Publicerad 9 oktober 2026

Sammanfattning: SFTP och korrekt konfigurerad FTPS skyddar överföringen mellan klient och server, men filen är inte krypterad hos servern som tar emot den. Överföringsservern kan läsa innehållet. Kryptering av lagrad data är en separat kontroll och gör inte heller överföringen end-to-end-krypterad. För många filflöden räcker det – men om leverantören inte ska kunna läsa innehållet måste filen krypteras innan den lämnar er, och det är ett krav ni behöver skriva in, inte hoppas på.

”Är överföringen krypterad?” är en av de vanligaste frågorna i en leverantörsgranskning, och nästan alltid får den svaret ja. Frågan som avgör saken ställs mer sällan: vem kan läsa filen?

Vad TLS och SSH faktiskt skyddar

SFTP körs över SSH och FTPS över TLS. Båda skyddar kanalen mellan klienten och servern: någon som lyssnar på nätet ser att en anslutning finns, men inte vad som skickas i den, och kan inte ändra innehållet på vägen utan att det upptäcks.

Sedan tar kanalen slut. Servern dekrypterar det den tar emot, för annars kan den inte lägga filen i rätt mapp, validera formatet, trigga ett flöde eller lämna den vidare till nästa system. Att lagringen är krypterad ändrar inte det: kryptering av lagrad data skyddar mot vissa former av obehörig åtkomst till lagringsmediet, till exempel en stulen disk, men inte mot en administratör eller applikation som har behörighet att läsa mappen.

Vad end-to-end-kryptering betyder

End-to-end-kryptering innebär att bara ändpunkterna har klartexten. Avsändaren krypterar med mottagarens nyckel, och det som passerar däremellan – nätet, servern, driftleverantören – har inte nycklarna och kan därför inte läsa innehållet ens om det ville. Det är modellen i krypterade meddelandetjänster, och det är också vad PGP-krypterade filer gör i ett filflöde.

Skillnaden är inte akademisk. Den avgör framför allt om leverantören tekniskt kan komma åt innehållet i klartext.

Varför skillnaden spelar roll i praktiken

Personuppgiftsbiträdet har faktisk åtkomst. När plattformen kan läsa innehållet räcker det inte att konstatera att det finns ett biträdesavtal – ni behöver veta vilka roller som kan öppna filerna, vilka underbiträden som är inblandade och var behandlingen sker.
En incident hos leverantören omfattar era filer. Om plattformen komprometteras är det inte bara metadata som exponeras. Med end-to-end-kryptering hade angriparen fått krypterade filer utan nycklar.
”Krypterat” i en svarsblankett betyder oftast transportkryptering. Det är inte fel svar, men det svarar på en annan fråga än den ni ställde om ni ville veta om leverantören kan läsa innehållet.

När ni faktiskt behöver end-to-end

För många vanliga filflöden behövs inte end-to-end-kryptering. För dem ger transportkryptering tillsammans med stark autentisering, snäva behörigheter, god nyckelhantering och loggning ett tillräckligt skydd för själva överföringen och åtkomsten. Det som oftare går fel ligger runt omkring: filer som mejlas i stället för att gå genom flödet, filer som hamnar hos fel mottagare och konton som ligger kvar efter att någon slutat. Det löser ni med ett styrt flöde med ägare och rutiner, inte med end-to-end-kryptering.

Det finns däremot flöden där kravet är rimligt: känsliga personuppgifter som ska passera en extern part utan att den parten behöver innehållet, material där källskydd eller tystnadsplikt gäller, och information som är kurskänslig eller under embargo. Lösningen är då att kryptera filen innan den laddas upp – PGP eller motsvarande – och att nyckelhanteringen ligger hos er och mottagaren, inte hos plattformen.

Priset ska sägas rakt ut: en fil som plattformen inte kan läsa kan den inte heller validera, konvertera eller söka i, och en tappad nyckel innebär att filen är borta. Kryptering före uppladdning är därför ett medvetet val för utpekade flöden, inte en generell inställning.

Hur ni skriver kravet

Ett krav formulerat som ”filöverföringen ska vara end-to-end-krypterad” får ni ja på från leverantörer som menar TLS. Formuleringen behöver i stället säga vad ni vill uppnå:

Filen ska vara krypterad innan den lämnar vår miljö, och leverantören ska inte ha åtkomst till klartext eller nycklar.
Ange vilka roller hos leverantören som tekniskt kan läsa innehållet, och hur den åtkomsten loggas.
Ange vilka protokoll och versioner som används för transporten, exempelvis TLS 1.2 eller senare, och hur lagringen är krypterad.

Samma tre punkter fungerar när någon granskar er. Svara med vad ni har – transportprotokoll, lagringskryptering och vilka roller som kan läsa – i stället för att sträcka ordet end-to-end längre än det räcker. Den som kan skillnaden litar mer på det svaret, och den som inte kan den blir hjälpt av att få den förklarad.

Vill ni gå ett steg djupare i valet mellan protokollen och plattformarna har vi skrivit om SFTP, FTPS och MFT och när respektive lösning passar.

Vi hjälper organisationer att sätta upp och förvalta säker filöverföring med kryptering, behörigheter, loggning och automatiserade flöden. Vill ni gå igenom hur era filflöden ser ut i dag är ni välkomna att kontakta oss.

Källor: ISO/IEC 27001:2022, bilaga A.8.24 om användning av kryptografi och A.8.12 om skydd mot dataläckage; NIST SP 800-52 Rev. 2 om konfiguration av TLS; Integritetsskyddsmyndighetens vägledning om säkerhetsåtgärder vid behandling av personuppgifter.

Den här texten är allmän information och utgör inte juridisk rådgivning i ett enskilt ärende.