Server Encryption: At Rest and In Transit

Server encryption encompasses two distinct operational domains — data protection during storage and data protection during network transmission — each governed by different cryptographic mechanisms, regulatory requirements, and failure modes. This page maps the technical structure, classification distinctions, regulatory context, and professional considerations of encryption at rest and in transit as applied to server environments across enterprise, government, cloud, and hybrid infrastructure. The distinction between these two states is not merely semantic; misconfiguring or omitting either layer represents a recognized compliance gap under frameworks including NIST SP 800-111 and PCI DSS.

• Definition and Scope
• Core Mechanics or Structure
• Causal Relationships or Drivers
• Classification Boundaries
• Tradeoffs and Tensions
• Common Misconceptions
• Checklist or Steps
• Reference Table or Matrix
• References

Definition and Scope

Encryption at rest refers to cryptographic protection applied to data stored on physical or virtual media — hard drives, SSDs, storage area networks, object storage buckets, database volumes, and backup archives. The mechanism protects data that is not actively moving across a network, ensuring that physical possession of a storage device does not yield readable content without the corresponding decryption key.

Encryption in transit — also referred to as encryption in motion or data in flight — refers to cryptographic protection applied to data traversing a network connection: between a client and server, between two servers, between a data center and a cloud endpoint, or across any other communication channel. The protection applies while data is moving and lapses once data is decrypted at the receiving endpoint.

Both classifications appear explicitly in major regulatory instruments. HIPAA's Security Rule (45 CFR §164.312(e)(2)(ii)) addresses encryption of electronic protected health information in transit. NIST SP 800-111 establishes guidance for storage encryption of sensitive information on end-user devices and servers. The PCI DSS v4.0 Requirements 3.5 and 4.2 mandate encryption of stored cardholder data and prohibition of unprotected transmission of cardholder data over open networks respectively.

The server security providers on this provider network cover vendors and service providers operating across both encryption domains, including managed key management services, hardware security module (HSM) provisioning, and TLS certificate lifecycle management.

Core Mechanics or Structure

Encryption at Rest — Mechanisms

Storage encryption operates at one of three layers: full-disk encryption (FDE), volume/partition encryption, or file/object-level encryption. Full-disk encryption, implemented through standards such as AES-256 in XTS mode, protects the entire storage medium. NIST identifies AES with 256-bit keys as acceptable for protecting data classified up to the SECRET level under FIPS 140-3, the federal standard for cryptographic module validation.

Volume encryption tools such as Linux Unified Key Setup (LUKS) operate at the block device layer, encrypting specific logical volumes without requiring full-disk encryption of the operating system partition. File-level encryption, including tools implementing the eCryptfs or fscrypt frameworks, applies encryption per file or provider network, allowing selective protection of sensitive data stores without encrypting system files.

Database-level encryption divides further into transparent data encryption (TDE) and column-level encryption. TDE, available in major relational database management systems, encrypts data files and log files at rest without requiring application-layer changes. Column-level encryption applies cryptographic protection to individual data fields, typically implemented when only a subset of stored data — such as Social Security numbers or payment card numbers — requires elevated protection.

Encryption in Transit — Mechanisms

Transport Layer Security (TLS) is the dominant protocol for encrypting data in transit. TLS 1.3, standardized in RFC 8446 by the Internet Engineering Task Force (IETF), provides forward secrecy through ephemeral Diffie-Hellman key exchange, mandatory authenticated encryption, and removal of legacy cipher suites present in TLS 1.2. NIST SP 800-52 Rev. 2 designates TLS 1.2 and TLS 1.3 as the minimum acceptable versions for federal information systems, explicitly prohibiting SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1.

IPsec (Internet Protocol Security) provides encryption at the network layer, commonly used for VPN tunnels and server-to-server communication within internal networks. SSH (Secure Shell) protocol encrypts administrative connections to servers, replacing the plaintext Telnet protocol. SFTP and FTPS extend encrypted transport to file transfer operations.

