How to Manage FileVault With Hexnode

TL;DR. Hexnode does not encrypt your Mac. FileVault does. Hexnode’s job is to push the configuration profile that turns FileVault on, capture the personal recovery key, and escrow it back to the portal so an admin can retrieve it later. Get the Bootstrap Token right on Apple Silicon, pre-stage via Apple Business Manager where you can, and rotate keys after every disclosure. The rest is policy field hygiene.

What does Hexnode FileVault management actually do?

It manages native FileVault. Hexnode does not write its own crypto, does not run a kernel extension, does not touch the data path. What ships from Hexnode to the Mac is a configuration profile (com.apple.MCX.FileVault2) and a redirection profile (com.apple.security.FDERecoveryKeyEscrow). Apple’s fdesetup does the actual work on the device. Hexnode is the policy engine and the key vault sitting on top.

Same architecture as Jamf, Kandji, Mosyle, and Intune. Apple has made it clear: one supported way to manage FileVault from an MDM, and that is the configuration-profile route. Anything bypassing it breaks the moment macOS bumps a minor version.

Why it matters: when something goes wrong with FileVault enablement, the failure is almost never inside Hexnode. It is in the macOS layer. The Bootstrap Token did not escrow. The user does not have Volume Ownership. The profile arrived after Setup Assistant closed. Hexnode reports the symptom. The fix sits in the OS.

Setting up the FileVault profile in Hexnode

The path is Policies > New Policy > macOS > Security > FileVault. Five field clusters matter.

Encryption status. Set to Enable to trigger encryption at enrolment. Set to Disable for edge cases (lab Macs, classroom kiosks). The default is unset, which does nothing. Plenty of policies sit unset in tenants we inherit, admins surprised that nothing is encrypting.

Recovery key type. Two choices, and the choice you make is load-bearing.

• Personal recovery key (PRK): a unique 24-character key generated on the device when FileVault turns on. Escrowed back to Hexnode. Each Mac has its own.
• Institutional recovery key (IRK): a single keypair you generate ahead of time, the public half pushed to every Mac, the private half held by the organisation. Same key opens the whole fleet.

PRK is what you want for almost every modern deployment. IRK exists for legacy reasons and creates a bigger blast radius if the private key ever leaks. Hexnode supports both. Pick PRK unless you have a written reason not to.

Escrow location. Tick Escrow personal recovery key to send the PRK back to the Hexnode portal. If you forget this, FileVault still turns on, the user still gets prompted, but the key never leaves the Mac. When the user forgets their password six months later, you have nothing. We have seen this. More than once.

Deferral options. Defer enablement at logout and Defer enablement at login control when the FileVault prompt appears. Maximum bypass attempts sets how many times a user can dismiss the prompt before it becomes blocking. Use a small number (3 to 5). Too high and users avoid encryption forever. Zero forces encryption on first login: fine for kiosks, rough on humans.

Show recovery key to user. Off, generally. The portal has the key. The user does not need to copy it down on a sticky note.

Save the policy, target the right device group, push.

How does the recovery key actually flow?

Six steps, in order.

1. The user signs in to a Mac that has the FileVault profile applied.
2. macOS shows the FileVault enablement prompt at the next login or logout (depending on deferral settings).
3. The user authenticates. macOS generates the personal recovery key locally.
4. macOS encrypts the recovery key with the public key Hexnode placed in the escrow profile.
5. The encrypted key is sent over MDM check-in to the Hexnode portal.
6. Hexnode decrypts it with the private half of the keypair (held server-side, not visible to admins) and stores the plaintext key against the device record.

To retrieve a key as an admin: Devices > select device > Actions > Get FileVault Recovery Key. Hexnode logs who pulled it and when. That audit trail matters when an auditor asks who has touched the key store.

The thing to internalise: the key only escrows when the device is online and able to check in after FileVault turns on. If the user enables FileVault on an offline Mac and never brings it back on the corporate network, the key sits on the device and Hexnode never sees it. More on this in pitfalls.

Apple Silicon vs Intel: what’s different?

The architectures look identical from the user side. The MDM side is not. Three differences matter.

