Post-quantum-ready PKI, deployable today.
NSA's Commercial National Security Algorithm Suite 2.0 mandates post-quantum-ready algorithms for national-security systems by 2035. SHA-384 across the board, ML-KEM for key encapsulation, ML-DSA for signatures, hybrid certificates during transition. TigerTrust gives you the runway.
The 2035 deadline is a decade of engineering work.
Migration is a multi-year programme. Firmware signing keys go first because signatures produced today outlive the classical algorithm. Web TLS goes later because it rotates every 90 days anyway. Without runway, you get a big-bang cutover — and things break.
- No inventory of which workloads use RSA-2048 vs ECDSA vs SHA-256
- Long-lived firmware signing keys still on classical algorithms
- Certificate templates locked to classical algorithms — no PQC issuance path
- Attestation policy only checks SHA-256 PCR bank; CNSA-scope workloads can't pass
- Big-bang migration risks breaking every relying party at once
- Discovery inventories every certificate by algorithm and key length
- Hybrid certificate templates issue classical + ML-DSA keys concurrently
- Progress dashboards track PQC readiness per CA, template, and workload
- Multi-bank SHA-384 attestation for CNSA-scope hardware-rooted workloads
- Phase-by-phase migration sequenced by actual risk, not guesswork
Hybrid PQC certificate issuance
Issue certificates carrying both a classical (ECDSA P-384) and a post-quantum (ML-DSA) key, so relying parties on either side of the transition can validate them. Templates gate the algorithm profile per environment.
- ML-KEM (Kyber) Level 5 for key encapsulation — FIPS 203
- ML-DSA (Dilithium) Level 5 for signatures — FIPS 204
- LMS or XMSS for software / firmware signing — SP 800-208
- Classical fallback maintained through cutover
Algorithm inventory across the estate
Automated discovery scans TLS endpoints, certificate stores, and code-signing artefacts and reports the signature and key-exchange algorithms in use. Filter by algorithm to see exactly which workloads still rely on RSA-2048 or SHA-256.
- Per-certificate algorithm and key-length reporting
- Filter workloads by signature algorithm
- Long-lived signing key identification (code / firmware)
- Baseline dashboards for programme reporting
Track PQC readiness per CA and template
Progress dashboards show percentage of certificates on approved algorithms. Policy engine enforces "no new issuance below SHA-384" at a chosen cut-over date. Phased rollout keeps you in control.
- Per-CA and per-template readiness scoring
- Policy engine enforces algorithm minimums at issuance
- Programmatic cutover dates
- Rollback windows if relying-party support isn't ready
Multi-bank SHA-384 attestation
For hardware-rooted CNSA 2.0 workloads, TPM attestation policy can require a SHA-384 PCR bank concurrent with (or instead of) SHA-256 — aligned with NIST SP 800-131A transitions.
- SHA-256 + SHA-384 concurrent PCR banks
- Configurable per fleet or device type
- Evidence.AdditionalQuotes[] for verifier consumption
- Documented failure codes when a bank is missing
From discovery to PQC-only, in stages.
The phases are cumulative — earlier phases keep running while later ones start. Firmware and code signing move first because those signatures outlive the classical algorithm.
- Cloud + on-prem discovery agents
- Per-workload algorithm scorecard
- Baseline for progress reporting
- Mission-critical NSS scope
- Long-lived signing key surfacing
- Risk-based sequencing
- Classical + ML-DSA per cert
- Per-CA rollout toggles
- Relying-party validation
- Attestation policy flip
- Firmware signing to LMS / XMSS
- Policy-enforced minimums
- Re-issuance of remaining classical creds
- Continuous scanning for drift
- Final PQC compliance sign-off
Algorithm mandate: CNSA 2.0 to TigerTrust
The approved algorithm set as published in the CNSA 2.0 Cybersecurity Advisory (NSA, September 2022) and its subsequent NIST FIPS finalisations. Note the SHA-384 mandate — SHA-256 is not permitted for signature or key-derivation in CNSA-scope national-security systems.
| CNSA 2.0 purpose | Requirement | TigerTrust Capability |
|---|---|---|
| Symmetric encryption | AES-256 per FIPS 197 | Enforced at template validation. TLS profiles configurable per certificate template to reject weaker symmetric primitives on the wire. |
| Hashing | SHA-384 or SHA-512 per FIPS 180-4 | Template-level hash algorithm allowlist. Multi-bank SHA-384 PCR attestation available for hardware-rooted workloads. |
| Key encapsulation | ML-KEM (Kyber) Level 5 per FIPS 203 | Hybrid certificate templates carry classical + ML-KEM public keys concurrently. Full support pending relying-party ecosystem readiness. |
| Digital signatures | ML-DSA (Dilithium) Level 5 per FIPS 204 | Hybrid certificate templates issue classical + ML-DSA signatures. Per-CA rollout toggles for phased cutover. |
| Software / firmware signing | LMS or XMSS (stateful hash-based) per SP 800-208 | Code-signing pipelines support LMS and XMSS for firmware artefacts with signatures that outlive the classical algorithm. |