Azure Container Registry's trusted images feature, combined with notation-based signing and the new image integrity preview on AKS, finally gives Azure customers a deploy-time policy they can actually enforce. Until 2024, the only practical Azure-native option was a custom admission controller and a hand-rolled signature verification path. The 2026 picture is different, and the rollout pattern is now stable enough to be repeatable.
I have led two ACR trusted images rollouts in the last nine months, both in Azure-heavy enterprises with mixed AKS, App Service, and Container Apps workloads. The patterns that work are clean. The patterns that break are usually about workload migration timing, not about the signing technology itself.
Why are ACR trusted images the right starting point in 2026?
Because the feature integrates with AKS image integrity, App Service container deployment, and Container Apps revision management, all without a third-party admission controller. The verification happens inside the Azure platform, with the customer's notation public keys bound to the registry, and the policy decision is logged in Azure Activity Log alongside every other Azure operation.
The 2024 version of this story required a Kyverno or Gatekeeper deployment on AKS, a custom Lambda or Function App on App Service, and a manual deploy script on Container Apps. The 2026 version is a single notation key bound to ACR, a single image integrity policy on AKS, and platform-native enforcement everywhere else. The operational simplification is significant, and it removes most of the failure modes that broke earlier rollouts.
That said, the platform-native enforcement is not turned on by default. The customer has to bind the notation public key to the registry, configure the trusted images policy on the registry, and enable image integrity on each AKS cluster. None of those steps is hard, but missing any of them leaves the policy unenforced even if the signing pipeline is producing signatures.
How do I plan the rollout phases?
Three phases, the same as any signing rollout: sign-only, verify-warn, verify-enforce. The Azure-specific wrinkle is that the verify-warn phase looks different on each compute target — AKS has a native warn mode via image integrity, App Service does not, and Container Apps verifies at revision activation time. The phase planning has to account for the heterogeneity.
The sign-only phase adds the notation sign step to every pipeline that publishes to ACR, and verifies that the signature lands in the registry alongside the image. The output of this phase is a complete inventory of signed images per repository, and a list of pipelines that are not yet signing. The list drives remediation in the next phase.
The verify-warn phase enables verification on AKS image integrity in audit mode, and runs a side-channel verification on App Service and Container Apps deploy paths that logs failures without blocking. The output is a complete inventory of deploy paths that would fail enforcement, which is the work list for the verify-enforce phase.
The verify-enforce phase flips AKS image integrity to enforce mode, switches the App Service and Container Apps deploy verification from logging to blocking, and turns on the trusted images policy on the registry. By the time you get here, the failure inventory should be near zero, and the move is uneventful.
How do I configure notation signing in the build pipeline?
Use the notation Azure CLI extension with a Key Vault-backed signing key, and run the sign step in an Azure DevOps pipeline that has been federated to a workload identity. The Key Vault key is rotatable, audited, and never leaves the Vault. The federation eliminates any long-lived credential in the pipeline configuration.
The pattern is straightforward. The pipeline builds the image, pushes it to ACR, and runs notation sign with the Key Vault key reference and the image reference. The signature is stored as an OCI artifact attached to the image manifest in ACR. The signing operation is logged in Key Vault's audit log, and the signed image's digest is recorded in the pipeline's run summary.
The per-pipeline key requirement applies the same as on AWS. A single signing key for the whole tenant is operationally simple and a security liability. A per-pipeline key contains the blast radius, and Azure Key Vault makes it cheap to operate dozens of keys with appropriate rotation policies.
The rotation policy is the part most rollouts skip. Notation supports multiple valid keys per registry — the verification side accepts any key in the configured trust policy. Rotation is therefore a simple matter of issuing a new key, adding it to the trust policy, switching the pipeline to use it, and removing the old key from the trust policy after the legacy images have been re-signed or aged out. Build the rotation into the rollout from day one; retrofitting it later is harder.
What does the AKS image integrity policy look like in production?
A trust policy that lists the registry, the trusted notation keys, and the image patterns that the policy applies to. The policy is bound to the AKS cluster via the image integrity feature, and the cluster's admission path verifies signatures on every pull. A pull whose signature does not verify against any key in the policy is rejected, and the rejection is logged in Azure Monitor.
The pattern that breaks rollouts is the wildcard image pattern. A policy that says "all images from this registry must be signed by this key" is too strict if the registry contains both signed and legacy unsigned images. The fix is to be specific about the image patterns the policy applies to, and to allow legacy unsigned images via an explicit exception list with a deadline.
The exception list management is the part that needs continuous attention. Every legacy image in the exception list is a work item, and the deadline on the list is the forcing function that gets the work done. Without a deadline, the exception list becomes permanent, and the policy provides theatre rather than security.
What about the App Service and Container Apps deploy paths?
App Service container deployment does not have a native admission controller, so the verification has to happen in the deploy pipeline before the deploy command is issued. Container Apps verifies at revision activation, and the verification is configured as part of the revision template.
The App Service path is a simple notation verify call in the deploy step, with the trust policy passed as a flag and the registry credentials picked up from the workload identity. A non-zero exit code fails the deploy. The pattern works, it is well-documented, and it is the right shape for App Service.
The Container Apps path uses the platform's revision management. A new revision is created with the signed image reference, the platform verifies the signature against the configured trust policy, and the revision either activates or fails activation. The activation log is the audit trail. For Container Apps, this is more native than App Service, and the pattern is closer to AKS image integrity.
How Safeguard Helps
Safeguard verifies notation signatures on every ACR image at scan time, regardless of whether the image is currently deployed, and produces a continuous posture signal that maps signed images to deployed AKS, App Service, and Container Apps workloads. The signal flags images that are deployed but not signed, signed by an unrecognised key, or signed by a key that has been rotated out of the trust policy.
Griffin AI generates per-pipeline Key Vault signing keys, notation sign steps in Azure Pipelines, AKS image integrity policies, and App Service deploy verification scripts from an existing ACR deployment, then opens pull requests against the customer's IaC repo to roll the changes out. The PR-driven workflow makes the rollout tractable in tenants with hundreds of pipelines.
Safeguard's SBOM module attaches an in-toto attestation to every ACR image alongside the notation signature, the TPRM module tracks the trust state of every base image and dependency the build consumes, and the policy gate module integrates with Azure DevOps approval checks so a pipeline approval can be wired to a Safeguard policy decision. The phase-progression dashboard is built into the platform, so the rollout's progress is data-driven rather than guesswork.
For Azure customers running multiple subscriptions, Safeguard rolls up trusted-images posture across all subscriptions, with a single view of which workloads are out of policy and a single workflow for getting them into policy.