Readiness is not validation
FIPS validation exists only as a CMVP laboratory certificate for a specific cryptographic module — no scanner or vendor can grant it, including this one. Scanning establishes readiness: proof that your code, endpoints, and dependencies use approved algorithms, so validated modules can slot in without a rewrite.
The seven-step path
1.Work out whether FIPS applies to you
FIPS 140-3 requirements arrive through your customers and contracts, not your own preference: federal agencies, FedRAMP authorization, CMMC / NIST 800-171 (defense supply chain — control 3.13.11 requires FIPS-validated cryptography to protect CUI), and increasingly the security questionnaires of large healthcare and financial partners. If none of those are in your pipeline, standard modern crypto (TLS 1.3, AES-GCM, SHA-256) already serves you well and you can stop here.
2.Understand readiness versus validation — they are not the same thing
FIPS validation is a certification of a specific cryptographic module (an exact build, on an exact platform) issued through NIST's Cryptographic Module Validation Program after laboratory testing. No scanner, vendor, or self-assessment can make you "FIPS validated." What you can do today is establish readiness: prove your code, TLS endpoints, and dependencies use FIPS-approved algorithms and parameters, so that adopting validated modules later is a swap, not a rewrite.
3.Find non-approved algorithms in your code
The classics show up in almost every codebase that predates a FIPS conversation: MD5 or SHA-1 used for security purposes (password hashing, signatures, HMACs), DES/3DES/RC4/Blowfish encryption, AES in ECB mode, and RSA keys under 2048 bits. NIST SP 800-131A disallows all of these. Scan for them line-by-line and disposition the false friends — MD5 as a cache key or ETag is not a security use and can be accepted with a note.
4.Check your TLS posture against approved parameters
A FIPS-mode deployment requires TLS 1.2+ negotiating approved suites — AES-GCM (or CBC) with approved key exchange. Servers that still accept TLS 1.0/1.1, or that negotiate 3DES or RC4 when offered them, fail that bar; so does preferring ChaCha20-Poly1305 (an excellent cipher that simply is not FIPS-approved). Probe what your endpoints actually negotiate, not what your config file says.
5.Audit your crypto libraries for CMVP-validated builds
Popular libraries — crypto-js, node-forge, PyCryptodome, libsodium, Go's x/crypto — are fine engineering but have no CMVP-validated builds. Others can be validated in the right configuration: PyCA cryptography against a FIPS-validated OpenSSL provider, Go with its FIPS-140 mode, node with a validated OpenSSL. Inventory what your manifests pull in and check each against the NIST CMVP validated-modules list.
6.Plan the migration in severity order
Replace encryption first (DES/3DES/RC4 → AES-GCM; ECB → GCM), then key sizes (RSA ≥ 2048 or ECDSA P-256/P-384), then hashes (MD5/SHA-1 → SHA-256/SHA-384 for security uses; passwords → PBKDF2-HMAC-SHA-256). Most migrations are mechanical; the painful ones are stored data encrypted under an old cipher — plan a re-encryption pass, not a big-bang cutover.
7.Keep the evidence continuously, not once
A one-off audit decays the day someone merges a new dependency. Wire the same checks into continuous scanning so every repo scan and web scan re-verifies the crypto posture and maps each finding to FIPS 140-3 / NIST 800-171 3.13.11 control language — the evidence format assessors and primes actually ask for.
Approved vs non-approved, at a glance
| Use | Not approved | Approved target |
|---|---|---|
| Symmetric encryption | DES, 3DES, RC4, Blowfish, AES-ECB | AES-128/256-GCM (FIPS 197 + SP 800-38D) |
| Hashing (security) | MD5, SHA-1 | SHA-256 / SHA-384 (FIPS 180-4), SHA-3 (FIPS 202) |
| Password storage | MD5, SHA-1, bcrypt* | PBKDF2-HMAC-SHA-256 (SP 800-132) |
| Asymmetric keys | RSA < 2048 bits | RSA ≥ 2048, ECDSA P-256 / P-384 |
| TLS | TLS 1.0/1.1, 3DES/RC4 suites, ChaCha20* | TLS 1.2+ with AES-GCM suites (SP 800-52r2) |
| Post-quantum | — | ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205) |
* bcrypt and ChaCha20-Poly1305 are respected, secure algorithms — they simply are not on the FIPS-approved list, which matters only in FIPS-mode deployments.
How KollGuard does this
KollGuard's scanners include a FIPS-readiness rule pack: code scans flag non-approved algorithms (MD5/SHA-1, DES/3DES/RC4, ECB mode, RSA under 2048 bits), web scans probe what your TLS endpoints actually negotiate, and repo scans include a CMVP advisory on crypto libraries without validated builds. Findings group under a FIPS 140-3 bucket with NIST 800-171 3.13.11 citations — continuous readiness evidence, clearly labeled as readiness, never as validation.
Frequently asked
- What is FIPS 140-3?
- FIPS 140-3 is the U.S. government standard for cryptographic modules. It defines security requirements for the hardware/software that performs encryption, and modules are certified against it through NIST's Cryptographic Module Validation Program (CMVP). Federal agencies — and programs that inherit federal requirements, like FedRAMP and CMMC — must use FIPS-validated cryptography to protect sensitive data.
- What is the difference between FIPS readiness and FIPS validation?
- Validation is a formal CMVP laboratory certification of a specific module build on a specific platform. Readiness means your code, TLS configuration, and dependencies already use FIPS-approved algorithms and parameters, so moving onto validated modules is feasible. A scanner can evidence readiness; only a CMVP lab can grant validation.
- Can a scan make my product FIPS compliant?
- No — and be wary of anything that implies it can. No scan, tool, or vendor attestation confers FIPS validation; that exists only as a CMVP certificate for a specific cryptographic module. What scanning does is find the non-approved crypto that would block you, and produce the readiness evidence assessors ask for.
- Who actually needs FIPS 140-3?
- Teams selling to U.S. federal agencies, pursuing FedRAMP, in the defense supply chain under CMMC / NIST 800-171 (3.13.11 requires FIPS-validated cryptography for CUI), and vendors whose enterprise customers pass those requirements down contractually. Outside those paths, modern crypto best practice (TLS 1.3, AES-GCM, SHA-256) is the right target instead.
- Which algorithms are not FIPS-approved?
- Commonly encountered non-approved algorithms include MD5 and SHA-1 for security uses, DES, 3DES (disallowed since 2023 per SP 800-131A), RC4, Blowfish, ChaCha20-Poly1305, the bcrypt password-hashing algorithm, and RSA keys under 2048 bits. ECB mode is not an approved way to encrypt data even though AES itself is approved.
- Does KollGuard check FIPS readiness?
- Yes. KollGuard's code scanner flags non-approved algorithms (MD5/SHA-1, DES/3DES/RC4, ECB mode, small RSA keys), the web scanner probes TLS endpoints for non-approved protocol versions and cipher suites, and repo scans include an advisory on crypto libraries without CMVP-validated builds — each finding mapped to FIPS 140-3 / NIST 800-171 3.13.11 control language. KollGuard reports readiness evidence; it does not and cannot issue FIPS validation.