We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

FAQGLOBALFIPS 140-3

FIPS 140-3 Entropy evidence

A direct answer on what should show before a team relies on a FIPS 140-3 module, deterministic random bit generator (), or sensitive security parameter (SSP) generation claim.

Based on FIPS 140-3 and Cryptographic Module Validation Program (CMVP) Implementation Guidance; it does not assert that any specific source, , module, or certificate is approved.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
3 sections4 primary sources
Overview

Under FIPS 140-3, should show how the module obtains entropy, where the source sits relative to the cryptographic boundary or tested operational environment physical perimeter, what minimum entropy amount is claimed for SSP generation, and how that claim is reflected in the Security Policy, test report, and any certificate caveat.

Search this module

Find a question or answer quickly

3 of 3 questions
Question 1

What should entropy evidence answer first?

Start with the entropy path. The evidence should identify whether the module generates entropy itself, directly calls a well-defined source through a GetEntropy() interface, passively receives externally supplied entropy, or combines active and passive inputs. CMVP Implementation Guidance 9.3.A assigns different evidence and certificate caveats to those cases because the laboratory can corroborate some entropy estimates but cannot guarantee the quality of entropy supplied by an uncontrolled external source.

The core record should include the module boundary, or physical perimeter, source location, interface type, seeding path, and the minimum bits of entropy generated, requested, accepted, or believed to have been loaded for SSP generation. The DRBG name alone cannot support a generated-SSP strength claim; the seeding evidence must support that claim.

  • Map every entropy source to the cryptographic boundary, , physical perimeter, and instantiation or reseed event it supports.
  • Distinguish direct GetEntropy() access from seed loaders, LOAD commands, preloaded seeds, caller-supplied API buffers, files, and other passive inputs.
  • Record the minimum entropy amount used for SSP generation and the evidence basis for that amount.
  • Check whether the design triggers a certificate caveat such as modified SSP strength or no assurance of minimum generated-SSP strength.
Recommended next step

Prepare FIPS 140-3 entropy evidence

Use the entropy path, Security Policy, test-report addendum, certificate caveat, ESV or ENT notation, and CAVP records as one review set.

Assessment workflow
Turn entropy evidence into controls

Convert entropy-source, SP 800-90B, Security Policy, and caveat checks into accountable evidence requests.

Explore next step
Research workflow
Research a FIPS source question

Resolve CMVP guidance, CAVP record, ESV, and module-scope questions before procurement or release review.

Explore next step
Talk to Sorena
Talk through entropy evidence

Review module scope, entropy-source evidence, caveats, and next validation-support actions with Sorena.

Explore next step
Question 2

What SP 800-90B evidence belongs in the file?

When an entropy source validation is required, CMVP guidance points to SP 800-90B, IG D.J, and IG D.K. A source within a software, firmware, or hybrid module's that supports an available-entropy claim requires an certificate and a direct path from the module to the source's GetEntropy() interface. The evidence package must include raw noise-source access details, statistical-test results, the entropy assessment tool version, and the laboratory's heuristic analysis of how the noise source works and why the claimed entropy rate is supported.

The Security Policy must document the overall generated entropy and the estimated entropy per source output bit when SP 800-90B testing applies. If the vendor claims independent and identically distributed (IID) behavior, the support must be rigorous and must substantiate independence and identical distribution separately; the guidance warns that most noise sources do not produce IID events.

  • Keep the entropy-source description, raw data collection method, and rationale that collection does not alter source behavior.
  • Attach statistical-test outputs and the version of the CMVP SP 800-90B entropy assessment tool used.
  • Include the heuristic entropy analysis, not only the statistical-test result.
  • Document known or suspected noise-source failure modes and the health tests intended to detect them.
Question 3

How should teams review Security Policy and certificate evidence?

Review the Security Policy, evidence, and module certificate together. CMVP guidance requires different public statements depending on whether the module uses an internal source, a known source inside the , an external source, a passive load, or a hybrid design. An ESV certificate supports the evaluated entropy source; it does not replace the module's CMVP certificate. If entropy is externally loaded or cannot be corroborated for the deployed configuration, the module certificate may need a no-assurance caveat rather than a broad strength claim.

