Conditional Access is the single most powerful security control in Microsoft 365 and the most consistently misused. Frontrow has reviewed Conditional Access policy sets across Australian mid-market tenants since 2018. The same five failure patterns appear in nearly every tenant. The policies look right on paper. The board has been told they are protecting the organisation. The sign-in logs say otherwise.
This is the field report. Each pattern, the technical detail, the fix, and what to look for in your own tenant.
Pattern 1 — Report-only purgatory
Report-only mode is a Microsoft feature that lets you validate a Conditional Access policy by recording its impact in sign-in logs without actually enforcing it. Microsoft recommends 14 days. Frontrow finds tenants with the headline 'block legacy authentication' policy in report-only for 18 months.
The pathology: someone built the policy correctly, set it to report-only, then left or got pulled onto another project. The policy sits in report-only forever. Sign-in logs show 'this would have been blocked' events. Nobody reads them. The board hears 'we have a block-legacy-auth policy'. The auditor sees the policy in the policy list. Neither realises it's enforcing nothing.
The fix: written change-management standard. Every new policy enters report-only for a defined window (Microsoft suggests 14 days). At the end of the window, the policy owner reviews the sign-in log impact, completes any exception list, signs off, and the policy is promoted to Enabled. If a policy is still in report-only after the window expires, it is auto-flagged for retirement. Audit your tenant for stale report-only policies and promote or retire them this quarter.
Pattern 2 — Weak break-glass
A break-glass account is a tenant-recovery mechanism. When a Conditional Access misconfiguration, MFA outage or compromised admin account locks legitimate administrators out, the break-glass account is the way back in. Microsoft mandates two of them.
Frontrow finds three failure modes. First: no break-glass account at all — the tenant discovers this during its first MFA outage and the consultant becomes a folk hero. Second: a break-glass account that was created at tenant setup, never tested, password long since lost. Third: a break-glass account that exists but is included in a Conditional Access policy that requires MFA — meaning when the MFA provider is down, the break-glass account is also down. The whole point of break-glass is that it works when nothing else does.
The standard, per Microsoft Learn: two cloud-only Global Administrator accounts, no licences attached, excluded from every Conditional Access policy, 32-character passwords stored in physical safes split across two locations, MFA registered using a hardware FIDO2 key (not Authenticator app, not SMS), Entra alert configured on any sign-in. Quarterly test where one account is retrieved, signed in, used to perform a benign privileged action, password rotated, returned to safe.
Pattern 3 — Device-compliance trust assumption
A common pattern: a Conditional Access policy with grant 'require device to be marked compliant' but no Intune device compliance policy actually evaluating the device. Result: every Entra-joined device passes the gate regardless of patch state, encryption, password requirements, antivirus or jailbreak status. The policy looks strong. The control is a no-op.
The fix is paired policies. For every Conditional Access policy that requires compliance, there must be an Intune compliance policy scoped to the same population that meaningfully gates compliance. Minimum criteria: OS minimum version, BitLocker / FileVault encryption, password requirements, antivirus running. Where Defender for Endpoint is licensed, add device risk score below medium. Configure non-compliance grace periods and user notifications so users have a path back to compliant rather than a sudden hard block.
Pattern 4 — Location-based bypass scope
Pre-cloud, the corporate office network was a trust boundary. Inside the firewall was 'safe'. Outside was 'untrusted'. That model is dead. The corporate office is no longer a trust boundary because the device might be unmanaged, the user might be a contractor on the guest WiFi, the network might be compromised laterally, and the threat actor might be sitting in the carpark.
Frontrow finds tenants where the corporate office IP is named a 'trusted location' and used to bypass MFA. Result: anyone connecting from that IP — including a guest who got the WiFi password — bypasses MFA on every sign-in. The organisation has carefully built MFA across users and apps and then exempted the most-used network from it.
The fix is to remove location-based MFA bypass entirely. If you need to reduce MFA prompt friction (which is a legitimate goal — prompting users multiple times a day is bad UX and trains them to click through prompts unthinkingly), use sign-in frequency on managed devices: on a compliant Intune-managed laptop, sign-in frequency = rolling means the user signs in Monday and doesn't see another MFA prompt all week. On unmanaged devices, sign-in frequency = 8 hours, persistent browser session disabled. Location signal is then used as risk input to Entra ID Protection rather than a hard bypass.
Pattern 5 — Legacy authentication still enabled
Microsoft retired basic authentication in Exchange Online for most protocols in 2022, but tenants still have SMTP AUTH enabled (commonly for line-of-business apps that send mail) and 'Other clients' open at the Conditional Access layer. Legacy authentication bypasses MFA entirely. Microsoft, ASD and CISA all recommend blocking legacy auth as the first Conditional Access policy.
Frontrow finds tenants that 'tried it once, broke an integration, reverted it' and never came back. The pattern: someone enabled the block-legacy-auth policy, the warehouse barcode scanner stopped working, the warehouse manager called the IT lead, the policy got reverted, the policy never returned. The integration was using SMTP AUTH to send shipment notifications. Migrating it to Microsoft Graph SendMail or High Volume Email for Microsoft 365 is a half-day of work. Reverting the policy and never coming back was a decision made under pressure that the organisation has been paying for ever since.
The fix is structured: enable the block-legacy-auth policy in report-only for 14 days. Pull the legacy auth sign-in events from the sign-in log. Identify the actual integrations using legacy auth (it will be a specific list, usually three to five). Migrate each one to modern auth. Promote the policy to Enabled. Audit quarterly via the sign-in log to confirm no legacy auth is succeeding.
Try it
Score your tenant against the five patterns
The Conditional Access Misconfiguration Self-Check scores your tenant against each of these patterns. Output is a board-grade PDF.
10 questions · 5 domains
Conditional Access Misconfiguration Self-Check
The five Conditional Access failure patterns we find in nearly every AU tenant. Score yours against each one and see which fixes will move the needle. Pick the option closest to how your tenant is configured today.
Domain 1
Report-only purgatory
Whether new policies move out of report-only mode within a defined window, or stay there forever (and therefore enforce nothing).
What's the maximum time a Conditional Access policy stays in report-only mode before promotion or removal?
Source: Microsoft Learn: Conditional Access policy report-only mode.
When was the last audit of which CA policies are in report-only versus enforced?
Source: Microsoft Learn: Manage Microsoft Entra Conditional Access policies; Microsoft Sentinel CA workbook.
Domain 2
Break-glass account hygiene
Whether emergency access accounts exist, are excluded from every Conditional Access policy, are alerted on use, and are tested.
How many emergency access (break-glass) accounts does your tenant have?
Source: Microsoft Learn: Manage emergency access accounts in Microsoft Entra ID.
When were the break-glass accounts last successfully tested?
Source: Microsoft Learn: Manage emergency access accounts; ASD Essential Eight Maturity Model — Restrict Administrative Privileges.
Domain 3
Device compliance trust assumption
Whether 'require compliant device' policies actually require Intune compliance, or just check that the device is Entra-joined.
Where you have a 'require compliant device' Conditional Access policy, is there an Intune device compliance policy that actually evaluates compliance?
Source: Microsoft Learn: Use compliance policies to set rules for devices you manage with Intune.
What proportion of devices accessing M365 are evaluated by an Intune compliance policy?
Source: Microsoft Learn: Microsoft Intune device enrolment; App protection policies overview.
Domain 4
Location-based bypass scope
Whether 'trusted location' or 'corporate IP' bypasses are scoped narrowly, or applied tenant-wide such that any office IP exempts users from MFA.
Are any of your CA policies set to bypass MFA when the user is on a 'trusted location' (e.g. corporate office IP)?
Source: Microsoft Learn: Using the location condition in a Conditional Access policy; Microsoft Zero Trust guidance.
How do you handle access from outside Australia for travelling staff?
Source: Microsoft Learn: Configure named locations in Microsoft Entra ID; Microsoft Entra ID Protection risk policies.
Domain 5
Legacy authentication blocking
Whether legacy authentication protocols (basic auth on IMAP, POP, SMTP AUTH, MAPI) are blocked tenant-wide.
Is legacy authentication blocked at the Conditional Access layer?
Source: Microsoft Learn: Block legacy authentication with Conditional Access; Microsoft retirement of basic authentication in Exchange Online.
Is SMTP AUTH enabled for any user mailboxes in your tenant?
Source: Microsoft Learn: Authenticated SMTP submission in Exchange Online; Disable SMTP AUTH for the entire organisation.
This is an indicative self-assessment. It is not a substitute for a tenant-level Conditional Access review. For verified results Frontrow Technology runs an in-tenant CA policy review and produces a remediated policy set.
How Frontrow runs this as a managed service
Conditional Access is not a project — it is a continuously evolving control surface. Microsoft updates the available conditions, grants and authentication strengths quarterly. The Frontrow Managed Identity & Information Protection program runs a quarterly Conditional Access posture review against published Microsoft and ASD baselines and the five misconfiguration patterns above. Break-glass accounts are tested quarterly with documented evidence. Legacy authentication is blocked and the absence is evidenced. Intune compliance policies are aligned to Conditional Access policies. The output is a quarterly board-grade summary and a monthly delta report for the IT lead.
If you recognise yourself in two or more of these patterns, the engagement is straightforward — email Frontrow at info@frontrow.email.