Choosing the Right Extension Type in Microsoft Entra
- Sebastian F. Markdanner
- 6 minutes ago
- 8 min read
I’ve been seeing a lot of discussions about the different extension types available across Microsoft Entra objects, and I have a few thoughts on the subject that I want to share with y’all.
Being able to extend the built-in attributes and data model in Microsoft Entra provides a flexible way to handle information across our organizations for monitoring, automation, and governance.
With that said, I don’t believe the 15 predefined extension attributes are the best route to take in the vast majority of cases.
Let’s talk about it!
Table of Content
The Extension Types in Microsoft Entra
Microsoft Entra provides several different extension types, including:
Extension Attributes
Directory Extensions
Schema Extensions
Open Extensions
In addition to these, there are also Custom Security Attributes, which function somewhat like an extension type, though not quite in the same way. I’ll save those for a future post.
The 4 custom extension types in Microsoft Entra at a glance
Extension Attributes are the simplest and most limited.
Directory Extensions are best suited for custom identity attributes in Entra.
Schema Extensions are best when you need structure and strongly typed data.
Open Extensions are best for flexible application metadata, but offer the weakest governance model.
Extension type | Main purpose | Best used for | Strengths | Limitations / watch-outs |
|---|---|---|---|---|
Extension Attributes | Store simple custom values using the built-in extensionAttribute1–15 fields. | Basic user/device metadata such as employee category, migration status, sync flags, or classifications. |
|
|
Directory Extensions | Add custom attributes directly to Microsoft Entra directory objects. Identity-focused extensions | Tenant-specific identity attributes on users, groups, devices, applications, or other directory objects. |
|
|
Schema Extensions | Define a named schema with strongly typed custom properties for supported Microsoft Graph resources. Reusable, non-identity-focused extensions | Allows applications to define structured data models within Microsoft Graph for storing application metadata |
|
|
Open Extensions | Attach flexible, untyped custom data to a Microsoft Graph resource. | Lightweight app-specific metadata where strict schema enforcement is not needed. |
|
|
Let’s take a closer look at each extension type.
Extension Attributes
While onPremisesExtensionAttributes were originally only populated from AD DS and Exchange on-premises and then synchronized to Microsoft Entra, their capabilities have expanded over time. Today, they can also be managed directly through Microsoft Graph for cloud-only users and devices.
Extension Attributes consist of 15 predefined fields that can be used to store custom string values on users and devices.
These are by far the extension type I see most people using and, in many cases, the only one they’re familiar with.
The biggest challenge with Extension Attributes is that they’re very easy to overwrite and often difficult to monitor. Many SaaS solutions use some of these attributes as part of their default deployment or require data to be stored in a specific attribute. This can easily create conflicts when multiple systems rely on the same fields for different business purposes.
While they’re simple to use, they’re also quite limited. They only support string values, have fixed names, are only available on user and device objects, and are restricted to 15 attributes in total.
Recommended use cases: Leveraging on-premises data, Exchange attributes, Purview adaptive protection scenarios, Conditional Access device filters, or displaying custom information in the Microsoft 365 profile card.
Directory Extensions
This is where it gets fun.
Directory Extensions work as add-ons to your environment through applications, allowing you to store custom, multi-value data across a wide range of objects.
They’re also identity- and policy-aware within Microsoft Entra, which means they can be used throughout the platform in features such as dynamic groups, provisioning, and more.
The easiest way to think about Directory Extensions is this:
It’s just another Entra attribute.
Directory Extensions extend an application’s schema with strongly typed, fully customizable attributes. Unlike Extension Attributes, they don’t use fixed names. Instead, they follow this naming convention:
extension_<appGUID>_<CustomAttributeName>This means you get to define the attribute names yourself, making them much easier to identify and manage at a glance.
For example:
extension_abcdef1234567890_EmployeeID
extension_abcdef1234567890_CostCenter
extension_abcdef1234567890_JobCode
extension_abcdef1234567890_ManagerID
extension_abcdef1234567890_Region
extension_abcdef1234567890_JobFamily
(...)There is currently no hard limit on the number of Directory Extensions that can be added to a single application registration. However, there is a limit of 100 extension values on a single object, meaning each user, device, group, and other supported object can have up to 100 extension attributes assigned.
Another major advantage of Directory Extensions is the range of supported object types:
user
group
administrativeUnit
application
device
organization
Directory Extensions are tied to an “owner” application, which can be either single-tenant or multi-tenant. If a multi-tenant application contains Directory Extensions in its schema, those extensions become available to any organization that grants consent to the application.
One downside of both Directory Extensions and Schema Extensions is that they aren’t visible or manageable through the portal. Management is currently limited to Microsoft Graph, which can become a challenge in environments with poor documentation, inherited configurations, or for MSPs managing a large number of tenants.
Stay tuned, I’ve got something coming in the next post that might help with exactly that.
Recommended use cases: Adding custom, identity-aware data to Entra objects for automations, workflows, and integrations with features such as dynamic groups, administrative units, identity governance, access reviews, automated license assignment, authentication flows, and custom claims.
In other words: almost anything Entra.
Schema Extensions
At first glance, Schema Extensions look very similar to Directory Extensions. However, there are some important differences in both their behavior and intended use cases.
Unlike Directory Extensions, Schema Extensions are not identity- or policy-aware. As a result, they can’t be used with Entra features such as dynamic groups, provisioning, or other identity-driven capabilities.
The easiest way to think about Schema Extensions is this:
A defined object that can be attached to other objects by extending the Microsoft Graph data model.
This allows developers to create structured, reusable data models for their applications and store related properties within a single schema extension. That’s one of the biggest advantages Schema Extensions have over the other extension types.
Schema Extensions can be used across a wide range of objects:
user
group
administrativeUnit
application
device
organization
message
event
post
Because Schema Extensions and Directory Extensions are so similar, many people struggle to understand when to use one over the other. That’s completely understandable, as they share many of the same characteristics:
Require an application registration to act as the owner
Use Microsoft Graph
Support many of the same resource types
Store custom data
That said, there are several important differences beyond what we’ve already covered. One of the biggest is the Schema Extension lifecycle.
Schema Extension Lifecycle
When a developer creates a Schema Extension, it starts in the InDevelopment state. During this phase, the extension is only available to applications within the owner application’s tenant.
Once published, the extension moves to the Available state. At this point, it becomes available to applications in any tenant because it has been published directly into the Microsoft Entra schema.
Finally, a Schema Extension can be retired using the Deprecated state.
These lifecycle stages introduce an additional layer of management that doesn’t exist with Directory Extensions.
With those differences in mind, the distinction between Directory Extensions and Schema Extensions becomes much clearer:
Directory Extensions – A single attribute extending the identity model:
user.<property>Schema Extensions – A structured object extending the data model:
user.<object>.<property>Recommended use cases: Reusable, structured objects that extend Microsoft Graph resources without requiring identity awareness. Common examples include customer data for multi-tenant applications, application-specific metadata, and logically grouped data sets.
Open Extensions
Open Extensions are a bit different from the other extension types. They’re unstructured, scoped to individual objects, non-filterable, and not strongly typed.
In short, Open Extensions allow you to attach a JSON blob directly to an object with very little setup and without modifying the schema.
The easiest way to think about Open Extensions is that they’re designed to store application- and object-specific data close to where it’s used. For example, a user’s language preference or favorite color—information that doesn’t need to participate in identity, security, governance, or provisioning scenarios and isn’t intended to be reused elsewhere.
At first glance, Open Extensions might seem a bit pointless. However, they serve a valuable purpose when you need agility over structure, don’t control the entire data model, or simply want loosely coupled metadata without requiring Entra to understand the contents.
A good example would be storing session-specific data in a support system.
A helpdesk engineer might receive a ticket that requires temporary access to a resource. In that scenario, an Open Extension could be attached to the session or related object for auditing, tracking, or integration purposes:
{
"supportContext": {
"ticketId": "INC123456",
"priority": "High",
"sessionStart": "2026-06-14T12:00:00Z"
}
}Like the other extension types, Open Extensions support a variety of resource types.
In fact, they support the broadest set of resources, which makes sense given that they’re simply attaching application-defined JSON data to an object.
Supported resources include:
user
group
administrativeUnit
application
device
organization
message
event
post
todoTask
todoTaskList
Recommended use cases: Storing user preferences and other non-reusable application data directly on Microsoft Graph objects, such as language preferences, time format settings, location preferences, favorite colors, or other metadata that Microsoft Entra doesn’t need to understand.
Microsoft Entra Custom Extensions Decision Tree
Now that we’ve gone through the different extension types, what they do, and where they fit, here’s a simple decision tree to help you figure out which one to use:
Conclusion
Microsoft Entra provides several ways to extend directory objects, and while all of them solve the same fundamental problem, storing custom data, they are designed for very different scenarios.
Extension Attributes remain useful for simple and often legacy-driven use cases, especially in hybrid environments. However, their limited number of fields, lack of structure, and frequent conflicts with third-party solutions make them a poor default choice for modern Entra implementations.
For most identity-driven scenarios, Directory Extensions should be the first option considered. They behave like native Entra attributes, integrate with identity features across the platform, and provide the flexibility needed for automation, governance, provisioning, and policy-based decisions.
Schema Extensions are ideal when applications need a reusable and structured data model that can be shared across Microsoft Graph resources, while Open Extensions provide a lightweight option for storing application-specific metadata without introducing schema complexity.
The key takeaway is simple: don’t choose an extension type because it’s the one you’re familiar with. Choose it based on how the data will be consumed, governed, and maintained over time. In most organizations, taking a few minutes to select the right extension type upfront can prevent years of technical debt later.
Now that we know what they are, and where we should use them, the next question is how - that'll be tackled in the next blog post so stay tuned, and until then stay safe and tinkering!