A Practical Guide to Mac Compliance with Hexnode and Intune

TL;DR. Mac compliance in 2026 means FileVault on with the recovery key escrowed to one place, the OS within 14 days of latest, screen lock at five minutes, password rules sane, Gatekeeper and the firewall on, and a configuration profile actually applied. Hexnode enforces all of that natively with a richer macOS profile catalogue. Intune covers the basics plus Conditional Access, but lags Apple’s release cadence. Pick by fleet shape, not vendor loyalty.

What does Mac compliance even mean in practice?

Strip the marketing off and Mac compliance is a short, honest list. Eight items, mostly.

FileVault on, with the personal recovery key escrowed to a known, retrievable location. The OS within fourteen days of the current Apple release: Sonoma or Sequoia in 2026, depending on hardware. Screen lock after five minutes idle, requiring the password on wake. A password policy that’s actually enforceable on macOS (length, not rotation theatre). No jailbroken or rooted Macs in the fleet. Rare on macOS but real. Apple Silicon vs Intel accounted for, because they behave differently under MDM. A configuration profile from your MDM applied and installed, not pending. App inventory readable, with no unsigned outliers, no suspect TCC bypasses, no remnants of a previous management agent.

That’s it. Compliance is binary per item, per device. Either FileVault is on or it isn’t. Either the device is on macOS 15.3 or it’s on 15.1 and overdue. Either the screen-lock profile is installed or it’s a “user setting” the user can switch off in System Settings.

The work is in proving it at scale, on every Mac, every day. That’s what an MDM is for.

What can Hexnode actually enforce on macOS?

Hexnode’s macOS feature set is broader than most people expect, and it tracks Apple’s release notes faster than Intune does. The compliance criteria you can name in a Hexnode policy include:

• FileVault status (on / off / encrypting / decrypting)
• macOS version threshold (greater than or equal to a named build)
• Screen-lock grace period
• Password policy (length, complexity, history, max failed attempts)
• Jailbreak / root detection
• Last-checked-in window
• Required app installed (positive list) and forbidden app installed (negative list)
• Supervised vs unsupervised state
• Apple Silicon vs Intel chip family

Each of those becomes a compliance criterion that flips the device in or out of compliance, which can in turn drive an action: notify, restrict, retire, wipe.

The profile types it ships are the named macOS configuration payloads, not generic key-value blobs:

• Restrictions: disabling iCloud sync, AirDrop, Handoff, Siri, screen-recording, USB mass storage where appropriate.
• Wi-Fi: pre-staging the corporate SSID with a certificate or PSK, so the user never sees the password.
• FileVault: turning encryption on at next logout, requiring the personal recovery key, escrowing it to Hexnode.
• Login Window: banner text, hidden user list, fast-user-switching off, auto-login disabled.
• Software Update: deferring major version upgrades by N days, scheduling installs, allowing or blocking beta seeds.
• Privacy Preferences Policy Control (PPPC): pre-approving Full Disk Access, Screen Recording, Accessibility, and System Extension entitlements for specific signed agents (Bitdefender, Crowdstrike, Zoom, the lot).

That last one is the difference between an MDM that “manages Macs” and one that runs them. PPPC is what stops Bitdefender’s endpoint sensor from sitting in System Settings with a yellow “needs permission” badge that nobody clicks. Hexnode ships the PPPC payload as a first-class profile type with the team identifier and code requirements pre-fillable.

What can Intune actually enforce on macOS?

Intune’s macOS coverage is real, but it’s narrower. The two tools you have are Compliance Policies and Configuration Profiles, both delivered via the standard macOS MDM channel, the same protocol Apple ships to every MDM vendor.

Compliance policy criteria on macOS:

• Minimum and maximum macOS version
• Password required, password complexity, password length
• System integrity (jailbreak detection)
• FileVault required
• Firewall enabled
• Gatekeeper enforced

Configuration profile types on macOS:

• Preference file (a .plist push, generic)
• Endpoint protection (FileVault settings, firewall)
• Device features (Login Window, AirPrint)
• Wi-Fi
• VPN
• Trusted certificates and SCEP
• Custom (raw .mobileconfig upload, when the GUI can’t express what you need)

That last one is where most Intune-on-Mac shops live. If you want to enforce, say, a specific Software Update deferral, or a PPPC profile for a security agent, the answer is often “build the .mobileconfig in iMazing or Apple Configurator and upload it as a Custom profile.” Functional. Not friendly.

The gaps versus Hexnode worth naming:

• No first-class PPPC builder in the Intune UI in 2026. Custom profile or third-party tool.
• Software Update controls trail Apple’s release feature flags by months.
• Application inventory exists, but the “compliance based on installed app” rule is thinner than Hexnode’s positive/negative app lists.
• Apple Silicon-specific behaviours (bootstrap token, volume ownership) are documented in Microsoft Learn but not surfaced as native dashboard signals.

