Once you introduce post-quantum signatures, the next question is whether every account will follow your approved algorithm policy. A design document alone cannot prevent teams from creating keys through a different path.

An AWS technical guide published on October 12, 2026 makes this concrete with ML-DSA parameter sets. Its example organization approves ML-DSA-65 and ML-DSA-87 and excludes ML-DSA-44, using SCPs and IAM to enforce that decision.

Is blocking new keys enough? What happens to existing keys and certificates? Understanding what AWS KMS evaluates helps separate controls that belong in policies from controls that belong in provisioning.

Key specs distinguish ML-DSA variants; the signing algorithm does not

ML-DSA provides post-quantum digital signatures. NIST published FIPS 204 on August 13, 2024, and AWS announced KMS support on June 13, 2025. The current topic is how to govern that capability through access controls.

KMS separates the key property KeySpec from the request parameter SigningAlgorithm. The key spec reference maps them as follows.

All three share the same signing algorithm value. Consequently, kms:SigningAlgorithm cannot distinguish 44 from 65 and 87. The kms:KeySpec condition can evaluate both a requested key spec during creation and the properties of a key used by an operation.

Excluding 44 is an organizational standardization choice in this example. ML-DSA-44 is also standardized in FIPS 204; its exclusion does not mean it is insecure. The approved set depends on signature and key sizes, performance, and the desired security margin.

Deny creation and existing-key use through their respective API operations

Denying CreateKey leaves previously created keys in place. To restrict those keys as well, cover Sign, Verify, and GetPublicKey. The KMS condition key documentation confirms that kms:KeySpec applies to both creation and KMS key resource operations.

This SCP example combines the AWS statements that share the same condition and includes multi-Region replication. It denies creation, replication, and use of ML_DSA_44 keys in scope; it does not grant permissions.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyExcludedMlDsaKeyOperations",
      "Effect": "Deny",
      "Action": [
        "kms:CreateKey",
        "kms:ReplicateKey",
        "kms:Sign",
        "kms:Verify",
        "kms:GetPublicKey"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:KeySpec": "ML_DSA_44"
        }
      }
    }
  ]
}

Replication belongs here because it creates another key in a different Region. Avoid expanding the action list to kms:*: that could also deny inspection, disabling, and deletion scheduling for the excluded keys. Explicit actions preserve the administrative path needed to manage them.

This policy neither prohibits RSA or ECDSA nor grants access to 65 or 87. Requiring all signing keys to use ML-DSA is a separate policy decision. Because the example also denies Verify, identify verification workflows that depend on existing 44 keys and decide how to transition them before enforcement.

Align SCP placement and IAM roles, then test success as well as denial

An SCP's placement at the organization root, an OU, or an account determines its scope. Start with a test OU and expand toward production after checking the effects. Under the Organizations rules, management-account identities and service-linked roles are outside SCP restrictions.

For role-level controls, use the same deny condition in an identity-based IAM policy. If using a permissions boundary, do not make this deny-only document the entire boundary: the boundary also needs to allow the intended actions. Permissions boundaries set a ceiling without granting permissions themselves. Enforce their attachment and prevent unauthorized removal.

Test with a role that already has the necessary permissions so that the new restriction is the variable. The following are expected outcomes to verify, not results from an executed AWS test.

Testing only failures can mistake missing permissions for successful enforcement. Successful operations with approved keys, plus administrative access, help establish that the intended boundary is in place.

Private CA and operations outside KMS need provisioning controls

Restricting KMS keys does not apply the same condition to AWS Private CA keys. The Private CA authorization reference provides no dedicated algorithm condition key for CA creation. Restrict creation to approved provisioning roles and pin the configuration in that trusted workflow.

The parameter values differ too. In CertificateAuthorityConfiguration, KeyAlgorithm and SigningAlgorithm accept variant values such as ML_DSA_65. The KMS value ML_DSA_SHAKE_256 does not belong in those fields.

A CA's own key is also distinct from the public key in an issued certificate. The latter comes from the certificate signing request, or CSR. Govern the CSR key algorithm in the issuance pipeline as well as the CA configuration.

The API boundary also matters for cryptographic libraries running on EC2, in containers, or in Lambda. SCPs evaluate AWS API operations, not signature calculations inside an application. Denying GetPublicKey later cannot stop local verification using a public key already retrieved.

Update ML-DSA prevention and detection when the approved set changes

The deny example names only 44. A newly introduced parameter set would not automatically be denied. To block unevaluated variants first, one option is to scope a condition to ML_DSA_* with StringLike and deny values outside the approved set with StringNotEquals. The tradeoff is a policy update whenever another variant becomes approved.

Pair prevention with CloudTrail visibility into key and CA creation, and configuration evaluation through tools such as AWS Config custom rules. An API event does not always contain enough information. When an operation references a certificate by ARN, determining its algorithm requires looking up the certificate rather than relying on that event alone.

An operational signing policy connects three things: approved keys remain usable, excluded keys cannot be created or used through the governed APIs, and provisioning or execution paths outside those APIs are controlled separately. Keep those three elements and the detection rules ready to change together. That turns algorithm selection into a maintainable governance process.

Source

• Title: Quantum-resistant signing on AWS, Part 2: Enforce your ML-DSA algorithm policy with SCPs and IAM
• URL: https://aws.amazon.com/blogs/security/quantum-resistant-signing-on-aws-part-2-enforce-your-ml-dsa-algorithm-policy-with-scps-and-iam/