CIP-005-7 R2 Remote access management: requirements and evidence

What CIP-005-7 R2 remote access management requires

CIP-005-7 R2 governs Interactive Remote Access and vendor remote sessions to in-scope BES Cyber Systems. In plain terms, it asks the entity to control how people and vendors reach these systems from outside the Electronic Security Perimeter, and to keep that control visible while sessions are active. The requirement has four parts. First, all Interactive Remote Access must pass through an Intermediate System, so the laptop or workstation that initiates the session never talks directly to the applicable Cyber Asset. Second, encryption must terminate at that Intermediate System. Third, multi-factor authentication must apply to every Interactive Remote Access session. Fourth, the entity must have methods to determine which vendor remote sessions are active, including system-to-system access, and methods to disable them. Part 2.1 through 2.3 cover the path and the login, while Parts 2.4 and 2.5 cover visibility and the ability to cut a session off.

The risk is straightforward. An unmanaged remote path gives an attacker, or a vendor engineer working outside agreed scope, a route into systems that control generation or transmission. Remote access is also one of the most common routes into operational environments, so auditors look closely at whether the entity can show each session's path, its authentication, and its end. In practice the hard parts are rarely the technology itself. Legacy jump hosts often predate the Intermediate System design and are hard to retire. Vendor tooling may open its own tunnels, route through vendor-managed cloud portals, or keep sessions alive for long periods. Proving a session was controlled means retaining logs that tie an authenticated user, the Intermediate System, and the target asset together. Entities should inventory every remote path, including those used by vendors and system-to-system connections, before deciding what to redesign.

R2 applies where technically feasible, which gives entities a narrow qualifier rather than an exemption, and the entity must document why a control cannot be met before relying on it. R2 carries a Medium Violation Risk Factor. Confirm the applicable systems, the current wording and any approved revisions directly in the NERC standard, and review your own remote paths against it with your Compliance Enforcement Authority's expectations in mind.

Which remote access paths fall under R2

R2 applies to remote access into high impact BES Cyber Systems and their PCA, and into medium impact BES Cyber Systems with External Routable Connectivity. The cards below separate the scoping decisions from the access paths, because the same asset can carry several paths with different controls and different amounts of work.

High and medium impact applicable systems

R2 covers high impact BES Cyber Systems and their associated Protected Cyber Assets, and medium impact BES Cyber Systems that have External Routable Connectivity. Low impact systems fall under CIP-003 instead. Start from the CIP-002 categorization and confirm, asset by asset, which systems carry routable connectivity. The list of in-scope systems drives every later step, so record the basis for each inclusion and exclusion in the evidence file.

Interactive remote access sessions

Interactive Remote Access is a user-driven session, such as a remote desktop, SSH shell or vendor console, that reaches an applicable Cyber Asset. Every such session must pass through an Intermediate System, must be encrypted so the encryption ends at that Intermediate System, and must use multi-factor authentication. Inventory who uses these sessions, from which networks, and which tools carry them, because each path needs its own routing rule.

System-to-system remote access

System-to-system access is an automated connection between systems, such as a vendor monitoring platform polling a substation device or a scheduled file transfer. It is not interactive, so it sits outside the Part 2.1 to 2.3 controls, but Part 2.4 and 2.5 still require methods to see and disable these active vendor sessions. Identify each automated feed, its endpoints and its owner before deciding how it will be detected and cut off.

Employee remote access paths

Staff remote access often arrives through several routes at once: a corporate VPN, a jump host, a remote desktop gateway or a vendor-managed tunnel. Each route that reaches an applicable Cyber Asset interactively has to terminate at an Intermediate System. Map every route, including emergency and break-glass access, and remove or retire any path that bypasses the Intermediate System, because one direct path can put the whole program out of scope of the evidence.

Vendor access paths

Vendor access is usually the hardest path to scope. Support engineers may connect from their own laptops, from managed service provider networks or through a vendor's cloud portal. R2 Part 2.4 and 2.5 require the entity to determine and disable active vendor sessions, so the entity needs a way to see and end each vendor connection, not only a contract clause. Confirm each vendor path with the vendor before the audit period begins.

Technically feasible routing decisions

R2 applies where technically feasible, so the scope document must record any path that cannot be routed through an Intermediate System and why. Common decisions include legacy devices with no supported remote session method, vendor appliances that only accept direct connections, and paths that break a real-time control function if rerouted. Each exception needs a documented justification and an alternative control. Ask the Regional Entity how it expects such decisions to be recorded before relying on them.

