NIS2 Digital Infrastructure: CIR 2024/2690 Adds 150+ Binding Controls for DNS, TLD, and CDN Operators

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.

What Is the Digital Infrastructure Sector Under NIS2?

NIS2 Annex I — the directive’s list of sectors of high criticality — places digital infrastructure in Point 8. The entities it covers are not homogeneous: a global hyperscaler cloud provider and a regional internet exchange point (IXP) both appear in the same annex, but their compliance obligations under the full NIS2 framework diverge significantly once you factor in Commission Implementing Regulation (EU) 2024/2690.

Annex I Point 8 identifies the following entity types under digital infrastructure:

• Internet exchange point (IXP) operators
• DNS service providers (excluding root zone name server operators)
• Top-level domain (TLD) name registries
• Cloud computing service providers
• Data centre service providers
• Content delivery network (CDN) providers
• Trust service providers (qualified under Regulation (EU) No 910/2014)
• Providers of public electronic communications networks
• Providers of publicly available electronic communications services

For most NIS2 sectors, the threshold for coverage is medium enterprise size (50+ employees or €10 million annual turnover). Digital infrastructure is partly different. DNS service providers, TLD name registries, and trust service providers qualified under Regulation 910/2014 are classified as Essential entities regardless of their size [7]. A three-person DNS provider resolving millions of queries per day carries the same Article 21 obligations as a hyperscaler.

Jurisdiction is determined by the main establishment principle: the member state in which an operator has its principal establishment supervises it for NIS2 purposes across the entire EU. For digital infrastructure operators serving multiple jurisdictions, this creates a single NCA relationship for compliance, registration, and incident reporting [4].

The following table maps each Annex I entity type to its CIR 2024/2690 scope status and entity classification:

Entity Type	NIS2 Annex I	CIR 2024/2690	Classification
DNS service providers	Yes	In scope	Essential (regardless of size)
TLD name registries	Yes	In scope	Essential (regardless of size)
Cloud computing providers	Yes	In scope	Essential (medium/large)
Data centre service providers	Yes	In scope	Essential (medium/large)
CDN providers	Yes	In scope	Essential (medium/large)
Internet exchange points (IXPs)	Yes	Not in scope	Essential (medium/large)
Trust service providers	Yes	In scope	Essential (regardless of size)

Why CIR 2024/2690 Changes Everything — And Which Entities It Covers

Article 21 of NIS2 sets out ten cybersecurity risk-management measures that all essential and important entities must implement [1]. The directive mandates an all-hazards approach — risk analysis policies, incident handling, business continuity, supply chain security, secure development practices, effectiveness assessment, cyber hygiene, cryptography, personnel security and access control, and multi-factor authentication.

What Article 21 does not do is specify how to implement those measures. The directive deliberately leaves technical detail to implementing acts. Commission Implementing Regulation (EU) 2024/2690 — CIR 2024/2690 — is that implementing act. Published on 17 October 2024 and entering into force on 7 November 2024, it translates Article 21’s principles into more than 150 specific, binding cybersecurity controls organised across 13 Annex sections [3][6].

Because CIR 2024/2690 is a Regulation rather than a Directive, it does not require national transposition. It applies directly and in full in every EU member state from the date it entered into force [3]. The ENISA Technical Implementation Guidance, published on 26 June 2025, provides non-binding practical advice and standard mappings (ISO 27001:2022, ISO 22301, NIST) for implementing the CIR’s controls — useful context, but the controls themselves are already obligatory [5].

The critical scope distinction: CIR 2024/2690 applies to a defined subset of NIS2 entities. The regulation explicitly covers DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, CDN providers, managed service providers (MSPs), managed security service providers (MSSPs), providers of online marketplaces, online search engines, social networking platforms, and trust service providers [3].

IXPs are not in this list. Internet exchange points appear in NIS2 Annex I and are supervised by national competent authorities — but they fall outside CIR 2024/2690’s scope. An IXP operator must comply with all ten Article 21(2)(a)–(j) measures using its own technical judgement. It faces no prescriptive 150+ control Annex. This is both an operational advantage (more flexibility in implementation) and a compliance risk: the IXP must make defensible technical choices without the prescriptive guidance the CIR gives to every other digital infrastructure operator in scope [4].

The 13 CIR Annex Sections: What Each Requires

CIR 2024/2690 is structured as a main body (Articles 1–16 covering scope, definitions, significant incident criteria, and enforcement) and a detailed Annex titled “Technical and methodological requirements.” The Annex is the operational core. Its 13 sections map against Article 21(2)’s ten measures [2][6]:

