FileVault and the Break-Glass Account on Apple Silicon in Intune

Turning FileVault on is the easy half. The half that keeps you employed is that the recovery key actually reaches your console, and that the account you plan to recover with can genuinely unlock a rebooted machine. On Apple silicon under Intune both have specific traps, and one of them, a password setting sitting in a policy that has nothing to do with encryption, will quietly leave you holding an encrypted Mac whose pre-boot screen rejects the password you know is correct.

This is the wart-and-all version. It includes the day I thought I had destroyed a machine's recovery key, the command that proved I had not, and the "fix" I very nearly ran that would have turned a display glitch into a real incident. For the cross-platform grounding on FileVault, escrow, SecureToken and deferred enablement, the companion guide on enforcing FileVault and escrowing the recovery key covers the concepts in both Jamf and Intune. This one assumes those and goes after the Intune-on-Apple-silicon specifics.

Why By-Policy Enablement Is the Whole Game

Apple silicon Macs are already encrypted at the hardware level. FileVault is what makes that encryption user-aware and, crucially, produces a personal recovery key that can be escrowed. Everything in this guide reduces to one rule:

That sounds obvious written down. It is much less obvious at 9am when a Setup Assistant pane offers a user a FileVault prompt and they, reasonably, say yes.

Who Holds the Key, and Why It Matters

Three mechanisms decide everything that follows, and they are worth thirty seconds each.

The SecureToken is what makes an account able to unlock the disk. On Apple silicon, the first account to log in interactively gets one. Accounts created later do not automatically, unless something grants it.

The bootstrap token is that something. Escrowed to your MDM at enrolment, it can grant a SecureToken to accounts that log in later, without a human typing an existing token holder's password. This is why enrolment matters to encryption: if the bootstrap token never escrowed, later accounts are on their own.

The personal recovery key is the disk's break-glass. It is generated when FileVault enables, and, if FileVault was enabled by policy, it gets escrowed to Intune. Note the direction of travel, because it explains a lag people misread as failure: escrow is a pull, not a push. The key sits on the machine until the MDM asks for it on a check-in. So a freshly encrypted Mac showing no key in the console for a while is normal, not broken. Check again after a check-in before you panic.

If you want the key sooner, force the check-in that triggers the pull rather than waiting on the agent's own cadence:

# Trigger the check-in that makes the MDM ask for the key
sudo killall IntuneMdmAgent
sudo profiles renew -type device

Verify all three on a real machine rather than trusting a diagram:

# Is the bootstrap token escrowed? (this is what grants tokens to later accounts)
sudo profiles status -type bootstraptoken

# Does this account hold a SecureToken?
sysadminctl -secureTokenStatus <account>

# Who can actually unlock the disk at pre-boot?
sudo fdesetup list

# Is FileVault on, and does a personal recovery key exist?
fdesetup status
sudo fdesetup haspersonalrecoverykey

A note on sudo: several of these return empty or partial output without it, which reads exactly like "no token" or "no key" and will send you chasing a problem you do not have. If a FileVault or profile query comes back suspiciously blank, run it again with sudo before drawing a conclusion.

The Template Trap: the Policy Type Decides Whether It Works

This is the root cause of my entire FileVault saga, and it is invisible from the console until you know to look for it.

There are two ways to build a FileVault policy in Intune: the older template profile type, and the Settings Catalog. They look interchangeable. They are not. The template type cannot expose Force Enable In Setup Assistant at all. The setting does not exist there. So if you build the template version and go looking for the setting that makes encryption happen silently during Setup Assistant, you will not find it, and you may reasonably conclude Intune cannot do it. Intune can. Your profile type cannot.

I built the template one first, spent real time hunting for a setting that was never going to be there, and eventually deleted it and rebuilt as Settings Catalog. If you take one structural thing from this guide: build FileVault as a Settings Catalog policy.

Building the FileVault Policy

