Argo CD for NERC CIP-010 change management

How Argo CD supports NERC CIP-010 configuration change management

Argo CD can supply much of the evidence behind CIP-010-4 R1 Parts 1.1 to 1.3 for BES Cyber System workloads on Kubernetes, and it can support parts of Parts 1.5 and 1.6 through Git and sync controls. It does not replace your CIP program, the review of the Compliance Enforcement Authority, or the vendor integrity checks the standard requires. DeployOpen prepares systems, controls and evidence for your assessment; it does not issue audit reports or certifications. Before any of this matters, confirm applicability: CIP-002-5.1a determines whether a system is high, medium or low impact, and most CIP-010 requirements apply only to high and medium impact BES Cyber Systems and their associated EACMS, PACS and PCA. A cluster hosting a low impact asset may need far lighter treatment, so confirm the scoping with your Regional Entity-facing compliance team first.

Part 1.1 asks for a baseline that records operating system or firmware versions, installed application software with versions, custom software, logical network accessible ports and applied security patches. Argo CD can hold the declared desired state of the workloads in Git, so the manifests, Helm values and Kustomize overlays become the baseline source of record. It does not discover the operating system, firmware or host packages on the nodes, so those items need a separate inventory and must be reconciled to the Git baseline. For Part 1.2, the useful control is the pull request: a deviation from the baseline is proposed, reviewed and approved in Git before Argo CD syncs it, and the sync history and Kubernetes events show what changed and when. Part 1.3 requires the baseline to be updated within 30 calendar days of a completed change, which in practice means the merged commit should be the baseline update, with a documented check that the live state matches it.

Parts 1.4 and 1.5 depend on decisions your team makes outside Argo CD. For Part 1.4, you must decide which CIP-005 and CIP-007 controls a change could affect and verify afterward that they were not adversely affected, so your change templates should name those controls and link to post-sync checks. For Part 1.5, Argo CD can deploy to a separate test cluster with the same manifests, which helps model the baseline, but you must confirm with your team whether a test environment is technically feasible for each high impact system and document the results before production. For Part 1.6, Argo CD does not verify the identity or integrity of vendor software. Use signed artifacts, pinned image digests and your supply chain procedures, and confirm which software sources offer an integrity method. Also protect the repo-server from untrusted repositories, since it runs Helm and Kustomize on repository content.

Mapping CIP-010-4 R1 parts to Argo CD capabilities and configuration

This table compares each CIP-010-4 R1 part against what Argo CD documents as Git-based desired state, RBAC, projects, sync history and secret handling, plus the configuration you need and the work that stays with your organization. Read each row as a control you assemble from Argo CD evidence and your own process, not as a finding Argo CD makes on its own. The main takeaway is that Argo CD produces change records and enforces a declared state, but authorization, impact analysis, test results and integrity decisions remain your responsibility.

