SanctiKey

Documentation

Getting started.

This walks the path from a completed checkout to a verified signature. It takes about fifteen minutes, and most of that is waiting for your account to finish provisioning.

Signing up, step by step

  1. You give us an email address. Not a card, not a company profile. One address.
  2. You verify it before you can pay. We send a verification link and checkout does not open until you follow it. This is deliberate and it is the one step people are surprised by. The email address is the anchor for your subscription, your invoices, your account recovery and every notice we will ever send you, so an address with a typo in it is worse than a delayed signup.
  3. You pay. Checkout runs on Stripe. We never see your card number.
  4. Your account provisions itself. A dedicated AWS account is created and configured without anyone touching it. This takes a few minutes.
  5. Two emails arrive. One for billing, one for the service. They are different logins on purpose, which is the next section.

What checkout creates

Paying does not put you on a shared cluster. It provisions a dedicated AWS account that holds only your keys, and the isolation boundary of your key material is that account: its identity policies, its key policies, its quotas, and its own audit trail. Provisioning runs unattended and finishes in a few minutes. You get an email when the console is ready.

Keys are generated inside FIPS 140-3 Level 3 validated hardware security modules and are non-extractable. No key you create here has a plaintext form that anyone, including us, can read or copy out.

The two logins

You receive two sets of credentials and they are not interchangeable. Knowing which is which saves the most common piece of early confusion, which is looking for keys in the billing portal or for an invoice in the console.

  • A billing login, on this site. It manages the commercial relationship: your subscription, payment method, invoices, the spend ceiling, and cancellation. It never touches key material and cannot perform a cryptographic operation.
  • A service login, for the console in your own account. This is where the product is: keys, signing, certificates, users, partitions, audit. This login is the first administrator of your account and it is the one your team will actually live in.

Both require multi-factor authentication. Not as a recommendation and not as a setting you can decline: enrollment is forced on first sign-in for each of them. Two logins means two enrollments, so have your authenticator to hand for both.

After signup, buying more is done from the service console, not from this site. Adding keys, adding a served region, placing a key into one, or turning on failover protection all happen where you can see what you already have, and the subscription quantity follows automatically. The billing portal is where you go to change how you pay, not what you buy.

A tour of the surfaces

Four things exist and each has one job:

  • This site. Public pages, the legal terms, pricing, and the billing portal behind your billing login.
  • The console. Your account's own interface. Create and use keys, run your certificate authority, add users and assign permission tiers, connect your identity provider, read the audit trail, and buy additional keys and regions.
  • The API. Everything the console does to keys, addressable from your pipeline with an API key. This is the surface that matters for build systems and device provisioning lines.
  • Your audit stream. A notification topic in your account that emits every audit record as it is written, so evidence lands in your own systems without an export job. See Audit.

The first sign-in

Your provisioning email carries the console URL and a temporary password for the first administrator, which is the billing email you paid with. You are required to set a new password on that first sign-in. The temporary one is single-use and expires.

That first administrator is the only user who exists. Everyone else you add later starts with no permissions until you assign a tier, which is covered in Users and permissions. If you would rather your people sign in with your existing identity provider, set that up first and skip the per-user password entirely. See Federation.

Multi-factor enrollment

Multi-factor authentication is required, not optional, and it is enforced at the identity layer rather than by the console. You enroll a time-based one-time password authenticator on first sign-in: the console shows a QR code, your authenticator produces a six-digit code, and you confirm it once to complete enrollment.

Do this at enrollment, not afterwards

An account holds one authenticator per user. Enrolling a new one replaces the old one, so there is no second device to fall back on unless you create it at enrollment time. While that QR code is on screen, scan it into a second authenticator app, or store the secret it encodes somewhere you control. Both apps then produce the same codes.

Then add a second administrator with their own login and their own authenticator, before you need one. If the only administrator loses their only authenticator there is no self-service recovery, and no other user can clear it for them. This is the one setup step whose cost is measured in minutes now and in a stranded account later.

Your first key

Your subscription includes one key, and the first thing to decide is what it is for, because a key's usage is fixed when you create it. A signing key cannot later encrypt, and an encryption key cannot later sign. Pick from:

  • SIGN_VERIFY for firmware signing, code signing, device identity, and anything a certificate authority does.
  • ENCRYPT_DECRYPT for protecting data, either directly or by wrapping a data key.

Then pick the algorithm: RSA at 2048, 3072 or 4096 bits, an ECC NIST curve at P-256, P-384 or P-521, or a symmetric key. If you have no constraint pushing you elsewhere, ECC_NIST_P256 with SIGN_VERIFY is the smallest, fastest signing key that is not controversial anywhere. Keys covers every combination and the deletion lifecycle.

API credentials

The console is for people. Your pipeline uses an API key, which you create under your own profile. Two things about them are worth knowing before you create one.

First, the secret is shown exactly once, at creation. There is no endpoint that reveals it again, because we do not store a form of it that could be revealed. Capture it into your secret manager in the same step that creates it.

Second, an API key carries scopes you choose, and it can never carry more than the person who created it holds. The available scopes are account:read, keys:create, keys:read, keys:delete, crypto:sign, crypto:verify, crypto:encrypt, crypto:decrypt, crypto:re-encrypt and crypto:generate-data-key. A build agent that only signs should hold crypto:sign and nothing else, so a leaked pipeline credential cannot create keys, delete them, or decrypt anything.

Your first signature

Signing is synchronous. You post your message or its digest to the key's sign endpoint, naming a signing algorithm that matches the key, and the signature comes back in the response. Set message_type to DIGEST when you have already hashed the payload yourself, which is the normal case for large artifacts, and RAW when you are sending the bytes to be hashed here.

For artifacts too large to put in a request body, request an upload URL for the key instead. You upload the artifact directly, and the signature is produced against what you uploaded.

Verification takes the same shape: the message or digest, the signature, and the algorithm. Verifying does not require the signature to have been produced here.

Every operation is recorded

That first signature already wrote an audit record naming the key, the caller, the operation and the time. You did not have to turn anything on. Audit covers what is captured and how to stream it out.

Where to go next