How to Upgrade to Post-Quantum Cryptography Using AWS KMS

Upgrading to post-quantum cryptography with AWS KMS starts by identifying systems that rely on traditional encryption algorithms vulnerable to future quantum attacks. AWS supports quantum-resistant key exchange through hybrid TLS and emerging cryptographic standards.

Organizations should inventory sensitive data, enable quantum-safe encryption where available, update applications to support new algorithms, and test interoperability.

If businesses combine AWS key management service with post-quantum security practices, they can protect long-term data confidentiality and prepare their cloud infrastructure for the quantum computing era.

How to Upgrade to Post-Quantum Cryptography Using AWS Key Management Service: Step-by-Step Guide 

Upgrading to Post-Quantum Cryptography (PQC) in AWS Key Management Service (KMS) is the process of transitioning your cloud security infrastructure from classical encryption algorithms to new, quantum-resistant algorithms. This upgrade is critical to defend against “harvest now, decrypt later” attacks, where adversaries steal encrypted data today to decrypt it when powerful quantum computers become available.

In AWS Key Management Service, this upgrade involves two primary actions. First, you must enable hybrid post-quantum TLS (using ML-KEM) to protect data moving across your network. Second, you must adopt quantum-resistant digital signatures (using FIPS 204 ML-DSA) to secure data authenticity, firmware updates, and identity tokens. 

Let’s explore a complete, step-by-step roadmap to auditing your environment, updating your AWS tools, and deploying these quantum-safe standards without disrupting your current operations.

Understanding the Quantum Threat: The “Why”

Quantum computing represents a massive leap in processing power. While beneficial for medicine and science, it poses an existential threat to modern cybersecurity.

The “Harvest Now, Decrypt Later” Threat

Currently, the internet relies on public-key cryptography (like RSA and Elliptic Curve Cryptography) to secure data in transit and verify digital identities. These algorithms rely on complex mathematical problems, such as factoring large prime numbers. For classical computers, these problems take thousands of years to solve.

However, a future Cryptographically Relevant Quantum Computer (CRQC) running Shor’s algorithm could solve these problems in hours or minutes. 

While a CRQC does not exist yet, adversaries are currently executing “harvest now, decrypt later” attacks. They intercept and store highly sensitive encrypted traffic today. Their goal is to hold onto this data until quantum technology matures enough to break the encryption and reveal the secrets inside. 

If your data has a long shelf life—such as financial records, state secrets, or personal health information—it is already at risk.

The NIST Standards: FIPS 203, FIPS 204 and FIPS 205

To combat this, the National Institute of Standards and Technology (NIST) spent years evaluating new cryptographic algorithms that can resist quantum attacks. These new algorithms are built on different mathematical foundations, like lattice-based cryptography, which quantum computers cannot easily solve.

The finalized standards include:

• FIPS 203 (ML-KEM): Formerly known as CRYSTALS-Kyber. This is a Key Encapsulation Mechanism used to establish secure encryption keys over a public channel. It protects data in transit.
• FIPS 204 (ML-DSA): Formerly known as CRYSTALS-Dilithium. This is a Digital Signature Algorithm used to verify the authenticity and integrity of data.
• FIPS 205 (SLH-DSA): Formerly known as SPHINCS+. This is a stateless hash-based digital signature algorithm, serving as a backup to ML-DSA.

AWS’s PQC Timeline and Commitment

Amazon Web Services (AWS) has been at the forefront of the PQC transition. They have integrated PQC into their s2n-tls library, updated AWS Certificate Manager (ACM), and recently introduced FIPS 204 ML-DSA digital signatures directly into AWS KMS. By building these tools into the AWS ecosystem, Amazon allows organizations to achieve cryptographic agility—the ability to swap out old algorithms for new ones rapidly and securely.

Key Post-Quantum Technologies in AWS Key Management Service

Understanding what needs to change is the first step in your migration. Not all encryption needs to be replaced. For example, symmetric encryption (like AES) is already considered quantum-safe if the key size is large enough. The vulnerability lies purely in asymmetric (public-key) cryptography.

Step-by-Step Guide: Upgrading to Post-Quantum Cryptography in AWS KMS

Transitioning to post-quantum cryptography is not a simple “flip of a switch.” It requires careful planning, updating client software, and testing. Follow these six detailed steps to upgrade your AWS KMS infrastructure safely.

Step 1: Inventory and Prioritize Cryptographic Workloads

Before you can upgrade, you must know exactly where classical cryptography is being used in your AWS environment.

