Skip to content
Security guide

Secure Cloudflare Architecture: Reference Design

A secure Cloudflare architecture secures four things: the account, the credentials, the applications and the origin. Enforce 2FA and keep Super Administrators few; replace the Global API key with scoped account API tokens; put internal tools behind Access and have applications validate its token; and make Cloudflare the only way to reach the origin, ideally through an outbound-only tunnel.

This guide draws that design, explains each area in plain words, maps it to Cloudflare's own documentation and ends with a decision checklist. Every claim comes from Cloudflare documentation read on 4 November 2026.

Updated 4 November 2026 (last reviewed)

TL;DR

The short version

5 points
  • Account: enforce 2FA, use security keys for administrators, keep the Super Administrator list short.
  • Credentials: account API tokens with narrow permissions, expiry and IP filtering; stop using the Global API key.
  • Applications: Access policies that name people or groups, device posture where it matters, and token validation at the origin.
  • Origin: Cloudflare Tunnel with inbound blocked, or Full (strict) with Authenticated Origin Pulls and a Cloudflare-only firewall; proxy records and clean DNS-only records.
  • Edge and evidence: DNSSEC, managed rules, custom rules, rate limiting, and audit logs exported to your SIEM.

The reference architecture

Read the figure from the left: visitors and staff arrive at the Cloudflare edge, where DNS, TLS, the WAF and Access sit. A tunnel carries allowed traffic out to the origins, which keep no inbound ports open. Underneath, the account plane decides who can change any of it.

Reference architecture for a secure Cloudflare setupVisitors and staff reach the Cloudflare edge. Visitors pass DNS with DNSSEC, the WAF with managed and custom rules and rate limiting, then a Cloudflare Tunnel to the public application origin. Staff use the Cloudflare One Client with device posture, pass Access policies and reach internal applications through the same tunnel. The origin has no inbound ports open. Below the edge, the account plane holds enforced 2FA and roles, scoped account API tokens and audit logs exported to a SIEM.Visitorspublic internetStaff deviceCloudflare One Clientdevice postureCloudflare edgeDNS with DNSSECproxied records, DS at registrarTLS Full (strict)no Flexible or OffWAF: managed rules, custom rulesrate limiting on login and API pathsZero Trust AccessAllow / Require / Exclude on identity and device postureService Auth for machines, Bypass rare and scopedsigned token sent to the applicationYour networkcloudflaredoutbound-onlytunnelOriginspublic site, admintool, wikivalidate Access token,inbound blockedtunnelAccount plane (who can change the setup above)Members and roles2FA enforced, security keys,few Super AdministratorsAccount API tokensscoped permissions and resources,expiry, IP filter, no Global keyAudit logsexported to a SIEMvia API or LogpushPlayCISO illustration based on Cloudflare documentation. Layout and labels are ours, not a Cloudflare diagram.
Figure 1. Reference architecture. Traffic is filtered at the edge, staff and applications are separated by Access, origins connect out through a tunnel, and a separate account plane controls who can change any of it. Cloudflare publishes its own reference architectures; this figure is our simplified illustration.

Design areas and where Cloudflare documents them

The table maps each design area to the Cloudflare pages that support it. The wording of the “what to do” column is ours.

AreaWhat to doSource
Account access2FA Enforcement for all members, security keys for administrators, a short Super Administrator list and narrower roles for everyone else.Two-factor authentication, Account roles
CredentialsAccount API tokens with only the needed permissions on only the needed resources, with expiry and client IP filtering; no Global API key.Account API tokens, Create API token, Global API key
Identity-aware accessAccess Allow policies naming people or groups, Require rules for stronger checks, Exclude for known exceptions; Service Auth for machines.Access policies
DevicesCloudflare One Client and device posture checks verified before enforcement; identity provider and team domain included in the client.Cloudflare One Client, Device posture
Application trustValidate the Cf-Access-Jwt-Assertion token at the application and follow the key rotation.Validate Access JWT
OriginCloudflare Tunnel with inbound blocked; otherwise Full (strict), Authenticated Origin Pulls and Cloudflare-only firewall rules; proxy records and clean DNS-only records.Cloudflare Tunnel, Protect your origin server, Authenticated Origin Pulls, SSL/TLS encryption modes
DNSDNSSEC enabled with the DS record at the registrar.DNSSEC
Edge protectionManaged rulesets, custom rules for sensitive paths and rate limiting for login and API endpoints.WAF overview, WAF managed rules, WAF custom rules, Rate limiting rules
EvidenceAudit logs reviewed and exported beyond the 90-day dashboard window.Audit logs

Account access and credentials

Cloudflare recommends two-factor authentication for all users, and Super Administrators can turn on 2FA Enforcement so members must enable it; a security key gives phishing-resistant authentication, and Cloudflare recommends at least two factors or several keys to avoid lockout (Two-factor authentication). The Super Administrator role can edit any setting, update billing and manage members, so hand out narrower account roles such as Administrator Read Only, Cloudflare Access or Audit Logs Viewer instead.

For machines, use tokens. The Global API key reaches all of a user's resources with the user's full permissions, is limited to one per user and cannot carry the time and IP limits tokens can. Account API tokens act as service principals for CI/CD and keep working when their creator leaves; members can only grant permissions that are a subset of their own. When you create a token, pick permissions and resources, then add client IP filtering and a TTL. The secret is shown once, and new tokens use scannable prefixes so leaks can be detected. Practise in the Cloudflare Security Lab.

Access, devices and application trust

