How vendor remote access under NERC CIP is controlled
A vendor needing remote support for a control center or substation system is controlled by CIP-005-7 when the system is a high or medium impact BES Cyber System with External Routable Connectivity, and by CIP-003-9 Attachment 1 Section 6 when the asset holds only low impact BES Cyber Systems, a requirement enforceable since 1 April 2026. Which standard applies depends on the categorization the registered entity made under CIP-002, so the first task is confirming that categorization in writing before any vendor session is opened. The 1,673 unique US entities that FERC's Order No. 919 counted as subject to CIP compliance share this scoping step, whatever their size.
The registered entity owns these controls. Its own staff decide which vendors may connect, which Intermediate System carries the session, how multi-factor authentication is enforced, and how active sessions are found and ended. An implementation partner such as DeployOpen can prepare the systems, configure the access path and assemble the evidence, but it does not decide compliance and does not issue reports. Only the Compliance Enforcement Authority, which is a Regional Entity or NERC, monitors compliance, through audits, spot checks, self-certifications, self-reports and data submittals. There is no CIP certificate. A vendor that offers a CIP certificate or seal is offering a claim the reader should not accept as proof of an entity's compliance.
Before engaging a vendor or a partner, ask the entity's CIP compliance lead three questions: which impact rating applies to the target system, which requirement parts govern that vendor session, and what evidence the entity already keeps for them. Confirm the current text of each standard against the NERC CIP Reliability Standards page rather than relying on older summaries, since several versions have new effective dates. The answers determine how much of the access path, logging and session control the vendor must support, and they set the scope for any quote.
Which vendor access requirement applies at each impact level
This table compares high impact, medium impact with External Routable Connectivity, medium impact without it, and low impact assets against each vendor access obligation. Read each row to see which requirement reaches your systems, then check the column for your impact rating from CIP-002. The main takeaway is that the Intermediate System and session rules are not the same at every level, so confirm your categorization before designing vendor access.
| Obligation | High impact or medium impact with ERC | Low impact assets |
|---|---|---|
| Interactive Remote Access through an Intermediate System (CIP-005-7 R2 Part 2.1) | Required for high impact BES Cyber Systems and their PCA, and for medium impact BES Cyber Systems with External Routable Connectivity | Not required by this rule; the low impact plan governs vendor electronic remote access |
| Encryption ending at the Intermediate System and MFA (Parts 2.2 and 2.3) | Required for all Interactive Remote Access sessions in scope of Part 2.1 | Covered by CIP-003-9 Attachment 1 Section 6 vendor access methods, confirm your chosen controls |
| Determining and disabling active vendor sessions (Parts 2.4 and 2.5) | Required, covering Interactive Remote Access and system-to-system vendor access | Required to determine, disable and detect malicious communications for vendor electronic remote access |
| Vendor connections to EACMS and PACS (CIP-005-7 R3 Parts 3.1 and 3.2) | Required for EACMS and PACS tied to high impact systems and medium impact systems with ERC | Not covered by R3; confirm whether any low impact vendor path reaches shared systems |
| Medium impact without External Routable Connectivity | Part 2.1 Intermediate System rule does not apply to these systems; confirm your ERC determination | Not applicable as a medium impact category, so the low impact plan does not apply |
| Enforcement start for vendor access controls | Current CIP-005-7 requirements apply now | CIP-003-9 vendor remote access requirement enforceable from 1 April 2026 (NERC) |
What CIP-005-7 requires for vendor Interactive Remote Access
CIP-005-7 Requirement R2 sets the baseline for any Interactive Remote Access session, including sessions opened by vendors and contractors. The three parts below shape the architecture: a mandatory Intermediate System, encryption that ends there, and multi-factor authentication on every session.
Part 2.1: Intermediate System required
Part 2.1 requires that all Interactive Remote Access to high impact BES Cyber Systems, medium impact BES Cyber Systems with External Routable Connectivity, and their Protected Cyber Assets pass through an Intermediate System. The vendor's laptop is the initiating Cyber Asset, and it must never connect directly to the applicable Cyber Asset. Check that your architecture has no alternate path, such as a vendor VPN that lands on the control network, that skips the Intermediate System.
Part 2.2: Encryption ends at the Intermediate System
Part 2.2 requires encryption for every Interactive Remote Access session, and the encrypted session must terminate at the Intermediate System. The vendor laptop encrypts the session to the Intermediate System, which then handles the connection to the target. Ask your Intermediate System provider where the encrypted tunnel ends, which protocols and cipher suites it uses, and whether session recordings or logs are stored in plaintext.
Part 2.3: MFA on every session
Part 2.3 requires multi-factor authentication for all Interactive Remote Access sessions, including vendor sessions and emergency access. A vendor's password alone does not meet the requirement. Confirm which factors the Intermediate System enforces, whether the vendor's identity provider or your own enforces them, and how the evidence of MFA is retained for audit review.
Jump hosts and the Intermediate System roles
A jump host is a system that a user logs into before reaching a further system. The Intermediate System is the controlled point that CIP-005-7 requires, and it must be a separate system from the target. Where a vendor uses a jump host inside your network, document whether it counts as the Intermediate System or sits behind it. Your product documentation must state how the Intermediate System meets Parts 2.1 to 2.3, and you must confirm that claim against your own configuration.
How sessions, EACMS and PACS, and low impact access are handled
CIP-005-7 Requirement R2, Parts 2.4 and 2.5, asks the responsible entity to keep methods that show which vendor remote access sessions are active and methods that can end them. The scope covers Interactive Remote Access and system-to-system remote access, so a scheduled data transfer or an API connection from a vendor platform counts as much as a human login. The entity chooses the methods, and the vendor's tooling has to support them.
- Session visibility: Maintain a current view of every active vendor session to in-scope BES Cyber Systems, including non-interactive connections that have no user at a keyboard.
- System-to-system paths: Identify service accounts, API tokens and scheduled jobs that let a vendor system reach a BES Cyber System, and record them in the access inventory.
- Disconnection method: Define how an operator ends a session quickly, such as closing the Intermediate System session or revoking a credential, and test that the method works.
- Records: Keep logs that show when each session started, who initiated it, and when it ended.
Ask the vendor which session-listing and termination functions its remote support tool provides and whether they can be exported for audit. Confirm these capabilities in your own environment before relying on them.
CIP-005-7 Requirement R3 applies a second set of controls to vendor connections that reach the Electronic Access Control or Monitoring Systems and Physical Access Control Systems associated with high impact BES Cyber Systems and medium impact BES Cyber Systems with External Routable Connectivity. Part 3.1 requires one or more methods to determine authenticated vendor-initiated remote connections to those systems. Part 3.2 requires one or more methods to terminate them and to control the ability to reconnect.
- Determination method: Use logs or monitoring that show authenticated vendor connections to EACMS and PACS, separate from the BES Cyber System sessions covered in Part 2.4.
- Termination method: Provide a way to end a vendor connection to an access control server, monitoring platform or badge system without disrupting unrelated administrative access.
- Reconnection control: Limit who can re-establish a terminated connection, and record each reconnection attempt.
- Scope mapping: Identify which EACMS and PACS belong to each high or medium impact system, because the requirement follows those associations.
Confirm with your compliance team which access control and badge systems fall in scope, since mislabeled PACS are a common gap in vendor reviews.
Low impact assets are not covered by the high and medium impact controls in CIP-005-7 Requirement R2 and R3. Instead, CIP-003-9 Attachment 1 Section 6 requires methods to determine, disable and detect malicious communications for vendor electronic remote access. This section has been enforceable since 1 April 2026, so entities with only low impact BES Cyber Systems must now address it in their cyber security plan.
- Determine: Identify when a vendor has an electronic connection to a low impact asset and record that access.
- Disable: Provide a documented method to end the vendor connection when needed.
- Detect: Monitor vendor connections for malicious communications, using alerts or traffic inspection that fits the asset's size and risk.
- Evidence: Attachment 2 of CIP-003-9 lists example evidence such as preauthorization steps, alerts on vendor log on, session monitoring or recording, security information management logging alerts and system logs.
Review your cyber security plan against Section 6 and Attachment 2 with your compliance lead, and ask your vendor whether it can produce the preauthorization record and session logs that Attachment 2 describes.
How to bring vendor access into compliance before an audit
This sequence moves vendor access from an unmapped set of connections to a documented, tested set of controls that an auditor can trace from scope to evidence. Each step produces a record the compliance lead can hand over without reconstructing it from memory.
Confirm impact categorization under CIP-002
Start by confirming which BES Cyber Systems are high, medium or low impact under the bright-line criteria in CIP-002-5.1a, and whether medium impact systems have External Routable Connectivity. The category decides which vendor access requirements apply: CIP-005-7 covers high and medium impact systems, while CIP-003-9 Attachment 1 Section 6 covers vendor electronic remote access at low impact assets. The output is a categorization record signed off by the CIP Senior Manager, listing each asset, its rating and the reasoning behind it.
Inventory every vendor access path
Work with operations, network and vendor management staff to list every route a vendor can use to reach in-scope systems. Include Interactive Remote Access, system-to-system links, vendor-managed monitoring tools, and any EACMS or PACS that can be reached remotely, since CIP-005-7 R3 applies to those as well. The output is an access path inventory that names each vendor, the target system, the protocol, the initiating device and the business owner, and that is reviewed whenever a vendor relationship changes.
Route Interactive Remote Access through an Intermediate System
Redirect every Interactive Remote Access session so the vendor's initiating Cyber Asset does not connect directly to an applicable Cyber Asset, as CIP-005-7 R2 Part 2.1 requires. The Intermediate System is placed inside the scope the standard defines, and the network team confirms through testing that no direct path remains. The output is a network diagram showing the Intermediate System and a test record demonstrating that a direct connection is refused.
Enforce encryption and multi-factor authentication
Configure encryption that terminates at the Intermediate System for all Interactive Remote Access sessions, and require multi-factor authentication for each session, as CIP-005-7 Parts 2.2 and 2.3 describe. Confirm that vendor accounts cannot bypass these controls through shared credentials or alternate paths. The output is a configuration record for the Intermediate System and the authentication service, plus a sample login showing the second factor in use.
Implement session determination and disabling methods
Define how the team identifies active vendor sessions, including both Interactive Remote Access and system-to-system connections, and how it disables them. CIP-005-7 Parts 2.4 and 2.5 require one or more methods for each, and Part 3.2 requires termination and reconnection control for vendor connections to EACMS and PACS. Test each method against a live session so the procedure is proven, not assumed. The output is a written procedure and a test record showing a session was detected and then terminated.
Configure logging, alerts and session records
Set the Intermediate System and related platforms to log vendor log-on events and session activity, and send alerts to the team that monitors them. For low impact assets, the CIP-003-9 Attachment 2 evidence examples include preauthorization steps, alerts on vendor log-on, session monitoring or recording, and system logs, which can guide the design. Confirm that logs are retained and can be retrieved for a given date range. The output is a logging configuration record and a sample alert with its matching log entries.
Collect and index evidence for the audit period
Gather the categorization record, access path inventory, network diagrams, configuration records, test results, procedures and log samples into one index that maps each artifact to the requirement part it supports. Ask the Regional Entity or your auditor which evidence format and retention period they expect before the audit notification arrives. The output is an evidence binder with a cross-reference table that a reviewer can follow without the compliance lead present.
What evidence shows vendor remote access controls work
Auditors test whether vendor remote access controls operate as designed, not only whether a procedure exists on paper. For a registered entity, that means showing records from real vendor sessions over the audit period: who was authorized in advance, when each vendor logged on, what the vendor did while connected, and when access was ended. The Compliance Enforcement Authority typically asks for preauthorization records (approvals, scheduled work orders or change tickets), alert records showing that the entity was notified of each vendor log on, session monitoring or recording output, security information management alerts, and the underlying system logs from the Intermediate System, the access point and the monitored assets. Each record should be traceable to the others by timestamp and account identity.
The entity owns this evidence, and it must retain it for the period its Regional Entity specifies. Confirm the retention period and the format the Regional Entity expects before the first audit cycle, because the answer determines how long logs must sit in storage and whether session recordings must be kept in tamper-evident form. An implementation partner can configure log forwarding, alert routing, session recording and retention settings, and can document how each source feeds the evidence set. The partner does not decide whether the evidence is sufficient. The Regional Entity's auditor makes that judgment, so the entity should test its own evidence pack against the requirement parts before an audit notice arrives.
A practical check is to pick one recent vendor session and try to rebuild its full story from the records alone: the approval, the Intermediate System log entry, the MFA event, the alert, the recording and the disconnect. If any link is missing, the gap will likely surface in an audit. Illustratively, a session that was approved but has no logged disconnect would prompt questions about whether the entity could determine and disable the active session as required. Close those gaps in the process and tooling first, then keep the sample records as the standing evidence set.
What usually breaks vendor remote access compliance
Vendor remote access under CIP-005 fails less often on the technology than on the paperwork around it. The five failures below share one root cause: the access path an auditor sees in the inventory is not the path vendors actually use, so each card pairs a failure with the check that closes the gap.
Shared accounts and personal remote tools
When vendor engineers share a login or connect through a consumer remote desktop application, the session never passes through the Intermediate System that Part 2.1 requires. Interactive Remote Access must route through that system, so the initiating device cannot reach the applicable Cyber Asset directly. Check every vendor workstation for remote tools, and confirm each person authenticates with an individual identity. Ask the vendor in writing to commit to using only the approved path, and document the restriction in the contract.
System-to-system links missing from inventory
Automated vendor connections, such as monitoring feeds, patch servers and file transfers, often run without anyone recording them as remote access. Part 2.4 covers system-to-system remote access as well as interactive sessions, so these links must be determinable. Walk the network flows for each vendor, compare them against the documented list, and assign an owner to every link. An undocumented feed is the failure an assessor is most likely to find.
Session disabling never tested
A procedure that says the entity can disable an active vendor session has little value until someone has done it. Part 2.5 requires a method to disable active vendor remote access, and the evidence should show that the method worked on a live session. Schedule a test that starts a vendor session, disables it, and records the timestamp and the resulting log entries. Repeat the test after firewall, VPN or jump host changes, because those changes often break the disable path quietly.
EACMS and PACS reached without logged connections
Vendors who troubleshoot access control servers or badge systems can authenticate into EACMS and PACS without anyone recording the connection. Part 3.1 requires methods to determine authenticated vendor-initiated remote connections to these systems, and Part 3.2 requires a way to terminate them and control reconnection. Confirm that vendor logins to these systems generate alerts or logs, that the logs reach the monitoring platform, and that someone reviews them. Ask the vendor how remote support is performed before the first session, not after an incident.
Low impact sites assume no vendor requirement
Teams that operate only low impact assets often conclude that vendor remote access rules do not reach them. Since 1 April 2026, CIP-003-9 Attachment 1 Section 6 requires methods to determine, disable and detect malicious communications for vendor electronic remote access at low impact sites. Inventory every vendor path into those sites, including maintenance modems and remote engineering tools, and document how each one is determined and disabled. Confirm the cyber security plan names these methods, because the evidence is reviewed as part of that plan.
Who owns vendor access controls and who prepares the evidence
The registered entity remains accountable for CIP compliance. It decides the impact categorization of its BES Cyber Systems under CIP-002, determines which vendor remote access paths exist, and sets the policy that governs them. It also signs the vendor contracts and makes the final call on whether its controls are sufficient for its environment. A partner can recommend a design, but the entity must accept the residual risk and the operating burden.
- Impact categorization: The entity determines which systems are high, medium or low impact, which in turn sets which Part requirements apply to each vendor path.
- Access policy and roles: The entity defines who may request vendor access, who approves it, and who can terminate a session.
- Vendor contracts: The entity specifies remote access, logging, notification and staff screening terms that vendors must accept.
- Operating records: The entity runs the daily review of session logs and alerts, and keeps the records that show it happened.
- Final sufficiency decision: The entity, not the partner, decides whether a control design meets its obligations.
Before engaging anyone, confirm with your Compliance Program lead which assets carry External Routable Connectivity and which vendor paths reach them.
An implementation partner such as DeployOpen works inside the client's own infrastructure to plan, build, harden and document the technical controls. For vendor remote access, that typically means designing and configuring an Intermediate System, enforcing encryption that terminates there, setting up multi-factor authentication, and configuring session determination, termination and logging. The partner then assembles the evidence the entity needs. It does not own the controls, and it does not decide whether they are compliant.
- Architecture and configuration: Planning the Intermediate System placement, the path from vendor endpoints, and the controls that keep the initiating Cyber Asset from reaching protected assets directly.
- Authentication and encryption: Implementing MFA and encryption for Interactive Remote Access, with configuration kept under version control.
- Session and reconnect controls: Building methods to determine active sessions, disable them, and control reconnection, including for EACMS and PACS paths.
- Logging and alerting: Configuring session recording, vendor log-on alerts and log retention so evidence can be produced on request.
- Documentation and evidence packs: Writing runbooks and mapping configurations and logs to the requirement parts they support.
Ask any partner to name the artifacts it will hand over and who keeps them after the engagement ends.
The Compliance Enforcement Authority, which is a Regional Entity or NERC, monitors compliance. It does so through Compliance Audits, Spot Checks, Self-Certifications, Self-Reports, self-logging, periodic data submittals and investigations. Under Section 403.10.1 of the NERC Rules of Procedure, Balancing Authorities, Reliability Coordinators and Transmission Operators receive a Compliance Audit at least once every three years, while other registered entities are audited on a risk-based schedule set by the Regional Entity. There is no CIP certificate, and no partner or consultant can issue one.
- Findings and enforcement: The Compliance Enforcement Authority records findings, and any violation proceeds through its own process.
- Evidence review: Auditors test whether the entity's evidence shows each requirement part was met during the audit period.
- Independent view: An independent assessor, when used, gives its own opinion, which is separate from the implementation work.
- No issued attestation: DeployOpen does not issue audit reports, attestations or certifications.
- Retention and readiness: The entity must be able to produce logs and records within the scope of the audit.
Confirm with the Regional Entity which evidence formats and retention periods apply to your registration.
Vendors and contractors who reach a CIP environment carry obligations that flow through the entity's contracts and its CIP-013 supply chain risk management plan. CIP-013 requires the entity to address vendor remote access, notification and related procurement topics in its plan. Those obligations become binding on vendor staff through contract terms, approved procedures and access rules, not through the Compliance Enforcement Authority's direct oversight of the vendor.
- Contract acceptance: Vendors agree to remote access methods, logging, and incident notification terms before work starts.
- Individual accountability: Each person using a vendor session uses individually assigned credentials and MFA where required.
- Session conduct: Vendor staff follow the approved procedure for requesting, using and ending sessions.
- Staff screening: Personnel risk assessments and training are completed before authorized access is granted.
- Revocation: Access is removed promptly when staff leave the project or the vendor relationship ends.
Before signing, ask the entity which vendor remote access terms are in its CIP-013 plan and how they are enforced.
Questions buyers ask about vendor remote access under NERC CIP
Can a vendor connect directly to a high impact BES Cyber System?
No. Under CIP-005-7 Part 2.1, all Interactive Remote Access to high impact BES Cyber Systems and their Protected Cyber Assets must pass through an Intermediate System, so the vendor's initiating device does not connect directly to the applicable Cyber Asset. The same rule applies to medium impact BES Cyber Systems with External Routable Connectivity. Part 2.2 requires encryption that terminates at the Intermediate System, and Part 2.3 requires multi-factor authentication for every Interactive Remote Access session. Your engineers should confirm how each vendor path reaches the Intermediate System before any session is allowed, because a single unmanaged路径 can undo the design. The control is the entity's responsibility, and an assessor will test it against the entity's own network diagrams and session records.
Do low impact sites have to control vendor remote access too?
Yes, for vendor electronic remote access at low impact assets, CIP-003-9 Attachment 1 Section 6 has been enforceable since 1 April 2026. It requires methods to determine, disable and detect malicious communications for that access. The obligation is narrower than the high and medium impact rules, but it is not optional. Attachment 2 of CIP-003-9 gives examples of evidence, such as preauthorization steps, alerts on vendor log on, session monitoring or recording, and system logs. Entities with only low impact assets should map each vendor access path to these items and keep the records that show them.
What does the work need from our own team?
Your team owns the controls, so it must supply decisions and access that no outside party can give. Typical inputs include the current BES Cyber System categorization from CIP-002, network diagrams that show every vendor path, a list of vendors and the accounts they use, and approval for changes to firewalls, Intermediate System configuration and identity sources. Your compliance lead should confirm which evidence the Regional Entity expects and how long it must be retained. Operations staff must also agree on how sessions are approved, watched and ended. Ask any implementation partner to name these inputs in writing before work begins.
Can we set up vendor remote access controls in-house?
Often yes, if your team has the skills and capacity to build and operate the controls. The work covers network design around the Electronic Security Perimeter, an Intermediate System, encryption and multi-factor authentication, session determination and disabling methods, and logging that supports an audit. Common gaps are unclear vendor inventories, shared accounts and session tools that cannot show who connected and when. An outside partner can prepare systems and evidence in your environment, but it cannot issue an audit result, and the entity remains accountable for the outcome. Compare the in-house option against the staff time and testing it would require.
What drives the effort and cost of vendor remote access work?
Effort rises with the number of vendors, the number of distinct access paths, and the number of systems and sites in scope. Each path must be inventoried, routed through an Intermediate System where required, authenticated with multi-factor methods, monitored and disabled on demand. Systems that reach EACMS and PACS add Part 3.1 and 3.2 steps for determining, terminating and controlling reconnection of vendor-initiated connections. Costs are usually one-time for design, build and testing, plus recurring costs for operating the tools, reviewing access and keeping evidence current. Ask any quote to separate these items and to state the systems, sites and vendors it covers.
How long does vendor remote access work take?
No duration is supplied for this work, so no timeline can be stated here. Length depends on how many vendors and access paths exist, how many systems and sites are in scope, whether an Intermediate System is already in place, and how much testing and evidence collection is needed. DeployOpen's engagements are fixed-scope, and the scope, deliverables and timeline are agreed in writing before work starts. Ask for a written schedule that ties each milestone to a named system or vendor path. No outcome of any audit can be promised.
How DeployOpen scopes and prepares vendor access controls
DeployOpen works on vendor remote access as an implementation partner: it scopes the systems in play, builds the access path and documents the evidence, while the registered entity owns its controls. Engagements are fixed-scope, with scope and deliverables agreed in writing before work starts.
How we scope
- Confirm which BES Cyber Systems, EACMS, PACS and PCA each vendor session can reach, by impact level
- Map every interactive and system-to-system vendor path, including low impact assets where CIP-003-9 applies
- Record the written scope, deliverables and timeline before any configuration work begins
How we build
- Prepare Intermediate System placement so vendor sessions never reach applicable Cyber Assets directly
- Configure encryption terminating at the Intermediate System and multi-factor authentication for each session
- Set up methods to determine, disable and reconnect-control active vendor sessions and EACMS or PACS connections
How we hand over
- Deliver configuration documentation and session logs mapped to each CIP-005-7 part the entity relies on
- Provide test records showing sessions were detected, disabled and blocked from reconnecting
- Hand over runbooks so the entity's own staff can operate, review and revoke vendor access
How we support
- Offer ongoing support, upgrades and continuous testing of vendor access paths as a retainer
- Re-check access controls when the entity's CIP scope or vendor roster changes
- Confirm with the entity's compliance team and independent auditor which evidence they will accept
