Why do shared administrative accounts create NIS2 risk?

Why This Matters for Security Teams

Shared administrative accounts turn a routine access pattern into a governance problem because they collapse attribution, approval, and review into a single opaque credential. Under NIS2, that matters because organisations are expected to demonstrate accountable access management, not just functional access. The issue is not only who can log in, but who can prove they used the access, when, and for what purpose. The NIS2 Directive — official EU legal text and the NIST Cybersecurity Framework 2.0 both push teams toward traceable, reviewable control. NHIMG research also shows why this is operationally urgent: only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs — Key Challenges and Risks. When shared admin accounts sit outside named identity governance, audit evidence weakens and incident response slows. In practice, many security teams encounter this failure only after a privileged action cannot be tied back to any individual, rather than through intentional access review.

How It Works in Practice

Shared administrative accounts are often introduced because legacy platforms, built-in appliance logins, or break-glass procedures do not support named identities cleanly. The control objective under NIS2 is not to eliminate every emergency account overnight, but to make privilege use attributable, reviewable, and time-bound. Current guidance suggests treating shared admin credentials as an exception path, not a normal operating model.

That means replacing broad shared access with named accounts wherever the system allows it, then layering NIST SP 800-53 Rev 5 Security and Privacy Controls-style logging, approvals, and privileged session recording for the cases that remain. PAM can help by brokering access, vaulting secrets, and issuing just-in-time elevation, but PAM does not by itself solve the identity problem if several people still authenticate through the same account. The stronger pattern is to bind each action to a named identity, then use shared credentials only as a last resort with compensating controls.

• Require named administrator accounts for routine work.
• Reserve shared accounts for tightly scoped break-glass use only.
• Record privileged sessions, command history, and approval context.
• Rotate credentials after every emergency use.
• Review access paths regularly and retire legacy shared accounts where possible.

NHIMG guidance in the Ultimate Guide to NHIs — Regulatory and Audit Perspectives reinforces that auditability is the real control objective, because shared accounts obstruct both attribution and clean evidence collection. These controls tend to break down in flat legacy environments where one privileged login still spans multiple applications, because the technical stack cannot preserve per-user identity end to end.

Common Variations and Edge Cases

Tighter privileged access often increases operational overhead, so organisations must balance auditability against emergency access speed and legacy system constraints. That tradeoff is real, especially where an outage response depends on rapid access to infrastructure that cannot yet support named identities.

There is no universal standard for this yet, but best practice is evolving toward temporary, heavily governed shared access with strong compensating controls. For example, if a mainframe, network appliance, or embedded platform requires a shared administrator login, organisations should document the exception, limit the number of authorised users, and attach time-bounded approvals, tamper-evident logging, and post-use review. The EU NIS2 Directive does not prescribe one technical pattern, but it does raise the bar for governance evidence, which means exception handling must be defensible. For broader identity hygiene, the Top 10 NHI Issues research is a useful reminder that visibility and rotation failures usually travel together. Shared accounts are sometimes unavoidable, but if they cannot be traced to a person and a purpose, they remain a standing risk rather than a controlled exception.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?
• Why do non-human identities create compliance risk even when policies exist?
• Why do collaboration tools create such a large secrets risk?