Orchestrate validated modules, enforce approved algorithms.
FIPS 140-3 (superseding 140-2) defines cryptographic module requirements for U.S. federal agencies and most regulated industries. TigerTrust keeps operations inside validated modules and produces the operational evidence a FIPS-compliant deployment needs.
FIPS deployments fail on algorithm drift and unbounded keys.
The standard aligns with ISO/IEC 19790:2012. Approved algorithms are strictly scoped; key material must remain inside the validated module. Manual tooling and legacy CLM drift outside those boundaries constantly.
- Certificate templates permit SHA-1 or RSA-1024 by accident — auditor findings inevitable
- CA private keys exported for backup or migration — module boundary broken
- No audit trail proving cryptographic operations stayed inside the HSM
- Role separation between Crypto Officer and User exists in name only
- TPMs used without EK validation against the CMVP list
- Templates gate algorithms to FIPS-approved primitives at policy validation
- PKCS#11 delegation keeps CA keys inside the HSM boundary for their entire lifetime
- Every sign / key-gen operation logged with module identifier and principal
- Dashboard RBAC enforces distinct Crypto Officer and User roles
- EK trust bundle curated against the NIST CMVP validated module list
Only NIST-approved primitives in approved mode
AES, SHA-2, SHA-3, RSA (2048+), ECDSA (P-256/P-384/P-521), HMAC. Legacy primitives (MD5, SHA-1 for signatures, DES, RSA-1024) are rejected at policy validation before any signing operation.
- RSA-2048/3072/4096 and ECDSA P-256/P-384 for certificate keys
- SHA-256 or SHA-384 signature hashes
- Configurable per-template algorithm allowlist
- Rejections logged with structured failure codes
CA keys never leave the validated module
PKI Core connects to any PKCS#11-compliant HSM — Thales Luna, Entrust nShield, AWS CloudHSM, YubiHSM 2 — and delegates all sign / decrypt operations. The validation attaches to the module; TigerTrust keeps the key inside it.
- Thales Luna, Entrust nShield, AWS CloudHSM, YubiHSM 2 tested
- Per-CA HSM slot assignment
- Automated backup ceremonies that preserve module boundary
- FIPS-mode operating system support (RHEL, Ubuntu Pro FIPS)
FedRAMP Moderate/High and DoD Impact Levels
FIPS 140-3 is a hard prerequisite for FedRAMP Moderate/High authorization and DoD Impact Level 4+ workloads. NIST SP 800-53 SC-12, SC-13, and SC-17 all cite FIPS-validated cryptography.
- AWS CloudHSM in GovCloud for FedRAMP High
- Entrust nShield Solo XC for on-prem deployments
- IEEE 802.1AR DevID for DoDI 8520.03 device authentication
- CNSA 2.0 profile stacks cleanly on top for CNSSP-11 workloads
Everything a validated deployment needs, nothing that breaks the boundary.
TigerTrust is not itself a FIPS-validated module. It is the orchestration layer that keeps operations inside validated modules and produces the audit evidence auditors ask for.
- Thales Luna
- Entrust nShield
- AWS CloudHSM
- YubiHSM 2
- RSA-2048/3072/4096
- ECDSA P-256/P-384
- SHA-256 / SHA-384
- Legacy algorithm rejection
- Concurrent SHA-256 + SHA-384
- Per-fleet policy
- CNSA 2.0 alignment
- Timestamp + principal
- JSON + syslog export
- AU-2 evidence collection
- Approval workflows
- Least-privilege defaults
- Just-in-time elevation
- Infineon SLB 9670
- Nuvoton NPCT750
- Per-fleet EK allowlist
Control mapping: SP 800-53 to TigerTrust
The NIST SP 800-53 controls most-cited in FedRAMP and DoD FIPS-mode audits, mapped to the TigerTrust capability that produces the evidence.
| SP 800-53 control | Requirement | TigerTrust Capability |
|---|---|---|
| SC-12 | Cryptographic Key Establishment and Management | PKCS#11 HSM delegation keeps CA private keys inside a FIPS 140-3 validated module for their entire lifecycle. Automated key ceremonies and audit trail on every operation. |
| SC-13 | Cryptographic Protection | Template-level algorithm allowlist rejects non-approved primitives at policy validation. Multi-bank SHA-256 / SHA-384 attestation for higher-assurance workloads. |
| SC-17 | Public Key Infrastructure Certificates | Full private CA lifecycle with automated issuance, renewal, revocation, and CRL / OCSP publication. Per-CA templates for approved algorithm and validity profiles. |
| AU-2 | Event Logging | Every key generation, import, sign operation, and administrative action logged with timestamp, principal, and operation identifier. JSON + syslog export for enterprise SIEM. |
| AC-5 | Separation of Duties | Dashboard RBAC enforces distinct Crypto Officer and User roles matching the module operator separation FIPS 140-3 requires. Approval workflows sit above the module boundary. |
| CM-6 | Configuration Settings | Certificate templates and attestation policies are version-controlled configuration objects. Changes require dual-approval and are captured in the audit trail. |