Enforcing an ML-DSA Policy on AWS - What kms:KeySpec and acm:KeyAlgorithm Can Stop, and What AWS Private CA and Imported Certificates Leave Open

First Published: 2026-10-21
Last Updated: 2026-10-21

When an organization decides to restrict its use of ML-DSA to only ML-DSA-65 and ML-DSA-87, AWS offers limited ways to enforce that policy through its services. Within AWS Key Management Service (AWS KMS), the condition key kms:KeySpec tells the three variants apart. The condition key kms:SigningAlgorithm does not. AWS Private Certificate Authority (AWS Private CA) has no condition key that looks at the algorithm. No condition key on importing certificates or on attaching them to load balancer listeners looks at the certificate's algorithm either.

This article reads this difference not as a guide to writing SCPs but as a contract table of condition keys. For each service and operation, it details which condition keys inspect the algorithm, the operations where those keys are evaluated, operations where they are not considered, what AWS has already handled, and what remains the responsibility of the user. This article does not rank the effectiveness of different condition keys or detection methods, nor does it discuss pricing.

This article was checked on October 21, 2026. The condition key counts come from the Service Authorization Reference JSON retrieved on the same day. The results in Section 10 were checked with IAM policies in one AWS account. The other sections were written from the sources.

Related articles on this site:

1. Scope and Assumptions
2. How to Read the Tables
3. The Big Picture: Where the Algorithm Is Visible to a Policy
4. AWS KMS: kms:KeySpec and kms:SigningAlgorithm
5. ACM, IAM Server Certificates, and Elastic Load Balancing
6. AWS Private CA: Where No Algorithm Condition Key Exists
7. Services Outside the AWS Security Blog's Scope: IAM Roles Anywhere, AWS Transfer Family, AWS Signer, and Amazon EC2
8. Where SCPs and RCPs Do Not Reach
9. The Detection Side: CloudTrail, AWS Config, Security Hub CSPM, and Key Inventory
10. What This Configuration Returned: A Record of IAM Policies in One Account
11. Failure Modes
12. Frequently Asked Questions About Enforcing an ML-DSA Policy on AWS
13. Summary
14. References

1. Scope and Assumptions

This section sets out the intended readers, the scope, the example policy, and the sources read. The conclusions come first:

AWS KMS: kms:KeySpec tells apart the three ML-DSA key specs (ML_DSA_44, ML_DSA_65, and ML_DSA_87). In the Service Authorization Reference JSON, this condition key appears on the CreateKey operation and on 45 operations on KMS key resources. The kms:SigningAlgorithm condition key only appears in relation to the Sign and Verify operations, and its value is ML_DSA_SHAKE_256 for all three variants.
ACM: acm:KeyAlgorithm only appears in relation to the RequestCertificate operation. The ImportCertificate operation only includes condition keys related to tags. According to the AWS Security Blog, as of October 12, 2026, ACM does not issue leaf certificates for ML-DSA.
AWS Private CA: The only condition keys are acm-pca:TemplateArn and the tag keys; no condition key looks at the algorithm. The CA's key and signing algorithms take the three ML-DSA variants as values.
Outside the blog's scope: The ec2:KeyPairType condition key appears in relation to the CreateKeyPair operation but not the ImportKeyPair operation. Its values are limited to rsa and ed25519, and it has no ML-DSA value. IAM Roles Anywhere, AWS Transfer Family, and AWS Signer do not include any condition keys that examine key or certificate algorithms in the JSON.
Where SCPs do not reach: SCPs do not apply to users and roles in the management account, or to service-linked roles. They also do not reach cryptography that runs on compute you control. No statement on whether kms:KeySpec can be used in an RCP condition was found in the sources this article read.

Where the Algorithm Is Visible to a Policy

1.1 Intended Readers

This article is intended for the following audience:

Security and platform professionals responsible for enforcing cryptographic policies through AWS Organizations SCPs or IAM policies, or who wish to do so.
People who want to narrow the ML-DSA variants to an organizational standard.
People who think the following: kms:SigningAlgorithm can block ML-DSA-44. AWS Private CA can also be constrained with condition keys. An SCP keeps ML-DSA-44 out of the whole organization. EC2 key pairs are outside SCPs. The algorithms of ACM certificates, imports included, can be constrained with SCPs.

Each of these either does not match the sources this article read or covers a different scope. The AWS Security Blog says about kms:SigningAlgorithm: It therefore can’t distinguish ML-DSA-44 from the approved variants and shouldn’t be used for this purpose (Section 4.3). About AWS Private CA, the same post says There is currently no condition key for the algorithm, so an SCP cannot enforce signing algorithm (Section 6). Areas outside the reach of SCPs are summarized in Section 8. EC2 CreateKeyPair carries ec2:KeyPairType (Section 7.4). Regarding imported certificates, the post says Certificate material brought in through acm:ImportCertificate or iam:UploadServerCertificate is also not algorithm-aware (Section 5.3).

1.2 What This Article Covers and What It Does Not

This article focuses on the following nine services, covering the operations where condition keys see the algorithm and the operations where they do not.

AWS KMS, AWS Certificate Manager (ACM), AWS Private CA, AWS Identity and Access Management (IAM), Elastic Load Balancing, IAM Roles Anywhere, AWS Transfer Family, AWS Signer, Amazon EC2

It also covers where SCPs and RCPs do not reach, and the detection side (AWS CloudTrail, AWS Config, AWS Security Hub CSPM, and key inventory). This article does not investigate other services. It will not make any statements regarding services not listed in the tables.

This article does not cover:

Pricing and billing mechanisms.
The ranking of condition keys and detection methods. When a source ranks them, this article quotes the source.
General principles of SCP and RCP, evaluation order, and data boundaries. These topics are covered on this site's AWS Organization Guardrails.
That kms:SigningAlgorithm has no effect on the JWT verification side. This is addressed on this site's NIST IR 8587 Mapped to AWS Controls.
Condition keys and AllowedKeyAlgorithms within ACME. This is covered on this site's How AWS Certificate Manager Issues Public Certificates.
Paths for moving public web certificates to post-quantum signatures. This is addressed on this site's Post-Quantum Certificates for Public TLS Are Three Proposals That Disagree.
TLS key exchange. Key exchange utilizing ML-KEM is a separate migration process from signature migration. This is covered on this site's Post-Quantum Cryptography Standardization Timeline and Migration on AWS.
Procedures for circumventing SCP, condition key, and IAM evaluations.

1.3 The Example Policy

This article uses the same example policy as Part 2 of the AWS Security Blog. The organization standardizes on ML-DSA-65 and ML-DSA-87 and removes ML-DSA-44 from its approved list. The blog says about this choice: That is a standardization decision, not a judgment that ML-DSA-44 is insecure.

In this article too, ML-DSA-44 is the example of a variant the policy does not include. This does not mean that ML-DSA-44 is weak. The mechanics are the same whichever variant the policy excludes.

The names of the ML-DSA variants are sometimes spelled differently across various documents. This article will use the following conventions:

ML-DSA-44, ML-DSA-65, ML-DSA-87: Names of the parameter sets in FIPS 204.
ML_DSA_44, ML_DSA_65, ML_DSA_87: Values for AWS KMS key specs. These same spellings are also used for the KeyAlgorithm and SigningAlgorithm values in AWS Private CA (Section 6.2).
ML_DSA_SHAKE_256: Value for the signing algorithm in AWS KMS. This is common to all three key specs.

1.4 Sources Read and the Check Date

