Trust nobody owned: the expired root certificate and hospital legacy clients

The week

On September 30, 2021, a root certificate called IdenTrust DST Root CA X3 expired. Its end date had been written into the certificate when it was issued in 2000, and Let’s Encrypt had been publishing warnings about it for more than a year. Even so, the days around the expiry brought a run of reports of broken integrations, scripts, appliances and older devices. The servers in most of those reports held valid certificates, renewed on schedule. The failures were on the other side of the connection.

Why that mattered comes down to how trust works online. When one computer connects securely to another, the server shows a certificate, a kind of electronic ID card. The connecting computer, the client, checks that the certificate was issued by an authority it already trusts. The list of authorities it trusts is called a trust store, and the top-level authorities on that list are called roots. The secure connection itself uses a standard called TLS, the technology behind the padlock in a browser and behind most system-to-system traffic in a hospital.

Let’s Encrypt, the free, automated certificate authority behind a large share of the web’s TLS certificates, launched in 2015 with a problem every new authority faces. Its own root, ISRG Root X1, was not yet in anyone’s trust store, and getting a new root into operating systems, browsers and devices takes years. So it arranged a cross-signature from IdenTrust. Older devices that had never heard of Let’s Encrypt still knew the IdenTrust root, and IdenTrust vouched for Let’s Encrypt. Meanwhile ISRG Root X1 spread into trust stores, so newer devices came to trust it directly.

The IdenTrust root’s expiry forced a choice. In December 2020, Let’s Encrypt announced that IdenTrust had agreed to a three-year cross-signature of ISRG Root X1 that ran past the old root’s own end date. This worked because Android does not enforce expiry dates on the roots in its trust store. Older Android phones, which made up roughly a third of Android devices in use at the time by Let’s Encrypt’s account, would therefore keep working. Let’s Encrypt made this longer chain its default.

The arrangement had a known cost. Clients that do enforce root expiry, and that build certificate chains in a particular way, could follow the long chain up to the expired IdenTrust root and stop there. On September 13, 2021, the OpenSSL project published a note explaining that OpenSSL 1.0.2 behaved exactly like this. OpenSSL is the most widely used open-source TLS library, the component inside a program that handles the secure connection. Version 1.0.2 prefers the chain the server sends over its own trust store, so it reported the certificate as expired even when ISRG Root X1 was present. Public support for 1.0.2 had already ended at the close of 2019, but it remained embedded in a great deal of software.

The OpenSSL note offered three workarounds. Remove the expired root from the client’s trust store and make sure ISRG Root X1 is there. Turn on a setting that makes the library prefer its own trusted roots, which applications had to enable in code. Or have the server send an alternative, shorter chain, which would break the older Android devices the long chain was designed to protect. Each fix belonged to a different party, and none was automatic.

Let’s Encrypt’s compatibility documentation listed the platforms that trusted ISRG Root X1 directly. Among them were macOS 10.12.1 and later, iOS 10 and later, Android 7.1.1 and later, Firefox 50 and later, and Java 8u141 and later. Windows trusted it from XP Service Pack 3 onward, provided automatic root certificate updates had not been turned off. Anything older, or anything carrying its own frozen copy of a trust store, was exposed.

An API is the doorway one computer system uses to request data from another, the way a laboratory system asks a partner for results. Many of the clients at risk were exactly that kind of machine-to-machine connection, with no person watching a browser warning. A widely read security researcher had warned on September 20 that some things would break. In the days after the expiry, he and others collected reports involving security appliances, cloud services, software platforms and consumer devices. Trade press noted that some failures came from servers sending outdated chains, but most traced back to clients.

There had been a smaller rehearsal. On May 30, 2020, an older root called AddTrust External CA Root expired, and some services saw failures from older OpenSSL and other libraries that could not find an alternative path. The 2021 episode was larger because Let’s Encrypt certificates were everywhere, including on the APIs and cloud services that hospital integrations call every few minutes.

Most certificate incidents are server stories. Someone forgot to renew the certificate on a website, the site shows a warning, and customers call. Embarrassing, but easy to explain and quick to fix. The episode of September 30, 2021 ran the other way. The servers held valid certificates. What failed were clients: the programs, devices and scripts that connect to those servers. Many of them had not refreshed their list of trusted roots in years.

