SASE flyttar kontrollen, inte ansvaret

Allt fler säkerhetsfunktioner flyttar från utrustning i egna lokaler till en leverantörs moln. SASE och SSE är samlingsnamnen: brandvägg, webbfiltrering och fjärråtkomst som tjänst, från en nod nära användaren i stället för en box i serverrummet.

För de flesta är det ett lyft. Men allt flyttar inte med. En del av det ni ansvarar för hamnar hos leverantören, en del blir kvar hos er, och leverantörens intyg täcker bara deras del.

Det som blir bättre

En vpn-koncentrator släpper in användaren på ett nät, och därefter avgör nätets uppbyggnad hur långt någon kommer. Med zero trust-åtkomst förmedlas en session till en enskild applikation i stället, och användaren hamnar aldrig på nätet. För fjärråtkomst är det en reell minskning av hur långt ett stulet lösenord räcker.

Till det kommer att en etablerad leverantör uppdaterar plattformen löpande (4 kap. 31 §), testar den (27 §), loggar (22 §) och har fungerande återställning (28 §), och kan visa ett revisionsutlåtande från tredje part på att det stämmer. Ett motsvarande underlag för egen drift är svårare att få fram.

Ansvaret följer inte med

Föreskriftens krav ligger på er, också när någon annan sköter driften. 4 kap. 1 § andra stycket:

Verksamhetsutövaren ska säkerställa att de krav som ställs på verksamhetsutövaren i denna författning uppfylls av leverantören utom i de delar kravet i sin helhet uppfylls av verksamhetsutövaren.

Undantaget är nyckeln. Kravet stannar hos er där ni uppfyller det i sin helhet själva. I övrigt är det leverantören som ska uppfylla det, och ni som ska säkerställa att det blir gjort.

Två saker uppfyller ni fortfarande själva, och ingen leverantörscertifiering täcker dem. Det ena är er egen konfiguration i tjänsten: vilka regler ni skrev, vilka undantag ni beviljade, vem som är administratör. Det andra är utrustningen som står kvar hos er och kopplar upp mot molnet: tunnlarna från era siter och integrationen mot katalogtjänsten.

Ett exempel på var det får betydelse. 4 kap. 25 § andra stycket kräver att autentiseringsuppgifter skyddas med kryptering vid överföring inne i den digitala miljön. Leverantören intygar kryptering i sin tjänst. Om något på er sida av länken skickar uppgifterna i klartext står det ingenstans i det intyget. Samma sak gäller vilka flöden ni har godkänt (11 §) och vilka förinställda konton som är kvar (13 §).

EU och var trafiken tar vägen

Den vanligaste frågan vi får är om kraven tvingar er att hålla trafiken inom EU. Föreskriften ställer inga krav på var informationen får behandlas. Ordet suveränitet förekommer en gång i hela texten, i ett allmänt råd till 4 kap. 2 §:

Verksamhetsutövaren bör även beakta myndigheters rekommendationer som syftar till att stärka EU:s och Sveriges digitala suveränitet.

Det är ett råd, och det säger inte att trafiken ska termineras inom EU.

Stödet för den frågan ligger någon annanstans, och 1 kap. 2 § är dörren: ”Om annan författning innehåller bestämmelser som ställer högre krav än kraven i dessa föreskrifter tillämpas den bestämmelsen.” För en del verksamheter är det säkerhetsskyddslagstiftningen som avgör var information får behandlas. Första frågan är alltså vilken författning som träffar er.

En sak till för den som tänkt luta sig mot certifiering: för molntjänster finns ännu ingen antagen europeisk ordning att certifiera sig mot. EUCS är fortfarande ett kandidatsystem, blockerat i flera år av just frågan om datalagring inom EU. En ISO 27001-certifiering är inte en certifiering enligt cybersäkerhetsakten, hur bra den än är.

Fyra frågor att ta med till leverantören

• Var termineras trafiken, var ligger administrationsgränssnittet, och var sparas loggarna och hur länge?
• Hur mycket av det går att skriva in i avtalet?
• Vilka av föreskriftens krav säger leverantören sig uppfylla, och var i utlåtandet står det?
• Vad förutsätter leverantören att ni sköter själva efter införandet?

Svaret på den sista är er del: konfigurationen i tjänsten och utrustningen hos er. Den täcks inte av leverantörens intyg, och det är den som behöver kontrolleras på plats.

Så tänker vi

En policy i en leverantörskonsol beskriver vad som ska hända. 4 kap. 27 § frågar efter något annat: att valda konfigurationer har införts. Det syns i trafiken, men bara åt ena hållet. Ser vi ett flöde som policyn säger inte ska finnas är det ett belägg för att den inte gäller. Att vi inte ser något är inget belägg för att den gäller.

Vi utformar och leder den här sortens förändring, och vi säljer inga licenser. Vi är inte återförsäljare för någon tillverkare och får ingen ersättning för vad ni väljer. Det är därför en jämförelse mellan två plattformar kan vara just en jämförelse.

Vill ni veta vad som är nåbart idag, före och efter ett byte? Hör av er.

Källor: MCFFS 2026:11, 1 kap. 2 §, 4 kap. 1 §, 2 §, 25 § och 27 §, kontrollerade mot källan den 20 september 2026. EUCS-statusen är kontrollerad mot ENISA och cep. Där vi drar en slutsats skriver vi ut det. Det här är inte juridisk rådgivning.