Best Practices for Data Encryption in 2026

Key Takeaways:

• AES-256-GCM is the standard for data at rest and TLS 1.3 for data in transit in 2026; neither secures data during processing.
• Envelope encryption with data encryption keys wrapped by a key-encryption key stored in a KMS or HSM reduces rotation costs: rotating the KEK re-wraps DEKs instead of re-encrypting all records.
• Client-side encryption is a product design choice, not a stronger security setting: it disables server-side search, spam filtering, and content scanning for the encrypted data.
• Homomorphic encryption and confidential computing protect data during processing, but each introduces latency, memory, and orchestration overhead that limit their use to specific workloads.
• Most audit failures result from missing proof that a control was active, not from missing controls themselves.

Data at rest and data in transit are mostly addressed for most enterprises. The remaining challenge is data in use. A September 2026 ABI Research analysis reported that confidential computing, which uses hardware to protect data during processing, is expanding from CPUs to GPUs, multi-GPU setups, containers, and agentic AI workflows as AI deployments grow. Organizations can encrypt all stored volumes with AES-256 and secure all connections with TLS 1.3, yet still expose plaintext to any process that reads the data.

The Three States and What Each Control Actually Stops

Data exists in three states, each with its own vulnerabilities. Data at rest is stored on disks, databases, or backups. Data in transit moves over networks. Data in use is actively processed in application or processor memory. Applying a control to the wrong state can create a misleading sense of security instead of actual protection.

Encryption at rest renders stored data unreadable without the key. It protects against theft of drives, copied backups, or raw storage access. It does not prevent attackers with valid credentials or those exploiting application bugs, since the application decrypts data on demand. As Back4app’s encryption explainer explains, encryption complements access control but does not replace it.

Encryption in transit secures data moving across networks. TLS creates an encrypted tunnel, authenticates endpoints, and ensures the payload is not altered during transmission. Its limitation is that once data reaches its destination, TLS ends and the recipient receives plaintext. A TLS connection to a cloud provider protects the network path but not the data stored within that provider’s system.

Encryption in use addresses what the other two do not. Protecting data while a processor accesses it requires hardware isolation or encryption that remains intact during computation. This is where Duality Technologies’ 2026 state-of-data guide identifies the main challenge. The guide also notes that breaches often exploit gaps between encrypted states rather than weaknesses in the algorithms themselves.

Encryption at Rest: AES-256 and Envelope Encryption

AES-256 continues to be the recommended standard for stored data in 2026. It is fast, widely available, and cryptographically strong. Most cloud providers and databases offer it either managed or customer-managed. Amazon has made it the default: S3 now automatically encrypts all new objects on the server side using AES-256, as BleepingComputer reported. The most frequent error is not selecting a weak algorithm but leaving development and staging environments unencrypted while encrypting production.

“Encrypted at rest” covers four different protections, each defending against a different attacker. Full-disk encryption like LUKS or BitLocker protects against stolen or discarded hardware but not against users on a running system. Transparent data encryption protects database files and backups but not users with database credentials. Field-level encryption protects specific columns from curious administrators and broader database breaches, but encrypted columns cannot be indexed or searched normally. Application-level encryption protects everything below the application but makes the application and its key store the target.

Envelope encryption simplifies key management. A data encryption key (DEK) encrypts the data; this DEK is itself encrypted by a key-encryption key (KEK) stored in a KMS or HSM, where it never leaves in plaintext. Rotating the KEK means re-wrapping the DEKs, not re-encrypting every record. The ciphertext and wrapped keys are useless without the key that unwraps them, which is not stored in the database.

A common audit failure occurs when an encrypted database’s backups are unencrypted. Encrypt backups, keep keys separate, and use crypto-shredding to invalidate stolen copies by destroying the key instead of trying to find every data replica.

Encryption in Transit: TLS 1.3 and Its Adoption

TLS 1.3 is the preferred protocol for data in transit in 2026. It completes the handshake in one round trip instead of two, removes legacy ciphers and RSA key exchange, and requires forward secrecy, so recorded traffic cannot be decrypted later even if the server’s long-term key is compromised. TLS 1.2 remains acceptable as a compatibility fallback but only with AEAD cipher suites.

