RSA vs ECDSA in 2026: Measuring the Web's Key Migration

Q: Is ECDSA more secure than RSA?

At the sizes the web actually uses, both are considered secure against classical attack: P-256 is rated at roughly 128 bits of security and RSA-2048 at roughly 112 (industry equivalence figures). ECDSA's real advantage is efficiency — a P-256 key is a fraction of the size of an RSA-2048 key, which means smaller certificates and faster TLS handshakes. Against a future quantum computer, both fail the same way; neither is a post-quantum choice.

Q: What share of websites use RSA vs ECDSA in 2026?

As of our August 2026 census of 231.5 million live TLS certificates, 59.3% carry RSA keys and 32.3% carry elliptic-curve keys. The two most common configurations are RSA-2048 (53.4% of all certificates) and EC P-256 (30.5%).

Q: Are MD5-signed certificates dangerous?

An MD5 signature means the certificate's integrity relies on a hash function with demonstrated forgery attacks dating to 2008. Every mainstream browser rejects MD5-signed chains, so the 425,004 we found are effectively all self-signed or private-CA certificates on appliances and internal-style systems exposed to the internet. The practical risk is less about MD5 forgery and more about what such a certificate signals: a system nobody has maintained in a very long time.

Q: Is my RSA-2048 certificate obsolete? Should I switch to ECDSA?

No, it is not obsolete — RSA-2048 remains within every mainstream guideline and passes our checks when properly deployed. If your certificate tooling offers ECDSA, taking it costs nothing and buys slightly faster handshakes; many issuance paths now default to it anyway. What is worth acting on is anything below 2,048 bits, any SHA-1 or MD5 signature, or an expired or self-signed certificate — all of which are free to fix with a modern automated CA.

Q: Why does hardly anyone use Ed25519 for HTTPS?

Because no public certificate authority is permitted to issue it — the CA/B Forum baseline requirements that govern public CAs do not allow Ed25519 (industry knowledge). Until the issuance path changes, it stays a private-certificate curiosity: 289 certificates out of 231.5 million in our August 2026 measurement.

Q: What should I actually do about my certificate's key type and signature algorithm?

