Encryption and Key Management

Encryption and key management form the final defense control in protecting cardholder data from unauthorized disclosure, ensuring that even if other security controls fail, the data remains unreadable to unauthorized identities. PCI DSS Requirement 3 mandates protecting stored account data through strong cryptography, while Requirement 4 requires protecting cardholder data with strong cryptography during transmission over open, public networks. The effectiveness of encryption, however, depends entirely on proper key management—cryptographic keys must be generated, stored, distributed, rotated, and destroyed using processes that prevent unauthorized access to key material. In cloud environments, managed encryption services, and automated key lifecycle management provide opportunities to implement cryptographic controls and key management practices with greater security, operational efficiency, and compliance auditability than traditional on-premises key management approaches. 

Encryption and Key Management within the AWS SRA

The AWS SRA provides foundational guidance for encryption and key management that directly supports key elements of PCI DSS:

Using AWS KMS with customer-managed keys for encryption at rest allows customers to render stored account data unreadable, addressing Requirements 3.5.1 and 3.5.1.1. 

For Managed Services: When customers use AWS managed services such as Amazon RDS or Amazon S3 with customer managed keys, encryption is applied above the disk or partition level at the application layer running on top of the abstracted infrastructure. This distinction is significant for Requirement 3.5.1.2, With customer managed keys, access to the data and access to the encryption key are separated: a user or role must have discrete authorization for the AWS service and then separate permissions to use the encryption key in KMS. This separation of access addresses the intent of Requirement 3.5.1.2 for managed services. Additionally, the customer retains full control over the key lifecycle, they can disable the key, revoke access through key policy or grant changes, or schedule key deletion at any time, immediately rendering all associated data unreadable.

For Storage Services: For Storage Mediums such as Amazon EBS, Amazon EFS, and Amazon FSx, which are the virtual equivalent of physical disks presented to the customer, KMS encryption alone may not satisfy Requirement 3.5.1.2. Once these volumes are mounted or attached, all data is accessible in decrypted form to anyone with operating system level access, which is functionally equivalent to disk level encryption where access equals decryption. If customers store cardholder data on these storage solutions, additional data level encryption at the file, folder, or application level is needed to ensure that access to the storage medium does not automatically provide access to cleartext PAN (Requirements 3.5.1 and 3.5.1.2).

The AWS SRA illustrates the recommended distribution model for key management, where the AWS KMS key resides within the same AWS account as the resource to be encrypted.  AWS KMS manages the complete key lifecycle within its backed HSMs, where symmetric key material cannot be exported in plaintext. For customer managed keys, customers can configure automatic rotation with a customizable period, or invoke on-demand rotation at any time. AWS is responsible for the physical security and logical protection of key material within its HSM infrastructure (supporting Requirements 3.6.1.2 and 3.6.1.4), while customers retain responsibility for defining key policies, managing access grants, and controlling which principals and services can use each key. KMS supports key generation within its HSMs or import of customer-provided key material (BYOK), secure distribution of data keys within the service, and cryptographic erasure of key material when deletion is initiated by customers. The default symmetric key spec (SYMMETRIC_DEFAULT) is AES-256-GCM. However, KMS also supports asymmetric keys (RSA 2048/3072/4096, ECC) and HMAC keys. For symmetric encryption keys used for data at rest, AES-256 is the only option. (Requirements 3.6 and 3.7)

Both AWS KMS and AWS CloudHSM support generation and tracking of cryptographic keys, enabling customers to maintain inventories of keys in use including algorithms, key strength, key custodians, and cryptoperiods, supporting compliance with Requirement 3.6.1.1.

AWS CloudTrail logs all KMS and CloudHSM API calls, providing a complete audit trail of key management activities — including key creation, rotation, usage, policy changes, and deletion — supporting the auditability requirements across Requirements 3.6 and 3.7.

Design Consideration: Use AWS KMS for native AWS integrations and a fully managed, cost-effective key management system. Use AWS CloudHSM when you need dedicated, single-tenant hardware, the ability to export key material, or compliance mandates that prohibit the cloud provider from possessing logical access to your keys. For more detailed design decision refer to AWS cryptography services decision guide.

AWS Certificate Manager provisions and manages SSL/TLS certificates for services such as Amazon CloudFront, Amazon API Gateway, and Elastic Load Balancers, and enables customers to maintain an inventory of certificates in use with relevant metadata including issuing certificate authority and expiration dates, supporting Requirement 4.2.1.1 for maintaining an inventory of trusted keys and certificates. (Requirement 4.2.1.1)

