The App Gallery provisioning requirements now instruct integrators to validate SCIM endpoints against the Microsoft Entra provisioning service and submit the results with their gallery submission.

The tutorial explains how Microsoft Entra Cloud Sync provisions cloud-managed users, a security group, and group membership to Active Directory Domain Services for access to a Kerberos-based on-premises application. User provisioning is identified as being in preview.

The documentation updates diagram descriptions and the provisioning example link. It also clarifies that AD-provisioned group members must have AD accounts, including eligible cloud-managed users and cloud-created security groups; synchronized users still require onPremisesObjectIdentifier.

A new conceptual article describes how Cloud Sync scopes, matches, maps, and writes users, groups, and memberships from Microsoft Entra ID to AD DS, including anchor-based matching and user source-of-authority scenarios.

The article now documents provisioning users and groups from Microsoft Entra ID to on-premises AD DS, including prerequisites, deployment options, scoping filters, attribute mappings, and testing. Users-only and users-and-groups options are marked Preview.

A new guide documents testing users or groups on demand, reviewing safeguards and notifications, enabling configurations, handling quarantines, restarting sync, and removing configurations. Group tests can include up to five members.

Adds an article covering prerequisites and license requirements for provisioning users and groups from Microsoft Entra ID to on-premises AD DS with Cloud Sync. It also links to configuration, testing, deployment, and agent-installation guidance.

The article now explains using directory extensions to filter groups for provisioning and to map attribute values to Active Directory users. It adds separate Groups and Users examples, prerequisites, and related guidance.

The guidance now describes testing Entra ID-to-Active Directory changes on a single user or group before enabling them broadly. It adds separate workflows, retains the five-member group limit, and explains result statuses, retries, and testing another object.

The article now covers directory extensions for users and groups when provisioning from Microsoft Entra ID to Active Directory, with updated examples, prerequisite wording, links, and related content.

The documentation removed the Repair-AADCloudSyncToolsAccount section because the cmdlet is obsolete.

The article now states that it covers provisioning from Active Directory to Microsoft Entra ID and links to the separate article for provisioning from Microsoft Entra ID to Active Directory.

The tutorial covering group provisioning to on-premises AD DS, scoping recommendations, and group/user SOA scenarios was deleted.

The documented ServicePrincipalId example was replaced with a generic UUID.

The Microsoft Entra tutorial for configuring automatic user provisioning to Rouse Sales has been deleted.

New documentation explains how provisioning can clear an existing target attribute when its source value is null or empty. The capability is opt-in, requires enabling “Flow null values” on both source and target mappings, and supports only single-valued attributes in specified inbound scenarios.

The documentation now states that null values are not sent by default. Clearing attribute values is available only in preview for API-driven inbound provisioning apps and isn’t supported for other provisioning scenarios.

The configuration article now links to documentation for clearing attribute values (Preview).

The FAQ now states that the /bulkUpload endpoint can clear existing user attributes and links to configuration guidance. It also clarifies that the endpoint cannot delete users and recommends Lifecycle Workflows for automated deletion after termination or disablement.

The synchronization documentation now describes enhanced support for synchronizing sAMAccountName with Microsoft Entra Domain Services and links to dedicated guidance.

The tutorial now explains that `{enterprise}` in the GitHub.com SCIM tenant URL is the enterprise slug (account name).

The article’s Microsoft MCP Server for Enterprise overview and setup links changed from Microsoft Learn paths to the EnterpriseMCP GitHub repository. The article continues to describe the service as preview, global-service-only, and read-only.

The Puzzel provisioning article now documents OAuth2 Client Credentials Grant authentication. It adds steps to create an OIDC client, set token lifetimes to 3600, generate a shared secret, and enter the client ID, secret, and token endpoint.

The tutorial now states that Client Credentials Authentication is supported.

The tutorial now documents entering a Tenant URL, Client identifier, Client secret, and OAuth token endpoint, and includes a list of SCIM user attributes and data types.

The account discovery documentation now links to the Microsoft MCP Server for Enterprise GitHub repository instead of Microsoft Learn pages for investigating reports and provisioning an MCP client.

The documentation now refers to the **Advanced Options** dropdown instead of **Show advanced options**, and directs administrators to **Edit schema** for modifying attribute mappings.

The documentation replaces the former Mappings-based steps with a Scoping filters wizard covering assignment-based and attribute-based filtering for users and groups. Existing operator details and limitations remain documented.

The documentation replaces older attribute-mapping navigation with the newer labels: **Advanced Options**, **Edit target User attributes**, and **Edit schema**.

The article now directs administrators to Manage > Attribute Mapping, with mappings organized by Users and Groups. It documents row-level edit and delete controls, group sync via Scoping filters, and the Advanced Options menu for custom attributes.

The documentation now says to open Expression Builder from the left navigation menu instead of Attribute Mapping > Advanced Options. The page date was also updated from March 4, 2025, to August 6, 2026, and the access screenshot was removed.

The documentation removes an example image and the instructions to enable or disable group provisioning through Attribute Mapping. It now directs administrators to the Scoping filters page for apps that support group sync.

The documentation now directs administrators to Provisioning > Manage > Attribute Mapping > Advanced Options > Edit schema, replacing the previous navigation labels and path.

The documentation now says to open the **Advanced Options** dropdown, then select **Expression builder**, on the attribute mapping page. This replaces the previous **Show advanced options** wording.

The documentation replaces the previous Attribute Mappings instructions with the current Attribute Mapping page, Advanced Options dropdown, and Edit target User attributes selection.

The FAQ changes “Scoping filter” to “scoping filter” and clarifies that administrators define scoping filter rules to include or exclude users from processing. The existing Sales example remains.

The documentation now refers to the **Advanced Options** dropdown and **Edit target User attributes** instead of the former UI labels.

