CIP-007-6 R1 Ports and services: requirements and evidence

What CIP-007-6 R1 requires for ports and services

Part 1.1 of CIP-007-6 R1 asks you to enable only the logical network accessible ports that you have determined are needed, where technically feasible, including port ranges or services needed to handle dynamic ports. Part 1.2 asks you to protect against the use of unnecessary physical input and output ports used for network connectivity, console commands or Removable Media, but only for the systems the standard scopes in: high impact BES Cyber Systems and medium impact BES Cyber Systems at Control Centers, along with their Protected Cyber Assets and nonprogrammable communication components, all inside both a Physical Security Perimeter and an Electronic Security Perimeter. Read the *Applicable Systems* column of the table before you scope the work, because the physical port requirement does not reach every medium impact system.

The risk is simple to state. Every listening service is a door that an attacker, or a misconfigured neighbor, can try to open, and a console or USB port left active gives someone with physical access a way around network controls. Compliance leads usually find that the hard part is not the setting itself but the record behind it. Port inventories drift after firmware updates and vendor changes, so a list built during the last audit no longer matches the device. Ports are often open for reasons nobody wrote down, such as a vendor troubleshooting tool or a legacy protocol that a process still depends on. Some embedded or older devices cannot disable a service or a port in the way the standard describes.

For those devices, the reader should confirm early whether the asset can meet the requirement as written, and document the reasons and the compensating controls if it cannot. The need for each enabled port must be written down, and that documentation should match what the device reports today. Start by pulling the current listening ports and removable media settings from each in-scope device, then compare them against the justification list. Gaps found now are far cheaper to fix than gaps an auditor finds during a Compliance Audit or Spot Check.

Which systems CIP-007-6 R1 applies to

CIP-007-6 R1 does not apply to every Cyber Asset you own. Its Applicable Systems column decides which parts of the requirement reach which assets, and that decision flows from the CIP-002 categorization. Work through the cards in order, then confirm each conclusion against the current standard table.

Start with the CIP-002 categorization

The impact rating of each BES Cyber System, set under CIP-002, determines whether CIP-007-6 R1 applies at all. High impact and medium impact systems are in scope, while low impact systems fall under the CIP-003 cyber security plan instead. Keep the categorization record current, because a change in impact rating changes which Applicable Systems rows you must evaluate. Ask your Compliance team to show you the signed categorization that your R1 evidence is built on.

High impact and Control Center medium impact

Part 1.1 covers high impact BES Cyber Systems and their associated systems, as does Part 1.2 for the same tier. Part 1.2 also reaches medium impact BES Cyber Systems at Control Centers. Both parts apply to the BES Cyber Systems themselves, so a Control Center rated medium impact can bring Part 1.2 into scope even when its field equipment is not in the same category. Confirm the Control Center classification with the CIP-002 record before you size the work.

Other medium impact systems

Medium impact BES Cyber Systems that sit outside Control Centers fall under narrower rows of the Applicable Systems table. Part 1.1 can reach them, but Part 1.2 does not, which means the physical port protection work is limited to the higher-risk tier. Read the table row by row for your system type, including whether External Routable Connectivity is present, because that condition changes the applicable rows. Document your reading so an auditor can follow it.

Protected Cyber Assets and associated systems

Protected Cyber Assets, Electronic Access Control or Monitoring Systems and Physical Access Control Systems are often overlooked in port inventories. Many CIP-007-6 rows name them directly, so a relay, historian or access control panel connected to an in-scope system can carry the same obligations. Build the asset list from the electronic security perimeter and physical security perimeter diagrams, not from the network team's inventory alone.

Part 1.2 physical port boundary

Part 1.2 only reaches assets inside both a Physical Security Perimeter and an Electronic Security Perimeter. An asset outside either boundary is outside that part, even when it is in the same substation or data center as an in-scope system. Confirm each asset's location against your current perimeter drawings, and record any change in location as a scoping event. Physical port controls such as locked cabinets, disabled USB ports or sealed console access are then tested against that boundary.

Confirm against the current table

