When JML stops at the directory or IdP, users can keep local accounts and embedded permissions inside the application long after they should lose access. That creates privilege persistence, weak audit evidence, and manual cleanup after changes or terminations. The governance failure is not the lifecycle process itself, but its inability to reach the application boundary.
Why This Matters for Security Teams
When JML only updates the directory or IdP, it creates a false sense of control: the user appears removed, but the application still recognizes a local account, cached role, API token, or embedded permission. That gap undermines offboarding, access reviews, and incident response because the true enforcement point sits inside the application boundary. Current guidance from the OWASP Non-Human Identity Top 10 and NHI Management Group research on the Ultimate Guide to NHIs both point to the same operational risk: identity lifecycle controls are only effective when they reach every place access is enforced.
For security teams, the problem is not just leftover access. It is the absence of trustworthy evidence that access was actually removed, which makes audit responses fragile and prolongs breach dwell time. The issue also shows up in legacy applications that do not support centralized provisioning, SCIM, or modern federation, so the team must rely on manual cleanup and periodic reconciliations. In practice, many security teams discover stale local access only after a termination, role change, or exception review has already failed to remove it.
How It Works in Practice
Effective JML has to extend beyond the directory into the application itself. That usually means establishing a clear system-of-record for identity changes, then mapping those changes to local accounts, application roles, service bindings, and any secrets or tokens associated with the account. Where the application supports it, automated deprovisioning should disable the account, revoke sessions, and remove entitlements at the same time. Where it does not, the fallback is a reconciled control set that compares HR events, IdP status, and application-local membership on a schedule.
The practical sequence is straightforward:
- Trigger offboarding or role change from the authoritative source, usually HR or IAM.
- Check whether the legacy application has a local account, nested group, or embedded role.
- Disable or delete the local identity, then revoke associated API keys, tokens, and service credentials.
- Record evidence that the application boundary was reached, not just the IdP.
- Reconcile exceptions through periodic access reviews and targeted cleanup.
This is especially important because NHI Management Group has shown that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, a finding covered in the Ultimate Guide to NHIs. That same pattern appears in legacy apps that keep local permissions after the directory entry is gone. In those environments, policy-as-code and workflow automation help, but they do not eliminate the need for compensating controls when the application lacks lifecycle hooks. These controls tend to break down when the application has no API for account removal and no reliable audit log, because the team cannot prove the deprovisioning actually happened.
Common Variations and Edge Cases
Tighter JML enforcement often increases operational overhead, requiring organisations to balance strong removal controls against legacy-system limitations and application ownership gaps. The hardest cases are apps with shared admin accounts, locally managed roles, or hard-coded credentials that survive user departure. There is no universal standard for this yet, but current guidance suggests prioritising the systems with the highest privilege or the weakest auditability first, then moving outward to lower-risk applications.
Legacy environments also create exceptions that look harmless but are not: a disabled directory account may still allow login through a local password, a stale group membership may continue to grant report access, or an old API token may keep automation alive after the user is gone. The operational answer is to treat the application itself as an enforcement point, not a passive consumer of identity events. That usually requires stronger coordination between IAM, app owners, and IT operations than many organisations have today. The broader risk profile is visible in NHI Management Group research, where the 52 NHI Breaches Analysis reinforces how often stale credentials and incomplete revocation turn into real incidents.
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-03 | Stale local accounts and unrevoked secrets are classic NHI lifecycle failures. |
| NIST CSF 2.0 | PR.AC-4 | Access revocation must be enforced consistently across system and application boundaries. |
| NIST SP 800-63 | Identity proofing and lifecycle assurance lose value if downstream app access persists. |
Ensure deprovisioning reaches every app account, token, and secret with evidence of revocation.
Related resources from NHI Mgmt Group
- Why does relationship-based access control matter for application and NHI governance?
- What breaks when SaaS subscriptions are not tied to access reviews?
- What breaks when each application team writes its own authorization logic?
- What do teams get wrong about policy engines and application access control?
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
