The VPN problem nobody wants to say out loud
VPN was designed in 1996 for a world where your data lived in a data centre, your users sat in an office, and the perimeter was a building with a locked door.
None of those things are true for most SMBs in 2026.
Your data lives in Microsoft 365, in a dozen SaaS apps, and maybe in a private cloud like ours. Your users work from home, coffee shops, client sites, and hotel lobbies. The perimeter isn’t a building — it’s an identity claim, a device state check, and a policy decision.
VPN doesn’t model any of this. It grants broad network access once — at login — and trusts the session forever. A stolen credential plus a VPN is a front door with the key under the mat.
What Zero Trust Network Access actually is
ZTNA is the operational model that replaces VPN. The key difference: instead of putting a user “on the network” and hoping for the best, ZTNA evaluates every access request against a policy: who is this user, what device are they on, is the device healthy, what application are they trying to reach, and what’s the risk level of this session?
Cloudflare’s implementation (which is what we deploy for TruWorkspace Zero Trust) adds one more dimension: it runs this evaluation at Cloudflare’s global edge — 300+ points of presence — so latency is nearly zero regardless of where your user or your application happens to be.
The four moves, in order
Here’s the exact sequence we use on every rollout:
Move 1: Get identity right first. Before touching Cloudflare, we harden the Entra ID tenant. This means enabling phishing-resistant MFA across all accounts, configuring conditional access to require device compliance, and running an access review to eliminate stale accounts and over-privileged roles. ZTNA is only as strong as the identity layer behind it.
Move 2: Establish device trust. We enroll all corporate endpoints in Intune, deploy the Cloudflare WARP client via Intune policy, and set device compliance requirements that Cloudflare will enforce. An unmanaged device — even with valid credentials — cannot reach internal resources.
Move 3: Build the per-app access matrix. For each internal application, we define who can reach it, from what device posture, and under what session conditions. A finance application might require phishing-resistant MFA and a fully-patched corporate device. A public wiki might allow any enrolled device with SSO. This matrix becomes the ZTNA policy.
Move 4: Decommission VPN. With a pilot cohort validated, we extend ZTNA to all users and run both VPN and ZTNA in parallel for a two-week overlap. Then VPN is switched off. Clients are usually surprised at how little noise this creates.
What changes for your users
Not much, which is the point. WARP runs silently in the background. Users sign in once with their existing Microsoft account — if they’re on a compliant device, they get to their apps. If they’re on an unmanaged device, they get a clear message explaining why access was denied and what to do.
Password reset tickets typically drop by 60–70% because passwordless authentication eliminates the “forgot my VPN password” class of support request.
The compliance benefit
Every ZTNA session generates an audit log: who accessed what, from where, on what device, at what time, and what the policy decision was. This log is insurer-friendly and auditor-friendly — and it lives in Cloudflare’s analytics, not in a dusty firewall that your MSP has to manually export.
For TruCompliance clients, these logs feed directly into our ISMS evidence library as proof of access control for SOC II, ISO 27001, and cyber insurance renewals.
Priya Sharma is the Virtual CISO at TruPoint Technology.