Category: Articles

The looming threat of quantum computing has created an urgent need to transition to post-quantum cryptography (PQC). Traditionally, cryptographic transitions have unfolded over decades, and the public-key algorithms that have secured digital communications and devices have been tested through years of real-world use. PQC algorithms haven’t had that same runway. However, organizations can’t afford to defer PQC migration until every implementation and dependency is fully in place.

Cryptographic migrations are typically expensive, time-consuming, and disruptive. Yet PQC migration guidance, requirements, and implementations are still maturing. The scale and current fluidity of the migration process raise the question: How do you commit to a complex, expensive, multi-year effort when things are still evolving?

Cryptographic agility allows you to update or replace algorithms as standards develop and requirements change, without the need for “rip and replace.” While the practice of cryptographic agility is not new, it’s a critical capability for maintaining quantum-resistant security and reducing risk in the PQC era.

01

What is cryptographic agility?

The National Institute of Standards and Technology (NIST) describes cryptographic agility as “the capabilities needed to replace and adapt cryptographic algorithms in protocols, applications, libraries, software, hardware, firmware, and infrastructures while preserving security and ongoing operations.” Essentially, crypto-agility enables organizations to migrate to new algorithms with minimal changes to code, configurations, or hardware.

Previous cryptographic transitions have demonstrated how slow this process can be and why crypto-agility is necessary. A good example is SHA-1, one of the most commonly used hashing algorithms of the late ‘90s and 2010s.

The research showing that SHA-1 is vulnerable to collision attacks — where attackers can create two different inputs that produce the same SHA-1 hash — first surfaced in 2005. But NIST didn’t begin restricting SHA-1 until 2011, and it took until 2022 to announce its full retirement, with the full phase-out not arriving until the end of 2030.

One of the reasons it took until 2011 to restrict SHA-1 was that at the time it was still difficult to carry out collision attacks. But backward compatibility, interoperability, and embedded legacy dependencies were also major contributors to a prolonged transition, according to NIST. Organizations still needed to verify legacy signatures, process previously protected information, and maintain connectivity with systems that had not yet adopted newer hash algorithms.

PQC migration has similar issues. But the scale is larger because many widely used cryptographic algorithms, not just one, need to be replaced within a limited time window. Organizations without built-in agility can face exactly this kind of drawn-out, disruptive timeline whenever an algorithm needs to be replaced.

02

Hybrid cryptography: practical application of crypto-agility

Cryptographic agility is not a single technique, and can encompass architecture, governance, and migration approaches. For PQC migration, multiple standards and security authorities, including NIST and the European Union Agency for Cybersecurity (ENISA), recommend a hybrid implementation.

A hybrid scheme combines a traditional algorithm with a PQC algorithm. Since PQC algorithms haven’t had the decades of scrutiny that classical algorithms have, hybrid schemes allows you to continue relying on well-tested traditional cryptography while the newer algorithms and their implementations mature. The idea is that if one algorithm has a newly discovered flaw, the system remains secure as long as the other algorithm holds.

Let’s say you configure two VPN gateways to use a hybrid IKEv2/IPsec exchange. The gateways use their existing methods to establish a shared encryption key, as well as ML-KEM — a post-quantum method — to add a second layer of protection when creating that key. The secrets produced by both methods are combined to create the encryption keys that protect data traveling through the VPN tunnel. The VPN’s encrypted traffic remains secure even if one of the methods fails.

A hybrid deployment allows you to reduce the risk of PQC migration because you can add protection against the quantum risk before you’re able to safely retire classical cryptography. It also gives you a longer transition runway when it’s not yet practical to use only PQC algorithms.

From an operational standpoint, hybrid deployment better enables a phased PQC migration based on your prioritized risks. Since you don’t have to change every application, connection, and vendor system at the same time, you’re also reducing the disruption to operations.

While hybrid schemes help avoid the need for a “rip-and-replace” approach, it may not be right for every organization. A 2026 Ponemon survey found that organizations are almost evenly split on their approach to the PQC transition: 36% plan a hybrid strategy, 35% will implement pure PQC, and 25% haven’t decided.

