Best Practices for Securing AWS Payment Cryptography Deployments

As businesses adapt to a rapidly evolving digital payments landscape, ensuring the confidentiality, integrity, and compliance of financial transactions remains a top priority. AWS Payment Cryptography is a fully managed service that enables organizations to secure their payment processing applications using industry-standard cryptographic functions and key management, delivered with the scalability and reliability of the AWS Cloud.

We designed AWS Payment Cryptography to reduce the operational complexity and cost of managing on-premises hardware security modules (HSMs) by providing a cloud-native solution. The service enables payment providers, acquirers, facilitators, processors, and financial institutions to generate, store, manage, use, and exchange cryptographic keys needed for payment operations securely, under PCI standards and global regulations. The service offers high availability, elastic scalability, and strong compliance certifications, including PCI PIN, PCI P2PE, PCI DSS, and PCI 3DS. AWS Payment Cryptography eliminates operational burdens and streamlines secure key exchange, helping minimize risk and accelerate innovation in payment processing.

The service only permits connections secured through the HTTPS protocol, and supports hybrid post-quantum cryptography TLS key-exchange ciphers to protect operations with the service. It automatically prevents the misuse of keys across resources (such as attempting to decrypt PIN blocks) according to PCI rules.

In this post, we explore the security layers you can apply to protect your AWS Payment Cryptography deployment. These layers complement our existing Security Reference Architecture, which provides broader security guidelines for a multi-account environment. This post assumes you have already implemented those guidelines, including AWS IAM Identity Center.

Reference Architecture

The following diagram shows a sample deployment of a payment application. For simplicity, it omits connectivity to payment networks and other external systems and focuses on the application’s interaction with AWS Payment Cryptography.

Figure 1: AWS Payment Cryptography implementation with layered security controls isolating control plane activities from data plane ones

1. AWS Account

We strongly recommend using separate AWS accounts for different applications (for example, issuing vs. acquiring) as part of the AWS Well-Architected Framework, rather than consolidating everything into a single account. This approach provides natural security boundaries because AWS accounts provide strong isolation boundaries, and cross-account access requires explicitly configured permissions. Each account has its own service quotas and API rate limits, ensuring that issues in one environment (such as development) don’t affect others (such as production). This separation also simplifies cost tracking, security management, and compliance. For instance, you can maintain stringent security policies in production accounts while allowing more flexibility in development environments. Additionally, this structure reduces the blast radius of potential security incidents or operational problems, containing them within the affected account rather than affecting your entire infrastructure.

Organizations may choose to store their cryptographic keys in a central AWS account and use them across accounts, or have the keys stored directly in the application AWS account. Choose a centralized key-management model when multiple application accounts must use the same cryptographic keys.

Application Protection

The following sections detail the different security layers you can apply to protect AWS Payment Cryptography usage in an application environment that’s actively using it. For specific guidance on reducing PCI-DSS scope, you can refer to the whitepaper Architecting for PCI DSS Segmentation and Scoping on AWS.

2. Private Networks

Amazon Virtual Private Cloud (Amazon VPC) provides internal networking between applications and creates a natural network boundary. Consider isolating the application in its own VPC without access to the public internet. Create a separate VPC for key management operations such as creating, deleting, importing, and exporting keys.

PCI requirements demand that incoming and outgoing traffic in a Cardholder Data Environment (CDE) passes through firewalls. While AWS PrivateLink can secure communications to AWS Payment Cryptography (see section 5 and 7), communication with external systems may require additional controls. A common implementation pattern uses centralized ingress and egress through AWS Transit Gateway and AWS Gateway Load Balancer. Alternatively, you can use zero-trust mechanisms such as Amazon VPC Lattice or AWS PrivateLink to create endpoint-specific zero-trust authenticated consumption of your application, further reducing the application’s exposed surface.

You can complement the private networking setup by enabling Block Public Access in the VPC or account, further mitigating misconfiguration risks.

3. IAM Roles

IAM roles should follow the principle of least privilege by granting only the required actions to specific principals and keys within AWS Payment Cryptography. The following sample policy permits a single API action (VerifyCardData) on a single key. If this is the only policy attached, all other API actions are denied by default.

{
   "Version": "2012-10-17",
   "Statement": [
         {
            "Effect": "Allow",
            "Action": [
               "payment-cryptography:VerifyCardData"
            ],
            "Resource": [
               "arn:aws:payment-cryptography:us-east-1:111122223333:key/kwapwa6qaifllw2h"
            ]
         }   
   ]
}

If an application has dozens of keys, consider using tags on your keys, such as BIN = 123456, USAGE = TRANSACTION_PROCESSING, then using IAM policies filtered by resource tag condition keys to segment which keys the application can access. You can find samples of these policies in our samples GitHub repository.

4. Security Groups

