Preparing your organization for the quantum future

Recently, we’ve shared a lot about post-quantum cryptography, the great work we’re doing to make it available to you through our products, and the importance of preparing for a future with quantum computers powerful enough to break classic RSA-based cryptography. You may have heard about “Q-day,” the day when a cryptographically relevant quantum computer (CRQC) is available to break public-key encryption–the underpinning of our digital world today. If you missed it, this risk is real, and proactive organizations are already preparing for it. Q-day is predicted to occur between 2029 and 2032, so now is the time to prepare.

The core issue at hand is that many of our current cryptographic systems, like RSA, rely on mathematical problems that are simple for classical computers to do in one direction, but extremely difficult to reverse. For example, multiplying 2 large prime numbers is simple, but factoring the result back to its original prime numbers is very hard. This is modern public-key cryptography, also called asymmetric cryptography. In contrast, symmetric cryptography relies on a single shared secret key for both encryption and decryption and requires a secure method for sharing that secret key beforehand. With public-key cryptography being the most common and practical way for computers to share that secret, we must also be aware that CRQCs can weaken the effectiveness of symmetric keys in addition to compromising the most common method by which those keys are shared.

CRQCs can do factoring at a scale and speed that is impossible with existing computers. Instead of multiple lifetimes, RSA can be broken in seconds. New cryptographic algorithms are needed to resist these new attacks, and those new algorithms (e.g., ML-KEM, ML-DSA, SLH-DSA) are available for you to start using today.

Beyond a simple update

The transition to PQC is not a simple matter of installing a software patch. It’s a complex, multiyear process that requires a fundamental shift in how you manage your digital security. There are 3 main considerations for you to understand.

Your upstream dependencies

The cryptographic libraries you rely on, such as OpenSSL, NSS, and GnuTLS, are developed by communities of open source volunteers. These libraries are pulled in and made available in operating systems (OSs) or called by applications. The pace of development in open source is unpredictable, and while PQC algorithms are being integrated today, not every library, package, or application has adopted them yet. In some cases this is because of a lack of time; in other cases, developers are waiting for the Internet Engineering Task Force (IETF) Requests for Comments (RFC) to be finalized so that correct implementation can be done. IETF RFCs allow for global interoperability of the internet.

Industry must draw a line in the sand to move forward from

Don’t expect PQC algorithms to be backported to the oldest version of your favorite OS. Doing so would require older versions of software to change their internal data structures and functions to accommodate changes needed to their interfaces, making the existing function calls, data sizes, and structures no longer compatible. Not to mention, it would involve substantial engineering efforts to make that happen without breakage.

Think of your current software like a gasoline-powered car, and PQC is the new, powerful electric vehicle. You can’t fill your car’s gas tank and expect it to work like an electric motor. The entire vehicle’s internal structure—engine block, fuel lines, brakes—is different because of the new power source. PQC is the new “engine” for cryptographic functions, and you’ll have to get a new ‘car’ that was designed for it.

Understanding how and where you use cryptography

Transport Layer Security (TLS) 1.3 and future versions will support PQC, but older versions will not. If you’re not using TLS 1.3 today, now is the time to start. If your teams use Java, you will likely need to move to Java 25. However, if you’re using BouncyCastle 1.79, then you can use Java 17. If your teams are using python, you’ll need to wait until Python has support for PQC. Now is also the time to contribute to and participate in open source projects, supporting volunteers in meeting the entire industry’s needs.

Expect a hybrid transition

It took 2 decades for the industry to move from Data Encryption Standard (DES) to Advanced Encryption Standard (AES). Therefore, we can expect this transition to be long, with both classical and post-quantum systems co-existing. Some systems will default to classical cryptography, but can support PQC when configured to do so. Eventually, we’ll move to PQC as the default, with classical cryptography configured where absolutely needed. As you can imagine, this is a significant undertaking that needs a lot of coordination, planning, and a strategic approach.

A business imperative, not just a technical challenge

As a leader in your organization, you’ll want to make sure that your teams are asking the right questions to prepare your organization for adopting, testing, integrating, and beginning to use PQC as it becomes available. To initiate discussions within your organization about its readiness, we recommend the following questions:

Do we have an accurate inventory of our cryptographic usage? Where are our keys, certificates, and algorithms being used across the enterprise, and what components are responsible for providing them?

Answering this question provides the foundational understanding of your current cryptographic attack surface. This inventory is critical for identifying quick wins for early PQC adoption, prioritizing systems for migration and understanding the scope of the cryptographic transition. Without an inventory, any PQC strategy will lack precise targets and could miss critical vulnerabilities.

Have we identified our high-value assets and high-impact systems to prioritize for PQC migration?

This answer directly informs your PQC migration roadmap and resource allocation. High-value assets (e.g., intellectual property, sensitive customer data) and high-impact systems (e.g., critical infrastructure, core business applications) should be prioritized for PQC readiness. This helps prioritize that the most critical parts of your organization are addressed first, minimizing business disruption and risk during the transition.

What are our software and hardware vendors’ roadmaps for PQC? Are their solutions aligned with NIST PQC standards and commonly understood transition timelines that place Q-day roughly in 2030?

Understanding your vendors’ PQC roadmaps is essential for developing a realistic and achievable PQC strategy. This information will influence your purchasing decisions, system upgrades, and overall migration timeline. If a strategic vendor is not aligned with NIST or international standards or common timelines, it could introduce significant delays or require alternative solutions, which need to be factored into your strategic planning.

Is our architecture designed for crypto-agility? Can we switch out cryptographic algorithms and key sizes easily? Or does this require a significant overhaul of our systems?

The answer to this question determines the complexity and cost of your PQC migration. Systems designed with crypto-agility will have a smoother and less disruptive transition. If your architecture lacks crypto-agility, all of your systems need to move in unison, requiring synchronization across your organization and increasing the probability of failure. Therefore, your strategy must include significant re-architecting efforts to account for this, potentially requiring more time and resources. This understanding helps in forecasting the scale of work required.

What are our suppliers, partners, and customers doing about PQC? How will we ensure secure, end-to-end communication as we all transition?

Your organization does not exist in a vacuum. The PQC transition will be a collective effort. Understanding the PQC readiness of your supply chain, partners, and customers is crucial for maintaining secure, end-to-end communication and collaboration. Your strategy must include plans for interoperability, communication protocols, and potentially shared timelines to ensure a smooth transition across your ecosystem.

Are we planning for PQC in our upcoming hardware and software purchases, ensuring they are capable of post-quantum cryptography?

This question addresses the proactive element of your PQC strategy. Integrating PQC requirements into your procurement processes for new hardware and software will prevent the acquisition of “crypto-legacy” systems that will require immediate upgrades or replacement. This forward-looking approach ensures that new investments are ready for the future, minimizing technical debt and maximizing cost-effectiveness in the long run–similar to the Y2K readiness of the late 1990s.

Conclusion

The move to post-quantum cryptography is more than a technical upgrade; it’s a critical business necessity that requires immediate action. By proactively assessing your organization’s cryptographic landscape, prioritizing high-value assets, understanding vendor roadmaps, fostering crypto-agility, and collaborating with your ecosystem, you can navigate this complex shift effectively. While the journey will be long and involve a hybrid approach, the time to prepare for Q-day is now–not tomorrow. Securing your digital future against the quantum threat requires foresight, planning, and a commitment to integrating PQC into the core of your security strategy.