Free tool · 5 minutes · Identity
The five Conditional Access failure patterns Frontrow finds in nearly every Australian tenant. Score yours against each one and see which fixes will actually move the needle.
10 questions · 5 domains
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
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
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
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
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
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.
The five patterns
Pattern 1
Report-only mode is for validating a policy's blast radius before enforcement. Frontrow finds tenants with policies stuck in report-only for 18+ months. The board believes they are protected. They aren't. The fix is a 14-day report-only window with a documented promotion gate.
Pattern 2
Microsoft mandates 2 emergency access accounts excluded from CA. Most tenants either have none (locked out by their own policies during the first MFA outage) or have them but never tested. The standard is: 2 cloud-only accounts with 32-character passwords stored in physical safes, excluded from every CA policy, MFA registered using a hardware FIDO2 key, and alerted on every sign-in attempt.
Pattern 3
The classic misconfiguration: a CA policy that grants 'require device to be marked compliant' without an Intune compliance policy actually evaluating the device. Result: every Entra-joined device passes regardless of patch state, encryption, or jailbreak status. The fix is a paired Intune compliance policy that meaningfully gates compliance.
Pattern 4
Frontrow finds tenants where the corporate office IP is named a 'trusted location' and used to bypass MFA. Result: anyone on the office WiFi (including a guest who got the password) skips MFA. The pattern is a remnant of the on-premises trust model. Modern guidance is to remove trust-by-IP and use device + identity signals only.
Pattern 5
Legacy auth bypasses MFA entirely. Microsoft has retired basic auth in Exchange Online, but tenants still have SMTP AUTH and Other clients open at the CA layer. Microsoft, ASD and CISA all recommend blocking legacy auth as the first CA policy. Frontrow finds tenants that 'tried it, broke an integration, reverted it' and never came back.
Frequently asked questions
The Conditional Access Gap Checker scores whether you have the recommended baseline policies. This Misconfiguration Self-Check is the second pass: assuming you have the policies, are they configured in a way that actually enforces what they say they enforce? Frontrow consistently finds the same 5 patterns where the policies exist but the controls don't bite — report-only purgatory, weak break-glass, untrusted device-compliance, location bypass, legacy auth. Two different problems, two different tools.
Microsoft recommends placing a new Conditional Access policy in report-only mode for a period (Microsoft suggests 14 days) to validate its impact via sign-in logs before enforcement. The misconfiguration is leaving the policy in report-only forever — months, sometimes years. The board believes the policy is enforcing. The sign-in logs show it's recording but not enforcing. Frontrow finds tenants where the headline 'block legacy auth' policy has been in report-only for 18 months.
An emergency access (break-glass) account is a privileged identity excluded from every Conditional Access policy and every other identity control, used as a tenant-recovery mechanism when a CA misconfiguration, MFA outage or other identity-layer failure locks legitimate admins out. Microsoft mandates 2 of them. Most AU tenants either have none (and discover this during their first MFA outage) or have them but never tested them. The standard hygiene is documented in Microsoft Learn.
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, or whether it has antivirus. The policy looks strong on paper. The control is a no-op in practice. The fix is a paired Intune compliance policy that meaningfully gates compliance against OS version, encryption, password requirements and (where licensed) Defender for Endpoint risk score.
Pre-cloud, the corporate office network was a trust boundary. In a Zero Trust model, it isn't. A Conditional Access policy that bypasses MFA when the user is on a 'trusted location' (your office IP) means anyone connecting from that IP — including a guest who got the WiFi password — bypasses MFA. Microsoft's published Zero Trust guidance is to remove location trust and rely on identity + device signals. Use sign-in frequency on managed devices to control MFA prompt friction, not location bypass.
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 auth bypasses MFA entirely. ASD, CISA and Microsoft all recommend blocking it as the first CA policy. Frontrow finds tenants that 'tried it once, broke an integration, reverted it' and never came back. The fix is to block legacy auth in CA, then migrate the broken integrations to Microsoft Graph SendMail or High Volume Email for Microsoft 365.
Every scoring threshold cites a primary source: Microsoft Learn for Conditional Access, emergency access accounts, Intune compliance, location conditions and legacy auth blocking; ASD Essential Eight for the Australian baseline. The methodology is authored by Daniel Brown (5x Microsoft MVP), Graeme Lodge (Managing Director), and Sam Williams (Investor & Executive Consultant).
Quarterly Conditional Access posture review against published baselines and the 5 misconfiguration patterns. Break-glass account quarterly test with documented evidence. Intune compliance policy alignment. Legacy authentication block evidence. Monthly delta report for the IT lead, quarterly board-grade summary.
