Artigos
Artigos de fundo sobre segurança de produto ligado e sobre o Cyber Resilience Act. O guia do CRA para fabricantes reúne o essencial do regulamento. Os novos artigos chegam também por RSS.
O resto da pilha: kernel Linux, Python e certificados
A semana do PHP2Shell trouxe também correções para o kernel Linux, para o Python e para o repositório de certificados. Para quem fabrica, a pergunta é a mesma nas três camadas: por que caminho, e com que atraso, a correção chega aos aparelhos já vendidos.
PHP2Shell e Node.js: o que pedem a quem fabrica aparelhos
A 21 de outubro de 2026, o PHP e o Node.js publicaram correções de segurança graves. Quem fabrica aparelhos com painel web, gateways ou executáveis Node tem três perguntas para responder: se o produto traz o componente, se há dever de reporte ao abrigo do artigo 14.º e como chega a correção às unidades que já estão no terreno.
Divulgação coordenada de vulnerabilidades: o canal que o CRA obriga a manter aberto
As obrigações de reporte às autoridades já estão em aplicação, mas são metade do circuito. O Anexo I, Parte II, exige a outra metade: um canal público para receber relatórios de vulnerabilidades, com política, ponto de contacto e processo por trás. Custa pouco a montar, e há norma para quase tudo.
CRA para quem faz software: o regulamento não é só para quem solda placas
O equívoco mais comum sobre o CRA é achar que se dirige a fabricantes de dispositivos. Software vendido como produto está dentro. SaaS puro está fora, com uma exceção que apanha muita gente. E 'grátis' não significa 'não comercial'.
O que o automóvel já aprendeu, e o resto da indústria vai aprender até 2027
O setor automóvel foi o primeiro obrigado a tratar a cibersegurança como propriedade do produto ao longo do ciclo de vida, com a UNECE R155/R156 e a ISO/SAE 21434. Os veículos ficam de fora do CRA precisamente por isso, e é também por isso que servem de antevisão.
CRA e RED: o dispositivo com rádio vive hoje sob dois regimes
Desde agosto de 2025, o equipamento de rádio ligado à internet tem de cumprir os requisitos de cibersegurança da RED. O CRA vem substituí-los, mas até dezembro de 2027 os dois regimes coexistem, e o trabalho feito num não vale automaticamente no outro.
Período de suporte: a promessa mais cara que o CRA obriga a fazer
O CRA obriga cada fabricante a declarar por quanto tempo suporta o produto: no mínimo, em regra, cinco anos. É uma decisão de engenharia, de contratos e de fornecedores disfarçada de campo num formulário.
Classificação do produto no CRA: a decisão que define o custo de tudo o resto
Padrão, importante classe I, importante classe II ou crítico. A categoria do produto determina se a conformidade é uma autoavaliação ou um organismo notificado, e a diferença mede-se em dezenas de milhares de euros e meses de calendário.
O reporte de 24h e 72h: como funciona a obrigação aplicável desde 11 de setembro de 2026
Desde 11 de setembro de 2026, um fabricante que saiba de uma vulnerabilidade ativamente explorada no seu produto tem 24 horas para o primeiro aviso. O que se reporta, a quem, por onde, e o que convém ter pronto.
SBOM para firmware embebido: o que o CRA pede e como se gera sem mentir
A lista de materiais de software exigida pelo CRA não se escreve à mão. Para firmware, a única SBOM credível sai do sistema de build, e o scan de binários serve para o que não construímos nós.