If your team is working through a FIPS 140-3 validation, entropy and randomness have become major topics in architecture discussions.
The SP 800-90 series has long been the foundation for cryptographic randomness, but recent updates—and shifting validation expectations around entropy sources, deterministic random bit generators (DRBGs), and random bit generator (RBG) constructions—are creating implementation headaches for development teams.
At ICMC 2026, SafeLogic’s Director of Engineering, Jake Maynard, gave a talk on what these changes look like when you’re implementing software entropy sources. These updates can ripple through your API design, cryptographic module boundaries, entropy provider architecture, testing timelines, documentation, and the sheer volume of data you need to collect from vendors.
For anyone building a new FIPS module, updating an entropy source, or adding support for a new operating environment, the details matter—a lot.
One of the first challenges Jake highlighted involves updated rules for DRBGs.
Many existing cryptographic APIs let you make a generate request and flip a flag when you need predication resistance. Under the new DRBG guidance Jake discussed, that pattern might not cut it anymore. Instead of combining prediction resistance and output generation in a single call, you may need to explicitly reseed first, then follow with a separate generate request.
It sounds like a small tweak, but in practice, it means real engineering work. For teams with established DRBG implementations, this affects how your APIs are structured, how reseeding gets triggered, and how applications interact with the module. What used to live neatly inside a single function call now needs to become a clearer, multi-step process.
Jake also walked through the different random bit generator (RBG) constructions described in SP 800-90C: RBG1, RBG2, RBG3, and RBGC.
These differ in meaningful ways, especially around where the entropy source lives, how reseeding works, and where you draw your security boundaries.
One interesting point with RBG3 (RS variant): every generate request to the RBG construction can trigger a reseed. But if you expose the underlying DRBG directly to an application, the behavior can differ—direct DRBG calls might not reseed the same way.
Key takeaway: Choosing your RBG construction is an early architectural decision. It affects security boundaries, entropy placement, reseeding behavior, and how applications consume randomness.
The diagrams Jake showed made it clear why getting these boundaries right is important during validation.
In an RBG1 setup, the entropy source sits outside the RBG boundary. In RBG2, the DRBG and entropy source share the same cryptographic module boundary. RBG3 keeps the entropy source inside the RBG boundary, but behavior varies between the XOR and RS variants.
These choices directly influence your security policy, how the lab evaluates your implementation, and what evidence you need to provide. If your architecture diagrams don’t accurately reflect how the code works and how applications request random bits, validation gets painful fast.
Key Takeaway: For FIPS 140-3 teams, alignment is everything—the code, the diagrams, the security policy, and the test evidence must all tell a consistent story.
To make these concepts concrete, Jake shared how SafeLogic approaches entropy providers. SafeLogic’s design connects a time-jitter RNG noise source to a FIPS module through the OpenSSL provider framework.
Instead of treating entropy as a black box, they expose a clean provider-compatible interface. After initialization, the FIPS module can call get_entropy, and the DRBG’s reseed function pointers link directly to that output.
This kind of clarity matters because entropy can no longer be an afterthought. Teams need solid answers to these architectural questions early in development.
A thoughtful entropy provider strategy can remove a lot of uncertainty as SP 800-90 expectations continue to evolve.
Learn more about CryptoComply Entropy Provider.
One of the most eye-opening parts of Jake's talk was the discussion of testing.
SafeLogic has been working with software entropy sources, including the Jitter Entropy Library (JENT). Previously, they collected 1 million raw samples and ran 1000 × 1000 restart tests—significant, but manageable.
Under newer heuristic assessment processes, the requirements have grown dramatically. For a recent update supporting two embedded environments, they needed roughly 250 million raw samples—about 5.4 GB of data that had to be pulled off the devices.
The collection took more time: 10 million samples required 60–80 minutes per device. The team had to repeat the cycle many times (collect → offload → store → repeat). Lab processing time also jumped from 20–30 minutes per environment to 1.5–2 hours, and documentation requirements increased.
The newer JENT analysis process can introduce a noticeable increase in effort across data collection, lab testing, and documentation.
These larger data requirements hit embedded systems particularly hard. Resource-constrained devices often have limited storage, slow interfaces, and tricky offload paths. When you need hundreds of millions of samples, the practical burden goes well beyond the raw numbers.
Teams need to think beyond “Can the device generate the data?” and ask:
If you’re planning ESV updates or adding new operating environments, bake these considerations into your project timeline early.
Jake’s talk drove home one key point: don’t leave entropy and randomness until the end of the validation cycle.
Here are some practical steps teams should consider:
SP 800-90 updates are raising the bar for entropy and randomness implementations. The impact shows up in engineering work: DRBG workflow changes, RBG construction decisions, security boundary definitions, entropy provider design, larger datasets, longer testing cycles, and more documentation.
These challenges are manageable—but only if you plan for them. Teams that treat entropy and randomness as core architectural concerns (rather than last-minute compliance tasks) will move through FIPS 140-3 much more smoothly.
SafeLogic’s CryptoComply Entropy Provider is built to help organizations tackle these exact challenges with a practical, production-ready solution.
Learn more about CryptoComply Entropy Provider or request a consultation with a SafeLogic entropy expert.