NIS2 does not require you to encrypt everything. Article 21(2)(h) requires every essential and important entity to have policies and procedures regarding the use of cryptography and, where appropriate, encryption. The policy is mandatory. Where you encrypt follows from your risk assessment. For cloud, managed service and other digital providers, Regulation (EU) 2024/2690 sets out what the policy must contain.
This guide covers what Article 21 requires, whether encryption is mandatory, Regulation 2024/2690, a policy outline, key management, post-quantum plans, telecom, GDPR and ISO 27001, what the rules leave open, and a checklist.
| Source | What it says on cryptography | Who it binds |
|---|---|---|
| NIS2 Art. 21(2)(h) | Policies and procedures on cryptography and, where appropriate, encryption | All essential and important entities |
| NIS2 Art. 21(2)(j) | Secured voice, video, text and emergency communications, where appropriate | All essential and important entities |
| Regulation (EU) 2024/2690, Annex section 9 | Policy content, approved algorithms, key management, reviews | Cloud, data centre, CDN, DNS, TLD, MSP, MSSP, online platforms, trust service providers |
| NIS2 recital 98 | Encryption, in particular end-to-end, should be promoted, and mandatory where necessary for telecom providers | Explains intent; the obligation is Article 21 |
| Recommendation (EU) 2024/1101 and roadmap | Start the post-quantum transition by end 2026; critical infrastructure by end 2030 | Addressed to Member States, not a duty on companies |
What does NIS2 require for encryption?
Article 21(2)(h) lists, among the minimum measures, “policies and procedures regarding the use of cryptography and, where appropriate, encryption”. “Where appropriate” qualifies encryption, not the policy. Every essential and important entity needs a documented approach to cryptography. Whether a given system is encrypted is a decision that approach has to make and justify.
Cryptography is also wider than encryption: it covers integrity and authenticity too, through signatures, certificates and hashes. Article 21(1) frames the decision: measures take into account the state of the art, relevant standards and the cost of implementation, in proportion to your exposure, size, and the likelihood and severity of incidents. Article 21(2)(j) adds “secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate”. In practice, secured means encrypted.
Article 20 makes the management body approve the measures and oversee them, the cryptography policy included. The other nine measures are in NIS2 Article 21 explained.
Is encryption mandatory under NIS2?
Not unconditionally. The binding text says “where appropriate” and names no system, data type or algorithm. The confusion comes from recital 98. It says encryption, in particular end-to-end encryption, “should be promoted” and, “where necessary”, “should be mandatory for providers of public electronic communications networks or of publicly available electronic communications services”. A recital explains the purpose of the law. The obligation sits in Article 21, which applies the same “where appropriate” test to every entity, telecom operators included.
Two things can make encryption compulsory for you in fact. First, national law: Article 5 lets Member States adopt provisions ensuring a higher level of cybersecurity, so check your transposition. Second, your own risk assessment: once it identifies a risk that encryption treats, not encrypting is a decision you have to defend.
What “where appropriate” means in practice
A sensible approach is to make encryption the default and document the exceptions. In practice, it is hard to argue that encryption is not appropriate for:
- data in transit over public networks, including administrative and remote access;
- laptops and phones, which get lost;
- backups, especially copies held off site or by a provider;
- storage holding personal, financial or customer data;
- email with critical suppliers and customers.
Where encryption is not appropriate, such as a legacy industrial controller that cannot support it, record why, the compensating control and a review date. That record is what you show an authority.
What does Regulation 2024/2690 require for cryptography?
Implementing Regulation (EU) 2024/2690 applies to DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed service providers, managed security service providers, online marketplaces, search engines, social networking platforms and trust service providers. Section 9 of its annex turns Article 21(2)(h) into specific requirements:
- 9.1: a policy and procedures on cryptography, ensuring “adequate and effective use of cryptography”, in line with asset classification and the risk assessment.
- 9.2(a): the type, strength and quality of cryptographic measures for each class of asset, “including data at rest and data in transit”.
- 9.2(b): the protocols, algorithms, cipher strength, solutions and usage practices approved and required, “following, where appropriate, a cryptographic agility approach”.
- 9.2(c): the approach to key management, across twelve activities from generation to destruction.
- 9.3: review and, where appropriate, update at planned intervals, “taking into account the state of the art in cryptography”.
Point 6.7.2(i) adds that distinct systems communicate only through trusted channels isolated by “logical, cryptographic or physical separation”. If you are not one of these providers, section 9 is still a detailed official reading of Article 21(2)(h), and a sound structure for your own policy. Who falls under the regulation is set out in NIS2 for digital infrastructure.
What should a NIS2 cryptography policy contain?
The outline below follows section 9 of Regulation 2024/2690. It is a practical template, not legal text. Put the algorithm tables in an annex you can update without re-approving the policy.
CRYPTOGRAPHY POLICY: OUTLINE
1. Purpose and scope
- Confidentiality, integrity and authenticity of data
- Services, systems and sites covered
2. Roles
- Policy owner, key custodians, approval by management
3. Protection by asset class
- Class | at rest | in transit | signing/integrity
- Exceptions: system, reason, compensating control,
owner, review date
4. Approved cryptography (annex, reviewed yearly)
- Protocols and minimum versions
- Algorithms and minimum key lengths
- Deprecated and banned items, with retirement dates
- Crypto agility: how an algorithm gets replaced
5. Key management
- Generation, certificates, distribution, storage
- Rotation, compromise, revocation, recovery
- Backup, destruction, logging, validity periods
6. Suppliers
- Minimum encryption requirements in contracts
- Who holds the keys for hosted and managed services
7. Evidence
- Coverage metrics, certificate expiry, open exceptions
8. Review
- Planned interval; triggers: incident, new threat,
new standard, deprecated algorithmHow should you manage encryption keys under NIS2?
Encryption is only as strong as the process that generates, stores, rotates and destroys the keys. Point 9.2(c) of Regulation 2024/2690 lists twelve activities the approach covers, where appropriate: generation, certificates, distribution, storage and access, changing keys, compromised keys, revocation, recovery, backup, destruction, logging and auditing, and activation and deactivation dates.
In practice, three gaps are common:
- Keys stored next to the data they protect, in the same database, repository or configuration file.
- No procedure for a compromised key, so the first one is improvised during an incident.
- Certificates nobody owns, discovered when they expire and a service stops.
A managed key service or hardware security module solves storage and logging. It does not solve ownership. Every key and certificate needs a named owner, and for hosted services the policy should say who holds the keys: you or the provider.
Does NIS2 require post-quantum cryptography?
No. The cryptography provisions of NIS2 and Regulation 2024/2690 contain no post-quantum requirement. The EU plan sits in two documents addressed to Member States:
- Commission Recommendation (EU) 2024/1101 of 11 April 2024 on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography.
- The coordinated roadmap the Member States published with the Commission on 23 June 2025, developed in the NIS Cooperation Group. The Commission’s announcement of it says all Member States “should start transitioning to post-quantum cryptography by the end of 2026”, and critical infrastructure should move “as soon as possible, no later than by the end of 2030”.
The link to NIS2 is indirect: Regulation 2024/2690 asks for cryptographic agility where appropriate and reviews against the state of the art. In practice, start with an inventory of where you rely on public-key cryptography (TLS, VPNs, SSH, code signing) and which vendors control it. Data that must stay confidential for years comes first, because traffic recorded today could be decrypted later.
What does NIS2 mean for encryption in telecom?
Providers of public electronic communications networks and publicly available electronic communications services are in scope regardless of size (Article 2(2)(a)). Medium-sized and larger providers are essential entities (Article 3(1)); small and micro providers are important unless identified as essential. Jurisdiction lies with the Member State where they provide services (Article 26).
Article 43 deleted the telecom security rules in Articles 40 and 41 of the European Electronic Communications Code (Directive (EU) 2018/1972) from 18 October 2024. Recital 95 says national guidelines adopted under those articles should be taken into account where appropriate. The telecom-specific encryption points are in the recitals:
- Recital 98: encryption, in particular end-to-end, should be promoted, alongside data-centric concepts such as cartography, segmentation, tagging and access management. Where necessary it should be mandatory, “in accordance with the principles of security and privacy by default and by design”. It “should be reconciled with the Member States’ powers” on public security and criminal investigation, but “this should not weaken end-to-end encryption”.
- Recital 99: secure routing standards should be promoted.
- Recital 104: providers should implement security by design and by default, and tell customers about significant cyber threats and measures they can take, “for example by using specific types of software or encryption technologies”.
Article 2(6) adds that NIS2 is without prejudice to Member States’ responsibility for national security and their power to maintain law and order. Read with recital 98, NIS2 leaves national rules on lawful access in place, and does not ask operators to weaken end-to-end encryption to serve them.
Article 23(2) is binding: where applicable, entities tell recipients potentially affected by a significant cyber threat what measures they can take. Pointing customers to an encrypted channel can be exactly that. Operators also pass encryption requirements to suppliers through contracts, as described in NIS2 for telecom suppliers.
How does NIS2 encryption overlap with GDPR and ISO 27001?
GDPR Article 32(1)(a) names “the pseudonymisation and encryption of personal data” as a security measure, as appropriate. Under Article 34(3)(a), you need not tell affected people about a breach if measures such as encryption made the data unintelligible to anyone unauthorised. Encryption you can prove changes what happens after a breach. One policy serves both laws: see NIS2 and GDPR.
ISO/IEC 27001:2022 covers the same ground in Annex A control 8.24, use of cryptography. If you run an ISMS, the policy probably exists; check that it covers key management in the depth section 9 describes. The rest of Annex A, sorted by the work it takes, is in the Annex A controls grouped for real work.
What does NIS2 leave open on encryption?
The cryptography rules in NIS2 and Regulation 2024/2690 name no algorithm, key length or protocol version. Article 25 has Member States encourage standards without imposing or favouring a particular technology, and the state of the art moves. You choose, and the authority checks whether your choice is followed: it can ask for evidence that policies are implemented, not only for the policies (Articles 32 and 33).
A policy that says “TLS 1.2 or higher” is easy to write. The audit question is whether it is true today: which endpoints still accept older protocols, which volumes and backups are unencrypted, which certificates expire next month, which keys missed rotation. The answers sit in key management services, device management, certificate inventories and scanners. Collected by hand once a year, they are out of date on arrival.
Closing the gap means reading encryption state from the systems continuously, with a person reviewing the exceptions against the policy. That is how the CloudSoul platform works: automated, with human-in-the-loop expertise. A security audit against Article 21 shows where your encryption coverage stands today, and the wider programme is on the NIS2 compliance page.
NIS2 encryption checklist
- Approve a cryptography policy covering confidentiality, integrity and authenticity.
- Classify data and set encryption at rest and in transit for each class.
- Keep an approved-algorithms annex with deprecated items and retirement dates.
- Record every exception with a reason, compensating control and review date.
- Name an owner for every key and certificate, and write the compromised-key procedure.
- Put encryption requirements and key ownership into critical supplier contracts.
- Inventory where you rely on public-key cryptography, ahead of the post-quantum transition.
- Measure encryption coverage and report it to management at planned intervals.
Sources
- Directive (EU) 2022/2555 (NIS2), Articles 2, 3, 5, 20, 21, 23, 25, 26, 32, 33 and 43 and recitals 95, 98, 99 and 104, EUR-Lex.
- Commission Implementing Regulation (EU) 2024/2690, Annex, points 6.7.2 and 9, EUR-Lex.
- Directive (EU) 2018/1972 (European Electronic Communications Code), EUR-Lex.
- Commission Recommendation (EU) 2024/1101 of 11 April 2024 on a Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography, EUR-Lex.
- A Coordinated Implementation Roadmap for the transition to Post-Quantum Cryptography, 23 June 2025, European Commission.
- European Commission, “EU reinforces its cybersecurity with post-quantum cryptography”, 23 June 2025, European Commission.
- Regulation (EU) 2016/679 (GDPR), Articles 32 and 34, EUR-Lex.
- ISO/IEC 27001:2022, Annex A control 8.24, ISO.
Frequently asked questions
Does NIS2 require encryption?
Not everywhere. Article 21(2)(h) requires policies and procedures regarding the use of cryptography and, where appropriate, encryption. Every essential and important entity needs the policy; where to encrypt follows from its risk assessment.
What does NIS2 say about end-to-end encryption?
Recital 98 says end-to-end encryption should be promoted and, where necessary, should be mandatory for providers of public electronic communications networks or services. It adds that reconciling it with Member States' public security and criminal investigation powers should not weaken end-to-end encryption.
What must a NIS2 cryptography policy contain?
For cloud, data centre, managed service and other listed digital providers, Implementing Regulation (EU) 2024/2690 requires the policy to set the type and strength of cryptographic measures by asset class, the approved protocols and algorithms, the approach to key management, and reviews at planned intervals. Other entities can use the same structure as a benchmark.
Does NIS2 require post-quantum cryptography?
No. The EU post-quantum plan is a Commission Recommendation and a coordinated roadmap addressed to Member States. It says Member States should start transitioning by the end of 2026 and critical infrastructure should be transitioned no later than the end of 2030.
