Entra ID What's New: Access Reviews GA, Passwordless Teams

Microsoft Entra ID opened September 2026 with one of the largest monthly updates of the year — two generally available governance features, a broader passwordless win for Teams devices, two public previews that extend hybrid identity in both directions, and two security-related change announcements. If you manage identity at scale, this is the month to update your roadmap.

The theme across all seven items is consolidation: consolidate how you review access, consolidate how you authenticate shared devices, consolidate how you provision identity, and consolidate which roles can respond to incidents.

Here’s what changed, why it matters, and what to do about it.

1. User-centric Access Reviews — General Availability

Status: GA Action required: Evaluate for your access review program

Access Reviews now work the way reviewers actually think — by user, not by resource. User-centric Access Reviews (UAR) let a reviewer see every resource one user can access inside a single review, instead of running separate reviews per group or per application.

What’s Included

• Unified view: Groups, connected applications, and disconnected (custom data-provided) applications in one review scope
• Disconnected app support: Upload CSV access data so applications that never integrate with Entra ID can still be governed
• Reviewer experience: Decisions are made in the My Access portal against a user-centric list of resources
• Licensing: Requires Microsoft Entra ID Governance or Entra Suite

Why This Matters

Traditional access reviews are resource-centric: pick a group, review its members, repeat for every group and app. For a user with access to 30 resources, that means their access is evaluated 30 times by 30 different reviewers — or, more likely, never comprehensively reviewed at all.

User-centric reviews flip the model. One reviewer responsible for a user can evaluate all of that user’s access in a single pass. The disconnected-application support is the sleeper feature here: it brings shadow IT and non-integrated SaaS into your governance program without writing a single line of integration code.

What Administrators Should Do

1. Identify your highest-risk users — start UARs with privileged or vendor users who accumulate the most access
2. Prepare CSV data for disconnected apps — inventory apps outside Entra ID and map who has access
3. Assign owners — every catalog resource and user should have a clear reviewer
4. Run a pilot UAR alongside your existing reviews before restructuring the full program

2. Clone Workflows in Lifecycle Workflows — General Availability

Status: GA Action required: Simplify your workflow portfolio

Lifecycle Workflows administrators can now clone an existing workflow and use it as the starting point for a new one. All configuration, tasks, execution conditions, and settings are copied; the clone opens on the Review and create page where you can adjust anything before saving.

What’s Included

• Two entry points: The Clone action in the workflow list, or the “Clone an existing workflow” card when creating a workflow
• Full fidelity: Tasks, triggers, and settings carry over
• Scope: Available in the Entra admin center (not via Microsoft Graph)
• Role needed: Lifecycle Workflows Administrator

Why This Matters

Many tenants run dozens of Lifecycle Workflows that differ by only one or two parameters — different departments, different triggers, different task sequences. Previously each one had to be built from scratch or from a template. Cloning turns an existing, tested workflow into a starting point, cutting configuration time from hours to minutes and reducing the errors that come from rebuilding complex task logic by hand.

What Administrators Should Do

1. Audit existing workflows — find near-duplicate workflows that can be regenerated from a single source
2. Establish a clone convention — define naming and documentation standards so clones stay manageable
3. Test clones in a staging tenant before applying them to production schedules

3. Entra Resource Accounts for Teams Devices — General Availability

Status: GA for Teams Rooms, Panels, and Common Area Phones Action required: Plan migration of shared device accounts

Passwordless authentication for Teams shared devices is now generally available across the device lineup. Microsoft Entra Resource Accounts replace legacy password-based sign-in with hardware-protected, device-bound credentials — the same model Microsoft uses for passwordless resource accounts in Teams Rooms on Windows, now extended broadly.

What’s Included

• Migration path: Teams Rooms Pro Management Portal → Planning → Resource Accounts → Migration tab
• Licensing: Teams Rooms or Teams Shared Space license required
• Identity: Resource account can be Entra ID only, synchronized from AD, or backed by a third-party federated IdP
• Known limitation: A replacement device must be set up with a password first, then migrated

Why This Matters

Shared-device passwords are a chronic security problem: they’re shared by nature, rotated infrequently, and stored in places that leak. If a Teams Room password was ever compromised, an attacker had interactive sign-in as a licensed user on hardware you don’t control. Device-bound credentials remove the password entirely — there is nothing to phish, spray, or steal. This also reduces the support burden from stale passwords breaking room sign-in at the worst possible moment.

What Administrators Should Do

1. Inventory shared device accounts — every Teams Room, Panel, and phone with a password-based account is a candidate
2. Verify device readiness — check Windows build, Android version, and Teams app versions against requirements
3. Stage migrations — use the Pro Management Portal migration tool on a pilot room first
4. Update the password vault — remove shared device credentials from your secrets management once migrated

4. Synchronize sAMAccountName with Entra Domain Services — Public Preview

Status: Public Preview Action required: Evaluate for legacy application compatibility

Entra Domain Services managed domains can now synchronize sAMAccountName values from the onPremisesSamAccountName attribute in Entra ID — enabling legacy applications that depend on sAMAccountName to keep working when you move workloads to Azure.

What’s Included

• New domains: Enabled by default
• Existing domains: Opt-in under Domain Services security settings
• Requirements: Enterprise or Premium SKU (not Standard); Application Administrator and Groups Administrator roles to change the setting
• Cloud-only users: Continue using mailNickname-based generation when no onPremisesSamAccountName exists
• Constraints: sAMAccountName must be unique, 20 characters or fewer, and free of unsupported special characters

Why This Matters

Plenty of on-premises applications were written before UPNs were universal. They authenticate or authorize against sAMAccountName, and when you lift those workloads into Azure with Entra Domain Services behind them, mismatched account names break file shares, SQL logins, and service accounts. Having Entra DS honor the real sAMAccountName removes a whole class of “it worked on-premises” migration failures.

