Self-hosted remote desktop for financial services

Self-hosted remote desktop for financial services: why the design starts with supervision and vendor access

A trading desk, an analyst group or an outsourced support team in a bank or insurer needs remote access now, and the tool is rarely what decides whether that access will pass review. MFA, session recording, segregation of privileged access and DORA-compliant vendor terms matter more than the platform choice. Those four decisions determine who can reach which system, how each session is evidenced and what the institution can demand from a provider if the arrangement fails. Choose the tool after those answers are written down.

Apache Guacamole and RustDesk fit different parts of the workforce. Guacamole is a clientless gateway: staff and vendors reach RDP, SSH or VNC hosts from a browser, the web application handles authentication and the guacd daemon brokers the protocol, and a session recording player extension is available. That suits employees on managed workstations and named vendor engineers who should never hold a copy of the software. RustDesk is agent-based and fits attended support where a person on the other end needs to be connected to a desktop quickly. Its open-source server runs as hbbs and hbbr, while Server Pro adds audit logging, 2FA and OIDC or LDAP integration. Confirm with the vendor which of those features your license tier actually includes before you rely on them.

The design is driven by regulation, not by the tool. Ask your compliance team which obligations apply to each population: DORA's contract requirements for ICT third parties, the record-keeping rules that apply to supervised communications and the MFA expectations in your jurisdiction. Then map each population to a gateway, a recording policy and a named owner. Illustratively, a 'vendor support' group that cannot be recorded or traced to an individual account is a finding waiting to happen, whichever product sits in front of it.

Which financial services rules shape the remote desktop build

This table maps each financial services rule to what it means for session recording, gateway placement, vendor contracts and access reviews in a self-hosted Guacamole or RustDesk design. Read each row as a question to answer with your compliance and legal teams, because several rules apply only when your entity or data falls within their scope.

Rule or framework	What it asks for	Build impact on remote desktop	Scope note
SEC Rule 17a-4(b)(4)	Preserve originals of business communications and copies of those sent, including inter-office communications, for not less than three years.	Session recordings and chat or support notes that record business communications must be retained on write-protected storage with a defined retention period. Confirm with counsel whether a remote session is a communication under your records policy.	Applies to broker-dealers subject to the rule.
FTC Safeguards Rule, 16 CFR 314.4(c)(5)	Require multi-factor authentication for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing.	Place MFA on the Guacamole login or RustDesk Server Pro console for every user, including vendor accounts. Record any written exception and its compensating control.	Applies to non-bank financial institutions under FTC jurisdiction.
DORA Article 28(3)	Maintain a register of information on all contractual arrangements for ICT services.	Each remote support vendor, its accounts, the systems it reaches through the gateway and its contract reference must appear in the register. Keep the gateway's connection inventory aligned with it.	Applies to the 20 financial entity types in scope of DORA, including insurers and payment institutions.
DORA Article 28(8)	Document and test exit strategies and transition plans for ICT services that support critical or important functions.	Design vendor access so it can be removed in one place: disable the vendor account, revoke gateway connections and rotate any shared secrets. Test this revocation as part of the exit plan.	Applies where the remote access supports a critical or important function.
DORA Article 30(2)	Require ICT contracts to state where services are provided and data processed, give advance notice of changes, and cover data return on insolvency or termination.	Specify in vendor contracts that session recordings and logs are stored in named locations, and that they are returned or deleted at exit. Restrict vendor-side copies of recordings.	Applies to ICT services contracts within DORA scope.
Swift Customer Security Controls Framework, MFA and attestation	Independent assessment of controls and annual attestation in the KYC-SA application for Swift users. The framework has 32 controls, 26 mandatory and 6 advisory.	Gateways that reach Swift-connected systems or operator consoles need MFA, administrator access controls and logging that the independent assessor can trace. Confirm the mandatory controls that touch your remote access path with your Swift assessor.	Applies to Swift users. Confirm current control applicability in the Swift CSP pages.
PCI DSS applicability	Applies to entities that store, process or transmit cardholder data or sensitive authentication data, or that could affect the security of the cardholder data environment. Remote access into that environment needs MFA and logging.	If a remote desktop path reaches a cardholder data environment, the gateway sits in scope. Plan separate gateways or segmentation for card-environment systems and record sessions there.	Applies only where cardholder data is touched or could be affected. Otherwise, treat it as a design choice, not a requirement.
SOX ITGC access areas, SEC Release 33-8810	Management's assessment of internal control over financial reporting covers IT general control areas such as program changes, computer operations and access to programs and data.	Access reviews for gateway administrators and vendor accounts that reach financial reporting systems should be recorded and retained. Change control applies to gateway configuration, connection definitions and recording settings.	Applies to issuers subject to SOX Section 404 assessments.

