Intune Multi-Admin Approval: Guarding High-Risk Changes Without Slowing Down
MAA puts a second pair of eyes on app protection policies and scripts. Design approver roles, request SLAs, and workflows that guard changes without gridlock.
C
CloudEngineerHub Team
Published: September 2, 2026· Last Updated: September 28, 2026·9 min read
Intune Multi-Admin Approval Without the Bottleneck
One careless edit to an app protection policy can block email for thirty thousand users before anyone notices. Multi-Admin Approval (MAA) puts a second pair of eyes on exactly those high-blast-radius changes — but a badly designed approver model turns a two-minute change into a two-day wait. This guide covers what MAA protects, how the request lifecycle actually behaves, and the RBAC and workflow patterns that keep control high and friction low.
Interactive FlowMulti-Admin Approval — Guardrail for High-Risk Change5/5
1
Protected resource edited
High-risk objects (e.g. scripts, baselines) trigger a request.
request
2
Approval request raised
Change captured with diff and requester identity.
approve
3
Second admin approves
A different admin reviews context and approves/denies.
apply
4
Change applies
Only then does the edit take effect on the resource.
5
Audit trail complete
Request, approval, and result stored for compliance review.
Multi-Admin Approval — Guardrail for High-Risk Change. 1. Protected resource edited: High-risk objects (e.g. scripts, baselines) trigger a request. — 2. Approval request raised: Change captured with diff and requester identity. — 3. Second admin approves: A different admin reviews context and approves/denies. — 4. Change applies: Only then does the edit take effect on the resource. — 5. Audit trail complete: Request, approval, and result stored for compliance review.
C
CloudEngineerHub Team
Author
The CloudEngineerHub editorial team — Microsoft endpoint management and cloud engineers writing hands-on guides on Intune, Azure, Entra ID, Autopilot, Defender and PowerShell. Every article is reviewed against current Microsoft documentation.
Microsoft Intune admin center access; requesters need a role that grants create/update rights on the protected resource they want to change
Approvers need the built-in Multi Admin Approver Intune role (or equivalent rights) and should be organized in dedicated Entra security groups
Intune RBAC in your tenant administered by a Role Administrator so approver groups stay out of day-to-day admin groups
A change-management convention (ticket IDs, batch windows) agreed with your ITSM owner, since MAA justification text is your audit trail
What Multi-Admin Approval protects
MAA gates changes to Intune resources where a mistake propagates instantly and widely. The protected resource types include app protection policies, device control policies, macOS shell scripts, macOS custom attributes, and scripts and remediations — and Microsoft has been expanding the list, so verify the current set on Microsoft Learn before you build your governance model around it.
The mechanism is consistent across types: when an admin with edit rights creates or updates a protected resource, the change doesn't take effect immediately. Intune converts it into an access request carrying the proposed change and the admin's justification. A designated approver reviews it and approves or denies. Only then does the change land.
Why these resources and not others
The common thread is instant, tenant-wide blast radius with no natural checkpoint. A configuration profile error usually shows up as device-level issues with time to react; an app protection policy change can cut off data access for every protected user on the next check-in. MAA exists for the changes where "undo quickly" isn't good enough, and where four-eyes review costs almost nothing compared to the incident it prevents.
Designing the approver RBAC model
Separate the roles cleanly
Requesters are your platform admins — Policy and Profile Managers, App Protection admins. Approvers should be a different population: platform leads, a change board delegate, or a senior engineer on rotation. The built-in Multi Admin Approver role grants the ability to act on requests without granting broad edit rights across Intune, which keeps the approver population meaningfully separated from the requester population. Intune also prevents a requester from approving their own request — the two-person rule is enforced by the service, not just by policy.
Put approvers in groups, and make membership deliberate
Create dedicated Entra groups — for example SEC-MAA-approvers-core and SEC-MAA-approvers-oncall — and attach the Multi Admin Approver role via role assignments scoped to those groups. This gives you three benefits: membership changes are auditable in Entra, you can delegate group management without touching Intune RBAC, and you can layer just-in-time access on top (see below).
Then verify the approver group itself — because role assignments point at groups, and groups drift:
PowerShell
1
2
3
# Who is in the approver group right now?$Approvers = Get-MgGroupMember -GroupId"<approver-group-id>" -All$Approvers.AdditionalProperties | Select-Object displayName, userPrincipalName
Field note: The audit script above has caught more than one drift problem: an approver group that quietly accumulated 14 members because every departing lead "just stayed in the group." Treat approver membership like privileged access — same review cadence, same removal discipline. If you run Entra ID P2, put approver groups behind PIM for Groups so approval rights are activated, not permanent.
On-call approvals without standing committees
The friction complaint about MAA is almost always really a staffing complaint. Fix it operationally: a small on-call approver rotation covering business hours and weekends, a documented escalation path when the primary is unreachable, and an SLA target (for example, approve or deny within 4 business hours) tracked like any other ops metric. Approvals happen in the Intune admin center — approvers see the proposed change, the requester, and the justification, and act from there.
The request lifecycle, end to end
State
Who acts
What happens next
Draft
Requester
Change saved but not effective; can be edited or submitted
Submitted
Requester
Notification flows to approvers; clock starts on the review period
In review
Approver
Approver examines the diff, justification, and impact
Approved
Approver
Change is applied to the resource automatically
Denied
Approver
Requester can adjust and resubmit; the original state stands
Cancelled
Requester
Requester withdraws a mistaken or superseded request
Expired
Service
Request not actioned within the access policy's review period lapses
Three operational details matter:
The justification field is evidence. Make the convention explicit — CHG0012345 | app protection policy refresh for Q3 — and your ITSM records become cross-referenceable without any integration work.
Expiry is a feature. Requests that sit unnoticed expire rather than silently granting approval-by-neglect. Size the review period in your access policy to match your change cadence, not the default.
Batch related changes. A scoped policy refresh touching three app protection policies should be three reviewed requests in one window — not three separate weeks of approval latency.
Integrating MAA into change management without inventing a new process
MAA slots into existing change flow best when treated as a technical control attached to your existing change classes. Standard changes in your CAB (like routine remediation script updates with reviewed diffs) map to MAA requests with pre-agreed approvers. Emergency changes still require a request — build the "emergency approver" path into your on-call model instead of working around MAA with shared accounts or re-scoping roles, which defeats the control and shows up in audits.
Field note: A healthcare tenant wired MAA into their change calendar: no app protection policy requests were submitted after 3 p.m. Friday unless flagged emergency, because the approver SLA was 4 hours and the weekend on-call didn't include an MAA approver. The fix wasn't relaxing MAA — it was adding one weekend approver to the rotation. Governance fails at staffing seams, not at policy definitions.
Visual Walkthrough
Delegation without holes: the intersection that grants effective rights.
Layered StackIntune RBAC — Role Meets Scope Tag5/5
PerimeterCore asset
1
Entra directory role
Intune Admin / Global Admin — the tenant-level floor.
floor
2
Intune RBAC role
Endpoint Security Manager, Help Desk, custom roles refine verbs.
role
3
Scope tag attached
Objects tagged by region/team become visible subsets.
scope tag
4
Assignment scope
Scope groups limit which users/devices the role touches.
scope group
5
Effective permission
Intersection of all three — document the matrix, verify with a test admin.
Each layer assumes the previous one failed — depth is the strategy.
Intune RBAC — Role Meets Scope Tag. 1. Entra directory role: Intune Admin / Global Admin — the tenant-level floor. — 2. Intune RBAC role: Endpoint Security Manager, Help Desk, custom roles refine verbs. — 3. Scope tag attached: Objects tagged by region/team become visible subsets. — 4. Assignment scope: Scope groups limit which users/devices the role touches. — 5. Effective permission: Intersection of all three — document the matrix, verify with a test admin.
GDPR export and operational limits
Two practical constraints round out the picture. First, tenant-level data operations interact with MAA: a GDPR data export initiated from Intune can affect request handling while it runs, so schedule exports outside your change windows — the specifics are documented in the MAA guidance on Microsoft Learn, and worth checking each time Microsoft updates the feature. Second, MAA is Intune-scoped. It does not gate conditional access policies, Entra role changes, or anything outside the Intune service — those need their own controls (PIM for Entra roles, change locks in Entra). Audit teams will ask for the full privileged-change map; MAA covers one important quadrant of it, not all four.
Finally, remember what MAA does not change: requesters retain their full editing rights on unprotected resources, and approvers don't need broad Intune admin rights. Keep the model that way — the moment approvers need edit rights "to see the impact," your separation of duties has quietly collapsed.
Auditing your MAA posture quarterly
A 20-minute quarterly check keeps the control honest:
PowerShell
1
2
3
4
5
6
# Recent Intune audit events — establish that changes to protected# resources correlate with approved MAA requests, not direct edits
Get-MgDeviceManagementAuditEvent -Top100 |
Select-Object ActivityDateTime, ActivityType, ActivityOperationType,
@{n='Actor';e={$_.Actor.UserPrincipalName}} |
Format-Table -AutoSize
Check four things: approver group membership matches the current org chart; no requester appears in an approver group; expired and denied requests show a pattern of resubmission worth investigating (a sign the approval criteria are unclear); and the review period on your access policies still matches your stated change SLA. Export the results into your existing privileged access review — auditors love evidence they didn't have to ask for twice.
Key takeaways
MAA gates the highest-blast-radius Intune changes — app protection policies, device control, macOS scripts and custom attributes, scripts and remediations — with a service-enforced two-person rule.
The request lifecycle (Draft → Submitted → In review → Approved/Denied/Cancelled/Expired) is your audit trail; put ticket IDs in justifications so ITSM and Intune evidence cross-reference cleanly.
Approver power should live in dedicated Entra groups behind the built-in Multi Admin Approver role — never in the requester population, and ideally behind PIM for Groups on P2.
Approval friction is a staffing problem: on-call rotations, a stated SLA, and batched requests fix it; shared accounts and role workarounds destroy the control.
Requests expire by design — size the review period deliberately rather than living with defaults.
MAA is one quadrant of privileged change control; pair it with PIM for Entra roles and your Azure resource governance for the full map.
Frequently asked questions
Can the admin who creates a request approve it themselves?
No. MAA enforces separation of duties at the service level — the requester cannot act on their own request. This is why approver group hygiene matters: if a requester ends up in the approver group for someone else's change, the two-person rule holds per request, but your risk posture degrades to one team approving itself.
What happens if a request expires without action?
The request lapses and the pending change does not apply. The requester resubmits with a fresh justification. Operationally, treat a rising expiry count as a signal: either your approver SLA is understaffed or your review period is shorter than your real change cadence — fix the process, not the control.
Does MAA slow down emergency changes?
Only as much as your on-call design lets it. Emergencies still need a request and an approval, but a reachable emergency approver turns that into minutes. The anti-pattern is the tenant that quietly removed MAA during its first incident and never restored it — the second incident was the one that cost them the audit.
Comments
0No comments yet — be the first to share your thoughts.