Your application can be genuinely secure and still not be FIPS compliant. That's a hard sentence for a lot of engineering teams to sit with, because it means all the usual signals — HTTPS everywhere, strong algorithms, a hardened container image — don't actually answer the question FIPS is asking. FIPS isn't a property of your application. It's a property of the specific cryptographic modules your entire environment depends on, and that distinction is where most "we deployed to Kubernetes, so we're compliant" conversations go wrong.
FIPS 140-3, the current NIST standard governing cryptographic modules, doesn't certify applications, orchestrators, or clouds. It certifies specific, versioned cryptographic modules — a particular build of OpenSSL, a specific crypto library shipped with an operating system — tested and validated by an accredited lab under NIST's Cryptographic Module Validation Program (CMVP), run jointly with Canada's Centre for Cyber Security. CMVP maintains a searchable registry of every module that's actually earned a certificate, and it's explicit on a point worth repeating: a product doesn't meet FIPS 140 requirements just because it implements an approved algorithm and holds an algorithm validation certificate. The module itself — its implementation, not just its output — has to be the thing that was tested.
That's the core misunderstanding behind "we use AES-256, therefore we're compliant." AES-256 is an approved algorithm. Whether a given piece of software is using a validated implementation of it is a completely separate question, and it's the one that actually determines compliance.
Picture a typical deployment: application code, running on a language runtime, on an operating system, calling a cryptographic library, packaged in a container image, scheduled by a container runtime, sitting on a Linux kernel, on a VM or physical server. Every one of those layers can be where cryptographic operations actually happen — key generation, signing, hashing, TLS negotiation — and FIPS compliance depends on which specific modules are doing that work at each layer, not on the layer that happens to be easiest to point to in an architecture diagram.
Kubernetes sits entirely outside this question. It orchestrates, schedules, scales, and handles service discovery — genuinely valuable capabilities, none of which touch whether the cryptographic operations underneath a workload are FIPS-validated. A single cluster can host fully compliant workloads sitting right next to completely non-compliant ones, because the orchestrator was never the thing being certified in the first place.
This is where the practical work lives. A container built from a generic Ubuntu or a stock mcr.microsoft.com/dotnet/aspnet image is calling whatever OpenSSL build happens to ship in that image — and unless that specific build has been configured to use FIPS-validated modules, the application running on top of it isn't compliant no matter how good its own code is. Enterprise Linux distributions generally offer a real path here: Red Hat Enterprise Linux, for instance, documents a specific procedure for switching RHEL into FIPS mode — setting the fips=1 kernel boot argument, applying the FIPS system-wide cryptographic policy, and regenerating the initial RAM disk so the switch actually takes effect at boot. Once that's done, RHEL's core cryptographic components restrict themselves to FIPS-approved implementations system-wide — which also means, notably, that an application's own FIPS-related configuration flags get ignored in favor of the OS-level policy, since the OS is the thing actually enforcing the boundary at that point.
Enabling FIPS mode isn't a checkbox flipped after the fact, either — it's meaningfully easier to build into a base image from the start than to retrofit into a running fleet, which is exactly why this decision belongs in early architecture conversations rather than a pre-launch compliance sweep.
.NET on Linux typically defers to the operating system's cryptographic libraries for many operations, which means its FIPS posture is largely inherited from whatever's underneath it. Java maintains its own provider architecture, where the specific crypto provider configured matters as much as the JDK version. Go often bundles its own cryptographic implementations directly into the standard library rather than calling out to the OS, which changes the compliance conversation entirely — a FIPS-compliant OS underneath a Go binary doesn't automatically make the Go binary's own crypto operations compliant. None of these are interchangeable, and assuming one runtime's FIPS story applies to another is a common way compliance work quietly breaks.
Compliance doesn't stop at the container. Disk encryption, TLS certificate management, where private keys actually live, whether an HSM is required, whether the load balancer terminating TLS is using validated cryptography, how secrets are stored, how backups are encrypted — every one of these sits inside the same cryptographic boundary as the application code, and a gap in any of them affects the overall posture the same way a gap in the application would.
"We deployed to Kubernetes." "We use HTTPS." "We use OpenSSL." Each of these describes a technology choice, not a compliance outcome. FIPS compliance emerges from how every layer — application, runtime, OS, crypto library, infrastructure, hardware — actually works together, using validated modules where the standard requires them. That's why it has to be an architectural decision made early: which OS, which base image, which crypto libraries, which cloud services, where keys are stored, whether HSM integration is needed. Reversing any of those choices after a system is already running in production is a materially more expensive exercise than deciding correctly at design time.
FIPS was never about Kubernetes, containers, or any single algorithm. It's about ensuring the actual cryptographic operations your system performs — at every layer between your application code and the physical hardware — are carried out by modules that have been independently validated against a defined standard, not just modules that happen to implement an approved algorithm somewhere in their code. Architects who understand the full boundary, rather than treating the orchestrator or the algorithm choice as the finish line, are the ones who end up building systems that actually meet the requirement instead of just resembling it.
Why FAPI Recommends Private Key JWT: Your Public Key Is Meant to Be Public
A public key is an identity. A private key is the proof. The math behind why an attacker who steals your public key still can't forge a signature — RSA factoring, ECDLP, and what FAPI actually gets from Private Key JWT.
Your Secure APIs May Need More Than Bearer Tokens
If possession of a stolen token is enough to access your API, the token has become the password. DPoP, mTLS, and why proof-of-possession asks a fundamentally different question than a bearer token ever could.