--- title: "Cyber Resilience Act: Was Unternehmen, die Software beauftragen, jetzt wissen müssen" description: Der EU Cyber Resilience Act gilt ab September 2026. Was Unternehmen, die Softwareprodukte entwickeln lassen, jetzt wissen und klären müssen. image: https://blog.mobilistics.de/hubfs/blog-feature-grafiken/20260806_devosphere_Cyber%20Resilience%20Act.png --- [![mobilistics](https://blog.mobilistics.de/hubfs/raw_assets/public/mobilistics-blog/images/mobilistics-logo-horizontal-positiv-rgb.svg)](https://www.mobilistics.de) - [Blog](https://blog.mobilistics.de) - [Unsere Marken](https://www.mobilistics.de/marken/) - [Über uns](https://www.mobilistics.de/ueber-uns/) [Kontakt](https://www.mobilistics.de/kontakt/) 1. [Blog](https://blog.mobilistics.de) 2. Cyber Resilience Act: Was Unternehmen, die Software beauftragen, jetzt wissen müssen [devosphere](https://blog.mobilistics.de/tag/devosphere) # Cyber Resilience Act: Was Unternehmen, die Software beauftragen, jetzt wissen müssen ![Fabian Friedrich](https://blog.mobilistics.de/hs-fs/hubfs/blog-autorenprofile/Fabian%20Friedrich%20Headshot.png?width=36&height=36&name=Fabian%20Friedrich%20Headshot.png) Fabian Friedrich · 06.08.2026 · 7 Min. Lesezeit Der EU Cyber Resilience Act (CRA) ist eine EU-Verordnung, die Hersteller, Importeure und Distributoren von Produkten mit digitalen Elementen zu verbindlichen Cybersicherheitsanforderungen über den gesamten Produktlebenszyklus verpflichtet. --- **Auf einen Blick** - Gilt für: Produkte mit digitalen Elementen, die auf dem EU-Markt bereitgestellt werden - Erste Pflichten ab: 11. September 2026 (Meldepflicht) - Vollständige Compliance ab: 11. Dezember 2027 - Zuständige Behörde in Deutschland: BSI - Höchststrafe: bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes --- Vernetzte Geräte, Software und cloudbasierte Dienste sind heute integraler Bestandteil nahezu jedes Geschäftsmodells. Gleichzeitig nehmen Cyberangriffe auf diese Produkte deutlich zu und verursachen erhebliche wirtschaftliche Schäden. Mit dem Cyber Resilience Act reagiert die EU auf diese Entwicklung und legt erstmals verbindliche Cybersicherheitsanforderungen für alle Produkte mit digitalen Elementen fest. Für viele Mittelstandsunternehmen stellt sich dabei zuerst eine Grundfrage: Bin ich überhaupt betroffen? Die Antwort hängt nicht allein davon ab, wer Software schreibt, sondern davon, wer sie auf den Markt bringt. --- ### Für wen gilt der Cyber Resilience Act? Wer Software nicht selbst entwickelt, sondern entwickeln lässt, sollte zunächst klären, ob das Ergebnis unter den CRA fällt und in welcher Rolle das eigene Unternehmen dabei steht. Der Cyber Resilience Act betrifft nahezu alle Unternehmen, die digitale Produkte im EU-Markt anbieten. Dazu zählen vernetzte Hardware, Softwarekomponenten innerhalb vernetzter Hardware sowie reine Softwareprodukte. Hersteller, Importeure und Distributoren werden verpflichtet, während des gesamten Produktlebenszyklus Sicherheitsmaßnahmen umzusetzen und ihre vollständige Konformität bis Dezember 2027 nachzuweisen. Bei Hardwareprodukten ist die CRA-Konformität zudem Voraussetzung für die CE-Kennzeichnung. Ausgenommen sind Produkte, die bereits durch sektorspezifische Regulierungen abgedeckt werden, zum Beispiel Medizintechnik, bestimmte Fahrzeugtypen sowie Produkte im Bereich der nationalen Sicherheit oder nichtkommerzielle Open-Source-Software. Unternehmen in regulierten Branchen sollten ihr Portfolio dennoch sorgfältig analysieren, da alle Produkte, die nicht eindeutig durch andere Regime abgedeckt sind, unter den horizontalen CRA-Anwendungsbereich fallen. Der CRA unterscheidet zwischen drei Produktkategorien: Standard-Produkte mit digitalen Elementen, wichtige Produkte in zwei Klassen sowie kritische Produkte. Die Einstufung bestimmt, welche Anforderungen konkret gelten und ob eine externe Zertifizierung erforderlich ist. --- ### Was der CRA konkret fordert Für betroffene Produkte definiert der CRA sechs Anforderungsbereiche über den gesamten Produktlebenszyklus: - **Security-by-Design:** Sicherheit muss bereits in der Entwicklung mitgedacht und umgesetzt werden. - **Vulnerability- und Incident-Management:** Schwachstellen müssen systematisch identifiziert, bewertet und behoben werden. Zusätzlich müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle an CSIRT und ENISA gemeldet werden. - **Produktsupport:** Sicherheitsupdates müssen über den Supportzeitraum kostenfrei bereitgestellt werden. - **SBOM:** Eine Software Bill of Materials muss in einem maschinenlesbaren Format wie CycloneDX dokumentiert und gepflegt werden. - **Dokumentation:** Alle umgesetzten Anforderungen müssen gründlich dokumentiert sein. - **Zertifizierung:** Produkte müssen entsprechend ihrer Kritikalität die CRA-Konformität nachweisen, entweder durch den Hersteller selbst oder durch externe Prüfstellen. --- ### Was der Cyber Resilience Act für Unternehmen bedeutet, die Software beauftragen Für Unternehmen, die Individualsoftware entwickeln lassen, entscheidet sich ein Teil des Umsetzungsaufwands bereits bei der Wahl des Entwicklungspartners. Der CRA definiert Anforderungen, die nicht nachträglich ergänzt werden können, sondern in der Entwicklung selbst verankert sein müssen. **Security-by-Design lässt sich nicht nachträglich einbauen** Der CRA verlangt, dass Sicherheit bereits in der Entwicklung mitgedacht und umgesetzt wird. Eine nachträgliche Einbindung führt erfahrungsgemäß zu höherem Nacharbeits- und Kostenaufwand und erhöht das Risiko, zum Stichtag nicht konform zu sein. **SBOM: Vollständige Dokumentation aller Softwarekomponenten** Der CRA verpflichtet dazu, eine Software Bill of Materials in einem maschinenlesbaren Format wie CycloneDX zu führen und zu pflegen. Sie dokumentiert vollständig, welche Softwarekomponenten im Produkt enthalten sind, einschließlich Open-Source-Bibliotheken und zugekaufter Komponenten. Wer ein Softwareprodukt in Auftrag gibt, sollte wissen, ob und wie dieser Nachweis im Projektergebnis enthalten ist. **Vulnerability Management und Sicherheitsupdates als Dauerpflicht** Hersteller sind verpflichtet, Schwachstellen systematisch zu identifizieren, zu bewerten und zu beheben. Aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle müssen zusätzlich an CSIRT und ENISA gemeldet werden. Sicherheitsupdates müssen über den Supportzeitraum kostenfrei bereitgestellt werden. Das bedeutet, dass Softwaresicherheit nicht mit der Projektabnahme endet, sondern eine laufende Aufgabe bleibt. **Die Wahl des Entwicklungspartners ist Teil der CRA-Umsetzung** Wer früh mit einem Partner entwickelt, der diese Anforderungen kennt und von Beginn an in die Entwicklung einbringt, reduziert den Aufwand in den späteren Schritten erheblich. Wer Security-by-Design als Prinzip konsequent in Prozesse und Produkte integriert, verkürzt die Time-to-Market, senkt Lifecycle-Kosten und schafft die Basis für neue digitale Services. [devosphere](https://www.devosphere.de) entwickelt Individualsoftware für den Mittelstand, ausgehend vom Geschäftsprozess, mit dem Anspruch, dass Software langfristig betreibbar bleibt. --- ### Die Fristen Ab dem 11. September 2026 greifen Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gegenüber CSIRT und ENISA. Ab dem 11. Dezember 2027 gelten die vollständigen Pflichten einschließlich der CE-Konformität für alle betroffenen Produkte. Viele Produkte, die im Dezember 2027 auf dem Markt sein sollen, befinden sich bereits heute in der Entwicklung. Wer die CRA-Anforderungen jetzt in laufende und geplante Projekte einbezieht, vermeidet teure Nachbesserungen und beschleunigt die spätere Zertifizierung. Bei Verstößen drohen Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes. Hinzu kommt das Risiko von Reputations- und Haftungsschäden durch Sicherheitsvorfälle rund um vernetzte Produkte. --- *Quelle: Deloitte, "Cyber Resilience Act (CRA): Anforderungen, Fristen und Umsetzung für Unternehmen", Juni 2026* ### Software, die Ende 2027 CRA-konform sein muss, entsteht jetzt. [Mehr erfahren](https://www.devosphere.de)   ## Häufige Fragen zum Cyber Resilience Act ### Gilt der CRA, wenn ich Software beauftrage, die ich nicht selbst verkaufe? Das hängt davon ab, was mit der Software passiert. Rein intern genutzte Software, die nicht auf dem Markt bereitgestellt wird, fällt grundsätzlich nicht unter den CRA. Sobald das Softwareprodukt oder ein Produkt, das diese Software enthält, an Kunden oder Dritte weitergegeben wird, ist zu prüfen, ob und in welcher Rolle das eigene Unternehmen unter den CRA fällt. Der CRA verpflichtet Hersteller, Importeure und Distributoren. Welche Rolle ein Unternehmen konkret einnimmt, sollte rechtlich geprüft werden. ### Ab wann gilt was, und was muss wann operativ sein? Der CRA tritt in zwei Stufen in Kraft. Ab dem 11. September 2026 müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle an CSIRT und ENISA gemeldet werden. Prozesse und Verantwortlichkeiten für das Meldewesen müssen deshalb bereits vor diesem Datum operativ sein. Die vollständigen Anforderungen, einschließlich Security-by-Design, SBOM, Dokumentationspflichten und Zertifizierung, gelten ab dem 11. Dezember 2027. Da viele Produkte, die zu diesem Zeitpunkt auf dem Markt sein sollen, bereits heute in Entwicklung sind, empfiehlt es sich, die CRA-Anforderungen in laufende und geplante Projekte unmittelbar einzubeziehen. ### Was ist eine SBOM, und warum ist sie relevant? Eine Software Bill of Materials ist ein vollständiges, strukturiertes Verzeichnis aller Softwarekomponenten, die in einem Produkt enthalten sind, einschließlich Open-Source-Bibliotheken und zugekaufter Komponenten. Der CRA verlangt, dass diese SBOM in einem maschinenlesbaren Format wie CycloneDX dokumentiert und gepflegt wird. Sie ist die Grundlage dafür, dass Schwachstellen in verwendeten Komponenten erkannt und bewertet werden können, was der CRA als laufende Pflicht vorschreibt. ### Muss jedes Softwareprodukt extern zertifiziert werden? Nicht jedes. Standardprodukte können die Konformität durch Selbstbewertung des Herstellers nachweisen. Wichtige Produkte der Klassen I und II sowie kritische Produkte unterliegen je nach Einstufung unterschiedlichen Anforderungen, einschließlich möglicher externer Konformitätsbewertungen. Welcher Kategorie ein Produkt zuzuordnen ist, hängt von Art und Verwendungszweck ab und sollte frühzeitig geklärt werden, da die Einstufung alle weiteren Planungen beeinflusst. ### Welche Strafen drohen bei Verstößen? Der CRA sieht Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes vor, je nachdem welcher Betrag höher ist. Hinzu kommt das Risiko von Reputations- und Haftungsschäden durch Sicherheitsvorfälle rund um vernetzte Produkte. Teilen LinkedIn X Link kopieren Tags: [devosphere](https://blog.mobilistics.de/tag/devosphere) ![Fabian Friedrich](https://blog.mobilistics.de/hs-fs/hubfs/blog-autorenprofile/Fabian%20Friedrich%20Headshot.png?width=72&height=72&name=Fabian%20Friedrich%20Headshot.png) Fabian Friedrich [LinkedIn](https://www.linkedin.com/in/friedrich-f/) [f.friedrich@mobilistics.de](mailto:f.friedrich@mobilistics.de) Weitere Beiträge ## Mehr zu devosphere [devosphere](https://blog.mobilistics.de/tag/devosphere) ### [Secrets in KI-gestütztem Code: Entscheidend ist, wie lange sie gültig bleiben](https://blog.mobilistics.de/secrets-ki-code-microservices) KI-gestützter Code hat 2025 im Jahresmittel ungefähr doppelt so oft Secrets geleakt wie der Durchschnitt aller öffentlichen GitHub-Commits, so steht es im Repor… ![Fabian Friedrich](https://blog.mobilistics.de/hs-fs/hubfs/blog-autorenprofile/Fabian%20Friedrich%20Headshot.png?width=28&height=28&name=Fabian%20Friedrich%20Headshot.png) Fabian Friedrich · 06.10.2026 [devosphere](https://blog.mobilistics.de/tag/devosphere) ### [Agentic Development: Was ein Agent im Repository darf](https://blog.mobilistics.de/agentic-development) Agentic Development heißt, dass ein Agent mehrschrittig und selbstständig im Repository arbeitet: Er ruft Werkzeuge auf, führt Code aus, prüft das Ergebnis und … ![Fabian Friedrich](https://blog.mobilistics.de/hs-fs/hubfs/blog-autorenprofile/Fabian%20Friedrich%20Headshot.png?width=28&height=28&name=Fabian%20Friedrich%20Headshot.png) Fabian Friedrich · 16.09.2026 [devosphere](https://blog.mobilistics.de/tag/devosphere) ### [Spec-Driven Development: Was die Methode leistet, wenn KI den Code schreibt](https://blog.mobilistics.de/spec-driven-development) Spec-Driven Development beschreibt eine Arbeitsweise, in der die Spezifikation das führende Artefakt eines Projekts ist. Sie ist die verbindliche Quelle, aus de… ![Fabian Friedrich](https://blog.mobilistics.de/hs-fs/hubfs/blog-autorenprofile/Fabian%20Friedrich%20Headshot.png?width=28&height=28&name=Fabian%20Friedrich%20Headshot.png) Fabian Friedrich · 03.09.2026 Über uns mobilistics ist Technologiepartner für den deutschen Mittelstand – von Managed Cloud über KI-Lösungen bis hin zu individueller Softwareentwicklung. Wir übernehmen Verantwortung für Systeme, die im Alltag funktionieren müssen – nicht nur im Konzept. mobilistics - [Über uns](https://www.mobilistics.de/ueber-uns/) - [Unsere Marken](https://www.mobilistics.de/unsere-marken/) - [Unser Beitrag](https://www.mobilistics.de/unser-beitrag/) - [Karriere](https://www.mobilistics.de/karriere/) Marken - [cloudriven](https://www.cloudriven.de/) - [devosphere](https://www.devosphere.de/) - [vectorpulse](https://www.vectorpulse.de/) - [vpagent](https://www.vpagent.de/) - [vpchat](https://www.vpchat.de/) - [workfleet](https://www.workfleet.de/) Rechtliches - [Impressum](https://www.mobilistics.de/impressum/) - [Datenschutz](https://www.mobilistics.de/datenschutz/) - [AGB](https://www.mobilistics.de/agb/) [![mobilistics](https://blog.mobilistics.de/hubfs/raw_assets/public/mobilistics-blog/images/mobilistics-logo-horizontal-negativ-rgb.svg)](https://www.mobilistics.de) © 2026 mobilistics. Alle Rechte vorbehalten. ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Fabian Friedrich", "url" : "https://blog.mobilistics.de/author/fabian-friedrich" }, "dateModified" : "2026-08-31T08:38:55.171Z", "datePublished" : "2026-08-06T12:25:26.000Z", "headline" : "Cyber Resilience Act: Was Unternehmen, die Software beauftragen, jetzt wissen müssen", "image" : [ "https://blog.mobilistics.de/hubfs/blog-feature-grafiken/20260806_devosphere_Cyber%20Resilience%20Act.png" ], "mainEntityOfPage" : { "@id" : "https://blog.mobilistics.de/eu-cyber-resilience-act", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://blog.mobilistics.de/hubfs/mobilistics-logo-horizontal-positiv-rgb.svg" } } } ``` ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Fabian Friedrich" }, "dateModified" : "2026-08-31T08:38:55+00:00", "datePublished" : "2026-08-06T12:25:26+00:00", "description" : "Der EU Cyber Resilience Act gilt ab September 2026. Was Unternehmen, die Softwareprodukte entwickeln lassen, jetzt wissen und klären müssen.", "headline" : "<span id="hs_cos_wrapper_name" class="hs_cos_wrapper hs_cos_wrapper_meta_field hs_cos_wrapper_type_text" style="" data-hs-cos-general-type="meta_field" data-hs-cos-type="text" >Cyber Resilience Act: Was Unternehmen, die Software beauftragen, jetzt wissen müssen</span>", "image" : { "@type" : "ImageObject", "height" : 630, "url" : "https://147879499.fs1.hubspotusercontent-eu1.net/hubfs/147879499/blog-feature-grafiken/20260806_devosphere_Cyber%20Resilience%20Act.png", "width" : 1200 }, "inLanguage" : "de-DE", "mainEntityOfPage" : { "@id" : "", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "//147879499.fs1.hubspotusercontent-eu1.net/hubfs/147879499/raw_assets/public/mobilistics-blog/images/mobilistics-logo-horizontal-positiv-rgb.svg" }, "name" : "mobilistics GmbH", "url" : "https://www.mobilistics.de" } } ``` ```json { "@context" : "https://schema.org", "@type" : "BreadcrumbList", "itemListElement" : [ { "@type" : "ListItem", "item" : "https://blog.mobilistics.de/tag/devosphere", "name" : "devosphere Blog", "position" : 1 }, { "@type" : "ListItem", "name" : "<span id="hs_cos_wrapper_name" class="hs_cos_wrapper hs_cos_wrapper_meta_field hs_cos_wrapper_type_text" style="" data-hs-cos-general-type="meta_field" data-hs-cos-type="text" >Cyber Resilience Act: Was Unternehmen, die Software beauftragen, jetzt wissen müssen</span>", "position" : 2 } ] } ``` ```json { "@context" : "https://schema.org", "@type" : "FAQPage", "mainEntity" : [ { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "Das hängt davon ab, was mit der Software passiert. Rein intern genutzte Software, die nicht auf dem Markt bereitgestellt wird, fällt grundsätzlich nicht unter den CRA. Sobald das Softwareprodukt oder ein Produkt, das diese Software enthält, an Kunden oder Dritte weitergegeben wird, ist zu prüfen, ob und in welcher Rolle das eigene Unternehmen unter den CRA fällt. Der CRA verpflichtet Hersteller, Importeure und Distributoren. Welche Rolle ein Unternehmen konkret einnimmt, sollte rechtlich geprüft werden." }, "name" : "Gilt der CRA, wenn ich Software beauftrage, die ich nicht selbst verkaufe?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "Der CRA tritt in zwei Stufen in Kraft. Ab dem 11. September 2026 müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle an CSIRT und ENISA gemeldet werden. Prozesse und Verantwortlichkeiten für das Meldewesen müssen deshalb bereits vor diesem Datum operativ sein. Die vollständigen Anforderungen, einschließlich Security-by-Design, SBOM, Dokumentationspflichten und Zertifizierung, gelten ab dem 11. Dezember 2027. Da viele Produkte, die zu diesem Zeitpunkt auf dem Markt sein sollen, bereits heute in Entwicklung sind, empfiehlt es sich, die CRA-Anforderungen in laufende und geplante Projekte unmittelbar einzubeziehen." }, "name" : "Ab wann gilt was, und was muss wann operativ sein?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "Eine Software Bill of Materials ist ein vollständiges, strukturiertes Verzeichnis aller Softwarekomponenten, die in einem Produkt enthalten sind, einschließlich Open-Source-Bibliotheken und zugekaufter Komponenten. Der CRA verlangt, dass diese SBOM in einem maschinenlesbaren Format wie CycloneDX dokumentiert und gepflegt wird. Sie ist die Grundlage dafür, dass Schwachstellen in verwendeten Komponenten erkannt und bewertet werden können, was der CRA als laufende Pflicht vorschreibt." }, "name" : "Was ist eine SBOM, und warum ist sie relevant?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "Nicht jedes. Standardprodukte können die Konformität durch Selbstbewertung des Herstellers nachweisen. Wichtige Produkte der Klassen I und II sowie kritische Produkte unterliegen je nach Einstufung unterschiedlichen Anforderungen, einschließlich möglicher externer Konformitätsbewertungen. Welcher Kategorie ein Produkt zuzuordnen ist, hängt von Art und Verwendungszweck ab und sollte frühzeitig geklärt werden, da die Einstufung alle weiteren Planungen beeinflusst." }, "name" : "Muss jedes Softwareprodukt extern zertifiziert werden?" }, { "@type" : "Question", "acceptedAnswer" : { "@type" : "Answer", "text" : "Der CRA sieht Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes vor, je nachdem welcher Betrag höher ist. Hinzu kommt das Risiko von Reputations- und Haftungsschäden durch Sicherheitsvorfälle rund um vernetzte Produkte." }, "name" : "Welche Strafen drohen bei Verstößen?" } ] } ```