Entra Permissions Management Is Retired. Your CIEM Coverage Might Still Have a Hole In It.

If you went looking for the Permissions Management blade in the Microsoft Entra admin center any time after November 1, 2025 and found nothing there, you didn't miss a menu — Microsoft deleted it, and the data collection behind it, on schedule. Microsoft Entra Permissions Management (the product born from the 2021 CloudKnox acquisition) is retired. What almost nobody has written about clearly is what that actually leaves an Intune/Entra admin with today, in September 2026, and it is not a simple like-for-like swap.

This post is not "breaking news" — the retirement itself is over ten months old by the time you're reading this. It exists because the coverage question is not old news at all: Microsoft is still actively changing how Cloud Infrastructure Entitlement Management (CIEM) works inside Microsoft Defender for Cloud as recently as August 2026, most admins were never given a CIEM replacement in the first place (Microsoft's own recommended path was a third-party product, not an internal one), and this site — despite covering Entra ID heavily — has never once written about Permissions Management, CIEM, or what replaced either of them. That gap, not the retirement date, is the actual news here.

The problem: the portal blade is gone and the data is already deleted

Here's the exact sequence, in Microsoft's own words and dates, because a lot of the secondary coverage of this got the final date wrong (an earlier, since-superseded plan said October 1, 2025 — that date changed).

If you had it onboarded and did nothing, here is what happened to you automatically, with no action required on your part:

• April 1, 2025 — new purchases stopped for Enterprise Agreement and direct customers.
• May 1, 2025 — new purchases stopped for CSP (Cloud Solution Provider) customers too.
• April 1 – September 30, 2025 — existing paid customers kept full access while Microsoft pushed migration guidance.
• November 1, 2025 — automatic offboarding. Permissions Management stopped working, and — this is the part worth re-reading — the collected permissions data was deleted, not archived. If you didn't export your custom reports, alert configurations, and authorization system list before this date, they are gone.

The confusing part for most Intune/Entra admins isn't the retirement itself — it's what to do instead. And here's the detail that gets skipped in almost every summary of this story: Microsoft's own official recommendation for what replaces Permissions Management is not "Microsoft Defender for Cloud." It's a named third-party partner.

Why it happens: one retired product, one surviving feature, and they are not the same thing

To make sense of this, you need to separate two things that get talked about as if they're interchangeable, because Microsoft itself used the same acronym — CIEM — for both.

Thing one: the standalone product that just died

Microsoft Entra Permissions Management was a full standalone SaaS product, reachable from the Microsoft Entra admin center, with its own portal, its own onboarding wizard (OIDC app registrations into your AWS and GCP accounts), custom reports, configurable alerts, and a scoring metric called the Permissions Creep Index (PCI). Microsoft's own retirement notice explains the business reasoning plainly:

That partner is Delinea, specifically their product Privilege Control for Cloud Entitlements (PCCE). Microsoft's guidance is explicit that this — not Defender for Cloud — is the recommended migration target for anyone who actually relied on the full feature set: continuous entitlement discovery, granular usage-based recommendations, and dashboards comparable to what Permissions Management provided.

Thing two: the feature inside Defender for Cloud that never went anywhere

Separately, Microsoft Defender for Cloud has its own native CIEM capability, bundled as part of the Defender Cloud Security Posture Management (CSPM) plan. This is not a new product Microsoft spun up to replace Permissions Management — it already existed as an integration point, and Microsoft's current documentation is careful to say the shutdown doesn't touch it:

So: one product retired and had its data deleted. A separate, narrower capability with a similar name and acronym kept running the whole time, inside a completely different portal, under a completely different license (a paid Defender for Cloud plan, not an Entra add-on), and it was never a one-for-one replacement for the thing that got shut down.

What you actually lose going from the old product to the new feature

Even fully onboarded, native CIEM in Defender for Cloud is a smaller feature set than the retired standalone product. As of this post, Microsoft's own documentation lists these two coverage gaps explicitly under "Limitations" on the CIEM enablement page:

• The Permissions Creep Index (PCI) metric is being deprecated and will no longer appear in Defender for Cloud recommendations at all — the one headline risk score the old product was built around doesn't carry over.
• Starting August 6, 2026, Defender for Cloud stopped publishing the detailed list of unused AWS and GCP permission actions behind the "overprovisioned identities" recommendations, for performance and scalability reasons. The recommendation itself still flags an overprivileged identity — but if you want to see exactly which unused actions are driving that flag, Microsoft's guidance is to go check AWS IAM's own "Last Accessed" data or Google Cloud's Policy Intelligence directly, not Defender for Cloud.

