CRA för maskintillverkare efter kommissionens riktlinjer av den 27 juli 2026. Vad behöver man egentligen införa?

Under många år gick det att beskriva en maskins cybersäkerhet i tre steg: en styrning från ett känt fabrikat, VPN “för så gör man” och det klassiska “kunden säkrar nätverket”. Och om någon dessutom satte in en brandvägg i elskåpet ansågs frågan ofta vara löst — åtminstone tills någon faktiskt försökte kontrollera vad som händer vid en verklig attack, och inte i en presentation.

Problemet är att cybersäkerhet inte färdas via PROFINET. Komponenter kan ha certifikat, deklarationer och “secure by design” i marknadsföringsmaterialet, men maskinen som helhet kan ändå vara förutsägbar på ett sätt som inte har något med säkerhet att göra. Precis som ett säkerhetsrelä inte gör systemet säkert om styrlogiken gör det möjligt att kringgå det, löser ett “säkert” HMI inte problemen med arkitektur, integration, behörigheter, uppdateringar och vad som händer när någon slutar be om tillåtelse.

CRA (Cyber Resilience Act, Europaparlamentets och rådets förordning (EU) 2024/2847) är inte ett tillägg för IT. Det är en produktreglering som går in i maskinens livscykel utan att fråga automationsavdelningen om lov. Den omfattar styrsystemets konstruktion, riskanalys, leveranskedjan, konfiguration, uppdateringar samt produktunderhåll långt efter att FAT har signerats och maskinen lämnat hallen. Och nej, argumentet “vi exponerar den inte mot internet” avslutar inte frågan. I praktiken räcker det med en servicelaptop, ett USB-minne, fjärrdiagnostik “bara en stund” eller integration med fabrikens system för att gränsen mellan isolering och exponering ska upphöra att finnas.

Kommissionens riktlinjer från den 27 juli 2026 ändrade inte själva förordningen, men de begränsade effektivt det tolkningsutrymme som tidigare gjorde det möjligt att behandla cybersäkerhet som ett valfritt lager. Bland annat förtydligades produktgränsen, rollen för fjärrbearbetning, ansvaret för ändringar efter leverans samt att “det är inte vårt problem efter FAT” inte längre är ett säkert antagande.

Den viktigaste förändringen är dock mer grundläggande: en cyberattack upphör att vara enbart en IT-händelse och blir i stället ett scenario som påverkar maskinens funktionella säkerhet. Om en obehörig programändring kan orsaka axelrörelse, kringgående av en spärr, ändring av processparametrar eller förlust av säkerhetsfunktioner, talar vi inte längre om en “nätverksincident”. Vi talar om ett potentiellt okontrollerat maskinbeteende — oavsett om orsaken är ett konfigurationsfel, en sårbarhet i programvaran eller ett avsiktligt ingrepp.

I detta sammanhang upphör ett engångs-pentest före FAT att vara ett bevis på överensstämmelse och blir i stället bara en ögonblicksbild av systemets tillstånd vid en viss tidpunkt. CRA kräver ett kontinuerligt angreppssätt: från konstruktion, via produktion och idrifttagning, till uppdateringar, hantering av sårbarheter, incidentrespons och underhåll under den deklarerade supportperioden.

I praktiken innebär det att man lämnar synsättet “klart = säkert” och går över till “underhållet = kontrollerat”. Utan illusionen att en brandvägg i elskåpet, VPN och ett komponentcertifikat löser frågan. Och utan antagandet att cybersäkerhet upphör i samma stund som mottagningsprotokollet undertecknas.

I den här artikeln går vi igenom vad CRA-riktlinjerna faktiskt förändrar för maskintillverkare, integratörer och dem som moderniserar maskiner — utan att reducera hela ämnet till slagordet “vi byter lösenord och lägger till en checkbox för cybersecurity”.

1. För att en maskin inte ska omfattas av CRA skulle den behöva vara nästan helt byggd med kontaktorer

I många projekt kontrolleras CRA:s tillämpningsområde med en enda fråga:

Kommer maskinen att vara ansluten till internet?

Det kommer den inte att vara.

Alltså är frågan avslutad.

I schemat finns PLC, HMI, några drivsystem, distribuerade in- och utgångar, en ventilö, en säkerhetsskanner samt en port för att ladda in programmet. Styrsystemet kommunicerar med panelen via PROFINET, utbyter styr- och statusord med drivsystemen, och sensorerna skickar data via IO-Link.

