A new set of preventive controls lets you lock down which ML‑DSA parameter sets may be created or used in your AWS account by applying Service Control Policies (SCPs) and IAM permissions. This matters because, once you have decided on an approved quantum‑resistant signature scheme, you need the cloud platform to enforce that decision automatically and surface any violations for remediation.
ML-DSA policy enforcement
AWS Key Management Service (KMS) currently offers three FIPS 204‑compliant ML‑DSA variants: ML-DSA-44, ML-DSA-65, and ML-DSA-87. In the example policy, the organization permits the latter two and blocks the former. By attaching an SCP that denies kms:CreateKey and kms:GenerateDataKeyPair calls when the KeySpec parameter equals ML-DSA-44, you prevent any principal in the organization from provisioning disallowed keys. Complementary IAM policies can be scoped to individual accounts or roles to reinforce the same deny logic for users who operate outside the organization‑wide boundary.
Similar deny statements can be applied to AWS Private Certificate Authority and AWS Certificate Manager APIs that accept an algorithm identifier, ensuring that private CAs cannot be instantiated with a prohibited ML‑DSA variant. Because the controls are expressed at the API level, they apply uniformly to all services that rely on KMS‑managed keys, including container image signing pipelines and software bill‑of‑materials generation.
Detecting policy drift
Even with preventive policies in place, you need visibility into attempts to bypass the rule set. Monitoring AWS CloudTrail for API calls that specify ML-DSA-44 provides a reliable audit trail. Any denied request appears as a failed event, which can be routed to Amazon CloudWatch Alarms or a SIEM for alerting. This detective layer satisfies the requirement that “any drift from those settings should be detected” and gives security teams evidence for corrective action.
Scope and limitations
The enforcement mechanisms operate only on AWS service APIs—specifically KMS, AWS Private CA, and AWS Certificate Manager. They cannot control cryptographic operations performed on compute resources you manage, such as OpenSSL calls on EC2 instances, container workloads, or Lambda functions. Likewise, protocol‑level uses of ML‑DSA (for example, SSH public‑key authentication) fall outside the reach of these policies. Practitioners must combine the API‑level controls with separate runtime safeguards if they run custom signing code on their own compute.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Adopt a two‑pronged approach: first, codify your approved ML‑DSA variants in SCPs and IAM policies to stop creation or use of disallowed keys at the source; second, enable CloudTrail logging and set up alerts for any denied attempts to ensure continuous compliance. Remember that these controls do not extend to user‑controlled compute, so you should also audit your build pipelines and runtime environments for ad‑hoc ML‑DSA usage. By aligning policy, enforcement, and detection, you keep the quantum‑resistant signing workflow both compliant and auditable.