Requirement	Argo CD capability	Configuration needed	What remains with the entity
Part 1.1: Baseline contents (OS or firmware, application software with versions, custom software, logical ports, security patches)	Git holds the declared desired state of Kubernetes manifests, Helm or Kustomize sources and pinned image tags, so the baseline is a versioned set of files that can be diffed and reviewed.	Pin chart versions and image digests in Git, keep one directory or repository per BES Cyber System group, and use a dedicated repository for baseline definitions separate from application code.	Listing the operating system or firmware versions, ports and security patch levels, which often live below the Kubernetes layer and must be captured in your own baseline document.
Part 1.2: Authorizing and documenting deviations from the baseline	Git pull requests record who proposed and who approved a change. Argo CD sync history shows what was applied and when, and RBAC limits who can sync.	Require reviewed pull requests on the baseline branch, separate sync permissions from merge permissions through Argo CD projects and RBAC, and confirm that manual syncs and out-of-band edits are restricted.	Defining what counts as a deviation, naming authorizers, and documenting emergency changes made outside the normal pull request path.
Part 1.3: Updating the baseline within 30 calendar days of completing a change	Because the merged commit is the baseline, the baseline is updated when the change merges. Git history supplies the dates needed to show the update timing.	Make the merge into the baseline branch the same step as the change, and avoid applying changes from branches that never merge back.	Tracking the 30-day clock for changes that cannot be merged immediately and confirming that the repository matches what is actually running in production.
Part 1.4: Identifying affected CIP-005 and CIP-007 controls before and verifying after the change	Argo CD shows a diff of live state against Git and reports sync status, which supports post-change verification that the declared state was applied.	Enable drift detection and health status for applications, and keep network policies and access settings declared in Git so they appear in the same diff.	Analyzing which Electronic Security Perimeter and system security controls a change could affect, and performing the post-change checks on ports, access and patching that Argo CD does not evaluate.
Part 1.5: Testing changes in a test environment that models the baseline, with results documented before production	Argo CD projects and separate destination clusters let you promote the same Git revision through a test environment before production.	Use separate Argo CD projects and destination clusters for test and production, promote one reviewed commit through both, and keep sync results with the change record.	Deciding whether a test environment is technically feasible for high impact systems, making sure it models the baseline, and writing up the test results.
Part 1.6: Verifying the software source and integrity before baseline changes to operating systems, firmware, application software or security patches	Argo CD reads from configured repositories and registries. Repository credentials are stored as Kubernetes Secrets, and API and log output redacts credentials.	Restrict repository and registry sources to approved entries in Argo CD, define repositories as Kubernetes Secrets, and confirm with the vendor and in your own testing whether commit signature or image signature checks are available in your Argo CD version before you claim them.	Verifying the identity and integrity of each software source using the method the vendor provides, retaining that evidence, and deciding how untrusted repositories are blocked, since the repo-server runs Helm and Kustomize on repository content.

Configuring Argo CD so baselines and changes are auditable

This sequence sets up Argo CD so that every workload's desired state lives in Git, every change is traceable to an approved pull request, and access to sync and edit functions is limited to named roles. The result is a configuration that produces the records a CIP-010 audit would sample.

Install Argo CD with the built-in admin user as a temporary path
The platform team installs Argo CD in the BES Cyber System management environment, keeping the cluster inside your own network boundary. The initial admin account is used only to finish setup, and the team records who holds it and where its credential is stored. Done means Argo CD answers on its intended internal address and the admin login works for setup tasks only.
Connect SSO and map groups to Argo CD roles
The identity team connects Argo CD to your workforce identity provider, either through the bundled Dex with a supported connector or through a direct OIDC integration. Identity provider groups are then mapped to Argo CD roles so that operators, approvers and auditors each receive only the access their role needs. Done means a test user from each group signs in and sees only the permissions assigned to that group.
Disable the admin user after access is confirmed
Once SSO or local users are working, the administrator sets admin.enabled to false in the argocd-cm ConfigMap, as the user management documentation recommends. The change itself is committed through your change process and the team keeps a record of the date. Done means the admin login is rejected and every change is traceable to a named individual.
Define repositories as Kubernetes Secrets
Repository connections are created as Kubernetes Secrets rather than entries in argocd-cm, because Argo CD 3.0 removed repository configuration from that ConfigMap. The Git repositories holding baselines are registered with read-only credentials, and the list of approved repositories is itself tracked in version control. Done means the approved repository list in the cluster matches the list your change board approved.
Create separate projects for test and production workloads
Engineers define one Argo CD project for test BES Cyber System workloads and another for production, each limited to its own destination clusters, namespaces and source repositories. Production changes can only reach production destinations, which supports the test-before-production sequence in Part 1.5. Done means a test application cannot be synced into a production namespace, and an attempted sync is rejected and logged.
Restrict update and delete permissions in RBAC
The security engineer writes RBAC policies that grant sync rights to the deployment role and withhold update and delete rights on applications from most users. Since Argo CD 2.14 to 3.0, update and delete permissions apply only to the application itself, and logs access requires an explicit logs, get permission, so the team grants these deliberately. Done means a test login without sync rights is refused a sync and the policy file is stored in Git.
Require pull request approval before any sync
The team configures the baseline repositories so that changes merge only after review by an approver who is not the author, and Argo CD tracks only the approved branch. Because the sync role is separate from the merge role, a deviation from the baseline must pass review before Argo CD applies it. Done means an unapproved commit does not sync and each sync history entry points to a merged, reviewed commit.
Set the Argo CD version plan from the release cadence
The platform owner records the Argo CD minor version in use and schedules upgrades against the project's quarterly minor release cadence. Only the three most recent minor versions receive patch releases, so the plan names the supported patch line and the review date for each upgrade. Done means a written version plan exists, approved through change management, and each upgrade is tested in the test project before production.

