What a FIPS 140 certificate actually tells you

Executive finding. A FIPS certificate and its Security Policy are a structured, corpus-wide security record, and this report reads them for what they reliably deliver: a map of the trusted-computing-base surfaces around each module (§6), a measure of how far its named components have drifted since validation (§5), and a ranked view of where a review should look first (§9). A certificate attests one module version, in one approved-mode configuration, at one moment, so it is best read as a map of what to verify in a deployment, which is exactly what makes these artifacts a fast way to aim that verification.

Terminology. Throughout, “certificate” / “validation” / “update” refer to the CMVP FIPS 140-3 validation certificate and its validation-history events, not an X.509/TLS certificate.

Corpus composition. The corpus is a near-census of the 415 FIPS 140-3 modules validated in cert window #4650–#5159. Lifecycle, archetype, algorithm and component-drift findings use all 415. The Security-Policy-structure findings, TCB surfaces (§6), review-priority (§9, §10) and document quality (§11), require the full pdfplumber SP extraction and are computed over the 136 modules that carry it; the rest are metadata-and-text records fetched from CMVP.

0Corpus confidence

The decision model, what actually backs deployed FIPS?

The whole analysis is the evidence layer for one reviewer decision: from “product claims FIPS” down to “is the deployed crypto function the same validated version, in approved mode?”, and on any mismatch, “was it a patch inside or outside the module boundary?” (the security-vs-compliance fork). Corpus data populates the branches below.

