NIS2 compliance

A máquina de infrações da UE passou dos avisos às remessas para o Tribunal em julho de 2026. A Irlanda, a Espanha, a França e os Países Baixos enfrentam agora sanções financeiras por não terem cumprido o prazo de transposição da NIS2 de outubro de 2024, com sanções pecuniárias diárias que se acumulam até cada país notificar a Comissão da transposição completa.

Em simultâneo, as estruturas de aplicação vão ganhando forma. O BSI da Alemanha está a auditar ativamente as entidades registadas. Os Países Baixos aprovaram a lei nacional um dia antes de a remessa ser apresentada. O Grupo de Cooperação NIS publicou o documento de mapeamento do artigo 21.º mais detalhado até à data. E a Comissão associou pela primeira vez, de forma explícita, a NIS2 à deteção de ameaças assistida por IA.

Este artigo aborda todos os desenvolvimentos relevantes da NIS2: o que mudou, que prazos estão em vigor e em que a equipa tem de agir já. Para os desenvolvimentos do mês anterior, consulte Últimas novidades NIS2: maio de 2026.

Pontos principais

• Remessas para o Tribunal contra quatro Estados-Membros. A 8 de julho de 2026, a Comissão Europeia remeteu a Irlanda, a Espanha, a França e os Países Baixos para o Tribunal de Justiça da UE por não terem transposto integralmente a NIS2. São solicitadas sanções financeiras para cada país.
• A Cyberbeveiligingswet dos Países Baixos entra em vigor a 15 de agosto de 2026. O Senado neerlandês aprovou a lei a 7 de julho. Mais de 8000 organizações têm de registar-se junto do NCSC, implementar medidas de segurança baseadas no risco e assegurar a supervisão ao nível do conselho de administração até essa data.
• O BSI alemão está agora a auditar, e não apenas a registar. A fase de supervisão ativa teve início a 6 de março de 2026. O BSI pode solicitar provas das medidas de segurança sem esperar por um incidente. Aplica-se um segundo prazo de registo, a 31 de julho, a uma parte significativa das 29 000 entidades abrangidas que falharam o prazo de março.
• O Grupo de Cooperação NIS publicou o seu documento de mapeamento do artigo 21.º. Publicado em junho de 2026, associa as obrigações da NIS2 e o Regulamento de Execução 2024/2690 às normas ISO 27001, NIST CSF 2.0 e IEC 62443 e aos quadros nacionais. É a orientação de conformidade mais concreta publicada até à data a nível da UE.
• O NCSC da Irlanda publicou orientações de governação cibernética para os conselhos de administração. Publicado a 7 de julho de 2026, o documento destina-se a CEOs, CIOs e CISOs de organizações reguladas pela NIS2 e assenta no quadro CyFun, baseado no NIST.
• A ENISA elevou o setor espacial para criticidade alta. O relatório NIS360 2026 coloca o setor espacial a par do setor bancário, da eletricidade e da aviação. Sete setores permanecem na zona de risco, onde a maturidade fica abaixo do que a criticidade exige.
• O Plano de Ação da UE para a Cibersegurança e a IA foi publicado a 7 de julho de 2026. É o primeiro documento a nível da UE a associar formalmente a conformidade com a NIS2 à deteção de ameaças assistida por IA como prática operacional esperada.
• O projeto de lei Cyber Security and Resilience Bill do Reino Unido foi aprovado na Câmara dos Comuns a 16 de junho. Deu entrada na Câmara dos Lordes a 17 de junho e a segunda leitura está agendada para 14 de julho. Os prestadores de serviços geridos e os operadores de centros de dados ficam abrangidos pela primeira vez.

Comissão Europeia leva Irlanda, Espanha, França e Países Baixos a tribunal por atrasos na NIS2

A 8 de julho de 2026, a Comissão Europeia remeteu a Irlanda, a Espanha, a França e os Países Baixos para o Tribunal de Justiça da UE por não terem notificado a transposição integral da Diretiva NIS2. As remessas incluem um pedido de sanções financeiras: uma quantia fixa e sanções pecuniárias diárias que se acumulam até cada país notificar a transposição completa.

O prazo de transposição era 17 de outubro de 2024. A Comissão enviou cartas de notificação aos Estados-Membros incumpridores em novembro de 2024 e pareceres fundamentados em maio de 2025. A remessa para o Tribunal é a terceira e última fase do processo por infração da UE.

O momento é digno de nota no caso dos Países Baixos. O Senado neerlandês aprovou a Cyberbeveiligingswet a 7 de julho, um dia antes de a remessa ser apresentada (mais pormenores adiante). A lei entra em vigor a 15 de agosto de 2026, mas a notificação formal da transposição à Comissão ainda não tinha sido apresentada à data da remessa. As sanções pecuniárias diárias deixarão de acumular-se quando a notificação estiver concluída.

Relativamente a Espanha, França e Irlanda, ainda não foi aprovada nenhuma lei nacional equivalente. A transposição em Espanha deverá ocorrer no final de 2026. A França e a Irlanda não anunciaram prazos firmes.

Os processos por infração têm números de processo individuais:

• Irlanda (INFR(2024)0279)
• Espanha (INFR(2024)0270)
• França (INFR(2024)0274)
• Países Baixos (INFR(2024)0288)

As remessas reforçam um ponto que as equipas de conformidade destes países já devem conhecer: os requisitos da Diretiva NIS2 são vinculativos independentemente do estado da transposição nacional. Os processos judiciais não suspendem as obrigações subjacentes, mas exercem pressão financeira sobre os governos para colmatarem a lacuna mais depressa.

Fonte: Comissão Europeia, 2026

Países Baixos: Cyberbeveiligingswet aprovada, entra em vigor a 15 de agosto

A 7 de julho de 2026, o Senado neerlandês aprovou a Cyberbeveiligingswet (a transposição neerlandesa da NIS2) e a Lei de Resiliência das Entidades Críticas (Wwke), que implementa a Diretiva relativa à Resiliência das Entidades Críticas (CER) da UE. Ambas as leis entram em vigor a 15 de agosto de 2026.

Mais de 8000 organizações são abrangidas: ministérios, municípios, autoridades da água, províncias, organismos administrativos independentes e parcerias intermunicipais. A partir de 15 de agosto, têm de:

1. Registar-se no Centro Nacional de Cibersegurança (NCSC) através do Registo de Entidades
2. Implementar medidas técnicas, operacionais e organizativas adequadas, com base numa avaliação de risco, incluindo as dependências da cadeia de abastecimento
3. Comunicar os incidentes de cibersegurança graves ao CSIRT pertinente e à autoridade de supervisão competente, dentro dos prazos legais
4. Assegurar a supervisão ao nível do conselho de administração: os membros do órgão de administração têm de ter conhecimentos suficientes de cibersegurança e concluir formação adequada

A aplicação cabe às autoridades de supervisão designadas, incluindo a Autoridade neerlandesa para as Infraestruturas Digitais. A Cyberbeveiligingswet introduz a responsabilidade dos administradores: as autoridades de supervisão podem emitir instruções vinculativas, realizar inspeções e suspender administradores sempre que necessário.

Para as organizações do setor público, o cumprimento da norma Baseline Information Security Government (BIO) 2 contribui para satisfazer os requisitos de segurança da Cbw.

A data de entrada em vigor, 15 de agosto, é um prazo improrrogável. O registo junto do NCSC deve começar antes dessa data: o próprio NCSC recomenda a preparação antecipada para evitar estrangulamentos no processo de registo.

Fonte: NL Digital Government, 2026

A nível da UE: Publicado novo documento de referência sobre medidas de segurança

Publicado em junho de 2026, o documento de referência sobre medidas de segurança do Grupo de Cooperação NIS oferece às organizações a orientação a nível da UE mais concreta até à data sobre a conformidade com o artigo 21.º da NIS2. O documento estabelece um quadro europeu comum de objetivos de cibersegurança e inclui uma tabela de mapeamento que associa as obrigações da NIS2 e o Regulamento de Execução europeu 2024/2690 a:

• ISO/IEC 27001
• IEC 62443
• NIST Cybersecurity Framework 2.0
• quadros nacionais de cibersegurança
• o CyberFundamentals Framework, CyFun®

O documento não é vinculativo. Não substitui a legislação nacional relativa à NIS2 nem as orientações setoriais. Mas, para as equipas de conformidade que já trabalham com base na ISO 27001 ou no NIST CSF 2.0, responde a uma pergunta em aberto desde a aprovação da diretiva: de que forma correspondem, exatamente, os controlos já existentes aos requisitos da NIS2?

O mapeamento é particularmente útil para organizações que operam em vários Estados-Membros. Em vez de manterem análises de lacunas separadas por jurisdição, as equipas podem utilizar o documento de referência como base comum e acrescentar depois os desvios nacionais.

O controlo de acessos, a autenticação e a gestão de acessos privilegiados surgem explicitamente nos objetivos mapeados, áreas em que as orientações do documento de referência se alinham diretamente com o artigo 21.º, n.º 2, alínea j), da NIS2, relativo à utilização de autenticação multifator e de sistemas de comunicação seguros.

Fontes: Center for Cybersecurity Belgium, 2026; Comissão Europeia, 2026

Irlanda: O NCSC publica orientações de governação cibernética para os conselhos de administração de entidades NIS2

A 7 de julho de 2026, o Centro Nacional de Cibersegurança da Irlanda publicou orientações sobre governação cibernética destinadas aos membros dos conselhos de administração de organizações reguladas pela NIS2. O documento dirige-se a CEOs, diretores-gerais, CIOs e CISOs, os dirigentes que têm responsabilidade pessoal pela gestão do risco de cibersegurança ao abrigo da NIS2.

As orientações centram-se no Cyber Fundamentals Framework (CyFun), o quadro nacional preferencial da Irlanda para a conformidade com a NIS2. O CyFun baseia-se no NIST Cybersecurity Framework e oferece aos conselhos de administração uma abordagem estruturada e baseada no risco para cumprirem as suas obrigações legais, sem exigir conhecimentos técnicos aprofundados.

O documento abrange três áreas práticas: compreender que perguntas os conselhos de administração devem colocar sobre o risco cibernético, identificar e gerir os riscos da cadeia de abastecimento e criar uma cultura organizacional em que a cibersegurança seja tratada como uma questão de governação, e não como um problema do departamento de TI.

O momento é deliberado. A Irlanda está atualmente sujeita a um processo por infração da UE por não ter transposto integralmente a NIS2 para o direito nacional: a Comissão remeteu o país para o Tribunal de Justiça a 8 de julho de 2026. A publicação de orientações ao nível do conselho de administração antes da transposição formal indica que o NCSC está a encaminhar as organizações para a conformidade, independentemente do ponto em que se encontre o processo legislativo.

Fonte: Portal oficial do Governo da Irlanda, 2026

ENISA NIS360 2026: Setor espacial sobe para criticidade alta

O relatório ENISA NIS360 2026 é a terceira avaliação anual da maturidade e da criticidade da cibersegurança em todos os setores do anexo I da Diretiva NIS2. A principal conclusão: o setor espacial juntou-se ao setor bancário, à eletricidade, à aviação e aos serviços digitais por defeito na faixa de criticidade mais alta.

A elevação reflete o papel crescente da infraestrutura espacial como camada de dependência para outros setores: a navegação, as comunicações, a liquidação financeira e a logística militar assentam todas em sistemas de satélite. Maior dependência significa maior impacto em caso de perturbação e maior criticidade temporal na recuperação.

Sete setores situam-se na zona de risco do NIS360 2026, em que a maturidade da cibersegurança fica abaixo do nível exigido pela respetiva criticidade:

1. Saúde
2. Transporte ferroviário
3. Transporte marítimo
4. Gestão de serviços de TIC
5. Espaço
6. Administração pública
7. Água potável e águas residuais

Três setores atingiram a faixa de maturidade alta: serviços de confiança, aviação e infraestruturas do mercado financeiro. O setor do gás começou a sair da zona de risco, graças à melhoria da partilha de informações e a uma implementação mais sólida das medidas de gestão de riscos.

A composição da zona de risco tem relevância operacional. As autoridades de supervisão utilizam os dados do NIS360 para definir as prioridades dos calendários de auditoria. Se a organização atua nos setores da saúde, ferroviário ou da administração pública, deve esperar uma maior atenção das autoridades de supervisão no segundo semestre de 2026.

A ENISA concluiu, no estudo NIS Investments 2025, que 70 % das organizações inquiridas apontaram o cumprimento da NIS2, do DORA e do CRA como o principal fator de investimento em cibersegurança, um valor que deverá aumentar à medida que as autoridades de supervisão passam do registo para a análise ativa.

Fonte: ENISA, 2026

Alemanha: O BSI entra na fase de supervisão ativa

O BSI da Alemanha entrou na fase de supervisão ativa a 6 de março de 2026, data em que expirou o prazo de registo ao abrigo da NIS2-Umsetzungsgesetz (NIS2UmsuCG). A lei foi promulgada a 6 de dezembro de 2025. Em junho de 2026, estava em vigor há seis meses.

A análise de 16 de junho do SecurityToday.de sobre a mudança na supervisão observou que a questão se alterou: já não se trata de saber se uma entidade está registada, mas se as medidas comunicadas resistem a um exame rigoroso.

O portal de registo do BSI abriu a 6 de janeiro de 2026. Uma parte significativa das cerca de 29 000 entidades abrangidas falhou o prazo de março. O BSI fixou um segundo prazo de registo, a 31 de julho de 2026. O registo tardio continua a ser possível, mas não constitui porto seguro: as obrigações de conformidade aplicam-se desde dezembro de 2025, independentemente do estado do registo.

O que significa supervisão ativa na prática:

• O BSI pode solicitar proativamente provas das medidas de segurança, sem esperar por um incidente
• As auditorias no local e remotas estão agora abrangidas
• As coimas para entidades essenciais podem ir até 10 milhões de euros ou 2 % do volume de negócios anual mundial, consoante o que for mais elevado
• Os membros dos órgãos de gestão enfrentam responsabilidade pessoal, incluindo a possível proibição temporária de exercer funções de gestão

A implementação alemã vai além do mínimo da UE em matéria de responsabilização dos dirigentes. A NIS2UmsuCG exige expressamente que os órgãos de gestão aprovem as medidas de cibersegurança, supervisionem a sua implementação e demonstrem competência pessoal. As autoridades de supervisão podem responsabilizar pessoalmente cada dirigente por falhas sistémicas.

O nível de exigência mais elevado da Alemanha tem uma vantagem prática. As organizações que cumprem os requisitos da NIS2UmsuCG satisfazem com folga o mínimo da UE. Para as empresas que operam em vários Estados-Membros, uma postura de segurança que satisfaça o escrutínio do BSI deverá, em geral, ser igualmente aceite pelas autoridades de supervisão vizinhas.

Para quem se registou tarde, a ordem de prioridades é clara: registar primeiro e só depois reunir provas documentadas das medidas. Se ocorrer um incidente de notificação obrigatória antes de as medidas estarem comprovadamente implementadas, um registo em falta ou tardio é um fator agravante.

Fonte: SecurityToday.de, 2026

Publicado o Plano de Ação da UE para a Cibersegurança e a IA

A 7 de julho de 2026, a Comissão Europeia publicou o Plano de Ação da UE para a Cibersegurança e a Inteligência Artificial (EU Action Plan on Cybersecurity and Artificial Intelligence). O documento define uma abordagem coordenada da UE à cibersegurança baseada em IA em todos os Estados-Membros, autoridades públicas e empresas.

O plano assenta em três objetivos: promover a utilização segura e responsável da IA avançada, reforçar a cibersegurança e a resiliência da UE e ampliar as capacidades de IA da Europa para fins de cibersegurança.

No que respeita à NIS2, o Plano de Ação refere expressamente a Diretiva NIS2 como parte do quadro jurídico existente em que se baseia e incentiva as organizações abrangidas pela NIS2 a utilizar IA (incluindo modelos de código aberto) para detetar e corrigir vulnerabilidades mais depressa. É o primeiro documento a nível da UE a associar formalmente a conformidade com a NIS2 à deteção de ameaças assistida por IA como prática operacional esperada.

As medidas concretas incluem:

• Um plano de referência europeu (blueprint) para o acesso seguro a sistemas de IA avançados para fins de cibersegurança, a desenvolver com a ENISA
• Uma plataforma de testes segura para organizações de setores críticos (energia, transportes, saúde, finanças e administração pública), destinada a testar e implementar soluções de IA em segurança
• Um Grande Desafio da UE sobre IA para a cibersegurança (EU Grand Challenge), que reúne a indústria, investigadores e comunidades de código aberto

O Plano de Ação coexiste com o Regulamento da IA, o Regulamento Ciberresiliência, o DORA e o Regulamento Cibersolidariedade. Não cria, por si só, novas obrigações vinculativas, mas indica onde a Comissão espera que se concentrem a ênfase na aplicação e o investimento no próximo ciclo legislativo.

Fonte: Comissão Europeia, 2026

Reino Unido: O Cyber Security and Resilience Bill passa na Câmara dos Comuns e segue para a Câmara dos Lordes

A 16 de junho de 2026, o projeto de lei Cyber Security and Resilience (Network and Information Systems) Bill concluiu a terceira leitura e a fase de relatório na Câmara dos Comuns. Teve a primeira leitura na Câmara dos Lordes a 17 de junho e tem a segunda leitura agendada para 14 de julho de 2026.

O projeto de lei foi apresentado ao Parlamento a 12 de novembro de 2025 e atualiza as Network and Information Systems Regulations 2018 (NIS1) em vigor. Não transpõe a NIS2 (o Reino Unido já não está vinculado pelo direito da UE), mas aproxima significativamente os requisitos do Reino Unido da norma NIS2 em termos de âmbito e de aplicação.

O que o projeto de lei acrescenta:

• Prestadores de serviços geridos ficam abrangidos pela primeira vez. Os prestadores de serviços geridos relevantes (RMSPs) têm de registar-se junto do ICO, implementar medidas de gestão de riscos e nomear um representante no Reino Unido caso não estejam estabelecidos neste país.
• Operadores de centros de dados também passam a ficar abrangidos.
• Os prazos de notificação de incidentes tornam-se mais rigorosos: notificação inicial em 24 horas e notificação completa em 72 horas, em linha com a estrutura do artigo 23.º da NIS2.
• Designação de fornecedores críticos: O ICO passa a ter poder para designar fornecedores cujo comprometimento afetaria serviços essenciais ou RMSPs.
• As sanções aumentam para até 17 milhões de libras ou 4 % do volume de negócios anual mundial em caso de infrações graves e até 10 milhões de libras ou 2 % nas menos graves.

A definição de incidente também é alargada: o projeto de lei abrange os incidentes «suscetíveis de ter um efeito adverso» nos serviços regulados, e não apenas os que tiveram um efeito real comprovado. Trata-se de uma alteração relevante para as organizações que estão a calibrar os respetivos limiares de notificação.

Foram propostas 63 alterações durante a tramitação do projeto de lei. Duas alterações apresentadas em junho, incluindo uma para acrescentar a cadeia de abastecimento alimentar como serviço essencial regulado, não obtiveram decisão na fase de relatório.

O Governo prevê realizar uma consulta em 2026 sobre a legislação secundária relativa a medidas específicas de gestão de riscos e a requisitos de notificação. Algumas disposições produzirão efeitos no primeiro dia ou no segundo mês após o assentimento real; outras seguirão por via de legislação secundária.

Fontes: Parlamento do Reino Unido, 2026; Parallel Parliament, 2026

Resumo

O período de junho a início de julho de 2026 marca o momento em que a aplicação da NIS2 passou da pressão política para a ação jurídica e de supervisão efetiva. As remessas para o Tribunal foram apresentadas. As leis nacionais estão a entrar em vigor. As autoridades de supervisão estão a solicitar provas das medidas de segurança, e não apenas confirmações de registo.

Para as organizações na Irlanda, em Espanha, em França e nos Países Baixos, os processos por infração não alteram em nada as obrigações subjacentes. Os requisitos da NIS2 são vinculativos desde outubro de 2024, independentemente do estado da transposição nacional. Os processos acrescentam consequências financeiras para os governos, mas não criam um período de tolerância para as entidades reguladas.

Para as organizações na Alemanha e nos Países Baixos, o calendário de conformidade está agora definido. O BSI está a auditar. A Cyberbeveiligingswet entra em vigor a 15 de agosto. O documento de mapeamento do artigo 21.º publicado pelo Grupo de Cooperação NIS em junho de 2026 é o resultado mais aplicável na prática deste período: se a equipa já trabalha com base na ISO 27001 ou no NIST CSF 2.0, oferece um caminho direto para concluir a análise de lacunas da NIS2 antes que uma autoridade de supervisão a faça por conta da organização.

Controlos de acesso NIS2 para a segurança da cadeia de abastecimento

48 % das violações envolvem agora terceiros. O artigo 21.º da NIS2 torna a governação do acesso de fornecedores uma obrigação legal. Eis como mapear o acesso dos fornecedores, impor a MFA e o princípio do menor privilégio e manter as provas de auditoria que demonstram que os controlos funcionam.

Passwork BlogAlex Muntyan

Shadow IT vs Shadow AI: Porque a IA é a maior ameaça

Os colaboradores estão a utilizar ferramentas de IA que não foram aprovadas, em contas que não é possível monitorizar, com dados que não é possível recuperar. Eis como é realmente o risco e o que a governação tem de abordar.

Passwork BlogAlex Muntyan

Saída de colaboradores: Guia de revogação segura de acessos 2026

Desativar uma conta SSO não revoga o acesso. As chaves de API, as credenciais de agentes de IA e as palavras-passe partilhadas sobrevivem à desativação. Este guia abrange o procedimento completo de saída de colaboradores, desde os gatilhos de hora zero até à limpeza de NHI.

Passwork BlogAlex Muntyan

Die EU-Vertragsverletzungsmaschinerie ist im Juli 2026 von Warnungen zu Gerichtsverweisungen übergegangen. Irland, Spanien, Frankreich und die Niederlande sehen sich nun finanziellen Sanktionen gegenüber, weil sie die NIS2-Umsetzungsfrist vom Oktober 2024 verpasst haben — tägliche Strafen laufen auf, bis jedes Land der Kommission die vollständige Umsetzung meldet.

Gleichzeitig nimmt die Durchsetzungsinfrastruktur Gestalt an. Das deutsche BSI prüft aktiv registrierte Einrichtungen. Die Niederlande haben ihr nationales Gesetz einen Tag vor der Gerichtsverweisung verabschiedet. Die NIS-Kooperationsgruppe hat das bisher detaillierteste Mapping-Dokument zu Artikel 21 veröffentlicht. Und die Kommission hat NIS2 erstmals explizit mit KI-gestützter Bedrohungserkennung verknüpft.

Dieser Artikel behandelt alle wesentlichen NIS2-Entwicklungen: was sich geändert hat, welche Fristen aktuell gelten und worauf Ihr Team jetzt reagieren muss. Für die Entwicklungen des Vormonats siehe Aktuelle NIS2-Nachrichten: Mai 2026.

Wichtigste Erkenntnisse

• Gerichtsverweisungen gegen vier Mitgliedstaaten eingereicht. Am 8. Juli 2026 hat die Europäische Kommission Irland, Spanien, Frankreich und die Niederlande an den Gerichtshof der EU verwiesen, weil sie NIS2 nicht vollständig umgesetzt haben. Für jedes Land werden finanzielle Sanktionen beantragt.
• Das niederländische Cyberbeveiligingswet tritt am 15. August 2026 in Kraft. Der niederländische Senat hat das Gesetz am 7. Juli verabschiedet. Mehr als 8.000 Organisationen müssen sich beim NCSC registrieren, risikobasierte Sicherheitsmaßnahmen umsetzen und bis zu diesem Datum eine Aufsicht auf Vorstandsebene sicherstellen.
• Das deutsche BSI prüft jetzt aktiv, nicht nur Registrierungen. Die aktive Aufsichtsphase begann am 6. März 2026. Das BSI kann Nachweise über Sicherheitsmaßnahmen anfordern, ohne auf einen Vorfall zu warten. Eine sekundäre Registrierungsfrist vom 31. Juli gilt für den erheblichen Anteil der 29.000 betroffenen Einrichtungen, die den März-Termin verpasst haben.
• Die NIS-Kooperationsgruppe hat ihr Artikel-21-Mapping-Dokument veröffentlicht. Im Juni 2026 veröffentlicht, ordnet es NIS2-Pflichten und die Durchführungsverordnung 2024/2690 ISO 27001, NIST CSF 2.0, IEC 62443 und nationalen Rahmenwerken zu — die bisher konkreteste EU-weite Compliance-Orientierung.
• Irlands NCSC hat Leitlinien zur Cyber-Governance auf Vorstandsebene veröffentlicht. Am 7. Juli 2026 veröffentlicht, richtet sich das Dokument an CEOs, CIOs und CISOs in NIS2-regulierten Organisationen und basiert auf dem NIST-basierten CyFun-Framework.
• ENISA hat den Raumfahrtsektor auf hohe Kritikalität angehoben. Der NIS360-Bericht 2026 stellt Raumfahrt neben Banken, Elektrizität und Luftfahrt. Sieben Sektoren verbleiben in der Risikozone, wo die Reife hinter den Kritikalitätsanforderungen zurückbleibt.
• Der EU-Aktionsplan zu Cybersicherheit und KI wurde am 7. Juli 2026 veröffentlicht. Es ist das erste EU-Dokument, das NIS2-Compliance formal mit KI-gestützter Bedrohungserkennung als erwartete operative Praxis verknüpft.
• Das britische Cyber Security and Resilience Bill hat das Unterhaus am 16. Juni passiert. Es wurde am 17. Juni ins Oberhaus eingebracht und ist für eine zweite Lesung am 14. Juli vorgesehen. Managed-Service-Provider und Rechenzentrumsbetreiber fallen erstmals in den Geltungsbereich.

EU-Kommission verklagt Irland, Spanien, Frankreich und die Niederlande wegen NIS2-Verzögerungen

Am 8. Juli 2026 hat die Europäische Kommission Irland, Spanien, Frankreich und die Niederlande an den Gerichtshof der EU verwiesen, weil sie die vollständige Umsetzung der NIS2-Richtlinie nicht gemeldet haben. Die Verweisungen beinhalten einen Antrag auf finanzielle Sanktionen: einen Pauschalbetrag plus tägliche Strafen, die auflaufen, bis jedes Land die vollständige Umsetzung meldet.

Die Umsetzungsfrist war der 17. Oktober 2024. Die Kommission sandte im November 2024 förmliche Mahnschreiben an nicht konforme Mitgliedstaaten und im Mai 2025 mit Gründen versehene Stellungnahmen. Die Gerichtsverweisung ist die dritte und letzte Stufe des EU-Vertragsverletzungsverfahrens.

Der Zeitpunkt ist für die Niederlande bemerkenswert. Der niederländische Senat hat das Cyberbeveiligingswet am 7. Juli verabschiedet — einen Tag bevor die Verweisung eingereicht wurde (mehr dazu unten). Das Gesetz tritt am 15. August 2026 in Kraft, aber die förmliche Mitteilung der Umsetzung an die Kommission war zum Zeitpunkt der Verweisung noch nicht eingereicht. Die täglichen Strafen werden nicht mehr auflaufen, sobald die Mitteilung abgeschlossen ist.

Für Spanien, Frankreich und Irland ist kein entsprechendes nationales Gesetz verabschiedet worden. Spaniens Umsetzung wird für Ende 2026 erwartet. Frankreich und Irland haben keine festen Zeitpläne angekündigt.

Die Vertragsverletzungsverfahren haben individuelle Fallnummern:

• Irland (INFR(2024)0279)
• Spanien (INFR(2024)0270)
• Frankreich (INFR(2024)0274)
• Niederlande (INFR(2024)0288)

Die Verweisungen bekräftigen einen Punkt, den Compliance-Teams in diesen Ländern bereits kennen sollten: Die Anforderungen der NIS2-Richtlinie sind unabhängig vom nationalen Umsetzungsstatus verbindlich. Gerichtsverfahren setzen die zugrunde liegenden Verpflichtungen nicht aus — sie erhöhen den finanziellen Druck auf Regierungen, die Lücke schneller zu schließen.

Quelle: Europäische Kommission, 2026

Niederlande: Cyberbeveiligingswet verabschiedet, tritt am 15. August in Kraft

Am 7. Juli 2026 hat der niederländische Senat sowohl das Cyberbeveiligingswet (die niederländische Umsetzung von NIS2) als auch das Critical Entities Resilience Act (Wwke) verabschiedet, das die EU-Richtlinie über die Resilienz kritischer Einrichtungen (CER) umsetzt. Beide Gesetze treten am 15. August 2026 in Kraft.

Mehr als 8.000 Organisationen fallen in den Geltungsbereich: Ministerien, Gemeinden, Wasserbehörden, Provinzen, unabhängige Verwaltungsorgane und interkommunale Partnerschaften. Ab dem 15. August müssen sie:

1. Sich beim National Cyber Security Centre (NCSC) über das Entitätenregister registrieren.
2. Angemessene technische, betriebliche und organisatorische Maßnahmen auf Basis einer Risikobewertung umsetzen — einschließlich Lieferkettenabhängigkeiten.
3. Schwerwiegende Cybersicherheitsvorfälle dem zuständigen CSIRT und der zuständigen Aufsichtsbehörde innerhalb der gesetzlichen Fristen melden.
4. Aufsicht auf Vorstandsebene sicherstellen: Mitglieder der Leitungsorgane müssen über ausreichende Cybersicherheitskenntnisse verfügen und entsprechende Schulungen absolvieren.

Die Durchsetzung liegt bei den benannten Aufsichtsbehörden, einschließlich der niederländischen Behörde für digitale Infrastruktur. Das Cyberbeveiligingswet führt eine Geschäftsführerhaftung ein: Aufsichtsbehörden können verbindliche Anweisungen erteilen, Inspektionen durchführen und Geschäftsführer bei Bedarf suspendieren.

Für Organisationen des öffentlichen Sektors zählt die Einhaltung des Standards Baseline Information Security Government (BIO) 2 zur Erfüllung der Sicherheitsanforderungen des Cbw.

Das Inkrafttreten am 15. August ist eine harte Frist. Die Registrierung beim NCSC sollte vor diesem Datum beginnen — das NCSC selbst empfiehlt, sich im Voraus vorzubereiten, um Engpässe im Registrierungsprozess zu vermeiden.

Quelle: NL Digital Government, 2026

EU-weit: Neues Referenzdokument zu Sicherheitsmaßnahmen veröffentlicht

Im Juni 2026 veröffentlicht, gibt das Referenzdokument zu Sicherheitsmaßnahmen der NIS-Kooperationsgruppe Organisationen die bisher konkreteste EU-weite Orientierung zur Einhaltung von NIS2 Artikel 21. Das Dokument etabliert einen gemeinsamen europäischen Rahmen für Cybersicherheitsziele und enthält eine Mapping-Tabelle, die NIS2-Pflichten und die Europäische Durchführungsverordnung 2024/2690 verknüpft mit:

• ISO/IEC 27001
• IEC 62443
• NIST Cybersecurity Framework 2.0
• nationalen Cybersicherheitsrahmenwerken
• dem CyberFundamentals Framework, CyFun®

Das Dokument ist nicht verbindlich. Es ersetzt weder nationale NIS2-Gesetzgebung noch sektorspezifische Leitlinien. Aber für Compliance-Teams, die bereits gegen ISO 27001 oder NIST CSF 2.0 arbeiten, beantwortet es eine Frage, die seit Verabschiedung der Richtlinie offen war: Wie genau ordnen sich meine bestehenden Kontrollen den NIS2-Anforderungen zu?

Das Mapping ist besonders nützlich für Organisationen, die in mehreren Mitgliedstaaten tätig sind. Anstatt separate Gap-Analysen pro Jurisdiktion zu pflegen, können Teams das Referenzdokument als gemeinsame Basis verwenden und dann nationale Abweichungen darüber legen.

Zugangskontrolle, Authentifizierung und Privileged Access Management erscheinen explizit in den gemappten Zielen — Bereiche, in denen sich die Orientierung des Referenzdokuments direkt mit NIS2 Artikel 21(2)(j) zur Verwendung von Multi-Faktor-Authentifizierung und sicheren Kommunikationssystemen deckt.

Quellen: Center for Cybersecurity Belgium, 2026; Europäische Kommission, 2026

Irland: NCSC veröffentlicht Leitlinien zur Cyber-Governance auf Vorstandsebene für NIS2-Einrichtungen

Am 7. Juli 2026 hat Irlands National Cyber Security Centre Leitlinien zur Cyber-Governance für Mitglieder von Leitungsorganen in NIS2-regulierten Organisationen veröffentlicht. Das Dokument richtet sich an CEOs, Geschäftsführer, CIOs und CISOs — die Führungskräfte, die unter NIS2 persönlich für das Cybersicherheits-Risikomanagement verantwortlich sind.

Die Leitlinien konzentrieren sich auf das Cyber Fundamentals Framework (CyFun), Irlands bevorzugtes nationales Framework für NIS2-Compliance. CyFun basiert auf dem NIST Cybersecurity Framework und gibt Vorständen einen strukturierten, risikobasierten Ansatz zur Erfüllung ihrer rechtlichen Verpflichtungen, ohne tiefes technisches Fachwissen zu erfordern.

Das Dokument deckt drei praktische Bereiche ab: Verständnis, welche Fragen Vorstände zu Cyberrisiken stellen sollten, Identifizierung und Management von Lieferkettenrisiken sowie Aufbau einer Organisationskultur, in der Cybersicherheit als Governance-Thema behandelt wird, nicht als Problem der IT-Abteilung.

Der Zeitpunkt ist bewusst gewählt. Irland ist derzeit Gegenstand eines EU-Vertragsverletzungsverfahrens wegen nicht vollständiger Umsetzung von NIS2 in nationales Recht — die Kommission hat das Land am 8. Juli 2026 an den Gerichtshof verwiesen. Die Veröffentlichung von Leitlinien auf Vorstandsebene vor der formellen Umsetzung signalisiert, dass das NCSC Organisationen unabhängig vom Stand des Gesetzgebungsverfahrens zur Compliance führt.

Quelle: Offizielles Portal der irischen Regierung, 2026

ENISA NIS360 2026: Raumfahrtsektor auf hohe Kritikalität angehoben

Der ENISA NIS360-Bericht 2026 ist die dritte jährliche Bewertung der Cybersicherheitsreife und Kritikalität aller Sektoren aus Anhang I der NIS2-Richtlinie. Die Haupterkenntnis: Der Raumfahrtsektor hat sich zu Banken, Elektrizität, Luftfahrt und digital-nativen Diensten im höchsten Kritikalitätsband gesellt.

Die Anhebung spiegelt die wachsende Rolle der Raumfahrtinfrastruktur als Abhängigkeitsschicht für andere Sektoren wider: Navigation, Kommunikation, Finanzabwicklung und Militärlogistik laufen alle über Satellitensysteme. Höhere Abhängigkeit bedeutet höhere Auswirkungen bei Störungen und höhere Zeitkritikalität bei der Wiederherstellung.

Sieben Sektoren fallen in die NIS360-Risikozone 2026, in der die Cybersicherheitsreife hinter dem Niveau zurückbleibt, das ihre Kritikalität erfordert:

1. Gesundheit
2. Schienenverkehr
3. Seeverkehr
4. IKT-Dienstleistungsmanagement
5. Raumfahrt
6. Öffentliche Verwaltung
7. Trink- und Abwasser

Drei Sektoren erreichten das hohe Reifeband: Vertrauensdienste, Luftfahrt und Finanzmarktinfrastrukturen. Der Gassektor hat begonnen, sich aus der Risikozone zu bewegen, angetrieben durch verbesserten Informationsaustausch und stärkere Umsetzung von Risikomanagementmaßnahmen.

Die Zusammensetzung der Risikozone ist operativ relevant. Aufsichtsbehörden nutzen NIS360-Daten zur Priorisierung ihrer Auditkalender. Wenn Ihre Organisation im Gesundheitswesen, Schienenverkehr oder der öffentlichen Verwaltung tätig ist, erwarten Sie in der zweiten Jahreshälfte 2026 erhöhte aufsichtliche Aufmerksamkeit.

Die ENISA NIS Investments 2025-Studie ergab, dass 70% der befragten Organisationen NIS2-, DORA- und CRA-Compliance als Haupttreiber der Cybersicherheitsausgaben nannten — eine Zahl, die wahrscheinlich steigen wird, wenn Aufsichtsbehörden von der Registrierung zur aktiven Prüfung übergehen.

Quelle: ENISA, 2026

Deutschland: BSI tritt in aktive Aufsichtsphase ein

Das deutsche BSI trat am 6. März 2026 in die aktive Aufsichtsphase ein — das Datum, an dem die Registrierungsfrist gemäß dem NIS2-Umsetzungsgesetz (NIS2UmsuCG) ablief. Das Gesetz wurde am 6. Dezember 2025 erlassen. Bis Juni 2026 war es sechs Monate in Kraft.

Die Analyse von SecurityToday.de vom 16. Juni zum Aufsichtswechsel stellte fest, dass sich die Frage geändert hat: nicht mehr, ob eine Einrichtung registriert ist, sondern ob ihre gemeldeten Maßnahmen einer Prüfung standhalten.

Das BSI-Registrierungsportal wurde am 6. Januar 2026 eröffnet. Ein erheblicher Anteil der etwa 29.000 betroffenen Einrichtungen hat die März-Frist verpasst. Das BSI hat eine sekundäre Registrierungsfrist auf den 31. Juli 2026 gesetzt. Eine späte Registrierung bleibt möglich, schafft aber keinen sicheren Hafen — die Compliance-Pflichten gelten seit Dezember 2025, unabhängig vom Registrierungsstatus.

Was aktive Aufsicht in der Praxis bedeutet:

• Das BSI kann proaktiv Nachweise über Sicherheitsmaßnahmen anfordern — ohne auf einen Vorfall zu warten.
• Vor-Ort- und Fernprüfungen sind jetzt im Umfang enthalten.
• Bußgelder für wesentliche Einrichtungen erreichen bis zu 10 Millionen Euro oder 2% des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.
• Mitglieder von Leitungsorganen tragen persönliche Haftung, einschließlich möglicher vorübergehender Verbote zur Ausübung von Leitungsfunktionen.

Deutschlands Umsetzung geht bei der Geschäftsführerhaftung über das EU-Minimum hinaus. Das NIS2UmsuCG verlangt ausdrücklich, dass Leitungsorgane Cybersicherheitsmaßnahmen genehmigen, deren Umsetzung überwachen und persönliche Kompetenz nachweisen. Aufsichtsbehörden können einzelne Führungskräfte persönlich für systemische Versäumnisse zur Verantwortung ziehen.

Es gibt einen praktischen Vorteil von Deutschlands strengerem Standard. Organisationen, die die NIS2UmsuCG-Anforderungen erfüllen, erfüllen das EU-Minimum mit Spielraum. Für Unternehmen, die in mehreren Mitgliedstaaten tätig sind, wird eine Sicherheitslage, die der BSI-Prüfung standhält, in der Regel auch bei benachbarten Aufsichtsbehörden bestehen.

Für späte Registranten ist die Prioritätenreihenfolge klar: zuerst registrieren, dann dokumentierte Nachweise über Maßnahmen erstellen. Wenn ein meldepflichtiger Vorfall eintritt, bevor Maßnahmen nachweislich vorhanden sind, ist eine versäumte oder verspätete Registrierung ein erschwerender Faktor.

Quelle: SecurityToday.de, 2026

EU-Aktionsplan zu Cybersicherheit und KI veröffentlicht

Am 7. Juli 2026 hat die Europäische Kommission den EU-Aktionsplan zu Cybersicherheit und Künstlicher Intelligenz veröffentlicht. Das Dokument legt einen koordinierten EU-Ansatz für KI-gestützte Cybersicherheit über Mitgliedstaaten, Behörden und Unternehmen hinweg fest.

Der Plan ist auf drei Ziele ausgerichtet: Förderung einer sicheren und verantwortungsvollen Nutzung fortschrittlicher KI, Stärkung der EU-Cybersicherheit und -Resilienz sowie Ausbau der KI-Fähigkeiten Europas für Cybersicherheitszwecke.

Auf der NIS2-Seite nennt der Aktionsplan explizit die NIS2-Richtlinie als Teil des bestehenden Rechtsrahmens, auf dem er aufbaut, und ermutigt Organisationen, die NIS2 unterliegen, KI (einschließlich Open-Source-Modelle) zur schnelleren Erkennung und Behebung von Schwachstellen einzusetzen. Dies ist das erste EU-Dokument, das NIS2-Compliance formal mit KI-gestützter Bedrohungserkennung als erwartete operative Praxis verknüpft.

Konkrete Maßnahmen umfassen:

• Einen European Blueprint für sicheren Zugang zu fortschrittlichen KI-Systemen für Cybersicherheitszwecke, der mit ENISA entwickelt werden soll.
• Eine sichere Testplattform für Organisationen in kritischen Sektoren (Energie, Verkehr, Gesundheit, Finanzen und öffentliche Verwaltung) zum sicheren Testen und Einsetzen von KI-Lösungen.
• Eine EU Grand Challenge zu KI für Cybersicherheit, die Industrie, Forscher und Open-Source-Communities zusammenbringt.

Der Aktionsplan steht neben dem AI Act, dem Cyber Resilience Act, DORA und dem Cyber Solidarity Act. Er schafft selbst keine neuen verbindlichen Verpflichtungen, signalisiert aber, wohin die Kommission erwartet, dass Durchsetzungsschwerpunkte und Investitionen im nächsten Gesetzgebungszyklus gehen.

Quelle: Europäische Kommission, 2026

UK: Cyber Security and Resilience Bill passiert Unterhaus, geht ins Oberhaus

Am 16. Juni 2026 hat das Cyber Security and Resilience (Network and Information Systems) Bill seine dritte Lesung und Berichtsphase im House of Commons abgeschlossen. Es erhielt seine erste Lesung im House of Lords am 17. Juni und ist für eine zweite Lesung im Lords am 14. Juli 2026 vorgesehen.

Das Gesetz wurde am 12. November 2025 ins Parlament eingebracht und aktualisiert die bestehenden Network and Information Systems Regulations 2018 (NIS1). Es setzt NIS2 nicht um (das Vereinigte Königreich ist nicht mehr an EU-Recht gebunden), aber es nähert die UK-Anforderungen erheblich dem NIS2-Standard in Umfang und Durchsetzung an.

Was das Gesetz hinzufügt:

• Managed-Service-Provider fallen erstmals in den Geltungsbereich. Relevant Managed Service Providers (RMSPs) müssen sich beim ICO registrieren, Risikomanagementmaßnahmen umsetzen und einen UK-Vertreter benennen, wenn sie nicht im UK ansässig sind.
• Rechenzentrumsbetreiber werden ebenfalls in den Geltungsbereich aufgenommen.
• Fristen für die Vorfallsmeldung werden verschärft: 24-Stunden-Erstmeldung, 72-Stunden-Vollmeldung — entsprechend der NIS2-Artikel-23-Struktur.
• Bezeichnung kritischer Lieferanten: Das ICO erhält die Befugnis, Lieferanten zu bezeichnen, deren Kompromittierung wesentliche Dienste oder RMSPs beeinträchtigen würde.
• Strafen steigen auf bis zu 17 Millionen Pfund oder 4% des weltweiten Jahresumsatzes bei schwerwiegenden Verstößen; bis zu 10 Millionen Pfund oder 2% bei weniger schwerwiegenden.

Die Vorfallsdefinition wird ebenfalls erweitert: Das Gesetz erfasst Vorfälle, die „geeignet sind, eine nachteilige Auswirkung" auf regulierte Dienste zu haben, nicht nur solche mit einer nachgewiesenen tatsächlichen Auswirkung. Dies ist eine bedeutsame Änderung für Organisationen, die derzeit ihre Meldeschwellen kalibrieren.

63 Änderungsanträge wurden während der Gesetzespassage vorgeschlagen. Zwei im Juni eingereichte Änderungsanträge, darunter einer zur Aufnahme der Lebensmittellieferkette als regulierten wesentlichen Dienst, erhielten in der Berichtsphase keine Entscheidung.

Die Regierung erwartet, 2026 eine Konsultation zu sekundärer Gesetzgebung durchzuführen, die spezifische Risikomanagementmaßnahmen und Meldepflichten abdeckt. Einige Bestimmungen werden ab dem ersten Tag oder zweiten Monat nach der königlichen Zustimmung in Kraft treten; andere werden durch sekundäre Gesetzgebung folgen.

Quellen: UK Parliament, 2026; Parallel Parliament, 2026

Zusammenfassung

Der Zeitraum von Juni bis Anfang Juli 2026 markiert den Punkt, an dem die NIS2-Durchsetzung von politischem Druck zu aktiven rechtlichen und aufsichtlichen Maßnahmen übergegangen ist. Gerichtsverweisungen sind eingereicht. Nationale Gesetze treten in Kraft. Aufsichtsbehörden fordern Nachweise über Sicherheitsmaßnahmen an, nicht nur Registrierungsbestätigungen.

Für Organisationen in Irland, Spanien, Frankreich und den Niederlanden ändern die Vertragsverletzungsverfahren nichts an den zugrunde liegenden Verpflichtungen. NIS2-Anforderungen sind seit Oktober 2024 verbindlich, unabhängig vom nationalen Umsetzungsstatus. Die Verfahren fügen finanzielle Konsequenzen für Regierungen hinzu — sie schaffen keine Schonfrist für regulierte Einrichtungen.

Für Organisationen in Deutschland und den Niederlanden ist der Compliance-Kalender jetzt festgelegt. Das BSI prüft. Das Cyberbeveiligingswet tritt am 15. August in Kraft. Das im Juni 2026 von der NIS-Kooperationsgruppe veröffentlichte Artikel-21-Mapping-Dokument ist das umsetzbarste Ergebnis dieses Zeitraums: Wenn Ihr Team bereits gegen ISO 27001 oder NIST CSF 2.0 arbeitet, bietet es einen direkten Weg, Ihre NIS2-Gap-Analyse abzuschließen, bevor eine Aufsichtsbehörde dies für Sie übernimmt.

NIS2-Zugangskontrollen für Lieferkettensicherheit

48% der Sicherheitsverletzungen betreffen mittlerweile Dritte. NIS2 Artikel 21 macht Lieferanten-Zugangs-Governance zu einer rechtlichen Verpflichtung. Hier erfahren Sie, wie Sie Lieferantenzugriffe erfassen, MFA und Least Privilege durchsetzen und Audit-Nachweise führen, die Ihre Kontrollen belegen.

Passwork BlogAlex Muntyan

Schatten-IT vs. Schatten-KI: Warum KI die größere Bedrohung ist

Mitarbeiter nutzen KI-Tools, die Sie nicht genehmigt haben, auf Konten, die Sie nicht überwachen können, mit Daten, die Sie nicht wiederherstellen können. Hier erfahren Sie, wie das Risiko tatsächlich aussieht und was Governance adressieren muss.

Passwork BlogAlex Muntyan

Mitarbeiter-Offboarding: Leitfaden zur sicheren Zugangsentziehung 2026

Das Deaktivieren eines SSO-Kontos entzieht nicht den Zugang. API-Schlüssel, KI-Agenten-Credentials und geteilte Passwörter überleben es. Dieser Leitfaden behandelt das vollständige Offboarding-Playbook — von Zero-Hour-Triggern bis zur NHI-Bereinigung.

Passwork BlogAlex Muntyan

El mecanismo de infracción de la UE pasó de las advertencias a las remisiones judiciales en julio de 2026. Irlanda, España, Francia y los Países Bajos enfrentan ahora sanciones económicas por incumplir el plazo de transposición de NIS2 de octubre de 2024 — con penalizaciones diarias que se acumulan hasta que cada país notifique la transposición completa a la Comisión.

Al mismo tiempo, la infraestructura de aplicación se está consolidando. La BSI de Alemania está auditando activamente a las entidades registradas. Los Países Bajos aprobaron su ley nacional un día antes de que se presentara la remisión. El Grupo de Cooperación NIS publicó el documento de mapeo del Artículo 21 más detallado hasta la fecha. Y la Comisión vinculó explícitamente NIS2 con la detección de amenazas asistida por IA por primera vez.

Este artículo cubre todos los desarrollos materiales de NIS2: qué cambió, qué plazos están vigentes y qué necesita abordar su equipo ahora. Para los desarrollos del mes anterior, consulte Últimas noticias de NIS2: mayo de 2026.

Puntos clave

• Remisiones judiciales presentadas contra cuatro Estados miembros. El 8 de julio de 2026, la Comisión Europea remitió a Irlanda, España, Francia y los Países Bajos al Tribunal de Justicia de la UE por no transponer completamente NIS2. Se solicitan sanciones económicas para cada país.
• La Cyberbeveiligingswet de los Países Bajos entra en vigor el 15 de agosto de 2026. El Senado neerlandés aprobó la ley el 7 de julio. Más de 8.000 organizaciones deben registrarse ante el NCSC, implementar medidas de seguridad basadas en riesgos y garantizar la supervisión a nivel de consejo directivo para esa fecha.
• La BSI de Alemania ahora audita, no solo registra. La fase de supervisión activa comenzó el 6 de marzo de 2026. La BSI puede solicitar evidencia de medidas de seguridad sin esperar a que ocurra un incidente. Un plazo de registro secundario del 31 de julio se aplica a la parte significativa de las 29.000 entidades dentro del ámbito que no cumplieron en marzo.
• El Grupo de Cooperación NIS publicó su documento de mapeo del Artículo 21. Publicado en junio de 2026, mapea las obligaciones de NIS2 y el Reglamento de Implementación 2024/2690 con ISO 27001, NIST CSF 2.0, IEC 62443 y marcos nacionales — la guía de cumplimiento más concreta a nivel de la UE publicada hasta la fecha.
• El NCSC de Irlanda publicó orientación sobre gobernanza cibernética a nivel de consejo directivo. Publicado el 7 de julio de 2026, el documento está dirigido a CEO, CIO y CISO en organizaciones reguladas por NIS2 y se basa en el marco CyFun basado en NIST.
• ENISA elevó el sector espacial a alta criticidad. El informe NIS360 2026 coloca el espacio junto con la banca, la electricidad y la aviación. Siete sectores permanecen en la zona de riesgo, donde la madurez no alcanza las demandas de criticidad.
• El Plan de Acción de la UE sobre Ciberseguridad e IA se publicó el 7 de julio de 2026. Es el primer documento a nivel de la UE que vincula formalmente el cumplimiento de NIS2 con la detección de amenazas asistida por IA como práctica operativa esperada.
• El proyecto de ley de Ciberseguridad y Resiliencia del Reino Unido fue aprobado por los Comunes el 16 de junio. Ingresó a los Lores el 17 de junio y está programado para una segunda lectura el 14 de julio. Los proveedores de servicios gestionados y los operadores de centros de datos entran en el ámbito por primera vez.

La Comisión de la UE lleva a Irlanda, España, Francia y los Países Bajos ante los tribunales por retrasos en NIS2

El 8 de julio de 2026, la Comisión Europea remitió a Irlanda, España, Francia y los Países Bajos al Tribunal de Justicia de la UE por no notificar la transposición completa de la Directiva NIS2. Las remisiones incluyen una solicitud de sanciones económicas: una suma global más penalizaciones diarias que se acumulan hasta que cada país notifique la transposición completa.

El plazo de transposición fue el 17 de octubre de 2024. La Comisión envió notificaciones formales a los Estados miembros incumplidores en noviembre de 2024 y dictámenes motivados en mayo de 2025. La remisión judicial es la tercera y última etapa del procedimiento de infracción de la UE.

El momento es notable para los Países Bajos. El Senado neerlandés aprobó la Cyberbeveiligingswet el 7 de julio — un día antes de que se presentara la remisión (más información al respecto a continuación). La ley entra en vigor el 15 de agosto de 2026, pero la notificación formal de transposición a la Comisión aún no se había presentado en el momento de la remisión. Las penalizaciones diarias dejarán de acumularse una vez que se complete la notificación.

Para España, Francia e Irlanda, no se ha aprobado ninguna ley nacional equivalente. Se espera que la transposición de España se realice a finales de 2026. Francia e Irlanda no han anunciado plazos firmes.

Los casos de infracción tienen números de caso individuales:

• Irlanda (INFR(2024)0279)
• España (INFR(2024)0270)
• Francia (INFR(2024)0274)
• Países Bajos (INFR(2024)0288)

Las remisiones refuerzan un punto que los equipos de cumplimiento en estos países ya deberían conocer: los requisitos de la Directiva NIS2 son vinculantes independientemente del estado de transposición nacional. Los procedimientos judiciales no suspenden las obligaciones subyacentes — añaden presión financiera sobre los gobiernos para cerrar la brecha más rápidamente.

Fuente: Comisión Europea, 2026

Países Bajos: Cyberbeveiligingswet aprobada, entra en vigor el 15 de agosto

El 7 de julio de 2026, el Senado neerlandés aprobó tanto la Cyberbeveiligingswet (la transposición neerlandesa de NIS2) como la Ley de Resiliencia de Entidades Críticas (Wwke), que implementa la Directiva de Resiliencia de Entidades Críticas (CER) de la UE. Ambas leyes entran en vigor el 15 de agosto de 2026.

Más de 8.000 organizaciones están dentro del ámbito: ministerios, municipios, autoridades del agua, provincias, organismos administrativos independientes y asociaciones intermunicipales. A partir del 15 de agosto, deben:

1. Registrarse ante el Centro Nacional de Ciberseguridad (NCSC) a través del Registro de Entidades.
2. Implementar medidas técnicas, operativas y organizativas apropiadas basadas en una evaluación de riesgos — incluyendo dependencias de la cadena de suministro.
3. Notificar incidentes de ciberseguridad importantes al CSIRT correspondiente y a la autoridad de supervisión competente dentro de los plazos legales.
4. Garantizar la supervisión a nivel de consejo directivo: los miembros del órgano de dirección deben tener conocimientos suficientes de ciberseguridad y completar la formación adecuada.

La aplicación recae en las autoridades de supervisión designadas, incluyendo la Autoridad Neerlandesa para la Infraestructura Digital. La Cyberbeveiligingswet introduce la responsabilidad de los directores: los supervisores pueden emitir instrucciones vinculantes, realizar inspecciones y suspender a los directores cuando sea necesario.

Para las organizaciones del sector público, el cumplimiento del estándar Baseline Information Security Government (BIO) 2 cuenta para cumplir los requisitos de seguridad de la Cbw.

La fecha de entrada en vigor del 15 de agosto es un plazo estricto. El registro ante el NCSC debería comenzar antes de esa fecha — el propio NCSC recomienda prepararse con antelación para evitar cuellos de botella en el proceso de registro.

Fuente: NL Digital Government, 2026

A nivel de la UE: Publicado nuevo documento de referencia sobre medidas de seguridad

Publicado en junio de 2026, el documento de referencia sobre medidas de seguridad del Grupo de Cooperación NIS ofrece a las organizaciones la guía más concreta a nivel de la UE sobre el cumplimiento del Artículo 21 de NIS2 hasta la fecha. El documento establece un marco europeo común para objetivos de ciberseguridad e incluye una tabla de mapeo que vincula las obligaciones de NIS2 y el Reglamento de Implementación Europeo 2024/2690 con:

• ISO/IEC 27001
• IEC 62443
• NIST Cybersecurity Framework 2.0
• marcos nacionales de ciberseguridad
• el CyberFundamentals Framework, CyFun®

El documento no es vinculante. No reemplaza la legislación nacional de NIS2 ni las directrices específicas del sector. Pero para los equipos de cumplimiento que ya trabajan con ISO 27001 o NIST CSF 2.0, responde a una pregunta que ha estado abierta desde que se aprobó la directiva: ¿cómo se mapean exactamente mis controles existentes con los requisitos de NIS2?

El mapeo es particularmente útil para organizaciones que operan en múltiples Estados miembros. En lugar de mantener análisis de brechas separados por jurisdicción, los equipos pueden usar el documento de referencia como una línea base compartida y luego añadir las desviaciones nacionales encima.

El control de acceso, la autenticación y la gestión de acceso privilegiado aparecen explícitamente en los objetivos mapeados — áreas donde la guía del documento de referencia se alinea directamente con el Artículo 21(2)(j) de NIS2 sobre el uso de autenticación multifactor y sistemas de comunicación seguros.

Fuentes: Centro de Ciberseguridad de Bélgica, 2026; Comisión Europea, 2026

Irlanda: El NCSC publica orientación sobre gobernanza cibernética a nivel de consejo directivo para entidades NIS2

El 7 de julio de 2026, el Centro Nacional de Ciberseguridad de Irlanda publicó orientación sobre gobernanza cibernética para miembros de consejos de administración en organizaciones reguladas por NIS2. El documento está dirigido a CEO, directores generales, CIO y CISO — los ejecutivos que asumen responsabilidad personal por la gestión de riesgos de ciberseguridad bajo NIS2.

La orientación se centra en el Cyber Fundamentals Framework (CyFun), el marco nacional preferido de Irlanda para el cumplimiento de NIS2. CyFun está basado en el NIST Cybersecurity Framework y proporciona a los consejos un enfoque estructurado y basado en riesgos para cumplir sus obligaciones legales sin requerir experiencia técnica profunda.

El documento cubre tres áreas prácticas: comprender qué preguntas deberían hacer los consejos sobre el riesgo cibernético, identificar y gestionar los riesgos de la cadena de suministro, y construir una cultura organizacional donde la ciberseguridad se trate como un tema de gobernanza, no como un problema del departamento de TI.

El momento es deliberado. Irlanda está actualmente sujeta a procedimientos de infracción de la UE por no transponer completamente NIS2 a la legislación nacional — la Comisión remitió al país al Tribunal de Justicia el 8 de julio de 2026. Publicar orientación a nivel de consejo directivo antes de la transposición formal señala que el NCSC está moviendo a las organizaciones hacia el cumplimiento independientemente de dónde se encuentre el proceso legislativo.

Fuente: Portal oficial del Gobierno de Irlanda, 2026

ENISA NIS360 2026: El sector espacial elevado a alta criticidad

El informe ENISA NIS360 2026 es la tercera evaluación anual de madurez y criticidad en ciberseguridad en todos los sectores del Anexo I bajo la Directiva NIS2. El hallazgo principal: el sector espacial se ha unido a la banca, la electricidad, la aviación y los servicios digitales por defecto en la banda de mayor criticidad.

La elevación refleja el creciente papel de la infraestructura espacial como capa de dependencia para otros sectores: la navegación, las comunicaciones, la liquidación financiera y la logística militar funcionan con sistemas satelitales. Mayor dependencia significa mayor impacto ante una interrupción y mayor criticidad temporal en la recuperación.

Siete sectores caen en la zona de riesgo de NIS360 2026, donde la madurez en ciberseguridad está por debajo del nivel que exige su criticidad:

1. Salud
2. Ferrocarril
3. Marítimo
4. Gestión de servicios TIC
5. Espacio
6. Administración pública
7. Agua potable y residual

Tres sectores alcanzaron la banda de alta madurez: servicios de confianza, aviación e infraestructuras del mercado financiero. El sector del gas ha comenzado a salir de la zona de riesgo, impulsado por una mejor compartición de información y una implementación más sólida de medidas de gestión de riesgos.

La composición de la zona de riesgo importa operativamente. Las autoridades de supervisión utilizan los datos de NIS360 para priorizar los calendarios de auditoría. Si su organización opera en salud, ferrocarril o administración pública, espere mayor atención supervisora en la segunda mitad de 2026.

El estudio ENISA NIS Investments 2025 encontró que el 70% de las organizaciones encuestadas citaron el cumplimiento de NIS2, DORA y CRA como el principal impulsor del gasto en ciberseguridad — una cifra que probablemente aumentará a medida que los supervisores pasen del registro a la revisión activa.

Fuente: ENISA, 2026

Alemania: La BSI entra en fase de supervisión activa

La BSI de Alemania entró en la fase de supervisión activa el 6 de marzo de 2026 — la fecha en que expiró el plazo de registro bajo la NIS2-Umsetzungsgesetz (NIS2UmsuCG). La ley se promulgó el 6 de diciembre de 2025. Para junio de 2026, había estado en vigor durante seis meses.

El análisis del 16 de junio de SecurityToday.de sobre el cambio de supervisión señaló que la pregunta ha cambiado: ya no se trata de si una entidad está registrada, sino de si las medidas declaradas resisten el escrutinio.

El portal de registro de la BSI abrió el 6 de enero de 2026. Una parte significativa de las aproximadamente 29.000 entidades dentro del ámbito no cumplió el plazo de marzo. La BSI estableció un plazo de registro secundario del 31 de julio de 2026. El registro tardío sigue siendo posible pero no crea ningún puerto seguro — las obligaciones de cumplimiento se aplican desde diciembre de 2025, independientemente del estado de registro.

Lo que significa la supervisión activa en la práctica:

• La BSI puede solicitar proactivamente evidencia de medidas de seguridad — sin esperar a que ocurra un incidente.
• Las auditorías presenciales y remotas están ahora dentro del ámbito.
• Las multas para entidades esenciales alcanzan hasta 10 millones de euros o el 2% de la facturación anual global, lo que sea mayor.
• Los miembros del órgano de dirección enfrentan responsabilidad personal, incluyendo posibles prohibiciones temporales para ejercer funciones de gestión.

La implementación de Alemania va más allá del mínimo de la UE en cuanto a responsabilidad ejecutiva. La NIS2UmsuCG requiere explícitamente que los órganos de dirección aprueben las medidas de ciberseguridad, supervisen su implementación y demuestren competencia personal. Los supervisores pueden responsabilizar personalmente a ejecutivos individuales por fallos sistémicos.

Hay una ventaja práctica en el estándar más estricto de Alemania. Las organizaciones que cumplen los requisitos de la NIS2UmsuCG satisfacen el mínimo de la UE con margen. Para las empresas que operan en múltiples Estados miembros, una postura de seguridad que pase el escrutinio de la BSI generalmente también se sostendrá ante las autoridades de supervisión vecinas.

Para los que se registran tarde, el orden de prioridades es claro: registrarse primero, luego establecer evidencia documentada de las medidas. Si ocurre un incidente notificable antes de que las medidas estén demostrablemente implementadas, un registro omitido o retrasado es un factor agravante.

Fuente: SecurityToday.de, 2026

Publicado el Plan de Acción de la UE sobre Ciberseguridad e IA

El 7 de julio de 2026, la Comisión Europea publicó el Plan de Acción de la UE sobre Ciberseguridad e Inteligencia Artificial. El documento establece un enfoque coordinado de la UE para la ciberseguridad impulsada por IA en los Estados miembros, autoridades públicas y empresas.

El plan se construye en torno a tres objetivos: promover el uso seguro y responsable de la IA avanzada, reforzar la ciberseguridad y la resiliencia de la UE, y ampliar las capacidades de IA de Europa para fines de ciberseguridad.

En cuanto a NIS2, el Plan de Acción nombra explícitamente la Directiva NIS2 como parte del marco legal existente sobre el que se construye, y alienta a las organizaciones sujetas a NIS2 a utilizar IA (incluyendo modelos de código abierto) para detectar y abordar vulnerabilidades más rápidamente. Este es el primer documento a nivel de la UE que vincula formalmente el cumplimiento de NIS2 con la detección de amenazas asistida por IA como práctica operativa esperada.

Las medidas concretas incluyen:

• Un Plan Europeo para el acceso seguro a sistemas de IA avanzados para fines de ciberseguridad, a desarrollar con ENISA.
• Una plataforma de pruebas segura para organizaciones en sectores críticos (energía, transporte, salud, finanzas y administración pública) para probar e implementar soluciones de IA de forma segura.
• Un Gran Desafío de la UE sobre IA para ciberseguridad, que reúne a la industria, investigadores y comunidades de código abierto.

El Plan de Acción se sitúa junto con la Ley de IA, la Ley de Ciberresiliencia, DORA y la Ley de Cibersolidaridad. No crea nuevas obligaciones vinculantes por sí solo, pero señala dónde espera la Comisión que se concentren el énfasis en la aplicación y la inversión durante el próximo ciclo legislativo.

Fuente: Comisión Europea, 2026

Reino Unido: El proyecto de ley de Ciberseguridad y Resiliencia es aprobado por los Comunes, ingresa a los Lores

El 16 de junio de 2026, el proyecto de ley de Ciberseguridad y Resiliencia (Sistemas de Redes e Información) completó su tercera lectura y etapa de informe en la Cámara de los Comunes. Recibió su primera lectura en los Lores el 17 de junio y está programado para una segunda lectura en los Lores el 14 de julio de 2026.

El proyecto de ley se presentó al Parlamento el 12 de noviembre de 2025 y actualiza los Reglamentos de Sistemas de Redes e Información de 2018 (NIS1) existentes. No transpone NIS2 (el Reino Unido ya no está vinculado por la legislación de la UE) pero acerca significativamente los requisitos del Reino Unido al estándar NIS2 en alcance y aplicación.

Lo que añade el proyecto de ley:

• Los proveedores de servicios gestionados entran en el ámbito por primera vez. Los Proveedores de Servicios Gestionados Relevantes (RMSP) deben registrarse ante el ICO, implementar medidas de gestión de riesgos y designar un representante en el Reino Unido si no están establecidos en el país.
• Los operadores de centros de datos también se incluyen en el ámbito.
• Los plazos de notificación de incidentes se acortan: informe inicial de 24 horas, notificación completa de 72 horas — coincidiendo con la estructura del Artículo 23 de NIS2.
• Designación de proveedores críticos: El ICO obtiene la facultad de designar proveedores cuyo compromiso afectaría a servicios esenciales o RMSP.
• Las sanciones aumentan hasta 17 millones de libras o el 4% de la facturación anual global por infracciones graves; hasta 10 millones de libras o el 2% por las menos graves.

La definición de incidente también se amplía: el proyecto de ley cubre incidentes «capaces de tener un efecto adverso» en los servicios regulados, no solo aquellos con un efecto real demostrado. Este es un cambio significativo para las organizaciones que actualmente calibran sus umbrales de notificación.

Se han propuesto 63 enmiendas durante el trámite del proyecto de ley. Dos enmiendas presentadas en junio, incluyendo una para añadir la cadena de suministro alimentario como servicio esencial regulado, no recibieron decisión en la etapa de informe.

El gobierno espera consultar en 2026 sobre la legislación secundaria que cubra medidas específicas de gestión de riesgos y requisitos de notificación. Algunas disposiciones entrarán en vigor desde el primer día o segundo mes después de la sanción real; otras seguirán mediante legislación secundaria.

Fuentes: Parlamento del Reino Unido, 2026; Parallel Parliament, 2026

Resumen

El período de junio a principios de julio de 2026 marca el punto en que la aplicación de NIS2 pasó de la presión política a la acción legal y de supervisión activa. Se presentaron remisiones judiciales. Las leyes nacionales están entrando en vigor. Las autoridades de supervisión están solicitando evidencia de medidas de seguridad, no solo confirmaciones de registro.

Para las organizaciones en Irlanda, España, Francia y los Países Bajos, los procedimientos de infracción no cambian nada sobre las obligaciones subyacentes. Los requisitos de NIS2 han sido vinculantes desde octubre de 2024 independientemente del estado de transposición nacional. Los procedimientos añaden consecuencias financieras para los gobiernos — no crean un período de gracia para las entidades reguladas.

Para las organizaciones en Alemania y los Países Bajos, el calendario de cumplimiento ya está establecido. La BSI está auditando. La Cyberbeveiligingswet entra en vigor el 15 de agosto. El documento de mapeo del Artículo 21 publicado por el Grupo de Cooperación NIS en junio de 2026 es el resultado más accionable de este período: si su equipo ya trabaja con ISO 27001 o NIST CSF 2.0, proporciona un camino directo para cerrar su análisis de brechas de NIS2 antes de que una autoridad de supervisión lo haga por usted.

Controles de acceso NIS2 para la seguridad de la cadena de suministro

El 48% de las brechas ahora involucran a terceros. El Artículo 21 de NIS2 convierte la gobernanza del acceso de proveedores en una obligación legal. Aquí se explica cómo mapear el acceso de proveedores, aplicar MFA y privilegio mínimo, y mantener la evidencia de auditoría que demuestra que sus controles funcionan.

Passwork BlogAlex Muntyan

Shadow IT vs Shadow AI: Por qué la IA es la mayor amenaza

Los empleados están usando herramientas de IA que usted no aprobó, en cuentas que no puede monitorear, con datos que no puede recuperar. Aquí se muestra cómo es realmente el riesgo y qué debe abordar la gobernanza.

Passwork BlogAlex Muntyan

Offboarding de empleados: Guía de revocación segura de accesos 2026

Desactivar una cuenta SSO no revoca el acceso. Las claves API, las credenciales de agentes de IA y las contraseñas compartidas sobreviven. Esta guía cubre el playbook completo de offboarding — desde disparadores de hora cero hasta limpieza de NHI.

Passwork BlogAlex Muntyan

The EU infringement machine moved from warnings to court referrals in July 2026. Ireland, Spain, France, and the Netherlands now face financial sanctions for missing the October 2024 NIS2 transposition deadline — daily penalties accruing until each country notifies complete transposition to the Commission.

At the same time, enforcement infrastructure is filling in. Germany's BSI is actively auditing registered entities. The Netherlands passed its national law one day before the referral landed. The NIS Cooperation Group published the most detailed Article 21 mapping document to date. And the Commission tied NIS2 explicitly to AI-assisted threat detection for the first time.

This article covers every material NIS2 development: what changed, which deadlines are live, and what your team needs to act on now. For the previous month's developments, see NIS2 latest news: May 2026.

Key takeaways

• Court referrals filed against four member states. On July 8, 2026, the European Commission referred Ireland, Spain, France, and the Netherlands to the Court of Justice of the EU for failing to fully transpose NIS2. Financial sanctions are requested for each country.
• Netherlands' Cyberbeveiligingswet enters force August 15, 2026. The Dutch Senate approved the law on July 7. More than 8,000 organizations must register with the NCSC, implement risk-based security measures, and ensure board-level oversight by that date.
• Germany's BSI is now auditing, not just registering. The active supervision phase began March 6, 2026. The BSI can request evidence of security measures without waiting for an incident. A secondary registration deadline of July 31 applies to the significant share of the 29,000 in-scope entities that missed March.
• The NIS Cooperation Group published its Article 21 mapping document. Released in June 2026, it maps NIS2 obligations and Implementing Regulation 2024/2690 to ISO 27001, NIST CSF 2.0, IEC 62443, and national frameworks — the most concrete EU-level compliance guidance published to date.
• Ireland's NCSC published board-level cyber governance guidance. Released July 7, 2026, the document targets CEOs, CIOs, and CISOs in NIS2-regulated organizations and is built around the NIST-based CyFun framework.
• ENISA elevated the space sector to high criticality. The NIS360 2026 report places space alongside banking, electricity, and aviation. Seven sectors remain in the risk zone, where maturity falls below criticality demands.
• The EU Action Plan on Cybersecurity and AI was published July 7, 2026. It is the first EU-level document to formally link NIS2 compliance with AI-assisted threat detection as an expected operational practice.
• The UK's Cyber Security and Resilience Bill passed the Commons on June 16. It entered the Lords on June 17 and is scheduled for a second reading on July 14. Managed service providers and data centre operators come into scope for the first time.

EU Commission takes Ireland, Spain, France, and the Netherlands to court over NIS2 delays

On July 8, 2026, the European Commission referred Ireland, Spain, France, and the Netherlands to the Court of Justice of the EU for failing to notify full transposition of the NIS2 Directive. The referrals include a request for financial sanctions: a lump sum plus daily penalties accruing until each country notifies complete transposition.

The transposition deadline was October 17, 2024. The Commission sent formal notices to non-compliant member states in November 2024 and reasoned opinions in May 2025. Court referral is the third and final stage of the EU infringement procedure.

The timing is notable for the Netherlands. The Dutch Senate approved the Cyberbeveiligingswet on July 7 — one day before the referral was filed (more on this below). The law enters into force on August 15, 2026, but formal notification of transposition to the Commission had not yet been submitted at the time of the referral. Daily penalties will stop accruing once notification is complete.

For Spain, France, and Ireland, no equivalent national law has passed. Spain's transposition is expected in late 2026. France and Ireland have not announced firm timelines.

The infringement cases carry individual case numbers:

• Ireland (INFR(2024)0279)
• Spain (INFR(2024)0270)
• France (INFR(2024)0274)
• Netherlands (INFR(2024)0288)

The referrals reinforce a point compliance teams in these countries should already know: the NIS2 Directive's requirements are binding regardless of national transposition status. Court proceedings do not suspend the underlying obligations — they add financial pressure on governments to close the gap faster.

Source: European Commision, 2026

Netherlands: Cyberbeveiligingswet approved, enters force August 15

On July 7, 2026, the Dutch Senate approved both the Cyberbeveiligingswet (the Dutch transposition of NIS2) and the Critical Entities Resilience Act (Wwke), which implements the EU's Critical Entities Resilience (CER) Directive. Both laws enter into force on August 15, 2026.

More than 8,000 organizations fall in scope: ministries, municipalities, water authorities, provinces, independent administrative bodies, and inter-municipal partnerships. From August 15, they must:

1. Register with the National Cyber Security Centre (NCSC) via the Entities Register.
2. Implement appropriate technical, operational, and organizational measures based on a risk assessment — including supply chain dependencies.
3. Report major cybersecurity incidents to the relevant CSIRT and competent supervisory authority within statutory deadlines.
4. Ensure board-level oversight: governing body members must have sufficient cybersecurity knowledge and complete appropriate training.

Enforcement sits with designated supervisory authorities, including the Dutch Authority for Digital Infrastructure. The Cyberbeveiligingswet introduces director liability: supervisors can issue binding instructions, conduct inspections, and suspend directors where necessary.

For public sector organizations, compliance with the Baseline Information Security Government (BIO) 2 standard counts toward meeting the Cbw's security requirements.

The August 15 entry-into-force date is a hard deadline. Registration with the NCSC should begin before that date — the NCSC itself recommends preparing in advance to avoid bottlenecks in the registration process.

Source: NL Digital Government, 2026

EU-wide: New security measures reference document released

Published on June, 2026, the NIS Cooperation Group's reference document on security measures gives organizations the most concrete EU-level guidance on NIS2 Article 21 compliance to date. The document establishes a common European framework for cybersecurity objectives and includes a mapping table that links NIS2 obligations and the European Implementing Regulation 2024/2690 to:

• ISO/IEC 27001
• IEC 62443
• NIST Cybersecurity Framework 2.0
• national cybersecurity frameworks
• the CyberFundamentals Framework, CyFun®

The document is non-binding. It does not replace national NIS2 legislation or sector-specific guidelines. But for compliance teams already working against ISO 27001 or NIST CSF 2.0, it answers a question that has been open since the directive passed: how exactly do my existing controls map to NIS2 requirements?

The mapping is particularly useful for organizations operating across multiple member states. Rather than maintaining separate gap analyses per jurisdiction, teams can use the reference document as a shared baseline and then layer national deviations on top.

Access control, authentication, and privileged access management appear explicitly in the mapped objectives — areas where the reference document's guidance aligns directly with NIS2 Article 21(2)(j) on the use of multi-factor authentication and secure communication systems.

Sources: Center for Cybersecurity Belgium, 2026; European Commission, 2026

Ireland: NCSC publishes board-level cyber governance guidance for NIS2 entities

On July 7, 2026, Ireland's National Cyber Security Centre published guidance on cyber governance for management board members in NIS2-regulated organizations. The document targets CEOs, Managing Directors, CIOs, and CISOs — the executives who bear personal accountability for cybersecurity risk management under NIS2.

The guidance centers on the Cyber Fundamentals Framework (CyFun), Ireland's preferred national framework for NIS2 compliance. CyFun is built on the NIST Cybersecurity Framework and gives boards a structured, risk-based approach to meeting their legal obligations without requiring deep technical expertise.

The document covers three practical areas: understanding what questions boards should be asking about cyber risk, identifying and managing supply chain risks, and building an organizational culture where cybersecurity is treated as a governance issue, not an IT department problem.

The timing is deliberate. Ireland is currently subject to EU infringement proceedings for failing to fully transpose NIS2 into national law — the Commission referred the country to the Court of Justice on July 8, 2026. Publishing board-level guidance ahead of formal transposition signals that the NCSC is moving organizations toward compliance regardless of where the legislative process stands.

Source: The Irish Government's official portal, 2026

ENISA NIS360 2026: Space sector elevated to high criticality

The ENISA NIS360 2026 report is the third annual assessment of cybersecurity maturity and criticality across all Annex I sectors under the NIS2 Directive. The headline finding: the space sector has joined banking, electricity, aviation, and digital-by-default services in the highest criticality band.

The elevation reflects space infrastructure's growing role as a dependency layer for other sectors: navigation, communications, financial settlement, and military logistics all run on satellite systems. Higher dependency means higher impact from disruption, and higher time criticality in recovery.

Seven sectors fall into the NIS360 2026 risk zone, where cybersecurity maturity falls below the level their criticality demands:

1. Health
2. Railway
3. Maritime
4. ICT service management
5. Space
6. Public administration
7. Drinking and waste water

Three sectors reached the high maturity band: trust services, aviation, and financial market infrastructures. The gas sector has begun moving out of the risk zone, driven by improved information sharing and stronger implementation of risk management measures.

The risk zone composition matters operationally. Supervisory authorities use NIS360 data to prioritize audit calendars. If your organization operates in health, railway, or public administration, expect increased supervisory attention in the second half of 2026.

ENISA NIS Investments 2025 study found that 70% of surveyed organizations cited NIS2, DORA, and CRA compliance as the main driver of cybersecurity spending — a figure that will likely climb as supervisors shift from registration to active review.

Source: ENISA, 2026

Germany: BSI enters active supervision phase

Germany's BSI entered the active supervision phase on March 6, 2026 — the date the registration deadline under the NIS2-Umsetzungsgesetz (NIS2UmsuCG) expired. The law was enacted on December 6, 2025. By June 2026, it had been in force for six months.

SecurityToday.de's June 16 analysis of the supervisory shift noted that the question has changed: no longer whether an entity is registered, but whether its reported measures hold up under scrutiny.

The BSI registration portal opened January 6, 2026. A significant share of the approximately 29,000 in-scope entities missed the March deadline. The BSI set a secondary registration deadline of July 31, 2026. Late registration remains possible but creates no safe harbor — the compliance obligations have applied since December 2025, regardless of registration status.

What active supervision means in practice:

• The BSI can proactively request evidence of security measures — without waiting for an incident.
• On-site and remote audits are now within scope.
• Fines for essential entities reach up to €10 million or 2% of global annual turnover, whichever is higher.
• Management body members face personal liability, including potential temporary bans from exercising management functions.

Germany's implementation goes beyond the EU minimum on executive accountability. The NIS2UmsuCG explicitly requires management bodies to approve cybersecurity measures, supervise their implementation, and demonstrate personal competence. Supervisors can hold individual executives personally responsible for systemic failures.

There is a practical upside to Germany's stricter standard. Organizations that meet the NIS2UmsuCG requirements satisfy the EU minimum with margin. For companies operating across multiple member states, a security posture that passes BSI scrutiny will generally hold up with neighboring supervisory authorities as well.

For late registrants, the priority order is clear: register first, then establish documented evidence of measures. If a reportable incident occurs before measures are demonstrably in place, a missed or delayed registration is an aggravating factor.

Source: SecurityToday.de, 2026

EU Action Plan on Cybersecurity and AI published

On July 7, 2026, the European Commission published the EU Action Plan on Cybersecurity and Artificial Intelligence. The document sets out a coordinated EU approach to AI-driven cybersecurity across member states, public authorities, and businesses.

The plan is built around three objectives: promoting safe and responsible use of advanced AI, reinforcing EU cybersecurity and resilience, and scaling up Europe's AI capabilities for cybersecurity purposes.

On the NIS2 side, the Action Plan explicitly names the NIS2 Directive as part of the existing legal framework it builds on, and encourages organizations subject to NIS2 to use AI (including open-source models) to detect and address vulnerabilities faster. This is the first EU-level document to formally link NIS2 compliance with AI-assisted threat detection as an expected operational practice.

Concrete measures include:

• A European Blueprint for secure access to advanced AI systems for cybersecurity purposes, to be developed with ENISA.
• A secure testing platform for organizations in critical sectors (energy, transport, health, finance, and public administration) to safely test and deploy AI solutions.
• An EU Grand Challenge on AI for cybersecurity, bringing together industry, researchers, and open-source communities.

The Action Plan sits alongside the AI Act, the Cyber Resilience Act, DORA, and the Cyber Solidarity Act. It does not create new binding obligations on its own, but it signals where the Commission expects enforcement emphasis and investment to go over the next legislative cycle.

Source: European Commision, 2026

UK: Cyber Security and Resilience Bill passes Commons, enters Lords

On June 16, 2026, the Cyber Security and Resilience (Network and Information Systems) Bill completed its third reading and report stage in the House of Commons. It received its first reading in the Lords on June 17 and is scheduled for a Lords second reading on July 14, 2026.

The Bill was introduced to Parliament on November 12, 2025, and updates the existing Network and Information Systems Regulations 2018 (NIS1). It does not transpose NIS2 (the UK is no longer bound by EU law) but it moves UK requirements significantly closer to the NIS2 standard in scope and enforcement.

What the Bill adds:

• Managed service providers come into scope for the first time. Relevant Managed Service Providers (RMSPs) must register with the ICO, implement risk management measures, and nominate a UK representative if not established in the UK.
• Data centre operators are also brought into scope.
• Incident reporting timelines tighten: 24-hour initial report, 72-hour full notification — matching NIS2's Article 23 structure.
• Critical supplier designation: The ICO gains power to designate suppliers whose compromise would affect essential services or RMSPs.
• Penalties increase to up to £17 million or 4% of global annual turnover for serious breaches; up to £10 million or 2% for less serious ones.

The incident definition is also broadened: the Bill covers incidents "capable of having an adverse effect" on regulated services, not just those with a demonstrated actual effect. This is a meaningful change for organizations currently calibrating their reporting thresholds.

63 amendments have been proposed during the Bill's passage. Two amendments tabled in June, including one to add the food supply chain as a regulated essential service, received no decision at report stage.

The government expects to consult in 2026 on secondary legislation covering specific risk management measures and notification requirements. Some provisions will take effect from the first day or second month after Royal Assent; others will follow via secondary legislation.

Sources: UK Parliament, 2026; Parallel Parliament, 2026

Recap

The period from June to early July 2026 marks the point where NIS2 enforcement moved from political pressure to active legal and supervisory action. Court referrals are filed. National laws are entering force. Supervisory authorities are requesting evidence of security measures, not just registration confirmations.

For organizations in Ireland, Spain, France, and the Netherlands, the infringement proceedings change nothing about the underlying obligations. NIS2 requirements have been binding since October 2024 regardless of national transposition status. The proceedings add financial consequences for governments — they do not create a grace period for regulated entities.

For organizations in Germany and the Netherlands, the compliance calendar is now set. The BSI is auditing. The Cyberbeveiligingswet enters force August 15. The Article 21 mapping document published by the NIS Cooperation Group in June 2026 is the most actionable output from this period: if your team is already working against ISO 27001 or NIST CSF 2.0, it provides a direct path to closing your NIS2 gap analysis before a supervisory authority does it on your behalf.

NIS2 access controls for supply chain security

48% of breaches now involve third parties. NIS2 Article 21 makes supplier access governance a legal obligation. Here’s how to map vendor access, enforce MFA and least privilege, and keep the audit evidence that proves your controls work.

Passwork BlogAlex Muntyan

Shadow IT vs Shadow AI: Why AI is the bigger threat

Employees are using AI tools you didn’t approve, on accounts you can’t monitor, with data you can’t recover. Here’s what the risk actually looks like and what governance needs to address.

Passwork BlogAlex Muntyan

Employee offboarding: Secure access revocation guide 2026

Disabling an SSO account doesn’t revoke access. API keys, AI agent credentials, and shared passwords survive it. This guide covers the full offboarding playbook — from zero-hour triggers to NHI cleanup.

Passwork BlogAlex Muntyan

Para implementar os controlos de acesso da NIS2 na segurança da cadeia de abastecimento, é necessário mapear cada fornecedor direto e prestador de serviços para os sistemas, contas, privilégios, métodos de autenticação e registos de evidências que utiliza. Em seguida, devem aplicar-se o princípio do menor privilégio, a autenticação multifator (MFA) ou a autenticação contínua, sempre que adequado, controlos de contas privilegiadas, cláusulas contratuais, monitorização e revisões de acesso periódicas.

A segurança da cadeia de abastecimento da NIS2 não é um exercício de aquisições. Implica traduzir cada relação com fornecedores em controlos aplicáveis sobre contas, credenciais partilhadas, vias de acesso remoto, ações privilegiadas e logs.

De acordo com o relatório de 2025 da Verizon (Data Breach Investigations Report), o envolvimento de terceiros surgiu em 30 % das violações de dados analisadas. O DBIR de 2026 mostra a aceleração desta tendência: o envolvimento de terceiros surge agora em 48 % das violações de dados confirmadas, um aumento de 60 % face ao ano anterior. Nesta trajetória, a governação do acesso de fornecedores deixa de ser um risco de primeiro nível que se possa adiar.

O argumento financeiro é igualmente expressivo. IBM, no relatório Cost of a Data Breach Report 2025, situa o custo médio de um comprometimento da cadeia de abastecimento em 4,91 milhões de dólares, e estas violações demoram, no conjunto, 267 dias a identificar e a conter. O artigo 21.º da NIS2 e o Regulamento de Execução (UE) 2024/2690 fazem disto um mandato de gestão de identidades e acessos (IAM), e não uma questão de gestão de fornecedores.

A organização é responsável, do ponto de vista regulamentar, por cada via de acesso concedida a uma entidade externa.

Pontos principais

• A segurança da cadeia de abastecimento da NIS2 é um mandato de IAM, e não uma questão de gestão de fornecedores. O artigo 21.º, n.º 2, alínea d), torna a organização juridicamente responsável por cada via de acesso concedida a uma entidade externa, incluindo VPN, APIs, consolas de administração SaaS, pipelines CI/CD e ferramentas de suporte remoto.
• Os incidentes com origem em terceiros estão a acelerar. O DBIR 2026 da Verizon situa o envolvimento de terceiros em 48 % das violações de dados confirmadas, contra 30 % no ano anterior.
• As orientações de 2025 da ENISA exigem MFA de nível 1 para todo o acesso privilegiado de fornecedores. FIDO2 e WebAuthn são os únicos métodos aceitáveis para contas de fornecedores com acesso administrativo ou a sistemas de produção. O SMS OTP está sinalizado para abandono progressivo.
• As contas partilhadas de fornecedores são uma lacuna de conformidade. Contas nominais individuais, RBAC com menor privilégio e acesso privilegiado just-in-time são a base de referência, e não um reforço opcional.
• Os logs de auditoria são a evidência, não o plano de contingência. O prazo de 24 horas para o alerta precoce previsto no artigo 23.º não pode ser cumprido sem logs imutáveis que mostrem exatamente o que uma conta de fornecedor fez e quando.
• A revogação de acessos deve ser automática e associada aos eventos do ciclo de vida do contrato. Os pedidos manuais de desprovisionamento são demasiado lentos. Quando o contrato de um fornecedor termina, o acesso termina com ele.
• O registo de controlo de acesso de fornecedores é a unidade de responsabilização. Um registo por relação com fornecedor (via de acesso, tipo de identidade, nível de MFA, evidências), atualizado em cada ciclo de revisão.

O que a NIS2 exige dos controlos de acesso de fornecedores

Artigo 21.º da NIS2 exige que as entidades essenciais e importantes adotem medidas técnicas, operacionais e organizacionais adequadas e proporcionadas para gerir os riscos de cibersegurança. O artigo 21.º, n.º 2, enumera dez medidas mínimas. Cinco incidem diretamente na governação do acesso de fornecedores.

A diretiva não impõe uma ferramenta única nem um método de MFA universal. Exige medidas adequadas e proporcionadas ao risco. No caso do acesso de fornecedores, isso significa identificar que utilizadores externos, contas de suporte, APIs e integrações podem chegar aos ativos críticos da organização, e aplicar depois controlos adequados à sensibilidade do que essas vias expõem.

O artigo 21.º, n.º 3, vai mais longe: as entidades devem ter em conta as vulnerabilidades específicas de cada fornecedor direto e prestador de serviços, bem como a qualidade global das suas práticas de cibersegurança. Isto faz da governação de identidades e acessos de fornecedores uma obrigação legal direta, e não uma recomendação de boas práticas.

O Regulamento de Execução (UE) 2024/2690 traduz os requisitos de alto nível do artigo 21.º em mais de 150 controlos de cibersegurança específicos. Para as relações com fornecedores, estabelece expectativas concretas em matéria de atribuição de acessos, gestão de contas privilegiadas e notificação de incidentes, deslocando a questão de conformidade de «existe uma política?» para «é possível provar que os controlos funcionam?»

ENISA, nas orientações técnicas de implementação de 2025, considera a política de segurança da cadeia de abastecimento, a política de controlo de acessos e as políticas de contas privilegiadas como políticas temáticas obrigatórias no quadro da NIS2.

Os 5 controlos de acesso essenciais para a conformidade da NIS2 na cadeia de abastecimento

Se um fornecedor tem acesso remoto ou privilegiado, a segurança da cadeia de abastecimento da NIS2 passa a ser um problema de controlo de identidades. A relação com o fornecedor cria uma via direta para as redes e os sistemas de informação da organização.

Aplicar um controlo de acesso baseado em funções (RBAC) rigoroso

Eliminar as contas partilhadas de fornecedores. Cada engenheiro do fornecedor que necessite de acesso a sistemas recebe uma conta nominal e individual, associada ao respetivo projeto. As contas genéricas de «fornecedor» impossibilitam a atribuição de responsabilidades durante um incidente, e essa atribuição é exatamente o que exige o requisito de alerta precoce em 24 horas do artigo 23.º.

Aplicar o princípio do menor privilégio ao nível das funções: os fornecedores recebem o acesso mínimo necessário para executar as tarefas contratadas, limitado a ativos específicos e não a segmentos amplos do sistema. Quando o âmbito do projeto muda, as permissões mudam com ele.

Implementar MFA de nível 1 para o acesso privilegiado

As orientações técnicas de 2025 da ENISA classificam a MFA em três níveis. Para qualquer fornecedor com acesso administrativo ou privilegiado, o nível 1 é a única opção aceitável.

A implicação prática: se os engenheiros de suporte de um MSP se autenticam por SMS para aceder a sistemas de produção, existe uma lacuna de conformidade face às orientações atuais da ENISA. Os métodos de nível 1 são resistentes a phishing porque a credencial criptográfica está associada ao domínio específico, e um site de phishing não a consegue intercetar.

Implementar a gestão de acessos privilegiados (PAM) e o armazenamento de credenciais em cofre

O acesso just-in-time (JIT) é o modelo adequado para equipas de suporte de terceiros. Os privilégios elevados são concedidos para uma sessão definida, registados na íntegra e revogados automaticamente quando a sessão termina. Sem acesso permanente e sem contas privilegiadas persistentes que se acumulam ao longo de anos de relações com fornecedores.

Para as credenciais partilhadas que não podem ser eliminadas (contas break-glass de emergência, contas de serviço de sistemas legados, chaves de API partilhadas), deve utilizar-se um cofre de credenciais com permissões baseadas em funções e um registo de auditoria completo. Um gestor de palavras-passe empresarial pode centralizar as credenciais partilhadas de fornecedores, restringir o acesso por função e conservar os registos que um auditor irá solicitar.

Black Kite, no 2026 Supply Chain Vulnerability Report, concluiu que os atacantes exploram vulnerabilidades, em média, sete dias antes da divulgação pública, a partir da análise de mais de 48 000 CVE publicados em 2025. As credenciais de fornecedores de longa duração que permanecem em pipelines CI/CD ou em contas de integração são um convite permanente. Os tokens de API devem ser rodados segundo um calendário definido e revogados imediatamente quando a relação com o fornecedor termina.

Manter logs de auditoria imutáveis

O artigo 23.º estabelece prazos rigorosos de notificação de incidentes: um alerta precoce em 24 horas, uma notificação formal em 72 horas e um relatório final completo no prazo de um mês. Cumprir esses prazos sem logs de auditoria imutáveis não é realista. Os logs são a evidência: mostram exatamente o que uma conta de fornecedor fez, quando e a partir de onde.

Os logs devem ser resistentes a adulteração e conservados durante o tempo suficiente para apoiar tanto investigações internas como pedidos das autoridades de supervisão. No caso das contas de fornecedores, devem registar-se eventos de autenticação, escalonamentos de privilégios, atividade de sessão, alterações de configuração e acessos a dados sensíveis. Quando ocorre um incidente, a pergunta «a que teve acesso esta conta de fornecedor?» exige resposta em horas, e não em semanas.

Automatizar a revogação de credenciais

Associe o acesso dos fornecedores diretamente aos eventos do ciclo de vida do contrato. Quando um contrato com um fornecedor expira, é rescindido ou quando um engenheiro com conta nominal deixa a equipa do fornecedor, a revogação do acesso deve ser imediata e automática, sem depender de um pedido manual que alguém se lembre de registar.

Elaborar um registo de controlo de acesso de fornecedores

Um registo de controlo de acesso de fornecedores é o registo operacional que associa uma relação com um fornecedor a direitos de acesso específicos e às evidências de que esses direitos estão controlados. Um registo por relação com fornecedor. Esta é a unidade de responsabilização.

O registo responde às perguntas que um auditor, um regulador ou a própria equipa de resposta a incidentes irá colocar: quem tem acesso, a quê, por que via, com que autenticação e quem deu aprovação?

As orientações de 2025 da ENISA preveem que a política de segurança da cadeia de abastecimento rege as relações com fornecedores diretos e prestadores de serviços e identifica as funções dos fornecedores: fornecedor de TIC, prestador de serviços geridos (MSP), prestador de serviços de segurança geridos (MSSP) e fornecedor de cloud.

Os registos devem refletir estas distinções. O perfil de risco de um MSP com acesso privilegiado à infraestrutura difere significativamente do de um fornecedor SaaS com acesso de API só de leitura, e os controlos devem diferir em conformidade.

Como auditar o acesso atual de fornecedores

Deve começar-se por um mapeamento completo dos fornecedores. Listar todas as ligações externas: VPN, APIs, consolas de administração SaaS, ferramentas de suporte remoto, integrações CI/CD e acesso a repositórios. Para cada ligação, identificar o tipo de identidade, o método de autenticação, o nível de privilégio e o responsável interno pela relação.

Em seguida, deve percorrer-se esta lista de verificação prévia à auditoria do acesso de fornecedores (7 pontos):

1. Todas as contas de fornecedores são nominais, sem credenciais genéricas partilhadas em uso para acesso privilegiado
2. O nível de MFA corresponde à sensibilidade do acesso: nível 1 para acesso privilegiado, nível 2 no mínimo para acesso padrão
3. Todas as contas de fornecedores são provisionadas através de controlos de diretório, com desprovisionamento automatizado
4. Os contratos com fornecedores incluem requisitos de contas nominais, obrigações de MFA, notificação de violações em 24 horas, direitos de auditoria e divulgação de subcontratantes
5. A PAM ou o registo de sessões abrange todas as sessões privilegiadas de fornecedores
6. Os tokens de API e as credenciais de contas de serviço têm calendários de rotação definidos
7. A cadência das revisões de acesso está documentada: trimestral para fornecedores críticos, anual para todos os outros e imediata após qualquer cessação ou incidente

Atualizar os contratos com fornecedores para incluir cláusulas explícitas de notificação de violações em 24 horas e direitos de auditoria, caso ainda não existam. As orientações de 2025 da ENISA indicam que os contratos ou SLAs devem abranger requisitos de cibersegurança, obrigações de notificação de incidentes, tratamento de vulnerabilidades, requisitos de subcontratação e obrigações de cessação.

O custo da não conformidade: coimas e responsabilidade pessoal

As entidades essenciais estão sujeitas a coimas máximas de até 10 milhões de euros ou 2 % do volume de negócios anual a nível mundial ao abrigo da NIS2, consoante o valor que for mais elevado. As entidades importantes estão sujeitas a coimas até 7 milhões de euros ou 1,4 % do volume de negócios. Trata-se de máximos administrativos (as autoridades aplicam o princípio da proporcionalidade), mas são o limite que a administração tem de compreender.

O artigo 20.º vai mais longe. Estabelece a responsabilização pessoal dos dirigentes de topo e dos órgãos de gestão. Os dirigentes podem ser objeto de proibições temporárias do exercício de funções de gestão se a respetiva organização for considerada gravemente negligente nas suas obrigações de cibersegurança. A obrigação de aprovar as medidas de gestão de riscos de cibersegurança e de supervisionar a sua implementação cabe à gestão, e não apenas à equipa de TI.

A ligação ao acesso de fornecedores é direta. Se uma violação de dados tiver origem numa conta de fornecedor não controlada (sem MFA, sem registo de sessões, sem desprovisionamento após o fim do contrato) e a gestão não puder apresentar evidências de que existiam controlos e de que foram revistos, é esse o cenário para o qual o artigo 20.º foi concebido.

Incluir requisitos de acesso nos contratos e nas revisões de fornecedores

Os controlos de acesso falham quando os contratos com fornecedores não definem responsabilidades. As orientações da ENISA devem ser traduzidas em cláusulas contratuais concretas:

• Os fornecedores têm de utilizar contas nominais e aplicar MFA de nível 1 no acesso privilegiado ou remoto
• A partilha de credenciais é proibida
• Os fornecedores têm de notificar o cliente de incidentes sem demora injustificada e, o mais tardar, no prazo de 24 horas em caso de incidentes significativos
• Os subcontratantes que necessitem de acesso têm de ser divulgados e sujeitos a controlos equivalentes
• Os fornecedores têm de assegurar a conservação de logs e dar resposta a pedidos de auditoria
• As informações têm de ser devolvidas ou eliminadas no termo do contrato

As revisões de acesso devem seguir uma cadência definida: no mínimo anual para todos os fornecedores, trimestral para fornecedores com acesso privilegiado ou a sistemas de produção, e imediata após um incidente, uma alteração contratual, uma alteração de funções ou uma cessação.

Conservar as evidências de auditoria para a conformidade com a NIS2

As evidências de auditoria são o que distingue um controlo documentado de uma simples afirmação. Numa auditoria interna, numa revisão de cliente ou num pedido de supervisão, é necessário apresentar registos, e não descrições do que se pretendia fazer.

As evidências úteis incluem: registo de fornecedores, matriz de controlo de acessos, pedidos de acesso aprovados, relatórios de adesão à MFA, logs de aprovação PAM, permissões do cofre de palavras-passe, registos de rotação de tokens de API, validações de revisões de acesso, cláusulas dos contratos com fornecedores, registos de notificação de incidentes, pedidos de correção de vulnerabilidades e registos de desprovisionamento.

A aceitação de risco do acesso privilegiado de fornecedores deve ter um responsável designado. Essa aceitação, e os controlos existentes, devem ser visíveis para a gestão através de relatórios periódicos, e não enterrados numa folha de cálculo que só a equipa de TI consegue encontrar.

10 passos para a conformidade do acesso de fornecedores com a NIS2

Mapear o acesso de fornecedores, aplicar controlos, contratualizar as obrigações, monitorizar continuamente e conservar evidências. A tabela seguinte consolida todos os passos de implementação numa única referência e deve ser utilizada como lista de verificação de trabalho, não como um exercício pontual.

O registo de controlo de acesso de fornecedores liga as linhas 1 a 10: um documento por relação, atualizado em cada ciclo de revisão e visível para a gestão.

Se a equipa gere palavras-passe partilhadas de fornecedores ou credenciais privilegiadas de fornecedores, um software de partilha de palavras-passe para empresas como o Passwork pode ajudar a organizar acessos, permissões e evidências de auditoria num único ambiente controlado. Constitui um componente de um programa de controlo de acessos mais amplo, e não um substituto do trabalho de governação descrito acima.

Perguntas frequentes

A NIS2 exige MFA para todo o acesso de fornecedores?

O artigo 21.º, n.º 2, alínea j), da NIS2 refere-se à MFA ou a soluções de autenticação contínua «sempre que adequado», pelo que se aplica uma abordagem baseada no risco. As orientações de 2025 da ENISA exigem MFA de nível 1 resistente a phishing (FIDO2, WebAuthn) para todo o acesso privilegiado e administrativo. Os métodos de nível 2 são aceitáveis para contas padrão sem privilégios elevados. O SMS OTP e o OTP por e-mail estão sinalizados para abandono progressivo em ambientes regulados.

O que é o Regulamento de Execução (UE) 2024/2690?

O Regulamento de Execução 2024/2690 traduz os requisitos gerais do artigo 21.º da NIS2 em mais de 150 controlos de cibersegurança específicos. No que respeita à segurança da cadeia de abastecimento, estabelece expectativas concretas em matéria de atribuição de acessos a fornecedores, gestão de contas privilegiadas e notificação de incidentes. Aplica-se diretamente a fornecedores de DNS, serviços cloud, prestadores de serviços geridos e outros tipos de entidades designadas.

A NIS2 aplica-se a subcontratantes e a fourth parties?

O artigo 21.º, n.º 2, alínea d), centra-se nas relações com fornecedores diretos e prestadores de serviços. Os contratos devem exigir a divulgação de subcontratantes e a transmissão dos requisitos de cibersegurança sempre que o acesso do fornecedor ou a continuidade do serviço dependa de um subcontratante. As orientações de 2025 da ENISA apoiam esta abordagem através das suas recomendações sobre requisitos de subcontratação nos SLAs de fornecedores.

Que evidências comprovam que os controlos de acesso de fornecedores funcionam?

As evidências úteis incluem registos de acesso de fornecedores, registos de adesão à MFA e logs de início de sessão, aprovações de sessões PAM, cláusulas contratuais que especificam requisitos de acesso, validações de revisões de acesso com data, pedidos de desprovisionamento e registos de notificação de incidentes. A combinação demonstra que os controlos existem, são aplicados e são revistos segundo um calendário definido.

Com que frequência deve o acesso de fornecedores ser revisto?

Todo o acesso de fornecedores deve ser revisto, no mínimo, anualmente. Para fornecedores com acesso privilegiado ou a sistemas de produção, as revisões trimestrais são mais adequadas. Deve desencadear-se uma revisão imediata fora do ciclo após qualquer incidente, alteração contratual, alteração de pessoal do lado do fornecedor ou cessação do contrato.

O que é um registo de controlo de acesso de fornecedores?

Um registo de controlo de acesso de fornecedores é um documento por relação que associa um fornecedor às contas específicas, vias de acesso, tipos de identidade, controlos de autenticação e registos de evidências associados a essa relação. É a unidade operacional para provar que o risco da cadeia de abastecimento foi convertido em governação de acessos aplicável ao abrigo do artigo 21.º da NIS2.

Últimas notícias sobre a NIS2: atualizações de aplicação em maio de 2026

Fase plena de sanções na Bulgária, nova lei do Luxemburgo, Cyberbeveiligingswet dos Países Baixos, ENISA NIS360 2026: novidades sobre a aplicação da NIS2 em maio de 2026.

Passwork BlogAlex Muntyan

Guia de conformidade NIS2: o roteiro de gestão de acessos para 2026

As credenciais roubadas dominam as violações de dados em 2026. O artigo 21.º da NIS2 impõe 10 medidas de segurança para eliminar os vetores de ataque baseados em credenciais. Este guia aborda os requisitos técnicos, a obrigação de notificação de incidentes em 24 horas, os níveis de MFA da ENISA e um roteiro em 5 fases até à conformidade pronta para auditoria.

Passwork BlogAlex Muntyan

Saída de colaboradores: guia de revogação segura de acessos 2026

Desativar uma conta SSO não revoga o acesso. As chaves de API, as credenciais de agentes de IA e as palavras-passe partilhadas subsistem. Este guia cobre o plano completo de saída de colaboradores, dos gatilhos de hora zero à limpeza de identidades não humanas (NHI).

Passwork BlogAlex Muntyan

Um NIS2-Zugriffskontrollen für die Lieferkettensicherheit zu implementieren, ordnen Sie jeden direkten Lieferanten und Dienstleister den Systemen, Accounts, Berechtigungen, Authentifizierungsmethoden und Nachweisdokumenten zu, die diese nutzen. Setzen Sie dann das Least-Privilege-Prinzip durch, MFA oder kontinuierliche Authentifizierung wo angemessen, Kontrollen für privilegierte Accounts, Vertragsklauseln, Monitoring und regelmäßige Zugriffsüberprüfungen.

NIS2-Lieferkettensicherheit ist keine Beschaffungsübung. Sie bedeutet, jede Lieferantenbeziehung in durchsetzbare Kontrollen über Accounts, gemeinsam genutzte Zugangsdaten, Remote-Zugriffspfade, privilegierte Aktionen und Protokolle zu übersetzen.

Laut Verizons Data Breach Investigations Report 2025 waren Drittparteien an 30 % der analysierten Sicherheitsverletzungen beteiligt. Der DBIR 2026 zeigt eine Beschleunigung des Trends: Die Beteiligung von Drittparteien erscheint nun bei 48 % der bestätigten Sicherheitsverletzungen — ein Anstieg von 60 % im Jahresvergleich. Bei dieser Entwicklung ist die Steuerung von Lieferantenzugriffen kein erstrangiges Risiko mehr, das Sie aufschieben können.

Die finanziellen Auswirkungen sind ebenso deutlich. IBMs Cost of a Data Breach Report 2025 beziffert die durchschnittlichen Kosten einer Lieferkettenkompromittierung auf 4,91 Millionen US-Dollar — und diese Sicherheitsverletzungen benötigen insgesamt 267 Tage zur Identifizierung und Eindämmung. NIS2 Artikel 21 und die Durchführungsverordnung (EU) 2024/2690 machen dies zu einem IAM-Mandat, nicht zu einer Frage des Lieferantenmanagements.

Ihre Organisation trägt die regulatorische Verantwortung für jeden Zugriffspfad, den Sie einer externen Partei gewähren.

Die wichtigsten Erkenntnisse

• NIS2-Lieferkettensicherheit ist ein IAM-Mandat, keine Frage des Lieferantenmanagements. Artikel 21(2)(d) macht Ihre Organisation rechtlich verantwortlich für jeden Zugriffspfad, der einer externen Partei gewährt wird — einschließlich VPNs, APIs, SaaS-Adminkonsolen, CI/CD-Pipelines und Remote-Support-Tools.
• Sicherheitsverletzungen durch Drittparteien nehmen zu. Verizons DBIR 2026 beziffert die Beteiligung von Drittparteien auf 48 % der bestätigten Sicherheitsverletzungen — gegenüber 30 % im Vorjahr.
• ENISAs Leitfaden von 2025 schreibt Tier-1-MFA für alle privilegierten Lieferantenzugriffe vor. FIDO2 und WebAuthn sind die einzigen akzeptablen Methoden für Lieferantenaccounts mit administrativem oder Produktionssystemzugriff. SMS-OTP ist zur Abschaffung vorgesehen.
• Gemeinsam genutzte Lieferantenaccounts sind eine Compliance-Lücke. Namentlich zugeordnete individuelle Accounts, Least-Privilege-RBAC und Just-in-Time-privilegierter Zugriff sind die Mindestanforderung — keine optionale Härtung.
• Audit-Protokolle sind der Nachweis, nicht der Notfallplan. Die 24-Stunden-Frühwarnfrist nach Artikel 23 kann ohne unveränderliche Protokolle nicht eingehalten werden, die genau zeigen, was ein Lieferantenaccount wann getan hat.
• Der Zugriffsentzug muss automatisch erfolgen und an Vertragslebenszyklus-Ereignisse gekoppelt sein. Manuelle Deprovisionierungs-Tickets sind zu langsam. Wenn ein Lieferantenvertrag endet, endet damit auch der Zugriff.
• Der Supplier Access Control Record ist die Einheit der Verantwortlichkeit. Ein Eintrag pro Lieferantenbeziehung — Zugriffspfad, Identitätstyp, MFA-Tier, Nachweis — aktualisiert bei jedem Überprüfungszyklus.

Was NIS2 von Lieferantenzugriffskontrollen verlangt

NIS2 Artikel 21 verlangt von wesentlichen und wichtigen Einrichtungen, angemessene und verhältnismäßige technische, operative und organisatorische Maßnahmen zur Bewältigung von Cybersicherheitsrisiken zu ergreifen. Artikel 21(2) listet zehn Mindestmaßnahmen auf. Fünf davon betreffen direkt die Steuerung von Lieferantenzugriffen.

Die Richtlinie schreibt kein einzelnes Tool oder eine universelle MFA-Methode vor. Sie verlangt Maßnahmen, die dem Risiko angemessen und verhältnismäßig sind. Für Lieferantenzugriff bedeutet das, zu identifizieren, welche externen Benutzer, Support-Accounts, APIs und Integrationen Ihre kritischen Assets erreichen können — und dann Kontrollen anzuwenden, die der Sensibilität dessen entsprechen, was diese Pfade offenlegen.

Artikel 21(3) geht weiter: Einrichtungen müssen Schwachstellen berücksichtigen, die spezifisch für jeden direkten Lieferanten und Diensteanbieter sind, sowie die Gesamtqualität ihrer Cybersicherheitspraktiken. Das macht die Steuerung von Lieferantenidentitäten und -zugriffen zu einer direkten rechtlichen Verpflichtung, nicht zu einer Best-Practice-Empfehlung.

Die Durchführungsverordnung (EU) 2024/2690 übersetzt die übergeordneten Anforderungen von Artikel 21 in über 150 spezifische Cybersicherheitskontrollen. Für Lieferantenbeziehungen setzt sie konkrete Erwartungen an die Zugriffsbereitstellung, das Management privilegierter Accounts und die Vorfallmeldung — und verschiebt die Compliance-Frage von „Haben Sie eine Richtlinie?" zu „Können Sie nachweisen, dass die Kontrollen funktionieren?"

ENISAs technische Implementierungsanleitung von 2025 behandelt Lieferkettensicherheitsrichtlinien, Zugriffskontrollrichtlinien und Richtlinien für privilegierte Accounts als erforderliche themenspezifische Richtlinien im NIS2-Rahmenwerk.

Die 5 wesentlichen Zugriffskontrollen für NIS2-Lieferketten-Compliance

Wenn ein Lieferant Remote- oder privilegierten Zugriff hat, wird NIS2-Lieferkettensicherheit zu einem Identitätskontrollproblem. Die Lieferantenbeziehung schafft einen direkten Pfad in Ihre Netz- und Informationssysteme.

Strikte rollenbasierte Zugriffskontrolle (RBAC) durchsetzen

Eliminieren Sie gemeinsam genutzte Lieferantenaccounts. Jeder Lieferanteningenieur, der Systemzugriff benötigt, erhält einen namentlich zugeordneten, individuellen Account, der an seinen spezifischen Einsatz gekoppelt ist. Generische „Vendor"-Accounts machen eine Zuordnung während eines Vorfalls unmöglich — und genau diese Zuordnung verlangt die 24-Stunden-Frühwarnfrist nach Artikel 23.

Wenden Sie das Least-Privilege-Prinzip auf Rollenebene an: Lieferanten erhalten den minimalen Zugriff, der zur Erfüllung ihrer vertraglich vereinbarten Aufgaben erforderlich ist, beschränkt auf spezifische Assets, nicht auf breite Systemsegmente. Wenn sich der Einsatz ändert, ändern sich auch die Berechtigungen.

Tier-1-MFA für privilegierten Zugriff implementieren

ENISAs technische Anleitung von 2025 stuft MFA in drei Tiers ein. Für jeden Lieferanten mit administrativem oder privilegiertem Zugriff ist Tier 1 die einzig akzeptable Option.

Die praktische Auswirkung: Wenn Ihre MSP-Support-Ingenieure sich per SMS authentifizieren, um Produktionssysteme zu erreichen, ist das nach der aktuellen ENISA-Anleitung eine Compliance-Lücke. Tier-1-Methoden sind Phishing-resistent, da die kryptografischen Anmeldedaten an die spezifische Domain gebunden sind — eine Phishing-Seite kann sie nicht abfangen.

Privileged Access Management (PAM) und Credential Vaulting einsetzen

Just-in-Time (JIT)-Zugriff ist das richtige Modell für Drittanbieter-Support-Teams. Erhöhte Berechtigungen werden für eine definierte Sitzung gewährt, vollständig protokolliert und automatisch widerrufen, wenn die Sitzung endet. Kein ständiger Zugriff, keine persistenten privilegierten Accounts, die sich über Jahre von Lieferantenbeziehungen ansammeln.

Für gemeinsam genutzte Zugangsdaten, die nicht eliminiert werden können — Notfall-Break-Glass-Accounts, Legacy-System-Dienstaccounts, gemeinsam genutzte API-Schlüssel — verwenden Sie einen Credential-Tresor mit rollenbasierten Berechtigungen und vollständigem Audit-Trail. Ein Enterprise Password Manager kann gemeinsam genutzte Lieferantenzugangsdaten zentralisieren, den Zugriff nach Rollen einschränken und die Aufzeichnungen aufbewahren, nach denen ein Prüfer fragen wird.

Black Kites Supply Chain Vulnerability Report 2026 ergab, dass Angreifer Schwachstellen durchschnittlich sieben Tage vor der öffentlichen Bekanntmachung ausnutzen — basierend auf der Analyse von über 48.000 CVEs, die 2025 veröffentlicht wurden. Langlebige Lieferantenzugangsdaten in CI/CD-Pipelines oder Integrationsaccounts sind eine offene Einladung. Rotieren Sie API-Tokens nach einem definierten Zeitplan und widerrufen Sie sie sofort, wenn eine Lieferantenbeziehung endet.

Unveränderliche Audit-Protokolle führen

Artikel 23 setzt strenge Fristen für die Vorfallmeldung: eine 24-Stunden-Frühwarnung, eine 72-Stunden-förmliche Meldung und einen umfassenden Abschlussbericht innerhalb eines Monats. Diese Fristen ohne unveränderliche Audit-Protokolle einzuhalten, ist nicht realistisch. Die Protokolle sind der Nachweis — sie zeigen genau, was ein Lieferantenaccount wann und von wo aus getan hat.

Protokolle müssen manipulationssicher sein und lange genug aufbewahrt werden, um sowohl interne Untersuchungen als auch Anfragen der Aufsichtsbehörden zu unterstützen. Erfassen Sie speziell für Lieferantenaccounts Authentifizierungsereignisse, Berechtigungseskalationen, Sitzungsaktivitäten, Konfigurationsänderungen und den Zugriff auf sensible Daten. Wenn ein Vorfall eintritt, muss die Frage „Was hat dieser Lieferantenaccount berührt?" innerhalb von Stunden beantwortet werden können, nicht innerhalb von Wochen.

Zugangsdatenwiderruf automatisieren

Koppeln Sie den Lieferantenzugriff direkt an Vertragslebenszyklus-Ereignisse. Wenn ein Lieferantenvertrag ausläuft, gekündigt wird oder wenn ein namentlich zugeordneter Ingenieur das Lieferantenteam verlässt, muss der Zugriffsentzug sofort und automatisch erfolgen — nicht abhängig von einem manuellen Ticket, das jemand zu erstellen nicht vergisst.

Einen Supplier Access Control Record erstellen

Ein Supplier Access Control Record ist der operative Datensatz, der eine Lieferantenbeziehung mit spezifischen Zugriffsrechten und dem Nachweis verknüpft, dass diese Rechte kontrolliert werden. Ein Datensatz pro Lieferantenbeziehung. Dies ist die Einheit der Verantwortlichkeit.

Der Datensatz beantwortet die Fragen, die ein Prüfer, eine Aufsichtsbehörde oder Ihr eigenes Incident-Response-Team stellen wird: Wer hat Zugriff, worauf, über welchen Pfad, mit welcher Authentifizierung und wer hat es genehmigt?

ENISAs Leitfaden von 2025 erwartet, dass die Lieferkettensicherheitsrichtlinie Beziehungen zu direkten Lieferanten und Diensteanbietern regelt und Lieferantenrollen identifiziert: IKT-Lieferant, Managed Service Provider (MSP), Managed Security Service Provider (MSSP) und Cloud-Anbieter.

Ihre Datensätze sollten diese Unterscheidungen widerspiegeln. Das Risikoprofil eines MSP mit privilegiertem Zugriff auf Ihre Infrastruktur unterscheidet sich erheblich von dem eines SaaS-Anbieters mit schreibgeschütztem API-Zugriff, und die Kontrollen sollten entsprechend unterschiedlich sein.

So prüfen Sie Ihren aktuellen Lieferantenzugriff

Beginnen Sie mit einer vollständigen Lieferantenerfassung. Listen Sie jede externe Verbindung auf: VPNs, APIs, SaaS-Adminkonsolen, Remote-Support-Tools, CI/CD-Integrationen und Repository-Zugriff. Identifizieren Sie für jede Verbindung den Identitätstyp, die Authentifizierungsmethode, die Berechtigungsstufe und den internen Verantwortlichen für diese Beziehung.

Arbeiten Sie dann diese Pre-Audit-Checkliste für Lieferantenzugriff (7 Punkte) durch:

1. Jeder Lieferantenaccount ist namentlich zugeordnet — keine gemeinsam genutzten generischen Zugangsdaten für privilegierten Zugriff.
2. Das MFA-Tier entspricht der Zugriffssensibilität: Tier 1 für privilegiert, mindestens Tier 2 für Standard.
3. Alle Lieferantenaccounts werden über Verzeichniskontrollen mit automatisierter Deprovisionierung bereitgestellt.
4. Lieferantenverträge enthalten Anforderungen für namentlich zugeordnete Accounts, MFA-Verpflichtungen, 24-Stunden-Benachrichtigung bei Sicherheitsverletzungen, Prüfungsrechte und Offenlegung von Subunternehmern.
5. PAM oder Sitzungsprotokollierung deckt alle privilegierten Lieferantensitzungen ab.
6. API-Tokens und Dienstaccount-Zugangsdaten haben definierte Rotationspläne.
7. Der Rhythmus der Zugriffsüberprüfung ist dokumentiert: vierteljährlich für kritische Lieferanten, jährlich für alle anderen, sofort nach jeder Kündigung oder einem Vorfall.

Aktualisieren Sie Lieferantenverträge um explizite 24-Stunden-Benachrichtigungsklauseln bei Sicherheitsverletzungen und Prüfungsrechte, falls diese noch nicht enthalten sind. ENISAs Leitfaden von 2025 besagt, dass Verträge oder SLAs Cybersicherheitsanforderungen, Vorfallmeldepflichten, Schwachstellenhandhabung, Anforderungen an Subunternehmer und Kündigungsverpflichtungen abdecken sollten.

Die Kosten der Nichteinhaltung: Bußgelder und persönliche Haftung

Wesentliche Einrichtungen müssen nach NIS2 mit Höchstbußgeldern von bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes rechnen, je nachdem, welcher Betrag höher ist. Wichtige Einrichtungen mit bis zu 7 Millionen Euro oder 1,4 % des Umsatzes. Dies sind administrative Höchstgrenzen — Regulierungsbehörden wenden Verhältnismäßigkeit an — aber sie sind die Obergrenze, die Ihr Vorstand kennen muss.

Artikel 20 geht weiter. Er begründet eine persönliche Verantwortlichkeit für Führungskräfte der C-Ebene und Leitungsorgane. Führungskräfte können mit vorübergehenden Verboten für Führungspositionen belegt werden, wenn ihre Organisation als grob fahrlässig bei ihren Cybersicherheitspflichten befunden wird. Die Verpflichtung, Maßnahmen zum Cybersicherheits-Risikomanagement zu genehmigen und deren Umsetzung zu überwachen, liegt bei der Geschäftsführung, nicht nur beim IT-Team.

Die Verbindung zum Lieferantenzugriff ist direkt. Wenn eine Sicherheitsverletzung auf einen unkontrollierten Lieferantenaccount zurückzuführen ist — keine MFA, keine Sitzungsprotokollierung, keine Deprovisionierung nach Vertragsende — und die Geschäftsführung keinen Nachweis erbringen kann, dass Kontrollen vorhanden waren und überprüft wurden, ist das genau das Szenario, für das Artikel 20 geschrieben wurde.

Zugriffsanforderungen in Lieferantenverträge und Überprüfungen aufnehmen

Zugriffskontrollen scheitern, wenn Lieferantenverträge keine Verantwortlichkeiten definieren. Übersetzen Sie ENISAs Leitfaden in konkrete Vertragsklauseln:

• Lieferanten müssen namentlich zugeordnete Accounts verwenden und Tier-1-MFA für privilegierten oder Remote-Zugriff durchsetzen.
• Das Teilen von Zugangsdaten ist verboten.
• Lieferanten müssen den Kunden unverzüglich über Vorfälle informieren, bei erheblichen Vorfällen spätestens innerhalb von 24 Stunden.
• Subunternehmer, die Zugriff benötigen, müssen offengelegt und gleichwertigen Kontrollen unterworfen werden.
• Lieferanten müssen Protokollaufbewahrung und Prüfungsanfragen unterstützen.
• Informationen müssen bei Vertragsbeendigung zurückgegeben oder gelöscht werden.

Zugriffsüberprüfungen sollten einem definierten Rhythmus folgen: mindestens jährlich für alle Lieferanten, vierteljährlich für Lieferanten mit privilegiertem oder Produktionssystemzugriff, und sofort nach einem Vorfall, einer Vertragsänderung, einem Rollenwechsel oder einer Kündigung.

Audit-Nachweise für NIS2-Compliance aufbewahren

Audit-Nachweise sind es, die eine dokumentierte Kontrolle von einer bloßen Behauptung unterscheiden. Bei einem internen Audit, einer Kundenüberprüfung oder einer Anfrage der Aufsichtsbehörde müssen Sie Aufzeichnungen vorlegen — nicht Beschreibungen dessen, was Sie vorhatten zu tun.

Nützliche Nachweise umfassen: Lieferantenregister, Zugriffskontrollmatrix, genehmigte Zugriffsanfragen, MFA-Registrierungsberichte, PAM-Genehmigungsprotokolle, Passwort-Tresor-Berechtigungen, API-Token-Rotationsaufzeichnungen, Abzeichnungen von Zugriffsüberprüfungen, Lieferantenvertragsklauseln, Vorfallmeldungsaufzeichnungen, Schwachstellenbehebungs-Tickets und Deprovisionierungsaufzeichnungen.

Die Risikoakzeptanz für privilegierten Lieferantenzugriff sollte einen verantwortlichen Eigentümer haben. Diese Akzeptanz und die vorhandenen Kontrollen sollten der Geschäftsführung durch regelmäßige Berichte sichtbar sein — nicht in einer Tabelle vergraben, die nur das IT-Team finden kann.

10 Schritte zur NIS2-Lieferantenzugriffs-Compliance

Lieferantenzugriff erfassen, Kontrollen durchsetzen, Verpflichtungen vertraglich festlegen, kontinuierlich überwachen und Nachweise aufbewahren. Die folgende Tabelle fasst jeden Implementierungsschritt in einer einzigen Referenz zusammen — verwenden Sie sie als Arbeitscheckliste, nicht als einmalige Übung.

Der Supplier Access Control Record verbindet die Zeilen 1 bis 10: ein Dokument pro Beziehung, aktualisiert bei jedem Überprüfungszyklus, sichtbar für die Geschäftsführung.

Wenn Ihr Team gemeinsam genutzte Lieferantenpasswörter oder privilegierte Lieferantenzugangsdaten verwaltet, kann Password-Sharing-Software für Unternehmen wie Passwork helfen, Zugriff, Berechtigungen und Audit-Nachweise in einer kontrollierten Umgebung zu organisieren. Das ist eine Komponente in einem umfassenderen Zugriffskontrollprogramm, kein Ersatz für die oben beschriebene Governance-Arbeit.

Häufig gestellte Fragen

Verlangt NIS2 MFA für allen Lieferantenzugriff?

NIS2 Artikel 21(2)(j) bezieht sich auf MFA oder kontinuierliche Authentifizierung „wo angemessen", daher gilt ein risikobasierter Ansatz. ENISAs Leitfaden von 2025 schreibt Tier-1-Phishing-resistente MFA (FIDO2, WebAuthn) für alle privilegierten und administrativen Zugriffe vor. Tier-2-Methoden sind für Standardaccounts ohne erhöhte Berechtigungen akzeptabel. SMS- und E-Mail-OTP sind in regulierten Umgebungen zur Abschaffung vorgesehen.

Was ist die Durchführungsverordnung (EU) 2024/2690?

Die Durchführungsverordnung 2024/2690 übersetzt die breiten Anforderungen von NIS2 Artikel 21 in über 150 spezifische Cybersicherheitskontrollen. Für die Lieferkettensicherheit setzt sie konkrete Erwartungen an die Bereitstellung von Lieferantenzugriffen, das Management privilegierter Accounts und die Vorfallmeldung. Sie gilt direkt für DNS-Anbieter, Cloud-Dienste, Managed Service Provider und andere bezeichnete Einrichtungstypen.

Gilt NIS2 für Subunternehmer und Vierte Parteien?

Artikel 21(2)(d) konzentriert sich auf Beziehungen zu direkten Lieferanten und Diensteanbietern. Verträge sollten die Offenlegung von Subunternehmern und die Weitergabe von Cybersicherheitsanforderungen verlangen, wo immer der Lieferantenzugriff oder die Dienstkontinuität von einem Subunternehmer abhängt. ENISAs Leitfaden von 2025 unterstützt dies durch seine Empfehlungen zu Anforderungen an Subunternehmer in Lieferanten-SLAs.

Welche Nachweise belegen, dass Lieferantenzugriffskontrollen funktionieren?

Nützliche Nachweise umfassen Lieferantenzugriffsdatensätze, MFA-Registrierungs- und Login-Protokolle, PAM-Sitzungsgenehmigungen, Vertragsklauseln zu Zugriffsanforderungen, Abzeichnungen von Zugriffsüberprüfungen mit Daten, Deprovisionierungs-Tickets und Vorfallmeldungsaufzeichnungen. Die Kombination zeigt, dass Kontrollen existieren, angewendet werden und nach einem definierten Zeitplan überprüft werden.

Wie oft sollte der Lieferantenzugriff überprüft werden?

Überprüfen Sie alle Lieferantenzugriffe mindestens jährlich. Für Lieferanten mit privilegiertem oder Produktionssystemzugriff sind vierteljährliche Überprüfungen angemessener. Lösen Sie eine sofortige außerplanmäßige Überprüfung nach jedem Vorfall, jeder Vertragsänderung, jedem Personalwechsel auf Lieferantenseite oder jeder Vertragsbeendigung aus.

Was ist ein Supplier Access Control Record?

Ein Supplier Access Control Record ist ein pro Beziehung geführtes Dokument, das einen Lieferanten den spezifischen Accounts, Zugriffspfaden, Identitätstypen, Authentifizierungskontrollen und Nachweisdokumenten zuordnet, die mit dieser Beziehung verbunden sind. Er ist die operative Einheit zum Nachweis, dass das Lieferkettenrisiko in durchsetzbare Zugriffssteuerung nach NIS2 Artikel 21 überführt wurde.

NIS2 aktuelle Nachrichten: Durchsetzungs-Updates Mai 2026

Bulgariens vollständige Sanktionsphase, Luxemburgs neues Gesetz, Niederlandes Cyberbeveiligingswet, ENISA NIS360 2026 — NIS2-Durchsetzungsentwicklungen vom Mai 2026.

Passwork BlogAlex Muntyan

NIS2-Compliance-Leitfaden: Der Access-Management-Fahrplan für 2026

Gestohlene Zugangsdaten dominieren die Sicherheitsverletzungen 2026. NIS2 Artikel 21 schreibt 10 Sicherheitsmaßnahmen vor, um Angriffsvektoren auf Basis von Zugangsdaten zu eliminieren. Dieser Leitfaden behandelt technische Anforderungen, die 24-Stunden-Vorfallmeldepflicht, ENISAs MFA-Tiers und einen 5-Phasen-Fahrplan zur auditfähigen Compliance.

Passwork BlogAlex Muntyan

Mitarbeiter-Offboarding: Leitfaden für sicheren Zugriffsentzug 2026

Das Deaktivieren eines SSO-Accounts widerruft nicht den Zugriff. API-Schlüssel, KI-Agenten-Zugangsdaten und gemeinsam genutzte Passwörter überleben es. Dieser Leitfaden behandelt das vollständige Offboarding-Playbook — von Zero-Hour-Triggern bis zur NHI-Bereinigung.

Passwork BlogAlex Muntyan

Para implementar controles de acceso NIS2 para la seguridad de la cadena de suministro, asigne cada proveedor directo y prestador de servicios a los sistemas, cuentas, privilegios, métodos de autenticación y registros de evidencia que utilizan. Luego aplique el principio de mínimo privilegio, MFA o autenticación continua según corresponda, controles de cuentas privilegiadas, cláusulas contractuales, monitorización y revisiones periódicas de acceso.

La seguridad de la cadena de suministro NIS2 no es un ejercicio de adquisiciones. Significa traducir cada relación con proveedores en controles aplicables sobre cuentas, credenciales compartidas, rutas de acceso remoto, acciones privilegiadas y registros.

Según el Informe de Investigaciones de Brechas de Datos 2025 de Verizon, la participación de terceros apareció en el 30% de las brechas analizadas. El DBIR 2026 muestra que la tendencia se acelera: la participación de terceros ahora aparece en el 48% de las brechas confirmadas, un aumento interanual del 60%. Con esa trayectoria, la gobernanza del acceso de proveedores ya no es un riesgo de primer nivel que pueda posponerse.

El argumento financiero es igualmente contundente. El Informe del Coste de una Brecha de Datos 2025 de IBM sitúa el coste medio de una brecha en la cadena de suministro en 4,91 millones de dólares — y estas brechas tardan un total de 267 días en identificarse y contenerse. El Artículo 21 de NIS2 y el Reglamento de Ejecución (UE) 2024/2690 convierten esto en un mandato de IAM, no en una cuestión de gestión de proveedores.

Su organización asume la responsabilidad regulatoria por cada ruta de acceso que concede a una parte externa.

Puntos clave

• La seguridad de la cadena de suministro NIS2 es un mandato de IAM, no una cuestión de gestión de proveedores. El Artículo 21(2)(d) hace que su organización sea legalmente responsable de cada ruta de acceso concedida a una parte externa — VPNs, APIs, consolas de administración SaaS, pipelines CI/CD y herramientas de soporte remoto incluidas.
• Las brechas de terceros se están acelerando. El DBIR 2026 de Verizon sitúa la participación de terceros en el 48% de las brechas confirmadas — frente al 30% del año anterior.
• La guía 2025 de ENISA exige MFA de Nivel 1 para todo acceso privilegiado de proveedores. FIDO2 y WebAuthn son los únicos métodos aceptables para cuentas de proveedores con acceso administrativo o a sistemas de producción. El OTP por SMS está marcado para eliminación progresiva.
• Las cuentas de proveedor compartidas son una brecha de cumplimiento. Las cuentas individuales nominativas, RBAC de mínimo privilegio y acceso privilegiado just-in-time son la base — no un endurecimiento opcional.
• Los registros de auditoría son la evidencia, no el plan de respaldo. El plazo de alerta temprana de 24 horas del Artículo 23 no puede cumplirse sin registros inmutables que muestren exactamente qué hizo una cuenta de proveedor y cuándo.
• La revocación de acceso debe ser automática y vinculada a eventos del ciclo de vida del contrato. Los tickets manuales de desaprovisionamiento son demasiado lentos. Cuando un contrato de proveedor termina, el acceso termina con él.
• El Registro de Control de Acceso de Proveedores es la unidad de responsabilidad. Un registro por relación con proveedor — ruta de acceso, tipo de identidad, nivel de MFA, evidencia — actualizado en cada ciclo de revisión.

Qué exige NIS2 de los controles de acceso de proveedores

El Artículo 21 de NIS2 exige que las entidades esenciales e importantes adopten medidas técnicas, operativas y organizativas apropiadas y proporcionadas para gestionar los riesgos de ciberseguridad. El Artículo 21(2) enumera diez medidas mínimas. Cinco afectan directamente a la gobernanza del acceso de proveedores.

La directiva no exige una herramienta única ni un método de MFA universal. Requiere medidas que sean apropiadas y proporcionadas al riesgo. Para el acceso de proveedores, eso significa identificar qué usuarios externos, cuentas de soporte, APIs e integraciones pueden alcanzar sus activos críticos — y luego aplicar controles que coincidan con la sensibilidad de lo que esas rutas exponen.

El Artículo 21(3) va más allá: las entidades deben tener en cuenta las vulnerabilidades específicas de cada proveedor directo y prestador de servicios, y la calidad general de sus prácticas de ciberseguridad. Eso convierte la gobernanza de identidad y acceso de proveedores en una obligación legal directa, no en una recomendación de buenas prácticas.

El Reglamento de Ejecución (UE) 2024/2690 traduce los requisitos de alto nivel del Artículo 21 en más de 150 controles de ciberseguridad específicos. Para las relaciones con proveedores, establece expectativas concretas sobre el aprovisionamiento de acceso, la gestión de cuentas privilegiadas y la notificación de incidentes — pasando la cuestión de cumplimiento de «¿tiene una política?» a «¿puede demostrar que los controles funcionan?»

La guía de implementación técnica 2025 de ENISA trata la política de seguridad de la cadena de suministro, la política de control de acceso y las políticas de cuentas privilegiadas como políticas temáticas requeridas bajo el marco NIS2.

Los 5 controles de acceso esenciales para el cumplimiento de la cadena de suministro NIS2

Si un proveedor tiene acceso remoto o privilegiado, la seguridad de la cadena de suministro NIS2 se convierte en un problema de control de identidad. La relación con el proveedor crea una ruta directa hacia su red y sistemas de información.

Aplicar control de acceso basado en roles (RBAC) estricto

Elimine las cuentas de proveedor compartidas. Cada ingeniero de proveedor que necesite acceso al sistema obtiene una cuenta nominativa individual vinculada a su compromiso específico. Las cuentas genéricas de «proveedor» hacen imposible la atribución durante un incidente — y la atribución es exactamente lo que exige el requisito de alerta temprana de 24 horas del Artículo 23.

Aplique el mínimo privilegio a nivel de rol: los proveedores reciben el acceso mínimo requerido para realizar sus funciones contratadas, limitado a activos específicos, no a segmentos amplios del sistema. Cuando el compromiso cambia, los permisos cambian con él.

Implementar MFA de Nivel 1 para acceso privilegiado

La guía técnica 2025 de ENISA clasifica el MFA en tres niveles. Para cualquier proveedor al que se conceda acceso administrativo o privilegiado, el Nivel 1 es la única opción aceptable.

La implicación práctica: si los ingenieros de soporte de su MSP se autentican mediante SMS para acceder a sistemas de producción, eso es una brecha de cumplimiento según la guía actual de ENISA. Los métodos de Nivel 1 son resistentes al phishing porque la credencial criptográfica está vinculada al dominio específico — un sitio de phishing no puede interceptarla.

Implementar gestión de acceso privilegiado (PAM) y almacenamiento seguro de credenciales

El acceso just-in-time (JIT) es el modelo adecuado para equipos de soporte de terceros. Los privilegios elevados se conceden para una sesión definida, se registran completamente y se revocan automáticamente cuando la sesión termina. Sin acceso permanente, sin cuentas privilegiadas persistentes que se acumulan durante años de relaciones con proveedores.

Para las credenciales compartidas que no pueden eliminarse — cuentas de emergencia break-glass, cuentas de servicio de sistemas heredados, claves API compartidas — utilice una bóveda de credenciales con permisos basados en roles y una pista de auditoría completa. Un gestor de contraseñas empresarial puede centralizar las credenciales compartidas de proveedores, restringir el acceso por rol y conservar los registros que un auditor solicitará.

El Informe de Vulnerabilidades de la Cadena de Suministro 2026 de Black Kite encontró que los atacantes explotan vulnerabilidades un promedio de siete días antes de la divulgación pública, analizando más de 48.000 CVEs publicados en 2025. Las credenciales de proveedor de larga duración en pipelines CI/CD o cuentas de integración son una invitación abierta. Rote los tokens API en un calendario definido y revóquelos inmediatamente cuando una relación con un proveedor termine.

Mantener registros de auditoría inmutables

El Artículo 23 establece plazos estrictos de notificación de incidentes: una alerta temprana de 24 horas, una notificación formal de 72 horas y un informe final completo en un mes. Cumplir esos plazos sin registros de auditoría inmutables no es realista. Los registros son la evidencia — muestran exactamente qué hizo una cuenta de proveedor, cuándo y desde dónde.

Los registros deben ser resistentes a manipulaciones y conservarse el tiempo suficiente para respaldar tanto las investigaciones internas como las solicitudes de supervisión. Para las cuentas de proveedores específicamente, capture eventos de autenticación, escaladas de privilegios, actividad de sesión, cambios de configuración y acceso a datos sensibles. Cuando ocurre un incidente, la pregunta «¿qué tocó esta cuenta de proveedor?» necesita una respuesta en horas, no en semanas.

Automatizar la revocación de credenciales

Vincule el acceso del proveedor directamente a los eventos del ciclo de vida del contrato. Cuando un contrato de proveedor expira, se termina, o cuando un ingeniero nominativo deja el equipo del proveedor, la revocación de acceso debe ser inmediata y automática — no dependiente de un ticket manual que alguien recuerde crear.

Crear un Registro de Control de Acceso de Proveedores

Un Registro de Control de Acceso de Proveedores es el registro operativo que vincula una relación con un proveedor a derechos de acceso específicos y la evidencia de que esos derechos están controlados. Un registro por relación con proveedor. Esta es la unidad de responsabilidad.

El registro responde a las preguntas que un auditor, un regulador o su propio equipo de respuesta a incidentes hará: ¿quién tiene acceso, a qué, a través de qué ruta, con qué autenticación y quién lo aprobó?

La guía 2025 de ENISA espera que la política de seguridad de la cadena de suministro gobierne las relaciones con proveedores directos y prestadores de servicios e identifique los roles de los proveedores: proveedor de TIC, proveedor de servicios gestionados (MSP), proveedor de servicios de seguridad gestionados (MSSP) y proveedor de nube.

Sus registros deben reflejar estas distinciones. El perfil de riesgo de un MSP con acceso privilegiado a su infraestructura difiere significativamente de un proveedor SaaS con acceso API de solo lectura, y los controles deben diferir en consecuencia.

Cómo auditar su acceso actual de proveedores

Comience con un ejercicio completo de mapeo de proveedores. Liste cada conexión externa: VPNs, APIs, consolas de administración SaaS, herramientas de soporte remoto, integraciones CI/CD y acceso a repositorios. Para cada conexión, identifique el tipo de identidad, método de autenticación, nivel de privilegio y el propietario interno responsable de esa relación.

Luego trabaje a través de esta Lista de verificación previa a la auditoría de acceso de proveedores (7 puntos):

1. Cada cuenta de proveedor es nominativa — no se utilizan credenciales genéricas compartidas para acceso privilegiado.
2. El nivel de MFA coincide con la sensibilidad del acceso: Nivel 1 para privilegiado, Nivel 2 mínimo para estándar.
3. Todas las cuentas de proveedor se aprovisionan a través de controles de directorio con desaprovisionamiento automatizado.
4. Los contratos con proveedores incluyen requisitos de cuentas nominativas, obligaciones de MFA, notificación de brechas en 24 horas, derechos de auditoría y divulgación de subcontratistas.
5. PAM o registro de sesiones cubre todas las sesiones privilegiadas de proveedores.
6. Los tokens API y las credenciales de cuentas de servicio tienen calendarios de rotación definidos.
7. La cadencia de revisión de acceso está documentada: trimestral para proveedores críticos, anual para todos los demás, inmediatamente después de cualquier terminación o incidente.

Actualice los contratos con proveedores para incluir cláusulas explícitas de notificación de brechas en 24 horas y derechos de auditoría si aún no las tienen. La guía 2025 de ENISA establece que los contratos o SLAs deben cubrir requisitos de ciberseguridad, obligaciones de notificación de incidentes, gestión de vulnerabilidades, requisitos de subcontratación y obligaciones de terminación.

El coste del incumplimiento: multas y responsabilidad personal

Las entidades esenciales enfrentan multas máximas de hasta 10 millones de euros o el 2% de la facturación anual global bajo NIS2, lo que sea mayor. Las entidades importantes enfrentan hasta 7 millones de euros o el 1,4% de la facturación. Estos son máximos administrativos — los reguladores aplican proporcionalidad — pero son el techo que su junta directiva necesita entender.

El Artículo 20 va más allá. Establece responsabilidad personal para ejecutivos de nivel C y órganos de dirección. Los ejecutivos pueden enfrentar prohibiciones temporales de ocupar puestos directivos si se determina que su organización ha sido gravemente negligente en sus obligaciones de ciberseguridad. La obligación de aprobar las medidas de gestión de riesgos de ciberseguridad y supervisar su implementación recae en la dirección, no solo en el equipo de TI.

La conexión con el acceso de proveedores es directa. Si una brecha se remonta a una cuenta de proveedor no controlada — sin MFA, sin registro de sesiones, sin desaprovisionamiento después del fin del contrato — y la dirección no puede producir evidencia de que los controles estaban en vigor y se revisaban, ese es el escenario para el que se redactó el Artículo 20.

Incorporar requisitos de acceso en contratos y revisiones de proveedores

Los controles de acceso fallan cuando los contratos con proveedores no definen responsabilidades. Traduzca la guía de ENISA en cláusulas contractuales concretas:

• Los proveedores deben usar cuentas nominativas y aplicar MFA de Nivel 1 para acceso privilegiado o remoto.
• Está prohibido compartir credenciales.
• Los proveedores deben notificar al cliente los incidentes sin demora indebida, y no más tarde de 24 horas para incidentes significativos.
• Los subcontratistas que requieran acceso deben ser divulgados y estar sujetos a controles equivalentes.
• Los proveedores deben respaldar la retención de registros y las solicitudes de auditoría.
• La información debe ser devuelta o eliminada al terminar el contrato.

Las revisiones de acceso deben seguir una cadencia definida: como mínimo anualmente para todos los proveedores, trimestralmente para proveedores con acceso privilegiado o a sistemas de producción, e inmediatamente después de un incidente, cambio de contrato, cambio de rol o terminación.

Conservar evidencia de auditoría para el cumplimiento de NIS2

La evidencia de auditoría es lo que separa un control documentado de una afirmación. Durante una auditoría interna, una revisión de cliente o una solicitud de supervisión, necesita producir registros — no descripciones de lo que pretendía hacer.

La evidencia útil incluye: registro de proveedores, matriz de control de acceso, solicitudes de acceso aprobadas, informes de inscripción de MFA, registros de aprobación PAM, permisos de bóveda de contraseñas, registros de rotación de tokens API, aprobaciones de revisión de acceso, cláusulas contractuales con proveedores, registros de notificación de incidentes, tickets de remediación de vulnerabilidades y registros de desaprovisionamiento.

La aceptación del riesgo para el acceso privilegiado de proveedores debe tener un propietario responsable. Esa aceptación, y los controles implementados, deben ser visibles para la dirección a través de informes periódicos — no enterrados en una hoja de cálculo que solo el equipo de TI puede encontrar.

10 pasos para el cumplimiento de acceso de proveedores NIS2

Mapee el acceso de proveedores, aplique controles, contracte las obligaciones, monitorice continuamente y conserve evidencia. La tabla siguiente consolida cada paso de implementación en una única referencia — úsela como una lista de verificación de trabajo, no como un ejercicio único.

El Registro de Control de Acceso de Proveedores une las filas 1 a 10: un documento por relación, actualizado en cada ciclo de revisión, visible para la dirección.

Si su equipo gestiona contraseñas de proveedores compartidas o credenciales privilegiadas de proveedores, el software de compartición de contraseñas para empresas como Passwork puede ayudar a organizar el acceso, los permisos y la evidencia de auditoría en un entorno controlado. Ese es un componente dentro de un programa de control de acceso más amplio, no un sustituto del trabajo de gobernanza descrito anteriormente.

Preguntas frecuentes

¿Exige NIS2 MFA para todo acceso de proveedores?

El Artículo 21(2)(j) de NIS2 se refiere a MFA o autenticación continua «cuando sea apropiado», por lo que se aplica un enfoque basado en riesgos. La guía 2025 de ENISA exige MFA resistente al phishing de Nivel 1 (FIDO2, WebAuthn) para todo acceso privilegiado y administrativo. Los métodos de Nivel 2 son aceptables para cuentas estándar sin privilegios elevados. El OTP por SMS y correo electrónico está marcado para eliminación progresiva en entornos regulados.

¿Qué es el Reglamento de Ejecución (UE) 2024/2690?

El Reglamento de Ejecución 2024/2690 traduce los requisitos amplios del Artículo 21 de NIS2 en más de 150 controles de ciberseguridad específicos. Para la seguridad de la cadena de suministro, establece expectativas concretas sobre el aprovisionamiento de acceso de proveedores, la gestión de cuentas privilegiadas y la notificación de incidentes. Se aplica directamente a proveedores DNS, servicios en la nube, proveedores de servicios gestionados y otros tipos de entidades designadas.

¿Se aplica NIS2 a subcontratistas y cuartas partes?

El Artículo 21(2)(d) se centra en las relaciones con proveedores directos y prestadores de servicios. Los contratos deben requerir la divulgación de subcontratistas y la extensión de los requisitos de ciberseguridad siempre que el acceso del proveedor o la continuidad del servicio dependa de un subcontratista. La guía 2025 de ENISA respalda esto a través de sus recomendaciones sobre requisitos de subcontratación en los SLAs de proveedores.

¿Qué evidencia demuestra que los controles de acceso de proveedores funcionan?

La evidencia útil incluye registros de acceso de proveedores, registros de inscripción e inicio de sesión de MFA, aprobaciones de sesión PAM, cláusulas contractuales que especifican requisitos de acceso, aprobaciones de revisión de acceso con fechas, tickets de desaprovisionamiento y registros de notificación de incidentes. La combinación demuestra que los controles existen, se aplican y se revisan en un calendario definido.

¿Con qué frecuencia debe revisarse el acceso de proveedores?

Revise todo el acceso de proveedores al menos anualmente. Para proveedores con acceso privilegiado o a sistemas de producción, las revisiones trimestrales son más apropiadas. Active una revisión fuera de ciclo inmediata después de cualquier incidente, cambio de contrato, cambio de personal en el lado del proveedor o terminación de contrato.

¿Qué es un Registro de Control de Acceso de Proveedores?

Un Registro de Control de Acceso de Proveedores es un documento por relación que asigna un proveedor a las cuentas específicas, rutas de acceso, tipos de identidad, controles de autenticación y registros de evidencia asociados con esa relación. Es la unidad operativa para demostrar que el riesgo de la cadena de suministro se ha convertido en gobernanza de acceso aplicable bajo el Artículo 21 de NIS2.

Últimas noticias de NIS2: Actualizaciones de aplicación de mayo 2026

La fase de sanciones completas de Bulgaria, la nueva ley de Luxemburgo, la Cyberbeveiligingswet de los Países Bajos, ENISA NIS360 2026 — desarrollos de aplicación de NIS2 de mayo 2026.

Passwork BlogAlex Muntyan

Guía de cumplimiento NIS2: La hoja de ruta de gestión de acceso para 2026

Las credenciales robadas dominan las brechas en 2026. El Artículo 21 de NIS2 exige 10 medidas de seguridad para eliminar los vectores de ataque basados en credenciales. Esta guía cubre los requisitos técnicos, la obligación de notificación de incidentes en 24 horas, los niveles de MFA de ENISA y una hoja de ruta de 5 fases para el cumplimiento listo para auditoría.

Passwork BlogAlex Muntyan

Desvinculación de empleados: Guía de revocación segura de acceso 2026

Deshabilitar una cuenta SSO no revoca el acceso. Las claves API, las credenciales de agentes de IA y las contraseñas compartidas sobreviven. Esta guía cubre el manual completo de desvinculación — desde los disparadores de hora cero hasta la limpieza de NHI.

Passwork BlogAlex Muntyan

To implement NIS2 access controls for supply chain security, map every direct supplier and service provider to the systems, accounts, privileges, authentication methods, and evidence records they use. Then enforce least privilege, MFA or continuous authentication where appropriate, privileged account controls, contract clauses, monitoring, and periodic access reviews.

NIS2 supply chain security is not a procurement exercise. It means translating every supplier relationship into enforceable controls over accounts, shared credentials, remote access paths, privileged actions, and logs.

According to Verizon's 2025 Data Breach Investigations Report, third-party involvement appeared in 30% of analyzed breaches. The 2026 DBIR shows the trend accelerating: third-party involvement now appears in 48% of confirmed breaches, a 60% year-over-year increase. At that trajectory, supplier access governance is no longer a first-tier risk you can defer.

The financial case is equally stark. IBM's Cost of a Data Breach Report 2025 puts the average cost of a supply chain compromise at $4.91 million — and these breaches take a combined 267 days to identify and contain. NIS2 Article 21 and the Implementing Regulation (EU) 2024/2690 make this an IAM mandate, not a vendor management question.

Your organization bears the regulatory responsibility for every access path you grant to an external party.

Key takeaways

• NIS2 supply chain security is an IAM mandate, not a vendor management question. Article 21(2)(d) makes your organization legally responsible for every access path granted to an external party — VPNs, APIs, SaaS admin consoles, CI/CD pipelines, and remote support tools included.
• Third-party breaches are accelerating. Verizon's 2026 DBIR puts third-party involvement at 48% of confirmed breaches — up from 30% the previous year.
• ENISA's 2025 guidance mandates Tier 1 MFA for all privileged vendor access. FIDO2 and WebAuthn are the only acceptable methods for supplier accounts with administrative or production-system access. SMS OTP is flagged for phase-out.
• Shared vendor accounts are a compliance gap. Named individual accounts, least-privilege RBAC, and just-in-time privileged access are the baseline — not optional hardening.
• Audit logs are the evidence, not the backup plan. Article 23's 24-hour early warning deadline cannot be met without immutable logs that show exactly what a vendor account did and when.
• Access revocation must be automatic and tied to contract lifecycle events. Manual deprovisioning tickets are too slow. When a supplier contract ends, access ends with it.
• The Supplier Access Control Record is the unit of accountability. One record per supplier relationship — access path, identity type, MFA tier, evidence — updated at every review cycle.

What NIS2 requires from supplier access controls

NIS2 Article 21 requires essential and important entities to take appropriate and proportionate technical, operational, and organisational measures to manage cybersecurity risks. Article 21(2) lists ten minimum measures. Five bear directly on supplier access governance.

The directive does not mandate a single tool or a universal MFA method. It requires measures that are appropriate and proportionate to the risk. For supplier access, that means identifying which external users, support accounts, APIs, and integrations can reach your critical assets — and then applying controls that match the sensitivity of what those paths expose.

Article 21(3) goes further: entities must account for vulnerabilities specific to each direct supplier and service provider, and the overall quality of their cybersecurity practices. That makes supplier identity and access governance a direct legal obligation, not a best-practice recommendation.

The Implementing Regulation (EU) 2024/2690 translates Article 21's high-level requirements into over 150 specific cybersecurity controls. For supplier relationships, it sets concrete expectations around access provisioning, privileged account management, and incident notification — moving the compliance question from "do you have a policy?" to "can you prove the controls are working?"

ENISA's 2025 technical implementation guidance treats supply chain security policy, access control policy, and privileged account policies as required topic-specific policies under the NIS2 framework.

The 5 essential access controls for NIS2 supply chain compliance

If a supplier has remote or privileged access, NIS2 supply chain security becomes an identity-control problem. The supplier relationship creates a direct path into your network and information systems.

Enforce strict role-based access control (RBAC)

Eliminate shared vendor accounts. Every supplier engineer who needs system access gets a named, individual account tied to their specific engagement. Generic "vendor" accounts make attribution impossible during an incident — and attribution is exactly what Article 23's 24-hour early warning requirement demands.

Apply least privilege at the role level: suppliers receive the minimum access required to perform their contracted duties, scoped to specific assets, not broad system segments. When the engagement changes, the permissions change with it.

Implement tier 1 MFA for privileged access

ENISA's 2025 technical guidance ranks MFA in three tiers. For any supplier granted administrative or privileged access, Tier 1 is the only acceptable option.

The practical implication: if your MSP support engineers authenticate via SMS to reach production systems, that is a compliance gap under the current ENISA guidance. Tier 1 methods are phishing-resistant because the cryptographic credential is bound to the specific domain — a phishing site cannot intercept it.

Deploy privileged access management (PAM) and credential vaulting

Just-in-time (JIT) access is the right model for third-party support teams. Elevated privileges are granted for a defined session, logged in full, and revoked automatically when the session ends. No standing access, no persistent privileged accounts that accumulate over years of vendor relationships.

For shared credentials that cannot be eliminated — emergency break-glass accounts, legacy system service accounts, shared API keys — use a credential vault with role-based permissions and a full audit trail. An enterprise password manager can centralize shared vendor credentials, restrict access by role, and retain the records an auditor will ask for.

Black Kite's 2026 Supply Chain Vulnerability Report found that attackers exploit vulnerabilities an average of seven days before public disclosure, analyzing over 48,000 CVEs published in 2025. Long-lived supplier credentials sitting in CI/CD pipelines or integration accounts are a standing invitation. Rotate API tokens on a defined schedule and revoke them immediately when a supplier relationship ends.

Maintain immutable audit logs

Article 23 sets strict incident reporting timelines: a 24-hour early warning, a 72-hour formal notification, and a comprehensive final report within one month. Meeting those deadlines without immutable audit logs is not realistic. The logs are the evidence — they show exactly what a vendor account did, when, and from where.

Logs must be tamper-resistant and retained long enough to support both internal investigations and supervisory requests. For supplier accounts specifically, capture authentication events, privilege escalations, session activity, configuration changes, and access to sensitive data. When an incident occurs, the question "what did this vendor account touch?" needs an answer in hours, not weeks.

Automate credential revocation

Tie supplier access directly to contract lifecycle events. When a vendor contract expires, is terminated, or when a named engineer leaves the supplier's team, access revocation must be immediate and automatic — not dependent on a manual ticket that someone remembers to raise.

Build a Supplier Access Control Record

A Supplier Access Control Record is the operational record that links a supplier relationship to specific access rights and the evidence that those rights are controlled. One record per supplier relationship. This is the unit of accountability.

The record answers the questions an auditor, a regulator, or your own incident response team will ask: who has access, to what, through which path, with what authentication, and who signed off?

ENISA's 2025 guidance expects supply chain security policy to govern relationships with direct suppliers and service providers and to identify supplier roles: ICT supplier, managed service provider (MSP), managed security service provider (MSSP), and cloud provider.

Your records should reflect these distinctions. The risk profile of an MSP with privileged access to your infrastructure differs significantly from a SaaS vendor with read-only API access, and the controls should differ accordingly.

How to audit your current supplier access

Start with a full supplier mapping exercise. List every external connection: VPNs, APIs, SaaS admin consoles, remote support tools, CI/CD integrations, and repository access. For each connection, identify the identity type, authentication method, privilege level, and the internal owner accountable for that relationship.

Then work through this Pre-audit supplier access checklist (7 points):

1. Every supplier account is named — no shared generic credentials in use for privileged access.
2. MFA tier matches the access sensitivity: Tier 1 for privileged, Tier 2 minimum for standard.
3. All supplier accounts are provisioned through directory controls with automated deprovisioning.
4. Vendor contracts include named-account requirements, MFA obligations, 24-hour breach notification, audit rights, and subcontractor disclosure.
5. PAM or session logging covers all privileged supplier sessions.
6. API tokens and service account credentials have defined rotation schedules.
7. Access review cadence is documented: quarterly for critical suppliers, annually for all others, immediately after any termination or incident.

Update vendor contracts to include explicit 24-hour breach notification clauses and audit rights if they do not already. ENISA's 2025 guidance states contracts or SLAs should cover cybersecurity requirements, incident notification duties, vulnerability handling, subcontracting requirements, and termination obligations.

The cost of non-compliance: fines and personal liability

Essential entities face maximum fines of up to €10 million or 2% of global annual turnover under NIS2, whichever is higher. Important entities face up to €7 million or 1.4% of turnover. These are administrative maximums — regulators apply proportionality — but they are the ceiling your board needs to understand.

Article 20 goes further. It establishes personal accountability for C-suite executives and management bodies. Executives can face temporary bans from holding management roles if their organization is found grossly negligent in its cybersecurity duties. The obligation to approve cybersecurity risk-management measures and oversee their implementation sits with management, not only with the IT team.

The connection to supplier access is direct. If a breach traces back to an uncontrolled vendor account — no MFA, no session logging, no deprovisioning after contract end — and management cannot produce evidence that controls were in place and reviewed, that is the scenario Article 20 was written for.

Put access requirements into supplier contracts and reviews

Access controls fail when supplier contracts do not define responsibilities. Translate ENISA's guidance into concrete contract clauses:

• Suppliers must use named accounts and enforce Tier 1 MFA for privileged or remote access.
• Credential sharing is prohibited.
• Suppliers must notify the customer of incidents without undue delay, and no later than 24 hours for significant incidents.
• Subcontractors requiring access must be disclosed and subject to equivalent controls.
• Suppliers must support log retention and audit requests.
• Information must be returned or deleted at contract termination.

Access reviews should follow a defined cadence: at minimum annually for all suppliers, quarterly for suppliers with privileged or production access, and immediately after an incident, contract change, role change, or termination.

Keep audit evidence for NIS2 compliance

Audit evidence is what separates a documented control from a claim. During an internal audit, a customer review, or a supervisory request, you need to produce records — not descriptions of what you intended to do.

Useful evidence includes: supplier register, access-control matrix, approved access requests, MFA enrollment reports, PAM approval logs, password vault permissions, API token rotation records, access review sign-offs, supplier contract clauses, incident notification records, vulnerability remediation tickets, and deprovisioning records.

Risk acceptance for supplier privileged access should have an accountable owner. That acceptance, and the controls in place, should be visible to management through periodic reporting — not buried in a spreadsheet that only the IT team can find.

10 steps to NIS2 supplier access compliance

Map supplier access, enforce controls, contract the obligations, monitor continuously, and keep evidence. The table below consolidates every implementation step into a single reference — use it as a working checklist, not a one-time exercise.

The Supplier Access Control Record ties rows 1 through 10 together: one document per relationship, updated at every review cycle, visible to management.

If your team manages shared vendor passwords or privileged supplier credentials, password sharing software for businesses like Passwork can help organize access, permissions, and audit evidence in one controlled environment. That is one component in a broader access-control program, not a substitute for the governance work described above.

Frequently asked questions

Does NIS2 require MFA for all supplier access?

NIS2 Article 21(2)(j) refers to MFA or continuous authentication "where appropriate," so a risk-based approach applies. ENISA's 2025 guidance mandates Tier 1 phishing-resistant MFA (FIDO2, WebAuthn) for all privileged and administrative access. Tier 2 methods are acceptable for standard accounts without elevated privileges. SMS and email OTP are flagged for phase-out in regulated environments.

What is the Implementing Regulation (EU) 2024/2690?

The Implementing Regulation 2024/2690 translates NIS2 Article 21's broad requirements into over 150 specific cybersecurity controls. For supply chain security, it sets concrete expectations around supplier access provisioning, privileged account management, and incident notification. It applies directly to DNS providers, cloud services, managed service providers, and other designated entity types.

Does NIS2 apply to subcontractors and fourth parties?

Article 21(2)(d) focuses on relationships with direct suppliers and service providers. Contracts should require subcontractor disclosure and flow-down of cybersecurity requirements wherever supplier access or service continuity depends on a subcontractor. ENISA's 2025 guidance supports this through its recommendations on subcontracting requirements in supplier SLAs.

What evidence proves supplier access controls are working?

Useful evidence includes supplier access records, MFA enrollment and login logs, PAM session approvals, contract clauses specifying access requirements, access review sign-offs with dates, deprovisioning tickets, and incident notification records. The combination demonstrates that controls exist, are applied, and are reviewed on a defined schedule.

How often should supplier access be reviewed?

Review all supplier access at least annually. For suppliers with privileged or production-system access, quarterly reviews are more appropriate. Trigger an immediate out-of-cycle review after any incident, contract change, personnel change on the supplier side, or contract termination.

What is a Supplier Access Control Record?

A Supplier Access Control Record is a per-relationship document that maps a supplier to the specific accounts, access paths, identity types, authentication controls, and evidence records associated with that relationship. It is the operational unit for proving that supply chain risk has been converted into enforceable access governance under NIS2 Article 21.

NIS2 latest news: May 2026 enforcement updates

Bulgaria’s full sanctions phase, Luxembourg’s new law, Netherlands’ Cyberbeveiligingswet, ENISA NIS360 2026 — NIS2 enforcement developments from May 2026.

Passwork BlogAlex Muntyan

NIS2 compliance guide: The access management roadmap for 2026

Stolen credentials dominate breaches in 2026. NIS2 Article 21 mandates 10 security measures to eliminate credential-based attack vectors. This guide covers technical requirements, the 24-hour incident reporting obligation, ENISA’s MFA tiers, and a 5-phase roadmap to audit-ready compliance.

Passwork BlogAlex Muntyan

Employee offboarding: Secure access revocation guide 2026

Disabling an SSO account doesn’t revoke access. API keys, AI agent credentials, and shared passwords survive it. This guide covers the full offboarding playbook — from zero-hour triggers to NHI cleanup.

Passwork BlogAlex Muntyan

O período de tolerância da NIS2 na Bulgária terminou a 1 de junho de 2026: os membros do órgão de gestão passam a estar sujeitos às coimas pessoais na íntegra, e já não beneficiam da redução de 50 % que vigorou até maio. A lei de transposição da Diretiva NIS2 do Luxemburgo entrou em vigor a 10 de maio de 2026, pelo que quatro Estados-Membros continuam sem legislação de transposição. O Grupo de Cooperação NIS da UE adotou modelos comuns de notificação de incidentes que a Comissão pretende tornar obrigatórios através de um ato de execução.

Este artigo reúne todas as atualizações relevantes da NIS2 de maio de 2026: o que mudou, que prazos estão em curso e em que a equipa tem de agir desde já.

Pontos principais

As atualizações da NIS2 de maio de 2026 têm desencadeadores de conformidade concretos: datas e obrigações específicas. Eis o que mudou.

• O regime sancionatório pleno da Bulgária está em vigor. A partir de 1 de junho de 2026, as coimas pessoais aplicáveis aos membros do órgão de gestão correspondem a 100 % dos montantes legais, até 5000 euros por pessoa, independentemente das coimas aplicáveis às entidades, que podem chegar a 10 milhões de euros. A redução transitória de 50 % deixou de existir.
• A lei da NIS2 do Luxemburgo entrou em vigor a 10 de maio de 2026. As entidades abrangidas têm até 10 de julho de 2026 para efetuar o autorregisto junto do ILR. A falta de registo constitui, por si só, uma infração sancionável.
• Quatro Estados-Membros da UE continuam sem transpor a NIS2, mais de 19 meses depois do prazo de outubro de 2024, segundo o levantamento de maio de 2026 da Cullen International.
• Foram adotados modelos comuns de notificação de incidentes em toda a UE. O Grupo de Cooperação NIS acordou formatos normalizados na sua 39.ª reunião plenária, em Chipre, a 26 de maio de 2026. Um ato de execução da Comissão tornará esses modelos obrigatórios.
• O relatório NIS360 2026 da ENISA identifica oito setores em zona de risco. Saúde, transportes ferroviários, transportes marítimos, gestão de serviços de TIC, espaço, administração pública, água potável e águas residuais apresentam a menor maturidade em cibersegurança face à sua criticidade.
• Os Países Baixos fizeram avançar a Cyberbeveiligingswet, que estava atrasada. A Câmara dos Representantes neerlandesa aprovou o projeto de lei a 15 de abril de 2026; a aprovação do Senado continua pendente.
• A Irlanda confirmou a National Cyber Security Bill como instrumento de transposição da NIS2. O Departamento da Justiça está a redigir a legislação e a conferir ao NCSC um enquadramento legal.
• A DigitalEurope defendeu uma harmonização mais profunda da NIS2. A associação do setor publicou uma posição formal que identifica o âmbito de aplicação, os limiares de dimensão, a notificação de incidentes e a avaliação da conformidade como as áreas que mais precisam de normalização entre Estados-Membros.

A fase de aplicação plena na Bulgária começou a 1 de junho de 2026

A aplicação da NIS2 na Bulgária entrou na fase final a 1 de junho de 2026. As coimas e sanções por todas as infrações aplicam-se agora na totalidade dos montantes legais: a redução de 50 % que vigorava para as infrações cometidas antes dessa data deixou de existir.

A legislação de base é a Lei que altera e completa a Lei da Cibersegurança, adotada pela 51.ª Assembleia Nacional a 5 de fevereiro de 2026 e promulgada no jornal oficial búlgaro State Gazette (n.º 17) a 13 de fevereiro de 2026, tendo entrado em vigor na mesma data.

Quem está abrangido

A Lei da Cibersegurança abrange entidades públicas e privadas dos setores dos anexos I e II que atinjam ou ultrapassem os limiares das médias empresas. Determinados prestadores estão abrangidos independentemente da dimensão: redes públicas de comunicações eletrónicas, prestadores de serviços de confiança, registos de nomes de domínio de topo, prestadores de serviços DNS, entidades que sejam o único prestador de um serviço crítico na Bulgária ou cuja perturbação afetaria significativamente a ordem pública, a segurança pública ou a saúde, ou a economia.

Os organismos da administração pública (incluindo os municípios) são classificados como entidades essenciais nos termos do artigo 4a(1)(4), independentemente da dimensão.

Aplicação plena sem um conjunto completo de regras

Subsiste uma complicação prática. A lei delega expressamente a definição das medidas mínimas de cibersegurança para determinadas categorias de entidades num regulamento secundário do Conselho de Ministros, a propor conjuntamente pela Comissão de Regulação das Comunicações e pelo Ministro do Governo Eletrónico. Esse regulamento ainda não foi publicado. As organizações entraram na fase de aplicação plena sem o conjunto completo de regras operacionais que a própria lei previa.

Isso não suspende as obrigações. A lei principal está em vigor e as sanções são reais. Fazer desde já uma análise de lacunas face ao quadro normativo existente da NIS2 é possível e aconselhável, antes de a pressão da supervisão aumentar. ISO/IEC 27001 e ISO 22301 constituem uma base de trabalho viável a par dos requisitos da Lei da Cibersegurança.

O que os órgãos de gestão têm agora de demonstrar

A Lei da Cibersegurança da Bulgária atribui responsabilidade pessoal explícita a cada membro dos órgãos de gestão, e não apenas à organização enquanto pessoa coletiva. Os órgãos de gestão devem:

• Aprovar formalmente as medidas de gestão dos riscos de cibersegurança exigidas pelo artigo 21.º
• Supervisionar a execução dessas medidas
• Concluir formação em cibersegurança, no mínimo de dois em dois anos
• Organizar formação equivalente para os trabalhadores com regularidade

As medidas que os órgãos de gestão têm de aprovar abrangem a análise de riscos e as políticas de segurança da informação, o tratamento de incidentes, a continuidade das atividades e a gestão de crises, a segurança da cadeia de abastecimento, as práticas de ciber-higiene e a autenticação multifator, quando adequado.

A estrutura das coimas pessoais

Quando um membro do órgão de gestão de uma entidade essencial ou importante infringe estas obrigações de governação, pode ser imposta uma coima pessoal de 500 a 5000 euros. Esta é distinta das sanções ao nível da entidade e acresce a estas: até 10 milhões de euros ou 2 % do volume de negócios mundial para as entidades essenciais, e até 7 milhões de euros ou 1,4 % para as entidades importantes.

A autoridade nacional competente pode ainda solicitar a um tribunal que imponha a uma pessoa singular a proibição temporária de exercer funções de gestão numa entidade essencial.

Implicação prática: um membro do órgão de gestão não pode eximir-se à responsabilidade por via da delegação. A eventual aplicação de uma coima, e a sua gravidade, dependerá da capacidade de a pessoa demonstrar ações concretas: deliberações do órgão de gestão, políticas adotadas, protocolos de auditoria, responsabilidades atribuídas, formação concluída e medidas corretivas documentadas.

Em toda a UE: Modelos comuns de notificação de incidentes adotados

A 26 de maio de 2026, o Grupo de Cooperação NIS adotou modelos comuns para a notificação de incidentes da NIS2 na sua 39.ª reunião plenária, em Chipre. O Grupo reúne os Estados-Membros da UE, a Comissão Europeia e a ENISA.

Os modelos preveem um formato normalizado para a notificação de incidentes de cibersegurança em toda a UE. Até agora, a inexistência de um formato comum obrigava as organizações que operam em vários Estados-Membros a lidar com formulários, conjuntos de campos e portais de submissão nacionais distintos, o que representa um encargo administrativo considerável para qualquer operação transfronteiriça.

A Comissão indicou que pretende adotar estes modelos através de um ato de execução, que os tornaria obrigatórios em todos os Estados-Membros. Quando esse ato entrar em vigor, os modelos estabelecerão um quadro unificado de notificação de incidentes em toda a UE.

Esta evolução liga-se também à proposta mais ampla do Digital Omnibus, que inclui um ponto de entrada único para a notificação de incidentes. Os modelos comuns foram concebidos para se alinharem com essa futura arquitetura.

O que isto significa para o processo de resposta a incidentes: Se a equipa tiver criado fluxos de notificação com base no formulário atual de um Estado-Membro específico, esses fluxos terão de ser atualizados quando o ato de execução for publicado. Os prazos centrais da NIS2 previstos no artigo 23.º (alerta precoce em 24 horas, notificação do incidente em 72 horas, relatório final no prazo de um mês) não se alteram. O formato de submissão, sim.

ENISA NIS360 2026: Oito setores ainda em zona de risco

A ENISA publicou a terceira edição do seu relatório NIS360 a 28 de maio de 2026. O relatório avalia a maturidade em cibersegurança e a criticidade de todos os setores de elevada criticidade enumerados no anexo I da NIS2.

A avaliação de 2026 abrange todo o ecossistema de cada setor (autoridades nacionais, entidades regulamentadas e legislação da UE aplicável), e não organizações individuais. Identifica os setores em que a maturidade melhorou e aqueles em que a diferença entre a criticidade e a postura de segurança real continua grande.

Oito setores são identificados como zonas de risco: saúde, transportes ferroviários, transportes marítimos, gestão de serviços de TIC, espaço, administração pública, água potável e águas residuais. São setores em que as consequências de um ataque bem-sucedido são graves, mas em que a base de segurança do setor continua abaixo do que o nível de ameaça exige.

Para os responsáveis de TI e de segurança destes setores, a avaliação NIS360 é uma referência útil. Se o setor constar da lista de zonas de risco, é de esperar maior atenção supervisora por parte das autoridades nacionais competentes: não porque o relatório desencadeie diretamente medidas de aplicação, mas porque os reguladores utilizam os dados de maturidade por setor para definir prioridades nos seus calendários de auditoria e inspeção.

Luxemburgo: Lei da NIS2 em vigor, prazo de registo a 10 de julho de 2026

O Luxemburgo publicou a sua lei de transposição da NIS2 a 6 de maio de 2026 no Journal officiel du Grand-Duché de Luxembourg. A lei entrou em vigor a 10 de maio de 2026 e substituiu a lei NIS1 de 28 de maio de 2019.

Quem está abrangido

No Luxemburgo, a NIS2 aplica-se às organizações com 50 ou mais trabalhadores ou volume de negócios anual superior a 10 milhões de euros, que operem num dos 18 setores críticos. Os limiares de dimensão são avaliados ao nível do grupo consolidado: uma filial com 40 trabalhadores pode continuar abrangida se o grupo-mãe exceder os limiares.

A estrutura de dois níveis

Entidades essenciais: as organizações de grande dimensão dos setores do anexo I, com mais de 250 trabalhadores e um volume de negócios de 50 milhões de euros ou um balanço de 43 milhões de euros, estão sujeitas a supervisão proativa e a sanções até 10 milhões de euros ou 2 % do volume de negócios mundial. Entidades importantes: as organizações de média dimensão do anexo I e todas as entidades do anexo II que cumpram os critérios estão sujeitas a supervisão reativa e a sanções até 7 milhões de euros ou 1,4 % do volume de negócios mundial.

Os dois níveis têm de aplicar as mesmas dez categorias de medidas previstas no artigo 12.º: análise de riscos, tratamento de incidentes, continuidade das atividades, segurança da cadeia de abastecimento, desenvolvimento seguro, avaliação da eficácia, ciber-higiene, criptografia, controlo de acessos e autenticação multifator.

Prazos de notificação de incidentes

O Luxemburgo segue a estrutura do artigo 23.º da NIS2 na íntegra: alerta precoce em 24 horas, notificação formal em 72 horas, relatório final no prazo de um mês. O incumprimento de qualquer prazo constitui, por si só, uma infração sancionável.

O prazo de autorregisto de 10 de julho de 2026

As entidades têm até 10 de julho de 2026 para efetuar o autorregisto junto da respetiva autoridade competente. O ILR (Institut Luxembourgeois de Régulation) é a autoridade competente para a maioria dos setores; a CSSF supervisiona a banca e as infraestruturas dos mercados financeiros. A falta de registo é uma infração sancionável nos termos do artigo 11.º.

Os órgãos de gestão têm de aprovar formalmente as medidas de cibersegurança, supervisionar a sua execução e frequentar formação regularmente. No caso das entidades essenciais, os quadros superiores podem ficar sujeitos a uma proibição temporária de exercer funções de gestão em caso de falhas graves.

Países Baixos: Cyberbeveiligingswet chega à fase de plenário do Senado

A Câmara dos Representantes neerlandesa aprovou a Cyberbeveiligingswet (a lei de transposição da NIS2 dos Países Baixos) a 15 de abril de 2026, por 140 votos contra 10. O projeto de lei avançou agora para a fase de plenário do Senado.

Situação do projeto de lei

A Tweede Kamer aprovou o projeto com amplo apoio transpartidário; apenas dois partidos votaram contra. As comissões do Senado responsáveis pela digitalização e pela justiça concluíram a sua análise escrita a 19 de maio de 2026. Entretanto, o projeto passou à fase de plenário do Senado, onde aguarda votação final.

O projeto está a ser tratado em paralelo com legislação distinta que transpõe a Diretiva CER da UE relativa à resiliência das entidades críticas.

Contexto

Os Países Baixos apresentaram o projeto ao parlamento a 2 de junho de 2025, falhando o prazo de transposição da UE, 17 de outubro de 2024, em mais de um ano. O projeto esteve quase dez meses em tramitação na câmara baixa antes de ser aprovado.

Principais disposições

Em vez de criar uma autoridade nacional única de cibersegurança, a lei atribui a aplicação a reguladores setoriais já existentes: o regulador da energia para as empresas de energia, o regulador da saúde para os hospitais, e assim por diante. A data exata de entrada em vigor da lei será fixada por decreto governamental após a aprovação do Senado, e diferentes disposições podem produzir efeitos em datas diferentes.

O que se segue

A aprovação do Senado é o último passo legislativo. Depois de a votação ser aprovada e de o Governo fixar uma data de entrada em vigor, as organizações abrangidas ficarão sujeitas a obrigações de conformidade imediatas: medidas de gestão de riscos, notificação de incidentes e requisitos de responsabilização da gestão.

Irlanda: National Cyber Security Bill confirmada como instrumento da NIS2

Numa resposta parlamentar escrita à Dáil Éireann (a câmara baixa do parlamento irlandês) a 13 de maio de 2026, o ministro da Justiça, dos Assuntos Internos e da Migração da Irlanda confirmou que o Departamento da Justiça está a elaborar a National Cyber Security Bill como instrumento legislativo para a transposição da NIS2.

O projeto de lei consta como prioritário para publicação no programa legislativo do verão de 2026. Designará o National Cyber Security Centre (NCSC) como autoridade nacional competente e como equipa de resposta a incidentes de segurança informática da Irlanda (CSIRT). Conferirá também ao NCSC, pela primeira vez, um enquadramento legal: atualmente, o centro funciona sem base legislativa específica.

A Irlanda não cumpriu o prazo de transposição da UE de 17 de outubro de 2024. Uma decisão do Conselho de Ministros em julho de 2024 determinou a redação prioritária da legislação, e os trabalhos têm avançado desde então. O projeto de lei ainda não foi publicado, mas o Governo divulgou em setembro de 2024 o General Scheme da National Cyber Security Bill, que define a estrutura prevista.

Responsabilidade da gestão

Nos termos do artigo 20.º da NIS2, tal como refletido no Head 28 do General Scheme, os órgãos de gestão serão obrigados a aprovar e supervisionar as medidas de gestão dos riscos de cibersegurança e a frequentar formação regular em cibersegurança, podendo ainda incorrer em responsabilidade pessoal por incumprimentos, incluindo proibições temporárias e coimas administrativas. O General Scheme define «órgão de gestão» como «um órgão ou grupo de pessoas investido da autoridade e da responsabilidade pela supervisão, orientação e controlo de uma entidade».

Reguladores setoriais já em atividade

Os reguladores setoriais já foram designados autoridades nacionais competentes e preparam-se para assumir funções de supervisão e aplicação. Os portais de registo e de notificação de incidentes da NIS2 ainda não estão ativos (abrirão quando a legislação for promulgada), mas o NCSC publicou um projeto de orientações sobre medidas de gestão de riscos e o quadro Cyber Fundamentals (CyFun) para ajudar as organizações a preparar-se entretanto.

O projeto de lei está também a ser elaborado em conjunto com a terceira Estratégia Nacional de Cibersegurança da Irlanda, coordenada por um Comité Interdepartamental presidido pelo Departamento da Justiça.

Para as organizações com operações na Irlanda, a inexistência de legislação promulgada não elimina a obrigação de se preparar. As autoridades nacionais competentes setoriais já estão ativas e a promulgação do projeto de lei é descrita como uma prioridade do Governo.

DigitalEurope: A NIS2 continua a precisar de maior harmonização

A 13 de maio de 2026, a DigitalEurope publicou uma posição formal sobre o pacote de cibersegurança da UE, que abrange a proposta de Cybersecurity Act 2 (CSA2), o quadro de segurança da cadeia de abastecimento de TIC e as alterações específicas à NIS2.

Quanto à NIS2 em particular, a posição da DigitalEurope é direta: as alterações específicas propostas no pacote atual respondem «minimamente» às preocupações que o setor tem manifestado ao longo de vários anos. As áreas que exigem uma harmonização mais rigorosa são:

• Âmbito: A NIS2 deve centrar-se apenas nas atividades principais, excluindo as operações acessórias que criam obrigações desproporcionadas
• Limiares de dimensão: As divergências nacionais na aplicação dos limiares criam uma cobertura incoerente entre Estados-Membros
• Notificação de incidentes: Os campos de notificação, os prazos e os processos de submissão continuam a variar a nível nacional, um problema que os modelos comuns (ver acima) resolvem em parte
• Regras sobre o estabelecimento principal: As organizações que operam em vários Estados-Membros enfrentam incerteza quanto à autoridade nacional com competência primária
• Avaliação da conformidade: Os requisitos diferem consoante o Estado-Membro, o que cria complexidade de conformidade para as operações transfronteiriças

A DigitalEurope pediu também que a ENISA realize avaliações de impacto para toda a legislação da UE relevante em matéria de cibersegurança e coordene a implementação de forma mais ativa, posicionando a agência como centro de coordenação e não como um organismo meramente consultivo.

Para os responsáveis de conformidade que acompanham a trajetória regulamentar: as lacunas de harmonização identificadas pela DigitalEurope são pontos reais de fricção operacional. Os modelos comuns de notificação de incidentes adotados a 26 de maio são um passo para eliminar um deles. Os restantes exigirão atos de execução ou o processo de alteração da NIS2 para serem resolvidos.

O que isto significa agora para a equipa

Os desenvolvimentos de maio de 2026 seguem um padrão constante desde o início da aplicação: o texto da diretiva é estável, mas a camada de implementação nacional continua em movimento. O regime sancionatório pleno da Bulgária, o prazo de registo já em curso no Luxemburgo e a votação pendente no Senado neerlandês representam desencadeadores de conformidade concretos, cada um com uma data específica.

Os modelos comuns de notificação de incidentes são a evolução mais relevante do ponto de vista operacional a nível da UE no período. Quando o ato de execução da Comissão for publicado, o fluxo de notificação de incidentes de todas as organizações terá de ser atualizado para corresponder ao formato normalizado. Convém incluir essa atualização desde já no planeamento da resposta a incidentes, antes que um incidente real obrigue a fazê-lo sob pressão.

A lista de zonas de risco do NIS360 da ENISA merece ser levada a sério se a organização operar na saúde, na administração pública ou em qualquer outro dos setores assinalados. A atenção da supervisão acompanha as lacunas de maturidade, e a avaliação da ENISA influencia diretamente a forma como as autoridades nacionais competentes definem as prioridades dos seus calendários de auditoria.

Perguntas frequentes

O que aconteceu com a NIS2 em maio de 2026?

Maio de 2026 trouxe quatro desenvolvimentos significativos da NIS2: a lei de transposição do Luxemburgo entrou em vigor a 10 de maio; o Grupo de Cooperação NIS adotou modelos comuns de notificação de incidentes a 26 de maio; a ENISA publicou a avaliação da maturidade setorial NIS360 2026 a 28 de maio; e os Países Baixos fizeram avançar a Cyberbeveiligingswet na Câmara dos Representantes. A fase sancionatória plena da Bulgária começou a 1 de junho de 2026, logo a seguir ao período de maio.

Qual é o prazo de autorregisto da NIS2 no Luxemburgo?

A lei de transposição da NIS2 do Luxemburgo, que entrou em vigor a 10 de maio de 2026, exige que todas as entidades abrangidas efetuem o autorregisto junto da respetiva autoridade competente até 10 de julho de 2026. O ILR (Institut Luxembourgeois de Régulation) é a principal autoridade competente. A falta de registo é uma infração sancionável nos termos do artigo 11.º da lei de transposição.

Quais são os novos modelos de notificação de incidentes da NIS2?

A 26 de maio de 2026, o Grupo de Cooperação NIS adotou modelos comuns para a notificação de incidentes da NIS2 na sua 39.ª reunião plenária, em Chipre. Os modelos preveem um formato normalizado para a notificação de incidentes de cibersegurança em todos os Estados-Membros da UE. A Comissão Europeia pretende torná-los obrigatórios através de um ato de execução. Os prazos do artigo 23.º da NIS2 (alerta precoce em 24 horas, notificação em 72 horas, relatório final no prazo de um mês) mantêm-se inalterados.

Que setores identifica o NIS360 2026 da ENISA como de maior risco?

O relatório NIS360 2026 da ENISA, publicado a 28 de maio de 2026, identifica oito setores como zonas de risco em que a maturidade em cibersegurança continua baixa face à criticidade: saúde, transportes ferroviários, transportes marítimos, gestão de serviços de TIC, espaço, administração pública, água potável e águas residuais. Todos são setores do anexo I da NIS2 e estão sujeitos a supervisão proativa enquanto entidades essenciais.

Quais são as regras de responsabilidade pessoal dos gestores no âmbito da NIS2 na Bulgária?

Nos termos da Lei da Cibersegurança alterada da Bulgária, os membros do órgão de gestão das entidades essenciais e importantes ficam sujeitos a coimas pessoais de 500 a 5000 euros por incumprimento das obrigações de governação, independentemente das coimas aplicáveis às entidades. A partir de 1 de junho de 2026, estas coimas aplicam-se na totalidade dos montantes legais; a redução transitória de 50 % que se aplicava às infrações anteriores a junho deixou de existir. A autoridade competente pode ainda solicitar a um tribunal a proibição temporária de um gestor exercer funções de gestão.

Quantos Estados-Membros da UE transpuseram a NIS2?

No final de maio de 2026, 23 dos 27 Estados-Membros da UE tinham transposto a NIS2 para o direito nacional, segundo o levantamento de maio de 2026 da Cullen International. A transposição do Luxemburgo entrou em vigor a 10 de maio de 2026, o que elevou o total para 23. Quatro Estados-Membros continuam em processo legislativo, mais de 19 meses depois do prazo de transposição de outubro de 2024.

O que é a Cyberbeveiligingswet dos Países Baixos?

A Cyberbeveiligingswet é a legislação nacional dos Países Baixos que transpõe a NIS2. A Câmara dos Representantes neerlandesa aprovou o projeto de lei em 2026, depois de os Países Baixos terem falhado o prazo de transposição original da UE, outubro de 2024. O projeto ainda necessita da aprovação do Senado antes de poder entrar em vigor. O modelo neerlandês assenta numa estrutura de supervisão descentralizada, em que os reguladores setoriais tratam da aplicação.

Guia de conformidade com a NIS2: O roteiro da gestão de acessos para 2026

As credenciais roubadas dominam as violações de dados em 2026. O artigo 21.º da NIS2 determina 10 medidas de segurança para eliminar os vetores de ataque baseados em credenciais. O guia abrange os requisitos técnicos, a obrigação de notificação de incidentes em 24 horas, os níveis de MFA da ENISA e um roteiro em 5 fases para uma conformidade pronta para auditoria.

Passwork BlogAlex Muntyan

O Passwork distinguido como Top Performer Spring 2026 no SourceForge

O Passwork foi distinguido pelo SourceForge como Top Performer Spring 2026, tendo ficado entre os 10 % melhores de mais de 100 000 soluções. A distinção baseia-se exclusivamente em avaliações verificadas: 4,8 estrelas no geral e a classificação máxima de 5,0 em suporte.

Passwork BlogAlex Muntyan

Ataques de força bruta em 2026: Tipos, exemplos e como os prevenir

Clusters de GPU, listas de palavras assistidas por IA, botnets com 2,8 milhões de dispositivos. A força bruta ganhou escala. O guia abrange seis variantes de ataque, casos reais de 2025 e uma estratégia de defesa em camadas que a equipa pode implementar desde já.

Passwork BlogAlex Muntyan

Bulgariens NIS2-Übergangsfrist endete am 1. Juni 2026 — Vorstandsmitglieder sind nun mit vollen persönlichen Bußgeldern konfrontiert, nicht mehr mit dem ermäßigten Satz von 50 %, der bis Mai galt. Luxemburgs NIS2-Richtlinien-Umsetzungsgesetz trat am 10. Mai 2026 in Kraft, womit vier Mitgliedstaaten noch ohne Umsetzungsgesetzgebung verbleiben. Die NIS-Kooperationsgruppe der EU hat gemeinsame Vorlagen für die Vorfallmeldung verabschiedet, die die Kommission durch einen Durchführungsrechtsakt verbindlich machen will.

Dieser Artikel behandelt alle wesentlichen NIS2-Updates vom Mai 2026: was sich geändert hat, welche Fristen aktuell gelten und worauf Ihr Team jetzt reagieren muss.

Wichtigste Erkenntnisse

Diese NIS2-Updates vom Mai 2026 bringen konkrete Compliance-Auslöser mit sich: spezifische Daten und spezifische Verpflichtungen. Hier ist, was sich geändert hat.

• Bulgariens vollständiges Sanktionsregime ist aktiv. Ab dem 1. Juni 2026 gelten persönliche Bußgelder für Mitglieder von Leitungsorganen zu 100 % der gesetzlichen Beträge — bis zu 5.000 € pro Person, getrennt von Bußgeldern auf Unternehmensebene von bis zu 10 Millionen €. Der 50 %-Übergangsrabatt ist entfallen.
• Luxemburgs NIS2-Gesetz trat am 10. Mai 2026 in Kraft. Betroffene Einrichtungen haben bis zum 10. Juli 2026 Zeit, sich beim ILR selbst zu registrieren. Eine Nichtregistrierung stellt bereits einen sanktionsfähigen Verstoß dar.
• Vier EU-Mitgliedstaaten haben NIS2 noch nicht umgesetzt — mehr als 19 Monate nach der Frist vom Oktober 2024, laut dem Tracker von Cullen International vom Mai 2026.
• Gemeinsame Vorlagen für die Vorfallmeldung wurden EU-weit verabschiedet. Die NIS-Kooperationsgruppe einigte sich auf standardisierte Formate bei ihrer 39. Plenarsitzung in Zypern am 26. Mai 2026. Ein Durchführungsrechtsakt der Kommission wird diese verbindlich machen.
• Der NIS360 2026-Bericht von ENISA identifiziert acht Risikosektoren. Gesundheit, Eisenbahn, Seefahrt, ICT-Dienstleistungsmanagement, Raumfahrt, öffentliche Verwaltung, Trinkwasser und Abwasser weisen die niedrigste Cybersicherheitsreife im Verhältnis zu ihrer Kritikalität auf.
• Die Niederlande haben ihr verzögertes Cyberbeveiligingswet vorangebracht. Die niederländische Zweite Kammer stimmte dem Gesetzentwurf am 15. April 2026 zu; die Zustimmung des Senats steht noch aus.
• Irland bestätigte das National Cyber Security Bill als NIS2-Vehikel. Das Justizministerium erarbeitet die Gesetzgebung und verleiht dem NCSC eine gesetzliche Grundlage.
• DigitalEurope forderte eine tiefere NIS2-Harmonisierung. Der Branchenverband veröffentlichte eine formelle Stellungnahme, die Anwendungsbereich, Größenschwellen, Vorfallmeldung und Konformitätsbewertung als die Bereiche mit dem größten Standardisierungsbedarf über die Mitgliedstaaten hinweg identifiziert.

Bulgariens vollständige Durchsetzungsphase begann am 1. Juni 2026

Bulgariens NIS2-Durchsetzung ist am 1. Juni 2026 in ihre finale Phase eingetreten. Bußgelder und Sanktionen für alle Verstöße gelten nun in voller gesetzlicher Höhe — die 50 %-Ermäßigung für Verstöße vor diesem Datum ist entfallen.

Die zugrundeliegende Gesetzgebung ist das Gesetz zur Änderung und Ergänzung des Cybersicherheitsgesetzes, das von der 51. Nationalversammlung am 5. Februar 2026 verabschiedet und im Staatsanzeiger (Ausgabe 17) am 13. Februar 2026 verkündet wurde und am selben Tag in Kraft trat.

Wer ist betroffen

Das Cybersicherheitsgesetz erfasst öffentliche und private Einrichtungen in den Sektoren nach Anhang I und Anhang II, die die Schwellenwerte für mittlere Unternehmen erreichen oder überschreiten. Bestimmte Anbieter fallen unabhängig von ihrer Größe in den Anwendungsbereich: öffentliche elektronische Kommunikationsnetze, Vertrauensdiensteanbieter, Top-Level-Domain-Registrierungsstellen, DNS-Diensteanbieter, Einrichtungen, die der einzige Anbieter eines kritischen Dienstes in Bulgarien sind, oder deren Ausfall die öffentliche Ordnung, öffentliche Sicherheit oder Gesundheit oder die Wirtschaft erheblich beeinträchtigen würde.

Verwaltungsbehörden (einschließlich Gemeinden) werden gemäß Artikel 4a(1)(4) unabhängig von ihrer Größe als wesentliche Einrichtungen eingestuft.

Vollständige Durchsetzung ohne vollständiges Regelwerk

Eine praktische Komplikation bleibt bestehen. Das Gesetz delegiert die Definition von Mindestmaßnahmen für Cybersicherheit für bestimmte Einrichtungskategorien ausdrücklich an eine Sekundärverordnung des Ministerrats, die gemeinsam von der Kommission für Kommunikationsregulierung und dem Minister für E-Governance vorgeschlagen werden soll. Diese Verordnung wurde noch nicht veröffentlicht. Organisationen traten in die vollständige Durchsetzungsphase ein, ohne das vollständige operative Regelwerk, das das Gesetz selbst vorgesehen hatte.

Das setzt die Verpflichtungen nicht aus. Das Primärgesetz ist in Kraft, Sanktionen sind real. Eine Gap-Analyse gegen das bestehende NIS2-Framework ist jetzt sowohl möglich als auch ratsam, bevor der aufsichtliche Druck zunimmt. ISO/IEC 27001 und ISO 22301 bieten eine praktikable Grundlage neben den Anforderungen des Cybersicherheitsgesetzes.

Was Leitungsorgane nun nachweisen müssen

Bulgariens Cybersicherheitsgesetz legt eine ausdrückliche persönliche Verantwortlichkeit auf einzelne Mitglieder von Leitungsorganen, nicht nur auf die Organisation als juristische Person. Leitungsorgane müssen:

• Die nach Artikel 21 erforderlichen Maßnahmen zum Cybersicherheits-Risikomanagement formell genehmigen
• Die Umsetzung dieser Maßnahmen überwachen
• Mindestens alle zwei Jahre eine Cybersicherheitsschulung absolvieren
• Regelmäßig gleichwertige Schulungen für Mitarbeiter organisieren

Die Maßnahmen, die Vorstände genehmigen müssen, umfassen Risikoanalyse und Informationssicherheitsrichtlinien, Vorfallbehandlung, Geschäftskontinuität und Krisenmanagement, Lieferkettensicherheit, Cyberhygiene-Praktiken und Multi-Faktor-Authentifizierung, wo angemessen.

Die Struktur persönlicher Bußgelder

Wenn ein Mitglied des Leitungsorgans einer wesentlichen oder wichtigen Einrichtung gegen diese Governance-Pflichten verstößt, kann ein persönliches Bußgeld von 500 € bis 5.000 € verhängt werden. Dies ist getrennt von Sanktionen auf Unternehmensebene und kumuliert sich zu diesen: bis zu 10 Millionen € oder 2 % des weltweiten Umsatzes für wesentliche Einrichtungen und bis zu 7 Millionen € oder 1,4 % für wichtige Einrichtungen.

Die zuständige nationale Behörde kann auch bei Gericht beantragen, dass einer natürlichen Person vorübergehend die Ausübung von Leitungsfunktionen in einer wesentlichen Einrichtung untersagt wird.

Die praktische Konsequenz: Ein Vorstandsmitglied kann sich nicht durch Delegation aus der Haftung befreien. Ob ein Bußgeld verhängt wird und wie schwer es ausfällt, hängt von der Fähigkeit der Person ab, konkrete Handlungen nachzuweisen — Vorstandsbeschlüsse, verabschiedete Richtlinien, Auditprotokolle, zugewiesene Verantwortlichkeiten, absolvierte Schulungen und dokumentierte Korrekturmaßnahmen.

EU-weit: Gemeinsame Vorlagen für die Vorfallmeldung verabschiedet

Am 26. Mai 2026 verabschiedete die NIS-Kooperationsgruppe bei ihrer 39. Plenarsitzung in Zypern gemeinsame Vorlagen für die NIS2-Vorfallmeldung. Die Gruppe bringt EU-Mitgliedstaaten, die Europäische Kommission und ENISA zusammen.

Die Vorlagen bieten ein standardisiertes Format für die Meldung von Cybervorfällen in der gesamten EU. Bis jetzt bedeutete das Fehlen eines gemeinsamen Formats, dass Organisationen, die in mehreren Mitgliedstaaten tätig sind, mit unterschiedlichen nationalen Meldeformularen, Feldsätzen und Einreichungsportalen umgehen mussten — eine erhebliche administrative Belastung für jeden grenzüberschreitenden Betrieb.

Die Kommission hat erklärt, dass sie plant, diese Vorlagen durch einen Durchführungsrechtsakt zu verabschieden, wodurch sie für alle Mitgliedstaaten verbindlich würden. Sobald dieser Rechtsakt in Kraft ist, werden die Vorlagen einen einheitlichen Rahmen für die Vorfallmeldung in der gesamten EU etablieren.

Diese Entwicklung steht auch im Zusammenhang mit dem breiteren Digital-Omnibus-Vorschlag, der einen einzigen Zugangspunkt für die Vorfallmeldung vorsieht. Die gemeinsamen Vorlagen sind darauf ausgelegt, mit dieser zukünftigen Architektur übereinzustimmen.

Was das für Ihren Incident-Response-Prozess bedeutet: Wenn Ihr Team Benachrichtigungs-Workflows um das aktuelle Formular eines bestimmten Mitgliedstaats herum aufgebaut hat, ist damit zu rechnen, dass diese Workflows aktualisiert werden müssen, sobald der Durchführungsrechtsakt veröffentlicht wird. Die grundlegenden NIS2-Compliance-Zeitvorgaben gemäß Artikel 23 (24-Stunden-Frühwarnung, 72-Stunden-Vorfallmeldung, Ein-Monats-Abschlussbericht) ändern sich nicht. Das Format für deren Einreichung jedoch schon.

ENISA NIS360 2026: Acht Sektoren noch in der Risikozone

ENISA veröffentlichte die dritte Ausgabe ihres NIS360-Berichts am 28. Mai 2026. Der Bericht bewertet die Cybersicherheitsreife und Kritikalität in allen Sektoren von hoher Kritikalität, die in Anhang I von NIS2 aufgeführt sind.

Die Bewertung 2026 umfasst das gesamte Ökosystem jedes Sektors (nationale Behörden, regulierte Einrichtungen und anwendbare EU-Gesetzgebung) anstatt einzelner Organisationen. Sie identifiziert Sektoren, in denen sich die Reife verbessert hat, und Sektoren, in denen die Lücke zwischen Kritikalität und tatsächlicher Sicherheitslage noch groß ist.

Acht Sektoren werden als Risikozonen identifiziert: Gesundheit, Eisenbahn, Seefahrt, ICT-Dienstleistungsmanagement, Raumfahrt, öffentliche Verwaltung, Trinkwasser und Abwasser. Dies sind Sektoren, in denen die Folgen eines erfolgreichen Angriffs schwerwiegend sind, aber das Sicherheitsniveau im gesamten Sektor unter dem bleibt, was das Bedrohungsniveau erfordert.

Für IT- und Sicherheitsverantwortliche in diesen Sektoren ist die NIS360-Bewertung ein nützlicher Benchmark. Wenn Ihr Sektor auf der Risikozonenliste erscheint, ist mit erhöhter aufsichtlicher Aufmerksamkeit seitens der nationalen zuständigen Behörden zu rechnen — nicht weil der Bericht direkt eine Durchsetzung auslöst, sondern weil Regulierungsbehörden sektorale Reifedaten nutzen, um ihre Audit- und Inspektionskalender zu priorisieren.

Luxemburg: NIS2-Gesetz in Kraft, Registrierungsfrist ist der 10. Juli 2026

Luxemburg veröffentlichte sein NIS2-Umsetzungsgesetz am 6. Mai 2026 im Journal officiel du Grand-Duché de Luxembourg. Das Gesetz trat am 10. Mai 2026 in Kraft und ersetzt das NIS1-Gesetz vom 28. Mai 2019.

Wer ist betroffen

NIS2 gilt in Luxemburg für Organisationen mit 50 oder mehr Mitarbeitern oder einem Jahresumsatz von über 10 Millionen €, die in einem von 18 kritischen Sektoren tätig sind. Größenschwellen werden auf konsolidierter Konzernebene bewertet: Eine Tochtergesellschaft mit 40 Mitarbeitern kann dennoch betroffen sein, wenn der Mutterkonzern die Schwellenwerte überschreitet.

Die zweistufige Struktur

Wesentliche Einrichtungen — große Organisationen in Anhang-I-Sektoren mit mehr als 250 Mitarbeitern und entweder 50 Millionen € Umsatz oder 43 Millionen € Bilanzsumme — unterliegen proaktiver Aufsicht und Sanktionen von bis zu 10 Millionen € oder 2 % des weltweiten Umsatzes. Wichtige Einrichtungen — mittelgroße Anhang-I-Organisationen und alle qualifizierenden Anhang-II-Einrichtungen — unterliegen reaktiver Aufsicht und Sanktionen von bis zu 7 Millionen € oder 1,4 % des weltweiten Umsatzes.

Beide Stufen müssen dieselben zehn Maßnahmenkategorien gemäß Artikel 12 umsetzen: Risikoanalyse, Vorfallbehandlung, Geschäftskontinuität, Lieferkettensicherheit, sichere Entwicklung, Wirksamkeitsbewertung, Cyberhygiene, Kryptografie, Zugangskontrolle und Multi-Faktor-Authentifizierung.

Zeitrahmen für die Vorfallmeldung

Luxemburg folgt exakt der Struktur von NIS2 Artikel 23: 24-Stunden-Frühwarnung, 72-Stunden-formelle Meldung, Ein-Monats-Abschlussbericht. Das Versäumen einer Frist ist selbst ein sanktionsfähiger Verstoß.

Die Selbstregistrierungsfrist am 10. Juli 2026

Einrichtungen haben bis zum 10. Juli 2026 Zeit, sich bei ihrer zuständigen Behörde selbst zu registrieren. Das ILR (Institut Luxembourgeois de Régulation) fungiert als zuständige Behörde für die meisten Sektoren; die CSSF überwacht das Bank- und Finanzmarktinfrastrukturwesen. Nichtregistrierung ist ein sanktionsfähiger Verstoß gemäß Artikel 11.

Leitungsorgane müssen Cybersicherheitsmaßnahmen formell genehmigen, deren Umsetzung überwachen und regelmäßige Schulungen absolvieren. Für wesentliche Einrichtungen können leitende Führungskräfte bei schwerwiegenden Versäumnissen mit einem vorübergehenden Verbot der Ausübung von Leitungsfunktionen belegt werden.

Niederlande: Cyberbeveiligingswet erreicht Senats-Plenarphase

Die niederländische Zweite Kammer stimmte dem Cyberbeveiligingswet (dem niederländischen NIS2-Umsetzungsgesetz) am 15. April 2026 mit 140 zu 10 Stimmen zu. Der Gesetzentwurf ist nun in die Senats-Plenarphase vorgerückt.

Stand des Gesetzentwurfs

Die Tweede Kamer verabschiedete den Gesetzentwurf mit breiter fraktionsübergreifender Unterstützung; nur zwei Parteien stimmten dagegen. Die für Digitalisierung und Justiz zuständigen Senatsausschüsse schlossen ihre schriftliche Prüfung am 19. Mai 2026 ab. Der Gesetzentwurf ist seitdem in die Senats-Plenarphase übergegangen, wo er auf eine Schlussabstimmung wartet.

Der Gesetzentwurf wird parallel zu separater Gesetzgebung zur Umsetzung der EU-CER-Richtlinie zur Resilienz kritischer Einrichtungen bearbeitet.

Hintergrund

Die Niederlande reichten den Gesetzentwurf am 2. Juni 2025 beim Parlament ein und verfehlten damit die EU-Umsetzungsfrist vom 17. Oktober 2024 um über ein Jahr. Der Gesetzentwurf verbrachte fast zehn Monate im Verfahren der Zweiten Kammer, bevor er verabschiedet wurde.

Zentrale Bestimmungen

Anstatt eine einzige nationale Cybersicherheitsbehörde zu schaffen, überträgt das Gesetz die Durchsetzung auf bestehende sektorspezifische Regulierungsbehörden — die Energieregulierungsbehörde für Energieunternehmen, die Gesundheitsregulierungsbehörde für Krankenhäuser und so weiter. Das genaue Datum des Inkrafttretens des Gesetzes wird nach der Senatszustimmung per Regierungserlass festgelegt, und verschiedene Bestimmungen können zu unterschiedlichen Zeitpunkten in Kraft treten.

Was als Nächstes kommt

Die Senatszustimmung ist der letzte legislative Schritt. Sobald die Abstimmung erfolgt ist und die Regierung ein Datum des Inkrafttretens festlegt, werden betroffene Organisationen mit sofortigen Compliance-Verpflichtungen konfrontiert — Risikomanagementmaßnahmen, Vorfallmeldung und Anforderungen an die Verantwortlichkeit des Managements.

Irland: National Cyber Security Bill als NIS2-Vehikel bestätigt

In einer schriftlichen parlamentarischen Antwort an das Dáil Éireann (das Unterhaus des irischen Parlaments) am 13. Mai 2026 bestätigte Irlands Minister für Justiz, Inneres und Migration, dass das Justizministerium das National Cyber Security Bill als gesetzliches Vehikel für die NIS2-Umsetzung erarbeitet.

Das Gesetz ist als Priorität für die Veröffentlichung im Gesetzgebungsprogramm Sommer 2026 aufgeführt. Es wird das National Cyber Security Centre (NCSC) als nationale zuständige Behörde und als Irlands Computer Security Incident Response Team (CSIRT) benennen. Es wird das NCSC auch erstmals auf eine gesetzliche Grundlage stellen — das Zentrum arbeitet derzeit ohne eine eigene legislative Basis.

Irland verfehlte die EU-Umsetzungsfrist vom 17. Oktober 2024. Eine Kabinettsentscheidung im Juli 2024 wies die vorrangige Erarbeitung der Gesetzgebung an, und die Arbeiten sind seitdem im Gange. Der Gesetzesentwurf wurde noch nicht veröffentlicht, aber die Regierung veröffentlichte im September 2024 das General Scheme des National Cyber Security Bill, das dessen beabsichtigte Struktur darlegt.

Managementhaftung

Gemäß NIS2 Artikel 20, wie in Head 28 des General Scheme widergespiegelt, müssen Leitungsgremien Cybersicherheits-Risikomanagementmaßnahmen genehmigen und überwachen, regelmäßige Cybersicherheitsschulungen absolvieren und können bei Compliance-Versäumnissen persönlich haftbar gemacht werden — einschließlich vorübergehender Verbote und Verwaltungsbußgelder. Das General Scheme definiert „Leitungsgremium" als „ein Gremium oder eine Gruppe von Einzelpersonen, die mit der Befugnis und Verantwortung für die Aufsicht, Leitung und Kontrolle einer Einrichtung betraut sind".

Sektorregulierungsbehörden bereits aktiv

Sektorregulierungsbehörden wurden bereits als Nationale Zuständige Behörden benannt und bereiten sich darauf vor, Aufsichts- und Durchsetzungsfunktionen zu übernehmen. Die NIS2-Registrierungs- und Vorfallmeldeportale sind noch nicht live — sie werden nach Inkrafttreten der Gesetzgebung eröffnet — aber das NCSC hat Entwürfe von Leitlinien zu Risikomanagementmaßnahmen und das Cyber Fundamentals (CyFun) Framework veröffentlicht, um Organisationen bei der Vorbereitung in der Zwischenzeit zu unterstützen.

Das Gesetz wird auch parallel zur dritten nationalen Cybersicherheitsstrategie Irlands entwickelt, koordiniert durch ein interministerielles Komitee unter dem Vorsitz des Justizministeriums.

Für Organisationen mit irischen Niederlassungen bedeutet das Fehlen einer erlassenen Gesetzgebung nicht, dass die Vorbereitungspflicht entfällt. Sektorale NCAs sind bereits aktiv, und der Erlass des Gesetzes wird als Regierungspriorität bezeichnet.

DigitalEurope: NIS2 braucht noch tiefere Harmonisierung

Am 13. Mai 2026 veröffentlichte DigitalEurope eine formelle Stellungnahme zum EU-Cybersicherheitspaket, das den vorgeschlagenen Cybersecurity Act 2 (CSA2), das ICT-Lieferkettensicherheits-Framework und gezielte NIS2-Änderungen umfasst.

Speziell zu NIS2 ist DigitalEuropes Position direkt: Die im aktuellen Paket vorgeschlagenen gezielten Änderungen reagieren „minimal" auf die Bedenken, die die Industrie seit mehreren Jahren geäußert hat. Die Bereiche, die eine strengere Harmonisierung erfordern, sind:

• Anwendungsbereich: NIS2 sollte sich nur auf Kerngeschäftsaktivitäten konzentrieren und Nebentätigkeiten ausschließen, die unverhältnismäßige Verpflichtungen schaffen.
• Größenschwellen: Nationale Unterschiede in der Anwendung der Schwellenwerte führen zu inkonsistenter Abdeckung über die Mitgliedstaaten hinweg.
• Vorfallmeldung: Meldefelder, Zeitrahmen und Einreichungsprozesse variieren noch auf nationaler Ebene — ein Problem, das die gemeinsamen Vorlagen (siehe oben) teilweise angehen.
• Regelungen zur Hauptniederlassung: Organisationen, die in mehreren Mitgliedstaaten tätig sind, sind mit Unsicherheit darüber konfrontiert, welche nationale Behörde die primäre Zuständigkeit hat.
• Konformitätsbewertung: Die Anforderungen unterscheiden sich je nach Mitgliedstaat, was Compliance-Komplexität für grenzüberschreitende Operationen schafft.

DigitalEurope forderte außerdem, dass ENISA Folgenabschätzungen für alle relevanten EU-Cybersicherheitsgesetze durchführt und die Umsetzung aktiver koordiniert — um die Agentur als Koordinierungszentrum zu positionieren, anstatt als rein beratende Stelle.

Für Compliance-Verantwortliche, die den regulatorischen Verlauf verfolgen: Die von DigitalEurope identifizierten Harmonisierungslücken sind echte operative Reibungspunkte. Die am 26. Mai verabschiedeten gemeinsamen Vorlagen für die Vorfallmeldung sind ein Schritt zur Schließung einer davon. Die anderen erfordern entweder die Durchführungsrechtsakte oder das NIS2-Änderungsverfahren zur Lösung.

Was das jetzt für Ihr Team bedeutet

Die Entwicklungen vom Mai 2026 folgen einem Muster, das seit Beginn der Durchsetzung konsistent ist: Der Text der Richtlinie ist stabil, aber die nationale Umsetzungsebene bewegt sich weiter. Bulgariens vollständige Sanktionsphase, Luxemburgs live geltende Registrierungsfrist und die ausstehende Senatsabstimmung in den Niederlanden stellen alle konkrete Compliance-Auslöser dar, jeweils mit einem nun festgelegten spezifischen Datum.

Die gemeinsamen Vorlagen für die Vorfallmeldung sind die operativ bedeutsamste EU-weite Entwicklung des Zeitraums. Sobald der Durchführungsrechtsakt der Kommission veröffentlicht wird, muss der Workflow für Vorfallmeldungen jeder Organisation aktualisiert werden, um dem standardisierten Format zu entsprechen. Planen Sie diese Aktualisierung jetzt in Ihre Incident-Response-Planung ein, bevor Sie ein tatsächlicher Vorfall dazu zwingt, dies unter Druck zu tun.

Die ENISA NIS360-Risikozonenliste ist es wert, ernst genommen zu werden, wenn Ihre Organisation im Gesundheitswesen, in der öffentlichen Verwaltung oder in einem der anderen markierten Sektoren tätig ist. Aufsichtliche Aufmerksamkeit folgt Reifelücken — und ENISAs Bewertung fließt direkt in die Priorisierung der Audit-Kalender der nationalen zuständigen Behörden ein.

Häufig gestellte Fragen

Was ist im Mai 2026 mit NIS2 passiert?

Im Mai 2026 gab es vier bedeutende NIS2-Entwicklungen: Luxemburgs Umsetzungsgesetz trat am 10. Mai in Kraft; die NIS-Kooperationsgruppe verabschiedete am 26. Mai gemeinsame Vorlagen für die Vorfallmeldung; ENISA veröffentlichte am 28. Mai die NIS360 2026-Sektorreifebewertung; und die Niederlande brachten ihr Cyberbeveiligingswet durch die Zweite Kammer. Bulgariens vollständige Sanktionsphase begann am 1. Juni 2026, direkt nach dem Mai-Zeitraum.

Was ist die Luxemburger NIS2-Selbstregistrierungsfrist?

Luxemburgs NIS2-Umsetzungsgesetz, das am 10. Mai 2026 in Kraft trat, verlangt von allen betroffenen Einrichtungen, sich bis zum 10. Juli 2026 bei ihrer zuständigen Behörde selbst zu registrieren. Das ILR (Institut Luxembourgeois de Régulation) ist die primäre zuständige Behörde. Nichtregistrierung ist ein sanktionsfähiger Verstoß gemäß Artikel 11 des Umsetzungsgesetzes.

Was sind die neuen NIS2-Vorlagen für die Vorfallmeldung?

Am 26. Mai 2026 verabschiedete die NIS-Kooperationsgruppe bei ihrer 39. Plenarsitzung in Zypern gemeinsame Vorlagen für die NIS2-Vorfallmeldung. Die Vorlagen bieten ein standardisiertes Format für die Meldung von Cybervorfällen in allen EU-Mitgliedstaaten. Die Europäische Kommission plant, diese durch einen Durchführungsrechtsakt verbindlich zu machen. Die zugrundeliegenden Zeitrahmen gemäß NIS2 Artikel 23 — 24-Stunden-Frühwarnung, 72-Stunden-Meldung, Ein-Monats-Abschlussbericht — bleiben unverändert.

Welche Sektoren identifiziert ENISAs NIS360 2026 als höchstes Risiko?

Der NIS360 2026-Bericht von ENISA, veröffentlicht am 28. Mai 2026, identifiziert acht Sektoren als Risikozonen, in denen die Cybersicherheitsreife im Verhältnis zur Kritikalität niedrig bleibt: Gesundheit, Eisenbahn, Seefahrt, ICT-Dienstleistungsmanagement, Raumfahrt, öffentliche Verwaltung, Trinkwasser und Abwasser. Dies sind alles Anhang-I-Sektoren unter NIS2 und unterliegen als wesentliche Einrichtungen proaktiver Aufsicht.

Was sind die persönlichen Haftungsregeln für Manager unter Bulgariens NIS2?

Gemäß Bulgariens geändertem Cybersicherheitsgesetz drohen Mitgliedern des Leitungsorgans wesentlicher und wichtiger Einrichtungen persönliche Bußgelder von 500 € bis 5.000 € bei Verstoß gegen ihre Governance-Pflichten — getrennt von Bußgeldern auf Unternehmensebene. Ab dem 1. Juni 2026 gelten diese Bußgelder in voller gesetzlicher Höhe; der 50 %-Übergangsrabatt, der für Verstöße vor Juni galt, existiert nicht mehr. Die zuständige Behörde kann auch ein gerichtlich angeordnetes vorübergehendes Verbot der Ausübung von Leitungsfunktionen für einen Manager beantragen.

Wie viele EU-Mitgliedstaaten haben NIS2 umgesetzt?

Bis Ende Mai 2026 haben 23 von 27 EU-Mitgliedstaaten NIS2 in nationales Recht umgesetzt, laut dem Tracker von Cullen International vom Mai 2026. Luxemburgs Umsetzung trat am 10. Mai 2026 in Kraft und brachte die Gesamtzahl auf 23. Vier Mitgliedstaaten befinden sich noch im Gesetzgebungsprozess, mehr als 19 Monate nach der Umsetzungsfrist vom Oktober 2024.

Was ist das niederländische Cyberbeveiligingswet?

Das Cyberbeveiligingswet ist die nationale Gesetzgebung der Niederlande zur Umsetzung von NIS2. Die niederländische Zweite Kammer stimmte dem Gesetzentwurf 2026 zu, nachdem die Niederlande die ursprüngliche EU-Umsetzungsfrist vom Oktober 2024 verpasst hatten. Der Gesetzentwurf erfordert noch die Senatszustimmung, bevor er in Kraft treten kann. Das niederländische Modell verwendet eine dezentralisierte Aufsichtsstruktur, bei der sektorspezifische Regulierungsbehörden die Durchsetzung übernehmen.

NIS2-Compliance-Leitfaden: Die Zugangsmanagement-Roadmap für 2026

Gestohlene Zugangsdaten dominieren Sicherheitsverletzungen im Jahr 2026. NIS2 Artikel 21 schreibt 10 Sicherheitsmaßnahmen vor, um Angriffsvektoren auf Basis von Zugangsdaten zu eliminieren. Dieser Leitfaden behandelt technische Anforderungen, die 24-Stunden-Vorfallmeldepflicht, ENISAs MFA-Stufen und eine 5-Phasen-Roadmap zur auditbereiten Compliance.

Passwork BlogAlex Muntyan

Passwork gewinnt Top Performer Frühjahr 2026 auf SourceForge

Passwork wurde von SourceForge als Top Performer Frühjahr 2026 ausgezeichnet und rangiert damit unter den besten 10 % von über 100.000 Lösungen. Das Abzeichen basiert ausschließlich auf verifizierten Bewertungen — 4,8 Sterne insgesamt, mit perfekten 5,0 für Support.

Passwork BlogAlex Muntyan

Brute-Force-Angriffe 2026: Arten, Beispiele und wie Sie sich schützen

GPU-Cluster, KI-gestützte Wortlisten, Botnets mit 2,8 Millionen Geräten. Brute Force ist skaliert. Dieser Leitfaden behandelt sechs Angriffsvarianten, reale Fälle aus 2025 und eine mehrschichtige Verteidigungsstrategie, die Ihr Team heute umsetzen kann.

Passwork BlogAlex Muntyan

El período de gracia de NIS2 en Bulgaria finalizó el 1 de junio de 2026 — los miembros del consejo de administración ahora enfrentan multas personales completas, no la tasa reducida del 50% que se aplicaba hasta mayo. La ley de transposición de la Directiva NIS2 de Luxemburgo entró en vigor el 10 de mayo de 2026, dejando a cuatro estados miembros todavía sin legislación de implementación. El Grupo de Cooperación NIS de la UE adoptó plantillas comunes de notificación de incidentes que la Comisión tiene previsto hacer obligatorias mediante un acto de ejecución.

Este artículo cubre todas las actualizaciones importantes de NIS2 de mayo de 2026: qué cambió, qué plazos están vigentes y qué debe hacer su equipo ahora.

Puntos clave

Estas actualizaciones de NIS2 de mayo de 2026 conllevan desencadenantes concretos de cumplimiento: fechas específicas y obligaciones específicas. Esto es lo que cambió.

• El régimen de sanciones completo de Bulgaria está activo. Desde el 1 de junio de 2026, las multas personales para los miembros del órgano de dirección se aplican al 100% de los importes legales — hasta 5.000 € por individuo, separadas de las multas a nivel de entidad de hasta 10 millones de €. El descuento transitorio del 50% ha desaparecido.
• La ley NIS2 de Luxemburgo entró en vigor el 10 de mayo de 2026. Las entidades dentro del ámbito de aplicación tienen hasta el 10 de julio de 2026 para autoregistrarse en el ILR. El no registro es en sí mismo una infracción sancionable.
• Cuatro estados miembros de la UE aún no han transpuesto NIS2 — más de 19 meses después del plazo de octubre de 2024, según el rastreador de mayo de 2026 de Cullen International.
• Se adoptaron plantillas comunes de notificación de incidentes en toda la UE. El Grupo de Cooperación NIS acordó formatos estandarizados en su 39ª reunión plenaria en Chipre el 26 de mayo de 2026. Un acto de ejecución de la Comisión las hará obligatorias.
• El informe NIS360 2026 de ENISA identifica ocho sectores en zona de riesgo. Salud, ferrocarril, marítimo, gestión de servicios TIC, espacio, administración pública, agua potable y aguas residuales muestran la madurez en ciberseguridad más baja en relación con su criticidad.
• Los Países Bajos avanzaron en su retrasada Cyberbeveiligingswet. La Cámara de Representantes neerlandesa aprobó el proyecto de ley el 15 de abril de 2026; la aprobación del Senado aún está pendiente.
• Irlanda confirmó el proyecto de ley de Seguridad Cibernética Nacional como su vehículo NIS2. El Departamento de Justicia está redactando la legislación y estableciendo al NCSC sobre una base estatutaria.
• DigitalEurope pidió una armonización más profunda de NIS2. El organismo de la industria publicó una posición formal identificando el ámbito de aplicación, los umbrales de tamaño, la notificación de incidentes y la evaluación de conformidad como las áreas que más necesitan estandarización entre los estados miembros.

La fase de aplicación completa de Bulgaria comenzó el 1 de junio de 2026

La aplicación de NIS2 en Bulgaria entró en su fase final el 1 de junio de 2026. Las multas y sanciones por todas las infracciones ahora se aplican en sus importes legales completos — la reducción del 50% que se aplicaba a las violaciones cometidas antes de esa fecha ha desaparecido.

La legislación subyacente es la Ley de Modificación y Complemento de la Ley de Ciberseguridad, adoptada por la 51ª Asamblea Nacional el 5 de febrero de 2026 y promulgada en el Boletín Oficial del Estado (número 17) el 13 de febrero de 2026, entrando en vigor en la misma fecha.

Quién está dentro del ámbito de aplicación

La Ley de Ciberseguridad cubre a entidades públicas y privadas en sectores del Anexo I y Anexo II que cumplen o superan los umbrales de mediana empresa. Ciertos proveedores están dentro del ámbito independientemente del tamaño: redes públicas de comunicaciones electrónicas, proveedores de servicios de confianza, registros de dominios de nivel superior, proveedores de servicios DNS, entidades que son el único proveedor de un servicio crítico en Bulgaria, o cuya interrupción afectaría significativamente al orden público, la seguridad pública o la salud, o la economía.

Los organismos administrativos (incluidos los municipios) se clasifican como entidades esenciales según el Artículo 4a(1)(4), independientemente del tamaño.

Aplicación completa sin un reglamento completo

Queda una complicación práctica. La ley delega explícitamente la definición de medidas mínimas de ciberseguridad para ciertas categorías de entidades a una ordenanza secundaria del Consejo de Ministros, que será propuesta conjuntamente por la Comisión de Regulación de Comunicaciones y el Ministro de Gobernanza Electrónica. Esa ordenanza aún no se ha publicado. Las organizaciones entraron en la fase de aplicación completa sin el reglamento operativo completo que la propia ley anticipaba.

Esto no suspende las obligaciones. La ley principal está en vigor, las sanciones son reales. El análisis de brechas contra el marco NIS2 existente es posible y aconsejable ahora, antes de que aumente la presión supervisora. ISO/IEC 27001 e ISO 22301 proporcionan una base de referencia viable junto con los requisitos de la Ley de Ciberseguridad.

Lo que los órganos de dirección deben demostrar ahora

La Ley de Ciberseguridad de Bulgaria establece una responsabilidad personal explícita para los miembros individuales de los órganos de dirección, no solo para la organización como entidad legal. Los órganos de dirección deben:

• Aprobar formalmente las medidas de gestión de riesgos de ciberseguridad requeridas según el Artículo 21
• Supervisar la implementación de dichas medidas
• Completar formación en ciberseguridad al menos cada dos años
• Organizar formación equivalente para los empleados de forma regular

Las medidas que los consejos deben aprobar cubren el análisis de riesgos y las políticas de seguridad de la información, la gestión de incidentes, la continuidad del negocio y la gestión de crisis, la seguridad de la cadena de suministro, las prácticas de higiene cibernética y la autenticación multifactor cuando sea apropiado.

La estructura de multas personales

Cuando un miembro del órgano de dirección de una entidad esencial o importante incumple estas obligaciones de gobernanza, puede imponerse una multa personal de 500 € a 5.000 €. Esto es independiente de las sanciones a nivel de entidad y se suma a ellas: hasta 10 millones de € o el 2% de la facturación global para entidades esenciales, y hasta 7 millones de € o el 1,4% para entidades importantes.

La autoridad nacional competente también puede solicitar a un tribunal que imponga una prohibición temporal a una persona física para ejercer funciones de dirección en una entidad esencial.

La implicación práctica: un miembro del consejo no puede delegar su responsabilidad. Si se impone una multa, y su gravedad, dependerá de la capacidad del individuo para demostrar acciones tangibles — resoluciones del consejo, políticas adoptadas, protocolos de auditoría, responsabilidades asignadas, formación completada y medidas correctivas documentadas.

A nivel de la UE: Se adoptan plantillas comunes de notificación de incidentes

El 26 de mayo de 2026, el Grupo de Cooperación NIS adoptó plantillas comunes para la notificación de incidentes NIS2 en su 39ª reunión plenaria en Chipre. El Grupo reúne a los estados miembros de la UE, la Comisión Europea y ENISA.

Las plantillas proporcionan un formato estandarizado para notificar incidentes cibernéticos en toda la UE. Hasta ahora, la ausencia de un formato común significaba que las organizaciones que operaban en múltiples estados miembros tenían que navegar por diferentes formularios de notificación nacionales, conjuntos de campos y portales de envío — una carga administrativa significativa para cualquier operación transfronteriza.

La Comisión ha declarado que planea adoptar estas plantillas mediante un acto de ejecución, lo que las haría obligatorias para todos los estados miembros. Una vez que ese acto entre en vigor, las plantillas establecerán un marco unificado de notificación de incidentes en toda la UE.

Este desarrollo también se conecta con la propuesta más amplia del Digital Omnibus, que incluye un punto único de entrada para la notificación de incidentes. Las plantillas comunes están diseñadas para alinearse con esa arquitectura futura.

Lo que esto significa para su proceso de respuesta a incidentes: Si su equipo ha construido flujos de trabajo de notificación en torno al formulario actual de un estado miembro específico, espere que esos flujos de trabajo se actualicen una vez que se publique el acto de ejecución. Las obligaciones básicas del cronograma de cumplimiento de NIS2 según el Artículo 23 (alerta temprana de 24 horas, notificación de incidentes de 72 horas, informe final de un mes) no cambian. El formato para presentarlas sí cambia.

ENISA NIS360 2026: Ocho sectores todavía en la zona de riesgo

ENISA publicó la tercera edición de su informe NIS360 el 28 de mayo de 2026. El informe evalúa la madurez en ciberseguridad y la criticidad en todos los sectores de alta criticidad enumerados en el Anexo I de NIS2.

La evaluación de 2026 cubre el ecosistema completo de cada sector (autoridades nacionales, entidades reguladas y legislación de la UE aplicable) en lugar de organizaciones individuales. Identifica sectores donde la madurez ha mejorado y sectores donde la brecha entre la criticidad y la postura de seguridad real sigue siendo amplia.

Ocho sectores se identifican como zonas de riesgo: salud, ferrocarril, marítimo, gestión de servicios TIC, espacio, administración pública, agua potable y aguas residuales. Estos son sectores donde las consecuencias de un ataque exitoso son graves, pero donde la línea base de seguridad en todo el sector permanece por debajo de lo que exige el nivel de amenaza.

Para los líderes de TI y seguridad en estos sectores, la evaluación NIS360 es un punto de referencia útil. Si su sector aparece en la lista de zonas de riesgo, espere una mayor atención supervisora de las autoridades nacionales competentes — no porque el informe desencadene directamente la aplicación, sino porque los reguladores utilizan los datos de madurez sectorial para priorizar sus calendarios de auditoría e inspección.

Luxemburgo: Ley NIS2 en vigor, el plazo de registro es el 10 de julio de 2026

Luxemburgo publicó su ley de transposición NIS2 el 6 de mayo de 2026 en el Journal officiel du Grand-Duché de Luxembourg. La ley entró en vigor el 10 de mayo de 2026, reemplazando la ley NIS1 del 28 de mayo de 2019.

Quién está dentro del ámbito de aplicación

NIS2 se aplica en Luxemburgo a organizaciones con 50 o más empleados o una facturación anual superior a 10 millones de €, que operan en uno de los 18 sectores críticos. Los umbrales de tamaño se evalúan a nivel de grupo consolidado: una filial con 40 empleados puede estar dentro del ámbito si el grupo matriz supera los umbrales.

La estructura de dos niveles

Las entidades esenciales — grandes organizaciones en sectores del Anexo I con más de 250 empleados y ya sea 50 millones de € en facturación o 43 millones de € en balance — están sujetas a supervisión proactiva y sanciones de hasta 10 millones de € o el 2% de la facturación global. Las entidades importantes — organizaciones medianas del Anexo I y todas las entidades cualificadas del Anexo II — están sujetas a supervisión reactiva y sanciones de hasta 7 millones de € o el 1,4% de la facturación global.

Ambos niveles deben implementar las mismas diez categorías de medidas según el Artículo 12: análisis de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, desarrollo seguro, evaluación de la eficacia, higiene cibernética, criptografía, control de acceso y autenticación multifactor.

Plazos de notificación de incidentes

Luxemburgo sigue exactamente la estructura del Artículo 23 de NIS2: alerta temprana de 24 horas, notificación formal de 72 horas, informe final de un mes. Incumplir cualquier plazo es en sí mismo una infracción sancionable.

El plazo de autoregistro del 10 de julio de 2026

Las entidades tienen hasta el 10 de julio de 2026 para autoregistrarse ante su autoridad competente. El ILR (Institut Luxembourgeois de Régulation) actúa como autoridad competente para la mayoría de los sectores; la CSSF supervisa la banca y la infraestructura del mercado financiero. El no registro es una infracción sancionable según el Artículo 11.

Los órganos de dirección deben aprobar formalmente las medidas de ciberseguridad, supervisar su implementación y someterse a formación regular. Para las entidades esenciales, los directivos pueden enfrentarse a una prohibición temporal de ejercer funciones de dirección por fallos graves.

Países Bajos: La Cyberbeveiligingswet alcanza la fase plenaria del Senado

La Cámara de Representantes neerlandesa aprobó la Cyberbeveiligingswet (la ley de transposición NIS2 de los Países Bajos) el 15 de abril de 2026 por 140 votos contra 10. El proyecto de ley ha avanzado ahora a la fase plenaria del Senado.

En qué punto se encuentra el proyecto de ley

La Tweede Kamer aprobó el proyecto de ley con amplio apoyo multipartidista; solo dos partidos votaron en contra. Las comisiones del Senado responsables de digitalización y justicia completaron su revisión escrita el 19 de mayo de 2026. El proyecto de ley ha pasado desde entonces a la fase plenaria del Senado, donde espera una votación final.

El proyecto de ley se está tramitando en paralelo con legislación separada que transpone la Directiva CER de la UE sobre la resiliencia de entidades críticas.

Antecedentes

Los Países Bajos presentaron el proyecto de ley al parlamento el 2 de junio de 2025, incumpliendo el plazo de transposición de la UE del 17 de octubre de 2024 por más de un año. El proyecto de ley pasó casi diez meses en el procedimiento de la cámara baja antes de ser aprobado.

Disposiciones clave

En lugar de crear una única autoridad nacional de ciberseguridad, la ley asigna la aplicación a los reguladores sectoriales existentes — el regulador de energía para las empresas energéticas, el regulador sanitario para los hospitales, y así sucesivamente. La fecha exacta de entrada en vigor de la ley se establecerá por decreto gubernamental después de la aprobación del Senado, y diferentes disposiciones pueden entrar en vigor en diferentes fechas.

Qué viene a continuación

La aprobación del Senado es el último paso legislativo. Una vez que pase la votación y el gobierno establezca una fecha de entrada en vigor, las organizaciones dentro del ámbito enfrentarán obligaciones de cumplimiento inmediatas — medidas de gestión de riesgos, notificación de incidentes y requisitos de responsabilidad de la dirección.

Irlanda: Proyecto de ley de Seguridad Cibernética Nacional confirmado como vehículo NIS2

En una respuesta parlamentaria escrita al Dáil Éireann (la cámara baja del parlamento irlandés) el 13 de mayo de 2026, el Ministro de Justicia, Asuntos de Interior y Migración de Irlanda confirmó que el Departamento de Justicia está redactando el proyecto de ley de Seguridad Cibernética Nacional como el vehículo legislativo para la transposición de NIS2.

El proyecto de ley está catalogado como prioridad para su publicación en el programa legislativo del verano de 2026. Designará al Centro Nacional de Seguridad Cibernética (NCSC) como la autoridad nacional competente y como el Equipo de Respuesta a Incidentes de Seguridad Informática (CSIRT) de Irlanda. También establecerá al NCSC sobre una base estatutaria por primera vez — el centro actualmente opera sin una base legislativa dedicada.

Irlanda incumplió el plazo de transposición de la UE del 17 de octubre de 2024. Una decisión del Gabinete en julio de 2024 ordenó la redacción prioritaria de la legislación, y el trabajo ha progresado desde entonces. El borrador del proyecto de ley aún no se ha publicado, pero el gobierno publicó el Esquema General del proyecto de ley de Seguridad Cibernética Nacional en septiembre de 2024, estableciendo su estructura prevista.

Responsabilidad de la dirección

Según el Artículo 20 de NIS2, tal como se refleja en el Head 28 del Esquema General, los consejos de dirección estarán obligados a aprobar y supervisar las medidas de gestión de riesgos de ciberseguridad, asistir a formación regular en ciberseguridad y pueden enfrentarse a responsabilidad personal por fallos de cumplimiento — incluyendo prohibiciones temporales y multas administrativas. El Esquema General define «consejo de dirección» como «un órgano o grupo de individuos investidos con la autoridad y responsabilidad para la supervisión, dirección y control de una entidad».

Reguladores sectoriales ya activos

Los reguladores sectoriales ya han sido designados como Autoridades Nacionales Competentes y se están preparando para asumir funciones de supervisión y aplicación. Los portales de registro y notificación de incidentes de NIS2 aún no están activos — se abrirán una vez que se promulgue la legislación — pero el NCSC ha publicado un borrador de guía sobre Medidas de Gestión de Riesgos y el marco Cyber Fundamentals (CyFun) para ayudar a las organizaciones a prepararse mientras tanto.

El proyecto de ley también se está desarrollando junto con la tercera Estrategia Nacional de Seguridad Cibernética de Irlanda, coordinada a través de un Comité Interdepartamental presidido por el Departamento de Justicia.

Para las organizaciones con operaciones en Irlanda, la ausencia de legislación promulgada no elimina la obligación de prepararse. Las ANC sectoriales ya están activas, y la promulgación del proyecto de ley se describe como una prioridad del gobierno.

DigitalEurope: NIS2 todavía necesita una armonización más profunda

El 13 de mayo de 2026, DigitalEurope publicó una posición política formal sobre el paquete de ciberseguridad de la UE, que abarca la propuesta de Ley de Ciberseguridad 2 (CSA2), el marco de seguridad de la cadena de suministro de TIC y las enmiendas específicas de NIS2.

Sobre NIS2 específicamente, la posición de DigitalEurope es directa: las enmiendas específicas propuestas en el paquete actual responden «mínimamente» a las preocupaciones que la industria ha planteado durante varios años. Las áreas que requieren una armonización más rigurosa son:

• Ámbito de aplicación: NIS2 debería centrarse únicamente en las actividades comerciales principales, excluyendo las operaciones auxiliares que crean obligaciones desproporcionadas.
• Umbrales de tamaño: La divergencia nacional en la aplicación de los umbrales crea una cobertura inconsistente entre los estados miembros.
• Notificación de incidentes: Los campos de notificación, los plazos y los procesos de envío todavía varían a nivel nacional — un problema que las plantillas comunes (ver arriba) abordan parcialmente.
• Reglas del establecimiento principal: Las organizaciones que operan en múltiples estados miembros enfrentan incertidumbre sobre qué autoridad nacional tiene jurisdicción principal.
• Evaluación de conformidad: Los requisitos difieren según el estado miembro, creando complejidad de cumplimiento para las operaciones transfronterizas.

DigitalEurope también pidió a ENISA que realice evaluaciones de impacto para toda la legislación de ciberseguridad de la UE relevante y que coordine la implementación de manera más activa — posicionando a la agencia como un centro de coordinación en lugar de un organismo puramente consultivo.

Para los responsables de cumplimiento que siguen la trayectoria regulatoria: las brechas de armonización que identifica DigitalEurope son puntos de fricción operativa reales. Las plantillas comunes de notificación de incidentes adoptadas el 26 de mayo son un paso hacia el cierre de una de ellas. Las demás requerirán los actos de ejecución o el proceso de enmienda de NIS2 para resolverse.

Qué significa esto para su equipo ahora mismo

Los desarrollos de mayo de 2026 siguen un patrón que ha sido consistente desde que comenzó la aplicación: el texto de la directiva es estable, pero la capa de implementación nacional sigue moviéndose. La fase de sanciones completas de Bulgaria, el plazo de registro activo de Luxemburgo y la votación pendiente del Senado en los Países Bajos representan todos desencadenantes concretos de cumplimiento, cada uno con una fecha específica ahora adjunta.

Las plantillas comunes de notificación de incidentes son el desarrollo a nivel de la UE más significativo operativamente del período. Una vez que se publique el acto de ejecución de la Comisión, el flujo de trabajo de notificación de incidentes de cada organización deberá actualizarse para coincidir con el formato estandarizado. Incorpore esa actualización en su planificación de respuesta a incidentes ahora, antes de que un incidente real le obligue a hacerlo bajo presión.

La lista de zonas de riesgo de ENISA NIS360 merece tomarse en serio si su organización opera en salud, administración pública o cualquiera de los otros sectores señalados. La atención supervisora sigue las brechas de madurez — y la evaluación de ENISA alimenta directamente cómo las autoridades nacionales competentes priorizan sus calendarios de auditoría.

Preguntas frecuentes

¿Qué pasó con NIS2 en mayo de 2026?

Mayo de 2026 vio cuatro desarrollos significativos de NIS2: la ley de transposición de Luxemburgo entró en vigor el 10 de mayo; el Grupo de Cooperación NIS adoptó plantillas comunes de notificación de incidentes el 26 de mayo; ENISA publicó la evaluación de madurez sectorial NIS360 2026 el 28 de mayo; y los Países Bajos avanzaron su Cyberbeveiligingswet a través de la Cámara de Representantes. La fase de sanciones completas de Bulgaria comenzó el 1 de junio de 2026, directamente después del período de mayo.

¿Cuál es el plazo de autoregistro NIS2 de Luxemburgo?

La ley de transposición NIS2 de Luxemburgo, que entró en vigor el 10 de mayo de 2026, requiere que todas las entidades dentro del ámbito se autoregistren ante su autoridad competente antes del 10 de julio de 2026. El ILR (Institut Luxembourgeois de Régulation) es la autoridad competente principal. El no registro es una infracción sancionable según el Artículo 11 de la ley de transposición.

¿Cuáles son las nuevas plantillas de notificación de incidentes NIS2?

El 26 de mayo de 2026, el Grupo de Cooperación NIS adoptó plantillas comunes para la notificación de incidentes NIS2 en su 39ª reunión plenaria en Chipre. Las plantillas proporcionan un formato estandarizado para notificar incidentes cibernéticos en todos los estados miembros de la UE. La Comisión Europea planea hacerlas obligatorias mediante un acto de ejecución. Los plazos subyacentes del Artículo 23 de NIS2 — alerta temprana de 24 horas, notificación de 72 horas, informe final de un mes — permanecen sin cambios.

¿Qué sectores identifica el NIS360 2026 de ENISA como de mayor riesgo?

El informe NIS360 2026 de ENISA, publicado el 28 de mayo de 2026, identifica ocho sectores como zonas de riesgo donde la madurez en ciberseguridad permanece baja en relación con la criticidad: salud, ferrocarril, marítimo, gestión de servicios TIC, espacio, administración pública, agua potable y aguas residuales. Todos estos son sectores del Anexo I bajo NIS2 y están sujetos a supervisión proactiva como entidades esenciales.

¿Cuáles son las reglas de responsabilidad personal para directivos bajo el NIS2 de Bulgaria?

Según la Ley de Ciberseguridad enmendada de Bulgaria, los miembros del órgano de dirección de entidades esenciales e importantes enfrentan multas personales de 500 € a 5.000 € por incumplir sus obligaciones de gobernanza — separadas de las multas a nivel de entidad. Desde el 1 de junio de 2026, estas multas se aplican a los importes legales completos; el descuento transitorio del 50% que se aplicaba a las violaciones anteriores a junio ya no existe. La autoridad competente también puede solicitar una prohibición temporal ordenada por el tribunal para que un directivo ejerza funciones de dirección.

¿Cuántos estados miembros de la UE han transpuesto NIS2?

A finales de mayo de 2026, 23 de los 27 estados miembros de la UE han transpuesto NIS2 a la legislación nacional, según el rastreador de mayo de 2026 de Cullen International. La transposición de Luxemburgo entró en vigor el 10 de mayo de 2026, elevando el total a 23. Cuatro estados miembros permanecen en el proceso legislativo, más de 19 meses después del plazo de transposición de octubre de 2024.

¿Qué es la Cyberbeveiligingswet de los Países Bajos?

La Cyberbeveiligingswet es la legislación nacional de los Países Bajos que implementa NIS2. La Cámara de Representantes neerlandesa aprobó el proyecto de ley en 2026 después de que los Países Bajos incumplieran el plazo de transposición original de la UE de octubre de 2024. El proyecto de ley todavía requiere la aprobación del Senado antes de poder entrar en vigor. El modelo de los Países Bajos utiliza una estructura de supervisión descentralizada, con reguladores específicos del sector manejando la aplicación.

Guía de cumplimiento NIS2: La hoja de ruta de gestión de acceso para 2026

Las credenciales robadas dominan las brechas de seguridad en 2026. El Artículo 21 de NIS2 exige 10 medidas de seguridad para eliminar los vectores de ataque basados en credenciales. Esta guía cubre los requisitos técnicos, la obligación de notificación de incidentes en 24 horas, los niveles de MFA de ENISA y una hoja de ruta de 5 fases para el cumplimiento listo para auditoría.

Passwork BlogAlex Muntyan

Passwork gana Top Performer primavera 2026 en SourceForge

Passwork ha sido nombrado Top Performer primavera 2026 por SourceForge, clasificándose en el 10% superior de más de 100.000 soluciones. La insignia se basa completamente en reseñas verificadas — 4,8 estrellas en general, con un 5,0 perfecto para soporte.

Passwork BlogAlex Muntyan

Ataques de fuerza bruta en 2026: Tipos, ejemplos y cómo prevenirlos

Clústeres de GPU, listas de palabras asistidas por IA, botnets de 2,8 millones de dispositivos. La fuerza bruta ha escalado. Esta guía cubre seis variantes de ataque, casos reales de 2025 y una estrategia de defensa en capas que su equipo puede implementar hoy.

Passwork BlogAlex Muntyan

Bulgaria's NIS2 grace period ended on 1 June 2026 — board members now face full personal fines, not the discounted 50% rate that applied through May. Luxembourg's NIS2 Directive transposition law entered into force on 10 May 2026, leaving four member states still without implementing legislation. The EU's NIS Cooperation Group adopted common incident-reporting templates that the Commission intends to make mandatory through an implementing act.

This article covers every material NIS2 update from May 2026: what changed, which deadlines are live, and what your team needs to act on now.

Key takeaways

These NIS2 updates from May 2026 carry concrete compliance triggers: specific dates and specific obligations. Here is what changed.

• Bulgaria's full sanctions regime is active. From 1 June 2026, personal fines for management body members apply at 100% of statutory amounts — up to €5,000 per individual, separate from entity-level fines of up to €10 million. The 50% transitional discount is gone.
• Luxembourg's NIS2 law entered into force on 10 May 2026. In-scope entities have until 10 July 2026 to self-register with the ILR. Non-registration is itself a sanctionable breach.
• Four EU member states have still not transposed NIS2 — more than 19 months after the October 2024 deadline, according to Cullen International's May 2026 tracker.
• Common incident-reporting templates were adopted EU-wide. The NIS Cooperation Group agreed on standardised formats at its 39th plenary in Cyprus on 26 May 2026. A Commission implementing act will make them mandatory.
• ENISA's NIS360 2026 report identifies eight risk-zone sectors. Health, railway, maritime, ICT service management, space, public administration, drinking water, and wastewater show the lowest cybersecurity maturity relative to their criticality.
• The Netherlands advanced its delayed Cyberbeveiligingswet. The Dutch House of Representatives approved the bill on 15 April 2026; Senate approval remains pending.
• Ireland confirmed the National Cyber Security Bill as its NIS2 vehicle. The Department of Justice is drafting the legislation and placing the NCSC on a statutory footing.
• DigitalEurope called for deeper NIS2 harmonisation. The industry body published a formal position identifying scope, size thresholds, incident reporting, and conformity assessment as the areas most in need of standardisation across member states.

Bulgaria's full enforcement phase began 1 June 2026

Bulgaria's NIS2 enforcement entered its final phase on 1 June 2026. Fines and sanctions for all infringements now apply at their full statutory amounts — the 50% reduction that applied to violations committed before that date is gone.

The underlying legislation is the Law Amending and Supplementing the Cybersecurity Act, adopted by the 51st National Assembly on 5 February 2026 and promulgated in the State Gazette (issue 17) on 13 February 2026, entering into force on the same date.

Who is in scope

The Cybersecurity Act covers public and private entities in Annex I and Annex II sectors that meet or exceed medium-enterprise thresholds. Certain providers are in scope regardless of size: public electronic communications networks, trust service providers, top-level domain registries, DNS service providers, entities that are the sole provider of a critical service in Bulgaria, or whose disruption would significantly affect public order, public safety or health, or the economy.

Administrative bodies (including municipalities) are classified as essential entities under Article 4a(1)(4), regardless of size.

Full enforcement without a complete rulebook

One practical complication remains. The law explicitly delegates the definition of minimum cybersecurity measures for certain entity categories to a secondary ordinance of the Council of Ministers, to be proposed jointly by the Communications Regulation Commission and the Minister of e-Governance. That ordinance has not yet been published. Organizations entered the full enforcement phase without the complete operational rulebook the law itself anticipated.

That does not suspend the obligations. The primary law is in force, sanctions are real. Gap analysis against the existing NIS2 framework is both possible and advisable now, before supervisory pressure builds. ISO/IEC 27001 and ISO 22301 provide a workable baseline alongside the Cybersecurity Act's requirements.

What management bodies must now demonstrate

Bulgaria's Cybersecurity Act places explicit personal accountability on individual members of management bodies, not just on the organization as a legal entity. Management bodies must:

• Formally approve the cybersecurity risk-management measures required under Article 21
• Oversee implementation of those measures
• Complete cybersecurity training at least every two years
• Organize equivalent training for employees on a regular basis

The measures that boards must approve cover risk analysis and information security policies, incident handling, business continuity and crisis management, supply chain security, cyber hygiene practices, and multi-factor authentication where appropriate.

The personal fine structure

Where a management body member of an essential or important entity breaches these governance obligations, a personal fine of €500 to €5,000 may be imposed. This is separate from entity-level sanctions and stacks on top of them: up to €10 million or 2% of global turnover for essential entities, and up to €7 million or 1.4% for important entities.

The competent national authority can also request a court to impose a temporary prohibition on a natural person from exercising management functions in an essential entity.

The practical implication: a board member cannot delegate their way out of liability. Whether a fine is imposed, and how severe, will depend on the individual's ability to show tangible actions — board resolutions, adopted policies, audit protocols, assigned responsibilities, completed training, and documented corrective measures.

EU-wide: Common incident-reporting templates adopted

On 26 May 2026, the NIS Cooperation Group adopted common templates for NIS2 incident reporting at its 39th plenary meeting in Cyprus. The Group brings together EU member states, the European Commission, and ENISA.

The templates provide a standardised format for reporting cyber incidents across the EU. Until now, the absence of a common format meant that organizations operating in multiple member states had to navigate different national reporting forms, field sets, and submission portals — a significant administrative burden for any cross-border operation.

The Commission has stated it plans to adopt these templates through an implementing act, which would make them mandatory for all member states. Once that act is in force, the templates will establish a unified incident-reporting framework across the EU.

This development also connects to the broader Digital Omnibus proposal, which includes a single-entry point for incident reporting. The common templates are designed to align with that future architecture.

What this means for your incident response process: If your team has built notification workflows around a specific member state's current form, expect those workflows to be updated once the implementing act is published. The core NIS2 compliance timeline obligations under Article 23 (24-hour early warning, 72-hour incident notification, one-month final report) do not change. The format for submitting them does.

ENISA NIS360 2026: Eight sectors still in the risk zone

ENISA published the third edition of its NIS360 report on 28 May 2026. The report assesses cybersecurity maturity and criticality across all sectors of high criticality listed under Annex I of NIS2.

The 2026 assessment covers the full ecosystem of each sector (national authorities, regulated entities, and applicable EU legislation) rather than individual organizations. It identifies sectors where maturity has improved and sectors where the gap between criticality and actual security posture remains wide.

Eight sectors are identified as risk zones: health, railway, maritime, ICT service management, space, public administration, drinking water, and wastewater. These are sectors where the consequences of a successful attack are severe, but where the security baseline across the sector remains below what the threat level demands.

For IT and security leaders in these sectors, the NIS360 assessment is a useful benchmark. If your sector appears in the risk-zone list, expect heightened supervisory attention from national competent authorities — not because the report triggers enforcement directly, but because regulators use sector-level maturity data to prioritize their audit and inspection calendars.

Luxembourg: NIS2 law in force, registration deadline is 10 July 2026

Luxembourg published its NIS2 transposition law on 6 May 2026 in the Journal officiel du Grand-Duché de Luxembourg. The law entered into force on 10 May 2026, replacing the NIS1 law of 28 May 2019.

Who is in scope

NIS2 applies in Luxembourg to organizations with 50 or more employees or annual turnover exceeding €10 million, operating in one of 18 critical sectors. Size thresholds are assessed at consolidated group level: a subsidiary with 40 employees may still be in scope if the parent group exceeds the thresholds.

The two-tier structure

Essential entities — large organizations in Annex I sectors with more than 250 employees and either €50 million in turnover or €43 million in balance sheet — face proactive supervision and sanctions of up to €10 million or 2% of global turnover. Important entities — medium-sized Annex I organizations and all qualifying Annex II entities — face reactive supervision and sanctions of up to €7 million or 1.4% of global turnover.

Both tiers must implement the same ten categories of measures under Article 12: risk analysis, incident handling, business continuity, supply chain security, secure development, effectiveness assessment, cyber hygiene, cryptography, access control, and multi-factor authentication.

Incident reporting timelines

Luxembourg follows the NIS2 Article 23 structure exactly: 24-hour early warning, 72-hour formal notification, one-month final report. Missing any deadline is itself a sanctionable breach.

The 10 July 2026 self-registration deadline

Entities have until 10 July 2026 to self-register with their competent authority. The ILR (Institut Luxembourgeois de Régulation) acts as the competent authority for most sectors; the CSSF oversees banking and financial market infrastructure. Non-registration is a sanctionable breach under Article 11.

Management bodies must formally approve cybersecurity measures, supervise their implementation, and undergo regular training. For essential entities, senior managers can face a temporary ban from exercising management functions for serious failures.

Netherlands: Cyberbeveiligingswet reaches Senate plenary stage

The Dutch House of Representatives approved the Cyberbeveiligingswet (the Netherlands' NIS2 transposition law) on 15 April 2026 by 140 votes to 10. The bill has now advanced to the Senate plenary stage.

Where the bill stands

The Tweede Kamer passed the bill with broad cross-party support; only two parties voted against. The Senate committees responsible for digitalisation and justice completed their written review on 19 May 2026. The bill has since moved to the Senate plenary stage, where it awaits a final vote.

The bill is being processed in parallel with separate legislation transposing the EU's CER Directive on the resilience of critical entities.

Background

The Netherlands submitted the bill to parliament on 2 June 2025, missing the EU transposition deadline of 17 October 2024 by over a year. The bill spent nearly ten months in lower house procedure before passing.

Key provisions

Rather than creating a single national cybersecurity authority, the law assigns enforcement to existing sector-specific regulators — the energy regulator for energy companies, the healthcare regulator for hospitals, and so on. The exact date the law enters into force will be set by government decree after Senate approval, and different provisions may take effect on different dates.

What comes next

Senate approval is the last legislative step. Once the vote passes and the government sets an entry-into-force date, organizations in scope will face immediate compliance obligations — risk management measures, incident reporting, and management accountability requirements.

Ireland: National Cyber Security Bill confirmed as NIS2 vehicle

In a written parliamentary answer to Dáil Éireann (the lower house of the Irish parliament) on 13 May 2026, Ireland's Minister for Justice, Home Affairs and Migration confirmed that the Department of Justice is drafting the National Cyber Security Bill as the legislative vehicle for NIS2 transposition.

The Bill is listed as a priority for publication in the Summer 2026 legislation programme. It will appoint the National Cyber Security Centre (NCSC) as the national competent authority and as Ireland's Computer Security Incident Response Team (CSIRT). It will also place the NCSC on a statutory footing for the first time — the centre currently operates without a dedicated legislative basis.

Ireland missed the EU transposition deadline of 17 October 2024. A Cabinet decision in July 2024 directed priority drafting of the legislation, and work has been progressing since. The draft Bill has not yet been published, but the government released the General Scheme of the National Cyber Security Bill in September 2024, setting out its intended structure.

Management liability

Under NIS2 Article 20, as reflected in Head 28 of the General Scheme, management boards will be required to approve and oversee cybersecurity risk management measures, attend regular cybersecurity training, and may face personal liability for compliance failures — including temporary bans and administrative fines. The General Scheme defines "management board" as "a body or group of individuals vested with the authority and responsibility for the oversight, direction and control of an entity."

Sectoral regulators already active

Sectoral regulators have already been designated as National Competent Authorities and are preparing to take on supervision and enforcement functions. The NIS2 registration and incident reporting portals are not yet live — they will open once the legislation is enacted — but the NCSC has published draft Risk Management Measures guidance and the Cyber Fundamentals (CyFun) framework to help organizations prepare in the interim.

The Bill is also being developed alongside Ireland's third National Cyber Security Strategy, coordinated through an Inter-Departmental Committee chaired by the Department of Justice.

For organizations with Irish operations, the absence of enacted legislation does not remove the obligation to prepare. Sectoral NCAs are already active, and the Bill's enactment is described as a government priority.

DigitalEurope: NIS2 still needs deeper harmonisation

On 13 May 2026, DigitalEurope published a formal policy position on the EU cybersecurity package, covering the proposed Cybersecurity Act 2 (CSA2), the ICT supply chain security framework, and targeted NIS2 amendments.

On NIS2 specifically, DigitalEurope's position is direct: the targeted amendments proposed in the current package respond "minimally" to the concerns industry has raised over several years. The areas requiring more rigorous harmonisation are:

• Scope: NIS2 should focus on core business activities only, excluding ancillary operations that create disproportionate obligations.
• Size thresholds: National divergence in how thresholds are applied creates inconsistent coverage across member states.
• Incident reporting: Reporting fields, timelines, and submission processes still vary at national level — a problem the common templates (see above) partially address.
• Main establishment rules: Organizations operating across multiple member states face uncertainty about which national authority has primary jurisdiction.
• Conformity assessment: Requirements differ by member state, creating compliance complexity for cross-border operations.

DigitalEurope also called for ENISA to conduct impact assessments for all relevant EU cybersecurity legislation and to coordinate implementation more actively — positioning the agency as a coordination hub rather than a purely advisory body.

For compliance officers tracking the regulatory trajectory: the harmonisation gaps DigitalEurope identifies are real operational friction points. The common incident-reporting templates adopted on 26 May are a step toward closing one of them. The others will require either the implementing acts or the NIS2 amendment process to resolve.

What this means for your team right now

The May 2026 developments follow a pattern that has been consistent since enforcement began: the directive's text is stable, but the national implementation layer keeps moving. Bulgaria's full sanctions phase, Luxembourg's live registration deadline, and the pending Senate vote in the Netherlands all represent concrete compliance triggers, each with a specific date now attached.

The common incident-reporting templates are the most operationally significant EU-wide development of the period. Once the Commission implementing act is published, every organization's incident notification workflow will need to be updated to match the standardised format. Build that update into your incident response planning now, before an actual incident forces you to do it under pressure.

The ENISA NIS360 risk-zone list is worth taking seriously if your organization operates in health, public administration, or any of the other flagged sectors. Supervisory attention follows maturity gaps — and ENISA's assessment feeds directly into how national competent authorities prioritize their audit calendars.

Frequently asked questions

What happened with NIS2 in May 2026?

May 2026 saw four significant NIS2 developments: Luxembourg's transposition law entered into force on 10 May; the NIS Cooperation Group adopted common incident-reporting templates on 26 May; ENISA published the NIS360 2026 sector maturity assessment on 28 May; and the Netherlands advanced its Cyberbeveiligingswet through the House of Representatives. Bulgaria's full sanctions phase began on 1 June 2026, directly following the May period.

What is the Luxembourg NIS2 self-registration deadline?

Luxembourg's NIS2 transposition law, which entered into force on 10 May 2026, requires all in-scope entities to self-register with their competent authority by 10 July 2026. The ILR (Institut Luxembourgeois de Régulation) is the primary competent authority. Non-registration is a sanctionable breach under Article 11 of the transposition law.

What are the new NIS2 incident-reporting templates?

On 26 May 2026, the NIS Cooperation Group adopted common templates for NIS2 incident reporting at its 39th plenary meeting in Cyprus. The templates provide a standardised format for reporting cyber incidents across all EU member states. The European Commission plans to make them mandatory through an implementing act. The underlying NIS2 Article 23 timelines — 24-hour early warning, 72-hour notification, one-month final report — remain unchanged.

Which sectors does ENISA's NIS360 2026 identify as highest risk?

ENISA's NIS360 2026 report, published 28 May 2026, identifies eight sectors as risk zones where cybersecurity maturity remains low relative to criticality: health, railway, maritime, ICT service management, space, public administration, drinking water, and wastewater. These are all Annex I sectors under NIS2 and are subject to proactive supervision as essential entities.

What are the personal liability rules for managers under Bulgaria's NIS2?

Under Bulgaria's amended Cybersecurity Act, members of the management body of essential and important entities face personal fines of €500 to €5,000 for breaching their governance obligations — separate from entity-level fines. From 1 June 2026, these fines apply at full statutory amounts; the 50% transitional discount that applied to pre-June violations no longer exists. The competent authority can also seek a court-ordered temporary ban on a manager from exercising management functions.

How many EU member states have transposed NIS2?

As of late May 2026, 23 of 27 EU member states have transposed NIS2 into national law, according to Cullen International's May 2026 tracker. Luxembourg's transposition entered into force on 10 May 2026, bringing the total to 23. Four member states remain in the legislative process, more than 19 months after the October 2024 transposition deadline.

What is the Netherlands' Cyberbeveiligingswet?

The Cyberbeveiligingswet is the Netherlands' national legislation implementing NIS2. The Dutch House of Representatives approved the bill in 2026 after the Netherlands missed the original EU transposition deadline of October 2024. The bill still requires Senate approval before it can enter into force. The Netherlands' model uses a decentralised supervisory structure, with sector-specific regulators handling enforcement.

NIS2 compliance guide: The access management roadmap for 2026

Stolen credentials dominate breaches in 2026. NIS2 Article 21 mandates 10 security measures to eliminate credential-based attack vectors. This guide covers technical requirements, the 24-hour incident reporting obligation, ENISA’s MFA tiers, and a 5-phase roadmap to audit-ready compliance.

Passwork BlogAlex Muntyan

Passwork wins Top Performer Spring 2026 on SourceForge

Passwork has been named a Top Performer Spring 2026 by SourceForge, ranking in the top 10% of 100,000+ solutions. The badge is based entirely on verified reviews — 4.8 stars overall, with a perfect 5.0 for support.

Passwork BlogAlex Muntyan

Brute force attacks in 2026: Types, examples & how to prevent them

GPU clusters, AI-assisted wordlists, botnets of 2.8M devices. Brute force has scaled. This guide covers six attack variants, real-world cases from 2025, and a layered defense strategy your team can implement today.

Passwork BlogAlex Muntyan

A Diretiva NIS2 (UE 2022/2555) está agora em vigor em toda a Europa. As entidades essenciais e importantes enfrentam um prazo inadiável: implementar medidas robustas de gestão de riscos de cibersegurança até outubro de 2024, sob pena de coimas até 10 milhões de euros ou 2 % do volume de negócios anual mundial. A maioria das organizações subestima o custo operacional da conformidade. Um gestor de palavras-passe é a base que torna a conformidade com o artigo 21.º alcançável sem comprometer o orçamento nem esgotar a equipa de TI.

Pontos principais

• O artigo 21.º da NIS2 está orientado para resultados e não prescreve ferramentas. Os reguladores exigem prova de que a organização controla quem acede a quê, quando e porquê. Um gestor de palavras-passe centralizado com controlo de acesso baseado em funções (RBAC) e registo de auditoria transforma um passivo de conformidade num processo documentado e auditável.
• Os custos do incumprimento excedem largamente o investimento em conformidade. As coimas diretas chegam a 10 milhões de euros para as entidades essenciais, a que se somam 5,1 milhões de euros de custos médios de remediação de violações de dados. Uma única violação de credenciais evitável custa mais do que implementar um gestor de palavras-passe: o retorno do investimento (ROI) é imediato e inegável.
• Oitenta e um por cento das violações de dados têm origem em credenciais roubadas ou fracas. Um gestor de palavras-passe elimina este vetor ao impor políticas de palavras-passe fortes, impedir a reutilização de credenciais, detetar acessos não autorizados através de logs de auditoria e permitir a rotação em massa de palavras-passe em poucas horas após um comprometimento.
• Os tickets de helpdesk relacionados com palavras-passe consomem 30–50 % da capacidade de suporte de TI. Um gestor de palavras-passe reduz estes tickets até 40 %, libertando o pessoal de TI para trabalho estratégico. As poupanças anuais chegam a 210 000 € numa organização de média dimensão típica, tendo em conta os custos de mão de obra do helpdesk, o tempo de auditoria de conformidade e a resposta a incidentes.
• A soberania dos dados na UE é alcançável sem complexidade operacional. O Passwork Cloud aloja os dados exclusivamente em centros de dados da UE, sem transferências transfronteiriças, o que satisfaz o artigo 32.º do RGPD e o artigo 21.º da NIS2. A organização mantém o controlo das chaves de cifragem e registos de auditoria imutáveis, e evita o encargo de aplicação de patches de uma implementação on-premise (nas instalações próprias).
• A escolha é binária: conformidade proativa ou conformidade reativa. Investir agora para evitar coimas ou sofrer primeiro uma violação de dados e pagar 15 milhões de euros mais tarde. As organizações europeias estão a optar pela primeira opção e a construir a conformidade sobre a base de um gestor de palavras-passe que reduz a carga operacional e satisfaz os requisitos regulamentares.

Compreender o artigo 21.º da NIS2: O cerne da gestão de riscos de cibersegurança

O artigo 21.º da NIS2 exige que as entidades essenciais e importantes implementem medidas técnicas, operacionais e organizacionais de gestão de riscos de cibersegurança. Estas medidas abrangem dez áreas de segurança de base: controlo de acesso, autenticação, cifragem, tratamento de incidentes, segurança da cadeia de abastecimento, entre outras. A diretiva não prescreve ferramentas específicas, define resultados. Um gestor de palavras-passe aborda diretamente vários requisitos do artigo 21.º ao centralizar a gestão de credenciais, impor políticas de autenticação fortes e manter registos de auditoria imutáveis.

O desafio central: O artigo 21.º está orientado para resultados, e não para ferramentas. Os responsáveis pela conformidade têm de demonstrar que a organização controla quem acede a quê, quando e porquê. A partilha manual de palavras-passe por e-mail, folhas de cálculo ou notas autocolantes falha imediatamente neste teste. Um cofre de credenciais centralizado com controlo de acesso baseado em funções (RBAC) e registo completo de eventos transforma um passivo de conformidade num processo documentado e auditável.

Os custos ocultos do incumprimento da NIS2

O incumprimento acarreta duas categorias de custos distintas: coimas diretas e custos indiretos de violações de dados.

• As coimas diretas são pesadas. O artigo 34.º da NIS2 estabelece sanções até 10 milhões de euros ou 2 % do volume de negócios anual mundial total para as entidades essenciais, e 5 milhões de euros ou 1 % para as entidades importantes. Uma empresa de serviços financeiros de média dimensão com 500 milhões de euros de receitas enfrenta uma possível coima de 10 milhões de euros por uma única falha material de conformidade.
• Os custos indiretos ultrapassam em muito as coimas. Segundo o 2025 Cost of a Data Breach Report da IBM, o custo médio global de uma violação de dados atingiu 5,1 milhões de dólares, e isto antes de as sanções da NIS2 produzirem efeitos. A gestão deficiente de credenciais é a causa de fundo: 81 % das violações de dados têm origem em credenciais roubadas ou fracas. Um gestor de palavras-passe elimina completamente este vetor ao impor políticas de palavras-passe fortes, impedir a reutilização de credenciais e detetar tentativas de acesso não autorizado através de logs de auditoria.

Faça as contas: uma única violação evitável custa 5,1 milhões de euros em remediação, notificação e perda de negócio. Uma coima da NIS2 acrescenta 10 milhões de euros. A implementação de um gestor de palavras-passe representa uma fração destes custos, e o ROI é imediato e inegável.

Quantificar o ROI: Como um gestor de palavras-passe poupa dinheiro e tempo

Os tickets de helpdesk relacionados com palavras-passe consomem 30–50 % da capacidade de suporte de TI. Um ticket típico custa 50–100 € em mão de obra. Para uma organização com 100 pessoas, isso representa 1500–2500 tickets por ano, ou seja, 75 000–250 000 € em custos gerais puros de helpdesk. A implementação de um gestor de palavras-passe reduz estes tickets até 40 %, libertando o pessoal de TI para trabalho estratégico.

Além das poupanças operacionais, os gestores de palavras-passe reduzem os prémios de seguros. As seguradoras de ciberseguros oferecem agora descontos de 10–15 % a organizações que utilizam gestão centralizada de credenciais com registo de auditoria, o que reflete diretamente a redução do risco de violação de dados.

As poupanças de tempo acumulam-se. Os utilizadores finais deixam de repor palavras-passe esquecidas: autenticam-se uma vez no cofre e acedem a todas as credenciais. Os administradores de TI deixam de ter de apurar quem tem acesso a quê, porque o RBAC e os logs de auditoria dão visibilidade imediata. A integração de um novo programador demora horas em vez de dias.

Funcionalidades do gestor de palavras-passe e requisitos do artigo 21.º da NIS2

O artigo 21.º da NIS2 exige «medidas técnicas, operacionais e organizativas adequadas e proporcionadas» para gerir os riscos de cibersegurança. As 10 medidas são obrigatórias para todas as entidades abrangidas. Os gestores de palavras-passe respondem aos principais vetores de ataque baseados em credenciais ao longo destes requisitos:

O Passwork fornece provas diretas de conformidade em 9 das 10 medidas da NIS2. Os logs de acesso e os registos de auditoria imutáveis satisfazem as medidas 1, 2 e 6. O armazenamento cifrado cobre a medida 8. O RBAC, a imposição da autenticação multifator (MFA) e o controlo de acesso ao nível do ativo concluem as medidas 9 e 10, em que os reguladores exigem prova técnica.

On-premise ou cloud: Escolher a gestão de palavras-passe para a soberania de dados na UE

O debate entre on-premise e cloud depende da residência dos dados, do controlo e do alinhamento regulamentar.

Os gestores de palavras-passe na cloud oferecem rapidez e simplicidade, mas introduzem dependência de um fornecedor terceiro. Os dados saem da infraestrutura da organização, atravessam fronteiras e podem desencadear restrições de transferência do RGPD. As implementações de cloud padrão alojadas fora da UE criam atritos de conformidade para as organizações que tratam dados sensíveis da UE.

No entanto, as soluções de cloud soberana da UE alteram esta equação. O Passwork Cloud, alojado exclusivamente em centros de dados da UE, sem transferência de dados para fora do bloco, elimina as preocupações com transferências transfronteiriças e mantém as vantagens da cloud: cópias de segurança automatizadas, clusters de failover e menor carga de TI. A implementação soberana na UE do Passwork satisfaz o artigo 32.º do RGPD (medidas de proteção de dados) e o artigo 21.º da NIS2 (expectativas de residência dos dados) sem o encargo operacional da gestão on-premise. As chaves de cifragem permanecem sob controlo da organização e os registos de auditoria são imutáveis.

Os gestores de palavras-passe on-premise mantêm todos os dados de credenciais na infraestrutura da organização. O Passwork on-premise oferece controlo total sobre as chaves de cifragem, os calendários de cópias de segurança, as políticas de acesso e a segurança física. Para as organizações que gerem infraestruturas críticas, dados classificados ou operam em redes com isolamento físico (air gap), a solução on-premise é a única opção. Está alinhada com o princípio da minimização de dados (um princípio central do RGPD) e proporciona a máxima certeza de conformidade.

A contrapartida: O Passwork on-premise exige maior esforço operacional de TI (aplicação de patches, cópias de segurança, recuperação de desastres, planeamento de capacidade). O Passwork Cloud reduz esse esforço e mantém a residência dos dados. A cloud padrão fora da UE introduz risco regulamentar.

Para as organizações da UE: O Passwork Cloud oferece a certeza de conformidade da solução on-premise com a simplicidade operacional da cloud. Os dados nunca saem da UE, as chaves de cifragem permanecem sob controlo da organização e os registos de auditoria são imutáveis, o que satisfaz o RGPD e a NIS2 sem o encargo da aplicação de patches.

Conformidade com a NIS2: O custo da ação face ao custo da inação

A conformidade com a NIS2 é obrigatória. O custo do incumprimento, com coimas até 15 milhões de euros mais a remediação de violações, excede largamente o investimento numa gestão adequada de credenciais. As organizações que constroem a conformidade sobre a base de um gestor de palavras-passe reduzem o custo total de propriedade e satisfazem os requisitos do artigo 21.º.

Um cofre de credenciais centralizado com RBAC, MFA e registo de auditoria imutável responde às medidas essenciais da NIS2: análise de riscos, resposta a incidentes, eficácia dos controlos, cifragem, governação de acessos e imposição da MFA. O benefício operacional: as equipas de TI gastam menos tempo no aprovisionamento manual de acessos e mais tempo em trabalho estratégico de segurança.

A escolha é binária: conformidade proativa (investir agora, evitar coimas) ou conformidade reativa (sofrer primeiro a violação, pagar depois).

O Passwork fornece esta base com uma implementação flexível: on-premise para as organizações que exigem soberania dos dados, ou cloud soberana da UE para as equipas que dão prioridade à simplicidade operacional. Ambos os modelos fornecem a prova técnica que os reguladores exigem: registos de auditoria imutáveis, RBAC até ao nível da pasta, compatibilidade com a MFA FIDO2/WebAuthn e cifragem AES-256.

O Passwork está disponível em modo on-premise (controlo total da infraestrutura) ou como cloud soberana da UE (residência dos dados garantida, conforme com o RGPD e a NIS2). Comparar as opções de implementação e pedir uma demonstração gratuita

Perguntas frequentes

O que é a NIS2 e quem tem de a cumprir?

A NIS2 (Network and Information Security Directive 2) é legislação da UE (UE 2022/2555) que exige que as entidades essenciais e importantes implementem medidas robustas de gestão de riscos de cibersegurança. As entidades essenciais incluem operadores de energia, transportes, água, saúde e infraestruturas digitais. As entidades importantes abrangem as finanças, os cuidados de saúde, a produção alimentar e outros setores críticos. O prazo de implementação foi outubro de 2024. O incumprimento implica coimas até 10 milhões de euros (entidades essenciais) ou 5 milhões de euros (entidades importantes), além dos custos de remediação de violações.

O que é o artigo 21.º da NIS2?

O artigo 21.º da NIS2 impõe dez medidas de base de gestão de riscos de cibersegurança: análise de riscos e políticas, tratamento de incidentes, continuidade de negócio, segurança da cadeia de abastecimento, desenvolvimento seguro, verificação da eficácia dos controlos, ciber-higiene e formação, cifragem, controlo de acesso e autenticação multifator. Estas medidas estão orientadas para resultados e não prescrevem ferramentas: as organizações têm de demonstrar que controlam quem acede a quê, quando e porquê. Um gestor de palavras-passe responde diretamente a seis destas dez medidas através da gestão centralizada de credenciais, do registo de auditoria e da governação de acessos.

Quanto pode custar uma coima da NIS2?

As entidades essenciais enfrentam coimas até 10 milhões de euros ou 2 % do volume de negócios anual mundial total, consoante o valor mais elevado. As entidades importantes enfrentam até 5 milhões de euros ou 1 % do volume de negócios. Uma empresa de serviços financeiros de média dimensão com 500 milhões de euros de receitas poderia enfrentar uma coima de 10 milhões de euros por uma única falha material de conformidade. Estas coimas acrescem aos custos de remediação de violações, que ascendem em média a 5,1 milhões de euros a nível mundial, segundo o 2025 Cost of a Data Breach Report da IBM.

Porque é que ocorre a maioria das violações de credenciais?

Oitenta e um por cento das violações de dados têm origem em credenciais roubadas ou fracas (IBM 2025 DBIR). As causas de fundo incluem a partilha de palavras-passe por e-mail ou folhas de cálculo, a reutilização de palavras-passe entre sistemas, a ausência de registo de acessos e a revogação tardia de credenciais quando os colaboradores saem. Um gestor de palavras-passe centralizado elimina estes vetores ao impor políticas de palavras-passe fortes, impedir a partilha de credenciais, registar todos os acessos e permitir a rotação em massa de palavras-passe em poucas horas.

Deve a implementação ser on-premise ou na cloud?

A solução on-premise oferece o máximo controlo sobre as chaves de cifragem, os calendários de cópias de segurança e a segurança física, o que é essencial para as organizações que tratam dados classificados ou operam em redes com isolamento físico (air gap). A cloud reduz a carga operacional (aplicação de patches, cópias de segurança, recuperação de desastres). A cloud soberana da UE (como o Passwork Cloud) consegue um meio-termo: os dados nunca saem dos centros de dados da UE, as chaves de cifragem permanecem sob controlo da organização e evita-se o encargo de aplicação de patches da solução on-premise. Para as organizações da UE que tratam dados regulados, a cloud soberana da UE satisfaz o RGPD e a NIS2 sem complexidade operacional.

É possível usar uma folha de cálculo ou o e-mail para a gestão de credenciais, em alternativa?

Não. A partilha manual de credenciais por folhas de cálculo, e-mail ou notas autocolantes falha imediatamente a conformidade com o artigo 21.º da NIS2. Os reguladores exigem prova de controlo de acesso (quem acedeu a quê), registos de auditoria (quando e porquê) e capacidade de revogação (remoção imediata do acesso). Uma folha de cálculo não oferece nenhum destes elementos. Um gestor de palavras-passe centralizado com RBAC e registo de auditoria imutável é a base mínima viável de conformidade.

O que é o RBAC e porque é que a NIS2 o exige?

O RBAC (controlo de acesso baseado em funções) consiste em atribuir permissões a grupos em vez de a indivíduos. Quando um programador se junta à equipa de DevOps, herda automaticamente o acesso da equipa aos cofres. Quando sai, a revogação faz-se uma única vez. O artigo 21.º da NIS2 (medida 9) exige direitos de acesso documentados e revogação imediata. O RBAC satisfaz este requisito ao eliminar o aprovisionamento manual por utilizador e ao proporcionar visibilidade imediata sobre quem tem acesso a quê.

A NIS2 exige autenticação multifator?

Sim. O artigo 21.º da NIS2 (medida 10) impõe a autenticação multifator a todas as entidades abrangidas. As orientações técnicas da ENISA especificam três níveis de robustez da MFA, e a autenticação resistente a phishing (FIDO2/WebAuthn) é obrigatória para todas as contas privilegiadas. Um gestor de palavras-passe impõe a MFA ao nível do cofre, o que garante que cada acesso a credenciais exige um segundo fator e satisfaz este requisito em toda a organização.

Como ajuda o Passwork na conformidade com a NIS2?

O Passwork fornece registos de auditoria imutáveis, RBAC até ao nível da pasta, compatibilidade com a MFA FIDO2/WebAuthn e cifragem AES-256, ou seja, a prova técnica que os reguladores exigem. Responde diretamente a nove das dez medidas do artigo 21.º. O Passwork está disponível em modo on-premise (controlo total da infraestrutura) ou como cloud soberana da UE (residência dos dados garantida, conforme com o RGPD e a NIS2). Ambas as implementações fornecem a governação de credenciais, o registo de acessos e a documentação de conformidade necessários para passar numa auditoria regulamentar.

Die NIS2-Richtlinie (EU 2022/2555) ist jetzt in ganz Europa in Kraft. Wesentliche und wichtige Einrichtungen haben eine verbindliche Frist: Bis Oktober 2024 müssen robuste Maßnahmen zum Management von Cybersicherheitsrisiken implementiert werden — andernfalls drohen Bußgelder von bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes. Die meisten Organisationen unterschätzen die operativen Kosten der Compliance. Ein Passwortmanager bildet das Fundament, das die Einhaltung von Artikel 21 ermöglicht — ohne das Budget zu sprengen oder Ihr IT-Team zu überlasten.

Kernaussagen

• NIS2 Artikel 21 ist ergebnisorientiert, nicht werkzeugspezifisch. Regulierungsbehörden verlangen den Nachweis, dass Ihre Organisation kontrolliert, wer auf was, wann und warum zugreift. Ein zentraler Passwortmanager mit RBAC und Audit-Protokollierung verwandelt dies von einer Compliance-Schwachstelle in einen dokumentierten, auditierbaren Prozess.
• Die Kosten der Nichteinhaltung übersteigen die Compliance-Investition bei Weitem. Direkte Bußgelder erreichen 10 Millionen Euro für wesentliche Einrichtungen, hinzu kommen durchschnittlich 5,1 Millionen Euro an Kosten für die Behebung von Sicherheitsverletzungen. Eine einzige vermeidbare Kompromittierung von Anmeldedaten kostet mehr als die Implementierung eines Passwortmanagers — der ROI ist sofort und unbestreitbar.
• 81 Prozent der Datenschutzverletzungen lassen sich auf gestohlene oder schwache Anmeldedaten zurückführen. Ein Passwortmanager eliminiert diesen Angriffsvektor, indem er starke Passwortrichtlinien durchsetzt, die Wiederverwendung von Anmeldedaten verhindert, unbefugten Zugriff durch Audit-Protokolle erkennt und die Massenrotation von Passwörtern innerhalb von Stunden nach einer Kompromittierung ermöglicht.
• Passwortbezogene Helpdesk-Tickets verbrauchen 30–50 % der IT-Support-Kapazität. Ein Passwortmanager reduziert diese Tickets um bis zu 40 % und gibt IT-Mitarbeitern Freiraum für strategische Aufgaben. Die jährlichen Einsparungen erreichen 210.000 Euro für eine typische mittelständische Organisation, wenn Helpdesk-Arbeitskosten, Audit-Zeitaufwand und Incident-Response-Kosten berücksichtigt werden.
• EU-Datensouveränität ist ohne operative Komplexität erreichbar. Passwork Cloud hostet Daten vollständig in EU-Rechenzentren ohne grenzüberschreitende Übertragungen und erfüllt damit DSGVO Artikel 32 und NIS2 Artikel 21. Sie behalten die Kontrolle über die Verschlüsselungsschlüssel und unveränderliche Audit-Trails, während Sie den Patching-Aufwand einer On-Premise-Bereitstellung vermeiden.
• Die Wahl ist binär: Proaktive Compliance oder reaktive Compliance. Investieren Sie jetzt, um Bußgelder zu vermeiden, oder zahlen Sie später nach einer Sicherheitsverletzung 15 Millionen Euro. Europäische Organisationen entscheiden sich für Ersteres — sie bauen Compliance auf einem Passwortmanager-Fundament auf, das den operativen Aufwand reduziert und gleichzeitig regulatorische Anforderungen erfüllt.

NIS2 Artikel 21 verstehen: Der Kern des Cybersicherheits-Risikomanagements

NIS2 Artikel 21 schreibt vor, dass wesentliche und wichtige Einrichtungen technische, operative und organisatorische Maßnahmen zum Management von Cybersicherheitsrisiken implementieren. Diese Maßnahmen umfassen zehn grundlegende Sicherheitsbereiche: Zugriffskontrolle, Authentifizierung, Verschlüsselung, Incident-Handling, Lieferkettensicherheit und andere. Die Richtlinie schreibt keine spezifischen Tools vor — sie definiert Ergebnisse. Ein Passwortmanager erfüllt direkt mehrere Anforderungen von Artikel 21, indem er das Anmeldedaten-Management zentralisiert, starke Authentifizierungsrichtlinien durchsetzt und unveränderliche Audit-Trails führt.

Die zentrale Herausforderung: Artikel 21 ist ergebnisorientiert, nicht werkzeugorientiert. Compliance-Beauftragte müssen nachweisen, dass ihre Organisation kontrolliert, wer auf was, wann und warum zugreift. Manuelles Teilen von Passwörtern per E-Mail, Tabellenkalkulation oder Haftnotizen besteht diesen Test sofort nicht. Ein zentraler Credential-Tresor mit rollenbasierter Zugriffskontrolle (RBAC) und umfassender Protokollierung verwandelt dies von einer Compliance-Schwachstelle in einen dokumentierten, auditierbaren Prozess.

Die versteckten Kosten der NIS2-Nichteinhaltung

Nichteinhaltung verursacht zwei unterschiedliche Kostenkategorien: direkte Bußgelder und indirekte Kosten durch Sicherheitsverletzungen.

• Direkte Bußgelder sind erheblich. NIS2 Artikel 34 legt Strafen von bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes für wesentliche Einrichtungen fest, sowie 5 Millionen Euro oder 1 % für wichtige Einrichtungen. Ein mittelständisches Finanzdienstleistungsunternehmen mit 500 Millionen Euro Umsatz riskiert ein potenzielles Bußgeld von 10 Millionen Euro für einen einzigen wesentlichen Compliance-Verstoß.
• Indirekte Kosten übersteigen die Bußgelder bei Weitem. Laut IBMs Cost of a Data Breach Report 2025 erreichten die durchschnittlichen globalen Kosten einer Sicherheitsverletzung 5,1 Millionen Dollar — und das vor Inkrafttreten der NIS2-Strafen. Schwaches Anmeldedaten-Management ist die Hauptursache: 81 % der Datenschutzverletzungen lassen sich auf gestohlene oder schwache Anmeldedaten zurückführen. Ein Passwortmanager eliminiert diesen Angriffsvektor vollständig, indem er starke Passwortrichtlinien durchsetzt, die Wiederverwendung von Anmeldedaten verhindert und unbefugte Zugriffsversuche durch Audit-Protokolle erkennt.

Betrachten Sie die Rechnung: Eine einzige vermeidbare Sicherheitsverletzung kostet 5,1 Millionen Euro an Behebung, Benachrichtigung und Geschäftsverlust. Ein NIS2-Bußgeld addiert weitere 10 Millionen Euro. Die Implementierung eines Passwortmanagers ist nur ein Bruchteil dieser Kosten — und der ROI ist sofort und unbestreitbar.

Den ROI quantifizieren: Wie ein Passwortmanager Ihnen Geld und Zeit spart

Passwortbezogene Helpdesk-Tickets verbrauchen 30–50 % der IT-Support-Kapazität. Ein typisches Ticket kostet 50–100 Euro an Arbeitsaufwand. Für eine 100-Personen-Organisation bedeutet das jährlich 1.500–2.500 Tickets — 75.000–250.000 Euro an reinem Helpdesk-Overhead. Die Implementierung eines Passwortmanagers reduziert diese Tickets um bis zu 40 % und gibt IT-Mitarbeitern Freiraum für strategische Aufgaben.

Über operative Einsparungen hinaus senken Passwortmanager die Versicherungsprämien. Cyberversicherungsanbieter gewähren mittlerweile 10–15 % Rabatt für Organisationen, die zentrales Anmeldedaten-Management mit Audit-Protokollierung einsetzen — ein direktes Abbild des reduzierten Risikos von Sicherheitsverletzungen.

Zeiteinsparungen summieren sich. Endbenutzer müssen vergessene Passwörter nicht mehr zurücksetzen — sie authentifizieren sich einmal am Tresor und greifen auf alle Anmeldedaten zu. IT-Administratoren müssen nicht mehr nachverfolgen, wer auf was Zugriff hat — RBAC und Audit-Protokolle bieten sofortige Transparenz. Das Onboarding eines neuen Entwicklers dauert Stunden statt Tage.

Passwortmanager-Funktionen auf NIS2-Artikel-21-Anforderungen abbilden

NIS2 Artikel 21 verlangt „geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen" zur Bewältigung von Cybersicherheitsrisiken. Alle 10 Maßnahmen sind für jede betroffene Einrichtung obligatorisch. Passwortmanager adressieren die zentralen Angriffsvektoren auf Basis von Anmeldedaten über diese Anforderungen hinweg:

Passwork liefert direkte Compliance-Nachweise für 9 der 10 NIS2-Maßnahmen. Zugriffsprotokolle und unveränderliche Audit-Trails erfüllen die Maßnahmen 1, 2 und 6. Verschlüsselte Speicherung deckt Maßnahme 8 ab. RBAC, MFA-Durchsetzung und Zugriffskontrolle auf Asset-Ebene schließen die Maßnahmen 9 und 10 ab — dort, wo Regulierungsbehörden technische Nachweise verlangen.

On-Premise vs. Cloud: Die richtige Passwortverwaltung für EU-Datensouveränität wählen

Die Debatte On-Premise vs. Cloud dreht sich um Datenresidenz, Kontrolle und regulatorische Konformität.

Cloud-Passwortmanager bieten Geschwindigkeit und Einfachheit, führen aber zu einer Abhängigkeit von einem Drittanbieter. Daten verlassen Ihre Infrastruktur, überqueren Grenzen und lösen möglicherweise DSGVO-Übertragungsbeschränkungen aus. Standard-Cloud-Bereitstellungen, die außerhalb der EU gehostet werden, erzeugen Compliance-Reibung für Organisationen, die sensible EU-Daten verarbeiten.

Allerdings ändern EU-souveräne Cloud-Lösungen diese Gleichung. Passwork Cloud, vollständig in EU-Rechenzentren gehostet ohne Datenübertragung außerhalb des Blocks, eliminiert Bedenken bezüglich grenzüberschreitender Übertragungen und behält gleichzeitig die Cloud-Vorteile: automatisierte Backups, Failover-Clustering und reduzierter IT-Overhead. Passworks EU-souveräne Bereitstellung erfüllt DSGVO Artikel 32 (Datenschutzmaßnahmen) und NIS2 Artikel 21 (Datenresidenz-Erwartungen) ohne die operative Belastung einer On-Premise-Verwaltung. Ihre Verschlüsselungsschlüssel bleiben unter Ihrer Kontrolle, und Audit-Trails sind unveränderlich.

On-Premise-Passwortmanager halten alle Anmeldedaten innerhalb Ihrer Infrastruktur. Passwork On-Premise gibt Ihnen vollständige Kontrolle über Verschlüsselungsschlüssel, Backup-Zeitpläne, Zugriffsrichtlinien und physische Sicherheit. Für Organisationen, die kritische Infrastruktur oder klassifizierte Daten verarbeiten oder in Air-Gapped-Netzwerken arbeiten, ist On-Premise die einzige Option. Es entspricht dem Prinzip der Datenminimierung (ein DSGVO-Kernprinzip) und bietet maximale Compliance-Sicherheit.

Der Kompromiss: Passwork On-Premise erfordert mehr IT-operativen Overhead (Patching, Backups, Disaster Recovery, Kapazitätsplanung). Passwork Cloud reduziert diesen Overhead bei gleichzeitiger Datenresidenz. Standard-Cloud außerhalb der EU führt zu regulatorischen Risiken.

Für EU-Organisationen: Passwork Cloud bietet die Compliance-Sicherheit von On-Premise mit der operativen Einfachheit der Cloud. Daten verlassen niemals die EU, Verschlüsselungsschlüssel bleiben unter Ihrer Kontrolle, und Audit-Trails sind unveränderlich — was sowohl DSGVO als auch NIS2 erfüllt, ohne den Patching-Aufwand.

NIS2-Compliance: Die Kosten des Handelns vs. Nichthandelns

NIS2-Compliance ist obligatorisch. Die Kosten der Nichteinhaltung — Bußgelder von bis zu 15 Millionen Euro plus Kosten für die Behebung von Sicherheitsverletzungen — übersteigen bei Weitem die Investition in ordnungsgemäßes Anmeldedaten-Management. Organisationen, die Compliance auf einem Passwortmanager-Fundament aufbauen, reduzieren die Gesamtbetriebskosten und erfüllen gleichzeitig die Anforderungen von Artikel 21.

Ein zentraler Credential-Tresor mit RBAC, MFA und unveränderlicher Audit-Protokollierung adressiert die Kern-NIS2-Maßnahmen: Risikoanalyse, Incident Response, Wirksamkeit der Kontrollen, Verschlüsselung, Zugriffsgovernance und MFA-Durchsetzung. Der operative Vorteil: IT-Teams verbringen weniger Zeit mit manueller Zugriffsbereitstellung und mehr Zeit mit strategischer Sicherheitsarbeit.

Die Wahl ist binär: Proaktive Compliance (jetzt investieren, Bußgelder vermeiden) oder reaktive Compliance (erst Sicherheitsverletzung, dann zahlen).

Passwork liefert dieses Fundament mit flexibler Bereitstellung: On-Premise für Organisationen, die Datensouveränität benötigen, oder EU-souveräne Cloud für Teams, die operative Einfachheit priorisieren. Beide Modelle liefern die technischen Nachweise, die Regulierungsbehörden verlangen — unveränderliche Audit-Trails, RBAC bis auf Ordnerebene, FIDO2/WebAuthn-MFA-Unterstützung und AES-256-Verschlüsselung.

Passwork ist als On-Premise (vollständige Infrastrukturkontrolle) oder EU-souveräne Cloud (Datenresidenz garantiert, DSGVO- und NIS2-konform) verfügbar. Bereitstellungsoptionen vergleichen und kostenlose Demo anfordern

Häufig gestellte Fragen

Was ist NIS2 und wer muss die Vorgaben erfüllen?

NIS2 (Network and Information Security Directive 2) ist eine EU-Gesetzgebung (EU 2022/2555), die von wesentlichen und wichtigen Einrichtungen verlangt, robuste Maßnahmen zum Management von Cybersicherheitsrisiken zu implementieren. Wesentliche Einrichtungen umfassen Betreiber in den Bereichen Energie, Transport, Wasser, Gesundheit und digitale Infrastruktur. Wichtige Einrichtungen umfassen Finanzen, Gesundheitswesen, Lebensmittelproduktion und andere kritische Sektoren. Die Frist für die Umsetzung war Oktober 2024. Bei Nichteinhaltung drohen Bußgelder von bis zu 10 Millionen Euro (wesentliche Einrichtungen) oder 5 Millionen Euro (wichtige Einrichtungen), zuzüglich Kosten für die Behebung von Sicherheitsverletzungen.

Was ist NIS2 Artikel 21?

NIS2 Artikel 21 schreibt zehn grundlegende Maßnahmen zum Management von Cybersicherheitsrisiken vor: Risikoanalyse und Richtlinien, Incident-Handling, Geschäftskontinuität, Lieferkettensicherheit, sichere Entwicklung, Überprüfung der Wirksamkeit von Kontrollen, Cyberhygiene und Schulung, Verschlüsselung, Zugriffskontrolle und Multi-Faktor-Authentifizierung. Diese Maßnahmen sind ergebnisorientiert, nicht werkzeugspezifisch — Organisationen müssen nachweisen, dass sie kontrollieren, wer auf was, wann und warum zugreift. Ein Passwortmanager adressiert direkt sechs dieser zehn Maßnahmen durch zentrales Anmeldedaten-Management, Audit-Protokollierung und Zugriffsgovernance.

Wie hoch kann ein NIS2-Bußgeld ausfallen?

Wesentliche Einrichtungen riskieren Bußgelder von bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes — je nachdem, welcher Betrag höher ist. Wichtige Einrichtungen riskieren bis zu 5 Millionen Euro oder 1 % des Umsatzes. Ein mittelständisches Finanzdienstleistungsunternehmen mit 500 Millionen Euro Umsatz könnte ein Bußgeld von 10 Millionen Euro für einen einzigen wesentlichen Compliance-Verstoß erhalten. Diese Bußgelder kommen zusätzlich zu den Kosten für die Behebung von Sicherheitsverletzungen, die laut IBMs Cost of a Data Breach Report 2025 global durchschnittlich 5,1 Millionen Euro betragen.

Warum passieren die meisten Sicherheitsverletzungen durch Anmeldedaten?

81 Prozent der Datenschutzverletzungen lassen sich auf gestohlene oder schwache Anmeldedaten zurückführen (IBM 2025 DBIR). Die Hauptursachen sind: gemeinsam genutzte Passwörter per E-Mail oder Tabellenkalkulation, Wiederverwendung von Passwörtern über Systeme hinweg, fehlende Zugriffsprotokollierung und verzögerter Widerruf von Anmeldedaten, wenn Mitarbeiter das Unternehmen verlassen. Ein zentraler Passwortmanager eliminiert diese Vektoren, indem er starke Passwortrichtlinien durchsetzt, das Teilen von Anmeldedaten verhindert, jeden Zugriff protokolliert und die Massenrotation von Passwörtern innerhalb von Stunden ermöglicht.

Sollten wir On-Premise oder Cloud bereitstellen?

On-Premise gibt Ihnen maximale Kontrolle über Verschlüsselungsschlüssel, Backup-Zeitpläne und physische Sicherheit — unverzichtbar für Organisationen, die klassifizierte Daten verarbeiten oder in Air-Gapped-Netzwerken arbeiten. Cloud reduziert den operativen Overhead (Patching, Backups, Disaster Recovery). EU-souveräne Cloud (wie Passwork Cloud) bietet einen Kompromiss: Daten verlassen niemals EU-Rechenzentren, Verschlüsselungsschlüssel bleiben unter Ihrer Kontrolle, und Sie vermeiden den Patching-Aufwand von On-Premise. Für EU-Organisationen, die regulierte Daten verarbeiten, erfüllt EU-souveräne Cloud sowohl DSGVO als auch NIS2 ohne operative Komplexität.

Können wir stattdessen eine Tabellenkalkulation oder E-Mail für das Anmeldedaten-Management verwenden?

Nein. Manuelles Teilen von Anmeldedaten über Tabellenkalkulationen, E-Mail oder Haftnotizen besteht die NIS2-Artikel-21-Compliance sofort nicht. Regulierungsbehörden verlangen den Nachweis von Zugriffskontrolle (wer hat auf was zugegriffen), Audit-Trails (wann und warum) und Widerrufsfähigkeit (sofortige Entfernung des Zugriffs). Eine Tabellenkalkulation bietet nichts davon. Ein zentraler Passwortmanager mit RBAC und unveränderlicher Audit-Protokollierung ist das minimal erforderliche Compliance-Fundament.

Was ist RBAC und warum verlangt NIS2 es?

RBAC (rollenbasierte Zugriffskontrolle) bedeutet, Berechtigungen Gruppen statt Einzelpersonen zu gewähren. Wenn ein Entwickler dem DevOps-Team beitritt, erbt er automatisch den Tresorzugriff des Teams. Wenn er das Team verlässt, widerrufen Sie den Zugriff einmal. NIS2 Artikel 21 (Maßnahme 9) verlangt dokumentierte Zugriffsrechte und sofortigen Widerruf. RBAC erfüllt dies, indem es die manuelle Bereitstellung pro Benutzer eliminiert und sofortige Transparenz darüber bietet, wer auf was Zugriff hat.

Verlangt NIS2 Multi-Faktor-Authentifizierung?

Ja. NIS2 Artikel 21 (Maßnahme 10) schreibt Multi-Faktor-Authentifizierung für alle betroffenen Einrichtungen vor. Die technischen Leitlinien der ENISA spezifizieren drei Stufen der MFA-Stärke, wobei Phishing-resistente Authentifizierung (FIDO2/WebAuthn) für alle privilegierten Konten obligatorisch ist. Ein Passwortmanager setzt MFA auf Tresorebene durch und stellt sicher, dass jeder Zugriff auf Anmeldedaten einen zweiten Faktor erfordert — womit diese Anforderung für die gesamte Organisation erfüllt wird.

Wie hilft Passwork bei der NIS2-Compliance?

Passwork liefert unveränderliche Audit-Trails, RBAC bis auf Ordnerebene, FIDO2/WebAuthn-MFA-Unterstützung und AES-256-Verschlüsselung — die technischen Nachweise, die Regulierungsbehörden verlangen. Es adressiert direkt neun der zehn Maßnahmen von Artikel 21. Passwork ist als On-Premise (vollständige Infrastrukturkontrolle) oder EU-souveräne Cloud (Datenresidenz garantiert, DSGVO- und NIS2-konform) verfügbar. Beide Bereitstellungen bieten die Anmeldedaten-Governance, Zugriffsprotokollierung und Compliance-Dokumentation, die erforderlich sind, um ein regulatorisches Audit zu bestehen.

La Directiva NIS2 (UE 2022/2555) ya está en vigor en toda Europa. Las entidades esenciales e importantes se enfrentan a un plazo estricto: implementar medidas sólidas de gestión de riesgos de ciberseguridad antes de octubre de 2024 o enfrentar multas de hasta 10 millones de euros o el 2% de la facturación anual global. La mayoría de las organizaciones subestiman el coste operativo del cumplimiento. Un gestor de contraseñas es la base que hace alcanzable el cumplimiento del Artículo 21 sin agotar el presupuesto ni sobrecargar a su equipo de TI.

Puntos clave

• El Artículo 21 de NIS2 se centra en resultados, no prescribe herramientas. Los reguladores exigen pruebas de que su organización controla quién accede a qué, cuándo y por qué. Un gestor de contraseñas centralizado con RBAC y registro de auditoría transforma esto de un problema de cumplimiento en un proceso documentado y auditable.
• Los costes del incumplimiento superan con creces la inversión en cumplimiento. Las multas directas alcanzan los 10 millones de euros para entidades esenciales, más 5,1 millones de euros en costes medios de remediación de brechas. Una sola brecha de credenciales prevenible cuesta más que implementar un gestor de contraseñas — el ROI es inmediato e innegable.
• El ochenta y uno por ciento de las brechas de datos se originan por credenciales robadas o débiles. Un gestor de contraseñas elimina este vector aplicando políticas de contraseñas fuertes, previniendo la reutilización de credenciales, detectando accesos no autorizados mediante registros de auditoría y permitiendo la rotación masiva de contraseñas en cuestión de horas tras un compromiso.
• Los tickets de soporte relacionados con contraseñas consumen entre el 30 y el 50% de la capacidad del servicio de TI. Un gestor de contraseñas reduce estos tickets hasta en un 40%, liberando al personal de TI para trabajo estratégico. El ahorro anual alcanza los 210.000 euros para una organización mediana típica, considerando la mano de obra del servicio de asistencia, el tiempo de auditoría de cumplimiento y los costes de respuesta a incidentes.
• La soberanía de datos en la UE es alcanzable sin complejidad operativa. Passwork Cloud aloja los datos íntegramente en centros de datos de la UE sin transferencias transfronterizas, cumpliendo el Artículo 32 del RGPD y el Artículo 21 de NIS2. Usted mantiene el control de las claves de cifrado y las pistas de auditoría inmutables, evitando la carga de actualización del despliegue local.
• La elección es binaria: cumplimiento proactivo o cumplimiento reactivo. Invierta ahora para evitar multas, o sufra una brecha primero y pague 15 millones de euros después. Las organizaciones europeas están eligiendo lo primero — construyendo el cumplimiento sobre una base de gestor de contraseñas que reduce la carga operativa mientras satisface los requisitos regulatorios.

Comprender el Artículo 21 de NIS2: El núcleo de la gestión de riesgos de ciberseguridad

El Artículo 21 de NIS2 exige que las entidades esenciales e importantes implementen medidas técnicas, operativas y organizativas de gestión de riesgos de ciberseguridad. Estas medidas abarcan diez áreas de seguridad básicas: control de acceso, autenticación, cifrado, gestión de incidentes, seguridad de la cadena de suministro y otras. La directiva no prescribe herramientas específicas — define resultados. Un gestor de contraseñas aborda directamente múltiples requisitos del Artículo 21 al centralizar la gestión de credenciales, aplicar políticas de autenticación fuertes y mantener pistas de auditoría inmutables.

El desafío principal: El Artículo 21 se centra en resultados, no en herramientas. Los responsables de cumplimiento deben demostrar que su organización controla quién accede a qué, cuándo y por qué. El intercambio manual de contraseñas por correo electrónico, hojas de cálculo o notas adhesivas falla esta prueba inmediatamente. Una bóveda de credenciales centralizada con control de acceso basado en roles (RBAC) y registro completo transforma esto de un problema de cumplimiento en un proceso documentado y auditable.

Los costes ocultos del incumplimiento de NIS2

El incumplimiento conlleva dos categorías de costes distintas: multas directas y costes indirectos por brechas.

• Las multas directas son severas. El Artículo 34 de NIS2 establece sanciones de hasta 10 millones de euros o el 2% de la facturación anual global total para entidades esenciales, y 5 millones de euros o el 1% para entidades importantes. Una empresa de servicios financieros de tamaño mediano con 500 millones de euros de ingresos enfrenta una multa potencial de 10 millones de euros por un solo incumplimiento material.
• Los costes indirectos superan a las multas. Según el Informe del Coste de una Brecha de Datos 2025 de IBM, el coste medio global de una brecha alcanzó los 5,1 millones de dólares — y eso es antes de que se apliquen las sanciones de NIS2. La gestión deficiente de credenciales es la causa raíz: el 81% de las brechas de datos se originan por credenciales robadas o débiles. Un gestor de contraseñas elimina este vector por completo aplicando políticas de contraseñas fuertes, previniendo la reutilización de credenciales y detectando intentos de acceso no autorizado mediante registros de auditoría.

Considere los números: una sola brecha prevenible cuesta 5,1 millones de euros en remediación, notificación y pérdida de negocio. Una multa de NIS2 añade 10 millones de euros. La implementación de un gestor de contraseñas es una fracción de estos costes — y el ROI es inmediato e innegable.

Cuantificando el ROI: Cómo un gestor de contraseñas le ahorra dinero y tiempo

Los tickets de soporte relacionados con contraseñas consumen entre el 30 y el 50% de la capacidad del servicio de TI. Un ticket típico cuesta entre 50 y 100 euros en mano de obra. Para una organización de 100 personas, eso son entre 1.500 y 2.500 tickets anuales — entre 75.000 y 250.000 euros en gastos generales de soporte técnico. Implementar un gestor de contraseñas reduce estos tickets hasta en un 40%, liberando al personal de TI para trabajo estratégico.

Más allá del ahorro operativo, los gestores de contraseñas reducen las primas de seguro. Las aseguradoras de ciberriesgos ahora ofrecen descuentos del 10-15% para organizaciones que utilizan gestión centralizada de credenciales con registro de auditoría — un reflejo directo de la reducción del riesgo de brechas.

El ahorro de tiempo se acumula. Los usuarios finales ya no restablecen contraseñas olvidadas — se autentican una vez en la bóveda y acceden a todas las credenciales. Los administradores de TI ya no persiguen quién tiene acceso a qué — el RBAC y los registros de auditoría proporcionan visibilidad instantánea. La incorporación de un nuevo desarrollador toma horas en lugar de días.

Correspondencia entre las funciones del gestor de contraseñas y los requisitos del Artículo 21 de NIS2

El Artículo 21 de NIS2 requiere «medidas técnicas, operativas y organizativas apropiadas y proporcionadas» para gestionar los riesgos de ciberseguridad. Las 10 medidas son obligatorias para toda entidad cubierta. Los gestores de contraseñas abordan los vectores de ataque basados en credenciales principales a través de estos requisitos:

Passwork proporciona evidencia directa de cumplimiento en 9 de las 10 medidas de NIS2. Los registros de acceso y las pistas de auditoría inmutables satisfacen las medidas 1, 2 y 6. El almacenamiento cifrado cubre la medida 8. El RBAC, la aplicación de MFA y el control de acceso a nivel de activo completan las medidas 9 y 10 — donde los reguladores exigen pruebas técnicas.

Local vs. nube: Elegir la gestión de contraseñas adecuada para la soberanía de datos en la UE

El debate entre local y nube gira en torno a la residencia de datos, el control y la alineación regulatoria.

Los gestores de contraseñas en la nube ofrecen velocidad y simplicidad, pero introducen dependencia de un proveedor externo. Los datos salen de su infraestructura, cruzan fronteras y potencialmente activan restricciones de transferencia del RGPD. Los despliegues estándar en la nube alojados fuera de la UE crean fricciones de cumplimiento para organizaciones que manejan datos sensibles de la UE.

Sin embargo, las soluciones de nube con soberanía en la UE cambian esta ecuación. Passwork Cloud, alojado íntegramente en centros de datos de la UE sin transferencia de datos fuera del bloque, elimina las preocupaciones sobre transferencias transfronterizas mientras mantiene los beneficios de la nube: copias de seguridad automatizadas, clústeres de conmutación por error y menor carga de TI. El despliegue con soberanía en la UE de Passwork satisface el Artículo 32 del RGPD (medidas de protección de datos) y el Artículo 21 de NIS2 (expectativas de residencia de datos) sin la carga operativa de la gestión local. Sus claves de cifrado permanecen bajo su control y las pistas de auditoría son inmutables.

Los gestores de contraseñas locales mantienen todos los datos de credenciales dentro de su infraestructura. Passwork local le proporciona control total sobre las claves de cifrado, calendarios de respaldo, políticas de acceso y seguridad física. Para organizaciones que manejan infraestructura crítica, datos clasificados u operan en redes aisladas, la opción local es la única alternativa. Se alinea con el principio de minimización de datos (un principio fundamental del RGPD) y proporciona la máxima certeza de cumplimiento.

El compromiso: Passwork local requiere mayor carga operativa de TI (parches, copias de seguridad, recuperación ante desastres, planificación de capacidad). Passwork Cloud reduce esta carga manteniendo la residencia de datos. La nube estándar fuera de la UE introduce riesgo regulatorio.

Para organizaciones de la UE: Passwork Cloud ofrece la certeza de cumplimiento del despliegue local con la simplicidad operativa de la nube. Los datos nunca salen de la UE, las claves de cifrado permanecen bajo su control y las pistas de auditoría son inmutables — satisfaciendo tanto el RGPD como NIS2 sin la carga de actualización.

Cumplimiento de NIS2: El coste de actuar vs. no actuar

El cumplimiento de NIS2 es obligatorio. El coste del incumplimiento — multas de hasta 15 millones de euros más la remediación de brechas — supera con creces la inversión en una gestión adecuada de credenciales. Las organizaciones que construyen el cumplimiento sobre una base de gestor de contraseñas reducen el coste total de propiedad mientras satisfacen los requisitos del Artículo 21.

Una bóveda de credenciales centralizada con RBAC, MFA y registro de auditoría inmutable aborda las medidas principales de NIS2: análisis de riesgos, respuesta a incidentes, eficacia de controles, cifrado, gobernanza de acceso y aplicación de MFA. El beneficio operativo: los equipos de TI dedican menos tiempo al aprovisionamiento manual de accesos y más tiempo al trabajo de seguridad estratégico.

La elección es binaria: cumplimiento proactivo (invertir ahora, evitar multas) o cumplimiento reactivo (sufrir una brecha primero, pagar después).

Passwork proporciona esta base con despliegue flexible: local para organizaciones que requieren soberanía de datos, o nube con soberanía en la UE para equipos que priorizan la simplicidad operativa. Ambos modelos proporcionan las pruebas técnicas que exigen los reguladores — pistas de auditoría inmutables, RBAC hasta nivel de carpeta, soporte de MFA FIDO2/WebAuthn y cifrado AES-256.

Passwork está disponible como local (control total de infraestructura) o nube con soberanía en la UE (residencia de datos garantizada, compatible con RGPD y NIS2). Compare las opciones de despliegue y solicite una demostración gratuita

Preguntas frecuentes

¿Qué es NIS2 y quién debe cumplir?

NIS2 (Directiva de Seguridad de Redes y de la Información 2) es la legislación de la UE (UE 2022/2555) que exige a las entidades esenciales e importantes implementar medidas sólidas de gestión de riesgos de ciberseguridad. Las entidades esenciales incluyen operadores de energía, transporte, agua, salud e infraestructura digital. Las entidades importantes abarcan finanzas, salud, producción alimentaria y otros sectores críticos. El plazo de implementación fue octubre de 2024. El incumplimiento desencadena multas de hasta 10 millones de euros (entidades esenciales) o 5 millones de euros (entidades importantes), más los costes de remediación de brechas.

¿Qué es el Artículo 21 de NIS2?

El Artículo 21 de NIS2 establece diez medidas básicas de gestión de riesgos de ciberseguridad: análisis de riesgos y políticas, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, desarrollo seguro, verificación de la eficacia de controles, higiene cibernética y formación, cifrado, control de acceso y autenticación multifactor. Estas medidas se centran en resultados, no prescriben herramientas — las organizaciones deben demostrar que controlan quién accede a qué, cuándo y por qué. Un gestor de contraseñas aborda directamente seis de estas diez medidas mediante la gestión centralizada de credenciales, el registro de auditoría y la gobernanza de acceso.

¿Cuánto puede costar una multa de NIS2?

Las entidades esenciales enfrentan multas de hasta 10 millones de euros o el 2% de la facturación anual global total — lo que sea mayor. Las entidades importantes enfrentan hasta 5 millones de euros o el 1% de la facturación. Una empresa de servicios financieros de tamaño mediano con 500 millones de euros de ingresos podría enfrentar una multa de 10 millones de euros por un solo incumplimiento material. Estas multas son adicionales a los costes de remediación de brechas, que promedian 5,1 millones de euros a nivel global según el Informe del Coste de una Brecha de Datos 2025 de IBM.

¿Por qué ocurren la mayoría de las brechas de credenciales?

El ochenta y uno por ciento de las brechas de datos se originan por credenciales robadas o débiles (IBM 2025 DBIR). Las causas raíz incluyen contraseñas compartidas por correo electrónico u hojas de cálculo, reutilización de contraseñas entre sistemas, falta de registro de accesos y revocación tardía de credenciales cuando los empleados se van. Un gestor de contraseñas centralizado elimina estos vectores aplicando políticas de contraseñas fuertes, previniendo el intercambio de credenciales, registrando cada acceso y permitiendo la rotación masiva de contraseñas en horas.

¿Debemos desplegar local o en la nube?

El despliegue local proporciona control máximo sobre claves de cifrado, calendarios de respaldo y seguridad física — esencial para organizaciones que manejan datos clasificados u operan en redes aisladas. La nube reduce la carga operativa (parches, copias de seguridad, recuperación ante desastres). La nube con soberanía en la UE (como Passwork Cloud) divide la diferencia: los datos nunca salen de los centros de datos de la UE, las claves de cifrado permanecen bajo su control y se evita la carga de actualización del despliegue local. Para organizaciones de la UE que manejan datos regulados, la nube con soberanía en la UE satisface tanto el RGPD como NIS2 sin complejidad operativa.

¿Podemos usar una hoja de cálculo o correo electrónico para la gestión de credenciales en su lugar?

No. El intercambio manual de credenciales mediante hojas de cálculo, correo electrónico o notas adhesivas incumple inmediatamente el Artículo 21 de NIS2. Los reguladores exigen pruebas de control de acceso (quién accedió a qué), pistas de auditoría (cuándo y por qué) y capacidad de revocación (eliminación inmediata del acceso). Una hoja de cálculo no proporciona nada de esto. Un gestor de contraseñas centralizado con RBAC y registro de auditoría inmutable es la base mínima viable de cumplimiento.

¿Qué es RBAC y por qué lo exige NIS2?

RBAC (control de acceso basado en roles) significa otorgar permisos a grupos en lugar de individuos. Cuando un desarrollador se une al equipo de DevOps, hereda automáticamente el acceso a la bóveda del equipo. Cuando se va, se revoca una sola vez. El Artículo 21 de NIS2 (Medida 9) exige derechos de acceso documentados y revocación inmediata. El RBAC satisface esto eliminando el aprovisionamiento manual por usuario y proporcionando visibilidad instantánea de quién tiene acceso a qué.

¿NIS2 exige autenticación multifactor?

Sí. El Artículo 21 de NIS2 (Medida 10) establece la autenticación multifactor como obligatoria para todas las entidades cubiertas. La guía técnica de ENISA especifica tres niveles de fortaleza de MFA, siendo la autenticación resistente al phishing (FIDO2/WebAuthn) obligatoria para todas las cuentas privilegiadas. Un gestor de contraseñas aplica MFA a nivel de bóveda, asegurando que cada acceso a credenciales requiera un segundo factor — satisfaciendo este requisito en toda la organización.

¿Cómo ayuda Passwork con el cumplimiento de NIS2?

Passwork proporciona pistas de auditoría inmutables, RBAC hasta nivel de carpeta, soporte de MFA FIDO2/WebAuthn y cifrado AES-256 — las pruebas técnicas que exigen los reguladores. Aborda nueve de las diez medidas del Artículo 21 directamente. Passwork está disponible como local (control total de infraestructura) o nube con soberanía en la UE (residencia de datos garantizada, compatible con RGPD y NIS2). Ambos despliegues proporcionan la gobernanza de credenciales, el registro de accesos y la documentación de cumplimiento necesarios para pasar una auditoría regulatoria.

The NIS2 Directive (EU 2022/2555) is now live across Europe. Essential and important entities face a hard deadline: implement robust cybersecurity risk-management measures by October 2024 or face fines up to €10 million or 2% of global annual turnover. Most organizations underestimate the operational cost of compliance. A password manager is the foundation that makes Article 21 compliance achievable without breaking the budget or burning out your IT team.

Key Takeaways

• NIS2 Article 21 is outcome-focused, not tool-prescriptive. Regulators demand proof that your organization controls who accesses what, when, and why. A centralized password manager with RBAC and audit logging transforms this from a compliance liability into a documented, auditable process.
• Non-compliance costs far exceed compliance investment. Direct fines reach €10 million for essential entities, plus €5.1 million in average breach remediation costs. A single preventable credential breach costs more than implementing a password manager — the ROI is immediate and undeniable.
• Eighty-one percent of data breaches trace back to stolen or weak credentials. A password manager eliminates this vector by enforcing strong password policies, preventing credential reuse, detecting unauthorized access through audit logs, and enabling bulk password rotation within hours of a compromise.
• Password-related helpdesk tickets consume 30–50% of IT support capacity. A password manager reduces these tickets by up to 40%, freeing IT staff for strategic work. Annual savings reach €210,000 for a typical mid-sized organization when accounting for helpdesk labor, compliance audit time, and incident response costs.
• EU data sovereignty is achievable without operational complexity. Passwork Cloud hosts data entirely within EU data centers with no cross-border transfers, satisfying GDPR Article 32 and NIS2 Article 21. You retain encryption key control and immutable audit trails while avoiding the patching burden of on-premise deployment.
• The choice is binary: proactive compliance or reactive compliance. Invest now to avoid fines, or breach first and pay €15 million later. European organizations are choosing the former — building compliance on a password manager foundation that reduces operational overhead while satisfying regulatory requirements.

Understanding NIS2 Article 21: The core of cybersecurity risk management

NIS2 Article 21 mandates that essential and important entities implement technical, operational, and organizational cybersecurity risk-management measures. These measures span ten baseline security areas: access control, authentication, encryption, incident handling, supply chain security, and others. The directive doesn't prescribe specific tools — it defines outcomes. A password manager directly addresses multiple Article 21 requirements by centralizing credential management, enforcing strong authentication policies, and maintaining immutable audit trails.

The core challenge: Article 21 is outcome-focused, not tool-focused. Compliance officers must demonstrate that their organization controls who accesses what, when, and why. Manual password sharing via email, spreadsheets, or sticky notes fails this test immediately. A centralized credential vault with role-based access control (RBAC) and comprehensive logging transforms this from a compliance liability into a documented, auditable process.

The hidden costs of NIS2 non-compliance

Non-compliance carries two distinct cost categories: direct fines and indirect breach costs.

• Direct fines are brutal. NIS2 Article 34 establishes penalties up to €10 million or 2% of total global annual turnover for essential entities, and €5 million or 1% for important entities. A mid-sized financial services firm with €500 million in revenue faces a potential €10 million fine for a single material compliance failure.
• Indirect costs dwarf the fines. According to IBM's 2025 Cost of a Data Breach Report, the global average breach cost reached $5.1 million — and that's before NIS2 penalties kick in. Weak credential management is the root cause: 81% of data breaches trace back to stolen or weak credentials. A password manager eliminates this vector entirely by enforcing strong password policies, preventing credential reuse, and detecting unauthorized access attempts through audit logs.

Consider the math: a single preventable breach costs €5.1 million in remediation, notification, and lost business. A NIS2 fine adds €10 million. A password manager implementation is a fraction of these costs — and the ROI is immediate and undeniable.

Quantifying the ROI: How a password manager saves you money and time

Password-related helpdesk tickets consume 30–50% of IT support capacity. A typical ticket costs €50–€100 in labor. For a 100-person organization, that's 1,500–2,500 tickets annually — €75,000–€250,000 in pure helpdesk overhead. Implementing a password manager reduces these tickets by up to 40%, freeing IT staff for strategic work.

Beyond operational savings, password managers reduce insurance premiums. Cyber insurance carriers now offer 10–15% discounts for organizations using centralized credential management with audit logging — a direct reflection of reduced breach risk.

Time savings compound. End-users no longer reset forgotten passwords — they authenticate once to the vault and access all credentials. IT administrators no longer chase down who has access to what — RBAC and audit logs provide instant visibility. Onboarding a new developer takes hours instead of days.

Mapping password manager features to NIS2 Article 21 requirements

NIS2 Article 21 requires "appropriate and proportionate technical, operational and organisational measures" to manage cybersecurity risks. All 10 measures are mandatory for every covered entity. Password managers address the core credential-based attack vectors across these requirements:

Passwork delivers direct compliance evidence across 9 of the 10 NIS2 measures. Access logs and immutable audit trails satisfy measures 1, 2, and 6. Encrypted storage covers measure 8. RBAC, MFA enforcement, and asset-level access control close out measures 9 and 10 — where regulators demand technical proof.

On-premise vs. cloud: Choosing the right password management for EU data sovereignty

The on-premise vs. cloud debate hinges on data residency, control, and regulatory alignment.

Cloud password managers offer speed and simplicity but introduce dependency on a third-party provider. Data leaves your infrastructure, crossing borders and potentially triggering GDPR transfer restrictions. Standard cloud deployments hosted outside the EU create compliance friction for organizations handling sensitive EU data.

However, EU-sovereign cloud solutions change this equation. Passwork Cloud, hosted entirely within EU data centers with no data transfer outside the bloc, eliminates cross-border transfer concerns while retaining cloud benefits: automated backups, failover clustering, and reduced IT overhead. Passwork's EU-sovereign deployment satisfies GDPR Article 32 (data protection measures) and NIS2 Article 21 (data residency expectations) without the operational burden of on-premise management. Your encryption keys remain under your control, and audit trails are immutable.

On-premise password managers keep all credential data within your infrastructure. Passwork on-premise gives you complete control over encryption keys, backup schedules, access policies, and physical security. For organizations handling critical infrastructure, classified data, or operating in air-gapped networks, on-premise is the only option. It aligns with the principle of data minimization (a core GDPR tenet) and provides maximum compliance certainty.

The trade-off: Passwork on-premise requires more IT operational overhead (patching, backups, disaster recovery, capacity planning). Passwork Cloud reduces this overhead while maintaining data residency. Standard cloud outside the EU introduces regulatory risk.

For EU organizations: Passwork Cloud offers the compliance certainty of on-premise with the operational simplicity of cloud. Data never leaves the EU, encryption keys remain under your control, and audit trails are immutable — satisfying both GDPR and NIS2 without the patching burden.

NIS2 compliance: The cost of action vs. inaction

NIS2 compliance is mandatory. The cost of non-compliance — fines up to €15 million plus breach remediation — far exceeds the investment in proper credential management. Organizations that build compliance on a password manager foundation reduce total cost of ownership while satisfying Article 21 requirements.

A centralized credential vault with RBAC, MFA, and immutable audit logging addresses the core NIS2 measures: risk analysis, incident response, control effectiveness, encryption, access governance, and MFA enforcement. The operational benefit: IT teams spend less time on manual access provisioning and more time on strategic security work.

The choice is binary: proactive compliance (invest now, avoid fines) or reactive compliance (breach first, pay later).

Passwork delivers this foundation with flexible deployment: on-premise for organizations requiring data sovereignty, or EU-sovereign cloud for teams prioritizing operational simplicity. Both models provide the technical proof regulators demand — immutable audit trails, RBAC down to folder level, FIDO2/WebAuthn MFA support, and AES-256 encryption.

Passwork is available as on-premise (full infrastructure control) or EU-sovereign cloud (data residency guaranteed, GDPR and NIS2 compliant). Compare deployment options and request a free demo

Frequently Asked Questions

What is NIS2 and who must comply?

NIS2 (Network and Information Security Directive 2) is EU legislation (EU 2022/2555) requiring essential and important entities to implement robust cybersecurity risk-management measures. Essential entities include energy, transport, water, health, and digital infrastructure operators. Important entities span finance, healthcare, food production, and other critical sectors. The deadline for implementation was October 2024. Non-compliance triggers fines up to €10 million (essential entities) or €5 million (important entities), plus breach remediation costs.

What is NIS2 Article 21?

NIS2 Article 21 mandates ten baseline cybersecurity risk-management measures: risk analysis and policies, incident handling, business continuity, supply chain security, secure development, control effectiveness verification, cyber hygiene and training, encryption, access control, and multi-factor authentication. These measures are outcome-focused, not tool-prescriptive — organizations must demonstrate they control who accesses what, when, and why. A password manager directly addresses six of these ten measures through centralized credential management, audit logging, and access governance.

How much can a NIS2 fine cost?

Essential entities face fines up to €10 million or 2% of total global annual turnover — whichever is higher. Important entities face up to €5 million or 1% of turnover. A mid-sized financial services firm with €500 million in revenue could face a €10 million fine for a single material compliance failure. These fines are in addition to breach remediation costs, which average €5.1 million globally according to IBM's 2025 Cost of a Data Breach Report.

Why do most credential breaches happen?

Eighty-one percent of data breaches trace back to stolen or weak credentials (IBM 2025 DBIR). Root causes include shared passwords via email or spreadsheets, password reuse across systems, lack of access logging, and delayed credential revocation when employees leave. A centralized password manager eliminates these vectors by enforcing strong password policies, preventing credential sharing, logging every access, and enabling bulk password rotation within hours.

Should we deploy on-premise or cloud?

On-premise gives you maximum control over encryption keys, backup schedules, and physical security — essential for organizations handling classified data or operating in air-gapped networks. Cloud reduces operational overhead (patching, backups, disaster recovery). EU-sovereign cloud (like Passwork Cloud) splits the difference: data never leaves EU data centers, encryption keys remain under your control, and you avoid the patching burden of on-premise. For EU organizations handling regulated data, EU-sovereign cloud satisfies both GDPR and NIS2 without operational complexity.

Can we use a spreadsheet or email for credential management instead?

No. Manual credential sharing via spreadsheets, email, or sticky notes fails NIS2 Article 21 compliance immediately. Regulators require proof of access control (who accessed what), audit trails (when and why), and revocation capability (immediate removal of access). A spreadsheet provides none of these. A centralized password manager with RBAC and immutable audit logging is the minimum viable compliance foundation.

What is RBAC and why does NIS2 require it?

RBAC (role-based access control) means granting permissions to groups instead of individuals. When a developer joins the DevOps team, they inherit the team's vault access automatically. When they leave, you revoke it once. NIS2 Article 21 (Measure 9) requires documented access rights and immediate revocation. RBAC satisfies this by eliminating manual per-user provisioning and providing instant visibility into who has access to what.

Does NIS2 require multi-factor authentication?

Yes. NIS2 Article 21 (Measure 10) mandates multi-factor authentication for all covered entities. ENISA's technical guidance specifies three tiers of MFA strength, with phishing-resistant authentication (FIDO2/WebAuthn) mandatory for all privileged accounts. A password manager enforces MFA at the vault level, ensuring every credential access requires a second factor — satisfying this requirement across the entire organization.

How does Passwork help with NIS2 compliance?

Passwork delivers immutable audit trails, RBAC down to folder level, FIDO2/WebAuthn MFA support, and AES-256 encryption — the technical proof regulators demand. It addresses nine of the ten Article 21 measures directly. Passwork is available as on-premise (full infrastructure control) or EU-sovereign cloud (data residency guaranteed, GDPR and NIS2 compliant). Both deployments provide the credential governance, access logging, and compliance documentation needed to pass a regulatory audit.

A Diretiva NIS2 (UE 2022/2555) deixou de ser uma preocupação futura. Desde outubro de 2024, as organizações de 18 setores europeus têm de demonstrar conformidade com controlos de cibersegurança obrigatórios. As coimas podem atingir 10 milhões de euros ou 2 % do volume de negócios anual a nível mundial, e os membros dos órgãos de administração respondem pessoalmente pelo incumprimento.

No centro da NIS2 está o artigo 21.º, que impõe 10 medidas de segurança específicas. Entre estas, a gestão de acessos (governação de credenciais, controlo de acesso baseado em funções, autenticação multifator e registos de auditoria) é a mais auditável e a que está mais diretamente ligada ao resultado das violações de dados.

Este guia associa esses requisitos a passos práticos de implementação e mostra como gerar as evidências de conformidade que os reguladores esperam.

Pontos principais

• As credenciais roubadas surgem em 39 % de todas as violações de dados, não apenas no acesso inicial, mas como principal mecanismo de movimento lateral, escalada de privilégios e persistência.
• O envolvimento de terceiros atingiu 48 % em 2026, um aumento de 60 % face ao ano anterior, que implica diretamente a governação de acessos na cadeia de abastecimento, nos termos do artigo 21.º, n.º 2, alínea d), da NIS2.
• O artigo 21.º da NIS2 impõe 10 medidas de segurança específicas, todas obrigatórias para qualquer entidade abrangida. As medidas mais auditáveis e mais críticas em caso de violação são o controlo de acesso, a MFA e os registos de auditoria imutáveis, que produzem evidências de conformidade exportáveis, como os reguladores esperam.
• É no controlo de acesso que a conformidade com a NIS2 se torna mensurável. Ao contrário dos documentos de política, a governação de credenciais produz evidências verificáveis: registos de auditoria, matrizes de permissões e relatórios de aplicação da MFA. Os reguladores podem confirmar que os controlos são efetivamente aplicados.
• O artigo 23.º introduz a obrigação de notificar incidentes em 24 horas. As organizações sem gestão centralizada de credenciais, registos de auditoria imutáveis e capacidade de rotação automatizada não conseguem cumprir este prazo. A rotação em massa de palavras-passe tem de poder ser executada em horas, não em dias.
• A ENISA especifica três níveis de MFA. O nível 1 (FIDO2/WebAuthn, resistente a phishing) é obrigatório para todas as contas privilegiadas. O nível 2 (TOTP) é aceitável para os utilizadores comuns. As palavras-passe de utilização única (OTP) enviadas por SMS e por e-mail estão expressamente sinalizadas para abandono progressivo e não cumprem o limiar mínimo.
• A responsabilidade pessoal dos membros dos órgãos de administração não tem precedentes. O artigo 20.º responsabiliza pessoalmente os quadros executivos de topo (C-suite) por falhas de cibersegurança, incluindo a proibição temporária de exercer funções de gestão. Esta disposição não tem precedente na NIS1.
• As coimas podem atingir 10 milhões de euros ou 2 % do volume de negócios anual a nível mundial no caso das entidades essenciais, com aplicação efetiva desde 2026. As autoridades nacionais competentes de toda a UE iniciaram auditorias proativas. O incumprimento deixou de ser uma preocupação futura.
• A implementação on-premise elimina a custódia de dados por terceiros. As credenciais permanecem na rede da organização, sem transmissão externa. Os registos de auditoria são armazenados localmente e enviados diretamente para o SIEM, sem intermediação do fornecedor, o que garante a independência da auditoria.
• O roteiro de implementação em 5 fases demora 30–60 dias, da avaliação à conformidade pronta para auditoria: avaliação prévia à implementação, auditoria de acessos, implementação do sistema de credenciais, configuração para a NIS2 e monitorização contínua. A maioria das organizações consegue passar de uma gestão de acessos fragmentada à aplicação efetiva de controlos dentro deste prazo.

Porque é que a NIS2 se centra na gestão de acessos

É no controlo de acesso que a conformidade com a NIS2 se torna mensurável. Ao contrário dos documentos de política ou das avaliações de risco, a governação de credenciais produz evidências exportáveis: registos de auditoria, matrizes de permissões e relatórios de aplicação da MFA. Os reguladores podem verificar que os controlos são efetivamente aplicados.

O panorama de ameaças torna esta urgência evidente. De acordo com o relatório 2026 Data Breach Investigations Report, da Verizon, a exploração de vulnerabilidades tornou-se o principal vetor de acesso inicial, com 31 % das violações, contra 20 % em 2025. No entanto, esta comparação de destaque oculta uma conclusão mais relevante: as credenciais roubadas surgem em 39 % de todas as violações de dados, ao longo de todo o ciclo de vida do ataque, não apenas no acesso inicial, mas como principal mecanismo de movimento lateral, escalada de privilégios e persistência.

Depois de entrarem, os atacantes usam sobretudo credenciais para se deslocarem pela infraestrutura. O envolvimento de terceiros atingiu 48 % em 2026, contra 30 % em 2025, ou seja, um aumento de 60 % que implica diretamente a governação de acessos na cadeia de abastecimento, nos termos do artigo 21.º, n.º 2, alínea d), da NIS2. ,

As credenciais roubadas alimentam a propagação das violações: são reutilizadas, partilhadas ou nunca revogadas quando os colaboradores saem. O artigo 21.º da NIS2 foi concebido para eliminar este problema através de um controlo de acesso rigoroso, de MFA obrigatória e de registos de auditoria imutáveis.

Compreender o artigo 21.º da NIS2: as 10 medidas de segurança obrigatórias

O artigo 21.º da NIS2 exige «medidas técnicas, operacionais e organizativas adequadas e proporcionadas» para gerir os riscos de cibersegurança. As 10 medidas são obrigatórias para qualquer entidade abrangida. Eis o que cada uma exige:

• Medida 1: análise de riscos e políticas de segurança dos sistemas de informação. As organizações têm de identificar e documentar continuamente os riscos de cibersegurança. Na prática, isto traduz-se na descoberta de credenciais: mapear todas as contas privilegiadas, identificar credenciais partilhadas e documentar que sistemas concentram o acesso de maior risco.
• Medida 2: tratamento de incidentes (prevenção, deteção e resposta). As organizações têm de dispor de procedimentos documentados para responder a incidentes de segurança. No caso de violações baseadas em credenciais, isto significa poder rodar em massa as palavras-passe comprometidas em horas, não em dias.
• Medida 3: continuidade das atividades, gestão de cópias de segurança e recuperação de desastres. As credenciais têm de permanecer acessíveis mesmo quando os sistemas principais falham. Para tal, são necessários clustering de failover, replicação e procedimentos de cópia de segurança testados.
• Medida 4: segurança da cadeia de abastecimento. As organizações têm de avaliar e gerir os riscos de cibersegurança associados aos fornecedores diretos e aos prestadores de serviços. No caso das credenciais, isto implica isolar o acesso de terceiros, limitá-lo no tempo e revogá-lo automaticamente quando os contratos terminam.
• Medida 5: segurança na aquisição, desenvolvimento e manutenção de redes e sistemas de informação. Os sistemas têm de ser construídos e mantidos com a segurança em mente. No caso dos sistemas de credenciais, isto significa práticas de desenvolvimento seguro e testes de intrusão regulares.
• Medida 6: políticas e procedimentos para avaliar a eficácia das medidas de gestão dos riscos de cibersegurança. As organizações têm de verificar que os controlos funcionam realmente. Para tal, são necessários registos de auditoria: prova de que os controlos de acesso são aplicados e de que cada ação sobre credenciais fica registada.
• Medida 7: práticas básicas de ciber-higiene e formação em cibersegurança. As palavras-passe fracas são a falha mais comum em matéria de credenciais. As organizações têm de impor requisitos de complexidade, calendários de rotação e sensibilização dos utilizadores para a segurança.
• Medida 8: políticas e procedimentos relativos à utilização de criptografia e cifragem. As credenciais têm de ser cifradas em repouso e em trânsito. Isto implica cifragem AES-256, TLS em todas as comunicações e uma arquitetura zero-knowledge, em que o servidor nunca detém as chaves de decifragem.
• Medida 9: segurança dos recursos humanos, políticas de controlo de acesso e gestão de ativos. Este é o núcleo da governação de acessos da NIS2: cada utilizador tem de ter direitos de acesso documentados, cada alteração de acesso tem de ficar registada e cada credencial tem de ser revogada quando o acesso deixa de ser necessário.
• Medida 10: utilização de soluções de MFA ou de autenticação contínua. A autenticação multifator deixou de ser opcional. As orientações técnicas da ENISA especificam três níveis de robustez da MFA, sendo a autenticação resistente a phishing (FIDO2/WebAuthn) obrigatória para todas as contas privilegiadas.

Tabela de referência rápida

O Passwork fornece evidências diretas de conformidade em 9 das 10 medidas da NIS2. Os registos de acesso e os registos de auditoria imutáveis satisfazem as medidas 1, 2 e 6. O armazenamento cifrado cobre a medida 8. O RBAC, a aplicação da MFA e o controlo de acesso ao nível dos ativos fecham as medidas 9 e 10, em que os reguladores exigem prova técnica. Obter uma demonstração gratuita e ver o Passwork em ação

A obrigação de notificar incidentes em 24 horas

O artigo 23.º da NIS2 introduz um calendário de notificação em três fases, que altera profundamente a forma como as organizações respondem a violações de credenciais.

• Alerta rápido (24 horas). No prazo de 24 horas após a deteção de um incidente significativo, as organizações têm de notificar o CSIRT nacional. Não é exigida uma avaliação completa, apenas a confirmação de que ocorreu um incidente e se há suspeita de atividade criminosa.
• Notificação de incidente (72 horas). Apresentar uma avaliação inicial: gravidade, impacto, indicadores de comprometimento (IoC) e sistemas afetados. É neste ponto que o âmbito da violação de credenciais se torna crítico. Se as credenciais de administrador tiverem sido comprometidas, o âmbito pode abranger toda a empresa.
• Relatório final (1 mês). Análise completa da causa de raiz, medidas de correção adotadas, avaliação do impacto transfronteiriço e lições aprendidas. Este é o documento que os reguladores irão examinar com mais atenção. No caso de violações de credenciais, deve incluir a prova de que todas as palavras-passe comprometidas foram rodadas e de que o acesso foi revogado para quaisquer contas que já não deveriam ter acesso.

As organizações sem gestão centralizada de credenciais, registos de auditoria imutáveis e capacidade de rotação automatizada não conseguem cumprir o prazo de 24 horas.

Orientações técnicas da ENISA: MFA, PAM e registos de auditoria

A Agência da União Europeia para a Cibersegurança (ENISA) publicou orientações técnicas de implementação detalhadas para a NIS2. Em matéria de gestão de acessos, dominam três áreas: a robustez da MFA, a gestão de acessos privilegiados (PAM) e os registos de auditoria.

MFA: três níveis de robustez

A ENISA classifica a MFA em três níveis, consoante a resistência a phishing:

1. Forte (resistente a phishing). FIDO2, WebAuthn e chaves de segurança de hardware. Não podem ser intercetados por ataques de phishing, porque utilizam protocolos criptográficos de desafio-resposta. A ENISA impõe o nível 1 para todas as contas privilegiadas e administrativas, sem exceções.
2. Média. Aplicações de autenticação TOTP e notificações push. Aceitáveis para contas de utilizadores comuns. São vulneráveis a phishing em tempo real, mas significativamente melhores do que as palavras-passe isoladas.
3. Último recurso (abandono progressivo). Palavras-passe de utilização única enviadas por SMS e por e-mail. São vulneráveis a ataques de SIM swap e a interceção. A ENISA recomenda expressamente o seu abandono progressivo em todos os ambientes regulados.

As organizações têm de documentar o nível de MFA aplicado a cada grupo de utilizadores. Os auditores verificarão que todas as contas privilegiadas utilizam o nível 1 e que as OTP por SMS ou e-mail já não estão em uso.

Gestão de acessos privilegiados (PAM)

A ENISA especifica quatro requisitos de PAM:

1. Segregação de funções. As contas de administrador nunca devem ser utilizadas em tarefas gerais, como o correio eletrónico ou a navegação. São necessárias contas separadas e dedicadas para todas as operações privilegiadas.
2. Registo de auditoria completo. Cada ação privilegiada tem de ser registada com a identidade do utilizador, a data e hora, o IP de origem e a ação executada. Os logs têm de ser imutáveis e invioláveis.
3. Acesso Just-In-Time (JIT). Os privilégios são concedidos por evento e revogados automaticamente após a utilização. Sem acesso de administrador permanente.
4. Governação do acesso de terceiros. O acesso de fornecedores tem de ter âmbito definido, ser limitado no tempo e ser revogado automaticamente no fim do contrato ou na conclusão do projeto.

Registos de auditoria (ENISA §11.4)

Os logs devem ser:

• Centralizados. Todas as ações sobre credenciais registadas num único sistema protegido.
• Imutáveis. Nenhum utilizador, incluindo os administradores, pode alterar ou eliminar entradas de log.
• Exportáveis. Formatos estruturados (JSON, CSV, syslog) para integração com o SIEM e para submissão a entidades reguladoras.
• Conservados. O período mínimo de conservação é definido pela avaliação de risco da entidade (tipicamente 1–3 anos).

Logs incompletos ou passíveis de adulteração não satisfazem a secção 11.4 da ENISA. Os reguladores rejeitá-los-ão.

Associar os requisitos da NIS2 a controlos técnicos

Eis como controlos técnicos específicos satisfazem as obrigações do artigo 21.º:

Todos os controlos da tabela acima estão integrados na arquitetura base do Passwork. Painéis de segurança das palavras-passe, registos de auditoria imutáveis, RBAC, aplicação da MFA e cifragem AES-256 estão disponíveis de origem. O resultado são evidências de conformidade que os reguladores esperam, e não documentos de política que têm de interpretar.

O roteiro de implementação em 5 fases: da avaliação à conformidade pronta para auditoria

Passar de uma gestão de acessos fragmentada para uma conformidade com a NIS2 pronta para auditoria não exige reconstruir toda a infraestrutura. Uma abordagem estruturada em 5 fases leva a maioria das organizações da avaliação à aplicação efetiva dos controlos em 30–60 dias.

Fase 1: avaliação prévia à implementação (semana 1)

1. Definir o âmbito da NIS2. Que unidades de negócio, sistemas e grupos de utilizadores estão abrangidos pela diretiva? Classificar a organização como entidade essencial ou importante e confirmar as obrigações aplicáveis.
2. Atribuir responsabilidades. Designar um responsável pela conformidade, com responsabilidade nos termos do artigo 20.º, tipicamente o CISO ou o diretor de TI. Alinhar as equipas de TI, segurança, recursos humanos e jurídica quanto a funções, responsabilidades e circuitos de escalamento.
3. Confirmar a prontidão da infraestrutura. Verificar as especificações dos servidores e a topologia de rede para a implementação on-premise. Confirmar a prontidão do Active Directory ou do LDAP para o provisionamento automático de utilizadores.

Fase 2: auditoria de acessos para avaliar a situação atual (semana 2)

1. Mapear todas as contas privilegiadas. Identificar todas as contas com acesso de administrador em todos os sistemas e infraestruturas. Incluir contas de serviço e credenciais partilhadas, que são as credenciais de maior risco.
2. Identificar o acesso de terceiros. Rever todos os acessos ativos de terceiros e fornecedores. Documentar o âmbito, a duração e o estado atual da MFA. É aqui que a maioria das organizações descobre acessos não controlados.
3. Avaliar o registo atual. O que é registado hoje, onde e durante quanto tempo? Documentar a diferença entre a situação atual e os requisitos técnicos da ENISA.

Fase 3: implementar o Passwork no ambiente da organização (semana 3)

1. Instalar on-premise. Implementar com Docker Compose ou num servidor bare-metal (Linux/Windows). O Passwork funciona inteiramente dentro da infraestrutura da organização, sem transmissão externa de credenciais.
2. Integrar com os sistemas de identidade. Ligar ao Active Directory ou ao LDAP para o provisionamento automático de utilizadores. Configurar o SSO através de SAML 2.0 para uma autenticação fluida e auditável.
3. Importar e organizar as credenciais. Migrar as credenciais existentes para cofres estruturados por equipa, sistema e criticidade. Definir a estrutura inicial dos cofres e a hierarquia de propriedade.

Fase 4: configurar para a conformidade com a NIS2 (semana 4)

1. Definir e aplicar o RBAC. Aplicar o princípio do menor privilégio de forma transversal. Cada utilizador acede apenas às credenciais de que a sua função necessita.
2. Impor a MFA. Aplicar o nível 1 (FIDO2) a todas as contas privilegiadas. Aplicar o nível 2 (TOTP) a todos os utilizadores comuns. Documentar a aplicação como evidência de auditoria.
3. Isolar o acesso de terceiros. Criar cofres dedicados e limitados no tempo para fornecedores e prestadores de serviços, com expiração automática no fim do contrato.
4. Configurar as políticas de palavras-passe. Aplicar regras de complexidade, calendários de rotação e expiração automática. Ativar o registo de auditoria completo e configurar a integração com o SIEM via syslog.

Fase 5: monitorização e reporte contínuos (permanente)

1. Agendar revisões de acessos trimestrais. Validar que as atribuições de RBAC continuam corretas. Garantir que não permanece acesso órfão após a saída de colaboradores.
2. Gerar relatórios de conformidade automatizados. Demonstrar a aplicação da MFA, a governação de acessos e a eficácia dos controlos. Ter pacotes de evidências exportáveis prontos para submissão aos reguladores, a pedido.
3. Monitorizar os registos de auditoria. Integrar alertas com o SIEM para padrões de acesso anómalos. Realizar avaliações anuais da prontidão para a NIS2 face às orientações atualizadas da ENISA.

Lista de verificação de conformidade com a NIS2

Esta lista de verificação permite acompanhar a situação de conformidade nas três áreas críticas: gestão de acessos, segurança da cadeia de abastecimento e prontidão para incidentes.

Controlo de acesso (artigo 21.º, n.º 2, alínea i)

• Mapear todas as contas privilegiadas em todos os sistemas e infraestruturas
• Implementar um RBAC rigoroso: cada utilizador acede apenas às credenciais de que a sua função necessita
• Eliminar todas as contas partilhadas e substituí-las por acesso individualizado
• Automatizar o ciclo de vida das identidades via AD/LDAP, com revogação imediata do acesso na saída do colaborador
• Exportar as matrizes de permissões como evidência pronta para auditoria

Cadeia de abastecimento (artigo 21.º, n.º 2, alínea d)

• Isolar todo o acesso de terceiros em cofres dedicados e limitados no tempo
• Auditar todas as credenciais ativas de fornecedores e revogar qualquer acesso que deixe de se justificar operacionalmente
• Documentar o âmbito, a duração e o estado da MFA do acesso de cada credencial ativa de terceiros
• Configurar a expiração automática no fim do contrato

MFA (artigo 21.º, n.º 2, alínea j)

• Aplicar MFA de nível 1 (FIDO2/WebAuthn) a todas as contas administrativas
• Aplicar MFA de nível 2 (TOTP) a todos os utilizadores comuns
• Abandonar progressivamente as OTP por SMS e por e-mail, que não cumprem o limiar mínimo da ENISA
• Gerar um relatório de conformidade que confirme a MFA em todas as contas ativas

Prontidão para incidentes (artigo 23.º)

• Verificar se os registos de auditoria têm detalhe suficiente para o alerta rápido de 24 horas
• Estabelecer e testar o fluxo de rotação de credenciais em massa para a resposta pós-incidente
• Designar uma pessoa responsável pela notificação ao abrigo do artigo 23.º
• Preparar pacotes de evidências exportáveis, prontos para submissão aos reguladores a pedido

Registos de auditoria (ENISA §11.4)

• Centralizar e proteger os registos de auditoria, configurando um registo imutável e exportável
• Integrar com o SIEM via syslog, garantindo que nenhum utilizador pode alterar ou eliminar entradas de log
• Confirmar que cada entrada regista a identidade, a data e hora, a ação e o IP de origem
• Gerar relatórios automatizados sobre a aplicação da MFA, a conformidade do RBAC e as revisões de acessos

Coimas: o custo real do incumprimento

As consequências financeiras e pessoais do incumprimento da NIS2 são graves:

• Para as entidades essenciais: até 10 milhões de euros ou 2 % do volume de negócios anual a nível mundial, consoante o que for mais elevado. Os reguladores podem também impor restrições operacionais temporárias.
• Para as entidades importantes: até 7 milhões de euros ou 1,4 % do volume de negócios anual a nível mundial, consoante o que for mais elevado. A supervisão reativa não significa menor risco.
• Responsabilidade pessoal da gestão (artigo 20.º). Os membros dos órgãos de administração e os quadros executivos de topo (C-suite) podem ser pessoalmente responsabilizados por falhas de cibersegurança. As autoridades competentes podem impor proibições temporárias de exercício de funções de gestão. Esta disposição não tem precedente na NIS1 e altera profundamente a forma como a liderança tem de encarar a conformidade.

Desde 2026, as autoridades nacionais competentes de toda a UE iniciaram auditorias proativas às entidades essenciais. A fase de fiscalização está em curso.

Construir o pacote de evidências da NIS2

Os reguladores querem provas. O pacote de evidências de conformidade deve incluir:

1. Exportação da configuração do RBAC. Matrizes de permissões que mostram que utilizadores/funções têm acesso a que credenciais.
2. Relatório de aplicação da MFA. Configuração do sistema que confirma que a MFA é aplicada a nível global, com o método de MFA por utilizador.
3. Amostras de registos de auditoria. Logs representativos com identidade, data e hora, ação e IP de origem para os acessos e modificações de credenciais.
4. Inventário de acessos de terceiros. Âmbito, duração e estado da MFA documentados para cada credencial ativa de fornecedores.
5. Documentação das políticas de palavras-passe. Regras de complexidade, calendários de rotação e definições de expiração automática em vigor.
6. Capacidade de resposta a incidentes. Prova de que a rotação de credenciais em massa pode ser executada em horas.
7. Registos de cópias de segurança e failover. Evidência de que as credenciais permanecem acessíveis durante falhas dos sistemas.

A vantagem do on-premise para a conformidade com a NIS2

As organizações perguntam frequentemente: porque é que a NIS2 dá ênfase à implementação on-premise? A resposta é a soberania dos dados e a independência da auditoria.

1. Os dados ficam onde a organização os governa. Todas as credenciais permanecem na rede da organização, sem transmissão externa, sem custódia por terceiros e sem ambiguidade jurisdicional.
2. Registos de auditoria que a organização detém e controla. Os logs são armazenados localmente e enviados diretamente para o SIEM via syslog, sem intermediário do fornecedor, sem restrições e sem que os dados saiam do perímetro da organização.
3. Sem dependência de dados de terceiros. Como o sistema de credenciais funciona dentro da infraestrutura da organização, não detém custódia das credenciais, o que elimina a dependência de dados de terceiros que desencadeia os requisitos de avaliação da cadeia de abastecimento nos termos do artigo 21.º, n.º 2, alínea d).
4. Evidências de conformidade nos termos da organização. Cada relatório, log e exportação de configuração é gerado a partir da própria infraestrutura e fica disponível a pedido dos auditores, sem depender da equipa de suporte ou da política de retenção de dados de um fornecedor.
5. Suporte para ambientes isolados. Implementação com isolamento físico (air gap) para infraestruturas OT/ICS, sem qualquer exposição de rede. As credenciais permanecem acessíveis mesmo onde a ligação à internet é proibida por conceção.

Conclusão: da conformidade à vantagem competitiva

A NIS2 é um mandato para proteger a infraestrutura de que depende a sociedade europeia. Os vetores de ataque baseados em credenciais dominam o panorama de ameaças de 2026 e são precisamente aquilo que o artigo 21.º foi concebido para combater.

As organizações que centralizam a governação de credenciais, impõem MFA resistente a phishing e mantêm registos de auditoria imutáveis fazem mais do que passar na auditoria: eliminam a sua superfície de ataque mais significativa. O roteiro de implementação em 5 fases deste guia conduz da gestão de acessos fragmentada à conformidade pronta para auditoria em 30–60 dias.

A base técnica para esse resultado exige três elementos: uma implementação on-premise que garanta a soberania dos dados, um RBAC que imponha o menor privilégio à escala e registos de auditoria que forneçam aos reguladores exatamente as evidências de que necessitam.

O Passwork fornece os 9 controlos técnicos desta tabela: painéis de segurança das palavras-passe, rotação em massa, clustering de failover, implementação on-premise, registos de auditoria imutáveis, aplicação de políticas, cifragem AES-256, RBAC e MFA. Obter uma demonstração gratuita e ver o Passwork em ação.Pronto para passar do planeamento da conformidade à implementação? Transferir o guia completo de conformidade com a NIS2 com o mapeamento técnico detalhado, orientações por setor e uma lista de verificação de conformidade personalizável.

Perguntas frequentes

O que exige, na prática, o artigo 21.º da NIS2 à minha organização?

O artigo 21.º impõe 10 medidas de segurança específicas: análise de riscos, tratamento de incidentes, continuidade das atividades, segurança da cadeia de abastecimento, desenvolvimento seguro, verificação da eficácia dos controlos, ciber-higiene, cifragem, controlo de acesso e MFA. Todas as 10 são obrigatórias para qualquer entidade abrangida. As medidas mais auditáveis e mais críticas em caso de violação são o controlo de acesso (artigo 21.º, n.º 2, alínea i), a MFA (artigo 21.º, n.º 2, alínea j) e os registos de auditoria (artigo 21.º, n.º 2, alínea f).

Quem tem de cumprir a NIS2?

As organizações de 18 setores europeus classificadas como entidades essenciais têm de cumprir de imediato. Estes setores incluem a energia, os transportes, a água, a saúde, as infraestruturas digitais e a administração pública. As entidades importantes (serviços financeiros, abastecimento alimentar, indústria transformadora, produtos químicos, espaço) têm até outubro de 2025 para a conformidade plena. As organizações de fora da UE que operam nestes setores sob jurisdição da UE também estão abrangidas.

Quais são as sanções por incumprimento?

As entidades essenciais enfrentam coimas até 10 milhões de euros ou 2 % do volume de negócios anual a nível mundial, consoante o que for mais elevado. As entidades importantes enfrentam coimas até 7 milhões de euros ou 1,4 % do volume de negócios anual a nível mundial. Os membros dos órgãos de administração e os quadros executivos de topo (C-suite) respondem pessoalmente nos termos do artigo 20.º, incluindo a proibição temporária de exercer funções de gestão. A fiscalização está em curso desde 2026.

Quanto tempo demora a implementar a conformidade com a NIS2 na gestão de acessos?

A maioria das organizações passa da avaliação à conformidade pronta para auditoria em 30–60 dias, com uma abordagem estruturada em 5 fases: avaliação prévia à implementação (semana 1), auditoria de acessos (semana 2), implementação do sistema de credenciais (semana 3), configuração para a NIS2 (semana 4) e monitorização contínua. O prazo depende da complexidade da infraestrutura e do volume de credenciais existentes a migrar.

Qual é a diferença entre entidades essenciais e entidades importantes na NIS2?

As entidades essenciais operam infraestruturas críticas (energia, transportes, água, saúde, infraestruturas digitais, administração pública). As entidades importantes prestam serviços essenciais (serviços financeiros, abastecimento alimentar, indústria transformadora, produtos químicos, espaço). As entidades essenciais enfrentam coimas mais elevadas (10 milhões de euros contra 7 milhões de euros) e prazos de fiscalização mais rigorosos. Ambas têm de implementar as 10 medidas do artigo 21.º.

Porque é que a NIS2 dá ênfase à gestão de credenciais on-premise?

A implementação on-premise garante a soberania dos dados: as credenciais permanecem na rede da organização, sem transmissão externa nem custódia por terceiros. Os registos de auditoria são armazenados localmente e enviados diretamente para o SIEM, sem intermediação do fornecedor. Isto elimina a dependência de dados de terceiros que desencadeia os requisitos de avaliação da cadeia de abastecimento nos termos do artigo 21.º, n.º 2, alínea d), e confere total independência da auditoria.

Que nível de MFA exige a NIS2?

A ENISA especifica três níveis: o nível 1 (resistente a phishing), com FIDO2, WebAuthn e chaves de segurança de hardware, é obrigatório para todas as contas privilegiadas e administrativas. O nível 2 (aplicações de autenticação TOTP, notificações push) é aceitável para os utilizadores comuns. As OTP por SMS e por e-mail estão expressamente sinalizadas para abandono progressivo e não cumprem o limiar mínimo da ENISA.

Como demonstrar a conformidade com a NIS2 aos reguladores?

O pacote de evidências deve incluir: exportações da configuração do RBAC com as matrizes de permissões, relatórios de aplicação da MFA que confirmem a aplicação global, registos de auditoria representativos com identidade/data e hora/ação/IP de origem, inventário de acessos de terceiros com âmbito e duração, documentação das políticas de palavras-passe, prova da capacidade de rotação de credenciais em massa e registos de cópias de segurança e failover. Todas as evidências devem ser exportáveis e estar prontas para auditoria a pedido.

Qual é o calendário de notificação do artigo 23.º?

O artigo 23.º introduz três fases: alerta rápido (24 horas), para notificar o CSIRT nacional de que ocorreu um incidente; notificação de incidente (72 horas), com uma avaliação inicial que inclui gravidade, impacto e sistemas afetados; e relatório final (1 mês), com a análise completa da causa de raiz, as medidas de correção e as lições aprendidas. As organizações sem gestão centralizada de credenciais e rotação automatizada não conseguem cumprir o prazo de 24 horas.

Gestão de palavras-passe e de acessos para PMEs: o KeePass é suficiente?

A equipa utiliza o KeePass? Conheça os riscos ocultos do KeePass para as PMEs em 2026: falhas de sincronização, lacunas de conformidade e quando migrar para um gestor de palavras-passe empresarial.

Passwork BlogAlex Muntyan

A autenticação sem palavra-passe é exigida para a conformidade com a NIS2?

O artigo 21.º, n.º 2, alínea j), da NIS2 exige MFA «quando apropriado», e não autenticação sem palavra-passe por defeito. Saiba o que as orientações da ENISA exigem realmente, como os auditores avaliam a implementação e como construir uma postura de conformidade híbrida e defensável para 2026.

Passwork BlogAlex Muntyan

O Passwork conquista o prémio Top Performer Spring 2026 no SourceForge

O Passwork foi distinguido como Top Performer Spring 2026 pelo SourceForge, ficando no top 10 % de mais de 100 000 soluções. O selo baseia-se exclusivamente em avaliações verificadas: 4,8 estrelas no geral e uma pontuação perfeita de 5,0 em suporte.

Passwork BlogAlex Muntyan

Die NIS2-Richtlinie (EU 2022/2555) ist keine Zukunftsangelegenheit mehr. Seit Oktober 2024 müssen Organisationen in 18 europäischen Sektoren die Einhaltung verbindlicher Cybersicherheitskontrollen nachweisen. Strafen erreichen 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes, und Vorstandsmitglieder haften persönlich bei Nichteinhaltung.

Im Kern von NIS2 steht Artikel 21, der 10 spezifische Sicherheitsmaßnahmen vorschreibt. Davon ist das Zugriffsmanagement (Credential-Governance, rollenbasierte Zugriffskontrolle, Multi-Faktor-Authentifizierung und Audit-Protokollierung) am besten prüfbar und am direktesten mit Sicherheitsvorfällen verbunden.

Dieser Leitfaden ordnet diese Anforderungen praktischen Umsetzungsschritten zu und zeigt, wie Sie Compliance-Nachweise erstellen, die Regulierungsbehörden erwarten.

Wichtigste Erkenntnisse

• Gestohlene Anmeldedaten erscheinen in 39 % aller Sicherheitsvorfälle — nicht nur beim initialen Zugang, sondern als primärer Mechanismus für laterale Bewegung, Rechteausweitung und Persistenz.
• Die Beteiligung Dritter hat 2026 48 % erreicht, ein Anstieg von 60 % im Jahresvergleich, der direkt die Supply-Chain-Zugangs-Governance unter NIS2 Artikel 21(2)(d) betrifft.
• NIS2 Artikel 21 schreibt 10 spezifische Sicherheitsmaßnahmen vor, die alle für jede betroffene Organisation verbindlich sind. Die am besten prüfbaren und sicherheitskritischsten Maßnahmen sind Zugriffskontrolle, MFA und unveränderliche Audit-Protokollierung — diese liefern exportierbare Compliance-Nachweise, die Regulierungsbehörden erwarten.
• Zugriffskontrolle ist der Bereich, in dem NIS2-Compliance messbar wird. Im Gegensatz zu Richtliniendokumenten erzeugt Credential-Governance überprüfbare Nachweise: Audit-Protokolle, Berechtigungsmatrizen, MFA-Durchsetzungsberichte. Regulierungsbehörden können bestätigen, dass Kontrollen aktiv durchgesetzt werden.
• Artikel 23 führt eine 24-Stunden-Meldepflicht für Vorfälle ein. Organisationen ohne zentralisiertes Credential-Management, unveränderliche Audit-Trails und automatisierte Rotationsfähigkeiten können diese Frist nicht einhalten. Massenhafte Passwortrotation muss innerhalb von Stunden durchführbar sein, nicht Tagen.
• ENISA spezifiziert drei MFA-Stufen. Stufe 1 (Phishing-resistentes FIDO2/WebAuthn) ist für alle privilegierten Konten obligatorisch. Stufe 2 (TOTP) ist für Standardbenutzer akzeptabel. SMS- und E-Mail-OTPs sind explizit zur Auslaufphase gekennzeichnet und erfüllen die Mindestanforderungen nicht.
• Persönliche Haftung für Vorstandsmitglieder ist beispiellos. Artikel 20 macht C-Level-Führungskräfte persönlich für Cybersicherheitsmängel verantwortlich, einschließlich temporärer Verbote von Managementfunktionen. Diese Bestimmung hat keinen Präzedenzfall in NIS1.
• Strafen erreichen 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes für Wesentliche Einrichtungen, wobei die Durchsetzung ab 2026 aktiv ist. Nationale zuständige Behörden in der gesamten EU haben mit proaktiven Audits begonnen. Nichteinhaltung ist kein Zukunftsthema mehr.
• On-Premise-Bereitstellung eliminiert die Datenverwahrung durch Dritte. Anmeldedaten verbleiben in Ihrem Netzwerk ohne externe Übertragung. Audit-Protokolle werden lokal gespeichert und direkt an Ihr SIEM weitergeleitet, ohne Vermittler des Anbieters, was Audit-Unabhängigkeit garantiert.
• Die 5-Phasen-Implementierungs-Roadmap dauert 30–60 Tage von der Bewertung bis zur audit-bereiten Compliance: Vor-Bereitstellungs-Bewertung, Zugriffs-Audit, Credential-System-Bereitstellung, NIS2-Konfiguration und laufende Überwachung. Die meisten Organisationen können innerhalb dieses Zeitrahmens von fragmentiertem Zugriffsmanagement zur Durchsetzung übergehen.

Warum NIS2 sich auf Zugriffsmanagement konzentriert

Zugriffskontrolle ist der Bereich, in dem NIS2-Compliance messbar wird. Im Gegensatz zu Richtliniendokumenten oder Risikobewertungen erzeugt Credential-Governance exportierbare Nachweise: Audit-Protokolle, Berechtigungsmatrizen, MFA-Durchsetzungsberichte. Regulierungsbehörden können überprüfen, dass Kontrollen aktiv durchgesetzt werden.

Die Bedrohungslandschaft macht diese Dringlichkeit deutlich. Laut Verizons Data Breach Investigations Report 2026 ist die Ausnutzung von Schwachstellen mit 31 % der Sicherheitsvorfälle zum führenden initialen Zugriffsvektor geworden, gegenüber 20 % im Jahr 2025. Dieser Schlagzeilenvergleich verdeckt jedoch eine kritischere Erkenntnis: Gestohlene Anmeldedaten erscheinen in 39 % aller Sicherheitsvorfälle über den gesamten Angriffslebenszyklus — nicht nur beim initialen Zugang, sondern als primärer Mechanismus für laterale Bewegung, Rechteausweitung und Persistenz.

Sobald Angreifer Zugang erhalten, werden Anmeldedaten ihr dominantes Werkzeug, um sich durch die Infrastruktur zu bewegen. Die Beteiligung Dritter hat 2026 48 % erreicht, gegenüber 30 % im Jahr 2025 — ein Anstieg von 60 %, der direkt die Supply-Chain-Zugangs-Governance unter NIS2 Artikel 21(2)(d) betrifft.

Gestohlene Anmeldedaten treiben die Ausweitung von Sicherheitsvorfällen voran — wiederverwendet, geteilt oder nie widerrufen, wenn Mitarbeiter das Unternehmen verlassen. NIS2 Artikel 21 wurde entwickelt, um dies durch strenge Zugriffskontrolle, obligatorische MFA und unveränderliche Audit-Protokollierung zu eliminieren.

NIS2 Artikel 21 verstehen: Die 10 obligatorischen Sicherheitsmaßnahmen

NIS2 Artikel 21 verlangt „angemessene und verhältnismäßige technische, operative und organisatorische Maßnahmen" zur Bewältigung von Cybersicherheitsrisiken. Alle 10 Maßnahmen sind für jede betroffene Organisation verbindlich. Hier ist, was jede einzelne verlangt:

• Maßnahme 1: Risikoanalyse und Sicherheitsrichtlinien für Informationssysteme. Organisationen müssen Cybersicherheitsrisiken kontinuierlich identifizieren und dokumentieren. Dies bedeutet Credential-Erkennung: Erfassung aller privilegierten Konten, Identifizierung gemeinsam genutzter Anmeldedaten und Dokumentation, welche Systeme den risikoreichsten Zugang haben.
• Maßnahme 2: Vorfallbehandlung — Prävention, Erkennung und Reaktion. Organisationen müssen dokumentierte Verfahren für die Reaktion auf Sicherheitsvorfälle haben. Bei Credential-basierten Sicherheitsvorfällen bedeutet dies die Fähigkeit, kompromittierte Passwörter massenhaft innerhalb von Stunden zu rotieren, nicht Tagen.
• Maßnahme 3: Geschäftskontinuität, Backup-Management und Disaster Recovery. Anmeldedaten müssen auch bei Ausfall primärer Systeme zugänglich bleiben. Dies erfordert Failover-Clustering, Replikation und getestete Backup-Verfahren.
• Maßnahme 4: Supply-Chain-Sicherheit. Organisationen müssen die Cybersicherheitsrisiken durch direkte Lieferanten und Dienstleister bewerten und managen. Für Anmeldedaten bedeutet dies die Isolierung des Zugriffs durch Dritte, zeitliche Begrenzung und automatischen Widerruf bei Vertragsende.
• Maßnahme 5: Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen. Systeme müssen mit Sicherheit im Blick gebaut und gewartet werden. Für Credential-Systeme bedeutet dies sichere Entwicklungspraktiken und regelmäßige Penetrationstests.
• Maßnahme 6: Richtlinien und Verfahren zur Bewertung der Wirksamkeit von Cybersicherheits-Risikomanagementmaßnahmen. Organisationen müssen überprüfen, dass Kontrollen tatsächlich funktionieren. Dies erfordert Audit-Trails: Nachweis, dass Zugriffskontrollen durchgesetzt werden und jede Credential-Aktion protokolliert wird.
• Maßnahme 7: Grundlegende Cyber-Hygiene-Praktiken und Cybersicherheitsschulungen. Schwache Passwörter sind der häufigste Credential-Fehler. Organisationen müssen Passwortkomplexität, Rotationspläne und Sicherheitsbewusstsein der Benutzer durchsetzen.
• Maßnahme 8: Richtlinien und Verfahren für den Einsatz von Kryptographie und Verschlüsselung. Anmeldedaten müssen im Ruhezustand und während der Übertragung verschlüsselt sein. Dies bedeutet AES-256-Verschlüsselung, TLS für alle Kommunikationen und Zero-Knowledge-Architektur, bei der der Server niemals Entschlüsselungsschlüssel hält.
• Maßnahme 9: Personalsicherheit, Zugriffskontrollrichtlinien und Asset-Management. Dies ist der Kern der NIS2-Zugangs-Governance: Jeder Benutzer muss dokumentierte Zugriffsrechte haben, jede Zugriffsänderung muss protokolliert werden, und jede Anmeldung muss widerrufen werden, wenn der Zugang nicht mehr benötigt wird.
• Maßnahme 10: Einsatz von MFA oder kontinuierlichen Authentifizierungslösungen. Multi-Faktor-Authentifizierung ist nicht mehr optional. Die technische Anleitung der ENISA spezifiziert drei Stufen der MFA-Stärke, wobei Phishing-resistente Authentifizierung (FIDO2/WebAuthn) für alle privilegierten Konten obligatorisch ist.

Kurzreferenztabelle

Passwork liefert direkte Compliance-Nachweise für 9 der 10 NIS2-Maßnahmen. Zugriffsprotokolle und unveränderliche Audit-Trails erfüllen die Maßnahmen 1, 2 und 6. Verschlüsselte Speicherung deckt Maßnahme 8 ab. RBAC, MFA-Durchsetzung und Zugriffskontrolle auf Asset-Ebene schließen die Maßnahmen 9 und 10 ab — wo Regulierungsbehörden technische Nachweise fordern. Erhalten Sie eine kostenlose Demo und erleben Sie es in Aktion

Die 24-Stunden-Meldepflicht für Vorfälle

NIS2 Artikel 23 führt einen dreistufigen Meldezeitplan ein, der grundlegend verändert, wie Organisationen auf Credential-Sicherheitsvorfälle reagieren.

• Frühwarnung (24 Stunden). Innerhalb von 24 Stunden nach Entdeckung eines erheblichen Vorfalls müssen Organisationen das nationale CSIRT benachrichtigen. Keine vollständige Bewertung erforderlich — nur Bestätigung, dass ein Vorfall stattgefunden hat und ob kriminelle Aktivitäten vermutet werden.
• Vorfallmeldung (72 Stunden). Eine erste Bewertung bereitstellen: Schweregrad, Auswirkungen, Indicators of Compromise (IoCs) und betroffene Systeme. Hier wird der Umfang des Credential-Sicherheitsvorfalls kritisch. Wenn Admin-Anmeldedaten kompromittiert wurden, ist der Umfang potenziell unternehmensweit.
• Abschlussbericht (1 Monat). Vollständige Ursachenanalyse, ergriffene Abhilfemaßnahmen, Bewertung grenzüberschreitender Auswirkungen und gewonnene Erkenntnisse. Dies ist das Dokument, das Regulierungsbehörden genau prüfen werden. Bei Credential-Sicherheitsvorfällen muss es den Nachweis enthalten, dass alle kompromittierten Passwörter rotiert wurden und dass der Zugang für alle Konten widerrufen wurde, die keinen Zugang mehr hätten haben sollen.

Organisationen ohne zentralisiertes Credential-Management, unveränderliche Audit-Trails und automatisierte Rotationsfähigkeiten können die 24-Stunden-Frist nicht einhalten.

Technische ENISA-Leitlinien: MFA, PAM und Audit-Protokollierung

Die Agentur der Europäischen Union für Cybersicherheit (ENISA) hat detaillierte technische Implementierungsleitlinien für NIS2 veröffentlicht. Für das Zugriffsmanagement dominieren drei Bereiche: MFA-Stärke, Privileged Access Management (PAM) und Audit-Protokollierung.

MFA: Drei Stärkestufen

ENISA klassifiziert MFA in drei Stufen basierend auf Phishing-Resistenz:

1. Stark (Phishing-resistent). FIDO2, WebAuthn und Hardware-Sicherheitsschlüssel. Diese können nicht durch Phishing-Angriffe abgefangen werden, da sie kryptografische Challenge-Response-Protokolle verwenden. ENISA schreibt Stufe 1 für alle privilegierten und administrativen Konten vor. Keine Ausnahmen.
2. Mittel. TOTP-Authenticator-Apps und Push-Benachrichtigungen. Akzeptabel für Standard-Benutzerkonten. Anfällig für Echtzeit-Phishing, aber deutlich besser als nur Passwörter.
3. Letzte Option (Auslaufphase). SMS- und E-Mail-Einmalpasswörter. Anfällig für SIM-Swap-Angriffe und Abfangen. ENISA empfiehlt ausdrücklich deren Auslaufphase für alle regulierten Umgebungen.

Organisationen müssen dokumentieren, welche MFA-Stufe für jede Benutzergruppe durchgesetzt wird. Prüfer werden überprüfen, dass alle privilegierten Konten Stufe 1 verwenden und dass SMS/E-Mail-OTPs nicht mehr verwendet werden.

Privileged Access Management (PAM)

ENISA spezifiziert vier PAM-Anforderungen:

1. Funktionstrennung. Admin-Konten dürfen niemals für allgemeine Aufgaben wie E-Mail oder Browsen verwendet werden. Separate, dedizierte Konten sind für alle privilegierten Operationen erforderlich.
2. Vollständige Audit-Protokollierung. Jede privilegierte Aktion muss mit Benutzeridentität, Zeitstempel, Quell-IP und durchgeführter Aktion protokolliert werden. Protokolle müssen unveränderlich und manipulationssicher sein.
3. Just-In-Time (JIT)-Zugang. Berechtigungen werden auf Ereignisbasis gewährt und nach Verwendung automatisch widerrufen. Kein dauerhafter Admin-Zugang.
4. Drittanbieter-Zugangs-Governance. Anbieterzugang muss umfangsbegrenzt, zeitlich begrenzt und bei Vertragsende oder Projektabschluss automatisch widerrufen werden.

Audit-Protokollierung (ENISA §11.4)

Protokolle müssen:

• Zentralisiert sein. Alle Credential-Aktionen werden in einem einzigen, geschützten System protokolliert.
• Unveränderlich sein. Kein Benutzer, einschließlich Administratoren, kann Protokolleinträge ändern oder löschen.
• Exportierbar sein. Strukturierte Formate (JSON, CSV, Syslog) für SIEM-Integration und regulatorische Einreichung.
• Aufbewahrt werden. Die minimale Aufbewahrungsdauer wird durch die Risikobewertung der Organisation definiert (typischerweise 1–3 Jahre).

Unvollständige oder manipulierbare Protokolle erfüllen ENISA §11.4 nicht. Regulierungsbehörden werden sie ablehnen.

NIS2-Anforderungen auf technische Kontrollen abbilden

So erfüllen spezifische technische Kontrollen die Verpflichtungen aus Artikel 21:

Jede Kontrolle in der obigen Tabelle ist in Passworks Kernarchitektur integriert. Sie erhalten Passwortsicherheits-Dashboards, unveränderliche Audit-Trails, RBAC, MFA-Durchsetzung und AES-256-Verschlüsselung standardmäßig. Das Ergebnis: Compliance-Nachweise, die Regulierungsbehörden erwarten, keine Richtliniendokumente, die sie interpretieren müssen.

Die 5-Phasen-Implementierungs-Roadmap: Von der Bewertung zur audit-bereiten Compliance

Der Übergang von fragmentiertem Zugriffsmanagement zu audit-bereiter NIS2-Compliance erfordert keine vollständige Infrastrukturumstellung. Ein strukturierter 5-Phasen-Ansatz führt die meisten Organisationen innerhalb von 30–60 Tagen von der Bewertung zur Durchsetzung.

Phase 1: Vor-Bereitstellungs-Bewertung (Woche 1)

1. NIS2-Umfangsgrenzen definieren. Welche Geschäftsbereiche, Systeme und Benutzergruppen fallen unter die Richtlinie? Klassifizieren Sie Ihre Organisation als Wesentliche oder Wichtige Einrichtung und bestätigen Sie die anwendbaren Verpflichtungen.
2. Verantwortlichkeit zuweisen. Bestimmen Sie einen Compliance-Verantwortlichen mit Artikel-20-Verantwortlichkeit — typischerweise der CISO oder IT-Direktor. Stimmen Sie IT-, Sicherheits-, Personal- und Rechtsteams auf Rollen, Verantwortlichkeiten und Eskalationspfade ab.
3. Infrastrukturbereitschaft bestätigen. Überprüfen Sie Serverspezifikationen und Netzwerktopologie für die On-Premise-Bereitstellung. Bestätigen Sie die Active-Directory- oder LDAP-Bereitschaft für automatisierte Benutzerbereitstellung.

Phase 2: Zugriffs-Audit — wo Sie heute stehen (Woche 2)

1. Alle privilegierten Konten erfassen. Identifizieren Sie jedes Konto mit Admin-Zugang über alle Systeme und Infrastrukturen. Schließen Sie Dienstkonten und gemeinsam genutzte Anmeldedaten ein — dies sind Ihre risikoreichsten Anmeldedaten.
2. Drittanbieterzugang identifizieren. Überprüfen Sie alle aktiven Drittanbieter- und Lieferantenzugänge. Dokumentieren Sie Umfang, Dauer und aktuellen MFA-Status. Hier entdecken die meisten Organisationen unkontrollierten Zugang.
3. Aktuelle Protokollierung bewerten. Was wird heute protokolliert, wo und wie lange? Dokumentieren Sie die Lücke zwischen aktuellem Zustand und den technischen Anforderungen der ENISA.

Phase 3: Passwork in Ihrer Umgebung bereitstellen (Woche 3)

1. On-Premise installieren. Bereitstellen über Docker Compose oder Bare-Metal-Server (Linux/Windows). Passwork läuft vollständig innerhalb Ihrer Infrastruktur ohne externe Credential-Übertragung.
2. Mit Identity-Systemen integrieren. Mit Active Directory oder LDAP für automatisierte Benutzerbereitstellung verbinden. SSO über SAML 2.0 für nahtlose, prüfbare Authentifizierung konfigurieren.
3. Anmeldedaten importieren und organisieren. Vorhandene Anmeldedaten in strukturierte Tresore nach Team, System und Kritikalität migrieren. Initiale Tresorstruktur und Eigentümerhierarchie definieren.

Phase 4: Für NIS2-Compliance konfigurieren (Woche 4)

1. RBAC definieren und durchsetzen. Das Least-Privilege-Prinzip durchgehend anwenden. Jeder Benutzer greift nur auf die Anmeldedaten zu, die seine Rolle erfordert.
2. MFA vorschreiben. Stufe 1 (FIDO2) für alle privilegierten Konten durchsetzen. Stufe 2 (TOTP) für alle Standardbenutzer durchsetzen. Durchsetzung als Audit-Nachweis dokumentieren.
3. Drittanbieterzugang isolieren. Dedizierte, zeitlich begrenzte Tresore für Lieferanten und Auftragnehmer mit automatischem Ablauf bei Vertragsende erstellen.
4. Passwortrichtlinien konfigurieren. Komplexitätsregeln, Rotationspläne und automatischen Ablauf durchsetzen. Vollständige Audit-Trail-Protokollierung aktivieren und SIEM-Integration über Syslog konfigurieren.

Phase 5: Laufende Überwachung und Berichterstattung (fortlaufend)

1. Vierteljährliche Zugriffsüberprüfungen planen. Validieren, dass RBAC-Zuweisungen korrekt bleiben. Sicherstellen, dass kein verwaister Zugang nach dem Ausscheiden von Mitarbeitern verbleibt.
2. Automatisierte Compliance-Berichte generieren. MFA-Durchsetzung, Zugangs-Governance und Kontrollwirksamkeit demonstrieren. Exportierbare Nachweispakete auf Abruf für regulatorische Einreichung bereithalten.
3. Audit-Protokolle überwachen. Warnungen mit SIEM für anomale Zugriffsmuster integrieren. Jährliche NIS2-Bereitschaftsbewertungen gegen aktualisierte ENISA-Leitlinien durchführen.

Die NIS2-Compliance-Checkliste

Verwenden Sie diese Checkliste, um Ihren Compliance-Status in den drei kritischen Bereichen zu verfolgen: Zugriffsmanagement, Supply-Chain-Sicherheit und Vorfallbereitschaft.

Zugriffskontrolle (Artikel 21(2)(i))

• Alle privilegierten Konten über alle Systeme und Infrastrukturen erfassen
• Strenge RBAC implementieren — jeder Benutzer greift nur auf Anmeldedaten zu, die seine Rolle erfordert
• Alle gemeinsam genutzten Konten eliminieren — durch individuellen Zugang ersetzen
• Identitätslebenszyklus über AD/LDAP automatisieren — sofortiger Zugriffswiderruf beim Ausscheiden von Mitarbeitern
• Berechtigungsmatrizen als prüferfertige Nachweise exportieren

Supply Chain (Artikel 21(2)(d))

• Alle Drittanbieterzugänge in dedizierten, zeitlich begrenzten Tresoren isolieren
• Alle aktiven Lieferanten-Credentials auditieren — jeden Zugang widerrufen, der nicht mehr operativ gerechtfertigt ist
• Lieferantenzugangsumfang, Dauer und MFA-Status für jede aktive Drittanbieter-Credential dokumentieren
• Automatischen Ablauf bei Vertragsende konfigurieren

MFA (Artikel 21(2)(j))

• Stufe-1-MFA (FIDO2/WebAuthn) für alle administrativen Konten durchsetzen
• Stufe-2-MFA (TOTP) für alle Standardbenutzer durchsetzen
• SMS- und E-Mail-OTPs auslaufen lassen — beide erfüllen die Mindestanforderungen der ENISA nicht
• Compliance-Bericht erstellen, der MFA für alle aktiven Konten bestätigt

Vorfallbereitschaft (Artikel 23)

• Überprüfen, dass Audit-Protokolle ausreichend Details für die 24-Stunden-Frühwarnung liefern
• Workflow für massenhafte Credential-Rotation für die Reaktion nach Vorfällen etablieren und testen
• Benannte Person für Artikel-23-Meldung bestimmen
• Exportierbare Nachweispakete auf Abruf für regulatorische Einreichung vorbereiten

Audit-Protokollierung (ENISA §11.4)

• Audit-Protokolle zentralisieren und schützen — unveränderliche, exportierbare Protokollierung konfigurieren
• Mit SIEM über Syslog integrieren — sicherstellen, dass kein Benutzer Protokolleinträge ändern oder löschen kann
• Bestätigen, dass jeder Eintrag Identität, Zeitstempel, Aktion und Quell-IP erfasst
• Automatisierte Berichte erstellen, die MFA-Durchsetzung, RBAC-Compliance und Zugriffsüberprüfungen abdecken

Strafen: Was Nichteinhaltung tatsächlich kostet

Die finanziellen und persönlichen Konsequenzen der NIS2-Nichteinhaltung sind gravierend:

• Für Wesentliche Einrichtungen: Bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Regulierungsbehörden können auch temporäre Betriebseinschränkungen verhängen.
• Für Wichtige Einrichtungen: Bis zu 7 Millionen Euro oder 1,4 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Reaktive Aufsicht bedeutet nicht geringeres Risiko.
• Persönliche Haftung für das Management (Artikel 20). Vorstandsmitglieder und C-Level-Führungskräfte können persönlich für Cybersicherheitsmängel haftbar gemacht werden. Zuständige Behörden können temporäre Verbote von Managementfunktionen verhängen. Diese Bestimmung hat keinen Präzedenzfall in NIS1 und verändert grundlegend, wie Führungskräfte Compliance angehen müssen.

Ab 2026 haben nationale zuständige Behörden in der gesamten EU mit proaktiven Audits von Wesentlichen Einrichtungen begonnen. Die Durchsetzungsphase ist aktiv.

Ihr NIS2-Nachweispaket erstellen

Regulierungsbehörden wollen Beweise. Ihr Compliance-Nachweispaket muss enthalten:

1. RBAC-Konfigurationsexport. Berechtigungsmatrizen, die zeigen, welche Benutzer/Rollen Zugang zu welchen Anmeldedaten haben.
2. MFA-Durchsetzungsbericht. Systemkonfiguration, die bestätigt, dass MFA global durchgesetzt wird, mit MFA-Methode pro Benutzer.
3. Audit-Protokollmuster. Repräsentative Protokolle, die Identität, Zeitstempel, Aktion und Quell-IP für Credential-Zugriff und -Änderungen zeigen.
4. Drittanbieterzugangs-Inventar. Dokumentierter Umfang, Dauer und MFA-Status für jede aktive Lieferanten-Credential.
5. Passwortrichtlinien-Dokumentation. Durchgesetzte Komplexitätsregeln, Rotationspläne und automatische Ablaufeinstellungen.
6. Vorfallreaktionsfähigkeit. Nachweis, dass massenhafte Credential-Rotation innerhalb von Stunden durchgeführt werden kann.
7. Backup- und Failover-Aufzeichnungen. Nachweis, dass Anmeldedaten während Systemausfällen zugänglich bleiben.

Der On-Premise-Vorteil für NIS2-Compliance

Organisationen fragen oft: Warum betont NIS2 die On-Premise-Bereitstellung? Die Antwort ist Datensouveränität und Audit-Unabhängigkeit.

1. Daten bleiben, wo Sie sie kontrollieren. Alle Anmeldedaten verbleiben in Ihrem Netzwerk ohne externe Übertragung, ohne Drittanbieter-Verwahrung und ohne jurisdiktionelle Unklarheiten.
2. Audit-Protokolle, die Sie besitzen und kontrollieren. Protokolle werden lokal gespeichert, direkt an Ihr SIEM über Syslog weitergeleitet, ohne Anbieter-Vermittler, ohne Einschränkungen und ohne dass Daten Ihren Perimeter verlassen.
3. Keine Drittanbieter-Datenabhängigkeit. Da das Credential-System innerhalb Ihrer Infrastruktur läuft, hält es keine Verwahrung über Ihre Anmeldedaten, wodurch die Drittanbieter-Datenabhängigkeit eliminiert wird, die Supply-Chain-Bewertungsanforderungen unter Artikel 21(2)(d) auslöst.
4. Compliance-Nachweise zu Ihren Bedingungen. Jeder Bericht, jedes Protokoll und jeder Konfigurationsexport wird aus Ihrer eigenen Infrastruktur generiert und ist auf Abruf für Prüfer verfügbar, ohne Abhängigkeit vom Support-Team oder der Datenaufbewahrungsrichtlinie eines Anbieters.
5. Isolierte Umgebungen unterstützt. Air-Gapped-Bereitstellung für OT/ICS-Infrastrukturen mit null Netzwerkexposition. Anmeldedaten bleiben auch dort zugänglich, wo Internetkonnektivität konstruktionsbedingt verboten ist.

Fazit: Von Compliance zum Wettbewerbsvorteil

NIS2 ist ein Mandat zur Sicherung der Infrastruktur, von der die europäische Gesellschaft abhängt. Credential-basierte Angriffsvektoren dominieren die Bedrohungslandschaft 2026 — und sie sind genau das, wofür Artikel 21 konzipiert wurde.

Organisationen, die Credential-Governance zentralisieren, Phishing-resistente MFA durchsetzen und unveränderliche Audit-Trails pflegen, tun mehr als nur das Audit zu bestehen. Sie eliminieren ihre bedeutendste Angriffsfläche. Die 5-Phasen-Implementierungs-Roadmap in diesem Leitfaden führt Sie innerhalb von 30–60 Tagen von fragmentiertem Zugriffsmanagement zu audit-bereiter Compliance.

Das technische Fundament für dieses Ergebnis erfordert drei Elemente: On-Premise-Bereitstellung, die Datensouveränität garantiert, RBAC, das Least Privilege im großen Maßstab durchsetzt, und Audit-Protokolle, die Regulierungsbehörden genau die Nachweise liefern, die sie benötigen.

Passwork liefert alle 9 technischen Kontrollen in dieser Tabelle: Passwortsicherheits-Dashboards, Massenrotation, Failover-Clustering, On-Premise-Bereitstellung, unveränderliche Audit-Trails, Richtliniendurchsetzung, AES-256-Verschlüsselung, RBAC und MFA. Erhalten Sie eine kostenlose Demo und erleben Sie es in Aktion.

Bereit, von der Compliance-Planung zur Implementierung überzugehen? Laden Sie den vollständigen NIS2-Compliance-Leitfaden herunter für detaillierte technische Zuordnung, branchenspezifische Anleitungen und eine anpassbare Compliance-Checkliste.

Häufig gestellte Fragen

Was verlangt NIS2 Artikel 21 tatsächlich von meiner Organisation?

Artikel 21 schreibt 10 spezifische Sicherheitsmaßnahmen vor: Risikoanalyse, Vorfallbehandlung, Geschäftskontinuität, Supply-Chain-Sicherheit, sichere Entwicklung, Überprüfung der Kontrollwirksamkeit, Cyber-Hygiene, Verschlüsselung, Zugriffskontrolle und MFA. Alle 10 sind für jede betroffene Organisation verbindlich. Die am besten prüfbaren und sicherheitskritischsten Maßnahmen sind Zugriffskontrolle (Artikel 21(2)(i)), MFA (Artikel 21(2)(j)) und Audit-Protokollierung (Artikel 21(2)(f)).

Wer muss NIS2 einhalten?

Organisationen in 18 europäischen Sektoren, die als Wesentliche Einrichtungen klassifiziert sind, müssen sofort die Vorgaben einhalten. Dazu gehören Energie, Verkehr, Wasser, Gesundheit, digitale Infrastruktur und öffentliche Verwaltung. Wichtige Einrichtungen (Finanzdienstleistungen, Lebensmittelversorgung, Fertigung, Chemie, Raumfahrt) haben bis Oktober 2025 Zeit für die vollständige Einhaltung. Nicht-EU-Organisationen, die in diesen Sektoren innerhalb der EU-Jurisdiktion tätig sind, fallen ebenfalls in den Geltungsbereich.

Welche Strafen drohen bei Nichteinhaltung?

Wesentliche Einrichtungen riskieren Bußgelder von bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Wichtige Einrichtungen riskieren bis zu 7 Millionen Euro oder 1,4 % des weltweiten Jahresumsatzes. Vorstandsmitglieder und C-Level-Führungskräfte haften persönlich nach Artikel 20, einschließlich temporärer Verbote von Managementfunktionen. Die Durchsetzung ist ab 2026 aktiv.

Wie lange dauert die Implementierung der NIS2-Compliance für das Zugriffsmanagement?

Die meisten Organisationen erreichen mit einem strukturierten 5-Phasen-Ansatz innerhalb von 30–60 Tagen audit-bereite Compliance: Vor-Bereitstellungs-Bewertung (Woche 1), Zugriffs-Audit (Woche 2), Credential-System-Bereitstellung (Woche 3), NIS2-Konfiguration (Woche 4) und laufende Überwachung. Der Zeitrahmen hängt von der Infrastrukturkomplexität und dem Volumen der zu migrierenden vorhandenen Anmeldedaten ab.

Was ist der Unterschied zwischen Wesentlichen und Wichtigen Einrichtungen unter NIS2?

Wesentliche Einrichtungen betreiben kritische Infrastruktur (Energie, Verkehr, Wasser, Gesundheit, digitale Infrastruktur, öffentliche Verwaltung). Wichtige Einrichtungen erbringen wesentliche Dienstleistungen (Finanzdienstleistungen, Lebensmittelversorgung, Fertigung, Chemie, Raumfahrt). Wesentliche Einrichtungen sehen sich höheren Strafen (10 Millionen Euro vs. 7 Millionen Euro) und strengeren Durchsetzungszeitplänen gegenüber. Beide müssen alle 10 Maßnahmen nach Artikel 21 umsetzen.

Warum betont NIS2 das On-Premise-Credential-Management?

On-Premise-Bereitstellung garantiert Datensouveränität: Anmeldedaten verbleiben in Ihrem Netzwerk ohne externe Übertragung oder Drittanbieter-Verwahrung. Audit-Protokolle werden lokal gespeichert und direkt an Ihr SIEM weitergeleitet, ohne Anbieter-Vermittler. Dies eliminiert die Drittanbieter-Datenabhängigkeit, die Supply-Chain-Bewertungsanforderungen unter Artikel 21(2)(d) auslöst, und gibt Ihnen vollständige Audit-Unabhängigkeit.

Welche MFA-Stufe verlangt NIS2?

ENISA spezifiziert drei Stufen: Stufe 1 (Phishing-resistent) — FIDO2, WebAuthn, Hardware-Sicherheitsschlüssel — ist für alle privilegierten und administrativen Konten obligatorisch. Stufe 2 (TOTP-Authenticator-Apps, Push-Benachrichtigungen) ist für Standardbenutzer akzeptabel. SMS- und E-Mail-OTPs sind explizit zur Auslaufphase gekennzeichnet und erfüllen die Mindestanforderungen der ENISA nicht.

Wie weise ich NIS2-Compliance gegenüber Regulierungsbehörden nach?

Ihr Nachweispaket muss enthalten: RBAC-Konfigurationsexporte mit Berechtigungsmatrizen, MFA-Durchsetzungsberichte, die globale Durchsetzung bestätigen, repräsentative Audit-Protokolle mit Identität/Zeitstempel/Aktion/Quell-IP, Drittanbieterzugangs-Inventar mit Umfang und Dauer, Passwortrichtlinien-Dokumentation, Nachweis der massenhaften Credential-Rotationsfähigkeit sowie Backup-/Failover-Aufzeichnungen. Alle Nachweise müssen exportierbar und auf Abruf prüferbereit sein.

Wie sieht der Meldezeitplan nach Artikel 23 aus?

Artikel 23 führt drei Stufen ein: Frühwarnung (24 Stunden) — das nationale CSIRT benachrichtigen, dass ein Vorfall stattgefunden hat. Vorfallmeldung (72 Stunden) — erste Bewertung einschließlich Schweregrad, Auswirkungen und betroffene Systeme bereitstellen. Abschlussbericht (1 Monat) — vollständige Ursachenanalyse, Abhilfemaßnahmen und gewonnene Erkenntnisse. Organisationen ohne zentralisiertes Credential-Management und automatisierte Rotation können die 24-Stunden-Frist nicht einhalten.

Passwort- und Zugriffsmanagement für KMUs: Reicht KeePass aus?

Sie nutzen KeePass für Ihr Team? Entdecken Sie die versteckten Risiken von KeePass für KMUs im Jahr 2026 — Synchronisierungsfehler, Compliance-Lücken und wann der Wechsel zu einem Unternehmens-Passwortmanager sinnvoll ist.

Passwork BlogAlex Muntyan

Ist passwortlose Authentifizierung für NIS2-Compliance erforderlich?

NIS2 Artikel 21(2)(j) schreibt MFA „wo angemessen" vor — nicht standardmäßig passwortlos. Erfahren Sie, was die ENISA-Leitlinien tatsächlich verlangen, wie Prüfer Ihre Implementierung bewerten und wie Sie eine vertretbare hybride Compliance-Position für 2026 aufbauen.

Passwork BlogAlex Muntyan

Passwork gewinnt Top Performer Frühjahr 2026 auf SourceForge

Passwork wurde von SourceForge als Top Performer Frühjahr 2026 ausgezeichnet und rangiert unter den Top 10 % von über 100.000 Lösungen. Das Abzeichen basiert ausschließlich auf verifizierten Bewertungen — 4,8 Sterne insgesamt, mit einer perfekten 5,0 für Support.

Passwork BlogAlex Muntyan