FIPS 140-3 Implementation Guidance: What Changed in NIST’s August 2026 Update

NIST released an updated FIPS 140-3 Implementation Guidance on August 19, 2026.

The most significant change is the addition of IG 1.B, Clarifications on the Definition and Requirements of Hybrid Modules. NIST also revised IG 2.3.C, Processor Algorithm Accelerators (PAA) and Processor Algorithm Implementations (PAI).

The new hybrid guidance is the more important architectural development. It gives vendors and laboratories a clearer framework for validating cryptographic modules whose security boundary spans software or firmware and hardware components, including components that may exist within the same processor or System-on-Chip.

For cryptographic library implementers, this is increasingly relevant as software interacts with processor instructions, cryptographic engines, accelerators, and other specialized hardware.

IG 1.B: A Clearer Model for Hybrid Cryptographic Modules

FIPS 140-3 defines hybrid modules as modules containing disjoint software or firmware and hardware components.

IG 1.B clarifies how that definition should be applied to modern system architectures.

One of the most important points is that module type and physical embodiment are independent concepts.

A hybrid software or hybrid firmware module can exist entirely within a single-chip embodiment.

That means a modern SoC may contain general-purpose CPU cores, memory, cryptographic engines, internal buses, and security processors within a single package, while the actual FIPS cryptographic boundary includes only selected components.

The physical chip boundary and the cryptographic module boundary do not have to be the same.

Defining the Hybrid Boundary

The new guidance requires the vendor to identify the disjoint components that make up the hybrid module.

The Security Policy must clearly describe:

  • the software, firmware, and hardware components within the module;
  • the physical ports and logical interfaces exposed by those components;
  • which components communicate with one another;
  • the surrounding Operational Environment; and
  • the cryptographic boundary around the combined module.

For sub-chip hardware components, vendors must provide enough technical evidence to establish the component and its boundary.

This moves hybrid-module validation beyond simply labeling a design as “software plus hardware.” The vendor must demonstrate exactly where the cryptographic module begins and ends.

Communications Between Components Matter

Once the module spans multiple components, the communication paths between those components become part of the security analysis.

This is especially important when Sensitive Security Parameters (SSPs) such as cryptographic keys cross component boundaries.

For example, a software component may pass keys or intermediate values to a cryptographic engine elsewhere on the SoC. Those values may travel through buses, memory, or other functional components before reaching their destination.

IG 1.B requires the module developer to identify those paths and determine whether the communications satisfy the applicable controlled-communication requirements.

If they do not, the normal FIPS 140-3 SSP entry and output requirements apply.

The practical engineering question becomes:

What happens to sensitive data while it moves between the disjoint components of the module?

The Hybrid Module Is One Security Object

Although a hybrid module contains multiple components, the validation applies to the module as a whole.

If a required self-test fails in one component, the entire module must enter an error state.

The finite-state model must describe the behavior of the combined implementation. Zeroization must account for SSPs stored across all components within the cryptographic boundary. Software and firmware integrity requirements must also be applied based on where the code is stored and how it is loaded.

The components may be physically or logically disjoint, but they collectively form one FIPS cryptographic module.

Why This Matters for Modern Cryptographic Libraries

Cryptographic implementations are becoming increasingly heterogeneous.

A software library may rely on:

  • general-purpose CPU instructions;
  • vector extensions;
  • dedicated cryptographic engines;
  • embedded security processors;
  • accelerator hardware; or
  • future hardware implementations of post-quantum algorithms.

For OpenSSL-based implementations in particular, the useful questions are no longer simply whether an algorithm is implemented in software.

Instead:

Where is the cryptographic function executed?

Which components are inside the FIPS boundary?

How do those components communicate?

Where do keys and other SSPs exist?

Which component is responsible for each FIPS requirement?

IG 1.B gives module designers and laboratories a clearer framework for answering those questions.

PAA/PAI Does Not Automatically Mean Hybrid

The August update also revises IG 2.3.C, which covers Processor Algorithm Accelerators and Processor Algorithm Implementations.

A PAA accelerates part of an algorithm without implementing the entire cryptographic function.

A PAI implements the complete algorithm in processor hardware.

Using either one does not automatically make a module hybrid.

A software module that contains a complete software implementation and optionally uses processor acceleration can remain a software module, assuming the other applicable requirements are satisfied.

If the software or firmware cannot provide the cryptographic function without the hardware component, however, the architecture may need to be treated as hybrid.