Applicable Systems tables change between versions, and the CIP-007 requirement set has been revised more than once. Confirm the rows you rely on against the current CIP-007-6 standard text published by NERC, and check whether any later revision on the CIP standards page changes your scope before the audit period. Ask your Regional Entity or auditor to confirm your reading if the boundary between tiers is unclear.

How an auditor tests CIP-007-6 R1 ports and services

This table compares what an assessor samples, compares and inspects for each part of CIP-007-6 R1, the evidence usually requested and the findings that appear most often. Read each row as a step in the audit walkthrough, and treat the common findings column as the list of gaps to close before the audit starts.

Test area	Part 1.1: logical network ports	Part 1.2: unnecessary physical ports
Sampling	Assessor selects applicable devices in scope, usually high impact BES Cyber Systems and medium impact systems with External Routable Connectivity, plus their PCA and associated EACMS and PACS where the table applies.	Assessor selects in-scope Control Center assets and high impact devices within a PSP and ESP, then checks each sampled device's physical ports, consoles and Removable Media access.
Comparison method	Listening ports from configuration files or command output such as netstat or a port scan are compared against the entity's list of needed ports and services.	Physical inventory of USB, serial, console, network and media ports is compared with the documented need and the control applied to each port.
Documented need	Each enabled port or port range has a written business or technical reason, tied to a specific service on the device. Ports with no reason are treated as unexplained.	Each active physical port has a documented decision to keep it enabled, with the reason, or a record that it is disabled, locked or covered by a Removable Media policy.
Evidence requested	Port listings from device configuration files, scan output, the port and service justification list, and change records for any ports opened or closed during the audit period.	Photos or configuration exports showing disabled or locked ports, console access records, Removable Media procedures and the list of physical port decisions.
Dynamic ports	Where a service needs a range of dynamic ports, the assessor checks that the range is named, limited to what the service needs and justified in writing.	Not typically applicable, but any port used for removable media or console commands must be covered by a physical control or a documented exception.
Common finding: undocumented ports	Ports appear in scan or configuration output with no justification record, often services left enabled from a vendor default.	Physical ports are found active on a sampled device with no entry in the physical port decision list.
Common finding: ranges without justification	A broad port range is enabled for convenience, for example during a software installation, and never narrowed or justified.	Removable Media ports remain usable on workstations or consoles that the Removable Media procedure does not cover.
Common finding: no documented control	The justification list exists but has not been reviewed or matched to the current device configuration, so enabled ports drift from the record.	Consoles or serial ports are left active without a locking method, access restriction or documented decision to accept the risk.

Steps to implement CIP-007-6 R1 ports and services

This sequence turns CIP-007-6 R1 from an open-ended hardening goal into a documented set of enabled ports, each tied to a stated need, with physical ports protected and a recurring review that keeps the record current. Each step produces an artifact an auditor can sample.