For those choosing the hybrid path, a complete move to PQC is still the end goal. Hybrid cryptography is designed to serve as a temporary bridge that enables security teams to begin migration while PQC implementations mature.

03

What a crypto-agile architecture looks like

A cryptographically agile architecture has three connected layers:

• Design principles that separate cryptography from application logic
• Technical components that allow algorithms and providers to be replaced
• Governance that directs, inventories, and manages those changes across the organization

At the system level, an agile design relies on crypto abstraction and modularity. You’re separating cryptographic logic from application code and making it easy to replace the components, rather than hardcoding a specific algorithm into every piece of software that uses it.

The technical layer contains the parts that must change when cryptographic policy changes. These may include algorithms and the software or services that provide them, protocol and connection settings, keys and certificates, and any specialized hardware or firmware used in cryptographic operations. For every component, you need a defined way to identify, replace, validate, and retire it.

Without governance, different teams may make conflicting decisions about what should change and when. NIST frames governance as a defined cryptographic policy that names an accountable owner, specifies which algorithms are approved, and gets communicated to IT teams, business partners, and vendors alike. The policy also needs to account for outside pressure such as regulatory mandates and industry standards.

Implementing a cryptographic bill of materials

A cryptographic bill of materials (CBOM) helps turn policy into an actionable migration plan. CBOM is an emerging extension of a software bill of materials (SBOM), an established practice in the software supply chain and a common requirement in federal software procurement.

Similar to how an SBOM provides a structured inventory of the software components and dependencies used to build an application, a CBOM does the same for cryptographic assets and dependencies. The CBOM can link the assets and dependencies to system owners, business criticality, compliance status, approved exceptions, remediation deadlines, and evidence of retirement. It’s an effective way to prioritize changes, assign accountability, track progress, and verify that legacy cryptography has been retired.

A CBOM also speeds up response when a cryptographic weakness emerges. By querying it to find which components are affected, you can quickly route remediation to the component owners.

04

Making the PQC transition sustainable

PQC migration is not a one-time project. Cryptographic agility enables the ongoing capability to manage cryptographic change. It minimizes disruption every time an algorithm needs to be replaced due to new standards, vulnerabilities, or policy requirements.

Agility also requires knowing your cryptographic posture in the first place — and tracking it continuously. Ciphersound’s free tool, Cipherscan, gives you the starting point for getting visibility into what you’re running across your systems. And if any of this raises questions specific to your environment, Ciphersound’s engineers are available to talk through it.

Many security leaders acknowledge that quantum computing could eventually undermine today’s public-key cryptography. Yet they defer action because that capability feels distant and uncertain while more pressing threats — such as ransomware and identity-based attacks — keep their security teams plenty busy.

However, post-quantum cryptography (PQC) is no longer solely a future concern, especially for federal contractors. Converging forces are making it an immediate priority:

• Deadlines for federal agencies’ PQC compliance are locked in, largely due to the recent Executive Order 14412.
• The timeline for the arrival of cryptographically relevant computers keeps narrowing.
• Confidential data with a long shelf life is already at risk from adversaries harvesting it today for potential decryption when cryptographically relevant computers are available.

Although no concrete PQC requirements exist yet for primary contractors and other federal supply chain vendors, federal agencies will likely start imposing them through the procurement process before 2030. But even organizations that are not subject to government mandates can’t afford delays. Those who are waiting for the frameworks to finalize or for “Q-Day” timelines to become more certain are putting themselves at both operational and competitive risks.

01

Risk 1: Rushed, compressed PQC migration

Migration to quantum-safe cryptography is not a simple software upgrade. Cryptography is embedded across multiple layers of the technology stack, from firmware and hardware to applications and protocols. Likewise, the transition to PQC involves many layers of the organization because it impacts operational continuity and relies on cross-functional collaboration.

Planning and executing the initial phases of PQC implementation will take large organizations — or those running their own IT —a combined four to six years, the UK’s National Cyber Security Centre estimates. This includes discovering your cryptographic inventory, assessing posture, creating a PQC migration plan, coordinating with vendors, replacing cryptographic libraries, and implementing other technical changes. You’ll also need organizational alignment, including leadership buy-in to prioritize quantum safety and allocate budget.

