Inbyggd säkerhet enligt CRA — omsätt krav i produktarbete

”Inbyggd säkerhet” är inte ett policydokument att skriva under. För en produkt med digitala element ska den synas i konstruktionsbeslut, minskad attackyta, säkra standardinställningar, uppdateringshantering, testning och sårbarhetshantering under hela produktens livscykel.

En praktisk modell är enkel: risk → krav → konstruktionsbeslut → åtgärd → test → resultat → underlag → granskning.

Omsätt väsentliga krav i produktarbete

Bilaga I till CRA innehåller väsentliga cybersäkerhetskrav. I det praktiska produktarbetet behöver team hantera bland annat:

utformning av produkten med en cybersäkerhetsnivå som motsvarar risken;
skydd mot obehörig åtkomst;
konfidentialitet, integritet och tillgänglighet för data och funktioner;
minskning av attackytan;
mekanismer som minskar konsekvenserna av en incident;
registrering och övervakning av relevant säkerhetsrelaterad aktivitet;
säker borttagning av data och inställningar;
säker distribution av uppdateringar;
regelbundna säkerhetstester och granskningar;
samordnad information om sårbarheter.

En checklista är en utgångspunkt. Den är inget bevis på genomförande.

Exempel: ”skydda mot obehörig åtkomst”

En svag post säger:

”Systemet har autentisering.”

En operativ post kan visa:

Risk: ett komprometterat administratörskonto kan ändra säkerhetskritisk konfiguration.
Beslut: privilegierade roller kräver en definierad mekanism för autentisering och sessionskontroll.
Ansvarig: en namngiven person eller ett team.
Genomförande: länk till utvecklingsändringen.
Test: scenario som verifierar det nödvändiga beteendet.
Resultat: PASS/FAIL med produktversion och datum.
Underlag: rapport, logg, skärmbild eller testartefakt.
Granskning: upprepad bedömning efter ändringar i autentisering eller riskprofil.

Månader senare kan organisationen visa både vad den avsåg att göra och vad som faktiskt verifierades.

Säkerhet som standard

Standardkonfigurationen är viktig eftersom många användare inte ändrar säkerhetsinställningarna efter driftsättning. CRA-kraven omfattar bland annat säker konfiguration, uppdateringar och skyddsmekanismer.

Fråga för varje säkerhetsrelevant funktion:

vilken konfiguration en ny användare får som standard;
varför standardinställningen är lämplig för normal användning;
vilka skydd som kan försvagas eller stängas av;
om riskfyllda ändringar är begripliga för användaren;
om produkten kan återgå till ett säkert tillstånd;
vilket test som verifierar beteendet efter installation och uppdatering.

Lägg säkerheten i utgåveprocessen, inte i dokumentationen efteråt

En utgåvegranskning ska åtminstone kontrollera:

om hotmodellen eller riskprofilen har ändrats;
om nya beroenden har införts;
om säkerhetstesterna täcker ändringen;
om kända sårbarheter har dokumenterade beslut;
om säkerhetsinformationen till användarna fortfarande är korrekt;
om antaganden och beroenden för stödperioden fortfarande är realistiska;
om underlaget är kopplat till rätt produktversion.

Om dessa frågor ställs först under en revision har organisationen en dokumentationsprocess snarare än inbyggd säkerhet.

ENISA: upprepbara åtgärder i stället för slogans

ENISA publicerade sin ”Secure by Design and Default Playbook” för små och medelstora företag den 30 juli 2026. Materialet fokuserar på att omvandla principer till upprepbara åtgärder i befintliga utvecklings-, produkt- och utgåveprocesser. Samma princip fungerar för CRA-införandet: använd teamets verkliga leveransprocess och gör sedan ansvar och underlag uttryckliga.

Hur Pulsar stödjer ett arbetsflöde grundat på underlag

Risker, kontroller, uppgifter, dokument, underlag, revisioner och rapporter i Pulsar kan koppla ett konstruktionsbeslut till genomförande, verifiering och granskning.

AI i Pulsar ska förbli ett stöd för att förbereda utkast. Den ska inte självständigt godkänna en riskbedömning, ett säkerhetsundantag eller ett beslut om produktens överensstämmelse.

Se Pulsar GRC i ett flöde från krav till underlag

Börja med ett missbruksscenario som går att testa

