CIP in a Virtual World: Categorizing the Lab under FERC Order 919

There’s something I’ve quietly leaned on for six posts: none of this lab is real. Not in the sense that it doesn’t work, because it does, but in the sense that there’s no rack of equipment anywhere. The grid, the substation controller, the firewall, the jump host, the sensor: every one of them is a virtual machine, a computer simulated in software, and they’re all running on a single physical Linux box under my desk. The software that creates and runs those virtual machines is called a hypervisor; mine is KVM, managed by a component called libvirt.

That’s a completely ordinary way to build things in 2026, and it creates a problem the regulations were never written for. NERC CIP was written for a world of physical boxes you could walk up to and touch. Ask it about a hypervisor and it mostly has no answer: you categorize the virtual machines, and the physical host they all live on gets treated as furniture.

That’s backwards, though. The host is the most dangerous computer in the building. Anyone who controls it controls every machine inside it, silently, without ever touching the network the regulations spend so much effort protecting.

FERC Order 919 is the regulators catching up to that. For the finale I categorize the lab twice, once under today’s rules and once under the new ones, and show which risk falls through the gap between them.

Where this fits. Post 7, the finale. It reframes everything from posts 1–6 through the lens of where the standards are actually heading.

What is FERC Order 919?

First, who’s who. FERC is the Federal Energy Regulatory Commission, the US government agency that approves the grid’s reliability standards. NERC writes them, and FERC gives them the force of law. An Order is how FERC directs that a standard be changed.

FERC Order 919 (approved March 19, 2026, effective May 26, 2026) directs revised CIP standards that finally account for virtualization, with a mandatory compliance date of July 1, 2028. The headline is a set of new definitions that change what you’re even categorizing:

• Cyber System — a grouping of cyber assets, moving the model away from counting individual boxes.
• Virtual Cyber Asset (VCA) — a virtual machine performing a BES function. My OT VMs.
• Shared Cyber Infrastructure (SCI) — hardware that hosts multiple cyber systems, potentially of different impact levels. My KVM host.
• Management Interface — the control plane of that infrastructure: the interface through which the virtual machines are created, started, stopped, copied, and reconfigured. If the virtual machines are the tenants, this is the landlord’s master key. On this lab it’s libvirtd and everything that talks to it: the virsh command line, the virt-manager console, the libvirt socket.

Here’s why this matters. Under the old model, a hypervisor is invisible and you just categorize the guests. Under Order 919, the host itself and its management plane become first-class things with their own controls. For a lab that’s 100% virtualized, that’s not a footnote, it’s the whole picture.

Here’s the concrete version, in case that’s too abstract. An attacker with the hypervisor’s master key doesn’t need to send a DNP3 command, get past the firewall from post 4, or evade the sensor from post 5. They can copy the entire substation controller’s memory to disk and read it at their leisure, or attach a new network cable (a virtual one, in software, instantly) that quietly bridges the protected zone to the internet. Every control in this series lives inside the virtual machines. The master key is outside all of them.

Categorization #1 — under today’s asset model

First, the assessment the way I’ve been running it (CIP-002). I apply the impact rating, justify Medium + External Routable Connectivity, and inventory the BES Cyber Assets and their groupings. Under this model the KVM host is basically just plumbing: I categorize the guest VMs, and the hypervisor barely shows up.

flowchart TB
    subgraph today["Today's model — categorize the guests"]
        plc["OpenPLC VM<br/>= BES Cyber Asset"]
        pp["pandapower VM<br/>= BES Cyber Asset"]
        scada["SCADA/HMI VM<br/>= BES Cyber Asset"]
        fw["Firewall VM<br/>= EACMS (EAP)"]
        sensor["Zeek/Suricata VM<br/>= EACMS"]
        host["KVM/libvirt host<br/>(mostly invisible — 'just infrastructure')"]
    end

Asset	Today’s classification	Rationale
OpenPLC / pandapower / SCADA VMs	BES Cyber Assets (Medium + ERC)	Perform the BES function
Firewall VM	EACMS (Electronic Access Control)	Enforces the EAP/ESP
Zeek/Suricata sensor	EACMS	Monitors inside the ESP
KVM/libvirt host	Not distinctly categorized	Hypervisor treated as plumbing

The gap jumps out immediately: the single most powerful component, the host that can read, clone, or snapshot every BES VM, has no real home in the classification. That’s exactly the gap Order 919 closes.

Categorization #2 — under FERC Order 919

Now the same lab, re-categorized under the new definitions.

flowchart TB
    subgraph o919["FERC Order 919 — categorize the infrastructure too"]
        vca["OT VMs<br/>= Virtual Cyber Assets"]
        sci["KVM/libvirt host<br/>= Shared Cyber Infrastructure"]
        mi["libvirtd API / virt-manager<br/>= Management Interface"]
        vca --- sci
        mi --- sci
    end

