Quantum-safe by accident

Whether a government site is post-quantum depends first of all on who hosts it. 207 of the 559 sites sit behind a CDN or a cloud front door, and 94% of those negotiate the hybrid, because Cloudflare, Akamai, Amazon CloudFront and Azure Front Door switched it on for their customers. Of the 352 sites served from governments’ own data centres, state IT providers or plain cloud servers, 17% do.

So the ranking mostly shows how each country hosts its websites. Malta, Estonia, Ireland and Lithuania put nearly everything behind a CDN and come out on top. Croatia, Latvia, Luxembourg and Slovenia host nearly everything with one state provider that has not switched post-quantum on, and come out at or near zero.

State hosting does not have to mean classic cryptography. Of the sites run by Germany’s federal IT service ITZBund, 11 of 11 use post-quantum key exchange; Austria’s Bundesrechenzentrum, 9 of 9; Romania’s Special Telecommunications Service, 13 of 17. Croatia’s FINA (0 of 25), Latvia’s LVRTC (0 of 21), Luxembourg’s CTIE (1 of 31), Spain’s ministry network (0 of 16), Belgium’s BELNET (0 of 15), Slovakia’s GOVSK (0 of 15), Denmark’s Statens IT (0 of 11) and Hungary’s NISZ (0 of 8) have not switched it on. For most of them it is a software upgrade, not a procurement.

The case for digital sovereignty, often made against American CDNs, is not a case against post-quantum: the German and Austrian state providers show that national infrastructure can do both.

Of the 27 member states, 7 have published a national post-quantum migration plan with dates: Estonia, France, Germany, Lithuania, the Netherlands, Romania and Sweden. Another 9 have official guidance without a national timetable, and 11 have nothing beyond a line in a strategy, or nothing at all: Austria, Bulgaria, Croatia, Cyprus, Greece, Hungary, Ireland, Luxembourg, Malta, Poland and Portugal. On 13 October the European Commission’s page of national PQC resources still listed only France and the Netherlands.

Plans and practice go together. 72% of the sites in the countries with a plan use post-quantum key exchange, against 37% elsewhere, and the gap holds on governments’ own servers too (49% against 9%), mostly thanks to Germany. That does not mean a plan switches anything on; more likely the same administrations that write plans also keep their servers up to date. Every country in the table links to the document we found, so the column can be checked.

56 of 81 sites of EU institutions, bodies and agencies use post-quantum key exchange (69%). All 55 behind a CDN do: most of europa.eu runs through Amazon CloudFront. Of the 26 on their own or plain cloud servers, 1 does.

For 6 of them TLS 1.2 is still the newest version, which rules post-quantum out entirely: the Court of Justice (curia.europa.eu), the Court of Auditors, CERT-EU itself, the European Banking Authority, the European Data Protection Board and the European Maritime Safety Agency.

United States. 22 of 24 front doors of the federal government use post-quantum key exchange: the White House, Congress, the 15 executive departments, the IRS, Census, CISA and login.gov. The exceptions are whitehouse.gov (TLS 1.3 without the hybrid) and va.gov (TLS 1.2 only). Across all 1,065 federal .gov domains that answered, it is 60%. The mechanism is the same as in Europe (94% behind a CDN, 8% without); US federal sites simply sit behind CDNs more often.

United Kingdom. Central government lives on GOV.UK, which runs behind Fastly, and the few other sites (Parliament, the Royal Household, NCSC, ONS, GOV.UK One Login) are behind Cloudflare or CloudFront: 6 of 6.

Ukraine. 19 of 26 of the core sites, and 75 of 102 across all central executive bodies and regional military administrations (74%). That is well above the EU average, for the same reason: most Ukrainian state sites are served through Cloudflare, Akamai or CloudFront.

Post-quantum key exchange protects today’s traffic against “harvest now, decrypt later”: recording encrypted sessions now and decrypting them once a large quantum computer exists. Browsers already offer it. The server only has to accept it, and for most sites that is a configuration or upgrade, not a project.

1. Enable TLS 1.3. Hybrid post-quantum groups exist only in TLS 1.3. A site that still stops at TLS 1.2 cannot offer them, even behind a CDN that supports them.
2. Behind a CDN or a cloud front door: check the edge settings rather than your server. In our data every site served through Cloudflare, Akamai, Amazon CloudFront or Azure Front Door with TLS 1.3 on negotiated post-quantum key exchange; the exceptions had TLS 1.3 switched off.
3. On your own servers: OpenSSL 3.5 or newer offers X25519MLKEM768 by default, so nginx, Apache or HAProxy built against it need no change, unless the configuration pins the key-exchange groups. If it does, put the hybrid first, for example ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1:secp384r1; in nginx.
4. Behind a WAF, load balancer or DDoS service that terminates TLS: that device decides. Ask the vendor for its post-quantum setting; in our data, sites behind Radware and F5 Distributed Cloud did not offer it.
5. Check it like a visitor: in Chrome, DevTools → Security shows the key exchange (look for X25519MLKEM768), or run openssl s_client -connect example.gov:443 -groups X25519MLKEM768 with OpenSSL 3.5+.

Certificates stay classical for now: no browser accepts post-quantum certificates yet, so there is nothing to change there in 2026.

What we measured. For each site we did what a browser does on a first visit and nothing more: DNS lookups, a TLS handshake that offers X25519MLKEM768, X25519, P-256 and P-384 the way current Chrome and Firefox do, and one HEAD / request. A site counts as post-quantum when it chose the hybrid group. When a site chose a classic group, a second handshake offered the hybrid alone, to tell sites that support it from sites that don’t. When the first handshake failed, a third one with a small classic hello checked whether the larger post-quantum hello was the problem. No port scans, no vulnerability checks, nothing behind a login.

Which sites. One rule for every country: the national government portal and the main e-services portal, the national eID login if it has its own site, the head of state, the government, each chamber of parliament, every ministry of the current government, the tax and customs administration, the statistics office, the national cyber agency and CSIRT. One row per distinct website: where ministries live as pages of one government portal (Poland, Slovenia, the Netherlands, the UK), that portal counts once. The lists come from each government’s own pages and were checked in October 2026; every row in the dataset links its source. The US comparison also includes every federal .gov domain from CISA’s public list.

From where. 13 October 2026, from four points: Nuremberg and Helsinki (the European figures), Ashburn in the US (the US figures), and Ukraine (de-nbg1, fi-hel1, ua-home, us-ash). The points agreed on the result for almost every site. Where the browser-like handshake failed from the main point and completed from another (a few German federal sites are slow from the US; a Portuguese anti-DDoS service resets some connections), we used the completed one. No site failed it consistently: none of them breaks on the larger post-quantum hello. A second, slower pass retried every site that did not answer, because some state networks block a burst of connections as if it were an attack.

What it does not show. This is the front door only: one hostname per site, no internal systems, no e-mail, VPNs or APIs, and nothing about cryptographic inventories or migration plans. A small country has few sites, so its share moves a lot with one site; the table gives the 95% confidence intervals. Some sites block traffic from outside their country or from data centres. A CDN in front of a site says nothing about the connection from the CDN to the government’s own server.

Corrections. If a row is wrong or a site is missing under the rule above, write to the address below and we will fix it in the next edition. We repeat the scan every few weeks until the EU deadline and publish what changed; the January 2027 edition covers the deadline itself.