Anta att en produkt har ett administrativt gränssnitt som kan ändra nätverksinställningar. Beskriv vem som ska få göra ändringen och vilken skada en obehörig ändring kan ge. Ange vilka vägar som finns till funktionen och vilka förutsättningar som krävs. En allmän risktext om ”cyberattack” hjälper utvecklaren mindre än ett avgränsat scenario där ett obehörigt konto försöker ändra en bestämd inställning.

Formulera därefter ett verifierbart produktkrav och en testidé. Testet behöver kontrollera både att behörig användning fungerar och att obehörig användning avvisas. Koppla resultatet till rätt version och konfiguration. Artikeln beskriver hur kravet görs prövbart; den väljer inte den tekniska säkerhetslösningen för varje produkt. Det valet behöver grundas på arkitektur, risk och tillämpliga krav.

Antaganden är en del av riskbedömningen

En kontroll kan vara tillräcklig i ett särskilt nät men ge andra resultat när produkten senare exponeras direkt. Dokumentera därför antaganden om installation, användare, gränssnitt och beroenden. Kontrollera dem mot produktens avsedda användning och användarinformation. Om produkten säljs på ett sätt som gör antagandet osannolikt behöver design eller instruktioner omprövas. Risken försvinner inte för att den beskrivs som ett kundansvar.

Bevara även sådant som inte har verifierats. Ett test kan täcka en normal konfiguration men ännu inte en återställd eller migrerad installation. Den begränsningen behöver vara synlig vid utgåvebeslutet. En granskare ska kunna se om nästa steg är ett nytt test, en teknisk ändring eller en motiverad avgränsning. Det ger ett användbart beslut i stället för en allmän lista över säkerhetsåtgärder.

Standardinställningen behöver prövas från början

Använd en ren installation eller en motsvarande testuppsättning och kontrollera vilka funktioner som är aktiva innan kunden ändrar något. Följ de relevanta behörigheter och anslutningar som användaren får. Testa även återställning när funktionen finns. Ett säkert resultat efter många manuella specialiststeg säger lite om hur produkten beter sig för en ny användare.

Skriv vilka inställningar som kunden förväntas ändra och varför. Om en säkerhetsrelevant ändring krävs ska informationen vara begriplig och stämma med gränssnittet. Prova instruktionen med någon som inte utvecklade funktionen. Om personen behöver odokumenterade råd från en expert är instruktionen ofullständig. Dokumentera vad som förbättrades och verifiera resultatet innan en tidigare risk anses hanterad.

Uppdateringshantering måste tåla felaktiga indata

En korrekt uppdatering som lyckas installeras är ett positivt funktionstest. Lägg även till ofarliga negativa fall i en tillåten testmiljö: fel produktversion, ett paket som inte ska accepteras eller ett avbrott vid ett relevant steg. Bedöm vad användaren ser och vilket återställningsbeteende som behövs. Testerna ska följa produktens faktiska hotbild och tekniska lösning, inte en generell mall som saknar koppling till arkitekturen.

Koppla de negativa resultaten till designbeslut och åtgärder. Om en begränsning lämnas kvar ska godkännaren känna till den och kunna läsa dess omfattning. Ett lyckat normalt test får inte användas för att dölja att felhantering saknas. Registrera också vilken utgåva som testats; samma uppdateringslogik kan bete sig annorlunda i en äldre produktvariant.

Minimera vad som behöver skyddas

Gå igenom funktioner och gränssnitt som produkten erbjuder. Fråga varför varje säkerhetsrelevant funktion behövs och vilka parter som kan nå den. En oanvänd funktion kan ändå öka komplexiteten för behörigheter, uppdateringar och tester. Dokumentera beslut om att ta bort, begränsa eller behålla den. En tydlig motivering hjälper senare utvecklare att förstå varför den inte ska aktiveras av bekvämlighet.

Samma arbete gäller data. Identifiera vilket innehåll som behövs för produktens funktion och hur länge det behövs. Om personuppgifter ingår krävs även relevant dataskyddsbedömning. En teknisk kontroll kan stödja flera skyldigheter, men de rättsliga frågorna ska hållas urskiljbara. Den här artikeln ger ingen generell garanti om att en viss lagringsperiod eller konfiguration uppfyller alla regler.

Säkerhetstest behöver relevant omfattning

Välj testfall från de risker som dokumenterats för produkten. Ange testmiljö, version, förväntat beteende och hur resultatet bedöms. Bevara observationer som motsäger förväntningen. Om en kontroll bara fungerar med en särskild konfiguration behöver teamet veta om den konfigurationen motsvarar avsedd användning. Ett godkänt resultat utan beskrivna förhållanden är svårt att använda i ett produktbeslut.

