Lesezeit: 8 Minuten

Der Cyber Resilience Act ist da

Der Cyber Resilience Act (CRA) ist seit Oktober 2024 in Kraft und betrifft auch digitale Agenturen und Hoster — früher als viele denken. Ab September 2026 gilt bereits die Meldepflicht für aktiv ausgenutzte Schwachstellen. Wer die eigene Leistungspalette jetzt nicht durchleuchtet, riskiert regulatorische Überraschungen. Die entscheidende Frage dabei: Bieten wir hier eine Dienstleistung an — oder bringen wir ein Produkt in Verkehr? Denn individuelle Kundenprojekte und selbst entwickelte, wiederholt vermarktete Software wie Extensions, Starter-Packages oder SaaS-Tools unterliegen grundlegend verschiedenen Pflichten. Dieser Beitrag erklärt, was die Unterscheidung bedeutet, welche Konsequenzen sie für Verträge und Prozesse hat — und warum das TYPO3-Ökosystem dabei strukturell im Vorteil ist.

Zwei Fristen, nicht eine

Die meisten wissen, dass die vollständige Anwendung des Cyber Resilience Acts für Dezember 2027 erwartet wird. Was weniger bekannt ist: Die erste Deadline liegt bereits im September 2026. Ab dann gilt für alle, die digitale Produkte kommerziell anbieten, eine Pflicht zur Meldung aktiv ausgenutzter Schwachstellen. Das sind nicht zwei Jahre Vorlaufzeit — das sind sechs Monate bis zum ersten kritischen Meilenstein.

Dienstleistung oder Produkt? Das ist die eigentliche Frage.

Für Agenturen ist die wichtigste Unterscheidung im CRA nicht die zwischen groß und klein oder zwischen Open Source und proprietär. Es ist die zwischen dem, was wir für Kunden bauen, und dem, was wir als eigenes Angebot in den Markt bringen.

Ein individuelles Kundenprojekt — eine maßgeschneiderte Website, ein konfiguriertes TYPO3-System, eine auf einen spezifischen Kunden zugeschnittene digitale Plattform — ist eine Dienstleistung. Der Kunde ist Auftraggeber; das Ergebnis geht in seine Infrastruktur ein. Die CRA-Pflichten liegen primär beim Kunden als Betreiber, nicht bei der Agentur als Dienstleister. Das entbindet die Agentur nicht von vertraglicher Sorgfalt, aber es bedeutet: Das individuelle Kundenprojekt ist kein Produkt mit digitalen Elementen im Sinne des CRA.

Anders verhält es sich bei allem, was eine Agentur selbst entwickelt und wiederholt in den Markt bringt. Eine TYPO3-Extension, die kommerziell vertrieben wird. Ein Starter-Package oder Theme, das als wiederverwendbares Produkt angeboten wird. Ein SaaS-Tool oder Managed-Service-Angebot, bei dem Software als Teil der Leistung bereitgestellt wird. Hier ist die Agentur Hersteller im Sinne des CRA — mit allen daraus folgenden Pflichten: 

• Vulnerability Management
• Security Updates in definierten Zeiträumen
• Dokumentation
• Konformitätsnachweise
• Meldepflichten

Die praktische Frage, die jede Agentur für ihr Portfolio beantworten muss, lautet daher: 
Verkaufen wir hier eine Dienstleistung — oder bringen wir ein Produkt in Verkehr?

Was bedeutet der Cyber Resilience Act für die Vertragsgestaltung?

Diese Unterscheidung hat unmittelbare Auswirkungen auf die Art und Weise, wie Agenturen mit Kunden kontrahieren. Wer Managed Hosting oder laufende Wartung als Teil eines Servicevertrags anbietet, sollte prüfen, ob dabei Software kommerziell bereitgestellt wird — und wenn ja, welche Pflichten das auslöst. Maintenance-Verträge, SLAs für Security Updates, Dokumentationspflichten: Das alles sind keine netten Extras mehr, sondern potenziell regulatorisch geforderte Bestandteile einer Leistungsbeziehung.

Für Kunden gilt spiegelbildlich: Wer digitale Produkte betreibt — insbesondere in Behörden, Krankenhäusern oder Versorgungsunternehmen — wird zunehmend bei Ausschreibungen danach fragen müssen, ob die eingesetzte Software von einem anerkannten Steward betreut wird und ob die beauftragte Agentur CRA-konforme Prozesse nachweisen kann.

Welche Rolle spielt die TYPO3 Association bzgl. Cyber Resilience Act?

Für Agenturen im TYPO3-Ökosystem gibt es einen strukturellen Vorteil: Die TYPO3 Association hat die Steward-Rolle nicht erst erfunden, sondern sie verlangt, weil der Cyber Resilience Act sie verlangt. Sie hat jahrelang gelebt — mit Vulnerability-Disclosure-Prozessen, einer Cybersecurity-Policy und der Bereitschaft, gegenüber Behörden Verantwortung zu übernehmen. Das bedeutet: Das Fundament, auf dem Kundenprojekte und eigene Produkte aufgebaut werden, ist regulatorisch anerkannt.

Was Agenturen darauf aufbauen müssen, ist ihre eigene Schicht: klarere Produktdefinitionen im eigenen Portfolio, sauberere Vertragsstrukturen gegenüber Kunden, und dokumentierte Prozesse für den Fall, dass eine eigene Extension oder ein eigenes Tool zum Compliance-Thema wird.

Der CRA zwingt uns, erwachsen zu werden. Das ist gut so.

Die Unterscheidung zwischen Projekt und Produkt war in der Agenturwelt lange unscharf — weil es keine Konsequenzen hatte, sie zu ignorieren. Das ändert sich. Wer die eigene Leistungspalette jetzt durchleuchtet und klar benennt, was Dienstleistung und was Produkt ist, schafft nicht nur regulatorische Klarheit. Er schafft auch die Grundlage für fairere Preisgestaltung, belastbarere Verträge und glaubwürdigere Gespräche mit Kunden, die zunehmend nach genau diesen Antworten fragen werden.

Betrifft der CRA Ihr Portfolio? Wir klären das gemeinsam.