What breaks when user lifecycle management is handled partly outside central IAM?

Where central IAM stops, lifecycle control fragments

Once lifecycle management is split across central IAM and departmental tools, the system stops behaving like one revocation path and starts behaving like several. The practical break is not only delayed deprovisioning, but also inconsistent ownership of joiner, mover and leaver events, so the same person may lose one set of entitlements while retaining another set elsewhere. That is why lifecycle governance has to be treated as one control plane, not a set of local exceptions.

When that fragmentation exists, the answer depends on which side owns the authoritative event. Central IAM may close the directory account, but if a department still controls SaaS access, API tokens, or app-local roles, the effective identity remains active in the business systems that matter. The result is a gap between “disabled in directory” and “disabled everywhere,” which is exactly where residual access persists.

This is the same lifecycle problem described in IAM and IGA Basics: provisioning, entitlement management, and access review only work when the authority to grant and revoke access is aligned with the system of record. If local admins can override that model, the lifecycle process is no longer deterministic.

Why revocation becomes inconsistent at offboarding and role change

Offboarding exposes the failure first because it is the sharpest test of whether revocation is complete. A user who leaves may have their central account removed, yet still hold SaaS seats, shared mailbox access, API credentials, or departmental app roles that were never tied back to the central workflow. A mover event creates a different failure mode: old access should be removed at the same time new access is granted, but partial ownership often leaves both active.

That is why the lifecycle issue is broader than termination. Role changes can create privilege creep, standing access, and orphaned entitlements when central and local admins make separate decisions. The break is not only a delay, it is an ownership mismatch, because no one control path sees the full access picture.

The operational remedy is to make the lifecycle event authoritative across all systems that confer access. Joiner-Mover-Leaver (JML) Guide is the clearest fit for this pattern because it focuses on removing old-role access and revoking the tokens, keys and accounts that leavers leave behind.

What stays exposed when revocation is split across teams

When central IAM and local admins are both allowed to decide lifecycle outcomes, the biggest exposure is residual access to business applications and the data behind them. That can include SaaS apps, collaboration tools, support systems, finance platforms, cloud consoles, and any service that trusts an external directory only indirectly. If those systems are not driven by the same offboarding event, former users can continue to act with legitimate credentials.

Fragmented lifecycle control also makes audit evidence weaker. Teams may be able to show directory deactivation, but not complete removal of downstream access. In practice, that means the organisation may believe it has revoked access while the actual blast radius still includes live sessions, cached tokens, delegated app permissions, or manually administered local roles.

For cloud and application access, the issue often shows up as identity sprawl across platforms. The Identity Security Programme Guide is useful here because it frames centralised versus federated identity as a governance and operating-model choice, not just a tooling decision.

Risk and Threat Considerations

Split lifecycle ownership creates a real security exposure because revoked users can retain access after termination, transfer, or suspension. The threat is not theoretical: if local admins do not follow the central offboarding event, an account that should be inert can still reach sensitive applications, shared data, or privileged functions.

Failure mechanism: One control plane removes the directory or SSO link, but independent app owners keep their own entitlements, tokens, or local accounts active. Attackers do not need to defeat the central IAM if an unmanaged downstream path still authenticates them, and insiders can exploit the same gap after a role change or exit.

Impact: Organisations face persistent unauthorized access, delayed containment, audit failures, and a wider blast radius for former employees, contractors, or compromised accounts. The longer the gap persists, the more likely it is that stale access will be used, abused, or missed during incident response.

Practitioner Guidance

What to verify: Verify that offboarding and role-change events propagate to every application that can independently grant access, not just to the directory or SSO layer. If a team can approve access outside central workflow, it must also be able to prove revocation through the same event path.

What to prioritise: Start with the systems that hold sensitive business data, privileged functions, or externally reachable access paths. Those are the places where a missed revocation turns a process flaw into an exposure.

Decision rule: If the application can keep access alive after central IAM is changed, treat it as part of the lifecycle control scope and remove the exception. If it cannot be integrated, require compensating review, explicit ownership, and periodic reconciliation rather than assuming central deprovisioning is enough.

Practitioner takeaway: Central IAM only works as a lifecycle control when it is the authoritative revocation path everywhere access can persist, otherwise offboarding becomes partial and residual access becomes the default.

Related resources from NHI Mgmt Group

• What breaks when user lifecycle management is still handled manually in SaaS environments?
• What breaks when Linux user lifecycle management is handled manually in the cloud?
• What is the difference between runtime protection and NHI lifecycle management?
• What breaks when AI identities are handled outside IAM?