Agency certificates now expire faster than agency budgets turn over

The week

On October 1, 2026, the first website certificates issued for the full term under a new 200-day cap ran out. Every time a browser shows the small padlock beside a web address, one of these digital certificates is at work. A TLS certificate proves to your browser that the site really belongs to, say, a federal agency and not an impostor, and it lets the two sides talk in encrypted form so nobody in between can read the conversation. It carries an expiry date, and when it lapses, browsers show visitors a stark warning, or refuse to connect at all.

Certificates are issued by companies called certificate authorities, and the rules they follow are set by the CA/Browser Forum, a body where the certificate authorities and the makers of web browsers agree on how publicly trusted certificates should work. In April 2025 the Forum approved ballot SC-081, which cuts the maximum lifetime of a certificate in steps.

The schedule is simple to state and demanding to live with. Certificates issued from March 15, 2026 may last no more than 200 days, down from 398. The cap falls to 100 days for certificates issued from March 15, 2027, and to 47 days for those issued from March 15, 2029. A related clock shrinks alongside it: the period during which a certificate authority may reuse its earlier check that an organization really controls a domain name, known as domain validation, falls to 10 days by 2029.

Then the calendar bit. A certificate issued on March 15, 2026 for the full 200 days expires on October 1, 2026. That is also the first day of the federal fiscal year, the date on which budgets turn over and contracts often renew. So in the last full week of September, the first wave of full-term certificates under the new cap was coming due at exactly the moment agencies were closing one financial year and opening the next.

There was one piece of good fortune. Congress had passed a stopgap funding bill earlier in the month, so no lapse in appropriations, the formal term for a government shutdown, loomed this time. Staff would be at their desks. But the coincidence exposed a deeper mismatch. For years, agencies had handled certificates on an annual rhythm: buy once a year, renew once a year, put the date on the calendar. A 200-day certificate no longer fits inside that rhythm, and the 100-day and 47-day certificates that follow will fit even less.

The change that matters here is cadence. How often a task recurs shapes how an organization buys for it, staffs it and schedules it. Change the frequency enough and the old arrangements stop working, usually before anyone has noticed.

For most of the past decade, a public certificate lasted about a year. Agencies bought it once a year, renewed it once a year and put it on an annual calendar. Many still do. A 200-day certificate cannot live inside that rhythm, and a 100-day one will need about four renewals a year. The annual model breaks in three places that do not overlap: how certificates are purchased, who does the renewals, and when renewals fall. Fixing one without the others only moves the failure.

What a certificate is, and why it expires

Start with the basics, because the jargon hides a simple idea. When someone visits an agency website to renew a license, pay a fee or check a benefit claim, their browser needs to answer two questions before it shows anything. First, is this really the agency's site? Second, can we talk privately? A TLS certificate answers both. TLS, short for Transport Layer Security, is the standard way web traffic is encrypted. The certificate is the document that ties a web address, such as a portal on an agency's domain, to a cryptographic key that only the genuine operator holds.

A certificate works much like a building pass with a photo and an expiry date, issued by a trusted security desk. The certificate authority is the security desk. It checks that the organization asking for a pass really controls the domain, then signs the pass. Browsers carry a built-in list of security desks they trust, which is why a visitor never has to think about any of this when it works.

Why make the passes expire at all, let alone faster? Because the longer a pass is valid, the longer a stolen or wrongly issued one can be abused, and the longer it takes for the whole system to adopt better rules. Shorter lifetimes limit the damage from mistakes and force organizations to keep their processes in working order. The trade-off is that renewal stops being an annual chore and becomes a routine operation.

Two more terms matter for what follows. Domain validation is the check the certificate authority performs to confirm that the requester controls the domain, often by asking for a specific record to be placed in the domain's DNS, the internet's address book. ACME, the Automatic Certificate Management Environment, is an open protocol that lets software request, prove and install certificates without a person filling in forms, so that an approved machine can collect fresh passes on schedule.

Purchasing: buy capacity, not certificates

Many agencies buy public certificates one at a time. A program office raises a purchase order, a contractor installs the certificate and the order closes. Under a 200-day cap, that cycle runs twice a year for every certificate, and procurement lead times can exceed the margin before expiry. The cycle also ties each renewal to a funding action, which is fragile around the turn of a fiscal year.

Say a county runs a property tax portal, a court records search and a parks reservation site, each with its own certificate bought on its own purchase order by a different department. Under the old annual model, each department remembered once a year, more or less. Now each needs two orders a year, soon about four. If any one of those orders stalls in approvals at year-end, the certificate expires while the paperwork waits, and residents meet a browser warning instead of their tax bill.

