A Practitioner’s Guide to Universal Zero Trust Network Access (UZTNA)

Foreword

I have spent most of my career watching Zero Trust get explained, sold, and then misapplied. The model itself is sound — it has been sound since John Kindervag put it on paper and NIST formalized it in SP 800-207. What broke is the gap between the theory and the deployments. Most organizations adopted the vocabulary, bought the products, and stopped one or two steps short of the outcome. Then 2020 happened, the workforce went remote overnight, and the market compressed Zero Trust into a single use case: replacing the corporate VPN. ZTNA shipped, the remote-access problem got better, and the harder majority of the estate — on-prem applications, service-to-service traffic, IoT and OT — got left behind.

That gap is what this guide is about. Universal Zero Trust Network Access is not a new acronym to memorize or a new product category to procure. It is the discipline of applying Zero Trust the way it was originally specified: to every user, every device, every workload, every access path, with no exceptions. The word ‘universal’ is not marketing. It is the acceptance criterion that separates a Zero Trust program from a Zero Trust press release.

I wrote this as an operator’s manual because operators are who I work with. The architects, the network engineers, the identity leads, and the CISOs who have to stand in front of an audit committee and explain why a contractor’s laptop could reach a production database. None of those people need another market guide. They need a sequenced playbook that tells them what to build, in what order, with what exit gates, and what to refuse to ship. That is what I have tried to put in your hands.

You will notice the guide is opinionated. It is supposed to be. Wherever I have seen the same wrong turn taken five times in a row, I called it out — in the chapter text, in the ‘Don’t Do This’ boxes, and in the vendor red flags. Treat those as scar tissue from other people’s programs so that they do not have to become scar tissue in yours.

One last note. UZTNA, like Zero Trust before it, is a program rather than a project. The organizations that treat it as a one-time deployment will be the ones I get called about after the breach. The ones that treat it as an operating discipline will not need to call. My hope is that this guide tilts you toward the second group.

— Dr. Chase Cunningham
DrZeroTrust | July 2026

Chapter 2 – Readiness Assessment (Do This First)

Skip this chapter and you will end up redesigning mid-rollout. The most expensive UZTNA programs are the ones that picked a vendor, drafted a timeline, and discovered within six months that the application inventory was wrong, identity was still federated across three directories, or the OT network had never been mapped. All of those failures are diagnosable in advance. The readiness assessment below is the cheapest insurance policy in the entire program.

UZTNA Readiness Scorecard

Score yourself honestly on the five dimensions in the table. Use a simple zero-to-two scale: zero for ‘not started,’ one for ‘in progress,’ two for ‘mature’ and sum the result. Honesty matters more than precision. A program that scores itself dishonestly will rebuild the deltas the hard way, in production, on a vendor’s clock.

Stakeholders that Need to Be in the Room Before Day One

Six roles must be present before Day One

• The CISO is the sponsor and the tiebreaker.
• The network and security architects own the design.
• The identity team owns IdP, PAM, and directory work.
• The application owners for the top twenty business-critical applications own migration and testing for those apps.
• The compliance and audit lead owns control mapping and evidence collection.
• The help desk lead owns change management and the userexperience side of every cutover.

If any of those seats are empty when the program kicks off, the corresponding workstream will stall by Phase 2.

Inventory Checklist

Before Day 1 you need a complete inventory across four domains. No shortcuts. On the identity side, catalog every directory, IdP, federation trust, service account, and contractor account. On the device side, capture every corporate-managed endpoint, BYOD device ever enrolled, contractor device with a known footprint, IoT sensor, and OT/ICS asset. On the application side document name, owner, hosting location, authentication method, protocol, and business criticality for every application including the ones nobody admits to running. On the network side, map every on-prem segment, cloud VPC, branch site, OT enclave, and VPN concentrator. Whatever you cannot inventory, you cannot protect.

Common Gaps that Kill Implementation

Four gaps kill more UZTNA programs than every vendor limitation combined.

1. Incomplete application inventory: You cannot protect what you have never catalogued.
   Impact: The missing applications are always the sensitive ones.
2. Legacy applications without migration plans: Legacy applications with no identity-aware access path and no migration plan.
   Impact: These become the permanent exceptions that erode the whole ‘universal’ premise.
3. Unmanaged endpoints without owners: Unmanaged endpoints that no one owns operationally.
   Impact: If no team is accountable for a device class, no policy will be enforced on it.
