Shadow IT is the use of unapproved technology without IT knowledge or oversight. Shadow AI is the use of unapproved AI tools, models, features, and workflows — and it is often riskier because it can process sensitive data, influence decisions, generate outputs, and interact with credentials or systems entirely outside normal governance.

The scale of the problem is already visible in breach data:

• One in five organizations reported a breach due to shadow AI, and high shadow AI usage added an average of $670,000 to breach costs — IBM's 2025 Cost of a Data Breach Report.
• More than half of executives (58%) reported that their organization experienced an AI-related security incident or a close call in the past year — Okta's AI Agents at Work 2026 survey.
• Over 1.27 million AI service secrets were found leaked on public GitHub. 81% more than the year before. Eight of the ten fastest-growing leaked secret types are tied to AI services — GitGuardian's State of Secrets Sprawl 2026.
• Only 5% of businesses have full visibility into which AI tools employees are actually using, and 78% either confirmed an AI-related security incident or could not rule one out — Check Point's 2026 Cloud Security Report.
• 92% of security professionals are concerned about AI agents and their security impact, yet only 37% of organizations have a formal AI policy in place — Darktrace's State of AI Cybersecurity 2026.

Governments have taken notice. The EU AI Act is now in active enforcement, with penalties for non-compliant use of high-risk AI systems reaching up to €15 million or 3% of global annual turnover.

In the United States, President Trump signed an executive order on June 2, 2026 — "Promoting Advanced Artificial Intelligence Innovation and Security" — directing CISA to expand AI-enabled cyber defenses across federal systems and critical infrastructure operators, and establishing a voluntary framework for assessing frontier AI models before public release. The order does not regulate how employees use AI inside enterprises, but it signals clearly that AI security is now a federal priority and that organizations operating critical infrastructure are already in scope.

The tools are in use. The data is moving. Where? Most organizations just don't know.

Key takeaways

• Shadow AI is a distinct risk category, not just Shadow IT with AI branding. Unapproved AI tools, models, and agents process data, influence decisions, and interact with credentials entirely outside normal governance, where traditional Shadow IT only creates unmanaged technology sprawl.
• The breach data is already visible. One in five organizations reported a breach due to Shadow AI. Most businesses have no clear picture of which AI tools employees are actually using.
• Personal accounts are the primary control gap. Most AI tool usage happens through personal accounts that bypass SSO, DLP, and centralized logging, leaving no audit trail and no contractual basis for data deletion.
• AI agents shift the problem from data input to access and action. Agents can read files, call APIs, and modify code through delegated OAuth permissions, and those actions may not be logged anywhere the security team can see.
• Credential exposure is the highest-severity gap. Logs, code snippets, environment files, and browser autofill data frequently contain passwords, API keys, or tokens. When pasted into an AI tool, the result is a potential persistent access path, not just a data exposure event.
• Blanket prohibition relocates Shadow AI, it doesn't eliminate it. Employees move to personal devices and alternative tools with fewer audit signals. Effective governance provides approved alternatives and monitors sensitive data movement.
• Regulators have taken notice. The EU AI Act is in active enforcement, with penalties reaching €15 million or 3% of global annual turnover. A U.S. executive order signed June 2, 2026 signals that AI security is now a federal priority.
• Governance requires five specific responses. Data classification, approved tool provisioning, output governance, agent permission review, and secrets management. Existing Shadow IT controls are necessary but not sufficient.

What is Shadow IT?

Shadow IT is any technology (software, hardware, cloud services, SaaS applications, scripts, or infrastructure) used within an organization without IT approval, knowledge, or oversight. The term covers a wide range of behavior: an employee using a personal cloud drive to share files, a team spinning up an unapproved project management tool, a developer running scripts on unmanaged infrastructure, or a department subscribing to a SaaS product outside the procurement process.

The core problem with Shadow IT is governance loss. When IT doesn't know a tool exists, it can't enforce access controls, apply Data Loss Prevention (DLP) policies, manage the data lifecycle, or revoke access when an employee leaves. Licensing, compliance, and audit trail requirements also fall through the gaps.

Shadow IT follows a predictable path. An employee needs a tool — faster file sharing, a project tracker, a script that runs on something other than the approved stack. The official process is too slow or the tool simply isn't available, so they find their own solution. IT never finds out.

Common Shadow IT examples include:

• Personal cloud storage (consumer accounts used for work files)
• Unapproved messaging and collaboration apps
• Browser extensions with broad data permissions
• Unmanaged SaaS subscriptions paid by a team budget
• Developer-built scripts and automation tools running outside IT visibility
• Consumer devices connected to corporate networks

Shadow IT is not always malicious. Most of it starts as a productivity workaround — a team needed a tool, procurement was slow, and someone found a free alternative. That context matters for governance: prohibition without replacement rarely works.

What is Shadow AI?

Shadow AI is the unsanctioned use of AI tools, AI features, models, prompts, agents, and workflows without IT approval or oversight. It is related to Shadow IT but distinct: where Shadow IT mainly creates unmanaged technology sprawl, Shadow AI creates unmanaged data processing, unmanaged decision support, and unmanaged action.

Shadow AI includes a broad and fast-growing set of behaviors. Employees use public large language models (LLMs) like ChatGPT, Claude, and Gemini through personal accounts. Developers use AI coding assistants such as GitHub Copilot or Cursor outside enterprise tenants. Teams use AI meeting assistants, AI browser extensions, and AI-powered SaaS features that were never formally reviewed. Some employees build their own AI workflows using consumer automation tools.

Shadow AI follows the same path as Shadow IT, but the consequences at the end are different. An employee needs to move faster — summarize a document, generate code, draft a response. There's no approved tool, or the approved tool is slower than the one they already use personally. So they use their own account, a browser extension, or an AI feature embedded in a SaaS product IT already approved but never audited.

Common examples of Shadow AI in practice:

• Employees using ChatGPT, Claude, Gemini, or Perplexity through personal free-tier accounts
• Developers using AI coding assistants outside enterprise license controls
• Sales and marketing teams using AI writing tools not reviewed by security
• HR and finance teams using AI to summarize documents containing regulated data
• AI meeting assistants recording and transcribing calls without enterprise retention controls
• Browser-based AI extensions with access to page content, clipboard, and form fields
• Employee-built AI agents connecting to SaaS APIs or internal systems

The scale is significant. Menlo Security's 2025 report recorded 10.53 billion visits to AI sites in January 2025 alone, up from 7 billion in February 2024, with 80% of that access happening through browsers. Shadow AI is not a niche behavior — it is how most employees currently use AI.

Shadow IT vs Shadow AI: The key differences

Shadow IT and Shadow AI share the same root cause: employees solving real problems with tools IT hasn't approved. But they create different risk profiles and require different controls.

The remediation gap is particularly significant. When an employee uses an unapproved SaaS tool, IT can revoke access and migrate data. When sensitive content enters an external AI model's workflow, confirming deletion, proving non-retention, and scoping the incident is substantially harder, especially when the tool was accessed through a personal account with no enterprise audit trail.

Why Shadow AI is the bigger threat

Shadow AI is often more dangerous than traditional Shadow IT because it doesn't just store or move data — it processes, generates, and acts on it. The following five dimensions explain where the risk model changes. Together, they form what this article calls the Shadow AI risk multiplier.

1. Data exfiltration happens through ordinary work

Employees don't need to exfiltrate data intentionally. They paste emails, contracts, spreadsheets, source code, support tickets, customer records, HR information, and system logs into AI tools as part of normal work. Each prompt is a potential data transfer.

Harmonic Security's analysis of 22,458,240 enterprise GenAI prompts from 2025 detected 579,113 sensitive data exposure instances across 665 AI tools. Code, legal documents, and financial data accounted for 74.5% of what was exposed. According to Cyberhaven's 2026 AI Adoption & Risk Report, 39.7% of all AI interactions involved sensitive data, and employees input sensitive data into AI tools once every three days on average.

Sensitive data and AI are now embedded in daily workflows, and the exposure is not occasional.

2. Personal accounts break enterprise controls

A significant share of AI usage happens through personal accounts rather than enterprise tenants. Cyberhaven's 2026 data found that 32.3% of ChatGPT usage, 58.2% of Claude usage, and 60.9% of Perplexity usage occurred through personal accounts. Menlo Security's 2025 report found that 68% of employees used free-tier AI tools via personal accounts, with 57% inputting sensitive data.

Personal accounts bypass SSO enforcement, enterprise retention policies, centralized logging, DLP controls, and admin-level data governance. When an employee uses Claude or Perplexity through a personal account, the organization has no visibility into what was submitted, no audit trail, and no contractual basis for data deletion or non-training commitments.

3. AI can influence decisions, not just store files

Shadow IT mainly creates unmanaged data storage or transfer. Shadow AI does something more: it summarizes, classifies, ranks, recommends, generates code, and drafts customer-facing or legal content. An unapproved AI tool can shape a business decision based on unverified data, an unknown model version, and assumptions the user never examined.

Hallucinations, model drift, and bias in AI output are real failure modes. When the tool is unsanctioned and the output is unattributed, there is no way to audit the decision chain after the fact.

4. AI agents extend the problem from input to action

AI agents can read files, use clipboards, call APIs, send messages, modify code, and connect to SaaS systems. Many run at the operating system level, maintain persistent context windows, and synchronize data to infrastructure outside security team oversight.

This moves Shadow AI from a data-input problem to an access-and-action problem. An agent with delegated OAuth permissions or an API key can act on behalf of a user, and those actions may not be logged anywhere the security team can see.

5. Credential and secrets exposure turns AI use into access risk

Logs, code snippets, environment files, browser autofill data, and support tickets frequently contain passwords, API keys, or tokens. When these get pasted into an AI tool — often accidentally — the result is not just a data exposure event. It is a potential persistent access path.

IBM's 2025 report found that 97% of organizations compromised through AI models or applications lacked proper AI access controls, which means most organizations that experienced an AI-related breach had no meaningful control layer in place.

If your team is starting to map Shadow AI exposure, credentials and secrets are often the highest-severity gap. Passwork centralizes shared passwords, API keys, and service account credentials in a single encrypted vault with RBAC, LDAP/SSO integration, and a full audit log of every access event. When an employee leaves or an AI workflow is decommissioned, access is revoked in one place, not tracked down across a dozen tools. Try Passwork free

Real-world examples of Shadow AI risk

The risk scenarios below are representative of what security and IT teams encounter across departments. None require malicious intent — each starts with a legitimate productivity goal.

Risk tends to concentrate in a small number of high-usage tools, which is useful for governance prioritization. But the long tail still matters — a rarely used integration can carry the same credential exposure risk as a daily-use assistant.

Why banning AI usually makes Shadow AI worse

A blanket ban on AI tools does not eliminate Shadow AI. It relocates it. Employees move to personal devices, personal accounts, or alternative tools that IT has less visibility into. The result is the same data exposure with fewer audit signals.

According to Okta survey published in May 2026, more than half of employees reported using personal AI tools without approval. Two-thirds of U.S.-based employees use unsanctioned AI, and nearly a quarter do so regularly. At the same time, 58% of executives said their organization had an AI-related security incident or close call in the previous year.

The Okta research also found that more than half of employees say their organization's AI usage policies are unclear, difficult to find, or non-existent. That gap between executive confidence and employee experience is where Shadow AI grows.

Some high-risk use cases should be blocked outright — pasting customer records into a public AI tool, or connecting a consumer AI agent to production systems. But blanket prohibition doesn't work. Employees adopt shadow AI for rational reasons: better tools, faster results, procurement that moves too slowly. Effective governance provides approved alternatives, sets clear boundaries, and monitors sensitive data movement. Ignore the underlying incentives and the behavior won't change.

How to detect Shadow AI in the enterprise

Detecting shadow AI requires visibility across browsers, endpoints, SaaS permissions, and identity systems. IBM's 2025 research found that only 34% of organizations with AI governance policies performed regular audits for unsanctioned AI — meaning most organizations have policy without operational visibility.

A practical detection approach covers seven areas

1. Step 1. Inventory AI domains, browser extensions, SaaS AI features, AI meeting tools, AI coding assistants, and AI features embedded in already-approved applications.
2. Step 2. Monitor browser-based GenAI usage, copy/paste events, file uploads, and downloads where legally and ethically appropriate under your jurisdiction's employee monitoring rules.
3. Step 3. Review OAuth grants, API tokens, service accounts, and third-party app permissions. AI agents and integrations often request broad OAuth scopes that persist long after initial setup.
4. Step 4. Classify sensitive data categories that should never be submitted to external AI tools without explicit approval: PII, source code, financial forecasts, legal documents, regulated health data, and credentials.
5. Step 5. Check identity controls: SSO coverage, MFA enforcement, SCIM/LDAP provisioning, RBAC assignments, and audit log completeness. Personal AI accounts bypass all of these.
6. Step 6. Search for exposed credentials in code repositories, logs, tickets, and AI-related workflows. Tokens and API keys appear in unexpected places — commit history, Slack threads, support tickets, and AI prompt logs.
7. Step 7. Map AI usage to business need before blocking it. Understanding why employees use a tool is necessary for providing a governed alternative that they will actually use.

How to reduce Shadow AI risk without blocking productivity

Effective Shadow AI governance is an enablement problem as much as a security problem. The goal is to give employees safe, approved options while applying controls where sensitive data is at risk.

The identity and access layer needs three things: SSO coverage across approved AI tools, MFA enforcement, and SCIM or LDAP provisioning that ties access directly to employment status. For passwords and secrets, a centralized vault with role-based access control, Active Directory integration, and activity logs turns credential management from a manual chore into an auditable process.

Where passwords and secrets fit into Shadow AI governance

Shadow AI governance is about what credentials and permissions AI-adjacent tools can reach.

Credential exposure in AI workflows often happens indirectly:

• A developer pastes a log file into a coding assistant — the log contains a database connection string
• A support engineer shares a screenshot in an AI tool — the screenshot shows an API key in a browser tab
• An employee uploads an environment configuration file for AI-assisted debugging — the file contains service account credentials

None of these are deliberate exfiltration events. All of them create real access risk.

AI coding assistants and agents compound this. They can interact with repositories, terminals, SaaS APIs, and local file systems. An agent with access to a developer's terminal session can read environment variables, SSH keys, and credential files. If that agent runs through a personal account with no enterprise audit trail, the organization has no record of what was accessed.

The governance goal is to prevent unmanaged AI workflows from turning a pasted token or shared password into a persistent access path. That requires specific controls: unique credentials per service, no shared passwords in chat or tickets, vault-based sharing with access controls, least privilege on service accounts, MFA on all administrative access, regular secret rotation, API key inventory, OAuth permission reviews, and audit logs covering credential access.

Passwork is available as a self-hosted deployment or in the cloud, with a full REST API and CLI tools for teams that need to integrate credential management into existing DevOps workflows. Access reviews, audit logs, and role assignments are managed through a single interface — no separate tooling required. Learn more

A practical Shadow AI governance checklist

This checklist is designed for security engineers and compliance teams beginning or maturing a Shadow AI governance program. Review it quarterly — AI tool capabilities and regulatory requirements change faster than annual cycles can track.

The Shadow AI governance checklist (10 points)

1. Define approved, conditional, and prohibited AI use cases by data type and business function.
2. Create a list of approved AI tools by function: writing, coding, data analysis, meeting notes, customer support.
3. Require enterprise accounts for approved tools where sensitive data may be processed.
4. Block or warn on public upload of restricted data categories (PII, source code, financial forecasts, legal documents, credentials).
5. Review AI browser extensions and OAuth permissions — revoke those without a documented business need.
6. Audit API tokens, service accounts, shared credentials, and secrets used near AI workflows.
7. Add DLP or browser controls for prompts, file uploads, and copy/paste events where appropriate and legally permitted.
8. Publish examples of allowed and prohibited prompts — concrete examples outperform abstract policy.
9. Train teams by role: developers, sales, legal, HR, finance, and support face different AI risk scenarios.
10. Review AI policies quarterly because tool capabilities, vendor retention terms, and regulations change quickly.

Conclusion

Shadow AI is not a reason to slow AI adoption. It is a reason to govern AI as a data, identity, and access problem — the same disciplines that security teams already apply to other technology, applied to a faster-moving and harder-to-observe category.

The five dimensions of the Shadow AI risk multiplier — data exfiltration through ordinary work, personal accounts that break enterprise controls, AI-influenced decisions, agentic action, and credential exposure — explain why existing Shadow IT controls are necessary but not sufficient. Each dimension requires a specific response: data classification, approved tool provisioning, output governance, agent permission review, and secrets management.

The organizations that manage this well are the ones that give employees safe options, define clear rules, and build the monitoring capability to see what is actually happening.

If your team is reviewing Shadow AI controls, include shared passwords, API keys, service accounts, and secrets in the assessment. Passwork supports this part of the governance program by centralizing credential access, integrating with LDAP/SSO, and providing audit visibility for password-related workflows.

Frequently Asked Questions

Is Shadow AI the same as Shadow IT?

No. Shadow AI is related to Shadow IT but specifically involves unapproved AI tools, AI features, models, prompts, agents, and workflows. It adds distinct risks around data processing through prompts and file uploads, model retention, generated output quality, and delegated permissions for AI agents. Traditional Shadow IT mainly creates unmanaged technology sprawl.

Why is Shadow AI more dangerous than Shadow IT?

Shadow AI is often more dangerous because it can expose sensitive data through prompts and file uploads, influence business decisions through unverified outputs, and interact with credentials or systems through agents and integrations. IBM's 2025 research found that organizations with high shadow AI usage incurred an average of $670,000 more in breach costs than those with low or no shadow AI usage.

What data should employees never paste into public AI tools?

Employees should not paste passwords, API keys, tokens, source code, customer records, HR records, legal documents, financial forecasts, regulated data (health records, PII), or confidential IP into public AI tools unless the organization has explicitly approved that tool and use case with appropriate contractual data protections in place.

Can companies completely stop Shadow AI?

Most organizations should not rely on complete prohibition. Harmonic Security's 2025 data found that while only 40% of companies have purchased official AI subscriptions, employees at over 90% of organizations actively use AI tools — mostly through personal accounts. A better strategy is to provide approved AI tools, define clear use cases, monitor sensitive data movement, and enforce access controls.

How can security teams detect Shadow AI?

Detection requires a combination of AI domain inventory, browser visibility tools, DLP, SaaS security posture review (SSPM), OAuth grant review, endpoint telemetry, and employee reporting. Security teams should also audit AI features embedded in already-approved SaaS tools — these are often overlooked because the parent application is sanctioned.

How do password managers help with Shadow AI risk?

Password managers do not govern AI by themselves, but they reduce credential sprawl around AI workflows. They help centralize shared credentials, enforce role-based access controls, support audit trails for password and secret use, simplify secret rotation, and provide visibility into which credentials are shared and with whom — all of which matter when AI tools or agents may have touched those credentials.

Does the EU AI Act address Shadow AI?

The EU AI Act (in force from August 2024, with phased obligations through 2027) establishes requirements for AI system providers and deployers, including transparency, risk classification, and governance obligations for high-risk AI systems. It does not directly regulate employee use of consumer AI tools, but organizations subject to the Act should ensure their AI governance programs cover unsanctioned use, particularly for high-risk use cases. Legal teams should review applicable obligations under the specific articles relevant to their AI deployment context.

VaultJacking: How one PIN can expose a Google password manager vault

VaultJacking targets the Google Password Manager PIN to unlock your entire vault. One captured PIN exposes every saved password and passkey. Learn how the attack works, who’s at risk, and what to do if you’ve been phished.

Passwork BlogAlex Muntyan

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

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

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

O VaultJacking é uma técnica de phishing que visa o cofre do Google Password Manager ao capturar o PIN que o desbloqueia. Demonstrado pela PhishU em 20 de maio de 2026, o ataque mostra como um único segredo de seis dígitos, capturado durante uma sessão de phishing adversary-in-the-middle (AiTM), pode dar a um atacante acesso a todas as palavras-passe e passkeys sincronizadas que a vítima tem guardadas no Google Password Manager.

Para as empresas, o risco é maior do que parece. O cofre do navegador de um único colaborador pode conter credenciais de SSO, acesso a consolas cloud, inícios de sessão em plataformas financeiras e chaves de repositórios de código: tudo num só local e exposto por um único PIN capturado. É um risco organizacional que fica fora da maioria dos playbooks de resposta a incidentes existentes e fora da visibilidade da maioria das equipas de TI e de segurança.

Pontos principais

O VaultJacking é relevante porque os gestores de palavras-passe dos navegadores concentram palavras-passe, passkeys e fluxos de recuperação num único alvo de elevado valor. Antes de continuar a leitura, eis o que é necessário saber.

• O VaultJacking visa a camada de sincronização do cofre. O ataque não quebra a criptografia WebAuthn. Explora o fluxo de inscrição de dispositivos, que determina quem pode ler o cofre sincronizado.
• O PIN do Google Password Manager é um segredo de acesso ao cofre. A Google utiliza o PIN para proteger os dados de credenciais cifrados. Deve ser tratado como tal, e não como um código descartável.
• Um único PIN capturado pode expor todo o cofre. A demonstração da PhishU mostra que a introdução de um único PIN pode permitir a um atacante decifrar todas as palavras-passe e passkeys sincronizadas em infraestrutura controlada pelo operador.
• O risco empresarial aumenta com as lacunas de governação. A mistura de perfis pessoais e profissionais, os perfis do Chrome não geridos e as credenciais privilegiadas guardadas em cofres de navegador aumentam, todos, o raio de impacto.
• A resposta a incidentes tem de ir além da reposição da palavra-passe. Um evento de VaultJacking suspeito exige a revisão de dispositivos, sessões, passkeys, conteúdo do cofre e inícios de sessão em serviços associados, e não apenas a alteração de uma palavra-passe.

O que é o VaultJacking?

O VaultJacking é uma técnica de phishing que visa o acesso ao cofre do Google Password Manager e a respetiva experiência de recuperação. Em vez de roubar a credencial de um único site, o atacante captura o PIN do Google Password Manager durante uma sessão de phishing AiTM e utiliza-o para inscrever um dispositivo sob o seu controlo no domínio de segurança Google da vítima, o que lhe dá acesso a todo o cofre de credenciais sincronizado. O termo e a demonstração de ponta a ponta têm origem na investigação publicada pela PhishU.

O phishing de credenciais tradicional visa uma conta de cada vez. O VaultJacking é uma classe de ataque diferente: o atacante ignora por completo as credenciais individuais e vai diretamente ao repositório que as contém a todas.

A investigação da PhishU descreve o ataque como totalmente coerente com o phishing AiTM habitual. O proxy AiTM captura o PIN juntamente com os cookies de sessão. Um processo em segundo plano adiciona depois uma passkey controlada pelo atacante à conta Google da vítima, para persistência, associa-se ao domínio de segurança a partir da infraestrutura do atacante com o PIN capturado e decifra todo o cofre. O operador vê todas as credenciais sincronizadas numa única vista.

Browser Syncjacking, uma técnica distinta referida pela PhishU, chega à mesma camada de sincronização da Google através de uma extensão maliciosa do navegador. O VaultJacking não requer um ponto de apoio no dispositivo nem uma extensão.

O que é o PIN do Google Password Manager?

O PIN do Google Password Manager é um segredo distinto da palavra-passe da conta Google e do bloqueio de ecrã do dispositivo. A documentação da Google descreve-o como uma forma de proteger os dados cifrados do Google Password Manager, utilizar passkeys num novo dispositivo e verificar a identidade.

Os utilizadores confundem com frequência três segredos diferentes, e essa confusão contribui para a eficácia do VaultJacking:

O pedido do PIN do Google Password Manager surge ao criar a primeira passkey num novo dispositivo, ao aceder a credenciais guardadas e cifradas em determinados contextos de recuperação ou quando um novo dispositivo se associa ao domínio de segurança Google. Este último cenário é precisamente o que o VaultJacking explora.

A razão estrutural para este funcionamento, de acordo com a análise da PhishU ao código-fonte do Chromium (chrome/browser/webauthn/enclave_manager.cc e components/trusted_vault/), é que o fluxo de associação ao domínio de segurança da Google exige duas verificações: um início de sessão na conta Google e a introdução correta do PIN. Não existe pedido de aprovação entre dispositivos, notificação push para os dispositivos existentes nem confirmação do tipo «aprovar a partir de outro dispositivo».

O iCloud Keychain da Apple exige que os dispositivos existentes aprovem os novos. O modelo da Google não o faz. A Google fez uma escolha deliberada de experiência de utilização: um PIN com limite de tentativas no servidor é mais fácil de recuperar do que um modelo de aprovação por notificação push quando o utilizador perdeu todos os seus dispositivos. O VaultJacking é a consequência dessa escolha.

Como funciona a cadeia de ataque do VaultJacking

A descrição seguinte apresenta o ataque de forma concetual, para fins defensivos. Não são incluídos detalhes de implementação ofensiva.