That distinction should be made during module design because it affects the cryptographic boundary, testing strategy, Security Policy, and porting options.

What Changed in IG 2.3.C

The August revision to IG 2.3.C is comparatively narrow.

For a new submission, a claimed PAA or PAI must be a known implementation recognized by CMVP, or it must first go through the process for adding a new PAA/PAI.

The validation documentation must also identify the processor's:

  • part number or version;
  • family; and
  • microarchitecture.

NIST also expanded the known-PAA list to include additional processor implementations.

The underlying testing model remains important:

Every certificate-listed Operational Environment that supports a PAA or PAI must be tested with that PAA or PAI enabled.

Similar-OE treatment may reduce redundant testing of an identical software-only implementation, but it does not eliminate testing of the accelerated path.

A Short Arm Example

Consider an OpenSSL FIPS Provider with generic AES and an optimized AES implementation using Arm Cryptographic Extensions.

If the original validation only exercised generic AES on x86, the vendor cannot later use the Management Manual porting rules and a VAOE submission to introduce the Arm-accelerated implementation. There is no tested Arm PAA execution path in the validation benchmark from which to make the porting claim.

If an Arm OE with Cryptographic Extensions was exercised during validation, a later qualifying port to another compatible Arm environment can then be evaluated under the Management Manual's porting rules.

That is the important boundary: porting carries validated behavior forward; it does not establish a new implementation path.

The Management Manual Still Governs Porting

This distinction is reinforced by the April 2026 FIPS 140-3 Management Manual.

The Management Manual defines the rules for post-validation porting and vendor affirmation, including VAOE.

For qualifying Level 1 software modules, a vendor may port or recompile a module to another compatible general-purpose environment when the applicable conditions are satisfied and the port does not require source-code modifications.

Firmware and hybrid modules have additional restrictions.

The Management Manual also makes clear that a vendor-affirmed OE is not equivalent to an OE tested by the laboratory and listed on the validation certificate.

That produces a useful separation:

IG 2.3.C
    |
    +--> What processor-specific implementations must be tested?

Management Manual
    |
    +--> When may already-validated behavior be ported?

The August revision to 2.3.C reinforces that separation by directing hybrid-module porting questions back to the Management Manual.

Why This Matters for OpenSSL

OpenSSL is highly processor-aware. Runtime capability detection can select generic implementations, AES-NI, SHA extensions, Arm Cryptography Extensions, and other optimized paths behind the same high-level API.

For a FIPS validation, those implementation choices are not merely performance details. They affect which cryptographic execution paths exist and which must be represented in the test strategy.

A useful validation model therefore includes more than an operating-system list:

                  OpenSSL FIPS Module
                         |
             +-----------+-----------+
             |                       |
         Software                 Accelerated
           path                      paths
             |                       |
      binary / compiler       processor family
      OS compatibility        microarchitecture
                              PAA/PAI capability

The validation strategy asks which paths must be tested. The porting strategy asks whether already-validated behavior can later execute on another compatible environment.

Keeping those questions separate makes both the implementation and certification strategy easier to reason about.

Engineering Takeaway

The most important part of NIST's August 2026 update is the new hybrid-module guidance.

IG 1.B gives cryptographic module developers a clearer way to define and validate architectures where software, firmware, and hardware collectively implement the cryptographic boundary—even when those components exist inside a single physical chip.

For modern cryptographic libraries, hardware dependencies therefore need to be considered as part of the FIPS architecture rather than simply as performance optimizations.

The 2.3.C changes are narrower but still important: processor implementations must be recognized, processor identity must be documented, and accelerated execution paths remain subject to processor-specific testing.

When the module later moves to another Operational Environment, the separation is straightforward:

Validation testing establishes the cryptographic behavior. The Management Manual governs how qualifying validated behavior may subsequently be ported or vendor affirmed.

As software and hardware cryptography become increasingly intertwined, defining those boundaries early makes both the implementation and the validation strategy easier to manage.

References

  1. NIST, Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program, August 19, 2026.

https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf

  1. NIST CMVP, FIPS 140-3 IG and RFG Announcements, August 19, 2026.

https://csrc.nist.gov/projects/cryptographic-module-validation-program/fips-140-3-ig-announcements

  1. NIST, FIPS 140-3 CMVP Management Manual, April 9, 2026.

https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS-140-3-CMVP%20Management%20Manual.pdf