Documentation

Portal and console.

SanctiKey gives you two places to sign in, and they are not the same place. One handles money. One handles keys. Almost every early question we get is a person looking for something on the surface that does not hold it, so this page says plainly what lives where, and why we refused to put them together.

Two surfaces

The billing portal is on this website. It is the commercial relationship: the subscription, the payment method, the invoices, cancellation, and getting back in if you lose access to it.

The console is the product. It runs in the dedicated AWS account that your subscription provisioned, on its own address, and it holds the keys, the assets, the cryptographic operations, your users, and the audit trail.

Each surface has its own login, and neither login works on the other one.

The portal

The portal is the money surface. It carries five things:

• Signup and checkout. Your subscription starts here, before the console exists.
• Billing. Invoices and the payment method open on Stripe's hosted billing portal from a button in ours. We never display or store your card details.
• Plan changes. Adding or removing key slots, operation blocks, served regions, placed keys and failover protection happens on the portal's Change plan page, which states the charge, or the date a decrease takes effect, before you confirm.
• Cancellation. Ending the subscription is a portal action, on the same Stripe surface as the rest of the commercial record. When you come back from Stripe, the portal's overview shows that the cancellation is pending, the date service ends, and the date your environment and every key in it are destroyed. You can withdraw the cancellation on the Stripe billing page before the date service ends; the overview links to it.
• Account recovery. Recovering the portal login when the password or the second factor is gone runs from the portal sign-in screen. A guide to it is being written.

What the portal cannot do is more interesting than what it can. It reads your subscription status and changes what you pay for, and nothing else. There is no path from it to a key, to a cryptographic operation, to your audit trail, or to your data. Someone holding your portal password holds your billing history and no key material at all.

The console

The console is the key surface, and it is where your team works. It carries:

• Keys and assets. Creating keys, listing them, and opening one to see its detail, its partition and its regional placements.
• Cryptographic operations. Signing, verifying, encrypting and decrypting, and the certificate authority built on those keys.
• Users and permissions. Inviting people, assigning permission tiers, managing partitions, and connecting your identity provider. See Users and permissions and Federation.
• Audit. The record of every operation, readable in place and streamable into your own systems. See Audit.
• Your key count. The console shows how many keys you hold and how many you pay for, and links to the portal page that changes the second number.

The console shows no invoice, no card, and no cancellation control. It shows what you are entitled to; it never changes what you pay.

Which login goes where

The portal has one login. It is created from the email address you paid with, and that address is the account owner. The portal has no self-service signup, so there is no second portal login to hand out and no way for one to appear without a purchase. It is deliberately a single seat, because everything behind it is a money decision.

The console has as many logins as you need. They live in a directory that belongs to your account and holds only your people: your administrators, your operators, your auditors. Accounts there are created by your administrators, never by self-service registration, and the first one is created for you at provisioning. If you connect your own identity provider, your people sign in through it instead.

Both surfaces require multi-factor authentication with an authenticator app. It is enforced at the identity layer on each of them, so enrollment is not a setting either one lets you decline.

Why they are separate

Money authority and key authority never share a surface. The person who can cancel the subscription is not, by that fact, a person who can sign with your firmware key, and the administrator who signs firmware all day cannot change your payment method or end your contract.

The practical consequence is the one that matters during an incident. A stolen portal password is a billing problem. It is not a key compromise, because the portal has no route to a key, and the credential that does reach your keys lives in a different directory in a different account with its own second factor. One breach does not become the other.

It also means you can staff them differently. Finance holds the portal seat. Your security team holds console administrator seats. Neither group needs the other's credential to do its own job.

How you get both

The website is the entrance. Signup and checkout happen here: you give an email address, you verify it before checkout will open, and you pay.

Your portal login is created from that checkout, after the payment, not before it. The temporary password arrives by email once the purchase completes, which is why there is nothing to sign in to while you are still deciding. Your dedicated account provisions in parallel, and a second email carries the console address and the first administrator credential for it.

Getting started walks that path in order, including the first sign-in on each surface.

Changing your plan

After signup, you change what you pay for in the portal, on the Change plan page. It is the only place a key slot is bought or released, and the only place operation blocks, served regions, placed keys and failover protection are added or removed. The console shows your key count and links there.

The page states what the change costs before you confirm it. Adding keys charges the payment method already on your subscription for the rest of the current billing period, prorated. You do not enter a card, you do not start a new checkout, and you do not get a second subscription. The subscription quantity you already have goes up.

The charge is processed first and the capacity follows it. When the payment clears, your paid key count rises and your environment picks up the new ceiling on its own. The new keys are then yours to create.

Lowering the count works in the other direction. Your environment confirms the lower count against what it holds, the decrease then takes effect at once, and the unused part of the month is credited, prorated, on your next invoice; the page shows the credit before you confirm, and you receive an email with the outcome. Removing a served region or failover protection instead ends on the 1st of next month with no refund, and you can withdraw it until then. The count cannot go below the number of keys you hold: delete keys in your console first, then lower the count. The page tells you what you hold and when that was last measured. Until your environment has reported its usage, lowering is refused and raising still works.

The same page changes the rest of your plan. Operation blocks are a number, like keys. A served region and failover protection are chosen by region. Your home region comes with the base subscription, so the page shows it as included and never sells it as a served region or as a place for placed keys. Failover protects your home region or a region you serve. The page asks only which region to protect; the region it fails over to is chosen in your console's failover map. A placed key is chosen by region too: you pay for a slot there, and your console picks which key fills it. Adding any of them is charged before anything changes. One change runs at a time: if another change to your plan is still in progress, the page asks you to try again in a moment. Removing works like lowering keys: nothing leaves your bill while your environment still uses it. Placed key slots in a region cannot go below the keys placed there. A served region cannot be removed while failover protects it or a failover pair fails over into it; keys placed there are deleted from it on the 1st the removal ends on, and each key stays in your home region. Failover protection cannot end while a failover pair for that region exists. Your plan always keeps its included block of 100,000 operations, and extra operation blocks cannot go below what the operations already used this month need beyond it. Key slots carry no operations, so this month's use never holds a key slot. Empty the item in your console first. Limits covers the ceilings and what each dimension costs you.

Quick reference

Where to go next

• The path from checkout to your first signature: Getting started.
• What a key is, and what you can change about it later: Keys.
• What each console permission tier can actually do: Users and permissions.
• What you are billed for and where the ceilings sit: Limits.