Blog

The New M5 and M6 Macs Can Run Powerful AI On Device: Why That Matters for Data Security

The New M5 and M6 Macs Can Run Powerful AI On Device: Why That Matters for Data Security

Apple announced new Macs this week, and the headline everywhere is raw power. The M6 chip in the Mac mini, and the M5 Ultra in the Mac Studio, described by Apple as its most powerful chip ever. The benchmarks are genuinely impressive. But the number that actually matters for a business is not the core count or the graphics performance. It is the memory, and what that memory now makes possible.

These machines can run large AI models entirely on the device. No cloud. No data leaving the Mac. For most businesses that is not a performance story at all. It is a data security story, and a rather important one.

This post explains what Apple actually launched, what running AI locally really means, and why it matters for any UK business that handles sensitive data and worries about where that data goes.

What Apple actually announced

Apple introduced two new chips this week, on 25 August 2026, across refreshed Macs.

The M6 arrived in the new Mac mini. It is Apple’s first 2-nanometer chip, with a 12-core CPU, a 12-core GPU and a Dual 16-core Neural Engine. It supports up to 32GB of unified memory. Apple positions it for everyday users, developers and, notably, AI hobbyists who want to run models on device.

The M5 Ultra arrived in the new Mac Studio. This is the serious one. It is Apple’s most powerful chip to date, built from a new quad-die architecture, with up to a 36-core CPU, up to an 80-core GPU, and here is the headline figure, up to 512GB of unified memory with 1.2TB per second of memory bandwidth. The Mac Studio also comes in an M5 Max configuration with up to 128GB of unified memory.

The chips are fast, and the graphics are faster still. But the reason this launch matters beyond the usual upgrade cycle is that memory figure, because unified memory is the thing that determines whether a Mac can run a large AI model without help from the cloud.

What “running AI locally” actually means

Most people use AI through the cloud. When you type into ChatGPT, Gemini or a similar service, your words travel to a data centre, the model runs there, and the answer comes back. The model is not on your device. Your data is not on your device while it is processed. It is on someone else’s servers.

Running AI locally means the opposite. The model runs on the Mac itself. Your prompt, the data you feed it and the answer it produces never leave the machine. Nothing travels to a data centre. Nothing is processed on infrastructure you do not control.

The barrier to doing this has always been memory. Large language models are big, and to run one the machine needs enough memory to hold the entire model at once. Consumer machines simply did not have enough. That is what has changed. Apple explicitly states that the M5 Ultra, with its up to 512GB of unified memory, lets users run huge LLMs with hundreds of billions of parameters entirely on device. Even the M6 Mac mini, at up to 32GB, is designed to run capable models locally for private tasks.

In plain terms, these Macs are now powerful enough to run serious AI without the cloud. That moves local AI from a hobbyist experiment to something a business can genuinely use.

Why this is a data security story, not a performance story

Here is where it matters for your business. The single biggest concern businesses have about AI is not whether it is clever enough. It is where the data goes.

Every time an employee pastes something into a cloud AI tool, that information leaves your control. A contract, a client record, a piece of financial data, a legal document, a patient detail. It travels to a third-party service, gets processed on infrastructure you do not own, and may, depending on the service and its terms, be retained or used in ways you cannot see. For a business handling sensitive or regulated data, that is a genuine problem, and it is the reason many firms have either banned AI tools outright or are quietly worried about the ones their staff use anyway.

Local AI removes that problem at the root. If the model runs on the Mac and the data never leaves the device, there is no third-party service to trust, no data leaving your control and no cloud retention to worry about. The sensitive document stays on the machine it started on.

For sectors where this matters most, and nDuo works with a lot of them, finance, legal and healthcare, this is significant. It means the productivity benefits of AI become available without the data governance nightmare that cloud AI creates. The new Mac hardware is what makes that practical rather than theoretical.

The shadow AI problem this helps solve

Most businesses already have an AI problem they may not fully see. Employees are using AI tools whether the business has approved them or not. They paste work into ChatGPT to summarise it, into other tools to rewrite it, into whatever is convenient. This is shadow AI, unapproved tools handling company data, and it is one of the fastest-growing data security concerns for UK businesses.

You cannot easily stop it by policy alone, because the tools are useful and people will find them. What you can do is offer a sanctioned alternative that is genuinely private. Local AI running on a properly managed Mac gives employees the capability they want, the AI assistance that makes them faster, without the data ever leaving the device.

That reframes the conversation from prohibition to provision. Instead of telling staff not to use AI, you give them a version that is safe by design. The new hardware is what makes that a realistic option rather than a compromise.

Powerful hardware still needs to be managed

A word of realism, because this is where a powerful new Mac can quietly become a liability rather than an asset.

A Mac Studio with 512GB of memory running local AI models is an extraordinarily capable machine. It is also, if unmanaged, an extraordinarily capable machine sitting outside your security controls. The power that lets it run a large language model locally is the same power that makes it a valuable target and a significant data store. Local AI means sensitive data is being processed and potentially cached on the device, which raises the stakes on getting the fundamentals right.

The security basics matter more, not less, on these machines. FileVault encryption so the data at rest is protected. Proper enrolment and supervision so the device is genuinely under management. Patching kept current so vulnerabilities are closed quickly. Access control so only the right person can reach what is on the machine. Compliance reporting so you can prove all of the above. Running powerful local AI on a Mac that is not properly managed is a data security risk dressed up as a productivity win.

This is the part the hardware announcements do not mention. The capability is real, but capability without management is exposure. Getting the value out of these machines safely means treating them as what they are, powerful endpoints handling sensitive data, and managing them accordingly.

Governing AI that runs on the device

There is a further wrinkle that the hardware announcements do not touch, and it is the one that matters most for governance. When AI runs in the cloud, your security tools can at least see it. Network monitoring and cloud-based controls can observe the traffic leaving the device, flag it and, where needed, block it. A local model breaks that entirely. It runs as a process on the Mac, in the machine’s own memory, and generates no network traffic for a proxy to inspect. To everything watching the network, nothing is happening at all.

That is precisely what makes on-device AI so hard to govern. The property that makes it attractive for privacy, that data never leaves the machine, is the same property that makes it invisible to the traditional security tooling most businesses rely on. You cannot govern what you cannot see, and a local LLM is, by design, something the network cannot see.

A new category of control has emerged

This is a genuinely new problem, and the tooling to address it is only now emerging. Jamf, the leading Apple management platform, launched a capability called AI Governance in mid-2026, described as the first native, OS-level AI control plane for Mac. Rather than watching the network, it works at the level of the device itself. It discovers which AI tools are actually in use across a fleet, applies policy controls to them, and produces audit-ready reporting on AI activity. Because it operates on the endpoint rather than the network, it can see AI processes that cloud and network tools miss.

It is worth being accurate about where this stands, because the category is early. At launch, Jamf AI Governance targets a defined and growing set of AI tools and agentic clients rather than every possible local model a user might run. It is not a finished, catch-all answer to governing any on-device AI. What it represents is the arrival of a new category of control, one that exists precisely because AI running locally on Apple silicon sits beyond the reach of everything that governs AI in the cloud. As the new hardware pushes local AI into the mainstream, that category will only grow in importance.

What this means for your business

The practical takeaway for a business is this. If you are going to allow, or you already have, AI running on your Macs, you need a way to see it, control it and report on it at the device level. Network controls alone will not do it. That is an endpoint management question, and it is exactly the kind of capability that belongs alongside the encryption, patching and access control that already keep a managed Apple fleet compliant.

Should your business rush out and buy one?

Not necessarily, and it is worth being honest about that. The M5 Ultra Mac Studio is a professional workstation aimed at developers, AI researchers, filmmakers and data scientists. Most businesses do not need 512GB of unified memory or the ability to run a frontier AI model locally. For the majority, the more modest new Macs, or the ones they already own, are perfectly capable for day-to-day work.

The point is not that every business should buy the most powerful Mac available. The point is that local, private AI has crossed the line from impractical to genuinely usable, and that opens a real option for businesses that care about data security. If AI assistance would help your team but data governance has held you back, on-device AI is now a serious answer, and the hardware to run it exists.

For businesses in regulated sectors specifically, this is worth a proper conversation. The combination of capable Apple hardware, local AI and correct device management offers a way to get the benefits of AI while keeping sensitive data genuinely private. That is a stronger position than either banning AI or accepting the risks of cloud tools.

How nDuo helps

We help UK businesses get the value out of their Apple fleet safely, and that increasingly includes the governance questions that local AI raises. That means making sure the powerful Macs handling your most sensitive work are properly encrypted, enrolled, patched and compliant, and that you have visibility and control over the AI running on them, so the capability is an asset rather than an exposure.

If your business is thinking about how to use AI without handing your data to third-party services, or you are investing in capable new Apple hardware and want it managed to the standard that sensitive data demands, that is exactly the kind of work we do. We make sure the fundamentals, Cyber Essentials alignment, encryption, patching and access control, are genuinely in place across your Apple fleet.

Read our guide on why the 14-day patching window is no longer enough to understand how we keep powerful endpoints current, or our Apple IT support page for how we manage Apple fleets for UK businesses.

Book a free consultation with our team to talk through secure Apple management and where on-device AI could fit in your business.

Cisco Is Exiting MDM: Why Ivanti Probably Isn’t the Answer for Your Apple Fleet

Cisco Is Exiting MDM: Why Ivanti Probably Isn’t the Answer for Your Apple Fleet

If you manage your Apple fleet with Cisco Meraki Systems Manager, you are now on a clock. Cisco is retiring the product. You can no longer buy or renew licences. The platform reaches full end of support in 2029.

This is not a routine upgrade. It is a mandatory migration, and the replacement Cisco itself recommends is, for most Apple-focused businesses, the wrong destination.

This guide sets out the timeline clearly. It explains what happens to your enrolled devices and gives an honest view of the realistic options. It also covers why an Apple fleet needs different treatment from a general Windows estate. And it explains why Cisco’s suggested path to Ivanti often solves the wrong problem.

The timeline, and where you are in it

Cisco announced the end of Meraki Systems Manager on 3 December 2025. The dates that matter are straightforward.

On 3 December 2025, Cisco announced the end of sale and immediately stopped selling new five-year licences.

On 3 June 2026, the last one-year and three-year licences were sold. After that date, no new Meraki SM licences are available to anyone. You cannot add a single seat to your environment, even as an existing customer.

On 3 June 2029, support ends entirely. No security patches, no firmware updates, no technical assistance. The platform effectively goes dark.

If you are reading this in the second half of 2026, the purchasing window has already closed. You can keep running the licences you hold until they expire. But you cannot grow your fleet on Meraki, and you cannot renew indefinitely. The three-year runway to 2029 sounds generous. It is still a hard deadline, and migrating an MDM platform is not a weekend job.The sensible time to plan is now.

What actually happens to your enrolled devices

An end-of-sale announcement does not switch anything off today. Your Macs, iPhones and iPads currently enrolled in Meraki SM keep working as normal. They keep receiving policies and stay managed until you migrate, or until support ends in 2029.

The migration itself is where the real work sits, and it is worth understanding what it involves. Moving a device from one MDM to another is not a simple transfer. In almost all cases each device has to be unenrolled from Meraki and freshly enrolled into the new platform. Configuration profiles, apps, restrictions and compliance policies do not carry across automatically. They have to be rebuilt in the new system.

For company-owned Apple devices bought through Apple Business Manager, the process is cleaner. You reassign the devices from Meraki to your new MDM server in Apple Business, and they enrol into the new platform automatically at the next wipe or through the appropriate workflow. For older devices, or those not in Apple Business, the path is more manual and may involve touching each device.

This is precisely why starting early matters. A fleet of a few dozen devices is a manageable project. A fleet of several hundred, migrated in a rush before a deadline, is a different proposition entirely.

Why Cisco points you to Ivanti, and why that may not fit

As part of the wind-down, Cisco partnered with Ivanti and recommends Ivanti Neurons for MDM as the comparable replacement, offered through its SolutionsPlus programme. On paper this looks like the obvious path. Cisco suggests it, it supports the same operating systems, and it promises an easy migration.

Look closer and the fit is often poor, especially for Apple fleets.

Ivanti Neurons is a full unified endpoint management platform built for large, complex enterprise environments. It carries a minimum purchase threshold of 50 licences and onboarding typically requires dedicated professional services. If you came to Meraki Systems Manager because it was straightforward, moving to Ivanti can feel like a step in the wrong direction rather than a like-for-like replacement.

There is a telling pattern in Cisco’s own community forums. Existing Meraki customers, reacting to the end-of-life news, repeatedly say two things. Several had already planned to move their Apple devices to Jamf, having seen the writing on the wall. And many balk at Ivanti meaning yet another separate console to manage rather than the integrated experience they valued in Meraki. When a vendor’s own users are openly planning a different route from the one recommended, it is worth paying attention.

The deeper issue is that a general UEM platform treats Apple as one operating system among many. For a business whose fleet is mostly or entirely Apple, that generalist approach is exactly what causes the management gaps we see repeatedly.

Why Apple fleets need different treatment

This is the heart of the matter, and it is the reason the Cisco-to-Ivanti path is the wrong default for Apple-focused businesses.

Apple device management has specific requirements that general UEM platforms handle less well. Automated Device Enrolment through Apple Business, supervision, FileVault key escrow, the way macOS delivers configuration profiles, the speed of policy check-ins, and crucially the automated patching of third-party Mac applications. These are the areas where Apple-first platforms consistently outperform generalist ones.

A general UEM platform can technically manage Macs. It can enroll them, apply some policies and report on them. What it does less well is the depth. Third-party application patching on Mac is the clearest example. On a proper Apple-focused platform it is automated across hundreds of applications. On a generalist platform it often requires manual packaging and scripting, which is exactly the kind of gap that undermines both day-to-day management and Cyber Essentials compliance.

If your fleet is predominantly Apple, migrating from one generalist platform to another generalist platform does not fix the underlying mismatch. It simply moves it. The Meraki end-of-life is a forced decision point, and that makes it an opportunity to move to a platform genuinely built for your fleet rather than defaulting to whichever replacement the outgoing vendor happens to recommend.

