NIS2 Cryptography Obligations: The 10 CIR Annex 9 Controls Your Encryption Policy Must Document

Most NIS2 cryptography guides offer the same checklist: encrypt data at rest, use TLS, manage your keys. That advice is correct. It is also insufficient to survive an audit.

Commission Implementing Regulation (EU) 2024/2690 — CIR 2024/2690 — introduces something the NIS2 Directive itself does not: a structured framework defining exactly what your cryptography policy must contain. The requirements sit in Section 9 of the CIR Annex on technical and methodological requirements, and as of its entry into force in January 2025, they set the evidentiary baseline for what regulators consider documented cryptography compliance.

At the time of writing, no publicly available guide covers CIR Annex 9 section by section. Every article summarises Article 21(2)(h) at directive level and then provides generic implementation advice. This guide does something different: it walks through each of the 10 distinct controls within Annex 9, explains what the regulation specifically requires, and maps concrete, auditor-facing evidence to each obligation.

Article 21(2)(h) and the Two-Layer Compliance Framework

The NIS2 Directive at Article 21(2)(h) requires all essential and important entities to implement “policies and procedures regarding the use of cryptography and, where appropriate, encryption.” The Directive is technology-neutral — it prescribes no specific algorithms, key lengths, or rotation schedules.

CIR 2024/2690 fills that gap for specific entity types. The Implementing Regulation, published on 17 October 2024 and in force from January 2025, applies directly to DNS service providers, TLD registries, domain registration services, cloud computing providers, data centre operators, content delivery networks, managed service providers, managed security service providers, online marketplace operators, search engine providers, and social networking platforms. For these entities, CIR 2024/2690 Section 9 is legally binding.

For all other essential and important entities, Article 21(2)(h) still applies — but the implementing technical detail must be derived from ENISA guidance, ISO 27001, and comparable frameworks. In practice, national competent authorities are using CIR Annex 9 as the benchmark for what proportionate, documented cryptography compliance looks like across all entity types. Using it as your policy template reduces audit risk and demonstrates due diligence.

Entity type	CIR 2024/2690 binding?	Article 21(2)(h) applies?
Cloud computing providers	Yes — Annex 9 is binding	Yes
DNS service providers	Yes — Annex 9 is binding	Yes
Managed service providers	Yes — Annex 9 is binding	Yes
Healthcare, energy, transport	No — outside CIR scope	Yes
Banks and financial infrastructure	No — outside CIR scope	Yes (+ DORA)

The 10 CIR Annex 9 Cryptography Controls — Section by Section

Section 9 of the CIR Annex can be read as a set of ten distinct obligations. The regulation’s internal numbering has three main sub-sections (9.1, 9.2, and 9.3), but 9.2 contains multiple lettered sub-requirements covering algorithm selection, cryptographic agility, and a detailed key management lifecycle. The 10 controls below map the complete scope of what your policy must document.

Control 1 — The Cryptographic Policy Mandate (Section 9.1)

Section 9.1 is the foundation. It requires entities to establish, implement, and apply a policy and procedures related to cryptography, with a view to ensuring adequate and effective use of cryptography to protect the confidentiality, authenticity, and integrity of data. The policy must align with the entity’s asset classification and the risk assessment results from Section 2.1 of the Annex.

Three distinct obligations are embedded in this single requirement. Establish means a written policy must exist. Implement means the policy must be operationally active — not shelf documentation. Apply means controls must be demonstrably deployed on actual systems and data. All three must be evidenced separately during an audit.

Audit evidence: A signed, dated, version-controlled cryptography policy document; deployment records confirming controls are live.

Control 2 — Asset Classification-Linked Protection Requirements (Section 9.2(a))

The policy must establish, in accordance with the entity’s classification of assets, the type, strength, and quality of cryptographic measures required to protect those assets. This means encryption requirements cannot be uniform across your environment — they must vary with data sensitivity.

In practice, build a mapping table: asset classification tier → encryption type required → minimum algorithm strength. A healthcare operator might classify patient records as Tier 1 (highest sensitivity), requiring AES-256 encryption at rest and TLS 1.3 in transit, while internal operational data at Tier 2 might accept AES-128 as a minimum.

Audit evidence: An asset register with classification labels; a policy section that maps each classification level to specific encryption requirements.

Control 3 — Data-at-Rest Protection (Section 9.2(a))

Section 9.2(a) explicitly calls out data at rest as a protection category. The regulation is algorithm-neutral — it does not name AES-256 — but requires that the type, strength, and quality of your encryption choices be documented and justified against your asset classification and risk results.

