Multi Admin Approval (MAA) — A Missing Feature (Notifications)

In May 2026, I had the opportunity to present at a Workplace Ninjas meetup in Dallas, where I covered a defense-in-depth approach to operational privileged identity management and Intune Multi Admin Approval (MAA).

The session focused on how organizations can move beyond simply assigning privileged roles and start building a more resilient operational model around them. That means using layered controls such as least privilege, Privileged Identity Management, just-in-time elevation, strong authentication, approval workflows, auditing, and separation of duties.

A major part of the discussion centered on Intune MAA and why it matters in modern endpoint management. Intune is no longer just a device management platform; it is part of the administrative control plane. If an account with the right permissions is compromised, the attacker may be able to make high-impact changes across devices, policies, apps, scripts, and administrative roles.

That is why MAA is such an important control. It adds a second layer of human approval before protected Intune changes can take effect. When combined with Privileged Identity Management and a mature operational process, MAA helps reduce the risk of one compromised account or one mistaken action turning into a broader incident.

The goal of the presentation was simple: show how identity, endpoint management, and operational security all connect. Defense in depth is not one feature or one checkbox. It is a layered strategy that protects privileged access before, during, and after administrative actions occur. This presentation was inspired by the Stryker attack reported on March of 20226.

Based on public reporting: Stryker disclosed a March 11, 2026 cybersecurity incident that caused a global disruption to its Microsoft environment; CISA later warned organizations to harden endpoint management systems after malicious activity targeting those systems; and Microsoft’s current Intune MAA documentation specifically says MAA is meant to help protect against compromised administrative accounts by requiring a second admin approval before protected changes apply.

Read more about the attack here:

CISA Urges Endpoint Management System Hardening After Cyberattack Against US Organization

The Stryker incident was not a traditional malware-driven ransomware event. It is best understood as a device wipe attack carried out through the Microsoft identity and endpoint management control plane. Instead of relying on malware to spread across endpoints, the attackers reportedly abused trusted administrative capabilities within the Microsoft environment to trigger device wipe actions at scale.

That distinction is important. In this type of attack, the endpoint management platform itself becomes the path of destruction. If an attacker compromises an account with enough Intune or Microsoft administrative privilege, they may be able to use legitimate management actions — such as wipe, retire, delete, or policy changes — against the organization.

One recommendation among several is to implement Multi Admin Approval (MAA). Based on community feedback, I’m confident many organizations have already moved in that direction. My organization had MAA configured prior to the March 11 incident, so it was already part of our operational process rather than a reactive control added afterward.

Microsoft’s current list of Intune MAA protected resources includes Apps, Compliance policies, Configuration policies, Device actions, RBAC, Scripts, Tenant Configuration, and MAA access policies themselves are automatically protected. MAA is also now relevant to automation because Microsoft documents that app-authenticated Graph API calls can be intercepted when the target resource is protected.

If you do not have Multi Admin Approval (MAA) configured in Intune, now is the time to set it up.

MAA is one of the most practical controls Microsoft provides to help protect against compromised administrative accounts. It requires a second administrator to approve protected changes before Intune applies them. That means high-risk actions like device wipe, retire, delete, script deployment, app changes, RBAC changes, compliance policies, and configuration policy changes can be placed behind an approval workflow instead of relying on a single admin session.

In the context of a device wipe attack, this matters. If an attacker compromises an Intune administrator account, MAA can create a critical pause between the attempted action and the actual change. That second approval step may be the difference between a suspicious request being caught and a destructive action being executed across the environment.

This should not be treated as an optional “nice to have” control. If Intune manages your endpoints, then Intune is part of your security control plane. Protect it accordingly.

Microsoft provides official guidance for configuring MAA here: Use Multi Admin Approval in Intune.

Assuming Multi Admin Approval is already configured, the next challenge is operationalizing the approval process.

MAA gives Intune administrators an important approval gate, but there is still a noticeable gap around notification and workflow. Today, the process can still be very manual. A requester may submit an approval request, but approvers often need to know where to look, when to check, and what context matters before making a decision. Likewise, requesters may need to manually follow up with approvers through Teams, email, chat, or ticketing systems to make sure the request is seen and reviewed in a timely manner.

That creates a process gap. The control exists, but the communication around the control may not be fully automated. In a fast-moving operational environment, that can lead to delays, missed requests, approval fatigue, or out-of-band conversations where important context is lost.

