Post-Quantum Readiness: Start with Your Software Estate Inventory

Preparing for post-quantum cryptography (PQC) begins with an inventory of systems, cryptographic methods, and dependencies. Our previous article on post-quantum preparation for legacy software discusses the technical risks of migration. Here is a specific inventory plan for companies ranging from 50 employees to large enterprises: inventory templates, tools, responsibilities, and next steps.

Why Post-Quantum Preparation Must Start Now

The quantum threat primarily affects RSA, Diffie–Hellman, and elliptic curve cryptography. The harvest now, decrypt later scenario is particularly dangerous: data intercepted today can be decrypted at a later date. Modern AES should not automatically be placed in the same risk category. In 2024, NIST approved FIPS 203, 204, and 205, but this is not sufficient to ensure compatibility among applications, protocols, and vendors.

UK NCSC recommends completing the infrastructure assessment and initial plan by 2028, carrying out the highest-priority migration by 2031, and to complete the bulk of the migration by 2035. These are guidelines, not universal legal deadlines. Next steps today: appoint a program owner and begin a cryptographic inventory without waiting for the entire infrastructure to be ready for PQC.

What Authorities Actually Recommend

In its July 2026 report, the Bank of England identifies the mapping of systems, software, data, and cryptographic dependencies as an immediate priority. The Bank specifically highlights the risks posed by critical third-party suppliers. The G7 Cyber Expert Group identifies Discovery and Inventory as a separate phase of its roadmap. However, the G7 document does not explicitly set out regulatory requirements.

Organization	What to Include in the Work
CMORG, 2025	Consider cryptography for data-at-rest, data-in-transit, and data-in-use; document algorithms, key metadata, owners, and the lifecycle.
BIS, 2025	Start with a cryptographic inventory; do not treat the transition as a simple replacement of algorithms.
NIST NCCoE	Create and maintain a unified registry; combine detection methods and scan results with system context.
NCSC, 2025	Survey the entire software environment, identify vendor dependencies, and develop a phased plan.

These documents differ in their legal status; the obligations vary by industry and jurisdiction.

Step 1. Assign Owners and Define the Scope

In a company with 50–200 employees, the IT manager or CTO can serve as the coordinator; a dedicated CISO and an in-house CMDB are not required. In an enterprise, the program is typically overseen by the CISO or CIO, and implementation is distributed among teams. Assign an owner for each system: this person verifies the system’s purpose, dependencies, and data quality. A security specialist checks the cryptography, architects review the connectivity, and the person in charge of procurement verifies information from vendors. Assign tasks to existing roles.

Start with business-critical services, but also consider test environments, clouds, SaaS, network devices, backups, PKI, KMS, HSM, repositories, and legacy applications. For a small IT department, a pilot covering 5–10 key systems is sufficient; an enterprise can start with a single business domain. This is an example of pilot scope, not a mandatory minimum. Record the date, source, and status of each entry: confirmed, inferred, unknown. “Unknown” does not mean “safe.”

Result: Approved scope, responsible parties, rules for accessing registries, and a list of systems that cannot yet be audited.

Step 2. Create Three Connected Inventories

Regardless of the company’s size, create three linked registries: assets, cryptographic applications, and dependencies. Use three Excel tabs or linked CMDB entities with unique IDs. Below is a hypothetical example, not a real company’s configuration.

A. Software Estate Register

Export assets from the CMDB, the cloud, application registries, and contracts. Identify systems outside the CMDB.

Asset ID	System / Version	Owner	Business Function	Status
APP-01	Customer Portal / v5	Application Team	Customer Service	Supported
APP-02	Order Processing / v2	Operations IT	Orders and Contracts	Unsupported
SEC-03	Certificate Service	IT Security	Certificates	Supported
EXT-04	Payment Provider API	Vendor Owner	Payments	Vendor-owned

Additional fields: department, environment, deployment, data classification, end of support, vendor, criticality, documentation. The Asset ID must remain consistent, even when the application version is updated.

B. Cryptographic Use Register

A system may have dozens of cryptographic applications. Record the actual usage, not just the libraries. Distinguish between key exchange algorithms, digital signatures, and symmetric encryption.

Crypto ID	Asset ID	Function	Protocol / Algorithm	Evidence
CR-01	APP-01	Key Establishment	TLS 1.3 / ECDHE	Configuration Verification
CR-02	APP-02	Document Signing	RSA-2048	Source Code Analysis
CR-03	SEC-03	Certificate Issuance	RSA / X.509	PKI Metadata Export
CR-04	EXT-04	Secure API Channel	Unknown	Awaiting Vendor Response

Required additional fields: library and version, key size, link to certificate or KMS, validity period, data confidentiality type and duration, verification status, estimated quantum exposure, migration complexity, and responsible person. Do not store private keys, secrets, or passwords in the registry—only identifiers and secure links.

