- 01FIPS 140-3 has been the target since September 2020. New 140-2 validations stopped April 2022; existing 140-2 validations move to historical five years post-cert. If you ship into federal, healthcare, or banking, the migration is overdue.
- 02Validation tests module specification, interfaces, role-based authentication, self-tests, and lifecycle assurance — not just algorithm correctness.
- 03Levels 1–4 increase from algorithm correctness to full physical tamper resistance. Most software targets Level 1; HSMs target 3–4. Targeting above your real assurance need wastes engineering time.
- 04Standardize on a small set of validated modules (one OS-level, one HSM, one application-level), centralize the choice in a platform team, and let product teams consume rather than choose.
FIPS 140-3, the federal standard for cryptographic modules, has been the target standard since September 2020. New 140-2 validations stopped in April 2022, and existing 140-2 validations move to the historical list five years after their final certification date.
If your product, service, or pipeline relies on a cryptographic module that is not on the active 140-3 validated module list, you have a procurement problem and a contracts problem.
What validation actually tests
- 01Module specification — boundary, modes, supported algorithms
- 02Cryptographic module interfaces — control of inputs, outputs, error states
- 03Roles, services, authentication — separation of crypto officer and user
- 04Self-tests — power-up and conditional tests for algorithms and integrity
- 05Lifecycle assurance — secure delivery, configuration, end-of-life
The four security levels
Levels 1 through 4 increase from basic algorithm correctness to full physical tamper resistance. Most software products target Level 1; HSMs and high-assurance hardware target Levels 3 and 4. Choosing a level above your real assurance need wastes money and engineering time.
Sourcing 140-3 modules without slowing engineering
Standardize on a small number of validated modules — typically one for OS-level (e.g., the platform's validated cryptographic library), one for HSM operations, one for application-level (e.g., a validated build of OpenSSL or BoringCrypto). Centralize the module choice in a shared platform team, and let product teams consume rather than choose.