Ambiguity around identity management paths: Microsoft Graph vs Az.Resources

### Description

Hi,

When Microsoft markets Graph and Entra as the successors to MSOnline and AzureAD, it’s reasonable for engineers to assume Az is not part of the identity story—yet the tooling still tells a different story:

[](https://learn.microsoft.com/en-us/powershell/module/az.resources/update-azaduser?view=azps-15.1.0)

==========================

Microsoft has consistently positioned Microsoft Graph PowerShell and Microsoft.Entra PowerShell as the official successors to the now deprecated and retired MSOnline and AzureAD / AzureADPreview modules.

This positioning has been very explicit in:

Microsoft Learn documentation, Blog posts and announcements, and especially Microsoft engineers’ and advocates’ posts on LinkedIn

Based on that messaging, many platform and identity engineers—including myself—made a deliberate architectural decision to:

1. Treat Microsoft Graph / Microsoft.Entra as the identity control plane
2. Treat Az modules strictly as the Azure resource and subscription control plane
3. Actively avoid AzureAD/MSOnline and discourage their use

From Microsoft’s marketing and guidance, it is reasonable to conclude that:

Identity and IAM changes should move forward via Graph/Entra, not Az.

However, in practice, Az.Resources still exposes identity-modifying cmdlets such as:

```
Update-AzADUser

New-AzADUser

Remove-AzADUser

```
etc.

What is surprising—and problematic—is that this capability is not clearly documented, positioned, or explained alongside Microsoft’s “Graph is the way forward” narrative.

As a result:

Engineers who closely follow Microsoft guidance end up blocked in customer tenants where Graph write permissions are restricted

Engineers who use Az identity cmdlets complete the same changes immediately via existing RBAC

This creates inconsistent practices, confusion, and a perception that following Microsoft’s recommended path is operationally disadvantageous

This is not an argument that Az identity cmdlets should be removed immediately.
Rather, the issue is lack of explicit guidance.

What’s missing is clarity on:

Whether Az identity cmdlets are:

Transitional

Long-term supported

Operational fallbacks only

When engineers should prefer Graph/Entra

When Az-based identity changes are considered acceptable

How customers should govern identity consistently when multiple mutation paths exist

Today, the reality feels like:

Microsoft.Entra / Graph is marketed as the successor

Az identity cmdlets quietly remain fully functional

Engineers discover this only by accident, not by design

That disconnect between marketing, documentation, and operational behavior is what causes confusion :( especially for platform engineers trying to build clean, future-aligned identity practices.

Thank you!
Alvin

### Script or Debug output

```PowerShell

```

### Environment data

```PowerShell

```

### Module versions

```PowerShell

```

### Error output

```PowerShell

```