Remote desktop RFP questions for implementation partners

Remote desktop RFP questions to ask before you hire a partner

If you are shortlisting partners to deploy browser-based access on Apache Guacamole or agent-based access on RustDesk inside your own infrastructure, your remote desktop RFP questions should do more than confirm that a firm has installed these tools before. Send the same written questions and the same scope to every bidder, require answers in writing, and score each answer against criteria you set before the responses arrive. The questions below are vendor-neutral. They work whether you end up with Guacamole, RustDesk, or a combination, and they should be checked against a reference design built for your own network, identity provider and compliance obligations rather than accepted at face value.

Start with architecture and identity, because most later answers depend on them. Ask where the Guacamole web application, the guacd daemon and the database sit relative to your DMZ, which ports and directions each tier needs, and how the design handles the RustDesk ID and relay services (hbbs and hbbr) if you choose that path. Ask how each partner will integrate authentication: which Guacamole extensions they would enable for Active Directory or LDAP, SAML, OpenID Connect or multi-factor authentication, and whether they would place an identity provider such as authentik in front of the gateway. Require them to name the protocols they will support on day one and to state what a new protocol would require. A strong answer names the components and the trust boundaries between them. A weak one only lists product features.

Then press on recording, hardening, high availability, monitoring and handover. Ask where session recordings are stored, how long they are kept, who can read or delete them, how they are encrypted and how they are backed up, and which retention period your own regulator or contract requires. Ask which hardening baseline they apply, how they will rotate secrets and database credentials, and how they will keep the platform patched. Ask what high availability means for their design, and whether it has been tested by failing over a component. Finally, ask what monitoring and audit logs they will deliver, and what documentation, runbooks and knowledge transfer you receive at the end. Confirm current versions and release schedules with each vendor, since these change often.

Architecture, DMZ placement and identity questions to put to partners

Where should a Guacamole or RustDesk gateway sit relative to the DMZ and internal networks?

Place the gateway in a DMZ or a tightly restricted network segment so that vendors and staff reach it first, and it reaches target systems through specific, documented firewall rules. A good answer names every inbound and outbound flow: which ports open from users to the web application, how the web application reaches guacd, and which target protocols (RDP, SSH, VNC) guacd may open toward which subnets. The partner should also explain whether the database and identity provider sit inside the trusted zone and how they are reached. Verify the flow list against your own firewall policy and have the partner demonstrate that a blocked target stays unreachable. Guacamole's architecture is documented in its Guacamole manual, which the partner should use as the baseline for component placement.

How should MFA and single sign-on be wired into a Guacamole deployment?

The partner should choose one primary identity source, connect it through a supported extension, and enforce a second factor at the gateway rather than trusting the browser alone. Guacamole's extensions cover Active Directory and LDAP, Duo and TOTP, OpenID Connect, SAML and smart card single sign-on, so the answer should name the extension, its version, and the attributes used for group mapping. Ask how Entra ID or LDAP groups map to Guacamole connection permissions, and how a user who leaves the directory loses access. Verify by testing a disabled account, a user without the MFA enrolment, and a group change, and confirm each result in logs.

Does an authentik RAC provider add policy control in front of Guacamole?

authentik can act as the identity layer and offers a remote access control (RAC) provider type, which lets it broker sessions with policy checks before the user reaches a published host. This is one identity pattern among several, not a requirement. The partner should explain which policies gate access, how sessions are authorized, and whether the gateway and authentik are both needed for recording. authentik's own pricing page lists mTLS client certificate authentication and privileged access management as Enterprise features, so confirm those against the edition quoted before relying on them. Check the authentik providers documentation and test a policy denial end to end.

What should a partner answer about recording storage and retention?

A strong answer states where session recordings are written, how they are encrypted, who can read them, and how long they are kept, with the retention period set by your own policy rather than the vendor default. It should also cover storage capacity, backup, and deletion at the end of the retention window. Regulated sectors often tie retention to specific rules: for example, 17 CFR 240.17a-4 requires broker-dealers to preserve certain business communications for at least three years, and that scope must be confirmed with your compliance counsel before it is applied to session logs. Ask the partner to demonstrate a recording being written, retrieved by an authorized reviewer, and removed on schedule.

How should hardening and patching of the gateway be scoped and tested?

