Top 10 Entra ID Security Risks: Where Tenants Break and How to Fix Them

Microsoft Entra ID is the front door to Microsoft 365, Azure and thousands of connected SaaS apps, so getting directory settings right protects everywhere it signs people and workloads in. This list ranks the ten Entra ID risks that most often turn a phished user, a forgotten app secret or a compromised on-premises server into control of the tenant, with how to check for each, what to alert on and how to fix it. The ranking is an editorial judgement based on Microsoft's own Entra documentation and its security operations guides. It is written for identity engineers, Microsoft 365 and Azure administrators and the security leads who own them. For the full control set, read the Entra ID Security Guide; for tenant-wide Microsoft 365 settings such as mail forwarding and SharePoint sharing, see the Top 10 Microsoft 365 Security Misconfigurations.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Privilege is the first thing to cut. Microsoft recommends fewer than five Global Administrators and just-in-time activation through Privileged Identity Management (PIM) instead of standing roles.
• Conditional Access is only as strong as its exclusions. Microsoft's security operations guidance treats any account exempt from Conditional Access as high risk, apart from emergency access accounts.
• MFA at sign-in does not stop token theft. Device-bound tokens, Token Protection and blocking device code flow close the gaps that adversary-in-the-middle phishing and token replay exploit.
• Applications are identities too. Client secrets, broad Graph permissions and unmonitored credential additions give attackers persistence that survives password resets.
• Hybrid links carry on-premises risk into the cloud. Microsoft says the Entra Connect server must be treated as a Tier 0 (Control Plane) asset and that privileged cloud roles should use cloud-only accounts.

The Top 10 at a glance

1. Standing privileged roles and too many Global Administrators

Microsoft's best practices for Entra roles recommend assigning Global Administrator to fewer than five people, and the Entra overview page shows an alert card when there are five or more. They also recommend PIM so that users are eligible for a role and activate it only when needed, with access reviews to remove assignments no longer required. Attackers who gain a role assign more roles to keep access (ATT&CK T1098.003 Additional Cloud Roles).

• Check: the Roles and administrators page filtered on the Privileged label, counting active (not eligible) assignments, including role-assignable groups and service principals.
• Detect: audit log Category "Role management" with Activity "Add member to role" or "Add eligible member (permanent)" outside a change ticket.
• Fix: convert standing assignments to PIM eligible with approval and MFA on activation, prefer least-privileged roles such as User Administrator over Global Administrator, and schedule quarterly access reviews of privileged roles. See the Privileged Identity Management (PIM) Guide.

2. Conditional Access gaps and broad exclusions

Conditional Access policies are a set of include and exclude lists for users, apps, platforms, locations and client types, and every exclusion is a path around the policy. Microsoft's guidance for monitoring privileged accounts rates "Accounts exempt from Conditional Access" as high severity, noting that any account exempt is most likely bypassing security controls, with emergency access accounts the only expected exception. Common gaps are exclusions added during a migration that were never removed, policies scoped to selected apps instead of all resources, and policies left in report-only mode indefinitely.

• Check: export every policy and list excluded users, groups, roles and apps; use Conditional Access insights and reporting and the What If tool to test a sample of users.
• Detect: sign-in logs where Conditional Access status is "notApplied" for interactive sign-ins, and audit events that update a policy or add members to an exclusion group.
• Fix: build baseline policies (require MFA for all users and all resources, block legacy authentication, protect security info registration), keep exclusions in named groups with owners and access reviews, and move each new policy through report-only to On with a dated plan.

3. Legacy authentication still allowed

Legacy protocols such as POP, IMAP and older Exchange ActiveSync clients cannot perform MFA. Microsoft's Conditional Access documentation states that, by its analysis, more than 97% of credential stuffing attacks and more than 99% of password spray attacks use legacy authentication (ATT&CK T1110.003 Password Spraying, T1110.004 Credential Stuffing). Tenants without Conditional Access licences can block it with security defaults.

• Check: sign-in logs filtered on client app "Other clients" and the legacy protocol types for the last 30 days, to find the devices and service accounts that still depend on them.
• Fix: deploy the block legacy authentication policy in report-only first, migrate the remaining clients and scanners to modern authentication, then switch the policy On. For mail relays, see the Exchange Online SMTP AUTH Basic Auth Retirement.

4. Phishable MFA and token replay

Push notifications, SMS and one-time codes can all be relayed by adversary-in-the-middle (AiTM) phishing kits, which capture the session tokens issued after MFA succeeds. Microsoft's guidance on protecting tokens describes two goals: prevent theft, and block replay or reduce its impact. A Primary Refresh Token (PRT) is valid for 90 days and continuously renewed while the device is used, and on devices with a working TPM its keys are bound to the device. Token Protection is a Conditional Access session control that accepts only device-bound sign-in session tokens from supported applications, so a stolen token cannot be used from another device. See the AiTM Phishing Guide and the Entra ID PRT Security Guide.