As a general guideline, practitioners and ENISA implementation guidance point to AES-256-GCM as the current industry standard for symmetric data-at-rest encryption, with key management via RSA-4096 or ECC P-256. The regulation’s “state of the art” standard (invoked in Section 9.3) means this list requires periodic review as cryptanalysis advances.

Common data-at-rest coverage areas where encryption must be documented:

• Full-disk encryption on endpoint devices (laptops, mobile phones, removable media)
• Database field-level encryption for sensitive records and personal data
• Encrypted container or file-system encryption for file stores and document repositories
• Encrypted backups — the most frequently missed finding in cryptography audits

Audit evidence: Encryption deployment records by system; tool configuration exports; backup encryption certificates.

Control 4 — Data-in-Transit Protection (Section 9.2(a))

The same requirement applies to data in transit. The documentation obligation extends to how encrypted transport is implemented across your network topology — not only external connections, but also internal service-to-service communication.

TLS 1.2 is the current practitioner minimum for in-transit protection; TLS 1.3 is preferred and should be the default for new deployments. TLS 1.0 and 1.1 are deprecated and must be explicitly disabled. Your policy must also address SSH-2 for administrative access, S/MIME or STARTTLS for email handling sensitive communications, and VPN requirements for remote access over public networks.

The policy must be explicit about when in-transit encryption is required and when it is not. Internal traffic on isolated, monitored segments may have a different classification than external or cross-cloud traffic. The at-rest vs. in-transit decision framework below addresses this directly.

Audit evidence: TLS configuration reports from network scanners; architecture diagrams annotating encryption boundaries; protocol audit logs.

Control 5 — Algorithm and Protocol Selection (Section 9.2(b))

Section 9.2(b) requires the policy to establish the protocols or families of protocols to be adopted, as well as cryptographic algorithms, cipher strength, cryptographic solutions, and usage practices approved for use within the entity. This is the approved-list requirement — and it has a direct counterpart: a prohibition list.

Your policy needs a specific section listing approved and prohibited algorithms. The table below reflects current practitioner consensus mapped to the regulation’s “state of the art” standard. Note that CIR 2024/2690 itself does not name specific algorithms — these recommendations derive from ENISA guidance, NIST SP 800-57, and BSI Technical Guidelines, which are Tier 2–3 sources. Your policy must justify your choices relative to your risk classification.

Category	Approved (minimum)	Preferred	Prohibited
Symmetric encryption	AES-128-GCM	AES-256-GCM	DES, 3DES, RC4, Blowfish
Asymmetric encryption	RSA-2048	RSA-4096, ECDSA P-256	RSA < 2048, DSA
Hashing	SHA-256	SHA-384, SHA-512	MD5, SHA-1
Transport protocols	TLS 1.2	TLS 1.3	SSL 2/3, TLS 1.0, TLS 1.1
Key exchange	ECDHE with P-256	ECDHE with P-384	RSA key exchange (no PFS)

Audit evidence: A documented approved-algorithm register with approval dates and version history; configuration exports from servers and network devices confirming prohibited protocols are disabled; vulnerability scanner output confirming no deprecated cipher suites are active.

Control 6 — Cryptographic Agility (Section 9.2(b))

Section 9.2(b) introduces cryptographic agility explicitly, requiring entities to follow, where appropriate, a cryptographic agility approach. This is the most underestimated control in Section 9 — and the one most likely to generate findings in future audits as post-quantum cryptography timelines firm up.

Cryptographic agility means your systems can switch algorithms without requiring architectural rework or extended downtime. It is not a product you purchase — it is a design property that must be built in and documented. ENISA’s June 2025 Technical Implementation Guidance specifically highlights cryptographic agility as preparation for the post-quantum transition. The “harvest now, decrypt later” threat — where adversaries capture encrypted data today to decrypt once quantum-capable hardware matures — makes this requirement operationally urgent for organisations handling long-lived sensitive data.

What auditors will look for when assessing cryptographic agility:

• A policy statement committing to cryptographic agility as a design principle for new systems
• An inventory of systems with their current algorithm bindings and dependencies
• A documented migration runbook: if Algorithm X is deprecated, here is the process to transition to Algorithm Y
• A process for emergency algorithm replacement triggered by vulnerability disclosure
• Evidence that cryptographic configurations are centralised (PKI, secrets management) rather than hardcoded in individual applications

Audit evidence: Architecture documentation showing abstraction of cryptographic functions; migration runbook; PKI or secrets management platform configuration; emergency response procedure for algorithm compromise.

