Remote desktop requirements checklist for self-hosting

Remote desktop requirements checklist: how to use it before choosing a platform

The first decision is the access model, not the product. A team that needs to reach internal machines, and sometimes vendor machines, without a VPN or a SaaS remote tool should settle whether users will connect through a browser or install an agent. Apache Guacamole is clientless: users reach RDP, VNC and SSH hosts from an HTML5 browser, and the gateway sits between them and the targets. RustDesk is agent-based: the client runs on each endpoint and connects through ID and relay servers that the organization can host itself. Once that choice is made, the remaining rows of this checklist narrow quickly. Use it as a set of questions to answer with evidence from your own environment, not as a scoring sheet.

The checklist groups its rows into five areas: functional (protocols, attended and unattended sessions, browser or agent access, scale), security (MFA and single sign-on, session recording and audit, least-privilege connection permissions), integration (directory, ticketing, certificate and log tooling), operations (high availability, patching, backup, monitoring, handover) and compliance (which control IDs apply and what evidence an assessor will request). For each row, write down the answer, the owner and the proof. For example, an illustrative row might read: "Vendors must authenticate with MFA through our identity provider and every session must be recorded." The row is settled only when someone can show the MFA policy and a sample recording. Where a requirement depends on identity, check how the chosen identity layer, such as authentik, supports the provider types you need, and confirm the edition features with the vendor.

Functional requirements to settle first

This table lists the functional requirements to settle before choosing a self-hosted remote desktop platform, with why each matters and how to verify it. Read each row as a question to answer for your estate, then confirm the answer in a pilot against your own hosts rather than vendor claims. The main takeaway is that protocol coverage and access model drive the platform choice more than any other requirement.

Requirement	Why it matters	How to verify
Protocols needed (RDP, VNC, SSH, others)	Guacamole reaches each host through a guacd protocol plugin, and a protocol without a plugin needs one written before it can be published	Inventory every protocol in use, then confirm each one connects through a pilot against a representative host of each type
Browser versus agent access per user group	Browser access suits staff and vendors on unmanaged devices, while agent-based access suits attended support on managed endpoints	Map each user group to a required access mode, and test both paths from the devices those users actually use
Attended versus unattended sessions	Attended support needs a person to accept the session, while unattended access must work without anyone at the endpoint and needs stronger credential control	List which hosts need unattended access, then confirm the chosen tool supports that mode on each client operating system
Concurrent session count	Peak concurrency sets gateway sizing and licence tier, and it is often higher during incidents or term-time peaks than in daily use	Pull real session logs or estimate peak concurrency per group, then load test the gateway at that number in the pilot
Supported client operating systems	Users on Windows, macOS, Linux, iOS or Android may need different clients, and some agents are not available for every platform	List the operating systems in the user base, then confirm a working client and install path for each one
Hosts behind NAT or in segmented networks	Hosts without inbound reachability need an outbound path, relay or gateway placement, which changes firewall rules and the DMZ design	Map which hosts sit behind NAT or in separate zones, then test a connection from the outside through the intended path

Browser or agent access: which model fits which user group

Apache Guacamole is a clientless remote desktop gateway that supports standard protocols such as VNC, RDP and SSH and is used from any HTML5 web browser once installed on a server. Its web application, written in Java, provides the interface and authentication layer, and it forwards traffic to the guacd daemon, which loads protocol client plugins that connect to the target desktop or host on the user's behalf. This model fits internal staff reaching servers and admin consoles, and vendor support sessions where the supplier should not install anything on their laptop.

Endpoint requirements: Users need only a modern HTML5 browser. Nothing is installed on the user's device, and the target machines need their native RDP, SSH or VNC service enabled.
Relay path: The browser connects to the Guacamole web application over HTTPS, and guacd connects onward to the target. All sessions pass through a server you control, which is the point where you enforce policy.
Authentication: Guacamole's extensions cover Active Directory and LDAP, Duo and TOTP multi-factor authentication, OpenID Connect, SAML and smart card single sign-on, so MFA is enforced at the gateway.
Security review: Check the gateway's placement, the database backend for connection definitions and credentials, TLS termination, and the session recording extension and where its recordings are stored.
Scope limit: Protocols beyond those with a plugin are not reachable without writing one, so confirm that every target system's protocol is covered.

