Cryptographic Inventory and PQC Readiness Assessment Guide

A cryptographic inventory is a complete, structured register of every cryptographic algorithm, key, certificate, protocol and library that an organisation uses to protect data, authenticate identities or sign documents. It is not simply a list of certificates due for renewal: it is the operational map that makes a post-quantum cryptography (PQC) migration programme possible, auditable and defensible to regulators. Without it, an organisation cannot know what it must migrate, in what order, or by when.

Why a Cryptographic Inventory Is the Non-Negotiable First Step

No migration roadmap can be built on incomplete data. Before any algorithm can be replaced with a FIPS 203, 204 or 205 equivalent, every instance of the vulnerable algorithm must first be located, catalogued and assessed for business impact.

NIST SP 800-227 (initial public draft, 2025), titled “Recommendations for Key Management,” and the companion document NISTIR 8547 together provide the most authoritative framework for this work. NIST SP 800-227 treats the cryptographic inventory as a prerequisite to any transition planning, specifying that the inventory must capture not only algorithm names and key lengths but also the sensitivity classification of the data being protected and the expected longevity of that data. This matters because data that must remain confidential for thirty years faces a materially different threat model than data that is public after twelve months.

NISTIR 8547 goes further by establishing a formal deprecation timeline: RSA, ECDSA, ECDH and finite-field Diffie-Hellman are designated for deprecation by 2030 in US federal systems. The EU NIS Cooperation Group PQC Roadmap (2025) aligns with this horizon for critical infrastructure in EU member states, making 2030 the effective compliance deadline for European regulated sectors as well.

Automated Discovery Tools for Quantum-Vulnerable Algorithms

Manual inspection alone cannot surface every cryptographic dependency in a complex infrastructure. Automated scanning is the practical starting point, covering network protocols, public certificates, application binaries and configuration files.

Several open-source and commercial tools are designed for this purpose. The NIST National Cybersecurity Center of Excellence (NCCoE) Migration to Post-Quantum Cryptography project has published reference architectures and evaluated tooling capable of scanning TLS handshakes, SSH configurations and X.509 certificate stores for RSA, ECDSA and Diffie-Hellman usage. Tools such as SSLyze and testssl.sh can rapidly enumerate cipher suites on network-facing services. For code-level discovery, static analysis tools including Semgrep with cryptographic rulesets and vendor-specific scanners can identify calls to deprecated algorithm libraries in Java, Python, Go and C/C++ codebases. IBM’s CBOM (Cryptography Bill of Materials) format, developed in the context of the NCCoE project, provides a machine-readable schema for recording discovered algorithms in a way that integrates with software supply chain tooling.

The scale of what automated discovery typically uncovers is significant. According to the NIST NCCoE Migration to Post-Quantum Cryptography project, more than 20,000 public-key certificates using quantum-vulnerable algorithms were identified in early discovery pilots across US federal systems (NCCoE, 2023). European organisations with comparable complexity should plan for similar or greater volume.

Risk-Tiered Prioritisation and the Migration Roadmap

Discovering every cryptographic asset is not the endpoint: the inventory must immediately feed a prioritisation framework that produces a sequenced migration roadmap aligned with the EU 2030 deadline.

Effective tiering combines four variables:

Assets that score high on all four dimensions must move first. A hospital’s patient record system, protected by RSA-2048, retaining records for thirty years, running on a system that requires vendor firmware updates, represents the highest tier. A staff intranet running TLS 1.3 with modern cipher suites and short data retention represents the lowest.

EU NIS Cooperation Group PQC Roadmap and NIS-2 Article 21 Obligations

The EU NIS Cooperation Group PQC Roadmap (2025) is the most direct European policy instrument shaping what member-state entities must document. It requires essential and important entities to produce a written inventory of quantum-vulnerable cryptographic assets, a risk-tiered transition plan with milestones, and evidence that supply chain dependencies have been assessed.

This intersects directly with NIS-2 Article 21, which requires essential and important entities to implement “appropriate and proportionate technical and organisational measures to manage the risks posed to the security of network and information systems.” Cryptographic controls, including the selection of algorithms and key management practices, are explicitly within scope. National competent authorities and ENISA interpret Article 21 as requiring documented evidence of active cryptographic governance, not merely the deployment of currently adequate algorithms. An organisation that cannot produce a cryptographic inventory is unable to demonstrate compliance with this obligation.

NIST has stated that “federal agencies should be prepared to replace all uses of quantum-vulnerable public-key cryptographic algorithms with quantum-resistant alternatives as soon as practical” (NISTIR 8547). European regulators, guided by ENISA and the NIS Cooperation Group, are converging on the same expectation for EU critical infrastructure.

Using the Inventory as Audit Evidence

For compliance officers and data protection officers, the cryptographic inventory is not only an operational tool: it is a regulatory artefact. ENISA’s guidance on cybersecurity audit evidence, national data protection authorities conducting adequacy assessments under GDPR, and financial supervisors reviewing DORA compliance all benefit from a well-maintained, version-controlled cryptographic register.

