iOS encrypts files at rest, but how well a given file is protected depends on a setting most developers never touch: its Data Protection class. The class decides when the file can be decrypted, only while the device is in use, or essentially always while it is powered on, and the default is not the strongest option. For sensitive data, choosing a stronger protection class means that if the device is lost or stolen while locked, the file stays encrypted and unreadable. Here is what iOS Data Protection is, the protection classes, and how to use them for sensitive files.
Short answer
iOS Data Protection encrypts files at rest using keys tied to the device passcode and hardware, and the NSFileProtection class on a file controls when it can be decrypted. Per Apple's documentation, the strongest class keeps a file encrypted and inaccessible while the device is locked, the default keeps it accessible after the user first authenticates following a reboot, and the weakest leaves it readable whenever the device is powered on. For sensitive files, set a stronger protection class rather than the default or none, and require a device passcode, since Data Protection depends on it. Then a lost or locked device keeps the protected data encrypted.
What you should know
- Files are encrypted at rest: with keys tied to the passcode and hardware.
- The protection class sets timing: when the file can be decrypted.
- The default is not the strongest: it allows access after first authentication.
- A passcode is required: Data Protection depends on the device passcode.
- Use a stronger class for sensitive files: not the default or none.
What is iOS Data Protection?
It is the system that encrypts files on the device using per-file keys derived from the device passcode and the hardware. Because the keys are tied to the passcode and the device's secure hardware, the encryption is meaningful only when a passcode is set, which is why Data Protection effectively depends on the user having one. The part developers control is the Data Protection class assigned to a file, which determines under what conditions the system will decrypt it: only while the device is in use, or more permissively. So Data Protection is always present, but how strongly a particular file is protected is a choice, and leaving everything at the default or, worse, the weakest class means sensitive data may be decryptable in situations where it should not be, such as while the device sits locked in someone else's hands.
What are the file protection classes?
Four classes, from strongest to weakest. The table summarizes them.
| Protection class | When the file is accessible |
|---|---|
| Complete | Only while the device is in use; encrypted while locked |
| Complete Unless Open | Accessible while locked only if already open |
| Complete Until First Authentication (default) | After the user first authenticates following a reboot |
| None | Whenever the device is powered on |
The default class keeps a file accessible after the user authenticates once following a reboot, which suits files your app needs in the background, but it is not the strongest, since the file can be read while the device is locked after that first authentication. The Complete class is the strongest, keeping the file encrypted and unreadable whenever the device is locked, which is what you want for the most sensitive data. The None class provides the least protection and should not be used for anything sensitive.
How do you protect sensitive files?
Assign a stronger protection class and ensure a passcode is in place. For files holding sensitive data, set a protection class stronger than the default, ideally Complete, so the file is encrypted and inaccessible while the device is locked, which protects it if the device is lost or stolen in that state. Reserve the default, accessible after first authentication, for data your app genuinely needs while running in the background, and avoid the None class for anything sensitive. Remember that Data Protection's strength comes from the passcode, so the protection is only as good as the device being passcode-protected. And for small secrets like tokens and keys, the Keychain with an appropriate accessibility level is still the right place, with Data Protection covering larger files your app writes. The aim is that sensitive files are not decryptable while the device is locked.
What to watch out for
The first trap is leaving sensitive files at the default protection class, which allows access while the device is locked after the first authentication; use the Complete class for the most sensitive data. The second is using the None class for anything sensitive, which offers the least protection. The third is assuming Data Protection helps without a passcode, when its keys depend on one. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled IPA against OWASP MASVS and assesses how your app stores data, including data protection on files, so you can confirm sensitive files use a strong protection class before you ship. Setting the class on your files is the change you make in the app.
What to take away
- iOS Data Protection encrypts files at rest with keys tied to the device passcode, and the NSFileProtection class controls when each file can be decrypted.
- The strongest class, Complete, keeps a file encrypted while the device is locked; the default allows access after first authentication; None offers the least protection.
- For sensitive files, set a stronger protection class than the default, avoid None, and remember the protection depends on the device having a passcode.
- Keep small secrets in the Keychain, and use a pre-submission scan such as PTKD.com to confirm sensitive files use a strong data-protection class.