• Detect: Identity Protection risk detections for unfamiliar sign-in properties and anomalous token use, MFA fatigue patterns (ATT&CK T1621), and the same session appearing from two networks.
• Fix: use authentication strengths to require passkeys, Windows Hello for Business or certificate-based authentication for administrators first and then all users; require compliant or registered devices for sensitive apps; pilot Token Protection on supported Windows clients; and require phishing-resistant re-authentication through authentication context for sensitive actions.

5. Device code flow left open

Device code flow lets users sign in on devices with no keyboard or browser by entering a code on another device. Microsoft's documentation calls it a high-risk authentication method that can be part of a phishing attack, and recommends blocking it wherever possible. Attackers send a lure with a genuine Microsoft code page; the victim signs in and the attacker's session receives the tokens. See the Device Code Phishing Guide.

• Check: sign-in logs filtered on authentication protocol "deviceCode" to find the genuine users, usually meeting room devices and some command-line tools.
• Fix: create a Conditional Access policy using the authentication flows condition to block device code flow for all users, with a named exception group for the devices that need it, restricted by location or device filter. Review authentication transfer at the same time.

6. Permissive user consent

If any user can consent to any application, a phishing link to a malicious app can grant it access to mail and files without a password ever being stolen. Microsoft recommends allowing user consent only for apps from verified publishers, and only for permissions classified as low impact, with the admin consent workflow so users can request review of anything else. We recommend using permission classification alongside the verified publisher setting. See the Consent Phishing and Illicit OAuth Grants Guide.

• Detect: audit log "Consent to application" events, especially for permissions such as Mail.Read, Files.Read.All or offline_access, and consent stopped by risk-based step-up.
• Fix: set user consent to verified publishers with selected low-impact permissions, enable the admin consent workflow with named reviewers, and review existing delegated grants. See the Entra ID Applications and Consent Guide.

7. Application and service principal credential sprawl

Client secrets are passwords for applications: they work from anywhere, rarely expire quickly and are often copied into code and pipelines. Microsoft's application monitoring guidance recommends X.509 certificates from trusted authorities or managed identities instead of client secrets, replacing long-lived credentials with short ones, and alerting on credentials added outside normal workflows (ATT&CK T1098.001 Additional Cloud Credentials). Workload identity federation lets external workloads such as CI/CD pipelines exchange their own tokens for Entra tokens without any stored secret. Conditional Access for workload identities can restrict single-tenant service principals by location and risk; it needs Workload Identities Premium licences and does not cover managed identities or multitenant SaaS apps.

• Check: list app registrations and service principals with password credentials, their expiry dates and last sign-in. See How to find expiring app secrets and certificates in Entra ID and How to find and remove stale service principals in Entra ID.
• Detect: audit Activity "Update application: Certificates and secrets management" and "Update service principal" outside change windows, and service principal sign-ins from unexpected IP ranges.
• Fix: move Azure-hosted workloads to managed identities, pipelines to workload identity federation, and everything else to certificates with short lifetimes; set app management policies that restrict secret lifetime. See the Azure Entra Client Secrets Security Guide.

8. Over-privileged applications and application administrators

Some Microsoft Graph application permissions, such as those that manage role assignments or app role assignments, let an application grant itself or others more privilege. Entra labels such roles and permissions as Privileged (the label is in preview), describing them as able to delegate management, modify credentials or policies, or access restricted data. People who can manage applications, including application owners and the Application Administrator and Cloud Application Administrator roles, can add credentials to an application and then act with its permissions. Review test tenants and their applications too.

• Check: filter app role assignments for permissions with the Privileged label, list owners on every high-privilege app, and count who holds application management roles.
• Detect: "Add app role assignment to service principal" for privileged Graph permissions, and "Add owner to application" events.
• Fix: remove unused application permissions, replace tenant-wide permissions with scoped alternatives where they exist, remove individual owners from privileged apps, and treat application management roles as privileged roles under PIM.

9. Hybrid trust: synced admins, sync server and federation

Microsoft's guidance on protecting Microsoft 365 from on-premises attacks names federation trust and account synchronisation as the two main threat vectors: a stolen SAML token-signing certificate lets an attacker impersonate any user (ATT&CK T1606.002 SAML Tokens), and a compromised sync path can change cloud identities (T1556.007 Hybrid Identity). It recommends cloud-only accounts for privileged roles and retiring on-premises federation in favour of Entra authentication. The Entra Connect prerequisites state that the Entra Connect server must be treated as a Tier 0 component and hardened as a Control Plane asset, with administrative access restricted to tightly controlled groups. The Hybrid Identity Administrator role is needed only during installation. See the Microsoft Entra Connect and Cloud Sync Hardening Guide and AD FS to Entra ID Migration.

