Azure Identity Security: Why MFA Alone Is Not Enough

What Is Azure Identity Security?

Azure Entra ID (formerly Azure AD) is the identity backbone for Microsoft 365, Azure, and thousands of SaaS applications. Every user, every admin, every automated process authenticates through it. When identity controls are misconfigured, attackers can bypass MFA, escalate privileges, and take over cloud environments with nothing more than a stolen password.

The two most critical Azure identity misconfigurations are MFA not enforced for administrators and Security Defaults disabled. Both represent a fundamental failure of the first line of defense — and both are trivially exploitable with off-the-shelf phishing kits.

How It Works

Azure identity security rests on two foundational controls:

MFA (Multi-Factor Authentication) requires a second factor — phone app, FIDO2 key, SMS — in addition to the password. Even if an attacker obtains a password via phishing or credential stuffing, MFA prevents authentication without the second factor.

Security Defaults are Microsoft's baseline security settings for Entra ID tenants — a pre-configured set of policies that enable MFA for admins, block legacy authentication, and require MFA for risky sign-ins. They are free, enabled by one toggle, and provide immediate uplift for tenants with no existing Conditional Access policies.

When neither is configured, any admin account is one phishing email away from full compromise.

The Attack Chain

Step 1 - Identify Admin Accounts Without MFA

Connect-MgGraph -Scopes "Directory.Read.All", "UserAuthenticationMethod.Read.All"

# List all admins with no MFA methods registered
$adminRoleIds = (Get-MgDirectoryRole | Where-Object DisplayName -match "Admin").Id
foreach ($roleId in $adminRoleIds) {
    Get-MgDirectoryRoleMember -DirectoryRoleId $roleId |
        ForEach-Object {
            $methods = Get-MgUserAuthenticationMethod -UserId $_.Id
            if ($methods.Count -le 1) {  # Only password, no MFA
                [PSCustomObject]@{
                    User = $_.AdditionalProperties.userPrincipalName
                    Role = $roleId
                    MFAMethods = $methods.Count
                }
            }
        }
}

Step 2 - Phish the Admin Account

Attackers use adversary-in-the-middle (AiTM) phishing proxies like Evilginx2 or Modlishka to intercept not just the password but the session cookie — bypassing even MFA-protected accounts:

# Evilginx2 — AiTM phishing for Microsoft 365
# Captures session tokens that bypass MFA entirely
# Requires: registered domain + SSL cert + Evilginx configured for O365 phishlet

For accounts without MFA, even a basic phishing page suffices.

Step 3 - Authenticate as Admin

With the stolen credential (or session token), the attacker authenticates to the Azure portal or Microsoft Graph:

# Using stolen session cookie — bypasses MFA entirely
# Import cookie into browser or use with API tools
curl -H "Authorization: Bearer {stolen_token}" https://graph.microsoft.com/v1.0/me

Step 4 - Establish Persistence

# Create backdoor Global Admin account
New-MgUser -DisplayName "IT Support" -UserPrincipalName "[email protected]" `
    -PasswordProfile @{Password="BackdoorP@ss123!"} -AccountEnabled $true

New-MgDirectoryRoleMemberByRef -DirectoryRoleId $globalAdminRoleId `
    -OdataId "https://graph.microsoft.com/v1.0/directoryObjects/$newUserId"

Detection

Microsoft Entra Sign-in Logs

SIEM Detection Query (Elastic KQL)

azure.signinlogs.properties.authentication_details.authentication_method: "Previously satisfied" AND
azure.signinlogs.properties.user_roles: "*Admin*" AND
azure.signinlogs.properties.risk_level_during_sign_in: ("high" OR "medium")

# Detect new Global Admin assignments
azure.auditlogs.operation_name: "Add member to role" AND
azure.auditlogs.properties.target_resources.modified_properties.new_value: "*Global Administrator*"

💡 Tip: Enable Microsoft Entra ID Identity Protection. It detects AiTM phishing, impossible travel, token anomalies, and other identity-based attack signals in real time — for free on P2 licenses.

Remediation

⚠️ Critical: Enable Security Defaults or Conditional Access MFA immediately. This is the single highest-impact action you can take for Azure identity security.

Option 1: Enable Security Defaults (No License Required)

Entra ID > Properties > Manage Security Defaults > Enable Security Defaults = Yes

Security Defaults enable:

• MFA required for all admins
• MFA required for all users during risky sign-ins
• Legacy authentication blocked
• MFA required for Azure management

⚠️ Note: Security Defaults and Conditional Access are mutually exclusive. If you have Conditional Access policies, use those instead.

Option 2: Conditional Access MFA (Recommended for P1/P2 Tenants)

Policy: Require MFA for All Admins
- Users: All users assigned to any admin role
- Cloud apps: All cloud apps
- Grant: Require MFA + Require compliant device

Enforce Phishing-Resistant MFA for Admins

For highest-value accounts, standard TOTP MFA can be bypassed by AiTM. Use phishing-resistant methods:

Entra ID > Authentication Methods > FIDO2 Security Keys = Enabled
Entra ID > Authentication Methods > Certificate-Based Authentication = Enabled

Conditional Access: Require authentication strength = Phishing-resistant MFA
(For Global Admin, Privileged Role Admin, Security Admin)

Enable Identity Protection

Entra ID > Security > Identity Protection:
- User risk policy: Medium and above → Require password change
- Sign-in risk policy: Medium and above → Require MFA

