Internet Security Research Group and the burden of running public trust

Summary

• Internet Security Research Group operates Let’s Encrypt, coordinates Prossimo, runs Divvi Up and supports emerging digital-identity research, giving a small nonprofit influence across several critical internet trust layers
• Let’s Encrypt combined free certificates, ACME automation, short lifetimes and open infrastructure to make encryption routine, while shifting operational responsibility towards continuously monitored renewal systems
• ISRG’s projects use different economic models: charitable funding supports public services, targeted grants finance safer software, and Divvi Up adds paid privacy infrastructure without becoming a conventional commercial vendor
• The organisation’s central challenge is institutional scale: its services reach far beyond its roughly 25-to-28-person workforce, making funding, succession, incident response and project selectivity part of internet resilience

A small organisation operating at internet scale

Internet Security Research Group does not fit comfortably into the usual categories of company, research institute or industry association. It is a California public-benefit corporation with federal tax-exempt status, a distributed workforce and a portfolio of live services and funded engineering programmes whose effects reach browsers, servers, hosting platforms, network paths, operating systems and application telemetry. Its public-facing organisational website uses the name A Better Internet, but that is the domain through which ISRG presents its work rather than a separate legal or operating entity.

The scale mismatch is the most useful starting point. ISRG’s 2025 annual report named 25 staff, while a February 2026 post implied approximately 27.5 people or full-time-equivalent capacity. The latter was an informal indication rather than a formal headcount and should not be treated as an exact workforce figure. Against that limited staffing base, the organisation reported hundreds of millions of protected websites, certificate issuance reaching roughly ten million on some days, public Certificate Transparency logs, standards work, memory-safety programmes and a privacy-preserving telemetry service.

This is not simply a story of organisational efficiency. It is a story of technical leverage and institutional concentration. Software, cryptographic keys, root-store relationships and automated protocols allow a small operator to extend trust across global infrastructure without employing the workforce associated with a conventional utility. The same architecture means that a software defect, funding shortfall, policy error or operational outage can propagate far beyond the nonprofit’s own legal and financial scale.

ISRG therefore has to be judged in two directions at once. Its achievement lies in converting capabilities that were expensive, manual or restricted to specialists into infrastructure that ordinary operators can adopt. Its exposure lies in the number of dependencies required to sustain that simplicity: browsers, root programmes, ACME clients, DNS, BGP, hardware security modules, data centres, contractors, donors and standards bodies all contribute to systems ISRG does not control on its own.

Two technical efforts became one institution

ISRG emerged from the convergence of two related efforts rather than from a single founder working in isolation. At the University of Michigan and the Electronic Frontier Foundation, J. Alex Halderman and Peter Eckersley were working on automated certificate issuance and renewal. At Mozilla, Josh Aas and Eric Rescorla were pursuing the idea of a free automated certificate authority. The groups discovered one another and joined forces in May 2013, combining protocol and client work with browser, public-key-infrastructure and certificate-authority expertise.

The legal history and the broader technical record describe the founding in slightly different ways. ISRG’s current organisational material names Aas and Rescorla as founding directors, while Aas’s later retrospective identifies Aas, Rescorla, Halderman and Eckersley as the wider founding team. Both accounts can be preserved without forcing them into one label. Aas and Rescorla formed the initial legal directorship, while all four belonged to the technical and organisational coalition from which the institution emerged.

ISRG was incorporated on 24 May 2013 and received federal tax-exempt status effective from June 2014. Mozilla, EFF, the University of Michigan, Cisco and Akamai appear in the founding record as sponsors or partners, although their roles differed. EFF and Michigan contributed protocol and client work, Mozilla brought browser and PKI expertise, and Cisco and Akamai supplied funding, infrastructure or operational support. IdenTrust later provided the cross-signing relationship that made early Let’s Encrypt certificates broadly usable.

That distributed origin established a method ISRG has continued to use. The organisation does not try to own every component of the systems it supports. It creates a legal and operational home that can coordinate institutions with different capabilities, raise mission-aligned funding, publish open software and standards, and operate the parts that require an accountable service provider.

The result is less vertically tidy than a conventional technology company, but it allows browser vendors, civil-liberties groups, academic researchers, infrastructure companies and independent maintainers to contribute without making any one participant the owner of the entire system.

The nonprofit structure was part of the trust model

The choice of a nonprofit structure was more than a fundraising decision. A public certificate authority occupies a privileged position in the internet trust system because browsers and operating systems accept its signatures as evidence that a server controlled a domain name or another approved identifier when the certificate was issued. The operator can influence price, access, automation, certificate profiles and the practical conditions under which encrypted communication becomes available.

ISRG’s founders concluded that this function should not depend on shareholders expecting an exit, a commercial incentive to increase certificate prices or a product strategy built around selling higher-validation tiers. They also wanted to avoid one corporate parent being able to redirect the mission or reserve automation as a proprietary advantage. The public-benefit structure aligned universal access and open standards with the organisation’s governing purpose rather than leaving them dependent on a temporary loss-leading strategy.

The structure did not remove economic constraints. Let’s Encrypt certificates are free to subscribers, but the service requires engineers, site reliability, legal and compliance work, audits, data-centre capacity, hardware security modules, validation infrastructure, incident response, Certificate Transparency operations, software maintenance and fundraising. The nonprofit model changes who funds that work and how any surplus can be used; it does not make the costs disappear.

Nor did nonprofit status eliminate governance risk. The Board still chooses budgets and strategic direction, major sponsors can become important to financial stability, and root programmes or the CA/Browser Forum can impose requirements that materially change operations. A small executive team can also become a concentration point. The main difference is incentive alignment: ISRG has no conventional shareholders, distributes no profits and is legally structured around public benefit rather than extracting revenue from certificate users.

That institutional choice later became a template for Prossimo and Divvi Up. The projects do not share one economic model, but they share the premise that some security and privacy capabilities generate broad public value without producing a straightforward proprietary market. ISRG tries to bridge that gap through sponsorship, grants, open-source development, direct operation and, in Divvi Up’s case, paid service where a contractual relationship can support the mission.

Let’s Encrypt needed borrowed trust before it could establish its own

Building a certificate authority does not make its certificates useful. Browsers and operating systems must already trust a root above the issuing chain, and a new ISRG root had no installed base in 2013 or 2014. Root inclusion could take years. The founders considered purchasing an established root, with historical estimates ranging from $1 million to $8 million, but instead entered a long-term cross-signing arrangement with IdenTrust in October 2014.

Cross-signing allowed a Let’s Encrypt intermediate or root key to appear in a certificate signed by an authority that devices already trusted. A client could then build a chain to IdenTrust’s accepted root before ISRG’s own root reached major trust stores. This arrangement bridged the gap between a technically functional CA and a publicly useful service, while demonstrating a permanent feature of web PKI: trust is not self-declared. Browser and operating-system programmes establish policies, review audits and decide which roots are accepted.

