Artifact GuideGLOBALFIPS 140-3

FIPS 140-3 Operational Environment

A focused guide to the operational-environment claims that appear in FIPS 140-3 module validation work.

Use it to check tested OS, platform, processor, hypervisor, algorithm-certificate, embedded module, and accelerator claims before relying on a certificate.

Author
Sorena AI
Published
May 9, 2026
Updated
May 9, 2026
Sections
5

Structured answer sets in this page tree.

Primary sources
3

Cited legal and guidance references.

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

Use this page when a FIPS 140-3 module claim depends on where the cryptographic module or algorithm implementation was tested. Operational environment is not a generic deployment label: in CMVP guidance it can control whether a software, firmware, or hybrid module may claim a tested operating system, platform, processor, hypervisor, embedded validated module, or processor accelerator path.

Section 1

What operational environment means in FIPS 140-3 validation

FIPS 140-3 identifies operating environment as one of the requirement areas for secure design, implementation, and operation of a cryptographic module. The standard also says the chosen module security level must be appropriate for the application, environment, and services the module provides.

For software modules, CMVP implementation guidance is more concrete: each operational environment listed for the module must include the operating system, platform, and processor tested; if a hypervisor was used, it must also be listed. A certificate or procurement review should therefore read the OE as tested configuration evidence, not as permission to run the same claim on any similar host.

  • Capture the module type before reviewing OE claims: software, firmware, hardware, hybrid, bound module, or embedded module.
  • For software OEs, record operating system, platform, processor, and hypervisor when one was used in testing.
  • Treat security level, module boundary, services, and OE together because FIPS 140-3 validation applies to the module as tested.
  • Do not infer support for another processor size, operating system, or platform unless the CMVP or CAVP evidence covers it.
Section 2

CAVP algorithm certificates must fit the module OE

CMVP guidance treats the validated algorithm implementation and its tested operational environment as part of the evidence chain for a FIPS 140-3 module submission. The algorithm implementation must not be modified when integrated into the module, and the CAVP-tested OE must be identical to, or fully included in, the OE being tested by the CST laboratory.

This is where many overbroad claims fail. A 32-bit processor test does not support a 64-bit processor claim by assumption. An algorithm tested on one operating system does not automatically support another operating system. Memory size and processor frequency are called out as not relevant in the cited example, but OS, platform, processor, and processor bit size are.

  • Match each CAVP certificate to the algorithm name, version, and tested OE used in the module submission.
  • Confirm the algorithm implementation was not changed when it was integrated into the cryptographic module.
  • Reject claims that silently expand a tested OS, processor bit size, platform, or hardware implementation to an untested environment.
  • If algorithm testing was not done directly by the CST lab, keep the vendor-supplied OE and vector-set evidence the lab used to verify the result.
Section 3

Embedded and bound modules add OE inheritance checks

If the implementation under test depends on an embedded or bound validated module, operational environment review must cover both sides of that relationship. CMVP guidance says that for software, firmware, and hybrid binding cases, the implementation under test and the embedded validated module must each operate on tested OEs that are the same, or one must be within the other.

The same guidance requires the submission materials to identify the embedded validated module by name, CMVP certificate number, and version, and to separate IUT information from EVM information in the Security Policy and validation test report. That makes OE comparison a documentation control as well as a technical test-scope control.

  • List the IUT and EVM boundaries separately so the tested OE for each module can be compared.
  • Record EVM name, CMVP certificate number, and version in the evidence pack.
  • Mark EVM-provided services, algorithms, SSPs, self-tests, and error-state information in the Security Policy where CMVP guidance requires distinction.
  • Before adding a post-validation IUT OE, check whether the EVM certificate already covers that OE or whether the EVM OE would also need to be expanded.
Section 4

Processor accelerators and PAA/PAI OE claims

Processor Algorithm Acceleration and Processor Algorithm Implementation claims can change how an OE is represented and tested. CMVP guidance says a module certificate must never include an OE that was not individually tested by the lab, and the test report must demonstrate that all module, PAA, and PAI code branches used by certificate OEs were tested within the tested OE combination.

Do not treat accelerator support as a marketing attribute detached from validation scope. If the module uses PAA or PAI, the certificate and test evidence need to show whether each OE was tested with the accelerator path, without it, or through an accepted similar-OE rationale.

  • Identify whether each OE supports PAA/PAI and whether module testing covered that path.
  • For a similar-OE rationale, keep the lab justification and confirm there are no binary differences for the module code across the similar OEs.
  • Check that the certificate does not list an OE the lab did not individually test.
  • Keep test-report evidence showing the module and accelerator code branches exercised by the listed OEs.
Section 5

Operational-environment evidence checklist

Use this checklist before publishing a FIPS 140-3 claim, relying on a supplier certificate, or preparing a submission. Every item should tie back to a tested module, certificate, or test report rather than a generic statement that an environment is supported.

  • Module OE record: operating system, platform, processor, hypervisor if used, module version, module type, and certificate number.
  • Algorithm OE record: CAVP certificate, algorithm implementation name and version, tested OE, and proof that the implementation was not modified during integration.
  • Boundary record: diagrams or tables showing the cryptographic boundary, any embedded or bound module, and which OE applies to each module.
  • EVM record: EVM certificate number, version, active status at submission, services or algorithms used, and Security Policy markings that separate IUT and EVM data.
  • PAA/PAI record: accelerator support per OE, with/without testing coverage, similar-OE rationale when used, and test-report evidence for exercised code branches.
  • Change record: any OS, processor, platform, hypervisor, binary, EVM, CAVP certificate, or accelerator change that could make the existing OE evidence no longer match.
Primary sources

References and citations

csrc.nist.gov
Referenced sections
  • Public search page for confirming algorithm validation certificates used in the OE evidence pack.
"validation-search"
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
A grounded workflow for collecting FIPS 140-3 approved-mode evidence: module boundary, approved services, service indicators, CAVP certificates, Security Policy entries, and change review.
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 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 compliance guide
A grounded 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
Build a FIPS 140-3 module Security Policy with sections for boundary, roles, services, approved algorithms, SSP handling, self-tests, and CMVP evidence.
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
Maintain FIPS 140-3 validation claims by checking module identity, certificate status, boundary changes, operational environments, and CAVP evidence.
FIPS 140-3 Validation Maintenance Change Workflow
A FIPS 140-3 workflow for triaging module changes against CMVP validation scope, Security Policy evidence, CAVP certificates, software loading, and CVE records.
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: CMVP Lifecycle Timeline
Practical FIPS 140-3 guidance for CMVP Lifecycle Timeline: scope, controls, evidence, source-linked decisions, and implementation checkpoints.
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: Security Levels Explained
Explain FIPS 140-3 Security Levels 1 through 4, what they cover, and how to document level claims for cryptographic module validation.
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 implementation identity, operational environment, module services, and security policy evidence.
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.