The State of Signatures on the WebOctober 2026
Once a month our own Domain Signature Health scanner makes one TLS handshake with each domain of the Tranco top 10,000 and with the most visited sites of nine countries, and records what comes back: the key-exchange group, the key that signs the site, the chain behind it, the protocol floor it accepts and how long its certificate is meant to live.
· 7,909 of 9,999 domains measured · 16,924 hosts in all lists · data below
- 7,909
- domains measured
- 58.7%
- negotiate post-quantum X25519MLKEM768
- 41%
- sign with ECDSA
- 84.8%
- negotiate TLS 1.3
- 27.8%
- still accept TLS 1.0
- 0.6%
- meet the 2029 rule today
of the top 10,000; 2,090 never completed a handshake
57.3% in the top 500
RSA is on 59% of leaf certificates
the remaining 15.2% settle for TLS 1.2
deprecated by RFC 8996 in 2021
median lifetime is 90 days
Key exchange
Post-quantum key exchange is already the majority
Every TLS connection starts by agreeing on a session key. This is the half of the post-quantum migration that cannot wait: a handshake recorded today can be decrypted by whoever owns a capable quantum computer later, however many years that takes.
Key exchange the servers picked
The group each of the 7,870 measured domains chose from the scanner's offer — X25519MLKEM768 first, then X25519 and the NIST curves, the order browsers use.
Show the numbers as a table
| Group | Domains | Share |
|---|---|---|
| X25519MLKEM768 | 4,620 | 58.7% |
| X25519 | 2,423 | 30.8% |
| P-256 | 703 | 8.9% |
| P-384 | 83 | 1.1% |
| P-521 | 41 | 0.5% |
Our scanner offers what a current browser offers — X25519MLKEM768 first, then the classical groups — and records the group each server picks. 4,620 domains (58.7%) chose the hybrid. X25519MLKEM768 runs the classical X25519 exchange and ML-KEM-768 (FIPS 203) side by side and mixes both secrets, so the session key stays safe as long as either half holds. Every post-quantum handshake we recorded used this hybrid; no server picked a pure ML-KEM group.
The ceiling is TLS 1.3. The hybrid groups exist only in TLS 1.3, so the 15.2% of domains that top out at TLS 1.2 cannot get there without a protocol upgrade first. Among the servers that do speak TLS 1.3, 68.9% already negotiate the hybrid. The rest picked plain X25519 or a NIST curve: a TLS stack without ML-KEM — OpenSSL before 3.5, Go before 1.24, older load-balancer firmware — or an explicit group list that leaves it out.
Countries
9 countries, one protocol, very different speeds
For each of this site's seven other languages we took the most visited sites of its main markets from the Chrome UX Report — Spain and Mexico for Spanish, mainland China and Taiwan for Chinese — and scanned them exactly like the world list.
X25519MLKEM768 by list
Share of the measured domains that negotiated the post-quantum hybrid: the world list, its top 500 and each country's most visited sites.
Show the numbers as a table
| List | Domains | Share |
|---|---|---|
| Tranco top 10,000 | 4,620 | 58.7% |
| Tranco top 500 | 197 | 57.3% |
| Mexico | 725 | 77% |
| Brazil | 712 | 73.6% |
| France | 720 | 73.1% |
| Germany | 727 | 72.8% |
| Spain | 676 | 68.4% |
| Taiwan | 629 | 66.8% |
| China | 608 | 63.2% |
| Japan | 557 | 58% |
| Russia | 258 | 27% |
Mexico leads with 77%; Russia trails with 27%. These are not the same websites seen from different places: each list is what people in that country actually open — its banks, retailers, media and government sites next to the global platforms everyone uses — so a country's figure describes how its own web is served.
| List | Measured | X25519MLKEM768 | ECDSA | TLS 1.3 | TLS 1.0/1.1 | A or A+ |
|---|---|---|---|---|---|---|
| Tranco top 10,000 | 7,909 | 58.7% | 41% | 84.8% | 29.5% | 61.6% |
| Mexico | 942 | 77% | 50.3% | 92.5% | 32.9% | 60.8% |
| Brazil | 971 | 73.6% | 52.9% | 90.4% | 38.6% | 56.5% |
| France | 988 | 73.1% | 48.7% | 93.8% | 23.5% | 72.2% |
| Germany | 999 | 72.8% | 51.8% | 94.8% | 24.8% | 72.3% |
| Spain | 991 | 68.4% | 40.1% | 87% | 23.6% | 66.1% |
| Taiwan | 947 | 66.8% | 46.7% | 85.9% | 43.7% | 45.2% |
| China | 963 | 63.2% | 55.1% | 87.9% | 61.5% | 33.3% |
| Japan | 969 | 58% | 27.9% | 78.1% | 31.9% | 56.3% |
| Russia | 955 | 27% | 29.8% | 79.3% | 40.4% | 52.5% |
The table puts the other figures side by side, and each country's page breaks them down further: key algorithms, the protocol floor, lifetimes and the CAs behind them. Two caveats belong next to it. The Chrome UX Report only sees Chrome users who share usage statistics; in mainland China, where Google is blocked and Chrome is a minority browser, that makes the list a small and unrepresentative slice, and Taiwan is the representative Chinese-language market. And the scan does not record who hosts a site, so we do not pin a country's gap on any particular provider.
Certificates
ECDSA vs RSA: still decided by defaults
Key exchange protects the session; the certificate proves who you are talking to. That side has not moved toward post-quantum at all, and between the two classical algorithms the call is still made by whatever requests the certificate — a CA's console or a hosting platform's automation, rarely a person.
Leaf certificate key algorithms
Share of the 7,909 domains that completed a handshake.
Show the numbers as a table
| Key family | Domains | Share |
|---|---|---|
| RSA | 4,669 | 59% |
| ECDSA | 3,240 | 41% |
RSA signs 59% of the leaf certificates and ECDSA 41%. Two key types do nearly all the work: RSA-2048 is 54.6% of everything, ECDSA P-256 40.4%.
Exact key types
Curve for elliptic-curve keys, modulus size for RSA.
Show the numbers as a table
| Key type | Domains | Share |
|---|---|---|
| RSA-2048 | 4,318 | 54.6% |
| ECDSA P-256 | 3,195 | 40.4% |
| RSA-4096 | 321 | 4.1% |
| ECDSA P-384 | 45 | 0.6% |
| RSA-3072 | 30 | 0.4% |
Issuing CAs, and what they issue
Issuing intermediates folded into the operator behind them. The bar is the CA's share; the table shows how the same certificates split between ECDSA and RSA.
Show the numbers as a table
| Certificate authority | Domains | Share |
|---|---|---|
| Google Trust Services | 2,169 | 27.4% |
| Let's Encrypt | 1,753 | 22.2% |
| Amazon | 1,106 | 14% |
| DigiCert | 1,074 | 13.6% |
| GlobalSign | 559 | 7.1% |
| Other / smaller CAs | 528 | 6.7% |
| Sectigo | 480 | 6.1% |
| GoDaddy | 70 | 0.9% |
| Smaller CAs (6) | 170 | 2.1% |
| Certificate authority | Certificates | ECDSA | RSA |
|---|---|---|---|
| Google Trust Services | 2,169 | 2,029 | 140 |
| Let's Encrypt | 1,753 | 799 | 954 |
| Amazon | 1,106 | 20 | 1,086 |
| DigiCert | 1,074 | 240 | 834 |
| GlobalSign | 559 | 51 | 508 |
| Other / smaller CAs | 528 | 65 | 463 |
| Sectigo | 480 | 27 | 453 |
| GoDaddy | 70 | 0 | 70 |
Google Trust Services issues the largest share of these certificates, 27.4%, and 93.5% of them carry an ECDSA key. Amazon (14%) is the opposite pole: 98.2% of its certificates are RSA, because RSA-2048 is the default key of a certificate requested through its console. Let's Encrypt (22.2%) sits in between at 45.6% ECDSA — it signs whatever key the site's ACME client generates, so its split is a census of client defaults rather than a policy of its own. If you want the smaller, faster key, you usually still have to ask for it; our ECDSA vs RSA comparison covers what changes when you do.
The 47-day countdown
Lifetimes: automation splits the web in two
The CA/Browser Forum has put public certificate lifetimes on a schedule (ballot SC-081): 200 days from March 15, 2026, 100 days from March 15, 2027, 47 days from March 15, 2029.
Certificate lifetime distribution
Total notBefore → notAfter validity of the leaf certificate, for the 7,909 domains measured. The highlighted bucket is the one that already satisfies the 2029 limit.
Show the numbers as a table
| Lifetime | Domains | Share |
|---|---|---|
| ≤ 47 days | 49 | 0.6% |
| 48–100 days | 4,105 | 51.9% |
| 101–200 days | 2,511 | 31.7% |
| 201–398 days | 1,233 | 15.6% |
| > 398 days | 11 | 0.1% |
90 days
median lifetime; the mean is 301.1 days, the shortest 30 and the longest 999,999
52.5%
would already satisfy the 100-day cap that starts in March 2027
0.6%
would already satisfy the 47-day cap that starts in March 2029 — 49 certificates in total
The median certificate lives 90 days — the lifetime of an automated ACME certificate — and 52.5% already fit the 100-day cap that arrives in March 2027. Only 0.6% fit the 47-day cap of 2029.
The lifetimes issuers actually pick
Most common exact lifetimes, in days. Certificate lifetimes are not a smooth distribution — they cluster on a handful of policy numbers.
Show the numbers as a table
| Lifetime | Domains | Share |
|---|---|---|
| 90 days | 3,774 | 47.7% |
| 199 days | 1,378 | 17.4% |
| 198 days | 962 | 12.2% |
| 397 days | 437 | 5.5% |
| 84 days | 204 | 2.6% |
| 395 days | 195 | 2.5% |
| 365 days | 160 | 2% |
| 394 days | 117 | 1.5% |
The split runs along the key algorithm: the median ECDSA certificate lives 90 days, the median RSA certificate 198. Elliptic-curve keys mostly arrive through automated issuance, while RSA is still where manually ordered certificates live — the 198- and 199-day lifetimes sitting just under today's maximum. Those are the sites the 100-day step reaches first, and the ones for which a calendar reminder stops being enough.
15.7% still serve a certificate valid for more than 200 days. The longest — 11 certificates valid for more than 398 days — are nearly all self-signed or issued by private CAs, which no browser accepts; they are why the mean is far above the median and says little. Nearly all of them were issued before the March 2026 cutoff and are running out their remaining validity; 13 were issued after it, and almost all of those chain to the Russian Trusted Root CA of Russia's Ministry of Digital Development, which is not in the Chrome, Mozilla, Apple or Microsoft root programs and so is not held to the browsers' lifetime rules. 30 domains served a certificate that had already expired.
Protocol floor
27.8% still answer TLS 1.0
Two separate handshakes per domain: one as a modern client, and one deliberately capped at the deprecated versions to see whether the server still answers.
Protocol negotiated by a modern client
What our scanner and the server agreed on when both were free to pick the best available version.
Show the numbers as a table
| TLS version | Domains | Share |
|---|---|---|
| TLS 1.3 | 6,707 | 84.8% |
| TLS 1.2 | 1,202 | 15.2% |
84.8% negotiate TLS 1.3 with a modern client; the remaining 15.2% top out at TLS 1.2. Nothing negotiated anything older when it had the choice.
Response to a deliberately obsolete handshake
A separate connection per domain, offering nothing above TLS 1.1 (and, where that succeeds, a second one capped at TLS 1.0).
Show the numbers as a table
| Behaviour | Domains | Share |
|---|---|---|
| Refused TLS 1.0 and 1.1 | 5,578 | 70.5% |
| Accepted TLS 1.0 and TLS 1.1 | 2,194 | 27.7% |
| Accepted TLS 1.1 | 135 | 1.7% |
| Accepted TLS 1.0 | 2 | 0% |
Offered nothing newer, 2,196 domains (27.8%) still completed a TLS 1.0 handshake, five years after RFC 8996 deprecated TLS 1.0 and 1.1. As in August, this is not a tail of forgotten hobby servers: it includes some of the largest properties on the list, often behind CDNs where the minimum protocol version is a per-customer setting that starts permissive. Modern clients never downgrade on their own, so the risk is situational — but the old protocols keep CBC-mode ciphers and a decade of attack surface alive for a client population that rounds to zero, and in our grading accepting TLS 1.0 caps a domain at C.
Scores
Graded A+ to F
The same deterministic grader that runs on /health, applied without exception to every domain that answered.
Grade distribution
All 7,909 domains that completed a handshake.
Show the numbers as a table
| Grade | Domains | Share |
|---|---|---|
| A+ | 1,439 | 18.2% |
| A | 3,434 | 43.4% |
| B | 768 | 9.7% |
| C | 2,186 | 27.6% |
| D | 45 | 0.6% |
| F | 37 | 0.5% |
61.6% earn an A or A+. Most of the C grades are the TLS 1.0 group from the previous section: accepting the old protocol caps a domain there however modern everything else is.
Most frequent findings
Every observation the grader made, ranked by how many domains it applied to. Green is praise, amber is a deduction, red is disqualifying.
Show the numbers as a table
| Finding | Domains | Share |
|---|---|---|
| Classical algorithm — migration ahead | 7,909 | 100% |
| Chain complete as served | 7,872 | 99.5% |
| Within validity period | 7,554 | 95.5% |
| TLS 1.3 negotiated | 6,707 | 84.8% |
| Legacy TLS refused | 5,578 | 70.5% |
| RSA-2048 — fine, but not compact | 4,318 | 54.6% |
| Lifetime of 90 days or less | 4,045 | 51.1% |
| Modern key (ECDSA / EdDSA) | 3,240 | 41% |
| TLS 1.0 accepted | 2,196 | 27.8% |
| TLS 1.3 not offered | 1,202 | 15.2% |
| RSA above 2048 bits | 351 | 4.4% |
| In the renewal window (< 30 days) | 239 | 3% |
The chains themselves are in good order: 99.6% served a complete chain, and only 1.8% carry a SHA-1 signature anywhere in the chain — in August the single most common defect of the top 500. The next section shows that this is a change of real servers, not of the sample.
Same servers, two months
What changed on the same 346 servers
Rankings move every month, so comparing this issue's top 500 with August's mixes real change with a different list. The panel is the like-for-like comparison: the hosts measured successfully in both issues.
346 hosts were measured successfully both in August 2026 and now. Their changes are changes of real servers, not of the sample:
3
moved from an RSA to an ECDSA certificate
2
negotiate TLS 1.3 now and did not before
7
refuse TLS 1.0 and 1.1 now and accepted them before
| Metric | August 2026 | October 2026 |
|---|---|---|
| X25519MLKEM768 key exchange | not measured | 55.8% |
| ECDSA leaf keys | 38.7% | 39.3% |
| RSA leaf keys | 61.3% | 60.7% |
| TLS 1.3 negotiated | 84.7% | 85.3% |
| TLS 1.0 or 1.1 still accepted | 27.7% | 26.3% |
| Lifetime ≤ 100 days | 47.4% | 48% |
| Lifetime ≤ 47 days | 1.2% | 1.2% |
| Median certificate lifetime | 181 days | 184 days |
| Graded A or A+ | 60.1% | 64.2% |
The biggest movement is one nobody announced. In August, SHA-1 in the chain was the single most common defect at the top of the web, and the report traced it to the self-signed GlobalSign Root CA from 1998 that servers appended to their chains. 97 panel hosts have stopped sending it, against 0 that started. Most of them carry Google Trust Services certificates, and their chains are now one certificate shorter: they still end with Google's root as cross-signed by that GlobalSign root — a signature made with SHA-256 — but no longer append the 1998 root itself.
Everything else moved slowly, and in both directions: 3 hosts switched from RSA to ECDSA and 1 the other way; 2 gained TLS 1.3 and 0 lost it; 7 stopped accepting TLS 1.0 and 1.1 while 2 started. Key exchange has no August value — that scan did not record it — so the panel starts following the hybrid with the next issue.
| Metric | August 2026 | October 2026 |
|---|---|---|
| X25519MLKEM768 key exchange | not measuredfirst issue | 57.3%not comparable: not measured in both |
| ECDSA leaf keys | 38.4%first issue | 40.7%up 2.3 points |
| RSA leaf keys | 61.6%first issue | 59.3%down 2.3 points |
| TLS 1.3 negotiated | 84.8%first issue | 85.1%up 0.3 points |
| TLS 1.0 or 1.1 still accepted | 28.1%first issue | 25.5%down 2.6 points |
| Lifetime ≤ 100 days | 47.3%first issue | 48.4%up 1.1 points |
| Lifetime ≤ 47 days | 1.1%first issue | 1.1%no change |
| Median certificate lifetime | 181 daysfirst issue | 181 daysno change |
| Graded A or A+ | 59.9%first issue | 64.5%up 4.6 points |
| Domains that answered | 69.8%first issue | 69.8%not comparable: scanned from elsewhere |
The top 500 is the August report's sample definition, so its figures continue the line August started. The world list and the countries start here.
| Metric | October 2026 |
|---|---|
| X25519MLKEM768 key exchange | 58.7%first issue |
| ECDSA leaf keys | 41%first issue |
| RSA leaf keys | 59%first issue |
| TLS 1.3 negotiated | 84.8%first issue |
| TLS 1.0 or 1.1 still accepted | 29.5%first issue |
| Lifetime ≤ 100 days | 52.5%first issue |
| Lifetime ≤ 47 days | 0.6%first issue |
| Median certificate lifetime | 90 daysfirst issue |
| Graded A or A+ | 61.6%first issue |
| Domains that answered | 79.1%first issue |
Post-quantum certificates
Post-quantum certificates: 0
We looked for ML-DSA and SLH-DSA in the public key and the signature algorithm of every certificate in every chain, and found none.
That is still the expected answer, for the reasons the August report set out: no publicly trusted CA may issue such a certificate yet, no browser would accept one, and the larger keys and signatures add several kilobytes to every new connection. It is also the less urgent half. A signature only has to resist an attacker at the moment it is verified, while a session key can be attacked years after the recording, which is why the migration starts with key exchange. On the transition schedule in NIST IR 8547 (an initial public draft), RSA-2048 and the other 112-bit parameter sets are deprecated after 2030 and today's signature algorithms are disallowed after 2035 at every key size. The PQC Migration Planner turns those dates into a plan for a specific stack.
No answer
2,090 of 9,999 domains never answered
Only 79.1% of the world list produced a measurement. That says more about how the ranking is built than about the health of the web.
Why domains dropped out
Share of the 2,090 domains that produced no result. One attempt each — the scanner never retries.
Show the numbers as a table
| Reason | Domains | Share |
|---|---|---|
| No public DNS answer | 1,607 | 76.9% |
| No handshake before the timeout | 322 | 15.4% |
| Port 443 refused or reset | 73 | 3.5% |
| Handshake or certificate error | 51 | 2.4% |
| Resolves to reserved address space | 37 | 1.8% |
76.9% of the failures are names with no address record at the bare domain at all. Tranco ranks registrable domains, and a ranking built partly from DNS traffic is full of names that were never websites: CDN and telemetry zones, update endpoints, ad infrastructure. 322 more did not finish a handshake in time, and 37 resolved into reserved address space, which the scanner refuses to contact by design.
We do not repair the list — no www fallback, no retries, no redirects — because a study that curates its own sample stops being reproducible. The country lists fail far less often for a simpler reason: the Chrome UX Report lists origins that people actually loaded, with their www. kept.
Methodology
How this was measured
Everything needed to reproduce, criticize or dispute the numbers above. The scanner page explains the same for site operators, including how to be left out.
The sample
- World: the top 10,000 of the Tranco research ranking, list 56Z8N of October 22, 2026, unfiltered. Entries that are not host names are skipped — here 1,
_wildcard_.ph— which leaves 9,999 domains. Its first 500 ranks are the top 500, the sample of the August report. - Countries: the top-1,000 popularity bucket of the Chrome UX Report for each country, from the September 2026 tables in BigQuery. The report lists HTTPS origins; we scan their host names as they are,
www.included. The bucket has no order inside it. - A host on several lists is scanned once and counted in each: 16,924 hosts in all. Exclusions requested by site owners and applied before the scan: 0. Hosts the run did not reach before its deadline: 0.
| List | Version | On the list | Excluded | Not attempted | Measured |
|---|---|---|---|---|---|
| Tranco top 10,000 | 56Z8N | 9,999 | 0 | 0 | 7,909 |
| Russia | chrome-ux-report.country_ru.202609 | 990 | 0 | 0 | 955 |
| Spain | chrome-ux-report.country_es.202609 | 1,000 | 0 | 0 | 991 |
| Mexico | chrome-ux-report.country_mx.202609 | 989 | 0 | 0 | 942 |
| Brazil | chrome-ux-report.country_br.202609 | 999 | 0 | 0 | 971 |
| Germany | chrome-ux-report.country_de.202609 | 1,000 | 0 | 0 | 999 |
| France | chrome-ux-report.country_fr.202609 | 998 | 0 | 0 | 988 |
| Japan | chrome-ux-report.country_jp.202609 | 993 | 0 | 0 | 969 |
| China | chrome-ux-report.country_cn.202609 | 997 | 0 | 0 | 963 |
| Taiwan | chrome-ux-report.country_tw.202609 | 992 | 0 | 0 | 947 |
This sample is not the web. Both kinds of list are the top of a popularity ranking — large, professionally operated sites concentrated behind a handful of CDNs and CAs — so expect the long tail of the internet to look worse, and expect one CDN's default to appear hundreds of times as if it were hundreds of independent decisions.
The measurement
- One TCP connection to port 443 per host, SNI set to the host, from Google Cloud Run in europe-west1 (Belgium). The address is screened before the connection and the connection pinned to it, so names that resolve into private or reserved space are refused. No HTTP request is ever sent, so no page is fetched and there is no User-Agent.
- The ClientHello is the runtime's default: Node.js v24.22.0 with OpenSSL 3.5.8, which offers X25519MLKEM768 first, as browsers do. The key-exchange group is read from that same handshake. Before scanning, every task proves that its runtime can negotiate and name X25519MLKEM768 against a local server that accepts nothing else; a runtime that cannot, does not scan.
- A second handshake capped at TLS 1.1 and, where that succeeds, a third capped at TLS 1.0, to test the protocol floor.
- 4 parallel tasks, each with 64 hosts in flight, 500 ms between waves, an 8-second handshake timeout, a 30-second watchdog per host and no retries: a host that fails is recorded as failed. The scan started on October 23, 2026 and took 9 minutes.
- The client offers both RSA and ECDSA signature algorithms, so on a server holding both certificate types we record the server's own preference for a modern client.
What we deliberately do not check
- Trust. We describe the chain as served and do not build a validated path to a root store: “chain complete” means every issuer → subject link matches, not “your browser trusts this site”. A certificate from a CA outside the browser root programs, or a self-signed one, is described and graded on its own properties.
- Revocation and transparency. No OCSP, no CRLs, no Certificate Transparency lookups.
- Everything a server supports. We record the negotiated protocol, cipher and key-exchange group, not the full list of what a server would accept. A server that supports the hybrid but prefers a classical group counts as classical, because that is what a browser gets from it.
- Anything beyond the listed name. No
wwwfallback, no redirects, no subdomains, no ports other than 443, one address per name. - HTTP-level configuration. No HSTS, no headers, no content.
What we compare, and what we do not
- A list is only compared with itself. The top 500 continues the August report; 500 and 10,000 domains are never put on one line.
- A figure is only compared where both issues measured it: the August scan did not record key exchange, so the hybrid share has no August value — not a zero.
- Success rates are not compared with August, which was scanned from one machine rather than from Cloud Run. Shares of the hosts that answered are.
- Changes of real servers come from the panel: hosts measured successfully in both issues.
The grading
Grades come from the same deterministic function that powers the public health check: a fixed set of deductions applied to the scan report, with the report's own timestamp as “now”, so the same scan always produces the same letter. Nothing was adjusted by hand, and no domain was removed after the fact. Accepting TLS 1.0 caps a domain at C regardless of everything else.
The code
The list builders, the scan job and the aggregation live in this site's repository (scripts/research/, services/research-scan/), on top of the unmodified scanner and grader in lib/health/. They are not on GitHub yet; when the site's code is published, they go with it. Until then the identical measurement is available one domain at a time on /health, which is the honest way to check any single row of the data.
Raw data
Take the numbers
Every file is released under CC BY 4.0: use it for anything, with credit. The country lists come from the Chrome UX Report, © Google, under the same licence.
CSV · JSON · CC BY 4.0
Per-host results
One row per host of every list: rank, countries, key exchange, key, protocol, lifetime, issuer, grade and findings — failures included.
/research/2026-10/records.csv
CSV · JSON · CC BY 4.0
Aggregated data
Every chart of the issue as numbers, for the world list, its top 500 and each country, with the run's metadata.
/research/2026-10/summary.json
CSV · JSON · CC BY 4.0
Data Package
Files, columns, licence, sources and citation in the Frictionless Data Package format.
/research/2026-10/datapackage.json
CSV · JSON · CC BY 4.0
Tracked metrics, all issues
The figures the tracker follows, one row per issue and list.
/research/trends.csv
Cite this issue with its month: ecdsa.com, “The State of Signatures on the Web”, 2026-10, https://ecdsa.com/research/2026-10. The next scan runs on November 2, and the next issue shows what changed.
Country pages
Each country of this issue on a page of its own: its figures next to the world's, and how it ranks among the nine.
Where does your domain sit?
Every number on this page came out of a scan you can run yourself, one domain at a time, for free.