NIS2 compliance: Fixing IAM and access control before the 2026 audit

The NIS2 Directive places direct obligations on organizations across supply chain risk management, incident reporting, and board-level accountability. October brings a new wave of legally binding deadlines across the EU, as member states move from transposition into enforcement. In Austria, the national implementation law enters into force once adopted; in Poland, mandatory self-registration closes on a fixed date set by the national authority.

Broader NIS2 non-compliance exposes essential entities to fines up to €10 million or 2% of global turnover, important entities to up to €7 million or 1.4%, and management bodies to personal liability, including temporary bans from executive roles.

Most organizations know they need to comply. The harder question is where to start without burning out the team before the first audit.

Companies can’t boil the ocean and tackle everything at once. The practical path is to identify controls that are fast to implement, generate immediate auditable evidence, and close the attack vectors that matter most.

Access management and credential hygiene fit all three criteria. They won’t cover every NIS2 requirement, but they’ll get you further, faster, than almost any other single investment.

Why credentials are still the chokepoint

The 2026 Verizon Data Breach Investigations Report found that vulnerability exploitation overtook stolen credentials as the top single initial access vector, accounting for 31% of breaches. But deprioritizing credential controls on that basis would be the wrong call.

The DBIR’s own data tells a different story when the focus shifts past the initial access frame. Credential abuse measured across the full attack chain appears in 39% of all breaches. Verizon explicitly identifies it as a “legitimate mitigation target chokepoint.” Credentials don’t just open the front door; they’re what attackers use to move through the building once they’re inside.

Compare the implementation timelines of two NIS2 Article 21 requirements:

• Supply chain risk management (Art. 21(2)(d)) — 6–12 months
• Access control enforcement (Art. 21(2)(i)) — 2–4 weeks

Enforcing a fine-grained password policy across Active Directory, migrating shared credentials into a managed vault, and enabling phishing-resistant MFA for privileged accounts is a 2–4-week project for a competent team. The ROI on compliance effort is not close.

Three access management gaps that fail pre-audits

1. Unmanaged service accounts and API keys

Most NIS2 access management discussions focus on human users. Auditors increasingly don’t. Service accounts, API keys, database connection strings, and deployment tokens are non-human identities and they’re routinely unmanaged in ways that would be unacceptable for any human account.

A typical mid-size organization has more service accounts than human accounts. Most share passwords have never been rotated, and have no documented owner. These credentials live in .env files, CI/CD pipeline configurations, and shared drives, exactly the places attackers look after initial access.

Article 21(2)(i) requires access control policies to cover all accounts with access to network and information systems. “All accounts” includes service accounts. If you can’t enumerate them, you can’t control them, and you can’t prove control to an auditor.

The fix starts with inventory: pull every service account from AD, every API key from your secrets store (or from the config files where they’re currently hardcoded) and get them into a managed system with rotation schedules and documented owners.

2. Dormant accounts and broken offboarding

A dormant account exists, has valid credentials, and belongs to someone who no longer needs access: a former employee, a contractor whose engagement ended, a vendor whose project closed six months ago. These accounts are a direct audit failure point under Article 21(2)(i), which requires access control policies to include lifecycle management.

The offboarding failure is almost never malicious. It’s procedural. HR closes the ticket, IT disables the Active Directory account, and nobody checks whether that person also had direct database access, a VPN certificate, an AWS IAM user, or SSH keys on three production servers. Each of those is a separate credential that needs to be revoked. In most organizations, no single system tracks all of them.

Access reviews must be documented and exportable. Auditors want reports with a clear review history, not email chains.

3. Missing phishing-resistant MFA

Article 21(2)(j) requires MFA “where appropriate.” ENISA’s guidance and the broader regulatory direction make clear that “appropriate” covers all privileged access and all remote access to critical systems. SMS OTP is no longer sufficient for these contexts.

NIST SP 800-63B (section 5.2.10) explicitly classifies SMS-based OTP as a restricted authenticator, citing SIM swapping and SS7 interception risks. Phishing-resistant MFA, FIDO2/WebAuthn, hardware security keys, or certificate-based authentication, is the standard that holds up under scrutiny.

