Argo CD for energy and utilities

Why Argo CD for energy and utilities needs a utility-specific build

Argo CD fits a utility when its change flow is Git-based and the cluster it deploys into sits inside a boundary the utility controls. Kubernetes demand is growing in utility environments, but the systems that matter most are often BES Cyber Systems scoped under NERC CIP, and those systems cannot be treated as ordinary application clusters. Argo CD is licensed under the Apache License 2.0, and the project itself offers no paid edition, so the software cost is not the question. The real work is deciding which clusters Argo CD may touch, how they are segmented from operational networks, and what evidence the change process will produce for an auditor.

Start by mapping each target cluster to the CIP impact categories that apply to its workloads. CIP-002-5.1a sorts BES Cyber Systems into high, medium and low impact, and the applicable requirements change with that category. A cluster hosting Argo CD's application controller and repo-server that deploys to medium impact systems will carry different expectations from a corporate analytics cluster. Confirm the classification with your compliance lead before you choose a topology, because it determines whether a single control plane is acceptable or whether each impact zone needs its own Argo CD instance, its own repository access and its own RBAC boundary.

Then design the segmentation and evidence together. Argo CD's AppProject boundaries, sync windows and RBAC decide who can change what, and Git history records the change itself, but neither answers the question of how the operational network stays protected. Plan for the Electronic Security Perimeter requirements in CIP-005-7 early, including how Git hosts, container registries and any remote access path reach the cluster. Decide now whether vendor or remote maintenance access will flow through a controlled intermediate system, because that decision shapes the architecture more than any Argo CD setting. Ask your integrator to write these decisions down as part of the scope, so the build can be reviewed against the standards rather than reconstructed afterward.

Which energy requirements change the Argo CD build

This table maps each energy and utility requirement in the supplied research to what it changes in an Argo CD build. Read each row as a question to answer before the cluster layout, Git flow and sync policy are fixed. Requirements that apply depend on your impact categorization and registration, so confirm scope with your compliance lead first.

Requirement	What it asks for	What it means for the Argo CD build
CIP-002-5.1a impact categorization	Sorts BES Cyber Systems into high, medium or low impact using bright-line criteria in Attachment 1 (NERC CIP standards page).	Decide which clusters host BES Cyber Systems before design starts. The impact category sets which Argo CD instances can manage them and how separate they must be.
CIP-005-7 Electronic Security Perimeter	Routable-connected high and medium impact assets sit inside an Electronic Security Perimeter, and Interactive Remote Access passes through an Intermediate System with encryption and multi-factor authentication (NERC CIP-005-7).	Keep the Argo CD control plane and managed clusters inside the perimeter. Do not expose the API server to remote users directly; route any interactive access through the approved Intermediate System.
CIP-010 baseline and change management	Baseline configuration and change control for in-scope cyber assets. CIP-010-4 is listed as mandatory in the United States (NERC CIP standards page).	Git becomes the change record. Protect the main branch, require reviewed pull requests, and use Argo CD sync and sync windows so deployed state matches the approved baseline.
CIP-013-2 vendor and software integrity	Supply chain risk management plans covering vendor incident notification, vulnerability disclosure, software integrity and authenticity verification, and vendor remote access, reviewed at least every 15 calendar months (NERC CIP-013-2).	Pin Argo CD and its images to reviewed versions, record the release source, and document how upgrades are verified. Track the patch releases in the Argo CD release process.
CIP-015-1 internal network monitoring	Internal network security monitoring, approved by FERC on 26 June 2025 and enforceable from 1 October 2028 (NERC CIP standards page).	Plan network telemetry from the Argo CD namespace and controller traffic now so monitoring can be added without redesign. Confirm the applicable date with your Regional Entity.
NIS2 Annex I energy	Energy, covering electricity, district heating and cooling, oil, gas and hydrogen, is a sector of high criticality (Directive (EU) 2022/2555).	Confirm whether your entity is in scope and whether it is essential or important under Article 3. The classification affects supervision intensity, not the technical design.
NIS2 Article 21 risk management	Risk-management measures apply to both essential and important entities, with reporting duties under Article 23 (Directive (EU) 2022/2555).	Map Argo CD controls to your risk register: access through SSO, project boundaries, audit history from Git, and tested recovery of the control plane.
Delegated Regulation (EU) 2024/1366 cross-border electricity	Network code on sector-specific cybersecurity rules for cross-border electricity flows, supplementing Regulation (EU) 2019/943 (EUR-Lex).	If your clusters support cross-border electricity flows, confirm which network code requirements apply to the deployment pipeline and its approvals before the build is fixed.