For multiple entropy sources, do not add entropy by intuition. CMVP guidance allows concatenating outputs from multiple independent SP 800-90B-compliant sources for a seed, but the Security Policy must explain which sources are creditable, whether they are physical or non-physical, and which method is used for entropy calculation. If sources are mutually dependent, at most one of those dependent sources may be credited.

  • Compare the design description, Security Policy entropy statement, or legacy ENT entropy-assessment notation, and certificate caveat for the same module version.
  • Confirm that caller guidance is present when an external party must provide entropy with a minimum claimed strength.
  • For multiple sources, document independence before summing credited entropy.
  • Do not treat a CAVP algorithm certificate, name, or generic FIPS reference as proof that the module's supports the deployed configuration.
Primary sources

References and citations

CMVP Implementation Guidance for FIPS 140-3
csrc.nist.gov4 citations
Referenced sections
  • Supports the FAQ's entropy-source scenarios, SP 800-90B evidence requirements, Security Policy statements, certificate caveats, and multiple-source entropy guidance.
  • IG 9.3.A is the main source support for entropy-source scenarios, GetEntropy access, Security Policy entropy statements, and certificate caveats.
  • IG D.J and D.K support the SP 800-90B evidence expectations: raw data, statistical testing, heuristic analysis, IID rationale, health tests, and Security Policy entropy amounts.
Show 1 more
  • IG 9.3.A and D.O support the Security Policy, certificate caveat, ESV or ENT notation, and multiple-source entropy review points.
"The module is either generating the entropy itself"
More quoted passages
"a CST laboratory is still responsible for performing a heuristic analysis"
NIST CAVP validation search
csrc.nist.gov2 citations
Referenced sections
  • Useful for checking algorithm validation records without treating those records as a substitute for module-specific entropy evidence.
  • CAVP records can support approved algorithm implementation checks, but algorithm evidence does not by itself establish module boundary or entropy-source validity.
NIST FIPS 140-3 security requirements for cryptographic modules
doi.org2 citations
Referenced sections
  • Defines the cryptographic-module validation context that makes entropy evidence relevant to sensitive security parameter management.
  • FIPS 140-3 establishes the cryptographic-module context and includes sensitive security parameter management among the module security requirement areas.
"sensitive security parameter management"
NIST SP 800-90B entropy assessment tool
github.com2 citations
Referenced sections
  • Public tool cited by CMVP guidance for SP 800-90B statistical testing of entropy sources.
  • CMVP guidance cites this public tool for SP 800-90B statistical testing; the tool output does not supersede the lab's heuristic analysis.

Related guides

FIPS 140-3 Algorithm Certificates FAQ

How CAVP algorithm certificates support, but do not replace, FIPS 140-3 cryptographic module validation evidence.

FIPS 140-3 Certificate Maintenance FAQ

How to maintain FIPS 140-3 certificate evidence after validation by checking module status, version, caveats, Security Policy, and revalidation records.

FIPS 140-3 Module Boundaries FAQ

Understand how FIPS 140-3 module boundaries affect cryptographic module scope, interfaces, software and firmware components, and bound or embedded validated modules.

FIPS 140-3 operational environments FAQ

Learn what a FIPS 140-3 operational environment means for software, firmware, and hybrid cryptographic modules, and what evidence to check before relying on a validation claim.

FIPS 140-3 security levels: how to choose and evidence them

A practical FAQ on FIPS 140-3 security levels, module scope, CMVP evidence, bound or embedded modules, and common claim mistakes.

FIPS 140-3 Vendor Affirmation FAQ

When vendor affirmation can support a FIPS 140-3 module claim, what it does not supersede, and which Security Policy, CAVP, CSTL, and test-report evidence to keep.

Show all related guides (28)

How should teams handle approved mode under FIPS 140-3?

Answer the FIPS 140-3 approved-mode question with service-level indicators, Security Policy evidence, and limits on non-approved functions.

