Let's Encrypt
Capability scores
Methodology →- Authentication
- 2.5
- SSO & Federation
- 2.0
- Authorization
- 2.0
- Lifecycle & Provisioning
- 4.0
- MFA & Passwordless
- 2.0
- Governance & Audit
- 3.0
- Developer Experience
- 4.5
- Deployment Flexibility
- 4.0
- Pricing Transparency
- 5.0
- Support & Ecosystem
- 4.0
Scored 0–5 against a published rubric. Independent analysis, no vendor sponsorship.
Overview
Let's Encrypt is a free, automated certificate authority run by the nonprofit Internet Security Research Group (ISRG) and funded by sponsors and donations. It issues domain-validated (DV) public TLS certificates entirely through ACME (RFC 8555), which it helped standardize, and it is the reason HTTPS became the default for the public web. There is no ownership or commercial change to note; it remains an ISRG project. For PKI teams it is less a vendor than an upstream dependency whose policy changes ripple into every automated renewal pipeline.
What it is good at
Zero-cost, zero-touch public TLS. Any ACME client (Certbot, Caddy, cert-manager, Traefik, most CDNs and hosting platforms) can request and renew certificates with no account managers, invoices or manual approvals. Validation runs over HTTP-01, DNS-01 or TLS-ALPN-01; wildcard certificates require DNS-01.
It is also the CA most actively pushing shorter lifetimes. Six-day (160-hour) and IP address certificates became generally available in January 2026, ACME Renewal Information was published as RFC 9773 so the CA can tell clients when to renew, and the default lifetime drops from 90 to 64 days on 10 February 2027 and to 45 days in February 2028. If your certificate lifecycle automation works with Let's Encrypt, it is ready for the industry-wide move to 47-day certificates.
Where it falls short
Scope is narrow by design. Only DV certificates for public domain names and IP addresses: no OV or EV, no code signing, no S/MIME, no private CA. Since 2026 it no longer covers client certificates either: the TLS Client Authentication EKU left the default profile on 11 February 2026 and all profiles on 8 July 2026, so anyone who used it for mTLS client or device identity needs a private CA.
Operational support has thinned. Expiration reminder emails ended in June 2025 and OCSP reached end of life in August 2025, leaving CRLs only. Rate limits cap issuance at 50 certificates per registered domain and 5 duplicates per exact identifier set every 7 days. There is no SLA and no paid support, only a community forum, and no inventory or policy console for the certificates you hold.
Pricing
Free, with no paid tier; ISRG is funded by sponsors and donations. It scores at the top of the Identity Pricing Transparency Index. The real cost is your automation and monitoring.
Best for, and who should look elsewhere
Let's Encrypt fits every team that needs public TLS on infrastructure it can automate, from a single site to Kubernetes clusters via cert-manager. Deployment effort is an afternoon for one server; the ongoing work is renewal monitoring, which shorter lifetimes make mandatory. Enterprises with private PKI, client and device certificates, or machine identity inventory needs should look at Smallstep, EJBCA or Keyfactor; buyers who need OV/EV, warranties or an SLA should compare DigiCert vs Sectigo. See the certificate lifecycle management guide.
Bottom line
The default choice for free, automated public TLS, and the best rehearsal for short-lived certificates. It is not a PKI program: client, device and private certificates now have to come from somewhere else.
Let's Encrypt: frequently asked questions
- How long are Let's Encrypt certificates valid?
- 90 days by default as of October 2026. Let's Encrypt moves the default to 64 days on 10 February 2027 and to 45 days on 16 February 2028, following CA/Browser Forum requirements. Subscribers can already opt into a 45-day tlsserver profile or a six-day (160-hour) shortlived profile. Renew at about two-thirds of the lifetime, or use an ACME client that supports ACME Renewal Information (RFC 9773).
- Can I use Let's Encrypt certificates for mTLS client authentication?
- No longer. The default classic profile stopped including the TLS Client Authentication extended key usage on 11 February 2026, and the tlsclient profile that kept it was retired on 8 July 2026. For client certificates, device identity or workload mTLS, run a private CA such as Smallstep, EJBCA or HashiCorp Vault PKI.
- Does Let's Encrypt issue wildcard or IP address certificates?
- Both. Wildcard certificates require the DNS-01 challenge; HTTP-01 cannot issue them. IP address certificates became generally available in January 2026 and must use the six-day shortlived profile. Let's Encrypt does not issue OV or EV certificates, code-signing or S/MIME certificates.
- Does Let's Encrypt still send expiry emails or run OCSP?
- No. Expiration notification emails ended on 4 June 2025, and the OCSP service reached end of life in August 2025; revocation status is published via CRLs only. Monitor expiry yourself or with a third-party service.
Related on Start with Identity
- CVESMB Server Kerberos reflection via Ghost SPNs
October 2025 follow-on to CVE-2025-33073. SMB Server elevation of privilege by combining Kerberos reflection with Ghost SPNs and DNS self-registration.
- CVEWindows SMB Client improper authentication (tampering)
Windows SMB Client improper authentication (CWE-287) that allows tampering. Not an Entra token bug, but it sits in the same Microsoft identity-adjacent patch tr
- CVEWindows SMB Kerberos reflection elevation of privilege
Kerberos authentication reflection on SMB, still abusable via Ghost SPNs after the first fix. High-severity elevation of privilege on Windows.
- Comparisonkeyfactor-vs-venafi
Both automate certificate lifecycle at enterprise scale. The live question in 2026 is ownership: Keyfactor is independent, while Venafi sits inside CyberArk, no
- Blog54% of business SaaS apps support passkeys or security keys. Only 13% let you require them
SWI's Phishing-Resistant MFA Support Matrix checked 95 business SaaS apps against their own documentation. 51 support passkeys or FIDO2 security keys, 12 let ad
- BlogA CVSS 10.0 bug let one user's Terraform token serve another user's request
HashiCorp's Terraform MCP Server failed to assign unique session identifiers in stateless HTTP mode, so a token supplied by one user could be reused for later r
By SWI Community Team · Last evaluated 2026-10-31
Independent, community-driven analysis. No vendor sponsorship. Compiled from public research and community input and verified on a best-effort basis, so details may be incomplete or out of date. Scores are opinions, not advice. Trademarks belong to their owners; mention does not imply affiliation or endorsement. See the full disclaimer, or send corrections to community@startwithidentity.com.