Documentation
Keys.
A key is created inside a FIPS 140-3 Level 3 validated hardware security module and never leaves it. There is no export operation, no plaintext form, and no support path that produces one. Everything below follows from that.
Usage is permanent
Every key carries exactly one usage, chosen at creation and fixed for the life of the key:
- SIGN_VERIFY. Produces and checks signatures. This is the usage behind firmware signing, code signing, device identity and every certificate authority operation.
- ENCRYPT_DECRYPT. Protects data, either directly for small payloads or by wrapping a data key for large ones.
Message authentication codes are not offered. A MAC key would be billable and unusable because there is no MAC operation to call, so key creation refuses that usage rather than selling you something inert.
There is no conversion. A signing key that turns out to need encryption is a second key, which is a billing line, so the choice is worth five minutes up front. The reason for the rigidity is not ours: reusing one key for both signing and encryption is a well understood way to weaken both.
Algorithms
| Key spec | Usages | When |
|---|---|---|
| ECC_NIST_P256 | SIGN_VERIFY | The default choice for signing. Small signatures, fast, universally accepted. |
| ECC_NIST_P384 | SIGN_VERIFY | Where a policy or a device profile names P-384 specifically. |
| ECC_NIST_P521 | SIGN_VERIFY | Rare outside long-horizon roots. |
| RSA_2048 | SIGN_VERIFY, ENCRYPT_DECRYPT | Compatibility with verifiers that predate elliptic curve support. |
| RSA_3072 | SIGN_VERIFY, ENCRYPT_DECRYPT | The middle RSA rung, common in certificate hierarchies. |
| RSA_4096 | SIGN_VERIFY, ENCRYPT_DECRYPT | Long-lived roots where the verifier fleet cannot be changed later. |
| SYMMETRIC_DEFAULT | ENCRYPT_DECRYPT | Envelope encryption: wrap a data key, encrypt bulk data locally. |
Signing algorithms are named per request, not per key, so one RSA key can produce both PKCS#1 v1.5 and PSS signatures at SHA-256, SHA-384 or SHA-512, and an ECC key signs at the digest length matching its curve. The request also carries a message type: DIGEST when you have hashed the payload yourself, RAW when you are sending bytes to be hashed here.
What you can do with a key
- Sign and verify. Signing is synchronous for anything that fits in a request. For larger artifacts, request an upload URL for the key, upload the artifact directly, and the signature is produced against what you uploaded.
- Encrypt and decrypt. Direct operations for small payloads.
- Generate a data key. Returns an AES-128 or AES-256 data key in both plaintext and wrapped form, so you encrypt bulk data locally and store only the wrapped copy. This is how you protect anything larger than a request body.
- Re-encrypt. Moves ciphertext from one key to another without exposing the plaintext at any point.
- Produce a CSR. A signing key can emit a certificate signing request carrying a subject you supply, which is the bridge between a key here and a certificate anywhere.
Partitions
A partition is a named compartment that keys live in: by environment, by product line, by customer. Every key is in exactly one, and a key you create without naming one lands in default.
Choose the partition at creation, like the usage
A key can be moved out of default into a named partition exactly once. After that it does not move again: there is no transfer between named partitions, and nothing moves a key back into default. A second attempt is refused outright.
So create the key into the partition you want it in. Treat the partition as a decision with the same permanence as the usage, not as a label you can rearrange later.
Partitions and permission tiers answer two different questions, and the difference matters enough to state directly. A permission tier answers what kind of thing may this person do: sign, read, create, administer. A partition answers which keys are we talking about. One is a verb, the other is a set.
So a tier is what stops a build agent from deleting keys, and a partition is what stops it from touching your production signing keys at all. The tier is granted to the person, the partition is a property of the key, and membership in that partition is granted to the person separately. A release engineer holding a signing tier but not the production partition can sign, just not with anything that matters.
Both are enforced, and they are enforced together. A caller may only create a key into a partition they belong to, may only list keys in partitions they belong to, and may only run an operation against a key whose partition they hold. Re-encryption checks both keys, so ciphertext cannot be moved into a compartment the caller cannot reach.
It fails closed. No memberships means no keys, not all keys. default is a real partition rather than an unguarded pool, so a key that was never moved out of it still requires that membership. Administrators get no bypass: an administrator who needs a partition grants it to themselves, and the grant is audited.
What a partition is not is the tenant boundary. It divides your own people and credentials inside one account. The boundary between you and any other customer is the account itself, which is one tenant wide. The full tier and scope tables are in Users and permissions.
Regions and placement
Keys are multi-region capable, and four distinct things live under that heading. Each does a different job, each is billed separately, and they compose rather than substitute, so it is worth naming the one you mean and knowing what it adds to the invoice:
- A served region is a region where the service runs and your callers can reach it. It exists whether or not any particular key is in it. This is a latency and data residency decision, and it is the most expensive of the four at $75 per month, because it stands up a live stack rather than adding a record.
- Placement puts a specific key into a served region, in addition to where it already is. The key gains a presence, it does not move. Serving a region does not place your keys into it: you choose which keys go where, key by key, and each placed key is $12 per month on top of the served-region fee. Ten keys placed into one further region is ten charges, not one.
- Relocation changes a key's home region. This is a move, not an addition, and afterwards the key is where you moved it and not where it was. It carries no per-key charge of its own, but the destination has to be a served region, so the $75 per month for that region applies if you are not serving it already.
- Failover pairing is the only one of the four that is about disaster recovery. You nominate a source region and the region that protects it, and the pair carries its own status, moving from pending to active. Pairing is a standby posture rather than a serving one, at $49 per month for each protected region. It does not stand on its own: failing over to a region only helps if that region is already served and the key is already placed there, so a protected pair costs the failover fee plus the served region beneath it plus every key you placed into it. Pairing a region you do not serve buys nothing.
A placed copy is a replica of the same key identity rather than a second key, so a signature produced in one region verifies against the same public key everywhere. You can list the regions available to you and remove a placement you no longer want.
One caveat to carry into the decision. Relocation moves the key rather than copying it, so a caller pinned to a regional endpoint the key has left will fail there rather than transparently reach it elsewhere. Check what is pinned before you relocate. What each of the four costs is set out in Limits.
Rotation posture
Asymmetric signing keys are not rotated underneath you, and that is deliberate. A rotated signing key is a new public key, and every verifier in the field, every device that pinned it and every certificate that chains to it would have to be told. Rotation on that class of key is a migration you plan, not a background job we run.
The rotation you actually want is usually at the certificate layer, not the key layer: issue a new certificate, distribute it, then retire the old one. Symmetric key material used for envelope encryption rotates at the data key, which is generated per payload by design.
Symmetric keys also have annual rotation of the backing key material switched on. That rotation is transparent: data encrypted under earlier material stays decryptable, no verifier or caller sees a change, and there is nothing for you to schedule around it.
Deletion
Deleting a key schedules it rather than destroying it immediately. The pending window is thirty days, during which the key performs no operations but can still be recovered. When the window closes the key material is destroyed and nothing recovers it, here or anywhere.
Two consequences worth planning around. Anything encrypted under that key becomes permanently unreadable at the end of the window, so re-encrypt to a surviving key before you schedule the deletion, not after. And a certificate authority key that is deleted cannot sign a revocation list again, which is a different kind of loss: see Certificate authority.
Cancelling your subscription does not silently delete anything. What happens to your keys when you leave is set out in Escrow and Keyout.