The CMMC pause doesn't push back the quantum security deadline

Started by Katie71, Aug 24, 2026, 05:44 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Topic: The CMMC pause doesn't push back the quantum security deadline   Views(Read 76 times)

Katie71

A Forbes Technology Council OP this week from Qrypt cofounder Denis Mandich lays out what looks like a contradiction in recent US policy but actually isn't. Back in June, the White House issued two quantum related executive orders at once, one accelerating quantum technology development broadly, and the other setting hard deadlines for federal agencies to migrate to post quantum cryptography, 2030 for key establishment and 2031 for digital signatures. Three weeks later, the Cybersecurity Maturity Model Certification program launched a full review aimed at cutting bureaucratic costs that were pushing smaller defense contractors out of the industrial base.

Mandich's argument is that these two moves aren't actually in tension. The CMMC pause changes how compliance gets measured on paperwork, not whether the underlying obligation to protect federal data still exists. Contractors still have to safeguard sensitive systems, they just may face a lighter certification process while doing it. Meanwhile the cryptographic deadlines from the executive orders remain fixed regardless of what happens with CMMC specifically, which shifts the real burden away from paperwork and toward actual engineering work, something Mandich argues is far harder and more resource intensive even with AI assistance.

He's specifically skeptical of throwing general purpose chatbots at the problem of discovering and migrating decades of legacy cryptography across a classified codebase. Cryptography needs deterministic outcomes, and a large language model that's confidently wrong some percentage of the time is a fine tradeoff for drafting marketing copy but an unacceptable one for a weapons system or intelligence platform. Instead he expects narrowly scoped, purpose built automation, doing things like code analysis, binary inspection, and dependency mapping, to handle much of the discovery work that used to require manual review.

Mandich's bigger point is architectural rather than purely algorithmic. Simply swapping in new NIST standardized post quantum algorithms while keeping the same decades old key distribution architecture doesn't actually solve the harvest now, decrypt later problem, where adversaries are already collecting encrypted data today with the plan to decrypt it once a capable enough quantum computer eventually exists. His prescription involves separating key establishment from the data plane, minimizing how much secret key material actually moves around a network, and building systems where the underlying cryptographic algorithms can be swapped out later without needing to rewrite the applications built on top of them


Sofia_61

The distinction between paperwork burden and actual engineering burden is the whole argument here in one sentence, and it's a useful reframing. Loosening a certification process doesn't loosen the underlying physics or math problem contractors still have to solve

Henry10

Harvest now, decrypt later doesn't get nearly enough attention outside of specialist cybersecurity circles given how serious the implication actually is. Data encrypted today with classical cryptography could already be sitting on some adversary's storage array waiting for a capable quantum computer to eventually crack it open. That means the actual damage from a future quantum computer isn't limited to attacks that happen after it exists, it retroactively applies to everything sensitive being transmitted right now. Organizations dealing with data that needs to stay secret for decades, government secrets, certain financial records, should probably be treating this as an active threat today rather than a future one
Here more than I should be

Highland Kev

Author has an obvious financial interest in this topic given he cofounded a quantum cybersecurity company, worth keeping in mind while reading the specific recommendations. Doesn't make the underlying argument wrong, just worth noting the incentive

NightOwl83

The architectural point about separating key establishment from the data plane is the part of this piece that actually matters most long term, more than the specific algorithm swap everyone focuses on. Just replacing RSA or ECC with a post quantum algorithm while keeping the same fundamental key distribution architecture from the 1970s is a bit like putting a better lock on a door frame that was never actually secure to begin with.

If the underlying architecture still moves secret key material around in ways that create single points of failure, a stronger algorithm alone doesn't fix the structural vulnerability sitting underneath it. That's a much bigger and more expensive undertaking than just doing a find and replace on which cryptographic library a piece of software calls though, since it touches how entire systems are designed rather than just which specific function gets invoked. Companies selling a quick algorithm swap as a full solution are probably underselling how much actual architectural work this transition really requires. The organizations taking this seriously early are going to have a real head start over everyone else scrambling once the deadline actually bites

TaxSeason37

Wonder how many smaller defense contractors are actually equipped to handle a cryptographic migration project this complex even with the CMMC paperwork burden reduced. Big primes have entire security teams for exactly this kind of work, but plenty of smaller subcontractors barely have dedicated IT staff at all. The paperwork relief helps them stay in the industrial base, but it doesn't solve the actual capability gap

LAKnight_Prime

Curious how many federal contractors have actually started serious cryptographic migration work versus still treating 2030 as some distant deadline that doesn't require immediate action. The piece argues the deadline has effectively already arrived given how long real migrations take, which tracks with basically every large scale IT migration project I've ever heard about running over schedule. Waiting until the deadline feels close is usually already too late for something this complex
Cashback on everything or it didn't happen

Save money on everyday spending Free cashback on thousands of retailers
View offer