📋 Microsoft Entra Documentation Changes

Changes for June 12th 2025

Period: June 11th 2025, 12:00 AM to June 12th 2025, 12:00 AM

📚 Historical Report: This report shows documentation changes that occurred during the 24-hour period ending on June 12th 2025.

📊 Summary

28
Total Commits
1
New Files
21
Modified Files
1
Deleted Files
15
Contributors

🆕 New Documentation Files

+21 lines added
Commit: 21790-21817-21793

📝 Modified Documentation Files

Modified by Chris Werner on Jun 11, 2025 7:42 PM
📖 View on learn.microsoft.com
+30 / -33 lines changed
Commit: Acrolinx update
Changes:
Before
After
manager: CelesteDG
ms.author: cwerner
ms.custom:
ms.date: 11/30/2021
ms.reviewer:
ms.service: identity-platform
 
 
# Run automated integration tests
 
As a developer, you want to run automated integration tests on the apps you develop. Calling your API protected by Microsoft identity platform (or other protected APIs such as [Microsoft Graph](/graph/)) in automated integration tests is a challenge. Microsoft Entra ID often requires an interactive user sign-in prompt, which is difficult to automate. This article describes how you can use a non-interactive flow, called [Resource Owner Password Credential Grant (ROPC)](v2-oauth-ropc.md), to automatically sign in users for testing.
 
To prepare for your automated integration tests, create some test users, create and configure an app registration, and potentially make some configuration changes to your tenant. Some of these steps require admin privileges. Also, Microsoft recommends that you *do not* use the ROPC flow in a production environment. Use a more trusted method such as the [authorization code flow](./v2-oauth2-auth-code-flow.md). [Create a separate test tenant](test-setup-environment.md) that you are an administrator of so you can safely and effectively run your automated integration tests.
 
> [!WARNING]
> Microsoft recommends you do *not* use the ROPC flow in a production environment. In most production scenarios, more secure alternatives are available and recommended. The ROPC flow requires a very high degree of trust in the application, and carries risks which are not present in other authentication flows. You should only use this flow for testing purposes in a [separate test tenant](test-setup-environment.md), and only with test users.
 
> [!IMPORTANT]
>
> * The Microsoft identity platform only supports ROPC within Microsoft Entra tenants, not personal accounts. This means that you must use a tenant-specific endpoint (`https://login.microsoftonline.com/{TenantId_or_Name}`) or the `organizations` endpoint.
manager: CelesteDG
ms.author: cwerner
ms.custom:
ms.date: 06/11/2025
ms.reviewer:
ms.service: identity-platform
 
 
# Run automated integration tests
 
As a developer, you want to run automated integration tests on the apps you develop. Calling your API protected by Microsoft identity platform (or other protected APIs such as [Microsoft Graph](/graph/)) in automated integration tests is a challenge. Microsoft Entra ID often requires an interactive user sign-in prompt, which is difficult to automate. This article describes how you can use a non-interactive flow, called [Resource Owner Password Credential Grant (ROPC)](v2-oauth-ropc.md), to automatically sign in users for testing.
 
To prepare for your automated integration tests, create some test users, create and configure an app registration, and potentially make some configuration changes to your tenant. Some of these steps require admin privileges. [Create a separate test tenant](test-setup-environment.md) that you are an administrator of so you can safely and effectively run your automated integration tests.
 
> [!WARNING]
> Microsoft recommends that you *do not* use the ROPC flow in a production environment. Use a more trusted method such as the [authorization code flow](./v2-oauth2-auth-code-flow.md). In most production scenarios, more secure alternatives are available and recommended. The ROPC flow requires a very high degree of trust in the application, and carries risks which aren't present in other authentication flows. You should only use this flow for testing purposes in a [separate test tenant](test-setup-environment.md), and only with test users.
 
> [!IMPORTANT]
>
> * The Microsoft identity platform only supports ROPC within Microsoft Entra tenants, not personal accounts. This means that you must use a tenant-specific endpoint (`https://login.microsoftonline.com/{TenantId_or_Name}`) or the `organizations` endpoint.
Modified by jayrusso on Jun 11, 2025 5:40 AM
📖 View on learn.microsoft.com
+6 / -8 lines changed
Commit: June 10 work continues
Changes:
Before
After
---
title:
ms.author: jayrusso
author: HULKsmashGithub
ms.service: entra-id
ms.topic: include
ms.date: 06/06/2025
manager: dougeby
ms.custom: Identity-Secure-Recommendation
# category: Access control
# risklevel: Medium
# userimpact: High
# implementationcost: Low
---
[insert text from "Customer-Facing Explanation" section here]
 