The realistic options, and who each suits

Setting Ivanti aside as the default rather than the automatic answer, here are the platforms genuinely worth considering for an Apple or Apple-heavy fleet, with an honest view of who each suits.

Jamf Pro

Jamf Pro is the most capable Apple-focused MDM available and the natural destination for a business whose fleet is predominantly Apple. The solution offers the deepest Apple management, automated third-party patching across a large application catalogue, mature Automated Device Enrolment, and the strongest compliance reporting for frameworks like Cyber Essentials.

It suits businesses that take their Apple estate seriously and want best-in-class management. It is more than many small fleets strictly need, and it carries a cost that reflects its capability, but for an Apple-first business it is usually the right long-term home. Many of the Meraki customers reacting to the end-of-life news are heading precisely here.

Microsoft Intune

If your business runs on Microsoft 365 and your fleet is genuinely mixed, with a Windows majority and a minority of Macs, Intune is a sensible destination. It is included in Microsoft 365 Business Premium and above, so the cost may already be covered, and it manages Windows and Apple from one console tied into your Microsoft identity.

The honest caveat is the one we have written about before. Intune’s Apple management is functional rather than deep, with slower check-ins and no native third-party Mac patching. For a Windows-first business with a few Macs, that trade-off is acceptable. For an Apple-first fleet, it is not. Our Jamf Pro vs Microsoft Intune comparison covers exactly where each falls short.

Iru (formerly Kandji)

Iru is a strong, modern Apple-focused platform, well suited to businesses that want capable Apple management with a clean, straightforward experience. It offers good automation and a strong out-of-the-box compliance posture. For a business that found Meraki appealing because of its simplicity, Iru can feel like a more natural successor than a heavy enterprise UEM.

It suits Apple-first businesses that value ease of use and want strong management without the full depth and configurability of Jamf Pro.

FleetDM

FleetDM is the option for the technically minded. Fleet is open-source, built around modern practices, and lends itself to managing your fleet as code with full version control and automation. It manages Apple alongside Windows and Linux from a single workflow.

Fleet suits businesses with an engineering culture that want transparency, automation and control, and who have the technical capability to run it. It is not the right choice for a business wanting a polished, click-and-go console, but for the right team it is powerful. We have written separately about managing an Apple fleet as code if that direction interests you.

How to choose, briefly

The decision comes down to a few honest questions about your fleet.

  • If your fleet is predominantly Apple and you want the best management available, Jamf Pro is the strongest destination.
  • If you value simplicity and a modern Apple-focused experience, Iru is well worth considering.
  • If you are genuinely Microsoft-first with a Windows majority and only a handful of Macs, Intune is pragmatic.
  • If you have the engineering capability and want automation and control, FleetDM is compelling.
  • And if you are a large, complex, multi-platform enterprise for whom a heavyweight UEM genuinely fits, Ivanti may be reasonable after all, though it rarely is for an Apple-focused business.

What matters is choosing based on your fleet, not on which replacement your outgoing vendor is paid to recommend.

How nDuo handles Meraki migrations for Apple fleets

We migrate Apple and Apple-heavy fleets off Meraki Systems Manager onto the platform that genuinely fits, rather than the one Cisco defaults you toward.

nDuo is a Jamf Elite Partner (one of only 14 in the UK), a Microsoft Partner, an Iru partner, a FleetDM partner, and one of only 11 Apple Premium Technical Partners in the country. We are accredited across every platform we might recommend, which is the point. We have run Apple fleets since 2011 and currently manage over 15,000 devices for UK businesses including Revolut, Kroo and Lottoland.

A typical migration we run looks like this. We audit your existing Meraki setup and document profiles, app, restriction and policy in place. Then we design the equivalent, improved configuration in the new platform. We reassign your Apple Business Manager devices to the new MDM server and plan the enrolment path for everything else. We migrate in controlled waves rather than all at once, so nothing breaks and your team keeps working throughout. And we make sure the result is not just a like-for-like copy but a genuine improvement on what Meraki gave you, particularly on patching, compliance and user experience.

Most migrations of 100 to 500 devices take four to eight weeks from audit to completion, depending on how much of your existing configuration needs rebuilding rather than replicating.

If you are running Meraki Systems Manager on an Apple fleet and weighing up where to go next, the worst option is to wait until 2029 approaches and migrate in a rush. The best option is to plan now, on your timeline, onto a platform built for your fleet.

Read our Jamf Pro vs Microsoft Intune comparison to understand the two most common destinations in more detail, or our zero touch deployment guide to see how enrolment works on the platform you move to.

Book a free consultation with our team to plan your Meraki migration and get an honest recommendation on the right platform for your Apple fleet.

Platform SSO for Mac: A Practical Guide for Okta, Google and Microsoft 365 Businesses

Platform SSO for Mac: A Practical Guide for Okta, Google and Microsoft 365 Businesses

Most people sign in to their Mac with one password and sign in to their work accounts with another. The two drift apart. Someone changes their cloud password, forgets to change the Mac password, and support tickets follow. Worse, the local Mac password often sits outside your identity provider entirely. It never expires, never enforces MFA, it appears in no security policy you set centrally.

Platform SSO is Apple’s answer to that problem. It connects the macOS login window directly to your identity provider. The credentials your employees use for everything else now unlock their Mac too.

Done well, it removes a whole category of password friction and closes a real security gap at the same time.

This guide explains what Platform SSO is and the three ways it can authenticate. It then covers where Okta, Google Workspace and Microsoft 365 actually stand today.

They are not at the same stage, and knowing the difference matters before you commit to a rollout.

What Platform SSO actually is

Platform Single Sign-On, usually shortened to Platform SSO or PSSO, is a framework built into macOS. It extends your identity provider all the way to the login window. Apple introduced it with macOS Ventura in 2022. Every release since has expanded it. Sonoma and Sequoia built on it, and the latest macOS generation improves setup
considerably.

It is best understood as the modern replacement for binding a Mac to a directory. In the past, organisations joined Macs to Active Directory to tie them to central identity. That approach is now the wrong one for cloud-first businesses. Platform SSO does the equivalent job for the cloud era. It links the Mac to a cloud identity provider rather than an on-premises directory.

Once configured, Platform SSO does three things. It lets the Mac create local accounts from the login window using cloud credentials. It keeps those credentials in step with
the identity provider. And it providesThe tokens that make this work are held securely on the device and refreshed automatically as they expire. The result is one identity, enforced consistently, from the moment the employee powers the Mac on.

The three authentication methods

Platform SSO can work in one of three modes. Choosing the right one is the most important decision in any deployment. It determines both your security posture
and the day-to-day experience for your team.

1. Secure Enclave key

This is the method Apple, Microsoft and Okta all recommend, and for good reason. A cryptographic key is generated and held in the Mac’s Secure Enclave, the same dedicated security hardware that backs Touch ID. The key never leaves the device, so it cannot be phished or copied off the machine. Employees authenticate with Touch ID, going effectively passwordless for cloud resources.

Crucially, the Secure Enclave method leaves the local account password untouched and separate. It meets phishing-resistant MFA requirements and works in a way conceptually similar to Windows Hello for Business on the Windows side. For most businesses that care about security, this is the right choice.

2. Password synchronisation

In this mode, the identity provider password is synchronised with the local macOS account. The employee uses the same password for their cloud accounts and their Mac, and changing it in one place updates the other. It is the simplest method to understand and the easiest for users, since there is only ever one password to remember.

It carries a trade-off worth knowing. The password method stores its keys in the iCloud Keychain, which introduces a theoretical risk that credentials could be exported and reused elsewhere. The risk is limited in practice, but for security-conscious businesses it is a reason to prefer the Secure Enclave method where the identity provider supports it.

3. Smart card

The third method uses a physical smart card or hardware token, such as a PIV or CAC card. It suits high-assurance environments, government and defence contexts, and any organisation already invested in smart card infrastructure. It is the least common of the three and requires additional hardware and configuration, so most commercial businesses set it aside in favour of one of the other two.

What you need for Platform SSO to work

Platform SSO is not something you switch on in isolation. Three things need to be in place.

  1. A supported version of macOS. While Platform SSO exists from Ventura onwards, Sonoma or later is the realistic minimum for a smooth deployment, and newer is better given how much the feature has matured.
  2. An MDM platform to deliver the configuration. Platform SSO is configured through a profile pushed by your mobile device management platform. Jamf Pro or Microsoft Intune both do this. The MDM defines which authentication method is used, how registration happens and how it ties into the rest of your device policy.
  3. An identity provider that supports it. This is the part that trips businesses up, because support varies significantly between providers. Apple built the framework, but each identity provider has to implement its side of it, and they have done so at different speeds and to different depths. This is where the three providers you are most likely to use diverge.

Platform SSO with Microsoft 365 and Entra ID

If your business runs on Microsoft 365, your identity provider is Microsoft Entra ID, and this is the most mature Platform SSO integration available. Microsoft has invested heavily in it through the Enterprise SSO plug-in for Apple devices.

Entra ID supports all three authentication methods, and Microsoft actively recommends the Secure Enclave approach. In that mode it delivers passwordless, phishing-resistant sign-in via Touch ID, built on the same underlying technology as Windows Hello for Business. It integrates with Conditional Access, so you can require a compliant, enrolled Mac before granting access to Microsoft 365 resources, exactly as you would for a Windows device.

For a business already committed to Microsoft 365, this integration is the strongest argument for Platform SSO. The Mac stops being the odd device out in a Microsoft identity estate and becomes a first-class citizen, subject to the same access policies, the same MFA enforcement and the same passwordless experience as everything else. For mixed Mac and Windows fleets on Microsoft, it brings genuine consistency to how identity works across both platforms.

Platform SSO with Okta

Okta was the first identity provider to support Platform SSO, alongside Jamf, back in 2023. Its implementation lives within Okta Device Access, the part of Okta’s platform that extends identity to the device login itself.

Okta’s support began with password synchronisation, branded as Desktop Password Sync, which lets employees sign in to their Mac with their Okta credentials directly at the login screen. More recently Okta has added Secure Enclave-backed key support through Platform SSO, bringing it into line with the hardware-bound, passwordless approach that Microsoft offers. That is a meaningful step, because it means Okta businesses no longer have to accept the password method’s trade-offs to get Platform SSO working.

Deployment requires the Okta Verify app on each Mac and configuration of Okta Device Access on the identity side, delivered through your MDM. For businesses that have standardised on Okta as their identity layer, Platform SSO closes the last gap, extending Okta’s reach from applications all the way down to the Mac lock screen. Onboarding becomes genuinely seamless: a new starter signs in once with their Okta identity and the Mac provisions their account from the login window.

Platform SSO with Google Workspace, the honest picture

Here is the part most guides skip, and the part that matters most if you run on Google. Google Workspace does not offer a first-party Platform SSO integration in the way Microsoft and Okta do. There is no Google equivalent of the Microsoft Enterprise SSO plug-in or Okta Device Access that plugs natively into the macOS login window.

This is not a small detail. It means a Google Workspace business cannot simply switch on Platform SSO the way an Entra ID or Okta business can. If your identity lives in Google and you want cloud credentials at the Mac login window, you generally need one of two approaches.

The first is a dedicated tool that bridges Google identity to the Mac. Jamf Connect has done exactly this since 2018, bringing cloud identity to Mac account provisioning and login, and it works with Google as the identity source. For many Google Workspace businesses, Jamf Connect rather than native Platform SSO is the practical route to a cloud-credential login experience.

The second is to federate Google through an identity provider that does support Platform SSO. Some businesses put Okta or Entra ID in front of Google Workspace, using Google for productivity while the Platform SSO-capable provider handles device identity. This adds architecture and cost, so it only makes sense in specific circumstances.

The honest takeaway: if you are a Google Workspace business set on Platform SSO, plan for Jamf Connect or a federation layer rather than expecting native support. Knowing this before you start saves a great deal of wasted configuration effort.

How this compares to the Windows side of a mixed fleet

If you run a mixed Mac and Windows fleet, it helps to see Platform SSO as the Apple counterpart to something Windows has had for a while. On Windows, Windows Hello for Business provides the same passwordless, hardware-backed, phishing-resistant sign-in, tied to Entra ID. Platform SSO with the Secure Enclave method is deliberately built along the same lines, which is why Microsoft describes the two as conceptually equivalent.

For a business standardising identity across both platforms, that parallel is the goal. Windows devices authenticate through Windows Hello for Business, Macs authenticate through Platform SSO, and both answer to the same identity provider with the same access policies. The employee experience becomes consistent regardless of which device they pick up, and your security team enforces one set of rules across the whole estate rather than treating the Macs as an exception.

Getting the Apple half of that picture right is usually where mixed-fleet businesses need the most help, because the Windows side is familiar ground and the Mac side is not. Our guide on why Windows IT teams struggle with Mac management covers that gap in more detail.

Why Platform SSO matters for security and compliance

Platform SSO is often sold on convenience, one identity, fewer passwords, smoother onboarding. The stronger case is a security one.

An unmanaged local Mac password is a genuine weakness. It sits outside your identity provider, so it does not expire, does not require MFA and does not respond to any central policy. If an employee leaves, that local password may remain valid on the device until someone manually intervenes. Platform SSO closes this gap by bringing the login itself under the control of your identity provider.

With the Secure Enclave method, you gain phishing-resistant, passwordless authentication that satisfies MFA requirements and aligns with the direction insurers and frameworks are pushing. For businesses pursuing Cyber Essentials, strong access control is one of the five core controls, and Platform SSO is a clean way to demonstrate that Mac access is governed by the same enforced identity as everything else. It turns the Mac login from an unmanaged local secret into a controlled, auditable part of your security posture.

Tying device access to cloud identity also strengthens your joiner and leaver process. When identity is central, deprovisioning a departing employee in your identity provider cuts their access to the Mac as well, rather than leaving a valid local account behind.

Common mistakes to avoid