1. Isca. A vítima recebe uma ligação de phishing e chega a uma página que imita um início de sessão ou um fluxo de conta legítimo da Google. Qualquer fluxo de início de sessão inesperado recebido por e-mail, chat ou anúncio deve ser encarado com desconfiança.
2. Transferência de confiança. O proxy AiTM apresenta um pedido de PIN com o aspeto da interface da própria Google: o mesmo tipo de letra, o mesmo campo de seis células, o mesmo texto. A formação dos utilizadores deve abranger os pedidos de PIN do gestor de palavras-passe, e não apenas as palavras-passe e os códigos OTP.
3. Captura do PIN. A vítima introduz o PIN no fluxo de phishing. O PIN é um segredo de acesso ao cofre, com sensibilidade equivalente à de uma palavra-passe mestra.
4. Inscrição do dispositivo do atacante. O atacante utiliza o PIN capturado para se associar ao domínio de segurança Google da vítima a partir de infraestrutura sob o seu controlo. É também registada uma passkey do atacante para persistência. Após qualquer suspeita de contacto com phishing, devem ser revistos de imediato os dispositivos com sessão iniciada e as passkeys registadas.
5. Decifragem do cofre. O Security Domain Secret é libertado pelo autenticador na cloud da Google e o dispositivo do atacante decifra todas as palavras-passe e passkeys sincronizadas. O cofre pode conter credenciais de e-mail, SSO, consolas cloud, plataformas financeiras e repositórios de código.
6. Comprometimento de outros serviços. As credenciais de terceiros guardadas são utilizadas contra outros serviços. Deve proceder-se à rotação das credenciais de elevado valor e monitorizar os inícios de sessão em serviços de terceiros.

A PhishU testou o processo de ponta a ponta em contas reais do Google Password Manager, incluindo a reprodução de passkeys de terceiros capturadas, independentemente de a credencial original ser baseada em hardware. Esta deve ser tratada como uma técnica demonstrada. Não existem provas públicas de exploração ativa generalizada à data da redação, mas a técnica não requer acesso especializado nem um ponto de apoio no dispositivo.

O VaultJacking significa que as passkeys foram quebradas?

Não. O VaultJacking não quebra a criptografia das passkeys. As passkeys baseiam-se em autenticação de chave pública vinculada à origem, tal como definida na especificação W3C WebAuthn: a chave privada nunca sai do dispositivo e a cerimónia de autenticação está vinculada à origem do site legítimo. Uma página de phishing não consegue reproduzir uma asserção WebAuthn no site real, porque a verificação da origem falha. Essa proteção mantém-se.

O que o VaultJacking demonstra é que as passkeys não existem isoladas. Existem dentro de um cofre, que se sincroniza entre dispositivos, que depende de um mecanismo de recuperação, que é governado por um PIN. O atacante contorna por completo a cerimónia criptográfica ao visar, em vez disso, a camada de gestão do cofre.

A Google descreve as passkeys como uma forma de iniciar sessão com uma impressão digital, uma leitura facial ou o bloqueio de ecrã, de forma mais simples e segura do que com palavras-passe. Essa descrição é rigorosa na camada de autenticação por site. O problema que o VaultJacking revela situa-se um nível acima: o que governa o acesso ao repositório que guarda essas passkeys.

Porque é que um só PIN pode ter um grande raio de impacto

Um cofre de palavras-passe é um repositório concentrado de acessos. Um único PIN capturado expõe todas as credenciais que a vítima alguma vez guardou no Google Password Manager.

O Identity Threat Landscape Report de 2025 da Recorded Future concluiu que o dispositivo comprometido médio forneceu 87 credenciais roubadas e que 276 milhões das credenciais indexadas em 2025 incluíam cookies de sessão ativos, o que significa que os atacantes podiam contornar a MFA por completo nessas contas.

O DBIR 2026 da Verizon contextualiza o efeito em cadeia: o abuso de credenciais surge, em algum momento, em 39 % de todas as violações confirmadas, em mais de 22 000 incidentes em 145 países. Raramente os atacantes ficam pela primeira porta que uma credencial roubada abre. Movem-se lateralmente, escalam privilégios e percorrem todos os inícios de sessão guardados até encontrarem algo valioso.

Quem está mais em risco?

O risco concentra-se onde se sobrepõem três condições: os dados do cofre do navegador são o principal repositório de credenciais, as credenciais profissionais e pessoais partilham um perfil e as credenciais privilegiadas foram parar a um sistema de nível consumidor.

1. O problema da mistura de credenciais. Os colaboradores guardam credenciais profissionais em perfis pessoais do Chrome. Os administradores não têm visibilidade nem controlo sobre o conteúdo do cofre nem sobre os dispositivos sincronizados. Isto significa que as palavras-passe da empresa ficam fora do perímetro de segurança, com cópia de segurança nos servidores da Google e acessíveis a partir de qualquer dispositivo em que o colaborador alguma vez tenha iniciado sessão.
2. Os utilizadores privilegiados são o alvo de maior valor. As palavras-passe de administrador guardadas no Google Password Manager representam a concentração de risco mais perigosa. O comprometimento de um só cofre expõe as chaves de plataformas de identidade, infraestrutura cloud, sistemas financeiros e ferramentas de segurança. Uma única conta de administrador comprometida torna-se um ponto de pivô para o movimento lateral em toda a organização.
3. A formação em segurança não abrange esta superfície de ataque. Os programas de sensibilização para a segurança ensinam os utilizadores a reconhecer e-mails de phishing e a proteger códigos OTP. Não os ensinam a reconhecer os pedidos de PIN do gestor de palavras-passe como alvos sensíveis. Os utilizadores veem um pedido de PIN e cumprem: não o encaram como um evento de segurança que deveria suscitar desconfiança.
4. As lacunas de política deixam as credenciais no sítio errado. A maioria das organizações não tem uma política que separe os cofres dos navegadores da gestão de credenciais empresariais. As credenciais partilhadas, as palavras-passe de administrador e as contas break-glass podem ficar guardadas onde for mais conveniente para os colaboradores. Não existe registo de auditoria que mostre onde estas credenciais se encontram ou quem lhes acedeu.
5. Os processos de revisão de dispositivos e sessões são demasiado lentos. Uma inscrição de dispositivo ou um acesso ao cofre suspeitos podem passar despercebidos durante semanas.

O último ponto é mais importante do que parece. A PhishU refere que a Google envia um único e-mail de «novo início de sessão no Windows» quando um novo dispositivo se associa ao domínio de segurança, o mesmo aviso enviado para qualquer novo início de sessão no Chrome. Não é enviada nenhuma notificação push para os dispositivos existentes. Numa operação AiTM em que o atacante capturou também a sessão de e-mail da vítima, esse e-mail pode ser suprimido antes de o utilizador o ver.

O que fazer se o PIN do Google Password Manager tiver sido alvo de phishing

Um evento de VaultJacking suspeito não deve ser tratado como um incidente de uma única palavra-passe. Deve ser tratado como possível exposição do cofre até prova em contrário.

A sequência de triagem seguinte destina-se a equipas de segurança e a particulares. Os nomes de eventos do Google Workspace devem ser verificados na documentação atual do Google Admin antes de criar deteção automatizada.

Os passos 5 e 7 são aqueles em que a maioria das respostas a incidentes falha. Alterar a palavra-passe da conta Google sem efetuar a rotação das credenciais subsequentes que esta protege é como trocar a fechadura de um cofre-forte depois de o conteúdo já ter sido fotografado.

O Passwork oferece visibilidade sobre todas as credenciais, sobre quem lhes acedeu e quando. O acesso baseado em funções mantém as credenciais partilhadas num único local, com um registo de auditoria completo, em vez de dispersas por perfis pessoais de navegador. Descobrir como funciona

Travar a violação: Resposta técnica passo a passo

Quando se suspeita de um evento de VaultJacking, os primeiros 60 minutos determinam até onde se propaga o dano. Estes passos destinam-se a engenheiros de segurança e administradores de TI. Devem ser executados por ordem, pois os passos posteriores dependem das provas preservadas nos anteriores.

1. Forçar o fim de todas as sessões ativas. Aceda a myaccount.google.com/security → «Manage all devices» (gerir todos os dispositivos) → revogue todas as sessões que não consiga confirmar fisicamente. Não delegue esta tarefa no utilizador afetado: faça-o a partir de uma consola de administração, sempre que possível. A revogação de sessões corta o acesso a um atacante que tem acesso ao cofre mas ainda não terminou de extrair as credenciais.
2. Auditar as passkeys registadas antes de revogar mais nada. Aceda a myaccount.google.com/security → «Passkeys and security keys» (passkeys e chaves de segurança). Faça primeiro uma captura de ecrã da lista completa e revogue depois todas as entradas que o utilizador não consiga identificar pelo nome do dispositivo e pela data de registo. Uma passkey registada pelo atacante sobrevive à reposição da palavra-passe e restabelece a persistência. A investigação da PhishU confirma que o processo em segundo plano regista uma passkey do operador como parte do fluxo normal do VaultJacking: a persistência está incorporada por conceção.
3. Extrair o registo de auditoria do Google Workspace. Em admin.google.com → Reports (Relatórios) → Audit (Auditoria) → Login, filtre pela conta do utilizador afetado na janela de 24 horas em torno do evento de phishing reportado. Procure qualquer evento login_type combinado com um IP de origem fora dos intervalos conhecidos da organização. Uma nova inscrição de dispositivo a partir de um IP não reconhecido, poucos minutos após o clique no phishing, é um forte indicador de comprometimento do cofre. Antes de criar consultas automatizadas, verifique os nomes atuais dos campos de eventos do Google Workspace na documentação do Google Admin SDK.
4. Configurar um alerta SIEM para deteção futura. Crie uma regra de correlação de alta prioridade: novo evento de inscrição de dispositivo numa conta Google + IP de origem fora da lista de permissões de IP da empresa + intervalo inferior a 10 minutos desde um clique conhecido em phishing. A maioria das organizações não tem atualmente qualquer deteção para eventos ao nível do cofre: esta regra colmata essa lacuna. O formato de boletins de ameaças da F5 Labs recomenda criar regras de deteção SIEM associadas a indicadores comportamentais específicos, em vez de depender apenas de notificações por e-mail.
5. Efetuar a rotação das credenciais por rigorosa ordem de prioridade. Não faça a rotação em bloco sem registar cada ação: o registo de auditoria é necessário para o relatório do incidente e para as decisões de notificação subsequentes.
   1. Contas de SSO e de fornecedores de identidade
   2. Credenciais de raiz e de administrador das consolas cloud
   3. Tokens de repositórios de código e segredos de pipelines de CI/CD
   4. Credenciais das plataformas financeiras e de processamento salarial
   5. Credenciais de VPN e de acesso remoto
   6. Quaisquer contas break-glass ou contas de serviço partilhadas guardadas no cofre
6. Verificar os serviços de terceiros subsequentes. Reveja os eventos de início de sessão da conta afetada em todos os serviços de terceiros durante as 48 horas seguintes ao evento de phishing. Os atacantes testam normalmente as credenciais guardadas nas horas seguintes ao acesso ao cofre. O DBIR 2026 da Verizon concluiu que o abuso de credenciais surge em 39 % das violações confirmadas: o movimento lateral através de inícios de sessão guardados é o passo seguinte esperado, e não um caso extremo.
7. Passo 7. Preservar as provas forenses antes da remediação completa. Faça capturas de ecrã da lista de dispositivos, exporte o registo de auditoria, registe o URL e a hora do phishing e documente quais as credenciais que estavam no cofre no momento do evento. A revogação destrói a persistência do atacante, mas também destrói algumas provas. Primeiro preservar, depois remediar.

O Passwork oferece à equipa de segurança um registo de auditoria completo de cada evento de acesso a credenciais: quem abriu o quê, quando e a partir de que dispositivo. Quando ocorre um incidente, a cadeia de provas está pronta. Ver como funciona

Como os particulares podem reduzir o risco de VaultJacking

O conselho prático é breve. Resume-se, na sua maior parte, a tratar o PIN do Google Password Manager como se trataria uma palavra-passe mestra, porque, funcionalmente, é uma.

• Não introduza o PIN do Google Password Manager em nenhuma página a que tenha chegado através de uma ligação num e-mail, chat ou anúncio. Aceda diretamente às definições da conta Google através da introdução de myaccount.google.com na barra de endereços.
• Reveja periodicamente os dispositivos com sessão iniciada e as passkeys registadas em myaccount.google.com. Um dispositivo desconhecido ou uma passkey que não reconheça merece ser investigado, e não ignorado. A investigação da PhishU mostra que as passkeys registadas pelo atacante são adicionadas em silêncio, sem notificação para os dispositivos existentes nem pedido push.
• Mantenha separados os perfis de navegador pessoais e profissionais. Se um perfil pessoal for comprometido, as credenciais profissionais não devem estar dentro do raio de impacto. O Secure Sign-in Trends Report de 2025 da Okta concluiu que a adoção de autenticadores resistentes a phishing passou de 8,6 % para 14,0 % num ano, mas a adoção na camada de autenticação não protege um cofre governado por um PIN.
• Evite guardar credenciais de administrador ou privilegiadas muito sensíveis num cofre de navegador de consumo. Essas credenciais exigem capacidade de auditoria e controlos de acesso que os cofres de navegador não oferecem. Continue a utilizar passkeys: continuam a ser mais seguras do que as palavras-passe reutilizáveis na camada de cada site. O problema não são as passkeys. O problema é o que governa o repositório que as guarda.

Evitar o próximo ataque: Lista de verificação de política e governação

O Secure Sign-in Trends Report de 2025 da Okta concluiu que a adoção de autenticadores resistentes a phishing passou de 8,6 % para 14,0 % dos utilizadores num ano, um aumento de 63 %. Esse crescimento é um progresso real. A lacuna de governação é que as organizações estão a adotar passkeys mais depressa do que estão a criar políticas para gerir os cofres que as guardam.

Os passos seguintes são proporcionais à sensibilidade das credenciais envolvidas. Nem todas as organizações precisam de todos os controlos. Todas as organizações que guardam credenciais privilegiadas em cofres de navegador precisam de uma política que aborde especificamente essa situação.

1. Auditar as credenciais privilegiadas que se encontram atualmente em cofres de navegador. Utilize o MDM ou as ferramentas de endpoint para identificar o estado de sincronização dos perfis do Chrome em todos os dispositivos geridos. Se não for possível responder à pergunta «que contas de administrador estão sincronizadas com perfis Google pessoais», essa é a primeira lacuna a colmatar, antes de redigir qualquer política.
2. Redigir uma política que nomeie categorias de credenciais específicas. Proíba o armazenamento de contas break-glass, credenciais de administrador, contas de serviço partilhadas, credenciais de raiz cloud e segredos de CI/CD em qualquer cofre de navegador de consumo. Uma política que refere «dados sensíveis» sem nomear categorias produz uma conformidade inconsistente. Nomeie as categorias. Defina uma data de aplicação.
3. Migrar as credenciais abrangidas antes da data de aplicação. Uma política sem um caminho de migração produz repositórios de credenciais paralelos. Transfira todas as credenciais abrangidas pelo Passo 2 para um gestor de palavras-passe empresarial com controlo de acesso baseado em funções e registo de auditoria completo antes de a política entrar em vigor. O Passwork permite a implementação autoalojada com cifragem AES-256, integração AD/LDAP e registo de auditoria completo, e foi concebido especificamente para esta separação entre credenciais corporativas privilegiadas e a comodidade do navegador pessoal.
4. Impor perfis de navegador geridos e separados para utilização profissional. Evite a mistura de cofres pessoais e profissionais através de políticas MDM e da formação dos utilizadores. Quando um perfil pessoal é comprometido, as credenciais profissionais não devem ficar abrangidas. Trata-se de uma alteração de configuração, e não apenas de uma recomendação.
5. Atualizar a formação de sensibilização para o phishing de modo a incluir os pedidos do cofre. Os programas de sensibilização para a segurança ensinam os utilizadores a reconhecer e-mails de phishing e a proteger códigos OTP. Não ensinam que um pedido de PIN do gestor de palavras-passe acarreta o mesmo risco que uma palavra-passe mestra. Inclua explicitamente no programa de formação os pedidos do cofre, os fluxos de recuperação e os pedidos de PIN. Os utilizadores que compreendem o que o PIN desbloqueia são significativamente mais difíceis de atacar com VaultJacking.
6. Incluir um runbook de exposição do cofre no plano de resposta a incidentes. O runbook deve abranger: revogação de sessões, auditoria da inscrição de dispositivos, revisão de passkeys, rotação de credenciais subsequentes e monitorização de contas de terceiros, como uma única resposta coordenada. Percorra a deteção, a contenção e a rotação. Identifique os passos que a equipa não consegue executar atualmente.
7. Configurar a deteção de novas inscrições de dispositivos em contas privilegiadas. Configure o CASB ou a plataforma de identidade para alertar sobre novas inscrições de dispositivos na conta Google a partir de dispositivos não geridos ou não reconhecidos, para todos os utilizadores com acesso privilegiado.
8. Rever trimestralmente a governação dos perfis de navegador. Os colaboradores mudam de funções, dispositivos e hábitos de credenciais mais depressa do que as revisões anuais conseguem captar. Uma verificação trimestral dos dispositivos geridos com a sincronização do Chrome ativada e do tipo de perfil ativo custa menos do que uma resposta a um incidente de exposição de cofre.

Porque um gestor de palavras-passe empresarial é mais seguro do que um cofre de navegador

Um gestor de palavras-passe de navegador resolve um problema de comodidade pessoal: preenchimento automático, sincronização entre dispositivos, armazenamento sem esforço. Para um utilizador individual, é uma escolha razoável. Num ambiente empresarial, essa mesma simplicidade converte-se numa vulnerabilidade estrutural.

O Passwork é a alternativa empresarial aos cofres de navegador pessoais. A extensão de navegador do Passwork funciona exatamente como um gestor de palavras-passe integrado no navegador: preenche automaticamente os inícios de sessão nos sites e propõe guardar novas credenciais, mas guarda-as num cofre corporativo protegido, em vez de num perfil de navegador pessoal.

O Passwork permite a implementação autoalojada, a cifragem AES-256, a integração com Active Directory e LDAP, a autorização SSO, o controlo de acesso baseado em funções, o registo de auditoria completo, a integração com SIEM e ferramentas de REST API e CLI para fluxos de trabalho DevOps.

A diferença é de arquitetura. Um cofre de navegador privilegia a comodidade individual. Um gestor de palavras-passe empresarial privilegia o controlo e a visibilidade organizacionais. Quando as credenciais privilegiadas acabam num cofre de navegador, escolheu-se a ferramenta errada para a tarefa, não porque a ferramenta seja má, mas porque foi concebida para outro problema.

Conclusão: O que fazer em relação ao VaultJacking

A ameaça descrita pelo VaultJacking é específica: uma técnica de phishing que transforma um único PIN capturado em exposição de credenciais a todo o cofre. A resposta deve ser igualmente específica: não o pânico em relação às passkeys, nem a desvalorização do risco dos cofres de navegador, mas uma política lúcida que separe a comodidade das credenciais pessoais da governação das credenciais privilegiadas.

Comece pela auditoria. Descubra que credenciais privilegiadas se encontram atualmente em cofres de navegador. Que contas de administrador estão sincronizadas com dispositivos pessoais? Que credenciais break-glass estão guardadas no Google Password Manager? Essa resposta indicará quanto trabalho há a fazer.

A partir daí, o caminho é simples: proibir credenciais privilegiadas nos cofres de navegador, transferi-las para um gestor de palavras-passe empresarial com registos de auditoria e controlos de acesso e alargar a formação de sensibilização para a segurança aos pedidos do cofre e aos fluxos de recuperação.

O VaultJacking não é motivo para abandonar os gestores de palavras-passe dos navegadores. É motivo para os utilizar para aquilo para que foram concebidos, as credenciais pessoais, e para criar um sistema separado e auditável para tudo o resto.

O Passwork é um gestor empresarial autoalojado de palavras-passe e segredos, concebido para a governação de credenciais privilegiadas. Disponibiliza acesso baseado em funções, registos de auditoria completos e uma separação total em relação aos cofres de navegador de consumo. Ver como se integra na infraestrutura

Perguntas frequentes

O que é o VaultJacking?

O VaultJacking é uma técnica de phishing que visa o cofre do Google Password Manager ao capturar o PIN do Google Password Manager do utilizador durante uma sessão de phishing adversary-in-the-middle. O PIN capturado é utilizado para inscrever um dispositivo controlado pelo atacante no domínio de segurança Google da vítima, o que permite decifrar todas as palavras-passe e passkeys sincronizadas guardadas no cofre. A técnica foi demonstrada de ponta a ponta pela PhishU em maio de 2026.

O VaultJacking é uma vulnerabilidade da Google?

Com base nas notícias publicadas, o VaultJacking é uma técnica demonstrada de phishing e de abuso de fluxos de trabalho, e não uma vulnerabilidade classificada nos sistemas da Google. Explora a conceção do fluxo de inscrição de dispositivos da Google, nomeadamente a ausência de aprovação entre dispositivos para novas adesões ao domínio de segurança, opção que a Google tomou deliberadamente como compromisso de experiência de utilização para a recuperação em caso de perda de dispositivos. A questão de saber se a Google classifica isto como uma vulnerabilidade que exige correção é distinta e não obteve resposta pública à data da redação.

O VaultJacking quebra as passkeys?

Não. As passkeys baseiam-se em criptografia de chave pública vinculada à origem, tal como definida na especificação W3C WebAuthn. Uma página de phishing não consegue reproduzir uma asserção WebAuthn no site real, porque a vinculação à origem falha. O VaultJacking visa a camada de cofre e de recuperação que guarda as passkeys, e não a própria cerimónia criptográfica de autenticação. As passkeys continuam a ser resistentes a phishing na camada de início de sessão de cada site.

O que é o PIN do Google Password Manager?

O PIN do Google Password Manager é um segredo que protege os dados cifrados do Google Password Manager. De acordo com a documentação da Google, é criado quando o utilizador guarda a primeira passkey num computador, iPhone ou iPad e é utilizado para aceder a passkeys em novos dispositivos, verificar a identidade e garantir que nem a Google consegue ler o conteúdo cifrado do cofre. É distinto da palavra-passe da conta Google e do bloqueio de ecrã do dispositivo.

Um único PIN pode expor todas as palavras-passe guardadas?

A demonstração da PhishU mostra que um PIN de seis dígitos do Google Password Manager capturado pode permitir a um atacante decifrar todo o cofre sincronizado, todas as palavras-passe guardadas e todas as passkeys sincronizadas, a partir de infraestrutura controlada pelo atacante. O PIN liberta o Security Domain Secret, que decifra o cofre numa única operação. Se o PIN foi introduzido numa página a que não se acedeu diretamente, deve ser tratado como possível exposição total do cofre.

O que fazer se o PIN tiver sido introduzido numa página suspeita?

Reveja de imediato os dispositivos com sessão iniciada e as passkeys registadas em myaccount.google.com. Revogue quaisquer dispositivos ou sessões desconhecidos. Altere a palavra-passe da conta Google. Efetue a rotação das credenciais de elevado valor guardadas no cofre, com prioridade para SSO, e-mail, consolas cloud, plataformas financeiras e contas de administrador. Verifique nos serviços de terceiros se existe atividade de início de sessão invulgar. Se pertencer a uma organização, abra um processo de resposta a incidentes em vez de tratar a situação como um problema de uma única conta.

As empresas devem proibir o Google Password Manager?

Uma proibição generalizada não é a política adequada para a maioria das organizações. Uma abordagem baseada no risco funciona melhor: restringir o armazenamento de credenciais privilegiadas e partilhadas a um gestor de palavras-passe empresarial com controlos de auditoria, impor perfis de navegador geridos e separados para utilização profissional e alargar a formação de sensibilização para o phishing aos pedidos do gestor de palavras-passe e aos fluxos de recuperação. O Google Password Manager é adequado para credenciais pessoais; não foi concebido para contas break-glass nem para acesso de administrador partilhado.

As chaves de segurança de hardware são suficientes para travar este ataque?

As chaves de segurança de hardware reforçam a garantia do início de sessão na conta Google, mas não governam automaticamente a sincronização do cofre do navegador, os fluxos de recuperação nem as credenciais guardadas no cofre. O VaultJacking visa a camada de gestão do cofre, e não o passo de início de sessão na conta. Uma chave de hardware na conta Google reduz o risco de tomada de controlo da conta, mas não impede que um utilizador seja induzido a introduzir o PIN do Google Password Manager numa página de phishing.

Gestão de palavras-passe e acessos para PME: O KeePass é suficiente?

A utilizar o KeePass na equipa? Conheça os riscos ocultos do KeePass para PME em 2026: falhas de sincronização, lacunas de conformidade e quando migrar para um gestor de palavras-passe empresarial.

Passwork BlogAlex Muntyan

O Passwork é distinguido como Top Performer Spring 2026 na SourceForge

