Zero Trust Network Access: A Realistic Rollout

"Zero trust" has been marketed into near-meaninglessness. Underneath the vendor material is a genuinely useful principle: stop granting access based on network location. Being on the corporate LAN should confer no more privilege than sitting in a coffee shop.

This is how that translates into a rollout that does not collapse in month two.

What actually changes#

The traditional model authenticates you at the perimeter and trusts you inside it. Zero trust authenticates every request against three things:

1. Identity — a verified user or workload, with strong authentication
2. Device posture — a known, healthy, compliant endpoint
3. Context — what is being accessed, from where, at what time, and how unusual that is

Access decisions are made per-request and are short-lived. Nothing is granted permanently because a session started successfully three hours ago.

The important architectural point: the policy decision point is separate from the enforcement point. One place expresses policy; many places enforce it. Get this wrong and you end up with per-application access rules that drift apart within a quarter.

Sequence the rollout by leverage#

Most failed programmes start with the hardest thing. Go in this order.

1. Fix identity first#

Zero trust rests entirely on identity, so weak identity means the whole thing is theatre.

• Phishing-resistant MFA. FIDO2 security keys or passkeys. Not SMS, not TOTP, not push approval — all three fall to attacks that are now routine. Push fatigue attacks in particular have compromised organisations with 100% MFA coverage.
• Single identity provider. Every application federates. Applications that cannot are catalogued as exceptions with an owner and a date.
• Eliminate standing privilege. Administrative rights are requested, time-boxed, approved, and logged. Just-in-time elevation, not permanent membership of a privileged group.

If you do only one thing from this article, make it phishing-resistant MFA for administrators. It closes the single most exploited path into enterprise environments, and it does so for a few dozen pounds per admin.

2. Inventory and posture#

You cannot make device-aware decisions without knowing what devices exist.

# Devices that have not checked in — the shadow inventory you actually have
Get-MgDeviceManagementManagedDevice -All |
    Where-Object { $_.LastSyncDateTime -lt (Get-Date).AddDays(-14) } |
    Select-Object DeviceName, UserPrincipalName, OperatingSystem,
                  ComplianceState, LastSyncDateTime |
    Sort-Object LastSyncDateTime |
    Export-Csv stale-devices.csv -NoTypeInformation

Define compliance concretely: disk encrypted, EDR agent running and reporting, OS within N versions of current, secure boot on, no jailbreak. Then report on it for a month before enforcing. The first report always finds substantially more non-compliance than expected, and enforcing on day one means locking out a third of the workforce.

3. Replace the VPN with per-application access#

This is the visible change, and it should come third rather than first.

The VPN's problem is that it grants network access. Once connected, a compromised laptop can reach everything the firewall allows — which, in most organisations, is far too much. Per-application access grants a tunnel to one application, authenticated per session.

Migrate in waves:

Wave 5 is the one organisations skip, and skipping it means paying for both systems while retaining every risk of the old one. Set the decommission date at the start of the programme and treat it as the deliverable.

Keep one break-glass path — an out-of-band route for a small number of named accounts, protected by hardware keys, monitored aggressively, and tested quarterly. When the identity provider has an outage, and it will, you need a way in that does not depend on it.

4. Segment east-west traffic#

Perimeter replacement does nothing about lateral movement inside the data centre. Segmentation does.

Start by observing rather than blocking. Deploy agents or use flow logs in monitoring mode for 30 days, build the actual dependency map, then write policy from it. The map you build from observation never matches the one in the documentation.

# Illustrative policy: the web tier reaches the app tier on one port only.
apiVersion: security/v1
kind: SegmentationPolicy
metadata:
  name: web-to-app
spec:
  source:
    labels: { tier: web, env: production }
  destination:
    labels: { tier: app, env: production }
  allow:
    - protocol: tcp
      ports: [8443]
  default: deny

Order matters: production first (highest value), then development (usually the messiest and least documented), then the flat management network everyone forgot about.

Policy design that survives#

Write policy against attributes, never against individuals or IP addresses:

ALLOW  role:finance-analyst
       app:erp-reporting
       WHEN device.compliant = true
        AND auth.method = "phishing_resistant"
        AND risk.session <= medium
       FOR 8h

REQUIRE step_up
       WHEN risk.session = high
         OR location.country NOT IN allowed_countries

DENY   ALL
       WHEN device.compliant = false
       EXCEPT app:compliance-remediation-portal

That last clause is easy to overlook and important: a non-compliant device must be able to reach the tool that fixes its compliance. Without the exception you have built a system where the remedy is behind the lock.

Measure the right things#

Vanity metrics — "95% of apps behind ZTNA" — say nothing about risk. Track instead:

• Standing privileged accounts. Should trend towards zero.
• Applications reachable from an unmanaged device. Should trend towards zero.
• Mean time to revoke access after a termination event. Hours, not days.
• Percentage of authentications using phishing-resistant factors. The headline number.
• Blast radius: from a compromised standard endpoint, how many systems are reachable? Measure it with an actual assessment, quarterly.

That last one is the honest metric. It is also the one that shows whether segmentation is real.

What it costs you#

Be straightforward with stakeholders about the trade-offs, because they are real:

Latency. Per-request policy evaluation adds 10–50 ms. Users notice on chatty internal applications. Cache decisions where the risk allows.

Operational dependency. The identity provider becomes the most critical system you run. Architect for its failure and rehearse the response.

Legacy applications. Anything using NTLM, hardcoded service accounts, or IP allow-listing needs a proxy in front of it or an exception with an expiry date. Budget for this — it is typically 20–30% of the total effort, and it is where timelines slip.

Change fatigue. People who could reach everything now cannot. Every access request that used to be implicit becomes a ticket. Staff the service desk for the transition or the programme will acquire a reputation it never recovers from.

A realistic 12-month plan#

• Months 1–2 — Phishing-resistant MFA for all administrators. Device inventory. Compliance policy in report-only mode.
• Months 3–4 — MFA for all staff. ZTNA pilot with IT plus two applications. Begin east-west traffic observation.
• Months 5–7 — ZTNA waves 2 and 3. Enforce device compliance. Just-in-time admin elevation.
• Months 8–10 — Thick clients and infrastructure access. Segmentation policy in production, monitor mode.
• Months 11–12 — Segmentation enforcement. VPN decommission. Blast-radius assessment against the baseline.

Twelve months is realistic for a mid-size organisation with dedicated people. Anyone promising ninety days is selling a product rather than describing an outcome.