The page title was simplified, and the role descriptions now state that the Microsoft Enterprise SSO plug-in performs device and user registration with Microsoft Entra ID. Microsoft Entra ID is described as verifying credentials and proofs and issuing the PRT.

The FAQ now states that identity provider buttons cannot be hidden. Removing a provider from a user flow prevents users from signing up or redeeming invitations with that provider, and `domain_hint` does not change this.

The documentation explains when users may encounter Arkose Labs anti-bot verification before receiving SMS messages or voice calls, including user experience, network requirements, and help-desk guidance.

Microsoft added a conceptual guide describing macOS Platform SSO registration, Secure Enclave device keys, the Platform SSO PRT, app SSO, and the roles of MDM, macOS, the Microsoft Enterprise SSO plug-in, and Microsoft Entra ID.

The article now explains that disabling sign-in sets the service principal’s `accountEnabled` property to `false` and changes Activation status to Deactivated. It also adds steps to restore tenant-local sign-in and notes that other deactivation conditions can still apply.

The documentation describes four separately manageable protections—administrator MFA, user MFA, legacy authentication blocking, and device code flow blocking—for selected Microsoft Entra ID Free tenants. It also explains how these protections work with Conditional Access and which roles can manage them.

The documentation now specifies tenant ID or the tenant’s onmicrosoft.com domain for the issuer URI, says custom verified domains aren’t supported, and requires matching onmicrosoft.com values for domain_hint. It also documents steps to refresh a user flow after provider configuration changes.

Microsoft Entra will enable users to change passwords after secure sign-in using strong credentials (passkey, FIDO2, Windows Hello) without knowing the current password or using SSPR. This feature, disabled by default, requires admin activation and will roll out globally from October to November 2026.

The documentation explains how unrestricted, synced-only, and device-bound-only profiles use platform-specific evaluation, while AAGUID-restricted and attestation-enforced profiles suppress nudges across platforms after one eligible passkey is registered.

The documentation now refers to registered passkeys and available passkey types instead of credentials in the platform-specific nudge suppression guidance and table.

The documentation now states that iOS cross-device registration does not support attestation, while Android does. Attested passkeys can also be registered through Android cross-device flows.

The documentation now states that iOS users can register attested passkeys only directly in the Authenticator app, while Android users can register them directly or through cross-device registration.

The documentation now states that Android users can register attested passkeys directly in the Authenticator app or through a cross-device registration flow. iOS registration remains direct through the Authenticator app.

The documentation now separately states that Android users can register attested passkeys through a cross-device registration flow, while iOS users register them directly in the Authenticator app.

The example now specifies a device-bound profile with attestation enforced and an eligible attested passkey. It states that the nudge is suppressed across operating systems and browsers, without using the platform table.

The example now explicitly states that User 1 signs in on macOS with Chrome and is nudged to register a compatible passkey.

The example now specifies that the user’s only registered passkey is Windows Hello for Business; the nudge is suppressed when they sign in on Windows with Chrome.

The documentation now states that Windows Hello for Business registration doesn’t follow passkey profile restrictions.

The documentation now states that Windows Hello for Business registration behavior is separate from passkey profile restrictions.

The MFA registration campaign documentation now links directly to the passkey profile eligibility guidance for the Microsoft managed registration campaign.

The documentation now states that eligible users can see nudges during interactive sign-ins that satisfy MFA. Silent SSO events, such as refresh token redemption, do not display nudges.

The documentation now explains that Deactivated can result from tenant-local sign-in disablement, app registration deactivation, or Microsoft disablement. It also documents the related properties and clarifies that these conditions can overlap and must be remediated independently.

The article now covers application and agent creation and management. It documents the **Users can create agent blueprints** setting, which administrators can turn off to restrict agent blueprint creation to administrators and Agent ID Developers.

The documentation now links to the “Restricting who can create applications and agents” section in two references, including the application registration error guidance.

The Security Defaults article no longer includes the section describing individual protections, their preview availability, roles, behavior, and management steps.

Step 1 now links to the permissions reference anchor without the `.md` suffix.

The permissions reference now states that Application Developer role holders can update applications they own, in addition to creating application registrations independently of the user registration setting.