The documentation replaces the old “Show advanced options” and “Edit attribute list for ScimOnPremises” labels with “Advanced Options” and “Edit target User attributes.”

The documentation replaces the old **Show advanced options** checkbox and **Edit attribute list for ScimOnPremises** labels with **Advanced Options** and **Edit target User attributes**.

The guide now refers to using “scoping filters” instead of the “Source Object Scope” field when selecting users for provisioning to Active Directory.

The instructions now refer to the Attribute Mapping page, the Advanced Options dropdown, and Edit target User attributes instead of the previous UI labels.

The article now explains viewing and downloading provisioning logs through the admin center, Microsoft Graph, and Microsoft MCP Server for Enterprise. The MCP integration supports natural-language, read-only analysis through delegated permissions and is currently limited to the global service.

The documentation now explains how to create custom task extensions and extensibility workflows through Microsoft Graph, including required permissions and example requests and responses. The workflow example is labeled Preview.

The application attribute customization article now links to guidance on extending attribute mappings with LCW extensibility workflows.

> [!NOTE]

The Conditional Access documentation now describes Android Microsoft Authenticator’s use of the Google Play Integrity API for jailbreak detection and the resulting access denial if the API is unavailable.

The updated Conditional Access documentation states that Microsoft Authenticator on Android uses Google Play Integrity API for jailbreak detection. If the API is unavailable, requests are denied unless the policy is disabled.

A link was fixed on the Conditional Access network assignment page.

The Conditional Access documentation now describes Microsoft Authenticator for Android using Google Play Integrity API for jailbreak detection and denying access when the API is unavailable, unless the policy is disabled.

The documented query now filters for UserId `00aa00aa-bb11-cc22-dd33-44ee44ee44ee` instead of the previous identifier.

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.

Microsoft Entra ID will retire custom CSS layout and positioning properties in company branding by late October 2026 to enhance security and reduce phishing risks. Organizations using these properties must update branding configurations before then; new use will be blocked from July 21, 2026. Branding will revert to default layouts after retirement.

The document date changed from August 18 to August 20, 2026, and existing vendor entries were reordered. Their displayed identifiers and support indicators remain unchanged.

The security key entry’s table formatting was corrected by removing an extra space before a separator.

The documentation now reflects FIDO Metadata Service version 275, with updated FIDO2 model entries, AAGUIDs, and capability indicators, including newly listed authenticators.

The documentation updates compatibility indicators for several Arculus, Feitian, Hyper FIDO, and IDmelon authenticators and removes multiple vendor entries.

The vendor table was re-rendered in its original order, with minor whitespace and line-formatting changes. Vendor names and support indicators are unchanged.

Several FIDO2 hardware vendor entries were reordered to restore their previous sequence. Product names, identifiers, and support indicators remain unchanged.

New documentation explains how the policy blocks federated sign-ins when the trusted realm and mapped user account have different root domains. It also documents the related Microsoft Graph beta APIs.

The documentation now states that tenants created after January 5, 2026, cannot use custom CSS. After July 21, 2026, older tenants not already using it cannot configure it, and support for custom CSS layout and positioning properties is being retired.

The documentation now covers custom CSS layout and positioning properties, and updates its publication date to August 18, 2026. It describes support for these properties as being retired under the Secure Future Initiative.

The documentation now identifies device-based X.509 authentication with the `x509` AMR value and explains that `x509` alone does not meet phishing-resistant MFA requirements. An additional authentication factor is required.

The reference now distinguishes `hwk` for multifactor CBA from `x509` for single-factor CBA, adds device-based X.509 authentication, and explains that `x509` alone does not indicate phishing-resistant MFA.

The documentation now states that, after July 21, 2026, eligible tenants without existing custom CSS cannot configure it. It also expands the list of layout and positioning properties that will eventually be blocked and updates the inspection steps.

The deployment guide no longer states that Platform SSO for macOS uses hardware-backed storage by default. The Intune setup link remains unchanged.

The guidance now states that authentication strength policies cannot currently be applied to external users authenticating through Microsoft personal (MSA) accounts, alongside the previously listed methods. It directs administrators to use the MFA grant control instead.

The article title and heading no longer include “(preview).” No other change is shown.

The page title and heading no longer include “(preview).” No other change is shown, and the diff does not explicitly announce general availability or a product launch.

The documentation now consistently uses “Microsoft Entra ID Auth SDK (sidecar)” and expands “SPA” to “single-page application.” The described authentication flows and responsibilities are otherwise unchanged in the supplied diff.

The local-development article now consistently uses “Microsoft Entra ID Auth SDK (sidecar)” instead of “Microsoft Entra Auth SDK,” including its title, description, intent, link text, and container description.

Microsoft will retire SMS first-factor sign-in for Microsoft Entra ID Free tenants on August 11, 2026, due to fraud risks. Users must switch to other authentication methods before then. SMS as a multifactor method remains unaffected. Admins should identify affected users and update authentication policies accordingly.

The documentation, dated August 11, 2026, replaces general transition text with scenarios describing additional interactive sign-ins when users are added to or removed from Staged Rollout. It also covers certain Microsoft Entra ID Protection remediation events, including SSPR and risk remediation.

The documentation now states that opting out requires the Microsoft Graph `Policy.ReadWrite.AuthenticationMethod` permission. The page date changed from July 29 to August 10, 2026.

The documentation now says Microsoft may enable managed policies at least 30 days after introduction when they remain in Report-only, instead of 45 days. It also documents that a security group is created with the high-risk remediation policy.

The documentation now describes Microsoft Entra joining as intended for Arc-enabled machines planned not to join another domain, replacing the stronger “can't join” wording. It still directs administrators to disconnect from Microsoft Entra by uninstalling the extension if another domain join is needed.

