What Is Endpoint Encryption, and Why Does It Keep Getting Confused with Everything Else?

You have probably seen "encrypted" on a vendor's marketing page and nodded along without asking a follow-up question. That is exactly the problem. If you want to understand what is endpoint encryption, you first need to separate it from two other encryption categories that get mashed together in sales copy: encryption in transit and encryption at rest. They protect different things, at different times, against different threats. Mixing them up is not a terminology nitpick. It is a gap that attackers walk through.

Key Takeaways

• Endpoint encryption is centrally managed, device-level encryption that renders stored data unreadable if the hardware is lost, stolen, or physically compromised. It is not the same as transport-layer encryption (TLS) or at-rest encryption on a remote server.
• Three layers of encryption exist: at rest (disk/database), in transit (network pipe), and end-to-end (sender to recipient, excluding the service provider). Endpoint encryption overlaps primarily with at-rest, but adds a management and policy layer specific to the device.
• Encryption does nothing once data is decrypted in memory. Malware, keyloggers, and infostealers operate in that gap. Endpoint encryption is necessary but not sufficient.
• Adoption is still surprisingly low: roughly half of organizations encrypt sensitive data on their devices. The other half is relying on hope.
• Regulatory frameworks like HIPAA treat encryption as "addressable" rather than mandatory, yet a stolen encrypted device with no key compromise is not even reportable as a breach under HHS rules. The incentive structure is clear, even if the mandate is not.

What actually counts as endpoint encryption?

Endpoint encryption means applying encryption at the device level, typically through centrally managed software that an IT team deploys across laptops, workstations, phones, and tablets. The goal: if someone walks out of an office with a hard drive, or a laptop gets lifted from a hotel room, the data on that disk is unreadable without the correct key. Organizations typically pair this with key escrow and centralized reporting, so authorized staff can still recover data while the encryption stays resistant to misuse.

Common implementations include Full Disk Encryption (FDE), where the entire volume is encrypted transparently, and Self-Encrypting Drives (SEDs), where the encryption logic lives in the drive's firmware. On the database side, Transparent Data Encryption (TDE) handles similar work for structured stores. These are all at-rest mechanisms, but what makes them "endpoint" encryption specifically is the management wrapper: policy enforcement, compliance reporting, remote wipe capability, key lifecycle.

Without that management layer, you just have disk encryption. With it, you have endpoint encryption. The distinction matters when you are auditing a fleet of 500 devices and need to prove every one of them is covered.

How is endpoint encryption different from encryption in transit?

They protect data at completely different points in its lifecycle. Encryption in transit protects data while it moves between two points over a network. Think TLS, the protocol your browser uses when you see the padlock icon. The endpoints perform a handshake, agree on a protocol, exchange keys, and create a secure channel that prevents interception of the data in flight.

Endpoint encryption, by contrast, does not care about the network at all. It cares about the disk. If you turn the machine off and hand it to a stranger, can they read what is on it? That is the question endpoint encryption answers. Transport encryption answers a different question: if someone is sitting on the same Wi-Fi as you, can they read the packets you are sending to a server?

Both matter. Neither substitutes for the other. A laptop with full disk encryption that sends unencrypted HTTP traffic is protected against theft but exposed on the wire. A machine using TLS for every connection but storing files in plaintext on an unencrypted volume is safe in transit but vulnerable the moment someone pries the SSD out.

Where does encryption at rest fit in?

Encryption at rest is the broader category. It means making stored data unreadable when it is not actively being used, whether that storage is a local disk, a cloud volume, a database, or a backup tape. Endpoint encryption is a subset of encryption at rest, scoped to the device layer and wrapped in management tooling.

When a cloud provider says "your data is encrypted at rest," they usually mean they encrypt the storage volumes in their data centers. That is useful. It means a rogue data-center technician cannot pull a disk and read your files. But it says nothing about what happens on your laptop, your employee's phone, or the USB drive someone copied a spreadsheet onto before leaving the office.

Endpoint encryption closes that local gap. It is the at-rest encryption you control, on hardware you (or your employees) physically possess.

What about end-to-end encryption? Is that the same thing?

No. End-to-end encryption (E2EE) is a different concept entirely, and it is the one that gets confused with transport encryption most often. TLS secures the network pipe, while true end-to-end encryption structurally excludes the service provider from ever seeing the content.

With transport encryption, data is encrypted between your device and a server, but the server decrypts it to process your request. The service provider can, in principle, read it. With E2EE, the data is encrypted on your device and only decrypted on the recipient's device. The server in the middle handles ciphertext it cannot read.

Endpoint encryption does not address this distinction at all. A device with full disk encryption can still send plaintext to a server over TLS, and that server can still read every byte. Endpoint encryption protects the local copy. E2EE protects the relationship between sender and recipient. They operate at different layers of the stack and solve different problems.