Confirm the exact plugin list and extension versions against the Guacamole manual before you commit to the design.

Security requirements that separate platforms

Remote desktop gateways concentrate privileged access, so the controls in front of a session matter as much as the session itself. The cards below cover the controls to settle before choosing Guacamole or RustDesk, and each one should come with a clear answer on how it is enforced and logged.

MFA on the gateway

Every browser session into Guacamole should pass a second factor before it reaches a target host. Guacamole's documented extensions cover Duo and TOTP multi-factor authentication, so check which factor your identity policy requires and whether it applies to every connection, including vendor accounts. For RustDesk, Server Pro Individual adds 2FA, but confirm whether it covers both administrators and end users. Ask how a failed or bypassed second factor is logged.

SSO with directory and federation

Central sign-on decides who can reach the gateway and how quickly access is removed. Guacamole's extensions cover Active Directory and LDAP, OpenID Connect, SAML and smart card login, so map each user population to one method. Confirm how group membership in the directory translates into connection permissions, and how a disabled account stops active sessions, not only new logins. Ask who owns the identity provider and whether it is inside the same trust boundary as the gateway.

Connection-level permissions and least privilege

Users should see only the hosts they need, with the protocol and account they are allowed to use. In Guacamole, permissions are assigned per connection and per user or group, so an administrator can grant a vendor one jump host and nothing else. Check whether permissions can be time-limited, whether shared accounts are avoided, and how privileged target credentials are stored. Ask the partner to show a test in which a user outside a group cannot discover that the host exists.

Encryption in transit and certificate management

The browser-to-gateway leg and the gateway-to-target leg both need encryption, and the HIPAA Security Rule's transmission security requirement at 164.312(e)(1) illustrates why auditors ask about it. Confirm which legs use TLS, which certificates are issued internally or publicly, and who renews them and how often. RustDesk relay traffic and self-hosted ID servers also need a documented key and certificate plan. Ask for a diagram that marks every encrypted hop and every point where traffic is decrypted.

Hardening and patch cadence

A remote access gateway is an internet-facing target, so its patch process is a security control in its own right. Confirm the upstream release cadence for Guacamole, the host operating system and the database backend, and agree who applies updates and how fast critical fixes are deployed. The authentik security policy gives a useful pattern: named supported versions and security releases announced at least 24 hours ahead. Ask for the hardening baseline and evidence that it is re-checked after each upgrade.

Acceptable-use controls for RustDesk

The RustDesk README states that its developers do not condone unauthorized access, control or invasion of privacy, which means the organization must supply every acceptable-use control itself. Decide which devices may install the client, whether unattended access is allowed, and how custom client builds are distributed and signed. Confirm that Server Pro's audit log and access control features record who connected to which device and when. Ask how the team detects an unapproved RustDesk installation on the endpoint estate.

Session recording and audit: what evidence must exist

Before you choose a gateway or relay, decide what a session record must prove. At minimum, each remote session should show who connected, which host they reached, when the session started and ended, how long it lasted, and what happened during it. Identity should come from the same source that enforces MFA, so the username in the log matches the account that passed the second factor. The host and time fields need to be reliable enough that an auditor can match a session to a change ticket or a vendor approval without guesswork.

Two candidate sources cover different parts of this. For Apache Guacamole, the session recording player extension is documented in the Guacamole manual, and it replays what happened on screen during a session. Confirm with your implementation partner whether recordings are written per connection, where they land on disk, and how they are protected from edits. For RustDesk, the audit log is a feature of RustDesk Server Pro, not the open-source server, so confirm the edition, the event types it captures and whether it records session content or only connection events. Whichever you use, test that an admin can export a single session's record and that the record survives a restart of the gateway.

Storage and retention are set by your own policy first and by any regulation that applies second. Recordings often contain sensitive data on screen, so plan encrypted storage, restricted read access and a deletion process. Two rules show how retention can be driven from outside. The HIPAA Security Rule's audit control requirement at 164.312(b) asks for mechanisms that record and examine activity in systems holding ePHI, and SEC Rule 17a-4(b)(4) requires broker-dealers to preserve certain communications for not less than three years. These are examples only, and whether either applies to you, and how far it reaches into remote session records, is a question for your counsel and compliance team. Record the retention period they confirm in writing before the first session is recorded.

