How ML-DSA-87 Opens the Door to Government Contracts

Government contracts are decided by a written question long before anyone discusses price: which algorithm, at which parameter set? For post-quantum signatures the strictest buyers have already answered it. The NSA names ML-DSA-87 for every classification level of US national security systems. Australia's Signals Directorate prefers it and stops approving the smaller set after 2030. A vendor that stops at ML-DSA-65 can tell a commercial buyer it is post-quantum. It cannot give those buyers the answer their own rules ask for.

KXCO can, and the proof is on a public chain. At 08:37:11 UTC on 6 October 2026, at block 4,951,111, ML-DSA-87 verification became a rule of consensus on KXCO's chain. Twenty-eight seconds later the first ML-DSA-87 identity registered. Four seconds after that, its first attestation anchored, per the chain's public record. On 7 October KXCO moved its own platform signing keys to ML-DSA-87, and each key change is on the same chain. That is the door. This article explains why it opens, and what a government evaluator finds when they check.

Category 5 is the margin. The others are the compromise.

FIPS 204 gives three parameter sets of the same lattice signature. They are not settings on one key. A verifier accepts a signature only against the public key of the matching set, and key length is the tag.

• ML-DSA-44 (category 2): a 1,312-byte public key, 2,560-byte private key and 2,420-byte signature, per Table 2. The smallest, for constrained devices.

• ML-DSA-65 (category 3): a 1,952-byte public key, 4,032-byte private key and 3,309-byte signature, per Table 2. The commercial default.

• ML-DSA-87 (category 5): a 2,592-byte public key, 4,896-byte private key and 4,627-byte signature, per Table 2. The set CNSA 2.0 names and ASD prefers.

Category 2 is about a 128-bit classical margin, category 3 about 192-bit and category 5 about 256-bit, the widest the standard offers. NIST's own line is that "ML-DSA is believed to be secure, even against adversaries in possession of a large-scale quantum computer". The 87 set is that claim at full width. Going from 65 to 87 costs a third more on the public key and about 40 percent more on the signature. That is the price of the margin. KXCO paid it.

The buyers already picked 87

United States, national security systems. CNSA 2.0 is the NSA's suite for national security systems. Its FAQ does not say "ML-DSA". It says "ML-DSA-87 for all classification levels". That covers digital signatures "in any use case, including signing firmware and software". Key establishment on the same list is "ML-KEM-1024 for all classification levels", not the 768 set. The clock is written down too. From 1 January 2027, "all new acquisitions for NSS will be required to be CNSA 2.0 compliant unless otherwise noted". By 31 December 2030, "all equipment and services that cannot support CNSA 2.0 must be phased out unless otherwise noted". KXCO's chain went live on the named set 87 days before the 2027 date.

United States, civilian agencies and their suppliers. Executive Order 14412, signed on 22 June 2026, moves agencies' high value assets and "high impact systems to use PQC for digital signatures" by 31 December 2031. Section 6 carries it into procurement. Within 180 days the FAR Council "shall publish a proposed rule amending the Federal Acquisition Regulation". That rule requires "covered contractors" to meet NIST's FIPS by 31 December 2030, "including all applicable FIPS incorporating PQC compliant algorithms". The proposal falls due on 19 December 2026. From then the post-quantum question is no longer a line in a security questionnaire. It is a contract clause with a date.

Australia. The Signals Directorate's Information Security Manual.pdf) says: "When using ML-DSA for digital signatures, ML-DSA-65 or ML-DSA-87 is used, preferably ML-DSA-87." It adds that ML-DSA-65 "will not be approved beyond 2030", and that "The development and procurement of new cryptographic equipment, applications and libraries ensures support for the use of ML-DSA-87, ML-KEM-1024, SHA-384, SHA-512 and AES-256 by no later than 2030". Every Commonwealth system bought from now on is bought against that date.

