The 5 Entra ID Settings Every Admin Gets Wrong
- Derek Morgan
- 2 days ago
- 9 min read
In January 2024, the group Microsoft tracks as Midnight Blizzard read email from Microsoft's own senior staff. They got in through two Entra ID settings, both left in a default state. First, a password spray found a legacy test account with no multifactor authentication. Then they used an OAuth application that had standing access to mailboxes. (Source: Microsoft disclosure; Cloud Security Alliance analysis, 2025.)
Most identity compromise looks like that. A default someone never changed, or a temporary exception that became permanent.
Microsoft ships Entra ID defaults to get a tenant running on day one. Security is a separate set of decisions someone makes on purpose. The five settings below, plus one bonus, are the ones I still find at their default after an MFA rollout and a passed compliance audit. None of them throws an error. They sit quietly until someone uses them.
A quick licensing note: Conditional Access and authentication strengths need Entra ID P1, and PIM needs P2. If you hold Microsoft 365 E3 or E5, the entitlement for most of what follows is already there.
One change in 2026 is worth naming up front. Microsoft is closing some of these by default. SMTP AUTH basic authentication goes off by default for existing tenants at the end of December 2026, and mandatory multifactor authentication is rolling out across the admin portals through 2026. That moves the live risk to the residual case: the one service account still on a legacy protocol, the one admin still approving a push notification.
1. User consent to applications
By default, any user in your tenant can grant a third-party application permission to read their mail, their files, and a fair amount of directory data. They click Accept on a consent prompt and the app receives an OAuth token.
The attack is consent phishing. Microsoft documents it as the illicit consent grant attack. A user gets a link to an app with a harmless-sounding name. One click, and the attacker holds a token that reads mail or files through the API. That token does not ask for the password again. It does not trigger MFA. A password reset does not revoke it. This is the OAuth half of the Midnight Blizzard intrusion.
For the CISO: the scope of that incident is everything the consenting user could reach, and the access lasts until someone finds and revokes the grant. Detection is hard, because the app authenticates as the user through approved API paths.
The fix is two changes on one screen. Restrict user consent to apps from verified publishers, for low-impact permissions only. Then turn on the admin consent workflow, so a user requests an app and an admin approves it instead of granting access alone. In the Entra admin center: Enterprise applications, then Consent and permissions. If you find a bad grant after the fact, revoke the app's consent and its active sign-in sessions; a password reset alone leaves the token working.
2. Legacy authentication
Older protocols, including POP, IMAP, SMTP AUTH, and basic-auth ActiveSync, predate modern authentication. They cannot present an MFA challenge. A sign-in over one of these protocols with a valid username and password succeeds, MFA or not.
That makes legacy authentication the preferred channel for password spray and credential stuffing. Microsoft's own measurements: more than 99% of password spray attacks and more than 97% of credential stuffing attacks come in over legacy authentication, and organizations that block it record 67% fewer compromises.
Here is where it goes wrong. A team enables Security Defaults or writes a Conditional Access policy to block legacy auth, and calls it done. Then one service account doing SMTP relay, a conference-room device, or an old line-of-business app keeps a single protocol alive, and that account is the one an attacker finds.
For the CISO: every dollar spent on MFA is bypassable through the protocol still open. The control you paid for does not apply to the path the attacker uses.
The fix starts with looking. In the sign-in logs, filter by Client app and select the legacy protocols to see which accounts and apps still use them. Then build a Conditional Access policy that blocks legacy authentication, run it in report-only first, document the exceptions you find, and switch it on. Keep break-glass and service accounts excluded.
Microsoft is retiring much of this for you. Basic authentication for most Exchange Online protocols is already gone, and SMTP AUTH basic auth turns off by default for existing tenants at the end of December 2026. What remains is the Conditional Access policy nobody finished, and the Other clients box left unchecked.
3. Standing Global Administrators
Walk into most tenants and count the permanent Global Administrators. The number runs higher than people expect, and it often includes a service account, a former project's admin, and two or three people who needed the role once.
Every standing Global Admin is an identity that can take over the tenant, available 24 hours a day. Microsoft Entra Privileged Identity Management changes the arrangement. Instead of holding the role permanently, an admin is eligible for it and activates it when needed. Activation can require MFA, a written justification, and approval, and it expires after a set window. The role stays dormant until someone turns it on, and every activation is logged.
For the CISO: this is blast radius and dwell time. A standing admin account that gets phished is full tenant control with no friction. The same account, PIM-eligible, gives an attacker an empty role until they can also clear the activation requirements, and it leaves a trail when they try.
Microsoft recommends fewer than five permanent Global Administrators. With clients, I target a tighter line: the only accounts that hold the Global Administrator role permanently are the two cloud-only break-glass accounts. Every other admin works from least-privileged roles, or activates Global Administrator through PIM just-in-time, scoped to a specific task and expiring after a short window. In the Entra admin center: Roles and admins for the assignments, Privileged Identity Management to convert them.
4. Admin MFA strength
This one passes a checkbox audit. The admins have MFA, and the audit moves on.
The question the checkbox skips is which kind of MFA. SMS, voice, and Authenticator push each verify a second factor, and each can be defeated. Adversary-in-the-middle phishing kits such as Evilginx capture the session token after the user completes the push. Push bombing repeats the prompt until a tired user approves. SIM swapping moves the phone number to the attacker. The accounts that can disable every other control are often protected by the most bypassable factor.
Phishing-resistant methods close that gap. FIDO2 security keys and passkeys bind the sign-in to the device and the domain, so a proxied login fails. Microsoft enforces this through authentication strengths, a Conditional Access grant control that requires a specific class of method rather than any MFA at all.
For the CISO: MFA blocks more than 99.2% of account compromise attacks, and that number assumes the method survives a real phishing attempt. For administrators, the gap between a push notification and a passkey is the gap between slowing an attacker and stopping one.
The fix: enable FIDO2 and passkeys in the Authentication methods policy, then require phishing-resistant MFA for administrators through a Conditional Access authentication strength. Pilot it with one admin group first.
Mandatory MFA is rolling out across the Azure portal, the Entra admin center, and the other management surfaces through 2026, which closes the basic case of an admin with no MFA at all. The live decision now is the strength of the method.
5. Default user permissions
A standard user in a default tenant can do more than most admins assume. They can register applications. They can invite external guests. And they can read most of the directory: every user, group, role assignment, and membership.
None of that is a vulnerability by itself. Together, they lower the cost of an attacker's first move. One phished standard account becomes a map of the org chart, the groups, and who holds which role. That reconnaissance feeds the next step: a targeted consent-phish from setting #1, a believable impersonation, a password spray aimed at the accounts that matter.
For the CISO: the first compromised account should give up as little as possible. Default permissions hand over the directory.
The fix, scoped to what the business actually needs. Set Users can register applications to No, and route app creation through a request. Restrict guest invitations to admins or specific roles. Limit directory read where your applications can tolerate it. In the Entra admin center: Users, then User settings, and External Identities, then External collaboration settings. The Maester and EIDSCA community projects check these same toggles as standard tenant hardening.
Bonus: break-glass, the one you get wrong in both directions
The last one gets configured wrong in both directions, which is why it earns a spot.
A break-glass account, also called an emergency access account, is the way back in when normal authentication fails. Some tenants have none. Others have one and then catch it in the same Conditional Access policy that just locked everyone out, which defeats the point at the worst possible moment.
For the CISO: a single bad Conditional Access policy, or an outage at your MFA provider, can lock every administrator out of the tenant at once. Without a tested way back in, that becomes a tenant-wide outage measured in hours and a support escalation.
Microsoft's guidance: create two cloud-only accounts, exclude them from the Conditional Access policies that block or restrict sign-in, give them long unique passwords, monitor their sign-ins, and test them on a schedule. One 2026 wrinkle: under mandatory MFA, break-glass accounts now need a strong method too, so plan for FIDO2 or certificate-based authentication on them rather than dropping MFA entirely.
What good looks like
A client I worked with closed four of these over a phased engagement, not a single weekend. First, an admin consent workflow, so every application consent request runs through approval. Then a Conditional Access policy blocking legacy authentication, after a report-only period to find the service accounts that needed attention. Then PIM across all privileged and sensitive Entra roles. Then an authentication strength requiring phishing-resistant MFA for administrators.
The point for a CISO reading this: these are decisions you stage over quarters. Each one removed a specific path an attacker uses, and the steady progress mattered more than doing it all at once.
Audit these six today
Six checks, each one a place in the admin center you can open right now:
User consent. Enterprise applications, Consent and permissions. Verified publishers, low-impact permissions, admin consent workflow on.
Legacy authentication. Sign-in logs filtered by legacy client app, then a Conditional Access block policy. Confirm the Other clients condition.
Standing Global Admins. Roles and admins. Only the two break-glass accounts permanent, everything else least-privilege or short, task-scoped PIM.
Admin MFA strength. Authentication methods, plus a Conditional Access authentication strength. Phishing-resistant for every admin.
Default user permissions. Users, User settings. App registration off, guest invites restricted, directory read scoped.
Break-glass. Two cloud-only accounts, excluded from blocking policies, monitored, tested.
The pattern
Microsoft will not patch any of these six. Each is a configuration decision the tenant owner makes, and the default sits in the weaker position because it has to let you start working.
For a CISO deciding where the next security dollar goes: identity is the control plane for everything else, and the cheapest control available this quarter is the one you already own and have not set. Configure the settings before buying the next tool.
If you do one thing after reading this, pull your sign-in logs and filter for legacy authentication. It is the fastest way to learn whether the MFA you already deployed is actually in the path.
Are Your Entra ID Settings a Decision, or Just the Default?
Cloud Harbor Consulting partners with security architects and technical leadership teams to turn a tenant that passed its MFA rollout and compliance audit but still runs on insecure Entra ID defaults into a deliberately configured, licensing-aware baseline that closes each gap and leaves an audit trail. Schedule a conversation to walk your tenant against these six settings and pinpoint where open user consent, legacy authentication, standing Global Admin roles, or a missing break-glass account are leaving access open.
Comments