The 5 Most Overlooked Entra ID Security Configurations That Put Your Organization at Risk

Introduction

If you manage Microsoft 365 identities, you've probably checked the obvious boxes: MFA enabled, Security Defaults on, maybe even a few Conditional Access policies in place.

But here's the uncomfortable truth: most organizations have critical security gaps hiding in plain sight. These aren't exotic vulnerabilities or zero-days. They're mundane misconfigurations that attackers exploit every day because defenders assume they're already covered.

We've analyzed thousands of Entra ID tenants through TrueConfig's security assessments. The same five misconfigurations appear in over 70% of them—including tenants that passed their last compliance audit.

Let's fix that.

---

1. Unrestricted User Consent to Applications

The Risk

By default, any user in your organization can grant permissions to third-party applications. Click "Accept" on an OAuth prompt, and suddenly that app can read emails, access files, or enumerate your directory.

Attackers exploit this through consent phishing: a convincing email links to a malicious app requesting innocent-sounding permissions. One click from any employee, and the attacker has persistent API access that bypasses MFA entirely.

Why It Gets Overlooked

IT teams assume users know better than to accept random permission requests. They don't. In penetration tests, consent phishing has a success rate above 30%—higher than traditional phishing.

The Fix

Restrict user consent to verified publishers only:

1. Navigate to Entra ID → Enterprise applications → Consent and permissions
2. Under "User consent settings," select Allow user consent for apps from verified publishers, for selected permissions
3. Or go stricter: Do not allow user consent

For the strictest control:

# Block all user consent
Set-AzureADMSAuthorizationPolicy -PermissionGrantPolicyIdsAssignedToDefaultUserRole @()

Establish an admin consent workflow so users can request apps through a governed process instead of granting access themselves.

---

2. Legacy Authentication Not Fully Blocked

The Risk

Legacy authentication protocols (IMAP, POP3, SMTP AUTH, older ActiveSync) don't support MFA. If these protocols are open, attackers can bypass your MFA deployment entirely using stolen credentials.

Why It Gets Overlooked

Organizations enable Security Defaults or create a Conditional Access policy to block legacy auth, then assume they're protected. But legacy auth often remains enabled for:

• Service accounts using SMTP relay
• Old mobile devices on basic authentication
• Conference room systems with outdated software
• Applications using basic authentication behind the scenes

The Fix

Step 1: Identify legacy auth usage

Check the Entra ID sign-in logs for legacy protocol usage:

1. Go to Entra ID → Sign-in logs
2. Add filter: Client app → Select all legacy authentication clients
3. Review which users and apps are still using these protocols

Step 2: Create a blocking Conditional Access policy with proper exceptions

Name: Block Legacy Authentication
Assignments:
  - Users: All users
  - Exclude: Emergency access accounts, documented service accounts
Conditions:
  - Client apps: Exchange ActiveSync clients, Other clients
Grant: Block access

Step 3: Monitor and enforce

Run the policy in report-only mode first. Identify any legitimate use cases, document them, then enforce.

---

3. No Conditional Access Policy for Privileged Roles

The Risk

Your Global Admins, Exchange Admins, and Security Admins have the keys to your kingdom. If their accounts are compromised, attackers can disable security controls, exfiltrate data, and establish persistence.

Yet most organizations apply the same authentication policies to admins as regular users. No additional verification, no device compliance requirements, no location restrictions.

Why It Gets Overlooked

Admins are often the ones configuring security. They exempt themselves "temporarily" for convenience, then forget to remove the exemption. Or they assume that because they're security-conscious, they don't need additional controls.

Spoiler: admin accounts are specifically targeted by attackers because of their elevated access.

The Fix

Create a dedicated Conditional Access policy for directory roles:

Name: Require Phishing-Resistant MFA for Admins
Assignments:
  - Users: Select directory roles
    - Global Administrator
    - Privileged Role Administrator
    - Exchange Administrator
    - SharePoint Administrator
    - Security Administrator
    - User Administrator
  - Exclude: Emergency access accounts only
Conditions: Any
Grant:
  - Require authentication strength: Phishing-resistant MFA
  - Require compliant device (if using Intune)
Session:
  - Sign-in frequency: 4 hours

For organizations without phishing-resistant MFA deployed yet, at minimum require:

• Standard MFA
• Compliant or hybrid Azure AD joined device
• Sign-in from trusted locations only

---

4. Sign-In Logs Not Exported for Long-Term Retention

The Risk

