ENISA's Secure by Design Playbook: wat het betekent voor productteams onder de CRA

Samenvatting

• ENISA heeft een Security by Design and Default Playbook gepubliceerd (v0.4, maart 2026), de eerste officiële EU-richtlijn die CRA-beveiligingsvereisten vertaalt naar praktische engineering-checklists voor kmo's
• Behandelt de volledige productlevenscyclus: van requirements tot buitengebruikstelling
• Definieert 22 beveiligingsprincipes georganiseerd in Secure by Design (14) en Secure by Default (8)
• Elk principe heeft een éénpagina-playbook met checklist, minimaal bewijsmateriaal en release gate-criteria
• Bevat 8 risicobeheeractiviteiten en een 5-stappen threat modelling-proces ontworpen voor lean teams
• Introduceert Machine-Readable Security Manifests (MRSM), een nieuw concept voor verifieerbaar, machineleesbaar compliance-bewijs
• Koppelt alle 22 principes aan CRA Bijlage I essentiële vereisten (Bijlage C)
• Momenteel een conceptversie open voor publieke consultatie

Wat is de ENISA Secure by Design Playbook?

Op 19 maart 2026 publiceerde het Europees Agentschap voor Cyberbeveiliging (ENISA) de Security by Design and Default Playbook, versie 0.4, uitgebracht als concept voor publieke consultatie.

Het is de eerste officiële EU-richtlijn die CRA-beveiligingsvereisten vertaalt naar concrete engineering-checklists gericht op kmo's. Het document is geen juridisch advies. Het biedt praktische, technisch onderbouwde benaderingen die productteams kunnen toepassen tijdens de ontwerp-, bouw- en implementatiefasen.

De playbook richt zich op kmo's (gedefinieerd als organisaties met minder dan 250 werknemers en een jaarlijkse omzet onder EUR 50 miljoen) die producten met digitale elementen vervaardigen. Dit omvat embedded software, IoT-apparaten, verbonden systemen, standalone software en hardware met programmeerbare componenten.

ENISA heeft de playbook ontwikkeld op basis van een analyse van bestaande beveiligingsraamwerken gepubliceerd door ENISA en andere EU-gebaseerde cyberbeveiligingsagentschappen, evenals richtlijnen van NIST en OWASP. Gemeenschappelijke vereisten en implementatiepatronen werden geïdentificeerd en geëvalueerd aan de hand van kmo-capaciteiten om haalbaarheid en aanpassingsvereisten te bepalen.

Bijlage C van de playbook koppelt alle 22 principes rechtstreeks aan CRA Bijlage I essentiële vereisten, wat een traceerbare koppeling biedt tussen engineeringpraktijken en regelgevende verplichtingen.

Belangrijk: Dit is een concept voor publieke consultatie (v0.4). ENISA zoekt actief feedback. De definitieve versie kan afwijken.

Voor wie is deze playbook bedoeld?

De playbook identificeert vier primaire groepen (Sectie 1.3):

• Software Developers en Engineers: mensen die code schrijven en praktische manieren nodig hebben om beveiliging in te bouwen zonder de doorlooptijd te vertragen
• Technische Productmanagers: mensen die featurewerk afwegen tegen beveiligingsvereisten en beiden willen laten passen
• Beveiligingsverantwoordelijken bij kmo's: mensen die enterprise-grade raamwerken vertalen naar iets dat werkt met beperkte budgetten en kleine teams
• Systeemarchitecten: mensen die systemen ontwerpen en beveiliging van meet af aan willen inbouwen, niet achteraf toevoegen

De gemeenschappelijke uitdaging die ENISA erkent: de meeste kmo's hebben geen toegewijd beveiligingsteam, een beperkt budget voor beveiligingstools en beveiligingswerk dat voortdurend concurreert met feature-delivery.

De reactie van de playbook: gestructureerde checklists die teams helpen quick-win-beveiligingscontroles te identificeren, deze op een realistische manier te implementeren en een herhaalbare baseline op te bouwen die ze in de loop van de tijd kunnen verbeteren.

Beveiliging over de productlevenscyclus

