Restore into a different Cloudflare account
Most restores put data back where it came from. Two kinds do not necessarily: a Cloudflare config restore and a media restore both write through the Cloudflare API to an account id you supply, rather than to a binding that is already fixed to one account.
That makes a specific mistake possible. Supply the wrong account id, or an id that has drifted since you saved it, and the write lands in the wrong Cloudflare account. It would succeed, because nothing about the request is malformed; it would simply have written your configuration somewhere it does not belong. This is a confused-deputy problem, and the engine guards it.
How the engine knows where the archive came from
Each archive records the account it was captured from, and that origin is signed. It is stamped at seal time by the source adapter itself and pinned by the archive root’s per-shard hash, so a request cannot claim a different origin: the value is not something the caller supplies alongside the target.
That is what makes the comparison meaningful. The engine is not checking your target against another thing you told it; it is checking your target against what the archive itself attests.
What you see, and when
The check runs on the dry run, before anything is written. If the target account you supplied is not provably the archive’s origin, the plan comes back carrying a cross-account warning for each affected leg, naming the leg, the archive’s origin account and the target you gave.
The apply is then refused until you confirm the difference by typing the target account id back. Not a checkbox: you have to reproduce the id, so confirming is an act of reading it. Get the id wrong in the confirmation and the apply stays refused. Where a plan carries both legs and they target two different foreign accounts, the console asks for every distinct target account id, separated by commas, so typing one of them can never arm the other.
On an ordinary same-account restore none of this appears. There is no warning to dismiss and nothing extra to type, so the friction lands only where the risk is.
An archive with no recorded origin is treated as cross-account
If the archive recorded no origin account, the engine does not treat that as “probably fine”. An unverifiable origin is treated as cross-account, so it raises the warning and requires the same typed confirmation.
That is the important asymmetry. The guard cannot be defeated by an archive that simply lacks the information. That gap is exactly where a silent write to an unverified account would otherwise be possible.
When you actually want this
Restoring into a different account is a legitimate operation, and the guard is not trying to stop you. It is worth doing deliberately for a recovery into a rebuilt account after losing the original, a migration between accounts, or standing an isolated copy up for a rehearsal so a drill never touches production.
In each of those the difference is the point, and the typed confirmation is cheap. What the guard prevents is the fourth case: the one where you believed you were restoring into the origin account and were not.
A same-account, different-zone restore is a separate, similarly guarded mistake
If your account has more than one zone, a Cloudflare config restore targets a zone id the same way it targets an account id, and the engine runs a parallel check: it compares your target zone against the archive’s own recorded origin zone, and an apply that would land in a provably different zone is refused until you type the target zone id back to confirm. It only ever fires when the plan would write at least one zone-scoped surface, since an account-scoped surface ignores the zone id entirely and cannot be misplaced by it.
The one place the zone guard is deliberately weaker than the account guard is the unverifiable case. Where an unrecorded origin account is treated as cross-account and refuses, an origin zone that cannot be read only warns on the dry run: it does not refuse the apply. So read a zone warning with no origin named as something to check yourself rather than something the engine has held for you. The account guard and the zone guard are independent; passing one says nothing about the other.
Where this fits
- What restore can and cannot write back covers which legs write through the Cloudflare API at all, which is what makes them account-targeted.
- The restore flow covers the dry run this check runs inside.
- Dual control for restores is a separate gate: it binds an approval to the plan hash, and where your estate requires a second approver, a cross-account plan needs both the approval and the typed confirmation.
- Granular and targeted restores covers narrowing what a plan touches, which is worth doing before a cross-account apply rather than after.
Last updated .