CRA for maskinproducenter efter Kommissionens retningslinjer af 27. juli 2026. Hvad skal man reelt implementere?

I årevis kunne en maskines cybersikkerhed beskrives i tre trin: en mærkevare-PLC, VPN “fordi sådan gør man”, og den klassiske “kunden sikrer netværket”. Og hvis nogen ovenikøbet satte en firewall i tavlen, blev emnet ofte betragtet som afsluttet — i hvert fald indtil nogen forsøgte at undersøge, hvad der faktisk sker ved et reelt angreb og ikke kun i en præsentation.

Men cybersikkerhed flyder ikke gennem PROFINET. Komponenter kan have certifikater, erklæringer og “secure by design” i marketingmaterialet, men maskinen som helhed kan stadig være forudsigelig på en måde, der ikke har noget med sikkerhed at gøre. Ligesom et sikkerhedsrelæ ikke gør et system sikkert, hvis styrelogikken gør det muligt at omgå det, løser et “sikkert” HMI heller ikke problemer med arkitektur, integration, rettigheder, opdateringer og det, der sker, når nogen holder op med at bede om lov.

CRA (Cyber Resilience Act, Europa-Parlamentets og Rådets forordning (EU) 2024/2847) er ikke et tillæg for IT. Det er en produktregulering, som træder ind i maskinens livscyklus uden at spørge automationsafdelingen om lov. Den omfatter styringsdesign, risikoanalyse, forsyningskæde, konfiguration, opdateringer samt vedligeholdelse af produktet længe efter, at FAT er underskrevet, og maskinen har forladt produktionshallen. Og nej, argumentet “vi eksponerer den ikke mod internettet” lukker ikke sagen. I praksis er en servicebærbar, et USB-stik, fjerndiagnostik “for en kort stund” eller integration med et fabriksanlægssystem nok til, at grænsen mellem isolation og eksponering ophører med at eksistere.

Kommissionens retningslinjer af 27. juli 2026 ændrede ikke selve forordningen, men de indskrænkede effektivt det fortolkningsrum, som tidligere gjorde det muligt at behandle cybersikkerhed som et valgfrit lag. De præciserede bl.a. produktgrænsen, rollen for fjernbehandling, ansvaret for ændringer efter levering samt, at “det er ikke vores problem efter FAT” ikke længere er en sikker antagelse.

Den vigtigste ændring er dog mere grundlæggende: et cyberangreb er ikke længere kun en IT-hændelse, men bliver et scenarie, der påvirker maskinens funktionelle sikkerhed. Hvis en uautoriseret programændring kan forårsage aksebevægelse, omgåelse af en spærring, ændring af procesparametre eller tab af sikkerhedsfunktioner, taler vi ikke længere om en “netværkshændelse”. Vi taler om en potentielt ukontrolleret maskinadfærd — uanset om årsagen er en konfigurationsfejl, en sårbarhed i softwaren eller bevidst manipulation.

I den sammenhæng er en engangs-pentest før FAT ikke længere bevis på overensstemmelse, men blot et øjebliksbillede af systemets tilstand på et bestemt tidspunkt. CRA kræver en løbende tilgang: fra design over produktion og idriftsættelse til opdateringer, håndtering af sårbarheder, reaktion på hændelser og vedligeholdelse i den erklærede supportperiode.

I praksis betyder det et opgør med tankegangen “færdig = sikker” til fordel for “vedligeholdt = under kontrol”. Uden illusionen om, at en firewall i tavlen, VPN og et komponentcertifikat afslutter sagen. Og uden antagelsen om, at cybersikkerhed slutter i det øjeblik, afleveringsprotokollen er underskrevet.

I denne artikel gennemgår vi, hvad CRA-retningslinjerne reelt ændrer for producenter, integratorer og dem, der moderniserer maskiner — uden at reducere hele emnet til sloganet “lad os ændre adgangskoden og tilføje et afkrydsningsfelt for cybersecurity”.

1. For at en maskine ikke skulle være omfattet af CRA, skulle den næsten kun bestå af kontaktorer

I mange projekter afklares CRA’s anvendelsesområde med ét spørgsmål:

Bliver maskinen forbundet til internettet?

Det gør den ikke.

Så er sagen lukket.

På diagrammet er der en PLC, et HMI, flere drev, distribuerede ind- og udgange, en ventilø, en sikkerhedsscanner samt en port til indlæsning af programmet. PLC’en kommunikerer med panelet via PROFINET, udveksler styre- og statusord med drevene, og sensorerne sender data via IO-Link.

Men der er ingen router med SIM-kort.