Beveiliging moet end-to-end worden overwogen, ongeacht het gebruikte productiemodel (V-model, Agile of anders). De playbook definieert zes fasen, elk met specifieke beveiligingsacties en concrete deliverables.

Kernprincipes uit het document:

• Gebruik kleine, herbruikbare artefacten (éénpagina-contextnotities, eenvoudige diagrammen, checklists)
• Geef de voorkeur aan geautomatiseerde controles in CI/CD boven handmatige reviews, en reserveer grondige review voor wijzigingen met een hoog risico
• Introduceer snelle security gates afgestemd op bestaande agile ceremonies (Definition of Ready/Done, PR-checks, release-checklist)

Elke fase levert een concrete deliverable op. Dit is geen abstracte richtlijn.

Welke risicobeheeractiviteiten raadt ENISA aan?

Risicobeheeractiviteiten vormen de basis voor alle Secure by Design- en Default-beslissingen. De playbook stelt geen zwaarwichtig formeel raamwerk voor. In plaats daarvan definieert het een minimale set activiteiten die beveiligingsbeslissingen kunnen ondersteunen zonder zware processen te creëren (Sectie 2.2).

Het document definieert 8 activiteiten (Tabel 2):

1. Productcontext en scope: Definieer beoogd gebruik, implementatieomgevingen, gebruikers-/beheerdersrollen, datatypes/gevoeligheid en belangrijkste externe afhankelijkheden. Deliverable: 1-2 pagina "Product Security Context"-notitie (scope, aannames, afhankelijkheden).
2. Asset- en schade-identificatie: Lijst top-data, hardware of functie-assets op (inloggegevens, klantdata, persoonsgegevens, apparaatbeheer) en de belangrijkste schadegevolgen (privacyschending, overname, uitval, fraude, veiligheidsimpact). Deliverable: Activalijst + "Topschade"-lijst (één pagina).
3. Lichtgewicht threat modelling: Zie de sectie over threat modelling hieronder.
4. Risicoregister: Leg 10-30 risico's vast met waarschijnlijkheid/impact (eenvoudige schaal), eigenaar, behandeling, status. Koppel hoge risico's aan backlog-items/controles. Deliverable: Levend risicoregister (spreadsheet of ticketbord).
5. Risicoaanvaardingscriteria: Definieer een reeks niet-onderhandelbare risicovoorwaarden. Misbruik van software-updates, ongeautoriseerde beheerderstoegang of misbruik van standaardinloggegevens is bijvoorbeeld NIET acceptabel. Stel criteria vast voor het aanvaarden van restrisico's die essentiële cyberbeveiligingsvereisten niet mogen ondermijnen. Deliverable: 1-pagina Risicoaanvaarding- en uitzonderingenbeleid.
6. Beveiligingsvereisten-baseline: Vertaal toprisico's naar testbare "moet"-vereisten (authn/authz, veilige standaarden, geheimen, encryptie, logging, updates). Deliverable: Kmo-beveiligingsvereisten-checklist (testbare controles).
7. Release-risicoreview gate: Formele pre-release gate: bevestig dat checklist voldaan is, standaarden geverifieerd, bekende kwetsbaarheden getriageerd, hoge risico's behandeld/aanvaard met motivatie. Besluit go/no-go. Deliverable: Release-beveiligingsreviewrecord + gedocumenteerde uitzonderingen.
8. Wijzigingsgestuurde heroverweging: Hervoer context/bedreiging/risico-stappen bij grote wijzigingen (architectuur, auth-model, kritieke afhankelijkheid/leverancier, implementatieomgeving, na incidenten). Deliverable: Bijgewerkte contextnotitie, verkorte bedreigingslijst en risicoregisterinvoer (met datum).

Opmerking: Risicobeheer is iteratief, niet eenmalig. De playbook specificeert dat het op gedefinieerde lifecycle-gates opnieuw moet worden bekeken en getriggerd door significante gebeurtenissen (grote release, leverancierswijziging, nieuwe implementatiecontext, incidentlessen).

Hoe moeten kmo's threat modelling aanpakken?

