Time Machine Encrypted Backups: The Complete Setup, Recovery & Best-Practices Guide

An encrypted Time Machine backup is the difference between "I lost a hard drive" and "I lost a hard drive, the data is unrecoverable to whoever has it now, and my recovery story is intact". For local backups it is good practice. For network and cloud backups it is non-negotiable. This guide covers everything: the setup walk-through, the cryptography that actually runs underneath, where macOS keeps your password, the (limited) options if you forget it, how to change it, and the pitfalls that turn a well-intentioned encrypted backup into a paperweight.

If you want the broader strategic picture of how Time Machine encryption fits alongside FileVault and SMB3, read the Mac backup encryption explainer first. This article is the deep operational guide for the Time Machine layer specifically.

Why Encrypted Time Machine Matters Now More Than Ever

Two trends have made this question more urgent than it was a decade ago. First, off-site backups are no longer the exception; cloud Time Machine destinations are mainstream and they put your snapshots somewhere you do not physically control. Second, NAS devices have become routine targets in opportunistic ransomware campaigns, which means a NAS holding your unencrypted backup is functionally a copy of your data sitting on a target.

Encrypting the Time Machine volume itself, as opposed to relying on whatever the destination provides, means you carry the security boundary with you. The cloud provider, the NAS, the USB SSD on your desk: none of them ever see plaintext.

Setup Walk-through

The setup flow is the same regardless of destination type, with one small wrinkle for network shares.

Adding a new backup disk

1. Open System Settings → General → Time Machine. (On older macOS releases this is System Preferences → Time Machine.)
2. Click Add Backup Disk (or the + button).
3. Select your destination from the list. Local USB drives and Thunderbolt enclosures appear under "Available Disks". Network shares appear under "Available Network Disks", but only if they are currently mounted in Finder; for cloud destinations, mount the share via ⌘K in Finder first.
4. Crucially, leave the Encrypt Backup toggle on. Do not turn it off "just to get the first backup going faster". Encryption applied at setup is dramatically simpler than retrofitting it later.
5. Set a passphrase when prompted. Make it long and random (more on this in a moment).
6. Optionally provide a password hint. Treat the hint as something the attacker will see; do not put anything that narrows the search space.
7. Click Set Up Disk. The first backup begins immediately.

Converting an existing unencrypted disk

If you already have an unencrypted Time Machine destination and want to add encryption, the cleanest path is:

1. Add a second destination with encryption enabled.
2. Wait for the new destination to complete a full initial backup.
3. Verify it with a test restore.
4. Remove the old unencrypted destination.

You can also try the in-place conversion trick on APFS volumes: select the volume in Disk Utility and choose Encrypt. macOS encrypts in the background while Time Machine continues to write. This works on most recent macOS versions but is not officially documented for Time Machine destinations specifically; treat it as best-effort.

Choosing a Passphrase

The passphrase is the single most important choice in your encrypted backup setup. The encryption itself (AES-XTS-128) has no known practical attacks; the realistic break is brute-forcing the passphrase. So pick one that resists brute force.

Targets:

• Length: 16+ characters minimum. 20+ is better. The math is exponential; each extra character roughly doubles the work for an attacker.
• Source: generated by a password manager, not chosen by you. Human-chosen passwords cluster in predictable patterns and have far less entropy than they look.
• Storage: in your password manager, plus a printed copy in a physical safe (or a sealed envelope kept somewhere you trust). The Keychain on your Mac is convenient but is not a long-term storage medium for the password itself.
• Hint: use sparingly or skip entirely. A hint that says "the same as my email password" undoes everything.

If you find yourself memorizing the passphrase, that is a sign it is too short. The whole point of encryption keys is that humans should not be in the memorization loop.

Where macOS Stores the Password

After setup, the encryption password is saved in the local Keychain so subsequent backups happen automatically without prompting. Specifically:

• For backups configured for "unattended" use, the entry lives in the System keychain (so it is available before login).
• For backups that prompt at login, the entry lives in the user's login keychain.

To inspect or retrieve it:

1. Open Applications → Utilities → Keychain Access.
2. In the search box, type the name of your backup volume (or "Time Machine" or the SMB share name).
3. Double-click the matching entry.
4. Check Show password. macOS will prompt for your login password to authorize.

This is your fallback if you forgot the encryption password but still have a working Mac that has been backing up successfully. Pull it out of the Keychain and write it down.

What AES-XTS Actually Does

The encryption algorithm Apple uses for Time Machine encrypted volumes is AES-XTS-128 (XEX-based Tweaked Codebook Mode with Ciphertext Stealing). The acronyms hide a fairly elegant idea: it is AES, but applied per-sector with a tweak derived from the sector index, so that two identical sectors at different positions on the disk encrypt to different ciphertexts.

Why XTS specifically, instead of something like CBC or GCM that you might recognize from network protocols?

• No per-sector IV needed. The sector index serves as the tweak, so storage cost is zero. With CBC you would need to store an IV per sector, eating space.
• Parallelizable. Each sector encrypts independently, so reads and writes can happen in any order at full disk speed.
• Bounded malleability. An attacker who flips bits in the ciphertext can only corrupt within a single block, not propagate. Combined with file system integrity checking, this makes silent tampering very hard.
• No authentication. XTS does not provide MAC authentication, but that is intentional for storage; macOS authenticates at the file system level (APFS checksums) and at the volume header level. For data confidentiality at rest, XTS is the correct choice and is the de facto standard for full-disk encryption everywhere.

Practically: each 4 KB sector on the encrypted Time Machine volume is encrypted with AES-128 in XTS mode using a per-sector tweak based on the sector index. The volume key (the actual AES key) is derived from your passphrase via a key-derivation function with a salt and a high iteration count, then used to derive the sector keys. None of those derivation steps are reversible without the passphrase.

What is Encrypted vs What is Not

Inside the encrypted sparsebundle:

• Encrypted: file contents, file names, directory structure, file metadata (timestamps, permissions, extended attributes, ACLs).
• Encrypted: the file system itself (APFS or HFS+ structures inside the volume).

Outside the sparsebundle, on the destination:

• Not encrypted: the sparsebundle wrapper folder name (typically YourMac.sparsebundle).
• Not encrypted: the size of the sparsebundle and the number of band files.
• Not encrypted: the fact that this is a Time Machine backup (recognizable by structure).

For most threat models the wrapper-level metadata leak is irrelevant. If it matters to your threat model (you do not want the destination operator to know you are storing a backup at all), wrap the SMB connection in a VPN tunnel and use a non-obvious sparsebundle name.

Recovering from a Forgotten Passphrase

The hard truth: there is no recovery without the passphrase. The volume key is derived from the passphrase through a one-way function. There is no escrow with Apple, no recovery key like FileVault offers, no backdoor for support, no way for the cloud provider to help. The encryption works by being mathematically irreversible without the key, and that property does not have an exception for the legitimate user.

What you can try:

• Check the Keychain on every Mac that ever backed up to this destination. The password is cached locally; if any working machine still has the entry, retrieve it via Keychain Access.
• Check your password manager history. If you used 1Password, Bitwarden, or similar, the entry may still exist even if you cannot remember setting it.
• Check any printed records. Strong setups print the passphrase and store it physically.
• If the password was based on a pattern you remember partially, you can attempt a targeted brute force against the sparsebundle using hdiutil in a script. This works only if your search space is small (you remember "it was 12 characters and started with X"). For genuinely random passphrases this is hopeless.

If none of those work, the data is gone. Erase the destination, set up a new encrypted backup with a passphrase you store properly this time, and treat the loss as a forcing function for better key management.

Changing the Passphrase Later

For APFS-based encrypted Time Machine destinations:

1. Mount the encrypted volume by entering the current passphrase.
2. Open Disk Utility.
3. Select the encrypted Time Machine volume in the sidebar.
4. From the menu: File → Change Password. Enter the current passphrase and the new one.

Or from Terminal, for APFS encrypted volumes:

diskutil apfs changePassphrase /dev/diskXsY -user disk

(Replace diskXsY with the device identifier shown by diskutil list.)

