Most NIS2 compliance failures won't occur during the audit. They'll happen in the 90 days before it, when your team realizes you can't prove the controls you thought you had.
The issue isn't a lack of understanding about credential management. It's a misunderstanding of where the risk is concentrated. You're securing employee passwords while service accounts run unchecked. You're enforcing MFA on email while privileged database access accepts any valid credential. You're tracking user offboarding while API keys from 2019 remain hardcoded in production configs.
These aren't exceptions; they're common. Under NIS2 Article 21(2)(i), which requires documented access control policies covering all accounts with system access, each one is an audit failure waiting to be documented.
Here's what keeps breaking, why it breaks, and how to fix it before enforcement intensifies.
Why These Mistakes Persist
Credential management failures during NIS2 preparation often stem from a gap between human-focused security and the actual attack surface.
Your security program evolved around human users because they were the primary threat vector. You built controls for password resets, phishing training, and user lifecycle management. Those controls work for the problems they were designed to solve.
However, the 2026 Verizon Data Breach Investigations Report found credential abuse present in 39% of all breaches across the full attack chain. This isn't due to weak employee passwords. It comes from the credentials your security program doesn't see: service accounts, API keys, certificates, and access paths outside your identity provider.
Fragmentation is another issue. Active Directory manages human accounts. Your secrets manager (if you have one) handles some service accounts. API keys live in CI/CD configs. Database credentials are in .env files. SSH keys are on developer laptops. No single system owns the full credential inventory, so no single team can prove it's controlled.
Mistake 1: Treating Service Accounts as Technical Debt Instead of Compliance Risk
Why it happens: Service accounts don't log in through your SSO portal. They don't trigger MFA prompts. They're invisible to access review workflows built for human users, so they're categorized as "technical debt we'll clean up later."
The consequence: A mid-size organization routinely has more service accounts than human accounts. Most share passwords that have never rotated and have no documented owner. Article 21(2)(i) requires access control policies to cover all accounts. If you can't enumerate your service accounts, you can't control them, and you can't prove control to an auditor.
The fix: Start with inventory. Pull every service account from Active Directory, 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. Assign each credential to a specific role or service owner. Set a 90-day rotation policy where feasible. The inventory itself becomes your first evidence artifact for Article 32 documentation requests.
Mistake 2: Offboarding Users but Not Their Credentials
Why it happens: 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 is a separate credential that needs explicit revocation.
The consequence: Dormant accounts are a direct audit failure under Article 21(2)(i), which requires lifecycle management as part of access control policy. More practically, they're what attackers enumerate after initial access. A former contractor's database credentials from eight months ago won't trigger your anomaly detection because the account has a legitimate history.
The fix: Build a single offboarding checklist that covers every credential type your organization issues: AD accounts, VPN certificates, database users, cloud IAM, SSH keys, API tokens. Map each credential type to the system that issues it and the person responsible for revocation. Run a quarterly audit query: any credential not accessed in 90 days with no documented exception requires either revalidation or revocation. Export the results. That export is your lifecycle management evidence.
Mistake 3: Deploying MFA Everywhere Except Where It Matters
Why it happens: You rolled out MFA to satisfy a compliance checkbox. You measured success by enrollment percentage. But you allowed exceptions for "legacy systems that don't support it" and "service accounts that need unattended access."
The consequence: Article 21(2)(j) requires MFA "where appropriate." ENISA's guidance makes clear that "appropriate" covers all privileged access and all remote access to critical systems. SMS OTP doesn't count. NIST SP 800-63B section 5.2.10 classifies SMS-based OTP as a restricted authenticator due to SIM swapping and SS7 interception risks. Your exceptions attract auditor scrutiny and require both technical controls and documented approval processes you probably don't have.
The fix: Identify every privileged access path and every remote access point to critical systems. Deploy phishing-resistant MFA (FIDO2/WebAuthn, hardware security keys, or certificate-based authentication) on all of them. For legacy systems that genuinely can't support modern MFA, document the technical limitation, the compensating controls (network segmentation, IP restrictions, enhanced logging), and the executive approval. Review the exception list quarterly. The goal is a shrinking list with clear ownership, not a static backlog.
Mistake 4: Storing Credentials in Systems That Don't Log Access
Why it happens: You needed a quick way to share a production database password with the on-call rotation, so you put it in a shared Slack channel or a team wiki page. It solved the immediate problem.
The consequence: NIS2 Article 32 gives competent authorities the right to request documentation of implemented security measures. Documentation means the policy, the technical control enforcing it, and a log showing the control has been active. If your credential storage system doesn't produce an audit trail, you can't prove who accessed what credential when. From an auditor's perspective, the control doesn't exist.
The fix: Deploy a centralized credential vault with full audit logging. Every access event needs a timestamp, user identity, and credential identifier. Configure the vault to integrate with your directory service for automated provisioning and deprovisioning. Enable role-based access control that mirrors your organizational hierarchy. Export a compliance report immediately after deployment to verify the logging works. That export demonstrates you can produce evidence on demand, which is what Article 32 enforcement requires.
Mistake 5: Building Controls Without Evidence Infrastructure
Why it happens: You implemented the security control. You assume that's sufficient. You don't build the system that proves the control has been active and effective over time.
The consequence: Having a control and proving a control are different things. This is where most organizations fail pre-audits: not because the controls don't exist, but because the evidence doesn't. Auditors expect access control policy (written, versioned, approved), technical enforcement evidence (configuration exports, enrollment reports), access review records (who reviewed, when, what was revoked), and credential rotation logs. If it isn't logged and exportable, it doesn't exist from an audit perspective.
The fix: For every credential control you implement, define the evidence artifact it must produce. Access control policy needs a version number and approval signature. MFA deployment needs an enrollment report with timestamps. Access reviews need a dated export showing dormant accounts identified and revoked. Service account rotation needs a log with completion timestamps. Build these evidence requirements into the initial deployment, not as a pre-audit scramble. The goal is a system that generates compliance evidence automatically as a byproduct of normal operations.
Prevention Checklist
Before your next NIS2 preparation meeting, verify you can answer yes to each question:
- You have a complete inventory of service accounts, API keys, and certificates with documented owners
- Every credential type has a defined revocation process in your offboarding workflow
- Phishing-resistant MFA protects all privileged access and all remote access to critical systems
- All credentials live in a centralized vault with full audit logging enabled
- You can export an access review report showing dormant accounts identified and revoked in the last 90 days
- Your credential vault integrates with Active Directory or LDAP for automated lifecycle management
- You have documented exceptions for any system that can't support modern MFA, with compensating controls and executive approval
- Each credential control you've implemented produces an exportable evidence artifact
Organizations that contain breaches faster are consistently the ones with visibility into where their credentials are. Credential management won't cover every NIS2 requirement, but it closes the chokepoint present in 39% of all breaches and gives you provable evidence in under 30 days. Start with the inventory. Everything else follows.