This is where organizations need to mature beyond simply enabling MAA. They should define who approves which workloads, how approvers are notified, what justification is required, how emergency requests are handled, and how approvals are documented. Without that structure, MAA can become either a bottleneck or a rubber-stamp process.

The security value of MAA is strongest when the approval workflow is visible, repeatable, and auditable. Enabling the feature is step one. Building the notification, escalation, and communication process around it is what makes it operationally effective.

Microsoft Intune Multi Admin Approval (MAA) is one of the most important controls available for protecting high-risk administrative actions. It brings the four-eyes principle into endpoint management by requiring a second administrator to approve sensitive changes before they take effect.

That matters.

If an admin attempts to wipe a device, delete a policy, modify a settings catalog profile, deploy a script, or change another protected workload, MAA can stop that action from being applied until another approved administrator reviews it.

But there is a gap.

MAA creates the approval workflow, but it does not fully operationalize the communication around that workflow.

The Problem Nobody Warns You About

The biggest operational challenge with MAA is not the approval itself. It is awareness.

When an MAA request is created, Intune does not automatically notify the right people in the way most teams would expect. There is no native Teams notification. No automatic email to approvers. No obvious push that says, “Hey, something is waiting for review.”

The request simply sits in Intune until someone goes looking for it.

In a real enterprise environment, that creates friction. A requester submits a change and then has to manually chase someone down in Teams, email, or a ticketing system. The approver may not see the message right away. The request may sit for hours, or even a full day, before anyone notices it.

That is where a security control can become an operational bottleneck.

And when security controls become painful, people start looking for ways around them.

That is the exact opposite of what we want.

MAA Is Valuable, But the Workflow Needs Help

To be clear, this is not an argument against MAA. MAA is absolutely worth implementing. In fact, after seeing attacks that abuse endpoint management and identity control planes, I believe MAA should be treated as a baseline control for Intune environments.

But enabling MAA is only step one.

The next step is making sure the people responsible for approving requests actually know when a request exists.

That was the gap I wanted to close.

I wanted MAA to work the way an approval system should work. When a request is created, the right people should be notified where they already work. For most organizations, that place is Microsoft Teams.

What I Built

To solve this, I built a small Teams-based workflow around Intune MAA.

GitHub

GitHub Intune-MAA-Notifier

**Live Demo**

The solution has two main parts.

The first part is a notifier. This is a PowerShell Azure Function that runs on a timer, checks Intune for pending MAA approval requests, and posts a Microsoft Teams Adaptive Card when it finds something new.

The second part is an approval bot. This is a Node.js Bot Framework function that handles the interaction from Teams. It allows the card to be updated, confirms the current state of the request from Intune, locks the card once the request is resolved, and notifies the original requester of the outcome.

The goal was not to replace Intune Tenant Administration blade.

The goal was to make MAA visible.

Why Polling Was the Right Choice

The obvious first thought was to use Microsoft Graph change notifications. Ideally, the system would subscribe to new MAA requests and react instantly when one appears.

The problem is that the Intune operationApprovalRequests resource does not support Graph change notification subscriptions.

So instead of forcing a real-time design where the platform does not support one, I used a timer-based polling model.

Every five minutes, the function checks Microsoft Graph for current approval requests. It filters for requests that still need approval, compares them against a small list of requests it has already announced, and posts a Teams card only for new items.

It is not flashy, but it works.

And for this type of workflow, five minutes is good enough. MAA approvals do not need a sub-second response time. They need visibility. A five-minute notification window is dramatically better than waiting for someone to randomly check the Intune portal.

Sometimes the boring design is the right design.

Keeping the Design Simple

The notifier keeps track of already-announced requests using a small JSON file in Azure Storage. There is no database. No queue. No complicated state engine.

It reads the existing list, compares it to what Graph returns, posts anything new, and writes the updated list back.

That simplicity matters. This kind of automation should be easy to understand, easy to troubleshoot, and easy to support. The point is to improve the operational workflow around MAA, not create another fragile system that requires constant care and feeding.

Secretless by Design

One of the most important design choices was to avoid stored secrets.

The Azure Function App uses a system-assigned managed identity. The bot app registration uses a federated identity credential that trusts that managed identity. At runtime, the function can request the tokens it needs without storing a client secret in application settings.

That removes an entire category of risk.

There is no secret to leak. No secret to rotate. No secret to accidentally commit. No calendar reminder to update a password before it expires.

