The Setup
When you’re a sales rep selling Zero Trust products, you hit a credibility problem fast.
You can talk about it. You can explain it. You can walk through the security benefits, the ROI, the operational simplification. But if you haven’t actually built it yourself, customers know. They ask questions you can’t answer. They point out edge cases you’ve never considered. And they wonder why they should trust your advice if you’ve never implemented it in anger.
So I did what any reasonable person would do: I turned my personal blog into a test environment for a full Cloudflare Zero Trust implementation.
Not because my blog needs Fortune 500 security. It doesn’t. But because the same architecture that protects a blog can protect a Fortune 500 company. The products don’t scale down — only the complexity does.
This is the story of how I built a seven-product Zero Trust stack on saltwaterbrc.com in one afternoon, what I learned that nobody tells you, and why that stack is now a permanent part of how I sell.
Why Zero Trust on a Blog?
Let me be clear about something: my blog doesn’t contain classified data. It’s not holding customer records. It’s not processing payments. It’s not storing medical records. Zero Trust architecture is overkill by traditional standards.
But that’s not the point.
Gateway protects your devices, not your website. Access protects your apps.
This is the insight I needed to actually understand Zero Trust. It’s not about how dangerous the thing you’re protecting is. It’s about building a security model that works exactly the same way whether you’re protecting a blog or a banking system.
And once you understand that, the architecture becomes obvious: you protect identity, you protect endpoints, you inspect data in transit, and you isolate risky access. Seven products. One pattern.
For a sales rep, that means I can now tell customers not just what Zero Trust does, but how it actually feels to deploy it. And I can tell them what surprised me — because I was surprised, multiple times.
Part 1: Access (ZTNA)
The first piece was Access — Cloudflare’s Zero Trust Network Access product. The pitch is simple: you don’t need a VPN anymore. Your users authenticate once through their identity provider, and they get access to protected applications. No VPN client. No concentrators. No split-tunnel nightmares.
I set this up to protect /admin on my blog.
I connected Google Workspace as my identity provider. I created a policy that said: if you’re a user in my Google Workspace domain and you try to access /admin, you authenticate with Google, and then you get through. If you’re not, you don’t.
That’s it. No special hardware. No VPN appliance. Just a rule that says “this path requires identity.”
The takeaway for enterprise customers: Access policies are the foundation. They’re reusable, they’re identity-aware, and they work on any device without requiring you to install anything. For the CISO who’s tired of managing VPN licenses, that’s freedom.
Part 2: Gateway (Secure Web Gateway)
Access protects applications. Gateway protects devices.
I configured Gateway on my domain with DNS filtering and HTTP policies. DNS filtering blocks malware, adult content, and other categories of bad stuff. HTTP policies block specific file downloads (I set one to block .exe files, just as a proof of concept).
Here’s the thing nobody tells you: Gateway doesn’t protect your blog. It protects the devices accessing your blog. If I enroll a laptop in Gateway, and someone tries to download a malware-infected file from anywhere on the internet, Gateway stops it. But if they try to access my website directly without enrollment, Gateway doesn’t see it.
That distinction is critical.
Gateway protects your devices, not your website. Access protects your apps.
For enterprise customers, this means Gateway is device security, not network perimeter security. It’s the last line of defense for users on any network — office, home, coffee shop, airport.
Part 3: Tunnel (Cloudflare Tunnel)
Next came Tunnel. This one hit different because it inverted my mental model.
With traditional architecture, you open a port on your firewall, point DNS at it, and inbound traffic flows in. Tunnel does the opposite: it establishes an outbound-only connection from your origin server to Cloudflare’s edge, and all traffic routes back through that tunnel.
I set up a subdomain (dev.saltwaterbrc.com) that points to a local development server. No open ports. No firewall rules. Just a cloudflared process running on my laptop that says “if traffic comes in for dev.saltwaterbrc.com, route it to localhost:3000.”
The implications for customers: you can expose internal applications without opening your network to the internet. You can replace VPN concentrators with tunnel connections. You can give remote teams access to internal tools without ever putting those tools on a routable IP address.
Zero inbound attack surface.
Here’s how to run it — two terminal tabs:
# Tab 1: Start the local dev server
cd ~/Documents/Claude/saltwaterbrc-astro && npm run dev -- --host 0.0.0.0
# Tab 2: Start the tunnel
cloudflared tunnel run saltwaterbrc-devThen visit https://dev.saltwaterbrc.com — you’ll see the local site served through Cloudflare’s edge. No open ports. No public IP. The tunnel is outbound-only.
Part 4: WARP (Cloudflare One Client)
Access handles authentication. Gateway handles device security. WARP is the agent that makes it all work together.
WARP is Cloudflare’s endpoint client — it was rebranded in February 2026 to be part of the larger Cloudflare One platform. When you enroll a device in WARP, you’re telling it to route all traffic through Cloudflare’s network, apply Gateway policies, and enforce Access rules.
I enrolled my laptop. Now when I browse the internet, Gateway is filtering DNS queries, blocking malware, enforcing HTTP policies. When I try to access /admin on my blog, Access intercepts the request and forces Google authentication.
The architecture scales from one device to 10,000 with no change. You’re not managing different products for different user counts. You’re managing the same product with the same policies applied consistently.
For enterprise customers, that’s the real value: you get the same security architecture for 1 remote employee and 1,000 distributed teams.
Part 5: Browser Isolation (Remote Browser Isolation)
Now here’s where Zero Trust gets interesting for high-risk access scenarios.
Browser Isolation is for contractors, partners, or BYOD users who need access to sensitive applications but you don’t control their device. Instead of giving them a VPN connection, you give them a link. They click it, and their browser session runs in an isolated container on Cloudflare’s servers. Everything they see is pixel-streamed to their screen.
They can’t copy-paste data out. They can’t download files (unless you allow it). They can’t install plugins. They can’t see the actual application code.
I set this up as an identity-gated access path, so only authenticated users can get to the isolated browser. The mental model shift: you’re not trusting their device. You’re trusting their identity. The device doesn’t matter.
Clientless doesn’t mean unauthenticated. It means no agent required.
That’s the key insight. Browser Isolation requires zero client software, but it still requires strong identity verification. This is how you let someone’s dodgy laptop access your crown jewels without giving it direct network access.
Try it yourself: Open an isolated browser session. You’ll authenticate through Google Workspace first, then the page loads inside Cloudflare’s edge — not your device. Look for the red border and blue badge confirming isolation.
Part 6: CASB (Cloud Access Security Broker)
CASB connects to your SaaS applications via API and continuously scans for security risks. Think about a large enterprise running Google Workspace with 10,000 employees. Over time, people share Google Docs with “anyone with the link.” They add external collaborators to internal Drive folders. Service accounts get created and forgotten. Admin permissions creep. Nobody’s auditing any of it — until there’s a breach.
CASB audits all of it automatically. It connects to Google Workspace (or Microsoft 365, Salesforce, GitHub, Slack, Box, Dropbox) and flags: files shared publicly that shouldn’t be, users without MFA, overprivileged service accounts, external users with access to internal resources, and shadow IT apps connected via OAuth.
On saltwaterbrc.com, I connected CASB to my Google Workspace domain. This is a fresh account, so there’s nothing to find — but the integration is live and scanning. The setup was the most involved of all seven products: create a GCP service account, override org policies to allow key creation, download the JSON key, upload it to Cloudflare, enable Google Workspace APIs, configure domain-wide delegation, and confirm the admin email. That complexity is worth understanding because customers will hit the same steps.
The value for enterprise customers is ongoing. CASB doesn’t scan once — it watches continuously. An employee shares a sensitive doc publicly on Tuesday, CASB flags it Wednesday morning.
Part 7: DLP (Data Loss Prevention)
DLP clicked for me when I thought about healthcare.
A hospital has thousands of employees accessing patient records, billing systems, and internal dashboards through their browsers. Those systems display sensitive data — social security numbers, credit card numbers from billing, medical record IDs. An employee copies a patient’s credit card number from the billing system and pastes it into a Google Doc, a ChatGPT prompt, or their personal Dropbox. Maybe it’s innocent. Maybe it’s not. Either way, that data just left the corporate environment. That’s a HIPAA violation and a PCI-DSS violation.
DLP sits inside Gateway and inspects every outbound HTTP request in real time. When the content matches a detection pattern — credit card numbers, SSNs, API keys — DLP catches it before it leaves. The employee hits submit. Gateway sees the request. DLP scans the body, recognizes the pattern, and blocks it. The data never leaves.
The detection profiles we enabled — Financial Information, Credentials & Secrets, SSN/Tax Numbers — are pre-built pattern matchers. Cloudflare already knows what a Visa number looks like (starts with 4, specific digit length, Luhn check). Same for SSN format, API key patterns, and SWIFT/IBAN codes. We toggled them on. No regex. Then we created a Gateway HTTP policy: if outbound traffic matches a DLP profile, block it.
That’s the last mile. Gateway blocks malware. Access controls who can touch applications. DLP makes sure nothing valuable leaves the building.
The Pattern Nobody Tells You
After deploying all seven, I hit the same gotcha three times:
Creating a policy feels like it should be active. Like flipping a switch and it’s live. But it’s not. It’s a template sitting on a shelf until you attach it.
I created an Access policy for /admin. For five minutes, I thought it wasn’t working because I could still access /admin without authenticating. Then I realized: I had to actually attach the policy to the /admin route.
I created a Device Enrollment policy to require WARP. Forgot to attach it. Devices couldn’t enroll because the policy didn’t exist in the enrollment flow.
I created an RBI policy for contractors. Never attached it to an application.
Creating a reusable policy feels like it should be active. It’s not. It’s a template sitting on a shelf until you attach it.
This is an enterprise design pattern. Policies are reusable because they’re templates. They do nothing until you apply them. If you haven’t built security products before, this trips you up fast. If you have, you nod and move on.
But as a sales rep, this is now something I can warn customers about in the design phase. Not as a gotcha, but as a “here’s how the architecture works” moment.
The Full Stack
After one afternoon, saltwaterbrc.com went from a blog to a full Cloudflare One implementation. The products in the stack:
- Pages (hosting)
- DNS (domain management)
- WAF (Web Application Firewall)
- Workers (edge compute, coming soon)
- R2 (storage)
- Email Routing
- Access (identity-aware access control)
- Gateway (device-level security)
- Tunnel (outbound-only connectivity)
- WARP (endpoint client)
- Browser Isolation (containerized access)
- CASB (SaaS auditing)
- DLP (data loss prevention)
- Logs (security event storage)
- Network Analytics
- Firewall Rules
Sixteen products. On a personal blog. That’s not overcomplicated architecture. That’s the modern security baseline mapped out in real time.
What’s Next
Phase 2 is OpenCode — a Cloudflare product that lets you run isolated code in customer environments. I’m building something on top of it.
I’m also writing the “Ask This Blog” feature so you can ask Zero Trust questions directly to my blog content — a meta example of identity-gated LLM access.
And I’m updating our enterprise training docs with real deployment patterns from this build. No theory. No architecture diagrams that don’t match reality. Just “here’s what I actually built and here’s where I got stuck.”
This is exactly what I needed when I was sitting with the SEs nine years ago. Now it’s what I’m building for the teams I’m training.
The blog isn’t just secure now. It’s a playbook.