Managing interactive displays: Why shared classroom devices need a different approach

Interactive displays belong in your endpoint management plan, but they should not be managed on the same assumptions as a 1:1 device. Nearly every management framework in wide use, Android Enterprise included, was designed around one person using one device they are assigned. A classroom display is used by six teachers and a hundred and fifty students in a day, has no assigned owner, is mounted on a wall, and exists to run instructional workflows that involve several people touching it at once. Apply single-user assumptions to that device and you get one of two outcomes: a display so locked down that teachers stop using it, or a display so loosely managed that it drifts out of compliance within a term.

This article is for district technology leaders deciding how classroom displays fit into their endpoint strategy. It covers what actually makes shared displays different, how Google EDLA and Android Enterprise relate to each other (they are not the same thing, and the confusion is expensive), which enrollment decisions are hard to reverse, and what to ask any display vendor before you commit. It is a companion to our classroom technology readiness framework and to our article on the configuration failures that break classrooms on day one.

Should interactive displays be managed as endpoints?

Yes. An interactive display authenticates to your network, holds certificates, runs an operating system with a version and a patch level, signs users into your identity provider, reaches cloud services through your firewall, and runs applications that update independently. By every functional test, it is a managed endpoint. What determines whether an IT team can support a growing fleet without the support burden growing in step with it is endpoint visibility, centralized management, and operational efficiency.

What is still catching up is district practice. Many readiness and endpoint plans still centre on student devices, with classroom infrastructure treated as fixtures. That gap is where most first-week classroom failures live. So the answer is not that displays need less management than laptops. It is that they need a different kind.

What makes a shared classroom display different from a 1:1 device?

Five differences matter, and each one breaks a common management assumption:

• Many users, no owner. A laptop maps to one person, which is what makes user-based policy, personal profiles, and compliance attribution work. Most classroom displays have a room rather than an owner, with the people using them changing every period. Some do have a single regular user, a specialist's room, a private office, a lab, and those can reasonably be managed on 1:1 assumptions. The point is that the shared case is the common one and the one most management frameworks handle worst.
• Instructional workflows, not productivity workflows. The device exists so a teacher can annotate over a lesson, pull up a resource in seconds, and send several students to the board at once. Management that adds a step to any of those costs instructional time in every period of every day.
• Guest and transient access is normal, not an exception. Substitutes, specialists, visiting staff, and students all use the display legitimately. On a 1:1 device, an unrecognised user is a signal worth investigating. On a classroom display, it is Tuesday.
• Multi-user interaction is a feature, not a risk. Several people interacting simultaneously is the point of the device. Management approaches built to enforce a single active session work against the reason the display was purchased.
• It is physically fixed and always visible. There is no swapping in a spare, no taking it to the helpdesk, and no discreet failure. When a wall-mounted display misbehaves, it does so in front of a class.

The vocabulary worth using

Districts and vendors often use guest, shared, and personal profile loosely, which makes management conversations harder than they need to be. SMART's own terminology is more precise and is worth adopting, because the product documentation and support content use it too. The Owner User is the user created at first setup. The Public User is the profile that applies when anyone walks up to the display, and Guest Access is an optional distinct feature within that category for walk-up use. Secondary Users cover additional users, including those signing in with a SMART Account. Required iQ Sign-in is an optional setting that restricts access to users with an organisation account. Separately, the choice between dedicated access mode (classic) and shared access mode determines, among other things, whether an IT administrator can recover a panel that has been left in an Android PIN-locked state. Getting these terms right early makes the enrollment discussion below considerably clearer.

Where single-user management assumptions break down

It is worth being concrete about which assumptions fail, because this is where districts get surprised after enrollment rather than before.

There is a concrete technical reason underneath all of this, and it is worth naming: there are current incompatibilities between the Google EMM APIs and the Android multi-user feature that shared displays depend on. The assumptions in the table above are not merely a poor cultural fit. At the platform level, the management framework and the multi-user capability are not fully reconciled. None of this means enterprise MDM has no role. Most districts should and will keep classroom displays visible in the platforms they already run. The point is that the enterprise platform answers governance questions, and something closer to the classroom has to answer the instructional ones.

