Check the CMVP Certificate Behind a VPN's FIPS Claim

Vendor pages that say FIPS validated are not evidence you can file. The evidence is a certificate number, a module name, a validated version and the operating conditions attached to it, and those have to match the build you deploy. The NIST CMVP FAQ is blunt about the difference between a product claiming compatibility and a module that was validated. Work the four steps below in order, and keep the record with the deployment.

Step 1: get the certificate number, not the badge

Ask the vendor for the CMVP certificate number that covers the cryptographic module in the product you intend to run. A certificate number is a specific, checkable object, while a badge is marketing. If the reply describes an algorithm instead of a module, the reply has answered a different question. Press once more for the number rather than accepting a PDF of a badge. The record behind the number is the thing an auditor can follow.

Then look that number up in the official validated-module search and read the record rather than a summary of it. The record names the vendor, the module, the validated version and the status, and it links the security policy document that describes how the module is meant to operate.

Write those five fields down, because the next step compares them with the build. A spreadsheet column is enough.

Step 2: match the module version to the build

A VPN client version and an embedded module version rarely share a number, and that is normal. What matters is whether the module version inside your build appears in the validated record. An update can change the module without changing the product name, which quietly moves the deployment outside the validated configuration.

Ask which component uses the module and how the approved mode is selected in the supported configuration. A build that can run in a non-approved mode is not the same evidence as a build configured for the approved one.

Read the local build, so the comparison uses the artifact rather than the download page. The commands below print exactly that.

openssl version -a
openssl list -providers -verbose
cat /proc/sys/crypto/fips_enabled

When the module reports a different version from the certificate, the claim has drifted and the record needs updating before anyone signs anything.

Step 3: read the operating conditions

The certificate carries conditions that describe the environment the validation covers. Those conditions can name the platform, the configuration, the key sizes allowed and the services that must be restricted. An ordinary installation that ignores them is a deployment outside the validated boundary, even when the binary is identical. That is why the security policy document matters as much as the certificate number.

Keep the vendor guidance next to the certificate, because it explains which settings select the approved mode and which ones take the product outside it.

If the conditions cannot be met in your environment, the honest statement is that this deployment sits outside the validated configuration. Naming the condition that cannot be met turns that statement into something a team can fix or accept.

Step 4: confirm the status today

The CMVP record carries a status, and the status is not permanent. NIST's FAQ describes the FIPS 140-2 transition dates in 2026, after which only FIPS 140-3 validations remain on the active list. A certificate that was active when the purchase was approved can be historical today.

Historical and revoked are different states, and each has its own meaning for procurement. Check the live record rather than a screenshot from the project folder, and note the date you checked.

Then ask the compliance or procurement owner which status their requirement accepts, because that is a policy decision rather than a technical finding. Record the answer with a date on it.

Check the record against the deployment

Compare the four collected values: the certificate number, the module version from the build, the operating conditions in force, and the current status. Any mismatch is a finding, and the finding belongs in the deployment record rather than in a slide.

Store the evidence with the build, including the date and the person who checked it. One directory per release is enough.

date -u +%FT%TZ
openssl version -a | head -3
cat /proc/sys/crypto/fips_enabled

Keep the claim inside its boundary as well. Module validation says nothing about the VPN's protocol handling, its authorization decisions or its logging policy. It is specific evidence about one defined cryptographic component, and treating it as a product score is how a compliance file ends up describing something nobody deployed.