Mac Backup Encryption Explained: Time Machine, FileVault, SMB3, and Why You Need All Three

The word "encrypted" carries a comforting heft, the kind that makes people stop asking follow-up questions. Most users see a checkbox labeled "Encrypt backup" and assume it means safe, full stop. It does not. Encryption only protects against specific threats, and a Mac with a backup involves at least three different encryption layers, each defending against a different kind of attacker.

Skip any one of them and you leave a hole. The three layers are FileVault on the source disk, Time Machine encryption on the backup disk, and SMB3 encryption on the wire when the backup is over a network. This article walks through each, explains exactly what it protects against and what it does not, and finishes with a threat-model table you can use to audit your own setup.

The Three Layers in One Sentence Each

• FileVault encrypts the data sitting on your Mac's internal disk, so a thief who powers it on cannot read the drive without your password.
• Time Machine encryption encrypts the backup itself, so a thief who steals your USB drive (or a cloud provider whose servers are compromised) cannot read your files.
• SMB3 encryption encrypts the data while it is moving over the network, so an attacker between your Mac and the backup server cannot eavesdrop.

None of them substitute for the others. Each defends against a different threat. You want all three.

Layer 1: FileVault, At Rest on the Source

FileVault is the disk-level encryption built into macOS. When enabled, the entire macOS startup disk is encrypted with XTS-AES-128 using a 256-bit key. The key is derived from your login password and (on modern Macs) sealed inside the Secure Enclave, a dedicated security chip on Apple Silicon and on the T2 chip in recent Intel Macs.

What FileVault protects against

• Lost or stolen MacBook, powered off. The thief sees an encrypted blob. Without your password (or your recovery key), the data is mathematically inaccessible.
• Disk pulled out of the Mac. Even with the disk attached to another machine, the contents are encrypted at the block level.
• Disposal of an old Mac. Wiping the encryption key (which macOS does on Erase All Content and Settings) instantaneously renders the data unrecoverable.

What FileVault does not protect against

• A Mac that is powered on and unlocked. Once you have logged in, the volume is mounted in the clear from the OS's perspective. Malware running with your privileges sees plaintext.
• A Mac in sleep with FileVault not actively re-locked. Hibernation files can in theory leak keys; modern macOS mitigates this but the threat is non-zero.
• The backup itself. FileVault protects the source disk, not the destination. If your Time Machine backup is unencrypted, the data is plain on the backup drive even when the Mac is locked.

The recovery key

When you enable FileVault, macOS asks whether to escrow the recovery key with iCloud or to store it locally. Locally is more private (Apple cannot decrypt your disk on legal request) but riskier (lose it and the data is gone). iCloud is more convenient but means Apple holds a key. There is no objectively correct choice; it depends on your threat model. Whatever you pick, store the recovery key somewhere physical too, like a printed page in a safe.

Layer 2: Time Machine Encryption, At Rest on the Backup

When you check "Encrypt Backup" while setting up a Time Machine destination, macOS creates the backup as an encrypted volume using AES-XTS-128. The encryption password you provide is used to derive the volume key. The key is stored in your local Keychain so subsequent backups happen automatically without re-prompting.

The encrypted backup lives inside a sparsebundle (a folder of "band" files that together form a virtual disk) on the destination. The sparsebundle wrapper itself is plaintext, but everything inside it (file contents, file names, directory structure, metadata) is encrypted as a CoreStorage or APFS volume.

What Time Machine encryption protects against

• Stolen backup drive. A thief who walks off with your USB SSD sees ciphertext.
• Cloud server compromise. If your backup lives on a cloud SMB share, the provider only ever stores encrypted blocks. Even a malicious admin or a server-side breach reveals nothing without your password.
• Subpoena or legal request to a backup provider. The provider has no plaintext to hand over. They can produce ciphertext, which is useless without the key, and the key never leaves your Mac. This is what people mean when they call a setup "zero-knowledge".
• Disposal of old backup hardware. Reformatting an unencrypted backup drive does not actually erase the data immediately (only marks it as deleted); an encrypted volume that has lost its key is effectively erased on the spot.

What Time Machine encryption does not protect against

• An attacker who has both the backup and your encryption password. Encryption is only as good as the secrecy of the key.
• Ransomware on the source Mac that has access to the backup share. If the backup share is mounted and writable, ransomware can encrypt or delete its contents. Encryption protects confidentiality, not integrity or availability.
• Network eavesdropping during the backup. The encrypted blocks have to travel over the network somehow; if the transport is in the clear, an attacker on the path can collect ciphertext for offline brute-force attempts. Hence SMB3.

Layer 3: SMB3 Encryption, In Transit

SMB3 is the network protocol that macOS uses to talk to network file shares. Starting with SMB 3.0 (2012) the protocol supports session-level encryption using AES-128-CCM; SMB 3.1.1 (2016) added AES-128-GCM, which is what modern macOS negotiates by default with capable servers.

What SMB3 encryption protects against

• Hostile café Wi-Fi. An attacker on the same network cannot read your traffic.
• ISP-level snooping. Your ISP can see that you are talking SMB to a particular IP, but cannot read the file contents.
• Compromised intermediate hardware. A man-in-the-middle on the path between your Mac and the backup server sees only ciphertext at the SMB layer.
• Tampering in transit. SMB3 also signs traffic, so an attacker cannot inject or modify data without breaking the signature.

What SMB3 encryption does not protect against

