HR-driven provisioning can’t save us from standing privilege, token theft, or cloud sprawl.

The joiner-mover-leaver flow has been lorded for twenty+ years. It sits at the heart of every identity program, usually accompanied by a reassuring slide showing neat arrows between HR, an IdP, and a stack of SaaS apps. That diagram gives leadership a warm fuzzy feeling: accounts are created, roles are updated, and access is removed. What a delightfully ordered world.

Anyone running modern cloud environments knows reality looks nothing like that diagram.

The joiner-mover-leaver model assumes identities behave tidily. It assumes roles match tasks, access is predictable, and entitlements sit politely inside the IdP waiting for HR to announce a job title change in a perfect help desk ticket that starts, “Can you just…”. It assumes attackers wait for a leaver event before doing anything nefarious. All charming ideas, but none of them reflect how identity risk actually works in AWS, Azure, GCP, or a sprawling SaaS ecosystem.

JML is hygiene. Necessary, yes. But it’s not security. Not anymore.

Where Joiner-Mover-Leaver Stops, Cloud Risk Begins

A joiner-mover-leaver tool is a bridge. It moves data from HR into an identity provider and triggers high-level provisioning actions. Useful, but it solves about 5% of the identity problem. The remaining 95% live downstream, in the environments where real permissions are assigned, drift accumulates, and attackers operate.

This is where most organizations discover the gaps:

1. Stale entitlements

Roles grow like weeds. People collect access they don’t use. Temporary rights become permanent. Emergency permissions are never reeled back in. JML doesn’t check whether those entitlements are still required; it just creates or updates them based on the job title.

A “mover” event may adjust someone’s department, but if they picked up admin rights two years ago during an outage, that access stays put. It’s now an attack path waiting to be walked.

2. Standing privilege

The biggest risk in cloud isn’t a new account. It’s an old one with too much access. JML happily provisions chunky roles that were designed when cloud estates were small, and when everyone trusted everyone else. Those roles now grant dangerous amounts of standing privilege.

Attackers love standing privilege. It’s stable, predictable, and always available. Perfect for lateral movement.

3. Shadow permissions

Developers grant themselves direct cloud access and breakglass permissions because waiting on IT is slower than writing YAML. Engineers wire up service accounts at 2 a.m. to get a CI pipeline working. Contractors receive temporary rights that no one remembers to remove. None of this flows through HR. None of it appears in the joiner-mover-leaver process.

Shadow access with broad permissions is invisible to provisioning systems but visible to attackers. That’s a problem.

4. Token theft and session hijacking

JML has nothing to say about what happens after login. If an attacker steals a cookie (or biscuit, if you’re based in the UK), replays a token, hijacks a session, or abuses OAuth, the lifecycle workflow is irrelevant. The attacker is using a legitimate identity with legitimate rights. The joiner-mover-leaver process did its job, but the security team still has an incident on its hands.

The Identity Lifecycle Was Designed for Offices, Not Cloud Estates

The joiner-mover-leaver pattern was built when identities were human, on-prem, and slow-changing. Today, identities are:

• human
• machine
• ephemeral
• automated
• event-driven
• created by pipelines
• destroyed by deployments
• and often granted more rights than they should ever have

HR systems don’t model this world. They can’t. You can’t reduce cloud identity management to employment data. Attackers don’t care about organizational charts.

The Real Security Work Happens Between the Lifecycle Events

A modern identity security program focuses on what happens during the lifecycle — the messy middle where accounts are active, roles grow stale, tokens leak, and entitlements drift. This is where real breaches form.

To close the gap between JML and cloud reality, teams need three capabilities:

1. On-demand access instead of standing privilege

Least privilege only works if access is temporary. Rights should appear only when needed and disappear as soon as the task ends. This eliminates the long-lived permissions attackers rely upon. It also means a “mover” event doesn’t leave behind a trail of forgotten admin grants.

2. Entitlement intelligence across cloud and SaaS

Security teams need visibility into the full permission graph: who has access, who actually uses it, which rights are risky, which identities behave strangely, and where drift is creeping in. This can’t come from the IdP alone — the dangerous stuff is buried in AWS IAM, Azure RBAC, GCP IAM, Kubernetes, and countless SaaS platforms.

JML doesn’t look there. A proper identity security platform does.

3. Automated revocation and continuous cleanup

Attackers thrive on what organizations forget — idle accounts, dormant roles, neglected service accounts. Revocation should be automatic, triggered by context, usage, and risk signals, not waiting for an HR ticket. The moment an entitlement stops being used, it should be a candidate for removal. The moment behavior becomes abnormal, elevation should shut down.

Automation here is worth more than another HR data sync.

JML Isn’t Going Away. But It Isn’t Enough

The joiner-mover-leaver flow still has a job, but it can’t claim to be a complete identity strategy. It handles the beginning and the end of the lifecycle. Everything that matters in cloud security happens in the middle.

Provisioning is not governance. Lifecycle is not least privilege. HR-driven workflows don’t reduce attack paths — real-time identity intelligence and on-demand access do.

Most breaches now start with a legitimate identity misused in a way no HR system can predict. That’s why the organizations shifting from lifecycle automation to continuous identity security are the ones reducing risk, shrinking standing privilege, and closing gaps attackers prefer to exploit.

JML keeps the accounts tidy. Identity security keeps the organization safe.