πŸ“‹ Microsoft Entra Documentation Changes

Daily summary for changes since August 2nd 2026, 8:12 PM PDT

Report generated on August 3rd 2026, 8:12 PM PDT

πŸ“Š Summary

17
Total Commits
2
New Files
4
Modified Files
0
Deleted Files
10
Contributors

✨ What changed today

Today’s Entra documentation updates cover MFA retirement planning, Global Secure Access NAT deployments, provisioning integrations and extensibility, Zscaler automation, and licensing references.

πŸ†• New Documentation Files

+210 lines added
Commit: Add guidance for remote network CPE behind NAT (#13993)
New documentation
New guidance for Global Secure Access CPEs behind NAT

A new how-to explains configuring a Global Secure Access remote network when the CPE has a private WAN address behind an upstream NAT router, using IKEv2 NAT Traversal (NAT-T) over UDP 4500. It covers topology, prerequisites, and setup considerations.

Why admins should care: Administrators can use this guidance for supported NAT-based deployments. The CPE must support NAT-T, the upstream router must allow UDP 500 and 4500 traffic, and its public IP should be static.

+152 lines added
Commit: creating a new tutorial for Zscaler zidentity (#13083)
New documentation
New tutorial for Zscaler provisioning with Microsoft Entra ID

Microsoft added a tutorial describing how to configure automatic user provisioning and deprovisioning between Microsoft Entra ID and Zscaler Provisioning, including user and group synchronization, prerequisites, SCIM setup, application-gallery configuration, scoping, and attribute mapping.

Why admins should care: Administrators integrating Zscaler can follow the documented steps and prerequisites, including required roles, a Zscaler admin account, app-role assignments, and OAuth client credentials. The documentation does not indicate a new product launch or preview.

πŸ“ Modified Documentation Files

Modified by Adelle Ingrid Dimitui on Aug 3, 2026 8:09 PM
πŸ“– View on learn.microsoft.com
+245 / -1 lines changed
Commit: added api instructions for custom call-outs docs (#14004)
Documentation change
Added Microsoft Graph instructions for extensibility workflows

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

Why admins should care: Administrators can follow the new API-based procedure to configure these extensions, but must consent to the documented Lifecycle Workflows permissions. This documents an existing capability; it does not indicate a new product launch.

Changes:
Before
After
 
Before creating an extensibility workflow, you need a custom extension that you can link to your extensibility workflow. As mentioned previously, you can think of the custom extension as a wrapper for the Azure Logic App where your custom logic resides. When the extensibility workflow triggers the custom extension, the Azure Logic App will run.
 
1. Using your browser, sign in to your Entra ID tenant via the [Microsoft Entra admin center](https://entra.microsoft.com).
1. Navigate to **Lifecycle workflows > Custom extensions > Add a custom extension**.
 
 
You now have a custom extension that is ready to link to an extensibility workflow as a task. Now let’s work on creating an extensibility workflow.
 
 
## Step 2: Create an extensibility workflow
 
Once you’ve created a custom extension, you can now create an extensibility workflow whose task is to trigger the custom extension.
 
1. Using your browser, sign in to your Entra ID tenant via the [Microsoft Entra admin center](https://entra.microsoft.com).
1. Navigate to **Identity Governance > Lifecycle Workflows > Create workflow**.
1. In the Choose a template tab, select the **Real-time Provisioning extensibility** template.
 
You now have an extensibility workflow that can trigger an Azure Logic App that contains your custom logic. Now let’s work on mapping the extensibility workflow to a target attribute.
 
 
Before creating an extensibility workflow, you need a custom extension that you can link to your extensibility workflow. As mentioned previously, you can think of the custom extension as a wrapper for the Azure Logic App where your custom logic resides. When the extensibility workflow triggers the custom extension, the Azure Logic App will run.
 
### In the Microsoft Entra admin center
 
1. Using your browser, sign in to your Entra ID tenant via the [Microsoft Entra admin center](https://entra.microsoft.com).
1. Navigate to **Lifecycle workflows > Custom extensions > Add a custom extension**.
 
 
You now have a custom extension that is ready to link to an extensibility workflow as a task. Now let’s work on creating an extensibility workflow.
 
## Using Microsoft Graph
 
1. Start the [Microsoft Graph Explorer tool](https://aka.ms/ge).
1. Sign in to your tenant.
1. Select **Modify permissions**.
1. Consent to the following required permissions: `LifecycleWorkflows-CustomExt.ReadWrite.All`
1. Use the [Create customTaskExtensions API](https://learn.microsoft.com/graph/api/identitygovernance-lifecycleworkflowscontainer-post-customtaskextensions) to create a custom extension.
 
**Example request**
+7 / -63 lines changed
Commit: Split SMS/voice retirement FAQ into a dedicated FAQ page (#13978)
Documentation change
Documentation adds SMS and voice retirement FAQs

The page now documents the retirement timeline, passkey auto-enablement beginning September 1, 2026, and loss of SMS/voice MFA without a customer-managed telecom provider from February 1, 2027. It also covers costs, SSPR, scope, and a temporary opt-out.

Why admins should care: Administrators should identify affected users, plan passkey or telecom-provider migration, and review the temporary opt-out before September 1, 2026. The documented timeline applies to public cloud tenants; Azure AD B2C and Entra External ID are excluded from this announcement.

Changes:
Before
After
 
To avoid sign-in disruption, make sure users register a passkey or move to another phishing-resistant authentication method before February 1, 2027. If your organization has a valid business, regulatory, or operational need to keep using SMS or voice, configure a customer-managed telecom provider before this date.
 
## Frequently asked questions
 
### Why is Microsoft provided telecom delivery for SMS and Voice ending?
 
The primary driver is security. As the industry moves toward phishing-resistant authentication, Microsoft Entra ID is making passkeys the default authentication experience. SMS and voice are among the most vulnerable authentication methods available today and provide significantly weaker protection against phishing and account compromise than passkeys.
 
Organizations that still require SMS or voice will continue to have that option through customer-managed telecom providers when there is a legitimate business, regulatory, or technical need. This change is intended to modernize authentication while preserving flexibility for those scenarios.
 
Beginning September 1, 2026, passkeys will be automatically enabled for users currently enabled for SMS or voice. Beginning February 1, 2027, tenants that have not configured a customer-managed telecom provider through the Microsoft Security Store will no longer be able to use SMS or voice for MFA. Users whose only MFA method is SMS or voice will be required to register a passkey during sign-in before they can continue accessing their account. Tenants that have configured a customer-managed telecom provider can continue using SMS or voice according to their organization's policies.
 
### Will there be costs associated with using a telecom provider through the Security Store?
 
Yes. Pricing varies by telecom provider and region. Costs are typically per-message and depend on your volume, geographic distribution, and selected provider. You'll need to evaluate providers in the Microsoft Security Store for specific pricing.
 
However, migrating Microsoft provided SMS and voice users to Passkeys incur no additional cost.
 
### Will my users be auto-migrated, or do I have to do it?
 
To avoid sign-in disruption, make sure users register a passkey or move to another phishing-resistant authentication method before February 1, 2027. If your organization has a valid business, regulatory, or operational need to keep using SMS or voice, configure a customer-managed telecom provider before this date.
 
## Temporarily opt out of the automatic passkey enablement
 
A temporary opt-out is available for the September 1, 2026 through February 1, 2027 changes. This lets you delay passkey and Registration Campaign enablement while you complete transition activities, such as configuring customer-managed telecom providers or migrating to other authentication methods.
 
To opt out, update your authentication methods policy using Microsoft Graph and set the `passkeyDynamicMigration` property to `true`.
 
}
```
 
After this setting is applied, your tenant is excluded from the automatic passkey enablement and Registration Campaign rollout during the opt-out period. Beginning February 1, 2027, standard passkey migration and enforcement timelines apply regardless of this setting.
 
If your tenant still has users enabled for Microsoft-managed SMS or voice on February 1, 2027, and you haven't configured a customer-managed telecom provider through the Security Store, those users can no longer use SMS or voice to satisfy MFA requirements and continue signing in.
 
**There is no opt out for the February 1, 2027 enforcement. This requirement applies to all tenants.**
 
## Frequently asked questions
 
Modified by shelleyatmicrosoft on Aug 3, 2026 5:28 PM
πŸ“– View on learn.microsoft.com
+26 / -32 lines changed
Commit: Learn Editor: Update licensing-service-plan-reference.md
Documentation change
Licensing service-plan reference updated

The documentation now includes Azure portal licensing management, refreshes product and service-plan identifier entries, adds Agent 365, and states the table was last updated August 3, 2026.

Why admins should care: Administrators using PowerShell or license-management tools should review the updated identifiers and CSV reference when mapping products and service plans.

Changes:
Before
After
 
# Product names and service plan identifiers for licensing
 
 
## Overview
 
When managing licenses in the [Microsoft 365 admin center](https://admin.microsoft.com), you see product names that look something like *Office 365 E3*. When you use PowerShell v1.0 cmdlets, the same product is identified using a specific but less friendly name: *ENTERPRISEPACK*. When using PowerShell v2.0 cmdlets or [Microsoft Graph](/graph/api/resources/subscribedsku), the same product is identified using a GUID value: *6fd2c87f-b296-42f0-b197-1e91e994b900*.
 
The following table lists the most commonly used Microsoft online service products and provides their various ID values. These tables are for reference purposes in Microsoft Entra ID, part of Microsoft Entra, and are accurate only as of the date when this article was last updated. Microsoft will continue to make periodic updates to this document.
 
- **Product name**: Used in management portals
- **String ID**: Used by PowerShell v1.0 cmdlets when performing operations on licenses or by the **skuPartNumber** property of the **subscribedSku** Microsoft Graph API
- **Service plans included**: A list of service plans in the product that correspond to the string ID and GUID
- **Service plans included (friendly names)**: A list of service plans (friendly names) in the product that correspond to the string ID and GUID
 
> [!NOTE]
> This information was last updated on July 27, 2026.
> You can also download a CSV version of this table [here](https://download.microsoft.com/download/e/3/e/e3e9faf2-f28b-490a-9ada-c6089a1fc5b0/Product%20names%20and%20service%20plan%20identifiers%20for%20licensing.csv).
 
| Product name | String ID | GUID | Service plans included | Service plans included (friendly names) |
 
# Product names and service plan identifiers for licensing
 
When [managing licenses in the Azure portal](https://portal.azure.com/#blade/Microsoft_AAD_IAM/LicensesMenuBlade/Products) or the [Microsoft 365 admin center](https://admin.microsoft.com), you see product names that look something like *Office 365 E3*. When you use PowerShell v1.0 cmdlets, the same product is identified using a specific but less friendly name: *ENTERPRISEPACK*. When using PowerShell v2.0 cmdlets or [Microsoft Graph](/graph/api/resources/subscribedsku), the same product is identified using a GUID value: *6fd2c87f-b296-42f0-b197-1e91e994b900*. The following table lists the most commonly used Microsoft online service products and provides their various ID values. These tables are for reference purposes in Microsoft Entra ID, part of Microsoft Entra, and are accurate only as of the date when this article was last updated. Microsoft will continue to make periodic updates to this document.
 
- **Product name**: Used in management portals
- **String ID**: Used by PowerShell v1.0 cmdlets when performing operations on licenses or by the **skuPartNumber** property of the **subscribedSku** Microsoft Graph API
- **Service plans included**: A list of service plans in the product that correspond to the string ID and GUID
- **Service plans included (friendly names)**: A list of service plans (friendly names) in the product that correspond to the string ID and GUID
 
>[!NOTE]
>This information was last updated on August 3, 2026.<br/>You can also download a CSV version of this table [here](https://download.microsoft.com/download/e/3/e/e3e9faf2-f28b-490a-9ada-c6089a1fc5b0/Product%20names%20and%20service%20plan%20identifiers%20for%20licensing.csv).
><br/>
 
| Product name | String ID | GUID | Service plans included | Service plans included (friendly names) |
| --- | --- | --- |--- | --- |
| 10-Year Audit Log Retention Add On | 10_ALR_ADDON | c2e41e49-e2a2-4c55-832a-cf13ffba1d6a | Auditing_10Year_ Retention_ Add_On (7d16094b-4db8-41ff-a182-372a90a85407) | Auditing 10Year Retention Add On (7d16094b-4db8-41ff-a182-372a90a85407) |
| Advanced Communications | ADV_COMMS | e4654015-5daf-4a48-9b37-4f309dddd88b | TEAMS_ADVCOMMS (604ec28a-ae18-4bc6-91b0-11da94504ba9) | Microsoft 365 Advanced Communications (604ec28a-ae18-4bc6-91b0-11da94504ba9) |
| Agent 365 | AGENT_365 | 796a6fb4-740b-4d36-bf56-9c12ca7fa069 | AGENT_365 (d0ce5ebb-9db0-491f-b780-8973a1d815fe)<br/>AUDIT_FOR_AGENTS (6d9b0ae5-e6a0-4f04-991a-e5700fd84930)<br/>COMMUNICATION_COMPLIANCE_FOR_AGENTS (135fe762-031a-4e79-bd3c-ac376addddec)<br/>COMPLIANCE_MANAGER_FOR_AGENTS (d1f65d05-a302-4861-bd35-da8933ba7655)<br/>DATA_LIFECYCLE_MANAGEMENT_FOR_AGENTS (30d56d35-9be2-41c1-b4b8-7a8d6f073152)<br/>DATA_LOSS_PREVENTION_FOR_AGENTS (46d3c309-0ba7-461f-9d0e-eaca165794c2)<br/>DEFENDER_FOR_AI (a1c15058-5559-4c1a-ba05-8040847f91bb)<br/>EDISCOVERY_FOR_AGENTS (92cedcb2-3fb2-40b4-9df4-f9a5603d9631)<br/>ENTRA_ID_GOV_FOR_ASSISTIVE_AGENTS (a9e85e05-1687-4958-8a4c-bdacda2943db)<br/>ENTRA_NETWORK_CONTROLS_FOR_ASSISTIVE_AGENTS (27e196a4-8b80-4930-bd65-53fd28581878)<br/>INFORMATION_PROTECTION_FOR_AGENTS (48478b49-91a1-4ded-94f0-066db80035ca)<br/>INSIDER_RISK_MANAGEMENT_FOR_AGENTS (004ddfc0-c92f-4b0a-90c5-c60646299d71) | Agent 365 (d0ce5ebb-9db0-491f-b780-8973a1d815fe)<br/>Microsoft Purview Audit for Agents (6d9b0ae5-e6a0-4f04-991a-e5700fd84930)<br/>Microsoft Purview Communication Compliance for Agents (135fe762-031a-4e79-bd3c-ac376addddec)<br/>Microsoft Purview Compliance Manager for Agents (d1f65d05-a302-4861-bd35-da8933ba7655)<br/>Microsoft Purview Data Lifecycle Management for Agents (30d56d35-9be2-41c1-b4b8-7a8d6f073152)<br/>Microsoft Purview Data Loss Prevention for Agents (46d3c309-0ba7-461f-9d0e-eaca165794c2)<br/>Microsoft Defender for AI (a1c15058-5559-4c1a-ba05-8040847f91bb)<br/>Microsoft Purview eDiscovery for Agents (92cedcb2-3fb2-40b4-9df4-f9a5603d9631)<br/>Microsoft Entra ID Governance for Assistive Agents (a9e85e05-1687-4958-8a4c-bdacda2943db)<br/>Microsoft Entra Network Controls for Assistive Agents (27e196a4-8b80-4930-bd65-53fd28581878)<br/>Microsoft Purview Information Protection for Agents (48478b49-91a1-4ded-94f0-066db80035ca)<br/>Microsoft Purview Insider Risk Management for Agents (004ddfc0-c92f-4b0a-90c5-c60646299d71) |
| AI Builder Capacity add-on | CDSAICAPACITY | d2dea78b-507c-4e56-b400-39447f4738f8 | CDSAICAPACITY (a7c70a41-5e02-4271-93e6-d9b4184d83f5)<br/>EXCHANGE_S_FOUNDATION (113feb6c-3fe4-4440-bddc-54d774bf0318) | AI Builder capacity add-on (a7c70a41-5e02-4271-93e6-d9b4184d83f5)<br/>Exchange Foundation (113feb6c-3fe4-4440-bddc-54d774bf0318) |
Modified by Adelle Ingrid Dimitui on Aug 3, 2026 4:29 PM
πŸ“– View on learn.microsoft.com
+1 / -1 lines changed
Commit: Added a link to lcw extensibility workflow article
Documentation change
Added guidance for LCW extensibility workflow mappings

The application attribute customization documentation now links the LCW extensibility workflow mapping type to a separate article explaining how to extend attribute mappings with these workflows.

Why admins should care: Administrators can use the new link for additional guidance; no product behavior or configuration change is documented.

Changes:
Before
After
> [!NOTE]
> The maximum supported length for a single attribute mapping expression is **10,000 characters**.
 
- **LCW extensibility workflow** - The target attribute is populated with the value generated by an Azure Logic app, which is triggered by an LCW extensibility workflow.
- **None** - the target attribute is left unmodified. However, if the target attribute is ever empty, it populates with the default value that you specify.
 
Along with these four basic types, custom attribute-mappings support the concept of an optional **default** value assignment. The default value assignment ensures that a target attribute is populated with a value if there's not a value in Microsoft Entra ID or on the target object. The most common configuration is to leave this blank. For more information about mapping attributes, see [How Application Provisioning works in Microsoft Entra ID](~/identity/app-provisioning/how-provisioning-works.md#mapping-attributes).
> [!NOTE]
> The maximum supported length for a single attribute mapping expression is **10,000 characters**.
 
- **LCW extensibility workflow** - The target attribute is populated with the value generated by an Azure Logic app, which is triggered by an LCW extensibility workflow. For more information about this mapping type, see [Extend attribute mappings with LCW extensibility workflows](~/identity/app-provisioning/extend-application-attributes.md).
- **None** - the target attribute is left unmodified. However, if the target attribute is ever empty, it populates with the default value that you specify.
 
Along with these four basic types, custom attribute-mappings support the concept of an optional **default** value assignment. The default value assignment ensures that a target attribute is populated with a value if there's not a value in Microsoft Entra ID or on the target object. The most common configuration is to leave this blank. For more information about mapping attributes, see [How Application Provisioning works in Microsoft Entra ID](~/identity/app-provisioning/how-provisioning-works.md#mapping-attributes).