MVO und CRA: Themenlandkarte für Maschinenbauer

Wenn ich mit Maschinenbauern über CRA und Maschinenverordnung spreche, kommt fast immer dieselbe Frage: Was gehört in einen gemeinsamen Block und was muss ich sauber trennen? Genau dafür nutze ich diese Themenlandkarte.

Die Grafik oben ist kein Schaubild für die Wand. Sie ist ein Arbeitsmodell. Sie zeigt, wo sich MVO-Security und CRA fachlich treffen, wo der CRA deutlich weiter geht und an welchen Stellen die Maschinenverordnung eigene, maschinenspezifische Anforderungen behält.

Stand 30. September 2026: Die CRA-Meldepflichten gelten seit 11. September 2026. Die Maschinenverordnung gilt ab 20. Januar 2027; der CRA wird vollständig ab 11. Dezember 2027 anwendbar. Gemeinsame Arbeitsunterlagen sparen Aufwand. Die Erfüllung beider Verordnungen muss trotzdem getrennt nachgewiesen werden.

So lese ich die Themenlandkarte

Links steht die MVO-Security. Dort liegen die Punkte, die eng an Maschine, Steuerung, Safety-Funktion und CE-Logik hängen. Dazu gehören zum Beispiel Steuerungsresilienz bei nicht-böswilligen Ausfällen, Nachvollziehbarkeit von Softwareänderungen oder der Nachweis, dass ein Cybervorfall Sicherheitsfunktionen nicht aushebelt.

In der Mitte liegt der gemeinsame Arbeitsblock. Das ist der Teil, mit dem ich in Workshops beginne. Zugriffskontrolle, Integritätsschutz, Logging, Schutz von Software und Daten, Cybersecurity-Risikobewertung: Hier sprechen MVO und CRA praktisch dieselbe Sprache.

Rechts beginnt der CRA-Mehrumfang. Dort wird es produktbezogen und nachmarktlastig: SBOM, PSIRT, CVD, Security Advisories, Meldepflichten, Support-Zeiträume, Importeur- und Händlerpflichten. Genau an dieser Stelle merken viele Maschinenbauer, dass der CRA kein kleines Add-on zur CE-Welt ist.

Womit ich im Workshop starte

Ich beginne nicht links und auch nicht rechts. Ich beginne in der Mitte.

1. Cybersecurity-Risikobewertung. Ohne sauberes Risikobild wird jede Diskussion über Maßnahmen beliebig.
2. Zugangskontrolle und Authentifizierung. Das ist fast immer der schnellste Hebel, um einen gemeinsamen Nenner zwischen Entwicklung, Service und Produktmanagement zu schaffen.
3. Integrität, Software-/Datenschutz und Updates. Hier wird aus Regulatorik technische Architektur.
4. Logging und Beweissicherung. Spätestens an diesem Punkt wird klar, ob ein Hersteller nur Schutzmaßnahmen hat oder auch Nachweise führen kann.

Danach steht meist etwas Wichtiges: Das Team nutzt denselben Wortschatz. Genau das fehlt in vielen Projekten am Anfang.

Was auf der MVO-Seite wirklich eigenständig bleibt

Die linke Spalte ist kleiner. Harmloser ist sie nicht.

Die MVO zieht Cybersicherheit in die Maschinensicherheit hinein. Dadurch entstehen Fragen, die der CRA allein nicht beantwortet: Wie verhält sich die Steuerung bei Ausfall? Bleibt die Not-Halt-Funktion auch unter Cyberstress wirksam? Welche Softwareänderung beeinflusst eine sicherheitsrelevante Funktion? Welche Nachweise braucht die CE-Dokumentation im Maschinenkontext?

Hier reicht es nicht, den CRA sauber umzusetzen und einen Haken zu setzen. Wer Maschinen baut, muss die Sicherheitsfunktion der Maschine mitdenken. Genau dort liegt die Grenze eines rein CRA-getriebenen Projekts.

Wo der CRA deutlich weiter geht

Der CRA macht aus punktueller Produktsicherheit einen dauerhaften Herstellerprozess.

Ein paar Themen sind für klassische Maschinenbauer neu oder zumindest ungewohnt:

• SBOM: maschinenlesbare Übersicht über Software-Komponenten, mindestens die direkten Abhängigkeiten nach CRA Anhang I Teil II Nummer 1; eine weitergehende Erfassung ist eine risikobezogene Umsetzungsempfehlung
• PSIRT: klarer Prozess für Schwachstellenbewertung, Kommunikation und Nachverfolgung
• CVD: geregelter Eingangskanal für externe Schwachstellenmeldungen
• Meldepflichten: Frühwarnung binnen 24 und Meldung binnen 72 Stunden ab Kenntnis. Bei aktiv ausgenutzten Schwachstellen beginnt die 14-Tage-Frist für den Abschlussbericht erst mit Verfügbarkeit einer Abhilfe- oder Risikominderungsmaßnahme; bei schwerwiegenden Vorfällen gilt ein eigener Monatszeitraum. Die Fristen und Meldewege sind getrennt zu planen.
• Security Advisories und CVE-Kommunikation: also öffentliche Sicherheitskommunikation, nicht nur interne Fehlerbearbeitung

Das ist kein kleiner Dokumentationsaufsatz. Das ist Betriebsmodell.

Wo viele Projekte falsch abbiegen

Der typische Fehler sieht so aus: Ein Team startet ein MVO-Projekt für CE und daneben ein CRA-Projekt für Cybersecurity. Beide bauen eigene Risikoanalysen, eigene Maßnahmenlisten, eigene Dokumente. Später stellt man fest, dass dieselben Themen doppelt bearbeitet wurden.

Das ist vermeidbar.

Die gemeinsame Mitte sollte einmal sauber aufgebaut werden. Danach trennen Sie bewusst: links die maschinenspezifischen MVO-Punkte, rechts die CRA-Pflichten über den Produktlebenszyklus. Genau so wird aus zwei Regelwerken kein doppeltes Projekt.

Wichtig ist nur die saubere Grenze: Der CRA hilft stark bei der MVO-Cybersecurity, ersetzt aber nicht die maschinenspezifischen Restanforderungen.

Wofür ich die Themenlandkarte konkret nutze

Ich nutze diese Darstellung in drei Situationen besonders häufig:

• im Vorstands- oder Geschäftsführungsbriefing, wenn in zehn Minuten klar werden muss, warum CRA und MVO zusammengehören
• im Kick-off mit Entwicklung, CE, Service und Produktmanagement, wenn zuerst ein gemeinsames Bild geschaffen werden muss
• in Schulungen, wenn ich den gemeinsamen Block erst vermittle und danach die Spezialthemen aufteile

Genau dafür ist die Seite gebaut: nicht als Dekoration, sondern als saubere Gesprächsgrundlage.

Wenn Sie CRA und MVO für Maschinen strukturiert zusammenführen wollen, finden Sie meine Leistung unter CRA & Maschinenverordnung. Ich begleite Maschinenbauer in Ulm, Neu-Ulm, Günzburg, Augsburg und deutschlandweit.