Azure Identity Security: Why MFA Alone Is Not Enough

What Is Azure Identity Security?

Azure identity security is the control set that protects Microsoft Entra ID accounts, privileged roles, authentication methods, application access, and administrative sessions across Microsoft 365, Azure, and connected SaaS applications. It is the front door to the tenant. If the identity layer is weak, an attacker may not need a server exploit; a stolen password, a phishable authentication flow, a weak exception, or a privileged session can be enough.

MFA is part of the answer, but MFA alone is not a complete Azure identity security strategy. A tenant also needs Conditional Access coverage, strong authentication methods for privileged roles, risk-based response, emergency access controls, application governance, and validation that policies actually apply to real sign-ins.

The two baseline failures that show up repeatedly are simple:

• privileged accounts without enforced strong authentication
• Security Defaults disabled without equivalent Conditional Access coverage

Those failures create a gap between what administrators believe is protected and what Microsoft Entra ID actually enforces.

---

Security Defaults vs Conditional Access

Security Defaults are Microsoft's built-in baseline protections for organizations that need a simple starting point. Microsoft documentation describes Security Defaults as appropriate for organizations that want to improve security but do not know where to start, and for organizations using the free tier of Microsoft Entra ID.

Security Defaults can require users to register for multifactor authentication, require MFA for privileged Azure management actions, and help block legacy authentication. They are intentionally simple and not customizable.

Conditional Access is the more flexible policy engine. Organizations with Microsoft Entra ID P1 or P2 licensing and more complex requirements usually need Conditional Access for application targeting, device state, locations, risk conditions, authentication strengths, session controls, and scoped exceptions.

The dangerous state is the transition gap: Security Defaults are disabled, but Conditional Access does not yet provide equivalent or stronger protection. Microsoft guidance for moving away from Security Defaults says organizations should immediately enable Conditional Access policies to protect the organization after disabling Security Defaults.

---

Why MFA Alone Is Not Enough

MFA improves resistance to password-only compromise, but not all MFA methods provide the same level of protection. A tenant can still be exposed if:

• administrators are excluded from MFA because of emergency troubleshooting
• Conditional Access applies only to selected applications while admin portals remain reachable
• privileged users use phishable methods where stronger methods are feasible
• break-glass accounts exist but are not monitored on every sign-in
• legacy authentication or older clients remain available for some workflows
• authentication method registration and recovery are weakly controlled
• sessions and refresh tokens remain valid after a risky event

Microsoft Entra authentication strengths exist because method strength matters. A Conditional Access authentication strength can require specific method combinations, including phishing-resistant options such as passkeys/FIDO2 security keys or certificate-based authentication where deployed and supported.

---

The Attack Chain

Step 1 - Find the Weak Identity Path

An attacker looks for accounts that can authenticate without strong controls: admin accounts without MFA, accounts excluded from Conditional Access, stale accounts, unmonitored emergency accounts, or applications with broad permissions.

Step 2 - Get a Valid Credential or Session

The initial access might come from password reuse, credential phishing, token theft, help-desk abuse, or a compromised device. The exact technique varies, but the identity control question is the same: does the tenant require a stronger authentication method, a compliant device, a low-risk sign-in, or an approved admin path before access is granted?

Step 3 - Reach an Administrative Surface

If the account can reach Azure portal, Microsoft Entra admin center, Microsoft 365 admin portals, Microsoft Graph, or PowerShell without the intended controls, the tenant has an effective-policy gap.

Step 4 - Preserve Access

Once inside, the attacker may attempt to add an authentication method, create a new user, assign a role, register an application, add a credential to a service principal, or weaken a Conditional Access policy. Those actions should be treated as high-signal audit events for privileged identities.

---

Detection

Sign-in and Policy Signals

Review Microsoft Entra sign-in logs and Conditional Access results for:

• successful privileged sign-ins where MFA was not required but should have been
• sign-ins where the authentication method does not satisfy the expected strength
• admin access from unmanaged devices or unexpected locations
• medium or high-risk sign-ins that completed successfully
• repeated failures followed by success for an admin account
• sign-ins by emergency accounts
• legacy client or protocol usage where it should be blocked

Audit Log Signals

Monitor tenant changes that can weaken identity controls:

Detection Caveats