The page now uses “Choose Your Own Telephony Provider” instead of “customer-managed telephony providers,” updates wording throughout, and changes its date to August 5, 2026. It retains the stated availability dates: provider information from September 18, 2026, and configuration from October 30, 2026.

A new concept article explains planned customer-managed providers for SMS and voice authentication. Provider information is expected beginning September 18, 2026, with configuration beginning October 30, 2026; providers aren't available to configure yet.

The documentation changes the registration campaign date from August 6 to November 9, 2026, and the date for accepting only explicitly registered methods from September 7 to October 5, 2026.

The updated documentation says passkeys will be automatically enabled for users using SMS or voice on September 1, 2026. From February 1, 2027, tenants without a customer-managed telecom provider will no longer be able to use SMS or voice for MFA. The timeline applies to public cloud; Azure AD B2C and Entra External ID are excluded from this announcement.

Starting November 9, 2026, Microsoft Entra ID SSPR will require explicitly registered authentication methods for password reset verification, disallowing directory-sourced contact info unless registered. A registration campaign begins October 5, 2026. Organizations must ensure users register methods to avoid reset failures.

The documentation corrects list formatting and navigation numbering and adds a direct link to user provisioning validation instructions.

A new how-to explains how to create and populate a GroupDN directory extension so a group's original distinguished name is retained when its Source of Authority changes to Microsoft Entra ID.

The page now links to guidance on how provisioning from Microsoft Entra ID to Active Directory works and to a tutorial for governing access to an on-premises app.

Two SAP Principal Propagation with Azure API Management references in the tutorial now use updated links; the surrounding guidance remains unchanged.

The tutorial updates two references to Azure API Management guidance for SAP Principal Propagation, including associated learning links.

The examples now define cmdlet parameters in `$params` hashtables before creating custom consent policies and configuring inclusions or exclusions.

The article now describes Entra2ADExchangeOnlineAttributeWriteback (LES Writeback), including its cloud-managed attribute flow, distinction from Exchange hybrid writeback, supported attributes, mappings, and related guidance.

The PowerShell example now uses a different sample ServicePrincipalId value in the New-MgServicePrincipalOwnerByRef command.

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.

Microsoft Entra is updating its self-service identity management domain from myaccount.microsoft.com to myaccount.cloud.microsoft, consolidating related sites for a unified experience. The change rolls out worldwide in late November 2026. Users need no action; administrators should ensure *.cloud.microsoft domains are allowed in network policies.

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.

The reference now explicitly labels synced passkeys as PRMFA and specifies that the PRMFA certificate-based authentication entry applies to multi-factor CBA.

The reference was updated August 19, 2026, adding entries for several Dynamics 365 and Microsoft 365 plans and refreshing listed Microsoft 365 licensing rows.

The page’s last-updated date now reads October 29, 2025, and two Teams Calling Plan names use “country/region” instead of “country.” The downloadable CSV link is unchanged.

The page now states that its information was last updated on August 19, 2026; the CSV download link remains unchanged.

The document’s metadata date changed from July 1, 2026, to August 18, 2026. No product behavior or guidance changed.

The reference was updated August 14, 2026, adding Windows 10 ESU service-plan identifiers to two Windows 365 plan entries.

The article now explains that agent user accounts are evaluated by user-based membership rules and can join dynamic user groups. By default, they are not distinguished from other user identities; rules can explicitly exclude or include them, including accounts tied to a specific agent identity blueprint.

The documentation replaces a direct Microsoft Graph beta PATCH request with Microsoft Graph PowerShell cmdlets, including the `OnPremDirectorySynchronization.ReadWrite.All` scope. It now sets `AllowOnPremUpdateOfOnPremisesObjectIdentifierEnabled` to `$true` temporarily and explains that `$false` re-enables hard match protection.

The existing-tenant installation documentation now instructs administrators to import the ADSyncTools module with a minimum version of 2.5.

The August 2026 update revises configuration steps for the Overview, Attribute mapping, Provisioning configuration, and Basics settings pages.

The documentation no longer includes the “Import ADSyncTools module” heading and `Import-Module ADSyncTools` command.

The article explains how to inspect failed Azure Logic Apps validation runs, identify root causes, and resolve common SCIM endpoint, authentication, permissions, filtering, and conflict errors.

A new guide explains how ISVs create an Entra Gallery Provisioning Test App, deploy the Azure Logic Apps validation template, configure permissions and parameters, and run SCIM provisioning tests.

A new article explains how to validate SCIM user and group provisioning with an Azure Logic Apps template, run 25 tests, and submit the results with a Logic App run ID for App Gallery review. It covers both AI-agent and Azure portal setup methods.

The page author changed from hsaini to himanshusainig.

The document’s author metadata changed from hsaini to himanshusainig.

The page author changed from `hsaini` to `himanshusainig`.

The documentation replaces its embedded onboarding checklist with links to current requirements and validation instructions. App publishers validate their SCIM integration and submit the results with their gallery application; customers obtain OAuth configuration values from the app’s admin experience.

The tutorial now explains that the Microsoft Entra SCIM Validator is for endpoint testing, while App Gallery publishing requires running the Azure Logic Apps validation template and submitting its results.

The SCIM provisioning documentation now links to guidance for the OAuth 2.0 client credentials grant.

The SCIM API reference now states that mailNickname may be omitted, null, or empty when creating a user. Microsoft Entra ID derives it from the characters before the first @ in userName. After creation, it cannot be removed with PATCH.

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 now labels synced passkeys as phishing-resistant MFA and clarifies that this designation for certificate-based authentication applies to multi-factor CBA. The associated SAML mappings are unchanged.

The documentation now describes clearing mapped target attributes when inbound provisioning payloads contain null or empty values. It also recommends complete user records for full and delta sync when this preview capability is enabled.

