Open source PAM for healthcare: why clinical systems change the design
A self-hosted bastion that records every privileged session is the function to decide on first for EHR databases, PACS and clinical servers. The choice between JumpServer and Apache Guacamole follows from three things: which protocols your database administrators, clinical application vendors and imaging support staff actually use, whether the edition limits of JumpServer Enterprise fit your asset count and high availability needs, and where the gateway can sit in a hospital network that already segments clinical devices from the office LAN. Decide those three before you pick a product.
HIPAA shapes the evidence you must keep. The Security Rule at 45 CFR 164.312 requires unique user identification, audit controls that record and examine activity in systems holding ePHI, and person or entity authentication, but HHS does not certify anyone against it. HHS states that no standard requires certification, so a hospital cannot show a certificate to the Office for Civil Rights. What it can show is a list of named admin identities, the MFA method used for each vendor login, recordings that were actually reviewed, and approvals tied to tickets. Confirm with your privacy and compliance leads which of these artifacts they will request in a complaint review, and build the recording and retention design backward from that list. The proposed Security Rule revision published in January 2025 is not final, so plan for the current text while tracking the HHS proposed rule.
Also check whether the bastion itself becomes part of your ePHI footprint. Session recordings of a PACS or EHR database can contain patient data, so storage location, encryption, access to the recordings and retention need the same controls as the systems they capture. Confirm with your vendors, in writing, how the chosen JumpServer edition or Guacamole deployment stores and encrypts recordings, and whether business associate terms under 45 CFR 164.314 cover any support partner who can reach those recordings. Under the CNIL's September 2026 fine against a French hospital, external access without VPN or multi-factor authentication was itself treated as a failure, so vendor access paths need the same scrutiny as internal ones.
Which HIPAA technical safeguards and other rules shape privileged access
This table maps the HIPAA technical safeguards, the business associate terms, and the NIS2 and GDPR obligations cited in the CNIL case to specific build items on a self-hosted bastion. Read each row as a requirement, the design decision it forces, and the evidence an assessor or regulator is likely to ask for. The main takeaway is that HIPAA sets outcomes rather than tools, so the bastion design must produce named, recorded, authenticated and encrypted access that you can show on request.
| Requirement | What it means for the bastion design | Evidence to keep |
|---|---|---|
| Unique user identification (45 CFR 164.312(a)(2)(i), required) | Every administrator, vendor engineer and service operator signs in with a named identity. Shared root or local admin accounts on EHR databases, PACS and clinical servers must be removed or locked behind the bastion. | Identity list mapped to each session, with account creation and removal records |
| Emergency access procedure (164.312(a)(2)(ii), required) | Design a break-glass account that works when the identity provider or MFA service is down. Store its credentials sealed, define who may use it, and alert on every use. | Break-glass runbook, sealed-credential custody log, and records of each emergency session |
| Automatic logoff (164.312(a)(2)(iii), addressable) | Set idle timeouts on gateway sessions to clinical database and server consoles. Confirm the timeout values in your own configuration and document why any value was chosen. | Configured timeout settings and a documented risk decision if a different value is used |
| Audit controls (164.312(b)) | Record admin sessions to ePHI systems, index them for search, and retain them under your own policy. Confirm recording and retention options for the edition you select, since some session features sit in paid tiers. | Session recordings, log retention settings, and periodic review records showing someone examined the activity |
| Person or entity authentication (164.312(d)) | Require strong authentication at the gateway for every administrator and vendor, not only for the corporate network. Integrate the bastion with your single sign-on and MFA service and confirm which MFA methods the chosen platform supports. | Authentication policy export, MFA enrollment records, and failed-login logs forwarded to the SIEM |
| Transmission security (164.312(e)) | Encrypt all traffic from the user to the gateway and from the gateway to each target, including RDP and database protocols. Confirm the protocol encryption and certificate handling for each target type before rollout. | TLS configuration, certificate inventory, and a list of any unencrypted segments with compensating controls |
| Business associate terms (45 CFR 164.314(a)(2)(i)) | Vendor support engineers who connect through the bastion may be business associates or their subcontractors. Contracts must require Security Rule compliance and incident reporting, and the bastion should restrict vendor sessions to named systems with approval and recording. | Signed business associate agreements, vendor access request tickets, and recorded vendor sessions |
| NIS2 health sector scope (Directive (EU) 2022/2555, Annex I) | Healthcare providers and medical device manufacturers in the EU are listed as high criticality sectors. Confirm with counsel whether your entity falls in scope, then apply the stronger privileged account and MFA expectations to the bastion design. | Scope determination memo and the privileged access policy mapped to the NIS2 measures your entity must implement |
| GDPR Articles 32 and 34 (CNIL case, 3 September 2026) | The CNIL fined a hospital after external access lacked VPN and MFA and ignored the care team's need to know. Enforce MFA on every external path, restrict access to the patient records each role needs, and plan breach notification steps for compromised accounts. | Need-to-know access matrix, external access approvals, and a tested notification procedure for access incidents |
How EHR, PACS and clinical servers need different session rules
EHR databases hold the most sensitive electronic protected health information in the environment, and administrators reach them mostly through database clients and SSH to the database host. The main risk is a direct query that bypasses the application's own audit trail, so the bastion should be the only route to the database listener and administrators should connect with named accounts rather than a shared service login. Recording needs to capture the database session itself, not only the operating system login, because a DBA can do damage inside a single authenticated connection.
- Protocols: SSH to the database host and native database connections, which JumpServer and Teleport can proxy for supported engines; confirm the exact engine and version your EHR vendor supports.
- Session risk: Schema changes, bulk exports and changes to audit settings, which can hide later activity.
- Recording and review: Keep query-level logs alongside session recordings and review privileged sessions on a set schedule.
- Bastion placement: In a management zone that reaches the database subnet, never on the clinical user network.
- Credentials: Inject database credentials at the gateway so administrators never hold them.
Before approving a design, confirm with the EHR vendor which administrative tasks it supports through its own tools and whether vendor support requires direct database access.
PACS and imaging archives combine large data stores, DICOM services and storage appliances, and they are often administered by a radiology IT team alongside the vendor. Vendor support sessions are common and frequently urgent, because a stalled archive can hold up image reads. The bastion has to handle long-running, bandwidth-heavy sessions and still produce a clear record of who connected, what they changed and when the session closed.
- Protocols: RDP to Windows-based imaging servers and SSH to Linux storage nodes; Guacamole is a common choice for browser-based RDP and SSH access.
- Session risk: Changes to storage configuration, deletion of studies and changes to DICOM routing that could send images to the wrong destination.
- Recording and review: Record full sessions for vendor access and set a review step that checks changes against the support ticket.
- Bastion placement: Between the imaging network and the administrative zone, with no direct path from modality networks into the archive.
- Session length: Plan for long sessions and set idle and maximum durations that clinical operations accept.
Confirm with the PACS vendor which support tasks require full desktop access, because a narrower command-level path may reduce recording volume and review effort.
Clinical application servers run the middleware, interface engines and departmental applications that exchange messages with the EHR and with devices. Their administrators often hold broad rights, and a change to an interface engine can affect many departments at once. Break-glass access matters most here, because a failed interface can stop admissions, orders or results. The session policy should separate routine administration, which needs approval and recording, from emergency access, which must work when the normal approval path is unavailable.
- Protocols: SSH for Linux application servers and RDP for Windows-based interface engines.
- Session risk: Changes to routing rules, certificates and service accounts that clinical workflows depend on.
- Break-glass design: Define a sealed emergency account, its approval after the fact, a documented trigger and an alert to the security team. Test it during planned maintenance.
- Recording and review: Store recordings in a location the application team cannot edit and review every break-glass session.
- Bastion placement: In a dedicated administrative zone with redundant gateways, so an outage at the bastion does not prevent emergency repairs.
Clinical uptime targets and downtime procedures are set by the hospital, so confirm them with clinical operations before writing the break-glass rules.
Medical device management hosts sit between biomedical engineering, device manufacturers and the clinical network. They often run device management consoles, firmware distribution and remote service tools for vendors. Vendor remote access is the largest source of risk here, and the Hospital Prive de la Loire fine by the French data protection authority on 3 September 2026 found that external access to a patient record system lacked a VPN and multi-factor authentication and that access control did not reflect the care team's need to know. That finding is a useful reminder that vendor access must be tied to a named person, a time window and a specific system.
- Protocols: RDP and SSH to management consoles, with browser-based access for vendor technicians through Guacamole or JumpServer.
- Session risk: Firmware changes, configuration pushes to many devices and remote sessions opened from outside the hospital.
- Recording and review: Require a ticket and approval before each vendor session, record the session and check it against the ticket after closure.
- Bastion placement: In a separate zone that reaches device management hosts only, with vendor sessions ending there and never reaching clinical servers directly.
- Access scope: Grant access per device group, not to the whole management network.
Confirm which device manufacturers require vendor-hosted remote tools, since those may not accept a bastion path without contract changes.
Which open source PAM platform fits a hospital network
Hospital privileged access usually comes down to two open-source bastions with different strengths: JumpServer for managed server, database and asset access, and Apache Guacamole for clientless browser access to clinical and vendor desktops. Each card below covers one decision that shapes licensing, recording and integration with the hospital's identity and clinical systems.
JumpServer under GPL-3.0
JumpServer is a PAM platform and bastion host covering SSH, RDP, Kubernetes, databases and web access in one workspace. Its license is GPL-3.0, and the Community edition is free for self-hosted use up to 5,000 assets in a standalone topology. Check the asset count early, because a hospital's clinical server estate can grow past that threshold once imaging, lab and medical device servers are counted. Confirm with the vendor how assets are counted and what your topology needs for high availability.
Enterprise features behind the paid tiers
Several capabilities that hospitals often need sit in the Enterprise edition, including Oracle and SQL Server access, password rotation, ticket and just-in-time approval workflows, custom roles, SSO and LDAP high availability. Clinical databases such as those behind EHR reporting may run on these engines, so confirm the database protocols you need before choosing a tier. Enterprise tiers are priced by quote, so ask for a written price tied to your asset count and high availability needs.
Guacamole as a clientless gateway
Apache Guacamole is a clientless remote desktop gateway that runs in any HTML5 browser, so vendor engineers and clinical staff do not install client software. The web application handles authentication and the user interface, while the guacd daemon loads protocol plugins for VNC, RDP and SSH. It is a good fit for vendor support into imaging workstations and clinical servers that need RDP or SSH from a browser. Confirm which protocols your target systems use, since a new protocol needs its own plugin.
Apache-2.0 licensing and the guacd split
Guacamole and the guacd server components are licensed under Apache-2.0, which carries no per-asset or per-user license fee. The cost moves to the people who build, harden, patch and operate the gateway. Keep the web application and guacd on separate hosts where your network design requires it, and confirm which protocol plugins your hospital needs before rollout. Version 1.6.0 was released on June 22, 2025, so check the current release before planning.
Database authentication and backends
Guacamole stores users, connections and permissions in MariaDB or MySQL, PostgreSQL or SQL Server. Clinical teams will ask how these backends are backed up, replicated and patched, because the gateway's connection inventory is itself sensitive. Choose the backend your hospital already operates and supports, and define who may change connection records. Test restore procedures before go-live so a failed database does not block emergency vendor access.
MFA and directory integration
Guacamole's extensions cover Active Directory and LDAP, Duo and TOTP multi-factor authentication, CAS, OpenID Connect, SAML and smart card single sign-on. For hospital staff, linking the gateway to the existing directory keeps one account per person and supports unique user identification. For vendors, add MFA at the gateway, since the hospital's own directory may not hold vendor identities. Confirm which MFA method your security policy accepts before selecting an extension.
Session recording and review
Guacamole includes a session recording player extension, which lets reviewers replay sessions to see what an administrator or vendor did on a clinical system. Recordings of patient data screens may themselves contain ePHI, so decide where they are stored, who can view them and how long they are kept. Ask your privacy and compliance leads to set retention and access rules before go-live. Recording is a control only if someone reviews the sessions on a defined schedule.
How a hospital rollout of a bastion is phased
The sequence moves from clinical scope and access paths to a tested bastion, a single supervised pilot, and a handover that lets hospital staff run and evidence the access layer without the implementation team on site. Timing depends on the agreed scope, so each phase closes with a written output rather than a calendar date.
Scope clinical systems and access paths
Inventory the EHR databases, PACS, clinical servers and medical devices that need administrative access, and map every route in today: direct RDP, shared SSH keys, VPN accounts and vendor remote tools. Record who uses each route, which protocols they need, and which systems hold ePHI. DeployOpen leads the workshops with the hospital's infrastructure, clinical engineering and security teams. Done when the hospital signs off a system register with owners, protocols and access paths, which becomes the baseline for the HIPAA technical safeguard mapping.
Confirm edition and licensing needs
Compare the protocols and features in the scope against the Community and Enterprise feature lists of the candidate platform, such as JumpServer or Guacamole, and note any capability that depends on a paid tier, including database protocol support, approval workflows, password rotation and high availability. Ask the vendor to confirm in writing which features apply to the hospital's asset count and topology. Done when the hospital has a written edition decision with the features it relies on and the support model it accepts.
Design identity, MFA and session controls
Decide how administrators authenticate to the bastion, whether through the hospital's directory, a single sign-on provider or local accounts with a second factor, and how unique user identification is enforced so no two people share a login. Define session timeouts, the approval path for vendor support, and the break-glass account and its storage. Done when the design document is approved by the security and identity owners and every access path in the register maps to a named control.
Build the bastion in a test segment
Deploy the bastion and its recording storage into a non-production network segment that mirrors the clinical network routing, using the hospital's own infrastructure. Integrate the chosen identity source, enable session recording, and test each protocol against lab copies of the systems. Configure the logs to flow to the hospital's monitoring platform. Done when a documented test run shows that every protocol in scope connects through the bastion, that no direct path is needed, and that recordings and logs are written and retrievable.
Pilot with one clinical system and one vendor
Choose one clinical system and one vendor support path with a clear owner, then move that access onto the bastion in a controlled change window agreed with clinical operations. Run the vendor through the approval, time-limited access and recorded session steps, and capture what the vendor and the administrators found difficult. Done when the pilot has a signed change record, a reviewed session recording, and a list of fixes that the hospital has accepted or scheduled.
Expand to the remaining systems
Move the remaining systems in the register onto the bastion in waves, grouped by clinical area or network zone, and retire the old access paths only after each wave's sessions are confirmed. Keep a rollback plan for each wave and update the register as each system changes status. Done when every system in scope has a single documented access path, and the old direct routes are disabled or formally accepted as exceptions with an owner and review date.
Validate recording and retention
Test that session recordings capture the activity needed for review, that they are stored inside the hospital's environment with access restricted to the audit function, and that retention and deletion follow the hospital's policy. Check that recordings can be searched by user, system and time, and that a sample of sessions can be reviewed by someone other than the administrator. Done when the hospital has an evidence pack showing these checks, mapped to the audit controls and the policy owner's retention decision.
Hand over runbooks and operating routines
Deliver the runbooks for onboarding and removing administrators, approving vendor sessions, using break-glass access, restoring from backup, and applying updates to the bastion. Train the hospital's operators, agree the review cadence for access lists and recordings, and set the upgrade and support model. Done when the hospital's named operators have run each runbook once under observation and the handover record is signed by the service owner.
What the audit trail must show for HIPAA audit controls
The HIPAA Security Rule's audit controls standard in 45 CFR 164.312 requires hardware, software and procedural mechanisms that record and examine activity in systems containing ePHI. For privileged access, that means every administrator, vendor or engineer session on an EHR database, PACS server or clinical host must be traceable to a unique user identification, a time window, a named target and, where policy requires it, the approval that allowed the session. Design the bastion so these fields are captured together in one record, not reconstructed later from separate logs.
Retention is a decision the organization owns. The rule does not state a retention period for session recordings or access logs, so set the period in your own policy, align it with your records schedule and any state or contractual obligations, and confirm it with your privacy and legal teams. Decide who can search recordings, how often someone reviews them, and how a review is documented. Confirm with the vendor where JumpServer or Guacamole stores recordings and whether that storage can be encrypted and kept inside the hospital network.
Enforcement under this rule runs through the HHS Office for Civil Rights, which uses complaints, compliance reviews and audits, so an examiner will ask for evidence rather than a certificate. Prepare a sample package before any review: the access list for a system, the approval and session record for a sampled vendor visit, and proof that someone examined the activity. HIPAA has no certification to earn, so the evidence is your own record of how the audit trail works in practice.
Which evidence an OCR review or assessor asks to see
This table lists the evidence items an OCR investigator or assessor is likely to request for privileged access to ePHI systems, the component that produces each item, and where it usually falls short. Use it to plan what the bastion, identity provider and SIEM must retain before a review starts. DeployOpen prepares this evidence for your review, but it does not issue attestations, and HIPAA has no certification.
| Evidence item | Produced by | What the reviewer checks | Common gap |
|---|---|---|---|
| Access list by system | JumpServer asset and permission records, or Guacamole connection and user mappings | Each admin, vendor and engineer account mapped to named EHR, PACS or clinical servers | Shared or generic accounts, and grants that outlive the job need |
| Unique user identification | Identity provider user records linked to bastion accounts | Every session traces to one named person, as 45 CFR 164.312 requires | Shared admin logins on the target systems behind the bastion |
| MFA configuration | Identity provider (for example Keycloak or authentik) policy export and bastion login settings | MFA applies to all privileged and remote access paths, including vendor accounts | Vendor accounts or break-glass accounts that bypass the second factor |
| Approval records | JumpServer ticket and approval workflow (Enterprise feature per JumpServer pricing), or a documented ticketing process | Who approved each vendor or elevated session, and when | Approvals given verbally or after the session started |
| Session recordings with retrieval tests | JumpServer audit and session recording, or the Guacamole session recording player extension | Recordings exist for sampled dates and can be found, played and linked to a ticket | Recordings never tested for playback, or kept only on a single server |
| Break-glass logs | Bastion audit logs and the emergency access procedure documented by the covered entity | Emergency access was limited, reviewed afterward and tied to a named person | No written trigger conditions or no post-event review |
| Vendor business associate agreement references | Contract file held by the covered entity, cross-referenced to vendor accounts in the access list | A signed business associate contract under 45 CFR 164.314(a)(2)(i) covers each vendor with ePHI access | Vendor access granted before the contract was signed |
| SIEM forwarding and retention | Bastion log export to a SIEM such as Wazuh, with retention settings set by the covered entity | Audit logs are forwarded, tamper-resistant and kept for the period the organization sets | Logs stored only on the bastion, or forwarding that silently stopped |
| Access review records | Periodic review exports from the identity provider and bastion, signed off by the system owner | Privileges were confirmed or removed on a documented schedule | Reviews not performed, or no record of removed access |
What do healthcare teams ask before a PAM build?
What drives the cost of an open source PAM build for a hospital?
The main cost drivers are the number of clinical systems in scope, the protocols they use, the edition tier, the identity integration work, and how much session recording you keep. Open source software itself carries no license fee for the Community tiers, so most of the spend goes to people and infrastructure. Plan for one-time costs such as design, integration with your identity provider, hardening, and rollout per system, plus recurring costs such as patching, certificate and credential administration, storage for recordings, and support. JumpServer's pricing page lists Enterprise tiers by asset count with prices by quote, and the Community edition is free up to 5,000 assets in a standalone topology. Ask any partner for a written quote that separates these components and states which edition each one assumes.
How long does a healthcare PAM rollout take?
Duration depends on how many clinical systems must go behind the bastion, how many protocols they use, and how quickly your teams can complete change approvals. The critical path is usually not the software install but the work around it: confirming system owners, mapping which accounts need access, agreeing network change windows, and getting clinical sign-off so that a session recording or access change does not disrupt patient care. Installation of a single JumpServer or Guacamole instance is comparatively quick, while onboarding EHR database servers, PACS and vendor access paths takes longer because each one needs testing. Ask for a timeline in the written scope that lists the dependencies by name and the dates on which your side must deliver them.
What must the hospital provide before the engagement starts?
The hospital needs to name accountable owners for each clinical system, such as the EHR, PACS and medical device servers, and confirm who approves access changes for them. It must also supply an inventory of hosts, databases and protocols, a list of current administrator and vendor accounts, the identity provider details, and network change windows that the clinical operations team accepts. Clinical sign-off matters because a bastion sits in the path of systems that clinicians depend on. Agree in advance who can pause a rollout, how break-glass access works during an emergency, and how the team will test changes outside patient-care hours. Your own staff, not the partner, must own these decisions after handover.
Can our IT staff run an open source PAM platform themselves?
Many hospital IT teams can operate a bastion after handover, but they need defined skills and time for it. Day-to-day work includes managing user and role mappings, reviewing access requests, handling session recordings, applying updates, and keeping backups and high availability working. JumpServer ships with an installer project and container images on Docker Hub, and Guacamole supports native and Docker installation, which makes the platform practical to manage in-house. Enterprise features such as password rotation, ticket and just-in-time approval workflows, and HA clusters are tied to specific tiers, so confirm which ones you need before deciding. A common arrangement is for the partner to build and document the platform, then for your team to take over with a retainer for upgrades and testing if needed.
Does HIPAA have a certification we can obtain for our PAM?
No. HHS states that no Security Rule standard requires an entity to certify its compliance, and private certifications do not prevent HHS from later finding a violation. The HHS Office for Civil Rights enforces the rule through complaints, compliance reviews and audits. What you can do is implement the technical safeguards in 45 CFR 164.312, including unique user identification, audit controls that record and examine activity in systems containing ePHI, and person or entity authentication, and then keep evidence of that implementation. Be cautious with any vendor or partner who offers a HIPAA certificate for a product. Ask instead how they document the controls and which independent assessment, if any, you might commission.
How do vendor support sessions fit under business associate terms?
A vendor that accesses systems containing ePHI is generally a business associate, and the business associate contract under 45 CFR 164.314(a)(2)(i) must require the vendor to comply with the Security Rule, flow the same terms down to subcontractors that handle ePHI, and report security incidents to you. The bastion helps by making vendor access time-limited, approved, recorded and tied to a named individual, so you can show who connected and what they did. Contracts should also cover which vendor staff may connect, how their credentials are issued and removed, and how recordings are retained and shared. Confirm these terms with your legal and privacy teams, because the contract defines your obligations, not the software.
Does a bastion alone make a hospital HIPAA compliant?
No. A bastion supports several technical safeguards, such as unique user identification, audit controls and access restriction, but HIPAA also requires administrative and physical safeguards, risk analysis, policies, workforce training and business associate management. The Security Rule's 18 standards and 36 implementation specifications cover all three safeguard types, and the HHS Office for Civil Rights reviews the whole program. A bastion also does not fix weaknesses in the systems behind it, such as unpatched EHR servers or shared accounts that bypass the gateway. Treat the bastion as one control in a documented program, and use NIST SP 800-66 Rev. 2 as a practical guide to mapping the rule to your environment.
Which hospital systems should go behind the bastion first?
Start with the systems where privileged access carries the most risk to ePHI: EHR databases, PACS servers, and clinical application servers that store or process patient data. Next, cover the administrator and vendor paths that reach them, because shared or unmanaged access is the most common gap that examiners and regulators examine. The CNIL's September 2026 fine against a French hospital under GDPR Articles 32 and 34 found that external access lacked VPN and multi-factor authentication and that access control ignored the care team's need to know, which shows why both access paths and need-to-know rules matter. Confirm the scope with your security team and document each system's owner before any work begins.
Questions to ask an implementation partner before hiring
Start with experience in clinical network segments, because a bastion that works in a flat office network can fail in a hospital. Ask the partner which EHR, PACS and clinical device zones they have placed a gateway into, how they handled the boundary between the clinical VLANs and the administrative network, and whether they can describe the firewall rules that let JumpServer or Guacamole reach a clinical server without opening general inbound paths. Ask for a written description of the network diagram they would draw for your environment before any engineering starts. Also ask how they test break-glass access without disrupting care: a strong answer describes a scheduled drill on a non-production replica, a documented approval path that still works when the identity provider is down, and a rollback plan that clinical operations has signed off.
Next, ask how recordings are stored, retained and searched. The partner should explain where session recordings for JumpServer or Teleport land, who can view them, how the access to recordings is itself logged, and how a compliance officer would find every session touching a given patient record system during a review window. Ask how they handle the audit control expectation in 45 CFR 164.312(b), which requires mechanisms that record and examine activity in systems with ePHI, and how they would prove recordings were not altered. On commercial terms, ask the partner to separate Community and Enterprise features in writing. JumpServer's pricing is by quote, and tiers are sized by asset count, so ask which tier covers your asset count and HA requirement, what the Enterprise support terms are, and which fees recur.
Finally, ask how vendor access workflows, patching windows and evidence will work in practice. Vendor support for medical systems should run through approval, time-limited access, credential injection so the vendor never sees a password, and a recording that the hospital owns. Ask how upgrades are scheduled around clinical change freezes, whether they test the upgrade path on a staging copy of the access layer, and how they handle emergency security patches. Request a sample evidence package: the access lists, approval records, session logs, configuration baselines and the change records they would hand you. Ask them to be explicit that they prepare this evidence for your own assessors and do not issue audit reports or certifications. Good answers name the artifacts, the owner for each, and the retention period you must confirm with your compliance team.
Integration points for the hospital bastion
A hospital bastion only works when it connects cleanly to the identity provider, the SIEM, the credential store and the clinical network. Each connection below is a decision to make and verify before rollout, not a default setting.
Identity provider for MFA and SSO
Decide whether the bastion authenticates against an existing hospital directory or a dedicated identity provider such as Keycloak or authentik. Administrators need unique named identities, and the Security Rule's unique user identification standard depends on that mapping being clean. Confirm how the chosen gateway handles MFA at login, whether vendor accounts sit in the same directory as staff, and what happens to sessions when the identity provider is unreachable. Test the offboarding path end to end.
SIEM for session event forwarding
Session starts, command logs, failed logins and recording access should reach the hospital's SIEM, such as Wazuh or Security Onion, so audit controls are reviewed rather than merely stored. Confirm which events the bastion emits, in what format, and whether recordings themselves are forwarded or only referenced. Agree who reviews these events and how often, because the rule asks that activity be examined, not just recorded.
Secrets storage for target credentials
Shared administrator passwords for EHR databases, PACS servers and clinical hosts should live in a vault, not in bastion configuration files or spreadsheets. The bastion should inject credentials at connection time so clinicians' support staff and vendors never see them. Confirm which vault the hospital already runs, whether the bastion integrates with it natively in the edition chosen, and how rotation is scheduled around clinical maintenance windows.
Clinical network segmentation
The bastion sits between administrator workstations and clinical zones, so its placement determines who can reach EHR and imaging systems at all. Map which VLANs or security zones the gateway can reach, which target ports are open, and whether vendor traffic enters through a separate DMZ segment. Confirm firewall rules with the network team and document them, because segmentation gaps are a common finding in external access reviews.
High availability per chosen edition
A bastion that fails during an emergency can block clinical support. Confirm which high availability topology the chosen JumpServer or Guacamole build supports, and which HA features sit in paid editions. The JumpServer pricing page lists active-standby HA and full HA cluster tiers, so verify the tier against the number of assets and the uptime expectations agreed with clinical leadership. Plan break-glass access for when the bastion itself is down.
How DeployOpen scopes and supports a healthcare PAM build
The sequence turns a healthcare access problem into a written scope, a bastion running on the client's own infrastructure, recorded and reviewable admin and vendor sessions, and an evidence pack the compliance and security teams can use. Each step ends with a named output that the client can check before the next one starts.
Agree the written scope and deliverables
Before any work starts, DeployOpen and the hospital or health system agree the scope in writing: which EHR databases, PACS servers, clinical servers and medical device hosts sit behind the bastion, which protocols are needed (SSH, RDP, database and Kubernetes access), which vendors need support access, and which identity source and multi-factor method apply. The scope also names the deliverables, the acceptance checks and the change process. The output is a signed scope document that lists in-scope systems and excludes anything not agreed. Ask for a quote built from this scope, since the scope drives the effort.
Map access paths and privileged accounts
DeployOpen works with the client's infrastructure, clinical application and security teams to list every current route into clinical systems: shared administrator accounts, vendor remote tools, direct database logins and service accounts. Each path is mapped to a named owner, a business reason and the HIPAA technical safeguard requirements it touches, including unique user identification and audit controls under 45 CFR 164.312. The output is an access inventory and a target-state diagram showing which paths the bastion will replace and which must stay until a later change. Confirm with the client that this inventory matches what the network team sees.
Design the bastion for the hospital network
DeployOpen plans where JumpServer or Apache Guacamole sits, how it reaches clinical segments, which zones and firewall rules it needs, and how session recordings are stored and retained on the client's own infrastructure. The design covers high availability requirements, the identity provider integration, and the separation between administrator access and vendor access. Edition and feature limits are checked against the scope, since some features such as Oracle or SQL Server access and just-in-time approval workflows are listed by JumpServer as Enterprise features. The output is a reviewed architecture and a list of open questions for the client's architecture board.
Install and integrate on client infrastructure
DeployOpen installs the chosen platform in the client's cloud accounts, data centers or enclave, connects it to the agreed identity source and multi-factor method, and configures asset groups, role-based permissions and credential handling so that vendors and staff do not see shared passwords. Recording and log forwarding to the client's SIEM are configured at this stage. Test accounts are used first, then production onboarding happens system by system in the agreed order. The output is a working bastion with a tested integration list and a record of each configured system.
Harden, test and verify access controls
DeployOpen applies the hardening baseline agreed in scope, covering administrative interfaces, TLS settings, logging, backups of configuration, and removal of direct access paths that the bastion is meant to replace. Access controls are tested against the access inventory: unauthorized users should be unable to reach clinical systems, recorded sessions should capture every privileged action, and emergency (break-glass) access should work and be logged. Where the client has authorized it, security testing covers the bastion and its integrations. The output is a test report listing each control, the result and any remediation agreed with the client.
Document procedures and train operators
DeployOpen writes the operating documentation the hospital will need: onboarding and offboarding steps for staff and vendors, approval and emergency access procedures, session review steps, recording retention and access to recordings, backup and restore, and the upgrade process. Operators and the service desk are trained on these procedures using the client's own systems. The output is a documentation set and a signed training record, with a list of owners for each procedure so the client can see who reviews access and recordings after handover.
Prepare evidence for compliance assessments
DeployOpen assembles the evidence that the client's compliance lead and any external assessor will ask for: the access inventory, unique user identifiers, role definitions, approval records, sampled session recordings, audit log configuration, multi-factor settings and the test report. The pack is mapped to the relevant HIPAA Security Rule standards and, where the organization is also working toward other frameworks, to the matching control areas. DeployOpen prepares these materials but does not issue audit reports, attestations or certifications. HIPAA has no certification, so the client should confirm with its counsel and compliance team what evidence its own risk analysis requires.
Hand over and agree ongoing support
At handover, DeployOpen confirms the acceptance checks in the written scope, transfers administrative knowledge and passes over credentials and configuration backups through the client's own secure channels. The client then decides whether to run the bastion internally or to take a retainer for upgrades, security testing and ongoing support. Retainer scope, response expectations and upgrade cycles are agreed in a separate written document. The output is a signed handover record and, if chosen, a retainer agreement that lists the systems and services covered.