For HFS+ Time Machine backups using CoreStorage encryption, in-place passphrase changes are not supported in the UI; the practical path is to start a new encrypted backup with the new passphrase and retire the old one. For network sparsebundles, behavior varies by macOS version; the safest, most predictable approach is again the new-backup approach.

After any passphrase change, immediately update the entry in your password manager and any printed copies. An out-of-date password record is worse than no password record at all.

Encrypted Backups Over a Network: Stacking Layers

When your encrypted Time Machine destination is a network share (NAS or cloud), two encryption layers stack:

• Time Machine encryption (AES-XTS at rest): applied by your Mac before any data hits the network. The destination only ever stores ciphertext.
• SMB3 encryption (AES-128-GCM in transit): applied to all SMB traffic between your Mac and the server. Even the already-encrypted Time Machine blocks travel inside another encrypted tunnel.

The result is genuinely zero-knowledge from the destination operator's perspective: they hold ciphertext that they cannot decrypt, and they cannot even observe the plaintext as it lands because they only ever receive ciphertext over the wire. This is the model used by Capsule Backup and is the reason cloud Time Machine can credibly claim end-to-end encryption. For the protocol-level details, see the SMB3 explainer; for the broader security context, see our security page.

Common Pitfalls

Mounting the sparsebundle without entering the passphrase

If you mount the sparsebundle on a different Mac without entering the passphrase, you will see the wrapper but not the contents. The encrypted volume inside refuses to mount and Disk Utility shows it as "not mounted". The fix is to enter the passphrase via the prompt that should appear; if no prompt appears, double-click the sparsebundle file directly.

Using the login password as the Time Machine password

Convenient. Catastrophic. One leak compromises both your live system and your backup. Use distinct passphrases generated by a password manager.

Sharing the backup disk between users

Time Machine encryption is keyed to the passphrase, not to a user. If two people share a single encrypted backup destination by sharing the passphrase, they each have full access to all data inside. Use separate destinations (or separate sparsebundles) for separate trust boundaries.

A password hint that is too informative

"Same as work email" or "the cat's birthday" undoes the work of choosing a strong passphrase. The hint is visible to anyone who attempts to mount the volume. Treat it as if the attacker will read it.

Not testing the restore

Encryption increases the cost of a failed restore: a backup you cannot decrypt is dead weight. Test the restore path quarterly. Mount the encrypted volume on a different Mac, enter the passphrase, restore one random file. If the test fails, you find out now instead of in a real emergency. Our restore guide covers the full procedure.

Reusing passphrases across backup destinations

If you have multiple Time Machine destinations (local USB, cloud, second NAS), use distinct passphrases for each. A leak of one then does not compromise the others. The marginal pain is one password manager entry per destination.

Best-Practices Checklist

Print this. Stick it next to your monitor.

• Encryption enabled on every Time Machine destination, no exceptions.
• Passphrase generated by a password manager, 16+ characters, fully random.
• Passphrase stored in the password manager AND in a physical printed copy.
• Distinct passphrase for each destination.
• Distinct passphrase from the FileVault password, the login password, and the SMB share password.
• Hint either skipped or worded so it tells you nothing the attacker would not already know.
• Quarterly restore test on a different Mac to confirm the passphrase works.
• Keychain entry confirmed on the primary Mac so day-to-day backups do not prompt.
• For network destinations, SMB3 encryption confirmed (read the SMB3 explainer for verification).
• For cloud destinations, the destination understood as zero-knowledge: provider holds only ciphertext.

Putting It All Together

Encrypted Time Machine is one of those rare cases in computing where the right answer is also the easy answer: check one box during setup, store the passphrase properly, and you have a backup that resists nearly every realistic attacker. The cost is essentially zero on modern hardware. The benefit is that the worst day of your computing life (drive failure, theft, ransomware) does not become the second-worst day too.

If you are setting up a fresh Time Machine destination today, do it encrypted from the start. If your current backup is unencrypted, schedule the migration for this week. The path from "no encrypted backup" to "encrypted backup, passphrase stored properly, restore tested" is about an evening's work. Get started here, or jump straight to our pricing page if you need a cloud destination.