Encryption at Rest vs In Use

During a vendor security assessment, a TPRM team asked about encryption. The vendor confirmed AES-256 encryption at rest for all customer data , database-level encryption, storage volume encryption, backup encryption, all confirmed in their SOC 2 Type II report. The team noted it and moved on. What the assessment did not explore was that the database-level encryption was transparent encryption , the database engine decrypted data automatically on read and the application layer, all microservices, the analytics pipeline, and any user with database credentials received plaintext data. The encryption protected the storage medium from physical extraction. It provided zero protection against unauthorized application-layer access, against a compromised database credential, against an application vulnerability that exposed database query results, or against the insider threat of a privileged user querying the database directly. The encryption was real. It was real protection against a threat that was not the most likely threat.

Encryption coverage gaps cluster around five specific exposure scenarios:

• Transparent database encryption with broad query access , database-level encryption that decrypts automatically for any authenticated user or application, providing no protection against authorized but excessive access
• Plaintext data in application memory and logs , sensitive data decrypted for application processing and present in memory, application logs, error messages, and debugging output
• Unencrypted data in transit between services , internal service-to-service communication that passes decrypted data without TLS protection, exposing data to network-layer interception
• Plaintext in caches and temporary storage , decrypted data stored in Redis, Memcached, or other caching layers without re-encryption, accessible to any process with cache access
• Encryption key management gaps , encryption keys managed in the same environment as the data they protect, eliminating separation of key and ciphertext that makes encryption meaningful

Why this matters

Encryption at rest confirmation is one of the most frequently cited security controls in vendor questionnaire responses , it is visible, auditable, and documented in SOC 2 reports. For TPRM practitioners, the risk is that encryption at rest confirmation creates assurance about data protection that significantly overstates what has been protected. The threats that encryption at rest addresses , storage media theft, physical intrusion , are not the threats that produce most vendor data breaches. The threats that produce breaches , compromised credentials, application vulnerabilities, insider access , all operate on decrypted data that encryption at rest does not protect.

The access control dependency is the critical dimension. Encryption at rest is only as protective as the access controls on the keys and the systems that perform decryption. If any user with database access receives decrypted data, the encryption provides no protection against excessive database access. If the application decrypts data for processing and an application vulnerability exposes database results, the encryption provided no protection against the vulnerability. The encryption protects the storage layer. Access controls, application security, and key management protect the layers where breaches actually occur.

For TPRM practitioners, this creates a specific assessment obligation: asking not just whether data is encrypted but what threat the encryption addresses, what is not protected by the encryption at rest layer, and what compensating controls address the in-use exposure. A vendor who can articulate the threat model for their encryption implementation , what the encryption protects and what requires other controls , has engaged with encryption as a security architecture decision rather than a compliance checkbox.

Where most teams get this wrong

The most pervasive failure is treating encryption confirmation as data protection confirmation. AES-256 at rest is a strong encryption standard. It protects data at rest against specific threats. It provides no protection against any threat that operates through authorized decryption , which is how virtually all production data breaches occur. Confirming that data is encrypted at rest and concluding that data protection is addressed has confused the mechanism with the coverage.

The second failure is not asking about key management specifically. Encryption is only as strong as the protection of the encryption keys. Database encryption that uses keys stored in the same database server, cloud storage encryption that uses keys managed by the same cloud account, and backup encryption that uses keys stored alongside the backups all provide significantly weaker protection than encryption with properly segregated key management. The encryption algorithm is AES-256. The key management determines whether that algorithm means anything in practice.

• Treating encryption at rest confirmation as data protection confirmation , encryption at rest protects storage layer, not the application and access layer where breaches occur
• No key management assessment , encryption strength determined by key protection, not algorithm selection
• Not asking about in-transit encryption between internal services , internal service-to-service communication that bypasses TLS
• Not asking about plaintext in logs and caches , sensitive data in application logs, error messages, and caching layers
• No threat model question , whether the vendor understands what their encryption covers and what requires other controls

What good looks like

Mature vendor encryption programs implement encryption as a layered protection strategy , storage encryption for the physical layer, TLS for all in-transit communication, application-layer encryption for sensitive fields that should remain encrypted even within the application tier, and key management segregated from the data it protects. The encryption posture is understood in terms of what threats it addresses, and compensating controls explicitly address the in-use layer where encryption at rest provides no protection.

• Encryption at rest with segregated key management , HSM-managed keys or cloud KMS with separation between key access and data access
• TLS 1.2 or higher for all in-transit communication , including internal service-to-service communication, not just external-facing APIs
• Application-layer encryption for highest-sensitivity fields , field-level encryption that keeps sensitive fields encrypted even when the database decrypts the surrounding record
• Sensitive data excluded from logs , application logging configured to redact or omit sensitive field values from log output
• Cache encryption for sensitive data , caching layer encryption preventing plaintext sensitive data from persisting in caches
• Encryption threat model articulated , vendor able to describe what threats their encryption addresses and what compensating controls cover the in-use layer

Tooling

Addressing encryption coverage across all layers requires tools that extend protection beyond the storage layer to application and transit contexts.

Key Management , AWS KMS, Azure Key Vault, HashiCorp Vault, Thales

Key management services provide the cryptographic key lifecycle management that determines whether encryption is meaningfully protective. AWS KMS and Azure Key Vault provide cloud-native key management with separation between key access and data access , a different IAM policy controls who can use the encryption key versus who can read the encrypted data. HashiCorp Vault provides application-level secrets and key management for multi-cloud environments. For TPRM practitioners, asking what key management service the vendor uses and how key access is segregated from data access is the single most important encryption governance question beyond algorithm confirmation.

