O Novo Regime de Cibersegurança: o que ficou por fazer

O Veredicto da Consulta Pública

---

A 14 de abril de 2026 submeti dez propostas em sede de consulta pública. Chegou o veredicto — e diz tanto sobre o regulamento como sobre o que ainda falta fazer.

A 14 de abril de 2026 publiquei aqui Da Conformidade Normativa à Resiliência Operacional: 10 Propostas para o Novo Regime de Cibersegurança, e submeti essas mesmas dez propostas em sede de consulta pública ao Projeto de Regulamento de execução do Regime Jurídico da Cibersegurança (transposição da Diretiva (UE) 2022/2555 — NIS 2).

O Centro Nacional de Cibersegurança (CNCS) publicou entretanto o Relatório de Consulta Pública. Importa, por rigor, fazer o balanço — e fazê-lo separando aquilo que o relatório diz daquilo que eu, como engenheiro, leio nele. São planos distintos e não devem ser confundidos.

---

PARTE I — OS FACTOS (o que consta do relatório)

Tudo o que se segue nesta secção é verificável no Relatório de Consulta Pública e nas peças do processo. Não há aqui interpretação.

• Enquadramento. Trata-se do Regulamento de execução do Regime Jurídico da Cibersegurança, aprovado pelo Decreto-Lei n.º 125/2025, de 4 de dezembro, no âmbito da transposição da Diretiva NIS 2.
• Período de consulta. Decorreu de 10/03/2026 a 22/04/2026, nos termos do n.º 2 do artigo 101.º do Código do Procedimento Administrativo.
• Participação. O CNCS recebeu contributos de 56 entidades e particulares.
• Autoria do relatório. Documento assinado pelo Coordenador do CNCS, Lino Santos (junho de 2026).
• Veredicto sobre as minhas dez propostas. As dez foram classificadas como "Não acolhido". O relatório fundamenta cada recusa, essencialmente, em três argumentos recorrentes: o Regulamento já fixa medidas mínimas obrigatórias, "aplicáveis de forma abrangente, transversal e pretendendo abarcar o maior número de situações"; a verificação da sua aplicação "tem em conta o princípio da proporcionalidade"; cabe a cada entidade, em função da sua análise de risco residual, implementar medidas mais exigentes.
• As alterações no eixo da gestão de risco. O Regulamento sofreu, no conjunto do processo, dezenas de alterações de redação acolhidas ou parcialmente acolhidas (entre outros, os artigos 6.º, 13.º a 17.º, 22.º a 28.º, 30.º, e vários controlos do Anexo III). No eixo que me ocupa — gestão de risco residual e inventário de ativos — as duas alterações de substância foram: Artigo 31.º — redação clarificada para passar a referir expressamente a análise e gestão do risco de cibersegurança e do risco residual, partindo da lógica de processos e funções críticas; Artigo 32.º — redação alterada, circunscrevendo a obrigação de listagem de ativos aos diretamente acessíveis publicamente através da Internet (contributo onde, entre outros, a posição da MEO foi parcialmente acolhida).

Este é o registo factual. As minhas dez propostas não foram acolhidas enquanto tais. Em rigor, porém, um dos vetores que defendi viu o texto mexer-se: o controlo PR.FC-2 (formação de pessoal com funções especializadas), no centro da minha Proposta 9, foi alterado — ainda que o relatório credite a alteração a contributos da ANA, da E-REDES, da CTT e da Aliança para a Cibersegurança, e não ao meu. A formulação "10/10 não acolhido" é, pois, formalmente exata; substantivamente, o Regulamento moveu-se em matéria que sinalizei, sem a referenciar.

---

PARTE II — A ANÁLISE (a minha leitura de engenharia)

Nota metodológica. Tudo o que se segue é análise da minha responsabilidade. A "leitura de convergência" abaixo resulta do cruzamento que eu próprio faço entre o meu contributo e os contributos públicos de outras entidades. Não é uma constatação formal do CNCS, que aprecia os contributos entidade a entidade e não os agrega por vetor de risco.

1. Não estive sozinho no diagnóstico — e isso é verificável

A minha leitura — e assumo-a como leitura — é a de que a comunidade de engenharia pesada e os operadores de infraestrutura identificaram, independentemente, os mesmos pontos cegos. Imponho-me, contudo, uma distinção: houve convergência no diagnóstico, não necessariamente no remédio. Várias entidades tocaram em OT e na cadeia de abastecimento, mas pediam por vezes soluções de sentido oposto ao meu — a NOS, por exemplo, requereu que a gestão de risco da cadeia fosse "calibrada ao impacto, criticidade e natureza dos fornecedores", isto é, mais margem; eu defendia o inverso, um piso normativo. É precisamente isto que singulariza o meu contributo: onde a maioria pedia flexibilidade, eu pedia um mínimo prescritivo calibrado à consequência física. O facto de a Siemens ter pedido normas de referência específicas para OT, e de o regulador as ter recusado com o argumento da abrangência genérica, é o sintoma central do problema que descrevo a seguir.

