Docker Content Trust Is Going Away. Your Image Verification Plan Should Not.

Docker announced that Docker Content Trust and the hosted Notary v1 service at notary.docker.io are being fully retired. The important date in the docs is blunt: the Notary v1 service shuts down on December 8, 2026.

For most Docker users, nothing changes. DCT was opt-in. If you never set DOCKER_CONTENT_TRUST=1, never used docker trust sign, and never wired Kubernetes admission policy around DCT signatures, your docker pull command will keep behaving exactly like the little raccoon it has always been: opportunistic, tag-shaped, and mostly unconcerned with your governance documents.

But if you did rely on DCT, this is not a cosmetic deprecation. It is Docker telling you that the old trust model has aged out, and that container verification now lives somewhere else.

What is actually changing

Docker Content Trust used a Notary v1/TUF-based flow to sign and verify image tags. Docker says Notary v1 is no longer maintained, adoption is extremely small, and the ecosystem has moved toward OCI-native signing systems such as Sigstore Cosign and Notation.

The affected workflows are specific:

• DOCKER_CONTENT_TRUST=1 in developer shells, CI, Dockerfiles, or deployment automation.
• docker trust sign, docker trust inspect, or docker trust revoke in scripts.
• Kubernetes admission controllers or release gates that expect DCT signatures.
• Publishers signing Docker Hub images with DCT.

Docker’s content trust documentation now carries the retirement notice and says the Notary v1 service shuts down on December 8, 2026. Docker’s migration post also notes that ordinary docker pull and docker push operations are not the target; the retirement affects trust operations.

That distinction matters. This is not “Docker pulls are broken.” It is “your old verification mechanism is being removed.” Those are very different incident tickets, though both can ruin a morning if discovered by CI instead of by inventory.

The replacement is not one thing

DCT was simple to describe: turn on content trust, sign tags, require signed tags.

The modern replacement is a stack:

1. Pin by digest when you need reproducible content.
2. Sign images with an OCI-native tool such as Cosign or Notation.
3. Generate provenance and SBOM attestations during builds.
4. Enforce policy at admission/deploy time rather than trusting that humans will remember the ceremony.

Docker’s migration guidance makes the first point explicitly: digest pinning guarantees you get the exact image content you requested, but it does not prove publisher identity. That is the line too many teams blur. A digest answers “which bytes?” It does not answer “whose bytes?”

For the metadata side, Docker’s build attestation docs describe BuildKit-generated provenance and SBOM attestations. Provenance attestations identify how the image was built; SBOM attestations describe what went into it. Docker also documents GitHub Actions support through docker/build-push-action, including a very practical warning: max-level provenance can expose build arguments, so secrets belong in secret mounts, not build args. Supply-chain metadata is great until it faithfully preserves the bad decision you hoped nobody would notice.

What builders and operators should do now

If you run containers in production, the action item is not “install Cosign and declare victory.” The action item is to map your current trust boundary.

Start with inventory:

• Search CI/CD config for DOCKER_CONTENT_TRUST.
• Search scripts for docker trust commands.
• Check admission controllers and policy engines for DCT-specific verification.
• Identify publishers still signing Docker Hub images with DCT.
• Identify base images currently referenced by mutable tags such as latest, stable, or version tags without digests.

Then decide what each part of the pipeline needs:

• Reproducibility: pin runtime and base images by digest where drift would be dangerous.
• Publisher identity: sign images with Cosign or Notation and document which identity or certificate chain is trusted.
• Build transparency: produce provenance and SBOM attestations from CI.
• Enforcement: verify signatures and metadata in the deployment path, not in a wiki page named secure-release-process-final-v3.md.

For Kubernetes, Docker points to admission-time enforcement options: Kyverno can verify Cosign signatures, while Ratify plus Gatekeeper is a common path for Notation-style verification. The exact tool matters less than the invariant: unsigned or policy-failing artifacts should fail before they become pods.

Docker also suggests Docker Hardened Images for teams relying on DCT primarily to verify base images from Docker Hub. That may be useful, but treat it as a base-image strategy, not a full supply-chain strategy. Your application image still needs its own signing, provenance, SBOM, and deployment policy.

The caveat: modern does not mean automatic

Moving away from DCT is directionally right. Notary v1 was built for a different registry era. OCI artifacts, identity-based signing, attestations, and policy engines are a better fit for how containers are actually built and shipped now.

But the migration can also increase complexity. Instead of one Docker feature, you now have several moving parts: registry artifact support, CI identity, signing keys or OIDC configuration, attestation storage, admission policy, exception handling, and developer education. The new stack is better, but it is not magic. It is plumbing with cryptography in it, which means it can leak in more interesting fonts.

The practical takeaway: do not wait for the final shutdown window to discover whether your pipeline depends on DCT. Audit now, replace tag trust with digest pinning plus OCI-native signing, and move enforcement into the deploy path. If your supply-chain security model only works when everyone remembers the flag, it is not a model. It is a group project with YAML.