JML for NHIs is the lifecycle process for joining, moving, and leaving non-human identities across systems. It covers provisioning, changing, and removing service accounts, API keys, tokens, certificates, and agent credentials with access tied to current function, scope, and risk, so dormant or excessive privileges do not persist.
What JML for NHIs Means in Practice
JML for NHIs is the lifecycle discipline for non-human identities, from creation and activation through role changes to removal, so access stays aligned to current function and exposure.
It treats service accounts, API keys, tokens, certificates, and agent credentials as governed access objects rather than static setup artefacts. That matters because access that is no longer needed, or was never fully reviewed, becomes a durable security weakness.
Why JML for NHIs Is a Security Control
The security value of JML is that it prevents privilege from outliving the job, workflow, or integration it was created for. Without it, dormant credentials, stale roles, and forgotten secrets can remain active long after the underlying service, deployment, or owner has changed.
For non-human identities, that creates a direct path from lifecycle failure to overprivilege, orphaned access, and unnecessary standing trust. A mature JML process should therefore connect provisioning, modification, and deprovisioning to source-of-truth ownership and current business need, as described in the NHI Lifecycle Management Guide.
Where JML Breaks Down
JML failures usually come from incomplete visibility rather than a single bad control. Teams may know a service exists, but not every token, certificate, delegated grant, or embedded secret it uses, which makes clean offboarding and scope reduction difficult.
Changes are also risky because movers are often re-platformed, re-scoped, or repurposed faster than the surrounding governance can keep up. If old permissions are not removed when new ones are added, the identity accumulates privilege over time instead of being re-baselined.
Removal is the most dangerous phase when credentials are shared, hardcoded, long-lived, or reused across environments. That is why the broader NHI issue set ties lifecycle management to ownership, inventory, and access governance, not just account deletion, and why the Top 10 NHI Issues is a useful companion reference.
How Organisations Operationalise NHI JML
Effective JML starts with discovery and ownership, then ties each non-human identity to a business service, technical owner, and expected lifecycle. That makes it possible to tell whether an identity should be rotated, re-scoped, suspended, or removed when the workload changes.
It also needs a practical way to reconcile access across cloud, SaaS, and internal systems, because the same identity may appear in multiple control planes. The strongest programmes pair JML with access review, secret hygiene, and periodic recertification so changes are not limited to one onboarding or offboarding event.
For a broader governance view that connects joiner-mover-leaver handling to entitlements, role design, and machine identity governance, see the Joiner-Mover-Leaver (JML) Guide and the IAM and IGA Basics reference.
Risk and Threat Considerations
When NHI JML is weak, attackers and internal misuse both benefit from credentials that should have been removed but were not. The result can be lingering access, lateral movement, unauthorized use of tokens or keys, and a larger blast radius when a single automation or integration is compromised.
Failure mechanism: lifecycle drift leaves stale, overprivileged, or orphaned non-human identities active after a role change, system retirement, or owner change, and those identities become reusable access paths for abuse or compromise.
Impact: exposed secrets, persistent unauthorized access, and harder incident containment, especially when the identity can reach production systems, signing workflows, or sensitive APIs.
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 |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | JML for NHIs governs credential issuance, rotation, and revocation across lifecycle events |
| AC-2 — Account Management | JML for NHIs is fundamentally account lifecycle control for service accounts and related identities | |
| AC-6 — Least Privilege | JML reduces residual access by shrinking permissions when function or ownership changes | |
| Recommendation — Manage non-human authenticators through issuance, rotation, and revocation tied to lifecycle changes. Provision, modify, and disable non-human accounts through a governed lifecycle process. Remove unnecessary access as soon as the non-human identity no longer needs it. | ||
| CIS Controls v8 | CIS-5 — Account Management | CIS account management directly supports lifecycle control over non-human identities and credentials |
| Recommendation — Inventory and govern non-human accounts so stale access can be removed promptly. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | JML for NHIs directly addresses offboarding failures that leave credentials active |
| Recommendation — Revoke access, secrets, and ownership when a non-human identity is retired. | ||
Practitioner Guidance
Why practitioners should care: JML for NHIs is not just an onboarding checklist, it is the control that stops machine access from becoming permanently excessive. If your process only creates identities but does not reliably narrow or remove them, privilege creep will accumulate across environments.
What to watch for: identities without clear owners, credentials that never expire, movers whose old access remains in place, and leavers whose tokens or certificates still validate. Those are the signals that JML is functioning as an administrative event rather than a lifecycle control.