Your Crytographic Controls have a hidden Expiration Date

Someone pushed back on me while I was putting this together: no quantum computer capable of breaking RSA exists yet, so why worry now? Fair question. It rests on a wrong premise, though.

The risk isn’t “someday, someone will break your encryption.” The risk is that data intercepted and stored today, under RSA or ECC, will be decryptable tomorrow. Security people call this “harvest now, decrypt later.” The protection window doesn’t close in the future. It may already be open. Any long-lived data, a medical record, a trade secret, a civil registry entry, encrypted today, already carries this exposure. The question worth asking isn’t “is RSA breakable today,” it’s “will this data still need to be confidential by the time that capability exists.”

Let’s stay honest about what’s actually new here, though. Generic cyber risk, interception, leaks, exploited vulnerabilities, has always existed. That’s not what’s changing. What’s changing is the status of a control we treated as permanently sufficient. That assumption is now on two separate clocks, and they shouldn’t be conflated. In March 2026, Google set 2029 as its target to migrate Chrome and Android to post-quantum cryptography, after revised estimates suggested RSA-2048 could be broken with far fewer qubits than previously thought. That’s risk management on Google’s part, not a forecast that a code-breaking machine will exist by then. NIST’s clock runs on a different logic entirely, one that doesn’t care when the hardware shows up: its transition plan (IR 8547) deprecates RSA-2048 and ECC P-256 after 2030, and disallows them outright after 2035.

For an internal auditor, this changes the question worth asking. Not “is there a cyber risk,” everyone already knows that. Instead: does this control I signed off on last year have a shelf life nobody documented?

In practice, that turns into questions worth asking now, regardless of industry:

• Is there a cryptographic inventory, meaning does anyone know which systems encrypt what, and with which algorithm?

• Has a migration roadmap toward post-quantum standards (ML-KEM, ML-DSA, finalized by NIST since August 2024) even started?

• Is this risk identified, assessed, assigned an owner, and being treated, whether it sits under a dedicated “quantum risk” line or inside a broader cryptographic or technology obsolescence risk? The label matters less than whether anyone owns it.

• Has the conversation with the CISO on this even begun?

There’s a piece missing from this list, though: crypto-agility, meaning whether the organization actually knows where its cryptography lives and can swap algorithms quickly when needed. An organization with a handful of PQC pilot projects but hundreds of undocumented cryptographic dependencies in legacy applications can be worse positioned than one that hasn’t migrated much yet but has full visibility into its cryptographic footprint. Migration without inventory is theater. Inventory without migration is a gap you can at least see coming.

Third line assurance isn’t meant to design the migration in the security team’s place. Its job is to independently challenge whether a plan exists and whether it’s being followed. It’s a standard audit exercise applied to an unusual object: a control that looked permanent, and no longer is.

Should we wait for scientific certainty before auditing a risk, or is that very uncertainty part of what we’re supposed to challenge?