1. Map Your Data Flows: Identify all services that terminate TLS connections, such as Application Load Balancers (ALBs), API Gateways, and Amazon CloudFront distributions.
2. Audit KMS Keys: Use the AWS Management Console or the AWS CLI to list all your KMS keys. Look specifically for asymmetric keys with usage set to SIGN_VERIFY that rely on RSA or ECC (Elliptic Curve) specifications.
3. Prioritize by Risk: Not all systems need an immediate upgrade. Prioritize workloads that handle data with long-term confidentiality needs (data that will still be sensitive 10 to 20 years from now). Authentication systems, identity providers, and firmware signing keys should also be at the top of your list.

Step 2: Update AWS SDKs and Tools for Client-Side Readiness

AWS operates on a shared responsibility model. While AWS has updated their server-side endpoints to support PQC, your client-side applications must be updated to negotiate these new protocols.

1. Update the AWS CLI: Ensure all administrative machines and CI/CD runners are using the latest version of the AWS Command Line Interface (v2).
2. Upgrade AWS SDKs: Update your application code dependencies. AWS has rolled out post-quantum TLS support across its major SDKs (including Java, Rust, Go, Python/Boto3, Node.js, and .NET).
3. Update AWS Secrets Manager Agents: If you use agents to retrieve secrets, ensure they are patched to the latest versions so they can utilize hybrid post-quantum TLS when communicating with AWS endpoints.

Step 3: Enable Hybrid Post-Quantum TLS (ML-KEM) for Data in Transit

To protect data moving between your applications and AWS KMS against “harvest now, decrypt later” attacks, you must enable hybrid TLS.

AWS uses a “hybrid” approach. This means they do not rely solely on the new ML-KEM algorithm. Instead, they combine a proven classical algorithm (like X25519) with the new post-quantum algorithm (ML-KEM). If a flaw is ever discovered in the new quantum algorithm, the classical algorithm still protects your data.

1. Configure API Endpoints: When your application makes an API call to AWS KMS (for example, calling GenerateDataKey), the underlying AWS SDK handles the TLS handshake. By updating the SDKs in Step 2, your clients will automatically advertise support for hybrid ML-KEM cipher suites.
2. Check s2n-tls: If you manage your own TLS terminations on EC2 instances using Amazon’s s2n-tls library, ensure you have enabled the specific security policies that prefer post-quantum key exchange.
3. Use AWS Certificate Manager (ACM): If you are protecting inbound traffic to your AWS environment, associate a post-quantum TLS security policy with your Application Load Balancers or API Gateways via ACM.

Step 4: Implement Quantum-Resistant Digital Signatures (ML-DSA)

AWS KMS now natively supports the FIPS 204 ML-DSA standard. You can create KMS keys specifically designed for quantum-resistant digital signatures. AWS offers these in three security levels, corresponding to different NIST parameters: ML_DSA_44, ML_DSA_65, and ML_DSA_87.

Here is how to create an ML-DSA key using the AWS CLI. In this example, we will use ML_DSA_65, which balances high security with performance.

Bash

aws kms create-key \
    --key-spec ML_DSA_65 \
    --key-usage SIGN_VERIFY \
    --description "Post-Quantum Signature Key for Code Signing"

Once the key is created, you will receive a Key ID. You can then use this Key ID to sign data.

Bash

aws kms sign \
    --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \
    --message "Your critical data to be signed" \
    --message-type RAW

Step 5: Handle Large Payloads with EXTERNAL_MU

One technical nuance of using ML-DSA in AWS KMS is payload size limits. By default, AWS KMS limits the size of the RAW message you can send directly to the service for signing to 4096 bytes.

For classical algorithms like RSA, you would typically hash a large file locally (using SHA-256) and send only the small hash to KMS to be signed. However, the FIPS 204 ML-DSA standard strictly defines how hashing must occur. It requires a specific pre-processing step using the SHAKE256 hash function, known as Message Unforgeability (MU).

If your data is larger than 4096 bytes, you must perform this SHAKE256 hashing locally on your client machine before sending it to AWS KMS.

1. Hash your large file locally using SHAKE256.
2. Format the API call to AWS KMS, changing the –message-type from RAW to EXTERNAL_MU.

Bash

aws kms sign \
    --key-id <your-ml-dsa-key-id> \
    --message fileb://your_local_shake256_hash.bin \
    --message-type EXTERNAL_MU

This ensures your applications remain compliant with NIST FIPS 204 standards while bypassing the 4096-byte payload limit over the network.

Step 6: Monitor, Test and Verify using CloudTrail

The final step is proving that your transition was successful and that your systems are actually using the new algorithms.

