The Challenge
Federal agencies are working under a 2035 deadline to migrate cryptographic systems to quantum-resistant algorithms. The January 2025 Executive Order on Strengthening and Promoting Innovation in the Nation's Cybersecurity formalized requirements for post-quantum cryptography in contract solicitations, building on National Security Memo-10. However, as agencies inventory legacy systems and plan PQC migration paths, they're overlooking a more immediate vulnerability: the quality of randomness underpinning their current encryption.
Classical computers can't generate true randomness. They rely on pseudo-random number generators that simulate unpredictability. This creates a weakness: if an attacker can predict or reproduce the seed values used to generate cryptographic keys, the strength of your encryption algorithm becomes irrelevant. You've built a vault with a predictable combination.
Quantum random number generators solve this problem by using quantum-physical randomness to produce truly unpredictable values. They're available now, integrate with existing infrastructure, and strengthen cryptographic operations while you plan your PQC transition.
The gap: most agencies treat quantum safety as a future PQC implementation project, not as a present-day cryptographic hygiene issue.
The Environment and Constraints
Your current security posture depends on randomness you can't verify. Every session key, initialization vector, nonce, and salt your systems generate relies on pseudo-random number generators. When you generate a TLS certificate, rotate an API key, or establish a VPN tunnel, you're trusting that your random number source is sufficiently unpredictable.
The constraint isn't technical capacity. Major network security vendors, including Palo Alto Networks, have released Open API frameworks for quantum random number generators, signaling industry recognition that randomness quality matters now. The constraint is organizational: agencies are waiting for comprehensive PQC guidance before addressing the randomness problem that exists today.
Consider the operational environment. You're managing systems subject to NIST SP 800-53 Rev 5 controls, particularly the SC (System and Communications Protection) family. SC-12 requires cryptographic key establishment and management. SC-13 mandates cryptographic protection. Neither control specifies the quality of randomness feeding those cryptographic operations. Your compliance documentation likely describes which algorithms you use and how you rotate keys, but it probably doesn't address whether your random number generation meets the unpredictability standard required for those algorithms to function as designed.
The stakes are specific. One analysis estimates that a quantum cyberattack on macroeconomic financial institutions could produce indirect GDP losses between $2 trillion and $3.3 trillion. Federal Reserve systems, DoD logistics networks, and CUI repositories all depend on encryption keys generated from random values. If those values aren't truly random, you're not just facing a future quantum threat; you're running current operations on compromised foundations.
The Approach Federal Teams Should Take
Start with a randomness audit. Identify every system component that generates cryptographic material: hardware security modules, key management systems, certificate authorities, VPN concentrators, and application-layer encryption services. Document which random number generator each component uses. If you're relying on operating system-provided randomness or software-based PRNGs, you've identified your integration points.
Integrate QRNGs where you generate high-value keys. You don't need to replace every random number call across your entire infrastructure. Focus on:
- Root and intermediate certificate authority key generation
- Long-lived encryption keys protecting data at rest
- Master keys in key management systems
- Authentication tokens with extended validity periods
- Cryptographic seeds for security-critical applications
Deploy QRNG hardware or services at these chokepoints. The integration model mirrors how you'd introduce a hardware security module: the QRNG becomes an entropy source feeding your existing key generation processes.
Update your System Security Plans to document QRNG integration. Under SC-12, describe how quantum randomness strengthens your cryptographic key establishment. Under SC-13, note that your cryptographic protection now relies on provably random inputs. This isn't a new control implementation; it's an enhancement to existing controls that your assessors will recognize as defense-in-depth.
Run this parallel to your PQC planning, not after it. The NIST post-quantum cryptography algorithms (FIPS 203, FIPS 204, FIPS 205) will still require high-quality randomness when you implement them. By integrating QRNGs now, you're strengthening current operations and preparing the infrastructure that will support your quantum-resistant algorithms.
Results and Metrics You Can Track
Measure QRNG integration by coverage, not by system count. Track what percentage of your high-value cryptographic operations now use quantum randomness. If your certificate authority generates root keys with QRNG entropy, you've secured the trust anchor for your entire PKI. That's more valuable than deploying QRNGs across a hundred low-risk systems.
Monitor key generation latency. QRNGs should introduce negligible performance impact for key generation operations, which typically happen infrequently. If you see degradation, you've likely misconfigured the integration or chosen a deployment model that doesn't match your operational tempo.
Document the enhancement in your continuous monitoring artifacts. Your Plan of Action and Milestones should show QRNG integration as a completed risk mitigation, not a pending item. Your assessor will see evidence that you're addressing cryptographic hygiene proactively.
What Agencies Should Do Differently
Don't wait for comprehensive PQC migration guidance to address randomness quality. The 2035 mandate creates urgency for algorithm replacement, but it shouldn't delay improvements to the cryptographic foundations you're using today.
Avoid treating quantum safety as a single-technology solution. Post-quantum cryptography protects against quantum attacks on your algorithms. Quantum random number generators protect against attacks on your key generation. Quantum key distribution, still under development for practical deployment, may eventually offer additional communications security. Each addresses a different attack surface.
Stop describing this as "quantum readiness" in your security documentation. That phrase suggests preparation for a future threat. You're addressing a current cryptographic weakness that quantum computing will eventually exploit. Frame it as operational security improvement that happens to use quantum technology.
Takeaways for Your Team
Quantum safety isn't a 2035 problem. The cryptographic randomness feeding your encryption today either meets the unpredictability standard required for your algorithms or it doesn't. If you're using pseudo-random number generators for high-value key material, you're accepting risk that quantum random number generators eliminate now.
Integration doesn't require infrastructure replacement. QRNGs function as entropy sources for existing key generation processes. You're enhancing components you already operate, not deploying new security architectures.
Your PQC migration plan should assume quantum randomness, not classical pseudo-randomness. When you transition to NIST's post-quantum algorithms, they'll still need unpredictable inputs. Build that foundation now while you map your algorithm migration path.
Compliance documentation should reflect the enhancement. Update System Security Plans to show that SC-12 and SC-13 controls now use provably random inputs. Your assessors will recognize this as defense-in-depth that strengthens your existing cryptographic protections.
The agencies that treat quantum safety as a holistic challenge, addressing algorithm strength, randomness quality, and emerging technologies in parallel, will build more resilient security postures than those waiting for a single comprehensive solution.
