Open-source tools for NERC CIP controls and evidence

Which open-source tools can produce NERC CIP evidence, and what they cannot do

Several open-source tools can generate recurring evidence for CIP configuration monitoring, vulnerability assessment, remote access recording, network monitoring, change records and backups. The entity owns its controls, and only the Compliance Enforcement Authority, a Regional Entity or NERC, judges compliance. There is no CIP certificate, so a tool's output is only as useful as the control it supports and the records that show who acted on it. Whether a given tool matters at all depends first on the entity's impact categories under CIP-002, then on the Applicable Systems listed in each standard. A tool that fits a high impact Control Center may be unnecessary for a low impact asset, and a tool that is free to use in one environment may carry license limits in another.

License terms need the same attention as technical fit. The Teleport Community Edition binaries are limited to organizations with fewer than 100 employees and less than US$10 million in annual revenue, so a larger entity must build from the AGPL source or buy an enterprise edition. Security Onion moved to the Elastic License 2.0 starting with version 2.4, which forbids offering the software as a hosted or managed service. Bundled tools such as Zeek and Suricata keep their own open-source licenses. Before selecting a tool, confirm the edition, the license text and the organization's size and service model with the vendor or its legal team.

DeployOpen plans, deploys, configures and documents these tools inside the client's own cloud accounts, data centers or air-gapped networks, and prepares the evidence they produce for the entity's own review. DeployOpen does not issue audit findings, attestations or compliance determinations. Ask any implementation partner to show, in writing, which CIP requirement each tool supports, which Applicable Systems it covers, what gaps remain, and who in the entity approves the evidence. The entity's CIP Senior Manager and compliance team should own that mapping before an audit notification arrives.

Which CIP controls generate recurring evidence

Six CIP requirement areas produce evidence on a schedule rather than once, so auditors ask for the same kind of record again in every review period. Each card names the requirement, the recurring evidence an auditor typically asks for, and the open-source category that can produce it. Confirm the Applicable Systems for each requirement with your CIP-002 categorization before you choose a tool.

Configuration and file integrity monitoring

CIP-010 requires baseline configurations and monitoring of changes to them, with a monitoring cycle of 35 days. The recurring evidence is the baseline itself, a dated record of detected changes, and a trail showing who investigated each unauthorized change. File integrity monitoring tools such as Wazuh keep checksums and attributes for monitored files, then alert on creation, modification or deletion. Confirm which Cyber Assets fall in scope, because the baseline must cover what the Applicable Systems table requires.

Vulnerability assessment records

CIP-010 R3 requires paper and active vulnerability assessments on set cycles, with action plans for findings. Auditors ask for the assessment date, the scope tested, the tool and feed version used, and the disposition of each finding. Open-source scanners such as Greenbone Community Edition run tests against target systems and produce reports, while software inventory correlation tools such as Wazuh can support the paper assessment. Check what each tool misses, especially devices that do not respond to active scanning.

Interactive Remote Access logs

CIP-005 requires Interactive Remote Access to pass through an Intermediate System with encryption and multi-factor authentication. Auditors ask for records of who connected, when, to which asset, and what was done during the session. An open-source access proxy such as Teleport can record SSH sessions and store recordings with audit events, but its prebuilt Community Edition binaries are limited to organizations with fewer than 100 employees and under US$10 million in revenue. Larger entities should confirm the license terms before deployment.

Internal network security monitoring

CIP-015-1 requires internal network security monitoring inside the Electronic Security Perimeters of covered high and medium impact BES Cyber Systems, and it becomes subject to future enforcement from 1 October 2028. Evidence typically includes network alert records, protocol metadata and retained packet captures that show internal traffic was reviewed. Security Onion can collect Suricata alerts, Zeek metadata and full packet capture, but it is licensed under the Elastic License 2.0, which is not an open source license under the OSI definition. Confirm the license terms with counsel before you adopt it.

Change control records

CIP-010 change control requires authorization, impact analysis and documented testing before a baseline changes, and CIP-013 requires supplier work to follow the entity's supply chain plan. Auditors ask for the change request, the approval, the impact analysis, and the closed record showing the change matched the approval. GLPI can hold change records with impact analysis, deployment and backup plans, approval requests and links to affected items. Confirm that the approval workflow matches the CIP Senior Manager delegations you have documented.

