Why vendor remote access needs its own design, and the short answer on platforms
If vendors and managed service providers reach your production systems today through shared accounts, personal laptops or consumer remote tools, the first job is to give each external party its own named identity, a defined scope and a session trail you can review. Apache Guacamole fits that job when the access is interactive and should happen in a browser: it brokers RDP, SSH and VNC sessions into named hosts, so the vendor never holds a network path or a copy of the target's credentials. RustDesk fits attended support, where a person on your side or the vendor's side needs to share a screen during an incident, and you want the ID and relay servers to sit inside your own network. Neither tool answers the access policy question on its own. Identity, multi-factor authentication and approval workflows sit in front of both, and that layer decides who may request a session and when. Vendor access differs from employee access in three ways that change the design. The party is external, so you cannot rely on HR offboarding to remove access. The contract has an end date, so every account needs an expiry tied to that date rather than a standing entitlement. And the activity must be attributable and reviewable, so a session has to be traceable to one individual at the vendor, limited to the hosts named in its work order, and recorded in a form that someone on your side will actually read. Shared accounts break all three properties at once, because a log entry shows a generic login and no one can prove who acted. Before choosing a platform, list every vendor and MSP that connects today, the systems they touch, the protocols they use and the approval each session should need. Confirm with your contract and procurement teams where the end dates live and who signs off on revocation. Regulated sectors add specific evidence duties, which the sibling pages on healthcare, financial services and PCI DSS cover in detail; the design choices here apply across them.
Which requirements shape the vendor access design
This table maps each requirement that shapes third-party vendor access to its source and to what it means for the build. Read it as a list of design obligations: the platform can support each control, but no tool alone satisfies a rule, so confirm the final mapping with counsel and your assessor.
| Requirement | Source or obligation | What it means for the build |
|---|---|---|
| Protection of ePHI in transit | HIPAA Security Rule 45 CFR 164.312(e)(1), transmission security | Route every vendor session through a gateway you operate with encrypted transport, so vendor traffic never reaches ePHI systems directly. Confirm the encryption configuration with your assessor. |
| Audit controls | HIPAA Security Rule 45 CFR 164.312(b) | Log vendor logins, connection starts, file transfers and session ends in a store vendors cannot edit. Someone must review these records, so assign the review role and its cadence. |
| Vendor communications as business records | SEC Rule 17a-4(b)(4), three-year preservation of business communications | If vendor chat, email or ticket notes relate to the business, retain them in an archive that meets your counsel's retention view. Session recordings and notes may need the same treatment. |
| Per-vendor identity | Access control and accountability expected by most frameworks | Issue one named account per vendor person, backed by MFA and an identity provider such as authentik, instead of shared vendor logins. Disable accounts when the individual leaves the vendor. |
| Least-privilege connections | Access control principle used across HIPAA, PCI DSS and CMMC assessments | Grant each vendor account only the specific hosts, protocols and permissions its scope requires. Review these grants against the signed statement of work before each engagement. |
| Approval and time windows | Internal change and access governance, confirmed with your risk team | Require a ticket reference and named approver before a session opens, and enforce a start and end time on the connection. Expired windows should fail closed without manual cleanup. |
| Session recording retention | Your retention schedule and counsel's guidance | Define how long recordings and their metadata are kept, where they are stored and who can view them. Storage size depends on session volume and recording settings, so ask the partner for a sizing estimate. |
| Revocation at contract end | Third-party risk obligations confirmed with counsel and contract terms | Tie each vendor account to a contract end date and a named internal owner. Revoke accounts, certificates and stored credentials on that date, then record proof of revocation. |
| Log and access review | Periodic review expected by most assessors | Schedule a recurring review of vendor accounts, active grants and recorded sessions, with sign-off by someone outside the vendor relationship. Document exceptions and follow-up. |
How the design changes by type of vendor
A software vendor that performs scheduled maintenance or upgrades usually needs access for a known window, to a known set of systems, for a known task. The design should be narrow and predictable: one named account per vendor engineer, a connection limited to the target hosts, and a booking that opens access only for the change window. Because the work is planned, approval can happen before the session through the change record rather than live.
- Account model: Named individual accounts per vendor engineer, mapped to a vendor group, with no shared logins and MFA enforced at the gateway.
- Approval pattern: Pre-approval tied to a change ticket, with the access window and target hosts stated in the request.
- Recording depth: Full session recording of the window, stored with the change identifier so reviewers can match actions to the ticket.
- Revocation trigger: Automatic expiry at the end of the window, plus removal of the account when the maintenance contract or statement of work closes.
Confirm that the vendor's engineers can complete the task within the window, that the target list matches the change ticket, and that expiry is enforced by the platform rather than by a manual reminder.
An MSP is different because its staff rotate across many client environments, often on short notice, and one person may hold several client relationships. The design must separate each client's access from the others, so a credential or session for one client never reaches another. The account model is usually per-engineer identity at the MSP, mapped to per-client authorization, and approval is more often standing for on-call duties and per-ticket for project work.
- Account model: One identity per MSP engineer in the provider's directory, with group-based permissions per client and no access to a client environment unless that client's group is granted.
- Approval pattern: Standing access for defined on-call roles with time limits, and ticket-linked approval for project or incident work outside those roles.
- Recording depth: Session recording on every client connection, with the client identifier stored alongside each recording so each client can receive its own evidence.
- Revocation trigger: Removal of group membership when an engineer leaves the MSP or rotates off a client, and disablement of the client's groups when the service agreement ends.
Confirm how the MSP's identity provider and your gateway exchange group membership, how quickly a rotation takes effect, and whether each client can export its own session records without seeing other clients' data.
An equipment or device vendor often needs hands-on access to a specific piece of hardware or a control system, sometimes during a fault that was not scheduled. The access is interactive, the session may be long, and the consequences of a wrong action can reach physical processes or clinical devices. The design therefore favors tight target scoping, live oversight during the session, and a fast kill switch, while accepting that approval may be needed on short notice.
- Account model: A dedicated vendor account per device or product line, scoped to the specific hosts or protocol sessions, with no permission to browse the wider network.
- Approval pattern: Case-by-case approval by the asset owner, recorded with the fault or service reference, and a time limit set when the session is approved.
- Recording depth: Full recording with live viewing enabled, so an internal operator can observe and terminate the session if needed.
- Revocation trigger: Immediate termination on operator decision, automatic disablement after the approved window, and removal of the account after the service case closes.
Confirm which hosts the vendor will touch, who on your side can watch and end a session, and whether the device itself needs a separate change procedure that the remote session must follow.
Which self-hosted platforms fit vendor access and why
Vendor access fails less often on the protocol than on the controls around it: who the vendor is, what they can reach, when that expires, and what gets recorded. The four components below each cover one part of that control chain, and each needs a licensing and feature check before it goes into a design.
Apache Guacamole as the clientless gateway
Guacamole is an Apache-2.0 licensed gateway that gives vendors RDP, SSH and VNC sessions from a browser, so no vendor-side client or VPN tunnel is needed. Version 1.6.0 was released on June 22, 2025. Its session recording player extension and database-backed connection permissions let you grant each vendor only the hosts they need. Confirm which permission model and recording storage your version provides before you design retention around it.
RustDesk Server Pro for attended sessions
Attended vendor support, where an engineer on your side accepts the session, often runs on RustDesk. The open-source server runs hbbs and hbbr, but per-vendor controls such as audit logs and access control sit in the Pro editions. The Basic plan adds OIDC single sign-on, LDAP integration and cross-group access, while Individual adds 2FA and an audit log. RustDesk's README carries a misuse disclaimer, so write an acceptable use rule for vendors before rollout.
authentik as the identity and policy layer
authentik's core is MIT licensed, and its enterprise directory covers features that vendor programs often need: Entra ID integration, mTLS client certificate authentication, privileged access management and enhanced audit logging. Its remote access control provider can sit in front of gateways to enforce policy per vendor identity. Check which of these features your edition includes, since the enterprise directory has its own license, and confirm that a vendor account can be disabled from one place.
GLPI or iTop as the vendor access register
Access to a system should expire with the contract, but expiry dates usually live in a spreadsheet nobody checks. GLPI, licensed under GPL-3.0, and iTop, licensed under AGPL-3.0, can hold vendor organizations, contract end dates, named individuals and the systems each one covers. Link each vendor account in the gateway to a register entry, then review open entries against contract dates. Confirm which contract and asset objects your chosen version supports and how the register is kept in sync with the identity layer.
How the rollout moves from one pilot vendor to all vendors
The sequence starts by agreeing which vendors and systems are in scope, then builds the identity model, gateway, permissions, recording and revocation process in an order that lets one vendor prove the design before every supplier is onboarded. Each phase closes with a written output that the security and procurement teams sign off.
Define vendor and system scope
The CISO's office, IT operations and procurement list every supplier and managed service provider that needs remote access, the systems each one touches, and the data classes involved. Each vendor is tagged with its contract, its named staff and the business owner who approves access. The output is a scope register that maps each vendor to target systems and the access purpose, which becomes the baseline for every later control. The phase is done when the register has been reviewed against the contract inventory and no vendor with live access is missing from it.
Design the identity and per-vendor account model
The team decides how each vendor person is identified: a dedicated account per individual, tied to a sponsoring internal owner, with no shared logins. Multi-factor authentication, single sign-on sources and account expiry dates are specified here, and the provider that will hold the identities is selected for its ability to disable accounts centrally. The output is an identity design document and a naming and lifecycle standard for external accounts. It is complete when every scoped vendor has a defined account pattern and an owner who can request changes.
Build and harden the gateway in the DMZ
The engineering team deploys the browser gateway, its authentication layer and database in a segment that vendors can reach only through the intended entry point, with no direct path to internal networks. Administrative interfaces are restricted, TLS is enforced, logs are forwarded to a central store, and the host is patched and configured to a written baseline. The output is a tested network diagram, a hardening checklist with evidence, and a documented list of firewall rules. The phase closes when a penetration test or configuration review confirms no unintended routes exist.
Set connection permissions and approval workflow
Administrators map each vendor account to the specific hosts and protocols it may use, and nothing broader. A request-and-approval step is defined so that the internal sponsor approves each access window before a session can start, with time limits enforced by the platform rather than by reminder. The output is a permissions matrix and a tested approval flow with named approvers and a fallback approver. The phase is done when a test account can reach only its approved host during its approved window.
Configure recording and log review
Session recording is enabled for every vendor connection, with storage locations, access rights to recordings, and a retention period set by the compliance owner against the applicable rules. A review schedule is agreed in which a named person samples sessions and reviews audit logs for out-of-window access or unusual activity. The output is a recording and review standard, a log retention record and a sample review report. The step closes when recordings can be retrieved and played back by the reviewer and the alerting path has been tested.
Run the pilot with one vendor
One vendor, chosen because its scope is contained and its sponsor is engaged, is onboarded end to end using the new account model, permissions, approval flow and recording. The team records every friction point, every access request and every audit event, then compares the actual sessions with the approved scope. The output is a pilot report listing defects, control gaps and the changes made, signed by the sponsor and the security owner. The pilot is complete only when the report shows the controls worked as designed and the vendor has accepted the working terms.
Onboard remaining vendors in controlled waves
The approved process is applied to the remaining vendors in groups, starting with those that have the least sensitive access. Each vendor receives individual accounts, a permissions set and a signed access agreement before first use. The output is an onboarding record per vendor and a register that shows status, owner and next review date. The wave is complete when every vendor in the group has been verified against the scope register and no shared or legacy access remains for that group.
Document the revocation runbook
The operations team writes and tests a runbook for ending vendor access at contract end, on termination of a staff member, or on suspicion of misuse. It covers disabling identities, removing permissions, closing open sessions, rotating any shared secrets and confirming with the vendor in writing. The output is a tested runbook, a revocation checklist and evidence from a test revocation showing that access was removed. The rollout is considered complete when the runbook has been exercised and the register shows an end date for every vendor relationship.
What auditors ask for and which component produces it
This table lists the evidence items auditors commonly request for supplier access and maps each one to the component that usually produces it. Use it to plan which logs, records and approvals your gateway, identity layer and ticketing system must generate from day one. The auditor decides whether any item is sufficient for a given control, so confirm the expected format and retention period with your assessor before go-live.
| Evidence item | Producing component | What to confirm before go-live |
|---|---|---|
| Vendor account inventory | authentik user and group records, supported by a ticketing system for onboarding requests | Each vendor has a named, individual account with no shared logins, and the inventory can be exported on request |
| Approval records | Ticketing system tied to the access request, with the approver recorded | Approval is captured before the account is enabled, and the approver is not the requester |
| Time-window configuration | authentik policy and access settings, plus the gateway connection permissions | Access windows are written into the configuration and the export shows when they were last changed |
| Session recordings | Guacamole session recording player extension, or the recording store used with RustDesk | Recordings cover every vendor session, are stored with restricted access, and follow the retention period your assessor expects |
| Audit log extracts | authentik enhanced audit logging (Enterprise), Guacamole connection history, RustDesk Server Pro audit log | Logs cover logins, failed attempts, connection start and end times, and are forwarded to a store that vendors cannot edit |
| Access reviews | Periodic review exported from the identity layer, signed off by the system owner | Reviews are scheduled, cover every active vendor account, and record the decision and reviewer |
| Revocation records | Identity layer deactivation log plus the ticket closing the contract or engagement | Revocation happens on the contract end date, and the record shows removal from both the gateway and the identity provider |
What the vendor relationship means for your own staff and contracts
The policy, the vendor agreements and the approval decisions stay with your organization. A self-hosted gateway such as Apache Guacamole can enforce a session once it is configured, but it cannot decide whether a supplier should be on the system at all. Your contracts need to state that the vendor will be recorded, how long recordings are kept, who in your organization may view them, and what the vendor must do when a session is disputed. Ask your legal and procurement teams to confirm whether recording consent language is needed in each jurisdiction where vendor staff sit, and whether your existing master services agreements already cover it. Vendor background checks, required training and security attestations are also contract terms you set, not terms DeployOpen can set for you.
Decide before go-live who approves each session, who reviews recordings and how revocation is triggered. Approval is an operating role: name the internal owner for each vendor, the person who books the time window and the person who confirms the session ended. Revocation at contract end should not depend on someone remembering. Tie each vendor account to a contract end date in your identity system, so that disabling access is a scheduled, reviewable step. Confirm with your identity provider and gateway vendors how account expiry and group removal are handled, since the exact behavior depends on the product version you deploy.
DeployOpen prepares the controls and the evidence that show they operate. In a typical engagement, that means configuring per-vendor accounts and connection permissions, time-boxed access, session recording and retention settings, and the logs and exports an auditor will ask for. The evidence package is only as credible as the policy behind it, and the policy belongs to you. Ask any implementation partner to show, in writing, which artifacts they deliver and which decisions you must sign off, and keep that record with your vendor contracts so that a reviewer can trace each vendor session back to an approved agreement.
What buyers ask before hiring help with vendor remote access
How much does self-hosted vendor remote access cost overall?
The total depends on scope more than on any single license, so ask for a quote built from a written scope. The main components are gateway and relay infrastructure in your own cloud account or data center, the identity layer, recording storage, the implementation and hardening work, and ongoing operations. Software licensing may be zero if you use open-source Apache Guacamole, or a recurring fee if you add paid features. For example, the authentik pricing page lists Enterprise at $5 per user per month billed annually plus $0.02 per external user per month, which matters when many vendor staff need accounts. RustDesk's pricing page lists Server Pro Individual at $11.88 per month for 1 login user and 20 managed devices, and Basic at $23.88 per month for 10 login users and 100 managed devices, billed annually. Ask each quote to separate one-time work from recurring costs.
What drives the cost of recording and storing vendor sessions?
Recording cost follows the number of sessions, their length, the protocols used and how long your retention rule requires you to keep them. Storage is usually the recurring part, and retention periods are often set by your compliance owner rather than by the vendor. Recordings that must be tamper-evident, encrypted and searchable add design and storage work, which should appear as a separate line in the quote. Ask the partner how recordings are indexed, where they are written, who can replay them, and how deletion at the end of the retention period is handled. Guacamole's manual documents a session recording player extension, but the storage design and access review around it are the parts that need scoping.
How long does a pilot for vendor remote access take?
A pilot's length depends on the number of vendors, the protocols in use and how many approval paths you need to model. The pace is usually set by identity integration, firewall and DMZ change approvals, and the time your vendors need to test their own tooling. No duration is fixed here, so ask for a timeline in the written scope with named milestones. A useful pilot covers one or two real vendor paths end to end, including approval, time-limited access, recording, review and a test revocation. Plan for the change windows in your network team's calendar before the build starts, since those approvals often take longer than the software work.
What does the implementation need from our identity and network teams?
The work needs your identity team to agree on how vendor identities are created, federated and disabled, and your network team to approve where the gateway sits and which paths it may reach. In practice, that means:
- Identity: a decision on directory source, MFA method, and whether vendor accounts live in your directory or in a separate identity provider such as authentik.
- Network: a DMZ or management segment, firewall rules to target hosts only, and a plan for outbound relay traffic if you use RustDesk.
- Security: agreement on logging destinations, recording storage location and who reviews sessions.
Ask the partner to list every input they need from each team before the build starts, and to name who signs each change.
Can our internal team run vendor remote access without a partner?
Yes, a capable internal team can run it, but the question is whether they have capacity for ongoing duties as well as the initial build. Running it means patching the gateway and identity components, reviewing access requests, handling vendor onboarding, reviewing recordings and testing backups. Authentik's security policy lists the supported release lines and says security releases are announced at least 24 hours in advance, so someone must watch that channel and schedule upgrades. A partner can build, harden and document the system, then hand over runbooks, or stay on a retainer for upgrades and testing. Decide which of those duties your team will own before choosing the model.
What happens to vendor access when a contract ends?
Access should end automatically or on a documented schedule, not when someone remembers to remove it. The procedure should disable the vendor account, revoke active sessions, remove gateway connection permissions, rotate any shared credentials, and confirm that the revocation was logged. Ask the partner to show a revocation test in the pilot and to add a contract-end checklist to your offboarding process. Keep the recordings and logs for the retention period your compliance owner set, even after access is removed. Also confirm that vendor-owned tools or agents on your devices are uninstalled and that their access to other systems through single sign-on is removed too.
Which compliance evidence should we expect from the build?
Expect evidence that maps to your framework, such as access request records, MFA settings, session recordings, audit logs and revocation records. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do. For healthcare, the HIPAA Security Rule at 45 CFR 164.312 requires transmission security for ePHI and audit controls that record and examine activity. Ask the partner which logs and reports will exist at handover, who can export them, and how they will be retained.
Questions to ask an implementation partner about vendor access
The first question to put to a partner is how each vendor gets its own identity. Ask whether every supplier and managed service provider receives a named account in the identity provider, with its own group, its own connection permissions in the gateway and its own expiry date, rather than sharing a generic support login. Ask which identity layer holds those accounts. If the partner proposes authentik, ask how its RAC provider maps vendor groups to specific hosts, and how MFA is enforced for external users. Also ask how a vendor's account is disabled in the directory and in the gateway in one step, so that revocation at contract end does not depend on someone remembering a second system.
Next, ask how time windows and approvals are enforced, not just documented. A credible design makes the approval a recorded event, ties the session to an approved window, and ends the session automatically when the window closes. Ask where the approval workflow lives, who can grant it, and whether the partner can show a test in which an expired window blocks a login. Ask how vendor sessions are kept apart from privileged internal access: separate gateway instances or connection groups, separate administrator roles, and separate network paths into the same protected systems. Ask the partner to show this on a diagram.
Finally, ask about recordings and handover, because these decide whether the evidence survives the engagement. Ask where session recordings are stored, who can read them, how long they are retained, and who holds the encryption or access keys. The customer should hold those keys or have a documented escrow, so that a partner who leaves cannot withhold evidence. Ask how reviews are scheduled and logged, and how the partner will hand over runbooks, configuration exports and access reports so your own team can prove, without the partner present, which vendor reached which system and when. Ask the partner to name the audit events it will export and to confirm what it does not cover.
