Summary
Quantum random-number generators are often sold on a simple proposition: quantum measurements are intrinsically unpredictable, so their output must be better randomness. ETSI TR 104 171, published in March 2026 and highlighted by ETSI in September, replaces that proposition with a more useful engineering model. A quantum entropy source is only the first stage of a system that also contains detectors, analog electronics, digitizers, extractors, firmware, interfaces, and consuming applications. Any of those stages can reduce security or expose side information.
The report's most important contribution for enterprise teams is therefore architectural, not promotional. It introduces an Entropy Zero Trust profile under which no stage of the entropy pipeline is accepted without verification. That approach aligns with established entropy-source work such as NIST SP 800-90B while extending attention to provenance, attestation, shared environments, physical interference, and delivery to the application.
For security architects and infrastructure buyers, the practical conclusion is clear: procure QRNG capability as an auditable entropy service, not as an opaque appliance. A statistically clean bitstream is evidence of output quality, but it is not proof that an attacker cannot predict, influence, substitute, or replay that output.
The Quantum Source Is Not the Product
A practical QRNG has two fundamental functions. First, a quantum entropy source measures a physical process such as photon arrival, optical phase noise, or vacuum fluctuations. Second, a classical randomness extractor turns imperfect raw observations into a shorter output intended to be close to uniform and independent of an adversary's information.
That second stage matters because the raw measurement is never an abstract quantum event. Detector efficiency, dead time, temperature, amplifier behavior, clock coupling, analog-to-digital conversion, and calibration all shape the sampled data. Some of those effects are benign and measurable. Others may be accessible to an attacker through optical injection, electromagnetic interference, voltage manipulation, timing observation, or compromised control software.
The correct security quantity is consequently not simply whether zeros and ones appear in equal proportions. It is the lower bound on entropy after accounting for realistic side information and the behavior of the complete implementation. ETSI emphasizes conditional min-entropy: a conservative measure tied to the probability of correctly guessing the most likely outcome given what an adversary may know. The extractor's output rate must be bounded by that estimate, with an explicit security margin.
This is why adding an extractor cannot rescue an unjustified entropy claim. Hashing can concentrate entropy that is already present; it cannot manufacture unpredictability from a source whose real entropy rate is unknown or has collapsed. If firmware continues emitting at the nominal rate after the optical path drifts or a sensor saturates, the output may look well distributed while carrying less uncertainty than the interface promises.
Passing Statistical Tests Is Necessary but Insufficient
Statistical test suites can detect bias, repetition, correlations, spectral features, and other departures from an expected distribution. They remain valuable in development, acceptance testing, and operational monitoring. They do not, however, establish the physical origin of the data or model an adversary's side information.
A deterministic stream encrypted or transformed with a secret value can look random to a black-box tester while being fully predictable to the party holding that value. Similarly, a QRNG can produce output that passes distribution tests even when an environmental signal partly controls the detector. Tests answer whether sampled output exhibits selected statistical properties; they do not by themselves answer who can predict or influence it.
NIST SP 800-90B makes a related distinction by specifying requirements for entropy-source design, validation, health testing, and entropy estimation. It treats an entropy source as a noise source combined with health tests and, optionally, conditioning. ETSI TR 104 171 builds a QRNG-specific operational view around that foundation. It discusses online conditional min-entropy estimation, statistical monitoring, shielding, side-channel protection, tamper resistance, and provenance.
The two documents should not be treated as interchangeable certifications. ETSI TR 104 171 is a Technical Report with implementation guidance, and its normative-reference section is explicitly empty. It identifies engineering practices and areas for standardization; it does not make every QRNG that follows its vocabulary certified. NIST SP 800-90B, meanwhile, defines entropy-source requirements but does not validate an entire product deployment, its supply chain, or its application integration.
Entropy Zero Trust Changes the Trust Boundary
The Entropy Zero Trust model moves the trust boundary from the QRNG enclosure to the complete path used to create and consume randomness. That path can be divided into six control planes.
1. Source model and calibration
The supplier should document the measured quantum process, classical noise contributions, expected operating envelope, and assumptions used to derive a min-entropy bound. Calibration data should be versioned and tied to device identity and firmware. A generic statement that the source is quantum is not an entropy model.
2. Extraction and rate control
The implementation should identify the extraction construction, input block size, output length, seed handling where applicable, and the entropy estimate that justifies the compression ratio. Output should be throttled or stopped when the validated entropy rate falls below the extractor's configured demand. Fail-open behavior is inappropriate for cryptographic key generation.
3. Continuous health monitoring
Startup and online tests should operate on data close enough to the raw source to detect source failures that conditioning might hide. Alert thresholds, false-positive assumptions, response actions, and recovery procedures need to be documented. Operators should receive health telemetry without receiving sensitive raw samples that create a new leakage path.
4. Platform integrity and attestation
Secure boot, signed firmware, measured configuration, anti-rollback controls, and hardware-backed device identity make it possible to distinguish an approved entropy pipeline from an altered one. Attestation evidence should cover the extractor and drivers as well as the physical source. A valid device certificate says little if unmeasured host software can replace the returned bytes.
5. Interface and tenant isolation
The transport from device to HSM, kernel, VM, container, or application must protect integrity and freshness. Shared deployments also need quotas, namespace separation, failure isolation, and resistance to one tenant exhausting or perturbing the source. Remote entropy delivery adds authentication, replay protection, availability dependencies, and a larger trust domain; it should not be described as equivalent to a local source without those differences being explicit.
6. Provenance and audit
For high-assurance key generation, an organization may need to establish which device, firmware, policy, and health state contributed entropy at a given time. Logs should provide that evidence without recording generated random values or enough internal state to reconstruct them. Signed health records and configuration measurements are more useful than a dashboard that only reports throughput.
A Better Enterprise Deployment Pattern
The safest integration pattern is generally not to replace the operating system or HSM deterministic random-bit generator with raw QRNG output. Instead, use validated quantum entropy as one input to a mature random-bit-generation construction that maintains internal state and can combine independent sources.
This hybrid pattern has several operational advantages. A stateful deterministic generator can serve bursts at far higher throughput than a physical source, limit direct exposure of source output, and continue according to a defined policy during brief source unavailability. Combining independent entropy inputs can also reduce reliance on one vendor or physical mechanism, provided the combining construction is reviewed and a failed input cannot cancel good entropy.
The policy decision during QRNG failure must be explicit. Some systems should stop generating long-lived keys. Others may continue from an already secure internal state while raising an alert and refusing reseed-dependent operations. The right choice depends on the threat model, application lifetime, and certification boundary. Silent fallback to an undocumented software generator defeats the assurance the QRNG was meant to provide.
Infrastructure teams should also separate cryptographic and simulation requirements. Monte Carlo workloads may value throughput, reproducibility controls, and measurable distribution properties. Key generation values resistance to prediction and compromise. The same device may support both, but the extraction rate, monitoring policy, interfaces, and failure semantics are not necessarily identical.
What to Put in an RFP or Architecture Review
A useful procurement process asks for evidence rather than adjectives. At minimum, require: a physical and stochastic source model; conditional min-entropy estimates across temperature, voltage, aging, and manufacturing variation; raw-source startup and continuous health tests; extractor design and output-rate justification; behavior on degraded entropy; protections against optical, electromagnetic, power, and timing influence; signed firmware and rollback protection; device and configuration attestation; authenticated interfaces; tenant-isolation controls; provenance records; and independent evaluation scope.
Buyers should map each claim to the exact boundary evaluated. A source module assessment does not automatically cover a PCIe card, its driver, a network entropy service, an HSM integration, or the application that requests keys. Likewise, a throughput number should state whether it describes raw samples, post-extraction bits, sustained delivery under health monitoring, or aggregate output from a deterministic generator.
Operational acceptance testing should include induced fault cases, not only long runs through a statistical suite. Teams should vary environmental conditions within approved limits, disconnect or obstruct the source where safe, test firmware rollback, interrupt the transport, exhaust tenant quotas, and confirm that alarms and failover behavior reach existing monitoring systems. The objective is to verify the security state machine, not to produce an attractive histogram.
The Real Value of the ETSI Guidance
ETSI TR 104 171 does not prove that quantum randomness is categorically superior to well-designed classical physical entropy. It explicitly places QRNGs within the broader class of physical true random-number generators and focuses on implementation choices. That is a strength. It directs attention away from the word “quantum” and toward the evidence needed to trust a deployed service.
The report also exposes a gap likely to matter in future standards and procurement: common interfaces and comparable claims remain immature. Enterprises need consistent ways to describe post-extraction throughput, power, dimensions, scaling, trust level, control operations, health telemetry, and attestation. Until those conventions harden, integration teams will have to normalize vendor claims themselves.
For post-quantum migration programs, this is an important corrective. Algorithms such as ML-KEM, ML-DSA, and SLH-DSA still depend on secure random values. Replacing vulnerable public-key algorithms while leaving entropy generation unaudited does not complete the trust chain. The durable architecture is not a magical source of perfect bits; it is a measured, monitored, attestable pipeline whose assumptions and failure modes remain visible from the physical source to the consuming cryptographic boundary.