Skip to content
Labs
Sign inRequest a demo

Security and trust

Security is the product, so we hold ourselves to it

QUME and RCC are post-quantum from their first release, keep a tamper-evident record of what was done and put dangerous actions behind two people. Every product runs on premises or air-gapped when your data must stay home.

Request a security briefingWhy quantum-safe
What protects a QuantineliQ deployment, from the connection to the recordFive layers are stacked: hybrid post-quantum connections at the bottom, then signed instructions, two people for dangerous actions, tamper-evident records, and deployment on premises or air-gapped at the top.Connectionshybrid post-quantum key exchangeencryptInstructionssigned, and refused if alteredsignDangerous actionsa second person approvesapproveRecordshash-chained, verifiable offlineproveDeploymenton premises or air-gappedcontain
  1. Connections combine a classical and a post-quantum key exchange.
  2. Instructions and dangerous actions are signed and approved before anything acts.
  3. Every action lands in a record anyone can verify offline, on infrastructure you control.

Principles

How our products are built

  • Post-quantum from the start

    Hybrid key exchange (X25519 with ML-KEM-768) and post-quantum signatures (ML-DSA-65) alongside classical algorithms.

  • Signed instructions

    Commands, policies and packages are signed, and anything altered on the way is refused.

  • Tamper-evident records

    Hash-chained audit, anchored with signatures, verifiable offline with a public key.

  • Two people for dangerous actions

    Destructive and sensitive actions need a second person, enforced on the server.

  • Least privilege

    Roles grant tasks, not applications, and elevated actions need a security key.

  • Sovereign deployment

    On premises or fully air-gapped, with signed offline updates.

By product

Security in each product

QUME quantum-safeHybrid TLS, co-signed commands, built-in PKI and a cryptographic inventoryQUME identityFederation, capability roles, two-person approval and step-upQUME evidenceHash-chained audit, offline verification and write-once archiveRCC securityDevice management, quantum-safe, zero trust, evidence and SOC

Standards

The standards behind our cryptography and identity

ML-KEM · FIPS 203ML-DSA · FIPS 204LMS · RFC 8554X25519ECDSA P-256TLS 1.3RFC 8785 canonical JSONOIDCSAML 2.0FIDO2 / WebAuthnRADIUS · RFC 5176TACACS+

Practices

How we build and ship

  • Signed releases

    Releases and offline bundles are signed, and installers refuse what does not verify.

  • Software bill of materials

    Every release carries its components, matched against advisories.

  • Open-source policy

    Permissive licences only in shipped code, each adoption recorded.

  • Responsible disclosure

    A clear route for researchers, acknowledged and fixed in the open.

Questions

What security teams ask

Where is our data stored?

Where you deploy it. On-premises and air-gapped installations keep all data on your infrastructure; cloud tenants choose their residency.

Can we review your security design?

Yes. We brief security architects on the design, the cryptography and the controls, under NDA where needed.

How do we report a vulnerability?

See our responsible disclosure page.

Bring your security team

A briefing on architecture, cryptography and controls.

Request a security briefingResponsible disclosure