Table of Contents
- Permanent Privilege Is Permanent Exposure
- Where Privilege Accumulates
- Just-in-Time Elevation
- Approval Without Theatre
- Session Recording and Its Limits
- Break-Glass Accounts Done Properly
- Machine Privilege Is the Larger Problem
- An Implementation Sequence
- Common Pitfalls
- Conclusion
- Frequently Asked Questions
Key takeaway: Administrative access should be requested, approved, time-limited, and recorded — not held permanently. The change converts “an attacker who phishes this person owns everything” into “an attacker who phishes this person owns nothing until they also obtain approval.”
Permanent Privilege Is Permanent Exposure
An engineer holds administrative rights because they occasionally need them. That access is available every minute of every day, including the minutes when their laptop is compromised or their session token is stolen.
The exposure window is not the time they spend performing administrative tasks. It is the entire duration they hold the entitlement, which is typically years.
This matters because privileged accounts are what attackers pursue specifically. The intrusion sequence — initial access, credential harvesting, lateral movement — is fundamentally a search for administrative credentials, because those convert a single compromised endpoint into control of the environment.
Standing access makes that search short. If the person whose workstation was compromised is a domain administrator, the attacker has finished. If administrative rights require a request, an approval, and expire after an hour, the attacker holds a normal user account and must find another path.
The change is not about trusting people less. It is about ensuring that compromising a person does not immediately mean compromising the environment.
Where Privilege Accumulates
Excessive standing privilege is rarely granted deliberately. It accumulates through predictable mechanisms.
Role change without revocation. Someone moves teams and retains the previous team’s access alongside the new. Over several years this compounds into an accumulated entitlement nobody would grant deliberately.
Temporary access made permanent. Elevated rights granted for an incident or a project, never revoked because nobody tracked the grant.
Group nesting. A group added to another group inherits its permissions. Nested several levels deep, effective access becomes genuinely difficult to determine, and additions have consequences nobody anticipated.
Convenience during troubleshooting. Broad rights granted because narrowing them would require determining exactly what was needed, under time pressure.
Shared administrative accounts. One credential used by several people, which eliminates attribution entirely and cannot be revoked for one person.
Local administrator rights on workstations. Frequently granted broadly, and it enables credential theft from memory, which is the standard escalation route.
The pattern common to all of these is that granting is easy and observable while revoking is effortful and invisible. Absent a process that removes access automatically, entitlement only accumulates.
A useful diagnostic: list every account with administrative rights in your primary directory and ask, for each, when it was last used for an administrative task. The answer for a substantial fraction will be never or years ago.
Just-in-Time Elevation
The core mechanism. Rather than holding administrative rights permanently, a user requests them when needed, receives them for a bounded period, and loses them automatically.
Normal state: engineer@example.com — standard user, no admin rights
Request: "Need production database access to investigate #4471"
Approval: automatic for this role and resource, or manager approval
Grant: 60 minutes, scoped to that database only
Session: recorded, all commands logged
Expiry: access removed automatically, no action requiredWhat this changes concretely. The exposure window shrinks from years to the duration of actual use. Every elevation carries a recorded business justification, which makes review meaningful. Attribution is unambiguous because the request is tied to an individual. And unusual patterns become visible — elevation requests at odd hours, or for resources unrelated to the stated reason, are detectable signals that standing access provides no equivalent of.
Two implementation details determine whether it works in practice.
Elevation must be fast. If requesting access takes ten minutes and interrupts an incident, engineers will find ways around it — shared accounts, retained credentials, permanently elevated service accounts. Automatic approval for expected role and resource combinations, with the request taking seconds, is what makes adoption real.
Scope must be narrow. Elevation to “administrator” rather than to “this specific resource” reproduces the original problem with a timer attached. Resource-scoped grants are the point.
Approval Without Theatre
Approval workflows fail in two opposite directions, and both are common.
Too much approval produces rubber-stamping. A manager receiving forty requests daily approves them without reading. The control exists on paper and provides nothing, while adding delay that pushes engineers toward workarounds.
Too little approval means elevation is available to anyone who asks, which reduces the control to a time limit.
A workable middle ground is risk-tiered. Automatic approval for expected combinations of role and resource — a database engineer requesting read access to a database they routinely work with — with the record and time limit providing the value. Manager approval for access outside the person’s normal scope. Two-person approval for the highest-sensitivity operations: production data modification, security control changes, key material access. And out-of-hours requests treated as higher risk regardless of resource, because that is when unusual activity concentrates.
What makes approval meaningful rather than ceremonial is that the approver sees information relevant to a decision: who is asking, for what, why, whether this is normal for them, and what has changed recently. An approval prompt showing only a name and a resource cannot produce a considered decision.
Session Recording and Its Limits
Recording privileged sessions serves several purposes and is frequently oversold.
What it genuinely provides: reconstruction during incident investigation, evidence for audit requirements, and a deterrent effect on deliberate misuse. The deterrent is real — people behave differently when they know actions are recorded.
What it does not provide: prevention. Recording is entirely retrospective. An attacker with valid elevated access performs their actions and the recording documents them afterwards.
Practical considerations that determine whether recordings are useful. Recording that nobody reviews provides only the deterrent and the audit trail — reviewing a sample, or triggering review on anomalous sessions, is what extracts more value. Recordings themselves contain sensitive data and require protection at least equal to the systems they document. And command logging is generally more useful than screen capture, because text is searchable while video requires someone to watch it.
The most valuable form is a searchable log of commands executed with their output, linked to the elevation request that authorised the session. That combination answers “what did this person do and why were they permitted to” in one query.
Break-Glass Accounts Done Properly
Every environment needs emergency access for the case where normal authentication fails — the identity provider is down, the automation is broken, or the person who held the only credential has left.
These accounts are simultaneously necessary and the highest-risk objects in the environment. Handled poorly they become the standing privilege problem in concentrated form.
Properties of a break-glass account done correctly:
Credentials split so no single person can use them alone, physically stored, with the split parts held separately. Excluded from conditional access policies specifically, because those policies are what may be failing. Every use generating immediate alerts to multiple people, not a log entry someone might read later. Tested periodically, because an emergency credential that does not work is worse than none. Rotated after every use and on a schedule regardless. And documented with explicit criteria for when use is justified.
The failure modes are equally specific: a break-glass credential in the same password manager that may be unavailable, a credential nobody has tested in three years, use that generates no alert, or an account whose existence is undocumented so nobody knows it should be monitored.
Machine Privilege Is the Larger Problem
Human privileged access receives most attention. Service accounts hold more privilege in aggregate and are protected considerably less well.
The pattern: an automation account created for a deployment pipeline, granted broad rights because determining the minimum was difficult, with a static credential that never expires, used by a system nobody currently owns.
These cannot use interactive approval workflows, which is why the answers differ:
Workload identity federation. The platform attests to a workload’s identity and issues short-lived credentials. No static secret exists to steal, which eliminates the problem rather than managing it.
Short-lived certificates for service-to-service authentication. Mutual TLS with certificates measured in hours.
Scoped tokens per operation. A pipeline that deploys one service holds a credential permitting exactly that, not general deployment rights.
Mandatory ownership metadata. Every service account has an accountable human. Accounts without one are disabled rather than inherited by nobody.
Usage-based review. Accounts not used in a defined period are disabled automatically. This is the only mechanism that reliably removes accumulated accounts.
Anomaly detection on machine authentication. A service account authenticating from a new location or performing operations outside its pattern deserves the same attention a human anomaly receives.
Workload identity federation is the highest-value item, because a credential that does not exist cannot be leaked, committed to a repository, or found in a container image.
An Implementation Sequence
Ordered so early stages deliver value and enable later ones:
Inventory privileged accounts and their last administrative use. This is the diagnostic that motivates everything else, and the results are usually persuasive without further argument.
Remove unused privilege. Accounts with administrative rights and no administrative activity in a year are pure exposure. This is the cheapest available reduction.
Separate administrative from daily-use accounts. An administrator reading email with administrative credentials means any successful phish is an administrative compromise.
Eliminate shared administrative accounts. Attribution is impossible and revocation affects everyone.
Implement just-in-time elevation for the highest-value resources first. Production databases, cloud administrative roles, security tooling. Not everything at once.
Add recording and justification capture. Once elevation is request-based, recording attaches naturally to the request.
Remove local administrator rights from workstations. Significant effort, and it closes the standard credential theft path.
Address service accounts. Ownership metadata, usage-based disablement, then migration to workload identity.
Establish and test break-glass procedures. Frequently deferred and worth doing before it is needed.
Common Pitfalls
Elevation that is slow. Engineers route around friction, usually in ways that are worse than the original risk.
Broad elevation with a timer. Scope matters as much as duration. “Administrator for an hour” is not much better than permanently.
Approval without decision-relevant information. Produces rubber-stamping, which is a control that exists without functioning.
Recording nobody reviews. Provides deterrence and audit only. Sampling or anomaly-triggered review extracts more.
Untested break-glass credentials. Discovered non-functional during the emergency they exist for.
Ignoring service accounts. They hold more aggregate privilege than humans and are protected by a static string.
Administrative accounts used for email and browsing. Any successful phish becomes an administrative compromise immediately.
Conclusion
Standing administrative access means the window of exposure equals the duration of employment. Just-in-time elevation shrinks it to the duration of actual use, and adds a recorded justification, unambiguous attribution, and detectable patterns as a consequence.
Start with the inventory, because listing privileged accounts alongside their last administrative use makes the argument by itself. Remove the unused privilege immediately. Separate administrative credentials from daily-use accounts so a routine phish is not an administrative compromise. Then implement elevation for the highest-value resources, keeping it fast enough that nobody works around it and narrow enough that it means something.
And treat service accounts as the larger problem they are. They outnumber humans, hold broad permissions, and are protected by static credentials that never expire. Workload identity federation removes the credential entirely, which is a better outcome than storing it more carefully.
Frequently Asked Questions
Does just-in-time access slow down incident response? Only if implemented poorly. Automatic approval for expected role and resource combinations means elevation takes seconds. Emergency paths with post-hoc review rather than pre-approval handle the genuine exceptions.
What elevation duration is appropriate? Long enough to complete the task without repeated requests, short enough to bound exposure. One to four hours suits most work. Extension on request is better than long default grants.
How is resistance from engineers handled? By making the workflow fast and by explaining the threat model — the control exists because their credentials are the target, not because they are distrusted. Slow implementations generate justified resistance.
Should session recording apply to all administrative access? Command logging, yes — it is cheap and searchable. Full screen recording is proportionate for the highest-sensitivity systems and generates volume nobody reviews if applied everywhere.
Are shared administrative accounts ever acceptable? Only as break-glass credentials with split control and alerting on use. For routine work they eliminate attribution and cannot be revoked selectively.
How can excessive privilege be reduced without breaking things? Use access logs to determine what each account actually exercised over a meaningful period, remove what was never used, and monitor for failures. Empirical rather than theoretical, and considerably safer than guessing.
What about vendors and contractors requiring privileged access? Time-bounded, scoped to specific systems, recorded, and revoked at engagement end automatically rather than manually. Third-party access is a common breach vector precisely because revocation depends on someone remembering.
