Cybersikkerhet for maskinprodusenter

Maskiner leveres nå med styreenheter, skjermer, telematikkenheter og følgeapper, og de fleste er bygget av leverandører. Fra 2027 forventer både maskinforordningen og Cyber Resilience Act at du vet hvilken programvare som er på hver maskin, og at du holder den sikker i årevis. CRACI registrerer hva som går inn i hvert programvarebygg.

Book en demo

To forordninger, ett spørsmål: hvilken programvare er på maskinen?

Fra 2027 må en maskin med en styreenhet, en operatørskjerm eller en datatilkobling oppfylle to EU-forordninger. Begge starter med det samme spørsmålet: hvilken programvare er på denne maskinen, versjon for versjon, og hva inneholder den?

11. september 2026Rapporteringspliktene i Cyber Resilience Act for aktivt utnyttede sårbarheter og alvorlige hendelser gjelder.
20. januar 2027Maskinforordningen, (EU) 2023/1230, gjelder og erstatter maskindirektivet.
11. desember 2027Cyber Resilience Act, (EU) 2024/2847, gjelder fullt ut.

Maskinforordningen

To av de grunnleggende helse- og sikkerhetskravene i vedlegg III handler om cybersikkerhet:

1.1.9, vern mot korrumpering. Tilkobling av en annen enhet til maskinen, direkte eller via fjernforbindelse, skal ikke føre til en farlig situasjon. Programvare og data som er avgjørende for at maskinen oppfyller de grunnleggende helse- og sikkerhetskravene, skal identifiseres og beskyttes mot utilsiktet eller forsettlig korrumpering. Maskinen skal identifisere programvaren som er installert på den og som den trenger for å fungere sikkert, og gjøre den informasjonen tilgjengelig til enhver tid. Den skal også samle inn bevis på legitime eller illegitime inngrep i den programvaren eller konfigurasjonen av den.
1.2.1, sikkerhet og pålitelighet i styringssystemer. Styringssystemer skal tåle rimelig forutsigbare ondsinnede forsøk fra tredjeparter som fører til en farlig situasjon. Etter 1.2.1(f) skal de føre en sporingslogg over inngrep og over versjonene av sikkerhetsprogramvare som er lastet opp etter at maskinen ble brakt i omsetning, i fem år etter opplastingen.

Cyber Resilience Act

En maskin med en datatilkobling, eller en del av den som selges separat, er et produkt med digitale elementer. Produsenten må utvise aktsomhet med tredjepartskomponentene den integrerer, utarbeide en SBOM som minst dekker avhengighetene på øverste nivå, håndtere sårbarheter gjennom støtteperioden, som er minst fem år med mindre produktet forventes å være i bruk kortere, og oppbevare den tekniske dokumentasjonen i minst ti år eller gjennom støtteperioden, avhengig av hva som er lengst.

Krav	Maskinforordningen	Cyber Resilience Act	Hva det krever på programvaresiden
Kjenne den installerte programvaren	1.1.9: maskinen identifiserer til enhver tid programvaren den trenger for å fungere sikkert	En SBOM som minst dekker avhengighetene på øverste nivå	En oversikt over hver komponent i hver programvareversjon
Beskytte den mot korrumpering	1.1.9 og 1.2.1: beskytte sikkerhetsprogramvare og tåle ondsinnede forsøk	Grunnleggende cybersikkerhetskrav til produktet	Kjente komponenter, og bygg som en forgiftet avhengighet ikke kan nå inn i
Registrere endringer og versjoner	1.2.1(f): logg over versjoner av sikkerhetsprogramvare lastet opp etter at maskinen ble brakt i omsetning	Teknisk dokumentasjon for produktet som er brakt i omsetning	Versjonshistorikk per bygg og per utgivelse
Håndtere sårbarheter	Ikke nevnt som sådan	Sårbarhetshåndtering gjennom støtteperioden; rapportering siden 11. september 2026	Overvåking av leverte komponenter mot nye advisories
Oppbevare dokumentasjonen	Sporingslogg: fem år etter hver opplasting	Teknisk dokumentasjon: minst ti år eller støtteperioden	SBOM-er eksportert til den tekniske dokumentasjonen