Component	Order 919 classification	New obligation it triggers
OT VMs (OpenPLC, pandapower, SCADA)	Virtual Cyber Assets	Same BES-function protections, now as VCAs
KVM/libvirt host	Shared Cyber Infrastructure	Protect the host as a system that could span impact levels
libvirtd API / virt-manager	Management Interface	Dedicated access control, monitoring, and isolation of the control plane

The shift is a real change, not just relabeling. Under Order 919 I have to defend the Management Interface as a first-class attack surface, because anyone who can talk to libvirtd can dump the memory of every BES VM, snapshot the OT zone, or attach a new interface that quietly bridges straight across the ESP. That’s game over for every VCA on the host, no matter how well I drew the perimeter in post 4. The hypervisor’s control plane becomes its own ESP-like boundary.

This is where KVM actually makes the point clearer than a web-UI hypervisor would. There’s no console to point at; the Management Interface is a Unix socket and an SSH path to it, which forces the question “who is in the libvirt group, and why?” That’s exactly the CIP-004 access-management question, and on this host it has a concrete, greppable answer:

Three commands describe the entire control plane: the socket is root:libvirt (mode 0770), the libvirt group has exactly one member, and that one account’s virsh drives every VM in the lab.

No TCP listener, no web console: the whole control plane is that one root:libvirt socket plus SSH to the host. Three commands answer, at the file-permission level, who can clone, snapshot, or dump the memory of every BES VM: exactly the accounts in that group. Under today’s model that fact is nobody’s line item. Under Order 919 it is the Management Interface, a CIP-004 access list and a CIP-007 monitored surface, and the honest finding is that right now it’s guarded by Unix group membership and nothing else: no MFA, no separate logging, no isolation from the management zone.

Why this reframes the whole series

Walk it back through the six posts:

• Post 4’s ESP protects traffic between VMs, but says nothing about someone with hypervisor access snapshotting the OT VM’s memory. Order 919’s SCI/Management Interface controls are what cover that.
• Post 5’s INSM watches the virtual network, but a Management Interface compromise could disable the sensor VM or mirror the traffic somewhere else. Order 919 makes protecting that control plane explicit.
• Post 6’s CIP-010 baselines covered the guests. Under Order 919 the host needs a baseline too, because SCI is now in scope.

In other words, everything I built is still correct, but Order 919 exposes a whole layer the old model let me ignore: the one my entire lab is standing on.

The assessment: current state → finding → risk → remediation

Control	Current state	Finding	Risk	Remediation
CIP-002 categorization	Guests categorized; host is plumbing	Host/control plane uncategorized	A hypervisor compromise bypasses every guest control	Categorize the KVM host as SCI, libvirtd as Management Interface
Management Interface	libvirtd socket reachable from the mgmt zone	Not treated as a distinct boundary	libvirt access = full control of all VCAs	Isolate + MFA + monitor the Management Interface; audit the libvirt group
SCI protection	Standard host hardening	No SCI-specific baseline (CIP-010)	Host drift invisible to the program	Extend baseline automation to the host

Pros and cons of getting ahead of Order 919

Pros	Cons
Categorizing under the future model now = no scramble before July 2028	The revised standards’ details are still settling
Surfaces the hypervisor risk today’s model hides	Dual categorization is more work than one pass
A worked example that’s hard to find elsewhere	Effective 2028 — some treat it as not-yet-urgent

Series wrap-up

Seven posts ago I built a fake power grid so the rules that protect the real one would stop being abstract. Here’s the arc, end to end:

1. The scenario — a virtualized Medium-impact BES Cyber System, framed honestly as a mock audit.
2. The physics — a live pandapower grid with a closed control loop.
3. The protocols — DNP3 on the wire, where a breaker command is a breaker command.
4. The perimeter — an ESP and a jump host under CIP-005, closing the outside path.
5. The inside — CIP-015 INSM catching the rogue command the perimeter can’t see.
6. The automation — CIP-010 baselines and evidence as code.
7. The future — the whole thing re-categorized under FERC Order 919.

I set out to get more comfortable with the language of a Responsible Entity, and building the lab got me closer than reading the standards ever did. If I had to leave you with one thing: don’t try to learn the standards by reading them, build something they apply to and then assess it honestly. That’s the difference between knowing the acronyms and knowing what they actually protect.

In plain terms, here’s what this series is: a virtualized OT environment built from scratch, assessed against CIP-002, CIP-005, CIP-007, CIP-010, and CIP-015, with the compliance evidence automated and the whole stack re-categorized against a standard that hasn’t taken effect yet. It’s a lab, not an audit, and I’ve said so in every post, but the reasoning behind it is the same reasoning the job takes. If your team does this work for real, I’d like to hear from you: get in touch.

References

• FERC Order No. 919 — Virtualization Reliability Standards (Federal Register, Mar 2026) · NERC Reliability Standards
• KVM · libvirt · libvirt access control
• Why I Built a Fake Power Grid to Learn NERC CIP — where the series began
• GRC-as-Code: Automating CIP-010 Baselines and Evidence