Choosing the password method by default. It is the simplest to set up, so it gets chosen without much thought. Where your identity provider supports the Secure Enclave method, that is almost always the better choice for security. Default to Secure Enclave and use password sync only when you have a specific reason.

Assuming Google Workspace works like the others. As covered above, it does not. A Google business that plans a Platform SSO rollout expecting native support will hit a wall. Plan the Jamf Connect or federation route from the start.

Configuring it without testing across macOS versions. Behaviour differs between macOS generations, and a fleet running a mix of versions needs the profile tested on each. Rolling out to the whole fleet before piloting is how avoidable problems reach every employee at once.

Overlooking FileVault interaction. How Platform SSO interacts with FileVault at the login window depends on the method and macOS version chosen. This needs deliberate configuration rather than being left to default, particularly where the password method is in use.

Treating it as a one-off switch rather than part of device management. Platform SSO works as part of a properly configured MDM and identity setup, not in isolation. It depends on the enrolment, the profiles and the identity integration around it all being correct.

How nDuo helps

We implement Platform SSO for UK businesses across all three identity providers, and crucially we know where each one stands.
– Microsoft 365 and Entra ID businesses, we configure Platform SSO with Secure Enclave and tie it into Conditional Access.
– Okta businesses, we deploy Okta Device Access and the Secure Enclave method through your MDM.
– Google Workspace businesses, we advise honestly on the Jamf Connect or federation route rather than promising native support that does not exist.

That means configuring the MDM profiles correctly, choosing the right authentication method for your security requirements, testing across your fleet before rollout and integrating the result into your wider Apple management and security posture. The goal is one enforced identity from the Mac login window outward, whichever identity provider you run.

If your Mac logins currently sit outside your identity provider, or you are planning a move to passwordless authentication and want the Apple side done properly, this is exactly the kind of work we do.

Read our guide to the perfect employee onboarding process to see how Platform SSO fits into a seamless first-day experience, or our Jamf Pro vs Microsoft Intune comparison to understand the MDM layer that delivers it.

Book a free consultation with our team to talk through Platform SSO for your identity provider and get a clear recommendation on the right approach.

Cyber Essentials vs ISO 27001: Which Does Your Fleet Actually Need?

Cyber Essentials vs ISO 27001: Which Does Your Fleet Actually Need?

Businesses weighing up their security credentials almost always arrive at the same fork in the road. Should they pursue Cyber Essentials, ISO 27001, or both? The two get mentioned in the same breath so often that they can seem interchangeable. They are not. They solve different problems, demand very different levels of effort and suit businesses at different stages.

This guide sets out what each one is, how they genuinely differ and which your business actually needs. It also covers a part of the decision that most comparisons ignore entirely: what happens to your certification when your fleet is a mix of Windows and Apple, and why the Apple side is so often where the evidence falls apart.

What Cyber Essentials is

Cyber Essentials is a UK government-backed certification, run by IASME on behalf of the National Cyber Security Centre. It focuses on five technical controls that protect against the most common internet-based attacks: firewalls, secure configuration, security update management, user access control and malware protection.

The scheme comes in two levels. The base level is a self-assessment, where you answer a questionnaire about your setup and it is verified. Cyber Essentials Plus adds an independent technical audit, where an assessor checks a sample of your devices to confirm the controls are genuinely in place rather than simply declared.

Its great strengths are speed and accessibility. A well-prepared business can achieve certification in a matter of weeks, at a cost measured in hundreds rather than thousands of pounds. It renews annually. For many UK businesses it is the practical starting point for demonstrating security, and it is frequently required to win public-sector contracts.

What ISO 27001 is

ISO 27001 is an international standard for information security management. Rather than checking a fixed list of technical controls, it requires you to build and run an Information Security Management System, usually shortened to an ISMS. That is an ongoing, documented approach to identifying risks and managing them across the whole organisation.

The scope reaches far beyond IT. ISO 27001 covers people, processes, policies, physical security, supplier relationships and business continuity, not just the configuration of your devices. At its heart sits a risk assessment: you identify what could go wrong, decide how to treat each risk and document your reasoning in a Statement of Applicability.

Certification comes through an accredited body via a two-stage audit, followed by annual surveillance audits across a three-year cycle. Achieving it typically takes months of preparation and a meaningful investment of time and money. In return, it is recognised internationally and often demanded by enterprise clients and procurement teams before they will trust you with sensitive data.

The differences that actually matter

Set side by side, the two frameworks differ on four things that shape the decision.

Effort and cost

Cyber Essentials is deliberately achievable. Weeks of preparation, a modest fee, annual renewal. ISO 27001 is a project. Months of work, significant cost, ongoing internal audits and management reviews to maintain it. The gap in effort between the two is large, and businesses regularly underestimate it.

Depth of assurance

Cyber Essentials confirms that controls exist at the point of assessment. ISO 27001 requires evidence that you continuously identify risks, act on them and improve over time. A client who accepts Cyber Essentials wants to know you meet a baseline. A client who insists on ISO 27001 wants confidence that security is embedded in how you operate.

Recognition

Cyber Essentials carries real weight in the UK, particularly for government and public-sector work. ISO 27001 is the language of international and enterprise procurement. Which one opens doors depends entirely on who your customers are and where they are based.

So which does your business actually need?

The honest answer is that it depends on what is driving the decision. A few common situations make it clearer.

Choose Cyber Essentials first if you are a UK-focused small or medium business wanting a credible security baseline, if you need certification to bid for public-sector contracts, or if your cyber insurer is asking for it. It delivers a recognised, affordable result quickly, and it forces you to get the fundamentals right.

Prioritise ISO 27001 if enterprise or international clients are demanding it before they will sign, if you handle sensitive data at scale, or if procurement processes in your sector treat it as the price of entry. In regulated fields such as finance and legal, it is increasingly a competitive necessity rather than a nice-to-have.

For many maturing businesses the real answer is both, in sequence. Cyber Essentials establishes the technical foundation, and much of the evidence it produces feeds directly into the broader ISO 27001 effort. Starting with Cyber Essentials and building toward ISO 27001 is a well-trodden and sensible path. Our guide to Cyber Essentials and Cyber Essentials Plus is worth reading alongside this if you are still deciding on the right level.

The part most comparisons miss: your mixed fleet

Here is where the standard advice quietly breaks down. Almost every guide to Cyber Essentials and ISO 27001 is written with an unspoken assumption baked in: that your estate runs on Windows, managed through Active Directory and Group Policy. The controls, the evidence and the audit expectations are all framed around that world.

Most real businesses no longer live in that world. They run a mix. Windows laptops for some teams, Macs for others, iPhones and iPads across the board. And the moment an estate becomes mixed, the Apple side becomes the part where compliance evidence tends to fall apart.

The reason is straightforward. Many IT providers are Windows-first by background. They produce clean, comprehensive evidence for the Windows fleet, because that is the platform they know. When it comes to the Macs and iPhones, the same rigour often is not there. The devices are technically present but not genuinely managed to the same standard, and the evidence an assessor needs simply does not exist.

This matters for both frameworks, in different ways.

What each framework demands of your Apple estate

Cyber Essentials and your Macs

Every one of the five controls applies to your Apple fleet just as it does to Windows. FileVault encryption and the macOS firewall must be configured and enforced. Software updates, including third-party applications, must be applied within the required window. Administrator rights must be controlled. Malware protection must be appropriate to the platform.

For Cyber Essentials Plus in particular, an assessor will sample your Macs directly. If those devices are not managed through a proper MDM platform, demonstrating these controls across the fleet becomes guesswork. The patching control is the most common failure point, because Intune does not natively patch third-party Mac applications the way it handles Windows, and manual patching rarely holds up to scrutiny. Our Cyber Essentials checklist covers what each control requires in practice.

ISO 27001 and your Apple estate

ISO 27001 raises the bar further. Its risk-based approach means your Apple fleet must sit clearly within the scope of your ISMS. You need an accurate asset inventory that includes every Mac and iPhone, documented configuration management for those devices, and demonstrable, ongoing control over how they are patched, encrypted and accessed.

An auditor will expect to see that the Apple portion of your estate is managed with the same discipline as the rest. A business that can produce detailed, continuous evidence for its Windows fleet but only vague assurances for its Macs has a genuine gap in its management system, and a good assessor will find it.

Why proper Apple management changes the picture

When your Apple fleet is managed through a capable MDM platform, the evidence problem largely disappears. Jamf Pro or Microsoft Intune, configured correctly, enforce the controls both frameworks require and produce the reporting that proves it. Encryption status, patch compliance, configuration enforcement and access control become device-by-device evidence you can hand to an assessor, rather than claims you hope will be accepted.

This is the practical difference between passing an audit comfortably and scrambling to justify gaps. For a mixed fleet, it is usually the Apple side that decides which of those two experiences you have.

It is also where nDuo iQ earns its place. By bringing your Apple and Windows management into a single view, it lets you demonstrate compliance across the whole estate from one place, rather than stitching together evidence from separate systems and hoping the Apple portion holds up.

How nDuo helps

We help UK businesses achieve and maintain both Cyber Essentials and ISO 27001, with particular focus on the part most providers get wrong: the Apple estate inside a mixed fleet. That means configuring your Macs and iPhones to meet the controls each framework demands, producing the evidence an assessor needs, and keeping that evidence current as your fleet grows and the standards evolve.

If you are weighing up which certification your business needs, or you already hold one and suspect your Apple fleet is the weak link in your evidence, the starting point is an honest look at where your estate actually stands.

Read our Cyber Essentials guide for the full detail on the UK scheme, or our Cyber Essentials checklist to see exactly what each control requires across Mac and Windows.

Book a free consultation with our team to talk through which framework fits your business and where your Apple fleet stands against it.

What Is Infrastructure as Code and Why It Is the Future of Apple Fleet Management

What Is Infrastructure as Code and Why It Is the Future of Apple Fleet Management

Ask most businesses how their laptops and Macs get configured and the answer is some version of the same thing. Somebody in IT logs into a management console, clicks through a series of menus, sets up a policy, assigns it to a group and saves. When the same change needs making somewhere else, they do it all again by hand. When something breaks, they try to remember what they altered.

This is the manual model of IT management. It has run the industry for decades and, for a small fleet managed by one person, it works well enough. As a business grows, though, it starts to strain. Configurations drift apart. Changes become inconsistent. Nobody can say with confidence what is actually deployed across the fleet right now.

Infrastructure as Code is the answer to that problem. It is not a distant, enterprise-only concept. It is a practical approach that forward-thinking businesses and IT partners are adopting today, and it is quietly becoming the standard for how a modern Apple fleet should be managed.

What Infrastructure as Code actually means

Infrastructure as Code, usually shortened to IaC, is the practice of managing your IT setup through written instructions rather than manual clicks. Instead of configuring a device policy by hand in a console, you describe what the setup should look like in a file. That file becomes the definitive record of how things should be, and an automated system reads it and makes reality match.

The shift sounds subtle but it changes everything. In the old model, you tell the system what to do, step by step, every single time. In the IaC model, you describe the end result you want and let the system work out how to get there and keep it there.

Think of it as the difference between giving someone verbal directions to a destination every time they drive, versus handing them a map they can follow, share, correct and reuse. The map does not get tired, does not forget a turning and does not do it slightly differently on a bad day. The instructions are written down, reviewable and repeatable.

For an Apple fleet, this means your security settings, your device policies, your application deployments and your compliance rules all live as written configuration rather than as a series of manual actions locked inside one person’s memory and one console’s history.

Why this matters more as your fleet grows

A handful of Macs configured by one careful administrator can be managed manually without much trouble. The problems begin when scale, distribution and staff changes enter the picture, which they always do as a business succeeds.

Consider what manual management looks like at fifty or a hundred devices across several locations, with remote workers and a compliance obligation. Every new starter’s device is set up by hand, so small inconsistencies creep in. One machine gets a setting another misses. Over months, the fleet becomes a patchwork of slightly different configurations, none of them documented.

Then the administrator who built it all leaves. The knowledge of why things are set up the way they are walks out with them. Their replacement inherits a console full of policies with no record of the reasoning behind any of them.

IaC removes these failure points. Because the configuration is written down and stored centrally, every device is built from the same definition. Nothing depends on memory. Nothing is undocumented. The setup can be understood, reviewed and rebuilt by anyone with the right access, regardless of who originally created it.

The four things Infrastructure as Code gives you

Consistency

Every device is configured from the same definition, so every device is genuinely identical in its setup. There is no drift, no forgotten setting, no machine quietly running a different configuration to the rest. When you need to change something across the whole fleet, you change the definition once and it applies everywhere, exactly the same way.

A complete audit trail

Because changes are made through written configuration, every change is recorded automatically. Who changed what, when, and why is captured as a matter of course rather than something anyone has to document separately. For a business that has ever tried to reconstruct what happened before a security incident, this is transformative. The record simply exists.

Rollback and recovery

When a change causes a problem, you revert to the previous known-good version and the fleet returns to how it was. If a management environment is lost or corrupted entirely, the whole configuration can be rebuilt from the written record. The documentation and the recovery plan are the same thing, always current, because they are the very thing that runs the fleet.

Provable compliance

This is where IaC earns its place for any business with an obligation to meet. Instead of gathering evidence by hand before an audit, the evidence is generated continuously as a byproduct of how the fleet is run. An assessor asking what changed, when and who approved it gets a precise, timestamped answer. Compliance stops being an annual scramble and becomes a state you can demonstrate at any moment.

Why compliance teams should care most of all

For businesses pursuing Cyber Essentials, ISO 27001 or SOC 2, the hardest part of certification is rarely the controls themselves. It is proving, on demand and consistently, that those controls are genuinely in place across every device and have stayed in place over time.

Manual management makes this a recurring burden. Before each assessment, someone compiles evidence, checks devices individually and hopes nothing has drifted since the last review. The process is slow, error-prone and only ever a snapshot.

Infrastructure as Code changes the nature of the task. When your security configuration is defined in code and enforced automatically, compliance is not something you prepare for. It is something the system maintains and records by default. If a device drifts from the required state, the system either corrects it or flags it. The evidence an auditor wants is produced automatically, accurately and continuously.