The alternative is to buy capacity, not certificates. Most commercial certificate authorities sell multi-year subscriptions under which certificates are reissued as often as needed within the term. Paired with automated issuance through the ACME protocol, an agency can tie issuance to an organizational account instead of individual orders. ACME's external account binding feature makes that link explicit and auditable: each automated request is tied back to the agency's paid account, so finance and security teams can see who obtained what, and when. A department-wide agreement, bought through existing government-wide vehicles where possible, turns many small purchases into one managed service.

Free certificate authorities remain an option for some public sites. Let's Encrypt, for instance, has announced that its default lifetime will fall to 45 days by 2028, so the same automation is required either way. Choosing a free provider does not remove the need for machinery that renews reliably; it simply moves the cost from licenses to operations.

Vendor-hosted services on agency domains need their own terms. Many citizen-facing portals, payment pages and case management systems run on a vendor's infrastructure under an agency hostname. The contract should say who holds the certificate, that renewal is automated, how much notice the agency gets before expiry, and what service credit applies if a lapse takes the service down. Without that, the agency carries the public failure for a task it does not control. A resident who cannot pay a parking fine does not care whose server it was; the agency's name is on the address bar. Renewal of the contract itself is the obvious moment to add the clause.

Domain validation needs the same treatment. As reuse periods shrink, someone must prove control of each domain far more often. Delegating a validation record in DNS to the certificate service lets that proof happen automatically, without a ticket to the DNS team each time. The agency gives the certificate service permission to answer one narrow question on its behalf, rather than routing every renewal through a human request queue.

People: from memory and goodwill to named ownership

An annual task can survive on memory and goodwill. One engineer knows that the benefits portal renews in June, and a sticky note does the rest. A task that recurs every few months for hundreds of certificates cannot. Each certificate needs a named owner, recorded alongside where it is installed and how it renews. Ownership should sit with a team, so that it survives staff turnover, contractor transitions and reorganizations. If the only person who knew about a certificate retired last spring, the certificate is, in practice, unowned.

For most agencies the workable model is a small central certificate service with distributed application owners. The central team runs the accounts, the automation, monitoring and the inventory. It can find certificates it did not know about by drawing on certificate transparency logs, public records in which certificate authorities list every publicly trusted certificate they issue. Searching those logs for the agency's domains surfaces the forgotten ones. Application owners remain responsible for their own endpoints, so the central team is not expected to understand every system, only to make renewal easy and visible.

Automation credentials need protection and separation of duties, because anyone holding them can obtain certificates for agency domains. The key that lets a machine collect fresh passes is itself a valuable thing to steal. It belongs in the same category as administrator passwords: stored securely, limited to the systems that need it, and reviewed when people change roles.

Three measures keep the model honest:

• The share of public certificates renewed automatically shows progress.
• The count of certificates within 14 days of expiry without a successor shows risk.
• The count of certificates with no named owner shows governance gaps.

All three should reach the CIO monthly, rather than only when something breaks. They are simple enough to read in a minute and specific enough to act on. State IT agencies can offer the same service to counties and cities that lack the staff to run one, which spreads the cost of a small expert team across many governments that would each struggle to hire it alone.

The calendar: why renewal dates start to wander

Annual renewals tended to cluster in predictable months and could be scheduled around them. Shorter lifetimes make renewal dates drift. A manual renewal every 200 days will, over a few cycles, land on holidays, the fiscal year-end and any lapse in appropriations.

This is not a theoretical worry. During the 2018 to 2019 shutdown, Netcraft reported that more than 80 certificates used by .gov sites had expired without renewal. Some of those sites were on browsers' HSTS preload lists, which made them unreachable. HSTS, or HTTP Strict Transport Security, is a setting that tells browsers never to connect to a site without a valid certificate. The preload list builds that instruction into the browser itself. It is an excellent security protection in normal times, because it stops attackers from downgrading a connection. But it also means a visitor cannot click past the warning. When the certificate lapses, the site simply goes dark.

Automation largely removes the calendar problem, provided it keeps running when people are away. Renewal should start well before expiry, typically about two-thirds of the way through a certificate's life. For a 200-day certificate, that means renewing at roughly day 133, leaving weeks of margin to notice and fix a failure. Certificate authorities that support ACME Renewal Information can also signal when a certificate should be renewed early, for example before a mass revocation, when a certificate authority has to withdraw many certificates at once.

Some systems cannot automate, such as older appliances and some vendor-hosted services. These should be fronted by a load balancer or proxy that can, replaced, or moved to a private certificate authority if only internal users reach them. A load balancer or proxy is a piece of equipment or software that sits in front of a system and handles incoming connections for it; if it holds the certificate and renews automatically, the old system behind it no longer needs to. A private certificate authority is one the agency runs for itself, trusted only by its own devices, and not bound by the public lifetime caps.

