From Docker Content Trust to Sigstore or Notation in 2026: a migration note for teams that need OCI signing without verification debt

Docker Content Trust is no longer something teams can treat as old-but-harmless plumbing. Once Docker began retiring DCT for Docker Official Images and Azure put a dated deprecation clock on its own DCT support, image signing stopped being a background hygiene topic and became a migration problem with real verification failure modes.[1][2][3]

This note is for platform and security teams that already have signed-image habits somewhere in their estate and now need a controlled move to a modern OCI signing path without turning rollout into a CI outage or an admission-policy mess.

Image context: the hero diagram is an analytical support visual built for this piece. It keeps the real decision in view: stop treating DCT as a tag-era trust habit, then choose whether your default verification authority should be workload identity or certificate policy.

The real migration thesis: stop copying DCT semantics forward

The easiest mistake is to search for a “new DCT” and preserve the old operating model.

That usually means keeping image trust mentally attached to tags, preserving long-lived signing keys in awkward places, and delaying verification-policy redesign until after the new tool is installed. That path imports the exact debt you are supposedly removing.

Docker’s own DCT documentation shows why the old model is brittle. DCT trust is attached to the tag portion of an image reference, not the immutable digest, and a publisher can end up with signed and unsigned content under the same tag name at different moments.[1] DCT also depends on a Notary server sidecar, delegation keys, timestamp keys, and an offline root key that Docker explicitly warns is not recoverable if lost.[1]

That was acceptable when DCT looked like the default trust lane for public registries. It is a poor contract for 2026, when the ecosystem has moved toward digest-based verification, OCI-native signature storage, transparency logs, cloud KMS plug-ins, and workload-identity-backed CI.

Why DCT now creates verification debt instead of reducing it

Three concrete facts matter.

First, Docker has already started the retirement path. Docker says the upstream Notary v1 codebase is no longer actively maintained, DCT usage on Docker Hub has fallen below 0.05% of pulls, and Docker Official Images began hitting certificate-expiry trouble from August 8, 2025 onward.[2] If your pull path still depends on DOCKER_CONTENT_TRUST=1, Docker’s own guidance is effectively to unset it for DOI pulls.[2]

Second, Azure Container Registry has published a full removal schedule. Microsoft says DCT deprecation started on March 31, 2025 and that DCT will be completely removed from ACR on March 31, 2028.[3] That is not a soft preference signal. It is a migration window.

Third, DCT’s trust model is awkward for modern automation. The Docker docs show DCT centered on local trust stores, delegation-key loading, and repository initialization through Notary-specific flows.[1] That is a very different operational shape from identity-backed ephemeral signing or cloud-managed certificate lanes.

So the objective is not “replace docker trust sign with a new CLI command.” The objective is to move from a tag-era trust contract to a digest-era verification contract.

The fork in the road: identity-first Sigstore or PKI-first Notation

Most teams do not need one universal answer for every image, but they do need one primary operating model.

A quick sorting rule helps keep the decision honest:

if your release authority already lives in OIDC-backed CI identities, start from Sigstore;
if your release authority already lives in enterprise PKI, trust stores, and certificate review, start from Notation;
if your team is still comparing tools mainly by which one feels most like docker trust sign, you are optimizing for familiarity rather than for the new verification contract.

Choose Sigstore when your strongest primitive is workload identity

Sigstore’s default path is keyless signing. Its docs describe Fulcio issuing short-lived certificates that bind an ephemeral signing key to an OpenID Connect identity, while Rekor records the signing event in a transparency log.[4] In practice, that means the trust anchor is not “where did we hide the long-lived private key?” but “which workload identity was allowed to sign this artifact, under which issuer, and was the event logged?”

That makes Sigstore the better primary lane when:

your CI already has stable OIDC identities from GitHub, GitLab, Google, or Microsoft,
you want to minimize private-key custody in release pipelines,
you care about identity-constrained verification such as --certificate-identity and --certificate-oidc-issuer,
and you are comfortable treating transparency-log presence as part of the verification story.[4][5]

Sigstore also maps well to organizations that want to sign more than images: blobs, attestations, SBOMs, and other release artifacts, while keeping one mental model around identity plus transparency.

Choose Notation when your strongest primitive is certificate policy

Notation sits in a different place. The Notation project describes itself as OCI-standard tooling for adding signatures as standard items in OCI registries, and Microsoft’s ACR transition guidance frames Notary Project as the portable replacement lane for sign-and-verify workflows across registries, CI systems, and AKS admission controls.[3][6][7]