The tutorial replaces the Orgvue authentication and SAML callback URLs with orgvue-staging URLs and changes the Sign-on URL to include the application login path and domain parameter. It also clarifies that both Reply URL and Sign-on URL values are placeholders.

The Conditional Access What If tool table now uses a different sample UserId in all four examples.

The consent policy documentation now lists revised application IDs for Apple Mail, Spark Email, eM Client, Android-Samsung, Android-Mail, and Thunderbird.

The consent-policy documentation now lists new application IDs for Apple Mail, Spark Email, eM Client, Android-Samsung, Android-Mail, and Thunderbird.

The documentation examples now show revised object IDs for Microsoft Graph and other resource APIs while retaining the same consent scenarios and permissions.

The guide now uses different Microsoft Graph resource API object IDs in delegated- and application-permission consent examples; the documented permissions and consent type remain unchanged.

The Conditional Access What If tool documentation replaces the sample UserId in four example rows with a new sample identifier.

The documented application IDs for Apple Mail, Spark Email, eM Client, Android-Samsung, Android-Mail, and Thunderbird were replaced.

The grant-admin-consent documentation updates the resource API object IDs shown in delegated- and application-permission examples.

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 page title capitalization and image alt text were revised. No configuration or product behavior changes are shown.

The reference now links to license management in the Azure portal, updates the table as of August 3, 2026, adds Agent 365, and revises service and plan identifier entries.

A new article compares groups-only, users-only, and users-and-groups provisioning through scoping filters. It also documents availability, domain and tenant configuration limits, and performance guidance.

A new overview explains how Cloud Sync provisions users, groups, and memberships from Microsoft Entra ID to on-premises AD, including supported scenarios, configuration options, synchronization behavior, and limitations. User provisioning is in preview; group provisioning is generally available.

The guidance now links to the Microsoft Entra ID-to-Active Directory provisioning overview and its nested group membership behavior section.

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

The page title no longer includes “(preview),” and the prerelease product notice was removed.

The documentation now lists a paid Azure subscription associated with an Enterprise Agreement or pay-as-you-go billing account, replacing the previous MCA subscription requirement.

The Governed Workforce tenant creation guidance now links the Microsoft Online Subscription Agreement and related billing agreement references.

The documentation now describes the requirement as an Enterprise Agreement (EA) or Pay-As-You-Go subscription and references MOSA and MCA billing agreements.

The documentation refreshes troubleshooting guidance for creating Governed Workforce tenants, including paid Azure subscription and billing-account requirements.

The documentation now lists token protection for iOS/iPadOS and macOS as generally available. Supported web apps accessing Azure Resource Manager on macOS remain in preview.

The documentation now compares application owners with application administrators, stating that owners can manage only the enterprise applications they own and have equivalent permissions within that application scope.

The documentation now states that replica sets require connectivity between all virtual networks hosting them. They are deployed in one Active Directory site and rely on a fully meshed virtual network topology for directory replication.

The page now documents browser-based application support in Preview for selected web apps accessing Azure Resource Manager on Windows and macOS. iOS/iPadOS browser support is not supported. The page also adds requirements for supported browsers, extensions, operating systems, and configurations.

The Conditional Access token protection documentation now links to a deployment guide for web apps that access Azure Resource Manager. The linked guidance is marked Preview.

Instructions about how to find Microsoft Entra ID and how to create a new tenant for your organization.

The guidance for controlling access to on-premises applications now links to the updated Microsoft Entra Cloud Sync documentation for provisioning groups to Active Directory.

Organizations are increasingly modernizing identity, access, and device management by reducing their dependence on on-premises Active Directory and adopting cloud-native capabilities in Microsoft Entra ID. Whether the goal is complete Active Directory retirement or a smaller, more secure on-premises footprint, this guidance helps you plan and execute that transformation.

Learn about Microsoft Entra tenant architecture for collaborating production tenants so that you can identify your needs and compare architectural options.

Learn about Microsoft Entra tenant architecture for nonproduction environments so that you can identify your needs and compare architectural options.

Learn about Microsoft Entra tenant architecture for primary production tenants so that you can identify your needs and compare architectural options.

Learn how to compose your Microsoft Entra tenant estate from common tenant architecture patterns so that you can meet your requirements with as few tenants as possible.

Learn about Microsoft Entra tenant architecture for business partner access so that you can identify your needs and compare architectural options.

Learn about Microsoft Entra tenant architecture for critical business systems so that you can identify your needs and compare architectural options.

Learn about Microsoft Entra tenant architecture for hybrid identity and isolation so that you can identify your needs and compare architectural options.

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.

Microsoft Entra ID will support passkey registration and sign-in for B2B users to meet resource tenant MFA requirements, enhancing phishing resistance. This feature, enabled by default, rolls out from October 2026 to February 2027, requiring no admin action but recommending policy reviews to align user scopes and MFA settings.

The guide removes the Preview designation, adds Microsoft Scout to the support matrix, and replaces detailed storage-flag instructions with updated Apple SSO plugin and Platform SSO guidance.

Microsoft Entra will recognize Windows Hello for Business and macOS Platform SSO as standalone MFA factors starting October 2026, allowing users to meet MFA requirements without additional passkeys. No configuration changes are needed, but organizations should update onboarding and MFA registration guidance accordingly.

Users can now register passkeys or passwordless sign-in as their first multifactor authentication method in Microsoft Entra, eliminating the need to set up weaker methods first. This change, rolling out from October 2026 to February 2027, aims to increase adoption of phishing-resistant authentication without requiring admin action.

The token protection article removes a screenshot of a Conditional Access policy requiring token protection as a session control. The Primary Refresh Token link remains.

Adds a guide for deploying and enforcing Token Protection with Conditional Access for supported browser-based applications accessing Azure Resource Manager. Web application support is explicitly in preview and limited to listed apps, platforms, browsers, and device configurations.

