You've read the directive, mapped requirements to controls, and convinced management to approve the budget. But when the auditor asks to see your access management evidence, you'll find that having a policy and proving it are two different challenges.
NIS2 Article 21 requires access control enforcement across all accounts with system access. Article 32 allows authorities to request documentation of implemented security measures. Most organizations fail not because they lack controls, but because they can't produce timestamped, exportable proof that those controls have been active and generating events.
Why These Mistakes Keep Happening
The access management failures that derail NIS2 audits aren't new. They're the same gaps found in breach post-mortems and internal security assessments. What's changed is the enforcement context: NIS2 non-compliance exposes essential entities to fines up to €10 million or 2% of global turnover, and management bodies to personal liability, including temporary bans from executive roles.
The credential problem persists because it sits at the intersection of IT operations, security policy, and vendor relationships. No single team owns the full lifecycle. HR triggers offboarding but doesn't track SSH keys. IT manages Active Directory but not database connection strings. Security writes the policy but can't enforce rotation schedules without operational buy-in.
Credential abuse appears in 39% of all breaches according to the 2026 Verizon Data Breach Investigations Report. The report identifies it as a "legitimate mitigation target chokepoint." You can't fix everything before the audit deadline, but you can close the vector that attackers use to move laterally once they're inside your perimeter.
Mistake 1: Treating Service Accounts Like Second-Class Citizens
Why it happens: Most access management discussions focus on human users. Service accounts, API keys, database connection strings, and deployment tokens get created on-demand by developers and operations teams, then forgotten. Nobody assigns ownership or schedules rotation. These credentials live in .env files, CI/CD configurations, and shared drives.
The consequence: A typical mid-size organization has more service accounts than human accounts. When an auditor asks for your complete account inventory under Article 21(2)(i), you can't produce it. Worse, when an attacker gains initial access through a vulnerability, these unmanaged credentials become the lateral movement path.
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 consolidate them into a managed vault with rotation schedules and documented owners. Configure Role-Based Access Control (RBAC) so each service account has defined permissions and a business justification. Set 90-day rotation policies where feasible, and document exceptions where it isn't.
Mistake 2: Relying on Offboarding Tickets Without Verification
Why it happens: HR closes the separation ticket, IT disables the Active Directory account, and everyone assumes the job is done. Nobody checks whether that person also had direct database access, a VPN certificate, an AWS IAM user, or SSH keys on production servers. Each of those is a separate credential that needs explicit revocation.
The consequence: Dormant accounts are a direct audit failure under Article 21(2)(i), which requires access control policies to include lifecycle management. They're also what attackers target after initial compromise: valid credentials, no monitoring, no user to notice suspicious activity.
The fix: Build a credential inventory that spans every system, not just AD. When offboarding triggers, generate a checklist from that inventory: AD account, VPN access, database users, cloud IAM, SSH keys, application-specific credentials, hardware tokens. Require sign-off from each system owner. Schedule quarterly reviews to catch anything that slipped through, and export the review results with timestamps and reviewer names. That export is your lifecycle management evidence.
Mistake 3: Deploying MFA Without Phishing Resistance
Why it happens: Your organization rolled out Multi-Factor Authentication (MFA) years ago. Everyone uses it. Management considers the requirement satisfied. But most implementations rely on SMS OTP or authenticator apps, both of which are vulnerable to real-time phishing and adversary-in-the-middle attacks.
The consequence: 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 remote access to critical systems. NIST SP 800-63B explicitly classifies SMS-based OTP as a restricted authenticator. Your current MFA implementation may not meet the standard an auditor applies.
The fix: Deploy phishing-resistant MFA for privileged accounts and remote access: FIDO2/WebAuthn, hardware security keys, or certificate-based authentication. Phase the rollout starting with administrative accounts and sensitive system access. Document technical exceptions (legacy systems that can't support modern authentication) with compensating controls and formal risk acceptance. The goal isn't perfection; it's demonstrable progress and documented justification for any gaps.
Mistake 4: Storing Credentials in Email and Shared Drives
Why it happens: A developer needs to share a database password with a contractor. Email is fast. A shared drive folder is convenient. The credential gets the job done, and nobody circles back to revoke it or move it into a managed system.
The consequence: These credentials have no access controls, no rotation schedule, and no audit trail. When an auditor asks where your secrets are stored and how access is controlled, you can't point to email threads and shared drives as evidence of compliance. When an attacker compromises a mailbox or a file share, they gain access to everything stored there.
The fix: Deploy a centralized credential vault with AES-256 encryption and RBAC. Migrate every credential currently stored outside that vault: spreadsheets, email, .env files, wiki pages, sticky notes. Configure the vault to integrate with your directory service (AD/LDAP) so access policies inherit from existing role definitions. Enable full audit logging from day one. The vault becomes your single source of truth and your primary evidence artifact.
Mistake 5: Treating Audit Logs as an Afterthought
Why it happens: Your team implemented access controls, enforced MFA, and cleaned up dormant accounts. The work is done. Logging feels like overhead, something to configure later when there's time.
The consequence: If it isn't logged and exportable, it doesn't exist from an auditor's perspective. You can describe your access review process, but without timestamped records showing who reviewed what and when, you have no evidence. Article 32 gives competent authorities the right to request documentation. "We do quarterly reviews" is a claim. An exported CSV with review dates, reviewer names, and revoked accounts is evidence.
The fix: Configure audit logging as part of initial deployment, not as a follow-up task. Every access request, credential rotation, and permission change should generate a log entry. Schedule automated exports on the same cadence as your access reviews (quarterly is typical). Store those exports in an immutable location with retention policies that match your regulatory obligations. When the auditor asks for proof, you hand them a file.
Prevention Checklist
Use this checklist to verify your access management controls generate auditable evidence:
- Complete credential inventory including service accounts, API keys, and non-human identities
- All credentials stored in a centralized vault with AES-256 encryption and RBAC
- Rotation schedules configured for service accounts and API keys with documented exceptions
- Phishing-resistant MFA enforced for privileged and remote access
- Offboarding procedure verified across all systems, not just Active Directory
- Quarterly access reviews scheduled with automated reminders and export requirements
- Audit logging enabled with automated exports and immutable storage
- Access control policy documented, versioned, and approved by management
- Role matrix defined with least-privilege assignments and business justifications
- Dormant account detection automated with 90-day inactivity threshold
Organizations that will struggle with NIS2 audits aren't those with imperfect security, but those with no evidence. Implementing access control enforcement under NIS2 can be a 2-4-week project for a competent team. Start with the inventory, close the credential gaps, and build the logging infrastructure that turns your controls into exportable proof. That work closes the chokepoint present in 39% of all breaches and gets you operational evidence in under 30 days.