Integration requirements with identity, ticketing and monitoring

A remote desktop gateway is only as controlled as the systems it trusts for identity, approvals, logging and inventory. List every system the platform must talk to before you select Guacamole or RustDesk, because each link carries an authentication, data or network decision that changes the design.

Directory integration

Decide which directory holds the accounts that will sign in: Active Directory, LDAP, or an OpenID Connect or SAML identity provider. Guacamole supports Active Directory and LDAP, plus OpenID Connect, SAML and smart card single sign-on through extensions, so confirm which of these your extension set covers and which group attributes map to connection permissions. Ask who owns group membership changes and how quickly a leaver loses access. Confirm whether the directory is reachable from the gateway's network zone.

Identity provider brokering

An identity provider such as authentik can sit between the directory and the gateway, handling login, multi-factor checks and policy in one place. authentik documents a remote access control (RAC) provider type, which is relevant if you want policy-based access to hosts published through Guacamole. Check which features your chosen edition includes, since the authentik pricing page places certain items such as privileged access management and enhanced audit logging in its Enterprise tier. Confirm the database and high availability design for the identity layer before it becomes a dependency for every session.

Ticketing links to each session

Require every remote session to reference an approved change, incident or support request. Decide whether the ticket reference is entered by the user at login, injected by the identity layer, or checked against the ticketing system before the connection opens. Define what happens when the ticketing system is unavailable, because an unclear default either blocks urgent support or allows unlogged access. Ask whether the session log can carry the ticket identifier so auditors can match recordings to approvals.

SIEM and log forwarding

Session start, stop, failed logins, permission changes and recording access should reach your security monitoring platform. Confirm which events each component writes, whether the gateway, the identity provider and the database each forward logs, and in what format. Set clock synchronization and retention in the log pipeline, not only on the gateway. HIPAA audit controls under 164.312(b) require mechanisms that record and examine activity in systems containing ePHI, so this integration is where that evidence is produced.

Asset inventory as publishing list

Only hosts recorded in an approved asset inventory should be published through the gateway. Decide which system is the source of truth, such as an ITSM configuration database, and how new hosts are added to the Guacamole connection list. Ask whether connection creation can be automated from that inventory and whether removed or decommissioned assets are unpublished automatically. Without this link, connection lists drift and stale entries to retired servers remain reachable.

Database backend for Guacamole

Guacamole stores users, connections and permissions in a database, with documented backends on MariaDB or MySQL, PostgreSQL and SQL Server. Choose the engine your organization already operates and can back up, patch and restore under its existing standards. Confirm that the database sits in the same network zone as the gateway, that its credentials are managed centrally, and that recording storage is sized and backed up separately from it. Changing engines later is a migration project, so settle this during selection.

Operational requirements and how to verify them

This table lists the operational requirements to settle before going live with self-hosted remote desktop, and the evidence that shows each one works. Read the verification column as the test you run, not the answer you accept on paper. The main takeaway is that a backup, a failover event and a runbook only count once someone has restored, failed over and followed the document under realistic conditions.

Requirement	What to settle	How to verify
Scale and peak periods	Expected concurrent sessions, peak windows such as shift changes or incident response, and whether the gateway and any relay servers are sized for that peak with headroom	Load test at the agreed peak, then confirm session limits, connection queuing and host resources (CPU, RAM, network) stay within targets you set in writing
High availability and failover	Which components are redundant (gateway, database, relay, identity provider), how users reach a standby, and the expected behavior of active sessions during a failover	Run a scheduled failover test with a named owner, record the time to resume service and the sessions lost, and repeat after each major change
Backup and restore of configuration and recordings	What is backed up (Guacamole database, connection definitions, authentication settings, RustDesk keys, session recordings), where copies live, and retention periods set by your policy	Perform a full restore into a separate environment, log in with a test user, confirm a known connection works and a known recording plays back, and time the procedure
Upgrade and security patch cadence	Which versions the vendor supports, how far in advance security releases are announced, and your change window and rollback plan	Ask for the written supported-version policy and notice period (authentik publishes both in its security policy), apply a patch in staging first and keep the previous image or backup ready for rollback
Dependency changes	Database and cache requirements, connection limits and any component removed or added between releases	Read release notes before each upgrade. For example, authentik's 2025.10 release notes say it no longer uses Redis and warn of roughly 50% more PostgreSQL connections, so check connection limits and capacity before upgrading
Monitoring and alerting	Health checks for the gateway, guacd, database and identity provider, session count, failed logins, certificate expiry and recording storage use	Trigger each alert on purpose (stop a service, fill a test disk, fail a login) and confirm the right person is notified within the window you agreed
Support hours and escalation	Support coverage hours, severity definitions, named escalation contacts, and whether vendor and implementation partner responsibilities are separate	Run a tabletop exercise with a simulated outage at an off-hours time and check that the on-call path reaches a responder who can act
Handover documentation	Architecture diagram, configuration inventory, credential ownership, restore and failover runbooks, and access revocation steps for departing staff or vendors	Have an engineer who did not build the system follow the runbook from start to finish in a test environment and record every gap they find