1. Go to Devices → Configuration → Create → New Policy. Platform macOS, profile type Settings catalog. Create.
2. Name it something you will recognise in a list of thirty policies at 5pm.
3. Add settings, search FileVault, and add the Full Disk Encryption / FileVault settings.
4. Enable = On. The headline setting.
5. Force Enable In Setup Assistant = True. This is the one only the Settings Catalog gives you, and the reason you are here. It makes encryption happen during Setup Assistant, before anyone logs in.
6. Defer = Enabled. Keep it. See the next section, this is not vestigial.
7. Show Recovery Key = Disabled. You are escrowing the key, not showing it to the user. Displaying it invites screenshots, photographs and Post-it notes, which is precisely the outcome escrow exists to prevent.
8. Escrow → Location = a human sentence. This text can surface to the user on the recovery screen when they need the key, so write it for them, not for you. Name who to contact and say the key is held securely by IT.
9. Assignment: All devices, with your enrolment-profile-name filter as an Include. Not a dynamic group. This is not a preference, and the next-but-one section explains why in detail.
10. Create.

Once it has had a check-in, confirm the profile actually reached the machine rather than trusting the console's "Succeeded":

# Did the FileVault profile land on the device?
sudo profiles list | grep -i -A2 filevault

# Force a check-in if it has not (escrow and policy both ride on this)
sudo killall IntuneMdmAgent
sudo profiles renew -type device

Prerequisites that live outside this policy but decide whether it works: the primary account must be an admin (it is the SecureToken holder, and force-enable needs an admin SecureToken user or the FileVault step never happens), and Await final configuration must be Yes on the enrolment policy so the device holds at Setup Assistant long enough for the policy to land. Both are set in the enrolment guide. Get them wrong and this policy is fine and still does nothing.

Defer Is the Safety Net, Not a Leftover

You will read advice, and you may reason yourself into it independently, that Defer and Force Enable conflict, and that removing Defer will make forcing work. Do not do it.

They are two separate enablement methods, not two settings fighting over one. When Force Enable fires, macOS effectively ignores the deferral keys, they simply do not come into play. When Force Enable cannot fire, and there are several ordinary reasons it might not, Defer catches the device and enables FileVault at next login instead. That is the whole point.

There is also a documentation ghost worth knowing about: guidance circulated saying Defer was required alongside Force Enable. That traced back to a console bug in a specific Intune release which has since been fixed. So Defer is not mandatory, it is simply sensible, and the reasoning above stands on its own.

Silent Enablement Is a Targeting Problem

On my first correct rebuild, with the Settings Catalog policy and Force Enable set to True, encryption still did not happen during Setup Assistant. The machine came up with FileVault off and deferred enablement active. Everything in the policy was right.

The policy was assigned to the dynamic group. Follow the chain:

1. FileVault policy assigned to the dynamic group. Sensible-looking.
2. A no-affinity Mac joins that group only after it enrols, because before that it is not an object that can match a membership rule.
3. So during Setup Assistant the FileVault policy is not on the device.
4. Force Enable has nothing to fire from.
5. Defer catches it, FileVault enables at next login instead, and everything looks vaguely broken but is in fact working exactly as designed.

The setting was never the problem. The group-evaluation lag was. The fix is to assign FileVault to All devices with a filter on the enrolment profile name:

// Device filter: Macs that came in via your ADE enrolment policy
// A filter evaluates at check-in without needing group membership,
// so the policy is present DURING Setup Assistant and Force Enable can fire.
(device.enrollmentProfileName -eq "<your enrolment policy name>")

Two bonuses. Personal devices never carry a corporate enrolment profile, so they never match, so they are excluded automatically with no separate exclusion rule. And whether Force fires or Defer catches it, the key still escrows correctly, because FileVault was enabled by policy either way. That is the only thing that truly matters. Silent-during-setup is the nice-to-have; policy ownership of the key is the requirement.

One FileVault Policy, and Rotation That Lies

Two smaller things that cost real time.

Have exactly one assigned FileVault policy. If you have been iterating, you may have an old template-type policy and something inherited from a previous year still assigned alongside your new one. Multiple FileVault policies conflict, and the resulting errors point everywhere except at the actual cause. Go to Devices → Configuration, filter to macOS, and unassign every FileVault policy except the one you meant to keep. Do this before you debug anything else, because a conflict will happily masquerade as any of the other problems in this guide.

The device will tell you if you have more than one, which is faster than auditing the console:

# More than one FileVault-ish profile here means you have a conflict to resolve
sudo profiles list | grep -i -E "filevault|diskencryption|fdesetup"

