Entra ID What's New: SSPR Enforcement, Passkey Campaigns, SCIM

Microsoft Entra ID’s first week of September 2026 delivered a mix of enforcement, documentation, and domain consolidation. The biggest item is live today: SSPR stopped accepting unregistered directory contact data for password resets. But there’s more beneath the surface — passkey campaign guidance got a documentation overhaul, SCIM 2.0 APIs gained granular permissions, four self-service portals are consolidating to a single domain, and Viva Engage is tightening its admin model.

If you manage identity for an organization, at least three of these items need your attention before the end of the month.

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

1. SSPR Enforcement Live — Unregistered Contact Data No Longer Accepted

Status: Enforcement active September 7, 2026 Action required: Identify users without registered authentication methods

As of today, Microsoft Entra ID terminated the use of unregistered directory contact data for Self-Service Password Reset (SSPR). Mobile numbers, business phones, and secondary emails stored as directory attributes — mobilePhone, businessPhone, otherMails — no longer function as verification methods unless the user has explicitly registered them through the authentication methods registration portal.

What Changed

• Before: SSPR accepted contact data from directory attributes as valid proof of identity, even if the user never personally confirmed those contacts
• After: Only authentication methods that users or administrators have explicitly registered are accepted
• Registration campaign: Began July 6, 2026, prompting affected users to register methods after sign-in
• Scope: All users including administrators, across Public cloud, GCC, GCC High, and DoD
• Estimated impact: Approximately 14% of SSPR verifications previously relied on unregistered directory contact data

Why This Matters

This change closes a security gap that undermined the entire premise of self-service password reset. When SSPR accepts unverified directory data, anyone who can populate a user’s mobilePhone or otherMails attribute — including a compromised admin account or a directory sync process with weak controls — can intercept that user’s password reset flow. The fix ensures verification methods are tied to user intent and proof of possession, not just admin-entered data.

The practical risk today is helpdesk overload. Users who ignored the registration campaign and relied on legacy directory fields are now locked out of self-service recovery. An administrator must manually set a temporary password and guide them through registration. Organizations that proactively ran the registration campaign and enabled Conditional Access policies requiring method registration will see minimal disruption.

What Administrators Should Do

1. Check the registration report — In the Entra admin center, go to Security → Authentication methods → User registration details. Export the list of users without a registered method and prioritize privileged accounts
2. Prepare the helpdesk — Brief support staff on the enforcement, provide a script for manual password reset plus guided registration
3. Enable registration enforcement — Consider a Conditional Access policy requiring users to register authentication methods, scoped to trusted networks or managed devices
4. Communicate to users — Send targeted notifications to accounts still without registered methods, with direct links to the registration portal

2. Passkey Registration Campaign Guidance — Three States Defined

Status: Documentation updated September 5, 2026 Action required: Review campaign configuration

Microsoft Learn documentation for passkey and Authenticator registration campaigns now defines three explicit campaign states, replacing the previous less-structured guidance. The update comes as the passkeys-by-default rollout — activated September 1, 2026 — continues through the end of the month.

The Three Campaign States

Method-Specific Eligibility

The documentation now specifies eligibility and prompting conditions for each method type:

• Authenticator campaigns: Require the Authenticator app to be configured as an authentication method in the tenant. Users with existing strong methods may not be prompted.
• Passkey campaigns: Require passkeys enabled in the authentication methods policy. Users enabled for SMS or voice are auto-eligible.
• Rollout window: The updated experience is rolling out through the end of September 2026. Tenant behavior may vary during the rollout — not all tenants will see the new states immediately.

Why This Matters

The passkeys-by-default rollout is the most consequential authentication change in Entra ID this year. Users enabled for SMS or voice are being automatically enabled for passkeys and prompted to register at their next MFA sign-in. The three-state model gives administrators a clear lever: let Microsoft manage the campaign, take explicit control, or suppress it entirely (useful for tenants with their own passkey deployment plans).

The temporary opt-out API (Graph Beta, passkeyDynamicMigration property) remains available through February 1, 2027, but it only delays the September 2026 auto-enablement. The February 2027 SMS/voice retirement has no opt-out.

What Administrators Should Do

