TL;DR

Inside a FedRAMP authorization boundary, FIPS-validated crypto stops being a best practice and becomes a hard requirement. This post is the bridge between the FedRAMP framework basics from Part 2 and the supply-chain work I’ve already documented in the Building for Compliance series — where FIPS shows up across the 800-53 control families, which crypto surfaces audit hits hardest, and how the SBOM / provenance / cosign / Wolfi work I described over there maps directly onto the FedRAMP evidence story over here.

Introduction

Part 2 walked through the FedRAMP framework end to end — impact levels, the document set, Rev5 versus 20x. One thing I deliberately left on the side: the FIPS angle. That deserved its own post, because FIPS-inside-FedRAMP is where most of the platform engineering pain actually lives.

Here’s the punchline I’d put on a slide: every cryptographic operation inside your FedRAMP boundary, at Moderate or above, must be performed by a FIPS-validated cryptographic module. Not “FIPS-capable.” Not “FIPS-compliant.” Validated — meaning it carries a NIST CMVP (Cryptographic Module Validation Program) certificate that you can reference by number.

That single requirement reshapes more of your platform than people expect. Let me walk through where it lands.

FIPS 140-2 vs 140-3 — Quick Refresher

I covered this in Building for Compliance Part 1, so I’ll keep it short here.

FIPS 140-2 dominated for two decades. NIST stopped accepting new module validations under 140-2 in September 2021, and the sunset window for existing 140-2 certificates runs through the rest of this decade.

FIPS 140-3 is the current standard, aligned with ISO/IEC 19790. Stricter on side-channel resistance, lifecycle documentation, and non-invasive attacks.

For container workloads the practical impact is identical in both cases: your crypto libraries — OpenSSL, BoringSSL, Go’s crypto stack — must carry a CMVP certificate, not just claim FIPS-ish behavior. Most upstream base images ship non-validated crypto by default. That’s the gotcha that sends teams hunting for new base images, and it’s exactly the problem the Wolfi work in Part 2 of the Building for Compliance series was solving.

If you’re new to the FIPS distinction, the Building for Compliance series covers the crypto-and-containers angle in much more depth. This post focuses on where that work lands inside a FedRAMP authorization.

Where FIPS Lands Inside the 800-53 Control Families

FedRAMP is built on NIST SP 800-53. FIPS requirements don’t live in a single control — they’re scattered across the catalog as enhancements and references that you only notice once you start writing the SSP. The families that carry the most FIPS weight, in roughly the order they bite you:

SC — System and Communications Protection. This is where FIPS-validated crypto shows up most directly. SC-8 (Transmission Confidentiality) and SC-13 (Cryptographic Protection) both require FIPS-validated mechanisms at Moderate and above. SC-12 (Cryptographic Key Establishment and Management) brings KMS, HSM, and key-rotation evidence into scope. SC-28 (Protection of Information at Rest) covers encrypted storage — the volumes, the buckets, the databases — and the encryption has to be validated.

IA — Identification and Authentication. IA-5 (Authenticator Management) and IA-7 (Cryptographic Module Authentication) pull in FIPS-validated mechanisms for password storage, MFA tokens, and machine-to-machine authentication. Anywhere a secret is hashed, signed, or verified, the underlying primitive needs a CMVP number.

AU — Audit and Accountability. AU-9 (Protection of Audit Information) and AU-10 (Non-Repudiation) increasingly assume that the integrity protection on your audit logs — the signing, the hashing, the tamper-evident chain — is also done by a validated module. Auditors started enforcing this more strictly somewhere around 2023.

SI — System and Information Integrity. SI-7 (Software, Firmware, and Information Integrity) is the family that fingerprints map directly to the signed-and-verified supply chain story. This is where SBOM, provenance, and cosign evidence stops being best practice and starts being SI-7 evidence.