O Passwork foi distinguido pela SourceForge como Top Performer Spring 2026 e ficou no top 10 % de mais de 100 000 soluções. A distinção baseia-se exclusivamente em avaliações verificadas: 4,8 estrelas no total e 5,0 (pontuação máxima) em suporte.

Passwork BlogAlex Muntyan

Ciclo de vida da rotação de segredos: Da criação à revogação

A rotação de segredos falha quando é tratada como uma tarefa agendada e não como um ciclo de vida. Este guia abrange as sete fases, desde a criação e a atribuição de responsabilidade até à rotação segura, à revogação de emergência e às evidências de auditoria.

Passwork BlogAlex Muntyan

VaultJacking ist eine Phishing-Technik, die auf den Tresor des Google Passwortmanagers abzielt, indem sie die PIN abfängt, die ihn entsperrt. Am 20. Mai 2026 von PhishU demonstriert, zeigt der Angriff, wie ein einziges sechsstelliges Geheimnis — während einer Adversary-in-the-Middle-Phishing-Sitzung (AiTM) abgefangen — einem Angreifer Zugang zu jedem synchronisierten Passwort und Passkey verschaffen kann, den ein Opfer im Google Passwortmanager gespeichert hat.

Für Unternehmen ist das Risiko größer als es erscheint. Der Browser-Tresor eines einzelnen Mitarbeiters kann SSO-Anmeldedaten, Cloud-Konsolen-Zugang, Logins für Finanzplattformen und Code-Repository-Schlüssel enthalten: alles an einem Ort und durch eine einzige abgefangene PIN offengelegt. Dies ist ein organisatorisches Risiko, das außerhalb der meisten bestehenden Incident-Response-Playbooks liegt und außerhalb der Sichtbarkeit der meisten IT- und Sicherheitsteams.

Wichtigste Erkenntnisse

VaultJacking ist relevant, weil Browser-Passwortmanager Passwörter, Passkeys und Wiederherstellungsabläufe in einem einzigen hochwertigen Ziel konzentrieren. Bevor Sie weiterlesen, hier das Wichtigste:

• VaultJacking zielt auf die Tresor-Synchronisierungsebene. Der Angriff bricht nicht die WebAuthn-Kryptographie. Er missbraucht den Geräteregistrierungsablauf, der bestimmt, wer den synchronisierten Tresor lesen kann.
• Die Google-Passwortmanager-PIN ist ein Tresor-Zugangsgeheimnis. Google verwendet die PIN zum Schutz verschlüsselter Anmeldedaten. Behandeln Sie sie entsprechend — nicht als belanglosen Code.
• Eine abgefangene PIN kann den gesamten Tresor offenlegen. Die Demonstration von PhishU zeigt, dass eine einzige PIN-Eingabe einem Angreifer ermöglichen kann, jedes synchronisierte Passwort und jeden Passkey auf einer vom Angreifer kontrollierten Infrastruktur zu entschlüsseln.
• Das Unternehmensrisiko skaliert mit Governance-Lücken. Die Vermischung von persönlichen und beruflichen Profilen, nicht verwaltete Chrome-Profile und privilegierte Anmeldedaten in Browser-Tresoren erhöhen den Schadensradius.
• Die Incident Response muss über einen Passwortwechsel hinausgehen. Ein vermutetes VaultJacking-Ereignis erfordert die Überprüfung von Geräten, Sitzungen, Passkeys, Tresorinhalten und nachgelagerten Logins — nicht nur das Ändern eines Passworts.

Was ist VaultJacking?

VaultJacking ist eine Phishing-Technik, die auf den Tresor-Zugang und die Wiederherstellungserfahrung des Google Passwortmanagers abzielt. Anstatt eine einzelne Website-Anmeldung zu stehlen, fängt der Angreifer die Google-Passwortmanager-PIN während einer AiTM-Phishing-Sitzung ab und verwendet sie, um ein vom Angreifer kontrolliertes Gerät in die Google-Sicherheitsdomäne des Opfers einzuschreiben. Dadurch erhält er Zugang zum gesamten synchronisierten Anmeldedaten-Tresor. Der Begriff und die End-to-End-Demonstration stammen aus der veröffentlichten Forschung von PhishU.

Traditionelles Credential-Phishing zielt auf ein Konto nach dem anderen. VaultJacking ist eine andere Angriffsklasse: Der Angreifer umgeht einzelne Anmeldedaten vollständig und greift direkt auf das Repository zu, das alle enthält.

Die Forschung von PhishU beschreibt den Angriff als vollständig konsistent mit Standard-AiTM-Phishing. Der AiTM-Proxy fängt die PIN zusammen mit Session-Cookies ab. Ein Hintergrundprozess fügt dann einen Passkey des Angreifers zum Google-Konto des Opfers für Persistenz hinzu, tritt der Sicherheitsdomäne von der Angreifer-Infrastruktur aus mit der abgefangenen PIN bei und entschlüsselt den gesamten Tresor. Der Betreiber sieht alle synchronisierten Anmeldedaten in einer einzigen Ansicht.

Browser Syncjacking, eine separate Technik, auf die PhishU verweist, erreicht dieselbe Google-Sync-Ebene über eine bösartige Browser-Erweiterung. VaultJacking erfordert weder einen Geräte-Zugang noch eine Erweiterung.

Was ist die Google-Passwortmanager-PIN?

Die Google-Passwortmanager-PIN ist ein separates Geheimnis, das sich von Ihrem Google-Kontopasswort und Ihrer Geräte-Bildschirmsperre unterscheidet. Googles Dokumentation beschreibt sie als eine Möglichkeit, verschlüsselte Google-Passwortmanager-Daten zu schützen, Passkeys auf einem neuen Gerät zu verwenden und die Identität zu verifizieren.

Benutzer verwechseln häufig drei verschiedene Geheimnisse, und diese Verwirrung ist Teil dessen, was VaultJacking so effektiv macht:

Die Aufforderung zur Eingabe der Google-Passwortmanager-PIN erscheint beim Erstellen Ihres ersten Passkeys auf einem neuen Gerät, beim Zugriff auf verschlüsselte gespeicherte Anmeldedaten in bestimmten Wiederherstellungskontexten oder wenn ein neues Gerät Ihrer Google-Sicherheitsdomäne beitritt. Das letzte Szenario ist genau das, was VaultJacking ausnutzt.

Der strukturelle Grund, warum dies funktioniert, liegt laut der Analyse von PhishU des Chromium-Quellcodes (chrome/browser/webauthn/enclave_manager.cc und components/trusted_vault/) darin, dass Googles Sicherheitsdomänen-Beitrittsablauf zwei Prüfungen erfordert: eine Google-Kontoanmeldung und eine erfolgreiche PIN-Eingabe. Es gibt keine geräteübergreifende Genehmigungsaufforderung, keine Push-Benachrichtigung an bestehende Geräte, keine „Von einem anderen Gerät genehmigen"-Bestätigung.

Apples iCloud-Schlüsselbund erfordert, dass bestehende Geräte neue genehmigen. Googles Modell nicht. Google hat einen bewussten UX-Kompromiss getroffen: Eine PIN mit einem serverseitigen Wiederholungslimit ist einfacher zu handhaben als ein Push-to-Approve-Modell, wenn ein Benutzer alle seine Geräte verloren hat. VaultJacking ist die Konsequenz dieses Kompromisses.

Wie die VaultJacking-Angriffskette funktioniert

Das Folgende beschreibt den Angriff konzeptionell für Verteidigungszwecke. Es sind keine offensiven Implementierungsdetails enthalten.

1. Köder. Das Opfer erhält einen Phishing-Link und landet auf einer Seite, die einen legitimen Google-Anmelde- oder Kontoablauf imitiert. Behandeln Sie jeden unerwarteten Anmeldeablauf, der per E-Mail, Chat oder Werbelink ankommt, mit Misstrauen.
2. Vertrauenstransfer. Der AiTM-Proxy rendert eine PIN-Aufforderung, die dem Stil von Googles eigener Oberfläche entspricht: gleiche Schriftart, gleiche sechs-Zellen-Eingabe, gleicher Text. Die Benutzerschulung muss Passwortmanager-PIN-Aufforderungen abdecken, nicht nur Passwörter und OTP-Codes.
3. PIN-Abfang. Das Opfer gibt die PIN in den Phishing-Ablauf ein. Die PIN ist ein Tresor-Zugangsgeheimnis, das in seiner Sensibilität einem Masterpasswort entspricht.
4. Angreifer-Geräteregistrierung. Der Angreifer verwendet die abgefangene PIN, um der Google-Sicherheitsdomäne des Opfers von einer vom Angreifer kontrollierten Infrastruktur aus beizutreten. Ein Passkey des Angreifers wird ebenfalls für Persistenz registriert. Überprüfen Sie angemeldete Geräte und registrierte Passkeys sofort nach jedem vermuteten Phishing-Kontakt.
5. Tresor-Entschlüsselung. Das Security Domain Secret wird von Googles Cloud-Authenticator freigegeben, und das Gerät des Angreifers entschlüsselt jedes synchronisierte Passwort und jeden Passkey. Der Tresor kann Anmeldedaten für E-Mail, SSO, Cloud-Konsolen, Finanzplattformen und Code-Repositories enthalten.
6. Nachgelagerte Kompromittierung. Gespeicherte Drittanbieter-Anmeldedaten werden gegen andere Dienste verwendet. Rotieren Sie hochwertige Anmeldedaten und überwachen Sie Drittanbieter-Logins.

PhishU hat dies End-to-End gegen Live-Google-Passwortmanager-Konten getestet, einschließlich der Wiedergabe von abgefangenen Drittanbieter-Passkeys, unabhängig davon, ob die ursprünglichen Anmeldedaten hardwaregestützt waren. Behandeln Sie dies als eine demonstrierte Technik. Es gibt zum Zeitpunkt des Schreibens keine öffentlichen Beweise für eine weit verbreitete aktive Ausnutzung, aber die Technik erfordert keinen spezialisierten Zugang oder Geräte-Zugriff.

Bedeutet VaultJacking, dass Passkeys unsicher sind?

Nein. VaultJacking bricht nicht die Passkey-Kryptographie. Passkeys basieren auf ursprungsgebundener Public-Key-Authentifizierung, wie in der W3C WebAuthn-Spezifikation definiert: Der private Schlüssel verlässt niemals das Gerät, und die Authentifizierungszeremonie ist an den legitimen Website-Ursprung gebunden. Eine Phishing-Seite kann eine WebAuthn-Assertion nicht gegen die echte Website wiedergeben, weil die Ursprungsprüfung fehlschlägt. Dieser Schutz bleibt bestehen.

Was VaultJacking demonstriert, ist, dass Passkeys nicht isoliert existieren. Sie existieren in einem Tresor, der über Geräte synchronisiert wird, der auf einem Wiederherstellungsmechanismus basiert, der durch eine PIN gesteuert wird. Der Angreifer umgeht die kryptographische Zeremonie vollständig, indem er stattdessen auf die Tresor-Verwaltungsebene abzielt.

Google beschreibt Passkeys als eine Möglichkeit, sich mit Fingerabdruck, Gesichtserkennung oder Bildschirmsperre anzumelden — einfacher und sicherer als Passwörter. Diese Beschreibung ist auf der Ebene der Einzelsite-Authentifizierung korrekt. Das Problem, das VaultJacking aufzeigt, liegt eine Ebene höher: Was steuert den Zugang zum Speicher, der diese Passkeys enthält.

Warum eine PIN einen großen Schadensradius erzeugen kann

Ein Passwortmanager-Tresor ist ein konzentrierter Speicher für Zugang. Eine abgefangene PIN legt alle Anmeldedaten offen, die das Opfer jemals im Google Passwortmanager gespeichert hat.

Der Identity Threat Landscape Report 2025 von Recorded Future stellte fest, dass das durchschnittliche kompromittierte Gerät 87 gestohlene Anmeldedaten ergab und dass 276 Millionen der 2025 indexierten Anmeldedaten aktive Session-Cookies enthielten — was bedeutet, dass Angreifer MFA für diese Konten vollständig umgehen konnten.

Verizons DBIR 2026 setzt die nachgelagerten Auswirkungen in einen Kontext: Der Missbrauch von Anmeldedaten erscheint irgendwann in 39 % aller bestätigten Sicherheitsverletzungen, über mehr als 22.000 Vorfälle in 145 Ländern hinweg. Angreifer bleiben selten bei der ersten Tür stehen, die gestohlene Anmeldedaten öffnen. Sie bewegen sich lateral, eskalieren Privilegien und arbeiten sich durch jeden gespeicherten Login, bis sie etwas Wertvolles finden.

Wer ist am stärksten gefährdet?

Das Risiko konzentriert sich dort, wo drei Bedingungen zusammentreffen: Browser-Tresor-Daten sind der primäre Anmeldedatenspeicher, Arbeits- und persönliche Anmeldedaten teilen ein Profil, und privilegierte Anmeldedaten sind in einem Consumer-System gelandet.

1. Das Problem der Vermischung von Anmeldedaten. Mitarbeiter speichern Arbeits-Anmeldedaten in persönlichen Chrome-Profilen. Administratoren haben keine Sichtbarkeit oder Kontrolle über Tresorinhalte oder synchronisierte Geräte. Dies bedeutet, dass Unternehmenspasswörter außerhalb des Sicherheitsperimeters leben, auf Googles Servern gesichert werden und von jedem Gerät aus zugänglich sind, bei dem sich der Mitarbeiter jemals angemeldet hat.
2. Privilegierte Benutzer sind das hochwertigste Ziel. Im Google Passwortmanager gespeicherte Admin-Passwörter stellen die gefährlichste Risikokonzentration dar. Eine Tresor-Kompromittierung legt die Schlüssel zu Identitätsplattformen, Cloud-Infrastruktur, Finanzsystemen und Sicherheits-Tools offen. Ein einziges kompromittiertes Admin-Konto wird zum Drehpunkt für laterale Bewegung in der gesamten Organisation.
3. Sicherheitstraining deckt diese Angriffsfläche nicht ab. Security-Awareness-Programme lehren Benutzer, Phishing-E-Mails zu erkennen und OTP-Codes zu schützen. Sie lehren Benutzer nicht, Passwortmanager-PIN-Aufforderungen als sensible Ziele zu erkennen. Benutzer sehen eine PIN-Anfrage und kommen ihr nach — sie sehen es nicht als ein Sicherheitsereignis, das Skepsis auslösen sollte.
4. Richtlinienlücken lassen Anmeldedaten am falschen Ort. Die meisten Organisationen haben keine Richtlinie, die Browser-Tresore von der Unternehmens-Anmeldedatenverwaltung trennt. Geteilte Anmeldedaten, Admin-Passwörter und Break-Glass-Konten werden möglicherweise dort gespeichert, wo es Mitarbeitern bequem erscheint. Es existiert kein Audit-Trail, der zeigt, wo diese Anmeldedaten liegen oder wer darauf zugegriffen hat.
5. Geräte- und Sitzungsüberprüfungsprozesse sind zu langsam. Verdächtige Geräteregistrierungen oder Tresorzugriffe können wochenlang unbemerkt bleiben.

Der letzte Punkt ist wichtiger, als es erscheinen mag. PhishU merkt an, dass Google eine einzige E-Mail „Neue Anmeldung unter Windows" sendet, wenn ein neues Gerät der Sicherheitsdomäne beitritt — dieselbe Benachrichtigung, die für jede neue Chrome-Anmeldung gesendet wird. Auf bestehenden Geräten wird keine Push-Benachrichtigung ausgelöst. In einem AiTM-Angriff, bei dem der Angreifer auch die Posteingangs-Sitzung des Opfers abgefangen hat, kann diese E-Mail unterdrückt werden, bevor der Benutzer sie sieht.

Was zu tun ist, wenn eine Google-Passwortmanager-PIN möglicherweise gephisht wurde

Behandeln Sie ein vermutetes VaultJacking-Ereignis nicht als Einzelpasswort-Vorfall. Behandeln Sie es als mögliche Tresor-Exposition, bis das Gegenteil bewiesen ist.

Die folgende Triage-Sequenz richtet sich an Sicherheitsteams und Einzelpersonen. Google-Workspace-Ereignisnamen sollten anhand der aktuellen Google-Admin-Dokumentation überprüft werden, bevor eine automatisierte Erkennung erstellt wird.

Die Schritte 5 und 7 sind dort, wo die meisten Incident Responses zu kurz greifen. Das Google-Kontopasswort zu rotieren, ohne die nachgelagerten Anmeldedaten zu rotieren, die es schützt, ist wie das Schloss an einem Safe zu wechseln, nachdem der Inhalt bereits fotografiert wurde.

Passwork gibt Ihnen Einblick in alle Anmeldedaten, wer darauf zugegriffen hat und wann. Rollenbasierter Zugriff bedeutet, dass geteilte Anmeldedaten an einem Ort mit vollständigem Audit-Trail bleiben — nicht über persönliche Browser-Profile verstreut. Erfahren Sie, wie es funktioniert

Wie Einzelpersonen das VaultJacking-Risiko reduzieren können

Der praktische Rat hier ist kurz. Das meiste läuft darauf hinaus, die Google-Passwortmanager-PIN genauso zu behandeln wie ein Masterpasswort.

• Geben Sie die Google-Passwortmanager-PIN nicht auf einer Seite ein, die Sie durch Klicken auf einen Link in einer E-Mail, einem Chat oder einer Werbung erreicht haben. Navigieren Sie direkt zu den Google-Kontoeinstellungen.
• Überprüfen Sie Ihre angemeldeten Geräte und registrierten Passkeys unter myaccount.google.com regelmäßig. Ein unbekanntes Gerät oder ein unbekannter Passkey ist eine Untersuchung wert.
• Halten Sie persönliche und berufliche Browser-Profile getrennt. Wenn ein persönliches Profil kompromittiert wird, sollten Arbeits-Anmeldedaten nicht im Schadensradius sein.
• Vermeiden Sie das Speichern hochsensibler Admin- oder privilegierter Anmeldedaten in einem Consumer-Browser-Tresor. Diese Anmeldedaten benötigen Auditierbarkeit und Zugriffskontrollen, die Browser-Tresore nicht bieten.
• Verwenden Sie weiterhin Passkeys. Sie bleiben auf der Einzelsite-Ebene sicherer als wiederverwendbare Passwörter. Verstehen Sie nur, welche Aufforderungen legitim sind und welche nicht.

Unternehmenskontrollen und Richtlinienempfehlungen

Oktas Secure Sign-in Trends Report 2025 stellte fest, dass die Einführung von phishing-resistenten Authentifikatoren in einem Jahr von 8,6 % auf 14,0 % der Benutzer wuchs — ein Anstieg von 63 %. Dieses Wachstum ist eine gute Nachricht. Das Governance-Problem ist, dass Organisationen Passkeys schneller einführen, als sie die Richtlinien zur Verwaltung der Tresore aufbauen, die sie speichern.

Die folgenden Kontrollen sind proportional zur Sensibilität der beteiligten Anmeldedaten. Nicht jede Organisation benötigt jede Kontrolle, aber jede Organisation, die privilegierte Anmeldedaten in Browser-Tresoren speichert, benötigt eine Richtlinie, die dies speziell adressiert.

• Browser-Profil-Governance. Erzwingen Sie separate verwaltete Arbeitsprofile. Entmutigen Sie die Vermischung von persönlichen und Arbeits-Tresoren durch Richtlinien und Benutzerschulung.
• Speicherung privilegierter Anmeldedaten. Verbieten Sie das Speichern von Admin-, Break-Glass-, Cloud-Root-, Finanz- und Service-Account-Anmeldedaten in nicht verwalteten Browser-Tresoren. Browser-Tresore sind bequem für die persönliche Nutzung. Sie sind nicht für geteilte Anmeldedaten, privilegierten Zugang oder Audit-Trails konzipiert.
• Enterprise-Passwort-Management. Verwenden Sie einen dedizierten Enterprise-Passwortmanager für geteilte, privilegierte und auditierte Anmeldedaten. Passwork ist eine selbst gehostete Lösung, die genau für diese Trennung entwickelt wurde: privilegierte Anmeldedaten in einem kontrollierten, auditierbaren Tresor mit rollenbasierter Zugriffskontrolle, AD/LDAP-Integration und vollständigem Audit-Log.
• Phishing-resistente MFA. Setzen Sie die Einführung von WebAuthn und FIDO2 fort. Erweitern Sie die Benutzerschulung auf Wiederherstellungsabläufe und Tresor-Aufforderungen, nicht nur auf Passwörter und OTP-Codes.
• Geräte- und Sitzungssichtbarkeit. Überwachen Sie auf unbekannte Geräteregistrierungen, ungewöhnliche Sitzungsaktivitäten und unerwartete Kontosicherheitsänderungen. Google sendet eine „Neue Anmeldung"-E-Mail für jede neue Chrome-Anmeldung. In einem AiTM-Angriff, bei dem der Angreifer auch die Posteingangs-Sitzung des Opfers abgefangen hat, kann diese E-Mail unterdrückt werden, bevor der Benutzer sie sieht.
• Incident Response. Erstellen Sie ein Tresor-Expositions-Runbook, das Anmeldedaten-Rotation, Sitzungswiderruf, Passkey-Überprüfung und Drittanbieter-Kontoüberwachung umfasst.
• Security Awareness. Schulen Sie Benutzer, dass PINs, Passwortmanager-Aufforderungen und Wiederherstellungsabläufe Phishing-Ziele sind. Sie tragen dasselbe Risiko wie Passwörter und OTP-Codes.

Der Punkt zum Enterprise-Passwortmanager verdient Betonung. Browser-Tresore sind bequem und verbessern die Passwort-Einzigartigkeit für viele Benutzer. Sie sind nicht für geteilte Anmeldedaten, privilegierten Zugang oder Audit-Trails konzipiert.

Warum ein Enterprise-Passwortmanager sicherer ist als ein Browser-Tresor für Arbeits-Anmeldedaten

Ein Browser-Passwortmanager löst ein persönliches Komfortproblem: Autofill, Gerätesynchronisation, mühelose Speicherung. Für einen einzelnen Benutzer ist das eine vernünftige Wahl. Für eine Unternehmensumgebung wird dieselbe Einfachheit zu einer strukturellen Schwachstelle.

Passwork ist die Enterprise-Alternative zu persönlichen Browser-Tresoren. Die Passwork-Browser-Erweiterung funktioniert genau wie ein integrierter Browser-Passwortmanager — sie füllt Logins auf Websites automatisch aus, bietet an, neue Anmeldedaten zu speichern — speichert sie aber in einem geschützten Unternehmens-Tresor anstatt in einem persönlichen Browser-Profil.

Passwork unterstützt selbst gehostete Bereitstellung, AES-256-Verschlüsselung, Active Directory- und LDAP-Integration, SSO-Autorisierung, rollenbasierte Zugriffskontrolle, vollständiges Audit-Logging, SIEM-Integration sowie REST API- und CLI-Tools für DevOps-Workflows.

Der Unterschied ist architektonisch. Ein Browser-Tresor priorisiert individuellen Komfort. Ein Enterprise-Passwortmanager priorisiert organisatorische Kontrolle und Sichtbarkeit. Wenn privilegierte Anmeldedaten in einem Browser-Tresor landen, wurde das falsche Werkzeug für die Aufgabe gewählt — nicht weil das Werkzeug schlecht ist, sondern weil es für ein anderes Problem konzipiert wurde.

Fazit: Was gegen VaultJacking zu tun ist

Die Bedrohung, die VaultJacking beschreibt, ist spezifisch: eine Phishing-Technik, die eine abgefangene PIN in tresorweite Anmeldedaten-Exposition verwandelt. Die Reaktion sollte ebenso spezifisch sein — keine Panik über Passkeys und keine Verharmlosung des Browser-Tresor-Risikos, sondern eine klare Richtlinie, die persönlichen Anmeldedaten-Komfort von privilegierter Anmeldedaten-Governance trennt.

Beginnen Sie mit dem Audit. Finden Sie heraus, welche privilegierten Anmeldedaten derzeit in Browser-Tresoren liegen. Welche Admin-Konten sind mit persönlichen Geräten synchronisiert? Welche Break-Glass-Anmeldedaten sind im Google Passwortmanager gespeichert? Diese Antwort wird Ihnen sagen, wie viel Arbeit noch zu tun ist.

Von dort aus ist der Weg klar: Verbieten Sie privilegierte Anmeldedaten in Browser-Tresoren, verschieben Sie sie in einen Enterprise-Passwortmanager mit Audit-Trails und Zugriffskontrollen, und erweitern Sie Ihr Security-Awareness-Training auf Tresor-Aufforderungen und Wiederherstellungsabläufe.

VaultJacking ist kein Grund, Browser-Passwortmanager aufzugeben. Es ist ein Grund, sie für das zu verwenden, wofür sie konzipiert wurden — persönliche Anmeldedaten — und ein separates, auditierbares System für alles andere aufzubauen.