In a health system, those clients are everywhere. Each one carries a trust decision that somebody made once, at build time, and nobody has revisited since. We start with the mechanism, because the rest depends on it. Then come the episode’s three parts: the clients that broke, the inventories that could not see them, and the owners who had to act. Two final sections cover what a scheduled failure costs a hospital and how to move trust decisions back in-house.

How a client decides whom to trust

Every time two computer systems talk securely, they go through a short exchange called a handshake. The server presents a certificate, a small digital document that says, in effect, “I really am the lab partner’s service, and here is proof.” The client checks that proof before it sends or receives any sensitive data. This protection is TLS, short for Transport Layer Security. It protects patient data moving between hospital systems, payers, laboratories and manufacturers.

The proof works like a chain of references. A certificate authority signs the server’s certificate. That authority’s own certificate was signed by a higher authority, and so on up to a root. A root is the top of the chain: an authority whose certificate is built directly into the client’s trust store. The trust store is a list, kept on the device or inside the software, of the roots that client is willing to believe.

A building’s front desk works the same way. It keeps a binder of approved ID formats. A visitor shows a badge, and the guard checks whether the issuer is in the binder. If the binder is current, everything works. If it was printed in 2016 and never updated, a visitor with a genuine badge from a newer issuer gets turned away. The visitor did nothing wrong. The binder is stale.

Chain building, step by step

The detail that caught people out is that a certificate can have more than one valid path to a root. A cross-signature creates a second path. The same intermediate authority can be vouched for by a new root and, separately, by an old one. The server usually sends the client a bundle of certificates, and the client assembles a path from them to something in its trust store.

Well-behaved clients try the alternatives. If one path ends at an expired root, they look for another that ends at a valid one. Some older libraries do not. They take the first path the server’s bundle suggests and give up if it fails. OpenSSL 1.0.2 had this habit, as its maintainers explained before the expiry. A client running it could hold ISRG Root X1 in its trust store and still reject a Let’s Encrypt certificate, because it walked the long chain to the expired IdenTrust root first.

Android was the opposite case. It does not enforce the expiry dates of roots in its trust store, so an old phone happily accepted the long chain after September 30. That asymmetry is why Let’s Encrypt chose the long chain as its default. It protected a very large population of phones at the cost of a smaller population of old libraries, mostly inside servers, appliances and integration software.

The server operator’s dilemma

For anyone running a server, this created a choice with no free option. Serve the long chain, and very old Android devices keep working while OpenSSL 1.0.2 clients without workarounds fail. Serve the short chain, and the reverse happens. A partner running a patient portal cared about old phones. A partner running a machine-to-machine API cared about old libraries. Each chose differently, and a hospital calling many partners could see both kinds of failure.

This is why the client side is where control has to sit. A hospital cannot set its partners’ chain choices. It can make sure its own clients find a valid path, whatever chain a partner sends.

Why roots expire at all

A root certificate has an end date for the same reason a passport does. The cryptographic key behind it ages: computing power grows, attacks on older algorithms improve, and the longer a key is in use the more chances there are for it to leak. Expiry forces the system to move to newer keys and newer algorithms on a known schedule.

The cost of that discipline falls on clients. A server can switch to a new certificate overnight. A client can only accept the new root if someone has put it in the trust store. For devices and embedded software, that someone is often a vendor on a release cycle measured in years. A root’s expiry therefore tests the slowest-updating clients in the whole ecosystem, which is a population hospitals contribute to heavily.

Hidden copies of the trust store

One more detail matters. Many programs do not use the operating system’s list of trusted roots at all. A Java application uses the trust store bundled with its Java runtime, which may be the one shipped in the vendor’s installer years ago. Python programs often carry their own bundle of roots. Appliances built on Linux carry the bundle from the day their image was built. Updating the computer underneath does not update these hidden copies.

Windows adds its own twist. By default it fetches trusted roots from Microsoft on demand, which is why XP Service Pack 3 and later could trust ISRG Root X1. Hospitals often turn that automatic update off on locked-down clinical workstations and servers with no internet access. That is a defensible security choice, but it means those machines only learn new roots when someone pushes them deliberately.

