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.
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.
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.
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.