Passwork ist ein selbst gehosteter Enterprise-Passwort- und Secrets-Manager, der für privilegierte Anmeldedaten-Governance entwickelt wurde. Er bietet rollenbasierten Zugriff, vollständige Audit-Logs und vollständige Trennung von Consumer-Browser-Tresoren. Erfahren Sie, wie er in Ihre Infrastruktur passt

Häufig gestellte Fragen

Was ist VaultJacking?

VaultJacking ist eine Phishing-Technik, die auf den Tresor des Google Passwortmanagers abzielt, indem sie die Google-Passwortmanager-PIN des Benutzers während einer Adversary-in-the-Middle-Phishing-Sitzung abfängt. Die abgefangene PIN wird verwendet, um ein vom Angreifer kontrolliertes Gerät in die Google-Sicherheitsdomäne des Opfers einzuschreiben, wodurch jedes synchronisierte Passwort und jeder Passkey im Tresor entschlüsselt wird. Die Technik wurde im Mai 2026 End-to-End von PhishU demonstriert.

Ist VaultJacking eine Google-Schwachstelle?

Basierend auf veröffentlichten Berichten ist VaultJacking eine demonstrierte Phishing- und Workflow-Missbrauchstechnik, keine klassifizierte Schwachstelle in Googles Systemen. Sie nutzt das Design von Googles Geräteregistrierungsablauf aus — insbesondere das Fehlen einer geräteübergreifenden Genehmigung für neue Sicherheitsdomänen-Beitritte — was Google bewusst als UX-Kompromiss für die Wiederherstellung bei verlorenem Gerät gewählt hat. Ob Google dies als Schwachstelle klassifiziert, die eine Behebung erfordert, ist eine separate Frage, die zum Zeitpunkt des Schreibens nicht öffentlich beantwortet wurde.

Bricht VaultJacking Passkeys?

Nein. Passkeys basieren auf ursprungsgebundener Public-Key-Kryptographie, wie in der W3C WebAuthn-Spezifikation definiert. Eine Phishing-Seite kann eine WebAuthn-Assertion nicht gegen die echte Website wiedergeben, weil die Ursprungsbindung fehlschlägt. VaultJacking zielt auf den Tresor und die Wiederherstellungsebene ab, die Passkeys speichert — nicht auf die kryptographische Authentifizierungszeremonie selbst. Passkeys bleiben auf der Einzelsite-Login-Ebene phishing-resistent.

Was ist die Google-Passwortmanager-PIN?

Die Google-Passwortmanager-PIN ist ein Geheimnis, das verschlüsselte Google-Passwortmanager-Daten schützt. Laut Googles Dokumentation wird sie erstellt, wenn ein Benutzer seinen ersten Passkey auf einem Computer, iPhone oder iPad speichert, und sie wird verwendet, um auf Passkeys auf neuen Geräten zuzugreifen, die Identität zu verifizieren und sicherzustellen, dass nicht einmal Google den verschlüsselten Tresorinhalt lesen kann. Sie unterscheidet sich vom Google-Kontopasswort und von der Geräte-Bildschirmsperre.

Kann eine PIN alle meine gespeicherten Passwörter offenlegen?

Die Demonstration von PhishU zeigt, dass eine abgefangene sechsstellige Google-Passwortmanager-PIN einem Angreifer ermöglichen kann, den gesamten synchronisierten Tresor zu entschlüsseln — jedes gespeicherte Passwort und jeden synchronisierten Passkey — von einer vom Angreifer kontrollierten Infrastruktur aus. Die PIN gibt das Security Domain Secret frei, das den Tresor in einer einzigen Operation entschlüsselt. Wenn Sie die PIN auf einer Seite eingegeben haben, zu der Sie nicht direkt navigiert sind, behandeln Sie dies als mögliche vollständige Tresor-Exposition.

Was sollte ich tun, wenn ich die PIN auf einer verdächtigen Seite eingegeben habe?

Überprüfen Sie sofort Ihre angemeldeten Geräte und registrierten Passkeys unter myaccount.google.com. Widerrufen Sie alle unbekannten Geräte oder Sitzungen. Ändern Sie Ihr Google-Kontopasswort. Rotieren Sie hochwertige Anmeldedaten, die im Tresor gespeichert sind — priorisieren Sie SSO, E-Mail, Cloud-Konsolen, Finanzplattformen und Admin-Konten. Überprüfen Sie Drittanbieterdienste auf ungewöhnliche Login-Aktivitäten. Wenn Sie in einer Organisation sind, eröffnen Sie einen Incident-Response-Fall, anstatt dies als Einzelkonto-Problem zu behandeln.

Sollten Unternehmen den Google Passwortmanager verbieten?

Ein pauschales Verbot ist für die meisten Organisationen nicht die richtige Richtlinie. Ein risikobasierter Ansatz funktioniert besser: Beschränken Sie die Speicherung privilegierter und geteilter Anmeldedaten auf einen Enterprise-Passwortmanager mit Audit-Kontrollen, erzwingen Sie separate verwaltete Browser-Profile für die Arbeit und erweitern Sie das Phishing-Awareness-Training auf Passwortmanager-Aufforderungen und Wiederherstellungsabläufe. Der Google Passwortmanager ist für persönliche Anmeldedaten geeignet; er ist nicht für Break-Glass-Konten oder geteilten Admin-Zugang konzipiert.

Reichen Hardware-Sicherheitsschlüssel aus, um dies zu stoppen?

Hardware-Sicherheitsschlüssel stärken die Sicherheitsgarantie bei der Google-Kontoanmeldung, aber sie steuern nicht automatisch die Browser-Tresor-Synchronisation, Wiederherstellungsabläufe oder die im Tresor gespeicherten Anmeldedaten. VaultJacking zielt auf die Tresor-Verwaltungsebene ab, nicht auf den Kontoanmeldeschritt. Ein Hardware-Schlüssel für das Google-Konto reduziert das Risiko einer Kontoübernahme, verhindert aber nicht, dass ein Benutzer dazu verleitet wird, seine Google-Passwortmanager-PIN auf einer Phishing-Seite einzugeben.

Passwort- und Zugangsverwaltung für KMUs: Reicht KeePass aus?

Verwenden Sie KeePass für Ihr Team? Entdecken Sie die versteckten Risiken von KeePass für KMUs im Jahr 2026 — Synchronisierungsfehler, Compliance-Lücken und wann Sie zu einem Unternehmens-Passwortmanager wechseln sollten.

Passwork BlogAlex Muntyan

Passwork gewinnt Top Performer Frühling 2026 auf SourceForge

Passwork wurde von SourceForge als Top Performer Frühling 2026 ausgezeichnet und gehört zu den besten 10 % von über 100.000 Lösungen. Die Auszeichnung basiert ausschließlich auf verifizierten Bewertungen — 4,8 Sterne insgesamt, mit einer perfekten 5,0 für Support.

Passwork BlogAlex Muntyan

Secrets-Rotations-Lebenszyklus: Von der Erstellung bis zum Widerruf

Secret-Rotation scheitert, wenn sie als geplante Aufgabe statt als Lebenszyklus behandelt wird. Dieser Leitfaden behandelt alle sieben Phasen — von Erstellung und Besitz bis hin zu sicherer Rotation, Notfall-Widerruf und Audit-Nachweisen.

Passwork BlogAlex Muntyan

VaultJacking es una técnica de phishing que ataca la bóveda de Google Password Manager capturando el PIN que la desbloquea. Demostrada por PhishU el 20 de mayo de 2026, el ataque muestra cómo un único secreto de seis dígitos, capturado durante una sesión de phishing adversary-in-the-middle (AiTM), puede dar a un atacante acceso a cada contraseña y passkey sincronizada que la víctima haya almacenado en Google Password Manager.

Para las empresas, los riesgos son mayores de lo que parecen. La bóveda del navegador de un solo empleado puede contener credenciales SSO, acceso a consolas en la nube, inicios de sesión de plataformas financieras y claves de repositorios de código: todo en un solo lugar y expuesto por un único PIN capturado. Es un riesgo organizacional que queda fuera de la mayoría de los manuales de respuesta a incidentes existentes, y fuera de la visibilidad de la mayoría de los equipos de TI y seguridad.

Puntos clave

VaultJacking importa porque los gestores de contraseñas del navegador concentran contraseñas, passkeys y flujos de recuperación en un único objetivo de alto valor. Antes de continuar leyendo, esto es lo que necesita saber.

• VaultJacking ataca la capa de sincronización de la bóveda. El ataque no rompe la criptografía WebAuthn. Abusa del flujo de inscripción de dispositivos que gobierna quién puede leer la bóveda sincronizada.
• El PIN de Google Password Manager es un secreto de acceso a la bóveda. Google utiliza el PIN para proteger los datos de credenciales cifrados. Trátelo en consecuencia, no como un código desechable.
• Un único PIN capturado puede exponer toda la bóveda. La demostración de PhishU muestra que una única entrada de PIN puede permitir a un atacante descifrar cada contraseña y passkey sincronizada en infraestructura controlada por el operador.
• El riesgo empresarial escala con las brechas de gobernanza. La mezcla de perfiles personales y laborales, los perfiles de Chrome no gestionados y las credenciales privilegiadas almacenadas en bóvedas del navegador aumentan el radio de impacto.
• La respuesta a incidentes debe ir más allá de un restablecimiento de contraseña. Un evento sospechoso de VaultJacking requiere revisar dispositivos, sesiones, passkeys, contenidos de la bóveda e inicios de sesión posteriores, no solo cambiar una contraseña.

¿Qué es VaultJacking?

VaultJacking es una técnica de phishing que ataca la experiencia de acceso y recuperación de la bóveda de Google Password Manager. En lugar de robar una credencial de un sitio, el atacante captura el PIN de Google Password Manager durante una sesión de phishing AiTM y lo utiliza para inscribir un dispositivo controlado por el atacante en el dominio de seguridad de Google de la víctima, obteniendo acceso a toda la bóveda de credenciales sincronizadas. El término y la demostración completa se originan en la investigación publicada por PhishU.

El phishing tradicional de credenciales ataca una cuenta a la vez. VaultJacking es una clase diferente de ataque: el atacante evita las credenciales individuales por completo y va directamente al repositorio que las contiene todas.

La investigación de PhishU describe el ataque como totalmente consistente con el phishing AiTM estándar. El proxy AiTM captura el PIN junto con las cookies de sesión. Un proceso en segundo plano añade entonces una passkey propiedad del atacante a la cuenta de Google de la víctima para persistencia, se une al dominio de seguridad desde la infraestructura del atacante usando el PIN capturado, y descifra toda la bóveda. El operador ve cada credencial sincronizada en una sola vista.

Browser Syncjacking, una técnica separada que PhishU referencia, alcanza la misma capa de sincronización de Google mediante una extensión de navegador maliciosa. VaultJacking no requiere ni un punto de apoyo en el dispositivo ni una extensión.

¿Qué es el PIN de Google Password Manager?

El PIN de Google Password Manager es un secreto separado de la contraseña de su cuenta de Google y del bloqueo de pantalla de su dispositivo. La documentación de Google lo describe como una forma de proteger los datos cifrados de Google Password Manager, usar passkeys en un nuevo dispositivo y verificar la identidad.

Los usuarios frecuentemente confunden tres secretos diferentes, y esa confusión es parte de lo que hace efectivo a VaultJacking:

Verá el aviso del PIN de Google Password Manager al crear su primera passkey en un nuevo dispositivo, al acceder a credenciales guardadas cifradas en ciertos contextos de recuperación, o cuando un nuevo dispositivo se une a su dominio de seguridad de Google. Este último escenario es exactamente lo que VaultJacking explota.

La razón estructural por la que esto funciona, según el análisis de PhishU del código fuente de Chromium (chrome/browser/webauthn/enclave_manager.cc y components/trusted_vault/), es que el flujo de unión al dominio de seguridad de Google requiere dos verificaciones: un inicio de sesión en la cuenta de Google y una entrada exitosa del PIN. No hay aviso de aprobación entre dispositivos, ni notificación push a los dispositivos existentes, ni confirmación de «aprobar desde otro dispositivo».

El Llavero de iCloud de Apple requiere que los dispositivos existentes aprueben los nuevos. El modelo de Google no lo hace. Google hizo una elección deliberada de experiencia de usuario: un PIN con un límite de reintentos del lado del servidor es más fácil de recuperar que un modelo de aprobación por push cuando un usuario ha perdido todos sus dispositivos. VaultJacking es la consecuencia de esa decisión.

Cómo funciona la cadena de ataque de VaultJacking

Lo siguiente describe el ataque conceptualmente con fines defensivos. No se incluyen detalles de implementación ofensiva.

1. Señuelo. La víctima recibe un enlace de phishing y llega a una página que imita un flujo legítimo de inicio de sesión o cuenta de Google. Trate cualquier flujo de inicio de sesión inesperado que llegue por correo electrónico, chat o enlace de anuncio con sospecha.
2. Transferencia de confianza. El proxy AiTM presenta un aviso de PIN con el mismo estilo que la propia interfaz de Google: misma fuente, misma entrada de seis celdas, mismo texto. La educación del usuario debe cubrir los avisos de PIN del gestor de contraseñas, no solo las contraseñas y los códigos OTP.
3. Captura del PIN. La víctima introduce el PIN en el flujo de phishing. El PIN es un secreto de acceso a la bóveda, equivalente en sensibilidad a una contraseña maestra.
4. Inscripción del dispositivo del atacante. El atacante utiliza el PIN capturado para unirse al dominio de seguridad de Google de la víctima desde infraestructura controlada por el atacante. También se registra una passkey propiedad del atacante para persistencia. Revise los dispositivos conectados y las passkeys registradas inmediatamente después de cualquier contacto sospechoso de phishing.
5. Descifrado de la bóveda. El Security Domain Secret es liberado por el autenticador en la nube de Google, y el dispositivo del atacante descifra cada contraseña y passkey sincronizada. La bóveda puede contener credenciales para correo electrónico, SSO, consolas en la nube, plataformas financieras y repositorios de código.
6. Compromiso posterior. Las credenciales de terceros guardadas se utilizan contra otros servicios. Rote las credenciales de alto valor y monitorice los inicios de sesión de terceros.

PhishU probó esto de extremo a extremo contra cuentas reales de Google Password Manager, incluyendo la reproducción de passkeys de terceros capturadas independientemente de si la credencial original estaba respaldada por hardware. Trate esto como una técnica demostrada. No hay evidencia pública de explotación activa generalizada en el momento de escribir esto, pero la técnica no requiere acceso especializado ni punto de apoyo en el dispositivo.

¿VaultJacking significa que las passkeys están rotas?

No. VaultJacking no rompe la criptografía de las passkeys. Las passkeys se basan en autenticación de clave pública vinculada al origen según se define en la especificación W3C WebAuthn: la clave privada nunca sale del dispositivo, y la ceremonia de autenticación está vinculada al origen del sitio legítimo. Una página de phishing no puede reproducir una aserción WebAuthn contra el sitio real porque la verificación de origen falla. Esa protección se mantiene.

Lo que demuestra VaultJacking es que las passkeys no existen de forma aislada. Existen dentro de una bóveda, que se sincroniza entre dispositivos, que depende de un mecanismo de recuperación, que está gobernado por un PIN. El atacante evita la ceremonia criptográfica por completo al atacar la capa de gestión de la bóveda en su lugar.

Google describe las passkeys como una forma de iniciar sesión con huella dactilar, escaneo facial o bloqueo de pantalla — más simple y más seguro que las contraseñas. Esa descripción es precisa en la capa de autenticación por sitio. El problema que VaultJacking expone está un nivel más arriba: qué gobierna el acceso al almacén que contiene esas passkeys.

Por qué un único PIN puede crear un gran radio de impacto

Una bóveda de gestor de contraseñas es un almacén concentrado de accesos. Un único PIN capturado expone cada credencial que la víctima haya guardado en Google Password Manager.

El Informe del Panorama de Amenazas de Identidad 2025 de Recorded Future encontró que el dispositivo comprometido promedio proporcionaba 87 credenciales robadas, y que 276 millones de las credenciales indexadas en 2025 incluían cookies de sesión activas — lo que significa que los atacantes podían eludir completamente el MFA para esas cuentas.

El DBIR 2026 de Verizon pone el efecto posterior en contexto: el abuso de credenciales aparece en algún momento en el 39% de todas las brechas confirmadas, en más de 22.000 incidentes en 145 países. Los atacantes rara vez se detienen en la primera puerta que abre una credencial robada. Se mueven lateralmente, escalan privilegios y trabajan a través de cada inicio de sesión guardado hasta que encuentran algo valioso.

¿Quién está en mayor riesgo?

El riesgo se concentra donde se superponen tres condiciones: los datos de la bóveda del navegador son el almacén principal de credenciales, las credenciales de trabajo y personales comparten un perfil, y las credenciales privilegiadas han terminado en un sistema de nivel consumidor.

1. El problema de mezcla de credenciales. Los empleados guardan credenciales de trabajo en perfiles personales de Chrome. Los administradores no tienen visibilidad ni control sobre el contenido de la bóveda o los dispositivos sincronizados. Esto significa que las contraseñas corporativas viven fuera del perímetro de seguridad, respaldadas en los servidores de Google, y accesibles desde cualquier dispositivo en el que el empleado haya iniciado sesión.
2. Los usuarios privilegiados son el objetivo de mayor valor. Las contraseñas de administrador almacenadas en Google Password Manager representan la concentración de riesgo más peligrosa. Un compromiso de bóveda expone las llaves a plataformas de identidad, infraestructura en la nube, sistemas financieros y herramientas de seguridad. Una única cuenta de administrador comprometida se convierte en un punto de pivote para el movimiento lateral a través de toda la organización.
3. La formación en seguridad no cubre esta superficie de ataque. Los programas de concienciación de seguridad enseñan a los usuarios a reconocer correos de phishing y proteger códigos OTP. No enseñan a los usuarios a reconocer los avisos de PIN del gestor de contraseñas como objetivos sensibles. Los usuarios ven una solicitud de PIN y cumplen — no lo ven como un evento de seguridad que debería activar el escepticismo.
4. Las brechas de políticas dejan las credenciales en el lugar equivocado. La mayoría de las organizaciones no tienen una política que separe las bóvedas del navegador de la gestión de credenciales empresariales. Las credenciales compartidas, contraseñas de administrador y cuentas de emergencia pueden almacenarse donde los empleados encuentren conveniente. No existe un registro de auditoría que muestre dónde viven estas credenciales o quién las ha accedido.
5. Los procesos de revisión de dispositivos y sesiones son demasiado lentos. La inscripción sospechosa de dispositivos o el acceso a la bóveda puede pasar desapercibido durante semanas.

El último punto importa más de lo que podría parecer. PhishU señala que Google envía un único correo electrónico de «nuevo inicio de sesión en Windows» cuando un nuevo dispositivo se une al dominio de seguridad — la misma notificación enviada para cualquier nuevo inicio de sesión en Chrome. No se dispara ninguna notificación push en los dispositivos existentes. En un compromiso AiTM donde el atacante también ha capturado la sesión del buzón de la víctima, ese correo puede ser suprimido antes de que el usuario lo vea.

Qué hacer si un PIN de Google Password Manager puede haber sido phisheado

No trate un evento sospechoso de VaultJacking como un incidente de una sola contraseña. Trátelo como posible exposición de la bóveda hasta que se demuestre lo contrario.

La siguiente secuencia de triaje es para equipos de seguridad e individuos. Los nombres de eventos de Google Workspace deben verificarse contra la documentación actual del Administrador de Google antes de construir detección automatizada.

Los pasos 5 y 7 son donde la mayoría de las respuestas a incidentes fallan. Rotar la contraseña de la cuenta de Google sin rotar las credenciales posteriores que protege es como cambiar la cerradura de una caja fuerte después de que el contenido ya haya sido fotografiado.

Passwork le proporciona visibilidad de cada credencial, quién accedió a ella y cuándo. El control de acceso basado en roles significa que las credenciales compartidas permanecen en un solo lugar con un registro de auditoría completo — no dispersas en perfiles de navegador personales. Explore cómo funciona

Cómo los individuos pueden reducir el riesgo de VaultJacking

El consejo práctico aquí es breve. La mayor parte se reduce a tratar el PIN de Google Password Manager de la misma manera que trataría una contraseña maestra.

• No introduzca el PIN de Google Password Manager en ninguna página a la que haya llegado haciendo clic en un enlace de correo electrónico, chat o anuncio. Navegue directamente a la configuración de la cuenta de Google.
• Revise sus dispositivos conectados y passkeys registradas en myaccount.google.com periódicamente. Un dispositivo o passkey desconocido vale la pena investigar.
• Mantenga los perfiles de navegador personales y de trabajo separados. Si un perfil personal se ve comprometido, las credenciales de trabajo no deberían estar en el radio de impacto.
• Evite guardar credenciales de administrador o privilegiadas altamente sensibles en una bóveda de navegador de consumidor. Esas credenciales necesitan auditabilidad y controles de acceso que las bóvedas del navegador no proporcionan.
• Continúe usando passkeys. Siguen siendo más seguras que las contraseñas reutilizables en la capa por sitio. Solo comprenda qué avisos son legítimos y cuáles no.

Controles empresariales y recomendaciones de políticas

El Informe de Tendencias de Inicio de Sesión Seguro 2025 de Okta encontró que la adopción de autenticadores resistentes al phishing creció del 8,6% al 14,0% de usuarios en un año — un aumento del 63%. Ese crecimiento es una buena noticia. El problema de gobernanza es que las organizaciones están adoptando passkeys más rápido de lo que están construyendo las políticas para gestionar las bóvedas que las almacenan.

Los siguientes controles son proporcionales a la sensibilidad de las credenciales involucradas. No todas las organizaciones necesitan todos los controles, pero toda organización que almacene credenciales privilegiadas en bóvedas del navegador necesita una política que aborde eso específicamente.

• Gobernanza del perfil del navegador. Imponga perfiles de trabajo gestionados separados. Desaconseje la mezcla de bóvedas personales y de trabajo a través de políticas y educación del usuario.
• Almacenamiento de credenciales privilegiadas. Prohíba almacenar credenciales de administrador, emergencia, root de nube, finanzas y cuentas de servicio en bóvedas de navegador no gestionadas. Las bóvedas del navegador son convenientes para uso personal. No están diseñadas para credenciales compartidas, acceso privilegiado o registros de auditoría.
• Gestión empresarial de contraseñas. Use un gestor de contraseñas empresarial dedicado para credenciales compartidas, privilegiadas y auditadas. Passwork es una solución autoalojada construida exactamente para esta separación: credenciales privilegiadas en una bóveda controlada y auditable con control de acceso basado en roles, integración AD/LDAP y registro de auditoría completo.
• MFA resistente al phishing. Continúe adoptando WebAuthn y FIDO2. Extienda la educación del usuario para cubrir flujos de recuperación y avisos de bóveda, no solo contraseñas y códigos OTP.
• Visibilidad de dispositivos y sesiones. Monitorice inscripciones de dispositivos desconocidos, actividad de sesión inusual y cambios inesperados en la seguridad de la cuenta. Google envía un correo de «nuevo inicio de sesión» para cualquier nuevo inicio de sesión en Chrome. En un compromiso AiTM donde el atacante también ha capturado la sesión del buzón de la víctima, ese correo puede ser suprimido antes de que el usuario lo vea.
• Respuesta a incidentes. Construya un manual de exposición de bóveda que incluya rotación de credenciales, revocación de sesiones, revisión de passkeys y monitorización de cuentas de terceros.
• Concienciación de seguridad. Capacite a los usuarios de que los PINs, avisos del gestor de contraseñas y flujos de recuperación son objetivos de phishing. Conllevan el mismo riesgo que las contraseñas y los códigos OTP.

El punto sobre el gestor de contraseñas empresarial merece énfasis. Las bóvedas del navegador son convenientes y mejoran la unicidad de las contraseñas para muchos usuarios. No están diseñadas para credenciales compartidas, acceso privilegiado o registros de auditoría.

Por qué un gestor de contraseñas empresarial es más seguro que una bóveda del navegador para credenciales de trabajo

Un gestor de contraseñas del navegador resuelve un problema de conveniencia personal: autocompletado, sincronización entre dispositivos, almacenamiento sin esfuerzo. Para un usuario individual, esa es una elección razonable. Para un entorno corporativo, esa misma simplicidad se convierte en una vulnerabilidad estructural.

Passwork es la alternativa empresarial a las bóvedas personales del navegador. La extensión de navegador de Passwork funciona exactamente como un gestor de contraseñas integrado del navegador — autocompleta inicios de sesión en sitios web, ofrece guardar nuevas credenciales — pero las almacena en una bóveda corporativa protegida en lugar de un perfil personal del navegador.

Passwork soporta despliegue autoalojado, cifrado AES-256, integración con Active Directory y LDAP, autorización SSO, control de acceso basado en roles, registro de auditoría completo, integración SIEM y herramientas REST API y CLI para flujos de trabajo DevOps.