Men det finns ingen router med SIM-kort.

Som alla vet blir data data först när de lämnar produktionshallen.

Men CRA frågar inte om maskinen har tillgång till internet.

Den frågar om maskinens avsedda användning eller rimligen förutsebara användning omfattar direkt eller indirekt, logisk eller fysisk dataanslutning till en enhet eller ett nätverk. Det behöver inte vara en anslutning till molnet, till tillverkarens server eller till det publika internet. Den kan gå via kabel, radiovågor, ett programgränssnitt eller som en del av ett större system.

Och då kommer den avgörande frågan: vad i en typisk maskin överför faktiskt data?

Läser HMI av tillstånd från PLC:n och skriver börvärden?

Skickar PLC:n ett styrord till drivsystemet och får tillbaka hastighet, status och felkod som svar?

Överför I/O-ön processbilden?

Skickar en IO-Link-sensor mätvärde, enhetsidentifierare och diagnostikdata?

Kommunicerar safety PLC med moduler via PROFIsafe?

Laddas program, hårdvarukonfiguration eller firmware in från en servicelaptop?

Kan recept, rapporter eller uppdateringar överföras via USB?

Om svaret ens en gång är “ja”, handlar det sannolikt om en dataanslutning.

Och det förändras inte av att:

• maskinen arbetar i ett lokalt nätverk,
• den har ingen publik IP-adress,
• Ethernet-porten används bara vid idrifttagning,
• endast servicepersonal ansluter en laptop,
• kommunikationen sker enbart inom styrsystemet,
• kunden har lovat att aldrig ansluta maskinen till internet.

CRA omfattar inte bara den användning som beskrivs i instruktionen som grundläggande, utan även användning som rimligen kan förutses. En serviceport upphör alltså inte att överföra data bara för att det står “SERVICE ONLY” bredvid den på schemat.

Kommissionens riktlinjer av den 27 juli 2026 gör dock en viktig åtskillnad.

Varje kabel och varje elektrisk signal är inte en dataanslutning.

Om en signal enbart används för att slå till, slå från eller mata en viss funktion och inte överför digitalt kodad information, räcker det inte att det finns två elektriska tillstånd för att den ska betraktas som en dataanslutning.

En knapp som lägger spänning på kontaktorspolen blir inte ett digitalt gränssnitt bara för att dess tillstånd kan beskrivas som noll eller ett.

På samma sätt kan en klassisk gränslägesbrytare som är inkopplad i en relä- och kontaktorkrets bara bryta eller sluta kretsen. Den överför inte enhetsnummer, processvärde, diagnoskod, firmwareversion eller ett telegram som innehåller flera uppgifter.

Men när samma tillstånd går till en intelligent enhet, kodas, skickas över en buss, kopplas till diagnostik och tolkas av mottagaren som information, ser situationen annorlunda ut.

Gränsen går alltså inte mellan en maskin som är “online” och en som är “offline”.

Den går mellan en vanlig styrsignal och utbyte av digitalt kodad information.

I praktiken innebär det att en maskin som skulle falla utanför CRA enbart på grund av avsaknad av dataanslutning måste likna en klassisk anläggning med knappar, gränslägesbrytare, reläer och kontaktorer mer än ett modernt projekt som öppnas i TIA Portal.

Detta är naturligtvis inte något lagstadgat undantag för kontaktorer.

Det går att bygga en enkel maskin med PLC som efter en detaljerad analys inte uppfyller kriteriet för tillämpningsområdet. Det går också att lägga till en digital regulator, ett servicegränssnitt eller en kommunikationsmodul i en kontaktorbaserad lösning och därmed hamna exakt på andra sidan gränsen.

Komponentens namn avgör inte saken.

Det avgörande är vad produkten faktiskt gör och vad den utbyter data med.

Därför måste man, innan man svarar på frågan om en viss maskin omfattas av CRA, fastställa:

• var gränsen går för den produkt som bedöms,
• vilka enheter och programvarukomponenter som ingår i den,
• vilka fysiska och logiska gränssnitt den har,
• vilken information som överförs via dem,
• vilka anslutningar som är direkta och vilka som sker via ett större system,
• vilka av dem som förekommer under normal drift, idrifttagning, diagnostik, uppdatering eller service,
• vilka användningssätt som rimligen kan förutses, även om tillverkaren helst inte skulle vilja förutse dem.

Förrän vi har svarat på dessa frågor vet vi inte om maskinen faller utanför CRA.

