Managing Macs With Intune: What Works and What Does Not

Intune can manage a Mac fleet properly. What it cannot do is keep your third-party Mac applications patched, and that single gap is usually what decides whether you need a second tool. Everything else in the Intune macOS story is better than its reputation suggests.

This is written for the business that already pays for Intune inside a Microsoft 365 subscription and would rather not buy and run a second management platform. That instinct is right more often than Apple-first consultants will admit.

The verdict, before the detail

If your Mac fleet is small, your application set is short and predictable, and nobody is auditing you against a control framework, Intune alone is enough. Buying a dedicated Apple MDM alongside it adds cost, a second console, a second set of enrolment records and a second thing to break.

Disclosure, because it is relevant to that verdict: we are a Jamf partner and a Microsoft partner, so we hold a commercial relationship on both sides of this question. We still tell most businesses in the position described above to stay on Intune alone, which is the cheaper answer for them and the smaller one for us.

Our rule of thumb, and it is professional judgement rather than a published benchmark: the trigger is not headcount, it is the application estate. Ten Macs running fifteen specialist creative or engineering applications will break Intune’s app model long before fifty Macs running Microsoft 365, a browser and a video conferencing client. If you can list every non-Apple, non-Microsoft application on your Macs on one hand, stay on Intune.

The trade-off is real: staying on Intune means you own the packaging and versioning of third-party Mac applications yourself, or you accept that they update themselves and you stop pretending you control that. Say which one you are choosing, in writing.

What Intune genuinely does well on macOS

Automated Device Enrolment and zero-touch setup. Intune links to Apple’s business portal, so a Mac bought through a participating reseller enrols itself out of the box and arrives supervised. Note the naming change: Apple replaced Apple Business Manager with a service called Apple Business on 15 April 2026, per Apple’s own announcement. The mechanics are unchanged and Intune’s enrolment token flow still works the same way. If you have not set that up, start with Apple’s business device portal before you touch Intune.

Platform SSO. This is the strongest thing Microsoft has shipped for the Mac. Platform SSO signs users into a managed Mac with their Microsoft Entra ID credentials, and with the Secure Enclave authentication method it is passwordless and hardware bound. Microsoft’s documentation states plainly that Secure Enclave “is considered password-less and meets phish-resistant multifactor (MFA) requirements” and is “conceptually similar to Windows Hello for Business”. It needs macOS 13.0 or newer, Company Portal 5.2404.0 or newer, and it is included with all Intune licensing plans.

One honest caveat from Microsoft’s own page: with Secure Enclave, the local account password is deliberately left alone, because FileVault uses the local password to decrypt the disk at startup. After a reboot the user still types the local password once. Touch ID works after that.

FileVault with escrowed recovery keys. Intune configures FileVault, escrows the personal recovery key, and surfaces it through the built-in encryption report. Key rotation is gated behind an RBAC right, so a help desk operator can retrieve a key without being a global administrator. Microsoft is candid that Intune’s FileVault settings “do not expose every FileVault capability”, so check the specific option you need exists before you promise it.

The settings catalog. Intune’s settings catalog exposes Apple’s declarative and profile settings directly, which means most things Apple publishes a payload for can be configured without hand-writing a mobileconfig file. This is a genuine change from the Intune of a few years ago and a lot of stale advice online predates it.

Compliance policy feeding Conditional Access. A Mac can be assessed for OS version, encryption status, firewall state and Defender health, and that compliance state can gate access to Microsoft 365 through Conditional Access. This is the single best argument for Intune on Macs: the same identity and access decision covers both platforms. It sits at the centre of endpoint security and device management for a mixed fleet.

Defender for Endpoint on Mac. Built on Apple’s system extension architecture, with web threat protection across Safari, Chrome, Firefox and Edge, network protection, and device control for removable storage now generally available. It is a real EDR product on macOS, not a token port.

