Audit, RBAC, and Consent Controls for Unattended Wayland Access

Unattended remote support is the use case Wayland's per-session xdg-desktop-portal consent model was not designed for. There is no end user at the keyboard to dismiss a dialog at 3 AM, at the GDM login screen, on a freshly rebooted endpoint. DeviceView solves this by moving the consent decision to enrollment time, where IT (not an absent end user) authorizes the device, governed by identity (SSO + MFA), authorization (RBAC), session-level audit, and (where enabled) session recording. The Wayland security model's structural wins (per-app input isolation, no global keylogging surface, mediated screen capture) are preserved. What changes is who makes the consent decision and when.

This page is for security and compliance leads evaluating whether DeviceView's unattended Wayland approach is defensible to internal security review and external audit.

Consent layer relocated

What changes (and what does not) when consent moves to enrollment

The Wayland security model has three structural properties that are independent of any consent dialog and that DeviceView's integration does not modify:

• Per-app input isolation. No application running in a Wayland session can read keystrokes, mouse events, or touch input destined for another application. There is no global keyboard hook on Wayland the way there is on X11.
• Mediated screen capture. Applications cannot read the framebuffer or scrape pixels off other windows. Screen content is delivered through PipeWire after compositor authorization.
• No protocol-level injection surface. Applications cannot synthesize input events into other windows or into the system. Input authorization is scoped to specific authorized sessions.

These properties are preserved on DeviceView-managed endpoints. They are why Wayland is structurally stronger than X11 for desktop security; the unattended remote-support architecture rides on top of them, not under them.

What DeviceView does change is the consent layer: the decision about whether a remote operator is allowed to view and control this device. On stock Wayland for attended use cases, that decision is made per session by the end user clicking Allow in a portal dialog. For unattended use cases, that decision is moved to enrollment: IT installs the agent on a known device, authorizes it under a tenant policy, and from that point forward any operator who satisfies the authentication and authorization gates can connect within the bounds of the policy.

The trust model is the same one Windows enterprise remote support has used since the 1990s, applied to Linux. The endpoint is enrolled into a fleet by IT, on a known device, with a recorded enrollment event. Operator access is governed by identity, RBAC, and audit. The Wayland-specific addition is that the underlying compositor isolation properties remain intact. DeviceView does not require disabling Wayland or routing through XWayland.

Identity

Who is allowed to connect

Authorization

What they can do, against which devices

Role-based access control operates on three intersecting axes:

A common configuration: tier-1 help-desk operators can connect to general-population workstations with read-only and chat, but cannot connect to executive laptops or to compliance-scope devices. Tier-2 engineers have full-control access on general-population devices and read-only on compliance-scope, with file transfer disabled on the latter. Audit administrators can read every session's log entry but cannot connect to devices. The tenant's RBAC policy is editable through the console and through API for IaC-managed configuration.

Endpoint authentication

Privilege still requires OS authentication

Unattended access to the endpoint does not equal privileged access on the endpoint. Privileged actions inside the session (sudo, pkexec, unlocking secrets, modifying system files, installing packages) still require local OS authentication via PAM, the GNOME greeter, or polkit. The unattended consent layer governs whether the operator can see and operate the desktop; OS-level authentication governs what they can do once they are operating it.

For sensitive operations that should require explicit operator-side credentials at the moment of execution, configure the relevant PAM stack and polkit policy as you would for any privileged-administrator workflow on Linux. DeviceView's session does not bypass these.

Audit

What is recorded, what it looks like, where it goes

Per-session audit events:

• Connection metadata. Operator identity (mapped to the IdP-issued identifier), endpoint identity, session start timestamp, session end timestamp, client IP, operator console version, agent version, authentication method.
• Authorization decision. Which RBAC policy allowed the connection, which permission scope was applied, whether step-up authentication was required.
• In-session activity (where enabled). Commands run through the integrated remote shell, file transfers (with file name, size, direction, and SHA-256 of contents), clipboard transfers (presence and direction; clipboard content is not logged unless content-logging is explicitly enabled), reboot and power-off events, remote installation events.
• Session recording (where enabled). Configurable per device group; common configurations record all sessions on compliance-scope devices, no recording on general-population, recording-on-demand for tier-2 escalations. Recordings are stored encrypted at rest and retention is tenant-configurable.

A sample audit log entry for a single session, in JSON format suitable for SIEM ingestion:

{
  "event_type": "deviceview.session.completed",
  "session_id": "ds_01HX9...",
  "tenant_id": "tnt_4f...",
  "operator": {
    "id": "okta:00u1abcd...",
    "email": "[email protected]",
    "ip": "203.0.113.42",
    "auth_method": "sso_saml+mfa_totp"
  },
  "endpoint": {
    "id": "dv_endpoint_8a...",
    "hostname": "lab-ws-014.eng.example.com",
    "device_groups": ["lab-equipment", "in-scope-soc2"],
    "os": "Ubuntu 26.04 LTS",
    "desktop": "GNOME 50 Wayland",
    "agent_version": "2026.04.3"
  },
  "authorization": {
    "rbac_policy_id": "pol_lab_eng_engineers",
    "permission_scope": "full_control_no_clipboard",
    "step_up_required": true,
    "step_up_method": "totp"
  },
  "session": {
    "started_at": "2026-05-03T03:12:44Z",
    "ended_at": "2026-05-03T03:21:08Z",
    "duration_seconds": 504,
    "scenario": "unattended_post_reboot",
    "endpoint_state_at_connect": "gdm_login_screen",
    "recorded": true,
    "recording_id": "rec_b7..."
  },
  "in_session_events": [
    {"t": "+00:08", "type": "shell_command", "cmd_hash": "sha256:..."},
    {"t": "+00:42", "type": "file_transfer", "direction": "to_endpoint", "name": "patch_apply.sh", "size_bytes": 2048, "sha256": "..."},
    {"t": "+04:15", "type": "reboot", "method": "in_session"},
    {"t": "+05:02", "type": "reconnect", "endpoint_state_at_connect": "gdm_login_screen"}
  ]
}

