Who is accountable when joiner, mover, and leaver changes are not reflected in privileged access revocation?

Accountability usually sits with the team that owns identity governance and the team that enforces privileged access, because both control a different part of the lifecycle. Governance defines who should have access, while runtime controls decide when that access expires. If either side fails, the organisation can end up with orphaned privilege and incomplete audit evidence.

Why This Matters for Security Teams

Joiner, mover, and leaver failures become a privileged access problem the moment a role change, transfer, or exit is not reflected in runtime revocation. The ownership split is usually simple in theory and messy in practice: identity governance defines entitlement intent, while privileged access controls enforce removal and expiry. When those two layers drift, orphaned access can survive well past the business need. NHI Mgmt Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys in the Ultimate Guide to NHIs.

This is why accountability cannot be assigned only to the identity team or only to the PAM team. The practical answer is shared accountability with clear control boundaries, backed by evidence that revocation actually happened. NIST control language in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that access enforcement, review, and revocation must be operational, not merely documented. In practice, many security teams discover the gap only after an audit exception, a surprise access path, or a breach has already exposed it.

How It Works in Practice

Accountability should be mapped to the control point that failed. If the joiner, mover, or leaver event was never triggered, the identity governance owner is accountable for lifecycle hygiene, authoritative source mapping, and approval workflows. If the event occurred but privileged access remained active, the PAM or workload access owner is accountable for revocation latency, token expiry, and exception handling. For NHI and service-account estates, the same logic applies, but the runtime layer matters more because secrets and tokens often outlive the human event that should have invalidated them.

Operationally, strong programs connect HR, IAM, PAM, and secrets management so that leaver events trigger immediate downstream actions: disable interactive access, revoke sessions, rotate secrets, and verify that dependent tools can no longer authenticate. Guidance from the OWASP Non-Human Identity Top 10 is especially useful here because many failures are not about missing policy, but about untracked credentials that keep working after a change. NHIMG research on the Ultimate Guide to NHIs also shows that excessive privilege and weak rotation are common, which makes missed leaver events materially more dangerous.

• Identity governance owns the source-of-truth event and entitlement decision.
• PAM or secrets owners own revocation, rotation, and session termination.
• Application owners own downstream dependencies that may need re-authentication.
• Security operations own evidence, monitoring, and exception follow-up.

When the process is mature, accountability is documented as a chain of custody for access removal, not a single team’s burden. These controls tend to break down when cloud permissions, CI/CD secrets, and third-party integrations all revoke on different schedules because no single system can prove end-to-end deprovisioning.

Common Variations and Edge Cases

Tighter revocation often increases operational overhead, requiring organisations to balance speed of cut-off against false positives and business interruption. That tradeoff is real when a mover event changes only part of a user’s responsibility, because not every entitlement should be removed, and not every token can be revoked without breaking production workflows. Best practice is evolving toward event-driven, context-aware review rather than fixed batch recertification, but there is no universal standard for this yet.

Edge cases matter most in hybrid estates. A human leaver may trigger clean IAM deprovisioning while their associated service account, API key, or automation token remains valid for days. The opposite also happens: a platform team rotates a secret, but the identity record still shows active access, creating audit confusion. NHIMG data in the Key Challenges and Risks section highlights how often secrets remain exposed long after notification, which is exactly why revocation evidence should be checked at the credential layer, not just the directory layer.

For organisations operating under formal control frameworks, the practical answer is to assign accountability to both control owners with a measured SLA: governance owns correctness of the event, PAM owns timeliness of revocation, and audit owns proof. Where that breaks down is in third-party access and shared admin accounts, because ownership is often ambiguous and revocation requires coordination outside the organisation’s direct control.

Related resources from NHI Mgmt Group

• Who should be accountable for keeping joiner mover leaver access current?
• How should organisations automate joiner mover leaver access changes?
• Who is accountable when API-driven access changes affect contracts, licences, or user permissions?
• Who is accountable when a compromised integration changes repository settings or adds unauthorized access?