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
• 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 under Recommendation 2003/361/EC (50 or more employees, or annual turnover and balance sheet total both above €10 million) [9]. Digital infrastructure is partly different. Providers of public electronic communications networks and services, trust service providers, TLD name registries and DNS service providers are in scope regardless of size (Article 2(2)), and qualified trust service providers, TLD name registries and DNS service providers are classified as Essential entities regardless of their size (Article 3(1)(b)) [1]. 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: under Article 26(1)(b), DNS service providers, TLD name registries, cloud computing, data centre and CDN providers fall under the jurisdiction of the member state where they have their main establishment in the Union, i.e. where cybersecurity risk-management decisions are predominantly taken. For these operators serving multiple jurisdictions, this creates a single NCA relationship for compliance, registration, and incident reporting. Providers of public electronic communications networks and services are the exception: they fall under the jurisdiction of each member state in which they provide their services, while IXPs and trust service providers follow the general rule of the member state where they are established [1].

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 (large); Important (medium)
Data centre service providers	Yes	In scope	Essential (large); Important (medium)
CDN providers	Yes	In scope	Essential (large); Important (medium)
Internet exchange points (IXPs)	Yes	Not in scope	Essential (large); Important (medium)
Trust service providers	Yes	In scope	Qualified: Essential (regardless of size); non-qualified: Essential (large), otherwise Important
Public electronic communications networks and services	Yes	Not in scope	Essential (medium/large); Important (small/micro)

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. Adopted on 17 October 2024, published in the Official Journal on 18 October 2024 and entering into force on the twentieth day after publication (7 November 2024), it translates Article 21’s principles into an Annex of 13 sections containing more than 150 numbered requirement points, many with further lettered sub-requirements [2][6].

Because CIR 2024/2690 is a Regulation rather than a Directive, it does not require national transposition. Article 16 makes it binding in its entirety and directly applicable in all member states [2]. The ENISA Technical Implementation Guidance, published on 26 June 2025, provides non-binding practical advice, examples of evidence and mappings of the security requirements 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 (Article 1) [2].

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. The same applies to providers of public electronic communications networks and services: they are in Annex I Point 8 but are not named in Article 1 of the CIR [1][2]. An IXP operator must comply with all ten Article 21(2)(a)–(j) measures using its own technical judgement. It faces no prescriptive CIR 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 DNS, TLD, cloud, data centre, CDN and trust service operators [4].

The 13 CIR Annex Sections: What Each Requires

CIR 2024/2690 is structured as a main body (Articles 1–16 covering subject matter, the link to the Annex, general and entity-specific significant incident criteria, the repeal of Implementing Regulation 2018/151, and entry into force) 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), with Section 13 also referring to points (c) and (e): 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: a small DNS provider with five employees faces the same 13-section Annex as a hyperscaler cloud platform. Article 2(2) of the CIR lets entities take due account of their risk exposure, size and the likelihood and severity of incidents when applying the requirements, and where an Annex requirement applies only “where appropriate”, “where applicable” or “to the extent feasible”, an entity that decides not to apply it must document its reasoning in a comprehensible manner [2].

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 subsection (point 6.7.2(l)), the CIR Annex requires relevant entities to “apply best practices for the security of the DNS, and for Internet routing security and routing hygiene of traffic originating from and destined to the network” [2].

This is not a recommendation. It is a binding requirement within a directly applicable EU regulation that has been in force since November 2024. The Annex does not name specific protocols such as DNSSEC or RPKI: recital 87 of the CIR notes that identifying the best available standards and deployment techniques for DNS security and routing hygiene entails specific challenges, and calls for a multi-stakeholder forum to identify them, without prejudice to the entities’ obligation to implement the Annex [2].

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 widely used mechanisms for this, and DNS providers and TLD registries operating their own AS numbers should document how they address routing security.

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: under Article 5 of the CIR, an incident is significant if a recursive or authoritative resolution service is completely unavailable for more than 30 minutes, or if its average response time exceeds 10 seconds for more than one hour [2].

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 should examine their significant incident thresholds carefully: under Article 9 of the CIR, a CDN that is completely unavailable for more than 30 minutes, or whose availability is limited for more than 5% of its EU users or more than 1 million EU users (whichever is smaller) for more than one hour, triggers Article 23 reporting obligations [2].

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 becoming aware) — 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 becoming aware; 24 hours for trust service providers where trust services are affected) — 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 [1].

