A French startup, Alice & Bob, recently estimated that RSA-2048 could be factored with Shor's algorithm using fewer than 23,000 physical qubits in as little as three days. This contrasts sharply with Google Quantum AI's 2025 estimate of 1 million qubits. This discrepancy has stirred discussions in compliance circles, raising several key questions. Here are the most common ones, with answers tied to the frameworks your team is assessed against.
Q1: Is this a real break, or can we ignore it until the hardware exists?
It's neither a break nor something to ignore. The estimate is not a demonstration, and the preprint needs peer review. It's uncertain whether cat qubits can perform and scale in real-world operations. Cat qubits reduce the number of physical qubits needed per error-corrected logical qubit by suppressing certain errors at the hardware level.
The trend is crucial for your planning. Alice & Bob's cat qubit requirement for RSA-2048 dropped from 350,000 in 2023 to 100,000 a year later and now to 23,000. Resource estimates are decreasing, and your migration schedule spans years. Treat this as evidence that the planning horizon is shrinking, not as a countdown clock.
Q2: Our data is protected in transit today. Why does a future quantum computer matter now?
"Harvest now, decrypt later" is the concern. An adversary can collect encrypted traffic today and decrypt it once quantum capability exists. While three days to break a key might not matter for a live payment, it does for a medical record, state secret, or intellectual property that must remain confidential for 15 years.
Apply this to your data inventory. Controlled Unclassified Information with long sensitivity lifetimes, export-controlled technical data under ITAR, and program records tied to long-lived platforms are at risk. Ask if each data set needs to stay confidential longer than classical cryptography is expected to hold. If yes, it's already at risk, regardless of the hardware timeline.
Q3: Does CMMC or NIST SP 800-171 require quantum-safe crypto right now?
No, and don't claim otherwise in an assessment. The current requirement is cryptography that meets the standard: NIST SP 800-171 requires FIPS-validated cryptography to protect CUI confidentiality (3.13.11), and DFARS 252.204-7012 and 32 CFR Part 170 enforce this in contracts and assessments. A FIPS 140-2 validated module is the benchmark your assessor will check.
Being compliant today doesn't mean you're protected against a quantum-capable adversary, and quantum-safe algorithms aren't yet a scored requirement. Keep your System Security Plan accurate about what you've implemented. Document your quantum planning as a risk-informed roadmap, not as a control you've satisfied.
Q4: Where do we even start? We can't swap out crypto we haven't found.
Start with a cryptographic inventory. You can't prioritize migration without knowing where RSA and elliptic-curve cryptography are used. Cover the obvious places and the hidden ones:
- TLS endpoints, VPN concentrators, and remote access gateways
- X.509 Certificates and the Public Key Infrastructure that issues them
- Code signing, firmware signing, and software update channels
- Email signing and encryption
- Embedded and OT devices with hard-coded keys
- Third-party SaaS and cloud services handling CUI
Record the algorithm, key length, owner, data sensitivity, and replacement difficulty for each. Your existing Software Bill of Materials work and Risk Management Framework control inventories (NIST SP 800-53 Rev 5, including the SC family for system and communications protection) give you a head start. The inventory also feeds your risk register, so leadership sees quantum exposure as a quantified item, not a vague worry.
Q5: What should we be buying or specifying in the meantime?
Build crypto-agility into procurement before implementing quantum-safe algorithms. In new contracts and renewals, ask vendors for their post-quantum roadmap, whether algorithms can be swapped without a forklift upgrade, and their plan to pursue validation through the Cryptographic Module Validation Program once validated post-quantum modules become available.
Be cautious with claims. A vendor saying a product is "quantum-safe" isn't the same as holding a validation you can cite to an assessor. Until validation exists, you're making a risk decision, and your documentation should reflect that. Also, watch cloud dependencies: for FedRAMP Low/Moderate/High Baseline services and DoD Cloud Computing Security Requirements Guide environments, your provider's cryptographic posture is part of the Shared Responsibility Model. Check the Customer Responsibility Matrix to see who owns what.
Q6: How do we prioritize if everything uses RSA?
Rank by data lifetime and exposure, not by system size. A practical order:
- Long-lived confidential data in transit across untrusted networks, since it's the easiest to harvest.
- Long-lived archived data protected by public-key mechanisms.
- Signing infrastructure with long certificate lifetimes, where forgery risk grows as quantum capability matures.
- Short-lived, low-sensitivity transactions, which can wait.
Flow-down matters here too. Your subcontractors handling CUI inherit your obligations under DFARS 252.204-7012, and a weak link in a supplier's key exchange undermines your own protection. Add cryptographic inventory and migration planning to your supplier questionnaires now, while it's a conversation and not yet a finding.
Where to go for more
Start with NIST's post-quantum cryptography standardization work and the migration guidance NIST and CISA have published. Track updates to NIST SP 800-53 and 800-171 for any change in cryptographic requirements. Follow Cyber AB and DoD CIO communications for how assessments may evolve under 32 CFR Part 170. Check with your Third-Party Assessment Organization or Independent Assessor on how they expect quantum planning to be documented. Then pick one data set with a long confidentiality lifetime and run the inventory exercise on it this quarter. That single pass will tell you more about your real exposure than any qubit estimate.