The partner should describe a hardened baseline covering the operating system, container or native install, TLS configuration, database access, and service accounts, plus a documented patch process. Ask which components are updated, how often, and how a security release is applied without an outage. For authentik, the project's security policy lists supported versions and says security releases are announced at least 24 hours in advance, which your change process should account for. Verify with a configuration review, a scan of exposed ports, and a documented rollback test on a staging copy.

What does high availability look like for a Guacamole or RustDesk deployment?

High availability depends on which component fails. The partner should separate the web application, guacd instances, the database, the identity provider, and for RustDesk, the rendezvous (hbbs) and relay (hbbr) services. A good answer names the redundancy for each, the failover method, and the expected impact on active sessions. RustDesk's open-source server runs hbbs and hbbr as separate services, so ask how relays are placed and how clients are pointed at them. Ask for a written failover test plan and run it: stop one node, measure reconnection, and record which sessions drop.

Which monitoring and audit signals should be in place before go-live?

The partner should list the signals collected: authentication successes and failures, MFA events, session start and end, connection targets, recording jobs, service health, and database connection counts. Ask where logs are shipped, how long they are kept, and how alerts reach your security team. For authentik upgrades, the 2025.10 release notes warn of roughly 50% more PostgreSQL connections, so the partner should test connection sizing on a staging system before production upgrades, then confirm headroom in your own environment. Verify by generating a failed login and a session, then confirming both appear in your monitoring platform.

What should handover include so the internal team can run the platform?

Handover should deliver the architecture diagram, firewall flow list, configuration with secrets managed in your vault, runbooks for backup, restore, patching, user onboarding and offboarding, and an incident contact path. It should also name who owns each component after the engagement and what support is available under a separate retainer. Ask the partner for a restore test performed by your staff, not only the partner, and confirm which documents are delivered in writing. The scope, deliverables and timelines of DeployOpen engagements are agreed in writing before work starts, so request the handover list as part of that scope.

Which questions change between Guacamole and RustDesk

Guacamole is a clientless gateway: users reach RDP, VNC and SSH hosts from an HTML5 browser, and the web application hands sessions to the guacd daemon, which loads the protocol plugins. The RFP questions for Guacamole focus on how that gateway is placed, how users authenticate, and where session evidence is kept. Because the web application and guacd are separate components, the partner should explain how they are deployed and which network paths each one needs.

Browser access and placement: Ask which components sit in the DMZ, which reach internal hosts, and how guacd connections are restricted to approved targets.
MFA and SSO extension choice: Ask which extensions are proposed for Active Directory or LDAP, Duo or TOTP, SAML, OpenID Connect or smart card login, and how each one is tested before cutover.
Session recording player: Ask where recordings are written, how the player extension is secured, who can replay sessions, and how long recordings are kept.
Database backend: Ask whether the connection and permission store runs on MariaDB or MySQL, PostgreSQL or SQL Server, who manages backups, and how the database is restored.
Protocol plugins: Ask which protocols are in scope and whether any host needs a protocol that is not covered by the standard plugins.

Ask the partner to show which of these questions change their recommended design, and to name the extensions and database they would deploy.

Partner answers that should end the shortlist

A partner's answers to these questions show whether it can carry the work through an assessment and into daily operation. The cards below cover the answers that should move a vendor off the list, whether the issue is scope, evidence, retention, compliance claims, hardening or handover.

No written scope or fixed deliverables

A proposal that describes the work only as a set of hours or a general plan leaves you paying for uncertainty. Most engagements are fixed-scope, so a credible bid names the gateway or relay components, the protocols, the identity integration, the recording design, the hardening baseline and the acceptance tests in writing before work starts. Ask for the deliverable list and the acceptance criteria for each one, and confirm what is excluded, such as end-user onboarding or vendor-side tooling.

Promises of audit or certification outcomes

A partner can prepare systems, controls and evidence for a compliance assessment, but it cannot issue an audit report, attestation or certification, and neither can anyone who claims otherwise. Treat a guarantee that a deployment will pass a named assessment as a warning sign. Ask instead which evidence the partner will produce, such as configuration baselines, access reviews and session logs, and which independent assessor will review it.

No recording retention plan that fits the rules

Session recordings are often the evidence a regulator or assessor asks for, so retention is a design decision, not a storage setting. Ask how long recordings are kept, where they are stored, who can view or delete them, and how that schedule maps to the rules that apply to your organization. For example, SEC Rule 17a-4(b)(4) sets a three-year preservation period for certain broker-dealer communications, which a partner should confirm applies to your records before setting a default.

