KXCOIdentity Armature L1 ↗ Developer SDK ↗ Consulting Request a Demo
KXCOIdentity — by Knightsbridge Group / KXCO

Post-quantum digital identity
for institutions that cannot
afford to be wrong.

Legally binding, ML-DSA-65-signed credentials and document signing — white-labeled under your brand, deployed in your infrastructure, independently verifiable by any counterparty without a network call or vendor dependency.

NIST FIPS 204 — ML-DSA-65 Cure53 audited 2024 10,900+ monthly downloads Production-deployed White-label
FIPS 204
ML-DSA-65 signatures
NIST August 2024
11
Open-source packages
Cure53 audited
5
Live production deployments
Under regulation
2035
NSA full migration deadline
CNSS Policy 15

Your digital signatures
are already at risk.

Every digital signature your institution has issued — every contract, every regulatory submission, every identity attestation — relies on RSA or elliptic curve cryptography. Algorithms a quantum computer will break. The migration window is closing.

01
Harvest now,
decrypt later.
Nation-state adversaries are archiving encrypted traffic and signed documents today, waiting for the quantum capability to decrypt them tomorrow. By the time the capability exists, signed loan agreements, regulatory filings, and trade confirmations from 2024 will already be compromised. This is a documented adversarial strategy, not a theoretical risk.
02
Compliance mandates
with fixed deadlines.
NIST published FIPS 203 and 204 in August 2024. NSA has mandated full migration of national security systems by 2035, with restrictions on new ECC/RSA procurement beginning in 2026. Banks and regulated platforms servicing US and EU counterparties will face the same requirements downstream — with less lead time than they think.
03
Current platforms
are not built for this.
Most enterprise identity and e-signature platforms were designed in a world where RSA-2048 was considered permanent. They carry no post-quantum signature standard, no portable offline-verifiable credentials, no hierarchical institutional trust model, and no cryptographically guaranteed audit trail. They are not being redesigned fast enough.

The regulatory timeline.

2022NIST selects ML-KEM, ML-DSA, and SLH-DSA as final post-quantum standards after six years of open competition.
Aug 2024NIST publishes FIPS 203 (ML-KEM-768) and FIPS 204 (ML-DSA-65). The standards are final. Migration begins. KXCOIdentity is production-compliant from day one.
2026NSA mandates PQC for all new US national security systems. ECC and RSA forbidden for classified government procurement from this point.
2030NIST deadline to deprecate RSA-2048 and ECC-256 across US federal infrastructure. Legacy TLS certificates begin expiry cycle.
2035NSA CNSS Policy 15: full migration of all classified systems without exception. ECC and RSA prohibited across all national security systems globally.

The institutions that migrate early own the compliance advantage. The ones that wait inherit the liability.

KXCOIdentity.
How it works.

A five-step trust model: institution root identity → KYC-gated credential issuance → user signing → counterparty verification → tamper-evident audit record. Every step is post-quantum secured. Every output is independently verifiable.

01
Institution creates a root identity
Your institution generates an ML-DSA-65 root keypair, stored in your HSM — PKCS#11, Luna, Utimaco, or YubiKey. The root private key never leaves the hardware boundary. This is the institutional anchor for every credential your platform issues.
02
Institution issues a credential post-KYC
After a user passes your KYC process (Sumsub native integration, or your existing provider), your institution signs and issues a credential encoding role, authority scope, jurisdiction, and expiry. Credential issuance is an authorised institutional act — logged, signed, and auditable.
03
Credentialed user signs documents and transactions
The user holds their credential and keypair. When they execute a document, submit a regulatory filing, or authorize a transaction, they produce an ML-DSA-65-signed, self-contained JSON envelope — portable, independently verifiable, and permanently associated with their institutional credential.
04
Any counterparty verifies the full chain offline
A bank, regulator, law firm, or exchange verifies the complete trust chain — user signature → credential → institutional root — with no API call, no vendor server, and no SLA dependency. The math is the guarantee. The signed envelope includes everything required for verification.
05
Every event is appended to a tamper-evident, ML-DSA-65-signed audit log
Credential issuances, document signings, key rotations, and revocations are appended to an append-only, SHA-256-chained NDJSON log — each entry individually signed by the institution's root key. No entry can be modified, deleted, or reordered without detection. The log is independently verifiable in full by any party holding your institution's public key. This is the audit trail your compliance and legal teams need.

Built for every team
that has something to lose.

Compliance teams
Audit-ready by design.
  • ML-DSA-65-signed, hash-chained audit logs provide forensic-grade proof of integrity — no entry can be silently altered or deleted
  • Full compliance with NIST FIPS 203/204 — demonstrate PQC migration progress ahead of regulatory deadlines
  • Credential lifecycle records (issuance, revocation, expiry) exportable for regulatory reporting and legal discovery
  • Sumsub KYC integration links every credential to a verified identity — satisfies FATF travel rule and AML requirements
  • Jurisdiction and authority scopes encoded in each credential — auditors can verify who was authorised to sign, under what mandate
