Why do shared credentials and stale accounts matter so much under NIS-2?

They destroy traceability and ownership. If multiple people use the same access path, or if old accounts remain active after role changes, the organisation cannot reliably prove who was responsible at the time of access. That creates both compliance risk and operational exposure because privilege cannot be defended or revoked cleanly.

Why shared credentials and stale accounts break NIS-2 accountability

shared credentials and stale accounts are a problem because NIS-2 expects organisations to know who had access, when they had it, and what they could do with it. Once several people share the same login, or an old account survives a role change, attribution becomes weak and revocation becomes messy. That undermines traceability, incident response, and the ability to defend control decisions.

Under NIS-2, this is not just an admin hygiene issue. It affects whether access can be tied to a named person or bounded service, whether joiner-mover-leaver processes actually close off old privilege, and whether audit evidence can show that access was intentional, approved, and removable. A control that cannot prove ownership is a control that cannot reliably hold up under review.

Shared accounts also flatten accountability across operational and security functions. If the same credential is reused across shifts, teams, or contractors, the organisation may still know that “someone” accessed a system, but not who, for what purpose, or under whose authority. That makes investigation slower, exception handling weaker, and policy enforcement much harder to sustain.

What stale accounts change in the risk picture

Stale accounts expand the window in which old access remains usable after a transfer, termination, or project end. Even when the account was legitimate at creation, it can become excessive over time, especially if roles change faster than reviews, recertification, or deprovisioning. The longer an unused account remains active, the more likely it becomes a dormant path into systems, data, and administrative functions.

The security issue is not only unauthorized use. Stale accounts also distort inventory, approvals, and logging. When the account database no longer reflects actual employment or business need, teams start making decisions based on incomplete information. That creates compliance exposure because access reviews can appear current while still leaving unneeded access in place.

For practitioners, the key distinction is between active access that is deliberately assigned and leftover access that survives by default. NIS-2 pressure is strongest where the organisation cannot show a clean lifecycle from provisioning to review to removal. NHI lifecycle management is useful here because it treats provisioning, rotation, offboarding, and visibility as one control loop rather than separate tasks.

Why this matters operationally, not just on paper

When shared credentials or stale accounts are present, response teams lose confidence in the log trail. If a suspicious action appears under a shared login, you may know which system was touched but not which operator, contractor, or automated process initiated it. That weakens containment decisions because you cannot easily separate genuine business activity from abuse, error, or compromise.

It also increases the chance of missed revocation. A stale account with elevated rights can survive one review cycle, then another, especially if ownership is unclear or the account is not tied to a current manager. In practice, that means the organisation may be carrying standing privilege it no longer intends to grant. Top 10 NHI Issues is relevant because it highlights shared accounts, inactive accounts, excessive permissions, and ownership gaps as common failure modes in access governance.

Operationally, the biggest failure is that access becomes hard to revoke cleanly. If one credential is used by multiple people, you cannot remove one person’s access without disrupting everyone else. If an old account is still active, you cannot be sure whether it is unused, forgotten, or still needed by a hidden process. That ambiguity is exactly what mature lifecycle governance is supposed to eliminate.

Risk and Threat Considerations

Shared credentials and stale accounts increase the blast radius of compromise because they hide individual responsibility and prolong access after it should have ended. They are attractive to attackers precisely because they often persist unnoticed, blend into routine activity, and reduce the chance that defenders can prove who used the access path.

Failure mechanism: A shared login or orphaned account lets malicious or unintended activity occur under a legitimate identifier, while weak ownership and delayed deprovisioning prevent timely detection or clean revocation.

Impact: The organisation can lose forensic clarity, fail access reviews, and keep excess privilege alive long enough for misuse, lateral movement, or policy breach to occur.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 and NIS2 define the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-4 — Identifier Management	Shared and stale accounts depend on unique account ownership and lifecycle control.
	IA-5 — Authenticator Management	Shared credentials and stale accounts hinge on credential lifecycle, rotation, and revocation.
	AU-2 — Event Logging	Traceability depends on logs that can distinguish individual use from shared access paths.
Recommendation — Enforce unique identifiers and retire them when access is no longer needed. Manage authenticators so shared or lingering credentials can be rotated and revoked cleanly. Log access events at a level that preserves accountable attribution.
ISO/IEC 27001:2022	A.5.16 — Identity management	NIS-2 accountability depends on identities being uniquely assigned and governed through their lifecycle.
	A.5.18 — Access rights	Stale and shared access are access-rights failures that must be reviewed and removed promptly.
Recommendation — Assign, manage, and retire identities so access always maps to a current accountable owner. Review and revoke access rights promptly when roles or employment conditions change.
NIS2	Directive (2022/2555)	The question is explicitly about NIS-2 accountability, traceability, and access control expectations.
Recommendation — Align identity lifecycle and access governance with NIS-2 accountability requirements.

Practitioner Guidance

What to prioritise: Start with any account that can reach production systems, privileged consoles, or external-facing services. If an account is shared or stale and it can still authenticate to a critical environment, treat it as a higher-risk condition than an ordinary unused account.

What to verify: Confirm that every active account has a current owner, a current business purpose, and a documented deprovisioning trigger. Also verify that reviews do not just count accounts, they confirm that access can be traced back to a specific person or service at the time of use.

Common mistake: Teams often focus on password complexity or periodic review while leaving the real problem untouched, which is the lack of unique ownership. If multiple users must retain access, redesign the access model rather than trying to audit your way out of a shared credential.

Practitioner takeaway: Under NIS-2, the control objective is not merely to reduce account count, it is to preserve provable ownership and timely revocation. If you cannot show who held the access and why it still existed, the account is already a governance problem.