Microsoft Entra ID will retire the MemberOf rule operator by November 3, 2026. Organizations using MemberOf in dynamic groups, administrative units, or entitlement policies must replace these rules to avoid stale access, licensing, and policy enforcement issues. Review and update configurations before the deadline.

The AzureActiveDirectoryInvalidCredential and AzureActiveDirectoryExpiredCredentials entries no longer reference the cloud service-account repair cmdlet.

The troubleshooting article no longer documents the Repair-AADCloudSyncToolsAccount cmdlet or its usage steps.

The Linux device registration troubleshooting documentation now shows a different tenant ID in its example output.

The example Tenant ID was changed from 12345678-90ab-cdef-1234-567890abcdef to aaaabbbb-0000-cccc-1111-dddd2222eeee.

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 troubleshooting guide now covers DataValidationFailed alongside IdentityDataValidationFailed, including cases where onPremisesObjectIdentifier changes during hard match operations. It also adds guidance for checking userPrincipalName formatting and using the documented hard match recovery paths.

The troubleshooting documentation now directs administrators to the Hard match scenarios and recovery paths when DataValidationFailed occurs during a hard match operation, while retaining guidance to validate userPrincipalName characters and format.

The documentation now uses clearer commands to enable and verify `AllowOnPremUpdateOfOnPremisesObjectIdentifierEnabled`, and explicitly shows how to set it back to `$false` after remediation to re-enable hard match protection.

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

The July row now includes an additional 99.999% value in the performance table; no product change is indicated.

The article was revised to use lowercase “account discovery,” clarify connector and limitation wording, update the GitHub reference, and change its date from May 26, 2026, to August 11, 2026. It continues to describe the existing discovery process and requirements.

The documentation now explains how to configure granular AMR values for SAML applications through the manifest or Microsoft Graph, since the admin center has no UI option for `include_granular_amr`. It also documents adding the `amr` claim to OIDC token types and clarifies that `include_granular_amr` applies only to SAML.

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 updates the C# sample’s imports, endpoint structure, downstream API call, and model declarations to provide valid create-agent-identity code.

The documentation adds Microsoft Graph and Microsoft.Identity.Web imports, changes sample calls from Applications to Users, and clarifies that configured scopes must match the Graph resources used. Examples use User.Read and User.ReadBasic.All.

The documentation updates its C# examples, including distinct method names for UPN and object ID calls, a revised controller constructor signature, and clearer user-data method names.

The documentation now identifies app-only tokens as using client credentials, expands on-behalf-of to OBO, and consistently uses the `agent-identity-client-id` placeholder in request examples.

The Amazon Bedrock integration guide now consistently uses “Microsoft Entra ID Auth SDK (sidecar)” in its description, explanations, container reference, and links. No behavior or availability change is described.

The documentation adds an OpenID Connect using directive and renames two C# sample variables: `applications` to `applicationsForUser` and `me` to `meByOid`.

The Agent ID Microsoft Graph documentation now labels sample variables as `usersAppOnly` and `usersOnBehalfOfUser`, clarifying the scenarios they represent.

The documentation replaces “Entra ID Auth SDK” with “Microsoft Entra ID Auth SDK” in two descriptions. The endpoint formats and behavior are unchanged.

The user delegation section now spells out “on-behalf-of (OBO)” on first use. No feature behavior or requirements changed in the supplied diff.

The code sample now uses `<your-tenant-id>` instead of `<your-tenant>` for the `TenantId` value.

The documentation now spells out “on-behalf-of (OBO)” on first use in the token scenario guidance. The referenced method is unchanged.

The `TenantId` example value changed from `<my-test-tenant>` to `<your-tenant-id>` for clearer documentation.

The third-party agents documentation now labels the sidecar setup link “Configure Microsoft Entra ID Auth SDK for agent identities” instead of “Configure Entra ID Auth SDK.”

The documentation now lists how an agent with its own identity can communicate through Outlook email, OneDrive and SharePoint comments, Teams chats, and Teams channels, including the permissions required for inbound and outbound communication.

The documentation now consistently uses `<your-tenant-id>` instead of `<my-test-tenant>` or `<your-test-tenant>` in PowerShell, OAuth URLs, and JSON examples.

The page description was shortened by removing the phrase “Key concepts.” The documented OAuth 2.0 protocols and token exchange patterns remain unchanged.

The autonomous agent authentication and authorization flow documentation now adds `using Microsoft.Identity.Web;` to a C# setup sample.

The interactive agent authentication and authorization documentation now includes `using Microsoft.AspNetCore.Authentication.JwtBearer;` in its C# setup samples.

The error-code documentation now separates quota, blueprint, blueprint principal, agent identity, and agent identity creation errors, with clearer descriptions and table headings.

The documentation replaces inconsistent tenant placeholders with `<your-tenant-id>` and standardizes `<agent-blueprint-clientid>` to `<agent-blueprint-client-id>` in code samples.

The article now consistently refers to the sidecar integration as the Microsoft Entra ID Auth SDK instead of the Microsoft Entra Auth SDK. The integration guidance is otherwise unchanged.

The page updates image accessibility text, refines wording about agent identities, and standardizes the name “Microsoft Entra ID Auth SDK (sidecar)” for third-party agent integrations.

The documentation now refers to the “Microsoft Entra ID Auth SDK (sidecar)” instead of the “Microsoft Entra SDK auth sidecar.” The token-validation guidance is otherwise unchanged.

The Agent ID token claims documentation no longer includes one `tid` claim table row.

The documentation now shows different sample GUID values for the aud, appid, oid, sub, and tid claims.

The documentation now spells out “on-behalf-of” before introducing the OBO acronym in the OAuth 2.0 authentication description.

The documentation now uses `<your-tenant-id>` instead of `<my-test-tenant>` in the token endpoint and `TenantId` code examples.

