_Flag_Emoji.png){kind=small}
CRA Product Security Engineering
Mehr als Prozessberatung: Der CRA verlangt Produkt-Security, die hält, was Dokumente behaupten
BreachLabz unterstützt Ihr Security Engineering: Firmware auseinandernehmen, Angriffswege finden, Sicherheit einbauen, Wirksamkeit nachweisen. Risikobewertung, Prozesse, Dokumentation und Konformität entstehen mit – Ihr Team beherrscht am Ende alles selbst.
admin:admin ist jetzt ein Fall für §EU-CRA Anhang I Teil I Nr. 2 lit. b
Sichere Voreinstellungen, signierte Updates, keine bekannten Schwachstellen bei Auslieferung: Diese Produktanforderungen des EU-CRA gelten ab dem 11. Dezember 2027. Eine Pflicht gilt aber schon heute, und sie betrifft nicht das Produkt, sondern Sie als Organisation: die Meldepflicht.
Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle melden: Erstwarnung binnen 24 Stunden, Detailmeldung binnen 72 Stunden, Abschlussbericht nach 14 Tagen bzw. einem Monat. Gemeldet wird über die Single Reporting Platform der ENISA, die an das nationale CSIRT weiterleitet, in Deutschland das BSI.
Oft übersehen: Das gilt nicht nur für neue Produkte, sondern für alles, was heute schon im Feld ist, über den gesamten Supportzeitraum von mindestens fünf Jahren.
Erfüllen können Sie die Pflicht nur, wenn Sie wissen, was in Ihrem Produkt steckt und ob eine gemeldete Schwachstelle Sie überhaupt betrifft. Das ist keine reine Prozessfrage, sondern Arbeit am Produkt, mit einem Prozess drumherum, der auch nachts um drei trägt.
Ihr Produkt muss am 11.12.2027 konform sein. Ihre Organisation muss seit dem 11.09.2026 meldefähig sein. Noch nicht ready? Dann fangen wir damit an.
Wir haben Cybersecurity-Regulierung bereits durchgezockt: BreachLabz für CRA-konforme Product-Security
Der CRA ist für die meisten Hersteller neu. Für uns ist er die zweite Runde. UN R155 und ISO/SAE 21434 haben die Fahrzeugindustrie vor Jahren durch dasselbe Nadelöhr geschickt: Nachweispflicht über den Lebenszyklus, Schwachstellenmanagement, Risikobewertung, prüffeste Dokumentation.
Mit langjähriger Praxiserfahrung in der weltweiten Fahrzeug-Lieferkette, die in nahezu jede weitere Industrie hineinreicht, haben wir unser Know-How bereits unter Beweis gestellt. Wir kennen die Hürden, vor denen Hersteller jetzt stehen, und wissen aus der Projekterfahrung, wie man sie meistert.
Lötkolben statt Powerpoint-Pitch
Rund 100 Pentest-Projekte an echter Hardware, für namhafte Kunden weltweit, stets unter Zeitdruck. Wir reden lieber über Ergebnisse als über Kundenlogos. Man kennt uns.
Firmware Reverse Engineering, Hardware-Angriffe, Fault Injection, Secure Boot, Update-Pfade, Backend und Schnittstellen. Dazu Risikobewertung und SBOM-Tooling.
Team und Pentest-Labor in München und Bangalore. Kurze Wege, keine Weiterreichkette, keine Junior-Besetzung nach dem Kick-off. Wer das Projekt gewinnt, macht es auch.
So arbeiten Sie mit BreachLabz rund um den CRA
Vier Prinzipien, die unsere Projekte von klassischer Beratung unterscheiden: Wir liefern Code statt Dokumente, passen uns Ihrem Tempo an, sprechen Technik und Regulatorik, und bringen mit, was andere schon falsch gemacht haben.
Im Repo, nicht im Meeting
Wir arbeiten in Ihrem Git, bauen die Firmware selbst und reichen Pull Requests ein. Keine Übergabedokumente. Das Ergebnis läuft am Montag, statt in einem PDF zu stehen.
Im Takt Ihres Teams
Wir arbeiten in Ihren Sprints, mit Ihrer Toolchain, ohne neuen Prozess vorab. „Security hält uns auf" lässt Projekte intern scheitern. Wir widerlegen den Satz.
Eine Person, beide Sprachen
Ihr Ansprechpartner redet mit der Firmware-Entwicklung über Bootloader-Partitionen und mit Regulatory Affairs über Anhang VII. Keine Übersetzungsschleife. Das verkürzt alles.
Wir kennen die Fehler anderer
Wir wissen, woran Secure Boot ganze Teams scheitern lässt, wie Lieferanten auf Meldungen reagieren und was in keiner Norm steht. Das überzeugt mehr als jede Zertifikatsliste.
BreachLabz Security Engineering: Wir begleiten Ihre Produktentwicklung nach CRA-Vorgaben
Deshalb arbeiten wir direkt am Gerät. Wir ziehen die Firmware, rekonstruieren, was tatsächlich verbaut ist, gleichen gegen bekannte Schwachstellen ab und prüfen, ob ein Angriff im konkreten Produkt wirklich funktioniert. Anschließend unterstützen wir Sie bei der Behebung und testen jeden Fix nach.
Reale Risiken checken. Statt Checklisten.
CRA beginnt am Produkt. Nicht mit einer PDF. Rund um den CRA entsteht gerade ein beachtlicher Markt aus Reifegradmodellen, Maßnahmenkatalogen und Checklisten mit 13 Häkchen. Nur beantwortet keines dieser Dokumente die Frage, die im Ernstfall zählt: Ist mein Produkt angreifbar, und wenn ja, wie genau?
Was Sie bereits haben, verwerten wir: Vorhandene Nachweise und Maßnahmen inventarisieren wir, ordnen sie den CRA-Anforderungen zu und schließen gezielt die Lücken, die danach übrig bleiben. Meistens sind das deutlich weniger, als marktübliche CRA-Beratungsangebote vermuten lassen.
Ein Pentest löst keine Meldepflicht nach Artikel 14 aus. Meldepflichtig sind nur aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle, nicht Funde aus Tests oder Sicherheitsforschung. Testen erzeugt kein regulatorisches Risiko. Testen senkt es.
./cra --scope=your_product --mode=hands_on
Vier Einstiege. Einzeln buchbar, aufeinander bezogen. Wo Sie einsteigen, hängt davon ab, was Sie schon haben. Was Sie am Ende in der Hand halten, ist immer dasselbe: ein Produkt, über das Sie Bescheid wissen, Nachweise, die ein Prüfer lesen kann, und ein Team, das es ohne uns weiterbetreiben kann.
Wer wann was CRA-konform meldet, steht fest, bevor es brennt
Für alle, die seit 09/2026 meldepflichtig sind und noch nicht wissen, wer wann was entscheidet.
Wir analysieren Ihren Status quo, definieren Auslösekriterien, Eskalationsweg und Befugnisse und liefern Meldetemplates für alle Fristen. Wir klären den Zugang zur ENISA-Plattform und spielen den Ernstfall als Tabletop durch.
Dazu die CVD-Policy mit öffentlichem Meldekanal, das einzige Prozessdokument, das der CRA namentlich verlangt. Wie viel Sie selbst machen und wie viel wir, legen wir gemeinsam fest.
Ergebnis: Meldeprozess, Rollenmodell, Templates, CVD-Policy, Testprotokoll
Vom Bauchgefühl zur CRA-Roadmap: Klassifizierung, Risiko, Gap-Analyse
Für alle, die erst Klarheit über CRA-Betroffenheit und Aufwand brauchen. Wir prüfen und klassifizieren Ihre Produkte, empfehlen das Konformitätsverfahren, legen die Produktgrenze fest und erstellen Cyber-Risikobewertung und Gap-Analyse gegen Anhang I.
Vorhandenes nutzen wir: Eine bestehende Risikobewertung reviewen wir auf CRA-Belastbarkeit, Fehlendes setzen wir mit passender Methodik und Tooling auf. Bei Bestandsprodukten klären wir, was bis 12/2027 ansteht und was erst bei wesentlicher Änderung.
Ergebnis: Scoping, Klassifizierung, Risikobewertung, Gap-Report, priorisierte Roadmap
Wir röntgen Ihr Produkt und zeigen, welche Schwachstellen Sie wirklich treffen
Für alle, die nicht sicher sind, was in ihrem Produkt steckt. SBOM/HBOM aus dem tatsächlichen Artefakt: Binary- und Source-Analyse, Abgleich gegen bekannte Schwachstellen, Bewertung der realen Ausnutzbarkeit im Produktkontext, CRA-konformes Risikobild.
Die Tiefe legen wir gemeinsam fest: Der CRA verlangt mindestens die direkt eingebundenen Komponenten, das Vulnerability Management profitiert oft von mehr. Was wir rekonstruieren konnten und was nicht, steht im Report, nicht zwischen den Zeilen.
Ergebnis: SBOM (SPDX/CycloneDX), CVE-Abgleich, Exploitability-Bewertung (optional VEX), Risikobild, Build-Integration
Von der Architektur über den Pentest bis zum laufenden Schwachstellenbetrieb
Für alle, die an ihrer Produkt-Security arbeiten: Requirements, Architektur, Secure Boot, Update- und Rollback-Pfade, Remediation. Wir entwickeln mit oder begleiten Ihr Team, immer so, dass es danach allein kann: Doku, die Entwickler lesen, Ownership als Projektziel.
Dazu unser Kern: Pentest und Produktsicherheitsanalyse mit Fix-Nachtest und Testbericht. Danach der Dauerbetrieb: Schwachstellen-Monitoring, Triage, Meldeunterstützung, mit Ihrem oder unserem Tooling, erreichbar, wenn es brennt.
Ergebnis: Anforderungen, Design, Testberichte, Doku nach Anhang VII, laufendes Vulnerability Handling
Passt alles nicht zu Ihren CRA-Needs?
Das CRAzy. Wir arbeiten auch punktuell, als Verstärkung Ihres Teams oder als benannte Rolle auf Zeit. Sprechen Sie mit uns.
So läuft der Einstieg in Ihr CRA-Projekt mit BreachLabz ab
Warum BreachLabz?
Frequently asked questions
Fällt mein Produkt überhaupt unter den CRA?
Faustregel: Sobald ein Produkt Daten verarbeitet und sich direkt oder indirekt mit einem Gerät oder Netz verbinden kann, ist es im Zweifel ein Produkt mit digitalen Elementen (PwDE). Ein reiner SaaS-Dienst ohne lokale Komponente dagegen nicht, der fällt gegebenenfalls unter NIS2. Eine App, die ohne Ihr Backend nicht funktioniert, ist zusammen mit dem Backend ein Produkt. Wir klären das in der Betroffenheitsprüfung.
Wir sind seit 09/2026 meldepflichtig und haben noch keinen Prozess. Wie schlimm ist das?
Schlimm genug, um jetzt anzufangen, nicht schlimm genug für Panik. Die Meldefähigkeit verlangt einen definierten Prozess, keine fertige Produktkonformität. Das lässt sich in Wochen aufbauen. Für die volle Konformität bis Dezember 2027 hängt es vom Produkt ab, dafür machen wir die Gap-Analyse.
Ist BreachLabz eine notifizierte Stelle?
Nein, und das ist Absicht. Wir prüfen und bauen. Die Konformitätsbewertung durch eine notifizierte Stelle ist ein getrennter Schritt, den wir vorbereiten und begleiten. Für die meisten Produkte in der Standardkategorie reicht ohnehin die Selbstbewertung, mit vollständiger technischer Dokumentation.
Was ist mit unseren Bestandsprodukten?
Die Meldepflichten gelten ausnahmslos, auch für alles, was vor dem Stichtag in Verkehr gebracht wurde. Die übrigen CRA-Anforderungen greifen bei Altprodukten grundsätzlich erst bei wesentlicher Änderung nach dem 11.12.2027. Was als wesentliche Änderung zählt, ist Auslegungssache. Wir dokumentieren die Annahme mit Ihnen.
Löst ein Pentest bei uns eine Meldepflicht aus?
Nein. Meldepflichtig sind aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle. Funde aus Penetrationstests und /Ethical/ Sicherheitsforschung sind ausdrücklich ausgenommen.
Müssen wir die SBOM veröffentlichen?
Nein. Die SBOM ist ein internes Dokument, das Sie der Marktüberwachungsbehörde auf begründete Anfrage vorlegen. Veröffentlichen müssen Sie die CVD-Policy, also den Weg, über den Externe Ihnen Schwachstellen melden können.
Welche Normen legt BreachLabz im CRA-Doing zugrunde?
Die, mit denen man heute sinnvoll arbeiten kann: BSI TR-03183 als Basis, die EN-40000-Entwürfe als Richtung, ISO/IEC 29147 und 30111 für das Schwachstellen-Handling. Eine Vermutung der Konformität gibt es erst, wenn eine Norm im Amtsblatt steht. Bis dahin dokumentieren wir Anforderung für Anforderung, wie Ihr Produkt sie erfüllt oder warum sie nicht zutrifft.
Ersetzt BL unser Team?
Nein. Wir arbeiten im Repo, in Ihren Sprints, mit Ihrer Toolchain, und das Ziel jeder Maßnahme ist, dass Ihr Team sie danach allein betreibt. Wenn Sie uns später nicht mehr brauchen, findet man uns wieder in GTA VI.
Was kostet das?
Kommt auf Produkt, Ausgangslage und Umfang an. Wir stellen Pakete, Deliverables und Angebot bedarfsgerecht zusammen und geben Ihnen nach einem kurzen Gespräch eine belastbare Einschätzung. Der Zwei-Wochen-Einstieg ist bewusst so geschnitten, dass die Entscheidung leicht fällt.
Arbeiten Sie remote?
Meistens. Hardware kommt zu uns ins Labor nach München/Bangalore, der Rest lässt sich remote effizienter abwickeln. Vor Ort geht aber auch.
Get a quote today!
Schicken Sie uns ein paar Eckdaten: Was ist das für ein Produkt, was steckt an Software drin, wo steht es im Markt, und was drückt gerade am meisten.
Wir melden uns innerhalb von 24 bis 48 Stunden und sagen Ihnen ehrlich, ob wir die Richtigen sind.
Bereit zum Kennenlernen? Sprechen Sie noch heute mit uns.