Signing containers and OCI artifacts: Notation, Cosign, and why the trust model is the real decision

Every container image you run is a piece of software you are trusting blindly unless you have done something to verify it. It came from a registry, it passed through a build pipeline, and somewhere along that path anyone with access could have swapped it for something else. Container signing is how you close that gap. You attach a cryptographic signature to an image, and your cluster refuses to run anything that does not carry a valid one.

For a long time this was a nice-to-have that security-minded teams did and everyone else postponed. That is changing fast. Regulation like the EU’s Cyber Resilience Act and frameworks like Supply Chain Levels for Software Artifacts (SLSA), developed by Google, are pushing supply-chain integrity up the priority list, and for organizations shipping containerized software, signed images with enforced verification have become a 2026 priority rather than a someday project.

Two tools dominate the conversation: Notation, from the CNCF Notary Project, and Cosign, from the Sigstore project. People tend to frame the choice as a feature comparison. It is more useful to understand it as a choice between two different models of trust, because that is what actually determines which one fits your organization.

Container image signing, defined: attaching a cryptographic signature to an OCI image or artifact, stored alongside it in the registry via the OCI 1.1 Referrers API, so an admission controller or runtime can verify the image’s origin and integrity against a defined trust policy before allowing it to run, using either an identity-based keyless model (Cosign/Sigstore) or a certificate-based PKI model (Notation).

Key Takeaways

• Cosign and Notation both sign OCI artifacts and store signatures in the registry via the same OCI 1.1 Referrers API; the real difference is where trust is rooted, an OIDC identity for Cosign’s keyless mode, or a certificate authority you control for Notation.
• A signature that nothing verifies provides no protection; admission control has to reach enforce mode, not stay in audit mode indefinitely, for signing to actually matter.
• This is the canonical comparison page for the container-signing cluster. For the implementation walkthrough, see Modern Strategies for Signing and Verifying Container Images with CodeSign Secure.
• The tools aren’t mutually exclusive; some organizations sign with Cosign in CI for speed and with Notation for formal release signing, requiring both before deployment.

What the Two Tools Have in Common

Before the differences, it helps to see the shared foundation, because it is larger than you might expect.

Both Notation and Cosign sign OCI artifacts, not just container images. Both store the signature in your registry as a separate artifact attached to the image, using the OCI 1.1 Referrers API, so the signature travels with the image and does not need a separate database. Both verify against a digest rather than a tag, which matters because tags can be moved and a digest cannot. And both plug into the same enforcement layer in Kubernetes, so whichever you choose, you can gate deployments on a valid signature.

In fact the two can coexist on the same image. Some organizations sign with Cosign in their CI pipeline for convenience and sign again with Notation for formal release signing, then require both signatures before anything deploys. The tools are not mutually exclusive. But for most teams picking a primary approach, the trust model is where the decision gets made.

Cosign: Identity-Based, Keyless, and Fast to Adopt

Cosign’s headline feature is keyless signing, and it is genuinely clever. Instead of managing a long-lived signing key, the signer authenticates through an OIDC identity provider, the same kind of login your CI system already has. A Sigstore service called Fulcio issues a short-lived X.509 certificate, valid for about 10 minutes, binding that identity to an ephemeral key pair. Both the signature and the certificate are logged to a transparency log called Rekor, creating a verifiable record of who signed and when, even after the key is gone.

The appeal is obvious. There is no signing key to store, rotate, protect, or lose, because the key never persists. For a team without a dedicated PKI function, this removes the single hardest part of signing. Cosign also has first-class support for attaching SBOMs and SLSA provenance attestations, and the broadest ecosystem of Kubernetes enforcement tooling around it. If you are building a modern provenance-and-attestation pipeline and want to move quickly, Cosign is often the fastest path.

The tradeoff is the trust model itself. Keyless signing binds trust to an identity verified by an external OIDC provider, and in its default form it leans on Sigstore’s public infrastructure. You can self-host Fulcio and Rekor to bring that in-house, but doing so is real operational work. And identity-based trust, while powerful, is a different thing from the key-custody model that many compliance regimes were written around.