ISRG announced Let’s Encrypt publicly on 18 November 2014. Dan Jeffery joined in April 2015 as the first full-time employee, helping prepare production operations. The first browser-trusted certificate was issued on 14 September 2015, public-trust milestones followed in October, and general availability began on 3 December 2015. The service issued its millionth certificate in March 2016, its hundred-millionth in June 2017 and its billionth cumulative certificate in February 2020.

Independent inclusion of ISRG Root X1 in major trust programmes reduced dependence on IdenTrust, but it did not end dependence on root governance. Each new root generation still requires inclusion, constraints and distribution across a fragmented device population. Older devices may not trust newer roots, making chain selection an ongoing compatibility problem rather than a launch task that can be completed once.

This history shows why ISRG is both an operator and an ecosystem participant. It can generate keys, conduct ceremonies, issue certificates and publish policies, but it cannot force a root into billions of devices. Trust emerges from technical controls, audits, public rules and independent platform decisions. That distributed authority limits unilateral control while making migration slow and introducing cross-signing complexity that can itself become a source of error.

ACME changed the economics of certificate management

Let’s Encrypt’s most consequential innovation was not free pricing in isolation. It was the combination of free certificates with the Automated Certificate Management Environment protocol. Before widespread automation, a server operator might purchase a certificate, prove control through a manual process, download files, install them, update configuration and repeat the workflow at renewal. Even when the certificate itself was inexpensive, the labour and risk made HTTPS costly to maintain.

ACME converted that lifecycle into a protocol. A client creates or uses an account, submits an order, satisfies a challenge, sends a certificate signing request and receives the certificate. The same client can renew before expiry and react to updated renewal information. Hosting companies, content platforms, web servers, Kubernetes systems and appliances can integrate issuance into normal deployment rather than treating it as a periodic administrative project.

The protocol was designed as an open interface rather than a private Let’s Encrypt API. When ACME became RFC 8555 in March 2019, other public and private certificate authorities could implement it, while clients could support several providers. This separation mattered strategically. Let’s Encrypt benefited from a growing client and integration ecosystem without needing to own every client. Certbot, Caddy, server-native modules, cloud services and certificate-management systems could each translate the standard into their own operating environment.

Automation also changed the viable certificate lifetime. A ninety-day certificate is unattractive when renewal requires a human ticket, but manageable when renewal is a continuously monitored software process. A six-day certificate would be unworkable for most manual users yet becomes plausible in tightly automated infrastructure. ACME therefore did more than reduce administrative cost: it enabled a risk model based on frequent revalidation and replacement.

ISRG’s 2025 annual report said the number of protected websites increased from about 492 million to 762 million during the year and that issuance reached roughly ten million certificates on some days. These are organisation-defined metrics rather than an independent census, and certificates are not the same as unique websites, services or users. Even with that limitation, the figures show that certificate management moved from a specialist purchase into a background function of hosting and application deployment.

Boulder separates internet-facing work from signing authority

The software behind Let’s Encrypt is called Boulder. It is an open-source implementation of an ACME certificate authority, but describing it as a web application understates the security problem. A public CA must receive untrusted requests from the internet while preventing compromise of request-handling code from becoming direct access to signing keys. Boulder therefore divides the issuance path into components with different privileges and responsibilities.

A simplified flow begins at the ACME web front end, continues through registration and order processing, invokes validation authorities, performs policy and Certification Authority Authorization checks, obtains Certificate Transparency commitments and requests signing from the CA layer. Storage, revocation, rate limiting, audit logging, ACME Renewal Information, certificate-revocation-list generation and other supporting functions remain separate. These boundaries divide internet-facing code, decision-making services and the systems permitted to request cryptographic signatures.

Root key material remains offline. Online issuing intermediates use keys protected by hardware security modules. The offline roots establish long-term trust, while the intermediates carry the daily issuance workload and can be replaced or revoked without replacing the whole root. ISRG’s 2019 technical account stated that site reliability engineers historically had the only direct access to certificate-issuing systems, showing how organisational access controls complement the software architecture.

Open source provides review and reuse, but it does not replace secure operation. Another organisation can inspect Boulder or use parts of it, yet Let’s Encrypt’s security also depends on key ceremonies, physical controls, HSM configuration, deployment practices, data-centre redundancy, monitoring, staff procedures and audit evidence. The code describes mechanisms; trusted status depends on the wider system around them.

The complete ACME outage in July 2025 showed the limits of component separation. A resolver-upgrade script created circular or unavailable forwarding dependencies across data centres, and the same DNS problem impaired monitoring and diagnosis. The outage lasted nearly eight hours. No signing keys were compromised, but a shared dependency defeated geographic redundancy, showing that resilience requires control, observability and recovery paths that do not fail through the same service.

Domain validation proves control, not legitimacy

Let’s Encrypt issues domain-validated certificates. A certificate confirms that the applicant demonstrated control of a domain name or, for the newer short-lived profile, an IPv4 or IPv6 address under the applicable validation rules. It does not establish that the operator is a legitimate business, that the site is harmless, that a trademark belongs to the certificate holder or that control will remain unchanged after issuance.

The distinction became more important as HTTPS approached universality. Users often interpret the browser lock icon as a safety judgement, but Transport Layer Security primarily protects the connection and authenticates the endpoint identifier. A phishing site can control a domain and obtain a valid DV certificate. Let’s Encrypt’s mission was to remove the cost and friction of encryption, not to create a global business-identity or content-moderation system.

Common ACME challenges reflect different deployment environments. HTTP-01 requires the applicant to place a token at a defined web path. DNS-01 uses a TXT record under _acme-challenge, enabling wildcard issuance but often requiring access to powerful DNS credentials. TLS-ALPN-01 uses a special certificate during a TLS handshake. IP-address certificates apply approved methods to literal addresses and are restricted to the short-lived profile. DNS-PERSIST-01 is an emerging model for standing, account-bound DNS authorisation rather than a fresh token for every issuance.

Each method relocates risk. Web validation depends on routing, hosting and request handling; DNS validation depends on authoritative DNS, API credentials and propagation; and TLS validation depends on correct service isolation. Persistent authorisation could remove routine DNS API access from renewal systems, but it increases the importance of the ACME account key and the standing record. The CA proves control under a defined protocol; it cannot eliminate every compromise path surrounding that proof.

This narrow scope is one reason Let’s Encrypt can operate at global scale. Organisation Validation and Extended Validation require different evidence about legal identity and authority, and ISRG chose not to offer those products. The resulting service is intentionally limited but highly accessible, protecting transport for an enormous population while leaving reputation, business identity and application safety to other systems.

Validation moved beyond one network viewpoint

A certificate authority that validates from one network location can be deceived if an attacker diverts its BGP route or manipulates DNS along that path. Let’s Encrypt began multi-perspective validation in 2020 with research support linked to Princeton University. Instead of trusting one observation, the CA asks validators in different network positions to corroborate control before issuance.

