Microsoft Entra Permissions Management retirement reshapes CIEM strategy

At a glance

What this is: Microsoft is retiring Entra Permissions Management and folding select CIEM functions into Defender for Cloud, forcing customers to reconsider how multi-cloud entitlements are governed.

Why it matters: IAM and cloud security teams need to decide whether an integrated CSPM approach can preserve least-privilege oversight across Azure, AWS, and GCP without losing entitlement visibility or operational continuity.

By the numbers:

• No new purchases will be accepted after April 1, 2025 for Enterprise Agreement or direct customers.
• No new purchases will be accepted after May 1, 2025 for Cloud Solution Provider customers.
• The product will no longer be available or supported after October 1, 2025.

👉 Read Unosecur's analysis of the Entra Permissions Management retirement and CIEM migration

Context

Microsoft is retiring Entra Permissions Management, the standalone CIEM product that gave organisations a central view of permissions across Azure, AWS, and GCP. New purchases stop before the support end date, and the remaining capability will be folded into Defender for Cloud as part of a broader CSPM-led model.

The identity governance question is not whether Microsoft still supports IAM in Entra ID. The question is whether entitlement governance survives when a dedicated CIEM layer is removed and practitioners are asked to rely on integrated cloud security tooling or a third-party replacement instead.

Key questions

Q: What breaks when standalone CIEM is retired but cloud permissions still need governance?

A: The main break is control depth, not sign-in capability. Authentication, MFA, and user lifecycle services can continue unchanged while the organisation loses a dedicated entitlement layer for cross-cloud privilege analysis, rightsizing, and evidence. Teams then risk treating CSPM findings as a substitute for true CIEM governance, which can leave overprivileged access less visible.

Q: Why does retiring CIEM matter if identity and access management still works?

A: IAM can still function because IAM and CIEM answer different questions. IAM governs who can authenticate and how identities are managed, while CIEM governs what those identities can access across cloud services. Retiring a standalone CIEM capability matters because the organisation may keep authentication intact but weaken its ability to detect and reduce excessive cloud permissions.

Q: How should security teams choose between CSPM, DSPM, and CIEM?

A: Start with the control gap you need to close. Use CSPM for configuration drift, DSPM for sensitive data discovery and exposure, and CIEM for entitlement sprawl. Most cloud environments need all three, but CIEM usually delivers the fastest identity governance value because excessive permissions are often the real blast radius driver.

Q: What should organisations do before a CIEM product retirement takes effect?

A: They should map purchase dates, support deadlines, and legacy-only constraints against current entitlement workflows. Then they should verify where remediation, exception handling, and reporting will live after retirement so the transition does not create a blind spot in multi-cloud privilege control. The aim is continuity of control during the migration window.

Technical breakdown

What changes when CIEM becomes a CSPM feature

Cloud Infrastructure Entitlement Management, or CIEM, is the control layer that inventories, analyzes, and rightsizes permissions across cloud environments. In a standalone model, it can focus narrowly on entitlement sprawl, excessive privilege, and cross-cloud access drift. When CIEM features are embedded into a CSPM platform, the visibility model changes: entitlement analysis becomes one part of a broader cloud posture workflow rather than a dedicated governance function. That shifts how teams operationalize reviews, exception handling, and remediation because permission data now competes with misconfiguration, exposure, and policy findings in the same control plane.

Practical implication: Treat embedded CIEM as a different operating model and test whether entitlement review depth is preserved when it sits inside CSPM.

Why multi-cloud entitlement governance becomes harder during migration

Multi-cloud entitlement governance depends on consistent discovery, normalization, and analysis of identities, roles, and permissions across providers. If a standalone CIEM product is removed, the organisation must prove that the replacement can still reconcile cloud-native constructs with enough fidelity to support least-privilege decisions. The risk is not only tool substitution but governance fragmentation, where Azure, AWS, and GCP permissions are managed through different workflows, evidence sets, or remediation timelines. That creates a control gap if teams assume a single integrated platform automatically preserves equivalent depth.

Practical implication: Map the current entitlement workflow end to end and check whether the successor path preserves the same review and remediation depth across clouds.

How retirement affects identity governance, not core Entra ID authentication

The retirement affects CIEM add-on capability, not the core Microsoft Entra ID services used for SSO, MFA, user management, or Conditional Access. That distinction matters because many organisations will conflate identity authentication with entitlement governance, even though they solve different problems. Authentication answers who can sign in, while CIEM answers what that identity can do once it has access. Losing a standalone entitlement layer does not break authentication, but it can weaken visibility into overprivileged cloud access if the replacement is thinner than the original control.

