CRA voor startups: lean compliant met één engineer

U brengt met een klein team een verbonden product op de markt, en de CRA raakt u. De hoofdverplichtingen gelden vanaf 11 december 2027, kwetsbaarheidsmelding al vanaf 11 september 2026. Dit is dus iets om nu in te bouwen, niet iets voor later. Twee dingen vangen startups: de meerjarige beveiligingsondersteuningsplicht die u op zich neemt zodra u het product op de EU-markt plaatst, en dat u dit alles doet zonder toegewijde beveiligingsmedewerker.

Deze gids is voor oprichters en engineers in een vroege fase die CRA-compliant moeten worden zonder te veel uit te geven of te veel te bouwen. De gids behandelt wat u veilig kunt overslaan, wat niet, en hoe één persoon het geheel kan dragen.

Valt uw startup onder de CRA?

Doorloop vier korte controles. De CRA geldt voor producten met digitale elementen die verbinding maken met een netwerk of een ander apparaat, en die in het kader van een commerciële activiteit op de EU-markt beschikbaar worden gesteld.

Valt uw product binnen het toepassingsgebied, dan is de volgende vraag in welke categorie het terechtkomt. Dat bepaalt of u zelf beoordeelt of een aangemelde instantie nodig heeft. Bevestig dit met de gids productclassificatie voordat u ook maar een dag aan iets anders besteedt.

Uw ene structurele voordeel: zelfbeoordeling

De grootste kostenbesparing voor een startup is dat een product buiten de categorieën Belangrijk en Kritiek een Standaardproduct is. Voor die producten laat de CRA u zelf beoordelen: u doet het conformiteitswerk zelf, ondertekent de EU-conformiteitsverklaring en brengt de CE-markering aan. Geen externe instantie, geen kosten per product. De werking van elke route staat in de gids conformiteitsbeoordeling. Het punt voor een startup is simpel: betaal niet voor een beoordeling door derden die u niet nodig heeft.

Belangrijk: zelfbeoordeling is geen lichtere compliance. U voldoet nog steeds aan dezelfde essentiële vereisten. U verklaart dit alleen zelf, in plaats van er iemand voor te betalen.

De verlichtingen die de CRA voor startups biedt

De CRA bevat ondersteunende maatregelen die specifiek zijn geschreven voor micro-ondernemingen, kleine en middelgrote ondernemingen, en startups. Of de verlichtingen voor u gelden, hangt af van uw omvang volgens de standaard EU-definitie: een micro-onderneming heeft minder dan 10 medewerkers en een omzet of balanstotaal van ten hoogste EUR 2 miljoen, en een kleine onderneming heeft minder dan 50 medewerkers en een omzet of balanstotaal van ten hoogste EUR 10 miljoen.

Vier verlichtingen die een startup daadwerkelijk kan gebruiken:

• Vereenvoudigde documentatie: micro-ondernemingen en kleine ondernemingen mogen de technische documentatie indienen in een vereenvoudigd formaat dat de Commissie vaststelt, en aangemelde instanties moeten die vorm accepteren.
• Verlaagde conformiteitskosten: heeft uw product wel een aangemelde instantie nodig, dan moet rekening worden gehouden met de specifieke behoeften van mkb-bedrijven, inclusief startups, en moeten de kosten proportioneel worden verlaagd.
• Regelgevende sandboxes: lidstaten mogen gecontroleerde omgevingen opzetten waarin u een innovatief product ontwikkelt en test tegen de CRA voordat u het op de markt plaatst, met vergemakkelijkte toegang voor startups.
• Directe ondersteuning: waar passend organiseren lidstaten bewustwordings- en trainingsactiviteiten en een apart adviesloket voor kleinere bedrijven, en wijst de Commissie de weg naar beschikbare financiële steun.

Compliant worden met één engineer

