Integrating PQC into federal procurement

Steve WallaceField CTO - Federal | F5

It’s been at least two years since 2030 surfaced as a likely timeframe for Q-Day, and quantum computing has since gained tremendous velocity. The actual date of Q-Day is less consequential than it may seem; however, the threat to data integrity has already arrived.

Adversaries are already engaging in “harvest now, decrypt later” attacks, storing encrypted data in preparation for future exploits. That makes it urgent to implement post-quantum cryptography (PQC)—or at least, hybrid PQC—today to protect the bedrock of information security.

Public sector data may be especially vulnerable

This challenge looks especially hairy in the public sector. First, classified information, military secrets, and citizen identity credentials make particularly tempting targets for some malevolent actors.

Second, F5 Labs research has found that government agencies in the United States lag behind nearly every other industry, even for simple website PQC protection, with just 42.7% adoption. When automated PQC or hybrid ciphers provided by default through CDNs and cloud-native hyperscalers are removed, the figure drops even lower, to 23.1%.

This lower figure is probably a more realistic characterization of true quantum readiness in federal agencies, especially when considering that protection for infrastructure, device encryption, secure communications, or other domains cannot be provided by a CDN’s default cryptographic choices.

According to F5 Labs research, government websites in the United States trail nearly every other major industry in PQC adoption, at just 42.7%—or 23.1% when default protection via CDNs is excluded.

Third, public sector organizations are often saddled with additional statutory requirements that rarely allow them to be as nimble as enterprises in other industries. Every organization faces financial and resource constraints, but few have to navigate the cumbersome procurement processes and legally mandated decision criteria involved in federal investments.

How public procurement cycles pose particular challenges

I spent more than two decades working for the U.S. government, with more than half of that time at the Defense Information Systems Agency (DISA) and the last seven years serving as its CTO. I am familiar with the ins, outs, and lengths of federal procurement cycles. Many of those gates and requirements exist for a valid reason. However, they rarely move at the pace of the threat.

Having lived through the introduction of cloud computing and, more recently, the early years of agency AI adoption, I’ve seen up close how the lengthy budgeting and acquisition timelines of federal procurement can make it challenging to keep up with technologies that advance quickly. I also recall the difficulty agencies consistently faced, at least during my tenure, in matching procurement requirements to the state of the market at the time.

Accurately translating requirements into realistic specifications, which usually requires clear, bi-directional communication with vendors, was often a challenge. The use of Other Transactional Authorities (OTAs) and Challenge-Based Responses helped, but there’s still room for improvement.

No matter how well a decision maker anticipates trends and identifies how to best respond, procurement and deployment tend to lag behind current best practices, innovations, and integrations. When selecting the procurement methodology, choose flexibility and allow for growth. Too frequently I saw the Lowest Priced Technically Acceptable (LPTA) standard, result in investments that satisfied basic procurement requirements but lacked the flexibility to evolve as technologies change. The approach often frustrated both industry and government personnel ultimately tasked with these solutions. Plus, it’s hard to appropriately implement the results if the requirement evolves beyond the very strict dimensions of the LPTA procurement. With IT rarely remaining static, this becomes nearly impossible.

In addition, federal buyers often favor long-term support agreements or vendor lock-in simply to boost the return on their procurement efforts. But long-term commitments can reduce agility in this era when technologies—and the ideal combinations of them—can shift before the ink dries on the contracts. Even more importantly, security guardrails are too often considered only after adoption, as an afterthought.

For digital transformations such as migration to a cloud-first strategy, the consequences of clumsy or delayed procurement decisions were primarily financial or operational. Perhaps a move intended to save money didn’t, or efficiency benefits didn’t play out as expected. Mistakes could be addressed by app repatriation, different cloud providers, or shifts in the balance between on-premises and cloud deployments in a hybrid architecture. Similarly, a mistake in AI adoption might only require use of better training datasets, a different model, or fine-tuning the model on in-house data.

