The primary directory account is removed, but the supporting accounts used to build, test, and deploy code remain active. That leaves residual access in services the enterprise cannot readily enumerate or revoke. The practical failure is not incomplete deactivation, it is fragmented identity ownership across the development stack.
Why Offboarding Breaks When Non-SAML Accounts Are Left Behind
Offboarding fails when identity is treated as the primary SSO account instead of the full set of accounts that can still build, deploy, sign, or administer systems. Non-SAML accounts often live in CI/CD, cloud consoles, package registries, source control, VPNs, secrets stores, and tooling that the directory team does not own end to end. The result is not just residue, it is a second control plane for access.
A Joiner-Mover-Leaver (JML) Guide matters here because leaver processes must remove the specific tokens, keys, and non-interactive accounts that survive directory deletion. When those accounts are outside SSO, the offboarding process must be broader than disabling the employee login.
What Actually Stays Active Across the Development Stack
Non-SAML accounts are usually the hidden credentials that support software delivery and operations: service accounts, API tokens, SSH keys, registry logins, cloud access keys, bot accounts, and tool-specific admins. They are often created by the platform team, a vendor, or a developer, then reused across multiple environments with weak ownership records. Deleting the primary directory account does nothing to those independently authenticated paths.
This is why NHI lifecycle management is the right lens for the failure. The question is not whether an employee is gone, but whether every credential-bearing account and secret that employee could reach has been discovered, mapped, and revoked.
In practice, the surviving access usually appears in places the enterprise can enumerate poorly: build runners, deployment pipelines, secrets managers, SaaS integrations, and third-party tooling. That fragmented ownership creates blind spots in revocation, audit, and exception handling. It also means one team may think offboarding is complete while another system still accepts the same person’s old automation credential.
Why Fragmented Ownership Becomes a Security and Governance Problem
The core breakage is accountability. Once access is spread across app teams, cloud teams, and tooling teams, no one has a complete inventory of who owns each non-SAML account or how it should be revoked. That creates residual access, delayed revocation, and inconsistent evidence when auditors ask whether leavers truly lost access.
For identity programs, the important control gap is not merely “account disabled” but “all authoritative access paths disabled.” A foundation in IAM and IGA helps because the enterprise needs entitlement visibility, access review, and deprovisioning across both human and machine-held credentials. If a credential is not in the governance process, it is effectively outside offboarding.
That same problem appears in practice when an old deploy key or API token continues to authenticate after the employee has left. The primary risk is not just unauthorized use, but uncontrolled persistence of trusted access in systems that change faster than HR records. The organization can remove the person while leaving the authority behind.
Risk and Threat Considerations
Residual non-SAML accounts create a durable access path for misuse, especially when credentials can authenticate to build systems, cloud services, or third-party integrations after the user relationship has ended. Because these accounts are often less visible than SSO identities, attackers and former insiders can abuse them longer before detection.
Failure mechanism: Offboarding terminates the directory record but not the non-SAML credentials, so authentication remains valid in downstream systems that trust tokens, keys, or local accounts rather than SSO state.
Impact: The enterprise retains hidden access, increasing the risk of unauthorized code changes, data access, deployment abuse, and delayed incident response when no one can quickly enumerate or revoke every remaining credential.
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 SP 800-63 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 | Left-behind non-SAML accounts are exactly an offboarding failure for non-human and service credentials. |
| NHI-02 — Secret Leakage | Residual API keys, tokens, and SSH keys are secret material that can outlive the primary account. | |
| NHI-07 — Long-Lived Secrets | Non-SAML accounts often persist because their credentials are long-lived and not tied to SSO shutdown. | |
| Recommendation — Revoke every surviving non-SAML credential path before closing leaver offboarding. Inventory and rotate exposed secrets when the leaver process ends. Shorten credential lifetime and force timely rotation for non-interactive access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Offboarding must revoke, rotate, and control authenticators used by non-SAML accounts. |
| AC-2 — Account Management | Leaver processing depends on deactivating all associated accounts, not only the primary directory entry. | |
| Recommendation — Rotate or invalidate authenticators that remain valid after a user leaves. Remove or disable every account tied to the departed user. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account inventories and timely deprovisioning directly address leftover non-SAML access. |
| Recommendation — Maintain an account inventory and deprovision departed-user access promptly. | ||
| NIST SP 800-63 | Digital Identity Guidelines | Federated SSO is only part of identity assurance, so leaver controls must cover non-federated accounts too. |
| Recommendation — Use digital identity assurance guidance to separate federated login from local or service credentials. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity Management | Identity management must cover account lifecycle and ownership across federated and non-federated access paths. |
| A.5.18 — Access Rights | Access rights must be removed when the user leaves, including rights held outside SSO. | |
| Recommendation — Define identity ownership for all accounts, including non-SAML access. Remove access rights across every platform, not just the main directory. | ||
Practitioner Guidance
What to verify: Confirm that offboarding evidence covers more than the IdP. The exit checklist should prove revocation or rotation of service accounts, API keys, SSH keys, CI/CD credentials, registry tokens, and any privileged account not federated through SSO.
Decision rule: If an account can still build, sign, deploy, or administer production, treat it as a live access path until the owning team shows it has been revoked or replaced. Do not accept “the employee account is disabled” as closure for non-SAML access.
Practitioner takeaway: Offboarding is complete only when every credentialed path, not just the primary directory login, has a clear owner, an inventory entry, and a revocation outcome.
Related resources from NHI Mgmt Group
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 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org