How an auditor tests R2 remote access

This table compares each part of CIP-005-7 R2 by how an auditor typically tests it, the evidence usually requested, and the findings that appear most often. Read it as a checklist for the records to hold before an audit, since the Regional Entity samples sessions and asks for proof of each control rather than a policy statement alone. The main takeaway is that a documented design is not enough; the auditor expects traces of real sessions that pass through the Intermediate System with MFA and a working way to end them.

Requirement part	Test approach and evidence requested	Common findings
Part 2.1: Intermediate System	Select a sample of Interactive Remote Access sessions and trace each one from the initiating Cyber Asset through the Intermediate System to the applicable Cyber Asset. Request network diagrams, firewall rules and session logs showing the Intermediate System as the only path.	Direct paths from vendor laptops or jump hosts to controls left open; firewall rules that allow a source to reach BES Cyber Systems without passing the Intermediate System.
Part 2.2: Encryption terminating at the Intermediate System	Inspect the protocols and TLS or SSH configuration for each session type, and confirm the encryption ends at the Intermediate System. Request configuration exports and a sample of session records showing the protocol used.	Sessions that are encrypted only to a proxy or bastion outside the Intermediate System; legacy clear-text protocols still enabled for some vendor tools.
Part 2.3: Multi-factor authentication	Review the authentication logs for a sample of logins, including vendor and contractor accounts, and confirm a second factor was checked for each. Request the MFA enrollment list, policy settings and any exceptions with approvals.	Vendor accounts or service identities that authenticate with a password alone; break-glass or shared accounts without a documented second factor.
Part 2.4: Determining active vendor sessions	Ask the entity to show, live or from recorded output, how it lists active Interactive Remote Access and system-to-system vendor sessions. Request the monitoring method, sample output and dates it was run.	No method for system-to-system sessions; monitoring that shows only sessions opened through the portal and misses direct connections.
Part 2.5: Disabling active vendor access	Walk through a test where an active vendor session is ended and confirm the access is removed. Request the procedure, the tool or command used and records of the test or a real disablement.	Procedure exists but has never been exercised; disabling a session at the portal leaves the underlying connection or credential active.

Implementing R2 in sequence

The sequence moves from knowing every remote path into the environment to a documented, tested set of controls that cover Intermediate System access, encryption, MFA, and vendor session visibility and disablement. Each step produces an artifact that an auditor can check against Part 2.1 through Part 2.5.

Inventory every remote access path
Start by listing each route into applicable high and medium impact BES Cyber Systems and their Protected Cyber Assets, including VPNs, jump hosts, vendor tools, vendor-managed service accounts and any system-to-system connections. Owners of the operations and IT teams usually build this list together, then check it against network diagrams and firewall rules. The step is done when every path is tagged as interactive or system-to-system, mapped to the systems it reaches, and assigned an owner.
Confirm where Intermediate Systems can be placed
Decide which paths can route through an Intermediate System and document any path where that is not technically feasible, since R2 applies where technically feasible. Placement is usually a hardened host or jump server outside the systems it protects, reached through an Electronic Access Point. The output is a diagram showing that the initiating Cyber Asset never reaches an applicable Cyber Asset directly, plus a written feasibility record for any exception.
Deploy and restrict the Intermediate System
Install the Intermediate System in its own hardened build, then limit it so that it reaches only the applicable Cyber Assets listed for each user or vendor. Firewall policy on a platform such as OPNsense can enforce source, destination, port and protocol limits, with aliases for address groups and rule logging turned on for later review. Confirm the result by testing from an unauthorized host and showing that the direct path is blocked.
Terminate encryption at the Intermediate System
Configure every Interactive Remote Access session so that encryption ends at the Intermediate System, with the session then carried to the target under a separate, controlled connection. Engineers should confirm the protocol versions and cipher settings with the organization's cryptography policy and record them in configuration baselines. The output is a packet capture or session test showing that the encrypted tunnel terminates at the Intermediate System for each access method in use.
Enroll MFA for all Interactive Remote Access users
Require a second factor for every Interactive Remote Access user, including vendor staff and administrators, and do not allow login without it. Identity platforms such as authentik or FreeIPA support TOTP, WebAuthn or FIDO2 keys and other factors, so the team should confirm which factors are approved and how recovery codes are issued and stored. The step closes when an enrollment list matches the access list and a login test without a second factor fails.
Build vendor session visibility and disablement
Set up one or more methods to determine active vendor remote sessions, including Interactive Remote Access and system-to-system connections, then set up one or more methods to disable them. Typical methods are session logs on the Intermediate System, a live list of active connections, and an administrative kill switch that drops a session and revokes its access. The output is a recorded test in which an active vendor session is found, then terminated, and the termination appears in the logs.
Document, test and retain the evidence
Write the procedure for each control, name the responsible roles, and set a test schedule that covers placement, encryption, MFA and session disablement. Keep dated configuration exports, test results, access lists, and logs in a location that matches the organization's evidence retention plan. Ask your CIP compliance lead and any external assessor to confirm which artifacts they expect, because the Regional Entity makes the final determination of sufficiency, not the implementation partner.