What you do get, that Hexnode doesn’t natively do, is Conditional Access through Entra ID. Non-compliant Mac, no mailbox. That’s load-bearing for many shops.

Where each one outshines the other on Mac

The honest comparison, fleet-side.

Hexnode wins on macOS feature parity speed. When Apple ships a new MDM command in Sonoma or Sequoia, Hexnode tends to surface it as a UI option within weeks. Bootstrap Token escrow, Erase All Content and Settings, Declarative Device Management hints. They turn up in the Hexnode console without a custom-profile workaround.

Intune wins on Conditional Access. If your identity is in Entra ID and your mail is in Microsoft 365, the Intune compliance signal flowing into a Conditional Access policy is unbeatable. A Mac that drops out of compliance loses access to corporate Outlook on the web within minutes. Hexnode can do something similar via SAML claims and SCIM, but it’s not native.

Intune wins on bundled licensing for M365 shops. If you’re already on Business Premium or E3, you’ve paid for Intune. Adding Hexnode is a real second invoice.

Hexnode wins on mixed-OS console economy. One pane for Macs, iPhones, iPads, Androids, Chromebooks, and Windows. Intune does Windows beautifully and Apple competently, but ChromeOS isn’t on the menu.

Both are fine. Most South African mid-market shops we audit end up with Intune for Windows and Hexnode for the Apple estate. Two consoles, each doing what it’s best at.

The 8 baseline Mac compliance criteria you should always set

Whether you land on Hexnode, Intune, or both, the eight-item baseline is the same. These are the criteria worth fighting for at the policy-design table.

1. FileVault on with key escrow. Encryption mandatory at next logout. Personal recovery key, escrowed to the MDM, retrievable by support staff with the right role. Institutional recovery key only if your team genuinely manages the keychain. Most don’t.
2. OS up to date within 14 days. Minimum version threshold tied to the latest Apple security release. Fourteen days is the industry-standard service-level for “patched” in cyber-insurance questionnaires.
3. Screen lock at 5 minutes idle. Grace period zero. Password required immediately on wake. The Login Window profile is what enforces this; a “user preference” set in System Settings does not survive a coffee.
4. Password complexity. Eight-character minimum, mix of letter / number, no rotation requirement (NIST has been clear on this since 2017). Max failed attempts at ten, with a lockout, not a wipe.
5. Jailbreak detection. Rare on macOS but real. The MDM compliance check flags devices with disabled SIP (System Integrity Protection) or unauthorised kernel extensions.
6. Signed-only apps. Gatekeeper set to “App Store and identified developers.” Block unsigned apps from launching. Combine with an allow-list for the line-of-business tools that aren’t notarised.
7. Gatekeeper enforced. Same payload, but explicitly: prevent the user from running spctl --master-disable to turn it off. The MDM profile is what makes this stick.
8. Firewall on. macOS application firewall enabled, with stealth mode optional. The MDM profile is again the thing that locks the toggle.

That eight-item list is what we measure against on every Mac compliance assessment we run. Devices that pass all eight are a known quantity. Devices that pass six are a question. Devices that pass three are not in the fleet. They’re a side project pretending to be a fleet.

How to enrol Macs cleanly via ABM/DEP

The cleanest enrolment path for corporate-owned Macs is through Apple Business Manager (ABM, formerly DEP). The pre-stage matters, so it’s worth spelling out.

Enrol the organisation in ABM. Apple verifies the company through a D-U-N-S number and a verification call. Link your reseller’s Apple Customer Number to your ABM tenant. When the reseller ships you a Mac, its serial number lands in your ABM inventory automatically. You assign that serial to your MDM (Hexnode or Intune) inside ABM, and from then on, every fresh-out-the-box boot on that Mac will phone Apple, see the assignment, download the configuration profile, and enrol into your MDM before the user even reaches the desktop.

The user-affinity step is the one most rollouts get wrong. ABM enrolment can be device-only (the Mac is managed but no user is associated) or user-affined (the Mac is enrolled against the user’s Entra ID or directory account). User affinity unlocks per-user app deployment, mail profile push, and Conditional Access. Without it, you have a managed device with no identity context, and Conditional Access can’t see the device at sign-in.

For Macs already in the wild that never went through ABM, your options are narrower. Apple Configurator 2 on a separate Mac can re-enrol an existing device into ABM, but it requires a wipe and restore. There is no in-place “promote this Mac to ABM” path. Plan the wipe-and-restore window into your project, or accept that pre-ABM Macs will be user-enrolled rather than device-enrolled and live with the reduced control.