Industry requirements later formalised the approach. From June 2026, CA/Browser Forum rules required at least four remote perspectives, with corroborating perspectives spanning at least two Regional Internet Registry service regions. Let’s Encrypt’s validation system therefore became geographically and topologically distributed by policy as well as by design.

Multi-perspective validation changes the attacker’s problem because a local route hijack that fools one vantage point may not fool remote networks. It does not make fraudulent validation impossible. A broad routing attack, authoritative-DNS compromise, correlated cloud failure or challenge-implementation flaw can still affect several perspectives. Diversity only helps when the validators do not share hidden dependencies.

CAA and Domain Name System Security Extensions add different controls. CAA records allow a domain to indicate which certificate authorities may issue for it, while DNSSEC can provide integrity for signed DNS responses. From 15 March 2026, public-CA requirements made DNSSEC validation mandatory for primary-perspective domain validation and CAA lookups, and a DNSSEC failure could no longer be treated as permission to proceed.

The 2020 CAA incident showed why a control’s value depends on correct implementation. Boulder rechecked one name repeatedly in certain multi-name orders rather than checking every required name. Approximately three million certificates were identified as potentially affected. The failure did not invalidate CAA; it exposed a software defect in how the rule had been applied. At web scale, a small indexing or loop error can become a mass-replacement and compliance event.

Certificate security therefore extends beyond the CA itself. It depends on the internet’s ability to present consistent views of identifiers across networks and on the CA’s ability to recognise disagreement. Let’s Encrypt’s validation architecture connects PKI directly to routing, DNS and the operational diversity of the wider internet.

Generation Y rebuilt trust through another compatibility layer

Let’s Encrypt’s hierarchy separates roots from issuing intermediates and uses both RSA and ECDSA families. The established roots include ISRG Root X1 and ISRG Root X2. In September 2025, ISRG generated new Generation Y roots, YE and YR, and later announced another group of intermediates. By July 2026, YE1 and YE2 were the active ECDSA intermediates, YR1 and YR2 were the active RSA intermediates, and YE3 and YR3 were retained as backups.

The new roots were not yet broadly present in major trust stores as of 8 July 2026. Default chains therefore continued through established ISRG X roots by using cross-certificates. This allowed the new hierarchy to operate while independent trust distribution continued, but each cross-certificate became another policy object whose extensions, validity, revocation and path-building behaviour had to be correct.

Generation changes are unavoidable. Root and intermediate lifetimes are finite, cryptographic preferences evolve, and key ceremonies or operational boundaries need renewal. A new hierarchy can introduce updated algorithms, profiles and a longer planning horizon. It also exposes differences among browser policies, operating-system stores, embedded devices and alternate chain-selection behaviour.

The hierarchy is therefore a compatibility strategy rather than a static list of certificates. A modern client may prefer a shorter ECDSA chain, while an older platform may need a path through a widely installed RSA root. ACME clients and servers can encounter alternate chains with different outcomes. The CA must balance cryptographic modernisation against the possibility that a valid chain will fail for a material population of devices.

ISRG’s chain documentation functions as a current operational source rather than a historical reference. Operators that pin intermediates or assume a fixed chain length can break during transitions. The intended model is to trust suitable roots and allow normal path building, but embedded software and older platforms do not always behave ideally. Generation Y shows how long-lived public trust is repeatedly reconstructed through shorter-lived operational decisions.

One missing constraint became a public compliance incident

The Generation Y rollout produced a compliance failure in May 2026. Cross-certified subordinate CA certificates were created without a required serverAuth extended-key-usage constraint. The omission affected the certificates linking the new hierarchy to existing trusted roots, not the cryptographic strength of subscriber keys.

Let’s Encrypt stopped affected issuance, created replacement cross-certificates and revoked the defective ones. It also used ACME Renewal Information to encourage subscribers whose chains might be affected to obtain replacement end-entity certificates. The organisation concluded that the subscriber certificates themselves did not require revocation because the defect lay in the subordinate cross-certification profile and could be addressed through chain replacement.

The incident matters beyond one missing extension because it demonstrates how compatibility mechanisms enlarge the compliance surface. A root certificate, an intermediate key, a self-signed certificate and several cross-signed forms may represent related cryptographic identities but carry different policy constraints. A profile suitable for one position in a path can be non-compliant in another.

The response also showed the value of automation developed before the incident. ARI could signal early renewal, ACME clients could obtain replacements without another purchasing process, and new chains could be distributed rapidly. The same operating scale that made the error consequential also made broad technical remediation possible.

Automation could not remove the need for judgement. Let’s Encrypt still had to decide which objects required revocation, how relying parties would build paths, whether subscriber certificates remained acceptable and how quickly the transition should occur. A blanket response could have created unnecessary outages, while an inadequate response could have left non-compliant chains in service. Incident handling at this layer requires a balance among cryptographic validity, formal rules, browser behaviour and service continuity.

The useful conclusion is not that Generation Y failed or that cross-signing is inherently unsound. It is that a public trust migration must be managed as an operational programme, with staged issuance, alternate-chain testing, ARI readiness, explicit closure evidence and a clear account of how every certificate form is constrained.

Short-lived certificates transfer risk into automation

Let’s Encrypt made six-day certificates and certificates for IPv4 and IPv6 addresses generally available on 15 January 2026. The short-lived profile is valid for 160 hours, and IP-address certificates must use it because addresses can be reassigned or change operational control more readily than many domain names. Frequent validation shortens the period during which stale control can remain authenticated.

Shorter certificates reduce the maximum exposure from a stolen key or incorrect issuance, but they move more risk into the renewal system. A ninety-day certificate gives an operator weeks to detect a broken workflow. A six-day certificate can become a service outage within days. The relevant security system therefore includes client scheduling, account-key protection, challenge availability, rate-limit planning, installation, service reloads and monitoring of the certificate actually presented to users.

The optional tlsserver profile moved to 45-day certificates in May 2026, while the default classic profile remained at ninety days at the research cutoff. Let’s Encrypt plans to reduce the default to 64 days in February 2027 and 45 days in February 2028. Separately, CA/Browser Forum requirements reduce the maximum publicly trusted TLS lifetime to 47 days from 15 March 2029. These are scheduled transitions rather than completed facts for every certificate.

The change alters the relationship between the CA and the subscriber. Renewal is no longer a periodic action chosen independently by each client. It becomes a continuous flow that the CA may need to distribute over time and redirect during incidents. Subscriber systems must therefore treat ACME account state, renewal logic and certificate deployment as production control planes.

IP certificates broaden the usefulness of automated public trust. Infrastructure endpoints without stable DNS names, network devices and certain service-discovery environments can authenticate literal addresses. The feature provides directness, but the address must remain controlled and repeatedly reachable through validation. It makes public PKI more useful to infrastructure operators while reinforcing the principle that identity should be refreshed as operational control changes.