The exact field names and structure may evolve; the schema above represents the operational shape of the data, suitable for evaluation alongside SIEM ingestion mapping. Audit logs are exportable to Splunk, Elastic, Sumo Logic, Datadog, and any system that consumes JSON over HTTPS or syslog.

Threat model

What is defended, what is the operator's responsibility

DeviceView's unattended access is designed against a specific threat model. Naming what is and is not defended is more useful than a generic "secure" claim.

Defended by DeviceView's design

• Compromised end user. The end user does not hold an unattended-access credential, cannot grant unattended access to a third party, and cannot disable the agent without administrative privilege.
• Network attacker. All operator-to-control-plane and control-plane-to-agent traffic is TLS-encrypted. Agent connectivity is outbound-initiated; the endpoint does not expose an inbound port. Mutual TLS is used between agent and control plane.
• Stolen operator credentials without MFA. MFA at the IdP layer protects against pure-credential-theft attacks. Compromise requires both factor types.
• Operator overreach. RBAC enforces device-group and permission-scope boundaries. An operator cannot connect to a device outside their authorized groups regardless of intent.
• Audit-trail tampering by an operator. Operators cannot delete or modify their own session audit entries. Audit entries are append-only from the operator-facing API.
• Insider threat with full operator credentials. Session recording on compliance-scope devices provides a forensic record of in-session activity. Step-up authentication on sensitive actions adds friction and a paired audit event.

Operator-and-tenant responsibility

• Compromised IdP or root identity provider. DeviceView relies on the configured IdP for operator authentication. IdP compromise is an upstream incident; DeviceView's MFA and session-token lifecycle limit blast radius but do not prevent the initial breach.
• Endpoint OS-level compromise (root on the endpoint). An attacker with root on the endpoint can undermine the agent the same way they can undermine any system service. Endpoint security tooling (EDR, vulnerability management, MDM posture) is the right mitigation layer.
• Insider with both operator credentials and admin RBAC privilege. A super-administrator can edit RBAC policy and (on some configurations) tenant audit retention. Audit tamper-evidence and operational separation of duties are the right mitigations; the platform supports both but does not enforce them across tenant policy.
• Phishing of operator credentials with step-up bypass. MFA, especially phishing-resistant factors (FIDO2 / WebAuthn at the IdP), reduces but does not eliminate this risk.
• Endpoint physical access. DeviceView does not protect against an attacker who has physical access to the endpoint. Boot-loader, disk encryption, and BIOS/firmware controls are the right mitigations.

The threat model above is summarized; deeper detail and architecture diagrams are available under NDA for security-team review.

Wayland-specific

Three points that should land cleanly with a CISO

1. 01

   DeviceView does not require disabling Wayland.

   No WaylandEnable=false override. The default desktop on supported distributions runs Wayland as shipped; the agent operates inside the constraints Wayland's compositor enforces, not by routing around them.

2. 02

   DeviceView does not weaken Wayland's per-app input isolation.

   A second application running on the same endpoint cannot read keystrokes destined for the DeviceView agent or for any other application. The Wayland compositor's input scoping remains in effect.

3. 03

   The unattended consent decision is auditable and revocable.

   The enrollment that authorized unattended access is a recorded event, and the authorization can be revoked through the tenant policy or by removing the agent from the endpoint. There is no "silent permanent capability" granted by DeviceView's installation that would not appear in an audit review.

Compliance

Framework alignment

DeviceView does not certify the organization's compliance with any framework. The audit and access controls described above produce the kind of evidence that compliance teams typically map to specific control objectives in common frameworks. Aligning DeviceView's evidence to a framework is the customer's audit-team work; the table below identifies which DeviceView capability tends to map to which control category.

DeviceView markets HIPAA-aligned operator controls. DeviceView does not currently market FedRAMP Moderate / High or DoD IL4 authorization; federal evaluators should ask for the current posture before evaluation. ISO 27001 and SOC 2 Type II posture is available to customers under NDA.

Limitations

Called out

• DeviceView does not certify your compliance. The mapping above is operational; the audit work is yours.
• Threat model assumes endpoint OS integrity. A root-compromised endpoint is a separate security problem layered on top.
• Audit retention defaults vary by tier. Confirm the retention period that ships with your tenant matches your compliance-framework requirements; longer retention is configurable.
• Session recording can produce sensitive data. Recordings of medical, financial, or other regulated work can themselves become regulated artifacts. The decision of whether to record on which device groups should be coordinated with privacy and compliance counsel.
• End-user notification is configurable. What the end user sees during an operator session (banner, post-session notification, none) is controlled by tenant policy. Some jurisdictions and some collective-bargaining agreements require notification by law or contract; confirm with your privacy team.

FAQ

Security and compliance questions