Microsoft Defender for Cloud Apps Retires Its Terminated-User Alert. Here Is What Replaces It.

Microsoft Defender for Cloud Apps has quietly retired one of its oldest insider-threat alerts. "Activity performed by terminated user" — the alert that fires when someone who no longer works at your company keeps touching your SaaS apps — is being replaced by a new dynamic detection called "Activity by a deprovisioned user (preview)." The rollout started in late June 2026 and was expected to complete by early July 2026, according to Microsoft's own Message Center post. Separately, and on its own schedule, Microsoft Defender unified role-based access control (RBAC) started auto-enabling for brand-new Defender for Cloud Apps customers in August 2026. Neither change requires you to click anything for it to happen — but both change what your SOC needs to know, and one of them has a real decision attached for tenants that already exist.

The problem: an alert your automation depends on just changed its name and its logic

If you have ever built a SOC runbook, a SIEM correlation rule, or a Power Automate playbook around the words "Activity performed by terminated user," that exact string is going away. Microsoft's Message Center post MC1402307, "Microsoft Defender for Cloud Apps: Improvements to threat protection capabilities," announced that this legacy alert is being retired and replaced by a new detection called "Activity by a deprovisioned user (preview)." The rollout began in late June 2026 and Microsoft expected it to complete by early July 2026.

This is not a cosmetic rename. The old alert was a static rule: Defender for Cloud Apps profiled users in your organization and fired when a user it considered "terminated" performed an activity. The new alert runs on what Microsoft calls a dynamic detection model — a Microsoft-maintained model that adapts on its own, rather than a fixed policy you can see and tune from the Policy management page. That distinction matters the moment something in your environment depends on the old alert existing, or on being able to open its policy definition and adjust it.

Separately from the alert change, Microsoft's Defender for Cloud Apps release notes page confirms a second change: starting in August 2026, Microsoft Defender unified role-based access control (RBAC) is automatically enabled for new Defender for Cloud Apps customers, with no manual workload activation required. That is genuinely hands-off — for a tenant that signs up for Cloud Apps for the first time after that date. It is a different story for every tenant that already existed before August 2026, which is most of the install base reading this.

Why it happens: dynamic detection models and the unified RBAC rollout timeline

To understand why Microsoft replaced a seemingly simple rule ("alert when a terminated user does something"), it helps to know what was actually limiting about it.

The legacy alert depended on Defender for Cloud Apps' own definition of "terminated." In practice this meant it profiled the user's account state as reflected in your directory and treated a static condition — the account looks terminated — as the trigger. That works cleanly for the textbook case: HR terminates an employee, the account gets disabled in Microsoft Entra ID, and if that same account keeps signing in and touching SaaS apps afterward, the alert fires. It is much less clean for every other way an account stops being legitimate. A contractor's access expires without a formal "termination." An account gets disabled temporarily for an unrelated reason and re-enabled later. An account is deleted and a new one is provisioned for the same person under a slightly different identity. The old alert's guidance for investigators even called this out directly — a documented benign-true-positive case was "the user was temporarily disabled or was deleted and re-registered," which tells you the static rule was already generating noise around exactly the edge cases that matter most.

Microsoft's own framing for the new model, described in the Message Center post, is that it "focuses on deprovisioned identity states rather than strictly 'terminated users.'" That is a broader net: the new detection is meant to catch activity from an account that should no longer have legitimate access, regardless of how the deprovisioning happened — not just the one specific HR-termination path the old rule watched for. Because it runs on a dynamic model Microsoft maintains centrally, the detection logic can keep adapting without you having to edit a policy, and — per Microsoft's own wording — "may change alert behavior over time" as the model adapts. That last point is worth sitting with: it means the alert volume and pattern you see this quarter is not guaranteed to be the same as what you see next quarter, even with zero configuration changes on your side.