4. Unclear policy ownership: Unclear policy ownership between security, network, and application teams.
   Impact: Surfaces as ‘whose change ticket is this?’ and stalls every cutover.

Name owners for each before you start. The earlier these are resolved, the faster and smoother your UZTNA rollout will be.

Chapter 3 – Reference Architecture

Every UZTNA deployment breaks down into the same logical components regardless of the vendor. The labels differ but the shape is identical — one vendor’s ‘connector’ is another’s ‘gateway’ is another’s ‘proxy’. Map your design against the reference diagram below before procurement so that you know which components a given vendor actually delivers and which you will have to bring yourself.

Figure 1. The UZTNA logical architecture, vendor-neutral. The PEPs shown here (reverse proxies and private-app connectors) are not appropriate for every workload class. OT, ICS, and many IoT segments require network-level enforcement instead; see the device-trust table in Chapter 5 for the per-class control mapping.

Core Components (Every Deployment Needs All of These)

• Identity Provider (IdP): Source of truth for user, group, and machine identity.
• Device Trust Broker: Collects posture signals and produces a per-device trust score.
• Policy Decision Point: Evaluates identity + posture + context against policy.
• Policy Enforcement Points: Cloud and on-prem proxies that allow or deny access.
• Application Connectors: Reverse proxies / connectors that publish apps without exposing the network.
• Continuous Risk Engine: Re-scores sessions in real time and triggers step-up or revocation.
• Telemetry Pipeline: Forwards access events to SIEM/SOAR for detection and audit.

Architecture Rules You Cannot Skip

Five architectural rules do not bend.

1. The first is sequencing on segmentation. Start with network-based macro-segmentation before UZTNA: separate production from corporate, OT from IT, regulated workloads from general-purpose. Then, progressively tighten toward application-level micro-segmentation as identity and posture data mature. Segment by application identity, not by IP range. A concrete example: isolate the finance ERP into its own segment where only the finance-admin identities can reach it, rather than allowing other departments and non-finance roles access.
2. The second rule is that east-west traffic is a prerequisite, not a Phase 4 problem. If service-to-service calls inside the data center are unpoliced, then a single compromised workload owns the blast radius regardless of your front door’s strength.
3. The third rule: legacy applications need an explicit handling plan that includes a protocol-aware proxy, header injection, or a controlled exception with an expiration date. The choice is yours; the absence of a choice is not.
4. The fourth rule is the IoT/OT plan. For devices that can hold a certificate, use certificate-based device identity plus network-level segmentation. For legacy and constrained devices that cannot, use compensating identifiers – MAC address plus switch port plus protocol fingerprint – combined with passive discovery and brokered access through a jump host or protocol-aware proxy. Plan for the OT estate reality that most agents will not exist.
5. The fifth rule is the vendor-evaluation lens. Score every vendor on the depth of its IdP, SIEM, and EDR integrations, and treat API-first as a hard requirement. A vendor that cannot be driven by API will become an operational bottleneck no amount of pricing concession can fix.

Deployment Model: Pick One Per Workload Class

UZTNA supports multiple deployment models. Choose the model that best fits each workload class.

Never connect users to the network. Connect them only to the specific application they are entitled to, after identity, posture, and policy have all been satisfied.

Chapter 4 – Phased Rollout Playbook

Run the phases in order. Each phase has an exit gate, and you do not start the next phase until the previous gate is met. The gates exist because every UZTNA program that has skipped one has paid for it later, usually in the form of a rebuild during Phase 3 or 4 when something foundational was assumed rather than verified.

Phase 0: Assess and Align (Weeks 1-4)

About alignment more than deployment. Complete the readiness scorecard from Chapter 2. Draft the ‘no exceptions’ policy statement and require your CISO to sign it personally. Verbal endorsement does not survive the first vendor exception request. Pick a pilot user group of 50 to 200 users spanning at least two business units (or functions) because a single-business-unit pilot will miss the cross-functional policy edges that matter most.

What Success Looks Like

• Readiness scorecard complete
• No-exceptions policy signed by CISO
• Pilot user group selected (50-200 users, 2+ BUs)
• Sponsor named; stakeholders committed

Phase 1: Identity & Device Foundation (Months 1-3)

