Operating the Istari Platform under FIPS 140-3

The core Istari platform supports customers operating undering a FIPS 140-3 requirement. By default, the core Istari platform always uses FIPS 140-3 compliant algorithms for its security-sensitive cryptographic operations out of the box.

Some customers have additional requirements to leverage FIPS 140-3 certified implementations of these algorithms, typically provided by the underlying operating system with a US-government issued validation certificate. This guide explains how a customer with such a FIPS 140-3 validated implementation requirement should deploy and operate the core Istari Digital Platform services together.

Scope

This guide covers the core platform: the Registry Service (including Remote Share), the web Frontend, the Python Client SDK, and the Istari Agent. The TypeScript/WebAssembly client, the MCP server, and specific tool integration modules are not in FIPS 140-3 scope today — see Limitations.

How Istari supports FIPS 140-3

Istari does not ship its own cryptographic module for FIPS validation. Instead, each core component is built so that its cryptography is performed by the FIPS 140-3 validated cryptographic module of the underlying platform — the OpenSSL FIPS provider on a FIPS-enabled Linux/RHEL host, or the Windows FIPS-validated modules under Windows FIPS policy.

This means FIPS compliance is a shared responsibility:

• Istari provides FIPS build variants of each component whose cryptography is compiled against (or defers to) the host's validated module.
• The customer provides a deployment environment that satisfies the module's conditions: FIPS-enabled host operating systems, FIPS-validated TLS termination at the network boundary, and FIPS-validated cryptography for the supporting data stores and identity services.

What every FIPS deployment requires

Regardless of which components you run, a FIPS 140-3 deployment requires:

1. FIPS-enabled host operating systems. Enable kernel FIPS mode on every host that runs an Istari service or agent (fips-mode-setup --enable on RHEL 9, or the Windows FIPS policy). This is what activates the validated cryptographic module the Istari software relies on.
2. FIPS-validated TLS termination. The Istari backend services do not terminate TLS themselves. Terminate inbound HTTPS at a FIPS-validated load balancer, ingress controller, reverse proxy, or service-mesh gateway.
3. FIPS-validated supporting infrastructure. Provide FIPS-validated TLS and cryptography at the boundary for the data stores and services the platform depends on — PostgreSQL, SpiceDB, the Zitadel identity provider, object storage, and any telemetry endpoints.
4. Deploy the FIPS build of each component, as described per-component below.

Component-by-component guidance

Component	FIPS support	What you must do	Notes
Registry Service	Supported	Deploy the published container image on a FIPS-enabled host; terminate TLS externally.	The base container image always operates in FIPS compatible mode.
Remote Share	Supported	Deploy the published container image on a FIPS-enabled host; terminate TLS externally.	The base container image always operates in FIPS compatible mode.
Frontend	Supported	Deploy the published static frontend image behind FIPS-validated TLS termination; do not modify it to terminate TLS itself.	Browser-owned crypto (login/PKCE, TLS) depends on the user's browser/OS FIPS configuration.
Python Client SDK	Supported	Install with the fips extra (pip install "istari-digital-client[fips]") and run on a FIPS-enabled host.	Inherits FIPS state from the host python installation.
Istari Agent	Supported (platform-dependent)	Install the -fips build (RPM/MSI) on a FIPS-enabled host and verify with --fips-check.	Full FIPS on RHEL 9, Ubuntu Pro, and Windows 11. No FIPS support on MacOS and best-effort on other linux and Windows distributions.

Registry Service and Remote Share

Both services ship as container images that are always FIPS-built (there is no separate non-FIPS variant), with their cryptographic dependencies compiled against the image's FIPS-validated OpenSSL. Deploy them on hosts with kernel FIPS mode enabled and terminate TLS at a FIPS-validated boundary.

Frontend

The frontend is a static web application served over plain HTTP inside your deployment boundary; it performs no customer cryptography in application code. FIPS compliance for the frontend comes from terminating its TLS at a FIPS-validated endpoint and from the backend services it talks to.

Browser-side cryptography