What remote sessions touch in a bank or insurer

The first design decision is the list of systems a remote session can reach, because that list sets the gateway placement, the MFA scope and the recording obligations. In a bank or insurer, traders and analysts usually reach order management, market data front ends, position and risk reporting, and back-office settlement or claims applications. Outsourced support staff typically reach the same applications through a narrower set of accounts, often for a single ticket queue. Core banking or policy administration systems are the highest-impact targets, and the question to settle early is which of them a remote session may open at all. Build an inventory that maps each published Guacamole connection or RustDesk device to a named application owner, the data classes it holds (customer identifiers, account balances, claims files, trade records) and whether the target is an interactive administrative host. Hosts that also run privileged tooling should be separated from user desktops before any gateway is published.

Where the bank processes card payments, the cardholder data environment is the most consequential target. PCI DSS applies to entities that store, process or transmit cardholder data or could affect the security of that environment, so a remote session that merely reaches a host connected to it can bring that host into scope. Confirm with your qualified assessor or acquirer which jump hosts, administrative consoles and support workstations count as connected to the environment before you route vendor sessions through them. Insurers face a similar pattern with claims systems that hold health or payment data. In both cases, document which connections are permitted to reach regulated zones and which are blocked by default, because auditors will ask for that map first. Session recordings are a regulated output of this design, not a convenience feature. A recording of a trader's terminal or a support engineer's administrative session can capture customer data, account numbers and internal procedures, so it must be stored under the same access restrictions as the source system. For broker-dealers, SEC Rule 17a-4(b)(4) requires preservation of communications relating to the business for not less than three years, and your counsel should confirm whether session captures fall within that obligation. Plan recording storage with restricted read access, separate administrators from people who run sessions, and integrity protection such as write-once storage or hashing at capture. Confirm the retention period with your compliance team before the first recording is written.

How deployment constraints change the gateway design

In a bank data center, the usual pattern places the Guacamole web application in a DMZ segment, with guacd on a separate host that can reach the internal target network. The web application speaks only the Guacamole protocol and forwards it to guacd, which loads the protocol plugins that connect to Windows, Linux or other desktops on the user's behalf. Keeping guacd off the DMZ web tier means a compromise of the front end does not hand an attacker a direct route into trading or core banking segments, but the firewall rules between the two tiers must be written and reviewed explicitly.

Placement of guacd: Run guacd on an internal host that accepts connections only from the web application and opens sessions only to approved target subnets.
Recording storage: Write session recordings to an internal store inside the data center, with access limited to the supervision and compliance function, not to the DMZ.
Authentication back end: Keep the directory and MFA integration on internal systems so credentials never rest on the DMZ host.
Register of information: Record the data center locations of the gateway, guacd and recording store as ICT infrastructure in the register.
Network controls: Confirm which ports open between tiers and log every connection attempt that is refused.

Ask your implementation partner to show the firewall rule set, the recording path and the register entries together, because auditors will test them against each other.

Which self-hosted platforms fit financial services remote access

