Post-quantum cryptography is often described as an algorithm problem: replace encryption that quantum computers could eventually break with newer mathematical techniques designed to survive them.
For software teams, the harder problem may come first.
Before an organization can replace vulnerable cryptography, it has to know where that cryptography actually lives. Encryption is embedded across TLS connections, certificates, VPNs, authentication systems, APIs, databases, cryptographic libraries, code-signing pipelines, hardware security modules and third-party software. In a large company, no single team may have a complete map.
That makes the post-quantum transition as much an asset-discovery and software-architecture problem as a cryptography problem.
NIST now explicitly says that organizations should build and maintain a comprehensive cryptographic inventory to guide post-quantum migration, because migration cannot be prioritized effectively when organizations do not know which systems still rely on vulnerable cryptography.
The algorithms are arriving before many companies are ready
The technical starting point has already changed.
NIST finalized its first three post-quantum cryptography standards in 2024: ML-KEM for key establishment, ML-DSA for digital signatures and SLH-DSA as a hash-based signature scheme. NIST now says those standards are ready to be implemented immediately rather than technologies organizations should wait to evaluate later.
The urgency comes from public-key cryptography.
Current systems such as RSA and elliptic-curve cryptography rely on mathematical problems that are extremely difficult for conventional computers. A sufficiently capable cryptographically relevant quantum computer could undermine those assumptions.
There is also a timing problem even before such a machine exists. NIST warns about attackers stealing encrypted information today and holding it until future technology makes decryption possible, often described as a “harvest now, decrypt later” threat.
For organizations protecting information that must remain confidential for many years, waiting until a capable quantum computer exists may therefore be too late.
Encryption is scattered through the software stack
The visibility problem is larger than locating a few TLS certificates.
Microsoft describes a cryptographic inventory as a living catalog of cryptographic assets and mechanisms used throughout an organization. That can include X.509 certificates, public and private keys, TLS and SSH configurations, cryptographic libraries such as OpenSSL, RSA and ECC calls inside source code, encrypted network sessions, secrets and credentials, HSMs and trusted-platform modules.
That list explains why post-quantum migration quickly becomes an engineering problem.
An organization might replace encryption in a public web service while overlooking an old Java application using RSA internally. A cloud service may depend on a library controlled by another team. An authentication system may rely on certificates issued by external infrastructure. Hardware devices may contain cryptography that cannot be changed without replacing the equipment itself.
Comcast researcher Jayati Dev described the same challenge at USENIX Security 2026: cryptographic assets are scattered across source code, network traffic, infrastructure and third-party systems, often under different organizational owners.
The practical consequence is simple: a migration spreadsheet maintained once and forgotten will not be enough.
Researchers are trying to automate cryptography discovery
Manual inventories become especially difficult in large software estates.
A 2026 study on automated cryptography discovery and inventory argues that organizations first need to identify which cryptographic schemes inside information systems are targets for post-quantum migration. The researchers examined the challenges involved in building tools that automatically detect cryptography and convert those findings into usable inventories.
Another peer-reviewed study published in IEEE Access developed a toolchain called QED for finding quantum-vulnerable cryptographic dependencies inside software executables.
The researchers evaluated QED across more than 200 real-world software executables and reported that it could reduce the manual analyst workload required to identify quantum-vulnerable executables by more than 90%. The system analyzes binaries down to APIs that trigger vulnerable cryptographic operations, addressing cases where source code may not even be available.
This is important for enterprise software because organizations do not control every component they run.
Some systems are commercial binaries. Others contain open-source dependencies nested several layers deep. Old applications may have incomplete documentation. Discovering vulnerable cryptography therefore increasingly resembles software-supply-chain analysis.
A cryptography bill of materials could become part of the answer
One emerging approach borrows from software bills of materials.
A Cryptography Bill of Materials, or CBOM, records the algorithms, protocols, certificates and cryptographic dependencies contained within software.
A 2026 open-access conference paper examining the CycloneDX standard describes CBOMs as a way to provide comprehensive visibility into cryptographic assets across software systems and connect those records with SBOMs, hardware inventories and other machine-readable dependency information.
For platform teams, that could make cryptographic risk more queryable.
Instead of asking dozens of teams whether they use RSA, a security organization could theoretically identify affected applications from structured inventory data, determine which business systems depend on them and prioritize migration based on data sensitivity and exposure.
That same capability would remain useful after the quantum transition.
Cryptographic algorithms change over time for reasons other than quantum computing. Weaknesses are discovered, key lengths become inadequate and standards evolve. Knowing where cryptography lives makes every future transition easier.
Meta shows why migration takes years
The scale of the work is already visible inside major technology companies.
Meta said in April 2026 that it has begun deploying post-quantum encryption across its internal infrastructure through a multi-year migration process. Its framework begins with prioritization and cryptographic inventory before moving through dependencies, implementation, guardrails and deployment.
Meta also describes cryptographic inventorying as a critical prerequisite because cryptography is ubiquitous and finding every primitive across a large infrastructure and codebase is inherently challenging.
Its approach combines automated production monitoring with developer reporting because monitoring cannot capture every edge case or shadow dependency.
That illustrates why migration cannot simply be assigned to a central security team. Application developers, infrastructure engineers, vendors, hardware teams and cryptographers all control different parts of the dependency graph.
The 2035 deadline is closer than it looks
Migration timelines may sound generous until the discovery work is considered.
The UK National Cyber Security Centre recommends that organizations complete discovery, assessment and an initial migration plan by 2028, move the highest-priority systems by 2031 and complete migration across systems, services and products by 2035.
The agency estimates that large organizations may require two to three years simply to perform discovery, define a strategy and build the initial migration plan.
NIST is moving toward a similar end state. Its transition guidance says quantum-vulnerable algorithms are expected to be deprecated and ultimately removed from NIST standards by 2035, with high-risk systems expected to move considerably earlier.
For CTOs, CISOs and infrastructure teams, that changes what “quantum readiness” means.
The immediate task is not purchasing a quantum-security product. It is building enough visibility into existing software to know what eventually needs to change.
Post-quantum cryptography may introduce new algorithms, but the difficult work begins much closer to ordinary software engineering: finding dependencies, assigning owners, understanding data lifetimes and designing systems so cryptography can be replaced without rebuilding everything around it.
The quantum computer may still be in the future. The software inventory needed to survive it cannot be.