ARI turns renewal into a coordinated control system

ACME Renewal Information, published as RFC 9773 in September 2025, gives a certificate authority a way to recommend when a client should renew. The CA can publish a start and end window, distribute routine renewal load and indicate that an affected certificate should be replaced early before revocation. Let’s Encrypt had already implemented the draft server-side, using operational experience to help shape the final standard.

ARI changes renewal from a client-only timer into a shared control plane. Without it, millions of clients may all renew at a fixed fraction of certificate lifetime, producing predictable spikes. During an incident, the CA can revoke certificates but cannot otherwise guarantee that every subscriber replaces them first. ARI-aware clients make a sequenced response possible: obtain a new certificate, deploy it, verify it, and then allow the old one to be revoked or expire.

The extension does not complete the final deployment path. A client can request a replacement and still fail to write the file, update a load balancer, reload a web server or detect that an old node remains in service. Adoption also varies among clients. ARI’s practical value therefore depends on implementation throughout the subscriber’s system, not only on support in the CA API.

DNS-PERSIST-01 addresses a separate automation risk. Conventional DNS-01 renewal often gives an ACME client credentials capable of modifying authoritative DNS, so compromise of the renewal host may become compromise of the domain. The proposed persistent challenge uses a standing record tied to a CA identifier and specific ACME account, with optional wildcard scope and expiration. Routine renewals can then proceed without repeatedly exposing broad DNS API credentials.

This approach relocates trust rather than removing it. The ACME account key becomes more powerful and the standing record must remain correct. At the research cutoff, the method remained an IETF draft. Pebble supported experimentation and Let’s Encrypt had described staging and production plans, but a definitive official announcement of completed production rollout was not identified. It should therefore be treated as an emerging control rather than a universal current feature.

Together, ARI and DNS-PERSIST-01 show that certificate management is moving beyond issuance towards continuous authorisation. The difficult questions concern who may renew, when renewal should occur, how credentials are protected and how a CA can steer a distributed client population during an incident without becoming responsible for every subscriber’s deployment system.

Ending OCSP simplified one layer and enlarged another

Let’s Encrypt ended its Online Certificate Status Protocol service on 6 August 2025. At peak, the service handled approximately 340 billion requests per month. That volume created substantial infrastructure cost, while each query could reveal the client IP address and the site whose certificate was being checked. ISRG concluded that the operational and privacy burden was no longer justified.

The service now publishes certificate-revocation information through certificate revocation lists. CRLs can be cached and distributed in bulk, avoiding a per-visitor query to the CA. They simplify the issuer’s online architecture and fit a browser ecosystem in which platform vendors increasingly aggregate or distribute revocation data through their own systems.

The trade-off concerns freshness and relying-party behaviour. Lists can be large, clients must obtain and process them, and platforms may update at different intervals. Ending OCSP did not make revocation unnecessary. It changed the distribution mechanism and transferred more responsibility to browsers and operating systems that consume the lists.

Let’s Encrypt’s broader strategy also reduces reliance on revocation through short lifetimes and fast renewal. A compromised six-day certificate has a shorter natural exposure window than a ninety-day certificate, while ARI can encourage replacement ahead of revocation. Expiry is still not an immediate response, and some incidents cannot wait. Revocation therefore remains necessary even if it is an imperfect layer.

Earlier mass events showed the conflict between formal deadlines and service continuity. In 2020, the CAA bug potentially affected about three million certificates, and Let’s Encrypt delayed immediate revocation of more than one million remaining certificates rather than abruptly break a large number of sites. In January 2022, a TLS-ALPN validation error led to roughly 2.7 million revocations. Compliance, risk reduction and availability did not point to one simple answer.

The end of OCSP should be understood as architectural simplification, not the end of status management. The system now relies more heavily on CRL distribution, platform integration, short lifetimes and coordinated renewal. Whether it performs better depends on the complete relying-party ecosystem rather than on the CA’s reduced request volume alone.

Sunlight makes transparency cheaper to operate

Certificate Transparency requires publicly trusted certificates to be submitted to append-only logs. Those logs allow domain owners to monitor issuance, enable browsers to demand evidence that certificates were logged and provide researchers with a public dataset for examining misissuance and PKI behaviour. Let’s Encrypt has operated public CT logs since 2019, making ISRG both a major certificate issuer and an operator of another trust-infrastructure layer.

Traditional CT systems often rely on database-backed read APIs that require storage, query capacity, consistency controls and substantial operational support. Let’s Encrypt introduced Sunlight in March 2024 as a static-tile architecture. The Merkle tree is represented in files or objects that can be placed in object storage, cached by content-delivery networks, compressed and independently mirrored.

The write path is intentionally simpler. A single writer advances checkpoints using compare-and-swap protection. Let’s Encrypt’s design argument is that CT already requires certificates to be submitted to several independent logs, so ecosystem-level redundancy can substitute for turning every log into a complex distributed database. If one log fails, others continue providing inclusion while the failed service can recover from a simpler state.

This is characteristic of ISRG’s engineering approach: use cryptographic data structures and independent operators to reduce the complexity of each service. The design does not guarantee that every static-tile log will be accepted by every browser programme or that every failure mode disappears. Log programmes still evaluate key management, operator behaviour, maximum merge delay, monitoring and availability.

Sunlight also addresses the organisation’s economic constraints. A free certificate authority can reduce cost by simplifying adjacent public infrastructure rather than continually expanding service fleets. Static objects are easier to cache, mirror and inspect. If the design is adopted beyond Let’s Encrypt, it could lower the barrier for additional log operators and increase diversity.

The strategic test is therefore adoption rather than architectural elegance. Sunlight becomes public infrastructure only if browser programmes, other CAs, monitors and independent operators use it in production without recreating another hidden central dependency.

Merkle Tree Certificates propose a different post-quantum path

Post-quantum signatures create a size problem for the web PKI because algorithms designed to resist future quantum attacks generally use larger public keys and signatures than current ECDSA or RSA systems. Replacing every signature in a conventional X.509 chain can enlarge TLS handshakes, increasing bandwidth and latency across billions of connections.

In June 2026, Let’s Encrypt announced a programme centred on Merkle Tree Certificates. Instead of signing every certificate individually with a large post-quantum signature, an issuer can place many certificates in a Merkle tree, sign a common checkpoint and provide each certificate with a compact inclusion proof. The model could reduce repeated signature overhead while integrating transparency into the issuance structure.

The roadmap targeted staging in late 2026 and a production-ready environment in 2027. These were plans rather than completed deployment. Ordinary subscribers continued receiving conventional certificates at the research cutoff, while browser support, protocol standardisation, client behaviour and interoperability remained external dependencies.

MTCs show that ISRG is prepared to question the format surrounding the existing CA rather than only replace algorithms inside it. A direct post-quantum substitution could preserve conventional X.509 semantics but impose a lasting size cost. A tree-based system changes issuance, proof distribution and relying-party validation, creating a more demanding transition but potentially better network economics.

