Encryption: At Rest and In Transit

This article is for educational purposes only and does not constitute professional compliance advice or legal counsel. Encryption strategy, algorithm selection, and key management practices depend on organizational context, regulatory requirements, and risk profile. Consult qualified cybersecurity professionals for guidance specific to your situation.

Encryption is almost universally required by compliance frameworks. Your cyber insurance application asks about it. Your customer contracts probably require it. Auditors ask about it. But many organizations deploy encryption and then discover that the implementation doesn't actually protect what they thought it did. Encryption is not a single thing—it's a set of practices that only work when implemented as a system. The algorithm matters less than most people think. Key management matters far more.

Understanding what encryption actually defends against, where to apply it, and how to do it in a way that survives implementation challenges and key compromise is what separates encryption that matters from encryption that's just a checkbox for auditors.

At Rest: Protecting Stored Data

Encryption at rest means data is encrypted while stored on disk or other persistent storage. If a laptop is stolen from an employee's desk, if a backup drive is lost, if someone physically removes a hard drive from a decommissioned server, the encrypted data on that storage is unreadable without the encryption key. The thief or finder has the encrypted bytes but cannot recover the original data.

This matters most for mobile devices and removable storage, where physical loss is a realistic threat. An employee traveling with a laptop containing customer data, financial records, or intellectual property creates a scenario where the laptop could be stolen. If the drive is encrypted, the theft becomes a minor inconvenience—the data is protected. If the drive is not encrypted, someone has access to sensitive information.

Encryption at rest also provides some defense against unauthorized data access by internal actors. A system administrator or attacker with file system access cannot read encrypted files without the encryption key. Depending on how encryption is implemented, this might stop them entirely, or it might just slow them down by requiring additional steps to compromise the key.

The important limitation is that encryption at rest does not protect data while it's being accessed. When a user opens an encrypted file, the system decrypts it and the decrypted version exists in memory and often on disk as a temporary file. At that moment, the data is vulnerable. Encryption at rest protects against theft of the storage device. It does not protect against access by someone with the encryption key, physical access to the running system, or access to memory while the system is powered on.

For most organizations, encryption at rest is essential for mobile devices and removable storage. Laptops should be encrypted. USB drives should be encrypted. Tablets should be encrypted. Servers in data centers should have encrypted storage as well, though the threat model is different—the risk is not physical theft but rather unauthorized administrative access or attack after compromise.

In Transit: Protecting Against Eavesdropping

Encryption in transit means data is encrypted as it travels over networks. Without encryption, network traffic is often transmitted in plain text. Someone with access to network infrastructure can see the content of communications. An attacker on public WiFi can intercept unencrypted traffic. An internet service provider or telecom can see what's being communicated.

Encryption in transit makes the transmitted data unreadable to passive observers. HTTPS encrypts web traffic. A VPN encrypts everything going through it. Encrypted messaging systems make the content of messages unreadable to anyone without the decryption key. The person sending and the person receiving can read the message, but no one eavesdropping on the network can.

The threat that encryption in transit defends against is real. Public WiFi networks are particularly vulnerable because multiple users are connected to the same access point and can theoretically see each other's traffic. Home networks are often not fully controlled, and network devices can be compromised. Even corporate networks cannot be assumed to be fully secure—an attacker with access to the network can capture and analyze traffic.

For most organizations, HTTPS for all web traffic is now standard. Data sent to cloud applications, to SaaS platforms, to your own web applications should all be encrypted in transit. VPN is a common approach for securing network traffic between remote employees and corporate networks. Encrypted messaging systems protect sensitive communications.

The key point is that encryption in transit protects against a specific threat: someone intercepting and reading your communications as they cross networks. It does not protect against compromise at the endpoints—if the attacker can access your email account directly, encryption in transit doesn't prevent them from reading your emails. It does not protect against compromise of the destination system—if an attacker compromises the cloud application you're sending data to, encryption in transit is irrelevant because the data is decrypted at the destination.

Key Management: Where Encryption Actually Fails

Here is where the practice of encryption often breaks down. Encryption is only as strong as the encryption keys. A very strong encryption algorithm with weak key management is fundamentally broken. An organization can deploy encryption across all systems and still have no protection if the keys are managed poorly.

Key management involves multiple aspects. Keys must be generated securely—using appropriate randomness and avoiding weak patterns. Keys must be stored securely—not in configuration files, not in source code, not in places where they can be easily discovered or compromised. Keys must be protected from unauthorized access—only systems and people who need to decrypt specific data should have access to the relevant keys. Keys must be rotated—old keys that might be compromised should be retired and new keys should be generated. Keys must have a lifecycle—they're created, used, rotated, and eventually archived or destroyed according to policy.

Many organizations implement encryption and then store encryption keys in places that might as well be public. Keys in configuration files, keys hardcoded in applications, keys in deployment scripts, keys in shared documents. If the encryption key is easily discoverable, the encryption provides zero protection. An attacker who finds the key can decrypt everything.

For small organizations, basic practices work: generate keys securely, store them in restricted directories with access controls, rotate them annually or when compromised, protect copies. For larger organizations or systems requiring higher security, hardware security modules (HSMs) provide a specialized device that stores keys and performs encryption operations without ever revealing the key itself. Keys can never leave the HSM, dramatically reducing the risk of compromise.

