What breaks when NHIs are not included in employee offboarding?

The offboarding process stops at the person while the credentials, tokens, and service accounts they created keep running. That leaves live access without accountable ownership, which makes orphaned NHIs hard to justify, hard to review, and easy to overlook during change events.

What stops working when NHIs are left out of offboarding?

When offboarding only covers the employee, the technical access they used can survive them. That breaks the handoff from people to machine access, so credentials, tokens, and service accounts keep operating with no clear owner, no recertification path, and no clean point to revoke or rotate them.

Why orphaned non-human access is hard to see and harder to trust

Offboarding is not just a people process when services, scripts, integrations, and automation are still active. If the identity layer is not included, ownership becomes ambiguous and inventory quality drops, which is why NHI lifecycle and ownership controls matter in NHI Lifecycle Management Guide and NHI Ownership and Accountability Guide.

That gap is especially visible where teams treat service accounts, API keys, and certificates as implementation details rather than assets with an owner and a removal date. The result is not just stale access, but a control failure: nobody can confidently say whether the access is still needed, who approves it, or whether it matches current business intent.

NHIs also expose a broader lifecycle problem because deprovisioning and rotation are separate actions. A leaver may be gone, but the machine credential they created can still authenticate, still authorize actions, and still bypass the review that happened during the human exit process. The practical consequence is that orphaned access often survives change windows, reorganisations, and vendor transitions.

Which controls usually break first

Once nhi offboarding is missed, the first broken control is usually revocation discipline. Tokens are not tied to the leaving employee anymore, so the team has to discover the dependent system first, then decide whether the credential can be rotated or retired without outage. The Joiner-Mover-Leaver (JML) Guide and the Service Account Security Guide both reinforce that offboarding must reach the credential, not stop at the person.

The second broken control is access review. Orphaned NHIs are hard to justify because the current owner is missing, the original business purpose is vague, and the entitlement record often no longer reflects how the system is actually used. That makes recertification weak, especially in environments with shared accounts, inherited permissions, or long-lived secrets.

The third break is change management. A decommissioning task, application migration, or staffing change can quietly leave behind automation that still depends on an old credential. In practice, the safest response is to treat offboarding as a dependency-discovery problem, not just an HR-triggered account removal.

What practitioners should do before the leaver ticket is closed

Start with a credential inventory that connects each NHI to a business system, owner, and expiry or rotation policy. If the leaving employee had administrative reach over a service account, signing key, or token issuer, confirm whether that access was personal, shared, or embedded in automation before you close the offboarding record.

Use a JML process that explicitly includes non-human accounts, then verify that the credential was revoked, rotated, or re-owned by a surviving operator. Where the environment has many integrations, prioritize the NHIs that can reach production, hold privileged scopes, or authenticate across trust boundaries.

What to verify: that every credential tied to the leaver has a named owner, a current purpose, and a removal or renewal decision. If the team cannot produce that evidence, treat the NHI as an open access path, not as a documentation issue.

What good looks like: offboarding closes both the human identity and the machine access path, with no orphaned secrets left behind and no dependency on tribal knowledge to explain why the credential still exists.

Practitioner takeaway: the failure is not simply “forgotten cleanup”, it is loss of accountability for access that still works. If an identity can still authenticate after the employee is gone, offboarding is incomplete.

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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Improper Offboarding	Employee exit leaving NHI access behind is the core failure mode.
	NHI-07 — Long-Lived Secrets	Orphaned access often persists because secrets outlive the employee.
	NHI-10 — Human Use of NHI	Offboarding must ensure people are not the only visible owners of machine access.
Recommendation — Revoke or re-own every NHI credential before closing the offboarding case. Rotate or retire long-lived secrets as part of leaver processing. Ensure each NHI has a surviving operational owner independent of the leaver.
NIST SP 800-53 Rev 5	IA-5 — Authenticator Management	Offboarding should cover revocation, rotation, and lifecycle of authenticators.
	AC-2 — Account Management	Leaver processing must disable or transfer accounts and related access.
	AU-6 — Audit Record Review, Analysis, and Reporting	Orphaned NHIs are easier to miss without log review and ownership validation.
Recommendation — Remove, rotate, or invalidate authenticators when staff or roles change. Disable stale accounts and validate residual access paths after separation. Review authentication and use logs to confirm which NHIs still need access.
CIS Controls v8	CIS-5 — Account Management	Offboarding is fundamentally an account lifecycle and removal problem.
Recommendation — Track, revoke, and verify all accounts and access tied to departing users.