Upprepa relevanta tester när ändringen påverkar förutsättningarna. Det behöver inte innebära att varje liten ändring ger exakt samma stora testpaket. En ansvarig bedömning kan identifiera vad som berörs och varför. Bevara den bedömningen så att granskaren kan följa hur testomfattningen valdes. Riskbaserat arbete kräver ett synligt skäl, inte bara en mindre mängd tester.

Kvarstående risk får en ansvarig bedömning

Utvecklingsteamet kan hitta en svaghet som inte löses i den planerade utgåvan. Ange dess konsekvens, befintliga kontroller och vad som talar för eller emot att fortsätta. Behörig person behöver fatta ett dokumenterat beslut inom organisationens process. Att uppgiften skjuts fram i utvecklingsregistret är inte i sig en bedömning av produktens tillämpliga skyldigheter eller kvarstående risk.

Ange när beslutet ska omprövas och vilka förändringar som utlöser ny bedömning. Nya användningssätt, nya exploateringsuppgifter eller en ändrad komponent kan påverka slutsatsen. Bevara tidigare beslut som historik och skapa en ny bedömning. Om allt alltid kallas accepterat blir registret svårt att skilja från en lista över det teamet inte hann göra.

En överlämning till drift och support

De som tar emot användarproblem behöver känna till relevanta begränsningar, säkerhetskontakt och hur tekniska fynd eskaleras. Dokumentera vilken information de får och prova hur ett hypotetiskt ärende hanteras. Supporten ska kunna identifiera produkt och version utan att först gissa utifrån kundens abonnemang. Om den informationen saknas behöver mottagningsprocessen förbättras.

Koppla sårbarhetsprocessen till utveckling och produktbeslut. En återkommande observation från support kan visa att standardinställning eller instruktion inte fungerar i praktiken. Bevara det som underlag för nästa bedömning. Inbyggd säkerhet fortsätter efter lanseringen genom kontroll av faktisk användning, relevanta rättelser och tydlig kommunikation. Den är inte avslutad när en designpolicy har undertecknats.

Ett internt mottagningstest och verktygets gräns

Välj en risk och låt en oberoende kollega följa den till krav, design, genomförande, test och beslut. Lägg in en testkopia med en rapport för fel version. Granskaren ska upptäcka att den inte stöder slutsatsen. Pröva även om en öppen begränsning kan hittas och förstås. Dessa frågor mäter kvaliteten på arbetsflödet, inte produktens fullständiga överensstämmelse med CRA.

Pulsar kan koppla risker, uppgifter och underlag så att denna granskning går att följa. Utvecklingsverktyg och tekniska specialister genomför konstruktion och tester. Organisationen behöver bedöma juridiska frågor och godkänna resultaten. Ett tydligt samband mellan risk och verifiering gör produktarbetet mer granskningsbart, men det ska aldrig marknadsföras som en garanti för frånvaro av sårbarheter eller automatiskt godkänd certifiering.

Granska en ändring som gör produkten enklare att använda

En ny bekvämlighetsfunktion kan ändra riskförutsättningarna även om den inte marknadsförs som en säkerhetsändring. Anta att ett installationssteg tas bort eller att ett gränssnitt aktiveras automatiskt. Produktteamet behöver bedöma vilken kontroll steget tidigare gav och vad som ersätter den. Jämför faktisk användning före och efter ändringen och ange vilka tester som ska verifiera det nya beteendet.

Bevara motiveringen även när ändringen bedöms ha liten betydelse. En senare granskare kan då se att frågan faktiskt hanterats. Om det saknas tekniskt underlag bör beslutet innehålla en öppen verifieringsuppgift i stället för ett antagande om att användbarhet och skydd alltid förbättras samtidigt. En tydlig avvägning hjälper teamet att välja en lösning som fungerar för avsedd användning utan att oavsiktligt ta bort relevant kontroll.

Prova också om användarinformationen fortfarande beskriver rätt beteende efter ändringen. En äldre instruktion kan skapa nya risker när kunden följer steg som inte längre finns eller missar en ändrad förutsättning.

Relaterad vägledning

Källor

Källor kontrollerade: 2 oktober 2026. De praktiska testerna och exemplen ovan är redaktionella förslag, inte nya rättsliga krav.

Pulsar GRC — åtkomst, dataisolering och export (polska)