Declarative software updates. macOS updates are now enforced through Apple’s declarative device management on macOS 14 and later, configured in the settings catalog, targeting a specific OS or build version with an enforced deadline. Apple has deprecated the older MDM software update workload and Microsoft recommends DDM. If you configure both, DDM wins.

Where Intune is genuinely weaker than a dedicated Apple MDM

Third-party application patching. This is the big one. Intune’s Enterprise App Catalog, the feature that discovers, packages and auto-updates non-Microsoft applications, is a Windows Win32 feature. There is no macOS equivalent. On the Mac you upload DMG, PKG or line-of-business packages yourself, and when the vendor ships a new version you upload it again. Nothing tells you a new version exists.

A dedicated Apple MDM either ships a maintained patch feed or plugs into the community tooling that does. Intune does not. In practice, Intune shops either script the gap or let applications self-update and accept the loss of control. Both are defensible. Neither is what a vulnerability scanner report will expect to see.

Scripting and inventory attributes. Intune supports shell scripts on macOS 12.0 and later, but only through the separate Intune management agent, only on devices with a direct internet connection (proxies are not supported), with a 1 MB script size limit and a hard 60-minute execution timeout. Run status is only reported when it changes, which makes troubleshooting slower than it should be.

Custom attributes are thinner still: the script runs every eight hours and the returned value must be 20 KB or less. Compare that with an Apple-first platform where extension attributes feed dynamic device groups that drive policy in near real time. If your operating model depends on “find every Mac where X is true and do Y”, Intune will frustrate you. This is the practical difference that shows up in how Jamf and Intune compare head to head.

Application control. Intune has no application allowlisting for macOS. Windows has Defender Application Control and AppLocker; the Mac has Gatekeeper, notarisation and XProtect, which are Apple’s controls, not yours. If you have a control requirement that says only approved software may execute, Intune will not get you there on the Mac and neither will a different MDM without a third-party product. We deal with that specifically when mapping the Essential Eight onto macOS.

Speed of support for new macOS releases. Microsoft’s published support policy is that Intune supports the three most recent major operating system versions, with older versions allowed to enrol but not guaranteed to work. That is a reasonable policy. What it does not promise is that a new setting Apple introduces at WWDC will be configurable in the settings catalog on the day the new macOS ships. Apple-first vendors compete on exactly that, and it matters if you deploy new hardware early or your users update themselves.

The practical consequence for an Australian business: Apple’s major macOS releases land in our spring, which is the same quarter as end-of-year project pressure. Plan a deferral window rather than assuming your MDM will keep up.

If you are staying on Intune, do these five things

1. Set the software update deferral and deadline through DDM, not through the deprecated MDM policy, and pick a deferral period you can actually support.
2. Decide your third-party patching position and write it down. Either you package and version applications yourself on a schedule, or you enable vendor auto-update and record that as an accepted risk. Undecided is the failure mode.
3. Deploy Platform SSO with Secure Enclave, not the password method, unless you have a specific reason otherwise. It is the phishing-resistant option and it costs nothing extra.
4. Confirm FileVault keys are actually escrowing by pulling a key from the encryption report for a real device. Escrow silently failing is common and only discovered when you need the key.
5. Get compliance policy wired into Conditional Access so a non-compliant Mac loses access to data rather than just showing red in a report.

If you want the full enrolment, policy and failure-mode picture rather than just the Intune slice, we cover the mechanics of running a Mac fleet separately, and the wider question of running Windows, Mac and Google in one business without standardising on one vendor.

Book a review of your existing Intune tenancy and we will tell you whether your Macs are actually managed or just enrolled, and whether a second MDM is worth the licence. Call 1300 028 324 or use the form at https://techassist.au/contact/. We will give you the answer even if the answer is that your current setup is fine.

Mac fleet management is the practice of enrolling company-owned Macs into a device management service so that configuration, encryption, updates and software deployment are controlled centrally instead of machine by machine. The technology is mature and Apple documents it thoroughly. What catches businesses out is that macOS enforces a set of user consent boundaries that Windows does not, and no amount of MDM licensing removes them.

