Identity lifecycle maturity is the real mid-market IAM gap

At a glance

What this is: This is an analysis of why manual joiner-mover-leaver management creates identity lifecycle risk in mid-sized firms, with the key finding that maturity gaps, not staffing alone, drive the problem.

Why it matters: It matters because IAM, IGA, and PAM teams need lifecycle controls that keep access aligned as people join, move, and leave, or they inherit audit friction and avoidable exposure.

Context

Identity lifecycle management is the discipline of creating, updating, and removing access as a person moves through an organisation. In mid-sized firms, the problem is not the idea of JML, but the operational gap between business change and access change.

Manual lifecycle processes fail because they depend on tickets, tribal knowledge, and disconnected app administration. That leaves onboarding slow, mover access stale, and leaver accounts behind the point where accountability should have ended.

Key questions

Q: What breaks when joiner-mover-leaver workflows are mostly manual?

A: Manual workflows create delay, inconsistency, and missed revocations. Access changes arrive late, offboarding becomes dependent on ticket discipline, and audit evidence is fragmented. The result is entitlement creep and a larger attack surface because the organisation cannot prove that access changed when the business event changed.

Q: Why do role changes create so much access creep?

A: Role changes create access creep because organisations are faster at adding new access than removing old access. The old permissions are often still usable, carry no immediate operational pain, and therefore survive the transition. The result is accumulated access from previous roles that expands blast radius and weakens least privilege.

Q: How do security teams know whether offboarding is actually working?

A: Security teams should measure completion, not process start. Confirm that accounts are disabled, tokens are revoked, privileged roles are removed, and recovery methods are no longer usable across every connected system. Sampling terminated identities is a practical way to prove whether revocation is real or only recorded.

Q: What is the difference between birthright access and overprovisioning?

A: Birthright access is the minimal, predefined access a role needs on day one. Overprovisioning is when extra permissions are added for convenience, speed, or uncertainty and then never removed. The first supports consistent onboarding. The second creates long-term privilege sprawl and makes later governance much harder.

Technical breakdown

Why manual joiner-mover-leaver workflows break down

Joiner-mover-leaver, or JML, becomes fragile when access decisions are handled as isolated tickets instead of lifecycle events. The underlying issue is that each application, directory, and admin console becomes its own decision point, so provisioning and revocation drift apart. Birthright access is often added inconsistently, movers keep old entitlements, and leavers are only partially deprovisioned. In practice, the organisation has identity data, but not identity governance. Practical implication: treat JML as a system design problem, not a helpdesk workflow.

Practical implication: centralise lifecycle decisions around authoritative identity events rather than manual requests.

How access creep accumulates during role changes

Access creep happens when a mover gets new privileges without the older ones being removed. This is not just clutter, it changes the effective blast radius of a compromised account because the user retains permissions tied to previous roles, projects, or managers. Attribute-based updates reduce this drift by recalculating entitlements when identity attributes change in the source of truth. The technical point is that authorisation should be recalculated from current role context, not layered indefinitely. Practical implication: role change automation needs removal logic, not only add-access logic.

Practical implication: design mover workflows to revoke outdated access at the same time new access is granted.

Why offboarding must revoke more than the directory account

Leaver failures persist because organisations often disable a primary directory account and assume the job is done. In reality, the identity may still exist in SaaS apps, privileged tools, shared systems, VPNs, and token-based services. That creates orphan accounts and residual sessions that remain valid after the employee relationship has ended. A mature offboarding process treats termination as a multi-system revocation event with logging and traceability. Practical implication: deprovisioning must reach every connected system, not just the master directory.

Practical implication: verify that offboarding closes downstream access paths, session state, and tokens across connected systems.

Threat narrative

Attacker objective: The attacker objective is to exploit stale or orphaned access to move through systems without needing fresh authorisation.

1. Entry occurs through normal hiring or role-change activity when access is provisioned manually and inconsistently across systems.
2. Privilege accumulation follows as movers retain old permissions while new ones are added, expanding the usable access surface.
3. Impact emerges when leaver accounts, shared tools, or orphaned access remain active after departure, creating avoidable audit and security exposure.

Breaches seen in the wild

• Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity lifecycle maturity is the real control plane for mid-sized IAM. Mid-sized firms do not fail because JML is conceptually hard; they fail because lifecycle events are not enforced as governed identity changes. When access is spread across SaaS, directories, and local admin consoles, the programme no longer has a single authoritative moment for grant, change, and revoke. The practitioner conclusion is that lifecycle maturity is the difference between access administration and access governance.