The unified RBAC change is a different kind of story, and it has a longer runway. Microsoft Defender unified RBAC — a single permissions model that replaces separate, product-specific admin role systems across Defender products — has been rolling toward Cloud Apps for over a year before the August 2026 milestone. In December 2025, integration of Defender for Cloud Apps permissions with unified RBAC reached worldwide general availability, meaning any tenant could map its existing Cloud Apps roles and activate unified RBAC for that workload if it chose to. What changed in August 2026 is narrower: for a brand-new Defender for Cloud Apps customer, that activation now happens automatically, with no admin having to visit the activation page at all. Every tenant that already existed before that date is unaffected by the automatic part — for you, unified RBAC for Cloud Apps is still something you turn on yourself, and it is still marked (Preview) in Microsoft's own support table for the unified RBAC model.

How to verify: what your tenant is actually running today

Before you touch any runbook or role assignment, confirm what your own tenant is actually doing right now. There are three things to check: whether the new alert exists in your Policy management list, whether unified RBAC is activated for the Cloud Apps workload, and whether anything in your alert history is already using either alert name.

Step 1 — Check whether the new alert is present in Policy management

1. Sign in to the Microsoft Defender portal at security.microsoft.com.
2. In the left navigation, go to Cloud Apps › Policies › Policy management.
3. Use the search box to search for terminated. If the legacy alert has been retired in your tenant, it will no longer appear in this list at all — that absence is itself the confirmation.
4. Search again for deprovisioned. If the migration has completed for your tenant, you should see the new detection listed, marked (Preview), with no manual policy configuration options exposed — this is expected, since Microsoft maintains its logic centrally.

Here is roughly what that list looks like once the migration has landed:

Step 2 — Check whether unified RBAC is activated for the Cloud Apps workload

1. Sign in to the Microsoft Defender portal with an account that holds at least the Security Administrator role in Microsoft Entra ID.
2. Go to security.microsoft.com/mtp_roles, or navigate to Settings › Permissions › Roles (labelled Permissions and roles in older navigation).
3. Look at the workload activation status shown for each supported service. Microsoft Defender for Cloud Apps is listed as (Preview) support in this model — if it shows as not activated, your tenant is still on the legacy, product-specific Cloud Apps admin role model for that workload.
4. If you decide to activate it, follow Microsoft's Activate Microsoft Defender unified RBAC guidance — do this in a test/pilot role group first, not against your entire admin population in one step.

Step 3 — Check your alert history for either alert name

The Defender for Cloud Apps Alerts API lets you query alert history directly rather than paging through the portal UI. The request below asks for the most recent 50 open alerts from the last 30 days — the script later in this post wraps this exact call and filters client-side for either alert title.

Read the returned fields carefully — Microsoft's own Alerts API reference documents resolutionStatusValue as an integer: 0 is open, 1 is dismissed (legacy status), 2 is resolved (legacy status), 3 is closed as false positive, 4 is closed as benign, and 5 is closed as true positive. severityValue runs 0 low, 1 medium, 2 high. There is no dedicated filter for alert title text in the documented filter list, so title matching has to happen client-side against the returned data array — which is exactly what the companion script below does.

The fix: update your runbooks, and decide on unified RBAC

There is nothing to "fix" in the sense of a bug — both changes are working as designed. The action items here are about making sure your team's process and permissions model catch up with what Microsoft already changed.

For the deprovisioned-user alert: update everything that references the old name

1. Search every SOC runbook, KQL query, SIEM correlation rule, and Power Automate playbook for the literal string "Activity performed by terminated user" (or "terminated user" more loosely). Anything that filters on that exact alert title will simply stop matching once the legacy policy is retired in your tenant — with no error to tell you it stopped.
2. Add "Activity by a deprovisioned user" as the new match string everywhere the old one was referenced. Keep both strings active during your tenant's transition window, since the rollout is phased and you may see either name depending on when the migration lands for you.
3. Re-validate your investigation runbook against the new alert's guidance once it appears in your tenant. The old alert's documented true-positive response was straightforward: disable the user, cross-reference HR records to confirm termination, validate the Microsoft Entra user account, decommission every app the user had access to, and update your offboarding procedure. Treat that same response playbook as your starting point for the new alert too — the new detection reports the same underlying insider-risk scenario, just triggered by a broader set of deprovisioning signals.
4. Notify your SOC and helpdesk teams directly, per Microsoft's own recommendation in MC1402307, and update any internal knowledge-base article that names the old alert. This is the step most likely to get skipped, and it is the one that actually prevents a confused ticket six months from now when someone searches your KB for an alert name that no longer exists.