The clients that broke

The failures showed up in places that rarely get an architecture review. Interface engines are the switchboards that move messages between hospital systems, and some of them pull lab results or eligibility data from partner APIs. Scripts move files to a clearinghouse every night. Data center appliances check licenses or send telemetry, meaning routine status reports, over HTTPS. Tablets and handhelds can no longer take operating system updates. Medical devices and their gateways call a manufacturer’s cloud service for updates or remote support.

Each of these carries its own trust store, usually frozen on the day its firmware or base image was built. Firmware is the built-in software that runs a device; a base image is the standard template from which a server or appliance is set up. A Linux appliance shipped in 2016 trusts the roots that existed in 2016. When the trust anchor moved, these clients had no way to follow.

Why hospitals have more of them

Health systems carry more frozen clients than most industries, for reasons that are mostly sound. Clinical devices are validated as configured, which discourages routine updates. Changing the software on an infusion pump or an imaging system is a controlled process, usually run by the manufacturer. Laboratory, imaging and pharmacy platforms often run for a decade. Integration work is spread across many teams and vendors, each with its own habits.

The mix also differs by type of organization. An academic medical center may run hundreds of interfaces through one or two engines, with a dedicated integration team and a large biomedical engineering department. That concentration makes the problem easier to find but raises the stakes when one engine fails. A community hospital may depend on a handful of vendor-hosted systems and a part-time interface analyst. Most of its exposure lies inside vendor products it cannot inspect.

An ambulatory network has a different profile again. It tends to have many small sites, each with its own appliances, printers, kiosks and practice management connections. The clients are scattered and often managed by a managed service provider. A failure at one site can look like a local network fault for days. Critical access hospitals and rural clinics, with the thinnest staffing, are the most likely to run old equipment past its supported life and the least likely to have someone reading certificate authority announcements.

Why the failures were hard to diagnose

A failed TLS handshake rarely announces itself clearly. Many integration products log a generic connection error, retry, and queue the message. The first visible symptom is often downstream: results that do not arrive, an eligibility check that times out, a dashboard that stops updating. The natural first theory is a network fault or an outage at the partner.

So the early hours tend to go on the wrong path. Network staff check firewalls. Application teams call the partner, who correctly says the service is healthy. Only when someone captures the handshake, or tests the connection from the affected machine with a diagnostic tool, does the real message appear. That message may say the certificate has expired, which sends the next person to check the partner’s certificate, which is fine.

A hypothetical regional health system shows how this unfolds. It runs an interface engine installed in 2017 that pulls insurance eligibility from a clearinghouse every few minutes. The clearinghouse uses a Let’s Encrypt certificate. On the morning after the expiry, registration staff notice that eligibility checks are timing out. They switch to phoning payers, and the queue at the front desk grows. Nothing is hacked and nothing is down. A trust list inside one piece of software cannot recognize a valid certificate.

Patients’ phones and the other direction

A health system also runs servers that other people’s clients connect to: patient portals, scheduling pages, telehealth links and APIs for partners. Here the hospital faced the server operator’s dilemma itself. A portal served with the long chain kept working for patients on old Android phones. A portal served with the short chain could fail for them. Few hospitals had data on which phones their patients used.

This side of the problem rarely produced an incident ticket. A patient whose phone refused the portal simply called the clinic or gave up. The cost showed up as access problems among patients least able to replace a device, which is a population many health systems serve heavily. Checking chain choices against patient device data, where portal analytics provide it, is a small task that protects them.

What the fixes looked like at the client

The repairs were usually small once the cause was known. Add ISRG Root X1 to the right trust store. Remove the expired IdenTrust root so the library stops choosing the dead path. Update the Java runtime or the library. Where the library could not change, ask the partner whether it could serve the short chain to that client.

The hard part was knowing which trust store was the right one. On a single server, an application might use the operating system bundle, a Java keystore inside its install directory, and a separate bundle for a scripting tool. Fixing the wrong one changes nothing. Teams that had to discover this during an outage spent most of their time on it.

The inventories that could not see them

