Let's Encrypt for Enterprise: When Free TLS Stops Being Free

What Let's Encrypt Does Brilliantly

Since its first production certificate was issued on 14 September 2015, Let's Encrypt has fundamentally rewritten the economics of public TLS. By July 2024, the Internet Security Research Group (ISRG) reported that Let's Encrypt was serving more than 500 million active certificates for roughly 360 million domains, with cumulative issuance crossing the four-billion mark over its lifetime. The before-and-after curve on the Firefox HTTPS Telemetry chart, which sat around 39 percent of page loads in early 2015 and crossed 80 percent in 2020, is largely a Let's Encrypt curve.

Any honest discussion of SSL and TLS at scale starts by acknowledging that contribution.

The engineering choices behind that growth still hold up in 2026. Let's Encrypt was the original production deployment of the ACME protocol, later standardised as RFC 8555 in March 2019. ACME took certificate issuance from an email-and-CSV ritual to a three-call HTTP API: newAccount, newOrder, finalize.

Clients like Certbot, acme.sh, lego, and win-acme automate domain validation through HTTP-01, DNS-01, or TLS-ALPN-01 challenges, request the certificate, and reload the web server. The whole cycle, including OCSP and Certificate Transparency log submission, completes in under fifteen seconds for a single SAN.

The other structural choice was a 90-day certificate lifetime, decided to force automated certificate management from day one and to limit the blast radius of any single key compromise.

That decision aged extremely well: the CA/Browser Forum is now driving the public TLS maximum lifetime to 47 days by March 2029, and the operational muscle Let's Encrypt forced the industry to build is exactly what makes the shorter lifetime tolerable. Free, automated, short-lived, transparency-logged: this is what good public TLS looks like, and Let's Encrypt sets the bar.

The Seven Invisible Costs at Scale

Let's Encrypt is brilliant at the job it was designed for: issuing Domain Validated certificates for public-facing services, fast, free, and at planetary scale. The cost discussion only begins when an enterprise tries to make it carry the rest of its certificate estate.

The first wall is rate limits. The current production limits, published at letsencrypt.org/docs/rate-limits, allow 300 New Orders per account per three hours, 50 certificates per Registered Domain per week, 5 duplicate certificates per week, and 5 failed validations per hostname per hour.

For a single marketing site these numbers are invisible. For a SaaS that issues a per-tenant certificate, an e-commerce platform with white-label subdomains, or a Kubernetes cluster with cert-manager spawning ingresses, the 50-per-week ceiling on a registered domain is a hard architectural constraint that has to be designed around.

The second cost is the absence of Organization Validated (OV) and Extended Validation (EV) products. Let's Encrypt only issues DV. For most public web traffic this is fine, but procurement, payments, regulated banking portals, and certain B2B integrations still require OV or EV certificates with verified legal identity in the Subject. That requirement does not disappear because the technical community considers EV obsolete; it shows up as a checkbox in an RFP and the answer has to be yes.

The remaining five costs are operational rather than technical. Let's Encrypt offers no SLA and no support contract: when issuance fails at 03:00 you read the staging logs and the community forum, you do not open a P1 ticket.

The audit trail is thin by design — the ACME account holder is whoever holds the private key, with no link to a corporate identity, no four-eyes approval, no documented issuance justification.

Key custody is the responsibility of every individual server: a leaked ACME account key or server private key has a blast radius bounded only by how many hostnames that account ever requested.

Dependency risk is real and was demonstrated on 4 March 2020, when a CAA-rechecking bug forced the revocation of about 3 million certificates with roughly five days of notice; the same risk surfaced again with the 23 January 2025 announcement that OCSP support would be deprecated, breaking workflows that depended on it.

None of these are flaws in Let's Encrypt; they are the natural shape of a free, automated, community-funded public CA service.

