Why do shared accounts and weak offboarding create compliance risk under NIS-2?

Why This Matters for Security Teams

NIS-2 places real weight on governance, access control, and the ability to demonstrate who did what, when, and under whose authority. Shared accounts blur that accountability, while weak offboarding leaves access in place after employment or role changes, creating a gap between policy and reality. That gap becomes a supervisory problem because it weakens incident investigation, change traceability, and evidence quality. The NIST Cybersecurity Framework 2.0 treats identity and access as part of a broader governance and protection posture, which is a useful way to interpret this risk.

The compliance issue is not only whether access exists, but whether access can be justified, reviewed, and revoked on time. Regulators and auditors increasingly expect organisations to show that privileged or business-critical access is assigned to a specific person, then removed promptly at departure or transfer. Shared accounts make that evidence weak by design, especially when logs cannot distinguish the actual operator. In practice, many security teams encounter this only after an audit exception, a fraud review, or an incident has already exposed the control gap.

How It Works in Practice

Under a NIS-2-aligned control model, shared accounts and poor offboarding fail in three places: authentication, logging, and lifecycle management. Authentication no longer proves a unique user identity, logs lose attribution value, and access reviews become incomplete because the directory no longer reflects real-world employment status. That is why mature control sets, such as NIST SP 800-53 Rev 5 Security and Privacy Controls and ISO/IEC 27002:2022 Information Security Controls, emphasise account management, access review, audit logging, and least privilege.

Operationally, the control objective is simple: every interactive action should map to a named individual, and every access grant should have a current business owner. That usually means:

• Eliminating routine shared accounts except where a specific technical exception is documented and compensated for.
• Using named accounts for administrators, service owners, and operational staff, with role-based assignment rather than password sharing.
• Forcing immediate deprovisioning when someone leaves, changes function, or loses a system need.
• Recording access review evidence so managers can confirm both ownership and continued necessity.
• Preserving logs that support attribution, especially for privileged actions and incident response.

Where identity governance is stronger, this also intersects with broader trust and risk processes, including HR feeds, joiner-mover-leaver workflows, and privileged access management. Security teams often pair these controls with ISO/IEC 27001:2022 Information Security Management to show that access lifecycle controls are embedded in the management system rather than handled as isolated tickets. These controls tend to break down in outsourced operations, legacy OT environments, and emergency access workflows because teams rely on password sharing to keep systems running.

Common Variations and Edge Cases

Tighter identity controls often increase operational overhead, requiring organisations to balance traceable access against speed in support, engineering, and incident response. That tradeoff is real, especially where teams rely on break-glass access or third-party contractors. Best practice is evolving, but current guidance suggests that exceptions should be rare, time-bounded, monitored, and explicitly approved rather than treated as normal operating procedure.

There are also legitimate edge cases. Shared human access may exist in a constrained technical environment, but the control goal should still be individual attribution through compensating controls such as personal tokens, session recording, or supervised jump hosts. In identity-heavy environments, poor offboarding can also create downstream fraud and AML concerns because stale access may be used to alter customer records, approve transactions, or weaken KYC evidence chains. That makes this issue relevant not only to cyber compliance but also to broader assurance and trust obligations. If access is still active after a person has left, the organisation no longer has a defensible answer to who could have acted.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create compliance risk even when policies exist?
• Why do static SSH keys and shared admin accounts create compliance risk?
• Why do shared passwords and copied keys create such a large risk in smaller environments?