Everything in Your Stack That Expires — and Which Half Renews Itself

At 6:12 a.m. on a Tuesday, the job that pushes field timecards from a 55-person marine contractor's job-costing app into their accounting system failed with a single line about an invalid client secret. The secret had been created twenty-four months earlier — almost to the hour — by an integrator who finished the project, invoiced it, and moved on. Nobody wrote the date down anywhere. The controller found it at 8:35, when the payroll register came up eleven hours short of what the crews had actually worked, and then spent two days deciding whether to trust any of the numbers. The fix took four minutes once someone knew where to look. Finding that someone took most of a week.

The interesting part is not that a secret expired. Secrets are supposed to expire. It is that the expiration stayed invisible until it produced a wrong number in a payroll run — and that nowhere in that company was there a page listing the thirty-odd other objects that also carry a date.

That page does not exist in most companies. Not because it is hard to write, but because nobody sells it.

Why this list has never been assembled in one place

Search for any individual item on it and you will find good, detailed material. Certificate authorities write thoroughly about TLS lifetimes. Microsoft documents app registration credentials well. Apple's push certificate renewal is covered in a dozen places. Each of those pages was written by the vendor whose product solves that one problem, and none has reason to mention the other nine.

None of this is a knock on the vendors — their documentation is usually accurate and often better than an independent writer would produce. It is a structural gap rather than a quality one. The inventory only becomes visible from the position of the person who has to answer for all of it, and that person is usually an office manager or a one-person IT lead who has never been handed a template.

So here is the inventory, and the thing that comes with it: these objects split into two groups, and the split determines how much of your year they consume.

The clock everybody is watching right now

Public TLS certificate lifetimes are on a published, ratified reduction schedule. The CA/Browser Forum passed Ballot SC-081v3 in April 2025:

• Since 15 March 2026, the maximum is 200 days. Already in force. Certificates issued before that date run to their original expiry, which is why plenty of environments have not felt it yet.
• From 15 March 2027, the maximum drops to 100 days.
• From 15 March 2029, the maximum is 47 days — and the window in which domain-control validation may be reused falls to 10 days.

That last pair is what gets skimmed. A 47-day certificate is tedious to renew by hand, roughly eight times a year per certificate. The 10-day validation reuse window is what makes manual renewal impractical, because you are no longer reissuing against a validation you performed months ago. You are re-proving control of the domain nearly every time.

Worth knowing in practice: several authorities issue one day under the cap rather than at it. DigiCert moved to a 199-day maximum on 24 February 2026 specifically to avoid brushing the ceiling, and GlobalSign does the same. Build your calendar around 199, then add headroom on top.

The honest answer to "what do I need to do about 47-day certificates" is: nothing urgent this quarter, and one structural thing this year. That thing is finding out which of your certificates can be automated and which cannot — because the ones that cannot are the ones still sitting there in 2029, needing a human eight times a year each.

Renewal reminders were load-bearing, and one of them is gone

For about a decade, the renewal process at most small companies was that the certificate authority emailed you and you acted on it. It was never a system, but it functioned like one.

Let's Encrypt ended its expiration notification email service on 4 June 2025. The reasoning was sound — most subscribers had working automation, keeping millions of email addresses tied to issuance records conflicted with their privacy position, and the service cost tens of thousands of dollars a year to run. They also deleted the stored addresses and stopped retaining contact information supplied through the ACME API.

That is a defensible decision and it does not deserve criticism. It does deserve a response. If any part of your renewal process depended on a Let's Encrypt email arriving, that part no longer exists, and it stopped existing over a year ago. Third-party monitoring fills the gap — but somebody has to notice the gap first.

The half that renews itself

ACME — the protocol behind Let's Encrypt, now supported by several commercial authorities — is the dividing line. Anything that speaks ACME, or sits behind something that does, is on the self-renewing side of your fleet:

• Public web servers and reverse proxies. A properly configured ACME client on nginx, Apache, Caddy, IIS through a third-party client, or a load balancer renews with nobody touching it. This is the largest category in most environments and it is genuinely solved.
• Platform-managed certificates. Certificates issued and rotated by a cloud load balancer, CDN, or hosted service are the platform's problem. You need to know they exist; you do not need to diary them.
• Firewalls and appliances on recent firmware. FortiOS added native ACME support in the 7.0 release, and several other appliance vendors have followed. If your edge device is on current code, its management and VPN portal certificates can renew themselves.

