KXCO's Free Post-Quantum Library Covers What TLS Leaves Out

TLS already moved. Your application did not.

A stock Node.js client on current releases negotiates a hybrid post-quantum key exchange, X25519MLKEM768, with no options set. Current releases of Chrome, Edge and Firefox do the same. The transport is no longer the open question. What the application signs, issues and stores still is. Documents, logins, webhooks, API tokens, file envelopes and the long-lived records a firm expects to open in 2035 are still protected by keys that a sufficiently large quantum computer could break. That is the gap. It is also the part of the migration with a date on it.

The United States has written the date down. Executive Order 14412, signed on 22 June 2026, moves federal high value assets and high impact systems to post-quantum key establishment by 31 December 2030. It moves the same systems to post-quantum signatures by 31 December 2031. OMB Memorandum M-26-15, issued two days later, turns the order into an execution programme: agency migration plans, a phased timetable, and a requirement that new applications be built on libraries that can change algorithm without a rewrite. The United Kingdom's National Cyber Security Centre has set 2028, 2031 and 2035 as its own milestones. None of these documents is a suggestion. A firm that sells to government, or that holds data a government later classifies as high value, inherits the dates whether it wanted them or not.

kxco-post-quantum is the free, open-source library built for that gap. It implements the NIST post-quantum standards for signatures and key exchange, for Node.js and the browser, and it has been checked against NIST's own test vectors. It is Apache-2.0. There is no licence check and nothing that phones home. The cryptography is free because it has to be: a signature that only verifies while the vendor is still in business is not a signature. What KXCO sells is the part that has to be operated, which is an answer, right now, about whether a key is still active, revoked or rotated. This article sets out what the library is, what the evidence shows, where the free line ends, and why the next four years are shorter than they look.

The transport is done. The application is not.

The distinction matters, and most migration plans blur it. Transport security and application security fail on different clocks. A TLS session recorded in 2024 can be broken later if its key exchange was classical. That is the harvest-now-decrypt-later problem, and it is why the hybrid groups landed first in browsers and in OpenSSL-backed stacks. A signature is different, because a signature is checked at the moment of use. A document signed in 2026 with a classical key is fine until the day someone needs to trust it after a quantum computer can forge that key. The forgery does not have to happen in 2026. It has to be impossible in 2032, when a regulator, a counterparty or a court asks whether the signature still means what it meant.

That is why the American order splits the deadline. Key establishment, which protects data against a later break, comes first, at the end of 2030. Signatures follow a year later, at the end of 2031. The order is aimed at high value assets and high impact systems. M-26-15 then says that "Secure software development practices must mandate the use of PQC-agile libraries for all new applications", and that "API gateways and application workloads must be configured to issue and validate PQC-signed tokens". A firm that treats the order as a federal-only problem will meet it again when a prime contractor asks for the same thing in a flow-down, or when a bank's vendor questionnaire starts quoting the memorandum by number.

The practical reading is simple. If a system establishes a key that will protect data still sensitive in 2030, that key establishment should already be post-quantum, or on a path with a date. If a system issues a signature that must still verify in 2031, the signature algorithm should already be one NIST has standardised, or the system should be able to change algorithm by configuration rather than by rewrite. Agility is a property of the interface, not of the mathematics.

Exhibit 1. Each rule is quoted from its primary text, and the build checks the quote. Each answer was read from npm when the figure was built: the package, its version and the function that does the work.

What NIST actually standardised

In August 2024 NIST published three Federal Information Processing Standards. FIPS 203 is ML-KEM, the module-lattice key encapsulation mechanism, the successor to Kyber from the NIST competition. FIPS 204 is ML-DSA, the module-lattice digital signature algorithm, the successor to Dilithium. FIPS 205 is SLH-DSA, the stateless hash-based signature scheme, the successor to SPHINCS+. These are not proposals. They are the standards. A library that ships something else and calls it post-quantum is selling a research artefact.

kxco-post-quantum ships all three. For signatures it ships ML-DSA-87 and ML-DSA-65. ML-DSA-87 is the set for new keys. ML-DSA-65 stays for keys that already exist, so a firm that issued identities last year does not have to re-key the world to pick up the current release. For key establishment it ships ML-KEM-768, the parameter set inside the hybrid TLS group already deployed, and ML-KEM-1024. For hash-based signatures it ships SLH-DSA-SHA2-192s.

The CNSA 2.0 parameter sets, the ones the National Security Agency names for national security systems, are ML-DSA-87 and ML-KEM-1024, both at security category 5. The agency's CNSA 2.0 FAQ lists "ML-DSA-87 for all classification levels". It lists "ML-KEM-1024 for all classification levels" beside it. Both ship with the same API as the category 3 sets. A change of import is a change of parameter set, not a change of architecture.

