Post-Quantum Readiness
In one line
How we prepare our encryption for future quantum computers, what is in place today, what is planned, and what nobody can do yet. There is no recognised post-quantum certification for a website, and we do not claim one.
The short version
This short version helps you understand the full text. Read the full text for the complete terms.
- Future quantum computers may break some of the encryption the internet uses today. Someone could record encrypted data now and read it later. (Section 1)
- Most connections to qypu, and from qypu to the AI and social platforms we use, already use a post-quantum key exchange. (Section 3)
- Our plan to protect stored platform tokens and signed records with post-quantum methods is designed and built, but not yet in use. (Section 4)
- Some parts cannot be post-quantum yet, because they belong to other companies or to your browser. (Section 5)
- We follow the NIST standards FIPS 203, FIPS 204, and FIPS 205. (Section 6)
- No one issues a recognised "post-quantum certified" badge for a website. We do not claim one. (Section 7)
Full text
Read the full text (about 4 minutes)
1. Why this matters
Encryption keeps your data private on the way to us and while we store it. Much of it relies on maths that a large quantum computer could solve. No such computer exists today. But an attacker could record encrypted traffic or steal encrypted files now, and decrypt them years later. This is called "record now, decrypt later".
The data most at risk is data that must stay secret for years: the tokens that let us post to your social accounts, your brand details, and the authorisations you sign. That is where we start.
2. How to read this page
- In place: running today, and checked by us.
- Planned: designed or built, not yet relied on. No date unless stated.
- Not yet possible: outside our control today. We say why and what we will do.
3. In place
| What | Detail | Status |
|---|---|---|
| Your browser to qypu | Connections use the hybrid key exchange X25519MLKEM768 when your browser supports it (Chrome 131+, Firefox 132+, Safari 26+). We checked qypu.ai on 10 October 2026. | In place |
| qypu to our hosting and AI providers | Connections to our hosting network, our AI gateway, our AI model provider, and our file storage used X25519MLKEM768 in our check on 10 October 2026. | In place |
| qypu to social platforms | Connections to the Meta, Google, LinkedIn, and TikTok APIs used X25519MLKEM768 in the same check. | In place |
| Stored platform tokens | Encrypted with AES-256-GCM using 256-bit keys. Quantum computers are not expected to break 256-bit symmetric encryption in practice. | In place |
These hops protect the key exchange. The certificates that prove a server's identity are still classical. That is a smaller risk, because an attacker would have to break them in real time, not later.
4. Planned
| What | Detail | Status |
|---|---|---|
| Hybrid protection for stored tokens | Wrap each token's key with both a classical method (X25519) and a post-quantum one (ML-KEM-768). An attacker would have to break both. | Planned (built, in review, not in use) |
| Hybrid signatures | Sign approvals, authorisations, and our audit log with both Ed25519 and ML-DSA-65. Long-lived root keys may use SLH-DSA. | Planned (built, in review, not in use) |
| Stronger long-term fingerprints | Use SHA-384 for records we keep for years. | Planned |
| Calls between our own services | Short-lived, hybrid-signed service tokens and post-quantum key exchange on every hop. | Planned |
| Our database connection | Move the database connection behind a post-quantum link. Today we cannot confirm this hop. | Planned |
5. Not yet possible
| What | Why | What we do |
|---|---|---|
| Sign in with Google, Meta, and other providers | Their sign-in tokens use classical signatures. Only they can change that. | We keep their tokens short-lived and wrap them in our own encryption at rest. |
| Website certificates | Browsers and certificate authorities do not yet accept post-quantum certificates. | We will adopt them when browsers support them. Nothing changes for you. |
| Older browsers | Older browsers cannot use the post-quantum key exchange. They fall back to classical encryption, which is still secure today. | Keep your browser up to date. |
| Some hosting hops | Not every provider confirms post-quantum support on every connection, such as some database connections. | We list these hops as Planned and check them again. |
6. Standards we follow
- FIPS 203 (ML-KEM): post-quantum key exchange, published by NIST in August 2024.
- FIPS 204 (ML-DSA): post-quantum signatures, NIST, August 2024.
- FIPS 205 (SLH-DSA): hash-based signatures, NIST, August 2024.
- Hybrid key exchange in TLS: the X25519MLKEM768 group used by browsers and our providers (IETF RFC 10024). ETSI TS 103 744 describes the same hybrid approach.
- Timelines: the UK NCSC asks organisations to finish planning by 2028, move the most important systems by 2031, and finish by 2035. A US executive order of June 2026 sets 2030 and 2031 for federal systems. We aim to be well ahead of both.
7. Certification
There is no recognised certification that says a website or service is "post-quantum secure". We do not claim one, and we will not use phrases such as "quantum-proof".
What does exist: NIST tests cryptographic modules under FIPS 140-3. In our check on 10 October 2026, post-quantum modules were in the NIST queue, but we could not confirm any validated module certificate that covers ML-KEM. The algorithms we use come from standard software libraries (OpenSSL 3.5 in Node.js). They are not a FIPS 140-3 validated module in our setup. If that changes, we will say so here.
8. Crypto-agility
Every encrypted item and signature we create carries a label that names its method and version. All our encryption code lives in one place. If a method is weakened, we can switch to a new one and re-protect stored data without rewriting the service. We review this page at least once a year and whenever the standards change.
9. Sources
- NIST, FIPS 203, 204, and 205 (August 2024): csrc.nist.gov
- NIST CMVP validated modules search: csrc.nist.gov/projects/cryptographic-module-validation-program
- UK NCSC, "Timelines for migration to post-quantum cryptography": ncsc.gov.uk/guidance/pqc-migration-timelines
- US Federal Register, "Securing the Nation Against Advanced Cryptographic Attacks" (25 June 2026)
- ETSI TS 103 744 V1.2.2, Quantum-safe Hybrid Key Establishment
- IETF RFC 10024, PQ/T Hybrid Key Agreement for TLS 1.3
- Vercel, "Vercel now supports post-quantum cryptography" (7 November 2025); Cloudflare SSL/TLS docs, "Post-quantum cryptography"
- Our own connection checks: OpenSSL 3.5.7, 10 October 2026
Change log
- 2026-10-10 - 0.1.0 - First draft, based on our post-quantum review and connection checks of 10 October 2026.
Open questions for counsel
We publish these while the page is a draft, so you can see what is not settled yet.
- Public representation. Re-run the connection checks before publication; every "In place" row must be true in production.
- Do not describe qypu as "quantum-safe", "quantum-proof", or "post-quantum certified" anywhere.
Useful for: Business owners, IT and security reviewers, Platform reviewers. To save this page as a PDF, use your browser's Print command. Back to the trust centre.