The main risk is coordination. A certificate format is useful only if servers can obtain and present it, browsers can validate it, standards bodies can specify it and fallback behaviour does not introduce downgrade or compatibility problems. Conventional X.509 and new mechanisms may need to coexist for years, adding another deployment and chain-selection problem to an already complicated trust system.

ISRG’s operational scale gives it an advantage because it can test proposals against real issuance patterns and build staging infrastructure. Its authority remains limited because it cannot make the web adopt MTCs by announcement. The programme depends on independent convergence among browser, server, standards and cryptographic communities.

Incidents reveal both the scale and the learning model

Let’s Encrypt’s history includes several incidents that define its limits as clearly as its growth. TLS-SNI-01 was disabled in January 2018 after shared-hosting behaviour created an unauthorised validation path. The CAA rechecking bug in February 2020 led to a large replacement and revocation programme. A TLS-ALPN validation error in January 2022 triggered roughly 2.7 million revocations. A DNS dependency caused a complete API outage across data centres for nearly eight hours in July 2025. Generation Y cross-certificates had to be replaced in May 2026 because of the missing EKU constraint.

These events do not by themselves establish that Let’s Encrypt is uniquely unreliable. A service issuing at this scale will expose rare interactions and faces close scrutiny from root programmes and security researchers. The more relevant test is how the organisation detects, discloses, contains and learns from failure.

The record shows repeated publication of incident details, suspension of affected issuance, replacement tooling and changes to architecture or procedure. It also shows that formal compliance and operational continuity can conflict. Immediate revocation may satisfy a deadline while breaking services whose operators have not renewed, whereas delayed revocation may preserve availability while leaving potentially affected certificates valid and attracting scrutiny.

Automation amplifies both consequences and recovery. One defect can affect millions of certificates, while the same automation can replace those certificates faster than a manual system. ARI developed partly from the need to coordinate replacement at scale. Multi-perspective validation and DNSSEC requirements reflect recognition that network paths and DNS behaviour can undermine certificate validation.

Professional users should therefore avoid treating the CA as the only responsible party. Operators need renewal monitoring, current clients, tested failover, reliable contacts and awareness of incident channels. Root programmes need proportionate rules and evidence, while ISRG needs monitoring and recovery systems that remain usable when a shared dependency fails. Public trust is sustained through visible failure and reduced recurrence, not through an assumption that incidents can be eliminated.

Prossimo finances the difficult path from safer code to adoption

Prossimo addresses another class of infrastructure risk: memory corruption in software written in languages that do not enforce memory safety. Use-after-free conditions, buffer overflows and invalid pointer access have affected TLS libraries, DNS software, operating systems, privilege-management tools and codecs for decades. Rewriting critical components can reduce this category of defect, but the work is expensive and the shared beneficiaries often have no single incentive to fund it.

ISRG’s Board approved the memory-safety project on 9 December 2020, and Prossimo became publicly established in 2021. The programme does not employ one central team to rewrite the internet. It identifies an important component, defines an initiative, raises dedicated funds, contracts maintainers or specialist engineering companies, pays for audits and tooling, supports packaging and compatibility, and tries to move the result into real deployment.

The operating model matters because technical completion is not the same as adoption. A Rust implementation may be memory-safe while lacking an API required by existing applications. It may perform differently, need a C interface, require packaging or fail in a constrained environment. Prossimo therefore funds the unglamorous work between prototype and default infrastructure: compatibility layers, benchmarks, security audits, no_std operation, distribution integration and maintainer handoff.

The programme works through a wide network. Funders have included AWS, the Sovereign Tech Agency, Alpha-Omega, Google, Cisco, Cloudflare, Shopify, ICANN and others. Contractors and partners have included Ferrous Systems, Tweede Golf, the Rust Foundation and the Trifecta Tech Foundation. These relationships do not make ISRG the owner of every resulting project. Copyright, governance and maintenance may remain with independent communities or move to a specialist foundation.

Prossimo is best understood as an adoption engine. It concentrates capital and coordination where fragmented beneficiaries cannot easily finance common infrastructure. Its success should be measured by whether implementations are audited, packaged, deployed, maintained and eventually treated as ordinary choices rather than by the number of initiatives announced.

Rustls shows why safer code still needs compatibility engineering

Rustls is one of Prossimo’s most developed initiatives. It is a TLS implementation written in Rust and designed to provide memory safety while meeting modern cryptographic and operational requirements. A native Rust API would not be enough to displace mature libraries, so the work has included a C interface, an OpenSSL compatibility layer, asynchronous support, no_std and no-allocation modes, FIPS-capable cryptographic options and post-quantum key exchange.

Each capability addresses a different adoption barrier. C compatibility allows existing software to use the library without being rewritten in Rust. OpenSSL compatibility targets applications that assume familiar APIs. no_std supports environments without a full operating-system standard library, while no-allocation work serves constrained systems. FIPS support matters in regulated deployments, and performance engineering responds to operators unwilling to accept a material infrastructure penalty in exchange for theoretical safety.

Prossimo has published favourable benchmarks, but the results should remain attributed rather than treated as universal proof. TLS performance depends on algorithm choice, hardware, record sizes, concurrency, session reuse and application integration. A library can lead one test while encountering compatibility or operational limits elsewhere.

The governance transition is as important as the code. In 2025, Rustls became an inaugural hosted project in the Rust Foundation’s Innovation Lab. That move could provide a durable home beyond a sequence of ISRG contracts. It reflects the desired Prossimo lifecycle: fund missing work, lower adoption barriers and then place stewardship where maintainers and users can continue it.

Rustls shows why memory safety is an institutional problem as much as a language choice. The implementation must be trustworthy, but the surrounding ecosystem must be able to adopt it. Prossimo finances the interfaces, audits, organisational relationships and deployment evidence that turn a safer library into a practical infrastructure option.

Production adoption separates mature work from funded ambition

The clearest Prossimo results are projects that have moved through development into production. The ntpd-rs initiative funded a memory-safe Network Time Protocol implementation with server, client and Network Time Security support. It underwent an external audit, moved to the Trifecta Tech Foundation for stewardship, gained Fedora and Ubuntu packages and entered Let’s Encrypt’s infrastructure in June 2024.

That sequence matters because time synchronisation is a hidden dependency for certificates, logs, authentication and distributed systems. A new daemon becomes useful only when operators trust its accuracy, can install it through normal packages and are willing to run it. By deploying ntpd-rs, ISRG became an adopter of the security work it financed rather than only a grant administrator.

sudo-rs offers a distribution-level example. Canonical made it the default sudo implementation in Ubuntu 26.04 LTS while retaining the original implementation as a compatibility fallback. This is strong evidence of adoption but not proof of complete feature parity. A fallback recognises that mature tools accumulate plugins, workflows and undocumented edge cases that a replacement may not yet reproduce.

