Conditional Access policies every Australian Microsoft 365 tenant should run

Microsoft Entra Conditional Access is the most consequential security control most Australian Microsoft 365 tenants own — and the most chronically under-deployed. Field experience: most AU midmarket tenants run two or three Conditional Access policies, often the Microsoft Security Defaults that came with the tenant or one custom 'require MFA' policy. The recommended baseline is closer to ten.

The policies below are what Frontrow deploys as the Australian midmarket baseline. Together they cover the Conditional Access expectations of Essential Eight ML2, the Privacy Act 2026 'reasonable steps' bar, and APRA CPS 234. Deploy in the order listed; each builds on the previous one.

Policy 1 — Block legacy authentication

Legacy authentication protocols (POP, IMAP, SMTP basic auth, older Office clients, ActiveSync without modern auth) cannot be challenged with MFA. They are the path attackers use most often after credential theft. The policy: block legacy auth across the entire tenant, with a sensible exception group for a small number of named legacy systems while migration completes. This is the single highest-leverage Conditional Access policy you'll ever deploy.

Policy 2 — Require MFA for all users

All cloud apps, all users, require MFA at sign-in. With named exclusions only for the documented break-glass accounts (which are monitored and tested monthly). Don't deploy as 'security defaults' — deploy as a Conditional Access policy you control and can audit.

Policy 3 — Require phishing-resistant MFA for privileged roles

Global Admin, Security Admin, Privileged Authentication Admin, User Admin, Exchange Admin, SharePoint Admin, Teams Admin, Application Admin — these accounts get FIDO2 or Windows Hello for Business or Authenticator passkeys, not SMS or phone MFA. Configured via the Authentication Strengths feature in Conditional Access.

Policy 4 — Block sign-in from non-AU geographies (with documented exceptions)

For most Australian businesses with no offshore staff, blocking sign-in from countries outside Australia and a small named travel list reduces attack surface materially. Implement as a 'block' policy with a named exception group for staff travelling internationally, who must request and get added before the trip. Combine with Conditional Access Continuous Access Evaluation so the block applies in real-time.

Policy 5 — Require compliant device for cloud apps

Cloud apps (Microsoft 365, all enterprise SaaS integrated to Entra) accessed only from devices marked compliant in Intune. Devices must be enrolled, encrypted, OS up to date, with EDR running. This single policy means a stolen unmanaged laptop with valid credentials cannot get into Microsoft 365.

Policy 6 — Block downloads to unmanaged devices via App Enforced Restrictions

For BYOD scenarios where MAM is in place but the device isn't fully enrolled, Conditional Access App Control via Defender for Cloud Apps applies session-level policies — block download, watermark, restrict to web access only. The user can read but can't bulk-extract content to a personal device.

Policy 7 — Risk-based sign-in challenge (Entra ID P2)

Entra ID Identity Protection assigns sign-in risk and user risk scores. Policy: medium-risk sign-in requires fresh MFA challenge; high-risk sign-in blocks. User-risk policy: high-risk user requires password reset before next sign-in. Requires Entra ID P2 (in M365 E5 or as add-on).

Policy 8 — Token persistence rules

By default, sign-in tokens persist for 90 days. For privileged roles and external-facing apps, reduce token lifetime and require re-authentication after 4–8 hours. This is the policy most operators forget and most auditors ask about.

Policy 9 — Service principal Conditional Access

Workload identities (service principals, apps that authenticate without a user) can be governed by Conditional Access in Entra ID P2. Lock down which service principals can call which APIs from which IP ranges. This is what Storm-0558 and Midnight Blizzard exploited; it's also what most AU tenants haven't enabled.

Policy 10 — Block specific high-risk apps and unblock specific low-risk patterns

Tenant-specific tail of policies for the apps and patterns unique to your environment — block consumer cloud storage, block unsanctioned AI tools, allow internal-IP-only access to sensitive admin apps. These are calibrated per tenant; the principle is that Conditional Access becomes the named choke point for any access decision the security team makes.

Deployment order matters

Don't deploy all ten on day one. The order: 1, 2, 3 first (legacy auth, MFA, phishing-resistant MFA for admins) — this gets you most of the way to Essential Eight ML1. Then 5, 6 (compliant devices, MAM) — this needs Intune to be deployed first. Then 4, 7, 8 (geography, risk-based, token lifetime). Then 9, 10 (workload identities, tenant-specific). The full rollout is typically 90 days for an Australian midmarket tenant; rushed rollouts produce policy conflicts that cause sign-in failures and erode trust.

What policy review looks like

Conditional Access policies aren't deploy-and-forget. Every policy needs a quarterly review: are the named exclusions still valid, is the exception group still small, are the new apps in the tenant covered. Microsoft's 'What If' tool lets you simulate sign-in scenarios before deploying changes — use it. The policy set is part of the quarterly board security pack.