Conditional Access for Australian Businesses: A Microsoft 365 Baseline Guide

Conditional Access for Australian businesses is the single most useful setting in Microsoft 365 that most small firms have never properly looked at. It is the rule book that decides who can sign in, from where and on what device, and Microsoft has started writing parts of that rule book for you.

This guide is for the owner, office manager or IT lead who wants a clear baseline without a six-month identity project. It explains what Conditional Access does, what Microsoft is switching on in your tenant, the seven policies we start from, how to test them safely in report-only mode, and where the usual lockouts come from.

What Conditional Access for Australian businesses does, and why it matters now

Conditional Access is the rule book that decides who gets into your Microsoft 365 environment, from what device, from where, and under what conditions. Every time a staff member signs in to Outlook, Teams, SharePoint or the Azure portal, Microsoft Entra ID checks the sign-in against your policies and then allows it, blocks it, or asks for more proof, such as a multi-factor authentication (MFA) prompt.

Think of it as the receptionist for your digital front door. A password is the key. Conditional Access is the person who looks at who is holding the key, notices they are arriving at 3am from another country on an unfamiliar laptop, and says "not without a second form of ID". Our plain-English glossary entry covers the basic definition. This guide is about what to actually do with it.

It matters more now because attackers have changed tactics. Stolen passwords are only one route in. Phishing kits capture session tokens, device code phishing tricks people into approving a login the attacker started, and token theft lets criminals replay a session that already passed MFA. Turning MFA on is no longer the finish line. The conditions around the sign-in are where the next layer of protection lives.

The part most owners miss: Microsoft is already writing policies in your tenant

Here is the angle we think most Australian small businesses have not caught up with. Microsoft now creates Conditional Access policies for eligible tenants on its own. They appear in your Entra admin centre with names that start with "Microsoft-managed:", and you did not create them.

Based on Microsoft's own documentation, the process works like this. When Microsoft introduces a managed policy, it is created automatically in report-only mode, which means it logs what it would have done but blocks nothing. If it is still in report-only after at least 30 days, Microsoft can switch it on. Customers are meant to get an email and a Message centre post two weeks before enablement, and some policies may be switched on sooner, with that noted in the notice. You can turn a policy on early, or set it to off to opt out, and you can edit the state and the excluded accounts. You cannot rename or delete the policy.

The policies on offer include blocking legacy authentication, blocking device code flow, requiring MFA for admins using Microsoft admin portals, requiring MFA for all users, and, with the right licensing, handling risky sign-ins and high-risk users. Microsoft notes that legacy authentication protocols such as IMAP, SMTP and POP3 account for over 99% of password spray attacks, which is why blocking them is first on almost every baseline list.

If you only do one thing after reading this guide, log in to the Entra admin centre, open Conditional Access, and look for anything named "Microsoft-managed". Check its state, check its report-only impact, and check who is on the exclusion list. If you cannot get in, or you do not know who your Global Administrators are, that is a finding in itself.

Security Defaults or Conditional Access: which one are you on?

Microsoft 365 gives you two ways to enforce basic sign-in protection, and they cannot run together. Security Defaults is the free, all-or-nothing baseline that comes with every tenant. It pushes everyone to register for MFA, protects administrators, and blocks legacy authentication. It is a solid starting point for a very small team, and it is better than nothing.

Conditional Access is the version you can tune. You can exempt a named emergency account, treat a shared front-desk device differently, require a compliant laptop for SharePoint, or block sign-ins from countries where you have no staff. The trade-off is that you carry the responsibility for getting the design right.

Ask yourself three questions. Do you have more than a handful of staff? Do you use shared mailboxes, scanners, or devices that cannot do MFA? Do you hold client data that a cyber insurer or a client may ask you to protect? If the answer to any of them is yes, Security Defaults is likely too blunt, and you should move to Conditional Access. When you do, turn Security Defaults off only after your replacement policies are live, otherwise you leave a gap.

Licensing: what you need before you start

