Who is accountable when a shared administrative credential is misused after offboarding?

Why This Matters for Security Teams

Shared administrative credentials create an accountability gap because the credential outlives the person, team, or vendor relationship that originally justified it. Once offboarding occurs, a surviving secret can still be used to change configurations, export data, or approve access long after human authority has ended. That is why the problem is not only misuse, but the control failure that allowed continued use. The 2025 State of NHIs and Secrets in Cybersecurity reports that 91% of former employee tokens remain active after offboarding, which shows how often lifecycle controls fail in practice.

Security teams should treat this as a governance issue across identity, secrets, and privileged access workflows. The answer is rarely “the person who used it” alone; it is usually the control owners, approvers, and system owners who permitted the credential to persist. This is consistent with the direction of the NIST Cybersecurity Framework 2.0, which emphasises ownership, risk treatment, and continuous control operation.

In practice, many security teams discover this only after a leaver review, incident, or audit has already exposed that no one could prove when authority actually ended.

How It Works in Practice

Accountability should follow the control plane, not just the individual who happens to know the password or hold the token. For shared administrative credentials, that means defining an owner for the vault, an approver for issuance, a reviewer for ongoing access, and a responder for revocation. If any of those roles are missing, the organisation has a process gap, not merely a misuse problem. The NHI Lifecycle Management Guide is useful here because offboarding must be tied to secret retirement, not only HR status changes.

Operationally, the strongest pattern is to remove the shared credential entirely and replace it with per-person or per-task access where possible. If a shared secret cannot be eliminated immediately, it should be placed behind a vault with explicit ownership, short-lived retrieval, and mandatory rotation on role change, offboarding, or suspected misuse. Current guidance suggests combining privileged access management with a lifecycle checklist that includes inventory, attestations, revocation, and evidence retention. The OWASP Non-Human Identity Top 10 reinforces that secret sprawl and weak lifecycle controls are recurring failure modes, not edge cases.

• Assign a named business owner and technical owner for every shared administrative credential.
• Bind offboarding to automatic revocation, rotation, or replacement of all known secrets.
• Require privileged access review before a credential can remain active after a role change.
• Log who approved continued use, who can still retrieve the secret, and when the last rotation occurred.

When those controls exist, accountability becomes auditable: the organisation can show who was allowed to hold authority, who ended it, and who failed to enforce the end state. These controls tend to break down in hybrid environments with multiple vaults and manual exceptions because authority becomes fragmented across teams and systems.

Common Variations and Edge Cases

Tighter revocation and review controls often increase operational overhead, requiring organisations to balance speed for administrators against the need to prove authority ended on time. That tradeoff becomes sharper when shared credentials are embedded in legacy systems, third-party support contracts, or emergency break-glass procedures. In those cases, the immediate answer is not always elimination, but stronger governance and shorter validity windows.

There is no universal standard for this yet, but best practice is evolving toward named ownership, just-in-time access, and credentials that expire automatically instead of remaining valid across staff changes. If an external vendor retains access after offboarding, accountability should extend to the internal sponsor who authorised the relationship and the platform owner who failed to revoke it. The Guide to the Secret Sprawl Challenge is relevant because duplicated secrets and unmanaged copies make it hard to determine which credential was actually misused.

For audit and incident response, the key question is whether the organisation can prove the exact point at which access should have ceased. If it cannot, the issue is broader than user misconduct. It is a lifecycle control failure that should be mapped to policy, ownership, and review obligations under identity governance.

Related resources from NHI Mgmt Group

• How can organizations manage the risk of credential leaks in MCP frameworks?
• Should organisations prioritise external exposure or internal credential governance first?
• Who is accountable when a third-party credential is misused?
• Who is accountable when a cloud credential is misused by an AI workflow?