Both of those changes landed within the last two months of this post being written — this is not a static, settled feature. If you built a migration plan around native CIEM a year ago, it's worth re-reading it against what's actually there today.

That's the breadcrumb you will not find anymore. There is no "Permissions Management" node under Identity in the Entra admin center as of this post. If a runbook, an onboarding doc, or a piece of internal training material still tells a new hire to go find it there, that documentation needs updating before it wastes someone's afternoon.

How to verify: check what you still have and what you never turned on

Before deciding what to do, find out where you actually stand. There are two separate things to check: leftover artifacts from the retired product, and whether the surviving feature is even switched on.

Step 1 — Check for leftover Permissions Management artifacts in Entra ID

Even though the product itself is gone, its supporting app registrations and role assignments can linger in your tenant if nobody ran the offboarding steps. Check both of these:

1. Sign in to the Microsoft Entra admin center.
2. Go to Identity › Applications › Enterprise applications › All applications.
3. Search for Cloud Infrastructure Entitlement Management. If this app is still present and still enabled for user sign-in, it's a dead credential surface left over from the old AWS/GCP OIDC connections — worth disabling even though the product behind it is retired.
4. Separately, go to Identity › Roles & administrators and search for the Permissions Management Administrator role. Check its assignments — anyone still holding that role has a standing privileged role assignment for a product that no longer exists.

If AccountEnabled comes back True, that service principal can still accept sign-ins even though the product it belonged to has been shut down and its data deleted for almost a year. There's no upside to leaving it enabled.

Step 2 — Check whether native CIEM in Defender for Cloud is actually on

This is the check most tenants skip, because it's easy to assume "we have Defender for Cloud" means "we have CIEM." Confirm it directly, per subscription, with PowerShell rather than clicking through every subscription's settings blade by hand.

Two things have to both be true for CIEM to actually be running on that subscription: PricingTier has to read Standard (Defender CSPM's paid tier — the Free tier doesn't carry CIEM at all), and the extension named EntraPermissionsManagement has to appear in the Extensions collection with IsEnabled set to True. That exact extension name — confusingly, still carrying the old product's name even though it now lives inside Defender for Cloud — is documented in Microsoft's own Azure Resource Manager schema reference for Microsoft.Security/pricings.

The fix: onboarding native CIEM in Defender for Cloud, click by click

If, after the checks above, you've decided native CIEM in Defender for Cloud is enough for your environment (rather than migrating to Delinea PCCE or another third-party CIEM tool for full feature parity), here is the complete, exact walkthrough — every click, for Azure, AWS, and GCP — straight from Microsoft's current enablement documentation.

Prerequisites — read this before you start clicking

1. You need the Security Admin Azure RBAC role — at subscription level for Azure, at account/organization level for AWS and GCP connectors.
2. For AWS or GCP resources, the cloud account/project must already be connected to Defender for Cloud (via the AWS or GCP connector) before you can turn on CIEM for it.
3. Defender CSPM must already be enabled (Standard tier) on the subscription, AWS account, or GCP project — CIEM is a sub-toggle inside that plan, not a standalone purchase.

Enable CIEM for an Azure subscription

1. Sign in to the Azure portal.
2. In the top search bar, search for and select Microsoft Defender for Cloud.
3. In the left navigation, select Environment settings.
4. Select the relevant subscription from the tree on the left.
5. Find the Defender CSPM plan row and select Settings next to it.
6. Toggle Permissions Management (CIEM) to On.
7. Select Continue.
8. Select Save.

The applicable recommendations — "Azure overprovisioned identities should have only the necessary permissions" and "Permissions of inactive identities in your Azure subscription should be revoked" — appear within a few hours. There's no separate connector or credential step for Azure; the toggle alone is sufficient because Defender for Cloud already has read access to the subscription it's protecting.

Enable CIEM for an AWS account