1. Policy on the security of network and information systems — maps to Article 21(2)(a). Formal policy covering governance objectives, scope, roles, and responsibilities for cybersecurity risk management.
2. Risk management policy — also Article 21(2)(a). Systematic identification, analysis, evaluation, and treatment of risks to network and information systems. See the risk assessment framework for implementation guidance.
3. Incident handling — Article 21(2)(b). Detection, classification, escalation, and response procedures, with explicit linkage to the Article 23 notification timeline.
4. Business continuity and crisis management — Article 21(2)(c). Backup management, disaster recovery planning with tested recovery time objectives, and crisis governance structures.
5. Supply chain security — Article 21(2)(d). Documented security requirements for direct suppliers, contractual security clauses, supplier self-assessment procedures, and ongoing monitoring.
6. Security in network and information systems acquisition, development and maintenance — Article 21(2)(e). Secure procurement criteria, patch management, vulnerability handling, and secure development lifecycle. This section also contains the DNS-specific provision discussed below.
7. Policies and procedures to assess the effectiveness of cybersecurity risk-management measures — Article 21(2)(f). Monitoring and measurement frameworks, internal audit cadence, and management review cycles.

The remaining six sections (8–13) address the areas mapped to Article 21(2)(g) through (j): cyber hygiene practices and training; policies and procedures for the use of cryptography and encryption; human resources security; access control and identity management; asset management; and physical and environmental security. Together, all 13 sections produce a compliance programme that covers every Article 21 obligation at the specificity required for a competent authority audit.

One important operational note: the CIR does not scale its requirements to entity size. A small DNS provider with five employees faces the same 13-section Annex as a hyperscaler cloud platform. The “appropriate and proportionate” language of Article 21(1) provides some calibration on how controls are sized, but the requirement to maintain documented policies, procedures, and evidence across all 13 sections is uniform [1][6].

DNS Security and DNSSEC: What the CIR Annex Requires

The section of CIR 2024/2690 most operationally relevant to DNS service providers and TLD registries is Annex Section 6 — security in network and information systems acquisition, development and maintenance. Within its network security controls subsection, the CIR Annex requires operators to “apply best practices for the security of the DNS, and for Internet routing security and routing hygiene” [2].

This is not a recommendation. It is a binding control within a directly applicable EU regulation that has been in force since November 2024. For DNS service providers and TLD registries in CIR scope, implementing DNS security best practices — including DNSSEC — is a compliance obligation, not a voluntary measure.

DNSSEC (DNS Security Extensions) cryptographically signs DNS resource records, allowing resolvers to verify that a response is authentic and has not been tampered with in transit. Without DNSSEC, a DNS resolver cannot distinguish a legitimate response from a cache-poisoned injection. DNS cache poisoning — the attack DNSSEC prevents — requires no access to the target’s own infrastructure: an attacker who can inject a forged DNS response can redirect users from legitimate services to malicious ones without any visible warning to the end user.

For a TLD registry, DNSSEC implementation means signing the top-level domain zone so that operators of second-level domains under that TLD can chain their DNSSEC signatures back to a trusted root. A TLD that does not support DNSSEC breaks the chain of trust for all domains registered beneath it, exposing every registrant to DNS spoofing risk.

The same CIR provision extends to Internet routing security and routing hygiene — specifically, BGP (Border Gateway Protocol) security. BGP route hijacking, where an attacker announces false routing information to redirect traffic, is the routing-layer analogue of DNS cache poisoning. Route Origin Authorisation (ROA) records and RPKI (Resource Public Key Infrastructure) are the current best-practice mechanisms. DNS providers and TLD registries operating their own AS numbers are expected to implement them [2].

DNS providers and TLD registries should document their DNSSEC implementation status, zone signing procedures, key rollover processes, and BGP/RPKI configuration as evidence for NCA review. These are not items where “we plan to implement” is an acceptable response after CIR entered into force.

Cryptographic controls more broadly — covering data confidentiality, authenticity, and integrity across all systems — are addressed in a separate Annex section mapping to Article 21(2)(h): policies and procedures for cryptography and, where appropriate, encryption. This covers algorithm selection, key management, and cryptographic practice review, and applies to all entities in CIR scope including cloud providers, CDNs, and data centres.

Entity-Specific Compliance Focus by Infrastructure Type

While the CIR Annex applies uniformly to all entities in its scope, the practical compliance emphasis differs by infrastructure type. Here is where each entity type faces its most acute obligations.