Access policies combine an action (Allow, Block, Bypass or Service Auth), rule types (Include, Require, Exclude), selectors and values. Access is deny by default, and every policy needs at least one Include rule. Bypass disables Access enforcement and its requests are not logged, so Cloudflare suggests Service Auth when you want enforcement and logging without user login.

The Cloudflare One Client reports device health so device posture checks can be used in Access and Gateway policies; verify the results before enforcing, and make sure traffic to your identity provider and team domain goes through the client. Finally, have the application validate the Access token in the Cf-Access-Jwt-Assertion header; the signing key rotates every 6 weeks by default and the previous key stays valid for 7 days.

Origin lockdown

Cloudflare's origin guidance starts with DNS: proxy records, audit DNS-only records for origin addresses, avoid mail on the same server and rotate origin IPs after onboarding, since historical records keep old addresses. It then lists options by layer. Cloudflare Tunnel makes outbound-only connections from cloudflared, so you can block all inbound traffic. Where a tunnel is not possible, Authenticated Origin Pulls makes the origin accept only requests from Cloudflare, needs Full or Full (strict) encryption mode, and does not apply to tunnelled hostnames; the shared Cloudflare certificate only shows a request came from Cloudflare, so use your own certificate for account-level assurance. Allowlisting Cloudflare IPs is rated moderately secure and vulnerable to spoofing, so treat it as an extra layer.

DNS, WAF and rate limiting

With DNSSEC, Cloudflare signs your zone and gives you a DS record to add at your registrar; when onboarding an existing domain, disable DNSSEC at the old provider first. The WAF runs managed rulesets that are updated regularly, custom rules that run in order, and rate limiting rules defined by characteristics, period, request threshold and mitigation timeout. Rate limiting is not exact, so keep application-side limits.

Evidence

Audit Logs are account-based and record user-initiated actions across the API and dashboard, with the authentication method and interface used. They are kept for 18 months, the version 2 dashboard queries only the last 90 days, and the API or Logpush reach the full period. Export them so DNS, token and member changes reach your SIEM.

Decision checklist

Answer each with yes, partly or no. Every “no” is a design decision to make. For a scored version with per-domain gaps and export, use the Cloudflare Security Checklist.

  1. Is 2FA enforced for every member, with security keys for administrators and a second factor registered for everyone?
  2. Is the Super Administrator role limited to the few people who need it?
  3. Has every integration moved from the Global API key to an account API token with narrow permissions, an expiry and IP filtering?
  4. Are internal applications behind Access Allow policies that name people or groups, with Bypass rare, scoped and tested?
  5. Do sensitive applications require a verified, healthy device through the Cloudflare One Client?
  6. Do your applications validate the Cf-Access-Jwt-Assertion token and follow the key rotation?
  7. Do origins connect through Cloudflare Tunnel, or else use Full (strict), Authenticated Origin Pulls and a Cloudflare-only firewall?
  8. Have DNS-only records been checked for origin addresses and origin IPs rotated after onboarding?
  9. Is DNSSEC enabled and the DS record published at the registrar?
  10. Is the Cloudflare Managed Ruleset deployed, with custom rules for admin, login and API paths?
  11. Do login and expensive endpoints have rate limiting rules, with application-side limits behind them?
  12. Are audit logs exported to your SIEM, and does someone review changes to DNS, tokens and members?

What this guide does not claim

  • Plan limits differ: for example, custom rule counts and rate limiting options vary by plan on the Cloudflare pages. Check your plan before you design around a feature.
  • The diagram is our simplification. Cloudflare publishes its own reference architectures, which we did not map here.
  • Cloudflare pages change; each source shows its own “last updated” date and we read them on 4 November 2026. Last reviewed 4 November 2026.
  • This is not an audit or a compliance opinion.

Frequently asked questions

What is a secure Cloudflare architecture?

It is a Cloudflare setup in which the account, the credentials, the applications and the origin are each locked down: 2FA enforced and few Super Administrators, scoped account API tokens in place of the Global API key, internal tools behind Access with validated tokens, origins reachable only through a tunnel or with Authenticated Origin Pulls, DNSSEC on the zone, and the WAF and rate limiting in front of public applications.

Why not just use the Global API key?

Cloudflare says the Global API key has access to all of a user's resources with the user's full permissions, only one can exist per user, and it cannot be limited by expiry or IP the way API tokens can. Cloudflare encourages current users to migrate to API tokens.

Is Cloudflare Tunnel better than allowlisting Cloudflare IPs?

Cloudflare's own origin guidance rates Tunnel as very secure and IP allowlisting as moderately secure and vulnerable to IP spoofing. Tunnel uses outbound-only connections so you can block inbound traffic. Allowlisting is still a fine extra layer where a tunnel is not possible.

Do I need Authenticated Origin Pulls if I use Tunnel?

No. Cloudflare says Authenticated Origin Pulls does not apply to hostnames routed through Tunnel, which already authenticates origin traffic with connector credentials. AOP is for proxied origins that still have an inbound listener, and needs Full or Full (strict) encryption.

Should my application check the Access token?

Yes. Cloudflare sends an application token in the Cf-Access-Jwt-Assertion header and says to validate it with your public key so you know the request came from Access. The signing key rotates every 6 weeks by default, so refresh the keys.

Does a WAF replace patching?

No. Managed rulesets are updated regularly and cover known attack techniques, and custom rules and rate limiting add targeted control, but Cloudflare notes rate limiting is not designed to allow a precise number of requests to reach the origin. Keep patching and application-side defences.

Sources

🖤 Black Friday: new customers get 3 months of Pro for $5, then $5/month. Ends 30 Nov. Claim 3 months for $5 →