Key management infrastructure underpins both at-rest and in-transit encryption. Hardware Security Modules (HSMs) provide tamper-resistant storage of cryptographic keys and are referenced in NIST SP 800-57 Part 1 Rev. 5 as a recommended mechanism for protecting high-value keys. The server security provider network purpose and scope outlines how HSM and key management service providers are classified within this network's provider structure.

Causal Relationships or Drivers

Regulatory mandates are the primary structural driver of server encryption deployment at scale. HIPAA's breach notification rule, codified under 45 CFR Part 164 Subpart D, creates a direct liability reduction incentive: encrypted data that is improperly disclosed may qualify as not "unsecured" under HHS guidance, potentially eliminating breach notification obligations. This safe harbor provision has measurably shaped healthcare sector encryption adoption.

PCI DSS v4.0 Requirement 3.5 mandates that primary account numbers (PANs) be rendered unreadable anywhere they are stored, with AES-256, Triple-DES with 112-bit minimum effective key strength, or RSA with 2,048-bit minimum key length verified as acceptable methods (PCI SSC, PCI DSS v4.0). Non-compliance carries per-transaction fines and potential loss of card processing privileges.

The Federal Information Security Modernization Act (FISMA), enforced through OMB Circular A-130, requires federal agencies to implement NIST cryptographic standards across all federal information systems. Cloud environments subject to FedRAMP authorization must demonstrate encryption controls meeting NIST SP 800-53 Rev. 5 SC-28 (Protection of Information at Rest) and SC-8 (Transmission Confidentiality and Integrity).

Beyond regulatory drivers, ransomware and insider threat vectors motivate encryption deployment independently. Storage encryption limits the damage window when physical media is removed from a data center. TLS enforcement prevents credential harvesting through network interception attacks.

Classification Boundaries

Server encryption classification follows several axes that define how solutions are scoped and evaluated:

By cryptographic layer: Encryption operates at the hardware layer (self-encrypting drives using the Opal 2.0 standard), the OS/hypervisor layer (LUKS, BitLocker, dm-crypt), the application layer (TDE, field-level encryption), or the protocol layer (TLS, IPsec, SSH).

By data state: At rest, in transit, and — a third emerging category — in use (also called confidential computing, using trusted execution environments such as Intel SGX or AMD SEV). In-use encryption is addressed separately in NIST IR 8320.

By key ownership model: Customer-managed keys (CMK), cloud provider-managed keys, and hybrid models using bring-your-own-key (BYOK) frameworks represent distinct trust boundary configurations. Key ownership determines who can decrypt data independently of the data owner — a critical distinction for regulated industries.

By algorithm classification: Symmetric algorithms (AES-256 for bulk encryption) versus asymmetric algorithms (RSA-2048, ECDSA P-256 for key exchange and authentication). NIST SP 800-131A Rev. 2 governs algorithm transitions and deprecation timelines.

Tradeoffs and Tensions

Performance overhead: AES-NI hardware acceleration, present in processors from Intel's Westmere architecture (2010 onward) and AMD's Bulldozer architecture, reduces the performance cost of AES encryption to near-negligible levels for most workloads. However, key-intensive operations and high-volume TLS handshakes at scale — particularly in environments terminating millions of connections — introduce measurable latency. TLS session resumption and TLS session tickets (defined in RFC 5077) mitigate handshake overhead at the cost of modified forward secrecy properties.

Key management complexity versus security: Stronger key management — shorter key rotation cycles, hardware-backed storage, split-knowledge procedures — increases operational complexity and introduces new failure modes. Lost encryption keys render data permanently inaccessible. The tension between key security and key availability recoverability is a recognized design challenge documented in NIST SP 800-57 Part 2 Rev. 1.

Encryption scope versus operational visibility: Encrypted traffic between servers reduces the effectiveness of network-layer security monitoring tools, intrusion detection systems, and DLP platforms that rely on packet inspection. Organizations must choose between terminating TLS at inspection points (introducing a decryption boundary) or accepting reduced visibility. This tradeoff is particularly acute in zero-trust architectures.