If you are choosing a platform to do this with, that decision is covered separately in Jamf against Intune. This article is about what happens after you have chosen, on any platform, because Apple’s rules apply to all of them equally.

There are four enrolment paths and only one of them is any good

Apple currently defines these methods, and the differences are not cosmetic.

Automated Device Enrolment. The device is in your organisation’s account in Apple Business, formerly Apple Business Manager, and enrols itself during Setup Assistant. The Mac is supervised automatically, enrolment can be made non-removable, and no technician touches the hardware. This is the only path that produces a properly controlled Mac from first boot.

Account-driven Device Enrolment. Introduced for macOS in macOS 14. The user signs in with a Managed Apple Account on a Mac already in service. On Mac this does produce supervision, which is a Mac-specific behaviour worth knowing, and it gives you data separation. It is the best available option for machines already in the wild.

Account-driven User Enrolment. Designed for personally owned devices, macOS 14 and later. Not supervised, deliberately limited, and you can only remove managed data rather than wipe the device. Correct for genuine BYOD, wrong for company hardware.

Profile-based Device Enrolment. The old manual profile install. On macOS 11 and later this still yields a supervised Mac if a local administrator approves it, which surprises people who assume manual enrolment means unsupervised. It is fine as a fallback and poor as a strategy, because the user can remove it if they know a local admin password.

The practical consequence is the same one that shows up in procurement: get the Mac into Apple Business at the point of purchase and you get path one. Miss that and you spend the next three years working around it.

User Approved MDM gates the payloads you actually care about

macOS distinguishes between an enrolment the user approved and one they did not, and the distinction is not academic. Apple’s own device management schema flags a specific set of payloads as requiring user-approved enrolment, and marks them as impossible to install by hand. They include the ones that matter most:

• Privacy Preferences Policy Control, which is how you pre-authorise security agents
• Kernel Extension Policy and System Extensions
• FileVault
• Extensible Single Sign-On, including the Kerberos variant
• Managed Login Items and Background Task Management

Without user-approved enrolment, those payloads do not apply. Your endpoint detection agent does not get the access it needs, FileVault does not enforce, and single sign-on does not deploy. Automated Device Enrolment resolves this cleanly, because the Remote Management step in Setup Assistant is itself the approval, and Apple documents that devices enrolled this way are automatically allowed to use the bootstrap token for authentication.

MDM cannot grant camera, microphone or screen recording. Ever.

This is the single most useful thing an IT manager can know about macOS, and it is the one most often got wrong in vendor sales calls.

A Privacy Preferences Policy Control profile lets you pre-approve a long list of permissions: Full Disk Access, Documents and Desktop and Downloads folders, Apple Events, Contacts, Calendars, Photos, access to other apps’ data, and more. Deploy those and the user is never prompted.

Four permissions do not work that way. Apple’s schema states, in these words, that access to the camera cannot be given in a profile and can only be denied. The same wording applies to the microphone, to screen capture, and to input event monitoring. You can block them centrally. You cannot grant them.

Anything that records the screen, joins a call with video, or watches keyboard input therefore requires the person sitting at the Mac to click Allow. That includes most remote support tools, most video conferencing, and several endpoint agents. Plan the user communication for it, because the alternative is a helpdesk queue full of tickets that all say the same thing. There is one narrow relief valve: for screen capture and input monitoring only, Apple provides an authorisation value that lets a standard user set the permission themselves without an admin password.

One change to diarise. Apple’s schema now records that the ability to grant Accessibility access through a PPPC profile is deprecated as of macOS 26.2 and will be removed in macOS 27.0. If you rely on a profile to grant Accessibility to an automation or assistive tool, that arrangement has a shelf life, and you should be testing the replacement now rather than discovering it during an OS upgrade.

Declarative device management is where updates now live

Declarative device management is Apple’s newer, asynchronous approach, in which the device applies settings and reports status itself rather than waiting to be polled. It is not a replacement protocol bolted on the side. It is part of the MDM protocol, and Apple states that software update and app configurations applied declaratively take precedence over the equivalent older commands.

