Quantum computing still feels distant to many business leaders because today’s systems continue to run on familiar cryptographic standards. Websites use TLS, applications rely on certificates, software is signed digitally, VPNs protect network traffic, and cloud platforms encrypt data using technologies that have supported enterprise security for years. The problem is that some of the public-key cryptography behind those systems was never designed to withstand a sufficiently capable quantum computer.
Algorithms such as RSA and elliptic-curve cryptography remain secure against current conventional attacks when implemented correctly, but quantum computing changes the mathematical assumptions behind them. A cryptographically relevant quantum computer could make some widely used public-key methods unsuitable for protecting future communications, identities, signatures, and long-lived confidential data.
Businesses therefore face an unusual migration problem: they need to begin changing cryptographic infrastructure before the technology capable of breaking the old infrastructure necessarily exists at scale.
That transition has already moved from research into implementation. 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 standard. NIST now explicitly recommends that organizations begin migrating to these standards rather than waiting for quantum computing timelines to become certain. NIST
The challenge for businesses is not simply choosing a new encryption algorithm. Post-quantum migration touches certificates, TLS, APIs, VPNs, identity, code signing, cloud infrastructure, hardware, key management, vendor products, embedded systems, and data that may need to remain confidential for years.
This makes PQC migration less like a software update and more like a long-term infrastructure modernization program.
- NIST’s first production-ready PQC standards are already available.
- Waiting for a powerful quantum computer to arrive would make migration too late.
- Cryptographic inventory is the most important starting point.
The Migration Has Already Started
Post-quantum cryptography is no longer a research topic that businesses can postpone until quantum computers become powerful enough to threaten existing encryption. The transition has already entered the standardization and implementation stage, which means organizations can begin preparing their systems using concrete technical standards rather than theoretical alternatives.
A major milestone came in August 2024, when the U.S. National Institute of Standards and Technology (NIST) finalized its first three post-quantum cryptography standards. These standards are designed to replace some of the public-key cryptographic mechanisms that could eventually become vulnerable to sufficiently powerful quantum computers. The three standards address two fundamental security functions: establishing secure connections and verifying digital signatures.
- ML-KEM, standardized as FIPS 203, is designed for secure key establishment. In practical terms, it helps two systems create a shared secret that can then be used to protect communication. This makes it relevant to technologies such as TLS, secure APIs, VPNs, and other systems where two parties need to establish an encrypted connection.
- ML-DSA, standardized as FIPS 204, is designed for digital signatures. Digital signatures are used to prove that software, documents, certificates, or messages genuinely came from a trusted source and were not modified. This makes ML-DSA relevant to areas such as code signing, certificate infrastructure, software distribution, firmware updates, and authentication.
- SLH-DSA, standardized as FIPS 205, provides another approach to digital signatures based on hash functions. It gives organizations an additional standardized option where different security or implementation characteristics may be required.
For business leaders, the important point is not memorizing the algorithm names. The important change is that organizations now have standardized post-quantum mechanisms that can begin replacing vulnerable public-key cryptography in real systems. That moves the discussion from “Which algorithms might eventually replace RSA and elliptic-curve cryptography?” to a much more practical question: “Where are we using vulnerable cryptography today, and how difficult will it be to replace?” That second question is much harder. Enterprise cryptography is rarely located in one security platform that can simply be upgraded. It is distributed throughout the technology environment. RSA and elliptic-curve algorithms can appear inside TLS certificates, VPN connections, API authentication, public key infrastructure, email security, code-signing processes, mobile applications, cloud services, identity platforms, firmware validation, hardware security modules, network appliances, and third-party software.
Some of these dependencies are obvious. Security teams generally know which certificate authorities or VPN platforms the company uses. Others are hidden inside libraries, operating systems, managed cloud services, vendor products, or devices that application teams may never think of as “cryptographic infrastructure.”
This is why replacing one cryptographic library does not make an organization post-quantum ready.
Imagine a company upgrades an application so that it supports a post-quantum key exchange. The application may still connect through a load balancer that does not support the new algorithm. A legacy client may be unable to complete the handshake. A monitoring appliance may not understand the new certificate format. A hardware security module may support the existing RSA keys but not the new signing algorithm.
The Risk Exists Before a Quantum Computer Can Break Encryption
One of the strongest business reasons to begin post-quantum preparation early is the possibility of harvest now, decrypt later attacks. The idea is straightforward. An attacker does not need access to a cryptographically relevant quantum computer today. They only need to intercept or obtain encrypted information now, store it, and wait until future computing capabilities make it possible to decrypt that data later. For organizations, this changes the way quantum risk needs to be evaluated. The threat is not limited to the moment when a sufficiently powerful quantum computer becomes available. Exposure can begin years earlier if sensitive information is already being collected by attackers. CISA, NSA, and NIST have specifically warned organizations about this scenario and recommend developing quantum-readiness roadmaps, identifying vulnerable cryptography, prioritizing systems based on risk, and engaging technology vendors before migration becomes urgent. The key issue is data lifetime. Not all information needs to remain confidential for the same amount of time. A temporary marketing campaign or short-lived operational record may lose most of its sensitivity relatively quickly. Intellectual property, merger information, legal documents, healthcare records, financial information, government data, strategic research, customer records, and authentication material can remain sensitive for many years. This creates a simple but important risk calculation.
Imagine an organization stores information that must remain confidential for 15 years. If migrating the systems protecting that information could take another five years, the company cannot safely wait until quantum computing is commercially mature before beginning the transition. By then, information captured years earlier may already be within the window in which future decryption becomes valuable. The same logic applies to business secrets. A confidential product roadmap may still matter several years after it is created. Source code, research data, engineering designs, acquisition plans, and long-term customer information can retain value far beyond the moment they are transmitted. If attackers believe that some of this information will still be valuable in the future, storing encrypted copies today can become strategically attractive. This is particularly relevant for organizations operating in industries where data has a long useful life. Financial institutions, healthcare companies, defense contractors, manufacturers, energy companies, governments, research organizations, and enterprises managing intellectual property may face much longer confidentiality requirements than businesses handling mostly short-lived consumer data. The risk is also not limited to files stored in databases. Sensitive information travels constantly through TLS connections, VPNs, APIs, email systems, cloud environments, backup systems, partner integrations, and service-to-service communications. Even if an organization secures stored data carefully, encrypted traffic can still be intercepted outside the organization and preserved for future analysis.
Cryptographic Inventory Comes Before Algorithm Replacement
For many organizations, the most difficult part of post-quantum migration will not be choosing between new cryptographic algorithms. It will be understanding where existing cryptography is already embedded across the business. Modern enterprises rarely operate one centralized encryption system. Cryptographic functions are distributed throughout the technology stack and often remain invisible until something needs to change. They can appear inside operating systems, application libraries, APIs, service meshes, TLS certificates, VPNs, databases, CI/CD pipelines, cloud services, identity platforms, network appliances, mobile applications, code-signing systems, hardware security modules, embedded devices, SaaS platforms, and vendor-managed infrastructure. Some of these dependencies are easy to identify. Security teams usually know which certificate authorities, VPN technologies, and key-management platforms they operate. Others are much harder to see because cryptography is hidden inside commercial software, third-party libraries, managed cloud services, or devices that engineering teams do not directly control. This is why post-quantum migration needs to begin with cryptographic discovery rather than immediate replacement. Before deciding which systems should adopt ML-KEM, ML-DSA, or another post-quantum standard, organizations need a reliable picture of the cryptographic environment they already have. NIST’s migration work places significant emphasis on cryptographic visibility because companies cannot prioritize or plan a transition if they do not know which algorithms, certificates, protocols, and dependencies are currently protecting their systems.
A useful cryptographic inventory needs to contain much more than a simple note saying that a system “uses RSA.” Organizations should understand which cryptographic algorithms are being used, where they are implemented, what key sizes and certificate types are involved, which protocols depend on them, how long certificates remain valid, what information is being protected, who owns the system, which external vendors are involved, and whether the component can be upgraded without replacing the surrounding infrastructure. Two systems may both use the same quantum-vulnerable algorithm while representing very different migration priorities. A public-facing application protecting short-lived session information may not require the same urgency as a PKI environment used to sign firmware that must remain trustworthy for fifteen years. A test environment is different from a system carrying confidential intellectual property, healthcare information, or long-term financial records.
The Timeline Is Becoming More Concrete
Businesses do not need to predict the exact year a cryptographically relevant quantum computer will arrive before they begin planning for post-quantum migration. In practice, organizations already have a more useful reference point: standards bodies and government agencies are defining when vulnerable cryptography should begin disappearing from production environments.
NIST’s current transition planning provides one of the clearest signals. Its post-quantum guidance calls for organizations to begin migration now, with quantum-vulnerable public-key algorithms progressively deprecated and ultimately removed from NIST standards by 2035. Higher-risk systems are expected to transition earlier rather than wait for the final deadline.
That 2035 date is important, but it should not be interpreted as a comfortable starting point.
Large organizations may need years to discover vulnerable cryptography, coordinate vendors, update certificates, replace legacy hardware, test new protocols, modify applications, and complete migrations across production environments. For companies with thousands of systems and external dependencies, the transition can easily span multiple technology refresh cycles. NIST’s own migration materials show how gradual that process is expected to be. Some lower-strength RSA, elliptic-curve, and related key-establishment schemes are expected to become deprecated after 2030, while quantum-vulnerable algorithms at higher security strengths are targeted to become disallowed after 2035.
Public Key Infrastructure Will Be One of the Hardest Areas
Public Key Infrastructure, or PKI, sits underneath a large part of modern digital trust. It allows organizations to verify that users, devices, applications, servers, and software are communicating with the right party and that information has not been altered along the way. Certificates are one of the most visible parts of PKI, but the infrastructure behind them is much broader. PKI includes certificate authorities, registration processes, keys, certificate policies, revocation mechanisms, hardware security modules, validation services, and the systems responsible for issuing, renewing, and rotating certificates. This infrastructure supports far more than secure websites. Organizations rely on PKI for TLS connections, VPN access, employee and device authentication, secure email, API communication, code signing, firmware validation, document signing, cloud workloads, machine identities, and communication between internal services. In many enterprises, thousands or even millions of certificates may be distributed across applications, devices, environments, and external services.
That makes PKI one of the areas where post-quantum migration can become particularly complicated.
Replacing the cryptographic algorithm behind a certificate is not simply a matter of selecting a new option in a configuration file. Every system that creates, distributes, stores, validates, or relies on that certificate must be able to understand the new cryptography. A certificate authority may support a post-quantum signature algorithm, for example, while an older operating system, browser, network appliance, or embedded device does not. In that situation, issuing a new certificate could break communication rather than improve security.
Organizations therefore need to consider the entire certificate trust chain. A typical TLS connection may involve an application, certificate authority, server, load balancer, proxy, operating system, client library, browser, security monitoring tool, and hardware security module. If even one critical component cannot process the new certificate or signature format, the end-to-end migration may not yet be possible. This interoperability issue becomes more significant because post-quantum cryptography can change technical characteristics that existing infrastructure has been designed around. Post-quantum public keys and signatures can be larger than those used in many current systems. Larger cryptographic objects can affect certificate sizes, TLS handshakes, network packets, memory requirements, storage, and processing behavior. In a modern cloud application with significant compute capacity, those differences may be relatively easy to manage. In constrained devices or legacy infrastructure, they may create much more serious limitations. Consider an industrial sensor, medical device, vehicle component, or IoT product expected to operate for fifteen or twenty years. The device may have limited memory, processing power, network bandwidth, and firmware-upgrade capability. Its cryptographic implementation may even be tied to hardware designed specifically for RSA or elliptic-curve operations. Migrating such a device is very different from updating a cloud-native service that can receive a new software release several times per day. If the device cannot efficiently process the new algorithms, the organization may need to redesign firmware, change certificate handling, introduce additional processing resources, or eventually replace the hardware itself. This is one reason long-lived devices deserve early attention in PQC planning. Certificate lifetime creates another issue. Some certificates are intentionally short-lived and can be replaced frequently. Others may be embedded into devices, manufacturing processes, software packages, or trust stores for many years. The longer the expected lifetime, the more important it becomes to understand whether the cryptography used today will remain trustworthy throughout that period.
Prepare for post-quantum security before migration becomes urgent.
Contact usConclusion
Post-quantum cryptography has moved from a theoretical security discussion into a real infrastructure transition.
NIST standards are available. Government migration timelines are becoming more concrete. Vendors are beginning to implement quantum-resistant capabilities. Organizations with long-lived sensitive information already need to consider harvest-now-decrypt-later exposure.
But the most difficult part of the transition will not be choosing between algorithm names. It will be discovering where cryptography exists, understanding which data and systems require early protection, coordinating vendors, modernizing PKI, updating protocols, testing performance, replacing legacy technology, and building enough crypto agility to manage future changes. Businesses do not need to migrate everything tomorrow. They do need to understand what they will eventually need to migrate. The organizations that start with inventory, prioritization, testing, vendor engagement, and architecture modernization now can make the transition gradually. Those that wait for quantum computing to become an immediate threat may face the same migration under much greater pressure. Post-quantum readiness is not about predicting when quantum computing arrives. It is about making sure the business is not still dependent on vulnerable cryptography when it does.
Why Ficus Technologies?
At Ficus Technologies, we help businesses modernize security and infrastructure foundations so they can evolve with changing technology and security requirements.
Our expertise combines custom software development, cloud architecture, cybersecurity, DevOps, API integration, infrastructure modernization, and scalable platform engineering. This allows us to help organizations identify legacy dependencies, modernize cryptographic integration points, improve system interoperability, and design applications that are easier to update as security standards evolve.
Post-quantum migration requires more than replacing an algorithm. It requires architecture capable of supporting new protocols, certificates, integrations, vendors, and security controls without disrupting critical business systems.
Prepare your digital infrastructure for the next generation of security – with Ficus Technologies.
Post-quantum cryptography uses algorithms designed to remain secure against attacks from both classical and sufficiently powerful quantum computers.
Yes. NIST finalized ML-KEM, ML-DSA, and SLH-DSA as its first PQC standards in 2024, and organizations are encouraged to begin migration.
Not every system needs to move at the same time, but organizations should begin inventorying cryptography, assessing risk, and planning migration now.
It refers to attackers collecting encrypted information today so they can attempt to decrypt it in the future when more powerful quantum computing becomes available.
High-priority areas include PKI, TLS, VPNs, code signing, identity, long-lived sensitive data, critical infrastructure, embedded devices, and systems with difficult upgrade paths.
Crypto agility is the ability to replace or update cryptographic algorithms, protocols, keys, and certificates without redesigning the entire system.
Success...! 