Finally, agencies should list certificate renewal among the activities that continue during a lapse in appropriations, and confirm the classification with counsel. If renewal is automated, very little human work is needed, but someone still has to be allowed to respond when the automation fails.

What a lapsed certificate costs

Certificates are plumbing, and in a well-run organization they should be invisible. But the consequences of failure are not technical. An expired certificate on a payment page stops revenue. On a benefits portal it stops people getting help and sends them to call centers that are already busy. On a site that handles personal information, it can prompt questions from inspectors general and oversight committees about basic operational control. And because the address bar carries the agency's name, the reputational cost lands on the agency even when a vendor caused the lapse.

The shift to shorter lifetimes also changes the economics. Under an annual model, the hidden cost of manual renewal was tolerable: a few hours per certificate per year. At four renewals a year, and later more, the same manual process multiplies its cost and its chances of error. Automation has an upfront cost in setup and contracts, but its running cost barely changes as lifetimes fall. That is the core business case, and it is the kind of argument a budget office understands.

There is a workforce angle too. Repetitive, deadline-driven tasks that depend on one person's memory are a retention and continuity risk. Moving them into a small, well-documented central service frees skilled staff for work that matters more and makes contractor transitions less dangerous.

A well-run agency can list every certificate, its owner and its renewal method

A well-run agency at this point would be able to answer, in one page, how many public certificates it has, who owns each one, how each renews and which ones cannot yet renew automatically. It would hold one or a few multi-year issuance agreements rather than dozens of single orders. Its vendor contracts would name certificate responsibilities explicitly. Its CIO would see the three monthly measures and would know which systems remain to be fronted, replaced or moved before the 100-day step.

The ways it goes wrong are predictable:

• Automating renewal but not discovery. The inventory only covers what someone remembered. Certificate transparency logs exist to close exactly this gap.
• Fixing purchasing but not ownership. A subscription that nobody monitors simply produces certificates that nobody installs.
• Treating vendors as out of scope. Citizen-facing services on agency hostnames are the agency's problem in the public's eyes, whatever the contract says.
• Leaving the hard cases for later. The old appliance that cannot automate is the one most likely to fail, and the 100-day cap leaves less room each year.
• Counting on the calendar. The October 1 coincidence will not be the last time a renewal lands on an awkward date.

What the CIO should be able to see

1. How many publicly trusted certificates do we have on our domains, and how did we find them?
2. What share renew automatically today, and what is the plan for the rest before March 15, 2027?
3. Which of our citizen-facing services run on vendor infrastructure under our name, and what do those contracts say about renewal, notice and service credits?
4. Who owns each certificate, by team, and what happens to that ownership when a contractor changes?
5. Is certificate renewal listed among activities that continue during a lapse in appropriations, and has counsel confirmed that?

Two follow-ups belong with them: who holds the automation credentials and how they are protected, and whether the three monthly measures already reach the CIO, or would have to be assembled by hand when asked. These questions need no technical background to ask, and the answers will reveal quickly whether the organization is running certificates as a managed service or still relying on memory and goodwill. With lifetimes set to fall twice more, that difference will matter more each year.

With hindsight

The first full-term 200-day certificates have expired and been replaced. We have found no public reports of a widespread agency outage tied to them, though individual expiries rarely make the news. A lapsed certificate on a small program site can cause real frustration for the people trying to use it without ever becoming a headline, so the absence of reports is encouraging rather than conclusive.

The schedule has not changed. Certificates issued before March 15, 2027 may still run up to 200 days, so the renewals made around October 1 run to about mid-April 2027. Only certificates issued from March 15, 2027 are capped at 100 days, and the 47-day cap starts on March 15, 2029. That leaves agencies one more 200-day cycle to finish their preparations before the pace doubles.

Congress has funded the government through December 11, so the next appropriations deadline falls inside this second 200-day cycle, months before the first 100-day certificate is issued. That makes the shutdown question practical rather than hypothetical: if funding lapses, any certificate that depends on a person to renew it is exposed, while those renewed automatically should carry on.

Let's Encrypt began offering 45-day certificates as an option in May 2026 and will move its default to 64 days in February 2027 and 45 days in 2028. Even agencies that rely on free certificates for some public sites will therefore see the pace quicken on a timetable of their provider's choosing.

The procurement point has held up. Agencies that bought issuance capacity rather than individual certificates have the most room for the next two steps. The expensive part of this change is organizational rather than technical: contracts, ownership and calendars. Those take months to adjust, so the months before March 15, 2027 are the time to do it. Organizations should confirm the schedule with their certificate authorities, since products and profiles vary.