Choosing your key custody: one key file, or a split key

Your break-glass key, identity.key, is generated in your browser during the key ceremony and is the one universal way back into your data. Nobody else holds it: not Cloudflare, and not Maelstrom. So the only real question about it is a custody question, how you keep that single file safe and recoverable over years. This page sets out the two shapes custody can take, keeping it as one file or splitting it across several custodians, and helps you pick between them. It is the sibling of choosing your key posture: posture is about what your engine holds, custody is about how you hold the offline key, and the two decisions do not constrain each other.

Both shapes recover the same data with the same key, so this is not a choice about whether you can recover. It is a choice about how many people and places must fail before recovery becomes impossible, weighed against the effort of running more custodians. Whichever you choose, the mechanics run entirely in your browser: the encryption and the split run on your machine, and the encrypted key file never leaves it. Each share is yours to download and hand over, or, if you prefer, to have your own engine email to a custodian; either way Maelstrom receives nothing. For where the key comes from and what else lands in your recovery kit, see the key ceremony and recovery kit.

One key or a split key

Keeping one key file is the simplest custody, and it fits most teams. You take the downloaded identity.key and store it well, in a corporate password manager or on a hardware-encrypted drive with a printed companion, optionally encrypting it first for defence in depth. There is one file to protect, and anyone who can open its store holds the key.

A split spreads custody across several holders instead. No single custodian can recover alone, and no single lost share ends recovery. The cost is ceremony and coordination: you decide how many shares exist and how many are needed, hand one to each custodian, and record who holds what. The table weighs the two side by side.

Both options leave you holding the same identity.key at the end of recovery, so you can start with one file and move to a split later by re-running the custody step in the console. A split earns its ceremony when no single person and no single vault should be able to end, or to perform, a recovery on their own.

How the split works

A break-glass identity is about 3.2 KB of post-quantum hybrid key material, an X25519 secret alongside an ML-KEM-1024 seed, which is the wrong size and shape to split directly, because Shamir tooling targets short secrets. So the console splits a stand-in. In your browser it generates a fresh random 256-bit key, encrypts identity.key under it with AES-256-GCM, and splits only that 32-byte key.

The step produces separate downloads: the encrypted key file (identity.key.enc), one share file per custodian (downpipe-share-1-of-N.txt and so on), and a plain-text recovery readme (RECOVER-SPLIT.txt) that records the scheme and the offline recovery procedure. The encrypted key file is small, so you store it the way you would a one-key file, in a vault or on an encrypted drive, and the shares go to your custodians. On its own the encrypted file carries no usable key, and one share on its own carries nothing either. Each share file also carries a short public checksum of the wrapping key: it is one-way and reveals nothing usable about the key, and its only job is to let recovery catch a wrong or mistyped share early, before the decryption step.

Choosing the threshold

A split has two numbers: N, how many shares exist, and M, the threshold, how many are needed to reconstruct. Any M shares rebuild the key. Up to N minus M shares can be lost, or held by custodians who are unavailable, and recovery still succeeds. Any M minus 1 shares together reveal nothing at all about the key, which is a property of the mathematics rather than a policy, covered in the next section.

The split accepts a threshold of at least 2 (a threshold of 1 would make any single share the whole key) and at most N, with N as large as 255, so the full bound is 2 <= M <= N <= 255. The console caps N at 16 in its picker, because more than a handful of custodians is an operational choice rather than a cryptographic limit; the underlying split allows the rest.

Pick M and N by the failure you most want to prevent. A higher threshold resists collusion, since more custodians must combine to rebuild the key, but it is more fragile to loss. A lower threshold survives more lost or absent shares, but a smaller group can reconstruct. The examples show the two sides of that trade.

What a single share reveals

Below the threshold, a share reveals nothing, and that word is exact. Each byte of the wrapping key is the constant term of a separate polynomial of degree M minus 1 whose other coefficients are drawn from fresh random bytes. With only M minus 1 shares in hand, every possible key stays equally consistent with what you hold, so no amount of computation extracts the key or narrows it. This is why distinct custodians are the whole point: the security comes from the shares being held apart, not from any share being hard to read. A share file is small, a single non-zero index byte and 32 payload bytes, wrapped with public labels (its index, the N and M parameters, and the checksum); only the payload is secret.

