Skip to content

CONCEPT Cited by 1 source

FIPS 140-validated cryptographic module

Definition

A FIPS 140-validated cryptographic module is a library or HSM whose implementation of cryptographic primitives has been tested by a NIST-certified lab against one of the FIPS 140 publications (FIPS 140-2 or the 2019 successor FIPS 140-3) and issued a NIST validation certificate. Validation covers both which primitives the module implements (must be FIPS-approved: AES, SHA-2/3, RSA, ECDSA with approved curves, X25519, ML-KEM since 2024, etc.) and how the module behaves in FIPS mode (non-approved modes disabled at runtime; self-tests on startup; approved-key-format enforcement).

The module is the enforcement artefact that realises a FIPS cryptographic boundary — without a validated module, a deployment cannot claim FIPS compliance, regardless of its algorithm choices on the wire.

Canonical instance: Redpanda + OpenSSL

Redpanda (2025-05-20) discloses its FIPS substrate verbatim: "Redpanda provides FIPS-compliant cipher enforcement for brokers using OpenSSL 3.0.9, which is validated for FIPS 140-2 and is undergoing validation by NIST for 140-3. Both Redpanda brokers and the rpk command-line tool leverage validated OpenSSL libraries for all security-related cryptography operations." (Source: sources/2025-05-20-redpanda-implementing-fips-compliance-in-redpanda)

This canonicalises three module-altitude properties:

  1. The module version matters, not just the library family. OpenSSL 3.0.9 is FIPS 140-2 validated; a different 3.0.x point release may not be. Upgrading the broker across module versions is a validation-gated operation.
  2. The module substrate propagates to sibling tooling. Redpanda validates both the broker binary and the rpk CLI against the same validated module. Any FIPS-claiming product must audit every on-box cryptographic consumer, not just the primary service.
  3. Validation lags release. OpenSSL 3.0.9 is 140-2 validated today and undergoing 140-3 validation; OpenSSL 3.1.2 (already 140-3 validated) is Redpanda's late-2025 upgrade target. This lag — between a library release and its validated drop-in availability — is the structural constraint inside the FIPS boundary.

FIPS 140-2 → 140-3 transition

FIPS 140-3 (published 2019, replaces 140-2) is the current standard for new validations; NIST stops accepting new 140-2 submissions and sunsets existing 140-2 certificates on a published schedule. The transition forces every product claiming FIPS compliance to upgrade its module dependency before its 140-2 substrate loses certificate validity. Redpanda's framing verbatim:

"In late 2025, Redpanda will move to OpenSSL 3.1.2, which was validated for FIPS 140-3 to remain compliant as 140-2 expires." (Source: sources/2025-05-20-redpanda-implementing-fips-compliance-in-redpanda)

The same forcing function hits every FIPS-claiming product in the corpus — SSH libraries, database TLS stacks, HSM vendors, cloud- provider KMS offerings — on the same schedule.

Startup-time self-test

A validated module performs power-on self-tests the first time it's loaded (known-answer tests on each approved primitive, integrity check on the module binary). Failure causes the module to refuse to initialise — consumer applications then fail their FIPS-mode precondition check at startup, which composes with patterns/startup-enforcement-fail-fast-on-config-noncompliance into a broker-level fail-fast on any validated-module breakage.

Design implications

1. Module-level trust, not algorithm-level trust. A FIPS-compliant deployment trusts the module to implement approved algorithms correctly. Rolling a CVE fix into the module requires re-validation; rolling a CVE fix into an adjacent non-crypto subsystem doesn't. This cleaves the patch-management surface in two.

2. Artefact distribution must preserve the boundary. The validated module is typically shipped as a parallel artefact (separate RPM, Debian package, or build target) alongside the default non-FIPS build. Redpanda's two-package split (redpanda-fips + redpanda-rpk-fips) is a canonical wiki instance; downstream consumers inside the boundary install the FIPS artefacts, consumers outside install the default artefacts, and both share a single upgrade pipeline.

3. Cross-cloud / cross-service FIPS coverage isn't uniform. Redpanda's 2025-05-20 disclosure limits FIPS support to self-managed RPM / Debian deployments; Cloud, Kubernetes, and Redpanda Connect are on the roadmap. The validated-module constraint forces every deployment shape to re-validate (or be re-validated) before joining the boundary.

Seen in

Last updated · 470 distilled / 1,213 read