United Kingdom. The National Cyber Security Centre takes the other side of the same standard. It "recommends ML-KEM-768 and ML-DSA-65 as providing appropriate levels of security and efficiency for most use cases", and says all the parameter sets suit "OFFICIAL-tier government information". Its migration timeline sets discovery and a plan by 2028, the highest-priority migration by 2031 and completion by 2035, and it tells organisations to "Communicate your needs to your suppliers."

Read together, the four rules split the market. The UK default is 65. US national security and Australia want 87. A supplier that sells across all three has to answer both, on the same system, without letting one pass for the other.

Exhibit 1. Each rule is quoted from its primary text and the build checks the quote. Each KXCO answer was read live when the figure was built: the packages on npm, the algorithms the relay accepts, the block on the chain.

How this opens the door to government contracts

A government evaluator does not take a vendor's word for its cryptography. They ask a short list of written questions, and each one is pass or fail before price is discussed. KXCO's answers are checkable from outside, without an account.

1. Which signature algorithm, at which parameter set? ML-DSA-87, FIPS 204 category 5, checked by every validator since block 4,951,111 on 6 October 2026. The same chain checks ML-DSA-65. A UK department at its default and a US national security buyer at the CNSA level use one system.

2. Can we check it ourselves? Yes. Sign a message with the public npm package, send it to the chain's public endpoint, and the chain answers 01. Flip one bit and it answers 00. The registration and anchor transactions are on the public explorer at chain.kxco.ai, and KXCO publishes its signing keys, each with its parameter set, at kxco.ai/.well-known/pq-keys.json.

3. Where does the private key live? kxco-pq-hsm generates the ML-DSA-87 key on a PKCS#11 hardware security module. The private object is marked non-extractable and sensitive, so the key never reaches the application. A 4,896-byte private key that leaves the module is just a bigger file to steal.

4. Can you trace the software you are selling us? The 13 npm packages that carry the category 5 level were released on 5 and 6 October, each with SLSA build provenance, which ties the published package to its public source and the build that produced it.

5. Do you run on it yourselves? Yes. On 7 October KXCO moved the keys that sign its platform identity, its deal room, its ontology engine, its mail and the articles on this site to ML-DSA-87. Each key change is a transaction on the chain, shown in Exhibit 2, and ML-DSA-65 signatures made before the change still verify.

6. When? Now. The chain went live 87 days before CNSA 2.0 applies to new national security acquisitions, and more than four years before the 2030 contractor deadline. A buyer opening a 2027 acquisition needs a supplier that is already live, not one with a roadmap.

Exhibit 2. Every key is read from KXCO's published key list and every key change from the chain's public endpoint when the figure was built.

Good means the check is in the path, not in the brochure

A library that can verify ML-DSA-87 is table stakes. The signature is only real if the system that stores the identity rejects a bad one. KXCO put the check in four places.

The chain. A verification precompile, a function built into the chain itself, checks every ML-DSA-87 signature during block validation. Its address is the ASCII for KXCO followed by 87. All four validators run it, and anyone who syncs the chain re-executes the check. Before any validator moved, an observer node ran the new software against 6,915 live blocks, including 47 real verification transactions, and found no difference in state, according to KXCO's rollout log. First registration: transaction 0xe78bd1e6, block 4,951,125. First anchor: transaction 0xd51255d5, block 4,951,127.

The key. kxco-pq-hsm creates the category 5 key on the token and marks it non-extractable. On a token that holds ML-DSA keys, the key stays in hardware.

The wire. The relay at relay.kxco.ai publishes the levels it accepts, and today that is ML-DSA-65 and ML-DSA-87. The contract decides the level from the length of the key, not from a field the caller sets. A 1,952-byte key cannot be submitted as category 5. That is the property that stops a downgrade dressed up as an upgrade.

The pair. kxco-post-quantum ships ML-KEM-1024, the category 5 key establishment CNSA 2.0 lists beside ML-DSA-87. A category 5 signature wrapped in a category 3 key exchange is a half upgrade. A buyer building to the suite gets both halves from one library.

