ENISAs Secure by Design-playbook: Vad det betyder för produktteam under CRA

Sammanfattning

• ENISA publicerade ett Security by Design and Default Playbook (v0.4, mars 2026), den första officiella EU-vägledningen som omvandlar CRA:s säkerhetskrav till praktiska ingenjörschecklistor för SMF
• Täcker hela produktlivscykeln: från kravspecifikation till avveckling
• Definierar 22 säkerhetsprinciper organiserade i Secure by Design (14) och Secure by Default (8)
• Varje princip har ett ensidigt playbook med checklista, minimibevis och kriterier för releaseport
• Innehåller 8 riskhanteringsaktiviteter och en 5-stegs hotmodelleringsprocess anpassad för snabbrörliga team
• Introducerar Machine-Readable Security Manifests (MRSM), ett nytt koncept för verifierbara, maskinläsbara efterlevnadsbevis
• Mappar alla 22 principer mot CRA Bilaga I:s väsentliga krav (Bilaga C)
• Är för närvarande ett utkast öppet för offentligt samråd

Vad är ENISA:s Secure by Design Playbook?

Den 19 mars 2026 publicerade Europeiska unionens cybersäkerhetsbyrå (ENISA) Security by Design and Default Playbook, version 0.4, som ett utkast för offentligt samråd.

Det är den första officiella EU-vägledningen som omvandlar CRA:s säkerhetskrav till konkreta ingenjörschecklistor riktade till SMF. Dokumentet är inte juridisk vägledning. Det ger praktiska, tekniskt välgrundade tillvägagångssätt som produktteam kan tillämpa under design-, bygg- och driftsättningsfaser.

Playbooken riktar sig till SMF (definierade som organisationer med färre än 250 anställda och en årlig omsättning under 50 miljoner euro) som tillverkar produkter med digitala element. Det inkluderar inbyggd programvara, IoT-enheter, anslutna system, fristående programvara och hårdvara med programmeringsbara komponenter.

ENISA utvecklade playbooken baserat på en analys av befintliga säkerhetsramverk publicerade av ENISA och andra EU-baserade cybersäkerhetsbyråer, samt vägledning från NIST och OWASP. Gemensamma krav och implementeringsmönster identifierades och utvärderades mot SMF:s kapacitet för att bedöma genomförbarhet och anpassningsbehov.

Bilaga C i playbooken mappar alla 22 principer direkt mot CRA Bilaga I:s väsentliga krav, vilket ger en spårbar länk mellan ingenjörspraxis och regulatoriska skyldigheter.

Viktigt: Detta är ett utkast för offentligt samråd (v0.4). ENISA söker aktivt feedback. Den slutliga versionen kan skilja sig.

Vem är den här playbooken för?

Playbooken identifierar fyra primära målgrupper (avsnitt 1.3):

• Programvaruutvecklare och ingenjörer: personer som skriver kod och behöver praktiska sätt att bygga in säkerhet utan att bromsa leveransen
• Tekniska produktchefer: personer som balanserar funktionsarbete mot säkerhetskrav och försöker få båda att fungera
• Säkerhetsansvariga på SMF: personer som översätter enterprise-ramverk till något som fungerar med begränsad budget och små team
• Systemarkitekter: personer som designar system och vill ha säkerhet inbyggt från start, inte påklistrat efteråt

Den gemensamma utmaningen som ENISA erkänner: de flesta SMF saknar ett dedikerat säkerhetsteam, har begränsad budget för säkerhetsverktyg och säkerhetsarbete som ständigt konkurrerar med funktionsleverans.

Playbooks svar: strukturerade checklistor som hjälper team att identifiera snabba säkerhetskontroller, implementera dem på ett realistiskt sätt och bygga en upprepningsbar baslinje som kan förbättras över tid.

Säkerhet genom hela produktlivscykeln

Säkerhet måste beaktas från start till slut, oavsett vilken produktionsmodell som används (V-modell, Agile eller annan). Playbooken definierar sex faser, var och en med specifika säkerhetsåtgärder och konkreta leverabler.

Nyckelprinciper från dokumentet:

• Använd små, återanvändbara artefakter (ensidiga kontextanteckningar, enkla diagram, checklistor)
• Föredra automatiserade kontroller i CI/CD framför manuella granskningar, och reservera djupgranskning för högriskändringar
• Inför snabba säkerhetsportar anpassade till befintliga agila ceremonier (Definition of Ready/Done, PR-kontroller, releasechecklista)

