Why vendor remote access needs its own design, and the short answer on platforms
A browser-based gateway such as Apache Guacamole or JumpServer, or an identity-based platform such as Teleport, can replace a VPN account or a shared password for support vendors, scoped to named vendors and named systems. If your vendors today receive a VPN login that reaches a whole network segment, or a password that several engineers at the vendor know, the access problem is larger than the tool you pick. The first decision is who each vendor identity is, which systems it may reach, and under what approval it reaches them. The platform comes second. Vendors differ from employees in four ways that the design has to reflect. Their identities usually live outside your directory, so they need a federated or locally managed account with its own MFA policy. Their need is time-boxed, often a single maintenance window, so access should expire on its own rather than wait for someone to remember it. Each session may need approval from your side, with a record of who approved it and what the vendor did. And offboarding is driven by the contract end date, which is rarely the date HR or IT tracks. A browser gateway handles the session path well, but it does not decide any of these four points for you. The platform choice turns on two questions that the rest of this page works through: which protocols the vendors actually use (RDP, SSH, Kubernetes or database clients), and which features your edition allows. For example, approval workflows and just-in-time requests are paid features in some tiers of JumpServer and in the Enterprise edition of Teleport, while the Teleport Community Edition license is limited to organizations under a set employee and revenue threshold. Confirm those limits against the current vendor documentation before you shortlist anything.
Which regulatory requirements shape vendor access and what each means for the build
This table lists the regulatory requirements that most often apply to vendor remote access, with what each asks for and what a build must produce as evidence. Use it as the baseline the sample rows map to, then add the obligations from your own sector and contracts. The main takeaway is that the same few controls (unique identity, approval, recording, no shared passwords, timely removal) recur across HIPAA and the FTC Safeguards Rule, so one well-designed vendor gateway can answer both.
| Requirement | What it asks for | Build implication and evidence to keep |
|---|---|---|
| HIPAA unique user identification (45 CFR 164.312) | Assign a unique name or number to each user of systems that hold ePHI | Give each vendor technician a named identity in the gateway, never a shared vendor login. Keep the identity roster and its change history. |
| HIPAA audit controls (45 CFR 164.312) | Record and examine activity in systems that contain ePHI | Enable session recording and logging for every vendor session. Keep a review record showing who examined the logs and when. |
| HIPAA person or entity authentication (45 CFR 164.312) | Verify that a person or entity seeking access is who they claim to be | Require strong authentication at the gateway for vendor users, backed by the identity provider. Document the authentication method per vendor group. |
| HIPAA transmission security (45 CFR 164.312) | Guard ePHI against unauthorized access while it moves over networks | Route vendor sessions through an encrypted gateway, not direct network paths. Keep the protocol and cipher configuration as evidence. |
| FTC Safeguards Rule MFA (16 CFR 314.4(c)) | Use multi-factor authentication for any individual accessing any information system | Apply MFA to every vendor account, including contractors and temporary accounts. Confirm the MFA method is enforced at the gateway, not only at the vendor's own login. |
| FTC Safeguards Rule encryption (16 CFR 314.4(c)) | Encrypt customer information in transit and at rest | Encrypt session traffic and any stored recordings or credentials. Record where recordings are stored and who can read them. |
| FTC Safeguards Rule monitoring (16 CFR 314.4(c)) | Monitor and log the activity of authorized users | Forward gateway logs and session metadata to your monitoring platform. Define who reviews them and how often. |
| Per-vendor unique identities (illustrative sample requirement) | Each vendor and each individual has a separate identity with a defined scope | Create one identity per person and per vendor organization, with the target systems listed. Shared accounts fail the unique identification check. |
| Approval records (illustrative sample requirement) | A named approver authorizes each access window before it starts | Keep the request, approver, justification and time window together. Confirm which approvals the edition you choose supports natively. |
| Session recording (illustrative sample requirement) | Vendor actions on in-scope systems are captured and retained | Store recordings for the period your contracts and regulators set. Confirm recording playback and retention options for your chosen platform. |
| Credential injection (illustrative sample requirement) | Vendors reach systems without ever seeing or holding the target password | The gateway injects credentials at connection time. Evidence includes configuration showing no vendor-visible secret exists. |
| Removal on contract end (illustrative sample requirement) | Access ends when the engagement, contract or employment ends | Set expiry on every grant and link offboarding to contract records. Keep the removal ticket and the confirmation of disabled identities. |
Which open-source platform fits vendor access, and why
Vendor access rarely needs a full platform rollout, but it does need a gateway that records sessions, injects credentials and ends access on schedule. The four options below cover the gateway choices and the identity source that vendor logins usually depend on, and each one suits a different mix of protocols, edition limits and identity providers.
Apache Guacamole for browser-based access
Guacamole is a clientless gateway: vendors open RDP, VNC or SSH sessions from an HTML5 browser, so nothing is installed on their laptops. The Java web application handles login and policy, while the guacd daemon loads the protocol plugins. Its Apache-2.0 license carries no edition thresholds. Check the authentication extensions you need for vendor identities, confirm the session recording player meets your retention rules, and choose a database backend (MariaDB or MySQL, PostgreSQL or SQL Server) that your operations team can back up.
JumpServer for approval-driven vendor sessions
JumpServer is a PAM bastion covering SSH, RDP, Kubernetes, databases and web access in one workspace. The Community edition is free up to 5,000 assets in a standalone topology. Ticket and just-in-time approval workflows and password rotation are listed as Enterprise features, so a vendor flow that depends on approvals should be priced before design starts. Confirm which protocols sit in the free tier, and whether the Windows and database connectors you need are Community or Enterprise components.
Teleport for certificate-based vendor access
Teleport issues short-lived certificates instead of shared keys, so each vendor session expires on its own without a manual key rotation step. It records sessions in both editions and supports SSH, Kubernetes, several databases and Windows hosts. The Community license applies only to organizations under 100 employees and under $10,000,000 in annual revenue. Vendors can request access just in time only in Enterprise Identity Governance. Confirm your size against the license before choosing it for vendor work.
Keycloak as the vendor identity source
A gateway can only be as strong as the identities behind it. Keycloak federates with LDAP and Active Directory, supports OpenID Connect and SAML 2.0, and can broker identities from external providers. This lets vendor accounts stay in a separate realm or directory with their own MFA rules and expiry dates. Teleport Community limits single sign-on to GitHub, so vendor identities held elsewhere need Enterprise or a different gateway. Confirm how your vendors authenticate before choosing the gateway.
How a vendor session is requested, approved, injected and recorded
Start with the vendor identity, because every later record depends on it. Each named vendor engineer needs a personal account, either federated from the vendor's own directory into your identity provider or created as a guest in Keycloak, authentik or ZITADEL, with MFA enforced there so every gateway inherits the control. Shared vendor logins make it impossible to tie a recorded session to one person. The request then names the target system, the start and end of the time window and the purpose, such as a patch tied to a change ticket. Only part of this is native. Access requests are a platform feature in Teleport Enterprise and JumpServer Enterprise, while Teleport's feature matrix shows Community Edition requesting roles only through the CLI. Confirm the approval features against your edition before designing around them.
Approval and the time-limited grant are where the process and the platform meet. The internal system owner should approve each request, and that approval should be recorded against the ticket and the access grant. JumpServer lists ticket and just-in-time approval workflows as Enterprise features, and Teleport Enterprise includes just-in-time access requests and reviews under Identity Governance. If your edition lacks these, the ticketing system holds the approval and an administrator creates the grant by hand, which adds a step someone must not skip. Expiry should be enforced by the platform, with a calendar reminder as a backup only. Teleport certificates expire automatically, so a vendor session cannot outlive its certificate. For Guacamole and JumpServer grants, confirm how the access window is enforced and test that a grant stops working on schedule.
Credential injection is what keeps the target password away from the vendor. In a Guacamole deployment, the vendor signs in to the web application, which hands the connection to guacd, and guacd opens the RDP or SSH session to the target on the vendor's behalf. The Guacamole architecture guide describes this split, and the stored target credentials stay on the gateway, so the vendor sees only the browser session. Confirm the same behavior in JumpServer, where password rotation is listed as an Enterprise feature, so you know which credential handling you actually get. For SSH to Linux hosts, Teleport avoids shared passwords altogether by issuing short-lived certificates. Recording then covers the full session: Guacamole includes a session recording player extension, Teleport records sessions in both editions, and JumpServer records sessions as well. Before go-live, run a vendor test session, retrieve its recording, and confirm it shows what the approver expects to review.
How a vendor access rollout moves from pilot to offboarding control
This sequence takes vendor access from an inventory of systems and support paths to a pilot with one vendor, then to the full set of vendors with tested offboarding. Each phase produces a written artifact that the security and vendor management teams can review before the next phase begins.
Inventory systems, vendors and protocols
Start by listing every system a vendor may need to reach, the vendors and contractors who support each one, and the protocols they use, such as SSH, RDP, database clients or web consoles. Record which systems hold regulated data and which are in a segregated zone. The owner of each system and the business need for vendor access should be named in the inventory. The phase is complete when the system owners have signed off the list and every vendor has a defined set of targets.
Design identity and MFA for external users
Decide how each vendor user is identified before any gateway exists. Vendor accounts should be separate from employee accounts, tied to a named sponsor inside your organization, and protected by multi-factor authentication. Confirm with your identity team whether vendor users come from a dedicated directory, a federated identity provider or a local store on the gateway, and how accounts are disabled when a contract ends. The output is an identity design document that the security team approves.
Build the gateway in a segregated zone
Deploy the bastion or browser-based gateway in a network zone that vendors can reach only through the gateway and that has no direct path into the target systems except the controlled ones. Confirm the hosting model, operating system baseline and high availability requirements in the written scope, since these depend on your environment and the edition you select. Test that the gateway can reach the targets and that no other route exists. The phase closes when a network test confirms the allowed paths and blocks the rest.
Configure request and approval workflow
Define who may request access, who approves it, and what each approval grants, including the system, protocol, account and time window. Where the chosen platform supports ticket or just-in-time approval workflows, configure them to match this policy. Where it does not, document the manual approval step and the record that proves it happened. Confirm with the vendor which approval features sit in the edition you plan to use. The output is an approved workflow with test requests that show grants and denials.
Inject credentials and vault secrets
Configure the gateway so it holds the privileged credentials for each target and inserts them when a session opens, so the vendor never sees or types a password. Store these secrets in a protected vault, restrict who can read them, and set a rotation plan that the system owner agrees to. Test that a vendor session works without exposing the credential in the browser, the terminal history or the clipboard. The phase closes when a review of the test session confirms that no secret reached the vendor's device.
Set recording and retention controls
Turn on session recording for every protocol in scope and confirm where recordings are stored, who can play them back and how long they are kept. Retention periods should come from your legal, regulatory and contract requirements, not from the default settings of the software. Confirm with your SIEM team whether session events should be forwarded for correlation. The output is a recording configuration record and a test recording that a reviewer can find, play and export.
Pilot with one vendor
Run a limited pilot with one vendor on a small set of systems. Walk through the full path: request, approval, MFA, session, recording and session end. Ask the vendor and the system owner to report friction, unexpected access or missing logs. Record the findings and fix the configuration before any other vendor is onboarded. The pilot is complete when the system owner accepts the results in writing and the findings are closed or accepted as known risks.
Migrate remaining vendors and test offboarding
Move the remaining vendors to the gateway in batches, each with its own approved targets and sponsor. Before a vendor goes live, confirm the scope, the contract end date and the sponsor who will request removal. Then test offboarding: disable the account, revoke active sessions, remove approvals and confirm that the vendor can no longer reach any target. Keep the test results as evidence that removal works. The phase closes when every vendor has a tested offboarding record and an access review schedule agreed with the business owners.
What do buyers ask before bringing in an implementation partner for vendor access?
What drives the cost of a vendor access project on open source?
Cost follows the scope you agree in writing: how many systems the vendors reach, which protocols are involved (RDP, SSH, Kubernetes, databases), how many vendors and contractors need access, how complex the approval design is, and how much session recording storage you keep. Each of these changes the configuration, testing and documentation effort. The software itself may be free, but the platform edition you need may not be. JumpServer's pricing page lists a free self-hosted Community edition up to 5,000 assets in a standalone topology, with Enterprise tiers priced by quote, and it puts ticket and just-in-time approval workflows in Enterprise. Ask any partner for a quote that itemizes these drivers separately.
Which costs are one-time and which recur after go-live?
One-time costs usually cover scoping, installation, integration with your identity provider, building the request and approval flows, onboarding the first set of systems, and writing the runbooks. Recurring costs cover edition or subscription fees if you use a paid tier, gateway hosting, storage for session recordings that grow with use, certificate and credential maintenance, upgrades, and periodic access reviews. Ask the partner to separate these lines in the quote and to state who pays for the recurring items after handover, whether that is your team, a retainer, or a vendor license.
Can our internal team run vendor access without a partner?
Many teams can, provided they already run Linux servers, identity federation and a basic network DMZ, and they have someone who owns the access policy. The hard parts are usually not the installation. They are designing approval rules that match your change process, deciding which vendor sessions require a human observer, keeping recordings searchable, and removing vendor accounts on time. Ask whether your staff can own those decisions after handover. If not, a partner can build the platform while your team takes over the operating model, and the written scope should state which parts each side keeps.
How long does a vendor access implementation take, and what does it depend on?
Duration depends on the number of systems onboarded, the protocols in use, how many identity sources must be connected, whether the platform needs high availability, and how quickly approvals and network changes are made. A small pilot with one vendor and a few Windows or Linux hosts moves faster than a rollout across many protocols and vendors. No general timeline is supplied here, so ask the partner for a phased plan with dependencies listed, and confirm the milestones you must sign off before each phase begins.
What do we need to provide during the engagement?
The partner will need named system owners who approve which accounts can reach which hosts, vendor contacts who confirm who works for them and when, and network staff who can open the required paths from the vendor-facing gateway to target systems. You will also need an identity provider or directory to federate with, a place to host the platform, and decision-makers who approve the access policy. Missing any of these usually extends the schedule, so put them in the written scope as client responsibilities with named owners.
Does the Community license apply to our organization?
It depends on the product. For Teleport, the Community Edition license applies only to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, with an exception for designated critical security patch versions. Organizations above those thresholds need a commercial agreement. For JumpServer, the free Community edition is GPL-3.0 licensed and is limited to 5,000 assets in a standalone topology, so larger estates need an Enterprise tier. Have your counsel and the partner confirm the threshold in writing before you choose a platform, because the edition decision changes the feature set and the license cost.
What should a partner be asked to confirm about the vendor access design?
Ask the partner to show how a vendor request is raised, who approves it, how credentials are injected so the vendor never sees a password, how sessions are recorded and where those recordings are stored, and how access expires and is removed at offboarding. Ask which controls rely on a paid edition and how the design handles break-glass access. Request a written test plan that covers a vendor session from request to revocation, so you can see the evidence each step produces before you rely on it.
Which evidence auditors and regulators ask for from vendor sessions
An auditor's first question is usually who outside your organization can reach which systems right now. The answer should come from a single list that maps each vendor identity to the systems, protocols and accounts it can use, with the date it was granted and the owner who approved it. In a bastion design, that list is generated from the access policy in the gateway, so it reflects what the platform will enforce rather than what a spreadsheet says.
- Vendor identity records: Each vendor user should have a named, individual account, never a shared login. The record should link to the contracting organization and the business owner.
- System grants: The export should show which hosts, databases, Kubernetes namespaces or Windows machines each identity can reach, and through which protocol.
- Point-in-time snapshots: Keep dated exports so you can show the state on a sampled date, not only the current state.
- Source of truth: Confirm whether the list comes from the gateway, the identity provider or a ticket system, and whether the export is available in your edition.
Before relying on the export, confirm with the vendor which features of the access policy and reporting are included in your chosen edition and which need an enterprise license.
Where vendor access requires approval, the evidence is the trail showing who asked, why, for what window, and who authorized it before the session began. Examiners often sample a handful of vendor sessions and then ask for the matching request and approval. A session that lacks a linked approval is a finding, even if the session itself was clean.
- Request details: The request should record the requester, the vendor identity, the target system, the stated purpose and the requested time window.
- Approver identity: Approval should be tied to a named internal approver who is separate from the requester, with a timestamp.
- Ticket linkage: Session records should reference the change or support ticket so a reviewer can follow the chain end to end.
- Emergency access: Break-glass or after-the-fact approvals need their own record, with a review date.
Confirm whether your edition supports approval workflows natively or whether you will need a ticket system to hold the approval record. Ask the vendor how approvals are stored, exported and retained.
For HIPAA, the audit controls standard in 45 CFR 164.312 requires mechanisms that record and examine activity in systems that contain ePHI. For the FTC Safeguards Rule, 16 CFR 314.4 requires covered financial institutions to monitor and log the activity of authorized users. A recorded vendor session is the most direct way to show both, provided the recording is complete, tamper-resistant and kept for the period your framework requires.
- Recording coverage: Confirm which protocols are recorded (SSH, RDP, database and Kubernetes sessions may differ) and whether recording can be enforced so vendors cannot bypass it.
- Storage and retention: Define how long recordings are kept, where they sit (inside your enclave or cloud account) and who can delete them.
- Integrity and access: Recordings should be protected against edits, and playback should itself be logged.
- Review: Show who examined recordings, how often, and what was found, since the rule asks for examination as well as collection.
The Guacamole manual documents a session recording player extension, and JumpServer lists a session recording transcoding worker among its Enterprise components. Teleport includes session recording with playback in both editions, but moderated sessions are Enterprise only. Confirm which of these features your edition includes before you commit to a design.
The HIPAA standard in 45 CFR 164.312 requires person or entity authentication, and the FTC Safeguards Rule in 16 CFR 314.4 requires multi-factor authentication for any individual accessing an information system. Assessors will want logs that show each vendor login, the factor used, and the outcome. A gateway that trusts an upstream identity provider is only as good as the logs that identity provider keeps.
- Authentication events: Each login should record the identity, timestamp, source address, result and the MFA method used.
- Factor enforcement: Show that MFA is required for every vendor path, not only the web console, including SSH and RDP through the gateway.
- Federated sign-in: If vendors authenticate through an external identity provider, confirm the gateway records the assertion it accepted.
- Log forwarding: Confirm logs reach your SIEM with enough retention to cover the sampling period.
Where SSO and LDAP integration are documented as Enterprise features, as in the JumpServer comparison, confirm that your tier includes them before you assume the logs exist. Ask the vendor for a sample log export during evaluation.
Vendor access often outlives the engagement that justified it. Evidence of offboarding shows that access was removed when the contract or task ended, and that no residual credentials remained. Auditors commonly test this by comparing the end date of a contract with the date the vendor identity was disabled.
- Expiry configuration: Time-limited grants should expire automatically, and the expiry date should be visible in the access record.
- Disablement events: Record when the identity was disabled, by whom or by which process, and the reason.
- Credential removal: Confirm no static passwords or long-lived keys remain on the target systems or in the gateway.
- Reconciliation: Compare active vendor identities against the contract register on a regular schedule and keep the result.
Ask the vendor which lifecycle features (automatic expiry, SCIM deprovisioning, access reviews) are included in your edition. Teleport lists access reviews and SCIM provisioning under Enterprise Identity Governance, and JumpServer lists ticket and just-in-time workflows as Enterprise features, so confirm these before you design your offboarding evidence around them.
Questions to ask an implementation partner about vendor access
Ask the partner to answer each question in writing, naming the specific systems, accounts and gateways in your environment. Start with identity: vendor users usually sit outside your directory, so ask how each vendor identity is created, which identity source it authenticates against (a local account, a federated IdP or a Guacamole extension such as OpenID Connect or SAML), how MFA is enforced for that identity, and when it expires. Ask who approves the vendor identity itself, separately from the session approval. A good answer names the role or group that owns each vendor account and the date it lapses by default.
Ask how approval is enforced rather than documented. Request a walkthrough showing that a session cannot start until a named approver has signed off, and ask which product feature does that: in JumpServer, ticket and just-in-time approval workflows are listed among Enterprise features, while Teleport's moderated sessions and dual authorization are Enterprise-only items on its feature matrix. Ask what happens when the approver is unavailable, and whether break-glass access exists, who may use it and how it is reviewed. Ask where recordings are stored, who can play them back, whether recordings are readable by the vendor being recorded, and how long they are retained. Also ask what the partner will do if the Community Edition license does not fit your organization.
Ask how credentials are injected and rotated, and how the vendor is kept away from the secret. For Guacamole, ask which credential store feeds the connection and whether the vendor's browser ever receives the password. For JumpServer, ask whether password rotation is an Enterprise feature in your target tier. Then ask the partner to demonstrate offboarding in a test environment: revoke the vendor identity, confirm active sessions terminate, confirm injected credentials rotate, and produce the removal record. Finally, ask how upgrades are tested against your recording and approval configuration. Ask for the current release history of the platform you propose, the upgrade procedure, and whether the partner's support covers emergency patches, with support terms stated in the signed scope.
How DeployOpen scopes, builds and supports vendor access
DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source access platforms inside your own infrastructure. For vendor remote access, that means a written scope that defines which systems vendors reach, how they request and receive approval, and how the gateway is deployed in your cloud account, data center or air-gapped network.
How we scope
- Inventory which vendors, systems, protocols and time windows the access must cover before any platform is chosen.
- Agree the request, approval and break-glass flow, including who approves vendor sessions and how urgent access is handled.
- Confirm identity sources, MFA method, session recording retention and edition limits in writing before work starts.
How we build
- Deploy the browser-based gateway, such as Guacamole or JumpServer, inside your own environment with the connections you agreed.
- Configure credential injection so vendors connect without ever seeing the target system passwords or keys.
- Test vendor sessions, recording playback, time-limited access and offboarding against the agreed scope before handover.
How we hand over
- Document the vendor onboarding and offboarding runbooks, approval roles and recording review steps for your team.
- Provide configuration records and access lists that your auditors or assessors can sample for the agreed controls.
- Train administrators on managing vendor accounts, rotating injected credentials and reviewing session logs.
How we support
- Offer ongoing support, upgrades and patching of the access layer as a retainer agreed in writing.
- Review gateway logs, recording storage and vendor account lists on a cadence set in the support agreement.
- Confirm with your platform vendor which support tier and edition features your deployment depends on.
