Encryption Keys Aren’t Just Technical—They’re Strategic: Getting Key Management Right for Federal Compliance
Encryption is often treated as a solved problem. After all, cloud platforms make it easy: flip a switch, set a default key, and let the platform handle the rest. But for organizations operating in federal, defense, or highly regulated environments, this perception is dangerously incomplete.
Behind the convenience of built-in encryption lies a more complex question: Are your key management practices actually compliant with federal standards, or just cloud-native defaults? For too many teams, the answer is the latter—and that gap could introduce real exposure during an audit, an accreditation process, or worse, a breach investigation.
Key management isn’t just about turning encryption on. It’s about demonstrating control over how your data is protected, who can access it, and under what conditions. And in the federal space, the bar isn’t defined by what your cloud provider offers out of the box—it’s defined by NIST.
NIST Says CMKs—Not Just Encryption
Under NIST SP 800-53 and related guidance (including overlays for IL4 and IL5), you are required to use customer-managed keys (CMKs)—not just platform-managed encryption. This means you must retain direct administrative control over encryption keys used to protect mission data.
In AWS, this distinction matters. AWS KMS makes it easy to enable encryption at rest across dozens of services. But if you’re relying on the AWS-managed keys (the default), you are not meeting the CMK requirement. Those keys are owned and controlled by AWS. You cannot define granular key policies, rotate on your own schedule, or tightly scope access to the key beyond basic IAM permissions. More importantly, you cannot demonstrate sole custodianship over encryption—a requirement in federal systems managing sensitive data.
This issue came into sharp focus in 2022, when researchers disclosed a vulnerability in AWS KMS that theoretically allowed privilege escalation through key policy misconfiguration. While AWS quickly mitigated the risk and clarified their documentation, the incident highlighted a deeper truth: encryption cannot be blindly trusted simply because it exists.
Control matters. Transparency matters. And relying on provider-managed keys robs you of both.
CMK Enforcement in AWS: Not as Easy as It Looks
Even when organizations intend to use CMKs, enforcing their use across a distributed AWS environment is more difficult than it seems. Setting a CMK as the default encryption key for an account or service is a good starting point—but it’s not enough to guarantee compliance.
For example, some services like S3 or RDS allow individual resources to override default keys. Others, like EBS or SNS, may default back to platform-managed keys unless explicitly configured at provisioning time. Even within the same service, developers may create resources using the CLI or SDKs with no enforcement of encryption context. And if you operate in a multi-account model, CMK visibility and policy management becomes even more fragmented.
There is no global switch that says “always use this CMK.” Ensuring CMK enforcement means implementing service control policies (SCPs), validating infrastructure-as-code (IaC) templates, and conducting continuous monitoring across environments to flag deviations. It also means managing key rotation, logging, access reviews, and lifecycle policies that tie back to your broader compliance framework.
In short: CMK strategy isn’t just a checkbox—it’s a control surface.
One Key or Many? Let Risk, Not Simplicity, Drive the Answer
Beyond the “what type of key” question, organizations often struggle with how many. Should you use a single CMK for everything? One per service? One per workload?
There’s no universal answer. But at SkyDryft, we’ve developed a pragmatic set of guidelines based on risk, scale, and complexity.
For small environments using just a few services—say, EC2 and S3, or Lambda and RDS—a single well-scoped CMK can be sufficient. The key here is predictability: low change velocity, minimal user interaction, and centralized ownership make managing a single key feasible and secure.
But as the environment grows in scope—more services, more data types, more teams—the case for multiple CMKs becomes stronger. Isolating encryption boundaries by workload (not by service) provides several benefits:
Limits the blast radius of compromise if a key is misconfigured
Simplifies audit trails by aligning keys with operational context
Enables finer-grained key policies tied to workload-specific IAM roles
Allows for differentiated rotation and access strategies
For example, if two workloads both use RDS but serve entirely different mission functions, they should have separate CMKs, even if the underlying service is the same. Conversely, if a single workload uses S3, RDS, and SQS together in a tightly coupled fashion, grouping those under a single CMK may be appropriate.
This model allows for a balanced tradeoff between manageability and isolation, rooted in actual mission architecture—not arbitrary per-service rules or oversimplified key sprawl.
Compliance Isn’t Optional—But Strategy Is
Failing to use CMKs in federal systems isn’t just a misstep—it’s a disqualifier. You cannot claim to meet IL4 or IL5 security standards if you don’t maintain direct administrative control over your encryption keys. But how you implement that control—how many keys, how you organize them, how you enforce their use—is a matter of strategy.
It’s tempting to over-correct with one key per resource, or to under-engineer with one key for everything. Neither is inherently wrong, but both carry hidden costs. The right approach is to align key boundaries with workload boundaries, map keys to risk domains, and ensure your team can demonstrate—not just declare—compliance.
The tools exist to make this possible. But they require forethought, documentation, and automation to do well. It’s not just about meeting the control on paper—it’s about making sure your encryption model reflects the trust boundaries that matter in your system design.
Conclusion: Don’t Let Convenience Define Your Encryption Strategy
Encryption is more than a switch. It’s a statement about who controls your data, how access is governed, and whether your system can withstand scrutiny. In federal environments, that statement must align with NIST expectations—and that means using CMKs, not platform-managed keys.
But compliance is only the beginning. To build resilient, auditable infrastructure, your key strategy must match your risk posture and workload architecture. Whether you use one CMK or many, make that decision deliberately—not by default.
Because in the end, it’s not enough for your data to be encrypted. You have to prove you’re the one holding the keys.