Dekker CRA-samsvar maskinforordningen?

Ikke automatisk. Cyber Resilience Act gir ingen presumsjon om samsvar med maskinforordningen. Fortalepunkt 53 sier at oppfyllelse av CRAs grunnleggende krav kan gjøre det lettere å oppfylle maskinforordningens krav om vern mot korrumpering og om sikkerhet og pålitelighet i styringssystemer. Det sier også at produsenten må påvise dette, for eksempel ved å anvende harmoniserte standarder etter en risikovurdering, og at prosedyrene for samsvarsvurdering i begge forordningene fortsatt gjelder.

Den harmoniserte standarden som utarbeides for 1.1.9, er EN 50742, Safety of machinery – Protection against corruption. I november 2026 forelå den som endelig utkast, FprEN 50742, som dekker 1.1.9 og de tilhørende punktene i 1.2.1, og så lenge henvisningen til en endelig versjon ikke er kunngjort i Den europeiske unions tidende, gir den ingen presumsjon om samsvar. Den kombinerer risikovurderingen i EN ISO 12100 med sikkerhetsbegreper fra IEC 62443 og godtar konsekvent bruk av IEC 62443-4-1, IEC 62443-3-3 og IEC 62443-4-2 som en likeverdig måte å nå beskyttelsesmålene på. IEC 62443-4-2 fastsetter de tekniske sikkerhetskravene til komponenter i styresystemer, gradert etter security capability level. I Tyskland omsetter prøvingsprinsippene GS-IFA-M25 fra juli 2026 vern mot korrumpering til 66 prøvingskriterier, med begrepene fra prEN 50742. Ett av dem, T46, krever at produktet på forespørsel kan oppgi installert programvareversjon og konfigurasjon. For å kunne svare på det for hver konfigurasjon trenger du en registrering av hva hver programvareversjon inneholder.

Maskinforordningen har en egen presumsjon, og den går gjennom en annen vei: EUs ordninger for cybersikkerhetssertifisering vedtatt under cybersikkerhetsforordningen (Cybersecurity Act), forordning (EU) 2019/881. Et sertifikat eller en samsvarserklæring under en slik ordning gir presumsjon om samsvar med 1.1.9 og 1.2.1 i den grad den dekker disse kravene.

Én risikovurdering og ett sett med bevis kan altså tjene begge forordningene, men du må påvise samsvar med hver av dem. Har maskinen din en datatilkobling, bør du planlegge for begge. Programvarebevisene, altså SBOM-er, sårbarhetsoppføringer og oppdateringshistorikken, er den delen de har felles.

I januar 2026 ba bransjeorganisasjoner for maskinindustrien om at 1.1.9 og 1.2.1(f) ble utsatt, og i mars 2026 om at de skulle gjelde fra CRAs dato, 11. desember 2027. Det er en anmodning, ikke lov: per november 2026 var ingen utsettelse vedtatt. Datoene på denne siden er datoene i forordningene.

Hvilke maskiner og hvilken programvare som omfattes

Anleggs-, materialhåndterings-, gruve- og industrimaskiner omfattes av maskinforordningen, og også av CRA når maskinen eller delene av den har en datatilkobling.
Jordbruks- og skogbrukstraktorer som omfattes av forordning (EU) nr. 167/2013, er unntatt fra maskinforordningen, bortsett fra maskiner som er montert på dem. CRAs liste over unntak nevner ikke den forordningen, så en tilkoblet traktor kan være innenfor CRAs virkeområde.
Kjøretøy som er typegodkjent under forordning (EU) 2019/2144, er unntatt fra CRA.
Komponenter som selges separat. CRA gjelder også for programvare- og maskinvarekomponenter som bringes i omsetning separat. En leverandør som selger en ECU eller en telematikkenhet for seg, er selv produsent under CRA. Når enheten bare bygges inn i maskinen, bærer maskinprodusenten forpliktelsen for hele maskinen og må utvise aktsomhet med leverandørens komponent.

