Treat that as a full offboarding event for the associated access chain, not just the human account. The agent, delegated scopes, and any downstream service accounts should be reviewed together, because the human departure can leave intact a set of credentials that still have working access but no current accountability.
What “offboarding” really means when a person leaves but access does not
When a human exits, the security event is bigger than disabling the person’s login. Any agent, service account, delegated token, API key, or linked automation that was created, approved, or operated by that person should be treated as part of the same access chain. The goal is to remove durable authority, not just disconnect the individual who originally used it.
That matters because non-human access often outlives employment changes. A dormant service account can still call internal systems, a delegated scope can still authorize actions, and an automation can still inherit trust from an old approval path. Offboarding has to answer one question: what access remains effective after the person is gone?
Which access paths should be reviewed together?
The review should include the human account, any non-human identity the person owned or administered, and any credentials or scopes that were issued to support that relationship. In practice, that means checking ownership records, delegated grants, token issuance paths, secret storage, and downstream accounts that depend on the same approval or trust chain.
This is where organisations often miss the real exposure. If the original human account is removed but the service account still authenticates successfully, accountability is broken even though access is still live. NHIMG’s Human vs Non-Human Identity is useful here because it frames the boundary between person-owned access and machine-operated access, which is exactly where offboarding gaps hide.
Where service accounts are used broadly across cloud, SaaS, and infrastructure, the review should also test whether the remaining identity has any privilege that no longer has a business owner. NHIMG’s Service Account Security Guide provides a practical view of discovery, least privilege, rotation, and governance for those accounts.
What should happen before the account chain is trusted again?
The first step is to verify ownership, then decide whether the remaining access should be rehomed, rotated, reduced, or removed. If a service account or agent is still needed, it should not remain tied to a departed person’s approval history, credentials, or recovery path. If it is not needed, it should be deprovisioned rather than simply left idle.
For cloud and Kubernetes environments, this often means checking whether workload identity, token federation, or pod-linked access has escaped the intended lifecycle. NHIMG’s Cloud Workload Identity Guide is relevant because these setups frequently replace static keys with federated access, but they still need explicit offboarding when the human relationship ends.
In agentic or delegated flows, review whether the agent still has the authority to act on behalf of the departed user, especially where token exchange or delegated scopes are in play. If the person was the only meaningful owner, the organisation should pause the chain until a new accountable owner is assigned and the active credentials are reissued or retired.
Risk and Threat Considerations
The main risk is orphaned authority: access that still works after the person who created, approved, or understood it has left. That creates stealthy persistence, because an attacker, a former insider, or simply operational neglect can keep using a valid credential path long after the business believes the access was closed.
Failure mechanism: The human account is terminated, but the associated service account, delegated scope, or token remains valid, so the effective access path survives without an accountable owner or routine review.
Impact: Systems can stay exposed to unauthorized use, privilege abuse, data access, and lateral movement, while investigations become harder because no current owner can explain or attest to the remaining access.
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 surface, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The question is directly about leftover non-human access after a human exit. |
| NHI-05 — Overprivileged NHI | Remaining agent or service access often persists with excess privilege after departure. | |
| Recommendation — Revoke the full access chain when the owner leaves, including service accounts and delegated credentials. Reduce surviving non-human access to the minimum needed or retire it entirely. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The scenario centers on retiring or rotating credentials that survive the human departure. |
| AC-2 — Account Management | Accounts and their lifecycle must be managed when the responsible person leaves. | |
| AC-6 — Least Privilege | Residual service access should be trimmed to the minimum necessary privilege. | |
| Recommendation — Rotate or revoke authenticators tied to the departed user before reusing the access path. Review, disable, or reassign accounts that remain active after personnel changes. Remove unnecessary entitlements from surviving service and delegated accounts. | ||
| CIS Controls v8 | CIS-5 — Account Management | Offboarding leftover service access is an account-management control problem. |
| Recommendation — Inventory and disable dormant or orphaned accounts during every offboarding event. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity Management, Authentication and Access Control | The answer is about managing identities and access that remain effective after a person exits. |
| GV.RM-01 — Risk Management Strategy | Organizations need a repeatable strategy for handling orphaned access risk. | |
| Recommendation — Map each remaining access path to an owner and remove unused authorization promptly. Define offboarding rules that force review of non-human access chains before closure. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | The situation requires identification and ownership of remaining identities and access paths. |
| A.5.18 — Access rights | Access rights tied to a departed person must be reviewed and removed where no longer needed. | |
| Recommendation — Ensure every surviving account or credential is assigned, reviewed, and justified. Revoke or reassign access rights that are no longer needed after offboarding. | ||
Practitioner Guidance
What to prioritise: Treat the departure as an access-chain review, not an HR-only event. Start with anything that can still authenticate, authorize, or exchange tokens without the departed person, because those are the paths that can quietly outlive the employee record.
What to verify: Confirm that every remaining non-human account has a current owner, a business purpose, and a documented approval path. If any of those are missing, treat the access as orphaned until the account is either re-owned or removed.
Common mistake: Disabling the user and assuming the job is done. The harder issue is usually the downstream credential, delegated grant, or automation that was never coupled to the person’s exit workflow.
Practitioner takeaway: Good offboarding ends authority, not just employment, so the control objective is to eliminate unowned access paths before they become invisible standing privilege.
Related resources from NHI Mgmt Group
- When should organisations separate human, service account, and agent governance?
- Should organisations prioritise AI agent settings or service account cleanup first?
- What should organisations check before retiring an AI agent’s service account?
- What breaks when human, service account and AI agent activity are monitored separately?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org