2. A incoerência da proporcionalidade: o argumento que vira a chave do regulador contra a sua decisão

O CNCS recusou a diferenciação OT/IT (a minha Proposta 1) afirmando que o Regulamento "já responde à necessidade de segregação de redes, à exigência de zero trust e à gestão de risco de ativos, incluindo legacy e OT", e que "as medidas pretendem ser o mais abrangentes possível". Invoca, simultaneamente e de forma transversal, o princípio da proporcionalidade.

É precisamente aqui que reside a contradição interna — e este é o ponto técnico que quero deixar claro:

Abrangência transversal e proporcionalidade não são a mesma coisa. São tendencialmente opostas.

A proporcionalidade, em rigor, exige que a medida seja calibrada à consequência da falha. O Regulamento não ignora a diferenciação — estratifica as medidas em níveis Básico, Substancial e Elevado, indexados à Matriz de Risco e à qualificação da entidade. O problema não é, portanto, a ausência de diferenciação; é o eixo segundo o qual ela é feita. Os níveis do QNRCS escalam por qualificação da entidade; a consequência ciberfísica, porém, não reside na entidade — reside no ativo. Um mesmo operador essencial alberga, sob o mesmo nível de conformidade, um servidor de correio e um PLC que comanda os disjuntores de uma subestação de alta tensão ou as comportas de um porto — e a consequência física de comprometer cada um é incomensurável. É esta a variável que a diferenciação por entidade não captura e que a proporcionalidade obriga a ponderar: o impacto ciberfísico ao nível da zona e da conduta, não da pessoa coletiva.

A própria engenharia já resolveu este problema. A norma ISA/IEC 62443-3-2 operacionaliza a proporcionalidade através de zonas e condutas com Target Security Levels (SL-T) atribuídos por avaliação de risco. Por outras palavras: a norma técnica que materializa o princípio da proporcionalidade em ambiente OT é exatamente aquela que o Regulamento se recusou a referenciar.

Daí a minha conclusão analítica: ao remeter a diferenciação OT para "a proporcionalidade aferida em sede de verificação", o regulador não aplicou a proporcionalidade — adiou-a, transferindo para o engenheiro operacional no terreno uma decisão que deveria ter um piso normativo. Não imputo má-fé ao CNCS; aponto uma incoerência de princípio que ainda vai a tempo de corrigir por via de instrução técnica.

3. O que defendi, com os devidos rigores técnicos

Score formal. As dez propostas foram integralmente indeferidas (10/10 «Não acolhido»), com fundamentação-tipo invariável do CNCS: «o Regulamento já responde / as entidades podem implementar medidas mais exigentes em função da análise de risco». Não houve uma única aceitação direta — ainda que, como notei na Parte I, o texto se tenha movido num vetor que sinalizei (PR.FC-2), por via de outros contribuintes.

Convergência (6 das 10). As propostas 1, 2, 4, 5, 8 e 9 foram corroboradas por terceiros — operadores e fabricantes de referência no domínio das infraestruturas críticas: BSO Consulting, Thales, Siemens, RS, APRITEL, NOS, E-REDES, CTT, ANA Aeroportos, TAG, JCF e a Aliança para a Cibersegurança. O núcleo técnico do contributo não era marginal: coincidia com a leitura de engenharia da própria indústria.

Contraste determinante. Nos mesmos controlos onde propus (PR.FC-2 formação, PR.GA-3 MFA, GR.CA-7 cadeia de abastecimento), o CNCS acolheu ou acolheu parcialmente — mas sempre por via dos outros contribuintes. A linha de fratura não é técnica, é de natureza do pedido: as contribuições acolhidas pediam clarificação/correção de redação sobre controlos preexistentes; eu propus aditamentos normativos (novas obrigações de texto, nível «Elevado»). O regulador rejeitou sistematicamente a criação de novas obrigações, remetendo-as para a autonomia da entidade e o princípio da proporcionalidade.

Propostas pioneiras (6, 7 e 10). Transição Pós-Quântica (PQC), Ciberseguro e Integridade de IA/algoritmia foram propostas só por mim — nenhum dos restantes 55 participantes as levantou. Foram indeferidas com o mesmo argumento genérico de remissão para a análise de risco da entidade, sem apreciação substantiva do mérito prospetivo. É o indicador mais claro de antecipação face ao corpo de contribuições: matéria que o Regulamento de execução, nesta versão, optou por não densificar.

