“Quantum” is not a substitute for assurance. In a September 24 announcement, ETSI introduced implementation guidance for Quantum Random Number Generators and emphasized that secure randomness depends on the integrity of the complete implementation, not merely on a quantum entropy source.
That is an important cryptographic-management lesson. Randomness underpins key generation, nonces, salts, challenges, and many other security parameters. A generator can produce output that passes statistical tests while still being weakened by side information, faulty extraction, bias, hardware drift, tampering, shared infrastructure, or an insecure delivery path to the consuming application.
ETSI’s Technical Report TR 104 171 addresses the QRNG lifecycle from source modeling and validation through extraction, continuous monitoring, protection, delivery, provenance, attestation, and auditability. The report is guidance, not proof that any product is secure. For buyers and operators, its value is the set of questions it adds to a cryptographic inventory.
Random output is not the same as trustworthy entropy
A statistical test observes properties of a sample. It cannot by itself prove how the sample was produced, whether an attacker had correlated side information, or whether the device will behave the same way tomorrow. ETSI highlights risks across the full path, including the quantum source, hardware, interfaces, operational environment, and the applications that consume the output.
This means “QRNG present” is too shallow as an asset record. An organization needs to know which generator and implementation produced entropy, which extractor conditioned it, which health tests and alarms were active, how the output moved between components, and which cryptographic operations relied on it. Without those relationships, an alert about drift or a compromised device cannot be translated into the keys and systems that may require action.
Entropy is a dependency, not a box
ETSI introduces the concept of Entropy Zero Trust: no stage of the entropy pipeline should be trusted without verification. That wording is useful because it turns a hardware purchase into an operating model. Source integrity, extraction, interfaces, monitoring, and shared-computing controls each contribute to the result.
A useful inventory for entropy services should capture:
- device, module, firmware, driver, and library versions;
- source model, conditioning or extraction method, and configuration;
- health tests, monitoring thresholds, alarm destinations, and failure behavior;
- physical and logical location, interface, and delivery path;
- consuming applications, key-management systems, HSMs, and workloads;
- attestation, certification, test, and calibration evidence;
- maintenance owner, supplier, replacement process, and last validation date; and
- fallback behavior when entropy quality is uncertain or the source is unavailable.
These fields connect the generator to business impact. If a fleet shares one entropy service, the dependency may be more concentrated than the number of applications suggests. If a product silently falls back to a different source, the effective cryptographic configuration may differ from the approved design.
Monitoring must lead to a decision
Operational monitoring is valuable only when teams have defined what happens after a warning. Does the system stop generating keys, switch sources, quarantine the device, or continue with a logged exception? Which previously generated keys fall inside the suspect interval? Who can identify the affected certificates, encrypted data, tokens, or signed artifacts?
Those questions require timestamps and lineage. An entropy-quality event should be linked to the generator configuration and to the cryptographic objects or operations that consumed its output during the relevant period. Perfect lineage may not be available in every architecture, but documenting the observable boundary is better than treating the generator as an isolated appliance.
The same principle applies to attestations and certifications. They are evidence with scope and date, not permanent guarantees. A certificate may cover a module version but not a later firmware build, deployment configuration, cloud tenancy model, or delivery interface. Inventory records should preserve those boundaries.
What organizations should do next
First, find where cryptographic randomness enters the environment. Include operating-system generators, language runtimes, HSMs, cloud key services, hardware appliances, embedded devices, and any external entropy feeds. Focus on high-impact key generation and shared services.
Second, map consumers and failure modes. Ask what keys or protocols depend on each source and what the system does when health checks fail. Test those paths deliberately rather than assuming fail-safe behavior.
Third, request evidence from suppliers that covers provenance, extraction, monitoring, tamper resistance, interfaces, and operational maintenance. ETSI also calls for consistent comparison across trust level, throughput, power, size, interfaces, and scale; buyers should keep performance claims separate from security assurance.
Finally, treat QRNG adoption and PQC adoption as related but distinct decisions. PQC algorithms still need sound randomness, yet adding a quantum entropy source does not make classical public-key cryptography quantum-resistant. Conversely, a PQC implementation is not trustworthy if its key generation is undermined by weak entropy.
How Vista Platform helps
Vista Platform is a self-hosted cryptographic system of record. Its operating loop—discovery, canonical inventory, evaluation, action, and proof—supports a governed view of cryptographic assets, their relationships, policy findings, owners, and evidence.
Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. It can help teams record discovered cryptographic dependencies and manage remediation evidence, but it does not certify entropy quality, generate PQC keys, or perform every migration action. Vista is not a vulnerability scanner. Selected-asset Active Scan is targeted, and incomplete discovery cannot prove absence.
Where uncertainty remains
ETSI identifies future work for attestation and logging protocols, certification models, and guidance on combining QRNGs with PQC. Organizations should therefore avoid turning “quantum random” into an unqualified trust label. The defensible approach is to record exactly what is deployed, how it is monitored, what evidence applies, which workloads depend on it, and how the organization will respond when that evidence changes.
Source
- ETSI identifies limitations of quantum random number generators, European Telecommunications Standards Institute, September 24, 2026.