Financial institutions usually combine a browser gateway for staff and vendor sessions with an agent-based tool for attended support, and both need identity, MFA and recording behind them. The cards below cover the two remote desktop platforms, the identity provider that supplies MFA, and the gaps to close before a design passes review.

Apache Guacamole gateway

Guacamole is a clientless gateway released under Apache-2.0 that serves RDP, VNC and SSH sessions to any HTML5 browser, so analysts and outsourced support never receive a direct route into trading or core banking hosts. Its web application handles authentication and forwards traffic to the guacd daemon, which loads the protocol plugins. Supported extensions include LDAP, SAML, OpenID Connect, Duo and TOTP, and a session recording player. Confirm which extension combination your supervision team can audit, and where recordings are stored.

RustDesk Server Pro for support

RustDesk suits attended and unattended support for desks that need to reach a workstation from an agent rather than a browser. The open-source server runs hbbs for ID and rendezvous and hbbr for relay, and is licensed AGPL-3.0. The Pro tiers add 2FA, a web console, audit log, access control and OIDC or LDAP single sign-on. Confirm that your session logs meet your retention rules, and that the Pro licence terms fit your user and device counts.

Open-source RustDesk server gaps

The open-source RustDesk server provides the ID and relay services but not the Pro audit log, access control or 2FA features. A bank that deploys only the community server for vendor access would lack the per-session accountability that supervisors and auditors expect. Treat the community server as a relay component and confirm, in writing, which features each tier provides before approving it for regulated access. Document the decision in the register of ICT arrangements where a third party supplies the tool.

Identity provider as MFA source

The identity provider is the control point for multi-factor authentication, which the FTC Safeguards Rule requires for any individual accessing an information system unless the Qualified Individual approves an equivalent control in writing. Both Guacamole and RustDesk Pro can delegate sign-in to LDAP, SAML or OIDC, so MFA policy lives in one place. Confirm which factors your provider enforces for vendor accounts, how privileged groups map to connection permissions, and whether the provider logs can be retained alongside gateway recordings.

Session recording and retention

Supervision and record-keeping rules push recording into the design from the start. SEC Rule 17a-4(b)(4) requires broker-dealers to preserve communications relating to the business for not less than three years, and a recording of a remote session can fall within that scope depending on the content and your policy. Guacamole ships a recording player extension, while RustDesk recording depends on the tier and client settings. Confirm with counsel which sessions must be retained, where recordings are held, and how they are reviewed.

How a financial services rollout runs in phases

The sequence turns a remote access idea into a gateway that covers the right populations, enforces MFA, records sessions for supervision and vendor oversight, and hands operations to the bank's own team. Each phase closes with a written output that the next phase depends on.