Recovery key rotation does not do what the payload implies. With Force Enable In Setup Assistant, macOS ignores the payload's rotation setting on the force path. The reliable mechanism is Intune-side rotation, the console action or automation, not the profile key. If you want rotation, six months is a sensible interval; a recovery key is break-glass, and monthly rotation is churn for its own sake. Get enable-and-escrow proven on a clean build first, then add rotation, not the other way round.

The Manual-Enable Disaster, in Full

This is the day I would like back, and the most useful thing in this guide.

What I saw. The FileVault recovery key vanished from the Intune console. The ability to view the managed admin password went with it. The FileVault Settings Catalog policy showed Error -2016341106 against the Defer, Enable and Show Recovery Key settings, while Location and Recovery Key Rotation reported success, which is a genuinely confusing mix. Rotate FileVault recovery key was greyed out. The device record said, flatly, No FileVault Recovery Key found for this device.

I checked the obvious explanations and they were all dead ends. The device was Corporate, so it was not the ownership rule that stops admins viewing keys on Personal devices. There was a single device record, so it was not a duplicate object holding the escrowed items on the older record. It genuinely looked like the key had evaporated.

Triage it in this order, because two of the three explanations are innocent and quick to rule out:

# 1. Is the data actually safe? true = yes. Do this FIRST, it changes everything after.
sudo fdesetup haspersonalrecoverykey

# 2. Is FileVault even on, and how did it get that way?
fdesetup status

# 3. In the console: is the device Corporate? (Personal = admins cannot view keys, by design)
# 4. In the console: is there ONE device record, or two? (a duplicate holds the key on the old object)

Both console checks came back innocent for me: Corporate, single record. That is what pointed at the real cause.

What was actually happening. FileVault had been enabled manually, at the Setup Assistant prompt. That created a recovery key Intune did not generate. When the Intune policy then tried to enable and manage FileVault, it found a disk already encrypted with a key it had no relationship to. The enablement settings errored, because there was nothing for them to do, and Intune had no managed key to display, because it had never had one. Every symptom followed from that single fact.

The command that stopped the panic. Before doing anything drastic, I ran this, and I would run it first every time now:

# THE reassurance command. true = a personal recovery key exists = the disk is recoverable.
sudo fdesetup haspersonalrecoverykey

It returned true. The key existed. The disk was recoverable. The data was safe. What I had was a managed-relationship and display problem, not key loss, and those are very different emergencies. Knowing which one you are in changes what you do next, which brings me to the part that matters most.

The actual fixes, in order of preference. If the machine is a clean build you are about to do anyway, do that: policy enables FileVault from the start with Force Enable, Intune creates and escrows the key itself, no mismatch ever exists. If the machine is real and in service, and you cannot wipe it, use Escrow Buddy, which assumes management of the existing encryption and escrows a fresh key at next login. It is also the answer for every already-encrypted machine you migrate in from another platform, which is most of a real fleet.

The lesson, stated plainly so nobody has to have my day: never let FileVault be enabled manually on a Mac you want Intune to manage encryption on. Hide the FileVault pane in the enrolment policy so the prompt never appears. Enforce it by policy from the start, or use Escrow Buddy to adopt an already-encrypted disk. A manually-enabled disk leaves Intune with a key it cannot see and a policy that errors, and no amount of clicking will reconcile them.

The Break-Glass Account and the Pre-Boot Truth

A break-glass admin is the account you fall back on when a user is locked out and the machine has rebooted. To be useful on an encrypted Mac it must unlock the disk at the pre-boot screen, which means holding a SecureToken and appearing on the FileVault unlock list.

Here is the truth that no configuration will change, and that quietly contradicts a very common specification:

The workable version: keep it unlock-capable and hide it from the ordinary login window and System Settings, so day to day nobody sees it, and accept that it appears at pre-boot only. That is the sensible trade, because an account that cannot unlock a rebooted machine is not a break-glass account, it is just an admin account.

# Hide the account from the ordinary login window (it will STILL show at pre-boot)
sudo dscl . create /Users/<account> IsHidden 1

# Confirm
dscl . read /Users/<account> IsHidden

The bit where the documentation and my machine disagreed

Worth being honest about, because you may hit it and conclude one of us is lying.

