Teams that want tighter control over administrative rights usually face the same decision: keep granting access permanently and audit it, grant it on demand for short windows, or lock it behind a vault that brokers each session. Laid out in parallel below, the three options give a technology lead what is needed to choose deliberately. It frames the choice as an AccessOps question, meaning how privileged access is requested, approved, limited and closed in daily operation.
The yardsticks for comparing AccessOps models
Before judging, agree on criteria. We use five: how much standing power exists on a quiet day, how quickly a legitimate person can get what they need, how much evidence each approach leaves behind, how it handles a stolen session, and how much operational effort it demands. These map neatly onto the metrics the Ops Atlas lists in its discussion of access operations, such as the count of standing privileged accounts, time to access at the median and ninetieth percentile, and the share of grants actually used.
Model one: standing access with periodic review
This is the traditional pattern. People hold elevated rights continuously, and a scheduled review, often yearly, checks that each right is still justified. A common benchmark from the control catalogues cited by the Atlas is an annual review at minimum, with a flag for accounts dormant beyond roughly forty-five days.
- Standing power: high, because rights exist around the clock.
- Speed: excellent, since nothing needs requesting.
- Evidence: thin; you see who holds rights, not why a given action was taken.
- Stolen session: severe, because the stolen session inherits everything.
- Effort: low per day, heavy at review time.
The Atlas notes that US federal zero-trust maturity guidance places permanent access plus review at its entry stage, called Traditional. That does not make the model wrong for low-risk systems, but it does explain why it rarely satisfies a mature programme.
Model two: just-in-time eligibility
Here the person is eligible for a role but holds nothing until they request it, give a reason and pass an approval step, which may be automatic for on-call staff. Activation lasts a bounded period. In one widely used cloud directory service, the maximum activation window can be configured anywhere from one to twenty-four hours.
- Standing power: low; most of the day nobody holds the role.
- Speed: good once tuned, with minutes of delay rather than none.
- Evidence: strong, because every activation carries a stated reason and timestamp.
- Stolen session: reduced exposure window, though not eliminated.
- Effort: moderate; approvers and request queues must be maintained.
The Atlas is careful here. Just-in-time does not make a session attacker-proof; it shortens how long a stolen session is useful. It also warns that a grant is not a session: the credential may expire while a connection that was already open carries on. In its lab, a shell outlived its certificate by about twenty seconds, and cloud role sessions can run to their own expiry unless explicitly revoked.
Model three: vaulted and brokered sessions
In the third pattern, a broker holds the credentials and opens sessions on the user’s behalf, often recording the shell or screen. The user never sees the secret. One open-source-derived access platform caps request durations by policy; the Atlas cites a fourteen-day maximum setting in one major version, which shows that “brokered” does not automatically mean “brief”.
- Standing power: low, as secrets are hidden from users.
- Speed: variable; depends on broker health and workflow design.
- Evidence: the richest, since recordings show actions, not only grants.
- Stolen session: better contained if the broker can terminate it.
- Effort: highest, including storage; the Atlas puts shell recording in one tool at roughly twenty kilobytes per minute, small per session but cumulative.
The Atlas also points out that some capabilities are edition-gated. Session recording and multi-person approvals appear only in enterprise tiers of certain products, so check licensing before committing a design to paper.
Side-by-side summary
On standing power, model one scores worst and models two and three score well. On speed, model one wins, model two follows, and model three varies. On evidence, model three leads, model two is respectable, and model one is weakest. On effort, model one is lightest day to day and model three heaviest. No column produces a universal winner, which is the honest finding.
Choosing by system tier
Rather than pick one model for everything, match models to sensitivity. The Atlas proposes maximum grant lengths by tier, from one or two hours for the most critical systems to standing, annually reviewed access at the least critical tier. A sensible pairing follows from that ladder: brokered, recorded, dual-approved sessions for the top tier; just-in-time eligibility for the middle tiers; standing access with review for low-risk tools.
If you are still scoping which systems belong in which tier, our roadmap article written for incoming service clients shows one way to inventory services before applying controls, and the companion blueprint for mastering growth planning covers sequencing the work.
A worked scenario: the quarterly database migration
Imagine a platform team that performs a heavy database migration once a quarter. Under model one, the migration engineer simply holds administrator rights all year; the migration is fast and the audit trail is a calendar invite. Under model two, the engineer files a request two days ahead, states the change ticket, receives a four-hour window and loses it when the work ends. Under model three, the engineer connects through a broker, every command is captured, and a colleague can replay the session next morning.
For a once-a-quarter task, model one is plainly wasteful, because the rights sit idle for ninety days. Model three is defensible if the database holds regulated data. Model two is the usual compromise, and it fits the pattern the Atlas calls task-scoped access at the far end of its maturity ladder, where the grant is tied to the task rather than to the person.
Where the emergency account fits
None of the three models removes the need for a break-glass path. The Atlas insists that these accounts stay active permanently, by design, with at least two cloud-only credentials, phishing-resistant sign-in and an alarm on every use. The model you choose changes day-to-day behaviour; the emergency path covers the day the model itself is unavailable.
Pitfalls that apply to every model
- Blanket manager approval produces generic justifications that tell reviewers nothing.
- Emergency accounts need regular validation; leaving an approver list empty can even lock an organisation out of its own tenant.
- Infrastructure-as-code tools that authoritatively rewrite bindings can silently erase privileged-access settings.
- Recording everything but sampling nothing leaves evidence nobody reads.
The conclusion is modest. Move away from permanent rights where the risk justifies it, pick the lightest model that gives the evidence you need, and measure the result with the same few numbers every month.
