What Zero Trust Architecture Actually Requires From IAM First

Zero trust has a sequencing problem that budgets rarely acknowledge. The architecture is sold, reasonably, as a network and policy story: microsegmentation, continuous verification, policy engines that check every request instead of trusting the network perimeter. What gets skipped is that every one of those mechanisms depends on identity signals being trustworthy in the first place. A policy engine that verifies “is this the right user” before granting access is only as good as the authentication behind that check and the deprovisioning process that keeps the access list current. Build the policy layer before the identity foundation holds, and the architecture verifies requests against information it cannot actually trust.

Okta's State of Zero Trust Security report, a survey of more than 800 security decision-makers, found identity rated as “extremely important” to zero trust strategy nearly doubled year over year, from 27% to 51%, and that 91% of respondents said identity matters to their zero trust approach overall. The industry has recognized where the foundation sits. Recognizing it and building the budget and timeline around it are different things, and the gap between them is where most zero trust programs lose momentum.

What “Zero Trust” Actually Assumes

NIST Special Publication 800-207, the reference architecture most vendor implementations trace back to, defines zero trust around a simple principle: no implicit trust based on network location, and every access request evaluated on its own merits. The practical consequence is that the architecture is a trust-evaluation engine, and a trust-evaluation engine is only as sound as the signals it evaluates. Three identity signals carry almost all of that weight.

Who is actually asking. Phishing-resistant authentication, meaning credentials that cannot be relayed or replayed by an attacker who tricks a user into approving a prompt, is the baseline the architecture assumes. A zero trust policy engine that trusts a session authenticated by SMS or a push notification is trusting a signal attackers have well-documented techniques for defeating.

Whether that access should still exist. A policy engine checking “does this user have access to this resource” is only useful if the access list it checks against reflects who should currently have access, not who had access six months ago when they changed roles or left. Deprovisioning latency is invisible to most zero trust tooling because the tooling evaluates the access grant that exists, not whether that grant should.

Whether a privileged session is actually contained. Microsegmentation limits lateral movement for ordinary access. It does very little against a compromised credential that already carries standing administrative privilege, because that credential was never meant to be contained by a network boundary in the first place. Zero trust architectures assume privileged access is brokered and time-bound; where it is not, the architecture has a hole shaped exactly like the account it cannot see.

Where CISA's Model Fits

CISA's Zero Trust Maturity Model, now in its second version, scores an organization's zero trust adoption across five pillars: identity, devices, networks, applications and workloads, and data. It is free, well-regarded, and useful for exactly what it measures, which is architectural adoption. What it is not built to do is interrogate identity maturity in the depth an IAM-specific assessment does. CISA asks whether phishing-resistant MFA is in use; it does not ask what percentage of access paths it actually covers, or how long a leaver keeps working access after departure. That is not a flaw in CISA's model, which has a different and legitimate scope. It is a reason not to treat a zero trust maturity score as evidence that the identity foundation underneath it has been verified at the control level. The two measurements answer different questions, and a program that has only ever run the architectural one is still missing the audit this article is describing.

Why Programs Stall Here

The stall pattern is consistent across organizations that have otherwise invested seriously in zero trust. Network segmentation projects and policy engine deployments are visible, roadmappable, and vendor-supported with clear implementation milestones. Fixing deprovisioning latency or phasing out standing privileged access is organizational work: it touches HR processes, requires app owners to cooperate, and rarely has a vendor demo attached to it. Okta's research found 80% of surveyed organizations increased zero trust budgets year over year, and that cost and technology gaps were the most commonly cited obstacles, which fits a pattern where spending flows toward the visible architecture layer while the identity foundation underneath it is treated as already adequate rather than verified.

The failure mode this produces is specific: a zero trust architecture that looks complete on a slide, with a policy engine evaluating every request, sitting on top of an access model that nobody has actually audited. The architecture is real. The trust it is supposed to verify is not.

What the Evidence Looks Like, Not the Intent

Each of the three prerequisites has a version that looks done on a roadmap slide and a version that is actually done, and the gap between them is where most audits find trouble.

A phishing-resistant authentication rollout that covers the primary SSO login but still allows a password-and-SMS fallback for a “legacy” application category is not phishing-resistant; it has exactly the attack path the project was meant to close, just moved to a system nobody tracks as closely. A deprovisioning process that is “automated” on paper but still requires someone to manually trigger the workflow for contractors, because contractors were never fully integrated into the identity system that drives the automation, is not automated where it matters most for a zero trust model, since contractor access is disproportionately represented in lateral-movement incidents. Privileged access that is “brokered” for production infrastructure but still allows direct, unbrokered admin login to the identity provider itself leaves the one system a zero trust architecture trusts completely outside its own model.

This is the same evidence-over-intent problem that shows up everywhere else in IAM measurement, and it is worth naming directly here because zero trust programs are particularly prone to it: the architecture's own vocabulary, continuous verification, policy-based access, makes it easy to describe a partial rollout in language that sounds complete.

Sequencing the Work

This is not an argument against zero trust, or against investing in policy engines and segmentation. It is an argument about order. Before a policy engine's decisions are worth trusting, three things need to already be true: workforce authentication needs to be phishing-resistant on every path that matters, not just the primary login; deprovisioning needs to happen on a timescale measured in hours, not weeks, so the access list the policy engine checks is actually current; and privileged access needs to be brokered rather than standing, so a compromised credential cannot simply walk past the segmentation that was built to contain ordinary traffic.

None of this requires abandoning an in-flight zero trust program. It requires treating the identity layer as a dependency to be verified, not an assumption to build on top of. A maturity assessment that scores workforce authentication, privileged access, and identity governance explicitly, rather than folding them into a single zero trust readiness score, is what makes that verification concrete instead of aspirational. The AXIS assessment covers these capabilities across all 37 questions, and the control-level detail behind authentication maturity specifically is documented against the NIST digital identity guidelines in the framework library.

For how foundational gaps in identity cascade into everything built on top of them more generally, see The IAM Maturity Model, Explained, and for the broader comparison of zero trust models to an IAM program measurement, the methodology page covers where the two frameworks overlap and where they measure different things entirely.

Common Questions

Is IAM maturity the same as zero trust maturity? No. Zero trust models such as CISA's Zero Trust Maturity Model measure adoption of an architecture across several pillars, of which identity is one. An IAM maturity assessment measures the identity program itself in depth, including governance and operations a zero trust model typically does not reach. Mature identity is a prerequisite for zero trust, not a synonym for it.

Can we run a zero trust pilot before fixing deprovisioning? A contained pilot on a small system is reasonable groundwork. What does not work is rolling the architecture out broadly while deprovisioning latency across the wider estate remains in weeks rather than hours; the pilot will succeed and the production rollout will inherit the gap at scale.

Does buying a zero trust platform fix the sequencing problem? No platform evaluates identity signals it was never given accurate data about. The platform can enforce a policy correctly and still enforce it against an access list that is wrong, because the access list was never the platform's problem to fix.