Two facts about that deserve to be stated plainly. A custodian who holds a share holds it wherever they keep it, so a share stored carelessly is exposed there, which is why each share should live apart from the encrypted key file and from the other shares. And the threshold cuts both ways: any M minus 1 custodians learn nothing, but any M of them, working together, reconstruct the key in full. Choose your custodians and your threshold with that in mind, so that no group you would not trust with a recovery can reach M, and no loss you think likely can drop you below it.

Distributing and recovering

The console produces each share as a separate, clearly labelled download. The most private route, and the recommended default, is to download each share and hand it to its custodian yourself, keeping every share apart from the encrypted key file. If a custodian is remote, you can instead have your own engine email a share to them; that stays no-custody because the encrypted key file is never sent, only the one share, and it needs your outbound email to be set up first, described in sending shares by email below. Store the small encrypted key file the way you would a one-key file, and keep the recovery readme beside it; in the cold-storage tier the console can also render the encrypted key file as a printed or QR companion, so it survives on paper.

Recovery reverses the split. You gather a quorum of M custodians, rebuild the wrapping key from their shares, decrypt the encrypted key file back to identity.key, and then recover exactly as a single-file break-glass key would, with neither Cloudflare nor Maelstrom in the loop. The reassembly runs in your browser at /restore/recover-key, and the same reassembly step is built into the in-console break-glass restore panel, so a split key can drive a restore directly without ever producing a file on disk. The path a recovered key follows from there is break-glass offline recovery.

1. Gather a quorum of custodians

   Bring together any M of the N custodians and their share files. Fewer than M cannot rebuild the key, and by design reveal nothing about it.

2. Reconstruct and decrypt in the console

   Open /restore/recover-key, add the quorum of shares and the encrypted key file, and the console rebuilds the wrapping key and decrypts identity.key.enc back to identity.key in your browser. Because the encryption is authenticated, a wrong or mistyped share fails the decryption rather than returning a corrupt file, so the step is self-checking. Off-console, a compatible Shamir-over-GF(256) tool plus an AES-256-GCM decrypt does the same thing, following RECOVER-SPLIT.txt.

3. Recover, in the console or with the offline reader

   Either hand the recovered identity.key to the offline reader and recover as an ordinary break-glass recovery, or stay in the console and use the in-console break-glass restore panel, which reassembles the same shares and passes only the per-run key for the run being recovered to your own engine. Neither route sends your shares or the wrapping key anywhere.

Sending shares by email

Downloading a share and handing it over keeps it off every network, so it stays the most private way to distribute, and the recommended default. When a custodian is remote, the console can email a share to them instead. A browser cannot send email, so the share is sent by your own engine, over your own outbound email on your own domain; Maelstrom is never in the path and receives nothing. This option appears only once your engine’s outbound email is configured, the same sending domain your licence and notification emails use, so set that up first if the Email action reports it is not ready.

Be clear-eyed about what emailing a share changes. The share travels through your engine and your email provider to the custodian’s inbox, where it rests until they move it, so it is exposed along that path in a way a hand-carried download is not. What does not change is the thing that makes the split safe: the encrypted key file is never emailed, so anyone who intercepts an emailed share, or even every emailed share, still cannot decrypt identity.key without that file. Keep the encrypted key file well away from your engine and your inboxes, and give each share to a different custodian. Reserve email for the shares whose exposure you can accept.

Each share is emailed as text in the body of the message, with no attachment. The email names the M-of-N scheme so the custodian understands a single share reveals nothing on its own, and it asks them to save the share offline or in a password manager such as Bitwarden and then delete the email so it does not linger. You address each share to one custodian: a real address on a custom domain (a workers.dev address is refused, as is a malformed one), plus an optional custodian name that rides only in the email itself. The engine sends one share per request and records only the scheme counts in its audit log; it never logs or stores the share value or the address.

Because the share passes through your engine on its way out, treat a successful send as sent, not as proven recoverable: rehearse a reconstruction from a quorum before you depend on the scheme, the same rehearsal a download-distributed split deserves.

Where this fits

Custody is one of two independent choices about your break-glass key. This page is about how you hold the offline key; choosing your key posture is about what your engine holds alongside it. For where the key and the recovery sheet come from, see the key ceremony and recovery kit. For why no split ever puts the key in Maelstrom’s hands, see the no-custody trust model. For the offline recovery that both a single-file key and a reconstructed key feed into, see break-glass offline recovery.

Last updated 11 July 2026.