Docker Content Trust gets a sunset date. The harder question is what you sign with next.

How many production pipelines do you think have DOCKER_CONTENT_TRUST=1 set today? Be honest — pick a number, write it down. (Whatever you wrote, it's probably high.) That's the install base Docker just put on a hospice schedule: the company has published the formal retirement plan for Docker Content Trust and the Notary v1 service at notary.docker.io, ten years after DCT shipped as one of the container ecosystem's first attempts at signing images.

The shutdown isn't immediate. Write brownouts hit on July 14 and 15, read brownouts on August 10 and 12, and the full lights-off lands on December 8 — each window four hours, all in the morning Pacific time. On those brownout days docker trust sign and docker trust inspect will simply stop working for a stretch, as a preview of what happens at the end of the year. Everything else about your build is unchanged, assuming DOCKER_CONTENT_TRUST is unset. The post is firm on that point: if you have never enabled DCT, this change does not touch you.

Why this one deserved the off-switch

The Notary v1 codebase isn't merely old — it's unmaintained. Docker's own post says the upstream is no longer worked on, which is the polite way of saying nobody is coming to patch it if something interesting turns up in the TUF metadata handling. Running an unmaintained signing service forever is paying rent on infrastructure that promises trust and ships entropy.

The bigger problem was always cultural, not codebase. DCT was a single environment variable. Set it to 1 and your CLI refused unsigned pulls; set it to 0 (or just didn't set it) and you got the same image whether the publisher signed anything or not. The verification was opt-in on the client. The signing was opt-in on the publisher. Both ends meeting in the middle was rare. (When you can disable a security control by typing =0, you don't really have a security control. You have a suggestion.)

What "migration" actually looks like

For most environments, the migration is one line — unset the variable in your shell profile, CI config, Compose file, or Dockerfile, and move on. That is the honest, Docker-endorsed answer for the vast majority of users.

For the much smaller group that was actually signing things, there are two serious replacements, and you should pick one before December does the picking for you:

• Cosign, from the Sigstore project, signs with short-lived identity-based certificates and stores the signature as an OCI artifact in the same registry as the image. Pair it with Kyverno on the admission side to fail pulls that aren't signed by an identity you allow.
• Notation, from the Notary Project (same name, different generation), uses a certificate-based PKI model and likewise writes signatures into the registry as OCI reference artifacts. Pair it with Ratify + Gatekeeper for cluster-side verification.

Either works. The right pick depends on whether your org already runs a private PKI — in which case Notation rewards the existing investment — or would rather lean on Sigstore's keyless identity model. Docker also points users at digest pinning (image@sha256:<digest>) as a baseline. That catches "did this image change" without solving "who made it" — useful as a floor, not a ceiling.

The part nobody is going to do

Here is what the migration guide cannot help with. The retirement is operational. The harder question — were you actually verifying signatures at deploy time, or just generating them so the audit checkbox would stay green? — is strategic. Swapping DCT for Cosign or Notation without also wiring an admission controller to reject unsigned pulls is the same compliance theater in a fresher T-shirt.

Signed by nobody, checked by nobody. For ten years that was DCT's quiet failure mode. December turns off the service. The rest of the answer is on you.