SanctiKey

Philosophy

What we do, and why we do it this way.

SanctiKey exists because key custody is a trust problem before it is a technology problem. Every managed crypto service asks you to believe a policy document. We would rather hand you a boundary you can verify: a dedicated AWS account, vended for you alone, with your keys inside FIPS 140-3 validated modules that nothing, including us, can extract from.

That choice drives everything else on this page: why our billing plane cannot reach your keys, why every account ships the complete product, and why you can buy the account holding your keys and audit logs out from under us whenever you choose.

FIPS 140-3

validated cryptographic modules

1 account = 1 customer

hard isolation, no co-tenancy

PCI SAQ-A

card data never touches our infra

Tamper-evident

every operation audit-logged

The isolation boundary

Your boundary is an AWS account, not a partition.

When you subscribe, our provisioning engine vends a brand-new AWS account and builds your HSM environment inside it. Your keys, your audit log, your quotas, your blast radius, all bounded by the same wall AWS uses to separate competing enterprises.

Even our own public edge, this website and our billing system, is architecturally incapable of reaching your environment. The plane that takes your payment cannot touch the plane that holds your keys. We designed it that way on purpose, and we document it publicly.

To be precise about ownership: SanctiKey owns and operates the account inside our AWS Organization; your keys and audit logs are yours, you are its only tenant, and we publish exactly what our operators can and cannot do.

→ See the full trust topology
SanctiKey platform

Gatehouse

This site · signup · billing edge

writes billing facts only

Ledger

Subscription source of truth

verified against Stripe directly

Warden

Provisioning engine

account vended across the boundary

Your AWS account

One tenant: you

KMS (FIPS 140-3) · API · audit · Cognito

No co-tenants. No shared anything.

What you can do

An HSM workflow, not a key-value store

Inside that boundary you get the full toolkit: sign and verify, encrypt and decrypt, run a certificate authority, escrow for recovery, federate into your identity provider, and audit every operation. One REST API, the same capabilities for every account.

→ See the full platform

The weakest component

The attack surface most vendors do not talk about is the people running the system.

Phishing works. Spear phishing works better. Credential theft, social engineering, and insider error account for the majority of security failures in organizations that have otherwise done everything right. The HSM in the locked room is only as secure as the people with badge access, the administrator with the master password, and the process for exporting cryptographic output into the systems that actually use it.

SanctiKey is engineered to remove that surface wherever possible. The platform runs without human intervention in the cryptographic operations themselves. There is no operator who can be phished into handing over a key, no support backdoor that can be socially engineered, no manual rotation process that fails quietly when the responsible engineer changes jobs.

That is not an argument that cloud is inherently safer than on-premises. It is an argument that the threat model for most organizations is dominated by human failure, not hardware failure, and that a system designed to minimize human access to key operations is a more honest response to that threat model than a system designed to maximize human control over it.

If your threat model genuinely requires physical sovereignty from all cloud infrastructure, we are not the right product. We say that directly on our known limits page.

Why not build it yourself

You can. Here is what that actually requires.

AWS KMS is powerful, well-documented, and FIPS 140-3 validated. Nothing stops an engineering team from building directly on top of it. If you have a dedicated security engineer who knows KMS deeply, time to build the compliance controls and audit trail on top of the primitives, a rotation and incident response process that will still be running correctly two years from now when staff has changed, and someone accountable when your auditor asks about key management at 9pm before a certification deadline, DIY is a legitimate path.

Most organizations arriving at this decision do not have that combination available at the moment they need it. They have capable engineers carrying multiple responsibilities, a compliance requirement that arrived faster than expected, and key management sitting at the bottom of the priority list until it suddenly is not.

SanctiKey is the operational and compliance layer you would otherwise have to build, staff, and maintain yourself. The cryptographic primitives are the same. The difference is who is responsible for keeping them configured correctly over time.

If you evaluate SanctiKey and conclude your team has what it takes to do this well independently, we will tell you that. We have no interest in selling infrastructure to organizations that do not need it.

How we sell

We diagnose before we prescribe. If SanctiKey is not the right fit, you will hear that from us.

SanctiKey solves a specific problem. It is not the right answer for every organization with a cryptographic need, and we do not treat it as one.

When someone asks whether SanctiKey fits their situation, the conversation starts with their problem, not our product. What does their current key management setup look like. What compliance pressure are they under and on what timeline. Do they have the staff to build and maintain this themselves. If the answers tell us they do not need SanctiKey, or that something else serves them better, we say so.

We built this platform because the problem is real and the existing options are either too complex, too expensive, or too opaque for the organizations that need it most. That is the only reason to buy it. If it is not your reason, we would rather you know that before you sign up than after.

The Keyout

The exit ramp you own, written before you need it.

A key-custody vendor that can strand your keys has leverage over your entire business. The Keyout removes that leverage permanently. It is a standing, published right to acquire the AWS account that holds your environment, lift it out of our Organization, and own it outright, with your keys and your audit history intact.

It works because of how the platform is built. Your key material lives in AWS KMS inside your own dedicated account; SanctiKey never holds a copy of a private key. Our managed layer adds the workflow, compliance tooling, and operational simplicity on top, but the keys themselves never depend on us staying in business. The buyout simply makes that independence formal and final.

Who can pull the trigger

You, and only you. SanctiKey will never initiate a buyout on your behalf and can never take your environment from you. The single exception: if we are compelled to remove you for a breach of our Terms, we may offer the Keyout as your exit ramp, so that even an involuntary departure still leaves with your keys in your hands.

How a buyout unfolds

Once you confirm and payment clears, the hand-off runs in three phases over roughly 91 days. The length is deliberate: it lets our proprietary deployment history age out of the account before it leaves our control. None of it interrupts your cryptographic access.

Phase 1 · Compute demolition (Day 1)

Our Lambda, API Gateway, and IAM orchestration are stripped from your account. Keys stay intact.

you keep operating via direct KMS calls

Phase 2 · Transition quarantine (Days 2-90)

The account stays in our Organization while CloudTrail deployment history ages out. Non-disruptive to you.

full key + audit access throughout

Phase 3 · Account ejection (Day 91)

The account is ejected to your sole ownership. SanctiKey retains no access, ever.

The instant Phase 1 completes, your managed endpoints go quiet but your keys do not: you operate them directly through the AWS KMS API using the IAM role provisioned at onboarding. There is no window where your cryptography stops working.

What leaves with you

  • +The AWS account itself, ejected from our Organization into your sole ownership
  • +Every KMS key and all key material, untouched and operational
  • +Your audit trail: the tamper-evident record of every operation, exported from DynamoDB

What stays ours

  • Our Lambda function source and packaged binaries
  • Our API Gateway configurations and deployment templates
  • Our IaC blueprints and CloudFormation stacks
  • SanctiKey trademarks, brand assets, and documentation

You receive the account, your keys, and your audit trail, never our software. The SanctiKey service layer is decommissioned during Phase 1, not handed over.

Honest about the edges: the buyout is fully specified for voluntary, cooperative hand-offs. The involuntary cases, a bankruptcy or an acquirer inheriting the company, are still being legally hardened so the right survives a change of control. We would rather tell you that than pretend the work is finished.

→ How the buyout fee is calculated

Provisioned in minutes. Isolated by construction.

And there is no lock-in: every account carries the Keyout Right, yours alone to invoke. Take the AWS account, your keys and audit logs with it, and own it outright for a published fee. The exit ramp is yours, never ours.