This article read the following sources on October 21, 2026. Because the sources differ in kind, the text and the tables say which kind each statement comes from.

Kind	Sources
Service Authorization Reference JSON	`kms`, `acm`, `acm-pca`, `iam`, `ec2`, `rolesanywhere`, `transfer`, `signer`, and `elasticloadbalancing` (all `v1.4`, retrieved 2026-10-21)
Blog posts	AWS Security Blog, "Quantum-resistant signing on AWS", Part 1 and Part 2 (2026-10-12)
AWS documentation	AWS KMS Developer Guide, ACM User Guide and API Reference, AWS Private CA API Reference and FAQ, AWS Organizations User Guide, Amazon EC2 API Reference, Elastic Load Balancing guides, IAM Roles Anywhere User Guide, AWS Transfer Family User Guide, AWS Config Developer Guide, AWS Security Hub User Guide
What's New	AWS KMS ML-DSA (2025-06-13), AWS Private CA post-quantum certificates (2025-11-10), IAM Roles Anywhere post-quantum certificates (2026-03-09)
Schema repository	`awslabs/aws-config-resource-schema` (retrieved 2026-10-21)

Part 2 of the AWS Security Blog is an official AWS blog and contains descriptions of the author's testing. This article differentiates between statements from the blog and statements from the reference materials. Even when both sources state the same information, the origin of the statement will be noted.

2. How to Read the Tables

This section defines the columns of this article's tables, the terms for status, and how condition keys are counted.

2.1 Shared Columns

This article's contract tables use the following seven column names. The Condition Key column is the one added in this article. The other six columns are common to two related articles on this site.

Column	What the cell holds
`Who Sets It`	The body that decides: a root program, the CA/Browser Forum, the IETF, or AWS
`What It Requires`	What the document requires or permits, in its own words
`Status on the Check Date`	The stage of the document on 2026-10-21, using the terms in Section 2.2
`Condition Key`	The condition key that sees the algorithm or key type on that operation, or none
`Where AWS Comes In`	What you can set on AWS today, and what AWS has already done
`No Statement Found`	What the sources do not state, with the sources searched
`What Stays With You`	What no document takes over and remains with the policy owner

2.2 Terms for Status on the Check Date

The Status on the Check Date column holds only the following eight terms. All rows in this article are In effect. When a product's status carries a check-date caveat, the cell adds the source and date.

Term	Meaning in this article
`Draft policy`	A policy text published and marked as a draft
`Draft pull request`	A GitHub pull request marked as Draft
`Internet-Draft`	An active IETF Internet-Draft that the IESG has not approved
`In the RFC Editor queue`	Approved by the IESG and waiting for an RFC number
`Published RFC`	Published with an RFC number
`In effect`	Shipped in a product or in force in a published policy
`Scheduled`	A date written into a policy that is not a draft
`Announced`	A plan or intent stated in a blog post, slide, or group post, without a policy text

Part 2 of the AWS Security Blog says at the time of writing about ACM and load balancer certificates. This article writes those rows as In effect (AWS Security Blog, at the time of writing on 2026-10-12).

2.3 Action Condition Keys and Resource Condition Keys

The Service Authorization Reference JSON specifies condition keys in two places.

Action Condition Keys: These are in the ActionConditionKeys of each action. They often relate to the request arguments.
Resource Condition Keys: These are associated with the resource type that the action targets. They refer to the attributes of that resource.

This article counts both types of condition keys together. Counting only one type would result in omissions. For example, kms:KeySpec is not among the action condition keys of Sign. It is among the condition keys of the key resource type that Sign acts on.

Furthermore, the EC2 JSON restates the condition keys for each resource inside the action. In ImportKeyPair, the key-pair entry lists only tag condition keys. The list of resource types includes ec2:KeyPairType. This article gives priority to the lists inside the actions. If you were to count only the list of resource types, you would wrongly count ImportKeyPair among the actions that carry ec2:KeyPairType.

The counts are the values in the JSON retrieved on October 21, 2026. The values in the JSON change as services are updated.

2.4 Documented Values, This Article's Inferences, and Demo Values

The tables in this article hold only documented values. When a specific statement cannot be found in the source material, it is marked No statement found, and the sources searched are named in the same cell or sentence. The article does not then say that the feature is missing.

What this article derives by combining statements from the sources is marked as an inference in the text.

The values in Section 10 are results checked with IAM policies in one AWS account. They sit in their own section, apart from the documented values, and are not mixed into those tables.

3. The Big Picture: Where the Algorithm Is Visible to a Policy

The following table lists nine services, with whether a condition key sees the algorithm (or key type) of keys and certificates. The numbers were counted from the Service Authorization Reference JSON (retrieved on October 21, 2026).

Service	Condition key that sees the algorithm or key type	Actions that carry it	Where the algorithm is not visible
AWS KMS	`kms:KeySpec`	46 (`CreateKey` as an action key, 45 actions on the `key` resource)	Verification outside AWS KMS
AWS KMS	`kms:SigningAlgorithm` (same value for all three ML-DSA key specs)	2 (`Sign`, `Verify`)	`GetPublicKey` and the other key operations
ACM	`acm:KeyAlgorithm`	1 (`RequestCertificate`)	`ImportCertificate`
IAM	None	—	`UploadServerCertificate`
Elastic Load Balancing	None for the certificate (`elasticloadbalancing:SecurityPolicy` names the TLS policy)	—	`CreateListener`, `ModifyListener`, `AddListenerCertificates`
AWS Private CA	None (`acm-pca:TemplateArn` names the certificate template)	—	`CreateCertificateAuthority`, `IssueCertificate`
IAM Roles Anywhere	None	—	`CreateTrustAnchor`, `UpdateTrustAnchor`
AWS Transfer Family	None for keys (`transfer:RequestSecurityPolicyName` names the security policy)	—	`ImportHostKey`, `ImportSshPublicKey`, `ImportCertificate`
AWS Signer	None	—	`PutSigningProfile`
Amazon EC2	`ec2:KeyPairType` (`rsa` or `ed25519` only)	6 (on the `key-pair` resource)	`ImportKeyPair`

None in this table means that no service-specific condition key in the JSON looks at the algorithm or key type. Other condition keys, such as the tag keys, do exist.

In this table, only kms:KeySpec tells the ML-DSA variants apart. ec2:KeyPairType looks at the key type, but has no ML-DSA value. acm:KeyAlgorithm looks at the algorithm, but in the sources on the check date, ACM keys are limited to RSA and ECDSA (Section 5.1).

4. AWS KMS: kms:KeySpec and kms:SigningAlgorithm

This section describes the differences between the two condition keys in AWS KMS, along with the number of actions that carry each.

4.1 Key Specs and the Signing Algorithm

AWS KMS announced support for ML-DSA signatures in the "What's New" update on June 13, 2025. The "Key spec reference" section of the KMS Developer Guide lists three ML-DSA key specs: ML_DSA_44, ML_DSA_65, and ML_DSA_87, and gives the signing algorithm as ML_DSA_SHAKE_256.

Part 2 of the AWS Security Blog describes this relationship as follows:

AWS KMS support for ML-DSA introduces three key specs—ML_DSA_44, ML_DSA_65, and ML_DSA_87—that all use a single post-quantum signing algorithm: ML_DSA_SHAKE_256.

In other words, the key spec tells the three variants apart, and the signing algorithm does not. This difference decides which condition key can serve the policy.

4.2 Actions That Carry kms:KeySpec

The KMS Developer Guide describes the kms:KeySpec condition as follows:

The kms:KeySpec condition key controls access to operations based on the value of the KeySpec property of the KMS key that is created by or used in the operation.

The table on the same page lists the API operations associated with this condition key as CreateKey and KMS key resource operations. The policy types are IAM policy for CreateKey and key policy and IAM policy for KMS key resource operations.

In the Service Authorization Reference JSON, kms:KeySpec appears in 46 operations.

As an action condition key of CreateKey (one action)
As a condition key of the key resource type, which applies to the 45 actions that act on this resource type

The following code block lists the 46 operation names extracted from the JSON.

Action condition key (1):
  CreateKey

Resource condition key on the key resource type (45):
  CancelKeyDeletion, CreateAlias, CreateGrant, Decrypt, DeleteAlias,
  DeleteImportedKeyMaterial, DeriveSharedSecret, DescribeKey, DisableKey,
  DisableKeyRotation, EnableKey, EnableKeyRotation, Encrypt, GenerateDataKey,
  GenerateDataKeyPair, GenerateDataKeyPairWithoutPlaintext,
  GenerateDataKeyWithoutPlaintext, GenerateMac, GetKeyLastUsage, GetKeyPolicy,
  GetKeyRotationStatus, GetParametersForImport, GetPublicKey, ImportKeyMaterial,
  ListGrants, ListKeyPolicies, ListKeyRotations, ListResourceTags, PutKeyPolicy,
  ReEncryptFrom, ReEncryptTo, ReplicateKey, RetireGrant, RevokeGrant,
  RotateKeyOnDemand, ScheduleKeyDeletion, Sign, SynchronizeMultiRegionKey,
  TagResource, UntagResource, UpdateAlias, UpdateKeyDescription,
  UpdatePrimaryRegion, Verify, VerifyMac

Part 2 of the AWS Security Blog covers a narrower set. The blog tested three operations: Sign, Verify, and GetPublicKey. The blog says testing confirmed kms:KeySpec is evaluated on all three. The 46 operations in the JSON and the three operations in the blog are two descriptions from different sources.

The KMS Developer Guide also covers the case where the parameter is absent from the request. Regarding the KeySpec condition for CreateKey, it says

This type of condition works even when the parameter doesn't appear in the request, such as when you use the parameter's default value

4.3 kms:SigningAlgorithm Does Not Tell the Three Variants Apart

In the Service Authorization Reference JSON, kms:SigningAlgorithm appears as a condition key for both the Sign and Verify actions, but is not included in GetPublicKey.

Part 2 of the AWS Security Blog describes this condition key as follows:

kms:SigningAlgorithm: Reflects the signing algorithm supplied on Sign and Verify, which is ML_DSA_SHAKE_256 for all three variants. It therefore can’t distinguish ML-DSA-44 from the approved variants and shouldn’t be used for this purpose.

A deny on kms:SigningAlgorithm equal to ML_DSA_SHAKE_256 stops Sign not only with ML-DSA-44 keys but also with ML-DSA-65 and ML-DSA-87 keys. It cannot stop only the variant that the policy excludes.

4.4 The Blog's SCP Examples and ReplicateKey

The SCP examples in Part 2 of the AWS Security Blog demonstrate the denial of CreateKey operations, as well as denials of Sign, Verify, and GetPublicKey operations, all when kms:KeySpec is ML_DSA_44. The following is the usage deny statement from the blog's example.

{
  "Sid": "DenyMLDSA44KeyUsage",
  "Effect": "Deny",
  "Action": [
    "kms:Sign",
    "kms:Verify",
    "kms:GetPublicKey"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:KeySpec": "ML_DSA_44"
    }
  }
}

The blog says not to widen the deny to kms:*. Stopping management operations such as DescribeKey, DisableKey, and ScheduleKeyDeletion would keep you from managing the keys you want to delete.

The JSON for the blog's SCP does not include ReplicateKey. In its text, the blog says to add kms:ReplicateKey to the creation deny if you use multi-Region keys. The rationale provided is kms:KeySpec is evaluated on ReplicateKey as well. When you replicate an ML-DSA-44 primary key, a new ML-DSA-44 key is created in another Region.

The blog also describes another shape: a StringNotEquals on the list of approved key specs. This shape denies a new variant that has not been evaluated until it is added to the list. The blog says that both shapes are valid. The following is that statement from the blog.

{
  "Sid": "OnlyApprovedMlDsaVariants",
  "Effect": "Deny",
  "Action": "kms:CreateKey",
  "Resource": "*",
  "Condition": {
    "StringLike": {
      "kms:KeySpec": "ML_DSA_*"
    },
    "StringNotEquals": {
      "kms:KeySpec": ["ML_DSA_65", "ML_DSA_87"]
    }
  }
}

The blog also mentions that the same denial of kms:KeySpec can be placed in the KMS key policy. Since a key policy is a resource policy, the statement requires a Principal element.

The blog describes preventing key creation within KMS as follows:

The practical consequence: for keys held in AWS KMS, preventing ML-DSA-44 key material from being created is the most robust single control.

This is a statement from the blog. This article does not assign a ranking to controls.

4.5 Verification Outside AWS KMS

The AWS KMS Developer Guide says about kms:SigningAlgorithm: This condition key has no effect on operations performed outside of AWS KMS.

With the public key from GetPublicKey, a signature can be verified outside AWS KMS. That verification does not call the KMS API, so neither kms:KeySpec nor kms:SigningAlgorithm applies to it. This is this article's inference from combining the statements of the two sources.

That kms:SigningAlgorithm has no effect on the JWT verification side is covered in Section 4.2 of this site's NIST IR 8587 Mapped to AWS Controls. This article adds only that it does not tell the three variants apart.

4.6 AWS KMS Contract Tables

Surface	`Who Sets It`	`What It Requires`	`Status on the Check Date`	`Condition Key`
Key creation (`CreateKey`, `ReplicateKey`)	AWS (KMS Developer Guide, Service Authorization Reference)	`KeySpec` of `ML_DSA_44`, `ML_DSA_65`, or `ML_DSA_87`	`In effect` (since 2025-06-13)	`kms:KeySpec`
Key use (`Sign`, `Verify`, `GetPublicKey`)	AWS	The key's `KeySpec`; signing algorithm `ML_DSA_SHAKE_256`	`In effect`	`kms:KeySpec`; `kms:SigningAlgorithm` on `Sign` and `Verify` only
Verification outside AWS KMS	You	A public key from `GetPublicKey`	`In effect`	None

Surface	`Where AWS Comes In`	`No Statement Found`	`What Stays With You`
Key creation (`CreateKey`, `ReplicateKey`)	The condition key in SCPs, IAM policies, and permission boundaries	Whether `kms:KeySpec` can be used in an RCP (KMS RCP page, RCP syntax page, condition key table)	Adding `kms:ReplicateKey` to the deny if you use multi-Region keys
Key use (`Sign`, `Verify`, `GetPublicKey`)	The condition key in SCPs, IAM policies, and key policies	None	Keeping management operations such as `DescribeKey` and `ScheduleKeyDeletion` out of the deny
Verification outside AWS KMS	None	None	The verifier's own algorithm policy

5. ACM, IAM Server Certificates, and Elastic Load Balancing

This section sorts the request, import, upload, and listener attachment of TLS certificates by whether a condition key sees the algorithm.

5.1 ACM Key Algorithms

The ACM User Guide says ACM supports these RSA and ECDSA public key algorithms and lists the following seven:

RSA_1024, RSA_2048, RSA_3072, RSA_4096
EC_prime256v1, EC_secp384r1, EC_secp521r1

The same page says that ACM can request new certificates only with the algorithms marked with an asterisk, and that the others are for imported certificates only. The three marked with an asterisk are RSA_2048, EC_prime256v1, and EC_secp384r1. The import prerequisites page lists the same seven.

Part 2 of the AWS Security Blog says at the time of writing, ACM doesn’t offer ML-DSA leaf certificates. The blog's date is October 12, 2026.

5.2 acm:KeyAlgorithm Is on RequestCertificate Only

In the Service Authorization Reference JSON, the acm:KeyAlgorithm condition key appears only as a condition key for the RequestCertificate action. The table of condition keys in the ACM User Guide also gives RequestCertificate as its operation.

The example in Part 2 of the AWS Security Blog uses StringNotEqualsIfExists to specify an approved list of algorithms.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestrictACMLeafKeyAlgorithm",
      "Effect": "Deny",
      "Action": "acm:RequestCertificate",
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "acm:KeyAlgorithm": [
            "EC_secp384r1",
            "RSA_2048"
          ]
        }
      }
    }
  ]
}

The blog describes the difference in operators as follows: StringNotEqualsIfExists denies only requests that name an algorithm that is not approved. A plain StringNotEquals also denies a request that omits acm:KeyAlgorithm, because the condition evaluates to true when the key is missing.

The blog calls this policy a forward-looking defense-in-depth control. This means it is not a control to mitigate the imminent risk associated with ML-DSA-44, as ACM does not currently issue leaf certificates for ML-DSA.

The ACM API Reference for RequestCertificate says RSA is the default key algorithm for ACM certificates. No statement was found, in the sources this article read, on whether the default value enters the context of a request that omits the parameter. In the configuration in Section 10, a request that omitted KeyAlgorithm was stopped by the deny for acm:KeyAlgorithm equal to RSA_2048. The default value behaved as if it were in the context. This result points the other way from the blog's explanation above. This article sets them side by side in Section 10.5 as an observation from one configuration.

ACM also has a condition key called acm:CertificateKeyPairOrigin. This key does not refer to the key's algorithm. It indicates the key's origin (AWS_MANAGED, ACME, or CUSTOMER_PROVIDED). The sources disagree on the number of actions for this condition key. The JSON lists five: AddTagsToCertificate, DeleteCertificate, RequestCertificate, RevokeCertificate, and UpdateCertificate. The table in the ACM User Guide lists three operations: RequestCertificate, AddTagsToCertificate, and RevokeCertificate. The ACME condition keys are covered in this site's How AWS Certificate Manager Issues Public Certificates.

5.3 Imports and Uploads

The Service Authorization Reference JSON indicates that ACM's ImportCertificate only includes tag condition keys. Similarly, IAM's UploadServerCertificate only includes tag condition keys.

Part 2 of the AWS Security Blog says Certificate material brought in through acm:ImportCertificate or iam:UploadServerCertificate is also not algorithm-aware. About UploadServerCertificate, it goes on:

In particular, iam:UploadServerCertificate doesn’t support any method to prevent use of particular algorithms, and AWS doesn’t recommend using this API to generate and upload certificates.

The blog says to control imports and uploads through the issuance process, or to deny the actions entirely where they are not required.

5.4 Attaching Certificates to Listeners

Part 2 of the AWS Security Blog states that the listener API calls only reference a certificate by its ARN.

Because the listener API calls reference a certificate only by ARN, you can’t write an SCP on CreateListener, ModifyListener, or AddListenerCertificates that inspects the certificate’s algorithm.

The same post says

At the time of writing, ACM requests and imports accept RSA and ECDSA keys only, and NLB and ALB listeners accept RSA and ECDSA certificates only, so no ML-DSA certificate can be bound to a listener today

.

The Elastic Load Balancing guides also give RSA and ECDSA. The Application Load Balancer page says that ACM supports RSA certificates with 2048-, 3072-, and 4096-bit key lengths, and all ECDSA certificates. The Network Load Balancer page lists the supported key algorithms as RSA (1024-3072 bits) and ECDSA (256-521 bits).

The Network Load Balancer page includes a note regarding certificates imported into IAM.

If you import a certificate into AWS Identity and Access Management (IAM) and attach it to an NLB TLS listener, the certificate key size and algorithm are not validated at the time of attachment. Validation occurs asynchronously after the certificate is associated with the listener.

In other words, on this path the algorithm is not checked at attachment. The check runs asynchronously after attachment.

The Service Authorization Reference JSON lists elasticloadbalancing:SecurityPolicy in relation to four operations: CreateListener, ModifyListener, CreateLoadBalancerPolicy, and SetLoadBalancerPoliciesOfListener. The blog post mentions this condition key in relation to CreateListener and ModifyListener, stating that it allows you to narrow down the TLS policies available to the listener. A TLS policy is a setting on the negotiation side. It is not the key algorithm of the certificate.

5.5 ACM, IAM, and Elastic Load Balancing Contract Tables

Surface	`Who Sets It`	`What It Requires`	`Status on the Check Date`	`Condition Key`
ACM `RequestCertificate`	AWS (ACM User Guide)	`RSA_2048`, `EC_prime256v1`, or `EC_secp384r1`	`In effect`	`acm:KeyAlgorithm`
ACM `ImportCertificate`	AWS (ACM User Guide)	Seven RSA and ECDSA algorithms	`In effect`	None
IAM `UploadServerCertificate`	AWS (IAM)	None found in the sources read	`In effect`	None
Listener certificate (`CreateListener`, `ModifyListener`, `AddListenerCertificates`)	AWS (Elastic Load Balancing)	RSA and ECDSA certificates	`In effect` (AWS Security Blog, at the time of writing on 2026-10-12)	None (`elasticloadbalancing:SecurityPolicy` names the TLS policy)

Surface	`Where AWS Comes In`	`No Statement Found`	`What Stays With You`
ACM `RequestCertificate`	No ML-DSA leaf certificates (AWS Security Blog, at the time of writing on 2026-10-12)	Whether the default `RSA_2048` enters the request context when the parameter is omitted (ACM User Guide, API Reference)	Choosing `StringNotEqualsIfExists` or `StringNotEquals`
ACM `ImportCertificate`	The key algorithm list of the import prerequisites	None	Controlling imports through provisioning, or denying the action
IAM `UploadServerCertificate`	None	A key algorithm list for IAM server certificates (IAM User Guide, Manage server certificates in IAM)	Denying the action unless it is required
Listener certificate (`CreateListener`, `ModifyListener`, `AddListenerCertificates`)	NLB validates IAM-imported certificates after attachment	Support for ML-DSA certificates on listeners (Elastic Load Balancing guides)	Keeping ML-DSA-44 certificate material from existing

6. AWS Private CA: Where No Algorithm Condition Key Exists

This section describes where AWS Private CA sets the ML-DSA variant, and that no condition key sees it.

6.1 The CA Configuration

AWS Private CA announced support for quantum-resistant digital certificates in its "What's New" release on November 10, 2025. The CertificateAuthorityConfiguration in the API Reference allows you to specify the KeyAlgorithm and SigningAlgorithm when creating a CA. Both Valid Values include ML_DSA_44, ML_DSA_65, and ML_DSA_87.

Part 2 of the AWS Security Blog says to put the same variant in both KeyAlgorithm and SigningAlgorithm. For example, it mentions KeyAlgorithm=ML_DSA_65 with SigningAlgorithm=ML_DSA_65.