For most organisations running a standard web presence, the right action is to check that your certificate is issued by a trusted public CA, is currently in date, and renews automatically. If those three things are true, your key type is almost certainly RSA-2048 or P-256 — both are fine. The population that needs to act is narrower: anything running a self-signed certificate (replace it with a free Let's Encrypt certificate), anything on RSA-1024 or below (replace immediately — these keys are outside every current guideline and browsers reject them), and any embedded device or appliance with a firmware-baked certificate (inventory it, update firmware where possible, and at minimum document when the certificate expires). For security-conscious operators who want to move to ECDSA P-256, most major CAs and hosting panels now issue it by default — the migration is often as simple as requesting a new certificate without changing anything else.

Q: How does the RSA/ECDSA split compare to the previous census round in July 2026?

The July 2026 census was our immediately prior measurement. The structural story — RSA dominant, ECDSA growing via hosting-panel and Let's Encrypt defaults, an unmanaged tail of legacy cryptography — has been consistent across rounds. The August data confirms the same dynamics: the ECDSA third of the web is growing not because operators are choosing it, but because default issuance paths changed and new certificates inherit those defaults. The MD5 and sub-2048 cohorts are unlikely to have changed materially between rounds; these are static relics on devices that are not being touched, not a population that responds to certificate lifecycle events.

Q: Why does certificate cryptography matter for procurement teams and compliance auditors?

Certificate cryptography is one of the first things a serious security audit will check, because it is externally observable and objectively graded. An RSA-1024 or MD5-signed certificate on any externally facing service is an immediate finding in a penetration test, a SOC 2 audit, or a vendor security questionnaire — it signals that the system it protects has not been meaningfully maintained since at least 2013. Beyond compliance, weak certificate cryptography is a real operational risk for organisations in regulated industries: a customer or partner who runs a security check on your domain and finds sub-2048 RSA or an MD5 signature has a defensible reason to question your security posture across the board. The fix costs nothing; the exposure is disproportionate to its size.

Published 2026-08-18

Figures as of 16 August 2026 · methodology v9. This is a recurring report; each edition re-measures the same population so the numbers can be tracked over time. All figures are aggregate — we never publish an individual business’s grade or name an individual registrant’s domain.

The headline: two algorithms, one slow handover

Of the 231.5 million live TLS certificates our August 2026 census parsed, 59.3% still carry an RSA public key and 32.3% carry an elliptic-curve key. One size dominates each camp: RSA-2048 alone accounts for 53.4% of every certificate on the web, and EC P-256 for another 30.5%. Two key configurations, between them, cover 83.9% of the entire TLS web.

The migration is real. A third of the web has moved to elliptic-curve keys, which barely existed on public sites fifteen years ago. But it is a migration moving at the speed of certificate renewals and hosting-panel defaults, not at the speed of cryptographic advice. And down in the long tail, the census found things that should not exist in 2026: 425,004 certificates signed with MD5, 148,499 RSA keys shorter than 2,048 bits, and 46 certificates still presenting RSA-512.

Key numbers

59.3% of live TLS certificates use an RSA key; 32.3% use an elliptic-curve key (231,455,163 certificates parsed, August 2026 census).
RSA-2048 is the single most common key on the web: 123,741,314 certificates, or 53.4% of all parsed.
EC P-256 is second at 70,543,356 certificates (30.5%) — together with RSA-2048 that is 83.9% of the TLS web on just two configurations.
425,004 live certificates are signed with MD5, a hash algorithm with practical forgery attacks demonstrated in 2008 (industry record).
148,499 certificates carry RSA keys below 2,048 bits, including 148,449 at RSA-1024 and 46 at RSA-512.
Ed25519, the algorithm many cryptographers would pick for a clean-slate design, appears on 289 certificates out of 231.5 million.

How much of the web still runs RSA?

Here is the full key-type breakdown from the census. The denominator is every certificate with a parseable public key: 231,455,163.

Key type and size	Certificates	Share
RSA-2048	123,741,314	53.4%
EC P-256	70,543,356	30.5%
RSA-4096	12,571,356	5.4%
EC P-384	4,159,212	1.8%
RSA-3072	857,500	0.37%
RSA-1024	148,449	0.06%
EC P-521	1,815	<0.01%
RSA-8192	1,373	<0.01%
Everything else	1,165	<0.01%

All RSA sizes combined: 137,321,157 certificates (59.3%). All EC curves combined: 74,704,383 (32.3%).

Two things stand out. The first is concentration. The top four rows cover 91.2% of the web. Whatever certificate authorities and hosting panels hand out by default is what the web runs, and the defaults are RSA-2048 and P-256. This whole dataset is a portrait of default-following, which is fitting, given the name of this site.

The second is what concentration implies about the migration’s engine. Nobody hand-picked P-256 seventy million times. Let’s Encrypt’s certbot client switched its default from RSA to ECDSA P-256 in late 2022, and several large CDN and hosting platforms issue ECDSA by default (industry knowledge, not census data). The EC third of the web is, in large part, people who never made a decision at all. The RSA two-thirds is the same crowd, one default generation earlier.

Is RSA-2048 actually a problem?

No, and it is worth being straight about that before the scary numbers further down. RSA-2048 is estimated at roughly 112 bits of classical security and P-256 at roughly 128 (NIST SP 800-57 equivalences — industry knowledge). Neither is breakable with any known classical technique, and against a future cryptographically relevant quantum computer both fall to the same algorithm, so neither is meaningfully more “quantum-ready” than the other. The practical case for ECDSA is efficiency: smaller keys, smaller certificates, faster handshakes. That matters at CDN scale. It does not make a small business’s RSA-2048 certificate a risk.

The census grades what it can observe, and an in-date, properly chained RSA-2048 certificate passes our checks exactly as a P-256 one does. The interesting story in this data is not RSA versus ECDSA at the top of the table. It is the floor.

The floor: keys that should have been retired a decade ago

The CA/B Forum baseline requirements have forbidden public CAs from issuing RSA keys below 2,048 bits since the end of 2013 (industry record). The census still found 148,499 certificates below that line, live and serving:

RSA-1024: 148,449 certificates. NIST recommended disallowing 1024-bit RSA after 2013 (industry knowledge). These have been outside every mainstream guideline for over a decade.
RSA-768: 4 certificates. A 768-bit RSA modulus was publicly factored in 2009 (industry record).
RSA-512: 46 certificates. Keys this size can be factored with modest rented compute — this has been a demonstrated, repeatable attack for years (industry knowledge).

Because public CAs cannot have issued these recently, this cohort is almost certainly self-signed certificates and ancient private-CA leftovers on appliances, admin panels and forgotten servers — the same population our self-signed data describes elsewhere. A browser will scream at all of them. The risk is not that Google.com runs RSA-512; it is that somewhere behind those 46 certificates is a device whose users have been trained to click through the warning.

And then there is the tail that is neither secure nor insecure, just human. The census found 999 certificates with RSA-2056 keys, 27 at RSA-10240, 18 at RSA-2432, and a scattering of one-off sizes like 2,924 and 5,392 bits. There is no standard that produces a 2,056-bit key. Someone typed a number into a key-generation prompt, slightly wrong or deliberately weird, and a certificate happened. Fourteen distinct key sizes in this dataset exist on exactly one certificate each.

Who is still signing certificates with MD5?

Key type is only half a certificate’s cryptography. The other half is the signature the issuer put on it, and that table has a nastier tail.

Signature algorithm	Certificates	Share
SHA-256 with RSA	138,978,234	60.1%
ECDSA with SHA-384	38,734,657	16.7%
ECDSA with SHA-256	33,475,578	14.5%
MD5 with RSA	425,004	0.18%
SHA-384 with RSA	203,657	0.09%
SHA-1 with RSA	193,121	0.08%
SHA-512 with RSA	10,863	<0.01%
ECDSA with SHA-512	4,376	<0.01%
Ed25519	289	<0.01%
Ed448	16	<0.01%

(Denominator: 231,455,163 certificates with a parsed signature algorithm. A handful of certificates carry raw OIDs our parser does not name — one appears four times, several exactly once — which is its own kind of relic hunting.)

The modern web is the top three rows: 91.3% signed with SHA-256 or SHA-384. That consolidation is a genuine success story — a decade ago the SHA-1 deprecation was an open industry fight, and today SHA-1 signatures are down to 0.08% of live certificates.

But look at what beat SHA-1 in the relic race. MD5 signatures outnumber SHA-1 signatures more than two to one: 425,004 against 193,121. MD5’s collision resistance was broken so thoroughly that researchers used it to forge a working rogue CA certificate in 2008, and browsers stopped trusting MD5-signed chains shortly after (industry record). Every one of those 425,004 certificates predates, ignores or never cared about the public trust ecosystem — which is precisely the point. Public CAs were forced to abandon MD5 seventeen years ago, so what survives is the unmanaged web: self-signed certificates minted by ancient OpenSSL defaults, embedded devices with firmware-baked certificates, appliances nobody has updated since installation. The public-CA system cleaned itself up. The long tail never got the memo, because nobody sends the long tail memos.

One more subtlety worth a sentence: a certificate’s key type and its signature algorithm are chosen by different parties. The key belongs to the site; the signature belongs to the issuer. That is why 74.7 million certificates carry EC keys but only 72.2 million carry ECDSA signatures — roughly 2.5 million EC-keyed certificates were signed by CAs using RSA. The ECDSA-with-SHA-384 row being larger than ECDSA-with-SHA-256 mostly reflects big issuers signing P-256 leaves from P-384 intermediates (industry knowledge).

What about Ed25519, the algorithm the future was promised?

Ed25519 is fast, compact, hard to implement wrongly, and widely admired by cryptographers. It dominates SSH keys and modern protocol design (industry knowledge). On the public TLS web, the census found it on 289 certificates. Ed448 adds 16 more.

The blocker is not enthusiasm, it is trust stores: no major public CA issues Ed25519 TLS certificates because the CA/B Forum baseline requirements do not permit the algorithm, so every one of those 289 is self-signed or privately issued (industry knowledge for the policy; census data for the count). The lesson generalises across this whole report. Algorithm migrations on the web do not happen when a better algorithm exists. They happen when the default issuance path changes, and not before. RSA-2048 will fade the same way it rose — not because operators choose against it, but because one day the tooling stops handing it out.

How we measured this

Population: 432,127,908 domains scanned in the August 2026 census round (figures as of 16 August 2026, methodology v9). Of these, 231.5 million domains presented a TLS certificate our scanner could retrieve and parse.
Denominators: all key-type and signature figures use the 231,455,163 certificates with a parseable public key and parsed signature algorithm.
Leaf certificate only. Every figure describes the leaf (end-entity) certificate a domain presented. We did not analyse intermediate or root certificates, so chain-level algorithm choices are out of scope. A leaf’s signature algorithm is set by its issuer, not the site operator.
One vantage, capture instant. Certificates were collected by our EU-based scanners at scan time. A server that presents different certificates to different clients (SNI-dependent, ECDSA/RSA dual-stack selection based on client hello) is recorded as whatever it served us — a modern browser-like client. Dual-certificate deployments therefore appear under whichever certificate was negotiated, which may undercount RSA fallback certificates held in reserve.
Validity not filtered. These tables count presented certificates whether or not the chain was trusted. That is deliberate: the MD5 and sub-2048 cohorts exist almost entirely outside public trust, and filtering to trusted chains would define the finding away.
Industry context is labelled. RFC history, CA/B Forum policy dates, NIST equivalences and CA tooling defaults are public industry knowledge, not census measurements, and are marked as such where used.
Aggregate only. We publish counts and shares, never the certificate or grade of a named registrant’s domain.
Data is stored and processed within the EU.

FAQ

Is ECDSA more secure than RSA? At the sizes the web actually uses, both are considered secure against classical attack: P-256 is rated at roughly 128 bits of security and RSA-2048 at roughly 112 (industry equivalence figures). ECDSA’s real advantage is efficiency — a P-256 key is a fraction of the size of an RSA-2048 key, which means smaller certificates and faster TLS handshakes. Against a future quantum computer, both fail the same way; neither is a post-quantum choice.

What share of websites use RSA vs ECDSA in 2026? As of our August 2026 census of 231.5 million live TLS certificates, 59.3% carry RSA keys and 32.3% carry elliptic-curve keys. The two most common configurations are RSA-2048 (53.4% of all certificates) and EC P-256 (30.5%).

Are MD5-signed certificates dangerous? An MD5 signature means the certificate’s integrity relies on a hash function with demonstrated forgery attacks dating to 2008. Every mainstream browser rejects MD5-signed chains, so the 425,004 we found are effectively all self-signed or private-CA certificates on appliances and internal-style systems exposed to the internet. The practical risk is less about MD5 forgery and more about what such a certificate signals: a system nobody has maintained in a very long time.

Is my RSA-2048 certificate obsolete? Should I switch to ECDSA? No, it is not obsolete — RSA-2048 remains within every mainstream guideline and passes our checks when properly deployed. If your certificate tooling offers ECDSA, taking it costs nothing and buys slightly faster handshakes; many issuance paths now default to it anyway. What is worth acting on is anything below 2,048 bits, any SHA-1 or MD5 signature, or an expired or self-signed certificate — all of which are free to fix with a modern automated CA.

Why does hardly anyone use Ed25519 for HTTPS? Because no public certificate authority is permitted to issue it — the CA/B Forum baseline requirements that govern public CAs do not allow Ed25519 (industry knowledge). Until the issuance path changes, it stays a private-certificate curiosity: 289 certificates out of 231.5 million in our August 2026 measurement.

What should I actually do about my certificate’s key type and signature algorithm? For most organisations running a standard web presence, the right action is to check that your certificate is issued by a trusted public CA, is currently in date, and renews automatically. If those three things are true, your key type is almost certainly RSA-2048 or P-256 — both are fine. The population that needs to act is narrower: anything running a self-signed certificate (replace it with a free Let’s Encrypt certificate), anything on RSA-1024 or below (replace immediately — these keys are outside every current guideline and browsers reject them), and any embedded device or appliance with a firmware-baked certificate (inventory it, update firmware where possible, and at minimum document when the certificate expires). For security-conscious operators who want to move to ECDSA P-256, most major CAs and hosting panels now issue it by default — the migration is often as simple as requesting a new certificate without changing anything else.

How does the RSA/ECDSA split compare to the previous census round in July 2026? The July 2026 census was our immediately prior measurement. The structural story — RSA dominant, ECDSA growing via hosting-panel and Let’s Encrypt defaults, an unmanaged tail of legacy cryptography — has been consistent across rounds. The August data confirms the same dynamics: the ECDSA third of the web is growing not because operators are choosing it, but because default issuance paths changed and new certificates inherit those defaults. The MD5 and sub-2048 cohorts are unlikely to have changed materially between rounds; these are static relics on devices that are not being touched, not a population that responds to certificate lifecycle events.

Why does certificate cryptography matter for procurement teams and compliance auditors? Certificate cryptography is one of the first things a serious security audit will check, because it is externally observable and objectively graded. An RSA-1024 or MD5-signed certificate on any externally facing service is an immediate finding in a penetration test, a SOC 2 audit, or a vendor security questionnaire — it signals that the system it protects has not been meaningfully maintained since at least 2013. Beyond compliance, weak certificate cryptography is a real operational risk for organisations in regulated industries: a customer or partner who runs a security check on your domain and finds sub-2048 RSA or an MD5 signature has a defensible reason to question your security posture across the board. The fix costs nothing; the exposure is disproportionate to its size.

What this means for IT managers, security teams, and business owners

The headline finding — 59.3% of the web on RSA, 32.3% on ECDSA — is not itself an action item for most organisations. RSA-2048, which accounts for 53.4% of all certificates, remains within every current standard and will continue to do so for the foreseeable future. The migration from RSA to ECDSA is real but unhurried, and it is being driven by default changes in issuance tooling, not by any regulatory deadline. For IT managers, the practical conclusion is: if your certificate tooling now defaults to ECDSA P-256, accept that default; if it still defaults to RSA-2048, that is fine too. Do not burn cycles on an algorithm migration that costs nothing to delay.

The floor is a different matter entirely. Security teams should treat the 148,499 sub-2048-bit RSA certificates and the 425,004 MD5-signed certificates in this census as a category-one finding on any system they manage. These cohorts exist almost exclusively on self-signed and private-CA material — admin panels, appliances, legacy internal tools — that sits outside the public-CA ecosystem and therefore outside its automatic upgrade path. The question to ask is not “is this certificate trusted by browsers?” (it almost certainly is not) but “what is behind it, and do we know it exists?” A device nobody monitors is a device nobody patches, and a device nobody patches is a device somebody else is interested in.

For business owners, the relevant insight is about vendors and supply chains. If a software vendor, SaaS provider, or managed service partner exposes any system to you — an admin portal, a support tool, an integration endpoint — that system’s certificate cryptography is a reasonable due-diligence question. An MD5-signed or RSA-512 certificate on a vendor’s admin interface is not a nuisance finding; it is evidence that the system has not been actively maintained for at least a decade. The defaults.exposed check runs in 30 seconds and produces a graded report you can attach to a vendor review. The cost of that check is zero. The cost of a breach through an unmonitored legacy system is not.

Data to cite — RSA vs ECDSA key migration 2026

Pull-quote statistics from the defaults.exposed August 2026 Domain Security Census (432M domains). These figures may be cited verbatim with attribution.

“59.3% of 231.5 million live TLS certificates on the public web carry RSA keys and 32.3% carry elliptic-curve keys, as measured in August 2026.” — defaults.exposed August 2026 Domain Security Census (432M domains)

“RSA-2048 is the single most common key configuration on the public web, appearing on 123,741,314 certificates — 53.4% of all live TLS certificates measured in August 2026.” — defaults.exposed August 2026 Domain Security Census (432M domains)

“425,004 live TLS certificates are still signed with MD5, a hash algorithm with practical forgery attacks demonstrated in 2008 — more than twice as many as the 193,121 still signed with SHA-1.” — defaults.exposed August 2026 Domain Security Census (432M domains)

“148,499 live TLS certificates carry RSA keys below 2,048 bits — a key size the CA/Browser Forum prohibited public CAs from issuing after 2013 — including 46 certificates still presenting RSA-512.” — defaults.exposed August 2026 Domain Security Census (432M domains)

“Ed25519, the elliptic-curve algorithm widely preferred by cryptographers for new deployments, appears on just 289 certificates out of 231.5 million measured — because no public CA is currently permitted to issue it.” — defaults.exposed August 2026 Domain Security Census (432M domains)

“Two key configurations — RSA-2048 and EC P-256 — together account for 83.9% of all live TLS certificates on the public web as of August 2026, confirming that algorithm distribution on the web is almost entirely a function of issuer defaults.” — defaults.exposed August 2026 Domain Security Census (432M domains)

Check your domain free at defaults.exposed — see exactly how your domain scores on certificate cryptography, key type, signature algorithm, and 31 other externally observable security checks. Takes 30 seconds. No account needed. Read the flagship census report: The State of Domain Security 2026 →

Aggregate data only. Data stored and processed in the EU.

How to cite this report

Press / blog: defaults.exposed (2026). RSA vs ECDSA in 2026: Measuring the Web’s Key Migration. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/rsa-vs-ecdsa-web-key-migration

Academic: defaults.exposed. (2026, August 18). RSA vs ECDSA in 2026: Measuring the Web’s Key Migration. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/rsa-vs-ecdsa-web-key-migration

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=231,455,163 certificates)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,781 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/en/articles/domain-security-scoring-methodology-v9 Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026