Det vi högst har är en bekväm formulering:

“Maskinen är inte ansluten till internet”.

Problemet är bara att det är ett svar på en fråga som CRA inte ställer.

PROFINET är inte internet. För CRA behöver det inte heller vara det.

2. Cybersäkerhet sprids inte via PROFINET

I många projekt börjar frågan om maskinens överensstämmelse redan i inköpsskedet.

PLC från en etablerad tillverkare.
HMI med aktuell firmware.
Hanterbar switch.
Industriell router med VPN.
Drivsystem med säkerhetsfunktioner.
Safety PLC med rätt certifikat.

Till varje enhet finns en försäkran om överensstämmelse, en instruktion och några dokument med ord som “secure”, “encrypted” och “defence in depth”.

På schemat ser allt professionellt ut.

Men fortfarande vet man inte om den kompletta maskinen är cybersäker.

För cybersäkerhet “går inte vidare” via PROFINET.

Det är lite som med ett dörrlås:
du kan ha ett mycket bra lås i varje rum, certifierat, testat, med snygg dokumentation och en “secure”-hologrametikett, men det garanterar fortfarande inte säkerheten om någon har lämnat ytterdörren vidöppen “för att det gick snabbare vid idrifttagningen”.

Och precis så är det här också: komponenterna kan vara föredömliga, men systemet kan ändå vara… kreativt öppet.

PLC:n “överför” inte säkerhet till HMI:t.
En brandvägg “rättar inte till” applikationslogiken.
En switch “ordnar inte upp” användaråtkomsten.
Och det faktum att varje del har ett certifikat betyder fortfarande inte att hela maskinen inte är en enda stor, vänligt dokumenterad sårbarhet.

PROFINET överför data.

Det överför inte ansvar.
Och tyvärr överför det inte heller sunt förnuft.

CRA omfattar både kompletta produkter och komponenter som släpps ut på marknaden separat. Det innebär att en styrenhet, en operatörspanel eller en kommunikationsmodul kan bedömas var för sig. Men maskintillverkaren måste fortfarande visa att helheten fungerar säkert i den verkliga konfigurationen hos kunden — alltså i den version där någon “helt säkert inte ändrade något mer… eller hur?”.

Och här uppstår det vanligaste felet.

Det är exakt samma mekanism som vi sedan länge känner igen från maskinsäkerhet.

Ljusridån har PL e.
Safety PLC har SIL 3.
Drivsystemet har STO.

Betyder det att hela maskinen automatiskt ligger på samma nivå?

Det är ungefär som att varje del i en ställning uppfyller säkerhetskraven, men det garanterar fortfarande inte att hela konstruktionen är stabil.

Nej.

För det måste fortfarande kontrolleras hur allt fungerar tillsammans — alltså det där mindre populära steget “systemtänkande”, som tyvärr inte har någon knapp märkt “auto-certify”.

Precis likadant är det inom cybersäkerhet.

Du kan ha “säkra” komponenter, men i praktiken:

• ser operatören och kan ändra mer data än vad som behövs, för att “det var smidigare så”,
• fungerar ett och samma servicelösenord på alla maskiner, eftersom “servicepersonalen vet ju ändå vad den gör”,
• är serviceporten tillgänglig “för säkerhets skull”, alltså för alla eventualiteter,
• omfattar fjärråtkomsten hela nätverket, för att någon en gång sa “det är ju bara diagnostik”,
• kan uppdateringar läggas in utan kontroll, eftersom “inget har ju någonsin gått sönder”,
• “litar” enheterna på varandra utan begränsningar, eftersom tillit är billigare än segmentering,
• och bygger integrationen på att ingen någonsin gör fel, vilket — som historien visar — är det mest optimistiska antagandet inom ingenjörsarbete.

Varje enskild del kan vara korrekt i sig.

Men systemet som helhet kan av dessa korrekta delar bygga något som fungerar … bara inte nödvändigtvis så som det var tänkt.

Och det är det viktiga: risken finns inte i enheterna i sig, utan i hur de kopplas ihop, konfigureras och i den där legendariska åtkomsten som “bara lämnades tillfälligt”.

CRA kräver att maskintillverkaren gör mer än att samla deklarationer som troféer. Det kräver att man kontrollerar om det som satts samman av komponenter fortfarande är säkert som helhet — och inte bara “ser bra ut i en efterlevnadstabell”.

I praktiken innebär det enkla affärsmässiga frågor:

• har varje användare bara den åtkomst som faktiskt behövs, och inte sådan som finns kvar “ifall den kan vara bra att ha någon gång”,
• är fjärråtkomsten begränsad till ett minimum, eller snarare till maximal bekvämlighet,
• har service inte “fulla rättigheter överallt” bara för att någon tyckte att det gjorde livet enklare,
• är nätverket inte en enda gemensam yta bara för att segmentering “komplicerar projektet”,
• är uppdateringar kontrollerade, eller handlar det snarare om “vi lägger in dem och hoppas på det bästa”,
• går det snabbt att identifiera vilka maskiner som är exponerade, eller blir det snarare “vi kollar efter incidenten”,
• öppnar ett fel i en komponent inte upp hela systemet, bara för att “det blev så i integrationen”.

Det här är inte tekniska frågor “för ingenjörerna som jobbar med de svåra sakerna”.

Det här är frågor om affärsrisk: stillestånd, kostnader, ansvar och den lilla detaljen att produktionen faktiskt måste fungera.

Därför räcker det inte att säga:

“alla komponenter är kompatibla”

För det svarar fortfarande inte på frågan:

är hela maskinen säker i verklig användning, eller bara i PowerPoint-presentationen från projektgenomgången?

Leverantörens deklaration är viktig.

Men den gäller bara en enda komponent — den som råkade testas under laboratorieförhållanden, inte i en miljö “någonstans ute i hallen, med VPN, USB och tidspress”.

Den omfattar inte hur den har använts.
Den omfattar inte konfigurationen.
Den omfattar inte integrationen.
Den omfattar inte beslut som fattades “snabbt under idrifttagningen, eftersom kunden väntade”.
Den omfattar inte vad som händer efter flera års drift, när ingen längre minns varför något “tillfälligt lämnades öppet”.

Därför kan bedömningen inte sluta vid en lista över enheter.

Man måste se på systemet som en helhet:

• vem som har åtkomst och varför (inte bara “för att den alltid har haft det”),
• vad som verkligen behövs och vad som bara “lämnades kvar eftersom det inte störde”,
• var data kan läcka utanför kontroll, eftersom någon ansåg att “det är ju bara diagnostik”,
• vad som händer om någon använder legitim åtkomst på ett otillåtet sätt (alltså exakt så som attacker går till),
• hur snabbt man kan reagera när ett problem uppstår, och inte först “vid den kvartalsvisa genomgången”.

Så länge det inte finns svar på de här frågorna har vi bara en uppsättning mycket ordentliga komponenter.

Vi har ännu inte en säker maskin.

Komponenternas överensstämmelse skapar inte automatiskt systemets överensstämmelse. Maskinens överensstämmelse måste utformas, verifieras och — svårast av allt — upprätthållas trots frestelsen att “inte röra något mer, för det fungerar ju”.

3. Lägg inte till cyberattacken i listan över faror. Koppla ihop de två analyserna på rätt ställe

På maskinmarknaden är en formell cybersäkerhetsanalys fortfarande snarare ett undantag än en standardmässig del av projektet.

Oftast finns det en industriell router.

Det finns VPN.

Det finns ett lösenord till PLC:n.

Ibland finns det en hanterbar switch som ingen sedan faktiskt hanterar.

I den mer ambitiösa varianten får tillverkaren en presentation från leverantören om “defence in depth” och anser att analysen av hela maskinens cybersäkerhetsrisk därmed är avslutad.

Det är den inte.

Man har köpt några tekniska skyddsåtgärder.

Det är fortfarande inte någon analys.

Det finns därför ingen mening med att beskriva problemet som om det i varje projekt togs fram två professionella bedömningar — en enligt ISO 12100, en annan för cybersäkerhet — som bara av en slump inte kopplades ihop.

Oftast tas bara en fram.

Maskinens riskbedömning.

Och någon cybersäkerhetsanalys för produkten tas inte fram alls.

En riskbedömning av en maskin enligt ISO 12100 handlar inte om att skriva in följande i en tabell:

fel på givare → oväntad rörelse → klämning.

Det kan vara en del av ett konkret scenario, men det är inte utgångspunkten.

Först måste maskinens begränsningar fastställas.

Vad är dess avsedda användning?

Vilka faser ingår i livscykeln?

Vem ska använda den?

Vilka uppgifter ska utföras vid transport, montering, idrifttagning, produktion, inställning, rengöring, åtgärdande av stopp, underhåll, diagnostik och demontering?

I vilka driftlägen kan maskinen arbeta?