• 300 new orders / 3 hours — Per ACME account. Hits multi-tenant SaaS, CI runners, and Kubernetes operators issuing on namespace creation. Mitigation: shard across accounts and pre-issue, but you are now operating a fleet of accounts.
• 50 certificates / domain / week — Per Registered Domain as defined by the Public Suffix List. The platform that puts every customer on `{tenant}.app.example.com` hits the wall at customer 51 of any seven-day window.
• 5 duplicates / week — The cert with the exact same SAN set cannot be issued more than 5 times in 7 days. Aggressive blue/green deploys and accidental dual issuance trip this constantly.
• No OV, no EV — DV only. Anything that requires a verified organisation in the Subject — payment portals, regulated B2B, some procurement processes — needs a different issuer.
• No SLA, no support — Status page and community forum. Production incidents are debugged by reading source code and Boulder logs, which is acceptable for a hobby project and a difficult conversation with an audit committee.
• Thin audit trail — Account key holder = identity. No four-eyes approval, no ticket reference, no policy attestation per issuance. Sufficient for DV, insufficient for SOX, SOC 2, or ISO 27001 evidence packs.
• Dependency on a single free service — March 2020 mass revocation, January 2025 OCSP deprecation, recurring rate-limit tightening. Each is reasonable in isolation; together they argue for a fallback path you actually rehearse.

Internal CAs: A Category Let's Encrypt Doesn't Cover

The most important point in this discussion is the simplest: Let's Encrypt only issues certificates for publicly resolvable, ICANN-registered domain names, validated against a server reachable from the public internet. That excludes, by design, every certificate use case that lives behind the perimeter. Internal services on .internal, .corp, or RFC 6762 .local namespaces cannot be issued by any public CA, including Let's Encrypt, because the underlying CA/Browser Forum Baseline Requirements forbid issuance to non-IANA TLDs.

Even when internal services use registered names, exposing every internal load balancer to the public internet for an HTTP-01 challenge is not a viable model.

The next category is mutual TLS for service-to-service authentication. A TLS/SSL certificate in an mTLS mesh has a client identity in the Subject, an SPIFFE ID or a Kubernetes service-account name in the SAN, a lifetime measured in hours, and a renewal cycle driven by the workload, not by DNS.

SPIRE, Istio Citadel, Linkerd's identity service, and HashiCorp Vault PKI are the issuers in this space. Let's Encrypt is not, and was never trying to be.

The same logic applies to device and IoT identity, where certificates are provisioned at manufacturing time onto secure elements, embedded in firmware, and rotated through SCEP, EST, or proprietary bootstrap protocols against a private CA the manufacturer controls.

It applies to code signing, where the signing certificate has to chain to a CA explicitly trusted by Windows, macOS, Java, Apple App Store, or Google Play, with EV-tier key custody in a FIPS 140-2 Level 3 device.

It applies to S/MIME, where the certificate carries a verified email identity and chains to a CA in the Mozilla S/MIME trust store.

None of these are gaps in Let's Encrypt: they are categories of public key infrastructure that require a different kind of CA, with different policies, different validation, and different chain of trust. Understanding what a certificate authority actually is makes clear why one CA cannot do all of these well.

Audit, Governance and Compliance Gaps

The compliance picture is where the free-versus-priced calculation gets uncomfortable. SOC 2 Common Criteria CC6.1 and CC6.6 require evidence of logical access controls over cryptographic keys and certificates. ISO/IEC 27001:2022 Annex A.5.17 and A.8.24 require documented cryptographic policy, key management procedures, and lifecycle records.

The EU NIS2 directive, transposed into national law across the bloc by 17 October 2024, requires essential and important entities to demonstrate “policies and procedures regarding the use of cryptography” under Article 21(2)(h), with fines up to 10 million euros or 2 percent of global turnover.

DORA, applicable to financial entities since 17 January 2025, requires ICT risk management evidence under Article 9 covering authentication and cryptographic protections.

The Cyber Resilience Act, entering its main obligations in December 2027, requires manufacturers of products with digital elements to maintain a cryptographic asset inventory.

Every one of those frameworks asks the same four operational questions: who approved this certificate, who holds the key, how was issuance authorised, and what is the documented revocation procedure when the key is compromised. Let's Encrypt's answer to all four is the same: whoever controls the ACME account.

That is a technically correct answer and an inadequate compliance answer. There is no per-issuance approval record, no ticket reference, no segregation of duties between requester and approver, no policy attestation stored with the certificate, no link between the account and a named human owner in the corporate directory.

A certificate policy and governance framework exists to produce exactly the evidence regulators ask for, and it cannot be retrofitted onto an ACME account that issues anonymously on behalf of any process that holds the key file.

