In enterprise environments, privileged (admin) access tends to accumulate under the “we might need it” rationale. Then one day:
- An account leaks, and the blast radius is enormous
- Someone leaves the company, but their access stays
- During an incident everyone signs in with the same “shared admin” and audit collapses
If you’re in operational leadership and you wave this off as “the IAM team’s problem”, you’re actually generating operational risk. The most critical mistakes get made in the most critical moments — through exactly these accesses.
In this post I’ll share a practical model that pulls access review out of “an annual compliance meeting” and onto a sustainable cadence.
The goal: not “who has admin?” but “how do we grant admin access?”
In mature systems the question shifts to:
- For how long does admin access last?
- Under what conditions is it granted (MFA, device, network, ticket)?
- When access is granted, what do we log?
- When the timer runs out, is it revoked automatically?
This shift improves not just security, but operational calm.
Three access classes: Persistent, JIT, Break-glass
1) Persistent access (the least preferred)
Reserved for platform owners only — narrow scope, justified.
2) Just-in-Time (the default target)
Triggered by ticket/incident, time-bound, and logged.
3) Break-glass (emergency)
The riskiest path, but also the most necessary — which is why it has to be the most disciplined:
- Separate identity (not the same account as your day-to-day)
- Separate MFA (ideally a hardware key)
- Tight time limit
- Mandatory post-event review
Cadence: weekly small, monthly medium, quarterly heavy
The cadence I’ve seen actually work in the field:
- Weekly (15 min): newly opened admin accesses, JITs that didn’t close, exceptions
- Monthly (45–60 min): role/group hygiene, orphan accounts, service ownership changes
- Quarterly (90 min): policy updates, MFA/device compliance, audit findings, drills
The aim here isn’t a “perfect report” — it’s continuous hygiene.
Operational runbook: the access revocation scenario
One of the most valuable reflexes during an incident is to treat revocation not as a “last resort” but as a controlled tool.
A revocation runbook should at minimum cover:
- Locking the user account / token revoke
- Rotating SSH keys / API keys
- Renewing the break-glass key (if needed)
- Scanning the “last 24 hours of admin actions” logs on the affected systems
This runbook should live with the ops team too, not just security.
Metrics: keep the signal, don’t drown the team
The practical metrics I track:
- Persistent admin count (trend)
- Average duration of JIT accesses
- Number of accesses that expired but weren’t closed
- Break-glass usage count and post-review completion rate
The point of metrics isn’t to “score” anyone — it’s to see where risk is piling up.
Closing thought
Privileged access isn’t only the backbone of security — it’s the backbone of operational leadership too. Once you put access review on a cadence, you stay calmer in incidents, audits come out cleaner, and — most important — risk doesn’t quietly accumulate where nobody is looking.