Scope populations and regulated functions
The firm lists every group that will connect, including traders, analysts, branch or operations staff, and outsourced support, and maps each group to the systems it reaches, such as trading desktops, core banking consoles or policy administration. Compliance, risk and the business owners sign the list. Done means a scope document that names each population, each system, the data classes involved and the regulatory obligations that apply, including which functions may fall under DORA as critical or important and which recordkeeping rules apply to communications. Ask the partner to show how out-of-scope systems are excluded from the gateway.
Map controls and place the gateway
The team translates the scope into a control map covering authentication, session limits, recording, logging and vendor access, and assigns each control to an owner. The gateway is placed in a controlled network zone, with the target desktops reachable only from it and no direct inbound path from the internet. Done means an architecture diagram, a firewall rule set reviewed by the network and security teams, and a control matrix that links each requirement to the configuration that meets it. Confirm the placement with your own network architects, since DMZ design depends on your existing segmentation.
Integrate identity and multi-factor authentication
Apache Guacamole is connected to the firm's identity provider through the extension that matches its existing stack, such as directory-based login, SAML, OpenID Connect or a supported MFA extension. Privileged and vendor accounts are separated from workforce accounts, and emergency access follows a documented break-glass procedure. Done means test logins for each population that succeed only with the approved second factor, failed attempts are logged, and the identity team has signed off on group mappings. Confirm which MFA methods the regulator-facing policy accepts before configuration begins.
Configure session recording and retention
Session recording is enabled for the populations and connections defined in scope, with storage location, encryption, access rights to recordings and retention periods set to match the firm's recordkeeping policy. Recordings are restricted so that only supervisors and assigned reviewers can play them, and each playback is logged. Done means a test session is recorded, stored, found by the reviewer and deleted only after the retention rule runs, with the results attached to the control matrix. The retention period itself should come from legal and records management, not from the implementation team.
Onboard vendors against contract checks
Each external support provider gets a named account, a connection list limited to its contracted systems, approval and time windows, and a contract review against DORA Article 28 and Article 30 expectations. The review confirms the register of information entry, where services are provided and data processed, exit and data return terms, and the notice period for changes. Done means a signed vendor profile for each provider that the third-party risk team has accepted, and a revocation procedure tested against a sample account. Ask legal to confirm the wording rather than relying on the implementation partner's summary.
Run a pilot with access reviews
A limited pilot runs with a small set of users from each in-scope population, with logs and recordings reviewed by the business and compliance reviewers on a set schedule. The team checks that access matches the approved list, that idle and expired sessions close, and that alerts reach the monitoring queue. Pilot length is set by the number of populations and the review cycle, not a fixed period. Done means a written pilot report listing exceptions, the fixes applied, and a sign-off from the access owners that the reviews produced the evidence the auditors will ask for.
Hand over with runbooks and evidence
The partner delivers runbooks for onboarding and offboarding users and vendors, certificate and key rotation, backup and restore, patching, incident response and recording review, along with the configuration baseline and hardening record. Internal staff perform a supervised run of the main procedures so the handover is tested rather than read. Done means the operations team completes the runbook drills, the evidence pack is indexed for the compliance team, and any residual support arrangement is written into a retainer or service agreement with defined scope. Confirm which items the firm will own after handover and which will stay with the partner.

Which integration points a financial remote desktop gateway needs

How should a Guacamole gateway integrate with the identity provider and MFA in a bank?

Guacamole can authenticate users through extensions for Active Directory and LDAP, SAML, OpenID Connect, CAS, smart card single sign-on, and Duo or TOTP multi-factor authentication, as described in the Guacamole manual. Financial teams usually put MFA on the gateway login itself, so every trader, analyst and vendor account passes the same check regardless of the target host. The FTC Safeguards Rule requires MFA for any individual accessing an information system unless the Qualified Individual approves an equivalent control in writing, so non-bank firms under FTC jurisdiction should record that decision. Confirm with your identity provider vendor and the Guacamole extension version you pin which factors and claims are supported, and test lockout and fallback paths before go-live.

What session recording and retention storage does a supervised remote desktop need?

Supervision needs recordings that are stored outside the gateway host, protected from change, and kept for the period your regulator and internal policy require. The Guacamole manual includes a session recording player extension, so confirm how recordings are written, where they are stored, and how they are indexed for review. For broker-dealers, SEC Rule 17a-4(b)(4) sets a three-year minimum for preserving communications relating to the business, and whether session recordings fall under that rule depends on your records policy, which counsel should decide. Ask the implementation partner to define storage encryption, access to recordings, legal hold and deletion procedures in writing.

How do gateway logs get forwarded to a SIEM?

The gateway should send authentication events, connection starts and ends, permission changes and administrative actions to your SIEM so that security operations can correlate them with network and identity logs. Typical approaches include shipping the Guacamole and guacd logs and the database audit tables through a log agent, and forwarding the MFA provider's events separately. Confirm with your SIEM and the chosen Guacamole build which log formats are emitted natively and which need parsing. HIPAA-style audit controls, where they apply, expect systems to record and examine activity, so the forwarding design should be documented alongside your retention policy. Test that a simulated vendor session produces a complete, time-ordered trail.

How does privileged access and credential vaulting fit with a remote desktop gateway?