Som bekendt bliver data først til data, når de forlader produktionshallen.

Men CRA spørger ikke, om maskinen har adgang til internettet.

Den spørger, om dens tilsigtede anvendelse eller rimeligt forudsigelige brug omfatter direkte eller indirekte, logisk eller fysisk dataforbindelse til en enhed eller et netværk. Det behøver ikke være en forbindelse til skyen, producentens server eller det offentlige internet. Den kan gå via kabel, radiobølger, en programgrænseflade eller som en del af et større system.

Og nu det afgørende spørgsmål: Hvad i en typisk maskine overfører faktisk data?

Læser HMI’et tilstande fra PLC’en og skriver setpunkter?

Sender PLC’en et styreord til drevet og modtager til gengæld hastighed, status og fejlkode?

Overfører ind-/udgangsøen procesbilledet?

Sender en IO-Link-sensor måleværdi, enhedsidentifikator og diagnostiske data?

Kommunikerer safety-PLC’en med moduler via PROFIsafe?

Indlæses program, hardwarekonfiguration eller firmware fra en servicebærbar?

Kan recepter, rapporter eller opdateringer overføres via USB?

Hvis svaret bare én gang er “ja”, er der sandsynligvis tale om en dataforbindelse.

Og det ændrer ikke på, at:

• maskinen arbejder i et lokalt netværk,
• den har ingen offentlig IP-adresse,
• Ethernet-porten bruges kun under idriftsættelse,
• det er kun service, der tilslutter en bærbar computer,
• kommunikationen foregår kun internt i styresystemet,
• kunden har lovet, at maskinen aldrig bliver koblet på internettet.

CRA omfatter ikke kun den brug, der i instruktionen er beskrevet som den tilsigtede, men også brug, som med rimelighed kan forudses. En serviceport holder derfor ikke op med at overføre data, bare fordi der på diagrammet står “SERVICE ONLY”.

Kommissionens retningslinjer af 27. juli 2026 indfører dog en vigtig sondring.

Ikke enhver ledning og ikke ethvert elektrisk signal er en dataforbindelse.

Hvis et signal udelukkende bruges til at aktivere, deaktivere eller forsyne en bestemt funktion og ikke overfører digitalt kodet information, er det forhold, at der findes to elektriske tilstande, i sig selv ikke nok til at anse det for en dataforbindelse.

En trykknap, der lægger spænding på kontaktorens spole, bliver ikke et digitalt interface, bare fordi dens tilstand kan beskrives som nul eller én.

Tilsvarende kan en klassisk endestopkontakt, der er indkoblet i et relæ-kontaktorkredsløb, kun bryde eller slutte kredsløbet. Den overfører ikke et enhedsnummer, en procesværdi, en diagnosekode, en firmwareversion eller et telegram med flere oplysninger.

Men når den samme tilstand når frem til en intelligent enhed, bliver kodet, sendt via en bus, koblet til diagnostik og fortolket af modtageren som information, ser situationen anderledes ud.

Grænsen går altså ikke mellem en “online” og en “offline” maskine.

Den går mellem et almindeligt styresignal og udveksling af digitalt kodet information.

Derfor ville en maskine, som kun skulle falde uden for CRA på grund af manglende dataforbindelse, i praksis skulle ligne et klassisk anlæg med trykknapper, endestop, relæer og kontaktorer mere end et moderne projekt, der åbnes i TIA Portal.

Det er naturligvis ikke en lovbestemt undtagelse for kontaktorer.

Man kan bygge en enkel maskine med PLC, som efter en detaljeret analyse ikke opfylder kriteriet for anvendelsesområdet. Man kan også tilføje en digital regulator, et serviceinterface eller et kommunikationsmodul til et kontaktoranlæg og dermed befinde sig præcis på den anden side af grænsen.

Komponentens navn afgør ikke sagen.

Det afgørende er, hvad produktet faktisk gør, og hvad det udveksler data med.

Før man svarer på, om en given maskine er omfattet af CRA, skal man derfor fastlægge:

• hvor grænsen for det vurderede produkt går,
• hvilke enheder og softwareelementer der indgår i det,
• hvilke fysiske og logiske interfaces det har,
• hvilke oplysninger der overføres gennem dem,
• hvilke forbindelser der er direkte, og hvilke der går via et større system,
• hvilke af dem der forekommer under normal drift, idriftsættelse, diagnostik, opdatering eller service,
• hvilke anvendelsesmåder der med rimelighed kan forudses, også selv om producenten helst ville lade være med at forudse dem.

Indtil vi har besvaret disse spørgsmål, ved vi ikke, om maskinen falder uden for CRA’s anvendelsesområde.

