πŸ“‹ Microsoft Entra Documentation Changes

Daily summary for changes since January 4th 2026, 7:44 PM PST

Report generated on January 5th 2026, 7:44 PM PST

πŸ“Š Summary

11
Total Commits
0
New Files
2
Modified Files
0
Deleted Files
7
Contributors

πŸ“ Modified Documentation Files

+25 / -1 lines changed
Commit: idp-token-detections-010525
Changes:
Before
After
description: Learn how to configure user self-remediation and manually remediate risky users in Microsoft Entra ID Protection.
ms.service: entra-id-protection
ms.topic: how-to
ms.date: 06/12/2025
author: shlipsey3
ms.author: sarahlipsey
manager: pmwongera
 
If a user was deleted from the directory that had a risk present, that user still appears in the risk report even though the account was deleted. Administrators can't dismiss risk for users who were deleted from the directory. To remove deleted users, open a Microsoft support case.
 
## PowerShell preview
 
Using the Microsoft Graph PowerShell SDK Preview module, organizations can manage risk using PowerShell. The preview modules and sample code can be found in the [Microsoft Entra GitHub repo](https://github.com/AzureAD/IdentityProtectionTools).
 
 
 
 
 
 
 
description: Learn how to configure user self-remediation and manually remediate risky users in Microsoft Entra ID Protection.
ms.service: entra-id-protection
ms.topic: how-to
ms.date: 01/05/2026
author: shlipsey3
ms.author: sarahlipsey
manager: pmwongera
 
If a user was deleted from the directory that had a risk present, that user still appears in the risk report even though the account was deleted. Administrators can't dismiss risk for users who were deleted from the directory. To remove deleted users, open a Microsoft support case.
 
## Token theft related detections
 
With a recent update to our detection architecture, we no longer autoremediate sessions with MFA claims when a token theft related or the Microsoft Threat Intelligence Center (MSTIC) Nation State IP detection triggers during sign-in.
 
The following ID Protection detections that identify suspicious token activity or the MSTIC Nation State IP detection are no longer auto-remediated:
 
- Microsoft Entra threat intelligenceβ€―
- Anomalous token
- Attacker in the Middle
- MSTIC Nation State IP
+14 / -3 lines changed
Commit: Update consent policies and mail client details
Changes:
Before
After
ms.subservice: enterprise-apps
 
ms.topic: how-to
ms.date: 10/15/2025
ms.author: jomondi
ms.reviewer: ergreenl, phsignor
ms.custom: enterprise-apps
Every tenant comes with a set of app consent policies that are the same across all tenants. Some of these built-in policies are used in existing built-in directory roles. For example, the `microsoft-application-admin` app consent policy describes the conditions under which the Application Administrator and Cloud Application Administrator roles are allowed to grant tenant-wide admin consent. Built-in policies can be used in custom directory roles or to configure an organization's default consent policy. These policies can't be edited. A list of the built-in policies are:
- **microsoft-user-default-low:** All low risk permissions consentable by member type users by default.
- **microsoft-user-default-recommended:** Permissions consentable based on Microsoft's current recommendations.
- **microsoft-all-application-permissions:** Includes all application permissions (app roles), for all APIs, for any client application.
- **microsoft-dynamically-managed-permissions-for-chat:** Includes dynamically managed permissions allowed for chat resource-specific consent.
- **microsoft-all-application-permissions-for-chat:** Includes all chat resource-specific application permissions, for all APIs, for any client application.
- **microsoft-company-admin:** Permissions consentable by Company Administrators.
 
> [!WARNING]
> Microsoft-user-default-recommended is a Microsoft managed policy. The conditions included in the policy are automatically updated based on Microsoft's latest security recommendations for end-user consent.
 
## Microsoft recommended current settings
 
ms.subservice: enterprise-apps
 
ms.topic: how-to
ms.date: 01/05/2026
ms.author: jomondi
ms.reviewer: ergreenl, phsignor
ms.custom: enterprise-apps
Every tenant comes with a set of app consent policies that are the same across all tenants. Some of these built-in policies are used in existing built-in directory roles. For example, the `microsoft-application-admin` app consent policy describes the conditions under which the Application Administrator and Cloud Application Administrator roles are allowed to grant tenant-wide admin consent. Built-in policies can be used in custom directory roles or to configure an organization's default consent policy. These policies can't be edited. A list of the built-in policies are:
- **microsoft-user-default-low:** All low risk permissions consentable by member type users by default.
- **microsoft-user-default-recommended:** Permissions consentable based on Microsoft's current recommendations.
- **microsoft-user-default-consent-apps:** Popular mail clients consentable for users
- **microsoft-all-application-permissions:** Includes all application permissions (app roles), for all APIs, for any client application.
- **microsoft-dynamically-managed-permissions-for-chat:** Includes dynamically managed permissions allowed for chat resource-specific consent.
- **microsoft-all-application-permissions-for-chat:** Includes all chat resource-specific application permissions, for all APIs, for any client application.
- **microsoft-company-admin:** Permissions consentable by Company Administrators.
 
> [!WARNING]
> Microsoft-user-default-recommended and microsoft-user-default-consent-apps are a Microsoft managed policies. The conditions included in the policies are automatically updated based on Microsoft's latest security recommendations for end-user consent.
 
## Microsoft recommended current settings