Open source PAM for NERC CIP remote access

How open source PAM meets the CIP-005 remote access requirements

Interactive remote access to BES Cyber Systems has to pass through an Intermediate System, and that system has to enforce encryption and multi-factor authentication before a session reaches the asset. CIP-005-7 R2 sets this for high impact BES Cyber Systems and for medium impact BES Cyber Systems with External Routable Connectivity, along with their Protected Cyber Assets. In practice, the open source function is a gateway, identity integration and recording layer: a browser or client connects to the gateway, the gateway authenticates the person against your identity source with MFA, and only then opens the protocol session (SSH, RDP or VNC) to the target. Guacamole or JumpServer can fill this role, but the utility still owns the design of which zones the gateway sits in and which accounts it can reach. NERC does not issue a CIP certificate. The Compliance Enforcement Authority, a Regional Entity or NERC, checks compliance through Compliance Audits, Spot Checks, Self-Certifications and Self-Reports, so the evidence you keep is what gets examined. R2 applies where technically feasible, and whether a given Cyber Asset falls in scope depends on your CIP-002 categorization and any Technical Feasibility Exception you have filed, so confirm both with your compliance team and the current CIP-005-7 text before you size the gateway. Also confirm how your CIP-002 categorization treats the gateway itself, since an Intermediate System that reaches applicable systems usually becomes part of the scope you must protect.

Before you build, decide three things with your compliance and operations staff. First, which vendor and engineer paths must traverse the Intermediate System and which system-to-system paths fall under the Part 2.4 and 2.5 controls, which require methods to determine and disable active vendor sessions. Second, which MFA method your identity provider supports for gateway logins and how it is enforced for every session. Third, how session recordings and gateway logs are stored, retained and exported to your evidence repository. Guacamole's documented extensions cover Active Directory, LDAP, Duo, TOTP, SAML and OpenID Connect, and JumpServer's Enterprise tier adds features such as ticket and just-in-time approval workflows, so confirm in writing which of these features your chosen edition includes before you commit to a design.

Mapping CIP-005-7 R2 parts to Intermediate System controls

This table maps each CIP-005-7 R2 part on Interactive Remote Access and vendor sessions to what the Intermediate System must do, how Guacamole or JumpServer can be configured for it, and what to confirm about applicability. Read it as a checklist to agree with your compliance lead before any gateway is built, since scope depends on the impact rating of each BES Cyber System.

Requirement	What the function must do	How to configure Guacamole or JumpServer	What to confirm about applicability
CIP-005-7 R2 Part 2.1 (Intermediate System)	Route all Interactive Remote Access through an Intermediate System so the initiating Cyber Asset never reaches the applicable Cyber Asset directly	Place the Guacamole server or JumpServer bastion in a separate network zone, block direct routes from user workstations to BES Cyber Systems, and allow only the gateway to open protocol sessions to targets	Confirm which BES Cyber Systems are high impact or medium impact with External Routable Connectivity under CIP-002-5.1a, and whether PCA and associated EACMS are in scope
CIP-005-7 R2 Part 2.2 (Encryption terminating at the Intermediate System)	Encrypt every Interactive Remote Access session so the encryption ends at the Intermediate System, with a defined protected path from there to the target	Require HTTPS with a valid certificate for the Guacamole web application or JumpServer web interface, and confirm the protocol path from the gateway to targets (RDP, SSH) is encrypted as documented for each protocol	Confirm with your compliance and network teams where encryption terminates for each session type, including vendor sessions and any HTTP or header-based login paths
CIP-005-7 R2 Part 2.3 (Multi-factor authentication)	Require multi-factor authentication for all Interactive Remote Access sessions before a session opens	Integrate Guacamole with an MFA-capable extension (such as Duo or TOTP) or an OpenID Connect or SAML identity provider, and configure JumpServer SSO and MFA so no session starts on a password alone	Confirm which login paths exist (local accounts, break-glass, API tokens) and whether each one meets the MFA expectation and is documented as in scope
CIP-005-7 R2 Part 2.4 (Determine active vendor sessions)	Provide one or more methods to determine active vendor remote access sessions, including Interactive Remote Access and system-to-system access	Use the live session view and session logs in JumpServer, or Guacamole active connection monitoring with session recording, and export session lists on a schedule for evidence	Confirm which access counts as vendor access in your program, and whether system-to-system remote access needs a separate method outside the gateway
CIP-005-7 R2 Part 2.5 (Disable active vendor access)	Provide one or more methods to disable active vendor remote access quickly, both for individual sessions and for vendor accounts	Terminate active connections from the admin console, disable the vendor account or group, and document the steps in the runbook; test the procedure on the lab gateway before go-live	Confirm the time expectations in your internal procedures and how disabling is recorded as evidence in your environment
R2 technical feasibility qualifier	R2 applies where technically feasible, so any exception must be justified and documented under the Technical Feasibility Exception process	A gateway can be used in most designs, so document a feasibility decision only where a specific system cannot route through an Intermediate System	Confirm with the Regional Entity or your compliance lead whether any TFE is needed and how it is recorded
CIP-002-5.1a Applicable Systems scope	Determines which BES Cyber Systems, PCA, EACMS and PACS the R2 parts reach, based on high, medium or low impact categories	Build the gateway inventory from your CIP-002 categorization, tagging each target with its impact rating and whether it has External Routable Connectivity	Confirm the categorization with your CIP-002 approval record, since low impact assets follow different rules under CIP-003

