Cloudflare Access, Tailscale + Twingate Compared

Knowing the Zero Trust principles is one thing; the question on a real engagement is "which tool implements them, and what evidence does it produce?" Three products dominate the ZTNA conversation for small and mid-sized companies — Cloudflare Access, Tailscale, and Twingate — and they take noticeably different architectural routes to the same destination. You don't need to be able to deploy all three, but you do need to read a company's choice, understand the trade-offs, and know where the access policy and logs live. This lesson gives you that map.

Two architectures, one goal

The three tools split along a fault line worth understanding first, because it shapes everything else.

Identity-aware proxy (Cloudflare Access). A reverse proxy sits in front of each application. Users reach the app through Cloudflare's edge; Cloudflare authenticates them against your IdP, checks policy, and forwards the request. The application is published through the proxy and never exposed directly. This is clientless for web apps — the user just hits a URL — which makes it excellent for browser-based SaaS-style access and for contractors who can't install agents.

Mesh / overlay network (Tailscale, and Twingate's connector model). Instead of proxying at an edge, these build an encrypted overlay between devices and resources. Tailscale uses WireGuard to create a flat, private mesh where each enrolled device gets a stable identity and can reach permitted peers directly; access is governed by policy (ACLs) rather than network location. Twingate sits in between: lightweight connectors deploy next to private resources and broker access per-application from a client, with no inbound ports opened and no broad subnet routing by default.

The distinction matters for assessment: a proxy model gives you clean per-application, often clientless access and centralized request logs; a mesh model gives you device-to-resource connectivity that's superb for engineering/infrastructure access (SSH, databases, internal tools) but requires care to keep "least privilege per app" rather than drifting back toward flat reach.

The comparison

Dimension	Cloudflare Access	Tailscale	Twingate
Architecture	Identity-aware reverse proxy (edge)	WireGuard mesh / overlay network	Connector-brokered per-app access
Client required	No for web apps (clientless); agent for non-HTTP	Yes (WireGuard client on each device)	Yes (lightweight client)
Best fit	Web apps, SaaS-style access, contractors/BYOD	Engineering access: SSH, DBs, internal tools, infra	Replacing VPN for mixed app access, fast rollout
Identity / MFA	Via your IdP (Okta, Entra, Google) + MFA	Via your IdP for device auth + MFA	Via your IdP + MFA
Device posture	Device posture checks + WARP client signals	Device posture via integrations	Device posture / trust controls
Access model	Per-application policy at the proxy	ACL policy file over the mesh	Per-resource policy via connectors
Where logs live	Cloudflare access/audit logs (per request)	Tailscale audit + network flow logs	Twingate activity / access logs
Inbound ports opened	None (app behind proxy)	None (outbound WireGuard)	None (outbound connector)

A few takeaways that survive past today's feature lists:

All three eliminate inbound exposure. None requires opening a public port on the protected resource — connectivity is established outbound, so there's no internet-facing front door to attack. That alone is a meaningful improvement over a VPN concentrator with a public address.
All three delegate identity to your IdP. The MFA and user lifecycle still come from Okta / Entra ID / Google. ZTNA is the enforcement and segmentation layer, not the identity source — which means the access-review and joiner/mover/leaver story still routes through the IdP work from Phase 2.
The differentiator is the access unit and the client model. Proxy (Cloudflare) → clientless, per-app, web-first. Mesh (Tailscale) → client-based, device-to-resource, infra-first. Connector (Twingate) → client-based, per-resource, VPN-replacement-first.

Choosing is about fit, not 'most secure'

There is no single "most secure" choice here — all three implement the same Zero Trust principles competently. The right pick is about the access pattern: a company whose crown jewels are web applications and who onboards lots of contractors leans Cloudflare Access; an engineering-heavy team that needs SSH and database access to infrastructure leans Tailscale; a company doing a fast, clean VPN replacement across mixed apps leans Twingate. When you assess a stack, don't grade the brand — grade whether access is genuinely per-application, conditioned on identity and device posture, and logged. A well-configured Tailscale beats a sloppily-configured Cloudflare Access every time.

What a GRC Engineer verifies, whichever tool

The product changes; the evidence questions do not. For any ZTNA deployment, you should be able to answer:

Is access per-application/per-resource, not flat? Pull the policy (Cloudflare Access policies, Tailscale ACL file, Twingate resource policies) and confirm groups map to specific apps — not "all employees → everything."
Is it conditioned on identity and device posture? Confirm MFA is enforced via the IdP and that device-posture/compliance checks gate sensitive resources (the conditional-access pattern from Phase 3).
Are decisions logged? Confirm per-request access logs exist, flow to a retained/monitored location, and can show "who reached what, on what device, allowed or denied."
Is the old path closed? A ZTNA rollout that leaves the legacy flat VPN running in parallel hasn't reduced risk — confirm the bypass is decommissioned or tightly governed.

That fourth point is the one teams most often miss and auditors most reward catching: a half-migrated ZTNA, with the broad VPN still available "just in case," preserves exactly the lateral-movement path Zero Trust was meant to remove.

Quick check

An engineering-heavy startup needs its developers to reach internal databases, SSH to servers, and internal admin tools — all currently behind a flat VPN. They want device-aware, per-resource access without exposing any inbound ports. Which option fits best, and what is the key thing to verify regardless?

A clientless web proxy only — engineers should access databases through a browser

A WireGuard-based mesh like Tailscale (strong fit for SSH/DB/infra access via clients, no inbound ports) — and regardless of tool, verify the ACL/policy grants per-resource least privilege, enforces IdP MFA + device posture, logs access, and that the old flat VPN is decommissioned

Keep the flat VPN but rename it Zero Trust in the policy document

Whichever tool has the best marketing — they are all identical in practice

What to carry forward

Cloudflare Access (identity-aware proxy, clientless, web-first), Tailscale (WireGuard mesh, client-based, infra-first), and Twingate (connector-brokered, VPN-replacement-first) all implement the same Zero Trust principles, all eliminate inbound exposure, and all delegate identity to your IdP. The choice is about the access pattern, not "which is most secure." Whatever the tool, you verify the same four things: per-application least privilege, identity-plus-device-posture conditioning, per-request logging, and that the legacy flat path is actually closed.

Next you'll apply this directly: configure a ZTNA policy set for a 50-person company with distinct groups and applications, deciding who reaches what, on which devices, and with what conditions.