When it comes to implementing PQC, however, the consequences of decisions that are wrong or too slow could be catastrophic. There’s no going backward from a massive data breach resulting from broken cryptography. No agency can afford to make procurement mistakes that expose national security systems, sensitive communications, or other high-value federal assets to quantum attack. Especially when data flows around the world rather than simply between two sovereign locations, it passes through places that may not be friendly or completely safe. Those are ripe for “store now and decrypt later” exploits.

Fear of mistakes is not an excuse, however, to delay making decisions at all. Decision makers in the public sector can’t afford to see what shakes out between now and 2030, because procurement and deployment will likely consume most of the time between now and then.

Move PQC from afterthought to forethought

Don’t underestimate the amount of time it takes to replace cryptography solutions. I’ve been eyeballing PQC issues since my first briefing about it in 2019, and it’s been near and dear to my heart ever since. But it’s taken a while to reach broader notice—and even longer, it seems, to stimulate much action. The F5 2026 State of Application Strategy Report found that while two-thirds of organizations have assessed their PQC risks, only 27% are starting to act. We need to stop admiring the problem and get to work now.

The National Security Agency (NSA) has repeatedly updated and clarified its Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) since its 2022 release. This past summer, U.S. Executive Order 14412 formally launched what will likely turn out to be the largest cryptographic migration in history. The order was followed shortly by Office of Management and Budget Memorandum M-26-15 to serve as an implementation playbook for federal civilian agencies. They’re required to transition toward PQC standards approved by the National Institute of Standards and Technology (NIST), with compliance expected by December 31, 2030. This aligns with the official NIST deadline for deprecating legacy encryption algorithms. For national security systems governed by NSA rules, the first major procurement gate arrives even sooner, on January 1, 2027.

More guidance is pending. We’re less than two months from the Dec. 19, 2026, deadline for the Federal Acquisition Regulatory (FAR) Council to release its first proposed rule to require covered contractors to comply with NIST-approved PQC standards. But don’t wait for that rule. Three NIST-approved standards—namely FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA)—and hybrid PQC cryptography already exist to support realignment. FIPS 203 and 204 are in CNSA 2.0.

How to get started today

So, start now toward PQC compliance. Here’s how:

1. Plan for ongoing change. First, recognize that PQC compliance will not be a “one and done” change. Agencies—and their leading contractors and vendors—already have what’s needed to take the first steps, but NIST and NSA will continue to advance additional candidate algorithms. Continuous protection will mean constant evolution, not ironclad commitment to any one algorithm or hybrid solution. Be wary of lengthy contract or deployment timeframes. Agility will also require continuing to ask smart questions up front and evolving procurement and contract language with the technology.
2. Start now. Whether under age-old contracts or new ones, ensure that every new deployment aligns with PQC—starting today, not in 2027 or 2030. Make sure partners deliver solutions that are compliant coming in through the door. It may be tempting to bolt on guardrails later. Don’t risk it.
3. Demand insight. When communicating with technology vendors and identifying RFP criteria, require interoperability testing, PQC performance metrics, and a cryptographic bill of materials to fully understand the algorithms, key sizes, digital certificates, and protocols used in solutions and tools. That will help you recognize contractors and vendors who are effectively keeping up with change—so your systems can, too.
4. Build for agility. Deploy platforms that are programmable and that can and will evolve as additional standards are advanced. The F5 Application Delivery and Security Platform (ADSP) is one example, providing built-in PQC compliance with ML-KEM and hybrid cipher support and quantum-secure VPN tunneling.

Quantum computers are a direct threat to the security of information and infrastructure. Their looming presence on the horizon today makes the transition to PQC an urgent necessity, not merely a cost-savings or efficiency move—unlike typical cloud or AI deployments. Encryption is the under-appreciated bedrock of information security, and the stakes of its potentially imminent demise are far higher than most operational decisions. Work carefully with experts to expand your knowledge, avoid deployment mistakes, and ensure national assets remain protected.

Above all else, don’t panic F5 is ready to help. Explore F5 public sector solutions.

About the Author

Steve WallaceField CTO - Federal | F5

More blogs by Steve Wallace