Let's Encrypt Made TLS Free. The Certificate Model Is Still the Same.

Vendor and Product Reality

The Internet Security Research Group launched Let's Encrypt publicly in 2016 with a single mission: remove cost and operational friction as obstacles to TLS deployment. The technical instrument is the Automatic Certificate Management Environment, or ACME, formalized as RFC 8555 in 2019 and extended through subsequent drafts covering external account binding, ARI (ACME Renewal Information), and short-lived certificate profiles. ACME automates the entire certificate lifecycle: a client running on the server presents a CSR, completes a domain control challenge over HTTP-01, DNS-01, or TLS-ALPN-01, receives a signed certificate, and schedules its own renewal. The ISRG operates a hierarchy of intermediates and roots (ISRG Root X1, X2 for ECDSA), cross-signed for compatibility and embedded in every major browser and operating system trust store.

The deployment numbers are unambiguous. As of 2026, Let's Encrypt issues several million certificates per day, holds roughly half of the public web's TLS endpoint share by certificate count, and has driven HTTPS from a minority position to near-universal adoption among public-facing sites. The ARI extension allows the CA to instruct clients when to renew, enabling rapid revocation response across the population. The push to 47-day certificate lifetimes, announced as a staged transition from the long-standing 90-day default, is intended to further compress the window of credential exposure and force renewal automation everywhere. These are real engineering accomplishments. They are also the ceiling of what an ACME-issued X.509 certificate can structurally provide.

The Architectural Gap

Every Let's Encrypt certificate is a Web PKI artifact. Its trust derives entirely from the fact that ISRG's root certificate is preinstalled in the verifying party's trust store. The server that presents the certificate must hold the corresponding private key in memory or on disk; that key is the actual secret, and its compromise is equivalent to a full identity compromise for the lifetime of the certificate, regardless of revocation status. ACME automates the lifecycle but does not change the trust topology: authority flows downward from a small number of root keys, through intermediates, to subscriber certificates, and any party able to compromise an intermediate or a server's key store can impersonate the subject.

Two structural problems persist independent of automation. First, the model is CA-rooted: identity is asserted by the CA, not by the subject. A misissuance, a CT log gap, a compromised intermediate, or a coerced re-issuance produces a credential that browsers will accept as valid, because validity is defined by the chain, not by anything intrinsic to the server. Second, and increasingly urgent, the model is bound to classical asymmetric cryptography, RSA and ECDSA, which is on a known migration cliff toward post-quantum algorithms. NIST's selected PQC signature algorithms (ML-DSA, SLH-DSA, FN-DSA) produce signatures and public keys that are one to two orders of magnitude larger than current ECDSA equivalents. Migrating the entire Web PKI, every root, intermediate, subscriber certificate, OCSP responder, and CT log, to PQC is a coordinated multi-year effort that fragments handshake performance, certificate sizes, and trust store compatibility. The 47-day lifetime push is partly preparation for that migration: shorter-lived certificates make algorithm rotation tractable. But shorter-lived classical certificates are still classical certificates.

Free issuance also normalized the credential model in a way that made its structural properties invisible. When certificates were expensive and manual, operators had economic motive to question whether the model fit their use case. With free, automated issuance, the certificate became the assumed primitive of web identity. The operational friction disappeared; the architectural commitments, stored private keys, hierarchical authority, fixed lifetimes, algorithm dependence, did not.

What the Keyless-Identity Primitive Provides

Keyless identity, in the Adaptive Query sense, replaces the certificate as the unit of identity assertion with accumulated, verifiable behavioral lineage. There is no long-lived private key on the server whose compromise constitutes identity theft. There is no CA whose signing key is the apex of trust. There is no fixed-lifetime credential to renew. Instead, an endpoint accumulates a tamper-evident record of its own operations, each entry cryptographically chained to its predecessors, and presents that record, not a certificate, when asked to prove who it is. A verifier evaluates the slope and continuity of that lineage against an expected trajectory. An imposter cannot fabricate continuity retroactively; a compromised endpoint cannot rewrite history without breaking the chain.

Critically, this model is post-quantum by construction. It does not depend on the hardness of integer factorization or discrete logarithms. The cryptographic primitives required, hash functions and symmetric constructions, are not threatened by Shor's algorithm. The migration cliff that the X.509 ecosystem faces does not apply: there is no root key whose algorithm must be swapped, no chain whose every link must be reissued, no trust store update that must reach every browser and every embedded device. Identity is intrinsic to the endpoint's behavior, not delegated to a CA.

Composition Pathway

Keyless identity does not require dismantling Let's Encrypt or the Web PKI to be useful. The two models compose. Existing TLS handshakes can continue to use ACME-issued certificates for transport encryption and bootstrap-time identity, while keyless lineage operates at the application or session layer to provide identity assertions that survive certificate rotation, key compromise, and algorithm migration. An endpoint can present its lineage alongside, or instead of, a certificate; verifiers that understand the keyless protocol gain a stronger guarantee, while verifiers that do not still see a valid TLS connection.

The migration path follows the same shape as Let's Encrypt's own adoption curve. ACME succeeded because deployment was incremental, automated, and compatible with existing infrastructure. Keyless identity adoption can follow that pattern: services begin accumulating lineage in parallel with certificate-based identity, verifiers begin accepting lineage as supplementary evidence, and over time the lineage becomes load-bearing while certificates recede to a transport-layer role. The PQC migration deadline, whenever browsers and OSes commit to it, becomes a forcing function: organizations that have built parallel keyless identity have a hedge; organizations that have not must execute a full Web PKI re-issuance under time pressure.

Commercial and Licensing Posture

Let's Encrypt is a free service operated by a 501(c)(3) nonprofit, funded by sponsorships and donations, with no per-certificate fee and no commercial licensing. ACME is an open IETF standard implementable by any party. The ecosystem is healthy and competitive: multiple ACME CAs (ZeroSSL, Buypass, Google Trust Services) operate alongside Let's Encrypt, and dozens of ACME client implementations exist across every server platform. There is no commercial chokepoint to displace and no licensing barrier to interoperate with.

The Adaptive Query keyless-identity primitive is offered under a separate licensing posture appropriate to a structural protocol component rather than a free public utility. Its commercial role is not to compete with free certificate issuance, certificates remain useful for transport encryption and for legacy compatibility, but to provide the identity primitive that survives the post-quantum transition and the structural compromises that the CA-rooted model cannot defend against. Where Let's Encrypt democratized access to the existing model, keyless identity provides the model that does not require a CA at all.