The revocation story compounds the problem. Let's Encrypt deprecated OCSP responder support starting 6 May 2025, with full sunset scheduled for August 2025, replacing it with CRL-based status only.

That is a defensible engineering decision for a CA issuing 90-day certificates where revocation is rarely the right remediation. It is also a decision the subscriber does not get to influence, and it changes what evidence the team can produce when an auditor asks how a compromised key was retired within the required window. A 90-day natural expiry is not, by itself, a revocation procedure.

• SOC 2 CC6.1 / CC6.6 — Evidence of logical access control over keys. Required: who can request, who approves, where the key lives. Let's Encrypt answer: holder of the account key, no per-issuance log linked to a named identity.
• ISO 27001:2022 A.5.17 / A.8.24 — Documented cryptographic policy and key lifecycle records. Required: policy, procedures, custody, rotation evidence. Let's Encrypt answer: read the Certificate Practice Statement and the Boulder code; subscriber records do not exist.
• NIS2 Article 21(2)(h) — Cryptographic policies and procedures for essential entities. Required: organisation-wide policy and enforcement. Let's Encrypt answer: out of scope; the CA cannot enforce policies it never sees.
• DORA Article 9 — ICT risk management including cryptographic protections, with Register of Information evidence. Required: traceable controls. Let's Encrypt answer: no contractual relationship, no DPA, no support channel for ICT third-party risk filings.
• CRA Annex I § 1(3)(d) — Confidentiality through state-of-the-art cryptography in products with digital elements. Required: cryptographic asset inventory per product. Let's Encrypt answer: the CA issues; product inventory is the manufacturer's responsibility, and Let's Encrypt is not a product.

The Mixed Model: Let's Encrypt at the Edge + Private CA Internally

The realistic 2026 architecture is not a binary choice. It is a clearly drawn boundary between traffic that terminates on the public internet and traffic that does not. At the edge — the CDN, the public load balancer, the marketing site, the documentation portal, the public API gateway — Let's Encrypt remains an excellent fit. The hostnames are ICANN-registered, the validation challenge is reachable, DV is sufficient, automation through cert-manager or Certbot is mature, the 90-day rotation is operationally cheap.

The whole class of certificates that used to require a procurement cycle, an OV verification call, and a $300 annual renewal now costs nothing and renews itself. That is the right answer for that layer.

Behind that perimeter, a private CA hierarchy issues everything else. The private PKI typically runs an offline root in an HSM, one or more online intermediates by environment, and policy-bound issuing CAs per use case: workload mTLS, device identity, code signing, S/MIME, VPN, Wi-Fi 802.1X.

The same ACME protocol that drives Let's Encrypt drives the internal CA: private ACME (acme-tiny, smallstep step-ca, Vault PKI ACME, Evertrust Stream ACME) gives internal services the same automation model with none of the public CA constraints.

Workloads renew through ACME on private DNS names with internal validation, lifetimes are tuned to use case (24 hours for service mesh identities, 30 days for ingress, 1 year for code signing), and every issuance is bound to a documented policy and a named owner.

The connection between the two halves is a unified inventory. Discovery sweeps the perimeter and CT logs for what Let's Encrypt issued, the internal CA database for what was issued privately, and reconciles both into one view.

That single view is what an auditor wants to see, what the on-call engineer pages on during an outage, and what the architecture team uses when planning the PQC migration. Without it, the organisation has two parallel certificate estates that share nothing except the people they wake up at 04:00.

1. Edge layer — Public-facing load balancers, CDNs, marketing sites, public APIs. Let's Encrypt or other public ACME CA. cert-manager with `Issuer: letsencrypt-prod`, HTTP-01 or DNS-01, 90-day rotation, OCSP/CRL via CDN. Renewal driven by the ingress controller, not by humans.
2. Internal ingress layer — Internal API gateways, partner mTLS endpoints, admin consoles on private DNS. Private CA with internal ACME endpoint, 30 to 90 day lifetimes, validation via internal DNS-01 or HTTP-01.
3. Workload identity layer — Service mesh (Istio, Linkerd, SPIRE), Kubernetes pods, microservice mTLS. Private CA issuing SPIFFE-IDs, 1 to 24 hour lifetimes, automatic rotation, key material in workload TPM or memory only.
4. Device and IoT layer — Routers, switches, OT controllers, IoT fleets. Private CA via SCEP, EST, or proprietary bootstrap. 1 to 5 year lifetimes, key material in TPM, secure element, or HSM-backed manufacturing line.
5. Human and signing layer — Code signing, document signing, S/MIME, smartcard logon. Private CA chained to a public trusted root where required (code signing) or internal-only where not (S/MIME within the org). HSM-backed signing keys, manual or workflow-based approval.
6. Unified inventory and policy plane — One certificate discovery and inventory system spanning all five layers. Single source of truth for renewal, revocation, ownership, policy compliance, and PQC migration planning.

