Cybersäkerhet för maskintillverkare

Från 2027 omfattas en maskin med styrsystem, förardisplay eller dataanslutning av två EU-förordningar. Båda utgår från samma fråga: vilken programvara finns på den här maskinen, version för version, och vad innehåller den?

1. 11 september 2026Cyber Resilience Acts rapportering av aktivt utnyttjade sårbarheter och allvarliga incidenter börjar gälla.
2. 20 januari 2027Maskinförordningen, (EU) 2023/1230, börjar gälla och ersätter maskindirektivet.
3. 11 december 2027Cyber Resilience Act, (EU) 2024/2847, gäller i sin helhet.

Maskinförordningen

Två väsentliga hälso- och säkerhetskrav i bilaga III handlar om cybersäkerhet:

• 1.1.9, skydd mot förvanskning. Att ansluta en annan enhet till maskinen, direkt eller på distans, får inte leda till en farlig situation. Programvara och data som är kritiska för att maskinen ska uppfylla de väsentliga hälso- och säkerhetskraven ska identifieras och skyddas mot oavsiktlig eller avsiktlig förvanskning. Maskinen ska identifiera den programvara som är installerad på den och som behövs för att den ska fungera säkert, och alltid kunna tillhandahålla den informationen. Den ska också samla in bevis på legitima eller illegitima ingrepp i programvaran eller dess konfiguration.
• 1.2.1, styrsystemens säkerhet och tillförlitlighet. Styrsystem ska stå emot rimligen förutsebara illasinnade försök från tredje part som leder till en farlig situation. Enligt 1.2.1(f) ska de föra en spårningslogg över ingrepp och över de versioner av säkerhetsprogramvara som laddats upp efter att maskinen släppts ut på marknaden, i fem år efter uppladdningen.

Cyber Resilience Act

En maskin med dataanslutning, eller en del av den som säljs separat, är en produkt med digitala element. Tillverkaren ska iaktta tillbörlig aktsamhet med de tredjepartskomponenter den integrerar, upprätta en SBOM som åtminstone omfattar beroendena på högsta nivån, hantera sårbarheter under supportperioden, som är minst fem år om inte produkten förväntas användas kortare tid, och bevara den tekniska dokumentationen i minst tio år eller under supportperioden, beroende på vilket som är längst.

Inte automatiskt. Cyber Resilience Act ger ingen presumtion om överensstämmelse med maskinförordningen. Enligt skäl 53 kan uppfyllandet av CRA:s väsentliga krav underlätta efterlevnaden av maskinförordningens krav på skydd mot förvanskning och på styrsystemens säkerhet och tillförlitlighet. Där står också att tillverkaren måste visa detta, till exempel genom att tillämpa harmoniserade standarder efter en riskbedömning, och att båda förordningarnas förfaranden för bedömning av överensstämmelse fortfarande gäller.

Den harmoniserade standard som tas fram för 1.1.9 är EN 50742, Safety of machinery – Protection against corruption. I november 2026 var den ett slutligt utkast, FprEN 50742, som omfattar 1.1.9 och de tillhörande punkterna i 1.2.1, och så länge hänvisningen till en slutlig version inte har offentliggjorts i Europeiska unionens officiella tidning ger den ingen presumtion om överensstämmelse. Den kombinerar riskbedömningen i EN ISO 12100 med säkerhetsbegrepp från IEC 62443 och godtar en konsekvent tillämpning av IEC 62443-4-1, IEC 62443-3-3 och IEC 62443-4-2 som ett likvärdigt sätt att nå skyddsmålen. IEC 62443-4-2 anger de tekniska säkerhetskraven för komponenter i styrsystem, graderade efter security capability level. I Tyskland omsätter provningsprinciperna GS-IFA-M25 från juli 2026 skyddet mot förvanskning i 66 provningskriterier, med begreppen från prEN 50742. Ett av dem, T46, kräver att produkten på begäran kan ange sin installerade programvaruversion och konfiguration. För att kunna svara på det för varje konfiguration behövs en registrering av vad varje programvaruversion innehåller.

Maskinförordningen har en egen presumtion, och den går en annan väg: EU-ordningar för cybersäkerhetscertifiering som antagits enligt cybersäkerhetsakten, förordning (EU) 2019/881. Ett certifikat eller en försäkran om överensstämmelse enligt en sådan ordning ger presumtion om överensstämmelse med 1.1.9 och 1.2.1 i den mån det täcker de kraven.

En riskbedömning och ett och samma underlag kan alltså tjäna båda förordningarna, men du visar överensstämmelse med var och en. Har din maskin en dataanslutning, planera för båda. Underlaget om programvaran, det vill säga SBOM:er, sårbarhetsregistreringar och uppdateringshistoriken, är den del de har gemensamt.

