Introductie
Voor IoT-fabrikanten gaat het gesprek niet langer alleen over beveiligingsfuncties op het moment van verkoop. Het gaat erom in staat te blijven deze producten te ondersteunen, monitoren en updaten gedurende de volledige periode waarin ze naar verwachting in het veld in gebruik blijven. Daar wordt robuuste connectiviteit onderdeel van de CRA-risicodiscussie.
Voor veel IoT-OEM’s ligt het CRA-risico niet alleen in de vraag of het apparaat veilig is gebouwd. Het gaat erom of de fabrikant dat apparaat in het veld nog kan bereiken wanneer een kwetsbaarheid moet worden onderzocht, een beveiligingsupdate moet worden uitgerold, of wanneer de klok voor incidentrapportage is gestart.
In het kort: De CRA maakt van connectiviteit geen afzonderlijke compliancecategorie, maar vereist wel dat fabrikanten nadenken over lifecycle-beveiliging, kwetsbaarhedenbeheer, updates, beschikbaarheid en het aanvalsoppervlak. Als een geïmplementeerd IoT-apparaat niet bereikbaar is, of standaard blootgesteld wordt aan het publieke internet, worden deze verplichtingen moeilijker aantoonbaar en uitvoerbaar.
Wat de CRA daadwerkelijk vraagt van IoT-fabrikanten
Vastgesteld als Verordening (EU) 2024/2847 op 23 oktober 2024 en gepubliceerd in het Publicatieblad van de Europese Unie op 20 november 2024, stelt de CRA horizontale cyberbeveiligingseisen vast voor “producten met digitale elementen”. Die definitie kan een groot deel van het IoT-landschap omvatten: sensoren, gateways, telematica-eenheden, telezorgapparatuur, EV-laadpalen, betaalterminals, slimme meters en, waar van toepassing, de software of oplossingen voor gegevensverwerking op afstand die deze ondersteunen.
Opmerking: Producten die onder sectorspecifieke regelgeving vallen, waaronder medische hulpmiddelen, in-vitrodiagnostiek, bepaalde voertuigregelgevingen, luchtvaartgecertificeerde producten en maritieme apparatuur, kunnen buiten de reikwijdte van de CRA vallen en dienen afzonderlijk onder die regelgevingen te worden beoordeeld.
De toepassings- en implementatietijdlijn van de CRA is als volgt:

Voor IoT-omgevingen met een lange levensduur is dat een veel korter tijdsbestek dan het lijkt.
Voor individuele producten die vóór 11 december 2027 op de EU-markt zijn gebracht, ligt de situatie genuanceerder: de belangrijkste CRA-verplichtingen zijn vanaf die datum alleen van toepassing wanneer deze producten vervolgens een substantiële wijziging ondergaan.
Producten die na de volledige inwerkingtreding nieuw op de markt worden gebracht, moeten voldoen aan de toepasselijke CRA-route. De meldingsverplichtingen van artikel 14 gelden echter voor alle producten binnen de reikwijdte die vóór 11 december 2027 al op de markt van de Unie beschikbaar zijn gesteld.
Voor deze producten die vóór 11 december 2027 op de markt zijn gebracht, brengt artikel 14 op zichzelf het product niet onder het volledige CRA-regime voor kwetsbaarheidsbeheer en conformiteit, tenzij het product na die datum substantieel wordt gewijzigd.
Voor fabrikanten komen de verplichtingen neer op drie kernpunten:
- Security by design. Producten moeten voldoen aan de essentiële cyberbeveiligingseisen van Bijlage I. De implementatie moet worden onderbouwd door een gedocumenteerde cyberbeveiligingsrisicobeoordeling, inclusief veilige standaardconfiguraties, bescherming van vertrouwelijkheid en integriteit, en een zo klein mogelijk aanvalsoppervlak.
- Kwetsbaarheidsbeheer gedurende de volledige ondersteuningsperiode:
- Kwetsbaarheden identificeren, documenteren en verhelpen gedurende de gehele periode waarin het product naar verwachting in gebruik zal zijn.
- Beveiligingsupdates kosteloos aanbieden, met automatische updates als standaardoptie waar van toepassing, ondersteund door duidelijke gebruikersinformatie, opt-outmogelijkheden en opties voor tijdelijke uitstel waar relevant. Daarnaast moet de ondersteuningsperiode vooraf aan kopers worden gecommuniceerd en moet documentatie van componenten worden bijgehouden, inclusief een Software Bill of Materials (SBOM).
- In de meeste gevallen moet deze ondersteuningsperiode minimaal vijf jaar bedragen, tenzij het product naar verwachting korter wordt gebruikt. De periode kan langer moeten zijn wanneer redelijkerwijs verwacht kan worden dat het product gedurende een langere termijn wordt ingezet. Zodra deze periode is vastgesteld, maakt zij deel uit van de productdocumentatie en vormt zij een marktverplichting voor de volledige duur ervan.
- Conformiteitsbeoordeling en CE-markering. Voor nieuwe producten binnen de reikwijdte die na de relevante toepassingsdatum van de CRA op de markt worden gebracht, zijn de toepasselijke conformiteitsroute en CE-markering essentieel voor legale toegang tot de EU-markt. De route hangt af van de productcategorie:
- Standaardproducten (buiten de categorieën belangrijk en kritiek): doorgaans zelfbeoordeling.
- Belangrijke producten Klasse I, bijvoorbeeld routers en modems met internetverbinding, slimme deursloten en beveiligingscamera’s voor thuisgebruik: zelfbeoordeling wanneer geharmoniseerde normen, gemeenschappelijke specificaties of een relevant Europees cyberbeveiligingscertificeringsschema worden toegepast; anders is een beoordeling door een derde partij vereist.
- Belangrijke producten Klasse II, zoals firewalls en systemen voor detectie en preventie van inbraken: beoordeling door een derde partij of toepasselijke certificering.
- Kritieke producten, zoals gateways voor slimme meters en secure elements: vereisen momenteel beoordeling door een derde partij of, waar beschikbaar en van toepassing, een Europees cyberbeveiligingscertificeringsschema. Een Gedelegeerde Verordening die een vermoeden van conformiteit vaststelt voor het European Cybersecurity Certification Scheme on Common Criteria (EUCC) wordt verwacht in het vierde kwartaal van 2026.
Voor compliance-teams. De Europese Commissie heeft inmiddels Uitvoeringsverordening (EU) 2025/2392 vastgesteld. Deze bevat de technische beschrijvingen die bepalen of de kernfunctionaliteit van een product valt binnen de belangrijke of kritieke productcategorieën van de CRA. Geharmoniseerde CRA-normen worden ontwikkeld door ETSI, CEN en CENELEC op basis van het standaardisatieverzoek van de Commissie. De eerste opleveringen worden verwacht vanaf het derde kwartaal van 2026. Totdat deze normen zijn gepubliceerd, zal de zelfbeoordelingsroute voor Belangrijke Producten Klasse I afhankelijk zijn van gemeenschappelijke specificaties of toepasselijke certificering waar beschikbaar; anders kan een beoordeling door een derde partij noodzakelijk zijn.
Daarbovenop geldt vanaf 11 september 2026 de meldingsplicht voor actief misbruikte kwetsbaarheden en ernstige beveiligingsincidenten. Fabrikanten moeten binnen 24 uur nadat zij kennis hebben genomen van een incident een eerste waarschuwing indienen, binnen 72 uur een uitgebreidere melding doen en een eindrapport indienen uiterlijk 14 dagen nadat een corrigerende of mitigerende maatregel beschikbaar is voor een actief misbruikte kwetsbaarheid, of binnen één maand na de 72-uursmelding in het geval van een ernstig incident.
Gedelegeerde Verordening (EU) 2026/881 van de Commissie, vastgesteld in december 2025 en gepubliceerd in april 2026, bepaalt op welke cyberbeveiligingsgronden een CSIRT die een melding als eerste ontvangt, de verspreiding naar andere CSIRT’s mag uitstellen. De eigen verplichtingen van fabrikanten om binnen 24 uur, 72 uur en via een eindrapport te melden, blijven ongewijzigd. De maximale sancties voor niet-naleving van Bijlage I en de artikelen 13 en 14 bedragen tot €15 miljoen of 2,5% van de wereldwijde jaaromzet, afhankelijk van welk bedrag hoger is.
Beschikbaarheid is niet alleen een SLA, maar een essentiële vereiste
Dit moet niet worden gelezen als een uptimegarantie die door de CRA wordt opgelegd; beschikbaarheid maakt deel uit van de beveiligingseigenschappen van een product die fabrikanten moeten meenemen en onderbouwen via hun risicobeoordeling, ontwerpkeuzes en ondersteuningsprocessen.
Voor cellulair IoT heeft dit zeer praktische gevolgen. Wanneer een fabrikant geen verbinding kan maken met een uitgerold apparaat, kan hij mogelijk niet:
- beveiligingsupdates leveren, inclusief automatische updates waar van toepassing;
- de telemetrie verzamelen die nodig is om vast te stellen dat een kwetsbaarheid actief wordt misbruikt;
- de essentiële functie beschermen waarvoor het product oorspronkelijk op de markt is gebracht.
De wettelijke meldingsverplichting begint zodra een fabrikant kennis krijgt van een misbruikte kwetsbaarheid of een ernstig incident. Een langdurig verlies van connectiviteit met uitgerolde apparaten kan het echter moeilijker maken om bewijs te verzamelen, incidenten met voldoende zekerheid te onderzoeken en aan de meldingsverplichtingen te voldoen.
Verlies van connectiviteit is daarom niet alleen een probleem van servicekwaliteit. Onder de CRA raakt het ook aan beveiligingsverplichtingen en de beschikbaarheid van essentiële functies. Veerkrachtige connectiviteit bewijst op zichzelf niet dat aan de CRA-eisen rond beschikbaarheid wordt voldaan, maar kan wel deel uitmaken van het technische en operationele bewijs waarmee een fabrikant aantoont hoe essentiële functies, updates en incidentrespons onder praktijkomstandigheden beschikbaar en beheersbaar blijven.
De kwetsbaarheid van één netwerk
Veel cellulaire IoT-omgevingen zijn nog steeds afhankelijk van één thuisoperator, één core-netwerkpad of één commerciële roamingarchitectuur, zelfs wanneer de SIM-kaart wordt omschreven als “multi-network” of roaming. Wanneer verkeer en authenticatie afhankelijk blijven van die primaire core, kan een storing in het core-netwerk de volledige IoT-omgeving offline halen, zelfs als dekking via partnernetwerken nog beschikbaar is.
Dat werkt meestal prima. Het werkt echter minder goed wanneer:
- het core-netwerk van de thuisoperator een storing ondervindt in het land of de regio waar de IoT-omgeving is uitgerold;
- één operator een lokale radiostoring heeft die niet wordt opgevangen door roamingpartners;
- een roamingovereenkomst wijzigt; of
- de uitfasering van 2G- en 3G-netwerken terugvalopties wegneemt waarop oudere installaties ongemerkt vertrouwden.
Stel u het moment voor waarop het echt telt: een kwetsbaarheid wordt actief misbruikt. Zodra de fabrikant hiervan op de hoogte is, begint de 24-uurs termijn voor de eerste melding te lopen, maar een deel van de uitgerolde apparaten is onbereikbaar doordat het primaire mobiele core-netwerk verstoord is. Het probleem gaat dan niet langer alleen over connectiviteitsprestaties; het raakt direct aan onderzoek, bewijsverzameling en het vermogen van de fabrikant om met voldoende zekerheid te handelen.
Voor een OEM concentreert een architectuur die afhankelijk is van één netwerk verrassend veel risico in één leveranciersrelatie. Het apparaat kan volledig secure-by-design zijn, volledig gepatcht en ondersteund worden door een zorgvuldig onderhouden SBOM, en toch onbereikbaar zijn tijdens een netwerkstoring of degradatie van de dienstverlening. Vanuit CRA-perspectief is dat tegelijkertijd een vraagstuk van beschikbaarheid, updatebaarheid en mogelijk ook rapportageverplichtingen.
Connectiviteit is geen compliance, maar kan wel onderdeel van het bewijs worden
De CRA schrijft geen specifieke connectiviteitsarchitectuur voor. Zo bepaalt de verordening niet dat cellulaire IoT-producten gebruik moeten maken van multi-network SIM-kaarten. Wel vereist zij dat fabrikanten de beveiliging gedurende de volledige verwachte levensduur van het product waarborgen, kwetsbaarheden beheren, updates leveren en essentiële functies beschermen. Voor verbonden producten die in het veld zijn geïmplementeerd, zijn deze verplichtingen aanzienlijk eenvoudiger uit te voeren én aan te tonen wanneer de fabrikant het apparaat kan bereiken op het moment dat dat nodig is.
Vanuit dat perspectief krijgt connectiviteitsveerkracht een logische plaats binnen gesprekken over CRA-gereedheid. Niet als een zelfstandige wettelijke verplichting, maar als onderdeel van het operationele bewijs waarmee een fabrikant kan aantonen dat hij voldoet aan de verplichtingen die de verordening daadwerkelijk oplegt.
Waar rSIM in beeld komt
De gepatenteerde rSIM van CSL biedt op SIM-niveau een oplossing voor het vraagstuk van connectiviteitsveerkracht. De SIM bevat twee operatorprofielen, monitort zelfstandig de gezondheid van het netwerk en schakelt automatisch over naar het back-upprofiel wanneer het primaire netwerkpad niet langer voldoende functioneert. Zodra het primaire netwerk weer beschikbaar is, schakelt rSIM automatisch terug. Het apparaat zelf hoeft deze logica niet uit te voeren.
In het kader van CRA-gereedheid leidt dit in de praktijk tot minder downtime, een hogere slagingskans van update-uitrol over de volledige IoT-omgeving en een sterker verhaal tijdens conformiteitsbeoordelingen wanneer een beoordelaar vraagt hoe essentiële functies beschikbaar blijven.
Voor IoT-fabrikanten die nadenken over productontwerp in het CRA-tijdperk zijn vier eigenschappen bijzonder relevant:
- Geen hardwareherontwerp nodig. rSIM werkt met apparaten die reeds UICC- of eUICC-SIM-kaarten ondersteunen, zonder dat dual-SIM hardware, extra firmwarecomplexiteit of gespecialiseerde modules nodig zijn.
- Minder code die moet worden beveiligd, gedocumenteerd en onderhouden. Het veerkrachtmechanisme bevindt zich in de SIM zelf en niet in de apparaatsoftware. Daardoor blijft de firmware van de OEM eenvoudiger en neemt de hoeveelheid apparaatcode, services en afhankelijkheden af die moeten worden beveiligd en opgenomen in technische documentatie en de SBOM-context. (Componenten voor SIM-beheer en connectiviteitsbeheer kunnen uiteraard nog steeds afzonderlijke due-diligencevereisten binnen de toeleveringsketen met zich meebrengen.)
- Bewezen in bedrijfskritische IoT-omgevingen. rSIM is afgestemd op GSMA-standaarden en wordt op grote schaal ingezet in missie- en levenskritische toepassingen, waaronder telezorg, EV-laadinfrastructuur, retail-PoS, lone-worker-oplossingen, CCTV en automotive toepassingen. In deze sectoren heeft downtime directe gevolgen.
- Het praktische voordeel voor OEM’s is dat extra veerkracht kan worden toegevoegd via inkoop en provisioning, in plaats van via een hardwareherontwerp. Dat is bijzonder relevant nu productroadmaps al onder druk staan door de uitfasering van 2G en 3G, de overgang naar eSIM-technologie (met name GSMA SGP.32 voor IoT Remote SIM Provisioning) en parallel lopende CRA-complianceprojecten.
Het verkleinen van het aanvalsoppervlak: private APN's en VPN's
Bijlage I van de CRA vraagt om meer dan alleen beschikbaarheid. Fabrikanten moeten ook het aanvalsoppervlak en blootgestelde externe interfaces beperken, de vertrouwelijkheid en integriteit van gegevens tijdens transport beschermen en de toegang tot apparaten beheersen. Voor cellulair IoT maakt de manier waarop een apparaat verbinding maakt met het internet – of idealiter juist niet – daarom nadrukkelijk deel uit van deze discussie.
Een standaard publieke APN biedt een apparaat een uitgaande verbinding naar het publieke internet. Dat is operationeel eenvoudig, maar afhankelijk van de configuratie van de operator, het IP-adresseringsmodel en de firewallarchitectuur kan dit ook betekenen dat het apparaat in grotere mate afhankelijk wordt van zijn eigen firmwarebeveiliging om ongeautoriseerde toegang te voorkomen. Voor een CRA-conformiteitsbeoordeling legt dat een aanzienlijke verantwoordelijkheid bij het apparaat zelf.
Een private APN kiest voor een andere benadering. Wanneer deze wordt geconfigureerd met private routing naar de beveiligde omgeving van de fabrikant of eindklant, kan het dataverkeer van apparaten via een dedicated gateway in het mobiele netwerk worden geleid zonder dat het apparaat rechtstreeks wordt blootgesteld aan het publieke internet, afhankelijk van de routeringsarchitectuur van de operator en de verdere netwerkverbindingen. In combinatie met VPN-tunneling biedt dit fabrikanten:
- Een kleiner en beter verdedigbaar aanvalsoppervlak, waarbij apparaten niet zichtbaar of rechtstreeks benaderbaar zijn vanaf het publieke internet.
- Versleuteld datatransport tussen gedefinieerde netwerkeindpunten, waarmee wordt bijgedragen aan de eisen rond vertrouwelijkheid en integriteit uit Bijlage I. Wanneer aanvullende end-to-end beveiliging vereist is, kan dit worden gecombineerd met encryptie op applicatie- of apparaatniveau.
- Authenticatie op SIM-niveau en toegangscontrole via APN- en private-routingmechanismen, aanvullend op de beveiligingsmaatregelen die door de firmware van het apparaat worden afgedwongen.
- Duidelijke scheiding van dataverkeer, waardoor telemetrie, logging en incidentonderzoek eenvoudiger beheersbaar worden.
Voor OEM’s is dit een architectuurkeuze waarmee bepaalde beveiligingsmaatregelen kunnen worden verplaatst van de apparaatfirmware naar de beheerde connectiviteitslaag, waar zij centraal over de gehele IoT-omgeving kunnen worden beheerd.
Dat heeft directe gevolgen voor twee van de meest arbeidsintensieve onderdelen van CRA-compliance. Wanneer deze architectuur het mogelijk maakt om apparaatgebonden remote-accessdiensten te verwijderen of uit te schakelen, wordt ook het blootgestelde softwareoppervlak kleiner: minder services en afhankelijkheden die moeten worden opgenomen in de technische documentatie en de SBOM-context, minder CVE’s (Common Vulnerabilities and Exposures) die gedurende de ondersteuningsperiode moeten worden beoordeeld en minder apparaatgebonden mitigerende maatregelen die moeten worden onderhouden.
Ook het verhaal richting een conformiteitsbeoordelaar wordt sterker. Wanneer een auditor vraagt hoe een apparaat de vertrouwelijkheid van gegevens tijdens transport beschermt of hoe blootstelling van externe interfaces wordt beperkt, vormt een gedocumenteerde architectuur met private APN’s een overtuigender antwoord dan uitsluitend een lijst van firmwarematige beveiligingsmaatregelen.
Waar de verantwoordelijkheid van de fabrikant blijft liggen
Noch rSIM noch een private APN is een CRA-complianceproduct. Zij genereren geen SBOM’s, voeren geen programma voor responsible vulnerability disclosure uit, verrichten geen conformiteitsbeoordelingen en nemen ook geen incidentrapportages uit handen van de fabrikant. Die verplichtingen blijven volledig bij de fabrikant liggen.
Wat deze oplossingen wél doen, is de connectiviteitslaag versterken waarop verschillende vereisten uit Bijlage I zijn gebaseerd. rSIM beperkt de risico’s van afhankelijkheid van één netwerk. Private APN’s en VPN’s verkleinen het aanvalsoppervlak van een apparaat en beschermen gegevens tijdens transport. Een fabrikant kan een apparaat alleen patchen, het gedrag ervan monitoren en voldoen aan rapportageverplichtingen wanneer het apparaat bereikbaar is – en idealiter alleen bereikbaar is onder voorwaarden die de fabrikant zelf beheerst.