Which BES Cyber Systems and Cyber Assets the gateway must cover

The gateway has to cover every BES Cyber System that the CIP-002-5.1a impact categories place in scope for Interactive Remote Access, and the scope starts with a classification, not with the tool. CIP-002-5.1a sorts BES Cyber Systems into high, medium and low impact using the bright-line criteria in its Attachment 1. High impact systems are mainly tied to Control Centers, and medium impact systems include, for example, generation of 1500 MW or more at one plant or Transmission Facilities at 500 kV or higher. Read the criteria against your own asset list before deciding which systems the Intermediate System must front. Most CIP requirements are written as tables keyed to *Applicable Systems*, so CIP-005-7 and CIP-007-6 each name their own population, and that population can include associated EACMS, PACS and PCA, not only the BES Cyber Systems themselves.

Those associated systems matter because a gateway that protects the control system but leaves its access control, monitoring or physical access systems reachable directly will fail a scoping review. Access paths into the EACMS that authenticate operators, the PACS that control doors and badges, and the PCA that share a network zone with the BES Cyber System all need a clear answer about how the initiating device reaches them. The planning date matters too. CIP-003-9 added vendor electronic remote access controls for low impact BES Cyber Systems and became enforceable on 1 April 2026. CIP-005-8, approved by FERC Order No. 919 for virtualization, is listed as effective 1 July 2028, and CIP-003-11 under Order No. 918 adds remote user authentication for low impact assets and is effective 1 July 2029. Design the gateway's identity and logging model so these later requirements can be added without rebuilding it.

Before you commit to a design, confirm scope in writing with your Compliance Enforcement Authority and reconcile the asset list with the current CIP-002 identification. Ask which Cyber Assets the Regional Entity considers in scope, how it treats virtualized environments, and whether any system qualifies for a Technical Feasibility Exception. The NERC CIP Reliability Standards page lists current status and US effective dates, and the CIP-005-7 standard defines the Applicable Systems for the remote access requirements. Record the outcome as a scoped inventory that maps each system to its impact category, its associated EACMS, PACS and PCA, and the network path that the Intermediate System will control.

Guacamole or JumpServer for a CIP Intermediate System

Guacamole is a clientless gateway. Engineers and vendors reach SSH, RDP and VNC targets from an HTML5 browser, so no client software is installed on the initiating Cyber Asset. The Java web application handles the interface and authentication, while the guacd daemon loads the protocol plugin that connects to the target on the user's behalf. That split makes the browser the only path into the enclave, which suits a small set of Windows or Linux hosts that vendors reach for maintenance. Its architecture documentation explains how the components divide the work.