Microsoft Purview will enable sensitivity labels for Microsoft Entra cloud security groups starting mid-November 2026, allowing administrators to apply and enforce governance policies on these groups. Labels can be assigned via multiple platforms, cannot yet be changed once applied, and require separate tenant configuration from Microsoft 365 groups.

The article now distinguishes deactivating an app registration from disabling sign-in on a tenant-local service principal. It also explains that activation status includes tenant-local and Microsoft disablement, and that reactivating the app registration does not automatically restore tenant-local sign-in.

Starting November 4, Microsoft Entra will stop automatically granting the AgentIdentity.CreateAsManager permission to agent blueprints. Admin consent will be required for agents to create identities. This change, rolling out worldwide in November 2026, enhances control and auditability of agent identity creation.

The documentation now states that when **Users can create agent blueprints** is set to **Yes**, any tenant user can create an agent identity blueprint and its principal. Otherwise, the Agent ID Developer and Agent ID Administrator roles can create them.

Starting November 4, 2026, default users in Microsoft Entra can create agent blueprints unless administrators disable this via the "Users can create agent blueprints" setting. Admins can restrict this by toggling the setting to No in the Entra admin center before rollout completes in late November.

The documentation now describes adaptive learning for new users’ sign-in behavior and says detection is calculated in real time, replacing the previous learning-period and offline-calculation details.

To strengthen your organization's security posture, Microsoft created a new Microsoft‑managed Conditional Access (CA) policy—Require risk remediation for high‑risk users—in your tenant, along with a new security group for this policy. This policy uses Microsoft Entra ID Protection to identify users at high risk and prompts them to self‑remediate through adaptive risk remediation, allowing users to resolve their own risk without administrator intervention.

The risk detection table now lists Atypical travel as “Real-time” instead of “Offline.” Its Premium requirement and unlikelyTravel identifier are unchanged.

The article’s licensing guidance was updated. It states that the tenant needs at least as many licenses as governed member (non-guest) users, including users who request, approve, or review application access.

The documentation date was updated, and the report description now refers to users and agent IDs when explaining direct access and active assignment mismatches.

The documentation adds postapproval extensions with deferred outcomes and asynchronous validation before assignment provisioning. It also describes collecting attributes such as cost center and project code, along with the required Graph permissions and endpoint configuration.

The documentation describes integrating SAP Access Control with Microsoft Entra entitlement management to govern SAP business roles through catalogs, access packages, and My Access. It covers SAP BTP, Cloud Connector, prerequisites, licensing, and status reconciliation.

The documentation now lists P1 with Microsoft 365 E3, E5, or E7; P2 with E5 or E7; and Governance capabilities with Microsoft Entra Suite and Microsoft 365 E7. The agent identity licensing reference was also updated.

The page now explains self-service sign-up through a user flow and invitation redemption through a custom OIDC provider using the domain_hint authorization parameter.

The article now highlights testing the user flow as the primary next step and adds links for adding applications, managing custom attributes, and routing invited users to an external identity provider.

The overview now states that a Microsoft Entra ID P1 license is required on the configured tenant to change the default redemption order, in addition to configuring trust or scoped access settings.

The documentation now states that changing the default redemption order, like configuring trust or access settings, requires Microsoft Entra ID P1 on the configured tenant.

New guidance explains how to use the domain_hint parameter to route invited external-tenant users to configured OpenID Connect, SAML/WS-Federation, or social identity providers. It covers prerequisites, invitations through Microsoft Graph or the admin center, and custom invitation emails.

The documentation now clarifies that invited users from another Microsoft Entra tenant use the default redemption flow unless an application explicitly routes them to a custom OIDC provider. The related link was also updated.

The user-creation example replaces the source tenant ID with its primary domain name in the issuer value and defines the new placeholder with an example domain.

A new guide explains how directly connected local resources can remain reachable while Private Access is enabled, including routing behavior, prerequisites, and configuration steps.

The documentation adds Performance mode, which routes user traffic to the connector with the lowest measured network latency. It also clarifies that connector load balancing applies only to Microsoft Entra Private Access applications, not application proxy applications.