Skip to main content

Gidsen · Technologierecht

Cyber Resilience Act voor Cypriotische softwareleveranciers: routekaart 2026–27

Bepaal of uw softwareproduct onder de EU-CRA valt, organiseer de meldplicht sinds 2026 en bereid beveiliging, ondersteuning en conformiteit voor 2027 voor.

Zeno · Redactie · Bijgewerkt · 14 minuten leestijd
Inhoudsopgave
  1. Bepaal of het aanbod een product met digitale elementen is
  2. Wijs fabrikant-, importeur- en distributeursrollen per product toe
  3. Behandel de meldplicht van 2026 los van conformiteit in 2027
  4. Oefen de ENISA-meldprocedure voordat er een noodsituatie ontstaat
  5. Vertaal bijlage I naar concrete beveiligingswerkzaamheden
  6. Bepaal een verdedigbare ondersteuningsperiode en duidelijke gebruikersinformatie
  7. Bereid de juiste conformiteitsroute voor 2027 voor
  8. Voer drie praktische toetsen met bewijsstukken uit
  9. Bronnen

Een Cypriotische softwareonderneming die een verbonden product in de EU aanbiedt, moet twee data van de Cyber Resilience Act uiteenhouden. Sinds 11 september 2026 moeten fabrikanten actief uitgebuite kwetsbaarheden en ernstige beveiligingsincidenten melden via het centrale meldplatform van ENISA. De belangrijkste eisen voor productbeveiliging en conformiteit gelden in beginsel vanaf 11 december 2027. Wie pas in 2027 begint, kan een nu geldende meldplicht missen. Wie iedere cloudabonnementsdienst zonder onderzoek als CRA-product behandelt, kan het bereik van de wet verkeerd bepalen. Deze gids verbindt de werkingssfeer met een uitvoerbaar plan voor bestuur, productteam en juridisch adviseur, gebaseerd op Verordening (EU) 2024/2847 en officiële informatie van Commissie en ENISA.

Bepaal of het aanbod een product met digitale elementen is

De CRA ziet op producten met digitale elementen die op de Uniemarkt beschikbaar worden gesteld en waarvan het beoogde of redelijkerwijs voorzienbare gebruik een directe of indirecte logische of fysieke gegevensverbinding met een apparaat of netwerk omvat. Software zelf kan zo een product zijn; een tastbaar apparaat is niet nodig. Omschrijf precies wat u aanbiedt: een downloadbare toepassing, firmware, plug-in, verbonden apparaat of gecombineerd systeem. Leg vast onder welke naam het wordt verkocht, wie de ontwikkeling beheerst en wie beveiligingsupdates levert. Vestiging op Cyprus maakt een onderneming niet vrijgesteld als haar product in de EU wordt aangeboden. Beoordeel iedere productlijn en verkooproute afzonderlijk.

Het onderscheid tussen product en dienst vraagt om een technische beschrijving. Een oplossing voor gegevensverwerking op afstand kan meetellen als zij door of voor de fabrikant is ontwikkeld en het product zonder haar een functie niet kan uitvoeren. Een app waarvan de kernfunctie afhankelijk is van een API van de fabrikant vergt daarom onderzoek naar dat backendonderdeel in de beveiligingsbeoordeling. Een onafhankelijke website of clouddienst buiten de verantwoordelijkheid van de fabrikant wordt daarentegen niet automatisch onderdeel van het product. Gewone SaaS is niet enkel door gebruik van internet een CRA-product. Documenteer functionele afhankelijkheid, controle, contracten en doel van de externe component.

Documenteer uitzonderingen en grensgevallen in plaats van op een commerciële benaming te vertrouwen. Sommige productcategorieën vallen onder specifieke EU-regels, met uitzonderingen of afgestemde toepassing van de CRA. Vrije opensourcesoftware buiten een commerciële activiteit heeft een andere positie dan een commercieel aangeboden product; een opensourcesoftwaresteward heeft weer eigen verplichtingen. Beschrijf productfamilie, versie, distributiekanaal, verdienmodel, beoogde gebruikers en externe afhankelijkheden. Controleer bij twijfel de definities in de verordening en de nieuwste uitvoeringsrichtsnoeren van de Commissie. Een etiket als „alleen platform” of „alleen open source” vervangt de analyse niet. Bewaar de redenering zodat u haar na productwijzigingen kunt herzien.

Lees ook: DSA-gids over meldingen op platforms.

Grondslag en toelichting: Verordening (EU) 2024/2847, Cyber Resilience Act, artikelen 2, 3, 13, 14 en 71 en bijlagen I–IV; Europese Commissie: overzicht van de Cyber Resilience Act; Europese Commissie: uitvoeringsrichtsnoeren CRA 2026

Wijs fabrikant-, importeur- en distributeursrollen per product toe

De hoofdverplichtingen voor ontwerp, conformiteit en omgang met kwetsbaarheden liggen bij de fabrikant: de persoon of onderneming die een product ontwikkelt of laat ontwikkelen en het onder eigen naam of merk op de markt brengt. Een Cypriotische onderneming kan fabrikant zijn wanneer programmeurs elders werken of onderdelen van derden afkomstig zijn. Een wederverkoper van een product van buiten de EU kan daarentegen importeur of distributeur zijn, met andere controle- en samenwerkingsplichten. White-labelverkoop kan de rol veranderen. Leg het werkelijke merk, de contractuele toeleveringsketen, de goedkeuring van releases en de zakelijke contactpersonen vast. Het etiket in een uitbestedingsovereenkomst is niet beslissend.

Wijs voor iedere productlijn verantwoordelijken aan voor beveiligingsarchitectuur, goedkeuring van afhankelijkheden, technische documentatie, EU-conformiteitsverklaring en ontvangst van kwetsbaarheidsmeldingen. Ook wanneer open-sourcepakketten worden geïntegreerd, heeft de fabrikant zorgvuldigheid en een oplossing voor bekend geworden fouten nodig. Een inkoopclausule die alle verantwoordelijkheid bij een externe programmeur legt, verschuift wettelijke fabrikantplichten niet vanzelf van de onderneming die het afgewerkte product onder eigen merk aanbiedt. Omgekeerd is een marktplaats die alleen de verkoop door een ander faciliteert niet daarom zelf fabrikant. De verplichtingen als platform moeten afzonderlijk worden onderzocht. Maak een rollentabel per product en rechtspersoon.

De rol kan tijdens de levensduur wijzigen. Een ingrijpende wijziging na de algemene toepassingsdatum kan een eerder op de markt gebracht product in het volledige stelsel brengen. Houd uitgaven, grote functiewijzigingen, beveiligingsgevoelige koppelingen en de verantwoordelijke onderneming bij. Werk de rollenkaart bij een overname, verkoop of overdracht binnen een groep bij. Bij een incident moet direct duidelijk zijn welke entiteit meldt en wie technisch voldoende weet om de wettelijke drempel tijdig te beoordelen. Voeg een hoofdverantwoordelijke, vervanger en beslisroute toe. Een algemeen organigram zonder productrelatie helpt weinig wanneer de meldtermijn al loopt.

Lees ook: DSA-gids over handelaarstraceerbaarheid.

Grondslag en toelichting: Verordening (EU) 2024/2847, Cyber Resilience Act, artikelen 2, 3, 13, 14 en 71 en bijlagen I–IV; Europese Commissie: overzicht van de Cyber Resilience Act; Europese Commissie: uitvoeringsrichtsnoeren CRA 2026

Behandel de meldplicht van 2026 los van conformiteit in 2027

De CRA trad in december 2024 in werking. Artikel 14 over meldingen door fabrikanten is sinds 11 september 2026 van toepassing; de voornaamste productvereisten gelden in beginsel vanaf 11 december 2027. Volgens de Commissie omvat de meldplicht ook producten met digitale elementen die al vóór 2027 op de EU-markt beschikbaar waren. Wacht dus niet op een toekomstig CE-markeringsproject om toegang tot het meldplatform en een incidentteam te regelen. Zeg andersom niet dat een ouder product de volledige CRA-conformiteitsprocedure al heeft doorlopen enkel omdat het beveiligingsteam incidenten behandelt. Houd de twee fasen met aparte verantwoordelijken en bewijsstukken in uw projectplanning.

Een actief uitgebuite kwetsbaarheid is niet hetzelfde als iedere theoretische zwakte die een scanner vindt. Een ernstig incident is niet ieder klein supportverzoek. Baseer triage op de definities van de verordening en de feitelijke gevolgen voor productbeveiliging. Artikel 14 verlangt een vroegtijdige waarschuwing binnen 24 uur na bekendwording en een volgende kennisgeving binnen 72 uur. De termijnen voor eindverslagen verschillen tussen een kwetsbaarheid en een ernstig incident. Een algemene belofte om klanten snel te antwoorden of een maandelijkse bespreking stopt deze wettelijke klok niet. Maak beoordelingscriteria, bereikbaarheidsroosters en een verslag van het moment waarop de relevante kennis ontstond.

Voor opensourcesoftwarestewards begint de overeenkomstige verplichting van artikel 24, lid 3, pas op 11 december 2027. Pas de huidige fabrikanttermijn niet toe enkel omdat een organisatie code in een openbaar archief plaatst. Bepaal eerst haar juridische rol en of een product commercieel beschikbaar wordt gesteld. Houd een gedateerde matrix bij met product, rol, EU-beschikbaarheid, begindatum van iedere plicht en incidentcontact. Herzie deze na nieuwe releases, licentiewijzigingen of een gewijzigd verdienmodel. Een eenmalige notitie van de oprichting is geen betrouwbaar instrument voor de doorlopende beoordeling van meldingsplichtige gebeurtenissen.

Grondslag en toelichting: Verordening (EU) 2024/2847, Cyber Resilience Act, artikelen 2, 3, 13, 14 en 71 en bijlagen I–IV; Europese Commissie: CRA-meldverplichtingen; ENISA: centraal CRA-meldplatform; Europese Commissie: overzicht van de Cyber Resilience Act

Oefen de ENISA-meldprocedure voordat er een noodsituatie ontstaat

Het centrale CRA-meldplatform van ENISA is sinds 11 september 2026 operationeel. De fabrikant dient daar een melding in voor de aangewezen CSIRT-coördinator; ENISA en bevoegde instanties krijgen toegang volgens de regels van de verordening. Controleer voor een Cypriotische fabrikant de actuele informatie over de coördinator en de instructies van het platform in plaats van een oud incidentmailadres te gebruiken. Registreer een bevoegde vertegenwoordiger en een plaatsvervanger. Test aanmelden, multifactorverificatie en toegang buiten kantooruren. Een incident op zaterdag mag niet stranden doordat de enige accounthouder afwezig is of een token is verlopen. Leg ook vast wie namens de fabrikant de inhoud goedkeurt.

Een eerste bericht mag steunen op gegevens die vroeg beschikbaar zijn; wacht niet tot het oorzakenonderzoek helemaal is afgerond. Leg tijd van bekendwording, betrokken product en versies, aanwijzingen voor actieve uitbuiting of ernst, bekende schade, noodmaatregelen en open vragen vast. De Commissie beschrijft een waarschuwing binnen 24 uur en een vollediger kennisgeving binnen 72 uur. Bij een actief uitgebuite kwetsbaarheid volgt het eindverslag uiterlijk 14 dagen nadat een corrigerende maatregel beschikbaar is; bij een ernstig incident binnen een maand na de 72-uursmelding. Bewaar een tijdlijn, de ingediende teksten, ontvangstbevestigingen en interne goedkeuring. Latere aanvullingen kunnen onzekerheden uit het eerste bericht duidelijk rechtzetten.

Beoordeel parallelle meldingen apart. De CRA kan informatie aan getroffen gebruikers verlangen bij een actief uitgebuite kwetsbaarheid of ernstig incident. Betreffen de feiten persoonsgegevens, dan is een eigen toets van de AVG-meldplicht nodig; gereguleerde klanten of contracten kunnen nog andere termijnen opleggen. Gebruik één feitenlogboek met afzonderlijke wettelijke klokken, geadresseerden en tekstverantwoordelijken. Een CRA-indiening voldoet niet automatisch aan een melding van een datalek. ENISA publiceert actuele veelgestelde vragen en handleidingen voor het platform; controleer die na belangrijke wijzigingen. Oefen een weekendscenario met een kwetsbare cloudcomponent en een mislukte aanmelding van de plaatsvervanger, zodat procesgebreken vooraf zichtbaar worden.

Lees ook: AVG-gids voor datalekrespons.

Grondslag en toelichting: Verordening (EU) 2024/2847, Cyber Resilience Act, artikelen 2, 3, 13, 14 en 71 en bijlagen I–IV; Europese Commissie: CRA-meldverplichtingen; ENISA: centraal CRA-meldplatform; ENISA: handleiding voor de aangewezen vertegenwoordiger; Verordening (EU) 2016/679, AVG, artikelen 33 en 34

Vertaal bijlage I naar concrete beveiligingswerkzaamheden

Bijlage I verbindt beveiligingseigenschappen van het product met het beheer van kwetsbaarheden gedurende de ondersteuningsperiode. Artikel 13 verlangt een cyberbeveiligingsrisicobeoordeling die ontwerp, ontwikkeling, productie en onderhoud stuurt. Begin met beoogd gebruik, voorzienbaar misbruik, aanvalsvlakken en gevolgen van compromittering. Maak hiervan releasecriteria: passende veilige standaardinstellingen, toegangscontrole, kleiner aanvalsoppervlak, bescherming van vertrouwelijkheid en integriteit, beschikbaarheid en beveiligingsupdates. Een algemeen penetratietestcertificaat verklaart niet hoe de verschillende versies en componenten de toepasselijke eisen vervullen. Bewaar besluiten en testresultaten bij de werkelijk geleverde versie in plaats van bij een ideale architectuurschets.

Zorg voor een betrouwbaar proces voor afhankelijkheden en kwetsbaarheden. Het team moet weten welke externe en open-sourcecomponenten in welke uitgeleverde versie zitten, hoe een reparatie wordt beoordeeld en wie een beveiligingsupdate mag uitbrengen. Definieer een kanaal voor meldingen, een triageverantwoordelijke, gecoördineerde openbaarmaking en bewijs van herstel. De CRA verlangt zorgvuldigheid bij het opnemen van componenten en een werkbare omgang met kwetsbaarheden; de technische documentatie moet deze stappen navolgbaar maken. Een machinaal leesbare componentenlijst helpt operationeel, maar het bestandsformaat alleen bewijst niet alle eisen van bijlage I. Controleer tevens ondertekeningssleutels en de leveringsketen, niet uitsluitend de broncode.

Pas maatregelen op het risico toe in plaats van voor elke functie dezelfde controle te claimen. Een klein lokaal hulpmiddel en een toepassing voor beheer op afstand kunnen sterk verschillen in authenticatie, logging, isolatie en benodigde tests. De risicobeoordeling moet die verschillen uitleggen en worden aangepast als het dreigingsbeeld of de architectuur verandert. Neem een externe dienst op wanneer die noodzakelijk is voor een productfunctie. Test de distributie en terugdraaiing van updates: een patchproces dat alleen op papier bestaat kan juist een storing veroorzaken. Sla bewijs per release op zodat het conformiteitsdossier aansluit bij de daadwerkelijk verspreide code. Onderzoek persoonsgegevens daarnaast onder de aparte regels van de AVG.

Lees ook: Data Act-gids voor verbonden producten.

Grondslag en toelichting: Verordening (EU) 2024/2847, Cyber Resilience Act, artikelen 2, 3, 13, 14 en 71 en bijlagen I–IV; Europese Commissie: overzicht van de Cyber Resilience Act; Europese Commissie: uitvoeringsrichtsnoeren CRA 2026

Bepaal een verdedigbare ondersteuningsperiode en duidelijke gebruikersinformatie

Volgens artikel 13 bepaalt de fabrikant de ondersteuningsperiode aan de hand van de verwachte gebruiksduur, redelijke verwachtingen van gebruikers en andere factoren uit de verordening. Zij bedraagt in beginsel ten minste vijf jaar; bij een aantoonbaar kortere verwachte levensduur kan zij daarmee overeenkomen. Maak van deze uitzondering geen standaard voor jaarabonnementen zonder te beoordelen of het product of de versie werkelijk niet langer gebruikt wordt. Een duurzaam netwerkapparaat of desktophulpmiddel kan zelfs langer onderhoud vragen. Noteer uw aannames, vergelijkbare producten, gebruiksgegevens en beslissing per productfamilie. Contractduur en technische levensduur zijn niet automatisch gelijk.

Plan middelen voor de gehele toezegging: monitoring van kwetsbaarheden, updates van onderdelen, ondertekeningssleutels, uitrolinfrastructuur, berichten aan gebruikers en continuïteit bij personeelswisselingen. Een product dat vandaag goedkoop wordt verkocht, kan later aanzienlijke onderhoudskosten veroorzaken. Vermeld de einddatum van de ondersteuning met maand en jaar bij aankoop helder en begrijpelijk, zoals de Commissie uitlegt. Verstop de informatie niet op een hulppagina die de commerciële belofte tegenspreekt. Gebruikt een klant het product in een gereguleerde dienst, dan moet hij zijn eigen risico en overstapmogelijkheden kunnen beoordelen. Communiceer wezenlijke beperkingen vroeg en consequent.

Gebruikersinstructies volgens bijlage II moeten veilige installatie, bediening en toepassing mogelijk maken. Beschrijf de updatewijze, het meldpunt voor kwetsbaarheden, ondersteunde versies en belangrijke afhankelijkheden. Laat een echte gebruiker een patch zoeken en uitleggen wanneer de ondersteuning eindigt. Noem bij een kritieke veiligheidsupdate de getroffen versies zonder onnodig details voor uitbuiting prijs te geven. Documentatie en werkelijk releasegedrag moeten overeenkomen. Een claim over automatische updates is misleidend wanneer een deel van de geïnstalleerde klanten op een kwetsbare versie blijft en geen waarschuwing krijgt. Een openbaar versieplan heeft slechts waarde wanneer het team het daadwerkelijk onderhoudt.

Grondslag en toelichting: Verordening (EU) 2024/2847, Cyber Resilience Act, artikelen 2, 3, 13, 14 en 71 en bijlagen I–IV; Europese Commissie: overzicht van de Cyber Resilience Act; Europese Commissie: uitvoeringsrichtsnoeren CRA 2026

Bereid de juiste conformiteitsroute voor 2027 voor

Voor een product waarop de hoofdeisen van toepassing zijn, beoordeelt de fabrikant de conformiteit, stelt technische documentatie en een EU-conformiteitsverklaring op en brengt voor het in de handel brengen een CE-markering aan. Het dossier moet risicobeoordeling, beveiligingseisen, ontwerpkeuzes, tests, kwetsbaarheidsbehandeling en instructies verbinden met een concrete productversie. De marketingclaim „CRA-conform” is geen beoordeling. Maak het productteam verantwoordelijk voor bewijs tijdens de ontwikkeling. Maanden aan ontwerpbesluiten vlak vóór december 2027 uit het geheugen reconstrueren is duur en onzeker. Bewaar voor iedere versie een vrijgavebesluit met documentstatus en bevoegde ondertekenaar.

De juiste beoordelingsprocedure hangt af van productcategorie en beschikbare geharmoniseerde normen of certificeringsregelingen. Volgens de samenvatting van de Commissie kunnen gewone producten doorgaans interne controle gebruiken. Producten met kernfuncties van belangrijke of kritieke categorieën uit bijlagen III en IV kunnen een andere route nodig hebben. Neem niet aan dat om het even welk cybercertificaat, SOC-verslag of leveranciersbelofte het wettelijke traject vormt. Controleer de geldende gedelegeerde handelingen voor classificatie en normen die daadwerkelijk in het EU-kader zijn aangewezen. Motiveer de categorie van het specifieke product en leg vast wie de eindverklaring ondertekent. Vraag voor marktintroductie deskundig advies bij twijfel.

Behandel oudere producten nauwkeurig. De Commissie zegt dat producten die vóór 11 december 2027 in de handel zijn gebracht bij een ingrijpende wijziging vanaf die datum onder het algemene CRA-kader kunnen vallen, terwijl de meldplicht al producten omvat die beschikbaar zijn. Een nieuwe hoofdversie kan een nieuwe beoordeling van reikwijdte en conformiteit vergen; een gewone veiligheidspatch is niet automatisch ingrijpend. Maak een releaseverslag over gevolgen voor veiligheid, productidentiteit en gewijzigde functies. Daarmee voorkomt u zowel onnodige herclassificatie als distributie van een wezenlijk veranderd product op basis van verouderde documenten. Het besluit hoort vóór de verkoopvrijgave te worden genomen.

Lees ook: gids over toegankelijkheid van webwinkels.

Grondslag en toelichting: Verordening (EU) 2024/2847, Cyber Resilience Act, artikelen 2, 3, 13, 14 en 71 en bijlagen I–IV; Europese Commissie: overzicht van de Cyber Resilience Act; Europese Commissie: uitvoeringsrichtsnoeren CRA 2026

Voer drie praktische toetsen met bewijsstukken uit

Test eerst de reikwijdte aan twee echte aanbiedingen: een installeerbare toepassing die een eigen API aanroept en een afzonderlijk abonnement dat uitsluitend in de cloud werkt. Schrijf op waarom ieder aanbod wel of niet voldoet aan de definities van product en externe gegevensverwerking. Benoem fabrikant en eventuele importeur of distributeur. Simuleer daarna een kwetsbaarheid in een afhankelijkheid van een vorig jaar verkochte versie. Kan het team getroffen producten vinden, actieve uitbuiting beoordelen, de termijn van artikel 14 starten en het ENISA-platform bereiken? De oude verkoopdatum heft de huidige meldplicht niet vanzelf op. Bewaar de analyse en onopgeloste beslispunten.

Toets vervolgens de onderhoudstoezegging bij een product dat naar verwachting minstens vijf jaar wordt gebruikt. Welke updates, medewerkers, sleutels en infrastructuur zijn gedurende die tijd nodig? Kan de koper de einddatum van ondersteuning vinden en een beveiligingsreparatie krijgen? Kan het team een meegeleverd onderdeel tot de exacte versie en corrigerende maatregel herleiden? Als alles afhangt van het geheugen van één ontwikkelaar of een leverancier zonder responsplicht, verbeter de processen vóór uitbreiding van de afzet. Geef iedere bevinding een eigenaar en datum. Een beleid op papier toont niet aan dat patches werkelijk aankomen of gebruikers worden geïnformeerd.

Controleer tot slot het conformiteitsdossier voor 2027 aan een echte releasekandidaat: besluit over werkingssfeer, risicobeoordeling, bewijs voor bijlage I, componentencontrole, gebruikersinstructies, ondersteuningsperiode, juiste beoordelingsprocedure en eigenaar van de verklaring. Vul hiaten voor publicatie aan in plaats van onbewezen beloften op de website te plaatsen. Hercontroleer materialen van Commissie en ENISA bij ieder belangrijk moment; gefaseerde toepassing, gedelegeerde handelingen en platforminstructies maken een statische checklist kwetsbaar. Een verdedigbaar dossier laat tegelijk zien wat de onderneming juridisch heeft geconcludeerd en hoe het product technisch functioneert.

Grondslag en toelichting: Verordening (EU) 2024/2847, Cyber Resilience Act, artikelen 2, 3, 13, 14 en 71 en bijlagen I–IV; Europese Commissie: overzicht van de Cyber Resilience Act; Europese Commissie: CRA-meldverplichtingen; ENISA: centraal CRA-meldplatform

Primaire bronnen en toepassingsgebied

Bronnen gecontroleerd: 7 oktober 2026. Deze gids betreft de Republiek Cyprus. Voorbeelden zijn hypothetisch en geen klantendossiers. Controleer de actuele officiële vereisten voordat u een aanvraag indient.

Praktische gidsen over dit onderwerp

Veelgestelde vragen

Geldt de Cyber Resilience Act voor een softwareonderneming op Cyprus?
Dat kan wanneer zij een gedekt product met digitale elementen op de EU-markt aanbiedt. Beoordeel product, verbinding, commerciële beschikbaarheid en juridische rol; de vestigingsplaats beslist dit niet alleen.
Is een abonnement op uitsluitend SaaS automatisch een CRA-product?
Nee. Externe gegevensverwerking telt onder voorwaarden mee als zij door of voor de fabrikant is ontwikkeld en nodig is voor een productfunctie. Een zelfstandige clouddienst vraagt een eigen analyse.
Sinds wanneer geldt de CRA-meldplicht voor kwetsbaarheden en incidenten?
Artikel 14 geldt voor fabrikanten sinds 11 september 2026. De belangrijkste eisen voor productbeveiliging en conformiteit gelden in beginsel vanaf 11 december 2027.
Waar meldt een fabrikant een actief uitgebuite kwetsbaarheid?
Via het centrale CRA-meldplatform van ENISA. De melding bereikt de bevoegde CSIRT-coördinator volgens de verordening. Regel toegang voor een vertegenwoordiger en vervanger vóór een incident.
Moet iedere kwetsbaarheid binnen 24 uur worden gemeld?
Nee. Artikel 14 betreft een actief uitgebuite kwetsbaarheid en afzonderlijk een ernstig incident met gevolgen voor productbeveiliging. De eerste waarschuwing moet binnen 24 uur na bekendwording worden gedaan.
Mag een fabrikant slechts één jaar beveiligingsondersteuning aanbieden?
Normaal bedraagt de periode minstens vijf jaar, maar zij kan aansluiten op een aantoonbaar kortere verwachte gebruiksduur. Motiveer dit en maak de einddatum bij aankoop duidelijk.
Zijn producten die vóór december 2027 zijn verkocht geheel uitgezonderd?
Nee. De meldplicht omvat reeds beschikbare producten. De hoofdeisen kunnen gelden wanneer een ouder product vanaf 11 december 2027 ingrijpend wordt gewijzigd.

Opgesteld met AI-ondersteuning op basis van de vermelde primaire bronnen. Dit houdt geen individuele professionele controle in. Algemene informatie, geen juridisch of fiscaal advies. Redactioneel beleid

Advies op maat nodig?

Boek een gratis gesprek van 30 minuten. Zeno coördineert onafhankelijke advocaten met een Cypriotische beroepsvergunning en accountants met een ICPAC-vergunning en stuurt binnen 24 uur een schriftelijke omschrijving van de werkzaamheden.

Boek een gratis gesprek