Cyber Resilience Act · Entwicklungsprozess-Check
CRA umsetzen.
Software wirksam schützen.
Wenn sich deine Firmware aus einem Updatepaket oder direkt aus dem Steuergerät auslesen lässt, lässt sie sich auch analysieren und reverse-engineeren. KI kann diesen Aufwand weiter reduzieren. Umso wichtiger ist eine Sicherheitsarchitektur, die Firmware, Schlüssel und Zugänge schützt.
Wir bewerten in einer Woche, wie dein Entwicklungsprozess Cybersecurity, Kryptografie und die relevanten CRA-Anforderungen abdeckt.
5 Arbeitstage
Ein ausgewähltes Produkt
Priorisierte Maßnahmen
Eine Woche. Ein konkreter Maßnahmenplan.
Wo steht dein Team beim CRA?
Hinterlasse deine Kontaktdaten. Wir besprechen Produkt, Umfang und Termin für euren CRA-Check.
Persönlicher Austausch über dein Produkt und deinen Entwicklungsprozess.
5 Arbeitstage Prozessbewertung
Cybersecurity & Kryptografie
Traceability & Nachweise
15+ Jahre Projekterfahrung
Funktionen nachbauen ist nur ein Teil
Kann jemand deine Firmware
einfach auslesen?
Ein unverschlüsseltes Firmware-Update oder ein auslesbares Steuergerät kann deine Implementierung offenlegen. Daraus lassen sich Algorithmen, Protokolle und interne Abläufe rekonstruieren. KI kann die Analyse unterstützen und das Nachbauen erleichtern.
Hier setzt eine durchdachte Sicherheitsarchitektur an: Sie erschwert das Auslesen der Firmware, schützt Schlüssel und kontrolliert Zugriffe. Signaturen und Secure Boot ergänzen den Schutz gegen manipulierten Code – allein machen sie die Firmware nicht vertraulich.
Der CRA adressiert die Cybersicherheit von Produkten. Schutz vor Nachbau bleibt eine zusätzliche Architektur- und Geschäftsfrage. Kryptografie kann Missbrauch erschweren, aber funktional ähnliche Software nicht grundsätzlich verhindern.
01
Firmware vor Auslesen schützen
Wir betrachten verschlüsselte Updatepakete, geschützte Debug- und Diagnosezugänge sowie hardwareabhängigen Ausleseschutz. Entscheidend ist, wo die Firmware entschlüsselt wird, wer darauf zugreifen kann und wie die Schlüssel geschützt sind.
02
Software und Updates authentifizieren
Signaturen sichern die Herkunft und Integrität von Software. Secure Boot kann die Ausführung unzulässig veränderter Firmware verhindern. Beide Maßnahmen müssen zur Vertrauenskette passen; sie verschlüsseln den Code nicht automatisch.
03
Identitäten und Zugriffe absichern
Geräteidentitäten, Authentifizierung und Autorisierung helfen, originale Geräte und berechtigte Nutzer von unbefugten Zugriffen zu unterscheiden.
04
Schlüssel und Daten schützen
Sichere Schlüsselablage, Provisionierung, Rotation und Widerruf gehören zum Konzept. Je nach Bedrohungsmodell kommen Secure Elements oder HSMs infrage.
Der CRA-Check von mars engineering
Wir prüfen den Prozess.
Und die Nachweise dahinter.
Wir betrachten den Entwicklungsprozess anhand eines ausgewählten Produkts. In Interviews und Stichproben prüfen wir, welche Abläufe bereits funktionieren, wo Nachweise fehlen und welche Themen zuerst angegangen werden sollten.
Wir bewerten Abläufe und ausgewählte Nachweise. Du erhältst priorisierte Lücken und konkrete nächste Schritte.
01
Risikoanalyse
& Security-Anforderungen
Wie werden Bedrohungen bewertet und daraus prüfbare Security-Anforderungen abgeleitet? Wir betrachten Produktgrenzen, Schnittstellen und die Nachverfolgung der Anforderungen.
Risikoanalyse · Bedrohungsmodell · Traceability
02
Architektur
& Kryptografie
Wie werden Schutzmaßnahmen begründet, umgesetzt und geprüft? Wir betrachten Prozesse und Nachweise zu Firmware-Verschlüsselung, Auslese- und Debug-Schutz, Schlüsselmanagement sowie Signaturen und Secure Boot.
Firmware-Schutz · Schlüssel · Vertrauenskette
03
Abhängigkeiten
& SBOM
Sind verwendete Komponenten bekannt und versioniert? Wir prüfen den Umgang mit Abhängigkeiten, die SBOM-Erstellung und die Bewertung gemeldeter Schwachstellen.
Komponenten · Versionen · Schwachstellen
04
Tests, Reviews
& Freigaben
Wie werden Security-Anforderungen geprüft? Wir betrachten Review-Regeln, Testnachweise, CI/CD und die Freigabe von Änderungen – auch für KI-generierten Code.
Reviews · Tests · Release-Prozess
05
Schwachstellen
& Sicherheitsupdates
Wer nimmt Meldungen entgegen, bewertet sie und stößt Maßnahmen an? Wir betrachten Zuständigkeiten, die Prüfung von CRA-Meldepflichten und die sichere Bereitstellung von Updates.
Meldungen · Verantwortlichkeiten · Updates
06
Dokumentation
& Produktlebenszyklus
Sind Risikoentscheidungen, Maßnahmen und Testergebnisse nachvollziehbar? Wir prüfen, wie technische Nachweise, Supportplanung und Änderungen über den Lebenszyklus gepflegt werden.
Nachweise · Support · Änderungsmanagement
CRA
Security by Design
Firmware-Schutz
Kryptografie
SBOM
Traceability
CI/CD
Security-Tests
Updates
Schlüsselmanagement
Nachweise
So läuft die Woche ab
Fünf Arbeitstage.
Konkrete nächste Schritte.
Der Check umfasst ein ausgewähltes Produkt und den zugehörigen Entwicklungsprozess. Vor dem Start stimmen wir Umfang, Ansprechpartner und benötigte Unterlagen ab.
Am Ende erhältst du:
- eine dokumentierte Bewertung je Prüffeld,
- priorisierte Lücken mit konkreten Beispielen,
- einen Maßnahmenplan mit Vorschlägen für Zuständigkeiten,
- eine gemeinsame Ergebnisbesprechung.
Die Bewertung erfolgt anhand von Interviews und Stichproben. Der Check ist keine vollständige Produktprüfung, kein Penetrationstest und kein Konformitätsnachweis.
01
Produkt und Prozess verstehen
Kick-off, Produktgrenzen, vorhandene Risikoanalyse und Entwicklungsabläufe. Wir halten offene Fragen zur CRA-Anwendbarkeit fest.
02
Architektur und Schutzmaßnahmen
Security-Anforderungen, Vertrauensgrenzen, Firmware- und Schlüsselzugriffe. Wir prüfen anhand ausgewählter Unterlagen, wie Ausleseschutz, Update-Verschlüsselung und Authentizität vorgesehen und nachgewiesen werden.
03
Implementierung, Tests und Releases
Stichproben zu Traceability, Reviews, Security-Tests und Build- beziehungsweise Release-Abläufen. Dazu der Umgang mit KI-generiertem Code.
04
Schwachstellen und Nachweise
SBOM, Bewertungs- und Meldewege, Updates, Supportplanung und technische Dokumentation. Wir identifizieren fehlende Abläufe und Belege.
05
Bewertung und Maßnahmenplan
Ergebnisse verdichten, Lücken priorisieren und mit dem Team besprechen. Du erhältst einen konkreten Ausgangspunkt für die weitere Umsetzung.
Markus Däschler
Geschäftsführer · mars engineering
Dein Ansprechpartner
Security muss in der
Entwicklung funktionieren.
Ich bin Markus Däschler. Seit über 15 Jahren unterstütze ich Softwareprojekte, in denen Architektur, Integration und nachvollziehbare Entwicklungsprozesse zusammenpassen müssen.
Dazu gehört praktische Erfahrung mit geschützter Fahrzeugdiagnose, AUTOSAR Crypto, HSM-Anbindung sowie ASPICE und Traceability.
Mit mars engineering schauen wir auf euren Entwicklungsalltag: Welche Entscheidungen sind begründet? Welche Schutzmaßnahmen sind überprüfbar? Und wo fehlen Zuständigkeiten oder Nachweise?
Softwarearchitektur · SFD · AUTOSAR Crypto · HSM · Tests · Traceability
Fristen im Blick
Die Meldepflichten
gelten bereits.
Der CRA betrifft Produktentwicklung und Betrieb über den Lebenszyklus. Prüfe jetzt, ob Meldewege, Zuständigkeiten und technische Nachweise dafür zusammenpassen.
01
Seit 11. September 2026
Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle nach den CRA-Vorgaben melden. Meldepflichten der EU-Kommission.
02
Ab 11. Dezember 2027
Die wesentlichen übrigen CRA-Anforderungen gelten grundsätzlich. Übergangsregeln und die konkrete Produktanwendbarkeit sind zu berücksichtigen. CRA-Überblick der EU-Kommission.
Kurz beantwortet
Fragen zum
CRA-Check.
Der CRA betrifft grundsätzlich auf dem EU-Markt bereitgestellte Produkte mit digitalen Elementen, deren vorgesehene oder vernünftigerweise vorhersehbare Nutzung eine direkte oder indirekte Datenverbindung zu einem Gerät oder Netzwerk umfasst. Ausnahmen und Sonderregelungen müssen produktbezogen geprüft werden. Im Vorgespräch grenzen wir den technischen Prüfgegenstand ab.
Wenn Firmware aus einem Update oder Gerät auslesbar ist, kann sie analysiert und reverse-engineert werden. Verschlüsselte Updatepakete, geschützte Schlüssel und hardwareabhängiger Ausleseschutz können die Extraktion erschweren. Signaturen und Secure Boot schützen hingegen die Herkunft und Integrität; sie ersetzen keine Vertraulichkeit. Im Prozesscheck bewerten wir das Konzept und ausgewählte Nachweise, nicht die praktische Widerstandsfähigkeit gegen jeden Extraktionsangriff. Der CRA selbst ist kein Kopierschutzgesetz.
Der Check bewertet euren Entwicklungsprozess und ausgewählte Nachweise. Er zeigt Lücken und priorisierte Maßnahmen. Er ersetzt weder die vollständige Produktbewertung noch das anwendbare Konformitätsbewertungsverfahren und stellt kein Zertifikat aus.
Für das ausgewählte Produkt benötigen wir verfügbare Prozessbeschreibungen, Anforderungen, Architekturunterlagen, Risikoanalysen, Beispiele für Test- und Release-Nachweise sowie Angaben zu Abhängigkeiten und Updates. Die Ansprechpartner für Entwicklung und Security sollten für abgestimmte Gespräche verfügbar sein. Fehlende Unterlagen machen wir als Lücken sichtbar.
Die Meldepflichten für Hersteller zu aktiv ausgenutzten Schwachstellen und schwerwiegenden Sicherheitsvorfällen gelten seit dem 11. September 2026. Die wesentlichen übrigen Anforderungen gelten grundsätzlich ab dem 11. Dezember 2027; Übergangsregeln und die konkrete Anwendbarkeit sind zu berücksichtigen. Informationen der EU-Kommission.
Ja. Nach dem Check können wir vereinbarte Arbeitspakete übernehmen: zum Beispiel Security-Anforderungen, Architektur, Kryptografie-Integration, Traceability, Tests oder die Automatisierung von Nachweisen. Die Umsetzung wird separat nach Umfang abgestimmt.
Wo steht eure Entwicklung beim CRA?
Lass uns über dein Produkt sprechen. Wir stimmen den Umfang ab und planen die Woche für euren Entwicklungsprozess-Check.
© mars engineering GmbH · Software für kritische Systeme
