Microsoft 365 Global Administrator After Death: A Continuity Plan

Microsoft 365 Global Administrator After Death: A Continuity Plan

For a small company, nonprofit, consultancy, or family business, one Microsoft 365 tenant may hold the keys to nearly every working day. Microsoft Entra ID controls identities. Exchange Online carries email. SharePoint and OneDrive hold records. Teams contains conversations and meetings. The admin center connects subscriptions, domains, support, and security settings.

If the founder is the only usable Global Administrator and that person dies or becomes incapacitated, a personal emergency can turn into an organization-wide access crisis. Staff may still be able to read email, yet nobody can reset an administrator, change a domain setting, investigate a security event, or manage a critical subscription.

The solution is not to share the founder's password. A strong plan creates independent, governed recovery paths before they are needed. It also separates technical access from the authority to make decisions about the deceased person's account, company data, and ongoing operations.

Understand what is concentrated in the Global Administrator role

Microsoft describes Global Administrator as a highly privileged role. It can reach administrative features across Microsoft Entra ID and services that rely on Entra identities. Depending on configuration and licensing, a Global Administrator may be able to manage users and domains, reset other administrators, manage subscriptions, access security and compliance portals, and elevate access to Azure resources.

That reach makes a sole Global Administrator a dangerous dependency. The same person may also control:

• the tenant's custom domains and DNS provider
• the subscription, reseller, invoices, and payment method
• Conditional Access policies and multifactor authentication methods
• the only privileged workstation or registered security key
• Exchange, SharePoint, Teams, Intune, Defender, and Purview administration
• third-party backup, single sign-on, and line-of-business applications
• the founder's mailbox, OneDrive, and business records

Write down these dependencies as roles and systems, not merely as passwords. A checklist that says “Microsoft is on Alex's phone” does not explain which tenant exists, which account has authority, how the domain is renewed, or who may act when Alex is unavailable.

Maintain two cloud-only emergency access accounts

Microsoft recommends two or more emergency access accounts for a Microsoft Entra organization. These are break-glass accounts with permanently active Global Administrator assignments, reserved for the situations in which normal administrators cannot sign in or activate their roles.

Microsoft's current guidance calls for cloud-only accounts using the tenant's onmicrosoft.com domain. That design avoids dependence on an on-premises directory, federation service, custom domain, or identity provider that may be part of the outage. Emergency accounts should use phishing-resistant authentication, such as FIDO2 passkeys or certificate-based authentication, and their authentication should not depend on the same method used by ordinary administrators.

Two accounts provide redundancy. Store their credentials or devices securely in separate locations available only to authorized people. Do not tie both accounts to the founder's personal phone, personal email, home office, or biometric. Do not use them for everyday email or administration.

Configure alerts for emergency-account sign-ins and audit activity. Every use should prompt a review: who authorized it, why normal access failed, what actions were performed, and what must be repaired before the account returns to standby.

Use least privilege for normal administration

Emergency Global Administrator accounts do not mean every IT task needs Global Administrator access. Microsoft 365 and Microsoft Entra provide narrower roles for Exchange, SharePoint, billing, users, authentication, security, and other functions.

Give each administrator an individual identity and only the roles needed for their work. A bookkeeper might need billing access without user or security control. A support lead may need limited password-reset powers. A SharePoint specialist does not automatically need authority over domains and subscriptions.

This approach reduces the damage from phishing, mistakes, and compromised devices. It also makes succession clearer: the continuity inventory can show who owns each operational responsibility instead of treating one founder as the answer to every administrative question.

Keep ordinary Global Administrator assignments few. Review privileged roles after personnel changes, acquisitions, vendor transitions, and long absences. If Privileged Identity Management is used, document who can approve activation and what happens if those approvers are unavailable. An elegant approval process that nobody can activate during a crisis is still a lockout.

Remove shared authentication dependencies

An organization can have several administrator accounts and still have only one practical recovery path. Examine the whole sign-in chain:

• Are all administrators registered to the same person's phone?
• Does every account depend on an on-premises identity provider in one office?
• Would Conditional Access block sign-in if the usual device or network were unavailable?
• Are all security keys stored in the same building?
• Does the password vault require approval from the missing founder?
• Are support notices delivered only to the affected Microsoft 365 domain?
• Does the reseller recognize anyone besides the deceased account owner?

Microsoft advises excluding emergency accounts from Conditional Access policies that could block or restrict their sign-in, while protecting them with a strong independent authentication method. The point is not to weaken security. It is to avoid making the emergency path depend on the same control that caused the lockout.

Record how the tenant's authentication works, including hybrid synchronization, federation, Conditional Access, passwordless credentials, privileged workstations, and partner access. Store the runbook somewhere reachable if the Microsoft tenant itself is unavailable.

Connect technical access to organizational authority

An emergency credential answers “how can an authorized person reach the tenant?” It does not answer “who is authorized?”

The organization should name the officers, owners, trustees, directors, executors, attorneys, or managers who can authorize emergency use. Corporate documents, operating agreements, employment policies, powers of attorney, and estate documents may all matter. The correct authority varies by organization and jurisdiction.

Create a two-part runbook. The technical section should identify:

1. Tenant names, tenant IDs, verified domains, and the default onmicrosoft.com domain.
2. Current administrators, emergency accounts, role assignments, and partner relationships.
3. Authentication dependencies, security devices, vaults, and privileged workstations.
4. Subscriptions, licensing contacts, invoices, billing methods, and renewal dates.
5. Domain registrars, DNS hosts, backups, and critical third-party applications.
6. Microsoft support and reseller contact routes available outside the affected tenant.

The authority section should identify who may approve emergency sign-in, data access, user suspension, mailbox delegation, subscription changes, public communication, and final account disposition. It should also state when counsel, the board, an executor, or a privacy officer must be consulted.

Never place every live password, recovery code, tenant map, and approval record in one unencrypted file. The runbook should point authorized people to protected secrets and record how access is logged.

What to do when the administrator has already died

If another authorized administrator can sign in, use that person's own account. If ordinary administration is unavailable and the documented conditions are satisfied, authorized people may use a tested emergency account. Record the reason and preserve the resulting audit logs.

Do not begin by deleting the deceased administrator. First:

1. Preserve organization-owned devices, authentication hardware, and relevant records.
2. Confirm who has authority to direct technical and data-handling decisions.
3. Review active sessions, role assignments, authentication methods, application registrations, forwarding rules, delegates, and partner access.
4. Protect urgent operations such as payroll, customer communication, domain renewal, security alerts, and subscription billing.
5. Determine how mailbox, OneDrive, Teams, SharePoint, and compliance records must be retained.
6. Remove or change privileges only through an approved, documented process.

Do not sign in as the deceased person merely because a password or unlocked device is available. That can blur audit records, conflict with policy, and expose private or regulated information. Use administrative delegation and preservation tools instead.

If every Global Administrator is inaccessible and no emergency account or authorized partner path works, contact Microsoft 365 business support or the relevant reseller and describe the situation as an administrator or tenant lockout. Be ready to establish the tenant, subscription, domain, and organizational authority. Recovery is a verification process, not an instant inheritance feature.

Preserve email and files before deleting anything

The deceased administrator's identity may also own a mailbox, OneDrive files, meetings, flows, application connections, or encryption dependencies. These need separate decisions.

Microsoft documents ways for appropriately privileged administrators to give another person access to former-user OneDrive content and to preserve, forward, export, or convert mailbox data. A mailbox can sometimes be converted to a shared mailbox, but licensing, size, retention, hybrid configuration, and compliance requirements affect the correct choice.

Deletion starts time-sensitive processes. Microsoft states that the default OneDrive retention period for a deleted user is 30 days, though it can be configured, and retention policies or holds can alter what happens. Do not interpret that default as permission to wait 29 days or as a guarantee that every workload follows the same timeline.

Before changing the account, inventory business-owned content and obtain guidance for personal, confidential, regulated, or disputed data. Preserve auditability: record who received access, what was transferred, which rules justified the action, and when access should end.

Test the plan at least every 90 days

Microsoft's emergency-access guidance calls for validation at least every 90 days. A safe test confirms that authorized staff can retrieve the governed credential, sign in from the designated secure environment, trigger monitoring, and perform an agreed limited administrative check.

During each exercise, verify that:

• both emergency accounts still exist and remain cloud-only
• authentication devices or certificates work and have not expired
• Conditional Access does not unexpectedly block the emergency path
• alerts reach more than one current responsible person
• authorized-user lists and safe locations are current
• the tenant, domain, reseller, billing, and support details are accurate
• administrators understand the legal and organizational approval process
• a second person can locate critical operational records

Test again after changes to IT staff, ownership, federation, Conditional Access, authentication methods, subscriptions, partners, domains, or office locations. Rotate safe combinations and access lists when an authorized custodian leaves.

A practical Microsoft 365 continuity checklist

Before calling the plan complete, confirm that:

• two cloud-only emergency Global Administrator accounts are configured
• emergency authentication is independent and phishing-resistant
• credentials and devices are stored securely in separate locations
• emergency sign-ins and audit events generate alerts
• named administrators use individual accounts and least-privileged roles
• normal Global Administrator assignments are limited and reviewed
• tenant IDs, domains, subscriptions, billing, and partners are documented
• the plan works even if federation, a personal phone, or the custom domain fails
• business records are not concentrated in the founder's OneDrive or mailbox
• retention and data-transfer decisions have named owners
• technical access and legal authority are documented separately
• Microsoft and reseller support routes are available outside the tenant
• the emergency process has been tested within the last 90 days

Conclusion

Planning for a Microsoft 365 Global Administrator after death is an exercise in organizational resilience, not password inheritance. The tenant should remain recoverable when one person, one phone, one identity provider, or one office is unavailable.

Build that resilience with two protected cloud-only emergency accounts, narrowly scoped everyday administrator roles, independent authentication, current tenant and vendor records, and a runbook that connects technical steps to genuine authority. Preserve the deceased administrator's identity and data until qualified people make deliberate retention and transfer decisions.

Ask one practical question today: if the primary administrator and all of their devices disappeared, could authorized colleagues recover tenant administration, explain why they were allowed to act, and preserve the organization's email and files without impersonating that person? Every uncertain answer belongs on the continuity plan.