Docker Sets a Retirement Clock for Content Trust and Notary v1

Docker is putting a final retirement date on Docker Content Trust and the Notary v1 service behind it, turning an old container-signing feature into a concrete migration task for teams that still depend on it.

In guidance published June 16, 2026, Docker said Docker Content Trust (DCT) and the Notary v1 service at notary.docker.io are being fully retired. The final shutdown is scheduled for Dec. 8, 2026, after a set of staged brownouts intended to flush out CI pipelines, publisher workflows, and admission controls that still assume the old trust service is available.

The announcement is narrow in one sense and important in another. Docker says normal docker pull and docker push operations are not affected by the brownouts. But teams that enabled DCT, used docker trust commands, published DCT-signed images to Docker Hub, or built Kubernetes policy around DCT signatures need to move before the shutdown.

Why Docker is retiring DCT

Docker Content Trust was one of the container ecosystem’s early image-integrity mechanisms. It was built on The Update Framework and the Notary v1 project, and it gave users a way to verify image integrity and publisher identity before today’s OCI-native signing patterns became common.

Docker’s rationale is straightforward: Notary v1 is no longer the maintained path, the broader ecosystem has moved to newer signing systems, and usage is now very small. Docker says fewer than 0.05% of Docker Hub pulls rely on DCT. It also says it began retiring DCT for Docker Official Images last year and is now finishing the work by retiring the Notary v1 service itself.

The replacement direction is not a single Docker-only feature. Docker points users toward modern signing tools such as Sigstore Cosign and the Notary Project’s Notation, which store signatures alongside images or artifacts in OCI-compatible registries rather than depending on a separate Notary v1 trust service.

The brownout schedule matters

Docker is not cutting DCT off all at once. The company listed four-hour brownouts before the final shutdown, with windows beginning at 8 AM Pacific Time. Write operations are scheduled to fail first on July 14 and July 15, 2026. Read operations are scheduled for brownouts on Aug. 10 and Aug. 12, 2026. The full shutdown follows on Dec. 8, 2026.

That ordering is useful. If a publisher still runs docker trust sign, a write brownout should reveal the dependency before consumers lose read-side verification. If a cluster admission policy or CI check still calls DCT read paths, the August brownouts should expose it while there is still time to change the policy.

Who needs to act

Most Docker users likely do not need to do anything. Docker says DCT was opt-in, and normal pulls do not touch the Notary service unless a user deliberately enabled the trust path.

Check for explicit DCT settings

The affected cases are specific. Teams should search shell profiles, CI/CD definitions, Dockerfiles, Compose files, Kubernetes manifests, and deployment scripts for DOCKER_CONTENT_TRUST=1. They should also look for use of docker trust sign, docker trust inspect, or docker trust revoke. Those strings are the clearest signs that a workflow is tied to DCT rather than ordinary registry pull and push behavior.

Separate repeatability from publisher identity

Docker’s migration guidance makes an important distinction. Disabling DCT can unblock pulls after shutdown, but it removes tag-level DCT verification. Pulling by immutable digest can make builds and deployments repeatable, because a digest identifies exact image content, but digest pinning alone does not prove publisher identity. For that, teams need a signing and verification model such as Cosign or Notation.

Move enforcement into the deployment path

Signing images is only useful if production policy checks the signatures before deployment. Docker’s guidance points to enforcement options around Cosign and Notation. The practical task for platform teams is to pick the signing model, decide which identities or certificates are trusted, and enforce that policy in CI and cluster admission rather than treating signatures as optional metadata.

The operational takeaway

DCT’s retirement is another sign that container trust is moving away from older, service-specific verification paths and toward OCI-native signatures, attestations, SBOMs, digest pinning, and policy enforcement. Docker is also using the announcement to point users of trusted base images toward Docker Hardened Images, which it says include signatures, provenance attestations, and SBOMs.

For teams that never enabled DCT, the story should be uneventful. For teams that did, the safest plan is to treat the July and August brownouts as rehearsals: identify every DCT dependency, decide whether the immediate fix is to disable DCT or replace it with a modern signing workflow, and verify the change before the Dec. 8 shutdown turns a warning into a failed release.

Sources

• Docker: Docker Content Trust retirement and migration guidance
• Sigstore: Signing containers with Cosign
• Notary Project: Sign and validate a container image
• Featured image source: Wikimedia Commons

Featured image: Container cranes at the MPET-MSC PSA European Terminal in the Port of Antwerp by Trougnouf, licensed under CC BY 4.0 via Wikimedia Commons; cropped and converted to WebP.