How CIP impact categories set where Argo CD can run

The CIP-002-5.1a bright-line criteria decide which BES Cyber Systems are high, medium or low impact, and that classification decides where Argo CD may run. Argo CD is not usually a BES Cyber System itself, but the clusters it deploys to host workloads that may be. Before choosing a topology, the CIP lead should map each target cluster to the impact category of the systems it hosts, then check which CIP-005-7 and CIP-007-6 requirements apply to the Argo CD control plane when it manages those clusters. Requirements in CIP-007-6 are scoped by Applicable Systems, so a control plane with credentials into a high or medium impact environment may itself fall into the EACMS or PCA scope. Confirm that classification in writing before the design starts, since it changes the access, logging and change controls that follow.

The central trade-off is between one shared Argo CD control plane and separate instances for each impact boundary. A shared instance is simpler to patch, back up and audit, and Argo CD's projects and RBAC can keep teams apart within it. But every cluster it can reach becomes part of its security perimeter, and a compromise of the controller or its credentials reaches all of them. Separate instances per impact boundary reduce that blast radius and make the ESP boundary easier to describe to an auditor, at the cost of more installations, upgrades and HA setups to run. Whichever model you choose, the cluster registrations, repository credentials and project definitions should match the boundary, not the team structure.

Ask the Compliance Enforcement Authority, or your own CIP lead, three questions before the architecture is fixed: which impact category applies to each cluster and whether any Argo CD component would be an Applicable System; whether an Argo CD instance that deploys into a boundary counts as Interactive Remote Access or vendor-initiated remote access under CIP-005-7 and CIP-013-2; and whether a separate instance per boundary is expected or acceptable. Record the answers as design inputs. Changing them after installation means re-registering clusters and re-validating the ESP, which is far more costly than deciding first.

Argo CD settings and integrations that matter for utilities

Six Argo CD settings carry most of the weight in a utility deployment. Each one answers a question an auditor or a NERC CIP or NIS2 assessor is likely to ask: who can change what, where changes land, how access is authenticated, and how delivery keeps working when a site has no inbound path. Check each setting against the impact classification of the systems it touches before you fix the design.

Projects as impact zone boundaries

Use Argo CD Projects to separate applications by impact zone, such as control center, generation and corporate IT, so each group has its own allowed source repositories, destination clusters and namespaces. This supports the way CIP-005-7 scopes Electronic Security Perimeters and the way CIP-010 baselines are kept per system. Confirm with your compliance lead which systems are high, medium or low impact under CIP-002-5.1a before you draw the project lines, and keep a written map from each project to the systems it can change.

SSO with admin disabled

Connect Argo CD to your identity provider through the bundled Dex or directly over OIDC, then set admin.enabled to false once SSO works. Named identities give the individual accountability that CIP-004 access management and NIS2 Article 21 access control reviews expect. Map groups to roles in one place and test that removing a person from the directory removes their Argo CD access. Keep one break-glass procedure documented and tested outside Argo CD.

Repositories as Kubernetes Secrets

Argo CD 3.0 removed repository definitions from the argocd-cm ConfigMap, so each Git or Helm repository must be declared as a Kubernetes Secret. This matters for CIP-013 software integrity and vendor remote access controls, because the list of trusted sources becomes a set of versioned, access-controlled objects. Restrict who can create repository Secrets, record each approved source in your supply chain risk register, and review the list at the cadence your CIP-013 plan requires.

HA and controller sharding

The HA manifests need at least three nodes because of pod anti-affinity, and the application controller can be sharded across replicas. Availability matters for CIP-009 recovery planning and for NIS2 business continuity expectations, since a stalled controller can stop approved fixes from reaching clusters. Confirm that your node pool spans separate failure domains, that IPv6-only clusters are out of scope, and that Redis is treated as a disposable cache in your recovery runbook.

Repo-server exposure from Helm and Kustomize

The repo-server runs Helm and Kustomize against repository content, so an untrusted chart, or a Kustomize file that reads files outside its directory, can change what gets deployed. Restrict which repositories can be used, disable out-of-tree file access where your version allows it, and keep the repo-server in a network segment that only Argo CD components reach. Document these checks as evidence for the configuration change controls your assessor will sample.