Volume Ownership. Apple Silicon introduced the concept of Volume Owners, the small set of users who hold a Secure Token capable of changing system state. Only a Volume Owner can enable FileVault. Only a Volume Owner can install macOS updates. The first user created during Setup Assistant is automatically a Volume Owner. Users created later need to be promoted, and that promotion requires either an existing Volume Owner running sysadminctl or the MDM holding a Bootstrap Token.

Bootstrap Token. This is the magic credential that lets the MDM grant Secure Token (and therefore Volume Ownership) to new users without any human in the loop. On Apple Silicon, no Bootstrap Token escrowed to Hexnode = FileVault enable will fail for any user who was not part of the Setup Assistant flow. We see this constantly on devices imaged by hand.

To check: on the Mac, run profiles status -type bootstraptoken. You want to see “Bootstrap Token escrowed to server: YES”. In Hexnode, the device record under Inventory > select device > Security shows Bootstrap Token status. If it says “Not escrowed”, FileVault for non-original users is going to fight you.

Activation Lock and Erase All Content and Settings (EACS). Apple Silicon Macs support Activation Lock when supervised through Apple Business Manager. They also support EACS, which lets the MDM remotely wipe a Mac back to factory state without losing the Secure Enclave’s tie to ABM. Combine these and a stolen Mac is genuinely useless to the thief: Activation Lock holds, EACS wipes the disk, and FileVault means the data was never readable to begin with. On Intel, EACS does not exist. You have a Recovery Mode reinstall and that is it.

T2 Intel Macs. T2 Macs (2018 to 2020) sit in an awkward middle ground. Secure Enclave, Bootstrap Token support, but the FileVault flow is closer to pre-Apple Silicon Intel than to Apple Silicon proper. Hexnode’s standard FileVault profile still works on them, but Volume Ownership semantics differ. Worth knowing for older fleet members.

Enabling FileVault on existing Macs

The cleanest case is a Mac that has been with the user for two years, never encrypted, and now needs to be brought into compliance. Push the FileVault policy to that device’s group and Hexnode does the right thing: macOS shows the prompt at the next logout or login (whichever you set), the user enters their password, macOS encrypts in the background while they keep working, and the recovery key escrows back when encryption finishes.

What not to do: push a blocking policy that demands enablement immediately. Encrypting a 1TB disk takes hours. Wedge the user into “encrypt now or get out” at 09:00 on Monday and you have made yourself the help desk. Use deferral. Set bypass attempts to 3. Let the user choose lunch as their encryption window.

One sharp edge for older Macs: if the user account is not a Volume Owner on Apple Silicon, the prompt will appear, the user will type their password, and the operation will silently fail. macOS does not tell the user why. Hexnode logs “FileVault enable failed” with no further detail. Check the Bootstrap Token status. That is almost always the answer.

Pre-staging FileVault on new Macs via ABM/DEP

This is the cleanest setup and the one we push every client toward. The flow:

1. Mac ships from Apple or your reseller registered to your Apple Business Manager organisation.
2. ABM auto-assigns the device to your Hexnode tenant via the DEP integration.
3. User unboxes, picks Wi-Fi, signs in to Setup Assistant.
4. Hexnode’s enrolment profile lands in the first 30 seconds.
5. The FileVault profile applies in the same wave.
6. macOS turns FileVault on as part of Setup Assistant itself, before the user even hits the desktop.
7. The recovery key escrows back to Hexnode the moment the device finishes setup and checks in.

No deferral, no prompt, no help desk ticket. The user never knows FileVault was turned on because there was nothing to interact with. Volume Ownership and Bootstrap Token both happen automatically because the original Setup Assistant user is the first Volume Owner, and the MDM gets the Bootstrap Token escrowed as part of the same flow.

If you are not on ABM yet, this is the single biggest reason to enrol. Manual provisioning is where 80% of FileVault failures originate.

Recovery key rotation

A personal recovery key disclosed to anyone outside the portal is now compromised. Disclosed when the help desk read it out over the phone to recover a forgotten password. Disclosed when an admin downloaded it to a CSV and emailed it. Disclosed when you fired the IT contractor who had Hexnode portal access.

