What Commission Implementing Regulation (EU) 2024/2690 actually requires for cryptography and crypto-agility under NIS2, who it applies to, and what it leaves to member states.
"NIS2 requires crypto-agility" gets repeated often enough that it is worth being precise about what that actually means, because two different EU documents share the NIS2 name, only one of them contains a specific, enforceable cryptography section, and it applies to a narrower set of organisations than most summaries suggest.
This guide separates the two, walks through exactly what the one with teeth (Commission Implementing Regulation (EU) 2024/2690) requires under its cryptography section, who it actually binds, and what everyone else covered by NIS2 more broadly should take from it anyway.
Directive (EU) 2022/2555, the NIS2 Directive itself, sets a high-level obligation: essential and important entities must take "appropriate and proportionate technical, operational and organisational measures," with Article 21(2)(h) naming "policies and procedures regarding the use of cryptography and, where appropriate, encryption" as one required measure category, among ten others. A directive does not apply directly; each EU member state transposes it into national law, and the specificity of what "appropriate" cryptography means varies by how each member state chose to implement it.
Commission Implementing Regulation (EU) 2024/2690 is different in kind, not just detail. It is a regulation, which applies directly across the EU without national transposition, and it exists specifically to remove that country-by-country ambiguity for a defined set of entity types. Its Annex, "Technical and methodological requirements," breaks the Directive's ten measure categories into thirteen detailed sections, more than 150 individual controls, including a dedicated Section 9 on cryptography.
When people say "NIS2 requires crypto-agility," they are almost always describing Section 9 of this implementing regulation. The distinction matters because the implementing regulation's specificity only applies if you fall inside its scope.
Commission Implementing Regulation (EU) 2024/2690 applies to eleven categories of entities, all drawn from NIS2's "digital infrastructure" and related annexes, not the full population of essential and important entities the Directive covers:
If you are, for example, a hospital, an energy operator, or a manufacturer covered by NIS2's broader essential/important entity categories, this specific implementing regulation does not bind you directly. Your obligations come from how your member state transposed Article 21 of the Directive, which may reference this same Annex as good practice, mirror it in national guidance, or specify something different entirely. Check your national transposing legislation rather than assuming the Annex below applies verbatim.
Section 9 of the Annex requires covered entities to have a documented policy and procedures on the use of cryptography, covering three things:
Algorithm and key-strength selection, appropriate to the classification of the data being protected, not a single organisation-wide standard applied uniformly regardless of sensitivity.
Key management, covering generation, storage, rotation and destruction, the same lifecycle framing DORA's own RTS uses (see our DORA encryption checklist for the financial-sector equivalent), though the two regulations are separate documents with separate scopes.
Periodic review against current best practice. This is the clause that actually operationalises crypto-agility: the policy cannot be a static document that names an algorithm once and never revisits it.
The Annex does not mandate specific algorithms or key lengths. That is deliberate: prescribing AES-256 or RSA-3072 in binding EU law would freeze the regulation to a specific point in cryptographic history. Instead, "state of the art" is the operative standard, interpreted in practice against current guidance from bodies like ENISA and standards bodies like ETSI and NIST, which is exactly why the review requirement exists: state of the art moves, so your policy has to move with it.
Strip away the marketing use of the term and Section 9's crypto-agility requirement reduces to three concrete obligations working together:
That third point is where policy meets engineering. A cryptography policy that says "we will update algorithms as needed" but sits on infrastructure that has no practical way to change a negotiated cipher without a multi-month project is not crypto-agile in any way an auditor should accept, regardless of what the document says. This is also where post-quantum migration connects directly to NIS2 compliance rather than being a separate, future-dated concern: ENISA's own coordinated roadmap sets the end of 2026 as the point by which EU member states should have cryptographic inventories in place, the same underlying capability Section 9 already requires.
Section 9 does not stand alone. Two other Annex sections are prerequisites for actually meeting it:
Section 2, risk management policy, is what drives the data classification that Section 9's algorithm selection criteria are supposed to be based on. Without a working classification scheme, "appropriate to the data" has nothing to be appropriate to.
Section 12, asset management, is what makes the cryptographic inventory itself possible. You cannot review algorithms and key strengths against current best practice if you do not have a current, accurate list of what cryptography is actually deployed across your estate, which in practice means a structured inventory format, not a spreadsheet someone updates when they remember to.
The Directive's Article 21(2)(h) obligation still applies to you if you are an essential or important entity under NIS2, just without this specific Annex's binding detail. In practice, three things are true regardless of which member state you are in:
The structured, current inventory Section 9 and Section 12 both assume is exactly what a CBOM (Cryptography Bill of Materials) is built to be: a CycloneDX-standardized, machine-readable record of every algorithm, certificate and key in scope. See our guide to generating a CBOM with DuoKey Cockpit for filesystem, source-code and domain scans that produce exactly that inventory, plus the get_qrs_score and get_vulnerable_assets MCP tools for ongoing review rather than a one-time snapshot.
For the "you have a practical way to actually change it" half of crypto-agility, our F5 BIG-IP and FortiGate PQC guides cover the execution side on two of the most common pieces of network edge infrastructure, including the agentic MCP tools that let a reviewed policy change turn into a deployed configuration change without a separate infrastructure project each time.
Q: Does NIS2 require post-quantum cryptography specifically?
Not by name. Section 9's requirement is "review against current best practice," and ENISA's coordinated PQC roadmap sets the end of 2026 as the point by which member states should have cryptographic inventories in place, which is effectively the same starting capability Section 9 already requires. Treat post-quantum readiness as the next iteration of a review process you are already obligated to have, not a separate, unrelated mandate.
Q: We're a hospital covered by NIS2. Does the implementing regulation's cryptography section apply to us?
Not directly. Commission Implementing Regulation (EU) 2024/2690 covers eleven specific entity categories (DNS providers, cloud, data centres, CDNs, managed service providers, and similar), which does not include healthcare providers. Your obligation comes from Article 21(2)(h) of the Directive as transposed by your member state; check your national law, though building the same underlying capability is a reasonable way to demonstrate compliance regardless.
Q: What's the difference between NIS2's cryptography requirement and DORA's?
They are separate regulations with separate scopes and separate documents containing the technical detail. NIS2's detail (for the eleven covered entity categories) lives in Commission Implementing Regulation 2024/2690's Annex Section 9. DORA's (for financial entities) lives in Commission Delegated Regulation 2024/1774's Articles 6 and 7. Both land on a similar shape (classification-driven algorithm selection, full key lifecycle management, periodic review), but they are not the same requirement and compliance with one does not automatically satisfy the other. See our DORA encryption checklist for the financial-sector version.
Q: Does Section 9 mandate specific algorithms like AES-256 or RSA-3072?
No. The Annex deliberately avoids naming specific algorithms in binding text, since that would freeze the regulation as cryptography evolves. It requires selection criteria aligned with current best practice instead, which in practice is interpreted against ENISA, ETSI and NIST guidance at the time of review.
Q: What does "periodic review" actually mean in practice? Is there a mandated frequency?
The Annex does not specify a fixed interval. In practice this means the review has to be frequent enough to catch a deprecated algorithm or standard before it becomes a live finding in an audit or incident, which argues for a defined cadence with a named owner rather than leaving "periodic" undefined and effectively reactive.
"NIS2 requires crypto-agility" is true for a specific, narrower set of organisations than the phrase usually implies, and even for those it does not just mean "support newer algorithms eventually." Section 9 of Commission Implementing Regulation (EU) 2024/2690 requires a working inventory, classification-driven selection criteria, full key lifecycle management, and a real, recurring review process, resting on the risk management and asset management sections around it. Build that capability once and it serves the same purpose whether the specific trigger is a deprecated TLS cipher today or a quantum-vulnerable algorithm on tomorrow's ENISA timeline.
Written by
Nagib Aouini
Related Resources
Tell us where control is difficult today. We will help you identify a practical next step.