Evidence Argo CD produces for CIP-010 reviews

A CIP-010 review asks for proof that each baseline change was authorized, tested where feasible, and recorded in the baseline. Argo CD produces much of that trail as a byproduct of Git and sync activity, but the entity still has to keep it, link it, and write down its own decisions.

Git history of baseline files

Baseline manifests, Helm values and Kustomize overlays stored in Git form the Part 1.1 baseline record. Each commit shows the author, the diff and the reviewer approvals on the merge request, which together support Part 1.2 authorization. Confirm that your Git host retains approval records and branch protection settings for the full audit period, and export them on a schedule.

Sync history and Kubernetes events

Argo CD records each sync with its revision, initiator and result, and Kubernetes emits events for the resulting object changes. Together they show what was applied to a BES Cyber System workload and when, which supports the Part 1.4 check that affected CIP-005 and CIP-007 controls were not adversely affected. Confirm how long your cluster and Argo CD retain these records, since they may age out sooner than your evidence retention period.

RBAC and SSO group records

Project roles, policy bindings and the identity provider groups mapped to them show who could approve, sync or override a change at each date. Keep exports of the RBAC configuration and the SSO group membership history alongside the Git records. Confirm that admin.enabled is set to false, since local admin activity is harder to tie to a named individual.

Argo CD version and patch level

The Argo CD version running at each date is part of the configuration of the tool that enforces your baseline. Record the version and patch level in your change log whenever you upgrade or patch, and keep the upgrade notes that justified the change. Confirm the supported patch lines against the release process before planning a window, because only the three most recent minor versions receive patches.

Test environment sync results

For changes to high impact systems where testing is feasible, the sync to a test environment and its results should be documented before the production sync. Keep the test cluster's sync output, the test result summary and a link to the Git commit promoted to production. Confirm with your compliance team how the test environment is scoped to model the baseline, since Part 1.5 depends on that.

Written 30-day baseline update record

Part 1.3 requires the baseline to be updated within 30 calendar days of completing a change. Keep a dated record for each change that links the baseline update to the Git commit, the authorization and the post-change verification. Track these records in a register with an owner for each item, so an overdue update is visible before a review finds it.

Test and production separation for high impact workloads

When test and production share one cluster, the separation comes from Argo CD projects and Kubernetes namespaces. Part 1.5 accepts a test environment or a production environment that minimizes adverse effects and models the baseline, so a shared cluster can work only if each environment is governed the same way the baseline is. Use one AppProject per environment so the boundary is explicit in configuration and in the records.

Separate AppProjects: Define one project for test and one for production, each with its own allowed source repositories and destination namespaces.
Restricted destinations: Limit each project to named namespaces so a test application cannot write into production namespaces.
Promotion in Git: Promote the same reviewed commit or tag from the test project to the production project, so production matches what was tested.
Narrower production permissions: Grant sync rights in the production project to a smaller group than in test, and record who holds them.

Confirm with your CIP compliance lead whether a shared cluster meets your documented definition of a test environment for each applicable system, since that determination belongs to your registered entity.

What Argo CD does not cover for CIP-010