This site's AWS Private CA Hierarchy Design discusses the selection of key algorithms and the CA hierarchy.

6.2 Three Values Named SigningAlgorithm

The name SigningAlgorithm appears in three places across AWS KMS and AWS Private CA. The values are not spelled the same.

Where	What the value names	ML-DSA values
AWS KMS `Sign` and `Verify` (`SigningAlgorithm` parameter)	The signing algorithm used with the KMS key	`ML_DSA_SHAKE_256` for all three key specs
AWS Private CA `CertificateAuthorityConfiguration` (`SigningAlgorithm`)	The algorithm the private CA uses to sign certificate requests	`ML_DSA_44`, `ML_DSA_65`, `ML_DSA_87`
AWS Private CA `IssueCertificate` (`SigningAlgorithm` parameter)	The algorithm used to sign the certificate to be issued	`ML_DSA_44`, `ML_DSA_65`, `ML_DSA_87`

Part 2 of the AWS Security Blog says about the SigningAlgorithm of AWS Private CA:

the SigningAlgorithm takes the variant value directly (ML_DSA_44, ML_DSA_65, and ML_DSA_87), and doesn’t accept ML_DSA_SHAKE_256

.

The IssueCertificate API Reference says

This parameter should not be confused with the SigningAlgorithm parameter used to sign a CSR in the CreateCertificateAuthority action

6.3 The Condition Keys Are acm-pca:TemplateArn and Tags Only

In the Service Authorization Reference JSON, the service-specific condition keys for AWS Private CA are limited to a single key: acm-pca:TemplateArn. This key is used as a condition key for the IssueCertificate action. All other condition keys relate to tags. Only tag-related condition keys are available for CreateCertificateAuthority.

The templates page of the AWS Private CA User Guide says about the IssueCertificate permission:

you can restrict the certificate templates used for certificate issuance by adding a acm-pca:TemplateArn Condition to the policy

. This condition key restricts the certificate templates, not the algorithms.

Part 2 of the AWS Security Blog says There is currently no condition key for the algorithm, so an SCP cannot enforce signing algorithm. Instead, the blog suggests the following four actions:

Broadly deny CreateCertificateAuthority via SCP, allowing only a limited number of trusted roles or approved creation processes.
In that approved pipeline or infrastructure-as-code template, pin SigningAlgorithm to ML_DSA_65 or ML_DSA_87.
Put only approved CAs in trust stores and issuance hierarchies.
Log CreateCertificateAuthority in CloudTrail and use AWS Config to identify CAs using ML_DSA_44.

6.4 The Key in the CSR

The CA's algorithm determines the signature on the certificates it issues. The subject key for the certificate originates from the CSR.

Part 2 of the AWS Security Blog says

the subject key in each certificate comes from the CSR, which AWS Private CA copies without validating its algorithm, so pin the CSR key algorithm in the same issuance pipeline

.

This statement reads as allowing an ML-DSA-65 CA to issue a certificate with an ML-DSA-44 subject key. This is this article's inference, and this article did not test it. The algorithm of the CSR key stays with the issuance pipeline.

The AWS Private CA FAQ says AWS PCA does not support Merkle Tree Certificates (MTC) at this time. The paths for public web certificates are covered on this site in Post-Quantum Certificates for Public TLS Are Three Proposals That Disagree.

6.5 AWS Private CA Contract Tables

Surface	`Who Sets It`	`What It Requires`	`Status on the Check Date`	`Condition Key`
CA creation (`CreateCertificateAuthority`)	AWS (AWS Private CA API Reference)	`KeyAlgorithm` and `SigningAlgorithm`, including `ML_DSA_44`, `ML_DSA_65`, `ML_DSA_87`	`In effect` (since 2025-11-10)	None
Certificate issuance (`IssueCertificate`)	AWS	`SigningAlgorithm`, including the three ML-DSA values; a CSR	`In effect`	`acm-pca:TemplateArn` (the template, not the algorithm)
Subject key in the CSR	You	None (AWS Private CA copies it without validating its algorithm)	`In effect`	None

Surface	`Where AWS Comes In`	`No Statement Found`	`What Stays With You`
CA creation (`CreateCertificateAuthority`)	CloudTrail records the signing algorithm (AWS Security Blog)	A plan for an algorithm condition key (the AWS Security Blog says `There is currently no condition key for the algorithm`)	Limiting who can create CAs; pinning the algorithm in the provisioning template
Certificate issuance (`IssueCertificate`)	None	A condition key on the `SigningAlgorithm` parameter (Service Authorization Reference)	Choosing templates and issuance callers
Subject key in the CSR	None	None	Pinning the CSR key algorithm in the issuance pipeline

7. Services Outside the AWS Security Blog's Scope: IAM Roles Anywhere, AWS Transfer Family, AWS Signer, and Amazon EC2

Part 2 of the AWS Security Blog defines its scope as follows:

Other TLS-terminating or signing services (for example Amazon CloudFront and Amazon API Gateway) and AWS IAM Roles Anywhere aren’t covered in this post and should be assessed separately.

This section reads four services that the blog does not cover, using the Service Authorization Reference JSON.

7.1 IAM Roles Anywhere

IAM Roles Anywhere announced ML-DSA support in What's New on March 9, 2026. The What's New post says

You can now use ML-DSA-signed CA certificates as IAM Roles Anywhere trust anchors, and issue end entity certificates bound to ML-DSA keys

.

For the signature on a request, which is computed with the certificate's private key, the signing process page of the IAM Roles Anywhere User Guide says SigningAlgorithm must be one of the following algorithms and lists SHA256WithRSA, SHA256WithECDSA, ML-DSA-44, ML-DSA-65, and ML-DSA-87.

In the Service Authorization Reference JSON, IAM Roles Anywhere does not include any service-specific condition keys. Its condition keys are the three tag keys only. CreateTrustAnchor carries only tag condition keys.

So in IAM Roles Anywhere, condition keys cannot tell apart the variants of the trust anchor CA or of the end-entity keys. The CA you register as a trust anchor and that CA's issuance pipeline decide the variant. This is this article's inference from combining the sources' statements.

7.2 AWS Transfer Family

The Service Authorization Reference JSON lists five service-specific condition keys for AWS Transfer Family.

transfer:RequestConnectorProtocol, transfer:RequestSecurityPolicyName, transfer:RequestServerDomain, transfer:RequestServerEndpointType, transfer:RequestServerProtocols

Of these, the one whose name is closest to algorithms is transfer:RequestSecurityPolicyName. It is on CreateServer, UpdateServer, CreateConnector, and UpdateConnector. What the name tells is that it looks at the name of a security policy. It does not look at a key algorithm.

Operations that import keys and certificates do not include any algorithm-specific condition keys. ImportHostKey, ImportSshPublicKey, and ImportCertificate only have tag-based condition keys.

The sources disagree on this list of condition keys. The AWS Transfer Family User Guide's page on condition keys lists four condition keys, omitting transfer:RequestSecurityPolicyName. The JSON lists five.

The SSH algorithms of Transfer Family and EC2 are covered on this site in SSH Algorithms on AWS Endpoints.

7.3 AWS Signer

In the Service Authorization Reference JSON, the service-specific condition keys for AWS Signer consist solely of signer:ProfileVersion. This key appears in relation to the following actions: CancelSigningProfile, GetSigningProfile, RevokeSignature, RevokeSigningProfile, SignPayload, and StartSigningJob. The PutSigningProfile action, used to create signing profiles, only includes condition keys related to tags.

