Why NERC CIP-005 changes self-hosted remote access for energy and utilities
If your team must reach BES Cyber Systems from outside the plant or control center, the short answer is a browser-based Apache Guacamole gateway that acts as an Intermediate System, sits outside the Electronic Security Perimeter, and enforces encryption, multi-factor authentication, vendor session detection and logging before any interactive session reaches an in-scope asset. Whether CIP-005-7 applies to a given session is not a question of technology. It depends on the impact category each BES Cyber System falls under and on which assets have routable connectivity. CIP-002-5.1a sorts systems into high, medium and low impact using bright-line criteria in its Attachment 1, and CIP-005-7 requires Interactive Remote Access to pass through an Intermediate System only for the applicable scope in its tables. Start by asking your compliance lead to confirm the impact rating of each target system and whether each one has External Routable Connectivity, because those two answers decide the architecture.
The Intermediate System is the piece most teams underestimate. Guacamole's web application handles authentication and the browser interface, while the guacd daemon loads the protocol plugins that connect to RDP, VNC or SSH targets on the user's behalf. That split means the gateway, not the operator's laptop, opens the session into the control network, which is the property CIP-005-7 is designed to create. Confirm with your auditor and with the NERC standard text how your Electronic Access Points, Intermediate System and EACMS classification should be documented, since these labels carry the evidence burden. Guacamole's documented extensions for TOTP, Duo, SAML and smart card login cover the authentication requirement, but the MFA method you choose must be verified against the standard's wording for your environment. The requirement is also not a certification. NERC and the Regional Entities monitor compliance through audits, spot checks and self-reports, and there is no CIP certificate to hold. DeployOpen can plan, build, harden and document a gateway and prepare evidence for that monitoring, but it does not issue audit results. Ask any partner, including us, to show how each design decision maps to a specific requirement part and to name the owner of each piece of evidence before work begins.
Which CIP requirements shape the build and what each means for the design
This table maps the NERC CIP requirements that most affect a Guacamole deployment to the design decision each one forces. Read it as a checklist of questions to settle with your compliance team, because which rows apply depends on how your BES Cyber Systems are categorized under CIP-002-5.1a. The main takeaway is that the gateway is only one part of compliance: the Electronic Security Perimeter, vendor session controls, and the monitoring and enforcement model all shape what the design must record and prove.
| Requirement | What it asks for | What it means for the Guacamole deployment |
|---|---|---|
| CIP-002-5.1a impact categories | Sort BES Cyber Systems into high, medium or low impact using bright-line criteria in Attachment 1 | Confirm the impact rating of each target system first. The rating decides which CIP-005 parts apply and whether the gateway itself falls in scope. |
| CIP-005-7 Electronic Security Perimeter | Routable-connected assets of high and medium impact BES Cyber Systems sit inside an ESP | Decide whether the Guacamole host is inside the ESP, at its boundary, or an associated access control system. Document every routable path into the perimeter. |
| CIP-005-7 Intermediate System | All Interactive Remote Access passes through an Intermediate System with encryption and MFA | Place Guacamole as the access point that brokers every interactive session. Users should not reach target hosts directly, so the gateway must enforce MFA before any session opens. |
| CIP-005-7 detect and disable vendor sessions | Methods to detect and disable active vendor remote access sessions | Configure session monitoring and an administrative kill path in the gateway, and test that a vendor session can be ended while active. Record who can perform this action. |
| CIP-013-2 vendor coordination | Supply chain risk management plan covering vendor coordination of remote access, incident notification and software integrity | Vendor accounts, approval steps and session records must match the written plan. Review the plan at least every 15 calendar months and align gateway procedures with it. |
| CIP-015-1 internal network security monitoring | Approved by FERC on 26 June 2025, enforceable from 1 October 2028 (NERC CIP standards page) | Plan now for gateway logs to feed network monitoring. Confirm with your Regional Entity which monitoring data will be required once the standard is enforceable. |
| NERC enforcement model (Rules of Procedure) | Compliance is monitored through audits, spot checks, self-certifications, self-reports and periodic data submittals | Keep evidence available on demand: configuration baselines, access lists, session logs and change records. There is no CIP certificate, so the design must produce proof that an auditor can examine. |
How high, medium and low impact categories change the design
High impact BES Cyber Systems sit at the top of the CIP-002-5.1a categorization, and in practice this mainly means qualifying control centers, including those of Reliability Coordinators. Interactive Remote Access to these systems must pass through an Intermediate System with encryption and multi-factor authentication under CIP-005-7, and the systems must sit inside an Electronic Security Perimeter. The gateway is therefore the single controlled entry point for every interactive session, and its scope usually covers all operator, engineer and vendor paths into the control center environment.
- Gateway scope: Every interactive path, including vendor and contractor paths, is routed through the Intermediate System with no direct session to the Electronic Access Point.
- Applicable Systems: High impact BES Cyber Systems are the primary scope, and the associated EACMS, PACS and PCA inventory must be kept current for each one.
- Vendor sessions: Methods to detect and disable active vendor remote access sessions must work for every vendor account, with documented procedures for disabling them.
- Evidence set: Expect session logs, MFA configuration records, change records for the gateway and proof of Electronic Security Perimeter boundaries.
- Supply chain: Coordination of vendor-initiated remote access falls under the CIP-013-2 plan, which is reviewed at least every 15 calendar months.
Confirm with your compliance team which of your control centers qualify as high impact under the Attachment 1 criteria before sizing the gateway.
Medium impact BES Cyber Systems include, for example, generation of 1500 MW or more at one plant and Transmission Facilities at 500 kV or higher. The CIP-005-7 controls apply to medium impact systems with External Routable Connectivity, so the first design question is which assets have routable connections outside the Electronic Security Perimeter. Systems without that connectivity follow a different scope, so the gateway may cover a subset of the fleet even when the entity operates many medium impact assets.
- Gateway scope: The Intermediate System covers interactive access to medium impact systems with External Routable Connectivity, which can differ from the plants or substations that have no such connection.
- Applicable Systems: Scope tables name medium impact BES Cyber Systems with External Routable Connectivity, along with their EACMS, PACS and PCA, so each asset needs a documented connectivity status.
- Plant and site access: Field engineers and vendors at remote sites often reach systems through local workstations, which must be inventoried and placed inside the same controls.
- Evidence set: Keep a current list of routable connections, Electronic Security Perimeter diagrams for each site and the access logs that show Intermediate System use.
- Monitoring: Plan for CIP-015-1 internal network monitoring, which is enforceable from 1 October 2028, when designing log retention.
Ask your implementation partner how the gateway will tag each medium impact asset so that scope changes are visible during an audit.
Low impact BES Cyber Systems are the remaining systems at listed assets. CIP-003-9 adds vendor electronic remote access controls for low impact BES Cyber Systems and became enforceable on 1 April 2026, so vendor remote sessions to these systems now need defined controls. CIP-003-11, approved in Order No. 918, adds remote user authentication, protection of authentication information in transit and malicious communication detection for low impact assets, with an effective date of 1 July 2029. Designs should leave room for those requirements now, even though they are not yet enforceable.
- Gateway scope: Vendor electronic remote access to low impact systems needs its own access path or a clearly defined extension of the shared gateway, and the design should record which assets use it.
- Applicable Systems: Low impact requirements apply at the asset level, so the inventory must list each low impact asset and the vendor access that reaches it.
- Vendor controls: The CIP-003-9 controls cover vendor electronic remote access, so vendor accounts, session approval and session recording need documented procedures.
- Evidence set: Keep records of vendor access granted, the controls in place for each asset and the procedures for review.
- Future readiness: Plan remote user authentication and authentication protection in transit before the 1 July 2029 effective date for CIP-003-11.
Confirm with your compliance lead whether a single gateway design can serve both low impact and higher categories, and how the evidence for each is separated.
Which platforms fit an energy CIP-005 remote access design and why
A CIP-005 remote access design is built from a few distinct components: a clientless gateway, the process that starts and launches sessions, the database that holds accounts and connection rules, and the tools that do not belong in an interactive path to BES Cyber Systems. The cards below cover each choice and what to confirm before it reaches a compliance review.
Apache Guacamole as the gateway
Guacamole is the web application that users reach through a browser, so no client software is installed on the laptop used for remote sessions. It is released under Apache-2.0, and version 1.6.0 was released on June 22, 2025. Its extensions cover SAML, OpenID Connect, smart card login, Duo and TOTP, and a session recording player, which map to the Intermediate System requirements in CIP-005-7. Confirm with the entity's compliance team that the gateway sits where the Electronic Security Perimeter design requires and that its logs meet the entity's retention rules.
guacd and protocol plugins
The Guacamole web application speaks only the Guacamole protocol. The guacd daemon loads a protocol plugin for RDP, VNC or SSH and makes the connection to the target host on the user's behalf. This split means the daemon is the component that talks to BES Cyber Systems, so its host placement, outbound rules and patch cadence need the same scrutiny as the web tier. Check that each protocol you need is served by a plugin you have tested, and that no unused plugin or protocol is left enabled.
Database backend for accounts and rules
Guacamole stores connection definitions, user accounts and permissions in a database. The manual documents MariaDB or MySQL, PostgreSQL and SQL Server backends. Choose the engine your entity already operates and can back up, patch and restore under its CIP-009 recovery plans. Access to this database effectively controls who can reach which asset, so restrict its administrative accounts, log changes and confirm the database falls inside the same CIP evidence scope as the gateway.
Authentication extensions for MFA
CIP-005-7 requires encryption and multi-factor authentication on all Interactive Remote Access. Guacamole's documented extensions include Active Directory and LDAP, Duo and TOTP, CAS, OpenID Connect, SAML and smart card single sign-on. Pick one primary factor source and test failure modes, such as lockout, token drift and identity provider outages, before cutover. Ask the entity's compliance lead which MFA method its evidence set accepts for both vendor and staff access.
RustDesk for interactive support only
RustDesk is designed for attended and unattended remote support from a desktop client and relay infrastructure. That model is different from a browser gateway with a defined Intermediate System, and it can complicate the evidence for where sessions originate and terminate. Treat RustDesk as a scoping caution for CIP-005 interactive access. If the entity considers it for support on non-BES assets, confirm in writing that it sits outside the Interactive Remote Access path to high and medium impact BES Cyber Systems.
Confirm the Intermediate System with evidence
Whether a given host or service counts as the Intermediate System depends on how the entity documents its Electronic Security Perimeter, Applicable Systems and access paths, not on the product alone. Ask the compliance team to map every route into the BES Cyber System, including vendor and cloud paths, before naming the gateway. For manufacturing OT and machine vendor access, see the sibling topic on OT remote access. For air-gapped networks, see the sibling topic on disconnected remote administration.
How a Guacamole gateway fits the Electronic Security Perimeter
The Intermediate System is the point where every Interactive Remote Access session to a BES Cyber System must terminate before it reaches an in-scope asset. CIP-005-7 requires that routable-connected assets of high and medium impact BES Cyber Systems sit inside an Electronic Security Perimeter, and that all Interactive Remote Access passes through an Intermediate System with encryption and multi-factor authentication. In a Guacamole design, the Intermediate System is the gateway itself. Engineers should place it at the ESP boundary so that the browser session from a remote user ends on the gateway, and a second, separately controlled connection carries the RDP or SSH hop to the target. Confirm with your Regional Entity whether it accepts the gateway as the Intermediate System or expects a different placement, and record that decision in the CIP-005 documentation before cutover.
Keep the Guacamole web application and guacd on separate hosts or separate trust zones. The web application handles authentication, authorization and the user interface, and guacd loads protocol plugins that open the actual RDP, VNC or SSH sessions. Splitting them lets you restrict which network paths guacd can use, expose only the web tier to the user-facing network, and limit the protocol daemon to the ports the target systems need. Authentication and MFA extensions belong on the web tier, and the database backend that stores connection definitions and permissions should be reachable only from that tier. Document each host, its firewall rules and its role, because each one becomes a component auditors will ask you to explain.
The gateway itself becomes a high-value asset once it is the only path into the ESP, so treat it as an in-scope Cyber Asset with its own hardening, patching, logging and access control. The DMZ versus dedicated jump zone decision is the central trade-off. A DMZ placement is easier to reach from remote users and may simplify the connection to the corporate identity provider, but it places the gateway in a more exposed segment and increases the number of paths an attacker could use to reach the ESP. A dedicated jump zone with tightly defined conduits keeps the gateway closer to the assets it protects and simplifies the perimeter diagram, but it requires more firewall work and clear rules for how the gateway reaches the corporate identity and logging systems. Ask your implementation partner to map both options against the ESP diagram and the Electronic Access Points before choosing.
How a CIP-005 remote access rollout moves from scoping to audit-ready operation
This sequence turns an undefined remote access need into a documented design, a hardened gateway, tested vendor controls and an evidence set that a Compliance Enforcement Authority can review. Each phase closes with a named output so the next phase starts from written facts rather than assumptions.
Scope BES Cyber Systems and Applicable Systems
The compliance lead and the OT engineers confirm which assets are BES Cyber Systems and how each one was categorized under CIP-002-5.1a as high, medium or low impact, using the bright-line criteria in its Attachment 1. Next, the team lists the Applicable Systems for each category, including EACMS, PACS and PCA where they apply, and records which assets have routable connectivity. The output is a signed categorization record and an asset inventory that every later phase references. You know this step is done when every interactive access path into those assets appears on the list.
Design the Electronic Security Perimeter and Intermediate System
The architecture team draws the ESP boundary around the in-scope assets and places the Intermediate System where all Interactive Remote Access must cross. The Guacamole gateway, its guacd host and its database sit inside the design, with the placement reviewed against the requirements of CIP-005-7. The output is a network diagram, an access flow document and a list of permitted inbound and outbound paths. Confirm with your compliance lead and your regional entity's expectations before building, because placement decisions are difficult to change later.
Deploy and harden the gateway
The implementation team installs Apache Guacamole on dedicated hosts, using the native or containerized method that matches your change control, and configures guacd and the protocol plugins only for the protocols you need. They remove default accounts, restrict administrative interfaces, apply the platform's hardening guidance and set up time synchronization and host baselines. The output is a build record, a configuration baseline and a list of open ports, all stored under change management. The step closes when a scan of the gateway matches the approved baseline.
Integrate MFA and vendor access controls
The identity team connects the gateway to your directory and enforces multi-factor authentication for every interactive session, using the MFA and single sign-on extensions your environment supports. Vendor accounts are created as individual identities with connection permissions limited to named assets, and each vendor path is tied to an approval workflow and a time window. The output is an access matrix that maps each user group and vendor account to permitted connections. The step is complete when a test login without the second factor fails and a vendor account cannot reach an asset outside its matrix.
Build logging and session recording
The security team configures session recording, connection logs and authentication logs on the gateway and forwards them to a central log platform that is protected from the users whose sessions it records. Retention periods are set with the compliance lead against the requirements of CIP-007-6 and related standards, and storage access is limited to a defined group. The output is a logging specification, a retention schedule and sample records from a test session. The step is done when a test session appears in the central platform with the user, target asset, start time and end time.
Test vendor session detection and disablement
The operations team runs scripted test sessions for each vendor account and verifies that the monitoring method identifies an active session and that the disable action ends it at the gateway and blocks reconnection. The team records the tested detection method, the response steps and the time taken to disable, and repeats the test after any configuration change. The output is a signed test report with screenshots or log extracts and a list of any gaps with owners. The step closes only when every vendor path has passed the disablement test or has a documented remediation plan.
Hand over evidence and operational runbooks
The DeployOpen team compiles the evidence set, which includes the categorization record, ESP diagrams, the configuration baseline, the access matrix, log samples, test reports and change records, and writes runbooks for daily operation, vendor onboarding, access review and incident response. The compliance lead and operations staff walk through each runbook and confirm they can run it without the implementation team. The output is a handover package and a training record. DeployOpen prepares the evidence, but the auditors and the Compliance Enforcement Authority decide whether it meets the standards, so confirm the review scope with them early.
What CIP auditors ask to see from a remote access gateway
This table maps the evidence a CIP-005 assessment usually asks for to the Guacamole component or supporting system that produces it. Compliance is monitored through Compliance Audits, Spot Checks, Self-Certifications and Self-Reports, not a certificate, so each row should be treated as material your team must be able to produce on request. Confirm the exact evidence format and retention with your Regional Entity and your compliance program.
| Evidence item | Produced by | What the assessor checks |
|---|---|---|
| Network diagrams showing the ESP and Intermediate System | Network architecture documentation, firewall rule exports | The Intermediate System sits in the path of all Interactive Remote Access, and the ESP boundary matches the diagram |
| MFA configuration records | Guacamole authentication extension settings (for example Duo or TOTP) and identity provider configuration | Every interactive remote session requires multi-factor authentication, with no bypass accounts left enabled |
| Encryption configuration for remote sessions | Guacamole web application TLS settings and guacd connection configuration | Traffic from the user to the Intermediate System and onward to the BES Cyber System is encrypted as the standard requires |
| Account and vendor access lists | Guacamole user and connection permission exports, identity provider group membership | Only named, authorized users and vendor accounts can reach specific Applicable Systems |
| Session logs and recordings | Guacamole database audit records and the session recording player extension | Each session can be tied to a user, a target and a time window, and logs are retained and protected |
| Vendor session detection and disable procedure tests | Gateway session monitoring procedure, test records from disabling a live vendor session | Active vendor remote access sessions can be detected and disabled, and the test was performed and documented |
| CIP-013 vendor plan entries | Supply chain risk management plan, vendor coordination records for vendor-initiated remote access | Vendor incident notification, vulnerability disclosure and remote access coordination are described and reviewed at least every 15 calendar months |
| Change records for gateway and firewall rules | Change management tickets, configuration baselines, version records for Guacamole components | Changes to the gateway, its authentication and its firewall rules were authorized, tested and documented |
What energy teams ask before hiring a partner for CIP-005 remote access
How much effort does a CIP-005 remote access project take?
Effort depends mostly on how many BES Cyber System sites and Cyber Assets sit in scope, how many vendors need Interactive Remote Access, and how much of the identity stack already exists. Each Intermediate System, the gateway placement inside the Electronic Security Perimeter, the MFA integration and the vendor session controls are separate work items, and each one multiplies when there are several control centers or substations. Ask any partner for a written scope that lists systems, sites, identity sources, vendor populations and evidence outputs, because a fixed-scope quote can only be priced against that list. The cost is one-time for design, build and hardening, and recurring for patching, access reviews and evidence collection.
How long does a CIP-005 remote access implementation usually take?
Duration follows the scope and the approval path inside the utility, not the software install. Most of the calendar time usually goes to architecture review, change control for the ESP and Intermediate System, testing of MFA and session termination, and evidence preparation. Ask a partner to tie its timeline to named milestones and to the utility's change board dates, and to state which items depend on the utility's own teams or vendors. No duration should be accepted without that dependency list.
What does the utility's compliance and OT team need to provide?
The work needs decisions and inputs from both groups. Compliance leads should confirm the impact categorization under CIP-002-5.1a, which assets are high or medium impact, which systems have External Routable Connectivity, and which requirement parts apply. OT and operations teams should confirm the network zones, the vendors and their current access paths, the change windows, and which Protected Cyber Assets and EACMS are involved. Without those inputs, a partner cannot place the Intermediate System correctly or prove that all Interactive Remote Access passes through it.
Can a small utility team run a CIP-005 remote access gateway itself?
A small team can operate a gateway if it has people who can patch the platform, manage accounts and MFA, review logs and maintain the evidence trail, and if the team has enough time for these tasks on a recurring basis. The main drivers are staff hours, on-call coverage for an access path that vendors depend on, and the skills needed for hardening and incident response. Many teams start with a partner for design and handover, then decide which recurring tasks stay in-house. Ask the partner to document the operating procedures and the evidence each procedure produces so the handover is testable.
How does a Regional Entity audit treat a self-hosted gateway?
The Compliance Enforcement Authority reviews the gateway as part of the Electronic Security Perimeter and the Intermediate System requirements, so the utility must show how each control works and how it was tested. Auditors monitor compliance through Compliance Audits, Spot Checks, Self-Certifications and other methods, so evidence should exist before an audit notice arrives. Entities registered as a Balancing Authority, Reliability Coordinator or Transmission Operator receive a compliance audit at least once every three years, and the maximum civil penalty is $1,584,648 per violation per day (18 CFR 385.1602). Confirm with your Regional Entity which evidence formats it expects, and ask any partner how it will prepare configuration baselines, session logs and vendor access records for review. DeployOpen prepares systems and evidence for assessments but does not issue audit results.
Can MFA or session recording be bought as a product?
Components such as MFA methods and session recording tools can be sourced separately, but the compliance outcome depends on how they are integrated and evidenced. Guacamole has documented extensions for Duo and TOTP multi-factor authentication, for SAML and OpenID Connect single sign-on, and for a session recording player, but each one still needs configuration, testing and an operating procedure. The purchase decision then turns on the identity provider the utility already uses, the storage and retention needed for recordings, and whether the utility wants a vendor for ongoing support. Ask any partner to show which requirement parts each component supports and which gaps remain for the utility's own process.
What should a partner be asked to prove in a CIP-005 design?
A credible design should show the Electronic Security Perimeter boundary, the Intermediate System placement, the encryption and MFA paths for every Interactive Remote Access route, and the procedure for detecting and disabling active vendor sessions. Ask for a traceability table that maps each design element to the applicable CIP-005-7 requirement part and to the evidence it produces. Request a test plan that includes a forced session termination, a failed MFA attempt and a log review. Confirm how these artifacts will be kept under the utility's CIP-004 and CIP-011 information protection rules.
What to ask an implementation partner before a CIP-005 remote access build
Start by asking the partner how it has handled CIP categorization before. Ask for the impact rating they assumed for each BES Cyber System, the Attachment 1 bright-line criteria they applied under CIP-002-5.1a, and who signed off on that categorization. A partner that cannot explain why a system is medium impact rather than low impact will struggle to scope the Electronic Security Perimeter, the Intermediate System and the EACMS and PCA records that follow from it. Ask them to walk through one categorization decision from a past engagement with the client details removed.
Next, test the ESP and Intermediate System design. Ask who draws the boundary, how the guacd host and the Guacamole web application are placed relative to the perimeter, and which interfaces are permitted to cross it. Ask how vendor session disablement works in practice: which console or API ends an active session, whether the operator can terminate it without a restart, how the vendor account is suspended, and how that action is logged. Require a written test plan that shows a live vendor session being detected and disabled before go-live. Also ask how recording storage is placed in OT-adjacent zones, and who can read recordings.
Finally, ask what the partner will not do. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, and the Compliance Enforcement Authority decides compliance. Ask how evidence packaging is organized against the CIP-005-7 requirement parts, who keeps the evidence after handover, and how separation of duties is enforced between the people who build the gateway, approve vendor access and review the logs. Confirm the patching and hardening process for guacd and the web application, including how the partner tracks upstream advisories and what change control applies inside a CIP environment.
How DeployOpen scopes, builds and supports CIP-005 remote access
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, which for this topic means the operator's control network boundary and Electronic Security Perimeter design. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory which BES Cyber Systems, EACMS, PACS and PCA are in scope and at which impact level under CIP-002.
- Map every remote access path, including vendor access, to the Intermediate System and the Electronic Security Perimeter.
- Record the written scope, deliverables and timeline for the engagement before any configuration begins.
How we build
- Deploy the Guacamole gateway and its authentication layer in the client's own environment, with encryption and MFA enforced at the Intermediate System.
- Configure per-vendor accounts, approval workflows, time limits and the controls used to detect and disable active vendor sessions.
- Test the design against the applicable CIP-005 requirements and document the results as evidence the compliance team can review.
How we hand over
- Deliver configuration baselines, network diagrams and runbooks that show how the gateway fits the Electronic Security Perimeter.
- Document session logging, recording and retention settings so audit evidence can be pulled without DeployOpen involvement.
- Walk the operations and compliance teams through procedures for vendor session revocation and incident response.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after handover.
- Patch and upgrade the gateway components on a schedule agreed in the retainer, with changes documented for the compliance record.
- Confirm with your compliance team which evidence an auditor will request, since DeployOpen prepares evidence but does not issue audit reports or certifications.