Why it matters in a transaction

A transaction on KXCO's chain is the instruction that moves: register an institution, issue a credential, revoke it, anchor a document, rotate a key, authorise an agent. The relay takes the signed intent and submits it. Blocks come every two seconds, and a finalised block does not reorg. Whatever the signature was at that moment is what the record will say later.

That is why the parameter set belongs on the transaction, not on a certificate filed beside it. The signature is checked by every validator before the block is final. A bad category 5 signature is refused, and nothing is written. A category 3 key cannot be presented as category 5, because the level is the key length.

The cost is real. Per FIPS 204, a 4,627-byte signature on every intent is bigger than the 3,309-byte ML-DSA-65 signature the relay already accepted. On a system of record that is the right trade. A credential, a revocation or an audit anchor that a counterparty will reopen in five years should not hang on the parameter set the vendor found convenient.

Why it matters in the ontology

KXCO's ontology engine is the logic between an institution and the model it uses, and the ontology is the record it keeps. Documents, payments, trading and identity are not four systems. They are four fronts of one operation, and each answers to that record. A claim carries its source, its basis and the date it was true. Conflicting accounts stay side by side. They are not smoothed into one answer.

A record like that is only as good as the signature on the claim and the anchor on the correction. Anyone can edit a graph. The question an inspector general or an auditor will ask is who was allowed to add the node, who was allowed to dispute it, and whether that authority can still be checked after the analyst has left. The engine's own signing key moved to ML-DSA-87 on 7 October. The anchor goes to the chain. The record can show the dispute. It cannot quietly replace the signature.

The public map at kxco.ai/ontology-live is the same engine on open data. The private record is the one that matters: positions, holdings, counterparties, findings. Those claims outlive the meeting that produced them. Category 5 is the margin on a record someone will use to decide, and then have to defend.

Why it matters in the deal room

KXCO's deal room is where a member runs the deal: documents, contracts, signatures, negotiation and offers, through to settlement. Counterparties do not apply. A member tickets them into the room, and when the deal dies they leave. What the room learned exports into the ontology.

The signatures in that room are the deal: an offer, a markup, a guest's authority to read the pack, the instruction that settles. A data room that stores PDFs and calls the click a signature has nothing to show a counterparty in 2031 except a log. The deal room has a named identity, and its platform key has signed at ML-DSA-87 since 7 October, with the key change on chain at block 4,989,959.

A deal room is also where the downgrade hurts. A document signed at category 3 and described as category 5 is how a closing pack fails an audit. Key length stops that.

Why the extra bytes are worth it

ML-DSA-87 is a bad default for a leaf certificate verified a million times and thrown away. It is the right default for the objects KXCO keeps: an identity registration, an attestation anchor, a signature someone will re-check in 2032 and have to defend to an auditor who has read the suite.

On those objects the 4,627-byte signature, per FIPS 204, is a storage line. The 3,309-byte signature is a failed answer to a written question: which parameter set? The chain, the hardware key and the relay now give the answer the buyer already published. ML-DSA-65 remains for what was already signed and for buyers whose rules ask for it. New high-assurance objects take 87.

That is how ML-DSA-87 opens the door. The rules name the set. KXCO verifies it in consensus, signs its own platform with it, and lets any evaluator check the answer. Same hard problem as the smaller sets. Wider margin. Checked before the block is final. Impossible to fake with a shorter key. Live since block 4,951,111.

What to watch

19 December 2026, when the FAR Council's proposed post-quantum rule for federal contractors falls due under Executive Order 14412. 1 January 2027, when CNSA 2.0 applies to new US national security acquisitions. 2028, the NCSC's date for discovery and a migration plan. 2030, when ASD stops approving ML-DSA-65 and the US contractor deadline arrives.

Shayne Heffernan, Ph.D., is the founder of Live Trading News, the KnightsBridge Group, Knightsbridge Law and the KXCO.ai ecosystem spanning post-quantum cryptography, identity, attestation and enterprise ontology.