When the tenant is compromised: emergency access, break-glass and continuity in identity administration

Your contingency plan assumes something it hasn't tested

Open your organisation's ICT contingency plan and find the section on what happens during a serious identity compromise. In most plans it says some variant of: "The IT department locks affected accounts and restores access."

Then ask three questions:

1. Who specifically does this, and what happens if that exact person's account is one of the compromised ones?

2. How do they log in, if the Conditional Access policy requires a device marked compliant, and device administration is itself part of what's been affected?

3. How is what was done documented, when what's being done is emergency action outside the normal process?

Questions 1 and 2 are about emergency access. Question 3 is about the fact that an incident is always followed by an investigation, and that the investigation is easier or harder depending on decisions made before the incident.

Emergency access accounts: Microsoft's recipe, and why it's often implemented wrong

Microsoft's recommendation is precise: organisations should have two cloud-based emergency access accounts permanently assigned the Global Administrator role. The accounts do not belong to named individuals and are restricted to emergencies where normal accounts cannot be used, or where all other administrators have been accidentally locked out.

Four requirements come with this, and all four are routinely broken:

Excluded from Conditional Access policies that block or restrict sign-in. Microsoft's reasoning is direct: an emergency access account subject to a policy requiring MFA in a particular way, a compliant device, or another control, can become unusable in exactly the situations it was created for. Recommended practice is a dedicated security group — for example EmergencyAccess — excluded from the relevant policies. Policies in report-only mode do not need exclusion.

Strong, phishing-resistant authentication, different from the normal one. Microsoft recommends a passkey (FIDO2) as the first choice, or alternatively certificate-based authentication where the organisation already has PKI. The method should be different from the one administrators use day to day — the point is that a compromise of the ordinary authentication mechanism should not also take down emergency access.

Cloud-based, not synced from a local directory. An account originating from local AD depends on local AD functioning.

Tested. An emergency access account that hasn't been verified in the last twelve months is an assumption, not a control.

The second point requires a clarification that is often missed: Microsoft has introduced mandatory multi-factor authentication for the administration surfaces. Phase 1 from October 2024 covers the Azure portal, the Entra admin centre and the Intune admin centre for all create, read, update and delete operations, extended to the Microsoft 365 admin centre from February 2025. Phase 2 began 1 October 2025 and covers Azure CLI, Azure PowerShell, the Azure mobile app, IaC tooling and REST endpoints for write operations. Emergency access accounts must therefore have an MFA method that satisfies the requirement — they cannot be exempt from MFA as such, only from the Conditional Access policies that impose additional conditions.

Continuity in the administrative capability itself

Emergency access solves the access problem. It doesn't solve the capacity problem.

During a serious incident, the operational needs are typically: lock a large number of accounts quickly, reset credentials for a defined population, remove specific group memberships, revoke active sessions, and do it all again once you discover the scope was too narrow.

These are bulk operations under time pressure, carried out by people who haven't slept. That combination is what produces the most expensive mistakes: the wrong group deactivated, the wrong filter in the script, an operation that stops halfway due to throttling in Microsoft Graph without anyone noticing.

It's worth being honest here about a paradox in the governed model. An architecture where nobody holds standing administrator privileges and everything goes through approval is more secure day to day — but it must also handle situations where the approval step cannot wait. The answer isn't to skip the control, but to design for emergency handling: a defined emergency procedure where the action can be carried out immediately, with documented approval following afterwards, and where the use of the emergency path is itself a recorded event.

An organisation that hasn't defined this in advance will improvise it under pressure, and the improvisation leaves no documentation.

The regulatory anchor

The Power Supply Preparedness Regulations (kraftberedskapsforskriften, FOR-2012-12-07-1157) § 7-7 require registration of all security breaches and security incidents, with a duty to notify and report to the preparedness authority whenever there is immediate risk to the operational control system's function. KBO entities also have KraftCERT/InfraCERT as their sector response centre.

The Digital Security Act (digitalsikkerhetsloven) requires notification of incidents that significantly affect service delivery, without undue delay and notwithstanding any duty of confidentiality. the Norwegian National Security Authority (NSM) is the national point of contact and national response environment. The exact deadlines should be checked against the Digital Security Regulations.

