How we secure KXCO, and how we can help you fix yours

A security claim you cannot check is marketing. So this is the whole of it: what cryptography actually runs in KXCO production systems, what you can verify yourself without any cooperation from us, what is still in progress, and the coordinated vulnerability disclosure programme we published this week. The last two sections matter most. One is the work still in flight, stated at its current state so the claims above can be taken at face value. The other is what we find broken in almost every company we look at, and what fixing it actually involves.

01Claims worth checking

KXCO sells signing, verification and post-quantum cryptography to institutions. That makes our own security posture part of the product rather than a page in a compliance binder. It also sets a standard we are held to: if we ask a bank to trust a signature, we cannot ask it to trust us about the signature.

The practical consequence is that every claim below is either independently checkable or explicitly labelled as unproven. We would rather publish a short list of verified facts than a long list of adjectives, and we would rather tell you the boundary of what is proven than let you discover it yourself in a procurement review.

02The cryptography in production

KXCO standardises on the finalised NIST post-quantum standards. Not candidates, not proprietary constructions.

• ML-DSA-65, NIST FIPS 204, for signatures. Identities, documents, session tokens, webhook envelopes and settlement records.
• ML-KEM-768, FIPS 203, for key establishment.
• SLH-DSA-SHA2-192s, FIPS 205, where a hash-based signature is the conservative choice.
• HMAC-SHA-256 and HKDF for envelope integrity and key derivation, alongside the post-quantum signature rather than instead of it.

These are Category-3 parameters. We do not claim CNSA 2.0 compliance, which specifies Level 5 and would mean ML-DSA-87. Saying so costs us a badge and buys us the right to be believed on the rest.

Where it runs: session tokens on our cloud platform are ML-DSA signed. Document signing on KXCO Sign issues a per-signer keypair. Keys at rest are wrapped with AES-256-GCM and Argon2id. The public estate is served over hybrid post-quantum TLS, with two endpoints still pending a certificate-authority migration, which we would rather state than round up.

Armature L1 is the case that could not have been fixed later. The chain has signed with ML-DSA-65 from block zero. That is not a feature switched on at some point in its life, it is a property of every block in the record, and it is the reason we built a new chain rather than bolting post-quantum signatures onto an existing one.

A live chain’s history cannot be re-signed. Whatever cryptography secured a block when it was written is the cryptography that secures it permanently, so a network that began on classical signatures carries that exposure in its record for as long as the record exists, no matter what its validators run tomorrow. This is the one part of a post-quantum migration that has no migration path. Signature verification on Armature is performed by node and client software, and the chain’s cryptographic foundation is not a roadmap item, because on a running network with a permanent record that is not something anyone gets to alter after the fact.

KXCO Purse is where the no-custody principle stops being a sentence in a policy. The wallet is self-custodial across EVM chains, Bitcoin and Tron: keys are generated on the user’s own device, and in the default mode KXCO holds no key material at all. There is no omnibus account, no pooled balance, and no internal ledger standing between a user and their assets, which means there is no honeypot to steal and nothing for us to lose on a customer’s behalf. The strongest security property a wallet can have is that the operator cannot move your money, and that is an architectural fact here rather than a promise about our conduct.

Recovery is usually where self-custody quietly becomes custody again, with a provider holding a seed “just in case”. We do not do that. Managed accounts use a 2-of-3 guardian scheme, so a lost device is not a lost balance, and no single party, KXCO included, can move funds alone. It ships white-label, which is the part that matters commercially: an institution can put self-custody in front of its own customers without becoming a custodian itself.

Anchoring is hash-only. A document’s SHA-256 digest goes to the chain for tamper evidence. Document content and personal data never do. That is a deliberate limit on what the public record can leak.

03Verify without us

The interesting question is not what we claim, it is what you can confirm on your own. Five things, none of which require our help:

• Read the code. Thirteen post-quantum packages are open source on npm and GitHub, and independently indexed by the supply-chain scanner Socket.dev. Apache-2.0 and MIT.
• Run the vectors. Every primitive ships with pinned test vectors. npm test gives you the same bytes we see, or it does not, and then you have found something worth telling us about.
• Check the cross-language agreement. Our verifier suite implements the same ML-DSA-65 envelope in JavaScript, Python, Rust and Go, and CI asserts byte-for-byte identical results across all four on every push. A payload signed in one language must verify in every other.
• Fetch the platform key. Our ML-DSA-65 public key is published at chain.kxco.ai/wallet/api/.well-known/kxco-pq-pubkey. Verify a signature we produced against a key we published, using a library neither of us wrote.
• Check the registers. Company number 15684975 at Companies House, LEI 213800TMP5DQFDKOZ549 at GLEIF, ICO registration C1961692. Membership of the PKI Consortium and the Cloud Security Alliance Quantum-Safe Security working group, and participation in the IETF LAMPS working group, are all listed by those bodies rather than only by us.