Pull-based agents for closed sites

Where a substation, plant or remote site accepts no inbound connections, an Argo CD agent running inside that cluster can pull desired state outward instead of the control plane pushing into it. This fits the CIP-005-7 requirement that all Interactive Remote Access pass through an Intermediate System, and it limits vendor-initiated access. Ask your team to confirm the agent's current support status, the outbound ports your firewall rules must allow, and how the agent authenticates to the control plane before you plan the topology.

Change windows, sync controls and emergency change

Planned outages on generation, substation or control center systems have an approved start and end, and the change board authorizes the work in advance. Argo CD sync windows can hold automatic syncs outside that approved span, so a manifest merged during a freeze does not reach the cluster until the window opens.

Window definition: Set allow windows on the AppProject for the affected cluster and namespaces, limited to the approved outage span.
Manual sync behavior: Confirm whether manual syncs are blocked or permitted inside a window, and whether that matches your board's rules.
Pending changes: Commits waiting outside the window appear as out-of-sync, so reviewers can see what will apply when the window opens.
Window closure: Remove or expire the window after the outage closes so later changes are not held without a record.

Check the window times against the approved outage ticket and confirm the time zone Argo CD evaluates, since a mismatch between the two is a common cause of unexpected holds.

Rollout phases for a utility Argo CD deployment

This sequence moves a utility Argo CD deployment from scope and impact categorization through controlled promotion and day-two operations, so each phase produces evidence that the next one depends on. It keeps the BES Cyber System boundary, access model and change records defined before any production cluster is touched.

Define scope and impact categorization
The compliance lead, OT engineers and the Argo CD platform owner list every cluster, namespace and workload that Argo CD would touch, then classify the systems that would deploy into or manage BES Cyber Systems under the CIP-002-5.1a bright-line criteria. Anything that cannot be classified stays out of scope until it can. The step closes with a signed scope statement that names each in-scope system, its impact category and the owner responsible for it.
Design the network and perimeter
The network architect maps where Argo CD's controller, repo-server, API server and Redis would run relative to the Electronic Security Perimeter for any high or medium impact systems in scope, and decides which destinations each cluster may reach. Where a cluster accepts no inbound connections, the design favors a pull-based agent that initiates outbound traffic to the control plane. The step closes with an approved flow diagram and firewall rule set that the security team has reviewed against the perimeter and remote access requirements.
Configure identity and RBAC
The identity team connects Argo CD to the organization's identity provider, either through the bundled Dex or directly over OIDC, then maps groups to Argo CD projects and roles so that each person and automation account has only the permissions its work requires. The built-in admin account is used only for initial setup and disabled once SSO and local users work. The step closes with a tested role matrix and a record showing that the admin account is disabled and that interactive access is routed through the approved identity path.
Run a pilot outside BES environments
The platform team deploys Argo CD and a small set of non-BES applications to a development or test cluster, using the same manifests, projects and sync settings planned for production. The pilot checks sync behavior, rollback, repository access, secret handling and alert routing, and it tests how a change request links to a Git commit and a sync record. The step closes with a written pilot report listing defects found, changes made to the configuration and any control gaps that must be resolved before promotion.
Promote changes with evidence capture
The change manager and operators promote the approved configuration into the in-scope environment through the Git-based change flow, with each promotion tied to an approved change record, a reviewed pull request and a sync that the team can trace back to a commit. Sync windows and project restrictions limit when and where changes can land. The step closes with an evidence pack for each change that includes the commit, approver, sync result and any exceptions, stored where the compliance team can retrieve it for a later review.
Operate, back up and upgrade on cadence
The platform and security teams run Argo CD day to day, monitor access and sync activity, test backups and restores, and review the role matrix on a regular basis. They also track the Argo CD release process, which ships a minor release every three months and patch releases only for the three most recent minor versions, and they schedule upgrades in a test environment first. The step closes with a documented upgrade calendar, a tested recovery procedure and an updated configuration baseline after each change, so the deployment stays on a supported version.

What auditors will ask to see from the Argo CD layer

Auditors reviewing an energy or utility environment will trace changes from the operational network back to an approved record, and they will test who could make those changes. The six areas below are the Argo CD evidence we would prepare for each, mapped to the CIP and NIS2 obligations they support. Compliance is judged by the regulator or auditor, not by the tooling, so each area is a set of records to assemble and test.

