Cloudflare and NIS2 Compliance: What Magic Transit, WAF, and Zero Trust Cover Under Article 21 — And the Supply-Chain Question Most Guides Skip

Somewhere behind a meaningful share of the essential and important entities NIS2 covers sits a Cloudflare dashboard — DNS, a WAF rule set, maybe Magic Transit absorbing DDoS traffic before it reaches the origin. Almost none of those deployments were configured with Article 21 in mind, because most predate the Directive’s 17 October 2024 transposition deadline by years. That gap matters now that competent authorities are running audits: an auditor doesn’t ask whether your CDN is fast, they ask which Article 21(2) measure it evidences, and whether you can produce a document proving you set it up that way on purpose.

This guide maps five specific Cloudflare products to the exact NIS2 Article 21(2) letter and Commission Implementing Regulation (CIR) 2024/2690 sub-point each one supports, shows the six Article 21(2) categories none of them touch, and covers the one supply-chain question Cloudflare’s own compliance materials don’t answer.

Does Article 21 Even Care Which CDN You Use?

Directly, no — Article 21 regulates your organisation, not your vendor’s product catalogue. Article 21(1) requires essential and important entities to take “appropriate and proportionate technical, operational and organisational measures” [1], and Article 21(2) lists ten categories those measures must cover, based on an all-hazards approach [1]. Nowhere does the Directive name Cloudflare, or any specific vendor.

CIR 2024/2690, the implementing regulation that turns Article 21(2) into concrete technical sub-requirements, works differently. Its Annex binds only entities in roughly ten digital-infrastructure categories directly — DNS providers, cloud computing services, content delivery networks, managed service providers, and similar [3]. Cloudflare is itself a CDN and DNS provider, so CIR 2024/2690 applies to Cloudflare directly, as a matter of its own compliance. If your organisation isn’t one of those ten categories, the CIR Annex isn’t legally binding on you — but it’s the clearest official interpretation of what network security and “acquisition” mean under Article 21(2), so auditors and consultants use it as a benchmark regardless of sector. That’s the frame for everything below: Cloudflare’s products can evidence your Article 21(2) measures. They can’t file your paperwork.

Five Cloudflare Products, Mapped to Article 21(2) — With the Exact CIR Sub-Point

Five Cloudflare products map cleanly onto four of the ten Article 21(2) letters. None of them map onto the other six — worth remembering as you read the scorecard further down. Here’s the letter-by-letter and CIR sub-point breakdown, checked against the Directive text and CIR Annex rather than product marketing.

Magic Transit → Article 21(2)(e), CIR Section 6.7

Magic Transit sits in front of your network and absorbs volumetric DDoS traffic before it reaches your infrastructure, using BGP route announcements to pull inbound traffic into Cloudflare’s network at the nearest data center and filter it there — Cloudflare states malicious traffic is typically identified and blocked within three seconds, backed by 500 Tbps of stated network capacity [4]. That’s a direct technical control for Article 21(2)(e), “security in network and information systems acquisition, development and maintenance” [1], and specifically for CIR Annex Section 6.7 (“Network Security”), which requires “appropriate measures to protect… network and information systems from cyber threats” through documented network architecture and access controls [3].

What it doesn’t do: write the network architecture documentation Section 6.7 actually asks for. Cloudflare mitigates the attack; your team still has to produce the diagram and access-control policy explaining why Magic Transit sits where it does.

Web Application Firewall (WAF) → CIR Section 6.1 and 6.7

The WAF inspects and blocks malicious HTTP requests at the edge — SQL injection, cross-site scripting, known CVE exploitation — before they reach your application. It covers the same Article 21(2)(e) / CIR 6.7 network-security ground as Magic Transit, at the application layer instead of the network layer.

It also touches a second CIR sub-point most vendor-mapping content skips: Section 6.1, “Security in Acquisition of ICT Services or ICT Products,” which requires a documented risk-management process for acquiring ICT services or products “critical for the relevant entities’ security of network and information systems,” including security requirements and validation methods, throughout the supplier relationship [3]. A WAF is exactly that kind of critical security component — which means choosing and configuring one isn’t only a technical decision. Section 6.1 expects it to be a documented one.