How the Intermediate System and encryption termination fit together

The request flow under CIP-005-7 R2 has three hops, and the middle one carries most of the compliance weight. The initiating Cyber Asset, such as a vendor laptop or an engineer's workstation, opens an encrypted session to the Intermediate System. The Intermediate System terminates that encryption, authenticates the user, and then opens a separate connection to the target BES Cyber System or its Protected Cyber Assets. The initiating device never reaches the target directly. Encryption ends at the Intermediate System rather than at the asset, so the Intermediate System is the point where the session becomes visible and controllable.

That placement is why the Intermediate System's configuration and logs matter as evidence. An assessor will expect to see that every Interactive Remote Access path into an applicable system runs through it, so the network design, firewall rules and asset inventory should show no alternative route, such as a direct VPN or a jump path that skips the platform. Confirm with your network team that the Intermediate System sits in a location where routing and access rules actually force traffic through it, and record how that was verified. Document the authentication events, session start and end times, and the source and destination of each connection, and make sure these logs are retained in a form that can be produced for the audit period. Your own retention periods and log sources should be confirmed against the Regional Entity's expectations and your internal evidence program.

For a self-hosted design, the Intermediate System is usually a hardened host or a set of hosts that you own and operate, and the choice of components determines how easily the evidence can be produced. A reverse proxy or access gateway can terminate TLS and enforce MFA before forwarding a session, and a packet filter such as OPNsense can restrict the Intermediate System so it reaches only the approved targets. Decide early who administers the Intermediate System, how its own access is controlled under the rest of the CIP program, and how changes to its rules are recorded. Ask any implementation partner to show, before build starts, which logs will prove the three hops occurred as designed.

Evidence that passes an R2 review

A CIP-005-7 R2 review tests whether remote access actually follows the design, not whether a policy says it should. The cards below cover the artifacts that show the Intermediate System path, encryption, MFA and vendor session control, and how to keep them current between audits.

Remote access network diagrams

Keep a dated diagram that shows every Interactive Remote Access path from the initiating Cyber Asset through the Intermediate System to the applicable BES Cyber System and its Protected Cyber Assets. Label the encryption termination point and the firewall rules on each hop. An assessor compares the diagram against live configuration, so any path drawn but not configured, or configured but not drawn, becomes a finding. Confirm the diagram covers high impact systems and medium impact systems with External Routable Connectivity.

Configuration exports showing no direct path

Export firewall and gateway rule sets on a schedule and retain them with timestamps. In OPNsense, rules can pass, block or reject traffic by source, destination, port and protocol, so the export should show that no rule permits an initiating device to reach a protected Cyber Asset directly. Use aliases to group addresses, and record which alias represents the Intermediate System. Ask whether the export captures both the current and the prior configuration so changes can be traced.

MFA enrollment and authentication logs

Produce a roster of users who hold second factors for Interactive Remote Access, with enrollment dates and factor types such as TOTP, WebAuthn or hardware tokens. Pair it with authentication logs that show the second factor was checked on each session. In authentik, the authenticator validation stage checks enrolled factors during login, so its event records are a primary source. Confirm that static recovery codes and fallback methods are logged and governed, since an assessor may treat them as weaker paths.

Encryption configuration at the Intermediate System

Document the protocols, cipher suites and certificate chain used for each remote session, and show where the encryption ends. Under Part 2.2, the encryption must terminate at the Intermediate System, so the configuration export for that host and the tunnel or proxy settings should match the diagram. Record certificate issuance and renewal dates. Ask your engineers whether any web application traffic is inspected at the gateway and how that inspection is itself logged.

Active vendor session records

Part 2.4 requires a method to determine active vendor remote access sessions, including interactive and system-to-system access. Retain session start and end times, the vendor account, the target system and the Intermediate System used. Confirm that the record can be produced on request for an arbitrary date, not only for the current day. Gaps in session logs are common findings because teams assume the gateway retains data that it actually rotates out quickly.