De playbook bouwt voort op de STRIDE-methodologie (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) als basis voor bedreigingsidentificatie en -classificatie (Sectie 2.3).

Het waarschuwt uitdrukkelijk tegen veelvoorkomende anti-patronen: threat modelling behandelen als een eenmalige compliance-oefening, het overengineren van modellen die geen invloed hebben op ontwerp- of secure-by-default-beslissingen, en het nalaten het model te herzien na substantiële productwijzigingen of veranderingen in het bedreigingslandschap.

Voor kmo's, met name die producten ontwikkelen voor niet-kritieke of lager-risico-omgevingen, is het doel een "minimum viable" model: snel te produceren, eenvoudig te vernieuwen en nauw gekoppeld aan delivery (architectuurbeslissingen, standaardconfiguratie en release gates).

De 5 stappen (Tabel 3)

1. Definieer scope, aannames en beveiligingsdoelstellingen: Begrens de scope-stap in tijd. Leg vast wat wel/niet in scope is, de implementatiecontext en de aannames waarop je vertrouwt (bijv. "klantnetwerk is niet vertrouwd", "cloud API's zijn blootgesteld aan het internet"). Formuleer de beveiligingsdoelstellingen die er toe doen voor dit product (vertrouwelijkheid, integriteit, beschikbaarheid, plus privacy/veiligheid indien van toepassing). Identificeer de "kroonjuwelen": wat mag nooit falen. Deliverable: 1-pagina "Threat Model Scope en Doelstellingen".

2. Modelleer het systeem op een nuttig abstractieniveau: Maak één eenvoudig architectuur- of datastroomdiagram. Toon hoofdcomponenten, externe entiteiten, dataopslag en de belangrijkste toegangspunten en datastromen. Een DFD-stijl diagram is de snelste benadering met hoge waarde. Het document zegt "denk er niet te lang over na". Deliverable: Diagram met hoofdcomponenten, externe entiteiten, dataopslag, toegangspunten.

3. Markeer vertrouwensgrenzen en geprivilegieerde paden; identificeer sleutelassets: Annoteer het diagram met vertrouwensgrenzen (internet-backend, apparaat-cloud, gebruiker-beheerder, tenant-tenant) en de hoogst-geprivilegieerde operaties (firmware/OTA-update, beheer op afstand, sleutelinrichting, identiteitsuitgifte). Deze stap verandert "architectuur" in "beveiligingsrelevante architectuur". Deliverable: Diagram met vertrouwensgrenzen, geprivilegieerde paden, topassets.