Google EDLA and Android Enterprise are not the same thing

These two terms get used interchangeably, including by vendors, and the confusion leads to decisions that are painful to unwind. They answer different questions.

EDLA stands for Enterprise Device Licensing Agreement, and it is worth being exact about what it covers, since this section exists to draw a precise line between two terms. It is not education-specific: it is the route by which Google licenses Google Mobile Services onto purpose-built and dedicated devices generally, with education one of the segments it covers.

Put simply: certification tells you what the display can do out of the box, and enrollment determines how you govern it afterwards. An EDLA-certified display gives teachers native access to the Google tools they already use, rather than a bolt-on layer sitting on top of a generic Android build. That distinction matters for reliability as much as for features, because native platform access means Google's own update and security pipeline applies to the device. Our explainer on what Google EDLA is covers the certification in more detail.

The enrollment decision you cannot easily reverse

Enrollment mode is the highest-consequence, least-discussed decision in classroom display management, and it deserves deliberate attention before deployment rather than discovery afterwards. Android Enterprise offers different enrollment modes, and the mode you choose can constrain which management tools remain available to you. On SMART displays the position is published: for displays used in a shared environment, SMART recommends SMART Remote Management rather than an EMM platform, and the two are alternatives rather than layers. Provision a display as a fully managed EMM device and Android itself disables SMART Account sign-in, because Android Enterprise and Android multi-user cannot both apply, which also removes the personalized home screen and access to Lumio files in the Files Library. Provision it with an EMM Work Profile instead and the profile reaches only the Owner User, so every teacher signing in with a SMART Account sits outside the EMM's policies altogether, leaving the platform useful for inventory but little else. And removing a display from Android Enterprise Device Owner enrollment requires a factory reset.

Read that last sentence again with a wall-mounted display in mind. A factory reset on a laptop is an afternoon. A factory reset across several hundred displays, each in a room, each needing reconfiguration and revalidation, is a summer. This is why the enrollment question belongs in July planning alongside certificates and identity policy, and why it is worth confirming the constraint with your display vendor for your specific models and firmware before you enroll a fleet.

Four questions to settle before enrolling anything:

• Which management capabilities does each enrollment mode enable, and which does it foreclose? On SMART displays the answer is published: fully managed enrollment forecloses SMART Account sign-in and Lumio access in the Files Library, Work Profile enrollment forecloses policy reach over any user who signs in with a SMART Account, and binding SMART Remote Management to an EMM forecloses direct Managed Play app assignment from the Google Admin Console.
• What is the exit path if the decision proves wrong, and what does it cost per room?
• Does the mode we are considering preserve the instructional experience teachers expect, or does it quietly restrict it?
• What is our Google Admin Console set to, and have we tested sign-in on an enrolled panel before rolling out? With Universal Settings and Android Management left on Advanced rather than Basic, signing in on the panel prompts for the Device Policy App, which converts the display into a fully managed device and disables the sign-in you were testing. Basic removes the Device Policy App requirement and leaves sign-in intact. This is free to check in advance and expensive to discover afterwards, not least because nobody chooses fully managed enrollment here; an administrator simply accepts a prompt.

What your Google Admin Console settings decide

There is a third decision layer that districts rarely account for, and it produces the most confusing tickets of the three. Certification determines what the display natively supports. Enrollment determines how you govern it. Your Google Workspace tenant settings determine what a teacher can actually reach once they have signed in, and those are separate permissions.

That separation is the whole problem. Signing in and reaching data are two different grants in Google Workspace, and K-12 tenants commonly allow sign-in by default while defaulting unconfigured third-party apps to blocked or limited access. The result is a display where the teacher is visibly signed in, their name is on the screen, and their Drive is empty, because the Drive permission was silently withheld from the app rather than from the user. Nothing about the display is misconfigured, and no amount of troubleshooting on the panel will find it.

