KXCO builds signing, verification, post-quantum cryptography and chain infrastructure for institutions. If you have found a security vulnerability in one of our products, we want to hear from you, and this page tells you exactly how to reach us, what we will do, and how quickly.
Email john@knightsbridgelaw.com. This mailbox is monitored and is kept separate from customer support, so security reports are not competing with support tickets for attention.
Please include:
Please do not open a public issue on GitHub for a security report.
If you want to encrypt or sign your report, sign it with your own key and say so, and we will respond in kind. Our platform post-quantum signing key (ML-DSA-65, NIST FIPS 204) is published at chain.kxco.ai/wallet/api/.well-known/kxco-pq-pubkey.
If you make a good-faith effort to comply with this policy, we will treat your research as authorised, we will not pursue or support legal action against you, and we will say so publicly if a third party attempts to.
Good faith means:
This safe harbour cannot bind third parties, including our hosting providers and our customers, and it does not extend to extortion, selling data, or public disclosure ahead of the window in section 7.
| Product | Surface |
|---|---|
| KXCO Nexus and KXCO Sign | sign.kxco.ai, signing, data rooms, recipient access |
| KXCO Verify and KXCOIdentity | verify.kxco.ai, credential issuance and verification |
| KXCO Sentinel and Bastion | pqc.kxco.ai |
| Armature L1 | chain.kxco.ai, explorer, relay, signing service |
| KXCO Purse | web wallet, browser extension, merchant rail |
| KnightsVault | white-label banking platform |
| Open-source packages | kxco-post-quantum, kxco-post-quantum-verifiers, kxco-post-quantum-webhook, kxco-verify |
| Web estate | kxco.ai, kxco.io |
We are particularly interested in anything that breaks a cryptographic guarantee: a signature accepted when it should not be, a replay window that does not hold, key material that can be recovered or reused, or a verification result that means less than our documentation claims.
livetradingnews.com, which publish their own separate policy| Stage | Commitment |
|---|---|
| Acknowledgement | A reply from a named person within 2 business days, with a tracking reference. Not an auto-responder alone |
| Triage decision | Within 5 business days: whether we reproduced it, our assessment of the impact, and a target fix date |
| Status updates | At least every 14 days while the case is open, including when the update is that nothing has changed |
| Explanation | Every decision is explained, including a decision not to fix |
We prioritise using CERT/CC's Stakeholder-Specific Vulnerability Categorization supplier model rather than a severity score alone. A number tells you how bad something is in the abstract; SSVC produces a decision about what we do next, which is the part that affects you. We record a CVSS vector as well when a CVE is issued, because downstream tooling expects one.
The four questions we ask: is it being exploited, is exploitation automatable and against concentrated targets, does it give partial or total control of the component, and is there material safety or financial impact.
| Outcome | What happens | Fix target |
|---|---|---|
| Immediate | Incident response, all available resources, customer notification prepared in parallel | 48 hours |
| Out-of-cycle | Engineers pulled off current work, out-of-band release | 7 days |
| Scheduled | Fixed in the normal release cycle | 30 days |
| Defer | Logged with our reasoning, reviewed at the next security review | No commitment, and we tell you why |
Anything touching cryptographic correctness, signature verification, replay windows or key custody starts at out-of-cycle or higher, and is only downgraded with a written reason.
Our default disclosure window is 90 days from triage confirmation. Where the fix ships sooner, we publish sooner. If you need a shorter window, tell us and we will negotiate rather than refuse.
We may publish earlier if the issue is already public or we see it being exploited, and later if the fix needs coordinated action by customers, such as a validator upgrade, in which case we will agree that with you.
We credit reporters by name in the advisory and the changelog unless you ask us not to. We do not require you to sign a non-disclosure agreement as a condition of reporting, we do not ship security fixes silently, and our advisories are never behind a paywall. Where a customer needs to track remediation, we request a CVE.
Most reports about our own products are handled directly between us and you. Where an issue affects several vendors at once, or sits in a shared cryptographic implementation or protocol, coordination through a neutral third party is better for everyone, and we work with the CERT Coordination Center at Carnegie Mellon University's Software Engineering Institute for those cases.
If you would rather report through a coordinator than to us directly, that is a legitimate choice and we will not treat it as hostile.
We do not run a formal bounty programme. We commit to public acknowledgement on every confirmed fix and to crediting you in the changelog unless you request anonymity. Cash awards for critical findings are at our discretion, and we will not imply a reward we have not agreed with you.
This page describes our process, not a contract, and it does not create legal rights beyond the safe harbour stated in section 2. It supersedes any earlier reporting instructions in our repositories or documentation. If you find an older address published anywhere in our estate, the address on this page is the correct one, and we would be grateful if you told us where you found the old one.