Choosing your key posture: an operational key, or an offline key only
Both key postures protect your backups with the same offline break-glass key, the one generated in your browser and kept only by you. Whichever posture you pick, every archive is sealed to that key, so both postures are equally recoverable offline with the reader and your identity.key. The choice is not about how recoverable your data is. It is about one thing only: whether your engine also holds a key that can read your archives back on its own.
That makes this a positive choice rather than a warning. An operational key buys your engine the ability to prove your backups restorable with nobody present. An offline key only keeps your engine holding nothing that can open an archive at rest. This page sets out what each posture lets your engine do, what a malicious platform update or a compromise of your own Cloudflare account could reach under each, the controls you can add on your side, and the exact statement you confirm. The mechanics of the switch between them, and why tightening is one-way and never risks your data, live in recovery postures.
The two postures
The operational key posture is what recovery postures calls the two-recipient posture. Your engine also holds a decryption-capable operational key, so it can reopen and restore-test runs it sealed earlier without a person present: scheduled restore tests, in-console restore, recovery drills and retention pruning all run on their own. Verification at seal time and the hourly canary are not on that list, because they no longer need this key; both run in either posture. The factual point that matters here, and one a reviewer corrected, is where that key lives. It is stored as a secret in your own engine, in your own Cloudflare account: a per-worker Worker secret on the engine you deployed. It is not a Cloudflare Secrets Store binding, which the engine refuses at config time. So the operational key sits inside the account you already control, and it is the engine’s own key on the engine’s own account.
The offline-key-only posture is the strict break-glass-only posture in that same page. Your engine holds no key that can decrypt your stored archives at rest, so the automated proofs above are off. You prove restorability yourself, at an attended verification: you supply your break-glass key at the time, your engine runs the check while you are present, and the key is gone when the session ends. Sealing and signing still work in this posture, because sealing needs only a public key; what your engine gives up is the ability to read an archive back by itself.
Pros and cons
The two postures differ on one axis: what your engine can do for you, set against what it holds that could be turned against you. The table weighs both.
| Consideration | Operational key | Offline key only |
|---|---|---|
| Automated proof of restorability | On: scheduled restore tests and in-console restore run with nobody present | Off: you prove restorability at an attended verification with your break-glass key. Restoring from the console still works, with you present and supplying your key in the browser |
| Retention pruning | Runs in your engine on the cadence you set | Runs on demand instead of on a schedule: from the console’s break-glass prune panel, or offline with downpipe prune, supplying your break-glass key or a quorum of shares at the time |
| Blast radius if a malicious platform update runs in your engine | It can read the operational key and decrypt your stored archive corpus at rest | It gets your stored ciphertext only, though it still reads source data in flight during the window |
| Blast radius if your own Cloudflare account is compromised | The operational key is in the account, so past archives can be read with the destination bytes | No key in the account opens an archive; the attacker holds ciphertext and metadata |
| Operational effort | Lower: the proofs run on a schedule | Higher: you run attended verification on your own cadence |
| Compliance evidence | Continuous restore-test recency and RTO samples the engine generates | Attended-verification records you produce on your cadence, each with its sample rate |
| Recovery-path dependencies | Your offline break-glass key recovers everything; the operational key is a convenience, never a recovery dependency | Your offline break-glass key recovers everything and is the only key that reads an archive |
What a malicious update could do
Start with what is and is not true about catching a bad release. A malicious release that carries a valid signature passes signature verification, and you do not rebuild the engine from source, so you could not tell by inspection that a signed release was hostile. Detection is not the protection here. Control is.
Nothing installs on its own. The channel alerts you that a version is available, but it never applies one; a human applies each update, pasting a fresh one-shot Cloudflare token that is collected at apply time and never stored. Because the engine keeps no standing deploy credential, an unattended auto-install is not merely disabled but architecturally impossible: there is no credential sitting in the engine for a hostile channel to ride. You can read the change notes and defer. And if you do apply a bad version, the apply is canary-gated and rolls itself back to the version you were on.
What the posture changes is the blast radius of an update that does run. In the operational key posture, a malicious update can read the operational key and decrypt your stored archive corpus at rest: it steals the ciphertext and can open it. In the offline-key-only posture your engine holds no key that decrypts archives at rest, so the same update gets your stored ciphertext and nothing that opens it, which is theft without decryption.
There is a caveat the offline posture does not remove, and it belongs in the open. Any backup engine reads your source data at backup time, when it seals a run, in either posture. So a malicious update that is resident during a backup can read that source data as it passes through, whichever posture you are in. The offline-key-only posture protects your archive corpus at rest, not the source data in flight during the compromise window. Read the claim precisely: it is your stored archives at rest that nothing in the account can decrypt, not everything the engine ever touches.
What the offline posture protects, precisely
The offline-key-only posture protects your stored archives at rest, so nothing in your engine can decrypt them. It does not protect the source data the engine reads while a backup runs, which any in-account writer necessarily sees. Apply only updates you trust, and add the controls in what you can add on your side.
Maelstrom’s job is to make a malicious release less likely to reach you at the channel and artefact layers. Each release is signed with a pinned hybrid key, an Ed25519 signature alongside an ML-DSA-87 signature with both halves required, and before your engine deploys anything it byte-verifies the artefact’s SHA-384 against the signed value in your own account. The release signing key is held offline and is never deployed, so reaching the running engine does not reach the signer. An offline signer lowers both the likelihood and the blast radius of channel and artefact tampering. It cannot tell you that the signer itself has been compromised, so treat it as a reduction in exposure rather than a detector of a signer breach.
What you can add on your side
None of these controls stop a malicious engine update, and it would be dishonest to imply they do. Each addresses a different residual, so the table labels them by what they actually cover.
| Control | The residual it addresses | What it does not do |
|---|---|---|
| Cloudflare Access and passkeys | A stolen console session or account access: they guard the console front door | Stop a malicious engine update, which runs in the engine behind that gate |
| Dual control on installs and updates | A single compromised operator driving an install or an update | Stop a validly signed but poisoned release, which each approver would pass in good faith |
| Streaming your audit log to your SIEM | Loss or quiet edit of the on-engine record: you keep an off-engine copy | Prevent the change; it gives you an independent record that it happened |
| Reviewing an update before you apply it | When, and whether, a release goes live: your timing control | Separate a good signed release from a malicious one by inspection |
Cloudflare Access is a Cloudflare product you run in front of your own console, and passkeys ride the same front door. The risk axis on this page is always your own Cloudflare account, never Cloudflare itself. For the second-approver controls in the table, see change control; for the front door, see prerequisites.
The acceptance you are recording
When you choose your posture in the console, or change it later, you confirm a short statement, so the record shows the choice was deliberate. This page carries both statements in full, so it is the disclosure each confirmation points back to.
For the operational key posture:
I am enabling an operational key. It is stored as a secret in my own engine, in my own Cloudflare account, and it can decrypt my stored archives. I understand that if my Cloudflare account is compromised, or a malicious platform update runs in my engine, my stored archives could be read. I understand that removing this key 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. I am accepting this so my engine can reopen and restore-test runs it sealed earlier without me present.
For the offline-key-only posture:
I am choosing an offline key only. My engine will hold no key that can decrypt my stored archives. It will still verify each run as it seals it, and prove its own test data recoverable every hour, but it cannot reopen a run it sealed earlier without me. Scheduled restore tests and retention pruning therefore do not run in my engine, and I am responsible for pruning my own archives with the offline reader, supplying my break-glass key at the time. Restoring from the console still works with me present, supplying my break-glass key in my browser, and I am also responsible for proving past runs restorable at an attended verification. If I lose that key my backups cannot be recovered.
The confirmation is written to your tamper-evident audit log by the posture you chose, the version of the statement, a hash of its exact wording, and the operator who confirmed it with the time. The log records the hash rather than the free-form text, so the choice is durably provable without copying the words back into it.
Where this fits
The mechanics of the two postures, and why tightening to break-glass-only is a one-way, data-loss-safe switch, are in recovery postures. The custody position each posture rests on is the no-custody trust model, and the adversary-by-adversary view, including a compromise of your own Cloudflare account, is the threat model.
For how an update is verified before it deploys and rolled back when it misbehaves, see update trust and rollback. For proving a backup restorable, see prove recoverability, and for the attended path the offline-key-only posture relies on, see attended verification.
Last updated .