Intune Multi-Admin Approval and Graph API: why your scripts are failing and how to fix them

Many IT teams only noticed when an automated task failed: a pipeline deploying apps in Intune or a PowerShell script managing devices suddenly returned an HTTP 403 error. Not a permissions problem, not an expired certificate, but a security feature that was quietly extended in Intune service release 2606 from June 2026: Multi-Admin Approval. What until then applied exclusively to interactive actions in the admin console now also applies to calls made via the Microsoft Graph API.

What is Multi-Admin Approval in Intune?

Multi-Admin Approval, abbreviated MAA, is a security layer in Microsoft Intune that requires a second administrator to approve certain write actions before they take effect. The principle is comparable to a four-eyes principle in financial processes: nobody can change sensitive configurations on their own without a colleague with the right role first reviewing and approving the action.

In practice it works like this: an administrator wants to deploy a script or update an application deployment. As soon as that action falls within a configured MAA access policy, the change is not applied immediately but placed in a queue. Another administrator receives a notification and must approve or reject the action before it takes effect. This prevents a single mistake or a malicious actor with access to an admin account from causing irreversible damage.

What changed in service release 2606?

Before June 2026, MAA applied exclusively to human administrators working manually in the Intune Admin Center. Automation solutions fell outside that protection: PowerShell scripts via Azure Automation, GitHub Actions workflows rolling out configuration profiles, Terraform configurations managing Intune resources, or custom applications calling the Graph API. That blind spot was closed with service release 2606.

From that release onward, MAA also intercepts application-authenticated API calls — requests made via a service principal or an app registration in Entra ID. If the target resource, an application, a script, a device configuration profile, is protected by an MAA access policy, the call is no longer silently applied but placed in an approval flow. Scripts that do not expect this receive an HTTP 403 with the error code ApprovalRequired.

Which automation is affected?

The impact is limited to write operations: POST, PATCH, PUT, and DELETE via the Graph API on resources covered by an MAA policy. Read operations, all GET calls, are never intercepted by MAA. Monitoring scripts, reporting tools, and queries retrieving device information continue to work without interruption.

What can be affected are automation scenarios where Intune resources are modified. Think of PowerShell scripts in Azure Automation or via a DevOps platform that deploy, update, or remove apps. CI/CD pipelines rolling out device configuration profiles or compliance policies. Third-party tooling using the Intune Graph API for workflow automation. And custom scripts that retire or delete devices based on compliance status.

Importantly, the impact only occurs if your tenant has an MAA access policy configured for the relevant Intune resources. If you have never set up MAA, nothing changes for your automation. If MAA is active but only for a limited set of resources, only the pipelines that modify those specific resources are affected.

How does the new approval flow work technically?

Microsoft extended the Graph API with a two-step flow for MAA-intercepted calls. In the first step, your script sends the original request including an additional header: x-msft-approval-justification, filled with a Base64-encoded description of why the action is necessary. If the target resource is protected, the server responds with an HTTP 412 Precondition Required, or in some configurations the familiar HTTP 403 with error code ApprovalRequired. The response headers contain an x-msft-approval-code: a unique request ID that your script must store.

In the second step, another administrator with approval rights must approve the request in the Intune Admin Center, under Tenant administration > Multi Admin Approval > Pending requests. Once approved, the script can repeat the original request, now with the x-msft-approval-code header replacing the justification header. The API then carries out the action.

For pipelines where a human approver mid-execution is not feasible — think of nightly batch deployment scripts or automated incident response — this is a practical problem. The pipeline cannot wait indefinitely for someone to click in a portal. Two solutions address this.

Two practical solutions

Solution one: exclude your service principal from the MAA policy. For trusted automation accounts, this is the most pragmatic approach. In the MAA access policy, you can designate specific app registrations as excluded. MAA then remains in force for human administrators working manually in the console, while your automation service principal performs write operations without interruption. Add compensating controls: restrict the app registration strictly to the minimum required Graph permissions and ensure all calls are visible in the Entra ID audit logs. Document the decision and have the exclusion reviewed annually.

Solution two: make your scripts MAA-aware. If you prefer not to set the exclusion, or if MAA must also apply to certain automation scenarios, adapt the script to support the two-step flow. Add an x-msft-approval-justification header to each write operation, capture the 412 response, store the approval code, send a notification to the approver via Teams or email, and retry the action once approval is confirmed. This requires more development work but gives the most complete MAA integration.

What to check right now

First step: verify whether your tenant has an MAA access policy configured. Go to the Microsoft Intune Admin Center, choose Tenant administration, then Multi Admin Approval, and review which resources are protected. If no policy is set up, there is no urgent action needed for your existing automation.

Second step: inventory which automation solutions perform write operations on protected Intune resources. Review Azure Automation jobs, GitHub Actions workflows, and scripts on other DevOps platforms for Graph API calls using POST, PATCH, PUT, or DELETE targeting Intune endpoints. Test these scripts in an acceptance environment if you are unsure whether they are affected.

Third step: decide per service principal whether to use exclusion or script logic changes, document the decision, and record the risk assessment. An exclusion is safe as long as the app registration has minimal permissions and audit logging is active. Manage exclusions centrally so they are not forgotten during future policy changes. Want help assessing your Intune automation or correctly configuring MAA for your environment? Contact Zarioh for a no-obligation conversation.