On 17 October 2024, the European Commission published the NIS 2 Implementing Regulation, which sets out the technical and methodological requirements for cybersecurity risk management measures that are mandatory for DNS service providers, TLD name registries and various other digital infrastructure actors, including cloud service providers, data centre service providers, content delivery network providers and others.
CENTR has previously provided feedback to the Commission on the draft Implementing Regulation, including asking for more clarity on conformity with the technical and methodological requirements as specified in the Implementing Regulation, and their interaction with the well established international security standards used across essential digital infrastructure, such as ccTLD registries. These include the ISO 27000 family of information security standards and the NIST Cybersecurity Framework that are the most widely adopted security standards across the CENTR community.
While the Implementing Regulation is already quite detailed, as evidenced by the extensive list of technical and methodological requirements listed in the Annex, we appreciate to find further guidance in the recently published document from ENISA, developed in collaboration with the European Commission and the NIS Cooperation Group.
One of the main contributions of ENISA’s guiding document is the mapping between the technical requirements referred to in the Annex of the Implementing Regulation and international standards and national cybersecurity management frameworks. This guidance is extremely relevant, primarily for the essential entities under the scope of the Implementing Regulation, such as the ccTLD registries, but also for the supervisory authorities in their enforcement capacity. It is concrete and tangible and places the requirements of NIS 2 in an international context, which is essential given the global and interdependent nature of the internet infrastructure.
The rest of the document, beyond the standards mapping, with additional guidance and examples of evidence, remains mostly at a high level and is not always filled with the most detail.
For example, the guidance on supply chain security refers to the unpublished work by the NIS Cooperation Group: the draft EU ICT Supply chain Toolbox from the Cooperation Group’s work stream on supply chain. It is unclear what the status of this document is and what kind of “best practice” operators are advised to follow. It is therefore advisable to update the ENISA document with the latest guidance from the NIS Cooperation Group as soon as it becomes available, and to provide concrete practices in each section.
This is also in line with ENISA’s objective to keep guidelines as a living document, subject to change and revision. Given the fast-paced nature of the cybersecurity landscape, this is a fundamental aspect of any guidance that may be issued in this area. Given ENISA’s technical advisory role within the EU cybersecurity policy, ENISA’s regular revision and updating the document with concrete guidance can be an important contribution to a high common level of cybersecurity preparedness in the EU.
Some of the advice in the same supply chain section can also be interpreted as paradoxical. While we appreciate the attention towards small entities with limited bargaining power, the advice to “negotiat[e] specific clauses such as the exit, pricing and service level agreements” with large service providers is precisely what small entities with limited bargaining power are unable to do. Negotiations between small entities and large service providers are in most cases not possible, because large providers have no economic incentive to alter the contracts for small entities.
Understandably, ENISA is not an advisory body for legal compliance. For these reasons, we expect the EU regulators to be mindful of this and to leverage all existing legislative initiatives in the area of cybersecurity. For example, the recently adopted Cyber Resilience Act (CRA) also has a significant supply chain security dimension.
Considering the overlap between these two legal instruments, especially in the area of digital infrastructure, we expect national and EU policymakers to ease the burden of supply chain security compliance under the NIS 2 Directive by reversing the burden of proof for supply chain security compliance on commercial manufacturers and major suppliers of products with digital elements used across the essential digital infrastructure. At present, it is not entirely clear how the CRA and NIS 2 Directive will interact in practice, given the widespread adoption of Free and Open Source Software (FOSS) in the Domain Name System (DNS).
There is also a risk of potential technical fragmentation as an unintended consequence of the CRA. In particular, the CRA calls for potentially mandatory cybersecurity certification under the EU Cybersecurity Act for products with critical dependency for essential entities under the NIS 2 Directive. This could lead to disruption of the global DNS, as European DNS service providers and ccTLD registries could be forced to use only EU certified products, rather than globally approved and standardised solutions. We hope that any development in this area will take due account of the special nature of the DNS as a global resource and the fact that burdensome certification procedures could themselves be the main disruptors of global supply chains for the essential internet infrastructure.
However, the compliance and vigorous enforcement of the CRA supply chain security will not be sufficient to reduce the compliance burden for all ICT services used by the essential entities, as it only applies to “products” and not to standalone ICT services. It is, therefore, still important to provide or jointly develop concrete guidance on supply chain security used within the essential infrastructure as a whole, taking into account its criticality for the global and interoperable internet.
ENISA’s draft is open for public consultation until 9 January, and we hope that once finalised, it can help operators and authorities to navigate a complex security compliance ecosystem.