How to run the requirements check in four phases

This sequence turns open questions about hosts, users, vendors and controls into a signed requirements register that a partner can build and test against. Each phase produces an artifact that the next phase depends on.

Inventory hosts and protocols
Start by listing every system a remote user or vendor must reach: Windows and Linux workstations, servers, network appliances and any lab or clinical systems. For each host, record the operating system, the protocol it already accepts (RDP, VNC, SSH or a vendor agent), its network zone, and who owns it. Confirm which hosts can run an agent and which can only be reached through a gateway, since that determines whether browser access or agent-based access fits. The output is a host list with protocol, zone and owner columns. The step is done when the system owners have reviewed and signed off their rows.
Classify users and vendors by access path
Group everyone who needs access into classes such as employees, administrators, help desk staff, clinicians or lab users, and external vendors or managed service providers. For each class, record which hosts it needs, whether it connects from managed or unmanaged devices, how it authenticates today, and whether its sessions must be recorded or time-limited. Mark any vendor who needs approval before each session. The output is an access matrix that maps user classes to hosts, permitted protocols, authentication method and session rules. The step is done when each row has an owner who confirms it matches current practice or the intended design.
Run a pilot on real hosts
Deploy a small pilot on a limited set of production-representative hosts, using the access matrix as the test plan. Turn on MFA through your identity provider, enable session recording, and confirm audit logs capture who connected, to which host, and when. Test one vendor path end to end, including approval, access window and revocation at the end of the window. Record the results of each test case, including failures and workarounds. The output is pilot evidence: test cases, outcomes, recording samples and audit log extracts. The step is done when every mandatory requirement has a passing test or a documented gap with an owner.
Sign off the requirements register
Consolidate the host list, access matrix and pilot evidence into a single requirements register. Each requirement should state what must be true, which hosts and user classes it applies to, how it is verified, and the evidence that proves it. Circulate the register to the security owner, the compliance owner and the system owners, and ask each to approve it in writing. Any requirement that the pilot could not meet should be accepted as a documented risk or sent back for redesign before implementation begins. The output is a signed requirements register that becomes the input to the written, fixed-scope proposal. Ask any implementation partner to quote against this register, not against a general description of the product.

Remote desktop requirements questions buyers ask before hiring help

How long does the remote desktop requirements phase take?

The length depends on how much needs to be decided, not on the tool itself. The main drivers are the number of hosts that need remote access, the number of distinct access paths (browser users, technicians, vendors, unattended devices), and whether a regulation such as HIPAA, PCI DSS or a sector rule requires specific evidence for session recording, MFA and audit logs. A small set of hosts with one identity provider and one user group moves quickly. Estimates should come from a written scope that lists these inputs, and you should ask any partner to state the assumptions behind its schedule so you can see which one would change it.

What does a remote desktop requirements engagement cost?

Cost follows from the written scope, so a quote should list each deliverable, the hosts and access paths in scope, and the systems that must be integrated. The main cost components are the people who inventory systems, design the network placement and identity integration, and document the controls, plus any hardware, virtual machines or storage you buy. Software licenses are a separate question. For example, RustDesk's pricing page lists self-hosted RustDesk Server Pro Individual at $11.88 per month and Basic at $23.88 per month, billed annually, with the company stating that Pro is not a SaaS subscription. Ask each quote to separate one-time work from recurring license and support costs.

What does the client need to provide for a remote desktop project?

