Intune Device Compliance for Australian Businesses: A Microsoft 365 Guide

Intune device compliance for Australian businesses sounds like a technical setting, but it answers a simple question: should a laptop or phone be allowed to open your company email and files? Out of the box, Microsoft 365 answers yes to almost everything, and that default is the problem this guide fixes.

This guide is for the owner, office manager or IT lead who wants a practical baseline without a six-month device project. It explains what compliance policies do, the one tenant setting that quietly lets unmanaged devices through, the seven checks we start from, and a five-week rollout that avoids locking out your own people.

What Intune device compliance for Australian businesses means, and why it matters now

Intune is Microsoft's device management service. A compliance policy inside Intune is a short list of rules a device must meet, such as disk encryption turned on, a firewall running, antivirus active and an operating system that is recent enough. Intune checks each enrolled device against those rules and gives it a status: compliant or not compliant.

That status is only useful when something acts on it. Microsoft Entra ID, through Conditional Access, can require a compliant device before it lets anyone open Outlook, Teams, SharePoint or OneDrive. Put the two together and you get a clear rule for your business: company data only opens on devices that meet your standard.

It matters more now for three reasons. Staff work from home, cafes and client sites, so the office network no longer vouches for anyone. Attackers increasingly steal sessions and credentials rather than break in, as we covered in our guide to Conditional Access for Australian businesses. And cyber insurers and clients now ask whether you can prove that the laptops touching their data are encrypted, patched and protected. A device compliance baseline lets you answer with evidence instead of confidence.

The setting most tenants never change: unmanaged devices pass by default

Here is the angle we think most Australian small businesses miss. Intune has a tenant-wide setting called "Mark devices with no compliance policy assigned as". Its default value is Compliant. In plain English, if a device is enrolled but has no compliance policy aimed at it, Intune treats it as meeting the standard.

Think about what that means in practice. You write a careful Windows compliance policy and a Conditional Access rule that requires a compliant device. Then someone enrols a Mac, or a phone, or a Windows device that falls outside the group your policy targets. That device has no applicable policy, so it is marked compliant by default, and it walks straight through the gate you thought was locked.

Intune also applies a built-in default compliance policy to every enrolled device. It checks three things: that a compliance policy is assigned, that the device is active and talking to Intune, and that an enrolled user exists with a valid licence. A device must pass this built-in check and your own policies to be marked compliant. The built-in check is useful, but it does not replace a real security baseline.

The fix is short. Set the "no compliance policy assigned" setting to Not compliant, after you have made sure every platform you manage has a policy. Do the order carefully: policies first, then the setting, otherwise you will mark your own staff devices as failing on a Monday morning. If you do only one thing after reading this guide, open the Intune admin centre, check that setting, and write down what it says.

Compliance policy, configuration profile, Conditional Access: three jobs, one outcome

Small businesses often mix up three different Intune and Entra features, and the confusion leads to gaps. They each do a separate job.

A good baseline uses all three together. A configuration profile turns encryption on. A compliance policy confirms it is on. Conditional Access refuses access when it is not. If you only build the compliance policy, you have a report. If you only build Conditional Access, you have no way to tell good devices from bad ones.

Licensing and prerequisites before you start

Conditional Access needs Microsoft Entra ID P1 at a minimum. Microsoft 365 Business Premium includes both Intune and Entra ID P1, which is why Business Premium is the default recommendation we give to Australian businesses with up to 300 users. Business Basic and Standard do not include Intune, so those tenants cannot enforce device compliance without buying extra licences.

Before you design anything, confirm what each user is licensed for, and confirm who your Global Administrators and Intune administrators are. Compliance and access rules only apply to users who hold the right licence, 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 basics first.

You also need a way to get devices into Intune. For new Windows laptops, Windows Autopilot lets a device enrol itself the first time a staff member signs in. For existing devices, you can enrol them through the Company Portal or through work account sign-in. Whichever route you pick, a device that never enrols is invisible to every rule in this guide, which is why the truth table later in this guide matters.

The seven-check Windows compliance baseline

ASD's Blueprint for Secure Cloud describes the compliance checks it expects for Windows 10 and 11: device health, device properties, system security and, where you use it, a Microsoft Defender for Endpoint risk score. You do not need dozens of rules. A short list that people understand is easier to test and far less likely to lock out your own team. This is the baseline we start from for Windows.

Resist the urge to add a password complexity rule on top of this unless you have a reason. Most staff sign in with Windows Hello and a PIN, and a conflicting password rule is one of the most common causes of devices flipping to non-compliant for no obvious reason. Add rules one at a time and watch what happens before adding the next.

Treat the minimum OS version as a living number. It should rise as Microsoft releases updates, which means somebody needs to own it. The older Windows 10 fleet is a separate and bigger issue, covered in our article on Windows 10, ESU costs and Secure Boot.

Phones, tablets and Macs: keep the rules short

Windows is usually where the biggest risk sits, but it is rarely the only platform. Staff read email on iPhones and Android phones, designers use Macs, and tablets live in meeting rooms. Each platform needs its own compliance policy, and that is exactly where the default setting bites, because a platform with no policy passes automatically.

For phones and tablets, keep it short: require a PIN or biometric, require a minimum operating system version, and block devices that are jailbroken or rooted. For Macs, require disk encryption with FileVault and a firewall. That is enough for most small businesses, and it is easy to explain to staff.

