FIPS 140-3 is the current U.S. government standard for cryptographic modules. It replaces 140-2 with stricter requirements for validation, testing, and lifecycle control. For FFmpeg, this means more than linking OpenSSL—it means ensuring the crypto backend is built from a validated FIPS module, with APIs mapped to the compliant subset, and all non-compliant algorithms disabled at compile time.
FFmpeg itself does not ship a FIPS 140-3 certified crypto library. The standard approach is to use a validated OpenSSL FIPS 140-3 module, configured to run in FIPS mode. You must rebuild FFmpeg with that exact library, lock in deterministic builds, and verify the binary hash. If your deployment spans multiple environments, every build must use identical compiler flags, dependency versions, and FIPS-approved algorithms.
Common pitfalls:
- Linking against a system OpenSSL that is not in FIPS mode.
- Enabling codecs or protocols that call non-FIPS algorithms.
- Forgetting to set
OPENSSL_FIPS=1 or equivalent runtime flags. - Mixing debug symbols from non-FIPS builds.
Testing is mandatory. Start FFmpeg and check crypto calls using openssl version -fips and API traces. Run NIST-approved vectors for each enabled crypto algorithm. Only after passing these should you mark the build as FIPS 140-3 ready. Documentation from NIST CMVP (Cryptographic Module Validation Program) and your OpenSSL vendor will be your reference here.
Compliance is not only technical—it is procedural. FIPS 140-3 defines how modules are handled from source to deployment. A compliant build pipeline must enforce version control, artifact integrity, and separation of duties. FFmpeg’s configuration scripts, dependencies, and final binaries must be logged and reproducible.
You can spend weeks setting this up, or you can launch a compliant pipeline instantly. See how it works live at hoop.dev and build FIPS 140-3-ready FFmpeg in minutes.