AWS Details Controls for Enforcing ML-DSA Algorithm Policies
Summary
AWS explains how to enforce approved ML-DSA variants with KMS condition keys, SCPs and IAM, and how to handle services without algorithm-aware controls through provisioning restrictions and drift detection.
Key points
- The example policy permits ML-DSA-65 and ML-DSA-87 while excluding ML-DSA-44 as a standardization choice, not because ML-DSA-44 is insecure.
- AWS KMS evaluates kms:KeySpec on CreateKey, Sign, Verify, and GetPublicKey, enabling controls against creating or using excluded keys; kms:SigningAlgorithm cannot distinguish the ML-DSA variants.
- SCPs can apply at the organization root or an OU, but do not restrict the management account. IAM policies and permission boundaries offer principal-level alternatives.
- AWS Private CA has no algorithm condition key. The guidance recommends restricting CA creation, pinning approved algorithms in trusted provisioning, controlling the trust chain, and using CloudTrail and AWS Config to detect drift.
- Certificate import and upload APIs are not algorithm-aware. At the time of writing, ACM and ALB/NLB listeners do not support ML-DSA certificates, so related controls are partly forward-looking.
- CloudTrail records algorithm inputs on relevant creation calls, but listener events reference certificates by ARN; AWS Config is suggested to evaluate certificate algorithms.
- The controls cover AWS service APIs, not cryptography performed on customer-controlled compute. Excluded-variant deny lists also have a default-allow gap for newly introduced algorithms, so the article recommends periodic review and detection.
Article Details
- Defense Focus
- Prevent and detect use of ML-DSA-44 across AWS key management and certificate workflows while keeping approved ML-DSA-65 and ML-DSA-87 variants usable.
- Detection Methods
- Monitor CloudTrail events for KMS CreateKey requests and Private CA creation calls, whose event inputs can include the key spec or signing algorithm.
- Use AWS Config resource evaluation and custom rules to flag certificate authorities configured with ML_DSA_44 and assess certificate algorithms where CloudTrail events expose only a certificate ARN.
- To identify existing KMS keys for possible disablement or deletion, enumerate keys with ListKeys, then use DescribeKey to inspect each KeySpec.
- Data Sources
- CloudTrail events for kms:CreateKey, acm-pca:CreateCertificateAuthority, acm:ImportCertificate, iam:UploadServerCertificate, CreateListener, ModifyListener, and AddListenerCertificates.
- AWS Config evaluations of KMS keys, certificate authorities, and certificates.
- AWS KMS ListKeys and DescribeKey results, including each key's KeySpec.
- Rule Types
- SCP, IAM policy, permission-boundary, or KMS key-policy JSON statements using kms:KeySpec conditions to deny excluded key specs.
- CloudTrail API-event monitoring for key and certificate-authority creation.
- AWS Config custom rules for detecting unapproved algorithm configurations.
- Platforms
- AWS organization root and organizational units (OUs)
- AWS member accounts, including production, build, and non-production accounts
- Defensive Actions
- Use an SCP or principal-level policy to deny ML_DSA_44 key creation; where existing keys must also be restricted, deny Sign, Verify, and GetPublicKey requests matching that key spec.
- For multi-Region keys, include kms:ReplicateKey in the creation deny so an excluded primary key cannot be replicated.
- Restrict certificate-authority creation to trusted roles or an approved provisioning pipeline, and pin the CA key and signing algorithms to approved variants; also constrain the CSR subject-key algorithm in that pipeline.
- Control imported and uploaded certificates through provisioning processes, or deny import and upload APIs where they are not required; add only approved CAs to trust stores and issuance hierarchies.
- If using permission boundaries, enforce their attachment and prevent their removal; periodically review restricted operations as service capabilities evolve.
- Test policy examples in a non-production environment before deployment. Take care before scheduling key deletion because deletion can make signature verification impossible.
Vendors
Products
ACMThese controls operate on AWS service APIs, principally AWS KMS, AWS Private Certificate Authority (AWS Private CA), and AWS Certificate Manager (ACM).AWS CloudTrailThe approach in this section controls who can create CAs and pins the algorithm in that trusted path, backed by AWS CloudTrail-based detection.AWS ConfigYou can also use AWS Config to record and query KMS key resources.AWS KMSAWS Key Management Service (AWS KMS) supports the ML-DSA digital signature scheme (FIPS 204) through three parameter sets, ML-DSA-44, ML-DSA-65, and ML-DSA-87, targeting NIST security categories 2, 3, and 5.AWS Private CAThese controls operate on AWS service APIs, principally AWS KMS, AWS Private Certificate Authority (AWS Private CA), and AWS Certificate Manager (ACM).Elastic Load BalancingElastic Load Balancing, for both network load balancers (NLB) and application load balancers (ALB), terminates TLS on behalf of your applications.IAMis also outside the reach of Service control policies (SCPs) and AWS Identity and Access Management (IAM) and isn’t addressed in this post.