A stolen password can open a Microsoft 365 tenant from almost anywhere. By leveraging the power of Microsoft Entra ID, businesses can implement conditional access rules to reduce that risk by checking the sign-in context before the platform will grant access to sensitive data.
For Australian businesses, the goal is to adopt a Zero Trust security philosophy. This means creating a framework where you allow staff to work securely across offices, sites, homes, and customer locations while using advanced access controls to stop high-risk sign-ins to Exchange Online, SharePoint, Teams, Azure, and other business apps.
The strongest policies are carefully scoped, tested in report-only mode, and supported by well-managed identities and devices.
Microsoft Entra Conditional Access evaluates security signals at sign-in time to enforce Zero Trust principles. It uses an “if this, then that” model: if a user meets certain conditions, Microsoft applies specific access controls.
A policy can consider the user or group, cloud app, device platform, IP location, device state, authentication method, and assessed sign-in risk. Based on these conditions, conditional access policies can require MFA, demand a compliant device, require a password change, set a sign-in frequency, or block access entirely.
For example, a finance employee signing in to Exchange Online from an unmanaged personal computer could be required to use MFA and a compliant device. If they cannot meet both requirements, the system will block access to protect sensitive data. Meanwhile, the same person could access a low-risk internal app under a different set of access controls.
Conditional Access sits between identity and the resource. It does not replace endpoint security, email protection, backups, or user awareness training. Instead, it makes identity management responsive to the context of each request.
Microsoft calls Conditional Access its policy engine in the Microsoft Entra Conditional Access overview. That description matters because policies work across many Microsoft cloud services rather than inside one product.
For a typical business, this reaches:
Older documentation and internal naming may still refer to Office 365. Microsoft now uses Microsoft 365 for the broader cloud suite, but the identity risks remain the same.
Conditional Access should make a stolen credential less useful, not make legitimate work impossible.
Policies need more than a technical trigger. They need an agreed business purpose. A rule that blocks personal devices may suit a professional services firm handling client documents. It may frustrate a construction business where site managers rely on mobile access, unless managed mobile devices are already available.
Effective security starts with the right foundation. Microsoft Entra ID licensing is a prerequisite for these features, and in most business scenarios, Microsoft Entra ID P1 supports core capabilities. Because Microsoft 365 Business Premium includes these features, it serves as a common starting point for smaller Australian organisations looking to implement robust controls.
Microsoft Entra ID P2 adds advanced identity protection, which includes automated user risk and sign-in risk policies. These features leverage Microsoft security signals to detect events like unfamiliar sign-in properties, leaked credentials, or suspicious activity.
Always confirm your licensing before configuring risk-based rules. Assigning a P2 feature to users without the required licences creates both technical and compliance problems, so keep a clear record of who receives each licence and why.
Clean up the tenant before building policies. Remove stale accounts, disable former staff accounts, review guest access, and identify service accounts. Even the most sophisticated conditional access policies cannot compensate for poor identity records.
You should also define clear ownership. Someone must approve policy changes, another person should be able to recover access, and the service desk needs a well-defined process when staff are blocked. A descriptive naming pattern is invaluable during an urgent support call. Use a consistent format that identifies the purpose and audience, such as:
CA | All Users | Require MFA | Microsoft 365
CA | Administrators | Phishing-resistant MFA | All Cloud Apps
Avoid naming policies after the person who created them. People change roles, while the purpose of your conditional access policies should remain clear to anyone managing the environment.
Security Defaults can provide baseline protection for tenants that do not use Conditional Access. However, Microsoft does not support using Security Defaults and Conditional Access together. Once your business requires targeted rules, device requirements, or location-based logic, plan a controlled move to a full implementation.
A badly scoped policy can lock out every administrator in a tenant. The safest design for conditional access policies starts with recovery options, exclusions, and staged enforcement.
Create at least two cloud-only break glass account entries. Store their long passwords securely, use strong phishing-resistant authentication where possible, and keep them outside everyday administration.
Exclude these accounts from policies that could block recovery. That exclusion should be narrow and deliberate, following the principle of least privilege. Do not exclude all global administrators or an entire IT group simply because an emergency account exists.
Test the accounts on a planned schedule. Confirm that authorised staff can sign in, that credentials are current, and that authentication methods still work. An untouched account can fail when it is needed most.
Microsoft’s emergency access account guidance provides a sound reference for setup and monitoring.
Avoid assigning a new policy to “All users” on day one. Create pilot groups that reflect actual work patterns. Include IT staff, office workers, remote employees, mobile users, and people with different device types.
Run the rule against a pilot group first. Then expand in stages after reviewing the sign-in impact. This process reveals hidden dependencies, such as a legacy email client, a shared device, or a vendor application that uses an older authentication flow.
Group-based assignments also make change control easier. When staff move into a sensitive role, group membership can bring the appropriate access conditions with it.
Legacy authentication protocols do not support modern MFA well. They are common targets for password-spray attacks because they can bypass modern authentication prompts.
Create a policy that blocks legacy authentication for all users, with tightly controlled exclusions only where a documented technical dependency remains. Each exception needs an owner and review date.
Use the Microsoft guidance on blocking legacy authentication to identify affected clients before enforcement. In many tenants, this policy is one of the clearest early risk reductions.
A mature environment can contain many policies. Most organisations should begin with a handful of conditional access policies that address common attack paths and fit everyday work.
The following policy patterns provide a practical foundation.
| Policy purpose | Typical assignment | Grant or block control | Licensing consideration |
|---|---|---|---|
| Require MFA | All users, selected cloud apps or all cloud apps | Require multifactor authentication | Entra ID P1 |
| Secure administrators | Directory roles or privileged groups | Require phishing-resistant MFA | Entra ID P1 |
| Require managed devices | Users accessing Microsoft 365 data | Require device compliance | Entra ID P1 and Intune |
| Restrict risky sign-ins | Users with P2 licences | Require MFA or block high sign-in risk | Entra ID P2 |
| Limit location-based access | Sensitive groups or apps | Block or require stronger controls | Entra ID P1 |
These policies should work together without duplicating controls or creating confusing exclusions.
Multifactor authentication is the first security layer most businesses create. However, simply requiring a prompt does not mean every method offers the same protection. SMS and voice calls may be useful during a transition, but they are more exposed to phishing and SIM swap attacks than modern methods.
For most staff, Microsoft Authenticator with number matching offers a practical starting point. For administrators and high-value roles, use an authentication strength that requires phishing-resistant methods. Options can include FIDO2 security keys, passkeys, Windows Hello for Business, and certificate-based authentication where it fits the environment.
A strong baseline policy might include all users and all cloud apps, while excluding only emergency access accounts. Begin in report-only mode, then address users without registered methods before turning it on.
Avoid a broad exclusion for users working from the office. Corporate network access does not make a stolen password safe. Attackers can use compromised devices, VPN services, or internal access paths.
For administrators, use a separate policy rather than relying on the general user rule. Target Microsoft Entra roles, require multifactor authentication, and apply it to all cloud apps. Privileged roles can change settings, create accounts, and access broad data sets, so their sign-in standard should be higher.
Microsoft’s authentication strengths documentation helps match accepted methods to each policy.
A rule requiring managed devices gives Conditional Access information it cannot get from a password alone. Microsoft Intune can assess whether a device meets your defined compliance policy, then report that state to Microsoft Entra ID.
For Windows devices, device compliance settings might require BitLocker encryption, a supported operating system version, Microsoft Defender Antivirus, firewall protection, and a low or acceptable device risk score. Mobile policies can require encryption, a PIN or biometric lock, and a supported version of iOS or Android.
Once Microsoft Intune reports compliance, these conditional access policies can require a device be marked as compliant before allowing access to Exchange Online, SharePoint, and OneDrive. This helps prevent company files from being synced to unmanaged hardware.
Start with a limited scope. Pilot the rule with managed devices first, then include mobile platforms after users have enrolled and met compliance requirements. If a device is marked non-compliant, users need clear instructions and a support route.
For bring-your-own-device scenarios, requiring a compliant device may be too restrictive. App protection policies can provide another option for iOS and Android. These policies protect work data inside approved apps without fully enrolling the personal device.
Do not confuse device registration with compliance. A device can appear in Entra ID but still fail the requirements that Conditional Access checks. Review both Intune device records and sign-in logs when troubleshooting.
Location-based policies use named locations, usually trusted public IP ranges or countries and regions. They can be useful, but IP location controls are not a substitute for multifactor authentication and device management.
An Australian company may create trusted named locations for permanent offices, data centres, and known VPN egress addresses. It could then require MFA outside those locations, or block access from countries where it has no operations.
Before you block access based on geography, check your workforce and suppliers. Australian staff may travel, work overseas, or connect through corporate VPNs that exit in another region. Cloud service IP ranges also change, and mobile connections do not have fixed addresses.
For this reason, location blocks work best around clearly defined cases. An example is blocking access to an Azure administration application from locations where the business has no staff, while retaining MFA and device requirements everywhere.
Treat GPS-style accuracy as unavailable. Entra evaluates IP geolocation, which can be wrong or affected by VPNs, mobile carriers, and proxy services. Review the named location list after office moves, network provider changes, or VPN redesigns.
Microsoft Entra ID Protection identifies signals that may indicate credential compromise. Conditional Access can use two related conditions: sign-in risk and user risk.
Sign-in risk concerns the current authentication event. A medium or high sign-in risk policy can require MFA to prove the person is legitimate. If the user completes MFA, they can continue without a helpdesk call in many cases.
User risk concerns the account’s assessed likelihood of compromise. A high user-risk policy can require a secure password change. This gives the user a recovery path while replacing a password that may have appeared in a leak.
Set risk thresholds conservatively at first. Review detections and false positives in your tenant before adopting aggressive blocks. A high-risk sign-in to an administrator portal may justify blocking access, while a staff member accessing standard Microsoft 365 apps might first be challenged for MFA.
Risk policies need Microsoft Entra ID P2. They also work best when MFA registration, password reset, and support procedures are already reliable. Otherwise, a valid recovery control turns into an avoidable lockout.
Report-only mode lets you assess how your conditional access policies would affect sign-ins without enforcing the grant or block control. Use this setting for every significant new policy, including changes to an established rule, to ensure you understand how the system will grant access before moving to full enforcement.
In the Microsoft Entra ID admin center, review the policy impact through sign-in logs. Look for users who would have been blocked, the applications involved, device information, location details, and the specific control that would have applied.
Pay close attention to non-interactive sign-ins, mobile mail clients, shared devices, automated workflows, and third-party applications. A policy that looks correct for browser sign-ins can disrupt a process that uses a different authentication path.
A practical rollout sequence is:
Do not treat results from report-only mode as a reason to exempt every failed sign-in. Investigate the reason first. A failure might expose an unsupported client, an unmanaged endpoint, or an old process that needs redesign.
Microsoft provides a Conditional Access What If tool for modelling a proposed sign-in. Use it before deployment, but do not rely on it alone. Real sign-in logs show actual application and device behaviour.
Conditional access policies require ongoing review. New staff, acquisitions, device refreshes, new locations, and SaaS integrations can all affect sign-in patterns.
Review your settings at least quarterly, and after any major Microsoft 365 or Azure project. Confirm that exclusions still have a business reason, named locations remain accurate, and pilot policies have either progressed or been retired.
Sign-in logs should feed normal security operations. Correlate unusual access with alerts from Microsoft Defender for Endpoint, Defender for Office 365, and Microsoft Sentinel where those products are deployed. A risky sign-in means more when it appears beside a device alert or suspicious mailbox activity.
The Australian Cyber Security Centre Essential Eight also provides useful context. Conditional Access supports MFA and critical access controls, but it does not replace patching, application control, backups, and incident response.
Document every exception. Record who approved it, the affected account or app, why it is needed, and when it expires. Temporary exceptions tend to become permanent when nobody owns the review.
Report-only mode allows you to simulate the impact of a new policy on your actual traffic without blocking any users. This is critical for identifying potential disruptions to legacy applications or unusual authentication flows before you enforce strict access controls.
No, you cannot use both at the same time. Microsoft does not support the concurrent use of these features, so you should plan a controlled migration to Conditional Access once your business requires custom rules or device-specific requirements.
Emergency access or “break glass” accounts act as a safety net if your primary authentication or policy configuration fails. Excluding these accounts ensures you can always regain control of your tenant even if a misconfigured policy blocks all other administrative access.
No, Conditional Access focuses on managing access based on identity and device state, not endpoint threat detection. It works best as one layer of a broader strategy that includes tools like Microsoft Defender for Endpoint, email protection, and regular security awareness training.
Conditional access rules give Australian businesses a practical way to apply security based on risk, device health, and user role. By implementing these controls, you move your organization toward a robust Zero Trust framework where every access request is verified. The best results come from simple policy goals, narrow exclusions, and evidence from real sign-in logs.
Start with strong MFA, protect administrators more tightly, and connect Intune compliance to access decisions. Then add location and risk-based policies after your team understands the tenant’s normal behaviour.
A policy is only trustworthy when it has been tested, monitored, and reviewed. Using report-only mode and emergency access accounts makes that discipline possible without turning security improvements into a tenant-wide outage.