Laptops get left in taxis, phones get dropped on trains, and bags get stolen from cars. You cannot prevent every loss, but you can make sure a lost device is an inconvenience rather than a data breach. Device encryption is the control that does that, and it is among the cheapest in security.

What Encryption Does and Does Not Do

Full-disk encryption scrambles everything stored on a device so it can only be read after the correct sign-in or key is provided. If someone steals a powered-off, encrypted laptop and removes the drive, they see unreadable data.

It protects against: loss or theft of the device, and someone reading the storage directly.

It does not protect against: malware running on an unlocked machine, a user who is signed in and walks away, phishing that steals credentials, or data you have already copied somewhere unencrypted. Think of it as one layer, an essential one, not a complete answer.

In practice, strength depends on the sign-in. A device encrypted but protected by a weak or absent password is barely protected. Pair encryption with a strong passcode or password and automatic screen locking.

The Basics by Device Type

Every major operating system includes a built-in encryption feature, and names and defaults change between versions, so check the vendor’s current documentation for exact steps.

• Windows laptops: a built-in drive encryption feature is available on many editions; management tools can enforce and report on it.
• Mac laptops: a built-in disk encryption feature is available and is commonly managed through device management.
• Linux laptops: disk encryption is typically chosen during installation; enabling it afterwards is harder.
• iPhones and iPads: data is generally encrypted once a passcode is set.
• Android phones: modern versions generally encrypt storage by default with a screen lock set, though behavior varies by manufacturer and version.
• Removable media: USB drives and external disks need encryption turned on separately.

The common thread: a screen lock must be enabled, and encryption must be confirmed, not assumed.

Verify, Do Not Assume

Telling people to turn encryption on is not a control. A control is knowing which devices are protected. Use these approaches in rough order of strength:

Method	What it tells you	Limitation
Device management with a compliance policy	Reports and enforces status centrally	Requires enrolling devices
Conditional access tied to compliance	Blocks unprotected devices from company data	Needs identity and management integration
Manual spot checks	Confirms status on sampled devices	Doesn’t scale; easy to forget
Self-attestation form	Records staff statements	Relies on honesty and accuracy
Vendor-built reporting	Per-device status in a dashboard	Varies by operating system

If you don’t have a management tool, even a one-page checklist walked through at onboarding is better than nothing. Just record who checked what and when.

Recovery Keys: The Part Everyone Forgets

Encrypted devices have recovery keys for when the usual sign-in fails. If a laptop’s hardware changes or an employee forgets their password, the recovery key is the way back in. Without it, the data may be gone for good. That is the point of encryption, and also its main operational risk.

Decide before rollout:

1. Where recovery keys are stored. Ideally in a central, access-controlled location such as your device management or identity system, not in a personal note.
2. Who can retrieve them. A small group, with logging.
3. How a user proves who they are before getting help.
4. What happens at offboarding when a device is returned.

Never store the recovery key on the device it unlocks, and never in an unprotected shared spreadsheet.

A Hypothetical Example

A consultant leaves a work laptop on a train. The company’s policy requires encryption and a screen lock, and device management shows the laptop reported as compliant last time it checked in. The administrator remotely disables the user’s sessions, revokes the device’s access, and, if the tooling supports it, issues a remote wipe instruction.

Contrast that with the same loss on an unencrypted laptop holding a local client folder. Now the question is whether regulators or clients must be notified, which requires legal advice and depends on jurisdiction. Encryption often changes that answer, though not always, so confirm with counsel rather than assuming.

Pair It With Related Controls

• Strong sign-in and automatic lock after a short idle time
• Remote lock and wipe capability for phones and laptops
• Mobile device rules for personal phones that access company email, such as a required passcode
• Keeping sensitive files in managed cloud storage rather than scattered across local folders
• Prompt updates, since some attacks bypass protections on outdated systems

Mistakes to Avoid

• Encrypting devices but never testing recovery
• Storing recovery keys in the same place as the data
• Skipping removable drives and backup disks
• Exempting executives because it is “inconvenient”
• Assuming the phone is encrypted because it is new

Frequently Asked Questions

Does encryption slow down a laptop? On modern hardware the effect is usually small and often unnoticeable. If performance is a concern on older machines, test before rolling out broadly.

Is a login password enough without disk encryption? No. A password protects the operating system session, but someone can often remove the drive and read it elsewhere unless it is encrypted.

What if an employee forgets their password? Your recovery process handles it. That is why storing and controlling recovery keys is part of the rollout.

Do we need to encrypt desktops that never leave the office? It is still sensible, since theft, disposal and repair all create exposure. Treat it as a standard.

Does encryption satisfy compliance requirements? It frequently supports them but rarely satisfies them alone, and requirements vary by jurisdiction and framework. Consult a qualified professional for your obligations.

Next Step

Take ten devices, including a couple of personal phones that read work email, and check the encryption and screen-lock status on each. The gaps you find tell you whether you need a policy, a tool, or both.