Cryptographic Inventory for NIS2: Annex 9 Never Says ‘Inventory’ — the 12 Fields That Make 9.2 Auditable and Start Your PQC Migration

Short answer: no NIS2 text requires a document called a “cryptographic inventory”. We counted: the word “inventory” appears zero times in the NIS2 Directive and zero times in chapter 9, the cryptography chapter, of Implementing Regulation (EU) 2024/2690. But point 9.2 of that regulation asks you to set crypto measures per asset classification, to name the algorithms “approved and required for use”, and to manage keys through their lifecycle. None of that can be shown to an auditor without a list of where cryptography actually runs. The EU’s post-quantum roadmap fills the gap: it defines a cryptographic inventory as “a structured overview of cryptographic assets” and calls building one the first essential step for every entity. Below are the 12 fields that list needs, each traced to a clause, and how the sheet joins the asset inventory you keep under point 12.4.

One disclosure: we sell NIS2 templates, including a cryptographic controls policy. Every legal statement here is sourced to the Official Journal, ENISA or the NIS Cooperation Group.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Does this apply to you? Scope first

In plain terms: every NIS2 entity needs a cryptography policy. Eleven types of digital-sector entity are bound by the detailed Annex wording. Banks and other financial entities under DORA face an explicit certificate-register duty.

Article 21(2)(h) of the NIS2 Directive requires “policies and procedures regarding the use of cryptography and, where appropriate, encryption”. Article 21(1) asks that measures take into account “the state-of-the-art”. The detail sits in Implementing Regulation (EU) 2024/2690 (the CIR), but its Article 1 limits the Annex to a named list of entity types.

Your organisation	Binding text	Inventory duty in the text?
DNS provider, TLD registry, cloud, data centre, CDN, managed service provider, managed security service provider, online marketplace, search engine, social network, trust service provider	CIR Annex points 9.1–9.3 and 12.4 apply directly	An asset inventory, yes (12.4.1). A cryptographic one, no; it is implied by 9.2
Any other essential or important entity (energy, health, transport, manufacturing and so on)	Article 21(2)(h) as transposed into national law	No. The CIR Annex is the most detailed reference point auditors use
Financial entity under DORA	Delegated Regulation (EU) 2024/1774, Articles 6 and 7	Yes, for certificates: a register of “all certificates and certificate-storing devices”

What the law says, word by word

In plain terms: chapter 9 tells you what your cryptography policy must decide. It never tells you to list where cryptography is used. That list is the evidence the decisions depend on.

Here is our word count over the official texts:

Text	“inventory”	“quantum”	What it does say
NIS2 Directive 2022/2555	0	0	Cryptography policies and procedures, Art. 21(2)(h)
CIR 2024/2690, chapter 9	0	0	Measures per classification, approved algorithms, key management
CIR 2024/2690, point 12.4 and Recitals 25–26	9	0	A “complete, accurate, up-to-date and consistent inventory” of assets
ENISA guidance v1.0, chapter 9	0	1	“future-proofing by considering quantum cryptographic algorithms”
DORA RTS 2024/1774, Art. 7(4)	explicit register		Certificates and certificate-storing devices, kept up to date
EU PQC roadmap v1.1	defines the term		Recommends CBOM as a standardised format

Now read point 9.2 with an auditor’s question in mind. Point 9.2(a) requires “the type, strength and quality of the cryptographic measures required to protect the relevant entities’ assets, including data at rest and data in transit”, set “in accordance with the relevant entities’ classification of assets”. Point 9.2(b) requires the protocols, algorithms and “cipher strength” that are “approved and required for use”, following “where appropriate, a cryptographic agility approach”. Point 9.2(c)(xii) requires activation and deactivation dates for keys.

Each of those is a rule, and an auditor will ask whether it is applied. You can’t answer for 9.2(a) without knowing which assets use which crypto, or show the 9.2(b) approved list is enforced without a record of what is running, or evidence key dates without a record of the keys. The inventory joins policy to reality. That is an inference from the text, not a quoted duty: treat it as the strongest evidence for 9.2, not a requirement in its own right.

Note the qualifiers. Agility in 9.2(b) and every key-management method in 9.2(c) carry “where appropriate”. Under CIR Article 2(2), if you decide one does not apply, you “shall in a comprehensible manner document [your] reasoning”. Point 9.2(a) carries no qualifier at all.

The 12 fields of a NIS2 cryptographic inventory

In plain terms: one row per place cryptography is used, not one row per asset. Each column answers a question an auditor or a migration planner will ask.

The example values follow one asset: a customer portal web server.

