Sapherbox logoSapherboxBlog
All articles

Post-quantum security: who has already written the requirements, and what they ask of you

NIST, the EU, BSI, ANSSI, the UK NCSC and the NSA have all published post-quantum timelines. What they agree on, where the dates fall, and how to read them for an encrypted document platform.

Also available in Deutsch

Post-quantum cryptography has left the research phase. Between 2022 and 2026 the agencies that set cryptographic requirements for governments, banks, operators of critical infrastructure and their suppliers have each published a position, and most of them have published dates. The question for anyone who stores confidential documents is no longer whether to prepare but which document to read first and what it actually asks for.

This article is that reading list. It covers who has defined requirements, what each one says, the dates they converge on, and the handful of demands that appear in every one of them. At the end it says where Sapherbox stands against that list.

Why there are deadlines at all

No quantum computer that can break RSA or elliptic-curve cryptography exists today. The deadlines exist because of a specific attack that does not need one yet. An adversary who records encrypted traffic or copies encrypted storage now can keep it and decrypt it when a capable machine arrives. For data whose confidentiality must hold for ten or twenty years, contracts, medical records, personnel files, legal correspondence, the exposure starts at the moment of recording, not at the moment of decryption. Every authority below cites this harvest-now-decrypt-later risk as the reason to move key establishment first and signatures second. We have described the mechanics separately; this article is about who requires it.

NIST: the algorithms and the end dates

The United States National Institute of Standards and Technology ran the competition that produced the algorithms everyone else now references. In August 2024 it published the first three standards: FIPS 203, the key encapsulation mechanism ML-KEM, formerly Kyber; FIPS 204, the signature scheme ML-DSA, formerly Dilithium; and FIPS 205, the hash-based signature scheme SLH-DSA. When a European guideline says “a standardised post-quantum KEM”, this is what it means.

In November 2024 NIST followed with the draft of IR 8547, the transition plan. It deprecates the 112-bit security level, which covers RSA-2048 and the P-256 curve, by 2030, meaning no new deployments, and disallows every quantum-vulnerable public-key algorithm, including RSA-3072 and P-384, by 2035. The document is still formally a draft, but United States federal guidance already uses its dates as the planning baseline, and vendors selling into regulated markets anywhere have adopted them as the de facto horizon.

The European Union: a coordinated roadmap with three milestones

The European Commission issued a Recommendation on 11 April 2024 asking member states to develop a coordinated approach. The NIS Cooperation Group, the body in which member states coordinate the implementation of the NIS2 directive, set up a post-quantum workstream and published its Coordinated Implementation Roadmap in June 2025. It has three milestones.

By the end of 2026, every member state should have a national transition roadmap and should have started pilots for high- and medium-risk use cases. The groundwork named for this phase is a quantum risk analysis, a cryptographic inventory and vendor engagement.

By the end of 2030, the transition for high-risk use cases should be complete. The roadmap names government communications, public key infrastructures and software and firmware update systems, and more generally any use case where confidentiality has to hold for a long time or where a compromise would be severe.

By the end of 2035, medium-risk use cases should be migrated as well, with hybrid or standardised post-quantum cryptography deployed wherever technically and economically feasible.

The roadmap is explicit that the preferred form is hybrid: a classical algorithm and a post-quantum algorithm combined so that both would have to fail. That is not a European idiosyncrasy. It is the position of every European agency that has written on the subject.

BSI, ANSSI and the joint statement

On 30 November 2024 Germany’s BSI, France’s ANSSI and the Dutch agencies, joined by fifteen further member states, published a joint statement titled Securing Tomorrow, Today. It is short and worth reading in full. It calls the transition urgent, strongly recommends hybrid deployment over standalone post-quantum algorithms, and sets out the same preparatory steps as the EU roadmap: a quantum threat analysis, a risk-oriented transition plan, and crypto-agility, meaning systems built so that an algorithm can be replaced without redesigning the product.

The BSI’s own Technical Guideline TR-02102-1, the document German auditors reach for when they assess cryptography, was updated in January 2026. It recommends hybrid classical-plus-post-quantum key establishment for any use case that needs long-term confidentiality, names ML-KEM, FrodoKEM and Classic McEliece as acceptable post-quantum mechanisms, and attaches a date of its own: purely classical key agreement is recommended only until the end of 2031. For a German organisation under NIS2, KRITIS obligations or a BSI C5 attestation, that is the sentence that turns a recommendation into a finding.

The United Kingdom and the United States