DNS service providers — Annex Section 6 DNS security best practices (DNSSEC, BGP routing hygiene) are the sector-specific control that most general compliance programmes miss. Beyond Section 6, DNS providers must also address Section 3 (incident handling) with particular care: a DNS service disruption affecting query resolution at scale is almost certainly a significant CIR incident. Given that recursive resolvers process billions of queries, even short outages can breach significance thresholds quickly [6].

TLD name registries — Essential entities regardless of size, TLD registries carry the same scope of obligation as the largest cloud providers. The supply chain dimension (Section 5) is high-stakes: registries depend on a chain of registrars, resellers, and registry service operators, and vulnerabilities in that chain fall within Article 21(2)(d) scope. Contractual security clauses with all direct suppliers are not optional [1].

Cloud computing service providers — CIR Sections 5 (supply chain) and 9 (cryptography) are where most compliance effort lands. Cloud providers are also supply chain entities for their own customers: a hyperscaler’s CIR compliance directly affects the supply chain security obligations of every other essential or important entity using its infrastructure.

Data centre service providers — Annex Section 13 (physical and environmental security) is the natural audit focus: physical access control, environmental monitoring (power, cooling, fire suppression), and CCTV audit trails. Section 4 (business continuity) is equally critical: a data centre resilience plan lacking specific tested recovery time and recovery point objectives will not satisfy CIR requirements.

CDN providers — content delivery networks sit at the intersection of supply chain and network security. A CDN is simultaneously a customer of its upstream network providers and a supplier of delivery infrastructure to potentially hundreds of downstream customers. Both relationships require governance under Section 5. CDN operators handling significant European web traffic volumes should examine their significant incident thresholds carefully: a DDoS attack degrading service delivery to a meaningful share of EU internet users may trigger Article 23 reporting obligations [6].

IXPs — because CIR 2024/2690 does not apply, IXP operators must build their Article 21 compliance independently. They must implement all ten measures under Article 21(2)(a)–(j), document that implementation, and demonstrate proportionality to their NCA without the CIR’s specific control catalogue as a guide. Reference frameworks — ISO 27001, the ENISA Technical Implementation Guidance — become the primary benchmarks for an IXP building a defensible programme [5].

Incident Reporting: Three-Phase Obligations Under Article 23

NIS2 Article 23 establishes a three-phase incident notification process for all essential and important entities. For digital infrastructure operators, CIR 2024/2690 supplements this with specific significant incident thresholds [6].

The three phases are:

• Early warning (within 24 hours of detection) — notify the NCA or CSIRT that a significant incident has occurred or is suspected. No detailed technical analysis is required at this stage; the obligation is to trigger the regulatory relationship promptly.
• Incident notification (within 72 hours of detection) — provide an initial assessment including the incident’s nature, severity, and impact, and whether it is suspected to involve unlawful or malicious activity. Provide updated information if the picture has changed since the early warning.
• Final report (within one month of incident notification) — a detailed account of the incident, its root cause, mitigating measures applied, and cross-border impact where applicable [7].

CIR 2024/2690’s significant incident thresholds specify that an incident is significant when it causes financial loss exceeding EUR 500,000 or 5% of annual global turnover (whichever is lower), results in unauthorised network access causing severe operational disruption, involves trade secret exfiltration, or causes health or safety damage [6]. For a DNS provider whose service underpins banking or healthcare infrastructure, a disruption measured in minutes — not hours — can cross these thresholds.

Building incident response documentation that maps detection time to notification deadlines — and pre-populates the early warning and 72-hour forms — is a practical prerequisite for Article 23 compliance, not a post-incident exercise.

Penalties and Management Accountability

Essential entities in the digital infrastructure sector face administrative fines of up to EUR 10 million or 2% of total worldwide annual turnover, whichever is higher. Important entities face up to EUR 7 million or 1.4% of worldwide annual turnover [7].

The penalty asymmetry for small Essential entities is real and significant. A DNS provider with EUR 2 million in annual turnover faces a maximum fine of EUR 10 million — five times its revenue. The directive’s drafters did not treat this as an anomaly: it reflects the systemic risk that even a small DNS provider can pose to EU internet infrastructure when something goes wrong.

NIS2 also extends personal liability to management. Competent authorities can impose temporary prohibitions on natural persons holding management responsibility in essential entities where those individuals are found to have failed their cybersecurity oversight duties. This provision has been incorporated by several member states — including Germany — directly into their transposition legislation.

The practical consequence: a board resolution approving the entity’s cybersecurity risk-management framework, and documented evidence that management has reviewed it, is not optional. Management bodies are legally required to approve cybersecurity risk-management measures and to undertake training to maintain adequate knowledge of cybersecurity risks and risk-management practices. This governance obligation sits alongside — and is a prerequisite for — Article 21’s technical requirements.

