What does time-bound, approval-gated elevation actually remove from an intruder's options?
answer
- bounds when, not where
- no privilege at a random moment
- expiry does not reach a live session
- the requester can be the compromised one
- break-glass is a standing right by design
basics
~20 sTime-bound elevation removes permanent membership as a target: an account compromised at a random moment holds no active privilege, and using it needs a request and an approver. It does not touch privilege already active, and bounds when, not where.
solid answer
~50 sJust-in-time elevation replaces continuous membership of a privileged group with a request that is approved, granted for a fixed window and then withdrawn. What it genuinely removes is the standing target: an intruder who compromises the account at an arbitrary moment finds no active privilege, and any use has to pass through a request another person sees. What it does not remove is substantial. Code already running with an elevated token keeps it - expiry withdraws the membership, not the session or token already issued. If the intruder controls the requester's own workstation, he can raise the request himself, and approvals granted under time pressure are frequently rubber stamps. A window of hours is no obstacle to an affiliate whose whole operation takes hours. And if the granted role is administrator on everything, the change bounded *when*, not *where* - so pair it with scoped roles.
go deeper
Know the difference between privilege you always hold and privilege you request for a bounded window, and that the second is what just-in-time elevation means.
Be ready to say exactly what it removes - the standing target and unilateral action - and what it leaves: active tokens, a compromised requester, and unscoped roles.
Show sequencing judgment: gate the rarely used, high-consequence rights, scope roles first, and design the break-glass path with a named owner and post-use rotation.
Own the friction budget across the estate - who absorbs the approval delay, whether approvers have real context, and how you keep the control from decaying into a queue.
## What "standing" means and what replaces it A standing right is privilege that exists continuously, whether or not anyone is using it. An account permanently in a privileged group is privileged at 03:00 on a Sunday, and is therefore privileged at the exact moment it is compromised. Just-in-time elevation replaces that with a workflow: the account is a member of nothing privileged by default; when the holder needs to act, he requests activation, an approver grants it, membership exists for a bounded window - typically an hour or a few - and is then withdrawn automatically. Interviewers ask this because both the enthusiasm and the disappointment are predictable, and the useful candidate can say precisely which is warranted. ## What it genuinely removes **The standing target.** Before, a compromised privileged account was immediately useful. After, at any random moment, the overwhelming majority of privileged accounts hold no privilege. An intruder who obtains one has obtained the *ability to ask*, not the ability to act. **Unilateral privileged action.** Every use now requires a second party. That is a genuine structural change: it converts a single-actor operation into one that needs another human to say yes, and it puts a human decision point in front of privileged work. **The always-on inventory.** Standing memberships are enumerable and stable, which is what makes privilege planning cheap for an intruder. Emptying those groups by default takes away a fixed map. **Departure and drift decay.** Rights granted for a project and never revoked are the ordinary way estates accumulate privilege. With activation as the default, unused privilege simply stops being exercised, and the entitlement becomes reviewable rather than invisible. ## What it does not remove, and this is the part candidates miss **Privilege already active.** Elevation that has been activated is active; code already running with an elevated token continues to hold it. Expiry withdraws a membership going forward - it does not reach into a running session, and it is not a containment mechanism. **A compromised requester.** If the intruder controls the workstation or session of someone entitled to request elevation, he requests it. The approval step is only as strong as the approver's ability to say no, and an approver handling dozens of requests a day under service-level pressure approves nearly all of them. An approval workflow that everyone approves is a queue, not a control. **Tempo.** Price the window against the adversary rather than against your change-management calendar. A ransomware affiliate on a revenue split is working in hours to days, not months. A four-hour activation window is not a constraint on him; it is a constraint on the slow, careful operator he is not. **Scope.** This is the most common design error. If the role you activate is administrator over everything, you have bounded *when* the privilege exists and left *where* untouched. Time-binding a role that is far too broad produces a control that feels rigorous and changes very little. Elevation should be time-bound **and** scoped to the smallest set of systems the task requires. **Break-glass.** Every implementation keeps an emergency path, because a system that can refuse an emergency will be worked around. That path is a standing right by construction, so it needs a named owner, sealed retrieval, and mandatory rotation after each use - otherwise the whole programme has one permanent exception at its centre. ## How to hold the two halves together The defensible position is: just-in-time elevation is a **reduction in the number and lifetime of standing targets**, and a **structural requirement for a second party**. It is not eviction, not containment, and not a substitute for scoping the role or for the rule about which hosts a privileged credential may be used on. It is also the most expensive of the three standing-rights removals in daily friction, which is why sequencing matters: unique per-host secrets and tier separation are usually cheaper wins, and elevation gating should be aimed first at the small set of rights that are rarely needed and catastrophic when abused. ## The claim to be careful with Saying "just-in-time elevation would have stopped this intrusion" is almost always wrong for an intrusion already inside a host. Say instead what is true: it would have made the privileged account less useful at the moment it was taken, and it would have forced the next step through a request that a person could have refused.
- Does an expiring elevation window cut off an intruder who activated it an hour ago?Not on its own. Expiry removes the membership going forward; anything already running with an elevated token, and any change he made while elevated - an account created, a right granted, a service installed - survives the window closing. Treat expiry as reducing exposure over time, never as a way of taking access back.
- How would you stop approvals becoming a rubber stamp?Restrict gating to the rights that are rarely needed, so approvers see few requests and each one is unusual. Require the approver to be someone with context on the work rather than a duty rota, and make the request state which system and task it is for. A gate applied to everything trains everyone to approve everything.
- Would you time-bind local administrator on laptops for support engineers?Usually not first. That right is exercised constantly, so gating it buys little and costs a lot of handle time. Scope it instead - a workstation-only support account - and spend the elevation gate on rights that reach servers or identity infrastructure, where use is rare and consequences are large.
saying these in an interview costs you the question
- Claims expiry cuts off an active intruder
- Assumes an approval step is always a real decision
- Time-binds a role that is administrator over everything
- Ignores the break-glass account entirely
- Judges the window length against process, not adversary tempo