In real projects I keep running into the same request in Entra ID tenants. Teams want to tag service principals or users with more detail than the default fields allow. Custom security attributes finally give them that flexibility. You define your own attribute sets and then assign attributes directly to users, service principals or even groups. With the right roles and processes behind it, the feature is very useful for Conditional Access, for Azure Storage ABAC and for classifying apps so governance and compliance get easier. Planning carefully at the start, particularly around delegation and lifecycle, pays off quickly in my experience.

Attribute sets give your custom metadata a clear structure

You always start in the Microsoft Entra admin center under Protection → Custom security attributes. There you create one or more attribute sets, which are logical collections for attributes that belong together, such as “AppClassification”. Each set holds the actual attributes, for instance “Sensitivity” or “DataOwner”. The model borrows from the claims-based tradition in IAM, but it was built specifically for security, policy and automation scenarios.

You assign values on the target object (user, service principal, group, etc.). The portal works for one object at a time, but scripts or the API are far more practical. Be aware that these attributes are strictly access-controlled by default. Even Global Administrators need explicit assignment roles to read or write them, and Microsoft made that choice deliberately with zero trust in mind. The technical details and step-by-step guides are in Microsoft’s documentation: overview of custom security attributes and adding attributes.

Two dedicated roles control definition and assignment

To manage and assign custom security attributes you work with two special roles. The Attribute Definition Administrator defines sets and fields, and the Attribute Assignment Administrator assigns attribute values to objects. Without them you get a “permission denied”, even as a Global Admin. I keep the assignment role as tightly scoped as I can and delegate it only to specific teams and automations. Assignments can be limited per attribute set. That means you can hand “AppClassification” to your application team, for example, without letting them tag users. In large environments where responsibilities are split, this helps a lot.

From what I’ve seen, this separation is what prevents accidental or overly broad assignments. Service principals used for automation need these roles as well, so include your CI/CD jobs and admin scripts when you plan permissions.

Conditional Access and Azure ABAC can target objects by attribute

Conditional Access is where attributes have the biggest effect. The "Filter for applications" condition (described in Microsoft’s documentation) lets you target policies at apps based on their custom security attributes. You could require strict MFA only for apps tagged "Sensitivity: High", or restrict certain locations for apps marked "InternalOnly". This requires Entra ID P1. It can replace complicated group-based logic, particularly when your app onboarding or review process updates the attributes automatically.

If you work with Azure Storage and Blobs, take a look at the Azure ABAC (attribute-based access control) integration too. Access rules can now reference user or service principal attributes directly, which simplifies permissions and keeps groups from multiplying when data access gets complicated.

The Mermaid diagram below shows how attribute sets, definitions and assignments relate to the admin roles. It follows the same model you see in the Entra portal:

flowchart TD
  Set["Attribute set"] --> Def["Attribute definition"]
  Def --> Obj["Target object (user/app)"]
  Admin["Assignment admin"] --> Obj
  AdminDef["Definition admin"] --> Set

Figure: How attribute sets, definitions, assignment and roles relate

Attributes earn their keep in app classification, audit and process

More and more often I see custom security attributes used to classify apps by sensitivity, compliance status or business owner. The context then lives on the object itself rather than in a spreadsheet, or worse, nowhere. Organizations that are starting with Microsoft 365 Copilot or tightening application governance really need this, mainly to spot shadow IT and to make sure only reviewed apps can reach sensitive data. For larger numbers of apps or users I usually automate attribute updates with Microsoft Graph PowerShell instead of clicking through the portal.

Attribute changes are recorded in their own category in the Entra ID audit log, so you can easily see who changed what and when. For compliance that audit trail is a real plus, and auditors pick up on it quickly.

Field tip: Before you roll out Conditional Access policies that rely on custom security attributes, test them with the What If tool and in Report-Only mode first (I covered that in this post). That catches most logic errors before they reach production.

If you’re trying out Conditional Access App Control or browser session controls, you can combine attribute-based app targeting with those policies as well. I describe the setup here: managing browser sessions with Conditional Access App Control.

I now treat these small fields as a core part of tenant design

What began as a modest metadata feature has turned into a central building block for identity security and governance in Entra ID. Because definition, assignment and auditing are clearly separated, the model stays secure, scales well and remains transparent. Environments with many apps, sensitive data or split admin responsibilities get the most out of it. I now plan custom security attributes into every new tenant design, especially when Conditional Access needs to stay dynamic and hold up as the environment grows.