Feature
Unattended Remote Control for Wayland Linux Devices
Connect to a Wayland Linux endpoint with no user logged in, including at the GDM or SDDM greeter, and after a reboot, on supported distributions.
Does DeviceView support unattended remote control on Wayland?
DeviceView provides unattended remote control of Linux endpoints running Wayland, including at the GDM and SDDM login screens and after a reboot, on supported distributions. Operator authentication, role-based access, and per-session audit logging are enforced. The DeviceView agent is installed before the unattended scenario is required; consent is granted at enrollment by IT, not per session by an end user. Validate compatibility for your specific distribution and greeter before rollout.
Last reviewed: · DeviceView Engineering
Background
Why unattended Wayland is hard (and what that means for your tool choice)
Most legacy remote control tools were built on X11. On X11, any authenticated client can read the framebuffer, capture keystrokes, and inject input events, by design. Remote support tools used those primitives directly.
Wayland reorganized the security model. The compositor (Mutter on GNOME, KWin on KDE) owns the screen. Clients cannot capture the display, inject input, or read other surfaces unless the compositor explicitly grants permission, typically through xdg-desktop-portal with end-user consent. That works for attended screen sharing on a video call. It is the wrong primitive for unattended IT support, where there is no end user to consent.
The hardest case in this category, and the one that distinguishes a real solution from a partial one, is the greeter: the device sits at GDM or SDDM with no user session at all. Tools that rely on a logged-in user session, including most that depend on xdg-desktop-portal, cannot reach the device in this state. After a reboot, the device returns to the greeter and the same problem recurs.
For a deeper architectural breakdown, see Why unattended remote desktop is hard on Wayland.
Architecture
How DeviceView handles it
DeviceView's unattended Wayland capability is delivered through a system-level agent that operates independent of any logged-in user session, paired with operator-side authentication, authorization, and audit. The agent is installed by IT before the unattended scenario is required; the consent decision is made at enrollment, on a known device, governed by RBAC and recorded.
Greeter and post-reboot reachable
The agent can present a session to an authenticated operator while the device is at the greeter, after a reboot, or with a screen lock active, without requiring an end user to dismiss a portal dialog.
Wayland isolation preserved
Per-app input isolation, no global keylogging surface, mediated screen capture. What changes is who makes the consent decision and when, not the underlying isolation properties.
Operator authentication, not OS bypass
Operator identity is enforced through SSO and MFA. Privileged actions inside the session still require local OS authentication via PAM, the greeter, or polkit as appropriate.
Wayland as shipped
DeviceView does not require disabling Wayland (WaylandEnable=false), forcing a switch to a non-default desktop environment, or routing the session through an X11 fallback.
DeviceView does not publish further implementation detail. Architecture-level disclosure is sufficient for an evaluation; deeper information is available to customers under NDA as part of a compatibility validation conversation.
Compatibility
Expected environments
The distributions and desktops below are expected to work with DeviceView's unattended Wayland capability based on the underlying architecture (system-level agent, GDM and SDDM integration, gnome-remote-desktop and KRdp primitives). Ubuntu 24.04, Ubuntu 26.04, and Debian 12 are verified today; remaining rows are expected to work based on the underlying architecture and will be marked verified as test runs complete. We will validate your specific distribution, version, default desktop, and greeter as part of evaluation.
| Distribution / Version | Default desktop | Display server | Default greeter | Status |
|---|---|---|---|---|
| Ubuntu 24.04 LTS | GNOME 46 | Wayland | GDM | ✓ Verified |
| Ubuntu 26.04 LTS | GNOME 50 | Wayland (only) | GDM | ✓ Verified |
| Fedora Workstation 40 | GNOME 46 | Wayland | GDM | Expected to work, not yet verified |
| Fedora Workstation 41 | GNOME 47 | Wayland | GDM | Expected to work, not yet verified |
| RHEL 9 (workstation) | GNOME 40 | Wayland (default) | GDM | Expected to work, not yet verified |
| RHEL 10 (workstation) | GNOME 47 | Wayland (only) | GDM | Expected to work, not yet verified |
| Debian 12 (GNOME) | GNOME 43 | Wayland | GDM | ✓ Verified |
For distribution-specific deployment notes, see Unattended remote control on Ubuntu 24.04 Wayland, Unattended remote control on Fedora Workstation Wayland, and the parent platform page Remote access for Linux devices running Wayland.
KDE Plasma, Xfce, Cinnamon, MATE, Sway, and other Wayland compositors are also expected to work where the underlying portal and display-manager primitives are present, on the same not-yet-verified basis. KDE-specific roadmap details are available under NDA. See limitations.
Security and consent
What an end user sees, what is logged, and who can override
Consent
For unattended sessions, the consent decision is made at enrollment by IT, on a known device, recorded in the audit trail. This replaces the per-session xdg-desktop-portal dialog that an absent user cannot answer. Wayland's structural isolation properties are preserved.
Operator authentication
SSO via SAML or OIDC, MFA enforcement, and SCIM provisioning are supported. Operator identity flows through to the audit record on every session.
Authorization
Role-based access controls (RBAC) at the operator, group, and device-group level. Technician permission scopes can be configured to separate read-only viewing, file transfer, clipboard access, remote shell, and full control.
Audit
Per-session connection events, operator identity, endpoint identity, session start and end timestamps, and where enabled, in-session activity logs and session recording (a usage-based add-on). Audit artifacts are exportable. Where SIEM integration is configured, events land alongside other security telemetry.
End-user visibility
What the end user sees during an unattended session, including any operator banner, post-session notification, or absence of either, is configurable by IT policy and should be aligned with internal acceptable-use policy and applicable regulation.
For the full control catalog, see Audit, RBAC, and consent controls for unattended Wayland access.
Use cases
Where unattended Wayland support changes the work
Five concrete operational scenarios where unattended Wayland support changes whether the work is doable remotely or requires a truck roll.
Recovering an endpoint that has rebooted overnight
A scheduled patch leaves the endpoint at the greeter. The on-call technician connects, authenticates as a privileged local or directory account at the endpoint, validates state, and closes the ticket, with no user.
Troubleshooting a locked Linux laptop
An end user is on PTO; their workstation is locked. A help-desk technician connects, completes work that does not require the user's data, and disconnects.
Supporting kiosk and signage endpoints
A kiosk reboots after a power blip and waits at the greeter. The DeviceView agent allows remote validation and remediation without dispatching a technician.
Pre-deployment configuration on a freshly imaged device
A new Linux endpoint is enrolled, agent-installed, and reachable for unattended configuration before any user logs in for the first time.
Out-of-hours remediation in regulated environments
Healthcare, lab, or research workstations remediated outside operating hours, where waiting for an end user to consent is not operationally viable. Operator identity, optional session recording, and audit export support evidence requirements for SOC 2, HIPAA, or ISO 27001 review.
Limitations and requirements
What is in scope, and what is not
The list below is not exhaustive; configurations outside it should be validated.
- 01Agent must be installed before the unattended scenario is requiredDeviceView is not a remote-attach tool that can recover an endpoint with no agent installed.
- 02GNOME Wayland is the supported compositor todayKDE Plasma, Xfce, MATE, Cinnamon, Sway, and other Wayland compositors are not in the same support tier. KDE-specific roadmap details are available under NDA.
- 03Distributions outside the supported environments matrix are unsupported until verifiedA distribution being Linux and shipping Wayland is not sufficient: the verification has to exist in the compatibility matrix.
- 04OS-level authentication still applies inside the sessionPrivileged actions require PAM, greeter, or polkit authentication on the endpoint. Unattended is about the display server consent layer, not bypassing OS authentication.
- 05Network requirementsThe DeviceView agent requires outbound connectivity per the documented network specification. NAT traversal, proxy support, and air-gapped deployment models should be validated against your environment.
- 06ComplianceDeviceView markets HIPAA-aligned operator controls and provides exportable audit artifacts. DeviceView does not certify your organization's compliance with SOC 2, HIPAA, ISO 27001, PCI, or any other framework. FedRAMP and DoD IL4 authorization are not currently marketed; federal and DoD evaluators should ask for the current posture.
- 07GNOME release trackingMajor GNOME releases can affect the integration surface. The DeviceView Linux engineering team runs continuous validation against current and pre-release GNOME builds. SLA-grade compatibility commitments can be discussed during procurement.
- 08Implementation disclosureDeviceView does not publicly disclose implementation specifics of the Wayland integration. Architecture-level information is sufficient for evaluation; deeper detail is available to customers under NDA.
Era comparison
How this differs from X11-era remote control
A short comparison of the two display-server eras for the same operational job. This is not a vendor comparison; for that, see TeamViewer alternative for Linux fleets on Wayland and other entries in the cluster.
| Aspect | X11-era remote control | Wayland unattended (DeviceView) |
|---|---|---|
| Display capture and input injection | Available to any authenticated X client by design | Mediated by the compositor; requires explicit authorization |
| Default consent model | None for trusted clients on the local server | Per-session user dialog via xdg-desktop-portal |
| Login-screen access | Via display manager configuration (e.g., xhost, XDMCP) | Requires architecture that does not depend on a logged-in user session |
| After reboot | Tool reattaches to the X session if running | Requires the agent to be present and operational independent of a user session |
| Security implications | Global keylogging and screen scraping latent in the protocol | Structural isolation; consent layer is the operator-managed surface |
| Common workaround on modern Linux | Switch back to X11 / Xorg | Not available on the default desktop in Ubuntu 26.04, RHEL 10, or any distribution whose default GNOME no longer ships an X11 backend |
The displacement is not "Wayland is harder, so use a workaround." It is "Wayland reorganized the security model; the workaround era is closing on the default desktop, and the durable answer is a tool architected for Wayland."
Frequently asked questions
Internal links