Rust support in the Linux kernel, merged in 2022 and supported by related funding, is a broader ecosystem milestone. It allows selected drivers and modules to be written in a memory-safe language without replacing the existing C code. The benefit is prospective: new components can avoid some classes of memory error while remaining part of a large legacy system.

Hickory DNS remains a more cautious case. The project is developing a high-performance recursive resolver in Rust with DNSSEC, NSEC3, opportunistic encryption, audits and production-readiness work. Prossimo has described preparation for Let’s Encrypt’s query volume, but a completed migration had not been verified at the cutoff. A funded implementation, an audit, a deployment plan and an operational service remain separate evidence stages.

Together, these projects define the adoption ladder Prossimo is trying to standardise: build, audit, package, deploy in a demanding environment, transfer stewardship and make the safer component a default with a controlled fallback. The programme’s long-term value depends on repeating that progression more often than it announces new rewrites.

Memory safety narrows one class of failure

Memory-safe languages can prevent many invalid accesses, use-after-free conditions and buffer errors by making unsafe states difficult or impossible to represent in ordinary code. This reduction is valuable in infrastructure parsers and protocol engines that routinely handle attacker-controlled input.

Memory safety is not complete software security. A Rust implementation can still contain logic errors, cryptographic misuse, denial-of-service weaknesses, unsafe blocks, poor dependency choices, privilege mistakes or interoperability defects. A rewrite may introduce new behaviour even as it removes old classes of bugs. Review, fuzzing, audits, reproducible builds, dependency governance and careful migration remain necessary.

Compatibility creates another source of risk. Mature C components often expose decades of behaviour not fully documented in their formal interfaces. Applications may rely on error codes, timing, configuration syntax or plugin conventions that a replacement does not reproduce. A memory-safe implementation that is theoretically correct but operationally incompatible may fail to gain adoption or cause outages during migration.

Prossimo’s programme design acknowledges this by funding C APIs, OpenSSL compatibility, packaging and staged defaults. It also raises an economic question: when should the ecosystem finance a rewrite rather than continue hardening existing code? The answer depends on vulnerability history, maintainer capacity, interface stability and whether the new implementation can attract durable stewardship.

The portfolio includes Rustls, Hickory DNS, sudo-rs, su-rs, ntpd-rs, the rav1d AV1 decoder, memory-safe zlib work, Rust for Linux, the River reverse proxy, Apache mod_tls and selected curl work. Maturity varies widely, and listing the projects together does not mean they are all production-ready or governed by ISRG.

The defensible assessment is that Prossimo has built a repeatable financing and adoption method, not a guarantee that memory-unsafe infrastructure will disappear. Its contribution is to convert a general policy preference into projects with maintainers, audits, interfaces and deployment targets. The eventual outcome will be visible in defaults, package use, continuity and vulnerability exposure over several years.

Divvi Up avoids collecting the plaintext it does not need

Divvi Up addresses the privacy cost of conventional telemetry. Most analytics systems send individual events to one organisation, which stores plaintext records and later computes aggregates. Even when the desired result is a simple count or sum, the collector often receives a richer dataset than the final question requires.

Divvi Up changes that architecture. A client uses a Verifiable Distributed Aggregation Function to split a measurement into encrypted shares. One share goes to a leader aggregator and another to a helper. Neither server receives the original measurement in plaintext. Each computes a partial aggregate, and a collector combines the partial results to obtain a statistic across the population.

The privacy guarantee depends on institutional separation. If at least one aggregator behaves honestly and the two do not collude, neither can reconstruct an individual measurement from its share. If both collude or one organisation effectively controls both, the main assumption fails. Divvi Up therefore makes organisational independence part of the cryptographic design.

ISRG approved the project in October 2020 and announced ISRG Prio Services in November. Its first live use supported private analytics for COVID exposure-notification systems in December 2020. The service was renamed Divvi Up in December 2021 and later expanded into browser, human-rights and application telemetry.

This model differs from Let’s Encrypt. Certificate subscribers do not pay ISRG, while Divvi Up invites organisations to discuss paid pilots and production service. The product combines open protocols, the open-source Janus implementation and a nonprofit-operated aggregator with a commercial relationship. That revenue can support the mission, but it also creates expectations around reliability, data governance, service levels and customer support.

Divvi Up’s main proposition is not that data collection becomes risk-free. It is that applications can decide in advance which aggregate they need and avoid building a central store of individual plaintext measurements. That constraint reduces future analytical flexibility, but it also removes a significant source of privacy and breach risk.

Privacy depends on the full deployment, not one protocol

Divvi Up combines several layers that solve different problems. Verifiable Distributed Aggregation Functions define how a measurement is split, validated and aggregated. Prio3 supports general counts, sums and histograms, while other families target more specialised tasks. Verification matters because a malicious client should not be able to submit malformed values that corrupt the final aggregate.

The Distributed Aggregation Protocol coordinates report upload, aggregation jobs, communication between the leader and helper, collection and error handling. At the research cutoff, DAP was Internet-Draft 19, dated 6 July 2026, while VDAF was an IRTF draft, version 20, dated 24 June 2026. These were active standards efforts rather than final RFCs, so wire formats and semantics could continue changing.

Janus is ISRG’s Rust implementation of DAP and powers Divvi Up. It remained under active development and supported VDAFs with trivial aggregation parameters, including Prio3. It did not support every scheme, including those with non-trivial parameters such as Mastic. An organisation therefore has to evaluate the implementation against the exact measurement it needs.

DAP protects report contents during aggregation, but it does not automatically hide network metadata. An aggregator may still see a client IP address, request timing and task participation. Oblivious HTTP can place an independent relay between the client and aggregator, allowing the relay to see the connection but not the encrypted destination content, while the aggregator sees the report without the original network identity. The relay and aggregator must remain operationally separate.

Distributed aggregation also cannot prevent every inference from the result. Queries over very small groups or repeated overlapping queries may reveal information even when individual reports were never exposed. Differential privacy can add controlled noise, limit queries and track a privacy budget, at the cost of statistical precision.

These controls should not be collapsed into one claim. A deployment may use DAP without OHTTP or private aggregation without differential privacy. The final privacy property depends on protocol version, aggregator independence, relay separation, batch size, query policy, cryptographic implementation and organisational controls. Divvi Up provides an architecture and service, but each customer must define the threat model it is trying to address.

Production evidence exists, but the market remains narrow

Divvi Up’s first operational phase was tied to exposure-notification analytics. ISRG reported that the service had processed more than 40 billion metrics by 2022. The figure is organisation-reported, but it shows that distributed aggregation operated beyond a laboratory prototype.

Later deployments are more revealing. Horizontal became the first publicly announced production subscriber, using the service in applications connected to human rights and sensitive communications. Mozilla uses an ISRG-operated aggregator alongside a Mozilla-operated aggregator for Firefox telemetry. This arrangement reflects the non-collusion model because two organisations process separate shares and neither should receive the original measurement.

