Why do unused permissions become a security risk in JML programmes?

Why Unused Permissions Are a JML Security Problem

Unused permissions are not harmless leftovers. In a joiner-mover-leaver programme, they represent access that remains valid even after the business need has disappeared, which means the account carries more reach than the current role requires. That creates avoidable exposure, weakens least privilege, and turns a basic access review into a comparison against outdated entitlements rather than active work.

Unused permissions also make compromise more dangerous. If an account is taken over, the attacker inherits every permission that was never removed, including rights the legitimate user no longer relies on. In practice, that means the blast radius is larger than the organisation believes, because the access set reflects history, not current necessity.

For JML programmes, the core issue is lifecycle drift. A mover event may leave old-role access behind, or a leaver process may fail to revoke standing entitlements quickly enough. When that happens at scale, access reviews become less about confirming business need and more about cleaning up accumulated privilege, which is a slower and less reliable control posture.

How Stale Access Weakens Access Reviews and Governance

Access reviews depend on a meaningful baseline. If an account contains permissions that are technically assigned but no longer used, reviewers can approve or ignore them without recognising that the set is already oversized. That creates false confidence, because the review outcome may look compliant while the actual entitlement set still exceeds the principle of least privilege.

This is why unused permissions are often a sign of weak governance, not just operational clutter. They can hide role design problems, delayed deprovisioning, poor ownership clarity, or a mismatch between HR-driven events and identity system updates. The Joiner-Mover-Leaver (JML) Guide is useful here because it treats old-role access removal as part of the control itself, not a cleanup task after the fact.

When access recertification is based on stale entitlements, the organisation is certifying a problem state. The control may still be executed on schedule, but its evidence is weaker because the review no longer reflects genuine business need. That is why unused permissions should be treated as a lifecycle integrity issue, not merely an efficiency issue.

The strongest operational pattern is to compare granted access with observed use and current role requirement. Where permissions are consistently unused, the right question is not whether they were ever legitimate, but whether they still belong in the active entitlement model at all. The IAM and IGA Basics guide covers how entitlement governance, access review and least privilege fit together in that decision.

Why Unused Permissions Become Exploitable Standing Privilege

Unused permissions become a risk because attackers do not care whether a right is actively used, only whether it is still available. If they compromise an account, dormant permissions can be used immediately without additional escalation, which turns hidden excess access into an easy path to broader impact. That is especially serious when the entitlement includes admin functions, cross-system reach, or data access that the business no longer expects the user to have.

In many environments, the gap is between granted permissions and effective permissions. The account may appear normal in daily operation, but the unused rights remain present and available for abuse, lateral movement, or privilege escalation. The Cloud PAM and CIEM Guide is a strong reference point for this issue because it focuses on effective permissions, right-sizing, and the risk created by unused cloud access.

Unused permissions also persist when organisations keep broad access for convenience, future flexibility, or role ambiguity. That is where JML becomes more than a provisioning workflow: it becomes the control that prevents entitlement accumulation. The Privileged Access Management Guide is relevant because standing privilege and overprivilege are the same basic failure mode at different sensitivity levels.

Risk and Threat Considerations

Unused permissions matter because they extend the attacker’s options after compromise. Even if the user never exercises those rights, an intruder can, and the excess access may open sensitive systems, data, or administrative actions that are invisible to day-to-day operation.

Failure mechanism: Access is granted once, but not fully removed when the role changes or the business need ends, so dormant entitlements remain available as standing privilege. That creates a hidden path for abuse if an account is stolen or misused.

Impact: The organisation absorbs a larger blast radius, weaker review evidence, and a higher likelihood that one compromised account can reach more systems than intended.

Practitioner Guidance

What to prioritise: Remove permissions that are not needed for the current job role before you rely on access review outcomes. If the entitlement is not required for current work, it should not survive the next JML step simply because it is still technically assigned.

What to verify: Check whether reviewers are assessing actual business need or merely confirming that a permission exists. A review that never challenges unused access is measuring administrative completeness, not least privilege.

Common mistake: Treating unused access as low risk because it is inactive. In security terms, inactivity often means the right is overlooked, not harmless.

Practitioner takeaway: The quality of a JML programme is shown by how quickly it removes access no longer justified by the role, because stale permissions are both hidden attack surface and weak review evidence.

Related resources from NHI Mgmt Group

• Why do excessive permissions become a compliance and security risk in IGA programmes?
• Why do help desk processes become a security risk in identity programmes?
• Why does unused access create risk in identity security programmes?
• How should security teams handle unused cloud credentials before they become an access risk?