What Is Encryption at Rest vs. Encryption in Transit?

Encryption at rest applies to information sitting on persistent storage rather than moving across a network. That covers a wide range of places: 

• Laptop and server drives
• Databases
• Storage arrays
• Object storage
• Snapshots
• Archives
• Removable media
• Backup repositories

If any of these fall into the wrong hands, the data inside them stays unreadable without the right key.

Organizations use several methods, depending on where the protection needs to sit:

• Full-disk encryption secures an entire drive.
• Volume encryption protects a defined storage segment.
• File or folder encryption works at the individual-item level.
• Database or storage-service encryption applies protection closer to where records are stored.

According to NIST SP 800-111, storage encryption combines encryption with authentication to restrict access to stored information. The guidance identifies full-disk, volume, and file-level encryption as the three broad implementation types.

What this protects against is fairly specific. It reduces exposure after a lost laptop, a stolen server, unauthorized physical access to a facility, or someone reaching storage media directly without going through the intended application. What it doesn’t do is protect data once a legitimate account or application has already decrypted it. Once information is unlocked for an authorized user, encryption at rest has done its job, and other controls need to take over from there.

Encryption in transit covers information while it moves between two endpoints, whether that’s a browser and a website, a branch office and a data center, or an on-premises system and the cloud. Once data starts moving, it faces the risk of interception anywhere along that connection.

The technology shows up in several familiar connections. HTTPS sessions protected by TLS encryption secure everyday web traffic, while VPNs shield connections between offices and remote workers. Encrypted backup transfer and replication protect data moving toward a recovery site. SSH secures administrative sessions, and secure APIs protect data passed between applications. TLS provides mechanisms to protect data during electronic dissemination over the internet, along with guidance on protocol selection and cipher configuration.

Transport encryption supports confidentiality and integrity while information crosses a network, but that protection only holds if the connection is configured correctly. Certificate validation matters: An encrypted connection to the wrong or impersonated endpoint can still expose data, even though the traffic itself is scrambled. Weak protocol versions or misconfigured certificates can undermine protection that looks solid on paper.

The table below compares encryption at rest and in transit across the main differences that matter in practice.

At rest protects storage, while in transit protects movement. Most organizations need both.

Cloud backup encryption and disaster recovery security depend on protecting data in both states because backup and recovery involve encryption at rest and in transit throughout the process. A typical cycle looks like this:

1. Read data from production
2. Capture a recovery point
3. Encrypt the data before or during transfer
4. Move it across the network
5. Store it in an off-site repository
6. Retain it immutably where configured
7. Test the backup periodically
8. Restore it into a recovery environment when needed

Skipping either state creates a real gap. A secure storage repository paired with an unencrypted transfer channel still exposes the network path while data is moving. Encrypted transfer paired with an unencrypted repository still exposes the stored copies. Either approach leaves a gap that the other form of encryption cannot cover.

The same principle extends to replication and failover traffic, administrative and management connections, recovery environments spun up during an incident, and the restored data itself once it lands back in production. Those paths need the same protection as the primary backup job.

Disaster recovery adds another consideration. Keys and credentials need to remain available during an incident, but they should not depend on the same systems or accounts that may already be compromised. 

Our guide to [Secure Cloud Architecture for Data Protection and Disaster Recovery] explains how those protections can be built into the broader recovery environment.

Data encryption at rest and in transit often supports legal, regulatory, contractual, and customer requirements that apply to stored and transmitted information. The exact obligation and what counts as an acceptable implementation depend on the specific data involved, the systems in play, the jurisdiction, and the compliance scope an organization falls under.

Two frameworks show how this works in practice. PCI DSS covers the protection of stored and transmitted payment account data for organizations that handle cardholder information. HHS guidance similarly advises organizations handling electronic protected health information to encrypt ePHI at rest and in transit where appropriate. The exact requirements still depend on the organization and its compliance scope, so teams should confirm what applies to them directly.

Encryption key management determines how well that protection works over time. That includes:

• Secure key generation 
• Controlled key storage 
• Strict access controls 
• Separation of keys from the data they protect 
• Regular key rotation 
• Key backup and recovery 
• Revocation when needed 
• Audit logging 
• Clear ownership 
• Documented recovery procedures 

Weaknesses in any of these areas can reduce protection or make recovery harder. This becomes especially important during recovery. A backup can be fully encrypted and still become useless if the decryption key is lost or unavailable when it is needed. Our Security as a Service brings encryption, access controls, monitoring, and recovery-focused security together under a managed approach.

Is HTTPS encryption at rest or in transit?

HTTPS relies on TLS to protect data while it moves across the network, which makes it encryption in transit rather than encryption at rest.

Are cloud backups encrypted automatically?

Encryption defaults vary by provider and service. Therefore, teams need to verify the transfer channel, the storage repository, and the key settings rather than assuming full coverage is automatic.

Does encryption prevent ransomware?

Encryption protects the confidentiality of data, but it does not stop an attacker with valid access from deleting, corrupting, or re-encrypting files.

Who should control encryption keys?

Provider-managed keys simplify day-to-day operations, while customer-managed keys offer more direct control over access, rotation, and compliance requirements. The tradeoff is that losing a customer-managed key can also mean losing access to the data itself.

Protecting data means covering encryption at rest and in transit at every stage: storage, movement, backup, replication, and recovery. Treating either state as optional leaves a gap that the other can’t close.

At OTAVA, we help organizations combine encryption, managed security, backup, and disaster recovery controls so sensitive data remains protected and recoverable. If you’re not sure where your own encryption or data-protection coverage has gaps, contact us, and we’ll review it with you.