G7 Puts Post-Quantum Cryptography on the Clock
The G7's call to action reframes post-quantum cryptography as a near-term threat. What its five priorities mean for your migration plan.
Seven national cybersecurity agencies signed the same document last Thursday, which does not happen often. On September 3, the G7 Cybersecurity Working Group published “Preparing for the Post-Quantum Era: A Call to Action,” a short joint statement telling decision makers in both sectors that post-quantum cryptography is no longer something they can defer to a future budget cycle. ANSSI drafted it, chairing the working group under France’s 2026 G7 presidency. Canada, Germany, Italy, Japan, the UK and the US all signed. The European Commission and ENISA backed it.
If you have been reading PQC guidance for the past two years, none of the technical advice will surprise you. That is sort of the point.
What the document actually says
The interesting language is about framing, not technique. The G7 asks readers to move the quantum threat “from a distant future problem” to “a near-term threat that demands action across all sectors, not just critical infrastructure.” That last clause is doing real work. Most national guidance so far has aimed at operators of essential services and defense suppliers. This one says the perimeter is wider.
The threat model is the familiar one, and the statement hedges honestly: “Although the exact timeline is uncertain, several recent advances suggest an anticipation of the development of quantum computers able to break widely used public-key cryptography.” That is diplomatic phrasing for something simpler. The estimates keep moving, and they keep moving in one direction.
The practical advice runs about four sentences. Inventory your cryptographic assets. Map the dependencies. Rank systems by how badly a decryption several years from now would hurt, then migrate in that order. Buy PQC-capable products at your normal refresh cycle instead of running a separate replacement program.
That last one deserves more attention than it usually gets. The cost of PQC migration is mostly not the cryptography. It is the unscheduled hardware and license spend you eat when you discover in 2029 that a load balancer nobody documented cannot negotiate ML-KEM. Write PQC support into your procurement requirements now and a lot of that cost disappears into budgets you were going to spend regardless.
Five priorities, and who they land on
The document lists five areas: awareness, national strategies, research and development, public-private partnership, and integrating PQC into cybersecurity requirements.
Four of those are work for governments. The fifth is the one that reaches your desk. “Integrating PQC into cybersecurity requirements” means regulators writing quantum-safe algorithms into rules you already have to comply with, and large buyers writing them into contracts. Once that happens, PQC stops being an initiative your security team has to justify to a CFO and becomes a compliance item somebody else enforces on a schedule you do not control.
The part with teeth
Joint statements are non-binding, and a certain amount of cynicism about them is healthy. What makes this one worth tracking is what the signatories are doing separately.
ANSSI has already said it will stop certifying products that lack quantum-safe cryptography starting in 2027, with PQC becoming mandatory in procurement for some categories of security product by 2030. If you sell security hardware or software into France, that is a product roadmap date, not a policy aspiration. On the US side, CNSA 2.0 and the executive order timelines already point at 2030 and 2033 for various classes of system. Microsoft, Google and AWS have all published their own dates.
The G7 statement adds no new deadline. What it does is stitch the existing ones into a shared position, which makes it considerably harder for a vendor to tell one national regulator that nobody else is asking for this.
What to do about it this week
Nothing here changes what a competent migration plan looks like. It changes the conversation you can have about funding one.
Start at your TLS termination points. Hybrid key exchange is deployable there today, with real client support and no certificate chain problems to solve first. X25519MLKEM768 is on by default in Chrome and Firefox and supported across the major CDNs. If your edge is not negotiating it, that is a configuration gap you can close this quarter, and it remains the cheapest reduction in harvest-now-decrypt-later exposure available to most organizations.
Signatures are the harder half and they are further out. ML-DSA certificates are still not something you can get from a public CA at any scale, and the chain size problems are genuine. Nobody sensible expects you to have solved that yet. What they increasingly do expect is that you know how many certificates you have and which algorithm each one uses.
You have probably read a version of that advice before. The difference this week is that seven governments put their names to it in the same paragraph, and one of them starts refusing to certify products without PQC next year.