Under Article 3(1) of CIR 2024/2690, an incident is significant when it has caused or is capable of causing direct financial loss exceeding EUR 500,000 or 5% of the entity’s total annual turnover in the preceding financial year (whichever is lower), the exfiltration of trade secrets, the death of a natural person or considerable damage to a person’s health; when a successful, suspectedly malicious and unauthorised access capable of causing severe operational disruption has occurred; or when it meets the entity-specific criteria in Articles 5 to 14 [2]. For a DNS provider, complete unavailability of a resolution service for more than 30 minutes is enough (Article 5).

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

For infringements of Article 21 or 23, essential entities in the digital infrastructure sector face administrative fines with a maximum of at least EUR 10 million or 2% of total worldwide annual turnover, whichever is higher. Important entities face a maximum of at least EUR 7 million or 1.4% of worldwide annual turnover (Article 34) [1].

The penalty asymmetry for small Essential entities is real and significant. A DNS provider with EUR 2 million in annual turnover faces a fine ceiling of at least 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. Under Article 32(5), where earlier enforcement measures against an essential entity have not worked, competent authorities can request that the relevant bodies or courts temporarily prohibit a person discharging managerial responsibilities at chief executive officer or legal representative level from exercising managerial functions in that entity [1].

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	Fine Ceiling (at least)	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: Where the Key Dates Stand

Status checked on 29 October 2026 against the EUR-Lex texts of Directive (EU) 2022/2555 and CIR 2024/2690.

CIR 2024/2690 entered into force on 7 November 2024 and has been directly applicable since then; Article 16 sets no transition period [2]. Under NIS2, member states had to establish their lists of essential and important entities by 17 April 2025 (Article 3(3)), and DNS service providers, TLD name registries, cloud, data centre and CDN providers had to submit their registration details to the competent authority by 17 January 2025 for the ENISA registry (Article 27(2)) [1]. Neither the directive nor the CIR sets a single EU-wide date for a first compliance audit: supervision, audits and their timing follow each member state’s transposition law and its competent authority, so check the current position with the NCA of the member state that has jurisdiction over you.

Operators who start their compliance programme late 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 — 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 — 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 — 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 — 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 — have the complete evidence pack available for supervisory review, and confirm that your registration details with the NCA are complete and up to date.

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 penalty ceiling of at least EUR 10 million applies even to micro-enterprises.
• CIR Annex point 6.7.2(l) includes a binding requirement to apply best practices for DNS security and for Internet routing security and routing hygiene. The CIR does not name specific protocols, but the obligation has been 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.
• There is no single EU-wide first-audit date; audit timing follows national transposition law and the competent authority. Operators who have not completed a gap assessment should start now, because the 13 Annex sections require evidence that controls operate, not just written policies.

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.

Related guides

• The CIR 2024/2690 Compliance Checklist: What DNS Operators, IXPs, Data Centres, and CDN Providers Must Document Before Their NIS2 Audit
• NIS2 Belgium Digital Infrastructure: Why BNIX, DNS Belgium, and Belnet Answer to BIPT, Not Just the CCB

Sources

1. Directive (EU) 2022/2555 (NIS2), official text: eur-lex.europa.eu
2. Commission Implementing Regulation (EU) 2024/2690, official text incl. Annex: eur-lex.europa.eu
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
9. Commission Recommendation 2003/361/EC — definition of micro, small and medium-sized enterprises: eur-lex.europa.eu