What platforms does DeviceView support?

DeviceView supports Android, iOS, macOS, Windows, and Linux from a single platform. All platforms are included at no extra cost, including full unattended remote control for Android Enterprise corporate-owned devices.

How does DeviceView compare to TeamViewer?

DeviceView includes mobile support, SSO (SAML 2.0 and OIDC), and SCIM provisioning as standard features. TeamViewer charges extra for mobile device support, locks SSO behind its most expensive Tensor tier, and does not support Android Enterprise corporate-owned devices even through Intune integration.

Does DeviceView include SSO and enterprise identity?

Yes. SAML 2.0, OIDC, and SCIM provisioning are included in every DeviceView plan. There is no separate enterprise tier required for SSO or directory sync.

Is DeviceView HIPAA-ready?

DeviceView is designed for HIPAA-regulated environments. Privacy Mode blacks out patient-facing screens during remote sessions, preventing PHI exposure. Optional session recording with full audit logs including operator, device, and timestamp is available and exportable for compliance audits.

Does DeviceView support unattended Android remote control?

Yes. DeviceView provides full unattended remote control for Android devices, including Android Enterprise corporate-owned (COPE and fully managed) devices. No end-user interaction is required to start a session.

What MDM and EMM integrations does DeviceView offer?

DeviceView integrates natively with Microsoft Intune, VMware Workspace ONE, SOTI MobiControl, Jamf Pro, and Samsung Knox. Remote view and control launch directly from your existing MDM console.

How does DeviceView handle session security?

DeviceView uses WebRTC peer-to-peer connections so sessions never route through DeviceView servers. Multi-tenant data is separated with cryptographic isolation. Every session is recorded with exportable audit logs.

Is DeviceView built for MSPs?

Yes. DeviceView supports multi-tenant environments with cryptographic isolation between tenants, making it suitable for managed service providers supporting multiple client organizations from a single platform.

What is the difference between attended and unattended remote access on Linux?

Attended remote access requires a user at the keyboard to grant consent, typically through the xdg-desktop-portal ScreenCast or RemoteDesktop dialog. Unattended remote access has no user present and is authorized differently: through the GNOME headless remote-login service, a vendor system-level integration, or the portal's persistent session pattern with a stored restore_token.

Can you do unattended remote control on a Linux device at the login screen?

Yes, on supported configurations. gnome-remote-desktop integrates with GDM to support headless remote login on GNOME 46 and later. Several commercial enterprise platforms provide equivalent capability with fleet management, identity, and audit. Tools that depend on a logged-in user session cannot do this.

What permissions does unattended remote control on Wayland require?

At a minimum: an endpoint-side service authorized at install or enrollment time to listen for inbound connections; OS-level credentials to authenticate at the greeter or for privileged actions inside the session; and identity for the operator (typically through SSO and MFA in enterprise tooling). Privileged actions inside the session still require PAM, the greeter, or polkit authentication regardless of how the session was established.

Is unattended remote control on Wayland less secure than on X11?

No. Wayland's compositor-mediated model is structurally stronger than X11's: per-app isolation, no global keylogging surface, mediated screen capture. What changes for unattended IT support is the consent layer, moved from a per-session end-user dialog to an IT-managed enrollment-time authorization, which is auditable and revocable. The underlying isolation properties are preserved.

Does unattended remote control bypass the user's consent on Wayland?

For the specifically unattended case, yes, the consent decision is made at enrollment by IT rather than per session by the end user. The end user's view of operator activity (banner, post-session notification, none) is configurable by IT policy and should be aligned with internal acceptable-use policy and any applicable regulation.

What is xdg-desktop-portal?

A Freedesktop component that brokers requests between applications and the host system on Wayland, including screen capture and remote desktop. Each desktop environment provides a portal backend (GNOME's, KDE's, etc.). Most attended remote-support flows on Wayland route through it.

Where can I see what works on my distribution and greeter?

On the Feature page's compatibility matrix: Unattended Remote Control for Wayland Linux Devices. The matrix lists distribution by display server by greeter by scenario, with verification dates.

