The tool that diagnoses outages had an outage
On Monday, June 15, 2026, IT administrators around the world opened connectivity.office.com and were met by the one message they spend their careers trying to prevent: "Your connection is not private."
That site is Microsoft's own Microsoft 365 Network Connectivity Test, the tool admins use to check whether a firewall, proxy, or network appliance is interfering with traffic to Exchange Online, SharePoint, and Teams. It's where you go when Microsoft 365 is misbehaving and you need to prove the problem is (or isn't) your network.
On that Monday, the tool you use to diagnose connectivity problems had a connectivity problem of its own. Its TLS certificate had expired.
What happened
The certificate for connectivity.office.com expired on Sunday, June 14, 2026. It had been issued by Microsoft's own Azure RSA TLS Issuing CA 07 and last renewed on December 16, 2025, on a roughly six-month validity window. Nobody renewed it in time.
By Monday morning, Edge, Chrome, and Firefox were all refusing to load the page. Not a soft warning, a hard block. Admins who relied on the tool couldn't run their tests without clicking through a browser security warning, which most enterprise security policies (correctly) forbid.
The workarounds were the usual scramble: nslookup and tcpping from a terminal, or the network assessment tool built into the Microsoft 365 admin center, which kept working. Help desk queues filled with tickets from admins who didn't know the root cause and assumed they had broken something.
Nothing was breached. No data was lost. It was just a certificate that expired because a date slipped by, the most mundane and most common outage there is.
The part that stings
There are two layers of irony here, and both are worth sitting with.
First: the tool that broke exists to diagnose exactly this class of problem. When the thing that's supposed to tell you why Microsoft 365 traffic is failing is itself failing, because of an expired cert, you've reached a very specific kind of operational embarrassment. We've written before about a Splunk license lapsing at a federal agency: the monitoring platform that watches everything, taken down because nobody watched its own expiry date. Same shape, different logo.
Second, and sharper: at the very moment connectivity.office.com went dark, Microsoft was actively urging its customers to renew their aging 2011-era Secure Boot certificates ahead of their expiry window between June and October 2026. The company telling everyone else to mind their certificate deadlines missed one of its own.
This isn't a knock on Microsoft's engineers. It's the whole point. If an organization with effectively unlimited infrastructure budget, dedicated PKI teams, and a reputation staked on certificate hygiene can let a six-month cert lapse, then the failure mode isn't competence. It's visibility.
Why it keeps happening, even here
The pattern is identical to every other expiry outage we've cataloged, Google's Bazel, IPinfo, Epic Games, and Microsoft Teams among them (we collected several here):
- The certificate generated no signal. A valid cert is invisible. It works silently for six months and gives you exactly one alert: the moment it stops working.
- The renewal wasn't watched. The issue is never "was there automation." It's whether anyone was alerted before the deadline instead of after the browser started blocking traffic.
Why this gets more common, not less
Here's the uncomfortable timing. As of March 15, 2026, the maximum lifespan of a public TLS certificate dropped from 398 days to 200, on the way to 100 in 2027 and 47 in 2029. Every public cert you manage now expires more than twice as often as it did a year ago, and the first wave of those 200-day certs starts coming due in early October 2026. (Here's what that shift means for your team.)
A six-month certificate lapsed at Microsoft. The industry is about to run on certificates that don't last much longer than that, renewed several times a year, across every endpoint you own. The margin for "someone will remember" is shrinking fast.
What to actually do
Nothing below is novel, but the connectivity.office.com outage is a clean reminder of the fundamentals:
- Inventory every public endpoint, including the subdomains and diagnostic tools nobody thinks of as "production."
- Assign an explicit owner and backup to each certificate. "The platform team has it" is how this exact outage happens.
- Alert before expiry, not after. Multiple reminders (30, 14, 7, and 1 day out) beat a single calendar entry that gets snoozed. And if you rely on auto-renewal, monitor the renewal itself. Silent auto-renewal failure is its own well-worn outage story.
A certificate expiring like this isn't catastrophic on the usual ledgers. No data lost, no revenue gone, no customers churned. But there's one more index, and on the embarrassment index it's priceless and trivial to get right.
ExpiryPulse tracks credential and certificate expiry for individuals and IT teams: one dashboard, automated alerts at 30, 14, 7, and 1 day before expiration, and primary/backup owners so nothing falls through a gap. Free tier at expirypulse.dev.
Related: The Credential Nobody Owned — why expired certificates still take down billion-dollar companies. And 47-Day SSL Certificates Are Coming. Is Your Team Ready? — why outages like this are about to get more frequent.
Top comments (0)