Quantum ready: A practical guide to enabling PQC with F5
Quantum computing is on the horizon, and it’s set to upend the cryptographic systems that protect our data, communications, and infrastructure. The time to start preparing is now. In this six-part blog series on post-quantum cryptography (PQC), cryptography thought leaders from across F5 will explain what’s at risk, what opportunities lie ahead, and what steps your organization can take today to stay secure in a post-quantum world. The future is closer than you think. Let’s get ready together.
Post-quantum cryptography (PQC) isn’t a “someday” problem—it’s already shaping how we build secure systems. Quantum computing threatens today’s encryption, and “harvest now, decrypt later” is already in play. With FIPS 203 now ratified and supported in F5 BIG-IP v17.5.1, part of the F5 Application Delivery and Security Platform, you can start deploying hybrid PQC key exchange in production.
Why PQC matters now
FIPS 203 (ML-KEM, based on Kyber) is the first U.S. National Institute of Technology (NIST) approved post-quantum algorithm for public key encryption and TLS key exchange. Without PQC, long-lived data in transit can be collected now and decrypted later. That means APIs, customer portals, and sensitive B2B exchanges are at risk even before large-scale quantum computers exist.
This makes hybrid PQC a priority today—especially for systems that protect personally identifiable information, payment details, or proprietary data.
Think of hybrid PQC like wearing both a seatbelt and an airbag. Today’s classical cryptography (like RSA or ECC) is still strong against everyday attackers, but quantum computers will eventually bypass it. By combining traditional methods with post-quantum algorithms in the same handshake, systems get two layers of protection: the proven security of what we use today, plus the quantum-resistant layer that protects against tomorrow’s threats.
From a practical standpoint, hybrid PQC means your browser, app, or API connection establishes keys using both an established algorithm (say X25519) and a PQC algorithm (like ML-KEM). If either one holds up, your data remains safe. This is important right now because we’re in a transition period: the old methods are widely deployed and efficient, while the new ones are still being tested, standardized, and rolled out. Hybrid ensures nothing breaks for compatibility, while still closing the “harvest now, decrypt later” loophole.
That’s why regulators and standards bodies like NIST recommend hybrid adoption: it’s a practical way to protect sensitive data flows today, while giving organizations time to test, tune, and prepare for a full post-quantum future.
Where to start with PQC deployment
The first step is enabling PQC on your most exposed TLS endpoints—such as login portals, web apps, and APIs—before expanding to internal services. Edge termination points, like CDNs and API gateways, are natural early targets since hybrid key exchange can be applied here without altering backend systems.
How enterprises can use PQC between the client and F5 BIG-IP as well as between BIG-IP and a PQC-enabled server.
The benefits of implementing PQC with F5
Adopting PQC on your web applications isn’t only about checking a compliance box—it is about building resilience into your security architecture. With FIPS 203 (ML-KEM) now ratified and supported in BIG-IP v17.5.1, F5 customers can begin enabling hybrid PQC at the edge, where it delivers the greatest risk reduction with the least operational disruption.
One of the biggest benefits comes from centralization. By deploying PQC on the F5 platform, organizations can add quantum-resistant protection to TLS without refactoring every individual application. This means sensitive portals, APIs, and B2B exchanges gain protection against “harvest now, decrypt later” attacks through a single point of control. It also simplifies audit and compliance reporting—critical as agencies like the U.S. Cybersecurity & Infrastructure Security Agency (CISA) and standards bodies like NIST push for accelerated post-quantum readiness across both government and private industry.
Performance and compatibility also matter. Hybrid key exchange allows for the combination of an efficient classical algorithm like X25519 with ML-KEM, ensuring that traffic is still compatible with today’s browsers and clients while gaining the added quantum-safe layer. Because TLS termination already happens within BIG-IP, organizations can take advantage of its optimization capabilities to offset some of the computational overhead PQC introduces. This reduces the performance trade-off that would otherwise be borne directly by application servers.
Finally, there is a strategic benefit. Implementing PQC with F5 positions organizations as early adopters in a rapidly evolving security landscape. Customers, regulators, and partners are increasingly asking for assurance that data will remain secure against future threats. Being able to point to F5-enabled PQC in production demonstrates both technical leadership and a commitment to long-term data protection. In many industries, that can be a differentiator.
Getting ready for the quantum shift
PQC isn’t just a one-time change—it’s the start of a continuous evolution in cryptographic standards. Begin with your most exposed services, then expand. Discuss PQC readiness with partners, and plan for periodic reviews as new standards emerge.
Key takeaways:
- Enable TLS 1.3 and test hybrid PQC in development
- Prioritize public-facing APIs, login flows, and sensitive data paths
- Track FIPS 204/205 for post-quantum signature support
- Build reporting and key-rotation processes into your roadmap
Stay tuned for the final blog post in our series in which we go beyond PQC to discuss taking a holistic approach to mitigating quantum risks.
Also, be sure to check out our previous blog posts in the series:
Apps, networks, and legacy systems in the quantum crosshairs: A CISO’s POV
Understanding PQC standards and timelines