Share via

Implementing Verifiable Zero-Trust in Azure Managed Applications with ReadOnly LockLevel

Brin Soko 20 Reputation points
2026-03-20T15:41:36.22+00:00

Hello,

I am developing an Azure Managed Application (Service Catalog/Marketplace) for a GPU-based Speech-to-Text (STT) engine. We have two strict requirements for a "Black Box" deployment:

IP Protection: The customer (consumer) must not be able to access the code, binaries, or model weights. We are using lockLevel: ReadOnly on the Managed Resource Group to enforce this via Deny Assignments.

Publisher Zero-Trust: Because the application processes highly sensitive personal audio data, the customer requires proof that we (the publisher) have zero standing access to the Managed Resource Group once deployed.

The Problem: When I attempt to set authorizations: [] (empty array) in the applicationDefinition to ensure the publisher has no access, the deployment fails with the error: MissingApplicationAuthorizations: The application authorizations is required if lock level is ReadOnly.

It appears Azure Resource Manager mandates at least one authorization entry when a lock is present.

My Questions:

How can I satisfy the ARM validation requirement for authorizations while providing the customer with verifiable proof that the publisher cannot access their data?

Is it a supported pattern to use a "Null GUID" (e.g., 00000000-0000-0000-0000-000000000000) or a non-existent Principal ID in the authorizations array to achieve a "Locked-Out Publisher" state?

Are there specific best practices for "Zero-Trust" Managed Apps where the publisher is intentionally locked out of the data plane, but the app still requires a ReadOnly lock on the control plane to protect intellectual property?

Environment Details:

Resources: Azure Container Apps (GPU Workload Profiles), Private ACR.

Lock Level: ReadOnly

Deployment: Service Catalog / Azure Marketplace.

Any guidance on the recommended architecture for this "Double-Locked" (Publisher out, Customer restricted) scenario would be greatly appreciated.

Azure Advisor
Azure Advisor

An Azure personalized recommendation engine that helps users follow best practices to optimize Azure deployments.

0 comments
Answer accepted by question author
  1. Suchitra Suregaunkar 11,150 Reputation points Microsoft External Staff Moderator
    2026-03-21T01:00:57.9533333+00:00

    Hello Brin Soko ARM really does insist on at least one valid principal in the authorizations array whenever you set lockLevel: ReadOnly. There’s no “null GUID” or magic placeholder that will pass validation, because ARM does a lookup in Microsoft Entra ID to make sure the object exists. That said, you can satisfy the requirement while still giving your customer proof that you (the publisher) have zero standing access:

    1. Use a harmless identity in your authorizations : • Add your managed-app’s own managed identity (system-assigned or user-assigned) to the applicationDefinition.authorizations array. • By itself, listing the identity here does not grant any data-plane rights. You control its RBAC assignments on the managed RG. • After deployment, show the customer (via the IAM blade or az role assignment list) that this identity has no Reader/Contributor roles on any resource in the managed RG.
    2. Alternatively, create a “dummy” AAD service principal • Register an AAD app/SP solely to satisfy the non-empty authorizations requirement. • Put its objectId in applicationDefinition.authorizations. • Give it zero RBAC assignments on the managed RG (or explicitly add a Deny assignment). • The SP exists for ARM validation but cannot do anything in the data plane.

    Neither of these patterns violate ARM’s validation, and both let you prove to your customer that no real publisher principal can read or modify their deployed resources.

    Best practices for your “double-locked” scenario:

    • Keep your intellectual-property lock on the managed RG as a ReadOnly lock + Deny assignments to block the customer from poking around.

    • Enforce the zero-trust requirement with RBAC + Deny assignments for the publisher principal you listed (so you can demonstrate “no access” post-deploy).

    • If you ever need to update or patch the managed app, temporarily grant that identity minimal rights, run your update, then remove the role again to return to zero-trust.

    • Share a short script or screenshot of the managed RG’s Access control (IAM) blade showing no publisher assignments—that’s your “verifiable proof.”

    Reference list:

    Thanks,

    Suchitra.

    1 person found this answer helpful.
    0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2026-03-20T15:42:05.56+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    Azure Managed Applications with lockLevel: ReadOnly require at least one authorizations entry. The authorization defines which principal gets a role on the managed resource group and is exempt from the ReadOnly deny assignment.

    From the managed application definition perspective:

    • lockLevel: ReadOnly prevents the customer from performing undesirable operations on the managed resource group. The customer can only read resources in that group.
    • The identities specified in authorizations are exempt from that lock and receive the role (for example, Owner or Contributor) on the managed resource group.
    • When lockLevel is ReadOnly, authorizations is required; an empty array is not allowed.

    There is no documented pattern in the provided material that supports using a null GUID or a non-existent principal ID in authorizations. The documentation instead states that authorizations must describe a real principal ID and role definition ID that are used to grant permission to the managed resource group.

    For a Zero Trust posture and shared-responsibility alignment:

    • Zero Trust guidance emphasizes eliminating standing privileged access and using just-in-time access, least privilege, and strong identity verification.
    • For managed applications, the publisher can request either permanent role assignment or just-in-time access, or configure the managed application so that there is no publisher access.
    • The managed resource group is in the customer’s subscription; access to it is governed by Azure RBAC and deny assignments. The customer can change access later (for example, remove publisher access) because they own the subscription and can modify role assignments and deny assignments according to their governance.

    Given the context:

    1. To satisfy ARM validation with lockLevel: ReadOnly, at least one valid authorization entry must be provided at definition time.
    2. The identities in authorizations are exempt from the ReadOnly lock; they are intended to be real principals with roles such as Owner or Contributor.
    3. The documentation does not describe or endorse using a null GUID or non-existent principal ID as a way to create a “locked-out publisher” state.
    4. Zero Trust and secure isolation guidance focus on:
      • Using Azure RBAC for least privilege.
      • Using just-in-time access instead of standing access.
      • Applying locks and deny assignments to protect critical resources.

    To provide verifiable assurance of no standing publisher access, the supported approach in this material is to rely on Azure RBAC and deny assignments in the customer’s subscription (for example, by removing or not granting publisher role assignments after deployment, or using just-in-time access rather than permanent roles), rather than attempting to bypass the authorizations requirement with invalid principals.

    References:

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.