Notation: Enterprise PKI and Keys You Control

Notation takes the approach that large enterprises have used for code signing for decades. You sign with an X.509 certificate issued by a certificate authority you trust, typically your own, and verification checks the signature against that CA through a trust policy you define. The signatures use the COSE format and, like Cosign, are stored as OCI artifacts in the registry. Notation’s trust policies can be scoped finely, to specific registries, repositories, or identities, which suits organizations that need delegated and segmented signing authority.

What makes Notation the natural fit for a regulated enterprise is exactly this rooting in your own PKI. The signing key is a long-lived organizational asset under your control, not an ephemeral credential tied to an external identity service. Notation’s plugin model integrates with key management systems and hardware security modules, so the signing key can live in an HSM and never leave it. For organizations with compliance requirements around key custody, the kind that come with FIPS validation or FedRAMP, that hardware-backed, organization-controlled key is often the only model that clears the bar. It also fits cleanly into environments where external public infrastructure is off the table but an internal CA already exists.

The cost, relative to keyless Cosign, is that you are back to managing keys and a PKI. That is a real responsibility. But for an enterprise that already runs PKI, it is not new work, it is existing capability applied to a new surface, and it gives you a trust model that maps directly onto how your auditors already think. Certificate revocation is handled through standard PKI mechanisms such as CRL or OCSP, which means a compromised signing certificate can be revoked and images signed with it can be flagged or blocked by updating your trust policy. That maps directly onto how enterprise security teams already handle code-signing certificate incidents.

Cosign vs. Notation: Side by Side

Aspect	Cosign (Sigstore)	Notation (Notary Project)
Trust root	OIDC identity, verified via short-lived Fulcio certificate	X.509 certificate from a CA you control
Key lifecycle	Ephemeral by default (keyless); long-lived key optional	Long-lived organizational key, typically HSM-backed
Transparency	Every signing event logged to Rekor by default	No built-in public transparency log
Revocation	N/A for keyless (certificate expires in ~10 minutes); Rekor provides an audit record instead	Standard PKI mechanisms: CRL or OCSP
Attestation support	First-class: SBOM and SLSA provenance via cosign attest / verify-attestation	Supported via COSE-signed artifacts, less ecosystem tooling around it
Best fit	Teams without an existing PKI function wanting fast adoption and rich attestation tooling	Regulated enterprises with FIPS/FedRAMP key-custody requirements and an existing CA

Verification Commands

Concepts aside, here is what actually runs at the verification step for each tool. Confirm current syntax against each project’s own documentation before scripting these into a pipeline, since both tools have changed flags across major versions.

Cosign

Keyless verification, checking against a specific signer identity and OIDC issuer:

cosign verify <image URI> \
  [email protected] \
  --certificate-oidc-issuer=https://accounts.example.com

Key-based verification, checking against a stored public key:

cosign verify --key <key path>|<key url>|<kms uri> <image uri>

Verifying a SLSA provenance attestation specifically, rather than just the signature:

cosign verify-attestation --type slsaprovenance \
  --certificate-identity="${IDENTITY}" \
  --certificate-oidc-issuer="${ISSUER}" \
  "${IMAGE_DIGEST}"

A successful verification exits with status 0 and, on recent Cosign versions, reports the verified claims and confirms transparency log inclusion; a failed one exits non-zero and names the specific check that failed (identity mismatch, missing transparency log entry, or signature mismatch).

Notation

Notation verification depends on a trust store and trust policy being configured first, via notation cert add and notation policy import; there’s no equivalent of Cosign’s zero-configuration keyless path. Once configured:

notation verify <IMAGE>

Add -v for verbose output, which prints the trust policy being evaluated, including the trust store and trusted identities, useful for diagnosing why a verification failed rather than just that it failed. A missing or misconfigured trust store produces a specific, named error rather than a silent failure.

Decision Criteria

