Whenever I review a Microsoft 365 tenant, the meeting room devices turn out to be the biggest gap in identity security. Teams Rooms resource accounts usually run on passwords that haven’t changed in years. They sit in groups excluded from MFA and are left out of Conditional Access policies because 'the device might get locked out'. I’m regularly surprised how often these accounts get overlooked, even in environments that are otherwise tightly locked down. Yet a compromised room account can lead to lateral movement, calendar scraping, email abuse and more. Securing Teams Rooms identities is now both possible and practical, thanks to dedicated Conditional Access policies, Intune compliance and solid update management.
Teams Rooms identities carry unusual risks
Teams Rooms security starts with understanding what makes meeting room identities different. They aren’t shared mailboxes or service accounts with limited rights. In many cases they are full user objects that sign into physical devices and access calendars, Teams and sometimes even email. The typical setup is one account per room with a non-expiring password (often not rotated in ages), excluded from the tenant’s MFA baseline for fear of accidental lockout. Nobody pays much attention to these accounts, but the risk is real. They come with remote access, rich calendar data, delegated mailbox rights and sometimes over-permissioned roles. If an attacker takes control, the blast radius is much bigger than most admins realise.
Room accounts need their own Conditional Access policy
If you care about Teams Rooms security, you can’t treat these accounts as second-class citizens without running into trouble. In every project I set up dedicated Conditional Access policies for room accounts, kept separate from the user policies. They allow sign-ins only from compliant Teams Rooms devices, from known trusted locations (like your office networks), or both. I manage all room accounts in a dynamic group and scope the policy to the members of that group only. The policy grants access only if the device is compliant (Intune-enrolled with up-to-date checks) or the sign-in comes from a trusted network location. MFA is deliberately not enabled for these accounts, but other controls such as sign-in risk-based blocking and audit logging still apply. The diagram below shows the flow:
flowchart TD
Login["Room account sign-in"] --> CA["Conditional Access policy (room accounts)"]
CA -->|"Compliant device or trusted location?"| Allow["Access allowed"]
CA -->|"Not compliant / wrong location"| Block["Access blocked"]
Figure: Conditional Access checks whether a room account signs in from a compliant device or a trusted location.
For the current details, check the Teams Rooms security documentation and the list of supported policies. In my experience, device compliance signals from Intune are by far the most reliable way to protect these accounts. Network location on its own is rarely strong enough.
Intune compliance works well for Teams Rooms on Windows
Many admins still don’t realise that modern Teams Rooms on Windows can be fully managed with Intune. All you need is Entra ID join (formerly Azure AD join) and Teams Rooms Pro licensing. Most deployments now automate Intune enrollment at deployment time. After enrollment you can apply compliance policies (BitLocker, secure boot, update status) and monitor device health and inventory. Once Intune is running properly, Conditional Access behaves as expected in my projects, and only compliant, healthy Teams Rooms devices get access.
Pro Tip: Put all Teams Rooms devices in a dedicated Intune device group and build targeted compliance policies for them. That way they don’t clash with your standard desktop policies.
A mistake I see often is that admins join the device to Entra ID but skip or misconfigure Intune enrollment, so compliance signals never reach Conditional Access. Before you rely on the access policy, check the compliance status of each room device in the Intune admin center.
The Teams admin center and the Pro Management Portal keep devices patched
Regular software and firmware patching is another core part of Teams Rooms security. The Teams admin center (under 'Teams devices') is the best place to monitor Teams Rooms devices for pending updates, push firmware or app upgrades and check health status. For larger estates, the Teams Rooms Pro Management Portal (available with the Teams Rooms Pro licence) is a big improvement. It adds deep monitoring, maintenance workflows and cross-device insights. That becomes essential as environments grow, especially with mixed hardware generations and several physical sites.
One issue keeps coming up. Admins keep the Teams app current but neglect device firmware and peripheral patches, which leaves cameras, hubs or touch panels exposed. The Pro portal makes it easier to spot outdated firmware and compatibility gaps before they turn into security holes.
Password and licence hygiene still matters
Passwords are no longer the front line for room accounts, but bad habits still cause problems. My rule is to generate strong, documented passwords and rotate them at least once a year, ideally automated. Better still, use managed identities or service principals where the device supports it. And never give room accounts permissions beyond what they actually need.
Teams Rooms Pro is still the licence you need. Without it you lose more than features, because you also lose support for Conditional Access and Intune integration. Assign the licence to the room account itself, not to an admin or a shared pool.
# PowerShell 7, Microsoft Graph module: add room accounts to a group
# Prerequisites: group exists, account object IDs known
Add-MgGroupMember -GroupId <GroupId> -DirectoryObjectId <RoomAccountObjectId>
I now treat meeting room accounts as a first-class security priority
If you’re still ignoring Teams Rooms security, now is the time to change that. Treat room identities like real users. Give them dedicated Conditional Access, check device compliance, rotate credentials and audit their rights. The old idea that 'room devices are special cases' no longer holds. In project after project, the small extra effort of applying a policy here has paid off, and a few times it stopped a compromise before it began. Don’t let your next incident start in the conference room. Nobody wants to be the one explaining that.


