How to set up Microsoft Intune and enrol your first devices (Australian setup guide)

Microsoft Intune is the point where a Microsoft 365 tenant stops being an email and documents platform and starts being a managed environment. Once devices are enrolled, an organisation can enforce encryption, require a minimum operating system version, push security settings, and block company data from reaching a device that doesn't meet the standard. The problem most first-time administrators hit is that the setup path isn't a single wizard. It's a sequence of small decisions spread across the Microsoft Intune admin center and Microsoft Entra ID, and skipping one of them tends to surface later as devices that won't enrol or policies that never apply.

This guide covers the full path for a first deployment: what Intune actually does, the licensing you need, the first-time configuration in the admin center, how the Windows enrolment methods differ, a step-by-step enrolment of a Windows 11 device and an iPhone, and the compliance and Conditional Access controls that turn enrolment into an actual security outcome. It's written for an internal IT lead or business owner setting Intune up for the first time, not for an environment that already has a mature configuration.

What Microsoft Intune is

Microsoft Intune is the cloud-based device and application management service inside Microsoft 365. It handles mobile device management (MDM), where the whole device is enrolled and managed, and mobile application management (MAM), where only the corporate apps and data on a device are managed without touching the rest of it. For a business, that means it's the tool that controls which devices can access company data and what state those devices have to be in to keep that access.

Intune is managed almost entirely from the Microsoft Intune admin center at intune.microsoft.com. It shares an identity backbone with Microsoft Entra ID (the service formerly named Azure Active Directory), which is where user accounts, groups and device identities live. That relationship matters throughout setup: enrolment, automatic enrolment and Conditional Access all depend on how devices and users are represented in Microsoft Entra ID. An administrator new to Intune should expect to move between the two admin centres regularly.

A quick note on licensing

Microsoft Intune is included with Microsoft 365 Business Premium as Intune Plan 1, which is the edition most small and mid-sized Australian businesses will already own. It's also included in the Enterprise Mobility + Security E3 and E5 bundles and in Microsoft 365 E3 and E5. Intune Plan 1 covers everything in this guide: device enrolment, compliance policies, configuration profiles and Conditional Access. Higher tiers and the Intune Suite add capabilities such as advanced endpoint analytics and remote help, but none of those are required to get first devices enrolled and protected. Frontrow's separate article on Microsoft Intune licensing in Australia sets out the plan comparison and the add-ons in detail, so this guide keeps to the assumption that a Business Premium or equivalent licence is already in place.

First-time setup in the Microsoft Intune admin center

Confirm the MDM authority

Historically, the first Intune setup step was to set the MDM authority, the tenant-level setting that tells Microsoft 365 which service is responsible for managing devices. For any tenant created in recent years, this is already set to Microsoft Intune automatically and needs no action. It's only worth checking on older tenants that were once managed by another platform or by on-premises Configuration Manager. If a tenant does still show the MDM authority as unset or pointing elsewhere, it must be set to Microsoft Intune before enrolment will work, but the vast majority of new administrators will find nothing to change here.

Turn on automatic enrolment (the MDM user scope)

Automatic enrolment is the setting that makes a Windows device enrol into Intune by itself when a user signs in with a work account and joins the device to Microsoft Entra ID. Without it, every Windows enrolment becomes a manual step. This is configured through the Windows enrolment options, and the key control is the MDM user scope, which has three settings:

• None, automatic enrolment is off for everyone. Devices can still be enrolled manually, but nothing happens automatically on Entra join.
• Some, automatic enrolment applies only to the users in a nominated Microsoft Entra ID group. This is the recommended setting for a first rollout, because it lets a pilot group be enrolled before the whole organisation.
• All, automatic enrolment applies to every user in the tenant. Appropriate once the pilot is proven, but a large blast radius to start with.

1. 1Sign in to the Microsoft Intune admin center at intune.microsoft.com with an account that holds the Intune Administrator or Global Administrator role.
2. 2Go to Devices, then Enrolment, then select the Windows tab.
3. 3Open Automatic Enrolment.
4. 4Set the MDM user scope to Some for a pilot and choose a Microsoft Entra ID group containing your test users, or set it to All once you're ready for the whole organisation.
5. 5Leave the MDM terms of use URL, discovery URL and compliance URL at their defaults, and save.

The MAM user scope on the same screen governs app-level management for personal Windows devices and is a separate decision. For a first device rollout, leaving the MAM user scope at None and focusing on the MDM user scope keeps things simple. One caution: a single user shouldn't sit in both an MDM scope and a MAM scope for the same platform, as the two paths conflict.

Windows enrolment methods compared

There isn't one way to enrol a Windows device, there are three, and choosing the right one depends on who owns the device and whether it's a brand-new machine or one already in use. At a high level:

• Microsoft Entra join with automatic enrolment, best for corporate-owned devices being set up for the first time or reset. The user joins the device to Microsoft Entra ID during Windows setup or from Settings, and with automatic enrolment turned on the device enrols into Intune with no further steps. This is the method most first-time deployments should start with.
• Windows Autopilot, best for shipping new devices straight to staff without IT touching them first. Autopilot uses the device's hardware identity to deliver a pre-configured, self-provisioning setup experience out of the box. It's a deployment method rather than a separate management system, and it still results in an Entra-joined, Intune-enrolled device. Frontrow's dedicated Windows Autopilot deployment guide for Australian organisations covers the hardware hash import, deployment profiles and Enrolment Status Page in full, so this guide treats Autopilot as one option and doesn't repeat that detail.
• Manual enrolment, where an existing user connects a device from Settings, Accounts, Access work or school. Useful for a one-off machine or a device that's already in service, but it doesn't scale and offers the least control over the initial state.