Older versions cause the main problems. TLS 1.0 and 1.1 were formally deprecated in RFC 8996, but deprecation has been slow. More than 850,000 websites still used TLS 1.0 and 1.1 when browsers started blocking access to HTTPS sites running them, including sites for major banks and governments, as ZDNet reported. Leaving those versions enabled triggers findings in CSPM scans and penetration tests.

Internal traffic is another weak point. Many organizations enforce TLS on external APIs but leave service-to-service communication and database connections unencrypted, assuming internal networks are safe. In cloud environments with shared infrastructure or after internal breaches, this assumption fails. Zero trust principles require encryption on internal connections as well. Proxies or load balancers that terminate TLS mid-path create plaintext segments that need the same security controls as the network edge.

Algorithm Selection Guide

Algorithm choice is a compliance requirement, not a preference. Auditors expect specific algorithms with authenticated encryption modes and will ask which ones are used. The table below shows what major frameworks accept and what the Knowledgelib implementation guide recommends for each case.

Three rules override the table. Never use ECB mode, which leaks data patterns. Never reuse a nonce with AES-GCM, which breaks authentication completely. Never hardcode keys in source control; if a key has ever been in git history, rotate it immediately. Passwords are handled differently: they are hashed with bcrypt, scrypt, or Argon2id, never encrypted, because decryptable passwords would defeat the purpose of hashing.

Deprecated algorithms should be treated as critical issues rather than technical debt. DES, 3DES, RC4, MD5, and SHA-1 are cryptographically broken. TLS 1.0 and 1.1 have been disabled by all major browsers and cloud platforms, so leaving them enabled will cause findings in any assessment.

Key Management Architecture: KMS, HSMs, and Client-Side Encryption

Encryption strength depends on key security. The most common critical error is storing keys alongside the data they protect, making encryption ineffective against attackers who compromise the system. Keys should reside in a dedicated key management service or hardware security module, separated from data by account boundaries and access policies. A breach of a South Korean government-backed startup platform revealed a key management failure rather than a broken algorithm, as BleepingComputer reported.

The KMS manages key creation, policies, rotation schedules, and audit logs. The HSM is the root of trust, where key material cannot be extracted. Most enterprises use one of three patterns: provider-managed keys with no customer hardware, a custom key store routing KMS API calls through a customer HSM cluster, or a fully external setup keeping keys entirely outside the provider. Our enterprise key management guide explains the cost and availability trade-offs, including an example showing how a two-HSM cluster increases monthly key workload costs from a few dollars to several thousand when availability is factored in.

Rotation requires caution. Scheduling rotation in KMS replaces key material for new operations but does not re-encrypt existing data or disable previous versions. For envelope-encrypted data, this is correct and efficient. For data encrypted directly with the rotating key, every record must be rewritten, which is a migration requiring a rollback plan rather than a simple configuration change. Avoid deactivating a key version while batch jobs still read data encrypted under it.

Client-side encryption shifts key custody to the customer, encrypting data before it reaches the provider’s servers. Google’s Gmail client-side encryption is available for Workspace Enterprise Plus, Education Plus, and Education Standard customers. Google describes it as giving customers sole control over encryption keys and access to their data, as BleepingComputer reported. The trade-offs are clear: email headers like subject, timestamps, and recipient lists remain unencrypted, and private keys used to decrypt mail may be accessible to company administrators and other applications for retention policies and gateway scanning. This makes it weaker than true end-to-end encryption, where only sender and recipient devices can decrypt. Use it when the threat model includes the provider itself, not just the network.

Data in Use: Homomorphic Encryption and Confidential Computing

Three methods protect data during processing, each with different trade-offs. Trusted execution environments (TEEs) create a hardware boundary: code runs inside an isolated enclave, and the processor ensures that even the hypervisor or operating system cannot access enclave memory. Intel SGX, AMD SEV, and Arm TrustZone are common implementations. TEEs operate near native speed, but enclave memory is limited, making them better suited for bounded workloads like key processing and authentication than large-scale analytics.

Fully homomorphic encryption (FHE) allows computation directly on ciphertext without decrypting it. Duality reports it is production-ready and used in financial services, healthcare, and government workloads. The main practical limitation is latency: optimized implementations return results in seconds for suitable query patterns, while heavier workloads fit batch analytics and periodic reporting. The vendor also notes that no single technology solves all data-in-use challenges; organizations usually combine TEEs, FHE, secure multi-party computation, and governance controls rather than relying on one.