• The server itself. SMB3 is hop-by-hop: client encrypts, server decrypts. The server sees plaintext at the SMB layer (which is why you also want Time Machine encryption underneath).
• Anything once it lands on the destination. Once written to disk, SMB3 has done its job and is no longer involved.
• A server that does not actually negotiate SMB3 encryption. Some older NAS devices and certain budget hosts only advertise SMB1 or unencrypted SMB2. macOS will fall back if you let it. Read the SMB3 explainer for the negotiation details and how to verify.

Where the Keys Actually Live

Understanding where each key lives helps you reason about what an attacker would need to compromise to break each layer.

• FileVault key: derived from your login password, sealed in the Secure Enclave on Apple Silicon and T2 Macs. Recovery key escrowed with iCloud or printed.
• Time Machine encryption key: derived from the encryption password you chose during setup. Cached in your local Keychain so subsequent backups do not prompt. The key never leaves your Mac.
• SMB3 session key: negotiated fresh per session via Diffie-Hellman style key exchange. Lives only in RAM on your Mac and on the server for the duration of the connection.

Threat-Model Table

Here is the practical view: which threats does each layer actually defend against?

Threat	FileVault	TM Encryption	SMB3
Stolen MacBook (powered off)	Yes	No	No
Stolen backup drive	No	Yes	No
Hostile café Wi-Fi	No	Partial	Yes
Compromised cloud provider admin	No	Yes	Partial
Subpoena to backup provider	No	Yes	No
Ransomware that targets backups	No	No	No
Lost MacBook, screen unlocked	No	No	No
Disposal of old backup drive	No	Yes	No

A few rows here matter more than the others. The "ransomware that targets backups" row is "No" across the board because confidentiality encryption does not address availability. The defense against ransomware is versioned snapshots plus an offline or write-protected copy, not encryption. The "lost MacBook, screen unlocked" row reminds you that any threat model assuming the device is in the attacker's hands while logged in defeats every cryptographic layer because the OS itself is decrypting in real time.

Why All Three Together

Now run the table again with only one layer enabled.

If you have FileVault but no Time Machine encryption: a thief who steals your backup drive (often kept in the same room as the Mac) has full access to everything. If your backup is in the cloud, anyone who compromises the cloud provider has full access.

If you have Time Machine encryption but no FileVault: a thief who powers on your stolen MacBook has full access to your live data. The backup is safe; the source is not.

If you have both at-rest layers but no SMB3 in transit: an attacker on a coffee-shop Wi-Fi network can capture your ciphertext, sure, but they can also potentially capture metadata, traffic patterns, and any unencrypted protocol layers above SMB. Not catastrophic, but you have given up the easy hardening.

You want all three. They are individually cheap. Together they cover essentially every threat short of "attacker has root on your unlocked machine", and against that no encryption helps anyone. For details on how Capsule Backup composes these layers in the cloud-Time-Machine context, see our security page.

How to Enable Each Layer

FileVault

System Settings → Privacy & Security → FileVault → Turn On. Choose iCloud or local recovery key. Wait for initial encryption to complete (modern Macs do this in the background while you work; older Macs may take hours).

Time Machine encryption

System Settings → General → Time Machine → Add Backup Disk. When prompted, check "Encrypt Backup". Set a strong password (16+ characters from a password manager is ideal). For a deep dive on the setup, password choice, and recovery, see the encrypted backups guide.

SMB3 encryption

Mostly automatic on modern macOS connecting to a modern SMB server. To require it explicitly, edit /etc/nsmb.conf:

[default]
signing_required=yes
smb_neg=smb3_only

This forces SMB3 negotiation and rejects fallback. Use this on a corporate Mac or anywhere you cannot afford a silent downgrade. For the protocol details and how to verify, see the SMB3 explainer.

Common Mistakes

• Reusing the login password as the Time Machine password. One leak compromises both layers. Use distinct passwords from a password manager.
• Not storing the recovery key or encryption password somewhere physical. If your Mac dies and the password was only in its Keychain, the backup becomes a paperweight.
• Trusting "the backup is in the cloud, so it must be encrypted". Many cloud backup tools encrypt on the server side with provider-held keys, which means the provider can decrypt. That is meaningfully weaker than client-side encryption with user-held keys. Always check the threat model.
• Forgetting the integrity threat. Encryption protects confidentiality, not availability. Pair encryption with versioned snapshots (Time Machine does this) plus an offline or off-site copy. Business users in particular should plan around ransomware too.
• Single-layer thinking. "I have FileVault, I am secure" is the most common mistake in this list. Re-read the threat-model table.

Bonus Layer: VPN as a Wrapper for SMB

SMB3 over the open internet works, but some users prefer to wrap the connection in a VPN tunnel as well. WireGuard is the modern choice (fast, small, audited); OpenVPN is the older standard. The VPN encrypts the SMB3 traffic again with another layer of keys, which mostly buys you defense in depth and a single chokepoint for network policy. It does not replace any of the three core layers; it adds a fourth.

For most users on a plain home or office network, SMB3 alone is sufficient. For users on shared, hostile, or untrusted networks (conferences, hotels, co-working spaces), a VPN is a worthwhile addition. Compared with proprietary cloud sync solutions like iCloud or Backblaze, the cloud-Time-Machine model with three encryption layers gives you stronger guarantees about who can read your data.

Summary

Encryption is not a single switch. It is a stack of three cooperating layers:

• FileVault defends against device loss.
• Time Machine encryption defends against backup compromise (and is what makes a cloud backup actually private).
• SMB3 defends against network observation during transfer.

Enable all three, store the keys safely, and you have a backup architecture that resists realistic attackers without needing custom tooling.