Disablement records for vendor access

Part 2.5 requires at least one method to disable active vendor remote access. Keep a record of each disablement, including who triggered it, when, the session or account affected and the reason. Test the method periodically and retain the test result as evidence. An assessor will ask for a sample of disablements, so a record that shows only the policy and never the event will not satisfy the review. Keep these records alongside the access request tickets that authorized each session.

What meeting CIP-005-7 R2 costs

This table compares the cost components of meeting CIP-005-7 R2, showing who is paid for each, whether it is one-time or recurring, and what moves it up or down. No price figures are given because none are published in the supplied facts, so use the table to shape the questions you put to each quote.

Cost component	Who is paid	One-time or recurring	What drives it up or down
Intermediate System capacity (hardware or cloud)	Infrastructure provider or your own hardware budget	Both: build once, then recurring hosting or refresh	Number of remote users, concurrent sessions, number of high and medium impact sites in scope
MFA tooling	Platform vendor or open-source deployment labor	Mostly one-time setup, plus recurring token or license cost if commercial	Choice of factor types (TOTP, WebAuthn, hardware keys), whether an existing identity provider is reused, and whether open-source software removes license spend
Engineering time to route access paths	Internal engineers or implementation partner under a fixed-scope agreement	One-time, with changes each time a vendor or path is added	Count of vendor paths, number of applicable Cyber Assets, and how many systems must be re-tested after each change
Network and firewall changes	Internal network team or implementation partner	One-time for initial rules, recurring for rule review and change tickets	Number of rules, quality of existing documentation, and change control approvals required
Session visibility and disable methods (Parts 2.4 and 2.5)	Tooling provider or internal staff	Recurring for log storage and monitoring, one-time for configuration	Number of vendors, session volume, log retention needs, and whether disable actions are automated or manual
Evidence upkeep	Internal compliance staff or consultant	Recurring, tied to each audit period and each configuration change	Frequency of change, how evidence is collected (manual screenshots versus exported logs), and how well it is indexed
Vendor coordination and contract updates	Procurement, legal and the vendor	One-time for contract terms, recurring for vendor access reviews	Number of third-party vendors, whether they use their own remote tools, and how many need new terms
External review and auditor sampling	Independent auditor or your Regional Entity process	Recurring, tied to the audit cycle	Size of the sample, the audit scope, and how ready the evidence is when requested

Who owns R2 and who can help

The registered entity owns CIP-005-7 R2. It decides which BES Cyber Systems and associated Protected Cyber Assets fall under the requirement, sets the Interactive Remote Access policy, approves who may connect, and keeps the operating procedure that staff follow day to day. Accountability for a missed requirement sits with the entity, even when a vendor or partner built the system, so the entity must understand how the Intermediate System, MFA and session controls actually work.

Scope decisions: Confirm which high and medium impact systems, with External Routable Connectivity where applicable, require Intermediate System access, and record where the requirement is not technically feasible.
Access policy: Define who may initiate Interactive Remote Access, from which devices, and under which approvals.
Operating procedures: Write the steps for opening, monitoring and closing sessions, including what staff do when a vendor session looks wrong.
Evidence ownership: Decide who collects session logs, MFA records and vendor access reports, and where they are retained for audit.
Vendor agreements: Make sure contracts require vendors to use the entity's remote access path and accept the disable method.

Before engaging any outside party, confirm that your own staff can explain the R2 controls and produce the evidence without help.

CIP-005-7 R2 questions buyers ask

How much effort does CIP-005-7 R2 take to meet?

The effort depends mostly on how many high and medium impact BES Cyber Systems, and their Protected Cyber Assets, have Interactive Remote Access paths today. R2 needs four things in place: an Intermediate System that every interactive session must pass through, encryption that ends at that Intermediate System, multi-factor authentication for every interactive session, and methods to see and disable active vendor sessions. Each of these is a design and configuration task, followed by evidence work that shows the controls operate. Organizations with few remote paths and a single identity source usually have the smallest workload. Those with many vendors, shared accounts or legacy jump hosts usually need the most. Ask any partner to size the work by counting remote paths and applicable systems, not by a generic hour estimate.

How long does it take to implement R2 controls?