Licensing: The project is released under Apache-2.0 with no edition ladder, so the gateway itself is the open-source build. Confirm the terms of any third-party extension you add before it enters the design.
MFA extensions: The manual documents Duo and TOTP, along with SAML, OpenID Connect and smart card single sign-on. Confirm that the second factor applies to every protocol path you use, including SSH and RDP, and that it runs before the target connection opens.
Session recording: A session recording player extension is documented. Confirm the recording format, where files are stored, how they are indexed for review, and how retention is enforced.
Database and high availability: Configuration can use MariaDB or MySQL, PostgreSQL or SQL Server. Plan redundancy for the database and for guacd instances separately, and confirm the supported clustering design with the Apache project or in the manual.

Before relying on Guacamole, verify that the MFA step cannot be bypassed on any protocol and that the gateway is the only route from the vendor network to the applicable system.

Controlling vendor remote access sessions in practice

This sequence shows how a utility moves a vendor from request to approved, time-limited, observable and revocable access through the Intermediate System, so the entity can evidence CIP-005-7 Parts 2.4 and 2.5 on demand. Each step names the output an auditor can later sample.

Register the vendor and scope the target systems
The entity's CIP owner records each vendor, the named individuals, the business reason and the specific Cyber Assets the vendor may reach through the Intermediate System. Access is scoped to those assets only, not to a network segment. The output is a vendor register entry that ties each identity to its target systems and to the applicable impact category under CIP-002. Confirm with your chosen platform whether vendor accounts can be defined as separate identities with their own roles and resource scopes.
Approve each session request before access
A vendor submits a request naming the system, the window and the work to be done. A designated approver inside the entity, distinct from the requester, approves or rejects it, and the approval is stored with a timestamp and identity. No session should be created until the approval exists. Check whether your edition provides ticket or just-in-time approval workflows natively, or whether approvals must be handled in an external ticketing system and linked to the session record.
Authenticate the vendor with MFA and encryption
The vendor signs in to the Intermediate System over encrypted transport using an identity that enforces multi-factor authentication, which covers Part 2.3. The initiating device never reaches the BES Cyber System directly, which covers Part 2.1. The output is an authentication log entry showing the MFA method and the source. Confirm how the identity provider integration handles vendor accounts and whether MFA can be required for every vendor login path, including SSH and RDP.
Grant time-limited access tied to the approval
The gateway creates a session or credential that is valid only for the approved window and target. Access expires without action from the entity, so an approval given for one maintenance window cannot be reused later. The output is a recorded grant with start and end times that matches the approval record. Ask the vendor for the exact expiry behavior and whether standing vendor accounts can be disabled when no request is open.
Monitor active vendor sessions in real time
Operators or the designated monitor view the list of active vendor sessions, including who is connected, to which asset and since when. This is the working method for Part 2.4, which requires one or more methods to determine active vendor remote access. The output is a documented monitoring procedure and a record of the monitoring checks. Confirm whether live session views, session lists and alerts on new connections are included in your edition or require a paid tier.
Record the session and retain the evidence
The gateway records keystrokes or screen output for the session, and the entity stores the recordings and the session metadata on its own infrastructure for the retention period set in its CIP evidence program. This gives the auditor a sample of what the vendor did, which supports the Part 2.4 determination and later review. Confirm recording coverage for each protocol you need, where recordings are stored, how they are indexed for search, and whether they can be exported with integrity controls.
Terminate sessions and revoke credentials on demand
When work ends early, when a vendor's access is no longer needed or when an anomaly appears, the designated operator terminates the active session and revokes the vendor's credential or grant. This is the method behind Part 2.5, which requires one or more methods to disable active vendor remote access. The output is a termination record showing who acted, when and what was disabled. Run a test termination in a non-production environment and confirm the time it takes to take effect on each protocol.
Close the request and review the session record
After each session, the entity compares the recording and access log with the approved request, confirms the vendor stayed within scope and closes the request. Exceptions are logged and assigned for follow-up. The output is a closed request package containing the approval, grant, MFA log, recording reference and termination record, which can be produced for an audit sample. Confirm with your implementation partner how this package is generated and whether it can be exported without manual assembly.