Var befinner sig människan under var och en av dessa operationer?

Vilka delar av maskinen är då fortfarande spänningssatta, trycksatta, belastade eller i rörelse?

Vilken användning strider mot instruktionerna men är ändå rimligen förutsebar?

Först därefter identifierar man för en viss uppgift eller operation bland annat:

• riskkällan,
• typen av fara,
• riskområdet,
• den exponerade personen,
• den farliga situationen,
• den farliga händelsen, om den förekommer i det aktuella scenariot,
• möjliga följder och typ av skada.

Så ser en maskinriskanalys ut.

Man börjar inte med komponenten.

Man börjar med människan som utför en bestämd uppgift vid en maskin i ett bestämt tillstånd. ISO 12100 anger just en sådan metodik för att identifiera faror samt uppskatta och bedöma risk under relevanta faser av maskinens livscykel.

Låt oss ta ett enkelt exempel.

Operatören avlägsnar en fastnad detalj inne i en palleteringscell.

Vi har alltså:

Uppgift: åtgärda ett stopp.

Användningsfas: drift, ingripande efter att processen har stoppats.

Driftläge: manuellt eller serviceläge.

Exponerad person: operatör eller underhållspersonal.

Riskområde: cellens inre, särskilt utrymmet mellan gripdonet, detaljen och maskinens konstruktion.

Riskkälla: mekanisk energi från roboten, linjäraxeln eller det pneumatiska gripdonet.

Farlig situation: människan befinner sig i området samtidigt som rörelse fortfarande är möjlig.

Farlig händelse: oväntad axelrörelse, att gripdonet stängs eller att lagrad energi frigörs.

Möjlig följd: slag, klämning, fraktur eller amputation.

Först nu kan man bedöma risken och fastställa åtgärder för riskreducering.

Det kan behövas en förregling av skyddet.

Det kan behövas ett säkert stopp.

Det kan vara nödvändigt att förhindra oväntad start.

Det kan vara nödvändigt att avleda pneumatisk energi.

Det kan också vara så att rörelse i manuellt läge endast får ske med hålldonsanordning och säkert begränsad hastighet.

Detta är fortfarande en klassisk riskbedömning av maskinen.

Var kommer cybersäkerheten in?

Inte som en ny post vid sidan av mekaniska, elektriska och termiska faror.

“Hackern” är inte källan till en mekanisk fara

Att lägga till posten

Fara: cyberattack

i en ISO 12100-tabell tillför inte mycket.

En cyberattack är inte en roterande axel, en vass kant, hög temperatur eller pneumatisk energi.

Det är inte heller ett separat riskområde.

Operatören blir inte klämd av en CVE-sårbarhet.

Skadan orsakas av en maskindel som utförde en rörelse när människan befann sig på fel plats.

En cyberattack kan däremot förändra styrsystemets tillstånd, data, program, konfiguration eller hur en skyddsåtgärd fungerar.

Den kan alltså bli:

• orsaken till en farlig händelse,
• en ytterligare väg till en farlig situation,
• orsaken till att en riskreducerande åtgärd förlorar sin effektivitet,
• eller ett sätt att kringgå de antaganden som låg till grund för utformningen av säkerhetsfunktionerna.

Det är här den verkliga beröringspunkten finns.

Inte i listan över faror.

Utan i maskinens beteende.

Cybersäkerhetsanalysen bör tas fram separat

För en maskin eller ett automationssystem kommer cybersäkerhetsanalysen att ha en annan struktur än en riskbedömning enligt ISO 12100.

Den mest naturliga strukturen för ett industriellt automationssystem ges av IEC 62443-3-2.

Standarden kräver bland annat:

• att det system som ska analyseras definieras, alltså SUC,
• att systemet delas in i zoner och kommunikationskanaler,
• att risk bedöms för enskilda zoner och kanaler,
• att målsatta säkerhetsnivåer SL-T fastställs,
• att säkerhetskraven dokumenteras.

Det är en helt annan utgångspunkt än i ISO 12100.

I IEC 62443 frågar man bland annat:

Vad ingår exakt i det analyserade systemet?

Vilka tillgångar måste skyddas?

Vilka enheter, applikationer och gränssnitt finns i systemet?

Vilka delar bör tillhöra samma zon?

Hur sker kommunikationen mellan zonerna?

Vem kan få åtkomst?

Från vilken plats?

Via vilket gränssnitt?

Vilka sårbarheter kan utnyttjas?