A gateway should not hold standing administrator passwords for target systems. The usual pattern is to store target credentials in a vault or privileged access tool, release them to the session only after approval, and rotate them after use. Guacamole connection definitions can reference credentials, so confirm how the chosen version stores them, whether it can request them from an external source, and where the encryption keys live. Separate the traders and analysts from the privileged operator accounts, and keep the vault's own audit trail in scope for supervision. Which vault product you use is a design decision, so the partner should confirm integration work with your existing tool rather than assume one.

Should vendor access approvals be tracked in GLPI, iTop or Zammad?

Vendor access should be tied to a ticket that records who requested the session, who approved it, the time window and the target systems. The open-source ITSM platforms GLPI (GPL-3.0, with GLPI 12.0.0 published on October 7, 2026) and iTop (AGPL-3.0, with 3.3.0 published on September 15, 2026) are common choices for change and access records, and Zammad (AGPL-3.0, with 7.2.2 released on October 8, 2026) can serve as a helpdesk front end. The integration is usually a webhook or API call that checks for an approved ticket before the gateway opens a connection. Confirm which ticket states, API version and approval workflow your team needs, and whether the approval check is enforced at the gateway or only documented.

Which database backend should store Guacamole users and connections?

Guacamole's manual documents database authentication backends on MariaDB or MySQL, PostgreSQL and SQL Server, so the choice usually follows your organization's standard database platform and support model. Select the engine based on what your database team can back up, patch, monitor and restore, and confirm that the schema version matches the Guacamole release you deploy. Use encrypted connections between the web application and the database, restrict the database account to the Guacamole schema, and include the database in your backup and restore tests, because connection definitions and permissions are the gateway's core configuration. Ask the partner which engine and version they validated and how schema upgrades are handled.

Which of these integrations must be confirmed with the vendor before scoping?

Confirm the exact extension names, versions and configuration keys for identity, MFA and recording with Apache Guacamole's documentation and your identity vendor, because extension behavior can change between releases. Confirm the log formats, the vault and ITSM connector options, and the database engine and version support with each product's vendor, not from general descriptions. Guacamole 1.6.0 was released on June 22, 2025, according to the Apache Guacamole website, so check whether your target build is newer and whether its extensions match. Ask your implementation partner to put this list in the written scope, with each item marked as tested, configured or deferred.

What auditors and supervisors ask to see from remote access

This table lists each evidence item that examiners, internal audit and DORA supervisors typically request for remote access into financial systems, the component that produces it, and what to confirm before the first review. Use it as a checklist when designing the gateway, because an item with no owner or no retention setting usually becomes the finding.

Evidence item	Component that produces it	What to confirm
MFA configuration and written exceptions	Guacamole authentication extension (TOTP, Duo, SAML or OpenID Connect) and the identity provider logs	Every account type uses MFA, and any exception carries a written approval from the accountable risk owner with an expiry date
Connection permission lists	Guacamole connection and user permissions held in the database backend (MariaDB or MySQL, PostgreSQL or SQL Server)	Export of who can reach which host, reviewed against the trading, analyst and vendor roles defined in the access model
Session recordings and retention settings	Guacamole session recording and its player extension, with storage on a controlled volume	Recording is enabled for privileged and vendor sessions, storage is immutable or access-logged, and the retention period matches the firm's record-keeping policy
Vendor access approvals with time windows	Access request workflow or ticketing system, plus connection schedule restrictions in the gateway	Each support session traces to a ticket with approver, named engineer, start and end time, and the access window closed automatically
Access review records	Identity provider group reports and gateway permission exports, signed off by the business owner	Reviews run on a defined cadence, removals are evidenced, and dormant or leaver accounts are tied to HR or contractor end dates
DORA register entries for remote support vendors	The firm's ICT third-party register of information, maintained by the third-party risk function	Each remote support provider appears with the service supported, the locations where access originates and data is processed, and the contract reference
Exit plans and data return terms for remote support vendors	Contract exit clause, documented transition plan and the vendor offboarding runbook	Plan is tested, covers revoking gateway accounts and certificates, and confirms data return on termination or insolvency of the provider
Change records for gateway configuration	Version control or change management system holding gateway, reverse proxy and guacd configuration	Every change to MFA, recording, network placement or permissions has an approval, a test record and a rollback path

