Multi-CDN buys availability, and the availability math has a security corollary nobody advertises: with two edges serving the same hostnames, attackers get to choose which one they attack. Whatever WAF rule, rate limit or token check exists on one CDN and not the other is not partial protection — it is a documented bypass, discoverable by anyone who resolves your DNS twice. Running multiple CDNs means your effective security is the minimum across them, and keeping that minimum high is a discipline with its own tooling.
Your security is your weakest edge
The failure mode is mundane. The primary CDN gets years of tuning — WAF exceptions, bot thresholds, tightened limits — while the secondary, added for failover, keeps its onboarding-day defaults. Traffic steering then sends some fraction of live traffic (or all of it, during the failover the secondary exists for) through the untuned edge, and the incident during a failover is the attack that was always being blocked, suddenly not. The corrective mindset: there is one security policy, owned in one place, and each CDN is merely an implementation of it. The moment policy lives in a vendor dashboard rather than a document, parity is already lost — you just have not measured it yet.
The parity matrix
The working artifact is a matrix: controls as rows, CDNs as columns, every cell one of implemented, partially implemented (with the gap named), or not available on this platform. Rows worth having: TLS floor and cipher policy; HSTS and the security-header set; WAF ruleset and the exception register; rate limits per endpoint tier; bot handling per lane; geo rules; token authentication parameters; origin-trust mechanism; logging and alert delivery. Fill it from configuration exports where the platform supports them, not from memory, and date every cell. The first pass is always humbling — teams discover the secondary lacks half the rows — and the matrix converts that from a vague unease into a ranked worklist. Review it whenever either platform ships changes, and at minimum each quarter alongside the security audit.
Portable controls vs native features
Parity is easiest for controls you can express identically everywhere, so prefer portability where the option exists. Security headers are perfectly portable — the same five headers configure anywhere in minutes. Rate-limit budgets port cleanly even when window semantics differ slightly; document the budget, implement per platform, accept small mechanical variance. WAFs are the hard case: managed rulesets differ genuinely across vendors, so express your policy as outcomes — the attack classes that must block, your application’s known quirks that must not false-positive — and verify each platform against that outcome list rather than trying to mirror rule IDs that have no equivalent. The genuinely native features (one vendor’s bot scoring, another’s ML anomaly engine) force an honest choice: find the closest equivalent and note the delta in the matrix, compensate on the weaker platform with tighter portable controls on the same endpoints, or decide the feature is critical enough that the steering layer must never route its traffic to the platform lacking it — a constraint your failover design then has to honour, as covered in the failover setup.
Tokens, certificates and origin trust
Three controls need bit-level compatibility, not just policy parity. Signed URLs: a token minted by your application must validate at whichever edge receives it, which in practice means choosing a scheme both platforms can verify — same algorithm, same claim structure, secrets provisioned to both — and testing the same token against each edge; where native schemes are incompatible, edge-compute validation of one common format is the escape hatch, and rotation now means dual-key windows on every platform simultaneously (see the signing guide). Certificates: every hostname needs valid certificates on all CDNs at all times — a secondary with an expired cert is a failover that fails on arrival — which under shrinking lifetimes means renewal automation per platform, monitored per platform. Origin trust: the origin must accept fetches from every CDN and only those, so allowlists cover both providers’ ranges, per-CDN secret headers or client certificates let the origin log which edge is calling, and adding a CDN triggers an origin-config change by checklist, not by outage.
Testing for drift, continuously
Parity decays like all configuration, so the real control is a test suite that treats every CDN as a target: the WAF regression payloads from tuning, a rate-limit probe, a token check (valid must pass, expired must fail), a header assertion, a TLS scan — run against each edge by resolving each provider’s hostname explicitly, on a schedule and after every config change on any platform. Diff the results across columns: a check passing on one CDN and failing on another is drift, caught by you rather than by an attacker with a dig command. Wire the suite into the change process — a config change on one platform is not done until the suite passes on all — and parity stops being a quarterly repair job and becomes a property the estate simply has. The reward is that failover day, the reason the second CDN exists, changes nothing about your security posture at all.