How to Choose a Workplace Device Management Platform: 6 Questions to Ask
A workplace device management platform is the software that enrolls, configures, updates, monitors and supports shared workplace devices such as room panels, desk signs, displays and status lights. This guide is for IT, facilities and workplace teams choosing one for devices spread across several buildings or sites.
Judge any platform on six areas you can test before you buy, and ask each vendor to show the answer on a real device, not on a data sheet:
- Enrollment: how a device gets from the box to managed.
- Updates: who controls them, and how you stage and recover from them.
- Monitoring: what tells you a device is wrong before people notice.
- Configuration and access: how changes scale, and who is allowed to make them.
- Network and data: what the devices need from your network and do with your data.
- Integrations and support: how the devices stay accurate, and who answers when they don't.
Each section explains why the area matters, what a good answer looks like and which answers need a follow-up. After the six questions you'll find a way to compare three year costs, a pilot test worth running and a checklist for recording what each vendor proved, what they only claimed and what you still need to test.
A workplace platform is not a replacement for general device management. Tools such as Microsoft Intune cover enrollment, compliance and policy, but shared workplace devices also have settings those tools often don't reach, such as room mapping, calendar connections and what the screen shows. Many teams run both.
The questions apply whether devices run Windows, Android, Microsoft's Device Ecosystem Platform (MDEP) or a vendor's own software. The examples come from Microsoft's published documentation for Teams Rooms and Teams Android devices because it is detailed and public. They show the kind of answer to look for, not requirements every workplace device must meet. The security questions follow NIST IR 8259A, a baseline of device cybersecurity capabilities rather than a certification. If MDEP is on your list, Microsoft describes it as an enterprise platform built on the Android Open Source Project with Microsoft Intune and Microsoft Entra ID management built in, says available capabilities vary by device, and notes that customers remain responsible for identity, access, network, application, compliance and lifecycle policies. For a plain explanation, read What Is Microsoft MDEP?
1. How do devices get from the box to managed?
Why it matters. A pilot of twenty devices can be set up by hand. Two thousand need a repeatable process, and provisioning also fixes each device's identity: its room or desk, its account and its group. Getting that wrong at enrollment shows up later as devices in the wrong group or showing the wrong room. Microsoft's room devices show the hidden work: each Teams Rooms device needs its own resource account, so enrolling at scale also means creating and naming accounts in bulk.
A good answer
- On-site steps (mounting, power, network) are separated from console steps (identity, desk or room mapping, configuration), and the console steps are shown done remotely and in bulk.
- Every device has a unique identity, and the vendor can say where it comes from. NIST lists unique logical and physical identifiers first.
- Default credentials are handled. For Teams Rooms and Teams Android devices, Microsoft tells administrators to change default local admin passwords; ask any vendor how its devices handle them.
- A replacement unit can take over the old unit's identity and settings without a full rebuild.
Red flags
- No bulk path. Manual setup can be fine for a pilot. Ask how long each device takes at your full count, and who does the work.
- Shared default admin passwords. Ask how local admin access is set, changed or disabled across the fleet, and ask to see it.
- A pilot only the vendor's engineers can run. Ask which steps your own team will do after rollout, and have them do those steps in the pilot.
2. Who controls updates, and how do you stage and recover from them?
Why it matters. Updates close vulnerabilities, and a bad one can also break a whole fleet at once. You want them in waves, at a version you have tested, with a known way back if something fails. Microsoft's Teams Rooms Pro Management portal, for example, rolls updates out through rings (Staging, General and Executive by default) and lets administrators pause, retry or force an update. Responsibility can also be split. On MDEP devices, Microsoft provides monthly platform updates while each device maker validates and delivers updates for its own hardware, so ask who ships what.
A good answer
- The vendor says who ships operating system, firmware and application updates, and how each is controlled.
- Rings or groups with a pilot wave, the ability to pause, and updates the device verifies before installing.
- A documented recovery process for a failed update, including rollback where it is supported and appropriate. NIST treats rollback as a capability some organizations want and others prefer to rule out, because restoring an older version can reintroduce vulnerabilities the update fixed. Ask who can roll back, when the vendor recommends it and how quickly a corrected version follows.
- Per device version and status, with failures raised as alerts, and a published support period for each version.
Red flags
- No way to stage or pause. If every device updates on the same night, ask how the vendor limits the impact of a bad release and how fast it can stop one.
- No version record. Ask to see which version each device runs, and what happens to a device that has spent a year in a box before it's installed.
3. What can you see, and what tells you before users do?
Why it matters. A panel showing the wrong room status does more harm than a dark one, because people trust it. A device can be online and still show stale or incorrect information, so monitoring has to go past online or offline. Microsoft's portal, for example, opens an incident automatically when a room device's update fails, and supports remote restart and log collection.
Two kinds of monitoring matter, and they are different requirements. Operational monitoring tells you whether the device is doing its job: connected to the calendar or booking system, showing current content, responding to people. Cybersecurity state awareness, one of NIST's six capabilities, is the device's ability to report its cybersecurity state to authorized people only, so you can tell when it may no longer be operating securely. Ask for evidence of both.
A good answer
- An inventory with model, firmware, application version and last seen time.
- Operational health signals that cover calendar or booking connectivity and whether what's on screen is current, not just whether the device responds.
- Security state reporting the vendor can show: how the device tells authorized administrators that it may no longer be in a secure state.
- Alerts that reach email, a ticketing system or a security tool. Microsoft's portal, for example, can send incidents to ServiceNow or to other tools through a webhook.
- An action history, remote restart and log collection, and exportable data or an API.
Red flags
- Online or offline is the only signal. Ask how the platform detects a device that is online but showing stale or wrong information, and ask to see that alert.
- Alerts that only appear in the console. Ask how an alert reaches the person on call when nobody is logged in.
4. How do you configure hundreds of devices, and who is allowed to?
Why it matters. Configuration drift and permission sprawl tend to appear once a deployment has run for a while. Ask what a change does to the settings it doesn't touch. In Teams admin center, configuration profiles are designed to change only the settings you configure, but only on firmware from device makers that support it. On devices that don't, every setting in the profile is applied, and the ones you left unconfigured go back to their default values. On access, Microsoft's portal scopes roles to rooms or groups of rooms and recommends least privilege. Room devices also often sign in with shared accounts rather than a person's. Teams Rooms on Windows can't use interactive multifactor authentication, and Microsoft advises against enforcing it on its Android devices, so ask any vendor how it expects device accounts to be protected.
A good answer
- Groups or templates by site, device type and role, with a preview before a change applies, an assignment history and a way to restore a secure configuration you've defined.
- A clear statement of what happens to settings a change doesn't include, for each device model.
- Admin console sign-in through your identity provider with your multifactor policy.
- Roles scoped to locations, view separated from change, an exportable audit log, and local device admin credentials that are unique or centrally managed.
Red flags
- One apply-to-all button with no preview or staging. Ask how you would test a change on one site before it reaches every device.
- Everyone is a super administrator. Ask how you would give a site technician access to one building only, and how that access is recorded.
- Console accounts outside your identity provider, or no exportable audit log. Ask what your security team would need to review access, and how they would get it.
5. What does it need from your network, and what does it do with your data?
Why it matters. Network and security review is where rollouts stall. Get destinations, certificates and data flows in writing before the pilot. Microsoft publishes the endpoints its devices use, and for MDEP every one is on port 443, including regional MDEP device management endpoints. Its network guidance for Teams Rooms shows the questions to ask any vendor: Teams Rooms doesn't support proxy authentication, and proxy settings on Android devices vary by manufacturer. If network equipment presents certificates from a private certificate authority, the device has to trust that authority. Teams Rooms works with most 802.1X configurations, but Microsoft can't test every one. Microsoft also notes that Teams Rooms devices don't need your internal network and suggests an isolated segment with direct internet access.
Use NIST's six capabilities as a security question list: device identification, device configuration, data protection, logical access to interfaces, software update and cybersecurity state awareness. Ask for evidence in writing, such as independent audit reports or penetration test summaries, not a badge on a slide. On data, ask what leaves the device (telemetry, logs, calendar data), where it is stored, how long it is kept, who at the vendor can see it and what happens at retirement. Logs can hold more than you expect: Microsoft notes that end user data may be stored in Teams Rooms on Windows log files for troubleshooting and support.
A good answer
- A published list of domain names and ports with change notice, and no inbound connections from the internet.
- Documented behavior with your proxy, TLS inspection and 802.1X design.
- A data map covering data types, location, retention and deletion.
Red flags
- "Open everything" or broad wildcards. Ask for the specific destinations, why each is needed and how you'll hear about changes.
- Certificate validation that has to be turned off. Ask whether the device can trust your inspection certificate instead, or which traffic must bypass inspection.
- No account of where data goes. Ask for the data map in writing before the pilot, not after.
6. Does it work with your calendar and booking systems, and who answers when it breaks?
Why it matters. The calendar or booking platform is the source of truth, so the device is only as accurate as that connection. When a panel is wrong, the cause could be the device, network, calendar, integration or console. Ask which system is the system of record, what read and write permissions the integration needs, who holds the credentials, and what the device shows if the calendar is unreachable.
Lifecycle runs on three clocks: software, hardware and console. On software, Microsoft supports the current and previous major Teams Rooms app versions. On hardware, some certified Teams Rooms devices couldn't move to Windows 11 when Windows 10 support ended on October 14, 2025 and had to be replaced. On the console, Microsoft has moved Teams Android device management to the Pro Management portal and is retiring the overlapping tools in the Teams admin center in phases from October 2026. On accountability, Microsoft's MDEP model has Microsoft develop and secure the core platform while device makers maintain device specific components. Shared responsibility works when it is designed, so ask who owns diagnosis across layers.
A good answer
- A named system of record, least privilege credentials your administrator creates, and defined behavior when the calendar is slow or unreachable.
- Published support periods and end of life notice for each device model and software version.
- One escalation path, a real cross layer example, and an exit plan: factory reset, re-enrollment elsewhere and data export.
Red flags
- A logo list with no detail. Ask what each integration reads and writes, and who owns the credentials. Credentials held by the vendor need a clear reason and a way for you to revoke them.
- No published end of life dates. Ask how much notice you get before a model or version loses support.
- No single owner when something breaks. Ask for a recent example of a problem that crossed layers and who resolved it.
What will it cost to own over three years?
The purchase price is only part of what a platform costs. Ask each vendor for a three year cost estimate built on the same device count and sites, so the numbers compare, and have it cover:
- Hardware, including mounts, power and spares.
- Recurring subscriptions, per device, per room or per site.
- Integration licenses on the other side of the connection. Microsoft's Pro Management portal, for example, requires certain Teams Rooms or Teams Shared Space licenses.
- Support tiers, and what each tier includes in response time and replacement.
- Replacement for devices that reach end of life or can't take a new software version within the three years.
- Staff time for provisioning, monitoring, updates and site visits.
Then go back through the demo and ask which of the capabilities you saw need an additional license, a higher tier or paid services. A feature shown in a demo isn't always in the package being quoted.
What should you test in a pilot?
One test shows more than most demos: break the booking connection on purpose. In a controlled test environment, with a test room and calendar, interrupt the integration between the devices and the calendar or booking system, for example by revoking the integration's access or blocking its connection. Then check:
- What the screen displays. Does it keep showing the last status as if nothing changed, or does it tell people the information may be out of date?
- Whether an alert arrives, how long it takes and who receives it.
- How service recovers once you restore the connection: automatically or by hand, how quickly, and what the logs record.
A device that keeps showing an old status with no alert is the online but wrong problem from question 3, found before it reaches a real meeting room.
A one page checklist
Take this into vendor meetings and pilots. For each row, record one result per vendor: shown live, answered in writing, not tested or not supported. Not tested means you haven't seen evidence yet. Not supported means the vendor has confirmed it can't be done. Note the evidence beside each result, such as a demo date, a document or a test result, and what still needs testing.
| Area | Ask to see | Evidence to keep |
|---|---|---|
| Enrollment and provisioning | A new device going from box to managed, in bulk | Setup time per device and who did each step |
| Updates and recovery | A staged update with a pause, and the recovery process for a failed one | Update and recovery documentation, version support periods |
| Monitoring and alerting | An alert for a device that is online but showing wrong information | The alert as received, and where it went |
| Configuration at scale | One change applied to a group, with preview | What happens to settings the change didn't include |
| Identity and access | A scoped administrator and the audit log | An exported audit log sample |
| Network and security | Destination list, certificate and 802.1X details | The written network requirements and security evidence |
| Data handling | A data map with retention and deletion | The data map in writing |
| Calendar and booking | Permissions, and the screen when the connection fails | Your pilot test results |
| Lifecycle and support | Support periods, escalation path, exit plan | Published end of life policy and support terms |
| Cost | A three year estimate on your device count | Which demonstrated features cost extra |
Where Embrava fits
Embrava makes Blynclight, Desk Sign, Room Sign and Any Sign, and connects digital systems with the physical spaces where people work. Desk Sign, Room Sign and Any Sign are managed remotely through Embrava Connect Cloud, the platform for managing Embrava devices and their connections to the booking and workplace systems an organization already uses. USB Blynclight models work differently: they take their status from the Embrava Connect app on the user's computer. Even within one family, devices can need different management, so map each device type to how it will be managed before you compare platforms.
The same applies to devices you already own. Connect Cloud is an example: Gen 2 Embrava devices move to it remotely during a scheduled maintenance window, while Gen 1 devices need a hardware upgrade first. Ask every vendor which of your current devices can move to its platform, and how.
Run these six questions against Embrava as you would against anyone else. To see how your device types, calendar and booking integrations, and network requirements map to them, talk with an expert.
Frequently asked questions
Sources
- Microsoft Learn, Platform Overview (Microsoft Device Ecosystem Platform), 2026
- Microsoft Learn, Services: Endpoints and Ports (Microsoft Device Ecosystem Platform), 2026
- Microsoft Learn, Manage devices in Microsoft Teams, 2026
- Microsoft Learn, How to create and configure resource accounts for Teams Rooms and panels, 2026
- Microsoft Learn, Microsoft Teams Rooms Pro Management Portal device update management, 2026
- Microsoft Learn, ServiceNow Incident Integration for Pro Management Portal, 2026
- Microsoft Learn, Role-based access control in the Microsoft Teams Rooms Pro Management Portal, 2026
- Microsoft Learn, Supported Conditional Access and Intune compliance policies for Microsoft Teams Rooms and Teams devices, 2026
- Microsoft Learn, Microsoft Teams Rooms on Windows and Teams Android device security, 2026
- Microsoft Learn, Prepare your environment for Teams Rooms, 2026
- Microsoft Learn, Teams Rooms app and Windows versioning support, 2026
- Microsoft Learn, Transitioning Teams Android Device Management from Teams Admin Center to the Teams Rooms Pro Management Portal, 2026
- NIST, NIST IR 8259A: IoT Device Cybersecurity Capability Core Baseline, 2020
- NIST, NIST SP 800-193: Platform Firmware Resiliency Guidelines, 2018