What breaks when lifecycle management stops at the main directory?

Orphan accounts and tokens can remain active in application-local stores after offboarding. That leaves access alive where the directory no longer reflects reality. The programme appears complete on paper, but the actual revocation step failed at the application layer, which is where attackers benefit.

Why This Matters for Security Teams

When lifecycle management stops at the main directory, offboarding becomes a paper exercise. The directory may show the account as removed, but application-local stores, API tokens, signing keys, and cached credentials can continue to function long after the employee or workload is gone. That gap creates a false sense of closure and turns revocation into a partial control, not a complete one.

This is especially damaging for Non-Human Identities because the real access path is often not the directory entry itself, but the secret or token held inside the application. NHI Management Group’s NHI Lifecycle Management Guide and Guide to the Secret Sprawl Challenge both point to the same failure pattern: central identity governance does not automatically reach every place a secret can live. Current guidance suggests treating the directory as only one control plane, not the control plane.

That distinction matters because attackers do not need the directory to be wrong in order to keep access alive. If an orphan token remains valid in an app, access persists until that token is actually revoked, expired, or replaced. In practice, many security teams discover this only after an offboarding review, incident response, or breach investigation shows the application layer was never touched.

How It Works in Practice

Effective lifecycle management has to follow the identity into the systems where it is actually consumed. For NHIs, that usually means cloud IAM, CI/CD, application configuration, secrets managers, service accounts, and local keystores. The directory should trigger the workflow, but it cannot be the endpoint. The operational goal is to ensure that disablement, rotation, and revocation propagate to every runtime dependency.

A practical model is to separate identity closure into four steps:

• Discover where the NHI is referenced, including embedded secrets and app-local stores.
• Revoke or rotate the credential at the source of use, not only in the directory.
• Invalidate cached sessions, refresh tokens, and downstream trust relationships.
• Verify removal with logging, secret scanning, and post-offboarding checks.

This aligns with the intent of the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0, both of which emphasize that identity controls must map to actual access paths and not just records in a system of record. In NHI practice, this often means automation: event-driven offboarding, just-in-time revocation, and short-lived credentials rather than long-lived static secrets. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is explicit that lifecycle discipline must include creation, use, rotation, and retirement as one continuous control chain.

The main implementation challenge is ownership. Directory teams, application owners, and platform teams often assume another group has completed revocation. These controls tend to break down when applications keep independent credential stores, because the directory cannot revoke what it does not directly govern.

Common Variations and Edge Cases

Tighter offboarding controls often increase operational overhead, requiring organisations to balance faster revocation against application stability and release friction. That tradeoff becomes visible in systems that use shared service accounts, legacy integrations, or manually managed secrets where immediate rotation can disrupt production. Best practice is evolving, but current guidance suggests that delay should be the exception, not the default.

Some environments also present edge cases where directory closure is only a signal, not an enforcement point. Examples include third-party SaaS connections, batch jobs with embedded credentials, long-lived refresh tokens, and signing keys used across multiple services. In those cases, lifecycle management needs a dependency map and a defined decommissioning sequence. The Ultimate Guide to NHIs — Static vs Dynamic Secrets is useful here because static secrets are the hardest to retire cleanly once they spread beyond a central directory. For broader governance context, the Top 10 NHI Issues highlights secret sprawl and weak rotation as recurring root causes.

Where teams rely on periodic reviews instead of event-driven revocation, the gap can remain open for weeks. That is why lifecycle controls should be measured by actual access termination, not by directory status alone. There is no universal standard for this yet, but the practical rule is simple: if the secret still works, the identity still exists.

Related resources from NHI Mgmt Group

• What breaks when identity lifecycle management is manual in Active Directory?
• How should organizations prioritize environments for NHI management?
• What is the difference between attack surface management and NHI governance?
• What is the main NHI risk in ServiceNow integrations?