Vilka data, funktioner eller komponenter kan ändras?

Vilken väg kan en angripare ta från serviceroutern till PLC, HMI, drivsystemet eller ingenjörsstationen?

Vilka konsekvenser får en förlust av konfidentialitet, integritet eller tillgänglighet?

Vilka skyddsåtgärder behövs?

För processen för säker produktutveckling och för kraven på själva komponenterna är även andra delar i serien relevanta, särskilt IEC 62443-4-1 och IEC 62443-4-2. IEC 62443-3-3 strukturerar däremot de tekniska säkerhetskraven på systemnivå.

CRA kräver i dag inte att tillverkaren skriver på analysens omslag att den “har utförts enligt IEC 62443”.

IEC 62443 ersätter inte heller att visa överensstämmelse med kraven i CRA.

För ett industriellt automationssystem är det dock en betydligt mer logisk referenspunkt än att försöka lägga till några hackerscenarier i en tabell enligt ISO 12100.

Det beror på att de två metoderna besvarar olika frågor.

ISO 12100:

Vid vilken uppgift, var, från vilken källa och till följd av vilken händelse kan en människa skadas?

IEC 62443:

Vem kan, via vilken väg och genom att utnyttja vilken sårbarhet, påverka systemet, dess data eller dess funktioner?

Först därefter behöver man kontrollera om svaret från den andra analysen förändrar scenariot i den första.

Samma scenario, två olika analyser

Låt oss återvända till operatören som tar bort en detalj som har fastnat.

Analysen enligt ISO 12100 visade att personen går in i en zon där han eller hon kan klämmas av robotens eller gripdonets rörelse.

Riskreducerande åtgärder är ett förreglat skydd, en funktion för säkert stopp samt en lokal återställning placerad utanför riskområdet.

Nu gör vi en cybersäkerhetsanalys av systemet.

Vi identifierar:

• router som används för fjärrservice,
• servicekonto,
• ingenjörslaptop,
• HMI,
• standard-PLC,
• safety PLC,
• drivsystem,
• programmeringsgränssnitt,
• PROFINET-nätverk och PROFIsafe-kommunikation,
• mekanismer för uppladdning av program och konfiguration.

Vi analyserar följande scenario:

Kapning av servicekontot möjliggör fjärråtkomst till standard-PLC:n och att ett rörelsekommando skickas medan en person befinner sig i cellen.

Leder detta scenario till en farlig händelse?

Det går inte att svara på enbart utifrån att PLC:n har tagits över.

Man måste kontrollera säkerhetsfunktionens arkitektur.

Om öppning av skyddet övervakas av safety PLC, funktionen säkert kopplar bort drivsystemens moment, återställning endast kan göras lokalt och standard-PLC:n inte kan återuppta rörelse oberoende av säkerhetsfunktionens status, kan ett övertagande av standardstyrningen stoppa produktionen eller störa processen.

Men det ska inte orsaka rörelse med skyddet öppet.

Då visar cyberanalysen att en attack har skett.

Maskinens riskbedömning visar en mekanisk fara.

En korrekt utformad säkerhetsfunktion bryter dock sambandet mellan dem.

Och nu den andra varianten.

Serviceläge väljs från ett vanligt HMI.

Värdet för begränsad hastighet kommer från standard-PLC:n.

Fjärrservicepersonal kan utföra återställning.

Samma ingenjörskonto gör det möjligt att ändra programmet i standardstyrningen och safety-konfigurationen.

Kopian av safety-programmet är inte kopplad till en specifik maskinversion.

Ingen kontrollerar kontrollsumman efter ingreppet.

Drivparametrar kan ändras på distans.

I denna arkitektur innebär ett kapat konto inte längre bara förlust av konfidentialitet eller ett kort driftstopp.

Det kan förändra de förutsättningar som riskreduceringen byggde på.

Det kan leda till:

• val av fel driftläge,
• ändring av en parameter för säker rörelse,
• obehörig återställning,
• uppladdning av en icke godkänd konfiguration,
• eller en försvagning av den funktion som skulle förhindra oväntad start.

Och då måste cyberscenariot kopplas till ett konkret scenario för maskinsäkerhet:

uppgiften att avlägsna ett stopp → person i riskområdet → obehörig ändring av styrsystemet eller skyddsfunktionen → oväntad rörelse → klämning.

Riskkällan har inte förändrats.

Det är fortfarande maskinens mekaniska energi.

Riskområdet har inte förändrats.

