Resource
Wayland Remote Access Evaluation Checklist
A vendor-neutral list of what to verify before choosing a remote control tool for a Wayland Linux fleet.
What should you verify before choosing a remote control tool for a Wayland Linux fleet?
Use this vendor-neutral list when evaluating any remote control tool for a Wayland Linux fleet. The 26 questions cover capability (greeter access, reboot persistence, headless), compositor coverage (GNOME, KDE, others), security and consent model, operations and integration, and the vendor's posture toward GNOME and KDE upstream in 2027. Specific vendor answers, or vague ones, separate real Wayland coverage from marketing copy. Useful even if DeviceView is not on your shortlist.
Last reviewed: · DeviceView editorial
How to use this
A vendor-neutral list, useful even if DeviceView is not on your shortlist
If you are running, upgrading to, or planning a fleet on Wayland Linux, Ubuntu 26.04, RHEL 10, Fedora 44, or any current GNOME or KDE distribution, the questions below will tell you whether a given remote support vendor actually solves the problem or papers over it. Pull this up alongside any vendor demo or capability document. The questions are deliberately specific. Vague answers from the vendor are themselves an answer.
This checklist is useful regardless of which tool you pick, including if you do not pick DeviceView. The architectural shifts in Wayland affect everyone running Linux desktops; the questions are the same questions every Linux desktop admin should be asking in 2026.
Capability
Does it actually do unattended on Wayland?
The first set is the wedge. Most legacy tools fail at least one of these in their current Wayland implementation.
- 01
Can the tool reach a GNOME Wayland endpoint at the GDM login screen with no user logged in?
Vendor-language to watch for: "Wayland supported" without specifying greeter access. Specifics to ask: which Mutter version, which GNOME version, which distribution, what authentication path. A live demo of a fresh boot to GDM, operator connect, login from the operator side is the only confident answer.
- 02
Can the tool reach a KDE Wayland endpoint at the SDDM login screen?
KDE Plasma 6.7 supports both X11 and Wayland sessions; Plasma 6.8 (October 2026) is Wayland-exclusive. KRdp is KDE's native RDP service, but third-party vendor support for SDDM-Wayland-greeter access varies. Ask the vendor specifically.
- 03
After a reboot, before any user logs in, does the tool re-establish operability automatically?
This is the test that catches tools storing unattended state inside a user session. A vendor that says "yes, the agent reconnects" should be able to demonstrate it from a cold reboot, not a logout.
- 04
With the screen locked, what happens to an active operator session?
Acceptable answers: continues, drops with auto-reconnect, drops with explicit re-authorization. Unacceptable: vague.
- 05
On a headless endpoint (no monitor attached at all), does the tool produce a usable session?
Some implementations capture the compositor's output and have nothing to capture if the compositor is not actually rendering. Lab equipment, kiosks, signage, and headless workstations all hit this.
Compositor coverage
Which Wayland environments are actually supported
Wayland is not one thing. Each compositor, Mutter (GNOME), KWin (KDE), and others, is an independent integration surface.
- 06
Which compositors are supported in unattended mode, at which versions?
GNOME Mutter and KDE KWin coverage are independent. If a vendor's docs say "supports Wayland" without naming compositors and version ranges, treat the claim as unverified.
- 07
Does the tool require disabling Wayland (WaylandEnable=false) or switching to a non-default desktop environment?
This was the universal workaround for years. On Ubuntu 26.04 (GNOME 50), RHEL 10, Fedora 44, and any future distribution shipping a GNOME 50+ default, that workaround does not exist for the default desktop. KDE Plasma 6.8 closes the same door in October 2026.
- 08
Does the tool depend on xdg-desktop-portal per-session consent?
If yes, it cannot do unattended in the operational sense, there is no user to dismiss the dialog. The persistent-session pattern (persist_mode + restore_token) helps for some scenarios but not for login-screen or pre-reboot-pre-login.
Security and consent model
The compensating controls have to be defensible
Unattended access changes the consent layer. The compensating controls have to be defensible.
- 09
How is unattended authorization granted at enrollment, and how is it revoked?
A defensible model authorizes the agent on a known device, by IT, governed by RBAC, with a clear path to revocation. Ask to see the audit record of an enrollment and the revocation procedure.
- 10
What does the audit log contain?
Operator identity, endpoint identity, session start and end timestamps, in-session activity (where enabled), session recording (where enabled). Ask to see a real audit log line for a real session.
- 11
Can session recording be enabled and where do recordings live?
Storage location, retention controls, access controls, encryption posture. Confirm the retention story is compatible with your compliance scope.
- 12
Does privileged work inside the session still require OS-level authentication?
PAM, the greeter, or polkit. If the answer is no, if the operator gains privilege without OS-level auth, that is a finding for security review, not a feature.
- 13
Is Wayland's structural isolation preserved?
Per-app input isolation, no global keylogging surface, mediated screen capture. Unattended remote access should relocate the consent decision, not weaken Wayland's underlying security model. If the vendor's implementation requires turning off compositor-level protections to function, the security story is materially weaker.
- 14
End-user visibility during an unattended session.
Is there a banner? A post-session notification? Is suppressing notification configurable? Whatever the answer, confirm it is configurable enough to align with your acceptable-use policy and any applicable regulation.
Operations and integration
The capability has to land in the operational reality of your team
- 15
Identity: SSO (SAML / OIDC), SCIM provisioning, MFA?
For an enterprise fleet, joiner-mover-leaver should track operator access automatically. Ask which IdPs are supported; confirm with the IdP-side configuration.
- 16
RBAC granularity?
Operator level, group level, device-group level. Separation between read-only viewing, file transfer, clipboard, remote shell, full control.
- 17
Mobile operator console?
If on-call engineers carry phones, confirm mobile parity for the operations they will actually do, including unattended Linux endpoints.
- 18
ITSM integration?
Session evidence flowing to the ticket. Look for ServiceNow, Jira Service Management, Freshservice, or whatever your team runs.
- 19
SIEM integration?
Audit events landing alongside the rest of your security telemetry.
- 20
MDM / UEM integration?
Intune, Workspace ONE, Jamf, SOTI MobiControl, Samsung Knox, others depending on the fleet. The question is whether device posture from the MDM gates remote-support access.
- 21
Cross-platform parity?
If your fleet is mixed (Linux + Windows + macOS), confirm the operator console is consistent across platforms. Tool fragmentation is a real cost.
Vendor posture
How does this hold up in 2027?
The Wayland landscape is moving. The vendor's posture toward upstream is part of the evaluation.
- 22
How does the vendor track GNOME and KDE releases?
Both ship every six months. Major releases can affect the integration surface. Ask: do you test pre-release builds? what is your release cadence relative to upstream? what SLA-grade compatibility commitments can you make?
- 23
What is the public position on KDE Plasma support, given Plasma 6.8's October 2026 Wayland-exclusive release?
Some vendors are GNOME-first today and explicit about it. Some claim broad coverage and have not tested KDE seriously. The honest GNOME-first answer plus a roadmap is more trustworthy than a vague "all Linux supported."
- 24
Has the vendor's engineering team publicly engaged with the upstream Wayland portal API work?
GitHub commits, GNOME Discourse threads, freedesktop.org mailing lists. Vendors that participate in the upstream conversation typically build sturdier integrations. Vendors that have not engaged at all are downstream consumers of whatever the ecosystem hands them.
- 25
Has the vendor publicly declined to support Wayland?
Some have. If the vendor's support docs or technical bulletins state Wayland will not be supported, that is dispositive, the path forward is not with that vendor on Linux.
- 26
What is the workaround posture in the vendor's current docs?
"Use X11" / "set WaylandEnable=false" / "switch to Xfce", those are workarounds, not solutions. On distributions shipping GNOME 50 and on KDE Plasma 6.8+, those workarounds are not viable for the default desktop. A vendor still recommending them is signaling where they are in their Wayland transition.
What to do with this list
Walk it on every vendor call
A practical approach: on every vendor evaluation call, screen-share this page and walk the questions in order. The vendor's answers, especially the specifics they offer or fail to offer, separate vendors with real Wayland coverage from vendors with marketing copy. Take notes on each. The answers will frame the procurement conversation more honestly than any vendor-supplied capability matrix.
If you would like to go through this checklist with DeviceView's Linux engineering team against your specific fleet, distribution, version, default desktop, greeter, MDM, IdP, compliance scope, see Unattended Remote Control for Wayland Linux Devices and the Validate Compatibility CTA. The conversation is technical, not a sales demo.
Read next
Where to go from here
Also: What is Wayland remote desktop? for components and the X11/Wayland comparison.