The page’s `ms.topic` metadata was changed from `how-to #Required; leave this attribute/value as-is` to `how-to`. The topic classification remains unchanged.

The delete-agent-identity article no longer contains a TODO asking engineering to confirm whether cascade cleanup removes associated agent user accounts.

The documentation now lists two license options: Microsoft 365 E7, or Microsoft Agent 365 paired with Microsoft Entra P1 or Microsoft 365 E3.

The documentation replaces the Microsoft Entra ID P1/P2 license requirement and the note that an Agent 365 license would soon be required with a direct Agent 365 license requirement.

The documentation now expands MCP, A2A, and OBO on first use to improve clarity and retrievability.

The key concepts page now labels the link “Microsoft Entra Agent ID OAuth protocols” instead of “oauth protocols.”

The document title was normalized by removing an extra space after the metadata colon. No substantive guidance or product behavior changed.

The page no longer includes a TODO questioning support for enumerated scopes versus `allAllowed`/`none`. The diff provides no evidence of a product or feature change.

The documentation replaces standalone Entra licensing options for agents with guidance that Microsoft Agent 365 is required. It states that Agent 365 is included with Microsoft 365 E7 and available as an add-on to Microsoft E5, A5, Business Premium, or Defender Suite plus Purview Suite.

The best-practices documentation now uses the full “Microsoft Entra Agent ID” and “Microsoft Entra ID” names in two recommendations. The guidance itself is unchanged.

The n8n integration page now consistently calls the pattern “Microsoft Entra ID Auth SDK (sidecar)” instead of “Microsoft Entra Auth SDK.”

The page’s bullet describing platforms and services that create agents retains the same wording and examples, including Copilot Studio, AWS Bedrock, and n8n. No substantive content change is shown.

The documentation now recommends creating agent identities from an agent identity blueprint instead of using standard app registrations or service principals. It also adds .NET usage guidance and lists required roles and permission.

The documentation updates its C# examples, separating app-only, on-behalf-of-user, and user-identification scenarios. Samples now configure agent identity options and pass the credential to the Blob client correctly.

The guide updates “Entra” to “Microsoft Entra” in the diagram alt text, setup heading, and TENANT_ID descriptions. No technical procedure or feature change is shown.

The agent identity architecture planning page now links to the correct interactive agent authentication article instead of the previous broken path.

The documentation now explains that agents should use an agent identity blueprint and the `#Microsoft.Graph.AgentIdentity` object, rather than standard app-registration APIs. It also lists supported creation channels, roles, permissions, and .NET usage.

The documentation now explains that Tc must target the agent identity blueprint, while T1 targets the token-exchange resource and is validated as bound to the blueprint and child agent identity. It also states that agent identities cannot use interactive consent and must have delegated permissions preauthorized through inheritable blueprint permissions.

The documentation now explicitly states that child agent identities, like their parent blueprints, cannot initiate interactive `/authorize` flows. Interactive consent attempts return `AADSTS82014`; required delegated permissions must be preauthorized instead.

The Agent ID documentation now refers to the linked SDK as the “Microsoft Entra ID Auth SDK” instead of “Entra ID Auth SDK.”

The documentation now states that disabling the Entra device blocks new token issuance, revokes user sessions, and prompts the user to sign in again. It no longer mentions revoking existing device-bound refresh tokens.

The documentation replaces “Device disablement” with “Attacker-added device” and explains that the Entra device object is disabled, new token issuance is blocked, existing device-bound refresh tokens are revoked, and user sessions are revoked.

The documentation now describes a Device disablement response for users flagged by Microsoft threat intelligence as having an attacker-added device. The device is disabled, and the user is prompted to sign in from a trusted device.

The heading changed from “Workaround for newly added Staged Rollout users” to “Workaround to avoid one additional federated sign-in.” No procedural content changed in the supplied diff.

The documentation now lists two supported licensing options: Microsoft 365 E7, which includes Agent 365 and Microsoft Entra Suite, or Microsoft Agent 365 paired with at least Microsoft Entra P1 or Microsoft 365 E3.

The documentation now states that Conditional Access for agents requires a Microsoft Agent 365 license to apply policies through Microsoft Entra Agent ID, replacing “Starting soon.”

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 deployment guide now documents a paid Azure subscription linked to an Enterprise Agreement or pay-as-you-go billing account, with Tenant Contributor or Subscription Owner/Creator access for the selected subscription.

The documentation now describes creating a lifecycle workflow by cloning an existing workflow in the Microsoft Entra admin center, including review and customization steps.

The documentation now specifies paid-account, billing, tenant-creation permission, role, and default governance-policy requirements for creating governed workforce tenants. Free or trial tenants cannot create additional tenants, and EA or pay-as-you-go billing accounts are supported.

The documentation now specifies that secure add-on tenant creation requires an existing paid Azure subscription and resource group, with the subscription associated with an Enterprise Agreement.

The documentation now specifies selecting an existing Microsoft Customer Agreement (MCA) subscription and resource group from the billing account when creating a tenant with the secure add-on tenant creation feature.

The tenant creation guidance now links references to the Microsoft Entra ID Free billing asset to the relevant billing documentation instead of the previous signals-and-metrics page.

The documentation now labels the governing tenant’s default governance policy template as optional instead of a required prerequisite. The tenant creation service still uses only the default template (ID: `default`).

The prerequisite now specifies that the home tenant must have at least one paid, license-based Microsoft product. Free and trial licenses do not qualify.

The secure add-on tenant creation documentation now refers to selecting an existing subscription, rather than specifically an existing Microsoft Customer Agreement subscription, from the billing account.

The documentation now says the home tenant—not the governing tenant—must have the default governance policy template for this optional prerequisite. The service uses the template with ID `default`.

The documentation now explicitly states that the required Enterprise Agreement or Pay-As-You-Go subscription must be paid.