That makes Notation the better primary lane when:

you already run enterprise PKI or HSM/KMS-backed certificate workflows,
your security team wants explicit trust stores and certificate policy rather than identity-issuer policy,
you need a cleaner path into registry-native enterprise controls such as Key Vault, AWS Signer, Ratify, or cloud admission policy integrations,
and your review culture is more comfortable with X.509-style signing governance than with OIDC identity semantics.[6][7]

Microsoft’s tutorial also reinforces two operationally important behaviors: sign by digest rather than mutable tag when possible, and use timestamping/trust-policy flows as first-class pieces of verification, not afterthoughts.[7]

What not to do during migration

Two bad patterns show up often.

1) Do not keep DCT on the pull path while redesigning verification later

If Docker Official Image pulls are already subject to certificate-expiry issues under DCT, keeping DOCKER_CONTENT_TRUST=1 sprinkled across old CI jobs just preserves a brittle dependency surface.[2] Remove DCT from the critical pull path early in the migration, then rebuild verification on the new lane intentionally.

2) Do not port tag-based trust assumptions into the new system

DCT’s tag attachment made it easy to think in human-friendly labels. Modern signing systems work better when tags are for release ergonomics and digests are for trust decisions. Microsoft’s Notation guidance is explicit that the digest should identify the image for signing because tags are mutable and can be overwritten.[7] Cosign’s verification flow likewise validates the digest bound into the signature payload by default.[5]

If your cutover plan still says “verify whatever is tagged stable,” the migration is not finished.

A practical four-phase cutover

Phase 1 — inventory the old trust surface

Find every place DCT still exists:

DOCKER_CONTENT_TRUST in CI or shell profiles,
docker trust commands in release scripts,
Notary server dependencies,
delegation keys in local runners or secrets stores,
and policy checks that assume tag-level trust.

Treat this as a dependency graph exercise, not a command grep. The highest-risk DCT dependency is usually the one hidden inside an old release template nobody thinks about.

Phase 2 — choose one primary verification contract

Decide which question your new system will answer by default:

Sigstore lane: “Was this artifact signed by the expected workload identity under the expected issuer, with valid transparency evidence?”[4][5]
Notation lane: “Was this artifact signed under a certificate and trust policy we explicitly allow in our registry and deployment controls?”[3][6][7]

You can support both in the estate, but each environment should have one default answer or the review burden explodes.

Phase 3 — dual-sign before you dual-enforce

For a controlled period, sign new release candidates on the new lane while leaving old pull behavior functional where necessary. The purpose is not permanent coexistence. The purpose is to collect verification evidence before admission rules become blocking.

Success criteria are practical:

signing works in unattended CI,
verify commands run against digest references,
policy owners can explain why a signature passes,
and emergency rollback does not require restoring retired DCT secrets.

Phase 4 — cut enforcement, then retire DCT artifacts

Once verification passes in CI and preproduction admission, remove DCT from pull/build environments, disable registry-side DCT where your platform exposes the switch, and retire unused delegation material.[2][3]

The final state should be boring:

no production pull path depends on DOCKER_CONTENT_TRUST,
no release decision depends on mutable tags alone,
and signing material or signing identity is owned by the same team that owns deployment trust policy.

A good falsifier before you promise a fast migration

If your environment is heavily air-gapped, your registry or admission layer still lacks the signature-referrer support you need, or your security process cannot yet approve either OIDC identity policy or certificate trust-store policy, then a fast cutover thesis is false.

In that case, do not disguise an architecture gap as a tooling task. First settle the verification authority model, then choose the CLI.

What to watch over the next quarter

Residual DCT dependencies that only appear during hotfix or rollback flows.[1][2]
Digest-first verification discipline in CI, registries, and admission controls.[5][7]
Trust-policy ownership: identity issuer rules for Sigstore, or certificate/trust-store governance for Notation.[4][6][7]
Cloud platform timelines such as ACR’s 2028 DCT removal window.[3]

Bottom line

A good DCT migration does not ask which new signing CLI feels familiar. It asks which verification contract you want to own in production.

If your organization is already identity-centric, Sigstore is usually the cleaner lane. If it is certificate- and policy-centric, Notation will often fit better. In both cases, the durable upgrade is the same: move trust decisions onto digest-based verification and make the signer identity or certificate policy explicit.

cronfeed.work