1. Enable AWS CloudTrail: Ensure CloudTrail is logging all data-plane API events for KMS.
2. Query the Logs: Use Amazon Athena or CloudWatch Log Insights to query your CloudTrail logs. Look at the Sign and Verify API calls.
3. Verify Key Specs: Check the keySpec field in the CloudTrail event record. It should explicitly show ML_DSA_44, ML_DSA_65, or ML_DSA_87. If you see RSA_2048 or ECC_NIST_P256, that specific workflow has not been upgraded yet.
4. Test Failbacks: Temporarily block classical cipher suites in a staging environment and ensure your applications successfully negotiate the TLS connection using purely post-quantum/hybrid methods.

The Performance Impact of Post-Quantum Cryptography

Post-quantum cryptography relies on highly complex mathematics, primarily lattice-based structures. While these are secure against quantum computers, they come with a performance cost compared to classical algorithms like RSA and ECC. You must account for these changes in your cloud architecture.

Bandwidth Considerations

The most significant impact of PQC is the size of the cryptographic keys and the resulting digital signatures. Classical ECC signatures are measured in a few dozen bytes. ML-DSA signatures are measured in kilobytes.

• If your application relies on high-volume, low-bandwidth communication (such as IoT devices communicating with AWS IoT Core), sending multi-kilobyte signatures can cause network congestion.
• You may need to adjust timeout settings on your API Gateways or load balancers to accommodate the longer transmission times.

Latency and CPU Overhead

While ML-KEM and ML-DSA are generally fast to compute (sometimes even faster than RSA at generating signatures), the massive size of the keys means more data must be processed and parsed. This can lead to minor increases in CPU utilization on your client-side applications. Always conduct thorough load testing in a staging AWS environment before pushing PQC keys into high-traffic production workloads.

Best Practices for Cryptographic Agility

Cryptographic agility is the ability of your IT infrastructure to easily and rapidly switch between different cryptographic algorithms without causing massive system failures. As PQC standards evolve, maintaining agility is just as important as the initial upgrade.

Embrace Hybrid Deployments

Do not abandon classical cryptography entirely just yet. Use AWS’s hybrid modes for TLS. A hybrid approach encapsulates the TLS handshake using both a classical algorithm (like ECDH) and a post-quantum algorithm (like ML-KEM). This guarantees that your connection is at least as secure as current standards, while adding a protective layer against future quantum attacks. It also satisfies current FIPS 140-2/3 compliance mandates that may not yet fully recognize standalone PQC.

Leverage AWS Managed Services

Do not try to build your own cryptographic libraries. Lean heavily on AWS managed services. Amazon S3, AWS Certificate Manager (ACM), and AWS Secrets Manager abstract away the immense complexity of TLS negotiations and key rotations. By simply checking a box to update an ACM security policy, you apply post-quantum security to an entire fleet of load balancers automatically.

Enforce IAM Policies for PQC

Prevent your developers from accidentally creating vulnerable classical keys. Use AWS Identity and Access Management (IAM) condition keys to enforce PQC adoption. You can write an IAM Service Control Policy (SCP) that denies the kms:CreateKey action if the kms:KeySpec is set to an older RSA or ECC specification, effectively forcing all new signature keys to be ML-DSA.

Implement Centralized Key Management and Rotation

Quantum security is not a “set it and forget it” task. As NIST continues to refine these algorithms, new versions will be released. Centralize all your cryptographic assets inside AWS KMS. Ensure that automatic key rotation is enabled for your symmetric data keys, and establish a clear, documented cadence for rotating your asymmetric ML-DSA signing keys.

Build Crypto-Agility into CI/CD Pipelines

Hardcoding key IDs or cryptographic algorithms directly into your application code is a major anti-pattern. Instead, design your software to query AWS Systems Manager Parameter Store or AWS Secrets Manager to retrieve the algorithm it should use. This way, if you need to upgrade from ML_DSA_44 to ML_DSA_65 in the future, you only need to change a single parameter in AWS, and your CI/CD pipeline will propagate the new cryptographic standard across your entire application fleet automatically.

Frequently Asked Questions (FAQ)

Do I need to replace AES-256 for post-quantum security?

No, you do not need to replace AES-256. Symmetric encryption algorithms like AES-256 are already considered highly resistant to quantum attacks. The primary focus of the PQC upgrade is replacing asymmetric (public-key) algorithms like RSA and ECC used for key exchange and digital signatures.

Does AWS KMS support Bring Your Own Key (BYOK) for PQC?

Currently, importing your own asymmetric key material (BYOK) for post-quantum algorithms like ML-DSA requires careful alignment with AWS KMS supported key specs. You must ensure that the key material was generated securely on-premises using the exact NIST FIPS 204 parameters before attempting to import it into AWS KMS. Check the latest AWS KMS documentation, as BYOK support for new PQC algorithms rolls out iteratively.

Will ML-DSA signatures affect my application’s performance?