Confirm applicable systems from the CIP-002 categorization
Start from the CIP-002 categorization to list which BES Cyber Systems, Protected Cyber Assets and associated systems fall within the scope of CIP-007-6 R1. The applicability tables differ by impact rating, so high impact systems, medium impact systems with External Routable Connectivity and any associated EACMS, PACS or PCA must each be identified explicitly. The output is an applicable systems list that names every device and cross-references its impact category. The step is complete when the compliance owner and the operations lead have signed off on that list.
Build a baseline inventory of listening ports
For each in-scope device, record the logical network accessible ports that are open and listening, using device configuration files, service listings or command output such as netstat, with port scans as a cross-check where the owner approves them. Include port ranges and dynamic services, since these must be captured as well. The output is a port register with one row per device and port, along with the collection method and date. The step is done when every in-scope device has a captured listing that operations staff have reviewed for accuracy.
Document the need for each enabled port
For every port in the register, the system owner records the business or technical reason it must stay open, the service that uses it, and the authorized source or client where relevant. Ports with dynamic allocation need a documented rule describing the range and the services that require it. The output is a justification record linked to each register entry. The step is complete when each enabled port has a stated need and an approver has signed off, because an unexplained port is the most common gap an assessor finds.
Disable ports without a documented need
Where technically feasible, disable or stop services bound to ports that have no documented need, then test that the dependent functions still operate. Where a port cannot be disabled on a particular device, record the technical reason and the compensating status in the register rather than leaving the port unexplained. The output is a change record for each disabled service and a list of exceptions with their reasons. The step is complete when re-running the listing confirms that only justified ports remain.
Identify physical input and output ports
Inventory the physical input and output ports on in-scope high impact systems and on medium impact Control Center systems, including their PCA and nonprogrammable communication components within the Physical Security Perimeter and Electronic Security Perimeter. Cover network interfaces, console ports, USB and other Removable Media connections. The output is a physical port inventory showing each port, its device, its location and whether it is in use. The step is complete when the inventory has been checked against a physical walkdown of the relevant locations.
Protect unused physical ports
For each physical port identified as unnecessary for network connectivity, console commands or Removable Media, apply a protection such as disabling it in firmware or operating system settings, physically blocking it or restricting its use through a documented procedure. Record the method used and who verified it. The output is a protection record added to the physical port inventory, with any ports that remain in use justified in writing. The step is complete when the verification entry confirms the protection on each port.
Set and run a recurring port review
Establish a review cadence and a trigger for ad hoc review, such as configuration changes, new software installations or vendor work on the device, and assign an owner for each. At each review, re-capture the listening ports, compare them with the register and update the justifications and the physical port inventory. The output is a dated review log that shows what changed and why. The step is complete when the first review has been run against the prior register and the log is stored with the compliance evidence.
Align the port register with the CIP-010 baseline
Logical network accessible ports also appear in the CIP-010 baseline configuration, so the port register should feed that baseline rather than duplicate it. Confirm that any change to an enabled port passes through the configuration change process and updates both records. The output is a cross-referenced baseline entry for each device that matches the port register. The step is complete when a sample change has been traced through both records without a mismatch.

Evidence that passes a CIP-007-6 R1 audit

An auditor testing ports and services wants to see what is listening on each in-scope device, why it is allowed to listen, and how that list stays accurate over time. The cards below cover the artifacts that answer those questions and the routines that keep them current between audits.

Listening port inventory from configuration

Export the enabled services and listening ports from each in-scope device's configuration files, such as firewall rule sets, service definitions and device startup settings. Record the device identifier, the firmware or software version and the export date on every file. Auditors compare this list with what the device actually runs, so a configuration export that does not match live behavior is a finding in its own right. Check that ports the vendor enables by default are captured too.

Live port scan or command output

Keep dated output from commands such as netstat or a port scan run against the device, showing the ports that are actually open. Label each capture with the device identifier, the scanning host, the date and the scan scope. Run captures from inside the Electronic Security Perimeter where possible, because a scan from outside may miss services that only answer on internal interfaces. Compare these captures against the configuration inventory and record any difference.

Documented need for each enabled port

For every enabled logical port or port range, keep a short written justification that names the service, the business or operational function it supports, and the systems that connect to it. Port ranges used for dynamic ports need their own note explaining which services require them. A port with no recorded reason is hard to defend, so treat an undocumented port as a candidate for disabling until someone signs off on it.

Disabled ports and physical port protections

Show that unneeded ports were turned off, using before and after configuration exports or change tickets. For Part 1.2, document how unnecessary physical input and output ports are protected, such as disabled USB ports, locked enclosures, port blockers or removal of console access, for each applicable device. Note the physical location and the protective method for each asset, since the Part applies to devices inside both a Physical Security Perimeter and an Electronic Security Perimeter.

Change-linked port list maintenance

Keep a process record that shows how the port list stays current. Tie every addition or removal of a port to a change ticket, then update the inventory and the justification in the same change. Schedule a periodic review of all in-scope devices, and file the results with dated exports. Ask your team to confirm the review interval against their own program, because the schedule is set by the entity's documented process rather than by a fixed period in the standard.

Tie-back to the CIP-010-4 baseline

Link the port inventory to the baseline configuration required by CIP-010-4 R1, which lists logical network accessible ports as a baseline item. A port that appears in the baseline should match the port inventory, and any change to the baseline should trigger a port review. Auditors often test both standards together, so a mismatch between the two records can create questions about both requirements.

What meeting CIP-007-6 R1 costs in money and effort