How NERC monitors compliance and what that means for evidence

NERC CIP compliance has no certificate. Your evidence for remote access controls is built for a Compliance Enforcement Authority that can select a method at any time, so the Intermediate System has to produce records that answer specific questions from the Regional Entity.

No CIP certificate exists

Nobody issues a CIP certificate for your Intermediate System. Compliance is judged by the Compliance Enforcement Authority, which is a Regional Entity or NERC, based on what you can show for each requirement. For a bastion design, this means the gateway configuration, the MFA settings and the session logs are the proof, so each claim about remote access must point to a record you can produce on request.

Audits, spot checks and self-reports

The Compliance Enforcement Authority can monitor through Compliance Audits, Spot Checks, Self-Certifications, Self-Reports and self-logging, among other methods. A spot check can arrive with little notice, so the Intermediate System should be able to show current configuration and recent session history at any time, not only during a planned review. Ask your team which of these methods applies to each CIP requirement you own.

Periodic data submittals

Some CIP obligations require you to send data to the Regional Entity on a schedule. For remote access, that can include lists of vendor access paths, active session records and evidence of method changes. Build exports from the bastion and its identity source before you need them, and confirm with your Regional Entity which data fields and formats it expects.

Regional Entity role under Section 400

NERC develops the CIP standards, but Regional Entities and NERC monitor and enforce them under the Rules of Procedure, Section 400. Your Regional Entity is therefore the body that reviews your evidence and interprets how the Intermediate System meets Part 2.1 through 2.5. Confirm early which Regional Entity covers your footprint and how it handles questions about session recording design.

Technical feasibility exceptions

CIP-005-7 R2 applies where technically feasible, and NERC runs a formal Technical Feasibility Exception process for cases where a requirement cannot be met. A TFE is an application with its own documentation and approval, not a verbal agreement. If a legacy system cannot sit behind an Intermediate System, document the technical reason, the compensating controls and the review date before the gap is discovered in an audit.

Penalty exposure and evidence quality

Civil penalties for violations are set under 18 CFR 385.1602, which adjusts penalty amounts over time. Confirm the current figures with the Federal Energy Regulatory Commission rather than relying on older summaries. The practical point is that a missing session log or an undocumented MFA exception can turn a minor finding into a larger one, so evidence retention should be designed in from the start.

CIP-005 evidence auditors ask for and which component produces it

This table maps each evidence item an auditor is likely to request for CIP-005 Interactive Remote Access to the component that produces it and how long to keep it. Read it as a starting inventory: the named component is where the record is usually generated, while the Compliance Enforcement Authority decides what it accepts for a given entity.

Evidence item	Source component	Retention considerations
Network and access diagrams showing Intermediate System placement	Network documentation and firewall configuration, validated against the gateway's listening interfaces	Keep versioned diagrams with dated revisions; process documentation is required to show how diagrams are updated after changes
List of Interactive Remote Access paths and users	Gateway policy and identity provider group membership exports	Export on a fixed schedule and at each change; confirm with your Regional Entity how often lists must be reproducible
MFA configuration records for Part 2.3	Identity provider authentication policy and gateway login logs	Retain configuration snapshots and sample authentication events; confirm the MFA method is documented per session path
Encryption configuration terminating at the Intermediate System (Part 2.2)	Gateway TLS or protocol settings and certificate inventory	Retain configuration baselines and certificate records for the audit period; process documentation should describe renewal
Session logs and recordings	Gateway session recording store, with SIEM ingestion for event logs	Confirm recording storage size, retention period and access controls with your compliance lead before deployment
Vendor session monitoring records (Part 2.4) and disable procedures (Part 2.5)	Gateway active session view, SIEM alerts, and ticketing for vendor access approvals	Keep the disable runbook and test records; process documentation is required to show who can revoke access and how
Change records for access paths and gateway configuration	Ticketing system linked to gateway and firewall change logs	Retain change tickets with approvals alongside the configuration history they produced

