Six Systems Fell Together: The Single Point of Failure You Cannot See

Six Systems Fell Together: The Single Point of Failure You Cannot See

On the evening of 31 August 2026 a broad outage began across Microsoft 365, logged in the admin centre as EX1464935 and later widened under MO1465074. The impact was not limited to email. Exchange Online went down alongside Teams, SharePoint Online and OneDrive for Business, and with them the governance and security tooling in Purview and Defender XDR. A company that reached its customers by email, coordinated internally by chat, kept its files in the cloud and watched its security from a dashboard lost all four in the same moment.

Microsoft described the cause as an issue with core authentication configuration used by multiple internal services within the Exchange Online infrastructure, and applied a staged mitigation that re-applied authentication components across a sample of the infrastructure before expanding it. Mail flow and search were restored on 1 September, with a limited impact on a small subset of users persisting into 2 September. The full interruption ran past a day, and the tail ran two.

This is not an article about Microsoft. Every large provider has outages, and we have covered interruptions at other AI services before. It is an article about the thing this particular outage exposed, which is more dangerous than it first looks.

What you count as six systems may be one

Ask any manager to list their systems and you get a list: a mail system, a chat system, a file system, a security system. Four names, four icons, usually four lines on the contract. The natural assumption is that one going down does not take the others with it, because they are different things.

But names are not system boundaries. The real boundary is what those services share underneath: who verifies your identity, where sessions are held, which network they traverse. When four services share one authentication layer, then from a risk point of view they are one service, however separate they look on the invoice.

The awkward part is that this sharing never shows up in normal times. Quite the opposite, it is exactly what gives you convenient single sign-on and smooth integration between mail and files. You buy the convenience daily and pay for it once every few years, in one long day.

This applies to a mid-sized Saudi company as much as to a global enterprise. Consider how many of your services hang off one Google account, or one WhatsApp number, or one hosting provider, or one employee who holds the passwords. Each of those is a single point of failure. The difference is that yours are smaller and far easier to fix.

Map your dependencies in one hour

You need no tool and no consultant. You need a sheet of paper, an hour, and honest answers. In the first column write every operation your business cannot go a full day without: taking orders, issuing invoices, answering customers, running payroll, delivering the service. Then ask three questions of each:

• Which external service does this operation depend on? Write the commercial name plainly: this mail provider, that storefront platform, that payment gateway, that messaging provider.
• Which account or identity do you sign in with? This is usually where the surprise appears. You will find four different services entered through one account, or three services tied to one mobile number for verification codes.
• If this stopped right now, what is the alternative within an hour? If the answer is none, you have found a real single point of failure rather than a theoretical one.

When you finish, one or two entries will repeat across most rows. Those are your shared dependencies. Do not try to remove all of them, which is neither realistic nor economic. Take the row that stops revenue, and deal with that one first.

The most preventable class of outage: expiry dates

Not all outages are equal. Some come from complexity you do not control. Others come from a date written somewhere nobody reads. The second kind is the easiest to prevent and the most frequently repeated, because all it needs is follow-up.

These are the expiry dates quietly running your business, and every one of them belongs on a single calendar with a named owner:

• Your website encryption certificate. When it lapses your site does not get slow, it shows visitors an outright security warning that stops them entering. The effect on sales is immediate and total.
• Domain registration. Forgetting to renew the domain takes down the website and the email together, because the email runs on the same domain. It is among the worst outages because it cuts off the very channel you would have used to explain yourself.
• The e-invoicing stamp certificate. ZATCA e-invoicing detailed technical guidelines state that taxpayers renew the cryptographic stamp identifier for their invoice-generating units before the existing one expires, and that renewal involves revoking the old identifier and issuing a new one. Miss the window and you have an invoicing problem, not just a notification.
• Integration keys between your systems. The access token linking your store to your inventory system, or your system to a payment gateway, has a defined lifetime. Its expiry does not stop either system, it stops the bridge between them, so orders keep arriving while syncing quietly halts. That is the kind of failure discovered late.
• App signing certificates and cards on file. An expired signing certificate blocks you from shipping an update to the store, and an expired card on a subscription stops the service itself. Both tend to land at the worst possible moment.

The working rule is simple. Anything with an expiry date needs three things: an alert sixty days out, an owner by name rather than by department, and a deputy who knows how to renew it if the owner is away. Missing any one of the three puts you back to relying on somebody's memory.

What to do on the day your provider goes down

When the outage hits, the difference between a business that looks professional and one that looks flustered is not repair speed, since the repair is not in your hands anyway. The difference is three things you prepared beforehand:

• A communication channel outside the layer that fell. If all your internal coordination lives in one tool, you have no coordination when it goes. A backup group on a genuinely different channel, plus a contact list held outside the system, is enough.
• A declared manual mode for critical operations. How do you take an order, record a payment and deliver a service without the system? Write it on one page today and hand it to the team. Companies that write that page lose hours. Companies that do not lose a day.
• A message ready for the customer. Customers are angered less by the outage than by the silence. A short note saying what is affected, what the workaround is, and when the next update comes turns a failure into a managed situation. Do not promise a fix time you do not control.

After it ends, ask one question and no more: what did we learn today about our dependencies that we did not know? The answer to that is worth more than any report, and it is usually a single line that deserves a single change.

The Origami view

In our work, what surprises business owners most is rarely the outage itself. It is discovering that systems they believed were independent went down together. A decision built on the belief that we have alternatives falls apart when it turns out the alternatives all pass through the same door. That is why we start any continuity conversation by mapping dependencies rather than by buying a tool, because the tool you buy may well sit on the same layer and raise the risk instead of lowering it.

We also think the right response to an outage like this is not to flee the cloud. Cloud infrastructure from a serious provider is more reliable than what most companies can build and operate themselves, and a rare interruption does not change that. The right response is to know precisely which of your operations stop and which continue, and to have chosen that deliberately rather than discovering it on a bad day. Continuity is not a system you purchase. It is a set of small decisions you make while you are under no pressure to make them.

Conclusion

A single fault in a shared authentication layer stopped six products for more than a day at companies across the world. The lesson is not to switch providers, it is to know what your systems genuinely share beneath the surface. Start with a three-column table that exposes your dependencies, put every expiry date on one calendar with a named owner, and write the manual-mode page before you need it. That is roughly three hours of work standing between you and a full day of paralysis, which makes it the cheapest continuity investment available.

Sources

• BleepingComputer: details of the Microsoft 365 outage, incident IDs EX1464935 and MO1465074, and the company statements on cause and mitigation
• Microsoft: official cloud service status page
• ZATCA: E-invoicing Detailed Technical Guidelines, onboarding and renewal of the cryptographic stamp identifier
• Tom's Guide: live coverage of the 31 August 2026 service interruption