Conditional Access

The Conditional Access policies a small business actually needs.

Conditional Access is where Microsoft 365 security gets enforced: who needs MFA, from which devices, from where, and what gets blocked. Done well, staff barely notice. Done badly, it locks out the whole office. Here is the policy set we start from, what licence each needs, and the order to roll them out.

Policy guidance from Microsoft Learn, checked 30 October 2026.

Have us review your policies Build a starter plan 07 3114 2808

Policy set by layer
Licensing explained
Starter plan for your tenant

Reviewed by Blake Bath, General Manager, on 30 October 2026.

An IT engineer at his desk holds a phone in one hand and a small hardware security key in the other, with monitors and a whiteboard diagram behind him. — **Before anything else**Two tested emergency access accounts. They are how you get back in if a policy goes wrong.

The layers

Five layers of policy.

Each layer answers a different question about a sign-in.

Baseline

Is it a modern sign-in, with MFA, from somewhere expected?

Block legacy auth
MFA for everyone
Location where justified

Conditional Access starter plan

Which policies should you start with?

Pick your licence and answer three questions. The plan lists the policies to build, in the order to roll them out.

Answer four questions for a starter set of policies, in the order to roll them out.

Which Microsoft 365 licence do you have?

Do staff use their own phones for work email or Teams?

Do you work with guests from other organisations?

Does everyone work from Australia?

Starter plan

7steps, in rollout order

Two emergency access accounts (Prep)Cloud-only, protected with passkeys, excluded from enforced policies and tested.
Block legacy authentication (CA001)Check sign-in logs for old mail clients and scanners first.
Require MFA for all users (CA002)Register everyone's methods before you enforce.
Phishing-resistant MFA for admins (CA301)Passkeys or security keys for admin roles.
Require a compliant device for desktop access (CA201)Build Intune compliance rules before enforcing.
Require app protection on phones (CA202)Use Require app protection policy. The approved client app control went read-only on 30 June 2026.
Block sign-ins from outside Australia (CA003)With a travel exception group and an expiry date on each exception.

Risk-based policies need Entra ID P2. Business Premium covers everything else here.

Start every policy in report-only mode, then pilot with a small group, then enforce.

Have us review your policies

How we do it

Our standard: MFA everywhere, Australia-only sign-in, managed devices.

For managed clients on Business Premium we block legacy sign-in, require MFA for everyone and block sign-ins from outside Australia, with a time-limited group for staff who travel. Where computers are managed in Intune, we add device compliance. Admins move to phishing-resistant MFA first, then everyone else as passkeys roll out.

Every policy should start in report-only mode. Read the sign-in logs across a full business cycle, pilot with a small group, then enforce. Test the emergency access accounts before the first policy goes live, not after something breaks.

Pre-work

Before you create a single policy.

Create two emergency access accountsCloud-only accounts protected with a phishing-resistant method such as FIDO2 passkeys, with dependencies separate from routine admins. Exclude them from policies that could block recovery, monitor their use and test them regularly.
Know your appsThird-party SaaS, federated apps and service accounts. Conditional Access can break things you forgot existed.
Plan the move from Security DefaultsSecurity Defaults and Conditional Access cannot run together. Move without leaving a gap in MFA coverage.
Get the sign-in logs readyInteractive and non-interactive sign-ins, kept long enough to review a full business cycle.

Layer 1

Baseline policies.

CA001 - Block legacy authenticationExample scope: users and all resources, using the legacy client-app conditions documented by Microsoft. Review sign-in logs for older mail clients, scripts and devices before enforcing Block. Protocol names alone do not prove legacy authentication: some clients use modern authentication. Replace legitimate dependencies and give temporary exceptions an owner and expiry.
CA002 - Require MFA for usersExample scope: the intended workforce and resources, with emergency access handled separately. Require MFA or an appropriate authentication strength, then confirm registration, guest behaviour and supported methods. A policy configured for MFA does not prove all accounts and applications are covered.
CA003 - Restrict locations where justifiedOptional, not a universal baseline. Define approved named locations and test travel, VPN egress, mobile networks and external collaborators. IP geolocation is not proof of identity or a person's physical location. Do not let an allowed country replace MFA or device checks.
CA004 - Respond to risky sign-insRequires the applicable Entra ID P2 or equivalent entitlement. Microsoft recommends MFA for medium or high sign-in risk and appropriate reauthentication. Keep sign-in risk separate from user-risk conditions; register users before enforcing remediation and plan helpdesk recovery.

Layer 2, needs P2

Identity protection policies.

CA101 - Remediate high user riskMicrosoft's current guidance recommends Require risk remediation for high user risk. Behaviour differs for password and passwordless users. Confirm the supported controls, registration and hybrid password-writeback prerequisites in your tenant. Decide when investigation or blocking is needed, rather than dismissing a detection to make access work.
CA102 - Define the medium-risk treatmentSelect a threshold based on risk tolerance and operational impact, not a copied template. If secure password change is used, verify MFA registration and the recovery path, including password writeback for hybrid users. Avoid overlapping policies that unintentionally demand incompatible remediation.
CA103 - Pilot token protectionUse the token-protection session control only with supported resources, devices and client applications. Microsoft's support matrix distinguishes native applications from limited browser scenarios. Capture interactive and non-interactive logs, test a representative pilot and retain coverage for unsupported clients. It is not universal protection for every token.

Layer 3

Device policies.