La diferencia es arquitectónica. Una bóveda del navegador prioriza la conveniencia individual. Un gestor de contraseñas empresarial prioriza el control y la visibilidad organizacional. Cuando las credenciales privilegiadas terminan en una bóveda del navegador, se ha elegido la herramienta incorrecta para el trabajo — no porque la herramienta sea mala, sino porque fue diseñada para un problema diferente.

Conclusión: Qué hacer ante VaultJacking

La amenaza que describe VaultJacking es específica: una técnica de phishing que convierte un único PIN capturado en exposición de credenciales a nivel de bóveda. La respuesta debe ser igualmente específica — no pánico sobre las passkeys, y no descarte del riesgo de la bóveda del navegador, sino una política clara que separe la conveniencia de credenciales personales de la gobernanza de credenciales privilegiadas.

Comience con la auditoría. Descubra qué credenciales privilegiadas viven actualmente en bóvedas del navegador. ¿Qué cuentas de administrador están sincronizadas con dispositivos personales? ¿Qué credenciales de emergencia están almacenadas en Google Password Manager? Esa respuesta le dirá cuánto trabajo hay por hacer.

A partir de ahí, el camino es directo: prohíba las credenciales privilegiadas en bóvedas del navegador, muévalas a un gestor de contraseñas empresarial con registros de auditoría y controles de acceso, y extienda su formación de concienciación de seguridad para cubrir avisos de bóveda y flujos de recuperación.

VaultJacking no es una razón para abandonar los gestores de contraseñas del navegador. Es una razón para usarlos para lo que fueron diseñados — credenciales personales — y para construir un sistema separado y auditable para todo lo demás.

Passwork es un gestor de contraseñas y secretos empresarial autoalojado construido para la gobernanza de credenciales privilegiadas. Proporciona acceso basado en roles, registros de auditoría completos y separación total de las bóvedas de navegador de consumidor. Vea cómo encaja en su infraestructura

Preguntas frecuentes

¿Qué es VaultJacking?

VaultJacking es una técnica de phishing que ataca la bóveda de Google Password Manager capturando el PIN de Google Password Manager del usuario durante una sesión de phishing adversary-in-the-middle. El PIN capturado se utiliza para inscribir un dispositivo controlado por el atacante en el dominio de seguridad de Google de la víctima, descifrando cada contraseña y passkey sincronizada almacenada en la bóveda. La técnica fue demostrada de extremo a extremo por PhishU en mayo de 2026.

¿Es VaultJacking una vulnerabilidad de Google?

Según los informes publicados, VaultJacking es una técnica demostrada de phishing y abuso de flujos de trabajo, no una vulnerabilidad clasificada en los sistemas de Google. Explota el diseño del flujo de inscripción de dispositivos de Google — específicamente la ausencia de aprobación entre dispositivos para nuevas uniones al dominio de seguridad — que Google eligió deliberadamente como una decisión de experiencia de usuario para la recuperación de dispositivos perdidos. Si Google clasifica esto como una vulnerabilidad que requiere una corrección es una cuestión separada que no ha sido respondida públicamente en el momento de escribir esto.

¿VaultJacking rompe las passkeys?

No. Las passkeys se basan en criptografía de clave pública vinculada al origen según se define en la especificación W3C WebAuthn. Una página de phishing no puede reproducir una aserción WebAuthn contra el sitio real porque la vinculación al origen falla. VaultJacking ataca la capa de bóveda y recuperación que almacena las passkeys — no la ceremonia de autenticación criptográfica en sí. Las passkeys siguen siendo resistentes al phishing en la capa de inicio de sesión por sitio.

¿Qué es el PIN de Google Password Manager?

El PIN de Google Password Manager es un secreto que protege los datos cifrados de Google Password Manager. Según la documentación de Google, se crea cuando un usuario guarda su primera passkey en un ordenador, iPhone o iPad, y se utiliza para acceder a passkeys en nuevos dispositivos, verificar la identidad y asegurar que ni siquiera Google pueda leer el contenido cifrado de la bóveda. Es distinto de la contraseña de la cuenta de Google y del bloqueo de pantalla del dispositivo.

¿Puede un único PIN exponer todas mis contraseñas guardadas?

La demostración de PhishU muestra que un PIN de Google Password Manager de seis dígitos capturado puede permitir a un atacante descifrar toda la bóveda sincronizada — cada contraseña guardada y cada passkey sincronizada — desde infraestructura controlada por el atacante. El PIN libera el Security Domain Secret, que descifra la bóveda en una sola operación. Si introdujo el PIN en una página a la que no navegó directamente, trátelo como posible exposición completa de la bóveda.

¿Qué debo hacer si introduje el PIN en una página sospechosa?

Revise sus dispositivos conectados y passkeys registradas en myaccount.google.com inmediatamente. Revoque cualquier dispositivo o sesión desconocida. Cambie su contraseña de la cuenta de Google. Rote las credenciales de alto valor guardadas en la bóveda — priorice SSO, correo electrónico, consolas en la nube, plataformas financieras y cuentas de administrador. Compruebe los servicios de terceros en busca de actividad de inicio de sesión inusual. Si está en una organización, abra un caso de respuesta a incidentes en lugar de tratar esto como un problema de una sola cuenta.

¿Deberían las empresas prohibir Google Password Manager?

Una prohibición general no es la política correcta para la mayoría de las organizaciones. Un enfoque basado en riesgos funciona mejor: restrinja el almacenamiento de credenciales privilegiadas y compartidas a un gestor de contraseñas empresarial con controles de auditoría, imponga perfiles de navegador gestionados separados para uso laboral, y extienda la formación de concienciación sobre phishing para cubrir avisos del gestor de contraseñas y flujos de recuperación. Google Password Manager es apropiado para credenciales personales; no está diseñado para cuentas de emergencia o acceso de administrador compartido.

¿Son las llaves de seguridad de hardware suficientes para detener esto?

Las llaves de seguridad de hardware fortalecen la garantía de inicio de sesión de la cuenta de Google, pero no gobiernan automáticamente la sincronización de la bóveda del navegador, los flujos de recuperación o las credenciales almacenadas dentro de la bóveda. VaultJacking ataca la capa de gestión de la bóveda, no el paso de inicio de sesión de la cuenta. Una llave de hardware en la cuenta de Google reduce el riesgo de toma de control de la cuenta pero no impide que un usuario sea engañado para introducir su PIN de Google Password Manager en una página de phishing.

Gestión de contraseñas y accesos para pymes: ¿Es KeePass suficiente?

¿Usa KeePass para su equipo? Descubra los riesgos ocultos de KeePass para pymes en 2026 — fallos de sincronización, brechas de cumplimiento y cuándo cambiar a un gestor de contraseñas corporativo.

Passwork BlogAlex Muntyan

Passwork gana Top Performer primavera 2026 en SourceForge

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

Passwork BlogAlex Muntyan

Ciclo de vida de la rotación de secretos: De la creación a la revocación

La rotación de secretos falla cuando se trata como una tarea programada en lugar de un ciclo de vida. Esta guía cubre las siete etapas — desde la creación y propiedad hasta la rotación segura, revocación de emergencia y evidencia de auditoría.

Passwork BlogAlex Muntyan

VaultJacking is a phishing technique that targets the Google Password Manager vault by capturing the PIN that unlocks it. Demonstrated by PhishU on May 20, 2026, the attack shows how a single six-digit secret, captured during an adversary-in-the-middle (AiTM) phishing session, can give an attacker access to every synced password and passkey a victim has stored in Google Password Manager.

For businesses, the stakes are higher than they appear. A single employee's browser vault can hold SSO credentials, cloud console access, finance platform logins, and code repository keys: all in one place and exposed by one captured PIN. It is an organizational risk that sits outside most existing incident-response playbooks, and outside the visibility of most IT and security teams.

Key takeaways

VaultJacking matters because browser password managers concentrate passwords, passkeys, and recovery flows into a single high-value target. Before reading further, here is what you need to know.

• VaultJacking targets the vault sync layer. The attack does not break WebAuthn cryptography. It abuses the device-enrollment flow that governs who can read the synced vault.
• The Google Password Manager PIN is a vault-access secret. Google uses the PIN to protect encrypted credential data. Treat it accordingly, not as a throwaway code.
• One captured PIN can expose the entire vault. PhishU's demonstration shows that a single PIN entry can allow an attacker to decrypt every synced password and passkey on operator-controlled infrastructure.
• Enterprise risk scales with governance gaps. Personal/work profile mixing, unmanaged Chrome profiles, and privileged credentials stored in browser vaults all increase the blast radius.
• Incident response must go beyond a password reset. A suspected VaultJacking event requires reviewing devices, sessions, passkeys, vault contents, and downstream logins, not just changing one password.

What is VaultJacking?

VaultJacking is a phishing technique that targets the Google Password Manager vault access and recovery experience. Instead of stealing one site credential, the attacker captures the Google Password Manager PIN during an AiTM phishing session and uses it to enroll an attacker-controlled device into the victim's Google security domain, gaining access to the entire synced credential vault. The term and the end-to-end demonstration originate from PhishU's published research.

Traditional credential phishing targets one account at a time. VaultJacking is a different class of attack: the attacker bypasses individual credentials entirely and goes straight for the repository that holds all of them.

PhishU's research describes the attack as fully consistent with standard AiTM phishing. The AiTM proxy captures the PIN alongside session cookies. A background worker then adds an attacker-owned passkey to the victim's Google account for persistence, joins the security domain from attacker infrastructure using the captured PIN, and decrypts the entire vault. The operator sees every synced credential in a single view.

Browser Syncjacking, a separate technique PhishU references, reaches the same Google sync layer via a malicious browser extension. VaultJacking requires neither a device foothold nor an extension.

What is the Google Password Manager PIN?

The Google Password Manager PIN is a separate secret from your Google account password and your device screen lock. Google's documentation describes it as a way to protect encrypted Google Password Manager data, use passkeys on a new device, and verify identity.

Users frequently confuse three different secrets, and that confusion is part of what makes VaultJacking effective:

You will see the Google Password Manager PIN prompt when creating your first passkey on a new device, when accessing encrypted saved credentials in certain recovery contexts, or when a new device joins your Google security domain. That last scenario is exactly what VaultJacking exploits.

The structural reason this works, according to PhishU's analysis of the Chromium source (chrome/browser/webauthn/enclave_manager.cc and components/trusted_vault/), is that Google's security domain join flow requires two checks: a Google account sign-in and a successful PIN entry. There is no cross-device approval prompt, no push notification to existing devices, no "approve from another device" confirmation.

Apple's iCloud Keychain requires existing devices to approve new ones. Google's model does not. Google made a deliberate UX trade-off: a PIN with a server-side retry cap is easier to recover from than a push-to-approve model when a user has lost all their devices. VaultJacking is the consequence of that trade-off.

How the VaultJacking attack chain works

The following describes the attack conceptually for defensive purposes. No offensive implementation details are included.

1. Lure. The victim receives a phishing link and lands on a page that imitates a legitimate Google sign-in or account workflow. Treat any unexpected sign-in flow arriving via email, chat, or ad link with suspicion.
2. Trust transfer. The AiTM proxy renders a PIN prompt styled to match Google's own interface: same font, same six-cell input, same copy. User education must cover password-manager PIN prompts, not only passwords and OTP codes.
3. PIN capture. The victim enters the PIN into the phishing flow. The PIN is a vault-access secret, equivalent in sensitivity to a master password.
4. Attacker device enrollment. The attacker uses the captured PIN to join the victim's Google security domain from attacker-controlled infrastructure. An attacker-owned passkey is also registered for persistence. Review signed-in devices and registered passkeys immediately after any suspected phishing contact.
5. Vault decryption. The Security Domain Secret is released by Google's cloud authenticator, and the attacker's device decrypts every synced password and passkey. The vault may contain credentials for email, SSO, cloud consoles, financial platforms, and code repositories.
6. Downstream compromise. Saved third-party credentials are used against other services. Rotate high-value credentials and monitor third-party logins.

PhishU tested this end to end against live Google Password Manager accounts, including replay of captured third-party passkeys regardless of whether the original credential was hardware-backed. Treat this as a demonstrated technique. There is no public evidence of widespread active exploitation at the time of writing, but the technique requires no specialized access or device foothold.

Does VaultJacking mean passkeys are broken?

No. VaultJacking does not break passkey cryptography. Passkeys are based on origin-bound public-key authentication as defined in the W3C WebAuthn specification: the private key never leaves the device, and the authentication ceremony is bound to the legitimate site origin. A phishing page cannot replay a WebAuthn assertion against the real site because the origin check fails. That protection holds.

What VaultJacking demonstrates is that passkeys do not exist in isolation. They exist inside a vault, which syncs across devices, which relies on a recovery mechanism, which is governed by a PIN. The attacker bypasses the cryptographic ceremony entirely by targeting the vault management layer instead.

Google describes passkeys as a way to sign in with a fingerprint, face scan, or screen lock — simpler and safer than passwords. That description is accurate at the per-site authentication layer. The issue VaultJacking surfaces is one level up: what governs access to the store that holds those passkeys.

Why one PIN can create a large blast radius

A password-manager vault is a concentrated store of access. One captured PIN exposes every credential the victim has ever saved in Google Password Manager.

Recorded Future's 2025 Identity Threat Landscape Report found that the average compromised device yielded 87 stolen credentials, and that 276 million of the credentials indexed in 2025 included active session cookies — meaning attackers could bypass MFA entirely for those accounts.

Verizon's 2026 DBIR puts the downstream effect in context: credential abuse appears at some point in 39% of all confirmed breaches, across more than 22,000 incidents in 145 countries. Attackers rarely stop at the first door a stolen credential opens. They move laterally, escalate privileges, and work through every saved login until they hit something valuable.

Who is most at risk?

Risk concentrates where three conditions overlap: browser vault data is the primary credential store, work and personal credentials share a profile, and privileged credentials have ended up in a consumer-grade system.

1. The credential mixing problem. Employees save work credentials in personal Chrome profiles. Admins have no visibility or control over vault contents or synced devices. This means corporate passwords live outside the security perimeter, backed up to Google's servers, and accessible from any device the employee has ever logged into.
2. Privileged users are the highest-value target. Admin passwords stored in Google Password Manager represent the most dangerous concentration of risk. One vault compromise exposes the keys to identity platforms, cloud infrastructure, finance systems, and security tooling. A single compromised admin account becomes a pivot point for lateral movement across the entire organization.
3. Security training doesn't cover this attack surface. Security awareness programs teach users to recognize phishing emails and protect OTP codes. They don't teach users to recognize password-manager PIN prompts as sensitive targets. Users see a PIN request and comply — they don't see it as a security event that should trigger skepticism.
4. Policy gaps leave credentials in the wrong place. Most organizations have no policy separating browser vaults from enterprise credential management. Shared credentials, admin passwords, and break-glass accounts may be stored wherever employees find it convenient. No audit trail exists to show where these credentials live or who has accessed them.
5. Device and session review processes are too slow. Suspicious device enrollment or vault access may go unnoticed for weeks.

The last point matters more than it might appear. PhishU notes that Google sends a single "new sign-in on Windows" email when a new device joins the security domain — the same notification sent for any new Chrome login. No push notification fires on existing devices. In an AiTM engagement where the attacker has also captured the victim's inbox session, that email can be suppressed before the user sees it.

What to do if a Google Password Manager PIN may have been phished

Do not treat a suspected VaultJacking event as a single-password incident. Treat it as possible vault exposure until proven otherwise.

The following triage sequence is for security teams and individuals. Google Workspace event names should be verified against current Google Admin documentation before building automated detection.

Steps 5 and 7 are where most incident responses fall short. Rotating the Google account password without rotating the downstream credentials it protects is like changing the lock on a safe after the contents have already been photographed.

Passwork gives you visibility into every credential, who accessed it, and when. Role-based access means shared credentials stay in one place with a complete audit trail — not scattered across personal browser profiles. Explore how it works

Stopping the breach: step-by-step technical response

When a VaultJacking event is suspected, the first 60 minutes determine how far the damage spreads. These steps are for security engineers and IT administrators. Execute them in order — later steps depend on evidence preserved in earlier ones.

1. Force sign-out of all active sessions. Navigate to myaccount.google.com/security → "Manage all devices" → revoke every session you cannot physically account for. Do not delegate this to the affected user — do it from an admin console where possible. Session revocation cuts off an attacker who has vault access but has not yet finished extracting credentials.
2. Audit registered passkeys before revoking anything else. Go to myaccount.google.com/security → "Passkeys and security keys." Screenshot the full list first, then revoke every entry the user cannot identify by device name and registration date. An attacker-registered passkey survives a password reset and re-establishes persistence. PhishU's research confirms that the background worker registers an operator-owned passkey as part of the standard VaultJacking flow — persistence is built in by design.
3. Pull the Google Workspace audit log. In admin.google.com → Reports → Audit → Login, filter for the affected user's account within the 24-hour window around the reported phishing event. Look for any login_type event combined with a source IP outside your organization's known ranges. A new device enrollment from an unrecognized IP within minutes of a phishing click timestamp is a strong indicator of vault compromise. Verify current Google Workspace event field names against Google Admin SDK documentation before building automated queries.
4. Configure a SIEM alert for future detection. Create a high-priority correlation rule: new Google account device enrollment event + source IP not in corporate IP allowlist + time delta under 10 minutes from a known phishing click. Most organizations currently have no detection for vault-layer events — this rule closes that gap. F5 Labs' threat bulletin format recommends building SIEM detection rules tied to specific behavioral indicators rather than relying on email notifications alone.
5. Rotate credentials in strict priority order. Do not rotate in bulk without logging each action — you need the audit trail for the incident report and for downstream notification decisions.
   1. SSO and identity provider accounts
   2. Cloud console root and admin credentials
   3. Code repository tokens and CI/CD pipeline secrets
   4. Finance and payroll platform logins
   5. VPN and remote access credentials
   6. Any break-glass or shared service accounts stored in the vault
6. Check downstream third-party services. Review login events from the affected account on all third-party services for the 48-hour window after the phishing event. Attackers typically test saved credentials within hours of vault access. Verizon's 2026 DBIR found credential abuse appears in 39% of confirmed breaches — lateral movement through saved logins is the expected next step, not an edge case.
7. Step 7. Preserve forensic evidence before full remediation. Screenshot the device list, export the audit log, record the phishing URL and timestamp, and document which credentials were in the vault at the time of the event. Revocation destroys attacker persistence — but it also destroys some evidence. Preserve first, remediate second.

Passwork gives your security team a full audit log of every credential access event — who opened what, when, and from which device. When an incident happens, you have the evidence trail ready. See how it works

How individuals can reduce VaultJacking risk

The practical advice here is short. Most of it comes down to treating the Google Password Manager PIN the same way you would treat a master password — because functionally, it is one.

• Do not enter the Google Password Manager PIN into any page you reached by clicking a link in email, chat, or an ad. Navigate to Google account settings directly by typing myaccount.google.com into the address bar.
• Review your signed-in devices and registered passkeys at myaccount.google.com periodically. An unfamiliar device or a passkey you do not recognize is worth investigating — not ignoring. PhishU's research shows that attacker-registered passkeys are added silently, with no notification to existing devices and no push prompt.
• Keep personal and work browser profiles separate. If a personal profile is compromised, work credentials should not be in the blast radius. Okta's 2025 Secure Sign-in Trends Report found phishing-resistant authenticator adoption grew from 8.6% to 14.0% in one year — but adoption at the authentication layer does not protect a vault that is governed by a PIN.
• Avoid saving highly sensitive admin or privileged credentials in a consumer browser vault. Those credentials need auditability and access controls that browser vaults do not provide. Continue using passkeys — they remain safer than reusable passwords at the per-site layer. The issue is not passkeys. The issue is what governs the store that holds them.

Building the controls that prevent the next one: policy and governance checklist

Okta's 2025 Secure Sign-in Trends Report found that phishing-resistant authenticator adoption grew from 8.6% to 14.0% of users in one year — a 63% increase. That growth is real progress. The governance gap is that organizations are adopting passkeys faster than they are building policies to manage the vaults that store them.

The following steps are proportional to the sensitivity of credentials involved. Not every organization needs every control. Every organization that stores privileged credentials in browser vaults needs a policy that addresses that specifically.

1. Audit which privileged credentials currently live in browser vaults. Use your MDM or endpoint tooling to identify Chrome profile sync status on all managed devices. If you cannot answer "which admin accounts are synced to personal Google profiles," that is the first gap to close — before writing any policy.
2. Write a policy that names specific credential categories. Prohibit storage of break-glass accounts, admin credentials, shared service accounts, cloud-root credentials, and CI/CD secrets in any consumer browser vault. A policy that says "sensitive data" without naming categories produces inconsistent compliance. Name the categories. Set an enforcement date.
3. Migrate covered credentials before the enforcement date. A policy without a migration path produces shadow credential stores. Move all credentials covered by Step 2 into an enterprise password manager with role-based access control and a full audit log before the policy takes effect. Passwork supports self-hosted deployment with AES-256 encryption, AD/LDAP integration, and complete audit logging — built specifically for this separation between privileged corporate credentials and personal browser convenience.
4. Enforce separate managed browser profiles for work use. Prevent personal and work vault mixing through MDM policy and user education. When a personal profile is compromised, work credentials should not be in scope. This is a configuration change, not just a recommendation.
5. Update phishing awareness training to cover vault prompts. Security awareness programs teach users to recognize phishing emails and protect OTP codes. They do not teach users that a password-manager PIN prompt carries the same risk as a master password. Add vault prompts, recovery flows, and PIN requests to your training curriculum explicitly. Users who understand what the PIN unlocks are significantly harder to VaultJack.
6. Build a vault-exposure runbook into your incident response plan. The runbook must cover: session revocation, device enrollment audit, passkey review, downstream credential rotation, and third-party account monitoring — as a single coordinated response. Walk through detection, containment, and rotation. Identify which steps your team cannot currently execute.
7. Configure detection for new device enrollments on privileged accounts. Set your CASB or identity platform to alert on new Google account device enrollments from unmanaged or unrecognized devices for all users with privileged access.
8. Review browser profile governance quarterly. Employees change roles, devices, and credential habits faster than annual reviews capture. A quarterly check on which managed devices have Chrome sync enabled and what profile type is active costs less than one vault-exposure incident response.

Why an enterprise password manager is safer than a browser vault for work credentials

A browser password manager solves a personal convenience problem: autofill, device sync, effortless storage. For an individual user, that is a reasonable choice. For a corporate environment, that same simplicity becomes a structural vulnerability.

Passwork is the enterprise alternative to personal browser vaults. The Passwork browser extension works exactly like a built-in browser password manager — it autofills logins on websites, offers to save new credentials — but stores them in a protected corporate vault instead of a personal browser profile.

Passwork supports self-hosted deployment, AES-256 encryption, Active Directory and LDAP integration, SSO authorization, role-based access control, full audit logging, SIEM integration, and REST API and CLI tools for DevOps workflows.

The difference is architectural. A browser vault prioritizes individual convenience. An enterprise password manager prioritizes organizational control and visibility. When privileged credentials end up in a browser vault, you have chosen the wrong tool for the job — not because the tool is bad, but because it was designed for a different problem.

Conclusion: What to do about VaultJacking

The threat VaultJacking describes is specific: a phishing technique that turns one captured PIN into vault-wide credential exposure. The response should be equally specific — not panic about passkeys, and not dismissal of browser vault risk, but a clear-eyed policy that separates personal credential convenience from privileged credential governance.

Start with the audit. Find out which privileged credentials currently live in browser vaults.Which admin accounts are synced to personal devices? Which break-glass credentials are stored in Google Password Manager? That answer will tell you how much work there is to do.

From there, the path is straightforward: prohibit privileged credentials in browser vaults, move them to an enterprise password manager with audit trails and access controls, and extend your security awareness training to cover vault prompts and recovery flows.

VaultJacking is not a reason to abandon browser password managers. It is a reason to use them for what they were designed for — personal credentials — and to build a separate, auditable system for everything else.

Passwork is a self-hosted enterprise password and secrets manager built for privileged credential governance. It provides role-based access, full audit logs, and complete separation from consumer browser vaults. See how it fits into your infrastructure

Frequently Asked Questions

What is VaultJacking?

VaultJacking is a phishing technique that targets the Google Password Manager vault by capturing the user's Google Password Manager PIN during an adversary-in-the-middle phishing session. The captured PIN is used to enroll an attacker-controlled device into the victim's Google security domain, decrypting every synced password and passkey stored in the vault. The technique was demonstrated end to end by PhishU in May 2026.

Is VaultJacking a Google vulnerability?

Based on published reporting, VaultJacking is a demonstrated phishing and workflow-abuse technique, not a classified vulnerability in Google's systems. It exploits the design of Google's device-enrollment flow — specifically the absence of cross-device approval for new security domain joins — which Google chose deliberately as a UX trade-off for lost-device recovery. Whether Google classifies this as a vulnerability requiring a fix is a separate question that has not been publicly answered at the time of writing.

Does VaultJacking break passkeys?