Backup and restore test records

CIP-009 requires recovery plans, backups that can be verified, and tests of the plan on a 15-month cycle. Auditors ask for the backup schedule, verification results and records of restore tests, including which data was sampled and whether the result met the plan. Bareos can schedule backup, restore and verify jobs and keeps a SQL catalog of backed-up files, which supports a dated record of each test. Confirm the retention period and off-site storage requirements that apply to your recovery plan before you set the schedule.

How Wazuh and Greenbone support CIP-010 baselines and vulnerability assessments

Wazuh and Greenbone cover two different parts of the CIP-010 evidence trail. Wazuh's file integrity monitoring (GPL-2.0-only) records a baseline of checksums and attributes for the files and directories you select, then raises an alert when a user or process creates, modifies or deletes one of them. Checks can run on a schedule or in real time, and each alert shows how the file changed and who changed it. For a CIP-010 baseline, the useful work is deciding which directories, configuration files and binaries belong in the monitored set on each in-scope Cyber Asset, then keeping that list reviewed against the baseline configuration. Confirm that the agent can run on each operating system in your environment, and that the alert history can be exported and retained for the audit period your Regional Entity uses.

Wazuh's vulnerability detection (also GPL-2.0-only) works from a different input. Each agent reports its software inventory, and Wazuh matches that inventory against the Wazuh CTI vulnerability repository or a locally hosted offline copy. The offline option matters for control networks with restricted egress, because the vulnerability data can be updated from inside the perimeter rather than from the internet. Greenbone Community Edition, built on the OpenVAS Scanner (AGPL-3.0-or-later), is an active scan engine. It runs vulnerability tests from the Greenbone Community Feed, which is updated daily, and is driven by gvmd over the Open Scanner Protocol. Before you rely on either tool for CIP-010 R3, confirm coverage for your specific operating systems, OT devices and firmware, and confirm that an active scan is safe for each device type. Many OT devices should be assessed by paper review or vendor-supported methods instead of active probing. Scanner output on its own does not satisfy the R3 assessment record. You still need the documented assessment, the action plan for each finding, and the record of how each finding was resolved or mitigated.

Which license and edition limits apply to each CIP evidence tool

This table compares six open-source tools against the CIP control areas they support, with each tool's license, edition or distribution limits, and the evidence it produces. Read each row as a starting point: a license governs how an organization may use the software, so the limits in the middle column decide whether a tool fits your size and deployment model before you plan any evidence workflow around it.

CIP control area	Product and license	Edition or distribution limits	Evidence the tool produces
CIP-010 configuration monitoring	Wazuh, GPL-2.0-only	Open-source agent and manager; confirm which features and content feeds your deployment uses and their terms	Baseline checksums and attributes, alerts on changes with who changed a file and when
CIP-010 R3 vulnerability assessment	Greenbone Community Edition (OpenVAS), AGPL-3.0-or-later	Community Feed is updated daily; confirm feed terms and scan scope against your asset list	Scan reports of vulnerability tests run against target systems
CIP-005 Interactive Remote Access	Teleport, AGPL-3.0-or-later	Prebuilt Community Edition binaries are limited to organizations under 100 employees and under US$10 million revenue; larger entities must build from source or buy Enterprise	Session recordings of SSH and Kubernetes sessions and audit events stored with them
CIP-007 and CIP-015 network monitoring	Security Onion, Elastic-2.0	Not OSI-approved; hosted or managed service offering is prohibited and license key functionality must not be circumvented	Network alerts, protocol metadata and PCAP files for analyst review
CIP-009 backup and recovery	Bareos, AGPL-3.0-only	Source distribution under AGPL; confirm which packaged builds and modules your environment requires	Catalog of backed-up files and job records for backup, restore and verify runs
CIP-010 change records	GLPI, GPL-3.0-or-later	Confirm which plugins and integrations you add carry compatible licenses	Change records with impact analysis, deployment and backup plans, and approvals

Why the Teleport Community Edition limit matters for CIP-005 remote access

