An AI halved HAWK's security in about 60 hours this week, and NIST pulled it. If you were eyeing HAWK — it was pitched as a faster, floating-point-free Falcon — that plan is dead. But the useful question the withdrawal leaves behind isn't philosophical. It's operational: which post-quantum signature do I build on now?

There are three real answers, and picking between them is genuinely a decision — not a matter of "the best one." Here's the whole thing in one screen, then the reasoning.

Default to ML-DSA. Switch to SLH-DSA when you need conservative, decades-long assurance. Reach for Falcon (FN-DSA) only when signature size is the binding constraint and you have crypto expertise — and even then, wait for FIPS 206.

ML-DSA (FIPS 204): the default, and you'll rarely regret it#

ML-DSA — the algorithm formerly known as CRYSTALS-Dilithium — is a module-lattice scheme finalized in FIPS 204 in August 2024. It signs fast, verifies fast, and its signatures land in a reasonable ~2.4–4.6 KB depending on parameter set. Constant-time reference implementations exist and have been widely reviewed.

For almost everything a founder ships — signing API responses, session tokens, software releases, documents, webhooks — ML-DSA is the right first choice. It is boring in the way you want your cryptography to be boring. The only reasons to move off it are a hard size constraint (see Falcon) or a demand for a more conservative security assumption (see SLH-DSA). If you don't have one of those, stop reading and ship ML-DSA.

SLH-DSA (FIPS 205): when you want to trust as little as possible#

SLH-DSA (formerly SPHINCS+) is the hedge. Its security rests only on the strength of hash functions — no lattice assumption, no number-theoretic gamble. Hash functions are the most scrutinized primitives we have, which makes SLH-DSA the scheme you reach for when the signature has to be trustworthy for a very long time and is expensive to change: firmware signing, secure-boot roots of trust, code-signing keys you can't easily rotate.

The bill comes due in size and speed. Signatures run roughly 8–50 KB depending on the parameter set, and signing is slow. That's fine for a firmware image signed once; it's a disaster for a service signing thousands of requests a second. Note the public keys are tiny (~32–64 bytes), so if your bottleneck is key distribution rather than signature transport, the calculus can shift. Use SLH-DSA where the assumption matters more than the bandwidth.

FN-DSA / Falcon (draft FIPS 206): small, sharp, and not ready#

Falcon — headed for standardization as FN-DSA in FIPS 206, expected 2026–2027 — wins on size: the smallest signatures (~0.7–1.3 KB) and small keys of the three. That's why it's attractive for constrained links: embedded devices, blockchains, tight protocol headers.

Two cautions, both load-bearing. First, it isn't finalized — building production dependencies on a draft standard is how you end up rewriting later. Second, and more important, Falcon is hard to implement safely. Its signing uses floating-point Gaussian sampling, a well-documented source of side-channel leaks and non-constant-time bugs. This is not a "roll your own" scheme. When FIPS 206 lands, adopt it through a vetted, hardened library — and until then, treat it as a plan, not a dependency. (The irony isn't lost on anyone: HAWK existed largely to give you Falcon-class sizes without the floating-point pain. Now HAWK is gone and the pain is back on the table.)

The rule, and the meta-lesson#

The decision compresses to one line: ML-DSA by default; SLH-DSA for conservative long-lived assurance; Falcon only when size is the constraint and you have the expertise. Most teams should run a hybrid during the transition — a classical signature (ECDSA/RSA) alongside a PQC one — so a break in either alone doesn't sink you, and migrate the long-lived keys first. The June 2026 executive order puts a real clock on it for anyone touching federal systems: digital signatures migrated by 2031.

And notice what this week actually demonstrated. The AI-assisted cryptanalysis that killed HAWK landed on an on-ramp candidate — a scheme with far less scrutiny than the finalized standards — not on ML-DSA or SLH-DSA. That's not luck; it's the process telling you where the thin ice is. The finalized standards survived a decade of the world's cryptographers and now the first serious wave of machine-assisted attacks. When you pick, pick from the schemes that have taken the most punches. Right now that's ML-DSA and SLH-DSA.