Legal teams
Signatures that hold up.
  • ML-DSA-65 signatures on executed documents are legally binding in jurisdictions recognising electronic signatures — with a stronger cryptographic proof of authorship than most current platforms provide
  • Self-contained verification envelopes allow a counterparty to verify a signed document without calling a third-party API — critical for disputed or archived documents
  • Credential chains prove not only who signed, but under what institutional authority and within what scope — essential for regulated transactions and cross-border agreements
  • Signed documents remain cryptographically valid after NIST deprecation deadlines; RSA-signed documents will not
Security teams
Zero-trust cryptographic architecture.
  • Keys never leave the HSM boundary in production — PKCS#11 support for SoftHSM2, Luna, Utimaco, and YubiKey
  • ML-KEM-768 + X25519 hybrid encryption for all inter-service communication — defeats harvest-now-decrypt-later on data in transit
  • Post-quantum file vault (ML-KEM-768 + AES-256-GCM) future-proofs archived documents against quantum decryption
  • Hybrid webhook signing (HMAC-SHA-256 + ML-DSA-65) provides non-repudiable machine-to-machine authorization
  • No custom cryptography — all algorithms build on Cure53-audited, publicly verifiable open-source implementations of NIST standards
Technology teams
API-first. Deployable anywhere.
  • REST and WebSocket API-first architecture — integrates with existing identity, compliance, document management, and audit systems
  • White-label UI deployable under your domain and brand — no "Powered by X" on client-facing surfaces
  • On-premise, private cloud, or managed service deployment — your data never leaves your infrastructure unless you choose otherwise
  • Built on thirteen packages — eleven open-source — the cryptographic implementation is a transparent, peer-reviewable codebase, not a black box
  • Node 20+ / TypeScript / standard PKCS#11 — integrates with existing enterprise infrastructure without protocol rewrites

Everything required
for institutional deployment.

Identity · ML-DSA-65
Hierarchical credential issuance
Institution-to-user trust chains. Each credential encodes role, authority scope, jurisdiction, and expiry — signed by the institution's HSM-held root key. Revocation is immediate and propagates downstream. Sumsub KYC native integration.
Signing · FIPS 204
Legally binding document signing
ML-DSA-65 signatures on any document, transaction, or payload. Each signature produces a portable, self-contained JSON envelope independently verifiable by any party with the signer's public key — no vendor dependency at verification time.
Compliance · Append-only
Tamper-evident audit logging
Every credential event, signing event, key rotation, and revocation appended to an ML-DSA-65-signed, SHA-256-chained NDJSON log. No entry can be modified, deleted, or reordered without detection. Full integrity verification in one command.
Key storage · PKCS#11
Hardware Security Module management
PKCS#11 backend supporting SoftHSM2, Luna, Utimaco, and YubiKey. Encrypted FileBackend (Argon2id + AES-256-GCM) for staging. MemoryBackend for development. Identical API across all backends — swap without application changes.
Attestation · Portable
Cryptographically signed attestations
Create signed attestation envelopes for any structured payload — term sheets, trade confirmations, regulatory submissions, identity assertions. Self-contained envelopes include all verification material. No expiry on offline verification.
Encryption · ML-KEM-768
Post-quantum file vault
Encrypt sensitive documents for one or multiple recipients using ML-KEM-768 + AES-256-GCM. Each recipient gets an independently decryptable content key. Defeats harvest-now-decrypt-later on archived documents. CLI and library interfaces.
Channels · Hybrid KEX
Post-quantum secure communication
ML-KEM-768 + X25519 hybrid key exchange, AES-256-GCM data encryption. Wraps existing TLS connections, Node.js streams, or WebSockets — no protocol rewrite required. Eliminates harvest-now-decrypt-later risk on inter-service traffic.
Verification · Zero-dependency
Offline browser-safe verifier
Any signed document or credential can be verified entirely client-side — in a browser, offline, without a vendor API. No server. No SLA dependency. No network call at verification time. The verification logic is open-source and independently auditable.

The technology is transparent
by design.

KXCOIdentity is the enterprise deployment layer built on top of thirteen production-grade packages — eleven open-source under Apache-2.0/MIT, and two commercial packages for on-chain anchoring and machine identity. The same stack running in production across five live institutional deployments. The cryptographic claims are not marketing assertions. They are publicly auditable code.

kxco-pqUmbrella package — installs the full stack
kxco-pq-sdkHierarchical quantum-resistant identity management
kxco-pq-hsmHardware Security Module key management
kxco-pq-auditTamper-evident audit logging
kxco-pq-attestCryptographically signed attestations
kxco-pq-tlsPost-quantum secure communication channels
kxco-pq-vaultPost-quantum file and data encryption vault
kxco-post-quantum-webhookHybrid webhook signing
kxco-post-quantumCore post-quantum cryptographic primitives
kxco-pq-cliCommand-line tooling for key management
kxco-verifyZero-dependency browser-safe attestation verifier
kxco-pq-chainMeta-transaction relay client — ML-DSA-65 signed intents, Armature L1 — commercial
kxco-pq-agentMachine identity for AI agents, robots & IoT — commercial
10,900+
Monthly downloads
Cure53
Security auditor, 2024
11 of 13
Packages open-source
Zero
Custom cryptography

