Microsoft Intune Admin Tasks: The New Approval Queue, and the Source Microsoft Already Retired

In January 2026, Microsoft Intune shipped a new node called Admin tasks — a single queue that pulls together the approval and remediation work that used to live in four separate corners of the admin center: Endpoint Privilege Management (EPM) file elevation requests, Multi Admin Approval (MAA) change requests, Microsoft Defender security tasks, and — briefly — suggestions from the Security Copilot Device Offboarding Agent. It reached general availability with that release. If you have not gone looking for it yet, it is sitting under Tenant administration right now, possibly with pending items nobody has noticed.

This post walks through what Admin tasks actually is, exactly which queues feed into it (and one that quietly stopped feeding into it), the RBAC model that decides what you can see versus what you can act on, and a read-only PowerShell script that gives you a fleet-level view of the two queues that expose a Microsoft Graph API — because Admin tasks itself is a portal-only aggregation with no unified Graph endpoint behind it.

The problem: approvals scattered across four blades, and one that no longer exists

Before Admin tasks existed, checking for pending approvals in Intune meant visiting each source blade in turn. An EPM elevation request sat under Endpoint security › Endpoint Privilege Management › Elevation requests. A Defender for Endpoint remediation request showed up under Endpoint security › Security tasks. A Multi Admin Approval change request lived under Tenant administration › Multi Admin Approval › Received requests. None of these blades notify you. Intune's own documentation says it plainly: there is no push notification when a new elevation request or MAA request lands — you have to go and check. That means an admin with EPM, MDE integration, and MAA all enabled had to remember to check three unrelated places, on no schedule, or things quietly expire.

Admin tasks fixes the "which blade do I check" problem by putting all of it — Task, Source, Status, Due in, Last updated, Created — into one filterable list at Tenant administration › Admin tasks. Selecting a row does not open some new simplified UI; it opens the exact same management pane you would have gotten from the task's original location. Admin tasks is a lens, not a replacement workflow.

Here is where the "four sources" framing needs a correction, and it is the kind of thing you only catch by reading the two Microsoft Learn pages side by side rather than trusting a single announcement post. Microsoft's own Admin tasks reference page (last updated July 1, 2026) still lists Device Offboarding tasks, from the Security Copilot Device Offboarding Agent, as one of the four sources feeding the queue. But the Device Offboarding Agent's own documentation page carries a retirement notice: setup was disabled April 30, 2026, and the agent was removed from the Intune admin center entirely on June 1, 2026. As of the date of this post, that fourth source is gone. Microsoft's cross-reference just has not caught up with Microsoft's own deprecation notice yet.

Why it happens: Admin tasks is an aggregation view, not a new data store

To use Admin tasks well, you need to understand what it is doing under the hood, because that explains both its strengths and its limits. Admin tasks does not create, store, or own any approval data itself. It reads from the same underlying records that already exist in EPM, MAA, and Defender security tasks, and renders them into one list. This is why selecting a task opens the source blade's real management pane rather than a new "Admin tasks" editor — there is no separate object to edit.

This matters for three practical reasons.

First, visibility follows the source, not the aggregation. Getting into the Admin tasks pane itself needs only one permission — Organization > Read — but that only unlocks the door. What you see inside the room is still gated per row by the RBAC permission for that row's original source: the Endpoint Privilege Management Elevation Requests permission for EPM rows, the relevant Endpoint security read permission for Defender security tasks, and MAA approver-group membership plus the resource-specific read permission for MAA rows. Two admins looking at the same Admin tasks pane can see two different lists, and that is by design, not a bug.

Second, the queue inherits each source's own status vocabulary, loosely unified. A Defender security task's lifecycle is Pending → Accepted → Completed (or Rejected). An MAA request's lifecycle is Needs approval → Approved → Completed (or Rejected, or Canceled, or Expired after 3 days). An EPM elevation request is Pending → Approved or Denied, with the approval itself only valid for 24 hours before the elevation right expires. Admin tasks maps all of these onto a shared column with values Active, Pending, Completed, Rejected, Expired, and Needs approval — but the timers underneath (3 days for MAA, 24 hours for an approved EPM elevation, 30 days before an Admin tasks row disappears entirely) keep running on each source's own clock, not a single unified one.

Third, there is genuinely no single API behind the aggregation. If you were hoping to script "get me everything in the Admin tasks queue" with one Graph call, that call does not exist. EPM elevation requests are exposed through the beta resource privilegeManagementElevationRequest at GET /deviceManagement/elevationRequests. MAA requests are exposed through the beta resource operationApprovalRequest at GET /deviceManagement/operationApprovalRequests. Defender security tasks and the (now-retired) Device Offboarding Agent suggestions do not have a documented public Graph surface as of this post. Admin tasks the portal feature is UI-layer aggregation over blades that were never unified at the API layer.

How to verify: find the queue and check what your role can actually see

Before you build anything around Admin tasks, confirm you can actually reach it and understand what your specific account is permitted to see. This is a manual portal check, no scripting required yet.

