Why Apache APISIX fits energy and utilities API traffic
Grid operators and utilities often need meter data, market partner exchanges and internal services to reach a small set of controlled entry points, while operational technology stays on networks that no external caller can touch. A self-hosted Apache APISIX gateway in the operator's own data centers or cloud accounts can serve as that single controlled entry point, with routes, authentication and logging all owned by the utility. Because APISIX is released under the Apache License 2.0 (Apache-2.0), the license terms are clear for procurement, and the gateway itself stays inside the infrastructure the operator already governs.
For the platform team, the change is concrete. Each partner or internal API becomes a route with a named upstream, and each caller becomes a consumer with its own credential. Authentication can be handled by the openid-connect plugin, which works with identity providers such as Keycloak, Microsoft Entra ID and Okta, or by key-auth and jwt-auth for machine clients. Confirm with your security team which identity provider and flows your market partners already support before you design consumers. Also decide where the gateway sits relative to the control network: the gateway should face the business and partner side, and it should not be placed on a path that reaches control system networks directly.
APISIX supports traditional, decoupled and standalone deployment modes. Traditional mode keeps the data and control planes together, decoupled mode separates them over a shared etcd cluster, and standalone mode reads configuration from a file or the Admin API with no etcd at all. Standalone mode can suit a gateway in a segment where operators want fewer moving parts and no shared datastore, but it changes how configuration is versioned and reviewed. The Ingress Controller is a separate project for Kubernetes clusters, so confirm which mode and which controller fit each zone before the first build.
Which energy regulations shape the gateway build
This table maps the energy regulations most likely to touch an APISIX gateway to the build decisions they influence. Read each row as a question to settle with your compliance team before design starts, since the gateway supports evidence but does not make an entity compliant. The main takeaway is that most obligations apply to the operating environment around the gateway, so the gateway design has to fit into it.
| Requirement | What it asks for | What it means for the gateway build |
|---|---|---|
| NERC CIP-002 impact classification | Sorts BES Cyber Systems into high, medium or low impact using bright-line criteria (NERC CIP standards) | Confirm the impact rating of systems behind the gateway first, because it sets which CIP-005 and CIP-013 controls apply to each route |
| CIP-005-7 Electronic Security Perimeter | Places routable-connected high and medium impact assets inside an ESP and routes Interactive Remote Access through an Intermediate System with encryption and MFA (NERC CIP-005-7) | Keep the gateway on the correct side of the perimeter, enforce MFA at the gateway for remote access paths, and document each route crossing the boundary |
| CIP-013-2 vendor supply chain | Requires supply chain risk management plans covering vendor incident notification, vulnerability disclosure, software integrity verification and vendor remote access, reviewed at least every 15 calendar months (NERC CIP-013-2) | Record APISIX and plugin versions, verify release integrity during installation, and capture the process for vendor-initiated access through the gateway |
| CIP-015-1 internal network security monitoring | Approved by FERC on 26 June 2025 and enforceable from 1 October 2028 (NERC CIP standards page) | Plan gateway access logs and telemetry so they can feed internal network monitoring later, and confirm the final requirements with your Regional Entity |
| NIS2 Annex I energy and Article 21 risk management | Lists electricity, district heating and cooling, oil, gas and hydrogen as high-criticality subsectors, with risk management measures under Article 21 (Directive (EU) 2022/2555) | Map gateway controls such as authentication, rate limits, TLS and logging to the Article 21 measures your national law applies to your entity |
| Commission Delegated Regulation (EU) 2024/1366 | Sets a network code on sector-specific cybersecurity rules for cross-border electricity flows, supplementing Regulation (EU) 2019/943 (EUR-Lex) | For market and cross-border APIs, confirm which cybersecurity rules apply to each partner interface before defining routes and partner authentication |
| Evidence for NIS2 and CIP audits | NIS2 has no certificate of compliance, and CIP entities face compliance audits by NERC and Regional Entities (NERC Rules of Procedure) | Keep gateway configuration in version control and retain access logs, so your auditors can trace configuration and access. DeployOpen prepares evidence, but audit outcomes come from the authorities. |
Where the gateway sits relative to BES Cyber Systems
The impact rating of each BES Cyber System decides where the gateway may sit. Under CIP-002-5.1a, operators sort BES Cyber Systems into high, medium and low impact using bright-line criteria, and high impact mainly covers qualifying control centers. Medium impact includes, for example, generation of 1500 MW or more at one plant or transmission facilities at 500 kV or higher. Before any APISIX route is designed, ask the operator's compliance team for the current impact list for each site and each control center, because the gateway's placement follows from those ratings, not from the team's own view of which systems look critical. Also confirm which assets are not in scope at all, since a meter or market system can be outside the BES Cyber System inventory and still need protection.
CIP-005-7 is the constraint that matters most for placement. Routable-connected assets of high and medium impact BES Cyber Systems must sit inside an Electronic Security Perimeter, and all Interactive Remote Access must pass through an Intermediate System with encryption and multi-factor authentication. In practice, an APISIX instance should not be deployed inside the perimeter to serve external partners, and no route should send a partner request directly to a control system. Market and meter APIs should terminate in a DMZ-style tier outside the perimeter, with APISIX there handling TLS, authentication and rate limits, and any data needed inside the perimeter passing through a controlled, one-way or tightly scoped path that the operator has approved. Confirm with the operator's CIP owners whether the APISIX deployment, its etcd cluster and its Admin API are themselves in scope, because a gateway that reaches into OT can change the perimeter.
Routes, authentication and plugins that matter for utilities
Utility gateways usually combine workforce sign-in, machine clients from meter and market systems, and legacy interfaces that do not speak modern HTTP. The cards below cover the APISIX plugins and settings we expect to see most often in that mix, along with what to confirm before you commit to a design.
OpenID Connect for workforce and partners
The openid-connect plugin handles browser and application sign-in for staff, contractors and partner users against an identity provider such as Microsoft Entra ID, Keycloak or Okta. Authorization code flow with PKCE suits people, while client credentials and token introspection suit services. Check which flows your identity provider supports, how group claims map to routes, and where session and token lifetimes are set for operator-facing tools.
jwt-auth and key-auth for machine clients
Market partners, meter head-end systems and reporting services typically authenticate as machines rather than people. jwt-auth validates signed tokens issued by a trusted authority, and key-auth checks API keys attached to a consumer. Decide which clients get short-lived tokens and which receive long-lived keys, and confirm how keys are rotated and revoked without changing route definitions.
Client certificate controls to confirm
Client certificate checks at the gateway are a common way to bind a machine client to a known identity, which matters for remote access paths that NERC CIP-005-7 scrutinizes. Confirm in the current plugin documentation exactly how client certificate validation is configured on routes, how certificates are chained to a trusted authority and how revocation is handled. Do not assume a plugin covers mutual TLS for every route type without testing it.
ldap-auth for legacy directories
Some operations teams still authenticate against an LDAP directory that predates the identity provider. ldap-auth lets the gateway check credentials against that directory for legacy tools that cannot yet use OpenID Connect. Plan for this as a transition path: confirm service account handling, how bind failures are logged, and when the directory's group membership will move to the central identity provider.
forward-auth to external policy services
The forward-auth plugin sends each request to an external authorization service before it reaches the upstream, which lets a utility keep access decisions in a policy engine it already governs. Check the added latency on high-frequency meter reads, what happens to traffic if the policy service is unreachable, and whether the decision service logs enough detail for audit.
Rate and request limits for meter data bursts
Meter data often arrives in scheduled bursts, and a misbehaving head-end can flood an interval read endpoint. Traffic control plugins let you set per-consumer or per-route limits so a single partner cannot starve other clients. Size limits from measured interval volumes in your own environment and test recovery after a backlog clears.
Protocol proxying for legacy utility interfaces
APISIX proxies HTTP, HTTPS, gRPC, WebSocket and TCP/UDP, so legacy utility interfaces can sit behind one gateway without a rewrite. Each protocol needs its own route type, TLS settings and health checks. Confirm which of your legacy protocols need stream routes, and keep those routes on segments that CIP-005-7 boundaries already cover.
Traditional, decoupled or standalone for regional utility estates
Traditional mode runs the data plane and control plane together on each APISIX node, and every node talks to its own etcd cluster. Client traffic arrives on port 9080 and the Admin API listens on port 9180. For a utility, this keeps the design simple for a single control center or a single regional gateway where one team owns the whole stack.
- Single operational unit: Each node holds routes, plugins and credentials locally, so there is one place to troubleshoot a request path.
- Admin API exposure: Port 9180 must be restricted to management networks, because whoever reaches it can change routes and plugins.
- etcd coupling: Every gateway site depends on its etcd cluster for configuration writes, so etcd sizing and backups sit inside the gateway team's responsibility.
- Cross-site consistency: Running separate traditional deployments per region means configuration drift must be controlled through your own pipeline.
- Change control: Route and plugin changes are made through the Admin API, so changes need approval workflows and version-controlled source.
Before choosing this mode, confirm which team will operate etcd, how the Admin API is reachable from each zone, and how a failed site is isolated without affecting other regions.
Decoupled mode separates the data plane from the control plane. Several data plane nodes, often placed in different regional DMZs, read configuration from one shared etcd cluster that the control plane manages. This suits a utility that wants one place to publish routes and policy for many gateway nodes across regions.
- Central policy point: Operators publish a route or plugin change once, and every connected data plane picks it up.
- Shared etcd dependency: The etcd cluster becomes a shared failure domain, so its placement, quorum layout and backup tests need explicit design.
- Network paths: Data plane nodes need a reliable, authorized path to etcd, which may cross zone boundaries that your security perimeter rules govern.
- Blast radius: A bad change published to the shared store reaches all data planes, so staged rollouts by zone matter.
- Operations load: Upgrades must keep control and data planes compatible, which adds a planning step to each release.
Before choosing this mode, confirm the etcd placement and quorum design, which zones may reach etcd, and whether a regional outage can keep existing data planes serving traffic while configuration changes are paused.
Standalone mode runs APISIX without etcd. Configuration comes from a YAML or JSON file, such as conf/apisix.yaml or conf/apisix.json, or from the API. APISIX checks the file every second and hot-reloads changes without a restart. This fits restricted networks and isolated DMZ segments where a database-backed control path is hard to justify.
- No etcd to run: The gateway has fewer moving parts, which reduces the operations surface inside a restricted zone.
- Configuration as code: The file can be generated by a pipeline, reviewed in Git and promoted between environments, which supports change evidence.
- Per-node files: Each node needs its copy of the file, so distribution and consistency checks must be automated.
- Hot reload risk: A malformed file can change live behavior within a second, so validation before deployment is mandatory.
- Limited dynamic control: Real-time changes depend on how the file or API is updated, so emergency changes need a tested runbook.
Before choosing this mode, confirm how files reach each node, how they are validated and signed, and who is authorized to change the file on a live gateway.
How a utility gateway rollout is phased
The sequence moves from classifying which systems and APIs are in scope to proving that the gateway keeps working when a region fails. Each phase closes with a written output that the utility can review before the next phase starts.
Scope and classify impact with compliance
DeployOpen works with your compliance and OT security leads to list the APIs, data flows and gateway functions in scope, and to map which assets could fall under the CIP-002 impact categories and which NIS2 obligations apply to your entity. You provide the asset inventory, the existing interface list with market and meter partners, and your compliance registration details. The step is done when a scope document records each in-scope API, its impact classification or assumption, and the open questions that your compliance team has accepted or assigned an owner for.
Design network and perimeter boundaries
The team designs where APISIX runs, which network zones it sits in, and which flows cross the boundary between corporate IT, partner networks and any control system segment. The design is checked against the perimeter requirements of CIP-005-7, including how routable connections to in-scope assets are handled and how remote access reaches the Intermediate System. You provide firewall and zoning standards, data center and cloud account details, and the architecture owner who signs off. The step closes with a reviewed network diagram and a rule-by-rule list of permitted flows.
Integrate identity and machine client access
Human and machine access to the gateway and to the APIs behind it is connected to your identity provider, using the openid-connect and other authentication plugins suited to each client type. Partner systems and meter data clients receive their own consumer identities, and administrative access to the Admin API is restricted to named roles. You provide the identity provider configuration, the list of client types and their credential methods, and the approval path for new partner accounts. The step is complete when test users and test machine clients authenticate, are denied when they lack the right role, and each decision appears in the access log.
Migrate meter and market routes with parallel running
Existing routes for meter data and market partner APIs are recreated in APISIX and run alongside the current gateway, with traffic split so that partners can be moved in controlled groups. Response content, latency and error rates are compared between the two paths before any partner is switched over. You provide the route inventory, partner contact list, acceptance criteria and the change window rules agreed with each partner. The step is done when every migrated route has a documented comparison result and a tested rollback that returns the partner to the previous gateway.
Configure cryptography and logging
TLS settings, certificate lifecycles, encryption of stored secrets and the mutual TLS setup for named partners are configured and tested against your approved cryptographic policy. Access logs and gateway audit events are routed to your monitoring platform with retention and protection that match your information protection rules, and payload content is kept out of logs where it is not needed. You provide the cryptographic standards, certificate authority details and the log retention and access requirements. The step closes with a test report showing accepted protocol versions, certificate chain validation results and a sample of audit events received by the central log store.
Test regional failover
The gateway is deployed across the regions you choose, and the team runs failover tests that remove one region from service and confirm that traffic, authentication and configuration synchronization continue as designed. Results are recorded against the recovery targets your operations team sets, and any gap is fixed and retested. You provide the target recovery objectives, access to the secondary region, and staff for the scheduled test windows. The step is done when a signed test record shows each failure scenario, the observed behavior and the retest results.
Hand over with runbooks
DeployOpen delivers runbooks for routine operations, certificate renewal, configuration changes, incident response, upgrades and rollback, along with the architecture records and evidence gathered in earlier phases. Your operators run a supervised session in which they perform the common tasks themselves. You provide named operators, the escalation contacts and the change process your organization follows. The step is complete when your team has executed the runbook tasks in the session, and the open items list is assigned to named owners.
What NERC CIP and NIS2 evidence the gateway can support
Does NERC CIP issue a certificate for an APISIX gateway?
No. There is no CIP certificate. Entities registered as a Balancing Authority, Reliability Coordinator or Transmission Operator receive a compliance audit at least once every three years, and the Regional Entity or NERC performs it. DeployOpen configures the gateway, documents its controls and assembles the evidence your team will present, but the audit outcome is decided by the auditors. Confirm with your Regional Entity which records they expect for any gateway that sits in scope.
How does CIP-005-7 apply to an APISIX gateway?
CIP-005-7 requires routable-connected assets of high and medium impact BES Cyber Systems to sit inside an Electronic Security Perimeter, and all Interactive Remote Access to pass through an Intermediate System with encryption and multi-factor authentication. APISIX can be part of that design as a controlled entry point, with:
- Route definitions and access rules kept in version-controlled configuration
- TLS on client connections and multi-factor authentication enforced by the identity provider behind the openid-connect plugin
- Access logs and admin change records retained for review
The perimeter and Intermediate System design are your architecture decisions. DeployOpen documents how the gateway meets them and what evidence it produces. Your auditor decides whether the design satisfies the standard.
How does CIP-013-2 relate to gateway software and vendor access?
CIP-013-2 requires supply chain risk management plans that cover 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. For an APISIX gateway, the evidence usually includes the source of each release, how you verify artifacts before deployment, how upgrades are approved, and how any DeployOpen or vendor remote session is authorized and logged. DeployOpen can prepare these records and the review procedure. Your organization owns the plan, the vendor agreements and the review cycle.
What do NIS2 Articles 21 and 23 expect from a gateway operator?
Article 21 requires risk-management measures, and Article 23 requires incident reporting to the competent authority within set deadlines. Essential and important entities face the same obligations under both articles. For a gateway, the relevant evidence covers access control, encryption in transit, logging, vulnerability handling, backup and recovery, and a tested process for detecting and reporting incidents that affect the gateway. DeployOpen can design those controls, configure the gateway and prepare the records. Your national transposition law and competent authority set the exact deadlines and what must be reported.
Does NIS2 issue a certificate of compliance?
No. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. Essential entities face ex ante supervision and important entities face ex post supervision. DeployOpen can prepare the controls, configuration baselines and evidence packs that support an inspection. Your national authority decides whether your organization meets the obligations, and it determines what it requests and how it reviews the evidence.
How can ENISA's June 2025 guidance help map gateway evidence?
ENISA published non-binding technical implementation guidance for Implementing Regulation (EU) 2024/2690 on 26 June 2025. It gives examples of evidence and mappings to ISO/IEC 27001:2022 and NIST CSF 2.0, among other frameworks. Use it as a checklist to decide which records to keep for each control, such as configuration exports, access reviews, TLS settings and incident logs. Note that the regulation applies to specific service types, so confirm with your competent authority whether and how it applies to your energy operations. DeployOpen uses the guidance to structure the evidence it prepares.
Is the 2026 NIS2 amendment proposal already in force?
No. On 20 January 2026 the Commission proposed targeted amendments to NIS2 (COM(2026) 13), including a new small mid-cap category. The proposal still needs approval by the European Parliament and the Council, and Commission pages updated through July 2026 describe it as a proposal. Plan around the current text and your national transposition law, and review your scope again once the amendments are adopted. DeployOpen can review how any changes would affect your gateway evidence, but your legal team decides which obligations apply to your organization.
What should a utility ask for before scoping gateway compliance work?
Ask for the scope in writing before any build starts. A useful scope states which BES Cyber Systems or NIS2 services the gateway touches, which impact categories apply, which CIP and NIS2 controls the work addresses, and which evidence records the client will own. Ask who performs the compliance audit or inspection, which records the auditor will request, and how changes to the gateway are approved and logged. Cost depends on the number of routes, identity integrations, environments and evidence formats, so ask for a fixed-scope quote that lists each of these items.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including Apache APISIX for energy and utilities. Engagements start from a written, fixed scope, and the gateway runs in utility-controlled cloud accounts, data centers or restricted networks.
How we scope
- Inventory which APIs, meter data feeds and market partner endpoints the gateway will front, and their data classification.
- Confirm which networks sit inside the Electronic Security Perimeter and which APIs must stay outside control system zones.
- Agree in writing the deployment mode, etcd layout across regions, identity provider and the evidence your compliance team needs.
How we build
- Deploy APISIX in your environment with routes, consumer design and authentication for partner and internal API clients.
- Configure TLS, mTLS for machine clients, rate limits per partner and logging that keeps personal and customer data out of gateway logs.
- Test failover between regions, Admin API restrictions and header trust settings, then record the results against the agreed scope.
How we hand over
- Deliver configuration as code, runbooks for route changes, certificate rotation and etcd recovery, and an architecture record.
- Provide a control mapping that shows how each gateway setting supports your NIS2 or CIP obligations, prepared for your own assessors.
- Run knowledge transfer sessions with your platform, security and operations staff before the written handover closes.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, with scope agreed in writing.
- Plan APISIX version upgrades and Ingress Controller updates in advance, confirmed against the project's release notes for your version.
- Review gateway configuration and logs on a schedule you choose, and reassess scope when NERC or NIS2 requirements change.
