Organisations should place unshared credentials under centralized organizational ownership, not private user ownership. That lets admins retain recovery and reassignment rights when someone leaves, while preserving reporting and audit visibility. The practical goal is full credential lifecycle management, so storage, use, succession, and offboarding are governed as one control plane rather than separate user-owned silos.
Why This Matters for Security Teams
Unshared credentials are often created to make work easier for a single team member, but they become a governance problem the moment that person leaves. If the credential is privately held, offboarding can break service continuity, strand access in forgotten tools, or force a risky reset that disrupts production. The safer pattern is centralized organizational ownership, with recovery rights, auditability, and succession rules defined before a departure happens.
This matters because offboarding is not only a human identity event. It is also a secret lifecycle event, and the two are frequently handled by different teams. Guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s NHI Lifecycle Management Guide both point to the same operational risk: if ownership is not explicit, recovery is improvised. In practice, many security teams discover orphaned access only after a resignation, incident, or billing review forces a manual inventory.
One useful benchmark is that The 2025 State of NHIs and Secrets in Cybersecurity found 91% of former employee tokens remain active after offboarding, which shows how often lifecycle controls fail when ownership is left informal.
How It Works in Practice
The operational answer is to treat every unshared credential as an organisation-owned asset with a named steward, not a personal possession. That means the credential, vault entry, key material, and associated audit trail all sit under corporate control, even if day-to-day use is limited to one person or one workflow. The practical model should cover creation, storage, rotation, recovery, reassignment, and retirement as one process, rather than letting each step live in a different tool or ticket queue.
Start by classifying the credential. If it authenticates an application, API, service account, admin console, or signing workflow, it should be governed as a secret with a lifecycle owner. Then enforce these basics:
- Store the secret in an approved vault or managed secret store, never in a personal password manager or inbox.
- Assign organisational ownership, with at least two roles: operational custodian and recovery authority.
- Log every use, rotation, and transfer of custody to preserve auditability.
- Document succession so offboarding can reassign access without exposing the credential to the departing user.
- Rotate or revoke immediately if there is any uncertainty about copy sprawl.
NHIMG’s Guide to the Secret Sprawl Challenge and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs both reinforce that the control objective is not merely storage, but complete lifecycle governance. For baseline identity hygiene, NIST SP 800-63 Digital Identity Guidelines remains useful for identity proofing and account recovery principles, while NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control basis for access, audit, and revocation.
These controls tend to break down when credentials are duplicated across teams, because no single owner can prove which copy is current or revoke all replicas with confidence.
Common Variations and Edge Cases
Tighter control over unshared credentials often increases operational overhead, so organisations have to balance recovery speed against administrative discipline. That tradeoff is most visible in legacy systems, shared admin consoles, and vendor portals that were never designed for clean handoff or delegated custody.
Best practice is evolving for these edge cases, but the guidance is consistent: if a credential cannot be uniquely owned, it should be wrapped in compensating controls such as just-in-time access, mandatory rotation after use, or a front-end privileged access workflow. Where a departed employee was the only person who understood a brittle integration, the recovery plan should include a rebuild or replacement path, not just a password reset. For teams still operating with fragmented secret storage, the Top 10 NHI Issues highlights how secret sprawl and weak lifecycle ownership create the same failure mode in different forms.
In highly regulated environments, the question is not whether access is lost after offboarding, but whether the organisation can prove who had custody, who approved reassignment, and when the last valid use occurred. That is why the control should be written into policy, backed by vault permissions, and tested during offboarding drills rather than assumed to work on paper.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Unshared credentials need explicit ownership, lifecycle tracking, and recovery controls. |
| NIST CSF 2.0 | PR.AC-1 | Access rights must be managed so orphaned credentials do not survive employee exit. |
| NIST SP 800-63 | Recovery and reassignment depend on strong identity lifecycle and account proofing. | |
| NIST SP 800-53 Rev 5 | AC-2 | Account management controls support assignment, review, and timely deprovisioning of secret-backed access. |
| NIST AI RMF | GOVERN 3.1 | Governance should define accountability and escalation for credential custody changes. |
Put every secret under org-owned lifecycle control with named custodians and verified offboarding steps.
Related resources from NHI Mgmt Group
- How should organisations manage contractor access without creating orphaned accounts?
- What is the difference between rotating a secret and revoking access?
- Why do ephemeral credentials still leave risk in machine access models?
- How can organisations reduce the risk of stale API keys and machine tokens?
