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 assurance levels we support
You set the minimum authenticator standard in the console, and Lavawall grades every key against a registry we maintain and can show an auditor, checked against the NIST CMVP list rather than taken from vendor marketing. There are three levels to choose from.
FIPS 140-3 Recommended
A current NIST CMVP certificate covers the key, the validated boundary includes the FIDO2 function, and the vendor publishes an AAGUID specific to the FIPS variant. Today that is the Yubico YubiKey 5 FIPS Series, under CMVP certificate 5291 (active, valid to 2031).
- YubiKey 5C FIPS, 5 Nano FIPS, and 5C Nano FIPS
- YubiKey 5 NFC FIPS and 5C NFC FIPS
- YubiKey 5Ci FIPS (Lightning)
The same keys sold under Yubico’s Enterprise Profile map to certificate 5291 by firmware version (5.7.4); we confirm those against a physical unit before relying on them in an audit. This is the level to specify for new work.
FIPS 140-2 Historical
The older YubiKey 5 FIPS Series on firmware 5.4.x, including the NFC and 5Ci models, is validated under CMVP certificates 3907 and 3914. Lavawall accepts these at the “140-2 or better” setting and shows their historical status rather than pretending it is a live validation.
NIST moves FIPS 140-2 validations to its historical list on 21 September 2026, so treat this level as a bridge for keys already in the field, not a destination for new deployments.
Attested hardware key No FIPS claim
Any security key that presents a verifiable attestation grades here: real, phishing-resistant hardware, but with no NIST CMVP certificate behind it, so it makes no FIPS claim. Choose this level when you want to require a hardware key without the FIPS requirement.
Registry maintained by ThreeShield and last reviewed August 2026; each certificate links to the CMVP so you can check it yourself.
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.
The Lavawall Viewer for Windows
The third path is a native Windows program the technician starts from the console. Its cryptography runs in the Go Cryptographic Module v1.0.0, NIST CMVP Certificate #5247, the same validated module that protects the remote session at the computer being supported. Where the browser viewer uses the browser’s own cryptography at the technician’s end, the Windows viewer uses the validated module at both ends. It is FIPS 140-3 only, and it is meant for organizations that require that.
The certificate covers the module, not everything around it. Windows, the Windows key store, the TPM, the code-signing that protects the program, the system browser used to sign in, and the passkey you sign in with all sit outside the module. The passkey has its own certification, if any; for a security key that is the certificate shown in the levels above.
Assessors can start with the Lavawall Viewer security and validation overview. To set it up, see the Lavawall Viewer.
Checking a computer’s TPM against NIST’s list
Some programs ask whether the technician’s computer has a TPM that appears on NIST’s validated-modules list. On Windows computers, Lavawall reads the TPM’s make and firmware and compares them against a listing of TPM modules that appear on NIST’s FIPS 140-3 list and, separately, its FIPS 140-2 list. The result is shown in the device’s hardware details, and a match is flagged.
Three limits apply. The check is an informational match against a published listing, and your agency must confirm the firmware against the certificate itself. A TPM match is not a certification of Lavawall or of the device. And the technician key is protected by the Windows key store today, which is outside the validated module; Lavawall does not claim the viewer keeps its keys in the TPM.
FIPS 140-2 listings are shown apart from FIPS 140-3 ones because NIST moved 140-2 validations to its historical list on 21 September 2026.
FIPS 140-3 inside Lavawall’s own services
The login keys and the remote-desktop transit are not the only places the standard applies. When an account requires FIPS 140-3, Lavawall runs its own cryptography on FIPS-approved algorithms, and where an algorithm is not on the approved list it uses the approved one for that account rather than calling the other one compliant.
| Service | In FIPS 140-3 mode |
|---|---|
| Password hashing | Accounts that do not require FIPS 140-3 hash passwords with Argon2id, the memory-hard modern default. Argon2 is not on the FIPS-approved list, so an account that requires FIPS 140-3 steps down to PBKDF2-HMAC-SHA-256 at 600,000 iterations or more, which is approved and meets current OWASP guidance. |
| Password vault | Every item is encrypted, secrets and URLs alike, with AES-256-GCM under keys wrapped to each member, so the vault runs entirely on FIPS-approved cryptography. |
| Remote support | The remote desktop session in transit is carried through a FIPS 140-3 validated cryptographic module, NIST CMVP Certificate #5247. |
| Lavawall Viewer for Windows | Runs its cryptography in the same validated module on the technician’s computer. Windows, the Windows key store, the TPM and the sign-in passkey are outside the module. |
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. The Lavawall Viewer for Windows runs that module on the technician’s computer too. |
| 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.
FIPS 140-3, compared with an appliance vendor
Appliance-based remote-access vendors carry a FIPS story too, and BeyondTrust Secure Remote Access is the one that comes up most. Here is where the detail an assessor checks differs. Lavawall cites a current FIPS 140-3 certificate for each named component and needs no appliance; BeyondTrust’s own validated module is an appliance-bound FIPS 140-2 certificate that NIST has moved to its historical list, and its FIPS 140-3 statement names compliant OpenSSL without a certificate number.
| Lavawall® | BeyondTrust Secure Remote Access | |
|---|---|---|
| Session cryptographic module | Go Cryptographic Module v1.0.0, certificate #5247, FIPS 140-3, current | “FIPS compliant-OpenSSL” 3.1, with no certificate number given |
| Own CMVP certificate | None; Lavawall is not itself a cryptographic module, so it runs on validated modules rather than claiming to be one | Certificate #3881, FIPS 140-2, validated 3 April 2021, now on NIST’s historical list, which NIST says “should not be included by Federal Agencies in new procurements” |
| What the FIPS statement covers | Each component named separately, with its own certificate | The B Series appliance; the client software and the browser are not addressed |
| Browser viewer | Uses FIPS-approved algorithms through the browser’s own cryptography; we do not claim the browser is a module of ours | Not addressed |
| Native Windows viewer | Runs its cryptography in the same validated module, certificate #5247, FIPS 140-3 | Client software is not addressed in its published FIPS statement |
| Appliance to buy and run | None; Lavawall runs in the browser and deploys in minutes | A B Series appliance, hardware or virtual, to license, host, and keep patched |
Sources: NIST CMVP certificate #3881 and BeyondTrust’s FIPS 140-3 compliance statement, as published, accessed September 2026. Confirm the current status before you rely on it.
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. Three paths run through FIPS 140-3 validated modules: the security keys people sign in with, the remote desktop sessions Lavawall carries under Certificate #5247, and the Lavawall Viewer for Windows, which runs that same module on the technician’s computer. A TPM listing match is information, not a validation of Lavawall. Beyond those paths, 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?
- Three 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. The third is the Lavawall Viewer for Windows, a native program whose cryptography runs in that same module on the technician's computer. Beyond those three 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. The remote sessions Lavawall carries, including those in the Lavawall Viewer for Windows, run through the validated module under Certificate #5247, and whether your overall deployment meets SC-13 is for your agency to determine.
- 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.
- Is the Lavawall Viewer for Windows FIPS 140-3 only?
- Yes. The Windows viewer runs its cryptography only in the validated module, NIST CMVP Certificate #5247, and is meant for organizations that require it. Windows, the Windows key store, the TPM and the passkey you sign in with are outside that module. A session viewed in a web browser uses the browser’s own cryptography, which is not a validated module.
- Does Lavawall check a computer’s TPM against NIST’s list?
- On Windows computers, yes, as information. Lavawall reads the TPM’s make and firmware, compares them with a listing of TPM modules that appear on NIST’s FIPS 140-3 and FIPS 140-2 validated-modules lists, and shows the result in the device’s hardware details. A match is informational. Your agency must confirm the firmware against the certificate, and a match is not a certification of Lavawall or of the device.