The inventory functions as audit evidence in three specific ways. First, it demonstrates that the organisation has performed a systematic risk identification exercise, satisfying the “appropriate measures” language of NIS-2 Article 21. Second, it provides a baseline for tracking progress: regulators can compare the inventory at two points in time to verify that migration is advancing. Third, it enables the organisation to respond to incident inquiries with specificity, showing exactly which cryptographic mechanisms protected which data at any given date.

IBM’s 2024 Cost of a Data Breach Report found that the global average cost of a data breach reached USD 4.88 million, the highest figure in the report’s history (IBM, 2024). Proactive cryptographic governance, documented through an inventory, is directly relevant to reducing both the probability and the regulatory consequences of breaches involving cryptographically protected data.

Hard Cases: OT/SCADA, SaaS Dependencies and Long-Lived Signed Documents

Three categories of cryptographic dependency consistently resist standard discovery approaches and require specific handling.

Legacy OT and SCADA Systems

Operational technology environments frequently run firmware that hardcodes cryptographic algorithms and cannot be patched without vendor involvement or full system replacement. Automated network scanning may detect TLS or SSH sessions, but it cannot inspect firmware-level cryptographic primitives without physical access or vendor documentation. The correct approach is to combine network-level scanning with formal requests to every OT vendor for a cryptographic algorithm register, aligned with the supply chain risk assessment requirements in the NIS-2 Article 21 framework. Where vendors cannot respond, organisations should classify those systems as highest-risk pending replacement.

Third-Party SaaS Integrations

SaaS tools present a specific governance gap: the organisation relies on the vendor’s cryptographic implementation without direct visibility into it. Contractual data processing agreements under GDPR, and supply chain security clauses increasingly standard under NIS-2, provide the legal mechanism to demand cryptographic transparency. Organisations should issue formal vendor questionnaires requesting algorithm registers, PQC transition timelines and evidence of third-party security audits. Vendors unable to provide a credible 2030-aligned migration plan should be flagged as high-risk dependencies in the internal inventory.

Long-Lived Signed Documents

Legal acts, notarial records, healthcare records and financial contracts signed with RSA or ECDSA digital signatures face a distinct problem: the signature algorithm is fixed at the time of signing. A document signed in 2015 with RSA-2048 cannot retroactively be re-signed without legal implications. The practical solution, aligned with emerging EU electronic signature regulations, is to apply a quantum-safe countersignature or timestamp using ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) to existing documents before the classical signature becomes cryptographically vulnerable. The cryptographic inventory must therefore include a separate register of long-lived signed documents, catalogued by algorithm, signing date and legal retention period, so that re-timestamping can be planned systematically before 2030.

Frequently Asked Questions

What exactly is a cryptographic inventory and what should it contain?

A cryptographic inventory is a structured register of every cryptographic algorithm, key, certificate, protocol and library in use across an organisation’s systems. It records where each algorithm appears, which data it protects, the key length and expiry date, the system owner, and whether the algorithm is quantum-vulnerable. NIST SP 800-227 specifies that the inventory should also capture data sensitivity classification and the expected longevity of protected data, so that prioritisation decisions can be made systematically.

Which algorithms should organisations treat as urgent priorities for replacement?

RSA (all key sizes), ECDSA, ECDH and finite-field Diffie-Hellman are the algorithms most at risk from a cryptographically relevant quantum computer. NISTIR 8547 sets a deprecation deadline of 2030 for these algorithms in US federal contexts, and the EU NIS Cooperation Group PQC Roadmap uses the same 2030 horizon for critical infrastructure. The approved replacements are ML-KEM (FIPS 203), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205).

How do we handle third-party SaaS tools where we cannot inspect the cryptographic implementation?

Issue formal questionnaires to all SaaS vendors requesting their cryptographic algorithm register, their PQC transition timeline and evidence of third-party audits. Where vendors cannot provide this, escalate to contractual obligations under data processing agreements. NIS-2 Article 21 supply-chain obligations support demanding this information from vendors in regulated-sector contexts. If a vendor cannot demonstrate a credible migration plan aligned with 2030, treat that dependency as a high-risk item in your own migration roadmap.

How long does a first cryptographic inventory typically take for a mid-sized public sector organisation?

Automated scanning of network-facing services and certificate stores can produce an initial draft within two to four weeks for a mid-sized organisation, based on experience from NIST NCCoE pilot programmes. The more time-consuming phase is manual verification of legacy OT systems, embedded devices and archived document stores, which typically adds six to twelve weeks depending on infrastructure complexity. Plan for iterative refinement rather than a single completed inventory.

Is a cryptographic inventory a one-time exercise or an ongoing process?

It is an ongoing process. New software deployments, certificate renewals, API integrations and third-party updates all introduce cryptographic changes. NIST SP 800-227 recommends integrating cryptographic discovery into DevSecOps pipelines and certificate lifecycle management so that the inventory is continuously updated. Regulators under NIS-2 and DORA increasingly treat a static, point-in-time snapshot as insufficient evidence of active cryptographic governance.