The breaking-changes documentation now uses a different client application ID in its OAuth authorization URL and description.

The breaking-changes documentation updates the sample OAuth authorization request and its description with a different client application ID.

The new page lists SCIM API, authentication, testing, support, documentation, customer deployment, and cloud compliance requirements for publishing user provisioning integrations in Microsoft Entra App Gallery.

A tutorial now explains how to use the Microsoft Entra App Validator browser extension with non-gallery enterprise applications, including IdP- and SP-initiated SSO, certificate scenarios, optional Single Logout, and result submission.

The documentation explains how to use the Microsoft Entra App Validator browser extension to test an OIDC multitenant app, review fixes, and generate the Test ID required for gallery publishing.

Microsoft added a page detailing SAML 2.0 and multitenant OpenID Connect requirements for validating and publishing applications in the Entra App Gallery, with links to general prerequisites and provisioning requirements.

The guide title now uses quoted punctuation, and the table separator spacing was standardized.

The documentation now states that standard users can create groups by default regardless of SSGM, and that SSGM controls behavior only in the My Groups portal. The MSODS reference was removed.

The page title changed from “What is single sign-on (SSO) in Microsoft Entra ID?” to “What is single sign-on in Microsoft Entra ID?”

The example request now uses client ID `ffffffff-eeee-dddd-cccc-bbbbbbbbbbb0` instead of `00001111-aaaa-2222-bbbb-3333cccc4444`.

The documentation explains how to access the Microsoft Application Network portal and submit requests to update SSO, MDM, or user provisioning details, upgrade SSO, or remove an application listing.

The documentation separates shared prerequisites from SSO and SCIM requirements, with dedicated guidance for each capability. Applications supporting both must complete validation for both.

The article now covers prerequisites for validating and publishing apps, with updated wording and links. Detailed portal submission, request tracking, implementation, and update/removal instructions were removed.

The permission-addition and permission-removal examples now use different sample object and client IDs.

The add and remove permission examples now use app registration ID `ffffffff-eeee-dddd-cccc-bbbbbbbbbbb0` instead of `00001111-aaaa-2222-bbbb-3333cccc4444`.

The examples for adding and removing Microsoft Graph permissions now use app registration identifier `00001111-aaaa-2222-bbbb-3333cccc4444` instead of the previous sample identifier.

The Microsoft Graph Update application example now uses a different app registration object ID when adding the documented delegated permissions.

The permission-management examples now use app registration identifier `ffffffff-eeee-dddd-cccc-bbbbbbbbbbb0` instead of `00001111-aaaa-2222-bbbb-3333cccc4444` when adding or removing Microsoft Graph permissions.

The documentation now distinguishes standard token validation, user mapping, and authentication policy checks from the additional domain-consistency validation provided by Federated Token Validation Policy. It also clarifies root-domain matching for federated sign-ins.

The documentation wording about Microsoft Entra joining Arc-enabled machines and disconnecting them from another domain was updated.

The how-to documentation revised its guidance explaining that enabling the capability joins an Arc-enabled machine to Microsoft Entra and is intended for machines not joined to another domain.

The guidance on enabling sign-in for Arc-enabled machines was revised, including their Microsoft Entra join behavior and domain-joining scenario.

The documentation fixes a typo in the sentence explaining that an Arc-enabled machine becomes Microsoft Entra joined and updates nearby truncated wording.

The documentation now states that this capability is intended for Arc-enabled machines not planned to join another domain, such as on-premises Active Directory or Microsoft Entra Domain Services.

Microsoft Entra now applies system-preferred authentication to first-factor sign-ins for tenants in the Microsoft managed state, selecting the most secure registered method. Rollout is from late June to late September 2026. Tenants can keep or change this setting and should update user guidance accordingly.

A tutorial now documents the self-service publishing workflow, including validation prerequisites, submission creation, capability selection, required application details, Microsoft review, and draft tracking.

The page title now says “Microsoft Entra ID,” and several table separators were reformatted for consistent Markdown presentation.

The documentation now explains that Agent ID objects are covered through their underlying directory object types, including user accounts as user objects and identity blueprints as application objects.