• Check: list holders of privileged Entra roles whose accounts are synchronised from Active Directory, and who can log on to the sync server.
• Detect: changes to federation settings or domain authentication, new Entra Connect installations, and Entra Connect Health alerts.
• Fix: create cloud-only admin accounts on the tenant domain, protect the sync server as Tier 0, and plan migration from federation to cloud authentication.

10. Untested emergency access and unwatched audit logs

Microsoft recommends two or more emergency access accounts: cloud-only, on the *.onmicrosoft.com domain, not federated or synchronised, using a phishing-resistant method such as a FIDO2 passkey that differs from normal admin methods, and excluded from Conditional Access policies that block or restrict sign-in. Its security operations guide says to send a high-priority alert every time an emergency access account is used or changed, because normal monitoring should show no activity. The same guide lists other high-value alerts, such as a Temporary Access Pass added to a privileged account and a user changed from Guest to Member.

• Check: sign in with each emergency account at least twice a year under a controlled procedure, and confirm the alert fires.
• Fix: stream sign-in and audit logs to a SIEM with retention that meets your investigation needs, and build the alerts in the detection table below. See the Entra ID Sign-In and Audit Log Detection Guide.

Detection: what to alert on

Measures that show progress: number of active (non-PIM) privileged role assignments; Global Administrator count; percentage of users covered by a phishing-resistant authentication strength; legacy authentication sign-ins per week (target zero); count of application password credentials and their median lifetime; and percentage of privileged accounts that are cloud-only.

Common failure patterns

• Exclusion groups nobody owns: a temporary exclusion for a migration or a VIP stays for years and becomes the route attackers use.
• MFA counted as done: registering everyone for push MFA leaves AiTM and token replay open; method strength and device binding are what matter.
• App secrets created by default: developers pick client secrets because they are quickest, and the 24-month secret outlives the project.
• Self-service reset and push approval left open to social engineering: a known attack pattern starts self-service password resets and, posing as IT support, persuaded users to approve the MFA prompts, then replaced their methods with its own Authenticator.
• Synced Domain Admins with cloud roles: the on-premises compromise path leads straight to Global Administrator.
• Break-glass accounts that fail: accounts caught by a compliant-device policy, or whose security key is lost, cannot be used in the outage they exist for.

Mapping to ATT&CK and NIST

Where to start

1. Day 1: confirm two working emergency access accounts and an alert on their use, so later changes cannot lock you out.
2. Week 1: deploy block legacy authentication and block device code flow in report-only, review the impact for seven days, then turn them On with a documented rollback (set the policy back to report-only).
3. Week 2: cut Global Administrators below five and move remaining privileged roles to PIM eligible.
4. Month 1: restrict user consent to verified publishers with low-impact permissions and enable the admin consent workflow; inventory application secrets.
5. Month 2 onwards: roll out phishing-resistant authentication strengths starting with administrators, convert privileged accounts to cloud-only, and harden the Entra Connect server as Tier 0.

Practitioner checklist

• Fewer than five Global Administrators, all cloud-only and on phishing-resistant MFA.
• All other privileged roles are PIM eligible with approval or justification.
• Every Conditional Access exclusion sits in an owned group with a periodic review.
• Legacy authentication and device code flow blocked except for named exceptions.
• Authentication strength policies require phishing-resistant methods for administrators.
• User consent limited to verified publishers and low-impact permissions, with admin consent workflow on.
• No application client secret older than your policy limit; managed identities or federation used where possible.
• Privileged Graph permissions and application owners reviewed quarterly.
• Entra Connect server managed as Tier 0 with restricted logon.
• Sign-in and audit logs streamed to a SIEM with the alerts above tested.

Standards and references

• Microsoft Learn: Best practices for Microsoft Entra roles
• Microsoft Learn: Manage emergency access admin accounts in Microsoft Entra ID
• Microsoft Learn: Block legacy authentication with Conditional Access
• Microsoft Learn: Authentication flows in Conditional Access
• Microsoft Learn: Token Protection in Microsoft Entra Conditional Access
• Microsoft Learn: Configure how users consent to applications
• Microsoft Learn: Protect Microsoft 365 from on-premises attacks
• Microsoft Learn: Microsoft Entra security operations guide for applications

Related NHI Mgmt Group resources: Entra ID Security Guide, Active Directory and Entra ID Hardening Guide, Top 10 Microsoft 365 Security Misconfigurations, Top 10 NHI Risks.