To force rotation in Hexnode: Devices > select device > Actions > Rotate FileVault Recovery Key. Hexnode pushes the rotation command, macOS generates a new PRK, encrypts it, and escrows it back. The old key is invalidated. The user does not see anything; their password still works.

When to rotate:

• Immediately after every disclosure to a human outside the portal.
• After any IT staff departure where that staff member had key-retrieval rights.
• Routinely, on a schedule (we usually configure 180 days for regulated clients, none for others).
• Always, after a key has been used to open a recovered or returned device.

Hexnode does not yet support tenant-wide scheduled rotation in the way Intune does. It is per-device or via a saved action group. If you have a policy of routine rotation, build the saved action and run it on a calendar.

Common pitfalls

Five failure modes, in rough order of how often we see them.

No Bootstrap Token, FileVault enable fails on Apple Silicon. The user’s account does not have Volume Ownership. macOS refuses to turn FileVault on. The Hexnode log shows the attempt and the failure with no useful detail. Fix: get the Bootstrap Token escrowed. On a Mac with one existing Volume Owner who can authenticate, run profiles install -type bootstraptoken from Terminal and have them authenticate. Better fix: re-enrol via ABM where Bootstrap Token escrow is automatic.

User dismissed the prompt and now needs admin intervention. Bypass attempts hit zero, the user kept clicking Later, and now the prompt is blocking but the user cannot remember which password macOS will accept. Fix: an admin with a Volume Owner local account on that Mac can run sudo fdesetup enable -user <username> to force enablement. If no such admin account exists, you are in a remote-management dance that ends in a wipe-and-restore. This is the case for every standalone build that bypassed ABM.

Recovery key did not escrow because the device was never online. FileVault turned on. The user is happy. The key never reached Hexnode because the Mac was offline at the moment of escrow and never checked back in. Six weeks later the user forgets their password. The portal shows “No recovery key available”. Fix going forward: monitor the FileVault inventory report in Hexnode. Any device with FileVault on but no key escrowed is a flag. Investigate before a real incident lands on your desk.

Profile installed after Setup Assistant closed. On a manual enrolment, Hexnode’s enrolment profile arrives, but the FileVault profile is in a separate wave that lands two minutes later. By then the user has already finished Setup Assistant and is looking at the desktop. FileVault enablement now requires logout or login, deferral kicks in, and you have lost the cleanest moment to encrypt. Fix: combine the FileVault policy into your default macOS enrolment policy group so it applies in the first wave, not the second.

FileVault is on, but the key in Hexnode does not open the disk. Rare and infuriating. Almost always caused by a manual fdesetup run on the device that rotated the key locally without telling the MDM. The MDM still holds the old key, which is now invalid. Fix: rotate the key from Hexnode, which forces a fresh escrow. Train local IT not to run fdesetup directly on managed Macs; that is what the MDM is for.

Where this fits in the bigger picture

FileVault is one piece of Mac compliance. Encryption alone is not compliance. You also need OS update enforcement, screen lock, Gatekeeper, and a configuration profile that holds together under audit. FileVault is the load-bearing piece, but it is not the whole load.

The Windows equivalent is BitLocker. We have a sister piece on how to manage BitLocker with Hexnode that walks through the equivalent flow on Windows, including the recovery key escrow path to Hexnode and the Conditional Access angle. If you are running mixed fleets, read both.

The bigger architectural question is which tool should own full disk encryption when you have Bitdefender GravityZone in the stack as well. The trade-offs sit in FDE: Bitdefender vs Intune. Short version: pick one place for keys, never two.

For the broader context, see our MDM page and the Hexnode page. For everything else OSH does around endpoint, identity, and email, the services hub is the entry point.

Get a managed FileVault audit

If you are running Hexnode on Macs and you are not 100% sure where every recovery key is, we will run a managed FileVault audit. The deliverable:

• Current FileVault coverage across the fleet, by device, by user, by Mac model.
• Recovery-key escrow audit: which devices have a key in Hexnode, which have FileVault on but no key, which have neither.
• Apple Silicon Bootstrap Token check on every device: escrowed, not escrowed, or unknown.
• A short remediation list ranked by blast radius.

One engineer, one Hexnode tenant, one report. Book a session through the MDM work-with-us page or message us directly.