BIPI
BIPI

ZTNA Beyond the Marketing Diagram: What Breaks in Real Deployments

Cybersecurity

Every ZTNA vendor draws the same architecture: identity, device posture, policy engine, enforcement point. The interesting part is what falls over once your contractor laptops, on-prem apps and break-glass admin paths hit the policy.

By Arjun Raghavan, Security & Systems Lead, BIPI · October 13, 2024 · 8 min read

#ztna#zero-trust#architecture

We have run six ZTNA deployments in the last two years across vendors that include Zscaler, Cloudflare Access, Tailscale, Twingate and a self-built Pomerium stack. The architectures all look identical on the slide. They diverge sharply once you start enforcing on real traffic.

The marketing diagram has four boxes: identity provider, device posture service, policy engine, enforcement point. The diagram is correct. It is also missing about fifteen footnotes that separate a working deployment from a help-desk firestorm.

Identity is harder than your IdP demo suggests

Your IdP knows about employees. It does not know about contractors logging in from their own machines, third-party integration partners that hit your APIs, service accounts that predate the ZTNA project and managed service providers who rotate staff weekly.

First deployment we ran, the contractor identity story took longer than the entire employee rollout. We ended up with three identity tracks: full SSO for employees, a federated B2B SAML setup for partners, and a short-lived credential issuance flow for contractors via a self-service portal with manager approval. Three flows, three policy paths, one audit trail.

Device posture is a snapshot, not a guarantee

Vendor demos show the policy engine checking that the device has disk encryption on, EDR running, OS patched within 30 days. They do not show what happens at minute 31 when the patch deadline rolls and 800 laptops fall out of policy simultaneously.

Real deployments need posture grace periods, posture dashboards before enforcement, and a remediation flow that does not require the user to call helpdesk. We typically configure a 7-day soft-fail window, a Slack notification on day 1, an in-product banner on day 3, and hard-fail on day 7. That pattern produced a 94 percent voluntary remediation rate at one client.

94%
voluntary patch compliance with soft-fail window
37
applications behind ZTNA at typical mid-market client
3
identity tracks needed for most enterprises

The policy engine and the legacy app

Your modern apps speak OIDC. Your ZTNA enforces at the OIDC layer, your audit trail is clean, life is good. Then someone reminds you of the on-prem app that your finance team uses, the one that does forms-based auth against AD.

Three patterns we use to bridge that gap.

  • Identity-aware proxy in front of the legacy app, terminating ZTNA and forwarding with a service account.
  • Browser isolation for the truly unfixable apps, where the user gets a remote browser session.
  • Network-layer ZTNA (Tailscale-style) for apps that need raw TCP and cannot be HTTP-fronted.

All three have tradeoffs. The proxy pattern is cleanest but requires you to handle session affinity. Browser isolation is fine for low-frequency use, miserable for daily drivers. Network-layer ZTNA is operationally simple but loses you the per-request visibility.

Break-glass and the policy backdoor

Every ZTNA deployment we have run has needed a break-glass path. The policy engine is down, the IdP is having an outage, the on-call needs to get to a production database to fix a customer-impacting bug. If your ZTNA does not let them in, your ZTNA is now causing the incident.

We use hardware token plus second-engineer approval, time-boxed to 4 hours, logged loudly to an immutable audit channel. Used about twice a quarter at a typical client. Worth its weight in gold the time the IdP went down for 90 minutes during a Black Friday peak.

What we wish vendors would tell you

If your CISO is being told by a sales team that this is a 90-day rollout, push back. The infrastructure can be stood up in 90 days. The policy reform, contractor onboarding, legacy app bridging and break-glass design takes the rest of the year. Plan for that and you will ship a working system. Plan for the demo and you will ship a help-desk problem.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.