Your observability platform ingests every log line, every trace span, every metric data point from your production systems. That telemetry contains IP addresses, request payloads, error messages with stack traces referencing internal systems, and sometimes PII that made it past your scrubbing filters. It is, by definition, some of the most sensitive operational data in your infrastructure.

Now ask your observability vendor: is that data encrypted with FIPS-validated cryptography? Not "we use TLS" or "we support encryption at rest." Specifically: has the cryptographic module been validated by NIST's Cryptographic Module Validation Program? For most vendors, the answer is either "no" or "only in our federal product tier."

This post covers how we built FIPS 140-3 validated cryptography into the standard Kloudfuse platform. Certificates #5186 and #5209 cover the commercial product, not a separate federal SKU. We'll walk through what the validation actually covers, how FIPS 140-3 differs from 140-2, and why the distinction between "embedded" and "configured" matters more than most security reviews acknowledge.

What Does FIPS 140-3 Validation Actually Cover in Kloudfuse?

The validated cryptographic modules are embedded in all platform container images and provide cryptographic services across the platform: data ingestion pipelines receiving telemetry over TLS connections, storage systems encrypting data at rest in the unified data lake, query engines decrypting data for analysis, API endpoints handling authentication and authorization, and control plane components managing cluster operations and configuration.

All five telemetry types receive the same cryptographic protection: metrics, logs, traces, events, and RUM data. There is no "unencrypted fast path" for lower-priority data.

The platform uses two FIPS 140-3 validated cryptographic modules from SafeLogic's CryptoComply family. Certificate #5186 covers the Kloudfuse Cryptographic Module, a C-based module built on the OpenSSL 3.x FIPS provider that handles cryptographic operations for platform infrastructure services. Certificate #5209 covers the Kloudfuse Java Cryptographic Module, which provides cryptographic services for Java-based platform components. Both modules are validated at FIPS 140-3 Level 1 and are embedded directly in every Kloudfuse deployment, not sourced separately by customers.

How Does FIPS 140-3 Differ from FIPS 140-2?

This distinction matters because NIST has set September 22, 2026 as the date when all FIPS 140-2 certificates move to the Historical List. After that date, FIPS 140-2 certificates can no longer support new federal acquisitions, though agencies may continue using validated modules in existing systems. The average CMVP validation process takes over 18 months from submission to certificate, according to SafeLogic's analysis of CMVP data. Organizations still on FIPS 140-2 face a mandatory transition with a lead time that has, for most vendors, already passed.

The key differences:

The shift from point-in-time to ongoing validation is the most operationally significant change. FIPS 140-2 treated validation as a point-in-time event with rigid change requirements. FIPS 140-3 introduces ongoing security requirements including continuous RNG health monitoring, pre-operational and conditional self-tests throughout the module's lifecycle, and stricter change management protocols. Every software update and configuration change must maintain compliance status, and entropy sources require ongoing output monitoring during operation.

For Kloudfuse customers, this is handled transparently. The validated module ships with every release, and the control plane managed by Kloudfuse ensures updates maintain compliance. Kloudfuse manages module updates to maintain FIPS validation status across releases; customers deploying vendor-supplied images do not need to perform separate re-validation.

Why Does "Embedded vs. Configured" Matter?

This is the central architectural distinction. Most vendors approach FIPS validation through one of three patterns:

Segment-limited FIPS. A FIPS-enabled agent or proxy covers one segment of the data path (typically TLS termination at the edge), leaving the rest of the platform outside the certificate's scope. Your data is encrypted in transit to the platform, but what happens inside the platform is a different story.

Opt-in configuration FIPS. The validated module exists but must be explicitly enabled, sometimes before first deployment, sometimes through a settings file. If the configuration step is missed, skipped, or incorrectly applied, the deployment runs without FIPS protection. The compliance claim depends on a configuration being correct, not on the architecture being secure.

Separate federal product tier. FIPS-validated cryptography is available only in a distinct product. The standard commercial platform doesn't include it. This creates a bifurcation in the product line: features ship first in the commercial tier and arrive later (if ever) in the federal tier.

Kloudfuse's approach: Certificates #5186 and #5209 cover the standard platform. Every commercial deployment ships with the validated cryptographic modules embedded in every container image. The C-based module (#5186) is configured to operate in Approved mode in all Kloudfuse platform images. The Java module (#5209) supports both approved and non-approved modes, with approved mode enforced through platform configuration. The cryptographic modules are always present in the images regardless of deployment configuration.

The distinction between "embedded" and "configured" is the difference between a compliance claim and a certified property of the architecture. An auditor asking "is this deployment FIPS-validated?" gets a different answer when the validation is inherent to the build versus dependent on a deployment-time configuration flag.