Entra ID retains sign-in logs for 30 days (7 days on free tier). If an attacker compromises an account and you don't notice for 45 days, the evidence is gone. You can't investigate what was accessed, how they got in, or whether they're still there.

Why It Gets Overlooked

Log retention seems like an infrastructure concern, not a security priority. Teams assume they'd catch a breach within 30 days. They usually don't—the average dwell time for attackers is still measured in months, not days.

The Fix

Export logs to long-term storage:

Option 1: Azure Monitor (recommended for Azure-native organizations)

1. Go to Entra ID → Diagnostic settings
2. Click Add diagnostic setting
3. Select:
   • SignInLogs
   • AuditLogs
   • NonInteractiveUserSignInLogs
   • ServicePrincipalSignInLogs
   • ManagedIdentitySignInLogs
4. Send to Log Analytics workspace or Storage Account
5. Set retention to 1 year minimum (compliance often requires longer)

Option 2: SIEM integration

Export to your existing SIEM (Sentinel, Splunk, etc.) via the Graph API or direct integration.

Minimum retention guidance:

• Sign-in logs: 1 year
• Audit logs: 1 year
• Risky sign-ins: 2 years
• Privileged operations: 7 years (for regulated industries)

---

5. Security Defaults or MFA Not Applied to All Accounts

The Risk

You enabled MFA. Great. But does "all users" actually mean all users? Common gaps include:

• Service accounts: Often excluded from MFA policies because they're "not human"
• Break-glass accounts: Emergency access accounts need MFA too (just different MFA)
• New employees: Fall through the cracks before group memberships propagate
• Guest users: External collaborators often bypass your MFA requirements
• Recently provisioned accounts: Sync delays mean new users authenticate before policies apply

Each gap is an attack vector.

Why It Gets Overlooked

MFA coverage reports show a green checkmark, so teams move on. But those reports measure registered users, not enforced authentication. An account can be registered for MFA but not required to use it.

The Fix

Verify actual MFA enforcement, not just registration:

# Find users not covered by any MFA-requiring Conditional Access policy
# This requires analyzing policy assignments, not just MFA registration status

Connect-MgGraph -Scopes "Policy.Read.All","User.Read.All"

# Get all users
$users = Get-MgUser -All

# Get Conditional Access policies requiring MFA
$mfaPolicies = Get-MgIdentityConditionalAccessPolicy | Where-Object {
    $_.GrantControls.BuiltInControls -contains "mfa"
}

# Analyze coverage (simplified - production analysis needs policy evaluation logic)

Create a catch-all MFA policy:

Name: Require MFA for All Users - Catch All
Assignments:
  - Users: All users
  - Exclude: Emergency access accounts (with hardware tokens)
Conditions:
  - Client apps: All
Grant: Require MFA

For service accounts, use managed identities or certificate-based authentication instead of passwords. If you must use service accounts with passwords:

• Exclude them from MFA policies explicitly
• Document the business justification
• Restrict their sign-in to specific IP ranges
• Monitor their activity closely

---

The Pattern: Default Settings Aren't Secure Settings

Notice a pattern? Every one of these misconfigurations exists because the secure option isn't the default. Microsoft prioritizes usability and backward compatibility, which means:

• Users can consent to apps (convenient for productivity)
• Legacy auth is available (compatible with old systems)
• Admins use the same policies as users (simpler to manage)
• Logs are retained briefly (cheaper storage)
• MFA is available but not required everywhere (easier rollout)

Security requires deliberately changing these defaults and continuously monitoring for drift back to insecure states.

---

Quick Checklist

Run through this checklist today:

• User consent to applications restricted to verified publishers
• Legacy authentication blocked via Conditional Access (not just Security Defaults)
• Privileged roles have dedicated Conditional Access policy with stricter requirements
• Sign-in logs exported to storage with 1+ year retention
• MFA enforced for all accounts including guests and service accounts
• Emergency access accounts documented and excluded appropriately

If any item is unchecked, you have work to do. If all are checked, verify the configuration hasn't drifted since you last looked.

---

What's Next

Fixing these five issues will close the most common gaps in Entra ID security. But security isn't a one-time project—it's continuous maintenance.

The configurations you fix today can drift tomorrow. Someone re-enables legacy auth for a "quick test." A new admin gets created without the privileged access policy applied. An exception gets added and never removed.

That's where continuous configuration monitoring becomes essential. Define your security baseline once, and get alerted when reality drifts from intent.

---

TrueConfig continuously monitors your Entra ID configuration for these misconfigurations and dozens more. When settings drift from your security baseline, you'll know within hours, not months. See your current security posture →