For software updates specifically, the old command set is on the way out. Apple’s schema marks the legacy scheduling, availability and status commands as deprecated as of the 26 releases. More immediately, if a declarative software update configuration is active on a Mac, the legacy commands already fail today: scheduling returns an install failure and status returns nothing. If your management platform is still driving Mac updates the old way, you are managing something that has already stopped working.

Software updates on Mac are enforceable, within limits

Managed updates are genuinely good now, provided you understand the boundaries.

Deferral is set in days, from one to ninety. macOS gives you three separate deferral controls where iOS gives one: major upgrades, minor updates, and non-OS system updates such as Safari and XProtect are deferred independently. Where several policies overlap, the longest deferral wins.

Enforcement works by setting a target version and a target local date and time, expressed in the device’s own time zone so a single policy behaves correctly across sites. As the deadline approaches, notifications escalate, and Apple states that Do Not Disturb is ignored in the final 24 hours. At the deadline macOS force-quits open applications regardless of unsaved documents and restarts. Tell people that before you turn it on.

Two constraints that bite:

On Apple silicon, enforcement depends on the bootstrap token. The Mac retrieves it from your management service to authorise the update without a human. No token, and the user gets a credential prompt instead, which means the enforcement quietly does not happen.

There is no way to hold a Mac fleet on a major version indefinitely. iOS and iPadOS have a cadence control that lets you offer only the older release. macOS has no equivalent. You have deferral, capped at ninety days, and that is the whole toolkit. If you have a critical application that is not yet certified on the next major macOS, ninety days is your runway. Budget vendor pressure accordingly.

FileVault: escrow the personal key, and stop using institutional keys

Apple’s guidance here has changed and a lot of documentation has not caught up.

Apple now states that institutional recovery keys provide no functional value on Apple silicon, because they cannot be used to access recoveryOS and target disk mode no longer exists, and that institutional keys are no longer recommended for managing FileVault on Mac. Use the personal recovery key and escrow it.

The mechanics: your management service supplies a public key as a certificate, the Mac encrypts the personal recovery key against it, and returns it. Because the encryption is asymmetric, whether your platform can actually decrypt and show you that key is a property of the platform, not of macOS. Test a real recovery before you need one. An escrowed key you cannot read is not a backup.

Standard MDM enablement is deferred: FileVault turns on at a user login or logout rather than instantly, and you control how many times the user may defer and whether they see the key. If the Mac came through Automated Device Enrolment, macOS 14 and later can force FileVault on during Setup Assistant instead, which removes the deferral problem entirely. Store the recovered keys somewhere that survives a laptop failure, which is a password management question as much as an MDM one.

The bootstrap token is the thing nobody knows about until it breaks

A bootstrap token is generated by macOS and escrowed to your management service, and it is what lets the Mac perform privileged operations without a person present. Your management platform has to advertise support for it, and the Mac escrows it on first login by a user with a secure token.

Without one, on Apple silicon:

• Enforced software updates prompt the user for credentials rather than proceeding
• Erase All Content and Settings is not supported, and an erase command falls back to obliteration, which means macOS has to be reinstalled from scratch
• Second and subsequent users do not get secure tokens, so they cannot unlock FileVault

Nearly every mystifying macOS management fault we are called into turns out to be a missing or stale bootstrap token. Check that your platform is collecting them, and check it per device rather than assuming.

Kernel extensions are a procurement problem, not a technical one

Apple’s position is unambiguous: kernel extensions are no longer recommended, and vendors should use system extensions, which run in user space. System extensions are approved centrally by team identifier through a profile, and that works well.

Kernel extensions on Apple silicon require the startup security policy to be set to Reduced Security. For an unenrolled Mac or one on User Enrolment, that means the user holding the power button to enter recoveryOS, authenticating as a local administrator, and changing the policy. Apple is explicit that only entering recoveryOS by power button press causes the Secure Enclave to accept the change, so it cannot be scripted. Under Automated Device Enrolment, Apple documents that management services can handle this automatically, which is one more argument for getting enrolment right at purchase.

