How should security leaders build a cryptography strategy to meet NIS2 requirements?

Security leaders should treat NIS2 cryptography as a governed programme, not a single control. Start with a documented policy that defines approved algorithms, key lengths, deprecation triggers, and key lifecycle rules. Then enforce encryption in transit and at rest, maintain certificate and key inventories, assess suppliers, and keep evidence ready for supervisory review. Management sign-off is part of the control model, not an afterthought.

What NIS2 expects from a cryptography strategy

NIS2 does not treat cryptography as a one-time technical setting. For security leaders, the real requirement is to show that encryption, key management, and crypto decisions are governed, repeatable, and reviewable. That means the strategy must define what is approved, how exceptions are handled, when algorithms are retired, and who approves changes. It also needs to align with operational reality across endpoints, applications, cloud services, and suppliers.

The official NIS2 legal text is the right reference point for understanding the directive’s emphasis on risk management and security governance, including measures that protect confidentiality, integrity, and resilience. NIS2 Directive — official EU legal text The practical mistake many organisations make is treating cryptography as an infrastructure task owned only by platform teams, when supervisory scrutiny usually focuses on accountability, evidence, and consistency across the business. In practice, many security teams discover weak crypto governance only when they have to prove what is protected, by which standard, and under whose approval.

How to design the strategy so it survives implementation

A workable strategy starts with policy, but it only becomes credible when policy is tied to inventory, enforcement, and review. Security leaders should define approved cryptographic standards for data in transit and at rest, then make sure those standards are translated into build patterns, procurement requirements, and exception handling. The strategy should also address key generation, storage, rotation, backup, revocation, and destruction, because weak lifecycle control can undermine strong algorithms.

In practice, the best programmes distinguish between policy intent and control operation. That means maintaining visibility over where cryptography is used, which certificates are expiring, which services rely on legacy protocols, and which suppliers terminate or process protected data on the organisation’s behalf. It also means deciding which teams own remediation when crypto is embedded in application code, managed services, or third-party products. For NIS2, that ownership question matters as much as the technical standard itself.

Define approved algorithms, key lengths, and protocol baselines for each system class.
Keep a live inventory of certificates, keys, and crypto-dependent services.
Require exceptions to be time-bound, documented, and reviewed by management.
Test supplier assurances against the organisation’s own minimum crypto policy.
Retire weak or deprecated cryptography before it becomes a compliance or incident issue.

Where this guidance breaks down is in environments with unmanaged legacy systems, embedded devices, or third-party platforms that cannot be upgraded without service disruption.

Where crypto strategy becomes fragile in real organisations

Tighter cryptographic governance often increases operational overhead, so organisations need to balance standardisation against legacy compatibility and service continuity. That tradeoff becomes visible when an otherwise sound policy collides with old applications, external integrations, or supplier-managed components that cannot easily adopt modern controls.

One common variation is the difference between defining cryptographic standards and proving they are actually enforced. Guidance and consensus are aligned that written policy alone is not enough, but organisations still disagree on how much central enforcement is realistic in federated or cloud-heavy estates. A second edge case is encryption key ownership in shared platforms: the buyer may retain accountability under NIS2 even when the provider operates the control. Another is certificate sprawl, where service proliferation creates more governance risk than weak algorithms themselves. The operational lesson is that the strategy should prioritise visibility and lifecycle control, not just stronger primitives.

Security leaders should also expect audit questions about evidence quality. If the organisation cannot show inventories, approval records, exception expiry dates, and supplier review artefacts, the crypto programme will look immature even if the technical controls are mostly sound.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST CSF 2.0 set the technical controls, while NIS2 and EU Cyber Resilience Act define the regulatory obligations.

Framework	Control / Reference	Relevance
NIS2	Art. 21(2)(a) — Policies on risk analysis and information system security	NIS2 requires governed security measures, including cryptography decisions and accountability.
	Art. 21(2)(d) — Supply chain security	Crypto strategy must cover suppliers, managed services, and third-party dependencies.
	Art. 21(2)(f) — Basic cyber hygiene and training	Operational crypto hygiene depends on staff following lifecycle and handling rules.
Recommendation — Document and approve cryptographic policy, lifecycle rules, and exceptions under formal management oversight. Assess supplier cryptographic assurances and contractually enforce minimum crypto requirements. Train operational teams to manage keys, certificates, and crypto exceptions consistently.
CIS Controls v8	04 — Secure Configuration of Enterprise Assets and Software	Cryptography strategy needs enforced secure baselines across systems and software.
	05 — Account Management	Key and certificate ownership is an access-governance problem as well as a crypto one.
	08 — Audit Log Management	NIS2-readiness depends on evidence of crypto governance, approvals, and exception handling.
Recommendation — Standardise approved crypto settings and remove weak protocols from enterprise baselines. Assign clear owners for keys, certificates, and crypto exceptions across services. Retain logs and records that prove crypto policy enforcement and exception review.
NIST CSF 2.0	PR.DS-1 — Data-at-rest protection	The strategy must ensure protected data is encrypted where stored and processed.
	PR.DS-2 — Data-in-transit protection	NIS2-aligned crypto strategy must cover transport protection and protocol hygiene.
	GV.RM-03 — Risk management strategy	Crypto choices should be governed as part of enterprise risk decisions, not ad hoc fixes.
Recommendation — Apply encryption standards to data at rest across systems handling sensitive information. Enforce protected transport for services, integrations, and supplier connections. Tie cryptography decisions to documented risk acceptance and management approval.
EU Cyber Resilience Act	V.1 — Security properties of products	Crypto posture depends on products supporting secure defaults and maintainable protection.
Recommendation — Prefer products that support modern cryptography and secure configuration by design.

Practitioner Guidance

What to prioritise: Build the strategy around control ownership and evidence first, because cryptography without clear accountability is hard to defend under supervisory review. The first mature sign is not algorithm choice, but whether the organisation can explain who approves crypto standards, who tracks exceptions, and who remediates drift.

What to verify: Verify that encryption requirements are implemented consistently across applications, not just in core infrastructure. Check for legacy protocols, unmanaged certificates, shadow services, and supplier-operated components that sit outside normal change control.

Decision rule: If a system cannot meet the approved standard, treat it as a managed exception with an expiry date, not as a permanent workaround. If the exception is business-critical and long-lived, escalate it as a governance issue rather than leaving it as a technical accommodation.

Practitioner takeaway: The strongest NIS2 cryptography programmes are the ones that can prove control over lifecycle, ownership, and exceptions, not just the ones that use modern encryption by default.