Can you rename or alias tenants in Defender multitenant management?

Reviewed by ContraForce team · Updated 2026-09-04

> Microsoft documents no ability to rename or alias a connected tenant for display in Defender multitenant management. Tenants are added and removed from the settings page and appear under their own directory name. A Tenant name column exists in the multitenant incident queue and device inventory, and is a documented filter and sort field.

What is documented?

Defender multitenant management surfaces the originating tenant rather than letting an operator relabel it. The multitenant incidents queue shows Tenant name and Workspaces columns indicating which tenant an incident came from, and the multitenant device inventory adds a Tenant name column that is documented among the filter and sort fields.

Tenants themselves are added and removed from the settings page. No rename, alias, display-name override, or grouping label appears in the documentation for that page.

The overview page carries an explicit Limitations section, and that section covers workspace and Azure Lighthouse constraints. It does not mention naming, which is worth stating precisely: the absence of an aliasing feature is an absence from the documentation, not a limitation Microsoft has published.

Why does this matter above about twenty tenants?

Directory names are chosen by the customer for the customer's own purposes, not for a provider's console. At small scale that is a curiosity. Past roughly twenty tenants it becomes an operational cost in three places.

• Hunting output. A KQL result grouped by tenant returns whatever each directory calls itself, so a query across eighty customers produces eighty labels that a human has to map back to accounts.
• Content distribution. Choosing which tenants receive a rule means recognising them by directory name in a picker.
• Handover. An analyst new to the account has no way to tell from the console which tenant is which commercial relationship.

How do you get customer-meaningful names in the console?

The constraint is that the console reads the customer's directory name because it has no other name to read. An operating layer that models the customer relationship separately does have one.

ContraForce operates every customer environment from one multitenant control plane where the workspace carries the name you give it, so incident queues, reporting, and content targeting all read the name your team uses for that account rather than the name in the customer's directory.

Sources

• Microsoft Defender multitenant management overview
• Manage tenants in multitenant management
• Multitenant incident queue