For regulated sectors where an audit failure carries real commercial and legal consequences, this is the difference between hoping you are compliant and knowing you are.

Why this is the future of fleet management

Software developers solved the problem of managing complex, changing systems years ago. They learned that anything important should be written down as code, stored centrally, reviewed before it changes and deployed automatically. Those disciplines made software teams faster, safer and more reliable.

IT infrastructure is now following the same path, for the same reasons. As fleets grow, as compliance obligations tighten and as businesses distribute across locations and remote workers, the manual model simply cannot keep up. The volume of change is too high and the cost of inconsistency too great.

There is a further reason this shift is accelerating. As automation and AI tooling increasingly assist IT teams, the businesses whose fleet configuration already lives as code will be able to use those tools to review, improve and safeguard their setup. Those still clicking through consoles will not. Writing your infrastructure down as code is what makes everything that comes next possible.

The direction of travel is clear. Manual management is becoming the exception, and code-defined, automated, auditable fleet management is becoming the standard that serious businesses expect.

Where nDuo is heading with this

We are building toward exactly this future for the Apple fleets we manage. Our long-term direction combines the discipline of Infrastructure as Code with nDuo iQ, the platform we are developing to give businesses a single, clear view of their entire fleet and its compliance posture across both Apple and Windows.

The goal is fleet management that is consistent by design, auditable by default and compliant continuously rather than occasionally. For a UK business in a regulated sector, that is not a technical nicety. It is the foundation of a security posture you can actually stand behind.

We will be publishing a detailed companion piece for the technically minded over the coming weeks, showing how this works in practice with real tools and a real setup, including the two test environments we are running to explore what is possible and where the limits lie. It will cover the specific platforms, the architecture and the honest lessons from building it.

If you are simply wondering whether there is a better way to manage and secure your growing Apple fleet than configuring each device by hand, there is, and it is more within reach than you might think.

Book a free consultation with our team to talk through how modern, code-defined fleet management could work for your business.

Why Windows Experts Struggle with Mac Management, and What That Costs Your Business

Why Windows Experts Struggle with Mac Management, and What That Costs Your Business

This post is NOT an attack on Windows expertise. Windows administration is a deep, complex discipline. The skills required to manage Active Directory, Group Policy, Intune, Exchange and the rest of the Microsoft stack at scale take years to develop and are genuinely valuable.

The problem is not that Windows IT professionals lack skill. The problem is that those skills do not transfer to Mac management in the way most people assume. And in a world where UK businesses increasingly run mixed Apple and Windows fleets, that assumption is costing businesses real money, in security gaps, compliance failures, user frustration and wasted IT time.

This post explains why. Not to embarrass anyone, but because understanding the gap is the only way to close it.

The assumption that creates the problem

When a business adds Macs to a Windows-majority fleet, the most common decision is to hand Mac management to the existing IT team or IT provider. The logic is straightforward: they already manage all the devices, they understand the network, they have the admin access. Adding some Macs to their workload seems like a small extension of what they already do.

What actually happens is that the IT team applies Windows thinking to a platform that works fundamentally differently. Not slightly differently. Fundamentally differently. The management model, the security architecture, the update mechanism, the application framework, the identity integration, all of it works differently on Mac.

The result is a fleet of Macs that appear to be managed but are not managed well. Policies that do not apply correctly. Patches that do not deploy reliably. Security configurations that look right on paper but have gaps in practice. Users end up with a worse experience on Mac than they would on Windows, not because Mac is worse, but because nobody who understands the platform configured it.

The Group Policy problem

Group Policy is the foundation of Windows device management. It is how Windows IT teams push settings, enforce policies, restrict software and configure security across every device in the domain. If you have spent years managing Windows, Group Policy is the mental model through which you understand device management.

Mac does not have Group Policy. It has never had Group Policy. It will never have Group Policy (hopefully). Mac uses configuration profiles, XML files that define settings and reach devices through an MDM platform.They achieve some of the same outcomes as Group Policy but through a completely different mechanism with completely different logic, completely different syntax and completely different limitations.

A Windows IT professional who knows Group Policy inside out does not automatically know configuration profiles. They are different things. A preference key in a macOS configuration profile is not a registry entry. An MDM scope in a MDM is not an OU in Active Directory. A PreStage enrolment in MDM is not an Autopilot deployment profile. The concepts map loosely but the implementation differs in ways that matter enormously in practice.

The common mistake: a Windows admin inherits a Mac fleet and tries to replicate the Group Policy logic they know in the MDM platform. They create policies that make sense from a Windows perspective but either fail to apply correctly on macOS, hit the wrong scope or conflict with how macOS handles configuration delivery. The devices appear enrolled. The policies appear applied. Under the hood, the configuration is wrong.

Active Directory thinking does not translate

Most Windows environments centre on Active Directory. Users, computers, groups and policies all live in AD. The domain is the boundary. Everything flows from the directory.

Mac does not join Active Directory the way Windows does. You can bind a Mac to Active Directory and Apple supports it, but it is increasingly the wrong approach for modern Mac management and creates more problems than it solves.

Group Policy requires Active Directory, an on-premises directory service. MDM and Group Policy serve different functions and neither replaces the other entirely. This is obvious to anyone who manages both platforms. It is not obvious to a Windows administrator encountering Mac management for the first time.

Modern Mac management uses Apple Business as the device enrolment layer, an MDM platform like Jamf Pro/Iru for policy delivery, and a cloud identity provider like Okta, Microsoft Entra ID or Google Workspace, as the identity layer. The directory is not on-premises. The policies are not delivered through AD. The user accounts are not domain accounts in the traditional sense.

A Windows administrator who joins a Mac to Active Directory, creates a corresponding computer object and tries to apply Group Policy to it is not managing the Mac incorrectly out of malice. They are applying the only mental model they have to a platform where that model does not fit. The Mac will appear domain-joined. Logins may appear to work. Under the surface, the security configuration that MDM should be enforcing is absent, because the Mac was never properly enrolled in an MDM platform.

The antivirus assumption

Windows has had a persistent malware problem for decades. As a result, Windows IT management culture places significant emphasis on antivirus software. Installing, managing and monitoring antivirus across the Windows fleet is a standard, expected part of the Windows IT workflow.

When a Windows IT team inherits a Mac fleet, the antivirus mindset comes with them. They install a Windows-oriented endpoint protection product on the Macs, confirm it is running and consider the malware question answered.

The Mac security model works differently. Apple’s built-in security architecture, XProtect, Gatekeeper, System Integrity Protection, the notarisation requirement, the app sandbox and creates a fundamentally different threat landscape than Windows. These controls are deeply embedded in the operating system and interact with management tools in specific ways.

A Windows-oriented endpoint protection tool that works excellently on Windows may create conflicts, performance issues or management blind spots on Mac. The right endpoint protection tools for Mac like Jamf Protect, CrowdStrike Falcon and few others with Mac support, (example: Microsoft Defender for Business with proper Mac configuration) are chosen and configured with the Mac security model in mind, not ported from a Windows deployment.

This matters for Cyber compliance specifically. An assessor reviewing your malware protection posture for an Apple fleet expects to see Mac-native or Mac-appropriate tools properly configured. A Windows endpoint protection tool installed on Macs without proper Mac-specific configuration is not the same as a well-implemented Mac security posture, regardless of what the dashboard shows.

The patching gap

Windows patching is largely centralised through Windows Update, WSUS or Intune’s Windows Update for Business integration. Windows IT teams develop strong instincts around patch management for Windows, the Patch Tuesday cycle, the testing rings, the deployment groups.

Mac patching works differently and the differences create gaps when managed by Windows-trained teams.

macOS updates come from Apple’s servers and are managed through MDM policy enforcement. iOS and iPadOS updates for iPhones and iPads in scope follow the same mechanism. Third-party application updates on Mac like Chrome, Slack, Zoom, Adobe and dozens of others, do not go through Windows Update or any equivalent central Windows patching mechanism. Each application has its own update mechanism.

A Windows IT team managing a Mac fleet with Intune faces a specific and significant problem here. Intune natively patches only a limited number of Microsoft applications on Mac. Third-party application patching on Mac via Intune requires custom scripts, manual packaging or additional tooling.

A Windows admin comfortable with Patch My PC integrating with Intune for Windows application patching will find that the same tool does not deliver the same breadth of coverage on Mac. The Jamf App Catalog covers over 190 Mac applications with automated patching. There is no equivalent native solution in Intune for Mac.

The practical consequence for businesses relying on Windows-trained IT teams to manage their Mac fleet: Windows devices are patched comprehensively within the Cyber Essentials 14-day window. Mac third-party applications are patched inconsistently, manually or not at all, because the tooling the IT team knows does not work the same way on Mac.

The enrolment assumption

Windows device management starts with domain join or Entra ID join. The enrolment model is familiar to any Windows IT administrator.

Mac enrolment through Apple Business and MDM PreStage is a different process that trips up Windows-trained teams consistently.

The most common mistake: a Windows IT team receives new Macs and enrolls them manually, connecting to the company Wi-Fi, downloading a management profile from a URL, clicking through the enrolment flow. The Macs appear enrolled. The MDM platform shows them as managed. What actually happened is user-initiated enrolment rather than Automated Device Enrolment through Apple Business.

The difference is significant. User-initiated enrolment creates an enrolment that the user can remove. ADE enrolment through Apple Business creates a supervised, persistent enrolment that the user cannot remove. Supervision enables a significantly broader set of management capabilities, restrictions, configuration options and security controls that are simply unavailable on non-supervised devices.

A Mac fleet enrolled manually by a Windows IT team is a fleet where users can unenrol their own devices, where supervision is absent and where a significant proportion of the management capability of the MDM platform is simply unavailable. The fleet looks managed. It is not managed well.

The FileVault misunderstanding

FileVault is macOS’s full disk encryption. It is the Mac equivalent of BitLocker on Windows. Both encrypt the disk. The management model and the recovery key architecture are completely different.

Windows IT teams managing BitLocker understand the escrowing of recovery keys to Active Directory or Entra ID. They are comfortable with the BitLocker management workflow in Intune or Group Policy.

FileVault management through MDM works differently. The recovery key must be escrowed to the MDM platform at the point of FileVault enablement. If FileVault is enabled by the user before MDM enrolment or if the enrolment sequence is incorrect then the recovery key may not escrow to the MDM platform. The disk is encrypted. The IT team has no recovery key. When the user forgets their password or the device needs to be recovered, IT has no way to unlock the device.

This is a scenario that plays out repeatedly in Mac fleets managed by Windows-oriented IT teams. BitLocker key escrowing is handled differently by Windows, and the assumption that FileVault works the same way leads to Mac fleets where encryption is technically enabled but the recovery keys are not centrally held.

The user experience consequence

Beyond the security and compliance gaps, there is a practical user experience consequence that businesses often underestimate.

Mac users chose Mac for a reason. They are typically more technically capable than average, more opinionated about their tools and more sensitive to a poorly configured environment. A developer whose Mac has been configured by a Windows IT team using Windows logic will notice. The policies will feel wrong. The restrictions will be in the wrong places. The management tools may conflict with the development workflow.

The result is shadow IT. Developers find workarounds. Settings get changed. MDM profiles get removed where possible. The carefully configured management environment degrades as users work around it.

This is not a user behaviour problem. It is an IT configuration problem. A well-configured Mac environment, built by someone who understands how Mac users work and what Mac management is designed to do, does not generate the same friction. Users stay inside the managed environment because the managed environment does not get in their way.

What this means for Cyber Essentials compliance

All of the gaps above, misconfigured policies, absent supervision, inconsistent patching, incorrect FileVault management have a direct bearing on Cyber Essentials compliance.

A business that achieves Cyber Essentials certification with a Windows-trained IT team managing their Mac fleet may have attested to controls that are not correctly implemented. The self-assessment questionnaire asks whether controls are in place. A Windows IT team that believes they have correctly implemented Mac management will answer yes. An independent technical assessor conducting a Cyber Essentials Plus audit will find the gaps.

This is one of the most common patterns we see when businesses come to nDuo after having their Mac fleet managed by a generalist or Windows-oriented IT provider. The paperwork says the controls are in place. The technical reality does not match the paperwork.

The honest point about Windows expertise

None of the above is a criticism of Windows expertise. A skilled Windows administrator is genuinely valuable and the skills involved in managing a complex Windows environment at scale are not trivial.

The point is specificity. Mac management requires Mac expertise in the same way that Windows management requires Windows expertise. A Mac specialist handed a complex Active Directory environment would make the same kinds of mistakes in reverse, applying Mac thinking to a platform where it does not fit.

The businesses that manage mixed fleets well understand this. They do not ask their Windows IT team to manage Macs without Mac-specific support. They either develop Apple expertise in-house or they work with a specialist partner for the Apple part of the fleet while keeping Windows management with their existing team.

The worst outcome and the most common is a Windows-oriented IT provider who manages the Mac fleet as an afterthought, uses the tools they know rather than the tools the platform requires, and produces a fleet that appears managed but has significant gaps underneath.

How to tell if your Mac fleet has this problem

Ask your current IT provider these questions:

1. Are your Macs enrolled through Apple Business Manager with Automated Device Enrolment or through manual user-initiated enrolment? If they cannot answer immediately, that is a signal.

2. Are your Macs supervised? Supervision is only available through ADE. If they are not sure, the answer is probably no.

3. Are your FileVault recovery keys escrowed to your MDM platform? Ask them to show you the recovery key for a specific device. If they cannot, the keys are not held centrally.

4. Which MDM platform manages your Macs and how do third-party applications like Chrome, Slack, Zoom get patched on Mac? If the answer involves Windows tools or manual processes, there is a gap.

5. What compliance reports does your MDM generate for Cyber Essentials? If they cannot produce a device-by-device patch compliance report and encryption status report, the compliance evidence trail does not exist.

These are not trick questions. A team with genuine Mac expertise will answer all of them immediately and specifically. A team managing Mac as an afterthought will struggle.