Det finns fortfarande inne i cellen.

Den möjliga konsekvensen har inte förändrats.

Det är fortfarande en skada på operatören.

Det som har förändrats är vägen fram till den farliga händelsen.

Alla sårbarheter hör inte hemma i ISO 12100

Den här skillnaden är lika viktig.

Anta att en sårbarhet i HMI gör det möjligt att läsa historiska produktionsdata.

Det kan vara ett väsentligt problem ur CRA:s perspektiv.

Det kan innebära ett brott mot datakonfidentialiteten.

Det kan kräva uppdatering, konsekvensbedömning, åtgärder gentemot användare och under vissa omständigheter även rapportering.

Men om det inte påverkar maskinens beteende, inte förändrar en skyddsåtgärd och inte kan leda till en farlig situation, finns det ingen mening med att pressa in det i riskbedömningen enligt ISO 12100.

På samma sätt kan en attack som enbart orsakar otillgänglighet i produktionsrapporter innebära ett affärsproblem och ett problem i förhållande till CRA.

Den behöver däremot inte skapa någon risk för operatören.

Å andra sidan kan en till synes harmlös möjlighet att ändra ett enda börvärde ha liten betydelse för datakonfidentialiteten, men mycket stor betydelse för den fysiska säkerheten.

Det gäller till exempel när värdet bestämmer:

• axelns maximala hastighet,
• presskraften,
• processtemperaturen,
• trycket,
• stoppunkten,
• ventilens öppningstid,
• eller den tillåtna gränsen vid arbete med öppet skydd.

Vi klassificerar alltså inte cyberhot utifrån hur tekniskt de låter.

Vi tittar på vad de faktiskt kan göra med maskinen.

Maskinförordningen kräver denna koppling

Denna koppling är inte bara god ingenjörspraxis.

Punkt 1.2.1 i bilaga III till maskinförordningen kräver att styrsystem ska vara konstruerade och utförda så att risksituationer förhindras, även till följd av rimligen förutsebara, illvilliga försök från tredje part.

CRA anger i sin tur att dess väsentliga cybersäkerhetskrav kan bidra till att visa överensstämmelse bland annat med kraven 1.1.9 och 1.2.1 i maskinförordningen.

Men det sker inte automatiskt.

Tillverkaren måste visa detta samband utifrån riskbedömningen. Bedömning av överensstämmelse enligt CRA och bedömning av överensstämmelse enligt maskinförordningen är fortfarande separata processer.

Det räcker alltså inte att ta fram:

• en riskbedömning enligt ISO 12100,
• en analys enligt IEC 62443,
• två separata rapporter,
• och hoppas att likheten i standardnumren ska skapa ett revisionsspår mellan dem.

Det krävs en koppling.

För varje relevant cyberscenario måste man fastställa:

1. vilken komponent eller funktion som kan tas över eller ändras,
2. vilket maskinbeteende detta kan orsaka,
3. om beteendet leder till en risksituation eller en farlig händelse,
4. vilken uppgift och vilken riskzon det gäller,
5. vilken möjlig konsekvens som har identifierats i ISO 12100-bedömningen,
6. vilken riskreducerande åtgärd som ska bryta scenariots utveckling,
7. om denna åtgärd fortfarande är effektiv efter att den angripna komponenten har tagits över.

Den sista punkten är den viktigaste.

För om attacken och skyddsåtgärden är beroende av:

• samma styrsystem,
• samma konto,
• samma nätverk,
• samma ingenjörsstation,
• eller samma program,

är det möjligt att vi inte har två oberoende skyddslager.

Vi har ett skyddslager som beskrivs i två dokument.

Vi behöver alltså inte en enda enorm tabell med namnet:

“riskbedömning safety & cybersecurity”.

Vi behöver två korrekta analyser, utförda med rätt metoder, samt en kontrollerad gränsyta mellan dem.

ISO 12100 ska beskriva människan, uppgiften, riskkällan, zonen, risksituationen, den farliga händelsen och den möjliga skadan.

IEC 62443 ska hjälpa till att beskriva systemet, dess zoner, kommunikationskanaler, tillgångar, hot, sårbarheter, attackvägar och nödvändiga skyddsåtgärder.

Och tillverkaren måste visa om scenariot i den andra analysen kan utlösa scenariot i den första eller göra den åtgärd verkningslös som skulle stoppa det.

En cyberattack behöver inte skapa en ny riskkälla. Det räcker att den öppnar en ny väg till en gammal olycka.

