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

[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

The CMMC Pause Won't Change The Quantum-Security Deadlinewww.forbes.com

[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

[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

[Karen76]

The skepticism toward general purpose chatbots handling cryptographic migration work is well placed. There's a specific kind of magical thinking that's crept into a lot of enterprise conversations lately where any hard technical problem gets assumed solvable by pointing an LLM at it.

Cryptography is exactly the wrong domain for that kind of statistical, occasionally wrong tool, since a single subtle mistake in a key exchange implementation isn't like a typo in a marketing email, it's a security hole that could go completely undetected until it's actively exploited. Narrow, purpose built automation that produces verifiable evidence instead of confident sounding prose is clearly the more sensible path forward here

[Mitchell_48]

The bit about the last generation of beltway bandits getting rich off CMMC style overruns and delays feels like the most cynical but probably most accurate line in the whole piece. Government compliance regimes have a long, well documented history of enriching consultants more than actually improving security outcomes