#	Field	Example value	Why it’s there
1	Asset ID	AST-0142 (portal web server)	The key to your 12.4 inventory; Recital 26 lists “a unique identifier”
2	Service supported	Online ordering	12.4.2(a) lists “operations and services”; drives priority
3	Classification of protected data	Confidential; integrity high	9.2(a) sets measures “in accordance with” classification (12.1.2(b))
4	Cryptographic purpose	Data in transit, external	9.2(a) “data at rest and data in transit”; 9.1 confidentiality, authenticity, integrity
5	Protocol and version	TLS 1.3, TLS 1.2 fallback on	9.2(b) “protocols or families of protocols”
6	Algorithm and strength	ECDHE P-256; RSA-2048 certificate; AES-128-GCM	9.2(b) “cryptographic algorithms, cipher strength”
7	Implementation and provider	OpenSSL 3.x via web server; TLS ends at cloud load balancer	9.2(b) “cryptographic solutions”; tells you who can change it
8	Key or certificate reference and custodian	Certificate serial; private key held in cloud KMS; platform team lead	9.2(c)(ii) and (iv); Recital 26 “person responsible for protecting”
9	Lifecycle dates	Active from 2026-04-01; expires 2026-10-18; last rotated 2026-04-01	9.2(c)(v) and (xii) activation and deactivation dates
10	Policy status	Approved / deprecated (exception EX-07, review date)	9.2(b) “approved and required for use”
11	Quantum exposure	Quantum-vulnerable key exchange; confidentiality need under 10 years: medium	EU PQC roadmap section 5 risk levels
12	Agility and migration route	Configuration change / vendor update / replacement; owner; target date	9.2(b) agility “where appropriate”; roadmap dependency maps

Two things the sheet must never hold. First, key material: field 8 records where a key lives and who guards it, never the key itself, or the sheet undermines your 9.2(c)(iv) rules on how “authorised users obtain access to keys”. Second, guesses. If you don’t know which library a vendor appliance uses, write “unknown, vendor asked on [date]”. The CISA, NSA and NIST quantum-readiness factsheet warns that discovery tools “may not be able to identify embedded cryptography used internally within products” and tells organisations to ask vendors for those lists.

How it plugs into your 12.4 asset inventory

In plain terms: keep the cryptographic inventory as a separate sheet linked by asset ID. Don’t add crypto columns to the asset register.

The reason is cardinality. Our portal server alone has a TLS certificate, an SSH host key, an encrypted disk and a backup encryption key, each with its own algorithm, custodian and expiry. Squeezed into one asset row, that becomes four sets of columns or a cell nobody can filter. A separate sheet joined on field 1 stays sortable by expiry, deprecated algorithm or quantum exposure.

The 12.4 rules then carry over. Point 12.4.1 requires you to “record changes to the entries in the inventory in a traceable manner”, and 12.4.3 requires you to “document the history of changes”. Apply both to the crypto sheet: a change log tab, or version history in the tool that holds it. Point 12.4.2 sets the asset inventory’s granularity “at a level appropriate for the needs of the relevant entities”. No clause mandates the crypto sheet itself, so starting with high-classification assets and widening from there is a defensible choice.

ENISA’s suggested fields for 12.4.2 include “relation to other assets” but no cryptographic attribute. The asset list says what exists; the crypto sheet says how each item is protected. Our asset management guide covers building the 12.4 inventory itself.

Linking the inventory to the key lifecycle

In plain terms: the inventory records the state of each key and certificate. The 9.2(c) procedures describe how you change that state. You need both, and the table shows which is which.

9.2(c) method	What the inventory adds
(ii) issuing and obtaining public key certificates	Records it: certificate reference and issuing CA (field 8)
(iv) storing keys and access to them	Records it: storage location and custodian (field 8)
(v) changing or updating keys, “when and how”	Records it: last rotation and next due date (field 9)
(xii) activation and deactivation dates	Records it directly (field 9)
(vi) dealing with compromised keys; (vii) revoking keys	Supports it: lists every usage of a key or CA so revocation reaches all of them
(xi) logging and auditing key management activities	Supports it: the change history required by 12.4.1 and 12.4.3
(i) generating, (iii) distributing, (viii) recovering, (ix) backing up, (x) destroying	Procedure only: the inventory shows the result, not the method

Field 8 earns its keep in an incident. If a certificate authority you rely on is compromised, “where do we use its certificates?” becomes a filter, not a memory test. If your keys and certificates already live in a secrets manager or PKI, export from it rather than retyping: our HashiCorp Vault compliance guide maps its PKI and Transit engines to 9.2(c). The full chapter 9 control set is in our hub guide to NIS2 cryptography and encryption obligations.

The post-quantum layer: what the EU roadmap actually asks

In plain terms: the roadmap is not law and is addressed to Member States. It is still the clearest official statement of what a cryptographic inventory is for.

The NIS Cooperation Group published A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography (Part 1, version 1.1) in June 2025. Under its First Steps it says: “A first essential step and ‘no-regret’ move for every entity is to create and maintain current inventories of assets that perform cryptographic operations and of assets that have cryptographic operations performed on them as part of asset management.” It adds: “Using a standardised format for a cryptographic inventory, like CBOM (Cryptographic Bill of Materials, an extension of the SBOM standard), is recommended.” It also notes that “some regulatory requirements on keeping cryptographic inventories already exist”. It doesn’t name them; DORA’s certificate register is one example.

Its timeline: First Steps and national roadmaps by 31 December 2026, high-risk use cases migrated by the end of 2030, medium-risk by the end of 2035. These dates appear nowhere in the NIS2 Directive or in the Commission’s 2026 amendment proposal, a point we cover in our NIS2 review 2026 analysis.