1. Sign in to the Azure portal and open Microsoft Defender for Cloud › Environment settings.
2. Select the connected AWS account.
3. Find the Defender CSPM plan row and select Settings.
4. Toggle Permissions Management (CIEM) to On.
5. (Recommended, not required) Set up AWS CloudTrail log ingestion for more accurate CIEM insights.
6. Select Configure access.
7. Select a deployment method (CloudFormation is the default onscreen option).
8. Run the generated CloudFormation deployment script against your AWS environment, following the onscreen instructions.
9. Check the CloudFormation template has been updated on AWS environment (Stack) box once the stack deployment completes.
10. Select Review and generate.
11. Select Update.

Unlike the Azure path, AWS requires this extra CloudFormation deployment because Defender for Cloud needs an IAM role granted inside your AWS account before it can read entitlement data there. Recommendations appear within a few hours of the stack finishing.

Enable CIEM for a GCP project

1. Sign in to the Azure portal and open Microsoft Defender for Cloud › Environment settings.
2. Select the connected GCP project.
3. Find the Defender CSPM plan row and select Settings.
4. Toggle Permissions Management (CIEM) to On.
5. Select Save.
6. Select Next: Configure access.
7. Select the relevant permissions type for the deployment.
8. Select a deployment method (Cloud Shell or Terraform).
9. Run the generated deployment script against your GCP environment using the onscreen instructions.
10. Check the I ran the deployment template for the changes to take effect box.
11. Select Review and generate.
12. Select Update.

Same story as AWS on the detail-level limitation: since August 6, 2026, drill-down on exactly which GCP permissions are unused has moved to Google Cloud's own Policy Intelligence and IAM role recommendations rather than staying inside Defender for Cloud.

The companion script: auditing CIEM coverage across every subscription

Clicking through Environment settings one subscription at a time doesn't scale past a handful of subscriptions. Get-CiemCoverageReport.ps1 loops every subscription the signed-in account can see, checks the Defender CSPM plan's pricing tier and its EntraPermissionsManagement extension state using the exact Get-AzSecurityPricing call shown above, and reports which subscriptions have full CIEM coverage, which have Defender CSPM but not the CIEM extension, and which don't have Defender CSPM (Standard) at all.

It is entirely read-only. It never calls Set-AzSecurityPricing or any other state-changing cmdlet — it only reads pricing configuration and reports on it. Running it does not turn CIEM on or off anywhere.

Proof it worked: reading the coverage report correctly

Run the script against a real tenant and you get one row per subscription, plus a summary count at the end. Here is an illustrative example — subscription names and IDs below are fictional, shaped the same way real ones would be, since this section can't publish a real tenant's subscription list.

Three things confirm the audit ran correctly rather than silently failing:

• Every subscription the account can see appears in the list. If the row count is lower than Get-AzSubscription returns on its own, something (usually an access or context error on one subscription) is being swallowed rather than reported — check the script's error output, don't just trust the summary line.
• A "Free" CSPM tier always reports CIEM as unavailable, never as off. Those are different statuses for a reason: "off" means you could enable it right now with one toggle; "unavailable" means you have to upgrade the whole Defender CSPM plan to Standard first.
• The exit code matches the summary. Exit code 0 only when every subscription shows full coverage; exit code 1 when at least one gap is found; exit code 2 only on a genuine script error (a failed Graph/Az call), never as a stand-in for "gaps found." That distinction matters if you wire this into a scheduled task or pipeline and want to alert only on real gaps, not on script failures.

If your organization actually used Permissions Management's fuller feature set — custom reports, alerting, granular usage analytics — treat a clean "full CIEM coverage" result from this script as a floor, not a ceiling. It confirms the baseline Azure-native recommendations are running. It does not mean you have parity with what was retired; for that, Microsoft's own guidance still points to Delinea PCCE or another dedicated third-party CIEM product.

References

• Microsoft Learn — Microsoft Entra Permissions Management offboarding guidance (exact retirement dates, offboarding steps)
• Microsoft Learn — Cloud infrastructure entitlement management (CIEM) in Microsoft Defender for Cloud
• Microsoft Learn — Enable CIEM for Azure, AWS, and GCP in Defender for Cloud (the exact console steps used in this post)
• Microsoft Tech Community — Important change announcement: Microsoft Entra Permissions Management end of sale and retirement
• Microsoft Learn — Get-AzSecurityPricing cmdlet reference (Az.Security)
• Microsoft Learn — Microsoft.Security/pricings ARM template reference (the EntraPermissionsManagement extension name, verbatim)

Microsoft MVP community deep-dives