What the EU’s AI and cybersecurity regime actually means for a North American utility — and why the certificate your vendor just waved at you is not the thing you think it is.
The following Utility Voice was authored by Marc Rosson, Community Connector at Utility.Community.
Six days before the EU AI Act’s high-risk obligations were due to land, the European Union moved the date.
Regulation (EU) 2026/1744 — the Digital Omnibus on AI — was published in the Official Journal on 24 July 2026 and entered into force on 27 July. Stand-alone high-risk systems under Annex III now have until 2 December 2027. AI embedded in products already covered by EU product-safety law, under Annex I, has until 2 August 2028. The August 2026 date that has been circled on every compliance calendar in this industry for two years is no longer the date.
If your reaction to that is relief, you have misread it. The requirements did not shrink. The clock did. And the reason the clock moved is the part that should concern you: the harmonised standards, the notified-body capacity, and the national competent authorities needed to make the regime operable were not ready. Europe deferred because the machinery was not built, not because it decided the machinery was unnecessary.
Meanwhile, I keep sitting in vendor conversations where three completely different instruments get presented as if they were interchangeable proof of the same thing. That confusion is the actual risk in front of most utilities right now — more immediate than any deadline.
Layer One: The Three Instruments Everyone Merges
There are three things in play, and they operate at different layers of the stack. Getting them straight is most of the work.
The Cybersecurity Act and its certification framework (ECCF) certifies products. It is voluntary unless some other law makes it mandatory. Assessment runs through an accredited conformity assessment body under an ENISA-managed scheme, and the output is an EU-recognised certificate — EUCC being the one that actually exists. Its legal effect is mutual recognition across Member States.
ISO/IEC 42001 certifies your management process — an AI management system, structurally analogous to ISO 27001 for information security. Voluntary and contractual. Assessment runs through an accredited certification body. Its legal effect inside the EU regulatory framework is precisely zero.
AI Act conformity and CE marking applies to the system as placed on the market. Mandatory for high-risk systems. Assessment runs through a notified body or self-assessment depending on which Annex you fall under, and the output is an EU declaration of conformity, a CE mark, and registration in the EU database. Its legal effect is market access. No mark, no sale.
Product. Process. Market access. Three layers, three instruments, and a vendor holding one of them has not demonstrated the other two.
Layer Two: The Presumption Gap
This is the technical point that changes procurement conversations, and it is the one I would put in front of your legal team first.
Article 40 of the AI Act establishes that conformity with a harmonised standard cited in the Official Journal creates a presumption of conformity. That phrase carries real weight. It shifts the burden of proof: a market surveillance authority challenging you has to demonstrate that the standard fails to address the requirement, rather than you demonstrating sufficiency from first principles.
ISO/IEC 42001 is not cited in the Official Journal. It is an international standard sitting outside the EU harmonisation process. A provider relying on it alone retains the full evidentiary burden, and will face open questions about whether each element of the Article 17 quality-management obligation is adequately covered — with the answers depending on an individual auditor’s interpretation.
The European equivalent is no longer a draft. CEN-CENELEC approved it on 12 July 2026 and published it as EN 18286:2026, Artificial intelligence — Quality management system for EU AI Act regulatory purposes, available since 22 July. It came out of CEN/CLC/JTC 21 under the Commission’s standardisation requests, and it is the first European standard supporting the AI Act to reach publication. It builds on 42001 and adds the AI Act-specific conformity assessment content that 42001 does not carry.
What it does not yet have is a citation in the Official Journal. Until that lands, Article 40 does not attach and EN 18286 confers no presumption either. That is the part worth sitting with: the text is final, the content is fixed, and the only thing outstanding is an administrative step. When the citation appears — it is intended to support Article 17(1) and the first sentence of Article 11(1), with the exact scope set out in Annex ZA — a provider holding EN 18286 gets the burden shift and a provider holding only 42001 does not. The gap is no longer between a standard and a draft. It is between a standard that is about to be recognised and one that never will be.
So: 42001 is still a credibility and readiness asset, and it is still not a legal shield. But the question to put to a vendor has sharpened. “Is your standard cited in the Official Journal?” still settles it — the follow-up is now the harder one: EN 18286 has been on the shelf since July, so what is your plan for it, and what happens to your position the day it is cited? If the answer is that 42001 covers it, they are either confused or hoping you are.
Layer Three: The Certification Framework Is Itself Under Construction
It is worth understanding how thin the European certification apparatus actually is before you assume it can carry weight in your supply chain assessment.
Seven years after the Cybersecurity Act, exactly one scheme has been adopted: EUCC, for ICT products, based on Common Criteria, adopted in 2024. The cloud services scheme (EUCS) has been deadlocked since 2020 over sovereignty and data-localisation requirements. The 5G scheme, the digital identity wallet scheme, and the managed security services scheme all remain under development.
The Commission’s answer arrived on 20 January 2026 as a proposed revision — CSA2. It renews the certification framework with a twelve-month default for developing new schemes, expands ENISA’s remit substantially, and adds supply-chain provisions including the power to exclude high-risk suppliers from critical infrastructure.
One provision in there deserves more attention than it is getting from this side of the Atlantic: CSA2 opens the door to certifying a company’s cybersecurity risk management — entity-level rather than product-level. That is the first European construct that structurally resembles a CIP audit. If it survives the legislative process, the two regimes start converging in a way they never have before.
Layer Four: The Deadline That Actually Binds You Is the CRA
For a DERMS platform, a grid-analytics product, or a metering head-end, the Cyber Resilience Act is frequently more consequential than the AI Act — and it did not get deferred.
The CRA phases in on its own schedule: vulnerability reporting obligations from 11 September 2026, full application from 11 December 2027. It requires manufacturers to report actively exploited vulnerabilities and serious incidents within 24 hours of discovery. It is product law, with CE marking, and it reaches into secure-development practice rather than paperwork.
It also feeds the AI Act. The secure-development and vulnerability-handling evidence a manufacturer builds for CRA is the same evidence that supports the AI Act’s Article 15 cybersecurity resilience requirement. If you are evaluating a European-sourced platform, CRA readiness is the more diagnostic question — and the one with the nearer deadline.
Layer Five: Where the SAP Estate Actually Gets Touched
Translate this into the estate most of us are running.
If you are on S/4HANA Utilities under RISE, with BTP services and Joule in the picture, the provider-versus-deployer distinction is not academic. SAP is the provider for what it ships. You become a provider the moment you build something on BTP that performs a high-risk function and you place it into service — and “placing into service” includes internal deployment. A custom scoring model for disconnection prioritisation, an AI-assisted credit or deposit determination in FI-CA, an algorithmic input into service territory decisions: these are the ones that walk toward Annex III on their own.
The Clean Core discipline helps here, and not for the reason it is usually sold. Keeping extensions on BTP rather than in the core means your AI-touching logic sits in a bounded, documented, separately-versioned place. That is exactly what a technical documentation obligation and an audit trail want. Clean Core as a compliance architecture is a better argument than Clean Core as an upgrade-velocity argument.
Layer Six: Europe Certifies the Artifact. North America Audits the Operator.
Here is the framing I would carry out of all of this.
The European model pushes obligation onto the manufacturer or provider and resolves it through certificates, declarations, and CE marks. NERC CIP puts the obligation on you, the registered entity, and resolves it through audit evidence and financial penalties. These are not equivalent constructions, and a European vendor’s CE mark is not a CIP artifact.
The one real bridge is CIP-013. An EUCC certificate, a CRA declaration of conformity, or an SBOM becomes vendor-supplied evidence inside your supply chain risk assessment. It does not become a substitute for the assessment.
And there has been an attempt to widen it — worth understanding precisely because it failed. The proposed CIP-013-4, developed under Project 2025-06 in response to FERC Order No. 912, would expand applicability to associated EACMS, PACS, PCAs, and Shared Cyber Infrastructure, and add reassessment timelines: 24 calendar months for high impact, 36 for medium, including for spares and emergency repairs. Draft 1 went to initial ballot in July 2026 and came back with 30.64 percent approval on a 90 percent quorum. Two-thirds of the weighted vote said no, on a draft the industry had turned out in force to read. It is back with the drafting team, with no second posting scheduled.
Read that as signal, not reprieve. FERC’s directive does not expire because a ballot failed, and something has to come back. What the vote tells you is that the industry does not yet accept a fixed reassessment clock on associated systems — which is exactly the obligation AI-enabled tooling would land inside if it survives. The direction is settled; the mechanism is not. Draft 2 is where that argument actually gets had, and a comment period is the cheapest place you will ever have it.
There is still no AI-specific NERC standard. Your exposure runs through CIP-010 change management and CIP-013 supply chain, not through anything purpose-built. Which means the AI-generated code accumulating in your internal tooling right now raises a provenance question CIP-013 was never drafted to answer: who is accountable for the integrity of code that no single developer wrote or reviewed line by line?
What European Peers Are Actually Reporting
I asked Kathleen Hänsch, who leads the DSAG utility group for Germany, Austria, and Switzerland, what she is seeing on the ground.
Her read is that utilities across Germany and Europe are absorbing regulatory expansion, cybersecurity pressure, AI adoption, and large-scale SAP transformation simultaneously — and that no organisation is managing that combination in isolation. Peer networks are becoming load-bearing infrastructure rather than a nice-to-have.
On the AI Act specifically: most organisations are still working out what the requirements mean in practice, and the current focus is governance, transparency, risk management, and how to introduce AI in a compliant and secure manner at all.
The observation I found most useful came from her organisation’s own IT security program — governance, ISMS, technical controls, monitoring, and NIS2 obligations. Her lesson from it: cybersecurity has stopped being a purely technical topic and has become a business and management issue requiring clear responsibilities, documented processes, and continuous organisational awareness.
Which produces the sequencing point I think is the single most transferable insight here. Before utilities can deploy AI at scale, they need a solid foundation in identity management, access governance, data quality, and cybersecurity. AI readiness and security maturity are the same maturity curve. Organisations discovering this are discovering it the expensive way.
That maps directly onto the BDC and data-foundation conversation this community has been having for a year. The governance work is not a tax on the AI program. It is the AI program’s prerequisite.
Honest Caveats
Several things in this piece are less settled than a clean article structure makes them look.
The Omnibus deferral is a moving target and may move again. It took three trilogues and a compressed five-month legislative sprint to land. Standards completion is what drove the delay, and while EN 18286 has now landed, it is one piece of a package that is still incomplete and still uncited. Do not build a plan that assumes December 2027 is final.
CSA2 is a proposal, not law. The entity-level certification provision I flagged as significant may not survive. Member State positions on the supply-chain exclusion powers are geopolitically loaded, and that is exactly the kind of provision that gets traded away.
CIP-013-4 failed its first ballot. The scope expansion and reassessment intervals I cited are Draft 1 text, and Draft 1 drew 30.64 percent. The numbers are accurate as drafted and may not survive the redraft. Confirm current status directly with NERC before you plan against them, and do not commit budget to a 24-month clock that two-thirds of the industry just declined to accept.
Most of this may not apply to you at all. If you are a US municipal or co-op with no European market presence, the AI Act and CRA reach you only through your vendors — which is real, but indirect. The direct obligation stays NERC CIP. I have watched enough compliance theater to be wary of importing a foreign regime’s anxiety without checking whether it actually attaches.
Nobody has run this end-to-end yet. There is no body of practice showing how a European conformity artifact performs as evidence in an actual CIP-013 audit. I am reasoning from the structure of the instruments. The first utility to test it in a real audit will teach the rest of us more than any article can.
And the “AI readiness equals security maturity” claim is a correlation I find persuasive, not a proven causal sequence. It is possible to deploy narrow AI successfully on a mediocre security foundation. It is just a bad bet at scale.
What Are You Seeing?
The questions I would most like answers to from this community:
Has anyone actually asked a vendor whether their standard is cited in the Official Journal, and what came back? Is anyone treating a CRA declaration as CIP-013 evidence today, and how did your auditor react? And for those running AI pilots on BTP — have you classified any of them against Annex III, or is that conversation still ahead of you?
If you are working through this, bring it into the community. The organisations that navigate the next eighteen months well will be the ones that compared notes rather than each solving it alone. That is the whole argument for peer networks, and it is Kathleen’s point as much as mine.
I will be at ASUG’s SAP for Utilities conference in San Antonio in October, and this is one of the threads I want to pull on there. Find me.