NIS2 · Compliance

NIS2 Article 21 and cryptography: what evidence auditors will actually ask for

Published 7 October 2026 · 7 min read · By Ali Korsi One line in Article 21 becomes a full policy, a key management lifecycle and a review cycle once you read the implementing rules.

Lire en français

Article 21(2)(h) of the NIS2 Directive (EU) 2022/2555 is one of the shortest obligations in the text. Essential and important entities must have “policies and procedures regarding the use of cryptography and, where appropriate, encryption.” That is the whole sentence.

It is tempting to read it as a box already ticked: we use TLS, our databases are encrypted, done. That reading does not survive contact with the Commission’s Implementing Regulation (EU) 2024/2690, or with a supervisor who asks you to show the policy working.

What the Directive actually says

Three provisions matter together:

Article 21(1) requires appropriate and proportionate technical, operational and organisational measures, “taking into account the state-of-the-art and, where applicable, relevant European and international standards, as well as the cost of implementation.”
Article 21(2)(h) lists cryptography and encryption policies among the minimum measures.
Article 20(1) requires management bodies to approve the Article 21 measures, oversee their implementation, and makes them liable for infringements. Article 20(2) requires management body members to follow cybersecurity training.

“State of the art” is the phrase to underline. It makes the obligation dynamic: a policy that was adequate when written can become non-compliant as the field moves on, without a single line of the policy changing.

What Implementing Regulation 2024/2690 adds

Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 sets out the technical and methodological requirements of the Article 21 measures for a specific group of entities: DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, providers of online marketplaces, online search engines and social networking services platforms, and trust service providers.

Section 9 of its Annex deals with cryptography. In summary:

9.1 — establish, implement and apply a policy and procedures related to cryptography, so that cryptography gives adequate and effective protection.
9.2(a) — in line with your asset classification, define the type, strength and quality of the cryptographic measures needed, including for data at rest and data in transit.
9.2(b) — based on that, define the protocols, algorithms, cipher strength, cryptographic solutions and usage practices that are approved and required, “following, where appropriate, a cryptographic agility approach.”
9.2(c) — define your approach to key management: generating keys, issuing and obtaining public key certificates, distribution and activation, storage and access, changing or updating keys, handling compromised keys, revocation, recovery, backup and archiving, destruction, logging and auditing of key management activity, and activation and deactivation dates.
9.3 — review and, where appropriate, update the policy and procedures at planned intervals, “taking into account the state of the art in cryptography.”

If you are not one of the listed entity types, the Regulation does not bind you directly; national transposition and your competent authority set the detail. In practice, Section 9 is the most precise statement of what “a cryptography policy” means anywhere in EU law, and we would expect auditors in other sectors to use it as a reference point. ENISA’s Technical Implementation Guidance (June 2025) adds practical examples of evidence for each requirement.

Why “we use TLS” is not a policy

Read 9.2 again. It asks you to tie cryptographic strength to asset classification, to name the approved algorithms and protocols, and to manage keys through their full life. A statement such as “all traffic is encrypted with TLS 1.2 or higher” answers none of those questions. It says nothing about:

which key exchange and signature algorithms are actually negotiated;
the RSA and elliptic-curve keys embedded in code, libraries and certificates;
who owns each key, when it expires and how it is revoked;
how quickly you could replace an algorithm if it were deprecated tomorrow.

A policy that names approved algorithms is only as good as your ability to prove that what runs in production matches it. That is where most organisations struggle.

What auditors and authorities can ask for

For essential entities, Article 32(2) gives competent authorities powers that include regular and targeted security audits, security scans, requests for documented cybersecurity policies, and “requests for evidence of implementation of cybersecurity policies.” Important entities are supervised ex post under Article 33, typically after evidence or indications of non-compliance. Either way, the question shifts from “do you have a policy?” to “show me it is applied.”

A practical mapping from requirement to evidence:

Requirement	Evidence an auditor expects	How an inventory / CBOM provides it
9.1 Policy exists and is applied	Approved, versioned policy; proof of coverage across systems	An inventory shows where cryptography is used, so coverage can be demonstrated rather than asserted
9.2(a) Strength matched to asset classification	Link between data classification and cryptographic controls	Each cryptographic asset is tied to a location and system, so it can be mapped to the data it protects
9.2(b) Approved algorithms and protocols	Approved list, plus deviations found and tracked	Discovered algorithms, key sizes and TLS configurations compared against the approved list
9.2(b) Crypto-agility	Evidence you can locate and replace algorithms	A CBOM lists every instance to change, which is the precondition for agility
9.2(c) Key management lifecycle	Certificate and key register, expiry tracking, revocation records	Parsed X.509 certificates with issuer, key type, size and validity dates
9.3 Review against state of the art	Dated reviews, change log, rationale for decisions	Repeated scans give a dated baseline and show what changed between reviews
Art. 20 Management oversight	Board minutes approving measures; reporting to management	A risk summary the management body can read, approve and minute

None of this replaces key management tooling or process documentation. But the inventory is what turns a policy from a statement of intent into something you can measure. We cover the overlap with financial-sector rules in DORA Article 9 and the cryptographic inventory.

Where post-quantum cryptography fits

NIS2 does not mention quantum computing. It does not need to. Article 21(1) ties the measures to the state of the art, and Section 9.3 requires reviews against the state of the art in cryptography. In August 2024 NIST published its first post-quantum standards, FIPS 203, 204 and 205. In June 2025 EU Member States, supported by the Commission, published a coordinated implementation roadmap for the transition to post-quantum cryptography, with first steps including cryptographic inventories by the end of 2026 and high-risk use cases migrated by the end of 2030.

It would be hard to argue in a 2026 or 2027 review that the state of the art in cryptography does not include a plan for quantum-vulnerable algorithms. That does not mean everything must be migrated now. It does mean the policy should acknowledge the issue, identify where RSA and elliptic-curve cryptography is used, and prioritise data with a long confidentiality life, which is exposed to harvest-now-decrypt-later attacks today. See our EU PQC roadmap explainer and crypto-agility explained for the detail.

Management body liability

Article 20 is why this belongs on the board agenda rather than only in the security team. Management bodies approve the measures and can be held liable for infringements. For essential entities, Article 32(5) also allows authorities, as a last resort and subject to procedural safeguards, to request a temporary prohibition on a person at chief executive or legal representative level exercising managerial functions. Article 34 sets maximum administrative fines of at least €10 million or 2% of worldwide annual turnover for essential entities, and €7 million or 1.4% for important entities, whichever is higher.

A board cannot meaningfully approve a cryptography policy it has no way to verify. Give it a dated inventory, a risk summary and a migration plan, and the approval means something.

A practical starting point

Inventory cryptography in code, certificates and live endpoints.
Compare what you find with your approved algorithm list and record deviations.
Prioritise by data sensitivity and quantum exposure.
Report to the management body and minute the approval.
Repeat at planned intervals, and keep the dated results as evidence.

Not sure where you stand? The free two-minute PQC readiness self-assessment or our CISO checklist are good first steps.

CRYPTAGION is built for this evidence trail. It runs static analysis of Python, JS/TS, Java, Go and C/C++, parses X.509 certificates and scans live TLS endpoints, then produces a CycloneDX 1.6 CBOM and a 0–100 per-asset quantum risk score that accounts for HNDL exposure. The board-ready PDF maps findings to DORA, NIS2, the EU Cyber Resilience Act and FIPS 203/204/205, with a four-wave migration roadmap. It runs on-premises or air-gapped, so your code never leaves your perimeter. More on the approach on our cryptographic inventory page.

Sources

Turn your cryptography policy into audit evidence

CRYPTAGION builds the dated cryptographic inventory, CBOM and board-ready report that NIS2 reviews and supervisors ask to see.

Book a free discovery call →

← All resources · Home