AWS’s Quantum-Resistant Signing Guide Shows Where Policy Stops
The October 12 deployment guides connect keys, identities and software verification, while leaving application-level cryptography outside cloud API controls.
.jpg){kind=link}
AWS has published a two-part guide to quantum-resistant software signing that makes a crucial boundary visible: controlling a cloud service is different from controlling every application running in that cloud. The October 12 tutorials combine existing capabilities; AWS Key Management Service (KMS) added ML-DSA signing in June 2025.[1][2][5]
ML-DSA, standardized by NIST in August 2024, verifies digital signatures intended to remain secure against a future large-scale quantum attacker. Signatures help establish who signed data and whether it changed. This is preparation for future attacks, not evidence that present quantum computers can forge deployed signatures.[3]
The design links KMS-held signing keys, Private CA certificates and Roles Anywhere authentication for external build agents. It signs software artifacts and a software bill of materials, the dependency inventory accompanying a release. A signed statement binds that inventory to a specific artifact through its digest, a content-derived identifier.[1]
There are implementation details behind the architecture. Current KMS documentation limits direct signing input to 4 KB. Larger inputs use an externally computed, 64-byte message representative through EXTERNAL_MU. AWS explicitly distinguishes this procedure from the separate HashML-DSA construction in the standard; substituting an arbitrary file hash is not equivalent.[4]
The policy boundary is equally important. Service control policies and identity permissions can constrain selected AWS API operations, but they do not police OpenSSL or application-level signing inside EC2 instances, containers or Lambda functions. Part 2 also leaves Roles Anywhere controls outside its scope, despite that service appearing in the pipeline.[2]
AWS illustrates an organization choosing ML-DSA-65 and ML-DSA-87 while excluding ML-DSA-44. That is an example organizational policy, not a finding that ML-DSA-44 is insecure. The guide calls for testing controls outside production; broad restrictions can interrupt legitimate workflows.[2]
QubitWire’s analysis: a valid signature is evidence about origin and integrity, not a certificate that software is harmless or its dependency inventory complete. Algorithm choice, access policy and release verification therefore answer separate questions. Passing one check cannot establish that the entire delivery process meets its security goals.[3]
A useful next test would deliberately alter an artifact, substitute a correctly signed inventory belonging to another release, and confirm that deployment rejects both. An unchanged, authorized release should still pass. Those paired tests would probe enforcement at the point of use, beyond merely demonstrating that a signing key works.[1]