Some organizations are required to use FIPS 140-3 validated authenticators for advanced authentication: a security key or passkey whose cryptographic module has passed testing under the NIST Cryptographic Module Validation Program. Knowing that a user has such a key is easy to assert and hard to prove. Lavawall® proves it, at registration and again at every login, and can refuse anything that does not meet the bar.
What FIPS 140-3 is, and the date on the calendar
FIPS 140-3 is the current US federal standard for cryptographic modules, published by NIST and based on the international standard ISO/IEC 19790. A certificate covers the module that performs the cryptography, for a security key, the chip inside it, not the application it signs into. On 21 September 2026, NIST moves every FIPS 140-2 validation to its historical list, so a program still resting on 140-2 hardware is on borrowed time and new procurements should specify FIPS 140-3.
How the enforcement works
In the console you set the minimum authenticator standard to FIPS 140-3 validated. From then on, every passkey or security key is checked against the maintained list of NIST CMVP validated authenticators.
| Step | What happens |
|---|---|
| Checked at registration | When a key is enrolled, its attestation is read and matched to a current CMVP FIPS 140-3 certificate, for example the YubiKey 5 FIPS Series under certificate 5291, valid to 2031. A model with no such certificate is not accepted at this level. |
| Re-checked at every login | The standard is enforced on each sign-in, not just once, so a key cannot slip below the bar unnoticed. |
| A PIN or biometric is required | User verification is required, which on most keys is what puts the device into its FIPS-approved mode. |
| Report-only first | Run the control in report-only mode to see which users would be blocked, issue compliant keys, then turn on enforcement once everyone is covered. |
The authenticators we accept at FIPS 140-3
At the FIPS 140-3 setting, Lavawall accepts a key only when a current NIST CMVP certificate covers it, the validated boundary includes the FIDO2 function, and the vendor publishes an AAGUID specific to the FIPS variant so a validated unit is distinguishable from an ordinary one over WebAuthn. Today that is the Yubico YubiKey 5 FIPS Series. We keep the determination in a registry we maintain and can show an auditor, checked against the CMVP list rather than taken from vendor marketing.
| Vendor | Model | Assurance | CMVP certificate |
|---|---|---|---|
| Yubico | YubiKey 5 FIPS Series (5C FIPS, 5 Nano FIPS, 5C Nano FIPS) | FIPS 140-3 | 5291, active, valid to 2031 |
| YubiKey 5 FIPS Series with NFC (5 NFC FIPS, 5C NFC FIPS) | FIPS 140-3 | 5291, active, valid to 2031 | |
| YubiKey 5Ci FIPS (Lightning) | FIPS 140-3 | 5291, active, valid to 2031 | |
| Yubico | YubiKey 5 FIPS Series, firmware 5.4.x (including the NFC and 5Ci models) | FIPS 140-2 | 3907 / 3914, historical |
The same keys sold under Yubico’s Enterprise Profile map to certificate 5291 by firmware version; we confirm those against a physical unit before relying on them in an audit. The firmware 5.4.x keys are validated under FIPS 140-2, which NIST moves to its historical list on 21 September 2026, so new deployments should use the FIPS 140-3 models above. Below the FIPS setting, Lavawall can also require a merely attested hardware key, but that carries no FIPS claim. List current as of our last validation review, August 2026; each row links to its CMVP certificate so you can check it.
Remote desktop, protected by a validated module
There is one place Lavawall itself carries information that may include criminal justice data: a remote desktop session into a machine that displays it. That traffic is protected in transit by a FIPS 140-3 validated cryptographic module, NIST CMVP Certificate #5247. For the remote-access path that CJIS is most concerned with, the cryptography is validated, not merely strong, and the certificate number is there for your assessor to check.
This is separate from the login control above. One enforces the FIPS 140-3 status of the hardware people sign in with; the other validates the cryptography protecting a remote session while it is open.
What FIPS 140-3 asks of your RMM, patching, and GRC tools
When a framework points you at FIPS 140-3, it lands on the everyday tools that reach into your machines: the RMM and remote support that log in and take control, the patching that pushes changes, and the GRC platform that has to prove all of it. Four things separate a tool that can stand behind that requirement from one that cannot.
| What the requirement pushes toward | What Lavawall does |
|---|---|
| Sign-in on validated hardware | Lavawall can require that every login, for RMM, patching, and GRC alike, use a FIPS 140-3 validated security key such as the YubiKey 5 FIPS Series (certificate 5291), checked against the NIST CMVP list at registration and again at every sign-in. Run it in report-only first, then enforce. |
| Keys and secrets kept encrypted | Credentials and secrets are stored encrypted, and access to them is logged, so the material that lets a tool into your environment is not sitting in the clear. |
| Protected in transit, by a validated module | The remote desktop sessions Lavawall carries are encrypted in transit through a FIPS 140-3 validated cryptographic module, NIST CMVP Certificate #5247, not merely a strong cipher an auditor has to take on faith. |
| Evidence an assessor accepts | Because patching, remote support, access reviews, and GRC run in one console, the record that the FIPS 140-3 login control was on, and who signed in with which key, is exportable evidence rather than a screenshot hunt. |
Now ask the tools you run today. Can your RMM refuse a login that is not on a FIPS 140-3 validated key? Can your remote-support tool point to a certificate number for the cryptography protecting the session, or only tell you it is “encrypted”? Can your GRC platform hand an assessor the evidence without a manual scramble? If the answer is no on all three, that is the gap this closes.
What this is, and what it is not
It is an authentication control. It enforces the FIPS 140-3 status of the hardware your people sign in with, and gives an auditor evidence that every login uses a validated key. Where FIPS 140-3 validated authenticators are required, under CJIS advanced authentication and in high-assurance environments generally, this is the control that proves it.
It is not a claim that everything else is FIPS-validated. Two paths run through FIPS 140-3 validated modules: the security keys people sign in with, and the remote desktop sessions Lavawall carries, under Certificate #5247. Beyond those, Lavawall does not represent that all of its own data cryptography, or your wider environment, runs through validated modules. CJIS control SC-13 also covers criminal justice information moving across your own infrastructure, which is a property of that infrastructure and the agency's to validate. We would rather tell you exactly where the line sits than blur it.
Frequently asked
- What does Lavawall actually do for FIPS 140-3?
- Two things. It enforces the authenticators: the console can require that every passkey or security key used to sign in be a FIPS 140-3 validated model, verified against the NIST CMVP certificate list by the key's attestation. And the remote desktop sessions Lavawall carries are protected in transit by a FIPS 140-3 validated module, NIST CMVP Certificate #5247. Beyond those two paths, it is not a claim that all of Lavawall's data cryptography, or your wider environment, is FIPS 140-3 validated.
- Does this satisfy the CJIS SC-13 encryption requirement?
- No, and no login control does. CJIS control SC-13 is about criminal justice information in transit being protected by FIPS 140-3 validated cryptographic modules, which is a property of the infrastructure carrying the data. What Lavawall covers is the separate requirement to use FIPS 140-3 validated authenticators for advanced authentication.
- Which keys qualify, and what happens on 21 September 2026?
- Models covered by a current NIST CMVP FIPS 140-3 certificate qualify, for example the YubiKey 5 FIPS Series under certificate 5291, valid to 2031. A PIN or biometric must be set, which is what puts most keys into their FIPS-approved mode. On 21 September 2026 NIST moves FIPS 140-2 validations to its historical list, so new work should be on FIPS 140-3 validated hardware.
- Why aren’t Hirsch, Identiv, uTrust, or other “FIPS” keys listed?
- Because at the FIPS 140-3 level Lavawall accepts only NIST CMVP-validated hardware, and those vendors were not CMVP-validated for the FIDO2 function, with a FIPS-specific AAGUID we can verify, as of our last validation check. A key can be marketed as “FIPS” on the strength of a certified chip, a FIDO Alliance certification level, or the use of FIPS-approved algorithms, and none of those is a NIST CMVP certificate covering the authenticator itself. When a vendor earns a qualifying certificate, we add it after confirming it against a physical key.