Microsoft's documented position is that the Intune-managed local admin account is not intended to receive a SecureToken, and that the escrowed personal recovery key is the canonical FileVault break-glass: the key unlocks the disk, and the admin then logs in normally once it is open. That is a clean model and it is the one I would design to.

On my build, however, I verified on the device that both the primary account and the managed admin account held a SecureToken, were on the FileVault unlock list, and were volume owners. The managed admin could unlock at pre-boot with no manual step, because the bootstrap token, escrowed automatically at enrolment, granted it a token at first login. That was a genuine improvement on the previous platform, where the same capability needed a manual per-machine step.

I am not going to resolve that tension by picking whichever suits the narrative. Both things are true: the documented intent is one thing, and what the bootstrap token actually did on my hardware was another. So verify on your own machine rather than assuming either way, and design so that you are safe if the answer is the conservative one:

# Does your managed admin actually hold a token, on YOUR build?
sysadminctl -secureTokenStatus <admin-account>

# And can it actually unlock? (the list is the truth, the token is the mechanism)
sudo fdesetup list

Then reboot and try it, because the unlock screen is the only test that counts. And regardless of the answer: treat the escrowed recovery key as your real safety net. If the admin account can also unlock, that is a bonus, not a plan.

The Password Policy That Breaks the Encryption Credential

This is the one that cost the most time, because it does not present as one problem. It presents as several, in different disguises, over several days.

Disguise one: the pre-boot screen rejects a password I know is correct

A policy prompted the user to change their password at almost exactly the moment FileVault was enabling. On the next reboot, the FileVault pre-boot screen rejected the password. Not "wrong password, try again" in a way that suggests a typo, a flat refusal to unlock a machine whose password I knew.

That is a genuinely unpleasant few minutes, because it looks exactly like a lockout. It was not. When a password change lands close to FileVault enablement, the pre-boot credential can lag the account credential: the pre-boot screen is still expecting the old password while the account has the new one. Resetting the account password to the intended value resynced the two, and the pre-boot screen accepted it on the next reboot. Not a lockout, a desync.

Disguise two: the machine forces a password change and needs two reboots

On a clean reinstall, so nothing residual, the sequence was repeatable: first boot prompts for FileVault, then forces a password change, then needs a second reboot before the machine is usable. Three odd behaviours, one after another, on a machine that had done nothing wrong.

Disguise three: it accepts the old password as the new one

At the forced change, typing the same password back in was accepted. You are told to change your password, you change it to what it already was, and it says thank you.

What is actually going on

All three are one cause. Start from a fact that narrows the search enormously: macOS has no native password policy. If a Mac is forcing a password change, an MDM profile is making it. There is nothing else it could be. So the question is never "why is macOS doing this", it is "which profile did I forget I deployed".

In my case, a password requirement, complexity, length, disallow-simple, was applying at the same moment FileVault was enabling. The password created at Setup Assistant did not satisfy the policy, so macOS forced a change at first login, colliding with FileVault enablement.

Why it accepts the old password: when the change fires, macOS knows the rules the new password must meet but cannot read the existing password, only a hash. Unable to confirm the current one complies, it demands a new one, and then checks that new one only against the complexity rules, not against the previous password. There is no must-differ comparison. So the old password sails through. That quirk is not a curiosity, it is the diagnostic: it proves the change is happening purely at the login layer, where nothing is being compared to anything.

You can see the pending change from the command line, which is more reliable than waiting to be prompted:

# exit 0 = clean and directly usable.
# A "password must change" error = something is still forcing a change. Go find the profile.
dscl . -authonly <account> '<password>' ; echo $?

# What policy is doing this to me? macOS has no native password policy,
# so if a change is being forced, one of these profiles is forcing it.
sudo profiles list | grep -i -E "passcode|password|compliance|restrictions"

And the login layer is exactly the problem:

That explains everything. The account can authenticate at the login window, because that layer accepted the change. The encryption side still points at the old value, so pre-boot rejects it, the account cannot be added to FileVault, and it never appears on the unlock list. Rotating the managed password to a known value fixes it precisely because rotation sets a fresh value and clears the pending change, realigning both sides at once.

Fixing the Collision at Source

Two fixes, and you want both, because they defend different flanks.