NIST NCCoE lists algorithms, protocols, certificates, keys, components, and protected data among the possible fields. For machine-readable results, CycloneDX CBOM can be used, but a standard SBOM does not guarantee knowledge of the algorithms actually used.

Set up a separate, secure repository for evidence. Assign Evidence ID to each observation and record the source (TLS scan, repository, PKI export, vendor response), the collection date, the person who collected it, the tool version, and the date of owner verification. Enter a link to the evidence in the table, not raw configurations or secrets. Set a review deadline for assumptions. If a rescan detects a different algorithm, do not overwrite the previous value without verification: create a discrepancy record and assign a person responsible. This allows you to distinguish a system change from a detection error or outdated documentation.

C. Dependency Register

The third registry answers the key migration question: which system depends on which cryptographic component.

From → To	Connection Type	What to Check During Migration
APP-02 → SEC-03	Signature Verification	Will the application be able to verify new signatures?
APP-01 → EXT-04	TLS/API	Are the algorithms on both sides compatible?
APP-01 → SEC-03	Certificates	Will the chain of trust be compromised?
APP-02 → CR-02	Use of RSA Signatures	Can the algorithm be replaced without rewriting the module?

Store Source ID, Target ID, connection type, data stream, protocol, owner, provider, proof, and compatibility. Separately document dependencies on HSMs, KMS, legacy DLLs, firmware, licenses, and hardware roots of trust.

A helpful diagram: Business Service → Application → Library/Protocol → Key/Certificate Service → Supplier. If a PKI update requires reworking an unsupported application, that is a specific roadblock that can be assessed and planned for.

Step 3. Discover Cryptography with Real Tools

