Hardware RNGs for Embedded Systems Explained

By RWT Robotics Editors Published November 6, 2026

An RTOS is built around determinism: the same inputs, the same timing, the same result. Yet a surprising number of embedded projects also need the opposite, a source of numbers nobody can predict. Cryptographic keys, TLS handshakes, session tokens and even jittered retry timers all depend on it.

Pseudo-random versus true random

A pseudo-random number generator is just an algorithm. Give it the same seed and it produces the same sequence, which is perfect for repeatable simulations and terrible for security. Many C libraries implement rand() this way, which is why it should never be used to generate keys. A true random number generator measures a physical process instead, such as thermal noise or the jitter between free-running ring oscillators.

Many modern microcontrollers include one on the chip. Numerous STM32 parts have an RNG peripheral, and Espressif’s ESP32 family exposes a hardware random number generator as well. The usual pattern is to use that hardware entropy to seed a cryptographically secure PRNG rather than reading the raw peripheral for every value, because raw noise sources are slower and can carry bias.

Getting entropy into RTOS tasks

RTOS projects handle this in different ways. Zephyr defines an entropy driver interface and builds its random number APIs on top of it. FreeRTOS-Plus-TCP asks the application to supply its own random number function, which is a common place for weak implementations to slip in unnoticed.

Two habits help. Avoid long blocking reads from an entropy source inside time-critical tasks, and run startup health checks so a failed noise source is detected rather than silently returning predictable values. NIST SP 800-90B is the usual reference for evaluating entropy sources if your product needs formal documentation.

Certified randomness in gaming machines

Few industries scrutinise random number generation as closely as regulated gambling. Gaming devices are tested by independent laboratories against published standards such as GLI-11, and online casino platforms commission similar audits of their game engines. Players notice too: Hungarians comparing the best online casinos in Hungary may check whether a site names its testing lab. That world is for adults 18+, and anyone who takes part should play responsibly, but it shows what a mature verification culture for randomness looks like, something firmware teams can learn from.

A short checklist for your next board

Confirm whether your MCU has a hardware RNG and read its errata.
Seed a vetted CSPRNG from it instead of rolling your own.
Add a health test at boot and fail safe if entropy looks wrong.
Keep entropy reads out of hard real-time paths.
Document where every random value in the system comes from.

Randomness is easy to overlook because a broken generator still produces numbers that look fine. Treat it as a reviewed subsystem, not a helper function, and your device will be harder to attack.