Zero Trust / Access → Article 21(2)(i)

Cloudflare Access verifies identity and device posture on every request and enforces least-privilege, context-based policies instead of a flat VPN tunnel [5]. That maps to Article 21(2)(i), “human resources security, access control policies and asset management” [1] — access control is named explicitly in the letter.

The Directive’s Recital 89 adds weight here without creating a binding obligation: it lists “zero-trust principles” by name as one of the “basic cyber hygiene practices” entities should adopt [2]. Recitals signal intent rather than create law, but this is a rare case where a specific product category appears almost verbatim in the Directive’s own preamble. Where Access sessions are also gated by multi-factor authentication, that additionally evidences Article 21(2)(j) — a separate letter from access control, and worth documenting as such rather than folding into the same policy.

Email Security → Article 21(2)(g)

Cloudflare Email Security screens inbound mail for phishing, business email compromise, and malware using behavioural analysis and threat intelligence, deployable inline or via API without an MX record change [6]. Article 21(2)(g) covers “basic cyber hygiene practices and cybersecurity training” [1], and Recital 89 names “phishing or social engineering techniques” explicitly as the threat that staff training under this letter should address [2].

That pairing is worth being precise about: the tool blocks the phishing email. It doesn’t run the training program (g) also requires. An email security gateway with a vendor-reported 99.99% detection rate for sophisticated threats [6] still leaves the human-factor half of (g) — the actual staff awareness training — as something your organisation has to run, document, and refresh on its own schedule.

R2 + Access → Article 21(2)(c)

R2 is Cloudflare’s S3-compatible object storage, built around zero egress fees and automatic replication [7]. As an off-platform backup destination, it’s a reasonable fit for Article 21(2)(c), “business continuity, such as backup management and disaster recovery” [1] — geographically separating backup storage from your production environment is exactly what backup management is meant to achieve.

Access plays a smaller, secondary role here: if a disaster-recovery plan depends on staff reaching admin consoles or restore tooling remotely during an incident, Access’s identity-verified remote connectivity supports that continuity workflow. Its primary Article 21(2) mapping still sits under access control (i), not (c). Neither product writes the disaster-recovery plan, tests it, or sets your recovery time objective.

The Full Article 21(2) Scorecard: What Cloudflare Touches and What It Doesn’t

Line up all ten Article 21(2) categories against Cloudflare’s product suite and the pattern is stark: four letters get direct or partial technical coverage, and six are untouched entirely — because they’re governance documents, not infrastructure.

Letter	Requirement	Cloudflare coverage	What’s still needed
(a)	Risk analysis and information system security policies	None	Written risk-management policy and risk register
(b)	Incident handling	None	Documented incident handling policy, roles, Article 23 notification workflow
(c)	Business continuity	Partial — R2 (backup), Access (secondary)	Business impact analysis, continuity plan, DR test schedule, RTO/RPO
(d)	Supply chain security	Partial — vendor certification reports	Documented vendor risk assessment naming Cloudflare, contract clauses
(e)	Network/system security (acquisition, development, maintenance)	Direct — Magic Transit, WAF	Network architecture documentation, vulnerability handling procedure
(f)	Effectiveness assessment	None	Policy for testing and reviewing security measures
(g)	Basic cyber hygiene and training	Partial — Email Security	Staff training program, phishing-awareness records
(h)	Cryptography and encryption	None	Written encryption policy covering data at rest and in transit
(i)	Access control	Direct — Access / Zero Trust	HR security procedures, asset register
(j)	MFA and secure communications	Partial — where Access enforces MFA	Documented MFA policy, secure emergency communications plan

Four direct or partial matches out of ten is a genuinely useful starting point — most organisations don’t get that much technical coverage from a single vendor relationship. It’s also, by definition, not compliance. The six untouched letters are documents: policies, registers, plans, and assessment procedures that describe what you did and why, which is what an auditor actually reads.

The Supply-Chain Question Cloudflare’s Own Materials Don’t Answer

Article 21(2)(d) requires entities to address supply chain security, “including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers” [1]. Cloudflare is a direct supplier for any organisation routing production traffic through it — which means Cloudflare itself needs to appear in your Article 21(2)(d) documentation, not just in your firewall rules.

