Usage-Based Access Review

The conventional access review sends a manager a list of their reports' entitlements and asks which to keep. The manager does not know what billing-service-writer grants, cannot tell whether anyone used it, and faces a real cost for removing something needed and none for keeping something unnecessary. So they approve the list. Entitlements grow monotonically, and the review produces an audit artefact and no change.

Usage-based review inverts the default. The question is not "should this person keep this?" but "has this been used in the last 90 days?" If not, it is removed, with a documented path to get it back in minutes. The reviewer's job becomes justifying an exception rather than evaluating a list, which is a question they can actually answer.

Why it matters

Privilege creep is what converts one compromised account into a serious incident, because a credential's lateral reach is the union of everything it can touch and that union is accumulated rather than designed. Reducing it is the containment control with the largest effect per unit of effort, and it is also the one most organisations cannot do, because their review mechanism removes nothing.

It also changes what an audit means. A review that approves everything demonstrates a process. A review that removes a measurable fraction of entitlements every cycle demonstrates a control, and the removal rate is a number a board can read.

Implementation patterns

• Collect last-used evidence from the platform. Cloud providers have published last-accessed data per identity and per action since around 2019, and recommender services compute the permissions actually exercised over a window. Application entitlements need the equivalent from audit logs, which is one reason read auditing on sensitive paths pays for itself.
• A 90-day default window, long enough to cover a quarterly process and a holiday, short enough that the removal set is meaningful. Shorten it for high-privilege roles.
• Remove by default with self-service restoration behind the approval the original grant needed. The restoration path is what makes removal politically possible.
• Exempt break-glass roles explicitly. They are unused by design, so review their grant list instead.
• Run it on workload identities too. Service roles accumulate faster than human ones and nobody owns them, so the largest reduction usually sits there.

Industry example

This is a platform-capability story rather than one company's. The major cloud providers ship the evidence: last-accessed timestamps per service and per action, and recommenders that propose a reduced policy computed from observed calls. The tooling has been generally available since roughly 2019 and is still rarely wired into a recurring process, which is the gap between having the data and having the control. Estates that wire it up find most identities exercise a small fraction of the actions they hold.

Failure scenarios

• Break-glass access deleted because it was unused, discovered during the incident it existed for.
• Last-used data that lags or is incomplete, so a permission used through an unlogged path looks unused. This is the common failure in application entitlements rather than cloud ones.
• Restoration that takes a day, which turns every removal into an outage and gets the programme cancelled.
• Reviewing humans only, leaving service accounts with the broadest grants untouched and the real lateral reach unchanged.

Trade-offs

The honest cost is interruption. A removal landing on release morning is somebody's bad day, and the mitigation is restoration in minutes plus notice before the first cycle, not a softer rule.

When not to use it

Usage is the wrong signal where absence of use is the design. Break-glass and incident-response roles, disaster recovery credentials, legal-hold accounts and anything exercised annually belong under a grant review instead. Small organisations are a poor fit for the machinery: with 15 engineers and one cloud account, reading the policy list together once a quarter removes more privilege than a tooling programme would, and the tooling cost is real. The practice earns its keep when the entitlement count is past what anyone will read, which is usually a few hundred identities, or the moment the first review is approved wholesale without being read.

Interview question

Q: "Your quarterly access review has a 100% completion rate and has never removed a permission. The auditor is satisfied and you are not. Redesign it, and tell me what you would do about the roles that are unused on purpose."

What a strong answer covers: the incentive asymmetry that makes managers approve everything; inverting the default to remove-unless-justified; a 90-day window; fast self-service restoration as the precondition; exemption for break-glass and seasonal access; removal rate rather than completion rate; and workload identities.

Quick check

Quiz: Why does a usage-based rule need an exemption list first? Answer: break-glass and annual compliance roles are unused by design, so the rule deletes the access an incident depends on.

Flashcard: What metric shows an access review is a control? The proportion of entitlements removed each cycle, not the completion rate.