Notifications
Clear all
Topic starter
06/07/2026 9:42 am
TL;DR: Manual joiner-mover-leaver processes still create ticket sprawl, delayed onboarding, slow revocation, and audit gaps, while Lumos cites CrowdStrike’s 2025 Global Threat Report that 80% of cyberattacks leverage identity-based methods. The real issue is that lifecycle governance built on human-paced tickets cannot keep up with access changes that need to happen in real time.
NHIMG editorial — based on content published by Lumos: JML Automation: Optimizing the Joiner-Mover-Leaver process with Lumos
By the numbers:
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Lumos's guide to JML automation and identity lifecycle control →
JML automation and lifecycle control: what IAM teams are missing?
Explore further
06/07/2026 9:57 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: JML automation exposes the limits of manual identity lifecycle control