1. Do you already operate a PKI and have FIPS or FedRAMP obligations around key custody? If yes, Notation’s certificate-rooted model maps directly onto what auditors expect.
2. Do you want to avoid running signing key infrastructure at all? Cosign’s keyless mode removes key storage and rotation entirely, at the cost of depending on Sigstore’s public infrastructure (or self-hosting Fulcio/Rekor).
3. Do you need SBOM or SLSA provenance attestations as a first-class part of the pipeline? Cosign’s attestation tooling is the more mature ecosystem today.
4. Do different pipeline stages have different trust needs? Consider both: Cosign for fast CI-stage signing, Notation for a formal release gate, requiring both before deployment.

The Part People Forget: Signing is Only Half the Job

Here is the mistake that quietly undermines a lot of signing efforts. A signature on an image does nothing on its own. If nothing in your cluster checks it, an unsigned or tampered image runs exactly as easily as a signed one. The security only exists at the moment of enforcement.

Enforcement in Kubernetes happens through admission control, and it pays to think of it in layers. A pre-deployment gate, implemented with an admission controller such as Kyverno, the Sigstore Policy Controller, or OPA Gatekeeper paired with Ratify, inspects every image as it is about to be admitted and rejects anything without a valid signature against your policy.

The runtime can add a second layer: newer versions of containerd support an image verifier that checks signatures at pull time, before an image is allowed to run on a node. Beyond that, a promotion gate can require a valid signature before an image moves from staging into the production registry, and periodic runtime audits can confirm that what is already running still verifies against current policy.

These admission controllers generally run in one of two modes, and the difference matters more than it sounds. In audit mode, a failed verification produces a warning but the image still deploys. In enforce mode, a failed verification blocks the deployment outright. Audit mode is the right place to start, so you can see what would be rejected without breaking anything, but audit mode is not protection.

The whole point of signing is to reach enforce mode with confidence, and getting there safely means rolling out policy gradually, namespace by namespace, with your signing pipeline reliable enough that legitimate images never fail.

This is also where the choice of tool meets reality. Whichever you pick, the signatures only deliver value once the enforcement layer is live, tuned, and trusted enough to actually block. A signing program that never graduates from audit mode is theater.

How Encryption Consulting Can Help

Standing up container signing that satisfies CRA and SLSA pressure is partly a tooling decision and partly a question of where your trust actually lives. For most enterprises, the answer points toward signing rooted in PKI you control, with keys protected in hardware, and that is squarely what we do.

CodeSign Secure, our code signing solution, gives you a governed signing process for your software artifacts, including container images, with the policy controls, access governance, and key protection that a Notation-style, PKI-backed approach depends on. Instead of signing keys scattered across CI runners and developer machines, signing runs through a controlled system with a clear audit trail, which is exactly the posture auditors and supply-chain frameworks expect to see.

What Codesign Secure Brings to Container Signing

This post has spent most of its time on Notation and Cosign, so it is worth being concrete about what our own platform adds, because a trust model is only as good as the signing process wrapped around it. CodeSign Secure is a centralized signing platform built for modern DevOps environments.

It integrates with the CI/CD systems most teams already run, including Azure DevOps, Jenkins, and GitLab, and it puts every signing operation behind access controls and approval workflows so that signing stays governed rather than scattered across build agents.

Signing keys stay in a FIPS 140-2 Level 3 hardware security module, and the platform works with the HSMs enterprises already deploy, including Entrust nCipher, Thales Luna, Utimaco, and Securosys, whether on-premises or in the cloud. Access is governed through integration with Microsoft Active Directory and Keycloak, with role-based access control and customizable workflows.

Policies are enforced at the platform level, so nothing is signed unless it meets the criteria you define, from the certificate type to the approvals required at each stage. Separation of duties is built in, since a developer can request a signature but a release manager or security officer has to approve it before the signature is applied, which removes the risk of a single compromised account signing and shipping software on its own.