Varje fas producerar en konkret leverabel. Det är inte abstrakt vägledning.

Tips: Playbooken rekommenderar att livscykelartefakter hålls lätta: en ensidig säkerhetskontextanteckning, ett enkelt arkitekturdiagram och en releasechecklista räcker för att komma igång.

Vilka riskhanteringsaktiviteter rekommenderar ENISA?

Riskhanteringsaktiviteter ger grunden för alla Secure by Design och Default-beslut. Playbooken föreslår inte ett tungt formellt ramverk. Istället definierar den en minsta uppsättning aktiviteter som kan driva säkerhetsbeslut utan att skapa tung process (avsnitt 2.2).

Dokumentet definierar 8 aktiviteter (tabell 2):

1. Produktkontext och omfång: Definiera avsedd användning, driftmiljöer, användar-/administratörsroller, datatyper/känslighet och viktiga externa beroenden. Leverabel: 1–2 sidig "Product Security Context"-anteckning (omfång, antaganden, beroenden).
2. Identifiering av tillgångar och skador: Lista de viktigaste data-, hårdvaru- eller funktionstillgångarna (inloggningsuppgifter, kunddata, personuppgifter, enhetskontroll) och de viktigaste skadeutfallen (integritetsbrott, övertagande, avbrott, bedrägeri, säkerhetspåverkan). Leverabel: Tillgångslista + "toppskadie"-lista (en sida).
3. Lätt hotmodellering: Se avsnittet om hotmodellering nedan.
4. Riskregister: Registrera 10–30 risker med sannolikhet/konsekvens (enkel skala), ägare, behandling, status. Länka höga risker till backloggobjekt/kontroller. Leverabel: Levande riskregister (kalkylblad eller ärendestavla).
5. Riskacceptanskriterier: Definiera en uppsättning icke förhandlingsbara riskvillkor. Till exempel: missbruk av programuppdateringar, obehörig administratörsåtkomst eller utnyttjande av standardinloggningsuppgifter är INTE acceptabelt. Fastställ kriterier för att acceptera kvarvarande risker som inte bör undergräva väsentliga cybersäkerhetskrav. Leverabel: 1-sidig policy för riskacceptans och undantag.
6. Baslinje för säkerhetskrav: Översätt toppriskerna till testbara "måste"-krav (authn/authz, säkra defaults, hemligheter, kryptering, loggning, uppdateringar). Leverabel: SMF:s checklista för säkerhetskrav (testbara kontroller).
7. Releaseport för riskgranskning: Formell port före release: bekräfta att checklistan uppfyllts, defaults verifierade, kända sårbarheter triagerade, höga risker åtgärdade/accepterade med motivering. Besluta om go/no-go. Leverabel: Säkerhetsgranskning inför release + dokumenterade undantag.
8. Omvärdering vid förändring: Kör om kontext-/hot-/riskstegen när stora förändringar inträffar (arkitektur, autentiseringsmodell, kritiskt beroende/leverantör, driftmiljö, efter incidenter). Leverabel: Uppdaterad kontextanteckning, kortlista med hot och riskregisterposter (med datum).

Obs: Riskhantering är iterativ, inte engångs. Playbooken specificerar att den måste ses över vid definierade livscykelportar och triggas av betydande händelser (stor release, leverantörsändring, ny driftskontext, lärdomar från incidenter).

Hur bör SMF nalkas hotmodellering?

Playbooken bygger på STRIDE-metodologin (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) som grund för identifiering och klassificering av hot (avsnitt 2.3).

Den varnar uttryckligen för vanliga anti-mönster: att behandla hotmodellering som en engångsövning för efterlevnad, att överteknikifiera modeller som inte påverkar design eller secure-by-default-beslut, och att inte granska modellen efter väsentliga produktändringar eller förändringar i hotlandskapet.

För SMF, särskilt de som utvecklar produkter avsedda för icke-kritiska eller lägre riskens miljöer, är målet en "minimum viable"-modell: snabb att producera, enkel att uppdatera och tätt kopplad till leveransen (arkitekturbeslut, standardkonfiguration och releaseportar).

De 5 stegen (tabell 3)