No duration is fixed by the standard, and any timeline should come from a written scope. The main variables are the number of remote access paths to re-route, whether an identity provider already supports multi-factor authentication, how many vendors must be onboarded to the new path, and how much change control your operations team requires during cutover. Plan the work in phases: inventory current remote paths, design the Intermediate System and authentication flow, pilot with one vendor, then migrate the rest. Keep in mind that evidence must show the controls working over the audit period, so starting early matters more than finishing fast. Ask for milestones and acceptance criteria in the proposal.

What does R2 require from our internal team?

Your team owns the decisions and the operating controls, even when an outside partner builds the systems. Expect to provide a current inventory of remote access paths and vendor accounts, access to the networks and cloud accounts where the Intermediate System will run, a named owner for identity and multi-factor policy, and operations staff who can approve cutover windows. Security and compliance staff should define which sessions count as Interactive Remote Access and who may approve vendor sessions. Someone also has to run the session review and disabling procedure after go-live. If these roles are unnamed, the project usually slows down at the first change approval.

Can we implement CIP-005-7 R2 in-house?

Yes, an organization can build and operate R2 controls with its own staff, and nothing in the standard requires an outside firm. The practical question is whether your team has current experience with jump hosts, identity federation, encryption termination, firewall rules and CIP evidence. Open-source components such as authentik, FreeIPA, OPNsense and Coraza can cover parts of the design, but each needs configuration, patching and documentation that your team must sustain. A common split is to keep ownership and operation internal while bringing in a partner for a fixed-scope build, hardening and evidence package. Whichever path you choose, the registered entity remains responsible for compliance.

What drives the cost of meeting R2?

Cost has two parts: one-time build work and recurring operation. One-time work includes the inventory, design, Intermediate System deployment, identity and multi-factor setup, vendor onboarding, testing and evidence collection. Recurring work includes patching, access reviews, session monitoring, log retention and audit support. The biggest drivers are the number of applicable systems and remote paths, the number of vendors and their tooling, whether you already run a multi-factor identity service, and how much cutover planning your change process demands. Ask any quote to itemize one-time and recurring costs, state what the partner is paid to do versus what your staff must provide, and list any licenses or hardware separately.

Can an implementation partner certify that we comply with R2?

No. An implementation partner can design, build, document and test the R2 controls and prepare evidence, but it cannot certify compliance. There is no CIP certificate. Compliance is monitored by the Compliance Enforcement Authority, a Regional Entity or NERC, through Compliance Audits, Spot Checks, Self-Certifications, Self-Reports and other mechanisms. Your organization owns the controls and the claims it makes to the auditor. Ask a partner to state its role in writing, to deliver evidence mapped to each R2 part, and to support your own compliance function during an audit.

How does technical feasibility affect the scope of R2?

R2 applies where technically feasible, so the standard does not force a control that cannot be implemented on a particular system. Feasibility is a question of the system's actual capability, not a convenience decision. If a device or vendor tool cannot route interactive sessions through an Intermediate System, document the specific technical limit, the compensating controls you apply, and the review that confirms the limit still holds. Under the current CIP framework, Technical Feasibility Exceptions are the process for requirements that cannot be met as written, and the enforcement page explains how they are handled. Confirm with your Regional Entity and your compliance counsel how any exception would be documented and approved before you rely on it.

How DeployOpen prepares R2 remote access controls

DeployOpen plans and implements the remote access path that CIP-005-7 R2 asks for, using self-hosted open-source platforms inside the client's own infrastructure. The organization keeps ownership of its controls, and the work produces the configuration, logs and records an independent auditor reviews.

How we scope

Engagements are fixed-scope, with systems, deliverables and timelines agreed in writing before work starts.
The scope lists which high and medium impact BES Cyber Systems and their PCA are reached by Interactive Remote Access.
The scope names which vendor remote access paths must be detected and disabled under Parts 2.4 and 2.5.

How we build

Configure an Intermediate System so the initiating Cyber Asset never reaches an applicable Cyber Asset directly.
Terminate encryption at the Intermediate System and enforce multi-factor authentication on every Interactive Remote Access session.
Set firewall rules with logging enabled, then test that direct paths are blocked and that session disablement works.

How we hand over

Deliver configuration documentation, network diagrams and the rule and identity settings that show R2 is in place.
Provide test records for each Part, including attempted direct connections and a session termination exercise.
Confirm with the client's compliance lead and the Regional Entity which evidence formats they expect for an audit.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover changes to vendor access paths, MFA enrollment updates and periodic re-testing of the remote access path.
Readiness work does not replace the independent audit, which only an auditor or the Compliance Enforcement Authority can conclude.

CIP-005-7 R2 Remote access management