U heeft geen beveiligingsteam nodig. U heeft één verantwoordelijke eigenaar nodig en een korte lijst dingen die automatisch draaien. Die persoon onderhoudt het technisch dossier, beoordeelt binnenkomende kwetsbaarheidsmeldingen en ondertekent de conformiteitsverklaring. Eén persoon kan die rol vervullen, maar wees eerlijk: de doorlopende kwetsbaarheidsafhandeling, updatelevering en documentatie zijn echt engineeringwerk. De gids CRA-compliancekosten modelleert de inspanning en het budget voor een klein team, zodat u de bezetting goed kunt plannen.

Drie dingen zijn het eerst de moeite waard om te automatiseren. Elk is een opgelost probleem met gratis tooling, en samen dekken ze uw zichtbaarste vroege verplichtingen af. Ze zijn een startpunt, niet het hele plaatje.

• Genereer een SBOM in CI: de CRA vereist een software bill of materials die ten minste uw directe afhankelijkheden dekt, en open-source tools zoals Syft en Trivy genereren er een bij elke build. De volledige toolchain staat in de SBOM-generatiegids.
• Monitor op kwetsbaarheden: scan uw afhankelijkheden bij elke build en handel bevindingen af op basis van risico voordat ze klanten bereiken. De CRA kijkt of u beoordeelt en oplost, niet welke scanner u gebruikt.
• Publiceer een beveiligingscontact: een security.txt-bestand en een werkend beveiligingsadres geven onderzoekers een manier om te melden. De security.txt-instructiegids bevat een kant-en-klare template.

Die drie zijn vroege automatiseringswinsten, niet de hele klus. Secure design, risicobeoordeling, updatelevering en de productcontroles staan ernaast. Uw technische documentatie groeit mee met het product in plaats van in een haastklus vlak voor de lancering, dus houd architectuur- en beveiligingsnotities bij terwijl u bouwt. De vereiste inhoud staat in de gids technische documentatie.

Uw proces voor kwetsbaarheidsafhandeling moet actief zijn voordat de meldingsverplichtingen ingaan op 11 september 2026. Vanaf die datum start een actief misbruikte kwetsbaarheid of een ernstig incident een strak tijdschema via het ENISA-single-reporting-platform: een vroege waarschuwing binnen 24 uur, gevolgd door een vollediger melding binnen 72 uur. Het eindrapport verschilt per traject. Voor een actief misbruikte kwetsbaarheid is dat verschuldigd binnen 14 dagen nadat een corrigerende of mitigerende maatregel beschikbaar is. Voor een ernstig incident is dat verschuldigd binnen één maand na de melding van 72 uur. U moet ook getroffen gebruikers informeren. De werking staat in de gids kwetsbaarheidsmelding.

U kunt snel shippen zonder elke release opnieuw te certificeren

Snel itereren betekent niet dat u elke sprint opnieuw een conformiteitsbeoordeling doorloopt. U herziet de conformiteit alleen na een ingrijpende wijziging: een wijziging na lancering die de naleving van de essentiële vereisten raakt, of het beoogde gebruik verandert waarvoor het product beoordeeld is. Een beveiligingsupdate die alleen het cybersecurityrisico verlaagt zonder het beoogde gebruik te veranderen, is geen ingrijpende wijziging, en een kleine wijziging zoals het toevoegen van een UI-taal is dat over het algemeen ook niet. Een functie-update die het aanvalsoppervlak vergroot of verandert wat het product doet, kan dat wel zijn. Routinematige patches en kleine updates gaan dus zonder herbeoordeling de deur uit, en u herbeoordeelt wanneer een wijziging echt verandert wat het product is of hoe hoog het risicoprofiel ligt.

Als u bouwt op of beheerder bent van open source

