PQC StatusNIS2 Article 21(2)(h) requires essential and important entities to have policies and procedures regarding the use of cryptography and, where appropriate, encryption. The directive prescribes no template, no algorithm list and no deadline, so the quality of the document is yours to decide. This article gives a section by section outline you can copy, maps each section to the evidence an assessor will ask for, and shows exactly where the post-quantum transition provisions belong.
What Article 21(2)(h) requires, and what it does not
Directive (EU) 2022/2555 lists, in Article 21(2), the minimum cybersecurity risk management measures that in-scope entities must take. Point (h) is a single line: policies and procedures regarding the use of cryptography and, where appropriate, encryption. The text is on EUR-Lex (data.europa.eu/eli/dir/2022/2555/oj). Article 21(1) frames all of these measures as proportionate to the risk faced and informed by the state of the art.
Three consequences follow. First, the obligation is documentary and procedural: you need a written policy plus the procedures that apply it, not one specific cipher suite. Second, because the directive names no algorithm and no key length, the policy itself has to carry that list, and has to say how the list changes over time. Third, the phrase where appropriate means the decision not to encrypt something must be a documented, risk-based decision rather than an omission. Our reference page on NIS2 Article 21(2)(h) keeps the text and the related milestones together.
This article is information, not legal advice. Your national transposition law, your sector and your competent authority decide what is sufficient in practice.
The policy outline you can copy
The structure below is a working outline, not a legal requirement. It is ordered so that a reader who starts at section 1 can reach an approved algorithm decision by section 5, and so that each later section produces an artefact an assessor can inspect. A policy of eight to fifteen pages, with the technical parameters in an annex you can revise without re-approving the whole document, is usually enough.
| # | Section | What it states |
|---|---|---|
| 1 | Purpose and legal basis | That the document implements NIS2 Article 21(2)(h) as transposed nationally, and lists any other regime in scope (DORA, PCI DSS, Cyber Resilience Act, sector rules). |
| 2 | Scope | Entities, subsidiaries, environments (production, test, cloud, OT), data classes and third-party services covered. Named exclusions and why. |
| 3 | Roles and accountability | Who owns the policy, who approves algorithm changes, who approves exceptions, who holds key custodian roles, and the management body involvement NIS2 expects. |
| 4 | Risk and data classification | How confidentiality lifetime is assigned per data class. This is the input that decides which systems migrate first. |
| 5 | Approved algorithms and parameters | The allowed list with minimum parameters, by use case: data in transit, data at rest, signatures, hashing, key derivation, random number generation. |
| 6 | Deprecated and prohibited algorithms | What may no longer be deployed, what remains tolerated for legacy verification only, and the removal date for each. |
| 7 | Protocol and configuration baselines | Minimum TLS version, group and cipher suite order, SSH key agreement, VPN and database settings. One baseline per platform family. |
| 8 | Key management | Generation, distribution, storage, rotation, escrow, archival and destruction, with the hardware requirements for each key class. |
| 9 | Certificate management | Issuance authority, maximum validity, renewal automation, revocation, and a register of certificates with owners. |
| 10 | Cryptographic inventory | What is inventoried (algorithm, parameters, library and version, system, owner, data class), how it is collected and how often it is refreshed. |
| 11 | Cryptographic agility and post-quantum transition | The trigger conditions, the migration sequence and the target dates. See the next section. |
| 12 | Supplier and procurement requirements | Clauses required of vendors and cloud providers: disclosure of algorithms in use, support for hybrid key exchange, notice of cryptographic changes. |
| 13 | Exceptions | Request format, risk acceptance level required, compensating controls, mandatory expiry date, central register. |
| 14 | Monitoring, testing and review | External and internal scanning cadence, configuration drift detection, and the review cycle of the policy itself. |
| 15 | Cryptographic incident handling | What to do on key compromise, certificate mis-issuance, or publication of a practical attack on an approved algorithm, including links to the NIS2 incident reporting process. |
Section 5: what the approved list should contain
Name final standards and give parameters. For key encapsulation, ML-KEM is standardized in NIST FIPS 203, published as a final standard on 13 August 2024, alongside ML-DSA in FIPS 204 and SLH-DSA in FIPS 205 (csrc.nist.gov/pubs/fips/203/final). For symmetric protection, AES-256 is preferred for long-lived data: symmetric algorithms and hashes are not broken by Shor's algorithm, and Grover's algorithm is the reason the larger key size is chosen. If you operate in Germany, BSI TR-02102-1 (version 2026-01, published 23 January 2026) is a technical guideline that recommends hybrid post-quantum key agreement and RSA of at least 3000 bits, and recommends classical key agreement alone only until the end of 2031, or the end of 2030 for very high protection needs. Guidelines of this kind are recommendations, not obligations, unless your national law or contract makes them binding.
Section 6: what to prohibit explicitly
RC4 is prohibited in TLS by RFC 7465. MD5 and SHA-1 are obsolete for signatures. DSA is no longer approved for signature generation under FIPS 186-5 and may be used only to verify legacy signatures. The pre-standard Kyber TLS groups, such as X25519Kyber768Draft00 at codepoint 0x6399, are obsolete and should be removed in favour of the registered ML-KEM groups. Add a removal date to each line, otherwise the section becomes a wish list.
Section 11: the post-quantum transition provisions
NIS2 does not mention post-quantum cryptography. The reason to include it anyway is harvest now, decrypt later: traffic recorded today is protected only by the key exchange that negotiated it, so a session captured now could be decrypted later if the key exchange is quantum-vulnerable. That is why hybrid key exchange comes first and why signatures and certificates can migrate afterwards. Note that COM(2026) 13, published on 20 January 2026, is a Commission proposal to amend NIS2 so that national strategies include a post-quantum transition policy. It is a proposal, it has not been adopted, and it addresses Member State strategies rather than imposing a direct obligation on entities (EUR-Lex CELEX 52026PC0013).
Write four things into this section. One: the inventory requirement, refreshed on a stated cadence, since you cannot migrate what you cannot list. Two: the sequence, key exchange before signatures, externally exposed services before internal ones, long-confidentiality data first. Three: the reference dates you choose to align with, flagged for what they are. The EU Coordinated Implementation Roadmap v1.1 (published 23 June 2025) is coordinated guidance for Member States, not a regulation binding companies: it sets first steps including a cryptographic inventory and national roadmaps by the end of 2026, high-risk use cases migrated by the end of 2030 and medium-risk by the end of 2035, with low-risk as far as feasible (our summary and the Commission library entry). NIST IR 8547 remains an initial public draft, published 12 November 2024: it proposes deprecating quantum-vulnerable algorithms at 112-bit security after 2030 and disallowing all quantum-vulnerable public-key algorithms after 2035. Cite it as a draft. Four: the agility clause, meaning the technical and contractual conditions under which you can change algorithm without redesigning the system.
The baseline that belongs in the annex is short. Hybrid group first, classical fallback kept, tested in staging before production:
# OpenSSL 3.5 or later is required for the ML-KEM TLS groups
# openssl.cnf, ssl_conf section: hybrid first, classical fallback retained
Groups = X25519MLKEM768:SecP256r1MLKEM768:X25519:P-256X25519MLKEM768 is registered by IANA at 0x11EC (4588), SecP256r1MLKEM768 at 0x11EB (4587) and SecP384r1MLKEM1024 at 0x11ED (4589); the IANA TLS parameters registry is the authority (iana.org). RFC 10024 (August 2026) specifies post-quantum traditional hybrid key agreement for TLS 1.3. Current Chrome, Edge and Firefox already offer X25519MLKEM768 by default, so enabling it is normally invisible to users. On the SSH side, OpenSSH 10.0 (9 April 2025) made mlkem768x25519-sha256 the default key agreement, and OpenSSH 10.1 (6 October 2025) warns when a connection negotiates a non post-quantum key agreement.
From policy clause to evidence
An assessor reads the policy, then asks for proof that it is applied. Deciding the artefact at writing time is cheaper than reconstructing it later. The right-hand column below is our interpretation of good practice, not a literal requirement of Article 21(2)(h).
| Policy clause | Evidence to keep |
|---|---|
| Approved algorithms and parameters | Signed policy with version history and the approval record of the last change. |
| Cryptographic inventory | Dated inventory export with system owner per entry. A CBOM (cryptographic bill of materials) is one practical way to produce it, as described in our note on what a CBOM is. |
| Protocol baselines | Configuration management records plus external scan results per public endpoint. |
| Key and certificate management | Key register, rotation logs and a certificate register with expiry dates and owners. |
| Exceptions | Exception register with risk acceptance, compensating control and expiry date. |
| Review cadence | Minutes of the last review and the resulting change list. |
| Post-quantum transition | Migration plan with owners and target dates, and a progress report against it. |
NIS2 sets no review frequency. If you are also in scope of PCI DSS v4.0.1, requirement 12.3.3 requires that cipher suites and protocols in use are documented and reviewed at least every 12 months, including a documented strategy for anticipated changes in cryptographic vulnerabilities, mandatory since 31 March 2025. Adopting a twelve-month cadence for the whole policy is a defensible single baseline. Financial entities should align the same document with DORA: Commission Delegated Regulation (EU) 2024/1774 Article 6 requires an encryption and cryptographic controls policy that includes provisions for updating or changing cryptographic technology based on developments in cryptanalysis, and Article 7 requires key management across the lifecycle plus a register of certificates for ICT assets supporting critical or important functions. Our walkthrough of the DORA encryption policy under Article 6 covers the more prescriptive wording, and one document can satisfy both regimes if the scope section is explicit.
National transpositions and what to avoid
NIS2 is a directive, so it takes effect through national law. Transposition acts, national authority guidance and implementing acts may add detail: a required policy structure, named national reference guidelines, specific review frequencies or reporting formats. The detail varies by Member State and by sector, so check your national authority's published guidance before freezing the document. Do not assume the directive's minimum is your ceiling.
Four frequent weaknesses are worth naming. A policy that lists algorithms but no removal dates cannot be audited. A policy with no exception process pushes teams into silent non-compliance. A policy that names a vendor product instead of an algorithm family breaks on the next migration. And a policy that claims post-quantum readiness without an inventory cannot show which systems are concerned. Keep hedges accurate in the document too: a draft standard is a draft, and a recommendation from a national agency is not an obligation unless your scope makes it one. ANSSI, for example, states that hybridation is mandatory within its regulated scope (product qualification, defence related, SAIV and SIIV) while its broader post-quantum recommendations are not yet regulatory obligations elsewhere.
Next step: measure what your policy claims
Section 7 of the outline is the only part of the policy a third party can verify from outside, so verify it yourself first. Scan your domain with PQC Status to see the TLS versions, cipher suites, hybrid ML-KEM group support and certificate chain your public endpoints actually negotiate, then attach the result to the baseline annex as the dated evidence for that clause. A scan describes the externally visible TLS configuration only: it is not a certification and not a compliance attestation. Run it on every public hostname, record the gaps in the exception register with an expiry date, and the post-quantum section of your policy stops being aspirational.