No statement that AWS Signer signs with ML-DSA was found in the AWS Signer Developer Guide, API Reference, or What's New.

7.4 Amazon EC2 Key Pairs

The Amazon EC2 CreateKeyPair API Reference specifies that the KeyType value can be either rsa or ed25519, with rsa being the default. The ImportKeyPair API Reference states that it accepts public keys for either RSA or ED25519 key pairs. Neither has an ML-DSA type.

In the Service Authorization Reference JSON, ec2:KeyPairType is a condition key for the key-pair resource and appears in six operations:

CreateKeyPair, DeleteKeyPair, CreateTags, RunInstances, RequestSpotInstances, RequestSpotFleet.

The key-pair entry of ImportKeyPair lists only tag condition keys.

So even if you deny the creation of ed25519 key pairs using ec2:KeyPairType, that condition key does not stop the import of a public key of the same type. On the other hand, ec2:KeyPairType is in the key-pair entry of RunInstances. In the configuration in Section 10, a RunInstances --dry-run that named an imported ed25519 key pair was stopped by the deny on ec2:KeyPairType. The key type was not visible during import, but it was visible during instance launch.

ec2:KeyPairType only distinguishes between the two traditional key types. It is not related to any policies regarding ML-DSA variants. SSH and OpenSSL cryptography inside an EC2 instance falls under compute you control in Section 8.3.

7.5 Contract Tables for the Services Outside the Blog's Scope

Surface	`Who Sets It`	`What It Requires`	`Status on the Check Date`	`Condition Key`
IAM Roles Anywhere trust anchors and end-entity certificates	AWS (IAM Roles Anywhere User Guide, What's New)	ML-DSA-signed CA certificates as trust anchors (What's New); request signatures with `SHA256WithRSA`, `SHA256WithECDSA`, `ML-DSA-44`, `ML-DSA-65`, or `ML-DSA-87` (signing process page)	`In effect` (since 2026-03-09)	None
AWS Transfer Family key and certificate imports	AWS	None found in the sources read	`In effect`	None (`transfer:RequestSecurityPolicyName` names the security policy)
AWS Signer signing profiles	AWS	None found in the sources read	`In effect`	None
EC2 `CreateKeyPair`	AWS (Amazon EC2 API Reference)	`KeyType` of `rsa` or `ed25519`	`In effect`	`ec2:KeyPairType`
EC2 `ImportKeyPair`	AWS (Amazon EC2 API Reference)	An RSA or ED25519 public key	`In effect`	None