For Azure-hosted automation, this should be the default pattern whenever the platform allows it.

Acting as the Human, Not as a Backdoor

The harder part was making sure the bot did not become a shortcut around the actual MAA control.

That was a key requirement.

The bot should not approve requests using some overpowered service principal. It should not become a hidden backdoor around separation of duties. The whole point of MAA is that a second authorized human must be involved.

The approval bot uses Teams SSO and delegated Graph tokens so that when an approver interacts with the card, the system reads the status as that user. The actual approve or reject action still happens in Intune or through the Intune-MAA workflow.

That means Intune remains the system of authority. The bot improves awareness and workflow, but it does not bypass the control.

Designing Around Stale Cards

One of the interesting lessons from this project was handling stale Teams cards.

In an approval workflow, the state can change somewhere else. Someone may approve or reject the request directly in Intune while the Teams card still shows available buttons.

Early in the project, this created an ugly experience. A user could click a button on a stale card and receive a raw Microsoft Graph error saying the action was no longer allowed because the request had already been handled.

Technically, that error was accurate.

Operationally, it was terrible.

No admin wants to see a wall of JSON when they click a button in Teams.

The fix was to redesign the behavior. Instead of allowing Teams to directly perform the approve or reject action, the buttons became confirm-only. The admin handles the request in Intune or the Intune-MAA module, then clicks the corresponding button in Teams to confirm the result and lock the card.

That made the workflow symmetrical and removed an entire class of errors.

The lesson was simple: graceful error handling is good, but designing the error out of the workflow is better.

Closing the Loop With the Requester

The final piece was notifying the requester.

When a request is approved or rejected, the original requester should not have to chase down the outcome. They should know what happened and why.

The bot sends the requester a private Teams message with the result. If the request was rejected, the message can include the approver’s reason. That turns MAA from a silent approval queue into a real workflow.

That small detail matters.

A requester who knows why something was rejected can fix the issue, adjust the change, or provide better justification next time. Without that feedback loop, MAA can feel like a black hole.

The Bigger Point

MAA is a strong control, but controls need operational support.

If approvers do not know something is waiting, the process slows down. If requesters do not know the result, they chase updates manually. If the only way to manage the queue is to remember to check the Intune portal, the process depends on human memory.

That is not a workflow.

That is a gap.

This project was built to close that gap by bringing MAA visibility into Microsoft Teams, where administrators are already working.

What I Would Tell Other Teams

If you are using Intune MAA, do not stop at enabling the feature. Think through the full operational process.

Who gets notified when a request is created?

Where do they see it?

How do they know what changed?

How does the requester know the outcome?

What happens when a request is rejected?

How do you avoid stale approvals and out-of-band confusion?

Those questions matter just as much as the technical configuration.

MAA gives you the approval gate. You still need a communication process around it.

Final Thought

Multi Admin Approval is one of the best controls Intune has for reducing the risk of single-admin compromise or accidental high-impact change. But without notification, visibility, and a clear workflow, even a good control can become frustrating.

That is why I built this.

Not to replace MAA.

Not to bypass Intune.

But to make the approval process visible, usable, and operationally sustainable.

Because a security control only works when people actually use it.

The Shape of the Workflow

At a high level, the workflow is simple.

A timer-based Azure Function checks Microsoft Graph every five minutes for pending Intune MAA requests. When it finds a new request, it posts an Adaptive Card into a Microsoft Teams channel so the approval team can see it.

From there, an administrator handles the request in Intune or through the Intune-MAA module. Once the request is approved or rejected, the Teams card can be confirmed and locked with the outcome. The original requester then receives a private Teams message with the result and, when available, the approver’s reason.

The flow looks like this:

Timer Function → Graph: list pending MAA requests
               → Dedupe against known request IDs
               → Post Adaptive Card to Teams

Approver acts in Intune or Intune-MAA
               → Confirms outcome from Teams card
               → Card locks with approval/rejection receipt
               → Requester receives private Teams notification

The goal is not to make Teams the source of authority. Intune remains the source of authority. Teams simply becomes the visibility and communication layer that MAA is missing.

Deployment Model

The notifier and bot are designed to be self-hosted.

Each organization deploys the solution into its own Azure subscription and tenant, using its own Function App, bot registration, managed identity, Teams channel, and Microsoft Graph permissions.

Nothing routes through a shared service.

