
September 12, 2026
12 min read
By Kokil Thapa | Last reviewed: September 2026
Federal procurement, healthcare, finance, and legal-tech platforms increasingly ask whether their stack meets cryptographic standards. FIPS 140-2 vs 140-3 Explained is the reference point for that question. FIPS 140-2 governed validated crypto modules for decades. FIPS 140-3 replaced it in 2019 and tightened how modules are tested. If you build REST APIs, payment integrations, or client portals that store sensitive documents, you need to know what each standard requires and what your hosting provider actually validates.
What is FIPS 140-2 and why does it matter for web applications?
FIPS 140-2 is a U.S. federal standard for cryptographic modules. It defines four Security Levels (SL1–SL4). Each level adds physical tamper evidence, role-based authentication, or stronger boundary protection. A module is not “FIPS compliant” because you enabled a setting. It must pass testing by an accredited lab and appear on the NIST Cryptographic Module Validation Program (CMVP) list.
For web developers, the practical impact sits one layer below your Laravel controllers. Your application calls OpenSSL, Java JCE, AWS KMS, or HSM firmware. Those are the modules buyers ask about. A law-firm portal I built for document upload and client login does not implement AES itself. It relies on TLS termination, disk encryption, and password hashing libraries that must use validated primitives when the contract demands FIPS mode.
Common triggers include U.S. federal contracts, FedRAMP-adjacent workloads, HIPAA environments that reference FIPS, and payment processors that require validated crypto for key storage. Nepal-based projects rarely cite FIPS in local tenders. International SaaS clients, remittance APIs, and banks with correspondent relationships often do.
Security Levels at a glance
SL1 requires production-grade algorithms and self-tests. No physical tamper requirements. SL2 adds role-based authentication and tamper-evident seals. SL3 demands identity-based authentication and physical tamper response. SL4 adds environmental failure protection. Most cloud HSM and managed KMS offerings target SL1 or SL2 in software or hybrid form factors.
What changed in FIPS 140-3 compared to FIPS 140-2?
FIPS 140-3 became effective in March 2019. It superseded FIPS 140-2 for new validations. Existing FIPS 140-2 certificates remain on the CMVP module list until they sunset. NIST publishes transition guidance; check current sunset dates before you assume a legacy certificate covers a new deployment.
The headline change is alignment with ISO/IEC 19790:2012 and ISO/IEC 24759. Test labs apply a unified international framework. That reduces ambiguity but also closes loopholes vendors exploited under the older Implementation Guidance notes.
FIPS 140-3 tightens entropy source requirements. Random number generation must meet stricter health tests. Key management adds explicit zeroisation rules. Software/firmware integrity checks are more demanding. Algorithm policy also moves forward. Legacy options like SHA-1 for digital signatures and Triple-DES for encryption face stronger restrictions in new validations.
Side-by-side comparison
| Criteria | FIPS 140-2 | FIPS 140-3 |
|---|---|---|
| Status for new validations | Legacy; no new submissions | Current standard since 2019 |
| Test basis | FIPS 140-2 + IG notes | ISO/IEC 19790:2012 aligned |
| Entropy / DRBG | Defined; IG clarified gaps | Stricter health tests and documentation |
| Software integrity | Basic verification | Stronger integrity and loading checks |
| Weak algorithms in new certs | Legacy modules may still list TDES | New validations restrict deprecated primitives |
| Security Levels | SL1–SL4 | SL1–SL4 (same conceptual model) |
| Typical cloud use | Older HSM/KMS certificates | AWS-LC FIPS, Azure, GCP FIPS modules |
The table is the core of FIPS 140-2 vs 140-3 Explained for procurement teams. Same security level labels do not mean identical test depth. A SL2 module validated under 140-3 went through different entropy and integrity scrutiny than a 140-2 SL2 module from 2014.
How do you choose between FIPS 140-2 and FIPS 140-3 validation for a project?
Short answer: you rarely choose the standard yourself. You choose a platform whose module certificate matches your contract language. If the RFP says “FIPS 140-2 or later,” a current 140-3 validation satisfies it. If it lists a specific certificate number, verify that exact module, operating environment, and version.
On greenfield work in 2026, prefer infrastructure with active FIPS 140-3 certificates. AWS, Azure, and Google Cloud publish FIPS endpoints and module details. Match region, service, and firmware version to the CMVP entry. A common mistake is enabling “FIPS mode” on a VM while the hypervisor or host OS module is not in scope.
- Extract the exact FIPS requirement from the contract or security questionnaire.
- Identify the cryptographic module boundary (OpenSSL FIPS provider, cloud KMS, HSM, load balancer).
- Look up the certificate on the CMVP searchable database.
- Confirm the operating environment matches your deployment (OS version, CPU, container vs bare metal).
- Document algorithm allow-lists: AES-256-GCM, SHA-256+, ECDSA P-256, RSA 2048+.
- Run pre-production tests with FIPS mode enabled; several ciphers fail loudly when disabled.
For enterprise applications with mixed Nepal and U.S. users, split the analysis. Local eSewa or Khalti flows may follow Nepal Rastra Bank guidance. Parallel export or B2B API channels may add FIPS language. Architecture should isolate key custody so one region’s policy does not force unnecessary HSM cost on the other.
What does FIPS 140 validation mean for Laravel and PHP applications?
PHP 8.3 and PHP 8.5 applications on Laravel 12 or Laravel 13 do not ship as validated modules. OpenSSL linked into PHP-FPM may run in FIPS mode if the underlying OpenSSL build and OS policy support it. Ubuntu 22.04 and 24.04 offer openssl-fips packages on some channels; RHEL-derived images expose update-crypto-policies --set FIPS. Your job is configuration and cipher policy, not lab certification of application code.
In practice I configure three layers on Linux production servers when a client demands FIPS:
- OS crypto policy set to FIPS (system-wide algorithm block list).
- Web server cipher suites restricted to approved TLS 1.2/1.3 combinations.
- Application-level checks that legacy MD5 or SHA-1 helpers are not used for security-sensitive operations.
Laravel’s Hash facade defaults to bcrypt or Argon2id. Password hashing is separate from FIPS module validation. Some auditors still ask for PBKDF2 or scrypt inside a validated boundary for specific identity systems. Read the security plan before swapping defaults.
Example: verify OpenSSL FIPS provider on Linux
# RHEL / Rocky / Alma style systems
update-crypto-policies --set FIPS
update-crypto-policies --show
# Confirm OpenSSL lists FIPS provider
openssl list -providers
openssl list -digest-algorithms | grep -i sha256
# Quick negative test — MD5 should fail in strict FIPS mode
openssl md5 /etc/hosts
For API token signing, prefer RS256 or ES256 with approved curves. Laravel Passport vs Sanctum choices affect how keys are stored. Pair Sanctum with a KMS-backed key if the data classification sheet requires hardware-backed custody. Never embed long-lived private keys in .env on FIPS-regulated workloads.
Redis 8.10 and MySQL 9.7 connections should use TLS when data crosses networks. The validated module is usually the TLS library on each endpoint, not the database engine itself. Document that chain in your security architecture diagram for auditors.
What are common FIPS migration mistakes in production web systems?
Teams often treat FIPS as a checkbox after development finishes. That produces late-stage failures when a dependency calls MD5, Blowfish, or non-approved RNG APIs. Catch this in CI by running integration tests on FIPS-enabled staging images that mirror production.
Another pattern I see on client projects: assuming cloud “FIPS endpoints” automatically cover the entire stack. Only the listed services and regions fall under the module certificate. A FIPS-compliant RDS connection plus a non-FIPS Lambda runtime breaks the chain unless both environments are in scope.
Certificate expiry catches maintainers off guard. CMVP entries include sunset dates. Add calendar reminders 12 months before expiry. Plan vendor upgrades for HSM firmware and cloud key service versions tied to the certificate.
Document storage on legal-tech portals such as Mijar Law Associates adds another layer. Files at rest may use S3 SSE-KMS with a FIPS-validated HSM-backed master key. Application-level encryption with libsodium is strong cryptography but is not itself a validated module unless you buy a FIPS-certified SDK. Match the design to what the client’s compliance officer actually attests.
Use a password generator that defaults to long random strings. Entropy quality at the application edge still matters for FIPS environments. Pair with Base64 encoding tools only for data transport, not as a security control.
How do Nepal and international projects differ on FIPS requirements?
Nepal government portals and local banks typically reference Nepal Rastra Bank IT guidelines, ISO 27001, or PCI DSS rather than FIPS by name. Cross-border payment APIs, U.S. healthcare SaaS, and defence subcontractors export FIPS language into statements of work. Developers in Kathmandu building for those clients need CMVP literacy even when local hosting is standard commercial cloud.
Cost impact is real. FIPS-validated HSM partitions, dedicated cloud regions, and premium support tiers add Rs 15,000–80,000 per month (~USD 110–590) on small workloads. Budget for ongoing maintenance and re-validation-driven upgrades, not only initial setup.
When FIPS is not required, modern practice still aligns with 140-3 direction: disable TLS 1.0/1.1, retire SHA-1 signatures, prefer AES-GCM, rotate keys on schedule. API rate limiting and abuse prevention complements crypto controls. FIPS validates modules; it does not stop credential stuffing.
For custom software bids, ask early whether FIPS appears in the compliance matrix. Late discovery forces expensive re-architecture of key management. Testing and optimization phases should include a FIPS staging environment if the answer is yes.
Key Takeaways
- FIPS validates cryptographic modules, not your entire Laravel or WordPress codebase — trace the module boundary first.
- FIPS 140-3 is the current standard for new CMVP certificates; treat 140-2 entries as legacy with published sunset dates.
- Enable OS FIPS policy, restrict TLS ciphers, and audit dependencies for MD5, SHA-1, and weak RNG calls before go-live.
- Cloud “FIPS regions” cover only listed services — verify each hop in your architecture against the certificate operating environment.
- Nepal-local projects may skip FIPS; international B2B contracts often require it — scope compliance per revenue channel, not per company guess.
- Document certificate numbers, security levels, and algorithm allow-lists for auditors; renew before CMVP expiry.
People Also Ask
Is FIPS 140-3 backward compatible with FIPS 140-2?
Conceptually yes for procurement language that accepts “140-2 or successor.” Technically no module is dual-certified as one object. Each certificate is either 140-2 or 140-3. New submissions use 140-3 only. Existing 140-2 certificates remain valid until NIST sunset. Always confirm the module number on the CMVP list rather than assuming backward compatibility of test results.
Does FIPS 140-3 require hardware security modules?
No. FIPS 140-3 validates software, firmware, hybrid, and hardware modules at SL1 through SL4. Higher levels add physical tamper requirements that pure software cannot meet alone. Many cloud KMS offerings provide SL1 or SL2 software modules. SL3 and SL4 typically involve hardware or hardened appliances.
Can PHP Laravel applications be FIPS 140 certified?
The application layer is outside CMVP scope unless you embed a certified cryptographic module SDK as a distinct boundary. Standard PHP-FPM plus Laravel is not submitted for FIPS validation. You run on a FIPS-enabled OS and OpenSSL provider, restrict algorithms, and reference the underlying module certificate in compliance documentation.
What algorithms are approved under FIPS 140-3?
Approved primitives follow NIST SP 800-140C and related publications: AES (128/192/256), SHA-2 and SHA-3 families, ECDSA on approved curves, RSA with approved key sizes, and approved DRBG mechanisms. Deprecated algorithms like SHA-1 for signatures and Triple-DES face restrictions in new 140-3 validations. Consult the module’s security policy document for the exact allow-list tied to your certificate.
Build compliant systems with the right crypto foundation
FIPS 140-2 vs 140-3 Explained boils down to validation era and test rigour, not a different security-level numbering scheme. For new work in 2026, specify FIPS 140-3 validated modules, map every TLS and key-management hop, and test on FIPS-enabled staging before auditors arrive. If your product roadmap includes federal buyers, healthcare data, or hardware-backed payments, bake CMVP verification into architecture reviews early.
Need help scoping FIPS requirements for an API, client portal, or e-commerce platform? Review the portfolio for production systems already handling sensitive workflows, or contact us to walk through your compliance matrix and hosting options. Explore more engineering guides on the blog, read about the development approach, or visit the homepage for service overview.
Frequently Asked Questions
0 Comments
Leave a comment
Your email is not published. Comments appear once they have been read. Sign in to have your details filled in.