The document’s `ms.author` metadata changed from `tafra00` to `tazkiaafra`.

The guide now links the Microsoft Online Subscription Agreement (MOSA) in its billing-account prerequisites. The Enterprise Agreement and Pay-As-You-Go references remain.

The prerequisite now refers to Enterprise Agreement or Pay-As-You-Go subscriptions and identifies MOSA and MCA subscriptions, replacing billing-account wording.

The tenant creation guide now explicitly states that the required subscription permissions are Azure Resource Manager (ARM) permissions, provided through the Tenant Contributor or Subscription Owner/Creator role.

The mover workflow templates now list the “Remove all access package assignments for user” task, with removal scheduled by default for 15 days.

The tutorial now includes a task that removes all access package assignments for a user, scheduled by default for 15 days.

The task is now listed for both Leaver and Mover templates. The documentation also states that setting daysUntilExpiration schedules removal instead of removing assignments immediately.

The lifecycle workflows task table now lists “Remove all access package assignments for user” for both Leaver and Mover workflow templates.

The documentation now covers delegating multi-resource access reviews in addition to access package approvals. It also documents restrictions for delegate selection and maximum delegation duration.

The documentation now expands its guidance that administrators must verify users meet existing access package policy requirements before assigning them; otherwise, assignment may fail.

The documentation removes an inaccurate statement implying that direct assignment to an access package requires approval. It now states only that assigned users must meet the policy’s eligibility requirements.

The access package assignments page no longer includes a note stating that assignment managers cannot bypass required approval settings or directly assign identities without approval.

The entitlement management delegation documentation removes a note about access package assignment managers being unable to bypass approval requirements when directly assigning identities.

The guide removes the Preview label and adds steps for creating the resource and Logic App, automatic upload notifications, manual result application, and new resource parameters.

The page no longer labels the capability as Preview and now documents catalog resource setup, Logic App integration, manual uploads, and applying results to non-Approve decisions. The previous note about single-stage reviews with manager reviewers was removed.

The documentation no longer labels Catalog Access Reviews or custom data provided resources as preview. It also generalizes reviewers beyond managers and adds a note that changes within 12 hours before a review starts may not appear.

The page no longer labels Catalog Access Reviews or Custom Data Provided Resource as preview. It updates wording from managers to reviewers, removes the statement that managers are primary reviewers, adds a 12-hour data-change limitation before review start, and updates links.

The governance licensing documentation now includes “PIM - Custom extensions for role activation (Preview)” with licensing indicators.

The documentation now states that support for the `memberOf` rule operator ends November 3, 2026, replacing October 27, 2026. Policies using it will be quarantined and stop processing assignments from that date.

The documentation states that, starting October 27, 2026, automatic assignment policies using memberOf will be quarantined. Assignment processing will stop, and no assignments will be added or removed until memberOf is removed.

Learn how to create configuration snapshots in Microsoft Entra Tenant Governance to capture tenant configuration for baselines or audit evidence

Learn how to view monitor results and configuration drifts and manage configuration monitors in Microsoft Entra Tenant Governance

Learn how to create a configuration monitor in Microsoft Entra Tenant Governance to evaluate a tenant against a configuration baseline and report drift

This article walks you through managing unsponsored guests using the **Unsponsored guest cleanup (Preview)** workflow template.

Learn how to deploy Microsoft Entra Tenant Governance from setup through tenant discovery, governance, and configuration monitoring

Learn how to assign or remove the application permissions and roles that the Tenant Configuration Management service uses to create snapshots and run monitors

Learn how to securely create a governed Microsoft Entra workforce tenant and establish governance from your home tenant.

When you create a new Microsoft Entra tenant using the secure add-on tenant creation feature, you're prompted to select an existing subscription and resource group from your billing account. When you create your new tenant, Microsoft generates a new billing asset called **Entra ID Free** under that subscription and resource group, which links to the newly created tenant.

The documentation now describes creating new cloud security groups in Microsoft Entra ID, provisioning them to AD DS as Universal groups, and updating applications to use the new group security identifiers.

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 secure tenant creation guidance now links the Microsoft Online Subscription Agreement (MOSA) reference alongside the existing Enterprise Agreement and Pay-As-You-Go links.

The deployment guide now refers to either a paid Enterprise Agreement or Pay-As-You-Go subscription and adds Microsoft Online Subscription Agreement terminology.

The secure tenant creation prerequisites were updated to clarify the required Azure Resource Manager permissions.

The task now applies to both leaver and mover templates. For mover templates, scheduled removal defaults to 15 days; administrators can customize the timing or choose immediate removal.

The documentation now consistently uses a different application client ID in the endpoint URI, calling application claim, and `resourceId` examples.

The documentation now uses revised Application (client) ID examples in the endpoint URI and `resourceId` configuration sample.

The guidance now links to a different Microsoft Entra Cloud Sync article for provisioning groups to Active Directory Domain Services.

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

The documentation now describes using the preview credential management API with delegated permissions so signed-in customers can list, register, and delete their own passkeys. It also clarifies that the sample uses high-privilege administrator provisioning and is for testing.

Microsoft Entra External ID now documents an API that lets applications list, register, and delete signed-in customers’ passkeys using delegated access tokens.

The cross-tenant service principal article changes the example ServicePrincipalId from `bbbbbbbb-1111-2222-3333-cccccccccccc` to `aaaaaaaa-bbbb-cccc-1111-222222222222`.

The guidance now includes an approximate domain-count example and reiterates that capacity depends on domain length within the 25 KB (25,000-character) policy limit.

We are announcing the ability to enable on-behalf-of ordering for Microsoft Entra External ID (EEID) in Dynamics 365 Commerce. This feature will reach general availability on September 11, 2026 How does this affect me?

