Choosing your recovery posture: strict break-glass-only or an added operational key
Every backup downpipes seals is encrypted to your break-glass key, which is generated in your browser and never leaves it. The break-glass private key is the universal way back into your data, and the vendor never holds it. Your engine, running inside your own Cloudflare account, never holds it either.
What your engine does or does not hold is the one remaining choice, and it is the recovery posture. The default is strict break-glass-only: the engine holds nothing that can decrypt any archive. You can instead add an operational key, whose private half lives in the engine, so the engine can read its own backups back and test that they restore without you present. This page sets out what each posture gives you, what each one costs, and why the default is the safer place to start.
The two postures at a glance
Both postures protect your data with the same break-glass key, so both are equally recoverable offline. They differ only in whether the engine also holds a key that can read your archives in place.
| Default: strict break-glass-only | Optional: add an operational key | |
|---|---|---|
| What the engine holds | The signer key and the break-glass public key only | The signer key, the break-glass public key, and an operational key (public and private) |
| Can the engine decrypt your archives? | No: in this strict posture it holds no key that can decrypt anything | Yes, through the operational private key |
| In-account read-back with no person present (the automated drill, scheduled restore tests, retention pruning) | Not available; the drill returns ok:false naming the absent key |
Available |
| In-account read-back that needs no standing key (verification at seal, the hourly canary) | Available, at the same keyed tier as the other posture | Available |
| In-console restore | Available with you present, supplying your key in the browser | Available |
| If your own Cloudflare account is fully compromised | Nothing the engine holds can read any archive | The operational private key can read past archives |
Recovery with your offline identity.key |
Recovers every archive | Recovers every archive |
| Changing your mind | You can add an operational key later from the Keys screen, with no re-key and no effect on archives already sealed | Removing it later does not protect archives already sealed while it was present, because each archive is wrapped to the keys in force when it was written |
Strict break-glass-only
In the strict break-glass-only posture the engine holds the signer private key and the break-glass public key, and nothing else that bears on confidentiality. It can still seal and sign new backups, because sealing wraps an archive to a public key and signing uses the signer key. It cannot read any archive back, because it holds no private key that decrypts one.
This is the posture to choose when the threat you most care about is a compromise of your own Cloudflare account. With no operational private key present, a full account compromise yields no key that opens an archive. The attacker still gets the cleartext run metadata and the ciphertext from your destination, the same as an attacker with only the bucket bytes, but they cannot read your values, names or secrets.
The cost is narrower than it sounds, and it is worth being exact about, because this is the posture most teams talk themselves out of.
What still runs in-account, automatically, with no key present: verification at seal and the hourly canary. The seal path holds the run’s own per-run key while it is finalising that run, so a break-glass-only engine reaches the same keyed verification tier as an operational one, and the canary runs with no skipped checks. Your backups are not unverified in this posture.
What still works, with you present: the in-console restore. The engine cannot open a run on its own, so the console’s break-glass panel takes your break-glass private key in the browser, derives the run’s key there, and wipes it when the restore finishes. The key is never sent to the engine. There is no terminal step.
What you actually give up is the UNATTENDED work, the operations that need a key at a moment when nobody is there to supply one: scheduled restore tests, the automated drill, and in-account retention pruning. A drill in this posture is honest about it rather than failing quietly: runDrill returns ok:false with a reason naming the absent in-account read-back key. The scheduled retention pass defers the same way rather than pruning silently; the console’s break-glass prune panel runs the SAME prune on demand instead, with you present to supply your break-glass key in the browser, or you can run it offline with downpipe prune.
Tightening is the reversible direction
Tightening to break-glass-only is performed in the console with no terminal: an owner pastes a one-shot scoped token, and the engine removes both operational secrets itself through the Cloudflare API. The route POST /admin/keys/break-glass-only calls removeOperationalSecrets, which deletes OPERATIONAL_PRIVATE and OPERATIONAL_PUBLIC. After that the engine holds no operational key.
Tightening does not lock you in. An engine that holds a signer and a break-glass key but no operational private key is offered a targeted add on the Keys screen, which installs only a fresh operational pair over POST /admin/keys/add-operational. That route never reads or writes SIGNER_PRIVATE or BREAK_GLASS_PUBLIC, so returning to two-recipient is not a re-key: your identity.key, your break-glass key, your signer and your recovery sheet all stay the ones you already have, and every run stays signed by the same signer. The targeted add refuses when an operational key is already present, because replacing one is the full ceremony’s job rather than this route’s.
The direction that cannot be taken back is adding the key, not removing it
Removing the operational key is reversible with the targeted add above. Adding one is the direction that does not fully undo. The recipient set is baked into each archive when it is sealed and is never rewrapped afterwards, so every run written while an operational key was present carries a wrapped key for that operational recipient permanently. Deleting the key later stops the engine reading those archives, but it cannot retract the exposure of a key that was live in your account while they were written. Archives sealed before the add stay break-glass-only recoverable, forever.
It is data-loss-safe
Removing the operational key does not risk your data in the ordinary case: no break-glass rotation behind you, one continuous break-glass identity. Each run is wrapped to the break-glass recipient as well as the operational one, so the offline identity.key recovers everything, including archives that were sealed while the operational key was present. Deleting the operational secrets then removes the engine’s ability to self-test-restore and nothing more.
That guarantee narrows if you have since rotated your break-glass key. An archive sealed to an older break-glass vintage, while the operational key was also present, is opened by either key today; after the switch it is openable only by the old identity.key you kept at rotation time (see rotating your keys). The engine does not let this happen silently. Before the switch it checks your run history and refuses with a 409 when removing the operational key would strand such an archive, or when it cannot rule that out; the console then states exactly how many archives are affected and offers the one sanctioned way forward, a second, explicit confirmation that you hold the identity.key for every older vintage. It never blocks the ordinary case: with every archive still wrapped to your current break-glass key, nothing is sole-access-openable by the operational key you are removing.
An owner starts the switch on the Keys screen
The strict break-glass-only control is owner-gated. Anyone without the owner role sees the reason rather than the control, and the change is rate-limited so it cannot be hammered.
You confirm the irreversible action
The switch is confirm-to-act: it never fires on a stray click. A confirmation states that the engine will no longer read or test-restore your archives, and that recovery is unaffected because your offline key still opens every archive. Because the route is step-up gated, a cookie-borne session is also asked for a fresh passkey assertion before the removal runs.
The engine removes both operational secrets
Using your one-shot token, the engine deletes
OPERATIONAL_PRIVATEandOPERATIONAL_PUBLIC. The token is used once for this call and is never stored or logged. Revoke it on the Cloudflare API Tokens page afterwards.The console confirms the new posture
The console polls the engine’s status until it reports the operational private key gone, then states that the engine is now break-glass-only and holds no key that can read your archives. The change is recorded in the audit log by name only.
Adding an operational key
There are two ways in, and which one the console offers you is decided by the state of your engine rather than by a menu.
At the first key ceremony, asking for an operational key generates one and installs both halves into the engine alongside the signer private key and the break-glass public key. The console states this plainly during onboarding: the operational private key can decrypt your archives and lives in your engine, which is what makes unattended restore proof possible.
On an engine that already holds a signer and a break-glass key but no operational private key, the Keys screen offers the targeted add instead, over POST /admin/keys/add-operational. It generates and installs only the operational pair, leaves the signer and the break-glass recipient untouched, and needs no new identity.key. Archives sealed before it stay break-glass-only recoverable; only runs sealed afterwards gain the operational recipient. Scheduled restore tests, drills and in-account retention pruning resume on their next run with no further action.
That self-test ability is the reason to add this key. With the operational private key present, the engine can open a run, recompute its integrity chain and restore a sample of records on its own. That is how scheduled restore tests, the in-console restore and the recovery drill work. A drill returns the records it verified, whether the run is the latest for its downpipe, and an honest measurement of how long the read-back took, so a clean drill means the backup is genuinely recoverable rather than merely written.
Presence is not validity
The Keys screen reports each key as present when its binding is set, never that the value parses or that a restore will succeed. The drill is what proves recoverability; presence only tells you the engine has a key by that name.
The residual you are accepting
The cost of adding an operational key is a real residual, and it is your own account, not the vendor. The operational private key is decryption-capable and it sits in the live engine. An attacker who fully compromises your Cloudflare account seizes that key, and with your destination bytes they can read past archives through the operational path. The break-glass private key stays out of their reach because it is offline, so they still cannot recover through break-glass, but the operational path is open to them.
This is the residual the threat model names for adversary two, a full Cloudflare account compromise. It is disclosed at the decision point in onboarding, on the Keys screen, and here, so that adding the key is an informed choice and never an accident.
How to decide
Pick the posture that matches the threat you are most worried about, and accept the cost that comes with it.
Stay break-glass-only
The default, and the right choice when the threat you most care about is compromise of your own account. A full account compromise then yields nothing readable. You accept that the engine cannot self-test-restore, so recovery and proof are exercised with your break-glass key, in the browser or at an attended verification.
Add an operational key
Choose this when you value automated, in-account restore drills and want the engine to prove your backups recoverable on its own. You accept the disclosed residual: a full compromise of your own Cloudflare account could read past archives through the operational key.
Break-glass rotation is a separate decision
Rotating the break-glass key writes a new BREAK_GLASS_PUBLIC and changes nothing else. It is not a re-key and it is not the posture switch. Archives sealed before a rotation can only be opened by the old identity.key, so keep it. New archives are sealed to the new key from the next run.
The exact controls, gates and what is recorded
The strict break-glass-only switch and break-glass rotation are both owner-exclusive and rate-limited, and both run through a one-shot scoped Cloudflare token that the engine uses for a single call and never stores or logs.
The audit entry for the switch records the action by name (operational-removed) and the operator’s own identity, with no key values. The audit log always carries operator identity, so the entry is durable evidence of who changed the posture and when. A later targeted add records its own entry by name (operational-added), so the trail carries both directions.
removeOperationalSecrets deletes the operational secrets idempotently: a secret that is already gone is treated as a success, so a repeated switch is safe. The deletion takes effect on the running engine without a redeploy. The signer private key and the break-glass public key are untouched by the switch, so the engine stays able to seal and sign new backups in either posture.
A drill in the break-glass-only posture returns ok:false rather than throwing, with a plain reason: there is no in-account read-back key. That is honest reporting of a posture you chose, not a failure. Read the rest of that message with one correction in mind. It tells you to exercise recovery offline with the break-glass key and the reader, and offline is no longer the only way: the console’s in-platform break-glass restore takes your key in the browser, never uploads it, and drives the restore from there. The offline reader remains the channel that needs neither the vendor nor Cloudflare, so it is still the one to rehearse.
Recording that you accepted the posture
Separately from choosing a posture, you can put on the record that you accepted the one you are in. The Keys screen shows the acceptance statement in force, a tick box reading “I have read the statement above and understand my choice”, and a Record this acknowledgement button that stays disabled until the box is ticked.
The posture on that screen is not a picker. It is whatever your engine reports: operational key present, or offline key only. That is deliberate, because a picker would let someone record an acceptance of a posture their engine is not actually in.
Confirming records four things in your tamper-evident audit log, under your signed-in identity: the posture, the version of the statement, a SHA-384 hash of the exact words you were shown, and whether it came from the Keys screen or from guided setup. It changes nothing about your keys, and the statement text itself is never logged.
Two refusals are worth knowing about, because both are honest rather than errors:
- If the words your console displayed do not match the engine’s canonical text for that statement version, the engine refuses instead of recording. The point of the record is that what was shown is what was hashed, so a mismatch has to fail rather than quietly record different words.
- If the statement version is unknown or stale, the engine refuses and asks you to reload. In practice that means your console and engine are on different versions, so the fix is to update them rather than to retry.
Both surface in the console as a single sentence naming the version-skew cause.
Related reading
For why the vendor never holds your data or your keys, and what each adversary can and cannot do against the platform, read the no-custody trust model. For how the keys are generated in your browser and what goes on your recovery sheet, read the key ceremony and recovery kit.
When you need to exercise recovery in the break-glass-only posture, break-glass offline recovery covers the MIT-licensed reader, your identity.key, and the steps to recover with neither the vendor nor Cloudflare in the loop.
Last updated .