CRA-Supportzeitraum-Planung: 5 Jahre Sicherheitsupdates (Und was das wirklich bedeutet)

Fünf Jahre. Das ist das Minimum, das Sie unter dem CRA Sicherheitsupdates für Ihre Produkte bereitstellen müssen. Für viele Hersteller bedeutet dies eine fundamentale Veränderung in der Art, wie sie über Produktlebenszyklus und Supportkosten denken.

Dieser Leitfaden behandelt, was die Supportzeitraum-Anforderung tatsächlich bedeutet, wie man dafür plant und wie man den unvermeidlichen End-of-Support-Übergang handhabt.

Was der CRA tatsächlich verlangt

Artikel 13 und Anhang I legen die Supportzeitraum-Verpflichtungen fest:

Mindestdauer

5 Jahre ab dem Zeitpunkt, an dem das Produkt auf dem EU-Markt bereitgestellt wird, ODER die erwartete Produktlebensdauer, je nachdem was kürzer ist.

"Erwartete Produktlebensdauer" wird bestimmt durch:

• Vernünftige Kundenerwartungen basierend auf Produktart
• Wie ähnliche Produkte typischerweise genutzt werden
• Was Sie über das Produkt kommunizieren

Für die meisten Software- und IoT-Produkte sind 5 Jahre das praktische Minimum.

Was Sie bereitstellen müssen

Während des Supportzeitraums müssen Sie:

1. Schwachstellen unverzüglich beheben

   • Sicherheitspatches für bekannte Schwachstellen bereitstellen
   • Nach Schweregrad priorisieren
   • Kein Warten auf "nächstes Major-Release"

2. Updates sicher bereitstellen

   • Automatische Updates, wo technisch möglich
   • Sichere Verteilung (signiert, verifiziert)
   • Rollback-Fähigkeit bei fehlgeschlagenen Updates

3. Kunden benachrichtigen

   • Über verfügbare Sicherheitsupdates informieren
   • Klare Installationsanweisungen bereitstellen
   • Sicherheitsrelevante Informationen kommunizieren

4. Updates kostenlos bereitstellen

   • Kein Bezahlen für Sicherheitsupdates
   • Feature-Updates können separat berechnet werden

Wann beginnt die Uhr?

Der Supportzeitraum beginnt, wenn das Produkt "auf dem Markt bereitgestellt" wird, also wenn Sie es erstmals in der EU verfügbar machen.

Nicht wenn:

• Der Kunde es kauft
• Der Kunde es aktiviert
• Eine bestimmte Einheit versandt wird

Dies schafft Lagerrisiko: Wenn Ihr Produkt 18 Monate im Vertrieb liegt, bevor es verkauft wird, endet der Support trotzdem 5 Jahre nach der erstmaligen Marktbereitstellung.

Beispiel-Zeitplan

Jan 2028: Produkt v1.0 auf EU-Markt bereitgestellt
          → Supportzeitraum beginnt
          → Updates bis Jan 2033 bereitstellen

Jun 2029: Kunde kauft v1.0 vom Händler
          → Kunde hat 3,5 Jahre Support verbleibend

Jan 2033: Supportzeitraum endet
          → Keine weitere Verpflichtung, v1.0 zu patchen
          → Kunde hat 18 Monate nicht unterstütztes Produkt

Best Practice: Marktbereitstellungsdaten pro Produktversion verfolgen, nicht pro Einheit.

Update-Bereitstellungsanforderungen

Automatische Updates (Bevorzugt)

Wo technisch machbar und angemessen, erwartet der CRA automatische Sicherheitsupdates:

ANFORDERUNGEN FÜR AUTOMATISCHE UPDATES:

Technisch:
- Sicherer Download-Kanal (TLS, signierte Pakete)
- Integritätsprüfung vor Installation
- Rollback-Fähigkeit bei Update-Fehler
- Angemessene Behandlung von Verbindungsproblemen

Nutzerkontrolle:
- Nutzer muss deaktivieren können (mit klarer Warnung)
- Nutzer muss aufschieben können (mit vernünftigen Grenzen)
- Kritische Updates können Aufschub für Sicherheit überschreiben
- Update-Status muss für Nutzer sichtbar sein

Benachrichtigung:
- Nutzer informieren, wenn Updates verfügbar sind
- Erklären, was das Update adressiert
- Installationsanweisungen bereitstellen, wenn manuell

Manuelle Updates (Wenn automatisch nicht möglich)

Einige Produkte können nicht automatisch aktualisieren: Air-Gapped-Systeme, Industrieausrüstung, eingebettete Geräte ohne Konnektivität.

Für diese:

• Herunterladbare Update-Pakete bereitstellen
• Klare Versionierung und Changelog
• Installationsdokumentation
• Verifizierungsmethode (Prüfsummen, Signaturen)
• Benachrichtigung über verfügbare Kanäle (E-Mail, Web-Portal, physische Mitteilung)

Update-Signierung

Alle Sicherheitsupdates sollten kryptografisch signiert sein:

UPDATE-SIGNIERUNGSANFORDERUNGEN:

Code-Signierung:
- Alle Update-Pakete signieren
- Dedizierten Signaturschlüssel verwenden (HSM-geschützt)
- Signaturverifizierung in Update-Prozess einbeziehen
- Öffentlichen Schlüssel zur Verifizierung veröffentlichen

Metadaten:
- Versionsnummer
- Veröffentlichungsdatum
- Changelog-/Advisory-Referenz
- Minimale kompatible Basisversion
- Signatur-Zeitstempel

Schwachstellenreaktion während des Supportzeitraums

Der Supportzeitraum geht nicht nur darum, Updates verfügbar zu haben. Es geht darum, auf Schwachstellen zu reagieren, wenn sie entdeckt werden.

Reaktionserwartungen

Diese sind keine CRA-vorgeschriebenen Zeitrahmen, aber sie spiegeln Branchenerwartungen wider und was Regulatoren als "unverzüglich" betrachten werden.

Schwachstellen verfolgen

Sie brauchen einen Prozess für:

1. Entdeckungs-Intake

   • CVD-Richtlinie und Kontaktstelle
   • Interne Entdeckungs-Pipeline
   • Dependency-Überwachung

2. Bewertung

   • Betrifft Schwachstelle unser Produkt?
   • Welche Versionen sind betroffen?
   • Wie hoch ist der Schweregrad in unserem Kontext?

3. Behebung

   • Patch entwickeln
   • Patch testen
   • Patch veröffentlichen

4. Kommunikation

   • Kunden benachrichtigen
   • Advisory veröffentlichen (wenn angemessen)
   • An ENISA melden (wenn aktiv ausgenutzt)

Dependency-Schwachstellen

Ihr Produkt enthält Drittanbieter-Komponenten. Wenn diese Schwachstellen haben:

• Direkte Dependencies: Sie müssen Auswirkung bewerten und aktualisieren, wenn betroffen
• Transitive Dependencies: Gleiche Verpflichtung, schwerer zu verfolgen
• OS/Plattform-Schwachstellen: Kann erfordern, dass Sie aktualisieren oder Mitigation kommunizieren

SBOM ist wesentlich: Sie können nicht verfolgen, was Sie nicht kennen.

Kostenmodellierung für Supportzeitraum

Viele Hersteller unterschätzen Supportkosten. Hier ist ein Framework:

Fixkosten (Pro Produktlinie)

Variable Kosten (Pro Jahr Support)

Beispiel-Kostenmodell

SUPPORTZEITRAUM-KOSTENMODELL

Produkt: Smart Home Hub v2.0
Supportzeitraum: 5 Jahre (Jan 2028 - Jan 2033)
Geschätzte Einheiten: 50.000

FIXKOSTEN (einmalig):
- Update-Pipeline-Setup:      15.000 €
- Signatur-Infrastruktur:     5.000 €
- Benachrichtigungssystem:    10.000 €
- Dokumentationsvorlagen:     5.000 €
ZWISCHENSUMME:                35.000 €

JÄHRLICHE KOSTEN:
- Security Engineer (0,2 FTE):  30.000 €/Jahr
- Dependency-Überwachung:       2.000 €/Jahr
- Test-Infrastruktur:           5.000 €/Jahr
- Kundenservice-Delta:          3.000 €/Jahr
ZWISCHENSUMME:                  40.000 €/Jahr × 5 = 200.000 €

INCIDENT-RESERVE (5 Jahre):
- Kritische Schwachstellen (geschätzt 2):  20.000 €
- Reguläre Patches (geschätzt 15):         30.000 €
ZWISCHENSUMME:                             50.000 €

GESAMTE 5-JAHRE-SUPPORTKOSTEN:             285.000 €
SUPPORTKOSTEN PRO EINHEIT:                 5,70 €

Wenn Verkauf zu 99 €/Einheit:
Support = 5,8% des Umsatzes

Wichtige Erkenntnis: Supportkosten pro Einheit sinken mit Volumen. Low-Volume-Produkte haben proportional höhere Support-Belastung.

End-of-Support-Planung

Der Supportzeitraum endet. Und dann?

Vor End-of-Support

12 Monate vorher:

• End-of-Support-Datum ankündigen
• An alle registrierten Nutzer kommunizieren
• Auf Produktseiten und in Dokumentation veröffentlichen
• Upgrade-/Ersatz-Wege anbieten

6 Monate vorher:

• Erinnerungs-Kommunikation
• Letzte Feature-Updates (falls vorhanden)
• Dokumentations-Freeze (aktuellen Stand erfassen)
• Letztes Sicherheitsupdate vorbereiten

Bei End-of-Support:

• Letztes Sicherheitsupdate mit allen bekannten Fixes veröffentlichen
• End-of-Support-Mitteilung veröffentlichen
• Produktdokumentation aktualisieren, um Status zu reflektieren
• Support-Kanäle auf Alternativen umleiten

Kundenkommunikations-Vorlage

END-OF-SUPPORT-MITTEILUNG

Produkt: [Produktname v1.0]
End-of-Support-Datum: [Datum]

Was das bedeutet:
- Sicherheitsupdates werden nach [Datum] nicht mehr bereitgestellt
- Technischer Support für diese Version endet
- Das Produkt funktioniert weiterhin, kann aber anfällig werden

Was Sie tun sollten:
- Option 1: Auf [Produktname v2.0] upgraden - [Link]
- Option 2: Mit [Alternativprodukt] ersetzen - [Link]
- Option 3: Auf eigenes Risiko weiter nutzen (nicht empfohlen)

Zeitplan:
- [Datum - 6 Monate]: Letztes Feature-Update
- [Datum - 1 Monat]: Letztes Sicherheitsupdate
- [Datum]: End of Support

Fragen? Kontaktieren Sie [Support-Kanal]

Nach End-of-Support

Ihre Verpflichtungen nach Supportzeitraum:

• Technische Dokumentation insgesamt 10 Jahre aufbewahren (ab letzter auf Markt gebrachter Einheit)
• Auf Marktüberwachungsanfragen reagieren
• Keine Verpflichtung, neue Schwachstellen zu patchen

Best Practices (freiwillig):

• Sicherheitskontakt für verantwortungsvolle Offenlegung pflegen
• Erwägen, bekannte-aber-nicht-behobene Schwachstellen zu veröffentlichen
• Update-Infrastruktur für kritische Notfälle verfügbar halten

Multi-Versions-Support

Die meisten Hersteller haben mehrere Produktversionen gleichzeitig auf dem Markt.

Gestaffelte Supportzeiträume

VERSIONS-SUPPORT-ZEITPLAN

v1.0: Jan 2028 ─────────────────────────── Jan 2033
v1.1:      Jul 2028 ─────────────────────────── Jul 2033
v2.0:           Jan 2029 ─────────────────────────── Jan 2034

Überlappender Support: Jan 2029 - Jan 2033 = 4 Jahre Dual-Support

Support-Matrix-Beispiel

PRODUKT-SUPPORT-MATRIX (Stand Jan 2030)

Version   Veröffentlicht    Support endet    Status
────────────────────────────────────────────────────
v1.0      Jan 2028          Jan 2033         Wartung
v1.1      Jul 2028          Jul 2033         Wartung
v2.0      Jan 2029          Jan 2034         Aktuell
v2.1      Jan 2030          Jan 2035         Aktuell

Wartung = Nur Sicherheitsupdates
Aktuell = Sicherheits- + Feature-Updates

Multi-Versions-Belastung reduzieren

Strategien zur Minimierung überlappenden Supports:

1. Einheitliche Codebasis: Code zwischen Versionen teilen, wo möglich
2. Backport-Prozess: Automatisierte oder semi-automatisierte Security-Backports
3. Kürzere Release-Zyklen: Häufigere Releases = vorhersehbarere Support-Fenster
4. Aggressive Deprecation: Kunden zum Upgrade ermutigen

Branchenspezifische Erwägungen

IoT-Geräte

• Viele haben 7-10 Jahre erwartete Lebensdauer
• Update-Mechanismen können begrenzt sein
• Kundenerreichbarkeit ist herausfordernd
• Erwägen: Fernupdate-Fähigkeit, Heartbeat-Überwachung

B2B-Software

• Enterprise-Kunden erwarten längeren Support
• Supportverträge können bereits 5 Jahre überschreiten
• Integrationskomplexität beeinflusst Update-Bereitstellung
• Erwägen: Erweiterte Support-Stufen, Professional Services

Unterhaltungselektronik

• Einzelhandelskanal erschwert Kundenkommunikation
• Endnutzer registrieren Produkte möglicherweise nicht
• Konkurrenz mit geplanter Obsoleszenz-Kultur
• Erwägen: In-Produkt-Update-Benachrichtigungen, App-basierte Updates

Industrieausrüstung

• 15-20 Jahre erwartete Lebensdauer üblich
• Ausfallzeit für Updates ist kostspielig
• Air-Gapped-Installationen
• Erwägen: Gestaffelte Rollouts, Kompatibilitätstests, professionelle Deployment-Services