The evidence, stated carefully

The package has been run against 2,103 of NIST's own ACVP test vectors, according to its conformance file. 1,793 passed. None failed. The other 310 are pairings the library refuses because they are weaker than the parameter set, such as a SHA2-256 pre-hash with ML-DSA-87, where the hash's collision strength sits below the category of the signature. The refusal is deliberate. A vector file will happily ask an implementation to do a weaker thing, and a production library should decline. Each skip is recorded with its reason. The vectors themselves are pinned by digest to a specific commit of NIST's ACVP server, so the test corpus cannot drift underneath a release.

That is algorithm-level conformance against NIST's published vectors, run by the project and reproducible by anyone with the repository. It is not a CAVP certificate and it is not a FIPS 140-3 validation. No certificate number is claimed because none exists. The distinction is in the conformance file, and it should be in any honest description of the work. A buyer who needs a laboratory certificate should ask for one and should not treat a vector run as a substitute. A buyer who needs to know the implementation agrees with NIST's own test suite, and who wants to re-run the suite, is looking at the right artefact.

Agreement with NIST is not agreement with a counterparty. The package is cross-checked, in both directions, against three independent implementations: liboqs in C, Bouncy Castle in Java, and the Python reference implementations. Two hundred and twenty-five checks passed and none failed. CI subsamples the expensive sets on every push and runs the full suite weekly, and the report says which of the two it was.

The mathematics is not reimplemented in this package. On Node 24 and later it runs in the platform's native post-quantum support, OpenSSL 3.5. On Node 22 and in browsers it runs in a JavaScript implementation. Both produce identical bytes on the wire, which is the property that makes the fallback safe: a signature issued on one backend verifies on the other. A deployment that wants to refuse the JavaScript path can require the native backend at import, and fail closed if it is not there. The current release, 1.10.0, requires Node.js 22.12 or later. Node 20 reached end of life in April 2026, and 22.12 is the first Node 22 release that loads ES modules through require without a flag, which is the property the previous floor provided.

Formats a stack already parses

A post-quantum library that invents its own envelope is a migration cost, not a migration tool. kxco-post-quantum speaks the formats an existing stack already knows how to route. It signs compact JSON Web Signatures under the ML-DSA-87 and ML-DSA-65 algorithm names. It reads and writes AKP JSON Web Keys and PKCS#8 seed-form keys. It takes context strings, so a signature made for a login does not verify as a signature for a payment. It derives keys deterministically from a master secret by label, so a firm can name its keys without inventing a second store. It computes a fingerprint of each public key, and it compares key identifiers in constant time, so a lookup does not leak which key was asked for.

Seed form matters. A lattice secret key is large, and the seed it was grown from is small. Storing the seed and expanding it on use is how these algorithms are meant to be held, and the package supports that form.

The default for new signatures is ML-DSA-87. A key that is already ML-DSA-65 continues to sign as ML-DSA-65, because the key's size selects the set. A token signed by the previous release verifies unchanged. That is the compatibility rule: new keys take the stronger set, existing keys keep their name, and nothing already issued breaks. A caller who wants the old default can name it. A caller who leaves the choice alone gets the set CNSA 2.0 names.

A supply chain that can be checked

Cryptography is a dependency, and dependencies are how modern systems are compromised. The package is Apache-2.0. Builds are reproducible and verified in continuous integration. Every release since 1.4.1 carries SLSA provenance, which ties the published tarball to the commit and the workflow that built it, and a CycloneDX software bill of materials. Current releases also carry a cryptographic bill of materials, a CycloneDX 1.6 CBOM listing every algorithm the package offers with its object identifier, its NIST category, its purpose and the place in the source that uses it. The test suite fails if the source uses an algorithm the CBOM does not declare.

That is the shape of the artefact CISA has been asked to specify. Executive Order 14412 gives CISA, working with NIST, 270 days to publish the minimum elements of a cryptographic bill of materials, which runs to 19 March 2027. A CycloneDX 1.6 CBOM ships today, ready to be checked against those elements when they exist.

Third-party dependencies are pinned to exact versions, so the code that performs the cryptography cannot change without a release. A bump of the underlying primitive is gated on the conformance and interoperability evidence regenerating clean. npm provenance is present. The OpenSSF Scorecard stands at 9.2 out of 10, from its scan of 9 October 2026. There is a vulnerability disclosure path. None of this is exotic, and all of it can be checked without asking the vendor for a slide.