1. Check your campaign state — In the Entra admin center, navigate to Authentication methods → Registration campaign. Verify which state is active
2. Review authentication methods policy — Ensure passkeys are enabled in the policy so the campaign can function correctly
3. Monitor registration progress — Use the authentication methods usage report to track how many users have registered passkeys versus how many are still on SMS/voice
4. Plan for February 2027 — Even if you opt out now, start building the transition plan. Microsoft-provided SMS/voice will be fully retired on that date with no extension

3. SCIM 2.0 API Reference — Granular Permissions and Higher Page Limits

Status: Documentation updated September 5, 2026 Action required: Review SCIM provisioning app permissions

The SCIM 2.0 API reference for Microsoft Entra ID received a substantial documentation update on September 5, covering page sizes, filters, granular permissions, and schema corrections. These are documentation changes, not new API capabilities — the APIs already supported these features, but the reference now properly documents them.

What’s New in the Reference

Page sizes and filters:

• Up to 999 users per page when the projection excludes the manager attribute
• New filter types documented: active users, negated suffix matches, group membership, group ownership
• Performance guidance for choosing page sizes and filter combinations

Granular least-privilege permissions:

• Operation-specific permissions for basic user reads, user creation and updates, group creation, and group membership changes
• Provisioning applications can now align consent requests to their actual workflow operations instead of requesting broad permissions
• The permissions table replaces individual inline links with a consolidated reference to the Microsoft Graph permissions reference

Schema corrections:

• User:ownedGroups and Group:owners documented as read-only, multi-valued attributes
• Their IDs can be used in filter queries but are never returned in response bodies
• Corrected the members.value response-body description for groups

Why This Matters

SCIM provisioning is how most organizations automate user lifecycle management across SaaS applications. The previous documentation gap meant developers either over-provisioned permissions (requesting full user read/write when they only needed to create users) or discovered filter capabilities by trial and error. The granular permissions mapping lets you implement least-privilege access for provisioning apps — a security best practice that also simplifies app approval and compliance reviews.

The 999-user page size is a meaningful performance improvement for large tenants. Combined with the new filter types, provisioning jobs can retrieve targeted user sets more efficiently and reduce API call volume.

What Administrators Should Do

1. Audit SCIM provisioning apps — Review the permissions granted to each SCIM-connected application and align them with the new granular options
2. Update provisioning configurations — If your SCIM clients use smaller page sizes, test 999-user pages with manager-excluded projections
3. Test new filters — Evaluate whether group membership or ownership filters can replace custom logic in your provisioning workflows
4. Validate schema expectations — If your SCIM client expects ownedGroups or owners in response bodies, update it to use filter queries instead

4. My Account Domain Migration — Consolidation to cloud.microsoft

Status: Plan for change — rollout late November 2026 Source: MC1462460 Action required: Update network allowlists

Microsoft Entra is consolidating its self-service identity management portals under a single domain. Starting late November 2026, four separate portals will converge under myaccount.cloud.microsoft.

Portals Being Consolidated

What Changes

• Users: No action required. Automatic redirects from old URLs to the new domain
• Core functionality: Unchanged — all existing workflows continue to work
• Admins: Ensure *.cloud.microsoft domains are allowed in network, proxy, firewall, and endpoint policies
• Documentation: Update internal guides, bookmarks, and training materials that reference the old URLs

Why This Matters

The consolidation aligns with Microsoft’s broader move to the cloud.microsoft domain namespace, which began with Microsoft 365 services. Having four separate portals for identity self-service — My Account for profile management, My Apps for app launcher, My Access for access reviews, and My Staff for delegated admin — created a fragmented user experience. The unified domain provides a single entry point while preserving the individual experiences behind it.

The network allowlist requirement is the real action item. If your organization restricts access to Microsoft domains through proxy, firewall, or endpoint policies, users will lose access to all four portals when the migration takes effect unless *.cloud.microsoft is allowed.

What Administrators Should Do

1. Audit network policies — Check proxy, firewall, and endpoint allowlists for myaccount.microsoft.com, myapps.microsoft.com, myaccess.microsoft.com, and mystaff.microsoft.com. Add *.cloud.microsoft where applicable
2. Update internal documentation — Revise user guides, helpdesk scripts, and training materials with the new URL
3. Test in advance — Microsoft has not announced a pre-rollout test window, but you can verify that myaccount.cloud.microsoft resolves correctly from your network today
4. Communicate to users — Send a notification in late October about the upcoming URL change, emphasizing that bookmarks will automatically redirect