This table lists the main cost components of meeting CIP-007-6 R1 and shows who is paid for each, whether it is one-time or recurring, and what pushes it up. Use it to structure a quote request, since no dollar figures or durations are supplied for this requirement and each organization's device count and equipment mix will set the actual totals.

Cost component	One-time or recurring	Drivers that raise it	How to keep it down
Tooling and licenses	Recurring (subscription or renewal) or one-time (perpetual purchase)	Number of monitored endpoints, number of sites, premium support tiers, and add-on modules needed for port evidence	Use open-source scanners and configuration assessment tools where their license and edition limits fit the environment, and confirm those limits in writing before adoption
Engineering time to inventory and justify ports	One-time for the initial inventory, recurring for updates after changes	Device count, number of vendor-managed devices whose port lists the entity cannot easily read, and undocumented services inherited from prior projects	Start from a baseline configuration and record a documented need for each enabled port in one register, so later reviews only cover changes
Physical port hardening labor	One-time for disabling or blocking ports, recurring for new hardware	Legacy equipment that cannot disable USB, serial or console ports, the number of Physical Security Perimeter locations, and the need for physical locks or port covers	Prioritize equipment in scope under the high impact and Control Center criteria, and record technical limits in a plan for equipment that cannot be changed
Vendor and integrator coordination	Recurring while vendor-managed devices remain in service	Number of vendor-managed devices, contract terms that limit configuration access, and maintenance windows	Write port configuration responsibilities and evidence delivery into vendor contracts and procurement terms before purchase
Evidence upkeep	Recurring	Frequency of configuration changes, number of systems in scope, and manual collection of listening port output	Automate collection of listening port data and store dated outputs with the port justification register
External review or testing	Recurring, typically scheduled per engagement	Scope of the port scan or configuration review, number of sites tested, and whether results must be independently verified	Agree scope, sample size and deliverables in a written statement of work before testing starts
Auditor sampling effort	Recurring per audit cycle	Audit frequency set by the Regional Entity, number of BES Cyber Systems sampled, and gaps in dated evidence	Keep evidence organized by Cyber Asset so an auditor can sample without extended requests

Open-source tools that produce CIP-007-6 R1 port evidence

CIP-007-6 R1 asks for two kinds of proof: which logical ports are enabled and why each one is needed. The open-source tools below can show the first part from the systems themselves, but none of them records the documented need, so that justification has to come from your own change records and system owners.

Wazuh configuration assessment checks

Wazuh Security Configuration Assessment (GPL-2.0-only) scans monitored endpoints against YAML policies, mostly based on CIS benchmarks, and can be extended with your own custom policies. It checks files, directories, registry keys and running processes, so it can confirm whether a service that should be disabled is configured or running. Confirm for each device type whether the policy set lists listening ports directly, or whether you need a custom check that reads the port state. Treat the output as configuration evidence, not as proof of need.

Fleet yes or no port policies

Fleet (MIT) expresses policies as yes or no osquery questions asked of devices, such as whether a listening socket exists on a port that should be closed. Its policies page shows which devices in each fleet pass or fail, which gives you a running count of exceptions for R1 review. Fleet is useful for workstation and server fleets with agents. Confirm that osquery covers the listening-socket tables on your operating systems, and confirm how it handles network devices and embedded equipment in your ESP.

Greenbone network port scanning

Greenbone Community Edition (OpenVAS, AGPL-3.0-or-later) runs vulnerability tests from the daily updated Greenbone Community Feed against target systems, which includes checking which network services respond. Scan results can document the ports that answer from a given address range, a useful cross-check against a configuration file. Active scanning of BES Cyber Systems needs careful planning and vendor approval. Confirm with the device vendor and your operations team that scan traffic is safe for each device type, and review the AGPL terms with counsel if you modify the code.

Trivy software component checks

Trivy (Apache-2.0) detects known vulnerabilities in OS packages and language dependencies across filesystems, Git repositories, virtual machine images and container images. It does not inspect running listening ports, so it supports R1 only indirectly. Its value is in showing which packages and services are installed in an image, which lets you confirm that unneeded components are absent from a build. Use it alongside a port listing, and confirm that the images you scan match the ones deployed in your ESP.

