A healthcare SaaS must prepare document-signing keys for quantum-safe requirements, needs FIPS-approved digital signatures with centralized key lifecycle, requires AWS-managed HSM backing, and must use standardized Module-Lattice algorithms without building custom crypto. Which post-quantum key management design meets these signing needs?
Select an answer to reveal the explanation.
Short Explanation
You need future-proof signatures without rolling your own crypto. ML-DSA in KMS gives you NIST-standard quantum-safe signing with managed keys and policies.
Full Explanation
The correct design is right because AWS KMS ML-DSA provides NIST-standardized Module-Lattice digital signatures that are FIPS-approved for quantum-safe signing, combined with AWS-managed HSM backing, centralized key creation rotation and deactivation, and IAM-controlled Sign and Verify workflows that meet healthcare lifecycle and compliance needs without custom cryptographic code. The KMS ECDSA design fails by algorithm concept because although it offers the same managed HSM backing, central lifecycle and FIPS-approved signing workflow, elliptic-curve signatures do not satisfy the explicit quantum-safe Module-Lattice requirement. The CloudHSM ML-DSA cluster design fails by operating-model concept because even if post-quantum signing were attempted there, single-tenant CloudHSM requires customer-managed provisioning, patching, clustering and lifecycle automation and therefore misses the required AWS-managed backing with centralized KMS control. The KMS ML-KEM design fails by purpose concept because although it is Module-Lattice, FIPS-approved, quantum-safe and centrally managed, ML-KEM is a key-encapsulation mechanism for key establishment rather than signing, and KMS ML-DSA keys are the signing option. As an exam caveat, always map KMS KeySpec and KeyUsage to workload intent since similar ML prefixes hide fundamentally different Sign Verify versus key-establishment operations. As a practical check, confirm with DescribeKey that KeySpec shows an ML_DSA value (ML_DSA_44, ML_DSA_65 or ML_DSA_87) with KeyUsage SIGN_VERIFY, backing as AWS managed, then test an IAM-scoped signing call before migration.