The practical upshot is that if a software vendor still ships a kernel extension in 2026, that is a red flag about the vendor. Ask before you buy, not during rollout.

Local admin rights: you can set them, you cannot easily change them

Apple gives you real control at enrolment and almost none afterwards.

Through Automated Device Enrolment you can have Setup Assistant create the user’s account as a standard user, create a managed administrator account alongside it, hide that admin account from view, and rotate its password remotely. That is a solid baseline and it is what a well-built fleet uses.

What does not exist is an Apple command to promote or demote an arbitrary existing account. If a Mac was set up with the user as an administrator, no MDM will demote them natively. It requires scripting against the local directory, which means your platform’s scripting capability is the deciding factor, and that is one of the sharper differences between platforms discussed in the limits of Intune on macOS.

One trap worth flagging: Apple notes that remotely changing the managed admin password updates the login password but not the secure token password if that account has become secure token enabled. That desynchronisation produces an account that logs in but cannot unlock FileVault, and it is genuinely unpleasant to unpick.

The bits that reliably break

Devices bought outside Apple Business. They can be added later with Apple Configurator, but Configurator-added devices carry a 30-day window in which the user can release them from management. Buy through the right channel and the window never exists.

Major OS upgrades. Ninety days of deferral, no cadence control, and an application vendor who is not ready. Start compatibility testing when the beta appears, not when the deadline does.

Activation Lock. If a Mac has Activation Lock enabled by a personal Apple Account before it enrolled, Apple states you cannot turn it off through management. Only the user can. And bypass codes must be captured and retained, because Apple’s warning is direct: if you change management platforms, make sure you receive a copy of those codes or that the outgoing platform clears Activation Lock for every enrolled device first. This is the most expensive migration mistake in the Apple world.

Erase commands on Apple silicon without a bootstrap token. Obliteration rather than a clean erase, and a machine that needs a full reinstall.

Conflicting profiles. Apple states plainly that where multiple profiles carry the same payload with different settings, the resulting behaviour is undefined. Do not layer policies and hope.

Getting this right is ordinary work, but it is Apple-specific work, and it does not transfer from a Windows background. That is the substance behind why most Melbourne providers cannot support Macs properly. It also has to line up with your wider endpoint security and device management posture, your compliance position as set out in the Essential Eight on macOS, and your identity architecture if you are running Windows, Mac and Google side by side. We run Mac fleets under management alongside Windows, through Apple’s business deployment programmes, as a member of the Apple Consultants Network, Apple’s programme of independent technology partners specialising in Apple solutions for small and medium-sized businesses, and as a Jamf partner. None of the above is theory.

If you have Macs that are enrolled but not actually enforcing anything, the fastest useful step is an audit of supervision status, bootstrap token presence and FileVault key escrow across the fleet. Call 1300 028 324 or get in touch at https://techassist.au/contact/ and we will tell you which of your Macs you could actually recover, wipe or update today.

Mobile device management is how you keep company email and data secure when staff read it on phones, tablets and personal laptops you don’t own. The real problem with bring-your-own-device (BYOD) is the privacy trade-off, and the fix is usually app-protection policies that secure the company data inside an app without taking control of someone’s entire personal phone.

The problem MDM and MAM actually solve

The moment a staff member adds their work Microsoft 365 account to the Mail app on their own iPhone, your company data is sitting on a device you have no control over. No screen lock policy, no encryption guarantee, no way to remove the data if the phone is lost or the person leaves. Multiply that across a 40-person business and you have email, OneDrive files and Teams chats scattered across dozens of unmanaged personal devices.

This is the gap two related technologies close. Mobile device management (MDM) manages the whole device — it enrols the phone or laptop and enforces a passcode, encryption and OS version, and gives you the ability to wipe it. Mobile application management (MAM), or app-protection policy, manages only the company apps and the data inside them. It can require a PIN on the work app, block copy-paste out to personal apps, and wipe just the company data, while never touching the photos, messages or personal accounts on the device.

