Conditional access is the cornerstone of Microsoft zero trust messaging. The platform lets administrators build policies that allow access only from compliant devices, only from approved locations, only after multi-factor authentication and only under conditions that meet the organisation security posture. In theory this is a powerful set of controls. In practice the gaps and overrides that creep into real tenants quietly recreate the very risks the policies were meant to prevent.
Exclusions Become Permanent Holes
Every conditional access policy comes with the temptation to exclude a specific account, group or location to solve an immediate problem. Service accounts get excluded because they cannot do MFA. Executives get excluded because they travel. A break glass account is excluded because it is supposed to be excluded. The challenge is that exclusions, once created, tend to outlive the situations that justified them. Each exclusion is a documented gap in the policy, and attackers know to look for them. A focused Azure pen testing should enumerate every exclusion in the tenant and verify that each one is still necessary.
Legacy Authentication Keeps Coming Back
Older authentication protocols such as IMAP and SMTP basic auth bypass conditional access entirely because they were designed before the concept existed. Microsoft has been deprecating these for years, but mailbox migrations, third party integrations and forgotten service accounts keep them alive in production tenants. Block legacy authentication tenant wide. The few workloads that still need it should be moved onto modern protocols promptly, not granted a permanent waiver.
Expert Commentary
William Fieldhouse, Director of Aardwolf Security Ltd
A pattern I see repeatedly is a conditional access policy that requires MFA, an exclusion for one service account, and a developer who quietly moved their day to day mailbox over to that service account because it was easier than dealing with the MFA prompts. The policy was technically intact. The protection was effectively gone.
Continuous Verification, Not One-Off Setup
A conditional access policy that worked when it was deployed may not work today. Tenants change. New services come online. New identities get created. Old exclusions persist. The right operational practice involves periodic validation that the policies still match the intent, supported by automated alerts when policy changes occur. Tenants that drift quietly tend to produce incidents nobody saw coming. The exclusions documented today often persist long past their original justification. A quarterly exclusion review removes the ones that are no longer needed and forces a fresh conversation about whether the remaining ones are still appropriate.
Testing Is The Only Way To Be Sure
A conditional access policy that looks correct in the portal is not the same as one that actually blocks the scenarios it claims to block. Active testing, where someone attempts to authenticate under conditions the policy should reject, is the only reliable way to confirm the policy is doing what was intended. A capable best pen testing company will design and execute these tests rather than relying on configuration review alone.
Zero trust is a goal, not a product. The work is in the verification, not the marketing slide. Conditional access works when it is verified continuously. Without verification it is a configuration file that nobody is sure still reflects the intent. Cloud security is a shared responsibility model in name and a fully owned responsibility model in practice. The configuration choices that matter live on your side of the line, regardless of how the provider markets the platform.
