CRA ondersteuningsperiode planning: 5 jaar beveiligingsupdates (en wat dat echt betekent)

Vijf jaar. Dat is de minimumperiode waarvoor u beveiligingsupdates voor uw producten moet leveren onder de CRA. Voor veel fabrikanten is dit een fundamentele verschuiving in hoe zij denken over de productlevenscyclus en ondersteuningskosten.

Deze gids behandelt wat de vereiste ondersteuningsperiode werkelijk betekent, hoe u deze plant en hoe u de onvermijdelijke overgang naar end-of-support aanpakt.

Samenvatting

• CRA vereist beveiligingsupdates voor minimaal 5 jaar (of de verwachte productlevensduur, afhankelijk van welke korter is)
• Updates moeten kwetsbaarheden "zonder vertraging" aanpakken en zijn gratis
• U heeft nodig: updateleveringsmechanisme, klantnotificatieproces, end-of-support plan
• Ondersteuningsperiode begint bij marktplaatsing, niet bij aankoop door klant
• Plan uw kostenmodel rond een ondersteuningscommitment van 5 jaar vóórdat u de prijs vaststelt

Wat de CRA werkelijk vereist

Artikel 13 en Bijlage I stellen de verplichtingen voor de ondersteuningsperiode vast:

Minimumduur

5 jaar vanaf marktplaatsing op de EU-markt, OF de verwachte productlevensduur, afhankelijk van welke korter is.

"Verwachte productlevensduur" wordt bepaald door:

• Redelijke klantverwachtingen op basis van de aard van het product
• Hoe vergelijkbare producten doorgaans worden gebruikt
• Wat u over het product communiceert

Voor de meeste software- en IoT-producten is 5 jaar het praktische minimum.

Wat u moet leveren

Gedurende de ondersteuningsperiode moet u:

1. Kwetsbaarheden zonder vertraging aanpakken

   • Beveiligingspatches voor bekende kwetsbaarheden leveren
   • Prioriteiten stellen op basis van ernst
   • Niet wachten op de "volgende grote release"

2. Updates veilig leveren

   • Automatische updates waar technisch mogelijk
   • Veilige distributie (ondertekend, geverifieerd)
   • Terugdraaicapaciteit als updates mislukken

3. Klanten informeren

   • Informeer over beschikbare beveiligingsupdates
   • Duidelijke installatie-instructies verstrekken
   • Beveiligingsrelevante informatie communiceren

4. Updates gratis verstrekken

   • Geen betaling voor beveiligingsupdates
   • Functie-updates mogen apart worden berekend

Wanneer begint de klok?

De ondersteuningsperiode begint wanneer het product "op de markt wordt gebracht", dat wil zeggen wanneer u het voor het eerst beschikbaar stelt in de EU.

Niet wanneer:

• De klant het koopt
• De klant het activeert
• Een specifieke eenheid wordt verzonden

Dit creëert voorraadrisico: Als uw product 18 maanden in de distributie ligt vóór verkoop, eindigt de ondersteuning nog steeds 5 jaar na de initiële marktplaatsing.

Voorbeeldtijdlijn

Jan 2028: Product v1.0 op EU-markt gebracht
          → Ondersteuningsperiode begint
          → Updates leveren tot jan 2033

Jun 2029: Klant koopt v1.0 bij distributeur
          → Klant heeft nog 3,5 jaar ondersteuning

Jan 2033: Ondersteuningsperiode eindigt
          → Geen verdere verplichting v1.0 te patchen
          → Klant heeft 18 maanden niet-ondersteund product

Beste praktijk: Marktplaatsingsdatums bijhouden per productversie, niet per eenheid.

Vereisten voor updatlevering

Automatische updates (voorkeur)

Waar technisch haalbaar en passend verwacht de CRA automatische beveiligingsupdates:

VEREISTEN AUTOMATISCHE UPDATES:

Technisch:
- Beveiligd downloadkanaal (TLS, ondertekende pakketten)
- Integriteitsverificatie vóór installatie
- Terugdraaicapaciteit als update mislukt
- Soepele afhandeling van verbindingsproblemen

Gebruikersbeheer:
- Gebruiker moet zich kunnen afmelden (met duidelijke waarschuwing)
- Gebruiker moet kunnen uitstellen (met redelijke grenzen)
- Kritieke updates kunnen uitstel overschrijven om veiligheidsredenen
- Updatestatus moet zichtbaar zijn voor gebruiker

Melding:
- Gebruiker informeren wanneer updates beschikbaar zijn
- Uitleggen wat de update aanpakt
- Installatie-instructies verstrekken indien handmatig

Handmatige updates (wanneer automatisch niet mogelijk is)

Sommige producten kunnen niet automatisch updaten: air-gapped systemen, industriële apparatuur, embedded apparaten zonder connectiviteit.

Voor deze producten:

• Downloadbare updatepakketten verstrekken
• Duidelijke versiebeheer en wijzigingenlog
• Installatiedocumentatie
• Verificatiemethode (checksums, handtekeningen)
• Melding via beschikbare kanalen (e-mail, webportaal, fysieke kennisgeving)

Updateondertekening

Alle beveiligingsupdates moeten cryptografisch worden ondertekend:

VEREISTEN UPDATEONDERTEKENING:

Code signing:
- Alle updatepakketten ondertekenen
- Speciale ondertekeningssleutel gebruiken (HSM-beschermd)
- Handtekeningverificatie opnemen in updateproces
- Publieke sleutel publiceren voor verificatie

Metadata:
- Versienummer
- Releasedatum
- Wijzigingenlog-/adviesreferentie
- Minimaal compatibele basisversie
- Tijdstempel handtekening

Kwetsbaarheidsrespons tijdens ondersteuningsperiode

De ondersteuningsperiode gaat niet alleen over het beschikbaar hebben van updates. Het gaat over het reageren op kwetsbaarheden zodra ze worden ontdekt.

Responsexpectaties

Dit zijn geen door de CRA voorgeschreven termijnen, maar ze weerspiegelen de verwachtingen van de sector en wat toezichthouders als "zonder vertraging" zullen beschouwen.

Kwetsbaarheden bijhouden

U heeft een proces nodig voor:

1. Intake van meldingen

   • CVD-beleid en contactpunt
   • Interne ontdekkingspijplijn
   • Monitoring van afhankelijkheden

2. Beoordeling

   • Heeft de kwetsbaarheid invloed op ons product?
   • Welke versies zijn getroffen?
   • Wat is de ernst in onze context?

3. Remediëring

   • Patch ontwikkelen
   • Patch testen
   • Patch uitbrengen

4. Communicatie

   • Klanten informeren
   • Advies publiceren (indien van toepassing)
   • Melden aan ENISA (indien actief misbruikt)

Kwetsbaarheden in afhankelijkheden

Uw product bevat componenten van derden. Wanneer deze kwetsbaarheden bevatten:

• Directe afhankelijkheden: U moet de impact beoordelen en updaten indien getroffen
• Transitieve afhankelijkheden: Dezelfde verplichting, moeilijker bij te houden
• OS/platform-kwetsbaarheden: Mogelijk moet u updaten of mitigatie communiceren

SBOM is essentieel: U kunt niet bijhouden wat u niet kent.

Kostenmodellering voor de ondersteuningsperiode

Veel fabrikanten onderschatten de ondersteuningskosten. Hier een raamwerk:

Vaste kosten (per productlijn)

Variabele kosten (per jaar ondersteuning)

Voorbeeld kostenmodel

KOSTENMODEL ONDERSTEUNINGSPERIODE

Product: Smart Home Hub v2.0
Ondersteuningsperiode: 5 jaar (jan 2028 - jan 2033)
Geschatte eenheden: 50.000

VASTE KOSTEN (eenmalig):
- Opzet update-pijplijn:     €14.000
- Ondertekeningsinfrastructuur: €4.500
- Meldingssysteem:           €9.000
- Documentatiesjablonen:     €4.500
SUBTOTAAL:                   €32.000

JAARLIJKSE KOSTEN:
- Beveiligingsengineer (0,2 fte): €27.000/jaar
- Monitoring afhankelijkheden:   €1.800/jaar
- Testinfrastructuur:            €4.500/jaar
- Delta klantenservice:          €2.700/jaar
SUBTOTAAL:                       €36.000/jaar × 5 = €180.000

INCIDENTRESERVE (5 jaar):
- Kritieke kwetsbaarheden (2 geschat): €18.000
- Reguliere patches (15 geschat):      €27.000
SUBTOTAAL:                             €45.000

TOTALE KOSTEN 5-JAAR ONDERSTEUNING: €257.000
KOSTEN PER EENHEID:                  €5,14

Bij verkoopprijs €89/eenheid:
Ondersteuning = 5,8% van de omzet

Kernbevinding: Kosten per eenheid dalen met volume. Producten met laag volume hebben een proportioneel hogere ondersteuningslast.

End-of-support planning

De ondersteuningsperiode eindigt. Wat dan?

Vóór end-of-support

12 maanden van tevoren:

• Einddatum ondersteuning aankondigen
• Alle geregistreerde gebruikers informeren
• Publiceren op productpagina's en documentatie
• Upgrade-/vervangingspaden aanbieden

6 maanden van tevoren:

• Herinneringscommunicatie
• Definitieve functie-updates (indien van toepassing)
• Documentatie bevriezen (actuele toestand vastleggen)
• Definitieve beveiligingsupdate voorbereiden

Bij end-of-support:

• Definitieve beveiligingsupdate uitbrengen met alle bekende fixes
• Mededeling end-of-support publiceren
• Productdocumentatie bijwerken om status te weerspiegelen
• Ondersteuningskanalen doorverwijzen naar alternatieven

Sjabloon klantcommunicatie

MEDEDELING END-OF-SUPPORT

Product: [Productnaam v1.0]
Einddatum ondersteuning: [Datum]

Wat dit betekent:
- Na [Datum] worden geen beveiligingsupdates meer geleverd
- Technische ondersteuning voor deze versie eindigt
- Het product blijft functioneren maar kan kwetsbaar worden

Wat u kunt doen:
- Optie 1: Upgraden naar [Productnaam v2.0] - [link]
- Optie 2: Vervangen door [Alternatief product] - [link]
- Optie 3: Gebruik voortzetten op eigen risico (niet aanbevolen)

Tijdlijn:
- [Datum - 6 maanden]: Definitieve functie-update
- [Datum - 1 maand]: Definitieve beveiligingsupdate
- [Datum]: Einde ondersteuning

Vragen? Neem contact op via [ondersteuningskanaal]

Na end-of-support

Uw verplichtingen na de ondersteuningsperiode:

• Technisch dossier 10 jaar bewaren (vanaf laatste eenheid op markt gebracht)
• Reageren op verzoeken van markttoezichtautoriteiten
• Geen verplichting om nieuwe kwetsbaarheden te patchen

Beste praktijken (vrijwillig):

• Beveiligingscontact handhaven voor verantwoorde onthulling
• Overwegen bekende-maar-niet-opgeloste kwetsbaarheden te publiceren
• Update-infrastructuur beschikbaar houden voor kritieke noodsituaties

Ondersteuning van meerdere versies

De meeste fabrikanten hebben meerdere productversies tegelijk op de markt.

Gespreide ondersteuningsperioden

TIJDLIJN VERSIE-ONDERSTEUNING

v1.0: jan 2028 ─────────────────────────── jan 2033
v1.1:      jul 2028 ─────────────────────────── jul 2033
v2.0:           jan 2029 ─────────────────────────── jan 2034

Overlappende ondersteuning: jan 2029 - jan 2033 = 4 jaar dubbele ondersteuning

Voorbeeld ondersteuningsmatrix

PRODUCTONDERSTEUNINGSMATRIX (per jan 2030)

Versie   Uitgebracht  Ondersteuning eindigt  Status
──────────────────────────────────────────────────
v1.0     jan 2028     jan 2033               Onderhoud
v1.1     jul 2028     jul 2033               Onderhoud
v2.0     jan 2029     jan 2034               Actueel
v2.1     jan 2030     jan 2035               Actueel

Onderhoud = Alleen beveiligingsupdates
Actueel = Beveiliging + functie-updates

Last van meerdere versies verminderen

Strategieën om overlappende ondersteuning te minimaliseren:

1. Gedeelde codebase: Code waar mogelijk delen tussen versies
2. Backportproces: Geautomatiseerde of semi-geautomatiseerde beveiligingsbackports
3. Kortere releasecycli: Frequentere releases = voorspelbaardere ondersteuningsvensters
4. Agressieve afschrijving: Klanten aanmoedigen te upgraden

Sectorspecifieke overwegingen

IoT-apparaten

• Veel hebben verwachte levensduur van 7-10 jaar
• Updatemechanismen kunnen beperkt zijn
• Klantbereikbaarheid is uitdagend
• Overweeg: capaciteit voor remote update, heartbeat-monitoring

B2B-software

• Zakelijke klanten verwachten langere ondersteuning
• Ondersteuningscontracten overschrijden mogelijk al 5 jaar
• Integratiescomplexiteit beïnvloedt updateimplementatie
• Overweeg: verlengde ondersteuningsniveaus, professionele diensten

Consumentenelektronica

• Retailkanaal compliceert klantcommunicatie
• Eindgebruikers registreren producten mogelijk niet
• Concurreert met cultuur van geplande veroudering
• Overweeg: in-product updatemeldingen, app-gebaseerde updates

Industriële apparatuur

• Verwachte levensduur van 15-20 jaar is gebruikelijk
• Downtime voor updates is kostbaar
• Air-gapped installaties
• Overweeg: gefaseerde uitrol, compatibiliteitstesten, professionele implementatiediensten

Veelgemaakte fouten

Beveiliging koppelen aan functie-updates

Probleem: Beveiligingspatches alleen beschikbaar in grote releases.

Waarom het fout is: Klanten moeten geen nieuwe functies (en mogelijk nieuwe bugs) accepteren om beveiligingsoplossingen te krijgen.

Oplossing: Beveiliging-enkel-updatetrack handhaven voor ondersteunde versies.

Afhankelijkheidsupdates negeren

Probleem: Productcode wordt onderhouden maar afhankelijkheden verouderen.

Waarom het fout is: De meeste kwetsbaarheden komen van afhankelijkheden.

Oplossing: Afhankelijkheidsupdates opnemen in uw beveiligingsonderhoud.

Geen updateverificatie

Probleem: Updates zijn beschikbaar maar klanten kunnen de authenticiteit niet verifiëren.

Waarom het fout is: Aanvallers kunnen nep-"updates" verspreiden.

Oplossing: Alle updates ondertekenen, verificatieprocedures publiceren.

Onduidelijk end-of-support

Probleem: Ondersteuning stopt gewoon… zonder communicatie.

Waarom het fout is: Klanten blijven achter met kwetsbare producten waarvan ze niet weten dat ze niet meer worden ondersteund.

Oplossing: Proactief, gedocumenteerd end-of-support-proces.

Ondersteuningsperiode niet in de prijs opgenomen

Probleem: Product geprijsd zonder rekening te houden met 5-jaar ondersteuningskosten.

Waarom het fout is: Ondersteuning wordt een kostenpost die de marges uitholt.

Oplossing: Ondersteuningskosten modelleren vóór prijsstelling. Ondersteuning beschouwen als kostprijs van verkochte goederen.

Checklist ondersteuningsperiode

CHECKLIST PLANNING ONDERSTEUNINGSPERIODE

VÓÓR MARKTPLAATSING:

Infrastructuur:
[ ] Update-buildpijplijn vastgesteld
[ ] Beveiligd updateleveringsmechanisme
[ ] Code signing-infrastructuur
[ ] Klantmeldingssysteem

Planning:
[ ] Ondersteuningsperiode bepaald (min. 5 jaar)
[ ] Einddatum ondersteuning berekend
[ ] Kostenmodel voltooid
[ ] Ondersteuningsbezetting gepland
[ ] Tracking afhankelijkheden vastgesteld

Documentatie:
[ ] Ondersteuningsperiode vermeld in productinformatie
[ ] Updateproces gedocumenteerd
[ ] Klantmeldingsjablonen gereed

TIJDENS ONDERSTEUNINGSPERIODE:

Monitoring:
[ ] Kwetsbaarheidsmonitoring actief
[ ] Updates afhankelijkheden bijgehouden
[ ] Feedbackkanalen klanten gemonitord

Respons:
[ ] Triageproces voor kwetsbaarheden
[ ] Patchontwikkelingsworkflow
[ ] Test- en releaseproces
[ ] Klantmeldingsproces

Rapportage:
[ ] ENISA-meldingsintegratie (bij misbruik)
[ ] AdviesPublicatieproces
[ ] Bijhouden ondersteuningscijfers

END-OF-SUPPORT:

Communicatie:
[ ] Aankondiging 12 maanden van tevoren verstuurd
[ ] Herinnering 6 maanden van tevoren verstuurd
[ ] Definitieve mededeling bij end-of-support
[ ] Documentatie bijgewerkt

Overgang:
[ ] Upgradepad gedocumenteerd
[ ] Definitieve beveiligingsupdate uitgebracht
[ ] Ondersteuningskanalen doorverwezen
[ ] Technisch dossier gearchiveerd (bewaring 10 jaar)

Belangrijk: De CRA vereist een minimale ondersteuningsperiode van 5 jaar voor beveiligingsupdates. Een kortere periode vereist een gedocumenteerde onderbouwing op basis van de verwachte productlevensduur.

Gerelateerde gidsen

• CRA end-of-life planning: verantwoorde productovergangen
• CRA-compliancekosten schatten
• CRA technisch dossier (Bijlage VII) gids

Hoe CRA Evidence helpt

CRA Evidence biedt beheer van de ondersteuningsperiode:

• Versie-levenscyclus bijhouden: Marktplaatsingsdatums, einddatums ondersteuning
• Monitoring afhankelijkheden: SBOM-gebaseerde kwetsbaarheidswaarschuwingen
• Klantmelding: Sjablonen en distributiebeheer
• Documentatie: End-of-support-records voor technisch dossier
• Compliance-dashboard: Status ondersteuningsperiode per product

Plan uw ondersteuningsperioden via app.craevidence.com.

Dit artikel is uitsluitend bedoeld ter informatie en vormt geen juridisch advies. Raadpleeg voor specifieke compliancebegeleiding een gekwalificeerde juridisch adviseur.