Argo CD can hold the desired state and record authorized changes for workloads on Kubernetes, but several CIP-010 obligations sit outside the tool or depend on decisions only the entity can make. The cards below mark those boundaries so the compliance team plans the remaining work before the first audit request.

No certificate, no automatic compliance

There is no CIP certificate. NERC and the Regional Entity monitor compliance through audits, spot checks, self-certifications and self-reports, and they test the entity's own records. Argo CD produces Git history and sync records, but an auditor will still ask whether your baselines match the Applicable Systems list, whether each deviation was authorized and whether the evidence covers the whole period. Confirm with your Compliance Enforcement Authority which evidence format it expects.

Operating system and device baselines

Part 1.1 covers operating system or firmware with version, and it covers baselines for devices that are not Kubernetes objects. Argo CD manages only the resources it can reach through the Kubernetes API. Host operating systems, hypervisors, network devices, relays, controllers and human-machine interface hardware need a separate baseline source, such as a configuration management tool or vendor images, with its own change records. Map each asset class to a named tool before the audit window opens.

Security control impact analysis

Part 1.4 requires you to determine, before each baseline change, which CIP-005 and CIP-007 controls could be affected, and to verify afterward that they were not adversely affected. Argo CD cannot make that judgment. Your team must maintain a mapping from Kubernetes resource types, such as network policies, service accounts, ports and logging agents, to the specific CIP-005 and CIP-007 requirements they support, and the change record must reference that mapping.

Vendor software integrity verification

Part 1.6 applies to high and medium impact systems and their EACMS and PACS, and it requires verifying the identity of the software source and the integrity of the software before a baseline change, where the source makes a method available. Argo CD can check the signatures or provenance data your pipeline produces, but it cannot create them. For vendor-supplied charts and images that offer no verification method, document that fact and the compensating review you performed.

Repo-server exposure to untrusted content

The Argo CD repo-server runs Helm and Kustomize against repository content, so a malicious or careless chart can execute during rendering and reach the cluster. Limit which repositories are registered, restrict who can add them, and review chart and Kustomize sources before they become baselines. Track each approved repository as a supply chain input, because a baseline is only as trustworthy as the source it renders from.

The CIP-013-2 supply chain plan

CIP-013-2 requires a supply chain risk management plan covering vendor incident notification, vulnerability disclosure, software integrity and authenticity verification, and coordination of vendor-initiated remote access. The plan is reviewed at least every 15 calendar months. Argo CD may support parts of the software integrity step, but the plan itself is a separate governance document with its own owners, reviews and vendor contracts. Treat it as a separate deliverable and cross-reference it from your CIP-010 procedures.

Questions buyers ask about CIP-010 and Argo CD

Does Argo CD alone satisfy CIP-010 requirements?

No. Argo CD is a delivery tool, and CIP-010-4 is a program obligation that the entity must run and evidence. Argo CD can hold baselines in Git, enforce authorized changes through reviewed commits and syncs, and keep a sync history that supports the records an auditor samples. The entity still has to define which systems are in scope, document the baseline contents required by Part 1.1, determine affected CIP-005 and CIP-007 controls for each change under Part 1.4, run and document test results under Part 1.5, and verify software source and integrity under Part 1.6. Those steps depend on processes, roles and approvals that sit outside the tool.

What does a compliance-oriented Argo CD setup cost?

Cost has three components. The first is a DeployOpen fixed-scope engagement, priced from a written scope that lists clusters, baselines, Git and approval workflows, and evidence outputs. DeployOpen does not publish a price list, so ask for a quote tied to that scope. The second is internal engineering time for the platform, Git repository structure, identity integration and cluster access. The third is effort from the CIP program, including the CIP-002 impact review, control mapping, auditor preparation and the Compliance Enforcement Authority's review of evidence. Most of the internal effort is recurring: baseline updates, change reviews and periodic evidence collection continue after the build. Ask each quote to separate one-time build work from ongoing support.

How long does a CIP-010 Argo CD project take?