Tables do not detect cryptography. Use scanning, code and configuration analysis, and vendor responses. [NIST NCCoE publishes a list of tools](https://pages.nist.gov/nccoe-migration-post-quantum-cryptography/FAQ/index.html) available for various tasks.

Tool	What it detects	Limitations
pqcscan, sslscan2	SSH/TLS settings and supported algorithm suites	Does not detect all cryptography within the application
crt.sh	Publicly registered certificates	Does not reveal the internal PKI
CodeQL	Selected cryptographic calls in supported source code	Requires appropriate queries; does not analyze closed binaries
CMDB / cloud inventory	Assets, environments, and owners	Typically do not know the actual algorithms
PKI / KMS / HSM exports	Key and certificate metadata	Do not reveal all application dependencies

If the source code is not available, use configuration analysis, binary dependencies, authorized network checks, and inquiries to vendors. Coordinate production scans. A scanner report is evidence of a specific observation, but not a complete registry: the results must be cross-referenced with the application, the owner, and the business process.

Step 4. Google Sheets, CMDB or Custom Software?

Google Sheets / Excel: A quick start for companies with 50 or more employees that do not use a CMDB. Create the tabs Assets, Crypto Uses, Dependencies, Vendors, Open Questions, and configure value lists, filters, and access rights. The table does not automatically detect cryptography; you will need to check links and changes manually. Use only storage solutions permitted by corporate policy: the system security map is sensitive.

Existing CMDB: This approach is preferred when assets and owners are consistently tracked, most often in medium and large companies. Do not create a duplicate registry: add cryptographic entities and references to technical evidence. If the CMDB is outdated, first assess its quality and integration capabilities.

Specialized Software: This is appropriate when dealing with hundreds of services, multiple teams, and regular audits. Evaluate coverage of protocols, applications, and clouds; export APIs; deduplication; security of hosting; and support for legacy systems. A vendor’s mention in NIST materials does not imply certification of its product.

Step 5. Extend Your Legacy CMDB Instead of Replacing It

Companies already using a legacy CMDB do not necessarily need to purchase a platform for PQC. The legacy CMDB often tracks software and owners, but not cryptography. It can be extended without a complete replacement, provided the architecture and license allow it. For a company without a CMDB, it makes more sense to start by setting up a simple registry and add automation as the business grows.

The practical scope of this project is as follows:

1. Data model extension. Add entities Crypto Use, Algorithm, Certificate Reference, Dependency, Evidence, PQC Assessment; link them to existing asset IDs and owners.
2. Discovery connectors. Import data from authorized TLS/SSH scanners, repositories, PKI, cloud APIs, and certificate management systems. Store the date, source, confirmation, and conflicting results.
3. Dependency mapping. Build a “business service → application → component → cryptography → vendor” view that allows you to assess the impact of updating a single element.
4. Workflow and reporting. Assign checks to owners, register unknown algorithms, track changes, export reports, and generate CBOM-compliant data as needed.
5. Controlled rollout. Test the update on several critical and legacy applications, then integrate the remaining systems without disrupting the existing CMDB.

What Softacom Has to Offer: Assessment of the existing CMDB and legacy applications, data schema design, development of modules and integrations, analysis of cryptographic dependencies in the available code, testing, and phased implementation. This is a proposal for custom development, not a claim that Softacom offers a ready-made product for a certified PQC audit.

The customer receives a fully functional CMDB with advanced capabilities, a verifiable cryptographic registry, a dependency map, and a modernization backlog. This data is also useful for managing certificates and technical debt.

What to Ask Third-Party Vendors

Instead of asking the supplier a general question like “Are you quantum ready?”, send a brief technical inquiry. Make sure the response refers to a specific product, version, and Asset ID; otherwise, it cannot be used for planning.

Question for the vendor	Why do we need an answer?
Which algorithms and libraries are actually used in our version?	To verify the crypto inventory entries
Which versions will support ML-KEM and post-quantum signatures?	Determine a feasible upgrade path
Are new certificates, HSMs, APIs, or hardware components required?	Identify associated costs and roadblocks
Is it possible to test hybrid options and roll back changes?	Prepare secure testing
What are the support timelines and compatibility limitations?	Coordinate the migration wave

If the supplier cannot provide an answer, do not fill in the algorithm based on guesswork. Set the status to unknown, assign a person responsible, and set a deadline for a follow-up request. This gap should be highlighted in reports to management along with technical risks.

How to Verify Inventory Completeness

Reconcile the number of assets across the CMDB, cloud accounts, network lists, repositories, and the business services catalog. Record any discrepancies as verification tasks. For critical applications, the owner must confirm at least three things: all external interfaces are listed, the cryptography of these interfaces has been reviewed, and significant dependencies are reflected in the registry.

Don’t judge quality solely by the number of algorithms found. The following metrics are more useful: the percentage of critical systems with an assigned owner, the percentage of verified cryptographic entries, the number of unknown external dependencies, and the age of the last check. For example, “80% of records verified” says nothing about risk if the remaining 20% are key payment systems. Therefore, reports should be broken down by the criticality of assets and the types of data being protected.

Step 6. Prioritise and Assign Next Actions

After conducting an inventory, do not automatically classify everything that uses RSA as high risk. Assess the algorithm’s use case, the data involved, the required confidentiality period, the criticality of the business process, the availability of fixes, and dependencies on vendors. First and foremost, examine systems containing long-term confidential information and those susceptible to a “harvest now, decrypt later” attack, as well as signature and trusted boot mechanisms with a long lifecycle.

Status	Criterion	Next Action
Investigate	Algorithm, owner, or dependency unknown	Verify configuration and proofs
Vendor action	Component is closed-source and controlled by the vendor	Request PQC roadmap and compatibility
Upgrade	Supported library, clear dependencies	Plan an upgrade and tests
Modernize	Unsupported code or hard-coded cryptographic dependency	Evaluate replacing the component, API, or application

For any legacy applications, regardless of the technology stack, check for built-in libraries, OS dependencies, certificates, hardware modules, and unsupported protocols. A TLS gateway can secure an individual connection, but it will not eliminate a vulnerable signature within the application. The modernization approach is determined based on a technical assessment, not on the programming language used.

Step 7. Align with Standards and Keep Records Current

Link the register to the current security management system. ISO/IEC 27001:2022 includes control A.5.9 (inventory of information and related assets) and A.8.24 (use of cryptography); ISO/IEC 27002:2022 explains the practical application of controls, while ISO/IEC 27005:2022 covers risk assessment. NIST Cybersecurity Framework 2.0 provides a practical framework for asset management. None of these documents, on its own, specifies a mandatory format for a PQC table.

Schedule periodic reviews and events that trigger a registry update: certificate issuance, a change in the cryptographic library, a new integration, a vendor update, and system decommissioning. Maintain a history of changes, verification results, and justification for priority. A registry that is updated only once quickly loses its value.

A 90-Day Starting Plan

When	What to Do	What to Present to Management
Days 1–15	Assign owners; identify critical services; approve templates for the three registries	Scope and Responsibilities
Days 16–30	Collect assets from catalogs and the CMDB (if available); select a pilot; identify gaps	Consolidated software inventory
Days 31–60	Scan available protocols, code, and PKI; request information from vendors	Cryptographic inventory with evidence
Days 61–75	Map dependencies; verify data with owners	Dependency map and list of unknowns
Days 76–90	Group risks and constraints; select initial updates	Backlog and plan for the next wave

This is an example of a plan, not a regulatory deadline. A company with 50–200 employees can cover most of its critical services within 90 days; for enterprise-level organizations, it is more realistic to test the method on a single domain and prepare for scaling. In both cases, management must identify verified assets, unknown dependencies, and the individuals responsible.

What Comes After the Inventory?

The result of the assessment is not the table itself, but a set of solutions: which applications to update as standard, which ones depend on vendor plans, where a legacy modernization project is needed, and which changes should be tested first. Next, the following steps are carried out sequentially: architectural assessment, coordination with vendors, lab testing, migration of priority systems, compatibility testing, and ongoing verification.

A Practical Readiness Criterion: For each critical system, the owner, the actual cryptography, the dependent components, the data being protected, the quality of the evidence, and the next step can be identified. Unknown answers require further verification.