What NIS2 actually requires on cryptography: the Article 21 framework

NIS2 does not specify algorithms. It does not name RSA, ECDH, or ML-KEM anywhere in its text. What it does require, under Article 21(2)(h) [VERIFIED — EUR-Lex CELEX:32022L2555, Yuki consensus 2026-05], is that entities implement "the use of cryptography and, where appropriate, encryption" as part of their cybersecurity risk management measures. The "where appropriate" qualifier applies to encryption; it does not provide an escape route from the cryptography obligation itself. Appropriate cryptographic techniques are a baseline requirement, not conditional on operational preference.

The mechanism by which post-quantum cryptography enters the NIS2 compliance picture is Article 21(1), which requires that all security measures be "appropriate and proportionate to the risks posed" and take into account "the state of the art." This is a dynamic standard. It moves as the technical baseline shifts. NIST finalised FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024; FIPS 206 (FN-DSA) followed in October 2024. In November 2024, NIST IR 8547 formally opened the deprecation clock on RSA and ECDH/ECDSA for new deployments with a 2030 deadline. Those two events in 2024 moved the state-of-the-art marker. An organisation that has not assessed alignment with those published standards is operating against a baseline that is now behind the current state of the art, in the specific sense that NIS2 Article 21(1) uses the term.

For entities in digital infrastructure and certain ICT service provider categories, Commission Implementing Regulation (EU) 2024/2690, which entered into force 18 October 2024, provides specific technical requirements that go beyond the Directive's high-level text. These entities should check whether they fall within its scope; the requirements are enforceable at a level of specificity the Directive alone does not reach. For the foundational analysis of NIS2 and PQC obligations, see the companion piece on NIS2 post-quantum cryptography and cyber resilience. This article focuses on a different moment: your programme is already running, and you have been asked whether quantum risk is properly in scope.

UK readers: NIS Regulations 2018, not NIS2

NIS2 does not apply to UK organisations operating solely under UK law. The UK transposed NIS1 via the Network and Information Systems (NIS) Regulations 2018 (SI 2018/506). The UK Cyber Security and Resilience Bill was in consultation as of August 2025 [ASSUMED: verify enacted status before publication]. UK organisations with EU operations or that provide ICT services to NIS2-regulated entities may face contractual requirements driven by NIS2 but are not directly subject to the Directive. The rest of this article addresses EU-regulated essential and important entities.

Four gaps in a running NIS2 compliance programme

The gaps below are verifiable absences. Each is expressed as a diagnostic question. Run them against your current programme and see which returns a no.

Gap 1: Does your risk register include harvest-now-decrypt-later as a named threat? HNDL is a prospective threat: an adversary captures encrypted data today and decrypts it after a cryptographically relevant quantum computer becomes operational, expected in the 2033-2035 window based on current technical literature. Because the impact is not observable and the timeline is uncertain, most risk management frameworks built in 2024-2026 treat it as speculative and exclude it. This is a gap under NIS2 Article 21(1). The proportionality obligation requires the risk register to include threats that are currently identifiable, even when the impact is prospective. ENISA has listed HNDL as an emerging threat in its Threat Landscape reports for 2022, 2023, and 2024. Absence from the risk register is not a defensible position; it is an absence of assessment.

Gap 2: Does your cryptographic control review address algorithm lifecycle? Standard NIS2 cryptography reviews check for TLS version compliance, certificate validity, encryption-at-rest implementation, and key management procedures. These are hygiene checks against current vulnerabilities. They do not address whether the algorithms in use are on a deprecation path. NIST IR 8547 (November 2024) formally initiates deprecation of RSA, ECDH, ECDSA, DSA, and finite-field DH/DSA for new deployments by 2030, with full retirement by 2035. A NIS2 Article 21 cryptographic control review that does not ask "are our algorithms on the NIST deprecation schedule?" is incomplete against the state-of-the-art standard in Article 21(1). Passing a TLS version audit is necessary. It is not sufficient.