Security groups act as stateful firewalls that protect VPC resources such as Amazon Elastic Compute Cloud (Amazon EC2) instances, containers, and VPC interface endpoints. Follow the principle of least privilege by configuring security groups to allow traffic only from and to the specific sources and destinations required for communication. You can use Security Group Referencing for simplified management. Here is an example showing a least-privilege security group that only allows traffic on port 443 from a specific application.

Figure 2: Security group configuration that allows inbound HTTPS traffic only from a specified source security group.

5. VPC Endpoint for the Data Plane

Interface VPC Endpoints allow you to restrict the traffic between your application and AWS Payment Cryptography using AWS PrivateLink, which secures the traffic without exposing data to the internet. AWS Payment Cryptography offers two endpoints: a data plane endpoint (com.amazonaws.us-east-1.payment-cryptography.dataplane), which handles day-to-day cryptographic operations such as PIN block translation, encryption, and decryption, and a control plane endpoint (com.amazonaws.us-east-1.payment-cryptography.controlplane), which handles mostly administrative activities, such as creating, importing, or deleting cryptographic keys. Evaluate which endpoint or endpoints are required for each VPC that interacts with AWS Payment Cryptography.

NOTE: Certain automated real-time application operations require control plane access, for example, dynamic key exchange with payment networks that requires the ImportKey or ExportKey operations. Consider handling this as a separate service with its own permissions rather than a monolithic role.

VPC Endpoints also support endpoint policies and security groups to further restrict which principals and services can invoke which actions through the endpoint.

Key Management Protection

Certain administrative tasks, such as creating, importing, exporting, or deleting keys, require elevated privileges and are typically performed manually. In this section, we outline an approach to secure AWS Payment Cryptography control plane operations through what we call the key management interface. We won’t cover security group or VPC endpoint configuration here, as we addressed those topics in the previous section.

6. Key manager IAM Role

The Key manager IAM role, by definition, must grant broader permissions over AWS Payment Cryptography key administration. You can limit its permissions to only the actions that the key manager requires when using the EC2 instance. You can find a sample policy for this role in our samples GitHub repository, and here is a snippet of what it would look like with only the ImportKey and ExportKey permissions.

{
   "Version": "2012-10-17",
   "Statement": [
         {
            "Effect": "Allow",
            "Action": [
               "payment-cryptography:ImportKey",
               "payment-cryptography:ExportKey"
            ],
            "Resource": "*"
         }   
   ]
}

7. VPC Endpoint for the Control Plane

AWS Payment Cryptography provides a control plane endpoint through AWS PrivateLink. This endpoint supports administrative operations, such as creating, importing, and deleting cryptographic keys. Apply the same security controls described in section 5, including endpoint policies and security groups.

8. EC2 Temporary Elevated Access through Systems Manager Session Manager

AWS Systems Manager Session Manager allows you to access an EC2 instance without opening administrative ports such as SSH or RDP. Temporary elevated access is a procedure to request, approve, and track the use of permissions to perform a specific task during a defined time window (for example, permission to use Session Manager for a specific instance). Temporary elevated access supplements other forms of access control, such as IAM Identity Center permission sets and multi-factor authentication. You can read more about how to implement this in our article Temporary elevated access for AWS accounts and the blog post Implementing just-in-time privileged access to AWS with Microsoft Entra and AWS IAM Identity Center.

By combining Session Manager with temporary elevated access, you grant users access to an EC2 instance to invoke AWS Payment Cryptography key administration APIs only after the approval workflow succeeds.

9. Multi-Party Approval for Root Keys

AWS Payment Cryptography supports AWS Organizations multi-party approval to protect the ImportKey API when the KeyMaterialType is RootCertificatePublicKey. Importing a Certificate Authority (CA) public key is a prerequisite for any key export operation. When this feature is enabled, even if an IAM principal has the correct policy to call ImportKey with KeyMaterialType: RootCertificatePublicKey, the operation enters a “pending” state and is executed only after multi-party approval is granted. Requiring approval from a configurable number of distinct users reduces the risk of key exfiltration by adding an approval gate when importing a Certificate Authority for asymmetric key exchange.

AWS Organization Controls

10. Service Control Policies

Service control policies (SCPs) are a type of organization policy that you use to manage permissions in your organization. SCPs offer central control over the maximum available permissions for IAM users and IAM roles in your organization. SCPs help you make sure your accounts stay within your organization’s access control guidelines. You can leverage these policies to limit access to AWS Payment Cryptography outside of specific VPCs or lock down permissions to specific IAM roles. You can find SCPs samples in our samples GitHub repository.

Conclusion

AWS Payment Cryptography provides the cryptographic functions and key management capabilities needed for payment applications, while the controls described in this post help you protect both day-to-day cryptographic operations and privileged key administration workflows. By separating data plane and control plane access, applying least privilege IAM roles, using VPC endpoints and security groups, implementing temporary elevated access, and enforcing AWS Organizations controls, you can reduce operational risk and support security and compliance objectives. Start by reviewing the AWS Payment Cryptography user guide and adapting the sample policies in the GitHub repository to your organization’s account structure, key management model, and PCI scope.