On September 21, 2026, every FIPS 140-2 certificate on the NIST Cryptographic Module Validation Program list moved to historical status. Not deprecated. Not discouraged. Historical. After that date, federal agencies will no longer be able to use those certificates to justify new acquisitions.

This is not a gradual sunset. It is a hard cutover. And for any organization that relies on FIPS 140-2 compliant observability tools today, which includes a significant portion of the federal IT landscape, along with healthcare, financial services, and defense contractors operating under NIST-derived frameworks, it means a mandatory transition to FIPS 140-3 validated modules is already underway.

The challenge is that most observability platforms have not completed that transition. Some are still on FIPS 140-2. Some offer FIPS as a configuration option rather than a validated property. Some do not have FIPS at all. And the CMVP validation process itself now averages 542 days from submission to certificate, which means any vendor that has not already submitted is unlikely to complete validation before the deadline.

This guide covers what FIPS 140-3 requires, how each major observability platform handles cryptographic compliance today, and what procurement and security teams should evaluate before September.

The Industry Reality: How Observability Platforms Handle FIPS Today

To understand the significance of FIPS 140-3, it helps to look at how cryptographic compliance is handled across the observability landscape today. Most platforms fall into one of three categories.

Category 1: FIPS-Enabled Configurations

The most common approach is to offer FIPS-enabled configurations. In this model, the platform itself does not contain a validated cryptographic module. Instead, it relies on the underlying operating system, a JDK provider, or an external cryptographic library to supply FIPS-compliant encryption.