Häufige Fehler

Sicherheit an Feature-Updates koppeln

Problem: Sicherheitspatches nur in Major-Releases verfügbar.

Warum es falsch ist: Kunden sollten keine neuen Features (und potenzielle neue Bugs) akzeptieren müssen, um Sicherheitsfixes zu bekommen.

Lösung: Security-Only-Update-Track für unterstützte Versionen pflegen.

Dependency-Updates ignorieren

Problem: Produktcode wird gepflegt, aber Dependencies veralten.

Warum es falsch ist: Die meisten Schwachstellen kommen von Dependencies.

Lösung: Dependency-Updates in Ihren Sicherheitswartungsumfang einbeziehen.

Keine Update-Verifizierung

Problem: Updates sind verfügbar, aber Kunden können Authentizität nicht verifizieren.

Warum es falsch ist: Angreifer können gefälschte "Updates" verteilen.

Lösung: Alle Updates signieren, Verifizierungsverfahren veröffentlichen.

Unklares End-of-Support

Problem: Support hört einfach auf. Keine Kommunikation.

Warum es falsch ist: Kunden mit anfälligen Produkten zurückgelassen, von denen sie nicht wissen, dass sie nicht unterstützt werden.

Lösung: Proaktiver, dokumentierter End-of-Support-Prozess.

Supportzeitraum nicht in Preisgestaltung

Problem: Produkt ohne Berücksichtigung von 5-Jahre-Supportkosten bepreist.

Warum es falsch ist: Support wird Kostenstelle, die Margen frisst.

Lösung: Supportkosten vor Preisgestaltung modellieren. Support als Herstellungskosten betrachten.

Supportzeitraum-Checkliste

SUPPORTZEITRAUM-PLANUNGS-CHECKLISTE

VOR MARKTBEREITSTELLUNG:

Infrastruktur:
[ ] Update-Build-Pipeline etabliert
[ ] Sicherer Update-Bereitstellungsmechanismus
[ ] Code-Signatur-Infrastruktur
[ ] Kundenbenachrichtigungssystem

Planung:
[ ] Supportzeitraum festgelegt (min. 5 Jahre)
[ ] End-of-Support-Datum berechnet
[ ] Kostenmodell erstellt
[ ] Support-Personalplanung
[ ] Dependency-Tracking etabliert

Dokumentation:
[ ] Supportzeitraum in Produktinfo angegeben
[ ] Update-Prozess dokumentiert
[ ] Kundenbenachrichtigungsvorlagen bereit

WÄHREND SUPPORTZEITRAUM:

Überwachung:
[ ] Schwachstellenüberwachung aktiv
[ ] Dependency-Updates verfolgt
[ ] Kundenfeedback-Kanäle überwacht

Reaktion:
[ ] Schwachstellen-Triage-Prozess
[ ] Patch-Entwicklungs-Workflow
[ ] Test- und Release-Prozess
[ ] Kundenbenachrichtigungsprozess

Meldung:
[ ] ENISA-Meldeintegration (bei Ausnutzung)
[ ] Advisory-Veröffentlichungsprozess
[ ] Support-Metriken-Tracking

END-OF-SUPPORT:

Kommunikation:
[ ] 12-Monate-Vorankündigung gesendet
[ ] 6-Monate-Erinnerung gesendet
[ ] Abschlussmitteilung bei End-of-Support
[ ] Dokumentation aktualisiert

Übergang:
[ ] Upgrade-Pfad dokumentiert
[ ] Letztes Sicherheitsupdate veröffentlicht
[ ] Support-Kanäle umgeleitet
[ ] Technische Dokumentation archiviert (10-Jahre-Aufbewahrung)

Verwandte Leitfäden

• CRA End-of-Life-Planung: Verantwortungsvolle Produktübergänge
• CRA-Compliance-Kostenabschätzung
• CRA-Technische Datei (Anhang VII) Leitfaden

Wie CRA Evidence hilft

CRA Evidence bietet Supportzeitraum-Management:

• Versions-Lebenszyklus-Tracking: Marktbereitstellungsdaten, Support-Enddaten
• Dependency-Überwachung: SBOM-basierte Schwachstellenwarnungen
• Kundenbenachrichtigung: Vorlagen und Verteilungs-Tracking
• Dokumentation: End-of-Support-Aufzeichnungen für Technische Dokumentation
• Compliance-Dashboard: Supportzeitraum-Status über Produkte hinweg

Planen Sie Ihre Supportzeiträume mit app.craevidence.com.

Dieser Artikel dient nur zu Informationszwecken und stellt keine Rechtsberatung dar. Für spezifische Compliance-Beratung wenden Sie sich an qualifizierte Rechtsberater.