Fix one: make Force Enable actually fire. If FileVault is already on before anyone logs in, the login-time collision cannot happen, because there is nothing to collide with. That is the targeting fix from earlier: All devices plus the enrolment-profile-name filter. This is defence in depth rather than the root fix, but it removes the whole class of problem.

Fix two: stop forcing the change. Take the password enforcement out of the policy that is doing it. In my case that was the Compliance policy; it can equally be a Device Restrictions profile. Password settings delivered that way switch on change-at-next-authentication by default, and that flag is what collides.

1. Open Devices → Compliance, open your macOS policy, and find System Security → Password.
2. Set Require a password to unlock devices to Not configured. That parent toggle gates the whole block, so the children beneath it (minimum length, expiration, history, simple passwords) grey out and stop applying. They may still display residual values; that is cosmetic, the parent being off is what counts.
3. Save. The Mac still has a password, FileVault requires one at boot and the user sets one at Setup Assistant, so nothing real is lost. What you removed is the enforcement that was flipping the forced-change flag.

If you genuinely need enforced complexity, deliver it through a Settings Catalog passcode profile with Change At Next Authentication explicitly off, never through compliance or restrictions. And set a minimum OS floor at a current point release, because older builds carried a related forced-reset bug that fires even with change-at-next-auth off.

Then prove it took, on the machine, after a sync. This is the definitive check that the collision is gone:

# After the policy change has synced: exit 0 means no forced change is pending.
# The console password is now directly usable for fdesetup add, with no rotation needed.
dscl . -authonly <account> '<password-from-console>' ; echo $?

Note the pilot that is already flagged will stay flagged until you settle it with one rotation. Removing the policy stops it happening on future builds; it does not retroactively clear a flag already set. Judge the fix by the next clean enrolment, not by the machine that caused you to find it.

The alternative, if you must keep the policy, is to set a staging password that already complies so nothing ever fires. That works, but it depends on every technician remembering, forever, which is a weaker control than deleting the cause.

One more thing while you are in the compliance policy, because it bit me alongside the password issue. If compliance has Incoming connections = Block under Device Security, and your firewall configuration profile sensibly leaves block-all-incoming off (blocking it breaks inbound remote support), compliance will mark perfectly healthy Macs non-compliant for not blocking incoming. Set it to Not configured to match your firewall posture. Two policies disagreeing about the same control is a quiet way to fail your own fleet.

Verifying Encryption, Escrow and Break-Glass

Prove every link. This is the sequence I run on a fresh build, in this order.

On the machine:

# 1. Is FileVault on?
fdesetup status

# 2. Does a recovery key exist? (true = the disk is recoverable, whatever the console says)
sudo fdesetup haspersonalrecoverykey

# 3. Who can unlock at pre-boot?
sudo fdesetup list

# 4. Token state for each account you care about
sysadminctl -secureTokenStatus <primary-account>
sysadminctl -secureTokenStatus <admin-account>

# 5. Bootstrap token escrowed?
sudo profiles status -type bootstraptoken

# 6. Is the password clean, with no pending forced change? (exit 0 = clean and usable)
dscl . -authonly <account> '<password>' ; echo $?

# 7. Did the FileVault profile actually land?
sudo profiles list | grep -i filevault

In the console: open Devices → [device] → Passwords and keys. You want the FileVault recovery key present and the local admin password retrievable. Both showing is the milestone that says the whole chain works: policy enabled the encryption, Intune owns the key, escrow completed, and your break-glass is real rather than theoretical. On my build, both of these were exactly what failed throughout the experimentation and both came good on the first clean, policy-enabled build. That is the moment you can trust the design.

Two conditions on seeing them at all: the device must be Corporate (admins cannot view recovery keys on Personal devices), and the escrow pull must have happened, so give it a check-in before concluding anything.

And then reboot. Confirm the disk unlocks at pre-boot with the account or key you expect. Everything above is a proxy; this is the test.

Breaking the Glass: Recovering a Locked-Out User

Everything above builds the safety net. This is the bit where you use it, and it is the only part of this guide you will read under pressure, so it is deliberately mechanical.

The situation: a user cannot get past the FileVault pre-boot screen. Before anything else, establish which problem you actually have, because two of the three are not lockouts at all.

