The keys you can never re-key
Somewhere in your estate is a signing key you cannot realistically rotate: the root that signs firmware for a deployed fleet, the internal CA that anchors years of issued certificates, the signer behind archives that must still verify decades from now. Today that key is almost certainly ECDSA or RSA - which means its trust has an expiry date you do not control, and the mandates are not waiting for the machine that sets it: Executive Order 14412 (June 2026) already fixes federal signature deadlines at 2031.
SLH-DSA is the signature standard built for exactly those keys. On QNSI it is not a migration project - it is one API call, or one policy setting. Sixty seconds of theory, then the practice.
SLH-DSA in 60 seconds
SLH-DSA (FIPS 205, finalized by NIST in August 2024, formerly SPHINCS+) is a stateless hash-based signature. Its security rests on a single assumption: the hash function holds. No lattice problem, nothing exotic underneath - the narrowest, oldest, most-scrutinized bet in cryptography. ML-DSA (FIPS 204) bets on lattices; SLH-DSA bets only on hashes. For a root that must outlive whatever cryptanalysis does next, the narrower bet is the safer one.
Stateless is the load-bearing word. The older hash-based schemes, LMS and XMSS, force the signer to track a counter forever - one restored backup or cloned VM and signatures can become forgeable. SLH-DSA has no state to lose: replicate the key across regions and recovery sites without ceremony.
The cost is size and speed: signatures run roughly 8 KB to 50 KB depending on parameter set (twelve of them - SHA2 or SHAKE, three security levels, fast or small), and signing takes milliseconds. For per-request JWTs that is the wrong tool; use ML-DSA. For artifacts you sign once per release and verify for years, the cost disappears next to the payload.
Where SLH-DSA earns its bytes
- Code-signing and firmware-update roots - a forged update is the catastrophic failure, and the fleet cannot be re-keyed overnight.
- CA hierarchies and root certificates whose trust chains run for years to decades.
- Archival and audit signatures - legal, medical, and government records that must verify long after today's lattice analysis has aged.
- Government and highest-assurance mandates that require FIPS-finalized, conservative-assumption algorithms.
- A diversity hedge beside ML-DSA - a different mathematical family, so no single break reaches both.
Per-key: one call on QNSI
On QNSI, SLH-DSA is one of 63 signature algorithms in an 87-algorithm catalog (24 KEMs, 13 families), created through the same KMS call as everything else - available from the Free Forever tier, not gated behind an enterprise plan. Choose the 256s variants for the smallest category-5 signatures, or 256f where signing speed matters more.
// pnpm add @heossihq/qnsi - free API key at cloud.qnsi.heossi.com
import { QnsiClient } from "@heossihq/qnsi";
const qnsi = new QnsiClient({ apiKey: process.env.QNSI_API_KEY! });
// SLH-DSA-SHA2-256s (FIPS 205): category-5 security, hash-only
// assumption, smallest level-5 signatures - built for signing roots
const root = await qnsi.kms.createKey({
keyType: "data",
algorithm: "sphincs-sha2-256s-simple",
purpose: "firmware-signing-root",
});
const signature = await qnsi.kms.sign(root.keyId, artifactBytes);
// Signing is rare; verification stays cheap - for decadesSource defines key unsealing, zeroization, audit, and 8 capability-gated custody connectors. Complete execution and event coverage remain NOT VERIFIED. The current escrow route is not threshold recovery and is not presented as available.
Per-policy: make conservatism the default, not a discipline
Engineers choosing good algorithms is a hope; policy is a control. QNSI crypto policy tiers pin the allowed algorithm set per tenant, enforced at key creation and key use. The strict tier admits the category-5 SLH-DSA-256 variants - SHA2 and SHAKE, both f and s - alongside ML-DSA-65 and ML-DSA-87. Maximum and government pin the most conservative sets, and government admits FIPS-finalized signatures only, which excludes draft FN-DSA by construction.
Since July 2026, crypto-policy changes are dual-controlled - maker-checker approval, so requester and approver can never be the same person. The policy guarding your firmware root cannot be quietly weakened by one compromised account. That is the difference between a documented standard and an enforced one.
Verify our SLH-DSA before you trust it
Every QNSI signing operation runs on the native liboqs engine, and the 18 FIPS algorithms shared with the independent noble implementation are cross-verified - two codebases must agree before a result is trusted. The conformance evidence is public and live: official NIST ACVP vectors at qnsi.heossi.com/verify/conformance, re-runnable by you, no account required.
To be precise about what that is: we run and publish the official NIST test vectors so you can check them yourself. It is not a NIST certification, and we never present it as one. It is something an engineer can act on faster - the vectors and the outputs, in the open.
The root does not live alone
Around the key, QNSI source defines audit chaining, CBOM discovery, vault lifecycle, and compliance-evidence packaging. Complete signing-root event coverage, connector execution, PQC envelope behavior, report availability, and auditor acceptance remain separate evidence questions.
Start now
Create a Free Forever workspace at https://cloud.qnsi.heossi.com/auth?mode=signup and mint your first SLH-DSA key in the next ten minutes - developer plans start at $149/month when you outgrow it. Planning a fleet-wide signing migration? Talk to an architect at /contact.