Cryptography policy under Article 21(2)(h)
Encrypting traffic is not the same as having a cryptography policy. Article 21(2)(h) NIS 2 asks for the policy. CIR §9 says what has to be in it: algorithm choices, key strengths, crypto-agility, and a twelve-point key management lifecycle.
The short version
Cryptography in NIS 2 is not the technical control. It is the written policy that decides which cryptography you use, where, and how the keys are looked after. Article 21(2)(h) is one line. CIR §9 turns that line into a real document with concrete sections.
The policy has to do three things. Tie crypto strength to your asset classification. Name the approved algorithms, key sizes and protocols, with a crypto-agility approach so they can be swapped as the state of the art moves. And cover the full key management lifecycle (CIR names twelve discrete steps from generation to destruction).
Germany puts the same duty into §30(2)(8) BSIG. The BSI's technical anchor is the TR-02102 series (TR-02102-1 for algorithms and key lengths, TR-02102-2/-3/-4 for TLS, IPsec, SSH). This page walks the directive, the CIR detail, and the German transposition in that order.
Article 21(2)(h) NIS 2 Directive (2022/2555)
Policies and procedures regarding the use of cryptography and, where appropriate, encryption.
Point (h) on the list of ten cybersecurity measures every essential and important entity has to put in place. 'Where appropriate' applies to encryption (the application), not to having the policy (which is mandatory).
CIR (EU) 2024/2690, Annex §9
The relevant entities shall lay down, implement and apply a policy and procedures on cryptography, in order to ensure adequate and effective use of cryptography to protect the confidentiality, authenticity and integrity of data, in line with the entity's asset and value classification and the results of the risk assessment.
Because this is a regulation (not a directive), it is directly binding EU law for the sectors in its Annex (DNS, TLDs, cloud, data centres, MSPs, trust services and others). §9.2 specifies the three sections the policy must contain, §9.3 sets a periodic review duty with crypto-agility in mind.
§30(2)(8) BSIG (Germany)
Concepts and procedures for the use of cryptography and, where appropriate, encryption.
Germany copies the EU text almost word for word. The BSI's technical reference is TR-02102 (the series that names approved algorithms, key lengths and protocol configurations). IT-Grundschutz module CON.1 (Krypto-Konzept) gives the implementation pattern.
Map crypto strength to asset classification
For each class of data or asset (confidentiality, authenticity, integrity, by sensitivity tier), the policy names the type, strength and quality of cryptographic measures used. The link to the asset inventory and the risk assessment from §2.1 is explicit. Higher-value data gets stronger crypto; the rule has to be written, not improvised.
Approved algorithms, key strengths, crypto-agility
The policy lists the protocols, algorithms, key strengths and key management procedures you allow, and rules out the ones you do not. CIR names this explicitly as 'a crypto-agility approach where appropriate': algorithms must be swappable as the state of the art moves. New algorithm, new key size, new protocol version: the policy supports replacement, not rewrites.
Twelve-point key management lifecycle
CIR §9.2(c) names twelve concrete key management steps: (i) generation, (ii) certificate issuance for public keys, (iii) distribution and activation, (iv) storage and authorised access, (v) change or update, (vi) handling compromised keys, (vii) revocation, (viii) recovery of lost or damaged keys, (ix) backup and archiving, (x) destruction, (xi) logging and audit, (xii) activation and deactivation dates. All twelve in the policy.
Asset classification drives crypto depth (Art. 21(1) proportionality)
You do not use AES-256 with HSM-backed keys for everything. You match the cryptography to the value and exposure of the asset. Customer database with personal data, financial records, source code: high tier. Internal templates and meeting notes: low tier. Article 21(1) says the measures must be 'appropriate to the risk posed'. CIR §9.2(a) builds that link into the policy.
Crypto-agility: review and replace (CIR §9.3)
CIR §9.3 says you review the policy at planned intervals and update it 'where appropriate, taking into account the state of the art in cryptography'. That is crypto-agility in two words. SHA-1 was fine, then it was not. RSA-1024 was fine, then it was not. Post-quantum is coming for RSA and ECC over the next decade. The policy has to support replacement, not just describe what you use today.
BSI / §30(2)(8) BSIG / TR-02102
Germany transposes Article 21(2)(h) through §30(2)(8) BSIG. The technical anchor is the BSI's TR-02102 series: TR-02102-1 for cryptographic algorithms and key lengths, TR-02102-2 for TLS, -3 for IPsec, -4 for SSH. IT-Grundschutz module CON.1 (Krypto-Konzept) is the building block that operationalises a policy. Auditors expect you to either cite TR-02102 or explain why your choice is at least as strong.
ENISA Technical Implementation Guidance
ENISA's Technical Implementation Guidance for the CIR covers §9 and maps it onto ISO/IEC 27001:2022 (A.8.24 Use of cryptography), NIST CSF 2.0, ETSI EN 319 401 and CEN/TS 18026. If you already run ISO 27001, the controls are mostly there. NIS 2 still wants the policy structured the way §9.2 lists it.
National transposition laws
Every member state has its own transposition (Netherlands: Cyberbeveiligingswet, Austria: NISG, Belgium: NIS2-Wet). The duty is the same because the directive sets one EU-wide standard. The national technical reference differs: ANSSI in France publishes RGS, ENISA-aligned guidance is reused in the Netherlands. The policy structure does not change.
We have TLS everywhere, so we are done.
Encryption in transit is one slice of the policy. CIR §9.2(c) wants the full key management lifecycle in writing: how keys are generated, where they live, how they are rotated, what happens when one is compromised, who can recover them, when they are destroyed. If those twelve points are not on paper, the policy is not finished, no matter how much TLS you have deployed.
We use what our vendor ships.
The entity stays accountable. §30 BSIG and Article 21 do not transfer the duty to the vendor. If your SaaS provider uses AES-128 and you classified that data as high-confidentiality, that is your problem to fix in the policy or in the contract. The policy has to name what you accept, not just what showed up in the default config.
Key management is IT's problem.
Key management is governance. The policy is signed off by the management body (Art. 20 plus the management-body sign-off pattern that runs through Article 21). When a key is compromised, the response runs through the incident process under Article 23. When access to a high-value key is granted, it is logged. IT runs the controls; management owns the policy.
What we see in the German Mittelstand: encryption-in-transit is usually fine (TLS, VPN, S/MIME or SMTP-TLS for mail). Encryption-at-rest is patchy but recoverable. The real gap is documentation of key management. Who has the master keys for the VPN? Where are the cloud KMS keys backed up? What happens to a leaver's encryption certificate? Most teams know the answers; the answers are not written down.
Two-step approach that holds up under audit. First, write the policy: asset tiers, approved algorithms (cite TR-02102 or ENISA TIG), key management lifecycle covering all twelve §9.2(c) points, sign-off by the management body. Then map the policy to the systems you already run (cloud KMS, certificate authority, VPN, mail, file encryption). Most of the controls exist. The §9.2(c) checklist is the artefact auditors ask for.
We provide a cryptography policy template that is structured along CIR §9.2(a), (b) and (c). You start from the template, name your asset tiers, pick algorithms from a TR-02102-aligned list, and walk through the twelve-point key lifecycle. The result is a signed document that maps directly to the CIR sub-points an auditor will reference.
The key inventory in the CRY module lists keys by purpose (TLS, signing, encryption, code), by system, by owner, by activation and deactivation date. CIR §9.2(c)(xi) (logging) and §9.2(c)(xii) (activation/deactivation dates) become a table, not a memory exercise. Review the policy yearly; the platform schedules the §9.3 review and tracks the sign-off.
- Directive (EU) 2022/2555 (NIS 2), Article 21(2)(h) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Commission Implementing Regulation (EU) 2024/2690 (CIR), Annex §9 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSI Act (BSIG), §30(2)(8) as amended by the NIS2 Implementation and Cybersecurity Strengthening Act
- BSI TR-02102 series (Cryptographic Mechanisms: Recommendations and Key Lengths) — bsi.bund.de/dok/tr-02102
- IT-Grundschutz Kompendium, module CON.1 (Krypto-Konzept) — bsi.bund.de/grundschutz
- ENISA Technical Implementation Guidance for CIR (EU) 2024/2690, mapping to ISO/IEC 27001:2022 A.8.24