Attended verification: prove your backups restorable with your break-glass key, on your cadence

Attended verification is how you prove your backups restorable in the offline-key-only posture. That is the strict break-glass-only posture where your engine holds no key that can decrypt an archive on its own. Rather than the engine testing restores unattended, you supply your break-glass key at the moment of the check. Your engine runs the verification while you are present, then forgets the key when the session ends. It is recovery proof on your cadence, driven by the one key that can open an archive.

What it proves

Attended verification actually decrypts your archives. That is its point, and it is the difference from a keyless attestation: because it opens each in-scope archive with a real key, it catches an archive that is present but will not decrypt, or one whose bytes are corrupt, which a signature-and-completeness check alone cannot see. A passed session also confirms something about people, not only bytes: that someone holding your recovery key ran it just now.

The proof has a limit. Like every recoverability check in an engine you host yourself, the result is recorded by your own engine. So attended verification is a corruption-and-integrity check and a live assurance that your archives decrypt today. It is not a proof that survives a compromised engine, because an engine under an attacker’s control writes its own records. It is not an engine-independent attestation.

How your key is handled

If your organisation holds the break-glass key as M-of-N shares, supply the shares here instead of a key file. The screen takes a quorum of share files with the wrapped-identity file the console gave you at the ceremony, reassembles the key in your browser for that session, and wipes it. You do not have to run downpipe recombine first, which would write a complete break-glass key to somebody’s disk and leave it there. The resume banner on a reopened tab takes a quorum the same way, so an interrupted session does not force you to abandon it and start again.

Your break-glass private key, the identity.key you keep offline, is read in your browser and never sent anywhere. The session works archive by archive. For each in-scope archive, your browser unwraps only that one archive’s per-archive key locally, then hands that single-archive key to your own engine. Your engine holds it in memory for that one check, then overwrites it as soon as the check finishes, not at session end. Your engine never receives your private key.

A per-archive key is deliberately narrow. It is the per-run master for one run’s archive, so it opens exactly that archive and nothing else, not another archive and not any future backup, and it is far weaker than the break-glass key it was unwrapped from. So what your engine briefly holds is the ability to open the archives you put in scope, and only those.

That briefly-held access is the limit of this flow. While a session runs, the contents of the in-scope archives are exposed to your engine. The same per-run master drives the in-console break-glass restore, where your engine does not only read an in-scope archive but writes its recovered contents back into your resources, so a restore exposes those contents to write as well as read. Either way it stays bounded to what you put in scope: a compromised update resident in your engine during a session would see, and in a restore write back, exactly those archives and no more. Handing the engine only a per-run master and never your private is defence in depth, not a custody boundary, since your engine is your own and the vendor receives nothing regardless. The rule that follows is simple: run attended verification, or an in-console restore, only on an engine version you trust, and see choosing your key posture for the controls around updates.

Files the console accepts

Every key picker on this page takes a plain-text identity.key: one line reading downpipe-identity-v1 followed by your key, base64url-encoded. The picker’s accept filter is .key,text/plain.

Two checks run on the file before your key is trusted. Your browser refuses a file over 64 KiB before reading it at all, because a real identity.key is a few hundred bytes; a file that size is not a key, whatever it is. Once read, the file is refused unless it decodes to exactly the 96 bytes a break-glass key holds. Either refusal clears any key the screen was already holding, reports what was wrong, and never repeats a byte of the file back to you. The 64 KiB check also applies to a share file and to the encrypted identity.key.enc in the reassembly card below. Their accept filters are .txt,text/plain for a share file and .enc,.txt,text/plain for identity.key.enc.

Running a session

A session has two choices. The first is scope: the latest completed backup of every enabled downpipe, or a selection you pick. The second is sample percentage: verify a random percentage of the records in each archive, or verify all of them.

Only a full run, at one hundred percent, records a full recoverability proof. A sampled run is recorded as an attended verification of N percent of the records, and never as a full proof, so a lower sample never quietly reads as complete assurance.