Getting Mac management right

The fix is not necessarily replacing your existing IT provider. For many businesses, the right answer is a specialist Apple partner working alongside the existing Windows IT team, handling the Apple-specific management while the existing team continues to do what they do well.

This is exactly how we work with many nDuo clients. The Windows IT function stays with the team that knows it. The Apple MDM implementation, the Jamf Pro configuration, the Cyber Essentials compliance posture for the Apple fleet and the managed IT support for Mac users comes to us.

The two teams integrate through shared tooling – nDuo iQ brings Jamf Pro and Microsoft Intune into a single management view so both teams can see the full fleet without operating in separate silos.

If you are an IT Director who has read this post and recognised some of these patterns in your current environment, or a business owner who has noticed that your Mac users seem to have a worse experience than your Windows users despite having the same IT provider, the starting point is a conversation.

Read our Apple IT support page for more on how we work with UK businesses, or our Jamf Pro vs Microsoft Intune comparison to understand the platform differences in more detail.

Book a free consultation with our team and we will give you an honest assessment of your current Mac management posture.

Why the 14-Day Patching Window Is No Longer Enough, And What UK Businesses Should Do Instead

Why the 14-Day Patching Window Is No Longer Enough, And What UK Businesses Should Do Instead

Whoever wrote the Cyber Essentials 14-day patching requirement wrote it for a different threat landscape. In 2018 it made sense. The average time between a vulnerability being disclosed and attackers actively exploiting it was 756 days. Businesses had over two years to patch before most threats materialised. A 14-day window was conservative, achievable and genuinely protective.

That world no longer exists.

The average time from CVE disclosure to a working exploit has collapsed from 56 days in 2024 to roughly 10 hours in 2026. The 14-day patching window, the standard that Cyber Essentials enforces and that most UK businesses are working toward, now leaves a gap of approximately 13 days, 23 hours and 50 minutes during which attackers with a working exploit can reach unpatched systems.

This is not an argument against Cyber Essentials. Meeting the minimum standard no longer guarantees protection. The certification is still worth pursuing. The 14-day window is still worth meeting. But treating it as sufficient is the security equivalent of locking your front door and leaving the back window open.

The numbers that make the case

The data on exploitation timelines is stark and consistent across multiple independent sources.

In 2018 the median time from vulnerability disclosure to first observed exploit was 771 days. In 2021 that window had compressed to 84 days. By 2023 it was six days. By 2024 it was four hours.

Mandiant’s M-Trends 2026 report puts the mean time to exploit at negative seven days, attackers routinely compromise systems before vendors release a patch at all.
Read that again. The average exploit now happens before the patch exists. A 14-day patching window assumes a patch is available when you start the clock. In 2026 attackers are frequently through the door before the patch exists, let alone before you have deployed it.

In 2025, attackers exploited 28.96% of known vulnerabilities on or before the day their CVE appeared, up from 23.6% the previous year. By 2026, zero-days account for 67.2% of all exploited CVEs, up from 16.1% in 2018. When attackers weaponise two-thirds of exploited vulnerabilities before any patch exists, reactive security has already lost.

There is also a structural problem with the CVE publication process itself. The National Vulnerability Database faces delays averaging 23 days between exploit publication and CVE assignment. This gap allows attackers to exploit vulnerabilities before defenders can even begin patching.

The implication is uncomfortable but clear: by the time a vulnerability appears in your patch management queue with a CVE number attached, attackers may have been exploiting it for three weeks.

What the 14-day window was designed to prevent

The 14-day patching requirement targets a specific and genuine problem — businesses running known vulnerabilities for months or years because patching was manual, inconvenient or simply forgotten. Zero-day exploitation was never what it set out to prevent.

That problem is real and the 14-day rule addresses it. Patching within 14 days of a release puts a business in a significantly stronger position than one running monthly or quarterly patch cycles.The requirement has raised the baseline meaningfully across UK businesses.

The issue is not that the 14-day rule is wrong. The real problem is that businesses increasingly mistake a Cyber Essentials pass for comprehensive protection. For the most dangerous category of vulnerabilities, those actively exploited in the wild, 14 days is not a protection window. It is a breach window. It is a breach window.

The AI acceleration problem

The collapse of exploitation timelines is not accidental. AI-assisted tooling is generating working exploits in minutes. Automated scanners are firing on freshly disclosed vulnerabilities within the same business day they appear publicly. The pattern is consistent -> disclose -> scan -> exploit, compressed to hours.

Traditional Patch Tuesday monthly cycles, once considered industry best practice, are now dangerously obsolete. When attackers exploit vulnerabilities in hours or days, organisations patching on monthly schedules are fighting with one hand tied behind their backs.

For UK businesses this is not a theoretical concern. The same AI tools that accelerate legitimate development are available to attackers. A critical macOS vulnerability published on a Monday morning can have automated exploitation scripts circulating in underground forums by Monday afternoon. By the time your IT team processes the alert on Tuesday and schedules patching for the following week, the window has long since closed.

In 2025 the public CVE program published 48,185 new vulnerabilities, a 20.6% jump on top of the record 38% surge in 2024. The CISA Known Exploited Vulnerabilities catalogue grew 20% to 1,484 entries. The volume of vulnerabilities is increasing at the same time as the exploitation window is collapsing. The combination is the security challenge of 2026.

What good patching actually looks like in 2026

Meeting the 14-day Cyber Essentials requirement should be treated as the floor, not the ceiling. Here is what a genuinely protective patching posture looks like in practice.

Automated patching for the majority

The most effective single change any UK business can make to its patching posture is removing humans from the routine patching loop entirely. Routine patches operating system updates, browser updates, productivity app updates, should deploy automatically without requiring IT to approve, schedule or manually push each update.

For Mac fleets, JAMF MDMs should handle this natively. macOS updates, iOS and iPadOS updates and third-party applications covered by the good App Catalog all update automatically based on policies you define. You set the deadline, 24 hours for critical patches, 72 hours for high severity, seven days for medium and the MDM enforces it across every device without human intervention.

For Windows devices, Microsoft Intune combined with Windows Update for Business handles OS patching automatically. For third-party application patching on Windows such as Chrome, Adobe, Zoom and hundreds of others, Patch My PC integrates directly with Intune and automates the update cycle for over 1,500 applications without manual packaging.

Automated patching does not mean uncontrolled patching. You define the rings, which devices update first, what testing happens, what the rollout timeline looks like. What it removes is the dependency on a human remembering to act within a specific window.

Risk-based triage for critical vulnerabilities

Not all vulnerabilities are equal and treating them identically is how you end up with overwhelmed IT teams and missed critical patches. A structured risk-based approach prioritises based on actual exploitation risk rather than theoretical severity scores.

CVSS scores measure theoretical severity, how bad could this vulnerability be in a worst-case scenario. They do not measure whether anyone is actually exploiting it right now. A CVSS 9.8 vulnerability that no attacker is targeting is less urgent than a CVSS 7.2 vulnerability with confirmed active exploitation.

The practical framework for risk-based patching:

Any vulnerability on the CISA Known Exploited Vulnerabilities catalogue – patch within 24 to 48 hours. These are vulnerabilities with confirmed active exploitation in the wild. The standard 14-day window is irrelevant. These need to be treated as emergencies.

Critical CVEs with proof of concept exploit code publicly available – patch within 48 to 72 hours. The existence of public exploit code dramatically increases the likelihood of widespread exploitation. Do not wait for the 14-day window.

High severity CVEs without confirmed exploitation – patch within seven days. Faster than the Cyber Essentials requirement but still manageable for most IT teams with automated patching in place.

Medium and low severity CVEs – patch within 14 days as the Cyber Essentials requirement specifies. The standard window is appropriate for vulnerabilities without active exploitation.

This tiered approach does not conflict with Cyber Essentials. It exceeds it for the vulnerabilities that actually matter while maintaining the standard requirement for lower-risk patches.

Monitoring for active exploitation – not just CVE feeds

The 14-day clock starts when a CVE is published. But as the data above shows, exploitation frequently begins before the CVE exists. Monitoring only CVE feeds means you are watching the wrong signal.

More useful signals for UK businesses:

1. The CISA Known Exploited Vulnerabilities catalogue – updated continuously with vulnerabilities confirmed to be actively exploited. Subscribe to alerts and treat every addition as a priority patch event.

2. Vendor security advisories – Apple, Microsoft, Google and major software vendors publish emergency out-of-band security updates for actively exploited vulnerabilities. These frequently arrive before a CVE number is assigned. Subscribe to security advisories for every major software vendor in your environment.

3. Threat intelligence feeds – for businesses in regulated sectors, subscribing to a threat intelligence service that provides early warning of active exploitation against specific software is increasingly worth the investment.

The Apple fleet patching picture

For businesses running Mac, iPhone and iPad fleets specifically, the patching challenge has some Apple-specific dimensions worth understanding.

Apple releases security updates for macOS, iOS and iPadOS regularly. Recent individual cases show the pattern clearly – CVE-2025-10585 affecting Chrome V8 was actively exploited within 24 hours of disclosure. CVE-2026-35616 in Fortinet FortiClient was weaponised almost immediately after disclosure. Apple-specific vulnerabilities follow the same compressed timeline.

Without MDM, enforcing patching deadlines across an Apple fleet is a manual process that depends on individual employees applying updates when prompted. Staff routinely defer update notifications, “I’ll do it later” and “later” frequently becomes “never until the next Genius Bar visit.” On an unmanaged fleet of 30 Macs there is no reliable way to know which devices are current and which are running a three-month-old operating system with known exploited vulnerabilities.

With an MDM, OS update enforcement works as follows: you define a deadline, MDM sends progressive notifications as the deadline approaches and on the deadline date the update applies whether the employee has actioned it or not. MDM compliance reporting confirms which devices are current and flags any that are non-compliant in real time. For a business with Cyber Essentials obligations, or simply a business that takes security seriously, this is the difference between knowing your fleet is patched and hoping it is.

For iPhone and iPad in scope for Cyber Essentials, the same MDM-enforced patching applies. Devices enrolled in Jamf Pro can be required to run a minimum iOS or iPadOS version with enforcement deadlines that match your patching policy.

The honest conversation about Cyber Essentials

Cyber Essentials is worth doing. The five controls it requires are genuinely protective and the certification demonstrates to clients, insurers and regulators that your basic security posture meets a recognised standard. The patching requirement specifically has driven meaningful improvement in how UK businesses manage updates.

The concern is not with the certification. The concern is with how it is often communicated and received.

When a business achieves Cyber Essentials certification it frequently communicates this to clients and leadership as “we are secure.” What it actually means is “we meet the minimum technical baseline that was designed to address the most common cyber attacks.” Those are meaningfully different statements and conflating them creates a false sense of protection that sophisticated attackers actively exploit.

A business that patches within 14 days, enforces MFA on cloud services, runs endpoint protection and has a properly configured firewall is in a much better position than one without any of those controls. The same business thinking that Cyber Essentials certification represents comprehensive protection is in a worse position than one that treats it as the starting point for a broader security programme.

The 14-day patching window is the most concrete example of this gap. It was protective in 2018. In 2026 it is the minimum acceptable standard, not the target.

What to implement and in what order

If you currently patch within the Cyber Essentials 14-day window and want to genuinely improve your patching posture, here is the practical sequence:

1. Automate routine patching first. Remove humans from the loop for OS updates and standard application updates. Jamf Pro for Mac, Intune combined with Patch My PC for Windows.

2. Subscribe to CISA KEV alerts. Free, authoritative and updated continuously with confirmed active exploitation. Set up email alerts so critical additions trigger immediate action rather than waiting for the next scheduled patch review.

3. Subscribe to Apple and Microsoft security advisories. Both vendors publish out-of-band emergency security updates for actively exploited vulnerabilities. These updates should be applied immediately, not at the next scheduled maintenance window.

4. Implement a risk-based triage process. Not every patch is an emergency. Having a defined process for categorising and prioritising patches means critical vulnerabilities get same-day attention without creating alert fatigue that causes important patches to be missed.

5. Review your Cyber Essentials posture through this lens. If you are currently meeting the 14-day requirement manually, someone reviews a list, schedules patching, confirms completion. you are meeting the minimum. Automating that process and adding the risk-based triage layer above it moves you from minimum compliance to genuine protection.

The bottom line

Fourteen days was a reasonable patching window when the average exploit took two years to develop. It is not a reasonable patching window when the average exploit takes 10 hours.

Meeting the Cyber Essentials patching requirement is worth doing, not because 14 days is sufficient but because it establishes the discipline of regular patching and forces businesses to have tooling in place that can be tightened. A business with automated patching meeting a 14-day deadline can tighten that to 48 hours for critical CVEs with a configuration change. A business patching manually on a monthly cycle cannot.

The goal for 2026 is not to meet the 14-day Cyber Essentials requirement. The goal is to treat the 14-day requirement as your worst-case fallback for low-risk patches and to have a faster, automated, risk-based process for everything that matters.

We work with UK businesses running Apple and mixed fleets to implement exactly this, automated patching through MDMs, risk-based triage processes and the ongoing management that keeps the patching posture current as the threat landscape continues to accelerate.

Read our Cyber Essentials checklist to understand the full compliance picture, or our Jamf Pro vs Microsoft Intune comparison to understand which patching automation tooling is right for your fleet.

Book a free consultation with our team to review your current patching posture and find out where the gaps are before an attacker does.

Zero Touch Deployment for Windows and Mac: A Practical UK Business Guide

Zero Touch Deployment for Windows and Mac: A Practical UK Business Guide

A new employee starts on Monday. They are based in Glasgow. Your IT team is in London. The MacBook and the Windows laptop ship directly from the supplier.

By Tuesday morning the employee should have both devices configured, enrolled, compliant and ready to use, without IT touching either of them..

That is zero touch deployment. And in 2026 it is no longer just for large enterprises. It is the standard expectation for any UK business with a distributed team, remote workers or simply more efficient priorities than spending hours manually configuring devices.