1. Definiera omfång, antaganden och säkerhetsmål: Tidsbegränsa omfångsteget. Fånga vad som är inom/utom omfång, driftskontexten och de antaganden du förlitar dig på (t.ex. "kundnätverket är opålitligt", "moln-API:er är exponerade mot internet"). Ange de säkerhetsmål som är viktiga för den här produkten (konfidentialitet, integritet, tillgänglighet, plus integritetsskydd/säkerhet om tillämpligt). Identifiera "kronjuvelerna": vad som inte får misslyckas. Leverabel: 1-sidig "Threat Model Scope & Objectives".

2. Modellera systemet på en lämplig abstraktionsnivå: Ta fram ett enda, enkelt arkitektur- eller dataflödesdiagram. Visa huvudkomponenter, externa enheter, datalager och de viktigaste ingångspunkterna och dataflödena. Ett DFD-liknande diagram är det snabbaste tillvägagångssättet med hög avkastning. Dokumentet säger "övertänk inte det". Leverabel: Diagram som täcker huvudkomponenter, externa enheter, datalager och ingångspunkter.

3. Markera förtroendegränser och privilegierade vägar, identifiera nyckelresurser: Annotera diagrammet med förtroendegränser (internet-backend, enhet-moln, användare-administratör, klient-klient) och de mest privilegierade operationerna (firmware/OTA-uppdatering, fjärradministration, nyckelprovisioning, identitetsutfärdande). Det här steget omvandlar "arkitektur" till "säkerhetsrelevant arkitektur". Leverabel: Diagram med förtroendegränser, privilegierade vägar och topptillgångar.

4. Identifiera och prioritera topphoten (5–10 missbruksfall): Generera en kort lista med realistiska missbruksfall mappade till ingångspunkter och gränser (t.ex. "credential stuffing → kontoövertagande", "skadlig uppdatering", "API-auktoriseringskringgång", "MITM vid introduktion"). Rangordna dem med ett lätt schema (Hög/Medel/Låg) baserat på konsekvens och rimlighet. OWASP beskriver identifiering och rangordning av hot som ett centralt steg i de flesta hotmodelleringstillvägagångssätt. Leverabel: Topphottabell med 5–10 missbruksfall, konsekvens och sannolikhet, lista med "topprisk".

5. Definiera motåtgärder, säkra defaults och verifiering, sätt uppdateringstriggers: För varje topphot, specificera motåtgärdsstrategin, nödvändig kontroll och den secure-by-default-inställning som ska levereras (t.ex. "administratörsgränssnitt inaktiverat som standard", "inga standardlösenord", "signerade uppdateringar genomdrivna", "roller med lägsta behörighet", "autentiseringsförsök hastighetsbegränsade"). Mappa varje kontroll till en verifieringsmetod (CI-kontroller, tester, konfigurationsvalidering, releaseport). Definiera de triggers som kräver att modellen körs om (nytt internetexponerat gränssnitt, ändring av autentiseringsmodell, ny känslig data, nytt kritiskt beroende, stor arkitekturändring). Leverabel: Checklista för kontroller, defaults och verifiering.

Tips: Redan 2 timmars kollaborativ hotmodellering med ditt team ger genomförbara resultat. Dokumentet betonar "minimum viable". Du kan alltid förfina senare.

Vad är de 22 säkerhetsprinciperna?

Dokumentet definierar 22 säkerhetsprinciper (avsnitt 3), var och en får sitt eget ensidiga playbook i avsnitt 4. Playbooken är dokumentets kärnleverabel. Varje playbook destillerar en enskild princip till en genomförandefokuserad guide med en checklista, minimibevis och kriterier för releaseport. Principerna är organiserade i två pelare: Secure by Design (hur systemet är konstruerat, 14 principer) och Secure by Default (hur produkten levereras och beter sig när den slås på första gången, 8 principer). Varje pelare är vidare uppdelad i två grupper.

Arkitekturella grunder (6 principer)

Dessa behandlar hur systemet är strukturellt utformat och byggt:

1. Förtroendegränser och hotmodellering: Gör förtroende explicit. Definiera var data, identiteter och exekveringskontexer korsar från betrodda till obetrodda zoner. Hotmodellera för att identifiera vad som kan gå fel vid dessa gränser.
2. Lägsta behörighet: Bevilja bara den minsta åtkomst som krävs. Tillämpa konsekvent för användarkonton, tjänstkonton, API:er och administratörsroller. Eskalera bara vid behov, för kortast möjliga tid.
3. Stark identitets- och autentiseringsarkitektur: Tydlig strategi för hur identiteter skapas, verifieras och hanteras för användare, enheter, tjänster och administratörer. Motståndskraftig mot credential stuffing, replay-attacker och session hijacking.
4. Minimering av attackyta: Minska komplexitet. Ta bort standardkonton, avinstallera oanvända paket, stäng icke-nödvändiga portar, begränsa exponerade hanteringsgränssnitt. Löpande sårbarhetssökning.
5. Djupförsvar: Skiktade kontroller så att ett enda misslyckande inte leder till fullständig kompromiss. Preventiva, detektiva och korrigerande kontroller. Diversifierade och oberoende, inte alla beroende av samma teknik eller förtroendeantagande.
6. Öppen design (undvik obskyritet): Förlita dig inte på designens hemlighetshållning för skydd. Använd välstuderade algoritmer och protokoll, tydlig dokumentation och design som tål granskning. Säkerheten ska vila på skyddade nycklar, stark autentisering och robust implementering, inte på dolda mekanismer.

Operativ integritet (8 principer)

Dessa behandlar hur systemet hanteras och underhålls:

1. Livscykelhantering: Säkerheten sträcker sig bortom utvecklingen. Underhåll, uppdatera och pensionera på ett kontrollerat sätt. Tillämpa secure by design från utveckling till avveckling.
2. Användarcentrerad design: Säkerhet måste vara användbar av vanliga användare. Dålig användbarhet leder till osäkra kringgångslösningar. Enkel installation, automatisk kryptering, vägledd process.
3. Säkra kodningspraxis: Följ etablerade standarder för säker kodning. SAST-verktyg, SCA för beroenden, DAST före driftsättning. Tidig identifiering, inte efter release.
4. Loggning, övervakning och avisering: Generera säkerhetsrelevanta loggar, behåll dem under en definierad period och skydda dem från manipulation. Identifiera misstänkt beteende (misslyckad autentisering, privilegieeskalering, oväntade konfigurationsändringar).
5. Konfigurations- och ändringshantering: Konfigurationer måste vara kontrollerade, konsekventa och spårbara. Baslinjehärdning, infrastruktur som kod, ändringsprocess med granskning/testning/godkännande/återställning.
6. Incidentrespons och återhämtning: Förberedd för sårbarheter, komprometterad kod, skadliga uppdateringar, produktmissbruk. Definierade roller, eskaleringsvägar, dokumenterade playbooks, kundkommunikation.
7. Hantering av sårbarheter och patchar: Praktisk, upprepningsbar, riskprioriterad. Enkla intag (säkerhets-e-post + avslöjandeprocess), intern triagemprocess, tydliga SLA:er.
8. Leveranskedjekontroller: Skydda produktintegriteten på de punkter med störst påverkan: kodlagringsplatser, byggsystem, signeringsnycklar, distributionskanaler. Miniminivå: begränsad CI/CD-åtkomst, MFA, peer review för säkerhetskritiska ändringar, SBOM:er.

Standardhärdning (4 principer)

Dessa säkerställer att produkter startar i ett säkert och restriktivt tillstånd:

1. Minimering av standardtjänster: Icke-nödvändiga funktioner och tjänster inaktiverade som standard. Användaren måste uttryckligen aktivera dem.
2. Restriktiv initial åtkomst: Eliminera universella "admin/admin"-inloggningsuppgifter. Genomdriv unika lösenord och obligatorisk lösenordsändring vid första uppstart.
3. Säker kommunikation som standard: All extern kommunikation krypterad och autentiserad från första anslutning. Genomdriv strikt TLS 1.3 eller SSH. Inga HTTP/Telnet-fallbacks.
4. Unik enhetsidentitet och hemligheter som standard: Leverera med unika per-enhetsinloggningsuppgifter och kryptografisk identitet. Inga delade nycklar eller certifikat mellan produkter. Skyddat mot extraktion.

Vägledd skydd (4 principer)

Dessa stödjer användare i att upprätthålla säkerhet efter driftsättning:

1. Obligatorisk säkerhetsintroduktion: Kritiska säkerhetsfunktioner måste ingå i den initiala installationsguiden (MFA, krypteringsnyckel, administratörskontoinställning). Göm dem inte i inställningar. Blockera drift tills det är klart.
2. Automatiserat underhåll och uppdateringar: Automatiska säkerhetsuppdateringar aktiverade som standard. Separera säkerhetsuppdateringar från funktionsuppdateringar. Kryptografiskt verifierade. Säkra fellägen (förstör inte enheten). Notifiera användare.
3. Transparent säkerhetsläge: Visa tydligt aktuellt säkerhetstillstånd. Varna när användaren minskar säkerheten. Förklara konsekvenser på vanligt språk. Erbjud ett klick-väg för att återställa säker baslinje.
4. Säker återhämtning och ägandeskapslivscykel: Vägledd återhämtning (återställning av inloggningsuppgifter, kontoåterställning, fabriksåterställning, ägarskapsöverföring). Enkel för användare men motståndskraftig mot kontoövertagande och social manipulation. Fabriksåterställning måste fullständigt ta bort tidigare användaråtkomst.

CRA-koppling: Bilaga C i playbooken mappar var och en av dessa 22 principer mot specifika väsentliga krav i CRA Bilaga I, vilket visar exakt vilka ingenjörspraxis som stöder vilka rättsliga skyldigheter.

Hur fungerar playbooken?

Playbookens format

Avsnitt 4 är den mest omfattande delen av dokumentet. Det ger ett praktiskt, lätt sätt för SMF att implementera Security by Design och Default utan att skapa en tung styrningsbörda. Varje playbook destillerar en enskild säkerhetsprincip till en ensidig, genomförandefokuserad guide som team kan tillämpa upprepade gånger i releases och produktlinjer (avsnitt 4, s28).

Syftet är att översätta säkerhetsprinciper från abstrakta ambitioner till konkreta ingenjörsmässiga och operativa åtgärder, med tydliga förväntningar, verifierbara resultat och en konsekvent "definition of done" för säkerhet. Varje playbook följer samma femavsnittiga format:

• Principnamn: Säkerhetskonceptet som implementeras
• Mål: Vad principen försöker uppnå och vilka fellägen den minskar
• Checklista: De åtgärder med störst påverkan att implementera (utformade för att vara uppnåeliga av snabbrörliga team)
• Minimibevis: Den minsta uppsättningen artefakter, loggar eller konfigurationer som visar att checklistan implementerades
• Releaseport: En kopieringsbar uppsättning godkänd/underkänd-kriterier som kan användas i en releasegranskning eller CI/CD för att förhindra regressioner

Viktigt: Den här strukturen är medvetet anpassad till hur SMF arbetar: korta cykler, delade ansvarsområden, begränsad specialistkapacitet och ett behov av vägledning med högt signal-brus-förhållande.

Använda playbooken

• Behandla varje playbooks releaseport som en standardpunkt på agendan vid releasegranskningar
• Implementera minimibevis som lagringsplatsertefakter och CI-utdata i möjligaste mån
• Tillåt undantag bara med dokumenterad motivering, ägare och granskningsdatum
• Uppdatera playbooken regelbundet baserat på incidentlärdomar, sårbarhetstrender och produktändringar
• Innehållet bör behandlas som en baslinje, inte ett slutläge. Granska och uppdatera i takt med att produkterna utvecklas.

Alla 22 playbooks i överblick

Arkitekturella grunder:

Operativ integritet:

Standardhärdning:

Vägledd skydd:

Fördjupning: Playbook 4.13, hantering av sårbarheter och patchar

För att visa formatets praktiska djup, här är playbook 4.13 i fullständig detalj som den visas i dokumentet:

Princip: Hantering av sårbarheter och patchar bör vara praktisk, upprepningsbar och riskprioriterad. Tillverkare behöver ett enkelt sätt för kunder och forskare att rapportera problem, och en intern process för att snabbt triage fynd och avgöra vad som behöver brådskande åtgärd.

Mål: Identifiera, prioritera och åtgärda sårbarheter snabbt nog för att minska verklig exponering, i din kod, dina beroenden, infrastruktur och (om tillämpligt) enheter/firmware. Fokus är ett enkelt intag-till-fix-arbetsflöde, tydliga SLA:er och en uppdateringsmekanism som gör patchning pålitlig.

Checklista:

Minimibevis:

• Sårbarhetsspårningstavla/register: problem, allvarlighetsgrad, berörda komponenter/versioner, ägare, status, måldatum
• Definierade SLA:er (exempel): Kritisk triage inom 48 timmar, mål för åtgärder/release inom X dagar (anpassa till din verklighet)
• Sökningsbevis: CI-utdata för beroendesökning och SAST (och DAST om tillämpligt)
• Proaktiva beroendepatcher: SBOM eller beroendeförteckning per release (minst för levererade artefakter)
• Patchrelease-post: länk från sårbarhetsärende till PR/s till tester till releaseversion till driftsättningsbekräftelse
• Undantagslogg: accepterade risker har ägare och utgångsdatum/granskningsdatum samt kompenserande kontroller (om några)

Releaseport:

• Beroendes- och SAST-sökningar utförda för releasen. Kritiska/höga fynd åtgärdade eller dokumenterat undantag (ägare och utgångsdatum)
• SBOM (eller beroendeförteckning) genererad/uppdaterad och lagrad för releasen
• Kända sårbarheter som påverkar levererade komponenter är triagerade med allvarlighetsgrad, ägare och måldatum
• Patchprocess validerad: fix granskad, tester godkända och versionsnoteringar uppdaterade efter behov
• För internetexponerade komponenter: åtgärder eller patchar för Kritiska/Höga finns på plats före release
• OTA/uppdatering (om tillämpligt) validerad för säker leverans. Återställning/återhämtning dokumenterad
• Accepterad kvarvarande risk är tidsbegränsad och spårad till slutförande eller granskningsdatum

Vad är Machine-Readable Security Manifests?

Avsnitt 5 i playbooken introducerar ett nytt koncept: övergången från statisk, dokumenttung efterlevnad till maskinläsbara, verifierbara säkerhetsintyg.

Ett maskinläsbart säkerhetsintyg är ett digitalt påstående i JSON eller YAML som intygar att en specifik säkerhetskontroll, process eller egenskap har uppfyllts. Till skillnad från statiska PDF-rapporter kan dessa intyg genereras och konsumeras av automatiserade system, vilket möjliggör frekventa uppdateringar och automatiserad validering. Inbäddad i utvecklingspipelinen blir säkerhet inneboende, inte en efterhandsruta att kryssa i.

Fyra nyckelegenskaper

• Demonstrerbarhet: Proaktiv kapacitet att tillhandahålla maskinläsbara bevis på att säkerhetskrav har implementerats, en förskjutning från "påståendet" till "visandet"
• Verifierbarhet: En oberoende part kan programmatiskt autentisera och validera integriteten hos säkerhetspåståenden, transparent, manipuleringssäker och mappad till en erkänd rot av förtroende
• Återanvändbarhet: Använd befintliga intyg för att bygga vidare på, integrera i utvecklingscykeln och inkludera i agila kvalitetsportar
• Tillförlitlighet: Förlita sig på intyg för tredjepartsdue diligence, vilket förenklar förtroendet i leveranskedjan

Fyrlagermodellen

Playbooken illustrerar en hierarkisk datamodell där varje högnivåsäkerhetspåstående backas upp av granulär teknisk bevisning:

1. Metadata och intyg (identitetsdomän): Produktidentitet, versionshantering, tillverkarens kryptografiska signatur
2. Kontrollager (styrningsdomän): Strukturerade säkerhetsmål anpassade till krav, principer och regelverk
3. Implementeringslager / Hot-motåtgärdskarta (operativ domän): Mappar specifika hot till implementerade motåtgärder, designprinciper, standardinställningar och mänskligt läsbara beskrivningar
4. Bedömnings- och verifieringslager (bevisdomän): Maskinläsbara godkänd/underkänd-resultat från automatiserade portar, med länkar till SBOM:er

Dokumentet beskriver också åtkomstkontrollager: ett publikt JSON som ger högnivåpåståenden, och ett begränsat tekniskt överlager som innehåller krypterade detaljerade verktygskonfigurationer och testtelemetri.

Befintligt ekosystem

Playbooken placerar MRSM i det befintliga standardlandskapet:

• OSCAL (NIST): "Compliance as Code", standardiserade kataloger för säkerhetskontroller, säkerhetsplaner för system, bedömningsresultat
• CycloneDX CDXA (OWASP/ECMA-424): Ursprungligen ett SBOM-format, utvidgat till en fullständig transparensstandard. CDXA-intyg för säkerhetspåståenden, VEX för utnyttjandebarhet, CBOM för kryptografiska tillgångar
• OpenSSF: Security Insights (maskinläsbara säkerhetsfakta i YAML), Scorecard (automatiserad bedömning av bästa praxis)
• OWASP ASVS: Application Security Verification Standard, underliggande krav. MLSVS utvidgas till AI/ML
• TC54 (Ecma International): Transparency Exchange API, standardiserar hur SBOM:er och intyg hittas och delas