How EtcSec Detects This

EtcSec audits Azure identity security controls on every scan.

MFA_NOT_ENFORCED_ADMINS identifies admin accounts with no MFA methods registered — accounts that are one phishing email away from full tenant compromise.

AZ_SECURITY_DEFAULTS_DISABLED flags tenants where Security Defaults are off and no equivalent Conditional Access policies have been configured, indicating a fundamental identity security gap.

Both findings appear at the top of the EtcSec Azure report given their direct impact on tenant security.

ℹ️ Note: EtcSec audits Azure identity controls automatically. Run a free audit to see which admin accounts in your tenant lack MFA.

Review Priorities

Azure Identity Security: Why MFA Alone Is Not Enough should be handled as a real exposure inside your Entra ID and Azure tenant, not as a single isolated setting. Start by defining the review perimeter: which admins, guests, service principals, app registrations, policy exclusions, and break-glass accounts are affected, which business workflows depend on them, which privileges they expose, and which emergency exceptions were added over time. That scoping step prevents shallow remediation, because the technical symptom is often smaller than the operational blast radius. By documenting the full path from configuration to privilege, the team can prioritize changes that reduce risk quickly without breaking production access. This also creates a defensible baseline for later validation and gives leadership a clear explanation of why the issue matters now.

Adjacent Controls to Review

When attackers reach your Entra ID and Azure tenant, they rarely stop at the first weak point. Around Azure Identity Security: Why MFA Alone Is Not Enough, they normally test whether the exposed path can be chained with legacy authentication, weak guest governance, broad app consent, stale emergency accounts, and roles that were never reviewed. That means defenders should review not just the headline weakness but every nearby dependency that turns access into persistence or privilege escalation. Confirm which identities, roles, permissions, and trust assumptions can be reused by a motivated operator. If a fix closes only one object while leaving adjacent privilege paths untouched, the effective risk barely changes. A disciplined review of chaining opportunities is what turns this article topic into a practical hardening exercise rather than a one-time checkbox.

Evidence and Telemetry to Pull

A strong response to Azure Identity Security: Why MFA Alone Is Not Enough needs evidence that can be reviewed by both engineering and detection teams. Pull sign-in logs, audit logs, role assignment changes, consent events, application credential changes, and risky sign-in signals, compare recent changes with known maintenance windows, and isolate accounts or systems that changed behavior without a clear business reason. Use that evidence to answer three questions: when the risky path appeared, who can still use it, and whether similar exposure exists elsewhere in your Entra ID and Azure tenant. Good telemetry review also helps you separate inherited technical debt from active misuse. That distinction matters, because the remediation plan for stale misconfiguration is different from the plan for a path that already shows attacker-like activity or repeated policy exceptions.

Adjacent Weaknesses Worth Reviewing

Very few environments contain Azure Identity Security: Why MFA Alone Is Not Enough alone. In practice, the same tenant or directory segment often contains legacy authentication, weak guest governance, broad app consent, stale emergency accounts, and roles that were never reviewed, and those neighboring weaknesses decide whether the issue is merely noisy or truly critical. Review shared owners, inherited permissions, duplicated exceptions, and long-lived administrative shortcuts. Check whether the same team approved similar risky patterns in multiple places, because repeated decisions usually point to a process gap rather than a single technical bug. This broader review prevents partial cleanup and gives you a better chance of removing the entire attack path. It also improves audit readiness, because the final state is easier to explain and easier to monitor over time.

Remediation Order That Lowers Risk Fast

For Azure Identity Security: Why MFA Alone Is Not Enough, remediation should follow an order that reduces exposure before it chases perfection. First remove the easiest privilege expansion paths, then lock down the highest-value identities or objects, and only after that clean up secondary hygiene gaps. Use Conditional Access, PIM, least privilege, access reviews, application ownership checks, approval workflows, and strong MFA as the control set that defines the target state. Each change should have an owner, a rollback note, and a validation step. This prevents long projects from stalling after the first technical fix. If a full redesign is not immediately possible, document interim controls that reduce abuse potential today and schedule the structural work inside the next weekly operational review and monthly hardening review. The important point is measurable risk reduction, not cosmetic compliance.

Related Reading

Review this topic together with Azure Conditional Access: MFA Bypass With Stolen Passwords, Azure Identity Protection: Blocking Leaked Credentials, Azure Privileged Access: Too Many Global Admins, Azure Tenant Hardening: Fix Insecure Default Settings, and Azure Guest Accounts: The Forgotten Attack Surface in Your Tenant. Those adjacent posts show how the same identity weaknesses usually chain together in a real assessment instead of appearing as isolated findings.

• Azure Conditional Access: MFA Bypass With Stolen Passwords
• 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

Using those references keeps the remediation discussion focused on the full attack path rather than a single control gap.

What to Review After Strengthening MFA

A stronger MFA baseline only works when the surrounding access paths are reviewed at the same time. Confirm which emergency accounts remain excluded, which authentication methods are still phishable, whether legacy protocols can bypass the new policy set, and whether device or location exceptions have quietly expanded over time. It is also worth checking service desk workflows, because weak fallback procedures often reintroduce the same exposure through temporary bypasses or long-lived exception groups. When teams document those operational dependencies alongside the control change, they reduce the chance that MFA looks strong on paper while attackers still have practical ways around it.