Meeting FIPS 140-3 and CMMC 2.0 Certificate Requirements in DevOps Pipelines

The era of self-attestation in government contracting is over. With the finalization of the Cybersecurity Maturity Model Certification (CMMC) 2.0 program, the release of NIST SP 800-171 Revision 3, and the mandated transition to FIPS 140-3, the Department of Defense (DoD) and federal agencies have fundamentally changed how contractors must manage digital certificates, Public Key Infrastructure (PKI), and encryption.

For DevOps engineers, security professionals, and IT administrators at government contractors (GovCons), manual certificate management is no longer a viable strategy. Proper PKI and encryption management are now strict, third-party validated pass/fail controls. If your infrastructure relies on manually rotated certificates or non-validated cryptographic modules, you risk not just an operational outage, but the loss of your federal contracts.

This post breaks down the technical realities of the new compliance landscape, the critical difference between FIPS-compliant and FIPS-validated algorithms, and how to engineer automated, cryptographically agile pipelines that pass Defense Industrial Base Cybersecurity Assessment Center (DIBCAC) audits.

The FIPS Trap: Compliant vs. Validated

The single most common reason government contractors fail encryption controls during audits is misunderstanding the difference between "FIPS-compliant" and "FIPS-validated."

Developers often assume that because they configured their Nginx server or Go application to use an approved algorithm like AES-256-GCM, they are compliant with Defense Federal Acquisition Regulation Supplement (DFARS) 252.204-7012. This is incorrect.

To meet federal standards, it is not enough to use the right math; the specific software module executing that math must hold an active validation certificate from the NIST Cryptographic Module Validation Program (CMVP). Standard open-source OpenSSL is FIPS-compliant, but unless you are using the specific OpenSSL FIPS Object Module compiled in a very specific way, it is not FIPS-validated.

Implementing Validated Modules at the OS Level

The most reliable way to solve this in DevOps environments is to standardize on FIPS-validated base images, such as Red Hat Universal Base Image (UBI) FIPS or Ubuntu Pro FIPS, and enforce FIPS mode at the kernel level.

For example, on Red Hat Enterprise Linux (RHEL), you can enable FIPS mode using the fips-mode-setup tool. This ensures that all cryptographic calls made by the OS and supported libraries route through validated modules.

# Enable FIPS mode
sudo fips-mode-setup --enable

# Reboot the system for the kernel parameters to take effect
sudo reboot

# Verify FIPS mode is active
sysctl crypto.fips_enabled
# Expected output: crypto.fips_enabled = 1

Compiling Applications for FIPS

If you are building custom microservices, your compiler toolchain must also support validated cryptography. For Go applications, this means compiling with BoringCrypto, a FIPS-validated fork of BoringSSL used by Google.

# Build a Go application using the FIPS-validated BoringCrypto module
CGO_ENABLED=1 GOEXPERIMENT=boringcrypto go build -o myapp-fips main.go

# Verify the binary contains the BoringCrypto symbols
go tool nm myapp-fips | grep _Cfunc__goboringcrypto_

Core Regulatory Mandates Reshaping PKI

To engineer a compliant system, DevOps teams must design around three major regulatory shifts taking effect in 2024 and 2025.

1. NIST SP 800-171 Rev 3 and Automated Provisioning

Released in May 2024, NIST SP 800-171 Revision 3 introduces stricter controls around cryptographic protection and system integrity. Crucially, it explicitly requires organizations to establish and manage cryptographic keys using automated mechanisms.

This aligns with the broader industry push—led by Google and Apple—to reduce public TLS certificate lifespans to 90 days. Between the sheer volume of 90-day certificates and the NIST mandate for automation, integrating protocols like ACME (Automated Certificate Management Environment), SCEP, or EST is now a baseline requirement.

2. The FIPS 140-3 Transition

As of 2024, FIPS 140-2 certificates are moving to historical status. All new cryptographic modules used by government contractors must be validated against the more stringent FIPS 140-3 standard. When auditing your Software Bill of Materials (SBOM) and infrastructure components, you must verify that your load balancers, ingress controllers, and HSMs (Hardware Security Modules) are actively transitioning to or already hold FIPS 140-3 validation.

3. Post-Quantum Cryptography (PQC) Readiness

