Device encryption is one of the most important security features on modern phones and computers, and most people do not know whether it is turned on. It is also widely misunderstood as a complete security solution when it is actually a specific protection against a specific threat: physical access to your device. Understanding what device encryption does and does not protect against is the difference between actual security and a false sense of it.
What Device Encryption Is
Device encryption, also called full-disk encryption (FDE) or full-volume encryption, encrypts the entire storage volume on a device. Every file, every application, every piece of data on the disk is encrypted with a key that is derived from your device passcode or password. When the device is locked, the encryption key is not readily available, and the data on the disk is unreadable without it.
The critical detail is when the key is available. On a phone with a strong passcode, the encryption key is protected by a hardware-secured enclave (Secure Enclave on iOS, Titan M on Google Pixel, TrustZone on other Android devices) that enforces a delay between passcode attempts. Even if someone removes the storage chip and reads it with specialized equipment, they get encrypted data. To decrypt it, they need the passcode, and the hardware limits how fast they can guess it.
On a laptop, the model is similar but the hardware protection varies. Apple Silicon Macs and modern Windows devices with TPM 2.0 chips provide hardware-backed key protection. Older devices without these chips are more vulnerable to physical attacks.
How Device Encryption Works by Platform
| Platform | Feature | Default Status | Hardware Protection | | --- | --- | --- | --- | | iOS (iPhone/iPad) | Automatic encryption | Enabled by default (since iOS 8) | Secure Enclave | | Android | File-Based Encryption (FBE) | Enabled on most new devices (since Android 6) | Titan M / TrustZone | | macOS | FileVault | Not enabled by default | Secure Enclave (Apple Silicon) / T2 chip | | Windows 11 | BitLocker | Enabled on new installs with TPM 2.0 | TPM 2.0 | | Windows 10 | BitLocker | Not enabled by default | TPM (if present) | | Linux | LUKS | Not enabled by default (varies by distro) | Varies (TPM optional) |
### iOS
iOS has had automatic encryption since iOS 8 (2014). Every iOS device with a passcode has its storage encrypted. The encryption is tied to the passcode through the Secure Enclave, which enforces escalating delays between incorrect guesses. After enough failed attempts, the device erases itself (configurable). This makes brute-forcing a strong alphanumeric passcode impractical — each guess takes seconds to hours depending on the attempt count.
### Android
Android has required file-based encryption (FBE) on new devices since Android 7.0, with full-disk encryption required since Android 6.0 on most hardware. FBE is an improvement over FDE because it encrypts files individually with different keys, allowing the device to boot to a limited state (showing alarms and notifications) without decrypting all user data. Google Pixel devices use the Titan M security chip for hardware-backed key protection, similar to Apple's Secure Enclave.
### macOS
FileVault is Apple's full-disk encryption for Mac. It is available on all Macs but is not enabled by default. You must turn it on in System Settings > Privacy & Security > FileVault. Apple Silicon Macs and Intel Macs with the T2 chip use hardware-accelerated encryption with keys protected by the secure enclave. On older Macs, FileVault still works but with weaker hardware protection. Enable FileVault on every Mac you own.
### Windows 11
Windows 11 requires TPM 2.0 and enables BitLocker device encryption by default on new installations, though this depends on hardware support and edition (Home vs Pro). BitLocker uses the TPM to seal the encryption key, releasing it only during a verified boot process. If the TPM detects tampering (different boot loader, modified firmware), it will not release the key. Check Settings > Privacy & security > Device encryption to confirm it is on.
### Windows 10 and Linux
Windows 10 does not enable BitLocker by default, and the Home edition does not include BitLocker at all (it offers a more limited "device encryption" feature). Linux distributions offer LUKS (Linux Unified Key Setup) for full-disk encryption, typically as an option during installation. If you did not select encryption during install, your Linux drive is not encrypted.
What Device Encryption Protects Against
Device encryption protects against one primary threat: physical access to your powered-off or locked device. Specifically:
Device theft. If someone steals your laptop or phone and tries to read the storage, they get encrypted data. Without your passcode or password, the data is unreadable. This is the scenario device encryption was designed for, and it works well against it.
Forensic extraction. Law enforcement or attackers using forensic tools (Cellebrite, GrayKey) that attempt to read storage directly are thwarted by encryption. The effectiveness depends on passcode strength and hardware protections — a 4-digit PIN can be brute-forced, but a strong alphanumeric passphrase cannot.
Lost devices. If you lose your phone on a train, the person who finds it cannot access your data without your passcode. Device encryption turns a data breach into a hardware loss.
What Device Encryption Does Not Protect Against
Device encryption is a specific protection, not a comprehensive one. It does not help with:
Cloud breaches. If you sync photos to iCloud, documents to Google Drive, or backups to Dropbox, device encryption does not protect that data. The cloud provider holds the encryption keys (unless you use client-side encryption). A breach of the cloud provider exposes your data regardless of your device encryption. Read our guide on encrypting files before cloud storage upload to address this gap.
Email and messaging interception. When you send a file by email or messaging app, device encryption does not protect it in transit or on the recipient's device. The file exists in readable form on mail servers, in backups, and on the recipient's unencrypted storage. Use file-level encryption before sharing.
Malware on your device. If your device is infected with malware, the malware runs with your privileges and can access your data in its decrypted form. Device encryption does not help because the data is accessible while the device is unlocked. This is why malware prevention (not clicking suspicious links, keeping software updated) matters independently of encryption.
Shared files. When you share a file with someone, the shared copy is typically unencrypted. Even if your device is encrypted, the copy you shared is not. The recipient's device may or may not be encrypted. For sensitive shared files, encrypt the file itself before sharing — see our file encryption guide.
Phishing and social engineering. If you are tricked into entering your credentials on a fake website, device encryption is irrelevant. The attacker gets your credentials directly. No encryption protects against voluntarily surrendering your secrets.
Cold Boot Attacks and Evil Maid Scenarios
Device encryption has known physical attack vectors that are worth understanding if you have a high-value threat model.
### Cold Boot Attacks
When a computer is powered on, the encryption key is stored in RAM. RAM retains its contents briefly after power is cut — seconds to minutes at room temperature, longer if cooled with liquid nitrogen or compressed air. A cold boot attack involves rapidly rebooting the computer from an external device and dumping the RAM contents to extract the encryption key.
This attack is more practical against laptops than phones, and more practical against devices without hardware-backed key protection (older Macs, PCs without TPM, Linux without TPM integration). Modern devices with secure boot chains and hardware key stores mitigate this by clearing RAM on tamper detection or storing keys only in secure hardware.
### Evil Maid Attacks
An evil maid attack involves an attacker with brief physical access to your device who modifies the boot process or installs a hardware keylogger. For example, an attacker boots your laptop from a USB drive, installs a bootloader modification that captures your BitLocker PIN, then returns the laptop. When you type your PIN next, the attacker captures it.
Mitigations include secure boot (which verifies the boot chain cryptographically), TPM sealing (which refuses to release the key if the boot environment has changed), and using a pre-boot PIN in addition to the TPM. The symmetric encryption behind these protections is sound — the vulnerability is in the physical boot process, not the cryptography.
When You Need File-Level Encryption Too
Device encryption is your baseline. File-level encryption is what you need when files leave the device. Use the file encryptor in addition to device encryption when:
You are emailing or messaging a sensitive file. The file must be encrypted independently of the device so it remains encrypted on mail servers, in transit, and on the recipient's device.
You are uploading to cloud storage. Encrypt the file before upload so the cloud provider cannot read it. This is client-side encryption and it is the only way to ensure your cloud-stored data is truly private.
You are sharing a USB drive or external storage. External drives are not covered by device encryption. Encrypt files before copying them, or encrypt the external drive itself.
You are storing particularly sensitive files on your device. Device encryption protects data when the device is locked, but not when you are logged in and the file is open. File-level encryption adds a second layer for your most sensitive documents.
The Bottom Line
Device encryption is necessary but not sufficient. Turn it on — FileVault on Mac, BitLocker on Windows, confirm encryption is active on your phone. But understand that it protects against physical theft, not against the myriad ways your data leaves your device. For files that travel — through email, cloud storage, messaging, or physical media — encrypt the files themselves with AES-256 before they leave. Device encryption is the floor, not the ceiling. For a deeper understanding of the encryption that powers both device and file encryption, read our AES-256-GCM explainer and our guide to sending confidential files securely.
