Recently, Kevin Perry, former Chief CIP Auditor of SPP Regional Entity and co-leader of the team that drafted versions 2 and 3 of the NERC CIP standards, pointed me to a recent blog post by Patrick Miller, the well-known consultant on industrial cybersecurity and NERC CIP. In that post, Patrick discussed three takeaways from FERC’s 2025 “Lessons Learned from Commission-Led CIP Reliability Audits” report.
Patrick’s takeaways were quite insightful and well-written. However, what I found most important was the third takeaway, since it pointed out that NERC auditors (observed by FERC staff members during CIP audits in which FERC participated) are identifying potential CIP violations due to use of cloud services during audits. Patrick summarized the takeaway in this paragraph:
Staff highlight two scenarios. First, an entity used a SaaS (Software-as-a-Service) model for PACS (Physical Access Control Systems), but lacked a documented agreement that spelled out roles, responsibilities, security controls, and compliance requirements. The entity could not demonstrate compliance with CIP-004-7 and CIP-010-4. Second, another entity used cloud-provided MFA (multi-factor authentication) for EACMS (Electronic Access Control or Monitoring Systems) and remote access into devices inside the ESP (Electronic Security Perimeter). Again, the entity had no formal agreements or evidence linking the service to CIP control expectations and failed to demonstrate compliance. Â
Note that, in both of Patrick’s scenarios, the cause of the potential CIP violation was not that the NERC entity’s direct action (or lack of action) had violated one of the CIP requirements, but that the entity had not provided evidence that the cloud service provider (respectively, the PACS-in-the-cloud provider or the cloud-based provider of MFA services that meet the EACMS definition) had taken the actions required to ensure the NERC entity’s compliance with all applicable CIP requirements.
In the first scenario, the entity didn’t document an agreement with the PACS provider that they would comply with the requirements of CIP-004-7 and CIP-010-4 (of course, the agreement needs to identify every Requirement and Requirement Part that the PACS provider must comply with – which means PACS is listed as an Applicable System).
Regarding CIP-004-7, Patrick notes that FERC’s report points to “challenges” for Personnel Risk Assessments (Requirement R3) and “awareness training” (FERC probably meant Requirement R1, the Security Awareness requirement; however, that doesn’t apply to PACS. But Requirement R2, the Cyber Security Training requirement, does apply to PACS and presents a much greater challenge to the NERC entity’s compliance posture than does R1).
Regarding CIP-010-4, Patrick notes that FERC’s report points to Requirement Part R3.1, which “expects an active or paper vulnerability assessment at a defined cadence, which can be hard to execute credibly against cloud-hosted control planes.” The FERC report adds that it is “unlikely that a CSP would allow an entity to perform an active vulnerability assessment within a cloud environment as required pursuant to Requirement R3.1.” Patrick also notes that “CIP-010-4 R1.6 expects software source identity and integrity verification prior to baseline-deviating changes, while many cloud offerings abstract underlying software delivery.”
To analyze the second scenario, regarding use of MFA (a service included in the EACMS definition) delivered through the cloud, you could substitute EACMS for PACS in the three paragraphs above. This is because the requirements referred to are all applicable both to EACMS and PACS. In fact, a supplier of cloud-based EACMS or PACS services will need to provide their NERC entity customers with evidence that they complied with every Requirement and Requirement Part that applies to EACMS or PACS respectively; the fact that FERC’s report only mentioned two standards might just mean the audit in question didn’t include the other standards that apply to EACMS or PACS. Â
There are approximately 95 NERC CIP Requirements and Requirement Parts that apply to EACMS; that number is about 70 for PACS. Patrick points out that, for each of these Requirements and Requirement Parts, the PACS or EACMS provider will need to provide a NERC entity customer with “data access, attestations (where applicable), software provenance, baseline visibility, and vulnerability assessment results”. If the PACS or EACMS provider cannot commit in writing to doing that, Patrick recommends that the entity “redesign” its compliance plan to exclude use of that supplier.
Both Patrick and FERC seem to believe it’s possible that cloud based PACS and EACMS providers will be able to provide NERC entity customers with the required compliance documentation for all 95 or 70 Requirements and Requirement Parts, although Patrick clearly doubts that can happen.
I’ll help them both out: There is simply no way that a provider of cloud based PACS or EACMS will 1) be willing to provide all of the required documentation or 2) be able to provide it, even if they’re willing (after all, I may say I’m willing to provide you a perpetual motion machine but since I can’t do that, my willingness to do so is worth exactly $0.00 to you). Moreover, the same can be said for a SaaS provider that provides a service that meets the definition of BES Cyber System (such as outsourced SCADA), or the platform cloud service provider (CSP) that provides the platform for a NERC entity to install one or more BCS – or even a whole Control Center – in the cloud.
Here’s why I say this:
1.     These providers base their business models on providing a standard set of services for every customer. If one group of customers, such as NERC entities with high or medium impact BES environments, requires a much higher level of service than do other customers, they have to decide whether to apply a surcharge to those customers or simply smile nicely and say they regret they’re unable to accommodate them. Only in a case where the provider is small and highly dependent on business from the electric power industry is it likely they will even consider agreeing to such a request, whether or not they impose a surcharge.
2.     Many of the NERC CIP requirements – such as CIP-007 R2 patch management and CIP-010 R1 configuration management - apply to individual devices, whether physical or virtual. There’s simply no way that any cloud-based service provider can provide documentation on a device-by-device basis, since every workload is almost always distributed among multiple devices and even data centers – and that distribution changes constantly.
3.     Only the smallest cloud-based service providers will be willing to negotiate a contract with a NERC entity – especially when they learn they will need to commit to provide evidence for at least 70 (for PACS in the cloud), 95 (for EACMS in the cloud, including cloud-based security monitoring services), or 110 (for BCS in the cloud, such as outsourced SCADA) CIP Requirements or Requirement Parts. Frankly, their big problem won’t be making the decision, but keeping from laughing out loud when they hear what’s required of them.
This is why, even though BCSI in the cloud was made “legal” in CIP on January 1, 2024, high and medium impact BCS in the cloud, PACS in the cloud, and EACMS in the cloud are effectively impossible to implement while maintaining CIP compliance, even though nothing in the current standards prohibits them.
How long will it take for this situation to change? I have two pieces of good news and one piece of bad news for you. The first piece of good news is that a standards drafting team tasked with solving this problem started meeting in the summer of 2024. The second piece of good news is that in this recent post, I identified seven small, easy-to-implement changes that look like they will solve all three remaining cloud problems: BCS in the cloud, PACS in the cloud and EACMS in the cloud. I believe that, if the SDT starts working today (well, maybe two days from now, since today’s a Saturday) to draft those changes, they could have them drafted, approved by NERC entities, approved by the NERC Board of Trustees, approved by FERC, implemented, and enforced by the initial enforcement date of CIP-015-1: October 1, 2028[i].
What’s the bad news? It’s that the drafting team seems to have embarked on a course that will a) go far beyond what’s needed to fix the three remaining cloud/CIP problems, b) in all likelihood be impossible to implement, and c) even if it is possible to implement it, the team will be at work for literally decades. Since no drafting team would even consider being in session for that long, this means in practice that, absent a change of course in the near future, the team will realize in a year or two that they have no hope of finishing before most of them retire, and abandon the project with little to show for the 2-4 years they’ve spent.
I have explained this in the post I just referenced, but I’ll admit it’s a long, dense post. Given the subject and the need to get everything written down in one place, I didn’t see any other way to write it. I intend to unpack that post into a small number of shorter, more focused posts in the coming month or two. In the meantime, you can email me with any questions or better yet, put them in my Substack chat.
Â
If you would like to comment on what you have read here, I would love to hear from you. Please email me at [email protected] or comment on this blog’s Substack community chat.
Tom Alrich’s Blog, too is a reader-supported publication. You can view new posts for one month after they come out by becoming a free subscriber. You can also access my 1300 existing posts dating back to 2013, as well as support my work, by becoming a paid subscriber for $30 per year.
[i] See the post I just referenced for a discussion of why it is important that the changes I’ve proposed be in place by this date – if at all possible.