The organisation should own them, not the individual who happened to use them last. Access transfer, revocation, and rotation need to happen through lifecycle workflows that preserve business continuity while removing unnecessary user control. If that handoff is unclear, the account remains a personal dependency instead of a governed asset.
Why This Matters for Security Teams
Non-SSO credentials are often shared across application owners, operations staff, and platform teams, which makes role changes and departures a governance event, not a simple HR update. If ownership stays tied to the departing employee, the organisation inherits a hidden dependency that can delay revocation, stall incident response, and weaken accountability. Current guidance in the OWASP Non-Human Identity Top 10 and NHIMG’s research on Guide to the Secret Sprawl Challenge both point to the same operational problem: credentials that are not clearly owned become difficult to rotate, audit, and retire.
The practical risk is not only exfiltration. A former employee may still know where a secret lives, how it is used, and which workflow depends on it. That makes delayed handoff a business continuity issue as much as a security issue. In practice, many security teams encounter misuse or outage only after the old owner has already left, rather than through intentional lifecycle transfer.
How It Works in Practice
The cleanest model is to treat every non-SSO credential as an organisational asset with an assigned business owner, a technical custodian, and a defined lifecycle. The employee who last used the secret may provide context, but they should not remain the owner after a role change or exit. Ownership should move into a service account registry, ticketed workflow, or secrets platform record that survives personnel changes.
That workflow should include transfer, validation, rotation, and revocation. Where possible, use short-lived credentials instead of long-lived static ones, because Ultimate Guide to NHIs shows why static secrets become brittle when teams need fast handoffs. For stronger lifecycle control, NIST identity guidance from the NIST SP 800-63 Digital Identity Guidelines reinforces that identity assurance and authentication need governance, not informal possession.
- Assign the credential to the organisation, application, or service, not to the departing user.
- Record who can approve use, rotation, and emergency access.
- Rotate immediately when the user changes teams, and revoke if the credential is no longer required.
- Preserve service continuity by testing the replacement before the former owner is removed.
Where secrets are embedded in scripts, pipelines, or infrastructure code, the handoff must also include dependency discovery so the new owner knows what breaks if the credential changes. These controls tend to break down when secrets are shared informally across personal notes, chat, or unmanaged automation because there is no reliable source of truth for who can safely remove or replace them.
Common Variations and Edge Cases
Tighter ownership controls often increase operational overhead, requiring organisations to balance faster employee transitions against the risk of service disruption. Not every non-SSO credential should be handled the same way, and current guidance suggests the response should vary by blast radius and rotation complexity. A low-risk internal API key may be rotated on schedule, while a production database credential may require staged handover, change windows, and fallback validation.
One common exception is shared legacy infrastructure where a service account is technically tied to a team mailbox or tool rather than a person. In those cases, the account should still be owned by the organisation and administered through a controlled process, not left to whichever employee remembers the password. NHIMG’s Guide to the Secret Sprawl Challenge and Ultimate Guide to NHIs both highlight how secret sprawl turns this into a recurring risk.
There is no universal standard for this yet, but best practice is evolving toward explicit custodianship, documented approvals, and automated rotation where feasible. The rule of thumb is simple: if a credential cannot be transferred without a person’s memory, it is already too personal to be safely governed.
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 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Ownership and lifecycle gaps are a core non-human identity weakness. |
| NIST CSF 2.0 | PR.AC-1 | Access control must follow identity lifecycle changes and removal. |
| NIST SP 800-63 | Digital identity guidance supports governed authentication and lifecycle handling. |
Assign each secret to a governed owner and remove personal dependency before staff changes occur.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
