Self-hosted remote support for IT helpdesks

The evidence comes from the RustDesk Server Pro audit log, which is included in the Individual plan and the higher tiers, and it should record which login user opened a session to which managed device and at what time. Auditors usually want a single export that ties a session start and end to a named technician and a named endpoint, so confirm that the log captures both ends of the connection and the device identifier, not only the login event. Keep the device inventory in your endpoint management or ITSM records so that a device ID in the log can be matched to an asset owner. Ask your implementation partner to show a sample export during handover, and to confirm how long the log is kept on the server before it is archived.

Authentication evidence sits in two places: the RustDesk Server Pro web console, which offers 2FA on the Individual plan and above, and your identity provider, which should be the system of record for who the technician is. The Basic plan adds OIDC single sign-on and LDAP integration, so the technician's identity can come from your directory rather than a local account. Your identity provider logs should show the MFA method used at sign-in, such as a hardware key, an authenticator app or a push approval, and the timestamp. Shared technician accounts make this question impossible to answer, so each technician needs an individual login. Confirm with your identity team which MFA methods are enforced and whether the identity provider log retention matches your audit window.

RustDesk session logs establish that a connection happened, but they do not by themselves describe every change made on the endpoint. To show what changed, combine the session record with endpoint management records, such as software installation logs, configuration change history and privileged command logs from the operating system or your endpoint management tool. Session recording, where enabled and permitted by your policy, can give a reviewer the visual record of a session, but recording storage and consent rules need to be set before the first session. Ask your partner to document which changes are expected in a support session, which are out of scope, and how a technician records the ticket number that justifies the session. Confirm the recording and retention settings with your privacy and legal teams before enabling them.

The retention period depends on the rule that applies to your organization, and no single period applies to every remote support log. For a HIPAA-covered entity, the Security Rule at 45 CFR 164.312(b) requires audit controls that record and examine activity in systems containing ePHI, and your documented retention policy should state how long those records are kept. For broker-dealers, SEC Rule 17a-4(b)(4) sets a minimum of three years for certain business communications, which may or may not cover support session metadata depending on how your counsel reads it. Set the retention in your log archive, not only on the RustDesk server, and confirm with your compliance team which rule governs the logs before choosing a number. Review the eCFR text for 45 CFR 164.312 and the audit scope with your counsel.

Revocation should happen in the identity provider first, then the RustDesk access control settings, and the evidence should show both steps with timestamps. If the technician signs in through OIDC single sign-on or LDAP, disabling the account in the directory stops new sign-ins, but existing sessions and any locally created accounts must also be checked on the RustDesk side. The access control features in Server Pro are the place to remove group membership and device permissions, and the audit log should show the last session before removal. Include the offboarding step in your joiner, mover and leaver process so that the ticket, the directory change and the console change are linked. Test the process with a non-production account before the first real offboarding, and ask your partner to document the steps in the runbook.

Prepare a short evidence pack that maps each question to a source: the Server Pro audit log export, identity provider sign-in and MFA records, endpoint management change history and the retention policy. Auditors will test whether the records are complete, unaltered and available for the required period, so store exports in a write-protected location with access limited to the security team. Make sure the team can explain which events are not logged, such as actions taken outside the RustDesk session, and document compensating controls for those gaps. Ask your implementation partner to prepare the evidence walkthrough and the control mapping as part of handover, and confirm with your independent auditor which format they accept. DeployOpen prepares systems, controls and evidence for compliance assessments, but audit outcomes come from independent auditors and certification bodies.

Blocking unauthorized remote access tools is an endpoint control, and its evidence comes from your endpoint management platform rather than from the RustDesk server. Application control or allowlisting reports should show which remote tools were blocked, which devices reported the block, and when the policy was last applied. The RustDesk logs will show only sessions made with your approved client, so they cannot prove that a competing tool was absent from the estate. Pair the endpoint report with a periodic software inventory and reference the CISA guidance on remote tools when you describe your approach to the auditor. Confirm with your security team which blocking method your endpoint platform supports before writing the control into policy.

The cost is made of five parts: server infrastructure for the ID and relay services, RustDesk Server Pro licenses if you need audit logs and access control, implementation and hardening, endpoint deployment of the client, and ongoing operations. The open-source server is free to download under AGPL-3.0, so the recurring spend is mainly hosting, licenses and staff time. RustDesk publishes Server Pro prices, which are listed in the next answer. Ask any partner to split the quote into these five lines so you can see who is paid for what.

RustDesk's pricing page lists Server Pro plans billed annually. The Individual plan is listed at $11.88 per month for 1 login user and 20 managed devices. The Basic plan is listed at $23.88 per month for 10 login users and 100 managed devices, with unlimited concurrent connections. Customized plans add users at $1.20 and devices at $0.12 per month on top of the Basic base price, according to the same page. RustDesk states that licenses do not auto-renew and that Pro is not a SaaS subscription. Confirm current prices and tax treatment on the vendor's pricing page before budgeting.

One-time costs usually include design, the first installation of the ID and relay servers, identity integration, hardening, and the initial rollout of the client to endpoints. Recurring costs include hosting for the servers, Server Pro license renewals if you buy them, patching and upgrades, backups, monitoring, and the staff time that keeps the helpdesk process working. Because RustDesk licenses are annual and do not auto-renew, plan a renewal line in the annual budget. Ask the partner to label each line in the quote as one-time or recurring.

Four factors move the cost most:

• Device count, since Server Pro plans are sized by managed devices and login users, and larger fleets need the Basic tier or customized plans.
• Identity integration, such as OIDC single sign-on or LDAP, which is available in the Basic tier and requires identity admin time to configure.
• Relay placement, because relay servers in several sites or zones add hosts, bandwidth and firewall work.
• Audit and retention needs, which increase storage and review effort.

Fewer devices, a single identity source and one relay location keep the cost lower.

A capable IT team can install the open-source server, which builds the hbbs ID and rendezvous service, the hbbr relay service and the rustdesk-utils command-line tools. The harder parts are the ones that carry risk: placing the servers in the right network zone, securing the key and port configuration, connecting identity, enforcing MFA, and building the audit trail that the open-source server does not provide on its own. RustDesk's documentation describes a migration path from the open-source server to Server Pro through its install script. Decide which of these tasks your team can own and which need outside help.

Duration depends on scope rather than a fixed number of weeks. A pilot for a small helpdesk with one site, one identity source and a limited device group is shorter than a rollout across several sites with relays in each zone, SSO, and an audit review. No timeline is published here for DeployOpen work, so ask for a timeline in the written, fixed-scope proposal that names the phases, the dependencies and the client tasks. Agree the pilot exit criteria in writing before the work starts.

The client's side of the work usually includes:

• An identity administrator who can create service accounts, connect OIDC or LDAP and set MFA policy.
• Network changes, such as firewall rules and public or internal addresses for the ID and relay servers.
• Endpoint management access, so the client can be deployed to managed devices through your existing tooling.
• A named owner for approvals, helpdesk procedures and retention decisions.

Identify these owners before the proposal is signed, because delays here often set the pilot length more than the software does.

Ask for a written, fixed-scope quote that lists the devices and users in scope, the server topology, the license tier and its annual renewal date, the identity integrations, the hardening and audit configuration, the endpoint rollout method, the handover documentation, and any ongoing support or retainer. Ask which items are one-time and which recur. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and it does not publish a price list, so the quote follows from the written scope.