What Does This Mean for Regulated Industries?

Federal and Defense: For organizations operating under DoD mandates, CMMC Level 2 requirements, or agency-specific STIG policies, Kloudfuse 4.0 meets the baseline without additional remediation. The platform supports alignment with FedRAMP, with over 400 NIST 800-53 security controls addressed. Combined with STIG-hardened container images and SOC 2 certification, security review becomes a documentation exercise rather than a multi-quarter remediation project.

Kishore Thakur, Senior Director of Cloud Platform Engineering at Zscaler, described the operational impact: "With Kloudfuse 4.0's FIPS certification, we can take that same observability stack into regulated federal environments without maintaining a separate toolchain. That kind of consistency is a meaningful operational advantage at enterprise scale."

Healthcare: HIPAA requires appropriate safeguards for protected health information. When observability telemetry contains patient identifiers (which it often does, despite scrubbing efforts), FIPS-validated encryption addresses the cryptographic control requirements under HIPAA. Customers must still validate other controls (access, logging, policies) as required by their compliance program. Kloudfuse's VPC deployment model means patient telemetry data never leaves the customer's infrastructure, adding a data residency layer on top of the cryptographic protection.

Financial Services: Firms serving government agencies or operating under PCI DSS requirements need validated cryptography. FIPS-validated encryption addresses the cryptographic control requirements for these frameworks, though customers should verify overall control mappings against their specific compliance obligations. The combination of FIPS 140-3, VPC deployment, and comprehensive RBAC means the observability platform doesn't create a compliance gap in an otherwise hardened environment.

How Does FIPS Interact with the Self-SaaS Deployment Model?

Kloudfuse's Self-SaaS or BYOC model runs the data plane entirely in the customer's VPC while Kloudfuse manages the control plane. This creates defense in depth:

1. FIPS-validated cryptography protects data in transit and at rest

2. RBAC controls application-level access with label-based data policies

3. SSO/SAML integration handles authentication through the customer's identity provider

4. VPC deployment ensures telemetry data never transits public networks

5. Infrastructure-level controls from the customer's cloud provider add another security layer

Each layer addresses a different threat model. FIPS handles cryptographic integrity. RBAC handles authorization. VPC deployment handles data residency. The layers are independent, so a failure in one doesn't cascade to compromise the others.

What About the Supply Chain?

FIPS validation is one element of a broader supply chain security posture in Kloudfuse 4.0:

• Base images: Every container migrated to Red Hat UBI9-minimal, reducing the attack surface

• OS-level hardening: STIG compliance and FIPS crypto policy enabled at the operating system level across all services

• Image integrity: All container images and Helm charts are cryptographically signed; customers can verify integrity before a single pod runs

• Runtime security: Every service runs as non-root by default

• Credential management: OIDC federation support allows image pulls from AWS ECR without long-lived credentials

This is how the containers ship, not a post-deployment hardening guide that customers need to follow. The security posture is a build-time property, not a deployment-time activity.

CEO Pankaj Thakkar framed the design philosophy: "Enterprise buyers should not have to choose between strong security and operational simplicity. We built Kloudfuse 4.0 so that customers start with a security posture that meets the expectations of regulated environments, without being forced into a separate product or a more complex deployment model."

The Design Decision: Why Validate the Commercial Product?

The easier path would have been a separate federal product tier. It's what most vendors do because it isolates the compliance burden from the commercial release cycle. Feature development proceeds at full speed on the commercial product while the federal tier follows at its own pace.

We chose to validate the commercial product because the bifurcation creates real costs:

• Features arrive in the federal tier months or quarters late, creating capability gaps for regulated customers

• Engineering teams maintain two build pipelines, two test matrices, two release processes

• Customers who start on the commercial tier and later need FIPS face a product migration, not just a configuration change

• Security posture improvements in one tier don't automatically flow to the other

By validating the standard product, every customer gets the same security baseline. Regulated customers don't wait for features. Non-regulated customers get better security than they asked for. And the engineering team maintains one product, not two.

The tradeoff is velocity: every release must maintain FIPS validation, which adds testing requirements and constrains which cryptographic libraries can be used. We accepted this because security is not a feature that ships in a release. It's a property of the platform that must hold across every release.

Next Steps

The Kloudfuse security documentation covers the full security architecture including FIPS configuration, encryption details, and compliance certifications. For organizations evaluating FedRAMP alignment, the FedRAMP installation guide walks through the federal deployment configuration.

What's your team's experience with FIPS validation in your observability stack? We're hearing from more organizations that the September 2026 FIPS 140-2 deadline is creating urgency around vendor evaluation. We'd be curious to hear how that's affecting your timeline.