Duration depends on scope, and no fixed timeline applies to every entity. The main drivers are the number of clusters and BES Cyber System workloads in scope, how many distinct baselines the entity must define, how mature the existing Git and identity setup is, and how many approval paths and test environments must be modeled. A single high impact environment with a few baselines is a different task from a fleet spread across several sites. Ask for a timeline in the written scope, with milestones for baseline definition, change workflow, test evidence and a review with the CIP program owner before production use.

What does the entity need to provide before the work starts?

The entity needs a current CIP-002 impact categorization that lists which BES Cyber Systems are high, medium or low impact and which workloads they run on. It also needs named system owners who can approve baseline content, a change board or equivalent authority that authorizes deviations under Part 1.2, and access to the CIP-005 and CIP-007 control documentation so that the Part 1.4 impact determination can be made. Technical inputs include cluster inventories, current operating system and application versions, and the sources of approved software and patches. Confirm these items during scoping, because gaps in the impact list usually change the set of clusters that must follow the process.

Can our team set this up without outside help?

Yes, a team can build this internally, provided it has Argo CD engineers and people who understand the CIP standards well enough to scope the work. The CIP side needs the most care: deciding which assets fall under each applicable system category, determining which CIP-005 and CIP-007 controls a change could affect, and deciding what test evidence is sufficient. Teams without that background often use an outside partner for scoping and a written review, then run the day-to-day process themselves. Whichever path you choose, have the compliance lead review the baseline and change design before production use.

What are the penalties for CIP-010 violations?

The maximum civil penalty under the federal rules is $1,584,648 per violation per day, according to the eCFR text of 18 CFR 385.1602. Penalties are set by the Compliance Enforcement Authority, which may be a Regional Entity or NERC, and depend on factors such as severity, duration, cooperation and the entity's compliance history. Argo CD does not remove that exposure by itself. Its value is in producing consistent records of baselines, authorizations and sync history, which help an entity show what changed, who approved it and when. Confirm current figures against the source before relying on them in a board or regulatory briefing.

How do Git baselines map to the CIP-010 Part 1.1 contents?

Part 1.1 asks for a baseline that lists operating system or firmware with version, intentionally installed application software with version, custom software, logical network accessible ports, and applied security patches. In practice, teams store these items as versioned manifests, Helm values, Kustomize overlays and a patch inventory in a Git repository, with the approved state reviewed through pull requests. Ports and network policies are declared as code, and patch levels are recorded with the image digests or package versions they deploy. Some items, such as host operating system or firmware, may sit outside the cluster manifests and need a separate record. Verify that every Part 1.1 element has a source of truth before treating the repository as the baseline.

Where CIP-010 scope meets Argo CD architecture

Your CIP-002 impact categorization decides which clusters and workloads Part 1.1 through 1.6 reach. CIP-002-5.1a sorts BES Cyber Systems into high, medium and low impact using bright-line criteria, and most CIP-010 requirements apply only to the systems named in its Applicable Systems column. Before you design the Argo CD topology, confirm with your compliance team which BES Cyber Systems run on each cluster, whether any Protected Cyber Assets, EACMS or PACS sit beside them, and whether the cluster hosts a single impact level or mixed levels. A cluster that mixes high impact workloads with lower-impact ones will push its Git repositories, Argo CD Projects and destination clusters into the strictest scope, so separating impact levels at the cluster and Project boundary is usually a decision to make early, not late.

Within that scope, the Argo CD components matter to CIP-010 mainly for records and availability. The API server authenticates users and writes the audit trail of sync and rollback actions, the repo-server renders manifests from Git, and the application controller compares live state with the declared state and applies changes. Redis is a disposable cache, so losing it does not lose baseline records, but losing the controller or API server stops authorized change and drift detection. The high availability documentation says HA manifests need at least three nodes because of pod anti-affinity rules, so confirm that your in-scope cluster has three schedulable nodes before you count on failover. Confirm also how long your Kubernetes event and Argo CD logs are retained, since those logs are what you will show as evidence of each change.

