{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/microsoft-entra-emergency-access-accounts-readiness/", "item": { "id": "https://update.dsesecurity.com/updates/microsoft-entra-emergency-access-accounts-readiness/", "slug": "microsoft-entra-emergency-access-accounts-readiness", "url": "https://update.dsesecurity.com/updates/microsoft-entra-emergency-access-accounts-readiness/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/microsoft-entra-emergency-access-accounts-readiness.md", "json": "https://update.dsesecurity.com/api/v1/posts/microsoft-entra-emergency-access-accounts-readiness/" }, "title": "Keep two emergency Microsoft Entra accounts ready before the tenant needs them", "summary": "Emergency access accounts provide a recovery path when normal administrators cannot sign in or activate a role. They must be independent, strongly protected, monitored, and tested without becoming everyday admin accounts.", "format": { "slug": "checklist", "name": "Checklist" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-07-19T21:27:53+00:00", "modified_at": "2026-07-19T21:27:53+00:00", "reviewed_on": "2026-07-19", "reading_minutes": 3, "word_count": 452, "potentially_affected": "Microsoft Entra tenants, especially organizations that use federation, Conditional Access, Privileged Identity Management, multifactor authentication, or a small administrator team.", "dse_recommendation": "Maintain at least two cloud-only emergency accounts, protect them with independent phishing-resistant credentials, exclude them from blocking access policies, alert on use, and validate them every 90 days.", "primary_source": { "name": "Microsoft Learn: Manage emergency access accounts in Microsoft Entra ID", "url": "https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access", "published_on": "2026-06-05", "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source fact: what Microsoft documents

\n

Microsoft recommends maintaining two or more emergency access accounts for situations in which ordinary administrators cannot sign in or activate a required role. Examples include an unavailable federated identity provider, inaccessible multifactor devices, an approval chain with no available approver, or an accidental tenant-wide lockout. These accounts are highly privileged and are intended only for planned validation or a real emergency.

\n

The current Microsoft guidance says the accounts should be cloud-only, use the tenant’s .onmicrosoft.com domain, and have a permanent active Global Administrator assignment rather than an eligible assignment in Privileged Identity Management. Microsoft recommends phishing-resistant authentication with passkeys (FIDO2) or certificate-based authentication, credentials that do not share the same dependency as normal administrators, and designated secure workstations. Accounts should be excluded from Conditional Access policies that can block or restrict sign-in. Report-only policies do not block access and do not require that exclusion.

\n

Microsoft also recommends alerting on every sign-in and audit event, keeping credentials in separate secure locations, reviewing every use, and validating account functionality at least every 90 days. A validation should prove that the account can sign in and perform an administrative task and that monitoring generates the expected notification.

\n

Applicability and cautions

\n

These recommendations apply to Microsoft Entra tenants, but the exact credential, alerting, workstation, storage, and approval design depends on the organization. Azure Monitor, Microsoft Sentinel, secure hardware, certificate infrastructure, or other components can introduce separate licensing and operational requirements. Emergency accounts must not be connected to employee-supplied devices or used as convenient secondary administrator identities.

\n

DSE recommendation: production-safe operational steps

\n
    \n
  1. Inventory existing emergency accounts, their object IDs, assigned roles, authentication methods, owners, storage locations, and policy exclusions.
    2. \n
  2. Create at least two cloud-only accounts if the tenant does not already have them. Use non-personal naming that does not expose a password or recovery detail.
    3. \n
  3. Register independent phishing-resistant credentials and store the credentials in separate, access-controlled locations available to more than one authorized custodian.
    4. \n
  4. Confirm permanent active Global Administrator assignment and exclude the accounts from every policy that could make them unusable during the failure scenario they address.
    5. \n
  5. Configure alerts for sign-in and audit activity, document authorized-use criteria, and require a post-use review.
    6. \n
  6. Run a witnessed drill at least every 90 days and after material administrator, authentication, federation, or Conditional Access changes.
    7. \n
\n

DSE recommends recording the date, tester, observed alerts, administrative action, and any corrective work for each drill. Stop the test after the minimum administrative validation; do not use an emergency account for routine maintenance. If a test fails, treat the recovery design as unavailable until the cause is corrected and independently retested.

\n

Official reference

\n

Manage emergency access accounts in Microsoft Entra ID — account design, authentication, Conditional Access, monitoring, and validation guidance.

", "content_text": "Source fact: what Microsoft documents\nMicrosoft recommends maintaining two or more emergency access accounts for situations in which ordinary administrators cannot sign in or activate a required role. Examples include an unavailable federated identity provider, inaccessible multifactor devices, an approval chain with no available approver, or an accidental tenant-wide lockout. These accounts are highly privileged and are intended only for planned validation or a real emergency.\nThe current Microsoft guidance says the accounts should be cloud-only, use the tenant’s .onmicrosoft.com domain, and have a permanent active Global Administrator assignment rather than an eligible assignment in Privileged Identity Management. Microsoft recommends phishing-resistant authentication with passkeys (FIDO2) or certificate-based authentication, credentials that do not share the same dependency as normal administrators, and designated secure workstations. Accounts should be excluded from Conditional Access policies that can block or restrict sign-in. Report-only policies do not block access and do not require that exclusion.\nMicrosoft also recommends alerting on every sign-in and audit event, keeping credentials in separate secure locations, reviewing every use, and validating account functionality at least every 90 days. A validation should prove that the account can sign in and perform an administrative task and that monitoring generates the expected notification.\nApplicability and cautions\nThese recommendations apply to Microsoft Entra tenants, but the exact credential, alerting, workstation, storage, and approval design depends on the organization. Azure Monitor, Microsoft Sentinel, secure hardware, certificate infrastructure, or other components can introduce separate licensing and operational requirements. Emergency accounts must not be connected to employee-supplied devices or used as convenient secondary administrator identities.\nDSE recommendation: production-safe operational steps\n\nInventory existing emergency accounts, their object IDs, assigned roles, authentication methods, owners, storage locations, and policy exclusions.\nCreate at least two cloud-only accounts if the tenant does not already have them. Use non-personal naming that does not expose a password or recovery detail.\nRegister independent phishing-resistant credentials and store the credentials in separate, access-controlled locations available to more than one authorized custodian.\nConfirm permanent active Global Administrator assignment and exclude the accounts from every policy that could make them unusable during the failure scenario they address.\nConfigure alerts for sign-in and audit activity, document authorized-use criteria, and require a post-use review.\nRun a witnessed drill at least every 90 days and after material administrator, authentication, federation, or Conditional Access changes.\n\nDSE recommends recording the date, tester, observed alerts, administrative action, and any corrective work for each drill. Stop the test after the minimum administrative validation; do not use an emergency account for routine maintenance. If a test fails, treat the recovery design as unavailable until the cause is corrected and independently retested.\nOfficial reference\nManage emergency access accounts in Microsoft Entra ID — account design, authentication, Conditional Access, monitoring, and validation guidance.", "content_markdown": "## Source fact: what Microsoft documents\n\nMicrosoft recommends maintaining two or more emergency access accounts for situations in which ordinary administrators cannot sign in or activate a required role. Examples include an unavailable federated identity provider, inaccessible multifactor devices, an approval chain with no available approver, or an accidental tenant-wide lockout. These accounts are highly privileged and are intended only for planned validation or a real emergency.\n\nThe current Microsoft guidance says the accounts should be cloud-only, use the tenant’s .onmicrosoft.com domain, and have a permanent active Global Administrator assignment rather than an eligible assignment in Privileged Identity Management. Microsoft recommends phishing-resistant authentication with passkeys (FIDO2) or certificate-based authentication, credentials that do not share the same dependency as normal administrators, and designated secure workstations. Accounts should be excluded from Conditional Access policies that can block or restrict sign-in. Report-only policies do not block access and do not require that exclusion.\n\nMicrosoft also recommends alerting on every sign-in and audit event, keeping credentials in separate secure locations, reviewing every use, and validating account functionality at least every 90 days. A validation should prove that the account can sign in and perform an administrative task and that monitoring generates the expected notification.\n\n## Applicability and cautions\n\nThese recommendations apply to Microsoft Entra tenants, but the exact credential, alerting, workstation, storage, and approval design depends on the organization. Azure Monitor, Microsoft Sentinel, secure hardware, certificate infrastructure, or other components can introduce separate licensing and operational requirements. Emergency accounts must not be connected to employee-supplied devices or used as convenient secondary administrator identities.\n\n## DSE recommendation: production-safe operational steps\n\n- Inventory existing emergency accounts, their object IDs, assigned roles, authentication methods, owners, storage locations, and policy exclusions.\n\n- Create at least two cloud-only accounts if the tenant does not already have them. Use non-personal naming that does not expose a password or recovery detail.\n\n- Register independent phishing-resistant credentials and store the credentials in separate, access-controlled locations available to more than one authorized custodian.\n\n- Confirm permanent active Global Administrator assignment and exclude the accounts from every policy that could make them unusable during the failure scenario they address.\n\n- Configure alerts for sign-in and audit activity, document authorized-use criteria, and require a post-use review.\n\n- Run a witnessed drill at least every 90 days and after material administrator, authentication, federation, or Conditional Access changes.\n\nDSE recommends recording the date, tester, observed alerts, administrative action, and any corrective work for each drill. Stop the test after the minimum administrative validation; do not use an emergency account for routine maintenance. If a test fails, treat the recovery design as unavailable until the cause is corrected and independently retested.\n\n## Official reference\n\n[Manage emergency access accounts in Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access) — account design, authentication, Conditional Access, monitoring, and validation guidance." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo.png" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/microsoft-entra-emergency-access-accounts-readiness/", "url": "https://update.dsesecurity.com/updates/microsoft-entra-emergency-access-accounts-readiness/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-07-19" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/microsoft-entra-emergency-access-accounts-readiness/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Keep two emergency Microsoft Entra accounts ready before the tenant needs them", "item": "https://update.dsesecurity.com/updates/microsoft-entra-emergency-access-accounts-readiness/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/microsoft-entra-emergency-access-accounts-readiness/#article", "identifier": "https://update.dsesecurity.com/updates/microsoft-entra-emergency-access-accounts-readiness/", "url": "https://update.dsesecurity.com/updates/microsoft-entra-emergency-access-accounts-readiness/", "headline": "Keep two emergency Microsoft Entra accounts ready before the tenant needs them", "description": "Emergency access accounts provide a recovery path when normal administrators cannot sign in or activate a role. They must be independent, strongly…", "abstract": "Emergency access accounts provide a recovery path when normal administrators cannot sign in or activate a role. They must be independent, strongly protected, monitored, and tested without becoming everyday admin accounts.", "articleBody": "Source fact: what Microsoft documents\nMicrosoft recommends maintaining two or more emergency access accounts for situations in which ordinary administrators cannot sign in or activate a required role. Examples include an unavailable federated identity provider, inaccessible multifactor devices, an approval chain with no available approver, or an accidental tenant-wide lockout. These accounts are highly privileged and are intended only for planned validation or a real emergency.\nThe current Microsoft guidance says the accounts should be cloud-only, use the tenant’s .onmicrosoft.com domain, and have a permanent active Global Administrator assignment rather than an eligible assignment in Privileged Identity Management. Microsoft recommends phishing-resistant authentication with passkeys (FIDO2) or certificate-based authentication, credentials that do not share the same dependency as normal administrators, and designated secure workstations. Accounts should be excluded from Conditional Access policies that can block or restrict sign-in. Report-only policies do not block access and do not require that exclusion.\nMicrosoft also recommends alerting on every sign-in and audit event, keeping credentials in separate secure locations, reviewing every use, and validating account functionality at least every 90 days. A validation should prove that the account can sign in and perform an administrative task and that monitoring generates the expected notification.\nApplicability and cautions\nThese recommendations apply to Microsoft Entra tenants, but the exact credential, alerting, workstation, storage, and approval design depends on the organization. Azure Monitor, Microsoft Sentinel, secure hardware, certificate infrastructure, or other components can introduce separate licensing and operational requirements. Emergency accounts must not be connected to employee-supplied devices or used as convenient secondary administrator identities.\nDSE recommendation: production-safe operational steps\n\nInventory existing emergency accounts, their object IDs, assigned roles, authentication methods, owners, storage locations, and policy exclusions.\nCreate at least two cloud-only accounts if the tenant does not already have them. Use non-personal naming that does not expose a password or recovery detail.\nRegister independent phishing-resistant credentials and store the credentials in separate, access-controlled locations available to more than one authorized custodian.\nConfirm permanent active Global Administrator assignment and exclude the accounts from every policy that could make them unusable during the failure scenario they address.\nConfigure alerts for sign-in and audit activity, document authorized-use criteria, and require a post-use review.\nRun a witnessed drill at least every 90 days and after material administrator, authentication, federation, or Conditional Access changes.\n\nDSE recommends recording the date, tester, observed alerts, administrative action, and any corrective work for each drill. Stop the test after the minimum administrative validation; do not use an emergency account for routine maintenance. If a test fails, treat the recovery design as unavailable until the cause is corrected and independently retested.\nOfficial reference\nManage emergency access accounts in Microsoft Entra ID — account design, authentication, Conditional Access, monitoring, and validation guidance.", "datePublished": "2026-07-19T21:27:53+00:00", "dateModified": "2026-07-19T21:27:53+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/microsoft-entra-emergency-access-accounts-readiness/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@id": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": "https://update.dsesecurity.com/assets/dse-updates-share.png", "articleSection": [ "Business Continuity", "Cybersecurity", "Microsoft 365 & Identity" ], "keywords": [ "Business Continuity", "Cybersecurity", "Microsoft 365 & Identity", "Checklist", "Important priority" ], "genre": "Checklist", "about": [ { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "wordCount": 452, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Microsoft Learn: Manage emergency access accounts in Microsoft Entra ID", "url": "https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access", "datePublished": "2026-06-05" } } ] } }