CM — Configuration Management. CM-7 (Least Functionality) and CM-11 (User-Installed Software) are the controls that authorize what runs in your boundary. Image inventories, allow-lists, admission-control evidence — all CM family.

SA — System and Services Acquisition. SA-12 (Supply Chain Risk Management) and SA-22 (Unsupported System Components) are the controls that ask the supply-chain question explicitly: who built this, with what, and how do you know.

That last cluster — SI + CM + SA — is where the Building for Compliance work does most of its lifting. Which brings me to the mapping.

Mapping the Supply-Chain Work to FedRAMP Evidence

Let me walk through the supply-chain primitives I covered in the Building for Compliance series and where each one shows up as FedRAMP evidence.

SBOM (build-time, signed, attached as in-toto attestation). This is the cleanest CM-8 (Information System Component Inventory) evidence I’ve ever produced. CM-8 asks for “an inventory of system components that accurately reflects the current system.” A signed build-time SBOM attached to an image, verified at admission time, is exactly that — for every image in your boundary, automatically, on every build. The CM-8 narrative in the SSP becomes a paragraph and a pipeline reference. Pair the same SBOM with SI-2 (Flaw Remediation) — re-scan the persisted SBOM as the CVE database updates, track findings into your monthly continuous monitoring report — and you’ve collapsed two control families into one pipeline output.

Provenance (in-toto attestation, signed in CI). SA-12 (Supply Chain Risk Management) wants assurance that the artifact in production is the one you built, from the source you reviewed, by the pipeline you control. Signed provenance is that assurance, in cryptographically verifiable form. The SA-12 narrative writes itself: “every artifact deployed into the boundary carries an in-toto provenance attestation signed by the build identity; the admission controller rejects artifacts without verified provenance; the verification log is exported to the SIEM and retained per AU-11.”

Cosign / sigstore signing and admission-time verification. SI-7 (Software, Firmware, and Information Integrity) is the headline control here. SI-7’s whole purpose is integrity verification of the software you run. Signed images plus an admission controller (Kyverno, Gatekeeper, Connaisseur) that refuses unsigned ones gives you the strongest SI-7 evidence available — and you didn’t have to write a custom integrity-monitoring agent to do it.

SLSA framework adoption (L3 target). SLSA doesn’t map to a specific control number, but it gives you a defensible posture across SA-10 (Developer Configuration Management), SA-11 (Developer Testing and Evaluation), and SA-12. The SLSA level becomes a one-liner in the SSP that summarizes a lot of organizational discipline.

Wolfi-based images with built-in SBOMs and FIPS-validated openssl. The Wolfi adoption I covered in Building for Compliance Part 2 and Part 3 collapses SC-13 (Cryptographic Protection), CM-7 (Least Functionality, via minimal image surface), SA-22 (Unsupported System Components, by rebuilding frequently), and SI-2 (Flaw Remediation, via the rebuild cadence itself) into a single base-image choice. That’s the move that makes the rest of the control narrative tractable. If you’re on a base image that still ships non-validated crypto and a bloated runtime in 2026, the SSP work is going to feel like fighting the image instead of writing the post.

Pipeline-level verification (Part 4 of Building for Compliance). The verified-pipeline pattern — signed at build, attested through the pipeline, verified at admission — gives you CM-3 (Configuration Change Control) and CM-5 (Access Restrictions for Change) evidence as a byproduct. The CloudTrail / audit-log entry showing the admission controller rejecting an unsigned image is, itself, the change-control evidence the auditor wants.

The pattern I keep noticing: well-designed supply-chain pipelines produce FedRAMP evidence as exhaust. Badly-designed ones produce a separate evidence stream that nobody trusts. The Building-for-Compliance work was always quietly preparing the platform for FedRAMP, even when SOC 2 was the active goalpost.

The Crypto Surfaces That Audit Hits Hardest