Organizations that tracked certificates at all tracked the ones they issued: the certificates on their own websites and servers, with renewal dates in a spreadsheet or a management tool. That answers the question “when do our certificates expire.” It does not answer “which of our clients will stop trusting someone else’s certificate.” The second question depends on software versions, operating system builds and embedded libraries.

Facts in pieces

The facts usually existed, but in different places. The configuration management database, the IT department’s catalog of systems and their settings, knew a server’s operating system version. Biomedical engineering, the team that maintains clinical equipment, knew a device’s firmware level. The vendor knew which TLS library it shipped. The integration team knew which partner endpoints each interface called. Nobody held a view that joined those facts to an outside event: on this date, this root expires, and these clients will reject these services.

Without that join, months of advance notice produced little action. An email saying an important root certificate expires in September prompts a reasonable question: does that affect us? If nobody can answer in an afternoon, the email waits, and the date arrives.

What a usable record holds

Building the missing view is not exotic. For anything that initiates outbound TLS, the asset record needs a few extra attributes:

• The TLS library and its version, or the runtime that supplies it.
• Where the trust store comes from: the operating system, a bundled runtime, or a file inside the application.
• How that store gets updated, and by whom: the hospital’s patching, the vendor’s release, or nobody.
• Which external endpoints the system calls, and which certificate authorities those endpoints use.
• Whether automatic root updates are enabled, for Windows systems.

Each attribute has a natural source. Software composition data from vendors gives library versions. Integration engine configuration lists endpoints. A simple scan of partner endpoints shows which authorities sign their certificates. Group policy settings show which Windows machines fetch roots automatically.

Finding the clients nobody listed

Records only cover what someone thought to record. Network observation fills the gap. Every TLS client announces some details of itself at the start of a handshake, including the protocol versions and cipher options it supports. Security tools can fingerprint those announcements and group clients by library and version. A hospital that watches outbound traffic at its internet edge can therefore find machines speaking an old library without knowing in advance that they exist.

This works best in combination. The fingerprint says “something in the imaging network speaks an old library and connects to this vendor’s cloud.” The asset record and the biomedical team say what that something is, who owns it and whether it can change.

Where existing tools fall short

Most certificate management tools were built for the issuing side. They discover certificates on the organization’s own servers, track expiry dates and automate renewal. That is valuable, and it covers the most common outage. It does little for this one, because the certificate that failed belonged to someone else.

Vulnerability scanners have a similar blind spot. They report out-of-date operating systems and, increasingly, outdated libraries on the servers they can log into. They rarely see inside appliances or devices, and they do not ask which roots a client will accept. Configuration management databases record what someone entered, which for an appliance installed years ago may be only a name and an IP address. Closing the gap means adding a client-side view on purpose, using the attributes above, rather than assuming an existing tool provides it.

The audit trail that follows

The HIPAA Security Rule already requires covered entities and business associates to run an accurate and thorough risk analysis of risks to electronic protected health information. It also requires transmission security safeguards for that information. An auditor reviewing either one will increasingly ask a practical question: can the inventory answer a specific query about which systems transmit data, how and with what protections? A list of servers with renewal dates does not meet that test for client-side trust.

The evidence that does meet it is concrete. It is a report showing outbound clients by library version, the date the report was produced, the exceptions and their owners. It also includes a record of the last time a public trust change was checked against the inventory. A health system with that data can turn the next root change into a query instead of a war room.

The owners who had to act

For a server certificate, the owner is clear: the team that runs the server. For a client trust store, ownership is spread across four parties. The operating system vendor decides when a new root ships. The application vendor may bundle its own library and root list. The device manufacturer controls updates through its own validation process. The hospital may have pinned a version, meaning deliberately locked it in place, for stability and then lost track of why.

Who could make each fix

The fixes mapped onto those four parties. Updating an operating system bundle was the hospital’s own patching job, provided the system still received updates. Updating a bundled runtime or library usually needed the application vendor, either through a patch or through permission to change files the vendor supported. Changing a device’s trust store almost always needed the manufacturer. Changing which chain a partner served needed the partner.

