操作系统都提供 CSPRNG，并以硬件熵作为种子：Linux 上是 getrandom(2) 和 /dev/urandom，macOS 和 BSD 上是 getentropy 和 arc4random，Windows 上是 BCryptGenRandom。各语言的 API 对它们做了封装：浏览器中的 crypto.getRandomValues()（每次调用最多 65,536 字节）、Node.js 中的 crypto.randomBytes、Python 的 secrets、Go 的 crypto/rand、Java 的 SecureRandom。Math.random()、Python 的 random 等通用生成器是可预测的，切勿用它们生成任何秘密值。
NIST SP 800-90A Rev. 1 规定了经批准的确定性生成器（Hash_DRBG、HMAC_DRBG 和 CTR_DRBG），SP 800-90B 规定熵源，SP 800-90C 规定如何组合两者；FIPS 140-3 模块必须使用它们。已被撤回的 Dual_EC_DRBG 是疑似存在后门的生成器的典型案例。
现实中大多数随机数生成器故障出在种子上，而不是算法上：嵌入式设备在熵还不够时就生成密钥，克隆的虚拟机以相同的状态恢复运行，fork 出的进程共享同一个生成器。ECDSA 对此尤其敏感，因为可预测的 nonce 会暴露私钥；确定性 nonce 或对冲（hedged）nonce 可以消除这种依赖。