Conditional Access needs Microsoft Entra ID P1 as a minimum. Microsoft 365 Business Premium includes it, which is why Business Premium is the default recommendation we give to Australian businesses with up to 300 users. Microsoft 365 Business Basic and Standard do not include it, so a business on those plans is usually limited to Security Defaults.

The risk-based features, meaning policies that react to a sign-in being scored as risky or a user being flagged as compromised, need Entra ID P2. That is included in Microsoft 365 E5 or available as an add-on. Not every business needs it on day one. A well-built P1 baseline covers most of the practical risk for a firm of 10 to 100 people.

Before you design anything, confirm what each user is licensed for. A policy that targets "all users" will quietly fail to apply risk conditions to anyone without P2, and a mismatch between what you think is protected and what actually is can sit unnoticed for months. Our Microsoft 365 hardening checklist is a useful companion for confirming the rest of your tenant settings.

The seven-policy baseline for Australian small and mid-sized businesses

You do not need forty policies. A small, readable set is easier to test, easier to explain to an auditor, and far less likely to lock out your own people. This is the baseline we start from.

Why this order

Policies 1 to 4 are the foundation, and they line up closely with the managed policies Microsoft is introducing. Policy 5 is a cheap, high-yield filter, as long as you maintain the exception process for staff who travel. Policy 6 is where Conditional Access starts to protect data rather than just logins, and it is the one that needs the most preparation because it depends on your devices being enrolled and compliant.

What good looks like for MFA

Not all MFA is equal. Text messages and approve-or-deny prompts are better than nothing, but they are the methods attackers are best at bypassing. Where you can, move toward number matching in the Authenticator app, then passkeys or FIDO2 security keys for administrators and finance staff. We covered what changes when Microsoft starts turning on passkeys by default and what to check first.

Emergency access accounts: the policy exception you must get right

Every Conditional Access design needs a way back in if the policies themselves go wrong. That is the job of emergency access accounts, often called break-glass accounts. They are cloud-only Global Administrator accounts that are excluded from your Conditional Access policies, so that a misconfiguration, an MFA outage or a lost phone cannot lock every administrator out at the same time.

The practical rules are simple:

• Create two accounts, not one. Use the onmicrosoft.com domain, not your company domain, and do not tie them to a person.
• Use very long, random passwords. Store them in two separate secure places, such as a sealed envelope in a safe and a password vault with restricted access.
• Exclude them from every policy. That includes the Microsoft-managed ones. Microsoft's own guidance says to exclude break-glass accounts from managed policies as you would any other.
• Alert on every use. A sign-in from one of these accounts should trigger an immediate alert to at least two people. If nobody is meant to be using it, any sign-in is an incident.
• Test them twice a year. An untested break-glass account is a hope, not a control.

The excluded accounts are also the first thing an attacker will look for. Treat the exclusion list as a sensitive asset, review it every quarter, and make sure nobody quietly adds themselves to it for convenience.

The rollout plan: four weeks using report-only mode

Report-only mode is the feature that makes this safe. A report-only policy evaluates every sign-in and records what it would have done, without blocking anyone. Microsoft's own managed policies start in this state for the same reason. The sign-in logs and the policy impact view then show you who would have been blocked and why.

Week 1: Inventory and clean-up

List your Global Administrators and confirm each one is a real, current person. Create the two emergency access accounts. Check for any existing policies, including anything named "Microsoft-managed". Identify who is still using legacy authentication by reviewing the sign-in logs. Old scan-to-email setups and line-of-business apps are the usual culprits. If you have a printer or scanner relying on basic authentication, our note on Microsoft switching off basic auth explains what to fix.

Week 2: Create the policies in report-only

Build policies 1 to 4 and set all of them to report-only. Do not exclude anyone other than the emergency accounts yet, because you want the logs to show you everything that would have been affected. Leave them running for the whole week so that you capture a full cycle, including month-end processing and any weekend or after-hours jobs.

Week 3: Read the results and build your exceptions

Open the policy impact view and the sign-in logs. For each sign-in that would have been blocked, decide whether it is an attack, a mistake, or a legitimate system that needs a fix. Most of the legitimate cases can be solved by updating the app, moving to modern authentication, or registering the user for MFA. Only the genuine edge cases should become named exceptions, and each one should have an owner and a review date.