Twee open-sourcefeiten zijn relevant voor een startup. Ten eerste: gratis en opensourcesoftware valt alleen binnen het toepassingsgebied wanneer die wordt geleverd in het kader van een commerciële activiteit. Software die de onderhouders niet monetariseren is doorgaans geen commerciële activiteit, maar monetarisering is breder dan geld vragen voor de code, dus weeg betaalde ondersteuning en vergelijkbare constructies mee. Bijdragen leveren van broncode aan een project dat niet onder uw verantwoordelijkheid valt, maakt de CRA niet op u van toepassing. Open source monetariseren, of het uitleveren binnen een product dat u verkoopt, brengt dat product gewoon binnen het toepassingsgebied.

Ten tweede creëert de CRA een lichtere rol genaamd beheerder van opensourcesoftware (open-source software steward), voor een organisatie, anders dan een fabrikant, die de ontwikkeling ondersteunt van opensourcesoftware bedoeld voor commercieel gebruik. De verplichtingen van een beheerder draaien vooral om een gedocumenteerd cybersecuritybeleid en samenwerking met autoriteiten. Kwetsbaarheidsmelding geldt voor zover de beheerder betrokken is bij de ontwikkeling van het product, en melding van ernstige incidenten en gebruikersnotificatie gelden wanneer een incident de systemen raakt die de beheerder voor die ontwikkeling levert. Deze verplichtingen zijn lichter dan de volledige set fabrikantverplichtingen. Beheert uw startup zowel een project als dat u een product verkoopt, wees dan duidelijk welke pet u op heeft bij welke activiteit, want de verplichtingen verschillen.

De vijfjarige ondersteuningsplicht is een bedrijfsmodelprobleem

Dit is het onderdeel van de CRA waar een startup niet met tooling omheen kan. De ondersteuningsperiode moet minstens vijf jaar zijn, en wanneer het product naar verwachting korter dan vijf jaar in gebruik zal zijn, sluit de periode aan bij die kortere verwachte gebruiksduur. Gedurende die periode handelt u kwetsbaarheden af op basis van risico, verhelpt u ze zonder onnodige vertraging en levert u de updates aan klanten.

Voor een bedrijf in een vroege fase is dat een echte verplichting, geen afvinkpunt:

• De plicht volgt het product: die ontstaat zodra u het product voor het eerst op de EU-markt plaatst, en een latere pivot beëindigt de plicht niet voor eenheden die al geplaatst zijn.
• De kosten moeten worden doorberekend: draagt uw marge de ondersteuningsperiode niet, dan klopt de prijs niet. Neem de ondersteuningskosten mee in uw unit economics voordat u lanceert, en verwacht dat ze afnemen naarmate de codebase stabiliseert.
• Plan voor tien jaar, niet vijf: elke beveiligingsupdate die u uitbrengt, moet minstens 10 jaar na release beschikbaar blijven, of voor de rest van de ondersteuningsperiode als die langer duurt.
• Publiceer de einddatum: u moet de einddatum van de ondersteuningsperiode, minstens de maand en het jaar, tonen op het moment van aankoop. Stel deze bewust vast, want klanten en kopers lezen hem.

U kunt de verplichting beter behapbaar maken, maar let op wat de plicht daadwerkelijk wel en niet opheft:

• Kies stabiele afhankelijkheden: elke snel veranderende library die u binnenhaalt, is jaren onderhoud waar u zich voor heeft aangemeld. Geef de voorkeur aan saaie, goed ondersteunde componenten.
• Versioneer bewust: definieer productgeneraties en plan hoe ondersteuning tussen generaties wordt overgedragen, zodat u niet een onbeperkte reeks live versies onderhoudt.
• Mitigaties heffen de plicht niet op: een schriftelijke overdracht van de ondersteuning aan een overnemende partij, een escrow-regeling of het open source maken van de beveiligingskritische componenten kan fixes laten doorstromen, maar geen van deze opties heft op zichzelf uw verplichting op.

Staakt u de activiteiten en kunt u niet langer voldoen, dan moet u de markttoezichtautoriteiten en, voor zover mogelijk, uw gebruikers informeren voordat de beëindiging ingaat. Wat er met de resterende plicht gebeurt zodra het bedrijf niet meer bestaat, is niet eenduidig geregeld en hangt af van de jurisdictie. Plan het afbouwpad nu, terwijl dat nog kan, en leg het vast in het technisch dossier.