All cryptographic operations delegate to @noble/post-quantum — the dependency-free TypeScript reference implementation of NIST's August 2024 post-quantum standards, audited by Cure53. View SDK documentation →

Why institutions are moving now

The window is not closing.
It has already closed.

The standard objection is: "Quantum computers capable of breaking RSA don't exist yet — we have time." That objection misunderstands the threat model. The attack does not require a quantum computer to exist when your documents were signed. It only requires one to exist when someone wants to read them.

2022NIST selects final post-quantum cryptography standards after six years of open international competition.
2024NIST publishes FIPS 203 and 204. The standards are final. Harvest-now-decrypt-later collection is already underway. KXCOIdentity is production-compliant from day one.
2026NSA mandates PQC for all new national security procurement. Institutions with government counterparties face downstream requirements. New ECC/RSA systems cannot be approved.
2030NIST deadline to deprecate RSA-2048 and ECC-256 across US federal infrastructure. Documents signed under legacy algorithms lose cryptographic standing.
2035NSA CNSS Policy 15: full migration without exception. Any institution still operating on ECC or RSA is non-compliant with allied government requirements.

Institutions that deploy KXCOIdentity now gain regulatory headroom, audit defensibility, and counterparty trust. The institutions that treat post-quantum migration as a 2030 problem will spend 2027–2029 in emergency remediation — on a fixed deadline, under scrutiny, without the luxury of a careful rollout.

Not a roadmap.
A track record.

KXCOIdentity is not in development or pilot. The same cryptographic stack powers five live institutional deployments — running under regulation, with real users, real signing events, and real audit trails.

Custody Software
KnightsVault
Post-quantum credentials and signing across custody operations. ML-DSA-65 on every authorised action. FIPS 140-3 HSM integration. Six active custodian clients.
White-Label Banking
KXCO Bank
Institutional banking platform with quantum-resistant identity at the authentication and authorisation layer. Deployed under licensed financial institution brands.
AI Compliance Intelligence
The Exchequer
ML-DSA-65-signed compliance reports and regulatory outputs. Hash-chained audit records across every query, finding, and recommendation issued by the platform.
Automated Trading
KnightsBot
Every trade order, strategy change, and execution log carries a non-repudiable ML-DSA-65 signature. Machine-to-machine authorization through the webhook signing layer.
L1 Blockchain
Armature L1
QBFT PoA permissioned chain with ML-DSA-65 signatures on every transaction and block attestation. KXCOIdentity credentials gate validator participation and on-chain governance.
Your institution
Deployment 6
Request a Demo →
NIST FIPS 203 (ML-KEM-768) aligned NIST FIPS 204 (ML-DSA-65) aligned Cure53 security audit 2024 PKCS#11 HSM — Luna, Utimaco, YubiKey Apache-2.0 / MIT open-source Anthropic MCP Certified — Shayne Heffernan, 2026

Partner logos, external audit reports, and client references available under NDA upon request.

Institutional pricing.
White-label included in every tier.

All plans include white-label deployment rights, HSM integration, full SDK access, and dedicated onboarding. Priced for regulated institutions — not per-seat SaaS.

Foundation
Foundation
Single-entity deployment. Up to 500 credentialed users. Ideal for regulated fintechs and single-jurisdiction platforms beginning their PQC migration.
  • Unlimited credential issuance
  • Unlimited document signings
  • 3-year audit log retention
  • FileBackend + SoftHSM2 HSM support
  • White-label UI — your brand
  • Cloud or on-premise deployment
  • Standard support — business hours
  • Standard compliance documentation
Contact Sales →
Enterprise
Enterprise
Unlimited scale. Custom infrastructure. For tier-1 banks, global custodians, law firms, and platforms with bespoke deployment, compliance, and SLA requirements.
  • Everything in Professional
  • Configurable audit retention
  • Custom PKCS#11 HSM integration
  • On-premise, private cloud, or managed
  • Dedicated 24/7 SLA support
  • Custom compliance documentation
  • CMVP certification pathway support
  • Dedicated implementation team
Contact Sales →

All plans require a minimum annual commitment. Volume pricing available for multi-entity group deployments. Academic and government pricing available on request.

Deploy quantum-resistant identity
before your counterparties require it.

KXCOIdentity is production-ready today — running under regulation across five live deployments. The institutions that define the post-quantum compliance standard will set the terms for everyone else.

Questions? Email shayne@knightsbridgelaw.com
Technical documentation at chain.kxco.ai/developers/sdk