Baseline and change records from Git

Every change to a cluster that Argo CD applies should trace to a reviewed commit, a merge approval and a sync event. For CIP-010 baseline and change management, ask the auditor which configuration items must be tracked and confirm that Git history, pull request approvals and Argo CD sync history cover them. Check that protected branches block direct pushes to the production path. The Git history is the baseline record only if no change reaches the cluster outside it.

Vendor software integrity for CIP-013

CIP-013-2 requires supply chain risk management plans that cover software integrity and authenticity verification and vendor-initiated remote access. For Argo CD, this means documenting where each Helm chart, manifest and container image comes from, how its version is pinned, and who approved it. Record the Argo CD release you run and the patch policy that follows the project's support window. Confirm with your vendors which signatures or digests they publish.

Remote access through the intermediate system

CIP-005-7 requires all interactive remote access to pass through an Intermediate System with encryption and multi-factor authentication. Argo CD's web UI and API should not be reachable from outside the Electronic Security Perimeter, and vendor access should not reach the controller directly. Evidence includes network diagrams showing the access path, firewall rules, and TLS settings on every Argo CD endpoint. Ask your Compliance Enforcement Authority which access paths they expect to see documented.

Access reviews from SSO groups

Auditors will ask who can sync, delete or change projects, and whether those rights were reviewed. Map each Argo CD role to an identity provider group, so access reviews happen in the identity system where your personnel records already live. Confirm that the built-in admin account is disabled once SSO is configured, and that logs access is granted only where needed. Retain review sign-offs with dates, because the review record is what the auditor tests.

Monitoring the Argo CD plane for CIP-015

CIP-015-1 covers internal network security monitoring and is enforceable from a date that the NERC standards page lists as 1 October 2028. Plan now for logs from the Argo CD API server, application controller and repo-server to reach your monitoring platform. Confirm with your Regional Entity whether the Argo CD cluster falls within the monitored scope based on its impact classification. Retain sync, login and permission-change events for the review period your program sets.

NIS2 Article 21 risk controls

For entities in the energy sector, NIS2 Article 21 requires risk-management measures, and Implementing Regulation (EU) 2024/2690 sets technical requirements for some digital service types. For Argo CD, document the risk analysis, the access model, backup and recovery tests, and vulnerability handling for the controller. Ask your national competent authority which evidence formats it accepts. The controls must be shown to operate, so keep dated test results, not only design documents.

Questions utilities ask before hiring a partner for Argo CD

What drives the cost of an Argo CD engagement for a utility?

The cost follows the written scope, and the main drivers are the number of clusters, the number of impact zones that each need their own delivery path, how many segmented networks must be reached, and how much evidence the change board expects. A partner is paid for design, build, hardening, documentation and handover, while your staff carry the change approvals and the operational knowledge. Ask for a quote that separates one-time work (architecture, installation, SSO, backup design, runbooks) from recurring work (upgrades, patch tracking, support retainers). DeployOpen does not publish a price list, and a quote follows from the written scope.

How long does a scoped Argo CD build take with several impact zones?

Duration depends mostly on the number of impact zones and the network paths between them, because each zone needs its own control path, access model and evidence set. Fewer zones with a single approved Git flow move faster than several zones that each need separate projects, sync windows and firewall changes. Your change board's review cycle often sets the critical path, so plan approval dates alongside technical work. No fixed duration applies to every utility, and the written scope and timeline are agreed before work starts.

What must our utility supply before an Argo CD project starts?

Prepare three inputs before kickoff: network diagrams that show the segmented operational zones and every permitted path between them, an inventory of the BES Cyber Systems and associated assets in scope with their impact classification, and written change board rules covering approvals, emergency changes and change windows. Also provide Git hosting details, identity provider access, and the names of the people who approve production changes. Missing inputs are the most common reason a schedule slips, so confirm each one against your own environment before signing the scope.

Can our internal staff run Argo CD after the project ends?

Yes, if the handover plan includes it. Argo CD keeps its state in Kubernetes objects and treats Redis as a disposable cache, which makes day-two work largely routine: reviewing sync status, rotating credentials, applying patch releases and restoring from backup. The project publishes a release cadence in which only the three most recent minor versions receive patch releases, so someone internally must own patch tracking. Ask the partner for runbooks, a recorded walkthrough, and a named internal owner for each role before the engagement closes.