Dette er generell informasjon, ikke juridisk rådgivning. Sjekk klassifiseringen av ditt eget produkt.

I én og samme maskin kommer programvaren fra ulike steder, og bare teamet som bygger en programvare, kan si pålitelig hva som er i den. Det vi hører fra maskinprodusenter, er at bare metal-ECU-er inneholder lite åpen kildekode, mens programvare for Linux, Android og Windows inneholder mye.

Programvare	Typisk opphav	Andel åpen kildekode	Hvem som kan lage en pålitelig SBOM	Hvor CRACI passer inn
Applikasjon for maskinens styreenhet	Internt eller leverandør	Varierer	Teamet som bygger den	Når den bygges på GitHub Actions på Linux
ECU-firmware (hydraulikk, styring, drivlinje)	Leverandør	Vanligvis lav: proprietær og modellgenerert kode	Leverandøren	Ikke direkte: gjennom leverandørens SBOM, lagt til i CRACI
Linux-image for skjerm eller HMI	Internt eller leverandør	Høy	Teamet som bygger imaget	Ja: Yocto og andre innebygde Linux-bygg
Telematikk-gateway	Internt eller leverandør	Høy	Teamet som bygger den	Ja, når den bygges på GitHub Actions
Diagnose- og følgeapper	Internt	Høy	App-teamet	npm-, PyPI-, Go- og Cargo-bygg ja; Android med Gradle, iOS- og Windows-apper ikke i dag
Backend i skyen	Internt	Høy	Tjenesteteamet	Ja, for bygg på GitHub Actions

Hvorfor maskiner er vanskeligere enn forbrukerelektronikk

Små volumer, stor variasjon. En maskinprodusent kan ha hundrevis av plattformer på markedet, selge en håndfull enheter av hver per år og konfigurere mange maskiner etter bestilling. Hver konfigurasjon er et eget sett med programvare, så en SBOM for hvert bygg betyr mer enn en SBOM for hver produktlinje.

Lang levetid. Maskiner er i drift i ti år eller mer, mens leverandører byttes ut eller går konkurs. Oversikten over hva som gikk inn i en programvareversjon, må lages når den bygges, fordi den ikke kan rekonstrueres år senere.

Leverandørprogramvare dominerer, og leverandørenes SBOM-er er ofte dårlige. Vi hører om leverandør-SBOM-er med manglende komponenter, uten package URL-er eller CPE-er, uten lisenser og uten hasher, noen skrevet for hånd og uten å bestå skjemavalidering. Binæranalyse av en flashet ECU er en nødløsning: den gjetter på innholdet i stedet for å registrere det.

Risikoen ligger i de tilkoblede lagene. Mye ECU-logikk genereres fra modeller og inneholder lite åpen kildekode. Den åpne kildekoden og nettverkseksponeringen samler seg i Linux-, tilkoblings- og applagene, så bruk innsatsen der først.

Et illustrerende eksempel: programvarestakken på en fiktiv hjullasterplattform, fra skyen og ned til ECU-ene.

Backend i skyen og følgeappInternt utviklet. Hovedsakelig åpen kildekode og eksponert mot nettverket. Cyber Resilience Act.
Telematikk-gatewayInnebygd Linux, hovedsakelig åpen kildekode, koblet til mobilnettet. Cyber Resilience Act, og 1.1.9 for fjernforbindelsen.
OperatørskjermInnebygd Linux-image med et UI-rammeverk, hovedsakelig åpen kildekode, koblet til maskinbussen og til serviceverktøy. Cyber Resilience Act og 1.1.9.
Maskinens styreenhetInternt utviklet applikasjon på en leverandørplattform, sikkerhetsrelevant. 1.1.9 og 1.2.1, og Cyber Resilience Act der den kan nås via en tilkobling.
ECU-er for hydraulikk, styring og motorLeverandørfirmware, proprietær og modellgenerert, lite åpen kildekode, sikkerhetsrelevant. 1.1.9 og 1.2.1; Cyber Resilience Act gjennom maskinen.

