En advisory är bara användbar om ni vet vad ni kör

Den 3 september uppdaterades en advisory som berör Schneider Electrics skyddsreläer, RTU:er och stationsgateways — Easergy MiCOM, EcoStruxure EPAS, PowerLogic och Saitel. Sårbarheten i sig var inte ny. Den publicerades i maj. Det som ändrades den 3 september var listan över vilka produkter som är berörda.

Det är en tråkigare nyhet än en ny kritisk sårbarhet. Den är också svårare att hantera.

Varför en reviderad lista är den svåra nyheten

En ny sårbarhet med högt CVSS-tal får uppmärksamhet. Den dyker upp i nyhetsflödet, någon skickar en länk, och arbetet startar mer eller mindre av sig självt.

En reviderad lista över berörda produkter gör inget av det. Den kommer som en rad i en revisionshistorik. Ingen rubrik, ingen varning, ingenting som kräver uppmärksamhet. Ändå är det den som kräver att någon går tillbaka och kontrollerar något som redan bedömdes klart. Den som stämde av mot junilistan och landade i ”berör inte oss” har inte nödvändigtvis rätt längre.

Det finns bara en fråga som avgör hur den här händelsen ser ut hos er: kör vi något av det här, i vilken version, och var?

Kan ni svara idag är det en icke-händelse. Ni öppnar förteckningen, jämför, konstaterar läget och går vidare. Kan ni inte svara blir det i bästa fall några dagars letande, i värsta fall ingenting alls, eftersom det inte finns någon som märker att frågan aldrig ställdes.

Vad föreskriften säger om det

Från den 1 oktober gäller MCFFS 2026:11. Två av bestämmelserna handlar om den här situationen.

3 kap. 10 § kräver att ni bedriver omvärldsbevakning — för att hålla er uppdaterade om ”hot, sårbarheter, teknisk utveckling, rättsliga krav och tillgängligt stöd”. Och den lämnar inte öppet varifrån: den kräver att ni hämtar in relevant information från leverantörer av den digitala miljöns hård- och mjukvara och från det nationella cybersäkerhetscentret (NCSC). De allmänna råden råder dessutom att ni hämtar in information från tillsynsmyndigheter, NCC-SE och ENISA. Bestämmelsen ligger bland de organisatoriska säkerhetsåtgärderna och gäller verksamhetsutövaren. Den är inte avgränsad till it- eller ot-segment.

En uppdaterad leverantörsadvisory och ett veckobrev från den nationella CSIRT-funktionen är exakt de två källor paragrafen pekar ut. Bevakning är inte en extra ambition, utan en av de tio åtgärderna.

4 kap. 9 § kräver en uppdaterad förteckning över relevant information om den digitala miljön, och skälet står i paragrafen: för att ni ”skyndsamt ska kunna omhänderta sårbarheter och incidenter” och bedöma konsekvenserna av dem. De allmänna råden råder att förteckningen bland annat innehåller kontaktuppgifter till leverantörer av hård- och mjukvara i produktionsmiljön, och vilka system som är sektorskritiska. Intill den ligger 4 kap. 8 §, som kräver att dokumentationen över arkitekturen hålls uppdaterad.

Det är vad den 3 september visar. Bevakningen fångar upp att listan ändrades. Förteckningen är det som gör upptäckten användbar.

En sak som ofta blandas ihop

Det här är inte ett krav på att ni ska patcha era reläer.

4 kap. 31 § skiljer tydligt på segmenten. För system i it-segment kräver föreskriften att ni skyndsamt genomför säkerhetsuppdateringar, och att mjukvara som leverantören inte längre ger säkerhetsuppdateringar för byts ut eller uppgraderas utan onödigt dröjsmål. För ot-segment kräver den att ni identifierar och hanterar behovet av uppdateringar, det vill säga att ni bedömer det. Det är en mildare skyldighet, av goda skäl: ett skyddsrelä kan sällan startas om på beställning.

Att läsa ihop de två leden till ”lagen kräver att ni uppdaterar era styrsystem” är fel, och det är en av de vanligaste feltolkningarna vi möter. Bedömningen är er, och den blir bara möjlig om ni vet vad ni har.

Så tänker vi

Vi gör vår del av det här, och inte mer än det.

I den externa kartläggningen visar vi vad som är nåbart utifrån och vilken version som är berörd enligt leverantörens advisory. Där stannar vi: nåbar och berörd version. Vi skriver aldrig ”bekräftat sårbar” utan separat, avtalad testning.

På insidan är passivt utgångsläget, men inte hela metoden. Grunden är att observera hur nätet hänger ihop utan att belasta driften. Omfattar uppdraget mer gör vi också en autentiserad genomgång av konfigurationen, och på it-sidan förekommer aktivt arbete, alltid inom ett skriftligt avgränsat uppdrag. OT är undantaget utan förbehåll — där arbetar vi passivt, aldrig med aktiv skanning. Exploatering, penetrationstest och aktiv testning mot produktionssystem ingår inte i grunduppdraget, utan avgränsas och prissätts separat.

Resultatet är bland annat den förteckning och den systemkarta som 8 och 9 §§ handlar om. Besluten är era. Vi ser till att ni fattar dem med rätt underlag.

Vill ni veta vad som är nåbart och vilka versioner som är berörda? Hör av er.

Källor: CISA ICSA-26-169-07 (Update A, 2026-09-03), Schneider Electric CPCERT SEVD-2026-132-02. Föreskriftstext: MCFFS 2026:11, 3 kap. 10 §, 4 kap. 8–9 §§ och 4 kap. 31 §.