Vi har højst en bekvem sætning:

“Maskinen er ikke tilsluttet internettet”.

Problemet er bare, at det er et svar på et spørgsmål, som CRA ikke stiller.

PROFINET er ikke internettet. For CRA behøver det slet ikke at være det.

2. Cybersikkerhed spreder sig ikke via PROFINET

I mange projekter begynder spørgsmålet om maskinens overensstemmelse allerede i indkøbsfasen.

PLC fra en anerkendt producent.
HMI med opdateret firmware.
Administrerbar switch.
Industriel router med VPN.
Drev med sikkerhedsfunktioner.
Safety PLC med det rette certifikat.

Til hver enhed følger en overensstemmelseserklæring, en instruktion og nogle dokumenter med ordene “secure”, “encrypted” og “defence in depth”.

På diagrammet ser alt professionelt ud.

Alligevel ved man stadig ikke, om den komplette maskine er cybersikker.

For cybersikkerhed “følger” ikke med over PROFINET.

Det er lidt som med en dørlås:
du kan have en meget god lås i hvert rum, certificeret, testet, med flot dokumentation og et hologram med “secure”, men det garanterer stadig ikke sikkerhed, hvis nogen har ladet hoveddøren stå på vid gab “fordi det gik hurtigere under idriftsættelsen”.

Og præcis sådan er det også her: Komponenterne kan være eksemplariske, og systemet kan alligevel være … kreativt åbent.

PLC’en “overfører” ikke sikkerhed til HMI’et.
En firewall “retter” ikke applikationslogikken.
En switch “ordner” ikke brugeradgangen.
Og det forhold, at hvert enkelt element har et certifikat, betyder stadig ikke, at hele maskinen ikke er én stor, høfligt dokumenteret sårbarhed.

PROFINET overfører data.

Det overfører ikke ansvar.
Og desværre overfører det heller ikke sund fornuft.

CRA omfatter både komplette produkter og komponenter, der bringes i omsætning separat. Det betyder, at en styring, et operatørpanel eller et kommunikationsmodul kan vurderes særskilt. Men maskinproducenten skal stadig kunne dokumentere, at helheden fungerer sikkert i den reelle konfiguration hos kunden — altså i den version, hvor nogen “helt sikkert ikke har ændret mere … vel?”.

Og her opstår den mest almindelige fejl.

Det er præcis den samme mekanisme, som vi i årevis har kendt fra maskinsikkerhed.

Lysgitteret har PL e.
Safety PLC har SIL 3.
Drevet har STO.

Betyder det så, at hele maskinen automatisk er på samme niveau?

Det svarer til, at det forhold, at hver enkelt del af et stillads opfylder sikkerhedsstandarderne, stadig ikke garanterer, at hele konstruktionen er stabil.

Nej.

For man skal stadig kontrollere, hvordan det hele fungerer sammen — altså det mindre populære trin med “systemtænkning”, som desværre ikke har en “auto-certify”-knap.

Præcis det samme gælder inden for cybersikkerhed.

Du kan have “sikre” komponenter, men i praksis:

• operatøren kan se og ændre flere data end nødvendigt, fordi “det var nemmere sådan”,
• det samme servicekodeord virker på alle maskiner, fordi “service ved jo godt, hvad de laver”,
• serviceporten er tilgængelig “for en sikkerheds skyld”, altså til enhver tænkelig situation,
• fjernadgang omfatter hele netværket, fordi nogen engang sagde: “det er jo kun til diagnostik”,
• opdateringer kan installeres uden kontrol, fordi “der er aldrig gået noget galt før”,
• enhederne “stoler på hinanden” uden begrænsninger, fordi tillid er billigere end segmentering,
• og integrationen bygger på, at ingen nogensinde begår fejl, hvilket — som historien viser — er den mest optimistiske antagelse i ingeniørarbejde.

Hver enkelt komponent kan isoleret set være korrekt.

Men systemet som helhed kan sammensætte disse korrekte komponenter til noget, der fungerer … bare ikke nødvendigvis sådan, som det var tænkt.

Og det er det vigtige: risikoen ligger ikke i enhederne alene, men i deres samspil, konfiguration og den legendariske adgang, der “midlertidigt blev ladt stå åben”.

CRA kræver, at maskinproducenten gør mere end blot at samle erklæringer som trofæer. Det kræver, at man verificerer, om det, der er sammensat af komponenter, stadig er sikkert som helhed — og ikke kun “ser pænt ud i en compliance-tabel”.

I praksis betyder det enkle, forretningsmæssige spørgsmål:

• har hver bruger kun den adgang, der reelt er nødvendig, og ikke bare “fordi det måske kan blive nyttigt en dag”,
• er fjernadgang begrænset til det nødvendige minimum, eller snarere til maksimal bekvemmelighed,
• har service ikke “fulde rettigheder overalt”, fordi nogen mente, at det gjorde livet lettere,
• er netværket ikke én fælles flade, fordi segmentering “gør projektet mere kompliceret”,
• er opdateringer kontrollerede, eller er det snarere “vi lægger dem ind og håber på det bedste”,
• kan man hurtigt identificere, hvilke maskiner der er eksponerede, eller er tilgangen snarere “det tjekker vi efter hændelsen”,
• åbner fejl i én komponent ikke hele systemet, fordi “det endte sådan i integrationen”.

Det er ikke tekniske spørgsmål “for ingeniører, der arbejder med de svære ting”.

Det er spørgsmål om forretningsrisiko: nedetid, omkostninger, ansvar og den lille detalje, at produktionen faktisk skal køre.

Derfor er det ikke nok at sige:

“alle komponenter er i overensstemmelse”

For det besvarer stadig ikke spørgsmålet:

er hele maskinen sikker i reel brug, eller kun i PowerPointen fra projektgennemgangen?

Leverandørens erklæring er vigtig.

Men den vedrører kun ét enkelt element — det, der faktisk blev testet under laboratorieforhold, og ikke i et miljø “ude i hallen, med VPN, USB og tidspres”.

Den omfatter ikke, hvordan det er blevet anvendt.
Den omfatter ikke konfigurationen.
Den omfatter ikke integrationen.
Den omfatter ikke beslutninger truffet “i hast under idriftsættelsen, fordi kunden ventede”.
Den omfatter ikke det, der sker efter mange års drift, når ingen længere kan huske, hvorfor noget blev “midlertidigt holdt åbent”.

Derfor kan vurderingen ikke stoppe ved en liste over enheder.

Man er nødt til at se på systemet som helhed:

• hvem har adgang, og hvorfor (ikke bare “fordi de altid har haft det”),
• hvad er reelt nødvendigt, og hvad er bare “blevet stående, fordi det ikke generede nogen”,
• hvor data kan slippe ud af kontrol, fordi nogen mente, at “det er jo kun diagnostik”,
• hvad der sker, hvis nogen bruger legitim adgang på en illegitim måde (altså præcis sådan, angreb gør),
• hvor hurtigt man kan reagere, når der opstår et problem, og ikke først “efter det kvartalsvise review”.

Så længe der ikke er svar på de spørgsmål, har vi kun et sæt meget ordentlige komponenter.

Vi har endnu ikke en sikker maskine.

Overensstemmelse på komponentniveau skaber ikke automatisk overensstemmelse på systemniveau. Maskinens overensstemmelse skal designes, verificeres og — det sværeste af det hele — opretholdes trods fristelsen til “ikke at røre mere ved det, for det virker”.

3. Sæt ikke cyberangreb på listen over farer som et ekstra punkt. Kobl de to analyser sammen det rigtige sted

På maskinmarkedet er en formel cybersikkerhedsrisikoanalyse stadig snarere undtagelsen end et standardelement i projektet.

Der er som regel en industriel router.

Der er VPN.

Der er et kodeord til PLC’en.

Nogle gange er der en administrerbar switch, som ingen bagefter administrerer.

I den mere ambitiøse version får producenten en præsentation fra leverandøren om “defence in depth” og konkluderer, at analysen af hele maskinens cybersikkerhedsrisiko dermed er afsluttet.

Det er den ikke.

Man har købt nogle få tekniske foranstaltninger.

Det er endnu ikke en analyse.

Derfor giver det ikke mening at beskrive problemet, som om der i hvert projekt blev udarbejdet to professionelle vurderinger — én efter ISO 12100, og én om cybersikkerhed — som blot tilfældigvis ikke blev koblet sammen.

Oftest bliver der kun udarbejdet én.

Maskinens risikovurdering.

Og der bliver slet ikke udarbejdet nogen cybersikkerhedsanalyse af produktet.

En maskinrisikovurdering efter ISO 12100 handler ikke om at skrive følgende i en tabel:

fejl på sensor → uventet bevægelse → klemning.

Det kan være et element i et konkret scenarie, men det er ikke udgangspunktet.

Først skal maskinens begrænsninger fastlægges.

Hvad er dens tilsigtede anvendelse?

Hvilke faser indgår i livscyklussen?

Hvem skal bruge den?

Hvilke opgaver skal udføres under transport, montering, idriftsættelse, produktion, justering, rengøring, afhjælpning af blokeringer, vedligeholdelse, diagnostik og demontering?

