App property limits updates#1873
Conversation
Jackson-Woods
commented
Jan 30, 2026
Jackson-Woods
commented
- Update service limits page with extension and credential limit info
- Update validation by account type page with extension and credential limit info
- Raise prominence of global app size limit on validations page
Added global application property limit and updated validation details for certificates and client secrets.
prmerger-automator
bot
requested review from
barclayn,
cilwerner and
sureshja
|
@Jackson-Woods : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change. |
|
Learn Build status updates of commit 217997a: ✅ Validation status: passed
For more details, please refer to the build report. |
|
Can you review the proposed changes? Important: When the changes are ready for publication, adding a #label:"aq-pr-triaged" |
There was a problem hiding this comment.
Pull request overview
This pull request updates documentation for Microsoft Entra application property limits across two files. The changes add new limit information and improve the prominence of existing limits to help developers understand constraints when registering applications.
Changes:
- Added credential limits (100 total certificates/client secrets, 20 federated credentials) to the service limits page
- Added a dedicated section for the global application property limit (~1000 items) on the validation page for better visibility
- Added extension limits to the validation differences table and updated the service limits row header to include both schema and directory extensions
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.
| File | Description |
|---|---|
| docs/includes/entra-service-limits-include.md | Updated the schema extensions row header to include directory extensions and added new credential limits (100 certificates/secrets, 20 federated credentials) to the Applications row |
| docs/identity-platform/supported-accounts-validation.md | Added new section for global app property limit, updated certificates and client secrets rows with 100 total limit, added new row for directory/schema extensions, and removed footnote about global limit |
| | 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> | | ||
| | Schema extensions and directory 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> | |
There was a problem hiding this comment.
The row header in the service limits table was changed from "Schema extensions" to "Schema extensions and directory extensions". However, the actual limit content in the cell only mentions "extension values" generically without clearly distinguishing between schema extensions and directory extensions. Consider verifying whether the "100 extension values" limit applies to schema extensions alone or to the combined total of both schema extensions and directory extensions. The new row added in the supported-accounts-validation.md file states "Maximum of 100 extensions, regardless of data type" for "Directory extensions and schema extensions", which suggests they share a combined limit, but the service limits page doesn't make this clear.
| | Certificates (`keyCredentials`) | Symmetric signing key <br><br> Maximum of 100 total certificates and client secrets | Symmetric signing key <br><br> Maximum of 100 total certificates and client secrets | Encryption and asymmetric signing key <br><br> Maximum of 100 total certificates and client secrets | | ||
| | Client secrets (`passwordCredentials`) | Maximum of 100 total certificates and client secrets | Maximum of 100 total certificates and client secrets | Maximum of two client secrets, maximum of 100 total certificates and client secrets | |
There was a problem hiding this comment.
The service limits page now includes information about federated credentials limit ("A maximum of 20 federated credentials may be configured on an app"), but this limit is not reflected in the validation differences table in the supported-accounts-validation.md file. For consistency and completeness, consider adding a row for federated credentials to the validation differences table, or add a note about this limit in the existing certificates/client secrets rows if the limit applies uniformly across all account types.
| | 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> | | ||
| | Schema extensions and directory 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>A maximum of 100 total certificates (public keys) or client secrets (passwords) may be configured on an app. A maximum of 20 federated credentials may be configured on an app.</li><li>See additional limits in [Validation differences by supported account types](~/identity-platform/supported-accounts-validation.md).</li></ul> | |
There was a problem hiding this comment.
According to the Microsoft Writing Style Guide, use "might" instead of "may" for possibility. The phrase "may be configured" should be changed to "can be configured" or another appropriate alternative. The word "may" should be reserved for permission. In this context, since we're describing a limit/capability rather than permission, consider using "can be configured" instead.
|
|
||
| ## Global application property limit | ||
|
|
||
| Apps are subject to a global limit of about 1000 items across all the collection properties on the app object. |
There was a problem hiding this comment.
The sentence "Apps are subject to a global limit of about 1000 items across all the collection properties on the app object." has a spacing issue. The number should be formatted as "1,000" (with a comma) for better readability, following standard number formatting conventions.
| Apps are subject to a global limit of about 1000 items across all the collection properties on the app object. | |
| Apps are subject to a global limit of about 1,000 items across all the collection properties on the app object. |
| | Certificates (`keyCredentials`) | Symmetric signing key | Symmetric signing key | Encryption and asymmetric signing key | | ||
| | Client secrets (`passwordCredentials`) | No limit\* | No limit\* | Maximum of two client secrets | | ||
| | Certificates (`keyCredentials`) | Symmetric signing key <br><br> Maximum of 100 total certificates and client secrets | Symmetric signing key <br><br> Maximum of 100 total certificates and client secrets | Encryption and asymmetric signing key <br><br> Maximum of 100 total certificates and client secrets | | ||
| | Client secrets (`passwordCredentials`) | Maximum of 100 total certificates and client secrets | Maximum of 100 total certificates and client secrets | Maximum of two client secrets, maximum of 100 total certificates and client secrets | |
There was a problem hiding this comment.
In the "Client secrets" row for "AzureADandPersonalMicrosoftAccount and PersonalMicrosoftAccount", the limit states "Maximum of two client secrets, maximum of 100 total certificates and client secrets". This creates potential confusion about the actual limit - it could be read as allowing only 2 client secrets OR it could be read as allowing 2 client secrets with an additional constraint of 100 total. The wording should be clarified to indicate whether the "two client secrets" limit is the primary constraint or if it's 100 total with a special restriction. Consider rephrasing to: "Maximum of 100 total certificates and client secrets, with a maximum of 2 client secrets" to make the hierarchy of limits clearer.