The guide now reflects revised Entra portal navigation and controls, including **New configuration**, **Create**, **Overview > Properties**, and **Attribute mapping**. It also updates terminology and scope-setting guidance.

The documentation now directs administrators to Entra ID > Cross-tenant Synchronization > Configurations, removing the External Identities step.

Microsoft Entra will update federatedTokenValidationPolicy by mid-August 2026 to block federated sign-ins when internalDomainFederation doesn't match the user's UPN domain, enhancing security. This affects federated domains configured before December 2025. Admins can customize the policy via Microsoft Graph but it's discouraged.

The instructions now consistently use `efpUrl` instead of `efpURL` and explain that PAC file JavaScript is case-sensitive.

The article now describes traffic forwarding through the Global Secure Access client and remote networks, six policies instead of three, Microsoft Traffic Bypass, Custom Acquire, and Agentic Acquire. It also expands Custom Bypass configuration steps to cover destination types, ports, and protocols.

Learn how to configure Microsoft Entra Internet Access and Microsoft Defender for Cloud Apps side by side without proxying traffic twice.

The documentation now explains that V2 selects the first applicable profile containing a V2 policy, does not support user or group targeting on individual rules, and may produce different enforcement from V1 during migration.

A new concept article documents the V2 web filtering model in Microsoft Entra Internet Access, including policies, rules, destination matching, and coexistence with V1 web content filtering.

The curl example now uses client_id `00001111-aaaa-2222-bbbb-3333cccc4444` instead of the previous value.

The VM managed identity documentation changes the client_id value in its curl token-request example.

Adds a first-party tutorial showing how a Kubernetes workload can exchange a SPIFFE JWT-SVID for a Microsoft Entra access token and access Azure resources without stored secrets. This is documentation for the scenario, not evidence of a new product launch.

Adds a step-by-step tutorial showing how to configure a Microsoft Entra application to trust a Google-issued service-account token, exchange it for an Entra access token, and access Azure resources without storing application secrets.

The guidance now requires GitHub flexible federated identity credentials to match `sub` plus `repository_id`, `repository_owner_id`, or both. Portal and Microsoft Graph examples include these claims and optional workflow matching.

The documentation now states that GitHub flexible federated identity credentials must match `sub` and at least one immutable claim: `repository_id` or `repository_owner_id`. It also updates examples and operator support details.

The documentation now links to guidance on mutable subjects and migrating GitHub Actions federated credentials to immutable subjects.

The setup documentation now links to guidance on mutable subjects and migrating GitHub Actions federated credentials to immutable subjects.

The documentation updates the name or identifier of the dedicated first-party service principal used to synchronize Active Directory with Microsoft Entra ID.

The documentation wording about the dedicated first-party application and service principal used for synchronization between Active Directory and Microsoft Entra ID was revised.

The page no longer lists SAP’s November 20, 2026 basic-authentication deprecation date and removes the note describing current and planned workload identity support scenarios.

The PowerShell example now uses a different Subject value for the managed identity federated credential.

The documentation changes the example `-Subject` value in the `New-AzADAppFederatedCredential` command.

GitHub Actions now supports immutable OIDC subject formats with repository and owner IDs to enhance Microsoft Entra federated identity security. Organizations using GitHub Actions OIDC must migrate to this format by late July 2026 to prevent token mismatches and reduce unauthorized access risks.

The concept page now points to first-party tutorials for Google Cloud and SPIFFE/SPIRE scenarios instead of the previous links. No product feature change is indicated.

The version-history section is now titled “Unsupported versions,” and guidance for version 1.5.612.0 or earlier recommends immediately updating to a newer version.

The version history marks versions 1.5.612.0, 1.5.402.0, 1.5.132.0, and 1.5.36.0 as deprecated and instructs users of 1.5.612.0 or earlier to update immediately.

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 release notes now document version 1.1.26060207, released August 21, 2026, with Home Network traffic control, a Connections page, agentic detection support, Secure DNS bypass, and several fixes.

Starting with version 1.1.26060207, the app package includes com.microsoft.autoupdate2 for future use cases.

The page no longer includes the note about `com.microsoft.autoupdate2` or the optional instruction to remove it from Intune detection rules. The metadata date and custom tag were also reverted.

The release-history page no longer includes version 1.1.26060207 or its listed changes, and its document date changed from August 21, 2026, to April 16, 2026.

The macOS client installation guidance now states that removing `com.microsoft.autoupdate2` from Intune detection rules is optional.

The documentation now warns that, starting with version 1.1.26060207, including the already-installed com.microsoft.autoupdate2 application in Intune detection rules might cause a conflict.

The macOS client installation guidance now clarifies that, starting with version 1.1.26060207, administrators can optionally remove `com.microsoft.autoupdate2` from Intune detection rules.

The macOS client release history now says administrators can optionally remove `com.microsoft.autoupdate2` from Intune detection rules; the app package includes this application.

A new how-to article explains the guided Global Secure Access migration experience. It covers eligible and ineligible security profiles, migration steps, policy and rule naming, and how V1 policies become rules in a single enabled V2 policy while preserving destinations, actions, and priorities.

The instructions now refer to the “Remote network assignments” section instead of “Remove network assignments.”

The step now refers to the **Remote network assignments** section instead of **Remove network assignments** when selecting the profile’s **View** link.

The documentation now states that **Agent** matches traffic classified as AI agent traffic, while traffic not classified as agent traffic is treated as **User** traffic. If the condition is omitted, the rule applies to all traffic. The condition remains in preview.

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

The web filtering documentation now links to an article explaining how to migrate web content filtering policies from V1 to V2.

Microsoft added a how-to article for configuring the Global Secure Access MCP firewall to inspect, audit, and allow or block Model Context Protocol traffic. It covers server, primitive, method, and protocol-version controls for supported MCP traffic.

The guide now presents the V1-to-V2 migration procedure and migration options as numbered steps.