1. Have they just changed their password? If so, this is probably the desync described earlier, not a lockout. The pre-boot credential is lagging the account credential.
2. Is the machine freshly built and unused? Wipe it. A rebuild costs twenty minutes and zero risk, and is almost always faster than a recovery.
3. Is it a real machine with real data and a genuinely forgotten password? Then you are breaking the glass. Read on.

Route one: the recovery key (the one that always works)

1. In the Intune admin centre go to Devices, find the machine, open it, and go to Passwords and keys. The FileVault recovery key is there.
2. If it is not there, stop and read the troubleshooting section below rather than improvising. Check the device is Corporate (admins cannot view keys on Personal devices) and that there is only one device record.
3. Read the key to the user, or better, get it to them over a channel you are happy with. It is long and case-sensitive.
4. At the pre-boot screen the user clicks the option to enter a recovery key (on recent macOS this is offered after a failed password attempt, or via the question-mark prompt). They type the key. The disk unlocks and the machine boots.
5. They now land at a password reset prompt or a logged-in session, depending on the macOS version and how the account got into this state.

Route two: the break-glass admin (if yours can unlock)

If you have verified that your managed admin holds a SecureToken and is on the unlock list, and remember the guide's earlier honesty about that not being guaranteed, you have a second route that does not burn the recovery key:

1. Retrieve the managed admin's current password from the same Passwords and keys blade.
2. At the pre-boot screen, select or type the admin account and its password. The disk unlocks.
3. Log in as that admin, then reset the user's password from System Settings → Users & Groups.
4. Rotate the admin password afterwards, for the same reason as the key: you have just handled it.

Note the ordering here, because it is the whole argument for this route. The recovery key is a single-use-and-burn credential for the entire volume. The admin password is rotatable by design and rotating it is routine. If both routes are open to you, prefer the admin.

Confirm the state before you rely on it existing, ideally long before you need it:

# Can the admin actually unlock, or have I only assumed it?
sudo fdesetup list
sysadminctl -secureTokenStatus <admin-account>

# And the disk-level truth, whatever the console says
sudo fdesetup haspersonalrecoverykey

Route three: neither works

No key in the console, no unlock-capable admin, and a genuinely forgotten password means the data is gone. That is not a failure of your process at that moment, it is FileVault working exactly as designed, and it is why every earlier section of this guide is written the way it is. The recovery you cannot perform on the bad day is decided by choices you made on a quiet Tuesday months earlier.

Practise it

Run this drill on the pilot before you need it for real: build a machine, escrow the key, then deliberately lock yourself out and recover using only what the console gives you. It takes fifteen minutes and it is the only way to know your break-glass is real rather than theoretical. Mine was theoretical for longer than I would like to admit.

Proving It Across the Fleet

Everything so far is single-machine. The question that matters at scale is different: are all of them encrypted, and do I hold all of the keys? One unescrowed machine in two hundred is the one that will find you.

The console side gives you the overview. Devices → Monitor → Encryption report lists encryption readiness and status across your Macs, and the per-device drill-in shows the key. Your Settings Catalog policy's own assignment and per-setting status view is the other half: it tells you where the policy landed and where it errored, and an error there is your early warning long before a lockout.

But a report tells you what Intune believes. The stronger check asks the machine. Deploy a small shell script on a schedule that verifies the things that actually matter and exits non-zero when they are not true, so a failure surfaces as a failed script in the console rather than as a phone call:

#!/bin/bash
# Fleet guardrail: verify FileVault state and break-glass capability.
# Exit 0 = compliant. Exit 1 = something is wrong on THIS machine.

ADMIN="<your-managed-admin-shortname>"
fail=0

# 1. Is FileVault actually on?
if ! fdesetup status | grep -q "FileVault is On"; then
  echo "FAIL: FileVault is not on"; fail=1
fi

# 2. Does a personal recovery key exist at all?
if ! fdesetup haspersonalrecoverykey | grep -qi "true"; then
  echo "FAIL: no personal recovery key on this Mac"; fail=1
fi

# 3. Is the bootstrap token escrowed? (grants tokens to later accounts)
if ! profiles status -type bootstraptoken | grep -q "escrowed to server: YES"; then
  echo "FAIL: bootstrap token not escrowed"; fail=1
fi

# 4. Can the break-glass admin actually unlock? (only if you use that model)
if ! fdesetup list | grep -q "^${ADMIN},"; then
  echo "FAIL: $ADMIN is not on the FileVault unlock list"; fail=1
