Overrides, attestations and posture regression

This page explains two related parts of the security centre: the Owner-only flow for grading a posture check the platform graded fail or cannot verify, called an override, and the way the engine notices when a check that used to be good starts needing attention. It is written for an auditor reading the posture as an honest record of decisions, and for an Owner who needs to act on a finding they cannot fix, or who can satisfy a control by means the platform cannot observe.

An override lets an Owner say, on the record and with a reason attached, one of four things: this control IS satisfied by means you cannot see (an attested pass); a different control satisfies the same intent (a compensating control); this control does not apply here (not applicable); or we know this fails and accept the risk for now (a risk acceptance). The posture score, the listing in the security centre, the signed reports and the regression detector all treat a graded check consistently, so the number you see and the decisions behind it never drift apart. No report ever shows a bare red “fail” for a control you have graded: it shows your determination, labelled as yours.

For how the score itself is computed and what the individual checks observe, read the posture score and control checks. This page assumes that and focuses on the override flow and regression behaviour.

The four override kinds, and what each does

Recording an override does not remediate the control. The check still appears in the security centre, still describes what was observed and how it is decided, and still carries its remediation, so a reviewer can see exactly what was graded and why the underlying state is what it is. What changes is the check’s effective status, how it counts, and how it reads in the reports.

The fold happens in one place. A check whose automatic outcome is fail, or cannot-verify, takes the override’s status; not-applicable pins regardless of the automatic outcome (an N/A is a scoping decision, so it holds even if the automatic check would pass); and an automatic pass wins over the other kinds, with the override retained dormant on the check so you can see it and withdraw it. An override never hides a check and never rewrites what was observed.

When an Owner records an override, the engine stores a small record against that check id. The record carries the check id, the kind, the reason the Owner typed, who recorded it and when. The identity is the verified Owner’s email, or null for the bare-token break-glass path, which has no attributable email. The reason is required for every kind and length-bounded. None of these fields can hold a secret; the record is redaction-safe by construction, the same discipline every posture surface follows. A record written before override kinds existed has no kind field and reads as a risk acceptance everywhere.

Only an Owner can grade, and only a real check

An override is an Owner-only action. It is gated by the posture.riskaccept capability, which is owner-reserved: it can never be granted to a custom role and no non-owner role holds it. The console mirrors this gate so the affordance is shown disabled with a reason to anyone who is not an Owner, but the engine is the enforcement point. Both the public route and the durable object behind it re-check the capability, so a forwarded request from a caller who lacks it is refused, not merely hidden.

The capability alone is not enough when the Owner is on a cookie session. Recording an override is treated as a sensitive action, so an Owner signed in with a passkey or a recovery code must also complete a fresh WebAuthn step-up re-authentication before the engine will record it. On the first attempt the engine fails the ambient session with 401 {stepUpRequired:true}; the console catches that, runs a fresh passkey assertion to mint a single-use step-up token, and retries the same request with an x-downpipes-stepup header. The step-up check fails closed, so if it cannot be reached the action is denied rather than allowed. The bare-token break-glass path and Cloudflare Access sessions are exempt, because each manages its own factor outside this check.

Only a real check id and a real kind may be recorded. Before it stores anything, the engine checks the submitted id against two things: a pattern that bounds it to a safe storage-key fragment, and the fixed set of known check ids; the kind must be one of the four override kinds (an absent kind reads as a risk acceptance, so an older console keeps working). A typo, an unknown id or a crafted value is rejected as a bad request rather than landing as a dangling record for a check that does not exist. This keeps the graded set in lockstep with the checks the engine actually computes.

The override is recorded in the tamper-evident audit log as a first-class posture-override-set event naming the check id and the kind: who did it, when, what was graded and how. The reason text itself is not written into the audit log; it lives on the override record and flows into the posture report and evidence packs. The audit log carries operator identity by design, so it is the attributable trail of who graded which control and when; withdrawing one records posture-override-withdrawn the same way.

Withdrawing an override

Withdrawing an override removes the stored record for that check id. The check is then graded on its computed state again, exactly as if it had never been graded. If the underlying condition is still present, the check shows as failing (or needing attestation) once more; if the condition has since been resolved, the check shows as a genuine pass. Withdrawal is the same Owner-only posture.riskaccept action, re-checked by the engine and held to the same fresh WebAuthn step-up on a cookie session, and it is idempotent: withdrawing an override that is not present is a no-op success rather than an error. An audit entry is recorded only when something was actually removed.

In the console, a failing check carries an Owner-only “Override” action and a needs-attestation check an “Attest or override” action; both open the same modal, with the kind pre-selected to the likely intent and each kind’s consequence explained. A graded check carries “Change override” and “Withdraw override”. A reviewer viewing the security centre as a non-Owner sees all of these disabled, with the reason that the action needs the Owner role.