This matters if you are evaluating an AI product, a messaging app, or a file-transfer service. "We encrypt your data" could mean any of these three things. Or all of them. Or, depressingly often, just one, presented in a way that implies the others.

Why should you care which layer is encrypted?

Because the threat model is different for each layer, and a vendor who blurs the boundaries is either confused or hoping you are.

Consider a concrete scenario. An employee's laptop is stolen from a car. If the device has endpoint encryption (FDE with a strong passphrase, no key compromise), the thief gets a brick. Under HIPAA's current framing, that stolen device does not even trigger a reportable breach, because the data is considered inaccessible. That is a real policy distinction with real operational consequences.

Now consider a different scenario. The same employee clicks a phishing link, and malware installs a keylogger. Full disk encryption does nothing here. The disk is decrypted while the OS is running, the malware has access to everything the user does, and the keylogger captures credentials and data in plaintext before any encryption layer touches it. This is the blind spot: encryption provides no defense once malware reaches decrypted data in memory.

Two different threats. Two different protections needed. Knowing which encryption covers which scenario is not academic. It is the difference between a security posture and a security story.

How effective has endpoint encryption been in practice?

There is one dataset that tells the story clearly. In U.S. healthcare, breaches from lost or stolen devices used to be the dominant category. A landmark 2013 case involved four stolen unencrypted computers affecting millions of patient records. By 2025, the total number of endpoint-related breaches had fallen to six incidents, affecting only 24,500 people. In the first half of 2026, no breaches from lost or stolen devices were reported to federal regulators at all. Experts credit improved encryption, cloud adoption, and better endpoint management.

That is a category of breach that has been nearly eliminated. Not through some novel technique, but through consistent application of a technology that has existed for over a decade. The hard part was never the cryptography. It was getting it deployed everywhere, on every device, with no exceptions.

And there are still exceptions. Only about 50% of organizations encrypt sensitive data on their endpoints. Half. In 2026. The technology is mature, the evidence is overwhelming, and half the market has not gotten around to it.

What does this mean for AI products specifically?

AI products introduce a wrinkle that traditional endpoint encryption was never designed to handle: data that must be decrypted for inference.

When you send a prompt to a cloud-hosted AI model, that prompt travels over an encrypted connection (TLS, in transit). It may be stored in an encrypted database afterward (at rest). But at the moment of inference, when the model is actually processing your input, the data exists in plaintext in the server's memory. This is true for essentially every cloud AI product. It is not a flaw specific to any one vendor. It is a consequence of how computation works.

At Selina, we built a privacy-focused AI assistant that remembers you across conversations. Memory is encrypted at rest. Files and transfers through SelinaSEND are end-to-end encrypted, zero-knowledge. But memory is not end-to-end encrypted, because a slice of each request reaches a frontier provider at inference. We state this plainly because the distinction matters, and because vendors who do not state it are hoping you will not ask.

The point for your own evaluation of any AI tool: ask which layers are encrypted, and ask what happens at the moment of processing. "We use AES-256" is a statement about an algorithm, not about a threat model. It tells you roughly as much as "we use locks" tells you about a building's security.

What does the regulatory landscape look like?

Murky, with a clear direction of travel. HIPAA still technically treats encryption as "addressable" rather than strictly mandatory, which means covered entities must implement it or document why they chose an equivalent alternative. In practice, encryption at rest and in transit has become the default operational expectation. The "addressable" label is a regulatory artifact, not a signal that encryption is optional.

The incentive structure reinforces this. An encrypted device that is stolen, with no key compromise, is not a reportable breach. An unencrypted device that is stolen triggers the full breach notification process: HHS notification, potentially media notification, fines, remediation costs. The cost difference between those two outcomes dwarfs the cost of deploying FDE.

Outside healthcare, the pattern repeats. GDPR expects encryption as a technical measure under Article 32. PCI DSS requires it for cardholder data. SOC 2 auditors want to see it. The specific mandates differ, but the direction is the same: encrypt the data, encrypt the pipe, encrypt the device. If you skip the device, you have a gap that regulators and auditors will find.

What threats does endpoint encryption not cover?

Several, and they are worth enumerating plainly.

Malware on a running system. As noted above, once the OS is booted and the disk is decrypted, endpoint encryption provides no barrier to software running with user or root privileges. Ransomware encrypts your files on top of your encryption. Keyloggers capture keystrokes before they reach any encrypted store. Infostealers read browser cookies, credentials, and session tokens from memory. This is the layer where the most damaging endpoint attacks operate.

Unmanaged devices. Endpoint encryption that is centrally managed only covers devices you know about and control. The contractor's personal laptop, the developer's home desktop, the phone an employee bought on their own. If those devices touch sensitive data and are not enrolled in your encryption management, they are unprotected. Reports suggest over 20% of total endpoints in many organizations are unmanaged, which means a fifth of the attack surface has no guarantee of encryption.