The distinction matters because most BYOD failures aren’t technical — they’re about trust. Staff don’t want their employer controlling their personal phone, and they’re right to be cautious. MAM answers that objection, and getting the choice right is the difference between a policy people accept and one they quietly work around.

The BYOD privacy tension, and why it kills full enrolment

Ask any team to enrol their personal phones in full MDM and you’ll hear the same fear: “Can the company read my texts? Can they wipe my photos?” With full device enrolment, the honest answer is that the company can see device-level inventory, push configuration, and yes, issue a full wipe that takes the personal data with it. Even when an MSP would never do that, the perception alone pushes people to refuse, use a second unmanaged device, or forward work email to a personal account — far worse for security than the problem you started with.

App-protection policy removes the objection. The company gets a security boundary around its own data — the work account, its files, its email — and the staff member keeps full ownership of everything else. When they leave, you wipe the company container and their holiday photos are untouched. For BYOD this is almost always the right model; you reserve full device management for hardware the business actually owns.

Microsoft Intune: the tool most Melbourne SMEs already have

If you’re on Microsoft 365 Business Premium or any E3/E5 licence, you already own Microsoft Intune — it’s bundled, which is why it’s the default MDM/MAM platform for businesses in our patch. Intune does both jobs from one console and ties into the rest of the Microsoft security stack. Four pieces do the heavy lifting.

Device compliance policies

A compliance policy defines what “healthy” means for a device: minimum OS version, disk encryption on, a passcode of a set length, not jailbroken or rooted. Intune continuously checks enrolled devices and marks each one compliant or non-compliant. On its own this is just a status flag — its power comes from what you connect it to.

App protection policies

This is the MAM layer. An app-protection policy applies to the Microsoft apps (Outlook, Teams, OneDrive, the Office apps) and governs the data inside them. You can require a separate PIN or biometric to open the work app, block cut/copy/paste into personal apps, stop “Save As” to personal storage, encrypt company data, and force a selective wipe of only the in-app company data on command. Critically, this works whether or not the device is enrolled in MDM at all.

Conditional access

Conditional access is the enforcement engine, and it lives in Microsoft Entra ID rather than Intune itself. It evaluates each sign-in and applies rules — for example, only grant access to Exchange Online if the device is marked compliant, or only allow Outlook if an approved app-protection policy is applied. That turns a compliance flag into a real control: a non-compliant or unmanaged device simply doesn’t get the data. We go deeper in our guide to conditional access policies in Microsoft 365.

Selective wipe at offboarding

When someone leaves, you don’t chase their personal phone. From the Intune console you issue a wipe of company data — on a MAM-protected BYOD device that removes the work account and its cached files and leaves the rest alone; on a company-owned enrolled device you can do a full wipe and reset. Combined with disabling the account, this is how secure offboarding actually happens — the step most businesses skip until a former employee still has live access three weeks later.

MDM full enrolment vs MAM app-protection

The single most useful decision in any BYOD rollout is which of these two models a given device gets. Here’s how they compare.

In practice a typical setup uses both: full MDM on the laptops and phones the business bought and owns, and MAM-only app-protection on staff personal devices, with conditional access requiring one or the other before any company data is released.

Company-owned vs BYOD enrolment paths

The enrolment path follows ownership. For company-owned devices, you enrol into full MDM — on iOS usually through Apple Business Manager so the device is supervised and locked to your tenant from first boot; on Windows it’s Autopilot, which ships a laptop that configures itself at first sign-in. These get the full set of compliance and configuration policies because the business owns the hardware.

For BYOD, you avoid full enrolment wherever you can. The staff member installs the standard Microsoft apps, signs in with their work account, and the app-protection policy applies automatically — no enrolment, no agent on the device, nothing that touches their personal data. Where a BYOD device genuinely needs full management you use a model that ring-fences the work side, such as a work profile on Android, but for most SMEs MAM-only covers it without the friction.