The same primitive sits under the rest of the family. It signs webhooks with HMAC and ML-DSA over the same bytes, and it encrypts files to one recipient or many. A browser verifier checks signatures with no KXCO server in the path, and an HSM package keeps the private key on a token. A scan reads a dependency tree and writes a CBOM, and a lint rule flags code that reaches past the wrapper. The primitive is the floor. The family is what a team actually installs.

Exhibit 2. Every figure was read when the exhibit was built: the conformance file from the package npm serves, the provenance attestation from npm, the CBOM from the release, and the score from the OpenSSF Scorecard API.

What is free, and what is not

The licence covers the code, not the service. Using it commercially, forking it and shipping it inside a product are free. Signing and verification work offline. A signature issued today verifies in ten years without a KXCO server, a network or a licence.

What cannot be free is an answer about the present. A signature proves that a key signed. It does not prove that the key is still trusted, that it has not been revoked, or that it has not been rotated since the artefact was issued. That answer requires someone to run a registry and stand behind it. The paid line is the hosted key registry, the meta-transaction relay, on-chain anchoring as an operated service, and live revocation, the mode that checks the registry at verify time and fails closed. So is support with an availability commitment. The price is in US dollars, per seat, per year. There is no token to buy, no node to run and no wallet to configure. A vendor that tells a firm post-quantum identity requires a token is selling a different product.

The relay exists so an institution can submit a signed intent without holding gas or operating infrastructure. KXCO validates the intent, pays the fee and submits the transaction. That is an operated service with a cost, and it is licensed. The KXCO name and its marks are not covered by Apache-2.0. Describing a product as "built on kxco-post-quantum" is fine. Putting a KXCO mark on a badge, a certificate or a sales page requires a written agreement. The line is deliberate. The cryptography is a public good. The brand and the operated answer are not.

Exhibit 3. Each package was installed from npm when the exhibit was built and the function named here was found in it. The operated services were read from their public endpoints at the same time.

Who this is for

It is for a team that issues signatures and does not want to become a cryptography group to do it. A bank can authenticate API calls with a post-quantum bearer token. A marketplace can sign webhooks so a merchant can prove a delivery came from the platform and not from an attacker who read the logs. A registry can issue credentials that still verify after the vendor who issued them has been acquired or wound down. A software firm can produce the cryptographic bill of materials a change record needs without assembling one by hand. An agency that has read M-26-15, or a contractor to one, can adopt a library that maps onto the requirements rather than a white paper that gestures at them.

It is also for the team that has been told to be quantum ready and has discovered that the phrase means nothing until a parameter set, a format and a test are named. Readiness is an algorithm identifier in a token, a key form a database can store, a vector suite that passes, and a bill of materials a reviewer can diff. The package is aimed at that list. It is not aimed at a researcher who wants a candidate that did not win the NIST competition. Those candidates lost for reasons, and shipping one in 2026 is a way to own a migration twice.

The install is one line. The package is on npm, and its Socket page is the shortest public summary of the claims, the licence and the supply-chain posture. A team that wants the whole family in one import installs the meta-package, kxco-pq. A team that wants only signatures installs this one. A team that wants to confirm a signature without the signer's stack installs kxco-verify, a separate verifier that does not import the signing library and needs no KXCO server. For a check that shares no code with the package at all, the conformance file records its agreement with liboqs, Bouncy Castle and the Python reference implementations.

The years between now and the deadline

2030 is closer than a programme plan admits. Inventory takes a year when it is done properly, because the cryptography in a large estate is not where the diagram says it is. Pilots take another, because the first integration finds the key store that cannot hold a seed and the token library that rejects an unknown algorithm. Prioritised migration then has to finish by the end of 2030, not start. M-26-15 sets out the same phases: strategy, planning and discovery in 2026 and 2027, pilots and early migration in 2027 and 2028, and prioritised migration from 2028 to 2030. A firm that begins in 2029 is late.

The order of work is not mysterious. Know what you have. Stop issuing new classical signatures for anything that must still verify in 2031. Put post-quantum key establishment in front of data that must stay confidential past 2030. Make the library agile, so the next parameter set is a configuration change. Then decide which keys need an answer about the present, meaning revocation, rotation and liveness, and buy that answer from someone who runs it, or run it yourself. The free packages do the first four. The service does the fifth.

There is a version of this story in which the deadlines slip and the memorandum is softened. That version has been available for a decade, and it is why so many estates are still classical. The agencies that have to move will move, because the order gives them a date and a reporting line. The contractors who serve them will move because the flow-down will say so. Waiting for perfect certainty is a way to arrive at the deadline with an inventory and no migrated system. The library is the piece that can be installed this week, under a licence that does not require a conversation.