Each fix needed someone with authority to make the change, and often that someone was in a vendor’s support queue. Health systems with escalation paths and named contacts at device and application vendors resolved issues in hours. Those negotiating contact details mid-incident took days. In a hospital, days of manual workarounds mean staff time, delayed results and frustrated patients, even when no data is lost.

The biomedical and IT boundary

Medical devices make ownership harder. In many hospitals, biomedical engineering or clinical engineering owns the device, while IT owns the network it sits on and the integrations it feeds. A device gateway that calls a manufacturer’s cloud falls between them. Neither team may consider its trust store theirs.

The regulatory picture is often misread here. The FDA’s 2016 guidance on postmarket management of device cybersecurity said that most changes made solely to strengthen cybersecurity do not need a new premarket review. That reduces one common objection to updating a device. It does not let the hospital change the device itself; the manufacturer still controls the software and its validation. What the guidance does is give the hospital a stronger basis to ask the manufacturer for a timely fix.

Proxies as a stopgap

For devices that could not change quickly, one option was to route their traffic through a proxy or integration layer that could. A proxy here is a go-between: the old device talks to a modern system inside the hospital, and that system makes the outside connection on its behalf. The proxy’s trust store is the one the hospital maintains.

That works for many integrations but has limits. Some devices check the identity of the system they connect to in ways a proxy disrupts. Some manufacturers will not support a device whose traffic is intercepted. Some connections rely on client certificates presented by the device, which a proxy cannot simply copy. Each case needs the manufacturer’s agreement, which is another reason to have the contact in place before the date.

What the partner owes in return

Partners carry part of the burden too. A clearinghouse, laboratory or payer that serves many hospital clients is in the best position to see a trust change coming and to warn its clients clearly. Good partners did this in 2021. They published which certificate authority they used, which chain they served, and which client versions would fail.

A hospital can ask for that behavior in its agreements. Partners can commit to notice before changing certificate authorities or chains, and to a test endpoint where clients can check compatibility in advance. They can also give a contact who understands the technical detail. These terms cost a partner little and save both sides an incident call.

What a named owner actually does

Ownership here means a handful of concrete duties. The owner of an outbound client knows its library and trust store source. They receive or check public announcements from certificate authorities and browser makers. They hold the vendor contact and know the escalation route. They run a test against the partner endpoints before a known change. And they sign off the exception when a system cannot be updated, with a compensating control such as a proxy.

These duties are small for any one system. Spread across hundreds of interfaces and thousands of devices, they need a coordinator, typically in the integration or infrastructure team, who tracks coverage and chases gaps.

What a scheduled failure costs a hospital

Nothing was breached, and most of the internet carried on. Even so, the episode touched several things boards and executives care about.

Operations and patient flow. Integrations are the plumbing of a modern hospital. When eligibility checks, lab results or pharmacy messages stop, staff fall back on phones and faxes. The cost shows up as overtime, delays and errors introduced by manual re-entry. Each re-keyed result is a chance for a transcription mistake.

Clinical risk. Devices that phone home for updates or remote support lose that support without any alarm. A device that cannot reach its manufacturer may keep working locally, but it is now running without the safety net the hospital assumed it had. The first sign may be a support call that fails months later.

Vendor dependency. The episode exposed how much control over basic security plumbing rests with suppliers. If a hospital cannot change what its own systems trust without opening a vendor ticket, it has a dependency that belongs on the risk register.

Reputation and partners. When a feed fails, the first call often goes to the partner, who is not at fault. Repeatedly blaming suppliers for problems inside your own walls wears down relationships and slows the next genuine escalation. Saying quickly “this one is ours, and here is the fix” builds credibility.

Predictability. This failure was scheduled. The date was public months ahead. An organization that cannot act on a dated, public warning will struggle far more with surprises.

How the cost differs by organization

The cost lands differently across a health system. In a large hospital, the main cost is staff time across many departments, spread thinly enough that nobody totals it. In a reference laboratory or imaging center, a failed results feed has a direct revenue and turnaround impact. In an ambulatory network, the cost often falls on front-desk staff working around failed eligibility or scheduling connections. For a health system’s own patient-facing apps, a failure on old phones becomes a patient access problem rather than an internal one.