Hoe de vereisten uit Bijlage I van de CRA zich verhouden tot de connectiviteitsarchitectuur, en waar de verantwoordelijkheid van de fabrikant blijft liggen.
Wat IoT-fabrikanten nu moeten doen
Er zijn vijf praktische vragen die het waard zijn om dit jaar te bespreken. Gebruik ze als uitgangspunt voor gesprekken tussen engineering-, product- en procurementteams.
CRA-gereedheidschecklist voor IoT-fabrikanten
- Welke van onze producten vallen binnen de reikwijdte van de CRA, en welke worden geclassificeerd als “belangrijk” of “kritiek”?
- Kunnen we elk uitgerold apparaat bereiken via alle netwerken waarvan we afhankelijk zijn?
- Is het risico van afhankelijkheid van één netwerk opgenomen in ons risicoregister, met voldoende zichtbaarheid voor zowel procurement als productmanagement?
- Kunnen een private APN of VPN ons blootgestelde aanvalsoppervlak verkleinen?
- Welke functionaliteit kan worden ondergebracht in de SIM- en connectiviteitslaag om de firmware zo eenvoudig mogelijk te houden?
Voor de meeste fabrikanten zal het antwoord bestaan uit een gefaseerd programma. Veranker de verwachtingen van de CRA in productspecificaties en leverancierscontracten. Gebruik de tijd tot december 2027 om de meest risicovolle onderdelen van uw IoT-omgeving structureel aan te pakken. En beschouw connectiviteitsveerkracht als een integraal onderdeel van het verhaal rond essentiële beschikbaarheid dat de CRA van fabrikanten verlangt, niet als een toevoeging die pas wordt overwogen wanneer de firmware al gereed is.
Veelgestelde vragen
Vereist de Cyber Resilience Act multi-network connectiviteit?
Nee. De CRA schrijft geen specifieke connectiviteitsarchitectuur voor. Wel verplicht de verordening fabrikanten om de beschikbaarheid van essentiële functies te waarborgen, beveiligingsupdates te leveren en te voldoen aan incidentrapportageverplichtingen gedurende de volledige ondersteuningsperiode. Al deze taken zijn aanzienlijk eenvoudiger uit te voeren én aan te tonen wanneer apparaten betrouwbaar bereikbaar zijn.
Vereist de CRA dat apparaten altijd bereikbaar blijven?
Nee. De verordening legt geen expliciete eis op voor permanente bereikbaarheid of een bepaald uptimepercentage. Wel moeten fabrikanten gedurende de ondersteuningsperiode beveiligingsupdates leveren, actief misbruikte kwetsbaarheden onderzoeken en verhelpen en voldoen aan de wettelijke rapportagetermijnen. Ook hier geldt dat deze verplichtingen aanzienlijk eenvoudiger uitvoerbaar en aantoonbaar zijn wanneer apparaten betrouwbaar bereikbaar blijven. Langdurige onbereikbaarheid kan deze verplichtingen ondermijnen, ook wanneer geen specifieke bereikbaarheidsregel wordt overtreden.
Maakt een private APN een IoT-product CRA-compliant?
Nee. Een private APN kan het blootgestelde aanvalsoppervlak van een apparaat verkleinen. In combinatie met VPN-tunneling of encryptie op applicatieniveau kan zij bovendien bijdragen aan de bescherming van gegevens tijdens transport tussen gedefinieerde eindpunten. CRA-compliance vereist echter ook secure-by-design producteigenschappen, een gedocumenteerd proces voor kwetsbaarheidsbeheer, een SBOM, conformiteitsbeoordeling en een geloofwaardige ondersteuningsverplichting. Deze verantwoordelijkheden blijven volledig bij de fabrikant liggen.
Wanneer gaan de CRA-meldingsverplichtingen in?
De meldingsverplichtingen treden in werking op 11 september 2026. Vanaf die datum moeten fabrikanten binnen 24 uur nadat zij kennis hebben genomen van een actief misbruikte kwetsbaarheid of een ernstig incident een eerste waarschuwing indienen, binnen 72 uur een uitgebreidere melding versturen en vervolgens een eindrapport indienen volgens de termijnen die zijn vastgelegd in artikel 14.
Wat moeten IoT-fabrikanten vóór december 2027 beoordelen?
Fabrikanten doen er goed aan hun productportfolio te evalueren op reikwijdte en classificatie (aan de hand van de technische beschrijvingen uit Uitvoeringsverordening (EU) 2025/2392), hun processen voor kwetsbaarheidsbeheer, ondersteuningsverplichtingen, conformiteitsroutes en de connectiviteitsarchitectuur die de updatebaarheid en beschikbaarheid van apparaten binnen de volledige IoT-omgeving ondersteunt.
De CRA stelt de deadline. Robuust ontwerp is de strategie
Voor IoT-fabrikanten betekent dit dat cybersecurity, lifecycle management en connectiviteit als één productvraagstuk moeten worden gezien, in plaats van drie afzonderlijke werkstromen.
Een apparaat dat secure-by-design is maar onbereikbaar in het veld, of onnodig blootgesteld wordt aan het publieke internet, kan het vermogen van de fabrikant ondermijnen om lifecycle security en beschikbaarheid onder de verordening aan te tonen. CSL’s veerkrachtige SIM-technologie vermindert een veelvoorkomend single-network- of single-core faalmechanisme, terwijl managed private APN- en VPN-connectiviteit het aanvalsoppervlak dat een apparaat vanaf dag één blootstelt verkleint. In veel implementaties kunnen beide zonder hardwareherontwerp en met minimale aanpassingen aan de device-side worden toegevoegd, waardoor fabrikanten hun CRA-inspanningen kunnen richten op waar die echt moeten landen: secure development, vulnerability handling en een geloofwaardige supportverplichting richting klanten die afhankelijk zijn van het product.
Uw CRA-roadmap plannen?
CSL bouwt al meer dan drie decennia aan veerkrachtige connectiviteit voor life-, mission- en business-critical IoT. We ondersteunen meer dan 3,5 miljoen actieve kritieke verbindingen in het VK, Europa en daarbuiten, en opereren met cyber-credentials waaronder Cyber Essentials Plus, ISO27001 en een vulnerability disclosure policy.
Als u de CRA-implicaties voor cellulaire IoT-producten aan het uitwerken bent, kunnen we samen bekijken waar rSIM, private APN/VPN en managed connectivity praktisch passen — zonder dat een hardwareherontwerp nodig is.
Bronnen en verdere lectuur
- Verordening (EU) 2024/2847 (de Cyber Resilience Act), volledige tekst op EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/2847/oj
- Uitvoeringsverordening (EU) 2025/2392 van de Commissie over de technische beschrijving van belangrijke en kritieke productcategorieën: https://eur-lex.europa.eu/eli/reg_impl/2025/2392/oj
- Gedelegeerde Verordening (EU) 2026/881 van de Commissie over de cyberbeveiligingsgerelateerde gronden voor het uitstellen van de verspreiding van meldingen: https://eur-lex.europa.eu/eli/reg_del/2026/881/oj
- Europese Commissie, overzicht Cyber Resilience Act: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
- Europese Commissie, CRA-implementatietijdlijn en resources (inclusief CRA FAQ en conceptguidance voor mkb): https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation
- Europese Commissie, CRA conformiteitsbeoordeling: https://digital-strategy.ec.europa.eu/en/policies/cra-conformity-assessment
- Europese Commissie, CRA rapportageverplichtingen: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
- ENISA, Cyber Resilience Act resources: https://www.enisa.europa.eu/topics/product-security-and-certification/cyber-resilience-act
- ENISA, Single Reporting Platform (SRP): https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp
- CSL rSIM productpagina: https://www.csl-group.com/nl/oplossingen/rsim/