This post covers how zero touch deployment works for both platforms; Windows via Microsoft Intune and Autopilot, Mac via Jamf Pro and Apple Business Manager. What each workflow actually involves, where the challenges sit and what the honest picture looks like when businesses try to run Mac zero touch deployment through Intune rather than Jamf.

What zero touch deployment actually means

Zero touch deployment is the process of onboarding and configuring new devices for employees without requiring an IT technician to set them up manually. Devices ship directly from the manufacturer or supplier to the end user and configure themselves on first boot using predefined company settings.

The employee receives the device, powers it on, connects to Wi-Fi and signs in with their corporate credentials. Within minutes the device enrols in MDM, applies its configuration profiles, installs its applications and enforces its security policies. IT never touched the device. The employee never waited for IT.

IT teams chase zero touch deployment for faster onboarding, consistent device setups, fewer configuration errors, stronger security from day one and easier scaling for globally distributed teams.

The tools that make this possible differ by platform. For Windows, the technology is Windows Autopilot working alongside Microsoft Intune. For Mac, it is Apple Business working alongside Jamf Pro. Both approaches achieve the same outcome, a device that arrives ready, but the architecture, the workflow and the practical experience differ significantly.

Zero touch deployment for Windows – Intune and Autopilot

How Windows Autopilot works

Windows Autopilot uses device identity, Microsoft Entra ID and Intune to turn a raw Windows device into a business-ready endpoint during first sign-in. Devices ship directly to users and join management without imaging or manual setup. Users unbox, connect to Wi-Fi and sign in to receive policies and profiles.

The process begins before the device ships. At the time of purchase, the OEM or reseller registers the hardware hash, a unique digital fingerprint of the device in your Microsoft Entra ID tenant. When the user powers up and connects to the internet, the device contacts the Autopilot service, recognises your tenant and starts guided setup. The device joins Entra ID and automatically enrolls in Intune.

From that point, Intune pushes everything, configuration profiles, compliance policies, security baselines, application assignments and encryption settings, all based on the user’s role and group membership. The Enrolment Status Page displays progress and can block desktop access until required applications, policies, certificates and connections are fully in place.

Prerequisites for Windows Autopilot

Before your first Autopilot deployment, the following needs to be in place:
– Microsoft Intune configured and licensed – included in Microsoft 365 Business Premium, E3 or E5.
– Microsoft Entra ID with automatic MDM enrolment enabled – devices joining Entra ID must auto-enrol to Intune.
– Hardware hashes registered – your OEM, reseller or Microsoft Partner must register devices in your Autopilot portal before they ship. Most first deployments miss this step.
– Autopilot deployment profile created in Intune – defining the out-of-box experience, whether user-driven or self-deploying, and assigned to a dynamic device group.
– Applications and configuration profiles scoped to the relevant groups – defining what installs and configures at first boot.
– Compliance policies defined – what constitutes a compliant device and what happens when a device does not meet the standard.

The Windows Autopilot workflow step by step

The OEM or reseller registers the hardware hash in your Autopilot portal at the time of order. The device ships directly to the employee’s address, no IT warehouse stop required.

The employee unboxes the device and connects to Wi-Fi. Windows contacts the Autopilot service and recognises the device belongs to your organisation. Your corporate setup flow replaces the standard consumer out-of-box experience.

The employee signs in with their corporate credentials via Entra ID. The device joins Entra ID and automatically enrols in Intune. Intune pushes configuration profiles, compliance policies, security baselines, BitLocker encryption, Microsoft Defender for Endpoint and application assignments based on the user’s role.

The Enrolment Status Page shows the employee each application and setting as it installs. Once it finishes, the device is fully enrolled, compliant and ready.

Where Windows Autopilot delivers well

For Windows devices on a Microsoft 365 environment, Autopilot is mature, reliable and genuinely zero touch when correctly configured. Windows Hello for Business, BitLocker encryption and automatic security update application are all enforced from first boot, reducing the risk of misconfiguration.

The deep integration between Autopilot, Entra ID and Intune means the identity layer and the device management layer are unified from the start. Conditional Access policies enforcing that only compliant, enrolled devices can access Microsoft 365 applications are straightforward to implement alongside Autopilot.

Leaders can calculate operational savings by retiring imaging infrastructure and reducing desk-side deployment labour. Shipping directly to employees cuts warehouse handling, saving measurable hours per device.

Zero touch deployment for Mac – Jamf Pro and Apple Business

How Mac zero touch deployment works

Zero touch deployment for Mac uses Apple’s Automated Device Enrolment (ADE) as the foundation. ADE requires no IT intervention. You assign a Mac bought through Apple or an authorised reseller to your MDM server in Apple Business. When the employee powers it on for the first time, the device contacts Apple’s servers, receives its MDM assignment and begins enrolling automatically.

Jamf Pro is the MDM platform that handles everything that follows. Once the device enrols, Jamf pushes configuration profiles, installs applications, enforces security policies and can customise the entire setup experience using tools like Jamf Setup Manager, a branded interface that shows the employee each application as it installs.

Prerequisites for Mac zero touch deployment via Jamf Pro

Apple Business account configured and active, the free platform that manages device enrolment, Managed Apple Accounts and app licensing for your organisation.

Devices purchased through Apple or an authorised reseller and assigned to your MDM server in Apple Business before shipping, this is the equivalent of the hardware hash registration step for Windows. Miss this and the device will not enrol automatically on first boot.

Jamf Pro configured with a PreStage enrolment, the configuration that defines what happens when a device enrols for the first time, including configuration profiles, packages and policies applied during setup.

Applications packaged and available in Jamf, either from the Jamf App Catalog for supported titles or custom packages for internal or specialist software.

Identity provider integration – Okta, Microsoft Entra ID or Google Workspace configured so employees sign in with corporate credentials rather than a local Mac account.

The Mac zero touch deployment workflow step by step

Devices are ordered through Apple or an authorised Apple reseller. Before or at the time of shipment, devices are assigned to your MDM server in Apple Business Manager. They ship directly to the employee, no IT staging required.

The employee unboxes the Mac and powers it on. During the macOS Setup Assistant, the device contacts Apple’s servers, detects the MDM assignment and presents the enrolment prompt. The employee is guided through a branded setup interface (Jamf Setup Manager) that shows them what is being installed and keeps them informed throughout the process.

Jamf Pro applies configuration profiles -> FileVault encryption, macOS Application Firewall, screen lock, Gatekeeper, software update policies. Applications install silently in the background. The goal is to have the Mac ready to use by the time the employee finishes the setup flow, apps installed, settings configured, security enforced, all without IT intervention.

The employee signs in with their Okta, Entra ID or Google Workspace credentials via Platform Single Sign-On. Their corporate identity is linked to the device from first boot.

Where Jamf Pro zero touch deployment excels

Jamf Pro’s zero touch deployment is best in class for Apple environments. Automated Device Enrolment is the foundation for modern Mac deployment, and Jamf’s native integration with ADE means the enrolment experience is polished, reliable and genuinely requires no IT intervention when correctly configured.

Jamf Setup Manager transforms the enrolment experience. You can define exactly what happens during provisioning, how it looks, what actions run, what the employee sees at each step, without scripting everything from scratch. It supports multiple languages, accepts JSON or XML configuration and creates a consistent, branded setup experience across every device in your fleet.

Third-party application patching is handled natively through the Jamf App Catalog. The Jamf App Catalog covers over 300 software titles with automated patching. Things like Chrome, Slack, Zoom, Adobe and dozens more update automatically without IT involvement. This is the most significant practical advantage Jamf has over Intune for Mac management and it directly affects your Cyber Essentials compliance posture.

Zero touch deployment with Jamf is modular. If any step in the chain fails, the workflow restarts from that point rather than requiring a full device wipe and reimaging. When workflows need to change, for example when upgrading to a new macOS version, updating the relevant package is usually sufficient. The rest of the deployment continues to work as before.

The honest picture – Mac zero touch deployment via Intune

This is the section that most comparison posts avoid. Intune can manage Macs. Intune can achieve a version of zero touch deployment for Macs. However, the practical reality differs from the Windows experience in ways that matter for IT teams and for compliance.

Check-in delays

Intune’s check-in time for Mac devices is between 8 and 24 hours. When you push a configuration profile or an urgent software deployment to a Mac through Intune, the device may not receive it for up to 24 hours. Jamf Pro check-ins are near real-time. For a zero touch deployment workflow where the employee needs the device ready now, a 24-hour policy propagation window is a meaningful limitation.

No native third-party app patching

Intune has no native support for patching non-Microsoft third-party applications on Mac. Chrome, Slack, Zoom, Adobe and anything outside the Microsoft app ecosystem requires manual packaging, custom scripts or a third-party tool like Patch My PC.

Patch My PC integrates with Intune for Windows application patching but its Mac support is limited. The practical consequence is that a Mac managed by Intune requires significantly more manual effort to maintain application currency than the same Mac managed by Jamf Pro. For businesses with Cyber Essentials obligations, where all critical updates must be applied within 14 days (this is already very long windows from the security point, but that is a separate topic) across every application, this gap requires either additional tooling or ongoing manual oversight.

Zero touch deployment is less polished

Intune does not have a built-in zero touch solution for Mac, and its platform limitations make handling third-party solutions difficult. The enrolment experience through Intune on Mac is functional but lacks the branded, step-by-step setup flow that Jamf Setup Manager provides. Employees setting up a Mac through Intune see a more generic experience than employees setting up through Jamf, and IT teams have less control over the setup sequence.

If you are a Microsoft-first shop, start with Intune, Platform Single Sign-On has improved significantly in 2025 and 2026. If you need granular control for compliance and security, complex scripting – Jamf Pro remains superior.

Scripting limitations

Jamf Pro provides a full shell scripting environment for macOS. Complex deployment workflows, custom application configurations and automated remediation tasks are all achievable through Jamf scripting. Intune’s scripting support for Mac is present but constrained, script size limits, restricted triggering options and narrower automation capability compared to Jamf.

Compliance reporting depth

For businesses pursuing Cyber Essentials, ISO, CIS etc, Jamf Pro generates compliance reports that map directly to the framework. Patch compliance, encryption status, firewall enforcement and application inventory are all available from a single console in the format an assessor needs. Intune requires more manual evidence compilation to achieve the same result for Apple devices specifically.

When Intune for Mac makes sense despite the limitations

The limitations above are real. They are also manageable in the right context. Intune for Mac zero touch deployment makes sense when:

1. Your fleet is primarily Windows with a minority of Macs. Managing both from the Intune console reduces operational complexity.

2. You are already on Microsoft 365 Business Premium and Intune is included. The cost difference versus adding Jamf Pro is significant and your Mac management requirements are basic.

3. Your identity infrastructure is entirely Microsoft, Entra ID, Conditional Access, Defender for Endpoint, and you want device management that integrates natively rather than requiring additional configuration.

4. Your Mac users have straightforward requirements without complex application catalogues, custom scripting or advanced compliance frameworks.

For businesses where any of those descriptions do not apply, where Macs are the primary platform, where compliance reporting is critical, where application patching needs to be automated and reliable, Jamf Pro is the right choice.

Running both – Jamf for Mac and Intune for Windows

The most effective architecture for businesses with significant Mac and Windows fleets is Jamf Pro for Mac management combined with Microsoft Intune for Windows. Both platforms are visible in the Microsoft Intune console through Jamf’s integration, allowing IT to monitor security posture across the whole fleet from a unified view. Conditional Access policies can be enforced consistently across both platforms.

This co-management approach delivers the best capabilities of each platform to each device type rather than compromising on either. With Jamf Pro and Intune, IT support can troubleshoot, update software and enforce security policies remotely across both platforms. Remote diagnostics and resolution can reduce the number of on-site visits by up to 80%.

The operational overhead of running two MDM platforms is real, two consoles, two policy sets, two vendor relationships. For businesses with a large or growing Mac fleet alongside Windows, this overhead is justified by the capability difference. For businesses with a handful of Macs alongside a Windows-majority fleet, Intune for everything may be the more pragmatic choice.

The identity layer – making zero touch work across both platforms

Zero touch deployment for both Windows and Mac depends on a well-configured identity layer. Whether you use Microsoft Entra ID, Okta or Google Workspace, the identity platform is what connects the device to the user, enforces access policies and ties the MDM environment to the rest of your security stack.

Modern zero touch deployment means no local device passwords. Employees sign in to their Mac or Windows device using their corporate email credentials through Platform Single Sign-On. For Mac devices in a Microsoft environment, Platform SSO allows users to sign in with their Entra ID password. Mac devices in a Google environment, federated authentication connects Managed Apple Accounts to Google Workspace credentials.

For businesses using Okta, the integration with both Jamf Pro and Intune is mature. Okta provisions user access, enforces MFA and provides the single sign-on layer that makes the first-boot experience seamless on both platforms. When a new employee joins, Okta provisions their identity. When they first log in on their Mac or Windows device, their identity is already there.

Zero touch deployment and Cyber Essentials compliance

Zero touch deployment is not just an IT efficiency tool. For businesses working toward Cyber Essentials certification, it is one of the most effective ways to maintain a consistent, auditable compliance posture as the team grows.

When a device is enrolled through zero touch deployment, whether Mac via Jamf or Windows via Intune, the compliance configuration is applied at the point of enrolment. FileVault encryption enabled. BitLocker enforced. Firewall on. Screen lock configured. MFA required. Patching policy active. All of it applied before the employee logs in for the first time, not retrofitted after the fact.

For businesses with Cyber Essentials Plus certification requirements, Jamf Pro’s compliance reporting provides the evidence an assessor needs, device-by-device patch status, encryption compliance, policy enforcement, without requiring manual evidence gathering. Intune provides similar reporting for Windows. The combination of both platforms in a mixed fleet gives you a complete, auditable compliance picture across every device.

The alternative, manually configuring each device and relying on individual employees to keep their devices updated, is the approach that fails Cyber Essentials assessments. Every new hire whose device is not enrolled through zero touch deployment is a potential compliance gap.

Getting zero touch deployment right, the common mistakes

Zero touch deployment fails in predictable ways. Understanding them before implementation saves significant time and frustration.