Do not alert only on the existence of MFA. Alert on effective outcomes. The question is not “does the tenant have an MFA policy?” The question is “did this sign-in to this resource by this identity satisfy the required control?” Conditional Access results, authentication details, risk level, user role, app, device, and location all matter.

---

Remediation

The safe baseline is either Security Defaults for simple tenants or a complete Conditional Access design for more complex tenants. Leaving both absent is the avoidable failure.

1. Re-enable Security Defaults or Replace Them Immediately

If the tenant does not have a mature Conditional Access design, enable Security Defaults. If the organization uses Conditional Access, document the replacement baseline before disabling Security Defaults and test it against real sign-in scenarios.

At minimum, the replacement design should cover privileged users, Azure management, Microsoft 365 admin surfaces, risky sign-ins, and legacy authentication exposure.

2. Require Strong Authentication for Privileged Roles

For normal privileged users, require MFA and consider stronger methods for the most sensitive roles. Use Conditional Access authentication strengths to require phishing-resistant methods where the environment supports them.

Common high-value role populations include:

• Global Administrator
• Privileged Role Administrator
• Conditional Access Administrator
• Security Administrator
• Application Administrator
• Cloud Application Administrator
• Exchange Administrator and SharePoint Administrator in Microsoft 365-heavy tenants

3. Manage Emergency Access Accounts Separately

Emergency accounts are necessary for resilience. Microsoft recommends two or more cloud-only emergency access accounts. These accounts should not be used as everyday admin identities, and their control design should avoid dependencies that could fail during the emergency they are meant to solve.

Protect them with phishing-resistant authentication where possible, store credentials securely, exclude only where necessary, alert on every sign-in, and test them regularly. If an emergency account signs in, the security team should know.

4. Remove Unnecessary Exceptions

Review every excluded user, group, location, app, and device condition in Conditional Access. Exceptions created during troubleshooting often become permanent. Each exception should have an owner, reason, expiration date or review cadence, and compensating monitoring.

5. Pair Identity Security With Risk Response

Security Defaults and MFA are not substitutes for risk-based response in larger tenants. Use Microsoft Entra ID Protection and Conditional Access risk conditions to require step-up authentication, reauthentication, password change, or blocking when risk is detected.

---

Validation After Policy Changes

Validate the effective policy path instead of trusting configuration screenshots:

• test a privileged user sign-in to Azure portal and confirm the expected control is required
• test a privileged user sign-in to Microsoft Graph or PowerShell where relevant
• confirm the same account is not excluded through another group, location, app, or device condition
• review sign-in logs to confirm Conditional Access result and authentication method details
• validate emergency account alerting by reviewing the alert path, not by assuming it exists
• review risky sign-ins and confirm risk-based policies would apply
• confirm legacy authentication is blocked where Security Defaults or Conditional Access should block it
• check whether authentication strength requirements are satisfied by the intended methods only

A control that exists but does not apply to the sign-ins attackers can use is not an identity security control.

---

How EtcSec Detects This

EtcSec audits Azure identity controls on every tenant scan.

MFA_NOT_ENFORCED_ADMINS identifies privileged accounts that do not have effective MFA protection.

AZ_SECURITY_DEFAULTS_DISABLED highlights tenants where Security Defaults are off and no equivalent baseline is in place.

CA_NO_MFA_REQUIREMENT surfaces Conditional Access designs that still leave critical authentication paths without MFA enforcement.

The meaningful question is not whether a tenant has policies on paper. It is whether privileged sign-ins actually face the intended controls and whether risky sessions trigger a response.

Related Controls

This control should be reviewed alongside Azure Identity Protection: Blocking Leaked Credentials, Azure Privileged Access: Too Many Global Admins, Azure Tenant Hardening: Fix Insecure Default Settings, Azure Guest Accounts: The Forgotten Attack Surface in Your Tenant, and Azure App Registrations: Over-Privileged Tenant Apps. Weak MFA posture becomes much worse when the same tenant also has standing admin privilege, broad guest access, risky applications, or weak risk-based response.

Primary References

• Configure Security Defaults for Microsoft Entra ID
• Microsoft Entra Conditional Access overview
• How authentication strengths work in Conditional Access
• Custom Conditional Access authentication strengths
• Manage emergency access accounts in Microsoft Entra ID
• Configure and enable Microsoft Entra ID Protection risk policies