Gap 3: Does your supply chain questionnaire ask a PQC question? NIS2 Article 21(2)(d) [VERIFIED — EUR-Lex CELEX:32022L2555, Yuki consensus 2026-05] requires entities to address "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." In practice, NIS2 supply chain questionnaires focus on current security hygiene: penetration testing frequency, incident response procedures, access control policies. Whether an ICT supplier has a published PQC migration roadmap covering when it will support ML-KEM and ML-DSA on its cryptographic interfaces is not yet a standard question in most programmes. For entities with long-lived sensitive data, an ICT supplier without a PQC roadmap is a supply chain cryptographic risk item under Article 21(2)(d). The question belongs in your questionnaire before your next supplier review cycle.

Gap 4: Does your cyber resilience plan address data already generated? Many NIS2 cyber resilience plans schedule PQC migration as a future project, often 2027-2030. This addresses new traffic and future systems. It does not address the data already generated and stored since 2020 under RSA or ECDH encryption. For organisations in energy, health, or financial market infrastructure with long-lived data, adversaries may already have collected that data. Migrating future systems does not retroactively protect it. A plan that treats migration as an entirely future project has a gap on the HNDL risk for data already in adversarial hands. The Mosca inequality applied to data with a 2020 collection date and a 10-year confidentiality requirement makes this concrete: for that data, the HNDL risk window opened years ago.

What the NIST standards and the Q-Day timeline mean for your risk assessment

FIPS 203, 204, 205, and 206 are the first finalised post-quantum cryptographic standards suitable for general deployment. Published August through October 2024, they provide the technical basis for algorithm selection in any NIS2 entity updating its cryptographic controls. For NIS2 purposes, their publication is the event that marks the shift in the state-of-the-art baseline for key exchange and digital signatures. An organisation relying exclusively on RSA and ECDH/ECDSA for key exchange after August 2024 is not aligned with the current published standards. That is the claim. It is based on the same interpretive logic as GDPR Article 32, which uses identical "state of the art" language and has been interpreted by supervisory authorities to require alignment with current technical standards even when the regulation does not name specific algorithms.

For EU entities in digital infrastructure and trust services that are subject to the eIDAS regulation, ETSI TS 119 312 is the primary algorithm selection reference. That standard is being updated to incorporate PQC algorithm suites. ETSI TR 103 619 (2022) provides the quantum-safe cryptography background analysis. NIS2 entities in these sectors should track the ETSI TS 119 312 update as the EU-native algorithm guidance reference alongside the NIST standards.

The Q-Day timeline, the point at which a cryptographically relevant quantum computer first breaks RSA-2048 at useful scale, is most commonly placed in the 2033-2035 window based on the current fault-tolerant quantum computing literature. Fowler et al.'s 2012 surface code threshold analysis in Physical Review A provides the technical foundation for these estimates. The timeline carries significant uncertainty; this is not an engineering delivery date. For risk planning purposes, what matters is this: for an organisation holding data with a 10-year confidentiality requirement as of 2026, even a 20% probability of Q-Day before 2033 represents material exposure, because that data would still be under its confidentiality obligation when a cryptographically relevant quantum computer exists.

Four actions to close the gaps within the NIS2 framework

The four actions below correspond one-to-one with the four gaps above. For a readiness assessment instrument to benchmark your current position before beginning these actions, see the PQC compliance readiness gap analysis.

Action 1: Add HNDL to the risk register (Article 21(1)). Define the risk entry as: "Adversary capture of data encrypted with RSA/ECDH/ECDSA for decryption post-Q-Day, affecting data with confidentiality requirements extending beyond the Q-Day risk window." Assign likelihood and impact ratings based on your data classification (what do you hold with long confidentiality requirements?) and confidentiality lifetime (for how long must it remain confidential?). The Mosca inequality gives the quantitative framework for the likelihood assessment. The risk register entry is the document that makes HNDL visible to the board, the audit committee, and the competent authority. Without it, the risk does not formally exist in your governance structure, regardless of whether it exists in reality.