Confidential computing is gaining traction because AI workloads require it. CPU-based confidential computing is closest to widespread adoption, while GPU-based deployments are growing because they address AI security gaps by protecting data during processing. Vendors like Anjuna, Red Hat, Fortanix, Decentriq, and IBM build platforms for secure AI model weights, attestation, and confidential containers. Nvidia’s confidential GPU line includes Hopper, Blackwell, and Vera Rubin platforms. Anjuna has extended its confidential computing platform to on-premises data centers, targeting enterprises that want consistent policy and operational experience on-premises and in the cloud.

Google has worked to make homomorphic encryption more accessible by open-sourcing HEIR, a compiler toolchain that allows AI to work with data it cannot see, as Help Net Security reported. Niobium has developed a fully homomorphic encryption accelerator ASIC nearing production through a partnership with SEMIFIVE and Samsung Foundry, according to the company’s announcement, though this claim has not been independently benchmarked.

These methods have costs. TEE memory limits restrict workload size, FHE adds latency for heavier computations, and confidential computing introduces attestation and orchestration overhead. Dark Reading reports that AI agents create new security challenges that current confidential computing technology does not fully address. Treat these methods as tools for specific workloads rather than universal replacements for encryption at rest or in transit.

Compliance Mapping and Enforcement

All major frameworks require encryption at rest and in transit, with specific controls auditors test. Mapping these controls once consolidates multiple discussions into a single control set.

Source: SecComply’s encryption compliance reference.

Penalties under GDPR can reach 4 percent of global annual turnover or 20 million euros, whichever is higher. Article 32 explicitly lists encryption as an appropriate technical measure, so lacking it is a documented deficiency, not an unfortunate outcome.

Audit findings often result from missing proof that controls operated, not from missing controls. A team that rotates keys on schedule but cannot provide rotation logs for the audit period fails similarly to a team that never rotated keys. Route KMS and HSM logs to immutable storage, keep them searchable for the audit window, and set alerts for unusual decrypt activity.

Implementation Checklist and Audit Timeline

A defensible program follows a sequence where each phase produces evidence. This example assumes a mid-sized organization using two cloud environments.

• Weeks 1-3, inventory and classification. List every key and data store, map keys to the data they protect, and assign sensitivity tiers. This determines which keys require hardware backing.
• Weeks 3-6, algorithm and root-of-trust design. Standardize on AES-256-GCM for data at rest and TLS 1.3 for data in transit. Choose the HSM deployment pattern per tier. Document availability design for any self-managed HSM cluster.
• Weeks 6-12, envelope encryption and rotation. Implement DEK/KEK separation, schedule KEK rotation, and define re-encryption procedures for any directly encrypted data. Test on a non-production key set first.
• Weeks 10-14, logging and evidence. Route all key operation logs to immutable storage and verify retention covers the audit period.
• Weeks 12-16, access review. Conduct a full review of key policies, remove stale principals, and document separation of duties for key administrators.
• Weeks 14-18, audit preparation. Assemble the control matrix, map controls to applicable frameworks, and perform a dry-run evidence review with someone outside the team.

Teams with broader programs should integrate this into the shared control mapping covered in our guide to enterprise compliance standards, where encryption and key management align with GDPR Article 32, SOC 2 CC6, and ISO 27001 Annex A.8.24 simultaneously. The most important practice is treating rotation as a monitored migration and maintaining evidence in a searchable store, since that is what Type II or surveillance audits examine.

Related Reading

More in-depth coverage from this blog on closely related topics:

• Enterprise Key Management Strategies
• Enterprise Compliance Standards
• How to Set Up End-to-End Encryption
• What Is Network Segmentation for Security?

Sources and References

Sources cited while researching and writing this article:

• Confidential Computing Expands from CPUs to GPUs, Containers, and Agentic AI as Enterprise Demand Accelerates
• Encryption at Rest vs. In Transit: TLS, AES-256, Key Management (2026)
• Data at Rest vs In Transit vs In Use: Encryption Guide (2026)
• Amazon S3 will now encrypt all new data with AES-256 by default
• RFC 8996
• Browsers to block access to HTTPS sites using TLS 1.0 and 1.1 starting this month
• Encryption at Rest and in Transit: Implementation Guide
• South Korean startup platform breach exposes key management failures
• Google: Gmail client-side encryption now publicly available
• Encryption at Rest vs In Transit: What You Must Know
• Article 32