Skip to main content
NIS2Certify
Back to overview

NIS2 Cryptography Requirements: Why "We Have Encryption" Fails Article 21(2)(h)

By NIS2Certify
NIS2cryptographyArticle 21encryptionpost-quantumMSP
NIS2 Cryptography Requirements: Why "We Have Encryption" Fails Article 21(2)(h)

An MSP I know passed twelve of the thirteen requirement domains in a client's NIS2 readiness review. The one they failed was cryptography. Not because the client lacked encryption — TLS was everywhere, laptops were BitLocker'd, backups were AES-256. They failed because when the auditor asked "show me your cryptographic policy," nobody could produce a document. "We have encryption" was true. It also wasn't the question.

This is the trap in NIS2 Article 21(2)(h). Encryption is a control you deploy. Cryptography, under NIS2, is a policy you have to govern, document, and prove. The two are not the same thing, and the gap between them is exactly where readiness assessments now fall apart.

Article 21(2)(h) Asks for a Policy, Not a Product

Article 21 lists ten baseline risk-management measures every essential and important entity must have. Point (h) reads: "policies and procedures regarding the use of cryptography and, where appropriate, encryption." Read it twice. The obligation is the policy and procedures. Encryption is the thing the policy governs — and even that is qualified with "where appropriate."

That wording matters for how you advise clients. A control-first mindset asks "is the data encrypted?" A NIS2 mindset asks "does a documented policy decide when, where, and how cryptography is applied, and can you show it was followed?" Most organisations can answer the first question and fall silent on the second.

Cryptography sits alongside the other nine measures, and it's one teams consistently underestimate because it feels like a solved problem. It isn't. It's a governance problem wearing a technical costume.

Article 21 — 10 NIS2 Cybersecurity Measures
Article 21
10 Cybersecurity Measures
Governance & Strategy
1Risk analysis & information security policies
6Effectiveness assessment of security measures
Incident & Continuity
2Incident handling & notification
3Business continuity & disaster recovery
Supply Chain & Systems
4Supply chain security
5Security in network & information systems development
Technical Controls
8Cryptography & encryption
10Multi-factor authentication & secure communications
People & Assets
7Cyber hygiene & training
9HR security & access control

What "We Have Encryption" Is Missing

A NIS2-grade cryptographic policy covers five things a raw deployment does not.

Algorithm selection. Which algorithms are approved, which are deprecated, which are banned. "AES-256 and TLS 1.2+" is a start; a policy also names what's forbidden and who signs off on exceptions.

Key management. Generation, storage, rotation, and destruction. This is where most environments are weakest — keys living in config files, no rotation schedule, no record of who can reach the key vault.

Encryption scope. What must be encrypted at rest, in transit, and — increasingly — in use. Databases, file systems, backups, removable media, internal service-to-service traffic. The policy defines the boundary; the boundary is auditable.

Certificate management. Issuance, monitoring, renewal. An expired internal certificate is both an outage and a finding.

Crypto-agility. The ability to swap an algorithm quickly when it's deprecated or broken — without re-architecting. This used to be a nice-to-have. The EU has now put a clock on it.

If you run compliance for clients, this is the same discipline you already apply to multi-factor authentication and backups: the control is the easy part, the documented, tested, evidenced process is the deliverable.

CIR 2024/2690 Turned the Guidance Into a Rule

Here's what changed the stakes. Commission Implementing Regulation (EU) 2024/2690, in force since November 2024, spells out the technical measures behind Article 21 for the digital infrastructure sector — and it applies directly in all 27 member states. No national transposition, no waiting for your country's law. If it covers you, it already binds you.

The regulation's annex has thirteen requirement domains, and cryptography is one of them. It explicitly demands a cryptographic policy based on state-of-the-art practice, cryptographic agility mechanisms enabling rapid algorithm replacement, and alignment with recognised standards such as ISO/IEC 27001 and the relevant ENISA and ETSI guidance.

The scope question is the one to settle first with every client. CIR 2024/2690 reaches DNS providers, TLD registries, cloud computing providers, CDNs, data centre services, managed service providers, managed security service providers, online marketplaces, search engines, social networks, and trust service providers. If you're an MSP, note that you are on that list — you carry these obligations for your own operations, not just your clients'.