The Management Regulations § 20 ("Registration, investigation and analysis of situations of hazard and accident") requires registration, investigation and analysis of hazard and accident situations, and § 22 ("Nonconformity handling") requires nonconformity handling with root-cause analysis.

Common to all three: reporting requires knowing what happened. During an incident, large volumes of actions are produced in a short time. Whether those actions are documented as they're carried out, or have to be reconstructed afterwards from logs and memory, is decided by the architecture — not by the will to document.

Four design choices that pay off during an incident

1. A continuously synchronised reference state. To know what's changed, you need to know what things looked like before. A continuously updated, searchable copy of the entire estate — users, groups, devices, Intune, Autopilot, mailboxes, apps, licences — turns "what did this look like before the incident" into a lookup. Without it, the answer is a reconstruction.

2. Bulk operations with traceability preserved. The ability to change many records in a single operation, where each individual change still gets its own attributable record, is above all an incident-response property. It lets a response move fast without becoming undocumented, and it shows precisely which objects were actually processed when an operation stops halfway.

3. Delegation that works when the key people are unavailable. If the capacity to act is concentrated in two people, preparedness is bounded by both being reachable. A model where several people can propose and a defined set can approve scales better under pressure than a model where few hold the privileges.

4. The emergency procedure is documented and rehearsed. Including: who can invoke it, what can be done without prior approval, how the use is recorded, and how subsequent approval is carried out. This is an organisational decision, not a product feature.

The preparedness card that should be ready at hand

Experience from incident response suggests that what isn't written down in advance doesn't get done correctly under pressure. On the identity side, the following should exist as a concrete, up-to-date document — not as a paragraph in an 80-page plan:

• Where the emergency access accounts' credentials are stored, who is authorised to retrieve them, and how the retrieval is recorded.
• Which Conditional Access policies the emergency access accounts are excluded from, and the date of the last verification.
• Names and contact details for those who can approve emergency actions, with at least three names across different geographies or time zones.
• Which groups are critical — the ones governing remote access, privileged roles and access to power-sensitive information — with owner and expected member count, so that deviations are immediately visible.
• Reporting channels with a named recipient: sector supervisory authority, NSM, sector response centre, and internally to management.
• Which actions can be carried out without prior approval, and how they must be documented afterwards.

The point about expected member count in critical groups is underrated. It's the simplest detection mechanism there is: a group that should have twelve members and has fourteen is a signal that requires no tool to interpret — just someone who knows the number.

On exercises

It's worth distinguishing between two types of exercise that often get conflated.

Emergency access test: log in with the emergency access account, verify it works, verify the exclusions still apply after the latest policy change, document it. Should be done at least twice a year, and always after changes to Conditional Access. Takes an hour.

Tabletop exercise on identity compromise: assume an administrator account has been compromised, and has been for two weeks. Walk through how you determine what's changed, how you scope it, how you report within the deadline, and who decides what. Takes a day, and typically reveals that the question "what was actually changed, by whom, with what justification" cannot be answered with the necessary precision.

That realisation is worth the entire exercise.

Sources

• Microsoft, Manage emergency access admin accounts — https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access
• Microsoft, Secure access practices for administrators in Microsoft Entra ID — https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-planning
• Microsoft, Plan for mandatory Microsoft Entra multifactor authentication — https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mandatory-multifactor-authentication
• Kraftberedskapsforskriften (FOR-2012-12-07-1157) §§ 2-5, 2-6, 7-7 — https://lovdata.no/dokument/SF/forskrift/2012-12-07-1157
• NSM, notification of incidents under the Digital Security Act — https://nsm.no/regelverk-og-hjelp/digitalsikkerhetsloven-og-forskriften/varsle-om-hendelser-etter-digitalsikkerhetsloven
• Havtil, the Management Regulations §§ 20 and 22 — https://www.havtil.no/globalassets/regelverk/gjeldende-regelverk-2022/styringsforskriften_n.pdf
• KraftCERT/InfraCERT — https://www.kraftcert.no/no/
• CISA, Emergency Directive 24-02 (Midnight Blizzard, compromised cloud accounts) — https://www.cisa.gov/news-events/directives/ed-24-02-mitigating-significant-risk-nation-state-compromise-microsoft-corporate-email-system-closed