What your team, a partner and the auditor each own

Your organization is the registered entity, so it owns the CIP-007-6 R1 obligation in full. That means deciding which logical network accessible ports and services each in-scope BES Cyber System, Protected Cyber Asset and applicable access control or monitoring system needs, recording the business or technical reason for each one, and deciding whether a port stays open, is disabled or is accepted with a documented justification. Your team also carries the operational consequences: change windows, vendor coordination and rollback plans when a port is closed on a live system.

Port need decisions: Approve the documented need for every enabled port, including port ranges or services used for dynamic ports.
Disable or accept decisions: Own the call to close a port or to accept a risk, and record who made it and when.
Physical port controls: Decide how unused USB, console and Removable Media access is blocked on high impact systems and qualifying medium impact Control Center assets.
Operational change: Schedule and test port changes so that protection does not disrupt Real-time operations.
Baseline ownership: Keep the port list aligned with the configuration baseline under CIP-010-4.

Confirm with your compliance lead which individual signs off on each port decision and where those approvals are stored for the audit period.

Where organizations fall short on CIP-007-6 R1

Most CIP-007-6 R1 findings come from port lists that were never tied to a specific device, a documented need, or the baseline configuration. The gaps below cluster around evidence, scope and drift, and each one has a closing action that an auditor can verify.

Undated port lists

A port list exported from a spreadsheet or a vendor screen, with no device name, date or collection method, is hard to defend. The standard expects a listing of logical network accessible ports that can be traced to a specific Cyber Asset. Capture the listening ports directly from each device, such as configuration files or command output like netstat, and record the device, the date and the person who collected it. Ask the auditor which evidence format they accept before you build the process around one tool.

Enabled ports without documented need

Services often stay enabled because they were on by default during installation. Each enabled port needs a recorded reason tied to a function the BES Cyber System performs. Walk through every listening port with the system owner and document the business or operational purpose, the protocol and the peer systems that use it. Ports with no owner or purpose should be disabled through change control, with the change recorded as evidence.

Open dynamic port ranges

Some services need port ranges to handle dynamic sessions, and the standard allows them where they are needed. Problems arise when a broad range stays open with no explanation of which service requires it or why a fixed port would not work. Narrow each range to the smallest set the service needs, record the service and the reason for the range, and confirm the range in the device configuration. Ask the vendor to state in writing which ranges their product requires.

Physical ports left unaddressed

The standard also covers physical input and output ports used for network connectivity, console commands or Removable Media on the in-scope systems. Teams often document logical ports carefully and never check USB ports, serial consoles or front-panel interfaces. Inventory these ports for each in-scope asset, then either disable them, protect them with physical controls, or document why they must stay active. Confirm the scope against the applicable impact rating and the Physical Security Perimeter before you finalize the list.

Vendor-managed port state

When a vendor manages a device, the entity may not know which ports the vendor has opened for remote support, updates or diagnostics. The entity remains responsible for the port state, so vendor-managed devices need the same listing and justification as internally managed ones. Require the vendor to provide port state on request, or to deliver a configuration export on a set schedule, and write that obligation into the contract. Check that the export shows the actual listening state rather than the intended design.

Port lists drifting from baseline

CIP-010-4 requires logical network accessible ports to appear in the baseline configuration, so a port list that differs from the baseline is a finding in two places. Drift usually follows patches, firmware upgrades or new services added during maintenance. Compare the current listening ports with the approved baseline after each change, and reconcile any difference through the change process. Keep the comparison output as evidence so the port list and the baseline tell the same story.

Questions buyers ask about CIP-007-6 R1

How much effort does CIP-007-6 R1 take, and what drives it?

The effort depends mostly on how many BES Cyber Systems, PCAs and nonprogrammable communication components fall in scope, and how many logical ports and physical ports each device has. Effort rises when devices are old, undocumented or run many services, because each enabled port needs a recorded business or technical need. Effort falls when systems are standardized, when baselines already list ports, and when the entity has a repeatable way to close unneeded services. Ask any partner for a quote built from an inventory of in-scope assets, the device types involved and the number of ports to justify, not from a flat headline figure.

How long does preparation for CIP-007-6 R1 typically take?