Many organizations have deployed MFA broadly but still allow exceptions for legacy systems, shared accounts, and service accounts. Those exceptions attract auditor scrutiny and require both technical controls and documented approval processes.

A single point of control

All three gaps share a common thread: the absence of a single system that tracks credentials, enforces access policies, and produces exportable evidence. Passwork addresses this directly:

• Service account passwords, API keys, and certificates stored in a self-hosted vault with per-secret ownership records and rotation schedules;
• RBAC and AD/LDAP integration for lifecycle management;
• WebAuthn and hardware security key support for phishing-resistant MFA on vault access.
• The audit log records every action with timestamps, so the quarterly access review becomes a report export, not a manual exercise.

The evidence problem

Having a control and proving a control are two different things. This is where most organizations fail pre-audits: not because the controls don’t exist, but because the evidence doesn’t.

NIS2 Article 32 gives competent authorities the right to request documentation of implemented security measures. Documentation is the policy text, the technical control enforcing it, and a log showing the control has been active and has generated events.

For credential and access management, auditors expect:

• Access control policy — written, versioned, approved by management
• Technical enforcement evidence — AD fine-grained password policy settings, MFA enrollment reports
• Access review records — who reviewed, when, what was revoked
• Privileged account inventory with ownership documentation
• Credential rotation logs for service accounts and API keys
• Offboarding records with completion timestamps

If it isn’t logged and exportable, it doesn’t exist from an auditor’s perspective. The goal is a system that generates the evidence automatically as a byproduct of normal operations.

Five steps to credential compliance

Step 1. Inventory everything.

Map what exists: shared accounts, service accounts, API keys, and any credentials stored outside a managed system: spreadsheets, email, .env files. This inventory is your baseline and your first evidence artifact.

Step 2. Deploy a centralized credential vault.

Choose a solution that supports AES-256 encryption, RBAC, and AD/LDAP integration. Configure vault structure to mirror your organizational hierarchy. A self-hosted deployment gives you data sovereignty and satisfies internal security policies that prohibit storing credentials in third-party cloud services. Passwork is one example of a platform designed specifically for this deployment model — self-hosted, AES-256 encrypted, with RBAC and AD/LDAP integration out of the box.

Step 3. Enforce MFA and least-privilege access.

Enable MFA on all vault access from day one. Assign permissions at the role level. Apply the principle of least privilege: each user and service account gets access only to what their function requires. Document the role matrix, this is your Article 21(2)(i) access control evidence.

Step 4. Migrate unmanaged secrets into the vault.

Move API keys, database credentials, certificates, and service account passwords into the vault. Retire the .env files and shared spreadsheets. Set rotation policies where feasible.

Step 5. Configure audit logging and schedule regular reviews.

Enable full audit logging and export a compliance report immediately after deployment. Schedule quarterly access reviews: dormant accounts, over-privileged roles, credentials not accessed in 90+ days. Each review cycle produces a dated evidence artifact demonstrating ongoing compliance, exactly what Article 32 enforcement requires.

Where to start

The organizations that will struggle with NIS2 audits are not the ones with imperfect security. They’re the ones with no evidence. IBM’s 2026 Cost of a Data Breach Report puts the global average breach cost at $4.99 million, and the organizations containing breaches faster are consistently the ones with visibility into where their credentials are.

The harder NIS2 workstreams, supply chain risk, incident response, board-level governance, need to run in parallel. But credential management is where you get your first provable win.

Start with the inventory:

1. Get service accounts under management.
2. Close the dormant account backlog.
3. Enforce phishing-resistant MFA on privileged and remote access.
4. Build the logging infrastructure that turns these controls into exportable evidence.

That work can be operational in under 30 days, and it closes the credential chokepoint present in 39% of all breaches across the full attack chain.

Passwork is a self-hosted password and secrets manager built for enterprise environments — AES-256 encryption, RBAC, AD/LDAP integration, and exportable audit logs included.

Learn how it maps to NIS2 Article 21 requirements.