A word on the practical shape of a large run. At one hundred percent a big estate can take a long while, and it runs as a queue rather than all at once. Keep the session open while it works: your browser is holding your break-glass key and deriving each archive’s key from it, so if you close the session the run resumes only once you supply your key again. The engine is never the holder here. It is handed a single run’s key, uses it for that one request and zeroes it, so the engine holds no key once the session ends. On a split key that means re-convening a quorum, which is a room full of people rather than a file on your desk, so it is worth knowing before you start a long run rather than halfway through one.

When a session starts, the screen shows how many runs it covers and about how many records. It gives no time estimate.

If your break-glass key is split

A split M-of-N key works here, and it does not need a reassembled key file on anybody’s disk first.

Beneath the key picker on the Start a verification card there is a collapsed Reassemble a split (M-of-N) key instead section. Load a quorum of your Shamir share files there, together with the small encrypted key file (identity.key.enc) the console gave you at the ceremony. The key is reconstructed in this browser tab and handed straight to the session. It is offered no download in this mode, so the reassembled break-glass key never becomes a file to look after afterwards. Change or remove a share after reconstructing and the derived key is treated as stale, and the session cannot be started until you reconstruct again.

The standalone Reassemble your split key screen at /restore/recover-key is the other way to do it. It is the one to use when you want the reconstructed identity.key as a file, for the offline reader or for a rehearsal. That screen holds no engine client, so it cannot reach the network even in principle, and it stops at reconstruct-and-download. Its output is then accepted in the key picker exactly as an unsplit break-glass key is. The M-of-N threshold is not weakened in either flow.

Either way the session needs your key for its whole length, not just to start it, because your browser derives a fresh key for every run rather than unlocking the estate once. Closing the page ends it, and resuming means re-convening the quorum. That is a room full of people rather than a file on your desk, which is why it is worth walking once before you need it.

Scheduling and reminders

You can state how often your organisation will prove its backups restorable: monthly, quarterly, every six months, or yearly. The interval is estate state, stored in your engine rather than in a browser, so it is the same wherever you sign in. It travels with your signed configuration export, and your compliance posture grades against it.

Two things are worth separating here, because it is easy to over-read either one. The interval is estate state and only an Owner can change it; setting it to “Not stated” records no rhythm, which is different from a zero-day one and simply means your posture does not grade this. The reminder toggle beside it is a preference in the browser you set it in and is off by default, so it decides whether the due nudge appears on the Restore screen and nothing more: it does not follow you to another machine, private browsing drops it, and clearing site data resets it.

When a downpipe with a completed run has no full attended verification inside the interval, the attended-verification-cadence check in your compliance posture reports it, at medium severity. It is deliberately not a critical finding and it blocks nothing: a lapsed proof rhythm is an assurance obligation, not a failure of your backups. Two states are reported apart rather than together, because they are not the same: a downpipe past the interval, and one never attended-verified. An estate you have just recovered restores its interval but not its proof history, so it reads as never verified rather than as having lapsed.

The check is omitted entirely when you have stated no interval, and when your engine holds an operational key, since that posture proves restorability without you and is already graded by the restore-test recency check. Falling behind raises one notification, when the check first goes from passing to needing attention, not once per hour while it stays there.

The two kinds of run update your records differently, and that difference is what keeps a compliance reader from being misled. A full attended pass updates the “restorability last proven” record for the downpipe, stamping who proved it and when, and marking it as a full one-hundred-percent proof. A sampled pass updates recency, so the freshness clock moves, but it is shown with its sample rate rather than as a fresh full proof. See prove recoverability for how that stamp reads alongside the other proof verbs.

Where this fits

Attended verification is the recovery proof the offline-key-only posture relies on, so it sits alongside choosing your key posture and the mechanics in recovery postures. For how a full pass stamps “restorability last proven” beside the drill, the blind restore test, the keyless attestation and the canary, see prove recoverability. When you need to recover for real with no engine in the loop, break-glass offline recovery is the offline reader and your identity.key.

Last updated 25 September 2026.