Control 7 — Key Generation Procedures (Section 9.2(c))

Section 9.2(c) requires the policy to address the approach to key management, explicitly calling out methods for generating different keys for cryptographic systems and applications. The requirement that different systems use different keys — key isolation — limits the blast radius of a compromise. A single compromised key affecting your entire estate is an automatic audit failure and a reportable incident under NIS2 Article 23.

Your policy must document:

• Key generation method: hardware random number generation (HRNG/TRNG) is preferred over software-based PRNG for high-assurance environments; document which method is used for each key type
• Key length requirements by algorithm: aligned with your approved algorithm list from Control 5
• Authorised roles: who may generate keys — a named role definition, not an individual name, to survive staff turnover
• HSM requirements: Hardware Security Modules for root CA keys and high-sensitivity data encryption keys; document whether HSMs are required or optional by key classification

The access control policy and the cryptography policy must be consistent: key generation rights must appear in both documents.

Audit evidence: Key management system records showing key origin; HSM configuration and certification if used; role matrix showing who holds key generation rights.

Control 8 — Key Activation and Deactivation Scheduling (Section 9.2(c))

Section 9.2(c) explicitly requires setting activation and deactivation dates for keys, ensuring that keys can only be used for the specified period of time according to the organisation’s rules on key management. This is not optional and not implicit — your policy must state planned expiration dates for each key type before the keys are generated.

Key type	Maximum active period	Recommended rotation trigger
Symmetric data encryption keys	12 months	Annual or on staff departure from key custodian role
TLS/SSL server certificates	12 months (CA/Browser Forum)	Automated renewal 30 days before expiry
Code signing certificates	12–36 months	At volume threshold or time limit, whichever first
API authentication keys	90 days	Quarterly automated rotation
Root CA keys	20 years	Compromise only; never routine rotation
Intermediate CA keys	5–10 years	At scheduled renewal or on subordinate compromise
Backup encryption keys	5 years	Review at each backup architecture change

These cadences reflect practitioner consensus — NIST SP 800-57 Part 1, ENISA implementation guidance — not mandated durations from CIR 2024/2690, which is cadence-neutral. Your policy must justify your chosen periods relative to your risk classification and document the justification. Auditors will ask why you chose 12 months, not merely that you did.

MFA requirements interact directly with key management: privileged key management operations should require multi-factor authentication as a compensating control.

Audit evidence: A key rotation calendar or schedule; completed rotation log entries with dates; certificate management platform screenshots confirming automated renewal is configured.

Control 9 — Key Revocation and Destruction (Section 9.2(c) scope)

While Section 9.2(c) explicitly names key generation and activation scheduling, the broader “approach to key management” requirement encompasses the full lifecycle. A compliant key management policy must address revocation — the immediate invalidation of a key before its scheduled expiration — and destruction, the irreversible elimination of key material at end of life.

Revocation triggers your policy must name:

• Known or suspected key compromise (including vendor notification of a breach affecting your HSM or key management platform)
• Departure of a key custodian without secure handover under dual-control procedures
• Certificate Authority compromise affecting your certificate chain
• Regulatory or algorithm deprecation announcement requiring emergency replacement
• Failure of cryptographic agility migration within a defined timeframe

Destruction requirements:

• Software keys: cryptographic erasure — overwrite key material in memory and storage with random data, multiple passes
• HSM keys: hardware zeroisation using the HSM’s built-in secure erase command, followed by documented certification
• Physical media: degaussing or physical shredding with destruction certificate for media holding unencrypted key material
• Cloud key material: documented deletion via key management service API, with cloud provider confirmation receipt

Audit evidence: A key revocation log with timestamps and authorising roles; executed revocation records; HSM zeroisation certificates; destruction certificates for physical media.

Control 10 — Policy Review and State-of-the-Art Compliance (Section 9.3)

Section 9.3 requires entities to review and, where appropriate, update their policy and procedures at planned intervals, taking into account the state of the art in cryptography. “State of the art” is a recurring standard in NIS2 — Recital 79 of the Directive defines it as requiring alignment with current expert consensus, not historical best practice.

The practical consequence: algorithm deprecations and the emergence of post-quantum cryptography mean the cryptographic field moves faster than most policy review cycles anticipate. Your policy must have a scheduled review cycle and a set of defined triggers for out-of-cycle review.

Minimum review frequency: Annual. Triggers for out-of-cycle review:

• NIST, ENISA, or BSI publishes a new algorithm deprecation notice or updated cryptographic guidance
• A vulnerability affecting an algorithm in your approved list is publicly disclosed (CVSS 7.0+)
• A significant breach at a peer organisation reveals a cryptographic failure mode relevant to your environment
• Your entity undergoes significant architectural change affecting the encryption scope (cloud migration, new service launch)
• New ENISA Technical Implementation Guidance is published — ENISA updated its guidance in June 2025

Audit evidence: Dated review records with reviewer names and sign-offs; a change log showing what was updated and why; evidence of algorithm-deprecation monitoring (e.g., ENISA newsletter subscriptions, NIST CSRC alerts).

At-Rest vs. In-Transit: A Decision Framework

Section 9.2(a) references data at rest and data in transit as distinct protection categories. Before deploying controls, your policy must be explicit about how the organisation classifies each data state and which encryption applies in each case.

Decision framework — four data states and their encryption obligations:

State 1 — Data in transit: Data currently moving between systems, users, or organisations. Apply transport layer encryption. Minimum: TLS 1.2 with forward secrecy cipher suites. Preferred: TLS 1.3. Required for: all external connections, internal service-to-service communication on networks classified as untrusted or mixed-trust, API calls.

State 2 — Data at rest: Data stored on devices, servers, databases, or backup media. Apply symmetric encryption. Minimum: AES-128-GCM for standard sensitivity. Required: AES-256-GCM for high-sensitivity and critical data. Also applies to: log files, caches, temporary processing files if they persist beyond the active session.

State 3 — Data in use: Data actively processed in application memory. Cryptographic protection is technically complex and operationally constraining. Your policy must document a risk acceptance decision for this state, name compensating controls (memory isolation, process segmentation, privileged access monitoring), and reference any Confidential Computing technologies being evaluated.

State 4 — Data crossing trust boundaries: Data leaving your organisation’s control — transmitted to third parties, uploaded to cloud storage, sent to processors. Both in-transit encryption for the transmission and at-rest encryption at the destination must be documented. Supply chain due diligence under NIS2 Article 21(2)(d) intersects here: your cryptography policy and your supply chain policy must be consistent on third-party data handling.

Key Lifecycle Management: Stages and Cadences

CIR Annex 9 Section 9.2(c) puts the key lifecycle at the centre of the cryptography policy. Every stage — from generation to destruction — must be addressed. The six stages below cover the full scope of what a compliant policy must document.

1. Generation: Keys generated using cryptographically secure random number generation. Role-controlled: only authorised personnel or automated systems may initiate key generation. HSM-based generation for root CA keys, high-sensitivity data encryption keys, and payment or healthcare context keys where regulatory equivalents (PCI DSS, HIPAA) also apply.

2. Distribution: Symmetric keys must never be transmitted in cleartext. Wrap keys using a Key Encrypting Key (KEK) or transmit via a key management system that enforces encrypted transport. Key distribution by email, shared drives, or configuration management tools without encryption is a common finding and a direct violation of the Section 9.2(c) key management obligation.

3. Storage: Keys stored separately from the data they protect. Minimum: encrypted key storage with role-based access control and audit logging. Preferred: HSM-based storage for high-value keys. Cloud key management services (AWS KMS, Azure Key Vault, GCP KMS) are acceptable when configured with customer-managed keys and audit logging enabled.

4. Activation and rotation: Keys activate on a defined start date and expire on a defined end date — both set at generation time per Section 9.2(c). Rotation is the process of generating a replacement key, re-encrypting data protected by the expiring key, and retiring the old key. Automated rotation, where the key management platform handles re-encryption without manual intervention, is the recommended approach for volume key types such as TLS certificates and API keys.

5. Revocation: A revoked key is permanently invalidated before its scheduled expiration. Revocation must be immediate on known or suspected compromise — not deferred to the next rotation window. Your policy must define the escalation path: who decides to revoke (role), who executes it (role), and how systems dependent on the key are notified, updated, and logged.

6. Destruction: At end of life, key material must be irreversibly eliminated. For software keys: cryptographic erasure with multiple overwrite passes. For HSM keys: hardware zeroisation using the device’s secure erase function. Document every destruction event with a destruction certificate. Auditors will request this evidence — missing destruction records imply keys may still exist and could be used outside policy.

What Goes in Your Cryptography Policy Document

The documentation requirement in Section 9.1 is not satisfied by a brief policy statement. Auditors assess whether the policy contains substantive content that maps to each sub-requirement. The checklist below covers the minimum required elements, mapped to their Annex 9 source.

