FIPS
Everything a FIPS-mode deployment needs to know, in one place: what Exaba’s FIPS posture is, who provides which part of the compliance story, and the decisions and steps that must happen. Most of them happen before installation.
When FIPS applies
FIPS 140 validation is a NIST and US-federal requirement. It binds deployments under FedRAMP, FISMA (NIST 800-53 SC-13), DoD / CMMC, and contracts that inherit those, along with analogous schemes in other jurisdictions. If no such framework applies to the deployment, FIPS mode is optional, and skipping it avoids the constraints below.
Exaba’s posture
Exaba is FIPS-compatible, not FIPS-certified. The platform detects and runs cleanly under a FIPS-mode kernel, and its cryptography uses FIPS-approved algorithms throughout: AES-256-GCM for object encryption, RSA-2048 OAEP for vault passphrase protection, and TLS through the AWS-LC cryptographic library. Exaba itself carries no FIPS 140 certificate. The validated modules in a deployment come from the layers below and beside it:
| Layer | Who provides it |
|---|---|
| Kernel and system cryptography | Rocky Linux 10 in FIPS mode, enabled by you at OS install |
| Disk encryption (LUKS) | The FIPS-mode installer, which derives keys under FIPS rules |
| Hardware key modules | You, with FIPS-validated parts (see below) |
| Application behavior | Exaba, which runs FIPS-compatible on top of the above |
What must happen, and when
-
Enable FIPS at OS install. There is no later. On Rocky Linux 10,
fips=1on the installer’s kernel boot line is the only supported mechanism. It must be active during the OS install itself, because the keys generated at install time (the LUKS volume keys) are otherwise not compliant. EL10 removed thefips-mode-setuptool, because a switch after installation has subtle faults, and the algorithm and key choices are fixed by then. A host installed withoutfips=1must be reinstalled. You cannot convert it. The boot-line steps are in Site Preparation → Operating System. -
Before any key exists. FIPS must be active before Exaba generates any key or certificate: mTLS certificates, KMS material, LUKS volume keys, and SSH host keys. Keys created outside FIPS mode are not retroactively compliant. The only fix is to destroy them and issue them again.
-
SSH key types are restricted. A FIPS-mode host rejects Ed25519. Use a NIST-approved type for the bootstrap key, ECDSA P-521, generated after you enable FIPS.
-
Hardware keys must be the validated parts. A YubiKey-backed vault passphrase needs the YubiKey 5 FIPS Series. The standard 5 Series performs the same operations, but it is not FIPS-validated. For a TPM-backed passphrase, check the certification of the specific TPM module. It varies by server vendor. See Site Preparation → KMS Vault.
-
Verify on every host:
cat /proc/sys/crypto/fips_enabled # -> 1
What to tell an auditor
- FIPS-approved algorithms are used platform-wide. The FIPS-validated modules are those of the OS (Rocky in FIPS mode) and of the hardware (FIPS-series keys, certified TPMs).
- Exaba runs as an application on that validated base, and claims no FIPS 140 certificate of its own.
- The wider control story (auditability, hardware-rooted key management, zero-trust mTLS) is covered in SOC 2 and Zero Trust Architecture.
FIPS-mode requirements also influence hardware selection. If FIPS applies, engage Exaba for a sizing review before ordering (see Hardware Sizing).