Your Encryption Has an Expiration Date: NIST Has Started the Clock
Published 9 October 2026
Quantum computers have been “just around the corner” for long enough to make even patient IT managers vaguely suspicious.
Nobody knows exactly when a quantum computer powerful enough to defeat some of today’s most widely used public-key cryptography will arrive. It may be years away. Who knows? One thing is certain: It won’t be nestled beneath anyone’s desk by next Tuesday.
However, the migration away from quantum-vulnerable cryptography has already begun.
For an introduction to qubits, superposition and the strange mechanics behind these machines, see Leaving Supercomputers in the Dust: An Introduction to Quantum Computing. I’ve also examined the wider cybersecurity threat in Quantum Computing and Cyber Security: Are We 24 Months From Mayhem?.
This time, I’m narrowing the lens. The immediate challenge for IT teams isn’t understanding quantum physics or predicting when a powerful quantum computer will arrive. It’s discovering where vulnerable cryptography is already embedded across the organization.
The migration away from quantum-vulnerable cryptography has already begun.
In August 2024, the National Institute of Standards and Technology (NIST) finalized its first three post-quantum cryptography standards. NIST now says organizations should begin using them and plans to remove quantum-vulnerable algorithms from its standards by 2035, with high-risk systems transitioning sooner.
Implementing new algorithms, however, isn’t the first problem.
The first problem is finding all the old ones.
Not All Encryption Is About to Break
Post-quantum cryptography is often presented as a replacement for encryption. IT teams need the more precise version.
The primary concern is public-key, or asymmetric, cryptography. It supports the secure exchange of encryption keys, digital signatures, identity verification and many other processes that make modern computing possible.
Widely used public-key algorithms such as RSA (named for its creators Rivest, Shamir and Adleman) and elliptic-curve cryptography are considered vulnerable to a sufficiently powerful quantum computer. Symmetric encryption, such as AES (Advanced Encryption Standard), faces a different and less drastic threat. Strong symmetric algorithms can generally remain secure when suitable key sizes are used.
Quantum computing won’t affect every form of encryption in the same way. Make sure you’re not vulnerable.
IT teams need to identify quantum-vulnerable cryptography, understand what depends on it and replace it without disabling something important. Most other encryption can remain where it is.
Then comes the question capable of bringing the meeting to a halt: “Well, where are we using it?”
Cryptography Is Everywhere
Although it may feel like it would make your life a whole lot easier, an organization’s cryptography isn’t stored in one convenient folder marked “Important Security Stuff.”
It’s typically built into:
- TLS (Transport Layer Security) certificates securing websites, APIs (Application Programming Interfaces) and internal services.
- VPNs (Virtual Private Networks), routers, firewalls and load balancers.
- Email encryption and document-signing systems.
- Identity and authentication platforms.
- Code-signing and software-update processes.
- Cloud services.
- Mobile devices, IoT equipment and industrial systems.
- Operating systems and application frameworks.
- Software libraries and custom applications.
- Third-party products.
Some uses are visible. Others are buried inside firmware or dependencies selected years before the current IT team arrived.
An organization’s cryptography isn’t stored in one convenient folder marked “Important Security Stuff.”
A certificate inventory can help, but certificates are only part of the picture. An organization also needs to understand the protocols, libraries, algorithms and business systems involved. One application may rely on several cryptographic components maintained by different vendors.
Building the inventory can take some digging. Older systems have a habit of hiding in plain sight while continuing to handle critical work.
The Threat Begins Before the Quantum Computer Arrives
My earlier look at the cybersecurity impact of quantum computing focused on why organizations should prepare. The next question is how. That begins with understanding which information must remain protected, which systems protect it and how long replacing their cryptography could take.
If large-scale quantum computers don’t yet exist, why begin now?
One reason is the possibility of “harvest now, decrypt later” attacks. An attacker can collect encrypted information today and retain it until technology becomes capable of decrypting it.
That doesn’t make every encrypted transmission an emergency. A lunch order intercepted in 2026 is unlikely to become a national treasure in 2036.
Medical records, intellectual property, government information, financial data and trade secrets are different. They may remain sensitive for decades. If the required confidentiality period extends beyond the expected life of the cryptography, waiting for a quantum breakthrough is waiting too long.
The second reason is more familiar: enterprise migrations take time.
Algorithms can be standardized much faster than organizations can replace hardware, update applications, negotiate vendor roadmaps, test integrations and retire legacy systems. A device purchased today may still be operating ten years from now. A custom application may depend on a cryptographic library that hasn’t been touched since its developer left the company.
The deadline isn’t the day a cryptanalytically relevant quantum computer appears. It’s the day by which your organization must be ready for one.
The deadline isn’t the day a cryptanalytically relevant quantum computer appears. It’s the day by which your organization must be ready for one.
NIST Has Supplied the Starting Point
NIST’s three principal post-quantum standards are ready for implementation:
- FIPS 203 supports secure key establishment.
- FIPS 204 provides post-quantum digital signatures.
- FIPS 205 provides an alternative digital-signature method based on hash functions.
NIST expects these Federal Information Processing Standards (FIPS) to provide the foundation for most post-quantum deployments.
Will your encrypted data outlive the security protecting it?
Their existence doesn’t mean organizations should start swapping algorithms inside production systems tomorrow morning. Products, protocols and services must support the standards. Implementations must also be tested for security, performance and interoperability.
It does mean that migration is no longer theoretical. NIST says organizations should begin applying the standards now.
Start With a Cryptographic Inventory
A useful cryptographic inventory should do more than record that an application “uses encryption.” That’s like documenting a building by noting that it contains doors.
For each important system, the inventory may need to capture:
- The algorithm and cryptographic function in use.
- The associated protocol, certificate or library.
- The application, device or service relying on it.
- The data or business process being protected.
- The system owner and responsible vendor.
- The expected life of the system.
- How long the data must remain confidential.
- Available post-quantum upgrade plans.
- Dependencies that could be affected.
The appropriate degree of detail will depend on the organization. A small MSP, for example, probably doesn’t need to reproduce the reporting structure of a federal agency. It just needs enough information to determine what must change, who controls the change and what might break.
Automated tools can examine certificates, network traffic, endpoints, source code and software components. They won’t find everything. Isolated systems, proprietary products and undocumented applications can create blind spots.
Discovery should combine tooling with certificate records, software bills of materials, architecture diagrams, procurement records and conversations with application owners. Yes, conversations. Occasionally the most advanced discovery technology available comes from asking Linda why a 14-year-old server must never be rebooted. She knows.
Occasionally the most advanced discovery technology available comes from asking Linda why a 14-year-old server must never be rebooted.
Prioritize What Matters Most
Suppose the inventory identifies 3,000 uses of vulnerable cryptography. Which one gets fixed first?
The answer depends on more than the algorithm involved. Prioritization should consider:
- The sensitivity and useful life of the data.
- Whether the system is internet-facing.
- The impact of compromise.
- The remaining life of the system.
- The complexity of its dependencies.
- Whether an upgrade path exists.
- How much control the organization has.
A replaceable security component is easier to update than one buried inside the system.
Systems protecting long-lived sensitive information deserve early attention. So do critical identity services, products with long replacement cycles and anything requiring extensive testing.
An application scheduled for retirement next year may only need monitoring. A medical records system expected to operate for another decade belongs near the front of the queue.
Put Vendors on the Record
Much of an enterprise’s cryptography is controlled by vendors. That changes the questions IT and procurement teams must ask.
Does the product use quantum-vulnerable cryptography? Which functions depend on it? Does the vendor have a post-quantum roadmap? Will support arrive via an update or require new hardware? Can the implementation be tested before deployment?
Contract renewals and new purchases provide opportunities to ask questions before another long-lived dependency enters the environment.
“Quantum-ready” should also invite follow-up questions. It may mean a product supports NIST-standardized algorithms. It may mean the vendor plans to support them. Ask what the vendor’s “quantum-ready” claim means in practical, technical terms.
Ask what the vendor’s “quantum-ready” claim means in practical, technical terms
Build for the Next Migration
Post-quantum migration won’t be the final cryptographic transition. Algorithms can weaken, standards can change and implementations can fail.
Nobody wants to rebuild an entire system every time an algorithm, certificate, key or library must change. That ability to make substitutions without major reconstruction is known as crypto agility. Hard-coded algorithms and undocumented dependencies make every transition slower. Configurable components, accurate inventories and clear ownership make future changes more manageable.
Installing the new cryptography solves the immediate problem. Crypto agility prepares the organization for whatever must be replaced next.
The Work Starts Before the Upgrade
Quantum computing may be the reason for the migration, but it isn’t the daily problem IT teams must solve.
The daily problem is visibility.
Organizations can’t replace vulnerable cryptography until they find it. Priorities depend on what each system protects, while any realistic schedule must account for vendors, hidden dependencies and equipment that can’t be updated quickly.
This isn’t science fiction. It’s asset discovery, dependency mapping, lifecycle planning and migration management.
In other words, it’s probably already on IT’s desk.
Your encryption has an expiration date. The safest time to check the label is well before someone announces that it’s passed its “Best By” date.
By Ed Clark
LinkTek COO
Ed Clark
Feel free to share this article on your social media:
Recent Comments
- No recent comments available.
ChatGPT,
Gemini,
Claude and
Copilot
Leave a Comment