The simple version
Encryption protects data while it’s traveling or sitting still. Most breaches don’t attack the data while it’s traveling or sitting still. They wait until it’s been decrypted, then take it.
The lock on an unlocked door
Here is what most security guides tell you to do: use HTTPS, encrypt your hard drive, enable end-to-end encryption on your messaging app. All of that is correct. None of it addresses how most serious data theft actually happens.
Consider what encryption actually does. It scrambles data so that anyone without the right key sees gibberish. The moment that data is in active use, by an application, a database query, a logged-in user, it has to be decrypted. That’s not a flaw in encryption. That’s the definition of encryption. The lock exists to be opened.
The problem is that the standard advice treats encryption as a destination rather than a tool. You implement it, check the box, and feel protected. What it actually buys you is very narrow: protection against someone intercepting your traffic or stealing your physical storage device. Both of those threat vectors are real. Both are also relatively rare compared to breaches that occur when data is already decrypted and accessible.
The 2013 Target breach, which exposed roughly 40 million payment card numbers, didn’t crack any encryption. Attackers entered through a third-party HVAC vendor with network access, moved laterally through Target’s systems, and captured payment card data as it was being processed at point-of-sale terminals, before it was encrypted for transmission. The data never needed to be decrypted because it was never in an encrypted state at the moment of theft.
Where the actual risk lives
Data breaches cluster around three moments: during processing, through credential compromise, and via excessive access permissions. Encryption is largely irrelevant to all three.
During processing, applications have to decrypt data to use it. If an attacker has compromised the application, they see what the application sees. This is how many payment card skimming attacks work, and it’s why point-to-point encryption in retail systems has to cover the entire processing chain, not just the storage layer.
Credential compromise is arguably the most common vector. If an attacker has valid login credentials for a database, the database doesn’t know to resist them. It decrypts and serves data the same way it would for a legitimate user. The Verizon Data Breach Investigations Report has consistently found, across multiple years, that stolen or weak credentials account for the majority of hacking-related breaches. Encrypting the underlying database files does nothing when the attacker logs in through the front door with a valid username and password.
Excessive permissions compound both problems. Many organizations grant database access broadly because restricting it creates friction. A customer service representative who needs to look up one user’s account often has read access to the entire customer table. An application that needs to write order records often has read access to payment data it never touches. When any of those accounts or application credentials are compromised, the blast radius is enormous. Again, encryption is not the operative variable.
What actually reduces risk
None of this means encryption is useless. Encrypting data at rest protects against physical theft of drives. Encrypting data in transit protects against network interception. These are legitimate threats, especially for organizations subject to compliance frameworks like PCI-DSS or HIPAA, which require encryption partly as a floor, not a ceiling.
But the controls that move the needle on breach probability and impact are less photogenic than encryption.
Least-privilege access means granting any user, application, or service only the permissions it actually needs and nothing more. This sounds obvious. It is rarely implemented well, because it requires ongoing maintenance as systems evolve. Permissions get added when someone needs them and almost never get removed when they don’t.
Secrets management addresses the surprisingly common problem of credentials stored in source code, environment files, or configuration documents. Hardcoded database passwords and API keys are a genuine epidemic. GitHub has a feature that scans public repositories for exposed credentials and notifies the affected services. They process millions of credentials annually. These are real secrets, in production systems, sitting in public code.
Network segmentation limits lateral movement. Even if an attacker gets into one part of your system, they shouldn’t be able to walk freely to every other part. The Target breach succeeded partly because the vendor access that served as the entry point had a path to the payment network. That path should not have existed.
Multi-factor authentication on privileged accounts is probably the single highest-return control most organizations aren’t fully deploying. It directly addresses credential compromise, which is the most common attack vector. It doesn’t require encrypting anything.
Why the wrong advice keeps spreading
Encryption is a compelling story because it’s conceptually clean. Data is either scrambled or it isn’t. You can implement it once and explain it simply. Least-privilege access, secrets management, and network segmentation require ongoing work, context-specific judgment, and they don’t reduce to a single product you can buy.
Security vendors have strong incentives to sell encryption products. The advice ecosystem around security often reflects what’s sellable, not what’s highest-impact. This same dynamic plays out across many technology categories, where the second-best product often makes more money than the most effective one.
There’s also a compliance angle. Regulatory frameworks that require encryption create the impression that encryption is the primary obligation. It’s one obligation. Regulators who wrote those frameworks did not intend for organizations to interpret encryption compliance as a substitute for access control.
What good looks like
Encrypt your data at rest and in transit. That’s table stakes and should be done. Then spend at least as much time on access control as you did on encryption. Audit who and what can read your most sensitive data. Revoke permissions that haven’t been used in 90 days. Get credentials out of source code. Enable multi-factor authentication on every privileged account.
The goal is to reduce the blast radius when something goes wrong, because something will go wrong. A breach that exposes one customer’s data because that customer’s session was compromised is a bad day. A breach that exposes every customer’s data because an application credential had unrestricted database access is a different order of problem entirely.
Encryption helps with the former. Access control determines the latter. Most security writing spends three paragraphs on the first and a footnote on the second.
