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, 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, let your engine run the verification while you are present, then let it forget 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.
Be clear about the ceiling on that proof. 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. Use it for what it is, and do not read it as 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, which holds it in memory for that one check and overwrites it as soon as the check finishes, rather than waiting for the session to 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 honest caveat for 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.
Running a session
A session has two choices. The first is scope: the latest backup of every 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 honestly for what it is, 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 engine is holding the per-archive keys in memory, so if you close the session or the engine restarts, the run resumes only once you supply your key again. 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. The first run for a given scope has no timing history behind it, so its time estimate is coarse and sharpens on later runs.
If your break-glass key is split
A split M-of-N key works here, with one manual step you should expect rather than discover on the day.
Reassemble the key first, on the recover-key screen, where a quorum of shares and your encrypted identity file reconstruct the original private key. That screen reaches no network at all. It holds no engine client, so it cannot upload anything even in principle, and the reconstructed key is only ever offered to you as a local download. The M-of-N threshold is not weakened anywhere in that flow.
Then start an attended verification and select the downloaded identity.key in the same key picker you would
use for an unsplit key. It is accepted exactly as an unsplit break-glass key is, and the session runs the same
way, with the key read in your browser and never uploaded.
The console does not carry the file between those two screens for you. That handoff is deliberately yours: the recover-key screen stops at reconstruct-and-download, which is what keeps it a surface that cannot reach the network. So the recovery path is complete for a split key, and it has a person in the middle of it. Worth walking once before you need it, because the day you need it is not the day to discover which file the picker wants.
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 this 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 .