Practical implication: Separate authentication resilience from entitlement governance in your roadmap so migration decisions do not blur distinct control objectives.

NHI Mgmt Group analysis

CIEM removal is a governance event, not a product swap: The practical issue is the loss of a dedicated entitlement governance layer for multi-cloud environments. When that control becomes a feature inside CSPM, teams should expect review, remediation, and exception handling to follow the broader posture tool’s workflow rather than CIEM-first governance. That changes the operating model, not just the licence.

Entitlement governance and authentication are being conflated too often: Entra ID authentication services and CIEM solve different identity problems. SSO, MFA, and Conditional Access continue, but permission analysis across Azure, AWS, and GCP is a separate control surface. Organisations that treat those as interchangeable will miss the gap created when a dedicated CIEM capability disappears.

Multi-cloud entitlement visibility is now a programme design choice: The article shows that organisations must decide whether integrated Defender for Cloud coverage is enough or whether they need a separate CIEM capability to preserve governance depth. That choice affects how evidence is collected, how least privilege is enforced, and how auditors see entitlement control across cloud estates.

Runtime cloud entitlements need a named concept: entitlement governance continuity: This retirement exposes the need to preserve the same review, analysis, and revocation logic when a control moves between products. If the workflow changes, the governance outcome changes too. Practitioners should evaluate continuity of control, not continuity of vendor branding.

The market is moving toward bundled control planes, but governance accountability remains separate: The direction of travel is clear: security vendors are consolidating posture and entitlement functions into fewer platforms. That may simplify procurement, but it does not remove the need to prove who owns cloud entitlement decisions, who reviews exceptions, and which team is accountable when multi-cloud privilege drifts.

What this signals

Entitlement governance continuity: When CIEM is absorbed into a broader cloud posture platform, the organisation must prove that permission analysis, rightsizing, and exception handling keep the same governance depth. Otherwise the control becomes easier to consume but harder to audit.

The migration also reinforces a familiar identity lesson: authentication and authorization should not be treated as interchangeable. Teams that preserve Entra ID sign-in controls but neglect cloud entitlement visibility may satisfy the wrong control objective and miss the actual privilege problem.

For practitioners

• Assess entitlement governance continuity Compare the current CIEM workflow against the successor path and verify that discovery, rightsizing, approvals, and evidence retention still operate at the same depth across Azure, AWS, and GCP.
• Separate authentication from authorization controls Document which controls cover sign-in, which cover cloud entitlements, and where the migration changes the boundary between Entra ID, CIEM, and posture tooling.
• Re-test multi-cloud least-privilege coverage Validate that overprivileged roles, stale access paths, and cloud-specific privilege drift remain visible after the CIEM transition, not only within the security posture console.
• Plan the support and licensing transition Map purchase cut-off dates, end-of-support timing, and legacy customer constraints so the organisation does not lose control of CIEM coverage during procurement overlap.

Key takeaways

• The retirement affects entitlement governance across Azure, AWS, and GCP, not the core authentication services in Entra ID.
• The control risk is a loss of CIEM depth if integrated CSPM cannot preserve the same review and remediation model.
• Practitioners should verify governance continuity, support timelines, and multi-cloud visibility before the transition window closes.

Key terms

• Cloud Infrastructure Entitlement Management: Cloud Infrastructure Entitlement Management focuses on who has access to what in cloud systems, especially excessive or unused permissions. It helps reveal overprivileged identities, but it does not automatically remove them. In practice, it is most useful when tied to policy enforcement and access expiry mechanisms.
• Entitlement Governance: Entitlement governance is the discipline of deciding who or what should have access, for how long, and under what business justification. It spans human users, non-human identities, and automated workflows, making it a core control layer for SaaS, cloud infrastructure, and lifecycle management.
• Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.
• Cloud Security Posture Management: Cloud Security Posture Management is a set of tools and processes that identify misconfigurations, policy drift, and exposure in cloud environments. It is strongest at discovery and weakest at enforcement, so it should be treated as a detection layer that feeds remediation rather than a control plane that changes access by itself.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• Purchase cut-off dates by customer type and the support timeline that governs the migration window
• The comparison between Defender for Cloud’s integrated CIEM features and a standalone CIEM replacement
• The licensing and subscription changes that affect legacy customers versus new buyers
• The vendor’s guidance on how to preserve multi-cloud entitlement governance after retirement

👉 Unosecur's full post covers the retirement timeline, CIEM migration options, and entitlement governance implications.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.