For unified RBAC: audit before you activate, don't activate blind

Unless your tenant is genuinely brand-new (created after Microsoft's August 2026 cutover), nothing forces your hand here — but leaving the decision unmade indefinitely is its own risk, since Microsoft's direction of travel is clearly toward unified RBAC being the default everywhere, eventually.

1. Confirm your Security Administrator Entra ID role coverage first — that role is required to gain initial access to Permissions and roles and to manage unified RBAC once activated.
2. Before activating, review Map Microsoft Defender for Cloud Apps permissions to the Microsoft Defender unified RBAC permissions and confirm every existing Cloud Apps scoped admin role your organization actually uses has a documented equivalent in the unified model.
3. Create the equivalent custom roles in unified RBAC and assign them to a small pilot group of admins first — do not activate for your entire admin population in the same step you create the roles.
4. Activate the workload following Activate Microsoft Defender unified RBAC, and immediately verify your pilot admins can still perform the same Cloud Apps tasks they could before.
5. Only after the pilot group confirms parity, roll the activation out to your remaining admin population.

The companion script: catching both alert names before your runbook does

Get-CloudAppsDeprovisionedAlertReport.ps1 queries the Defender for Cloud Apps Alerts API for open alerts in a configurable lookback window, then filters client-side for a title matching either "terminated user" or "deprovisioned" — since the documented Alerts API filter list has no title-text filter, this has to happen after the data comes back. It is entirely read-only: it calls the List alerts endpoint only, using a GET/POST request, and never calls any of the documented close/mark-read/mark-unread write endpoints. You provide your own API token and tenant hostname; the script never stores or transmits either anywhere beyond the single documented API call.

Run it with -CsvPath to export a row per matching alert, so your SOC has a running record of exactly when the transition happened in your own tenant rather than relying on memory of when you last checked Policy management.

Proof it worked: reading the script's output correctly

"Proof it worked" here means proof you now know what your tenant is actually doing, not proof of a fix — there is nothing broken to fix. Three results are possible, and each one tells you something different:

• Only legacy-named alerts appear, or none at all. The migration likely has not reached your tenant yet. Keep your runbooks matching the old name for now, but add the new name too so you are not caught out when it does land.
• Only new-named alerts appear. The migration has completed for your tenant. Anything still matching only the old name in your automation is now silently blind to this detection category.
• Both names appear in the same lookback window. You are mid-transition — expected during a phased rollout. Keep both strings active in every runbook and SIEM rule until you consistently see only the new name across a full lookback window.

For the RBAC side, "proof it worked" is simpler: after activation, have your pilot admins attempt every Cloud Apps task their old scoped role allowed, and confirm each one still works under their new unified RBAC role assignment. Anything that breaks is a role-mapping gap you needed to catch before rolling out further — exactly what the permission mapping reference is there to help you avoid.

References

• Microsoft Learn — What's new in Microsoft Defender for Cloud Apps (August 2026: unified RBAC auto-enabled for new customers)
• Microsoft Learn — How to investigate anomaly detection alerts (legacy "Activity performed by terminated user" definition and investigation guidance)
• Microsoft Learn — Microsoft Defender unified role-based access control (RBAC)
• Microsoft Learn — Activate Microsoft Defender unified RBAC
• Microsoft Learn — Map Microsoft Defender for Cloud Apps permissions to the Microsoft Defender unified RBAC permissions
• Microsoft Learn — List, Alerts API (Defender for Cloud Apps)
• Microsoft Learn — Alerts API reference (property and filter definitions)
• Microsoft Learn — What's new in Microsoft Defender unified RBAC (December 2025: Cloud Apps permissions integration reaching worldwide GA)