Builds the identity and device foundation that the rest of the program rests on. Federate every application you can to a single primary IdP and eliminate local accounts on each system as it federates. Enforce phishing-resistant MFA. This is the place to be prescriptive: disable SMS-based OTP which remains the most commonly deployed second factor and the easiest to phish or SIM-swap. Require, in order of preference, FIDO2 credentials and passkeys, then platform provided biometric authenticators (ie: Windows Hello, Touch ID, Face ID), then push-based authenticator apps with number matching and biometric unlock. Voice OTP and email OTP are not acceptable second factors. In parallel, stand up the device trust broker and wire it to your MDM, UEM, and EDR feeds, and issue device certificates from your PKI for every managed endpoint.

What Success Looks Like

• All applications federated to a single primary IdP
• Phishing-resistant MFA enforced (FIDO2/passkeys)
• Device trust broker wired to MDM, UEM, EDR
• Device certificates issued from PKI

Phase 2: Cloud App Migration (Months 2-5)

Migrates cloud and SaaS applications behind the UZTNA proxy. Publish each application in shadow mode first, where the broker logs but does not enforce the policy decision. Promote an application to enforcement only after seven consecutive days of clean logs — no unexplained denies, no posture drift, no policy exceptions accumulating. Migrate the pilot user group off the VPN for those applications as each one cuts over, so that you build a track record of clean cutovers before scaling.

What Success Looks Like

• All cloud/SaaS apps published behind UZTNA proxies
• Each app tested in shadow mode first
• Seven consecutive clean-log days before enforcement
• Pilot users migrated off VPN as apps cut over

Phase 3: On-Prem Parity (Months 4-8)

Where most programs hit their hardest stretch: bringing on-prem applications under the same policy regime that already governs cloud and SaaS. Deploy on-prem application connectors in high-availability pairs near the workloads they front. Move the top 20 internal applications behind UZTNA first, starting with HR, finance, and engineering tooling. Those three categories are chosen deliberately. They cover the highest-value data — HR PII, financial systems of record, source code, and build infrastructure. They draw the most active audit attention. And they exercise the broadest set of access patterns — human, service account, and CI/CD workload — which surfaces policy gaps early when they are still cheap to fix. As each application cuts over, eliminate the matching VPN entitlement on the same day.

What Success Looks Like

• On-prem apps under same policy regime (single PDP, federated PEPs)
• On-prem connectors deployed in HA pairs
• Top 20 internal apps behind UZTNA (HR, finance, engineering)
• VPN entitlements eliminated same day as cutover

Phase 4: IoT/OT Coverage (Months 6-12)

Extends coverage to IoT and OT. Inventory every device by segment and protocol because you cannot apply a policy to a device class you have not seen. Apply network-level micro-segmentation as the primary control. For most OT devices, segmentation is the only control you will ever have. Issue device certificates where the hardware supports them; otherwise wrap with brokerfronted access through a jump host or protocol-aware proxy. Every exception that survives this phase must be documented with a named owner, a compensating control, and an expiration date. Unexpired exceptions are how OT environments accumulate the decade-old vulnerabilities that show up in breach disclosures.

What Success Looks Like

• Every device inventoried by segment and protocol
• Network-level micro-segmentation applied
• Certificates issued or broker-fronted access via jump host
• Every exception documented (owner, control, expiry)

Phase 5: Validate & Optimize (Ongoing)

The ongoing work. Run quarterly policy reviews and retire any rule that has been in shadow mode for more than a quarter or that has not matched a request in ninety days. Tune the risk engine to reduce false positives without
softening enforcement — false-positive fatigue is the most common path to enforcement-mode rollback. Advance one rung of the maturity model each quarter (see Chapter 7) and treat that advancement as a board-reportable metric, because what is not measured will not be improved.

What Success Looks Like

• Quarterly policy reviews conducted
• Unused rules (90+ days) retired
• Risk engine tuned to reduce false positives
• One maturity rung advanced per quarter

Migration Discipline: Kill the VPN

The discipline for killing the VPN is straightforward and unforgiving. Inventory every VPN entitlement and map each one to a specific application. Migrate applications in waves. On the same day an application cuts over to UZTNA, remove the matching VPN entitlement. Track ‘percent of access migrated off VPN’ as a programlevel KPI and report it to the board on a quarterly cadence. Operational migration metrics belong to the project, but the trend line and the VPN sunset date belong to the board.

Set that hard sunset date for the VPN concentrator and publish it internally because a published date concentrates minds in a way a private one does not.

Always-On Guardrails