Business associates carry their own share. A billing company or clearinghouse whose clients’ integrations fail will field the support calls even when its certificates are fine. Its incentive is to publish clear guidance to clients ahead of a known change, and many did.

The case for treating it as minor

The strongest counter-argument is that this was a small event. Most systems kept working. Let’s Encrypt planned carefully and communicated early. The failures were mostly fixed within days. A hospital with limited security budget might reasonably spend it on ransomware defenses instead of certificate trivia.

Much of that is correct. The root expiry itself was a modest incident, and it would be a poor use of money to build a large program around one date. The argument for acting rests elsewhere. The inventory that answers “which clients embed an old TLS library” is the same inventory that answers “which systems embed a vulnerable component” in any software emergency. It costs little to add those attributes once. The question it answers recurs every time a widely used component turns out to be flawed.

A second objection is that validated clinical devices cannot be changed, so knowing about their trust stores achieves little. Knowing still matters. It tells the hospital which devices need a proxy, which need a manufacturer fix, and which manufacturers to press in the next contract. Doing nothing because the device is locked leaves the hospital learning about the problem from a failed support call.

Moving trust decisions back in-house

The durable response is contractual and architectural at once. The aim is to shift trust decisions from dozens of frozen images to a few systems the hospital controls, and to make suppliers answerable for the rest.

Procurement and contracts

Procurement can ask, before purchase, how a product updates embedded roots and how fast it can ship a trust store change outside a full release. Many hospitals already ask device manufacturers for the Manufacturer Disclosure Statement for Medical Device Security, the standard MDS2 form. Its answers on patching and third-party components are a natural place to add a question about trust store updates. Contracts can then set a service level for root changes, distinct from feature releases, and require notice when the vendor learns of an upcoming change that affects the product.

The trade-off is negotiating effort and, sometimes, price. Large health systems have bargaining power with major vendors; small hospitals and clinics usually do not. Group purchasing organizations and shared contract language can narrow that gap.

Architecture: fewer doors, better kept

Integration teams can keep long-lived clients behind a small number of central brokers whose trust stores the hospital maintains. A broker is a hub that handles outside connections on behalf of many internal systems. An interface engine often plays this role already for clinical messages. Extending it to cover API calls, file transfers and device telemetry means one place to update roots, monitor handshake failures and test against partner endpoints.

The trade-off is concentration. A misconfigured broker breaks many feeds at once, so it needs change control, redundancy and monitoring to match. Putting all outbound traffic through one door makes the door easier to maintain, but it also makes it a single point of failure, and it deserves the care given to any critical system.

Monitoring that names the cause

Monitoring should catch a trust failure before staff do. Synthetic checks can test each critical partner endpoint from the actual client environment, not from a modern laptop, every few minutes. Interface engines can alert on queue growth and on handshake errors specifically, rather than on generic connection failures. The goal is that the first alert says “certificate validation failed on this client,” which saves the hours otherwise spent on firewalls and partner calls.

Who pays and who staffs it

The work needs a home in the budget. In most health systems, the natural owner is the integration or infrastructure team, with biomedical engineering responsible for device records and procurement responsible for contract terms. The effort is mostly people time: a few weeks to enrich records for critical integrations, then a few hours each quarter to review exceptions and test against announced changes.

Smaller organizations can buy rather than build. Managed service providers and integration vendors can take on the monitoring and the trust store maintenance, provided the contract says so explicitly. The risk is assuming a provider covers client trust stores when its contract only mentions server certificates.

A sequence for the first ninety days

A health system starting from scratch can work in a sensible order. First, list the ten to twenty integrations whose failure would stop patient care or revenue, and record their trust store details. Second, scan outbound traffic to find clients the list missed. Third, name an owner and a vendor contact for each. Fourth, put the longest-lived clients behind the broker where feasible. Fifth, assign someone to read certificate authority and browser announcements and run them against the inventory.

The metrics are simple. Count the share of outbound clients with a known trust store source. Track the share of critical integrations with a named owner and vendor contact. Record the time taken to answer “which systems are affected” for the most recent public trust change. Each one trends in a direction a board can follow.

Testing the outbound connections

These questions do not require technical knowledge to ask, and the quality of the answers will tell a leader a good deal.

