NIS2 Article 21(2)(h): What Auditors Accept as Cryptography Evidence

NIS2 Article 21(2)(h) requires “policies and procedures regarding the use of cryptography and, where appropriate, encryption”.

That is the entire text. No algorithms, no key lengths, no protocol versions. Teams preparing for an audit reasonably ask what it means in practice, and the answer comes from two places: the directive’s own “state of the art” language in Article 21(1), and what supervisory authorities have actually asked for.

The recurring audit failure is evidence, not security

The most common finding in 2026 NIS2 assessments is not a missing control. It is a control that exists with nothing to show for it.

A policy document stating “we use industry-standard encryption” is not evidence. It describes an intention. An auditor is looking for something that demonstrates the state of the system on a given date, and ideally something they can reproduce.

This is why external measurement has become the path of least resistance for the transport-layer portion: it produces a dated observation of what your systems actually negotiated, which no policy document can.

What the transport-layer evidence looks like

For the externally observable portion of 21(2)(h), a defensible evidence pack contains the following, each with a timestamp and the raw observation rather than a verdict.

Protocol versions offered. TLS 1.2 minimum, TLS 1.3 supported. TLS 1.0 and 1.1 must be refused, not merely deprioritised. The evidence is a handshake attempt against each version and its outcome.

Cipher suites negotiated. The actual suite chosen, with forward secrecy. A list of what your configuration file permits is weaker evidence than what the server did when asked.

Certificate properties. Issuer, key algorithm and size, signature algorithm, validity window, and increasingly the issued lifetime against the CA/Browser Forum ceiling. Auditors have begun asking how renewal is performed, because a manual process is a resilience finding as well as a cryptography one.

HSTS. Presence, max-age, includeSubDomains, and whether the domain is on the preload list. Without HSTS, the first request of a session is downgradeable, which undercuts everything else in this list.

Mail transport. Whether MTA-STS enforces authenticated TLS for inbound mail. This is where most vendors have a genuine gap, because sender authentication is mistaken for transport encryption.

Key agreement. Whether post-quantum hybrid key exchange is offered. Not yet a requirement, increasingly a question, and directly relevant to the “state of the art” language.

What “state of the art” does and does not mean

Article 21(1) requires measures appropriate to the risk, taking into account the state of the art and the cost of implementation.

Two things follow that are worth being precise about.

It is not a requirement to deploy the newest available mechanism. Cost of implementation is explicitly a factor, and proportionality is built into the text.

It is a requirement to know where you stand relative to current practice and to have made a decision. An auditor asking about post-quantum key exchange in 2026 is usually not expecting it to be deployed. They are checking whether you have an answer, because “we had not considered it” and “we assessed it, here is our position, here is the timeline” are different postures under a standard that references the state of the art.

Writing down the decision, including decisions not to act and why, is the cheapest evidence in this entire domain.

What this article does not cover

The externally observable portion is not all of 21(2)(h). Encryption at rest, key management, secrets handling, and internal service-to-service encryption are in scope and cannot be measured from outside.

Being clear about that boundary matters when you present evidence. A vendor who submits an external scan as though it covered the whole clause invites a correction. A vendor who submits it as “the external transport layer portion, measured on this date, with the internal controls documented separately” is easier to assess and reads as more competent.

See what an external scan can and cannot prove for where that line sits.

The mapping other frameworks use

If you are maintaining one evidence set across frameworks, the transport-layer controls land in predictable places:

Framework	Control
NIS2	Article 21(2)(h), with network items under 21(2)(e)
ISO/IEC 27001:2022	A.8.24 use of cryptography, A.8.20 networks security
DORA	Article 9 protection, Article 7 ICT systems and tools
BSI IT-Grundschutz	The relevant technical guideline, TR-03108 for mail

Producing one measurement and mapping it four ways is considerably less work than four assessments, which is the main argument for doing the external layer with a tool that emits the mapping rather than with a spreadsheet.

A practical sequence

1. Measure what you currently present externally. You cannot write a policy about a configuration you have not observed.
2. Fix anything that fails a current baseline: TLS below 1.2, missing HSTS, certificates issued outside the current ceiling.
3. Write the policy to describe what is now true, with the decisions and their rationale.
4. Re-measure on a schedule and keep the dated outputs. A single snapshot proves a moment; a series proves a process, and the process is what Article 21 is actually about.

The short version

21(2)(h) does not name algorithms, so evidence beats assertion.

Dated external measurements of protocol versions, cipher suites, certificates, HSTS and mail transport cover the observable portion. Document the internal portion separately, and write down the decisions you made about what not to deploy yet.