Field 11 applies the roadmap’s own risk rules to data protected by today’s public-key cryptography:

• Confidentiality must be protected: quantum risk is medium or high.
• Confidentiality must last at least 10 years, and a later breach would still do significant damage: high. Attackers can record traffic now and decrypt it later.
• Migration would take more than 8 years: medium or high.
• High migration effort plus high impact, such as signing software updates: high.

Field 12 records each row’s agility. A protocol switched by configuration is a short job; cryptography fixed in vendor firmware waits on the vendor. Another of the roadmap’s First Steps, “Include the supply chain”, starts with that dialogue.

On format: CBOM is part of CycloneDX from version 1.6, per the OWASP CycloneDX guide to CBOM. It models algorithms, certificates, protocols and related material such as keys, and separates a library that “provides” an algorithm from an application that “uses” it. In practice, a spreadsheet works while one team can keep it current by hand; once discovery is automated across code, pipelines and binaries, a machine-readable CBOM pays off. The 12 fields map onto either.

Once field 11 is filled, the next question is which dates to plan against and how an auditor can raise them. Our guide to post-quantum cryptography under NIS2 traces how CIR points 9.2(b) and 9.3 bring the roadmap’s 2030 and 2035 milestones into a policy review, and why the EU’s two definitions of crypto-agility differ.

Build it in five steps

1. Pull the asset list and classification levels (effort: Low). Export asset IDs, services and classification from your 12.4 inventory and 12.1 scheme. Fields 1–3 come from here.
2. Cover external endpoints and certificates (Low to Medium). Scan every public hostname for protocol, cipher suite and certificate. That fills fields 4–6, 8 and 9 for your most exposed rows.
3. Export from key stores (Medium). Pull keys and certificates from your KMS, HSM, PKI or secrets manager, with custodians and dates.
4. Find embedded and in-code cryptography (High). Use dependency or CBOM scanning in your pipelines. Send vendors a written request for the cryptography in their products, as the CISA factsheet advises.
5. Score and feed risk management (Medium). Mark policy status, quantum exposure and agility (fields 10–12). Pass high-risk rows into the risk assessment under point 2.1, which 9.1 names as an input.

Review cadence: the CIR sets none. Point 12.4.3 says “regularly”, and 9.3 says “at planned intervals, taking into account the state of the art in cryptography”. Pick an interval, write it into the policy and add triggers: a new system, a deprecated algorithm, a compromised CA.

Role	What they own
SME owner / non-technical lead	Start with steps 1–3 for high-classification assets only. A 30-row sheet covering public TLS, VPN and backup keys beats an empty project plan.
CISO / IT security	Steps 2–5, the approved-algorithm list behind field 10 and the CBOM tooling decision.
Compliance officer	Traceability (12.4.1, 12.4.3), the written Article 2(2) reasoning for skipped “where appropriate” items, audit evidence packs.
Board / management body	Approves the risk treatment for high quantum-exposure rows; the roadmap wants the quantum threat in top-level risk management so it is “discussed and evaluated at the board level”.

Frequently asked questions

Does NIS2 require a cryptographic inventory?

Not by name; the Directive and CIR chapter 9 never use the word. Point 12.4 requires an asset inventory, and the rules in 9.2 can only be evidenced by knowing where cryptography runs.

Is a certificate list enough?

It covers fields 8 and 9 for one asset type. It misses symmetric keys, disk and backup encryption, SSH keys, protocols and vendor-embedded cryptography. DORA’s register duty is limited to certificates and certificate-storing devices; the EU PQC roadmap asks for more.

Do we have to use the CBOM format?

No. The roadmap recommends a standardised format like CBOM; nothing in NIS2 or the CIR prescribes one. A well-kept spreadsheet with the 12 fields is valid evidence.

Are the 2030 and 2035 post-quantum dates binding on NIS2 entities?

No. They come from the NIS Cooperation Group roadmap, which is addressed to Member States and is not a legal act. National authorities may adopt them in guidance or law, so check your Member State. In NIS2 itself, the binding hook today is Article 21(1)’s “state-of-the-art” test.

Sources

1. Directive (EU) 2022/2555 (NIS2 Directive) — EUR-Lex. Articles 21(1) and 21(2)(h).
2. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — EUR-Lex, Official Journal text. Articles 1 and 2(2); Recitals 25–26; Annex points 2.1, 9.1–9.3, 12.1.2 and 12.4.1–12.4.3.
3. Commission Delegated Regulation (EU) 2024/1774 (DORA RTS on the ICT risk management framework) — EUR-Lex. Articles 6 and 7(4).
4. Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0 — ENISA, June 2025. Guidance under Annex points 9.1–9.2 and 12.4.2.
5. A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography, Part 1, version 1.1 — NIS Cooperation Group, EU PQC Workstream, June 2025. Sections 3.2, 4, 5 and 6.2.
6. Quantum-Readiness: Migration to Post-Quantum Cryptography — CISA, NSA and NIST, August 2023.
7. Authoritative Guide to CBOM, second edition — OWASP CycloneDX, October 2025.