KXCO has quietly completed a change that puts its software ahead of a deadline most organizations have not yet started preparing for. Across its post-quantum packages and its file vault at pqc.kxco.ai, the company has made ML-KEM-1024 the default for new encryption keys, pairing it with ML-DSA-87 for signatures. Both parameter sets are the ones the US National Security Agency designates as mandatory "for all classification levels" under its Commercial National Security Algorithm Suite 2.0.
Why the Key Establishment Step Matters Most
ML-KEM is the NIST standard for key establishment, formalized as FIPS 203. It is the mechanism that negotiates the shared secret protecting a file or a network connection, the cryptographic handshake that happens before any actual data moves. NIST organizes post-quantum strength into security categories, and this is where the distinction between KXCO's old and new defaults becomes concrete: ML-KEM-768 sits in Category 3, while ML-KEM-1024 sits in Category 5, the highest tier NIST defines. The practical cost is size - an ML-KEM-1024 public key and ciphertext each run 1,568 bytes, compared with 1,184 and 1,088 bytes for ML-KEM-768 - a modest trade for organizations racing a government timetable rather than a performance benchmark.
Key establishment carries a particular urgency that signatures do not. An adversary can record encrypted traffic or copied files today and decrypt them later, once a sufficiently powerful quantum computer exists. A weak signature can be reissued after the fact; a secret captured in transit cannot be recalled. That asymmetry is why NSA, NIST, and the White House have all prioritized migrating key establishment first.
What Changed, Package by Package
The shift touches the full KXCO stack. kxco-pq-vault 2.0.0 now generates ML-KEM-1024 keys by default for file and envelope encryption, while continuing to decrypt anything sealed under the earlier ML-KEM-768 default. kxco-pq-tls 2.0.0 opens new encrypted channels with ML-KEM-1024 combined with X25519, growing the opening handshake message from 1,218 to 1,602 bytes. Hardware key storage through kxco-pq-hsm 1.8.0 and the audited interface in kxco-pq-sdk 2.4.1 both now handle the larger keys, and the core kxco-post-quantum 1.11.0 library leads its documentation with ML-KEM-1024 without altering the behavior of existing ML-KEM-768 calls. The bundled kxco-pq 3.0.0 installs this entire stack, and kxco-pq-scan 1.3.1 records ML-KEM-1024 in the cryptographic bill of materials it generates for each build.
Since 01:47 UTC on 11 October 2026, every file uploaded to pqc.kxco.ai has been sealed to an ML-KEM-1024 key before it touches storage, with the vault retaining whichever key sealed earlier uploads so nothing already stored becomes unreadable.
Backward Compatibility Was Tested, Not Assumed
A default change that silently breaks old data is arguably worse than no change at all, and KXCO built its testing around that risk. Every release that altered a default was checked against the prior releases pulled directly from npm, with results compiled in what the company calls Exhibit 2. An envelope encrypted under kxco-pq-vault 1.3.0 decrypts correctly under 2.0.0. A key derived under the old version reproduces identically under the new one when a caller explicitly requests ML-KEM-768. A hardware key store from kxco-pq-hsm 1.7.0 opens under 1.8.0, with old and new keys coexisting. Notably, kxco-pq-tls does not quietly fall back to the weaker parameter set when it meets an older responder - it fails with a named error instead, a deliberate choice the project's documentation frames bluntly: a silent fallback would amount to a downgrade path, the exact vulnerability pattern that has undermined encryption protocols before.
The Regulatory Clock Behind the Decision
This is not a change made in a vacuum. NSA's CNSA 2.0 guidance requires that, from 1 January 2027, new acquisitions for national security systems be CNSA 2.0 compliant, with non-compliant equipment phased out by the end of 2030 and full quantum resistance across those systems targeted by 2035. Civilian federal agencies face a parallel deadline: Executive Order 14412 directs them to transition high-value and high-impact systems to post-quantum key establishment by 31 December 2030. Buyers working against those dates are asking vendors two blunt questions - which parameter sets are in use, and do the defaults already meet the bar. KXCO's answer is now ML-KEM-1024 and ML-DSA-87, shipped in software available for inspection today, with every release carrying a build provenance attestation linking the published package back to its source and build process.
KXCO is careful not to overstate the milestone. It makes no claim of CNSA 2.0 compliance or validation, and none of its packages hold FIPS 140-3 certification - the change covers new keys generated through its npm packages and its own vault, not the broader web, where ordinary connections to KXCO's sites still rely on the X25519MLKEM768 hybrid that current browsers negotiate. The packages remain free under an Apache-2.0 license on npm and GitHub, and KXCO says institutions planning their own CNSA 2.0 migration can reach the company directly through its public contact channels.