Because it signs a wide range of formats, including Docker containers and OCI images alongside firmware binaries, executables, and packages, it fits the container-signing case this post is about as well as the rest of an organization’s signing needs, and it plugs into common tooling such as Signtool, Jarsigner, and JSign.

It uses client-side hashing and secure timestamping so signatures stay valid even after a certificate expires, and it records each signing event, along with the approvals and denials behind it, in audit logs that feed SIEM tools such as Grafana, Loki, and Splunk through OpenTelemetry. That gives security teams the evidence trail that supply-chain frameworks expect to see.

It can run as a fully managed cloud service with built-in HSM security or on-premises with keys held in cloud or on-prem HSMs, so the deployment model can match your constraints. It also signs with post-quantum algorithms directly on the HSM, including ML-DSA (Module-Lattice-Based Digital Signature Algorithm) and LMS (Leighton-Micali Signatures), and it supports dual signatures that pair a classical RSA or ECDSA signature with a post-quantum one for a gradual transition.

Because enterprise image signing is only as trustworthy as the certificate authority behind it, PKI-as-a-Service gives you a modern, well-run CA to issue and manage the signing certificates that anchor your trust policy, without the burden of building and maintaining that infrastructure yourself. This is the root of trust that a Notation deployment verifies against, and getting it right is what makes the whole chain credible.

To protect the signing keys themselves, HSM-as-a-Service keeps them isolated in a hardware security module, so a signing key cannot be copied off a build server or extracted from a pipeline. For organizations with FIPS or FedRAMP obligations around key custody, hardware-backed keys are typically not optional, and pairing them with your signing workflow is what lets you meet those requirements rather than work around them.

If you are deciding how to sign your container images and where to root the trust, or you want help taking a signing program all the way to enforced verification, get in touch. We can help you design it and build the PKI and key protection underneath it.

Frequently Asked Questions

Can I use both Cosign and Notation on the same image?

Yes. Both store signatures as separate OCI artifacts attached to the same image digest, so they coexist without conflict. Some organizations sign with Cosign in CI for speed and require a second Notation signature at a formal release gate.

Does Cosign’s keyless signing mean there’s no key at all?

There’s still an ephemeral key pair, generated fresh for each signing operation and valid for roughly 10 minutes, bound to an OIDC identity via a short-lived Fulcio certificate. Nothing persists afterward; the record that the signing happened lives in the Rekor transparency log instead.

Why doesn’t Cosign have certificate revocation the way Notation does?

Because there’s no long-lived certificate to revoke; the certificate expires on its own within minutes of issuance. Instead, Rekor’s transparency log lets you audit exactly when and by whom a signature was created, which serves a similar accountability purpose through a different mechanism.

What happens if my admission controller is only in audit mode?

Unsigned or invalid images still deploy; a failed check only produces a warning. Audit mode is useful for rolling out policy without breaking existing deployments, but it provides no actual protection until it moves to enforce mode.

Do I need a registry that supports OCI 1.1 for either tool?

Both tools rely on the OCI 1.1 Referrers API to attach signatures to images without a separate database. Confirm your registry’s support for this API before committing to either tool for production use.

Conclusion

The Notation-versus-Cosign question is not really about which tool has more features. It is about which model of trust fits your organization. Cosign’s keyless signing is fast to adopt and excellent for modern, attestation-rich pipelines, especially for teams that would rather not run a PKI at all. Notation’s enterprise-PKI approach fits organizations that already manage certificates, need keys they control and can place in hardware, and answer to compliance regimes built around key custody. Many organizations end up using both, for different stages of the same pipeline.

Whatever you choose, two things hold. The signature has to be rooted in a trust model you can stand behind, and it has to be enforced at admission, not merely produced and forgotten. A signed image that nothing verifies is no safer than an unsigned one.

Supply-chain regulation is not going to loosen, and the pressure to prove where your software came from will only grow. The organizations that set up signing and enforcement deliberately this year, with their trust anchored in infrastructure they control, are the ones who will treat the next compliance requirement as a box already checked rather than a fire to fight.