Update Entra ID Apps for Teams PowerShell

Microsoft announced a change in August 2025 that is relevant for administrators who use Teams PowerShell in automated processes. Specifically, it affects Entra ID apps that run Teams cmdlets without user login. The goal of this adjustment is clear: to strengthen security and compliance with guidelines for administrative units. For you as an administrator, this means reviewing existing Service Principals and, if necessary, assigning additional permissions so that your automations continue to work.

Background and architecture

The change is based on a new authentication model for app-only access to Teams. Until now, it was sufficient to assign the Teams administrator role to an app. From now on, two additional Microsoft Graph permissions must be present: RoleManagement.Read.Directory and GroupMember.Read.All. These are necessary to maintain the integrity of the administrative units and at the same time to be able to read out group memberships.

Why is this important? Many companies use Azure Automation or other orchestration platforms to regularly review Teams structures or generate reports. These processes run in the background without a user being actively logged in. This is exactly where the app-only model comes into play. Without the new permissions, such scripts will fail in the future because the API calls are no longer authorized.

Concept for implementation

The first step is to identify the affected apps. You’ll need to find out which Service Principals in your tenant have the Teams admin role. This role is an indicator that the app is likely to run Teams cmdlets in app-only mode. The query is made through the Microsoft Graph PowerShell SDK. The role ID for “Teams Administrator” is first determined and then all active assignments are read.

The following PowerShell snippet shows the core of the logic:

$TeamsAdminRole = Get-MgDirectoryRoleTemplate | Where-Object {$_.displayName -eq "Teams administrator"} | Select-Object -ExpandProperty Id

[array]$ActiveAssignments = Get-MgBetaRoleManagementDirectoryRoleAssignmentSchedule -Filter "(RoleDefinitionId eq '$($TeamsAdminRole)')" -ExpandProperty RoleDefinition, Principal, DirectoryScope -All

The results contain the Service Principal IDs that you will need later for authorization assignment. In addition, you can generate a report that contains the display name and the app type in addition to the ID. This way you can keep track of which automations are affected.

Add permissions

After the affected apps have been identified, the actual adjustment follows. You’ll need to add the two new Microsoft Graph app roles to the Service Principals. The graph itself exists as a service principal with the app ID in the tenant. The assignment is done using the New-MgServicePrincipalAppRoleAssignmentcommand .

[array]$Permissions = "RoleManagement.Read.Directory", "GroupMember.Read.All"
$GraphApp = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'"
ForEach ($App in $Apps) {
ForEach ($Permission in $Permissions) {
$Role = $GraphApp.AppRoles | Where-Object {$_.Value -eq $Permission}
$AppRoleAssignment = @{
PrincipalId = $App
ResourceId = $GraphApp.Id
AppRoleId = $Role.Id
}
Try {
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $App -BodyParameter $AppRoleAssignment -ErrorAction Stop
} Catch {
Write-Host ("Fehler beim Zuweisen von {0} an {1}" -f $Permission, $App)
}
}
}

The logic is deliberately designed to be robust: it checks each authorization individually and catches errors so as not to interrupt the process. This ensures that all relevant apps receive the necessary rights.

Security and governance

The introduction of these additional permissions is not an end in itself. It addresses a central problem: the uncontrolled expansion of app rights. By making read rights explicit for roles and groups, Microsoft prevents an app from receiving more information than is necessary for its purpose. For you, this means that you can continue to use your automations without compromising the tenant’s security architecture.

Result

The adaptation is technically manageable, but strategically relevant. You make sure that your automations don’t fail by granting the new permissions. At the same time, you benefit from a clearer separation of rights and improved governance. The effort is minimal: a one-time scan of the service principals and the assignment of two app roles. The benefits, on the other hand, are great, because you avoid failures in productive processes and meet Microsoft’s new security requirements.

Outlook: It is likely that Microsoft will take further steps towards granular permissions for app-only access. For you as an administrator, this means that you should regularly check your scripts and automations for new requirements. Proactive monitoring of Message Center announcements and close integration with the Microsoft Graph SDK are critical to this. Reacting early saves time and avoids operational risks.

External sources