The sobering reality is that many organizations implement encryption without implementing proper key management. They deploy an encrypted backup system and store the decryption key in the same location as the backup—defeating the purpose. They implement drive encryption but store the encryption password in BIOS in an easily accessible way. They encrypt databases but store the key in configuration files that get checked into version control. They convince themselves they've addressed data protection because they've deployed encryption, when actually they've just performed security theater.

If you're responsible for encryption implementation, treat key management with the same care you give the encryption algorithm itself. Audit where keys are stored. Verify that only appropriate systems have access. Implement key rotation. Consider HSMs for sensitive encryption keys. Key compromise is catastrophic—any time spent on protecting keys is worthwhile.

Algorithm and Protocol Selection

Which encryption algorithm you use matters far less than doing encryption correctly. AES-256 is the current standard for symmetric encryption—encrypting data for storage. RSA and elliptic curve cryptography are standards for asymmetric encryption—encryption where different keys are used for encryption and decryption. TLS 1.2 and TLS 1.3 are current standards for encrypting web traffic. These are solid choices that won't be broken by conventional attacks.

You do not need to agonize over algorithm selection unless you have a specific reason to. If you're implementing encryption for routine data protection, use AES-256 for at rest encryption, use TLS 1.3 for web traffic, and move on. The algorithm is not the weak point.

What does matter is avoiding deprecated or weak algorithms. MD5 and SHA1 should not be used for cryptographic purposes. DES and 3DES are essentially obsolete and should be retired if they're still in use. SSL 2.0 and SSL 3.0 are broken and should not be used. If your systems are using these, it's a sign that upgrades are overdue.

Similarly, do not use proprietary or novel encryption algorithms unless you have a very specific reason and significant cryptographic expertise. Established algorithms have been reviewed and tested by many experts. Novel algorithms may hide weaknesses. The practice of security is using well-understood, peer-reviewed techniques, not experimenting with custom encryption.

Performance and Overhead

A common objection to encryption is performance. Encryption and decryption consume CPU resources. Encrypted transmission takes slightly longer than unencrypted. For some systems, this overhead is meaningful.

The good news is that modern hardware acceleration for encryption has dramatically reduced the overhead. Processors include specialized instructions for AES encryption. GPUs can accelerate cryptographic operations. For most applications, encryption overhead is negligible—a few percent CPU utilization at most. Performance should not be a blocker for encryption.

There are scenarios where encryption overhead is noticeable. Real-time systems with strict latency requirements might struggle with decryption latency. High-throughput systems processing massive amounts of data might see meaningful CPU utilization from encryption. These are exceptions, not the norm. Even in these cases, the security benefit usually justifies the performance cost.

If your organization encounters a scenario where performance is genuinely limiting encryption, that's worth investigating. But "performance" is rarely the real reason that encryption is skipped. More often, encryption is omitted because it was never considered, or because implementation is perceived as difficult, or because it's seen as unnecessary. In these cases, the performance objection is a rationalization, not a real constraint.

When to Encrypt and When Not To

Not every piece of data requires encryption equally. Customer data, financial records, health information, intellectual property—these should be encrypted both at rest and in transit. These are genuinely sensitive and their compromise has real consequences.

Public information, marketing materials, non-sensitive operational data—these don't require the same level of encryption. Encrypting everything adds overhead without commensurate security benefit.

A reasonable approach is data classification: rank data by sensitivity, and apply encryption controls proportionate to sensitivity. Highly sensitive data gets encryption at rest and in transit, plus key management practices that are robust. Moderately sensitive data gets encryption in transit. Low-sensitivity data might not require encryption.

This classification-based approach prevents both extremes. It prevents over-encrypting everything and wasting resources on data that doesn't need the protection. And it prevents under-protecting sensitive data. Most importantly, it forces your organization to think about what data actually matters and what the real risks are.

Encryption As Part of a Larger System

Encryption is foundational but not sufficient as a standalone control. Encryption at rest protects against theft of storage. Encryption in transit protects against eavesdropping. But encryption does not protect against compromise of systems, doesn't prevent unauthorized access to data by legitimate users, and doesn't detect data loss or exfiltration. Those require other controls: access management, logging, data loss prevention, incident detection.

Many breaches occur because encrypted data was accessed by someone who had the right credentials or who compromised a system with legitimate access. In these cases, encryption provided zero protection because the attacker had a legitimate path to the decrypted data.

The goal of encryption is not to encrypt everything. It's to encrypt sensitive data properly, using appropriate algorithms, with secure key management, as one layer in a security program that includes access controls, detection, and response. Done well, encryption makes stolen data useless. Done poorly, it's a checkbox that provides false confidence.

If you're implementing encryption, do it thoroughly. Get the algorithm right. Get the key management right. Get the implementation details right. And recognize that encryption is not the only control you need. It's part of a larger strategy for protecting information.

Fully Compliance provides educational content about IT compliance and cybersecurity. This article reflects general information about encryption practices and implementations as of its publication date. Encryption standards, algorithms, threat landscapes, and best practices evolve continuously. Consult qualified cybersecurity professionals for guidance specific to your organization.