Encryption and What It Does Not Do
The control most relied upon in compliance answers, what it actually protects against, and the three cases where it does nothing.
Policy · Explainer
Device encryption is the first thing named in any security questionnaire. It is genuinely valuable and the protection is narrower than the confidence it inspires.
The practical question in “Encryption and What It Does Not Do” is how to make work visible without confusing visibility with certainty. For teams researching cognitive offloading, this resource can add time and project context to the operational record, provided its use is proportionate, disclosed and reviewed with the people affected.
What it protects against
A device that is lost or stolen while powered off or locked.
For an independent baseline relevant to “Encryption and What It Does Not Do”, the OWASP Mobile Application Security is a useful companion: compare its principles with the proposed configuration, ownership model and real support process before approving a rollout.
Somebody removing the storage and reading it elsewhere.
Disposal without proper erasure, which is the underrated case.
In each, the data is unreadable without the key, which is tied to the passcode.
What it does not protect against
A device that is unlocked. Encryption is irrelevant while the user is signed in, which is most of the time.
Malicious software running as the user, which sees decrypted data by definition.
Anybody who knows the passcode, including over a shoulder.
And data that has already left the device, which is most data.
The passcode dependency
Encryption without a passcode is close to no encryption on most platforms, because the key is available.
Which is why the two settings travel together and why a weak passcode undermines the encryption claim.
Saying "the device is encrypted" without saying "and a passcode is enforced" is an incomplete answer.
Modern defaults
Current mobile platforms encrypt by default and have for years.
Which means the management setting frequently verifies rather than enables.
That is still worth doing — verification is the point — and it should be described accurately rather than as though you turned it on.
Desktops
Different: encryption may not be on by default, and recovery key handling becomes a real operational concern.
A recovery key stored only on the device is not a recovery key.
Escrow it in the management platform and test retrieval, because the first time you need it should not be the first time you try.
The disposal case
The strongest practical argument.
An encrypted device that is wiped or simply has its key destroyed is unreadable without physical destruction.
Which makes disposal cheaper and safer, and is worth stating in the policy because it is the benefit nobody mentions.
What to claim
"Devices are encrypted, with passcode enforcement, verified by management, and recovery keys held in escrow."
Checkable, complete, and it does not overstate.
Rather than "our devices are encrypted", which answers a questionnaire and not a risk.
What to check
Is passcode enforcement applied everywhere encryption is claimed?
Are desktop recovery keys escrowed, and has retrieval been tested?
Does your disposal process rely on encryption, and is that written down?
And does your compliance answer mention the passcode dependency?