Post-Quantum Readiness: Build a Cryptography Inventory Now

Post-quantum readiness begins with a cryptography inventory because organizations cannot migrate controls they cannot locate. Record which business systems and vendors use public-key cryptography for encryption, key exchange, digital signatures, certificates, identity, software updates, devices, and backups; what data they protect; how long that data must remain secure; which algorithms and key sizes apply; who owns the component; and whether an upgrade path exists. Prioritize long-lived sensitive data and difficult-to-replace systems, require vendor roadmaps, and improve cryptographic agility before making algorithm changes.

Why inventory work should begin now

Large cryptographically relevant quantum computers do not yet make current widely used public-key systems obsolete in ordinary operations, and timelines are uncertain. Migration still takes years because cryptography is embedded in protocols, certificates, hardware, firmware, code, partner connections, procurement, and regulated processes. NIST finalized its first three post-quantum cryptography standards in August 2024 and encourages organizations to begin transitioning, making preparation an engineering and supplier-management task rather than a prediction contest.

Some information may be collected now and decrypted later if an adversary can store it until future capability exists. Risk depends on sensitivity and required secrecy lifetime. A contract expiring next month differs from health, identity, intellectual property, legal, or strategic records that must remain protected for many years. Start with data value and lifetime, then trace the cryptography and systems protecting it.

Define the inventory around business use

For each item, record business service, owner, data, users, environment, confidentiality and integrity need, retention, protocol or function, algorithm, key length, certificate or key source, library or product, hardware dependency, configuration, external party, expiry, update mechanism, and evidence. Include encryption at rest and in transit, key exchange, authentication, digital signatures, code signing, document signing, VPN, email, APIs, databases, backups, and device management.

Prioritize where public-key cryptography is used because that is the main quantum migration concern, while continuing to manage symmetric cryptography properly. Avoid scanning for algorithm strings without context; a library may be installed but unused, or cryptography may be hidden inside an appliance or SaaS service. Combine automated discovery, configuration review, code analysis, certificate records, network observation, architecture diagrams, procurement data, and owner interviews.

Include certificates, keys, and trust relationships

Inventory public and private certificate authorities, TLS certificates, client certificates, signing certificates, SSH keys, VPN credentials, API identities, device certificates, and roots embedded in software or hardware. Record issuance, storage, rotation, revocation, automation, expiry, and relying parties. Identify hard-coded keys or trust stores and long-lived credentials. An algorithm migration may fail operationally if one partner or device cannot validate the new chain.

Protect the inventory because it reveals security architecture. Use role-based access, version control, and clear evidence without centralizing private keys. Reconcile certificate discovery with approved records and investigate unknown issuers or expired services. Improving ordinary key management and eliminating obsolete cryptography creates value now and reduces the future migration surface.

Map software, hardware, cloud, and suppliers

Ask vendors which cryptographic functions their products use, where they are configured, which post-quantum standards they plan to support, whether updates are software or hardware, what versions and dates apply, and how hybrid or transition modes will be tested. Require evidence and contract commitments proportionate to risk. A broad statement of quantum readiness is less useful than a roadmap for the exact product version deployed.

Include operating systems, browsers, runtimes, libraries, cloud key management, load balancers, identity providers, network devices, industrial systems, mobile apps, firmware, secure elements, and archived media. Record end-of-support and replacement lead time. A device with a fifteen-year operational life deserves earlier planning than a stateless service upgraded monthly. Identify partner protocols and regulators that constrain changes.

Prioritize with data lifetime and migration difficulty

Score sensitivity, secrecy or signature lifetime, exposure, business criticality, algorithm vulnerability, internet reachability, vendor dependency, replacement lead time, and testing complexity. Prioritize high-value long-lived data and components with slow upgrade paths. Also identify digital signatures whose validity must be proven years later, such as code, documents, or records, and assess preservation requirements with qualified specialists.

Create waves: remove obsolete and unknown cryptography; improve inventory and ownership; enable crypto-agile configuration; test vendor-supported standards in laboratories; pilot interoperable paths; then migrate production under official guidance. Do not replace algorithms ad hoc or implement novel cryptography. Use finalized standards and supported, reviewed implementations appropriate to the system and jurisdiction.

Build cryptographic agility

Separate algorithms and parameters from business logic where feasible, centralize policy, automate certificate and key lifecycle, maintain dependency and software bills of materials, and make configurations observable. Create test environments and interoperability cases. Ensure data formats, APIs, databases, and protocols can accommodate larger keys, signatures, ciphertexts, and messages. Performance, memory, bandwidth, storage, and hardware constraints need measurement.