ISRG also identifies Tinfoil and a prototype integration with the Flower federated-learning ecosystem. The Flower work suggests a potential role in machine-learning systems that need population-level information without centralising local data. It remains a prototype rather than evidence of a mature production market.

These examples show why private measurement is most attractive where conventional telemetry creates exceptional trust risk. Browsers observe sensitive user behaviour, human-rights applications can endanger users if data is exposed, and public-health systems need population statistics without creating central movement records. Federated learning may benefit from aggregate signals without collecting raw examples.

The architecture also changes product management. A conventional analytics team can collect detailed events and decide later which queries to run. Divvi Up requires the team to choose an aggregate function, define the batch, set privacy thresholds and accept that uncollected detail cannot be recovered. The technology therefore limits organisational curiosity as well as protecting data.

Public customer evidence remains incomplete. ISRG has not disclosed a full subscriber census, traffic volume, service-level record or detailed case studies for every deployment. Firefox and Horizontal are meaningful production signals, but they do not establish broad market adoption. The next stage will be determined by whether more organisations accept the integration cost in exchange for reducing data exposure.

Paid privacy infrastructure has not yet proved its economics

Divvi Up complicates descriptions of ISRG as entirely donation-supported. Its website offers paid pilots and production service, while pricing remains private. In ISRG’s unaudited January-to-October 2025 figures, Divvi Up represented 9% of revenue and 19.2% of expenses.

Those percentages do not establish profitability. The report did not disclose the underlying dollar allocation, the treatment of shared overhead, customer concentration or the amount of restricted grant funding supporting the project. A 9% revenue share may indicate useful diversification without covering the full cost of operating and developing the service.

The commercial model has practical advantages. Payment can align service capacity with customer demand and reduce dependence on annual grants. A production contract creates direct feedback about reliability, integration and support, while funding protocol engineering that benefits the open ecosystem.

It also creates tensions. A nonprofit has to decide which features serve a paying customer and which advance the public standard. Private pricing makes market access harder to assess, and a small number of large subscribers could become operationally or financially influential. The two-aggregator design may also require cooperation with another trusted provider, making the service more difficult to sell as a single-vendor solution.

Divvi Up is therefore a test of whether privacy can be sold as an infrastructure property rather than added later as a compliance feature. Its alternatives include centralised analytics, internal secure-computation systems, local differential privacy and the decision not to collect a metric at all.

A financially meaningful service could give ISRG recurring revenue connected to direct customer value. A specialist service that remains subsidy-dependent could still be strategically useful if it advances standards and enables high-risk applications. Current evidence does not support choosing between those outcomes. The relevant measures are paid production users, protocol stability, independent privacy review, operational reliability and clearer accounting of how revenue supports the wider mission.

Digital identity is still research rather than an operating service

ISRG’s current research extends its interest in privacy from machine telemetry to human credentials. It is developing an open-source Rust implementation of Longfellow, a zero-knowledge-proof system associated with Google. The work is being conducted with the SIROS Foundation and is intended to support a PKI backend for the European digital-identity effort known as wwWallet.

The objective is selective disclosure. A user could prove a statement about an existing credential, such as being above an age threshold or holding a licence, without presenting every field in the credential. Zero-knowledge proofs can reduce the amount of personal data that verifiers receive and retain.

This remains research and implementation work rather than a mature ISRG identity service. The system depends on credential issuers, wallets, verifier software, trust registries, revocation systems and standards outside the organisation. A cryptographic proof can establish that a signed credential contains a property, but it cannot establish whether the original issuer conducted a sound identity process.

The work also introduces a post-quantum consideration because credential lifetimes may exceed those of web certificates. ISRG’s Merkle Tree Certificate programme and Longfellow research therefore address different parts of a broader transition. One concerns server authentication at internet scale; the other concerns minimal disclosure from human credentials.

Identity could eventually become another operating project, but the available evidence does not show that decision has been made. The prudent description is an emerging research area with a proof-of-concept implementation and a planned integration relationship. Its relevance lies in the institutional thesis it reflects: where trust infrastructure collects excessive data or imposes unnecessary cost, open cryptographic systems and a public-benefit operator may be able to change the default.

A small Board oversees several high-consequence systems

ISRG’s current public Board lists eight directors: Josh Aas, Vicky Chin, Jennifer Granick, J. Alex Halderman, Pascal Jaillon, David Nalley, Erica Portnoy and Christine Runnegar. Their affiliations connect the organisation with ISRG itself, Mozilla, the University of Michigan, OVHcloud, Amazon, EFF and independent legal or policy expertise. Christine Runnegar was identified as Board Chair in the 2025 annual report, while the current Board page retains her as a director without restating officer titles.

The roster changed after the annual report. Richard Barnes of Cisco and Aanchal Gupta were among ten directors listed in the report but no longer appeared on the live page. No public departure announcement or exact effective date was identified. That absence does not imply misconduct, but it shows a transparency gap: current membership is visible while the timing and reasons for transitions may not be.

Josh Aas remains Executive Director. The 2025 report also identified leadership in finance, legal, advancement, people and engineering, although many staff were presented by first name only. ISRG is remote and distributed, and its San Francisco and Minneapolis addresses serve legal or mail functions rather than indicating a large central operations site.

External controls reinforce internal governance. Let’s Encrypt publishes certificate policies and practice statements, undergoes WebTrust audits, reports incidents and operates under root-program requirements. Open-source software and standards participation make technical decisions visible. These mechanisms do not replace Board accountability, but they create independent audiences that can challenge errors.

The small-team model remains a material risk. Expertise in CA operations, HSMs, cryptography, standards and reliability may be concentrated among relatively few people. Portfolio growth can also pull legal, engineering, finance and operational capacity in different directions. Board oversight therefore has to assess whether the organisation can support several high-consequence systems without creating hidden single-person or shared-service dependencies.

ISRG coordinates relationships without owning the ecosystem

ISRG’s network of relationships is extensive, but the mechanisms differ. Mozilla, EFF and the University of Michigan belonged to the founding coalition. Cisco and Akamai supplied early funding or infrastructure, while IdenTrust provided cross-signing. Browser and operating-system companies including Apple, Google and Microsoft act as root-program or relying-party stakeholders. None owns ISRG.

Standards relationships are also distributed. The Internet Engineering Task Force produced ACME as RFC 8555 and ARI as RFC 9773, while DNS-PERSIST-01 remained a draft. The IETF Privacy Preserving Measurement working group develops DAP, the Internet Research Task Force develops VDAF, and the CA/Browser Forum sets baseline requirements for public TLS certificates. ISRG participates and implements but does not control these bodies unilaterally.