The symptoms follow a recognisable pattern:

• “Access blocked: your organisation's admin needs to review this app”. The app was never configured, and the tenant default is to block.
• Signed in, but no Google files appear. The app is set to limited rather than trusted, so the Drive scope is withheld.
• Browsing Drive works but exporting to Slides fails. The Slides API is restricted, or one app is trusted and another is not.
• Uploads fail with a generic error. The Drive SDK is disabled for that organisational unit, or the account has no storage headroom.
• One school or one grade is affected, and the rest of the district is fine. A setting is scoped to some organisational units and not others.

The last one deserves emphasis, because it is what makes this class of problem so hard to see from a sample. Every setting here can be scoped per organisational unit, and a sub-unit can override its parent. A configuration validated against a teacher account in one building tells you nothing definitive about the building next door. If you validate one thing after reading this article, validate with a test account in both a teacher unit and a student unit.

What to check, in order: that each SMART application is configured as trusted rather than limited under app access control, and scoped to the units your users are actually in; that the Drive SDK is enabled for those units and not only at the top level; that Drive and Slides API access is either unrestricted or restricted with the SMART applications explicitly trusted; and that user storage limits are not set to zero, which blocks every upload. Applications have to be trusted individually, since trusting one does not trust the others. Signing a user out of the display and back in forces a fresh consent and token exchange, which is worth doing before concluding a change has not worked; changes usually propagate in minutes but can take up to 24 hours.

Two things are worth telling teachers rather than troubleshooting. A consent prompt on first use is normal and expected. And the Drive permission these applications request is file-scoped: the application touches only the files a user opens or creates with it, not the whole of their Drive. That second point answers a question districts ask early and is easier to make once, in writing, than repeatedly in meetings.

The identifiers needed to configure each application, and the current recommended values, are in SMART's support documentation rather than in this article, because they change. Ask your SMART contact or check the support site before a wide deployment.

The trade-off nobody names: manageability against teachability

Every management decision on a classroom display trades governance against instructional usability, and the trade is real rather than rhetorical. Lock a display into a single-app kiosk and you have a device that is easy to govern and useless for the teaching it was bought for. Leave it fully open and you have a flexible device that drifts out of compliance and accumulates the software drift that causes next August's problems.

The failure mode districts underestimate is the first one, because it does not generate tickets. It generates disuse. A display that adds three steps to starting a lesson does not get reported as broken; it gets quietly avoided, and the investment stops returning value without anyone raising a hand. When you evaluate a management approach, ask what it costs a teacher at the start of every period, not only what it gives IT at the start of every year.

This tension is also why the design decisions inside a management platform matter. SMART Control, for example, is being built as policy-based configuration of the existing iQ launcher rather than a launcher replacement or a full EMM takeover. That is a deliberate trade-off, and one most district IT teams evaluating “MDM for interactive displays” would overlook. The reason it matters is that a policy layer over the teaching experience keeps the classroom working the way teachers already know, while a launcher replacement changes the teaching experience in order to manage it. Both are defensible engineering choices. Only one of them leaves the classroom untouched.

What good classroom display management actually provides

Whatever platform you use, and whatever brand you buy, these are the capabilities that matter for a shared display fleet:

• Fleet-wide visibility. Firmware and OS versions, application inventory, and device status for every display, viewable from one place. This is what turns an audit from a walking exercise into a query.
• Centralized configuration. Network profiles, certificates, and settings applied consistently, with the ability to group displays by building, model, or OS version, since those groupings determine how changes need to be staged.
• Update governance. A deliberate model for how firmware and OS updates reach the fleet, whether automatic or staged, applied consistently rather than left to chance.
• Session and access handling suited to shared use. Clean handover between users, sensible sign-out behaviour, and a defined path for substitutes and guests.
• Application control. The ability to hold a standard build and prevent the drift that accumulates between school years.
• Interoperability with what you already run. Support for the enterprise tooling and identity platforms the district has standardized on, rather than a parallel stack.
• Preservation of the teaching experience. Every capability above delivered without adding steps to the start of a lesson.

