We publish our trust topology. All of it.

Each customer environment is provisioned into a dedicated AWS account. Keys, audit logs, API quotas, identity pools: everything you touch lives inside that account. There is no shared database with a tenant_id column, because there is no shared database.

The platform itself is split into planes with one-way trust: the public edge (this site and billing) writes billing facts to a ledger; the provisioning engine independently verifies those facts against Stripe before it acts. A full compromise of our public website cannot fabricate a paid customer, reach the provisioning engine, or touch any customer account.

Keys are generated inside AWS KMS using FIPS 140-3 Level 3 validated cryptographic modules, with key material flagged non-extractable, multi-region replication, and rotation enforced. Sign and decrypt operations execute inside the module; the API returns outputs, never key bytes.

To be precise for a security review: the FIPS 140-3 Level 3 boundary is the KMS HSM that generates and stores your private key material, reached over FIPS-validated AWS endpoints. Key material is created in that boundary and never leaves it; that scope is the entire basis of the guarantee, not a platform-wide certificate.

• SC-004 + SC-053Before any operation runs, two independent checks confirm the key is yours, exists, is enabled, and matches the requested use. Only then is the cryptographic module called.
• SC-054Moving encrypted data onto a different key checks that destination key too, so data can never be re-encrypted out to a key you don’t own.
• SC-055Only valid algorithm and key-type combinations are accepted. There is no way to request a weakened or mismatched operation.
• SC-062For key types that support automatic rotation, rotation is switched on the moment the key is created. If it can’t be, the key is deleted and creation fails, so a non-rotating key can never quietly exist.
• SC-031 + SC-004Even a fully compromised application function cannot disable or delete your keys: its permission ceiling explicitly forbids those actions.

We do not operate a “support backdoor.” If you lose access to your keys and have not configured escrow, we cannot recover them. We consider that a feature, and we say so before you buy.

• SC-007Two-factor sign-in uses authenticator-app codes only, never SMS, so SIM-swap attacks simply don’t apply. Accounts are created by your admin, not open registration, and password recovery can’t be used to skip the second factor.
• SC-009Sign-ins using passwords known from public data breaches are blocked outright, and unusual sign-in patterns trigger extra challenges.
• SC-038 + SC-039Sign-in tokens are accepted only in the exact cryptographic form we issue. Forged or downgraded tokens are rejected before their contents are even read, and a token issued for one purpose can’t stand in for another.
• SC-042Permission changes take effect on the very next request. Revoking an API key or narrowing access never waits for a cache to expire, because authorization is never cached.
• SC-002 + SC-003An API key can never carry more power than the person who created it, and your admin can cap or shut off all programmatic access at once instead of hunting down keys one by one.
• SC-005Administrative privileges are stripped at the identity provider before a token is ever signed, so a misconfigured app can’t hand out rights a user doesn’t have.

Checkout and billing management are hosted by Stripe, on Stripe’s pages, on Stripe’s infrastructure. Your card number and CVV are entered into Stripe’s UI and never transit or rest on a SanctiKey server. We store only opaque Stripe identifiers (cus_…, sub_…), useless to an attacker as payment instruments.

Billing events arrive from Stripe over a cryptographically signed webhook. We verify the signature on the raw payload before parsing a single byte, reject anything older than five minutes, and process every event exactly once. Our signup API actively rejects any request containing card-like fields; accepting card data anywhere is a tested failure condition.

Everything sits behind CloudFront with WAF managed rule sets, rate limiting, geo controls, and abuse auto-blocking. Authenticated APIs additionally verify an edge-injected origin header, so they cannot be reached except through the hardened front door.

• SC-071 to SC-073Modern encryption (TLS 1.2 or newer, strict cipher settings) is required on your connection, security headers go out on every response, and even the internal leg between our CDN and the origin is encrypted. Both sides of the connection, not just yours.
• SC-006 + SC-043The API gateway is the hardened front door: a regional firewall with managed attack-pattern rules and per-IP rate ceilings sits directly on it, and requests without credentials are rejected by the gateway itself before any application code runs.
• SC-080Every request is checked against a strict schema twice, once at the edge and once in the application. Unknown fields and out-of-range values are refused at both.
• SC-068 + SC-082Abuse detection identifies the real client address in a way that can’t be spoofed, and it won’t ban an entire office because one person behind a shared connection misbehaved.
• SC-078Cryptographic endpoints carry their own tighter rate ceilings, separate from the rest of the API.

• SC-029Every database change is recorded with both its before and after state in a tamper-evident stream. A deletion or a status change can’t vanish from history.
• SC-019If an audit record ever fails to write, that failure itself raises an alarm. A gap in the trail is something we get paged about.
• SC-079 + SC-061Logs capture diagnostic metadata only, never request contents, tokens, or credentials, and error messages are fixed sanitized text. No stack traces, no internal identifiers, ever.
• SC-013 + SC-028Data stores can be restored to any point in time and carry two independent layers of deletion protection, because either layer alone can be bypassed by mistake.

The pipeline is part of the attack surface, so it carries the same discipline as the product:

• SC-084The pipeline holds no stored cloud passwords. Every deployment uses short-lived credentials issued for that one job. There is nothing to steal.
• SC-085 + SC-032Reading and changing infrastructure are two separate identities, and the one that can change things only works from the main branch. A malicious pull request can look, not touch.
• SC-030 + SC-031Everything that runs does so under an enforced permission ceiling, and the pipeline is structurally unable to create anything without one. A compromised component stays in its own lane.
• SC-086 to SC-088Four automated scanners gate every change: infrastructure misconfiguration, insecure code patterns, dependencies with known vulnerabilities, and accidentally committed secrets.
• SC-090Nothing reaches production without explicit human approval, independent of every other safeguard.

The plane you used to reach this page is the public edge: signup, billing, and the portal. It writes billing facts a provisioning engine independently re-verifies against Stripe. Here are its three flows end to end; a compromise of any of them cannot fabricate a paid customer or touch a key.

• ✕Private keys: no extraction path exists, for anyone
• ✕Card data: lives at Stripe; we hold tokens only
• ✕Your plaintext: operations run in-module; bodies are never logged
• ✕Other tenants from your account: there are none

• We run on AWS. Our isolation model inherits AWS’s account boundary. If you require sovereignty from US hyperscalers entirely, we are not the right product today.
• FIPS 140-3 applies to the modules, not to every line of our application code. We follow the discipline platform-wide, but the certificate belongs to the HSMs.
• The AWS account is SanctiKey-owned. We operate it inside our AWS Organization under guardrail policies; you are its only tenant. Exclusive tenancy is architectural. And there is no lock-in: the Keyout Right, a published-fee account hand-off available to every account, is yours alone to invoke, we never initiate it, so you can take the account and your keys whenever you choose to leave.
• The control catalog is self-attested. The 90 controls cited on this page are documented and tested by us, not yet certified by a third party. We’d rather show you a numbered, specific catalog than a vague badge.
• Availability follows AWS regions. Keys are multi-region, but a full regional failover runbook is published with honest RTO numbers, not marketing zeros.

Found something? Email security@sanctikey.com. We acknowledge within 48 hours, we don’t pursue good-faith researchers, and we credit fixes publicly unless you prefer otherwise.