Removed an extra space from the Help desk admin row in the documentation table.

Starting with broker version 2.0.2, Microsoft Single Sign-on for Linux uses Microsoft Entra join instead of registration for device trust. Existing upgraded devices must be re-joined and re-enrolled.

The version history now records agent version 4.5.2614.0, including credential-security and key-rotation improvements, better cloud compatibility and telemetry resilience, and installation, registration, reliability, and quality improvements.

The installation documentation now points to download ID 108777 for the AD FS and AD Domain Services agents instead of 108565.

Microsoft Single Sign-on for Linux version 2.0.2 and later uses Microsoft Entra join for device trust instead of device registration. The documentation also adds MSAL integration support guidance and updates device removal terminology.

The documentation now references the Chrome Windows 10 Accounts extension and Mozilla Firefox v91+ Windows SSO setting.

The recovery model documentation now lists agent user accounts, agent identity blueprints, agent identities, and agent identity blueprint principals among covered objects.

Enhanced synchronization can source sAMAccountName for hybrid users from onPremisesSamAccountName in Microsoft Entra ID. Existing domains retain current behavior until enabled; enabling updates existing hybrid users during synchronization, while cloud-only users without the source value continue using mailNickname-based generation.

The documentation now states that the “Users may join devices to Microsoft Entra ID” setting applies to Windows 10 or newer, macOS, and Linux. It also adds troubleshooting guidance to verify registration or join settings when users encounter errors.

The article now states that a governance relationship and related resources are established only when the home tenant has a default governance policy template.

The documentation now states that the Tenant Creator role is required regardless of the “Restrict non-admin users from creating tenants” setting.

The documentation now explains that relative time-based comparisons expand the standard time-based attribute trigger. During preview, the admin center shows two choices, but both represent the same trigger.

Administrators can configure triggers using operators, offsets from 0 to 180 days, before or after event timing, and supported user attributes such as hire date, leave date, and creation date. Both the workflow and its schedule must be enabled for evaluation.

Documentation describes relative comparisons using Exactly, Between, or Less than or equal to, with event offsets from 0 to 180 days before or after supported user-attribute dates. The admin center temporarily shows two choices for the same time-based trigger.

The documentation adds examples describing how designated users can request access packages for others and clarifies that both requestors and targets need the required license.

The allowed offset for Days from event, and Days to event when using Between, increased from 180 to 365 days.

The Event user attribute description in the lifecycle workflow execution conditions documentation was reformatted.

The page removes the standalone setup section and detailed steps for configuring relative time-based triggers, including timing options, offsets, supported attributes, and enablement notes.

The documentation now describes the Time based attribute V2 trigger, including Exactly, Less than or equal to, and Between comparisons with offsets from 0 to 180 days before or after a date attribute. It also documents that workflows and schedules must be enabled and that V2 has no three-day catch-up window.

The password migration documentation now uses a different example API application identifier.

Starting in November 2026, eligible Windows clients automatically receive Global Secure Access upgrades through Windows Update. Version 2.32.294 also adds Prefer local network, faster tunnel creation, and other fixes and improvements.

The documentation now uses the full names for GCC and GCC-H and clarifies that Global Secure Access is available in GCC but not yet supported in GCC-H, Department of Defense, or other government or sovereign cloud environments.

The documentation received a minor formatting change with no substantive content changes identified.

The documentation now explicitly states that Global Secure Access is available in GCC, but not supported in GCC-H, Department of Defense, or other government and sovereign cloud environments.

The August 21, 2026 release adds Home Network traffic controls, a Connections page, agentic detection support, and Secure DNS bypass. It also includes connectivity, sign-in, tunnel, cache-reset, and crash fixes.

The documentation now states that version 1.1.26060207 includes com.microsoft.autoupdate2 and that an existing installation may conflict with Intune detection rules. It also advises optionally removing that app from the Included apps list.

The release history now lists the macOS client as available for download on August 24, 2026, instead of August 21, 2026.

The Netskope integration example now uses different values for the tenantId and userId fields.