I hvilke driftstilstande kan maskinen arbejde?

Hvor befinder personen sig under hver af disse operationer?

Hvilke dele af maskinen er da fortsat spændingssatte, under tryk, belastede eller i bevægelse?

Hvilken brug er ikke i overensstemmelse med instruktionen, men stadig rimeligt forudsigelig?

Først derefter identificerer man for den konkrete opgave eller operation blandt andet:

• farekilden,
• typen af fare,
• farezonen,
• den eksponerede person,
• faresituationen,
• den farlige hændelse, hvis den forekommer i det pågældende scenarie,
• mulige konsekvenser og typen af skade.

Det er sådan, en maskinrisikoanalyse ser ud.

Man starter ikke med komponenten.

Man starter med den person, der udfører en bestemt opgave ved en maskine i en bestemt tilstand. ISO 12100 fastlægger netop en sådan metode til identifikation af farer samt estimering og evaluering af risiko i de relevante faser af maskinens livscyklus.

Lad os tage et enkelt eksempel.

Operatøren fjerner et fastklemt emne inde i en palleteringscelle.

Vi har altså:

Opgave: afhjælpning af blokering.

Brugsfase: drift, indgreb efter stop af processen.

Driftstilstand: manuel eller service.

Eksponeret person: operatør eller vedligeholdelsestekniker.

Farezone: cellens indre, især området mellem griberen, emnet og maskinens konstruktion.

Farekilde: mekanisk energi fra robotten, den lineære akse eller den pneumatiske griber.

Faresituation: personen befinder sig i zonen, mens det stadig er muligt at udføre en bevægelse.

Farlig hændelse: uventet bevægelse af en akse, lukning af griberen eller frigivelse af oplagret energi.

Mulig konsekvens: slagpåvirkning, klemning, brud eller amputation.

Først nu kan man vurdere risikoen og fastlægge foranstaltninger til risikoreduktion.

Det kan være nødvendigt med låsning af afskærmningen.

Det kan være nødvendigt med sikkert stop.

Det kan være nødvendigt at forhindre uventet opstart.

Det kan være nødvendigt at aflede pneumatisk energi.

Det kan være, at bevægelse i manuel tilstand kun må ske med holdekørselsanordning og sikkert begrænset hastighed.

Det er stadig en klassisk risikoanalyse i henhold til ISO 12100.

Hvor kommer cybersikkerhed så ind?

Ikke som en ny post ved siden af mekaniske, elektriske og termiske farer.

“Hackeren” er ikke kilden til en mekanisk fare

At tilføje følgende post i en ISO 12100-tabel:

Fare: cyberangreb

bidrager kun i begrænset omfang.

Et cyberangreb er ikke en roterende aksel, en skarp kant, høj temperatur eller pneumatisk energi.

Det er heller ikke en særskilt farezone.

Operatøren bliver ikke klemt af en CVE-sårbarhed.

Vedkommende bliver klemt af en maskindel, som udførte en bevægelse, mens personen befandt sig det forkerte sted.

Et cyberangreb kan derimod ændre styresystemets tilstand, data, program, konfiguration eller beskyttelsesforanstaltningens funktionsmåde.

Det kan derfor blive:

• årsag til en farlig hændelse,
• en ekstra vej til en faresituation,
• årsag til tab af effektiviteten af en risikoreducerende foranstaltning,
• eller en måde at omgå de forudsætninger, der blev lagt til grund ved design af sikkerhedsfunktionen.

Og det er det rigtige berøringspunkt.

Ikke listen over farer.

Maskinens adfærd.

Cybersikkerhedsanalysen bør udarbejdes separat

For en maskine eller et automationssystem vil en cybersikkerhedsanalyse have en anden struktur end en risikovurdering efter ISO 12100.

Den mest naturlige ramme for et industrielt automationssystem leveres af IEC 62443-3-2.

Standarden kræver blandt andet:

• definition af det system, der er omfattet af analysen, altså SUC,
• opdeling af systemet i zoner og kommunikationskanaler,
• risikovurdering for de enkelte zoner og kanaler,
• fastlæggelse af målrettede sikkerhedsniveauer SL-T,
• dokumentation af sikkerhedskrav.

Det er et helt andet udgangspunkt end i ISO 12100.

I IEC 62443 spørger man blandt andet:

Hvad hører præcist til det analyserede system?

Hvilke aktiver skal beskyttes?

Hvilke enheder, applikationer og grænseflader findes i systemet?

Hvilke elementer bør høre til den samme zone?

