Top 15 FIPS Terms You Should Know – The Full Breakdown
We recently shared our top 15 FIPS acronyms and terms to help you get familiar with the basics. Now, let’s dive deeper into what each of these means and why they matter in the FIPS 140-3 certification process.
- FIPS – Federal Information Processing Standards
FIPS are standards published by the U.S. federal government that specify security requirements for cryptographic modules. FIPS 140-3 is the current standard for validating cryptographic modules, ensuring they meet strict security and implementation guidelines for use in government and regulated industries.
- NIST – National Institute of Standards and Technology
NIST develops and maintains FIPS standards. It also oversees the Cryptographic Module Validation Program (CMVP), coordinating with testing labs and vendors to ensure modules meet FIPS 140-3 requirements.
- CMVP – Cryptographic Module Validation Program
This is the official program, jointly run by NIST and Canada’s CCCS, that validates cryptographic modules against the FIPS 140-3 standard. Vendors submit their modules to CMVP-accredited labs, which test and verify compliance before issuing certificates.
- CAVP – Cryptographic Algorithm Validation Program
Before a cryptographic module can be validated, each cryptographic algorithm it uses (such as AES, SHA, ML-KEM, ML-DSA, RSA, ED25519, KDF’s for various protocols… etc.) must be validated under CAVP. This ensures the algorithms are correctly implemented and function as intended and guarantees interoperability with any other validated module(s).
- ESV – Entropy Source Validation
Entropy Source Validation is a separate validation process that verifies the quality and reliability of the randomness source used by the cryptographic module, crucial for secure key generation and other cryptographic operations that depend on high quality entropy to guarantee certain levels of bit-strength.
- ACVP – Automated Cryptographic Validation Protocol
ACVP is the automated system that facilitates cryptographic algorithm testing within the CAVP framework. It allows machine-to-machine communication between vendors and validation servers (DEMO), and labs and validation servers (PRODUCTION) speeding up the testing process and reducing errors.
- NVLAP – National Voluntary Lab Accreditation Program
NVLAP accredits independent labs authorized to perform FIPS 140-3 testing. Only NVLAP-accredited labs can conduct the official testing required for CMVP certification.
- SP – Security Policy
The Security Policy is a detailed document that describes the cryptographic module’s security features, intended use, and operational modes. It defines how the module should be configured and used to remain compliant and in the approved mode of operation.
- UG – User Guide
The User Guide provides instructions for deploying and operating the cryptographic module securely and in compliance with FIPS requirements. It ensures end users configure and use the module correctly so it is running the FIPS 140-3 approved mode of operation.
- OE – Operational Environment
The Operational Environment refers to the specific combination of hardware (chipset), operating system, and cryptographic module configuration used during testing. Different OEs require separate validation to ensure proper validation/certification.
- Tested Configuration
The Tested Configuration specifies the exact hardware and software setup (including form factor, OS version, chipset details) that was used during testing. Users must match this configuration to maintain FIPS 140-3 validation.
- OEUP – Operational Environment Update
An OEUP is a process to add a new Operational Environment (new chipset or OS) to an existing FIPS certificate without undergoing full revalidation. This allows validated modules to support more platforms efficiently over time.
- UPDT – Module Update
A Module Update (UPDT) applies when there are security-relevant changes to the cryptographic module, such as updates to code, algorithms, or key management. It requires a new certificate and resets the module’s sunset date.
- PAA – Processor Algorithm Acceleration
Processor Algorithm Acceleration refers to hardware-assisted cryptographic acceleration features, like AES-NI or Arm Crypto Extensions, which improve performance and efficiency of cryptographic operations within validated modules.
- RBND – Rebrand
Rebranding (RBND) lets a company apply its own branding and logo to an existing FIPS 140-3 certified module, often referred to as white-labeling. This helps companies market validated products without needing to repeat the entire certification process or point to a third-party certificate for their products.
Understanding these terms is critical whether you’re developing, integrating, or managing FIPS 140-3 validated cryptographic modules. At wolfSSL, we leverage this knowledge to help customers navigate complex validation requirements and deliver secure, compliant solutions.
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now
Top 15 FIPS Terms You Should Know
Working with FIPS 140-3 can get confusing fast, especially with all the acronyms involved. To help cut through the noise, here are our top 15 FIPS-related terms:
- FIPS – Federal Information Processing Standards
- NIST – National Institute of Standards and Technology
- CMVP – Cryptographic Module Validation Program
- CAVP – Cryptographic Algorithm Validation Program
- ESV – Entropy Source Validation (separate from but complimentary to a FIPS certificate)
- ACVP – Automated Cryptographic Validation Protocol
- NVLAP – National Voluntary Lab Accreditation Program
- SP – Security Policy
- UG – User Guide
- OE – Operational Environment (Chipset + OS + Cryptographic module)
- Tested Configuration – OE description including form factor used for testing
- OEUP – Operational Environment Update (add an OE to an existing FIPS certificate)
- UPDT – Module Update (Security relevant changes to an existing FIPS module, results in a new certificate # and new sunset date)
- PAA – Processor Algorithm Acceleration (Hardware assisted cryptographic acceleration)
- RBND – Rebrand an existing FIPS certificate into your company’s own letter/logo-head for marketing purposes (often referred to as a white-label)
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now
wolfMQTT: Using wolfCrypts implementation of ML-KEM and ML-DSA
A long time ago, we added support for Kyber and Falcon in wolfMQTT. That support used an integration into liboqs for the Kyber and Falcon implementation.
Things have changed since then! Kyber is no longer Kyber, it is now ML-KEM. Falcon will soon become FN-DSA, but since then rock solid standards for ML-DSA have been released so a strong focus within the industry has been put on it. And now, wolfCrypt has its very own implementations of ML-KEM and ML-DSA.
As such, very recently, we updated our instructions for wolfMQTT to show how to do an interoperability demo against the OQS’s port of Mosquitto on top of OpenSSL3 and the OQS provider. The interoperability demo shows the Mosquitto broker and subscriber listening to the wolfMQTT publisher. Check out the the very simple and easy to follow instructions.
Please go ahead and try it out for yourself!
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now
OpenSSL Compatibility Layer Additions in wolfSSL 5.8.2
The wolfSSL’s repo pull request #8897 adds significant OpenSSL compatibility layer enhancements across four key areas: RSA operations, big number mathematics, X.509 certificate extensions, and private key serialization.
RSA API Enhancements:
The PR introduces comprehensive RSA-PSS (Probabilistic Signature Scheme) support with enhanced OpenSSL compatibility. Key additions include:
- wolfSSL_EVP_PKEY_CTX_set_rsa_pss_saltlen() for configuring salt lengths
- wolfSSL_EVP_PKEY_CTX_set_rsa_mgf1_md() for setting MGF1 hash algorithms
- wolfSSL_EVP_PKEY_CTX_set_rsa_oaep_md() for RSA-OAEP padding configuration
- The existing wolfSSL_RSA_sign and wolfSSL_RSA_verify functions have been enhanced to support RSA-PSS with custom salt lengths and MGF1 hash types.
- Additional functions include wolfSSL_RSA_padding_add_PKCS1_PSS_mgf1() and wolfSSL_RSA_verify_PKCS1_PSS_mgf1() for advanced PSS padding operations with MGF1 support.
Bignum API Additions:
A new wolfSSL_BN_ucmp() function has been added that compares the absolute values of two WOLFSSL_BIGNUM structures. This function provides OpenSSL-compatible behavior identical to BN_ucmp(). The implementation uses internal duplication to avoid modifying const input parameters, making the implementation compliant with the API.
X.509 Extensions API Additions:
Two X.509 certificate extension handling functions have been added. The wolfSSL_X509v3_get_ext_by_NID() function searches for extensions by their Numeric Identifier (NID) within a stack of extensions, supporting iterative searching with a “lastpos” parameter. The wolfSSL_X509v3_get_ext() function retrieves extensions by index position from an extension stack. Both functions enable programmatic certificate extension processing for PKI applications, policy enforcement, and extension data extraction.
Private Key DER Output API Additions:
The new wolfSSL_i2d_PrivateKey_bio() function provides private key serialization to DER format through BIO objects. This function performs a two-pass operation to determine buffer size and encode the key.
These additions collectively enhance wolfSSL’s OpenSSL compatibility layer, providing essential functionality for RSA-PSS operations, mathematical computations, certificate processing, and key management operations required by modern cryptographic applications.
If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.
Download wolfSSL Now
Live Webinar: WolfGuard: FIPS 140-3 Enabled WireGuard
WireGuard is known for its simplicity, speed, and modern cryptography, but what if your deployment requires FIPS 140-3 validated security? That’s where WolfGuard comes in.
Join wolfSSL Software Engineer Lealem Amedie as he introduces WolfGuard, a FIPS 140-3 enabled WireGuard solution optimized for speed and cryptographic agility. Built on the FIPS-certified wolfCrypt library, WolfGuard delivers all of WireGuard’s functionality with the assurance of FIPS-approved algorithms.
Register now: WolfGuard: FIPS 140-3 Enabled WireGuard
Date: August 27th | 9 AM PT
This webinar will cover:
- WireGuard fundamentals and implementations (Linux, GO, BoringTun)
- How WireGuard secures tunnels and encrypts data
- FIPS 140-3, FedRAMP, and CMMC 2.0 compliance needs
- How WolfGuard integrates FIPS into WireGuard with zero architectural changes
- Real-world use cases + live demo with WolfGuard Go
If you need WireGuard with FIPS 140-3 compliance and zero complexity trade-offs, WolfGuard is your solution.
Register now to see WolfGuard in action and achieve compliance in your VPN deployments.
As always, our webinar will include Q&A throughout. If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 425 8247.
Download wolfSSL Now
How to Make Your TPM Talk PKCS11
TPM vs HSM, what’s the difference? Check out this blog post for more detailed.
In a nutshell, TPMs are typically a dedicated chip included along side a main (host) processor and used for securing a single consumer electronics device. HSMs are external devices that can be used across multiple devices and systems, offering advanced cryptographic operations and key management. For both of them, their main objective is to protect and store private key material. A TPM typically presents itself via the standardized TPM 2.0 API while an HSM presents itself via the standardized PKCS11 API.
If you think about it really, really carefully, the difference is just a matter of form factor, interfaces, and regulatory technicalities. So is it possible for a TPM to present itself as an HSM? The answer is most definitely YES! But how?
Here at wolfSSL we have our own PKCS11 provider library, wolfPKCS11, to leverage cryptographic hardware and keystores on various systems. A while ago, we added support for using TPM 2.0 modules via wolfTPM into wolfPKCS11. We believe that this functionality is particularly useful for users that have coded to the PKCS11 standard, but need to switch to a TPM or fTPM; there are many technical and business reasons to do so.
With that in mind, if you have been using an HSM and want to simplify to simply using a TPM with little to no code changes in your application, let us help you with that. Reach out to us to find out how your specific situation would work!
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now
wolfSSL’s Newest Offering for the Financial Vertical
Are you wondering what Microsoft’s roadmap for the IIS (Internet Information Services) webserver says about post-quantum cryptography? We’re not; read on to find out why.
Not everyone in the financial industry is old enough to remember what it was like to be in the trenches during the Y2K (Year 2000) era, but those that were around for it know that it was expensive both in dollar and human terms. Many dollars and man hours were spent converting years from two digits to four digits. In the end the endeavor to fix the Y2K bug was a victim of its own success. When January 1st, 2000 rolled around, everyone was fine and the financial system just went along all honky dory.
We here at wolfSSL are hoping for the same fate for Y2Q (Years To Quantum). Hopefully, when a cryptographically relevant quantum computer is finally built, everyone will have switched over to post-quantum algorithms. To ensure this is the case, we here at wolfSSL have been hard at work getting ahead of the curve.
That said, we feel your pain. We know that you’ve been conservatively using Microsoft products. Why wouldn’t you; who doesn’t trust Microsoft? Microsoft’s approach has been to prioritize stability over agility which makes sense for now. But you also know that there are timelines to move to post-quantum cryptography. So what are your options?
At wolfSSL, we are currently working on a product that is so new that it does not even have a name!! It will act as an alternative to Microsoft Windows SChannel Library. It will hook into the windows SSPI (Security Support Provider Interface). Why is this important? Because this is how network security is provided to the Windows IIS Webserver. Without even knowing it, IIS will seamlessly become quantum-safe when you pop in wolfSSL’s alternative to SChannel!
Let us know what you think of the concept around this new product. Are you interested in seeing the timeline accelerated and the priority raised? Let us know by reaching out to facts@wolfssl.com.
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now
MCP (Model Context Protocol) and FIPS-140-3 Requirements
Are you one of our customers tasked by the US federal government to implement their newly minted AI initiatives? Then go get a cup of coffee and sit down because you are going to want to hear what we have to say about the MCP (Model Context Protocol) and how it relates to FIPS 140-3.
The Model Context Protocol (MCP) is a framework that provides AI models with relevant, structured context to improve efficiency and accuracy around how the data is used. It ensures AI agents receive pertinent data and environmental cues for optimal performance, reducing ambiguity, enhancing decision-making, and streamlining AI-environment interaction.
The protocol works on a client-server model. The servers are, generally speaking, data and service providers while the clients are the AI agents. MCP servers can provide real-time sensor data, historical archives, structured databases (CRM, ERP), knowledge bases, and external API access (weather, mapping, translation). MCP clients are AI entities, from chatbots to complex autonomous systems, needing external data/services. Examples include, LLMs, decision-making AIs and robotics/autonomous vehicles.
Here are just a few examples of servers within agencies of the US Federal Government:
The messages are formatted as JSON with some predefined fields. The important part is that these messages need to be authenticated, encrypted, and integrity checked. From the https://modelcontextprotocol.io/docs/concepts/transports:
> Always use TLS/HTTPS for production deployments
So if the US federal government is going to be contracting you to create an AI MCP client to leverage these servers, then you can bet your bottom dollar that it needs to be using FIPS 140-3 certified cryptography.
Want to learn more about our laddered-approach to FIPS 140-3 certifications and our evergreen licensing model? Send a message to fips@wolfssl.com or facts@wolfssl.com and we’ll be happy to explain it all to you!
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now
wolfSSL 5.8.2: Smarter and Cleaner Sniffing
The latest release of wolfSSL 5.8.2 comes with key improvements for users of the wolfSSL sniffer.
Multi-Session Sniffer Support
The wolfSSL sniffer now supports decoding multiple TLS sessions, including those using session tickets and session resumption.
This enables more accurate decryption of real-world TLS traffic, where connections are commonly reused for performance.
New ssl_RemoveSession() API
This release also introduces a new API for targeted sniffer session cleanup:
int ssl_RemoveSession(const char* clientIp, int clientPort,
const char* serverIp, int serverPort,
char* error);
This allows for fine-grained control of cached sessions, helping reduce memory usage which can be integral especially when operating in high traffic environments.
If you have questions about any of the above, please contact us at facts@wolfssl.com or call us at +1 425 245 8247.
Download wolfSSL Now
wolfBoot v2.6.0 Now Available
The wolfSSL team has released version 2.6.0 of wolfBoot, the lightweight and portable secure bootloader for embedded systems. This update expands platform coverage, improves support for external memory layouts, and adds key performance optimizations for a range of architectures. It also includes critical fixes and brings updated module integration across the wolfSSL ecosystem.
New Platform Support
PIC32CZ CA (Cortex-M7) and PIC32CK (Cortex-M33) devices from Microchip are now supported. The PIC32CZ family targets high-performance secure connected applications with integrated HSM and extended memory. The PIC32CK line brings TrustZone support for secure partitioning on Armv8-M systems. wolfBoot can now provide verified secure boot and firmware updates across both families.
External Flash Support with ELF Scattering
wolfBoot now supports external flash configurations when using ELF scattering mode. This enables firmware sections to be distributed between internal and external flash, useful in scenarios where internal flash is limited or where larger applications are split across multiple memory regions.
Encrypted Updates on Renesas RX
Encrypted firmware updates are now supported for the Renesas RX family. When paired with Renesas TSIP (Trusted Secure IP), wolfBoot can handle encrypted update packages, with decryption performed securely on-chip using hardware-managed keys. This provides strong protection for sensitive firmware in the field.
PowerPC 32-bit Optimizations
New assembly-level optimizations for SHA and AES are now available on 32-bit PowerPC platforms. These improvements reduce boot-time cryptographic processing overhead and improve performance during image verification and decryption operations.
STM32F4 Enhancements
wolfBoot v2.6.0 includes updated clock configuration logic for the STM32F4 series, ensuring compatibility across the full device family. In addition, support has been added for the STM32F411 variant, commonly used in development and prototyping platforms.
Fixes and Improvements
This release includes several important bug fixes:
- Fixed unaligned memory access on Cortex-A5
- Corrected compile flags to allow execution from RAM on ARM targets
- Proper handling of VTOR_NS when staging non-secure images in TrustZone-M mode
- Removed redundant flash write-after-erase cycle in wolfBoot_update_trigger
- Multiple TrustZone-related fixes for STM32H5 devices
These changes improve stability, reduce flash wear, and ensure correct behavior on secure platforms.
Updated Module Versions
The following components have been updated in this release:
- wolfSSL version 5.8.2 or later
- wolfTPM version 3.9.1 or later
- wolfPKCS11 latest revision
- wolfHSM latest revision
More Information
To download the latest version of wolfBoot, visit our download page or clone it from the wolfBoot GitHub repository. For questions about commercial support, licensing, or integration assistance, please contact us at facts@wolfssl.com or +1 425 245 8247.
Download wolfSSL Now