The work moves fastest when your organization provides four things before design starts. First, named owners for the gateway, identity, network and security decisions, each with authority to approve changes. Second, a host inventory listing every machine to be reached, its operating system, its owner and whether it is in a domain or workgroup. Third, access to your identity provider and group structure, so MFA and single sign-on can be designed against real groups. Fourth, change windows for the DMZ or firewall rules and for cutover on production systems. Ask your partner to confirm which of these it needs in writing and when.

Can our internal team deliver remote desktop without an implementation partner?

Many teams can, provided they have engineers who already run Linux servers, reverse proxies, identity providers and database backends. Guacamole combines a Java web application, the guacd daemon, protocol plugins, a database and optional identity extensions, so the design work covers more components than a single installer. RustDesk is simpler to stand up but still needs thought about relay placement, key management and client rollout. Assess your team against the specific tasks in the requirements, including hardening, backup, upgrades and evidence collection, and identify which tasks would fall to people who are already committed elsewhere. A partner can take the fixed-scope pieces while your staff keep ownership of operations.

How do I know whether Apache Guacamole or RustDesk fits my needs?

Guacamole fits when users need browser access to RDP, VNC or SSH hosts with no client installed, central permissions, and recording in the same gateway. RustDesk fits when the main need is attended or unattended remote support from a desktop client, with your own ID and relay servers. Guacamole's web application speaks only the Guacamole protocol and relies on guacd and protocol plugins, so a protocol outside the supported set requires a plugin. RustDesk's client and server are both AGPL-3.0, and its misuse disclaimer means you should define acceptable use and logging before rollout. Many regulated buyers evaluate both against recording, vendor access and network placement requirements.

What does authentik's free edition include, and what needs enterprise?

authentik's Open Source edition is free and most of its code is under the MIT license, but enterprise features sit in a separate directory under an enterprise license. According to authentik's pricing page, the Enterprise edition is listed at $5 per user per month billed annually plus $0.02 per external user per month. Features the page lists as enterprise-only include Google Workspace and Microsoft Entra ID integrations, mTLS client certificate authentication, privileged access management, password history and enhanced audit logging. Confirm with authentik which features your remote access design needs, especially audit logging for session evidence, and check the supported version list in its security policy before choosing a release line.

Which questions should I ask about security before choosing the design?

Start with the controls your regulator or customer requires, then map each to a design decision. Ask where MFA is enforced, whether the gateway sits in a DMZ, how session recordings are stored, how long they are kept and who can read them. For HIPAA, the Security Rule at 45 CFR 164.312 requires transmission security for ePHI and audit controls that record activity, so ask for evidence of both. Ask the partner to show how access is granted per vendor and revoked at contract end, and how the gateway itself is patched. Written answers to these questions form the core of the requirements document.

Questions that separate platforms and partners

The answers to these questions decide the architecture more than feature lists do. Ask vendors and implementation partners for written answers before you settle the design, because each answer changes where the gateway sits, what you must build yourself, and what evidence you can produce later.

How the access path is isolated

Ask where the gateway, the guacd daemon or RustDesk relay sits relative to your network zones, which ports cross each boundary, and whether any inbound connection reaches internal hosts directly. Guacamole's web application speaks only the Guacamole protocol and hands sessions to guacd, so the placement of those two components decides which hosts are exposed. Ask the partner to show the proposed DMZ layout and the firewall rules in writing, and to state whether the design depends on a VPN, a reverse proxy or an identity-aware front end.

Native controls versus add-ons

Separate what ships in the core from what requires an extension or a paid license. Guacamole documents Active Directory and LDAP, Duo and TOTP, SAML, OpenID Connect and smart card extensions, each with its own configuration and support burden. RustDesk Server Pro features such as 2FA, audit logs and OIDC or LDAP integration sit in paid tiers, while the open-source server does not include them. Request a control-by-control matrix that marks each requirement as native, extension, add-on license or custom work, with the version it was tested against.

What is logged and where

Ask which events are recorded (logins, failed authentications, connection starts and ends, permission changes, clipboard or file transfer activity), where those logs are written, and whether they reach your SIEM in a form you can query. HIPAA's audit control requirement at 45 CFR 164.312(b) expects activity in systems holding ePHI to be recorded and examined, so a log that exists but cannot be searched does not meet the need. Confirm the log format, time synchronization, and whether administrators can alter or delete entries.

