Skip to content

CONCEPT Cited by 1 source

Deployment transparency evidence

Definition

Deployment transparency evidence is a public, reproducible audit artifact that documents a specific infrastructure deployment event was provisioned under the claimed process. It is published alongside the deployment itself — not held privately as an internal engineering-review record — so that any user can independently verify the deployment without relying on the operator's word or a third party's attestation.

The structural shape:

  • Infrequent, high-stakes events — HSM-fleet rollovers, TEE-image releases, signing-key rotations. The low event rate is precisely what makes each event high-stakes: there is no "next one next quarter" to correct a bad one against.
  • A claimed process — the operator publishes, in advance, a procedure that a secure deployment will follow (e.g. multi-party sign-off, physical attestation, build-reproducibility claim). The Audit section of a whitepaper is a typical home for this procedure.
  • An evidence artifact — on each deployment, the operator publishes evidence (signed transcripts, attestation reports, photographs of procedural sign-offs, build-provenance manifests) sufficient for an external verifier to replay the claimed process against the artifact and get the same result.
  • Reproducibility by any user — the artifact is not just visible; it is verifiable. A user with the published procedure and the artifact can independently arrive at "yes, this matches" or "no, it doesn't."

Canonical wiki instance — Meta HSM-fleet rollovers

The 2026-05-01 Meta Engineering post on strengthening E2EE backups introduces the canonical wiki instance:

"Transparency in the deployment of our HSM fleet is essential to demonstrating that the system operates as designed and that Meta cannot access users' encrypted backups. We will now publish evidence of the secure deployment of each new HSM fleet on this blog page, further cementing our leadership in the space of secure encrypted backups. New fleet deployments are infrequent — typically no more than every few years — and we are committed to demonstrating to our users that each new fleet is deployed securely, which any user can verify by following the steps in the Audit section of our whitepaper."

Three structural properties worth canonicalising from that passage:

  1. Publication is on the Meta Engineering blog — a single canonical location known in advance. Users don't have to discover where the evidence lives.
  2. Rollover cadence is named — "typically no more than every few years." The promise is tractable: users can plausibly check for a new deployment post when they rotate backup schemes or audit their security posture.
  3. Verification path is pre-published — the Audit section of the Security of End-To-End Encrypted Backups whitepaper describes the procedure in advance, so the evidence published later is comparable against a known standard.

Relationship to transparency logs

Deployment transparency evidence is the event-scoped sibling of a transparency log. Both make operator behaviour externally observable; they differ on cadence and artifact shape:

Transparency log Deployment transparency evidence
Cadence High-rate (certificates issued continuously, binary digests on every release) Low-rate (fleet rollovers every few years)
Artifact Append-only structured ledger with inclusion proofs Per-event published-prose + artifact (transcripts, attestation reports, photos)
Verification Merkle-tree inclusion proof Follow a documented audit procedure
Operator independence Typically third-party-run log Published by the operator; independence comes from reproducibility

The two compose naturally in a full security-architecture stack:

Both of Meta's 2026 security-architecture posts show a two-artifact transparency posture: a low-frequency event-scoped artifact for high-stakes rollovers + a high-frequency log-scoped artifact for everyday operations. See patterns/publish-deployment-evidence-for-transparency for the pattern form.

What deployment evidence does NOT provide

  • Evidence quality is not guaranteed by evidence existence. A published evidence artifact can be incomplete, misleading, or fabricated. The user's verification path (Audit section of the whitepaper) is what converts "we published something" into "it satisfies the claimed standard." Publishing is necessary; it is not sufficient.
  • The operator still has to be honest about what a deployment means. If Meta quietly replaced the signing keys without calling it a new fleet deployment, no transparency evidence would be published. This is bounded by the semantic definition of "deployment" and is tighter with an external review than with operator-alone authority.
  • User inspection is voluntary. Like Certificate Transparency, real-world trust depends on someone — not every user, but someone with reproducible tooling — routinely checking. The public artifact is a prerequisite, not a substitute, for external scrutiny.

Seen in

Last updated · 445 distilled / 1,275 read