Access creep is a lifecycle failure, not a role-design annoyance. The common pattern is additive access with no corresponding removal event, which means the organisation keeps accumulating permissions tied to old duties. That weakens least privilege and makes audits reflect historical accumulation rather than current need. The practitioner conclusion is that mover governance must be designed to subtract access as deliberately as it adds it.

Leaver offboarding is where accountability ends or lingers. A directory disablement is not an offboarding strategy if downstream credentials, sessions, and shared accounts remain valid. The failure mode is persistent identity reach after employment has ended, which turns exit processing into a standing risk window. The practitioner conclusion is that offboarding should be measured by complete revocation, not ticket closure.

Birthright access should define the minimum usable identity, not a convenience bundle. When organisations over-grant on day one, they create a future cleanup problem that JML later has to unwind. A clear birthright model keeps onboarding consistent while preserving role-based restraint. The practitioner conclusion is that joiner automation only works when the baseline entitlement model is explicit and enforceable.

Improper offboarding is the named lifecycle gap mid-market teams must treat as a governance defect. In OWASP-NHI terms, the issue is not simply that access exists, but that it outlives the identity lifecycle that justified it. That same failure pattern appears in human IAM when offboarding is incomplete and in NHI governance when credentials survive ownership changes. The practitioner conclusion is that lifecycle controls must be validated against revocation completeness, not just provisioning speed.

What this signals

Lifecycle maturity is the practical test of IAM maturity in mid-sized firms. When access changes are tied to business events rather than tickets, the organisation can keep pace without growing headcount at the same rate as the app estate. The signal to watch is whether joiner, mover, and leaver events are handled as one connected control loop.

Incomplete offboarding is a governance failure with cross-domain consequences. The same pattern that leaves human accounts active also appears when organisations lose track of non-human credentials and shared access paths. Teams that care about IAM resilience need to look at revocation completeness, not just onboarding speed.

JML becomes a control discipline when the baseline entitlement model is explicit. That means role-based onboarding, attribute-driven updates, and deterministic removal when the identity changes state. For practitioners, the real question is whether lifecycle controls are reducing manual exception handling or merely documenting it.

For practitioners

• Define authoritative lifecycle triggers Tie join, move, and leave events to a single source of truth so provisioning and revocation follow business status rather than ad hoc tickets.
• Remove access on role change Build mover workflows that recalculate entitlements and explicitly remove permissions that no longer match the person’s current job attributes.
• Verify downstream offboarding Check that leaver processing disables directory access, closes SaaS entitlements, revokes tokens and sessions, and covers privileged tools and shared accounts.
• Document birthright access by role Create a minimal baseline entitlement set for each common role so onboarding is consistent and does not rely on managers asking for extra access.
• Measure revocation completeness Track how many systems are updated when a person leaves and use the gaps to find where manual deprovisioning still depends on memory or tribal knowledge.

Key takeaways

• Mid-sized firms do not just have a provisioning problem. They have a lifecycle governance problem that shows up as slow onboarding, stale entitlements, and incomplete removal.
• The riskiest stage is not only leaver processing, but the accumulation of access across role changes that turns ordinary accounts into overextended ones.
• A credible JML programme has to prove complete revocation across all connected systems, not just show that a directory account was disabled.

Key terms

• Joiner Mover Leaver: Joiner Mover Leaver is the identity lifecycle process for creating, changing, and removing access as people enter, change roles, or leave an organization. It governs provisioning, modification, and deprovisioning across systems, ensuring access matches current job needs and reducing orphaned accounts, privilege creep, and residual access risk.
• Identity Lifecycle Governance: Identity lifecycle governance is the set of processes that create, change, review, rotate, and revoke access across human and non-human identities. It matters because access risk usually increases when lifecycle events are slow, incomplete, or disconnected from the systems that rely on them.
• Birthright Access: The baseline set of entitlements that a user should receive by default because of role, department, or another stable attribute. It is a governance construct, not a blanket permission model. The control challenge is proving that the baseline stays current as jobs, applications, and ownership change.
• Access Creep: Access creep is the gradual accumulation of permissions that remain after a role change, project move, or temporary exception ends. It matters because legacy access often creates hidden conflicts, especially when a user retains rights across systems that should be controlled separately.

Deepen your knowledge

NHI governance, identity lifecycle management, 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 IAM programme, it is worth exploring.