• Run Every New Policy in shadow mode before Enforcing it.
• Maintain a documented rollback for every change
• Keel parallel VPN access available for one wave behind the active migration and decommission only after the new wave had run stably.
• Communicate every cutover to affected users on a seven-day, three-day, and one-day cadence; the user-experience complaints that kill programs are almost always preceded by inadequate notice.

Chapter 5 – Identity & Device Controls

Identity is the perimeter. Device posture is the second factor. Together they decide whether any access request gets evaluated at all, which is why this chapter comes before policy and application access — get identity and posture wrong and no amount of clever policy will save the program.

Identity – Required Configurations

On the identity side, five configurations are non-negotiable.

• Designate one primary IdP as the authoritative source of identity and federate everything else to it wherever supported (Okta, Entra ID, or Ping are the common choices). Where a target system does not integrate with your IdP, document the exception, wrap it with a proxy or PAM session that does, and put it on a remediation roadmap rather than accepting it as a permanent gap.
• Enforce phishing-resistant MFA for every human user, FIDO2 credentials or passkeys.
• Configure conditional access policies that bind to device posture, location, and session risk score; static role membership alone is not sufficient.
• Require step-up authentication for any access to sensitive or privileged resources, so that the elevation event is itself a fresh trust decision.
• And integrate PAM with the UZTNA proxy so that privileged sessions are just-in-time, scoped, and recorded end-to-end.

Non-Human Identity: The Most Overlooked Attack Surface

Non-human identity is the most consistently overlooked attack surface in modern estates.

• Inventory every service account, API key, and workload identity, and put them in the same identity store you use for humans rather than a parallel spreadsheet.
• Adopt a workload identity model for service-to-service authentication (SPIFFE/SPIRE or a cloud-native equivalent), so that workload identity is cryptographic rather than network-derived.
• Place API gateways inside the UZTNA enforcement plane for east-west API calls because an unprotected east-west API is the lateral-movement path attackers will use once the front door is difficult.
• Rotate secrets automatically; long-lived static credentials should be treated as an audit finding under SOC 2 CC6, PCI DSS 8.3, and NIST SP 800-53 IA-5, and remediated on a defined timeline rather than left in place indefinitely.

Device Trust Spectrum: Plan a Control for Each Tier

Different device classes need different controls; the table below maps each class to the primary control and the acceptable risk posture. The principle behind the table is that the access-grant decision should be a function of what the device actually is and what it can prove about itself, not a binary ‘managed vs. unmanaged’ classification that drops half the estate into the unmanaged bucket.

Posture Signals Worth Collecting

Seven posture signals are worth collecting on every endpoint that can produce them:

1. Operating system version and patch level.
2. The presence and health of EDR or anti-virus.
3. The validity and enrollment status of the device certificate.
4. Whether disk encryption is enabled.
5. Jailbreak or root detection on mobile devices.
6. In-session re-evaluation rather than login-only checks.
7. Conformance with corporate device-configuration policy, including restricted services, ports, and protocols.

Any signal you collect should be evaluated continuously, not only at session establishment. Posture that was clean at login can degrade in minutes, so a continuous-verification model exists specifically to catch that drift.

Chapter 6 – Application Access & Policy

The goal of UZTNA at the application layer is application-level access. Network-level access is the blast-radius problem: grant network access and the attacker who compromises one identity inherits reach to everything that network can see. Every policy you write should grant access to one application, not one subnet.

Connector and Proxy Deployment Rules

Four rules govern connector and proxy deployment.

1. Place connectors close to the workload they front, because latency between the connector and the application is the single largest determinant of user-perceived performance and therefore of adoption.
2. Deploy connectors in high-availability pairs across availability zones, with no single points of failure — a connector outage looks like an application outage to the user.
3. For SaaS applications, combine inline proxying with API-based controls wherever the vendor exposes them, because API controls cover the out-of-band paths that an inline proxy cannot see.
4. And for east-west and workload-to-workload traffic, terminate at an API gateway or service mesh that sits inside the UZTNA enforcement plane, so that internal API calls receive the same scrutiny as user-facing ones.

Legacy Application Decision Tree

Most application portfolios contain legacy systems that do not speak modern authentication. The decision tree below walks through the choices for handling them in priority order. Modern, auth-ready applications publish through a reverse proxy and you are done. Everything else needs a deliberate compensating pattern. Resist the temptation to skip a step and grant network-level access just for one legacy application because ‘just one’ is how permanent exceptions begin.

Policy Structure: A Template That Scales

Every UZTNA policy must specify: subject + action + resource + conditions.

