Automating Joiner-Mover-Leaver: Identity Lifecycle Done Right

Why the lifecycle is a security control, not a paperwork chore

Every account in your environment was created by a joiner event and should be destroyed by a leaver event. In between, movers change roles and accumulate access. When that lifecycle runs on tickets, spreadsheets, and someone's memory, it fails in predictable and dangerous ways: accounts that outlive the employee, permissions that outlive the job, and privilege that nobody remembers granting.

Attackers know this. Orphaned accounts and standing access are among the most reliable footholds in a breach, because they are valid credentials that no human is watching. Verizon's DBIR has for years put the human and credential element at the center of most breaches, and IBM's Cost of a Data Breach research consistently shows stolen or compromised credentials among the most expensive and slowest breaches to contain. Joiner-mover-leaver — JML — is the process that decides who holds those credentials and for how long. Automating it well is one of the highest-leverage security investments a mid-market organization can make.

The system of record: HR drives identity, not IT

The single most important design decision in identity lifecycle is choosing an authoritative source of truth. That source is your HR system — Workday, BambooHR, UKG, ADP, whatever you run payroll from — not your directory and not a helpdesk queue. HR knows the ground truth: this person was hired, changed departments, went on leave, or was terminated. Everything downstream should be a consequence of that record, not an independent decision.

The pattern we implement for clients looks like this:

1. HR is the system of record. A new hire, transfer, or termination is entered once, by the people who own that data.
2. An identity platform reads HR and provisions accordingly. The identity provider (IdP) creates, updates, or disables the account and its group memberships based on attributes like department, job code, location, and manager.
3. Downstream applications receive changes automatically through standards rather than manual clicks in a dozen admin consoles.

This inverts the common failure mode. Instead of IT reacting to a terminated employee days later, the leaver event fires the moment HR closes the record. The goal is that no human has to remember to do anything for the routine cases.

SCIM and SSO: the plumbing that makes it real

Two standards do the heavy lifting, and it is worth being precise about what each one does.

• SSO (single sign-on), usually via SAML or OIDC, handles authentication. When a user logs into an application, they authenticate against the central IdP. Cut off the IdP account and, for SSO-integrated apps, you cut off the login path immediately. This is why consolidating apps behind SSO is a deprovisioning win, not just a convenience.
• SCIM (System for Cross-domain Identity Management) handles provisioning. It is the API that pushes create, update, and deactivate operations from your IdP into each application, so a disabled user is actually disabled inside Salesforce, GitHub, or your ERP — not merely blocked at the front door.

The distinction matters because SSO alone leaves gaps. An app integrated for login but not for provisioning can still hold a live account, local password, or API token that survives after SSO access is cut. Prioritize SCIM provisioning for any application that stores sensitive data or supports local authentication. For everything that cannot speak SCIM, maintain an explicit manual runbook — you cannot automate it, but you can at least make sure it is never forgotten.

Getting this foundation right is the core of a managed identity and access management program: one IdP, SSO everywhere it is supported, SCIM provisioning to the systems that matter, and a documented fallback for the rest.

Birthright versus requested access

Not all access is equal, and treating it as one bucket is why role models collapse. Split it in two.

• Birthright access is what everyone in a given role gets automatically on day one: email, the intranet, the standard productivity suite, the tools their department universally uses. This should be provisioned by attribute the moment the joiner record lands, so a new hire is productive on their first morning without a single ticket.
• Requested access is everything sensitive, expensive, or role-specific: production systems, financial applications, administrative consoles, customer data. This should require an explicit request, an approval from a defined owner, and ideally a time bound.

The discipline is keeping birthright bundles small and specific. When "birthright" quietly grows to include high-value systems because it is convenient, you have recreated standing access under a friendlier name. A useful test: if you would be uncomfortable seeing that entitlement on an access review with no justification attached, it does not belong in a birthright bundle.

The mover problem: access that only ever grows

Joiners and leavers get attention. Movers are where real risk hides. When someone transfers from finance to operations, they almost always gain the new role's access and keep the old role's access, because revocation is nobody's explicit job. Do this for a few years across a workforce and you produce exactly the over-privileged accounts attackers dream of.

Automate the mover event as a true recalculation, not an addition. When the job code or department attribute changes in HR, the identity platform should compute the new correct entitlement set and remove what no longer applies, not simply layer new access on top. For privileged entitlements especially, a role change should revoke and re-request rather than carry forward. Standing administrative rights are the highest-value target in any environment, which is why they belong in a privileged access management program that vaults credentials and grants elevation just-in-time — temporary, approved, and recorded — instead of leaving admin access permanent and invisible.

Timely deprovisioning: the number that matters

The single metric that best captures lifecycle health is time-to-deprovision — how long between a termination in HR and access actually being revoked everywhere. For a routine departure, an automated pipeline can make that near-instant. For a high-risk termination, it needs to be immediate and complete.

A defensible leaver runbook:

1. Disable, do not delete, first. Immediately block sign-in and revoke active sessions and tokens across SSO and SCIM-connected apps. Deletion can wait; containment cannot.
2. Kill live sessions and refresh tokens. A disabled account with a valid session is still a live account. Force revocation, not just a password reset.
3. Reclaim and rotate shared secrets. Terminated staff who knew service account passwords or API keys mean those secrets are now compromised. Rotate them.
4. Handle data and mailbox delegation on a defined schedule so a manager keeps access to work product without the account staying alive.
5. Fully deprovision after the retention window, and confirm the account is gone from every downstream system, not just the directory.

Do not forget service and machine accounts. They rarely have MFA, often carry broad rights, and almost never have an owner who leaves — so they quietly become permanent standing access. Give every non-human account a named human owner and a review date.

Access reviews: proving the model still holds

Automation drifts. Applications get connected outside the standard process, manual grants pile up, and edge cases accumulate. Periodic access reviews — access certification — are how you catch that drift and prove control to auditors. Have entitlement owners recertify who has access to sensitive systems on a schedule (quarterly for the crown jewels, at least annually elsewhere), and feed every "remove this" decision back into the automation so it sticks.

This is also where lifecycle and least-privilege reinforce each other. Continuous, identity-driven verification is the backbone of a zero trust implementation: access is granted by current role and revoked the moment that role changes, rather than assumed because an account happens to exist. JML is the mechanism that keeps the zero trust promise honest over time.

Where to start

If your offboarding still depends on someone remembering to disable an account, fix that before you buy anything else. Wire HR to your IdP as the trigger, get your highest-value applications onto SCIM provisioning, split birthright from requested access, and instrument time-to-deprovision so you can see the process working.

intSignal builds and runs automated identity lifecycle programs — HR-driven provisioning, SCIM and SSO integration, privileged access controls, and recurring access reviews — so orphaned accounts and standing access stop being the quiet risk in your environment. If you want a candid assessment of where your JML process leaks today, talk to our team.