NIS2 Encryption Requirements: What Article 21(2)(h) Actually Obliges You to Do
Ten cybersecurity risk-management measures sit at the core of NIS2 — and one of them, Article 21(2)(h), requires essential and important entities to adopt “policies and procedures regarding the use of cryptography and, where appropriate, encryption.” That single clause is short. What supervisors expect behind it is not. Most compliance teams treat encryption as a technical checkbox already handled by IT; NIS2 treats it as a governed policy area that must be documented, risk-assessed, and demonstrable during an audit — a distinction that catches many organisations unprepared.
Key facts — NIS2 Directive (EU) 2022/2555, Art. 21(2)(h)
- Legal basis: Article 21(2)(h) — one of ten mandatory risk-management measures under Art. 21(2)
- Exact text: “policies and procedures regarding the use of cryptography and, where appropriate, encryption”
- Applies to: Both essential entities and important entities — the text of Art. 21(2) does not distinguish between the two categories
- Standard of measure: “Appropriate and proportionate” per Art. 21(1) — scaled to the entity's size, exposure, and risk, not a fixed technical mandate
- Maximum sanction for failure to implement Art. 21 measures: €10M or 2% of global annual turnover (essential entities); €7M or 1.4% (important entities), per Art. 34
Does NIS2 mandate a specific encryption algorithm? No. Article 21(2)(h) does not name an algorithm, key length, or product. It requires entities to have documented policies and procedures governing when and how cryptography is used — a governance obligation, not a technical specification. The word “where appropriate” before “encryption” signals that the Directive expects a risk-based judgement about which data and systems require encryption, made and recorded by the entity itself, not a one-size-fits-all technical standard imposed from Brussels.
Why cryptography sits inside Article 21(2) at all
Article 21(1) sets the umbrella obligation: essential and important entities must take “appropriate and proportionate technical, operational and organisational measures” to manage cybersecurity risk. Article 21(2) then lists ten categories these measures must cover, at minimum — from risk analysis (a) and incident handling (b) through to supply chain security (d), vulnerability handling (e), cyber hygiene training (g), human resources security and access control (i), and multi-factor authentication (j). Cryptography and encryption sit at point (h), between effectiveness-assessment policies (f) and HR/access control (i).
The placement matters. Encryption is not treated as a standalone technical control bolted onto a network diagram — it is one governed policy area among ten that together form a single risk-management framework. Supervisors assess Art. 21(2)(h) alongside the other nine measures, looking for internal consistency: does your cryptography policy reference the same risk analysis (Art. 21(2)(a)) and asset inventory (Art. 21(2)(i)) used elsewhere in your framework, or does it exist in isolation as a separate IT document nobody outside the security team has read?
What a cryptography and encryption policy needs to cover
Because Art. 21(2)(h) sets a governance standard rather than a technical one, the practical question for compliance teams is what a defensible policy actually contains. Based on the structure ENISA applies to the other Art. 21(2) measures and the “appropriate and proportionate” test in Art. 21(1), a cryptography and encryption policy that would survive supervisory scrutiny typically addresses five areas:
Scope: what data and systems require encryption
The policy should map back to the entity's data classification and asset inventory (the same inventory feeding Art. 21(2)(i) access control): which categories of data — customer records, credentials, operational technology telemetry, network configuration files — are classified as requiring encryption at rest, in transit, or both, and which are not, with the reasoning documented.
Standards: which cryptographic algorithms and protocols are approved
A named list of approved algorithms, minimum key lengths, and approved protocols (e.g. TLS versions), aligned to a recognised external standard such as ENISA's cryptographic guidelines or ISO/IEC 27001 Annex A cryptographic controls, so the policy is not relying on an internal, unreviewed standard.
Key management: generation, storage, rotation, and revocation
Documented procedures for how cryptographic keys are generated, where they are stored (ideally separated from the encrypted data itself), the rotation schedule, and the process for revoking and reissuing keys after a suspected compromise — key management failures, not weak algorithms, are the most common root cause of encryption-related incidents.
Ownership and review cycle
A named owner (typically the CISO or equivalent) responsible for the policy, and a documented review cycle — this connects directly to Art. 21(2)(f), the obligation to assess the effectiveness of cybersecurity risk-management measures. A cryptography policy last reviewed three years ago, with no record of reassessment against evolving threats, is a supervisory red flag.
Exceptions and legacy systems
A documented exception process for legacy systems that cannot support current cryptographic standards — including compensating controls and a remediation timeline — rather than silent non-compliance. Supervisors are more concerned by undocumented gaps than by acknowledged, risk-assessed ones.
Proportionality: how “appropriate” changes by entity size and sector
Article 21(1) requires measures “proportionate” to the entity's “degree of exposure to risks, size, the likelihood of occurrence of incidents and their severity, including their societal and economic impact.” This means Art. 21(2)(h) does not impose an identical technical bar on a 50-employee food manufacturer (an important entity under Annex II) and a large bank (an essential entity under Annex I). Both need a documented cryptography policy; the depth of the standards referenced, the sophistication of key management infrastructure, and the frequency of review can reasonably differ.
What proportionality does not excuse is the absence of a policy altogether. An entity handling only low-sensitivity operational data may reasonably conclude that full-disk encryption on internal file servers is unnecessary while encryption of remote access channels is essential — but that conclusion needs to be the documented output of a risk assessment, not an assumption never written down. The distinction supervisors draw is between proportionate scope and absent governance.
“Policies and procedures regarding the use of cryptography and, where appropriate, encryption.”
The full and complete text of Article 21(2)(h) of Directive (EU) 2022/2555. It is deliberately short — but a compliant policy behind it needs to answer scope, standards, key management, ownership, and legacy exceptions in enough documented detail to withstand a supervisory audit.
— Directive (EU) 2022/2555, Article 21(2)(h)
How Art. 21(2)(h) relates to the other nine Art. 21(2) measures
Cryptography does not function as an isolated obligation. It overlaps directly with several of the other nine measures, and a policy written without reference to them tends to fail supervisory review even if the cryptography content itself is technically sound.
| Art. 21(2) measure | Overlap with cryptography policy (h) |
|---|---|
| (a) Risk analysis and information system security policies | The risk analysis determines which data categories require encryption — the cryptography policy should cite it, not duplicate it. |
| (b) Incident handling | Key revocation and re-issuance after a suspected compromise should be a defined step in the incident response procedure, not an ad hoc decision. |
| (d) Supply chain security | Where ICT vendors process encrypted data or hold key material, vendor contracts should specify the cryptographic standards those vendors must meet. |
| (f) Effectiveness assessment | The review cycle for the cryptography policy should feed into the entity's broader effectiveness-assessment procedure — not run on a separate, forgotten schedule. |
| (i) Access control and asset management | The asset inventory underpinning access control is the same inventory that should determine encryption scope — assets not on the register cannot be reliably classified for encryption. |
| (j) Multi-factor authentication | MFA and secured communications under (j) rely on the same cryptographic infrastructure and standards defined under (h) — the two are typically documented in coordinated, not separate, policies. |
How IgeraRegTech supports NIS2 cryptography policy documentation
Compliance teams building or auditing a cryptography policy against Art. 21(2)(h) need fast, citable answers about how it interacts with the other nine measures, and a way to check their existing documentation against the Directive's exact wording rather than a third-party summary that may drift from the source text.
IgeraRegTech — NIS2 policy query
Query from a compliance manager at a mid-size important entity:
“We encrypt customer data at rest but not our internal configuration backups. Does that gap alone put us out of compliance with Art. 21(2)(h)?”
IgeraRegTech answers:
Not automatically. Art. 21(2)(h) requires “policies and procedures regarding the use of cryptography and, where appropriate, encryption” — it does not mandate encryption of every data category. What matters under Art. 21(1)'s proportionality test is whether the decision not to encrypt configuration backups was made through a documented risk assessment, and whether compensating controls (access restrictions, integrity monitoring) are in place and recorded. An undocumented gap is a compliance risk; a documented, risk-assessed exception with compensating controls is a defensible position under a proportionate framework. I'd recommend adding the configuration backup decision to your cryptography policy's exceptions register with the reasoning and review date attached. Source: Directive (EU) 2022/2555, Art. 21(1)–(2)(h).
Check your cryptography policy against Art. 21(2)(h) in seconds
IgeraRegTech answers Art. 21 measure-by-measure queries, cites the exact Directive text, and flags where your existing documentation has gaps against all ten mandatory measures — without hallucinations.
Start free NIS2 gap analysisWhat supervisors typically ask for during an Art. 21(2)(h) review
During ex-ante inspections (essential entities, Art. 32) or post-incident reviews (important entities, Art. 33), supervisory authorities examining Art. 21(2)(h) compliance typically request:
- The written cryptography and encryption policy itself, with a named owner, version history, and last review date.
- Evidence the policy is linked to the entity's risk analysis under Art. 21(2)(a) — not a generic template disconnected from the entity's actual data and systems.
- Key management procedures, including generation, storage location, rotation frequency, and the revocation process following a suspected compromise.
- A record of exceptions for systems or data categories not covered by current cryptographic standards, with compensating controls and remediation timelines.
- Evidence of periodic review tied to the effectiveness-assessment procedure under Art. 21(2)(f), showing the policy has been reassessed against evolving cryptographic standards and threats, not left static since first drafted.
Summary: NIS2 Article 21(2)(h) — what you need to do
- Art. 21(2)(h) requires documented policies and procedures on cryptography and encryption — it does not name a specific algorithm or mandate universal encryption.
- Applies identically to essential and important entities; only supervisory intensity and maximum fines (Art. 34) differ by category.
- A defensible policy covers five areas: scope (what needs encrypting), approved standards, key management, ownership/review cycle, and documented exceptions for legacy systems.
- Proportionality (Art. 21(1)) permits scaling depth to entity size and risk, but does not excuse having no documented policy at all.
- The policy overlaps directly with risk analysis (a), incident handling (b), supply chain security (d), effectiveness assessment (f), access control (i), and MFA (j) — write it as part of the integrated Art. 21(2) framework, not in isolation.
- Supervisors ask for the written policy, its link to the risk analysis, key management procedures, an exceptions register, and evidence of periodic review.
- IgeraRegTech answers Art. 21 measure-by-measure queries and flags documentation gaps by citing the exact Directive text.
IgeraRegTech for NIS2 compliance teams
Query any of the ten Art. 21(2) measures and get an answer citing the exact Directive article and relevant ENISA guidance. Cross-check your policy documentation against the full Art. 21 framework, not just cryptography in isolation. Track parallel obligations across NIS2, GDPR, and DORA simultaneously.
See IgeraRegTech in actionFrequently asked questions about NIS2 cryptography and encryption requirements
Does NIS2 Article 21(2)(h) require end-to-end encryption for all communications?
No. Article 21(2)(h) requires documented policies and procedures on the use of cryptography and, “where appropriate,” encryption — it does not mandate end-to-end encryption for every communication channel across all in-scope entities. A separate provision, Article 21(2)(j), addresses secured voice, video, and text communications and multi-factor authentication “where appropriate,” using similarly proportionate language. Entities must assess which communication channels carry sensitive or operationally critical data and document the reasoning behind their encryption decisions for each.
Does Article 21(2)(h) apply equally to essential and important entities?
Yes. The text of Article 21(2) applies the same ten measures, including (h) on cryptography, to both essential entities (Annex I) and important entities (Annex II). What differs between the two categories is the supervisory regime — essential entities face proactive, ex-ante supervision under Art. 32, while important entities face reactive, ex-post supervision under Art. 33 — and the maximum administrative fine under Art. 34, not the substantive obligation itself.
What is the difference between “cryptography” and “encryption” in the text of Art. 21(2)(h)?
Cryptography is the broader discipline, covering encryption but also digital signatures, hashing, certificate management, and authentication protocols. The Directive's phrasing — “cryptography and, where appropriate, encryption” — signals that entities need governance over the full cryptographic function (key management, certificate lifecycle, algorithm selection) and, specifically where warranted by the risk assessment, encryption of data at rest or in transit. A policy addressing only encryption while ignoring certificate management or key handling would not fully satisfy the provision.
Do we need to encrypt everything to comply with NIS2?
No. Article 21(1)'s proportionality principle means encryption scope should follow a documented risk assessment, not a blanket rule. Data or systems assessed as low-risk may reasonably be excluded from encryption requirements, provided that assessment is recorded and reviewed periodically. What is not defensible is an absence of any documented decision — supervisors distinguish between a proportionate, reasoned scope and an undocumented gap.
How does the cryptography policy interact with key management specifically?
Key management is not named separately in the text of Art. 21(2)(h), but it is the practical foundation of any cryptography policy: encryption is only as strong as the process protecting the keys that unlock it. A documented policy should specify how keys are generated, where they are stored (ideally isolated from the encrypted data), the rotation schedule, and the revocation and reissuance procedure following a suspected compromise — weaknesses in key management, not the choice of algorithm, are the most common practical failure point.
What happens if we cannot upgrade legacy systems to meet current cryptographic standards?
NIS2 does not require immediate replacement of every legacy system. What Art. 21(1)'s proportionality standard expects is a documented exception: identify the legacy system, record why it cannot meet current standards, apply compensating controls (network segmentation, restricted access, enhanced monitoring), and set a remediation timeline. An undocumented legacy gap discovered during a supervisory review is treated far more seriously than an acknowledged, risk-assessed exception with a remediation plan attached.
Who within the organisation should own the cryptography and encryption policy?
NIS2 does not specify a named role, but the policy should have a documented owner — typically the CISO or equivalent security leadership function — accountable for its content and review cycle. Under Article 20, the management body must approve the entity's overall cybersecurity risk-management measures, including the Art. 21(2)(h) cryptography policy, and can be held personally liable for compliance failures. This means the policy needs board-level visibility, not just sign-off buried within IT documentation.
Published: August 2026 · Reviewed by: EU Compliance Desk, IgeraSolutions · Sources: Directive (EU) 2022/2555 (NIS2), Arts. 20, 21, 32–34; ENISA guidance on NIS2 cybersecurity risk-management measures · Author: IgeraRegTech Legal Team · This article is for informational purposes only and does not constitute legal advice. Consult qualified legal counsel and, for technical cryptographic standards, a qualified security professional for jurisdiction- and sector-specific NIS2 implementation guidance.