Den åpne kildekoden og nettverkseksponeringen ligger i de tre øverste lagene, og det er også der dine egne byggepipeliner vanligvis er. Begynn der.

Slik forbereder du deg, steg for steg

Maskinfunksjoner som identifisering av programvare på maskinen og logger over inngrep er en del av maskinens konstruksjon. Stegene nedenfor dekker programvaren som går inn i den.

Kartlegg programvaren på hver maskinplattform. List opp all programvare på hver plattform og konfigurasjon, og marker det som er sikkerhetsrelevant. Dette er utgangspunktet for 1.1.9, som krever at maskinen identifiserer programvaren den trenger for å fungere sikkert.
Skill mellom det du bygger og det du integrerer. Programvare teamene dine bygger og programvare som kommer fra leverandører, trenger ulike veier til bevis. For den første lager du oversikten selv; for den andre stiller du krav og sjekker det du får.
Registrer hvert utgivelsesbygg av din egen programvare. Lag en SBOM fra hvert utgivelsesbygg, ta vare på den per versjon, og overvåk den for nye sårbarheter gjennom hele støtteperioden.
Sett en minstestandard for leverandørenes SBOM-er. Bli enige om formatet og feltene du trenger, som package URL-er eller CPE-er, lisenser og hasher, valider hver leveranse, og send den tilbake når den ikke holder mål. Se hvordan leverandører svarer på SBOM-forespørsler fra kunder.
Planlegg oppbevaring for maskinens levetid. Oppbevar teknisk dokumentasjon for CRA i minst ti år eller gjennom støtteperioden, avhengig av hva som er lengst, og loggen over sikkerhetsprogramvare etter 1.2.1(f) i fem år etter hver opplasting. Planlegg for maskinens levetid, ikke prosjektets lengde.
Ha sårbarhetshåndtering og rapportering på plass. CRA-rapportering av aktivt utnyttede sårbarheter og alvorlige hendelser har gjeldt siden 11. september 2026. Bestem hvem som prioriterer funn, hvem som eier hver retting og hvem som rapporterer.
Lås ned selve bygget. Kjør hvert bygg i et isolert miljø som bare når kildene det trenger, så en kompromittert avhengighet ikke kan nå kildekoden, hemmelighetene eller utgivelsen din.

Hvor CRACI passer inn

CRACI kjører GitHub Actions-byggene dine på egne runnere og registrerer hva som går inn i hvert av dem. For en maskinprodusent dekker det programvaren teamene dine bygger og leverandør-SBOM-ene du samler inn.

Byggeregistreringer for maskinprogramvaren du bygger

Kjør styringstjenestene dine og Linux-imagene for skjerm og telematikk, inkludert Yocto- og andre innebygde Linux-bygg, på CRACIs GitHub Actions-runnere, opptil 32 vCPU-er, på x86-64 eller native ARM64. Mens bygget kjører, registrerer CRACI hver pakke og fil det henter inn, inkludert de skjulte avhengighetene ingen oppskrift eller lockfile viser, og merker hver jobbs SBOM med en fullstendighetsstatus. I et core-image-sato-bygg hadde CRACIs SBOM alle komponentene i Yoctos egen SBOM pluss 88 den manglet, med en package URL for hver av de 653 Rust crate-versjonene. Mer om Yocto-bygg på CRACI.

Leverandørenes SBOM-er ved siden av dine egne

Legg til SBOM-er fra leverandørene av ECU-er, skjermer og telematikk, så overvåkes de innkjøpte komponentene sammen med programvaren du bygger. Når en ny sårbarhet dukker opp i en leverandørs Linux-stakk, vises den i samme oversikt som dine egne.

Hvilke maskiner som er berørt, og siden når

