How should security teams govern joiner, mover, and leaver access when approvals are federated?

Why federated JML approvals still need one policy spine

Federated approvals work only when the central team defines the rules that every approver must follow, even if the approvers sit in business units or regional functions. That means role changes, access requests, and leaver events all need the same enforcement logic, the same evidence trail, and the same authoritative source of truth for employment status and identity state.

When organisations blur local discretion with local policy, approval outcomes drift. The usual failure mode is not that teams forget to approve access, but that they approve against different standards, which makes entitlement review, revocation timing, and exception handling inconsistent across the lifecycle.

For lifecycle governance, the practical anchor is to treat JML as a continuously governed process rather than a periodic cleanup exercise. The central policy should decide who can approve what, under which conditions, and with which mandatory data inputs, while local managers or system owners supply the business justification.

How federated approval authority should be structured

The most reliable model separates three things: policy, approval, and execution. Central security or identity teams own policy and minimum control requirements; local approvers decide whether the access is justified for their area; downstream provisioning systems enforce the decision and record the evidence. That separation preserves accountability without turning every request into a central bottleneck.

Joiner events usually need the cleanest input model because they define birthright access and baseline entitlements. Mover events are harder because they must remove old access as explicitly as they add new access, and that is where federated approval breaks down if the old role is not reviewed as part of the same change. Leaver events should be treated as revocation events, not administrative paperwork.

A sound pattern is to anchor lifecycle state to authoritative HR or contractor data and then let the approval workflow consume that state as a control input. Joiner-Mover-Leaver (JML) Guide is a useful reference for how federated workflow, deprovisioning, and authoritative source design fit together.

What has to be monitored after approval is delegated

Delegating approval authority does not remove the need for central visibility. Security teams still need to detect stale access, approval exceptions, privilege creep, and leavers whose access survives beyond the expected cutoff. The key question is whether lifecycle changes are evaluated continuously, because federated review models often fail when they rely on quarterly recertification alone.

The evidence trail matters as much as the decision itself. If a business owner approves access outside policy, the central team should be able to see that exception, who accepted it, what compensating control exists, and when the exception expires. Without that visibility, federated approval becomes a convenience layer rather than a governable control.

Leaver controls are especially sensitive because delayed revocation can leave tokens, keys, and privileged sessions active after employment ends. NHI Lifecycle Management Guide is relevant here because the same lifecycle discipline applies wherever credentials or access artifacts outlive the business event that justified them.

What good federated governance looks like in practice

Good practice is to make local approvers accountable for business justification, while central governance remains accountable for policy integrity, control design, and exception oversight. That usually means role-based approval guardrails, automated checks against HR status, and periodic reporting on overdue removals, orphaned access, and access drift.

Teams should also keep ownership explicit. If a mover request reassigns someone into a sensitive function, the old manager should not be the only reviewer of the old access, and the new manager should not be able to grant access that conflicts with centrally defined separation-of-duties rules. Federated approval works best when each approver can decide only inside a bounded policy envelope.

For a broader control baseline, IAM and IGA Basics helps connect approval delegation to entitlement governance, while OpenID Connect Core 1.0 is useful where lifecycle decisions also depend on federated identity assertions and session trust.

Risk and Threat Considerations

Federated approvals create risk when local convenience outruns central control. The main exposure is approval drift, where different managers approve different access standards, and revocation lag, where leavers or movers keep access longer than policy allows. That creates privilege creep, audit gaps, and a larger blast radius if an account is later abused.

Failure mechanism: Local approvers accept or retain access without the same minimum checks, revocation timing, or evidence requirements, so lifecycle changes are only cleaned up during periodic review instead of being enforced as events happen.

Impact: Excess access persists, orphaned accounts remain active, and compromised or departed users may retain access to systems, data, or tokens that should have been removed.

Practitioner Guidance

What to verify: Confirm that every federated approver is constrained by centrally defined policy, that HR or contractor status feeds the workflow, and that approvals cannot bypass mandatory revocation checks for mover and leaver events.

Decision rule: If a request changes role, employment status, or sponsor, require the workflow to evaluate removal of prior access before granting new access. If the workflow cannot prove that sequencing, treat the case as a higher-risk exception.

What good looks like: The organisation can show who approved, what policy rule was applied, what identity event triggered the request, and when the related access was removed or recertified. The strongest signal is that cleanup is automatic for routine lifecycle changes and exceptions are rare, visible, and time-bound.

Practitioner takeaway: Federated approval is safe only when local decision-making is bounded by central policy and lifecycle data, because delegation without continuous enforcement turns JML into an audit problem instead of an access-control one.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should teams govern Jira access through joiner-mover-leaver workflows?
• What do security teams get wrong about managing joiner, mover, and leaver access at scale?