How recordings are stored and purged

Session recordings often contain credentials, customer data and screen content, so their storage location, encryption, access list and deletion process matter as much as the capture itself. Ask who can replay a recording, whether replay access is logged, how retention periods are set per connection or per group, and how a purge is verified. Where a regulation sets a minimum retention period, such as the three-year preservation requirement for certain broker-dealer communications in 17 CFR 240.17a-4, confirm which records are in scope before you set a purge schedule.

How upgrades and security fixes arrive

Ask which versions receive security fixes, how much notice you get before a security release, and whether fixes come as a documented patch or a feature release you must test in full. authentik's security policy lists the supported versions and states that security releases are announced at least 24 hours in advance, which gives you a concrete benchmark for the question. For Guacamole and RustDesk, ask who tracks upstream advisories, who applies them to your gateway, and how the partner proves a patched build was deployed to every node.

What handover looks like

Handover decides whether your team can run the platform after the engagement ends. Ask for the runbooks covering backup and restore of the configuration database, certificate rotation, user and connection provisioning, recording retention, and incident response, together with the list of accounts and secrets the partner created and how each one is transferred. Request a named test restore or a walkthrough of a recovery exercise in the written scope, and confirm what support continues after handover and under which retainer terms.

How DeployOpen turns this checklist into a fixed scope

The checklist is the input to scope, not the scope itself. Each answer you settle on protocols, browser versus agent access, MFA and SSO, session recording, vendor access, network placement, scale and support becomes a line in a requirements register. That register records the owner of each decision, the evidence it must produce and the open questions still blocking it. DeployOpen uses it to write a fixed-scope proposal, so the deliverables and timelines are agreed in writing before any build work starts. A quote follows from that written scope, and the register is the document you should hold us to.

Work usually runs in stages that map back to the checklist. A pilot on a small set of hosts tests the gateway or relay design, the identity provider integration and the recording path before anything is widened. Implementation then covers the chosen components, whether that is Apache Guacamole with its guacd daemon and authentication extensions, or a RustDesk ID and relay deployment, along with connection permissions and network placement. Hardening, testing and handover follow, with configuration, runbooks and evidence documentation delivered to your team. Ask each proposal to name the owner of every stage, the test cases for each requirement and what is handed over at close.

DeployOpen plans, implements, integrates, hardens and supports self-hosted platforms inside your own cloud accounts, data centers or disconnected networks. For compliance, we prepare the systems, controls and evidence that an assessor will examine, such as access logs, MFA configuration and session records, but we do not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Before you request a quote, confirm which assessor will review the environment, which controls your regulator or customer expects, and who in your organization owns the evidence after handover.

How DeployOpen scopes and delivers remote desktop requirements

DeployOpen turns remote desktop requirements into a written scope before any build starts, then implements, hardens and documents the chosen gateway inside your own infrastructure. The work covers protocols, identity, recording, network placement and handover, and it is delivered as a fixed-scope engagement with optional ongoing support.

How we scope

We map each access group, target system and protocol (RDP, SSH or VNC) to a written requirement list.
We confirm the identity source, MFA method and session recording rules before any design work starts.
Scope, deliverables and timeline are agreed in writing, with the out-of-scope items named explicitly.
We confirm whether Apache Guacamole, RustDesk or both fit the access pattern, and record why.

How we build

We deploy the gateway or relay in the network zone you specify, including DMZ or air-gapped placement.
We integrate SSO, MFA and connection permissions against your directory and access policy.
We configure session recording, audit logging and retention to match your record-keeping duties.
We test each requirement on the checklist and record the result against the written scope.

How we hand over

We document the architecture, network flows, configuration keys and access-approval steps for your team.
We deliver runbooks for adding users, revoking vendor access and restoring the service from backup.
We map each implemented control to evidence your auditors or assessors can review, without claiming certification.
We walk your operations staff through monitoring, patching and recording review before closing the engagement.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers cover component upgrades, security fix application and periodic access reviews, as agreed in writing.
Security testing of the remote access path can be scheduled as a separate, scoped engagement.
Ask any partner, including DeployOpen, to confirm response expectations and escalation paths in the written agreement.