By DavidLundell October 1, 2025
This article is the sixth in a series about Custom Attributes in Entra ID and will discuss the Limitations of each these approaches.
- Names and aliases
- Naming Conventions
- Resource Types
- Data Types
- Lifecycle
- Limitations
- Use Cases
- Decision Tree
Limitation | Extension attributes | Directory Extensions | Schema Extensions | Open Extensions | Custom Security Attributes |
Needs an App to own it | N | Y | Y | N but an App must create it | N |
Values Per Resource | 15 | 100 | 100 | 2 kb of data | 50 |
Per App | N/A | 5 definitions | 2 extensions | N/A | |
Per Tenant | 15 | Infinte | Infinte | Infinte | 500 |
Schema can be shared | Built in to every tenant | If other tenants install your mult-tenant app | Discoverable Globally | N | N |
Can exist on Synced User | Y | Y | Y | Y | Y |
Must Manage on Prem for Synced User | Y | N* | N | N | N |
*No, except for Directory extensions from the “Tenant Schema Extension App” used by Entra ID Connect Sync and Cloud Sync.
The most distinguishing limit is how many extensions/custom attributes each method can have. The Extension Attributes can only have 15 string attributes per resource and only on users and devices. While these Extension Attributes have a lot of use cases in the next post we will see that there are some use cases that only Extension Attributes can do. The use cases that can only use Extension Attributes combined with only 15 attributes makes these handy attributes a very valuable resource and not be littered with inconsistent garbage as we often see in on-prem AD.
Custom Security Attributes can only have 500 attribute definitions whereas the other three (Open, Directory and Schema) can have infinite definitions. On the plus side deactivated definitions do not count against the limit. Further, Custom Security Attributes can only have 50 attribute values populated per resource (this means a resource having 50 single-valued attributes populated, one particular multi-valued custom security attribute having 50 values or some combination thereof). This limitation and its unique use case can also make this a method to use wisely.
Directory Extensions and Schema Extensions are both limited to 100 values populated per resource.
Open Extensions can only have two extensions per creator app. Open Extensions have a data size limit per resource rather than a limit in the number of attributes but this also differs depending on the resource type. On directory resources (user, group, device and organization) the limit is 2 Kb of data.
Open Extensions on Outlook resources are stored in a MAPI Named Property. This imposes different restrictions on Outlook resources in a user’s mailbox (message, event, and contact) than for Open Extensions on directory objects. The documentation just says that these “are a limited resources in a user’s mailbox.".
The linked documents on MAPI Named Properties don’t explain this, at least not to my satisfaction. I find discussion about property identifiers ranges. The range for Named Properties goes from 0x8000 to 0xFFFE, allowing for 32,767 Named Properties. I also found a reference to increasing MAPI property limits in on-prem Exchange Server which seems to have had a default limit of 8192, which could be changed in the registry.
One final important distinction has to do with users that are synced from on-prem AD. For users synced from on-prem AD you must manage the Extension Attributes in the on-prem AD, the same is true for a limited set of Directory Extensions – the ones from the “Tenant Schema Extension App” used by Entra ID Connect Sync and Cloud Sync.