Identity Is the New Outage Domain

TL;DR

• Identity now controls access to email, files, devices, and core business applications.
• A working application is still unavailable when employees cannot authenticate or recover access.
• MFA helps, but identity resilience also requires governance, recovery, and administrative separation.
• Growing firms should manage identity as operational infrastructure, not an administrative utility.

A server can be healthy while the business remains unable to work.

“The system is up” used to settle the availability question. It no longer does. If employees cannot sign in, satisfy an access policy, recover an account, or reach the correct data, the underlying service may be technically available and operationally useless.

That is why identity is the new outage domain.

The change is structural. Microsoft 365 identity often sits in front of email, documents, collaboration, endpoint management, cloud applications, and administrative access. Each added integration makes identity more valuable. It also makes identity failure more consequential.

What is an identity outage?

An identity outage is the loss of usable access caused by authentication, authorization, account recovery, or identity-governance failure.

The failure does not need to affect every employee. A disabled executive account before a financing deadline, an inaccessible project mailbox during a bid submission, or a locked administrative account during an incident can be enough to interrupt a material workflow.

Common forms include:

• A conditional access change that blocks legitimate users.
• A lost or replaced phone that prevents multifactor authentication.
• A privileged account with no tested recovery route.
• A role change that removes necessary access or preserves unnecessary access.
• A terminated employee whose credentials remain connected to shared systems.
• A line-of-business application that depends on a single identity administrator.

Microsoft describes Conditional Access as a policy engine that evaluates signals and applies access decisions. That capability is powerful because it concentrates control. It also means policy design, exclusions, testing, and rollback become continuity concerns—not merely security settings.

Why does growth increase identity risk?

Growth multiplies exceptions faster than most firms standardize them.

The 30-person organization usually knows why someone has access. The 100-person organization may only know that the access existed before the last reorganization. New locations, acquisitions, contractors, shared mailboxes, temporary projects, and cloud applications create more identities and more relationships between them.

The warning signs are operational:

• Managers request access by copying the last employee’s permissions.
• Shared accounts remain because no owner wants to change a familiar workflow.
• Former contractors still appear in groups or collaboration spaces.
• Department changes add new rights without removing old ones.
• Administrative roles accumulate around the people who “know the system.”
• Recovery steps exist in memory rather than in a tested procedure.

This is technology debt expressed through identity. Each exception is manageable alone. The risk appears when several exceptions depend on one another and nobody owns the combined result.

What separates identity availability from application availability?

Availability is now a chain, not a component.

An employee reaching a file may depend on a device state, an identity provider, an MFA method, a policy decision, a group membership, a license, and an application permission. Every link can be operating as designed while the final business outcome still fails.

Mature operations monitor both sides of this table. They verify the platform and the user journey. They also define which identity-dependent workflows cannot wait for an improvised response.

Where do identity outages most commonly become severe?

The highest impact appears where authority and recovery are concentrated.

We routinely encounter environments where one long-tenured employee is the informal identity control plane. That person knows which account owns the billing relationship, which exceptions are intentional, and which administrator can recover another administrator. The knowledge is valuable. The concentration is not resilient.

Severity increases when:

• Global administrative access is used for routine work.
• Emergency access accounts exist but are not monitored or tested.
• Authentication methods depend on one device or one person.
• Service accounts have unclear owners and undocumented dependencies.
• Policy changes have no test group, rollback plan, or peer review.
• Identity logs are retained but not reviewed during normal operations.

CISA and the NSA’s identity and access management guidance emphasizes governance, credential management, authentication, federation, and authorization as related capabilities. The practical lesson is simple: identity is not one setting. It is an operating system with multiple control points.

A resilient identity program protects access without making one person, one device, or one policy the only route back into the business.

How should a growing firm build identity resilience?

The practical sequence is:

1. Map the critical access paths. Identify which identities, groups, applications, and devices support revenue, payroll, client delivery, and incident response.
2. Separate daily administration from emergency authority. Limit privileged accounts, protect them differently, and avoid using them for ordinary email or browsing.
3. Create and test recovery routes. Document emergency access and user recovery. Test them before a real interruption.
4. Standardize role-based access. Define access by job function and location rather than copying another employee’s history.
5. Control policy changes. Use test populations, named owners, peer review, and rollback criteria for consequential changes.
6. Review exceptions on a cadence. Temporary access, guest accounts, service accounts, and exclusions should expire or receive explicit reapproval.

This does not require turning every firm into an identity engineering organization. It requires treating access with the same discipline already expected of financial authority, physical keys, and business continuity.

Common mistakes when improving identity resilience

• Treating MFA as the finish line. Stronger authentication does not define ownership, recovery, or appropriate authorization.
• Keeping permanent policy exclusions. An exception created during rollout often survives long after its reason disappears.
• Protecting users but ignoring administrators. Privileged identity failure can block recovery for everyone else.
• Automating an undefined process. Automation makes a clear process faster; it makes a confused process harder to inspect.
• Testing security controls but not recovery. A control is incomplete when nobody has verified how legitimate access returns.
• Measuring tickets instead of business interruption. A short identity ticket can still delay a high-value decision or deadline.

Map Your Operational Gaps →

An identity review should show where access, ownership, and recovery depend on undocumented exceptions. Executive-level discussion. No technical pre-work required.

Schedule a Technology Alignment Discussion

About the author

Sebastian Abbinanti is President of The Isidore Group, a Chicago-based technology consulting, managed services, cybersecurity, cloud, and AI advisory firm. He works with growth-stage organizations to align technology controls with real operating requirements.

Related reading: The Hidden Technology Debt in Onboarding and Offboarding · How Growing Firms Standardize Access Without Slowing Down