Consider Using User and Group Assignments for All Tenant-Created Applications

Following up the conversation about deactivating Entra ID applications, it’s worth noting that another method exists to limit the set of people who can use applications. That method is to assign users (or groups) to applications. When assignments are present, only those with assignments can use an application. It’s a good way to secure access to applications like the Microsoft Graph Command Line Tools application used to run interactive Microsoft Graph PowerShell SDK sessions.

Like deactivation, limiting the set of users with access to an application through assignments is a good way to prevent unauthorized use of an application. In the case of suspicious applications that you don’t recognize, creating a set of authorized users will stop malicious use because it’s highly unlikely that an attacker will have assigned access. Controlling access like this should be a checklist item for many of the applications created within tenants. It doesn’t hurt and can stop abuse.

Microsoft documentation explains how to make user and group assignments and doesn’t need to be repeated here. However, the documentation references “an enterprise application” when it discusses assignments. This is possibly done because the Entra admin center manages user and group assignments through the Enterprise applications section. It would be clearer if the documentation said service principal, which exist for both app registrations created by a tenant and multi-tenant applications created by Microsoft and other third parties. User and group assignments can be created for both app registrations and multi-tenant applications.

Adding User and Group Assignments

Take the example of the IdPowerToys application. Figure 1 shows that two users have assignments to use the application. As the note in the Entra admin center says, because these users have assignments, Entra ID automatically includes the application in the set shown in the My Apps screen.

Adding user and group assignments is easily done through the Entra admin center and can be assigned to either individual users or groups (including dynamic groups). There’s no need to add assignments through PowerShell unless you want to control the process programmatically.

The example below shows how to add a user assignment with the New-MgUserAppRoleAssignment cmdlet. In this case, we use the default role (a GUID with all zeros) to grant access. Custom app roles can be created to support granular levels of access, but the default app role is all that is needed to restrict access to an application.

Connect-MgGraph "Application.ReadWrite.All"

$SP = Get-MgServicePrincipal -Filter "displayName eq 'idPowerToys'"
$UserId = (Get-MgUser -UserId Lotte.Vetler@office365itpros.com).Id
$AppRoleId = '00000000-0000-0000-0000-000000000000'
$Params = @{
   "PrincipalId" = $UserId
   "ResourceId" = $SP.Id
   "AppRoleId" = $AppRoleId
}
Try {
   $Status = New-MgUserAppRoleAssignment -UserId $UserId -BodyParameter $Params -ErrorAction Stop
   Write-Host ("Assignment successful for {0} to {1}" -f $SP.displayName, $Status.PrincipalDisplayName)
} Catch {
   Write-Host ("Error adding assignment for {0}" -f $SP.displayName)
}

Adding Group Assignments

Adding individual user assignments is an effective way to grant access to specific people. However, group assignments are more scalable and easier to manage when large numbers of people need access to an application. Group assignments require Entra P1 or P2 licenses.

To make a group assignment, fetch the group identifier and use it in the request body. The assignment is then made by running the New-MgGroupAppRoleAssignment cmdlet:

$GroupId = (Get-MgGroup -Filter "displayname eq 'IT Department Ireland (Dynamic)'").Id
$Params = @{
   "PrincipalId" = $GroupId
   "ResourceId" = $SP.Id
   "AppRoleId" = $AppRoleId
}
New-MgGroupAppRoleAssignment -GroupId $GroupId -BodyParameter $Params

The Get-MgServicePrincipalAppRoleAssignedTo cmdlet retrieves the assignees for an application:

[array]$Assignees = Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $SP.Id
$Assignees | Format-Table CreatedDateTime, PrincipalDisplayName, AppRoleId

CreatedDateTime     PrincipalDisplayName            AppRoleId
---------------     --------------------            ---------
14/03/2023 23:07:08 Tony Redmond                    00000000-0000-0000-0000-000000000000
17/11/2023 17:16:09 Lotte Vetler (Paris)            00000000-0000-0000-0000-000000000000
17/02/2026 15:01:51 IT Department Ireland (Dynamic) 00000000-0000-0000-0000-000000000000
17/02/2026 14:56:07 Group Creation Control          00000000-0000-0000-0000-000000000000

To remove a user or group assignment, select the assignment and run the Remove-MgServicePrincipalAppRoleAssignedTo cmdlet. For example, to remove the last assignment from the set captured in the $Assignees array (see above):

Remove-MgServicePrincipalAppRoleAssignedTo -AppRoleAssignmentId  $Assignees[-1].Id -ServicePrincipalId $SP.Id

Hiding Applications from MyApps

As mentioned above, when a user receives an assignment, Entra ID surfaces the app in the user’s My Apps screen (Figure 2) if the app is a “non-first-party Microsoft Enterprise Application.” In many cases, it doesn’t make sense to highlight apps in the My Apps screen. For example, apps used to run PowerShell scripts based on the Microsoft Graph PowerShell SDK in app-only mode usually cannot be run from My Apps.

The solution is to amend the application properties by adding a tag to instruct Entra ID to hide the app from My Apps. This won’t stop users signing into apps, but it will stop the My Apps screen becoming cluttered with apps that probably shouldn’t be there. To add the tag, fetch the set of existing tags from the service principal and add the HideApp tag if it’s not already there.

[array]$Tags = $SP.Tags
If ("HideApp" -notin $Tags) {
  $Tags += "HideApp"
  Update-MgServicePrincipal -ServicePrincipalId $SP.Id -Tags $Tags
}

$Tags
WindowsAzureActiveDirectoryIntegratedApp
HideApp

Once the HideApp tag is present for an application, Entra ID won’t include that application in the set it shows in My Apps.

