Cryptography under NIS2: policy, keys, inventory

This guide shows what belongs in the policy, how to build the inventory, how to handle plants without encryption and what the move to post-quantum cryptography means for your planning today. The examples are invented.

What the law requires

§ 30(2) no. 8 BSIG (German BSI Act) lists "concepts and processes for the use of cryptographic methods" as a minimum measure. Its model is Art. 21(2)(h) NIS2 Directive, which adds "where appropriate, encryption". § 30(2) sentence 1 BSIG applies to all measures: they should follow the state of the art.

Implementing Regulation (EU) 2024/2690 goes into more detail. It takes precedence for certain types of digital entities, such as cloud providers and managed service providers (§ 30(3) BSIG). Its Annex, point 9, is a good outline for everyone else as well:

Policy and procedures in line with the classification of assets and the risk assessment.
Type and strength of the measures for stored data and data in transit.
Approved protocols and algorithms, where appropriate following a crypto-agility approach.
Key management across the whole life cycle: generation, certificates, distribution, storage, change, handling of compromised keys, revocation, recovery, backup, destruction, logging and activation periods.
Review at planned intervals, taking the state of the art into account.

The common standards have their own requirement too: ISO/IEC 27001 in Annex A 8.24 on the use of cryptography, IEC 62443-3-3 in system requirement SR 4.3.

BSI TR-02102 as the yardstick

In Germany, what "state of the art" means for methods and key lengths is described in the BSI Technical Guideline TR-02102, "Cryptographic Mechanisms: Recommendations and Key Lengths". It is free on the BSI website and has a general part plus parts on TLS, IPsec and SSH. The BSI updates it regularly. So refer to the current version in your policy, and check with every new version whether your approved methods still fit.

Do not copy figures from blog posts or old templates. The wording of the current TR-02102 is what counts.

What belongs in the cryptography policy

A policy that works in daily practice is short and answers six questions:

Areas of use: Where do you protect data with cryptography? Transmission, storage, signatures, authentication.
Allowed methods: Which protocols, algorithms and minimum lengths apply, with a reference to TR-02102, and which are explicitly not allowed?
Keys and certificates: Who generates, stores, distributes, renews and revokes? Where are recovery keys kept?
Responsibilities: Who owns the policy, and who owns each area?
Exceptions: How is a deviation requested, justified, compensated, time-limited and approved?
Review: When do you review the policy, regularly and also when a new version of TR-02102 appears?

Where cryptography sits in your company

The inventory starts with a simple question: where do we rely on encryption or signatures today? The table helps you collect it.

Area	Typical examples	Common gap	Usually owned by
Data in transit	Websites, email transport, VPN, remote maintenance	Expired certificates, old TLS versions	IT operations
Data at rest	Laptops, servers, backups, cloud storage	Unencrypted backups, recovery keys nowhere to be found	IT operations
Signatures	Code signing, documents, email	Signing keys without an agreed storage location	Development
Authentication	Certificates, smart cards, FIDO2 keys	No revocation process on loss	IT security
OT	Machine remote maintenance, links between zones, engineering	Protocols without encryption, no documented exception	Control engineering

For each entry, record the purpose, method, key length, where the key is stored, expiry or rotation interval and an owner. Key material itself never goes into the inventory, only its description.

Cryptography in OT

In production plants you quickly hit limits. Many fieldbus protocols such as Modbus/TCP and older controller communication have no encryption in the form in common use. An update is often not available, and extra latency can disturb control loops.

Compensate instead of forcing it: Keep unencrypted traffic inside one zone and encrypt the transitions, for example with a tunnel between zones.
Plan new plants better: Newer controller generations offer secure protocol variants such as OPC UA with security turned on. Put that into your specifications.
Remote maintenance first: Connections from outside into the plant are the most important place for strong encryption and mutual authentication.
Document exceptions: system, deviation, reason, compensating measure, time limit and approval.

Post-quantum cryptography: plan today

Powerful quantum computers could break public-key methods in wide use today, such as RSA and elliptic curves. Nobody knows reliably when that will happen. For data that must stay confidential for a long time, one point already matters today: whoever records encrypted data now can decrypt it later.