A note on claims

A package in this category collects adjectives: quantum-safe, certified, validated, compliant. Most of them are larger than the evidence. The accurate statements are narrower and more useful. The package implements the three NIST standards, at the parameter sets CNSA 2.0 names and at the sets already on the wire. It has been checked against NIST's own vectors, with none failed and with the refusals explained. It interoperates, by test, with three independent implementations. It speaks formats a stack already parses. Its builds are reproducible, its releases carry provenance and a bill of materials, and its licence is Apache-2.0. It does not reimplement the mathematics. It is not a FIPS 140-3 module. It does not, by itself, make a deployment compliant with CNSA 2.0, because compliance is a property of a deployment, not of an available function.

That narrower list is the one a procurement reviewer can check. The Socket page, the repository, the conformance file and the evidence bundle for each release are public. A reviewer who wants to re-run the vectors can. A reviewer who wants a laboratory certificate should ask for one, will not find it here, and should not be told otherwise. The work is the credential. The commit history is public.

Install it, then decide

Install it with npm install kxco-post-quantum. It requires Node.js 22.12 or later and it is ESM-only. The quick start makes an ML-DSA-87 key, signs a string and verifies it. From there a team points it at the thing it actually signs: the webhook, the token, the document, the agent request. Add the lint rule at the same time, so a later change cannot quietly reach past the wrapper and drop the algorithm choice. Add the scan next, so the bill of materials is a command rather than a project. KXCO's developer guide, What TLS leaves out, walks through each step with code that runs against the current release.

The conversation with KXCO starts when the team needs the answer about the present: a hosted registry, anchoring, live revocation, a relay that submits a signed intent without a wallet, and support with a name to call. Those are priced per seat, in US dollars, and the terms sit with [email protected]. Until that need exists, there is nothing to buy. The cryptography is free. Use it, fork it, ship it.

TLS already moved. The application is the rest. The dates are written down. The library is on the registry, the evidence is in the repository, and the line between free and paid is in the licence file rather than in a sales call. That is the offer.

Frequently asked questions

What does TLS already protect, and what does it leave out?

Current Node.js releases, Chrome, Edge and Firefox negotiate the hybrid X25519MLKEM768 key exchange by default, which protects traffic recorded today against later decryption. TLS does not cover what the application signs, issues and stores: documents, logins, webhooks, API tokens, file envelopes and long-lived records.

When must US federal systems move to post-quantum cryptography?

Executive Order 14412 of 22 June 2026 sets 31 December 2030 for post-quantum key establishment and 31 December 2031 for post-quantum signatures in high value assets and high impact systems. OMB M-26-15 requires PQC-agile libraries for all new applications and post-quantum signed tokens at API gateways.

Which algorithms are in kxco-post-quantum?

It implements ML-DSA-87 and ML-DSA-65 from FIPS 204, ML-KEM-768 and ML-KEM-1024 from FIPS 203, and SLH-DSA-SHA2-192s from FIPS 205. ML-DSA-87 is the default for new signing keys, and ML-DSA-87 with ML-KEM-1024 are the sets CNSA 2.0 names.

How do you sign a JSON Web Token with ML-DSA-87 in Node.js?

Install kxco-post-quantum, derive an ML-DSA-87 key and call signJws from kxco-post-quantum/jws. The token header carries the algorithm name ML-DSA-87, and verifyJws checks it against a pinned algorithm and key identifier and fails closed.

Is kxco-post-quantum FIPS 140-3 validated?

No. According to its conformance file, it has been run against 2,103 of NIST's ACVP test vectors with 1,793 passed, none failed and 310 weaker pairings refused, and cross-checked against liboqs, Bouncy Castle and the Python reference implementations. That is algorithm-level conformance, not a CAVP certificate or a FIPS 140-3 validation.

What does KXCO charge for?

The library is free under Apache-2.0, and signing and verification work offline. KXCO charges for the operated services: a hosted key registry, live revocation, a meta-transaction relay, on-chain anchoring and support, priced in US dollars per seat per year, with no token, node or wallet.

What to watch

19 December 2026, when the FAR Council's proposed rule bringing NIST's post-quantum standards into federal contracts falls due under Executive Order 14412. 19 March 2027, when CISA's minimum elements for a cryptographic bill of materials fall due. 31 December 2030, the federal date for post-quantum key establishment in high value assets and high impact systems. 31 December 2031, the date for post-quantum signatures.

kxco-post-quantum is published under Apache-2.0 on npm and GitHub. Commercial terms for the operated service are available from [email protected]. The KXCO name and its marks are not covered by that licence.

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.