Entra ID: No reliable way to distinguish human vs non-human accounts in Dynamic User group rules

In Microsoft Entra ID, there is currently no reliable or supported way to distinguish human user accounts from non-human accounts (e.g. meeting rooms, training rooms, shared/system users, test accounts) when building Dynamic User group membership rules.

All of these objects are represented as user objects and often share identical properties such as:

• userType = Member

accountEnabled = true

• No consistent mailbox or license indicators

No “account purpose” or “identity classification” attribute

This forces administrators to rely on naming heuristics rather than authoritative identity signals.

What seems to be missing

There is no first-class attribute such as:

• user.isHuman
• user.accountPurpose
• user.identityClassification
• user.objectSubtype

Even a simple enum like:

Human

Non-Human

Resource

Test / System

would dramatically improve:

• Dynamic group accuracy
• Governance
• Conditional Access targeting
• Admin experience

Why this is a real operational problem

Dynamic groups are commonly used for:

Conditional Access targeting

Application access

Licensing

Security group membership

However, Entra dynamic rules cannot evaluate:

Mailbox type (Room, Equipment, Shared)

License presence

Sign-in activity

Resource account flags

Regex or advanced pattern matching

Custom “isHuman” style attributes

As a result, admins must exclude accounts using fragile logic such as:

• displayName contains "Training Room"
• userPrincipalName contains "room"

mail starts with "-"

These approaches are:

• Error-prone
• Tenant-specific
• Not future-proof
• Hard to explain to auditors and governance teams

Question / request

Is Microsoft considering:

Adding a native attribute to distinguish human vs non-human users?

Extending dynamic membership rules to evaluate mailbox/resource account types?

Providing official guidance or best practices beyond naming conventions?

At the moment, identity admins are forced to solve a classification problem using string matching, which feels like a fundamental gap in Entra ID.

Why this matters

This isn’t just a convenience issue — it impacts:

Security posture

Compliance

Least-privilege access

Identity lifecycle automation

Any guidance or roadmap insight would be greatly appreciated.