Glossar

    CRA-Glossar: das Vokabular von SBOM bis Schwachstellenmanagement

    Die zentralen Begriffe rund um Cyber Resilience Act, EU-Maschinenverordnung und Schwachstellenmanagement – kurz definiert und für Anlagenbauer und Integratoren eingeordnet. Jeder Begriff hat einen festen Anker zum Verlinken.

    Regulierung & Geltungsbereich

    Cyber Resilience Act (CRA)Verordnung (EU) 2024/2847

    Der Cyber Resilience Act (Verordnung (EU) 2024/2847, CRA) ist die EU-Produktverordnung für Cybersicherheit. Sie verpflichtet Hersteller von Produkten mit digitalen Elementen zu sicheren Produkteigenschaften und zu Schwachstellenmanagement über den gesamten Support-Zeitraum.

    Kerndaten: Meldepflicht ab dem 11.09.2026, volle Anwendung ab dem 11.12.2027. Für Anlagenbauer gilt er parallel zur Maschinenverordnung – keine ersetzt die andere. Details im Leitfaden für Anlagenbauer und Integratoren.

    Siehe auch: Maschinenverordnung (MVO), Produkt mit digitalen Elementen, Wesentliche Cybersicherheitsanforderungen, Meldepflicht & ENISA

    Maschinenverordnung (MVO)Verordnung (EU) 2023/1230

    Die Maschinenverordnung (EU) 2023/1230 (MVO) ist die EU-Produktverordnung für Maschinen; sie löst ab dem 20. Januar 2027 die Maschinenrichtlinie 2006/42/EG ab und führt erstmals verbindliche Cybersicherheitsanforderungen mit Safety-Bezug ein.

    Für Anlagenbauer gilt sie parallel zum CRA: Beide führen zur CE-Kennzeichnung, schützen aber Unterschiedliches – die MVO die Sicherheit von Personen, der CRA das Produkt. Den vollständigen Vergleich liefert unser Leitfaden.

    Siehe auch: Cyber Resilience Act (CRA), CE-Kennzeichnung & Konformitätserklärung, Risikobeurteilung, Maschinenrichtlinie 2006/42/EG, Inbetriebnahme

    Produkt mit digitalen Elementen

    Ein Produkt mit digitalen Elementen ist jedes Software- oder Hardwareprodukt samt zugehöriger Datenfernverarbeitung, dessen bestimmungsgemäße Verwendung eine Datenverbindung umfasst (CRA Art. 3). Diese Definition eröffnet den Anwendungsbereich des CRA.

    Praktisch fast jede moderne Anlage: Sobald digitale Elemente verbaut sind und kommunizieren, ist das Gesamtprodukt CRA-pflichtig.

    Siehe auch: Cyber Resilience Act (CRA), Wesentliche Cybersicherheitsanforderungen, Produktklassen (wichtig / kritisch)

    NIS2-RichtlinieRichtlinie (EU) 2022/2555

    NIS2 (Richtlinie (EU) 2022/2555) ist die EU-Richtlinie zur Cybersicherheit von Betreibern wesentlicher und wichtiger Einrichtungen. Sie verpflichtet Organisationen (Betreiber), während der CRA Produkte verpflichtet (Hersteller).

    Häufige Verwechslung: Der CRA betrifft, was Sie in Verkehr bringen; NIS2 betrifft, wie Sie als Unternehmen Ihre eigene Infrastruktur absichern. Anlagenbauer können beidem unterliegen.

    Siehe auch: Cyber Resilience Act (CRA), Schwachstellenmanagement

    Maschinenrichtlinie 2006/42/EG

    Die Maschinenrichtlinie 2006/42/EG ist die bisherige EU-Regelung für Maschinen. Sie wird ab dem 20. Januar 2027 vollständig durch die Maschinenverordnung (EU) 2023/1230 abgelöst.

    Wesentlicher Unterschied: Die alte Richtlinie kannte keine verbindlichen Cybersicherheitsanforderungen – die Maschinenverordnung führt sie ein und verzahnt sich damit mit dem CRA.

    Siehe auch: Maschinenverordnung (MVO), CE-Kennzeichnung & Konformitätserklärung

    ↑ Zur Themenübersicht

    Rollen & Pflichten

    Inverkehrbringen

    Inverkehrbringen ist die erstmalige Bereitstellung eines Produkts auf dem EU-Markt im Rahmen einer Geschäftstätigkeit (CRA Art. 3). Es löst die Herstellerpflichten aus.

    Der entscheidende Begriff für Integratoren: Wer eine Anlage unter eigenem Namen in Verkehr bringt, ist Hersteller des Gesamtprodukts — und bringt deshalb die CE-Kennzeichnung an, nicht umgekehrt. Wann genau Sie in diese Rolle fallen, erklärt unser Leitfaden für Anlagenbauer und Integratoren.

    Siehe auch: Produktklassen (wichtig / kritisch), Wesentliche Veränderung, Hersteller & Wirtschaftsakteure, Wesentliche Cybersicherheitsanforderungen

    Hersteller & Wirtschaftsakteure

    Der CRA verteilt Pflichten auf vier Wirtschaftsakteure: Hersteller (volle Verantwortung), Bevollmächtigter, Einführer und Händler. Hersteller ist, wer ein Produkt unter eigenem Namen entwickelt oder in Verkehr bringt (Art. 3).

    Für Integratoren entscheidend: Mit dem Inverkehrbringen unter eigenem Namen fallen Sie in die Herstellerrolle – die Rolle mit den meisten Pflichten.

    Siehe auch: Inverkehrbringen, Cyber Resilience Act (CRA), Wesentliche Cybersicherheitsanforderungen

    Wesentliche Veränderung

    Eine wesentliche Veränderung ist eine Änderung an einem bereits in Verkehr gebrachten Produkt, die seine Konformität berührt oder die Risikobewertung verändert (CRA Art. 22, analoges Konzept in der MVO).

    Der Auslöser, an dem Integratoren und Instandsetzer zum Hersteller des geänderten Produkts werden – mit vollen Pflichten. Ein reiner Bugfix zählt in der Regel nicht, eine neue Funktion oder mehr Angriffsfläche dagegen schon.

    Siehe auch: Inverkehrbringen, Hersteller & Wirtschaftsakteure, Gesamtheit von Maschinen

    Gesamtheit von Maschinen

    Eine Gesamtheit von Maschinen (Maschinenanlage) ist eine Zusammenstellung mehrerer Maschinen, die für ein gemeinsames Ziel zusammenwirken und als Einheit gesteuert werden – und gilt dann als eine einzige Maschine im Sinne der MVO.

    Genau das, was Integratoren bauen: Wer eine Linie oder Anlage zu einem funktionalen Ganzen zusammenführt und unter eigenem Namen liefert, ist Hersteller der Gesamtheit – inklusive aller zugekauften Komponenten.

    Siehe auch: Inverkehrbringen, Wesentliche Veränderung, Unvollständige Maschine, Maschinenverordnung (MVO)

    Unvollständige Maschine

    Eine unvollständige Maschine ist eine Baugruppe, die fast eine Maschine bildet, für sich aber keine bestimmte Funktion erfüllen kann (z. B. ein Antriebssystem). Sie wird nicht CE-gekennzeichnet, sondern erhält eine Einbauerklärung und eine Montageanleitung.

    Wichtig für Integratoren auf beiden Seiten: Wer Teilanlagen zuliefert, stellt eine Einbauerklärung aus; wer sie zur fertigen Maschine zusammenbaut, übernimmt die Herstellerpflichten für das Gesamtprodukt.

    Siehe auch: Gesamtheit von Maschinen, CE-Kennzeichnung & Konformitätserklärung, Inverkehrbringen

    Inbetriebnahme

    Inbetriebnahme ist die erstmalige bestimmungsgemäße Verwendung eines Produkts in der EU. Sie ist vom Inverkehrbringen zu unterscheiden und kann Pflichten auch dann auslösen, wenn ein Produkt nicht im klassischen Sinn verkauft wird (z. B. Eigenbau für den eigenen Betrieb).

    Relevant an der Außenkante des Anlagenbaus: Erst auf dem Kundengelände errichtete Komplettanlagen werden über Inverkehrbringen und Inbetriebnahme abgegrenzt.

    Siehe auch: Inverkehrbringen, Gesamtheit von Maschinen

    Support-ZeitraumUnterstützungszeitraum

    Der Unterstützungszeitraum ist die Zeitspanne, in der ein Hersteller nach CRA Schwachstellen behandeln und kostenlose Sicherheitsupdates bereitstellen muss – mindestens fünf Jahre, orientiert an der erwarteten Nutzungsdauer.

    Aus diesem Zeitraum entsteht der wiederkehrende Aufwand – und für Anlagenbauer ein planbares Service-Geschäft: Integration, Absicherung und Wiederinbetriebnahme der Updates.

    Siehe auch: Schwachstellenmanagement, Wesentliche Cybersicherheitsanforderungen, Cyber Resilience Act (CRA)

    ↑ Zur Themenübersicht

    Risikobeurteilung & Konformität

    Wesentliche Cybersicherheitsanforderungen

    Die wesentlichen Cybersicherheitsanforderungen sind die in CRA Anhang I festgelegten Pflichten: sichere Produkteigenschaften (Teil I) und Schwachstellenbehandlung (Teil II).

    Teil I verlangt Produkte, die „secure by design" und „secure by default" sind; Teil II regelt den Umgang mit Schwachstellen über den gesamten Support-Zeitraum (SBOM, Meldewege, kostenlose Sicherheitsupdates). Aus Teil II entsteht der wiederkehrende Aufwand — und damit der Bedarf nach Automatisierung. Quelle: CRA Anhang I.

    Siehe auch: Schwachstellenmanagement, SBOM, Produktklassen (wichtig / kritisch), Cyber Resilience Act (CRA)

    Risikobeurteilung

    Die Risikobeurteilung ist die systematische Ermittlung und Bewertung der Gefährdungen eines Produkts. Die MVO verlangt sie für die grundlegenden Sicherheits- und Gesundheitsanforderungen (Anhang III), einschließlich der safety-relevanten Cybersicherheit (1.1.9 Schutz gegen Korrumpierung, 1.2.1 Steuerungen).

    Für die Cyber-Dimension ist eine STRIDE-Bedrohungsanalyse je Anlagentyp das übliche Werkzeug – eine einmalige Aufgabe, die Werkspilot übernimmt.

    Siehe auch: STRIDE, Sicherheitsbauteil, Maschinenverordnung (MVO), Wesentliche Cybersicherheitsanforderungen

    STRIDE

    STRIDE ist ein Bedrohungsmodell mit sechs Kategorien (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) zur systematischen Risikoanalyse.

    Für die nach CRA und Maschinenverordnung geforderte Risikobeurteilung der Cybersicherheit ist STRIDE je Anlagentyp das übliche Werkzeug — eine einmalige Aufgabe, im Gegensatz zum laufenden Monitoring. Werkspilot erstellt diese STRIDE-Bedrohungsanalysen als Teil der Risikobeurteilung.

    Siehe auch: SSVC, IEC 62443, Risikobeurteilung, Wesentliche Cybersicherheitsanforderungen

    Sicherheitsbauteil

    Ein Sicherheitsbauteil ist eine Komponente, die eine Sicherheitsfunktion erfüllt und deren Versagen Personen gefährdet (z. B. Schutzeinrichtungen, Zweihandschaltungen). Bestimmte Maschinen und Sicherheitsbauteile listet MVO Anhang I als Hochrisiko-Kategorien mit strengerem Konformitätsbewertungsverfahren.

    Wer solche Produkte baut, kommt seltener mit der reinen Selbstdeklaration aus und braucht gegebenenfalls eine notifizierte Stelle.

    Siehe auch: Konformitätsbewertungsverfahren, Risikobeurteilung, Produktklassen (wichtig / kritisch)

    Produktklassen (wichtig / kritisch)

    Der CRA stuft Produkte mit digitalen Elementen in drei Risikostufen ein: Standard (Selbstbewertung), wichtig (Klasse I und II, Anhang III) und kritisch (Anhang IV). Die Klasse bestimmt das Konformitätsbewertungsverfahren.

    Die meisten Anlagen fallen in die Standardklasse und erlauben die Selbstdeklaration. „Wichtige" Produkte (z. B. bestimmte Industrie- oder Netzkomponenten) verlangen strengere Verfahren. Die Einordnung ist ein Pflichtschritt beim Inverkehrbringen, kein optionaler.

    Siehe auch: Inverkehrbringen, Konformitätsbewertungsverfahren, Wesentliche Cybersicherheitsanforderungen

    Konformitätsbewertungsverfahren

    Das Konformitätsbewertungsverfahren ist der Nachweisweg, über den ein Hersteller die Erfüllung der Anforderungen belegt – von der internen Selbstbewertung (Modul A) bis zur Prüfung durch eine notifizierte Stelle. Welches Verfahren gilt, hängt von der Produktklasse ab.

    Die meisten Anlagen erlauben die Selbstdeklaration; wichtige bzw. kritische CRA-Produkte und Hochrisiko-Maschinen (MVO Anhang I) verlangen strengere Verfahren.

    Siehe auch: Produktklassen (wichtig / kritisch), Sicherheitsbauteil, CE-Kennzeichnung & Konformitätserklärung, Harmonisierte Norm

    CE-Kennzeichnung & Konformitätserklärung

    Die CE-Kennzeichnung erklärt die Konformität eines Produkts mit allen anwendbaren EU-Vorschriften; die EU-Konformitätserklärung ist das unterschriebene Dokument dahinter. Für eine Anlage mit digitalen Elementen sind sowohl MVO als auch CRA darin abzudecken.

    Nicht die CE-Kennzeichnung macht den Hersteller – umgekehrt: Wer unter eigenem Namen in Verkehr bringt, ist Hersteller und bringt deshalb die CE-Kennzeichnung an.

    Siehe auch: Inverkehrbringen, Konformitätsbewertungsverfahren, Maschinenverordnung (MVO), Cyber Resilience Act (CRA)

    Harmonisierte Norm

    Eine harmonisierte Norm ist eine im EU-Amtsblatt gelistete Norm, deren Anwendung die Konformitätsvermutung für die zugehörigen Anforderungen auslöst. Für CRA und MVO sind viele dieser Normen Mitte 2026 noch nicht gelistet.

    Folge: Wer sich heute absichert, stützt sich auf anerkannte Normen wie IEC 62443 und BSI TR-03183 als Stand der Technik, bis die harmonisierten CRA-Normen erscheinen.

    Siehe auch: IEC 62443, BSI TR-03183, Konformitätsbewertungsverfahren

    ↑ Zur Themenübersicht

    Schwachstellenmanagement & Meldung

    Schwachstellenmanagement

    Schwachstellenmanagement ist der fortlaufende Prozess, Schwachstellen zu erfassen, zu bewerten, zu behandeln und zu melden — nach CRA Anhang I Teil II Pflicht über den gesamten Support-Zeitraum.

    Der wiederkehrende Kern des CRA: nicht einmalig zum Inverkehrbringen, sondern täglich über Jahre. Er umfasst die SBOM-Pflege, das Feed-Monitoring (CSAF bis E-Mail), die Triage (EPSS/KEV/SSVC) und die 24-Stunden- bzw. 72-Stunden-Meldung an die ENISA. Genau diese Pipeline automatisiert Werkspilot.

    Siehe auch: SBOM, CSAF, VEX, CISA KEV, EPSS, SSVC, Meldepflicht & ENISA, Support-Zeitraum

    Meldepflicht & ENISA

    Der CRA verpflichtet Hersteller, aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle über eine zentrale ENISA-Plattform zu melden: Frühwarnung binnen 24 Stunden, Schwachstellenmeldung binnen 72 Stunden, Abschlussbericht später (Art. 14).

    Die Meldepflicht startet am 11.09.2026 – über ein Jahr vor der CE-Pflicht und rückwirkend für Bestandsanlagen. Damit ist sie die erste harte Frist.

    Siehe auch: Schwachstellenmanagement, CISA KEV, Cyber Resilience Act (CRA)

    PSIRTProduct Security Incident Response Team

    Ein PSIRT (Product Security Incident Response Team) ist die organisatorische Stelle eines Herstellers, die Produkt-Schwachstellen entgegennimmt, bewertet und ihre Behandlung sowie Meldung koordiniert.

    Der CRA setzt PSIRT-Funktionen faktisch voraus: Eingangskanal (CVD), Triage und fristgerechte Meldung müssen organisiert sein – auch beim Anlagenbauer, nicht nur beim Softwarekonzern.

    Siehe auch: Coordinated Vulnerability Disclosure, Schwachstellenmanagement, Meldepflicht & ENISA

    Coordinated Vulnerability DisclosureCVD

    Coordinated Vulnerability Disclosure (CVD) ist der koordinierte Prozess, über den Dritte Schwachstellen an einen Hersteller melden und beide die Veröffentlichung abstimmen. Der CRA verlangt eine Kontaktstelle und eine Vulnerability-Disclosure-Policy.

    Praktisch: eine erreichbare Meldeadresse (z. B. security.txt) plus ein definierter interner Ablauf bis zur Behebung.

    Siehe auch: PSIRT, Schwachstellenmanagement

    CISA KEVKnown Exploited Vulnerabilities Catalog

    Der CISA-KEV-Katalog (Known Exploited Vulnerabilities) listet Schwachstellen, die nachweislich aktiv ausgenutzt werden.

    KEV ist das härteste Priorisierungssignal: Steht ein CVE im Katalog und betrifft eine Ihrer Anlagen, ist das der Auslöser für die getriggerte Stichprobe und mündet im Ernstfall in die 24-Stunden-Meldung an die ENISA. Es ergänzt das prognostische EPSS um den harten Nachweis tatsächlicher Ausnutzung.

    Siehe auch: EPSS, SSVC, Schwachstellenmanagement

    EPSSExploit Prediction Scoring System

    EPSS (Exploit Prediction Scoring System) ist ein von FIRST.org gepflegter Score zwischen 0 und 1, der die Wahrscheinlichkeit schätzt, dass eine Schwachstelle in den nächsten 30 Tagen ausgenutzt wird.

    Anders als CVSS (das den Schweregrad misst) schätzt EPSS die Ausnutzungs-Wahrscheinlichkeit — nützlich zur Priorisierung, wenn tausende CVEs anfallen. Es ergänzt den CISA-KEV-Katalog (bereits ausgenutzt) um eine prognostische Komponente.

    Siehe auch: CISA KEV, SSVC, Schwachstellenmanagement

    SSVCStakeholder-Specific Vulnerability Categorization

    SSVC (Stakeholder-Specific Vulnerability Categorization) ist ein Entscheidungsbaum-Modell von CISA und dem CMU SEI, das Schwachstellen nach Handlungsbedarf einordnet (z. B. Act, Attend, Track) statt nur nach Score.

    SSVC passt zur CRA-Triage oft besser als ein reiner CVSS-Score, weil es Exploit-Status, Exposure und Auswirkung im konkreten Anlagenkontext zusammenführt. In unserer Bewertungslogik kombinieren wir SSVC-Entscheidungen mit der STRIDE-Bedrohungssicht je Anlagentyp.

    Siehe auch: EPSS, CISA KEV, STRIDE

    CVSSCommon Vulnerability Scoring System

    CVSS (Common Vulnerability Scoring System) ist ein standardisierter Score von 0 bis 10 für den Schweregrad einer Schwachstelle.

    CVSS sagt, wie schlimm eine Lücke theoretisch ist – nicht, ob sie ausgenutzt wird oder Ihre Anlage betrifft. Zur Priorisierung gehören deshalb EPSS (Wahrscheinlichkeit) und KEV (tatsächliche Ausnutzung) dazu.

    Siehe auch: EPSS, CISA KEV, SSVC, CVE

    CVECommon Vulnerabilities and Exposures

    Eine CVE (Common Vulnerabilities and Exposures) ist ein eindeutiger, weltweit referenzierter Bezeichner für eine konkrete Schwachstelle (z. B. CVE-2025-12345).

    Die gemeinsame Sprache des Schwachstellenmanagements: Lieferanten-Advisories, Feeds und Ihre SBOM müssen über CVE-IDs zusammenfinden, sonst ist kein automatischer Abgleich möglich.

    Siehe auch: CVSS, EPSS, CPE & PURL, SBOM

    ↑ Zur Themenübersicht

    SBOM, Formate & Standards

    SBOMSoftware Bill of Materials

    Eine SBOM (Software Bill of Materials) ist ein maschinenlesbares Inventar aller Softwarekomponenten eines Produkts inklusive Versionen und Abhängigkeiten.

    Der CRA verlangt eine SBOM in maschinenlesbarem Format, damit Schwachstellen über CVE-fähige IDs (CPE/PURL und Version) zuordenbar werden. Wichtig: Eine Hardware-Stückliste ist keine SBOM — erst die Software-Sicht macht den automatischen Abgleich mit Lieferanten-Feeds möglich. Gängige Formate sind CycloneDX und SPDX; Inhalt und Pflichtfelder konkretisiert die BSI TR-03183 Teil 2.

    Siehe auch: HBOM, CSAF, VEX, CycloneDX & SPDX, CPE & PURL, Schwachstellenmanagement

    HBOMHardware Bill of Materials

    Eine HBOM (Hardware Bill of Materials) listet die Hardwarekomponenten eines Produkts. Sie ist der praktische Ausgangspunkt, aber kein Ersatz für die SBOM.

    Für Anlagenbauer der realistische erste Schritt: die HW-BOM auf Firmware-Versionen mappen. Für das CVE-Matching braucht es dann aber die Software-Sicht (SBOM), weil Schwachstellen an Software-Versionen hängen, nicht an Bauteilen.

    Siehe auch: SBOM

    VEXVulnerability Exploitability eXchange

    VEX (Vulnerability Exploitability eXchange) ist eine maschinenlesbare Hersteller-Aussage, ob ein Produkt von einer bekannten Schwachstelle tatsächlich betroffen ist (affected, not affected, fixed, under investigation).

    VEX senkt Fehlalarme drastisch, weil der Hersteller den „betrifft mich?"-Schritt beantwortet, statt ihn dem Anwender zu überlassen. Häufig als Profil von CSAF transportiert. Für Anlagenbauer ist das Produkt-Level-VEX des Direktlieferanten der stärkste Hebel, um aus tausenden CVEs die wenigen relevanten herauszufiltern.

    Siehe auch: CSAF, SBOM, EPSS, Schwachstellenmanagement

    CSAFCommon Security Advisory Framework

    CSAF (Common Security Advisory Framework) ist der OASIS-Standard für maschinenlesbare Security-Advisories im JSON-Format; das VEX-Profil ist Teil davon.

    CSAF 2.0 löst die PDF-Advisory ab und macht Lieferanten-Meldungen automatisierbar; verteilt werden sie über ROLIE-Feeds. Das BSI empfiehlt CSAF. In der DACH-Zulieferkette ist es 2026 aber noch selten — der Long-Tail liefert PDF, RSS, Newsletter oder gar nichts. Genau dieses Einsammeln von CSAF bis E-Mail und das Normalisieren auf eine Sicht automatisieren wir.

    Siehe auch: VEX, SBOM, ROLIE, Schwachstellenmanagement

    ROLIEResource-Oriented Lightweight Information Exchange

    ROLIE (Resource-Oriented Lightweight Information Exchange, RFC 8322) ist ein Feed-Standard, über den Hersteller Security-Advisories – etwa im CSAF-Format – maschinenlesbar zum Abruf bereitstellen.

    Praktisch der Feed für Advisories: Über ROLIE-Endpunkte ziehen wir die CSAF-Advisories der Direktlieferanten automatisch und kontinuierlich ein.

    Siehe auch: CSAF, VEX, Schwachstellenmanagement

    CycloneDX & SPDX

    CycloneDX (OWASP) und SPDX (Linux Foundation, ISO/IEC 5962) sind die beiden etablierten maschinenlesbaren SBOM-Formate.

    Beide werden von BSI TR-03183 akzeptiert. CycloneDX deckt zusätzlich VEX und HBOM mit ab und ist im Security-Umfeld verbreiteter.

    Siehe auch: SBOM, BSI TR-03183, VEX, CPE & PURL

    CPE & PURL

    CPE (Common Platform Enumeration) und PURL (Package URL) sind standardisierte Kennungen, die ein Produkt bzw. ein Softwarepaket samt Version eindeutig benennen.

    Sie sind das Bindeglied zwischen SBOM und CVE: Erst eine CVE-fähige ID (CPE/PURL und Version) macht aus einer Stückliste einen automatisch abgleichbaren Datensatz.

    Siehe auch: SBOM, CVE, CycloneDX & SPDX

    BSI TR-03183

    BSI TR-03183 ist die Technische Richtlinie des BSI zu „Cyber Resilience Requirements for Manufacturers and Products“; Teil 2 spezifiziert die Anforderungen an SBOMs.

    Teil 2 konkretisiert Format und Inhalt einer SBOM (CycloneDX/SPDX, Pflicht- und Kann-Felder) und ist im deutschsprachigen Raum der praktische Referenzpunkt für CRA-konforme Software-Stücklisten.

    Siehe auch: SBOM, IEC 62443, Schwachstellenmanagement

    IEC 62443

    IEC 62443 ist die internationale Normenreihe für Cybersicherheit in industriellen Automatisierungs- und Steuerungssystemen (IACS/OT).

    Die Reihe liefert anerkannte Sicherheitsanforderungen — etwa 4-1 (Secure Development Lifecycle) und 4-2 (technische Anforderungen an Komponenten) —, die als Nachweis für CRA-Anforderungen herangezogen werden können, solange noch keine harmonisierte CRA-Norm im EU-Amtsblatt gelistet ist.

    Siehe auch: STRIDE, OT / IACS, Harmonisierte Norm, BSI TR-03183

    OT / IACS

    OT (Operational Technology) bzw. IACS (Industrial Automation and Control Systems) bezeichnet die Steuerungs- und Automatisierungstechnik in Anlagen – im Unterschied zur klassischen Büro-IT.

    OT hat eigene Randbedingungen (lange Lebenszyklen, Verfügbarkeit vor Vertraulichkeit, seltene Patch-Fenster), weshalb CRA-Schwachstellenmanagement hier anders aussieht als in der IT. Die Normenreihe IEC 62443 adressiert genau diesen Bereich.

    Siehe auch: IEC 62443, Schwachstellenmanagement

    ↑ Zur Themenübersicht

    Fachbeiträge

    Gespräch vereinbaren.

    Sehen Sie, wie Ihr Team das Schwachstellenmanagement einfach und fristgerecht umsetzen kann.