How do NIS2 and NERC CIP obligations overlap for an Argo CD platform?

Both regimes ask for risk management, supply chain control and incident handling, but they apply to different entities and enforce differently. NERC CIP is mandatory in the United States once FERC approves a standard, and it is enforced through audits and spot checks. NIS2 is a directive, so its obligations reach you through national transposition laws, and it creates no certificate of compliance. Map each Argo CD control, such as Git-based change flow, RBAC and sync windows, to the specific requirement in each regime, and confirm with your regulator and counsel which obligations apply to your entity.

How do we keep Argo CD upgrades within the supported minor versions?

The Argo CD release process ships a minor release four times a year, roughly once every three months, and only the three most recent minor versions receive patch releases. Upgrades should therefore be scheduled as a recurring process, not an occasional project, so that each cluster stays on a supported minor version. Test each upgrade in a non-production zone first, read the official upgrade notes for breaking changes such as the 2.14 to 3.0 RBAC and repository changes, and plan the production window with your change board. Confirm the current supported versions on the project's releases page before scheduling.

Does the engagement make us compliant with NERC CIP or NIS2?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. For NERC CIP, the Compliance Enforcement Authority monitors compliance through audits, spot checks and self-certifications, and there is no CIP certificate. For NIS2, national competent authorities oversee compliance through inspections and audits. Your engagement should produce configuration records and evidence that your compliance team and independent assessors can test.

What to ask a partner before a utility Argo CD scope is signed

Start with segmentation experience. Ask any implementer to describe a previous deployment where the GitOps control plane sat outside, or next to, an operational network, and how they kept it from becoming a path into one. A credible answer names the boundary decisions: which clusters register with which Argo CD instance, where the repo-server and Redis run, and how the Argo CD namespace is kept separate from the systems it deploys to. Ask who draws the Electronic Security Perimeter diagram, and whether they will review it against the requirements in CIP-005-7 before any cluster is connected. A partner that answers only with generic Kubernetes hardening has not thought about your asset boundaries.

Ask how change records become evidence without the partner claiming a compliance outcome. The right answer separates what Argo CD produces (Git history, pull request approvals, sync history and RBAC configuration) from what the utility must still own: the CIP-010 baseline, the review cadence and the auditor-facing narrative. Ask them to show a sample evidence pack and to explain which fields come from Git and which from the cluster. Because no CIP certificate exists and compliance is monitored by the Compliance Enforcement Authority, any partner who offers a certificate or an audit pass should be treated as a warning sign. Ask them to name the CIP requirements their evidence supports and the ones it does not.

Ask how agents stay outbound-only and who controls the credentials. For clusters that accept no inbound connections, confirm whether the design uses the agent-based pull model and what the agent can reach, and whether the Git and registry endpoints are allowed through the boundary. Ask who rotates the agent credentials, how a revoked credential is handled and which change window the partner needs to make firewall or proxy changes. Finally, ask about upgrades: who applies the patch releases that the project supports for only its three most recent minor versions, who tests them in a non-production cluster, and how long your team has to accept a release before it falls out of support. Get those answers in the written scope, not in a call summary.

How DeployOpen scopes and supports utility Argo CD work

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including segmented operational networks. For energy and utility teams, we start from the change control and network boundaries that apply to each environment, then build Argo CD around them so the written scope, the evidence and the handover match what your compliance and operations teams need.

How we scope

Written scope lists which environments, clusters and networks Argo CD will manage, and which are excluded.
Scope records how each cluster's impact classification and network zone shape the Argo CD placement.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

Build covers SSO, Argo CD projects, RBAC and sync windows aligned to your approved change windows.
Repository credentials, Git access and pull-based agents are configured for clusters that accept no inbound connections.
Configuration is tested in a non-production environment before any change reaches operational systems.

How we hand over

Handover documents the Git change flow, RBAC model, sync policy and admin account disablement steps.
Runbooks cover high availability settings, backup and recovery, and upgrade steps for Argo CD minor releases.
Evidence packs describe the controls and records that your team can present to internal and external auditors.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainer scope should be agreed in writing, including how patch releases for supported minor versions are applied.
Confirm with DeployOpen which support hours, escalation paths and change windows apply to your environment.