Your Teams phones, panels and room systems stop being managed from the Teams admin center this month. Three conditions decide whether yours make the trip.
Microsoft is retiring the device management workflows in the Teams admin center and consolidating them into the Teams Rooms Pro Management portal. For a healthy device the move is automatic. Two of the three things that stop a device being healthy are things an institution acquires by hardening its tenant.
- The date and the device list in Microsoft's own words
- Which Conditional Access controls Teams devices cannot satisfy, in a table
- The inventory to run before the end of the month, and what it costs to miss
What is actually being retired, and what is not
The retirement itself takes nothing offline. The phone still rings, the panel outside the boardroom still shows the next meeting, and the room system still joins calls. What is being retired is the place you manage them from. Microsoft is consolidating Teams device management out of the Teams admin center and into the Teams Rooms Pro Management portal, so that Teams Rooms on Windows and every Android-based Teams device are administered from one place instead of two.
Microsoft describes the last stage of that consolidation as Phase 4, and names it plainly: decommissioning the overlapping Teams device management features in the Teams admin center, with the remaining workflows retired and the Pro Management portal becoming the primary management portal. The timing is in the article's own frequently asked questions.
"The phased deprecation of the device management features in TAC will start in the September 1st week, 2026 and expect to complete by end of September 2026."
Note what that sentence does and does not say. It gives a month, not a day, and it says expect. Treat the whole of September as the window rather than waiting for a 30 September event, because the workflows are being withdrawn progressively and the first ones went in the opening week.
Four device families move: Teams Rooms on Android, Teams Phones, Teams Panels, and SIP devices. Existing devices appear in the new portal automatically, and Microsoft's guidance is that no manual migration is required.
Teams Displays are the exception, and they are not migrating at all
Microsoft states that the management of Teams Displays will not be moved to the Pro Management portal, and gives the reason: this is in line with the end of support for the Teams Displays app. If you have Displays on desks, this month is not a migration question for them, it is a replacement question, and it belongs in a different conversation from the one on this page.
No, this is not a licensing upsell
The portal is called the Teams Rooms Pro Management portal, which makes the obvious worry that management is moving behind a Pro licence and that anyone on Basic loses it. That is not what Microsoft says, and we checked specifically because it would have been the more dramatic story.
"The current access to PMP is included with Teams Rooms and Teams shared device licensing. Additional guidance to be provided if any licensing scenarios require attention."
The prerequisites are broader still. Access requires the organisation to hold at least one of the following, which is a low bar for anyone who already owns Teams devices:
- At least one Teams Rooms Pro, Teams Rooms Basic, or Teams Rooms Standard licence, or
- At least one Teams Shared Space licence, which Microsoft notes was formerly called Shared devices, or
- At least one Teams device already enrolled in the portal. Microsoft flags this last route as mainly for customers who manage only Teams Phones and hold none of the licences above.
There is a caveat worth reading in Microsoft's own hedge. The sentence says current access and promises additional guidance if any licensing scenarios require attention, which is not the same as a commitment that nothing will ever change. Take the licensing question off tonight's list, and keep it on the list for the next renewal.
The access that does need checking is administrative rather than financial. Reaching the portal takes a Microsoft Entra ID role of Global Administrator, Teams Administrator, Teams Device Administrator or Global Reader, or one of the portal's own roles of Teams Rooms Pro Manager, Site Lead or Site Technician, or a custom role scoped to particular devices and device groups. If the person who has always managed your Teams devices holds a role outside that list, they lose the tool before they lose the devices.
The firmware floor, and the sentence that describes what missing it costs
A Teams Android device is manageable in the new portal only if it is running Admin Agent version AA 830, published as 1.0.0.202606082157.product, or later. Government cloud customers in GCC, GCC-High and DoD need AA 856, published as 1.0.0.202607160723.
Microsoft is not waiting for your update rings to get there. It says it will accelerate deployment of the minimum version so devices are ready as soon as possible, which means the Admin Agent updates arrive at a faster cadence than the schedule you configured. Two consequences follow, and both are stated outright:
- Customers who permanently disabled auto updates will have their devices forcefully auto-updated to the minimum Admin Agent version before the deprecation.
- These updates are, in Microsoft's own capitals, not pausable and are mandatory in order to manage devices in the new portal successfully.
For most institutions that is good news wearing an alarming font. The devices that were going to be fine get dragged to a supported version whether or not anyone remembered. The problem is the devices Microsoft cannot reach, and here the documentation is unusually direct about the consequence.
"After the deprecation, admins will no longer be able to update these devices from TAC and may need to use the OEM portal to update firmware with required Admin Agent before the devices can be managed in PMP again."
Read that as the cost of missing the window. Once the Teams admin center workflows are gone, a device that never got the update cannot be updated from the old portal, because it is retired, and cannot be managed from the new one, because it is below the floor. Note Microsoft's word may, because it is doing real work: how the device recovers depends on how far behind it is. A device already on Admin Agent 794 or later gets there on its own once it is powered on and connected. Only below that does the route run outside Microsoft, through the hardware vendor's own firmware tooling.
Microsoft splits that recovery by how far behind the device is, and the dividing line is Admin Agent 794:
| Device state | What Microsoft says happens | Who has to do something |
|---|---|---|
| Admin Agent 794 or later, powered on and connected | Microsoft's Zero-Day Update mechanism automatically updates the device to the latest eligible Admin Agent version. | Nobody. Power it on and let it reach the network. |
| Admin Agent earlier than 794 | Administrators must first manually update the device to a firmware version obtained from the OEM portal that includes Admin Agent 794 or later. Zero-Day Update takes over after that. | You and your hardware vendor, device by device. |
| Signed out for an extended period | Microsoft cannot automatically onboard the device. An administrator must sign in to the device at least once after it has been updated. | Someone with the credentials, at the device or remotely. |
| Past end of life as a certified device | Microsoft will make the latest Admin Agent available for connectivity, but states that because these are unsupported, manageability has not been tested and may not work as expected. | Plan a replacement rather than a migration. |
The devices most likely to be in the bottom two rows are the ones nobody thinks about: the spare phone in a supply cupboard, the panel outside a branch meeting room that was closed for refurbishment, the room system in the office that moved. They are also, awkwardly, exactly the devices an inventory pulled from a management portal will show as present and healthy right up until the moment somebody needs one.
The new portal talks to devices over its own endpoints
The Pro Management portal reaches devices through a different set of hostnames from the ones the Teams admin center used. If your firewall has never had to allow them, the devices arrive in the new portal in a state Microsoft describes with a specific error, Device is not connected to IoT Hub, and remote actions such as restart and remove are greyed out.
For commercial and GCC customers, Teams Android devices need thirteen hostnames reachable over TCP and UDP port 443. GCC customers need a fourteenth. GCC-High and DoD each have their own separate endpoint on a different top-level domain.
agent.rooms.microsoft.com mmrprodnoamcbiot.azure-devices.net mmrprodemeacbiot.azure-devices.net mmrprodnoamtciot.azure-devices.net mmrprodemeatciot.azure-devices.net mmrprodnoamphonesiot.azure-devices.net mmrprodemeaphonesiot.azure-devices.net mmrprodnoampanelsiot.azure-devices.net mmrprodemeapanelsiot.azure-devices.net mmrprodapaccbiot.azure-devices.net mmrprodapacphonesiot.azure-devices.net mmrprodapactciot.azure-devices.net mmrprodapacpanelsiot.azure-devices.net
The commercial and GCC list as published, over TCP and UDP 443. GCC adds mmrprodgcciot.azure-devices.net; GCC-High uses mmrgcchiot.azure-devices.us and DoD uses mmrdodiot.azure-devices.us. Read from Microsoft Learn on 8 September 2026. Confirm against the live page before you write a firewall rule, because Microsoft adds endpoints as regions come online.
The naming is worth a second look because it tells you the shape of the dependency. The hostnames are region specific across North America, Europe and Asia Pacific, and device class specific within each region, with separate names carrying phones and panels. An allow list that was assembled for room systems can therefore be complete for room systems and silently short for the phones on the desks in the same building.
The sentence that catches banks specifically
Microsoft states plainly that Teams Android devices do not support authenticated proxy servers or tenant restrictions, and directs customers to their hardware vendor for proxy support information. An institution that routes all outbound traffic through an authenticating proxy, which is an ordinary and defensible control, has a device population that cannot use it.
Microsoft's own recommendation points the other way from the instinct to put appliances behind more inspection: it suggests Teams Android devices do not need to reach the internal network at all, and are better placed in a segregated segment with direct internet access, so that a compromised internal network has fewer routes to them.
Two smaller network facts worth recording while you are in the firewall. Teams Android devices use TLS 1.2 or above, so a segment still terminating older TLS is a problem independent of this migration. And Microsoft's guidance is to let real-time Teams media bypass proxies and inspection devices entirely, because the media is already encrypted and the latency cost is paid in call quality.
We will tell you which of your Teams devices will not make the trip, before the end of the month
A read of the Admin Agent version on every device the tenant can see, the Conditional Access policies that apply to your Teams resource accounts, and whether the thirteen endpoints are reachable from the segment the devices sit on. Written up, in your hands, whether or not you engage us for anything after it.
Get a free security assessmentThe controls a hardened tenant enforces are the ones Teams devices cannot satisfy
This is the condition that separates a well-run financial institution from a small business with three conference rooms, and it is the reason this page exists rather than a one-line note.
When a device does not appear or cannot be managed in the new portal, Microsoft's troubleshooting section names three things to check. Two are the conditions above. The third is this:
"Ensure no unsupported conditional access policies are assigned to the Teams Resource Accounts which could prevent authentication."
Which policies are unsupported is documented on a separate page, and it is not a short list. Several entries on it are controls that a mature identity programme has deliberately turned on, because for ordinary user accounts they are the right answer.
| Conditional Access control | Teams Rooms on Windows | Teams Rooms on Android, phones, panels | What Microsoft adds |
|---|---|---|---|
| Require authentication strength | Not supported | Not supported | "Authentication strength including but not limited to, FIDO2 Security keys, isn't supported for use with Conditional Access policies that affect all Teams Devices." |
| Require multifactor authentication | Not supported | Supported | On Android: "To enable seamless sign-on, don't enforce this policy, use a different secondary authentication factor." |
| Require device to be marked as compliant | Supported | Supported | The one device grant that works on both platforms. |
| Require Microsoft Entra hybrid joined device | Not supported | Not supported | A hybrid-join grant applied tenant-wide reaches these accounts and they cannot satisfy it. |
| Sign-in frequency | Not supported | Not supported | "Using the sign-in frequency policy causes devices to periodically sign out and may not be desired." |
| Authentication flows condition | Supported | Not supported | "Don't block device code flow." |
| Customize continuous access evaluation | Not supported | Not supported | "If you check the box, it must be set to Disable or you'll experience instability." |
| Require token protection for sign-in sessions | Not supported | Not supported | Currently a preview control. |
| User risk and sign-in risk conditions | Supported | Supported | Risk conditions do apply, so these accounts are not outside your risk posture. |
Read the first row again, because it is the one that catches the institutions doing the best work. An organisation that has moved its Conditional Access grants from the plain multifactor requirement to authentication strengths, which is the more modern and more precise control and the one Microsoft's own guidance pushes toward, has adopted a grant that Teams devices cannot satisfy on either platform. The same is true of the phishing-resistant direction of travel: the note names FIDO2 security keys specifically.
The underlying reason is in the device security documentation, and it follows from how these devices have to behave rather than from a setting somebody forgot to add:
"You can't use user interactive two-factor or multifactor authentication with this account. Requiring a user interactive second factor would prevent the account from being able to automatically sign into the Teams Rooms app after a reboot."
A room system has to come back on its own after a power cut at two in the morning. Anything that requires a human to be standing in front of it is incompatible with that, by design. The answer is not to weaken the tenant, it is to scope the strong controls to the accounts that can carry them and give the resource accounts a deliberately designed exception that is documented, reviewed, and compensated for with the controls that do work: device compliance, risk conditions, network and location conditions, and a segregated network segment.
ABT's reading, not Microsoft's: the two sentences nobody joins up
Microsoft states in the transition article that a device signed out for an extended period cannot be onboarded automatically, and that an administrator must sign in to the device at least once. Microsoft states on the Conditional Access page that blocking device code flow prevents using the microsoft.com/devicelogin route to sign in a Teams Android device remotely. It never puts those two sentences side by side.
We are putting them side by side. Blocking device code flow is ordinary hardening and generally the right call for user accounts, because device code phishing is a real and current technique. But if it is applied to the Teams resource accounts, and a device has been sitting signed out, the remote half of the only recovery step is gone and somebody is driving to a branch. Scope the block so it does not land on those accounts, or accept the visit.
One more entry on Microsoft's list is worth checking before the end of the month, because it locks out administrators rather than devices. If an administrator is scoped to an administrative unit in Microsoft Entra ID, Microsoft states they will not be able to access the Pro Management portal at all. Institutions that delegate administration by region, charter or subsidiary are the ones who use administrative units. The workaround Microsoft gives is for an administrator with full access to create custom roles inside the portal, which is work that has to happen before the person needs the tool rather than after.
Why an unmanageable phone is not an IT footnote
Four things that carry across differently, and one that carries across too well
Your maintenance window is gone
Microsoft states that all updates in the new portal are carried out in a default nightly maintenance window between midnight and 5 AM device local time, and that administrators cannot set a different window yet. If your change management put device updates in a specific approved window, that window no longer exists for these devices.
Worth telling your change advisory board before it notices on its own.
Update phases become update rings, and they are not the same shape
During the transition period the new portal keeps following the update cadence defined by your old Teams admin center phases, until an administrator explicitly adopts the new rings. Microsoft ties that grace period to the end of September. Phones that are not yet on the minimum Admin Agent version move to the default General ring regardless of which phase they used to be in.
The old behaviour is borrowed, not inherited. Rebuild the rings deliberately.
Tags become Groups, and they stop meaning the same thing
Microsoft is explicit about the semantic change: tags in the Teams admin center are associated with the account signed in to the device, whereas groups in the new portal are associated directly with the device. Importing a tag creates a group containing the devices signed in with the accounts that tag covered.
If you tag by branch or by department, check the import produced the membership you expected rather than the membership the sign-ins produced.
Configuration profiles have to be imported, not assumed
Existing configuration profiles can be carried over as settings templates in the new portal, and existing tags can be carried over as groups, but both are import actions somebody has to perform. Neither is described as automatic in the way the device inventory is.
The devices arrive on their own. The configuration does not.
A pause you set last year carries across perfectly, which is the problem
Microsoft states that customers who have updates disabled or paused in the Teams admin center continue to have them disabled or paused in the new portal. A pause put in place for a good reason during a past incident, and never lifted, migrates intact and invisibly into a portal where nobody remembers setting it.
This is the one to look for first, because it is the one that will not announce itself.
The inventory to run before the end of September
- Open the Pro Management portal and compare the count. Public and GCC customers use portal.rooms.microsoft.com. Every device enrolled in the Teams admin center should appear automatically. The number that matters is not how many are listed, it is how many are missing against what you believe you own, and the answer is usually a supply cupboard.
- Find anything showing the IoT Hub error. A device reporting that it is not connected to IoT Hub, or with restart and remove greyed out, is telling you it failed one of the three conditions. Microsoft's own order for chasing it is network first, then Admin Agent version, then Conditional Access.
- Check the Admin Agent version on every device against AA 830, or AA 856 in a government cloud. Anything below 794 is the expensive category and needs OEM firmware, so find those now rather than in October.
- Power on and sign in to everything that is currently off or signed out. This is the cheapest item on the list and the one that expires. A device that is on, connected, and signed in before the deprecation gets updated automatically; the same device found in November may need a vendor.
- Confirm the thirteen endpoints are reachable from the network segment the devices actually sit on, over TCP and UDP 443, and check whether an authenticating proxy sits in that path. Confirm the phone and panel hostnames specifically, not just the room-system ones.
- List every Conditional Access policy that applies to your Teams resource accounts and compare its grants against the unsupported table above. Authentication strength, sign-in frequency, hybrid join and blocked device code flow are the four to look for first.
- Check whether your Teams device administrators are scoped to an administrative unit, and if they are, have somebody with full access create the portal custom roles now.
- Look for a paused or disabled update setting in the Teams admin center and decide, deliberately, whether it should follow you into the new portal. It will follow you either way.
- Separate the Teams Displays. They are not migrating and they are not covered by any of the above. Whatever the answer is for them, it is a different answer.
What a clean result looks like
Every device you own is visible in the new portal, none is showing the IoT Hub error, every Admin Agent version is at or above the floor, no Conditional Access policy applying to the resource accounts uses a control from the unsupported list, and the administrator who looks after all of this can actually open the portal. That is a finished job, and for most institutions it is genuinely reachable this month.
We run the inventory against your tenant and hand back the answer in writing
The free security assessment covers the three conditions on this page, run against your environment rather than described to you. We report the Admin Agent version on every Teams device the tenant can see, against the minimum, which devices are visible and manageable in the Pro Management portal and which are not, whether the Pro Management portal endpoints are reachable from the segment your devices sit on, and every Conditional Access policy that applies to your Teams resource accounts with its grant controls named against the unsupported list. Where an exception is needed for those accounts, we set out what it should be scoped to and what compensating controls belong beside it.
Two honest limits. It is a technical review rather than legal or compliance advice. And firmware recovery through a hardware vendor's own portal needs that vendor's tooling and your relationship with them, so where a device is below Admin Agent 794 we identify it and tell you what it needs, rather than claiming we can fix it from here.
The written output is yours whether or not you engage us for anything afterwards. ABT manages Microsoft 365 tenants and hosts Azure environments for more than 750 financial institutions, so Conditional Access in a regulated setting is the environment we work in daily rather than an occasional project. ABT also operates M365 Guardian, its managed security service for credit unions, banks, and mortgage companies.
Where the facts on this page come from
The three questions behind this one
Microsoft Teams Licensing for Financial Institutions (2026 Guide)
What the Teams Rooms and shared device licences actually cover, which is the ground the portal access question on this page sits on.
Read the article ›
Conditional Access Policies for Financial Institutions: 2026 Best Practices
The policy set an institution should have in place. Read it next to the unsupported table above, because the overlap is the whole of condition three.
Read the article ›
Lock It Down: Risk-Based Device Compliance with Microsoft Intune
Device compliance is the one device grant Teams devices do support on both platforms, which makes it the centre of any exception you design for them.
Read the article ›Answered from Microsoft's own documentation
No. What is being retired is the management workflow in the Teams admin center, not the devices. Calls still connect, panels still show meetings, and phones still ring. Microsoft's wording is that the phased deprecation of the device management features in the Teams admin center will start in the September 1st week, 2026 and is expected to complete by end of September 2026, with the Pro Management portal becoming the primary management portal. The risk is not that a device stops working on a date, it is that a device you can no longer manage stops working later and you have lost the tool to fix it.
Microsoft says no, and for a healthy device that is accurate. Devices enrolled in the Teams admin center appear in the Pro Management portal automatically. The three conditions are what decide whether a given device counts as healthy: it must be on Admin Agent version AA 830 or later, the Pro Management portal endpoints must be reachable from its network, and no unsupported Conditional Access policy may be blocking the resource account from authenticating. Configuration is a different matter from inventory. Existing configuration profiles and tags carry over as settings templates and groups, but both are import actions somebody has to perform.
No. Microsoft states that current access to the portal is included with Teams Rooms and Teams shared device licensing. The published prerequisite is that the organisation holds at least one Teams Rooms Pro, Teams Rooms Basic or Teams Rooms Standard licence, or at least one Teams Shared Space licence, formerly called Shared devices, or simply has at least one Teams device already enrolled in the portal, which Microsoft notes is mainly relevant to customers managing only Teams Phones. Read Microsoft's own hedge alongside that: it says current access, and promises additional guidance if any licensing scenarios require attention. It is not a question for this month, and it is worth raising at your next renewal.
Microsoft lists require authentication strength, require Microsoft Entra hybrid joined device, sign-in frequency, customized continuous access evaluation and require token protection for sign-in sessions as not supported on both Teams Rooms on Windows and Teams Rooms on Android, phones and panels. On Android the authentication flows condition is also unsupported, with the instruction not to block device code flow. Require multifactor authentication is not supported on Windows and is supported on Android, though Microsoft advises against enforcing it there to preserve seamless sign-on. Require device to be marked as compliant is supported on both, and user risk and sign-in risk conditions are supported on both. The note attached to authentication strength is the one to read twice: authentication strength, including but not limited to FIDO2 security keys, is not supported for use with Conditional Access policies that affect all Teams devices.
No, and that is the wrong shape of fix. The controls stay where they belong, on the accounts that can carry them, and the Teams resource accounts get a deliberately designed exception that is documented, reviewed on a cadence, and compensated for. The reason the exception is necessary is structural rather than a gap awaiting a fix: Microsoft states that a resource account cannot use user interactive two-factor or multifactor authentication, because requiring an interactive second factor would prevent the account from signing in automatically after a reboot. A room system has to recover on its own after a power cut. The compensating controls that do work on these accounts are device compliance, user risk and sign-in risk conditions, network and location conditions, and putting the devices in a segregated network segment, which is also Microsoft's own recommendation.
AA 830, published as 1.0.0.202606082157.product, for commercial customers, and AA 856, published as 1.0.0.202607160723, for GCC, GCC-High and DoD. Microsoft is accelerating the rollout of that version ahead of your own update rings and states that these updates are not pausable and are mandatory, and that customers who permanently disabled auto updates will have devices forcefully auto-updated. If a device misses the window, Microsoft's own sentence describes the cost: after the deprecation, admins will no longer be able to update these devices from the Teams admin center and may need to use the OEM portal to update firmware with the required Admin Agent before the devices can be managed in the Pro Management portal again. Devices already on Admin Agent 794 or later recover on their own once powered on and connected, via Microsoft's Zero-Day Update mechanism. Devices below 794 need a manual firmware update from the hardware vendor first.
Teams Android devices need thirteen hostnames reachable over TCP and UDP port 443 for the Pro Management portal, being agent.rooms.microsoft.com plus twelve azure-devices.net names that are specific to both region and device class, with separate names for phones and panels. GCC customers need a fourteenth, and GCC-High and DoD each have their own endpoint on the azure-devices.us domain. The proxy question matters a great deal: Microsoft states that Teams Android devices do not support authenticated proxy servers or tenant restrictions, and refers customers to their hardware vendor for proxy support information. Microsoft's own network recommendation is that these devices do not need to reach the internal network at all and are better placed in a segregated segment with direct internet access.
They are not migrating. Microsoft states that management of Teams Displays will not be moved from the Teams admin center to the Pro Management portal, and gives the reason as being in line with the end of support for the Teams Displays app. Every other Android-based Teams device family moves, so Displays are the single exception. Treat them as a replacement decision rather than a migration task, and confirm the current end-of-support date on Microsoft's own Teams Displays page before you plan against a specific quarter, because this page does not carry that date.
Yes, and it is easy to miss because it locks out people rather than devices. Microsoft states that an administrator scoped to an administrative unit in Microsoft Entra ID will not be able to access the Pro Management portal. Institutions that delegate administration by region, charter or subsidiary are exactly the ones that use administrative units, so this lands disproportionately on multi-charter and multi-branch organisations. The workaround Microsoft gives is for an administrator with full access to create custom roles inside the portal, which can be scoped to specific devices and device groups. That work has to happen before somebody needs the tool rather than after.
Partly, and the differences are worth knowing before somebody discovers them. Updates in the Pro Management portal run in a default nightly maintenance window between midnight and 5 AM device local time, and Microsoft states that administrators cannot set a different window yet, so a bespoke change window does not survive. During the transition the new portal follows the cadence defined by your old Teams admin center update phases until an administrator explicitly adopts the new rings, and Microsoft ties that grace period to the end of September. Phones below the minimum Admin Agent version move to the default General ring regardless of their previous phase. Tags can be imported as groups, but they change meaning: tags were associated with the account signed in to the device, whereas groups are associated directly with the device. And a pause carries across perfectly, which is the one to check, because updates disabled or paused in the Teams admin center stay disabled or paused in the new portal.
Find out which of your Teams devices will not make the trip.
Tell us roughly how many users you have and whether you have Teams phones, panels or room systems in branches. Our engineers read the tenant and come back in writing on the scope set out above: the Admin Agent version on every device the tenant can see, against the minimum, which devices the Pro Management portal can and cannot manage, whether the portal endpoints are reachable from the segment your devices sit on, and every Conditional Access policy applying to your Teams resource accounts with its grants named against Microsoft's unsupported list. Confirming what is physically installed in which branch needs your records too, and we name exactly which ones to pull.
ABT manages Microsoft 365 tenants and hosts Azure environments for more than 750 financial institutions. The assessment is a technical review and is not legal or compliance advice.
Get a free security assessment
A read of your Teams device fleet and the Conditional Access policies around it, with a written answer while the old portal is still there to check against.