Week 4: Enforce in stages

Switch on the least disruptive policy first, which is usually blocking legacy authentication, then administrators, then all users. Roll out to a pilot group of IT and a few friendly staff before the whole company. Pick a Tuesday or Wednesday morning, not a Friday afternoon, and make sure someone is watching the help desk queue. Keep the report-only copies of the later policies running while you do this, so the evidence for the next stage keeps building.

Build a lockout map before you enforce anything

Most Conditional Access outages come from the same short list of accounts and devices that nobody thought about. Before you flip any policy to on, write down every one of these and decide how it will be handled.

• Service and automation accounts. Backup tools, scripts and integrations that sign in without a human. These often cannot do MFA, so they need a managed identity, an app registration with a certificate, or a tightly scoped exception.
• Shared mailboxes and room devices. Teams Rooms systems and front-desk shared devices may need a scoped exception to the device code and MFA policies.
• Scanners, copiers and line-of-business apps. Anything still using IMAP, SMTP or POP3 will break when legacy authentication is blocked.
• Contractors and guests. External accountants, bookkeepers and vendors sign in from devices you do not manage. Decide whether they get MFA only or device controls too.
• Staff who travel. If you block countries, you need a fast, documented way to approve a trip, and a check on who is travelling over the busy periods.
• Executives and finance. The people most likely to be impersonated are also the people most likely to demand an exception. Hold the line, and offer a better sign-in method instead.

A lockout map takes about an hour for a small business, and it turns a risky change into a predictable one. It also gives you the exact paper trail that an auditor or insurer will ask for later.

Six mistakes we see again and again

• Enforcing without report-only testing. The fastest route to a Monday morning where half the office cannot sign in.
• Leaving Security Defaults on while building policies, or turning it off too early. Both leave you either blocked from creating policies or exposed in the gap.
• Excluding too many people. Every exclusion is a hole. A permanent exception for "the directors" is how breaches start.
• Forgetting the Microsoft-managed policies. They change your tenant on a schedule you do not control, and the notice is easy to miss.
• Treating it as a one-off project. Staff change, apps change and Microsoft changes the defaults. A quarterly review keeps the policies honest.
• Protecting logins but not devices. A perfect MFA policy does little if the laptop signing in is unmanaged and already infected.

How this fits Essential Eight and cyber insurance

Conditional Access is not a named control in the ASD framework, but it is how you deliver several of them in Microsoft 365. Multi-factor authentication and restricting administrative privileges are both among the Essential Eight, and Conditional Access is where MFA is enforced and where admin sign-ins are tightened. If you are mapping your environment to the framework, our Essential Eight guide for Australian SMBs shows where each control sits.

Cyber insurance applications now routinely ask whether MFA is enforced for all users, whether legacy authentication is blocked, and whether administrator accounts are protected separately. A documented Conditional Access baseline lets you answer those questions truthfully and quickly. It is also worth reading what your policy actually requires, as covered in our piece on cyber insurance in Australia.

Identity is also the thread that links your other defences. Strong sign-in controls protect the mailboxes that DMARC is trying to stop attackers impersonating, and they cut off the account takeover that usually comes first in a business email compromise. When staff leave, the same rules make it simpler to follow a proper digital offboarding checklist.

When to bring in a managed IT partner

Many small businesses can handle policies 1 to 4 themselves with this guide and a quiet fortnight. The point to get help is when you have shared devices, a legacy line-of-business system, several offices, compliance obligations such as APRA or the Privacy Act, or no one who can safely own the exception list over time.

A good partner will do four things: audit what is in your tenant today including the Microsoft-managed policies, build and test the baseline in report-only, enforce it in stages with your team, and monitor the sign-in logs and exclusions on an ongoing basis. That last part is the one that tends to get dropped, and it is where the long-term value sits.

Written by Caleb Attard, All IT Services. All IT is a Sydney-based managed IT provider supporting hospitality, not-for-profit and financial services organisations across Australia.