FAQ · Security
Is the service ready for post-quantum cryptography?
What is the post-quantum threat?
A large enough quantum computer could break the public-key cryptography used today (RSA and elliptic curves). Someone can record encrypted traffic now and decrypt it later ("harvest now, decrypt later"). So protection has to start before such computers exist.
Where is post-quantum cryptography used?
The service uses hybrid schemes: they combine a classical algorithm with a standardised post-quantum one, so security holds if either fails.
| Where | How |
|---|---|
| Connections to the service | TLS 1.3 with hybrid X25519 + ML-KEM-768 key exchange, when the client supports it |
| Signed receipts and bundles | Dual Ed25519 + ML-DSA-65 signature (decision receipts, computer policies, appliance configuration, Windows agent updates) |
| Sealing secrets for appliances | X25519 + ML-KEM-768 |
| Privileged access escrow key | X25519 + ML-KEM-768, held by the customer |
What about passkeys?
Passkeys follow the WebAuthn standard and today use classical signatures, defined by operating systems and browsers. When these offer post-quantum algorithms, the service can accept them. The "harvest now, decrypt later" risk does not apply to a sign-in signature, which is only valid at that moment.
What about the approver phone?
The phone's approval key is generated in Android's secure chip, which uses elliptic curves today. The phone's connection to the service uses TLS 1.3 with hybrid key exchange when the system offers it; the account details on the phone show the key exchange used.
How can I verify a receipt?
Developers can verify both signatures on a receipt; see Verify receipts.
Was this page helpful?
Thank you. Your answer stays in this browser; nothing is sent.
Sorry about that. Try:
- searching for the exact text of the message or the error code
- the error code index
- asking your organization's administrator