Teleport can produce strong session evidence for an Intermediate System, but the Community Edition license may rule it out for larger registered entities. Teleport records SSH and Kubernetes sessions by capturing full terminal output, records desktop screen and mouse input, and captures database queries and application request events. It stores those recordings in a filesystem, S3-compatible or Google Cloud Storage backend next to its audit events. For a CIP-005 Interactive Remote Access program, that combination maps well to the session visibility and recording evidence an assessor will ask to see, provided the recordings are retained and reviewed as your own procedures require.

The licensing question comes first. Teleport moved its source code from Apache-2.0 to AGPL-3.0 in December 2023 with Teleport 15, and only the /api module remains Apache-2.0. The prebuilt Teleport Community Edition binaries are not open source. They ship under the Teleport Community Edition License, which allows use only by organizations with fewer than 100 employees and less than US$10 million in annual revenue. An organization above either threshold has two routes: build the Community Edition from source under AGPL-3.0, or buy Teleport Enterprise. Building from source carries its own cost, including build pipelines, patch tracking and your own support obligations, so get that effort estimated in writing before you commit.

Before you rely on any feature for CIP-005, check the Teleport feature matrix against the Applicable Systems in your categorization. Confirm authentication, multi-factor authentication, session termination and vendor session visibility in the specific edition and version you will run, not only in the documentation for the latest release. Ask your CIP Senior Manager or compliance lead to approve the licensing position in writing, because a license breach in an Intermediate System creates a separate compliance problem on top of any CIP finding.

How Bareos and GLPI create verifiable CIP-009 and change evidence

This sequence ties each backup and restore action to a planned change record, so an auditor can trace the backup plan, the job results and the restore test back to one documented decision. The entity owns the plan, the test scope and the sample data, and the tools keep the records that show they were followed.

Open a change record with the backup plan
The entity's change owner opens a change record in GLPI for the backup or restore test, then completes the analysis of impacts and controls, the deployment plan, the backup plan and the checklist. Approval requests go to the named users or groups, and links to affected items tie the record to the BES Cyber Systems in scope. The output is an approved change record that names the systems, the backup method and the expected results before any job runs.
Define backup and verify jobs in Bareos
The backup administrator configures Bareos Director jobs for the systems named in the change record, including backup, verify and, where needed, archive jobs. Schedules and retention settings are recorded in the configuration, which the entity should keep under its own change control. The output is a configuration set that matches the approved plan, which an auditor can compare line by line against the change record.
Run backup and verify jobs and retain results
Bareos runs the scheduled backup and verify jobs and writes their status to the job log and the SQL catalog. The administrator exports or archives the job reports and confirms that failed or partial jobs were investigated and recorded. The output is a dated set of job results showing that backups completed and that verification ran against them.
Confirm the catalog holds the backed-up files
The administrator queries the Bareos SQL catalog to confirm which files and systems each backup job recorded, and checks that the catalog matches the systems listed in the change record. Gaps, such as a system missing from the catalog, are logged as findings before the test proceeds. The output is a catalog extract that shows what each backup contains and which backups are available for restore.
Restore from the current or a point-in-time backup
Following the test scope and sample data the entity defined in advance, a recovery team restores selected files or a system from the current backup, or from a backup taken before a chosen date and time. Bareos performs the restore and the team records the restore job, the target environment and the people involved. Because CIP-009 sets the testing cadence (a plan test every 15 months, and an operational exercise every 36 months for high impact systems), the entity must confirm its own test scope, frequency and sample data with its CIP Senior Manager. The output is a restore job record and a test log.
Compare restored data to the expected result
The team checks the restored files or system against the expected results in the change record, such as file hashes, application start-up or a defined functional check. Any mismatch is raised as a deficiency and handled under the entity's recovery plan. The output is a documented pass or fail for each test item, with the evidence that supports the result.
File the test result with the change record
The team attaches the job reports, catalog extract, restore log and comparison results to the GLPI change record and links any follow-up tickets or problems. The change owner records closure, and any update to the recovery plan or backup configuration goes through a new change record. The output is a closed change record that links the plan, the approvals, the job results and the test outcome in one trail for the auditor.

Who owns the controls, who builds the tooling, and who judges it