What Administrators Should Do

1. Check your SKU — this preview does not apply to Standard-tier managed domains
2. Review onPremisesSamAccountName coverage — synced users need the attribute populated in Entra ID
3. Test in a non-production domain first — validate legacy app authentication before enabling broadly

5. Cloud Sync: Manage Identity Lifecycle from the Cloud — Public Preview

Status: Group provisioning GA; user provisioning Public Preview Action required: Evaluate as a Connect Sync migration path

Entra Cloud Sync now works in both directions. In addition to provisioning from AD to Entra ID, Cloud Sync can provision users, groups, and group memberships from Entra ID back into on-premises Active Directory. Cloud-first organizations can now keep Entra ID as the authoritative source while still populating AD for legacy applications, file servers, and Kerberos-dependent systems.

What’s Included

• Supported identities: Cloud-native users, Source of Authority-converted users, B2B guests, security groups
• Prerequisites: Provisioning agent v1.1.3730.0+, AD DS schema with msDS-ExternalDirectoryObjectId (Windows Server 2016+), Entra ID P1
• Limits: Groups over 50,000 members and tenants over 150,000 objects are not supported
• Sync cadence: Group provisioning runs every 20 minutes
• SoA conversion note: Preserves group SID and can keep the original OU path

Why This Matters

This is the missing piece of the Connect Sync → Cloud Sync migration story. The reason many tenants stayed on Connect Sync wasn’t the sync engine itself — it was the directory-to-AD dependency. Cloud Sync’s reverse provisioning removes that blocker. Combined with earlier releases, you can now run a genuinely cloud-first identity lifecycle: HR writes to Entra ID, Entra ID provisions users, and AD gets exactly the accounts on-premises workloads need — with no Connect Sync server in the path.

What Administrators Should Do

1. Map AD-dependent applications — know exactly what still needs on-premises accounts before you migrate
2. Plan the agent footprint — the provisioning agent replaces Connect Sync servers in this model
3. Test B2B guest provisioning — external users flowing into AD is powerful but needs careful scope control
4. Watch the object limits — very large tenants will still need Connect Sync

6. Security Administrator Role Expansion — Change Announcement

Status: Rolling out, complete by end of September 2026 Action required: Review role assignments and SOC runbooks

The built-in Security Administrator role is being expanded to include identity incident response actions for non-privileged users: disable or enable user accounts, revoke active sessions, and force password resets.

What’s Included

• New permissions: Disable user, enable user, revoke sessions, force password reset
• Scope: Non-privileged users only — not Global Administrators or other high-privilege accounts
• Governance: Existing auditing and least-privilege controls continue to apply
• Context: Follows the SOC Identity Responder role (June 2026 preview) and the Security Operator extensions from earlier this year

Why This Matters

In many organizations, identity incident response requires two or three roles: Security Administrator for triage, plus Identity Administrator or User Administrator for the containment actions. During an active incident that handoff costs minutes — and minutes matter when an account is compromised. This expansion lets SOC teams using Security Administrator contain identity incidents directly, while the non-privileged-user scope keeps the blast radius of the role itself in check. Audit trails still capture every action.

What Administrators Should Do

1. Review Security Administrator assignments — this role becomes more powerful; revalidate who holds it
2. Update SOC runbooks — document that containment actions for non-privileged users no longer require escalation
3. Verify audit coverage — confirm your SIEM ingests the disable, session revocation, and password reset events

7. User.ReadBasic.All Permission Scope Update — Security Fix

Status: Rolling out Action required: Audit applications using User.ReadBasic.All

Microsoft is fixing an information disclosure issue in Microsoft Graph: the User.ReadBasic.All permission was unintentionally allowing applications to read app role assignments and license details, not just the basic profile properties it is scoped for.

What’s Included

• The fix: Removes unintended access to appRoleAssignments and licenseDetails
• Intended scope unchanged: displayName, givenName, id, mail, photo, securityIdentifier, surname, userPrincipalName
• For apps that need more: Use User.Read.All for app role assignments, LicenseAssignment.Read.All for license details (User.Read.All covers both)
• Impact: Not a breaking change for apps using the permission as intended

Why This Matters

This is the kind of vulnerability that rarely makes headlines but quietly matters: an app provisioned for the least possible privilege — reading names and email addresses — could also enumerate which roles every user holds and what licenses they have. That turns a low-privilege app into a reconnaissance tool for privilege escalation planning. The fix is the right call, and it’s a reminder to periodically re-validate what your delegated and application permissions actually expose.

What Administrators Should Do

1. Audit apps with User.ReadBasic.All — list every app granted it and what data it legitimately needs
2. Upgrade where needed — request User.Read.All or LicenseAssignment.Read.All for apps that genuinely need assignment or license data
3. Review consent and grant history — look for apps that may have been exploiting the unintended access
4. Document the change — update your application permission matrix before the fix reaches your tenant

Also in the September Roundup

Three items featured in Microsoft’s September 2026 roundup were already tracked on this series:

• Tenant Governance GA (August 10, 2026) — tenant-wide governance settings now generally available
• MCP Firewall Preview (August 6, 2026) — access control for Model Context Protocol servers in the age of agentic AI
• MemberOf retirement (MC1448379) — the MemberOf rule operator in dynamic groups, administrative units, and entitlement management retires November 3, 2026; migration guidance is available in Message Center

Key Dates to Watch

• End of September 2026: Security Administrator role expansion fully rolled out
• October 1, 2026: Legacy risk policies in Entra ID Protection retired
• November 3, 2026: MemberOf rule operator retired in dynamic groups, AUs, and entitlement management

Follow Kevin on X at https://x.com/kkaminsk for daily Microsoft Entra updates and analysis.