NIST SP 800-90A, 90B and 90C: which document answers which question?

Use the series as a map of responsibilities

The introduction to SP 800-90C connects deterministic mechanisms, entropy sources and their construction into a complete random-bit generator. A review should therefore begin with the question being asked. Is the evidence about an algorithm, the source feeding it or the way they are assembled? Write that question beside the document reference. This prevents a report about one component from being presented as if it covered every operating mode of a larger system. The mapping is also useful when technical teams divide work between hardware and software specialists.

Verified publication and scope table

The official publication catalogue is the appropriate place to check status. A search result containing a newer year can refer to a workshop, comment request or draft. Keep the status field alongside the date so the newest-looking document does not silently replace the agreed evaluation baseline.

Build a requirements matrix instead of a stack of PDFs

Create one row for each requirement or review question that applies to the chosen design. Add columns for the document edition, implementation component, evidence identifier, reviewer and disposition. A row should end in a reasoned conclusion such as demonstrated, not applicable with explanation or unresolved. Avoid using a single green tick for an entire publication. If the product has several configurations, identify which configuration each row covers. This makes the matrix an engineering control rather than an index of downloaded files that nobody can connect to the running build.

Read maintenance notes before interpreting an edition

The SP 800-90B publication page carries a May 2025 planning note identifying two errata for a future update. An errata notice is neither a new full edition nor permission to ignore the affected subject. Record the notice in the review baseline and determine how the applicable evaluation process treats it. If the team cannot resolve that question from public material, ask the responsible evaluator and preserve the answer. The same discipline applies to draft revisions: useful discussion material should remain visibly separate from requirements already adopted for the project.

Connect component evidence to the complete construction

A mechanism assessment and an entropy-source assessment may use different boundaries and assumptions. The integration review should explain how their interfaces fit together, including the information passed, the conditions for successful operation and the response to failure. Do not infer a construction class from the presence of a familiar algorithm name. Ask for the explicit design selection and the evidence that applies to it. Where a supplier provides only a component certificate, list the remaining integration questions. Missing coverage should be a visible project task rather than an optimistic sentence in the executive summary.

Manage changes without rewriting history

When a library, firmware image or operating environment changes, compare the new configuration with the reviewed baseline. Classify what changed and identify the matrix rows that depend on it. Some evidence may remain relevant; other evidence may need to be repeated or extended. Preserve the previous report and issue a new version or controlled supplement instead of overwriting the old conclusion. A clear history allows a downstream user to understand which build was reviewed at which time. It also prevents a current download from being confused with an older evaluated release.

Publication-baseline checklist

• Record the exact publication identifier, revision, status and date.
• Map each document to its component or construction question.
• Include applicable maintenance notes and unresolved interpretations.
• Connect every conclusion to version-specific evidence.
• Reassess affected rows when the implementation changes.

A good handover lets another engineer answer two questions quickly: which documents governed this review, and which implementation did the evidence describe? If either answer requires guessing from filenames, improve the manifest before accepting the package. This small administrative step protects the meaning of the technical work already performed.

Sources and verification

• SP 800-90A Revision 1: deterministic random bit generators — NIST — 2026-10-23
• SP 800-90B: entropy sources — NIST — 2026-10-23
• SP 800-90C: random bit generator constructions — NIST — 2026-10-23
• Random bit generation publication status — NIST — 2026-10-23