# Quantum Cybersecurity: The KXCO Chain Is Already Running

The World Economic Forum says the race has changed gears. Here is a finished post-quantum stack, measured on the day of writing.

Canonical HTML: https://www.livetradingnews.com/quantum-safe-cybersecurity-the-kxco-chain-is-already-running
Last modified: 2026-09-15

---

By Shayne Heffernan · 2026-09-15
Tags: post-quantum cryptography, quantum-safe, ML-DSA, ML-KEM, NIST, FIPS 204, cybersecurity, KXCO, Armature L1, World Economic Forum, PKI Consortium, crypto-agility, harvest now decrypt later, $GOOGL
Signed: ML-DSA-65, anchored on Armature L1.
Nothing in this article is investment advice.

On 11 September 2026 the World Economic Forum published [a warning about the quantum-safe race](https://www.weforum.org/stories/cybersecurity/global-race-quantum-safe-cybersecurity/) that should have been unnecessary and, on the evidence of most corporate roadmaps, still is. The authors, writing from Quside, argued that the gap between future quantum risk and today's security planning has narrowed sharply over the past year, that governments have already moved, and that private organisations should not wait for a statute to tell them what "state of the art" now means.

They are right about the direction of travel. They are late about the work.

This is the second time we have answered the Forum from inside a working stack. The first was on fragmentation, and [where KXCO actually fits](https://www.livetradingnews.com/wef-fragmentation-principles-where-kxco-actually-fits) has not changed since.

The race they describe is no longer a research programme. It is a procurement cycle. The United States has set a 2030 deadline for federal post-quantum cryptography. The European Commission has told member states to begin the transition by the end of 2026 and to have critical infrastructure migrated by 2030. France's ANSSI will stop certifying products that lack quantum-resistant encryption from 2027. Japan is folding post-quantum primitives into CRYPTREC. The European Central Bank has written to bank chief executives. FINMA has told Swiss institutions to produce a migration plan, a cryptographic inventory and a defence against harvest-now-decrypt-later collection.

What a policy piece cannot say, because it is not a production report, is that a complete stack can already be built on the standards those governments are pointing at. [KXCO](https://kxco.ai/) did not wait for the 2030 letters. Every product in the estate runs on NIST's post-quantum algorithms, and they all run on the same implementation of them.

This article answers the Forum's three recommendations, inventory, agility and defence in depth, from the other side of the implementation wall. Every number in it was measured on the day of writing, and the method is stated so you can measure it yourself.

## The threat is a storage problem, not a date

Classical public-key cryptography is secure because the best known attacks on today's machines take an amount of time that might as well be infinite. A sufficiently large, sufficiently stable quantum computer running Shor's algorithm does not respect that bargain. It factors and it extracts discrete logarithms. The public keys protecting bank transfers, software updates, VPNs, medical records and government cables become reconstructable.

Current machines are not there. That is not an argument for delay.

Adversaries with patience and disk do not need a working cryptanalytically relevant quantum computer this year. They need only collect ciphertext now and wait. That is the harvest-now-decrypt-later attack, and it is already rational for any intelligence service or criminal syndicate that expects the hardware to arrive inside the lifetime of the secret. A thirty-year mortgage, a multi-decade medical record, a state secret with a classification life measured in decades, all of these are already inside the threat window.

Research from Alphabet suggested the resources required to break RSA could fall by an order of magnitude, and a March 2026 follow-up associated with Ethereum and Stanford put the elliptic-curve signature problem in a similar range. Whether those estimates hold is beside the point. The direction is one way, and the policy response has already been written in Washington, Brussels, Paris and Tokyo. Waiting for a precise Q-Day is how institutions discovered, in 2020, that they did not have a pandemic plan.

## What governments have already decided

In August 2026 the United States Treasury stood up a Quantum-Readiness Task Force for the financial sector, with workstreams on the post-quantum transition, vendor readiness and digital-asset risk. That followed two June executive orders: one to accelerate quantum computing, and one directing federal agencies to move to post-quantum cryptography by 2030 for federal assets and by 2031 for authentication. Historically, when the United States federal estate changes its cryptography, the vendors who sell into it change theirs.

Europe is not waiting to copy the American calendar. DORA, NIS2 and the Cyber Resilience Act never named ML-KEM or ML-DSA, because they were drafted as technology-neutral instruments. They do require state-of-the-art measures, and supervisors are now filling in the blank. On 7 July the ECB told bank chief executives that quantum progress will hit cybersecurity and that post-quantum adoption must start with strategic investment. Two days later FINMA required a migration plan, a risk analysis, a cryptographic inventory, protection against harvest-now-decrypt-later attacks, engagement with external providers, and crypto-agility.

France has gone further than guidance. ANSSI has said that from 2027 it will no longer certify security products that lack quantum-resistant encryption. Across Africa the immediate task is different, because much of the digital backbone is still being built, which is precisely why post-quantum migration belongs there as a design choice rather than a retrofit. It is cheaper to pour the right concrete than to jackhammer it out in 2031.

The Forum is correct that public-sector demand will pull private markets. The error, if there is one, is the implication that industry is still at the awareness stage. Some of it is. The part that builds settlement, identity and machine credentials cannot afford to be.

## What "state of the art" now means

Three NIST Federal Information Processing Standards, published in August 2024 after a multi-year international competition, are what the world is standardising on.

FIPS 203 specifies ML-KEM, the module-lattice key-encapsulation mechanism formerly called Kyber. It replaces RSA key transport and quantum-vulnerable elliptic-curve Diffie-Hellman. FIPS 204 specifies ML-DSA, the module-lattice signature algorithm formerly called Dilithium, replacing RSA signatures and ECDSA. FIPS 205 specifies SLH-DSA, a stateless hash-based signature scheme formerly called SPHINCS+, kept as a conservative alternative whose security rests on hash functions rather than lattices.

The KXCO production default is ML-KEM-768 for encapsulation and ML-DSA-65 for signatures, NIST Category 3, roughly the classical equivalent of AES-192. ML-KEM-1024 and ML-DSA-87 are available at Category 5, and SLH-DSA-SHA2-192s where a hash-based backup is required. Symmetric cryptography stays on AES-256-GCM and SHA-512. Grover's algorithm halves the effective strength of a symmetric key, and AES-256 remains above the 128-bit quantum security floor NIST treats as the minimum.

Algorithms are not the whole of cryptography, and the Forum is right about that too. Keys are only as unpredictable as the entropy that produced them. A lattice scheme fed from a weak generator is not a lattice scheme. KXCO treats that as an engineering constraint rather than a slogan. Key derivation is domain-separated HKDF-SHA-512 from explicit master secrets, high-value secrets use Argon2id, and production signing keys can live on a PKCS#11 token with CKA_EXTRACTABLE set false so the private material never enters host memory.

## Native, not a bolt-on: 42 manifests, one library

Here is the difference between a post-quantum estate and a post-quantum press release, drawn as a graph.

![Round Table graph showing every KXCO product depending on a single cryptographic library, kxco-post-quantum 1.7.2, which implements ML-DSA-65, ML-KEM-768, SLH-DSA and AES-256-GCM against FIPS 203, 204, 205 and 197, and is graded by ACVP certificate A11025](https://livetradingnews-media.nyc3.digitaloceanspaces.com/media/2026/09/15/cmpgg3-869257a210b195eb.svg)

*Figure 1. Read the shape, not the labels. Every product edge terminates on one node.*

Count the edges into the centre. There are eight product families in that view and one cryptography node. Nothing in the estate carries its own copy of ML-DSA, its own ML-KEM, or its own idea of what a good parameter set is.

The number under the hub is checkable rather than rhetorical. Searching every `package.json` in the KXCO source tree, excluding installed dependencies, build output and archived snapshots, returns **42 manifests that declare `kxco-post-quantum` as a direct dependency**. Meridian declares it. The Round Table anchor service declares it. The bank declares it. The identity service declares it. The content platform that published this article declares it.

That is what native means, and it is a structural property rather than a marketing one. Three consequences follow, and none of them are available to an estate that bolted post-quantum onto the side:

- Moving from ML-DSA-65 to ML-DSA-87 is one edge, not eight release trains. The envelope format does not change, because the envelope format was never per-product.
- A defect in the primitive layer is found once and fixed once. It cannot hide in the seventh product because the seventh product does not have its own.
- The estate can be graded as a single subject. A validation certificate against the hub is a statement about everything above it. A certificate against one product says nothing about the other seven.

There is no KXCO product that signs with ECDSA and promises to add post-quantum later. Later is how harvest-now-decrypt-later wins.

## The KXCO chain, and what it verifies

[Armature L1](https://chain.kxco.ai/) is the settlement and public-record layer of the stack: a permissioned, EVM-compatible chain operated by Knightsbridge Group under QBFT proof-of-authority. There are no reorganisations. Gas is negligible and predictable, which is the point of a settlement rail rather than a speculative venue. The native unit is ARMR. The chain does not custody customer assets; licensed institutions do.

Measured on 15 September 2026 against the public RPC endpoint: chain ID 1111111, block height 4,030,109, and a mean block time of exactly 2.00 seconds across 10,000 consecutive blocks.

What separates Armature from a conventional permissioned EVM is that post-quantum verification is native to the client. ML-DSA-65 signatures are checked on-chain by a precompiled contract at address `0x0b`, running on all four validators and the observer, against NIST FIPS 204.

That claim is cheap to make and easy to test, so here is the test, run against production on the day of publication.

A fresh ML-DSA-65 key pair was generated by OpenSSL 3.5 inside Node, and a message was signed with Node's own implementation. The public key, the signature and the message were concatenated and passed to `0x0b` through an ordinary `eth_call`. The chain returned 1.

Then the negative controls, which are the half that matters:

- One byte of the signature flipped. The chain returned 0.
- The signature left intact and one character of the message changed. The chain returned 0.
- A different public key substituted for the right one. The chain returned 0.

Note what that also proves. The key and signature were produced by OpenSSL, and the precompile verifies with an entirely separate implementation. A signature made by one codebase was accepted on-chain by another, and three deliberately corrupted variants were rejected. That is cross-implementation interoperability demonstrated on a live ledger, not asserted in a compatibility table.

A transaction can carry a classical secp256k1 signature for EVM tooling compatibility and an ML-DSA-65 signature for the quantum-resistant record. Document hashes, audit checkpoints, identity credentials and release attestations are written to the same ledger. Anyone with an RPC endpoint and the open-source verifier can check a claim without asking KXCO to confirm it.

That last property is the one most quantum-ready slide decks omit. A migration plan living in a PDF is not agility. A signature that can only be verified by calling the vendor's API is not non-repudiation. Armature was designed so the verification path does not run through KXCO. The public signing key is published. The verifier exists in JavaScript, Python, Rust and Go.

## Every product, and how it is wrapped

The Forum's first recommendation is a cryptographic inventory. Here is ours, in public, because an inventory that cannot be inspected is a brochure. Each of these is a [product page](https://kxco.ai/products) you can read rather than a capability on a slide.

### Armature L1, the record

[Armature L1](https://chain.kxco.ai/) carries on-chain ML-DSA-65 verification at `0x0b`. Document and audit anchoring in production. ML-KEM-768 and SLH-DSA available. Hybrid transaction signatures give EVM compatibility without surrendering the quantum-resistant record.

### Round Table, the decision layer

[Round Table](https://kxco.ai/ontology) is the ontology engine that turns documents into a checkable model of who owns what, who decided what, and when. Its anchor service signs with ML-DSA-65 and writes evidence to Armature, so a conclusion carries its provenance rather than a claim of authority.

### Meridian, doing business

In [Meridian](https://kxco.ai/meridian), deal documents, NDA execution and structured deal events are signed with ML-DSA-65 and attested on Armature. A data room that will still matter in fifteen years cannot be sealed with a five-year signature assumption.

### Treasury, the movement of value

[Treasury](https://kxco.ai/treasury) covers FX, securities, tokens, stablecoins and cash. Instructions that move value are signed. The audit trail is chained and, where policy requires it, checkpointed on Armature.

### Sentinel, the quantum-resistant security layer

[Sentinel](https://kxco.ai/sentinel) is one product with three modules. Bastion scans repositories, lockfiles and live endpoints for RSA, ECC, SHA-1 and weak TLS, and emits a CycloneDX 1.6 cryptographic bill of materials. PQC Host refuses a critical deploy that still carries quantum-vulnerable cryptography and signs the release with ML-DSA-65. Agent Certainty scores an agent before it acts.

### Identity, for people, companies and agents

[Credentials](https://verify.kxco.ai/) for individuals, companies and autonomous agents are signed with ML-DSA-65 and written to Armature. Verification does not require a KXCO server. The same model covers a human treasurer, a licensed institution, and an agent allowed to move money inside a policy envelope.

### Institutional rails

Every transaction, API request and outbound webhook uses ML-DSA-65. Key exchange and memo encapsulation use ML-KEM-768. Symmetric traffic is AES-256-GCM. Password and secret derivation is Argon2id. Outbound webhooks are deliberately hybrid, carrying HMAC-SHA-256 for receivers who have not moved yet and ML-DSA-65 for those who have.

### The open toolkit

[Nine packages on npm](https://kxco.ai/post-quantum) under Apache-2.0, all verified live at the time of writing. `kxco-post-quantum` is the primitive layer: ML-DSA, ML-KEM, SLH-DSA and fingerprinting. On Node 24 and later the mathematics runs in OpenSSL 3.5; older Node and browsers use the audited `@noble/post-quantum` implementation, and the two are wire-interoperable by test rather than by assumption. Around that core sit `kxco-pq-sdk` for hierarchical identity, `kxco-pq-hsm` for PKCS#11 custody, `kxco-pq-tls` for hybrid ML-KEM-768 plus X25519 channels, `kxco-pq-vault` for file and envelope encryption, `kxco-post-quantum-webhook` for drop-in signed webhooks, `kxco-pq-attest` for self-contained signed envelopes, `kxco-pq-audit` for a tamper-evident ML-DSA-chained log, and `kxco-pq-cli` for operators who should not have to write code to rotate a key.

Developers start at [kxco.ai/developers](https://kxco.ai/developers). Assessors should start at the [PQC evidence page](https://kxco.ai/developers/pqc-evidence), which exists because third-party assessments kept scoring the commercial platform and recording the result against the Apache-2.0 library. That page states which subject is which and carries the negative claims explicitly.

## We sent the cryptography to NIST and asked to be marked

Claims of post-quantum readiness have become cheap. Most of them are a blog post, a hybrid TLS experiment, or a laboratory file the vendor generated itself and then graded against its own answers. That is not how cryptographic implementations are tested when the tester is the United States government.

We sent ours to NIST and asked to be marked, and [published the result in full](https://www.livetradingnews.com/nist-graded-our-post-quantum-cryptography-zero-failures). NIST's server generated vectors nobody had seen, we answered them over the ACVP protocol, and NIST graded the result.

2,130 test cases. Zero failures. ML-KEM, ML-DSA and SLH-DSA, across key generation, signing, verification, encapsulation and decapsulation, issued as demo certificate A11025 against `kxco-post-quantum` 1.7.2.

NIST is the National Institute of Standards and Technology, a United States federal laboratory under the Department of Commerce. It ran the global post-quantum competition, published FIPS 203, 204 and 205, and operates the Cryptographic Algorithm Validation Program. The Automated Cryptographic Validation Protocol is the machine-to-machine method NIST uses so an implementation can be tested against vectors the implementer did not write. The server sits at NIST. The vectors are generated there. The implementation under test returns responses. NIST scores them.

Now the caveats, because a result stated without its boundary is an overclaim, and we would rather draw the line ourselves than have an assessor draw it for us.

A demo certificate is not a FIPS 140-3 module validation. FIPS 140-3 is a module programme covering physical security, roles, key zeroisation and the operational environment. ACVP algorithm validation is a statement about whether an implementation produces the outputs the standards require when the inputs are NIST's. A11025 does not appear on the public CAVP list and it is not a certification of the firm.

The tested claim is also deliberately narrower than NIST's full matrix. The JavaScript backend refuses a HashML-DSA or HashSLH-DSA pre-hash weaker than the parameter set's own security category. That is the `@noble` library's policy, not a FIPS 204 or 205 requirement, so those combinations were declined rather than answered. And these results describe the JavaScript path. The OpenSSL 3.5 backend is a separate implementation and has not been run against ACVTS.

One more piece of context worth having. On 13 September 2026, reading NIST's own validated-modules database, **zero active FIPS 140-3 certificates carried ML-KEM or ML-DSA anywhere**, against 454 active certificates for AES on the identical query shape. The control is the point: the zero is the database answering, not a malformed search. Any vendor claiming a FIPS 140-3 validated post-quantum module today is misstating it, and one query says so. Institutions that need a validated module should plan that engagement and watch the modules-in-process list. Institutions that need the algorithms to be correct can look at A11025 and run the checks themselves.

The library also carries a cross-implementation interoperability matrix against OpenSSL 3.5, liboqs, Bouncy Castle and independent Python implementations, in both directions, with negative controls. Releases are reproducible from tagged source, carry SLSA provenance and ship a CycloneDX SBOM. The whole evidence bundle is published, and readers who would rather not take any of this on trust can [check it themselves](https://www.livetradingnews.com/check-it-yourself-the-evidence-behind-the-kxco-post-quantum-stack). None of that replaces a third-party audit of the wrapper patterns, which is on the public roadmap. It does replace the habit of saying quantum-safe and pointing at a white paper.

## Inventory, agility and depth, as they look in production

The Forum's three steps are the right three. They are also incomplete if they stop at policy. So here is the second graph: what the supervisors have asked for, and which running capability answers each demand.

![Round Table graph mapping regulators including FINMA, the ECB, ANSSI, the EU Commission, CRYPTREC and the US Treasury task force to their obligations, and each obligation to a KXCO capability already in production and the product that provides it](https://livetradingnews-media.nyc3.digitaloceanspaces.com/media/2026/09/15/cmpgg3-b27a3ff3da0cd879.svg)

*Figure 2. Bands read left to right. The right-hand column is not a roadmap.*

FINMA is the densest node on the left because it asked for five things at once on 9 July 2026. Follow each of its edges and they all terminate in the third column, which is the column of things that already run.

A cryptographic inventory that does not include every webhook secret, every CI signing key, every agent identity, every firmware updater and every vendor connection is an inventory of the office diagram, not of the attack surface. Bastion exists because most estates discover their RSA in a lockfile rather than on a slide, and [the cryptography you did not choose is already in your software](https://www.livetradingnews.com/the-cryptography-you-did-not-choose-is-already-in-your-software). The output is a CBOM, not a paragraph.

Cryptographic agility that cannot swap a parameter set without a six-month release train is a synonym for hope. Agility in the KXCO stack means the primitive layer is a single package, which is the property Figure 1 draws. Products call ML-DSA-65 today and can call ML-DSA-87 or SLH-DSA-SHA2-192s without redesigning the envelope format. Hybrid constructions, X25519 with ML-KEM-768 on the wire and secp256k1 with ML-DSA-65 on the transaction, exist so counterparties who have not moved are not locked out, and so a break in one family does not take the channel down. Agility is also operational: `kxco-pq-cli` rotates institution keys, optionally anchors the rotation on-chain, and never prints a private key to stdout.

Defence in depth that stacks two classical schemes is not depth against a quantum adversary. Depth means a lattice encapsulation wrapping AES-256-GCM, a lattice signature on the payload, an optional hash-based signature where conservatism is worth the size, an HSM boundary so host compromise does not yield the key, an audit log whose entries are themselves signed and chained, and a public record that outlives the company process that created it. That is what multiple protection layers looks like when it is not a consultancy sentence.

## Standing in the standards community

None of this is done in a room by ourselves. KXCO's legal entity, Knightsbridge Financial Ltd, has been [a member of the PKI Consortium since July 2026](https://pkic.org/members/kxco/), listed with the working groups and the representative named in public.

The PKI Consortium is where the certificate authorities, HSM vendors, browser makers and enterprise PKI teams argue out what post-quantum migration actually requires, and it publishes the PQC Maturity Model that vendors are now being measured against. Membership is not an accolade and we do not present it as one. It is the room where the migration is being specified, and being in it means the specification arrives as a conversation rather than as a surprise.

Read the [KXCO trust page](https://kxco.ai/trust) for the wider position on compliance and assurance, and the [security page](https://kxco.ai/security) for how to report something.

## The cost of waiting is no longer theoretical

A FINMA survey of sixty Swiss financial institutions found the familiar pattern: the risk is recognised, the roadmap is not. That pattern will not survive contact with procurement. When ANSSI stops certifying classical-only products, when federal agencies can only buy what meets the 2030 letters, and when a correspondent bank asks for evidence that webhooks will still verify after Q-Day, the institutions that spent 2026 commissioning another study will be buying someone else's stack in a hurry.

There is a second cost, specific to anyone tokenising a real-world asset or signing a contract with a multi-decade life. A signature is a promise about the future. If the algorithm that made the promise is broken in 2032, the document is not slightly less convenient to verify. It is repudiable. Courts, counterparties and auditors will ask what standard you used when a conservative alternative existed. Building a thirty-year instrument on a five-year cryptographic assumption is a governance failure dressed up as a technology lag.

Artificial intelligence makes the same point from the other direction. Autonomous agents that pay invoices, file reports or move inventory need identities that cannot be forged when the adversary has a quantum computer and a copy of last year's traffic. The KXCO agent path is the human path: an ML-DSA-65 identity, signed actions, policy on what the key is allowed to do, settlement on Armature. Treating agents as a special case that can live on classical keys for another product cycle is how an estate grows a second, quieter harvest-now-decrypt-later problem.

## What to do this quarter

Do not wait for a named obligation in DORA or NIS2. Supervisors have already said that state of the art includes the quantum transition. The work splits cleanly.

- Inventory every place a public-key operation happens. TLS, code signing, document signing, payments authorisation, webhooks, VPNs, firmware, agent credentials, vendor APIs. Produce a CBOM.
- Classify secrets by lifetime. Anything that must stay confidential or verifiable beyond 2030 is already late if it is still classical-only.
- Put hybrid post-quantum key exchange on the wire wherever you control both ends. ML-KEM-768 combined with X25519 is the conservative production pattern.
- Move signatures on long-lived records to ML-DSA now: legal documents, identity credentials, audit logs, release attestations. Keep a classical signature alongside if a counterparty cannot verify yet.
- Demand evidence from vendors. ACVP results against NIST-generated vectors, interoperability matrices, published public keys, and a verifier you can run without the vendor's cloud. Ask which implementation was tested, and whether the certificate is an algorithm result or a module validation. Brochures are not evidence.
- Treat entropy and key custody as part of the same programme. An excellent algorithm with a software key sitting in an application server is one incident away from becoming a case study.
- If you are building new rails, identity, payments, settlement or agent economies, do not pour classical concrete. Retrofitting a live chain is a coordination problem most networks will not solve on time.

The Forum's authors closed by saying organisations need not predict the arrival date of a cryptographically relevant quantum computer. They need only notice that expectations have already moved.

That is the correct close, and it is the reason KXCO did not write a readiness strategy. We shipped the primitives, put them under NIST's grader, put verification on the chain, and made every product take a dependency on the same library. The race has changed gears. A race is decided by who is already on the track.

Company mentioned in this article: $GOOGL.

Shayne Heffernan, Ph.D., is the founder of Live Trading News, the KnightsBridge Group, Knightsbridge Law and the [KXCO.ai](https://kxco.ai/) ecosystem spanning post-quantum cryptography, identity, attestation and enterprise ontology. He writes at [shayneheffernan.com](https://shayneheffernan.com/).

*Figures 1 and 2 were produced by the KXCO Round Table ontology engine. Algorithm names and FIPS numbers follow NIST FIPS 203, 204 and 205, August 2024. Demo certificate A11025 refers to ACVP testing of `kxco-post-quantum` 1.7.2 and is not a FIPS 140-3 CMVP module validation. Chain, block-time and precompile figures were measured against the production Armature L1 RPC endpoint on 15 September 2026 and are reproducible by any reader with the endpoint and the published verifier.*

---

This Markdown mirrors https://www.livetradingnews.com/quantum-safe-cybersecurity-the-kxco-chain-is-already-running. The HTML page is canonical.
Site index for AI clients: https://www.livetradingnews.com/llms.txt