Agility does not mean an administrator can select any algorithm. Changes should use an approved policy, authenticated configuration, testing, staged deployment, monitoring, and rollback. Prevent downgrade and inconsistent negotiation. Hybrid approaches may combine classical and post-quantum methods during transition, but they add complexity and should follow authoritative guidance and vendor support rather than improvised composition.

Create governance and a maintained roadmap

Assign a cryptography owner or working group appropriate to size, with system, security, risk, procurement, and business input. Review NIST and relevant national or sector guidance, vendor roadmaps, inventory coverage, unsupported systems, pilots, and exceptions. Add cryptography questions to architecture and procurement. Require new systems to support inventory, key lifecycle, upgrade, and export rather than adding opaque dependencies.

Update the inventory after releases, renewals, incidents, acquisitions, and infrastructure changes. Measure coverage, unknown services, obsolete algorithms, certificate automation, vendor responses, end-of-support exposure, and tested migration paths. The immediate goal is not to switch every algorithm. It is to know where the company depends on cryptography and to preserve the ability to migrate safely when the supported path is ready.

Add discovery to normal engineering. Certificate transparency, network scans, code and dependency analysis, cloud configuration, key-management logs, and architecture reviews can identify parts of the estate, but each produces false positives and blind spots. Reconcile automated findings with owner attestation and runtime evidence. Track inventory confidence and last verification rather than marking a row complete forever.

Coordinate retention with migration. Data scheduled for defensible deletion may not need an expensive long-term cryptographic transition, while archives with legal, historical, or operational value need readable formats, protected keys, authenticity evidence, and tested recovery. Confirm which signatures or timestamps must remain verifiable and how trust evidence is preserved. Do not keep sensitive data indefinitely merely because migration planning is difficult.

Test interoperability before broad rollout. A client, server, proxy, certificate authority, hardware module, partner, or monitoring tool may support a standard differently or impose size limits. Measure handshake, throughput, failure, fallback, observability, and resource use under realistic load. Prevent silent downgrade. Record supported combinations and update them with versions so a future team can reproduce the result.

Budget by migration wave. Long-lived hardware, embedded devices, regulated systems, and partner protocols may require procurement years ahead, while software services can move faster. Include testing, downtime, licenses, certificates, hardware, vendor services, training, and rollback. Early inventory gives leadership options and prevents every dependency from becoming an emergency when a deadline or vulnerability arrives.

Include cryptography in incident response. A compromised certificate authority, stolen signing key, weak random generation, expired root, or vulnerable library may require rapid discovery and rotation independent of quantum risk. The inventory should support contact, scope, revocation, replacement, and validation. Practicing these events builds the operational capability later migration will require.

Communicate with customers and partners carefully. Share supported algorithms, certificate changes, test dates, and retirement plans through authenticated channels. Avoid exposing sensitive architecture. Provide overlap and rollback appropriate to criticality and confirm both sides can detect a downgrade or failure. Partner readiness can be the longest dependency, so agreements and tests should begin before the final production wave.

Monitor standards and guidance at the source. Algorithm selections, implementation advice, transition dates, and sector expectations evolve. Assign responsibility for reviewing NIST and relevant national or industry publications, then translate changes into an approved roadmap update. Vendor announcements and general news can prompt investigation but should not be the sole authority for a security migration.

Avoid a compliance-only inventory that ignores availability. Cryptographic changes can affect performance, message size, hardware capacity, certificates, monitoring, and disaster recovery. Include operations and service owners in acceptance tests and measure normal and peak loads. A secure algorithm is not successfully deployed if it makes an essential service unreliable or prevents recovery.

Frequently asked questions

Should SMEs replace current encryption immediately?

Do not make unsupported ad hoc changes. Begin inventory, data-lifetime analysis, ordinary cryptography hygiene, vendor engagement, and agility. Follow finalized standards and current guidance for supported migrations appropriate to each system.

What does harvest now, decrypt later mean?

An adversary may collect encrypted information today and retain it in case future capability can break the public-key protection. Data needing long confidentiality deserves earlier inventory and migration planning.

Is post-quantum readiness only an IT issue?

No. Data owners determine sensitivity and lifetime; procurement manages vendor commitments; legal and compliance assess obligations; operations plan upgrades; leadership accepts residual risk and funds long-lead replacement.