Login (OIDC/PKCE) and the browser's TLS connections use the browser and operating system's cryptographic modules, which are outside Istari's control. For a FIPS requirement, end-user workstations must themselves be configured to use a FIPS-validated module. The in-browser TypeScript/WebAssembly SDK is outside the FIPS boundary and must not be solely relied on in isolation for security operations.

Python Client SDK

Install the SDK with the fips extra so its cryptographic dependencies use the host's validated OpenSSL:

pip install "istari-digital-client[fips]"

No code changes are required. The SDK has no --fips-check of its own — verification of the runtime environment is the responsibility of the application that embeds it.

Istari Agent

tip

For customers who do not have a strict legal requirement to use FIPS 140-3 validated implementations in this product, we recommend using the standard agent builds. Standard builds use FIPS compliant algorithms and are comparably secure. They support more up-to-date patches on the underlying operating system kernel and do not require read access to link cryptographic libraries on deployment hosts, making them generally more secure and reliable than their -fips build counterparts.

Install the -fips build of the agent and confirm its posture with the built-in self-test:

istari_agent_<version> --fips-check

A zero exit code confirms the FIPS provider is loaded, the host's default OpenSSL properties require FIPS, and an end-to-end encrypt/decrypt round-trip succeeds.

Agent FIPS support depends on the host platform:

Platform	FIPS support
RHEL 9	Full — cryptography is built against the host's FIPS-validated OpenSSL.
Windows	Full — bundles the validated OpenSSL FIPS provider; enable Windows FIPS policy on the host.
Ubuntu	Full — defers to the host's OpenSSL, which must itself be FIPS-enabled (e.g. Ubuntu Pro FIPS).
macOS	Not a supported FIPS target.

tip

The agent's FIPS activation is best-effort: it will still run on a non-FIPS host rather than refusing to start. If you have a compliance requirement, run --fips-check after install and treat any non-zero result as a deployment misconfiguration to fix before going live.

Putting it together

A representative FIPS 140-3 deployment looks like this:

• Control plane — the Registry Service, Remote Share, and Frontend images run on FIPS-enabled hosts, behind a FIPS-validated ingress/load balancer that terminates TLS. Backend services require FIPS at startup.
• Supporting services — PostgreSQL, SpiceDB, Zitadel, and object storage are reached over FIPS-validated TLS, and are themselves deployed in FIPS-compliant configurations.
• Agents — run on FIPS-enabled RHEL 9 or Windows hosts using the -fips agent build, verified with --fips-check.
• Automation / SDK users — install istari-digital-client[fips] on FIPS-enabled hosts.

In this configuration, data in transit is protected end-to-end by FIPS-validated TLS, and the cryptography each Istari component performs is carried out by the host's FIPS 140-3 validated module.

Verifying FIPS is active

Layer	How to verify
Host	fips-mode-setup --check (RHEL), cat /proc/sys/crypto/fips_enabled (Linux), or the Windows FIPS policy registry value.
Registry / Remote Share	Run the service's bundled fips_check.py inside a running container; it exits 0 only when the FIPS provider is active and a crypto round-trip succeeds.
Agent	istari_agent_<version> --fips-check.
Python SDK	Verified through the embedding application and the host checks above.

Limitations and out of scope

• TypeScript / WebAssembly client — not supported; no WebAssembly FIPS module exists. Do not use it in isolation for security operations (e.g. in a nodejs backend application). Data security relies on the host configuration and backend validations.
• MCP server — not currently supported under strict FIPS certification requirements. Uses FIPS compliant cryptography but cannot guarantee attestation for libraries.
• Integration modules — the tool-specific modules executed by the agent are not currently in FIPS 140-3 scope. Evaluate any module's own data handling separately against your requirements.
• macOS agents and non-Pro Ubuntu agents — not suitable for strict FIPS attestation; use RHEL 9 or Windows.
• End-user browsers and workstations — their cryptography is the customer's responsibility and must be configured for FIPS independently.

note

FIPS support is evolving across the platform. Confirm the current status of any specific component with your Istari representative before finalizing a compliance deployment, and re-verify with the checks above after each upgrade.