The registered entity owns its CIP program from end to end. Its CIP Senior Manager and compliance staff decide which assets fall into scope under CIP-002, approve baselines and cyber security policies, accept or reject mitigation plans, and decide what evidence is retained and for how long. When a Regional Entity asks a question, the entity answers it, not the tool vendor or the partner that installed the software. Open-source tools produce records, but the entity must be able to explain what each record means and who acted on it.

Scope and categorization: Decide which BES Cyber Systems are high, medium or low impact and keep that decision documented.
Approvals: Approve configuration baselines, patch decisions and vulnerability action plans, and record who signed each one.
Evidence retention: Define where tool output is stored, who can access it, and how exports are kept unchanged.
Regulator contact: Answer the Evidence Request Tool and interviews with staff who can explain each control.
Staffing: Confirm that named personnel can operate the tools after the project closes.

Before engaging anyone, confirm internally which person signs each CIP requirement and who will answer audit questions on each tool's output.

Where open-source CIP evidence programs usually fail

Most CIP evidence gaps in open-source deployments come from decisions made before the first scan or log is collected. The cards below cover license terms, scanner output, data freshness, retention and change documentation, each with the check that prevents it.

Adopting tools before confirming license terms

A tool can be free to download and still be unusable for your organization. The prebuilt Teleport Community Edition binaries are limited to organizations under a set employee and revenue threshold, so larger utilities must build from source under AGPL or buy Enterprise. Security Onion's Elastic License 2.0 bars offering the software as a hosted or managed service, which matters if a partner operates it for you. Confirm the license against your size, your operating model and your partner's contract before the tool enters an Electronic Security Perimeter.

Treating scanner output as the assessment record

A vulnerability scan report shows what a scanner found, not what the entity decided to do about it. CIP-010 R3 expects a documented assessment process, and findings need an action plan, owner and disposition. Record who reviewed each finding, what was patched, mitigated or accepted, and why. Check that scan scope matches the Cyber Assets in your inventory, since an unscanned asset produces no finding and no evidence.

Letting monitoring data go stale

Configuration monitoring and baseline comparisons only satisfy CIP-010 if they run inside the 35-day window the standard sets. A file integrity agent that stops reporting after a certificate expires or a server is rebuilt leaves a gap that auditors will find in the logs. Set alerts for agents that stop checking in, review collection coverage monthly, and keep a record of every outage and how it was closed.

Missing evidence retention for the audit period

Auditors test evidence from the audit period, not from the day of the audit. Session recordings, FIM alerts, scan reports and backup verification logs often sit on default retention settings or on a disk that fills up. Decide the retention period with your Regional Entity's audit schedule in mind, store recordings and audit events where they will survive a platform upgrade, and test that you can retrieve a record from the start of the period.

Leaving tool configuration undocumented

An auditor may ask who approved a change to a monitoring rule, a scan schedule or an access proxy setting, and why. If that answer lives only in an administrator's memory, the evidence fails even when the tool worked. Record each tool's configuration in version control or a change record, with the approver, the date and the reason for every change. Change records in a system such as GLPI can hold the impact analysis, approvals and linked configuration items.

Questions buyers ask about open-source tools for NERC CIP evidence

Do open-source tools satisfy NERC CIP requirements on their own?

No. Open-source tools generate evidence, such as configuration baselines, scan results, session recordings and backup logs, but they do not make an entity compliant. The registered entity owns its CIP program, and each requirement needs documented policies, defined roles, a Senior Manager accountable for approvals and records showing the control ran on schedule. A tool that produces a record helps only when that record is tied to a documented process, a defined Applicable System and a named owner. Auditors judge the program and its evidence, not the software label.

Can our own staff run open-source CIP tools without an outside partner?

Yes, if your team can install, patch, configure, back up and document the tools and keep them running through the evidence period. The effort depends mostly on the number of Applicable Systems, the number of sites, how many tools you deploy, and whether the tools feed each other or your change management system. Staff also need enough time to review alerts, investigate deviations and write the records an auditor will ask for. Ask internally whether you can keep a tool supported and documented through a full audit cycle, since gaps in operation are often what auditors find.

What drives the cost of an implementation partner, and what recurs?