Many security and compliance teams are nowhere near the schedule they need to be on. In the defense sector, for example, only 43% of organizations planned to initiate a formal PQC adoption within the next two years, according to a Capgemini survey. Nearly half said they recognized the need but hadn’t prioritized it yet and didn’t expect to initiate a plan for another three to five years.

Attempting a complex, multi-year project on a compressed timeline is more likely to create problems. Those that delay may face higher costs, rushed technology choices, interoperability failures, and greater operational risk as customer or regulatory deadlines approach.

02

Risk 2: The threat of ‘harvest now, decrypt later’ attacks

Security experts have warned that well-resourced threat actors may already be collecting encrypted data with a long sensitivity life to decrypt it when quantum computers can break current encryption. Global connectivity and low-cost data storage enable adversaries such as nation-state actors to launch these “harvest now, decrypt later” (HNDL) attacks at scale.

Academic research shows that HNDL attacks are economically viable across major TLS and SSH protocols. Palo Alto Networks’ Unit 42 researchers have observed HNDL-like behavior in the wild, with attackers rapidly exfiltrating data in massive quantities earlier in an intrusion.

Attackers’ speed has also gone up, giving security teams much less time to prevent data exfiltration: Separately, Unit 42 found that exfiltration time has decreased from 285 minutes in 2024 to 72 minutes in 2025. The challenge of detecting an intrusion and preventing exfiltration is even worse if the data is protected by non-PQC algorithms.

Information that needs to remain confidential for the next 10-15 years is especially at risk because it may retain its value into the quantum era. This includes the type of data that federal contractors often handle, such as government records and defense communications.

Organizations acknowledge this risk but are not necessarily acting on it. A Ponemon study found that 59% of security practitioners are concerned about the exposure of long-term sensitive data, yet only 38% are actively preparing for post-quantum.

03

Risk 3: Broken digital trust

A less discussed but equally significant threat is what security experts call “trust now, forge later” (TNFL). While HNDL compromises data confidentiality, TNFL undermines the authenticity of digital signatures. These signatures are fundamental to establishing trust in software, identities, and communications, including through code-signing certificates and certificate authorities.

Adversaries could retain public keys used today until quantum computers are capable of deriving the corresponding private keys. They could then forge signatures to impersonate legitimate vendors, identities, or networks.

This threat is relevant now because many systems use certificates with long lifetimes. Signed software, devices, trust anchors, records, and identity systems may remain in service for years. An adversary who captures a public key and digital signature today could impersonate an organization when cryptographically relevant computers emerge.

The threat actor could assume the authority associated with the compromised signing key, producing digital signatures that would be indistinguishable from genuine ones, even if backdated. That could make it very difficult for the legitimate organization to prove that a disputed signature was forged.

For the broad segment of the federal supply chain whose systems depend on code integrity and identity verification, this risk warrants the same level of consideration as HNDL, even though it gets far less attention.

04

Risk 4: Vendor and supply chain gaps

Most organizations don’t build their own cryptographic systems from scratch. Their cryptographic posture is highly dependent on partners such as cloud providers, software vendors, and managed services providers. Consequently, many expect to outsource their PQC migration as well — 62% of organizations surveyed by IBM believe vendors will handle the transition requirements for them.

In principle, outsourcing quantum-safe readiness takes care of the technical aspects of the problem. But how do you know your vendors and partners have completed the necessary steps? Are you leaving governance and ownership gaps in the process? Who’s accountable for any failures? Shifting the risk to your supply chain doesn’t eliminate it.

05

Risk 5: Mounting PQC compliance pressure

Governments around the globe are increasing their emphasis on PQC adoption and accelerating its transition timelines. In the United States, Executive Order 14412 set hard deadlines for high-value and high-impact federal civilian systems, while CNSA 2.0 provides a transition path for National Security Systems. These timelines will likely affect the federal supply chain through the procurement process.

But organizations not directly subject to government mandates may still face comparable pressures. Customers, business partners, and insurers are focusing on PQC readiness:

• Enterprise buyers are adding PQC readiness checks to their vendor assessment and procurement processes. Among early adopters of quantum-safe solutions, 70% said they view the PQC transition as essential to remaining competitive.
• Other regulated-sector partners may flow their security requirements into their supplier contracts. Digital Operational Resilience Act (DORA), which applies to financial entities, is one example. Although it doesn’t explicitly mandate PQC, its requirements establish a strong case for practices such as maintaining cryptographic agility and assessing information and communication technology suppliers for PQC readiness.
• Cyber insurers are beginning to explore quantum-aware risk modeling. They may assess quantum-related cryptographic risk as an emerging underwriting consideration, including through PQC-readiness questionnaires.

This shift also creates an opportunity for compliance consultants to help their clients proactively. As more organizations start asking questions about PQC, those who can bring a credible solution to a client engagement will have a competitive advantage.

06

The cost of waiting could add up substantially

A delayed transition doesn’t just affect your migration timeline. A rushed process could turn migration into an emergency hardware or software replacement project or lead to accelerated overhauls of key-management systems rather than phased replacements. You may need to switch multiple suppliers and systems simultaneously.

The potential consequences are increased risk and cost — and budget constraints are already one of the top three barriers to becoming quantum-safe.

Major technology and infrastructure providers such as Google, Microsoft, and Cloudflare are already rolling out PQC across their platforms. As this transition spreads through the ecosystem organizations depend on, those that haven’t kept pace may encounter a compatibility problem.

What happens if your systems, algorithms, libraries, or protocol configurations aren’t compatible with PQC algorithms? Service outages, connection failures, and latency or capacity issues could disrupt operations and potentially erode customer trust.

Taken together, the potential for additional costs, lost opportunities, and operational disruptions could materially affect the bottom line. A phased migration that starts now helps you mitigate security, operational, and financial risks.

07

Taking the first step doesn’t have to be complicated

The window for a deliberate transition is narrowing. Migration takes years, while compliance, procurement, and security pressures continue to build. Starting earlier gives organizations more room to plan rather than react.

You don’t need to wait for government mandates or partner requirements to solidify your plans. The first step is the same regardless of what framework or assessment process eventually applies to your organization: understanding your risk exposure.

Ciphersound’s free tool, Cipherscan, gives you a fast, low-friction starting point to assess your cryptographic posture. Start with visibility and use concrete data to build the case within your organization.

The looming quantum computing threat has prompted federal mandates for the migration to post-quantum cryptography (PQC). While earlier PQC compliance frameworks and implementation timelines were ambiguous, the directives are now moving faster. Executive Order 14412 sets concrete deadlines for high-value federal systems, and federal contractors should expect that pressure to reach the supply chain soon.

The recent Executive Order 14412 sets clear deadlines for high-value federal systems and signals what’s to come in federal procurement. Even as the rules affecting the downstream supply chain ecosystem are pending, federal contractors should expect increasing PQC compliance pressure.

The potential timelines for the arrival of cryptographically relevant quantum computers have also accelerated in recent months. Long-value data such as government records is already vulnerable to “harvest now, decrypt later” attacks.

The convergence of all these forces makes it clear that federal contractors must act now. This guide explains what federal contractors need to know today about PQC.

What is PQC and why has it emerged as a requirement?

Security experts have long known that quantum computers would be capable of breaking today’s cryptographic systems. The encryption that digital communications and transactions have relied on for decades is based on complex mathematical problems. Classical computers would need potentially billions of years to solve these. A sufficiently capable quantum computer could reduce that to hours or less.

Nobody knows when “Q-Day” will arrive. Some industry projections place it as early as 2030. Recent research from Google and other scientists has lowered the estimated quantum resources needed to break widely used public-key cryptography, and progress is being made on other fronts, including hardware.

These developments further increase concerns that cryptographically relevant quantum computers could arrive sooner than expected. Google has accelerated its own PQC migration target. So have other major infrastructure providers, including Microsoft and Cloudflare.

Whenever the day arrives, the implications would be widespread. A range of systems relying on public-key cryptography could become vulnerable, including:

• Encrypted connections: data transmitted through VPNs, TLS, email, and cloud traffic could be decrypted.
• Authentication and verification: digital signatures and certificates that authenticate software, identities, and communications could be forged.
• IT infrastructure: applications, web browsers, APIs, and cloud platforms could be compromised.
• Embedded systems: IoT devices, sensors, and operational technology may be difficult, or impossible, to upgrade without significant disruption.