If I were going to estimate where 3PAOs spend the most time when they assess FIPS in a FedRAMP boundary, in order:

  1. TLS termination at ingress. Is the ingress controller — nginx, Envoy, ALB, the load balancer fronting your cluster — using FIPS-validated TLS? Most stock images aren’t. This is the first crypto surface every auditor checks because it’s the most visible.

  2. KMS and key wrapping. AWS KMS in the GovCloud regions runs FIPS-validated HSMs. Commercial KMS regions have FIPS endpoints you can opt into. Using KMS isn’t enough — you have to be hitting the FIPS-validated endpoint, and your code has to know about that distinction.

  3. Application-layer crypto. Anything your application does directly — signing JWTs, hashing passwords, encrypting field-level data, generating session tokens. This is where the FIPS-validated language runtime matters. Go has GOEXPERIMENT=boringcrypto and now native FIPS 140-3 modes; the JVM has FIPS-validated providers; Python and Node need an explicitly FIPS-built OpenSSL underneath them.

  4. At-rest encryption. Volume encryption, S3 SSE, RDS encryption — all need to land on a validated underlying primitive. Mostly this is solved by using cloud-managed encryption in the right region, but the SSP narrative has to make that explicit.

  5. Signing and verification of artifacts. Cosign, sigstore, the keys behind them, the transparency log. The keys used to sign deployment artifacts need to come from a validated module path, and the verifier needs to use one too.

  6. Audit log integrity. As I mentioned under AU-9 — increasingly an auditor focus.

Each of these can be handled. None of them are difficult in isolation. The trap is that they have to all be handled consistently, and a single non-validated TLS handshake on a sidecar somewhere in production is enough to fail SC-8. Hence the boundary discipline: the perimeter has to be drawn precisely, and everything inside it has to be FIPS-clean.

What I’d Tell My Past Self

Two things, looking back at the work that led into this.

First: the FIPS conversation should happen before the FedRAMP conversation, not during it. If you start FedRAMP discovery and then find out your base images ship non-validated OpenSSL, you’ve added six months to the timeline. The supply-chain modernization — Wolfi or equivalent, signed images, verified pipelines — is the prerequisite, not the parallel workstream. The teams I’ve seen succeed at FedRAMP did the FIPS and supply-chain work as a SOC 2 / general hardening effort in the year before they ever scoped a FedRAMP engagement.

Second: let the supply-chain pipeline be the evidence engine. The biggest mindset shift is realizing that the SSP isn’t a document you write in Word — it’s a thin narrative layer over a pipeline that produces evidence continuously. SBOMs, provenance, signing logs, admission-controller verdicts, CVE remediation timelines — these are the inputs the auditor actually wants. The SSP just explains how the pipeline operates. The leverage of building this way is enormous: every new control becomes a paragraph and a pointer to existing pipeline output, instead of a fresh evidence-collection sprint.

Conclusion

That’s where FIPS lives inside FedRAMP — across SC, IA, AU, SI, CM, and SA, with the heaviest enforcement on the crypto surfaces (TLS, KMS, application-layer, at-rest, signing) and the supply-chain surfaces (SBOM, provenance, signature verification). The good news, if you’ve been doing the supply-chain work for SOC 2 or for general posture: most of the FedRAMP evidence already exists, you just haven’t been calling it FedRAMP evidence.

Where this series goes next is still loose, and I want to keep it that way. The candidates on my list: a deep dive into FedRAMP 20x and OSCAL (the machine-readable submission model), the Kubernetes-specific control mappings, the boundary-and-architecture conversation (drawing the perimeter is its own dark art), and the SOC 2 → FedRAMP delta in concrete terms. Probably I’ll pick the one that the engagements I’m in are actively forcing me to learn.

If you’ve been walking a similar path — non-US ISV, platform or DevOps lead, working backwards from a federal opportunity to figure out what the platform needs to look like — I’d love to hear what you’re hitting. The whole point of writing the series as I go is that it gets better when other practitioners push back.

Further Reading