A content delivery network ends up holding your TLS private keys, deciding what gets cached and served to whom, and sitting in front of every request to your public services, yet it is often chosen on price per gigabyte and edge latency. Once traffic flows through it, the CDN is a supplier with privileged access to your data in transit and a control plane that can redirect or expose your whole web estate. This vendor-neutral guide sets out the security requirements to write into a CDN selection: key custody, origin protection, cache safety, account and API governance, logging, edge code and supplier assurance. It is for security architects, platform teams and procurement leads running an RFP or a renewal. It covers selection only; for configuring a CDN you already run, see the CDN Security Guide.
Key takeaways
- Key custody is the first decision. Decide whether the provider may hold your private keys, use certificates it issues, or must call back to a key server you run, and check which plans actually offer each option.
- Origin protection must be cryptographic, not only IP-based. Shared edge IP ranges mean an IP allowlist also admits other customers of the same provider; require mutual TLS, signed tokens or private connectivity to the origin.
- Cache behaviour is a data protection control. Require that the CDN honours
Cache-Control: privateandno-store, and that path normalisation matches your origin, or you risk serving one user's data to another. - The CDN console and API are privileged identities. One API token can change DNS, disable the WAF or repoint an origin, so demand SSO, enforced MFA, scoped and expiring tokens, and a complete audit log.
- Logs and evidence decide whether you can investigate. Insist on request-level log streaming to your SIEM, configuration change history, and contractual incident notification before you sign.
Define requirements
Start from what the CDN will carry, not from a feature list. NCSC's 14 Cloud Security Principles are a useful frame because a CDN is a cloud service: data in transit protection (principle 1), separation between customers (3), operational security (5), identity and authentication (10), external interface protection (11), and audit information for customers (13) all apply directly. Write down:
- Traffic classes: static public assets, authenticated HTML, APIs, file downloads, video, and any regulated data (payment, health, personal data). Each class needs its own caching and TLS decision.
- Key custody stance: provider-managed certificates, your certificates uploaded to the provider, or keyless operation where the private key never leaves your infrastructure. Record which hostnames fall into each.
- Data location: where TLS is terminated and content is decrypted and cached. If personal data may only be processed in certain regions, you need regional edge restrictions, not just regional storage of logs.
- Origins: cloud object storage, load balancers, on-premises servers, and how each will be locked to the CDN.
- Adjacent services: whether WAF, bot management and DDoS mitigation come from the same provider. See the WAF and WAAP Buyer's Guide and the DDoS Protection Buyer's Guide.
- Operating model: configuration through the console, through infrastructure as code, or both, and who holds the provider accounts.
Capability areas
The table lists the security capability areas to score, what to require, and why each one matters during an incident.
| Capability area | Minimum requirement | Why it matters |
|---|---|---|
| TLS at the edge | TLS 1.3 and TLS 1.2 only, configurable minimum version per hostname, modern cipher suites, HSTS support, automated certificate renewal | NIST SP 800-52 Rev. 2 requires government TLS servers to support TLS 1.2 with approved cipher suites and TLS 1.3 by 1 January 2024 |
| Key custody | Choice of provider-managed, customer-uploaded or keyless certificates; documented key storage and staff access | Whoever holds the key can impersonate the site and decrypt traffic |
| Edge to origin TLS | Full certificate validation to the origin (no "flexible" or unencrypted back haul), mutual TLS available | An unencrypted or unvalidated origin leg undoes edge encryption (NIST SP 800-53 SC-8) |
| Origin authentication | At least one cryptographic option: client certificate per account or hostname, signed origin requests, or private connectivity; published edge IP ranges as a secondary layer | Attackers who find the origin IP bypass every edge control |
| Cache controls | Honours origin Cache-Control by default, per-path rules, cache key control, extension and content-type checks, purge by URL, tag and prefix via API | Cache deception and poisoning turn the CDN into a data leak |
| Access control | SAML or OIDC SSO, enforced MFA, role-based access with read-only and per-zone roles, SCIM or equivalent deprovisioning | The console can reroute or expose every service |
| API tokens | Scoped to resource and permission, expiry dates, IP restrictions, last-used data, revocation | Automation tokens are long-lived non-human identities |
| Logging | Request logs streamed near real time to your storage or SIEM, audit log of every configuration change with actor and source IP | Without them you cannot scope a cache leak or a malicious change |
| Edge compute | Isolation model documented, secrets store for edge code, deploy permissions separate from config permissions, versioning and rollback | Edge code runs on every request with access to cookies and headers |
| Supplier assurance | Independent audit reports, vulnerability disclosure policy, incident notification terms, sub-processor list | The provider's own compromise becomes yours |
Origin protection options compared
Major platforms document several ways to make the origin accept only CDN traffic. They are not equal, and the strongest designs combine two.
| Approach | Documented examples | Strength | Limitation |
|---|---|---|---|
| Edge IP allowlist | Published IP lists, cloud service tags such as AzureFrontDoor.Backend | Simple network control | Microsoft notes that other Front Door customers share the same IPs, so IP filtering alone is not sufficient |
| Provider identifier header | The X-Azure-FDID header checked against your profile ID | Ties traffic to your profile | Header value is a static identifier; pair with IP filtering |
| Mutual TLS from edge to origin | Authenticated Origin Pulls at zone or per-hostname level with your own certificate | Cryptographic proof the request came through your account | A global, provider-shared certificate only proves the request came from the provider network, not from your account |
| Signed requests to cloud storage | CloudFront origin access control for S3 and other AWS origins; managed identity tokens on Front Door (preview) | Origin stays private, no shared secret to rotate | Usually limited to the provider's own cloud origins |
| Private connectivity | Private Link origins (Front Door Premium), VPC origins (CloudFront) | Origin has no public endpoint at all | Tier and region dependent; check pricing tier |
Ask every bidder which of these they support for each of your origin types, and on which plan. Tier gating is common: Microsoft documents Private Link origins on the Premium tier only, and Cloudflare documents Keyless SSL as an Enterprise add-on.
Evaluation criteria
Weights are an NHI Mgmt Group suggestion; adjust them to your traffic classes. Score each criterion 0 to 3 from evidence, not from the datasheet.
| Criterion | Weight | Evidence to request | Maps to |
|---|---|---|---|
| Key custody and TLS | 15% | Key storage design, HSM use, staff access controls, TLS policy options per hostname, FIPS 140-3 validated modules if you need them | SP 800-53 SC-8, SC-12, SC-13; CSF PR.DS-02 |
| Origin protection | 15% | Supported options per origin type and tier, demonstrated in POC | SC-7 |
| Cache safety | 10% | Default caching behaviour, normalisation rules, deception protections, purge latency | SC-8 |
| Identity and access to the platform | 15% | SSO, MFA enforcement, roles, token scoping and expiry, deprovisioning | AC-2, IA-2 |
| Logging and audit | 15% | Log fields, delivery latency, retention, change audit log, SIEM integrations | AU-2, AU-12 |
| Availability and DDoS | 10% | Capacity per customer, SLA terms, behaviour under attack | SC-5; CSF PR.IR-04 |
| Change safety | 10% | Infrastructure as code provider, staged rollout, versioned config, one-step rollback | CM-3, CM-6 |
| Supplier assurance | 10% | Audit reports, vulnerability disclosure, incident notification clause, sub-processors | SA-9, SR-6; CSF GV.SC-05, GV.SC-06 |
CISA's Secure by Demand Guide is a good source of baseline questions for any software supplier: SSO at no extra cost, MFA by default, no default passwords, security logs in the base product and, for cloud services, logs retained for at least six months at no extra charge, plus a published vulnerability disclosure policy. Treat a provider that charges extra for SSO or audit logs as weaker on those criteria, not as an add-on negotiation.
Where identity fits
A CDN account is one of the most powerful identities you will create. Console users, API tokens used by CI/CD and Terraform, edge code deploy keys, and the client certificates used for origin authentication are all credentials an attacker would want. Require that the provider can show every token, its scope, its creator and when it was last used, and that tokens can be set to expire. Keep provider accounts in your joiner, mover and leaver process with SCIM or a reviewed manual equivalent. The Cloudflare 2023 incident, where credentials not rotated after an earlier Okta compromise let an attacker into internal systems, is a reminder that a CDN provider's own credential hygiene is part of your risk; see the Cloudflare Thanksgiving Breach 2023. For token governance see the API Key Management Guide, and for certificates the Machine Identity, PKI and Certificate Lifecycle Guide.
Decision guidance by organisation size
- Small teams: favour a provider whose secure options are on by default (full origin certificate validation, MFA enforced, honouring origin cache headers) over one with more knobs. Buy the tier that includes SSO and audit logs even if you need nothing else from it, and use provider-managed certificates unless policy forbids it.
- Large or regulated estates: expect to need per-hostname key custody choices, private origin connectivity, regional decryption limits, log streaming with at least six months of retention, and configuration fully managed as code with change approval.
- Multi-CDN: two providers improve availability but double the keys, tokens, rule sets and logs to govern. Only adopt it if you can keep security rules equivalent across both, and test failover with the same origin protection on each path.
- Bundled edge security: buying CDN, WAF and DDoS mitigation from one provider simplifies operations but concentrates control plane risk; weigh that against the separate WAF and WAAP Buyer's Guide criteria.
Questions to ask vendors
- Where are customer private keys stored, are they held in hardware security modules, which staff roles can access them, and is that access logged and reviewed?
- Do you offer an option where our private key never leaves our infrastructure, on which plans, and what TLS versions and certificate types does it support?
- Which origin authentication methods do you support for each origin type, is any client certificate shared across customers, and can we use our own per-hostname certificate?
- What is the default caching behaviour when the origin sends no
Cache-Controlheader, and can any rule overrideprivateorno-store? - How do you normalise URL paths (encoded slashes, dot-segments, trailing delimiters) before cache key calculation, and do you offer a check that content type matches the file extension?
- Can we enforce SSO and MFA for every console user with no local password fallback, and how is break-glass access handled?
- Can API tokens be scoped to a single zone and permission, set to expire, restricted by source IP, and listed with last-used dates?
- Which request log fields can we stream, with what delay, to which destinations, and is the configuration audit log available through an API?
- In which locations is our traffic decrypted and cached, and can we restrict that to named regions?
- How quickly will you notify us of a security incident affecting our account or keys, and is that a contractual term?
- Which independent audit reports and certifications can you share under NDA, and do they cover the edge network and the control plane?
- How is edge code isolated between customers, where are its secrets stored, and who can deploy it?
Red flags
- An encryption mode that serves HTTPS to users but connects to the origin over plain HTTP or without validating the origin certificate, offered as a default or a recommended setting.
- Origin protection based only on shared IP ranges or a static shared header, with no cryptographic option on your tier.
- Caching rules that silently override origin
Cache-Controlheaders, or no documentation of path normalisation. - SSO, audit logs or log streaming only available on the top tier, or audit logs kept for days rather than months.
- API tokens with account-wide scope and no expiry as the only option.
- No vulnerability disclosure policy, no incident notification commitment, or refusal to share audit reports.
- Vague answers about where decrypted traffic is processed when you have data residency obligations.
Proof of concept
Run the POC on a non-production hostname that mirrors a real application, including an authenticated page and an API. Keep the old path live so you can roll back by changing DNS.
- Onboard the hostname with your chosen key custody model and confirm the certificate chain, TLS versions and cipher suites offered from several regions with an external TLS scanner. See the TLS Server Configuration Baseline Guide.
- Lock the origin using the strongest option the provider offers, then send a request directly to the origin IP and confirm it is refused. Send a request through a second account on the same provider and confirm that is refused too.
- Test cache safety: request an authenticated page with a static-looking suffix and an encoded path variant, then request the same URL without credentials and confirm nothing private is returned. The Web Cache Poisoning and Cache Deception Guide describes the classes to test.
- Configure SSO, enforce MFA, create a scoped expiring token for your pipeline, and confirm a revoked token fails immediately.
- Make three configuration changes and confirm each appears in the audit log with actor, time and source IP, and that request logs reach your SIEM within the agreed delay.
- Manage the configuration through infrastructure as code, apply a bad change, and time the rollback.
- Purge a cached object by URL and by tag and measure global purge time, which is your containment time if sensitive content is cached.
- Agree go-live metrics: percentage of origins with cryptographic origin authentication, number of tokens without expiry, log delivery delay, purge time, and mean time to roll back a configuration change.
After selection, follow the CDN and DDoS protection service rollout playbook and harden the platform with Securing the CDN and DDoS protection service itself. Keep the If your CDN and DDoS protection service is compromised playbook ready before go-live.
Primary sources used here: NCSC: The Cloud Security Principles, CISA: Secure by Demand Guide, NIST: SP 800-52 Rev. 2, NIST: SP 800-53 Rev. 5, NIST: Cryptographic Module Validation Program, Microsoft Learn: Secure traffic to Azure Front Door origins, AWS: Restricting access to an origin, Cloudflare: Authenticated Origin Pulls, Cloudflare: Keyless SSL and PortSwigger: Web cache deception. Products are named only to illustrate documented features; this is not a recommendation.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our NHI and AI products directory or contact us.
Related NHI Mgmt Group resources: CDN Security Guide · WAF and WAAP Buyer's Guide · DDoS Protection Buyer's Guide · Security Requirements for Selecting a Load Balancer · Subresource Integrity (SRI) Guide