No. Passkeys are based on origin-bound public-key cryptography as defined in the W3C WebAuthn specification. A phishing page cannot replay a WebAuthn assertion against the real site because the origin binding fails. VaultJacking targets the vault and recovery layer that stores passkeys — not the cryptographic authentication ceremony itself. Passkeys remain phishing-resistant at the per-site login layer.

What is the Google Password Manager PIN?

The Google Password Manager PIN is a secret that protects encrypted Google Password Manager data. According to Google's documentation, it is created when a user saves their first passkey on a computer, iPhone, or iPad, and it is used to access passkeys on new devices, verify identity, and ensure that not even Google can read the encrypted vault contents. It is distinct from the Google account password and from the device screen lock.

Can one PIN expose all my saved passwords?

PhishU's demonstration shows that a captured six-digit Google Password Manager PIN can allow an attacker to decrypt the entire synced vault — every saved password and every synced passkey — from attacker-controlled infrastructure. The PIN releases the Security Domain Secret, which decrypts the vault in a single operation. If you entered the PIN on a page you did not navigate to directly, treat it as possible full vault exposure.

What should I do if I entered the PIN on a suspicious page?

Review your signed-in devices and registered passkeys at myaccount.google.com immediately. Revoke any unfamiliar devices or sessions. Change your Google account password. Rotate high-value credentials saved in the vault — prioritize SSO, email, cloud consoles, financial platforms, and admin accounts. Check third-party services for unusual login activity. If you are in an organization, open an incident-response case rather than treating this as a single-account issue.

Should companies ban Google Password Manager?

A blanket ban is not the right policy for most organizations. A risk-based approach works better: restrict privileged and shared credential storage to an enterprise password manager with audit controls, enforce separate managed browser profiles for work use, and extend phishing awareness training to cover password-manager prompts and recovery flows. Google Password Manager is appropriate for personal credentials; it is not designed for break-glass accounts or shared admin access.

Are hardware security keys enough to stop this?

Hardware security keys strengthen Google account sign-in assurance, but they do not automatically govern browser-vault synchronization, recovery flows, or the credentials stored inside the vault. VaultJacking targets the vault management layer, not the account sign-in step. A hardware key on the Google account reduces the risk of account takeover but does not prevent a user from being tricked into entering their Google Password Manager PIN on a phishing page.

Password and access management for SMBs: Is KeePass enough?

Using KeePass for your team? Discover the hidden risks of KeePass for SMBs in 2026 — sync failures, compliance gaps, and when to switch to a corporate password manager.

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

Secrets rotation lifecycle: From creation to revocation

Secret rotation fails when it’s treated as a scheduled task rather than a lifecycle. This guide covers all seven stages — from creation and ownership to safe rotation, emergency revocation, and audit evidence.

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

La Directiva NIS2 (UE 2022/2555) ya no es una preocupación futura. Desde octubre de 2024, las organizaciones de 18 sectores europeos deben demostrar el cumplimiento de controles de ciberseguridad obligatorios. Las sanciones alcanzan los 10 millones de euros o el 2% de la facturación anual global, y los miembros del consejo de administración enfrentan responsabilidad personal por incumplimiento.

En el núcleo de NIS2 está el Artículo 21, que establece 10 medidas de seguridad específicas. De estas, la gestión de acceso (gobernanza de credenciales, control de acceso basado en roles, autenticación multifactor y registro de auditoría) es la más auditable y la más directamente vinculada a los resultados de las brechas de seguridad.

Esta guía relaciona esos requisitos con pasos de implementación prácticos y muestra cómo generar evidencia de cumplimiento que los reguladores esperan.

Puntos clave

• Las credenciales robadas aparecen en el 39% de todas las brechas — no solo en el acceso inicial, sino como el mecanismo principal para el movimiento lateral, la escalada de privilegios y la persistencia.
• La participación de terceros ha alcanzado el 48% en 2026, un aumento interanual del 60% que implica directamente la gobernanza del acceso a la cadena de suministro según el Artículo 21(2)(d) de NIS2.
• El Artículo 21 de NIS2 establece 10 medidas de seguridad específicas, todas obligatorias para cada entidad cubierta. Las medidas más auditables y críticas para las brechas son el control de acceso, MFA y el registro de auditoría inmutable — estas producen evidencia de cumplimiento exportable que los reguladores esperan.
• El control de acceso es donde el cumplimiento de NIS2 se vuelve medible. A diferencia de los documentos de políticas, la gobernanza de credenciales produce evidencia verificable: registros de auditoría, matrices de permisos, informes de aplicación de MFA. Los reguladores pueden confirmar que los controles se aplican activamente.
• El Artículo 23 introduce una obligación de notificación de incidentes en 24 horas. Las organizaciones sin gestión centralizada de credenciales, registros de auditoría inmutables y capacidades de rotación automatizada no pueden cumplir este plazo. La rotación masiva de contraseñas debe ser ejecutable en horas, no en días.
• ENISA especifica tres niveles de MFA. El Nivel 1 (FIDO2/WebAuthn resistente al phishing) es obligatorio para todas las cuentas privilegiadas. El Nivel 2 (TOTP) es aceptable para usuarios estándar. Los OTP por SMS y correo electrónico están explícitamente marcados para eliminación progresiva y no cumplen el umbral mínimo.
• La responsabilidad personal de los miembros del consejo de administración no tiene precedentes. El Artículo 20 responsabiliza personalmente a los ejecutivos de nivel C por fallos de ciberseguridad, incluyendo prohibiciones temporales de funciones directivas. Esta disposición no tiene precedente en NIS1.
• Las sanciones alcanzan los 10 millones de euros o el 2% de la facturación anual global para Entidades Esenciales, con aplicación activa desde 2026. Las autoridades competentes nacionales en toda la UE han comenzado auditorías proactivas. El incumplimiento ya no es una preocupación futura.
• El despliegue en las instalaciones propias elimina la custodia de datos por terceros. Las credenciales permanecen dentro de su red sin transmisión externa. Los registros de auditoría se almacenan localmente y se envían directamente a su SIEM sin intermediario del proveedor, garantizando la independencia de la auditoría.
• La hoja de ruta de implementación en 5 fases toma de 30 a 60 días desde la evaluación hasta el cumplimiento listo para auditoría: evaluación previa al despliegue, auditoría de acceso, despliegue del sistema de credenciales, configuración NIS2 y monitoreo continuo. La mayoría de las organizaciones pueden pasar de una gestión de acceso fragmentada a la aplicación dentro de este plazo.

Por qué NIS2 se centra en la gestión de acceso

El control de acceso es donde el cumplimiento de NIS2 se vuelve medible. A diferencia de los documentos de políticas o las evaluaciones de riesgos, la gobernanza de credenciales produce evidencia exportable: registros de auditoría, matrices de permisos, informes de aplicación de MFA. Los reguladores pueden verificar que los controles se aplican activamente.

El panorama de amenazas hace evidente esta urgencia. Según el Informe de Investigaciones de Brechas de Datos de Verizon de 2026, la explotación de vulnerabilidades se ha convertido en el vector de acceso inicial líder con el 31% de las brechas, frente al 20% en 2025. Sin embargo, esta comparación general oculta un hallazgo más crítico: las credenciales robadas aparecen en el 39% de todas las brechas a lo largo de todo el ciclo de vida del ataque — no solo en el acceso inicial, sino como el mecanismo principal para el movimiento lateral, la escalada de privilegios y la persistencia.

Una vez que los atacantes obtienen entrada, las credenciales se convierten en su herramienta dominante para moverse a través de la infraestructura. La participación de terceros ha alcanzado el 48% en 2026, frente al 30% en 2025 — un aumento del 60% que implica directamente la gobernanza del acceso a la cadena de suministro según el Artículo 21(2)(d) de NIS2.

Las credenciales robadas impulsan la expansión de las brechas — reutilizadas, compartidas o nunca revocadas cuando los empleados se van. El Artículo 21 de NIS2 fue diseñado para eliminar esto mediante un control de acceso estricto, MFA obligatorio y registro de auditoría inmutable.

Comprendiendo el Artículo 21 de NIS2: Las 10 medidas de seguridad obligatorias

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 cada entidad cubierta. Esto es lo que exige cada una:

• Medida 1: Análisis de riesgos y políticas de seguridad de los sistemas de información. Las organizaciones deben identificar y documentar continuamente los riesgos de ciberseguridad. Esto se traduce en el descubrimiento de credenciales: mapear todas las cuentas privilegiadas, identificar credenciales compartidas y documentar qué sistemas contienen el acceso de mayor riesgo.
• Medida 2: Gestión de incidentes — prevención, detección y respuesta. Las organizaciones deben tener procedimientos documentados para responder a incidentes de seguridad. Para las brechas basadas en credenciales, esto significa la capacidad de rotar contraseñas comprometidas de forma masiva en horas, no en días.
• Medida 3: Continuidad del negocio, gestión de copias de seguridad y recuperación ante desastres. Las credenciales deben permanecer accesibles incluso cuando los sistemas principales fallan. Esto requiere clustering de conmutación por error, replicación y procedimientos de copia de seguridad probados.
• Medida 4: Seguridad de la cadena de suministro. Las organizaciones deben evaluar y gestionar los riesgos de ciberseguridad que plantean los proveedores directos y prestadores de servicios. Para las credenciales, esto significa aislar el acceso de terceros, limitarlo en el tiempo y revocarlo automáticamente cuando terminan los contratos.
• Medida 5: Seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas de información. Los sistemas deben construirse y mantenerse teniendo en cuenta la seguridad. Para los sistemas de credenciales, esto significa prácticas de desarrollo seguro y pruebas de penetración regulares.
• Medida 6: Políticas y procedimientos para evaluar la efectividad de las medidas de gestión de riesgos de ciberseguridad. Las organizaciones deben verificar que los controles realmente funcionan. Esto requiere registros de auditoría: prueba de que los controles de acceso se aplican y que cada acción de credenciales se registra.
• Medida 7: Prácticas básicas de higiene cibernética y formación en ciberseguridad. Las contraseñas débiles son el fallo de credenciales más común. Las organizaciones deben aplicar complejidad de contraseñas, programas de rotación y concienciación de seguridad del usuario.
• Medida 8: Políticas y procedimientos relativos al uso de criptografía y cifrado. Las credenciales deben estar cifradas en reposo y en tránsito. Esto significa cifrado AES-256, TLS para todas las comunicaciones y arquitectura de conocimiento cero donde el servidor nunca tiene las claves de descifrado.
• Medida 9: Seguridad de recursos humanos, políticas de control de acceso y gestión de activos. Este es el núcleo de la gobernanza de acceso de NIS2: cada usuario debe tener derechos de acceso documentados, cada cambio de acceso debe registrarse y cada credencial debe revocarse cuando el acceso ya no es necesario.
• Medida 10: Uso de MFA o soluciones de autenticación continua. La autenticación multifactor ya no es opcional. La guía técnica de ENISA especifica tres niveles de fortaleza de MFA, con autenticación resistente al phishing (FIDO2/WebAuthn) obligatoria para todas las cuentas privilegiadas.

Tabla de referencia rápida

Passwork proporciona evidencia de cumplimiento directa en 9 de las 10 medidas de NIS2. Los registros de acceso y los registros de auditoría inmutables satisfacen las medidas 1, 2 y 6. El almacenamiento cifrado cubre la medida 8. RBAC, la aplicación de MFA y el control de acceso a nivel de activos cierran las medidas 9 y 10 — donde los reguladores exigen pruebas técnicas. Obtenga una demostración gratuita y véalo en acción

La obligación de notificación de incidentes en 24 horas

El Artículo 23 de NIS2 introduce un cronograma de notificación en tres etapas que cambia fundamentalmente cómo las organizaciones responden a las brechas de credenciales.

• Alerta temprana (24 horas). Dentro de las 24 horas posteriores al descubrimiento de un incidente significativo, las organizaciones deben notificar al CSIRT nacional. No se requiere evaluación completa — solo confirmación de que ocurrió un incidente y si se sospecha actividad criminal.
• Notificación de incidente (72 horas). Proporcionar una evaluación inicial: gravedad, impacto, indicadores de compromiso (IoCs) y sistemas afectados. Aquí es donde el alcance de la brecha de credenciales se vuelve crítico. Si las credenciales de administrador fueron comprometidas, el alcance es potencialmente empresarial.
• Informe final (1 mes). Análisis completo de la causa raíz, pasos de remediación tomados, evaluación del impacto transfronterizo y lecciones aprendidas. Este es el documento que los reguladores examinarán. Para las brechas de credenciales, debe incluir prueba de que todas las contraseñas comprometidas fueron rotadas y que el acceso fue revocado para cualquier cuenta que ya no debería haber tenido acceso.

Las organizaciones sin gestión centralizada de credenciales, registros de auditoría inmutables y capacidades de rotación automatizada no pueden cumplir el plazo de 24 horas.

Guía técnica de ENISA: MFA, PAM y registro de auditoría

La Agencia de la Unión Europea para la Ciberseguridad (ENISA) publicó guía detallada de implementación técnica para NIS2. Para la gestión de acceso, tres áreas dominan: fortaleza de MFA, gestión de acceso privilegiado (PAM) y registro de auditoría.

MFA: Tres niveles de fortaleza

ENISA clasifica MFA en tres niveles según la resistencia al phishing:

1. Fuerte (resistente al phishing). FIDO2, WebAuthn y llaves de seguridad de hardware. Estos no pueden ser interceptados por ataques de phishing porque utilizan protocolos criptográficos de desafío-respuesta. ENISA exige el Nivel 1 para todas las cuentas privilegiadas y administrativas. Sin excepciones.
2. Medio. Aplicaciones autenticadoras TOTP y notificaciones push. Aceptable para cuentas de usuarios estándar. Vulnerable al phishing en tiempo real pero significativamente mejor que solo contraseñas.
3. Último recurso (eliminar progresivamente). Contraseñas de un solo uso por SMS y correo electrónico. Vulnerable a ataques de SIM-swap e interceptación. ENISA recomienda explícitamente eliminar estos para todos los entornos regulados.

Las organizaciones deben documentar qué nivel de MFA se aplica para cada grupo de usuarios. Los auditores verificarán que todas las cuentas privilegiadas usen el Nivel 1 y que los OTP por SMS/correo electrónico ya no estén en uso.

Gestión de acceso privilegiado (PAM)

ENISA especifica cuatro requisitos de PAM:

1. Separación de funciones. Las cuentas de administrador nunca deben usarse para tareas generales como correo electrónico o navegación. Se requieren cuentas separadas y dedicadas para todas las operaciones privilegiadas.
2. Registro de auditoría completo. Cada acción privilegiada debe registrarse con identidad del usuario, marca de tiempo, IP de origen y acción realizada. Los registros deben ser inmutables y a prueba de manipulaciones.
3. Acceso Just-In-Time (JIT). Privilegios otorgados por evento y revocados automáticamente después del uso. Sin acceso de administrador permanente.
4. Gobernanza de acceso de terceros. El acceso de proveedores debe estar delimitado, limitado en el tiempo y revocado automáticamente al finalizar el contrato o el proyecto.

Registro de auditoría (ENISA §11.4)

Los registros deben ser:

• Centralizados. Todas las acciones de credenciales registradas en un único sistema protegido.
• Inmutables. Ningún usuario, incluidos los administradores, puede modificar o eliminar entradas de registro.
• Exportables. Formatos estructurados (JSON, CSV, Syslog) para integración con SIEM y presentación regulatoria.
• Retenidos. Período mínimo de retención definido por la evaluación de riesgos de la entidad (típicamente 1-3 años).

Los registros incompletos o manipulables no satisfarán ENISA §11.4. Los reguladores los rechazarán.

Mapeo de requisitos NIS2 a controles técnicos

Así es como los controles técnicos específicos satisfacen las obligaciones del Artículo 21:

Cada control en la tabla anterior está integrado en la arquitectura central de Passwork. Obtiene paneles de seguridad de contraseñas, registros de auditoría inmutables, RBAC, aplicación de MFA y cifrado AES-256 de serie. El resultado: evidencia de cumplimiento que los reguladores esperan, no documentos de políticas que tienen que interpretar.

La hoja de ruta de implementación en 5 fases: De la evaluación al cumplimiento listo para auditoría

Pasar de una gestión de acceso fragmentada a un cumplimiento NIS2 listo para auditoría no requiere una reconstrucción completa de la infraestructura. Un enfoque estructurado en 5 fases lleva a la mayoría de las organizaciones de la evaluación a la aplicación en 30-60 días.

Fase 1: Evaluación previa al despliegue (semana 1)

1. Definir los límites del alcance NIS2. ¿Qué unidades de negocio, sistemas y grupos de usuarios están bajo la directiva? Clasifique su organización como Entidad Esencial o Importante y confirme las obligaciones aplicables.
2. Asignar responsabilidad. Designe un responsable de cumplimiento con responsabilidad del Artículo 20 — típicamente el CISO o Director de TI. Alinee los equipos de TI, seguridad, RRHH y legal en roles, responsabilidades y rutas de escalación.
3. Confirmar preparación de infraestructura. Verifique las especificaciones del servidor y la topología de red para el despliegue en las instalaciones propias. Confirme la preparación de Active Directory o LDAP para el aprovisionamiento automatizado de usuarios.

Fase 2: Auditoría de acceso — dónde está hoy (semana 2)

1. Mapear todas las cuentas privilegiadas. Identifique cada cuenta con acceso de administrador en todos los sistemas e infraestructura. Incluya cuentas de servicio y credenciales compartidas — estas son sus credenciales de mayor riesgo.
2. Identificar acceso de terceros. Revise todo el acceso activo de terceros y proveedores. Documente el alcance, la duración y el estado actual de MFA. Aquí es donde la mayoría de las organizaciones descubren acceso no controlado.
3. Evaluar el registro actual. ¿Qué se está registrando hoy, dónde y por cuánto tiempo? Documente la brecha entre el estado actual y los requisitos técnicos de ENISA.

Fase 3: Desplegando Passwork en su entorno (semana 3)

1. Instalar en las instalaciones propias. Despliegue mediante Docker Compose o servidor bare-metal (Linux/Windows). Passwork se ejecuta completamente dentro de su infraestructura sin transmisión externa de credenciales.
2. Integrar con sistemas de identidad. Conecte con Active Directory o LDAP para aprovisionamiento automatizado de usuarios. Configure SSO mediante SAML 2.0 para autenticación fluida y auditable.
3. Importar y organizar credenciales. Migre las credenciales existentes a bóvedas estructuradas por equipo, sistema y criticidad. Defina la estructura inicial de bóvedas y la jerarquía de propiedad.

Fase 4: Configurando para cumplimiento NIS2 (semana 4)

1. Definir y aplicar RBAC. Aplique el principio de mínimo privilegio en toda la organización. Cada usuario accede solo a las credenciales que su rol requiere.
2. Exigir MFA. Aplique Nivel 1 (FIDO2) para todas las cuentas privilegiadas. Aplique Nivel 2 (TOTP) para todos los usuarios estándar. Documente la aplicación como evidencia de auditoría.
3. Aislar acceso de terceros. Cree bóvedas dedicadas y con límite de tiempo para proveedores y contratistas con expiración automática al fin del contrato.
4. Configurar políticas de contraseñas. Aplique reglas de complejidad, programas de rotación y expiración automática. Habilite el registro completo de auditoría y configure la integración SIEM vía Syslog.

Fase 5: Monitoreo e informes continuos (continuo)

1. Programar revisiones de acceso trimestrales. Valide que las asignaciones de RBAC permanezcan precisas. Asegúrese de que no quede acceso huérfano después de las salidas de empleados.
2. Generar informes de cumplimiento automatizados. Demuestre la aplicación de MFA, gobernanza de acceso y efectividad de controles. Tenga paquetes de evidencia exportables listos para presentación regulatoria bajo demanda.
3. Monitorear registros de auditoría. Integre alertas con SIEM para patrones de acceso anómalos. Realice evaluaciones anuales de preparación NIS2 contra la guía actualizada de ENISA.

La lista de verificación de cumplimiento NIS2

Use esta lista de verificación para rastrear su postura de cumplimiento en las tres áreas críticas: gestión de acceso, seguridad de la cadena de suministro y preparación para incidentes.

Control de acceso (Artículo 21(2)(i))

• Mapear todas las cuentas privilegiadas en todos los sistemas e infraestructura
• Implementar RBAC estricto — cada usuario accede solo a las credenciales que su rol requiere
• Eliminar todas las cuentas compartidas — reemplazar con acceso individualizado
• Automatizar el ciclo de vida de identidad vía AD/LDAP — revocación inmediata del acceso tras la salida del empleado
• Exportar matrices de permisos como evidencia lista para auditores

Cadena de suministro (Artículo 21(2)(d))

• Aislar todo el acceso de terceros en bóvedas dedicadas con límite de tiempo
• Auditar todas las credenciales activas de proveedores — revocar cualquier acceso que ya no esté operativamente justificado
• Documentar el alcance del acceso de proveedores, duración y estado de MFA para cada credencial activa de terceros
• Configurar expiración automática al fin del contrato

MFA (Artículo 21(2)(j))

• Aplicar MFA Nivel 1 (FIDO2/WebAuthn) para todas las cuentas administrativas
• Aplicar MFA Nivel 2 (TOTP) para todos los usuarios estándar
• Eliminar progresivamente SMS y OTP por correo electrónico — ambos no cumplen el umbral mínimo de ENISA
• Generar informe de cumplimiento que confirme MFA en todas las cuentas activas

Preparación para incidentes (Artículo 23)

• Verificar que los registros de auditoría proporcionen detalle suficiente para la alerta temprana de 24 horas
• Establecer y probar el flujo de trabajo de rotación masiva de credenciales para respuesta post-incidente
• Designar individuo nombrado responsable de la notificación del Artículo 23
• Preparar paquetes de evidencia exportables listos para presentación regulatoria bajo demanda

Registro de auditoría (ENISA §11.4)

• Centralizar y proteger registros de auditoría — configurar registro inmutable y exportable
• Integrar con SIEM vía Syslog — asegurar que ningún usuario pueda modificar o eliminar entradas de registro
• Confirmar que cada entrada captura identidad, marca de tiempo, acción e IP de origen
• Generar informes automatizados que cubran aplicación de MFA, cumplimiento de RBAC y revisiones de acceso

Sanciones: Lo que realmente cuesta el incumplimiento

Las consecuencias financieras y personales del incumplimiento de NIS2 son severas:

• Para Entidades Esenciales: Hasta 10 millones de euros o el 2% de la facturación anual global, lo que sea mayor. Los reguladores también pueden imponer restricciones operativas temporales.
• Para Entidades Importantes: Hasta 7 millones de euros o el 1,4% de la facturación anual global, lo que sea mayor. La supervisión reactiva no significa menor riesgo.
• Responsabilidad personal de la dirección (Artículo 20). Los miembros del consejo de administración y los ejecutivos de nivel C pueden ser considerados personalmente responsables por fallos de ciberseguridad. Las autoridades competentes pueden imponer prohibiciones temporales de funciones directivas. Esta disposición no tiene precedente en NIS1, y cambia fundamentalmente cómo el liderazgo debe abordar el cumplimiento.

Desde 2026, las autoridades competentes nacionales en toda la UE han comenzado auditorías proactivas de Entidades Esenciales. La fase de aplicación está activa.

Construyendo su paquete de evidencia NIS2

Los reguladores quieren pruebas. Su paquete de evidencia de cumplimiento debe incluir:

1. Exportación de configuración RBAC. Matrices de permisos que muestren qué usuarios/roles tienen acceso a qué credenciales.
2. Informe de aplicación de MFA. Configuración del sistema que confirme que MFA se aplica globalmente, con método MFA por usuario.
3. Muestras de registros de auditoría. Registros representativos que muestren identidad, marca de tiempo, acción e IP de origen para acceso y modificaciones de credenciales.
4. Inventario de acceso de terceros. Alcance documentado, duración y estado de MFA para cada credencial activa de proveedor.
5. Documentación de política de contraseñas. Reglas de complejidad aplicadas, programas de rotación y configuración de expiración automática.
6. Capacidad de respuesta a incidentes. Prueba de que la rotación masiva de credenciales puede ejecutarse en horas.
7. Registros de copia de seguridad y conmutación por error. Evidencia de que las credenciales permanecen accesibles durante fallos del sistema.

La ventaja del despliegue en las instalaciones propias para el cumplimiento NIS2

Las organizaciones a menudo preguntan: ¿por qué NIS2 enfatiza el despliegue en las instalaciones propias? La respuesta es soberanía de datos e independencia de auditoría.