• Which of our systems reach out to connect to partners, payers, manufacturers or cloud services, and do we have a list?
• For our ten most important outbound connections, who would change what that system trusts, and how long would it take?
• Which of our devices and appliances carry their own built-in trust lists that our normal updates do not touch?
• When a certificate authority or browser maker announces a change, who reads it, and how do they decide whether it affects us?
• Do our purchasing contracts require vendors to update trusted roots on a defined timeline, separate from full product releases?

If the answers are names and days, the next trust change will be routine. If the answers are “the vendor, probably,” the health system has a dependency it does not manage. The work is unglamorous, but the 2021 root expiry showed that a hospital’s ability to keep information flowing can depend on a list inside a device that nobody remembered was there.

With hindsight

September 2021 turned out to be an early rehearsal for a run of trust changes, and for a broader question about what organizations know of the software inside their systems.

The first test came within weeks. In December 2021, the Log4Shell vulnerability in the widely used Log4j logging library set off an emergency search across every industry. The question health systems faced was the same shape as the root expiry: which of our systems, including vendor products and devices, embed this component? Organizations that had begun recording libraries and versions after September could answer faster. Those relying on vendor statements waited for each supplier to reply.

Device regulation moved in the same direction. In December 2022, Congress added section 524B to the Federal Food, Drug, and Cosmetic Act, which took effect in March 2023. It requires manufacturers of connected “cyber devices” to include a software bill of materials in premarket submissions, along with plans to monitor and address vulnerabilities. The FDA finalized premarket cybersecurity guidance in September 2023 and updated it in June 2025. A software bill of materials lists the components inside a product, including its TLS library. For new devices, the facts that were missing in 2021 now have to exist. The installed base of older devices is a different matter, and much of it will remain in service for years.

Let’s Encrypt’s own compatibility arrangement also ran its course. It stopped serving the long chain by default in February 2024 and stopped offering it entirely in June 2024. The cross-signature that had kept old Android phones working expired on September 30, 2024. That second step drew far less attention than the first, partly because the remaining affected devices were very old by then.

Then came a reminder that trust stores change for reasons other than expiry. In June 2024, Google announced that Chrome would stop trusting new certificates from Entrust, a long-established certificate authority, issued after October 31, 2024. Customers using Entrust had to replace certificates on a deadline they did not choose. Browser root programs also adopted policies limiting how long a root stays trusted, around fifteen years from key creation in the case of Chrome and Mozilla. Root changes are now a routine feature of the system rather than a rare event.

In April 2025, the CA/Browser Forum, the industry body where certificate authorities and browser makers agree the rules, approved a schedule that shortens the maximum lifetime of public TLS certificates in steps. It starts at 200 days in March 2026 and reaches 47 days by March 2029. In December 2025, Let’s Encrypt announced its own path from 90-day to 45-day certificates by 2028. A certificate that once might have been renewed once a year will need renewing every few weeks.

Shorter lifetimes make manual renewal impractical and push every organization toward automated certificate management, meaning software that requests, installs and renews certificates without a person in the loop. That is a sensible direction for security, because a stolen or mis-issued certificate is useful to an attacker for a shorter time. But it raises the stakes on the same weakness that 2021 exposed.

On the health care side, HHS proposed a revision of the HIPAA Security Rule in January 2025. It would require a written technology asset inventory and a network map showing how electronic protected health information moves. Its final form and timing were still unsettled in 2026. Whatever happens to it, the proposal shows where examiner expectations point.

What held up from 2021 is the core diagnosis. The clients that could not follow the root change are often the ones that struggle with automation now. Their trust stores and renewal processes are still fixed at build time. A device whose trust list cannot be updated without a vendor release is unlikely to handle certificates that change every few weeks gracefully either.

What did not hold up as well is the idea that the problem was mainly about clients. With lifetimes shrinking, the server side has become just as demanding. Hospitals now need automation for the certificates they issue, on internal systems and devices as well as public websites. The organizations in the best position recorded both what their clients trust and what their servers present. Certificate management has moved from an occasional chore to a continuous operational process, with an owner, a budget line and a place in vendor contracts.