fi

exit $fail

Two honest caveats. This proves the key exists on the machine; it cannot prove Intune successfully escrowed it, because that lives on the server side, so pair it with the encryption report rather than treating it as the whole answer. And if you have taken the documented model, recovery key as the break-glass and no token on the admin, drop check four or it will fail every machine, correctly, for a thing you chose on purpose.

Troubleshooting and Gotchas

No FileVault recovery key found, and the policy shows Error -2016341106

Errors on Enable, Defer and Show Recovery Key, while Location and Rotation succeed, is the signature of a disk that was encrypted outside Intune's control, almost always a manual enable at the Setup Assistant prompt. Before anything else, run sudo fdesetup haspersonalrecoverykey: if it returns true, your data is safe and this is a display and management-relationship problem, not key loss. Rule out the two innocent explanations, confirm the device is Corporate and confirm there is only one device record (a duplicate holds the escrowed items on the old object, which looks identical to loss). If both check out, it is the manual-enable mismatch. Fix with a clean policy-enabled rebuild if you can, or Escrow Buddy on a live machine you cannot wipe (noting that my existing Escrow Buddy write-up is Jamf-based, so take the concepts from it, not the deployment steps). Do not run changerecovery.

Force Enable In Setup Assistant is True but encryption is deferred

Working as designed, and your targeting is wrong. The policy is assigned to a dynamic group, which a no-affinity device joins only after enrolment, so the policy was not present during Setup Assistant and Force had nothing to fire from. Defer caught it, which is why the machine is encrypted at all. Retarget at All devices with the enrolment-profile-name filter. Do not remove Defer to "force" it, that is how you end up with no encryption.

The pre-boot screen rejects a password I know is correct

Do not assume a lockout. A password change landing near FileVault enablement desyncs the pre-boot credential from the account credential, so pre-boot expects the old password. Realign by resetting the account password to the intended value in System Settings, not at the login window, then reboot. If you cannot get in to do that, log in with the managed admin whose password is in Intune and reset the user's password from there. On a fresh build, a wipe is a zero-cost fallback. And fix the cause: something forced that password change, and it was an MDM profile, because macOS has no native password policy.

The break-glass admin can log in but never appears at pre-boot

The collision. The account is login-capable but not encryption-enabled, because a forced change desynced its credential. Rotate the managed password to a known value to clear the pending change, then add the account to FileVault, then reboot and confirm. Then remove the password enforcement from compliance so it stops happening.

# Settle the account (rotate from the console first), then:
sudo fdesetup add -usertoadd <account>

# If it has no token at all, grant one using an existing token holder
sysadminctl -secureTokenOn <account> -password <pw> -adminUser <admin> -adminPassword <adminpw>

# Confirm it landed
sudo fdesetup list

The hidden break-glass account shows at every reboot

Expected and unavoidable once it is encryption-enabled. Hide it from the ordinary login window and accept pre-boot visibility. If that visibility is genuinely unacceptable, do not make the account encryption-capable at all and rely on the escrowed recovery key as the disk break-glass, which is the documented model anyway.

The console shows no key on a machine I just encrypted

Escrow is a pull, not a push. The key waits on the machine until the MDM asks for it at a check-in. Force one, wait, and look again before you treat it as a fault. If it is still absent after a confirmed check-in, then start working through the manual-enable signature above.

Everything is erroring and I have been at this all day

Worth saying because it happened to me. After enough wipes, enrolment-model changes, duelling scripts, a manual FileVault enable and a changerecovery attempt on one poor pilot machine, its managed-secret state went genuinely inconsistent: key not displaying, policy erroring, and the local admin password rotation failing too. Data was safe, break-glass worked, but the console was a mess.

That state is an artefact of experimentation, not evidence your configuration is wrong. Do not firefight it button by button; you will chase symptoms for hours. A clean rebuild from the settled configuration resolves all of it at once, because the machine starts from a consistent state. The pilot's job was to surface the failure modes and prove the correct path, and by that point it had done exactly that. Let it go and rebuild.

The Command Reference

Run on the Mac as an admin. Several of these need sudo or they return misleadingly empty output.

Encryption state

# Is FileVault on?
fdesetup status