flowchart TD
  A["Product claims FIPS 140 support"] --> B["CMVP certificate for the module?"]
  B -->|No| Z["No public FIPS validation evidence"]
  B -->|Yes| C["Certificate status / assurance type?"]
  C -->|Active full validation| D["Check deployed module identity"]
  C -->|Interim validation| C1["Interim CMVP assurance
2-yr window, reduced review depth"]
  C -->|Historical / revoked| C2["Exists, but not current active assurance"]
  C1 --> D
  C2 --> D
  D --> E["Deployed version = certificate version?"]
  E -->|Yes| F["Check operational environment"]
  E -->|No / unknown| G["Certified-state drift"]
  F --> H["Deployed OE = listed / allowed OE?"]
  H -->|Yes| I["Check approved mode"]
  H -->|Porting rules used| H1["Vendor/User affirmation
limited assurance"]
  H -->|No / unknown| G
  H1 --> I
  I --> J["Operated per Security Policy?"]
  J -->|Yes| K["Check services / algorithms"]
  J -->|No / unknown| G
  K --> L["Only approved services / algorithms?"]
  L -->|Yes| M["Strongest deployed FIPS evidence"]
  L -->|No / unknown| N["Validated module, use outside approved mode"]
  G --> O["Caused by a patch/update?"]
  O -->|Outside crypto boundary| P1["May preserve validation if boundary/OE unchanged"]
  O -->|Inside crypto boundary| Q["Security/compliance fork:
patched but not validated until cert update"]
  O -->|Unknown| R["Opacity gap: need vendor evidence"]

Corpus populates the branches: status/assurance, Full 200 · Interim 146 · other 69; ever updated, 22% (so most are frozen at the “version = certified?” branch); drift, measured in §5 (OpenSSL providers ~39–40 upstream CVEs since cert); the patch-boundary fork and OE/mode branches need per-module Security-Policy + vendor evidence (the opacity gap a data layer surfaces).

1Lifecycle & certificate window

Volume context (external input, provided, not corpus-derived): active 140-3 certs by year run 2022:6 · 2023:6 · 2024:176 · 2025:163 · 2026-YTD:265, a transition-driven surge (~500/yr). The population skews to very recent certificates, so the freeze/exposure patterns are structural and will bite as the 2024–26 cohort ages inside its window without updates.

Assurance type, certificates differ in what backs them

2CMVP re-validation cadence

How often a certificate carries an Update entry (any kind, security, version, OE, administrative, or rebrand; we do not yet classify the type). If a certificate is never updated, public CMVP evidence does not show that later product fixes, firmware updates, or dependency changes are part of the validated configuration.

3Cryptographic posture, specific algorithms

1949 distinct normalized approved-algorithm labels (operation-level, e.g. “RSA SigVer”, “ECDSA KeyGen”, not distinct primitives); median 27 per module. Presence ≠ insecure use, legacy primitives are often retained for verify-only/legacy paths, and AES-ECB is a building block; the signal is breadth of the approved surface.

4Post-quantum readiness

10/415 (2%) list any PQC algorithm, but composition matters: it is almost entirely stateful hash-based signatures (LMS/HSS, SP 800-208) for firmware signing. Adoption of the new lattice standards ML-KEM/ML-DSA (FIPS 203/204) and SLH-DSA (FIPS 205) is effectively zero (lattice module(s): [], under the pre-standard 'Kyber' name).

5Component identification & drift

Components are identified generically, a full-record scan (module name + software/firmware versions + SP body/tables) against an extensible, CPE-mapped catalog (generic whole-record scanning rather than certificate-specific rules). Strong = the module names/ships it (name/version field); a CPE enables the NVD drift join below.

Naming the actual code is the highest-resolution view of a module's trust boundary the public record offers, and the sparsest: it exists only where a component is named. It is the component-level counterpart to the surface-level TCB view in §6, which stays visible for the many modules that name nothing. Where this section goes dark, §6 still sees the surface.

Component drift, the certified-state freeze, measured

For modules that wrap a well-known upstream (OpenSSL, GnuTLS, libgcrypt, Linux kernel, NSS), this counts CVEs disclosed in that upstream component (CPE-matched in NVD) since the module's initial validation date. It measures how far the upstream has moved past the certified snapshot.

Coverage is component-shaped, and mostly crypto libraries. A drift signal is only possible where a module both names a component and that component maps to an NVD CPE. That holds for 85 of 415 modules (OpenSSL 36, Linux kernel 23, GnuTLS 7, libgcrypt 7, NSS 6, U-Boot 3, wolfSSL 2, strongSwan 1). The other 330, disproportionately the hardware, firmware, and appliance modules, name no CPE-mappable component, so they get no component-level drift signal at all. That blank is a prompt: for the hardware, firmware, and appliance modules where boot and firmware integrity matter most (the spotlight above), the component is simply unnamed at this resolution, so §6 reads them at surface resolution instead, where they stay legible.

Read carefully, this is a drift/pressure indicator, NOT a vulnerability count for the module. The certified version may or may not be affected by any given CVE, and distros routinely back-port fixes without re-validating. For the Linux kernel the count spans the whole kernel, most of it outside the crypto subsystem. The number answers 'how much has the named upstream churned since this certificate froze', which is the question a reviewer should then run down.

Linux-kernel modules (23): upstream CVE counts since cert range 3932–10212, but that is whole-kernel volume, the vast majority outside the crypto subsystem, so it overstates crypto-relevant drift and is kept separate from the table above.

6TCB surfaces visible in public FIPS artifacts

FIPS validation certifies a defined cryptographic-module boundary; the security of that boundary usually depends on the surrounding trusted computing base (TCB): the boot chain, firmware-update path, debug/recovery controls, host/OE dependencies, network-management services, and secure-element/HSM trust anchors. A Security Policy is not an SBOM, but it is often enough to sketch the core TCB surfaces around the module, which is a more useful thing to ask of it than deployment proof.

What “TCB surface” means here. Public evidence of the mechanisms that decide whether the validated cryptographic boundary stays the code and configuration users rely on: the boot chain, firmware-update path, debug/recovery controls, host/OE dependencies, and trust anchors. Each surface below is an architectural pattern (a motif) matched from public signals, so a match locates the surface where that bug class would matter, pointing a review straight to where to look.

Bottom line: public FIPS artifacts are genuinely useful TCB-surface evidence. They reveal where boot, firmware-update, debug/recovery, host/OE, network-service, and component-version questions should be asked, turning a certificate into a map of what to verify. Where a component is unnamed (§5), that map still marks the spot to check.

7What the devices expose

8Device classification

Coarse taxonomy from name + vendor + type + embodiment. The classes behave very differently, chips are frozen silicon (rarely re-validated), HSMs are actively maintained (100% re-validated), network appliances are well-documented but re-validate less, and software carries the broadest crypto surface.

9Risk-triage lens

An active module whose last validation is old and which exposes a remote/networked interface is where an unpatched CVE would matter, its certified state predates the fix and no re-validation has pulled the fix in. This is the internal signal to correlate against external CVE/advisory timelines (NVD, vendor PSIRTs).

10Operational archetypes & review-priority

Embodiment (hw/sw/fw) is too coarse for risk. Operational archetype captures the attack path and lets reachability be weighted by class, a network interface on a software library is host-mediated (the app listens, not the module), on a network appliance it is the management/data plane. Review priority = Likelihood + Impact as ordinal ranks (a rank sum, not a product) banded into tiers, explicit rules, no weighted coefficients; measured upstream CVE drift weighs most (real evidence, not heuristic). The tiers are review-order candidates, not vulnerability severities.

11Machine-readability & extraction confidence

An extraction-friendliness / completeness proxy, not a judgement of security. It measures whether the Security Policy is structured, complete, and machine-readable, a triage signal for a large corpus, not authoring quality per se.

12Vendors with multiple certificates

Vendor names are entity-normalized (trademark marks, legal suffixes, and punctuation removed), so “Cisco Systems, Inc.” and “Cisco Systems, Inc” count once: 191 raw name strings collapse to 174 organizations. Parent/subsidiary and rebrand relationships are not resolved.

13Market structure (labs)

16 accredited labs; work is concentrated in a few CSTLs, concentrated delivery capacity and a potential systemic dependency. Where validation delay actually arises cannot be established from issued certificates alone (see the caveat in §14).

14Where FIPS time accumulates

This corpus cannot explain why validations take so long. It is survivorship-biased (only modules that succeeded; abandoned/failed/stuck submissions are absent) and carries no pipeline-timing data (no IUT / Cost-Recovery / Pending-Review durations, no comment cycles). So the below are candidate predictors / hypotheses of review burden, not measured time drivers. A true root-cause model needs longitudinal MIP/IUT snapshots.

flowchart LR
  A["Vendor product / module design"] --> B["Boundary, services, SSPs, OE defined"]
  B --> C["Security Policy + evidence package"]
  C --> D["CSTL testing / pre-validation"]
  D --> E["Implementation Under Test"]
  E --> F["Cost Recovery / admin queue"]
  F --> G["Pending CMVP Review"]
  G --> H["CMVP Review"]
  H -->|comments| I["Comment resolution loop"]
  I -->|vendor + CSTL response| H
  H -->|accepted| J["Finalization"]
  J --> K["Certificate issued + SP posted"]
  K --> L["Patch / version / dependency / CVE event"]
  L --> M{"Change inside crypto boundary?"}
  M -->|No / outside| Nn["May not require update if assumptions unchanged"]
  M -->|Yes / unclear| O["Update / revalidation path"]
  O --> C
  classDef queue fill:#fff7e6,stroke:#d6a642;
  classDef rework fill:#fbe9e9,stroke:#c25b5b;
  class E,F,G,H,J queue;
  class I,O rework;

Not determinable from this corpus (needs MIP/IUT snapshots + status-transition history):

• days in IUT / lab pipeline
• days in Cost Recovery
• days in Pending Review
• number of CMVP comment cycles
• which party (vendor/lab/CMVP) drove a delay
• which evidence class (entropy/algorithm/physical/SSP/OE/SP-quality) caused rework
• how long abandoned or still-pending modules have waited (not in a validated-cert corpus at all)

Method, reproduction & caveats

Pipeline (deterministic given the swept cert range + cached NVD responses): build_corpus.py (fetch cert page + Security Policy PDF → per-module JSON) → build_drift.py (NVD CVE API v2, CPE virtualMatchString, CVEs in each named component since validation date) → build_version_exact.py (CVEs whose affected-range includes the certified version, published ≥ validation date, Rejected/Disputed excluded) → analyze_corpus.py → this report / findings / explorer. All corpus figures come from corpus_analysis.json; external inputs (volume-by-year, industry timeline) are labelled inline as provided, not corpus-derived.

• Corpus is a swept sample of the recent CMVP certificate-number range, filtered to FIPS 140-3, not the full population.
• Validation-history timing (windows, cadence, staleness) has ~100% coverage; SP-revision development-span only where the SP ships a dated revision table (a minority).
• Component/version-exact CVE counts are upstream pressure indicators, not module-vulnerability counts; distro back-ports are not reflected in the version string, so version-exact is an upper bound. NVD data as of the reference date.
• The risk-triage lens and review-priority are attack-path hypotheses requiring confirmation, not confirmed vulnerabilities; L5 (confirmed exposure) is never reached from public CMVP+NVD data alone. Impact is an expert prior; thresholds are not yet calibrated against expert labels.
• Document grades reflect extraction-friendliness + completeness, not authoring or security quality.
• Terms: CMVP = the FIPS 140-3 validation program/certificate; CSTL = accredited test lab; Security Policy = the per-vendor module PDF; SSP/CSP = protected keys/parameters; OE = operational environment; sunset = certificate end-of-active-window.