KXCO Makes ML-KEM-1024 Its Default, Completing the CNSA 2.0 Algorithm Pair

KXCO has made ML-KEM-1024 the default for new keys and new encryption across its post-quantum packages and its file vault at pqc.kxco.ai. Its signing keys moved to ML-DSA-87 earlier in October. Together these are the two parameter sets the US National Security Agency names in its Commercial National Security Algorithm Suite 2.0 (CNSA 2.0): "ML-KEM-1024 for all classification levels" and "ML-DSA-87 for all classification levels".

Data and keys made with the earlier ML-KEM-768 default keep working. Every release that changed a default was tested against the earlier releases from npm, and the results are in Exhibit 2.

What changed on 10 and 11 October 2026

ML-KEM is the NIST standard for key establishment, published as FIPS 203. It is the step that agrees the secret protecting a file or a connection. ML-KEM-768 sits in NIST Security Category 3. ML-KEM-1024 sits in Category 5, the highest. Under FIPS 203, an ML-KEM-1024 public key and ciphertext are each 1,568 bytes, against 1,184 and 1,088 bytes for ML-KEM-768.

• kxco-pq-vault 2.0.0, KXCO's file and envelope encryption, generates ML-KEM-1024 keys by default. Its README states the rule plainly: "New keys made with kxco-pq-vault use ML-KEM-1024 (FIPS 203, Category 5); ML-KEM-768 keys made earlier keep decrypting."

• kxco-pq-tls 2.0.0, KXCO's encrypted channels for Node streams and WebSockets, opens every new connection with ML-KEM-1024 combined with X25519. The opening message grows from 1,218 to 1,602 bytes.

• kxco-pq-hsm 1.8.0 holds ML-KEM-1024 keys in hardware through PKCS#11, and kxco-pq-sdk 2.4.1 passes them through its audited key interface.

• kxco-post-quantum 1.11.0, the core library, leads its documentation with ML-KEM-1024. Its ML-KEM-768 interface keeps its meaning, so no existing caller changes behaviour without asking.

• kxco-pq 3.0.0 installs the whole stack at those versions, and kxco-pq-scan 1.3.1 lists ML-KEM-1024 in the cryptographic bill of materials it produces.

• Since 01:47 UTC on 11 October 2026, every file uploaded to pqc.kxco.ai is sealed to an ML-KEM-1024 key before it reaches storage. The key that sealed earlier uploads is kept for decryption.

Why the pair matters to institutions and government

NSA's timetable for national security systems is fixed. Its CNSA 2.0 guidance says that 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". NSA adds that "NSA intends that all NSS will be quantum-resistant by 2035".

Civilian agencies have their own date. Executive Order 14412 directs agencies to "transition all HVAs and high impact systems to use PQC for key establishment" by 31 December 2030.

A buyer working to those dates asks two questions about any vendor's cryptography: which parameter sets it uses, and whether the defaults already match. KXCO's answer is now ML-KEM-1024 and ML-DSA-87 by default, in software anyone can install and inspect today.

Key establishment is also where waiting costs the most. An adversary can record encrypted traffic or copy encrypted files now and decrypt them once a large quantum computer exists. A signature can be replaced later; a recorded secret cannot be taken back.

What a buyer can check without asking KXCO

• Every release named above is on npm with a build provenance attestation, which links the published package to the source commit and the public build that produced it.

• The upload record for a test file shows the arithmetic of an ML-KEM-1024 seal. A 94-byte file is stored as 1,690 bytes: 1,568 bytes of ML-KEM-1024 ciphertext, 12 bytes of nonce and a 16-byte authentication tag around the data. Its signed record names "ML-KEM-1024 + AES-256-GCM" and is signed with ML-DSA-87.

• KXCO's published key list, mirrored on each of its hosts, states the same policy in its key-encapsulation field.

• The checks behind Exhibit 2 run against the released packages in one command. KXCO also runs them with every input corrupted, and every check fails, which shows they are testing what they claim to test.

Nothing made with ML-KEM-768 is stranded

A default change that broke old data would be worse than no change. Each release was tested against the earlier releases from npm, installed side by side.

• An envelope encrypted by kxco-pq-vault 1.3.0 decrypts under 2.0.0, byte for byte.

• A key derived from a master secret under 1.3.0 is derived again, identically, by 2.0.0 when the caller asks for ML-KEM-768.

• A hardware key store written by kxco-pq-hsm 1.7.0 opens under 1.8.0, and its ML-KEM-768 key works beside a new ML-KEM-1024 key.

• A channel library at 2.0.0 meeting an older responder stops with a named error instead of quietly using the weaker set. The kxco-pq-tls README explains why: "A fallback would be a downgrade path". A caller who needs the older responder chooses ML-KEM-768 explicitly, and the connection opens.

What KXCO does not claim

KXCO does not claim CNSA 2.0 compliance or validation, and its packages hold no FIPS 140-3 certificate. The change covers new keys in KXCO's npm packages and its pqc.kxco.ai vault. Ordinary web connections to KXCO's sites use the X25519MLKEM768 hybrid that browsers negotiate today.

The packages are free under Apache-2.0 on npm and GitHub. Institutions and agencies planning a CNSA 2.0 migration can reach KXCO at [email protected] or through kxco.ai/contact.

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.