• Datadog offers a dedicated FIPS Agent that uses FIPS 140-2 validated cryptographic modules (Certificate #4282) to encrypt payloads before forwarding them to Datadog's infrastructure. This agent is available in the US1-FED region and supports FedRAMP Moderate-certified monitoring. However, the FIPS compliance is scoped to the agent layer and specific integrations, not the full platform stack. Telemetry data is encrypted by the agent before it leaves the customer's environment, but the platform that receives, stores, processes, and serves that data runs on Datadog-hosted infrastructure. The FIPS boundary ends at the agent.

• New Relic provides FIPS 140-2 compliant encryption in AWS US and EU regions, available on request. Their FedRAMP-authorized environment requires an Enterprise edition with the Data Plus option. FIPS compliance is delivered through key management using validated cryptographic modules on the server side. Like Datadog, this is a hosted model: telemetry leaves the customer's infrastructure and is processed within New Relic's cloud.

• Elastic takes a different path. Elasticsearch can be configured to run in a FIPS 140-2 or FIPS 140-3 compliant mode within a JVM that has a FIPS-certified security provider installed, such as Bouncy Castle's FIPS libraries. However, Elastic's own documentation states explicitly that Elasticsearch itself does not contain a validated cryptographic module. The responsibility for installing, configuring, and maintaining a compliant provider falls entirely to the deploying organization. This capability also requires a Platinum subscription.

• Grafana does not ship with native FIPS validation. For regulated deployments, organizations typically rely on third-party FIPS-validated container images, such as those from Chainguard, to run Grafana components with compliant cryptography. Building a full FedRAMP-compliant Grafana stack requires significant modifications across the entire deployment.

Category 2: Partial FIPS Support

• Splunk Enterprise supports both FIPS 140-2 and FIPS 140-3 modes through a configuration file edit at install time. However, FIPS mode must be enabled before the first startup. It cannot be retroactively applied to an existing deployment without reinstalling. The underlying OS must also be running in FIPS mode, and any Splunk apps on the instance must be independently certified to run without dependencies on algorithms that FIPS disables, such as MD5 and RC4. While FIPS is technically available, deploying and maintaining a FIPS-compliant Splunk environment requires careful planning, specialized configuration, and ongoing operational overhead.

Category 3: Native FIPS-Validated Cryptographic Modules

Very few observability platforms ship with a natively embedded, FIPS-validated cryptographic module. This is the highest bar: the platform itself contains a module that has been independently tested by an accredited laboratory and validated by NIST through the CMVP process.

With Certificate #5186, Kloudfuse is in this category. The cryptographic module, powered by SafeLogic's CryptoComply library, is embedded directly into the platform. It covers AES, SHA-2, RSA, ECDSA, HMAC, DRBG, and KDF algorithms per NIST SP 800-series specifications. Organizations deploying Kloudfuse do not need to source, configure, or maintain external cryptographic providers. Validated encryption is a built-in property of the platform from the moment it is deployed.

Side-by-Side Comparison

What Changed from 140-2 to 140-3

FIPS 140-3 is not a minor revision. It is a structural change in how cryptographic modules are tested, documented, and validated. Understanding these differences matters because they explain why the transition is taking so long and why many vendors are not yet certified.

• Testing standard: FIPS 140-2 used a single derived test requirements document. FIPS 140-3 is based on ISO/IEC 19790 and ISO/IEC 24759. The testing is more rigorous, the documentation requirements are substantially heavier, and the lab evaluation process takes longer. This is the primary reason NIST's average validation time increased from 367 days under 140-2 to 542 days under 140-3.

• Module boundaries: 140-3 requires clearer definitions of the cryptographic boundary. Software modules must explicitly define what is inside the boundary and what is outside. For observability platforms, this determines whether encryption is validated at the agent level, the platform level, or both. A module that only covers the agent leaves the platform's internal communication, storage encryption, and authentication tokens outside the validated boundary.

• Self-tests: 140-3 mandates pre-operational self-tests and conditional self-tests. The module must verify its own integrity before processing data. If a self-test fails, the module must enter a degraded mode that prevents the use of compromised algorithms. This is a runtime enforcement mechanism, not a build-time or install-time check.

• Algorithm requirements: 140-3 narrows the set of approved algorithms and strengthens key length requirements. Algorithms that were acceptable under 140-2 may not be approved under 140-3, which is why Splunk requires that all apps on a FIPS-mode instance be independently verified for algorithm compatibility.

What Procurement and Security Teams Should Evaluate

The FIPS certificate number is the starting point, not the finish line. Here is what we believe matters when evaluating an observability platform for a regulated environment.

Scope of validation

Is the cryptographic module validated at the agent level, the platform level, or both? An agent-level FIPS certificate means data is encrypted on the way out of your infrastructure. It says nothing about encryption at rest within the platform, between internal components, or at the storage layer. Our FIPS 140-3 module (SafeLogic CryptoComply, Certificate #5186) is embedded in the platform itself. Every cryptographic operation — data in transit between components, data at rest in storage, authentication tokens, session management — passes through the validated module.

Data residency

Where does your observability data live after collection? With SaaS observability vendors, the answer is their infrastructure. Their cloud. Their region. Their security posture. With Kloudfuse's Self-SaaS model, the platform runs in your VPC. Every log, metric, trace, profile, and AI workload telemetry record stays inside your network boundary. There is no external data path. For organizations subject to data classification requirements, ITAR restrictions, or data sovereignty mandates, this distinction is not a preference. It is a compliance requirement.

Supply chain integrity

Can you verify that the container images and Helm charts you deploy have not been tampered with? We sign all container images and Helm charts. OIDC federation supports credential-free image pulls from AWS ECR, eliminating long-lived secrets. Images can be mirrored to internal registries for air-gapped environments where no external network path exists.

Runtime security posture

Do the platform's containers run as root? Most observability platforms do not disclose this in their documentation. All Kloudfuse services run as non-root users by default, with configurable service accounts and security contexts via Helm values. In a FIPS environment where the platform handles encrypted data at rest, a compromised root container means key access. Non-root by default eliminates that attack path.

AI workload considerations

This is the evaluation criterion that did not exist two years ago. As organizations deploy large language models, AI agents, and multi-step model pipelines into production, observability platforms are increasingly processing a new category of sensitive operational data: LLM request and response telemetry, token-level performance metrics, agentic workflow traces, and model inference logs. This data often contains sensitive information about model behavior, internal system architecture, and in some cases the data that models are processing. Ensuring that this telemetry is protected by validated cryptography is not an edge case. It is rapidly becoming a core requirement for any organization deploying AI in regulated or security-sensitive environments.

The Risk of Waiting

September 2026 is six months away. In federal procurement, six months is not six months.

A typical evaluation cycle for a new observability platform runs 3-4 months: vendor briefings, technical evaluation, security review, Authority to Operate documentation. If a migration from an existing platform is also required, add 2-3 months for data migration, dashboard recreation, alert configuration, and team training. For organizations with formal change management processes, add another review cycle.

That means if your current vendor's FIPS 140-2 certificate is going historical and they do not hold a 140-3 certificate today, your window to evaluate, select, deploy, and validate an alternative is already compressed. Every month of delay makes the timeline harder.

And if your vendor has not yet submitted for 140-3 validation, the math is definitive. At 542 days average validation time, a submission today would not yield a certificate until late 2027. The September 2026 deadline is not moving.

When to Act

If any of the following apply to your organization, the FIPS 140-3 transition directly affects your observability infrastructure:

• Your current observability vendor holds a FIPS 140-2 certificate but not 140-3

• Your vendor's FIPS support is scoped to the agent layer, not the full platform

• Your observability data leaves your network boundary under a SaaS model

• You are approaching a contract renewal with a SaaS observability vendor within the next 12 months

• You are deploying AI or LLM workloads that generate sensitive telemetry

• Your next federal audit, ATO renewal, or CMMC assessment is scheduled before December 2026

If none of these apply, this transition may not affect you directly. If even one does, the evaluation should start now. The window is closing, and the vendors who have completed the work already have certificates. The vendors who have not are asking you to wait.

The Bottom Line

FIPS 140-3 is no longer a future requirement. It is a present requirement with a six-month grace period. The transition from 140-2 to 140-3 is not a version bump. It is a structural change in testing, documentation, and runtime enforcement that most observability vendors have not yet completed.

Observability platforms collect some of the most sensitive operational data in modern infrastructure: error logs with stack traces, distributed traces showing every service-to-service interaction, user session recordings, application profiles, and increasingly, LLM prompts and model outputs. The cryptographic module that protects this data should not be an aftermarket configuration, an agent-level patch, or a customer-managed JVM library.

It should be a certified, validated, embedded property of the platform. That is what FIPS 140-3 was designed to ensure. And that is what Certificate #5186 delivers.

Secure observability is not a feature. It is an architecture.

Kloudfuse runs in your VPC. FIPS 140-3 certified. Signed containers. Non-root by default. Your data never leaves.