Yes, ML-DSA will impact performance primarily through increased bandwidth usage. ML-DSA keys and signatures are significantly larger than classical ECC or RSA signatures—often spanning several kilobytes. While the computation speed is fast, transmitting these larger signatures over the network may introduce slight latency, which requires careful testing, especially in mobile or IoT environments.

What is the difference between ML-KEM and ML-DSA in AWS?

ML-KEM (FIPS 203) is a Key Encapsulation Mechanism used to securely establish a shared secret over an untrusted network; AWS uses it primarily in hybrid TLS for data in transit. ML-DSA (FIPS 204) is a Digital Signature Algorithm used to prove the authenticity and integrity of data; AWS KMS allows you to create ML-DSA keys to sign documents, code, and tokens natively.

Why do I need to use EXTERNAL_MU for large files in KMS?

AWS KMS has a strict 4096-byte limit for the RAW message type. Because the FIPS 204 standard requires a specific pre-processing hash using SHAKE256, you cannot simply send a standard SHA-256 hash to KMS like you did with RSA. You must compute the SHAKE256 hash locally on your client and use the EXTERNAL_MU message type to pass that pre-processed hash to KMS for signing.

Will upgrading to post-quantum keys in AWS KMS increase my AWS bill?

No, AWS does not charge a premium for using post-quantum algorithms. You pay the standard AWS KMS pricing for key creation, storage, and API requests, regardless of whether you are using classical (RSA/ECC) or post-quantum (ML-DSA) key specifications. However, keep in mind that the larger signature sizes of ML-DSA could marginally increase your data transfer out (DTO) costs if you are transmitting millions of signatures outside of the AWS network.

What happens if my clients don’t support hybrid post-quantum TLS yet?

Your connections will remain perfectly secure using current standards. If a client application, SDK, or older browser connects to an AWS endpoint and cannot support ML-KEM, the AWS server will gracefully fall back to classical, industry-standard TLS key exchange mechanisms (like X25519 or ECDHE). This ensures that your migration to PQC does not break backward compatibility with legacy systems.

Does enabling PQC in KMS automatically change how my S3 or EBS data is encrypted?

No, because it does not need to. Data at rest in services like Amazon S3 and Amazon EBS is protected using symmetric encryption (specifically AES-256), which is already considered quantum-safe. The post-quantum upgrades you make in AWS KMS are strictly for protecting data in transit (via ML-KEM) and securing digital identities and signatures (via ML-DSA). Your underlying AES-256 data encryption remains unchanged and secure.

Can I automatically rotate my existing RSA signing key to an ML-DSA key in AWS KMS?

No, you cannot automatically rotate a classical asymmetric key to a post-quantum key. Because the underlying mathematics and key sizes are fundamentally different, AWS KMS requires you to create a brand new ML-DSA key. You must then manually update your application configurations to use the new Key ID and carefully phase out the old RSA key once you have verified the new signatures are functioning correctly.

Are the new post-quantum algorithms in AWS KMS FIPS compliant?

Yes, the ML-DSA implementation in AWS KMS directly adheres to the finalized NIST FIPS 204 standards. However, the broader overarching FIPS 140-3 validation programs run by the government are still catching up to test these new algorithms. To ensure you meet current compliance mandates while adopting new standards, AWS utilizes hybrid cryptography and its AWS-LC (AWS libcrypto) module, which maintains FIPS 140-3 compliance while offering post-quantum protection.

Read Here: Microsoft Purview vs AWS Macie: Which is Best for AI Data Governance?

References

1. Alagic, G., Dang, Q., Moody, D., Robinson, A., Silberg, H., & Smith-Tone, D. (2024). Module-Lattice-Based Key-Encapsulation Mechanism Standard (Federal Information Processing Standards [NIST FIPS] 203). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.FIPS.203
   Cited by: 8
2. Campbell, R. (2025). Enterprise migration to post-quantum cryptography: Timeline analysis and strategic frameworks. MDPI. https://www.mdpi.com/2073-431X/15/1/9
   Cited by: 2
3. Dang, T., Lichtinger, J., Liu, Y., Miller, C., Moody, D., Peralta, R., & Robinson, A. (2024). Module-Lattice-Based Digital Signature Standard (Federal Information Processing Standards [NIST FIPS] 204). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.FIPS.204
   Cited by: 17
4. El Bizri, M., & Ahmad, M. (2026). Institutional approaches to post-quantum cryptography: A comparative analysis of migration frameworks. IEEE Access, 14, 3259–3283. https://doi.org/10.1109/ACCESS.2025.3650465
   Cited by: 5
5. Nagy, N. (2025). Module-lattice-based key-encapsulation mechanism performance measurements. MDPI. https://www.mdpi.com/2413-4155/7/3/91
   Cited by: 11

Read Here: How to Implement Agentic SRE on AWS: Step-by-Step Guide