There are five of them, they are free, and they are on npm today. Together they take a JavaScript estate from a vague intention about post-quantum cryptography to a position you can defend in a meeting: the new algorithms in place, the old ones located, the build refusing to let anyone hold them wrong, and the private keys inside hardware that will not release them.
kxco-post-quantum is the core. ML-DSA-65 for signatures, ML-KEM-768 for key encapsulation and SLH-DSA where a hash-based signature is wanted, all through a single API, on established implementations pinned to an exact version. You get FIPS 204, 203 and 205 without choosing a library, tracking its breaking changes, or owning its bugs.
kxco-verify answers one question, whether a signature is mathematically valid, and it is free and stays free. If that is all you need, take it and pay us nothing. We are not going to meter arithmetic.
kxco-pq-scan reads your lock file and tells you where the quantum-vulnerable cryptography already is. It emits a CycloneDX 1.6 cryptographic bill of materials, so the answer is a standard document rather than a screenshot.
eslint-plugin-kxco-pq fails the build when application code reaches past the wrapper into a raw primitive. That sounds like housekeeping. It is not, and the reason is in the next section.
kxco-pq-hsm generates ML-DSA keys on a PKCS#11 hardware token as non-extractable objects and signs with C_Sign, so the private key never enters host memory and survives a restart as a token object.
The problem they remove
The hard part of this migration was never choosing an algorithm. NIST chose. The hard parts are the two nobody budgets for.
You do not know what you have. Source-code scanning finds the cryptography your own developers wrote, and in a modern application that is the smaller half. The rest arrived transitively, several levels down a dependency tree, inside a package nobody selected deliberately. A scan of first-party code will not see it.
You can hold the new thing wrong, silently. This is the one that costs people. Our wrapper takes sign(secretKey, message). The raw primitive underneath takes its arguments in the other order. Transpose them and you still get a well-formed byte string of exactly the right length. It looks like a signature. It verifies as nothing. No exception, no warning, no failing test, and it ships.
We know precisely how easy that is, because we did it. While testing against a hardware token last week, our own integration test called the raw primitive with the wrapper's argument order. Every offline test passed. The real token was what caught it. That is the entire reason the lint rule exists: it is not branding, it is a scar.
Who needs them, and why
Any team shipping JavaScript with a signing or key-exchange dependency. Which, once you read a lock file honestly, is close to all of them. If you issue a JWT, verify a webhook, talk to a payment provider or authenticate a service, elliptic-curve cryptography is in your tree whether or not anyone chose it.
Regulated firms first. Banks, payment schemes, exchanges, custodians and market infrastructure are the ones being asked the question already, and the question does not come from engineering. It comes from audit, and it arrives as: show me what cryptography you run, show me what you are doing about it, and show me when you knew.
Anyone with a supplier questionnaire in front of them. The G7 has issued PQC guidance, CNSA 2.0 sets a 2027 procurement gate for US national security systems, and eIDAS and ETSI are moving. Your customers will ask before your regulator does.
And anyone putting an AI system near money. That is a different problem with the same root, and it is the one the industry has not started on. If a model can initiate a refund or a transfer, you need to know what it was permitted to do and who decided that.
How you use them
Start with the scan, because it takes one command and no account.
npx kxco-pq-scanIt reads package-lock.json on your machine, prints what it finds, and uploads nothing. Add --cbom for a CycloneDX 1.6 document you can attach to a change record, and --strict to make it a build gate.
Then adopt the wrapper where you sign, and turn the rule on in the same change so nobody can bypass it later:
npm install kxco-post-quantum eslint-plugin-kxco-pqTwo lines in eslint.config.js and a raw primitive call now fails the build rather than shipping. When keys need to live in hardware, kxco-pq-hsm takes a PKCS#11 library path and a PIN, and generation moves onto the token without the calling code changing shape.
Notice what the scanner does not do. It does not report AES-256 and SHA-2 as problems, because Grover's algorithm weakens them and Shor's algorithm does not break them, and a tool that reports both as findings teaches its reader to stop reading. It recognises hybrid constructions, so the classical half of an ML-KEM with X25519 pairing shows as the recommended migration path rather than a defect. Signal, not volume.
How it fits together
The packages are not a product line. They are the floor that everything else at KXCO stands on, which is why they are free and why they are maintained to a standard that would be excessive for marketing.
Armature L1 is a permissioned chain with instant finality where every block carries on-chain ML-DSA-65 verification from block zero. Not a retrofit, not a hybrid bolted on at a migration point. The same wrapper in the packages is what attests it.
KXCO Treasury, the economic operating system, moves value on that record. Sentinel is the quantum-resistant cloud and the trust layer for AI systems. The Ontology is where it becomes legible: every datum a typed claim with a source, an as-of date, a confidence and a basis, or a visible statement that the information is not available. Not a database of things. A record of who said what, when, and on what authority.
Put those together and the shape is clear. The packages give you the mathematics. KXCO Command, our licensed control plane, gives you the decision: whether a given key is still allowed to sign right now, which counterparties break if you rotate it, what an autonomous agent is permitted to do, and a sealed evidence pack that says so afterwards. A signature being valid and a signature being allowed are different questions, and only the second one survives an audit.
Why ours is different
Every claim is checkable without asking us. 2,103 NIST ACVP test vectors across FIPS 203, 204 and 205, pinned by digest so the corpus cannot drift: 1,793 passed, 0 failed, 310 skipped, and every skip is the library refusing a pre-hash weaker than the parameter set rather than a gap in coverage. Every release carries a SLSA provenance attestation tying the published tarball to the commit and workflow that built it. Run npm audit signatures and check it yourself.
We publish our own corrections. Version 1.3.1 of the HSM package claimed on-token key custody. The code did not implement it. We shipped 1.3.2 as a documentation-only release that named the defect precisely, in the README, on npm, where every prospective user reads it. Then 1.4.0 implemented the thing properly, with the claim owned by an integration test against a real PKCS#11 token rather than a convenient test double. Most vendors would have quietly fixed it in a minor version. The retraction is on the record permanently, and if you are evaluating cryptography from a company you have not met, that record should matter more to you than any feature list.
Findings you can act on the same afternoon. Every result names the exact dependency path that carried it, so the fix has an address rather than a category. That is the difference between a report someone files and a change someone makes.
The whole stack, not a layer. Plenty of vendors will sell you a library. Fewer can show you a chain that has been post-quantum attested since its genesis block, an ontology that records the provenance of every claim, and a control plane that decides admission. That coherence is the difference between adopting an algorithm and having a position.
Trust and compliance
KXCO is a member of the PKI Consortium, a contributor member of the Decentralized Identity Foundation, a participant in the CSA Quantum-Safe Working Group and the CoSAI open project, and active in the IETF LAMPS working group. We hold an active NIST ACVTS registration, a GLEIF LEI, ICO registration, and a vulnerability disclosure policy published under RFC 9116.
The work is aligned to NIST FIPS 203, 204 and 205, ETSI TS 119 312, UK eIDAS advanced electronic signature requirements, the G7 post-quantum mandate and NSA CNSA 2.0. A patent application covering identity-verified records anchored to a blockchain ledger is pending. The full list, with registration numbers, is on the corporate page.
None of that is a substitute for reading the code, which is why the code is open.
Who builds it
The packages are authored by Shayne Heffernan and John Heffernan with the KXCO engineering team, a small group of cryptography, distributed systems and platform engineers working across the chain, the control plane and the ontology. We do not put the team on a page with headshots, because the work is the credential and the commit history is public.
We run developer programmes for teams adopting the stack: integration support, review of your CBOM output, and early access to the control plane for firms with a governance requirement rather than only a cryptography one. Start at kxco.ai/developers.
FAQ
What do the KXCO post-quantum packages actually do?
They give a JavaScript team the NIST post-quantum algorithms through one wrapper, find the quantum-vulnerable cryptography already in its dependency tree, fail the build when application code bypasses the wrapper, and keep private keys inside a PKCS#11 hardware token. They are free and open source.
Why does a scanner read package-lock.json instead of the source code?
Because most quantum-vulnerable cryptography is not code your developers wrote. It arrives transitively, several levels down the tree, inside a package nobody chose. A manifest records what was requested; the lock file records what was installed.
What is a CBOM and why does it matter?
A cryptographic bill of materials. CycloneDX 1.6 added a cryptographic asset type, so a scan becomes a standard document that can be diffed between releases and merged with scans of your hosts, certificates and key stores rather than sitting in a report of its own.
Is ML-DSA-65 the right parameter set?
It is the NIST default and the one to build on today. CNSA 2.0 asks for ML-DSA-87 for US national security systems on a 2027 procurement gate, which is a specific buyer rather than a general mandate.
How is this connected to Armature L1, Treasury, the Ontology and Sentinel?
One cryptographic core underneath all of them. Armature L1 attests every block with ML-DSA-65 from block zero, Treasury and Sentinel consume the same primitives, and the Ontology records typed claims about what was signed and when. The packages are the layer they all stand on.
What does it cost?
Nothing. The packages are Apache-2.0 on npm and stay that way. KXCO Command, the licensed control plane that decides whether a signature is accepted, is the commercial product.
Talk to us
If you are inventorying an estate, replacing a signing path, or being asked a question by an auditor that your current tooling cannot answer, we would like to hear the specifics. The packages will not need a conversation. The position around them usually does.
Contact KXCO for a briefing, an integration review, or access to the control plane. More on the group, the certifications and the wider stack at kxco.ai/corporate.