Step by step: enrol a Windows 11 device

This is the Microsoft Entra join path for a corporate-owned Windows 11 device, the most common starting point once automatic enrolment is switched on. It assumes the user has a Microsoft 365 licence that includes Intune and is in scope for automatic enrolment.

1. 1On a new or freshly reset device, start the Windows 11 out-of-box experience and connect to a network. When prompted to sign in, enter the user's Microsoft 365 work account, which joins the device to Microsoft Entra ID.
2. 2For a device already in use, instead open Settings, Accounts, Access work or school, select Connect, then choose Join this device to Microsoft Entra ID and sign in with the work account.
3. 3Complete sign-in, including multi-factor authentication if prompted. Because automatic enrolment is on, the device enrols into Intune as part of this step, no separate enrolment action is needed.
4. 4Allow a few minutes for the first policy sync. Any compliance policies and configuration profiles assigned to the user or device begin applying during this window.
5. 5Confirm the result in the Microsoft Intune admin center under Devices, Windows, where the new device should appear with its enrolment and compliance state. On the device itself, Settings, Accounts, Access work or school will show it connected, with an Info button that can force a sync and display policy status.

Enrolling an iPhone or iPad (BYOD via the Company Portal)

Apple devices need one piece of setup before any iPhone or iPad can enrol: an Apple MDM push certificate. This is a certificate Intune uses to communicate securely with Apple's management service, and without it iOS and iPadOS enrolment simply won't proceed. It's created once in the admin center, is tied to an Apple ID (use a shared organisational Apple ID, not a personal one), and is valid for 365 days, so it has to be renewed every year using the same Apple ID or device management breaks.

1. 1In the Microsoft Intune admin center, go to Devices, Enrolment, then the Apple tab, and open Apple MDM Push certificate.
2. 2Grant Microsoft permission to send the required data to Apple, download the certificate signing request (CSR) that Intune generates, then sign in to the Apple Push Certificates Portal with the organisational Apple ID and upload the CSR to create a certificate.
3. 3Download the resulting certificate from Apple and upload it back into Intune, entering the Apple ID used so the renewal reminder is accurate.
4. 4For personal (BYOD) enrolment, the user installs the Intune Company Portal app from the App Store, opens it, and signs in with their Microsoft 365 work account.
5. 5The user follows the Company Portal prompts to download and install a management profile, which iOS asks them to approve in Settings. Once the profile is installed, the device is enrolled and reports its compliance state back to Intune.

For a personal iPhone, MDM enrolment is one option, but many organisations prefer app protection policies (MAM) that manage only the corporate apps and data and leave the rest of the phone untouched, which staff tend to accept more readily on a device they own. Either approach is valid; the push certificate is only required for full MDM enrolment, whereas app protection alone can apply without enrolling the whole device.

Compliance policies versus configuration profiles

New administrators frequently confuse these two, and the distinction is worth getting right early because it shapes everything that follows. A compliance policy checks a device against a set of rules and returns a verdict, compliant or not compliant. It changes nothing on the device itself; it only measures and reports. A configuration profile does the opposite, it delivers and enforces an actual setting, such as switching BitLocker on or setting a screen-lock timeout, and holds the device in that state, without reporting a pass or fail.

The two work as a pair. A configuration profile sets BitLocker; a compliance policy checks that BitLocker is on. On their own, compliance policies are just a report card, their value comes when Conditional Access uses the compliance verdict to decide whether a device is allowed near company data. A sensible first compliance policy for a Windows fleet checks three things:

1. 1BitLocker encryption, require the device's drive to be encrypted so a lost or stolen laptop doesn't expose company data.
2. 2Minimum operating system version, set a floor (for example, a current supported Windows 11 build) so devices missing months of security updates are flagged as non-compliant.
3. 3Microsoft Defender Antivirus, require that Defender is turned on and reporting healthy, so endpoints without working malware protection don't slip through.

Set the policy's action for non-compliance to give users a short grace period, for example, mark the device non-compliant a day or two after it first fails, rather than immediately, so genuine devices have time to remediate before access is affected. Assign the policy to a pilot group first, confirm the results are what you expect in the admin center, then widen the assignment.

Require a compliant device with Conditional Access

Enrolling devices and writing a compliance policy achieves little on its own if a non-compliant or unmanaged device can still reach Microsoft 365. Conditional Access is the control that closes that gap. It's a Microsoft Entra ID feature that evaluates each sign-in against conditions, then grants, blocks, or adds requirements to access. The pairing that matters here is a policy that requires a device to be marked as compliant before it can reach Microsoft 365 services.

1. 1In the Microsoft Entra admin center, go to Protection, Conditional Access, and create a new policy.
2. 2Under Users, start by targeting a pilot group rather than all users, and always exclude the break-glass emergency access accounts so a misconfigured policy can't lock everyone out.
3. 3Under Target resources, select the cloud apps to protect, commonly Office 365 as the starting set.
4. 4Under Grant, choose Grant access, then select Require device to be marked as compliant, and save the policy in report-only mode first.
5. 5Review the report-only impact in the sign-in logs to confirm the policy would behave as intended, then switch it to On and expand the user scope once you're satisfied.

The report-only step is not optional in practice. Conditional Access is powerful enough to block legitimate access if it's scoped wrongly, and the break-glass exclusion plus a staged rollout are what keep a first deployment safe. Once this policy is live, the full chain is complete: a configuration profile sets the control, a compliance policy verifies it, and Conditional Access enforces the consequence by keeping non-compliant devices away from company data.