Q&A
Entra ID Security Starts With the Settings Most Teams Overlook
Louis Mastelinck previews common Entra ID pitfalls around authentication, Conditional Access, privilege and app consent.
Microsoft Entra ID has become one of the most important control points in enterprise security, but many tenant weaknesses still come from basic configuration gaps rather than sophisticated attacks.
That is the focus of Louis Mastelinck's upcoming TechMentor session, "The Entra ID Pitfalls: Auth, Access, Privilege, Apps & Default Settings," scheduled for Aug. 4 at TechMentor & CyberSecurity Live! at Microsoft HQ. The intermediate-advanced session will examine the tenant settings, authentication choices, Conditional Access designs, privilege models and application consent decisions that can quietly expand risk if they are left unchecked.
Mastelinck, a Belgian security consultant and Microsoft MVP, specializes in incident response and the Microsoft Security stack, including Microsoft Defender, Microsoft Sentinel and related cloud security tools. His session is designed as a practical walkthrough of common Entra ID misconfigurations, with an emphasis on repeatable validation and remediation steps that IT and security teams can apply across existing tenants or new deployments.
In this Q&A, Mastelinck discusses where he starts when assessing an Entra ID tenant, why standing admin access remains a major risk, how organizations can reduce downgrade paths in authentication flows and what teams should know before approving application permissions. He also explains how to test Conditional Access coverage without locking out users or administrators, and why exclusions, weak registration methods and risky consent decisions often reveal hidden gaps in otherwise mature environments.
For more of Mastelinck's insights, make your plans today to attend Techmentor & Cybersecurity Live! Register by July 10 to save $300!
Redmondmag: When assessing a tenant, what are the first Entra ID misconfigurations you look for before diving into more advanced issues?
Mastelinc: I usually start with the foundational identity security controls because these tend to expose the most important risks early. That includes guest user access, application consent settings, Conditional Access scope and coverage, and whether the core baseline policies are actually in place and enforced.
Next, I assess how mature the organization is in using Entra ID capabilities such as Privileged Identity Management, role-assignable groups and just-in-time access. Many environments still rely too heavily on standing privileged access, which creates unnecessary risk.
A common area for improvement is the authentication methods strategy. I often see organizations allowing weaker authentication methods or using overly permissive self-service password reset configurations, which can introduce account takeover risk if they are not carefully designed. Strong authentication assurance should be the default.
I also review whether MFA is consistently enforced, whether Conditional Access policies are applied coherently, and whether legacy authentication is still enabled. In addition, I look for gaps such as excluded users, groups, or applications that are not covered by compensating controls.
What should organizations enable, avoid or retire to reduce downgrade paths and weak registration flows?
Organizations should enforce strong authentication methods using authentication strengths and make sure modern authentication is fully enabled. Legacy authentication protocols should be disabled, since they can bypass MFA and Conditional Access protections.
It is also important to standardize and secure registration flows by enforcing combined registration and limiting the authentication methods that are allowed. Weak methods such as SMS and voice should be avoided where possible, especially for higher-risk scenarios.
Organizations should avoid overly broad exclusions in Conditional Access policies because they often create unintended downgrade paths. Features such as Temporary Access Pass should be tightly scoped, time-bound, and monitored to reduce the chance of misuse.
How can teams validate Conditional Access coverage without accidentally locking out users, admins, or critical service accounts?
A key best practice is to always exclude at least one break-glass account from all Conditional Access policies. That gives you a secure recovery path if a policy is misconfigured or causes a lockout.
When rolling out new policies, start in report-only mode and initially scope them broadly, for example to all users, so you can understand the impact before enforcing them. There are two main ways to validate policy behavior:
- Use the What If tool to simulate sign-in scenarios by defining parameters such as that critical service, location, device state, and client application. This helps you validate how the policy would behave without affecting real users.
- Review the policy impact insights and sign-in logs while the policy is in report-only mode to analyze real-world behavior and detect unintended effects.
This phased approach helps teams move from testing to enforcement safely.
What are the biggest risks of standing admin access in Entra ID, and how should organizations transition toward just-in-time elevation safely?
Standing privileged access creates significant risk because if an account is compromised, the attacker immediately gains persistent high-level permissions. Modern attackers are also increasingly targeting session tokens rather than passwords, which means MFA alone is not enough once access has already been established.
To reduce this risk, organizations should eliminate standing privileges and use just-in-time access with Privileged Identity Management. That way, permissions are only activated when needed and expire automatically.
The main challenge for IT teams is aligning roles with least privilege. That requires careful role design and mapping permissions to operational tasks.
Risky consent is a recurring issue in cloud identity security. What should admins understand about consent governance before approving new applications?
Administrators should understand that application permissions, especially application-only permissions, can be very powerful and in some cases comparable to Global Administrator-level access. For example, an app may be able to read all mailboxes, send email as any user or access all SharePoint sites.
Proper consent governance means reviewing permissions carefully, understanding their scope and impact, and applying controls such as admin consent workflows, publisher verification, and permission classification. Permissions should always be scoped as narrowly as possible, and high-risk permissions should be tightly controlled and reviewed regularly.
Admins should also challenge vendors when they request excessive permissions and insist on least privilege as the standard.
For teams that already have MFA and Conditional Access in place, what next-level checks often reveal hidden gaps in their identity security posture?
A deeper gap analysis is needed to make sure every sign-in scenario is covered. That means checking whether all users, applications, and authentication flows are governed by Conditional Access.
Special attention should go to exclusions. Every exclusion should be clearly justified and backed up with compensating controls. For example, if a user is excluded from MFA for a specific business need, then other restrictions should be added, such as limiting access to trusted locations and requiring a compliant device.
Other advanced checks include token protection, session controls, authentication strengths, and monitoring for unusual sign-in behavior. The goal is to remove any unintended paths that bypass the main security controls.