Full reference doc — not a script to run top to bottom.
Legend: ▶ click / nav · 💬 spoken line · $ terminal · ⏸ pause · ➡ transition
Pre-demo setup checklist
Logged into Cloudflare One dashboard · tarheel23 tenant
Two terminals ready: one on laptop, one SSH'd into the EVE-NG server
Aliases on EVE-NG server: syscloud · stopcloud · startcloud
Browser tab queued to https://eve-ng.tarheel.us (Safari, since WARP routes there cleanly)
Both connectors up at the start — verify with syscloud
Build my demo
Check the sections you actually want to walk through today, then hit "Show only checked." Section 0 (the platform intro before you touch the dashboard) always runs — this controls sections 1–21 plus the reference sections below them.
▶ OPEN → cf-demo-app.dustinburke23nc.workers.dev/vpn-vs-zerotrust
→ Tab 1: "The full platform." Pause 2 sec, let the diagram register.
One platform, three things in scope.
Left: who needs protection — employees, contractors, AI agents, their devices, their locations
Right: what they're reaching — apps, infrastructure, networks
Middle: everything Cloudflare does
→ Point at the orange "Policy at the edge" card in the center.
Here's what happens in that single pass, right at the nearest PoP — no backhaul to a central point first:
WARP Check — device healthy
Identity Check — Okta, Google, Apple... or whatever you use as an IDP
Access Policy — what you're allowed to reach
Gateway Security — web filtering
DLP Scan — sensitive data leaving where it shouldn't
CASB Control — SaaS misconfigs, oversharing
Email Security — phishing caught before it lands
Browser Isolation — risky sites run in the cloud, not the laptop
Same control plane, same logs across all of it — and it's not limited to what's on screen right now. It's all running on the same network shown on the sides, not a separate box bolted on.
→ Point at the dashed "Shadow AI Control" pill at the bottom of the card.
I'm calling this one out because it's becoming increasingly popular in conversations, especially since there are more and more language models coming out. And with those models come high costs. It's important to know what's being used versus what's already approved.
It's essentially a combination of CASB, Gateway Security, and DLP.
→ Point at the three orange tiles along the bottom.
Three promises: end-to-end visibility on every flow · consistency across all on-ramps · global distribution at 330+ cities.
Most vendors do half of this and partner for the rest. We do it all on one network — that's SASE as architecture, not marketing.
🎬
Stay on the same page — Tab 1 already has the on-ramps
→ Tab 1: "Cloudflare platform & connectivity"
3 user cards on the left, 3 server cards on the right, Cloudflare in the middle. Click each card as you tell its story. "Animate all" cycles through all six if you'd rather narrate over the animation. Standalone URL still works: cf-demo-app.dustinburke23nc.workers.dev/connectivity
→ Still on Tab 1. Shift eye down to the 3-column diagram — six cards, three per side, Cloudflare in the middle.
Next question is always: how do users connect, how do servers hook in? Three on-ramps per side — walk each one, match to their environment.
Replaces MPLS + site-to-site VPN concentrators — this is the conversation that ends the MPLS bill
User-side punchline: 3 on-ramps, same policy hits all of them. Written once, not three times. Contractor offboards, device falls out of compliance, branch drops — response happens in one place.
⚡ SERVER SIDE — 3 patterns
→ Click card S1 (Single server or VM).
Single server — one app, one box (EC2, on-prem VM, container, anywhere).
Install cloudflared — 3 commands, dials out on port 443, persistent connection
Nothing inbound — no public IP, no firewall port, no NAT rule
Fastest path from "internal app" to "securely reachable app" — 5 minutes
→ Click card S2 (Whole VPC or subnet).
Whole VPC / subnet — mixed workloads, don't want to install an agent on every box.
WARP Connector on one server represents the whole CIDR range — everything behind it is reachable
No per-server agents
Best for legacy apps you can't touch, long-lived TCP (databases, RDP, SSH, SAP)
Mesh variant = full peer-to-peer, not just inbound
→ Click card S3 (Data center or cloud region).
Whole data center / cloud region — network-level integration.
Same IPsec/GRE pattern as branch office, but from your DC router or cloud transit gateway
CNI (Cloudflare Network Interconnect) for large/latency-sensitive — direct connection bypassing the public internet: AWS Direct Connect, Azure ExpressRoute, GCP Partner Interconnect, or a physical cross-connect at Equinix
Magic WAN orchestrates it all — branches, DCs, clouds — through Cloudflare's backbone. No MPLS, no SD-WAN appliances, no per-site mesh to maintain
Server-side punchline: no public IP, no open firewall rule, no port forward — anywhere. Every connection is outbound-only. The door doesn't exist on the internet. Apps stop being a target because they stop being addressable.
3 user on-ramps + 3 server patterns, all converging on the same Cloudflare network. Same policy engine evaluates all of it. Next: the Zero Trust architectural argument.
→ Click Tab 2: "What VPN costs you". Walk the red center box, then point at "Your Cloud" on the right.
People left, apps right, middle is everything they go through to get there.
Middle isn't one product — VPN box, firewall, cert store, MFA appliance. Outgrow it, replace all of it. Same vendor conversation every 3-5 years
Forgotten part: your own cloud takes the same detour — contractor in Singapore, VPN in Virginia, AWS region next door to the contractor, traffic still round-trips to Virginia. Same for M365, Salesforce
Half a second per click. Design problem, not vendor problem.
→ Click "What Cloudflare delivers". Let them notice left/right columns are identical, then point at the orange center.
Same picture, left/right didn't move. Middle isn't a box anymore — it's a network, 330+ cities. SF employee hits SF, Singapore contractor hits Singapore. Nobody routes back to a central office.
→ Walk the 8 capabilities. One line each, don't dwell.
Eight checks, one pass, at that local PoP:
WARP — device healthy
Identity — Okta, Google, Apple... or whatever you use as an IDP
Access — what you're allowed to reach
Gateway — web filtering
DLP — sensitive data leaving where it shouldn't
CASB — SaaS misconfigs/oversharing
Email Security — phishing caught before landing
Browser Isolation — risky sites run in the cloud, not the laptop
Not separate products — same network, rules, logs. Same Singapore contractor, same app: ~200ms now.
→ Optional — only if engineers are in the room. Click "Do the math · Latency".
490ms vs 212ms. Can't break physics — ~180ms is the Virginia-to-Mumbai speed-of-light floor.
What actually changes:
Public internet → private backbone (rush-hour streets → toll road)
Connection stays open — no per-request setup tax
Repeat data cached in Mumbai — second user never crosses the ocean
That's the 278ms saved per click — real time back across a workday.
➡ Switch tab to one.dash.cloudflare.com. Section 1 begins.
"This is the Cloudflare One Overview — the page you land on when you log in. It's designed to answer one question in 10 seconds: is my Zero Trust deployment healthy and being used, or is it just sitting there? Let me walk you through it."
→ Point at the counters at the top of the page
"I just want to touch on a few items on this page — I won't go over all of them, some are self-explanatory. Start at the top. These counters are the pulse check. Users — seats in use out of seats provisioned, that tells me adoption. Active devices connected in the last seven days. Targets — private network resources I've registered. Applications — whatever's protected by Access policies. And Active Tunnels — outbound connections from my infrastructure to Cloudflare. I'll show those working live in a few minutes."
→ Scroll down to the "Your deployment" flow diagram
"This part is brand new — and honestly, it's one of my favorite things on the platform right now. It's a flow diagram of how traffic actually moves through Zero Trust — users on the left, the policies they pass through in the middle, the applications they reach on the right."
→ Scroll to the Connected Users widget
"Connected Users shows how people are reaching Cloudflare — Device Client only, browser only, or Both. 'Both' is the gold standard — same user, two enforcement paths, fully covered."
→ Scroll to the leaderboards at the bottom
"Finally, quick leaderboards at the bottom — top private apps, top users, top routes, top policy actions. If something looks wrong, I'll see it here before a user even opens a ticket."
"Notice the framing across this whole page — every metric is about users and applications, not networks. That's intentional. Zero Trust starts from identity and what you're trying to reach. Not what subnet you're on."
➡ Now let's go deeper — Insights tells me HOW Zero Trust is actually being used.
2. Analytics Overview Spine
▶ Insights → Overview
"This page tells me quickly whether Zero Trust is actually being used — or just configured and forgotten. Big difference."
Global Status — the sanity check
"Top left. What's enabled, what's active, what's configured. Access apps, Gateway policies, DLP profiles, seats in use. If you onboard a team here, this is where you'd watch adoption climb."
Access — every decision before the app
"The most important section on the page. Every event here is Cloudflare making a decision before the user reaches the app — allowed, denied, and why."
"If it shows up here, identity was evaluated. No anonymous access. No 'once you're in, you're trusted.'"
Proxy and DNS traffic — Gateway working in real time
"This is where SWG and DNS filtering surface. Every HTTP request and DNS query, logged and attributed."
"And here's what lands — Cloudflare doesn't just see an IP. It ties every request back to the user. Not a device. A person."
"Takeaway: visibility. Who accessed what, when, why — one place. No stitching VPN logs, firewall logs, and app logs together at 2 a.m. If somebody asks 'what was Mayah doing yesterday at 3pm?' — that's three filters away."
3. Dashboards Library
Pull this in if: prospect wants trend data or a report they can bring to their boss.
▶ Insights → Dashboards
"Built around how Zero Trust actually works — and the questions teams ask every day. Each dashboard maps to a control plane: Access, Gateway, applications, data security."
Application Access Report — what apps are people using, how often, by whom. Great for audits and access reviews.
Access Event Analytics — where teams go when someone can't get in, or after a policy change.
Shadow IT & SaaS Analytics — what SaaS are people actually using? That's how you line controls up with reality.
4. Logs Library
Pull this in if: prospect asks "where do I see that traffic now?" after moving off firewalls/VPN, or raises audit/forensics.
▶ Insights → Logs
"Dashboards show trends. Logs show proof. Organized by control plane, so instead of one giant fire-hose, it's broken out by what enforced the decision."
Access logs — every app login, allowed or denied, why.
Admin activity — who changed what, when.
Gateway DNS / HTTP / Network — DNS first because it's the earliest decision point. HTTP goes deeper. Network covers non-HTTP.
⏸ Pause
"When teams move off traditional firewalls, they always ask: 'where do I see that traffic now?' — This is where."
5. Devices Library
Pull this in if: conversation turns to BYOD, device posture, or enrollment control.
▶ Team & Resources → Devices
"Device trust. Identity is half the story — we also care about what they're connecting from."
"Devices connect through the Cloudflare One client — formerly WARP. Not a VPN. No network drop-in — traffic goes straight to our edge, policy enforced in real time."
"Because the client runs on the device, we get real context. Enrolled? Healthy? Meets posture? Access decisions are about who you are andwhat you're using."
▶ Device Enrollment
"Control who's even allowed to enroll. I have it set to my Gmail account, which is only me. Device trust stays intentional, not accidental."
6. Users Library
Pull this in if: prospect asks about IdP integration, offboarding, or killing a session remotely.
▶ Team Resources → Users
"In production you're not managing this list manually — it populates automatically from your identity provider. Okta, Entra, Google Workspace, whatever you're using."
"Once I gave my team access by allowing @cloudflare.com, they were authenticated and populated automatically. I didn't add these."
▶ Click Dustin Burke
"Admins can revoke active sessions. If a device is lost or someone leaves — access cut off immediately. No network changes. No waiting for VPN sessions to time out."
"Risk score lives here too — highlights unusual behavior tied to a user over time. Don't need to open it now, but it's there when teams want to dig deeper."
➡ Devices and users are who and what. Now let's see how they actually connect — without exposing a network.
7. Networks Overview Library
Pull this in if: conversation shifts from users/apps to network/infra topology.
▶ Networks → Overview
"This is the connectivity layer underneath Access — how users and apps reach each other without exposing the network. Quick actions at the top for tunnels, app publishing, routing. Health metrics on the right. The big idea: users connect to Cloudflare, apps connect to Cloudflare, and policy decides what's allowed — not the network."
8. Connectors + LIVE TUNNEL DEMO (the centerpiece)Spine
▶ Networks → Connectors
"Cloudflare Tunnels — outbound-only connections from the environment up to Cloudflare. No open ports. No exposed IPs. The app connects out. Nothing listens inbound."
"I'm running two connectors here, not one. In production, you never run a single tunnel for an app you care about — primary plus at least one replica. Same tunnel, multiple connectors. If one dies, the other keeps serving."
$ syscloud
UNIT LOAD ACTIVE SUB DESCRIPTION
cloudflared.service loaded active running cloudflared
cloudflared-replica.service loaded active running cloudflared-replica
2 loaded units listed.
"Two scenarios. First — one connector dies. Then — both die. Two very different stories."
DEMO A — High Availability (one connector dies, traffic keeps flowing)
▶ On the EVE-NG server:
$ systemctl stop cloudflared
"Killing the primary only. In a real outage this could be a host crash, a network blip, anything that takes one connector offline."
$ syscloud
cloudflared.service loaded inactive dead cloudflared
cloudflared-replica.service loaded active running cloudflared-replica
▶ Switch to Safari → https://eve-ng.tarheel.us
"The app loads. From the user's perspective, nothing happened. They have no idea a connector just died."
"This is the boring part of HA — and that's exactly the win. When HA is working, the demo is uneventful. The customer sees nothing. The user sees nothing. Just a working app."
▶ Back to dashboard → Networks → Connectors
"One connector degraded, one healthy. Cloudflare routes through the healthy one. No human intervention. No paging. No 3 a.m. phone call."
DEMO B — Full Failure (both connectors die, fail-closed)
▶ On the EVE-NG server:
$ stopcloud
"Now killing the replica too. Both down. Tunnel has zero connectors registered."
$ syscloud
cloudflared.service loaded inactive dead cloudflared
cloudflared-replica.service loaded inactive dead cloudflared-replica
▶ Switch to Safari → https://eve-ng.tarheel.us
"Error 1033 — Cloudflare Tunnel error."
"The tunnel is outbound-only, so when every connector drops, access fails closed. Nothing is exposed. There's no fallback path to the origin. The app is just… gone, from the internet's perspective. It stops AT Cloudflare — not at your tunnel endpoint."
"This is the part traditional architectures get wrong. When a VPN concentrator fails, you usually have a hardware backup, a public IP somewhere, some path back to the network — and that path is the attack surface. Here, when the connectors go down, there's no path at all. Nothing to find. Nothing to attack."
DEMO C — Recovery (both connectors back, traffic restored)
▶ On the EVE-NG server:
$ startcloud
⏸ Wait ~5 seconds, return to dashboard
$ syscloud
cloudflared.service loaded active running cloudflared
cloudflared-replica.service loaded active running cloudflared-replica
▶ Dashboard → Networks → Connectors
"Tunnel healthy. Both connectors connected. Uptime climbing."
"The connectors re-established their outbound connections. Access immediately restored. No firewall changes. No inbound ports. No VPN."
"That's Zero Trust in practice: outbound-only connectivity, identity-first access, automatic high availability."
▶ Click the tunnel itself → show both connectors and PoP each is connected to (IAD = Northern Virginia, ATL = Atlanta)
THE ARCHITECTURAL POINT
One down → user sees nothing. HA does its job invisibly. All down → app vanishes from the internet. Nothing to attack. Back up → connectors phone home, access restored. No firewall rule changed.
"This is what 'fail closed' actually means. Compare that to a VPN concentrator going down — and the public IP that's still sitting there."
📦 Onboarding internal servers (EC2, on-prem, anywhere) (~2 min — show if asked)
Customer trigger: "OK that's your lab — how would I actually onboard my own EC2 instances?" This is the answer.
"Three ways to bring internal servers into Zero Trust, depending on what fits your environment. Let me walk through them."
Option 1: Install cloudflared on the instance itself
"The most common pattern. Install our tunnel daemon directly on the EC2 box. Outbound-only port 443 to Cloudflare — that's the only network change needed. No security group changes. No public IP. No load balancer."
# On any EC2 instance with internet egress:
curl -L --output cloudflared.deb \\
https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb
sudo cloudflared service install <your-tunnel-token>
"Run those three commands, the instance shows up in the dashboard as a connected tunnel. Per-instance control — what I'm running on my lab right now."
Option 2: One Mesh node per VPC (subnet routing)
"What if you don't want to install software on every box? Run one Mesh node per VPC, point it at the VPC's CIDR — say, 10.0.0.0/16. Now every server, database, and resource in that VPC is reachable through that single node, with nothing installed on the rest. Great for RDP, databases, file shares, anything you can't put cloudflared on directly."
# On one EC2 instance acting as the subnet router:
sudo apt install cloudflare-warp
sudo warp-cli connector new <token>
# In the dashboard: Networks → Mesh → Advertise routes → 10.0.0.0/16
"One install, whole VPC reachable. For HA, run two Mesh nodes in different AZs — same active-passive replica pattern you saw with cloudflared."
Option 3: Magic WAN (network-level integration)
"For larger deployments who want full SD-WAN: connect your VPC to Cloudflare over IPsec or GRE. No agents anywhere — the network itself is on Cloudflare. Bigger commitment, but it's how you'd connect data centers and large enterprise environments."
The honest framing: "Start with Option 1 for the first few apps. Move to Option 2 when you want to onboard whole subnets without touching every box. Option 3 is the long-game answer for large environments."
9. Resolvers & Proxies Library
Pull this in if: a technical audience wants DNS/proxy mechanics specifically.
▶ Networks → Resolvers and Proxies
"How DNS traffic from your network gets sent to Cloudflare. Instead of installing agents, you point routers, firewalls, or DHCP at Cloudflare DNS."
"Lightweight — start with a single location, nothing changes until you actually redirect DNS at it. Agentless way to bring existing networks under Zero Trust. No re-architecture. No VPN."
10. Access Controls — Applications Library
Pull this in if: prospect asks how a specific app gets protected end to end.
▶ Access Controls → Applications
"You just saw the eve-ng app working live. This is where I told Cloudflare it exists — and what rules users have to pass to reach it."
"Every request is evaluated in real time. Identity checked, policy enforced — before traffic ever hits the app."
"This is where it breaks from the VPN model. No 'once you're in, you're trusted.' Access is per-request, scoped to the application. You get this app. That's it — no free roam on the subnet."
11. Policies Library
Pull this in if: prospect wants to see the granularity of the policy/rules engine.
▶ Access Controls → Policies
"Apps define what we're protecting. Policies define who gets access — and under what conditions."
"Define a policy once, reuse it across apps. Consistent and easy to manage."
"Every request evaluated in real time. The moment a user stops meeting policy — access stops. Not at the next login. Right then."
12. Service Credentials Library
Pull this in if: conversation is about service-to-service or non-human/machine identity access.
▶ Access Controls → Service Credentials
"Quick stop here, because this is the one most teams forget. Zero Trust isn't just for people. A lot of access today is automation — scripts, CI/CD, integrations."
"Traditionally that's handled with long-lived passwords or API keys that quietly become risk over time. Service credentials fix that — machines get an identity. Tokens or certs that can be rotated and revoked."
"Machines treated just like users. Explicitly defined, allowed by policy, evaluated every time."
➡ So far we've talked about getting in. Let's flip it — what happens once a user is on the internet.
⚙ LAB NOTE — Context switch (just for me)
Heads up to self: my Linux box runs both cloudflared AND WARP. They can't both be on. Up to this point in the demo, tunnels are up, WARP is off — that's what kept eve-ng and nginx reachable for the live demo.
For the SWG section coming up, I need WARP on, tunnels off. Do this between sips of coffee while you're transitioning:
$ stopcloud # turn off both cloudflared connectors
$ warp-cli connect # bring WARP up
Trade-off: while WARP is up, eve-ng.tarheel.us and nginx.tarheel.us are offline. If a customer hits refresh during the SWG section, they'll see a tunnel error. That's fine — the demo flow has moved on, just don't pivot back to the apps.
To return to ZTNA mode after the demo:
$ warp-cli disconnect
$ startcloud
Smooth transition line for the audience (covers the pause): "Alright — quick gear shift. We've covered how users get in. Now I want to show you what happens to their traffic on the way out."
13. Traffic Policies Overview Library
Pull this in if: you're segueing into a Gateway/SWG-specific conversation.
▶ Traffic Policies → Overview
"Cloudflare acting as a Secure Web Gateway. Controls what user traffic can do after it leaves the device."
"Traffic policies decide what's allowed, blocked, or logged across DNS and web traffic. Cloudflare sits inline and evaluates everything in real time. Disallowed? The connection just never completes."
"Same policies whether users are on the Cloudflare One client or in an office. That consistency is the win."
14. Firewall Policies (live demo)Library
Pull this in if: prospect wants to see a policy change take effect live.
▶ Traffic Policies → Firewall Policies
▶ Click the HTTP tab at the top (next to DNS and Network)
"I'm clicking into the HTTP tab here — that's where the Secure Web Gateway demo lives. DNS and Network policies are next to it, but HTTP is where you see web traffic being evaluated request-by-request."
"Real guardrails. Look at the Action column — not just block or allow. Block social media outright. Redirect LinkedIn to a Cloudflare-approved page. Isolate Netflix in a remote browser so users can still watch but nothing executes locally. Same policies remote or in-office."
▶ Show the firewall policy list in the dashboard. Point at the variety of actions: BLOCK, REDIRECT, ISOLATE.
"Eleven HTTP policies running right now, plus three DNS policies underneath. Four different actions: BLOCK (drop the request), REDIRECT (send the user somewhere else), ISOLATE (open the site in a remote browser), and BLOCK with custom message (block plus a tailored explanation). One platform, multiple ways to enforce policy."
LIVE — Watch every policy fire in real time
▶ Switch to the Linux terminal · run: traffic-gen
"This script hits a list of sites through Gateway. Watch the color-coded output."
"GREEN — ALLOWED. Clean traffic, no policy matched.
"RED — BLOCKED. TikTok, Facebook, X — user sees a clean block page.
"BLUE — REDIRECTED. LinkedIn, YouTube → cloudflare.com (or your LMS, HR portal).
"PURPLE — ISOLATED. Netflix, Spotify open in a remote browser. Pixel streams only.
"Same script, same network, four outcomes — decided at the edge in milliseconds."
▶ Show twitch.tv and hulu.com — custom block messages
"Both blocked, but with tailored messages. Twitch: 'blocked during work hours.' Hulu: 'streaming services blocked on corporate network.' Fewer help-desk tickets because users know why."
▶ Switch to Firefox · visit netflix.com directly
"Isolation in action. Netflix loads inside Cloudflare's remote browser — small banner at the top, otherwise identical UX. Any script, any download, any exploit runs in our cloud — not on the laptop."
▶ Pivot to dashboard · Insights → Logs → Gateway → HTTP · filter by tiktok.com
"Every decision logged. Filter by domain, see which policy fired and why."
▶ Mention DNS policies underneath
"DNS layer catches the broad obvious-bad — malware, phishing, C2, newly-registered domains, public DoH bypass attempts. HTTP handles the surgical stuff. Layered defense, one dashboard."
15. Egress Policies Library
Pull this in if: compliance/fixed-egress-IP requirements come up.
▶ Traffic Policies → Egress Policies
"What the outside world sees when your users go to the internet."
"By default, Cloudflare sends traffic out from the closest egress IP. Great for performance — usually exactly what you want."
"But sometimes you need a fixed IP. SaaS app or a partner that only allows traffic from specific addresses — classic example."
"Define the rule once. Users can be anywhere on the planet, but to that external service, the traffic always looks like it's coming from a known, trusted address. That's something a VPN concentrator was the only way to get for years. Now it's a checkbox."
16. Cloud & SaaS Findings Library
Pull this in if: prospect is worried about shadow IT or SaaS sprawl.
▶ Cloud and SaaS Findings → Overview · then Posture Findings
"Quick one. This page answers one question: are my cloud and SaaS apps in a good state — or not? Connect Microsoft 365, Google Workspace, whatever — we review them with a read-only API, and we do it automatically. Nothing inline, nothing breaks. It looks for risky config, data exposure, and misconfigurations — the stuff that quietly causes problems."
17. Email Security Library
Pull this in if: prospect brings up phishing or email specifically.
▶ Email Security → Overview
"Still one of the most common attack paths. Cloudflare watches email for phishing, spoofing, and BEC — behavior and patterns, not just filters. The one I really like: Retro Scan. Look back at past email and see what we would have caught without changing mail flow. Customers prove the value before flipping anything live."
18. Data Loss Prevention (DLP) Library
Pull this in if: prospect brings up data exfiltration or compliance requirements.
▶ Data Loss Prevention → Overview
"Protecting sensitive data — making sure it doesn't leave where it shouldn't."
"Easy scenario, easy to picture. An employee can't accidentally upload a list of Social Security Numbers to some random website. But they are allowed to upload them to Workday — because that's the HR system. Cloudflare scans traffic for those patterns and enforces accordingly."
"Most data loss isn't malicious. It's accidental. You define what 'sensitive' means — personal, financial, custom data — and protect it without relying on people to always make the right call. Because they won't. Every time."
19. Browser Isolation Library
Pull this in if: BYOD/contractor conversation raises "how do I let them touch data without it touching their device?"
▶ Browser Isolation → Overview
"Protecting users from risky websites. Instead of trusting the site, Cloudflare opens it somewhere else."
"The page actually runs in a remote browser — and a safe view is streamed back to the user. So if there's malware on that page, it never reaches the device."
"You control when isolation kicks in — unknown sites, risky categories, specific apps. And what users can do inside the session — copy/paste, downloads, printing."
"This ties directly into Gateway and Access. It's not a separate tool — it's another enforcement option."
20. Reusable Components (quick mention)Library
Pull this in if: technical buyer asks whether policies/rules are reusable across products.
▶ Reusable Components (describe — don't click in)
"Last quick stop — and I'll just mention it. Lists and tags."
"Lists store values — IPs, domains, URLs — so policies reference them without you repeating data everywhere. Tags attach labels to things. Users, devices, networks, apps."
"Define once, use everywhere. Sounds boring, saves you hours every month at scale."
21. Closing Spine
"What you saw today isn't a pile of security tools. It's a different access model."
"We didn't put users on a network. We didn't open ports. We didn't trust anything by default."
"Every access decision based on identity, device, and policy — enforced at the edge. Tunnel up, access worked. Tunnel down, everything stopped. Nothing else was exposed. Nothing leaked sideways."
"That's Zero Trust in practice."
"The real question isn't 'can you replace a VPN?' It's 'does your access model actually match how your business operates today?'"
⏸ Pause — let it land
"One more thing on lead times — because it always comes up. Cloudflare has no lead times. No hardware to install. Sign up today, start working today. The environment you just saw — private app, registered domain, connected to my server, accessible from anywhere on the internet — 20 minutes. Start to finish."
"Thank you for the time — happy to take a couple of questions."
Q&A — back-pocket answers
Zero Trust & Access Model
What is Zero Trust? Nothing trusted by default. Every request verified by identity, device, and policy.
Zero Trust vs. perimeter security? Perimeter trusts whatever's inside the network. Zero Trust never assumes trust based on location.
Zero Trust vs. VPN? VPNs put users on a network. Zero Trust gives access only to specific apps.
What problems does it solve VPNs can't? Lateral movement, blast radius from stolen credentials.
Product or strategy? Strategy — implemented through tools and policies.
If credentials are compromised? Device posture, re-auth, and policy still block access.
Where does Zero Trust fail? When identity, devices, or policies are too permissive.
How do contractors get in without a VPN? Cloudflare Access. They log in with their own identity (Google, GitHub, Microsoft, email OTP), get scoped to the specific apps they need — nothing else. No agent install required for web apps.
What about temporary or time-limited access? Set an expiration on the policy. Access automatically revokes at the date/time you specify. No cleanup tickets, no forgotten accounts.
What if they need access for one project, then it's done? Tag the policy by project. When the project ends, remove the rule. Their access ends instantly across every app tied to that policy.
Can I onboard a contractor in minutes? Yes. Add their email to an Access group → assign the group to specific apps → send them the URL. They log in via their existing identity provider or get an email OTP. No accounts to provision in your AD, no laptop to ship.
How do I know what a contractor did? Every access request logged — who, what, when, from where. Filter by user in Logs. Full audit trail with no extra tooling.
Can I require a managed device? Yes — device posture checks. Or, for unmanaged contractor laptops, route them through Browser Isolation so nothing executes locally on their device.
What if the contractor is hostile or compromised? Disable them in your IdP, or just remove them from the Access group. Their session is terminated. No "they might still have VPN credentials cached somewhere" problem.
Biggest misconception about ZT? That it's a product you buy.
What doesn't Cloudflare replace? SIEMs, application-level security logic.
Why do breaches still happen? Stolen credentials, excessive trust.
🔨 "Isn't this just another VPN client to install?" — DROP THE HAMMER
Open with this — slow it down, look them in the eye:
"Same form factor. Completely different architecture.
The right question isn't 'is this another VPN client?' —
it's 'what do I get to uninstall when I deploy this?'"
Then back it up with these three counters — fast, one at a time:
Counter 1
Often no client at all
Most internal apps are web apps. Users just hit a URL — auth via IdP — they're in. VPN clients are mandatory. Ours are optional for web.
Counter 2
One replaces many
Our client typically replaces: VPN client + SWG agent + DNS filter + sometimes CASB. The endpoint gets simpler, not more crowded.
Counter 3
Users feel faster, not slower
Traffic routes to the nearest of 330+ edges, not a concentrator in HQ. We resolve DNS faster than most ISPs. Users tell us the internet feels faster after install.
⚡ The kill shot — say this AFTER the three counters
"VPN clients install software so you can pretend you're inside a network. Our client installs software so you can stop pretending. That's not the same thing wearing different paint."
Delivery note: Don't rush. Pause after the opener. Pause after each counter. Pause before the kill shot. Confidence = silence. If they push back after this, you've already won — they're negotiating, not rejecting.
📋 Follow-up answers — questions from the call
Plain-English answers you can deliver naturally. No memorization needed — read it once, then say it your way. Each item links to the relevant visual demo when applicable.
1. (Oscar) What's the difference between Cloudflare's CDN/DNS stuff and Zero Trust?
Animated comparison · public CDN/DNS pipeline vs Zero Trust pipeline · side-by-side view
Same network, different jobs.
Our CDN and DNS sit in front of your public website — like a bouncer at the door. Anyone on the internet can show up, and we filter the bad stuff out before it reaches your servers.
Zero Trust is for everything that isn't public — your internal apps, your databases, your developer tools. There's no door for the internet to knock on. Users get verified by identity, then we let them in to the specific thing they need.
Example: your marketing site uses our CDN. Your internal HR portal uses Zero Trust. Same Cloudflare account, same dashboard, totally different traffic patterns.
2. (Oscar) Can we use Cloudflare for RDP and SSH to internal servers?
Animated SSH terminal + Windows RDP desktop · live audit log · policy enforcement
Yes, two ways.
The easy way: users open a URL in their browser, log in, and get a working RDP or SSH session right there in the browser tab. No PuTTY, no Remote Desktop client, no agent install. Works from any laptop.
The power-user way: if your developers want to use their normal SSH client, they can. Cloudflare just makes sure the connection goes through identity and policy checks first.
Example: a contractor needs RDP into a production Windows box. You send them a URL. They log in with their Google account. They're in. You see every keystroke logged. When the project ends, the URL stops working.
3. (Paul) India developer to AWS East — doesn't the traffic still cross the globe?
Honest answer: yes. We can't break physics. If the server is in Virginia and the user is in Mumbai, the bits still have to go between them.
But we change how they make the trip:
Instead of taking whatever messy path the public internet gives them, traffic goes onto our private backbone — like switching from rush-hour streets to a toll road.
We hold the connection open instead of rebuilding it every time, so the user doesn't pay the "setup tax" on every request.
If the same data is requested twice, we cache it in Mumbai. The second user never has to cross the ocean at all.
Example: a Mumbai developer pulling logs from an AWS East server. On a normal VPN that's about 280ms per request. Through us, it's around 145ms. Not zero — but cut in half.
If they push back: "Let's run a real test on your traffic for a week. I'll show you the actual numbers, not my marketing numbers."
📊 Visual:VPN vs Zero Trust diagram → click "Do the math · Latency" tab for the hop-by-hop breakdown.
4. (Oscar) How do I get my EC2 instances onto the Cloudflare network?
Three ways, depending on how much you want to install where.
One server at a time: install our small connector program on each EC2 box. Three commands. It reaches out to Cloudflare — nothing reaches in. This is what I showed you live in the demo.
A whole VPC at a time: install on one EC2 box, tell it "I represent this whole network." Now everything in that VPC is reachable through that one connector. No agents on the other boxes.
A whole data center: if you want full network-level integration, we set up an IPsec tunnel from your network gateway to us. No software on any box.
The important part: in all three patterns, your servers only make outgoing connections to us. You don't open any firewall ports for the internet to reach them. There's nothing exposed.
5. What about contractors who can't install our security client?
They don't have to. That's actually our strongest story for external users.
You send them a URL. They open it in any browser. They sign in with their own Google or Microsoft account — whatever they already have. They're in. Scoped to just the app you allowed.
You can set the access to expire automatically when the project ends. No tickets to clean up. No forgotten accounts sitting in your AD.
Example: you bring in three contractors for a Q4 audit. You give them a URL and assign them to the "Q4 audit" group. They use their own laptops. When December 31 hits, the URL stops working for everyone in that group. Done.
A traditional VPN sends every user's traffic to one or two appliances at your headquarters. If you're a developer in London accessing an app in London, your traffic goes London → Texas → London → Texas. That's the speed problem.
We have data centers in 330+ cities. The user connects to the one closest to them. Policy gets enforced right there. Then traffic takes the shortest path to the app. No detour through your HQ.
Example: a sales rep in Singapore opens your internal CRM. On the VPN, that's a 300ms round trip through your US data center. Through us, it's 90ms because we enforce in Singapore. They feel the difference immediately.
How big the win is depends on how spread out your team is. If everyone's in one office, we're only a little faster. If you have a hybrid workforce across multiple continents, we're a lot faster.
For a 12-minute guided architecture walkthrough that hits multiple: Guided demo flow
For static slides: screenshot each demo, drop into a 3-slide deck, send as a follow-up.
8. How exactly does Magic WAN connect — what's the link?
Magic WAN hooks your network to Cloudflare at the router level — no software on any laptop or server. Four ways to make the connection:
IPsec tunnel — the most common. Standard encrypted tunnel from your firewall/router (Palo Alto, Fortinet, Cisco, AWS VPN Gateway, etc.) to Cloudflare's IPs. Two endpoints, shared key, done. Like running a private encrypted line between your office and Cloudflare.
GRE tunnel — same idea but lighter and faster. No built-in encryption. Used when you need raw throughput. GRE is the older, faster cousin of IPsec.
Cloudflare Network Interconnect (CNI) — a physical or virtual direct connection to our backbone, bypassing the public internet entirely. Available at major peering points (Equinix, Megaport) and in cloud regions (AWS Direct Connect, Azure ExpressRoute, GCP Partner Interconnect). This is a literal cable between your network and ours.
WARP Connector — software-based fallback. Runs on a Linux box inside your network when you can't touch the router itself. If you can't change the router, put one of these on a server in the network instead.
What you get once connected: Cloudflare becomes both your network's on-ramp to the internet (Gateway, DLP, filtering) and the path between your sites. Branch-to-branch traffic flows through Cloudflare's backbone instead of MPLS.
Example: you have an AWS VPC in us-east-1, an office in Atlanta, and a data center in Dallas. Set up one IPsec tunnel from each — three tunnels total. Now anything in any of those three places can reach anything in the other two, securely. You retire MPLS. You retire the VPN concentrator. Network team configures it all in our dashboard.
When to use Magic WAN vs. Tunnel/Mesh:
Tunnel/Mesh = software approach. Good for individual apps or VPCs. Small/medium deployments.