**Remediation action**
 
-
-
---
title: Require Password Reset Notifications for Administrator Roles
ms.author: jayrusso
author: HULKsmashGithub
ms.service: entra-id
ms.topic: include
ms.date: 06/10/2025
manager: dougeby
ms.custom: Identity-Secure-Recommendation
# category: Access control
# risklevel: High
# userimpact: Low
# implementationcost: Low
---
Configuring password reset notifications for administrator roles in Microsoft Entra ID enhances security by notifying privileged administrators when another administrator resets their password. This visibility helps detect unauthorized or suspicious activity that could indicate credential compromise or insider threats. Without these notifications, malicious actors could exploit elevated privileges to establish persistence, escalate access, or extract sensitive data. Proactive notifications support quick action, preserve privileged access integrity, and strengthen the overall security posture.
 
**Remediation action**
 
- [Notify all admins when other admins reset their passwords](../../identity/authentication/concept-sspr-howitworks.md#notify-all-admins-when-other-admins-reset-their-passwords)
 
Modified by jayrusso on Jun 11, 2025 5:40 AM
📖 View on learn.microsoft.com
+6 / -6 lines changed
Commit: June 10 work continues
Changes:
Before
After
---
title:
ms.author: jayrusso
author: HULKsmashGithub
ms.service: entra-id
ms.topic: include
ms.date: 06/06/2025
manager: dougeby
ms.custom: Identity-Secure-Recommendation
# category: Access control
# risklevel: High
# userimpact: Low
# implementationcost: Low
---
[]
 
**Remediation action**
 
---
title: Resource-Specific Consent Is Restricted
ms.author: jayrusso
author: HULKsmashGithub
ms.service: entra-id
ms.topic: include
ms.date: 06/10/2025
manager: dougeby
ms.custom: Identity-Secure-Recommendation
# category: Access control
# risklevel: Medium
# userimpact: Medium
# implementationcost: Medium
---
Letting group owners consent to applications in Microsoft Entra ID creates a lateral escalation path that lets threat actors persist and steal data without admin credentials. If an attacker compromises a group owner account, they can register or use a malicious application and consent to high-privilege Graph API permissions scoped to the group, such as reading all Teams messages, accessing SharePoint files, or managing group membership. This consent action creates a long-lived application identity with delegated or application permissions. The attacker maintains persistence with OAuth tokens, steals sensitive data from team channels and files, and impersonates users through messaging or email permissions. Without centralized enforcement of app consent policies, security teams lose visibility, and malicious applications spread under the radar, enabling multi-stage attacks across collaboration platforms.
 
**Remediation action**
 
Modified by jayrusso on Jun 11, 2025 7:48 AM
📖 View on learn.microsoft.com
+5 / -5 lines changed
Commit: June 10 work continues to continue
Changes:
Before
After
---
title: App Instance Property Lock is Configured for All Multitenant Applications
ms.author: jayrusso
author: HULKsmashGithub
ms.service: entra-id
ms.topic: include
ms.date: 06/06/2025
manager: dougeby
ms.custom: Identity-Secure-Recommendation
# category: Access control
# risklevel: Medium
# userimpact: High
# implementationcost: Low
---
App instance property lock prevents changes to sensitive properties of a multitenant application after the application is provisioned in another tenant. Without a lock, critical properties such as application credentials can be maliciously or unintentionally modified, causing disruptions, increased risk, unauthorized access, or privilege escalations.
 
**Remediation action**
 
- [Configure an app instance lock](../../identity-platform/howto-configure-app-instance-property-locks.md#configure-an-app-instance-lock)
---
title: App Instance Property Lock Is Configured for All Multitenant Applications
ms.author: jayrusso
author: HULKsmashGithub
ms.service: entra-id
ms.topic: include
ms.date: 06/10/2025
manager: dougeby
ms.custom: Identity-Secure-Recommendation
# category: Access control
# risklevel: High
# userimpact: Low
# implementationcost: Low
---
App instance property lock prevents changes to sensitive properties of a multitenant application after the application is provisioned in another tenant. Without a lock, critical properties such as application credentials can be maliciously or unintentionally modified, causing disruptions, increased risk, unauthorized access, or privilege escalations.
 
**Remediation action**
Enable the app instance property lock for all multitenant applications and specify the properties to lock.
- [Configure an app instance lock](../../identity-platform/howto-configure-app-instance-property-locks.md#configure-an-app-instance-lock)
Modified by jayrusso on Jun 11, 2025 5:40 AM
📖 View on learn.microsoft.com
+4 / -6 lines changed
Commit: June 10 work continues
Changes:
Before
After
---
title:
ms.author: jayrusso
author: HULKsmashGithub
ms.service: entra-id
ms.topic: include
ms.date: 06/06/2025
manager: dougeby
ms.custom: Identity-Secure-Recommendation
# category: Access control
# userimpact: High
# implementationcost: Low
---
[insert text from "Customer-Facing Explanation" section here]
 
**Remediation action**
 
-
-
-
---
title: Workload Identities are Configured with Risk-based Policies
ms.author: jayrusso
author: HULKsmashGithub
ms.service: entra-id
ms.topic: include
ms.date: 06/10/2025
manager: dougeby
ms.custom: Identity-Secure-Recommendation
# category: Access control
# userimpact: High
# implementationcost: Low
---
Configuring workload identity based on risk policy in Microsoft Entra ID is a critical security measure that ensures only trusted and verified workloads can access sensitive resources. Without these policies, threat actors can compromise workload identities with minimal detection to perform further attacks. The lack of conditional controls for risk detections, such as anomalous activity, allows malicious operations like token forgery, sensitive resource access, and disruption of workloads to proceed unchecked. The lack of automated containment mechanisms increases dwell time and impacts the confidentiality, integrity, and availability of critical services.
 
**Remediation action**
 
- [Create a risk-based Conditional Access policy](../../identity/conditional-access/workload-identity.md#create-a-risk-based-conditional-access-policy)
 
 
Modified by shlipsey3 on Jun 11, 2025 6:33 AM
📖 View on learn.microsoft.com
+5 / -5 lines changed
Commit: 21790-21817-21793
Changes:
Before
After
# userimpact: Low
# implementationcost: Low
---
Allowing unrestricted external collaboration with unvetted organizations increases the risk surface area to the tenant because it allows onboarding guest accounts that might not have proper security controls. Threat actors can establish initial access by compromising identities within loosely governed external tenants and leveraging legitimate collaboration pathways to infiltrate resources in your tenant. Once granted guest access, adversaries can attempt to harvest sensitive information, and exploit misconfigured permissions to escalate privileges and try additional attacks. Without vetting the security of organizations you collaborate with, malicious external accounts can persist undetected, exfiltrate confidential data, inject malicious payloads. This unbounded collaboration surface weakens organizational control, enabling cross-tenant attacks that bypass traditional perimeter defenses and undermine both data integrity and operational resilience.
 
Cross-tenant access settings for outbound access in Entra provides a mechanism to block collaboration by default with unknown organizations, reducing the attack surface created.
 
**Remediation action**
 
- [Disable inactive privileged service principals](/graph/api/serviceprincipal-update)
- Investigate if the application has legitimate use cases. If so, [analyze if a OAuth2 permission is a better fit](/entra/identity-platform/v2-app-types)
- [If service principal doesn't have legitimate use cases, delete it](/graph/api/serviceprincipal-delete)
# userimpact: Low
# implementationcost: Low
---
Allowing unrestricted external collaboration with unverified organizations can increase the risk surface area of the tenant because it allows guest accounts that might not have proper security controls. Threat actors can attempt to gain access by compromising identities in these loosely-governed external tenants. Once granted guest access, they can then leverage legitimate collaboration pathways to infiltrate resources in your tenant and attempt to gain sensitive information. Threat actors can also exploit misconfigured permissions to escalate privileges and try different types of attacks.
 
Without vetting the security of organizations you collaborate with, malicious external accounts can persist undetected, exfiltrate confidential data, and inject malicious payloads. This type of exposure can weaken organizational control and enable cross-tenant attacks that bypass traditional perimeter defenses and undermine both data integrity and operational resilience. Cross-tenant settings for outbound access in Microsoft Entra provides the ability to block collaboration with unknown organizations by default, reducing the attack surface.
 
**Remediation action**
 
- [Cross-tenant access overview](../../external-id/cross-tenant-access-overview.md)
- [Configure cross-tenant access settings](../../external-id/cross-tenant-access-settings-b2b-collaboration.yml#configure-default-settings)
- [Modify outbound access settings](../../external-id/cross-tenant-access-settings-b2b-collaboration.yml#modify-outbound-settings)
+7 / -3 lines changed
Commit: Update concept-mfa-regional-opt-in.md
Changes:
Before
After
 
When a transaction is flagged as potentially abusive:
- The transaction may be throttled, preventing immediate delivery of the SMS or voice call.
- The user may receive a message to try again later, indicating that the request was temporarily blocked.
- The user can choose an alternative authentication method, such as using the Microsoft Authenticator app or another registered method.
 
New tenants are subject to additional safeguards to prevent abuse from newly created or compromised tenants. Specifically, telephony activity is throttled for the first few days of the tenant's creation to limit excess telecom usage and reduce fraud exposure during this high-risk window.
 
IRSF poses a significant threat to online businesses and can cause reputational damage. By understanding IRSF, you can be more aware of the problem and can engage in implementing preventive measures such as regional restrictions, rate limiting, and phone number verification.
 
## SMS and Voice verification
For SMS and Voice verification, the following region codes require an opt-in. This means that if you'd like to use telecom in these regions, you'll have to reach out to support.
 
Region Code | Region Name
------------|------------
Afghanistan|93
 
 
 
 
When a transaction is flagged as potentially abusive:
- The transaction may be throttled, preventing immediate delivery of the SMS or voice call.
- The user may see a "Sorry, we're having trouble verifying your account"
- The user can choose an alternative authentication method, such as using the Microsoft Authenticator app or another registered method.
 
New tenants are subject to additional safeguards to prevent abuse from newly created or compromised tenants. Specifically, telephony activity is throttled for the first few days of the tenant's creation to limit excess telecom usage and reduce fraud exposure during this high-risk window.
 
IRSF poses a significant threat to online businesses and can cause reputational damage. By understanding IRSF, you can be more aware of the problem and can engage in implementing preventive measures such as regional restrictions, rate limiting, and phone number verification.
 
## Regions that need to opt-in for MFA telephony verification
 
For SMS and Voice verification, the following region codes require an opt-in. This means that if you'd like to use telecom in these regions, you'll have to reach out to support.
 
Note: We always recommend that customers figure more than one authentication, with at least one being a non-telecom method.
 
Note: If a user has previously received SMS or voice calls in the country and stopped receiving them, they may be temporarily throttled. PLease retry after some time. If users of a tenant are not receiving SMS or voice calls in a specific country, and the country is listed in the opt-in list, it may indicate that the customer/tenant is not enabled for telecom authentication in that country and may need to opt-in. In such cases we recommend that the user use an alternative authentication method to immediately unblock themselves. If telecom is required and they are unable to use an alternative authentication method for some reason, suggest opening a support ticket.
 
Region Code | Region Name
------------|------------
+7 / -3 lines changed
Commit: Updates
Changes:
Before
After
| Entitlement Management | [Guest policy assigned with custom extension](entitlement-management-logic-apps-integration.md) | Bill on successful request creation when a custom extension is included in the assignment policy.<br>**API**<br> https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/assignmentRequests when a custom extension is included in the assignment policy. | User requests access package assignment, Create access package assignment user update request. |
| Entitlement Management| [Guest is granted an auto-assignment policy](entitlement-management-access-package-auto-assignment-policy.md) | Bill on successful request creation with an auto-assignment policy. | Entitlement Management creates access package assignment request for user. |
| Entitlement Management | [Directly assign any user](entitlement-management-access-package-assignments.md#directly-assign-any-user-preview) | Bill on successful request creation when using directly assigning an access package to a user not yet in the directory.<br>**API**<br> https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/assignmentRequests when using requestType "*AdminAdd*" for a user who doesn’t exist in the directory. | Administrator directly assigns user to access package. |
| Entitlement Management |[Mark guest as governed](entitlement-management-access-package-manage-lifecycle.md) | Bill on conversion to governed user.<br>**API**<br> https://graph.microsoft.com/beta/identityGovernance/entitlementManagement/subjects where subjectLifecycle is set to "governed". | Update access package user lifecycle. |
| Lifecycle Workflows  | [Workflow is run for guest](what-are-lifecycle-workflows.md) | Bill on workflow execution.<br>**API**<br> https://graph.microsoft.com/v1.0/identityGovernance/lifecycleWorkflows/workflows/{workflowId}/activate | Workflow execution started for user. |
| Access Reviews  | [Access Review – machine learning assisted access reviews](review-recommendations-access-reviews.md#user-to-group-affiliation) | Bill on access review start date. | Available after 8/1/2025 |
| Access Reviews  | [Access Review – inactive users](review-recommendations-access-reviews.md#inactive-user-recommendations) | Bill on access review start date. | Available after 8/1/2025 |
 
 
## Guest billing in multitenant organizations
Governance features included with Microsoft Entra P2 including basic access reviews and entitlement management capabilities won't be
billed to the governance guest add-on. Only governance features that are exclusive to Microsoft Entra Suite or standalone Microsoft Entra ID Governance will be billed to the meter. See the billable tables action on this page for details.
 
 
## Related content
 
 
 
 
 
| Entitlement Management | [Guest policy assigned with custom extension](entitlement-management-logic-apps-integration.md) | Bill on successful request creation when a custom extension is included in the assignment policy.<br>**API**<br> https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/assignmentRequests when a custom extension is included in the assignment policy. | User requests access package assignment, Create access package assignment user update request. |
| Entitlement Management| [Guest is granted an auto-assignment policy](entitlement-management-access-package-auto-assignment-policy.md) | Bill on successful request creation with an auto-assignment policy. | Entitlement Management creates access package assignment request for user. |
| Entitlement Management | [Directly assign any user](entitlement-management-access-package-assignments.md#directly-assign-any-user-preview) | Bill on successful request creation when using directly assigning an access package to a user not yet in the directory.<br>**API**<br> https://graph.microsoft.com/v1.0/identityGovernance/entitlementManagement/assignmentRequests when using requestType "*AdminAdd*" for a user who doesn’t exist in the directory. | Administrator directly assigns user to access package. |
| Entitlement Management |[Mark guest as governed](entitlement-management-access-package-manage-lifecycle.md) | Bill on conversion to governed user.<br>**API**<br> https://graph.microsoft.com/beta/identityGovernance/entitlementManagement/subjects where *"subjectLifecycle"* is set to "governed". | Update access package user lifecycle. |
| Lifecycle Workflows  | [Workflow is run for guest](what-are-lifecycle-workflows.md) | Bill on workflow execution.<br>**API**<br> https://graph.microsoft.com/v1.0/identityGovernance/lifecycleWorkflows/workflows/{workflowId}/activate | Workflow execution started for user. |
| Access Reviews  | [Access Review – machine learning assisted access reviews](review-recommendations-access-reviews.md#user-to-group-affiliation) | Bill on access review decision or review end date if no decision. <br>**API**<br> https://graph.microsoft.com/v1.0/identityGovernance/accessReviews/definitions where recommendation settings is enabled in a group review. | Available after 8/1/2025 |
| Access Reviews  | [Access Review – inactive users](review-recommendations-access-reviews.md#inactive-user-recommendations) | Bill on access review decision or review end date if no decision.<br>**API**<br> https://graph.microsoft.com/v1.0/identityGovernance/accessReviews/definitions where inactive guest reviews are included in the policy for a group resource. | Available after 8/1/2025 |
 
 
## Guest billing in multitenant organizations
Governance features included with Microsoft Entra P2 including basic access reviews and entitlement management capabilities won't be
billed to the governance guest add-on. Only governance features that are exclusive to Microsoft Entra Suite or standalone Microsoft Entra ID Governance will be billed to the meter. See the billable tables action on this page for details.
 
**Does Governance guest billing apply to all guest users, including those within the first 50,000 Monthly Active Users (MAU)?**
 
Yes, there is no free tier for governance billing. Governance guest billing applies to all guest users, even those within the first 50,000 MAU.
 
 
## Related content
 
Modified by shlipsey3 on Jun 11, 2025 6:33 AM
📖 View on learn.microsoft.com
+4 / -4 lines changed
Commit: 21790-21817-21793
Changes:
Before
After
---
Microsoft services applications that operate in your tenant are identified as service principals with the owner organization ID "f8cdef31-a31e-4b4a-93e4-5f571e91255a". When these service principals have credentials configured in your tenant, they might create potential attack vectors that threat actors can exploit. If the credentials were added by an administrator and are no longer needed, they can become a target for attackers. Although less likely when proper preventive and detective controls are in place on privileged activities, credentials can also be added maliciously by threat actors. In either case, threat actors can use these credentials to authenticate as the service principal, gaining the same permissions and access rights as the Microsoft service application. This initial access can lead to privilege escalation if the application has high-level permissions, allowing lateral movement across the tenant. Attackers can then proceed to data exfiltration or persistence establishment through creating additional backdoor credentials.
 
When credentials (like client secrets or certificates) are configured for these service principals in your tenant, it means someone - either an administrator or a malicious actor - has enabled them to authenticate independently within your environment. These credentials should be investigated to determine their legitimacy and necessity. If they are no longer needed, they should be removed to reduce the risk. If they are still required, consider using OAuth2 permissions instead of credentials for better security practices.
 
**Remediation action**
 
- [Disable inactive privileged service principals](/graph/api/serviceprincipal-update)
- Investigate if the application has legitimate use cases. If so, [analyze if a OAuth2 permission is a better fit](/entra/identity-platform/v2-app-types)
- [If service principal doesn't have legitimate use cases, delete it](/graph/api/serviceprincipal-delete)
---
Microsoft services applications that operate in your tenant are identified as service principals with the owner organization ID "f8cdef31-a31e-4b4a-93e4-5f571e91255a". When these service principals have credentials configured in your tenant, they might create potential attack vectors that threat actors can exploit. If the credentials were added by an administrator and are no longer needed, they can become a target for attackers. Although less likely when proper preventive and detective controls are in place on privileged activities, credentials can also be added maliciously by threat actors. In either case, threat actors can use these credentials to authenticate as the service principal, gaining the same permissions and access rights as the Microsoft service application. This initial access can lead to privilege escalation if the application has high-level permissions, allowing lateral movement across the tenant. Attackers can then proceed to data exfiltration or persistence establishment through creating additional backdoor credentials.
 
When credentials (like client secrets or certificates) are configured for these service principals in your tenant, it means someone - either an administrator or a malicious actor - has enabled them to authenticate independently within your environment. These credentials should be investigated to determine their legitimacy and necessity. If they are no longer needed, they should be removed to reduce the risk.
 
If this check doesn't pass, it's labeled as "investigate" because you need to identify and review any applications with unused credentials configured.
 
**Remediation action**
 
- [Follow the Entra recommendation guidance to remove unused credentials from apps](../../identity/monitoring-health/recommendation-remove-unused-credential-from-apps.md)
Modified by shlipsey3 on Jun 11, 2025 6:33 AM
📖 View on learn.microsoft.com
+3 / -4 lines changed
Commit: 21790-21817-21793
Changes:
Before
After
# userimpact: Low
# implementationcost: Low
---
Without approval workflows, threat actors who compromise Global Administrator credentials through phishing, credential stuffing, or other authentication bypass techniques can immediately activate the most privileged role in the tenant without any additional verification or oversight. Since PIM allows eligible role activations to become active within seconds, compromised credentials enable near-instant privilege escalation. Once activated, threat actors leverage the Global Administrator role for persistent access by creating additional privileged accounts, modifying conditional access policies to exclude their accounts, and establishing alternate authentication methods such as certificate-based authentication or application registrations with high privileges. The Global Administrator role provides access to administrative features in Microsoft Entra ID and services that use Microsoft Entra identities, including Microsoft 365 Defender, Microsoft Purview, Exchange Online, and SharePoint Online. Without approval gates, threat actors can rapidly escalate to complete tenant takeover, exfiltrating sensitive data, compromising all user accounts, and establishing long-term backdoors through service principals or federation modifications that persist even after the initial compromise is detected.
 
**Remediation action**
- [Enable approval workflows for Global Administrator role activation](/entra/identity-governance/privileged-identity-management/configure-approval-workflows)
- [Require MFA for all privileged role activations](/entra/identity-governance/privileged-identity-management/configure-mfa)
- [Regularly review and audit privileged role assignments](/entra/identity-governance/privileged-identity-management/review-privileged-role-assignments)
# userimpact: Low
# implementationcost: Low
---
Without approval workflows, threat actors who compromise Global Administrator credentials through phishing, credential stuffing, or other authentication bypass techniques can immediately activate the most privileged role in a tenant without any additional verification or oversight. Privileged Identity Management (PIM) allows eligible role activations to become active within seconds, so compromised credentials can allow near-instant privilege escalation. Once activated, threat actors can use the Global Administrator role to gain persistent access by creating new privileged accounts, modifying Conditional Access policies to exclude those new accounts, and establishing alternate authentication methods such as certificate-based authentication or application registrations with high privileges. The Global Administrator role provides access to administrative features in Microsoft Entra ID and services that use Microsoft Entra identities, including Microsoft 365 Defender, Microsoft Purview, Exchange Online, and SharePoint Online. Without approval gates, threat actors can rapidly escalate to complete tenant takeover, exfiltrating sensitive data, compromising all user accounts, and establishing long-term backdoors through service principals or federation modifications that persist even after the initial compromise is detected.
 
**Remediation action**
- [Configure role settings to require approval for Global Administrator role activation](../../id-governance/privileged-identity-management/pim-how-to-change-default-settings.md)
- [Set up approval workflows for privileged roles](../../id-governance/privileged-identity-management/pim-approval-workflow.md)
 
Modified by jayrusso on Jun 11, 2025 7:48 AM
📖 View on learn.microsoft.com
+2 / -4 lines changed
Commit: June 10 work continues to continue
Changes:
Before
After
---
title: ID Protection Notifications are Enabled
ms.author: jayrusso
author: HULKsmashGithub
ms.service: entra-id
 
**Remediation action**
 
-
-
-
---
title: ID Protection Notifications Are Enabled
ms.author: jayrusso
author: HULKsmashGithub
ms.service: entra-id
 
**Remediation action**
 
- [Configure users at risk detected alerts](../../id-protection/howto-identity-protection-configure-notifications.md#configure-users-at-risk-detected-alerts)
 
 
Modified by Thiago Cardoso Luiz on Jun 11, 2025 12:50 AM
📖 View on learn.microsoft.com
+3 / -3 lines changed
Commit: Update github-enterprise-managed-user-tutorial.md
Changes:
Before
After
1. Ensure that you have your Enterprise URL before you begin. The ENTITY field mentioned below is the Enterprise name of your EMU-enabled Enterprise URL. For example, https://github.com/enterprises/contoso - **contoso** is the ENTITY. On the **Basic SAML Configuration** section, if you wish to configure the application in **IDP** initiated mode, enter the values for the following fields:
 
a. In the **Identifier** text box, type a URL using the following pattern:
`https://github.com/enterprises/<ENTITY>`
> [!NOTE]
> Note the identifier format is different from the application's suggested format - please follow the format above. In addition, please ensure the **Identifier doesn't contain a trailing slash.
b. In the **Reply URL** text box, type a URL using the following pattern:
`https://github.com/enterprises/<ENTITY>/saml/consume`
 
1. Select **Set additional URLs** and perform the following step if you wish to configure the application in **SP** initiated mode:
 
In the **Sign-on URL** text box, type a URL using the following pattern:
`https://github.com/enterprises/<ENTITY>/sso`
 
1. On the **Set up single sign-on with SAML** page, in the **SAML Signing Certificate** section, find **Certificate (PEM)** and select **PEM certificate download** to download the certificate and save it on your computer.
 
1. Ensure that you have your Enterprise URL before you begin. The ENTITY field mentioned below is the Enterprise name of your EMU-enabled Enterprise URL. For example, https://github.com/enterprises/contoso - **contoso** is the ENTITY. On the **Basic SAML Configuration** section, if you wish to configure the application in **IDP** initiated mode, enter the values for the following fields:
 
a. In the **Identifier** text box, type a URL using the following pattern:
`https://github.com/enterprises/{enterprise}`
> [!NOTE]
> Note the identifier format is different from the application's suggested format - please follow the format above. In addition, please ensure the **Identifier doesn't contain a trailing slash.
b. In the **Reply URL** text box, type a URL using the following pattern:
`https://github.com/enterprises/{enterprise}/saml/consume`
 
1. Select **Set additional URLs** and perform the following step if you wish to configure the application in **SP** initiated mode:
 
In the **Sign-on URL** text box, type a URL using the following pattern:
`https://github.com/enterprises/{enterprise}/sso`
 
1. On the **Set up single sign-on with SAML** page, in the **SAML Signing Certificate** section, find **Certificate (PEM)** and select **PEM certificate download** to download the certificate and save it on your computer.
 
Modified by Shreya Goyal on Jun 11, 2025 10:35 PM
📖 View on learn.microsoft.com
+1 / -3 lines changed
Commit: Removed unwanted code
Changes:
Before
After
* Enable your users to be automatically signed-in to my.sdworx.com with their Microsoft Entra accounts.
* Manage your accounts in one central location.
 
<!-- You configure and test Microsoft Entra single sign-on for my.sdworx.com in a test environment. my.sdworx.com supports **IDP** initiated single sign-on. -->
 
You configure and test Microsoft Entra single sign-on for my.sdworx.com in a test environment (my.acc.sdworx.com) but not by using this gallery app (import SP metadata, to be provided by your my.sdworx.com contact). my.sdworx.com supports **IDP** and **SP** initiated single sign-on.
When using **SP** initiated initiated single sign-on, only “email domain” realm discovery is supported, which means only company/enterprise email addresses are allowed (no private email addresses like hotmail.com, gmail.com, …)
 
* Enable your users to be automatically signed-in to my.sdworx.com with their Microsoft Entra accounts.
* Manage your accounts in one central location.
 
You configure and test Microsoft Entra single sign-on for my.sdworx.com in a test environment (my.acc.sdworx.com) but not by using this gallery app (import SP metadata, to be provided by your my.sdworx.com contact). my.sdworx.com supports **IDP** and **SP** initiated single sign-on.
When using **SP** initiated initiated single sign-on, only “email domain” realm discovery is supported, which means only company/enterprise email addresses are allowed (no private email addresses like hotmail.com, gmail.com, …)
 
 
 
Modified by Ortagus Winfrey on Jun 11, 2025 6:14 AM
📖 View on learn.microsoft.com
+2 / -2 lines changed
Commit: Update Licensing includes table with correct links
Changes:
Before
After
|[Entitlement management - Mark guest as governed](~/id-governance/entitlement-management-access-package-manage-lifecycle.md)|||| :white_check_mark: | :white_check_mark: |
|[Entitlement management - Manage the lifecycle of external users](~/id-governance/entitlement-management-external-users.md#manage-the-lifecycle-of-external-users)||| :white_check_mark: | :white_check_mark: | :white_check_mark: |
|[My Access portal](~/id-governance/my-access-portal-overview.md)||| :white_check_mark: | :white_check_mark: | :white_check_mark: |
|[Entitlement management - Microsoft Entra Roles (Preview)](~/id-governance/entitlement-management-request-behalf.md)|||| :white_check_mark: | :white_check_mark: |
|[Entitlement management - Request access packages on-behalf-of (Preview)](~/id-governance/entitlement-management-roles.md)|||| :white_check_mark: | :white_check_mark: |
|[Entitlement management - Sponsors Policy](~/id-governance/entitlement-management-access-package-create.md)|||| :white_check_mark: | :white_check_mark: |
|[Privileged Identity Management (PIM)](~/id-governance/privileged-identity-management/pim-configure.md)||| :white_check_mark: | :white_check_mark: | :white_check_mark: |
|[PIM For Groups](~/id-governance/privileged-identity-management/concept-pim-for-groups.md)||| :white_check_mark: | :white_check_mark: | :white_check_mark: |
|[Entitlement management - Mark guest as governed](~/id-governance/entitlement-management-access-package-manage-lifecycle.md)|||| :white_check_mark: | :white_check_mark: |
|[Entitlement management - Manage the lifecycle of external users](~/id-governance/entitlement-management-external-users.md#manage-the-lifecycle-of-external-users)||| :white_check_mark: | :white_check_mark: | :white_check_mark: |
|[My Access portal](~/id-governance/my-access-portal-overview.md)||| :white_check_mark: | :white_check_mark: | :white_check_mark: |
|[Entitlement management - Microsoft Entra Roles (Preview)](~/id-governance/entitlement-management-roles.md)|||| :white_check_mark: | :white_check_mark: |
|[Entitlement management - Request access packages on-behalf-of (Preview)](~/id-governance/entitlement-management-request-behalf.md)|||| :white_check_mark: | :white_check_mark: |
|[Entitlement management - Sponsors Policy](~/id-governance/entitlement-management-access-package-create.md)|||| :white_check_mark: | :white_check_mark: |
|[Privileged Identity Management (PIM)](~/id-governance/privileged-identity-management/pim-configure.md)||| :white_check_mark: | :white_check_mark: | :white_check_mark: |
|[PIM For Groups](~/id-governance/privileged-identity-management/concept-pim-for-groups.md)||| :white_check_mark: | :white_check_mark: | :white_check_mark: |
Modified by csmulligan on Jun 11, 2025 8:03 PM
📖 View on learn.microsoft.com
+1 / -1 lines changed
Commit: Minor OTP update.
Changes:
Before
After
 
### One time passcode send
The **OnOtpSend** event is triggered when a one time passcode email is activated. It allows you to [call a REST API to use your own email provider](./custom-extension-email-otp-get-started.md). This event can be used to send customized emails to users who sign up with email address, sign-in with email one-time passcode (Email OTP), reset their password using email one-time-passcode, or user Email OTP for multifactor authentication (MFA).
When the **OnOtpSend** event is activated, Microsoft Entra sends a one-time passcode to the specified REST API you own. The REST API then uses your chosen email provider, such as Azure Communication Service or SendGrid, to send the one-time passcode with your custom email template, from address, and email subject, while also supporting localization.
 
 
### One time passcode send
The **OnOtpSend** event is triggered when a one time passcode email is activated. It allows you to [call a REST API to use your own email provider](./custom-extension-email-otp-get-started.md). This event can be used to send customized emails to users who sign up with email address, sign in with email one-time passcode (Email OTP), reset their password using Email OTP, or use Email OTP for multifactor authentication (MFA).
When the **OnOtpSend** event is activated, Microsoft Entra sends a one-time passcode to the specified REST API you own. The REST API then uses your chosen email provider, such as Azure Communication Service or SendGrid, to send the one-time passcode with your custom email template, from address, and email subject, while also supporting localization.
 

🗑️ Deleted Documentation Files

DELETED docs/includes/secure-recommendations/27193.md
Deleted by shlipsey3 on Jun 11, 2025 6:33 AM
📖 Was available at: https://learn.microsoft.com/en-us/entra/includes/secure-recommendations/27193
-21 lines removed
Commit: 21790-21817-21793