Most Conditional Access gaps aren’t exotic. They come from reading policies the wrong way: as firewall rules with an “allow”, as a list of platforms that seems complete, as an MFA exception for the office that made sense years ago. Brandon Colley has reviewed well over a thousand Conditional Access policies in customer assessments, and the same handful of mistakes come up in tenant after tenant. Once those are fixed, the risk moves. Passkeys, privileged access and Conditional Access put more locks on the front door, the user sign-in. An app that was consented to years ago, holds a client secret and still has a stale redirect URI is a back door that none of those locks cover. Brandon is a Senior Security Consultant at TrustedSec and a Microsoft Security MVP. He came from systems administration, learned Active Directory security at Trimarc, and now spends his days on cloud and on-premises assessments and the remediation that follows. These are the gaps he checks first, and the app and consent settings he has moved on to. Security defaults can cover more admins than your policies The free tier can be stricter than the paid one. Security defaults require MFA for 16 administrator roles. The Microsoft-managed policy “Multifactor authentication for admins accessing Microsoft Admin Portals”, and the “Require MFA for admins” template it mirrors, cover 14. The two extra roles in security defaults are Authentication Policy Administrator and Identity Governance Administrator. If a small tenant is on security defaults, think hard before switching it off: the moment you do, you lose protections that you then have to rebuild in Conditional Access yourself. Sponsored by: ENow Software Introduces New Entra ID App Onboarding Experience As user requests for SaaS and AI applications increase, Entra ID and M365 teams face a growing volume of security reviews, added hours of manual research, and bottlenecks. New! ENow App Governance Accelerator 4.0 introduces App Onboarding, helping teams: * Accelerate app approvals with configurable, multistage workflows. * Evaluate security risks more efficiently with integrated Microsoft Defender for Cloud Apps risk scores. * Reduce manual work with centralized requests, reviews, and approvals. * Improve transparency with a self-service portal for requesters to track status and decisions. * Control app sprawl with an Internal App Catalog of approved applications. Go beyond Microsoft’s consent and approval capabilities with customizable, structured application governance, from the initial request through ongoing oversight. Faster Approvals. Less Admin Work. Better Security Posture. Learn More About ENow App Governance Accelerator 4.0 See It In Action: Request a Demo Decide which roles are privileged yourself “We require MFA on privileged roles” is easy to say in an audit. An assessment asks a harder question: privileged by whose definition? Brandon’s own list is about 36 roles, grouped into tier 0 and tier 1, the same tiering model Active Directory admins used 20 years ago. Don’t lean on Microsoft’s mandatory MFA either. It covers the Azure portal, the Microsoft Entra admin center, the Intune admin center and the Microsoft 365 admin center, plus create, update and delete operations from Azure CLI, Azure PowerShell, the Azure mobile app and IaC tools. Microsoft Graph APIs are generally not in scope, so in some cases a single-factor sign-in can still reach Graph. Your Conditional Access still has to cover every app and every role you consider privileged. Every platform is not all platforms Conditions inside one policy combine with AND. A policy that requires MFA when the user is risky, the sign-in is risky and the location is outside the United States only fires when all three are true at once, so it almost never fires. Put conditions that should act on their own into separate policies. The device platforms condition has the same trap. Ticking Android, iOS, Windows, macOS and Linux is not the same as “any device”. The platform comes from the user agent string, which isn’t verified and is easy to change, so a sign-in that claims an unknown platform matches none of your platform policies and walks past all of them. Microsoft’s recommended fix is a separate block policy: include Any device, exclude the platforms you support, and set the grant to Block access. Brandon covers how the spoofing works in his Petri article (linked below). Watch this episode… Conditional Access has no allow rule Customers often ask for a policy that will “allow finance access to the finance app”. Conditional Access has no allow rule. A policy is an if-then statement: if the users, target resources and conditions match, then require MFA, a compliant device or another control, or block. Anything the policy doesn’t match passes through untouched. So every time you narrow the users, the apps or the conditions to describe who should get in, you also shrink what the policy protects. Scope policies broadly and carve out exclusions on purpose. Testing: ask what a policy doesn’t do Testing usually covers the happy path: the right user opens the right app and gets an MFA prompt. The gaps are in the paths nobody tried: the user who isn’t in the group, the unmanaged device, the other network. Two locations, managed and unmanaged devices, a few apps and a few user types already make dozens of test cases, and every new condition (insider risk from Microsoft Purview, for example) multiplies them again. The useful question isn’t “what does this policy do?” but “what doesn’t it do, and does something else cover that?” When you add a role or group to one policy, check whether it should come out of another. Tools help: * What If tool: simulate a sign-in for a user, app, device platform and location, and see which policies apply. * Conditional Access Optimization Agent: Microsoft Security Copilot reviews your policies and suggests new policies (created in report-only mode) and changes for you to approve. It needs Microsoft Entra ID P1 and security compute units. * AI with sanitized data: as a consultant, Brandon often can’t run tools inside a customer’s tenant. He exports the policies as JSON, removes tenant names, group names and IDs, and asks an AI model to explain a specific coverage question. Challenge the answers and verify them; don’t take them on trust. User actions and device code flow Two gaps Brandon still finds often: * User actions. Conditional Access can target Register security information and Register or join devices. Without a policy on these, registering an MFA method or a device is protected only by whatever the sign-in itself required. * Device code flow. Microsoft deploys a managed policy that blocks it in some tenants, but Brandon has seen it deployed only about three times. Check whether you need it: filter the sign-in logs by authentication protocol for device code and see who uses it. Legitimate users are usually input-constrained devices such as Teams phones and Teams Rooms. At one customer, the single device code sign-in turned out to be their own penetration test. Then block it with an authentication flows policy and exclude only what genuinely needs it. Trusted locations: the exception that switches MFA off A common policy reads: require strong authentication for all users, all apps, everywhere, except trusted locations. It was best practice once. In effect it means single-factor sign-in at the office, and it often survives after the rest of the policy has been modernized. On Microsoft Entra joined and hybrid joined Windows devices you don’t need the exception for single sign-on. The primary refresh token (PRT) provides SSO to apps and carries the MFA claim. The exception only lets users skip strong authentication. Flip how you use locations. Instead of using them to relax MFA, use them to lock down the accounts that can’t do MFA, such as service accounts, shared accounts and kiosk accounts, so they only work from specific IP ranges and devices. While you’re there: * MFA trusted IPs in the legacy MFA service settings are IPv4-only and not recommended. The “All trusted networks and locations” option in Conditional Access includes them. The checkbox to skip MFA for federated users on your intranet belongs to the same legacy settings. * Continuous access evaluation checks IP-based named locations at the resource. Include both IPv4 and IPv6 ranges, or IP mismatches will cause unexpected behaviour. * Check your ranges. Few admins still calculate subnets by hand. AI can help, as long as you check the answer: ask whether a specific IP is inside a specific range rather than accepting “it’s a /8”. * Compliant network. With Global Secure Access and the Microsoft traffic profile, the compliant network check in Conditional Access is included with Microsoft Entra ID P1. It follows the device rather than the building, which suits people who move around with their laptops. Apps: the back door There are no unpatched Entra servers for an attacker to exploit, so the ways in are user sign-in and apps. Once an app is in the tenant, consented, holding permissions and a client secret, it lives there until someone actively looks at it. A single leaked client secret can be all an attacker needs, and none of the controls on user sign-in apply to it. Prefer certificates, and better still managed identities or workload identity federation, over client secrets. Redirect URIs and dangling domains A redirect URI (reply URL) is where Microsoft Entra sends the token after a user signs in. If an attacker controls that URL, they get the token from a completely legitimate Microsoft sign-in, usually started by a phishing link. Watch for three kinds: * Old redirect URIs left behind after an app moved. * Wildcards, which Microsoft’s guidance says not to use. * Reclaimed domains: names you let go that someone else can register. The classic case is azurewebsites.net. Deve
![php[podcast] episodes from php[architect]](/assets/artwork/1x1.gif)