Hardware hashes or ADE assignment not set up before shipping

The most common single point of failure for first deployments. For Windows, if the hardware hash is not registered in Autopilot before the device ships, zero touch does not work. For Mac, if the device is not assigned to your MDM server in Apple Business Manager before first boot, it will not enrol automatically. Both require coordination with your reseller at the point of purchase.

Applications causing Enrolment Status Page timeouts on Windows

Keeping required apps minimal on the Enrolment Status Page so users finish enrolment quickly is strongly recommended. Heavy apps can be delivered post-provisioning. Assigning every application as required during the ESP phase extends the setup time significantly and increases the risk of timeout failures.

Identity provider not connected before deployment

If Platform SSO, Okta integration or federated authentication with Google Workspace is not configured before the first device is enrolled, employees cannot sign in with corporate credentials at first boot. This requires re-enrolment after the fact.

No offboarding process defined

Zero touch deployment is the beginning of the device lifecycle, not the whole of it. Defining the offboarding process, remote wipe for Mac, Intune retire action for Windows, Okta deprovisioning, at the same time as the onboarding process ensures the security posture holds at both ends of the employee journey.

This is where nDuo iQ earns its place. When someone leaves, their Mac can be locked or wiped, their FileVault key retrieved and the device unmanaged from the app, without waiting for someone to be at a console. For distributed teams where the departing employee and the IT admin are in different cities, that gap between the leave date and the device actually being secured is where the real risk sits.

Read our guide to the perfect employee onboarding process for the full lifecycle picture.

What to implement and in what order

If you are starting from scratch or rebuilding a broken deployment workflow, here is the practical sequence:

1. Start with Apple Business Manager. Register your organisation, link your Apple devices and connect your MDM server. This is free and is the foundation everything else builds on.

2. Choose your MDM platform. Mac-primary or Apple-heavy fleets, Jamf Pro. For Windows-primary or Microsoft-first environments, Intune. For mixed fleets with significant Mac requirements, both.

3. Configure your identity layer. Okta, Entra ID or Google Workspace connected to your MDM before the first device is deployed. Platform SSO configured for Mac. Autopilot linked to Entra ID for Windows.

4. Build your deployment profiles. PreStage enrolment in Jamf for Mac. Autopilot deployment profile in Intune for Windows. Applications and configuration profiles scoped to role-based groups.

5. Run a pilot. Three to five devices. Go through the full workflow from order to first login. Identify what breaks. Fix it before rolling out to the whole team.

6. Define offboarding. Remote wipe and MDM unenrolment process for Mac. Intune retire action for Windows. Identity deprovisioning in Okta or Entra ID. Document it before you need it.

Managing Jamf and Intune from a single console – nDuo iQ

For businesses running both Jamf Pro and Microsoft Intune across a mixed fleet, managing two separate consoles adds operational overhead that grows with your team. Our iQ platform solves this by bringing Jamf Pro and Microsoft Intune into a single management portal, one place to view every device across both platforms, monitor compliance status, track security posture and act on issues without switching between consoles.

Rather than an IT admin toggling between Jamf for Mac and Intune for Windows, iQ provides a single pane of glass view across the entire fleet. A device enrolled via Jamf zero touch on Monday and a Windows laptop via Autopilot on Tuesday both appear in the same dashboard, with the same compliance reporting and the same visibility. For businesses managing a mixed Apple and Windows environment, this removes the biggest operational friction point in running two MDM platforms simultaneously.

iQ is built specifically for Apple-first and mixed fleet environments and is designed to sit alongside your existing MDM investment rather than replace it, giving you the depth of Jamf Pro for Mac and the native Windows integration of Intune, unified into one view.

How nDuo helps

We implement and manage zero touch deployment for UK businesses running Mac, Windows and mixed fleets. That means Apple Business setup and MDM connection, Jamf Pro PreStage enrolment configuration, Microsoft Intune Autopilot setup for Windows, Okta or Entra ID integration and the ongoing management that keeps the workflow running reliably as your team grows.

If your current device deployment process involves IT manually configuring each device or employees waiting days for access, zero touch deployment is the fix. For Revolut, it took new-starter onboarding from over an hour of IT time per device to under 15 minutes across globally distributed teams. The investment in getting it right pays back within the first few deployments – read the full story.

Read our guide to the perfect employee onboarding process to see how zero touch deployment fits into the wider onboarding picture, or our Jamf Pro vs Microsoft Intune comparison for a deeper assessment of which MDM platform is right for your fleet.

Book a free consultation with our team to discuss your device deployment workflow and get a clear recommendation on the right approach for your environment.

Managing the macOS Share Menu for NCSC Cyber Essentials

Managing the macOS Share Menu for NCSC Cyber Essentials

Transitioning from legacy Restrictions to Blueprints

If you’re currently working through the UK NCSC Cyber Security Essentials guidance for your fleet, there’s a good chance you’ve been looking at how to restrict the macOS context menu. Specifically, we’re talking about managing what appears when a user right-clicks an item and opens the “Share…” submenu.

From a security perspective, the Share menu presents a quiet but important risk for data exfiltration. That’s why the NCSC guidance recommends locking it down by removing consumer platforms from the list. Specifically, their baseline configuration pack requires disabling AirDrop, Messages, Add to Aperture, Twitter, Facebook, LinkedIn, Video Services, Sina, and Weibo. You can check out the explicit requirements in the NCSC macOS Configuration Pack on GitHub.

For a long time, Jamf Pro admins handled this cleanly inside a standard Restrictions profile. However, while that baseline configuration pack originally targeted macOS 11 Big Sur, relying solely on it today will leave gaps on your modern macOS endpoints.

Let’s look at how we implemented this, what still works, and how to plug the holes using modern management tools.

Figure 1: Visual layout changes of the native “Share…” context submenu from macOS 11 Big Sur to modern releases.

The Legacy Method: The Restrictions Profile

Traditionally, navigating to the Sharing services tab within a Jamf Pro Restrictions profile allowed you to selectively check boxes to disable these platforms.

Figure 2: Legacy Sharing Services selections within the Jamf Pro Restrictions profile.

While Jamf Pro groups these options under the generalised “Restrictions” umbrella, it doesn’t actually leverage the standard com.apple.applicationaccess preference domain behind the scenes. Instead, these specific toggles write to the now-deprecated com.apple.ShareKitHelper domain.

For reference on how Apple originally structured this, you can look over the Apple Developer Documentation for ShareKit.

A raw configuration profile payload implementing these legacy restrictions looks something like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>PayloadContent</key>
	<array>
		<dict>
			<key>PayloadDisplayName</key>
			<string>ShareKit</string>
			<key>PayloadIdentifier</key>
			<string>com.apple.ShareKitHelper.39EF4293-67EF-484C-A589-0A7B455F58E8</string>
			<key>PayloadType</key>
			<string>com.apple.ShareKitHelper</string>
			<key>PayloadUUID</key>
			<string>39EF4293-67EF-484C-A589-0A7B455F58E8</string>
			<key>PayloadVersion</key>
			<integer>1</integer>
			<key>SHKDeniedShareServices</key>
			<array>
				<string>com.apple.share.AirDrop</string>
				<string>com.apple.share.Messages</string>
				<string>com.apple.share.addtoaperture</string>
				<string>com.apple.share.Twitter</string>
				<string>com.apple.share.Facebook</string>
				<string>com.apple.share.LinkedIn.post</string>
				<string>com.apple.share.Video</string>
				<string>com.apple.share.SinaWeibo</string>
			</array>
		</dict>
	</array>
	<key>PayloadDisplayName</key>
	<string>Untitled</string>
	<key>PayloadIdentifier</key>
	<string>88F766B5-D4ED-4293-B2C7-1FD2F8B521C2</string>
	<key>PayloadType</key>
	<string>Configuration</string>
	<key>PayloadUUID</key>
	<string>88F766B5-D4ED-4293-B2C7-1FD2F8B521C2</string>
	<key>PayloadVersion</key>
	<integer>1</integer>
</dict>
</plist>

The Catch with Modern macOS

If you push this profile to a modern macOS machine, it does still work for legacy items like AirDrop.

The problem is that it completely fails to cover any of the new native share menu options built into modern versions of the OS. Newer collaboration and native apps-like Freeform or Journal-ignore the legacy com.apple.ShareKitHelper domain entirely. If you only deploy the legacy profile, these extensions remain completely open to your users.

The Modern Fix: Jamf Blueprints & NSExtension Management

To properly lock down the modern Share Menu ecosystem, we need to target Apple’s current configuration framework using the NSExtension Management (com.apple.NSExtension) payload.

In newer iterations of Jamf Pro, this management paradigm shifts away from standard profile checkboxes and into Jamf Blueprints.

Step 1: Add the Component to Your Blueprint

Create or edit a Blueprint targeting your Mac fleet and include the NSExtension Management component from the library.

Figure 3: Selecting NSExtension Management within Jamf Pro Blueprints.

Step 2: Configure Denied Extensions

Inside the payload configuration, you will utilize the Denied extensions (DeniedExtensions) array. This tells the operating system exactly which application extension bundles are strictly prohibited from running.

Figure 4: Populating specific extension bundle identifiers into the Denied extensions framework.

To achieve parity with NCSC requirements on modern OS versions, you can add explicit targets like:

  • AirDrop: com.apple.share.AirDrop.send
  • Add to Photos: com.apple.share.System.add-to-iphoto

How to Discover Other Sharing Bundle IDs

The NCSC guidelines provide an excellent compliance baseline, but your users likely have third-party apps or newer native features that add unapproved shortcuts to their context menus.

To audit exactly what extensions are registered on a live macOS device, run the following command in Terminal:

pluginkit -mAvvv

This outputs a comprehensive list of every registered plugin, its application path, and its exact bundle identifier. For instance, running this command reveals extensions such as:

  • com.apple.share.Mail.compose (Native Mail sharing)
  • com.apple.Notes.SharingExtension (Native Notes sharing)
  • com.apple.freeform.sharingextension (Freeform sharing)
  • com.apple.journal.JournalShareExtension (Journal sharing)

Simply copy the specific bundle identifier string (the text right before the version parentheses) and drop it directly into your Blueprint’s Denied extensions array to keep your fleet fully compliant and secure.

If you are working through Cyber Essentials compliance for your Apple fleet and need help implementing the right MDM policies, our team works with UK businesses through the full certification process.


Book a free Cyber Essentials readiness review

Jamf Pro vs Microsoft Intune for Apple Devices: An Honest Business Guide 2026

Jamf Pro vs Microsoft Intune for Apple Devices: An Honest Business Guide 2026

Every IT manager making an Apple MDM decision in 2026 hits the same question at some point: Jamf Pro or Microsoft Intune?
The question sounds straightforward. The answer is not because both platforms are genuinely good, both have real limitations and the right choice depends entirely on your specific environment, your existing tooling and where your fleet is heading over the next two years.
This post gives you the honest picture from a partner that implements both. nDuo is a Jamf Elite Partner and an Apple Premium Technical Partner, managing over 15,000 Apple devices for UK businesses including Revolut and Kroo. Not a feature checklist that ends with “both are great, you decide.” A direct, experience-based assessment of where each platform excels, where each one falls short and exactly which business profile fits each one best.
If you have already read our MDM comparison covering Jamf, Intune, Iru and FleetDM, this post goes deeper on the Jamf vs Intune question specifically.

The fundamental difference

Jamf is the industry standard for specialised, deep management of Apple-only environments: macOS, iOS and iPadOS. Microsoft Intune is a cross-platform endpoint management solution built around the Microsoft 365 ecosystem, managing Windows, macOS, iOS, Android and Linux from a single console.

That distinction matters more than any individual feature comparison. Jamf built its entire product around Apple. Every feature, every workflow, every integration reflects a decade of deep Apple platform expertise. Intune built its product around Windows and extended it to other platforms, including Mac – over time.

The Apple MDM decision used to follow a simple rule: Intune for Windows, Jamf for Macs. Three things have disrupted that in 2026. Microsoft has closed several of the gaps that made Intune a second-class citizen for Mac management. The vendor field has expanded. And the question of how much of your security and identity stack you want to consolidate into one vendor has become central to the decision.

Neither platform is wrong. Each is wrong for certain environments. Understanding which environment you are actually in is the only way to make the right call.

Where Jamf Pro wins

Apple-specific depth

Jamf Pro dominates for zero-touch deployments, patch management and application management, providing a solid framework for managing Macs that Intune cannot match for Apple-specific depth.

When a Mac arrives from Apple or an authorised reseller, Jamf’s zero-touch deployment workflow handles the entire setup automatically, device enrolment, configuration profile application, app installation and user account setup – before the employee touches the keyboard. The experience is polished, reliable and genuinely zero-touch in a way that Intune cannot consistently deliver.

Intune has a much longer check-in time, between 8 to 24 hours, and does not allow items deployed through Intune to be triggered through any sort of workflow. Jamf Pro has always been on the forefront of zero-touch provisioning, with built-in support for macOS Onboarding and compatibility with tools like Swift Dialog. Intune does not have a built-in zero-touch solution and its platform limitations make handling third-party solutions difficult.

For a business where new Macs need to arrive pre-configured, enrolled and compliant before the employee starts, which is the standard expectation for any well-run onboarding process, Jamf Pro is the more reliable choice.

Third-party app patching

This is one of the starkest practical differences between the two platforms and one that directly affects your Cyber Essentials compliance posture.

Jamf Pro provides App Installers, a secure and automated way to patch third-party applications. The Jamf App Catalog covers over 300 software with automated patching. Intune natively updates only a small number of Microsoft apps, anything else requires custom scripts, manual packaging or third-party add-ons.

In practice, this means a business running Intune for Mac management needs to either manually package and deploy every third-party application update like Chrome, Zoom, Slack, Adobe, and dozens of others or invest in a third-party tool to fill the gap.

That additional tooling adds cost, complexity and another dependency to manage. For a business that needs to meet the 14-day patching requirement under Cyber Essentials v3.3, third-party app patching is not optional. Jamf handles it natively. Intune requires a workaround.

