How should organisations implement JML workflows for human and machine identities?

They should use the same governance model for both, but not the same technical mechanics. Human identities usually start with HR-driven joiner events and manager-led mover reviews, while machine identities need ownership, expiry, and automated revocation tied to workload or service context. The key is to make access change with identity state, not with ticket closure.

Why This Matters for Security Teams

Joiner-mover-leaver workflows are straightforward for employees only until machine identities enter the process. Human access is usually tied to employment status, but service accounts, API keys, certificates, and workload identities often survive long after the service changes, the pipeline is retired, or the owner leaves. That gap turns JML into a control over identity state, not just HR state. In NHI Mgmt Group research, only 20% of organisations have formal offboarding and revocation processes for API keys, and 91.6% of secrets remain valid five days after notification, which shows how slowly revocation can happen in practice. See the Ultimate Guide to NHIs for the broader lifecycle context and the NIST Cybersecurity Framework 2.0 for governance alignment.

The real risk is that organisations often manage human joiners through HR and tickets, while machine identities are left to application teams, CI/CD owners, or cloud admins with no shared revocation standard. That creates orphaned credentials, stale privileges, and unclear ownership during service changes. In practice, many security teams encounter misuse of stale machine access only after a deployment, incident, or vendor handoff has already exposed it.

How It Works in Practice

Effective JML for human and machine identities starts with a common control objective: identity state must trigger access state changes automatically. For humans, the joiner event is usually sourced from HR or workforce systems, with provisioning based on role, location, and manager approval. For movers, the workflow should recertify entitlements and remove access that no longer matches the new role. For leavers, deprovisioning should disable accounts, revoke sessions, and remove access from downstream systems without waiting for ticket closure.

For machine identities, the same governance model applies, but the mechanics differ. There may be no HR record, so the authoritative events are service creation, deployment, ownership change, environment retirement, or pipeline decommissioning. Best practice is evolving toward workload ownership plus expiry: every secret, certificate, token, or service account should have a named owner, a purpose, a maximum lifetime, and an automatic revocation path. NIST guidance on identity and access control supports this operational logic, and the JetBrains GitHub plugin token exposure is a useful reminder that long-lived credentials often outlast the context they were created for.

• Define a source of truth for humans and a separate authoritative source for workloads, then map both into one JML policy.
• Use short-lived credentials where possible, and prefer automated rotation for secrets that cannot be eliminated.
• Require ownership on creation, with expiry dates and revocation triggers tied to service retirement or access review failure.
• Log issuance, use, renewal, and revocation so reviewers can trace identity state changes end to end.

Current guidance suggests that JML should be enforced through policy-as-code where practical, with approvals for exceptions and automated removal for routine events. These controls tend to break down when identity records are scattered across SaaS platforms, cloud accounts, and CI/CD systems because no single team can confirm which machine identity still has active reach.

Common Variations and Edge Cases

Tighter JML controls often increase operational overhead, so organisations must balance automation against false positives, service interruption, and developer friction. That tradeoff is especially visible when human movers need temporary overlap during role transitions, or when machine identities must stay active through blue-green deployments, incident response, or vendor-supported maintenance.

There is no universal standard for every edge case yet, but current guidance suggests treating exceptions as time-bound and explicitly approved. For humans, emeritus access, contractors, and rehires need distinct paths because employment status does not always map cleanly to access intent. For machine identities, shared service accounts, legacy certificates, and third-party integrations are the hardest cases because ownership is often unclear and revocation can break dependent systems. The Hugging Face Spaces breach illustrates why secret sprawl and weak lifecycle discipline can become an operational security failure rather than a policy issue.

Organisations should avoid treating ticket closure as proof of deprovisioning. Instead, confirm that access has actually been removed from the authoritative identity store, the secrets manager, the cloud control plane, and any downstream tool that cached the credential. That is the point where JML becomes measurable rather than procedural.

Related resources from NHI Mgmt Group

• How should organisations implement ISO 27001 access reviews across human and machine identities?
• What breaks when organisations manage human and machine privilege the same way?
• Who should be accountable for cloud PAM when human, machine, and AI identities all have access?
• How should organisations measure identity security maturity across human and non-human identities?