Media diversity: the canonical attested check

The clearest example of a check an Owner is meant to grade with an attested pass is media-diversity, the “two different media” leg of 3-2-1. downpipes is cloud-only object storage, so the platform cannot verify media-type diversity for you: two buckets, or a bucket plus an external S3, are the same media class as far as the engine can tell. Once any source fans out to two or more destinations, the check reads “needs attestation” (amber, never a red failure the operator has no automatic way to clear) until an Owner attests it. The same pattern covers admin-strong-auth: MFA enforced inside your IdP or your Cloudflare Access policy is invisible to the engine, so the check asks for your attestation rather than fabricating a verdict either way.

Attesting media-diversity is the honest tick. It records that the Owner has confirmed their destinations meet their own media-diversity policy, for example distinct providers or distinct accounts. It is an operator attestation, never a platform claim that the media are genuinely diverse. Before any fan-out exists the check does not apply and passes silently, so it only prompts for attestation once there is something to attest.

Posture regression: a check that used to be good and now needs attention

Separately from overrides, the engine watches for posture going backwards. Each time the posture report is computed, the engine takes a snapshot of the outcome per check id, storing only the id, a single boolean for whether it was good (not needing attention), and the severity. When a later computation finds a check that the prior snapshot recorded as good but that now needs attention (failing, or newly awaiting attestation), the engine treats that as a regression and emits a posture-regression notification.

The report is computed on every read, and the engine also runs a scheduled evaluation about every six hours, so regression detection does not depend on someone opening the console: an unwatched account still alerts within the interval. An ordinary read refreshes the same snapshot, so an actively-viewed account never pays an extra scheduled computation.

A few properties make this honest rather than noisy:

• A newly added check is never a regression, because it has no earlier good state recorded to fall from.
• The very first computation, when there is no prior snapshot at all, is never a regression for the same reason.
• The “good” basis is everything not needing attention: pass, every override kind including not-applicable, and the reserved resolved-alternative all count. Grading a check therefore does not later read as a regression, an N/A never regresses, and a check that recovers on its own is not treated as one either.
• A check that was failing and stays failing is not a regression. Only the transition from a recorded good state to a current needs-attention state counts. Withdrawing an attestation moves the check back to needs-attention, and that transition does alert, deliberately: the posture dropped.

The severity of the notification follows the severity of the check. A regression on a critical check, such as a downpipe that loses its recent successful restore test, is emitted as a critical notification; any other check regresses as a warning. The detail names the check title only, which is redaction-safe, and never carries a secret.

How the regression notification is dispatched

The detection itself happens inside the durable object that holds the snapshot, which does no network work of its own. The public route that computes the posture report reads back the list of detected regressions and routes each one through the same notification path the rest of the alert stream uses: it resolves the channels that subscribe to the event, delivers through the channel adapters, then records the redaction-safe per-channel outcome back into the notification history.

That dispatch is fire-and-forget and fail-open. A regression is routed without the posture read waiting on it, and any delivery hiccup is swallowed so it can never turn a posture read into a failure. The practical consequence is that the notification is best-effort observability: a delivery problem degrades to “no regression notice on this read” rather than a blocked or failed posture computation. The snapshot is still updated each time, so the comparison is always against the most recent state.

A worked sequence

To make the two behaviours concrete, consider a single critical check, restore-test-recency, over three posture reads.

1. A passing baseline

   Every downpipe has a recent successful restore test, so the check passes. The snapshot records the check id as passing. Nothing is emitted.

2. The check regresses

   A downpipe’s last successful restore test ages past the window, or its latest test fails, so the check now computes as failing. The prior snapshot had it passing, so this is a regression. Because the check is critical, a critical posture-regression notification is routed to any subscribed channel, and the new snapshot records the check as failing.

3. An Owner accepts the risk, for now

   The Owner cannot run a drill immediately and accepts the risk with a reason, perhaps that a remediation window is already scheduled. The check status folds to risk-accepted, it counts toward the score again, and it is listed under the marked-by-you heading. Because a graded check is not in the needs-attention set, the next snapshot records it as good, so it will not re-fire as a regression while the override stands. When the Owner later runs the drill and withdraws the override, the check is graded on its observed state once more.

Where this fits

An override changes the status of a check and how it scores, so it is best read alongside the posture score and control checks, which defines the score, the severities and what each check observes. For what is and is not in scope of the posture in the first place, see coverage, the honest-unknown view of which resources are protected and tested. Recording and withdrawing an override can be routed through a second-person approval when change control is enabled, described under change control. For the standing honest phrasings behind these claims, including why an attested check is never a verified one, read precise claims and honesty.

Last updated 2 July 2026.