MFA ao abrigo do NIS 2 Artigo 21.º(2)(j)
O NIS 2 faz da autenticação multifator um dever próprio. O Artigo 21.º(2)(j) é onde a obrigação vive, o CIR (UE) 2024/2690 §11.7 diz onde e quão forte, e o §30(2)(10) BSIG transporta-o para o direito alemão.
A versão curta
A MFA não é opcional nem é apenas um bónus. O Artigo 21.º(2)(j) coloca-a na lista das dez medidas de cibersegurança que toda a entidade essencial e importante tem de implementar. A mesma redação cobre também a comunicação segura por voz, vídeo e texto e, onde tal importa, as comunicações de emergência seguras dentro da sua organização.
O CIR (UE) 2024/2690 §11.7 preenche o detalhe. Os utilizadores têm de se autenticar com vários fatores ou com autenticação contínua quando a classificação do ativo a que acedem o exigir. A força da autenticação tem de corresponder a essa classificação. As joias da coroa precisam de autenticação mais forte do que um portal de menus de cafetaria.
O CIR §11.3.2 estabelece depois um piso rígido para as contas privilegiadas. Por defeito, têm de existir procedimentos fortes de identificação, autenticação e autorização (o CIR aponta a autenticação multifator como exemplo) para contas privilegiadas e de administração de sistemas. A Alemanha copia o dever através do §30(2)(10) BSIG com quase a mesma redação.
Artigo 21.º(2)(j) Diretiva NIS 2 (2022/2555)
a utilização de soluções de autenticação multifator ou de autenticação contínua, de comunicações de voz, vídeo e texto seguras e de sistemas de comunicação de emergência seguros dentro da entidade, se for caso disso.
Ponto (j) da lista das dez medidas de cibersegurança. Faz duas coisas ao mesmo tempo: nomeia a MFA (ou a autenticação contínua) como padrão de controlo de acesso e arrasta a voz, vídeo, texto e comunicações de emergência internas seguras para o mesmo dever.
CIR (UE) 2024/2690, Anexo §11.7 e §11.3
As entidades relevantes asseguram que os utilizadores são autenticados utilizando vários fatores de autenticação ou mecanismos de autenticação contínua para aceder às redes e sistemas de informação das entidades relevantes, se for caso disso, em conformidade com a classificação do ativo a que se pretende aceder.
O §11 é o capítulo de controlo de acesso do CIR e cobre o Artigo 21.º(2)(i) e (j) em conjunto. O §11.7 é a subsecção específica da MFA. O §11.3.2(a) vai mais longe para as contas privilegiadas e de administração: são exigidos procedimentos fortes de identificação, autenticação (a MFA é nomeada como exemplo) e autorização. Por ser um regulamento, o CIR é direito da UE diretamente vinculativo para os setores nomeados no seu Anexo.
§30(2)(10) BSIG (Alemanha)
a utilização de soluções de autenticação multifator ou de autenticação contínua, de comunicações de voz, vídeo e texto seguras e de sistemas de comunicação de emergência seguros dentro da entidade, se for caso disso.
A Alemanha copia o texto da UE quase palavra por palavra. A operacionalização prática na Alemanha aponta para o IT-Grundschutz baustein ORP.4 (Gestão de identidade e acessos), que é o catálogo de referência do BSI para fazer bem a autenticação na operação.
MFA adequada à classificação do ativo
Os utilizadores autenticam-se com vários fatores ou com autenticação contínua para acederem às suas redes e sistemas de informação, calibrado à classificação do ativo que estão a alcançar. A pré-condição implícita: classificou os seus ativos. Sem uma classificação não consegue cumprir a regra.
Contas privilegiadas: MFA por defeito
Para contas privilegiadas e para contas de administração de sistemas, são obrigatórias identificação, autenticação e autorização fortes. O CIR aponta a autenticação multifator como o exemplo concreto. Este é o único ponto em que a MFA deixa de estar condicionada à classificação e passa a ser o estado por defeito.
A força da autenticação corresponde à classificação
A força da autenticação tem de ser adequada à classificação do ativo a que se acede. Este é o segundo teste. A MFA não é uma coisa única. SMS, TOTP baseado em aplicação, aprovação por push, chaves de hardware FIDO2 e autenticação baseada em certificados estão em degraus muito diferentes. Quanto mais alta a classificação, mais alto o degrau de que precisa.
Comunicações seguras, não só MFA (Artigo 21.º(2)(j))
O ponto (j) é mais amplo do que a autenticação. Nomeia a comunicação segura por voz, vídeo e texto e os sistemas de comunicação de emergência dentro da entidade, se for caso disso. Uma implementação de MFA por si só não encerra a obrigação. A videoconferência interna, as mensagens e qualquer canal de emergência fora de banda estão dentro do mesmo dever.
A classificação do ativo determina a profundidade (Artigo 21.º(1))
O Artigo 21.º(1) exige medidas adequadas e proporcionadas. O CIR transforma isso num teste concreto para a MFA: a classificação do ativo fixa a força. Um pequeno Stadtwerk não precisa de chaves de hardware FIDO2 para cada portal interno. Um jump host de sistema de controlo é outra conversa. A alavanca é a classificação, não a dimensão da empresa por si só.
BSI / §30(2)(10) BSIG
A Alemanha copia a redação da UE quase à letra para o §30(2)(10) BSIG. A referência de implementação do BSI é o IT-Grundschutz baustein ORP.4 (Gestão de identidade e acessos), que dá requisitos concretos para a emissão de credenciais, a MFA, a separação de contas privilegiadas e o acesso de emergência. Se implementar o ORP.4 corretamente, está dentro do dever do §30(2)(10).
ENISA Technical Implementation Guidance
O TIG da ENISA para o CIR percorre o §11 em linguagem operacional simples e mapeia-o para a ISO/IEC 27001:2022, o NIST CSF 2.0, a ETSI EN 319 401 e a CEN/TS 18026:2024. Se já corre a ISO 27001 (controlos A.5.16, A.5.17, A.8.5) já tem quase tudo feito. O TIG também lista as provas que os auditores esperam: política de MFA, classificação de contas, registos de inscrição, registo de exceções.
Leis de transposição nacionais
Cada Estado-Membro tem a sua própria transposição do NIS 2 (Países Baixos: Cyberbeveiligingswet, Áustria: NISG, Bélgica: NIS2-Wet). O dever de MFA em si é idêntico porque assenta na diretiva e no CIR. O que difere entre países: o catálogo de referência (Grundschutz na Alemanha, BIO nos Países Baixos, sem catálogo formal noutros), o canal de reporte e a autoridade de supervisão.
Temos MFA na VPN, portanto está feito.
A MFA na VPN é um caminho de acesso. O CIR §11.7 é sobre o acesso aos ativos de acordo com a sua classificação, não sobre um dispositivo de perímetro. Se um utilizador privilegiado conseguir alcançar um controlador de domínio, uma consola de cópias de segurança, uma consola de administração na cloud ou um tenant SaaS sem MFA, o dever não está cumprido. O teste é a classificação do ativo por trás da porta, não a porta por onde entrou.
A MFA baseada em SMS chega para toda a gente.
O CIR §11.7.2 diz que a força da autenticação tem de corresponder à classificação. O SMS e o OTP por voz são o fator mais fraco: o SIM swap, a interceção SS7 e o phishing derrotam-nos todos. Para o acesso interno comum, o auditor pode aceitá-lo. Para as joias da coroa (consolas de administração, sistemas de controlo, fornecedores de identidade) precisa de autenticação resistente a phishing (FIDO2 / WebAuthn / smartcard). A força tem de escalar com a classificação.
As contas de serviço e de sistema não precisam de MFA.
O CIR §11.3.2(a) cobre expressamente as contas privilegiadas e as contas de administração de sistemas. As contas de serviço só ficam fora do âmbito da MFA humana se estiverem devidamente classificadas e usarem um controlo forte diferente (identidades geridas, credenciais de curta duração, certificados assinados, segredos emitidos por cofre com rotação). 'Conta de serviço, não dá para MFA, isenta' não é uma defesa. Ou é conduzida por humanos (então MFA), ou é conduzida por máquinas (então um modelo documentado de credenciais de máquina).
A maioria das equipas do Mittelstand alemão começa no mesmo sítio: primeiro MFA em todas as contas de administrador (consolas de administração na cloud, administrador de domínio, hipervisor, cópias de segurança, equipamento de rede, tenants SaaS), depois MFA no correio eletrónico, depois MFA no fornecedor de identidade para todos os utilizadores humanos. Isso cobre o piso do §11.3.2 e as linhas de classificação elevada de uma só vez. O resto é estendido a todos os utilizadores humanos em ativos classificados durante o primeiro ano.
O que os auditores realmente abrem: a lista de classificação de ativos, o relatório de inscrição de MFA do seu fornecedor de identidade e o registo de exceções. Se os três se alinharem, o dever está cumprido. O buraco isolado mais profundo que vemos não é técnico, é documental: falta a classificação de ativos, por isso não há regra para saber que ativos justificam que força de autenticação. Resolva primeiro a classificação, depois a implementação da MFA lê-se diretamente a partir da lista.
O módulo ACC (controlo de acesso) da plataforma carrega o dever do §11 de ponta a ponta. Regista os ativos com a sua classificação, lista que grupos de utilizadores precisam de acesso e documenta a força de autenticação para cada linha. A mesma tabela responde tanto ao teste do §11.7.1 (MFA se for caso disso) como ao do §11.7.2 (a força corresponde à classificação), e destaca separadamente as linhas de contas privilegiadas do §11.3.2.
A aprovação do inventário de controlo de acesso é nominal. As exceções (o sistema antigo que ainda não consegue fazer MFA, a integração que tem de usar uma conta de serviço) vivem no mesmo registo com um controlo compensatório documentado e uma data de revisão. O rasto de auditoria e a exportação de provas da plataforma dão ao auditor os artefactos que o TIG da ENISA nomeia: política, classificação, registo de inscrição, registo de exceções, tudo num só sítio.
- Diretiva (UE) 2022/2555 (NIS 2), Artigo 21.º(2)(j), eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regulamento de Execução (UE) 2024/2690 da Comissão (CIR), Anexo §11.3 e §11.7, eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Lei BSI (BSIG), §30(2)(10) na redação dada pela Lei de Implementação do NIS2 e de Reforço da Cibersegurança
- BSI IT-Grundschutz, Baustein ORP.4 'Identitäts- und Berechtigungsmanagement'
- ENISA Technical Implementation Guidance para o CIR (UE) 2024/2690 (à data de maio de 2026)