Compliance minimum versus cryptographic best practice: Regulatory frameworks often trail cryptographic research. PCI DSS still permits Triple-DES in some configurations; NIST has deprecated 80-bit security strength for most uses since SP 800-131A. Organizations may satisfy a compliance audit while operating below current cryptographic best practice — a gap that compliance frameworks do not automatically resolve.

The how to use this server security resource page explains how the provider network organizes providers by encryption service category to assist professionals navigating these tradeoffs.

Common Misconceptions

Misconception: HTTPS on a web server means all server data is encrypted.
TLS protects the connection between client and server. Data stored in the database, on disk, in log files, and in backups remains unencrypted unless storage encryption controls are independently implemented. HTTPS addresses one of two distinct protection domains.

Misconception: Encryption at rest protects against all data breaches.
Storage encryption protects against physical media theft and unauthorized physical access. It provides no protection against a breach occurring while the system is running and data is mounted and accessible — the most common breach scenario. An attacker with valid credentials accessing a live, mounted encrypted volume reads decrypted data.

Misconception: TLS 1.2 and TLS 1.3 are interchangeable.
TLS 1.3 eliminates cipher suites that TLS 1.2 permits but that are considered cryptographically weak, including RSA key exchange (which lacks forward secrecy) and RC4. RFC 8446 reduced the TLS handshake from 2 round trips to 1, improving both security and performance. The two versions are not equivalent in their security properties.

Misconception: Cloud provider encryption is equivalent to customer-managed encryption.
When a cloud provider manages encryption keys, the provider retains technical capability to decrypt customer data. Cloud provider key management is appropriate for many threat models but does not satisfy use cases where the cloud provider is within the threat model, including certain government, legal, and cross-border data residency scenarios.

Misconception: Self-signed certificates provide the same in-transit protection as CA-signed certificates.
The encryption strength of a TLS session is independent of certificate signing authority. However, self-signed certificates disable trust chain verification, creating conditions under which man-in-the-middle substitution of a certificate cannot be detected by connecting clients. The encryption algorithm is the same; the authentication assurance is absent.

Checklist or Steps

The following sequence describes the technical verification and implementation phases for a server encryption audit or initial deployment, structured as observable states rather than prescriptive advice:

1. Inventory data classification — Identify all data categories present in the environment and their applicable regulatory frameworks (HIPAA, PCI DSS, FISMA, state-level statutes). Map data to storage locations: databases, file systems, object storage, backups, logs.

2. Audit storage encryption status — Verify full-disk or volume encryption status on all server storage media using OS-level commands (dmsetup status, lsblk, cryptsetup status). Confirm encryption algorithm and key length against FIPS 140-3 requirements for applicable environments.

3. Review TLS configuration — Enumerate all listening services and their protocol versions using tools such as openssl s_client or testssl.sh. Confirm TLS 1.2 minimum, TLS 1.3 preferred. Document and remediate any SSL, TLS 1.0, or TLS 1.1 endpoints per NIST SP 800-52 Rev. 2.

4. Validate cipher suite configuration — Confirm that cipher suites offering forward secrecy (ECDHE or DHE key exchange) are prioritized. Verify that NULL, EXPORT, RC4, DES, and 3DES cipher suites are disabled at the server configuration layer.

5. Assess certificate chain validity — Verify certificate authority chain, expiration dates, Subject Alternative Names, and certificate revocation status. Confirm that certificates are issued by a recognized CA for external-facing services.

6. Audit key management procedures — Document key storage locations, access control lists for key material, key rotation schedules, and backup/recovery procedures. Verify alignment with NIST SP 800-57 Part 1 Rev. 5 key management lifecycle requirements.

7. Test database encryption state — For databases processing regulated data, verify TDE status, confirm that data files and transaction log files are encrypted at rest, and validate that backup files inherit encryption controls.

8. Document encryption control evidence — Produce configuration artifacts, scan outputs, and key management policy documentation suitable for compliance evidence packages under the applicable framework audit requirements.

Reference Table or Matrix