29.06.2026
Eine ehrliche Antwort auf die Kostenfrage beginnt mit einer Klarstellung: CRA-Compliance ist keine Aufgabe für eine Person, sondern verteilt sich quer durchs Unternehmen — über Engineering, Security, Produkt/Compliance und Recht, bei höheren Risikoklassen zusätzlich über Qualitätsmanagement und eine notifizierte Stelle. Genau diese Verteilung macht es für KMU teuer und mühsam. Wir schlüsseln den Aufwand pro Aufgabe und Rolle auf, nennen ein nachvollziehbares Referenzszenario, trennen Einmal- von laufendem Aufwand — und kennzeichnen transparent, welche Zahlen aus Studien stammen und welche aus eigener Projekterfahrung.
CRACompliance-KostenAufwandKMUSBOMKonformitätsbewertungRollenMethodikPersonentagecrAIready
19.06.2026
Ein Gerät mit eingebetteter Software fällt häufig unter mehrere CE-Rechtsakte zugleich — den CRA und etwa die Maschinenverordnung oder die Funkanlagenrichtlinie. Bekommt es dann ein eigenes 'CRA-CE' zusätzlich zum bestehenden CE? Nein. Der CRA führt keine eigene Kennzeichnung ein: Es bleibt bei einem einzigen CE-Zeichen, einer Konformitätserklärung und einer technischen Dokumentation. Wir zeigen, wie die CRA-Anforderungen in das bestehende Verfahren einfliessen — und wo das Verhältnis zur Funkanlagenrichtlinie noch unscharf ist.
CRACE-Kennzeichnungeingebettete SoftwareEmbeddedMaschinenverordnungFunkanlagenrichtlinieArt. 30 CRAKonformitätsbewertungSingle CECompliance
05.06.2026
'Unsere Verantwortung endet bei der Installation' — diese verbreitete Annahme hält dem CRA nicht stand. Wer ein Software-Bundle unter eigenem Namen in Verkehr bringt, haftet für das Gesamtprodukt einschliesslich aller integrierten Komponenten. Wir zeigen, wo die Verantwortungsgrenzen wirklich verlaufen: bei der Sorgfaltspflicht für Dritt- und Open-Source-Komponenten (Art. 13 Abs. 5/6), beim Open-Source-Steward (Art. 24) — und wie die neue Produkthaftungsrichtlinie dieselbe Linie zieht.
CRASoftware-BundleKomponentenOpen SourceArt. 13 CRASorgfaltspflichtOpen-Source-StewardArt. 24 CRAProdukthaftungCompliance
22.05.2026
Mit der CRA-Konformitätsbewertung ist es nicht getan: Software lebt von Updates, und jedes Update kann ein Produkt erneut konformitätspflichtig machen — sobald es eine 'wesentliche Änderung' im Sinne von Art. 3 Nr. 30 CRA ist. Wer mehrmals täglich ausliefert, fragt sich zu Recht, ob jedes Release eine neue Bewertung auslöst. Wir zeigen anhand der Primärquelle und der EU-Guidance, wann ein Funktions- oder Sicherheitsupdate die Schwelle überschreitet, wann nicht, was für Rolling Release und Bestandsprodukte gilt — und welche Folgen die Einstufung hat.
CRAWesentliche ÄnderungSubstantial ModificationSoftware-UpdateRolling ReleaseContinuous DeploymentKonformitätsbewertungBestandsprodukteCompliance
08.05.2026
Am 12. März 2026 hat das Bundesministerium des Innern den Referentenentwurf zum deutschen Cyberresilienz-Durchführungsgesetz vorgelegt; der Regierungsentwurf wurde am 1. Mai 2026 vom Kabinett verabschiedet, das Gesetz ist noch nicht verkündet. Das BSI wird zur zentralen Marktüberwachungs- und notifizierenden Behörde, bekommt zusätzliche Planstellen und einen gestaffelten Vollzugsauftrag bis Ende 2027. Bitkom, TeleTrusT und OSBA haben in ihren Verbändestellungnahmen erhebliche Kritik geübt: zu wenig Mittel für KMU-Unterstützung, problematische Notifizierungs-Konstruktionen und der Wegfall aufschiebender Wirkung. Wir analysieren den Entwurf, ordnen die Kritik ein und zeigen, was Hersteller jetzt einplanen sollten.
CRABSICyberresilienz-DurchführungsgesetzBMIMarktüberwachungNotifizierende BehördeBSIGTeleTrusTBitkomOSBACompliance
01.05.2026
Art. 32 CRA verweist auf vier Konformitätsbewertungsmodule aus Anhang VIII: A, B, C und H. Während Modul A für die meisten Softwareprodukte ausreicht, müssen wichtige Produkte der Klasse II und kritische Produkte aus Anhang IV den Weg über eine notifizierte Stelle gehen. Erfahren Sie, welches Modul zu Ihrem Produkt passt — und wie die BSI TR-03183-H ein ISO-27001-konformes ISMS mit CRA-Modul H verbindet.
CRAKonformitätsbewertungModul AModul HBSI TR-03183-HNotifizierte StellenCE-KennzeichnungEU-Konformitätserklärung
24.04.2026
Am 11. September 2026 treten die ersten CRA-Meldepflichten in Kraft. Softwarehersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb von 24 Stunden über die einheitliche Meldeplattform nach Art. 16 CRA mitteilen — über zwei parallele dreistufige Regimes. Erfahren Sie, welche Fristen gelten, wie die Plattform funktioniert und warum die Auslegung des Begriffs 'Kenntnis' entscheidend ist.
CRAVulnerability DisclosureIncident ReportingENISAMeldepflichtenSchwachstellenmanagementComplianceSoftwaresicherheit
20.04.2026
Die Software Bill of Materials (SBOM) ist nicht optional – sie ist eine Kernpflicht des Cyber Resilience Act. Wir zeigen, was der CRA konkret verlangt, welche Formate akzeptiert sind, und wie Sie SBOM-Generierung praktisch in Ihre CI/CD-Pipeline integrieren.
CRASBOMCyber Resilience ActSoftware Bill of MaterialsComplianceSupply Chain SecuritySPDXCycloneDX
17.04.2026
Art. 12 CRA verspricht eine elegante Abkürzung: CRA-Compliance deckt die Cybersicherheitsanforderungen des AI Act ab. Doch die drei Bedingungen der Konformitätsvermutung sind anspruchsvoller, als sie klingen — die Vermutung gilt nicht für Genauigkeit und Robustheit, Erwägungsgrund (51) verlangt die Berücksichtigung KI-spezifischer Angriffsvektoren und Grundrechte-Risiken, und harmonisierte Normen fehlen noch. Wir analysieren die praktischen Hürden, die KI-spezifischen Angriffsvektoren und das kombinierte Konformitätsbewertungsverfahren nach Art. 43 KI-VO direkt am Verordnungstext.
CRAAI ActHochrisiko-KIArt. 12 CRAErwägungsgrund 51Data PoisoningAdversarial AttacksSBOMRisikobewertungMITRE ATLASComplianceArt. 43 KI-VOGrundrechte
13.04.2026
Wer ein KI-Produkt auf dem EU-Markt anbietet, steht vor zwei Verordnungen gleichzeitig, deren Pflichten gestaffelt bis Ende 2027 wirksam werden: dem CRA für Cybersicherheit und dem AI Act für KI-Risiken. Doch der Gesetzgeber hat eine Brücke gebaut — Art. 12 CRA in Verbindung mit Erwägungsgrund 77 AI Act ermöglicht eine einseitige Konformitätsvermutung für die Cybersicherheitsanforderungen des Art. 15 AI Act, die Doppelarbeit vermeidet. Wir erklären die drei tatsächlichen Rechtsvoraussetzungen aus dem Verordnungstext, die kritische Einschränkung bei Genauigkeit und Robustheit, den Verfahrenswechsel zur KI-VO bei Hochrisiko-KI sowie das kombinierte Verfahren bei wichtigen und kritischen Produkten — und warum die Vorbereitung auf beide Verordnungen parallel laufen muss.
CRAAI ActKIHochrisiko-KIArt. 12 CRAErwägungsgrund 77 AI ActKonformitätsvermutungCybersicherheitComplianceDuale Regulierung
05.04.2026
Electron-Apps, Feature-gated SaaS, Browser-Extensions, SDKs mit Cloud-Backend: Zwischen dem klaren 'CRA-pflichtig' und dem klaren 'nur NIS-2' liegt eine Grauzone, in der sich zahlreiche DACH-Softwarehersteller bewegen. Wir analysieren fünf der schwierigsten Abgrenzungsfälle gegen die Primärquelle der EU-Kommission — und zeigen, warum die Antwort oft nicht 'keine Pflicht' lautet, sondern 'abgestufte Pflicht nach Art. 13 CRA'.
CRARDPSGrauzoneSaaSElectronSDKBrowser-ExtensionWhite-LabelComplianceArt. 13 CRA
03.04.2026
Ihr Produkt ist nach dem Zwei-Fragen-Test keine RDPS? Das heisst nicht, dass der CRA Sie nicht betrifft. Art. 13 CRA definiert drei abgestufte Pflichtniveaus — von voller RDPS-Compliance über Due-Diligence-Pflichten für Drittanbieter-Komponenten bis zur Risikobewertung für nicht-funktionale Datenverbindungen. Wir zeigen anhand konkreter Szenarien, was jede Stufe in der Praxis bedeutet, welche Verträge Sie brauchen und wie Sie die operative Umsetzung organisieren.
CRAArt. 13 CRADue DiligenceDrittanbieterLieferketteRisikobewertungComplianceSupply Chain SecuritySaaS-IntegrationKomponentenpflicht
01.04.2026
Ab wann ist Server-Kommunikation CRA-pflichtig? Die EU-Kommission hat in ihrer Draft Communication erstmals einen strukturierten Test veröffentlicht, der die Abgrenzung zwischen CRA-pflichtiger Datenfernverarbeitung (RDPS) und reinen Cloud-Diensten operationalisiert. Wir zerlegen den kumulativen Zwei-Fragen-Test anhand der Primärquelle — einschliesslich der drei abgestuften Ergebnisse, die weit über ein simples Ja/Nein hinausgehen.
CRARDPSComplianceSaaSDraft CommunicationDatenfernverarbeitungEU-KommissionDrei-Elemente-Test
28.03.2026
Ab Dezember 2027 gelten die CRA-Anforderungen für alle Produkte mit digitalen Elementen auf dem EU-Markt. Viele SaaS-Anbieter wiegen sich in Sicherheit — aber sobald eine Desktop-App, ein Agent oder ein Browser-Plugin existiert, wird das Cloud-Backend zur Datenfernverarbeitungslösung. Wir erklären die Abgrenzung, zeigen warum deutlich mehr Softwarehersteller betroffen sind als erwartet, und nennen drei Sofortmassnahmen.
CRASaaSCloudRDPSNIS-2ComplianceDACHSoftwarehersteller
21.03.2026
Was regelt der Cyber Resilience Act eigentlich genau? Welche Produkte fallen klar in den Anwendungsbereich — und warum gilt er trotzdem nicht für jede Software? Wir gehen den Verordnungstext systematisch durch: vom Zweck der CRA in Art. 1, über den Anwendungsbereich in Art. 2, bis zur Schlüsselrolle des Inverkehrbringens als regulatorischer Anknüpfungspunkt. Der Auftakt unserer Serie für Softwarehersteller, die wissen müssen, ob ihr Produkt betroffen ist.
CRACyber Resilience ActAnwendungsbereichInverkehrbringenProduktrechtSaaSNIS-2SoftwareherstellerCompliance