Zero trust isn't a product. It's a proof obligation.
Zero trust works when each access decision is treated like a claim you'd have to prove. Get the evidence, then enforce. Done that way, the audit mostly takes care of itself.
part 2 of 4 · Identity security, from the ground upthe ideaEvery access decision is a claim, and it needs evidence you can show.
after reading, you can- Explain why identity governance has to come before conditional access policies mean anything.
- Roll out an access policy the way you'd ship a deploy. Monitor mode first, then enforce. Keep it versioned and reversible.
- Look at a control and decide whether it produces its own audit evidence, or whether audit prep stays a separate project.
Every vendor deck says zero trustdefinitionA security model where nothing is trusted just because of where it sits. Every request gets checked against current evidence about the user, the device and the context.. Very few deployments can answer the question that matters. For this access, right now, what's your evidence? That question is the architecture, and no product answers it for you.
The name comes from the code hash. We think about security the way engineers think about integrity: a claim nobody can verify counts for nothing. Applied to access, three practical rules come out of that.
Identity is the perimeter, so govern it like one
Most zero-trust programs stall because nobody trusts the identity data. There are orphaned accountsdefinitionAccounts with nobody active behind them, such as a former employee's login that never got switched off., there's entitlement sprawldefinitionThe slow buildup of access rights people no longer need, until nobody can explain why someone has what they have., and some roles nobody can explain. Conditional accessdefinitionPolicies that grant or block access based on conditions such as who the user is, the state of their device or where they are connecting from. policies mean little until provisioning and certification are automated and auditable. In our SailPoint engagements that groundwork alone cut provisioning time by 85%, and the security payoff came after.
A policy you can't explain is a control you don't have.
Every decision needs a signal, every signal needs a source
Adaptive access is only as good as what you feed it, such as device posturedefinitionThe security state of the requesting device, such as whether it's managed, patched and encrypted., behavioral baselines and network context. Wire those signals in one at a time. Run monitor modedefinitionRunning a new policy so it records what it would have blocked without actually blocking anything, before switching it to enforce. first and enforce second, and treat each policy like a deploy, versioned and tested with a way to roll back.
# every access policy ships like software policy: finance-prod-access version: v14 // reversible mode: monitor → enforce signals: [device, behavior, network] ✓ tested · ✓ versioned · ✓ evidence-emitting
Evidence should be a byproduct of the controls
If audit prep is an event on the calendar, the architecture is wrong. The controls that enforce access should produce their own proof as they run, in session records, certification trails and policy logs. Then the audit is just a report someone generates.
What to take from this
- 01
Start with identity governance. Get provisioning automated and auditable before anyone writes a single policy.
- 02
Add signals one at a time. Run each in monitor mode before you enforce it, and keep a way back.
- 03
Make every control emit its own evidence, and audits become report generation.
Three questions, about a minute
Pick an answer and we'll tell you if it's right, and why it is or isn't. The score stays in this browser.
-
Q1Your team wants conditional access turned on, but nobody can explain half the roles in the directory. What comes first?
show the answer
C. Automated, auditable provisioning and certification Most programs stall because nobody trusts the identity data. Automate provisioning and certification first, and keep them auditable. Policies written on top of bad data don't mean much.
-
Q2You're adding a device-posture signal to an access policy that's already live. How should it go live?
show the answer
D. Run it in monitor mode, then enforce, keeping it versioned and reversible Wire in one signal at a time. Run it in monitor mode, look at what it would have blocked, then enforce. Version the policy and keep a way back, the same as any deploy.
-
Q3Audit season means weeks of pulling screenshots and logs by hand. What does that say about the architecture?
show the answer
B. The controls don't emit their own proof continuously Evidence should come out of the controls as they run: session records, certification trails, policy logs. If audit prep is a project every year, that's a design problem, and the audit should be a report you print.