What about BYOD Macs?

The user-enrolment vs device-enrolment distinction is sharper on iPhones than on Macs, but it does exist. On macOS, the closest equivalent is profile-based enrolment (the user installs a configuration profile manually) versus automated device enrolment through ABM.

A BYOD Mac coming in via profile-based enrolment can have:

• A Wi-Fi profile pushed
• A mail account profile pushed (Exchange, IMAP)
• A VPN profile pushed
• App protection for managed apps inside an enrolled context

What it cannot have:

• FileVault enforcement (the user has to opt in)
• Mandatory OS update deferrals
• Activation Lock bypass
• Erase All Content and Settings as a remote command
• Most of the aggressive Restrictions payloads

In short, BYOD Macs become a “we can configure but not enforce” tier. That’s fine for some staff (contractors, occasional users, executives who refuse a corporate device) but write the policy honestly. Don’t claim full compliance on a personally-owned Mac. Tell the auditor it’s a managed-app tier and move on.

The cleaner BYOD pattern in 2026 is to skip Mac BYOD entirely and issue a corporate Mac with ABM enrolment. The cost of the hardware is lower than the cost of three audit findings.

Common Mac compliance pitfalls

The recurring failure modes we clean up.

Apple Silicon vs Intel quirks. Apple Silicon Macs need a bootstrap token escrowed to the MDM for some operations (specifically, to trigger system extensions and FileVault enable on first logout without user interaction). Intel Macs don’t. If your MDM never received the bootstrap token (usually because the Mac was enrolled before the token was generated), half your management commands will silently fail. Hexnode and Intune both surface bootstrap-token status; check it on every Apple Silicon Mac.

FileVault recovery key in the wrong escrow. Three places the key can live: the MDM (Hexnode or Intune), the user’s iCloud account, or your endpoint security tool’s console (Bitdefender FDE, for example, can also escrow FileVault keys; see our FDE comparison). Pick one. Two is a configuration drift waiting to happen. You’ll have devices where the key in MDM is stale and the working key sits in Bitdefender’s console, or vice versa. The audit question “where is the key for serial X” must have one answer.

PPPC missing for the security agent. This is the single most common failure on a freshly-MDM’d Mac. The security agent (Bitdefender, Crowdstrike, SentinelOne, Defender for Endpoint) installs, but its Full Disk Access, Screen Recording, or System Extension entitlements aren’t pre-approved by a PPPC profile. The user gets a bunch of System Settings prompts, ignores them, and the agent runs in a degraded mode for months. Push the PPPC profile before the agent installer, with the correct team identifier and code requirements for the version you’re deploying. In Hexnode this is a named profile type. In Intune it’s a custom .mobileconfig you build separately.

Supervised vs unsupervised enrolment. Macs enrolled via ABM are automatically supervised. Macs enrolled via the user-installed profile method are not. Several powerful MDM commands (notably Erase All Content and Settings, and certain Restrictions) only work on supervised Macs. If your fleet is half-supervised and half-not, your remote-wipe story has gaps. Inventory by supervised state and plan a re-enrolment for the unsupervised tail.

A bonus pitfall worth flagging: the Software Update profile that blocks updates indefinitely. Some admins push a 90-day deferral and forget about it. Three months later, devices are stuck on a vulnerable build because the deferral never expired in the user’s mind, even though Apple shipped the patch. Set the deferral, set a calendar reminder to review it, and tie it to your compliance threshold (no more than 14 days behind, even with a deferral active).

Where this sits in the OSH stack

Mac compliance is a slice of the broader MDM coverage, which covers both Hexnode and Intune in depth. The full-disk-encryption story for Macs sits adjacent to the Bitdefender vs Intune FDE comparison, because the recovery-key-escrow question is shared. The compliance angle ties into cyber insurance underwriting expectations. Underwriters in 2026 want evidence that the Mac fleet is centrally managed and encryption is enforced, not just installed.

For the broader stack of professional services around MDM rollouts, see our services hub.

The CTA

If you have more than ten Macs and you’re not certain how many of them are FileVault-on with a retrievable key, that’s the prompt.

We run a 60-minute Mac compliance assessment that delivers three things in writing:

1. Current FDE coverage. How many Macs are encrypted, where the recovery keys actually live, and which devices are in escrow drift.
2. Baseline gap report. Score against the eight-item baseline above, per device, with the specific profile or policy missing for each gap.
3. Recommended Hexnode-vs-Intune split. Whether to consolidate on one MDM, run both for different roles, or stay where you are. Reasoning tied to your M365 SKUs, fleet size, and IT team capacity.

No pitch in the meeting. Written reasoning afterwards. Book the assessment and we’ll start with a fleet inventory call.