How this maps to the Essential Eight and secure offboarding

Mobile device management isn’t a standalone exercise — it’s how several Essential Eight controls reach the devices outside your office walls. The Australian Cyber Security Centre (ACSC) Essential Eight expects multi-factor authentication, patched operating systems and applications, and restricted admin privileges. Intune enforces those on a phone or laptop you can’t physically touch: compliance policies hold devices to a current, patched OS; conditional access pairs with MFA so a stolen password alone doesn’t open the mailbox; and app-protection keeps company data inside sanctioned apps.

Offboarding is where the absence of MDM gets expensive. We worked with a construction firm in Box Hill that had no device management at all — staff used personal phones for site photos, email and the project app. When a site supervisor left for a competitor, the business had no way to remove its data from his phone and no record of what he could still reach. With Intune in place, offboarding is a five-minute job: disable the account, issue a selective wipe of company data, done. That firm now runs MAM on every personal device and full MDM on the company-issued tablets on site.

A sensible BYOD plus MDM policy outline

We have a separate post on writing the BYOD policy itself; here the focus is the technical controls it should mandate. A workable policy ties the rules to enforceable Intune settings rather than good intentions:

• Eligibility. Define which roles may use BYOD and which must use company-owned devices — sensitive client or health data often warrants company hardware.
• Minimum device standard. Require a supported, currently-patched OS and a device passcode or biometric, blocked by conditional access if not met.
• App-protection mandatory. Company data is accessed only through the approved Microsoft apps with app-protection applied — no native mail clients, no forwarding to personal accounts.
• Access conditions. Conditional access requires a compliant or app-protected device before email, files or Teams are released.
• Separation of data. Block copy, paste and “Save As” from work apps into personal storage so company data can’t leak sideways.
• Offboarding and loss. State in writing that the business will selectively wipe company data on exit or device loss — never personal data on a BYOD device — with a single point of contact who actions it the same day.

The policy and the platform have to match. “Devices must be encrypted” means nothing if no system checks; a compliance policy that enforces it does. That pairing — written rules backed by enforced technical controls — is the whole point, and the part most businesses get half-right.

Frequently asked questions

Can my employer read my personal texts or photos if I enrol in MDM?

On a personal BYOD device set up with app-protection (MAM) only, no — the business sees nothing outside the work apps and cannot read your messages, photos or personal accounts. On a company-owned device in full MDM, the business can see device inventory and configuration and can issue a full wipe, which is exactly why we keep full enrolment for company-owned hardware and use app-protection for personal devices.

What’s the difference between MDM and MAM?

MDM (mobile device management) manages the whole device — passcode, encryption, OS, all apps — and is right for company-owned hardware. MAM (mobile application management, or app-protection policy) manages only the company apps and the data inside them, leaving the rest of a personal device alone. For BYOD, MAM is almost always the better fit.

Do I need extra licences for Microsoft Intune?

Usually not. Intune is bundled with Microsoft 365 Business Premium and the E3 and E5 plans, so most SMEs on those licences already own it and aren’t using it. On a lower plan it’s available as an add-on, but for most Melbourne businesses the capability is already paid for.

What happens to company data when someone leaves?

You issue a selective wipe from the Intune console, removing the company account and its cached files. On a BYOD device that’s all it touches — personal data stays put. Pair it with disabling the user’s account so access is revoked immediately. That’s the secure offboarding step businesses without device management can’t perform.

Getting it set up properly

Intune is powerful, but a misconfigured rollout either locks staff out of email or quietly enforces nothing. The work is in the detail: scoping which devices get MDM versus MAM, writing conditional access that doesn’t break legitimate access, and tying offboarding into a repeatable process. As a Melbourne MSP founded in 2014 with 13 Australian-employed engineers, we set up and run Intune across the metro as part of our cybersecurity services and managed IT services, on per-user fixed monthly pricing so it isn’t a surprise line item. If staff devices are reaching your company data with no controls in place, get in touch and we’ll map out what BYOD security should look like for your business.