What the gateway alone does not satisfy

A compliant Intermediate System covers only part of CIP-005 and touches several other standards. The cards below cover the decisions and records that sit outside the gateway, and that an assessor will ask about alongside the session logs.

Technical feasibility determination

CIP-005 R2 applies where technically feasible, so the reasoning behind any system that cannot route Interactive Remote Access through an Intermediate System is a decision in its own right. Document which Cyber Assets are excluded, who approved the determination, and what compensating controls apply. Confirm the current eligibility criteria with NERC and your Regional Entity before relying on an exception, since an undocumented exception is a common finding.

Personnel and training records

CIP-004 governs who holds access to BES Cyber Systems, their background checks, training and access revocation. A gateway can enforce MFA and role mapping, but it cannot prove that a user completed the required training or that a departing contractor's access was removed on time. Connect the gateway's user list to the HR and access-request process, and keep training evidence for each person granted remote access.

Electronic Security Perimeter design

CIP-005 Part 1 requires the Electronic Security Perimeter and its access points to be defined and controlled. The Intermediate System must sit at a defined boundary, and the network paths around it must not provide a bypass. Map every routable path into the applicable Cyber Assets, document the firewall rules that enforce the perimeter, and verify with periodic testing that no direct session from an engineer workstation reaches the control network.

Patch and malware controls

CIP-007 covers security patch management, malicious code prevention and system event logging for applicable systems. The gateway host is itself an Electronic Access Control or Monitoring System in many designs, so it needs the same patch cadence, hardening baseline and anti-malware coverage as other in-scope servers. Ask which assets the gateway belongs to in your classification and schedule its patching around outage windows.

Incident response and reporting

CIP-008 requires a Cyber Security Incident response plan with defined roles, testing and reporting. A suspicious vendor session through the gateway is a case the plan should name explicitly, including how the session is terminated, preserved and reported. Test this path in a tabletop exercise so that the operators know who can disable a vendor session and how the recording is handed to the response team.

Vendor contract terms

Vendor remote access falls under CIP-013 supply chain risk management, and the contract shapes what the vendor may do through the gateway. Terms should cover which vendor personnel may connect, MFA responsibilities, notification of security events, and the vendor's own handling of credentials and recordings. Confirm with counsel and your supply chain team which terms your program needs, since the required content depends on your risk assessment.

Questions utilities ask before building an Intermediate System

What does an Intermediate System cost to build and run?

The software license is not the main variable: JumpServer Community Edition and Apache Guacamole are both free to download, so cost comes from the work around them. Those components are the engagement scope, the hardware or cloud capacity for the gateway, session recording storage, the identity and MFA integration, and ongoing patching and administration. Costs recur for infrastructure, storage, patching and staff time, while design, build, testing and evidence preparation are one-time. The number of assets and whether you need high availability push the design up. Ask any implementation partner for a fixed-scope quote with written scope, deliverables and timelines, and ask which items depend on asset count or edition.

How long does a CIP remote access rollout take?

Timeline depends on the number of systems in scope, how many protocols must be routed (SSH, RDP, VNC, databases), how many vendors need access, and how quickly your identity source and network changes can be approved. Each Electronic Access Control or Monitoring System and each Intermediate System change also runs through your change management process before go-live. DeployOpen agrees a timeline in the written scope before work starts, so ask for milestones tied to asset groups and to your change windows rather than a single end date.

What must a utility provide before implementation starts?

