Microsoft Teams RBAC: All 8 Admin Roles Explained
Role-based access control in Microsoft Teams runs on Microsoft Entra ID, split into 8 Teams-specific admin roles rather than one all-or-nothing switch. Getting this right means matching each admin’s job to the narrowest role that covers it, not defaulting to Global Administrator.
Quick answer: Microsoft Entra ID has 8 Teams-specific admin roles, from full Teams Administrator down to read-only Teams Reader and narrow roles like Teams Devices Administrator. Assign the narrowest role that covers the job, keep your Global Administrator count under five, and use Privileged Identity Management (PIM) for anything that only needs time-bound elevation.
What RBAC actually means in Microsoft Teams
It’s worth separating two things that get conflated constantly: tenant-level admin roles and per-team owner/member roles.
The 8 roles covered here are Entra ID directory roles. They control who can administer the Teams service (policies, devices, telephony, tenant-wide settings) from the Teams admin center or PowerShell, across the whole tenant.
Team owner and member roles are a different, narrower layer: a team owner can add or remove members, change a team’s settings, or manage channels within that one team, with no admin-center access at all. When troubleshooting “who can do what,” check which layer you’re in first, because the two don’t overlap.
The 8 Microsoft Teams admin roles
According to the Microsoft Entra built-in roles reference, there are 8 Teams-specific roles in Entra ID: Teams Administrator, Teams Communications Administrator, Teams Communications Support Engineer, Teams Communications Support Specialist, Teams Devices Administrator, Teams External Collaboration Administrator, Teams Reader, and Teams Telephony Administrator.
One naming quirk: the Entra role reference calls role 5 “Teams Devices Administrator” (plural), while the Teams admin roles documentation writes “Teams Device Administrator” (singular). Same role, inconsistent docs. That same page also documents only 7 of the 8 roles: it doesn’t yet cover Teams External Collaboration Administrator, which currently lives only in the Entra role reference.
| Role | What it manages | Where it’s managed | Notable limit |
|---|---|---|---|
| Teams Administrator | Full Teams service: meetings, voice, messaging policies, org-wide/federation settings, devices, troubleshooting, all reports, CQD, app catalog publishing | Teams admin center + PowerShell | Resource account creation also needs User Administrator |
| Teams Communications Administrator | Calling and meeting features: policies, voice, phone number assignment, resource accounts, call-quality troubleshooting, CQD | Teams admin center + PowerShell | Resource account creation also needs User Administrator |
| Teams Communications Support Engineer | Advanced call-quality troubleshooting, CQD down to affected users | Call Analytics / CQD | Troubleshooting only, no configuration control |
| Teams Communications Support Specialist | Basic call troubleshooting in Call Analytics | Call Analytics | Can only view the specific user being searched for |
| Teams Devices Administrator | Device configuration, updates, health status, profiles, restarts | Teams admin center (Devices) | No call quality or analytics access; needs Communications Administrator |
| Teams External Collaboration Administrator | External collaboration policies: external domains, which groups/users can interact with the org | Entra ID | New role (below), not yet in the Teams admin roles page |
| Teams Reader | Read-only view of the Teams admin center | Teams admin center | Cannot view Teams management, Meetings & Calls details, Notifications & Rules, Frontline deployment, or the insights dashboard |
| Teams Telephony Administrator | Voice/telephony: calling policies, phone numbers, voice apps, resource accounts, PSTN reports, support tickets | Teams admin center + PowerShell | Some voice tasks need the admin to hold a Teams license |
Which role should you actually assign?
Work backward from the task, not from seniority:
- Whole Teams service, including federation and org-wide settings → Teams Administrator.
- Only calling and meeting policies, no devices or reporting → Teams Communications Administrator.
- Deep call-quality troubleshooting for a support team → Teams Communications Support Engineer.
- Front-line support looking up one user’s call history at a time → Teams Communications Support Specialist.
- Teams-certified devices and meeting room hardware, nothing else → Teams Devices Administrator (no call-quality visibility).
- External domains and which orgs can collaborate with your tenant → Teams External Collaboration Administrator.
- Auditors or anyone who just needs visibility → Teams Reader.
- Phone numbers and PSTN reporting → Teams Telephony Administrator.
If none of the 8 fits cleanly, don’t default to Global Administrator — check whether a custom role scoped to an administrative unit fits better.
The new Teams External Collaboration Administrator role
Teams External Collaboration Administrator is the newest addition to this list. Microsoft announced it in message center notification MC1215071 on January 8, 2026, with a rollout stated for late January 2026, per Tony Redmond’s write-up on Office365itpros.com. Its Entra description: it manages “external collaboration policies and settings for Teams, including configuring external domains and controlling which groups and users can interact with the organization.”
Redmond is skeptical most tenants need a dedicated role for this:
“The point is that a small set of roles is enough to segregate administrative tasks for many Microsoft 365 tenants.”
His view: changing external collaboration settings isn’t onerous enough to justify its own delegated admin for most organizations. It fits “very large enterprise tenants with big administrative staffs and clearly delineated areas of responsibility” more than typical mid-sized ones.
How to assign a Teams admin role
Click path: entra.microsoft.com → Entra ID → Roles & admins → All roles, select the role, open Assignments, then Add assignments. Unsure which role fits? The Service filter on that list narrows Entra’s 65+ built-in roles down to the ones relevant to Teams.
For scripted assignment, the current supported path is the Microsoft Graph PowerShell SDK and its New-MgDirectoryRoleMemberByRef cmdlet:
Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory"
New-MgDirectoryRoleMemberByRef `
-DirectoryRoleId "<role-id>" `
-BodyParameter @{ "@odata.id" = "https://graph.microsoft.com/v1.0/directoryObjects/<user-id>" }Teams-specific cmdlets live in the Teams module; run Get-Command -Module MicrosoftTeams to see what’s available for policy work alongside role assignment.
Migration warning if you’re working from older scripts: the AzureAD and MSOnline PowerShell modules are retired — deprecated since March 30, 2024, out of support since March 30, 2025. Runbooks calling Connect-AzureAD or Get-MsolUser are historical references now, not commands to keep running. Move that automation to the Microsoft Graph PowerShell SDK, or the Microsoft Entra PowerShell module.
Assigning roles to groups instead of people
You can assign a Teams admin role to a group instead of managing assignments one by one, but the group has to be built correctly from day one.
A role-assignable group requires Microsoft Entra ID P1, and must be created as a new security or Microsoft 365 group with “Microsoft Entra roles can be assigned to the group” set to Yes at creation. That setting, isAssignableToRole, is immutable: you can’t convert an existing group afterward.
The part that matters most: membership type must be Assigned; dynamic membership groups are not supported for role assignment. Microsoft’s reason: automated population could add an unwanted account, which would then inherit the role automatically. If an old process hands out admin roles by job title via dynamic rules, that’s a security gap to close.
Related escalation risk: anyone who can manage a group’s dynamic membership elsewhere could indirectly add themselves to a role assigned to that group. Microsoft’s example: a group assigned User Administrator, where an Exchange administrator able to modify dynamic membership groups could add themselves and become a User Administrator without ever being directly assigned it.
Other constraints: at most 500 role-assignable groups per tenant, creating one needs Privileged Role Administrator, managing membership via Graph needs RoleManagement.ReadWrite.Directory (Group.ReadWrite.All won’t work), and nesting isn’t supported. Full detail in Microsoft’s role-assignable groups documentation.
Just-in-time access with PIM
Standing privileged access is a bigger attack surface than it needs to be for roles used only occasionally. PIM makes a role assignment eligible instead of permanent: someone activates it, for a defined window, when they need it. It requires Entra ID P2 or Microsoft Entra ID Governance.
Setup path: Entra admin center → Identity Governance → Privileged Identity Management → Microsoft Entra roles → Roles, select the role, Add assignments, set as Eligible or Active, with start and end dates.
If an admin needs several eligible roles, activating each individually gets tedious. PIM for Groups solves that: create a group, grant it permanent access to the roles needed, then make the admin an eligible member. One activation covers everything the group is linked to.
Keeping Global Admin counts down
Microsoft recommends fewer than five Global Administrators, since the role has essentially unrestricted access. An alert appears on the Entra ID Overview page past that threshold. Keep privileged role assignments overall under 10 too, since Entra warns above that count and labels privileged roles PRIVILEGED. Also keep two cloud-only “break glass” accounts permanently assigned Global Administrator, not tied to any individual, so you’re never locked out of your own tenant.
The practical way to hit “fewer than five” is delegation: push well-scoped work to one of the 8 Teams roles above, or a custom role, instead of defaulting to Global Administrator out of habit. Product-level RBAC can help too — nBold, for example, layers its own delegated roles (End-User, Catalog Manager, Integration Manager, Teams Service Admin, Global Admin) alongside Entra roles rather than replacing them, so routine work like authoring workspace templates, configuring integrations, or bulk workspace maintenance doesn’t require tenant-wide Global Admin. Every action still runs through the Microsoft Graph API under permissions the tenant controls.
MFA belongs in the same conversation. Amy Hogan-Burney, Microsoft’s Corporate VP for Customer Security & Trust, said when announcing the Microsoft Digital Defense Report 2025 that “MFA can block over 99% of identity-based attacks.” The same report notes more than 97% of identity attacks are password attacks, and attacks surged 32% in the first half of 2025, which is exactly the target privileged accounts represent. Separately, Microsoft’s Entra role best-practices guidance still cites an older figure, from an earlier study: MFA makes an account 99.9% less likely to be compromised. Different source, same direction.
Also use cloud-native accounts for Entra role assignments, not on-premises synced ones, because a compromised synced account can reach Entra-managed resources too.
Layered controls beyond roles
Roles alone aren’t the whole access-control story. Microsoft’s Entra best-practices guidance lays out a layered model that combines several controls, each suited to a different problem:
| Control | What it does | When to use it |
|---|---|---|
| Administrative units | Scope a role to a subset of users, groups, or devices | Delegate to regional/departmental admins without tenant-wide access |
| Custom roles | Define exactly the permissions a job needs | Built-in roles too broad or too narrow |
| PIM | Just-in-time, time-bound, approval-based activation | Eliminate standing privileged access |
| Conditional Access | Evaluate real-time signals: risk, device, location, app | Context-based access decisions |
| Entitlement management | Bundle resources into access packages with approval/expiration | Govern access at scale |
| Continuous Access Evaluation (CAE) | Re-evaluate access mid-session on critical events or policy changes | Enforce changes in near-real-time, not at token expiry |
| Custom security attributes (Azure ABAC) | Tag principals and gate access by attribute condition | Currently Azure Blob/Queue Storage data actions |
Microsoft’s worked example: a custom role scoped to an administrative unit so a regional helpdesk admin can only reset passwords in their region, PIM activation so it’s time-bound and approval-based, Conditional Access requiring a compliant device and MFA at activation, and access reviews to confirm the admin still needs it. Custom roles and Conditional Access require Entra ID P1, as do administrative units for admins scoped to one. PIM requires Entra ID P2 or Microsoft Entra ID Governance, while entitlement management and access reviews require Entra ID Governance or the Microsoft Entra Suite.
Review sensitivity labels and the Microsoft 365 Groups they attach to alongside your role structure — access control and data classification should be designed together.
Monitoring and access reviews
Auditing now lives in the Microsoft Purview portal at purview.microsoft.com, under the Audit card — the older Security & Compliance Center naming is retired. It’s on by default for standard Microsoft 365 licenses, but not for SMB licenses (Business Basic, Standard, Premium), free trials, or unmanaged enterprise tenants. Check explicitly with Exchange Online PowerShell:
Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabledTurning it on late means losing visibility into everything before activation, so confirm it during initial tenant setup, not after an incident.
Beyond logging, run periodic access reviews on role assignments. Microsoft gives two reasons this matters: an account can be compromised, and people move teams within a company, amassing unnecessary access over time if nobody audits it. Access reviews require Microsoft Entra ID Governance or the Microsoft Entra Suite.
FAQ
What are the Microsoft Teams admin roles? Microsoft Entra ID has 8 Teams-specific admin roles: Teams Administrator, Teams Communications Administrator, Teams Communications Support Engineer, Teams Communications Support Specialist, Teams Devices Administrator, Teams External Collaboration Administrator, Teams Reader, and Teams Telephony Administrator. Each covers a different slice of the Teams service, from full administration down to read-only access or narrow tasks like device management or external collaboration settings.
What’s the difference between Teams Communications Support Engineer and Support Specialist? Both troubleshoot calling and meeting issues, but with different tool access. The Support Engineer gets the advanced troubleshooting toolset and Call Quality Dashboard access down to the specific users affected by poor call quality. The Support Specialist gets only basic tools and, in Call Analytics, can view user information only for the specific user being searched for.
Can I assign Teams admin roles to a group instead of individual users? Yes, using a role-assignable group, which requires Microsoft Entra ID P1. The group must be created as role-assignable from the start, since that setting is immutable and can’t be added later. Membership type must be Assigned. Dynamic membership groups aren’t supported for role assignment, because automated membership changes could add an unintended account to a privileged role.
How many Global Administrators should we have? Microsoft recommends fewer than five Global Administrators, since the role has essentially unrestricted access across the tenant. Beyond five active assignments, Entra ID shows a warning on the Overview page. Microsoft also recommends keeping two cloud-only emergency access accounts permanently assigned Global Administrator, not tied to any one person, in case normal admin access is unavailable.
Do I need a license for Privileged Identity Management? Yes. Privileged Identity Management requires Microsoft Entra ID P2 or Microsoft Entra ID Governance. PIM lets you make role assignments eligible rather than permanent, so admins activate a role only when they need it, for a limited time, instead of holding standing privileged access around the clock.
Summary
Eight roles cover the Teams-specific admin surface in Entra ID, and picking the right one for each job, rather than reaching for Global Administrator by default, is most of what “doing RBAC well” means here. Layer in role-assignable groups built correctly (Assigned membership, never dynamic), PIM for anything that doesn’t need standing access, administrative units and Conditional Access where a built-in role is too blunt, and regular access reviews so unused permissions don’t quietly accumulate. None of it is complicated; it just needs to be applied consistently as your tenant grows.