Deep-Dive · Companion to the Zero Trust Field Guide
One decision, made well, every time: is this access needed — and if so, how far should it be restricted? This is the deep version of the Zero Trust guide's central question, from the request to the revoke.
Every access request runs two gates. The first asks whether the access should exist at all — a question of necessity. The second asks whether this requester, on this device, in this context, has cleared the bar the resource's sensitivity demands — a question of authorization. Between them you size the grant to the minimum that does the job. After them, the work isn't done: access that never expires or gets reviewed is the most common source of risk.
Default-deny throughout: access is what you deliberately grant, not what you forgot to block.
The necessity gate is where most over-provisioning is stopped — or waved through. A legitimate need is tied to a specific role or task and can be stated in a sentence. Anything vaguer is a no until it's sharpened.
Once a need is established, grant the narrowest access that satisfies it. Minimize independently on five axes — a grant that's tight on four axes and wide on one is still wide.
How high the authorization bar should sit is a function of what's behind it. Rate the resource by the impact if its confidentiality, integrity, or availability were lost — then let that drive the controls.
| Tier | Examples | Impact if compromised |
|---|---|---|
| Crown jewels | customer PII, secrets/keys, domain admin, production data stores | Severe — regulatory, financial, existential. |
| Sensitive | source code, financial systems, internal PII | Significant — material harm, contained. |
| Internal | general business apps, intranet | Limited — operational friction. |
| Public / low | published content, open reference data | Minimal — but integrity still matters. |
If a resource isn't classified, you can't size its bar — so classification (the Data pillar) is usually the prerequisite work, not the network plumbing. Unclassified defaults to "treat as sensitive until rated," not "treat as open."
Sensitivity maps to the assurance required before access is allowed. When a request falls short, step up (raise the assurance) rather than defaulting to a flat deny — and only hard-deny when step-up can't close the gap.
| Tier | Identity | Device | Approval / elevation | Duration | Logging |
|---|---|---|---|---|---|
| Crown jewels | phishing-resistant MFA | managed + compliant | explicit approval + JIT | minutes–hours | full, alerted |
| Sensitive | MFA | posture-checked | role-based, JIT for elevation | session–days | full |
| Internal | SSO + MFA | known device | role-based | role lifetime | standard |
| Public / low | authenticated | any | self-service | standing OK | basic |
A contractor on an unmanaged laptop hasn't failed forever — route them through managed VDI, add approval, or provision a scoped replica. Step-up keeps people productive without lowering the bar, which is what prevents the workarounds (shadow IT) that a flat deny breeds.
A grant you can't describe later is a grant you can't review, audit, or safely revoke. Record enough that a stranger could re-evaluate it in a year.
The two fields people skip are expiry and review owner. A grant without them becomes standing privilege the moment the task ends.
The decision doesn't end at "grant." Access has a life, and the riskiest part is the end nobody tends to.
Periodically list grants that haven't been used in the review window. Unused access is pure risk with no offsetting benefit — revoke first, ask questions after.
How the decision gets implemented. Pick the model that matches how your access actually varies.
| Model | Decides by | Best when | Watch out for |
|---|---|---|---|
| RBAC | role → permission sets | stable, well-defined job functions | role explosion; creep as people accumulate roles |
| ABAC | attributes of user, resource, context | fine-grained, dynamic, context-dependent access | policy sprawl; needs clean attribute data |
| PBAC | central policies (often ABAC + a policy engine) | consistent governance at scale | only as good as the attributes and policies feeding it |
Need: one-week reporting task — legitimate, bounded. Size: read-only, two tables, seven days, one identity. Sensitivity: customer PII = crown jewels. Bar: phishing-resistant MFA + managed device + approval. Contractor is on an unmanaged laptop → step up to managed VDI + manager approval. Grant: read-only, two tables, 7 days, auto-expiring, fully logged. Residual: in-scope exfiltration still possible → add egress/volume monitoring.
Need: debug a live incident — real, urgent. Size: the affected service only, time-boxed to the incident. Sensitivity: prod data store = crown jewels. Bar + step-up: JIT elevation through PAM, session recorded, auto-expiry on incident close. Grant: scoped, JIT, recorded. Lifecycle: access self-revokes; no standing prod admin remains.
Need: a nightly job calls one API. Size: that one API method, that one dataset, no interactive login. Sensitivity: sensitive. Bar: short-lived credential, network-scoped. Lifecycle: owner assigned, quarterly review, alert if it authenticates from anywhere unexpected. The non-human identity gets the same two gates a person would.
Gate 1 — needed? tied to a task, stated in a sentence, default-deny. Gate 2 — authorized? conditions clear the bar the sensitivity demands; if not, step up rather than slam shut.
Principal · Resource · Actions · Duration · Conditions — narrowest point on each. The widest axis is your real exposure.
Classify first (you can't size a bar for an unrated resource). Crown jewels → strong identity + managed device + approval + JIT + short-lived + alerted.
Capture principal, scope, actions, justification, approver, and — always — expiry and review owner. No expiry = standing privilege.
Request → approve → provision → use → review → revoke. Expire by default; re-request, never auto-renew. Revoke on role change, offboarding, risk signal. Sweep unused grants.
The deep version of the Zero Trust Field Guide's "Is it needed? Should it be restricted?" decision. Concepts are standard access-control practice — principle of least privilege, need-to-know/need-to-use, RBAC/ABAC/PBAC, just-in-time / just-enough-access, separation of duties, privileged access management, break-glass, and access recertification. Map them to the access-control requirements of your own control framework before formal use; classification tiers, the assurance matrix, and worked examples are illustrative, not a control baseline. Least privilege reduces blast radius — it does not make a system "secure." Companion to the Zero Trust, Critical Thinking, Troubleshooting, and Root Cause Analysis guides.