4. Identificeer en prioriteer topbedreigingen (5-10 misbruikscenario's): Genereer een korte lijst van realistische misbruikscenario's gekoppeld aan toegangspunten en grenzen (bijv. "credential stuffing naar accountovername", "kwaadaardige update", "API-autorisatieomzeiling", "MITM bij onboarding"). Rangschik ze met een lichtgewicht schema (Hoog/Midden/Laag) op basis van impact en plausibiliteit. OWASP beschrijft bedreigingsidentificatie en -rangschikking als een kernstap in de meeste threat modelling-benaderingen. Deliverable: Topbedreigingstabel met 5-10 misbruikscenario's, impact + waarschijnlijkheid, "toprisico's"-lijst.

5. Definieer mitigaties, veilige standaarden en verificatie; stel vernieuwingstriggers in: Specificeer voor elke topbedreiging de mitigatiestrategie, de vereiste controle(s) en de secure-by-default-instelling die geleverd moet worden (bijv. "beheerinterface standaard uitgeschakeld", "geen standaardwachtwoorden", "ondertekende updates afgedwongen", "least privilege-rollen", "verificatiepogingen beperkt"). Koppel elke controle aan een verificatiemethode (CI-checks, tests, configuratievalidatie, release gate). Definieer de triggers die vereisen dat het model opnieuw wordt uitgevoerd (nieuw internet-blootgesteld interface, auth-modelwijziging, nieuwe gevoelige data, nieuwe kritieke afhankelijkheid, grote architectuurwijziging). Deliverable: Controles, Standaarden en Verificatie-checklist.

Wat zijn de 22 beveiligingsprincipes?

Het document definieert 22 beveiligingsprincipes (Sectie 3), die elk hun eigen éénpagina-playbook krijgen in Sectie 4. De playbooks zijn de kerndeliverable van het document. Elk destilleert één principe tot een uitvoeringsgericht handleiding met een checklist, minimaal bewijsmateriaal en release gate-criteria. De principes zijn georganiseerd in twee pijlers: Secure by Design (hoe het systeem is ontworpen, 14 principes) en Secure by Default (hoe het product arriveert en zich gedraagt bij eerste inschakeling, 8 principes). Elke pijler is verder verdeeld in twee groepen.

Architecturale Fundamenten (6 principes)

Deze behandelen hoe het systeem structureel is ontworpen en gebouwd:

1. Vertrouwensgrenzen en threat modelling: Maak vertrouwen expliciet. Definieer waar data, identiteiten en uitvoeringscontexten overgaan van vertrouwde naar niet-vertrouwde zones. Voer threat modelling uit om te identificeren wat er fout kan gaan bij die grenzen.
2. Least privilege: Verleen alleen de minimaal vereiste toegang. Pas dit consequent toe op gebruikersaccounts, serviceaccounts, API's en beheerdersrollen. Verhoog alleen wanneer nodig, voor de kortst mogelijke duur.
3. Sterke identiteits- en authenticatiearchitectuur: Duidelijke aanpak voor hoe identiteiten worden aangemaakt, geverifieerd en beheerd voor gebruikers, apparaten, services en beheerders. Bestand tegen credential stuffing, replay en sessiekaping.
4. Aanvalsoppervlakminimalisatie: Verminder complexiteit. Verwijder standaardaccounts, verwijder ongebruikte pakketten, sluit niet-essentiële poorten, beperk blootgestelde beheerinterfaces. Doorlopende kwetsbaarheidsscanning.
5. Defence in depth: Gelaagde controles zodat het falen van één niet tot volledige compromittering leidt. Preventieve, detectieve en corrigerende controles. Divers en onafhankelijk, niet allemaal afhankelijk van dezelfde technologie of vertrouwensaanname.
6. Open Design (obscuriteit vermijden): Vertrouw niet op de geheimhouding van het ontwerp voor bescherming. Gebruik goed bestudeerde algoritmen en protocollen, duidelijke documentatie en ontwerpen die bestand zijn tegen scrutiny. Beveiliging moet rusten op beschermde sleutels, sterke authenticatie en robuuste implementatie, niet op verborgen mechanismen.

Operationele Integriteit (8 principes)

Deze behandelen hoe het systeem wordt beheerd en onderhouden:

1. Lifecycle-beheer: Beveiliging reikt verder dan ontwikkeling. Onderhoud, update en pensioneer op een gecontroleerde manier. Pas secure by design toe van ontwikkeling tot buitengebruikstelling.
2. Gebruikersgerichte ontwerp: Beveiliging moet bruikbaar zijn voor alledaagse gebruikers. Slechte bruikbaarheid leidt tot onveilige omwegen. Eenvoudige setup, automatische encryptie, begeleide stromen.
3. Veilige codeerpraktijken: Volg gevestigde veilige coderingsstandaarden. SAST-tools, SCA voor afhankelijkheden, DAST vóór implementatie. Vroege identificatie, niet na de release.
4. Logging, monitoring en waarschuwingen: Genereer beveiligingsrelevante logs, bewaar ze voor een gedefinieerde periode en bescherm ze tegen manipulatie. Detecteer verdacht gedrag (mislukte auth, privilege-escalatie, onverwachte configuratiewijzigingen).
5. Configuratie- en wijzigingsbeheer: Configuraties moeten gecontroleerd, consistent en controleerbaar zijn. Basis-hardening, infrastructure-as-code, wijzigingsproces met review/testen/goedkeuring/terugdraaien.
6. Incidentrespons en herstel: Voorbereid op kwetsbaarheden, gecompromitteerde code, kwaadaardige updates, productmisbruik. Gedefinieerde rollen, escalatiepaden, gedocumenteerde playbooks, klantcommunicatie.
7. Kwetsbaarheids- en patchbeheer: Praktisch, herhaalbaar, risicoprioritair. Eenvoudig innamkanaal (beveiligings-e-mail + openbaarmakingsproces), intern triageproces, duidelijke SLA's.
8. Supply chain-controles: Bescherm de productintegriteit op de punten met de hoogste impact: coderepositories, buildsystemen, ondertekeningssleutels, distributiekanalen. Minimaal: beperkte CI/CD-toegang, MFA, peer review voor beveiligingskritische wijzigingen, SBOM's.

Standaard Hardening (4 principes)

Deze zorgen ervoor dat producten starten in een veilige en restrictieve toestand:

1. Minimalisering van standaard services: Niet-essentiële functies en services standaard uitgeschakeld. Gebruiker moet expliciet opt-in geven.
2. Restrictieve initiële toegang: Elimineer universele "admin/admin"-inloggegevens. Dwing unieke wachtwoorden en verplichte wachtwoordwijziging bij eerste opstart af.
3. Veilige communicatie standaard: Alle externe communicatie versleuteld en geverifieerd vanaf de eerste verbinding. Strikt TLS 1.3 of SSH handhaven. Geen HTTP/Telnet-terugvalopties.
4. Unieke apparaatidentiteit en geheimen standaard: Leverbaar met unieke per-apparaat inloggegevens en cryptografische identiteit. Geen gedeelde sleutels of certificaten over producten. Beschermd tegen extractie.

Begeleide Bescherming (4 principes)

Deze helpen gebruikers beveiliging te handhaven na implementatie:

1. Verplichte beveiligingsonboarding: Kritieke beveiligingsfuncties moeten deel uitmaken van de initiële setup-wizard (MFA, encryptiesleutel, beheerderaccount-setup). Niet verborgen in instellingen. Blokkeer werking totdat dit is voltooid.
2. Geautomatiseerd onderhoud en updates: Automatische beveiligingsupdates standaard ingeschakeld. Scheid beveiligingsupdates van feature-updates. Cryptografisch geverifieerd. Veilige faalwijzen (beschadig het apparaat niet). Informeer gebruikers.
3. Transparante beveiligingspositie: Toon de huidige beveiligingstoestand duidelijk. Waarschuw wanneer de gebruiker beveiliging vermindert. Leg de impact uit in begrijpelijke taal. Bied een één-klik-pad om terug te keren naar een veilige baseline.
4. Veilig herstel en eigendoms-lifecycle: Begeleide herstel (inloggegevens resetten, accountherstel, fabrieksreset, eigendomsoverdracht). Eenvoudig voor gebruikers maar bestand tegen accountovername en social engineering. Fabrieksreset moet alle vorige gebruikerstoegang volledig verwijderen.

CRA-koppeling: Bijlage C van de playbook koppelt elk van deze 22 principes aan specifieke CRA Bijlage I essentiële vereisten, en toont precies welke engineeringpraktijken welke wettelijke verplichtingen ondersteunen.

Hoe werken de playbooks?

Het playbook-formaat

Sectie 4 is het meest uitgebreide deel van het document. Het biedt een praktische, lichtgewicht manier voor kmo's om Security by Design and Default te implementeren zonder een zware governance-last te creëren. Elke playbook destilleert één beveiligingsprincipe tot een éénpagina, uitvoeringsgericht handleiding die teams herhaaldelijk kunnen toepassen over releases en productlijnen (Sectie 4, p28).

Het doel is beveiligingsprincipes te vertalen van abstracte aspiraties naar concrete engineering- en operationele acties, met duidelijke verwachtingen, verifieerbare resultaten en een consistente "definition of done" voor beveiliging. Elke playbook volgt hetzelfde vijf-secties-formaat:

• Principe: Het te implementeren beveiligingsconcept
• Doelstelling: Wat het principe probeert te bereiken en welke faalwijzen het vermindert
• Checklist: De acties met de hoogste impact om te implementeren (ontworpen om haalbaar te zijn voor lean teams)
• Minimaal bewijs: De kleinste set artefacten, logs of configuraties die aantonen dat de checklist is geïmplementeerd
• Release gate: Een kopieer-/plak-set van geslaagd/gezakt-criteria die kunnen worden gebruikt in een release-review of CI/CD om regressies te voorkomen

Belangrijk: Deze structuur is bewust afgestemd op hoe kmo's werken: korte cycli, gedeelde verantwoordelijkheden, beperkte specialistische capaciteit en een behoefte aan richtlijnen met een hoge signaal-ruisverhouding.

De playbooks gebruiken

• Behandel de release gate van elke playbook als een standaard agendapunt in release-readiness-reviews
• Implementeer het minimale bewijs als repository-artefacten en CI-outputs waar mogelijk
• Sta uitzonderingen alleen toe met gedocumenteerde motivatie, eigenaar en reviewdatum
• Vernieuw playbooks periodiek op basis van incidentlessen, kwetsbaarhedstrends en productwijzigingen
• De inhoud moet worden behandeld als een baseline, niet als een eindstaat. Bekijk en update naarmate producten evolueren.

Alle 22 playbooks in één oogopslag

Architecturale Fundamenten:

Operationele Integriteit:

Standaard Hardening:

Begeleide Bescherming:

Verdieping: Playbook 4.13, Kwetsbaarheids- en patchbeheer

Om de praktische diepte van het formaat te tonen, hier is Playbook 4.13 in volledige detail zoals het in het document verschijnt:

Principe: Kwetsbaarheids- en patchbeheer moet praktisch, herhaalbaar en geprioriteerd naar risico zijn. Fabrikanten hebben een eenvoudige manier nodig voor klanten en onderzoekers om problemen te melden, en een intern proces om bevindingen snel te triageren en te beslissen wat dringende actie vereist.

Doelstelling: Kwetsbaarheden snel genoeg identificeren, prioriteren en verhelpen om echte blootstelling te verminderen, in je code, afhankelijkheden, infrastructuur en (indien van toepassing) apparaten/firmware. De focus is een eenvoudige intake-tot-fix-workflow, duidelijke SLA's en een updatemechanisme dat patching betrouwbaar maakt.

Checklist:

Minimaal bewijs:

• Kwetsbaarhedstracking-board/register: probleem, ernst, getroffen componenten/versies, eigenaar, status, doeldatum
• Gedefinieerde SLA's (voorbeeld): Kritieke triage binnen 48 uur; herstel/release-doel binnen X dagen (stel in op jouw realiteit)
• Scan-bewijs: CI-outputs voor afhankelijkheidsscanning + SAST (en DAST indien van toepassing)
• Proactieve afhankelijkheidspatches: SBOM of afhankelijkheidsinventaris per release (minimaal voor geleverde artefacten)
• Patch-release-record: koppeling van kwetsbaarheidsticket naar PR('s) naar tests naar releaseversie naar uitrolbevestiging
• Uitzonderingslog: aanvaarde risico's hebben eigenaar + vervaldatum/reviewdatum en compenserende controles (indien aanwezig)

Release gate:

• Afhankelijkheids- en SAST-scans uitgevoerd voor de release; Kritieke/Hoge bevindingen aangepakt of gedocumenteerde uitzondering (eigenaar + vervaldatum)
• SBOM (of afhankelijkheidsinventaris) gegenereerd/bijgewerkt en opgeslagen voor de release
• Bekende kwetsbaarheden die verzonden componenten treffen, zijn getriageerd met ernst, eigenaar en doeldatum
• Patchproces gevalideerd: reparatie gereviewd, tests geslaagd en release-notities bijgewerkt indien nodig
• Voor internet-blootgestelde componenten: mitigaties of patches voor Kritiek/Hoog zijn aanwezig vóór release
• OTA/update (indien van toepassing) gevalideerd voor veilige levering; terugdraaien/herstel gedocumenteerd
• Aanvaard restrisico is tijdgebonden en wordt bijgehouden tot afsluiting of reviewdatum

Wat zijn Machine-Readable Security Manifests?

Sectie 5 van de playbook introduceert een nieuw concept: de verschuiving van statische, documentzware compliance naar machineleesbare, verifieerbare beveiligingsattestaties.

Een machineleesbare beveiligingsattestatie is een digitale claim in JSON of YAML die stelt dat aan een specifieke beveiligingscontrole, -proces of -eigenschap is voldaan. Anders dan statische PDF-rapporten kunnen deze attestaties worden gegenereerd en verwerkt door geautomatiseerde systemen, waardoor frequente updates en geautomatiseerde validatie mogelijk zijn. Ingebed in de ontwikkelingspipeline wordt beveiliging intrinsiek, geen post-development-vinkje.

Vier sleuteleigenschappen

• Aantoonbaarheid: Proactieve capaciteit om machineleesbaar bewijs te bieden dat aan beveiligingsvereisten is voldaan, een verschuiving van "beweren" naar "aantonen"
• Verifieerbaarheid: Een onafhankelijke partij kan de integriteit van beveiligingsclaims programmatisch authenticeren en valideren, transparant, manipulatiebestendig en gekoppeld aan een erkend vertrouwensanker
• Herbruikbaarheid: Gebruik bestaande attestaties om op voort te bouwen, in de ontwikkelingscyclus te integreren en op te nemen in agile kwaliteitsgates
• Betrouwbaarheid: Vertrouw op attestaties voor due diligence door derden, wat supply chain-vertrouwen vereenvoudigt

Het vierlaagsmodel

De playbook illustreert een hiërarchisch datamodel waarbij elke hoogwaardige beveiligingsclaim wordt ondersteund door granulaire technische bewijzen:

1. Metadata en Attestatie (Identiteitsdomein): Productidentiteit, versiebeheer, cryptografische handtekening van de fabrikant
2. Controlelaag (Governance-domein): Gestructureerde beveiligingsdoelstellingen afgestemd op vereisten, principes en regelgeving
3. Implementatielaag / Bedreiging-Mitigatie-Kaart (Operationeel domein): Koppelt specifieke bedreigingen aan geïmplementeerde mitigaties, ontwerpprincipes, standaardinstellingen en voor mensen leesbare beschrijvingen
4. Beoordelings- en Verificatielaag (Bewijs-domein): Machineleesbare geslaagd/gezakt-resultaten van geautomatiseerde gates, met koppelingen naar SBOM's

Het document beschrijft ook toegangscontrollagen: een Publiek-Gerichte JSON met hoogwaardige claims, en een Beperkte Technische Overlay met versleutelde gedetailleerde toolconfiguraties en testtelemetrie.

Bestaand ecosysteem

De playbook plaatst MRSM binnen het bestaande standaardenlandschap:

• OSCAL (NIST): "Compliance as Code", gestandaardiseerde beveiligingscontrolecatalogi, systeembeveiligingsplannen, beoordelingsresultaten
• CycloneDX CDXA (OWASP/ECMA-424): Oorspronkelijk een SBOM-formaat, uitgebreid tot een volledige transparantiestandaard. CDXA-attestaties voor beveiligingsclaims, VEX voor exploiteerbaarheid, CBOM voor cryptografische assets
• OpenSSF: Security Insights (machineleesbare beveiligingsfeiten in YAML), Scorecard (geautomatiseerde best-practice-beoordeling)
• OWASP ASVS: Application Security Verification Standard, onderliggende vereisten. MLSVS uitgebreid naar AI/ML
• TC54 (Ecma International): Transparency Exchange API, standaardisering van hoe SBOM's en attestaties worden ontdekt en gedeeld

Het SafeGate-X1-voorbeeld

Het document bevat een volledig scenario (pagina's 56-61) dat laat zien hoe een fictieve hardware-controller-fabrikant MRSM zou implementeren: een threat model met 5 bedreigingen (RCE via web API, privilege-escalatie, port-scanning, credential stuffing, binary-manipulatie), controles gekoppeld aan principes, en een JSON-manifest dat laat zien hoe elke threat_id wordt gekoppeld aan een principe, mitigation_control, secure_by_default_setting en verification_gate met evidence_hash. Het bevat ook een verificatietabel voor derden die laat zien wat auditors steekproefsgewijs kunnen controleren.

Opmerking: MRSM is een illustratief concept, geen voorgestelde standaard. Maar het signaleert waar CRA-compliance naartoe gaat: van statische PDF-bewijsmappen naar verifieerbare, machineleesbare artefacten die je CI/CD-pipeline en klanten automatisch kunnen verifiëren.

Hoe koppelen de principes aan CRA-vereisten?

Bijlage C van de playbook biedt een volledige mapping van alle 22 principes naar specifieke CRA Bijlage I essentiële vereisten. Dit is de engineeringbrug tussen de richtlijnen van de playbook en jouw wettelijke verplichtingen.

CRA Bijlage I is verdeeld in twee delen:

• Deel 1 (ANNEX-1.PT1): Productbeveiligingsvereisten, die 14 vereisten omvatten: beoordeling van cyberbeveiligingsrisico's, veilige standaarden, updates, toegangscontrole, gegevensbescherming, integriteit, dataminimalisatie, beschikbaarheid, beperking van het aanvalsoppervlak, incidentmitigatie, logging en veilige gegevensverwijdering
• Deel 2 (ANNEX-1.PT2): Vereisten voor kwetsbaarheidsbehandeling, die 8 vereisten omvatten: SBOM, tijdige verhelping, testen, openbaarmaking, gecoördineerde VDP, kwetsbaarheidsintake, veilige distributie van fixes en tijdige verspreiding

Elk principe koppelt aan meerdere CRA-vereisten. Hier zijn geselecteerde voorbeelden uit Bijlage C:

CRA-koppeling: De playbook is geen juridische compliance-checklist, maar biedt de engineeringbrug naar CRA Bijlage I. Als je aantoonbare naleving van deze 22 principes kunt laten zien, heb je substantieel bewijs ter ondersteuning van je CRA-conformiteitsbeoordeling.

Wat moet je als volgende stap doen?

1. Begin met Sectie 2: Identificeer je huidige lifecycle-fase en produceer de deliverables uit Tabel 1. Zelfs een éénpagina-Security Context-notitie en een basisarchitectuurdiagram zetten je voor op de meeste teams.

2. Doorloop de 8 risicobeheeractiviteiten (Tabel 2): De meeste kmo's kunnen de outputs in 1-2 gerichte dagen produceren. Begin met productcontext, asset/schade-identificatie en je risicoaanvaardingscriteria.

3. Voer een lichtgewicht threat model uit (Tabel 3): Zelfs 2 uur met je team, met een whiteboard en STRIDE, levert bruikbare resultaten op. Focus op de 5-10 misbruikscenario's die er het meest toe doen.

4. Kies de 3-5 playbooks die het meest relevant zijn voor je volgende release en gebruik de checklists. Veelvoorkomende startpunten: 4.9 (Veilig coderen), 4.13 (Kwetsbaarhedsbeheer), 4.2 (Least privilege), 4.16 (Restrictieve initiële toegang).

5. Gebruik de release gate-criteria als je pre-release-beveiligingsreview-agenda. Dit is het snelste pad van "geen beveiligingsreviewproces" naar "gedocumenteerde, herhaalbare security gates".

6. Download de volledige ENISA-playbook: Dit is een v0.4-concept. Dien je feedback in tijdens de consultatieperiode.

Officiële bronnen

• ENISA Security by Design and Default Playbook v0.4 (PDF)

Gerelateerde gidsen

• CRA Product Classification Guide
• SBOM Requirements Under the CRA
• CRA Technical File (Annex VII) Guide
• CRA Vulnerability Reporting: The 24-Hour Rule
• CRA Conformity Assessment Decision Guide

Dit artikel is uitsluitend bedoeld voor informatieve doeleinden en vormt geen juridisch advies. Raadpleeg een gekwalificeerde juridisch adviseur voor specifiek compliance-advies.