CA201 - Require the intended device assuranceDecide whether the grant requires compliance, hybrid join, or one of those controls. Hybrid join is not a compliance result; selecting OR accepts either condition. Build and validate Intune compliance rules before enforcing them, and document macOS, mobile, guest and enrolment paths.
CA202 - Require mobile app protectionFor new iOS and Android policies, use Require app protection policy with assigned Intune policies and supported apps. Microsoft moved the approved-client-app control and policies using it to read-only on 30 June 2026. Existing enabled policies still enforce, but they are not a suitable new template. Test unsupported apps and registration before rollout.
CA203 - Limit unmanaged SharePoint accessCoordinate Conditional Access app-enforced restrictions with SharePoint's unmanaged-device settings. Test browser access, downloads, sync, supported file types and guests. A restricted browser session is not a universal guarantee against copying or photographing information.

Since 30 June 2026 the Require approved client app control, and any policy that uses it, is read-only. Existing enabled policies still enforce. Use Require app protection policy for new mobile policies.

Layer 4

Administrator policies.

CA301 - Require phishing-resistant admin MFASelect the intended built-in directory roles and resources, then require phishing-resistant authentication strength where compatible. Register and test supported methods first. Microsoft notes that role targeting does not cover every custom or administrative-unit-scoped role, so check the real privileged population.
CA302 - Check privileged legacy-auth coverageVerify administrator sign-ins are already covered by CA001. Create a separate policy only when a distinct scope or control is needed; otherwise record the coverage in the register. Duplicating a policy name does not add independent protection.
CA303 - Protect administrative devicesScope privileged work to an approved device model with the required compliance and authentication controls. Do not treat hybrid join as a substitute for compliance. Preserve tested emergency recovery and check account elevation, browser and mobile workflows.
CA304 - Govern privileged external accessStart with least-privilege roles, guest governance and the actual administration workflow. Where a resource-access policy is needed, target supported resources and test partner delegation. A blanket block on Microsoft Graph is not a precise switch for privileged actions and can disrupt ordinary application use.

Layer 5

Session policies.

CA401 - Set justified reauthenticationUse sign-in frequency where the application and risk justify it, then measure the prompts and recovery impact. An arbitrary four-hour interval is not a token-theft guarantee. Consider privileged role activation and relevant authentication context separately from every routine sign-in.
CA402 - Control persistent browser sessionsScope Never persistent to the intended users and browser scenarios. It controls persistence after a browser closes, not every desktop token or existing session. Check interaction with device filters, MFA and sign-in frequency instead of applying conflicting tenant-wide settings.
CA403 - Check continuous access evaluationCAE is automatically enabled for supported scenarios, and Microsoft documents a Conditional Access session setting to disable it. It is not a separate tenant-only switch or instant revocation guarantee for every application. Confirm supported clients, events and session behaviour before promising a response time.

Rollout

Roll out without locking anyone out.

Step 1Emergency accounts
Created, protected and tested first.
Step 2Report-only
Every new policy, for a full business cycle.
Step 3Read the logs
Who would have been blocked, and why.
Step 4Pilot
A small group, including someone who travels.
Step 5Enforce
Then keep a register of every exception and its expiry.

Related guides

Policies need the pieces behind them. These are those pieces.

Licences, devices and sign-in methods that Conditional Access relies on.

Get help your way

Six ways to reach us. Pick whichever suits you.

Helpdesk hours are Monday to Friday, 8am to 5pm AEST. On Advantage and above, emergencies get a response within 1 hour and outages within 2, with 24/7 best-effort escalation.

Questions

What people ask about Conditional Access.

What is Conditional Access in Microsoft 365?

It is the set of rules in Microsoft Entra ID that decides what a sign-in has to prove before it gets in: MFA, a managed device, a sign-in from Australia, or a block. It is how you turn 'everyone uses MFA' into something Microsoft enforces.

Which licence do we need for Conditional Access?

Microsoft lists Entra ID P1 for standard Conditional Access, including entitlement through Microsoft 365 Business Premium. User-risk and sign-in-risk policies need the applicable P2 or equivalent entitlement. Check each feature and the users covered; Office 365 E3 is not the same licence as Microsoft 365 E3.

Should emergency access accounts have no MFA?

No. Microsoft now recommends cloud-only emergency accounts protected with a suitable phishing-resistant method, such as a FIDO2 passkey, with dependencies distinct from routine administrators. Exclude them from enforced policies that could prevent emergency recovery, monitor use and test access regularly. Exclusion is not permission to leave the accounts unprotected.

Is a week in report-only mode enough to enable every policy?

Not necessarily. Observe a period that covers normal application use, travel, guests and non-interactive activity, then use an enforced pilot. Report-only logs do not prove users can complete every challenge. Microsoft also documents possible device-certificate prompts and unsupported User Actions scenarios.

Can we still create a policy requiring an approved client app?

No. Microsoft moved that control and policies containing it to read-only on 30 June 2026. Existing enabled policies continue to enforce, but new mobile policies should use Require app protection policy with supported apps and the corresponding Intune configuration.

Does hybrid join mean a device is compliant?

No. Hybrid join identifies a directory relationship; compliance is a separate assessment against configured device rules. A grant accepting compliance OR hybrid join can allow a device that has not passed those compliance checks. Choose and test the assurance the business actually needs.

Does one successful policy let a user bypass another block?

No. Applicable policies are evaluated together, and a blocking policy can prevent access even when another policy succeeds. Review the combined outcome, exclusions and dependencies in sign-in logs and test the intended scenarios before changing enforcement.

Next step