Stop identifying users by display name 

Stop identifying users by display name 

Many identity environments still rely on display name or email address as primary identifiers in automation logic. It is common. It is convenient. And it is a structural mistake. 

If lifecycle workflows depend on displayName, mail, or userPrincipalName as core targeting attributes, automation is being built on presentation, communication, or sign-in data — not on structural identity data. Microsoft defines displayName as the name displayed in the address book, mail as the user’s SMTP address, and userPrincipalName as the internet-style login name for the user.  

That approach worked within limited boundaries. It does not scale in modern identity governance and lifecycle automation environments. Microsoft explicitly recommends that developers use the user objectID as the immutable identifier rather than UPN or email addresses. 

This is not a minor technical nuance. It is an architectural decision. 

The illusion of stability 

Display names feel unique. 

They are not. 

Two people can share the same name. Names change. HR corrects spelling. Local formats differ between countries. Consultants are reclassified. Formatting standards evolve. displayName is a presentation attribute — the value shown in the address book — not a structural identity anchor. 

Email addresses feel stable. 

They are not. 

Domains migrate. UPN formats change. Aliases are added. Companies merge. External users follow different naming patterns. Cloud migrations expose inconsistencies. Microsoft documents mail as the user’s SMTP address, which is a communication attribute, and also notes that some organizations use mail as an alternate login ID because users know their email address better than their UPN. 

Display name and email are presentation and communication attributes. 

They were not designed to function as lifecycle anchors. 

When automation relies on them, governance becomes dependent on data that was never meant to carry structural meaning. 

What breaks when the wrong attributes are used 

In isolation, using display name or email may appear harmless. 

At scale, it becomes operational risk. 

When lifecycle workflows depend on weak identifiers, organizations can introduce: 

• incorrect onboarding 
• missed offboarding 
• broken provisioning flows 
• misaligned access assignments 
• difficult-to-diagnose automation failures 
• compliance exposure 

Modern identity environments are ecosystems: 

• HR systems 
• provisioning engines 
• SaaS integrations 
• access governance platforms 
• Conditional Access policies 
• cross-tenant collaboration 

Microsoft’s guidance on automating identity lifecycle management makes clear that HR systems often act as the source of authority, and that changes in employee records can automatically update user accounts in Active Directory and Microsoft Entra ID. In that kind of environment, weak identifiers do not fail in isolation — they propagate through connected systems. 

Automation does not always fail loudly. It often fails quietly — and repeatedly — when its assumptions are wrong. 

Why it seemed to work 

It is common to hear that attributes like email address or userPrincipalName “have always worked.” 

In reality, they were designed with specific scope and purpose. 

In traditional Active Directory environments, userPrincipalName was intended to be unique within a forest. Microsoft states that a UPN must be unique among security principal objects within a directory forest. That uniqueness worked well inside a defined boundary. 

But uniqueness is not the same as immutability. 

Microsoft also documents multiple reasons why UPN values change, including employee name change, employee move, restructuring that affects the suffix, merger and acquisition changes, and UPN prefix or suffix changes. 

It was unique at a given moment within a given forest. It was never designed to be a permanent, cross-system identity anchor over time. 

Another pattern emerged alongside this: operational meaning was added directly into presentation attributes. 

Administrative accounts were labeled by modifying userPrincipalName or displayName: 

This made accounts visually distinguishable, but it blurred the boundary between identity and role. 

A role is not an identity. 

When administrative context is embedded into attributes meant for presentation or communication, automation begins to rely on string patterns rather than structural properties. 

That approach does not scale. 

It also introduces unnecessary security exposure. Encoding privileged status into visible attributes makes high-value accounts easier to identify. Privileged access is better governed through role assignments, group membership, and policy controls than through naming conventions. 

Identity should describe who the account belongs to. 
Authorization should describe what the account can do. 

Blending the two weakens both governance and security posture. 

As organizations expanded beyond a single forest, consolidated domains, or synchronized identities to Entra ID, those design limitations became visible: 

• duplicate usernames had to be corrected 
• some accounts required renaming 
• domain changes created conflicts 
• cleanup efforts revealed inconsistent data 

These were not new weaknesses. They were the natural result of using attributes beyond the scope they were designed for. 

The question is not whether these attributes worked within a forest. 

The question is whether they are structurally suitable for enterprise-scale lifecycle automation. 

Mature lifecycle automation is built on: 

• immutable system identifiers, such as Object ID or source-anchor-style identifiers  
• authoritative HR identifiers, where available 
• structured attributes such as employeeType or companyName 
• purpose-built extension attributes for governance targeting, where needed 

Instead of building logic like: 

If mail ends with company.com 

build logic like: 

employeeType equals External 
AND companyName equals Vendor Managed Services 
AND accountEnabled equals true 

That logic is explicit. Auditable. Deterministic. 

Executives may not care about attribute names — but they should care about predictability. 

Predictability reduces operational risk. 

Identity vs. presentation 

A useful model separates identity into layers: 

System identity 
– Object ID 
– immutable identifiers  

Business identity 
– Employee ID 
– HR system ID 

Communication 
– Email address 

Presentation 
– Display name 

Lifecycle workflows should operate on system identity and business identity layers. 

Not on communication and presentation layers. 

When those layers are mixed, governance becomes fragile. 

Closing thoughts 

Using display name or email address as the foundation for lifecycle automation is not just a technical shortcut. It is a design decision. 

And design decisions scale. 

In smaller environments, weak identifiers can survive because humans compensate. Someone notices the mismatch. Someone corrects the access. Someone fixes the naming conflict. 

Automation removes that safety net. 

It executes exactly what it is told to execute. 

If lifecycle workflows depend on attributes that were never meant to serve as structural identity anchors, that is not governance. It is the automation of assumptions. 

The difference between immature and mature identity governance is not how many workflows exist. 

It is the quality and intentionality of the data those workflows depend on. 

Before adding more automation, ask a simpler question: 

Are lifecycle workflows built on presentation data — or on structural identity? 

Automation will faithfully amplify whichever foundation is chosen. 

Author: Sandra Saluti, Identity consultant at Epical