Azure Artifacts is the package feed of choice for many Microsoft-shop engineering organizations, and Sigstore has become the de facto standard for keyless artifact signing. Joining the two is more complicated than it should be in 2026, but the path is well-trodden enough now to document the working pattern.
Why bother adding Sigstore to Azure Artifacts?
Azure Artifacts provides authenticated access and feed-level permissions, which is useful but does not give you cryptographic proof of artifact provenance. If your Azure DevOps tenant is compromised, or if an insider with feed write access pushes a malicious package, the consumer of that package has no independent way to verify the artifact came from your trusted build pipeline. Sigstore solves this with keyless signing against a transparent log, Rekor, anchored to the OIDC identity of your CI pipeline. The downstream verifier checks that the artifact was signed by the expected workload identity and the signature is present in the public log. Microsoft introduced native Sigstore support for some artifact types in Azure DevOps in late 2025, but coverage is uneven across npm, NuGet, Maven, and Python feeds. The walkthrough below assumes you are filling those gaps yourself.
What is the signing pipeline structure?
The working pattern is to sign artifacts in your Azure Pipelines build job using cosign with OIDC token issuance from the pipeline's federated identity. The build job authenticates to Sigstore's Fulcio CA with the Azure-issued OIDC token, receives a short-lived signing certificate tied to the pipeline identity, signs the artifact, and pushes both the artifact and the signature bundle to Azure Artifacts. The signature bundle includes the certificate, the signature, and a Rekor inclusion proof, and it is published as a sidecar artifact in the same feed. For npm and Python packages, the bundle is attached via the package metadata. For NuGet, the bundle currently has to be uploaded as a separate file with a parallel naming convention, which is the most awkward part of the integration. Maven is the cleanest because Sigstore's Maven plugin handles bundle attachment natively.
How do you handle verification at consumption time?
Verification is the half that organizations underestimate, because signing without verifying is theatrical. The consumption-side change has to happen in every project that pulls from the signed feed, and the cosign verify step has to be wired into the install workflow. For NuGet, this typically means a wrapper around dotnet restore that downloads the sidecar bundle and verifies before restore proceeds. For npm, the npm install --integrity flag combined with a Sigstore verifier plugin works for packages with embedded bundles. The verification policy should pin to the expected pipeline identity, not just any Sigstore signature, because the keyless model means anyone with an OIDC token can produce a valid signature. The expected identity for a typical Azure DevOps pipeline takes the form of https://vstoken.dev.azure.com/{tenant-id}, and the workflow identity within that tenant. Get this policy wrong and you have signed artifacts that anyone in the world could have produced.
What are the common pitfalls in production?
The first pitfall is OIDC token lifetime versus build duration. Azure-issued tokens are valid for 60 minutes by default, and long builds can exceed that window between signing setup and signature submission. The fix is to issue the signing certificate as close to the actual sign operation as possible, not at the start of the job. The second pitfall is feed retention policy interactions: Azure Artifacts feeds can be configured to delete old versions, but Sigstore signatures in Rekor are permanent. A retention policy that deletes the artifact but leaves the signature creates a dangling reference, which is harmless but produces verification warnings. The third pitfall is air-gapped or restricted-egress environments where Fulcio and Rekor public endpoints are unreachable. The solution is to run a private Sigstore deployment using the upstream Helm charts, but this is a non-trivial operational commitment and you should budget at least one engineering quarter for production readiness.
How does this fit with SLSA and broader supply chain controls?
Sigstore signing alone gets you to SLSA Level 2: signed provenance produced by a build platform. Reaching SLSA Level 3 requires the additional steps of generating a SLSA provenance attestation alongside the signature, capturing the build inputs, the source revision, and the builder identity. The slsa-github-generator equivalent for Azure does not exist as a single package, but the working pattern is to use slsa-verifier with a custom Azure builder configuration and to publish the in-toto attestation as an additional sidecar artifact. Several teams have published reference templates as of early 2026, and copying from a known-good template is faster than rolling your own. Level 4 requires reproducible builds, which most real-world Azure pipelines cannot achieve without significant rework, and the cost-benefit is rarely justified outside of high-trust scenarios.
How Safeguard Helps
Safeguard ingests Sigstore signatures and SLSA attestations alongside SBOM data, treating provenance as a first-class signal in our supply chain graph. Policy gates can require valid Sigstore signatures with a specific expected identity before a build progresses to deployment, eliminating the gap between signing and verification. Griffin AI flags artifacts where the signing identity does not match the expected pipeline, catching insider risk and tenant compromise. Reachability and CVE data layered on top of provenance gives you a single view: this artifact was signed by the right pipeline, has these reachable CVEs, and is policy-compliant for deployment to this environment. The integration with Azure Artifacts is pre-built, and the verification step lives in a single policy decision rather than scattered across consumer projects.