That last bullet carries a warning inside it. Native ACME arrived in specific firmware versions, so the same appliance model can sit on either side of the split depending on when it was last updated. A five-year-old FortiGate on 6.x is a manual-renewal device. The identical unit on 7.x is not. You cannot answer the question from the model number.

The half that needs a human, every cycle

Everything below has a date, and none of it renews itself. This is the list worth writing down.

• Domain registrations, and the card behind the auto-renew. Auto-renew is not protection if the payment method attached to it expired eighteen months ago. Corporate cards get reissued on their own schedule, and registrars are inconsistent about how loudly they complain. The failure stays quiet until the domain lapses and your mail stops.
• The Apple MDM push certificate. Valid for 365 days, with a 30-day grace period after expiry. It must be renewed using the same Apple account that created it — not a different admin's Apple ID, not a fresh one. If it fully lapses, every enrolled iOS and iPadOS device loses management and has to be re-enrolled by hand. For forty iPads across job sites, that is not a renewal task, it is a project. It is the highest-consequence annual item in most small environments, and it is frequently tied to a personal Apple ID belonging to someone who no longer works there.
• Entra ID app registration client secrets. The portal caps secret lifetime at 24 months, and the Graph API defaults to two years if you do not specify an end date. Every integration authenticating with a secret — accounting connectors, backup tooling, custom scripts, line-of-business apps — has one. Microsoft's own guidance is to use certificates, federated credentials, or managed identity where the application supports it, which removes the item from your calendar rather than dating it.
• SAML and AD FS token-signing certificates. Self-signed AD FS token-signing certificates default to roughly a year. Automatic rollover handles generation, but relying parties that cannot consume federation metadata need the new public key sent by hand, and Microsoft's guidance is to give partners at least 60 days' notice. Third-party SAML applications frequently fall into that manual category, and they fail as a total loss of sign-in, all at once.
• The RADIUS or NPS server certificate behind 802.1X Wi-Fi. The worst failure characteristics on the list. When it expires, clients configured to validate the server certificate refuse to authenticate — correctly, because that validation is the entire point of the setting. Nothing breaks in a way that looks like a certificate problem. It looks like the Wi-Fi stopped for everyone at once, and the people who can fix it may be unable to get on the network to do it.
• Code-signing certificates. If you ship signed software or internal tooling, note that since 1 June 2023 the private key must live on hardware certified to FIPS 140-2 Level 2, Common Criteria EAL 4+, or equivalent. Renewal is no longer a file you download — it involves a token or an HSM, and the lead time is longer than people plan for.
• DKIM keys. Microsoft 365 does not rotate DKIM keys for custom domains automatically — an administrator does it, through the Defender portal or with Rotate-DkimSigningConfig. No expiry will bite you, which is exactly why keys sit untouched for years at 1024 bits. Before you schedule one: after a rotation it takes about four days for the new private key to start signing.
• RMM and backup agent certificates. Usually invisible, because the vendor handles them. When they fail, the symptom is agents going grey in a console, which reads as a connectivity problem rather than a trust problem. Ask your tooling vendor what expires and what the failure looks like.

What the register looks like

One page. One row per object. Five columns, and the fourth does the real work.

What it is — the specific object, not the category. Not "SSL certificates" but "wildcard certificate on the reverse proxy."

Where it lives — the device, tenant, or portal, with the console URL.

When it expires — the actual date, not the interval.

How it renews — the name of the automation, or the name of a role. Never "automatic" without saying what does the automating.

Who owns it — a role, not an individual. "Controller" survives turnover. "Dave" does not.

Writing "ACME via Certbot on web01" in one row and "manual, Apple Push Certificates Portal, admin Apple ID" in the row beneath puts both halves of your fleet on one page for the first time. Everything with a human role in that column is recurring work, and the total is usually smaller than people fear and larger than they guessed — eight to fifteen items in a thirty-to-eighty-person shop.

The register also answers the question that started this. When a secret expires twenty-four months after an integrator created it, the useful question was never "how do we fix this." It was "who knew this existed." A row on a page answers that in advance, and it costs nothing to produce.