- AWS Security published a method to block one ML-DSA variant, ML-DSA-44, across an organization using SCPs, IAM policies and permission boundaries.
- A deny list leaves any variant you have not named usable by default. An approved list blocks new variants until someone reviews them.
- The controls cover AWS service APIs only. Ask your teams where cryptography runs outside them, such as on EC2, in containers or in Lambda.
Writing a cryptography standard is the easy part. Making sure no engineer, script or pipeline departs from it is harder. A policy document cannot refuse a request. A cloud platform can. AWS Security has now published a worked example of how to turn an algorithm policy into controls that do the refusing.
What AWS published
The post is Part 2 of a series on quantum-resistant signing. It is written for security, governance and compliance teams. Its subject is KMS, Amazon's key management service. KMS lets customers create keys for ML-DSA, a post-quantum signature standard known as FIPS 204. Customers pick from variants numbered 44, 65 and 87, aimed at NIST security categories 2, 3 and 5.
The worked example imagines a company whose approved list holds only ML-DSA-65 and ML-DSA-87. Variant 44 is the one it wants to exclude. AWS is explicit that this is a standardization choice. It is not a claim that ML-DSA-44 is weak. The post calls ML-DSA-44 a valid choice, the most compact and fastest of the three.
How the control works
Inside KMS, each variant appears as its own key type, labelled ML_DSA_44, ML_DSA_65 or ML_DSA_87. All three share one signing algorithm, ML_DSA_SHAKE_256. So the variant is fixed when the key is made, not when a signature is requested. For keys held in KMS, AWS advises that the strongest single step is to block creation of the unwanted key type. With no such key in existence, nothing can sign with it through KMS.
The example service control policy (SCP) does two things. It denies kms:CreateKey for the ML_DSA_44 key spec. It also denies kms:Sign, kms:Verify and kms:GetPublicKey for that spec, which covers keys that already exist. Teams with multi-Region keys should also deny kms:ReplicateKey.
AWS warns against a blanket kms:* deny. It would also block DescribeKey, DisableKey and ScheduleKeyDeletion. Those are the actions needed to clean up the keys you are trying to remove.
An SCP denial cannot be overridden by IAM policies in member accounts. It does not apply to the organization's management account, so AWS advises keeping such workloads out of that account. For build and test accounts, AWS suggests IAM permission boundaries instead. A boundary works only on principals that have it attached, so something must enforce its attachment.
The idea underneath: a deny list governs what you have already thought about
The most useful part of the post is an admission. A control that names ML-DSA-44 allows everything it does not name. A newly introduced variant, including one nobody has evaluated, is usable until someone notices and adds it to the list.
The alternative is to write the rule around the approved list. The policy then refuses any request whose key type matches none of the approved entries. A new variant stays refused until someone adds it. The price is a policy change before teams can adopt a variant that has just been approved. The family-level SCP in Part 1 takes this shape, denying creation of any signing key whose key spec is not ML_DSA_*.
This shows a choice that is easy to miss in a standards meeting. Do you want to block first and approve later, or notice first and decide later? The first slows the engineer who wants a new option. The second leaves the security team watching for surprises. AWS calls both valid. The decision belongs to leadership, and it should be made on purpose.
The human cost is concrete. A pipeline fails on a denied key creation. The engineer sees an AccessDenied error naming a service control policy but not its contents. AWS notes the blocked user often cannot see the SCPs applied to their environment, so it advises documenting each SCP's ARN and purpose for support teams.
Where the controls stop
AWS is direct about the limits. These controls act on AWS service APIs, mainly KMS, AWS Private CA and ACM. Code that you run yourself falls outside their reach. OpenSSL or an application could still perform ML-DSA-44 signing on an EC2 instance, in a container or in a Lambda function.
Protocol-level use, such as OpenSSH's hybrid ssh-mldsa44-ed25519 authentication, is also outside their reach. Certificates imported through acm:ImportCertificate or iam:UploadServerCertificate are not algorithm-aware. CloudFront, API Gateway and IAM Roles Anywhere are not covered and need separate assessment.
AWS also lists the operations that can use an ML-DSA-44 key today as Sign, Verify and GetPublicKey. That list may grow as AWS adds features, so a block on use needs periodic review.
What to ask your team
Start with the approved list. Is there one, and does it exist as an enforced control or only as a document? Then ask which style your controls take. Do they name what is banned, or what is allowed?
Ask who is exempt. The management account sits outside SCPs. Ask what detects drift, since AWS pairs prevention with detection. Ask who owns the review schedule as the service adds operations.
Finally, ask where signing happens outside AWS APIs. Those places need their own controls. A policy enforced on part of the estate is a partial policy, and it should be reported to the board that way.
A cryptographic standard is only as strong as the places that can say no to it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: AWS Security.
