Cyber Resilience Act: Auswirkungen auf Patentsoftware
Der CRA stellt neue Anforderungen an Patentsoftware-Anbieter und -Nutzer. Was die Verordnung bedeutet und wie Sie sich vorbereiten.
Der Cyber Resilience Act trifft auch Ihre Patentsoftware: Was Sie jetzt wissen müssen
Der Cyber Resilience Act (CRA), im Oktober 2024 verabschiedet und seit Dezember 2024 in Kraft, bringt die umfassendste Cybersicherheitsregulierung für Softwareprodukte, die die EU je erlassen hat. Ab dem 11. September 2027 müssen alle Produkte mit digitalen Elementen - einschließlich Patentsoftware - die CRA-Anforderungen erfüllen und das CE-Zeichen tragen.
Für Patentkanzleien und IP-Abteilungen, die auf spezialisierte Software für Recherche, Drafting, Einreichung und Portfoliomanagement angewiesen sind, hat der CRA zwei Dimensionen: als Nutzer dieser Software müssen sie verstehen, was der CRA von ihren Anbietern verlangt, und als Verantwortliche für ihre IT-Infrastruktur müssen sie sicherstellen, dass ihre Softwarelandschaft CRA-konform ist.
Was der CRA von Software-Produkten verlantet
Der CRA definiert Cybersicherheitsanforderungen für "Produkte mit digitalen Elementen" - eine bewusst breite Kategorie, die sowohl Hardware mit Software-Komponenten als auch reine Software-Produkte umfasst. Patentsoftware, ob Cloud-basiert oder On-Premise, fällt eindeutig in den Anwendungsbereich.
Die Kernanforderungen (Annex I des CRA) umfassen:
Security by Design: Software muss so konzipiert sein, dass sie ein angemessenes Cybersicherheitsniveau gewährleistet. Das bedeutet: sichere Standardkonfigurationen, Verschlüsselung sensibler Daten, Authentifizierungsmechanismen, Schutz vor unbefugtem Zugriff.
Vulnerability Handling: Hersteller müssen Schwachstellen in ihren Produkten aktiv identifizieren und beheben. Das umfasst: ein dokumentiertes Verfahren zur Schwachstellenbehandlung, die Behebung bekannter Schwachstellen ohne unangemessene Verzögerung, und die Information der Nutzer über Sicherheitsupdates.
Software Bill of Materials (SBOM): Hersteller müssen eine maschinenlesbare Stückliste aller Softwarekomponenten bereitstellen. Das ermöglicht Nutzern, Schwachstellen in Drittkomponenten zu identifizieren und das Risiko von Supply-Chain-Angriffen zu bewerten.
Sicherheitsupdates: Hersteller müssen für den gesamten Support-Zeitraum (mindestens fünf Jahre oder die erwartete Produktlebensdauer, je nachdem was kürzer ist) kostenlose Sicherheitsupdates bereitstellen.
Pflichten für Patentsoftware-Anbieter
Für Anbieter von Patentsoftware - ob etablierte Akteure wie Clarivate, Questel und Anaqua oder spezialisierte Start-ups - bringt der CRA erhebliche neue Pflichten.
Konformitätsbewertung: Vor dem Inverkehrbringen muss der Hersteller eine Konformitätsbewertung durchführen. Für Standard-Software genügt in der Regel eine Selbstbewertung nach Annex VIII. Für Software, die in kritische Infrastruktur eingebunden ist (etwa in Patentämtern), kann eine Bewertung durch eine benannte Stelle erforderlich sein.
CE-Kennzeichnung: Nach erfolgreicher Konformitätsbewertung muss das Produkt das CE-Zeichen tragen. Das ist kein dekoratives Element - es ist die rechtsverbindliche Erklärung, dass das Produkt die CRA-Anforderungen erfüllt.
Meldepflichten: Aktiv ausgenutzte Schwachstellen müssen innerhalb von 24 Stunden an die zuständige CSIRT (Computer Security Incident Response Team) und an die ENISA gemeldet werden. Innerhalb von 72 Stunden muss ein detaillierter Bericht folgen.
Technische Dokumentation: Eine umfassende technische Dokumentation muss erstellt und gepflegt werden, die die Konformität mit allen CRA-Anforderungen nachweist. Diese Dokumentation muss den Marktüberwachungsbehörden auf Anfrage zugänglich sein.
Auswirkungen auf Nutzer: Was Kanzleien beachten müssen
Auch wenn der CRA primär Pflichten für Hersteller definiert, haben Nutzer von Patentsoftware konkrete Verantwortungen.
Sicherheitsupdates zeitnah einspielen: Der CRA verpflichtet Hersteller, Updates bereitzustellen - aber Nutzer müssen diese auch installieren. Eine Kanzlei, die bekannte Sicherheitsupdates ignoriert, handelt nicht nur fahrlässig im Sinne des CRA, sondern riskiert auch DSGVO-Verstöße, wenn die ungepatchte Software zu einem Datenschutzverstoß führt.
Produkte mit CE-Kennzeichnung bevorzugen: Ab September 2027 sollten Kanzleien bei der Softwarebeschaffung darauf achten, dass Produkte CRA-konform sind. Software ohne CE-Kennzeichnung darf ab diesem Zeitpunkt nicht mehr regulär in der EU in Verkehr gebracht werden.
SBOM auswerten: Die vom Hersteller bereitgestellte Software Bill of Materials sollte regelmäßig gegen bekannte Schwachstellen-Datenbanken (CVE) geprüft werden - idealerweise automatisiert.
Vendor Due Diligence aktualisieren: Die Anforderungen an die Überprüfung von Softwareanbietern müssen um CRA-spezifische Punkte erweitert werden: Liegt ein CE-Zertifikat vor? Wie ist der Vulnerability-Handling-Prozess organisiert? Wie lang ist der zugesicherte Support-Zeitraum?
CRA im Zusammenspiel mit NIS2 und AI Act
Der CRA existiert nicht isoliert, sondern als Teil eines regulatorischen Ökosystems, das auch die NIS2-Richtlinie und den AI Act umfasst. Für Patentsoftware-Nutzer ergeben sich daraus überlagernde Anforderungen.
NIS2: Patentkanzleien, die als Dienstleister für wesentliche oder wichtige Einrichtungen tätig sind, können indirekt in den Anwendungsbereich der NIS2-Richtlinie fallen. NIS2 verlangt unter anderem Cybersicherheits-Risikomanagement, Incident-Response-Pläne und Meldepflichten für erhebliche Sicherheitsvorfälle.
AI Act: Patentsoftware, die KI-Komponenten enthält, unterliegt zusätzlich den Anforderungen des AI Act. Die Interaktion zwischen CRA und AI Act ist in Art. 8 CRA geregelt: Für KI-Systeme, die unter den AI Act fallen, gelten die CRA-Cybersicherheitsanforderungen als erfüllt, wenn die AI-Act-Anforderungen erfüllt sind - vorausgesetzt, die AI-Act-Anforderungen decken die CRA-Anforderungen inhaltlich ab.
In der Praxis bedeutet das: Eine Patentkanzlei, die KI-gestützte Patentsoftware in der Cloud nutzt, muss sicherstellen, dass der Anbieter CRA-konform ist, die AI-Act-Anforderungen erfüllt, die DSGVO-Anforderungen als Auftragsverarbeiter einhält und ggf. NIS2-relevante Sicherheitsmaßnahmen umsetzt. Vier Rechtsregime, ein Softwareprodukt.
Compliance-Timeline: Wann was gilt
Der CRA sieht eine gestaffelte Übergangsfrist vor.
Seit dem 11. Juni 2026 gelten die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle. Hersteller müssen ihre Meldeprozesse eingerichtet haben.
Ab dem 11. September 2027 gelten alle CRA-Anforderungen vollständig. Produkte mit digitalen Elementen dürfen nur noch mit CE-Kennzeichnung in der EU in Verkehr gebracht werden.
Für Kanzleien als Nutzer bedeutet das: Bis September 2027 prüfen, ob alle eingesetzten Softwareprodukte CRA-konform sind oder sein werden. Softwareanbieter kontaktieren und deren CRA-Roadmap erfragen. Beschaffungsprozesse anpassen, um CRA-Konformität als Auswahlkriterium zu verankern.
Vorbereitung in der Praxis
Die konkreten Vorbereitungsschritte für Patentkanzleien sind überschaubar, aber sie müssen jetzt beginnen.
Erstens: Software-Inventar erstellen. Welche Softwareprodukte mit digitalen Elementen sind im Einsatz? Welche Version? Welcher Anbieter? Welcher Support-Zeitraum?
Zweitens: Anbieter-Assessment durchführen. Haben die Anbieter der eingesetzten Software eine CRA-Compliance-Strategie? Wann wird die CE-Kennzeichnung erwartet? Wie ist der Vulnerability-Handling-Prozess organisiert?
Drittens: Update-Prozesse formalisieren. Sicherstellen, dass Sicherheitsupdates innerhalb definierter Fristen eingespielt werden - nicht "wenn Zeit ist", sondern nach einem dokumentierten Prozess.
Viertens: SBOM-Management aufsetzen. Die Fähigkeit etablieren, SBOMs zu empfangen, zu speichern und gegen CVE-Datenbanken zu prüfen - entweder manuell oder idealerweise automatisiert.
Fazit
Der Cyber Resilience Act ist die letzte große Lücke, die die EU in ihrem Cybersicherheits-Regulierungsrahmen schließt. Für Patentkanzleien bedeutet er primär eine Veränderung der Anbieterbeziehung: Mehr Transparenz, mehr Sicherheit, mehr Pflichten auf beiden Seiten. Wer sich jetzt vorbereitet, wird den September 2027 als organisatorische Formalität erleben. Wer wartet, riskiert den Einsatz nicht-konformer Software - mit allen regulatorischen und haftungsrechtlichen Konsequenzen.