Flat claims of out-of-the-box compliance

No open-source remote access product is compliant on installation. Compliance depends on how the gateway is placed, how MFA is enforced, how permissions are scoped, how logs are kept and how the environment is operated. A partner that says a product is compliant as installed has not reviewed your obligations. Ask it to map each requirement to a configured control, an owner and a piece of evidence, and to name the requirements it will not cover.

No hardening or patch cadence

A remote access gateway is an internet-facing or DMZ-facing system with privileged reach into internal hosts, so it needs a documented hardening baseline and a patch process. Ask what the partner changes from default settings, how it tracks security releases for Guacamole, guacd, the database, the identity provider and the operating system, and how quickly it applies them. Ask for the cadence in writing, including how emergency fixes are handled and tested.

Unattended RustDesk access without a misuse answer

RustDesk offers attended and unattended control, and its README carries a disclaimer that its developers do not condone unauthorized access, control or invasion of privacy. A partner recommending it for unattended access should explain how the self-hosted ID and relay servers are locked down, how Server Pro features such as 2FA, access control and the audit log are configured, and how unknown devices are blocked. If the answer is only that it works out of the box, keep looking.

Refusal to hand over documentation

If a partner will not provide architecture diagrams, configuration records, runbooks, recovery procedures and an operating handover, you cannot run or audit the system after the engagement ends. Ask for these artifacts as deliverables in the written scope, with named owners and a handover acceptance step. The partner should also confirm that your team can operate the platform without it, including how backups and restores are tested.

How to score partner responses consistently

This sequence gives every implementation partner the same scope and questions, then turns their answers into comparable scores backed by written evidence. The result is a shortlist you can defend on architecture, identity, recording and handover, not on sales presentation.

Issue one scope and question set
Send every shortlisted partner the same written scope, with the chosen platform (Guacamole, RustDesk or both), target protocols, user groups, vendor access cases, network zones and the question set from this page. Include the industry constraints that apply to you so partners price and design against the same facts. Name one owner on your side who answers clarifying questions, and share every answer with all partners. The step is done when each partner confirms in writing that they received the identical package.
Request written answers with evidence
Ask each partner to answer every question in writing and attach evidence for each claim, such as a reference architecture diagram, a sample hardening baseline, a sample recording retention configuration or a runbook extract. Ask them to state which items are included in a fixed-scope offer and which would be quoted separately. Mark any answer that is a promise without an artifact as unverified. The step is done when each response is complete, or its gaps are listed in writing.
Run the scripted DMZ and recording call
Hold the same scripted call with each partner, covering DMZ placement, the path from the user through the gateway or relay to the target hosts, and where session recordings are stored and for how long. Ask each partner to draw the data flow live and to explain which component holds credentials and which holds recordings. Use the same follow-up questions for every partner and note answers verbatim. The step is done when your reviewers have a signed-off note per partner on network placement and recording design.
Score each answer against fixed criteria
Before reading the responses, agree on a scoring sheet with weighted criteria for architecture, identity integration, recording storage and retention, hardening, high availability, monitoring and handover. Score each answer on the same scale, citing the evidence that supports it, and record any score that rests on a claim alone. Have two reviewers score independently, then reconcile differences in a short meeting. The step is done when every partner has a scored sheet and each disagreement between reviewers has a recorded resolution.
Request a reference design and test plan
Ask the top-scoring partners for a reference design tailored to your environment and a test plan that covers authentication, session recording, failover and access revocation. Ask for the test cases, expected results and the owner of each test. Compare the designs against the same network and identity assumptions you gave in the first step. The step is done when each shortlisted partner has delivered both documents and you have confirmed the test scope in writing.
Confirm the final selection in writing
Review the scored sheets, reference designs and test plans together, and document the reason for the chosen partner against the criteria. Confirm the scope, deliverables, handover items and any ongoing support terms in the written agreement before work starts. Keep the scoring record with your procurement file so the selection can be explained later. The step is done when the signed scope matches the design and test plan that won the evaluation.

Scoring criteria for remote desktop partner answers

This table lists the areas a buyer should score when comparing partner answers for a Guacamole or RustDesk implementation, with what full marks look like and the evidence to request. Weights are set by the buyer, so treat the suggested values as a starting point and adjust them to your risk profile. The main takeaway is that architecture, identity and recording are where weak answers most often hide gaps.