Hvordan foregår kommunikationen mellem zonerne?

Hvem kan få adgang?

Fra hvilket sted?

Ved brug af hvilken grænseflade?

Hvilke sårbarheder kan udnyttes?

Hvilke data, funktioner eller komponenter kan ændres?

Hvilken vej kan en angriber tage fra servicerouteren til PLC, HMI, drev eller ingeniørstation?

Hvilke konsekvenser vil tab af fortrolighed, integritet eller tilgængelighed have?

Hvilke beskyttelsesforanstaltninger er nødvendige?

For processen for sikker produktudvikling og kravene til selve komponenterne er andre dele af serien også relevante, især IEC 62443-4-1 og IEC 62443-4-2. IEC 62443-3-3 systematiserer derimod de tekniske sikkerhedskrav på systemniveau.

CRA kræver i dag ikke, at producenten skriver på forsiden af analysen “udarbejdet i overensstemmelse med IEC 62443”.

IEC 62443 erstatter heller ikke dokumentation for overensstemmelse med kravene i CRA.

For et industrielt automationssystem er det dog et langt mere logisk referencepunkt end at forsøge at føje nogle få hackerscenarier til en ISO 12100-tabel.

For de to metoder besvarer forskellige spørgsmål.

ISO 12100:

Under hvilken opgave, hvor, fra hvilken kilde og som følge af hvilken hændelse kan et menneske komme til skade?

IEC 62443:

Hvem kan via hvilken vej og ved udnyttelse af hvilken sårbarhed påvirke systemet, dets data eller funktioner?

Først derefter skal man kontrollere, om svaret fra den anden analyse ændrer scenariet i den første.

Samme scenarie, to forskellige analyser

Lad os vende tilbage til operatøren, der fjerner et fastklemt emne.

Risikovurderingen efter ISO 12100 viste, at personen går ind i en zone, hvor vedkommende kan blive klemt af robotten eller griberen i bevægelse.

Risikoreduktionen består af et låsbart værn, en sikker stopfunktion og en lokal reset placeret uden for farezonen.

Nu udfører vi en cybersikkerhedsanalyse af systemet.

Vi identificerer:

• routeren, der bruges til fjernservice,
• servicekontoen,
• den bærbare ingeniør-pc,
• HMI,
• standard-PLC,
• safety PLC,
• drev,
• programmeringsgrænsefladen,
• PROFINET-netværket og PROFIsafe-kommunikationen,
• mekanismerne til upload af program og konfiguration.

Vi ser på følgende scenarie:

Overtagelse af servicekontoen giver fjernadgang til standard-PLC’en og mulighed for at sende en bevægelseskommando, mens der befinder sig en person i cellen.

Fører dette scenarie til en farlig hændelse?

Det kan ikke besvares alene ud fra det forhold, at PLC’en er kompromitteret.

Man skal kontrollere sikkerhedsfunktionens arkitektur.

Hvis åbning af værnet overvåges af safety PLC’en, funktionen sikkert afbryder drevenes moment, reset kun kan udføres lokalt, og standard-PLC’en ikke kan genoprette bevægelse uafhængigt af sikkerhedsfunktionens tilstand, kan overtagelse af standard-styringen stoppe produktionen eller skade processen.

Men det bør ikke forårsage bevægelse med åbent værn.

I så fald påviser cyberanalysen et angreb.

Maskinens risikovurdering påviser en mekanisk fare.

En korrekt konstrueret sikkerhedsfunktion afskærer imidlertid forbindelsen mellem de to.

Og nu den anden variant.

Servicetilstand vælges fra et almindeligt HMI.

Værdien for begrænset hastighed kommer fra standard-PLC’en.

Fjernserviceteknikeren kan udføre reset.

Den samme ingeniørkonto gør det muligt at ændre både standardprogrammet og safety-konfigurationen.

Kopien af safety-programmet er ikke knyttet til en bestemt maskinversion.

Ingen kontrollerer checksummen efter indgrebet.

Drevparametre kan ændres eksternt.

I denne arkitektur betyder overtagelse af kontoen ikke længere kun tab af fortrolighed eller et kort driftsstop.

Det kan ændre de forudsætninger, som risikoreduktionen byggede på.

Det kan føre til:

• valg af forkert tilstand,
• ændring af parameteren for sikker bevægelse,
• uautoriseret reset,
• upload af en ikke-godkendt konfiguration,
• eller svækkelse af den funktion, der skulle forhindre uventet opstart.

Og så skal cyberscenariet kobles til et konkret scenarie for maskinsikkerhed:

opgaven med at fjerne en blokering → person i farezonen → uautoriseret ændring af styresystemet eller beskyttelsesfunktionen → uventet bevægelse → klemning.

Farekilden har ikke ændret sig.

Det er stadig maskinens mekaniske energi.

Farezonen har ikke ændret sig.

Den befinder sig stadig inde i cellen.

Den mulige konsekvens har ikke ændret sig.

Det er stadig skade på operatøren.

Det, der har ændret sig, er vejen frem til den farlige hændelse.

Ikke enhver sårbarhed hører hjemme i ISO 12100

Denne sondring er lige så vigtig.

Lad os antage, at en sårbarhed i HMI gør det muligt at læse historiske produktionsdata.

Det kan være et væsentligt problem set i forhold til forordning (EU) 2024/2847 (CRA).

Det kan krænke datafortroligheden.

Det kan kræve en opdatering, en vurdering af påvirkningen, handling over for brugerne og under bestemte omstændigheder også rapportering.

Men hvis det ikke påvirker maskinens adfærd, ikke ændrer en beskyttelsesforanstaltning og ikke kan føre til en faresituation, giver det ingen mening at presse det ind i risikovurderingen efter ISO 12100.

På samme måde kan et angreb, der kun medfører utilgængelige produktionsrapporter, være et forretningsmæssigt problem og et problem i forhold til overholdelse af CRA.

Det behøver dog ikke at skabe en risiko for operatøren.

Omvendt kan en tilsyneladende uskyldig mulighed for at ændre én enkelt setværdi have begrænset betydning for datakonfidentialiteten, men enorm betydning for den fysiske sikkerhed.

For eksempel når værdien fastlægger:

• maksimal aksehastighed,
• preskraft,
• procestemperatur,
• tryk,
• stopposition,
• ventilens åbningstid,
• eller den tilladte grænse ved drift med åbent værn.

Vi klassificerer derfor ikke cybertrusler ud fra, hvor teknisk de lyder.

Vi ser på, hvad de reelt kan gøre ved maskinen.

Maskinforordningen kræver denne bro

Denne kobling er ikke kun god ingeniørpraksis.

Punkt 1.2.1 i bilag III til maskinforordningen kræver, at styresystemer projekteres og udføres, så der forebygges farlige situationer, også som følge af rimeligt forudsigelige, ondsindede handlinger fra tredjeparter.

CRA angiver til gengæld, at dets væsentlige cybersikkerhedskrav kan understøtte dokumentation for overensstemmelse blandt andet med kravene 1.1.9 og 1.2.1 i maskinforordningen.

Men det sker ikke automatisk.

Producenten skal dokumentere denne sammenhæng på grundlag af risikovurderingen. Overensstemmelsesvurdering efter CRA og overensstemmelsesvurdering efter maskinforordningen er fortsat to adskilte processer.

Det er altså ikke nok at udarbejde:

• en risikovurdering efter ISO 12100,
• en IEC 62443-analyse,
• to separate rapporter,
• og håbe, at ligheden i standardnumrene skaber et auditspor mellem dem.

Der skal være en kobling.

For hvert væsentligt cyberscenarie skal det fastlægges:

1. hvilken komponent eller funktion der kan overtages eller ændres,
2. hvilken maskinadfærd det kan udløse,
3. om adfærden fører til en farlig situation eller en farlig hændelse,
4. hvilken opgave og hvilken farezone det vedrører,
5. hvilken mulig konsekvens der er identificeret i ISO 12100-vurderingen,
6. hvilken risikoreducerende foranstaltning der skal afbryde udviklingen af scenariet,
7. om denne foranstaltning fortsat er effektiv, efter at den angrebne komponent er blevet overtaget.

Det sidste punkt er det vigtigste.

For hvis angrebet og beskyttelsen afhænger af:

• den samme controller,
• den samme konto,
• det samme netværk,
• den samme engineering-station,
• eller det samme program,

så har vi måske ikke to uafhængige beskyttelseslag.

Så har vi ét lag, beskrevet i to dokumenter.

Vi har derfor ikke brug for én enorm tabel med navnet:

“safety & cybersecurity-risikovurdering”.

Vi har brug for to korrekte analyser, udført med de rette metoder, samt et kontrolleret berøringspunkt mellem dem.

ISO 12100 skal beskrive mennesket, opgaven, farekilden, zonen, den farlige situation, den farlige hændelse og den mulige skade.

IEC 62443 skal hjælpe med at beskrive systemet, dets zoner, kommunikationskanaler, aktiver, trusler, sårbarheder, angrebsveje og nødvendige beskyttelsesforanstaltninger.

