The security-centre posture score and control checks

This page is a reference for the posture score the security centre shows: how the number is computed, what each control check looks at, and which checks are graded against which are informational. It is written for an auditor who wants to read the score as an honest summary rather than a marketing figure, and for an operator deciding what to fix first.

The posture is a pure computation over your account’s own observable state. The engine gathers presence booleans, per-downpipe recency, expiry states, identity counts and a few flags, then runs a fixed function with no input or output of its own; the console renders the result. The vendor reads nothing, and every check carries only redaction-safe metadata: an id, a title, a severity, a status, the automatic outcome, the named control it maps to, what was observed, how the determination is made, and how to fix it. No check can carry a key, a value or a fingerprint.

How often it updates

The report is recomputed live on every read: opening the security centre, pressing its refresh, or generating a posture report or evidence pack always evaluates every check against the state at that moment; nothing is cached. The console also refreshes the open screen about every thirty seconds while it is visible (pausable with the auto-refresh control), and the engine runs a scheduled evaluation about every six hours so a previously-good check that regresses fires its posture-regression notification even when no one has the screen open. There is no state a stale read could show you; the only latency is the gap since the last computation.

How the score works

The score is a weighted pass fraction, rendered as a 0 to 100 integer. Each check has a fixed severity, and each severity carries a weight. The score is the sum of the weights of the checks that count as passing, divided by the total weight of all checks, multiplied by 100 and rounded. A critical check therefore moves the number far more than a low one.

Every check first computes an automatic outcome: pass, fail, or cannot-verify. The third is honest, not evasive: some controls (media diversity for cloud-only storage, MFA enforced inside your IdP or your Cloudflare Access policy) are genuinely unobservable from inside the engine, so the platform neither fabricates a verdict nor paints them as red failures you have no automatic way to clear. A cannot-verify check with no owner grading reads as “needs attestation” (amber), and it does not earn its weight until you grade it.

On top of the automatic outcome sits the Owner’s grading, called an override. The effective status is one of:

Every override requires a reason, records the Owner’s identity and time, queues for a second approver when the four-eyes gate is on, and is written to the audit log as a posture-override-set event naming the check and the kind; the reason itself lives on the record and flows into the posture report and evidence packs, never into the audit chain. An override also asks for a fresh passkey assertion, in both the accept and the withdraw direction. It does not take a change number, and the distinction matters on this page in particular: an override is a config mutation, so the four-eyes gate covers it and the Require Change Number policy does not, even though this page’s own emergency-change-review check watches that policy. See what each policy covers. An override on a check whose automatic outcome later recovers to pass goes dormant: the check reads pass, the recorded determination stays attached and visible, and you can withdraw it.

The checks are sorted most severe first, and within a severity the needs-attention checks (failing or awaiting attestation) sort before the graded and passing ones, so the worst open item is always at the top of the security centre.

The twenty-six checks

There are twenty-six named checks, one per stable id, and each maps to a named control standard. The set is fixed in the code, so the list does not vary by account; what varies is each check’s status. Several are conditional: recovery-codes-low appears only for a signed-in identity with a recovery-code set, dest-cred-encryption only when there is a stored destination credential (or a wrap key) to grade, emergency-change-review only when the Require Change Number policy is on, attended-verification-cadence only on an offline-key-only estate that has stated an interval, and the two update checks only once an engine update has settled through the signed channel. Every check also states, in plain language on its card, how its determination is made. The table gives the id, what it looks at, its severity and the control it maps to.

That is twenty-six checks: three critical, nine high, ten medium and four low.

The critical recoverability checks

Three checks are critical, and together they are the load-bearing recoverability signals. A failure in any of them weighs heaviest on the score, by design, because each one is the difference between a backup that exists and a backup you can actually recover.

restore-test-recency is the headline. It fails critical when any downpipe that has completed at least one run has had no successful restore test within 180 days. “Successful” means the last test outcome was a pass within the window; a downpipe with archives that has never been tested, or whose last test failed, counts as failing. A downpipe that has never completed a run is named in the detail but not failed, because there is no archive to test yet; a brand-new downpipe must not open as a critical failure it cannot clear until its first run. There is a warning band between 90 and 180 days: a downpipe with a successful test older than 90 but not yet 180 days does not fail the critical check, but the detail line flags it as high so it does not silently age into a failure. The check names the worst offender by its downpipe name, which is your own redaction-safe configuration.