Compliance reporting and framework support

For businesses working toward Cyber Essentials, ISO 27001 or CIS benchmark compliance, Jamf Pro provides dedicated compliance reporting that maps directly to those frameworks.

Jamf Pro delivers CIS benchmark enforcement, zero-touch deployment via Apple Business Manager and built-in self-service workflows. At scale, the efficiency these provide outweighs the higher upfront cost.

Intune provides compliance policies and conditional access integration, but the compliance reporting depth for Apple-specific frameworks is significantly shallower than Jamf’s. If your compliance requirements are serious, Jamf Pro gives you the evidence trail and the framework mapping out of the box. Intune requires more manual effort to achieve the same result.

Scripting and automation

Apple-specific capabilities such as enrolment customisation, advanced scripting and granular onboarding control are more limited in Intune.

Jamf Pro provides a full scripting environment for macOS. IT teams can write and deploy shell scripts across the fleet, build automated workflows triggered by device events and create extension attributes that pull custom inventory data from every Mac. This capability is what separates a basic MDM setup from a truly mature, automated Apple environment.

Intune’s scripting support for Mac is present but limited. Script size is constrained, triggering options are limited and the overall automation capability is significantly narrower than Jamf’s. For businesses with complex deployment workflows or automation requirements, this gap matters.

Where Microsoft Intune wins

Cross-platform management from a single console

This is Intune’s strongest argument and it is a genuinely compelling one for the right environment.

Intune is a multi-platform solution managing Windows PCs, Macs, iOS devices, Android devices and Linux endpoints from a unified console. For businesses already running Microsoft 365, it leverages existing licensing, integrates with security and identity layers and becomes part of a broader system rather than a standalone tool.

If your business runs 80% Windows and 20% Mac, managing both platforms through Intune means one console, one compliance policy framework, one reporting view and one set of admin skills. Adding Jamf Pro for Mac management means running two MDM platforms, two sets of policies and two admin consoles simultaneously. That complexity has a real operational cost.

Cost – especially for Microsoft 365 users

Many businesses are already paying for Microsoft licences that include Intune, which means there is often question if we they need to purchase additional tools.

Microsoft 365 Business Premium includes Intune at no additional cost. For a 50-person business already on Microsoft 365 Business Premium, the effective additional cost of using Intune for Mac management is zero. Adding Jamf Pro at the equivalent scale costs from £7-8 per device per month, adding £4,200 per year or more.

That cost difference is real and legitimate for businesses where Intune’s Mac management capabilities are sufficient for their requirements. The question is whether Intune’s capabilities are genuinely sufficient, not whether it is cheaper.

Identity and Conditional Access integration

Intune’s core value comes from how tightly it connects with Microsoft 365 and Microsoft Entra ID, where identity, access and device control are already unified. For teams already operating within this stack, Intune fits in naturally.

Conditional Access policies in Entra ID can enforce that only Intune-enrolled, compliant devices can access Microsoft 365 applications. When Intune confirms a Mac meets your compliance policy, patched, encrypted, screenlocked, etc. Entra ID allows access. When it does not, access is blocked. This device-based conditional access is tightly integrated within the Microsoft ecosystem in a way that requires more configuration to achieve with Jamf and Entra ID.

For businesses where Microsoft is the primary productivity and identity platform, this native integration is a meaningful advantage.

Android and non-Apple device support

If your fleet includes Android devices alongside Mac and Windows, Intune manages all three from the same console. Jamf manages only Apple platforms (lately added Android as of 2025). For businesses with genuinely mixed operating system environments including Android, Intune is the only platform in this comparison that covers the full scope.

Where Intune falls short for Apple

This is the honest section that Microsoft marketing tends to gloss over. Intune has improved meaningfully for Mac management over the last two years. It has not closed the gap with Jamf Pro for Apple-specific depth.

Third-party patching requires workarounds

As covered above, Intune natively patches only Microsoft applications on Mac. Intune has no native support for patching non-Microsoft third-party applications on Mac. Chrome, Slack, Zoom, Adobe and anything outside the Microsoft Store requires manual packaging, custom scripts or a third-party tools. This is a significant operational burden at scale and a compliance risk for businesses that need to evidence 14-day patching across the full application catalogue.

Zero-touch deployment is less reliable

Apple-specific capabilities such as enrolment customisation and granular onboarding control are more limited in Intune. Intune’s zero-touch deployment for Mac works — but it is less polished, less flexible and less reliably zero-touch than Jamf’s equivalent. IT teams frequently need to intervene during Intune Mac enrolments in a way that Jamf’s workflow makes unnecessary.

Check-in delays affect policy enforcement

Intune’s check-in time for Mac devices is between 8 and 24 hours. When you push a security policy update or an urgent software deployment, Mac devices in Intune may not receive it for up to 24 hours. Jamf Pro check-ins are ‘near’ real-time. For environments where security policy enforcement speed matters and under Cyber Essentials it does, this delay is a meaningful limitation.

Reporting depth for Apple environments

Intune needs to refine its reporting capabilities and match the depth of macOS management offered by competitors like Jamf Pro. Generating the compliance evidence an auditor needs for a Cyber Essentials Plus assessment or an ISO 27001 audit from Intune requires significantly more manual effort than pulling the equivalent report from Jamf Pro.

A direct comparison

Jamf ProMicrosoft Intune
Platform focusApple, AndroidWindows, Mac, iOS, Android, Linux
Zero-touch deployment for MacBest in classWorks but less reliable
Third-party app patching on Mac300+ titles nativelyRequires Patch My PC or custom scripts
Policy check-in speedNear real-time8 to 24 hours
Scripting and automationFull shell scriptingLimited
CIS benchmark supportBuilt-inManual evidence gathering
Microsoft 365 integrationVia Entra ID integrationNative
Conditional AccessVia Entra IDNative
Android managementYesYes
Cost for Microsoft 365 usersAdditional cost from £7/device/monthIncluded in M365 Business Premium
Implementation complexityHigh – needs specialistHigh – needs specialist
Best forApple-first or Apple-heavy fleetsMixed Windows and Mac, Microsoft-first

Who should choose Jamf Pro

  • Choose Jamf Pro when Apple management is a serious discipline in your business, not an afterthought.
  • Your fleet is primarily or entirely Apple, Macs, iPhones, iPads and you need the best possible management capability for those devices.
  • You need reliable zero-touch deployment where new Macs arrive fully configured without IT intervention.
  • You have third-party application patching requirements that you need to meet automatically without additional tooling.
  • You are working toward Cyber Essentials Plus, ISO 27001 or CIS benchmark compliance and need dedicated compliance reporting.
  • You have complex deployment workflows, scripting requirements or automation needs that exceed what Intune can deliver.
  • You run a regulated environment, fintech, legal, healthtech ect, where Apple device management is a compliance-critical function.
  • Your IT team has Apple expertise and wants a platform that reflects that specialisation rather than treating Mac as a secondary platform.

The honest caveat on Jamf Pro:

Jamf Pro’s pricing may not be the cheapest, but its comprehensive management tools and support offer valuable investment for businesses that need Apple depth. Implementation complexity is real. Getting the most out of Jamf Pro requires either an experienced in-house Apple admin or a specialist implementation partner. As one of only 14 Jamf Elite Partners in the UK, nDuo implements Jamf Pro for regulated Apple fleets, including a global fintech where zero-touch onboarding went from over an hour of IT time per device to 15 minutes. The right partner from day one determines whether Jamf becomes your strongest IT asset or your most expensive under performer. A poorly configured Jamf environment delivers far less value than the platform is capable of. The right partner from day one determines whether Jamf becomes your strongest IT asset or your most expensive under performer.

Who should choose Microsoft Intune

  • Choose Intune when consolidation and cost efficiency matter more than Apple-specific depth.
  • Your fleet is genuinely mixed – ~80% or more Windows devices alongside Macs and managing both from a single console reduces operational complexity meaningfully.
  • You already have Microsoft 365 Business Premium or an E3 or E5 licence and Intune is included at no additional cost.
  • Your Mac management requirements are straightforward, devices enrolled, basic security policies applied, OS updates managed without complex compliance frameworks or deep scripting needs.
  • You are already invested in the Microsoft identity and security ecosystem, Entra ID, Defender, Conditional Access, and want device management that integrates natively with those tools.
  • Your team is more comfortable with Microsoft tooling than Apple-specific platforms and the operational overhead of learning Jamf is not justified by your Apple fleet complexity..

The honest caveat on Intune for Mac:

Intune’s depth can make it harder to navigate and slower to set up for teams whose primary challenge is Apple management rather than Windows. The moment your Mac requirements grow beyond the basics, complex patching, compliance framework reporting, advanced scripting, reliable zero-touch deployment. Intune starts to show its limitations. At that point the question of adding Jamf Pro alongside Intune becomes a serious conversation rather than a theoretical one.

Can you run both?

Yes and some businesses do. Combining both platforms, using Intune to orchestrate compliance via Conditional Access while letting Jamf manage Macs at depth is a viable architecture for businesses with complex requirements.

The co-management approach works as follows: Jamf Pro manages the Apple fleet at depth: zero-touch deployment, app management, scripting, compliance reporting. Intune manages Windows devices natively. Entra ID provides the identity layer and Conditional Access policies for both. Devices enrolled in either MDM can be required to meet Intune compliance policies before accessing Microsoft 365 applications.

The Cyber Essentials lens

For UK businesses pursuing or maintaining Cyber Essentials certification, the choice between Jamf Pro and Intune has direct compliance implications.

Both platforms can satisfy the five Cyber Essentials controls when correctly configured. The difference is in the effort required to maintain and evidence that compliance.

Jamf Pro generates compliance reports that map directly to the Cyber Essentials control framework. Third-party app patching within the 14-day window is handled natively through the App Catalog. Policy enforcement is near real-time. The compliance evidence an assessor needs for Cyber Essentials or Cyber Essentials Plus is available from a single console.

Intune requires more manual effort to achieve the same result. Third-party app patching on Mac needs Patch My PC or equivalent. Policy check-in delays mean enforcement is less immediate. Compliance reporting for the CE framework requires manual evidence compilation rather than dedicated reports.

For businesses that take Cyber Essentials seriously, particularly those working toward Plus tier with independent technical verification, Jamf Pro reduces the compliance overhead significantly. For businesses with basic CE requirements on a primarily Windows fleet with some Macs, Intune is sufficient.

Pricing – what you actually pay

Jamf for Mac:
Jamf for Mac pricing cost £9.38 per device per month depending on fleet size, contract length and whether additional Jamf products are included. A 50-device Mac fleet typically costs ~£5,600 per year. Implementation and configuration adds a one-time cost depending on fleet complexity and whether you use a specialist partner or implement in-house.

Microsoft Intune:
Intune is included in Microsoft 365 Business Premium at £18.60 per user per month, Microsoft 365 E3 at £28.10 per user per month and Microsoft 365 E5 at £48.10 per user per month. Standalone Intune Plan 1 is available at approximately £6.20 per user per month. For businesses already on Microsoft 365 Business Premium, the effective additional cost for Mac management via Intune is zero, but add third-party patching at approximately £3 per device per month.

The verdict

The decision comes down to one question: is Apple management a first-class discipline in your business or a secondary consideration?

If Apple management is first-class, your fleet is primarily Mac, your compliance requirements are real, your team takes device security seriously then Jamf Pro is the right platform. The additional cost and implementation investment deliver capabilities that Intune cannot match for Apple environments.

If Apple management is secondary, your fleet is primarily Windows, you are already in the Microsoft ecosystem, your Mac requirements are basic then Intune is sufficient and the cost advantage is genuine.

The businesses that get this wrong are the ones that choose Intune for Mac management because it is included in their Microsoft licence, hit its limitations as their Apple fleet grows or their compliance requirements mature, and then face the cost and disruption of migrating to Jamf Pro two years later. Starting with the right platform for your trajectory is significantly cheaper than switching platforms mid-growth.

Whichever platform fits, implementation determines the outcome. nDuo is a Jamf Elite Partner and one of only 11 Apple Premium Technical Partners in the UK, and we deploy both Jamf Pro and Intune for Apple fleets so the recommendation is based on your environment, not our margin.

How nDuo helps

We implement and manage both Jamf Pro and Microsoft Intune for UK businesses running Apple and mixed device environments.

nDuo is a Jamf Elite Partner (one of only 14 in the UK), Microsoft Partner, and one of only 11 Apple Premium Technical Partners in the country. We have specialised in Apple device management since 2011 and currently manage over 15,000 Apple devices for UK businesses including Revolut and Kroo.

We hold these accreditations deliberately. It means we implement Jamf Pro at depth and Intune at depth, and the recommendation we give you reflects your environment rather than the one platform we happen to be certified in. If Intune is the right answer for your fleet, we will say so and then build it properly.

Where we typically get involved:

Platform selection. An Apple MDM Platform Review assesses your fleet, compliance requirements and existing Microsoft stack, and produces a written recommendation with costs. Typically two weeks.

Jamf implementation. Zero-touch deployment via Apple Business Manager, configuration profiles, app patching through the App Catalog, and compliance reporting mapped to Cyber Essentials, ISO 27001 and other frameworks.
This typically takes new-starter setup from over an hour of IT time per device to under 15 minutes. See how this worked for Revolut.

Intune implementation. Where Intune is the right call, we build it properly for Apple, configuration profiles, patching workflows, Conditional Access for Macs, and for the Windows estate alongside it, so one console covers the whole fleet rather than leaving the Macs half-managed.

Migration between platforms. Moving from Intune to Jamf, or consolidating onto one, without re-enrolling devices manually or losing compliance evidence mid-audit.

Across all of these, nDuo iQ – our own iOS app, listed on the Jamf Marketplace and App Store gives IT teams a single view across Jamf Pro and Intune from their phone: compliance status, FileVault and LAPS key retrieval, remote lock and wipe, patch reporting and PDF compliance reports.

Book a free consultation with our team to get a clear recommendation on the right MDM platform for your Apple fleet.