A broad migration only works if you know where which methods run. That makes the inventory the first step. For each entry, note whether the method is ready for post-quantum cryptography, planned or unknown. TR-02102 now also covers post-quantum methods. The Implementing Regulation names crypto-agility, the ability to swap methods without major rework, explicitly. Ask your suppliers for it in new systems.

Example from machine building

The example is invented. A maker of packaging machines with 400 staff is an important entity under the BSIG. So far there was a spreadsheet with 20 certificates, kept by one person.

Stocktake: Reading web servers, VPN and certificate stores turns up 64 certificates. Two expire within the next three weeks, one of them on the portal for remote maintenance of customer machines.
Weak spots: An internal server still offers TLS 1.0, and one old certificate is signed with SHA-1.
OT: The warehouse system speaks Modbus/TCP. The traffic stays in its zone, and the transition runs through an encrypted tunnel. The exception is time-limited and approved by the information security officer.
Afterwards: Every renewal has an owner, and the policy is reviewed every year and with every new TR-02102.

Checklist

The cryptography policy is adopted and names owners.
Allowed and disallowed methods are set, with a reference to the current TR-02102.
All areas of use are covered: transmission, storage, signatures, authentication, OT.
Every certificate has an owner and a warning before expiry.
Recovery keys are stored centrally and separately from the devices.
Backups are encrypted, and the key is reachable in an emergency.
There is a procedure for compromised and lost keys.
OT exceptions are justified, compensated, time-limited and approved.
Post-quantum readiness is noted for each method.
A date for the next review is set.

Cryptography in Complass

Certificates in a spreadsheet go stale quietly, and the expiry warning depends on one person and their calendar. In Complass, policy and inventory work together:

Policy from the template: The NIS2 module includes the template "Cryptography policy" with areas of use, allowed methods, key management, OT specifics, exceptions with time limit and approval, and the date of the last review.
Certificate inventory: You see every certificate with issuer, key, expiry and locations, with quick filters and a timeline of the next 90 days.
Many sources: The domain check takes over the certificates of your own domains. You import others as a certificate file, nmap XML, testssl.sh JSON or CSV, or read them with the collector script from Windows and Linux certificate stores.
Warnings: The owner gets an email before expiry, by default 30, 14 and 7 days ahead.
Weak methods: Complass points out keys that are too short, SHA-1 and old TLS versions. You set the limits yourself.
Other keys: You record VPN, disk encryption or code signing with storage location, rotation interval and post-quantum readiness.

Only public certificate data and descriptions are stored, never private keys.

Certificate inventory of the demo company with expiry, issuer, location and notes on weak methods — Certificates and cryptography: expiry, locations and weak methods at a glance.

Frequently asked questions

Do we have to encrypt everything?

No. The law requires policies and processes, not encryption at any cost. You decide based on protection needs and risk, and where encryption is not possible, you document the exception and the compensating measure.

Is TR-02102 mandatory?

The BSIG requires the state of the art but names no specific guideline. In Germany, TR-02102 is the usual yardstick for it. If you deviate from it, give your reasons.

How often do we review the policy?

The Implementing Regulation requires a review at planned intervals. A yearly date works well, plus an extra review when a new version of TR-02102 appears or a method is no longer considered secure.

Do we have to move to post-quantum methods now?

The BSIG names no general duty to switch. What makes sense today: build the inventory, note readiness for each method, ask for crypto-agility in new systems and look first at data that needs protection for a long time.

Do keys belong in the inventory?

No, only their description: purpose, method, length, storage location, rotation interval and owner. The key material stays in the key store.

In a demo we use the demo company to show you how a certificate spreadsheet turns into an inventory with warnings and a reviewed policy.

Request a demo Try it for 14 days

Not legal advice. This guide gives a general overview and does not replace an assessment of the individual case. The current wording of the BSIG and of Implementing Regulation (EU) 2024/2690, the current version of BSI TR-02102 and your licensed editions of the standards are authoritative. As of November 2026.