How should organisations handle shared passwords in the identity lifecycle?

Shared passwords need an owner, not informal convenience

A shared password is still an access path, so the organisation must decide who owns it, why it exists, and which business process it supports. If nobody can answer those questions, the credential is effectively outside identity governance. Treat it as a managed account pattern, not a shortcut that sits beside the lifecycle process.

That means the password should have a named steward, a defined purpose, and a clear boundary around where it may be used. The question is less about whether sharing ever happens and more about whether the sharing is controlled enough to survive role change, leave events, and audit review without creating invisible access.

For lifecycle management, the key issue is that shared passwords break the normal link between a person and an entitlement. Once several people know the same secret, offboarding no longer removes access cleanly, and mover events become harder to govern. A governed process should therefore require ownership, periodic review, and a decision about whether the shared secret can be replaced by a more attributable access method.

Why shared passwords create lifecycle blind spots

Shared passwords create two practical problems: accountability and residual access. Accountability is weak because the organisation cannot reliably tell who used the credential for a specific action. Residual access appears when someone leaves a team, changes role, or no longer needs the system but still remembers the password.

This is where shared credentials become a lifecycle control issue rather than just a policy issue. If the access path is not tied to joiner, mover, and leaver events, then revocation is delayed until the password is rotated, and even then older copies may remain in chats, notes, browsers, or scripts. The control failure is not only secrecy, it is the inability to prove that all holders lost access at the right time.

A useful internal reference for this pattern is the Joiner-Mover-Leaver (JML) Guide, which frames offboarding and access removal as lifecycle events, not one-time administration tasks. The NHI Ownership and Accountability Guide is also relevant because the same ownership problem applies when a shared credential is used as a standing access path. For broader lifecycle discipline, the Lifecycle Processes for Managing NHIs section explains why provisioning, rotation, and offboarding need a defined owner even when many users touch the same access path.

What good control looks like for shared access

Good control starts by reducing the number of shared passwords, then tightly governing the ones that remain. If a shared password is unavoidable, it should be documented, scoped to one system or one purpose, reviewed on a schedule, and rotated when membership changes. The organisation should also know where the password is stored, who can retrieve it, and how use is detected or attested.

The more a shared password is used by multiple people, the more important it becomes to attach it to a process owner rather than a person. That owner should be responsible for approving users, confirming continued need, and triggering rotation when someone leaves. In practice, the safest shared credential is one with a short lifetime, a narrow use case, and a strong exit rule.

NHIMG’s Password Security and Password Manager Guide is useful here because it treats shared passwords as a managed exception rather than a normal collaboration habit. The IAM and IGA Basics guide also supports the right operating model: access must be reviewed, entitlements should be traceable, and governance should extend to people and machines alike. For organisations with repeated offboarding problems, the Top 10 NHI Issues provides a concise view of why shared accounts and stale credentials are recurring failure modes.

Risk and Threat Considerations

Shared passwords increase the chance that access survives after a person no longer needs it, and they also make misuse harder to investigate because multiple people can legitimately claim knowledge of the same secret. The result is a broader attack surface and weaker attribution, especially where the password is reused across systems or stored in low-control channels.

Failure mechanism: A shared credential remains valid after role change or departure, or it is copied into informal locations that outlive the intended user group. Rotation then becomes the only clean revocation mechanism, and any missed copy preserves access.

Impact: Former staff, contractors, or unapproved users can continue to reach systems, and investigators may be unable to distinguish authorised use from misuse. That weakens containment, slows incident response, and can turn a routine offboarding event into a lingering access problem.

Practitioner Guidance

What to prioritise: Classify every shared password as a temporary exception with an owner, a purpose, and an expiry condition. If you cannot name the owner and the offboarding trigger, the control is already failing.

Decision rule: If the shared password is used for ongoing production access, replace it with attributable access as the default path. If replacement is not yet possible, require rotation on mover and leaver events, plus a documented review of every user who still needs it.

What to verify: Confirm that the secret is stored in a controlled system, that the approved user set is current, and that revocation actually removes all known holders. Also verify that the team can produce evidence of review and rotation when personnel change.

Practitioner takeaway: Shared passwords are manageable only when the organisation treats them as lifecycle-managed exceptions with explicit ownership; once the access path is informal, offboarding no longer means access removal.

Related resources from NHI Mgmt Group

• How should organisations handle identity lifecycle changes when employees move across roles or business units?
• What is the difference between runtime protection and NHI lifecycle management?
• How can organisations reduce the risk of stale API keys and machine tokens?
• How should organisations handle identity verification when deepfakes can mimic real users?