seal-verification is the at-seal companion to recency. After a run, the engine can read the just-written archive back from the destination and verify it. This check fails critical when a downpipe’s most recent verify-at-seal verdict was suspect, meaning the archive that landed could not be verified. The run still completed and the archive was not deleted, because the behaviour is fail-open and it alerts rather than destroying data, but a suspect verdict means you should confirm recoverability with a drill or a restore before trusting that copy. A downpipe that has never run with the feature on does not fail, because there is no suspect verdict to surface.

destination-configured fails critical when no archive destination is configured at all, because backups then have nowhere to land. It proves only that a second copy exists off-source, so it is described as the second-copy check and never as 3-2-1; that distinction is set out below.

The identity checks, precisely

access-enforced is a high-severity check, and its meaning is exact and account-level: it fails while a shared-token admin path is effectively live, that is, an ADMIN_TOKEN is configured and has been neither env-disabled nor retired in-app. When that path is dead, every remaining sign-in route (Cloudflare Access, passkeys, native OIDC or SAML SSO, recovery codes) resolves to a verified, attributable identity, and the check passes. It deliberately does not read how the current viewer signed in: a per-caller signal would make the same account score differently depending on who looked, and would unfairly fail a tenant whose admins sign in with passkeys or native SSO rather than Cloudflare Access. The determination is identical for every reader and for the scheduled evaluation.

admin-strong-auth asks whether admin sign-in is phishing-resistant MFA, and it is honest about what the platform can see. It auto-passes only in the state it can observe end to end: every Owner and access-admin identity has an enrolled passkey, no IdP connection is enabled, and no shared-token path is live. In every other state it reads “needs attestation” rather than failing, because MFA may well be enforced somewhere the engine cannot see: your IdP’s conditional-access policy, or your Cloudflare Access policy. If that is your setup, attest it (an attested-pass override naming the policy), and the check reads as a pass attributed to your attestation in the console and every report.

Informational checks that always pass

Two checks are informational and always pass. They state a posture rather than grade an outcome, so they must not be read as graded results that happen to be green.

audit-export-available states that a tamper-evident, signed audit log is retained and can be exported. It is a low-severity informational pass that records the posture; there is no failing condition for it.

encryption-pq-hybrid states that archives are sealed with post-quantum hybrid encryption and signed with a post-quantum hybrid signature, and that this makes them tamper-evident. It too is a low-severity informational pass with no failing condition. The wording is precise on purpose: the encryption is post-quantum hybrid, and the property is tamper-evident, never the stronger words those terms are sometimes loosely swapped for.

These differ from the immutability check, which is medium severity and genuinely graded against a live probe. Its three honest states, only one of which fails, are documented on immutability and attestation.

The 3-2-1 distinctions

The score is careful about 3-2-1, because overclaiming it is an easy way to mislead. The three relevant checks measure different things and are deliberately labelled differently.

destination-configured proves only the second copy: a live source plus one archive off-source. One destination is not 3-2-1, and the check is never labelled as such, because claiming 3-2-1 from a single destination would overstate the posture.

redundant-copies is the verifiable leg of 3-2-1. It checks that each protected source fans out to at least two distinct destinations, so a backed-up source exists in two places, which with the live source is three copies. The platform can verify this from each downpipe’s configured destination count, so it is graded as a real outcome.

media-diversity is the operator-attested leg. downpipes is cloud-only object storage, so it cannot verify the “two different media” criterion for you: two buckets, or a bucket plus an external S3, are the same media class as far as the platform can tell. Once a source fans out the check reads “needs attestation” (never a red failure), and an Owner attests it with an attested-pass override: the honest statement that their destinations meet their own media-diversity policy, recorded with the reason. It is a deliberate operator statement, never a platform claim that the media are genuinely diverse.

Where this fits

The posture report can be generated as a signed artefact; that path, and how to verify it yourself, is on signed reports. Several checks point at the immutability probe, the canary and the audit log, which have their own canonical homes at immutability and attestation, the integrity canary and the audit log. To act on a finding you cannot or will not fix immediately, or to grade a control the platform cannot verify, an Owner uses the override flow (attested pass, compensating control, not applicable, or accepted risk), described on overrides and regression alerts. For the standing honest phrasings behind the score’s claims, read precise claims and honesty.

Last updated 4 August 2026.