Despite the uncertainty around timing, adversaries are not waiting. National security authorities have warned that nation-state actors could collect encrypted data now to decrypt once quantum computing catches up. HNDL attacks put data that needs to stay confidential for years at immediate risk: 56% of respondents in an ISACA poll cited HNDL attacks as a concern.

PQC compliance, readiness, and “quantum-safe”: what’s the difference?

These terms are related but shouldn’t be used interchangeably. They represent different states:

• PQC readiness describes your organization’s preparedness to migrate to PQC, a pre-migration phase that starts with understanding your cryptographic posture, prioritizing risks, and creating a migration plan.
• Quantum-safe means your migration is complete, with quantum-resistant cryptography fully deployed and enforced, including the cryptographic agility to adapt as standards mature.
• PQC compliance is its own category: checking the boxes a specific framework sets. As with security in general, you can be fully compliant but not fully protected.

The quantum-resistant algorithms and their implications

NIST’s release of three quantum-safe standards in August 2024 marked a shift from PQC research to implementation, based on three algorithm types:

• FIPS 203 uses ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) as the primary standard for general encryption, letting two parties securely establish a shared key.
• FIPS 204 uses ML-DSA (Module-Lattice-Based Digital Signature Algorithm) as the main standard for protecting digital signatures.
• FIPS 205 uses SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) as a hash-based backup if ML-DSA becomes vulnerable.

In practice, FIPS 203 protects data confidentiality (including against HNDL attacks), while FIPS 204 and 205 support authenticity and integrity. A migration plan needs to address both functions long term. Note that a given mandate may not call for every standardized algorithm: CNSA 2.0, for instance, specifies ML-KEM and ML-DSA but doesn’t currently approve SLH-DSA.

What PQC compliance means for federal contractors today

As of August 2026, no framework broadly applicable to federal contractors mandates PQC outright yet. That doesn’t mean compliance and security teams can relax: provisions for quantum-safe solutions are already influencing procurement decisions.

Cybersecurity Maturity Model Certification (CMMC)

CMMC Level 2 is built on NIST SP 800-171, Revision 2, which includes FIPS-validated cryptography but doesn’t prescribe a PQC migration deadline or specific algorithms. However, a new U.S. Department of War PQC strategy published in June calls for adding PQC to CMMC requirements, with a December 31, 2031 deadline for DoW systems. CMMC’s third-party certification requirement is currently paused pending a Reform Task Force review, but the underlying NIST 800-171 obligation remains in force.

CNSA 2.0

CNSA 2.0 has more granular, concrete timetables for National Security Systems:

• January 1, 2027: new NSS acquisitions must be CNSA 2.0 compliant
• December 31, 2030: phase out equipment and services that can’t support PQC/CNSA
• December 31, 2031: full use of CNSA 2.0 algorithms
• 2030: software and firmware signing, traditional networking equipment
• 2033: web browsers and servers, cloud services, operating systems, niche devices, large PKI, custom applications, legacy equipment

FedRAMP

FedRAMP generally requires cryptographic modules validated to FIPS 140 standards. A cloud service provider would need to implement FIPS 203 to 205 using FIPS 140-validated modules before deployment, a process that can take years. FedRAMP-authorized PQC won’t be widely available until validation catches up, though some providers, like Cloudflare with its recent FedRAMP High authorization, are already moving ahead.

What contractors need to do now

Waiting for mandates to finalize is not a viable strategy. Migration is a complex, multi-year effort involving multiple functions and systems, and many CISOs are already behind. The risks of delay range from competitive disadvantage to increased cost.

Regardless of framework, understanding your cryptographic posture is one of the critical first steps. You have to know your exposure before you can build a plan to mitigate it.

Get started with a simple tool

PQC posture assessment can feel like a heavy lift because cryptographic inventory platforms are typically built for enterprise environments, with pricing and complexity to match. Ciphersound offers a simple tool that compliance and security teams can use immediately, at no cost, without waiting for budget approval or a procurement cycle.