AWS Secrets Manager supports secure storage and automated rotation of SSL/TLS certificates used to protect cardholder data in transit. When certificates are stored in Secrets Manager, rotation is managed through a custom AWS Lambda rotation function that handles certificate renewal and deployment to target resources, as the default managed rotation feature does not support certificate rotation. This capability complements AWS Certificate Manager for certificates that cannot be managed directly through ACM, such as certificates used by Amazon EMR or other services requiring custom certificate deployment, supporting Requirement 4.2.1.1 for maintaining an inventory of trusted keys and certificates..

VPC endpoints powered by AWS PrivateLink enable private connectivity between VPCs and supported AWS services, ensuring traffic remains on the AWS network backbone and does not traverse open, public networks. Because Requirement 4.2 specifically applies to PAN transmitted over open, public networks, traffic routed through PrivateLink endpoints to AWS services can be considered out of scope for Requirement 4.2 encryption requirements — though this scoping determination should be documented in the network segmentation documentation and validated with the QSA during the assessment. (Requirement 4)

Externally exposed AWS services such as Amazon CloudFront, Amazon API Gateway, and Elastic Load Balancers support transport encryption of TLS 1.2 or greater with configurable security policies to enforce strong cryptography during transmission over open, public networks. (Requirement 4.2.1)

Encryption and Key Management beyond the AWS SRA

Some incremental enhancements may be needed to extend the AWS SRA for alignment with additional PCI DSS requirement elements:

AWS Database Encryption SDK to implement attribute level encryption: Deploy client side encryption using the AWS Database Encryption SDK to implement attribute level encryption for DynamoDB tables storing cardholder data, ensuring PAN is encrypted at the application layer before being written to the database, providing defense in depth independent of service level encryption (Requirement 3.5.1). You can also use Amazon Relational Database Service (Amazon RDS) for SQL Server support for column-level data encryption. Column-level encryption provides encryption at a more granular level of data that can be applied on all or selected columns. With column-level encryption, you can define different encryption keys for each different column. Refer to 'Column-level encryption on Amazon RDS for SQL Server for more details on column level encryption.

Enable automatic key rotation for KMS customer-managed keys: Configure annual automatic rotation for KMS keys used to encrypt stored account data to satisfy cryptoperiod requirements. Use AWS Config to detect KMS keys that do not have automatic rotation enabled and trigger AWS Systems Manager Automation to remediate non-compliant keys. Customers are responsible for defining cryptoperiods appropriate to their environment and key usage. (Requirements 3.7.4)

Configure encryption by default for all storage services: Enable Amazon S3 default bucket encryption with SSE-KMS using customer-managed keys, enable Amazon RDS encryption during instance creation, and enable Amazon EBS encryption by default in account settings. Deploy AWS Config to detect unencrypted storage resources and trigger automated remediation to ensure all stored account data is rendered unreadable. (Requirement 3.5)

Deploy Amazon Macie for SAD and PAN discovery and data retention monitoring: Enable Amazon Macie across S3 buckets in the cardholder data environment to continuously discover and classify stored PAN. Use Macie findings to identify unauthorized PAN storage locations and support data retention minimization by flagging data that exceeds defined retention periods for automated or manual purging. (Requirement 3.2.1 and 12.10.7)

Implement application-level PAN masking and truncation: While AWS services provide infrastructure-level encryption, customers are responsible for implementing application-level controls to render PAN unreadable when displayed. Use AWS Lambda functions to implement masking (displaying only first six and last four digits) or truncation when PAN must be displayed, ensuring full PAN is never displayed except for users with a legitimate business need (Requirement 3.4.1).

Enforce TLS 1.2 minimum for all data in transit: Configure Application Load Balancer security policies, Amazon CloudFront distributions, and Amazon API Gateway stages to require TLS 1.2 . It is recommended to use TLS 1.3 where applicable as it provides support for  Post Quantum cryptography. The Elastic Load Balancing (ELB) new post-quantum TLS (PQ-TLS) based security policy  ELBSecurityPolicy-TLS13-1-2-Res-PQ-2025-09 or ELBSecurityPolicy-TLS13-1-2-Res-FIPS-PQ-2025-09 .Deploy AWS Config to detect load balancers, CloudFront distributions, or API Gateway stages configured with security policies that permit TLS versions below 1.3, and trigger automated remediation. Configure AWS SDKs to enforce TLS 1.3 or higher when accessing public AWS service endpoints. (Requirement 4.2.1)

Implement certificate lifecycle management and inventory: Use AWS Certificate Manager to automate certificate renewal and deploy AWS Config to maintain a current inventory of all trusted keys and certificates used to protect PAN during transmission, including issuing certificate authority and expiration dates, enabling rapid response to discovered vulnerabilities in cryptographic protocols. (Requirement 4.2.1.1)