When Microsoft Goes Dark, What Keeps Your Organisation Moving?

When a major cloud provider has an outage, everyone asks the same question: “How could this happen?”

The better question is: “What kept moving, and what froze?”

Because the pain is rarely the loss of one application. The pain is the collapse of the seams between applications: identity, email, device trust, workflows, and the human habit of “just logging in again”. When the seams go, work stops in places you did not label as “IT-critical”.

The Danish incident described in Microsoft-nedbrud rammer hele Danmark: »Den centrale nerve i kommunikationen er ramt« is useful for one reason. It compresses a slow-burn risk into a single day. Municipalities, regions, and private businesses all felt it, but not equally. That difference is the whole lesson.

Here is a template I would use to run the post-mortem, and then turn it into architecture and contracts that fail softly, not “best effort”.

The real outage is usually identity, not apps

Most organisations believe they are buying SaaS. In practice, they are buying a dependency graph, and the top node is identity.

When identity is unavailable or inconsistent, three things happen fast:

• People cannot start work: they cannot authenticate to the tools that hold today’s tasks.
• Support cannot help: the helpdesk scripts assume the same identity plane that is failing.
• Local workarounds get blocked: conditional access, MFA, and device compliance prevent “just use your phone” fixes.

This is why the article’s framing of Microsoft as “the central nerve in communication” lands. It is not only communication. It is the permission layer for work.

If you want a sharper internal conversation, stop saying “Microsoft outage” and start saying: identity-plane outage. That naming change forces the right follow-up: “What else uses that plane?”

Map dependencies by workflow, not by vendor

Concentration risk is not solved by sprinkling in a second vendor. It is solved by knowing which workflows must survive, then designing the minimum viable path for each one.

A simple way to map this is to pick five workflows that keep your organisation safe, legal, and cash-positive. Then trace what they require, end to end, on a normal day.

In municipal and industrial service settings, the dependencies that matter tend to cluster in four places.

1) Identity and access

• SSO and MFA
• Conditional access policies
• Password reset flows
• Privileged access tooling

If your “break glass” accounts live in the same identity system, they are not break glass. They are theatre.

2) Email and calendaring (because it is also your workflow bus)

Email is still how approvals happen, incidents get escalated, and ad hoc coordination happens when systems are down. If mail is coupled to the same identity failure, you lose your backup communication channel right when you need it.

3) Device management and trust

Modern endpoints are governed, and rightly so. But device management can become a hidden single point of failure: compliance checks, certificate renewal, VPN profiles, and the ability to push emergency configuration.

During a broad outage, the immediate symptom is often “my laptop is fine, but I cannot access anything”. The structural cause is that the device is no longer considered trusted.

4) SCADA-adjacent workflows (not the control loop, the people loop)

In critical infrastructure, the control system is often segmented. The fragile part is everything around it: maintenance tickets, alarms routed into collaboration tools, on-call rosters, shift handovers, vendor remote access procedures, and reporting.

The control loop might keep running, but the organisation loses visibility and coordination. That is how minor faults turn into long faults.

One practical method: for each workflow, write the “Day Zero Minimum”. That is the smallest set of actions you must still be able to do if identity, mail, and device management are impaired for 24 hours.

Design for fail-soft: degraded modes you can rehearse

Business continuity plans tend to read like aspirations. Fail-soft design is different. It is engineering a degraded mode that is deliberately less convenient, but reliably available.

Three design patterns show up again and again.

Pattern A: Local authority, time-boxed

You need a way for a limited set of people to act without the central identity system. That does not mean “no security”. It means alternate security.

• Offline-capable credentials stored in a secure physical process (sealed envelope, dual control, audit log afterwards).
• Time-limited local accounts on key systems that can be enabled with a manual approval chain.
• Emergency access procedures that are practiced quarterly, not admired annually.

Pattern B: Alternate comms that do not share the same failure domain

If your incident channel is Teams and your identity is Entra, that is one domain. If your phone system is cloud-managed through the same admin accounts, that can be the same domain too.

Pick at least one channel that is operationally separate. It can be as simple as a pre-agreed SMS tree for incident roles, backed by a printed roster. The goal is not elegance. The goal is a path that survives the same blast radius.

Pattern C: Data access that does not require the full productivity stack

When the “central nerve” is hit, the immediate blockers are often mundane: contact lists, procedures, asset registers, current work orders, and who is on call.

Make a small subset available in a read-only, offline or alternate-hosted form. The mistake is trying to replicate everything. The win is making the 20 pages that keep the organisation coordinated accessible when the rest disappears.

I once watched a connected product organisation discover, during an identity disruption, that the biggest operational loss was not dashboards. It was the inability to reach the right field technician with the right context. The systems were “up enough”. The work was not. That changed how we treated contact data, role rosters, and on-call handovers. Not as admin trivia, but as production inputs.

Contract for recovery you can test, not promises you can quote

Cloud contracts are usually negotiated like procurement. Concentration risk requires negotiating like a risk owner.

Four clauses matter more than another discount point.

1) Explicit failure modes and support escalation

When things go wrong, you need clarity on what you will be told, how quickly, and through which channel that does not require the same identity system. “Status page” is not enough if access to your admin center is broken.

2) RTO and RPO where you actually need them

Most organisations write generic numbers that look professional and do nothing. Tie targets to the workflows you mapped earlier. If procurement cannot send purchase orders, or a region cannot coordinate staffing, that is not a “minor degradation”.

3) Exit and portability that covers identity and device posture

Exit plans tend to focus on data export. In real outages, identity and device posture are the choke points. Your exit rights should include what you need to re-establish authentication, endpoint trust, and admin access elsewhere, under time pressure.

4) The right to rehearse

You cannot claim resilience you have never exercised. Bake in the right to run planned tests of your degraded modes. Not chaos engineering for its own sake. A controlled rehearsal: “For two hours, assume identity is unavailable. Prove the Day Zero Minimum.”

If this sounds like more work than it is worth, remember the alternative. You will do the work anyway, except you will do it during an outage, with stressed people, and with political heat.

A post-mortem template you can run next week

Use the outage as a forcing function. Even if you were not directly hit, treat it as your near-miss.

1. Write the timeline in human terms: When did people first notice? What did they try? What failed first? What work stopped?
2. Pick 5 workflows that must survive 24 hours. Name the workflow owner for each.
3. Trace dependencies: identity, mail, device management, ticketing, comms, file access, on-call tooling.
4. Define Day Zero Minimum for each workflow in one paragraph. No jargon.
5. Design one degraded path per workflow, even if it is manual.
6. Assign one accountable person to make it real: documentation, access, rehearsal.
7. Negotiate the contract deltas that make the degraded path supportable, including rehearsal rights and escalation channels.

This is where many organisations discover an uncomfortable truth: their resilience story is mostly implied. Implied is the same as unowned.

If you want a related mental model, I like asking “what breaks first?” because it forces specificity over slogans. I use the same approach in market infrastructure, where failure cascades are not theoretical. It is the same question behind What breaks first in 24/7 tokenized equities: halts or dividends?

My opinion: fail-soft is a leadership choice, not a cloud feature

The goal is not to be independent of large providers. For most organisations, that is unrealistic and unnecessary.

The goal is to be independent of one failure. Identity goes down, you still coordinate. Email is delayed, you still approve. Device management is degraded, you still reach critical systems. SCADA-adjacent workflows slow down, but they do not blind you.

That is what “cloud concentration risk” looks like in real life. Not a risk register entry. A Tuesday where people cannot do their job.

If you design for that Tuesday, you are not only safer. You are faster the rest of the year, because you finally understand what your organisation actually depends on.