Surface	`Where AWS Comes In`	`No Statement Found`	`What Stays With You`
IAM Roles Anywhere trust anchors and end-entity certificates	ML-DSA trust anchors and end-entity keys	A condition key on the CA or key algorithm (Service Authorization Reference)	The CA you register and its issuance pipeline
AWS Transfer Family key and certificate imports	None	`transfer:RequestSecurityPolicyName` in the Transfer Family User Guide's list of condition keys (the sources disagree)	Controlling which keys are imported
AWS Signer signing profiles	None	ML-DSA signing in AWS Signer (AWS Signer Developer Guide, API Reference, What's New)	No ML-DSA setting to pin was found on the check date
EC2 `CreateKeyPair`	The key type condition key	ML-DSA key pair types (Amazon EC2 API Reference)	Not applicable to ML-DSA
EC2 `ImportKeyPair`	None	None	Checking the key type at launch, or controlling imports

8. Where SCPs and RCPs Do Not Reach

This section covers only the parts of the SCP and RCP scope that matter to a cryptographic policy. General discussions regarding SCP and RCP are covered on this site under AWS Organization Guardrails.

8.1 The Management Account

The AWS Organizations User Guide says SCPs don't affect users or roles in the management account. The same page also indicates that SCPs do apply to member accounts designated as delegated administrators.

Part 2 of the AWS Security Blog advises against running workloads on the management account that handle ML-DSA-44, as SCPs do not apply there.

8.2 Service-Linked Roles

The AWS Organizations User Guide says SCPs do not affect any service-linked role. The actions performed by service-linked roles are outside the scope of SCP restrictions.

8.3 Inside Compute You Control

Part 2 of the AWS Security Blog describes the scope of control as follows:

They don’t and can’t govern cryptography that runs on compute you control.

The blog provides examples, such as when OpenSSL or an application signs using ML-DSA-44 within EC2 instances, containers, or AWS Lambda functions. The blog states that it will not address the use of protocols like OpenSSH's hybrid ssh-mldsa44-ed25519 public key authentication, as this falls outside the reach of SCP and IAM.

An SCP sees only requests to AWS service APIs. Cryptographic processing inside your compute does not call AWS APIs, so condition keys do not apply there.

8.4 RCPs

The list of services that support RCPs (AWS Organizations User Guide, read on October 21, 2026) includes kms, rolesanywhere, and transfer. Services such as acm, acm-pca, ec2, iam, signer, and elasticloadbalancing were not found on the list.

The RCP page of the KMS Developer Guide says that RCPs do not apply to AWS managed keys. The same page says that the kms:RetireGrant permission is not effective in an RCP.

No statement on whether kms:KeySpec can be used in an RCP condition was found in the sources this article read. The sources searched were three: the RCP page of the KMS Developer Guide, the RCP syntax page of AWS Organizations, and the table on the KMS condition keys page. The table on condition keys lists the policy types for kms:KeySpec as IAM policies for CreateKey, and both key policies and IAM policies for operations on KMS key resources. RCP is not mentioned in this table. This article does not say either that it can or that it cannot.

9. The Detection Side: CloudTrail, AWS Config, Security Hub CSPM, and Key Inventory

Where no condition key sees the algorithm, detection is what remains. This section describes which records carry the algorithm.

9.1 AWS CloudTrail

Part 2 of the AWS Security Blog discusses CloudTrail logging, stating:

Whether the algorithm shows up in the event depends on what the call itself carries.

The blog says that creation calls that take the algorithm as input record it. For example, kms:CreateKey records the KeySpec, and acm-pca:CreateCertificateAuthority records the signing algorithm. Because attaching a listener references the certificate by ARN, the certificate's algorithm does not appear in that event.

The KMS Developer Guide provides CloudTrail examples that show the keySpec field in a CreateKey event and the signingAlgorithm field in a Sign event. The example values are not ML-DSA.

In the configuration in Section 10, the allowed CreateKey event kept keySpec. The denied CreateKey event recorded no algorithm-related request parameters. So in this configuration, the record of a denied attempt to create an ML-DSA-44 key did not include keySpec. The denied record did not show which key spec was requested.

9.2 AWS Config

The table in Part 2 of the AWS Security Blog gives the detection of unapproved variants as Supported using custom AWS Config rules; not managed rules.

The managed AWS Config rule acm-certificate-rsa-check verifies that the key length of ACM RSA certificates is 2048 bits or greater. It does not look at ML-DSA variants.

The repository for AWS Config resource schemas, awslabs/aws-config-resource-schema (retrieved on October 21, 2026), includes the following fields:

AWS::KMS::Key: configuration.keySpec, configuration.signingAlgorithms
AWS::ACM::Certificate: configuration.keyAlgorithm
AWS::ACMPCA::CertificateAuthority: configuration.KeyAlgorithm, configuration.SigningAlgorithm

These are the values in the schema repository. This article does not verify the actual format of the configuration items. The list of supported AWS Config resources includes AWS::KMS::Key, AWS::ACM::Certificate, AWS::ACMPCA::CertificateAuthority, AWS::IAM::ServerCertificate, and AWS::RolesAnywhere::TrustAnchor. AWS::EC2::KeyPair was not found on the list.

9.3 AWS Security Hub CSPM

The AWS Security Hub User Guide lists KMS.1 through KMS.5 as Security Hub CSPM controls for KMS, ACM.1 through ACM.3 as controls for ACM, and PCA.1 and PCA.2 as controls for AWS Private CA. No control title mentions key specs or ML-DSA. ACM.2 is the closest, as it checks the key length of RSA certificates managed by ACM.

9.4 Key Inventory

Part 2 of the AWS Security Blog describes how to find existing ML-DSA-44 keys as follows:

AWS KMS has no server-side filter for key spec, so you must enumerate keys with ListKeys and call DescribeKey and inspect each KeySpec.

The blog also states that denying kms:KeySpec can be applied at the time of the request, regardless of which keys exist. You only need to search for keys when you want to disable or delete them. The blog advises verifying that a key is not in use before deleting it, as deleting a used key will prevent signature verification.

10. What This Configuration Returned: A Record of IAM Policies in One Account

This section records the results of attaching deny statements to IAM roles in one AWS account. SCPs were not used. The evaluation of condition keys was observed through IAM identity-based policies, and does not constitute an observation of SCP scope (Section 8).

10.1 The Configuration

Region: us-east-1
Run date: October 20, 2026 (UTC). The two RunInstances cases were run again on the same day with a subnet specified.
AWS CLI: aws-cli/2.37.12
Role R1: Carries the two kms:KeySpec statements and the one ACM statement from Part 2 of the AWS Security Blog, as written. It also carries a deny on CreateKeyPair and ImportKeyPair when ec2:KeyPairType is ed25519, and the same deny on RunInstances, checked with --dry-run only.
Role R2: Carries a deny on Sign when kms:SigningAlgorithm is ML_DSA_SHAKE_256. To see whether default values enter the request context, it also carries a deny on CreateKeyPair when ec2:KeyPairType is rsa, and a deny on RequestCertificate when acm:KeyAlgorithm is RSA_2048.
Role R1 created the ML-DSA-65 key. The caller running the demo created the ML-DSA-44 key with its own identity, to which neither R1 nor R2 applied.

10.2 AWS KMS Results

In the following table, "Denied" means an AccessDeniedException, where the error message named an explicit deny in an identity-based policy. The caller created the ML-DSA-44 key (keyB) between cases K5 and K6 and made one signature with it.

Case	Role	Operation	Key or input	Result
K1	R1	`CreateKey`	`KeySpec` of `ML_DSA_44`	Denied
K2	R1	`CreateKey`	`KeySpec` of `ML_DSA_65` (keyA)	Allowed
K3	R1	`Sign`	keyA (`ML_DSA_65`), `ML_DSA_SHAKE_256`	Allowed
K4	R1	`Verify`	keyA (`ML_DSA_65`)	Allowed
K5	R1	`GetPublicKey`	keyA (`ML_DSA_65`)	Allowed
K6	R1	`Sign`	keyB (`ML_DSA_44`)	Denied
K7	R1	`Verify`	keyB (`ML_DSA_44`)	Denied
K8	R1	`GetPublicKey`	keyB (`ML_DSA_44`)	Denied
K9	R1	`DescribeKey`	keyB (`ML_DSA_44`)	Allowed
S1	R2	`Sign`	keyA (`ML_DSA_65`)	Denied
S2	R2	`Sign`	keyB (`ML_DSA_44`)	Denied
S3	R2	`GetPublicKey`	keyA (`ML_DSA_65`)	Allowed

10.3 EC2 and ACM Results

The "Denied" result for EC2 indicates an UnauthorizedOperation. For ACM, the "Denied" result, like KMS, indicates an AccessDeniedException. The RunInstances command was executed with the --dry-run option only, and no instances were actually created. The initial E6 and E7 requests failed with a VPCIdNotSpecified error because the account had no default VPC, and the authorization evaluation was never reached. The following table presents the results of re-attempting E6 and E7 after explicitly specifying a subnet.

Case	Role	Operation	Input	Result
E1	R1	`CreateKeyPair`	`KeyType` of `ed25519`	Denied
E2	R1	`CreateKeyPair`	`KeyType` of `rsa`	Allowed
E3	R1	`ImportKeyPair`	An ed25519 public key	Allowed
E4	R2	`CreateKeyPair`	`KeyType` omitted	Denied
E5	R2	`CreateKeyPair`	`KeyType` of `ed25519`	Allowed
E6	R1	`RunInstances` with `--dry-run`	The ed25519 key pair imported in E3	Denied
E7	R1	`RunInstances` with `--dry-run`	The rsa key pair created in E2	`DryRunOperation`
A1	R1	`RequestCertificate`	`KeyAlgorithm` of `EC_prime256v1`	Denied
A2	R1	`RequestCertificate`	`KeyAlgorithm` of `EC_secp384r1`	Allowed
A3	R1	`RequestCertificate`	`KeyAlgorithm` omitted	Allowed
A4	R2	`RequestCertificate`	`KeyAlgorithm` omitted	Denied
A5	R2	`RequestCertificate`	`KeyAlgorithm` of `EC_prime256v1`	Allowed

DryRunOperation is the error code that says the request would have been authorized without --dry-run.

10.4 CloudTrail Records

Only the event names, error codes, and algorithm-related request parameters were taken from the CloudTrail event history. The following table presents a portion of this data.

Event	Case	`errorCode`	Algorithm-related request parameters
`CreateKey`	K1	`AccessDenied`	None recorded
`CreateKey`	K2	None	`keySpec` of `ML_DSA_65`, `keyUsage` of `SIGN_VERIFY`
`Sign`	K3	None	`signingAlgorithm` of `ML_DSA_SHAKE_256`, `messageType` of `RAW`
`Sign`	K6	`AccessDenied`	None recorded
`CreateKeyPair`	E1	`Client.UnauthorizedOperation`	`keyType` of `ed25519`
`CreateKeyPair`	E4	`Client.UnauthorizedOperation`	None recorded
`RequestCertificate`	A1	`AccessDenied`	None recorded
`RequestCertificate`	A2	None	`keyAlgorithm` of `EC_secp384r1`
`RequestCertificate`	A3	None	None recorded

10.5 What This Configuration Showed

This configuration showed the following five things. Each is one result from one account, and this article does not say that other configurations behave the same.

kms:KeySpec: It denied CreateKey for ML-DSA-44 and allowed CreateKey for ML-DSA-65. It denied Sign, Verify, and GetPublicKey on the ML-DSA-44 key and allowed DescribeKey. The results match the three operations that Part 2 of the AWS Security Blog says it tested.
kms:SigningAlgorithm: The deny on ML_DSA_SHAKE_256 stopped Sign with the ML-DSA-65 key and Sign with the ML-DSA-44 key. That it does not tell the variants apart showed in this configuration too. Calls to GetPublicKey were not blocked.
ec2:KeyPairType: CreateKeyPair for ed25519 was denied, and ImportKeyPair of the same type was allowed. A RunInstances --dry-run that named the imported ed25519 key pair was stopped by the deny on the same condition key. The key type was not visible at the import stage, but was visible at the instance launch stage.
Omitted parameters: CreateKeyPair without KeyType was stopped by the deny for ec2:KeyPairType equal to rsa. RequestCertificate without KeyAlgorithm was stopped by the deny for acm:KeyAlgorithm equal to RSA_2048. In this configuration, the default values behaved as if they were in the request context.
CloudTrail: The events of the denied CreateKey and RequestCertificate calls recorded no algorithm-related request parameters. The event of the denied CreateKeyPair call kept keyType. The allowed CreateKey recorded keySpec, and the allowed Sign recorded signingAlgorithm.

The omitted-parameter results point the other way from the description in Part 2 of the AWS Security Blog. The blog says that a plain StringNotEquals also denies a request that omits acm:KeyAlgorithm, and gives the reason the missing key makes the condition evaluate true. This configuration did not test plain StringNotEquals. This article only sets the two side by side and does not decide which holds in general.

Everything the demo created was cleaned up after the checks. The IAM roles, the EC2 key pairs, and the ACM certificate requests were deleted, and the two KMS keys were scheduled for deletion.

11. Failure Modes

The following are misreadings that are easy to make with the tables in this article.

Blocking ML-DSA-44 with kms:SigningAlgorithm: All three variants use the ML_DSA_SHAKE_256 signing algorithm. A deny also stops signing with the approved variants (Section 4.3).
Widening the kms:KeySpec deny to kms:*: This will prevent operations like DescribeKey and ScheduleKeyDeletion, making it impossible to manage the key you are trying to delete (Section 4.4).
Forgetting the replication of multi-Region keys: The blog's SCP example does not include ReplicateKey. The blog's text says to add it to the creation deny (Section 4.4).
Reading that a CA in AWS Private CA can be constrained with condition keys: AWS Private CA has no condition key for the algorithm. It is constrained through the permission to create CAs and the provisioning pipeline (Section 6.3).
Reading that pinning the CA variant also pins the certificate key: The subject key comes from the CSR, and AWS Private CA copies it without validating its algorithm (Section 6.4).
Writing the KMS value ML_DSA_SHAKE_256 into the SigningAlgorithm of AWS Private CA: The AWS Private CA value is the variant name, and the blog says that it does not accept ML_DSA_SHAKE_256 (Section 6.2).
Reading that imported certificates are also stopped by acm:KeyAlgorithm: acm:KeyAlgorithm is on RequestCertificate only (Sections 5.2 and 5.3).
Inspecting the certificate algorithm in an SCP on the listener APIs: The listener's API only references the certificate by ARN (Section 5.4).
Reading that ec2:KeyPairType also stops ImportKeyPair: The key-pair entry of ImportKeyPair has only tag condition keys. In the configuration in Section 10, the type was visible at launch, in RunInstances (Sections 7.4 and 10).
Reading that a denied event shows the requested key spec: In the configuration in Section 10, the denied CreateKey event did not record keySpec (Section 9.1).
Reading that an SCP applies everywhere in the organization: It does not apply to users and roles in the management account or to service-linked roles, and it does not reach compute you control (Section 8).
Asserting that kms:KeySpec can be used in an RCP: No statement was found in the sources this article read (Section 8.4).
Reading that AWS Config managed rules find ML-DSA variants: The blog refers to custom rules. The managed rule acm-certificate-rsa-check only checks the length of RSA keys (Section 9.2).

12. Frequently Asked Questions About Enforcing an ML-DSA Policy on AWS

Q1. Can kms:SigningAlgorithm block ML-DSA-44?

No. The signing algorithm of all three variants is ML_DSA_SHAKE_256. Part 2 of the AWS Security Blog says that kms:SigningAlgorithm cannot tell ML-DSA-44 apart from the approved variants. The condition key that tells the variants apart is kms:KeySpec (Section 4.3).

Q2. On which operations is kms:KeySpec evaluated?

The Service Authorization Reference JSON (retrieved on October 21, 2026) lists CreateKey and 45 operations on the KMS key resource. Part 2 of the AWS Security Blog tested Sign, Verify, and GetPublicKey, and says in its text that ReplicateKey is evaluated as well (Sections 4.2 and 4.4).

Q3. Can an SCP constrain the algorithm of a CA in AWS Private CA?

No. AWS Private CA's condition keys are limited to acm-pca:TemplateArn and tags; no condition key looks at the algorithm. Part 2 of the AWS Security Blog says to limit who can create CAs and to pin the algorithm in the provisioning pipeline (Section 6.3).

Q4. Can ML-DSA certificates be used with ACM or ALB?

In the sources on the check date, no. ACM uses RSA and ECDSA keys. Part 2 of the AWS Security Blog says that as of October 12, 2026, ALB and NLB listeners accept RSA and ECDSA certificates only (Sections 5.1 and 5.4).

Q5. Can SCPs constrain EC2 key pairs?

For the key type, yes, on CreateKeyPair. ec2:KeyPairType is on CreateKeyPair and not on ImportKeyPair. In the configuration in Section 10, which used an IAM policy rather than an SCP, a RunInstances request that used an imported key pair was stopped by this condition key. The values are limited to rsa and ed25519; there is no ML-DSA key type (Sections 7.4 and 10).

Q6. Do SCPs apply to the management account?

No. According to the AWS Organizations User Guide, SCPs do not apply to users or roles in the management account. They also do not apply to service-linked roles (Sections 8.1 and 8.2).

Q7. Can kms:KeySpec be used in an RCP?

No statement was found in the sources this article read. The RCP list of supported services includes kms, and the table on the KMS condition keys page lists IAM policies and key policies as valid policy types for kms:KeySpec, but does not include RCP (Section 8.4).

Q8. When was this article checked?

This article read the sources on October 21, 2026, and retrieved and counted the Service Authorization Reference JSON on the same day. The AWS Security Blog's statements about ACM and load balancer certificates carry the note at the time of writing (October 12, 2026), and the JSON for the condition keys may change with service updates (Sections 1.4 and 2.3).

13. Summary

The condition key that tells the ML-DSA variants apart is kms:KeySpec: It is on CreateKey and on the KMS key resource operations. kms:SigningAlgorithm has the same value for the three variants and does not tell them apart (Section 4).
ACM's acm:KeyAlgorithm only examines requests: No condition key on importing, uploading to IAM, or attaching to listeners sees the certificate's algorithm. In the sources as of October 12, 2026, ACM and listener keys are RSA and ECDSA (Section 5).
AWS Private CA does not have condition keys related to algorithms: The permission to create CAs, the provisioning pipeline, and pinning the CSR key remain with the user. The name SigningAlgorithm appears in three places, and the AWS Private CA values differ from the KMS value (Section 6).
The services outside the blog's scope have no condition key that sees the variant either: IAM Roles Anywhere accepts ML-DSA trust anchors and request signatures with the three ML-DSA variants. While ec2:KeyPairType is included in CreateKeyPair, it is not included in ImportKeyPair. In the configuration in Section 10, this condition key saw the type in RunInstances with an imported key pair (Sections 7 and 10).
There are places an SCP does not reach: the management account, service-linked roles, and compute you control. No statement on whether kms:KeySpec can be used in an RCP was found in the sources (Section 8).
Detection is the records of operations that take the algorithm as input, and custom Config rules: The CloudTrail event of an allowed CreateKey records keySpec; in the configuration in Section 10, the denied one did not. AWS KMS has no server-side filter for key spec (Section 9).

When assembling and testing SCPs within AWS Organizations, you can use the AWS Service Control Policy (SCP) Builder and Simulator to evaluate them by giving kms:KeySpec as an additional context key. The tool does not know on which operations AWS evaluates that condition key. Refer to the list of JSON operations in Section 4.2 to confirm the scope of operations.

14. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi