JML automation exposes the limits of manual identity lifecycle control

At a glance

What this is: This is a practitioner-focused case for automating JML workflows, with the key finding that manual identity lifecycle handling creates security, compliance, and operational drag.

Why it matters: It matters because joiner-mover-leaver controls sit at the intersection of human IAM, NHI lifecycle discipline, and access governance, so weak lifecycle handling expands risk across the whole identity programme.

By the numbers:

• 80% of cyberattacks leverage identity-based methods.

👉 Read Lumos's guide to JML automation and identity lifecycle control

Context

Joiner-mover-leaver, or JML, is the identity lifecycle process that provisions access when someone joins, adjusts it when they change roles, and removes it when they leave. The governance gap is not the concept itself, but the fact that many organisations still run it through tickets, spreadsheets, and manual approvals that lag behind real workforce change.

That matters to IAM and identity governance teams because delayed revocation and role-change handling create privilege creep, orphaned access, and audit problems in the same control plane that should enforce least privilege. The same lifecycle discipline also applies to service accounts and AI agents, which is why lifecycle governance cannot stay human-only in modern programmes.

Key questions

Q: What breaks when JML is still managed through manual tickets and spreadsheets?

A: 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.

Q: Why do role changes create privilege creep in identity programmes?

A: Role changes create privilege creep when old entitlements are left in place and new ones are layered on top. That happens most often when access is adjusted manually or without entitlement-level review. The fix is not just faster provisioning. It is ensuring mover events remove obsolete permissions as reliably as they add new ones.

Q: How do you know if JML automation is actually working?

A: JML automation is working when the access outcome matches the lifecycle event across all connected systems, with no unexplained exceptions. Look for fast revocation on leaver events, accurate entitlement updates on mover events, and complete audit logs that show what changed and why. If any of those are missing, the automation is incomplete.

Q: Who is accountable when access remains after offboarding?

A: Accountability sits with the identity and access governance owners, the system owners who approve or execute access changes, and the business process that failed to ensure revocation. In regulated environments, frameworks such as the NIST Cybersecurity Framework 2.0 expect organisations to prove that access removal is controlled, repeatable, and evidenced.

Technical breakdown

Why manual JML workflows break at scale

Manual JML depends on people noticing changes, creating tickets, and closing them in the right order. That model fails when workforce change is continuous and access spans SaaS, on-prem, and cloud systems. The technical problem is not just delay. It is state drift, where the HR record, identity provider, and application entitlements stop matching each other. Once that happens, access decisions become inconsistent, and the organisation loses confidence that what is provisioned is also what is authorised. Automation replaces that drift with policy-driven triggers tied to joiner, mover, and leaver events.

Practical implication: map each identity source and remove ticket-only steps where lifecycle state must stay synchronised.

How policy-based provisioning and deprovisioning work

Policy-based JML uses attributes such as role, department, location, and employment status to drive access actions automatically. Onboarding creates the right baseline entitlements, mover events update or remove obsolete access, and leaver events revoke access across target systems. The value is not simply speed. It is deterministic enforcement, because the same input state should always produce the same access outcome. That consistency is what makes JML useful as a control, not just as an admin convenience. It also improves traceability because the access change is tied to an event, not a manual handoff.

Practical implication: define lifecycle triggers and entitlement rules centrally, then test them against HR and IdP events before broad rollout.

Why audit-ready JML needs visibility, not just automation

Automation without visibility only hides the gaps faster. A mature JML process needs entitlement-level insight, logging, and proof of who had access, when it changed, and why it changed. That is what turns lifecycle management into an audit control rather than a workflow shortcut. For security teams, the critical question is whether access removal is actually complete across all connected systems, including exceptions, temporary access, and app owner actions. If those artefacts are missing, the programme can look automated while still leaving residual risk behind.

Practical implication: verify that every lifecycle event produces an auditable trail across provisioning, modification, and revocation.

Threat narrative

Attacker objective: The attacker aims to exploit stale or excessive lifecycle access before governance catches up, turning identity drift into unauthorised activity or persistence.

1. Entry begins when manual onboarding, mover, or offboarding handling creates a delayed or incomplete access state in the identity lifecycle.
2. Escalation follows when stale entitlements, overprovisioned roles, or unrevoked access remain active after the business event that should have changed them.
3. Impact occurs when those lingering permissions enable insider misuse, unauthorised access, or failed audit outcomes across critical systems.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Manual JML is now a control failure, not a process inconvenience. When onboarding, movers, and leavers are handled through tickets and spreadsheets, identity state drifts faster than the governance team can correct it. That drift creates privilege creep, orphaned access, and audit unreliability across human IAM and adjacent machine identities. The practitioner conclusion is simple: lifecycle handling must be treated as a security control with measurable outcomes, not an administrative workflow.