Area	What full marks require	Evidence to request	Weight
Architecture and DMZ	A written data flow showing where the Guacamole web application, guacd and any RustDesk hbbs and hbbr services sit, with only the required ports open between zones	Network diagram, firewall rule list, statement of which hosts hold credentials and session data	Suggested: high
Identity and MFA	Login through your directory (LDAP, SAML, OpenID Connect or smart card) with MFA enforced at the gateway, not only on the target host	Test results for each login path, MFA enrollment and fallback procedure, list of extensions and versions in use	Suggested: high
Recording and retention	Session recording on by default for privileged sessions, stored in a location the gateway admins cannot silently alter, with a retention period set by your policy	Recording storage design, retention and deletion settings, sample recording review, access log for recording viewers	Suggested: high
Hardening	Documented baseline for hosts, containers and database, least-privilege service accounts, and removal of unused protocols and features	Hardening checklist mapped to your standard, scan results before go-live, change control for later updates	Suggested: medium
High availability	Defined failure modes for gateway, database, relay and storage, with tested failover and a stated recovery approach	Architecture for redundancy, failover test report, backup and restore test record	Suggested: medium
Monitoring	Alerts on failed logins, new connections outside approved windows, service health and recording pipeline failures	Monitoring design, sample alert rules, log forwarding target, named owner for alert response	Suggested: medium
Handover and support	Runbooks, admin training, version upgrade procedure and a clear split of responsibilities after go-live	Runbook index, training outline, upgrade plan, written support scope and response model	Suggested: medium

How regulated buyers should frame recording and audit questions

Recording and audit questions should start from the rules your organization must meet, not from what a gateway happens to log by default. Ask each bidder to show which session events are captured (connection start and end, authentication outcome, the target host, the user identity and any privilege changes), where those records are stored, who can read or alter them, and how long they are kept. If your firm is a broker-dealer, check whether the communications in scope fall under SEC Rule 17a-4(b)(4), which requires preserving originals of certain business communications for not less than three years. Session recordings are not automatically communications under that rule, so confirm the classification with your compliance counsel before you set a retention period in the RFP.

For healthcare and other ePHI environments, two requirements in 45 CFR 164.312 shape the questions. Section 164.312(b) calls for audit controls that record and examine activity in systems containing ePHI, so ask how the Guacamole audit trail or the RustDesk Server Pro audit log feeds your central log platform and how review is scheduled. Section 164.312(e)(1) calls for technical measures that guard against unauthorized access to ePHI sent over a network, so ask how the browser-to-gateway and gateway-to-target links are encrypted, which protocol versions are enforced and who holds the certificates. Read the regulation text yourself at 45 CFR 164.312 on eCFR before you write these into the requirements.

A partner prepares the controls, configuration and evidence described above, but does not certify that your environment is compliant. Your auditor or regulator decides whether the design and retention settings are adequate for your obligations. Ask the partner to name the evidence it will hand over at handover, such as configuration exports, retention job settings, sample audit records and a test of recording playback, and ask who at your organization owns each item afterward. Keep the audit questions in the RFP tied to these named artifacts so that the bid responses can be checked against your auditor's list rather than against marketing claims.

How DeployOpen scopes and delivers remote desktop evaluations

DeployOpen answers remote desktop RFP questions by first agreeing on a written scope covering architecture, identity, recording, hardening and handover, then building and testing the chosen platform inside your own infrastructure. Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we scope

We confirm which protocols, hosts and user groups the gateway must reach before any design work starts.
We document the DMZ or network placement, firewall flows and identity provider the written scope depends on.
We agree recording storage, retention periods and who can review sessions as part of the written scope.

How we build

We deploy Apache Guacamole or RustDesk servers in your cloud accounts, data centers or air-gapped networks.
We integrate SSO, multi-factor authentication and connection permissions according to the scope agreed with your identity team.
We test session recording, failover behavior and hardening settings, and record the results as evidence for your review.

How we hand over

We deliver configuration documentation, runbooks for routine administration and a record of what was tested.
We walk your operations and security staff through access reviews, recording retrieval and incident procedures.
We document the controls and evidence prepared for your compliance assessors, who issue any audit reports or certifications.

How we support

Ongoing support, upgrades and continuous security testing are available as retainers after handover.
We can plan upgrades and patch cycles for the gateway, its database and the identity components it depends on.
Ask any partner to confirm response expectations and service levels in writing before you sign a retainer.

Remote desktop RFP questions