Default Microsoft Entra ID Security Is Often Overestimated
A Technical Analysis of Identity Gaps in New Tenants
Introduction
Many security teams believe that a newly created Microsoft Entra ID (formerly Azure AD) tenant is reasonably secure by default.
This is not the case.
In a recent hands-on lab (EID-EXP-001), I evaluated the default security posture of a new Entra ID tenant with no custom policies or intentional misconfigurations, using only Microsoft’s current default settings.
The result:
Several significant identity attack paths remain open unless they are explicitly addressed.
This article outlines the default security gaps, explains their significance, and details what identity engineers should verify immediately after tenant creation.
Lab Scope & Methodology
The experiment was performed against:
- A fresh Entra ID tenant
- No Conditional Access policies
- No Identity Protection configuration
- Default guest access and authentication settings
- Security Defaults left untouched.
Evidence was collected from the Entra portal, sign-in logs, and Identity Protection blade, and has been documented publicly in the lab.
1. Conditional Access: Empty by Design
Observation
By default, no Conditional Access (CA) policies are configured.
This means:
- No enforced MFA for users
- No device compliance requirements
- No location, platform, or risk-based restrictions
- No explicit legacy authentication block
Why this matters
Conditional Access serves as Entra ID’s primary enforcement mechanism. Without it:
- Authentication relies on static credentials.
- Risk signals are collected but not acted on
- Attackers face fewer barriers once credentials are Logging without enforcement provides observability, not security.
2. MFA Is Not Universally Enforced
Observation
Standard user sign-ins may succeed without MFA, depending on workload and context.
Even with Security Defaults enabled, MFA enforcement is:
- Limited
- Non-deterministic
- Not presented as an auditable or transparent policy for engineers
Why this matters
Attackers are not required to bypass MFA if it is not consistently enforced.
Password spray attacks, legacy authentication, and basic protocols remain effective in default tenants.
3. Legacy Authentication Is Not Explicitly Blocked
Observation
No Conditional Access policy is in place to block legacy authentication.
Legacy auth protocols (POP, IMAP, SMTP AUTH, older Office clients):
- Do not support MFA
- They are heavily targeted in credential attacks.
- Still appears in real-world breach reports. (Block legacy authentication with Conditional Access - Microsoft Entra ID, 2023)
Why this matters
A single unblocked legacy authentication path can undermine all modern security controls.
The presence of legacy authentication effectively bypasses MFA requirements.
4. Identity Protection Policies: Disabled
User risk and sign-in risk policies remain unconfigured.
This results in:
- No automated response to risky sign-ins
- No forced password resets for compromised users
- Risk signals are collected but not utilized.
Why this matters
Identity Protection without active policies functions similarly to an IDS that neither alerts nor blocks threats.
Attackers can:
- Reuse compromised credentials
- Maintain access longer
- Escalate without triggering enforcement.
5. Guest Access Defaults Are Broad
Observation
Guest users may be invited without:
- Approval workflows
- Access restrictions
- Dedicated Conditional Access rules
Why this matters
Guest identities are frequently:
- Less monitored
- Poorly governed
- Over-permissioned
Guest accounts are also a common entry point for lateral movement, particularly in hybrid and multi-tenant environments. (Security guidance - Protect tenants and isolate production systems, 2024)
The Primary Risk: Assumptions of Adequate Security Measures
None of these findings are zero-days.
None requires advanced attacker tradecraft.
These issues persist due to a common and risky assumption:
“Microsoft would secure this by default.”
Microsoft provides robust security tools, but expects engineers to enable them proactively.
What Identity Engineers Should Do Immediately
Explicit Conditional Access policies
- Enforce MFA
- Block legacy authentication
- Require compliant or hybrid-joined devices where applicable.
Identity Protection enforcement
- User risk → password reset
- Sign-in risk → MFA or block
Guest-specific controls
- Dedicated CA policies
- Restricted access
- Regular access reviews
Evidence-based validation
- Screenshots
- Sign-in logs
- Security measures that cannot be verified should not be considered trustworthy.
Final Thoughts
Default Entra ID settings prioritize ease of adoption over attack resistance.
This approach is not a flaw, but it does shift responsibility to the organization.
If you operate Entra ID in a production environment and have not validated the default settings, you should assume there are security gaps until they are proven otherwise.
Related Evidence & Guidance
Hands-on Lab (F11)
Business Risk View
About the Author
Jaspreet Singh
Identity & Security Engineer
Hands-on Entra ID experiments, real-world attack paths, and evidence-based security analysis.
References
(2023). Block legacy authentication with Conditional Access - Microsoft Entra ID. Microsoft Learn. https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/block-legacy-authentication
(2024). Security guidance - Protect tenants and isolate production systems. Azure Docs. https://docs.azure.cn/en-us/entra/fundamentals/zero-trust-protect-tenants