What should teams do when most permissions go unused but still remain active?

Why unused permissions still count as active exposure

Permissions are not risk-free just because nobody has exercised them recently. If a right remains granted, it can still be used later by the original user, a delegated process, a service account, or a compromised session. The practical question is not whether the permission is dormant today, but whether it can still be invoked tomorrow without a fresh decision.

Unused access also obscures the real blast radius. A profile may look acceptable when measured by day-to-day behaviour, yet still contain rights that would become powerful immediately after compromise, role drift, or a policy change. That gap between routine use and maximum reachable scope is where overpermission turns into exposure.

That is why teams should distinguish exercised permissions from granted permissions. Exercised access shows what people or systems actually do; granted access shows what they can do. A stable security review needs both views, because the second one is what determines whether dormant rights are waiting to be inherited or abused.

How dormant rights become a security problem

dormant permissions usually fail in one of three ways. First, they outlive the business need that justified them, so access lingers after the task has changed. Second, they create hidden escalation paths, especially where broad roles, overrides, or inherited group membership make the maximum technical scope far larger than normal work patterns suggest. Third, they expand the impact of compromise, because an attacker does not need to follow the usual pattern of use to benefit from a permission that is already there.

This is why rights that seem harmless in an access review can still be valuable to an attacker. A rarely used admin entitlement, a stale cloud permission, or an old automation grant can all be turned into a shortcut once a credential, session, or token is taken over. In practice, this is the difference between a tidy permissions report and a meaningful security boundary. Cloud PAM and CIEM Guide is useful here because it explains how effective permissions, escalation paths, and right-sizing should be evaluated together, not separately.

In non-human contexts, dormant access is even more dangerous because automation tends to preserve whatever was once granted. If an agent, workload, or integration can still use a standing right, that right may survive long after the original workflow or owner has changed. AI Agent Authorisation Guide and Just-in-Time Access and Zero Standing Privilege Guide both reinforce the same operational lesson, standing access should be temporary by default, not merely reviewed occasionally.

What teams should change in access review practice

Teams should stop treating access review as a binary yes or no exercise. A useful review asks four questions: who has the permission, when was it last used, what system or data it can reach, and whether that reach is still justified. If the answer to any of those is unclear, the permission is a candidate for removal, narrowing, or time-bound reissue.

The best next step is to right-size by actual use, not by historical entitlement. That means revoking rights that are never exercised, collapsing broad roles into narrower ones where possible, and separating exceptional override access from routine access. Where the permission is genuinely needed but rarely used, make it eligible rather than standing, and require re-approval for activation. This is the core logic behind Privileged Access Management Guide, which ties privilege review to vaulting, JIT access, and zero standing privilege.

For cloud environments, do not judge only by named roles. Effective permission often comes from inherited policies, cross-account trust, wildcard rights, and hidden escalation paths. A right can be unused in daily operations and still remain the most important thing to remove because it changes the technical ceiling of what an actor can do. Cloud PAM and CIEM Guide is especially relevant when teams need to separate effective permissions from nominal assignments.

Practitioner Guidance

What to verify: Compare granted permissions against last-use data, not just role names. If a permission has not been exercised for a meaningful period, confirm whether it is still required for a break-glass case, a seasonal workflow, or an unattended integration before leaving it in place.

Decision rule: If the permission can reach production data, admin functions, or cross-domain trust, treat it as live exposure until proven otherwise. If it is only needed occasionally, convert it to eligible or just-in-time access instead of keeping it permanently active.

Common mistake: Teams often trust the apparent normality of user behaviour and forget the maximum technical scope. That is how broad overrides, inherited group rights, and old automation grants survive long after the original need has disappeared.

Practitioner takeaway: The right measure is not how often access is used, but how much damage it can still do while waiting unused.

Related resources from NHI Mgmt Group

• How should security teams govern Active Directory service accounts?
• Why do unused permissions remain a risk even after teams find them?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?