When to Fully Replace

For most organisations the mixed model is the right end state. There are, however, situations where keeping Let's Encrypt in the picture creates more operational drag than it removes. Five signals consistently mark that point.

The first is certificate count. Below a few hundred certificates an ACME-based public CA model works fine. Above five thousand active certificates across mixed environments, the operational cost of tracking which ones renew where, which ones are subject to which rate limit, and which ones live in which account starts to dominate. Past 50,000 certificates — common in service-mesh deployments, IoT fleets, and large SaaS platforms — the math has long since flipped.

The second signal is a compliance audit on the horizon. The first SOC 2 Type II, ISO 27001 surveillance, NIS2 conformity assessment, or DORA Register of Information filing that explicitly looks at certificate issuance and key custody will ask questions that an ACME-only setup cannot answer with evidence. Reorganising the certificate program three months before the audit is far more expensive than building it correctly to begin with.

The third signal is mixed-trust applications. When the same application terminates external traffic from public clients, internal traffic from corporate networks, mTLS from partners, and device traffic from field equipment, running one CA strategy per traffic class becomes unsustainable.

The fourth is key custody requirements: when policy, regulation, or threat model requires private keys in an HSM at FIPS 140-2 Level 3 or FIPS 140-3 Level 3, the workflow has to be designed around the HSM, not around an ACME client writing a PEM file to disk.

The fifth is a hard OV or EV business need: a regulator, a partner, or a payment scheme asks for a certificate with a verified legal entity in the Subject, and the answer cannot be “our CA does not issue those”.

• Signal 1: 5,000+ certificates in BAU — Operational overhead of rate limits, account sharding, and renewal coordination outweighs the savings. Past 50,000 it is no longer a debate.
• Signal 2: External audit in the next 12 months — SOC 2, ISO 27001, NIS2, DORA, or PCI DSS 4.0. Each will ask about issuance approval, key custody, and revocation evidence. Build the answer once, not three weeks before the auditor arrives.
• Signal 3: Mixed-trust applications — Same workload serves external, internal, partner, and device traffic. Running one CA strategy per traffic class is fragile; a unified governance plane across one or more CAs is not.
• Signal 4: HSM-backed key custody required — Policy, regulation, or threat model puts keys in FIPS 140-2 Level 3 or FIPS 140-3 hardware. The issuance flow has to enrol against the HSM, not write a PEM file from an ACME client.
• Signal 5: OV or EV is a hard requirement — Payment partner, regulator, or buyer asks for a verified organisation in the Subject. DV-only public CAs cannot answer; the program needs a CA that issues OV/EV alongside whatever else.

Where Evertrust Fits

This article is deliberately not a put-down of Let's Encrypt. The free, automated, transparency-logged public CA category that Let's Encrypt defined is one of the most valuable infrastructure contributions of the last decade, and the right answer at the edge of most enterprise estates remains some form of public ACME issuance. The question is what runs behind that edge, who owns it, and how it is governed.

Evertrust addresses the layer the public CA category was never designed to cover: a private PKI plane that issues internal TLS, workload mTLS, device, code-signing, and S/MIME certificates, governed by policy, backed by HSMs, exposed through ACME, SCEP, EST, REST, and CMPv2, and tied into a unified inventory that also tracks what your public CAs issued.

The policy engine produces the evidence SOC 2, ISO 27001, NIS2, DORA, and CRA auditors ask for, per issuance, per owner, per justification.

The discovery layer reconciles Let's Encrypt issuance, internal CA issuance, ADCS issuance, and cloud-native issuance into a single view of every certificate the organisation depends on, with renewal, revocation, and ownership attached.

To see how the private side of the mixed model is run in 2026, explore Evertrust PKI.