SP 800-90 Implementation Hurdles for FIPS 140-3 Teams

Why SP 800-90 Updates Put Entropy in the Spotlight

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.

DRBG Updates May Force Changes to Your APIs

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.

Watch: SP 800-90C DRBG Updates

Key things implementers should review:

• How DRBGs are instantiated and seeded
• Whether prediction resistance is handled via a flag or as a separate operation
• How reseed requests are exposed and enforced
• Whether generate behavior changes based on the underlying construction
• How API changes will impact downstream application integrations

Choosing an RBG Construction Shapes the Architecture

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.

• RBG1: No internal entropy sources. It’s seeded externally, used, and then destroyed. No reseeding during its lifetime.
• RBG2: Can use physical or non-physical entropy sources, with the DRBG inside the same security boundary. Reseeding can happen based on app requests or the module’s own policy.
• RBG3: Brings more nuance—the entropy source lives inside the RBG boundary and can provide full-entropy output. Jake covered both the XOR and RS variants, and how they differ in full-entropy generation and reseeding.
• RBGC: Uses a tree structure that works well for larger, layered systems (hardware → hypervisor → VMs) where entropy needs to be distributed across multiple levels.

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.

Watch: SP 800-90C RBG Constructions Explained

Key takeaway: Choosing your RBG construction is an early architectural decision. It affects security boundaries, entropy placement, reseeding behavior, and how applications consume randomness.

Security Boundaries: Your Diagrams Need to Match Reality

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.

Watch: SP 800-90C RBG Security Boundaries Explained

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.

Designing a Modern Entropy Provider Architecture

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.

Watch: SafeLogic Entropy Provider Architecture

Important Questions to Answer Early:

• Where does the raw entropy originate?
• How is that source exposed to the cryptographic module boundary?
• How does the module access entropy after initialization?
• How are DRBG reseed operations connected to entropy output?
• How does the architecture fit within the OpenSSL provider framework?
• How will the design be tested and documented?

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.

The Big Jump in JENT/ESV Testing Data: From 1 Million to ~250 Million Samples

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.

Watch: JENT Entropy Testing Updates

The newer JENT analysis process can introduce a noticeable increase in effort across data collection, lab testing, and documentation.

Why Embedded Environments Make This Even Harder

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:

• How long will collection actually take?
• How will we offload the data?
• Where will we store it?
• How many operating environments need this treatment?
• How will this affect lab timelines?
• How much extra documentation will be required?

If you’re planning ESV updates or adding new operating environments, bake these considerations into your project timeline early.

An Action Plan for SP 800-90 Implementation Work

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:

1. Audit your DRBG API behavior — Make sure reseed and generate operations can be cleanly separated and that prediction resistance aligns with current expectations.
2. Choose your RBG construction early — Understand the implications for entropy placement, security boundaries, reseeding, and full-entropy output.
3. Ensure your code matches your diagrams — The implementation, architecture diagrams, security policy, and validation evidence all need to line up.
4. Plan for bigger ESV data collection — Account for much larger sample volumes, collection time, storage, lab processing, and documentation if you’re using JENT or similar software entropy sources.
5. Evaluate your entropy provider architecture early — Especially in OpenSSL-based environments.

What This Means for FIPS 140-3 Teams

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.