Why physical sources need monitoring
A physical entropy source is not a timeless mathematical object. It is implemented in electronics, sensors, clocks, analog circuitry, detectors or other hardware that can change with environment and age.
Possible influences include temperature, supply voltage, component degradation, electromagnetic interference, manufacturing variation, saturation, disconnection, stuck signals or unexpected software/firmware configuration.
A system that was characterized successfully in a lab still needs a way to notice if the source stops behaving like the characterized source during deployment.
What a health test should do
A health-test mechanism should detect certain forms of failure quickly enough that suspect data is not silently credited as entropy.
The exact tests depend on the framework and source. The important systems questions are:
- what failure modes are the tests intended to detect?
- what thresholds are used and why?
- what happens when a test fails?
- is output suppressed, degraded, retried or reported?
- can failures be logged without exposing sensitive raw data?
Health tests vs generic randomness tests
A large offline suite applied to a long output file answers a different question from an online health test.
Offline suites look for statistical properties over accumulated data. A runtime health test is designed to catch source failures as the system operates, often over much shorter windows and with thresholds chosen from the source model and assurance requirements.
Passing NIST STS, Dieharder or similar suites is therefore not a substitute for operational health monitoring.
Health tests vs entropy estimation
Entropy estimation asks how much unpredictability can be conservatively credited to the source under an evaluation model.
Health testing asks whether the source continues to behave within acceptable bounds during operation.
A source can have a good laboratory entropy estimate and later fail in the field. Conversely, a health test can pass while the claimed entropy rate is still overstated. You need both characterization and monitoring.
QRNG-specific considerations
QRNGs include classical measurement electronics around the quantum process. A health strategy should therefore consider both the source physics and the acquisition path.
Potential problems include changes in signal level, detector behavior, amplifier saturation, timing, digitization thresholds, environmental coupling or other classical artifacts that reduce the unpredictable contribution.
A credible QRNG architecture should be able to explain how such conditions become observable and how the device reacts.
Fail closed, not silently
From a security architecture perspective, an important question is what happens after a health-test failure.
If the system simply continues issuing output and hides the alarm, the test provides little protection. The response policy should be explicit and appropriate to the application.
Depending on the design, a failure might cause entropy output to stop, trigger reinitialization, enter a degraded mode, raise an alarm to a host, or require operator action. QRNG.io should explain these as architectural possibilities rather than prescribe one universal response.
What to document
For an entropy-source review, document:
- which health tests exist;
- what source behavior each targets;
- threshold rationale;
- startup behavior;
- continuous or periodic execution;
- failure handling;
- interaction with conditioning and downstream DRBGs;
- how false positives/negatives are considered;
- what telemetry is exposed to integrators.
Health tests are evidence, not marketing decoration
A product page that says “continuous health monitoring” without explaining the monitored property or failure response is incomplete.
For serious evaluation, engineers need enough information to understand the trust boundary without requiring disclosure of proprietary circuit details.
Where to go next
Pair this page with What Makes a QRNG Trustworthy?, SP 800-90B Explained, and Entropy Conditioning Explained.
Sources and further reading
Primary sources
- NISTFinal2018-01SP 800-90B: Recommendation for the Entropy Sources Used for Random Bit Generation
NIST lists identified errata to be corrected in a future update/revision.
- NIST CMVPCurrent2026Entropy Validation Server
States that the server runs the entropy assessment tool but additional documentation is required for validation.
- ETSIPublished Technical Report2026-03-25TR 104 171 V1.1.1: Implementation Guidelines for Quantum Random Number Generators
ETSI work programme marks it as a Technical Report and not a harmonised standard.
Part of the QRNG.io quantum randomness knowledge hub.