Lost Admin Access to Microsoft 365: The Recovery Playbook

Losing admin access to a Microsoft 365 tenant is one of the few IT problems that can genuinely stop a business from operating. Mail flow usually keeps working, but you cannot add users, reset passwords, fix licencing, or respond to a security incident. If the admin was also compromised, the problem is worse than an operational one. Microsoft recovery paths exist, but they are slow, bureaucratic, and require proof of domain ownership at minimum. Start the conversation early.

Scenario 1: The Admin Left and Nobody Has Credentials

This is the most common version. The person who set up the tenant is no longer with the organisation, their account was not properly handed over, and no other user has the Global Administrator role. You may still have access to the domain registrar and to the tenant through a lesser-privileged account, or you may not.

Recovery path

1. Identify which account is the last Global Admin by asking any user with the Billing Administrator or User Administrator role to look in the Microsoft 365 admin centre under Roles > Global administrator.
2. If the former admin's mailbox still exists, reset the password through the domain registrar-based admin reset flow (see Microsoft Learn). This requires control of the DNS for your domain, which you should verify before anything else.
3. If the mailbox was deleted and the password cannot be reset, open a Microsoft support case and request an admin takeover. Microsoft requires proof of organisational ownership: typically domain DNS control (a TXT record they specify), articles of incorporation, and a government-issued letter on company letterhead.
4. Expect the takeover to take several business days at minimum. Microsoft deliberately moves slowly here, because the same process is what an attacker would attempt.

Scenario 2: The Admin Account Is Compromised

You still have the username but the attacker changed the password, registered their own MFA device, added OAuth application consents, and possibly changed the recovery phone and email. This is an active security incident, not a password reset.

Recovery path

1. If a second Global Admin exists and is not compromised, use that account to disable the compromised one, force sign-out of all sessions, clear all MFA registrations on the compromised account, and revoke OAuth grants. This is why tenants should always have at least two Global Admin accounts.
2. If no second Global Admin is reachable, skip to the Microsoft support path in Scenario 1, but flag the case as a security incident. Microsoft has a faster escalation queue for confirmed account takeovers.
3. Engage breach counsel and your cyber insurer. A compromised Global Admin is, by default, a full tenant compromise. Assume the attacker has read and exfiltrated mail, files, and Teams data. See our incident response playbook for the containment sequence.
4. After recovery, rotate every secret that ever touched the tenant: service principal secrets, app registrations, conditional access named locations, partner (CSP) relationships, and any SAML signing certificates.

Scenario 3: Forgotten Credentials but You Control the Domain

The easiest version. You still control DNS for the domain, you still have a working admin account, but you forgot the password or lost the MFA device.

Recovery path

1. If MFA is lost but the password is known, have another admin reset your MFA registrations, or use a registered alternate method.
2. If the password is lost, use the self-service password reset flow if it was enabled at tenant level. Otherwise, another Global Admin resets it.
3. If nothing else works, the DNS-based admin reset path in Scenario 1 applies.

Scenario 4: The Breakglass Account Is Missing

A breakglass (emergency access) account is a cloud-only Global Admin account, exempt from conditional access, not tied to any individual, with an extremely long random password stored somewhere offline. Best practice is two of them, stored in different safes. If you configured one at tenant creation and know where the password is, this whole article is a non-issue. If not, plan the remediation now.

Setting up breakglass accounts correctly

• Create two cloud-only accounts, for example [email protected] and break-glass-2@.
• Assign both the Global Administrator role directly, not through a group.
• Exclude both from all conditional access policies that could lock you out (location-based, device-based, risk-based).
• Use a long randomly generated password, at least 32 characters. Split it across two envelopes if you want two-person control.
• Register phishing-resistant MFA (FIDO2 security keys) rather than SMS or app-based, and physically store the keys in a safe.
• Store the credentials in a sealed envelope in a physical safe or in a hardware security module. Do not store them in the same password manager that staff use daily.
• Monitor sign-in activity on both accounts with an alert; they should only ever log in during a genuine emergency drill or a genuine emergency.

See Microsoft's guidance on emergency access accounts in Entra ID for the full configuration.

Proof of Ownership Documents Microsoft Asks For

If you need to open a support case for admin takeover, gather these before you call. Having them ready cuts days off the process.

• Legal name and registered address of the organisation.
• Domain registrar access to add a Microsoft-specified TXT record to DNS.
• Articles of incorporation or BC registry profile.
• A signed letter on company letterhead requesting admin takeover, from an officer of the organisation.
• Government-issued identification for the signing officer.
• Details of the tenant (primary domain, initial onmicrosoft.com domain if known, billing contact if known).

After Recovery: Tighten the Tenant

Once you are back in, do not stop at the password reset. Schedule a short project to put the fundamentals in place so this cannot happen again:

• Two breakglass accounts configured and documented.
• At least two named Global Admins, both on phishing-resistant MFA.
• Privileged Identity Management (PIM) for just-in-time role elevation.
• Conditional access policies, with documented breakglass exclusions.
• Audit log retention extended beyond the default where licencing allows.
• A written off-boarding procedure that covers admin roles, delegate access, and service accounts whenever IT staff leave.

Related articles: I Clicked a Phishing Link: What to Do · How to Choose an IT Company in Vancouver · Signs You Need Managed IT

← Back to Blog