Before design begins, the utility needs an accurate inventory of the applicable Cyber Assets, grouped by impact category under the CIP-002 bright-line criteria, and a list of which vendors and engineers initiate Interactive Remote Access. You also need a chosen identity source, typically Active Directory or LDAP, a MFA method that the gateway can use, and a clear list of firewall and routing changes. Guacamole supports Active Directory and LDAP and several MFA extensions, and JumpServer supports LDAP and SSO in its Enterprise tiers, so confirm the exact integration with the vendor before design sign-off.

Can our staff run an Intermediate System without a partner?

Many utilities have the skills to run a bastion internally, but the work is continuous: patching the gateway, rotating credentials, reviewing session logs, handling vendor onboarding, and keeping evidence ready for Compliance Audits and Spot Checks. The question is whether the team has capacity for those tasks alongside CIP obligations, and whether it has staff who can test failover and recovery. A partner can plan, implement, harden, document and support the system under a retainer, while the utility keeps ownership of its compliance decisions. Ask partners to separate one-time delivery from recurring support in the scope.

Which JumpServer edition limits matter for a utility?

The main limit is asset count and high availability. JumpServer's pricing page lists a free self-hosted Community edition for up to 5,000 assets in a standalone topology, while the paid tiers add active-standby high availability and a full HA cluster at the top tier. The comparison also lists features such as ticket and just-in-time approval workflows, custom roles, SSO, RADIUS and LDAP HA as Enterprise features, and Enterprise adds an SLA and account manager. Confirm with the vendor which protocol proxies, such as RDP or database proxies, your design needs, because some are Enterprise components.

How do CIP version changes affect an Intermediate System design?

CIP-005-7 R2 requires the Intermediate System, encryption that terminates there and MFA for all Interactive Remote Access, so that design is the baseline today. Later versions change scope: FERC Order No. 919 approved revised standards, including CIP-005-8, that accommodate virtualization and are listed as effective 1 July 2028, and CIP-003-11 adds remote user authentication for low impact assets with an effective date of 1 July 2029. CIP-015-1 adds internal network security monitoring with future enforcement from 1 October 2028. Design the gateway, logging and identity integration so new Cyber Asset types and monitoring can be added without a rebuild.

What does an implementation partner deliver for CIP evidence?

A partner delivers the technical and documentation work under the written scope: architecture, installation on your infrastructure, integration with your identity source and MFA, configuration aligned to the CIP-005-7 requirements, hardening, backup, testing, runbooks and the evidence that shows how the system operates. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications. Your Regional Entity or NERC decides compliance, so ask partners to show which artifacts they produce and how those map to the applicable requirement parts.

How DeployOpen scopes, builds and supports the CIP remote access gateway

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, which for a utility usually means its control center network, data center or enclave. For Open source PAM for NERC CIP remote access, the work starts with a written scope that maps each Interactive Remote Access path, vendor session and evidence source to the applicable CIP requirements.

How we scope

Inventory every Interactive Remote Access path into in-scope BES Cyber Systems and their associated Cyber Assets, with the Applicable Systems each one falls under
Confirm impact categorization with the client's own CIP-002 records before any gateway design is fixed
Agree the written scope, deliverables and timeline with the client before work starts, as engagements are fixed-scope

How we build

Deploy the Intermediate System on the client's own infrastructure, with Guacamole or JumpServer configured so initiating devices never reach applicable Cyber Assets directly
Integrate multi-factor authentication with the client's existing identity source and document each factor used for every session
Test the gateway against the CIP-005 Part 2 controls, including session visibility and the ability to disable vendor access, before handover

How we hand over

Deliver configuration baselines, network diagrams and runbooks that show how each Part 2 control is met and where it is evidenced
Document the vendor session workflow, including how active sessions are identified and how access is disabled during an incident
Walk operations and compliance staff through evidence collection so audit samples can be produced without rebuilding records

How we support

Support ongoing operations, upgrades, backups and hardening of the gateway as a retainer, once the engagement ends
Re-test the access path after platform upgrades or changes to the CIP standards that apply to the client
Prepare evidence updates for compliance assessments, while the Compliance Enforcement Authority and auditors make the determinations