Maak van compliance een verkoop- en financieringstroef

Voor een startup kan CRA-werk dubbel dienstdoen: het opent EU-markttoegang, en het levert bewijs op dat u aan een enterprise-koper of investeerder kunt overhandigen.

Stel het due-diligencepakket één keer samen. EU-inkoopteams kunnen tijdens leveranciersonboarding vragen om een actuele SBOM, een ondertekende conformiteitsverklaring en een gedocumenteerd proces voor kwetsbaarheidsopenbaarmaking met een reactietermijn. Dit is sterk bewijs, geen bewijs van volledige compliance, want gereedheid rust uiteindelijk op het voldoen aan elke essentiële vereiste. Maar met alles op één plek verzameld, hoeft u later niet te hollen om het bewijs bij elkaar te zoeken, en het is hetzelfde pakket waar de technische due diligence van een investeerder mogelijk om vraagt.

Investeerders willen weten dat u legaal kunt leveren. Het schenden van de essentiële vereisten of de kernverplichtingen van de fabrikant leidt tot bestuurlijke boetes tot EUR 15 miljoen of 2,5% van de totale wereldwijde jaaromzet, welk bedrag hoger is. Praktischer: een product dat vanaf 11 december 2027 op de EU-markt wordt geplaatst, moet aan de CRA voldoen om daar verkocht te mogen worden. Compliance presenteren als markttoegang en een EU-intrede met minder risico's landt beter bij een raad van bestuur dan wanneer u het als kostenpost framet.

Publieke programma's kunnen een deel van het werk financieren. EU-instrumenten zoals Horizon Europe, het Digital Europe Programme en de EIC Accelerator ondersteunen cybersecurity en de ontwikkeling van veilige producten, en nationale programma's voegen daar meer aan toe. Bedragen en voorwaarden verschillen, dus check bij uw nationale digital innovation hub wat er openstaat. Formuleer de aanvraag rond het bouwen van betrouwbare, veilige digitale producten, niet rond het afvinken van een regelgevend vakje.

Komen beveiligingscertificeringen ter sprake in de verkoop, weet dan waar de CRA zich toe verhoudt. De overlap met een ISMS staat in de gids CRA versus ISO 27001, en teams die met consumenten-IoT werken lezen het best de gids EN 303 645.

Veelgemaakte startupfouten

• "Beveiliging pakken we na de funding aan": op een beperkte runway verbrandt het achteraf inbouwen van beveiliging het geld dat u net heeft opgehaald. Bouw de basis vanaf de eerste sprint in.
• "We hebben het product geprijsd zonder de ondersteuningsplicht": meerjarig beveiligingsonderhoud hoort in uw unit economics te zitten. Zit het er niet in, dan klopt de prijs niet.
• "Onze compliance-eigenaar is vertrokken en niemand heeft het overgenomen": houdt één persoon het technisch dossier en het meldingsproces bij, dan is diens vertrek een compliancegat. Leg schriftelijk vast wie de eigenaar is.
• "De overnemende partij neemt de plicht wel over": een deal kan het ondersteuningswerk toewijzen, maar dat heft op zichzelf niet de wettelijke plicht bij u op. Regel dit expliciet in de voorwaarden, en neem niets aan.
• "CRA plakken we er wel bij zodra we naar de EU uitbreiden": kunnen EU-gebruikers uw product al bereiken, dan levert u al aan de EU-markt, en compliance er later bij bouwen is een herbouw. Ontwerp vanaf het begin voor de verplichtingen van 2027.
• "We zijn te vroeg in onze fase om binnen het toepassingsgebied te vallen": als startup krijgt u verlichtingen, geen vrijstelling. De plicht ontstaat bij de eerste plaatsing, ongeacht uw fase.