1. Sign in to the Microsoft Intune admin center with the account you use day-to-day.
2. In the left navigation, expand Tenant administration.
3. Select Admin tasks. If this entry is missing entirely, your account's Intune role does not include Organization > Read — talk to whoever assigns RBAC roles before going further.
4. Look at the Source column of whatever rows appear. You should only ever see values like Endpoint Privilege Management elevation request, Defender security task, or Multi Admin Approval request — never a Device Offboarding entry, for the reason covered above.
5. Use the filter control above the list to filter by Status. Set it to Needs approval and Pending together to see everything genuinely waiting on you right now, separate from anything already Completed or Rejected.
6. Select one row. Confirm the pane that opens matches what you would see navigating there directly — for an EPM row that means the same Elevation request properties pane documented under Endpoint Privilege Management, not a different simplified view.

If step 3 shows an empty list rather than a permissions block, that is a different, valid outcome — it means your role can see the pane but none of the underlying sources currently have anything you are permitted to act on. Do not confuse "empty because permitted-but-nothing-pending" with "empty because blocked."

The fix: working the queue, and scripting the two sources with a Graph API

"The fix" here has two halves: the manual workflow for actually clearing items from the queue, and a companion script for getting programmatic, fleet-wide visibility into the two sources that expose a Graph API.

Working an EPM elevation request from Admin tasks

1. From Tenant administration › Admin tasks, select a row where Source is an EPM elevation request.
2. In the Elevation request properties pane that opens, review File, Publisher, Device, and the user's Justification.
3. If your tenant is licensed for Security Copilot, select Analyze with Copilot in the upper right to have Defender Threat Intelligence evaluate the file's reputation and the publisher's trust before you decide.
4. Select Approve or Deny.
5. In the justification dialog, optionally enter a Reason, then select Yes.
6. An approval is only valid for 24 hours from the moment you approve it — the user must complete the elevated action within that window using Run with elevated access, or request again.

Working a Multi Admin Approval request from Admin tasks

1. From Tenant administration › Admin tasks, select a row where Source is a Multi Admin Approval request.
2. Select the Business justification link to open the Access policy request pane.
3. Enter notes in the Approver notes field if useful — these are visible to the original requestor.
4. Select Approve request or Reject request.
5. The original requestor still has to return to their own My requests page and select Complete before Intune actually applies the change — your approval alone does not push it through.
6. An unactioned request automatically becomes Expired after 3 days and must be resubmitted from scratch.

Working a Defender security task from Admin tasks

1. From Tenant administration › Admin tasks, select a row where Source is a Defender security task.
2. Review the Remediation Type (Application or Configuration), the linked Managed apps or Devices, and any Notes left by the Defender security admin who submitted the task.
3. Select Accept or Reject. Either choice can carry notes that are sent back to Defender for Endpoint.
4. If accepted, follow the Remediation details provided — these vary by vulnerability and might be an automated Intune deployment or plain-text manual instructions for an unmanaged app.
5. Once remediation is done, reopen the task and select Complete Task. This updates status in both Intune and the Defender portal, where the security admin can confirm the fix reduced the exposure score.

Scripting fleet visibility: the two sources that expose a Graph API

Admin tasks itself is portal-only, but two of its three living sources are not. EPM elevation requests are available read-only through the Microsoft Graph beta endpoint GET /deviceManagement/elevationRequests, and Multi Admin Approval requests through GET /deviceManagement/operationApprovalRequests. Both require an app registration with the appropriate Intune Graph scopes and, because these are beta endpoints, both are subject to change without the same notice period as v1.0.

The script below wraps both endpoints into one read-only fleet report, with no write permissions requested and no Set/Approve/Deny call made anywhere in the code.

Proof it worked: reading the script's output

A successful run produces a plain-language summary before any table, so a non-scripting admin scanning a scheduled-task log can tell health at a glance without parsing objects.

What "good" looks like here is not zero pending items — a queue with nothing in it just means nobody has asked for anything lately. What "good" looks like is Exit code: 0 and an oldest-item age that is inside each source's own expiration window. If the oldest MAA item shown is already past 72 hours, the script is not lying — Intune's own portal will show that same request as Expired, and the number you are looking at is a stale record about to be swept, not something you can still approve.

References

• Microsoft Tech Community — "Admin tasks in Microsoft Intune: Centralized control today, AI-ready for tomorrow"
• Microsoft Learn — Centrally manage Admin Tasks in Microsoft Intune
• Microsoft Learn — Get started with the Device Offboarding Agent (includes the April 30 / June 1, 2026 retirement notice)
• Microsoft Learn — Use EPM support approvals for file elevation requests with Intune
• Microsoft Learn — Use Multi Admin Approval in Intune
• Microsoft Learn — Use Multi Admin Approval with the Microsoft Graph API (operationApprovalRequest resource)
• Microsoft Learn — Use Intune to remediate vulnerabilities found by Microsoft Defender for Endpoint
• Microsoft Graph beta — privilegeManagementElevationRequest resource type

Microsoft MVP community deep-dives