CRA Beratung

Zuerst klären wir gemeinsam, welche Ihrer Produkte unter den CRA fallen und in welche Kritikalitätsklasse sie gehören – denn davon hängt ab, welche Pflichten gelten und ob für den Nachweis eine Prüfstelle hinzugezogen werden muss. Dabei schauen wir nicht nur auf das Produkt (Firmware, Update-Fähigkeit, Lieferkette), sondern auch auf die Prozesse im Unternehmen – etwa Meldewege und Schwachstellenmanagement, die nicht produktspezifisch, sondern einmal unternehmensweit aufgesetzt werden müssen. So erhalten Sie eine belastbare Grundlage, statt im Ungefähren zu planen. 

CRA-Betroffenheit in 2 Minuten klären

Ob Sie als Hersteller von Hardware, Software oder vernetzten Produkten unter den Cyber Resilience Act fallen und wie dringend Handlungsbedarf besteht, hängt von Ihrer Ausgangslage ab. Unser kostenloses Online-Assessment zeigt Ihnen in rund zwei Minuten, wo Sie stehen und was als Nächstes ansteht.

In einer strukturierten Risikoanalyse (Threat & Risk Assessment) bewerten wir Ihre Produktarchitektur gegen die relevanten Bedrohungen und gleichen die Anforderungen des CRA ab. Wir priorisieren die Maßnahmen nach Risiko und Umsetzbarkeit, damit Sie Ihr Budget dort einsetzen, wo es den größten Sicherheits- und Compliance-Effekt hat – genau diese Herleitung verlangt der CRA auch für die technische Dokumentation. 

Security by Design ist zuerst ein Prozessthema: Es bedeutet, sich schon in der Designphase systematisch mit Sicherheit zu befassen, statt sie später nachzurüsten. Genau das bieten wir als sicheren Software- und Produktentwicklungsprozess an – etwa aufgebaut mit MAN Truck & Bus. Aus diesem Prozess heraus entstehen die technischen Grundlagen, die der CRA über den gesamten Lebenszyklus fordert: von Secure Boot über gehärtete Kommunikation bis zu einer updatefähigen, langfristig wartbaren Architektur. 

Ein Beispiel dafür ist Krypto-Agilität: Ein Gerät, das 2027 in den Markt geht und zehn Jahre laufen soll, muss aktualisiert werden können und dabei bei Bedarf das Signaturverfahren wechseln – etwa beim Umstieg auf quantensichere Verfahren. Wer Speicher und Update-Bandbreite ohne Reserve dimensioniert, kann diesen Wechsel später nicht mehr vollziehen. Möglich wird dieser Wechsel überhaupt erst durch Updatefähigkeit – und die ist eine von mehreren technischen Mindestanforderungen, nicht die einzige. Welche Maßnahmen ein Produkt tatsächlich braucht, ergibt sich risikoorientiert aus der Bedrohungsanalyse. 

Wir integrieren die Erstellung einer maschinenlesbaren Software Bill of Materials in Ihren Build-Prozess und etablieren ein kontinuierliches Schwachstellen-Management inklusive CVE-Tracking. Zusätzlich helfen wir, die ab September 2026 geltende Meldepflicht prozessual sauber abzubilden.

Dabei ist die Meldepflicht weniger ein Compliance- als ein Engineering-Thema: Sie ist dreistufig — eine Frühwarnung binnen 24 Stunden, eine ausführliche Meldung binnen 72 Stunden und ein Abschlussbericht binnen 14 Tagen nach Verfügbarkeit einer Lösung. Die 24-Stunden-Frist läuft in Kalenderzeit, nicht in Arbeitstagen. Wer freitagabends von einer aktiv ausgenutzten Schwachstelle erfährt, muss am Samstag melden.

Voraussetzung dafür ist überhaupt erst, dass ein Vorfall erkannt wird: Man muss bemerken, dass eine Schwachstelle aktiv ausgenutzt wird – das setzt ein funktionierendes Incident Management voraus. Damit die Meldung dann gelingt, müssen drei Dinge vorab geklärt sein: eine benannte, auch außerhalb der Geschäftszeiten erreichbare Rolle mit Mandat zur Meldung; ein Meldekanal für Sicherheitsforscher, Kunden und den eigenen Support samt laufender Beobachtung der eingesetzten Komponenten; und ein Device Management, das jederzeit beantwortet, welche Geräte in welchem Softwarestand im Feld sind. Am letzten Punkt hängen die meisten Hersteller – und genau diese Fähigkeit baut MaibornWolff mit auf. 

Der CRA verlangt Security-Updates über Jahre. Wir bauen die dafür nötige Over-the-Air-Update-Infrastruktur mit Staging, Rollback und Fleet-Analytics — bewährt in Produktflotten mit über einer Million Geräten. So schließen Sie Schwachstellen zuverlässig, statt Techniker ins Feld schicken zu müssen.

Ob sich eine Update-Strecke überhaupt nachrüsten lässt, hängt an drei Dingen: freiem Flash-Speicher für ein zweites Firmware-Abbild, einem Bootloader, der den Rückfall auf den alten Stand erlaubt, und einem Weg, auf dem das Update das Gerät auch dann erreicht, wenn es selten online ist. Das erklärt zugleich, warum Sicherheitsupdates in der Praxis oft nicht eingespielt werden: Ohne Rückfallpfad kann ein fehlgeschlagenes Update das Wartungsfenster sprengen und die Anlage stoppen. Genau deshalb denkt MaibornWolff den Rückfallpfad von Beginn an in der Architektur mit.