Docker Content Trust is being switched off. Docker's own retirement notice sets December 8, 2026 as the shutdown date for the notary.docker.io v1 signing service, with revocation of Docker Official Image signing certificates having already begun on August 8, 2025. Docker's own numbers explain why almost nobody will notice: fewer than 0.05% of Docker Hub pulls used Content Trust at the time the retirement was announced. Azure Container Registry started deprecating DCT support on March 31, 2025, targeting full removal by March 31, 2028, and Harbor dropped Notary v1 support entirely back in version 2.9.0 in 2023. The mechanism that was supposed to be Docker's answer to supply-chain trust never got past single-digit adoption, and two very different successors — Sigstore/Cosign and Notary v2 (branded as the Notation CLI) — have split the field that's left. One eliminates signing keys almost entirely; the other doubles down on traditional PKI. This piece walks through how each actually works, where each is winning, and what changes once you have to verify a signature at deploy time instead of just producing one.
Why did Docker Content Trust fail to catch on?
Docker Content Trust never solved the problem it was built for: it required operators to run and secure a separate Notary v1 server and to manage long-lived signing keys client-side, with no straightforward key-rotation or revocation story if a laptop with a root key got compromised. Notary v1 itself implements TUF (The Update Framework), which is sound cryptographic design, but the operational burden — provision a signing server, distribute delegate keys, rotate them, back them up — sat on top of a workflow (docker push) that had shipped for years without any of that friction. Ecosystem support followed usage: Harbor removed Notary v1 in v2.9.0 (2023), and cloud registries are unwinding support on multi-year timelines rather than ripping it out immediately, because enough regulated pipelines still depend on it to need a runway. The lesson the two successor projects both absorbed is that a signing scheme only gets adopted if it fits inside the registry push/pull flow instead of bolting a new server onto it.
What makes Sigstore's keyless signing different?
Sigstore's core departure from every prior signing scheme is that it removes long-lived private keys from the picture entirely. Instead of a developer or CI job holding a signing key, Sigstore's Fulcio certificate authority issues a short-lived X.509 certificate — valid for roughly 10 minutes — bound to a workload's OIDC identity, such as a specific GitHub Actions workflow or GitLab CI job. The signing operation happens inside that ten-minute window, and the certificate expires immediately after, so there is no key to steal, rotate, or leak months later. Every signature is then recorded in Rekor, Sigstore's public, append-only, Merkle-tree-based transparency log, so anyone can independently verify that a specific identity signed a specific artifact digest at a specific time, without trusting Docker, Sigstore, or the signer's own claims. Cosign, the CLI most commonly paired with Sigstore, stores the resulting signature as an OCI artifact alongside the image manifest in any standard OCI-compliant registry — no separate trust server required, unlike Notary v1. Sigstore itself is governed under the Open Source Security Foundation (OpenSSF), not CNCF — a distinction worth being precise about, since Notary Project (below) is the CNCF-governed one of the two. That governance difference hasn't slowed adoption: Sigstore has become the default signing mechanism behind SLSA provenance and in-toto attestation tooling industry-wide.
How does Notary v2 / Notation differ from the original Notary?
Despite the name, Notary v2 — governed under the CNCF's Notary Project and shipped as the notation CLI — was rebuilt from scratch and is not backward-compatible with Notary v1 or its TUF trust model. It implements the OCI signature specification directly, supporting both JWS and COSE signature envelope formats, and like Cosign it stores signatures as separate OCI manifests co-located with the image in the registry rather than requiring an external signing server. The meaningful difference from Sigstore is philosophical: Notation is built for organizations that already run an internal PKI and want signatures anchored to long-lived certificates issued by their own CA, not short-lived certificates bound to an OIDC identity. Its plugin model supports pluggable KMS/HSM backends — AWS KMS and Azure Key Vault are common integrations — which lets a security team keep private keys inside hardware they already audit for other purposes. As of current CNCF records, the Notary Project sits at Incubating status — it's the one of the two projects covered here that actually falls under CNCF governance — and it tends to be the pick for regulated environments where "who is the certificate authority" is a compliance question with a specific, pre-approved answer.
Which approach do enterprises actually pick, and why?
The split tracks identity infrastructure more than security posture. Teams already built around ephemeral, CI-native identity — GitHub Actions, GitLab CI, cloud workload identity federation — gravitate to Sigstore because Fulcio's OIDC binding maps directly onto the identity they already have, and Rekor's public transparency log gives downstream consumers an audit trail they don't have to host themselves. Teams operating in regulated industries with an established internal CA — financial services, government contractors, healthcare — tend to prefer Notation, because auditors and internal PKI policy often require signatures traceable to a certificate their own CA issued, not a third-party OIDC provider's identity claims. Neither is objectively "more secure" in isolation: Sigstore's transparency log adds detectability that Notation's plugin-KMS model doesn't natively provide, while Notation's long-lived-cert model fits change-control processes that some compliance frameworks still assume. In practice, several platforms — including Safeguard's own attestation pipeline — support both and let teams pick per-environment rather than forcing an org-wide choice.
How does signature verification actually get enforced at deploy time?
Signing an image is only half the workflow; verification has to run somewhere that can actually block an unsigned or improperly signed image from running. The common pattern is a Kubernetes admission controller that intercepts pod creation, checks the image reference against its registry for an attached signature (Cosign or Notation both publish signatures as sibling OCI artifacts, so the check is a registry lookup, not a separate database query), and confirms the signer's identity matches an allow-list before permitting admission. For Sigstore-signed images, verification additionally checks the Rekor inclusion proof to confirm the signature was actually logged and hasn't been backdated or removed. Safeguard's admission controller runs exactly this check on every pod admission, confirming SBOM presence, signature validity, and that the artifact meets a configured SLSA level — denying admission on any mismatch. This is the point where signing schemes stop being a CI-pipeline nicety and start functioning as an actual supply-chain control: an attacker who compromises a registry can swap an image, but they can't forge a valid Fulcio-issued, Rekor-logged signature or a Notation signature chained to your internal CA without also compromising the identity provider or CA itself.
How Safeguard Helps
Safeguard signs and verifies container images with both backends discussed here rather than forcing a single choice: Sigstore/Fulcio/Rekor is the default for teams that want keyless signing tied to CI workload identity, and X.509/Notation is available for regulated tenants that need signatures anchored to an internal CA. Every signed artifact carries a SLSA provenance attestation, a CycloneDX or SPDX SBOM, and a vulnerability-scan snapshot, all in in-toto format, and Safeguard's Kubernetes admission controller verifies signature validity, SBOM presence, and SLSA level on every pod admission — denying deployment on any failure. Enterprise tenants that need transparency-log semantics without depending on the public Rekor instance can run a private Rekor at their own subdomain, and vendor or third-party images can be checked at CI time with safeguard verify --expect-signer and --expect-slsa-level before they ever reach a cluster.