Preparation usually runs longer for large fleets with poorly documented services than for small, standardized sites, and the work is paced by how fast owners can confirm port needs. The main time sinks are asset discovery, interviews with system owners about why each port is open, and fixing devices that carry unnecessary services. No supplied timeline applies here, so ask any partner to state the duration in the written scope, and confirm with your own compliance team how many systems can realistically be reviewed each cycle without disrupting operations.

What does the requirement need from our own staff?

The requirement needs people who own the systems and can explain them, not just people who run scanners. Operations staff must confirm which logical ports are required and why, and must agree to disable services that are not needed. Physical port protection needs facilities or field technicians who can verify locks, port blockers or disabled USB and console access on in-scope devices. Compliance staff must keep the justification records and evidence current. Ask who on your side signs off on each port decision before any partner starts work.

Can an in-house team meet CIP-007-6 R1 without outside help?

Yes, an in-house team can meet CIP-007-6 R1 if it has staff who understand the in-scope assets, the time to document each port and the authority to change configurations. Many entities keep control of the requirement and use outside help only for specific gaps, such as a one-time asset review or a second look at evidence. The organization remains responsible for its own compliance either way. Test your team's readiness by asking whether it can produce a current list of listening ports for every in-scope device, with a documented need for each one, within the audit window.

Can a partner produce the port evidence for CIP-007-6 R1?

A partner can prepare the systems and assemble evidence, but the entity owns the controls and the determination of need. DeployOpen, for example, can help document listening ports from device configuration files, capture command output such as netstat or port scan results, and organize the justification for each enabled port in a form an auditor can follow. Open-source tools such as Wazuh Security Configuration Assessment, which checks configurations against YAML policies, and Greenbone Community Edition, which runs vulnerability tests, can support this work. Confirm with the partner which evidence they will produce, who keeps it, and how it is retained.

Does an auditor issue a certificate for CIP-007-6 R1?

No. There is no CIP certificate. The Compliance Enforcement Authority, which is a Regional Entity or NERC, monitors compliance through Compliance Audits, Spot Checks, Self-Certifications, Self-Reports and other mechanisms. A consultant or partner does not issue a compliance report or attestation either. What an entity can show is evidence that its ports are controlled and documented, which the monitoring body reviews. Ask any firm that offers a certificate for this requirement to explain what document they would issue and under what authority.

What happens if an unneeded port is found open during an audit?

An open port without a documented need is a finding against the requirement, and the consequence depends on severity, duration and whether the entity self-reported it. Penalties are set under NERC's Sanction Guidelines, where the maximum civil penalty referenced is $1,584,648 per violation, per day, as adjusted by FERC Order No. 906 and shown in the eCFR in October 2026. Most entities avoid this exposure by reviewing ports on a schedule, recording the reason for each one and disabling services that lack a need. Ask your compliance lead how open ports are tracked between reviews.

How DeployOpen scopes and prepares CIP-007-6 R1 port evidence

DeployOpen prepares the systems and evidence behind CIP-007-6 R1 Ports and services inside your own infrastructure, on a fixed scope agreed in writing before work starts. Your organization keeps ownership of its controls, and an independent auditor or the Compliance Enforcement Authority reviews the result.

How we scope

Confirm which BES Cyber Systems, PCA and nonprogrammable components fall under the R1 Applicable Systems table.
Record which systems sit inside a PSP and ESP, since Part 1.2 applies to those assets.
Agree the written scope, deliverables and timeline before any configuration or testing begins.

How we build

Collect listening port inventories from device configuration files and running services on each in-scope asset.
Document the business or operational need for every enabled port, port range and dynamic service.
Test physical input and output port protections, such as console and Removable Media controls, and record the results.

How we hand over

Deliver a port and service register, with per-asset evidence such as command output and configuration excerpts.
Align the port baseline with the CIP-010-4 R1 baseline configuration so both standards point to the same record.
Provide documented procedures so your staff can repeat the checks and produce evidence for a future audit.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial engagement closes.
Confirm with your Regional Entity which evidence format and sample period it expects before the evidence is finalized.
Review port baselines again after significant changes, so the evidence stays current between monitoring engagements.