Entity Classification	Max Fine	Turnover Threshold
Essential (incl. DNS, TLD, trust services)	EUR 10,000,000	2% of global annual turnover (whichever higher)
Important	EUR 7,000,000	1.4% of global annual turnover (whichever higher)

Your Compliance Timeline: The June 30, 2026 First Audit Horizon

CIR 2024/2690 entered into force on 7 November 2024. Entities in its scope have been subject to its obligations since that date [3]. The practical enforcement horizon is the first compliance audit window — the point by which digital infrastructure operators are expected to demonstrate an operative compliance cycle to their national competent authority.

Regulatory analysis of member state enforcement frameworks indicates that June 30, 2026 marks the end of the initial audit window in many EU jurisdictions. Operators who begin their compliance programme after January 2026 face a structural problem: the 13 CIR Annex sections require not just policies but evidence that those policies have been implemented, tested, and reviewed. A risk assessment that has not completed a review cycle, a business continuity plan that has not been tested, or a supply chain register with no documented supplier assessments will not satisfy a competent authority examining whether controls are operative rather than merely documented.

A realistic sequencing for operators not yet compliant:

1. Gap assessment (Q3 2025 or earlier) — map current controls against all 13 CIR Annex sections. For IXPs not in CIR scope, map against Article 21(2)(a)–(j). Identify where policies exist, where they need to be created, and where implemented controls lag behind policy.
2. Policy and procedure development (Q3–Q4 2025) — produce or update the core documents: IS security policy, risk assessment methodology and register, incident handling procedure with pre-populated Article 23 notification forms, business continuity plan with tested RTO/RPO, and supply chain security clauses for all direct suppliers.
3. Implementation and evidence generation (Q4 2025–Q1 2026) — deploy controls, complete the initial training cycle, conduct the first risk assessment, and run a tabletop incident exercise. This evidence base is what auditors examine.
4. Internal audit and management review (Q1–Q2 2026) — complete a full internal audit across the 13 Annex sections, produce a management review report, and document corrective actions. This demonstrates the programme is an operative management system, not a document exercise.
5. NCA submission / audit readiness (by June 30, 2026) — have the complete evidence pack available for supervisory review. In some member states, registration with the NCA may be a prerequisite to demonstrating compliance.

The ENISA Technical Implementation Guidance (published June 26, 2025) is the most detailed non-binding reference available for mapping CIR controls to established standards. For digital infrastructure operators building or validating their compliance programmes, it is the single most useful implementation resource alongside the regulation itself [5].

Key Takeaways for Digital Infrastructure Operators

• CIR 2024/2690 is a directly applicable EU Regulation in force since 7 November 2024. DNS, TLD, cloud, data centre, CDN, MSP, MSSP, and trust service providers are bound now — no national transposition is pending.
• IXPs are in NIS2 Annex I but outside CIR 2024/2690’s scope. They must implement Article 21(2)(a)–(j) without the prescriptive CIR Annex as a guide.
• DNS service providers and TLD registries are Essential entities regardless of size. The EUR 10 million penalty ceiling applies even to micro-enterprises.
• CIR Annex Section 6 includes a binding requirement to apply DNS security best practices — including DNSSEC and BGP routing hygiene — for DNS providers and TLD registries. This is an obligation in force since November 2024.
• The Article 23 notification timeline — 24-hour early warning, 72-hour notification, 30-day final report — applies to all significant incidents. Pre-built notification forms are a compliance prerequisite, not a convenience.
• June 30, 2026 is the practical first-audit horizon in many member states. Operators who have not completed a gap assessment have fewer than twelve months to generate a full evidence base across 13 Annex sections.

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

1. Directive (EU) 2022/2555 — Article 21: nis-2-directive.com
2. CIR 2024/2690 Annex — Technical and Methodological Requirements: Advisera formatted text
3. European Commission — CIR 2024/2690 overview: digital-strategy.ec.europa.eu
4. Finnish NCSC (NCSC-FI) — Digital infrastructure supervision: kyberturvallisuuskeskus.fi
5. ENISA — NIS2 Technical Implementation Guidance (26 June 2025): enisa.europa.eu
6. Hunton Andrews Kurth — CIR 2024/2690 entry into force analysis: hunton.com
7. Legiscope — NIS2 Compliance Guide 2026: legiscope.com
8. Advisera — CIR 2024/2690 for digital infrastructure: advisera.com