The main cost drivers are scope, the number of systems and locations in the Applicable Systems, the integrations needed with existing tools such as ticketing or asset inventories, and how mature your evidence already is. Setup work, such as deploying agents, writing baselines and building evidence procedures, is typically one-time, while patching, upgrades, alert review and continuous testing recur. DeployOpen works from a written scope and does not publish a price list, so ask any partner for a quote that separates one-time setup from recurring support, lists the systems covered, and states who owns the evidence afterward. An implementation partner prepares systems and evidence. It does not issue audit findings or attestations.

Which open-source licenses work for a large utility?

Licensing decides what your organization can legally deploy, so check it before choosing a tool. Teleport's prebuilt Community Edition binaries are licensed only for organizations with fewer than 100 employees and less than US$10 million in annual revenue. Larger organizations must build the AGPL source code themselves or buy Enterprise. Security Onion's Elastic License 2.0 is not an OSI-approved open source license, and it forbids offering the software as a hosted or managed service and circumventing license key functionality. Bundled components such as Zeek and Suricata keep their own open-source licenses. Have counsel confirm the license terms for your organization and deployment model.

Must CIP-015 network monitoring be in place now?

Not yet for most entities, but planning should start now. CIP-015-1, Internal Network Security Monitoring, was approved by FERC on 26 June 2025 and is subject to future enforcement from 1 October 2028. It covers internal network monitoring inside Electronic Security Perimeters of high impact and medium impact BES Cyber Systems with External Routable Connectivity. NERC lists CIP-015-2, which extends monitoring to associated EACMS and PACS, as approved by FERC on 10 August 2026 with an effective date of 1 October 2029. Confirm your scope against the current NERC status page, and check whether your architecture and network sensors need budget and change windows before the enforcement dates.

What should we ask an auditor or consultant before signing?

Ask for the scope in writing, including which CIP standards, Applicable Systems and locations are covered. Ask who produces each deliverable, what the entity keeps as its own evidence, and what the partner will not do, since only an independent auditor or Compliance Enforcement Authority issues findings. For a consultant, ask which tools they will deploy, what licenses those tools carry, how upgrades and patches will be handled, and who will be trained to operate them. For an auditor, confirm independence, relevant experience with registered entities, and the process for evidence requests. Request a quote tied to that scope and ask how changes to scope will be priced and approved.

Do open-source tools cover every CIP evidence need?

No. Open-source tools cover several recurring needs, such as file integrity monitoring, vulnerability detection, session recording, network alerting and backup logs, but gaps are common. Scanners may miss assets that do not respond to scans, and evidence from one tool may not show the approval and review steps a standard expects. Before you rely on a tool, test it against the specific requirement, confirm which data it retains, and confirm that its records can be exported and retained for the audit period. Confirm each capability with the vendor or project documentation, since features change between releases.

How DeployOpen deploys CIP evidence tools in your environment

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the tools that generate CIP evidence. We scope each engagement in writing before work starts, so you know which tools, licenses and edition limits are in play before anything is installed. Your organization keeps ownership of its controls, and an independent auditor or Regional Entity reviews the evidence.

How we scope

Written scope names the CIP requirements, applicable systems and evidence each tool must produce.
We confirm license and edition limits for each candidate tool, including the Teleport and Security Onion terms, before selection.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.

How we build

We deploy tools such as Wazuh, Greenbone, Teleport, Bareos and GLPI in your own cloud accounts, data centers or air-gapped networks.
We configure baselines, monitoring schedules, scan policies, session recording and backup jobs to match your documented requirements.
We test each evidence output, such as alert records, scan reports and restore logs, to confirm it can be retrieved for an audit.

How we hand over

We document architecture, configuration, runbooks and the evidence retrieval steps your compliance staff will use.
We map each tool's outputs to the CIP requirements in scope so your team can show which record answers which request.
We confirm in writing which items remain with your organization, such as policy approval, risk decisions and final control ownership.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, separate from the fixed-scope build.
Retainers can cover tool version updates, feed and signature maintenance, and periodic checks that evidence still generates correctly.
Ask any proposed partner to confirm in writing who performs each task, and which tasks remain with your internal staff.