Wir machen regulatorische Anforderungen technisch umsetzbar.
Wir unterstützen Hersteller digitaler Produkte bei CRA-Betroffenheit, Gap-Analyse, Anforderungskatalog und technischer Umsetzung. Besonders für Embedded Linux, Legacy-Code, OSS-Abhängigkeiten und systemnahe Software.
Frage 1
Ergebnis mit sodge IT besprechenTechnischer Erstabgleich für Hersteller digitaler Produkte
Beantworten Sie einige Fragen zu Produkt, Bereitstellung und Pflege. Der Check gibt erste Hinweise zu CRA-Betroffenheit und typischen Umsetzungsfeldern.
Hinweise zu möglichen Umsetzungsfeldern erscheinen hier gesammelt.
Produkte mit Firmware, Embedded Linux oder gerätenaher Software, bei denen Sicherheit, Updates und Lifecycle-Themen früh technisch mitgedacht werden müssen.
Systeme mit eigener Plattform, Build-Umgebung oder Appliance-Charakter, bei denen SBOM, Härtung, Pflege von Komponenten und Release-Prozesse zusammenkommen.
Gewachsene Produkte mit Altlasten, langen Lebenszyklen und historisch gewachsenen Prozessen, die CRA-tauglich gemacht werden müssen, ohne das Produkt neu zu erfinden.
| Verbindliche Produktanforderungen | Cybersicherheit wird Teil der Produktanforderungen und darf nicht erst kurz vor dem Inverkehrbringen betrachtet werden. |
| Schwachstellenmanagement als Pflicht | Hersteller müssen Meldungen, Bewertung, Behebung und Kommunikation von Schwachstellen belastbar organisieren. |
| Technische Nachweise und Dokumentation | Entscheidungen, Maßnahmen und Produktinformationen müssen nachvollziehbar dokumentiert und über die Zeit pflegbar gehalten werden. |
| Pflege über den Lebenszyklus | Sicherheitsupdates, Supportzeiträume und Betriebsfähigkeit werden zu einem festen Teil der Produktverantwortung. |
Wir verbinden CRA-Verständnis mit echter Produktentwicklung. Statt abstrakter Empfehlungen arbeiten wir an den Stellen, an denen Umsetzung im Alltag schwierig wird: Architektur, Code, Build- und Release-Prozesse, OSS-Abhängigkeiten, SBOMs, Schwachstellenmanagement und technische Dokumentation. Unser Fokus liegt auf technischer Umsetzung und belastbarer regulatorischer Einordnung, nicht auf Rechtsberatung im Einzelfall.
| Betroffenheit, Erstbewertung und Gap-Analyse |
Fällt unser Produkt unter den CRA und wo stehen wir technisch? Wir schauen gemeinsam auf Produktgrenzen, Marktrolle, Einsatzkontext, Architektur und Entwicklungsstand. Daraus entsteht eine erste technische und regulatorische Einordnung mit Blick auf die größten Lücken und Risiken.
Ergebnis: belastbare Ersteinschätzung, priorisierte Gap-Liste und klare nächste Schritte für Produkt, Organisation und Entwicklungsteam.
|
| Anforderungskatalog und Umsetzungsplan |
Was müssen wir konkret ändern, nachweisen oder vorbereiten? Wir übersetzen CRA-Anforderungen in konkrete technische und organisatorische Arbeitspakete. Dabei priorisieren wir nach Produktrealität, Risiko, Umsetzbarkeit und vorhandenen Entwicklungsprozessen.
Ergebnis: technischer Anforderungskatalog, priorisierte Maßnahmenliste, Verantwortlichkeiten und ein pragmatischer Umsetzungsplan.
|
| Technische Umsetzung im Produkt |
Wie bekommen wir die Maßnahmen in Code, Build und Release-Prozess? Wir unterstützen direkt in Architektur, Codebasis, Build-Umgebung und Tooling. Das reicht von SBOM- und OSS-Transparenz über Härtung, Fuzzing, SAST/SCA und Update-Strategien bis zur Modernisierung kritischer Legacy-Stellen.
Ergebnis: umgesetzte Security-, Build-, SBOM- oder Update-Maßnahmen, technische Nachweise und weniger schwer beherrschbare Altlasten.
|
| Schwachstellenmanagement und Meldeprozesse |
Wie reagieren wir sauber auf CVEs, Meldungen und mögliche Meldepflichten? Wir helfen beim Aufbau pragmatischer Prozesse für Vulnerability Handling, Disclosure, Triage und die Zusammenarbeit zwischen Entwicklung, Produktverantwortung und Compliance. Bei Meldepflichten unterstützen wir technisch und organisatorisch; Rollen und rechtliche Verantwortung müssen kundenspezifisch sauber geregelt werden.
Ergebnis: funktionierender Meldeweg, Triage- und Bewertungsprozess, Vorlagen für technische Bewertung und nachvollziehbare Entscheidungswege.
|
| Begleitung über den Produktlebenszyklus |
Wer behält Abhängigkeiten, Updates und Security-Themen dauerhaft im Blick? Auf Wunsch übernehmen oder begleiten wir laufende produktnahe Aufgaben: Monitoring von CVEs und Advisories, Triage, Pflege von Komponentenübersichten, Wartung einzelner Bibliotheken, Reviews, Update-Entscheidungen und Abstimmung mit Entwicklungsteams.
Ergebnis: laufende CRA-nahe Betreuung mit Nähe zu Code, Releases, Abhängigkeiten und Produktlebenszyklus statt generischem Managed-Security-Angebot.
|
Wir kommen aus der technischen Produktentwicklung und sprechen mit Entwicklungsabteilungen auf Augenhöhe. Unsere Stärke liegt dort, wo CRA-Anforderungen auf Embedded-Systeme, Linux-Plattformen, Legacy-Code, OSS-Abhängigkeiten und reale Release-Prozesse treffen.
Seit mehr als 10 Jahren unterstützen wir Hersteller und Softwareteams im DACH-Raum bei C, C++, C#, Rust und Go, von Bare Metal bis Cloud. Wir arbeiten gerne an den schwierigen Stellen: Altlasten verstehen, Ursachen sauber analysieren und Lösungen so umsetzen, dass sie im Produktalltag funktionieren. Dazu bringen wir Erfahrung in Software Security, Open Source, CI/CD und technisch sinnvollen Entwicklungsprozessen mit.
Unterstützung von Entwicklungsabteilungen bei Produkten, Plattformen und langlebiger Software im DACH-Raum.
C, C++, C#, Rust und Go, Embedded, Linux, Legacy-Modernisierung, Backend und Build-Infrastruktur.
Fuzzing, SCA, SAST, CI/CD, SBOM-nahe Komponentenübersichten und Schwachstellen-Triage mit Blick auf reale Releases.
Wir nutzen, pflegen und veröffentlichen Open Source und behalten Abhängigkeiten und Pflegezustand im Blick.
Kollegen aus unserem Team bringen sich in Normungsarbeit und fachlichen Austausch rund um CRA-nahe Themen ein.
Wir suchen Ursachen, machen Bestandscode beherrschbar und bevorzugen tragfähige Lösungen vor kurzfristigen Workarounds.
Kurzantworten für Hersteller, die CRA-Pflichten technisch einordnen und die nächsten Schritte planen wollen.
Die wichtigsten Eckdaten für den ersten Überblick.
Der Cyber Resilience Act ist die EU-Verordnung 2024/2847 zu horizontalen Cybersicherheitsanforderungen für Produkte mit digitalen Elementen. Sie ist am 10. Dezember 2024 in Kraft getreten.
Betroffen sind vor allem Hersteller von Produkten mit digitalen Elementen, die im Rahmen einer Geschäftstätigkeit auf dem EU-Markt bereitgestellt werden. Ob der CRA greift, hängt vom konkreten Produkt, Einsatzzweck, Marktrolle und möglichen Bereichsausnahmen ab.
Die Meldepflichten nach Artikel 14 gelten ab dem 11. September 2026. Die Hauptpflichten, also insbesondere Konformitätsbewertung, CE-Kennzeichnung und allgemeine Produktanforderungen, gelten ab dem 11. Dezember 2027.
Je nach Produkt gehören dazu Sicherheitsanforderungen an Entwicklung und Produktdesign, technische Dokumentation, Schwachstellenmanagement, Meldepflichten und Sicherheitsupdates über den vorgesehenen Unterstützungszeitraum.
CRA-Umsetzung ist selten nur Papierarbeit. Oft sind Build-Prozesse, Abhängigkeiten, Update-Mechanismen, Dokumentation und Verantwortlichkeiten betroffen. Frühes Handeln verteilt Aufwand und reduziert späte Hauruck-Aktionen.
Fehlende Konformität kann zu regulatorischen Maßnahmen, Marktproblemen und erheblichem Nachbesserungsaufwand führen. Meist ist der erste sinnvolle Schritt, technische und organisatorische Lücken sichtbar zu machen und priorisiert abzuarbeiten.
Was für vorhandene Produkte, Pflegezeiträume und spätere Änderungen wichtig wird.
Grundsätzlich ja, aber die genaue Marktrolle ist wichtig. Für Produkte, die bereits vor dem 11. Dezember 2027 in Verkehr gebracht wurden, greifen die CRA-Hauptpflichten nicht allein deshalb nachträglich, weil Restbestände weiter bereitgestellt oder weitervertrieben werden.
Anders kann es aussehen, wenn ein Produkt ab diesem Datum erstmals auf dem EU-Markt in Verkehr gebracht oder später wesentlich geändert wird. Die Meldepflichten nach Artikel 14 gelten ab dem 11. September 2026 auch für zuvor in Verkehr gebrachte Produkte, soweit die Voraussetzungen erfüllt sind.
Gemeint sind Änderungen nach dem Inverkehrbringen, die die Konformität mit grundlegenden Cybersicherheitsanforderungen beeinflussen oder den vorgesehenen Verwendungszweck verändern können.
Nicht jedes Update ist automatisch wesentlich. Reine Sicherheits- oder Fehlerbehebungsupdates sind typischerweise nicht schon deswegen wesentlich; bei Feature-Erweiterungen, Plattformwechseln oder tiefen Eingriffen in Sicherheitsfunktionen lohnt sich eine saubere Einzelfallbewertung.
Der Unterstützungszeitraum orientiert sich daran, wie lange das Produkt voraussichtlich genutzt wird. Grundsätzlich beträgt er mindestens fünf Jahre; ist die erwartete Nutzungsdauer kürzer, kann auch der Unterstützungszeitraum entsprechend kürzer sein.
Bei Produkten mit längerer erwarteter Nutzung kann der erforderliche Zeitraum entsprechend länger ausfallen. Hersteller sollten diese Bewertung nachvollziehbar festlegen und dokumentieren.
Ja. Der CRA steht Sicherheitsupdates für ältere Produkte nicht entgegen. Für Softwareprodukte sieht er außerdem vor, dass Hersteller frühere Versionen unter bestimmten Voraussetzungen auf eine zuletzt in Verkehr gebrachte Version führen und öffentliche Softwarearchive weiter betreiben können.
Legacy ist nicht automatisch ein Verbot oder Makel. Kritisch wird es dort, wo unklare Abhängigkeiten, fehlende Build-Reproduzierbarkeit, alte Komponenten oder fehlende Update-Wege verhindern, dass Risiken bewertet und Sicherheitsprobleme praktisch behoben werden können.
In vielen Fällen geht es zuerst um eine realistische Risiko- und Gap-Analyse, danach um punktuelle Härtung, bessere Pflegeprozesse, gezielte Modernisierung oder eine klare End-of-Life-Strategie.
Technische Bausteine, die in Vorbereitung und Nachweisführung helfen.
Die CRA-Anforderungen zur technischen Dokumentation und zum Umgang mit Komponenten greifen grundsätzlich ab dem 11. Dezember 2027. Eine SBOM oder belastbare Komponentenübersicht ist aber schon jetzt hilfreich, um Betroffenheit, Risiken und technische Lücken sichtbar zu machen.
Praktisch lohnt sich der frühe Start, weil Komponenten- und Versionsklarheit auch für Gap-Analyse, Meldeprozesse und spätere Reaktion auf Schwachstellen gebraucht wird.
Ja. Der CRA verbietet weder die Nutzung noch die Mitarbeit an Open Source. Wenn Sie ein kommerziell bereitgestelltes Produkt mit digitalen Elementen auf den Markt bringen, bleiben Sie aber für dessen CRA-Konformität verantwortlich, auch wenn Open-Source-Komponenten enthalten sind.
Der CRA nennt keine pauschale Frist, nach der jede CVE immer in derselben Zeit behoben sein muss. Hersteller müssen Schwachstellen während des Unterstützungszeitraums aber wirksam handhaben und Sicherheitsprobleme ohne unangemessene Verzögerung adressieren.
Meldepflichtig sein können insbesondere aktiv ausgenutzte Schwachstellen sowie schwere Sicherheitsvorfälle nach Artikel 14. Diese Fristen gelten nicht für jede einzelne Alltagsmeldung, reichen aber über klassische CVE-Fälle hinaus.
Diese Methoden verhindern Haftung oder Compliance-Probleme nicht automatisch. Sie helfen aber, Risiken früh zu erkennen, typische Fehlerklassen zu reduzieren und Sicherheitsprobleme nachvollziehbar zu behandeln.
Entscheidend ist nicht das Abhaken von Schlagworten, sondern dass Maßnahmen zu Produkt, Architektur, Risiko und realer Pflegefähigkeit passen.
Kontextfragen, die wichtig sind, aber eine Einzelfallbewertung nicht ersetzen.
Ja, wenn die Software als Produkt mit digitalen Elementen in den CRA-Anwendungsbereich fällt und ab dem 11. Dezember 2027 auf dem EU-Markt in Verkehr gebracht wird.
Bei Software bedeutet CE-Kennzeichnung aber nicht zwingend einen physischen Aufkleber. Je nach Bereitstellungsform kann sie typischerweise auch in der Benutzeroberfläche, auf der Website, auf der Verpackung, in begleitenden Unterlagen oder in der EU-Konformitätserklärung erfolgen.
Distributoren und Importeure haben eigene Sorgfalts- und Prüfpflichten, etwa zu CE-Kennzeichnung und erforderlichen Unterlagen. Unter bestimmten Umständen können sie selbst wie Hersteller behandelt werden.
Das ist besonders relevant, wenn ein Produkt unter eigenem Namen oder eigener Marke bereitgestellt, in eigene Lösungen integriert oder wesentlich verändert wird.
Der CRA regelt vor allem Pflichten für Hersteller: Produktanforderungen, Prozesse, Dokumentation, Schwachstellenmanagement und Pflege. Die aktualisierte Produkthaftungsrichtlinie regelt, wann Hersteller für Schäden durch fehlerhafte Produkte haften.
Ein CRA-Verstoß führt nicht automatisch zur Haftung im Einzelfall. Er kann aber ein starkes Indiz dafür sein, dass ein Produkt nicht das Sicherheitsniveau bietet, das man vernünftigerweise erwarten darf.
Die aktualisierte Produkthaftungsrichtlinie bezieht Software ausdrücklich mit ein. Relevant werden damit auch Fehler in Software, problematische Updates oder fehlende sicherheitsrelevante Updates, soweit diese im Einflussbereich des Herstellers liegen.
PLD ist hier Kontext zum CRA, nicht unser Hauptangebot. Für verbindliche rechtliche Bewertungen sollte juristische Expertise eingebunden werden.
Wie wir aus der regulatorischen Frage technische Arbeitspakete machen.
Wir unterstützen bei Betroffenheit, Gap-Analyse, Anforderungskatalog, technischer Umsetzung im Produkt sowie beim Aufbau von Schwachstellen- und Pflegeprozessen. Unser Schwerpunkt liegt auf realer technischer Umsetzbarkeit.
Dabei helfen wir bei technischer Umsetzung und regulatorischer Einordnung, ersetzen aber keine Rechtsberatung im Einzelfall. Bei Bedarf arbeiten wir mit rechtlicher Expertise auf Kundenseite oder über Partner zusammen.
Ja. Wir kommen aus der Softwareentwicklung und unterstützen nicht nur mit Konzepten, sondern auch in Architektur, Codebasis, Build-Systemen, CI/CD, Tests, Update-Mechanismen und technischer Dokumentation.
Das reicht von punktueller Unterstützung bei einzelnen Maßnahmen bis zur engeren Begleitung von Entwicklungsteams.
Ja, wenn es zum Produkt und zur Organisation passt. Wir können laufend bei CVE- und Advisory-Monitoring, Triage, Bewertung von Schwachstellen, Pflege von Komponentenübersichten und Vorbereitung von Security-Updates unterstützen.
Auch die Betreuung einzelner Bibliotheken, produktkritischer Komponenten oder wiederkehrender Vulnerability-Management-Aufgaben ist möglich. Rollen, Verantwortlichkeiten und Meldepflichten sollten dabei sauber mit dem Kunden abgegrenzt werden.
Ja. Gerade bei gewachsenen Produkten helfen wir, Build- und Release-Wege wieder beherrschbar zu machen, alte Abhängigkeiten zu bewerten, unnötigen Code zu identifizieren und Modernisierungsschritte realistisch zu priorisieren.
Unser Ziel ist nicht, jedes Produkt neu zu bauen, sondern Bestandscode so zu pflegen und weiterzuentwickeln, dass Sicherheits- und Pflegeanforderungen praktisch erfüllbar werden.
Oft starten wir mit Produktabgrenzung, technischer Bestandsaufnahme und Gap-Analyse. Daraus entsteht ein priorisierter Anforderungskatalog mit konkreten Arbeitspaketen für Produkt, Entwicklung, Build, Release und Pflege.
Danach können wir die Umsetzung begleiten, einzelne Maßnahmen selbst mit umsetzen oder dauerhaft bei Security- und Lifecycle-Aufgaben unterstützen.