Aproveito o balanço para precisar dois pontos que, na sua formulação divulgativa, mereciam maior rigor de engenharia. Faço-o de propósito: a credibilidade técnica constrói-se também a corrigir o próprio.

Sobre o OOBM e a recuperação (Proposta 3). A rede de gestão Out-of-Band (OOBM) não é, em si mesma, capacidade de black start. O black start é um procedimento de reposição do sistema elétrico (unidades auto-arrancáveis, ilhamento e ressincronização controlados). O que o OOBM garante é o plano de comando e telemetria segregado que permite à equipa de operação manter observabilidade e manobra remota durante uma reposição, mesmo com a rede de produção comprometida por ransomware. É um habilitador da resposta, não o ato de reposição. A formulação correta importa, porque é o que distingue uma exigência regulatória implementável de uma promessa difusa.

Sobre a automação e a estabilidade da rede (Proposta 4 — Human-in-the-Loop). Esta proposta não é autónoma: é a consequência justificativa da Proposta 1. A minha preocupação enuncia-se como cenário, não como facto consumado: caso uma decisão automatizada de mitigação tivesse autoridade de disparo direto sobre geração síncrona, a subida resultante do RoCoF (taxa de variação da frequência) numa rede com elevada penetração de eletrónica de potência poderia comprometer a estabilidade dinâmica. Sublinhe-se que uma arquitetura correta de zonas e condutas (Proposta 1) vedaria, à partida, que um controlo de mitigação de IT exercesse comando destrutivo direto sobre OT — razão pela qual os dois pontos são, no fundo, um só: é para barrar esta cadeia causal — falso positivo → disparo → perda de geração → instabilidade dinâmica — que a decisão destrutiva em OT não pode prescindir simultaneamente de validação humana e da segmentação que a confine. A resposta do regulador (medida DE.MC-7, que devolve à entidade a gestão dos falsos positivos) confirma a lacuna: existe a faculdade, falta o piso.

Sobre o vetor das credenciais (Proposta 5). Mantenho a defesa de MFA resistente a phishing (FIDO2/PKI) para perfis de administração. Evito, por rigor, números de efeito: basta constatar que o comprometimento de credenciais permanece, de forma recorrente, entre os principais vetores de acesso inicial reportados na telemetria de incidentes do setor (linha consistente com sucessivas edições do Verizon DBIR). Não é preciso uma percentagem para justificar a medida; basta a engenharia de risco.

---

Conclusão:

a proporcionalidade bem entendida é o caminho, não o obstáculo

O Regulamento é um marco. Mas o seu ponto mais frágil não é a ambição — é o eixo da sua diferenciação. Ao estratificar as medidas pela qualificação da entidade e não pela consequência ciberfísica do ativo, trata a Tecnologia Operacional como um caso particular do regime de IT — o que é incompatível com o próprio princípio da proporcionalidade que o regulador invoca para o justificar.

A correção não exige reabrir o diploma. Exige uma instrução técnica que autonomize o regime de OT, ancorada na IEC 62443-3-2 e na lógica de zonas e condutas com níveis de segurança calibrados à consequência física da falha. É a proporcionalidade — desta vez aplicada, e não adiada.

A resiliência não se decreta numa folha de papel; constrói-se com rigor e engenharia no terreno. As dez propostas não foram acolhidas. O diagnóstico que as sustenta, esse, continua de pé.

Fico à inteira disposição para o aprofundamento técnico que se entenda oportuno.

— Gaspar do Amaral

---

Referências normativas

• Diretiva (UE) 2022/2555 (NIS 2)
• Decreto-Lei n.º 125/2025, de 4 de dezembro (Regime Jurídico da Cibersegurança)
• Relatório de Consulta Pública do Regulamento de execução do RJC, CNCS (junho de 2026)
• ISA/IEC 62443-3-2 — Security risk assessment for system design (zonas, condutas e SL-T)
• NIST SP 800-207 — Zero Trust Architecture
• ANSI/TIA-942 — redundância de infraestrutura de data center, incluindo percursos de distribuição redundantes (Tier III/IV)
• ISO 22301 / NIST SP 800-34 — continuidade de negócio e planeamento de contingência (diversidade de percurso e recuperação)
• Verizon Data Breach Investigations Report (DBIR) — vetores de acesso inicial

As dez propostas originais foram submetidas à Consulta Pública em 14.04.2026. Este texto constitui o balanço técnico do respetivo veredicto.