Prossimo works through funders, contractors and downstream stewards. AWS, the Sovereign Tech Agency, Alpha-Omega, Google, Cisco, Cloudflare, Shopify and ICANN have supported initiatives, while Ferrous Systems and Tweede Golf have undertaken engineering work. The Rust Foundation hosts Rustls, and the Trifecta Tech Foundation stewards ntpd-rs. Canonical’s adoption of sudo-rs is a distribution relationship rather than an acquisition or transfer of control to ISRG.

Divvi Up depends on another set of institutions. Mozilla is both a subscriber and operator of the second Firefox aggregator, while Cloudflare contributes to related protocol work. The Open Technology Fund, Ford Foundation, Internet Society Foundation, Meta and other supporters have funded privacy measurement. Horizontal is a production user, and SIROS with wwWallet connects emerging identity research to the European digital-identity ecosystem.

ISRG’s institutional skill is coordinating without claiming ownership. It may provide legal capacity, fundraising, engineering, service operation or standards participation while another entity controls the browser, DNS zone, distribution, software project or second aggregator. This reduces vertical concentration but relies on continuing alignment. Every relationship therefore has to be understood by its mechanism: funding, trust decision, implementation, governance, service use or standards authority.

Financial recovery does not remove funding volatility

ISRG’s revenue grew from approximately $100,400 in 2014 to $9,563,960 in 2024. Its 2024 Form 990 reported $7,925,896 in expenses, a positive change of $1,638,064 and year-end net assets of $5,110,071. Total assets were $6,887,136 and liabilities $1,777,065. The reserve is significant for a small nonprofit but modest relative to the consequences of the services it operates.

The annual pattern is uneven. Revenue increased through 2022, reaching about $8.08 million, before falling to $5.16 million in 2023 while expenses reached $7.81 million. The resulting deficit of $2,651,888 reduced net assets to $3.39 million. Revenue recovered strongly in 2024 and returned the organisation to surplus.

The volatility reflects a model based on sponsorships, contributions and grants rather than usage fees from Let’s Encrypt. ISRG’s unaudited January-to-October 2025 chart attributed 40% of revenue to sponsorships, 24% to grants, 23% to contributions, 9% to Divvi Up and 4% to interest and dividends. Expenses were allocated 50.8% to Let’s Encrypt, 19.2% to Divvi Up, 12.3% to advancement, 11% to operations and administration, and 6.8% to Prossimo.

The figures show that fundraising is part of infrastructure operation rather than discretionary overhead. Advancement consumes resources because the free certificate service has no subscriber billing relationship. They also show a more mixed revenue model: charitable support remains central, but Divvi Up and investment income make claims that ISRG is funded only through generosity too simple in an accounting sense.

The 2024 filing reported $352,850 in reportable compensation and $44,856 in other compensation for Executive Director Joshua Aas. These regulatory categories are not identical to base salary and should be interpreted within Form 990 disclosure rules. Their relevance lies in the public visibility of compensation at an organisation whose individual project budgets remain less clear.

The largest unresolved financial questions concern concentration and allocation. ISRG does not publish sponsor concentration, audited standalone accounts for each project or exact dollar values behind the 2025 percentage chart. A global service can appear healthy at organisational level while one project remains underfunded or one sponsor is unusually important. Resilience therefore has to be judged against replacement cost, incident capacity and dependency on in-kind support, not only whether the latest year produced a surplus.

The portfolio tests whether one institution can support several public goods

Across its projects, ISRG follows a consistent method. It identifies a security or privacy problem that conventional product incentives have not solved, works through open standards and open-source implementations, raises mission-aligned funding, operates infrastructure where a neutral service is needed and seeks adoption beyond the organisation.

Let’s Encrypt is the mature form of the model: a free global service with public roots, audits, an open protocol and a broad client ecosystem. Prossimo is the funding-and-adoption form: ISRG does not operate every resulting component but pays for the path from safer code to real deployment. Divvi Up is a hybrid, combining open cryptographic protocols and software with a paid service. Digital identity remains exploratory.

This approach can address coordination and financing gaps. It can lower access barriers, reduce proprietary lock-in and provide a credible operator where markets would otherwise centralise data or charge for a basic trust function. It can also align funders around shared infrastructure instead of encouraging several incompatible private implementations.

It cannot remove dependency. Let’s Encrypt depends on root programmes, DNS, BGP, Certificate Transparency, data centres and subscriber automation. Prossimo depends on maintainers, software distributions and long-term project homes. Divvi Up depends on independent aggregators, evolving standards, relays, customer integration and query governance. Identity work depends on issuers, wallets and verifier systems.

Public-benefit status also cannot replace scale discipline. Each additional project creates demands on legal, financial, engineering and governance capacity. A small organisation may launch infrastructure efficiently through automation, but incident response, knowledge transfer and succession do not scale as cheaply as routine traffic. ISRG risks overextension if it interprets every promising public-interest technology as a mandate to operate another permanent service.

The organisation’s longer-term significance therefore depends on selectivity. It must distinguish projects that require an ISRG-operated service from those better supported through grants, standards work or transfer to another foundation. The strongest version of the model is not an ever-expanding nonprofit conglomerate, but an institution that knows when to operate, when to fund and when to hand responsibility elsewhere.

Public-interest infrastructure still creates concentrated power

ISRG has changed the assumptions surrounding several infrastructure layers. Let’s Encrypt made encryption an expected default rather than a premium product. ACME made certificate lifecycle automation part of normal software operation. Multi-perspective validation connected certificate issuance to routing diversity, Sunlight treated verifiable static data as an alternative to complex log systems, Prossimo turned memory-safety advocacy into funded adoption, and Divvi Up made non-centralised telemetry available as a service.

The common thread is reducing unnecessary trust concentration. A website operator should not need a manual commercial relationship to encrypt traffic. A safer implementation should not fail because each beneficiary waits for another to fund compatibility. An analytics service should not receive every individual measurement when only an aggregate is required. A credential verifier should not receive every personal field when one predicate is sufficient.

ISRG itself nevertheless becomes a concentration point. Its CA signs certificates for a vast population, its service choices influence operating practice, and its funding decisions can affect which open-source replacements advance. Public-benefit infrastructure does not eliminate power; it changes the incentives, controls and review mechanisms through which that power is exercised.

Operators should therefore treat ISRG services as production dependencies rather than background conveniences. ACME account keys, renewal clients, DNS records, certificate installation, CRL consumption and incident monitoring belong in ordinary risk management. Divvi Up requires an explicit privacy model and genuinely separate processors. Prossimo-funded replacements require the same technical and operational evaluation as any other infrastructure component.

For policymakers and funders, ISRG shows that a small nonprofit can create global public goods when software, standards and automation produce leverage. That model warrants support because the benefits are widely shared. Support should be accompanied by clearer disclosure of project costs, reserves, sponsor concentration, Board succession and incident-response capacity.

The organisation’s most important achievement is not the number of certificates issued or initiatives funded. It is whether infrastructure can become ordinary while remaining open, trustworthy, replaceable and resilient. The less visible ISRG’s services become in daily use, the more consequential the institution behind them becomes.