Conditional Access Policy in Microsoft 365 Explained

What a Conditional Access policy actually is

A conditional access policy is a rule that sits between a user and your Microsoft 365 data. Rather than treating every login the same, it asks a set of questions the moment someone signs in: who is this person, what app are they opening, what device are they on, where are they connecting from, and does this look risky? Based on the answers, it lets them in, blocks them, or forces an extra step such as multi-factor authentication (MFA).

The name tells you how it works. Access is conditional on signals being met. The old model was simple: correct password equals access. Conditional access replaces that with a sharper question for any modern business: "Correct password, but is this login actually trustworthy?" That shift is why the Australian Cyber Security Centre (ACSC) and the Essential Eight rank MFA and access restriction so high.

In plain terms, Microsoft 365 conditional access lets you say things like: "Staff can read email from their phones, but they can only download client files onto a managed company laptop," or "Block any sign-in attempt coming from outside Australia." You get a locked door with a receptionist who checks ID, instead of a door that opens for anyone with the right key.

How Conditional Access works in Microsoft Entra ID

Conditional Access lives inside Microsoft Entra ID (the identity service formerly called Azure Active Directory). If you have seen the terms microsoft entra conditional access, entra id conditional access and azure conditional access used interchangeably, that is why. They all point to the same engine, before and after Microsoft renamed the product. Any conditional access policy azure documentation you find online still applies to today's Entra portal.

Each policy has two halves: assignments (the conditions, or the "if") and access controls (the result, or the "then").

The conditions (the "if")

• •Users and groups, who the policy applies to, such as all staff, the finance team, or external guests.
• •Target resources, which apps or data, for example Exchange Online, SharePoint, or all cloud apps.
• •Conditions, the live signals: device platform, location (IP address or country), whether the device is managed, client app type, and sign-in risk.

The controls (the "then")

• •Block access entirely, useful for risky countries or legacy authentication protocols.
• •Grant access with conditions, require MFA, require a compliant (managed) device, or require an approved app.
• •Limit the session, allow access but block file downloads, or force re-authentication every few hours.

When someone signs in, Entra evaluates every policy that could apply, combines them, and enforces the strictest combined result. Policies are additive, so if any one of them blocks the request, the user is blocked. This is the part that trips businesses up most, and it is why you should test before you flip anything to enforce.

A password proves you know a secret. A conditional access policy proves the sign-in is coming from a person, a device and a place you actually trust.

Common Conditional Access policy examples

To understand microsoft conditional access, look at what real SMBs deploy. Here are the policies we configure most often for businesses across Sydney, ordered roughly from "switch this on today" to "plan this carefully".

• •Require MFA for all users, the single most valuable policy. It stops most password-spray and credential-stuffing attacks, and it satisfies the Essential Eight MFA control.
• •Block legacy authentication, older protocols like POP and IMAP cannot do MFA, so attackers favour them. Blocking them closes a door most staff never use.
• •Require MFA for admins, privileged accounts get a stricter, separate policy with no exceptions.
• •Restrict access by location, block or challenge sign-ins from outside Australia if your team never travels overseas. This shrinks your attack surface to the geography you actually work in.
• •Require a managed device for downloads, let staff read email anywhere, but only let them download client files onto a company-managed laptop, helping you meet Australian Privacy Act obligations.
• •Risk-based MFA, force a password reset or MFA challenge when Microsoft detects an unusual sign-in, such as an impossible travel pattern.

Microsoft also ships "security defaults" and ready-made policy templates that cover the basics. For a very small team they are a fine starting point, though they are blunt. A tailored set of policies gives you proper control over who gets challenged and when, without locking out the people who need to work. Getting that balance right is a core part of well-run Microsoft 365 management.

Do you need a licence to use Conditional Access?

Yes, and this catches businesses out. Conditional Access is not part of the entry-level Microsoft 365 plans. You need Microsoft Entra ID P1 (the licence formerly known as Azure AD Premium P1) for standard policies. For most Sydney SMBs, P1 comes bundled into Microsoft 365 Business Premium, which is the plan we recommend to most clients anyway. If you are on Business Premium, you already have what you need to build a full microsoft 365 security policy set, at no extra cost.

On Business Basic or Business Standard, you will need to either upgrade to Business Premium or add standalone Entra ID P1 licences. The advanced risk-based policies, the ones that respond to suspicious sign-ins on their own, require the higher Entra ID P2 tier. For most small businesses, P1 covers the controls that move the needle. Working out the right licence mix for your team is a short conversation, and one we cover as part of broader IT strategy planning.

How to set up a Conditional Access policy safely

Creating a policy is not hard. The risk is in the rollout. One overly broad policy can lock your whole team out on a Monday morning. Here is the sequence we follow to deploy entra id conditional access without disruption.

• •1. Open the Entra admin centre, go to the Microsoft Entra portal, then Protection > Conditional Access. Create your break-glass admin account first if you do not already have one.
• •2. Define the policy, set the users it applies to, the cloud apps it targets, the conditions, and the access control (for example, require MFA).
• •3. Exclude break-glass accounts, confirm your emergency admin is excluded from any blocking or single-device MFA policy.
• •4. Set it to Report-only, the critical step. Report-only mode logs what would have happened without enforcing the policy, so you can spot anyone who would be wrongly blocked.
• •5. Review the sign-in logs, leave it in report-only for a few days, check the impact across real staff, and adjust the conditions.
• •6. Switch to On, once the logs are clean, enable the policy and keep monitoring for the first week.

That report-only discipline separates a smooth rollout from a help desk meltdown. For a business with more than a handful of staff, or one juggling managed devices, guest access and remote workers, this is rarely a one-and-done job. You will want to review it as your team grows and threats change, as part of your cyber security posture. Many of our clients fold this into an ongoing managed IT arrangement so it stays maintained, monitored and audited without them having to think about it.

Done well, azure conditional access is close to invisible to your staff. Trusted people on trusted devices in Australia barely notice it. The friction shows up only for the logins that should be questioned, which is the point. You reduce real risk without slowing your business down.

This article reflects best practices as of the publication date. Technology and security recommendations evolve, so verify current guidance with the original sources or our team before acting.