> ## Content Index
> Fetch the complete content index at: https://wealthlab.life/llms.txt
> Use this file to discover other available public pages before exploring further.

# Docker Content Trust Retirement: Migrate Before December 8
- URL: https://wealthlab.life/docker-content-trust-retirement-migration/
- Published: 2026-10-25T00:08:22.000Z
- Updated: 2026-10-25T00:08:22.000Z
- Description: Docker will shut down notary.docker.io on December 8, 2026. Audit DCT dependencies and replace verification before disabling the legacy path.
- Author: WealthLab
- Tags: Docker, Security, Cloud Infrastructure

**Quick answer:** Docker says Docker Content Trust (DCT) and the Notary v1 service at `notary.docker.io` will shut down on **December 8, 2026**. Ordinary `docker pull` and `docker push` operations are not being retired, and users who never enabled DCT are not affected. Operators who set `DOCKER_CONTENT_TRUST=1`, run `docker trust` commands, sign Docker Hub images through DCT, or enforce DCT signatures in deployment policy need a migration plan now.

This is source-based operator analysis, not a hands-on migration report. WealthLab reviewed Docker's retirement notice and engine documentation, the archived Notary v1 repository, Microsoft's Azure Container Registry deprecation notice, Harbor's Notary v1 deprecation record, and current Notation and Cosign documentation. No registry, signing key, CI pipeline, or admission policy was changed or tested for this article.

## What is actually shutting down

DCT is Docker's opt-in tag-signing workflow built on The Update Framework and Notary v1\. Docker's current documentation warns that the hosted Notary v1 service at `notary.docker.io` will close on December 8\. Docker's migration notice says the retirement concerns DCT trust operations; normal image transfer remains available.

The distinction matters. A successful image pull after removing DCT proves availability, not authenticity. If a pipeline currently treats a verified DCT signature as an admission gate, silently unsetting the variable restores delivery while also removing that gate. Preserve the security objective before removing the old mechanism.

## Who is affected

- **CI/CD owners** whose jobs export `DOCKER_CONTENT_TRUST=1` or invoke `docker trust sign`, `inspect`, or `revoke`.
- **Image publishers** that sign Docker Hub tags with DCT and expect consumers to validate them.
- **Platform teams** whose Kubernetes admission controller, deployment wrapper, or policy engine expects DCT/Notary v1 metadata.
- **Developer workstations** with DCT enabled in shell profiles, environment managers, or shared build scripts.

If those indicators are absent, Docker says the change should not affect the workflow. Still verify rather than infer: environment variables can be injected by CI groups, reusable workflows, secrets managers, or old base images.

## The retirement timeline

Docker scheduled four-hour write brownouts on July 14 and 15, 2026 and read brownouts on August 10 and 12, followed by full shutdown on December 8\. Those rehearsal windows have passed. A pipeline that did not run during them received no useful warning, so “we saw no outage” is not evidence that DCT is absent.

Docker first announced the retirement in July 2025\. The broader ecosystem had already moved in the same direction: Microsoft retired DCT support in Azure Container Registry on March 31, 2028 after announcing deprecation, while Harbor deprecated Notary v1 integration in its 2.9 release line. These dates describe different products and must not be treated as extensions of Docker's December 2026 deadline.

## Migration decision: Notation or Cosign

Docker identifies both the Notary Project's **Notation** and Sigstore's **Cosign** as modern OCI-native alternatives. They can store signatures as OCI artifacts alongside images, but they are not drop-in switches for DCT. Key identity, trust policy, registry behavior, verification command, and deployment enforcement all need an explicit design.

- **Consider Notation** when an OCI artifact-signing workflow and explicit trust-policy model fit the organization. The official quickstart covers signing and verifying artifacts, but production use still requires a suitable plugin/key provider and trust-store governance.
- **Consider Cosign** when the organization already uses Sigstore, certificate identities, transparency-log evidence, or Cosign-aware admission tooling. The official verification guidance requires constraining the expected certificate identity and issuer for keyless signatures; a generic verification that accepts an unintended identity is not a useful gate.
- **Do not choose from command similarity alone.** Start from the threat model and the verifier: who may sign, which registry/repository is in scope, what identity or key is trusted, where revocation is handled, and what happens when verification infrastructure is unavailable.

## Operator migration checklist

