Your board approved a zero-trust program two years ago. The architecture diagram is on a slide. The auditor is asking a narrower and much harder question: show me that a request from a non-compliant laptop to a production database is denied, and show me the record of the last time that happened. That is the test every control eventually faces, and it is where most programs thin out.
The gap is usually not ambition. It is that teams build toward a maturity model and then discover that assessors, customers, and underwriters want artifacts: configuration exports, sample reviews, and evidence tied to a date. This is a working map of the controls that carry weight in a real walkthrough, sorted by how often they fail.
Auditors grade evidence, not architecture
NIST SP 800-207 describes zero trust as a set of principles enforced through a policy engine, a policy administrator, and policy enforcement points placed close to the resource. The document is deliberately implementation-agnostic, which is why it is a poor audit checklist. CISA's Zero Trust Maturity Model is more useful for gap analysis: five pillars, four maturity stages, and a clear message that identity is the foundation the rest depends on. Neither document tells you what an assessor will ask to see.
What works is a three-part pattern for every control you claim. First, state the rule in one sentence. Second, name the system that enforces it and where the configuration lives. Third, name the artifact that proves enforcement held over a period, not just at a point in time. A control that cannot complete that third step is a project, not a control, and experienced assessors spot it within two questions.
Identity: the control that carries most of the weight
Start with administrators. Phishing-resistant authenticators, meaning FIDO2 or WebAuthn security keys and passkeys rather than push notifications or one-time codes, are the factor class that holds up against real-time proxy phishing. NIST SP 800-63B requires phishing-resistant authenticators at authenticator assurance level 3, and the direction of travel for privileged access is the same everywhere: hardware-backed, bound to origin, no fallback to SMS. If your identity provider still allows a help-desk reset from a phone call for admin accounts, that is the finding, no matter how good the rest of the program looks.
The second identity control is conditional access that combines user, device, network, and risk into a single decision evaluated per session. The practical test: can you show the policy definition, and then show a sign-in log where the policy blocked a session and the reason code is legible? If your policies exist but nobody has read a blocked-session log in a quarter, the policy has never been exercised.
Third, non-human identities. Service accounts, API keys, and CI tokens outnumber employees at most companies, and they are where MFA stops mattering. Replace static keys with short-lived credentials from workload identity federation where the platform supports it, inventory the rest, and set an owner and expiry on every one. The access review artifact assessors want is a list of privileged accounts by owner with a reviewer signature, plus an orphaned-account report showing how many were removed.
Device posture: registered is not the same as trusted
Device management tools will happily report that 97 percent of laptops are compliant. That number is worthless unless compliance is a condition of access. The control is a signal that gates the session: disk encryption on, secure boot enabled, endpoint agent healthy, OS build within your patch window, and a device certificate issued by your own authority rather than asserted by the client.
Assessors tend to pick a device at random from the inventory and ask for three things: its compliance history over the last 90 days, whether it could reach sensitive applications while non-compliant, and what happens to its access when the agent is uninstalled. Have a live answer for the unmanaged-device path too, because contractors and executives will always have one, and an undocumented exception path is worse than a documented restricted one.
Segmentation: prove east-west traffic control, not VLANs
A network diagram shows intent. Effective policy shows what is actually reachable. The controls that hold up are identity-aware proxies in front of internal applications, default-deny between workload tiers, and egress rules that force outbound traffic through an inspected path. In cloud accounts, security groups and network policies are easy to export and easy to leave stale, so the artifact that matters is a current reachability analysis with owners attached to each allowed flow.
Run the negative test and save the output. Pick a low-trust resource, such as a developer laptop or a build runner, and attempt a connection to a high-value store such as the production data warehouse. A denied connection with a timestamped log, plus the policy that caused the denial, is the single most convincing segmentation artifact you can produce. Then count your exceptions and check that each has an expiry date, because exception lists are where segmentation quietly dies.
Logging: the evidence problem
Most organizations log authentication well and authorization poorly. Sign-ins, MFA events, token issuance, and directory changes are usually captured. The question that stops a walkthrough is: who read this customer record on this date? Answering it needs application-level access logs for sensitive data stores, not just infrastructure logs.
Build the logging control around four properties. Coverage: identity, control plane, data plane, and security tooling all send to a central store. Retention: twelve months is what regulated customers commonly ask for, with longer for security events. Integrity: logs land in a separate account or subscription with object lock or write-once storage, so an attacker with production credentials cannot erase the trail. Detection: a documented set of rules mapped to the techniques you care about, with a record of what fired. Time sync across sources is unglamorous and decides whether a timeline reconstruction is admissible as evidence.
Key management and secrets
Key policies are authorization systems, and auditors increasingly treat them that way. The questions are who can decrypt, who can change the key policy, and whether those two groups are the same people. Separate key administrators from data administrators, require dual control for destructive operations such as scheduled key deletion, and export the key policy alongside the list of principals who can modify it.
Then cover the lifecycle. Rotation should be automated and observable, including certificate rotation for internal services; short-lived certificates from an internal authority beat annual renewals on every dimension. Code signing keys deserve their own custody story because they gate your supply chain. Secrets in CI pipelines should come from a broker at run time, not from a repository variable, and the artifact is a scan showing zero long-lived credentials in build configuration. If a vendor claims customer-managed keys or keys held in your country, the evidence is where the key material is generated and whether the provider can decrypt without your grant.
The audit checklist
| Control area | Evidence that satisfies an assessor | Most common failure |
|---|---|---|
| Privileged identity | Phishing-resistant MFA enrollment by role; policy definitions; blocked-session log sample | SMS or push fallback still enabled for admins |
| Access reviews | Quarterly review with reviewer sign-off; orphaned-account report | Reviews signed without changes; no removals recorded |
| Device posture | Compliance history for a sampled device; enforcement rule; unmanaged-device path | Posture reported but not enforced |
| Segmentation | Reachability export; timestamped denied-connection test; exception register with expiries | Diagram instead of effective policy |
| Logging | Source coverage matrix; retention config; immutability proof; rule list | No application-level access logs for sensitive data |
| Keys and secrets | Key policy export; rotation logs; secret scan of CI configuration | Same team administers keys and data |
Use the table as a coverage check, not a scorecard. An honest assessment of your program will show two or three rows where the artifact exists but is stale, and stale evidence is the failure mode that costs the most time during an audit because it forces a scramble after the assessor has already formed a view.
What to do next
- Pick one privileged role and trace a real session end to end: authenticator, device check, policy decision, resource access, and the log line that records it. Fix whatever breaks.
- Export your conditional access or IAM policy set and look for any rule that permits fallback to a weaker factor for administrators. Remove it this quarter.
- Run one denied-connection test on your most sensitive data store and archive the output with a timestamp. Repeat it every quarter.
- Add application-level authorization logging to the one system that holds regulated data. Sign-in logs alone will not answer the record-access question.
- Inventory non-human identities, assign an owner and expiry to each, and put the count on the same dashboard as employee MFA coverage.