Microsoft 365 / How to Assign Administrator Roles and Prepare Emergency Access Accounts

Assign Microsoft 365 administrator permissions according to each person’s tasks rather than giving every administrator the Global Administrator role. Prepare and regularly validate independent emergency access accounts so that the organization can recover administrative access if its normal administrator accounts cannot be used.

Why separate administrator roles?

Admin roles determine the scope of settings that can be viewed and the operations that can be changed. Roles such as License Administrator, User Administrator, Exchange Administrator, and SharePoint Administrator are designed for different responsibilities. Giving unnecessarily broad permissions to a single account increases the potential impact of account compromise or mistakes.

Microsoft's Microsoft 365 Administrator Role Guide recommends minimum privileges and limiting the number of administrators. When assigning roles, first list the specific tasks the person will perform, and select the most restrictive role that supports those tasks. Do not estimate permissions based on the role name alone; check the detailed permissions.

Choosing roles for common tasks

For example, if HR provides a list of new employees and IT creates their accounts, HR can submit an approval request without receiving user-management permissions. Separate the tasks into "tasks necessary for the company" and "tasks that this person must perform directly". Role assignments should be performed by a separate administrator who has the appropriate permissions.

Assigning and removing administrator roles

1. In the Microsoft 365 admin center, open Roles → Role assignments. Your current account must have permission to manage roles.

2. Select a role suitable for your tasks and read the permission description. If needed, check more detailed roles in the Microsoft Entra admin center.
3. On the Assigned tab, select Add users, choose the appropriate account, and select Add. Record the reason for the assignment, approver, scope, and review schedule.
4. Check whether the necessary work can be performed with the account and remove any unnecessary permissions. Since it may take time for permissions to be applied, start a new login session to verify.

You can also change roles on the user detail screen's Manage roles. Microsoft's role assignment procedure explains both paths.

After saving, the assigned person checks the necessary menus and tasks in a new login session. If it is read-only work, just verify the viewing; when checking change permissions, determine the approved test target and values to revert. In case of errors, first check the target scope of the organization and roles and the assignment status, and do not immediately elevate to a global administrator.

When the work is finished or the person in charge changes, remove the person from the same Roles → Role assignments → the relevant role → Assigned and check again. If multiple roles are held simultaneously, even if one is removed, the same work may still be possible by another path. If the organization uses PIM (Privileged Identity Management, a management function to activate permissions when needed), distinguish and confirm active roles and eligible roles.

What is an emergency administrator account?

Emergency accounts are accounts used to regain access to your organization when your regular administrator accounts, authentication methods, or external ID systems encounter problems. They are different from simply creating an additional account for daily tasks. Microsoft recommends in Emergency Access Account Guidance preparing two or more cloud-only accounts, designing authentication paths different from regular operational accounts, monitoring their use, and testing them periodically.

Emergency accounts should be created as cloud-only accounts in the default onmicrosoft.com domain and designed so they do not rely on on-premises directory synchronization or external authentication servers. The Microsoft guidance updated in June 2026 advises that emergency accounts use phishing-resistant authentication methods different from regular administrators and be excluded from Conditional Access policies that block or restrict login. Report-only policies do not prevent login, so there is no need to exclude emergency accounts for that reason alone.

This exception does not mean they should be configured to log in with only a password. Use FIDO2 passkeys or security keys to meet mandatory multifactor authentication (MFA) requirements. Certificate-based authentication is another option if the organization already has a public key infrastructure (PKI) in place. If regular accounts rely on phone authentication, do not configure emergency accounts to rely on the same phone. If using PIM, it is recommended that emergency accounts’ global administrator roles be in a permanently active state rather than an eligible assignment that requires activation approval.

Preparing and validating emergency access accounts

1. Investigate current global administrators and authentication dependencies. Ensure that they do not rely solely on integrated on-premises IDs or a single authentication method.
2. Design at least two cloud-only emergency accounts according to organizational policy. Account names should allow identification of their purpose but should not be exposed in public documents or screenshots.
3. Set global administrator privileges and authentication methods following Microsoft guidelines, and ensure a usage path independent from regular administrator accounts. The setup method varies depending on the organization’s licenses and policies.
4. Configure alerting and audit procedures for account usage and configuration changes. If logged in with an emergency account, incident records and post-review must be maintained.
5. Regularly test logins in a controlled environment. After testing, verify that the expected logs and alerts are generated, and update access procedures when personnel changes occur.

What to verify during regular tests

Microsoft recommends validating emergency accounts at least every 90 days. Recheck after administrator changes, authentication policy updates, or storage location changes. The key is to distinguish between "having an account" and "being able to use it for recovery," so that the account is not tried for the first time during an actual outage.

1. Inform the security officer that a scheduled test will be conducted and verify that the approved personnel can access the credentials and designated secure work environment. If access to the locker relies on a work account that is unavailable during the incident, the recovery path may also be blocked.
2. Log in using the emergency account without reusing a general account session. Confirm that the required authentication methods work and that administrative functions are accessible. Do not arbitrarily disable organizational policies for testing purposes.
3. Check whether the actual accounts and timestamps appear in login and audit logs, and whether monitoring alerts are sent to other administrators. If no alerts were received, do not consider the system ready for normal operation.
4. After logging out, record the test results, users who accessed the system, failed items, and the person responsible for remediation. After actual emergency use, review the tasks performed and reassess credentials and storage procedures that might have been exposed.

Monitoring can be designed based on the account object ID in Entra login logs. When connecting notifications through Azure Monitor or the organization's security monitoring tools, you need to first prepare log exports, storage, and alert paths, which may require additional permissions and incur separate costs. Simply creating an account does not automatically configure alerts. Do not record the actual emergency account address, recovery codes, or secure key storage locations in public documents; keep them in controlled operational records.