How DeployOpen scopes a CIP-010 Argo CD configuration

DeployOpen scopes this work as a fixed-scope engagement, and the scope is agreed in writing before any build starts. The first input comes from the entity, not from DeployOpen. The entity's compliance lead needs to state which assets are high, medium or low impact under CIP-002-5.1a, which BES Cyber Systems sit on the Kubernetes clusters in question, and which of them carry the Applicable Systems that CIP-010-4 Part 1.1 and Part 1.6 reach. Impact categorization determines whether the Argo CD design needs to cover only high impact systems, medium impact systems with External Routable Connectivity, or associated EACMS and PACS. The written scope should list the clusters, namespaces and Argo CD projects in each category, and name the entity's internal owner for every decision that the categorization drives.

The next steps are the baseline inventory and the Argo CD configuration. The inventory records, per group of workloads, the operating system or firmware with version, the open-source and custom application software with versions, the logical network ports and the security patches applied, which is the content Part 1.1 requires. DeployOpen then maps that inventory to Git paths, Argo CD Applications and projects, and the RBAC roles that can authorize a sync. The scope should state which Argo CD settings are in the design, such as single sign-on, disabling the built-in admin user, and the repository credential approach, along with the items the entity still has to confirm in its own environment, including any vendor platform support it requires.

Evidence design comes last, and it is where DeployOpen states its boundary. The scope defines which records map to Part 1.2 authorization, Part 1.3 baseline updates, Part 1.4 CIP-005 and CIP-007 checks and Part 1.5 test results, and where each one is retained. DeployOpen prepares the systems, controls and evidence for these checks. It does not issue audit reports or attestations, and it does not determine compliance. Independent auditors and the Compliance Enforcement Authority, which is a Regional Entity or NERC, make those determinations through the monitoring methods listed in the NERC Rules of Procedure Appendix 4C. Ask for the written scope to say so explicitly, and confirm the retention period and evidence format with your compliance team and auditor before the build begins.

How DeployOpen delivers CIP-010 change management configuration

DeployOpen plans, implements and documents Argo CD inside the infrastructure you control, so that Git holds the baselines and Argo CD records the authorized changes that CIP-010-4 R1 asks you to show. We scope the work in writing first, then build and test it against the parts of the standard your compliance team has to evidence.

How we scope

We confirm which BES Cyber Systems, clusters and namespaces fall under CIP-010 and which impact categories apply to them.
We agree in writing which baseline elements in Git cover OS, application, custom software, ports and patch levels.
We document which CIP-005 and CIP-007 controls each change type could affect, so the pre-change check has a defined scope.
Engagements are fixed-scope, with deliverables and timelines agreed before work starts, and ongoing support is available as a retainer.

How we build

We structure Git repositories and Argo CD projects so baselines, change approvers and sync permissions are separated by design.
We configure pull request approval, protected branches and sync windows so every baseline deviation has a recorded authorization.
We build a test environment that models the production baseline and document the test results that R1 Part 1.5 expects.
We set up source verification of Helm charts, container images and other software before it enters a baseline, where the source offers a method.

How we hand over

We deliver documented runbooks for baseline updates, including the 30 calendar day window in R1 Part 1.3 and who owns each step.
We provide evidence mapping that shows which Git commits, approvals and sync records answer each CIP-010-4 requirement.
We walk your compliance and operations staff through the change flow, emergency change handling and post-change verification steps.
We hand over configuration of SSO, RBAC and the disabled built-in admin account so access evidence is ready for review.

How we support

Retainers can cover Argo CD patch and minor upgrades, with the supported version list checked before each change.
We review baseline drift reports and unauthorized change alerts, and we agree how findings move into your change records.
We help prepare your evidence for compliance audits. DeployOpen does not issue audit reports, attestations or certifications, so independent auditors and the Compliance Enforcement Authority make that determination.
We revisit the baseline and the change mapping when CIP standard versions or your system inventory change.

Argo CD for NERC CIP-010 configuration change management