CRACI fortsetter å vurdere overvåkede SBOM-er på nytt etter hvert som nye sårbarheter publiseres. Byggehistorikken viser hvilke bygg som inneholdt den sårbare avhengigheten, direkte eller transitiv, innenfor oppbevaringstiden i planen din, og inventarvisningen viser hvilke programvareversjoner som er rullet ut til hvilke produkter. Sikkerhetsteam prioriterer hvert funn og ruter det til teamet som eier rettingen, og en policy gate kan holde en bestemt CVE ute av alle senere bygg.

Bevis for den tekniske dokumentasjonen

CRACI leverer bevisene om programvareleverandørkjeden som den tekniske dokumentasjonen din trenger: SBOM-er fra bygget eksportert som CycloneDX eller SPDX, med transitive avhengigheter, deklarerte lisenser og sårbarhetene som er funnet i komponentene, i tillegg til sårbarhetsoppføringer og byggehistorikk. For maskiner som omfattes av CRA, forbereder CRACI innholdet i CRA-varslene, og en person i bedriften din sender dem inn via Single Reporting Platform. Samsvarsvurderingen, EU-samsvarserklæringen og CE-merkingen forblir hos deg, produsenten.

Et bygg som bare når det det trenger

Hver jobb kjører i sin egen isolerte virtuelle maskin under en egress-policy som valideres før jobben starter og blokkerer ved feil (fail closed). Med en default deny-policy når bygget pakkekildene dine og ingenting annet, og en tilkobling til en hvilken som helst annen vert blir blokkert og utløser et varsel.

For leverandører av ECU-er, skjermer og telematikkenheter

Maskinprodusenter stiller nå SBOM-krav til programvaren de kjøper, som package URL-er eller CPE-er, lisenser, hasher og et format som består validering, og sender tilbake filer som ikke holder mål. Bygger du på GitHub Actions, lager CRACI SBOM-en fra selve bygget, så den viser hva som faktisk gikk inn i utgivelsen, inkludert komponentene ingen lockfile nevner, med en package URL og deklarert lisens for hver komponent. Sjekk eksporten mot hele listen over felt kunden din ber om. Mer om hvordan du svarer på SBOM-forespørsler fra kunder.

Når CRACI ikke er svaret

CRACI passer for programvaren du bygger. Det passer ikke i disse tilfellene:

Ikke for en maskinprodusent som bare integrerer leverandørers ECU-er og ikke bygger noen programvare selv. CRACI registrerer bygg; det kan ikke lage en SBOM for en binærfil noen andre har bygget. Hvis nesten all programvaren din kommer ferdig flashet på leverandørmaskinvare, er verktøyene dine SBOM-krav til leverandører, SBOM-validering og, som nødløsning, binæranalyse, som CRACI ikke gjør (se binæranalyse sammenlignet med en byggeregistrering). CRACI hjelper deg gjennom leverandørenes bygg og ved å overvåke SBOM-ene de gir deg.
Ikke for bare metal- eller RTOS-firmware som bygges utenfor GitHub Actions, eller på Windows eller macOS. CRACI kjører GitHub Actions-jobber på Linux-runnere i dag. Andre CI-systemer, som GitLab CI og Jenkins, og Windows- og macOS-runnere står på veikartet.
Ikke for Android-følgeapper bygget med Gradle, eller for Java-tjenester. Maven og Java står på veikartet og støttes ikke i dag. iOS-apper trenger macOS-runnere, som også står på veikartet.
Ikke for maskiner som allerede er i drift og har programvare som ble bygget for år siden. CRACI registrerer bygg mens de kjører.
Ikke kontrollene på maskinen. Å identifisere den installerte programvaren på maskinen, samle inn bevis på inngrep og føre sporingsloggen er maskinfunksjoner etter 1.1.9 og 1.2.1. CRACI leverer dem ikke, signerer ikke firmware og gjennomfører ikke samsvarsvurderingen.
Ikke langtidsarkivering alene. Byggeregistreringer oppbevares i oppbevaringstiden i planen din. Eksporter SBOM-ene til den tekniske dokumentasjonen for tiårshorisonten.

Cybersikkerhet for maskiner, forklart

