Your Encryption Has an Expiration Date. Here’s What That Means for the Systems You’re Building Now.
The tech industry, academia, and governments have known for years that the encryption securing most of the world’s digital systems — think financial transactions, healthcare records, government communications, and enterprise networks — will not survive quantum computers. The mathematical equations that make today’s encryption hard for classical computers to solve are just the problems quantum computing is being built to solve.
Globally, the response has been in development for a decade. The January 2027 deadline is documented in NSA's CNSSP 15 guidance. The date is already inside the planning window for programs in active acquisition today, given that defense acquisition cycles typically run 18 to 36 months.
Before we discuss the architecture decisions this creates, let’s make sure the underlying concepts are clear.
What is post-quantum cryptography? What is NIST’s role in it? What is CNSA 2.0, and why does the January 2027 deadline matter?
And most importantly: what decision does all of this create for technical and program leadership today?
The Problem: Encryption That Doesn’t Survive Quantum
Most encryption in use today, protecting your email, your VPN, your organization’s network perimeter, relies on mathematical problems that are computationally hard for classical computers to solve.
Specifically, it relies on the difficulty of factoring very large numbers or solving discrete logarithm problems. These problems take classical computers so long to crack that the encryption is effectively unbreakable in practice. Quantum computers, using a fundamentally different computational model, can solve these problems orders of magnitude faster. A sufficiently powerful quantum computer could break RSA-2048, one of the most widely used encryption standards today, in hours rather than the billions of years a classical computer would require.
It is worth mentioning that quantum computers rely on specific environmental variables to achieve their operational state. We don’t have a quantum computer powerful enough to crack RSA-2048 in yours yet. But two reasons make action urgent now.
First, building quantum-resistant systems takes years. The design, procurement, testing, and accreditation cycles in complex organizations are all long.
Second, adversaries are already collecting encrypted data today with the intention of decrypting it later when the capability exists.
That active threat occurring today is known as "harvest now, decrypt later" and is not theoretical. It is an active, ongoing collection strategy against sensitive data with long classification lifespans.
The Response: NIST PQC Standards
In August 2024, the National Institute of Standards and Technology finalized the first three post-quantum cryptography standards; new algorithms that are mathematically resistant to both classical and quantum attacks. These standards were selected through a rigorous, years-long international competition to identify encryption algorithms that can withstand quantum attacks. They are not experimental: they were chosen through years of analysis by the global cryptographic research community, tested for weaknesses, and hardened through multiple rounds of evaluation.
When you see ‘PQC migration’ or ‘quantum-safe cryptography,’ the reference is to replacing current vulnerable algorithms with NIST’s finalized standards. Post-quantum cryptography, or PQC, is simply the category name for these quantum-resistant encryption algorithms. For organizations that handle sensitive data, operate under federal contract requirements, or build technology systems with any regulatory exposure, the migration is not optional. It is a matter of when and how, not if.
The Mandate: CNSA 2.0 and the January 2027 Gate
The NSA’s Commercial National Security Algorithm Suite 2.0, CNSA 2.0, specifies which post-quantum algorithms to use, at which parameter levels, and by when. It is the most operationally specific quantum cryptography requirement in the world as of this writing: it names exact algorithms, sets deadlines by system category, and connects those deadlines to procurement eligibility. Organizations that cannot demonstrate compliance lose access to certain contracts.
January 1, 2027, is the most immediate deadline: all new acquisitions for National Security Systems must support CNSA 2.0-compliant algorithms; otherwise, they cannot be deployed. This is a hard gate. Not a guideline, not a target, not a suggestion. A system delivered after that date without compliant cryptography is non-compliant from day one, regardless of how good the rest of the design is.
The 2027 date matters for programs currently in active acquisition because it falls within a typical defense and government procurement cycle. The longer timeline extends well beyond 2027, with full transition across all covered system categories not required until 2033 to 2035. Systems being designed today will meet this requirement. That design decision is happening now, whether or not it is being made consciously.
The Architecture Decision This Creates
Here is where the policy briefing ends, and the architecture conversation begins.
The standard response to a compliance mandate like this is to treat it as a future checkbox: inventory the systems, identify the gaps, schedule the remediation, update the plan. That approach is appropriate for some deadlines. It is the wrong approach for a cryptographic migration, for one specific reason: cryptography is not a layer you add to a system. It is embedded in the design.
Every system your organization is building or buying right now makes assumptions about cryptographic algorithms: in communication protocols, key management architecture, authentication mechanisms, and the handling of data at rest and in transit. Those assumptions are baked into the design. The organizations that will navigate this transition at the lowest cost are those building systems today with what cryptographers call crypto-agility. That is the ability to swap cryptographic algorithms without redesigning the underlying system. That design pattern has to be a conscious architecture decision. It does not emerge naturally from a standard engineering process.
For every significant technology system your organization is currently designing, procuring, or contracting for, ask this question: Does it have a clear path to post-quantum cryptographic compliance, and is that path part of the design? Or is it an assumption that someone will figure out later?
The Bottom Line
For systems in active acquisition, post-quantum cryptography is a 2026 design decision, not a 2030 problem that can be addressed with a 2029 plan. The organizations that treat it as a compliance deadline to be managed will spend significantly more money remediating systems that weren’t built to accommodate the transition. Organizations that build crypto-agility into their architecture requirements now will meet the mandate without rework. That difference is made at the design stage — before the contract is signed, before the engineering team is stood up, before the system is built.
That is the decision to make this year.