Operate FileVault recovery, APFS snapshots, and verified Time Machine backups on macOS 26
Manage hidden MDM-escrowed PRKs and Bootstrap Tokens, distinguish APFS snapshots from backups, verify Time Machine, restore real data, and rehearse audited recovery with rotation.
Protect managed Mac data at rest while proving that authorized operators can recover it without leaking recovery keys or relying on same-disk snapshots.
- macOS 26.x
- Apple silicon supported current hardware
- Managed encryption ownership MDM supports Apple FileVault escrow/rotation, device identity, Secure Token/volume owners, Bootstrap Token and retrieval roles are verified.
- Independent protected backup Encrypted external/network Time Machine and application backups exist with separate passphrase custody.
- Safe recovery test target Spare/canary Mac or separate restore path, two authorized recovery operators, audit and non-destructive acceptance are available.
OneLiners never runs these steps or stores secrets. Review placeholders, versions, current state, and change-control requirements before using a command.
Full guide
What you will build
- A managed macOS 26.x FileVault lifecycle using Secure Token/volume ownership, Bootstrap Token, unique Personal Recovery Keys encrypted to MDM escrow, metadata-only verification, audited two-person recovery, and immediate post-use rotation.
- A recovery system that distinguishes transient same-disk APFS snapshots from encrypted external Time Machine and application backups, verifies destination health, and performs real content/metadata/application restores to a separate target.
- Every managed Mac reports FileVault On and a current hidden PRK generation escrowed to the correct device record without exposing key material.
- Authorized users unlock normally; a canary recovery rehearsal proves custody, correct-device mapping, Apple recovery, audit closure, and key rotation.
- External backups restore representative bytes, ACLs, flags, xattrs and application state within RPO/RTO while local snapshots remain explicitly non-backup aids.
Architecture
How the parts fit together
APFS encryption on Apple silicon/T2 binds volume keys to Secure Token users and volume owners. MDM deploys FileVault policy, escrows Bootstrap Token and encrypts a unique PRK to restricted custody. Local APFS snapshots provide transient same-disk versions. Encrypted Time Machine and application-native exports leave the source failure domain; destination verification and separate restores prove recoverability.
- Baseline maps device, APFS, enabled users, management and escrow; external backup and restore pass before policy changes.
- MDM enables FileVault and escrows a hidden unique PRK; operators verify generation/status rather than retrieving it.
- Snapshots provide local convenience while external Time Machine and application exports protect durable recovery.
- Separate restore and canary FileVault recovery prove the full path; any PRK use triggers managed rotation and new escrow.
Assumptions
- Macs run supported macOS 26.x on Apple silicon or supported T2 hardware and are enrolled in an MDM that implements Apple's FileVault, escrow, Bootstrap Token and rotation workflows.
- At least one authorized Secure Token user/volume owner exists and lifecycle processes cover joiners, password changes, ownership transfer, leavers and lost devices.
- PRK escrow certificate/private key, retrieval roles, audit logs and incident alerts are protected and tested without routine key viewing.
- Time Machine destination is encrypted and external/network with capacity/retention; stateful applications also provide consistent exports.
- A spare/canary Mac or separate restore path can be used without overwriting or exposing production user data.
Key concepts
- Personal Recovery Key
- Unique device unlock credential recommended by Apple for managed modern Macs; treat it like a high-impact secret and rotate after use.
- Secure Token
- Password-protected wrapped key-encryption capability associated with authorized users on APFS.
- Bootstrap Token
- MDM-escrowed token that supports Secure Token, volume ownership and managed update workflows on supported Macs.
- APFS snapshot
- Copy-on-write point on the same storage, automatically purgeable and not protection against device/disk loss.
- Restore proof
- Separate reconstruction whose bytes, metadata, ownership and application behavior meet documented RPO/RTO.
Before you copy
Values used in this guide
{{escrowCertificatePayloadUuid}}secretMDM certificate payload UUID used to encrypt PRK escrow.
Example: A91F77D2-2B7E-4D43-9139-62F8B056448E{{assetId}}Non-secret device asset reference shown in recovery help text.
Example: MAC-004218{{timeMachineVolume}}Approved mounted external Time Machine volume.
Example: /Volumes/TM-Encrypted{{backupSourcePath}}Selected Time Machine path for a representative item.
Example: /Volumes/.timemachine/.../Data/Users/test/document.pdf{{restoreDestination}}Separate validation destination.
Example: /Users/test/RestoreProof/{{restoredFile}}Restored representative file used for metadata checks.
Example: /Users/test/RestoreProof/document.pdfSecurity and production boundaries
- Never place account passwords, FileVault personal recovery keys, MDM bootstrap tokens, repository credentials, or backup encryption passphrases in argv, shell history, logs, screenshots, inventory fields, or this guide.
- Use a standard user for Homebrew and routine package work. Elevate only through Apple-supported workflows; do not change ownership of system paths or run Homebrew itself with sudo.
- A FileVault personal recovery key is equivalent to a device-unlock credential. Escrow it encrypted to the authorized device-management service, restrict retrieval, log access, rotate after use, and never display it as verification evidence.
- APFS local snapshots share the source storage and disappear under space pressure. Time Machine status, a mounted backup, or a successful verify operation is not enough without periodic restore tests to separate media or a recovery Mac.
Stop before continuing if
- Stop when device identity, Secure Token/volume owner, MDM, Bootstrap Token, PRK escrow or external backup status is unknown.
- Stop immediately if a PRK/password/token/passphrase would enter argv, logs, screenshots, clipboard records or tickets; rotate exposed credentials.
- Stop treating snapshots or backup verification as recovery until separate file and application restore passes.
- Stop recovery rehearsal on wrong serial, destructive target, missing two-person authorization, absent backup, or failed rotation/new escrow.
decision
Define encryption, escrow, snapshot, backup, and recovery ownership
Inventory every macOS 26.x Mac, Apple silicon/T2 status, Secure Token users, volume owners, MDM enrollment, Bootstrap Token, FileVault policy, PRK escrow service and authorized retrievers, retention/audit, external Time Machine destination, application backups, RPO/RTO, legal/privacy constraints, lost-device response, and a spare-Mac restore rehearsal. Prefer a unique Personal Recovery Key; Apple no longer recommends institutional keys for modern institutional management.
Why this step matters
Encryption availability depends on Secure Token, volume ownership, MDM escrow, user lifecycle, hardware and recovery custody. Local snapshots and the encrypted source cannot protect against disk loss or forgotten credentials.
What to understand
Apple states IRKs have limited/no functional value on Apple silicon for recoveryOS and recommends PRKs for institutional management.
Separate PRK retrieval authority from routine Mac administration and device assignment.
Define what proof is allowed: escrow status yes, key value never.
Record only status, timestamps, identifiers, hashes, and pass/fail evidence. Redact usernames and never capture the personal recovery key, passwords, escrow payload, backup passphrase, or user documents.
Keep the source Mac and backup unchanged until the separate restore has passed content, metadata, ownership, application, and recovery-time checks.
System changes
- Creates the approved privacy, escrow, backup, restore, and incident policy.
Syntax explained
Personal Recovery Key- Unique per-device unlock credential recommended for managed modern Macs.
encrypted MDM escrow- Transfers the PRK under the escrow certificate to restricted managed custody.
Protection plan approved: macOS 26.1 Apple silicon; FileVault required in Setup Assistant; unique PRK hidden from user and encrypted to MDM; two authorized recovery operators; retrieval logged; rotate after use; external encrypted Time Machine; quarterly file/app restore; annual spare-Mac recovery.
Checkpoint: Checkpoint: Define encryption, escrow, snapshot, backup, and recovery ownership
Continue whenOwners approve enablement, token/volume-owner lifecycle, PRK custody/rotation, backup isolation, restore tests, and lost-device response.
Stop whenPRK would be shown/stored in tickets, MDM cannot escrow, no volume owner/recovery operator exists, or external restore is untested.
If this step fails
FileVault is On but MDM reports no escrowed PRK.
Likely causeEnablement preceded escrow profile/check-in, rotation failed, MDM inventory is stale, or the device is unmanaged.
fdesetup statusprofiles status -type enrollmentprofiles status -type bootstraptokenCheck MDM escrow status without revealing the key.
ResolutionKeep the user available, deploy the correct escrow policy, rotate the PRK through MDM, and confirm custody before maintenance or handoff.
Security notes
- Run the step only from an approved administrative session, preserve the exact before/after evidence, and keep credentials, recovery keys, tokens, and private data out of commands, output, screenshots, and tickets.
- Treat a successful command as provisional until the independent verification and a real consumer or restore test pass.
Alternatives
- Rehearse the same change on an isolated canary with production-shaped policy, storage, networking, identity, and restore conditions before production.
Stop conditions
- Stop when inventory, ownership, version, capacity, identity, encryption, backup, or recovery evidence differs from the approved plan.
- Stop when an independent access or restore path is unavailable, or when the proposed command would expose a secret or irreversibly overwrite the only usable copy.
verification
Verify macOS 26.x, APFS, FileVault, token, ownership, and management status
Capture model, OS build, architecture, APFS layout, FileVault status, enabled unlock users, MDM enrollment and Bootstrap Token escrow without displaying any recovery credential. Compare with device inventory and confirm the assigned user plus recovery owner before policy deployment.
Why this step matters
Encryption state alone does not prove that a supported user can unlock, that management holds recovery, or that the correct physical device is represented in inventory.
What to understand
`fdesetup list -extended` lists enabled users and key types; protect usernames in exported evidence.
`diskutil apfs listUsers /` identifies cryptographic users without exposing their secrets.
Never run commands or MDM queries that return PRK value merely to prove escrow.
Record only status, timestamps, identifiers, hashes, and pass/fail evidence. Redact usernames and never capture the personal recovery key, passwords, escrow payload, backup passphrase, or user documents.
Keep the source Mac and backup unchanged until the separate restore has passed content, metadata, ownership, application, and recovery-time checks.
System changes
- Read-only encryption, APFS, user, and management inventory.
Syntax explained
fdesetup status- Reports FileVault On/Off and encryption progress without key disclosure.
profiles status -type bootstraptoken- Reports whether management escrow exists without printing the token.
sw_vers; uname -m; system_profiler SPHardwareDataType | grep -E 'Model Identifier|Chip'; diskutil apfs list; fdesetup status; fdesetup list -extended; diskutil apfs listUsers /; profiles status -type enrollment; profiles status -type bootstraptokenProductVersion: 26.1 BuildVersion: 25B78 arm64 FileVault is On. Escrowed Recovery Key: [not queried] Enrolled via DEP: Yes MDM enrollment: Yes Bootstrap Token escrowed to server: YES
Checkpoint: Checkpoint: Verify macOS 26.x, APFS, FileVault, token, ownership, and management status
Continue whenSupported macOS 26.x/APFS device, correct identity, FileVault/token/volume-owner mapping understood, MDM and Bootstrap Token healthy.
Stop whenInventory mismatch, no authorized unlock user, unmanaged device, token/escrow unknown, or command/output would reveal recovery data.
If this step fails
The authorized user cannot unlock FileVault at preboot.
Likely causeThe account lacks Secure Token/volume ownership, password changed without synchronization, keyboard layout differs, or APFS/preboot state is stale.
fdesetup list -extendeddiskutil apfs listUsers /profiles status -type bootstraptoken
ResolutionUse another authorized volume owner or escrowed PRK through recovery, then repair token/ownership with Apple-supported management and retest.
Security notes
- Run the step only from an approved administrative session, preserve the exact before/after evidence, and keep credentials, recovery keys, tokens, and private data out of commands, output, screenshots, and tickets.
- Treat a successful command as provisional until the independent verification and a real consumer or restore test pass.
Alternatives
- Rehearse the same change on an isolated canary with production-shaped policy, storage, networking, identity, and restore conditions before production.
Stop conditions
- Stop when inventory, ownership, version, capacity, identity, encryption, backup, or recovery evidence differs from the approved plan.
- Stop when an independent access or restore path is unavailable, or when the proposed command would expose a secret or irreversibly overwrite the only usable copy.
verification
Create and restore-test an external backup before FileVault changes
Configure an encrypted external or approved network Time Machine destination through the supported UI/MDM, create application-native exports, start and complete a backup, then restore representative files and a stateful application dataset to a separate path or spare Mac. Local APFS snapshots do not satisfy this gate.
Why this step matters
Enabling or rotating recovery credentials changes the only paths to encrypted data. A completed external backup plus restored data is the minimum proof before touching those paths.
What to understand
Use application-consistent exports for databases and stateful services before Time Machine.
Compare ACLs, flags, extended attributes, resource forks and application behavior, not only bytes.
Store the backup encryption passphrase separately from the FileVault PRK.
Record only status, timestamps, identifiers, hashes, and pass/fail evidence. Redact usernames and never capture the personal recovery key, passwords, escrow payload, backup passphrase, or user documents.
Keep the source Mac and backup unchanged until the separate restore has passed content, metadata, ownership, application, and recovery-time checks.
System changes
- Creates external Time Machine/application backups and a separate restored validation copy.
Syntax explained
--auto --block- Starts configured automatic-style backup and waits for completion without a password argument.
latestbackup/listbackups- Records the external recovery points available to restore.
Values stay on this page and are never sent or saved.
tmutil destinationinfo; tmutil startbackup --auto --block; tmutil latestbackup; tmutil listbackups; shasum -a 256 {{restoredFile}}; ls -leO@ {{restoredFile}}; xattr -l {{restoredFile}}Name : TM-Encrypted Kind : Local Mount Point : /Volumes/TM-Encrypted Backup completed successfully. /Volumes/.timemachine/.../2026-07-28-110500.backup 9e107d9d372bb6826bd81d3542a419d6... /Users/test/RestoreProof/document.pdf
Checkpoint: Checkpoint: Create and restore-test an external backup before FileVault changes
Continue whenExternal/network encrypted backup completes and separate restored content/metadata/application passes within RPO/RTO.
Stop whenOnly same-disk snapshot exists, destination/passphrase custody is unknown, backup errors, or restore fails.
If this step fails
Time Machine backup fails or remains preparing.
Likely causeExclusions, filesystem errors, antivirus, huge churn, sparsebundle/network faults, or insufficient capacity block progress.
tmutil statustmutil latestbackuplog show --last 2h --predicate 'process == "backupd"'
ResolutionPreserve logs, fix the specific storage/network/exclusion condition, retry, and require a restore test rather than repeatedly deleting backup history.
Security notes
- Run the step only from an approved administrative session, preserve the exact before/after evidence, and keep credentials, recovery keys, tokens, and private data out of commands, output, screenshots, and tickets.
- Treat a successful command as provisional until the independent verification and a real consumer or restore test pass.
Alternatives
- Rehearse the same change on an isolated canary with production-shaped policy, storage, networking, identity, and restore conditions before production.
Stop conditions
- Stop when inventory, ownership, version, capacity, identity, encryption, backup, or recovery evidence differs from the approved plan.
- Stop when an independent access or restore path is unavailable, or when the proposed command would expose a secret or irreversibly overwrite the only usable copy.
config
Deploy FileVault and encrypted PRK escrow through MDM
Use the organization's Apple-supported device-management FileVault payload to require FileVault at Setup Assistant or approved deferred enablement, hide PRK from routine display, escrow each unique PRK encrypted with the escrow certificate, and ensure Bootstrap Token support. Configure recovery messaging with a help-desk reference, never the key.
Why this step matters
MDM can coordinate Secure Token/volume ownership and encrypt the PRK to escrow without putting it in shell history or asking users to copy it. Hiding the key reduces accidental disclosure.
What to understand
The device-management vendor implements payload/reporting details; validate against Apple's payload and deployment documentation.
Use Setup Assistant enforcement for newly deployed managed Macs where supported; stage deferred enablement carefully for existing users.
The escrow certificate private key and PRK retrieval role are high-impact secrets and require rotation, audit and separation.
Record only status, timestamps, identifiers, hashes, and pass/fail evidence. Redact usernames and never capture the personal recovery key, passwords, escrow payload, backup passphrase, or user documents.
Keep the source Mac and backup unchanged until the separate restore has passed content, metadata, ownership, application, and recovery-time checks.
System changes
- Installs FileVault/escrow policy, may enable encryption, create a unique PRK, and escrow it encrypted to MDM after user/bootstrap authorization.
Syntax explained
ShowRecoveryKey Off- Prevents routine display of the PRK after enablement.
EncryptCertPayloadUUID- Identifies the certificate used to encrypt the PRK for escrow.
MDM FileVault policy (structured payload, not a local secret-bearing file)Values stay on this page and are never sent or saved.
Enable: On
ForceEnableInSetupAssistant: On where supported
UseRecoveryKey: On
ShowRecoveryKey: Off
FDERecoveryKeyEscrow: On
EncryptCertPayloadUUID: {{escrowCertificatePayloadUuid}}
Location: Contact authorized support and provide device asset ID {{assetId}}.
MDM command status: Acknowledged FileVault policy: Installed PRK escrow status: Escrowed PRK value: not returned to operator Bootstrap Token escrowed: YES
Checkpoint: Checkpoint: Deploy FileVault and encrypted PRK escrow through MDM
Continue whenPolicy acknowledged, FileVault reaches On, unique PRK reports Escrowed without value exposure, Bootstrap Token remains escrowed, authorized user unlock works.
Stop whenPRK appears in logs/UI evidence, policy lacks escrow encryption, user has no Secure Token/volume ownership, or backup/recovery gate failed.
If this step fails
FileVault is On but MDM reports no escrowed PRK.
Likely causeEnablement preceded escrow profile/check-in, rotation failed, MDM inventory is stale, or the device is unmanaged.
fdesetup statusprofiles status -type enrollmentprofiles status -type bootstraptokenCheck MDM escrow status without revealing the key.
ResolutionKeep the user available, deploy the correct escrow policy, rotate the PRK through MDM, and confirm custody before maintenance or handoff.
Security notes
- Run the step only from an approved administrative session, preserve the exact before/after evidence, and keep credentials, recovery keys, tokens, and private data out of commands, output, screenshots, and tickets.
- Treat a successful command as provisional until the independent verification and a real consumer or restore test pass.
Alternatives
- Rehearse the same change on an isolated canary with production-shaped policy, storage, networking, identity, and restore conditions before production.
Stop conditions
- Stop when inventory, ownership, version, capacity, identity, encryption, backup, or recovery evidence differs from the approved plan.
- Stop when an independent access or restore path is unavailable, or when the proposed command would expose a secret or irreversibly overwrite the only usable copy.
verification
Verify escrow and retrieval controls without viewing the recovery key
Correlate asset ID, serial, MDM device record, policy status, FileVault On, Bootstrap Token, last check-in, escrow timestamp, key-rotation generation, and authorized retriever roles. Use a second reviewer and confirm the MDM can initiate rotation; do not open or copy the PRK during routine verification.
Why this step matters
Matching status and custody metadata proves operational escrow while preserving the secrecy of the credential. Viewing it for every audit increases compromise risk without proving recovery.
What to understand
Audit who can retrieve, require a reason/ticket and alert device owner/security on use.
Retention must avoid storing retired PRKs indefinitely outside incident/legal needs.
Test MDM API/admin behavior with a synthetic lab Mac when possible.
Record only status, timestamps, identifiers, hashes, and pass/fail evidence. Redact usernames and never capture the personal recovery key, passwords, escrow payload, backup passphrase, or user documents.
Keep the source Mac and backup unchanged until the separate restore has passed content, metadata, ownership, application, and recovery-time checks.
System changes
- Reads local and MDM metadata only; no key retrieval or rotation.
Syntax explained
generation/timestamp- Shows current escrow event and supports rotation audit without revealing the key.
two-person review- Reduces asset-record mismatch and unauthorized credential access.
system_profiler SPHardwareDataType | grep 'Serial Number'; fdesetup status; profiles status -type enrollment; profiles status -type bootstraptokenSerial Number (system): C02REDACTED123 FileVault is On. Enrolled via DEP: Yes MDM enrollment: Yes Bootstrap Token escrowed to server: YES MDM PRK status: Escrowed 2026-07-28T11:40:12Z; generation 3; value hidden
Checkpoint: Checkpoint: Verify escrow and retrieval controls without viewing the recovery key
Continue whenSerial/asset match, FileVault On, current PRK generation escrowed, restricted retrieval roles and audit alerts proven, no key value accessed.
Stop whenRecord mismatch, stale/missing escrow, excessive retriever role, unlogged access, or verification requires displaying the key.
If this step fails
FileVault is On but MDM reports no escrowed PRK.
Likely causeEnablement preceded escrow profile/check-in, rotation failed, MDM inventory is stale, or the device is unmanaged.
fdesetup statusprofiles status -type enrollmentprofiles status -type bootstraptokenCheck MDM escrow status without revealing the key.
ResolutionKeep the user available, deploy the correct escrow policy, rotate the PRK through MDM, and confirm custody before maintenance or handoff.
Security notes
- Run the step only from an approved administrative session, preserve the exact before/after evidence, and keep credentials, recovery keys, tokens, and private data out of commands, output, screenshots, and tickets.
- Treat a successful command as provisional until the independent verification and a real consumer or restore test pass.
Alternatives
- Rehearse the same change on an isolated canary with production-shaped policy, storage, networking, identity, and restore conditions before production.
Stop conditions
- Stop when inventory, ownership, version, capacity, identity, encryption, backup, or recovery evidence differs from the approved plan.
- Stop when an independent access or restore path is unavailable, or when the proposed command would expose a secret or irreversibly overwrite the only usable copy.
instruction
Rotate a personal recovery key through the managed workflow
Rotate after suspected disclosure, authorized recovery use, ownership transfer, or policy schedule using the MDM FileVault key-rotation command. Keep the Mac online and an authorized user/recovery path available; wait for command acknowledgement and new escrow generation before invalidating the incident. Never use a command that prints the new PRK into automation output.
Why this step matters
Rotation limits the lifetime of an exposed or used unlock credential, but losing connectivity or escrow between generations can strand the device. Managed acknowledgement and metadata-only verification close that gap.
What to understand
Do not rotate during OS update, low power, MDM outage, or when no authorized unlock user/backup exists.
After recovery use, treat all copied/viewed instances as sensitive incident artifacts and rotate promptly.
Retired PRK should no longer unlock; test only in an authorized spare/rehearsal path without recording either value.
Record only status, timestamps, identifiers, hashes, and pass/fail evidence. Redact usernames and never capture the personal recovery key, passwords, escrow payload, backup passphrase, or user documents.
Keep the source Mac and backup unchanged until the separate restore has passed content, metadata, ownership, application, and recovery-time checks.
System changes
- Generates a new FileVault PRK, invalidates the previous key, and escrows the new key encrypted to MDM.
Syntax explained
MDM RotateFileVaultKey- Apple-supported managed rotation without exposing the new PRK in local argv.
RotateFileVaultKey command: Acknowledged Previous generation: 3 (retired) Current generation: 4 (escrowed 2026-07-28T12:05:44Z) Recovery key value: hidden FileVault status: On
Checkpoint: Checkpoint: Rotate a personal recovery key through the managed workflow
Continue whenCommand acknowledged, generation advances once, new PRK reports escrowed/hidden, FileVault remains On, normal user unlock succeeds.
Stop whenMDM is offline, old/new escrow state ambiguous, backup missing, only unlock user unavailable, or key would be returned to logs.
If this step fails
A displayed PRK was copied into logs or a ticket.
Likely causeManual enablement or recovery exposed the key and the operator treated it as ordinary output.
Review access/audit logs without repeating the value.Confirm whether the key was retrieved or used.
ResolutionTreat the PRK as compromised, restrict the record, rotate it through approved MDM workflow, confirm new escrow, and remove exposed copies under incident policy.
Security notes
- Run the step only from an approved administrative session, preserve the exact before/after evidence, and keep credentials, recovery keys, tokens, and private data out of commands, output, screenshots, and tickets.
- Treat a successful command as provisional until the independent verification and a real consumer or restore test pass.
Alternatives
- Rehearse the same change on an isolated canary with production-shaped policy, storage, networking, identity, and restore conditions before production.
Stop conditions
- Stop when inventory, ownership, version, capacity, identity, encryption, backup, or recovery evidence differs from the approved plan.
- Stop when an independent access or restore path is unavailable, or when the proposed command would expose a secret or irreversibly overwrite the only usable copy.
verification
Inventory APFS local snapshots and prove their limited role
List Time Machine and APFS snapshots on the source volume, record dates and free space, create a controlled local snapshot only if policy permits, and restore one harmless prior file version through the supported Time Machine interface. Explicitly document that snapshots share the same disk and may be purged under pressure.
Why this step matters
Snapshots are useful for short accidental-change recovery and update workflows, but their same-volume placement and automatic deletion make them unsuitable for device loss, disk failure, ransomware, or retention guarantees.
What to understand
Do not manually thin snapshots simply to hide low capacity; identify storage growth and preserve external backup first.
Snapshot names/timestamps do not prove application consistency or independent recoverability.
Use external Time Machine and application backup for the durable recovery objective.
Record only status, timestamps, identifiers, hashes, and pass/fail evidence. Redact usernames and never capture the personal recovery key, passwords, escrow payload, backup passphrase, or user documents.
Keep the source Mac and backup unchanged until the separate restore has passed content, metadata, ownership, application, and recovery-time checks.
System changes
- Creates one APFS local snapshot on the source volume when allowed; it consumes shared copy-on-write storage until purged/deleted.
Syntax explained
tmutil listlocalsnapshots- Lists Time Machine local snapshot names on a volume.
diskutil apfs listsnapshots- Shows APFS snapshot UUID/XID metadata.
tmutil listlocalsnapshots /; diskutil apfs listsnapshots /; df -h /; tmutil localsnapshot; tmutil listlocalsnapshots /Snapshots for disk /:
com.apple.TimeMachine.2026-07-28-120112.local
+-- 7E41A762-06E9-4F19-94F7-D05FD244A818
Name: com.apple.TimeMachine.2026-07-28-120112.local
XID: 8123481
Created local snapshot with date: 2026-07-28-121530Checkpoint: Checkpoint: Inventory APFS local snapshots and prove their limited role
Continue whenSnapshots are visible and one harmless version can be restored, while policy records they are transient same-disk aids only.
Stop whenDisk space is low, external backup is stale, snapshot is called a backup, or application owner assumes transaction consistency.
If this step fails
tmutil shows no local snapshots.
Likely causeTime Machine is not configured/recent, volume is not APFS, space pressure removed snapshots, or policy disabled behavior.
diskutil info / | grep 'File System Personality'tmutil listlocalsnapshots /tmutil destinationinfo
ResolutionFix Time Machine configuration and external backup; do not depend on local snapshots because macOS may purge them.
Security notes
- Run the step only from an approved administrative session, preserve the exact before/after evidence, and keep credentials, recovery keys, tokens, and private data out of commands, output, screenshots, and tickets.
- Treat a successful command as provisional until the independent verification and a real consumer or restore test pass.
Alternatives
- Rehearse the same change on an isolated canary with production-shaped policy, storage, networking, identity, and restore conditions before production.
Stop conditions
- Stop when inventory, ownership, version, capacity, identity, encryption, backup, or recovery evidence differs from the approved plan.
- Stop when an independent access or restore path is unavailable, or when the proposed command would expose a secret or irreversibly overwrite the only usable copy.
command
Run external Time Machine backup and verify destination health
Connect or reach the approved encrypted destination, verify its identity and capacity, run a blocking backup, inspect status/latest backup, and use Apple's supported Verify Backups menu for network destinations or Disk Utility verification for directly attached media. Verification is a complement to, not replacement for, restore.
Why this step matters
Destination identity, completed copy, and filesystem/network verification detect different failure classes. None proves user/application recovery until files are restored separately.
What to understand
For supported network backups, hold Option in the Time Machine menu and choose Verify Backups as Apple documents.
Do not place the backup passphrase in tmutil commands; unlock through Keychain/approved UI or managed workflow.
Keep at least one copy outside the Mac's physical failure domain.
Record only status, timestamps, identifiers, hashes, and pass/fail evidence. Redact usernames and never capture the personal recovery key, passwords, escrow payload, backup passphrase, or user documents.
Keep the source Mac and backup unchanged until the separate restore has passed content, metadata, ownership, application, and recovery-time checks.
System changes
- Writes a new Time Machine backup and reads/verifies the destination volume.
Syntax explained
destinationinfo- Identifies configured destination before writing.
verifyVolume- Checks filesystem structure for an attached Time Machine volume; use the destination-appropriate Apple method.
Values stay on this page and are never sent or saved.
tmutil destinationinfo; tmutil startbackup --auto --block; tmutil status; tmutil latestbackup; diskutil verifyVolume {{timeMachineVolume}}Name : TM-Encrypted Mount Point : /Volumes/TM-Encrypted Backup completed successfully. Running = 0; /Volumes/.timemachine/.../2026-07-28-124500.backup The volume TM-Encrypted appears to be OK.
Checkpoint: Checkpoint: Run external Time Machine backup and verify destination health
Continue whenCorrect encrypted destination, backup completed, latest point advances, destination verification passes, and retention/capacity are healthy.
Stop whenWrong destination, unencrypted/unknown media, backup incomplete, verify errors, or only local snapshot exists.
If this step fails
Verify Backups is unavailable.
Likely causeApple exposes manual verification primarily for supported network backup destinations, while directly attached disks use Disk Utility/normal backup integrity paths.
tmutil destinationinfodiskutil verifyVolume {{timeMachineVolume}}Check Time Machine menu with Option held.
ResolutionUse the verification method Apple supports for the destination and always complement it with a real restored-file/application test.
Security notes
- Run the step only from an approved administrative session, preserve the exact before/after evidence, and keep credentials, recovery keys, tokens, and private data out of commands, output, screenshots, and tickets.
- Treat a successful command as provisional until the independent verification and a real consumer or restore test pass.
Alternatives
- Rehearse the same change on an isolated canary with production-shaped policy, storage, networking, identity, and restore conditions before production.
Stop conditions
- Stop when inventory, ownership, version, capacity, identity, encryption, backup, or recovery evidence differs from the approved plan.
- Stop when an independent access or restore path is unavailable, or when the proposed command would expose a secret or irreversibly overwrite the only usable copy.
verification
Restore files and application state to a separate destination
Choose a backup older than a controlled modification, restore representative documents and stateful application data into a new validation directory or spare Mac, and compare content hash, ACLs, flags, extended attributes, resource forks, ownership, and application integrity. Do not overwrite the live source during testing.
Why this step matters
A separate restore is the only direct proof that Time Machine contains usable bytes and metadata and that application backup captures a coherent dataset.
What to understand
Use non-sensitive synthetic proof files where possible; never paste restored user content into tickets.
Test at least one deleted-file, prior-version, large package, extended-attribute, and stateful application case.
Record achieved RPO/RTO and remediate exclusions or slowness.
Record only status, timestamps, identifiers, hashes, and pass/fail evidence. Redact usernames and never capture the personal recovery key, passwords, escrow payload, backup passphrase, or user documents.
Keep the source Mac and backup unchanged until the separate restore has passed content, metadata, ownership, application, and recovery-time checks.
System changes
- Copies selected backup data to a separate validation destination and runs read-only integrity checks.
Syntax explained
tmutil restore source destination- Restores selected backup content to an explicit separate target.
ls -leO@ / xattr- Verifies ACLs, flags and extended attributes beyond file hash.
Values stay on this page and are never sent or saved.
tmutil listbackups; tmutil restore {{backupSourcePath}} {{restoreDestination}}; shasum -a 256 {{restoredFile}}; ls -leO@ {{restoredFile}}; xattr -l {{restoredFile}}Total copied: 486.2 MB
9e107d9d372bb6826bd81d3542a419d6... /Users/test/RestoreProof/document.pdf
-rw-r-----@ 1 test staff - 48622 Jul 27 16:42 document.pdf
com.apple.quarantine 57
Application integrity check: PASSCheckpoint: Checkpoint: Restore files and application state to a separate destination
Continue whenSelected point restores to separate destination; bytes, metadata, ownership and application behavior match expected RPO/RTO.
Stop whenDestination is original/production, source point is ambiguous, personal data would leak, metadata differs, or app integrity fails.
If this step fails
A restored file hash matches but the application cannot use it.
Likely causeACLs, extended attributes, resource forks, database consistency, related files, keychain material, or schema version is missing.
xattr -l {{restoredFile}}ls -leO@ {{restoredFile}}Run the application's official integrity check.
ResolutionRestore the full application-consistent set to an isolated location and validate metadata plus application behavior, not hash alone.
Security notes
- Run the step only from an approved administrative session, preserve the exact before/after evidence, and keep credentials, recovery keys, tokens, and private data out of commands, output, screenshots, and tickets.
- Treat a successful command as provisional until the independent verification and a real consumer or restore test pass.
Alternatives
- Rehearse the same change on an isolated canary with production-shaped policy, storage, networking, identity, and restore conditions before production.
Stop conditions
- Stop when inventory, ownership, version, capacity, identity, encryption, backup, or recovery evidence differs from the approved plan.
- Stop when an independent access or restore path is unavailable, or when the proposed command would expose a secret or irreversibly overwrite the only usable copy.
verification
Rehearse authorized FileVault recovery and rotate after use
On a spare or designated canary Mac with current external backup, simulate lost user access. Two authorized operators retrieve the PRK through audited MDM custody without copying it, enter it only into Apple recovery/preboot, unlock the correct volume, verify identity and a harmless file, then rotate the PRK immediately and confirm new escrow. Do not erase production during a credential test.
Why this step matters
Escrow status does not prove the organization can locate the right device record, authorize retrieval, enter the credential safely, unlock, recover data, close audit, and rotate afterward. A canary rehearsal proves the human system.
What to understand
Apple silicon recovery behavior differs from older Intel/IRK workflows; test the supported hardware and macOS 26.x path.
Do not enable remote login solely for recovery without a security review; macOS 26 can support FileVault unlock over SSH in specific Apple-silicon/network conditions, which adds exposure.
If the PRK is viewed or used, rotate it even when the rehearsal succeeds.
Record only status, timestamps, identifiers, hashes, and pass/fail evidence. Redact usernames and never capture the personal recovery key, passwords, escrow payload, backup passphrase, or user documents.
Keep the source Mac and backup unchanged until the separate restore has passed content, metadata, ownership, application, and recovery-time checks.
System changes
- Uses the canary PRK for unlock and rotates it through MDM; no production data is overwritten.
Syntax explained
two-person retrieval- Separates approval and reduces wrong-device or unauthorized recovery.
immediate rotation- Retires the credential after authorized exposure/use.
Recovery request: approved by two operators Device serial and asset: matched FileVault volume: unlocked through Apple recovery Validation file: readable; content hash PASS PRK retrieval: closed RotateFileVaultKey: acknowledged New generation escrowed; value hidden
Checkpoint: Checkpoint: Rehearse authorized FileVault recovery and rotate after use
Continue whenCorrect canary unlocks, validation data is readable, audit is complete, new key generation escrowed/hidden, normal user unlock and backup still work.
Stop whenSerial mismatch, target is production without approval, retrieval is unlogged, key would be copied/recorded, backup absent, or rotation/escrow fails.
If this step fails
A recovery rehearsal risks erasing or exposing production data.
Likely causeThe procedure was not isolated, PRK custody was not separated, restore destination was ambiguous, or the test required destructive recoveryOS actions.
Confirm serial number and target disk through two-person review.Verify external backup and replacement/test Mac.Confirm PRK retrieval logging without displaying it.
ResolutionStop, re-scope to a spare Mac or non-destructive unlock, and rotate the PRK after any authorized use.
Security notes
- Run the step only from an approved administrative session, preserve the exact before/after evidence, and keep credentials, recovery keys, tokens, and private data out of commands, output, screenshots, and tickets.
- Treat a successful command as provisional until the independent verification and a real consumer or restore test pass.
Alternatives
- Rehearse the same change on an isolated canary with production-shaped policy, storage, networking, identity, and restore conditions before production.
Stop conditions
- Use a spare/canary or non-destructive authorized recovery target; never improvise erase/restore on the only production Mac.
- Abort and rotate through incident response if the recovery key appears in any log, screen capture, clipboard history, or ticket.
Finish line
Verification checklist
fdesetup status; profiles status -type enrollment; profiles status -type bootstraptokenFileVault On, correct MDM enrollment and Bootstrap Token escrow without key disclosure.tmutil destinationinfo; tmutil latestbackup; tmutil listbackupsCorrect encrypted external/network destination and current backup generation.shasum -a 256 {{restoredFile}}; ls -leO@ {{restoredFile}}; xattr -l {{restoredFile}}Content, ACLs, flags, attributes, ownership and application integrity pass separately.Recovery guidance
Common problems and safe checks
FileVault is On but MDM reports no escrowed PRK.
Likely causeEnablement preceded escrow profile/check-in, rotation failed, MDM inventory is stale, or the device is unmanaged.
fdesetup statusprofiles status -type enrollmentprofiles status -type bootstraptokenCheck MDM escrow status without revealing the key.
ResolutionKeep the user available, deploy the correct escrow policy, rotate the PRK through MDM, and confirm custody before maintenance or handoff.
A displayed PRK was copied into logs or a ticket.
Likely causeManual enablement or recovery exposed the key and the operator treated it as ordinary output.
Review access/audit logs without repeating the value.Confirm whether the key was retrieved or used.
ResolutionTreat the PRK as compromised, restrict the record, rotate it through approved MDM workflow, confirm new escrow, and remove exposed copies under incident policy.
The authorized user cannot unlock FileVault at preboot.
Likely causeThe account lacks Secure Token/volume ownership, password changed without synchronization, keyboard layout differs, or APFS/preboot state is stale.
fdesetup list -extendeddiskutil apfs listUsers /profiles status -type bootstraptoken
ResolutionUse another authorized volume owner or escrowed PRK through recovery, then repair token/ownership with Apple-supported management and retest.
FileVault encryption remains paused or incomplete.
Likely causePower is unavailable, disk/APFS health is poor, OS update is pending, or enablement policy/user interaction did not finish.
fdesetup statusdiskutil apfs listpmset -g battlog show --last 1h --predicate 'process == "fdesetupd"'
ResolutionConnect power, repair supported storage issues, complete the managed user workflow, and monitor until encryption reports complete.
Bootstrap Token is not escrowed.
Likely causeMDM does not support it, no Secure Token user logged in after enrollment, management connectivity failed, or enrollment sequence is wrong.
profiles status -type enrollmentprofiles status -type bootstraptokenlog show --last 1h --predicate 'subsystem CONTAINS "ManagedClient"'
ResolutionRestore MDM connectivity/support, have an authorized Secure Token user complete the supported login/escrow flow, and verify status without printing token data.
tmutil shows no local snapshots.
Likely causeTime Machine is not configured/recent, volume is not APFS, space pressure removed snapshots, or policy disabled behavior.
diskutil info / | grep 'File System Personality'tmutil listlocalsnapshots /tmutil destinationinfo
ResolutionFix Time Machine configuration and external backup; do not depend on local snapshots because macOS may purge them.
A local snapshot cannot restore a file.
Likely causeSnapshot aged out, shares the damaged disk, file was excluded/not present, APFS is unhealthy, or available snapshots postdate the loss.
tmutil listlocalsnapshots /diskutil apfs listsnapshots /tmutil latestbackup
ResolutionUse the external Time Machine or application backup, restore to a separate path, and investigate protection coverage.
Time Machine cannot find or mount the destination.
Likely causeDisk/network is unavailable, destination identity changed, credentials/keychain are invalid, filesystem is damaged, or capacity is exhausted.
tmutil destinationinfodiskutil listmountlog show --last 1h --predicate 'process == "backupd"'
ResolutionRestore approved connectivity/mount/credential through UI or MDM without exposing secrets, verify the disk, and do not reformat until recovery ownership is confirmed.
Time Machine backup fails or remains preparing.
Likely causeExclusions, filesystem errors, antivirus, huge churn, sparsebundle/network faults, or insufficient capacity block progress.
tmutil statustmutil latestbackuplog show --last 2h --predicate 'process == "backupd"'
ResolutionPreserve logs, fix the specific storage/network/exclusion condition, retry, and require a restore test rather than repeatedly deleting backup history.
Verify Backups is unavailable.
Likely causeApple exposes manual verification primarily for supported network backup destinations, while directly attached disks use Disk Utility/normal backup integrity paths.
tmutil destinationinfodiskutil verifyVolume {{timeMachineVolume}}Check Time Machine menu with Option held.
ResolutionUse the verification method Apple supports for the destination and always complement it with a real restored-file/application test.
A restored file hash matches but the application cannot use it.
Likely causeACLs, extended attributes, resource forks, database consistency, related files, keychain material, or schema version is missing.
xattr -l {{restoredFile}}ls -leO@ {{restoredFile}}Run the application's official integrity check.
ResolutionRestore the full application-consistent set to an isolated location and validate metadata plus application behavior, not hash alone.
A recovery rehearsal risks erasing or exposing production data.
Likely causeThe procedure was not isolated, PRK custody was not separated, restore destination was ambiguous, or the test required destructive recoveryOS actions.
Confirm serial number and target disk through two-person review.Verify external backup and replacement/test Mac.Confirm PRK retrieval logging without displaying it.
ResolutionStop, re-scope to a spare Mac or non-destructive unlock, and rotate the PRK after any authorized use.
Reference
Frequently asked questions
Should an admin view the PRK to verify escrow?
No. Verify asset match, current generation, escrow timestamp, status, roles and audit. Retrieve only for authorized recovery and rotate after use.
Is an APFS snapshot a backup?
No. It shares the source disk and may be purged. Maintain encrypted external/network backup and prove it with separate restores.
Should organizations use an IRK?
Apple recommends unique PRKs for modern managed Macs; IRKs have limited utility and no functional recoveryOS value on Apple silicon.
Recovery
Rollback
Do not disable FileVault casually. Roll back a failed policy by pausing further deployment while preserving encryption and access; restore data from tested backup or use authorized recovery. Any exposed/used PRK is rotated, not restored.
- Keep the Mac powered, preserve MDM/FileVault/APFS/backup logs and verify device serial before action.
- If escrow is missing, keep the authorized user available, repair MDM policy/connectivity and rotate to a newly escrowed hidden PRK.
- If a user/token change blocks unlock, use another authorized volume owner or audited PRK recovery, then repair through Apple-supported management.
- If storage/data is damaged, restore to separate media/Mac first; never overwrite the only source until integrity and ownership pass.
- After recovery, rotate any viewed PRK, confirm new escrow, normal unlock, current backup and repeat restore evidence.
Evidence