Vanlige spørsmål om maskinforordningen, CRA og programvaren på en maskin

Når gjelder EUs maskinforordning?

Fra 20. januar 2027. Forordning (EU) 2023/1230 erstatter maskindirektivet på den datoen. Teksten som først ble publisert, oppga 14. januar 2027; en rettelse endret den til 20. januar 2027. Maskiner som bringes i omsetning på EU-markedet fra da av, må oppfylle de grunnleggende helse- og sikkerhetskravene, inkludert de cybersikkerhetsrelaterte i vedlegg III, 1.1.9 og 1.2.1.

Hvilke cybersikkerhetskrav stiller maskinforordningen?

Vedlegg III 1.1.9, vern mot korrumpering: tilkobling av en annen enhet skal ikke skape en fare, sikkerhetskritisk programvare og data skal beskyttes, maskinen skal til enhver tid identifisere sin sikkerhetsrelevante programvare og samle inn bevis på inngrep. Vedlegg III 1.2.1: styringssystemer skal tåle rimelig forutsigbare ondsinnede forsøk og føre en sporingslogg over versjoner av sikkerhetsprogramvare lastet opp etter at maskinen ble brakt i omsetning.

Gjelder Cyber Resilience Act for maskiner?

Ja, når maskinen eller en del av den er et produkt med digitale elementer, noe som i praksis betyr at den har en datatilkobling. CRA unntar ikke maskiner. Rapporteringspliktene har gjeldt siden 11. september 2026, og forordningen gjelder fullt ut fra 11. desember 2027, elleve måneder etter maskinforordningen.

Hvis en maskin oppfyller CRA, oppfyller den da også maskinforordningen?

Ikke automatisk. Det finnes ingen presumsjon om samsvar mellom de to. CRA sier at oppfyllelse av kravene kan gjøre det lettere å oppfylle 1.1.9 og 1.2.1, men produsenten må påvise det, og begge prosedyrene for samsvarsvurdering gjelder. Maskinforordningens egen presumsjon går gjennom EUs ordninger for cybersikkerhetssertifisering. Ett sett med bevis kan tjene begge.

Trenger en maskinprodusent en SBOM?

For en maskin innenfor CRAs virkeområde, ja: CRA krever at produsenten utarbeider en SBOM som minst dekker avhengighetene på øverste nivå. Maskinforordningen nevner ikke SBOM-er, men 1.1.9 krever at maskinen identifiserer programvaren den trenger for å fungere sikkert, og det er vanskelig å holde nøyaktig på tvers av mange konfigurasjoner uten en oversikt over hver programvareversjon.

Hvem er ansvarlig for programvaren i en leverandørs ECU?

Begge, i ulike roller. En leverandør som bringer en ECU i omsetning for seg, er produsent under CRA for den komponenten. Maskinprodusenten er ansvarlig for hele maskinen og må utvise aktsomhet med komponentene den integrerer, og derfor ber maskinprodusenter nå leverandører om SBOM-er som oppfyller en fastsatt standard.

Omfattes traktorer av maskinforordningen eller CRA?

Jordbruks- og skogbrukstraktorer som omfattes av forordning (EU) nr. 167/2013, er unntatt fra maskinforordningen, bortsett fra maskiner som er montert på dem. CRAs unntak nevner ikke den forordningen, så en tilkoblet traktor kan være innenfor CRAs virkeområde. Sjekk klassifiseringen av ditt eget produkt; dette er generell informasjon, ikke juridisk rådgivning.

Hvilke CI-systemer og byggemaskiner støtter CRACI?

CRACI kjører GitHub Actions-jobber på Linux-runnere, x86-64 og ARM64, fra 1 til 32 vCPU-er. Andre CI-systemer, som GitLab CI og Jenkins, står på veikartet, det samme gjør Windows- og macOS-runnere.

Se hva som går inn i byggene av maskinprogramvaren din

Book en demo, så viser vi hver komponent byggene for styring, skjerm og telematikk henter inn, og hvilke av dem som er sårbare

Book en demo