As organizations accelerate their transition to post-quantum cryptography, most attention has focused on algorithms, key sizes and migration timelines. A more basic question receives far less scrutiny: where the randomness behind every cryptographic key actually comes from. According to the U.S. National Institute of Standards and Technology (NIST), the answer matters as much as the algorithm itself.
NIST’s Entropy as a Service (EaaS) project states that cryptography fails when systems rely on weak keys, low-entropy randomness or inaccurate time sources. Private keys, session keys, signature nonces and authentication tokens all depend on unpredictable secret values. Because computers are deterministic, they rely on a small amount of genuine physical uncertainty, known as entropy, to seed the random bit generators that produce those values. If the seed is weak, duplicated or guessable, every key derived from it inherits the weakness, usually without any visible error.
History offers clear examples. In the Debian OpenSSL incident (CVE-2008-0166), a code change left the process ID as essentially the only source of entropy on Debian-based systems from 2006 to 2008. This reduced the key space to roughly 32,768 possible keys per type, which allowed affected SSH and TLS keys to be enumerated. In 2012, researchers presenting “Mining Your Ps and Qs” at the USENIX Security Symposium found that devices generating keys shortly after first boot frequently produced repeated or related keys. The researchers were able to compute private keys for a measurable fraction of TLS and SSH hosts on the internet. In both cases the algorithms were sound. The randomness was not.
Security experts note that cloud computing introduces new pressure on this foundation. Virtual machines can boot in seconds and begin establishing SSH and TLS sessions before gathering sufficient entropy. When a virtual machine, container checkpoint or serverless environment is restored from a snapshot, its random generator state may be restored as well. Several copies could then produce identical “random” values, an issue Amazon Web Services addresses in dedicated guidance for Lambda SnapStart. Guest systems also draw their entropy from provider hypervisors and hardware that customers cannot inspect or audit. Organizations operating across multiple clouds inherit multiple entropy designs, with no single policy, validation record or audit trail.
NIST has identified quantum phenomena as the best source of true randomness. Because quantum random number generators are impractical to build into every device, NIST’s proposed approach is to deliver quantum entropy as a network service, so systems benefit without hosting quantum hardware themselves. The agency reports that technology transfer of the architecture is complete and that it is in use by industry. Its guiding principles are that the service supplies entropy but never generates keys, that the server gains no insight into client keys, and that trust should not rest on a single operator.
Delivering entropy over a network, however, creates its own risks. Entropy sent over classical key exchange could be recorded today and decrypted later once a cryptographically relevant quantum computer exists, a threat commonly described as “harvest now, decrypt later.” Without authentication and freshness checks, attackers could replay old entropy or inject chosen values. Memory-safety flaws are another concern: Microsoft and Google have each reported that around 70 percent of their serious security vulnerabilities stem from memory-safety issues, and the NSA and CISA now urge vendors to adopt memory-safe programming languages.
Canadian quantum security company SuperQubit Inc. has introduced Sovereign Entropy, a client-owned appliance designed around these principles. The hardened server is fitted with multiple independent quantum random number generators and installed in a customer’s own data centre, colocation facility or dedicated enclave. Lightweight agents deliver fresh quantum entropy to workloads running on AWS, Google Cloud, Azure, private cloud and edge environments at first boot, after snapshot restore, during scale-out, on a scheduled reseed and before high-value keys are generated.
According to the company’s October 2026 white paper, the quantum sources are continuously health-tested against NIST SP 800-90B, and a failing source is removed from service. Each workload mixes the delivered entropy with its own local entropy, in line with SP 800-90C, so the appliance never sees the final seed or any derived key. Entropy travels over TLS 1.3 with hybrid ML-KEM key exchange (FIPS 203). Each response is bound to a nonce and timestamp and signed with ML-DSA (FIPS 204), using a key held in a hardware security module. The entropy server is written in Rust, a memory-safe language, and all cryptographic operations run in a FIPS 140-3 validated module. Applications continue to use standard interfaces such as getrandom(), OpenSSL, Java SecureRandom and Python’s secrets library.
The white paper also sets out the approach’s limits. Quantum entropy does not strengthen a weak algorithm, cannot repair keys already generated or copied inside a snapshot, and does not replace the need for a sound local entropy source at very early boot. It is intended to supplement existing cloud protections rather than replace them.
As governments and enterprises prepare for the post-quantum era, attention is beginning to extend beyond which algorithms protect data to the integrity of the randomness those algorithms depend on. For organizations operating across multiple clouds and regulated environments, an entropy source that is owned, auditable and secured in transit may become an increasingly important part of long-term cryptographic resilience.