intellimetrics Learning
Zero Trust Implementation Module 2 · Identity

Kill Standing Privilege

Last reviewed

Intermediate

What you'll learn

~15 min
  • Convert permanent privileged assignments to just-in-time eligible roles
  • Design the activation gate, the review cadence, and the tiered-admin boundary
  • Operationalize assume-breach: privilege that expires limits what a stolen session can do

Assume breach, applied to your own admins

Tenet 5 said assume nothing is clean — including, uncomfortably, your administrators’ sessions. The question that reframes privilege: when an admin’s token is stolen at 2 p.m. (Lesson 1.1’s test), what does the attacker hold? In the standing-privilege world: Global Admin, forever, everywhere. In the world this lesson builds: whatever was activated right then — usually nothing.

The mechanism is just-in-time elevation: privileged roles are held as eligible, not active. An eligible admin is a normal user until they activate — a gated ceremony (phishing-resistant MFA, business justification, optionally approval for the crown-jewel roles) that grants the role for a bounded window, hours not months, logged end to end.

Standing world:  identity IS the privilege     - steal it, own everything
JIT world:       identity MAY REQUEST privilege - steal it, and the attacker
                 must perform the activation ceremony: strong-auth gate,
                 justification on the record, alert fired, clock ticking

Prompt first

Design the privileged-access model for this estate:
1. ROLE INVENTORY: every privileged role (directory, cloud, SaaS admin
   consoles), current assignment count, and which are standing vs eligible
2. CONVERSION PLAN: standing -> eligible for every role; activation gate per
   tier (phishing-resistant MFA always; approval + max 4h window for
   tier-0 roles; 8h for tier-1); the two break-glass accounts stay standing,
   excluded-and-alarmed per our CA baseline
3. REVIEWS: quarterly access reviews per role - the reviewer is the role's
   OWNER, not the admin's manager; inactivity rule: eligible-but-never-
   activated in 2 quarters => flagged for removal
4. TIERED ADMIN: which roles require a privileged access workstation or
   cloud PC; the rule that tier-0 credentials never touch a daily-driver
   browser profile
Output as a table plus the decisions register entries for anything unusual.

Three design points that make the model hold:

The activation gate is a PDP moment. Activation is itself an access decision — evaluated with the strongest signals: phishing-resistant strength (Lesson 2.2), compliant device (Module 3), and for tier-0, a second human. This is where the pillars you’re building compound: the gate is only as strong as the weakest signal it accepts.

Reviews prune by evidence, not memory. Quarterly reviews fail when they’re a rubber-stamp email to managers. The version that works reviews activation logs: a role never activated in six months is a role that person doesn’t need — removal is the default and retention needs the justification. (The same inactivity logic that Lesson 6.1 applies to groups and projects.)

The tier boundary is physical. Tier-0 (identity infrastructure itself) is administered only from hardened, separately-managed workstations — because a domain admin activating from the same browser profile that opens lunch-menu links makes the JIT ceremony theater. The boundary between “daily driver” and “admin surface” is the one air gap left that’s worth its cost.

💬The resistance, and the answer

Admins experience JIT as friction — “I activate five times a week!” Two honest answers. First: five activations a week means five moments an attacker must also survive, each one alarmed; that IS the control. Second: streamline what’s streamlinable — activation approval only on tier-0, sensible window lengths, no re-auth mid-window. The goal is standing privilege at zero, not activation ceremonies at maximum. If someone activates daily for a routine task, that task probably deserves a scoped automation identity (next lesson) instead of a human admin role.

KNOWLEDGE CHECK

A quarterly review shows a database engineer has held eligible 'Subscription Owner' for a year and activated it exactly twice — both during a migration that ended in March. The engineer objects to removal: 'I might need it, and re-granting takes a day.' What does the model say?

Key takeaway

Privilege that stands is privilege pre-stolen. Make every role eligible, gate activation with your strongest signals, bound it in hours, review by activation evidence with removal as the default, and put tier-0 behind hardware you don’t browse on. The 2 p.m. token thief now holds a normal user and an alarm bell. One identity class left — the one that outnumbers everyone: the machines.

Search lessons