What CIP-003-9 vendor remote access requires for low impact assets
If your entity owns only low impact BES Cyber Systems, you now need a documented method for vendor electronic remote access. The requirement has been enforceable since 1 April 2026, and the controls are yours to design, operate and evidence. Your cost and effort depend mainly on how many low impact assets have vendor access paths, how those paths are built today, and how much monitoring you add. Attachment 1 Section 6 of CIP-003-9 asks for three things: methods to determine known or suspected malicious communications, methods to disable vendor remote access when needed, and methods to detect malicious communications. Read the standard itself in the CIP-003-9 standard PDF before scoping, because the wording governs what an auditor will test.
Start by inventorying every route a vendor uses to reach a low impact asset, including vendor-managed tools, support sessions, remote desktop gateways and cloud management consoles. For each route, decide how you will determine malicious communications (for example, by inspecting traffic or checking vendor-supplied indicators), how you will disable the session or account quickly, and how you will detect anomalies. Confirm with your Compliance Enforcement Authority or peers how they expect the detection method to be shown for your asset type, because the standard leaves the method to you. Ask any integrator quoting the work to name each method, the systems involved, and which steps they perform versus which your staff keep.
There is no CIP certificate for this requirement. Compliance is judged by the Compliance Enforcement Authority, which is a Regional Entity or NERC, through audits, Spot Checks, Self-Certifications and other monitoring. An independent auditor does not issue a CIP attestation, and a consultant or implementation partner can prepare systems and records but cannot certify your program. Your evidence therefore has to show, for each vendor route, the method you chose, the date it was set up, and the logs or alerts that prove it operated. Keep that record current from the first day the requirement applied.
What meeting the vendor remote access requirement costs and who gets paid
This table separates the cost components of meeting the CIP-003-9 vendor electronic remote access requirement, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to structure a written scope and to check that each quote covers the same work. No prices or durations are stated because none were supplied; ask for them in writing.
| Cost component | Who is paid or who bears it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Internal staff time for the low impact plan and vendor procedures | Your own staff, including the CIP Senior Manager and operations owners | One-time to write, then recurring to review and maintain | Number of vendors, number of remote access paths, and how many plan sections already exist |
| Tooling for session control, logging and alerting | Licensed vendor or open-source project, plus whoever installs and runs it | Licence or subscription recurring; deployment one-time | Choice between licensed and open-source tools, existing logging stack, and number of vendor sessions |
| Implementation partner work on configuration and evidence | Implementation partner under a written fixed scope, if you engage one | Mostly one-time for configuration; some recurring for evidence upkeep | Number of systems in scope, how much existing configuration is reusable, and how much evidence must be built |
| Ongoing monitoring and alert review | Your security operations staff or a retained provider | Recurring | Alert volume, hours of coverage, and how often vendor sessions occur |
| Independent auditor or Regional Entity review | The auditor or Regional Entity, which is not paid by DeployOpen | Recurring on the audit cycle set by the Regional Entity | Risk-based audit schedule, quality of evidence, and number of findings to resolve |
| Remediation of gaps found in review | Your staff and any contracted help | One-time per gap, but may recur if controls drift | How well vendor access is already documented and how many exceptions exist |
Which vendor access model fits a low impact entity
In this model, the vendor connects to a jump host that the entity owns or controls, and the vendor's session passes through that host before reaching any low impact BES Cyber System. The entity decides which accounts exist on the jump host, which systems the host can reach, and how sessions are recorded. This model suits entities that want one place to observe vendor activity and to disable access quickly.
- Evidence produced: Session logs, recordings of vendor sessions, and system logs from the jump host can support the Attachment 2 examples of session monitoring or recording and system logs.
- Preauthorization: Account approval tickets and scheduled access windows can document preauthorization steps.
- Alerting: Alerts on vendor log on can be configured on the host if the host supports them, so confirm this capability before relying on it.
- What it does not solve: A jump host does not inspect what a vendor does inside a session on a downstream asset unless the entity also captures that activity, and it does not detect malicious content in files the vendor transfers.
Confirm with the vendor and your own environment whether the jump host can record sessions and forward logs to your central logging system.
Here the vendor reaches a remote access gateway that enforces preauthorization before any session starts. The gateway typically brokers connections to specific low impact assets and can require the entity to approve each session or each access window. This model fits environments where the entity wants policy-based control over which vendor reaches which system.
- Evidence produced: Preauthorization records, approval workflows, and gateway logs can document the preauthorization steps listed in Attachment 2.
- Alerting and monitoring: Some gateways generate alerts on vendor log on or support session monitoring, but capabilities differ by product and configuration.
- Logging integration: Forwarding gateway logs to a security information management tool supports the SIEM logging and alert examples.
- What it does not solve: A gateway controls the path in, not the behavior of the vendor's own laptop or credentials, so the entity still needs a method to determine and disable malicious communications from the vendor side.
Confirm whether the gateway's session recording and alerting meet the depth your method requires, and whether it can operate across all of your low impact sites.
In this model, the vendor has no standing path into the environment. The entity enables access only when a specific task needs it, then disables it afterward. This approach reduces the window in which a vendor connection exists, which matters most where a low impact asset is remote, lightly staffed or rarely visited by the vendor.
- Evidence produced: Change tickets, enable and disable timestamps, and the approval record for each enablement can support preauthorization and access disablement evidence.
- Detection: Because the connection is closed most of the time, any unexpected attempt during a closed window is a useful signal, and system logs can show it.
- Operational cost: Each enablement needs a person to act, so the process must be reliable enough to avoid delays during an outage.
- What it does not solve: The model depends on the procedure being followed. An enablement that is left open, or a standing credential that survives the disable step, defeats the control, and this model still needs monitoring while access is active.
Confirm with the vendor how enablement will be requested and verified, and check whether your CIP-003 plan describes the steps clearly enough for an auditor to follow.
How to move from the current state to audit-ready evidence
This sequence takes an entity from an unknown vendor access footprint to a documented, tested low impact vendor remote access program with evidence an auditor can sample. Each phase produces a specific artifact that the next phase depends on, so the work can be reviewed and signed off in order.
Inventory low impact assets with vendor access
Start by listing every asset containing low impact BES Cyber Systems, then mark which ones have any electronic path that a vendor, integrator or contractor can use to reach them. Include vendor-managed equipment, remote monitoring tools, cellular modems, and accounts that vendor staff hold on site systems. Owners of the asset list, usually operations and engineering, confirm the list with the CIP Senior Manager. The output is a signed inventory that names each asset, its vendor access paths, and the party responsible for each path. The step is complete when operations confirms no vendor path is missing.
Document the current vendor access paths
For each path in the inventory, record how the connection is made, which protocol and service it uses, where it terminates, who authorizes it, and how a session starts and ends. Walk through one real session with the vendor and the operator so the document reflects actual practice rather than the intended design. Network and security staff own this record. The output is a path diagram and a table per asset that shows the current state. The step is complete when someone who did not write the document can trace each path from vendor to asset.
Define determine, disable and detect methods
Write the methods your entity will use for the three parts of Section 6 of Attachment 1: determining known or suspected malicious communications, disabling vendor remote access when needed, and detecting malicious communications. Specify the tool or manual check, the trigger, and the person who acts. Keep each method tied to a specific path from the previous step. The CIP Senior Manager or a delegate approves the methods. The output is a written method set, mapped to each vendor path, that a technician could follow without further guidance.
Configure and test the methods
Implement the methods on the systems in scope, then test each one with a controlled event. For example, a test could disable a vendor account and confirm the session fails, or send a known test pattern and confirm an alert is raised (illustrative). Record the test date, the tester, the expected result, and the actual result. Operations and security staff perform the work, and any vendor involvement is agreed in writing beforehand. The output is a test record for each method. Gaps found in testing return to the previous step until the method works as written.
Collect evidence in Attachment 2 style
Gather the records that show the methods operate in practice. CIP-003-9 Attachment 2 lists evidence examples for vendor remote access, including preauthorization steps, alerts on vendor log on, session monitoring or recording, security information management logging alerts, and system logs. Confirm the exact wording of those examples in the standard before you rely on them. Store each artifact with its date, source system, and the asset it covers. The output is an evidence index that maps each path and method to specific artifacts. The step is complete when a sample of sessions can be traced from authorization to log entry.
Review the program with the CIP Senior Manager
Present the inventory, path records, method set, test results and evidence index to the CIP Senior Manager. Confirm that the cyber security plan reflects the methods and that the approval and review cadence is documented. Ask the reviewer to identify any path or method that cannot be explained from the records. The output is a recorded review with decisions, open actions and an approval date. The step is complete when the open actions have owners and the evidence index is locked for the audit period.
How this differs from CIP-005 for medium and high impact systems
The key difference is structural: CIP-005 builds vendor and remote access controls around an Electronic Security Perimeter (ESP) and its Electronic Access Points, and it applies to high impact and medium impact BES Cyber Systems. The low impact obligation for vendor electronic remote access sits in CIP-003-9 Attachment 1, Section 6, and it is written as a plan-level method rather than a perimeter with per-system controls. For a low impact entity, the practical question is not "which Electronic Access Point do we protect?" but "what methods does our cyber security plan use to determine, disable and detect malicious communications from vendors, and can we show they work across every asset that contains low impact BES Cyber Systems?" Confirm with your Regional Entity how it expects a plan-level method to be documented for a site with several low impact assets, since the expectation is set in audit practice as well as in the text.
Because the requirement is lighter in form, the risk of a gap is usually in the evidence rather than the design. Reviewers will look for a method that actually runs: a documented way to determine that a vendor session is occurring, a way to disable it, and a way to detect suspected malicious traffic during the session. Attachment 2 gives evidence examples such as preauthorization steps, alerts on vendor log on, and session logs, but it does not turn them into a CIP-005 style Intermediate System or per-session MFA. Record which vendor accounts exist, who approves each session, and how a session is ended, so the plan section can be traced to records. Do not treat a CIP-005 design as automatically compliant for low impact assets, and do not assume a low impact method will satisfy a future medium impact scope.
Design now for CIP-003-11, which FERC approved in Order No. 918 and which takes effect on 1 July 2029. It adds remote user authentication, protection of authentication information in transit and detection of malicious communications for low impact assets with external routable connectivity. An approach that stores vendor credentials locally, passes them over unprotected channels or relies on shared accounts will need rework before that date. Choosing a remote access method that already supports individual identities, strong authentication and encrypted sessions keeps the 2026 method and the 2029 additions on one design path. Confirm the final wording and any transition details against the standard text before budgeting that work.
What must be in place before an audit or Self-Certification
A low impact program with vendor remote access is judged on whether its paperwork, approvals and technical records match what actually happens during a vendor session. The six items below are the things an auditor or Self-Certification reviewer will ask to see, and each one can be checked internally before a monitoring engagement begins.
Documented low impact plan with the vendor method
The cyber security plan under CIP-003-9 must name the vendor electronic remote access method in use for each asset containing low impact BES Cyber Systems, not just state that vendor access is controlled. Check that the plan section for vendor remote access describes the actual tools and paths, such as a vendor portal, jump host or VPN, and that the description matches the network diagram and current access list. A plan that describes a method nobody uses is a common finding.
CIP Senior Manager approval
The CIP Senior Manager, or a delegate recorded in writing, must approve the low impact plan and its revisions. Confirm that the approval is dated, that it covers the version containing the vendor remote access section, and that any delegation is documented with its scope. Approval records are easy to lose when the plan is updated through a ticketing workflow, so check the signed or time-stamped copy directly.
Vendor access procedures
Write the steps a vendor follows to request, start and end a remote session. Procedures should cover how access is authorized, which accounts the vendor uses, how credentials are issued and revoked, and who from the entity watches the session. Walk through one request from start to finish with the people who run it. If a step exists only in someone's memory, the procedure is not yet a control.
Methods to determine, disable and detect
Section 6 of Attachment 1 expects methods that determine, disable and detect known or suspected malicious communications for vendor access. Identify the specific tool or configuration that performs each of the three functions, such as a session-level block or a security alert rule, and record who owns it. Test each method once and keep the result, because an untested detection rule cannot be shown to work during an audit.
Tested alerting and session records
The evidence examples in Attachment 2 include alerts on vendor log-on, session monitoring or recording, and security information management logs. Confirm that at least one vendor login produces an alert that reaches a person, and that session logs or recordings are retained and can be retrieved for a chosen date. Keep a short test record showing the date, the event generated and the response, since reviewers ask for proof that alerts work, not only that they are configured.
Evidence retention and access records
Decide how long vendor access evidence is kept, where it is stored and who can read it, then apply that rule consistently. Auditors sample from the audit period, so logs that roll over after a few weeks will leave gaps. Check that the retention rule is written in the plan, that the storage location is inside the entity's control, and that a sample of past vendor sessions can be produced from it without rebuilding records by hand.
Who owns the controls, who prepares evidence, and who issues the verdict
The registered entity is the organization registered with NERC that owns the low impact BES Cyber Systems, and it carries the compliance obligation for CIP-003-9 Attachment 1 Section 6. That obligation covers the methods used to determine, disable and detect known or suspected malicious communications for vendor electronic remote access. No outside party takes over that duty by contract, and the entity remains answerable to the Regional Entity for every vendor session.
- Plan ownership: The entity approves the cyber security plan, names the CIP Senior Manager and records any delegations.
- Vendor agreements: The entity sets the terms under which vendors may connect, including who may request access and how sessions are approved.
- Control decisions: The entity chooses the determine, disable and detect methods it will use and documents why they fit its environment.
- Evidence custody: The entity keeps session records, alerts and logs for the retention period its program requires and produces them on request.
- Partner oversight: The entity keeps written scope, acceptance criteria and sign-off for any outside work it commissions.
Before starting, confirm with your Regional Entity which evidence formats it expects for vendor remote access.
An implementation partner such as DeployOpen prepares the systems that carry vendor remote access and assembles the evidence the entity needs. Work is typically fixed-scope and agreed in writing before it starts. The partner works inside the entity's own infrastructure and does not take ownership of the controls or the compliance decision.
- Configuration: The partner can configure logging, session controls and alerting on the self-hosted platforms the entity operates, under a written scope.
- Session controls: Work may include session monitoring or recording set-up, where the chosen tools support it, so that vendor activity is visible.
- Evidence assembly: The partner can organize logs, alerts and configuration records against the CIP-003-9 Attachment 2 evidence examples.
- Documentation: The partner can write runbooks and procedures that describe how the controls operate, for the entity to review and adopt.
- Boundaries: The partner does not issue reports or certifications, and it does not decide whether the entity is compliant.
Ask any partner to state in writing which systems are in scope and which evidence items it will hand over.
The Compliance Enforcement Authority, which is a Regional Entity or NERC, monitors compliance. CIP compliance has no certificate, so the verdict comes from the monitoring process itself, not from a document issued by a vendor or consultant. Monitoring can take the form of a Compliance Audit, a Spot Check, a Self-Certification, a Self-Report or an investigation.
- Audit schedule: Balancing Authority, Reliability Coordinator and Transmission Operator entities 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.
- Spot Checks and Self-Certifications: These may request vendor remote access evidence on short notice or on a defined cycle.
- Findings: The Regional Entity decides whether a requirement was met, and it records any violation and its sanction.
- Independent assessors: Where a standard or contract calls for an outside assessor, that assessor reports to the client, but the Regional Entity still holds the compliance determination.
Ask your Regional Entity which monitoring method it currently uses for low impact entities.
Questions buyers ask about low impact vendor remote access
Can we meet the low impact vendor remote access requirement in-house?
Yes, if your staff can document and operate the controls. The entity owns its CIP-003-9 cyber security plan and the methods it uses to determine, disable and detect malicious communications from vendor electronic remote access. Most in-house teams already run remote access tools, logging and alerting, so the gap is usually the documented plan, the evidence trail and the assigned owners. An outside partner can help configure and document these systems, but the organization remains responsible for the controls and the CIP Senior Manager must approve the plan. Confirm internally whether anyone has time to maintain the evidence each quarter, since the work recurs after the first implementation.
What does meeting the vendor remote access requirement cost?
No fixed figure applies, because cost depends on how many vendors connect, how those connections are made today and how much logging already exists. The main cost components are staff time to inventory vendor access and write the plan, any licenses or hosting for session monitoring or log management, configuration work on the access path, and recurring time to review alerts and collect evidence. One-time costs include the initial design and documentation. Recurring costs include license renewals, log retention and periodic review. When requesting a quote, ask for a written scope listing the systems in scope, the vendors covered, the methods proposed for each of the three objectives, the deliverables and the evidence format. Fixed-scope quotes make it easier to compare options.
How long does a low impact vendor remote access project take?
Duration depends on scope rather than on a fixed number of weeks. The key drivers are the number of low impact assets with vendor access, whether remote paths already use logged, monitored sessions, how many vendor relationships need new procedures, and how quickly internal approvals move. A project that only documents existing controls for one vendor path will take far less time than one that adds session recording across several vendors and sites. Because the requirement has been enforceable since 1 April 2026, entities that have not yet documented their methods should prioritize a current-state review first. Ask any partner to state the milestones, dependencies and the internal reviews it expects you to complete.
What do vendors and internal staff need to provide?
The work needs a current list of vendors with electronic remote access, the accounts and methods they use, and the people who approve each session. Vendors may need to agree to preauthorization steps, provide contact information for session approval, and accept session monitoring or recording where you require it. Internal staff need to own the plan, review alerts, and keep the evidence current. Contract language matters: it should cover notice of access, cooperation during investigations and reporting of suspected malicious activity. Ask vendors early what logging they can provide, because a missing log source often delays the evidence work more than the technical configuration does.
Does cloud or SaaS vendor access change the requirement?
The obligation stays with the entity, but the technical path changes. When a vendor reaches your low impact systems through a cloud or SaaS management console, you still need methods to determine, disable and detect malicious communications on that remote path. The evidence may come from the provider's logs, your own identity platform or a jump host you control, so you need contract terms that give you access to the relevant logs and session records. Check whether the provider can disable a vendor session on your request and how quickly alerts reach your team. Confirm these details in the provider's documentation and contract before relying on them as evidence.
How does the Regional Entity check compliance with this requirement?
There is no CIP certificate. The Compliance Enforcement Authority, which is a Regional Entity or NERC, monitors compliance through tools such as Compliance Audits, Spot Checks, Self-Certifications, Self-Reports and data submittals. Audit timing for most registered entities is set on a risk-based schedule by the Regional Entity, so confirm your own schedule with it. Auditors will ask for the documented methods, the vendor access inventory and evidence that the methods operated during the audit period, such as session records and alert logs. Violations carry civil penalties. The maximum referenced by NERC's Sanction Guidelines under 18 CFR 385.1602(d) is $1,584,648 per violation, per day, as adjusted by FERC Order No. 906. Entities can self-report issues, which typically shapes how a case is handled.
How DeployOpen prepares vendor access controls and evidence
DeployOpen is a Chainscore Labs company that plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, including their cloud accounts, data centers and air-gapped networks. For a low impact entity, that work can cover the vendor access path itself: the intermediary host or jump system that vendors connect through, the logging and alerting that records their sessions, and the procedures that let staff enable or disable a vendor account. The entity keeps ownership of its cyber security plan, its CIP Senior Manager decisions and the methods it chooses for Section 6. DeployOpen prepares the systems and documentation that show those methods work.
Engagements are fixed-scope. Before work starts, the parties agree in writing which low impact assets, vendor access paths and platforms are covered, what will be delivered and on what timeline. Typical handover items include the configuration of the access platform, runbooks for granting, revoking and reviewing vendor access, alert and log configuration, and an evidence package that maps each artifact to the Attachment 2 evidence examples that apply to the entity's chosen methods. Ask for the exact list of artifacts, the format of each one and who is responsible for keeping them current after handover. Ongoing support and periodic reviews are available as retainers, scoped separately.
DeployOpen does not issue audit reports, attestations or certificates, and it does not guarantee a compliance outcome. The Compliance Enforcement Authority, a Regional Entity or NERC, determines whether an entity meets CIP-003-9, and the entity is responsible for demonstrating it. Before engaging anyone, confirm with your Regional Entity how it expects vendor remote access evidence to be presented, and verify that the design you adopt matches your own vendor workflows and risk decisions. Any statement about how a specific open-source product meets a requirement should be checked against that product's documentation and tested in your environment.
