An emergency administrator account is useful only if an authorised person can retrieve it, sign in from the right device and demonstrate that the activity reached someone who can respond. This guide turns that requirement into a small, reviewable drill for a Canadian business.
Use it when ordinary administration is available, before the person who usually handles IT is on leave or unreachable. If you are already locked out, work through your documented recovery and provider escalation process. Do not experiment with policies in a production incident.
Start with one unavailable dependency
Write a short scenario: "Our usual administrator is unavailable, but Microsoft 365 itself is operating." That is different from a Microsoft service outage, a lost internet connection or an attacker controlling your tenant. State which problem you are testing so a successful sign-in is not mistaken for proof that every recovery path works.
The Canadian Centre for Cyber Security's baseline controls connect incident preparation, strong authentication and access control. This drill is one implementation aid within that broader programme; it is not a Canadian certification or a substitute for a complete response plan. Read the Cyber Centre's baseline controls.
For a remote business, choose a realistic custody scenario. If the primary key is in the office and the designated responder is at a jobsite, record who can retrieve it and how the responder reaches a suitable workstation. Do not place account secrets in a shared contact spreadsheet.
Check the prerequisites before touching production
Microsoft recommends at least two cloud-only emergency accounts, protected with phishing-resistant authentication independent of normal admin methods. Its guidance also covers secure credential storage, designated workstations, monitoring and validation at least every 90 days. Review Microsoft's current emergency-access requirements.
Have your administrator compare the actual configuration with that guidance. In particular, Microsoft distinguishes protection of the emergency account from Conditional Access restrictions that could prevent emergency use. Review that configuration deliberately; do not remove MFA or copy a blanket policy exception from an unrelated tenant. The same source explains the conditions and monitoring requirements.
- Approver: the business owner or accountable IT lead authorises the purpose and window.
- Operator: an authorised administrator uses the recovery path.
- Observer: a separate person records results and confirms the alert arrived.
- Recovery fallback: ordinary administrative access remains available throughout the rehearsal.
- Safe task: agree a read-only check that does not expose customer information or alter policy.
- Evidence location: choose a restricted record store, with a ticket reference rather than secrets in the worksheet.
Stop if no one can confirm the account's custody, the workstation is not suitable, alerts have no accountable recipient, or ordinary access is already unreliable. Those findings are useful outcomes. Creating an emergency path and testing an existing one are different changes.
Run a rehearsal with explicit stop conditions
| Step | Action | Evidence or stop condition |
|---|---|---|
| 1. Authorise | Confirm the ticket, window, operator, observer and allowed read-only task. | No named approver or fallback means stop. |
| 2. Retrieve | Follow the documented credential and device custody procedure. | Record retrieval outcome and elapsed time, never the credential itself. |
| 3. Sign in | Use the approved emergency account from the designated workstation. | Record success or the error category. Unexpected prompts go to the administrator for review. |
| 4. Confirm authority | Open the agreed administrative view and confirm the expected role is usable. | A portal opening alone is insufficient if the required administrative capability is unavailable. |
| 5. Confirm detection | Ask the observer to find the corresponding sign-in record and notification. | Record the evidence reference, recipient and observed delay. Missing notification is an unresolved finding. |
| 6. Close | Sign out, secure the credentials and workstation, and close the approved activity record. | Record custody restoration and any unexpected activity for investigation. |
| 7. Review | Assign each gap an owner, due date and retest decision. | Do not mark a failed or unobserved step as complete. |
Do not deliberately lock out your normal administrator to make a rehearsal feel realistic. If the sign-in fails, preserve the error reference and stop the affected test. Repeatedly changing authentication settings during the drill destroys the evidence of what originally failed.
Download the evidence record
Download the emergency-access drill template
The plain-text template can be copied into your ticket system or printed. It contains blanks for the scenario, approvals, custody result, sign-in result, read-only check, alert evidence and corrective actions. Store the completed version in your business's restricted documentation system. It does not ask for passwords, recovery codes, key PINs or customer data.
A labelled example, not a customer result
Imagine the operator signs in successfully but the observer cannot locate the notification because it went only to the unavailable administrator's mailbox. Record "access demonstrated; notification outcome not accepted". The corrective action is to review notification ownership and rerun that part of the drill. Do not claim the recovery arrangement is ready because the login worked.
This is a hypothetical teaching example. The supplied procedure has not been executed against your tenant, and it contains no claimed recovery-time benchmark.
Read the result as evidence, not a score
- Demonstrated: the approved step was completed and its evidence was observed.
- Not demonstrated: the step failed, could not be attempted safely or lacks evidence.
- Out of scope: the scenario did not test it, such as internet loss or Microsoft service availability.
Revisit the drill when custodians, authentication methods, devices or policies change, as well as on the documented review schedule. Record the next due date and who owns it. A successful exercise is evidence of the conditions tested on that date, not a guarantee of future access.
Fit the drill into the rest of your IT plan
The Microsoft 365 security baseline covers the wider configuration review. For an employee departure, use the separate offboarding handoff and acceptance record.
Use your disaster-recovery plan to identify wider dependencies, the MSP exit checklist to clarify customer ownership, and recovery testing guidance for business-data restoration. These solve related problems but do not replace an administrator-access drill.
If you need help reviewing the actual configuration, see managed Microsoft 365 support or contact North Star. Keep account identifiers and credentials out of public contact forms.