SageMaker MLflow adds customer-managed KMS keys
For FedRAMP and CMMC shops, the shift from AWS-managed to customer-managed keys means CloudTrail audit trails on MLflow data access are now independently verifiable.
TL;DR
AWS SageMaker MLflow now supports customer-managed KMS keys for encryption, giving customers control over key management and independent CloudTrail audit trails. Previously, MLflow used AWS-managed keys: encryption existed but key-access logging was invisible to the customer. For defense contractors and organizations operating under CMMC or FedRAMP, the shift turns a black-box encryption posture into something an assessor can independently verify. Constraints are standard KMS fare: symmetric keys only, same account and region as the MLflow app.
The gap SageMaker MLflow just closed isn't about whether data was encrypted, it was. AWS-managed keys have always provided encryption at rest. The gap was about who could prove it, and to whom. Under AWS-managed keys, CloudTrail logs key access, but the customer can't see those logs, can't revoke the key on their own timeline, and can't rotate it on their own schedule. For a CMMC assessor or a FedRAMP auditor, that's the difference between "encryption exists" and "encryption is demonstrable under customer control."
Under 800-171 control 3.13.11, which requires cryptographic protection of CUI at rest, the control doesn't explicitly demand customer-managed keys. But in practice, the audit distinction matters. A System Security Plan that says "AWS encrypts it" and one that says "we encrypt it under keys we manage, and here are the CloudTrail logs" are not treated the same way by a DIBCAC assessor.
The feature ships with the standard KMS constraints: symmetric keys only, and the key must live in the same AWS account and region as the MLflow app. It's available in all commercial regions where SageMaker MLflow operates. The engineer's Monday move: update the MLflow app configuration to reference the CMK, confirm CloudTrail is logging, and file the change in the SSP. No new service to provision, no architecture change, just a configuration flag that meaningfully shifts the audit posture.
Published ·Updated ·Deep Fathom