1. Los datos permanecen donde usted los gobierna. Todas las credenciales permanecen dentro de su red sin transmisión externa, sin custodia de terceros y sin ambigüedad jurisdiccional.
2. Registros de auditoría que usted posee y controla. Los registros se almacenan localmente, se envían directamente a su SIEM vía Syslog sin intermediario del proveedor, sin restricciones y sin datos que salgan de su perímetro.
3. Sin dependencia de datos de terceros. Debido a que el sistema de credenciales se ejecuta dentro de su infraestructura, no tiene custodia sobre sus credenciales, eliminando la dependencia de datos de terceros que desencadena los requisitos de evaluación de la cadena de suministro bajo el Artículo 21(2)(d).
4. Evidencia de cumplimiento en sus términos. Cada informe, registro y exportación de configuración se genera desde su propia infraestructura y está disponible bajo demanda para auditores, sin dependencia del equipo de soporte del proveedor o política de retención de datos.
5. Entornos aislados soportados. Despliegue con air gap para infraestructuras OT/ICS con cero exposición de red. Las credenciales permanecen accesibles incluso donde la conectividad a internet está prohibida por diseño.

Conclusión: Del cumplimiento a la ventaja competitiva

NIS2 es un mandato para asegurar la infraestructura de la que depende la sociedad europea. Los vectores de ataque basados en credenciales dominan el panorama de amenazas de 2026 — y son precisamente lo que el Artículo 21 fue diseñado para abordar.

Las organizaciones que centralizan la gobernanza de credenciales, aplican MFA resistente al phishing y mantienen registros de auditoría inmutables hacen más que pasar la auditoría. Eliminan su superficie de ataque más significativa. La hoja de ruta de implementación en 5 fases de esta guía le lleva de una gestión de acceso fragmentada a un cumplimiento listo para auditoría en 30-60 días.

La base técnica para ese resultado requiere tres elementos: despliegue en las instalaciones propias que garantice la soberanía de datos, RBAC que aplique el mínimo privilegio a escala y registros de auditoría que proporcionen a los reguladores exactamente la evidencia que necesitan.

Passwork ofrece los 9 controles técnicos de esta tabla: paneles de seguridad de contraseñas, rotación masiva, clustering de conmutación por error, despliegue en las instalaciones propias, registros de auditoría inmutables, aplicación de políticas, cifrado AES-256, RBAC y MFA. Obtenga una demostración gratuita y véalo en acción.

¿Listo para pasar de la planificación del cumplimiento a la implementación? Descargue la guía completa de cumplimiento NIS2 para mapeo técnico detallado, orientación específica por sector y una lista de verificación de cumplimiento personalizable.

Preguntas frecuentes

¿Qué exige realmente el Artículo 21 de NIS2 a mi organización?

El Artículo 21 establece 10 medidas de seguridad específicas: análisis de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, desarrollo seguro, verificación de efectividad de controles, higiene cibernética, cifrado, control de acceso y MFA. Las 10 son obligatorias para cada entidad cubierta. Las medidas más auditables y críticas para las brechas son el control de acceso (Artículo 21(2)(i)), MFA (Artículo 21(2)(j)) y registro de auditoría (Artículo 21(2)(f)).

¿Quién está obligado a cumplir con NIS2?

Las organizaciones en 18 sectores europeos clasificadas como Entidades Esenciales deben cumplir inmediatamente. Estas incluyen energía, transporte, agua, salud, infraestructura digital y administración pública. Las Entidades Importantes (servicios financieros, suministro de alimentos, manufactura, productos químicos, espacio) tienen hasta octubre de 2025 para el cumplimiento total. Las organizaciones no pertenecientes a la UE que operan en estos sectores dentro de la jurisdicción de la UE también están en el ámbito de aplicación.

¿Cuáles son las sanciones por incumplimiento?

Las Entidades Esenciales enfrentan multas de hasta 10 millones de euros o el 2% de la facturación anual global, lo que sea mayor. Las Entidades Importantes enfrentan hasta 7 millones de euros o el 1,4% de la facturación anual global. Los miembros del consejo de administración y los ejecutivos de nivel C enfrentan responsabilidad personal bajo el Artículo 20, incluyendo prohibiciones temporales de funciones directivas. La aplicación está activa desde 2026.

¿Cuánto tiempo lleva implementar el cumplimiento NIS2 para la gestión de acceso?

La mayoría de las organizaciones pasan de la evaluación al cumplimiento listo para auditoría en 30-60 días utilizando un enfoque estructurado en 5 fases: evaluación previa al despliegue (semana 1), auditoría de acceso (semana 2), despliegue del sistema de credenciales (semana 3), configuración NIS2 (semana 4) y monitoreo continuo. El plazo depende de la complejidad de la infraestructura y el volumen de credenciales existentes a migrar.

¿Cuál es la diferencia entre Entidades Esenciales e Importantes bajo NIS2?

Las Entidades Esenciales operan infraestructura crítica (energía, transporte, agua, salud, infraestructura digital, administración pública). Las Entidades Importantes proporcionan servicios esenciales (servicios financieros, suministro de alimentos, manufactura, productos químicos, espacio). Las Entidades Esenciales enfrentan sanciones más altas (10 millones de euros vs. 7 millones de euros) y plazos de aplicación más estrictos. Ambas deben implementar las 10 medidas del Artículo 21.

¿Por qué NIS2 enfatiza la gestión de credenciales en las instalaciones propias?

El despliegue en las instalaciones propias garantiza la soberanía de datos: las credenciales permanecen dentro de su red sin transmisión externa ni custodia de terceros. Los registros de auditoría se almacenan localmente y se envían directamente a su SIEM sin intermediario del proveedor. Esto elimina la dependencia de datos de terceros que desencadena los requisitos de evaluación de la cadena de suministro bajo el Artículo 21(2)(d) y le proporciona independencia de auditoría completa.

¿Qué nivel de MFA requiere NIS2?

ENISA especifica tres niveles: Nivel 1 (resistente al phishing) — FIDO2, WebAuthn, llaves de seguridad de hardware — es obligatorio para todas las cuentas privilegiadas y administrativas. Nivel 2 (aplicaciones autenticadoras TOTP, notificaciones push) es aceptable para usuarios estándar. Los OTP por SMS y correo electrónico están explícitamente marcados para eliminación progresiva y no cumplen el umbral mínimo de ENISA.

¿Cómo demuestro el cumplimiento NIS2 a los reguladores?

Su paquete de evidencia debe incluir: exportaciones de configuración RBAC que muestren matrices de permisos, informes de aplicación de MFA que confirmen la aplicación global, registros de auditoría representativos con identidad/marca de tiempo/acción/IP de origen, inventario de acceso de terceros con alcance y duración, documentación de política de contraseñas, prueba de capacidad de rotación masiva de credenciales y registros de copia de seguridad/conmutación por error. Toda la evidencia debe ser exportable y estar lista para auditores bajo demanda.

¿Cuál es el cronograma de notificación del Artículo 23?

El Artículo 23 introduce tres etapas: Alerta temprana (24 horas) — notificar al CSIRT nacional que ocurrió un incidente. Notificación de incidente (72 horas) — proporcionar evaluación inicial incluyendo gravedad, impacto y sistemas afectados. Informe final (1 mes) — análisis completo de causa raíz, pasos de remediación y lecciones aprendidas. Las organizaciones sin gestión centralizada de credenciales y rotación automatizada no pueden cumplir el plazo de 24 horas.

Gestión de contraseñas y acceso para pymes: ¿Es suficiente KeePass?

¿Usa KeePass para su equipo? Descubra los riesgos ocultos de KeePass para pymes en 2026 — fallos de sincronización, brechas de cumplimiento y cuándo cambiar a un gestor de contraseñas corporativo.

Passwork BlogAlex Muntyan

¿Es obligatoria la autenticación sin contraseña para el cumplimiento de NIS2?

El Artículo 21(2)(j) de NIS2 exige MFA «cuando sea apropiado» — no sin contraseña por defecto. Conozca lo que realmente requiere la guía de ENISA, cómo evalúan los auditores su implementación y cómo construir una postura de cumplimiento híbrida defendible para 2026.

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

The NIS2 Directive (EU 2022/2555) is no longer a future concern. As of October 2024, organizations across 18 European sectors must demonstrate compliance with mandatory cybersecurity controls. Penalties reach €10 million or 2% of global annual turnover, and board members face personal liability for non-compliance.

At the core of NIS2 is Article 21, which mandates 10 specific security measures. Of these, access management (credential governance, role-based access control, multi-factor authentication, and audit logging) is the most auditable and the most directly linked to breach outcomes.

This guide maps those requirements to practical implementation steps and shows how to generate compliance evidence that regulators expect.

Key takeaways

• Stolen credentials appear in 39% of all breaches — not just at initial access, but as the primary mechanism for lateral movement, privilege escalation, and persistence.
• Third-party involvement has reached 48% in 2026, a 60% year-over-year increase that directly implicates supply chain access governance under NIS2 Article 21(2)(d).
• NIS2 Article 21 mandates 10 specific security measures, all mandatory for every covered entity. The most auditable and breach-critical measures are access control, MFA, and immutable audit logging — these produce exportable compliance evidence regulators expect.
• Access control is where NIS2 compliance becomes measurable. Unlike policy documents, credential governance produces verifiable evidence: audit logs, permission matrices, MFA enforcement reports. Regulators can confirm that controls are actively enforced.
• Article 23 introduces a 24-hour incident reporting obligation. Organizations without centralized credential management, immutable audit trails, and automated rotation capabilities cannot meet this deadline. Bulk password rotation must be executable within hours, not days.
• ENISA specifies three MFA tiers. Tier 1 (phishing-resistant FIDO2/WebAuthn) is mandatory for all privileged accounts. Tier 2 (TOTP) is acceptable for standard users. SMS and email OTPs are explicitly flagged for phase-out and do not meet the minimum threshold.
• Personal liability for board members is unprecedented. Article 20 holds C-suite executives personally accountable for cybersecurity failures, including temporary bans from management roles. This provision has no precedent in NIS1.
• Penalties reach €10 million or 2% of global annual turnover for Essential Entities, with enforcement active as of 2026. National competent authorities across the EU have begun proactive audits. Non-compliance is no longer a future concern.
• On-premise deployment eliminates third-party data custody. Credentials remain inside your network with no external transmission. Audit logs are stored locally and piped directly to your SIEM with no vendor intermediary, guaranteeing audit independence.
• The 5-phase implementation roadmap takes 30–60 days from assessment to audit-ready compliance: pre-deployment assessment, access audit, credential system deployment, NIS2 configuration, and ongoing monitoring. Most organizations can move from fragmented access management to enforcement within this timeline.

Why NIS2 focuses on access management

Access control is where NIS2 compliance becomes measurable. Unlike policy documents or risk assessments, credential governance produces exportable evidence: audit logs, permission matrices, MFA enforcement reports. Regulators can verify that controls are actively enforced.

The threat landscape makes this urgency clear. According to Verizon's 2026 Data Breach Investigations Report, vulnerability exploitation has become the leading initial access vector at 31% of breaches, up from 20% in 2025. However, this headline comparison obscures a more critical finding: stolen credentials appear in 39% of all breaches across the entire attack lifecycle — not just at initial access, but as the primary mechanism for lateral movement, privilege escalation, and persistence.

Once attackers gain entry, credentials become their dominant tool for moving through the infrastructure. Third-party involvement has reached 48% in 2026, up from 30% in 2025 — a 60% increase that directly implicates supply chain access governance under NIS2 Article 21(2)(d). ,

Stolen credentials drive breach expansion — reused, shared, or never revoked when employees leave. NIS2 Article 21 was designed to eliminate this through strict access control, mandatory MFA, and immutable audit logging.

Understanding NIS2 Article 21: The 10 mandatory security measures

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. Here's what each one demands:

• Measure 1: Risk analysis and information system security policies. Organizations must continuously identify and document cybersecurity risks. This translates to credential discovery: mapping all privileged accounts, identifying shared credentials, and documenting which systems hold the highest-risk access.
• Measure 2: Incident handling — prevention, detection, and response. Organizations must have documented procedures for responding to security incidents. For credential-based breaches, this means the ability to rotate compromised passwords in bulk within hours, not days.
• Measure 3: Business continuity, backup management, and disaster recovery. Credentials must remain accessible even when primary systems fail. This requires failover clustering, replication, and tested backup procedures.
• Measure 4: Supply chain security. Organizations must assess and manage the cybersecurity risks posed by direct suppliers and service providers. For credentials, this means isolating third-party access, time-bounding it, and revoking it automatically when contracts end.
• Measure 5: Security in network and information systems acquisition, development, and maintenance. Systems must be built and maintained with security in mind. For credential systems, this means secure development practices and regular penetration testing.
• Measure 6: Policies and procedures to assess the effectiveness of cybersecurity risk-management measures. Organizations must verify that controls actually work. This requires audit trails: proof that access controls are enforced and that every credential action is logged.
• Measure 7: Basic cyber hygiene practices and cybersecurity training. Weak passwords are the most common credential failure. Organizations must enforce password complexity, rotation schedules, and user security awareness.
• Measure 8: Policies and procedures regarding the use of cryptography and encryption. Credentials must be encrypted at rest and in transit. This means AES-256 encryption, TLS for all communications, and zero-knowledge architecture where the server never holds decryption keys.
• Measure 9: Human resources security, access control policies, and asset management. This is the core of NIS2 access governance: every user must have documented access rights, every access change must be logged, and every credential must be revoked when access is no longer needed.
• Measure 10: Use of MFA or continuous authentication solutions. Multi-factor authentication is no longer optional. ENISA's technical guidance specifies three tiers of MFA strength, with phishing-resistant authentication (FIDO2/WebAuthn) mandatory for all privileged accounts.

Quick reference table

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. Get a free demo and see it in action

The 24-hour incident reporting obligation

NIS2 Article 23 introduces a three-stage reporting timeline that fundamentally changes how organizations respond to credential breaches.

• Early Warning (24 hours). Within 24 hours of discovering a significant incident, organizations must notify the national CSIRT. No full assessment required — just confirmation that an incident occurred and whether criminal activity is suspected.
• Incident Notification (72 hours). Provide an initial assessment: severity, impact, indicators of compromise (IoCs), and affected systems. This is where credential breach scope becomes critical. If admin credentials were compromised, the scope is potentially enterprise-wide.
• Final Report (1 month). Full root cause analysis, remediation steps taken, cross-border impact assessment, and lessons learned. This is the document regulators will scrutinize. For credential breaches, it must include proof that all compromised passwords were rotated and that access was revoked for any accounts that should no longer have had access.

Organizations without centralized credential management, immutable audit trails, and automated rotation capabilities cannot meet the 24-hour deadline.

ENISA Technical Guidance: MFA, PAM, and audit logging

The European Union Agency for Cybersecurity (ENISA) published detailed technical implementation guidance for NIS2. For access management, three areas dominate: MFA strength, privileged access management (PAM), and audit logging.

MFA: Three tiers of strength

ENISA classifies MFA into three tiers based on phishing resistance:

1. Strong (Phishing-Resistant). FIDO2, WebAuthn, and hardware security keys. These cannot be intercepted by phishing attacks because they use cryptographic challenge-response protocols. ENISA mandates Tier 1 for all privileged and administrative accounts. No exceptions.
2. Medium. TOTP authenticator apps and push notifications. Acceptable for standard user accounts. Vulnerable to real-time phishing but significantly better than passwords alone.
3. Last Resort (Phase Out). SMS and email one-time passwords. Vulnerable to SIM-swap attacks and interception. ENISA explicitly recommends phasing these out for all regulated environments.

Organizations must document which MFA tier is enforced for each user group. Auditors will verify that all privileged accounts use Tier 1 and that SMS/email OTPs are no longer in use.

Privileged Access Management (PAM)

ENISA specifies four PAM requirements:

1. Separation of duties. Admin accounts must never be used for general tasks like email or browsing. Separate, dedicated accounts required for all privileged operations.
2. Full audit logging. Every privileged action must be logged with user identity, timestamp, source IP, and action taken. Logs must be immutable and tamper-evident.
3. Just-In-Time (JIT) access. Privileges granted on a per-event basis and automatically revoked after use. No standing admin access.
4. Third-party access governance. Vendor access must be scoped, time-limited, and automatically revoked upon contract end or project completion.

Audit logging (ENISA §11.4)

Logs must be:

• Centralized. All credential actions logged to a single, protected system.
• Immutable. No user, including administrators, can modify or delete log entries.
• Exportable. Structured formats (JSON, CSV, Syslog) for SIEM integration and regulatory submission.
• Retained. Minimum retention period defined by the entity's risk assessment (typically 1–3 years).

Incomplete or tamper-able logs will not satisfy ENISA §11.4. Regulators will reject them.

Mapping NIS2 requirements to technical controls

Here's how specific technical controls satisfy Article 21 obligations:

Every control in the table above is built into Passwork's core architecture. You get password security dashboards, immutable audit trails, RBAC, MFA enforcement, and AES-256 encryption out of the box. The result: compliance evidence that regulators expect, not policy documents they have to interpret.

The 5-phase implementation roadmap: From assessment to audit-ready compliance

Moving from fragmented access management to audit-ready NIS2 compliance doesn't require a complete infrastructure rebuild. A structured 5-phase approach takes most organizations from assessment to enforcement within 30–60 days.

Phase 1: Pre-deployment assessment (week 1)

1. Define NIS2 scope boundaries. Which business units, systems, and user groups fall under the directive? Classify your organization as Essential or Important entity and confirm applicable obligations.
2. Assign accountability. Designate a compliance owner with Article 20 accountability — typically the CISO or IT Director. Align IT, security, HR, and legal teams on roles, responsibilities, and escalation paths.
3. Confirm infrastructure readiness. Verify server specifications and network topology for on-premise deployment. Confirm Active Directory or LDAP readiness for automated user provisioning.

Phase 2: Access audit — where you stand today (week 2)

1. Map all privileged accounts. Identify every account with admin access across all systems and infrastructure. Include service accounts and shared credentials — these are your highest-risk credentials.
2. Identify third-party access. Review all active third-party and vendor access. Document scope, duration, and current MFA status. This is where most organizations discover uncontrolled access.
3. Assess current logging. What is being logged today, where, and for how long? Document the gap between current state and ENISA's technical requirements.

Phase 3: Deploying Passwork in your environment (week 3)

1. Install on-premise. Deploy via Docker Compose or bare-metal server (Linux/Windows). Passwork runs entirely within your infrastructure with no external credential transmission.
2. Integrate with identity systems. Connect to Active Directory or LDAP for automated user provisioning. Configure SSO via SAML 2.0 for seamless, auditable authentication.
3. Import and organize credentials. Migrate existing credentials into structured vaults by team, system, and criticality. Define initial vault structure and ownership hierarchy.

Phase 4: Configuring for NIS2 compliance (week 4)

1. Define and enforce RBAC. Apply the least-privilege principle throughout. Every user accesses only the credentials their role requires.
2. Mandate MFA. Enforce Tier 1 (FIDO2) for all privileged accounts. Enforce Tier 2 (TOTP) for all standard users. Document enforcement as audit evidence.
3. Isolate third-party access. Create dedicated, time-bound vaults for vendors and contractors with automatic expiry at contract end.
4. Configure password policies. Enforce complexity rules, rotation schedules, and automatic expiry. Enable full audit trail logging and configure SIEM integration via Syslog.

Phase 5: Ongoing monitoring and reporting (ongoing)

1. Schedule quarterly access reviews. Validate that RBAC assignments remain accurate. Ensure no orphaned access remains after employee departures.
2. Generate automated compliance reports. Demonstrate MFA enforcement, access governance, and control effectiveness. Have exportable evidence packages ready for regulatory submission on demand.
3. Monitor audit logs. Integrate alerts with SIEM for anomalous access patterns. Conduct annual NIS2 readiness assessments against updated ENISA guidance.

The NIS2 compliance checklist

Use this checklist to track your compliance posture across the three critical areas: access management, supply chain security, and incident readiness.

Access control (Article 21(2)(i))

• Map all privileged accounts across all systems and infrastructure
• Implement strict RBAC — every user accesses only credentials their role requires
• Eliminate all shared accounts — replace with individualized access
• Automate identity lifecycle via AD/LDAP — immediate access revocation upon employee exit
• Export permission matrices as auditor-ready evidence

Supply chain (Article 21(2)(d))

• Isolate all third-party access in dedicated, time-bound vaults
• Audit all active vendor credentials — revoke any access no longer operationally justified
• Document vendor access scope, duration, and MFA status for every active third-party credential
• Configure automatic expiry at contract end

MFA (Article 21(2)(j))

• Enforce Tier 1 MFA (FIDO2/WebAuthn) for all administrative accounts
• Enforce Tier 2 MFA (TOTP) for all standard users
• Phase out SMS and email OTPs — both fail ENISA's minimum threshold
• Generate compliance report confirming MFA across all active accounts

Incident readiness (Article 23)

• Verify audit logs provide sufficient detail for 24-hour early warning
• Establish and test bulk credential rotation workflow for post-incident response
• Designate named individual responsible for Article 23 notification
• Prepare exportable evidence packages ready for regulatory submission on demand

Audit logging (ENISA §11.4)

• Centralize and protect audit logs — configure immutable, exportable logging
• Integrate with SIEM via Syslog — ensure no user can modify or delete log entries
• Confirm every entry captures identity, timestamp, action, and source IP
• Generate automated reports covering MFA enforcement, RBAC compliance, and access reviews

Penalties: What non-compliance actually costs

The financial and personal consequences of NIS2 non-compliance are severe:

• For Essential Entities: Up to €10 million or 2% of global annual turnover, whichever is higher. Regulators may also impose temporary operational restrictions.
• For Important Entities: Up to €7 million or 1.4% of global annual turnover, whichever is higher. Reactive supervision does not mean lower risk.
• Personal liability for management (Article 20). Board members and C-suite executives can be held personally liable for cybersecurity failures. Competent authorities may impose temporary bans from management roles. This provision has no precedent in NIS1, and it fundamentally changes how leadership must approach compliance.

As of 2026, national competent authorities across the EU have begun proactive audits of Essential Entities. The enforcement phase is active.

Building your NIS2 evidence package

Regulators want proof. Your compliance evidence package must include:

1. RBAC configuration export. Permission matrices showing which users/roles have access to which credentials.
2. MFA enforcement report. System configuration confirming MFA is globally enforced, with MFA method per user.
3. Audit log samples. Representative logs showing identity, timestamp, action, and source IP for credential access and modifications.
4. Third-party access inventory. Documented scope, duration, and MFA status for every active vendor credential.
5. Password policy documentation. Enforced complexity rules, rotation schedules, and automatic expiry settings.
6. Incident response capability. Proof that bulk credential rotation can be executed within hours.
7. Backup and failover records. Evidence that credentials remain accessible during system failures.

The On-Premise advantage for NIS2 compliance

Organizations often ask: why does NIS2 emphasize on-premise deployment? The answer is data sovereignty and audit independence.

1. Data stays where you govern it. All credentials remain inside your network with no external transmission, no third-party custody, and no jurisdictional ambiguity.
2. Audit logs you own and control. Logs are stored locally, pipe directly to your SIEM via Syslog with no vendor intermediary, no restrictions, and no data leaving your perimeter.
3. No third-party data dependency. Because the credential system runs within your infrastructure, it holds no custody over your credentials, eliminating the third-party data dependency that triggers supply chain assessment requirements under Article 21(2)(d).
4. Compliance evidence on your terms. Every report, log, and configuration export is generated from your own infrastructure and available on demand for auditors, without dependency on a vendor's support team or data retention policy.
5. Isolated environments supported. Air-gapped deployment for OT/ICS infrastructures with zero network exposure. Credentials remain accessible even where internet connectivity is prohibited by design.

Conclusion: From compliance to competitive advantage

NIS2 is a mandate to secure the infrastructure that European society depends on. Credential-based attack vectors dominate the 2026 threat landscape — and they are precisely what Article 21 was designed to address.

Organizations that centralize credential governance, enforce phishing-resistant MFA, and maintain immutable audit trails do more than pass the audit. They eliminate their most significant attack surface. The 5-phase implementation roadmap in this guide takes you from fragmented access management to audit-ready compliance within 30–60 days.

The technical foundation for that outcome requires three elements: on-premise deployment that guarantees data sovereignty, RBAC that enforces least privilege at scale, and audit logs that give regulators exactly the evidence they need.

Passwork delivers all 9 technical controls in this table: password security dashboards, bulk rotation, failover clustering, on-premise deployment, immutable audit trails, policy enforcement, AES-256 encryption, RBAC, and MFA. Get a free demo and see it in action.

Ready to move from compliance planning to implementation? Download the full NIS2 compliance guide for detailed technical mapping, sector-specific guidance, and a customizable compliance checklist.

Frequently asked questions

What does NIS2 Article 21 actually require from my organization?

Article 21 mandates 10 specific security measures: risk analysis, incident handling, business continuity, supply chain security, secure development, control effectiveness verification, cyber hygiene, encryption, access control, and MFA. All 10 are mandatory for every covered entity. The most auditable and breach-critical measures are access control (Article 21(2)(i)), MFA (Article 21(2)(j)), and audit logging (Article 21(2)(f)).

Who is required to comply with NIS2?