Every UZTNA policy specifies four elements: subject, action, resource, and conditions.

• The subject is the user, group, service account, or workload identity with an applicable policy.
• The action is the verb being authorized — read, write, administer, connect, or an applicationspecific operation.
• The resource is the specific application, URL path, or API endpoint the action targets.
• And the conditions are the runtime context that must hold for the policy to grant: device posture, network location, time of day, risk score, step-up state.

A policy missing any of those four elements is implicitly relying on an assumption that will eventually be wrong.

Policy Authoring Rules

1. Start with deny-all and add explicit allows: The reverse – allow-all with explicit denies – has produced every lateral-movement breach in recent memory.
2. Prefer ABAC layered on top of RBAC: Use attribute-based access control layered on top of role-based access control. Use roles for the baseline and attributes for the context.
3. Name policies consistently: Use a pattern such as <env>-<app>-<role>-<action> so that the name carries its own audit trail.
4. Test in shadow mode for seven days: Test every new policy in shadow mode for seven days before enforcing it.
5. Treat every exception as time-limited and scoped: Every exception must have auto-expiry and required renewal. Permanent exceptions are how “universal” becomes “partial” over time.
6. Manage policy as code: Version-control it, and review changes through the same process you use for infrastructure and require the same approval rigor.

Sample Policy: Finance App, On-Prem, Privileged

Chapter 7 – Monitor, Measure, Mature

UZTNA produces more access telemetry than most security teams know what to do with. The day-two work of any UZTNA program is converting that telemetry into three things:

• Detections that the SOC can act on.
• Evidence that auditors can consume.
• Signals that drive measurable improvement in the access posture.

An organization that ships UZTNA without that pipeline has bought a very expensive log generator.

SIEM and SOAR Integration

Integration with SIEM and SOAR is what turns telemetry into operations. Forward every event above to the SIEM with a consistent schema because schema drift is the silent killer of correlation rules. Author correlation rules for the access patterns that actually indicate compromise:

• Impossible travel between authentication events.
• Mass denial bursts on a single account.
• Posture downgrades during an active session.

Codify SOAR playbooks for the three highest-leverage responses — session revocation, device quarantine, and IdP account hold. Why? Because those are the actions that contain a breach in the first hour. Then, measure mean-time-to-revoke-a-session as a board-reportable KPI
with a target of under sixty seconds. That metric is the single most honest measure of how real your UZTNA program is operationally.

Quick-Mapping: Compliance Evidence

UZTNA produces evidence that maps cleanly to four common control regimes.

• HIPAA access logs satisfy the Security Rule’s access-control and audit-trail requirements.
• CMMC 2.0 directly benefits from the Access Control (AC) domain coverage that UZTNA delivers.
• NIST SP 800-207 treats UZTNA as a direct implementation pattern of the Zero Trust Architecture which simplifies the conformance story for federal-facing programs.
• SOC 2 Type II auditors will accept UZTNA telemetry as direct evidence for the CC6 logical access controls.

In each case, the work is configuring the SIEM forwarding and the retention policy correctly the first time, so the evidence collects itself.

Required Telemetry Feeds

1. Authentication events with full context: Every successful and failed authentication with user, device, location, and risk score.
2. Access grant and deny events per application and per user: So that the SIEM can answer ‘who reached what, when, and on whose authority’ as a single query.
3. Policy change audit log: The only durable record of who softened which control.
4. Device posture change events: A posture downgrade mid-session is one of the highest-fidelity attack signals available.
5. Continuous-risk engine’s alert and step-up trigger stream: Tells you when the system caught something the static policy missed.

Program KPIs the Board Should See

Resist the urge to report uptime or alert volume — both are easy to game and neither tells the board whether the program is working.

Measure mean-time-to-revoke-a-session as a board-reportable KPI with a target of under sixty seconds. That metric is the single most honest measure of how real your UZTNA program is operationally.

First 90 Days

The UZTNA Plan-on-a-Page
Print it. Tape it to the wall. If you finish each column’s exit gate, you finish the program. If you skip one, you will have to rebuild it inside of a year.

If a column slips, do not move on. Slipping a gate is cheaper than rebuilding the next phase on a broken foundation.

Vendor Evaluation Grid

Use this grid to score UZTNA vendors apples-to-apples. Weight each category 1–3 based on your environment, then score each vendor 0–5 per row. Multiply weight × score and total the column.

Regulatory Mapping

Use this table to point auditors at the UZTNA capability that satisfies each control area.