FIPS 140-3 algorithm certificate mapping: ACVTS certificates to module boundary

Map CAVP algorithm certificates to FIPS 140-3 module services, approved security functions, security policy tables, and validation evidence.

FIPS 140-3 Applicability Test

Check whether FIPS 140-3 applies to a cryptographic module claim by testing agency use, module boundary, security level, approved functions, CMVP status, and procurement evidence.

FIPS 140-3 Approved and Non-Approved Mode Workflow

Classify FIPS 140-3 module services by approved security service, allowed no-security-claimed use, and non-approved service evidence.

FIPS 140-3 approved-mode evidence workflow

Collect FIPS 140-3 approved-mode evidence for a specific module service: boundary, indicator, selected CAVP capabilities, Security Policy entry, and deployment configuration.

FIPS 140-3 Change Impact Review

Review FIPS 140-3 module changes against boundary, version, operational environment, embedded module, software loading, CVE, and certificate evidence.

FIPS 140-3 CMVP Lifecycle and Status Guide

Follow a FIPS 140-3 module from scoping and CST-laboratory testing through CMVP review, publication, Active status, revalidation, and procurement checks.

FIPS 140-3 compliance guide

A FIPS 140-3 compliance guide grounded in official sources for cryptographic module scope, security levels, CMVP validation evidence, and procurement review.

FIPS 140-3 Entropy and DRBG Evidence

FIPS 140-3 entropy and DRBG guidance for module boundary decisions, entropy caveats, Security Policy evidence, ESV references, and DRBG CSP handling.

FIPS 140-3 FAQ for Cryptographic Modules

Answers to common FIPS 140-3 questions about scope, CMVP validation, algorithm certificates, module boundaries, approved mode, and validation evidence.

FIPS 140-3 Module Boundary Selector Workflow

A FIPS 140-3 workflow for selecting a cryptographic module boundary, separating embedded and bound modules, and collecting CMVP validation evidence.

FIPS 140-3 Security Policy Template

Draft the vendor-authored parts of a FIPS 140-3 CMVP Security Policy and prepare the structured module information that CMVP merges into the final policy.

FIPS 140-3 Validation Checklist

Checklist for preparing a cryptographic module for FIPS 140-3 validation: boundary, levels, services, approved algorithms, entropy, tests, security policy, and change evidence.

FIPS 140-3 Validation Maintenance

Decide whether a changed FIPS 140-3 module still matches its validation or needs a CMVP revalidation scenario, evidence update, or paused claim.

FIPS 140-3 Validation Maintenance Change Workflow

Triage a changed FIPS 140-3 module against current CMVP revalidation scenarios, Security Policy evidence, CAVP testing, operational environments, and CVE handling.

FIPS 140-3 vs ISO/IEC 19790 and ISO/IEC 24759

Compare FIPS 140-3 with ISO/IEC 19790 and ISO/IEC 24759 for cryptographic module validation scope, evidence, testing, and procurement claims.

FIPS 140-3: FIPS 140-2 vs FIPS 140-3

Compare FIPS 140-2 legacy references with FIPS 140-3 requirements, ISO/IEC 19790 alignment, CMVP testing evidence, and guidance mappings.

FIPS 140-3: Module Boundary and Service Mapping

Map a FIPS 140-3 cryptographic module boundary to services, approved algorithms, operational environments, and CMVP validation evidence.

FIPS 140-3: Module Boundary Selector

Select and document a FIPS 140-3 cryptographic module boundary across hardware, software, firmware, operational environment, services, and validation evidence.

FIPS 140-3: Operational Environment

FIPS 140-3 operational environment guidance for software, firmware, hybrid, CAVP certificate, EVM, and PAA/PAI validation claims.

FIPS 140-3: Security Levels Explained

Compare FIPS 140-3 Security Levels 1 through 4 by requirement area and document a level claim without extending it beyond the validated module.

FIPS 140-3: step-by-step workflow for mapping algorithm certificates to CMVP modules

Map CAVP algorithm certificates to a FIPS 140-3 module by matching the tested implementation, operational environment, service use, and CMVP Security Policy record.