1. **Inventory every DCT dependency.** Search repositories, CI variables, shell profiles, Compose/Kubernetes manifests, build images, policy engines, and runbooks for `DOCKER_CONTENT_TRUST`, `docker trust`, `notary.docker.io`, and Notary v1 client/server references.
2. **Map producers to consumers.** For each image, record who signs, which tag or digest is deployed, who verifies, the trust root, and the failure behavior. Include third-party images that a policy currently expects to be DCT-signed.
3. **Select and document the replacement trust model.** Decide whether keys or workload identities authorize signing. Pin expected certificate identities and issuers where applicable. Do not let “signature exists” replace “signature is from the approved signer.”
4. **Test registry support.** Confirm that the target registry stores and returns the chosen signature artifact and that retention, replication, garbage collection, and vulnerability tooling do not discard or separate it unexpectedly.
5. **Run old and new verification in parallel.** Sign a non-production image, verify by digest, exercise the admission policy, test an unsigned image, an image signed by an untrusted identity, and an unavailable-verifier condition.
6. **Update consumers before producers stop DCT.** A newly signed image provides no protection if deployments never check the new signature. Roll out policy in audit mode where supported, review results, then enforce.
7. **Remove DCT deliberately.** Only after the replacement works, remove DCT variables and commands, rotate or archive legacy key material according to policy, and update recovery documentation.
8. **Schedule a post-cutover drill.** Verify that authorized releases pass, unauthorized or unsigned artifacts fail as intended, and emergency rollback does not bypass the control silently.

## Failure modes to avoid

- **Availability-only fix:** setting `DOCKER_CONTENT_TRUST=0` and declaring migration complete.
- **Tag-only policy:** validating a mutable tag without binding the deployment to the verified digest.
- **Signer ambiguity:** accepting any valid signature instead of an approved key or workload identity.
- **Producer-only rollout:** publishing OCI signatures that no admission or deployment system checks.
- **Unverified registry assumptions:** assuming signature artifacts survive retention, mirroring, or garbage collection.
- **Fail-open surprise:** discovering during an outage that policy bypasses verification when a service or transparency log cannot be reached.

## Fit and non-fit cases

**This checklist fits** Docker Hub users with DCT enabled, self-hosted CI pipelines using `docker trust`, and platform teams migrating an admission gate from Notary v1 to OCI-native signatures.

**It is not a complete design** for air-gapped environments, regulated key-management systems, custom private Notary servers, multi-registry replication, or organizations requiring a formal software-supply-chain framework. Those cases need a threat model, registry-specific compatibility test, key lifecycle plan, incident process, and documented exception path.

A private Notary v1 deployment is not the same service as `notary.docker.io`, so Docker's hosted-service shutdown does not directly switch it off. The upstream v1 repository is archived and describes the code as obsolete, however; continued private operation still carries maintenance and migration risk.

## Evidence boundary and sources

**Sources checked October 25, 2026.** Docker is authoritative for the hosted-service scope and December 8 shutdown. Tool projects are authoritative for their verification syntax and trust models. Microsoft and Harbor independently corroborate the ecosystem's retirement of DCT/Notary v1, but their product dates do not supersede Docker's schedule.

- [Docker: DCT retirement and migration guidance](https://www.docker.com/blog/docker-content-trust-retirement-and-migration-guidance/) — affected workflows, brownouts, shutdown, and alternatives.
- [Docker Engine: content trust documentation](https://docs.docker.com/engine/security/trust/) — DCT behavior and current retirement warning.
- [Notary v1 repository](https://github.com/notaryproject/notary) — archived upstream status and obsolete-project notice.
- [Microsoft: Azure Container Registry DCT deprecation](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-content-trust-deprecation) — independent platform timeline.
- [Harbor: Notary v1 deprecation](https://github.com/goharbor/harbor/wiki/Harbor-Deprecates-Notary-v1-Support-in-v2.9.0) — independent registry-project change.
- [Notary Project: Notation quickstart](https://notaryproject.dev/docs/quickstart/) and [Sigstore: Cosign verification](https://docs.sigstore.dev/cosign/verifying/verify/) — current replacement-tool documentation.

No hands-on signing or migration test was performed. Exact registry support and production policy behavior must be verified in the reader's environment. This article contains no affiliate links.

## Related WealthLab guides

- [Docker Engine 29.9.1 containerd image-pull security checklist](https://wealthlab.life/docker-engine-29-9-1-containerd-security/) — separate runtime patching from image-authenticity controls.
- [Docker Hub security response checklist](https://wealthlab.life/docker-hub-cve-2026-105445/) — assess registry-side events without treating every pull as compromise.
- [Docker VPS production checklist](https://wealthlab.life/docker-vps-checklist/) — baseline host, update, backup, and exposure controls.
- [Ghost Docker backup and restore](https://wealthlab.life/ghost-docker-backup-restore/) — test application recovery independently of image-signing migration.