📋 Microsoft Entra Documentation Changes

Daily summary for changes since February 19th 2026, 8:12 PM PST

Report generated on February 20th 2026, 8:12 PM PST

📊 Summary

15
Total Commits
0
New Files
4
Modified Files
0
Deleted Files
7
Contributors

📝 Modified Documentation Files

Modified by anksridhar on Feb 20, 2026 4:15 PM
📖 View on learn.microsoft.com
+13 / -0 lines changed
Commit: Add section on blocking access for high-risk users
Changes:
Before
After
- [Multifactor authentication for all users](#multifactor-authentication-for-all-users)
- [Multifactor authentication for per-user multifactor authentication users](#multifactor-authentication-for-per-user-multifactor-authentication-users)
- [Multifactor authentication and reauthentication for risky sign-ins](#multifactor-authentication-and-reauthentication-for-risky-sign-ins)
 
### Block all high risk agents from accessing all resources (Preview)
 
 
To prevent attackers from taking over accounts, Microsoft blocks risky users from registering for multifactor authentication.
 
## Security defaults policies
 
The following policies are available for when you upgrade from using security defaults.
 
 
 
 
 
 
 
 
- [Multifactor authentication for all users](#multifactor-authentication-for-all-users)
- [Multifactor authentication for per-user multifactor authentication users](#multifactor-authentication-for-per-user-multifactor-authentication-users)
- [Multifactor authentication and reauthentication for risky sign-ins](#multifactor-authentication-and-reauthentication-for-risky-sign-ins)
- [Block access for high-risk users](#block-access-for-high-risk-users)
 
### Block all high risk agents from accessing all resources (Preview)
 
 
To prevent attackers from taking over accounts, Microsoft blocks risky users from registering for multifactor authentication.
 
 
### Block access for high-risk users
 
This policy helps protect your organization by restricting access for users identified as high risk by Microsoft Entra ID Protection. User risk represents the likelihood that a user account has been compromised, based on signals such as leaked credentials or other risk detections.When enabled, this policy blocks access for users who meet the configured high user risk level until the risk is remediated. Remediation follows existing Microsoft Entra ID Protection processes and guidance.
 
This policy targets:
 
- Organizations with Microsoft Entra ID P2 licenses
- Organizations where security defaults aren't enabled
 
+6 / -6 lines changed
Commit: Fix Windows client doc: registry key table formatting and ARM64 guidance
Changes:
Before
After
- Azure Virtual Desktop single-session is supported.
- Azure Virtual Desktop multi-session isn't supported.
- Windows 365 is supported.
- You need local admin credentials to install or upgrade the Global Secure Access client.
- The Global Secure Access client requires a license. For details, see the licensing section of [What is Global Secure Access](overview-what-is-global-secure-access.md). If needed, you can [buy licenses or get trial licenses](https://aka.ms/azureadlicense).
 
 
### Restrict nonprivileged users
Administrators can prevent nonprivileged users on the Windows device from disabling or enabling the client by setting the following registry key:
`Computer\HKEY_LOCAL_MACHINE\Software\Microsoft\Global Secure Access Client`
`RestrictNonPrivilegedUsers REG_DWORD`
 
|Data|Description|
|--|--|
| 0x0 | Nonprivileged users on the Windows device can disable and enable the client. |
| 0x1 | Nonprivileged users on the Windows device are restricted from disabling and enabling the client. A UAC prompt requires local administrator credentials for disable and enable options. The administrator can also hide the disable button (see [Hide or unhide system tray menu buttons](#hide-or-unhide-system-tray-menu-buttons)). |
 
### Disable or enable Private Access on the client
This registry value controls whether Private Access is enabled or disabled for the client. If a user is connected to the corporate network, they can choose to bypass Global Secure Access and directly access private applications.
- Azure Virtual Desktop single-session is supported.
- Azure Virtual Desktop multi-session isn't supported.
- Windows 365 is supported.
- Windows on Arm devices (such as Surface Pro and Surface Laptop with Snapdragon processors) require a separate client installer, available at **aka.ms/GlobalSecureAccess-WindowsOnArm**. Don't use the standard x64 installer on Arm64 devices.
- You need local admin credentials to install or upgrade the Global Secure Access client.
- The Global Secure Access client requires a license. For details, see the licensing section of [What is Global Secure Access](overview-what-is-global-secure-access.md). If needed, you can [buy licenses or get trial licenses](https://aka.ms/azureadlicense).
 
 
### Restrict nonprivileged users
Administrators can prevent nonprivileged users on the Windows device from disabling or enabling the client by setting the following registry key:
`Computer\HKEY_LOCAL_MACHINE\Software\Microsoft\Global Secure Access Client`
 
|Value |Type |Data |Description |
|---------|---------|---------|---------|
|RestrictNonPrivilegedUsers |REG_DWORD |0x0 |Nonprivileged users on the Windows device can disable and enable the client. |
|RestrictNonPrivilegedUsers |REG_DWORD |0x1 |Nonprivileged users on the Windows device are restricted from disabling and enabling the client. A UAC prompt requires local administrator credentials for disable and enable options. The administrator can also hide the disable button (see [Hide or unhide system tray menu buttons](#hide-or-unhide-system-tray-menu-buttons)). |
 
### Disable or enable Private Access on the client
This registry value controls whether Private Access is enabled or disabled for the client. If a user is connected to the corporate network, they can choose to bypass Global Secure Access and directly access private applications.
+1 / -1 lines changed
Commit: Fix Kerberos SSO: correct klist flag to KEYLIST in nltest output
Changes:
Before
After
 
`nltest /dsgetdc:contoso /keylist /kdc`
 
Verify the DC locator returns a Domain Controller that is a participant of cloud Kerberos trust operations. The returned DC should have the `klist` flag.
 
### How to avoid Kerberos Negative Caching on Windows Machines
Kerberos is the preferred authentication method for services in Windows that verify user or host identities. Kerberos negative caching causes a delay in Kerberos tickets.
 
`nltest /dsgetdc:contoso /keylist /kdc`
 
Verify the DC locator returns a Domain Controller that is a participant of cloud Kerberos trust operations. The returned DC should have the `KEYLIST` flag.
 
### How to avoid Kerberos Negative Caching on Windows Machines
Kerberos is the preferred authentication method for services in Windows that verify user or host identities. Kerberos negative caching causes a delay in Kerberos tickets.
Modified by barclayn on Feb 20, 2026 5:44 PM
📖 View on learn.microsoft.com
+1 / -1 lines changed
Commit: making changes to service limits
Changes:
Before
After
| Category | Limit |
| --- | --- |
| Tenants | <ul><li>A single user can belong to a maximum of 500 Microsoft Entra tenants as a member or a guest.</li><li>Create a maximum of 200 tenants. This limit only applies to the legacy add-on tenant creation experience in the Microsoft Entra admin center.</li><li>Limit of 300 [license-based subscriptions](/microsoft-365/commerce/licenses/subscriptions-and-licenses) (such as Microsoft 365 subscriptions) per tenant.</li></ul> |
| Domains | <ul><li>You can add no more than 5,000 managed domain names.</li><li>If you set up all of your domains for federation with on-premises Active Directory, you can add no more than 2,500 domain names in each tenant.</li></ul> |
| Resources | <ul><li>By default, a maximum of 50,000 Microsoft Entra resources can be created in a single tenant by users of the Microsoft Entra ID Free edition. If you have at least one verified domain, the default Microsoft Entra service quota for your organization is extended to 300,000 Microsoft Entra resources.<br>The Microsoft Entra service quota for organizations created by self-service sign-up remains 50,000 Microsoft Entra resources, even after you perform an internal admin takeover and the organization is converted to a managed tenant with at least one verified domain. This service limit is unrelated to the pricing tier limit of 500,000 resources on the Microsoft Entra pricing page.<br>To go beyond the default quota, you must contact Microsoft Support.</li><li>A non-admin user can create no more than 250 Microsoft Entra resources. Both active resources and deleted resources that are available to restore count toward this quota. Only deleted Microsoft Entra resources that were deleted fewer than 30 days ago are available to restore. Deleted Microsoft Entra resources that are no longer available to restore count toward this quota at a value of one-quarter for 30 days.<br>If you have developers who are likely to repeatedly exceed this quota in the course of their regular duties, you can [create and assign a custom role](~/identity/role-based-access-control/quickstart-app-registration-limits.md) with permission to create a limitless number of app registrations.</li><li>Resource limitations apply to all directory objects in a given Microsoft Entra tenant, including users, groups, applications, and service principals.</li></ul> |
| Schema extensions |<ul><li>String-type extensions can have a maximum of 256 characters. </li><li>Binary-type extensions are limited to 256 bytes.</li><li>Only 100 extension values, across *all* types and *all* applications, can be written to any single Microsoft Entra resource.</li><li>Only User, Group, TenantDetail, Device, Application, and ServicePrincipal entities can be extended with string-type or binary-type single-valued attributes.</li><li> Only the "equals" operator is supported for DateTime-type extensions. Range operators like "greater than" or "less than" are not supported.</li></ul> |
| Applications | <ul><li>A maximum of 100 users and service principals can be owners of a single application.</li><li>A user, group, or service principal can have a maximum of 1,500 app role assignments. The limitation is on the assigned service principal, user, or group across all app roles and not on the number of assignments of a single app role. This limit includes app role assignments where the resource service principal has been soft-deleted.</li><li>A user can have credentials configured for a maximum of 48 apps using password-based single sign-on. This limit only applies for credentials configured when the user is directly assigned the app, not when the user is a member of a group that is assigned.</li><li>A group can have credentials configured for a maximum of 48 apps using password-based single sign-on.</li><li>See additional limits in [Validation differences by supported account types](~/identity-platform/supported-accounts-validation.md).</li></ul> |
| Category | Limit |
| --- | --- |
| Tenants | <ul><li>A single user can belong to a maximum of 500 Microsoft Entra tenants as a member or a guest.</li><li>Create a maximum of 200 tenants. This limit only applies to the legacy add-on tenant creation experience in the Microsoft Entra admin center.</li><li>Limit of 300 [license-based subscriptions](/microsoft-365/commerce/licenses/subscriptions-and-licenses) (such as Microsoft 365 subscriptions) per tenant.</li></ul> |
| Domains | <ul><li>You can add no more than 5,000 managed domain names.</li><li>If you set up all of your domains for federation with on-premises Active Directory, we strongly recommend limiting to 300 domain names in each tenant for optimal performance. The maximum supported limit is 2,500 domain names.</li></ul> |
| Resources | <ul><li>By default, a maximum of 50,000 Microsoft Entra resources can be created in a single tenant by users of the Microsoft Entra ID Free edition. If you have at least one verified domain, the default Microsoft Entra service quota for your organization is extended to 300,000 Microsoft Entra resources.<br>The Microsoft Entra service quota for organizations created by self-service sign-up remains 50,000 Microsoft Entra resources, even after you perform an internal admin takeover and the organization is converted to a managed tenant with at least one verified domain. This service limit is unrelated to the pricing tier limit of 500,000 resources on the Microsoft Entra pricing page.<br>To go beyond the default quota, you must contact Microsoft Support.</li><li>A non-admin user can create no more than 250 Microsoft Entra resources. Both active resources and deleted resources that are available to restore count toward this quota. Only deleted Microsoft Entra resources that were deleted fewer than 30 days ago are available to restore. Deleted Microsoft Entra resources that are no longer available to restore count toward this quota at a value of one-quarter for 30 days.<br>If you have developers who are likely to repeatedly exceed this quota in the course of their regular duties, you can [create and assign a custom role](~/identity/role-based-access-control/quickstart-app-registration-limits.md) with permission to create a limitless number of app registrations.</li><li>Resource limitations apply to all directory objects in a given Microsoft Entra tenant, including users, groups, applications, and service principals.</li></ul> |
| Schema extensions |<ul><li>String-type extensions can have a maximum of 256 characters. </li><li>Binary-type extensions are limited to 256 bytes.</li><li>Only 100 extension values, across *all* types and *all* applications, can be written to any single Microsoft Entra resource.</li><li>Only User, Group, TenantDetail, Device, Application, and ServicePrincipal entities can be extended with string-type or binary-type single-valued attributes.</li><li> Only the "equals" operator is supported for DateTime-type extensions. Range operators like "greater than" or "less than" are not supported.</li></ul> |
| Applications | <ul><li>A maximum of 100 users and service principals can be owners of a single application.</li><li>A user, group, or service principal can have a maximum of 1,500 app role assignments. The limitation is on the assigned service principal, user, or group across all app roles and not on the number of assignments of a single app role. This limit includes app role assignments where the resource service principal has been soft-deleted.</li><li>A user can have credentials configured for a maximum of 48 apps using password-based single sign-on. This limit only applies for credentials configured when the user is directly assigned the app, not when the user is a member of a group that is assigned.</li><li>A group can have credentials configured for a maximum of 48 apps using password-based single sign-on.</li><li>See additional limits in [Validation differences by supported account types](~/identity-platform/supported-accounts-validation.md).</li></ul> |