Policy element required	Annex 9 control	Audit evidence
Policy scope, purpose, and owner	9.1	Signed, dated, version-controlled document
Asset classification linkage table	9.2(a)	Asset register with classification; mapping to encryption requirements
Data-at-rest encryption requirements by classification	9.2(a)	Deployment records; encryption inventory by system
Data-in-transit encryption requirements	9.2(a)	TLS configuration reports; network architecture diagram
Approved algorithm register (with prohibition list)	9.2(b)	Algorithm list with approval dates; scanner output confirming compliance
Cryptographic agility statement and migration runbook	9.2(b)	Architecture documentation; emergency replacement procedure
Key generation procedures and role authorisation	9.2(c)	Key management system records; role matrix
Key rotation schedule by key type	9.2(c)	Rotation calendar; completed rotation logs
Key revocation triggers and procedures	9.2(c)	Escalation matrix; executed revocation records
Key destruction procedures and documentation requirements	9.2(c)	Destruction logs; HSM zeroisation certificates
Policy review schedule and out-of-cycle triggers	9.3	Review records with sign-offs; change log
State-of-the-art monitoring mechanism	9.3	Evidence of ENISA/NIST alert subscriptions; review meeting minutes

Need a policy document that covers all 12 elements above? The Encryption Policy template in the Complete NIS2 Toolkit is pre-structured to Annex 9, saving an estimated 20–30 hours of drafting and legal review time.

Role Responsibilities for Cryptography Compliance

NIS2 Article 20 holds management bodies directly responsible for approving and overseeing cybersecurity risk-management measures. The cryptography policy is a management-level obligation — not an IT team deliverable. The RACI table below reflects a proportionate ownership structure.

Control area	CISO / IT Security	IT Operations	Legal / Compliance	Board / Management
Policy authorship and maintenance	Own	Input	Review	Approve
Algorithm selection and approval list	Own	Input	N/A	Aware
Key generation and storage operations	Supervise	Own	N/A	N/A
Key rotation execution	Supervise	Own	N/A	N/A
Key revocation decision	Own	Execute	Notify if reportable	Inform if material
Policy review scheduling	Own	Input	Co-own	Approve
Audit evidence compilation	Co-own	Provide	Co-own	N/A

Frequently Asked Questions

Does NIS2 require encryption for all data?

No. Article 21(2)(h) says “where appropriate” — encryption requirements are proportionate to risk. Your asset classification (Control 2) determines which data requires encryption and at what level. The cryptography policy itself is mandatory for all entities; blanket encryption of all data is not required, but selective encryption decisions must be documented and risk-justified.

Does CIR 2024/2690 Annex 9 apply to my organisation?

CIR 2024/2690 applies directly to specific digital service provider categories — cloud providers, DNS operators, CDNs, managed services, online marketplaces, search engines, and social platforms. If your organisation is outside those categories, Article 21(2)(h) of the Directive applies and Annex 9 serves as the most detailed published specification of what proportionate compliance looks like. National competent authorities are increasingly using it as the benchmark even for entities outside CIR scope.

What are the penalties for non-compliance with NIS2 cryptography requirements?

Under NIS2 Article 34, essential entities face penalties of up to EUR 10 million or 2% of global annual turnover, whichever is higher. Important entities face up to EUR 7 million or 1.4% of global turnover. Cryptography policy failures are among the most auditable deficiencies because the evidence — or its absence — is document-based. Missing a rotation log or an algorithm register is a documented finding, not a matter of interpretation.

How often must we review our cryptography policy?

Section 9.3 requires review at “planned intervals” — the regulation does not mandate a specific cadence. Annual review is the practitioner minimum. Additional out-of-cycle reviews are triggered by algorithm deprecation announcements, new ENISA guidance, significant incidents, or architectural changes affecting your encryption scope.

What is cryptographic agility and why is it required?

Cryptographic agility is the ability to replace an algorithm across your systems without architectural changes or extended downtime. Section 9.2(b) requires entities to follow a cryptographic agility approach where appropriate. ENISA’s June 2025 Technical Implementation Guidance specifically links this requirement to post-quantum cryptography readiness — organisations that cannot rapidly swap algorithms will face significant re-engineering when quantum-resistant standards become mandatory.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — EUR-Lex (eur-lex.europa.eu)
• Directive (EU) 2022/2555 (NIS2), Article 21 — EUR-Lex (eur-lex.europa.eu)
• ENISA Technical Implementation Guidance on Cybersecurity Risk-Management Measures, version 1.0, June 2025 — ENISA (enisa.europa.eu)