Manual JML breaks when identity state changes faster than human workflows can process them. The result is delayed onboarding, stale access after role changes or departures, and poor auditability. Once access and business state diverge, organisations lose least-privilege consistency and create a persistent window for misuse or compliance failure.
Why This Matters for Security Teams
Manual joiner-mover-leaver handling turns identity governance into a queueing problem, not a control problem. Every ticket, spreadsheet update, and approval handoff adds delay between a business event and the access state that should follow it. That lag is where risk accumulates: new hires wait for access, movers keep permissions from prior roles, and leavers remain active long after departure. For NHIs, the same pattern is even more dangerous because service accounts, API keys, and automation identities often outlive the people who requested them. The issue is not just operational friction. It is a persistent gap between intended access and actual access, which undermines least privilege, auditability, and zero trust alignment. Current guidance in the NIST Cybersecurity Framework 2.0 treats identity governance as a core protective function, but manual workflows rarely keep pace with modern identity volume. In practice, many security teams discover stale access only after a role change, offboarding event, or incident has already exposed the mismatch.
How It Works in Practice
Effective JML for both human and non-human identities depends on lifecycle events being authoritative and machine-enforced, not manually interpreted. The practical model is: HR, IAM, ITSM, or workload orchestration emits a change event; policy evaluates what access should exist; provisioning and revocation happen automatically; and evidence is retained for review. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and NHI Lifecycle Management Guide both emphasize that lifecycle control is only reliable when issuance, rotation, revocation, and offboarding are tied to a source of truth.
Practical JML design usually includes:
- Automated onboarding triggered by verified identity or workload creation events.
- Role- or attribute-based access assignment, with approvals only for exceptions.
- Immediate deprovisioning on termination, contract end, or workload retirement.
- Short-lived secrets and just-in-time access instead of standing permissions.
- Logging that proves when access changed, who approved it, and what was revoked.
For NHIs, that often means pairing workload identity with ephemeral credentials so the identity state can be changed faster than tickets can move. For humans, the same principle reduces drift when people change teams, vendors rotate, or projects end. This aligns with zero trust and the identity lifecycle expectations in NIST CSF 2.0, especially where access review and revocation are meant to be continuous rather than periodic. These controls tend to break down when access depends on informal manager approvals or shared spreadsheets because the source of truth becomes inconsistent across HR, IAM, and application owners.
Common Variations and Edge Cases
Tighter JML control often increases operational overhead, requiring organisations to balance speed against assurance. That tradeoff is real, especially where legacy applications cannot consume event-driven provisioning or where multiple business units define “joiner” and “leaver” differently. Current guidance suggests that these exceptions should be isolated, documented, and reduced over time rather than accepted as the default.
A few edge cases matter:
- Contractors and third parties may need separate lifecycle rules, since their offboarding often depends on procurement or vendor management rather than HR.
- Shared accounts and break-glass access should follow a separate process, because they do not map cleanly to standard JML flows.
- NHIs created by CI/CD, scripts, or agents may have no human owner in the usual sense, so lifecycle ownership must be assigned to a service or team.
- High-churn environments may require policy-as-code and workflow automation to prevent revocation delays from piling up.
NHIMG’s Top 10 NHI Issues notes that visibility and lifecycle ownership remain common failure points, which is why manual JML often creates hidden privilege persistence long after the business event has ended. For regulated environments, the audit problem is just as serious as the security problem, because a spreadsheet cannot prove timely revocation with the same confidence as an automated control trail. The model breaks most visibly in large enterprises with high identity churn, where manual routing cannot keep pace with role changes across systems and time zones.
Related resources from NHI Mgmt Group
- What breaks when privileged access is still managed through manual tickets?
- What breaks when access is managed through too many manual steps?
- What breaks when JML processes are still manual in a SaaS-heavy environment?
- What breaks when privileged access is managed through scripts and manual reconciliation?
