Intune Multi Admin Approval Now Enforced on Graph API Calls 

With the Intune service release 2606 in June 2026, Microsoft changed something that can break your automation overnight. Multi Admin Approval (MAA) is now also enforced on Microsoft Graph API calls. Until now, only interactive changes in the admin center were intercepted. From now on, PowerShell scripts and automation apps that change protected resources like apps or scripts are intercepted, too. If they don’t handle the new approval flow, they fail with an HTTP 403 error. In this blog post, I explain what changed, why your automation suddenly gets 403 errors, how the approval flow works for API calls, and how you can exclude your automation apps from enforcement. 

What is Multi Admin Approval? 

Multi Admin Approval protects against compromised admin accounts. You create an access policy for a resource type, and from that moment on, every change to that resource type needs a second administrator to approve it. One admin submits the change with a business justification, and a different admin approves or rejects it. An admin can never approve their own request. 

Intune supports access policies for these resource types: 

• Apps (app deployments, not app protection policies) 
• Compliance policies 
• Configuration policies (settings catalog) 
• Device actions (wipe, retire, delete) 
• Role-based access control 
• Scripts (Windows PowerShell scripts) 
• Tenant configuration (device categories) 

Changes to the access policies themselves are always protected as well. You can find everything under Tenant administration > Multi Admin Approval in the Intune admin center. 

What changed in June 2026? 

Before this change, Multi Admin Approval only applied to interactive (delegated) admin actions. A script with an app-only token could create or change protected resources without any approval. That was a real gap, because a compromised app registration could bypass the whole protection. 

With service release 2606, this gap is closed. Application-authenticated (app-auth) API calls through Microsoft Graph are now also intercepted by MAA when the target resource is protected by an access policy. 

Important to know: This is opt-in per workload. Nothing changes if your tenant has no MAA access policies. Enforcement only applies to tenants with configured access policies. It does not automatically enable MAA anywhere. 

Also important: MAA only applies to operations that modify a protected resource (POST, PATCH, PUT, DELETE). Read-only GET requests are not affected. 

Why does my automation get a 403? 

If your script or app calls Microsoft Graph with an app-only token and targets a protected resource, the call no longer goes through directly. Two things can happen: 

1. Without the required justification header, the request fails with an error stating that the x-msft-approval-justification header is required. 
2. With the justification header, the request still returns an HTTP 403, but with the error code ApprovalRequired. This 403 is expected. It’s not a permission problem. It’s how MAA tells you that the request was received and is now waiting for approval. 

So, before you start rotating certificates or adding Graph permissions, check the error body. If you see ApprovalRequired, your permissions are fine, and MAA is doing its job. If you want to decode other Intune and Graph error codes quickly, ErrorHunter, a tool I built, can help: errorhunter.msnugget.com. For a general approach to Intune errors, I also wrote the ultimate Intune troubleshooting guide. 

How does the approval flow work for API calls? 

The flow for automation has four steps. All details are in the official documentation: Use Multi Admin Approval with the Microsoft Graph API. 

Multi Admin Approval flow for Graph API calls with HTTP 403 ApprovalRequired and approval code resubmit 

Submit the request with a justification header. Add the x-msft-approval-justification header to your call. The value must be Base64 encoded. 

1. Handle the 403 response. The response has the error code ApprovalRequired and contains an x-msft-approval-code header with a request ID. Save this code. 

Wait for approval. A different administrator must approve the request in the Intune admin center. Applications can’t approve or reject MAA requests. You can query the status with GET /beta/deviceManagement/operationApprovalRequests?$filter=requestId eq ‘<code>’ and wait until it’ approved. 

2. Resubmit with the approval code. Send the original request again but replace the justification header with the x-msft-approval-code header. Now the request completes. 

Here is a short PowerShell example for step 1 and the 403 detection: 

# Send the change with a Base64-encoded business justification 
$justification = [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("Deploy remediation script v2")) 
$headers = @{ "x-msft-approval-justification" = $justification } 
 
try { 
    Invoke-MgGraphRequest -Method POST -Headers $headers ` 
        -Uri "https://graph.microsoft.com/beta/deviceManagement/deviceManagementScripts" ` 
        -Body $body -ContentType "application/json" 
} 
catch { 
    # A 403 with error code "ApprovalRequired" is expected with MAA. 
    # The request ID is returned in the x-msft-approval-code response header. 
    Write-Warning $_.ErrorDetails.Message 
} 

Hint: This flow needs a human in the loop. A fully unattended pipeline can’t approve itself. So, for pure automation, the exclusion described in the next section is often the more realistic option. 

How do I exclude my automation app? 

If you can’t update your application right away, Microsoft added a new Exclusions tab to the access policy. With it, you can exclude specific applications from Multi Admin Approval enforcement. 

Multi Admin Approval access policy Exclusions tab with an automation app pending second admin approval 

The steps are simple: 

1. Go to Tenant administration > Multi Admin Approval > Access policies. 
2. Edit the access policy for the workload your app calls. 
3. Add the application on the Exclusions tab. 
4. A second administrator must approve this change before the exclusion takes effect. 

Note: Exclusions only apply to app-auth calls made by the excluded service principal. Interactive admin actions on the same resources still require approval, so the protection for humans stays fully in place. 

What do I recommend? 

This is what I would do in a tenant with MAA access policies: 

1. Inventory your automation first. Find every script, pipeline, and third-party tool that writes to apps, scripts, or policies with an app-only token. The Intune audit log records MAA events like approve, block, and pass, so you can see which app-auth calls are hitting MAA. 
2. Decide per app. For tools where a human review makes sense, implement the justification and approval-code flow. For trusted, unattended automation (packaging pipelines, service accounts), use the Exclusions tab. 
3. Keep the exclusion list small. Every excluded app is a bypass of MAA. Treat these app registrations like privileged accounts and protect their credentials well. 
4. Don’t turn off Multi Admin Approval just because automation broke. The 403 is annoying for a day, but the protection is worth it. 

In this blog post, I showed you why Multi Admin Approval now breaks Graph automation with 403 errors, how the new approval flow for API calls works, and how the Exclusions tab helps with service accounts. I hope this helps.