That matters from a security and trust perspective. MAA is protecting sensitive administrative workflows, so the notification and bot layer should stay under the organization’s control. The automation should support the approval process without becoming another third-party dependency in the middle of privileged operations.

In other words, this is not meant to be a centralized service that sees everyone’s approval requests. It is meant to be tenant-owned automation that closes a real operational gap while keeping control where it belongs: inside your environment.

Security Considerations

Because this workflow touches Intune MAA, it needs to be treated as privileged automation.

The bot and notifier should only have the permissions they need to perform their jobs. The notifier needs enough access to read pending approval requests and post notifications. The bot needs to confirm request status and communicate the outcome, but it should not become a broad administrative service principal with unnecessary control over the tenant.

That distinction is important.

The purpose of this project is to improve visibility around MAA, not weaken the control MAA provides. The automation should support the approval process without bypassing Intune’s separation-of-duties model.

That is why the design keeps Intune as the source of authority. Approvals and rejections still happen in Intune or through the Intune-MAA workflow. Teams is used for awareness, confirmation, receipts, and requester communication.

Why This Matters After Control-Plane Attacks

The Stryker incident showed why endpoint management platforms need stronger operational controls. When attackers target the systems that manage endpoints, the management plane itself can become the attack path.

That is exactly why MAA matters.

But MAA is only effective if people actually see and act on the requests. A protected device wipe action sitting silently in a portal is better than no approval at all, but it still leaves a visibility gap. In a real incident, time matters. If a suspicious request is created, approvers need to know quickly so they can investigate, deny it, and escalate if needed.

This is the difference between having a control configured and having a control operationalized.

MAA provides the gate. Notification and workflow make the gate usable.

Final Takeaway

I built this because MAA solves an important security problem, but it leaves an operational gap.

The approval control exists. The notification workflow does not.

In a busy Intune environment, that gap matters. Admins should not have to remember to check the portal. Requesters should not have to chase approvals in side chats. Approvers should not have to guess what is pending or where to review it.

A good approval process should be visible, repeatable, and easy to follow.

This Teams bot turns Intune MAA from a silent approval queue into a real workflow. It brings requests into the place administrators already work, helps approvers see what needs attention, and closes the loop with the requester when the decision is made.

That is the kind of operational layer security controls need if we expect teams to actually use them.

A Note: Proof of Concept and Deployment Guidance

This project was created as an AI-assisted proof of concept to demonstrate how Microsoft Intune Multi Admin Approval notifications can be surfaced in Microsoft Teams. It is intended to show what is possible, close an operational visibility gap, and provide a starting point for organizations that want to build a more complete approval workflow around MAA.

This should not be deployed directly into production without review, validation, and testing.

Before implementing this solution, work closely with your IAM teams, Messaging/Teams administrators, Microsoft 365 administrators, Intune administrators, and security teams. The workflow touches privileged administrative processes, Microsoft Graph permissions, Teams bot registration, Azure Functions, managed identities, and Intune approval data. Those areas require proper ownership, review, and governance.

Organizations should first release this into a development or test environment, validate the permissions model, review the authentication flow, confirm Teams behavior, test requester and approver notifications, and perform extensive end-to-end testing before considering any broader rollout.

The intent of this tool is not to replace Microsoft Intunes current implementation, bypass Multi Admin Approval, or create an alternate approval path. Intune remains the source of authority. This solution is designed to improve visibility and communication around MAA requests by notifying the right people when action is needed.

Use this as a foundation, not a finished enterprise product. Review the code, adapt it to your organization’s standards, test thoroughly, and make sure the final implementation aligns with your internal security, identity, messaging, and change-management requirements.

Alright IT professionals, that wraps this one up.

MAA is a great control, but visibility is what makes it operational. Get it into Teams, test it in dev, work with the right teams, and make sure the process works before you trust it in production.

Cheers 🍻, and until next time keep securing the endpoint, protect the control plane, and I’ll see you in the next one.

Note:

If you are actively managing Intune Multi Admin Approval requests, I also built a companion tool called Intune-MAA to make the hands-on approval experience easier from PowerShell.

The Teams notification workflow helps solve the awareness problem, but Intune-MAA helps with the operational side of reviewing and managing approval requests directly.

You can check it out here:

GitHub — Intune MAA

Intune MAA — Multi Admin Approval Manager for PowerShell

If you are using MAA today, or planning to roll it out, give it a look. It was built for admins who want a faster, cleaner way to work through MAA approvals without living entirely in the portal.