The *Engineering* Cost of FIPS 140-3 Compliance — Six Months for One Customer

Last year we rebuilt our entire system to use only FIPS 140-3 validated cryptography for a US federal customer's bid. It took six months.

This post is the real cost — lines of code, dependency changes, political work, and the question of who should do this at all.

What FIPS 140-3 actually is

FIPS 140-3 — FIPS Publication 140-3. The standard the US federal government requires for cryptographic modules. Only validated modules may be used — meaning libraries and hardware officially validated by NIST.

Often the qualifying line for federal bids. Almost impossible to add later — must be in from the start.

Six months — time allocation

Work                                          | Duration | Labor cost
──────────────────────────────────────────────┼──────────┼────────────
Dependency audit (find non-FIPS libraries)    | 4 weeks  | $16,000
Replacement library research + evaluation     | 6 weeks  | $24,000
Explicit wrapping of TLS / crypto calls       | 8 weeks  | $32,000
Build-time FIPS mode activation               | 2 weeks  | $8,000
Validation (all tests pass under FIPS mode)   | 4 weeks  | $16,000
*Certification* itself (external lab + paperwork) | 6 weeks | (external cost separate)
──────────────────────────────────────────────┼──────────┼────────────
Total                                          | 30 weeks | $96,000 (+ external certification)

The expensive part — dependencies

Most of the time went into dependencies, not our code.

Node.js standard crypto module

Default builds aren't FIPS-compatible. There's a FIPS Node.js build you have to put in your base image. That alone took two weeks.

TLS libraries

OpenSSL has FIPS mode OK. Transit libraries we'd never written ourselves bundled their own TLS — all needed FIPS-compatible replacements.

JSON Web Token

jsonwebtoken npm — pure JS crypto. Not FIPS-compatible. Replaced with node-jose + FIPS Node build.

Random generators

Math.random — non-cryptographic PRNG — turned up in places we didn't know it was used. UUID generation, slug generation, temporary tokens — all replaced with crypto.randomBytes.

Four political costs

Beyond engineering, there were political costs.

1. Holding off non-FIPS-validated new tech

When a new library or service appears, we can't adopt it until validated. This slows technical decisions. Three upgrades held in six months.

2. Same codebase as non-FIPS customers

Two options:

• FIPS build and standard build in one codebase — complex, low maintenance
• Separate fork — simpler, but permanent divergence accrues

We chose one codebase + build flags. Three weeks of debate.

3. Policy on non-FIPS dependency discovery

Every PR adding a new dependency must include a FIPS compatibility check. If not compatible, PR rejected. This policy slowed engineering 15%. Required quarterly review meetings + CTO sign-off.

4. Who pays for external certification

NIST validation labs cost tens of thousands. Bill the customer, or absorb as OPEX? Decided in commercial negotiation — must be explicit in the deal.

Was it worth it?

This single customer contract = several million per year. ROI on $96,000 + external certification is clearly positive.

That said, doing this for one customer alone would have been a regret. We confirmed three more potential customers with FIPS as a qualifying gate before deciding. With one, we'd have held.

For security and engineering leads preparing bids for US federal, some EU government, or Korean public-sector entities adopting FIPS standards, the order is fixed. First, confirm in writing that FIPS is actually required. If it is, the six months + $96,000 above are the minimum budget. And don't do it for one customer — decide when, like us, three or more are on the table.