Decision Trees.

Start at the top with the question "What is the cryptographic operation?" If the system establishes a shared secret over a network — a TLS handshake, an IPsec key exchange, an SSH session — follow the left branch to ML-KEM (FIPS 203). If the system produces a signature — a TLS certificate, a JWT, a code-signing artifact, a firmware update — follow the right branch to a second question that distinguishes general-purpose signatures (ML-DSA) from conservative long-lived signing (SLH-DSA).

The right answer for most inventory rows is one of three. Mixed systems — a TLS endpoint also uses certificate signatures, an identity provider does both key exchange and JWT signing — get two or three rows in the inventory, one per cryptographic role, not one combined row.

Q1 · What is the cryptographic operation?
├── Key establishment
│   → ML-KEM (FIPS 203) · key encapsulation for TLS / VPN / SSH
│
└── Digital signature
    │
    └── Q2 · Long-lived or conservative role for the signature?
        ├── No — general-purpose (TLS cert, JWT, document)
        │   → ML-DSA (FIPS 204) · general signature
        │
        └── Yes — root CA / firmware / code-signing / long-lived
            → SLH-DSA (FIPS 205) · hash-based, conservative

Outcomes — at a glance

A single product often performs multiple cryptographic roles. A TLS terminator does both key establishment (ECDH-class) and signature verification (against the server certificate). An identity provider may issue JWTs (signature) and accept federated logins (signature verification). When that happens, the rule is: one inventory row per cryptographic role, not one combined row. Run the tree for each role independently.

How to handle the common collisions

• TLS endpoint with certificate signing. Two rows — one for the key exchange (ML-KEM via FIPS 203), one for the certificate signature (ML-DSA via FIPS 204).
• Code-signing CA chain. Two rows — one for the issuance signature (ML-DSA or SLH-DSA depending on lifetime), one for the verification path (matching).
• Hardware security module storing keys. Inventory the cryptographic operations the HSM performs, not the HSM itself. An HSM that signs releases is one row; an HSM that wraps key-establishment material is another.
• Symmetric primitives (AES, hashes). Out of scope for this tree. Symmetric ciphers are not directly broken by quantum computers — the migration is a key-size uplift, not an algorithm change. See the glossary entry on AES and the Grover's algorithm entry.

When SLH-DSA is the right call

• Root CA signing keys. Multi-decade lifetime; cascade risk if compromised; algorithm-diversity hedge against future lattice cryptanalysis is worth the size cost.
• Firmware update signing. Device fleets with 7–10+ year field life; verification path lives on devices that can't be easily updated.
• Code-signing for archival or long-lived binaries. Signed software whose verification surface extends past the CNSA 2.0 inflection (2027–2031).
• Anywhere algorithm diversity is an explicit policy requirement. SLH-DSA's security depends only on the hash function, which is a fundamentally different assumption from the lattice problems underlying ML-DSA.