FAQGLOBALFIPS 140-3

FIPS 140-3 Certificate maintenance FAQ

Maintain FIPS 140-3 certificate evidence by checking the current CMVP record, module version, Security Policy, caveats, and change history before repeating a validation claim.

This page helps separate valid module evidence from stale screenshots, algorithm-only certificates, and unsupported post-change claims.

Author
Sorena AI
Published
May 9, 2026
Updated
Jul 24, 2026
Questions
3

Structured answer sets in this page tree.

Primary sources
4

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated Jul 24, 2026
Overview

Short answer: maintain a FIPS 140-3 claim against the exact cryptographic module, public , Security Policy, version, tested environment, and approved services. A copied certificate image or whole-product shorthand cannot establish that scope. Reassess the claim whenever the module or its relied-on evidence changes.

Search this module

Find a question or answer quickly

3 of 3 questions
Question 1

How should teams maintain a FIPS 140-3 certificate claim?

Treat the public CMVP certificate entry as the current reference for the validation claim. Before using it in procurement, customer trust, audit, or product-security material, verify the status, certificate number, module name, vendor, version, tested configuration, caveats, Security Policy, and validation history on the official NIST CMVP site. Record the date of that check because the public status and supporting documents can change.

Do not rely on a downloaded certificate image or a vendor slide as the only proof. FIPS 140-3 treats CMVP validation as a module-level decision after accredited-laboratory testing and CMVP review, so the public claim must continue to identify the module that was actually validated rather than the surrounding product by implication.

  • Record the official CMVP URL, certificate number, validation status, module name, vendor, module version, tested configuration, and date checked.
  • Compare the product or embedded module being offered with the certificate entry and the non-proprietary Security Policy.
  • Re-check the CMVP entry before renewing public claims, responding to procurement questionnaires, or accepting a vendor's updated module package.
Citations
Question 2

What changes trigger a maintenance review?

Review the certificate whenever the module, product packaging, embedded validated module, operational environment, algorithm set, Security Policy wording, vendor evidence, or vulnerability status changes. First decide whether the change is outside the validated boundary, changes only documentation, or changes security-relevant code, hardware, configuration, or dependencies. Then ask the vendor and CST laboratory which CMVP submission or revalidation path, if any, applies; a customer cannot extend a certificate by its own assessment.

A maintenance review does not extend the original validation. CMVP guidance makes this concrete for bound or embedded modules, operational environments, algorithm implementations, software or firmware loading, and security-relevant vulnerabilities. After validation, a security-relevant CVE may require design changes, implementation changes, updated guidance, or a CST-laboratory submission; the vendor must address the module's continued validated-list status with CMVP.

  • Check whether the offered product is the validated module itself or a product that incorporates a validated module.
  • Check whether module version, hardware version, software or firmware version, tested configuration, and caveats still match the deployed or supplied item.
  • If a validated module is embedded or bound to another module, watch for changes in the referenced module's status because CMVP guidance can make the dependent claim inherit status.
Citations
CMVP Implementation Guidance for FIPS 140-3

Supports change review for embedded or bound validated modules, operational environments, algorithm evidence, software or firmware loading, vulnerabilities, and inherited Historical status.

CMVP validated modules overview

Explains that certificate detail pages include module information, algorithm references, Security Policies, certificate images, and vendor links when provided.

Question 3

What evidence should be kept for certificate maintenance?

Keep a compact evidence record that lets a reviewer repeat the check. It should show the official CMVP entry, the Security Policy used, the exact product or module version in scope, the claim being made, and any change or revalidation question that remains open.

Separate completed validation evidence from engineering, vendor, or laboratory work in progress. FIPS 140-3 says that modules validated under CMVP are considered conforming; planned testing, internal readiness, CAVP algorithm certificates, or an unpublished submission do not establish that completed module-validation claim.

  • Save the CMVP certificate URL, certificate number, current status, validation date shown on the entry, Security Policy URL or file reference, caveats, and validation-history notes.
  • For vendor responses, keep the vendor's signed or written statement that identifies the validated module or incorporated validated module and its certificate number, then compare it with the CMVP entry.
  • Track open maintenance actions separately: laboratory or CMVP process question, algorithm transition check, vulnerability or flaw assessment, Security Policy update, or product-version mismatch.
  • Do not present work in progress as completed FIPS 140-3 validation; use the posted CMVP module record as the public completion evidence.
Citations
Primary sources

References and citations

csrc.nist.gov
Referenced sections
  • Supports checking CAVP, approved service, embedded module, and operational-environment evidence when a certificate claim depends on those details.
"validation certificate serves as a benchmark"
csrc.nist.gov
Referenced sections
  • Supports comparing vendor claims with CMVP certificate details and the posted Security Policy before accepting a validation claim.
csrc.nist.gov
Referenced sections
  • Official search page for checking certificate number, vendor, module name, validation status, and certificate details.
Related guides

Explore more topics

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 Algorithm Certificates FAQ
How CAVP algorithm certificates support, but do not replace, FIPS 140-3 cryptographic module 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
An official source FIPS 140-3 compliance guide for cryptographic module scope, security-level claims, 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 Entropy Evidence FAQ
How FIPS 140-3 entropy evidence should document entropy source location, GetEntropy access, SP 800-90B testing, Security Policy text, and certificate caveats.
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 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 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 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 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 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.
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.
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.