How SMART approaches shared classroom display management

SMART sits at the intersection of classroom technology and district IT operations, which shapes how its management tools are designed. SMART is the ONLY interactive display manufacturer combining Google EDLA-certified displays with a purpose-built classroom device management platform designed specifically for shared classroom environments. In practice that means three things for an IT team.

Native platform access rather than a bolt-on layer

SMART Boards with iQ 4 are EDLA-certified, giving native Google Mobile Services access rather than a management layer added on top of a generic Android build. The AM60 appliance is independently EDLA-certified as well, which matters for fleets rather than for new purchases: it can retrofit the iQ 4 experience onto compatible SMART panels with iQ running earlier iQ 3 hardware, which covers the MX series, 6000 series, and 7000 series. It is a SMART-specific upgrade rather than a general OPS computing module, so it does not apply to third-party panels, and it is not compatible with non-iQ SMART displays such as the GX series. Confirm compatibility for your exact models before planning a retrofit. For a district running compatible displays bought across several years, that is the difference between managing several distinct software environments and standardizing older and newer displays onto one.

Centralized visibility designed for education fleets

With custom workflows and scripting in MDMs (SMART Remote Management, SMART Control), SMART provides centralized visibility and management of interactive displays designed for education environments, helping IT teams maintain classroom readiness at scale. SMART Remote Management includes a subscription with every SMART Board with iQ for the length of the included warranty, and covers the visibility and configuration work described earlier in this article.

Complementing enterprise MDM, not replacing it

This is the honest boundary, and it is worth stating plainly because it is the question every IT director asks. SMART's management tools are designed to complement the enterprise MDM platforms districts already run, not to replace them. SMART displays also support Android Enterprise enrollment for districts that prefer their existing tooling, subject to the enrollment-mode constraints described above. Districts should not expect, and SMART does not claim, that a display management platform will take over enterprise endpoint governance. Nor is any of this zero-touch: certificates still need planning, identity changes still need testing against shared devices, and rooms still need validating before term. What centralized management changes is how much of that work requires a person standing in the room.

On the governance and compliance side, SMART's current panel lines carry the regulatory and industry certifications districts are typically asked to evidence in procurement, including UL, FCC, and ISED for the US and Canada, CE, UKCA, RoHS, and WEEE for the EU and UK, and RCM for Australia and New Zealand, alongside ENERGY STAR, HDMI, and HDCP compliance. Interoperability with Microsoft 365 and Google Workspace is native rather than layered.

Questions to ask any interactive display vendor about management

These work for any brand, and the answers are more revealing than a feature list:

• Is the display EDLA-certified, and what specifically does that certification cover on this model?
• Which Android Enterprise enrollment modes do you support, and which management capabilities does each mode enable or foreclose?
• What is the exit path from an enrollment decision, and does it require a factory reset?
• How long will this display continue to receive OS and security updates, and is that commitment published?
• Can I see firmware versions, application inventory, and device status across the entire fleet from one place?
• How does your management approach handle many users per day, and what happens to one user's session when the next arrives?
• Does your management platform replace or complement the enterprise MDM we already run?
• If we already own displays from earlier years, can they be brought onto the same software experience as new ones, and which exact models qualify?
• What does your management approach change about the teacher's experience at the start of a lesson?

The bottom line

Treat interactive displays as managed endpoints, and then manage them as what they are: shared, instructional, multi-user devices that live in rooms rather than in bags. That means choosing enrollment deliberately because reversing it is expensive, understanding that EDLA certification and Android Enterprise enrollment answer different questions, and judging every management decision against both governance and the teacher's first thirty seconds of a lesson. Get that balance right and classroom displays become the easiest part of your fleet to keep ready. Get it wrong in either direction and you either manage a display nobody uses, or use a display nobody manages.