Identity lifecycle governance is only as strong as the slowest revocation path. Offboarding that is technically documented but operationally delayed leaves residual access in place after the employment relationship changes. That is the same failure mode that appears in NHI programmes when tokens, keys, or accounts outlive their intended owner. The implication is that lifecycle governance has to be judged by revocation completeness, not by whether a ticket was closed.

JML automation exposes the difference between policy intent and entitlement reality. Organisations often assume role rules are enough because they describe what access should exist. In practice, the entitlement layer tells the truth, and manual handling makes that layer diverge from policy. This is where identity governance becomes measurable: if role changes do not reliably remove obsolete access, least privilege is a declaration, not a control. Practitioners should focus on entitlement accuracy and event-to-action consistency.

There is a growing convergence between human lifecycle control and NHI lifecycle control. The same governance patterns used for employees, movers, and leavers increasingly apply to service accounts, tokens, and AI-driven identities. That means lifecycle thinking can no longer stay inside HR-driven IAM workflows. Practitioners need one governance model that can express join, change, and exit across human and non-human actors without losing accountability.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For a deeper governance baseline, see NHI Lifecycle Management Guide for lifecycle practices that apply across human and non-human identities.

What this signals

Lifecycle automation is becoming the only practical way to keep identity state aligned with business state. Manual controls cannot absorb the pace of role churn, SaaS sprawl, and distributed ownership that modern enterprises already live with. The governance question is no longer whether automation is useful, but whether identity teams can prove that access changes are complete and reversible at the same speed as the organisation itself.

With 91% of former employee tokens still active after offboarding in our research, the operational signal is clear: revocation remains the weakest point in the lifecycle chain. Teams should expect auditors, risk leaders, and platform owners to ask for evidence of closure, not just workflow activity.

The next step is to align JML controls with broader identity governance architecture, including reviews, exception handling, and lifecycle evidence. The organisations that treat lifecycle events as measurable security outcomes will be better positioned to extend the same discipline to service accounts and AI-driven identities.

For practitioners

• Tighten lifecycle triggers to HR and identity events Connect joiner, mover, and leaver workflows directly to authoritative HRIS and identity provider signals so access changes happen from state change, not from ticket completion.
• Measure revocation completeness, not ticket closure Track whether access has actually been removed from every target application, including SaaS, on-prem, and exception-based access, before treating offboarding as complete.
• Review entitlement drift after every role change Compare current app entitlements against the new job state whenever a mover event occurs, and remove permissions that no longer match the person’s function.
• Add audit evidence to each lifecycle step Preserve who approved the change, what access changed, when the change happened, and which systems were updated so recertification and audit reviews do not depend on manual reconstruction.

Key takeaways

• Manual JML handling creates identity drift that weakens least privilege, slows revocation, and increases audit risk.
• The scale of the problem is already visible in offboarding failures, lingering access, and identity-based attack patterns.
• Practitioners should treat lifecycle events as security controls and verify that access changes are complete across every connected system.

Key terms

• Joiner-Mover-Leaver: A Joiner-Mover-Leaver process manages access across the full employee lifecycle, from onboarding to role changes to departure. In practice, it is the control plane that should keep identity, entitlements, and business state aligned so access is granted, adjusted, and removed at the right time.
• Privilege Creep: Privilege creep is the gradual accumulation of permissions beyond what a user or account needs for current work. It usually happens when role changes are handled inconsistently or revocation is delayed, leaving old access in place alongside newly granted access.
• Entitlement: An entitlement is a specific permission inside an application or system, such as a role, group, privilege, or capability. Entitlements matter because they are the real units of access control, and lifecycle governance fails when those permissions do not match current identity state.

What's in the full article

Lumos's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step automation examples for onboarding, mover events, and offboarding across connected applications
• Specific integration patterns with HRIS, identity provider, and ITSM workflows that drive lifecycle triggers
• Practical examples of entitlement rules, RBAC and ABAC policy logic, and app-level access bundles
• Platform-oriented discussion of the Lumos workflow model and how its AI identity agent is positioned in the article

👉 Lumos's full article covers lifecycle workflow examples, access adjustment logic, and offboarding automation details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.