Og producenten skal dokumentere, om scenariet fra den anden analyse kan udløse scenariet fra den første eller fjerne effektiviteten af den foranstaltning, der skulle stoppe det.

Et cyberangreb behøver ikke at skabe en ny fare. Det er nok, at det åbner en ny vej til en gammel ulykke.

4. En pentest før FAT er et øjebliksbillede. CRA kræver en film

I mange projekter dukker cybersikkerhed op to uger før FAT.

Der bestilles en pentest.

Der udarbejdes en rapport.

Kritiske sårbarheder bliver rettet, mellemrisici accepteret, og dokumentet havner i projektmappen.

Maskinen er cybersikker.

Indtil næste tirsdag.

En pentest kan være et meget værdifuldt element i verifikationen. Men den viser tilstanden for en konkret produktversion, i en konkret konfiguration og med brug af bestemte testscenarier.

Den besvarer ikke spørgsmålet om, hvad producenten gør bagefter.

Og CRA gælder for hele produktets livscyklus. Risikovurderingen af cybersikkerhed skal påvirke planlægning, projektering, udvikling, produktion, levering og vedligeholdelse af produktet. Efter markedsføringen skal producenten håndtere sårbarheder i den erklærede supportperiode.

Lad os vende tilbage til grøntsagspakkemaskinen.

Maskinen har bestået FAT.

Pentesten viste ingen kritiske sårbarheder.

Otte måneder senere offentliggør producenten af servicerouteren information om en sårbarhed, der gør det muligt at overtage enheden.

Og nu begynder det egentlige arbejde.

Hvilke leverede maskiner har denne routermodel?

Hvilken firmwareversion er installeret i hvert enkelt eksemplar?

Er fjernadgang aktiv?

Kan sårbarheden udnyttes i den faktiske konfiguration?

Giver overtagelse af routeren kun adgang til diagnostik, eller også til HMI, PLC, drev og safety PLC?

Er kun datalæsning mulig, eller også ændring af program eller parametre?

Kan angrebet påvirke sikkerhedsfunktionen?

Har leverandøren stillet en rettelse til rådighed?

Vil en opdatering af routeren ændre certifikater, kommunikationsregler eller måden, tunnelen etableres på?

Skal fjernservice, kommunikation og dele af sikkerhedsfunktionerne kontrolleres igen efter en opdatering?

Hvilke kunder skal underrettes?

Og opfylder situationen kriterierne for anmeldelse af en aktivt udnyttet sårbarhed eller en alvorlig hændelse?

En pentest-rapport udført før FAT giver ikke svar på nogen af disse spørgsmål.

Den beskriver en maskine, som ikke længere findes i den form.

For siden testen er softwareversioner, konfigurationer, brugerens miljø og viden om sårbarheder blevet ændret.

Derfor har producenten ikke kun brug for en test, men for en proces:

• identifikation af hardware-, firmware- og softwareversioner i hvert leveret eksemplar,
• overvågning af oplysninger om sårbarheder,
• vurdering af deres udnyttelse i den faktiske arkitektur,
• kontrol af mulige konsekvenser for processen og maskinens sikkerhed,
• forberedelse og test af opdateringer,
• information til brugerne,
• dokumentation af de beslutninger, der er truffet,
• håndtering af de krævede anmeldelser.

Fra 11. september 2026 er producenter forpligtet til at rapportere aktivt udnyttede sårbarheder og alvorlige hændelser, der påvirker sikkerheden i produkter med digitale elementer. En indledende advarsel skal sendes inden for 24 timer, og den fulde anmeldelse inden for 72 timer.

Det betyder, at når problemet først er opdaget, er der ikke tid til at begynde eftersøgningen:

“Hvem var det egentlig, der lavede den router, og hvor har vi listen over de maskiner, vi satte den i?”

IEC 62443-4-1 viser tydeligt forskellen mellem en engangssikring af et produkt og en sikker udviklingslivscyklus. Den omfatter ikke kun design og verifikation, men også håndtering af fejl, rettelser og produktets end-of-life.

FAT kan derfor afslutte projektfasen.

Den afslutter ikke produktets livscyklus.

Den afslutter ikke supportperioden.

Den afslutter ikke overvågningen af sårbarheder.

Og den betyder ikke, at konfigurationen på overtagelsesdagen er fastfrosset de næste femten år.

Maskinen kan i lang tid pakke grøntsager til supermarkeder.

Men producenten kan ikke pakke dens cybersikkerhed sammen med manualen, forsegle det i folie og antage, at det er leveret én gang for alle.

En pentest kan lukke et punkt på FAT-listen. CRA åbner en proces, der varer til udløbet af produktets supportperiode.