How DORA changes contracts with remote support vendors

DORA applies to a remote support vendor's access whenever that access touches ICT systems the financial entity relies on. Regulation (EU) 2022/2554 has applied since 17 January 2025 to 20 types of financial entity, from credit and payment institutions to insurers, and it applies directly without national transposition. A vendor that connects into trading, claims or core banking systems through a gateway you operate is providing an ICT service, so the ICT third-party rules are likely to reach that contract. Whether a given vendor is in scope depends on how the entity classifies the service and whether it supports a critical or important function. That classification belongs to the financial entity and its compliance function, and it should be documented before the contract is drafted.

Once a remote support vendor is in scope, two records need to exist and stay current. Article 28(3) requires a register of information covering all contractual arrangements for ICT services, so each vendor account, its contract reference and the systems it can reach should appear in that register. For services supporting critical or important functions, Article 28(8) requires a documented and tested exit strategy and transition plan. In practice, that means being able to revoke a vendor's gateway accounts, recording credentials and session policies, and move support to another provider or to in-house staff without losing access to the session logs you will need later.

Article 30(2) sets the contract content. The agreement must state where the services are provided and where data is processed, which matters when a support engineer connects from another country or when session recordings are stored in a different region from the gateway. It must also require advance notice of location changes and cover return of data on insolvency or termination. Ask the vendor to confirm in writing where session recordings, logs and any copied files will be held, and to commit to returning or deleting them at contract end. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue attestations or certifications, and it cannot classify your services for you. Confirm the classification and the contractual wording with your legal, compliance and outside counsel.

What financial institutions ask about cost, time and effort

What are the main cost drivers for self-hosted remote desktop in a bank or insurer?

The main drivers are the gateway and relay infrastructure, the hardening and integration work, the identity and MFA setup, recording storage and the ongoing operations that keep the platform patched and reviewed. Infrastructure is usually the smallest share of the first-year picture, while integration with your identity provider, privileged access controls and evidence collection take most of the effort. Ask any partner for a quote built from a written scope that lists the protocols, the number of connection targets, the identity sources, the recording retention period and the environments (production, disaster recovery and test). Those inputs move the price more than the software choice does. DeployOpen does not publish a price list, and each engagement is quoted from its agreed scope.

Can our internal team run self-hosted remote access after the rollout?

Many institutions can, provided they assign clear owners for the gateway, the identity integration, patching and access reviews. The skills needed are Linux and container operations, directory and SSO administration, network placement in a DMZ, and the ability to read session logs and handle incidents. Guacamole's web application, its guacd daemon and its database backend are separate components, so your team should be comfortable operating all three and the authentication extensions you choose. Decide before the build which tasks stay internal and which go to a retainer. Ongoing support, upgrades and continuous testing are available from DeployOpen as retainers, and the split should be written into the scope.

What does the work need from compliance and vendor management teams?

Compliance and vendor management teams shape the design before any server is built. For DORA, the ICT services register under Article 28(3) must list the remote support arrangements, and contracts must state where services are provided and data processed, with advance notice of changes and data return on termination (Article 30(2)). Exit strategies and tested transition plans are expected where remote access supports critical or important functions (Article 28(8)). For PCI DSS environments, the assessor will look at MFA and vendor access controls. Compliance leads should confirm which obligations apply to the institution, which evidence the assessor or supervisor will request, and who signs off on the register entries. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports or attestations.

How long does the rollout depend on internal approvals?