The UK National Cyber Security Centre published its migration timeline in March 2025. By 2028 an organisation should have completed discovery across its estate and have an initial migration plan. By 2031 the highest-priority services should be migrated and the plan refined. By 2035 the migration should be complete. The guidance has no statutory force, but it gives boards, auditors and insurers dates to ask questions against.

The United States National Security Agency’s Commercial National Security Algorithm Suite 2.0, published in September 2022 for national security systems, is the most prescriptive of the set. It names ML-KEM-1024 for key establishment and ML-DSA-87 for signatures, requires new software and firmware to be signed with post-quantum algorithms from 2025 and all deployed software by 2030, and requires web browsers, servers and cloud services to support and prefer the new algorithms from 2025 and to use them exclusively by 2033. Few organisations outside that scope are bound by it, but its dates are what suppliers to government build to, and that shapes what the rest of the market can buy.

The rules that do not name an algorithm

A second set of requirements never mentions ML-KEM and binds more organisations than all of the above. The GDPR asks for security appropriate to the risk, taking into account the state of the art. NIS2 and DORA require cryptography and key management policies that reflect the state of the art and are reviewed against emerging threats. ISO 27001 and BSI C5 ask for a cryptography policy and for controls that are kept current.

None of these says “post-quantum by 2030”. All of them delegate the meaning of “state of the art” to exactly the documents listed above. When an auditor asks under one of these frameworks how an organisation handles the quantum threat, the acceptable answer in 2026 is an inventory, a risk assessment that distinguishes long-lived from short-lived confidentiality, and a plan with dates that are consistent with the EU roadmap or the BSI guideline. The answer “no quantum computer exists” is the one answer that is no longer accepted.

What every one of them asks for

Read together, the documents converge on five demands.

Know where you use cryptography. Every roadmap starts with an inventory: which systems, which algorithms, which key lengths, which protocols, which suppliers. You cannot migrate what you have not listed.

Sort by how long the secret must hold. Data that must stay confidential beyond the early 2030s is the high-risk bucket and moves first. Session keys for a video call are not; archived contracts are.

Move key establishment before signatures. Recorded ciphertext is the live risk. A forged signature only helps an attacker who has the quantum computer now.

Deploy hybrid. Combine a classical and a post-quantum algorithm so that a flaw in the young one does not reopen what the old one still protects. The EU, BSI, ANSSI and NCSC all say this; NIST allows it.

Stay agile. Whatever is deployed now must be replaceable, because the post-quantum algorithms themselves will be revised.

And the dates cluster: planning and inventory by 2026 to 2028, high-risk use cases by 2030 or 2031, everything by 2035.

Where Sapherbox stands against that list

We built the key layer to meet the first four demands and designed it for the fifth.

Every key that Sapherbox wraps is wrapped hybrid: RSA-4096 and ML-KEM-768 together, with the wrapping key derived from both so that neither alone opens anything. That applies to the key of every file, to the key bundles of folders, to the account master key held in escrow for recovery, and to the per-user search key. There is no RSA-only path left in the product; the server rejects a wrap that lacks the post-quantum half, and the desktop sync client and the macOS client implement the same scheme. In the vocabulary of the roadmaps, stored documents in Sapherbox are a high-risk, long-confidentiality use case that already uses standardised hybrid key establishment. We have described the construction in detail.

Signatures are classical. Share grants are signed with Ed25519, which is enough for the harvest-now threat, because a signature cannot be forged retroactively, and we will move to ML-DSA when its size and tooling make it practical in a browser. The algorithms are isolated behind one interface in each client, which is what crypto-agility means in practice.

For your own inventory, then, the line for Sapherbox reads: content and key establishment hybrid post-quantum at the end-to-end layer, signatures classical. We provide the algorithm list per layer in the security whitepaper so that the line can be copied rather than inferred.

What to do this year

If you are the person who has to answer the auditor, three steps cover the 2026 milestone of every roadmap above.

Make the inventory, and include suppliers. For each system that holds confidential data, write down which layer uses which algorithm, and ask the vendor to confirm it in writing. A vendor who cannot name the algorithm per layer has not done their own inventory.

Mark the data that outlives 2030. That is the set the EU roadmap and the BSI guideline want migrated first, and the set where a platform without hybrid key establishment is already a finding.

Ask three questions of every encryption product: Which layer is post-quantum, the transport or the stored data? Is it hybrid? Which standardised algorithm, and how would you replace it? The answers tell you more than any badge.

Questions?

If you are preparing a cryptographic inventory, mapping the EU roadmap or the BSI guideline onto your document storage, or want our algorithm list per layer in writing for an audit, get in touch at hello@sapherbox.com.