Cloud Comes to NERC CIP: The 100-Series and Project 2023-09
By Patrick Miller
Ask a room of utility people whether they would run their Energy Management System (EMS) in the cloud and many of them cringe. Fair enough. Some are ready for this. Others still want critical systems to stay on their own iron in their own data center. At the same time, almost all of these same utilities run their email, their HR, their productivity suites, their service ticketing, and a growing stack of their security tooling in the cloud, and the grid keeps humming along just fine. The cloud was never the problem for these tools. The problem is that CIP was never built to tell those two situations apart (when we built it, we didn’t need to).
For twenty years, CIP has rested on a single foundation, the Cyber Asset. It is a programmable electronic device, with hardware, software, and data you can point to. In the cloud, that idea falls apart. There is no box, no rack, no device you own. So for most of the last decade, utilities have asked a simple question. Can I put a BES Cyber System or an EACMS in the cloud and stay compliant? The honest answer was a clear no, but that answer carried a cost. While everyone lived with it, vendors kept sunsetting the on-premises products utilities were forced to hold onto. Compliance had frozen the architecture in time while technology and innovation zoomed ahead.
NERC's Project 2023-09 is their answer to this problem. What makes it interesting, is actually the road they didn’t take. The project team(s) didn’t reopen CIP-002 through CIP-015 and bolt some cloud language on. They stood up a second suite of CIP Standards that runs alongside the old one, numbered by adding 100 to whatever standard it mirrors. You elect a path, the old construct or the new, for any given system. The first informal drafts posted on July 8, 2026. Comment runs through August 21. This is the earliest real look we have at what a cloud-native CIP reads like, and it is worth your time now, because the shape of it is already set even though almost none of the details are.
Overview
Project 2023-09 posted five draft standards for informal comment: CIP-002-9, CIP-102-1, CIP-103-1, CIP-105-1, and CIP-113-1, along with an implementation plan, nine new definitions, and a technical rationale for each piece. None of it is balloted. These are early drafts on an informal track, and the drafting team says plainly that several of the hardest questions are still open. But the architecture is clear, and it is the biggest conceptual shift in CIP since we moved off the old Critical Cyber Asset model a decade ago. I would even go so far as to say it’s definitely a bigger shift than the v3 to v5 transition and maybe even bigger than the virtualization improvements. All together, it’s an avalanche of change in a very short amount of time.
Three decisions carry the whole thing. First, the existing suite does not change; NERC now calls it the "000-Series." Second, the cloud version is a separate "100-Series" that maps standard-for-standard onto the old one. Third, you do not run both on the same system. You pick a track per system, and CIP-002-9 exists to make sure the two can never land on the same system at once.
I have spent a good part of my career with these standards, helping shape the early ones and later reviewing programs against them from the audit side. So here is my honest read. Nothing else moving in the CIP pipeline matters as much as this, and nothing this important is this unfinished. Read it as direction to understand, not as requirements you can build to yet.
Why a Parallel Track, and Not a Rewrite
The backbone of the current CIP suite we are still using today was originally filed with FERC in August 2006. It was built on a voluntary standard from 2003. Both predate the iPhone. Every control in that suite traces back to a physical Cyber Asset you own and can locate. NERC said as much in its own 2019 Virtualization and Future Technologies white paper. Rely on physical assets the way the current standards do, and cloud simply cannot be done compliantly for some systems, including BES Cyber Systems and EACMS. FERC's 2020 Notice of Inquiry (Docket RM20-8) made the same point from the other side, noting that nearly every new product vendors sell is now cloud-based. This has been coming for years. NERC has even cracked this door open once already, letting entities keep BES Cyber System Information in the cloud under CIP-004-7 and CIP-011-3 a couple of years back. The 100-Series follows that same instinct across the full body of the standards.
It also lands on a base FERC just finished establishing. In March 2026, Orders 918 and 919 finalized the on-premises virtualization update from Project 2016-02, standing up Shared Cyber Infrastructure and a new "Cyber System" definition and producing the CIP-002-8, CIP-005-8, CIP-007-8, and CIP-013-3 versions the 100-Series builds straight on top of. The cloud track doesn't reopen that work, it extends it.
The team looked at a range of options. A single cloud standard, a notional "CIP-016," got considered and rejected for piling on complexity. Amending the existing standards in place was the obvious move, and they did not take it, because you cannot touch the definitions and exemptions that hold the 000-Series together without the change cascading into every standard. A parallel suite keeps the impact contained. The old standards stay exactly as written for anyone who never touches cloud and the new obligations only attach when you do.
Another interesting thing is this effort did not start as a FERC order. Supply chain came from Order No. 829. INSM came from Order No. 887. This came from an industry Standards Authorization Request, first accepted in December 2023. FERC had already floated the idea. Their 2020 NOI asked, in plain terms, whether CIP even permits cloud and whether the Commission should direct NERC to fix it. This is how the industry answered the question.
The Structure: 000 Versus 100
Start with the numbering, because it tells you what kind of change you are looking at. A whole-number bump (CIP-005-8 to a hypothetical CIP-005-9) is a revision. A ".1" is an errata. A letter “a” is an Interpretation applied. Adding 100 is none of these. It says you are looking at a different regime that happens to share DNA with the one you know.
The future 100-series map is one-to-one with the 000-series on purpose:
| 000-Series (existing) | 100-Series (cloud) | Status |
|---|---|---|
| CIP-002 Categorization | CIP-102 BCSS Identification | Draft posted |
| CIP-003 Security Management | CIP-103 Security Management Controls | Draft posted |
| CIP-004 Personnel & Training | CIP-104 | Anticipated |
| CIP-005 + CIP-007 | CIP-105 System Protection (CIP-107 merged in) | Draft posted |
| CIP-006 Physical Security | CIP-106 | Anticipated |
| CIP-008 Incident Reporting | CIP-108 | Anticipated |
| CIP-009 Recovery | CIP-109 | Anticipated |
| CIP-010 Config/Vuln | CIP-110 | Anticipated |
| CIP-011 Info Protection | CIP-111 | Anticipated |
| CIP-012 Comms | CIP-112 | Anticipated |
| CIP-013 Supply Chain | CIP-113 Supply Chain Risk Management | Draft posted |
| CIP-015 INSM | CIP-115 | Anticipated |
Two things should jump out of that table:
CIP-105 rolls two standards into one, folding the old CIP-007 content (which had briefly been drafted as its own CIP-107) into a single System Protection standard
There is no CIP-114, because CIP-014 physical security sits outside this whole effort
The Election Is Per System, and It Is Enforced
CIP-002 is still the cornerstone and you need to get it right. But now, you make the choice per service or system, and not once for the whole entity, and not per Cyber Asset, because in the cloud there is no physical Cyber Asset to point at. The new unit of decision is the individual cloud service or system, what the 100-Series calls BES Cyber Services and Systems, or BCSS, along with the supporting security services around it. Those supporting pieces get their own new names, described in the next section; for now the point is just that you are classifying services, not boxes. Most entities will end up running both suites at the same time, the 000-Series for the on-premises fleet and the 100-Series for anything in the cloud. The one thing you cannot do is put a single system under both.
CIP-002-9 is the lever that does the work. It fits with CIP-102, but the intuitive concept in your mind may be wrong. The way these are written, CIP-002-9 is not a step you finish first, and there is no "do this, then that" order between them. It is a companion revision to the existing categorization standard that has to take effect in lockstep with CIP-102, and its whole job is the carve-out. It makes CIP-102 and CIP-003 through CIP-015 mutually exclusive, so a system identified under one cannot also be pulled under the other. The front door is still identification and impact rating, and that logic does not change between suites. The fork comes at one question you ask of each system, is it cloud-provided or cloud-integrated? Yes sends it down CIP-102 and the rest of the 100-Series. No keeps it in CIP-002 and the 000-Series.
Two wrinkles may bite in practice. The first is the transition path. The drafts see the messy middle coming, where a BES Cyber System stays on-premises but its supporting access-control or monitoring systems move to the cloud. There, the on-prem system stays on the 000-Series while the cloud-hosted supporting pieces go to the 100-Series, and one entity ends up running both regimes around a single system. That is going to be the common pattern, so it is the one to run through the process early. The second wrinkle, cloud is the trigger, but not the only door. The implementation plan also lets you elect into the 100-Series for systems that are not in the cloud at all, because BCSS is written to cover on-premises systems too. If you like the objective-based model better, you can choose it. You don’t have to wait until you migrate.
BCSS: The New Foundation
If the Cyber Asset is the foundation for the old suite, BES Cyber Services and Systems (BCSS) is the foundation for the new one. It replaces "BES Cyber System" throughout the 100-Series, and the team gave it a deliberately different name so the two suites never blur together. The impact test will look familiar. A service or system whose loss, degradation, or misuse would hurt reliable operation of the BES within 15 minutes, redundancy not considered. What changed is the thing you are protecting. It is no longer a device you own. It is a service, maybe one you rent, maybe one running on infrastructure you will never even see.
Under BCSS, the team rebuilt the whole supporting-asset vocabulary, because the old EACMS/PACS/PCA terms are just as asset-anchored and do not survive the cloud construct. In their place, nine new defined terms:
| New term | Roughly maps to | What it is |
|---|---|---|
| BES Cyber Services and Systems (BCSS) | BES Cyber System | The 15-minute-impact service or system itself |
| Access Control Services and Systems (ACSS) | Part of EACMS | Provides access control for BCS/BCSS/PCSS |
| Security Monitoring Services and Systems (SMSS) | Part of EACMS | Provides security monitoring |
| Other Security Services and Systems (OSSS) | Part of EACMS | Recovery, config, vuln, posture functions |
| Protected Cyber Services and Systems (PCSS) | Protected Cyber Asset | In-zone systems that are not BCSS/ACSS/SMSS/OSSS |
| Associated BES Cyber Services and Systems (ABSS) | (collective) | The set of ACSS, SMSS, OSSS, and PCSS together |
| Cyber Security Zone (CSZ) | Electronic Security Perimeter | A logical trust boundary, independent of location |
| Conduit | (new) | A secured pathway between zones |
| System Security Plan (SSP) | (new) | The document tying controls to objectives |
Notice the old EACMS splits into three cleaner functional buckets. That alone is going to change how people scope, and it lines up with Project 2021-03, which is already trying to centralize how EACMS, PACS, and PCA get identified in the current suite. Notice too that these definitions only add. The team is proposing nine new terms and modifying or retiring zero of the existing ones. The 000-Series glossary stays untouched, which is the entire reason to fork in the first place.
The other big change is the System Security Plan. The SSP is a NIST concept, and it flips the posture from "follow this documented process and keep the evidence" to "state your objective, document the methods and controls you actually used, and show the results." It is objective-based and results-based instead of prescriptive. If you have spent a decade proving you followed a process whether or not it accomplished anything, that is a real shift, and the auditor's job under it looks different too. This shift is part of the larger NERC CMEP move to more of a controls-based audit approach. We’ve covered it in our posts “Beyond the Checklist: The Place of Internal Controls in NERC CIP Compliance Programs” and “From Spot Evaluations to Continuous Oversight: NERC’s New Internal Controls Model.”
That NIST lineage raises a fair question for anyone running an internal controls program. If the SSP is a NIST construct, should you reach for a NIST control catalog like SP 800-53 to show compliance? It’s not a bad idea, and there is genuine value in it, with a caveat. A recognized catalog hands you a testable, traceable control set with objectives, owners, and evidence, which is exactly what an internal controls review seeks. FERC audit staff already cite the NIST 800-series as additional guidance in their lessons-learned reports and several orders. But watch for the trap. Compliance is still measured against the security objective in the CIP Technical Rationale, not against 800-53. Lean too hard on the NIST catalog and you drag in controls the standard never asked for, handing an auditor scope you never owed and binding your program to obligations past the requirement. The mappings between NIST catalogs and CIP are subjective, and they get revised often, so an alignment you build today may not match the mapping sitting in front of you at your next audit. Use a NIST catalog for structure and defensibility if it helps you, but tie every control back to the CIP objective, and treat the mapping as a convenience you maintain vs. a prescription you inherit.
CIP-102: Identification Without Location
CIP-102 is built on CIP-002-8, and its whole move is to cut categorization loose from physical “thing.” The old standard leans on where a thing sits, most obviously through the Control Center definition and its "and associated data centers" language, which is exactly the phrase that made cloud hosting impossible to categorize. Rather than reopen the Control Center definition, which you cannot touch without cascading into every other standard, the team rebuilt the relationship in Attachment 1 around function instead of place, the cyber service or system, the function it performs, and the "iron" asset it serves.
The prescriptive list of location-based asset types that used to sit in Requirement R1 is gone, its work now handled in the Attachment 1 criteria. The impact-rating criteria themselves, the electrical thresholds and weighted values, were smartly left alone, so only the location-tethered language got reworked. The stated intent is reassuring. For on-premises systems, CIP-002 and CIP-102 should give you the same answer. The difference is what CIP-102 catches on top of that, which is cloud, either as systems in their own right or as services woven into on-prem systems. One more practical touch, identification happens "prior to use" rather than on the old 15-month review cycle, so a new cloud service gets scoped and approved before it goes live instead of waiting for the calendar to turn.
CIP-105: The ESP Gives Way to Zones and Conduits
CIP-105 is where the architecture changes most, and if you only read one draft, read this one along with its Technical Rationale. It merges CIP-005 and CIP-007 into a single System Protection standard, and for cloud purposes it retires the the Electronic Security Perimeter (ESP) idea that has defined CIP network security from the beginning.
In its place are the Cyber Security Zone and the Conduit. A CSZ is a logical trust boundary that groups systems by common security requirements, impact level, or objective, and it is explicitly independent of physical location or network topology. A Conduit is a secured pathway between zones, and it has to be protected to the level of the highest-impact zone it touches, so an attacker cannot ride a weak connection into a critical zone. If you have worked with IEC 62443 zones and conduits, the vocabulary will feel familiar. That is not a coincidence. It’s a straight borrow, and a smart one.
The standard runs across eight familiar requirements:
Zone definition
Access to zones
Access to services and systems
Authorization
System hardening
Vulnerability management
Malicious code
Security event monitoring
Every requirement reads as an objective with the risk it addresses spelled out, and every one closes with a periodic testing-and-verification step. This is CIP written as outcomes instead of checklists. Whether the industry and its auditors are actually ready to be measured on outcomes instead of artifacts is one of the more interesting questions this whole project surfaces.
CIP-113: Supply Chain, Rebuilt for Providers You Do Not Control
CIP-113 adapts CIP-013-3, with an eye on the CIP-013-4 work happening in parallel under Project 2025-06, and it keeps the FERC Order No. 829 obligations that started supply chain regulation in the first place. What is new is a structured, up-front inquiry into cloud-specific risks that simply did not exist when CIP-013 was written:
Concentration risk and span of control. The single-provider, single-pane-of-glass exposure, including the sector-level version where much of the industry leans on the same few hyperscalers.
Licensing and end-of-life. A provider sunsetting or re-terming a service, largely out of your hands.
Reliance on indirect services. Subcontractors and sub-processors you cannot see behind the prime vendor.
Data, processor, and network sovereignty. Where your data actually lives, gets processed, and can be legally compelled.
Cloud interface configuration, API to API. The reliability hit when a provider changes an API out from under you without notice or a test window.
Resiliency and service interruption. The provider's failover, recovery, and restoration posture.
The design is a sequence, not a gate. Gather decision-useful information from the vendor first, understand the residual risk, then document the entity-specific controls that manage whatever is left. The requirements got regrouped by security domain, incident management, access management, supply chain vulnerability management, and shared responsibility, with a new subpart making you document who owns what when responsibility is split with a provider. The old CIP-013 requirement for CIP Senior Manager approval of the plan got deleted here, because that governance now lives in CIP-103's SSP controls. No double jeopardy. (For where the on-premises version of this standard is heading next, see our read on FERC Order 912 and the future of supply chain risk management.)
Borrowing From the Bigger OT Security Picture
NERC CIP may be one of the oldest OT security standards out there, but it is now only one of many developed since it’s origin. The 100-Series effort is pulling CIP into line with the rest of the OT security world. The System Security Plan is NIST. The Cyber Security Zone and Conduit come almost word-for-word from IEC 62443. The objective-and-outcome structure, state the goal and the risk, then show the controls that met it, is framework language, not prescriptive-compliance language. None of that is cosmetic. It means an entity already running a 62443-aligned architecture or a NIST-based control program can reuse that work instead of translating it into CIP dialect, and it means auditors will increasingly expect fluency in those frameworks, not just in the CIP requirement tables. For a standard that spent two decades as its own closed universe, that is a real opening to the wider field, and on balance a much more effective/efficient approach. The same caution from the internal-controls discussion above applies. Harmonization helps right up to the point where borrowed language drags you past what the CIP objective actually requires.
Where Everything Stands, and What to Watch
The "how far along is this" question matters as much as the "what does it say" question, so here is the status in one place:
| Item | Detail |
|---|---|
| Origin | Industry SAR, accepted December 2023. Not a FERC order. |
| Current posting | Informal comment on draft standards, July 8 to August 21, 2026 |
| Prior posting | Informal white paper, December 2025 to February 2026 |
| Drafts posted | CIP-002-9, CIP-102-1, CIP-103-1, CIP-105-1, CIP-113-1 |
| New definitions | Nine, led by BCSS. None modified, none retired |
| Effective date | Later of January 1, 2029, or six months after approval |
| Low-impact cloud grace | Additional 24 months for low-impact BCS already using cloud |
| Priority | Medium on the current plan; the January 2026 CIP Roadmap recommends raising it to high |
Regulation by Proxy: The Provider Problem
The hardest question here is not technical, but rather jurisdictional. FERC and NERC regulate registered entities, the owners and operators of the Bulk Electric System. They do not regulate AWS, Azure, or GCP, and they cannot (while still accounting for the distinction for the Computational Load Entity). Yet the entire 100-Series leans on those providers behaving in ways you can document and defend at audit. The standard puts the evidence and the accountability on you, the Registered Entity, and then counts on you to pull audit rights, log retention, incident notification, and subcontractor visibility out of a provider through a contract. When the provider says no, and hyperscalers routinely hand you a SOC 2 report, an ISO 27001 certificate, or a FedRAMP package instead of CIP-shaped evidence, you are left holding a gap you did not create and cannot close on your own. Most existing cloud agreements were never written with a CIP auditor in mind. This is only formally addressed currently through the “work of others” options, which haven’t really been tested yet through actual audits.
There is an already existing, fair defense of this design. CIP-013 already regulates vendor risk indirectly, and the entity has always been on the hook for reliability no matter who hosts the system. The 100-Series even nods at the seam with a CIP-113 subpart making you document who owns what when responsibility is shared. Under this perspective, NERC is not regulating the cloud provider at all. It is making you manage your own third-party risk, which is squarely NERC's business.
The trouble is that cloud stretches that model past where it bends comfortably. The concentration is extreme, with much of the sector resting on a handful of providers. The leverage runs the wrong way, because one utility has almost no ability to move a hyperscaler that serves the whole economy. And "the market will respond to demand" is a hope, not a control, and even when it works it tends to show up as a premium you pay for. Regulating the providers by proxy, through the entities they serve, is a legitimate description of what is happening here, and it’s definitely worth saying out loud during a comment period instead of after the text is locked. The liability question sits under all of it and the drafts leave it there. When a provider outage or compromise causes a real reliability event, who answers for it, and in what proportion, is a contractual and legal matter the standard hands back to the parties. That is not a knock on the drafting team so much as a limit on what a reliability standard can do. It is also why several commenters have argued that provider assessment should be run centrally, by NERC, FERC, or the E-ISAC, rather than by a few thousand entities each negotiating alone with the same few providers.
Forward-Looking Questions
Pull the pieces together and a handful of questions decide whether this works, and all of them are worth raising while the words are still being drafted.
The first is the one I keep coming back to from the audit side. Can objective-based CIP be audited the same way twice? The 100-Series bets almost everything on the System Security Plan and on requirements written as outcomes, state the objective, show the controls that met it. That is a better way to run security, but it’s a harder way to run compliance. We have seen where vague, outcome-flavored language goes before. The first INSM draft asked entities to provide "security value to address the perceived risks," and the ballot body torched it at 15 percent approval. Objective-based only works if the regions land in the same place on the same evidence, and nothing in these drafts guarantees they will (and history shows they probably won’t). This approach risks trading prescriptive box-checking for years of inconsistent findings.
The second is the provider problem wearing a different suit. Does anyone assess the cloud service providers centrally, or does every entity keep doing it alone? I gave that its own section for a reason. The open piece is whether NERC, FERC, or the E-ISAC steps in to run a shared assessment, or whether a few thousand entities each keep negotiating blind with the same three hyperscalers. That one decision drives the cost and the credibility of the whole model.
Third, the risk you are actually defending against changed, therefore the controls have to change with it. Commenters have said what any cloud engineer will tell you. The thing that gets you breached in the cloud is misconfiguration, not the unpatched CVE that much of CIP was built to catch. CIP-105's hardening and monitoring requirements have to prove they catch the misconfiguration as reliably as the old model caught the missing patch.
Fourth, the fork only holds if the cleanup happens. The exemptions still lean on 000-Series terms like "Cyber System" and "Electronic Security Perimeter," and the team has parked a holistic fix until after this comment period, because those words cannot move without moving everything. Until that is done, the seam between the two suites is held together with acknowledgments and good intentions.
And fifth, this is a still-gelling foundation with most of the building still on paper. Eight more standards, CIP-104, 106, 108, 109, 110, 111, 112, and 115, are anticipated and undrafted. The question is whether they keep the same shape, objective-based, zone-based, service-based, or whether the concept drifts as it scales out across incident response, recovery, information protection, and INSM. The first four drafts set the precedent, but they don’t guarantee the rest hold to it.
Final Thought
Step back and the 100-Series is a bigger move than its "informal draft" label signals. In one project, NERC has changed the object of protection from a device to a service, the compliance posture from prescriptive to objective, the network boundary from a perimeter to a zone, and the frame of reference from CIP's own closed world to the broader NIST and IEC 62443 ecosystem(s). Any one of those would be a notable change on its own. Stacked together, they are a different way of thinking about what CIP even is. And the industry asked for it, which is worth holding onto when the comments get sharp.
But the hard parts are exactly the parts left for later, and they are major undertakings. Whether outcome-based CIP can actually be audited. Whether anyone can pry the right evidence out of a cloud provider. Who carries the liability when a provider fails. Whether the definitions ever get reconciled so the two suites do not bleed into each other. None of that is answered in what you can read today.
So here is the practitioner read… Don’t treat this as something to comply with today, because there is nothing to comply with yet. Treat it as the window to shape your future program. Read CIP-105 first, because the zone model is the biggest departure and the hardest to retrofit later. Map your likely cloud footprint against BCSS and the supporting-service categories, so you know what would move and what would stay. Walk the transition path where a system stays on-premises but its security tooling goes to the cloud, because that is the case that will actually land on your desk. Pull your cloud contracts and flag every place you cannot get audit rights, logs, or notification, because those gaps are your future findings. Most importantly, comment before August 21 while comments can still influence the future text. These standards will take years, but the architecture is being decided this summer.