In August 2024, NIST finalized the first three PQC algorithms (FIPS 203, 204, and 205). Following OMB Memorandum M-23-02, federal agencies and contractors must inventory all cryptographic systems to prepare for the transition to quantum-resistant algorithms by 2030. This demands "crypto-agility"—the architectural ability to swap out root certificates and cryptographic algorithms across thousands of endpoints without taking systems offline.

External Certificate Authorities (ECA) vs. Public CAs

Many contractors struggle with knowing when to use a standard public certificate (like those from Let's Encrypt or DigiCert) versus a DoD External Certificate Authority (ECA) certificate.

• Public CAs: If you are hosting a public-facing informational website or a FedRAMP SaaS portal where standard users log in over the internet, standard public certificates are acceptable—provided the TLS termination endpoint (e.g., an AWS GovCloud Application Load Balancer configured with a FIPS security policy) uses FIPS-validated cryptography.
• DoD ECA Certificates: If your application interacts directly with DoD information systems, or if your personnel need to send encrypted emails to DoD addresses or authenticate to DoD portals, you must use certificates issued by a DoD-approved ECA vendor.

Currently, only a few providers, such as IdenTrust and GlobalSign, are authorized to issue these certificates. Your web servers (Nginx/Apache/Envoy) must be configured to request client certificates, validate them against the Federal Public Key Infrastructure (FPKI) trust anchors, and extract the Subject Alternative Name (SAN) or EDI-PI for identity mapping.

Implementing Compliant Certificate Architectures in Kubernetes

Modern DevOps relies heavily on container orchestration, but securing Kubernetes for federal compliance requires strict Zero Trust Architecture (ZTA) principles. Executive Order 14028 mandates ZTA, which translates technically to enforcing Mutual TLS (mTLS) between all microservices.

mTLS with FIPS-Validated Service Meshes

You cannot simply terminate TLS at the Kubernetes Ingress and allow plaintext traffic inside the cluster. To pass a CMMC or FedRAMP audit, you must implement a service mesh like Istio or Linkerd.

However, the standard Envoy proxy sidecars used by Istio are not FIPS-validated out of the box. You must deploy Istio using a FIPS-compliant Envoy image (often provided by enterprise vendors like Tetrate, Solo.io, or Red Hat OpenShift Service Mesh).

Once deployed, you must enforce strict mTLS via a PeerAuthentication policy:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT

This ensures that every pod-to-pod communication is encrypted using FIPS-validated cryptography and authenticated via short-lived internal certificates managed by the mesh's control plane.

Real-World Audit Failures and Solutions

Understanding the theory is one thing; surviving an audit is another. Here are two real-world scenarios that illustrate how these requirements play out in practice.

Case Study 1: The Internal Traffic DIBCAC Failure

A mid-sized defense contractor underwent a DIBCAC assessment. They had meticulously configured their external Web Application Firewall (WAF) to enforce FIPS-validated TLS 1.2.

The Failure: The auditors examined the traffic behind the WAF—specifically the connections between the internal load balancer and the backend database clusters. The DevOps team had used long-lived, self-signed certificates generated by standard OpenSSL to encrypt this internal traffic. Because the internal modules were not FIPS-validated, the contractor failed the control.

The Resolution: The contractor had to halt operations and deploy an internal PKI using a FIPS-validated root CA. They integrated HashiCorp Vault Enterprise (which includes a FIPS 140-2/3 validated cryptographic module) to dynamically issue and rotate internal certificates for the database connections.

Case Study 2: FedRAMP High Authorization via Cryptographic Agility

A SaaS provider seeking FedRAMP High authorization needed to prove they could rotate all cryptographic keys and certificates across their entire infrastructure within 24 hours in the event of a suspected compromise.

The Success: Manual rotation across hundreds of nodes was mathematically impossible within the time frame. The team implemented a centralized Certificate Lifecycle Management (CLM) tool integrated directly with their Kubernetes ingress controllers via ACME. By executing a single API call, they could force the renewal and redeployment of all certificates without human intervention, easily satisfying the FedRAMP continuous monitoring and incident response controls.

Tooling and Infrastructure for Cryptographic Agility

To build a compliant, automated certificate pipeline,