4. Ett pentest före FAT är en ögonblicksbild. CRA kräver en film

I många projekt kommer cybersäkerhet in två veckor före FAT.

Ett pentest beställs.

En rapport tas fram.

Kritiska sårbarheter åtgärdas, medelhöga accepteras, och dokumentet hamnar i projektmappen.

Maskinen är cybersäker.

Fram till nästa tisdag.

Ett pentest kan vara en mycket värdefull del av verifieringen. Men det visar tillståndet för en viss produktversion, i en viss konfiguration och med användning av bestämda testscenarier.

Det besvarar inte frågan om vad tillverkaren gör därefter.

Och CRA gäller under hela produktens livscykel. Riskbedömningen av cybersäkerhet ska påverka planering, konstruktion, utveckling, produktion, leverans och underhåll av produkten. Efter att den har släppts ut på marknaden måste tillverkaren hantera sårbarheter under den deklarerade supportperioden.

Låt oss återgå till grönsaksförpackningsmaskinen.

Maskinen har klarat FAT.

Pentestet visade inga kritiska sårbarheter.

Åtta månader senare publicerar tillverkaren av serviceroutern information om en sårbarhet som gör det möjligt att ta över enheten.

Och nu börjar det verkliga arbetet.

Vilka levererade maskiner har denna routermodell?

Vilken firmwareversion har installerats i varje exemplar?

Är fjärråtkomst aktiv?

Går sårbarheten att utnyttja i den faktiska konfigurationen?

Ger ett övertagande av routern tillgång enbart till diagnostik, eller även till HMI, PLC, drivenheter och safety PLC?

Är endast dataläsning möjlig, eller även ändring av program eller parametrar?

Kan attacken påverka säkerhetsfunktionen?

Har leverantören tillhandahållit en korrigering?

Kommer en uppdatering av routern att ändra certifikat, kommunikationsregler eller sättet som tunneln upprättas på?

Behöver fjärrservice, kommunikation och vissa säkerhetsfunktioner kontrolleras på nytt efter en uppdatering?

Vilka kunder ska informeras?

Och uppfyller situationen kriterierna för anmälan av en aktivt utnyttjad sårbarhet eller en allvarlig incident?

En pentestrapport som togs fram före FAT ger inget svar på någon av dessa frågor.

Den beskriver en maskin som inte längre finns.

För sedan testet genomfördes har programvaruversioner, konfigurationer, användarmiljö och kunskapen om sårbarheter förändrats.

Därför behöver tillverkaren inte bara ett test, utan en process:

• för att identifiera versioner av hårdvara, firmware och programvara i varje levererat exemplar,
• för att bevaka information om sårbarheter,
• för att bedöma hur de kan utnyttjas i den faktiska arkitekturen,
• för att kontrollera möjliga konsekvenser för processen och maskinens säkerhet,
• för att förbereda och testa uppdateringar,
• för att informera användare,
• för att dokumentera fattade beslut,
• för att hantera de anmälningar som krävs.

Från och med den 11 september 2026 är tillverkare skyldiga att rapportera aktivt utnyttjade sårbarheter och allvarliga incidenter som påverkar säkerheten hos produkter med digitala komponenter. En första varning ska lämnas inom 24 timmar och en fullständig anmälan inom 72 timmar.

Det innebär att när ett problem upptäcks finns det ingen tid att börja leta efter svar på frågor som:

“Vem var det egentligen som tillverkade den här routern, och var har vi listan över maskiner där vi byggde in den?”

IEC 62443-4-1 visar tydligt skillnaden mellan att säkra en produkt vid ett enskilt tillfälle och att ha en säker utvecklingscykel för produkten. Den omfattar inte bara konstruktion och verifiering, utan även hantering av fel, korrigeringar och produktens slut på livscykeln.

FAT kan alltså avsluta ett projektsteg.

Det avslutar inte produktens livscykel.

Det avslutar inte supportperioden.

Det innebär inte att övervakningen av sårbarheter upphör.

Och det betyder inte att konfigurationen från dagen för godkännandet fryses för de kommande femton åren.

Maskinen kan under lång tid packa grönsaker åt stormarknader.

Tillverkaren kan däremot inte packa in dess cybersäkerhet tillsammans med bruksanvisningen, plasta in allt och utgå från att det därmed har levererats en gång för alla.

Pentest kan bocka av en punkt på FAT-listan. CRA öppnar en process som pågår till slutet av produktens supportperiod.