Personal phones deserve a separate decision. Many small teams do not want to manage a personal device end to end, and staff will rightly push back. A common approach is to use app protection policies for personal devices, which protect the company data inside Outlook and Teams without taking control of the whole phone, and to keep full compliance rules for company-owned devices. Choose the approach on purpose and write it down, rather than letting it happen by accident.

Grace periods, validity windows and the "not real time" trap

Two timing behaviours cause most of the confusion after go-live. The first is the grace period. You can give a non-compliant device a window to fix itself before it loses access. For a small business, a short grace period for ordinary issues, such as a pending update, is kind to staff. A long one quietly defeats the purpose, so set it deliberately and review it.

The second is validity. Intune expects devices to report in on their assigned policies within a set number of days. A device that stops reporting is marked not compliant once that window passes. The most common cause is a laptop that sat in a drawer or a cupboard for a few weeks, which then fails the first time somebody opens it. Define the validity period on purpose rather than accepting whatever is there.

The rollout plan: five weeks, no surprise lockouts

The safest way to introduce device compliance is in stages, with each stage visible to the people it affects. This five-week plan suits a business of 10 to 150 people.

Week 1: inventory and decisions

Build the device truth table described in the next section. Decide your standard for company-owned and personal devices, name an owner for the minimum OS version, and pick two or three pilot users from different roles, ideally including one person who travels and one who uses a shared device.

Week 2: policies in monitor mode

Create the compliance policies and assign them to the pilot group only. Do not yet create a Conditional Access rule that blocks anyone. Watch the results in the Intune admin centre, fix the common causes of failure, and note any device that fails for a reason you did not expect.

Week 3: widen the policies

Assign the policies to every user and every platform you manage, and keep the "no policy assigned" setting at its default for now. The aim is for every device to have a policy before you remove the safety net. Review the non-compliant list daily and talk to the people on it.

Week 4: Conditional Access in report-only mode

Create the Conditional Access rule that requires a compliant device, and set it to report-only mode. It logs who would have been blocked without blocking anyone. Review the sign-in logs against your truth table and fix the exceptions, such as shared devices, kiosks and meeting-room systems.

Week 5: enforce, then close the gap

Turn the rule on for the pilot group, then for everyone, and then change the "no compliance policy assigned" setting to Not compliant. Keep two emergency access accounts excluded from the rule so a misconfiguration can never lock every administrator out at once. Tell staff what is changing, and who to call.

Build a device truth table before you enforce anything

Before you enforce anything, list every device that touches company data and write down four facts for each: who uses it, who owns it, which platform it runs, and whether it is enrolled in Intune. This is your device truth table, and it is the single most useful document in the project.

It is usually uncomfortable. Most businesses find devices nobody remembered: the old laptop used by the part-time bookkeeper, the tablet in the warehouse, the personal phone of a director, the shared PC at reception. Each one is a decision. Enrol it, replace it, restrict it to a web-only experience, or remove its access.

Compare the table with the list in Intune and with the sign-in logs in Entra. Devices that appear in the logs but not in Intune are the ones the default setting would currently wave through. Those are the ones to fix first.

Six mistakes we see again and again

• Leaving the default setting alone. Unmanaged and unpolicied devices are treated as compliant, so the gate has a side door nobody locked.
• Building policies without Conditional Access. A compliance dashboard that blocks nothing is a report, not a control.
• Enforcing before testing. Skipping report-only mode is how an otherwise good project locks the owner out on the first morning.
• Forgetting shared and special devices. Reception PCs, meeting-room systems and kiosks usually cannot meet the same rules as a personal laptop, and they need a planned exception.
• Setting the minimum OS version once and forgetting it. Without an owner, the number goes stale and the rule stops meaning anything.
• Ignoring leavers. When staff leave, their devices and access should go with them. A proper digital offboarding checklist keeps the device list honest.

How this fits Essential Eight and cyber insurance

Intune compliance is not a named control in ASD's framework, but it is one of the ways you deliver several of them in Microsoft 365. Patching operating systems, restricting administrative privileges and multi-factor authentication all depend on knowing which devices are in play and what state they are in. If you are mapping your environment to the framework, our Essential Eight guide for Australian SMBs shows where each control sits, and our transition roadmap covers what changes as ASD moves to its Essentials series.

Cyber insurance applications now routinely ask whether laptops are encrypted, whether devices are patched, and whether unmanaged devices can reach company data. A documented compliance 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.

Device compliance also supports your other defences. Compliant devices make it harder for stolen credentials to be used from an attacker's machine, which strengthens the identity controls in our DMARC guide and in the groundwork for a safe Copilot rollout. For organisations with legal duties under the Privacy Act, being able to show that devices holding personal information are encrypted and controlled is a practical part of taking reasonable steps.

When to bring in a managed IT partner

Many small businesses can build the Windows baseline themselves with this guide and a quiet month. The point to get help is when you have a mixed fleet of Windows, Mac and mobile devices, shared or special-purpose devices, several offices, compliance obligations such as APRA or the Privacy Act, or nobody who can safely own the policy over time.

A good partner will do four things: audit the devices and policies in your tenant today, build and test the baseline in stages, enforce it with your team and communicate clearly with staff, and keep watching the non-compliant list, the exclusions and the minimum OS version. That last part is the one that tends to get dropped, and it is where the long-term value sits. If you are weighing providers, our guide to choosing the right MSP lists the questions to ask.

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