The honest comparison
Why not just use KMS?
AWS KMS is a good product, it’s well documented, and the cryptographic modules behind it are the same FIPS 140-3 Level 3 validated modules your keys are generated in when you buy from us. We build on KMS, so we’re not going to spend a page arguing it’s bad.
The useful question is narrower than that. What does KMS not do, what would you have to build on top of it to close the gap, and is there anything it structurally can’t give you no matter how much you build? There’s one of those, and it’s the reason this product exists at all.
The argument KMS cannot make
If your keys live in your own AWS account, whoever owns your AWS organization owns your keys.
That’s not a criticism of KMS, it’s just what an account is. Your key policy gets evaluated by the same organization the attacker has taken over, so management account credentials, a compromised org-level role, an SCP change or a stolen administrator session all land in the same place: the person holding your data is now on the same side of the wall as the key protecting it.
We hold your keys in an AWS account outside your organization entirely, which means an attacker who owns your whole AWS environment still can’t extract or use them. They’d need SanctiKey credentials, issued by a different identity provider, in an account they have no path to enumerate.
No key store living inside the same organization as the thing it protects can make that argument, however carefully its key policies are written. That’s the part you’re actually buying.
Keys inside your own organization
- Attacker reaches org-level credentials.
- Your key policies are now evaluated by an org they control.
- Data and key sit inside one blast radius.
Keys in a SanctiKey account
- Same attacker, same total compromise of your environment.
- The key lives in an account they can’t enumerate, under an identity provider they don’t hold.
- They get ciphertext, plus an audit trail with their attempts in it.
The capability delta
The capability delta, including the rows where KMS wins.
| Capability | AWS KMS on its own | SanctiKey |
|---|---|---|
| Key material in FIPS 140-3 Level 3 validated HSMs | Yes | Yes, the same modules (CMVP #4884) |
| Isolation from your own AWS organization | No, by definition | Yes, a separate account on a separate trust axis |
| CA hierarchy: roots, intermediates, chaining | No, that is AWS Private CA at $400 per CA per month | In the base subscription, not priced per CA |
| CSR import and signing into external chains | No | Included |
| Operational partitions with group-scoped access | Key policies and IAM, assembled by you | Named partitions, each with its own access group and audit trail |
| Enforced lifecycle: rotation or the key does not exist | Rotation is a setting that can be left off | SC-062: rotation is enabled at creation or creation fails and the key is deleted |
| Per-operation record built to be handed to an assessor | CloudTrail, a general-purpose management log | Purpose-built tamper-evident per-operation trail, exportable |
| Certificate enrollment protocols (ACME, SCEP, EST) | No | No. Integration is your pipeline calling the REST API, plus the console |
| Console for people who do not live in the AWS console | The AWS console | Purpose-built: keys, certificate authorities, signing, policies, audit |
| Time to build all of the above on KMS yourself | Months of engineering, then owned forever | $49 a month, provisioned in minutes |
On raw price KMS wins outright and we’re not going to pretend otherwise, since it’s a primitive priced like a primitive and every row above is something you’d be paying us to build on top of it. If a key inside your own account covers what you need, buy that.
Building it yourself
You can build all of it on KMS yourself, and here’s what that takes.
The isolation
A second AWS account outside your organization, its own identity provider, its own permission boundaries, and a provisioning path that does not hand your own operators a way back in.
The CA layer
Root and intermediate ceremonies, chain construction, CSR handling, revocation, and the operational discipline to keep the root offline and the intermediates rotated.
The governance layer
Partitions, group-scoped access, rotation enforcement that fails closed, algorithm pinning, and the API surface that makes all of it usable by a team that is not you.
The evidence layer
A per-operation record with integrity protection, a monitored write path so a gap raises an alarm, and an export format someone outside your company can read.
The part nobody budgets for
Keeping all of it correct two years from now, after the engineer who built it has changed jobs and the compliance deadline moved up on you.
None of that is exotic work, it’s just months of it, and then you own it forever. The cryptographic primitives come out identical either way, so what you’re actually deciding is who stays accountable for keeping them configured correctly two years from now.
When KMS alone is right
Situations where KMS on its own is the right purchase.
- The key protects data in the same account.If compromise of your own AWS organization isn’t in the threat model you’re defending against, the second trust axis buys you nothing and costs you money every month.
- You have the team and the runway. A security engineer who knows KMS deeply, with room to build the governance and evidence layers and keep maintaining them, is a legitimate path, and we say the same thing on why not build it yourself.
- You need a public trust chain.Browser-trusted TLS and publicly trusted code signing need a CA admitted to a root program, which we’re not and aren’t applying to become. What we serve is private trust: firmware, device identity, internal signing and mTLS.
Need a certificate authority too?
Then the comparison that matters next is against AWS Private CA, not against KMS. That page is mostly arithmetic and it is shorter than this one.