Det genomarbetade exemplet SafeGate-X1

Dokumentet innehåller ett fullständigt scenario (sidorna 56–61) som visar hur en fiktiv tillverkare av hårdvarukontroller skulle implementera MRSM: en hotmodell med 5 hot (RCE via webb-API, privilegieeskalering, portskanning, credential stuffing, binär manipulering), kontroller mappade mot principer och ett JSON-manifest som visar hur varje threat_id mappar till en principle, mitigation_control, secure_by_default_setting och verification_gate med evidence_hash. Det inkluderar också en tredjepartsverifieringstabell som visar vad revisorer kan stickprovskontrollera.

Obs: MRSM är ett illustrativt koncept, inte en föreslagen standard. Men det signalerar åt vilket håll CRA-efterlevnad är på väg: från statiska PDF-evidensmappar till verifierbara, maskinläsbara artefakter som din CI/CD-pipeline och dina kunder automatiskt kan verifiera.

Hur mappar principerna mot CRA:s krav?

Bilaga C i playbooken ger en fullständig mappning av alla 22 principer mot specifika väsentliga krav i CRA Bilaga I. Det är ingenjörsbryggan mellan playbooken vägledning och dina rättsliga skyldigheter.

CRA Bilaga I är uppdelad i två delar:

• Del 1 (ANNEX-1.PT1): Produktsäkerhetskrav, som täcker 14 krav: cybersäkerhetsriskbedömning, säkra defaults, uppdateringar, åtkomstkontroll, dataskydd, integritet, dataminimering, tillgänglighet, begränsning av attackyta, incidentminskning, loggning och säker dataradering
• Del 2 (ANNEX-1.PT2): Krav på hantering av sårbarheter, som täcker 8 krav: SBOM, snabb åtgärd, testning, avslöjande, koordinerad VDP, intag av sårbarheter, säker distribution av patchar och snabb spridning

Varje princip mappar mot flera CRA-krav. Här är utvalda exempel från Bilaga C:

CRA-koppling: Playbooken är inte en checklista för juridisk efterlevnad, men den ger ingenjörsbryggan till CRA Bilaga I. Om du kan visa efterlevnad av dessa 22 principer har du väsentliga bevis som stöder din CRA-konformitetsbedömning.

Vad bör du göra härnäst?

1. Börja med avsnitt 2: Identifiera din aktuella livscykelfas och ta fram leverablerna från tabell 1. Även en ensidig Security Context-anteckning och ett grundläggande arkitekturdiagram sätter dig före de flesta team.

2. Gå igenom de 8 riskhanteringsaktiviteterna (tabell 2): De flesta SMF kan ta fram utdata på 1–2 fokuserade dagar. Börja med produktkontext, identifiering av tillgångar/skador och dina riskacceptanskriterier.

3. Gör en lätt hotmodell (tabell 3): Redan 2 timmar med ditt team, med en whiteboard och STRIDE, ger genomförbara resultat. Fokusera på de 5–10 missbruksfall som betyder mest.

4. Välj de 3–5 playbooks som är mest relevanta för din nästa release och använd checklistorna. Vanliga startpunkter: 4.9 (Säker kodning), 4.13 (Sårbarhetshanterin), 4.2 (Lägsta behörighet), 4.16 (Restriktiv initial åtkomst).

5. Använd releaseportkriterierna som agenda för din säkerhetsgranskning inför release. Det är den snabbaste vägen från "ingen säkerhetsgranskning" till "dokumenterade, upprepningsbara säkerhetsportar".

6. Ladda ner hela ENISA-playbooken: Det är ett v0.4-utkast. Skicka in din feedback under samrådstiden.

Tips: Börja smått. Välj en kommande release, tillämpa 3 playbooks och använd releaseportarna. Du får konkreta bevis på Secure by Design-praxis att bygga vidare på.

Officiella källor

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

Relaterade guider

• 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

Den här artikeln är enbart i informationssyfte och utgör inte juridisk rådgivning. För specifik efterlevnadsvägledning, rådgör med kvalificerat juridiskt ombud.