Multifaktorautentisering, ofta kallad MFA, är en andra kontroll utöver ett lösenord: en kod från en app, ett SMS eller en fysisk nyckel. Frågan om detta är obligatoriskt för ett mjukvaruföretag kan inte besvaras med ett enkelt ja eller nej, eftersom NIS2-direktivet inte föreskriver någon specifik teknik. Artikel 21 förpliktar organisationer som omfattas av säkerhetskravet att vidta lämpliga åtgärder för åtkomstkontroll och multifaktorautentisering, och tillsynsmyndigheter tittar på var risken är störst.
För ett mjukvaruföretag är det i praktiken två helt olika platser: utvecklingsledningen som ni själva arbetar med, och mjukvaran som ni levererar till kunder. Båda kräver en egen bedömning, och den bedömningen är inte lika streng överallt.
Två platser där multifaktorautentisering spelar en roll
Den första platsen är internt: miljön där era utvecklare arbetar. Källkod, utvecklingsledningen, molnkonsoler och systemen som ni använder för att distribuera till produktion. Den andra platsen finns i själva produkten: om mjukvaran som ni utvecklar eller levererar har en inloggningsskärm, är multifaktorautentisering även där ett ämne, både för era egna användare och för era kunders slutanvändare. En säkerhetsfrågelista från en uppdragsgivare frågar nästan alltid om båda, ofta i separata frågor som är formulerade lite annorlunda än vad ni skulle förvänta.
Vid åtkomsten till er utvecklingsledning
Här ligger den starkaste förväntningen. Vem som kan komma till källkoden, vem som kan distribuera till produktion och vem som har administratörsrättigheter i molnmiljön utgör den största risken om ett lösenord bara blir stulet eller återanvänt. För dessa konton gäller multifaktorautentisering i nästan alla säkerhetsstandarder som en grundåtgärd, och det är också vad tillsynsmyndigheter och kunder förväntar sig först. Versionshantering, själva utvecklingsledningen och i synnerhet varje konto med rättigheter att distribuera kod till produktion, hör i praktiken utan undantag hemma bakom ett andra steg.
Det är också viktigt att titta på vem som faktiskt fortfarande behöver denna åtkomst. En dokumentation som visar för varje system vem som får åtkomst och varför gör det lättare att svara på denna fråga i en frågelista med ett konkret svar istället för ett antagande. hur åtkomstkontroll och multifaktorautentisering förklaras per ämne ger ett startpunkt för det.
Vid mjukvaran som ni levererar
Det andra området är själva mjukvaran. Om er produkt har en inloggningsfunktion, dyker frågan om ni tillhandahåller multifaktorautentisering nästan alltid upp i en säkerhetsfrågelista, och ibland till och med som ett avtalskrav. Det är en annan bedömning än för er egen utvecklingsledning: här handlar det inte om vad ni själva använder, utan om vad ni levererar till er kund. En uppdragsgivare som själv omfattas av säkerhetskravet måste enligt artikel 21 även bedöma sin leverantörskedja, och frågan om er produkt stöder stark autentisering hör till det.
Svaret behöver inte vara att det är obligatoriskt överallt. Ofta räcker det att visa att möjligheten finns, att användare uppmuntras att använda det, och att ni har en plan för att utöka det där risken motiverar det.
Där det är mindre självklart
Inte alla konton eller miljöer kräver samma nivå av säkerhet. En testmiljö utan verklig kunddata, ett internt dokumentationssystem med endast läsrättigheter, eller ett fristående verktyg som en utvecklare använder då och då, vägs annorlunda än ett konto med åtkomst till produktion. Skyldigheten att vidta lämpliga åtgärder kräver åtgärder som motsvarar riskerna, inte att lägga samma tunga skyddslager överallt. Tillsynsmyndigheter bedömer detta på grundval av proportionalitet, och det innebär att ett väl motiverat val att inte tillämpa flerfaktorsautentisering någonstans kan vara en lika väl dokumenterad del av en säkerhetsmapp som de ställen där den väl används.
Motiveringen är här det viktigaste ordet. Ett val utan förklaring verkar snabbt som en utelämning i en frågelista, medan samma val med en kort begäran ofta är precis det svar en uppdragsgivare söker.
Vad detta innebär för samtalet med en uppdragsgivare
En uppdragsgivare som skickar en frågelista vill vanligtvis inte veta om du uppfyller alla detaljer, utan om du vet var dina risker ligger och hur du hanterar dem medvetet. För flerfaktorsautentisering betyder det: kunna visa vad som finns på utvecklingssidan, vad som finns i produkten, och varför resten är organiserad annorlunda. Den som har dokumenterat detta per system med en status och en ansvarig behöver inte söka upp frågan på nytt nästa gång en ny frågelista kommer in.
Hur detta exakt fungerar för din egen organisation beror på din roll i leverantörskedjan och vad dina kunder specifikt frågar; rådfråga vid osäkerhet texten i richtlinjen själv eller en rådgivare. Om du först vill veta var du står, ger den kostnadsfria kontrollen på några frågor en första indikation, och en förklaring av var informationen kommer ifrån visar hur denna indikation kommer fram.
Om du vill läsa bredare hur detta ämne hänger ihop med de andra åtgärderna från säkerhetskravet, hittar du det i översikten över ämnen per situation. Snabbskannningen och kunskapsdatabasen är fritt tillgängliga, utan att du behöver skapa ett konto.