Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 is the directly applicable EU act that converts the high-level risk-management principles of NIS-2 Directive Article 21 into specific, enforceable technical and methodological requirements. Unlike the Directive itself, which required national transposition, this Regulation applies in every Member State without further legislative action, making it the most operationally consequential cybersecurity instrument the European Commission has issued for network and information systems operators to date.
Scope: Which Entities Are Directly Bound
The Implementing Regulation targets a precisely defined group of digital infrastructure and service providers, not the full universe of NIS-2 essential and important entities.
The Regulation applies to DNS service providers, top-level domain name registries, cloud computing service providers, data centre service providers, content delivery networks, managed service providers (MSPs), managed security service providers (MSSPs), and providers of online marketplaces, online search engines and social networking platforms. Each category carries a distinct control emphasis. Cloud computing service providers must demonstrate logical isolation between customer environments and produce evidence of cryptographic separation. Data centre operators are specifically required to address physical security perimeters, power resilience and cooling redundancy as part of their risk-management documentation. MSSPs face the most detailed supply-chain requirements because they introduce third-party tooling into customers’ environments and thereby extend the attack surface of multiple regulated entities simultaneously.
Entities that fall under NIS-2 Article 21 but outside the Implementing Regulation’s listed categories, such as energy distribution operators or hospital networks, remain subject to the Directive’s risk-management obligations directly. National competent authorities retain the power to extend the Regulation’s technical specificity to those sectors through supplementary implementing measures, and several Member States had signalled that intention before the Regulation’s applicability date.
ENISA’s 2025 Technical Guideline: From Regulation to Audit Checkpoints
ENISA published its NIS2 Technical Guideline in 2025 as a structured translation of the Implementing Regulation’s requirements into concrete configuration benchmarks and audit checkpoints that sovereign infrastructure operators can verify against.
The guideline organises controls around the ten security domains referenced in NIS-2 Article 21, including policies on risk analysis, incident handling, business continuity, supply-chain security, cryptography and human resources security. For each domain, ENISA specifies the artefacts an operator must produce, the technical parameters that constitute compliance (for example, minimum key lengths, maximum session token lifetimes, log retention periods) and the evidence that a national authority inspector should be able to examine on site.
For sovereign on-premises operators, the guideline is particularly useful because it acknowledges that compliance does not require a specific commercial product. An operator running an air-gapped or Swiss-hosted infrastructure can satisfy the cryptographic requirements by demonstrating that its chosen algorithms and key management processes meet the parameters, regardless of which vendor supplies the underlying stack. The ENISA guideline cross-references the European Cybersecurity Certification Framework (EUCC) where relevant, which means operators seeking formal certification can use the same documentation set for both the EUCC audit and a NIS-2 inspection.
Cryptographic Controls, Access Management and Supply-Chain Security
These three control domains receive the most detailed treatment in Implementing Regulation 2024/2690 and represent the areas where sovereign deployments have a structural advantage over public cloud configurations.
Cryptographic requirements
The Regulation requires entities to maintain a written cryptography and key management policy that covers algorithm selection, key lifecycle, and renewal procedures. It does not mandate specific algorithms by name in the legislative text, but it requires that choices be justified against the current state of the art, which in practice means alignment with ENISA’s own cryptographic recommendations and, increasingly, readiness for post-quantum migration. Sovereign operators running on-premises key management systems, such as hardware security modules under their own physical control, can produce key custody records that public cloud customers cannot replicate because hyperscaler key management services retain the ability to access keys under lawful process in their home jurisdiction.
Access management
Article 21 as elaborated by the Implementing Regulation requires privileged access management to be documented, with role-based access control policies covering both human administrators and non-human service accounts. Multi-factor authentication is required for all administrative access to network and information systems. For sovereign operators, this maps directly to directory service configurations: a Nextcloud-based workspace federated against an on-premises LDAP or LDAP-over-TLS directory, with hardware token MFA enforced at the gateway, satisfies these requirements in a way that is fully auditable without dependency on a foreign-controlled identity provider.
Supply-chain security
This is the domain where the Regulation introduces the most operationally significant new obligations. Every entity must assess the cybersecurity practices of its direct suppliers and service providers, maintain a register of critical third-party dependencies, and include contractual clauses that require suppliers to notify the entity of security incidents affecting the supply chain. The NIS Cooperation Group has stated: “Supply-chain security is no longer a theoretical risk category. The Implementing Regulation requires entities to evaluate and contractually bind every provider that touches their network or information systems.” For MSSPs, this creates a cascading obligation: they must both comply themselves and help their customers document the MSSP as a supplier in the customer’s own supply-chain register.
Compliance Documentation for National Authority Inspections
A compliance officer facing a national authority inspection under the Implementing Regulation must be able to produce a specific set of documents, not general security policies.
| Control domain | Required documentation | Evidence an inspector will examine |
|---|---|---|
| Risk management | Current risk register with residual risk acceptance sign-off | Date of last review, approver identity, link to asset inventory |
| Cryptography | Cryptography and key management policy | Algorithm list, key rotation logs, HSM custody records |
| Access control | Role-based access control matrix and MFA policy | User provisioning and deprovisioning logs, privileged session recordings |
| Supply chain | Supplier register with criticality ratings | Contractual clauses, most recent supplier security assessments |
| Incident handling | Incident response plan with tested escalation procedure | Tabletop exercise records, notification templates timed to 24-hour threshold |
| Business continuity | BCP and DRP with recovery time objectives | Last tested RTO/RPO results, backup verification logs |
IBM’s Cost of a Data Breach Report 2024 records the average cost of a data breach at USD 4.88 million, the highest in the report’s history, which provides a financial baseline for the cost-benefit calculation that should accompany a compliance officer’s risk acceptance decisions. ENISA’s NIS Investments Report 2024 found that approximately 40 percent of newly in-scope organisations lacked a documented risk assessment at the time of measurement, meaning a substantial share of regulated entities are already in a documentation gap. ENISA’s Threat Landscape 2024 recorded more than 1,000 significant incidents reported to national authorities across the EU in 2023, underscoring that inspection triggers are real and frequent.
Alignment and Divergence with DORA’s ICT Risk-Management Framework
Financial entities supervised under DORA Regulation (EU) 2022/2554 face a dual-regime question: which obligations overlap, and where must they produce separate evidence streams?
DORA functions as a lex specialis for financial entities. Where its ICT risk-management requirements are deemed equivalent to NIS-2’s, national competent authorities may accept DORA compliance as satisfying the corresponding NIS-2 obligation. In practice, the overlap is substantial for incident classification, business continuity, and third-party risk management. Both frameworks require documented ICT risk assessments, recovery capability testing, and contractual requirements on critical ICT third-party providers.
The divergence appears at the level of technical specificity. Implementing Regulation 2024/2690 specifies cryptographic policy requirements and supply-chain contractual clauses in more prescriptive terms than DORA’s ICT risk-management framework, which tends to operate at the level of principles and outcome descriptions. A bank that is DORA-compliant may therefore still need supplementary documentation to satisfy a NIS-2 inspection if the bank also operates infrastructure that falls within the Implementing Regulation’s scope categories, such as a private cloud platform offered to other financial institutions.
The January 2026 Amendment Proposals and Micro-Enterprise Scope
The Commission’s amendment proposals discussed in early 2026 do not remove the general size-based exemptions that allow micro and small enterprises to fall outside NIS-2 scope. Instead, they tighten the criticality-override pathway: a small entity providing a service for which no reasonable alternative exists within an EU Member State, such as a niche MSSP serving a single critical-infrastructure sector, can be designated in-scope by the relevant national authority regardless of headcount or annual turnover. The proposals also clarify the criteria national authorities must apply before making such a designation, requiring a documented assessment of market concentration and substitutability. For compliance officers at small operators serving essential-sector customers, this means that a sector-by-sector analysis of whether a criticality designation could apply is now a prudent precaution, even for entities that have previously assumed they were below the threshold.
FAQ
When did Commission Implementing Regulation 2024/2690 enter into force and when must entities comply?
The Regulation was published on 17 October 2024 and entered into force twenty days after publication in the Official Journal of the European Union. As a directly applicable EU regulation it required no national transposition. The applicability date aligns with the NIS-2 national implementation timeline, meaning entities within its scope were expected to have controls in place from that date onward.
Does the Implementing Regulation apply to every NIS-2 entity, or only to specific sectors?
It applies to a defined subset: DNS service providers, TLD registries, cloud computing service providers, data centre service providers, content delivery networks, MSPs, MSSPs and certain platform providers. Other NIS-2 essential and important entities remain subject to Article 21 directly but are not bound by the Implementing Regulation’s specific technical requirements unless national law extends its reach.
How does a compliance officer demonstrate conformance during a national authority inspection?
The officer must produce a current risk register, written policies on cryptographic controls and key management, a role-based access control matrix with MFA evidence, a supplier register with contractual security clauses, incident response plans with documented test dates, and business continuity evidence including tested recovery time objectives. ENISA’s 2025 technical guideline maps each of these artefacts to the corresponding Implementing Regulation provisions.
Are entities subject to both NIS-2 and DORA required to comply with both regimes separately?
DORA operates as a lex specialis, and national authorities may accept DORA compliance as satisfying equivalent NIS-2 obligations. However, the greater technical specificity of Implementing Regulation 2024/2690 around cryptographic policies and supply-chain contracts may require additional documentation even for fully DORA-compliant financial entities that also operate in-scope infrastructure categories.
Do the 2026 NIS-2 amendment proposals change the scope thresholds for micro and small enterprises?
The proposals do not remove existing size-based exemptions but tighten the criticality-override pathway. A small enterprise providing an irreplaceable service to essential-sector operators can be designated in-scope by national authorities, and the proposals set clearer criteria for when that designation is permissible. Small operators serving critical-infrastructure customers should conduct a documented substitutability analysis rather than assuming size exemptions apply automatically.