# Does a personal recovery key exist? THE reassurance command.
sudo fdesetup haspersonalrecoverykey

# Who can unlock at pre-boot?
sudo fdesetup list

# Add an account to FileVault (needs credentials, cannot be scripted silently)
sudo fdesetup add -usertoadd <account>

# DO NOT RUN to "fix" a missing console key: invalidates the existing/escrowed key
# sudo fdesetup changerecovery -personal

Tokens and ownership

# SecureToken status for an account
sysadminctl -secureTokenStatus <account>

# Grant a SecureToken using an existing token holder (needs both passwords)
sysadminctl -secureTokenOn <account> -password <pw> -adminUser <admin> -adminPassword <adminpw>

# Bootstrap token escrowed? (this is what grants tokens at first login)
sudo profiles status -type bootstraptoken

# Volume ownership / cryptographic users
diskutil apfs listUsers /

Accounts and passwords

# Is the password clean and directly usable? exit 0 = yes, no pending forced change
dscl . -authonly <account> '<password>' ; echo $?

# Hide from the ordinary login window (still visible at pre-boot)
sudo dscl . create /Users/<account> IsHidden 1
dscl . read /Users/<account> IsHidden

# List real local accounts
dscl . list /Users | grep -v '^_'

Policy and profiles

# Did the FileVault profile land?
sudo profiles list | grep -i filevault
sudo profiles show

# Force a check-in (escrow is a PULL, so this is what triggers it)
sudo killall IntuneMdmAgent
sudo profiles renew -type device

Assignment rule

// Filter for the FileVault policy: All devices + this filter as an Include.
// NOT a dynamic group, or Force Enable cannot fire during Setup Assistant.
(device.enrollmentProfileName -eq "<your enrolment policy name>")

Quick-Action Checklist

1. Build FileVault as a Settings Catalog policy. The template type cannot expose Force Enable at all.
2. Set Enable = On, Force Enable In Setup Assistant = True, Defer = Enabled (keep it), Show Recovery Key = Disabled, Escrow Location = human help text.
3. Assign to All devices + enrolment-profile-name filter. Never a dynamic group.
4. Confirm the primary account is an admin and Await final configuration = Yes in the enrolment policy.
5. Hide the FileVault pane in the enrolment policy so nobody can enable it manually.
6. Ensure exactly one assigned FileVault policy; unassign the old ones.
7. Remove password enforcement from Compliance (Require a password to unlock → Not configured) and from Device Restrictions.
8. If you need complexity, use a Settings Catalog passcode profile with Change At Next Authentication off. Set a minimum OS floor.
9. Align the compliance Incoming connections check with your firewall profile.
10. Decide the break-glass model, and verify it on the machine rather than assuming: sysadminctl -secureTokenStatus and fdesetup list. The escrowed key is the safety net either way.
11. Verify: fdesetup status, haspersonalrecoverykey, fdesetup list, dscl . -authonly = 0, key and admin password both visible under Passwords and keys, then reboot and unlock.
12. Run the break-glass drill on the pilot: lock yourself out deliberately and recover using only the console. Fifteen minutes, and the only proof it is real.
13. Deploy a fleet guardrail script and watch the encryption report. One unescrowed machine in two hundred is the one that finds you.
14. After any recovery: reset the password in System Settings, then rotate the key or admin password you just used. It is burned.
15. Never change a macOS password anywhere except System Settings → Users & Groups.
16. Never run changerecovery to fix a console display problem.

Closing Thoughts

FileVault on Apple silicon under Intune rewards one discipline above all: enable it by policy so Intune owns the key, and prove the key is retrievable every single time, because an encrypted machine you cannot get back into is its own kind of incident. Everything else in this guide is a consequence of that rule being broken in some specific way.

Be honest with yourself about the break-glass account. An unlock-capable account is visible at pre-boot; that is not a bug awaiting a fix. Verify what your bootstrap token actually did rather than trusting anyone's diagram, mine included, and keep the escrowed recovery key as the real safety net regardless. Keep password enforcement out of compliance, because a forced change at first login will silently desync the credential that unlocks your fleet. And when the console frightens you, run haspersonalrecoverykey before you run anything else, because the difference between a display problem and a data problem is the difference between a coffee and a very long evening. I have had both. The coffee is better.

---

← All guides