5. Viva Engage Permissions Tightened — Entra Roles Required

Status: Plan for change — late September 2026 Source: MC1465773 Action required: Review and update role assignments

Starting late September 2026, Microsoft Viva Engage will require Microsoft Entra permissions for community and membership administration tasks that were previously available to Verified Admins and Network Admins without specific Entra role assignments.

What’s Changing

• Community creation and management: Now requires Yammer Administrator role or Community Admin assignment
• Membership management: Same Entra role requirement — Verified Admins and Network Admins without these roles will lose community management capabilities
• Scope: All Viva Engage tenants worldwide
• Timeline: Late September 2026 (exact date not specified in Message Center)

Why This Matters

Viva Engage (formerly Yammer) has long operated with its own admin model that didn’t fully align with Entra RBAC. Community management was possible with Yammer-specific admin roles that had no Entra equivalent. This change brings Viva Engage in line with Microsoft’s identity-first admin model, where every administrative action is governed by an Entra role.

The risk is operational: organizations that rely on Yammer Network Admins or Verified Admins for community management will see those capabilities removed. Without proactive role assignment, community management breaks silently.

What Administrators Should Do

1. Inventory current Viva Engage admins — Export the list of users with Verified Admin or Network Admin roles in Yammer
2. Assign Entra roles — For users who need to continue managing communities, assign either the Yammer Administrator Entra role or explicitly designate them as Community Admins
3. Update training materials — Revise admin documentation to reflect the Entra role requirement
4. Monitor after rollout — Watch for helpdesk tickets about community management failures, which will indicate missed role assignments

6. Workload Identity Namespace Clarification

Status: Documentation update September 5, 2026 Action required: Review IaC templates and CLI scripts

Microsoft clarified a namespace distinction that has been causing automation failures: Azure CLI commands and infrastructure-as-code templates must use the provider namespace Microsoft.Storage, not Microsoft.Storage/*. The * format is only an Azure portal display convention and is not accepted by the API.

What’s Changed

• Portal display: Shows Microsoft.Storage/* for visual clarity
• API, CLI, and IaC: Requires Microsoft.Storage (without the wildcard)
• Documentation now explicitly states: Azure CLI commands and IaC templates must use Microsoft.Storage

Why This Matters

This is a small documentation fix that solves a real problem. Automation scripts that copied the portal’s display format verbatim would fail at deploy time with namespace errors. The clarification removes a source of confusion for workload identity federation configurations involving Azure Storage.

What Administrators Should Do

1. Audit IaC templates — Search Bicep, Terraform, and ARM templates for Microsoft.Storage/* and replace with Microsoft.Storage
2. Review CLI scripts — Check Azure CLI and Azure PowerShell scripts that reference workload identity federation for Storage
3. Update documentation — Revise internal runbooks that may have propagated the portal display format

Also Worth Tracking

Security Administrator Role Expansion

The Security Administrator built-in role is being expanded with identity response actions for non-privileged users: disable/enable accounts, revoke active sessions, and force password resets. Documentation now lists Security Administrator alongside Helpdesk Administrator and User Administrator for invalidating non-admin users’ refresh tokens. The rollout is completing by the end of September 2026. This was covered in detail in our September 2, 2026 update.

New Message Center and Roadmap Items

• MC1423108 — Improved restore experience for Authenticator passkeys on iOS
• RM567885 — Entra ID Backup & Recovery (roadmap)
• MC1438571 — Default visibility of additional profile card properties in M365 profile cards
• RM568784 — Defender for Identity: Unified identity timeline on the Identity page
• RM569446 — Enhanced sAMAccountName support for Entra Domain Services (roadmap)

Key Dates to Watch

• End of September 2026: Security Administrator role expansion fully rolled out; Viva Engage permissions change takes effect
• October 1, 2026: Legacy risk policies in Entra ID Protection retired
• October 5, 2026: SSPR registration campaign begins (for any remaining phases)
• November 3, 2026: MemberOf rule operator retired in dynamic groups, AUs, and entitlement management
• Late November 2026: My Account domain migration to myaccount.cloud.microsoft
• February 1, 2027: Microsoft-provided SMS and voice authentication fully retired

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