Organizations in 18 European sectors classified as Essential Entities must comply immediately. These include energy, transport, water, health, digital infrastructure, and public administration. Important Entities (financial services, food supply, manufacturing, chemicals, space) have until October 2025 for full compliance. Non-EU organizations operating in these sectors within EU jurisdiction are also in scope.

What are the penalties for non-compliance?

Essential Entities face fines up to €10 million or 2% of global annual turnover, whichever is higher. Important Entities face up to €7 million or 1.4% of global annual turnover. Board members and C-suite executives face personal liability under Article 20, including temporary bans from management roles. Enforcement is active as of 2026.

How long does it take to implement NIS2 compliance for access management?

Most organizations move from assessment to audit-ready compliance within 30–60 days using a structured 5-phase approach: pre-deployment assessment (week 1), access audit (week 2), credential system deployment (week 3), NIS2 configuration (week 4), and ongoing monitoring. The timeline depends on infrastructure complexity and the volume of existing credentials to migrate.

What is the difference between Essential and Important Entities under NIS2?

Essential Entities operate critical infrastructure (energy, transport, water, health, digital infrastructure, public administration). Important Entities provide essential services (financial services, food supply, manufacturing, chemicals, space). Essential Entities face higher penalties (€10 million vs. €7 million) and stricter enforcement timelines. Both must implement all 10 Article 21 measures.

Why does NIS2 emphasize on-premise credential management?

On-premise deployment guarantees data sovereignty: credentials remain inside your network with no external transmission or third-party custody. Audit logs are stored locally and piped directly to your SIEM with no vendor intermediary. This eliminates the third-party data dependency that triggers supply chain assessment requirements under Article 21(2)(d) and gives you complete audit independence.

What MFA tier does NIS2 require?

ENISA specifies three tiers: Tier 1 (phishing-resistant) — FIDO2, WebAuthn, hardware security keys — is mandatory for all privileged and administrative accounts. Tier 2 (TOTP authenticator apps, push notifications) is acceptable for standard users. SMS and email OTPs are explicitly flagged for phase-out and do not meet ENISA's minimum threshold.

How do I prove NIS2 compliance to regulators?

Your evidence package must include: RBAC configuration exports showing permission matrices, MFA enforcement reports confirming global enforcement, representative audit logs with identity/timestamp/action/source IP, third-party access inventory with scope and duration, password policy documentation, proof of bulk credential rotation capability, and backup/failover records. All evidence must be exportable and auditor-ready on demand.

What is the Article 23 reporting timeline?

Article 23 introduces three stages: Early Warning (24 hours) — notify the national CSIRT that an incident occurred. Incident Notification (72 hours) — provide initial assessment including severity, impact, and affected systems. Final Report (1 month) — full root cause analysis, remediation steps, and lessons learned. Organizations without centralized credential management and automated rotation cannot meet the 24-hour deadline.

Password and access management for SMBs: Is KeePass enough?

Using KeePass for your team? Discover the hidden risks of KeePass for SMBs in 2026 — sync failures, compliance gaps, and when to switch to a corporate password manager.

Passwork BlogAlex Muntyan

Is NIS2 passwordless authentication required for compliance?

NIS2 Article 21(2)(j) mandates MFA “where appropriate” — not passwordless by default. Learn what ENISA guidance actually requires, how auditors evaluate your implementation, and how to build a defensible hybrid compliance posture for 2026.

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

Todos os administradores de TI que utilizam o KeePass numa equipa contam a mesma história. Começa com um ficheiro .kdbx partilhado numa unidade de rede. Depois, alguém não consegue abri-lo porque um colega o tem bloqueado. Depois, um administrador de sistemas júnior guarda o ficheiro por cima de uma alteração que outra pessoa fez uma hora antes. Depois, um colaborador sai e ninguém tem bem a certeza de a que palavras-passe tinha acesso.

O KeePass é uma ferramenta realmente excelente, mas apenas para uma pessoa. A partir do momento em que é colocado à frente de uma equipa, já não se gerem palavras-passe: gere-se um único ficheiro.

O fascínio do KeePass para as pequenas empresas

O KeePass atrai as PME por três razões totalmente racionais: não tem custos, armazena os dados localmente e foi auditado pela comunidade open source durante mais de duas décadas. Para uma pequena empresa de cinco pessoas, sem obrigações de conformidade e com um único generalista de TI, estas são vantagens reais.

A cifragem é sólida. O KeePass 2.x utiliza AES-256 por predefinição, com suporte opcional para ChaCha20, mais rápido em hardware móvel sem aceleração de hardware para AES. O formato .kdbx está bem documentado, é portátil e não vai desaparecer.

O KeePass continua a ter peso na curva de adoção entre consumidores, sobretudo entre utilizadores com conhecimentos técnicos que desconfiam dos serviços cloud. No entanto, o segmento empresarial (em que as auditorias de conformidade, o acesso multiequipa e o registo de auditoria são obrigatórios) migrou quase por completo para soluções concebidas de raiz para o efeito.

A «armadilha da escala» do KeePass: Quando o gratuito se torna caro

O KeePass foi concebido como aplicação para um único utilizador. A documentação sobre vários utilizadores reconhece-o de forma direta: a página de ajuda oficial do KeePass sobre vários utilizadores descreve soluções alternativas, não funcionalidades nativas. Quando se coloca um ficheiro .kdbx numa partilha de rede e se dá acesso a cinco pessoas, constrói-se um sistema que acabará por falhar. Eis exatamente como.

O problema do «last-writer-wins»

O KeePass não tem motor de sincronização em tempo real. Quando dois utilizadores abrem em simultâneo o mesmo ficheiro de base de dados, cada um mantém uma cópia local em memória. Quando o utilizador A guarda, o ficheiro é atualizado. Quando o utilizador B guarda trinta segundos depois, a sua versão substitui por completo as alterações do utilizador A. Não existe fusão, deteção de conflitos nem aviso.

O KeePass oferece uma função manual «Synchronize» (sincronizar) que permite fundir dois ficheiros .kdbx, mas exige uma ação deliberada do utilizador e só funciona se ambas as versões estiverem disponíveis. Numa partilha de rede em que o ficheiro é substituído ao guardar, essa segunda versão já não existe.

Acesso tudo ou nada

O KeePass tem uma única palavra-passe mestra (ou ficheiro de chave) por base de dados. Todos os que precisam de acesso recebem a mesma chave. Não existe o conceito de «este utilizador pode ler as credenciais dos servidores cloud, mas não as palavras-passe das bases de dados». É possível criar ficheiros .kdbx separados para diferentes níveis de acesso, mas passam a gerir-se vários ficheiros e vários processos de sincronização, e continua a não existir registo de auditoria.

RBAC (controlo de acesso baseado em funções), a capacidade de definir o que cada utilizador ou grupo pode ver e fazer, simplesmente não existe na arquitetura do KeePass. É uma opção de conceção de uma ferramenta para um único utilizador.

A saída de colaboradores

Quando um colaborador com acesso à base de dados partilhada do KeePass sai da organização, a resposta de segurança correta é rodar todas as credenciais que poderia ter visto. Todas. Como não existe registo do que consultou, não é possível delimitar a rotação: tem de se assumir o pior cenário.

Numa base de dados com 200 entradas, isso representa um dia inteiro de trabalho. Numa base de dados com 800 entradas distribuídas por sistemas de produção, ferramentas SaaS e ambientes de clientes, é um incidente de vários dias. E repete-se de cada vez que alguém sai.

Os cofres baseados em funções do Passwork permitem revogar o acesso de um colaborador que sai com uma única ação. Ver como funciona

Segurança vs. conformidade: O panorama regulamentar de 2026

A cifragem do KeePass é realmente sólida. O AES-256 com uma palavra-passe mestra bem escolhida não é o ponto fraco. O ponto fraco é o KeePass não produzir qualquer evidência do que aconteceu dentro da base de dados e, em 2026, é essa evidência que os auditores pedem.

O que exige o artigo 32.º do RGPD

O artigo 32.º do RGPD exige «medidas técnicas e organizativas adequadas» para garantir um nível de segurança adequado ao risco. No caso da gestão de credenciais, a interpretação prática do artigo 32.º inclui cifragem em repouso, controlos de acesso e, de forma determinante, a capacidade de demonstrar que os controlos de acesso funcionam. Esta última parte exige logs.

Uma base de dados do KeePass não indica quem a abriu, quando, a partir de que máquina, nem o que consultou. Se uma autoridade reguladora exigir a demonstração de que o acesso às credenciais de dados pessoais foi devidamente restringido, um ficheiro .kdbx não constitui uma resposta.

Diretiva NIS2: Controlo de acessos e resposta a incidentes

A Diretiva NIS2 (em vigor desde outubro de 2024 para organizações da UE) exige que os operadores de serviços essenciais e as entidades importantes apliquem «controlo de acesso avançado» e mantenham logs detalhados do acesso a ativos críticos. No que respeita à gestão de credenciais, isto significa:

• Controlo de acesso baseado em funções (RBAC) com autenticação por utilizador
• Logs de auditoria imutáveis de todos os acessos a credenciais
• Capacidade de revogar o acesso imediatamente após a saída de um colaborador

Um ficheiro KeePass partilhado com uma única palavra-passe mestra viola os três requisitos. Substituir a chave de toda a base de dados quando alguém sai não é «revogação imediata»: é uma solução alternativa que gera sobrecarga administrativa e aumenta o risco de erro humano.

ISO 27001:2022 e requisitos de controlo de acesso

Os controlos A.8.2 (controlo de acesso) e A.8.15 (registo) do Anexo A da ISO 27001 exigem que as organizações apliquem controlos que restrinjam o acesso à informação a utilizadores autorizados e mantenham registos desse acesso. No caso dos repositórios de credenciais, isto traduz-se em:

• Permissões de acesso granulares associadas às funções profissionais
• Registos de auditoria que mostrem quem acedeu a quê, quando e a partir de onde
• Aplicação automatizada do princípio do menor privilégio

O KeePass não oferece nenhuma destas capacidades. Uma base de dados partilhada entre os membros da equipa com uma única palavra-passe é o oposto do menor privilégio: é o privilégio máximo para todos.

PCI DSS 4.0: Proteção de dados de cartões de pagamento

Se a organização trata dados de cartões de pagamento, o requisito 7.1 do PCI DSS 4.0 exige que o acesso aos dados dos titulares de cartões seja restringido ao pessoal com necessidade legítima de negócio. O requisito 10.2.1 exige o registo de todos os acessos aos sistemas que contêm dados de titulares de cartões, incluindo o ID de utilizador, a data, a hora e a natureza do acesso.

Uma base de dados do KeePass que armazene chaves de API de gateways de pagamento ou credenciais de bases de dados não consegue satisfazer estes requisitos. Não há autenticação por utilizador, nem registo de auditoria, nem forma de provar a um auditor PCI que o acesso foi restringido a pessoal autorizado.

SOC 2 Tipo II e CC6.1

O critério CC6.1 dos Trust Services Criteria do SOC 2 exige que o acesso lógico a sistemas que armazenam dados sensíveis seja restringido a utilizadores autorizados e que esse acesso fique registado. Uma base de dados KeePass partilhada com uma única palavra-passe mestra falha ambas as condições. Não há autenticação por utilizador e não há log.

Este risco não é teórico. Os auditores pedem logs de acesso durante as avaliações SOC 2 Tipo II. «Utilizamos o KeePass» encerra essa conversa da pior forma.

NIST SP 800-63B (revisão 4)

NIST SP 800-63B, finalizada em agosto de 2025, recomenda um comprimento mínimo de 15 carateres para segredos memorizados e desaconselha explicitamente a rotação periódica obrigatória, em favor da rotação em caso de violação. O KeePass pode armazenar palavras-passe conformes, mas não consegue aplicar a política, reportar a conformidade nem provar a um auditor que a política foi cumprida.

A dimensão da ameaça

Os números tornam concreto o argumento da conformidade. Segundo o Cost of a Data Breach Reportda IBM de 2025, o custo médio de uma violação de dados em empresas com menos de 500 colaboradores atingiu 3,31 milhões de dólares. O comprometimento de credenciais figura sistematicamente entre os principais vetores de acesso inicial. Uma violação de conformidade somada à violação de dados agrava o dano financeiro através de coimas regulamentares e custos de remediação.

A curva de maturidade da segurança de palavras-passe nas PME

A maioria das PME passa por três fases reconhecíveis. Dar nome a esta progressão ajuda as equipas a identificar onde se encontram e como é, na prática, o passo seguinte.

• Fase 1: Excel/documento partilhado. Credenciais numa folha de cálculo, muitas vezes numa unidade partilhada ou numa cadeia de e-mails. Sem cifragem. Sem controlo de acesso. Totalmente auditável, da pior forma possível: qualquer pessoa com o ficheiro vê tudo.
• Fase 2: KeePass. Ficheiro cifrado, criptografia forte, custo zero. Uma melhoria genuína face à Fase 1. Adequado para indivíduos e equipas muito pequenas sem requisitos de conformidade. Deixa de funcionar com mais de cinco utilizadores, sob auditoria ou quando alguém sai.
• Fase 3: Cofre empresarial. Gestão de credenciais multiutilizador concebida para o efeito, com RBAC, integração com AD/LDAP, logs de auditoria por utilizador, aplicação obrigatória da MFA e saída automatizada de colaboradores. É aqui que devem estar as equipas com obrigações de conformidade, mais de dez utilizadores ou quaisquer requisitos de segurança exigidos pelos clientes.

A armadilha é permanecer na Fase 2 para além do ponto em que se adequa. O custo desse atraso é a sobrecarga administrativa, a exposição a incidentes e as constatações de auditoria.

Teste de esforço do KeePass em 5 pontos para a empresa

Aplique estas cinco perguntas à configuração atual. Cada «sim» é um sinal de que o KeePass está a criar um risco que a equipa pode não ter contabilizado.

1. Mais de 5 utilizadores acedem à base de dados partilhada?
   Com mais de cinco utilizadores em simultâneo, os conflitos de sincronização tornam-se quase diários. O problema do «last-writer-wins» escala linearmente com a dimensão da equipa.
2. É possível provar quem acedeu a uma credencial específica e quando?
   Se um cliente perguntar quais dos colaboradores acederam às credenciais dos seus sistemas na terça-feira passada, é possível responder? O KeePass não consegue produzir esse registo. Um cofre empresarial com registo de auditoria consegue.
3. A base de dados está guardada numa unidade partilhada, no Dropbox ou em algo semelhante?
   As ferramentas de sincronização na cloud, como o Dropbox, acrescentam a sua própria resolução de conflitos por cima da do KeePass, o que pode levar a existirem várias versões do ficheiro .kdbx e a nenhuma forma fiável de saber qual é a atual. As partilhas de rede têm o problema de bloqueio de ficheiros descrito acima.
4. Quanto tempo demora a revogar por completo o acesso de um antigo colaborador?
   Se a resposta for «alteramos a palavra-passe mestra e depois rodamos tudo o que possa ter visto», trata-se de um incidente de várias horas que se repete de cada vez que alguém sai. Com controlos de acesso por utilizador, a revogação é uma única ação.
5. A MFA protege o próprio cofre?
   O KeePass permite usar ficheiros de chave como segundo fator, mas distribuir e gerir esses ficheiros por uma equipa é, por si só, um problema operacional. A integração nativa de MFA (TOTP, chaves de hardware, SSO) exige uma ferramenta concebida para o efeito.

Se a resposta for «não» às perguntas 2 e 5, ou «sim» às perguntas 1, 3 e 4, a equipa já ultrapassou a capacidade do KeePass.

Como gerir o acesso às credenciais quando a equipa ultrapassa as cinco pessoas? O Passwork permite a gestão de credenciais multiequipa com RBAC, registo de auditoria e sincronização em tempo real, sem a sobrecarga operacional. Experimentar o Passwork grátis

Para além do KeePass: Escolher uma solução empresarial de gestão de acessos

Os critérios para um gestor de credenciais de nível empresarial não são complicados, mas tornam-se inegociáveis a partir do momento em que se opera em qualquer escala ou sob qualquer quadro de conformidade.

Cofres partilhados com permissões granulares

Cada equipa ou projeto deve ter o seu próprio cofre. Os utilizadores individuais têm acesso aos cofres de que necessitam, com o nível de permissão necessário (leitura, escrita, administração). Quando a função de alguém muda, atualiza-se a sua pertença aos cofres, e não a palavra-passe mestra. Este é o controlo de acesso baseado em funções (RBAC), a base da conformidade. O KeePass não tem equivalente.

Passwork atribui permissões a grupos, pelo que, quando um programador entra na equipa de DevOps, herda automaticamente o acesso da equipa aos cofres. Quando sai, o acesso é revogado uma única vez.

RBAC associado ao diretório

A integração com AD/LDAP significa que o aprovisionamento e o desaprovisionamento de utilizadores ocorrem automaticamente. Quando o administrador encerra uma conta no Active Directory, o acesso aos cofres desaparece com ela. Sem passos manuais, sem lacunas. O Passwork integra-se nativamente com o Active Directory e o LDAP, pelo que o acesso às credenciais acompanha a estrutura organizacional, e não o contrário.

Logs de auditoria por utilizador

Cada visualização, cópia, edição e partilha de credenciais deve ser registada com carimbo de data e hora e identidade do utilizador. Este é o registo que satisfaz o SOC 2 CC6.1 e sustenta a responsabilização prevista no artigo 32.º do RGPD. O KeePass não produz logs.

O Passwork mantém um registo de auditoria completo de todas as ações, exportável para revisões de conformidade e investigações de incidentes.

Aplicação obrigatória da MFA ao nível do cofre

Não é opcional nem uma preferência de cada utilizador: é aplicada por política, com suporte para TOTP, tokens de hardware e SSO SAML. O KeePass admite ficheiros de chave, o que não é MFA. O Passwork aplica a MFA ao nível do cofre, com vários métodos de autenticação associados ao fornecedor de identidade.

Preenchimento automático e integração com navegadores

Um gestor de credenciais moderno integra-se com navegadores e ferramentas de CLI para preencher automaticamente palavras-passe e injetar segredos em pipelines de implementação. O KeePass tem plugins para navegadores, mas são mantidos pela comunidade e não têm o modelo de segurança de um cofre centralizado. O Passwork disponibiliza extensões de navegador e ferramentas de CLI nativas que obtêm credenciais a pedido a partir do cofre, com registo de auditoria completo de cada ação de preenchimento automático.

Arquitetura zero-knowledge

Os dados das credenciais devem ser cifrados do lado do cliente antes de chegarem ao servidor. Isto significa que o servidor (autoalojado ou na cloud) não consegue decifrar as credenciais. É uma garantia, não uma promessa. O KeePass cifra localmente, mas não oferece colaboração em equipa sem partilha manual de ficheiros. O Passwork utiliza cifragem AES-256 do lado do cliente com arquitetura zero-knowledge: as credenciais são cifradas antes da transmissão, armazenadas cifradas no servidor e decifradas apenas em clientes autorizados.

Autoalojado ou na cloud, à escolha da organização

Algumas PME têm razões regulamentares ou contratuais para manter os dados de credenciais nas próprias instalações. Uma ferramenta que ofereça autoalojamento genuíno proporciona o controlo que o KeePass oferece, sem as limitações operacionais. O Passwork está disponível como gestor de palavras-passe e segredos na cloud e como implementação autoalojada na infraestrutura própria, com cifragem AES-256 completa e arquitetura zero-knowledge. Os dados nunca saem do controlo da organização.

KeePass vs. Passwork: Comparação de funcionalidades

A diferença é arquitetónica. Quando a equipa ultrapassa as cinco pessoas, o atrito operacional do KeePass torna-se real. A rotação de credenciais exige substituir a chave de toda a base de dados. A saída de um colaborador obriga todos a alterar a palavra-passe mestra. O controlo de acesso é binário: ou se tem a palavra-passe mestra, ou não. Passwork elimina esse atrito: permissões granulares, saída automatizada de colaboradores, registos de auditoria por utilizador e sincronização em tempo real sem conflitos.

Se a organização está sujeita a requisitos de conformidade (RGPD, SOC 2, NIS2, ISO 27001, PCI DSS), a diferença acentua-se. Uma base de dados KeePass partilhada reprova em todas as auditorias. O Passwork, com RBAC, registo de auditoria, integração com AD e cifragem zero-knowledge, cumpre os requisitos de conformidade sem criar sobrecarga administrativa.

Conclusão

O KeePass é um ponto de partida. Para um administrador isolado ou uma equipa de duas pessoas sem requisitos de auditoria externa, cumpre a sua função. Para qualquer equipa acima desse limiar, cria mais risco do que elimina.

A dívida administrativa acumula-se em silêncio: conflitos de sincronização que custam uma hora aqui, uma rotação por saída de colaborador que custa um dia ali, uma constatação de auditoria que custa um trimestre. Nada disto aparece na fatura do KeePass, porque não há fatura. Mas o custo é real.

O passo seguinte é simples: mapear o inventário atual de credenciais, identificar que equipas partilham o acesso a que sistemas e avaliar se a ferramenta atual consegue dizer quem tem acesso a quê. Se não consegue, a resposta está dada.

Se a equipa já ultrapassou o KeePass, o Passwork foi concebido precisamente para este momento. Oferece permissões granulares, sincronização em tempo real, logs de auditoria por utilizador, integração com AD, aplicação obrigatória da MFA e cifragem zero-knowledge, sem a dívida operacional de gerir palavras-passe mestras partilhadas e rotações manuais de credenciais. Experimentar o Passwork grátis

Perguntas frequentes

O KeePass é seguro para uso empresarial?

O KeePass utiliza cifragem AES-256 e é de código aberto, com um longo histórico de segurança, o que o torna criptograficamente sólido. Para uso empresarial, o risco de segurança está na ausência de logs de auditoria, de controlos de acesso granulares e de aplicação obrigatória da MFA. Estas lacunas criam exposição a problemas de conformidade ao abrigo do artigo 32.º do RGPD e do SOC 2 CC6.1.

Podem vários utilizadores partilhar uma base de dados KeePass?

Sim, mas com limitações significativas. O KeePass não tem motor de sincronização em tempo real. Quando dois utilizadores editam o mesmo ficheiro .kdbx em simultâneo numa partilha de rede, a última gravação substitui a anterior, sem fusão nem aviso. A própria documentação do KeePass descreve esta situação como uma limitação conhecida que exige soluções manuais.

Qual é a principal diferença entre o KeePass e um gestor de palavras-passe empresarial?

A diferença essencial está na arquitetura de acesso. O KeePass utiliza uma única palavra-passe mestra partilhada por todos os utilizadores: não existem contas individuais, permissões por utilizador nem registos de atividade. Um gestor de palavras-passe empresarial atribui a cada utilizador a sua própria sessão autenticada, aplica acesso baseado em funções a cofres específicos e regista cada interação com credenciais.

O KeePass é compatível com o Active Directory ou o LDAP?

Não. O KeePass não tem integração nativa com AD nem LDAP. O aprovisionamento e o desaprovisionamento de utilizadores são totalmente manuais. Em contraste, os gestores de credenciais de nível empresarial integram-se com AD/LDAP, de modo que os direitos de acesso acompanham automaticamente a pertença a grupos do diretório.

Porque é que o KeePassreprova nas auditorias de conformidade?

O KeePass não consegue produzir evidência de quem acedeu a que credenciais e quando. Os auditores de SOC 2 Tipo II exigem logs de acesso ao abrigo do CC6.1. O artigo 32.º do RGPD exige controlos de acesso demonstráveis. Um ficheiro .kdbx com uma palavra-passe mestra partilhada não satisfaz nenhum dos requisitos, por mais forte que seja a cifragem.

Quando deve uma PME passar do KeePass para um gestor de palavras-passe empresarial?

O limiar prático são cinco ou mais utilizadores, qualquer obrigação de conformidade (SOC 2, RGPD, HIPAA, ISO 27001) ou qualquer situação em que seja necessário provar o histórico de acessos. Se a saída de um colaborador obriga a rodar credenciais em vez de revogar uma conta de utilizador, é um sinal claro de que a ferramenta atual não é adequada ao fim em causa.

O Passwork conquista o Top Performer Spring 2026 na SourceForge

O Passwork foi distinguido como Top Performer Spring 2026 pela 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, com uma pontuação perfeita de 5,0 em suporte.

Passwork BlogAlex Muntyan

Ciclo de vida da rotação de segredos: Da criação à revogação

A rotação de segredos falha quando é tratada como uma tarefa agendada e não como um ciclo de vida. Este guia abrange as sete fases, desde a criação e a atribuição de responsabilidade até à rotação segura, à revogação de emergência e à evidência de auditoria.

Passwork BlogAlex Muntyan

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

Clusters de GPU, listas de palavras assistidas por IA, botnets com 2,8 milhões de dispositivos. Os ataques de força bruta ganharam escala. Este guia aborda seis variantes de ataque, casos reais de 2025 e uma estratégia de defesa em camadas que a equipa pode implementar hoje.

Passwork BlogAlex Muntyan