Does NIS2 Apply to Your Organisation?
1
Does your organisation operate in an essential or important sector (energy, transport, health, digital infrastructure, etc.)?
Yes ↓No →
2
Does your organisation have 50 or more employees, or an annual turnover exceeding €10 million?
Yes ↓No →
3
Is your organisation a critical infrastructure provider or a qualified trust service provider?
Yes ↓No →
✗
NIS2 does not directly apply to your organisation.
✓
NIS2 applies to your organisation as an Essential or Important Entity.
!
NIS2 may apply to your organisation — seek legal advice to confirm your status.
Applies
Possibly applies
Does not apply

The Quantum Clock Is Now a Compliance Deadline

Crypto-agility stopped being theoretical in 2026. The NIS Cooperation Group published a Coordinated Implementation Roadmap for the transition to post-quantum cryptography, and it sets hard milestones that connect directly to your NIS2 obligations.

End of 2026 — member states initiate a national post-quantum transition strategy and coordinate at EU level.

End of 2030 — high-risk use cases should be migrated to post-quantum cryptography, no later than this date.

2035 — the transition completed for as many systems as practically feasible.

The mechanism that ties this back to Article 21(2)(h) is crypto-agility. You cannot migrate to quantum-resistant algorithms in 2030 if your systems have RSA and ECC hard-wired into applications with no upgrade path. The "state-of-the-art" test that auditors apply to a cryptographic policy today already reads the roadmap as context — which means a policy with no crypto-agility provision is arguably not state-of-the-art in 2026.

For clients this is not a 2030 problem. It's a 2026 documentation problem: your cryptographic policy needs a post-quantum readiness clause and an inventory of where your current algorithms live. The organisations treating "harvest now, decrypt later" as a real threat — adversaries capturing encrypted traffic today to break it once quantum computing matures — are building that inventory now.

What an Auditor Will Actually Ask For

Readiness assessments don't test whether you own encryption software. They test whether you can produce evidence. For cryptography, expect to be asked for the written cryptographic policy with a named owner and review date; an inventory of algorithms and protocols in use across systems; a key management procedure covering the full lifecycle; a certificate inventory with expiry tracking; and evidence that the policy is enforced, not just filed.

That last point is where the "assess effectiveness" discipline meets cryptography — the same effectiveness testing that Article 21(2)(f) demands applies here. A policy nobody checks against reality is a finding waiting to happen.

Failing This Measure Doesn't Stay Contained

The reason cryptography deserves attention out of proportion to its single line in Article 21 is that a gap here cascades. A weak cryptographic posture is not one isolated finding — it undermines your incident-handling claims (breached data was supposedly protected), your supply-chain assurances (you asked vendors for controls you can't demonstrate yourself), and your board's personal liability position, because signing off on a compliance posture you can't evidence is exactly the exposure NIS2 created for management.

NIS2 Penalty Escalation — Beyond the Fine
!
Trigger event
Non-Compliance Detected or Incident Occurs
A supervisory authority identifies a compliance gap or an organisation fails to meet NIS2 requirements
Authorities can impose
▼
Non-Monetary Penalties
1
Compliance orders with binding deadlines
2
Mandatory security audits at your expense
3
Public disclosure of violations
4
Binding instructions on specific security measures
Escalates to
▼
Operational & Personal Consequences
1
Suspension of certifications or operating licences
2
Temporary ban on management functions for individuals
3
Public naming of responsible natural persons
Trigger
Non-monetary
Operational / personal

Because CIR 2024/2690 makes these requirements direct-effect for the digital infrastructure sector, "our national law isn't final yet" is not a defence available to the entities it covers. The obligation is live.

What to Do This Quarter

Start with three moves. First, write or refresh the cryptographic policy as a governed document — owner, review cadence, approved and prohibited algorithms, key lifecycle. Second, build the algorithm inventory: you cannot claim crypto-agility for systems you haven't mapped. Third, add the post-quantum clause now, so the 2030 migration is a scheduled project rather than a scramble.

If you're advising clients and want to know where cryptography sits among their other gaps before an auditor does, a structured gap analysis is the fastest way to find out. You can run a free NIS2 readiness assessment at nis2certify.org/quick-scan — it flags exactly the documentation gaps, like an undocumented cryptographic policy, that quietly fail audits.

"We have encryption" was never the finish line. Under Article 21(2)(h) and CIR 2024/2690, the policy is the deliverable — and the quantum clock means the policy you write this year needs to already be looking at 2030.

    NIS2 Cryptography Requirements: Why "We Have Encryption" Fails Article 21(2)(h) — NIS2Certify