04What we have in progress

Everything above is in production today. This is the work that is not finished, published with its current state rather than its intended state, because an institutional reviewer will establish all of it in due diligence anyway and the only variable is whether they hear it from us first.

• Independent cryptographic review. Today the position is self-attested: our wrapper libraries and integration patterns have not been independently audited, and the upstream @noble/post-quantum package carries a maintainer self-audit rather than a third-party one. Cure53’s 2023 NDS-01 audit of the @noble ecosystem covered ciphers, curves and hashes, and not the post-quantum package. We have published AUDIT.md precisely so that a reviewer can see the exact scope an audit would need to cover, which is the prerequisite for commissioning one properly rather than buying a logo.
• Formal certification. KXCO does not hold SOC 2 or ISO 27001 and has not commissioned a third-party penetration test. These are on the roadmap ahead of enterprise procurement, in that order. Internal review by our own engineering and security people is real work, but it is not the same thing and we will not present it as such until an external party has signed something.
• CERT/CC vendor record. Registration with the CERT Coordination Center is under way so that multi-vendor coordination cases reach us properly. Verification is the coordinator’s to complete, not ours to announce, and there will be no badge on our trust page until it is done.
• Disclosure surface across every product domain. The policy and the RFC 9116 security.txt are live on kxco.ai. The same file is still being rolled out across the signing, cloud, chain, verification and wallet domains, each of which is a separate host with its own deployment path. Until that finishes, the address on the policy page is the one that reaches us.

One thing on this list will not change, and it is not a gap. KXCO is a software company. It holds no financial licences and never custodies customer assets. Licensed institutions that deploy KXCO software operate under their own licences and hold their own customer relationships. That is a permanent design boundary, not an unfinished item.

05Reporting a vulnerability to us

Our coordinated vulnerability disclosure policy is published at kxco.ai/security, with the machine-readable contact at /.well-known/security.txt under RFC 9116.

# the machine-readable route, on every KXCO domain
curl https://kxco.ai/.well-known/security.txt

What we commit to:

• Acknowledgement within 2 business days, from a named human with a tracking reference. Not an auto-responder.
• A triage decision within 5 business days: whether we reproduced it, our assessment of impact, and a target fix date. Every decision is explained, including a decision not to fix.
• An update at least every 14 days while a case is open, including when the update is that nothing has changed. Silence is what turns a reporter into a public discloser.
• Safe harbour for good-faith research. Comply with the policy and we treat your research as authorised, will not pursue or support legal action against you, and will say so publicly if a third party tries.
• Credit by default, in the advisory and the changelog, unless you would rather we did not.
• A 90-day default disclosure window, sooner where the fix ships sooner, negotiable if you need it shorter.
• No blanket NDAs, no silent fixes, no paywalled advisories. Machine-readable advisories in CSAF 2.0 alongside the human-readable page.

The intake mailbox is deliberately separate from customer support. That is not an organisational nicety: the July 2026 joint guidance is explicit that mixing the two causes reports to be lost or accidentally disclosed, and we have seen enough vendors learn it the expensive way.

06How we prioritise

We use CERT/CC’s Stakeholder-Specific Vulnerability Categorization supplier decision model rather than a severity score on its own. A CVSS number tells you how bad something is in the abstract. SSVC produces a decision about what happens next, which is the part a customer actually experiences. We record a CVSS vector too, because downstream tooling expects one.

Four questions: is it being exploited, is exploitation automatable and aimed at concentrated targets, does it give partial or total control of the component, and is there material safety or financial impact. Four outcomes, each tied to a commitment:

• Immediate. Incident response, all available resources, customer notification prepared in parallel. Patch or mitigation within 48 hours.
• Out-of-cycle. Engineers come off current work for an out-of-band release. Seven days.
• Scheduled. Fixed in the normal release cycle. Thirty days.
• Defer. Logged with our reasoning and reviewed at the next security review. No commitment, and we tell you why.

One local rule: anything touching cryptographic correctness, signature verification, replay windows or key custody starts at Out-of-cycle or higher by default, and is downgraded only with a written reason. In a signing product those are not ordinary bugs.

07What is usually broken

We run this exercise across our own estate on a schedule, which is where the specifics below come from. None of it is exotic. The same handful of failures accounts for most of what we find, and every one of them is cheap to fix once someone has actually looked.

The same handful of failures shows up nearly everywhere, and every one of them is invisible until a researcher, a regulator or an attacker finds it first.

