Rebuilding for FIPS 140-3: The Foundation Under Post-Quantum

I rebuilt an OpenShift cluster on RHCOS with FIPS 140-3 mode enabled from first boot. Turning FIPS on is not a switch you flip on a running system: it disables every cryptographic algorithm that is not validated, so anything authenticating, pulling, or connecting on a non-approved one stops until you move it. The job is to raise the cryptographic floor and keep every function the platform had. This is the third post in a series on the sovereign cluster I operate: the first covered why I run it, the second covered the governance layer on top. This one goes down to the foundation.

FIPS mode is set when a system is created. Build a new one and it is a decision you make up front; bring an existing one up to it and reaching it is a rebuild, whether that runs on bare metal, a managed OpenShift cluster, or a government cloud like AWS GovCloud, Azure Government, or Google Cloud Assured Workloads. Mine already existed, so this was the rebuild. You stand the system back up on validated cryptography and bring every function with it. Here is how I ran it.

I Started With an Inventory

The cluster was already OpenShift-grade, but it ran on OKD, the community, open-source build of OpenShift that had been a deliberate constraint from the start. OKD gives you the same architecture as the commercial product, and it can even turn FIPS mode on. What it cannot give you is FIPS-validated cryptography. Validation is a CMVP certificate issued against one specific vendor build, and it does not transfer to a community rebuild: the mode is available, the certificate is not. Holding validated cryptography meant the platform itself had to become a vendor build that carries its own certificate: Red Hat OCP on RHCOS. Becoming a Red Hat partner is what let me run this on a validated build.

Even with the platform decided, the move starts with an account of what stops the moment FIPS mode comes on. That account is the step that tells you which functions are about to break, and it is the one easiest to skip.

RHCOS runs in FIPS mode by drawing on FIPS 140-3 validated cryptographic modules, but only when a node is provisioned that way from first boot. So the real inventory was a list of functions that assumed a non-FIPS world, because FIPS mode disables the algorithms that are not validated and that surfaces quickly. Ed25519 SSH keys stop being accepted. A TLS client that negotiates a non-approved cipher fails the handshake outright. Each line in that inventory is a function that stops, and a function I would have to bring back another way. None of this is exotic. It is the ordinary plumbing of a running cluster, and every piece of it is decided at provisioning time, which is why the inventory pointed at a full rebuild rather than an in-place change.

Keeping the Functions While Raising the Floor

Before touching the foundation, I backed up everything and restored it to a scratch target to confirm the backups were usable. A backup is not a backup until you have restored it somewhere and checked what came back. That check is the unglamorous work that makes a rebuild survivable, and I do it first.

Most of the rebuild is then the work of bringing each stopped function back on approved cryptography. SSH access returns on RSA-4096 and ECDSA keys in place of the rejected Ed25519. GitOps reconciliation returns over authenticated smart HTTP. The anonymous git:// transport ArgoCD used before was never a FIPS casualty: git:// carries no cryptography to disable, but the validated build ships no git daemon to serve it, and an unauthenticated transport had no place in a hardened cluster anyway. Component-to-component TLS comes back as each client is moved onto an approved cipher suite. Console access had to be stood up from nothing, because the rebuilt cluster came with no identity provider, and even that carried a sharp edge: the htpasswd provider rejected the bcrypt hash Python emits with a $2b$ tag, and the fix was the identical-digest $2y$ tag. None of these are large changes alone. The discipline is doing all of them, so the platform ends up doing everything it did before, now on validated modules.

A node also came up wrong during the rebuild and had to be reprovisioned clean. I ran that step with AI agents as a co-pilot, governed by the secret-guard hooks that wrap Claude Code on this host: a pre-execution hook blocks any command that would read a credential, and a post-execution hook scans output for secrets before it reaches the model. The in-cluster LLM Guard proxy from the last post was itself offline during the rebuild (it runs on the cluster I was tearing down), so the shell-layer hooks were the live boundary. The agents were quick on the diagnosis, reading node conditions and operator status and proposing the reprovision sequence, while a human approval held on every consequential move. Quick on the diagnosis, a hard stop on the consequence: that is the shape an agent should have on infrastructure mid-rebuild.

The Pressures That Call for FIPS

The pressure is regulatory before it is technical. NIST's Cryptographic Module Validation Program (CMVP) is retiring FIPS 140-2 module validations on its 2026 schedule, so new work that calls for validated cryptography is built on FIPS 140-3 modules. Where that requirement originates depends on the contract: NIST SP 800-171 control 3.13.11 requires FIPS-validated cryptography to protect CUI, and CMMC Level 2 inherits 800-171; FedRAMP carries the same expectation for cloud services sold to federal agencies; CNSA 2.0 sets it for national security systems.

Whether a given system falls inside any of those scopes is the assessor's call, not mine: the practitioner scoping the program owns that determination. What I own is the platform that satisfies the requirement once it applies, which is why I built it ahead of the contract rather than under one.

Post-quantum cryptography is the pressure behind the pressure. The post-quantum signature and KEM standards (ML-DSA, ML-KEM, SLH-DSA) have to run inside FIPS-validated modules to count for federal use, and those validated modules are only now arriving. Enabling FIPS mode now provides validated classical cryptography and the place those post-quantum modules will land once they ship. Validated cryptography, post-quantum readiness, and AI security converge on this one layer, which is the throughline of this series.

Where This Leaves You

FIPS mode is provisioned at creation, which cuts two ways. If the architecture is not built out yet, FIPS is a decision you make in the initial build, before anything depends on the algorithms it will disable, and it costs almost nothing. If the system already exists, reaching it is a rebuild, and that is where the work concentrates. I was on the second path. When you are, the platform-specific parts change but the parts that decide the outcome do not: an inventory that finds which functions FIPS will stop before you boot, backups you have restored and checked, a change process that stays in control while the cluster is in pieces, and the patience to bring every function back on approved cryptography.

If you do not run a platform yourself, this is smaller than it sounds. Most companies that owe FIPS-validated encryption are buyers of it, not builders: the actual job is choosing products that are already on the government's approved list and switching the validated setting on, which is closer to paperwork than to the rebuild above. The heavy version in this post is what it takes when you run the ground floor everyone else stands on, where there is no product to buy because you are the thing being validated. If you are not sure which of those two you are looking at, that is the first question worth answering, and for most companies it is the lighter one.

The execution is the hard half: standing a live system back up on FIPS-validated modules with its functions intact. That is the work I do. The rebuild above is on infrastructure I operate, built ahead of the requirement, and it is a fair picture of how I would run the same migration for a client.