De Cyber Resilience Act eist dat producten worden ontworpen, ontwikkeld en geproduceerd met een passend niveau van cybersecurity, en dat ze met een veilige standaardconfiguratie worden geleverd. Hoe, dat staat er niet. In juli 2026 publiceerde ENISA, het Agentschap van de EU voor cyberbeveiliging, het Secure by Design and Default Playbook om dat gat voor een deel te dichten voor kleine en middelgrote fabrikanten.
Het is een van de meest praktische documenten die tot nu toe rond de CRA zijn verschenen. Dit artikel vat samen wat erin staat en hoe u het gebruikt.
Wat het is, en wat niet
Het playbook is versie 1.0, gepubliceerd na een openbare consultatie in april en mei 2026 die 28 bijdragen opleverde van fabrikanten, practitioners en de opensourcecommunity. Het is gratis en valt onder de licentie CC BY 4.0.
De doelgroep is het mkb dat producten met digitale elementen bouwt: embedded software, IoT-apparaten, verbonden systemen, losse software en hardware met programmeerbare componenten. Het is geschreven voor de mensen die het werk doen: ontwikkelaars, technische productmanagers, architecten en de securitylead die vaak ook nog een paar andere petten draagt.
ENISA is duidelijk over de grenzen. Het playbook is geen juridisch advies en geen compliancehandboek. Wie het volgt, maakt een product daarmee niet automatisch CRA-compliant of certificeerbaar tegen een norm. Het is een praktisch vertrekpunt dat principes vertaalt naar herhaalbare engineeringacties, en een bijlage koppelt die principes aan de essentiële eisen van de CRA.
Hoe het is opgebouwd
Het document heeft vijf delen:
- Secure by design en default over de hele levenscyclus van het product, inclusief licht risicomanagement en threat modeling.
- De principes van secure by design en secure by default.
- Eén playbook per principe, 22 in totaal. Dit is de kern van het document.
- Machineleesbare attestatie: hoe u beveiligingsclaims en bewijs vastlegt in een formaat dat tools kunnen verifiëren.
- Bijlagen met de essentiële eisen van de CRA en de koppeling van elk principe daaraan.
Levenscyclus en risicomanagement, licht gehouden
Het playbook volgt een product door zes levenscyclusprocessen: eisen, ontwerp, implementatie, verificatie, uitrol, en onderhoud en buitengebruikstelling. Voor elk proces noemt het acties en een concreet resultaat, en die resultaten zijn bewust klein: een securitycontext van één pagina, één architectuurdiagram met trust boundaries, een korte checklist met eisen, een security-checklist voor releases, een proces van één pagina voor kwetsbaarheden en patches.
Voor het mkb lopen er drie regels doorheen:
- Gebruik kleine, herbruikbare artefacten: notities van één pagina, eenvoudige diagrammen, checklists.
- Geef de voorkeur aan geautomatiseerde controles in CI/CD boven handmatige reviews, en bewaar diepe reviews voor wijzigingen met een hoog risico.
- Voeg snelle security gates toe aan de rituelen die u al hebt, zoals de definition of done, controles op pull requests en de release-checklist.
Risicomanagement krijgt dezelfde behandeling. In plaats van een formeel framework stelt het playbook een korte reeks activiteiten voor: een productsecuritycontext van een of twee pagina’s, een lijst met belangrijke assets en ongewenste gevolgen, een levend risicoregister van 10 tot 30 risico’s, een beleid van één pagina voor het accepteren van risico’s, een risicoreview vóór de release, en een herbeoordeling als er iets wezenlijks verandert. Het acceptatiebeleid bevat harde grenzen, zoals nooit misbruik van het updatemechanisme, ongeautoriseerde beheerderstoegang of uitbuitbare standaardwachtwoorden accepteren.
Threat modeling voor teams zonder threat modeling-expert
Threat modeling staat centraal in de aanpak. Het playbook organiseert het rond de vier vragen van Shostack:
- Waar werken we aan?
- Wat kan er misgaan?
- Wat gaan we eraan doen?
- Hebben we het goed genoeg gedaan?
Voor de meeste mkb-producten is het doel een “minimum viable model”: één diagram met trust boundaries en geprivilegieerde paden, de belangrijkste 5 tot 10 dreigingsscenario’s met een prioriteit, per scenario een mitigatie en een veilige standaard, per maatregel een verificatiemethode, en vastgelegde triggers voor wanneer het model moet worden bijgewerkt, zoals een nieuwe interface naar internet of een gewijzigd authenticatiemodel. STRIDE wordt aangeboden als één manier om dreigingen te vinden, niet als de enige.
Twee punten die ik zou onderstrepen. ENISA zegt dat licht threat modeling geen threat modeling-specialisten vereist, maar wel mensen die het product goed kennen. En het benoemt de valkuilen: threat modeling als eenmalige compliance-oefening behandelen, modellen bouwen die geen enkele ontwerpbeslissing beïnvloeden, en ze nooit bijwerken. Voor producten met AI-componenten vraagt het teams rekening te houden met AI-specifieke aanvallen zoals prompt injection en model poisoning.
22 principes in vier groepen
De principes zijn verdeeld over secure by design (hoe het product wordt gebouwd) en secure by default (hoe het aankomt en zich gedraagt als de gebruiker het voor het eerst aanzet), elk met twee groepen:
| Groep | Principes |
|---|---|
| Secure by design: architectonische fundamenten | Trust boundaries en threat modeling; least privilege; sterke architectuur voor identiteit en authenticatie; minimalisering van het aanvalsoppervlak; defence in depth; open design |
| Secure by design: operationele integriteit | Levenscyclusbeheer; gebruikersgericht ontwerp; secure coding en verificatie; logging, monitoring en alerting; configuratie- en wijzigingsbeheer; incident response en herstel; kwetsbaarheids- en patchbeheer; maatregelen in de toeleveringsketen |
| Secure by default: standaardhardening | Minimale standaarddiensten; beperkende initiële toegang; standaard veilige communicatie; standaard unieke apparaatidentiteit en secrets |
| Secure by default: begeleide bescherming | Verplichte security-onboarding; geautomatiseerd onderhoud en updates; transparante securitystatus; veilige levenscyclus voor herstel en eigendom |
De meeste hiervan zijn bekend voor iedereen die in applicatiebeveiliging heeft gewerkt. Bij secure by default schieten veel producten in de praktijk nog tekort: geen gedeelde admin/admin-wachtwoorden, unieke sleutels per apparaat, versleuteling vanaf de eerste verbinding, automatische beveiligingsupdates die standaard aanstaan, een installatiewizard die de belangrijke beveiligingskeuzes afdwingt, en een duidelijke waarschuwing met een terugweg in één klik als een gebruiker de configuratie verzwakt.
De playbooks: checklist, bewijs, release gate
Elk van de 22 playbooks past op ongeveer één pagina en gebruikt dezelfde vijf koppen:
- het principe dat wordt toegepast
- het doel, inclusief de fouten die het voorkomt
- een checklist met de acties met de meeste impact voor een klein team
- het minimale bewijs dat laat zien dat de checklist is toegepast
- een release gate: criteria voor slagen of zakken die u in een releasereview of CI/CD-pipeline kunt overnemen
Het playbook voor kwetsbaarheids- en patchbeheer laat zien hoe concreet dit wordt. De checklist behandelt meldkanalen met één eigenaar, triage met de vlaggen “bereikbaar vanaf internet” en “bekend uitgebuit”, een vast ritme voor het bijwerken van dependencies, kennis van de meldtermijnen, en het publiceren van machineleesbare advisories met CSAF en VEX waar dat in verhouding staat. Het minimale bewijs omvat een kwetsbaarhedenregister, vastgestelde SLA’s, scanresultaten uit CI, een SBOM per release en een uitzonderingslogboek met eigenaren en vervaldatums. De release gate controleert vervolgens onder meer dat kritieke en hoge bevindingen zijn opgelost of een vastgelegde, tijdgebonden uitzondering hebben, en dat de SBOM voor de release bestaat.
Het hoofdstuk over bewijs is het waardevolste deel voor de voorbereiding op de CRA. ENISA benadrukt dat bewijs geen aparte documenten nodig heeft: één SBOM, scanresultaat of releaseverslag kan meerdere playbooks dienen, en bestaande engineeringgegevens zoals diagrammen, tickets, testresultaten en CI-output moeten worden hergebruikt. Precies die houding voorkomt dat technische documentatie een apart project wordt.
Waar u begint
De playbooks hoeven niet allemaal tegelijk te worden ingevoerd. De voorgestelde volgorde:
- Breng context en prioriteiten in kaart met de activiteiten voor risicomanagement en threat modeling en het playbook voor trust boundaries.
- Bouw een technische basis: secure coding en verificatie, logging en monitoring, kwetsbaarheids- en patchbeheer, en maatregelen in de toeleveringsketen. Voeg de secure-by-default-playbooks toe die op uw product van toepassing zijn: beperkende initiële toegang als het gebruikers- of beheerderstoegang heeft, veilige communicatie als het via een netwerk communiceert, unieke identiteiten en secrets als het inloggegevens gebruikt, en geautomatiseerde updates als het kan worden bijgewerkt.
- Verbreed en versterk de rest in de loop van de tijd, met meer dekking, consistentie en automatisering.
ENISA voegt een belangrijke kanttekening toe: geleidelijke invoering betekent niet dat u iets uitstelt wat de CRA vereist. De volgorde gaat over het verdelen van de inspanning, niet over deadlines.
Machineleesbare attestatie
Het meest vooruitstrevende deel van het playbook gaat over bewijs dat machines kunnen lezen. In plaats van pdf-rapporten publiceert een fabrikant gestructureerde beveiligingsclaims, bijvoorbeeld in JSON, gekoppeld aan het bewijs erachter en aan de verificatieresultaten. Het illustratieve voorbeeld, een fabriekspoortcontroller met de naam SafeGate-X1, gebruikt drie lagen:
- een controlelaag met de beveiligingsdoelen, zoals bescherming tegen ongeautoriseerde toegang
- een implementatielaag met de claims over hoe elk doel wordt gehaald en de tools, versies en configuraties die daarbij horen
- een beoordelings- en verificatielaag die verwijst naar testresultaten, SAST-samenvattingen en hashes van buildartefacten
Het playbook stelt geen nieuw formaat voor. Het wijst naar bestaand werk: OSCAL van NIST, CycloneDX-attestaties (CDXA), het securityprofiel van SPDX 3.0, OpenSSF Security Insights en Scorecard, SLSA-provenance met in-toto en Sigstore, en de Transparency Exchange API van Ecma TC54. Het stelt ook voor om publieke, ondertekende claims te scheiden van een afgeschermde technische laag die alleen bevoegde partijen kunnen inzien.
Ook hier is ENISA voorzichtig: een attestatie van de fabrikant is geen bewijs dat een product veilig is. Attestatie, verificatie en onafhankelijke beoordeling zijn verschillende activiteiten. Toch is de richting duidelijk. Technische documentatie die uit de pipeline wordt gegenereerd, blijft actueel, en een build die zijn bewijs niet kan leveren, kan automatisch worden gestopt.
De koppeling met de CRA
Bijlage C koppelt elk principe aan de essentiële eisen in bijlage I van de CRA. Trust boundaries en threat modeling ondersteunen bijvoorbeeld de risicobeoordeling, bescherming tegen ongeautoriseerde toegang, vertrouwelijkheid en integriteit, en het beperken van het aanvalsoppervlak. Kwetsbaarheids- en patchbeheer hoort bij het identificeren en documenteren van componenten en bij het zonder vertraging verhelpen van kwetsbaarheden.
De koppeling is indicatief en geeft geen vermoeden van conformiteit. Dat komt van geharmoniseerde normen zodra die in het Publicatieblad zijn vermeld; ons overzicht van de geharmoniseerde CRA-normen laat zien hoe ver ze zijn. Maar het is een handige manier om te controleren of uw veilige ontwikkelpraktijken elke essentiële eis dekken, en om het bewijs te vinden dat u nodig hebt voor de technische documentatie.
Hoe het aansluit op OWASP SAMM
Het playbook noemt OWASP SAMM als een manier om securityactiviteiten over de levenscyclus te organiseren en volwassener te maken, en de practices threat assessment en security requirements als voorbeeld van het vertalen van dreigingen naar testbare eisen. De twee vullen elkaar goed aan. SAMM vertelt u hoe volwassen elke practice is en hoe de volgende stap eruitziet; het playbook geeft u concrete checklists, bewijs en release gates voor afzonderlijke principes. Onze artikelen over de keuze tussen SAMM en BSIMM en over SAMM-metrics behandelen de kant van volwassenheid.
Onze kijk
Voor een mkb-bedrijf dat zich voorbereidt op de CRA is dit het document dat ik als eerste aan de engineeringlead zou geven. Het is kort waar het kan, concreet waar het ertoe doet, en het behandelt bewijs als bijproduct van gewoon engineeringwerk in plaats van als aparte compliance-inspanning. Vooral de release gates kunnen direct in een definition of done of een CI-pipeline.
Twee dingen om in gedachten te houden. Het is een introductie, geen complete methode: producten voor kritiek of risicovol gebruik hebben meer diepgang nodig dan de minimale versies die hier staan. En het vervangt niet de risicobeoordeling die de CRA per product vereist; het helpt u die uit te voeren.
Wilt u hulp bij het toepassen van de playbooks? Onze threat modeling-training behandelt de activiteiten in de ontwerpfase, ons SSDLC Maturity Assessment laat zien waar uw ontwikkelproces nu staat, en werkpakket 6 van de EU CRA Compliance Journey brengt secure by design en by default in de praktijk.