How a 120-Engineer SaaS Company Replaced Its Corporate VPN with Zero-Trust Access
A mid-size B2B SaaS company eliminated its legacy VPN bottleneck by rolling out Cloudflare Access and WARP, cutting engineer connection failures by 94% and slashing lateral-movement risk.
Security · intermediate · 12 min read · 2263 words · By Sandip Das · Published
Composite scenario: built from common industry patterns; the figures are illustrative.
What this covers
- The Situation
- The Problem
- Constraints
- Options Considered
- The Solution
- Implementation
- Results
- What Went Wrong Along the Way
- Lessons Learned
- Apply It Yourself
Key numbers
| Metric | Before | After |
|---|---|---|
| Daily VPN connection failure rate | 18% | 1.1% |
| Median engineer connection latency (India) | 280 ms | 62 ms |
| Per-session audit log coverage | 0% | 100% |
| On-call VPN-cycle incidents per week | 11 | 0 |
| Contractor access provisioning time | 45 min | 4 min |
Key components
- Cloudflare Access — Enforces per-application identity and device-posture policies at the Cloudflare edge, replacing network-layer VPN access.
- WARP Client — WireGuard-based client installed on engineer devices that routes traffic through Cloudflare and enforces device posture checks before granting access.
- Cloudflare Tunnel (cloudflared) — Outbound-only daemon running inside the private network that exposes internal services to Cloudflare Access without opening inbound firewall rules.
- Okta IdP — Authoritative identity provider integrated via SAML/OIDC; group membership in Okta drives access policy decisions in Cloudflare Access.
- Cloudflare Logpush to S3 and Splunk — Ships structured per-session audit events from Cloudflare to S3 and then to Splunk SIEM within 60 seconds, satisfying the ISO 27001 audit trail requirement.
- Device Posture Rules — Client-side checks (disk encryption, EDR sensor running, OS version) enforced by the WARP agent before any tunnel traffic is permitted.
The Situation
This is a composite scenario assembled from patterns seen across multiple mid-size engineering organisations; all figures are illustrative and internally consistent, not drawn from any single company.
The organisation in question is a 120-engineer B2B SaaS company selling workflow-automation software to enterprise customers. The engineering team is split across three time zones — US East, UK, and India — with roughly 30 contractors joining at any given time for short-term feature work. Infrastructure runs on AWS (us-east-1 primary, eu-west-1 secondary), with workloads on EKS 1.28, RDS Postgres 15, and a handful of self-hosted tools: Grafana, ArgoCD, and an internal SSH bastion. The security and platform team has six engineers. The company is SOC 2 Type II certified and mid-way through an ISO 27001 audit cycle.
The rest of this case study — the trade-offs, the scaling numbers and the build prompt — is available to LearnXops members. Create an account or see membership.
Topics: security, zero-trust, networking, cloudflare, identity, devops
Related case studies
- AWS Keys Leaked to GitHub: The First 60 Minutes and the Clean-Up
- How a B2B SaaS Team Contained Prompt Injection Across an AI Agent With Live Tool Access
- How a B2B SaaS Team Cut Supply-Chain Risk by Enforcing SBOMs, Sigstore Signing, and OPA Admission Policies
- How a B2B SaaS Team Eliminated Plaintext Secrets and Cut Credential Exposure Risk by 94%