Weak key management. Encryption is only as strong as the key management around it. A device with FDE and a four-digit PIN is encrypted in the technical sense and trivially breakable in the practical sense. Key escrow that stores recovery keys in a plaintext spreadsheet is worse than no escrow, because it centralizes the risk. The cryptographic algorithm is rarely the weak link. The operational practices around it almost always are.

Cloud and SaaS data. Endpoint encryption protects data on the device. It does nothing for the copy of that data sitting in a SaaS application's database, in an email server's archive, or in a cloud storage bucket. If you are evaluating your encryption posture, the endpoint is one layer. The cloud is another. They require separate controls.

How should you evaluate an "encrypted" product claim?

Ask three questions. You will get useful answers or evasion, and both are informative.

1. Which layers are encrypted? At rest, in transit, end-to-end, or some combination? A product that says "encrypted" without specifying is either being lazy or deliberately vague. You want specifics: TLS 1.2+ in transit, AES-256 at rest, E2EE for file transfers, whatever the actual implementation is.

2. Who holds the keys? If the service provider holds the decryption keys, then "encrypted" means "encrypted until we decide to decrypt it." That may be fine for some use cases (the provider needs to process the data to deliver the service). It is not fine if you are being told no one can read your data. Key custody is the question that separates marketing from architecture.

3. What happens at the moment of processing? This is the question most vendors hope you will not ask. If data must be decrypted for computation (which it usually must), then there is a window during which it is exposed. The relevant follow-up: how long is that window, what isolation exists around it, and what happens to the decrypted data afterward? Answers like "ephemeral processing" or "short retention window" are more honest than silence.

What about the post-quantum question?

It is real and it is closer than most people think. Encryption standards are shifting due to quantum computing readiness concerns, regulatory mandates, and demand for privacy-preserving computation. The practical impact on endpoint encryption: the symmetric algorithms (AES-256) are relatively quantum-resistant, but the key exchange and management protocols that wrap them may not be.

For most organizations today, the priority is still getting basic endpoint encryption deployed everywhere. But if you are building systems with a 10-year data sensitivity horizon (healthcare records, legal documents, financial data), algorithm agility matters. You want encryption implementations that can swap underlying algorithms without re-architecting the entire stack. This is an infrastructure concern, not a marketing concern, and it is worth raising with any vendor whose encryption you depend on.

What does the market trajectory look like?

The broader endpoint security market reached $40.3 billion in 2025 and is projected to reach $119 billion by 2035. That includes encryption alongside EDR, XDR, and other detection and response tooling. The growth reflects continued enterprise investment, driven partly by regulatory pressure and partly by the ongoing reality that endpoints remain the primary attack surface for most organizations.

One trend worth noting: 67% of Managed Service Providers reported facing an AI-driven attack in the past year. The tools attackers use are getting better, which means the baseline defenses (including endpoint encryption) need to be in place before you start worrying about advanced threats. You cannot build a detection strategy on top of an unencrypted foundation.

A practical checklist for endpoint encryption deployment

If you are responsible for a fleet of devices and you are not sure where you stand, here is a minimal starting point.

1. Audit your device inventory. You cannot encrypt what you do not know about. Include BYOD, contractor devices, and anything that touches sensitive data.
2. Deploy FDE on every managed device. BitLocker on Windows, FileVault on macOS, LUKS on Linux. These are built-in, free, and well-understood. The barrier to deployment is operational, not technical.
3. Centralize key management. Use a management platform that can report encryption status across the fleet, enforce policies, and handle key escrow securely. A device you cannot verify is encrypted is, for policy purposes, unencrypted.
4. Enforce strong authentication at boot. FDE with a weak PIN is theater. Require passphrases or hardware tokens for pre-boot authentication.
5. Layer endpoint detection on top. Encryption handles the theft scenario. You still need EDR or equivalent tooling for the malware scenario. These are complementary, not competing controls.
6. Revisit annually. Devices rotate. Employees join and leave. New device categories appear. An encryption policy that was complete in January may have gaps by June.

None of this is novel. All of it is under-implemented. The 50% adoption figure suggests that half the organizations reading this have work to do.

The core distinction, stated once more

Endpoint encryption protects the data on a device. Transport encryption protects data moving across a network. At-rest encryption protects data in storage (local or remote). End-to-end encryption protects data from sender to recipient, excluding intermediaries. These are four different answers to four different threat scenarios. Any vendor, including us, who says "encrypted" without specifying which kind is not giving you enough information to evaluate the claim.

The word "encrypted" is doing a lot of work in a lot of marketing copy. Make it do less work. Make it be specific.

Start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io