Field-Level Encryption , Crypteron, AWS DynamoDB Encryption Client, MongoDB CSFLE

Field-level or client-side field-level encryption keeps specific sensitive fields encrypted at the application layer, meaning the database stores and returns encrypted ciphertext even for an authenticated application user , the application must hold the decryption key separately to access the field value. This extends encryption protection to the application layer for the most sensitive fields. MongoDB Client-Side Field Level Encryption (CSFLE) provides this capability for MongoDB deployments. For TPRM practitioners, asking whether the vendor uses field-level encryption for the most sensitive data categories surfaces whether encryption coverage extends beyond the storage layer.

Confidential Computing , Intel SGX, AMD SEV, AWS Nitro Enclaves

Confidential computing platforms provide hardware-based trusted execution environments that protect data in use , keeping data encrypted even in memory during processing, protecting it from privileged OS access and hypervisor compromise. AWS Nitro Enclaves and Azure Confidential Computing provide cloud-native confidential computing. These are emerging capabilities not yet in widespread enterprise use, but vendors processing the most sensitive data categories , genomics, financial trading, classified government data , are beginning to deploy them. For TPRM practitioners, awareness of confidential computing as the direction of travel for in-use protection enables informed conversations about the current state and roadmap.

Governance challenges

The governance challenge with encryption is the algorithm-versus-architecture confusion that the reviewer exemplifies. AES-256 is a strong algorithm. Whether it is applied in a way that provides meaningful protection depends entirely on key management, decryption access controls, and what happens to data after it is decrypted. An encryption program that specifies the algorithm without addressing key management, access controls, and in-use exposure has documented a cipher choice without documenting a security architecture.

For TPRM programs, the practical governance shift is from algorithm confirmation to threat model confirmation , asking vendors to describe what threats their encryption addresses and what compensating controls address the threats that encryption at rest does not cover. A vendor who can articulate that response has thought about encryption as security architecture. A vendor who can only confirm AES-256 has thought about encryption as a compliance requirement.

• Ask about key management specifically , not just what algorithm, but how keys are managed, stored, and access-controlled
• Ask about in-transit encryption between internal services , TLS coverage extending to service mesh and internal communication
• Ask about sensitive data in logs , whether application logging redacts sensitive field values
• Ask vendors to describe what their encryption covers , what threat it addresses and what compensating controls address the in-use layer
• Include encryption architecture in vendor assessments , not just algorithm confirmation but key management, transit coverage, and field-level encryption for highest-sensitivity data

If you are a small team

Add two questions to your encryption assessment that go beyond algorithm confirmation. First: how are your encryption keys managed and who has access to the keys versus who has access to the encrypted data , are these segregated? Second: what protects sensitive customer data during application processing, after the storage encryption has decrypted it , specifically, what prevents a database administrator with valid credentials from accessing all customer data in plaintext? The first question surfaces key management maturity. The second forces a threat model conversation that reveals whether the vendor understands what encryption at rest does and does not protect.

• Add key management segregation to your encryption assessment , who accesses keys vs who accesses data
• Ask what protects data during application processing after decryption
• Ask about TLS coverage for internal service communication, not just external APIs
• Ask whether sensitive data appears in application logs

What to require

Ask directly:

"How are your encryption keys managed , specifically, are they stored in a separate key management service with access controls segregated from the data they encrypt, or are they managed in the same environment as the data?"

"What protects customer data during application processing, after your storage encryption has decrypted it , specifically, what prevents a user with valid database credentials from querying all customer data in plaintext?"

"Is TLS applied to all internal service-to-service communication within your application architecture, and does sensitive customer data appear in application logs or error messages in plaintext?"

Expect as evidence

• Key management architecture description , KMS service, key access segregation from data access
• In-use protection description , access controls, field-level encryption, or confidential computing for highest-sensitivity data
• TLS coverage confirmation for internal service communication
• Log redaction confirmation for sensitive data fields

A vendor who responds to the key management question with 'we use AES-256' has described the algorithm again. Ask specifically where the keys are stored and who can access them. An encryption key stored on the same server as the encrypted data provides the same protection as no encryption if that server is compromised. The algorithm is the lock. The key management is whether the key hangs next to the door.

How to evidence it

Encryption requirements are addressed in PCI-DSS (strong cryptography for cardholder data), HIPAA's encryption addressable specification, GDPR's pseudonymization and encryption as appropriate technical measures, and NIST SP 800-111. Demonstrating due diligence requires evidence that encryption architecture was assessed , not just algorithm confirmation.

• Vendor assessment records documenting key management, in-use protection, and TLS coverage questions
• Key management architecture documentation for highest-risk vendor relationships
• Encryption threat model documentation , what the encryption covers and what compensating controls address
• TLS coverage confirmation for service communication

Key Takeaway

AES-256 is a strong algorithm. It protects data on the storage medium from physical extraction. It decrypts automatically when the database processes a query. After decryption, the data flows through the application in plaintext, through the service mesh in plaintext, into the cache in plaintext, and onto the screen of anyone with valid credentials in plaintext. The encryption at rest protects against the threat nobody is executing , disk theft. The access controls, application security, and key management protect against the threats that produce actual breaches. Confirming the algorithm is confirming the lock on the vault. Asking who holds the keys, who can open the vault, and what the data looks like once it leaves the vault is asking about the security. Ask all three questions.

More on Privacy

• Cross-Border Data Flow Risks
• Data Access Logging Gaps
• Data Access Privilege Creep