I januari 2026 bad maskinindustrins branschorganisationer om att 1.1.9 och 1.2.1(f) skulle skjutas upp, och i mars 2026 om att de skulle gälla från CRA:s datum, den 11 december 2027. Det är en begäran, inte lag: i november 2026 hade inget uppskov antagits. Datumen på den här sidan är datumen i förordningarna.

• Bygg-, materialhanterings-, gruv- och industrimaskiner omfattas av maskinförordningen, och även av CRA när maskinen eller dess delar har en dataanslutning.
• Jordbruks- och skogsbrukstraktorer som omfattas av förordning (EU) nr 167/2013 är undantagna från maskinförordningen, utom maskiner som är monterade på dem. CRA:s lista över undantag nämner inte den förordningen, så en uppkopplad traktor kan omfattas av CRA.
• Vägfordon som är typgodkända enligt förordning (EU) 2019/2144 är undantagna från CRA.
• Komponenter som säljs separat. CRA gäller också programvaru- och hårdvarukomponenter som släpps ut på marknaden separat. En leverantör som säljer en ECU eller en telematikenhet separat är själv tillverkare enligt CRA. När enheten bara byggs in i maskinen bär maskintillverkaren skyldigheten för hela maskinen och ska iaktta tillbörlig aktsamhet med leverantörens komponent.

Detta är allmän information, inte juridisk rådgivning. Kontrollera klassificeringen av din egen produkt.

I en och samma maskin kommer programvaran från olika håll, och bara teamet som bygger en viss programvara kan säga tillförlitligt vad den innehåller. Enligt vad vi hör från maskintillverkare innehåller ECU:er utan operativsystem lite öppen källkod, medan programvara för Linux, Android och Windows innehåller mycket.

Små volymer, stor variation. En maskintillverkare kan ha hundratals plattformar på marknaden, sälja en handfull enheter av varje per år och konfigurera många maskiner på order. Varje konfiguration är en egen uppsättning programvara, så en SBOM för varje bygge är viktigare än en SBOM för varje produktlinje.

Lång livslängd. Maskiner är i drift i tio år eller mer, medan leverantörer byts ut eller går i konkurs. Registreringen av vad som gick in i en programvaruversion måste göras när den byggs, eftersom den inte går att rekonstruera flera år senare.

Leverantörernas programvara dominerar, och deras SBOM:er är ofta bristfälliga. Vi hör om leverantörers SBOM:er med saknade komponenter, utan paket-URL:er eller CPE:er, utan licenser och utan hashvärden, en del skrivna för hand och underkända vid schemavalidering. Binäranalys av en flashad ECU är en nödlösning: den gissar sig till innehållet i stället för att registrera det.

Risken finns i de uppkopplade lagren. Mycket ECU-logik genereras från modeller och innehåller lite öppen källkod. Den öppna källkoden, och exponeringen mot nätverk, koncentreras till Linux-, anslutnings- och applagren, så lägg din insats där först.

Ett illustrativt exempel: programvarustacken i en fiktiv hjullastarplattform, från molnet ner till ECU:erna.

1. Molnbaserad backend och kompanjonsappEgen utveckling. Mest öppen källkod och exponerad mot nätverk. Cyber Resilience Act.
2. TelematikgatewayInbyggd Linux, mest öppen källkod, ansluten till mobilnätet. Cyber Resilience Act, och 1.1.9 för fjärranslutningen.
3. FörardisplayInbyggd Linux-avbild med ett UI-ramverk, mest öppen källkod, ansluten till maskinens buss och till serviceverktyg. Cyber Resilience Act och 1.1.9.
4. MaskinstyrsystemEgen applikation på en leverantörsplattform, säkerhetsrelevant. 1.1.9 och 1.2.1, och Cyber Resilience Act där den kan nås via en anslutning.
5. ECU:er för hydraulik, styrning och motorLeverantörsfirmware, proprietär och modellgenererad, lite öppen källkod, säkerhetsrelevant. 1.1.9 och 1.2.1; Cyber Resilience Act via maskinen.

Den öppna källkoden och exponeringen mot nätverk finns i de tre översta lagren, och det är också där dina egna byggpipelines oftast finns. Börja där.

Maskintillverkare ställer nu SBOM-krav på den programvara de köper, till exempel paket-URL:er eller CPE:er, licenser, hashvärden och ett format som klarar validering, och skickar tillbaka filer som inte håller måttet. Om du bygger på GitHub Actions tar CRACI fram SBOM:en från själva bygget, så att den listar vad som faktiskt gick in i releasen, inklusive komponenterna som ingen lockfile nämner, med en paket-URL och deklarerad licens för varje komponent. Kontrollera exporten mot hela listan över fält som din kund efterfrågar. Läs mer om att besvara kunders SBOM-förfrågningar.