Tenant Guidelines for User and Group Assignments

While it’s nice to have free and easy access to applications, the current state of threat and the way that attackers use Entra applications means that control is necessary. It’s a good idea for tenants to set guidelines for when applications should have user and group assignments. If you don’t control access to all applications, a good case can be made that any application with a high-profile Graph permission like Sites.FullControl.All or Mail.Send should be protected by user and group assignments. Better safe than sorry.

Learn about managing Entra ID apps and the rest of the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s important and how best to protect your tenant.

Flex Routing Handles Situations When Excessive Demands for Copilot Processing Exists

If you manage a Microsoft 365 tenant in the European Union or European Free Trade Association (EU/EFTA), you need to pay attention to message center post MC1269223. On April 17, 2026, Microsoft is enabling a new feature called “flex routing” for Microsoft 365 Copilot. Depending on your organization’s data residency requirements, you may need to take action quickly.

European Data Privacy Is Different

In general, European law (including sector-specific regulations like NIS2 and DORA, not to mention GDPR) restricts how data belonging to European organizations may move or be processed outside of the EU. To comply with these laws, Microsoft provides what they call the EU Data Boundary, which guarantees organizations that their data will stay within the EU.

Compliance with these laws and rules isn’t optional, so customers, quite rightly, demand it from their cloud providers. Microsoft has a generally good track record in this regard, with clear statements of where they process data versus where they store it at rest like this page.

What Is Flex Routing?

Flex routing is a new capability that allows Microsoft to process Copilot LLM inferencing workloads outside the EU Data Boundary during periods of peak demand. The idea is straightforward: when too many people are hammering Copilot at once and EU-based GPU capacity runs short, Microsoft can route requests from EU-based tenants to data centers in the United States, Canada, or Australia to maintain a consistent user experience.

“Inferencing” here means the step where the large language model actually processes your prompt and generates a response. By the time inferencing happens, the prompt has already been through preprocessing, safety checks, and retrieval-augmented generation (RAG). That means your organizational data — emails, files, metadata, and system prompts — is bundled together and sent to the model. When flex routing kicks in, that entire package can be processed outside the EU.

Microsoft emphasizes that data remains encrypted in transit and at rest, and that data at rest continues to be stored inside the EU Data Boundary. However, “limited pseudonymized data” may be stored outside the boundary for security and operational purposes.

Flex Routing Is a Potential Problem

For organizations subject to GDPR, sector-specific regulations, or internal data governance policies that require EU-only processing, flex routing represents a meaningful change. Microsoft is being transparent about it — but “transparent” and “compliant with your organization’s policies” are two different things.

The real issue for many administrators is the default state. Flex routing is enabled by default for new tenants created after 25 March 2026, and for everyone else, it will default to “on” starting on 17 April 2026. Microsoft expects administrators to check the setting and decide whether it’s appropriate for their organization.

Then Again, Maybe Not?

The first question, of course, is whether or not flex routing is even necessary given the extremely low adoption of Microsoft 365 Copilot. Are Copilot loads routinely exceeding capacity? Let’s not get into that question just now.

Instead, keep in mind that flex routing only applies to tenants with a sign-up location in the EU or EFTA. If you’re outside those regions, you won’t see the setting. If you’ve purchased Multi-Geo capabilities, the flex routing setting won’t appear even if your tenant is in the EU or EFTA.

What Should Administrators Do?

First, check your current flex routing setting. Here’s how:

1. Sign in to the Microsoft 365 admin center with an account that has the AI Administrator role.
2. Navigate to Copilot > Settings > Flexible inferencing during peak load periods. (Figure 2)
3. You’ll see two options: Allow flex routing during periods of peak load or Do not allow flex routing.

If you select “Do not allow flex routing,” all LLM inferencing will stay inside the EU Data Boundary even during peak demand periods. Microsoft’s standard data processing and data residency commitments continue to apply regardless of which option you choose — the difference is where the GPU crunching happens during busy periods.

Note that Microsoft 365 admin center setting covers Microsoft 365 Copilot and Copilot Chat. There’s a separate setting in the Power Platform admin center for Copilot experiences in Dynamics 365, Power Platform, and Copilot Studio, but it honors the M365 admin center setting unless the Power Platform setting is more restrictive.

The Bigger Picture

This isn’t the only recent change that EU administrators should be watching. Microsoft also enabled Anthropic models by default for most commercial tenants starting in January 2026 — though EU, EFTA, and UK tenants have Anthropic disabled by default because Anthropic-processed data falls outside Microsoft’s EU Data Boundary commitments.

Taken together, these changes represent something more than a pair of new toggles in the admin center. They represent further evidence that Microsoft is continuing its trajectory of pushing updates that have a significant compliance or privacy impact without consulting its enterprise customers. In this case, those customers didn’t even get much notice. For years, EU organizations could reasonably assume that Microsoft’s defaults were conservative — that if a feature had data residency implications, it would ship as opt-in, not opt-out. That assumption no longer holds.

When your cloud provider starts enabling features by default that move data outside regulatory boundaries, the compliance burden shifts from “trust your vendor’s defaults” to “audit every change your vendor makes.” In practice, that means every Message Center post represents a potential compliance problem. Organizations that treat the Message Center as an IT operations feed need to start treating it as a compliance feed, too — and that’s a big change in how much work it takes to stay on the right side of the regulations.

Log into the admin center, check your flex routing and Anthropic model settings, and make a deliberate decision about each one. If your organization has a data protection officer or legal team that cares about data residency, loop them in. The settings are easy to change — but only if you know they exist. The bigger challenge is building a process that catches the next one before it’s too late.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365. Only humans contribute to our work!