The rollout depends more on approvals than on the technical build in most financial institutions. Change advisory boards, security architecture review, third-party risk assessment of any vendor who will use the platform, and sign-off on recording and retention policies can each add cycles. Ask your partner for a written schedule that separates build tasks from approval gates, and confirm which gates your own governance requires before production use. Fixed-scope engagements are agreed in writing before work starts, so the approval calendar should be part of that agreement. No duration should be assumed until the scope and gates are known.

Does Apache Guacamole require a software license for a financial institution?

Apache Guacamole is released under the Apache License, Version 2.0, so there is no per-user or per-connection software license fee for the open-source platform itself. Version 1.6.0 was released on June 22, 2025, according to the Apache Guacamole website, and your team should confirm the current release before planning. The costs that remain are infrastructure, implementation, hardening, integration with your identity provider, recording storage and support. Also check the licenses of any extensions, databases, operating systems and target-side remote desktop products you connect to, since those are separate components with their own terms.

When does RustDesk Server Pro pricing apply, and what does it cover?

RustDesk Server Pro pricing applies only if you choose the commercial edition instead of running the open-source RustDesk server, which is licensed under AGPL-3.0. According to RustDesk's pricing page, Individual is billed annually at $11.88 per month for 1 login user and 20 managed devices, and Basic is billed annually at $23.88 per month for 10 login users and 100 managed devices, with unlimited concurrent connections. Individual adds 2FA, a web console, an address book, an audit log, access control, centralized settings and distributed relay servers. Basic adds OIDC single sign-on, LDAP integration, cross-group access and a custom client generator. The page states Pro is not a SaaS subscription. Confirm current pricing directly with RustDesk, because plan terms can change.

How does session recording storage affect the remote access budget?

Recording storage is a recurring cost that grows with the number of sessions, their length, the recording quality and the retention period. Supervision and audit needs in regulated firms often require keeping records for years, so the retention schedule is a budget decision as well as a policy one. For example, the SEC's Rule 17a-4(b)(4) requires broker-dealers to preserve certain communications for not less than three years, but whether session recordings fall under that rule is a question for your counsel and records team. Storage costs also depend on whether recordings are encrypted, replicated, backed up and tested for restore. Ask the partner to size storage from your session volumes, retention rules and backup design, and to show how recordings are protected and deleted at end of life.

Where can we find the full breakdown of build, partner and SaaS costs?

The remote desktop cost hub compares building in-house, engaging a partner and using per-seat SaaS remote access tools, and it covers gateway and relay infrastructure, licenses, implementation, hardening, storage and ongoing operations in more detail than this page. Use it to structure your internal business case, then request a written quote from a partner based on the scope you agree. Compare quotes on the same inputs: number of targets, identity sources, MFA methods, recording retention, environments and support level. Quotes that leave these inputs out are not comparable.

How DeployOpen scopes and supports financial remote access

DeployOpen plans, implements, hardens, documents and supports self-hosted remote access inside the client's own cloud accounts, data centers or air-gapped networks. For financial services, the work starts from the controls a bank or insurer must evidence, then fixes the design, the test plan and the handover before any platform is installed.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
The written scope names which user groups, traders, analysts and outside support vendors, are covered and which systems they reach.
Scope records the MFA method, recording rules, retention period and which DORA register entries and vendor contracts the design must support.

How we build

Gateway placement, identity integration and privileged account segregation are designed and documented before deployment begins.
Session recording, audit logging and access approval workflows are configured and tested against the scope's supervision requirements.
Security testing of the gateway and its administrative interfaces is included where the written scope calls for it.

How we hand over

Handover covers architecture records, configuration baselines, runbooks for access requests, revocation and recording review.
Evidence packs map configured controls to the compliance requirements the client's assessors or auditors will ask about.
Exit and transition steps for each external support vendor are documented so access can be removed cleanly at contract end.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Patching of the gateway, identity connectors and recording storage follows a schedule agreed in the retainer scope.
Clients should confirm response expectations, service levels and escalation paths in writing, since these vary by retainer.

Self-hosted remote desktop for financial services