Cloudflare’s own compliance materials point to self-service ISO 27001, ISO 27701, and SOC 2 Type II reports as “foundational evidence” for that supply-chain requirement, plus a Data Localization Suite aimed at managing “the legal and geographical risks associated with data processing and service providers” [8]. Those are real, usable artefacts for a supplier risk file.

What they don’t resolve is a question independent risk analysis keeps raising: Cloudflare is a US-headquartered company, subject to the US CLOUD Act and FISA 702, both of which can compel access to data “even if the data is physically located within the EU” [9] — a tension with the data-sovereignty expectations that followed the Schrems II ruling. Cloudflare’s own trust-hub page doesn’t raise or disclaim this point [8]; it’s independent commentary, not vendor marketing, that flags it [9].

None of this means avoiding Cloudflare. It means your Article 21(2)(d) supplier file for Cloudflare should address the jurisdiction question explicitly — a documented risk acceptance, or a Data Localization Suite configuration, rather than silence on the point. An auditor who has read the same commentary this article cites will ask; a supplier file with no answer reads worse than one with a hedged, honest one.

What Your Auditor Will Actually Ask For

When a vendor like Cloudflare sits inside your network path, expect a competent authority or internal auditor to ask for four specific artefacts, not a product screenshot:

• A vendor security assessment for Cloudflare specifically, referencing the ISO 27001 / SOC 2 reports it makes available [8] — not a generic “we use a CDN” line
• A written risk acceptance or mitigation note addressing the CLOUD Act / jurisdiction question for any regulated or personal data that transits Cloudflare’s network
• A network architecture diagram showing exactly where Magic Transit, the WAF, and Access sit relative to your origin infrastructure — evidence for the CIR 6.7 documentation requirement [3]
• A named point of contact and escalation path for coordinating incident response with Cloudflare during a live event, feeding into your Article 23 notification clock

None of these are things Cloudflare generates automatically. They’re organisational documentation — the same six-letter gap identified in the scorecard above, made concrete for one specific vendor relationship.

Frequently Asked Questions

Does using Cloudflare make us NIS2 compliant?

No. It provides technical coverage for at most four of the ten Article 21(2) categories, direct or partial, and none of the governance documentation Article 21 requires — risk analysis, incident handling policy, effectiveness assessment, or your own supplier risk file.

Is Cloudflare itself directly regulated by NIS2?

As a CDN and DNS provider, Cloudflare falls within the roughly ten digital-infrastructure categories CIR 2024/2690 binds directly [3]. That’s separate from whether your organisation, as a customer, is bound by the same CIR provisions — most customers aren’t, and the CIR Annex applies to them only as an interpretive benchmark, not a legal requirement.

Do we need a written agreement addressing NIS2 with Cloudflare specifically?

NIS2 doesn’t mandate a named Cloudflare clause. Article 21(2)(d)’s supplier-relationship requirement, combined with the jurisdiction question above, is best evidenced with a documented risk assessment that names Cloudflare specifically, rather than a general cloud-vendor policy that never mentions it.

Key Takeaways

Five Cloudflare products, mapped honestly, cover four Article 21(2) letters directly or partially. That’s a real head start on the technical side of compliance, and a genuinely small fraction of what Article 21 actually requires. The other six letters, the supply-chain documentation for Cloudflare itself, and the jurisdiction question its own materials leave open are organisational work no CDN, WAF, or Zero Trust product performs for you. Start with the four artefacts your auditor will ask for; the scorecard above shows exactly which gaps to close next.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• “NIS2 Directive Article 21” — nis-2-directive.com
• “NIS2 Directive Recital 89 (Preamble 81-90)” — nis-2-directive.com
• “CIR 2024/2690 Annex — Technical and Methodological Requirements” — advisera.com
• “Magic Transit” — cloudflare.com
• “Access | Zero Trust Network Access” — cloudflare.com
• “Email Security” — cloudflare.com
• “Cloudflare R2” — cloudflare.com
• “NIS 2 | Compliance Resources” — Cloudflare Trust Hub, cloudflare.com
• “Cloudflare and NIS2: Risks the Public Sector Cannot Afford to Ignore” — excedo.se