• A published address nobody reads. The most common failure is not a missing policy, it is a security mailbox that forwards to someone who left, or to a distribution list everyone mutes. The vendor believes it has a reporting channel. It has a void with a nameplate on it. Send a test report to your own published address today and see what happens.
• Security reports landing in the support queue. A vulnerability report triaged as a customer complaint gets a canned reply and a closed ticket. The joint guidance published in July 2026 is explicit about this, and it is the failure most likely to turn a cooperative researcher into a public discloser.
• No security.txt. A researcher who cannot find where to report either gives up or posts publicly. Neither outcome is one you get to choose after the fact.
• No safe harbour, so the careful researchers walk away. Good-faith research happens under laws that could be read to criminalise it. Without an explicit authorisation the people who read the legal position carefully are precisely the ones who decline to help, and the ones who proceed anyway are not the ones you wanted.
• Severity scores with no decision attached. A CVSS number generates an argument about how bad something is. It does not answer the only question a customer cares about, which is when it will be fixed. Without an outcome model, prioritisation collapses into whoever is loudest.
• No cryptographic inventory. Almost nobody can answer which algorithms are running where across their estate. That answer is the prerequisite for every post-quantum migration plan, and the reason most 2030 roadmaps are fiction: you cannot schedule the replacement of something you have not located.
• Advisories that are late, vague, or paywalled. Customers cannot assess exposure they cannot read, and silent fixes shipped as routine releases leave every downstream operator unable to tell whether they are affected.
• Audit claims that do not survive a search. Upstream audit scopes are narrower than the marketing around them, and citations get inherited between packages without anyone re-reading the original. One claim a buyer can check and disprove costs more credibility than the badge was ever worth.

There is a clock on all of this, not just a risk. US Executive Order 14412, signed 22 June 2026, requires at section 6(d) that the FAR Council publish a proposed rule within 270 days obliging covered contractors to run vulnerability disclosure policies that accept reports of cryptographic vulnerabilities specifically. Section 6(c) sets a contractor deadline of 31 December 2030 for FIPS post-quantum compliance. If you sell to the US federal market, or to anyone who does, disclosure process is about to become a procurement question rather than a maturity nicety. The joint guidance from CISA, the NSA, the UK NCSC, the Netherlands NCSC and JPCERT/CC of 15 July 2026 is what that rule will be measured against.

08How we fix yours

We have just taken a real estate through this end to end, including the uncomfortable parts, and the work is fresh rather than theoretical. Four things we do, in the order they usually need doing.

• Find the cryptography you are actually running. KXCO Sentinel scans repositories and endpoints and produces a signed CycloneDX CBOM: which algorithms, in which components, on which hosts, and what has to change before the 2030 deadline. The inventory is the hard part of a post-quantum migration. The algorithm swap is comparatively easy once you know where to swap it.
• Stand up the disclosure programme. The published policy and safe harbour wording, an RFC 9116 security.txt across every domain you own, a monitored intake genuinely separated from customer support, an SSVC triage model with service levels attached to each outcome, CSAF 2.0 advisory templates, and the CERT/CC coordination route for anything that turns out to be multi-vendor. Days of work, not the quarter most organisations budget for it, because the shape is now known.
• Replace the cryptography with standards rather than a rewrite. Our post-quantum libraries are open source and in production: signing, verification, webhook envelopes, key derivation, and a standalone verifier, at FIPS 203, 204 and 205. Adopt them, or use them as the reference while your own team implements. We would rather be checked than trusted.
• Make the result provable to third parties. KXCO Nexus signs documents and runs data rooms with post-quantum signatures and hash-only chain anchoring, so a counterparty, an auditor or a regulator can verify what you assert without trusting either of us. Where AI agents act on your behalf, they get identities that can be checked and revoked on the same terms as people.
• Let your customers hold their own assets. KXCO Purse is a white-label self-custodial wallet: EVM chains, Bitcoin and Tron, merchant payments and scan-to-pay, deployed under your brand rather than ours. Because your customers hold their own keys, you can offer a wallet without becoming a custodian, which keeps you out of the safeguarding and licensing obligations that attach to holding client assets, and removes the pooled balance that makes an operator worth attacking in the first place. Guardian-based recovery is available where customers want a safety net, without any single party being able to move funds alone.

We are a software company. We do not custody assets, we do not hold financial licences, and we do not operate regulated services. Institutions deploy our software under their own licences. That boundary is why our own security posture has to be legible rather than merely asserted: our customers inherit it, and they are the ones examined on it.

If you find something wrong in any of this, including in this article, the address is kxco.ai/security. We will acknowledge within two business days, and we will credit you.

Talk to us: kxco.ai/contact · Policy: kxco.ai/security · security.txt · Code: npmjs.com/~kxco · github.com/KnightsbridgeAIQ · Audit posture: AUDIT.md. KXCO is a software company; regulated services are operated by licensed institutions and KXCO never custodies assets. Cryptographic posture reflects NIST FIPS 203/204/205 at Category-3 parameters; KXCO does not claim CNSA 2.0 compliance, and does not currently hold a third-party cryptographic audit, SOC 2, ISO 27001 or commissioned penetration test; see section 04 for the current state of each. Nothing here is investment advice.