Action 2: Commission a cryptographic bill of materials (Articles 21(1) and 21(2)(h)). A CBOM maps every cryptographic asset in the ICT estate to the system and data it protects, along with the data classification and confidentiality lifetime. It converts the abstract HNDL risk into a prioritised, actionable list of systems requiring migration. NIST NCCoE SP 1800-38B provides the methodology; automated discovery tooling for TLS cipher suite scanning, HSM inventory export, and static code analysis for algorithm calls is available and should be used at enterprise scale. The CBOM is the prerequisite for every subsequent technical action in the programme.

Action 3: Deploy hybrid key exchange on priority data flows (Article 21(2)(h)). Hybrid TLS 1.3 key exchange combining X25519 with ML-KEM-768 is operationally deployable today. Cloudflare has operated this in production; Chrome and Firefox have done the same. IETF RFC 9496 (X-Wing hybrid KEM) and the IETF TLS hybrid design draft specify the implementation. For NIS2 essential entities with data classified as requiring confidentiality beyond 2030, deploying hybrid key exchange on the highest-risk flows is the minimum proportionate response to the HNDL risk under Article 21(1). It protects new traffic without requiring replacement of the underlying infrastructure and provides immediate measurable risk reduction.

Action 4: Update the supply chain questionnaire (Article 21(2)(d)). Add three questions to the annual supplier due diligence questionnaire: Does the supplier have a published PQC migration roadmap? By what date will its cryptographic interfaces support ML-KEM-768 and ML-DSA-65? What is the supplier's FIPS 140-3 validation status for post-quantum modules? Suppliers who cannot answer these questions represent a supply chain cryptographic risk item under Article 21(2)(d). Document the responses and non-responses in the ICT risk management framework. At next contract renewal, incorporate PQC roadmap commitments as a contractual requirement using the DORA RTS 2024/1773 contractual levers as the model for language, even where DORA does not directly apply.

Supervisory position: what proportionate action looks like under Articles 32 and 33

NIS2 essential entities are subject to proactive supervisory assessment under Article 32. Competent authorities can require on-site inspection, off-site audit, or targeted security audit at any time and without requiring prior evidence of non-compliance. An essential entity that has identified the quantum risk, documented it in the risk register, produced a CBOM, and is executing the four-action programme above is in a materially better position under an Article 32 assessment than one that has not assessed the risk at all. Article 21(1)'s proportionality principle accommodates phased migration; it does not accommodate the absence of risk identification.

NIS2 important entities face reactive supervision under Article 33, triggered by evidence of non-compliance or following an incident. For important entities with fewer resources, a minimum viable quantum security programme is proportionate: add HNDL to the risk register, commission a targeted CBOM on the highest-confidentiality data only, and issue PQC readiness questions to tier-1 ICT suppliers at next contract review. That programme is defensible under the proportionality framework in Article 21(1) for a medium-sized entity in a lower-criticality sector. It is not the full programme; it is the minimum that demonstrates the risk has been assessed.

Member state competent authorities have published national guidance that may impose requirements more specific than the Directive alone. Germany's BSI TR-02102-1 (Kryptographische Verfahren) [INFERRED — publication currency; verify latest version date at bsi.bund.de before publication] and France's ANSSI algorithmic recommendations [INFERRED — publication currency; verify latest version date at ssi.gouv.fr before publication] both address PQC migration, with some variation in parameter set preferences and transition timelines relative to NIST. NIS2 entities with cross-border operations should read their primary competent authority's guidance alongside ENISA's implementing material. BSI and ANSSI guidance generally aligns with NIST FIPS 203/204/205 but entities should verify national deviations before finalising their algorithm selection. The Netherlands NCSC-NL has also published relevant guidance in this space.