Glossary

What Is Unattended Remote Control on Wayland?

Definition, mechanics, and what makes it harder than X11.

What is unattended remote control on Wayland?

Unattended remote control on Wayland is the ability to remotely view and operate a Linux device running the Wayland display server when no user is at the keyboard, including at the GDM or SDDM login screen, after a reboot, or on a headless endpoint with no user session yet established. It requires either the GNOME headless remote-login service, a vendor-built system-level integration, or a portal-based persistent session pattern, because Wayland's standard screen-capture and input flow assumes a user is present to grant consent.

Last reviewed: 3 May 2026 · DeviceView editorial

Read the guide Jump to definition

Context

Why the term exists

"Unattended" distinguishes the use case from "attended" remote support, where a user is sitting at the device, can see a consent prompt, and clicks Allow. Most remote-support tools were built first for the attended case. The unattended case (IT support at 3 AM, a kiosk reboot, a help-desk ticket while the user is on PTO, an off-hours patch on a clinical workstation) is operationally different in one specific way: there is no user available to consent.

On X11, that difference did not matter much. X11 exposed screen capture and input injection broadly, and any authenticated client could attach to a session or to the display server itself. On Wayland the difference is structural. Wayland's compositor mediates capture and input. The default flow assumes a user grants per-session consent through xdg-desktop-portal. Unattended use is therefore not the default path; it requires a deliberately different mechanism.

Coverage

The three things "unattended" has to cover

To call a Linux remote-support tool unattended in 2026, three scenarios all have to work, not just one of them.

Login screen

The endpoint sits at the GDM or SDDM login screen with no user logged in. The operator must be able to connect, authenticate, and either drive the greeter or land in a privileged session.

Post-reboot, pre-login

After a reboot, before any user logs in, the operator can re-establish a session. This is the test that catches tools that store unattended state inside a user session.

Locked screen and headless

A locked screen is the same kind of test in miniature. A headless endpoint with no monitor pushes harder: some implementations capture the compositor's display output and have nothing to capture if no display exists.

A tool that handles only post-login is not "unattended" in the IT-operations sense. It is interactive remote support that needs a user to log in first.

Comparison

How it differs from attended

Aspect	Attended remote support	Unattended remote control
User presence	User at the keyboard	No user present (by definition)
Consent model	Per-session user dialog (xdg-desktop-portal)	Authorization granted at enrollment by IT, governed by RBAC and audit
Login-screen access	Not relevant, user is logged in	Required
Post-reboot	Often N/A	Required
Use cases	Help-desk walkthroughs, training, screen-share-based troubleshooting	After-hours patching, pre-login configuration, kiosk and lab support, headless equipment, automated remediation
Failure mode if mistaken for the other	Users feel surveilled; consent model is invisible	Endpoint is unreachable when help is needed

Mechanics

Why it is harder on Wayland

Wayland's display protocol places the compositor (Mutter on GNOME, KWin on KDE) in charge of screen capture and input. Standard remote desktop on Wayland goes through the xdg-desktop-portal RemoteDesktop interface, which surfaces a consent dialog the user clicks. Unattended use cases have no user to click, so the standard flow does not apply.

Portal persistent session

The xdg-desktop-portal pattern where a one-time grant is stored as a restore_token and replayed on subsequent connections.

GNOME headless remote-login

gnome-remote-desktop integrated with GDM, available since GNOME 46, providing RDP access to the login screen and through to the desktop session.

Vendor system-level integration

A vendor-built integration with the desktop environment that operates outside the per-session portal flow, with policy and audit governed at the fleet level.

Each has trade-offs. For the deeper architectural breakdown, see Why unattended remote desktop is hard on Wayland.

Frequently asked questions

Where to go from here

Why unattended remote desktop is hard on Wayland

Full architectural explanation of the unattended Wayland problem, the patterns that actually work in 2026, and what to evaluate when choosing a tool.

Unattended Remote Control for Wayland Linux Devices

Verified compatibility matrix by distribution, display server, greeter, and scenario, with verification dates.