NIS2 og virksomhedsmobiler (den del alle glemmer at få styr på)

Kollegaen der lige tjekker mail på egen mobil i toget. Teams-mødet fra køkkenbordet på en privat iPhone. Android-telefonen i lageret der aldrig bliver opdateret. SMS med engangskoder på en u låst mobil.

Hvis du nikkede til mindst et punkt, så er dine virksomhedsmobiler en reel NIS2-risiko, uanset hvor flot jeres policy-dokumenter ser ud.

Hvem rammes af NIS2 – og hvorfor mobilerne pludselig betyder mere end før

NIS2 er EU-direktivet, der stiller skrappere krav til cybersikkerhed hos en lang række væsentlige og vigtige virksomheder. Det handler ikke kun om datacentre, firewalls og krypterede backups. Mobiltelefonerne er også en del af angrebsfladen.

Hvis din virksomhed er omfattet af NIS2 (eller leverer til nogen der er), skal du kunne vise, at du har styr på bl.a.:

• risikostyring
• adgangsstyring
• patch management (opdateringer)
• incident response
• leverandører og tredjepartsadgang

Alle de punkter rammer direkte ned i jeres mobilflåde. For de fleste virksomheder er telefonen i dag:

• nøgle til mail, Teams, SharePoint, CRM osv.
• MFA-enhed (godkendelse via app eller SMS)
• bærbar lagerplads for dokumenter, billeder og chats

Så hvis du kun tænker NIS2 på servere, netværk og laptops, og lader mobilerne sejle, ender du med en kæmpestor bagdør. Det er lidt som at have en sikkerhedsdør i stål og så lade vinduet stå på klem.

Minimumskrav du bør have på alle virksomhedsmobiler

Lad os starte med bunden af sikkerhedspyramiden. Det her er ting, jeg ærligt talt mener, du bare skal beslutte dig for er standard. Ikke lange diskussioner. Ikke “måske senere”.

Skærmlås, biometrisk, auto-lock og brute-force beskyttelse

Hvis mobilen bliver stjålet fra en togkupé, en taxa eller kantinen, er det første forsvar skærmlåsen. Her er et fornuftigt NIS2-niveau i praksis:

• PIN-kode eller kodeord: Minimum 6 cifre, gerne alfanumerisk kode til højrisko-roller (ledelse, økonomi, IT).
• Biometri: Face ID / fingerprint er ovenpå koden, ikke i stedet for. Slå det til, men sørg for at kode stadig kræves ved genstart.
• Auto-lock: Maks 2 minutter. Til følsomme funktioner (bank, ERP, admin-apps) giver det mening at køre 30 sekunder.
• Brute-force beskyttelse: På både iOS og Android kan du sætte automatisk sletning eller længere ventetid efter X forkerte forsøg. Brug det.

Sådan implementerer du det:

• Central håndhævelse via MDM (Mobile Device Management) som f.eks. Intune, MobileIron, Workspace ONE osv.
• Lav én baseline-policy for alle og en skærpet policy for “high risk” brugere.

Sådan dokumenterer du det til NIS2:

• En kort “Sikkerhedskrav til mobiler”-policy, der beskriver minimumskrav.
• Screenshot eller eksport fra MDM, der viser konfigurerede policies.
• Evt. en årlig kontrolrapport: “Password/lockscreen policy gennemgået og verificeret”.

Kryptering: hvad er “god nok” på iOS og Android

Hvis en mobil bliver stjålet, skal du med ro i maven kunne sige: “Ja, men data på den er krypteret og adgangsbeskyttet”.

iOS (iPhone og iPad):

• En moderne iPhone (fra ca. iPhone 8 og frem) har fulddisk-kryptering aktiveret, så snart du sætter en kode på.
• Her handler “kontrollen” mest om at sikre, at der faktisk er kode, og at enheden ikke er jailbroken.

Android:

• Nyere Android-enheder har som udgangspunkt kryptering, men det kan variere mellem producenter.
• Tjek at “Device Encryption” eller “File-based encryption” er slået til via MDM og ikke kan slås fra af brugeren.
• Overvej at forbyde ældre Android-versioner, hvor kryptering er svagere eller valgfri.

Sådan implementerer du det:

• MDM-policy: “Kryptering krævet” på alle devices.
• Compliance-regler: Enheder uden kryptering må ikke få adgang til mail, SharePoint osv.

Sådan dokumenterer du det til NIS2:

• Beskrivelse i mobil-sikkerhedspolitik: “Alle virksomhedsmobiler skal være krypterede”.
• MDM-rapport der viser antal/andel krypterede enheder.
• Beskrivelse af min. OS-versioner, du accepterer (fx “Android 11+”, “iOS 16+”).

OS- og app-opdateringer (patch management på mobiler)

Patch management er et nøgleord i NIS2. På dansk: får du rent faktisk installeret sikkerhedsopdateringer i tide? Her er mobilen ofte overset, selvom den typisk har:

• mail med bilag
• Teams/Slack med links og filer
• adgang til SharePoint, OneDrive, Google Drive osv.

Mit anbefalede niveau:

• Fast minimums-OS-version, som MDM håndhæver.
• Auto-opdatering af apps slået til som standard.
• Regel om at sikkerhedsopdateringer skal være installeret senest X dage efter release (typisk 7-14 dage).

Sådan implementerer du det:

• Sæt compliance-regler i MDM: Enheder der er over f.eks. 30 dage bagud med OS patches, bliver markeret usikre.
• Brug “Conditional Access” (mere om det om lidt) til at blokere usikre enheder fra følsomme systemer.
• Planlæg månedlige eller kvartalsvise reviews af enhedsstatus.

Sådan dokumenterer du det til NIS2:

• Patch-policy for mobiler med klare tidsfrister.
• Rapporter fra MDM om OS-versioner og compliance over tid.
• Evt. notat om særlige undtagelser (gamle special-enheder) og hvordan du kompenserer for dem.

MDM/MAM: de vigtigste policies du bør slå til

Hvis du skal kunne styre og dokumentere noget som helst for NIS2, kommer du ikke uden om et MDM/MAM-setup. Ellers er det bare “vi tror nok folk gør det rigtige”. Det er sjældent nok til en audit.

Jeg nævner typisk værktøjer som Microsoft Intune, Jamf, Workspace ONE, MobileIron osv. Pointen er ikke brandet, men det, du kan gøre med dem.

Conditional Access + MFA på mobilen

De fleste NIS2-relevante virksomheder kører allerede MFA til Office 365, VPN osv. Men mange har ikke helt fået styr på, at mobilen ofte er en del af problemet:

• Brugere godkender MFA på en usikret privat mobil.
• En gammel Android uden opdateringer har stadig fuld mailadgang.
• En stjålet iPhone med åben mail, Teams, OneDrive og CRM.

Minimum jeg vil anbefale:

• MFA som krav til alle cloud-tjenester med følsomme data (mail, filer, CRM osv.).
• Conditional Access, der tjekker enhedens sikkerhedsstatus før adgang gives.
• Blokering af ukendte enheder eller enheder uden MDM-kontrol.

Sådan implementerer du det teknisk (typisk med Intune/Entra ID som eksempel):

• Registrer alle virksomhedsmobiler som managed devices i MDM.
• Opret Conditional Access policies: “Kun compliant devices må tilgå mail/SharePoint/Teams”.
• Definér, hvad “compliant” betyder: kryptering, skærmlås, max OS-aldersgrænse osv.

Sådan dokumenterer du det til NIS2:

• Beskrivelse af MFA-krav i jeres adgangsstyringspolitik.
• Oversigt over Conditional Access regler (evt. skærmbilleder).
• Notat om, hvordan I håndterer undtagelser (f.eks. servicekonti, specialenheder).

App-whitelisting, blacklisting og “unknown sources” på Android

Her begynder vi at rydde op i app-zooen. For NIS2 giver det mening at kunne sige:

• “De her apps bruger vi og stoler på”
• “De her apps må ikke installeres på virksomhedens enheder”
• “Vi tillader ikke installation fra ukendte kilder” (særligt Android)

På Android:

• Deaktiver “Unknown sources” / installation fra APK-filer.
• Brug Managed Google Play via MDM til at styre, hvilke apps der må installeres.
• Lav en whitelist til arbejdsapps (mail, Teams, CRM, lagerstyring, scanner osv.).

På iOS:

• Brug VPP / Managed apps via MDM, så du kan styre, hvilke apps er “arbejdsapps”.
• Overvej om du vil blokkere bestemte typer apps (torrent, jailbreak-værktøjer osv.).

Sådan dokumenterer du det:

• Liste over godkendte arbejdsapps (evt. i en bilag til mobilpolitikken).
• Policy der beskriver, at installation fra ukendte kilder er forbudt.
• MDM-konfig der viser, at “unknown sources” er slået fra på Android.

Container/Work Profile på Android og managed apps på iOS

Hvis du har BYOD (Bring Your Own Device), er det her din redning. I stedet for at prøve at styre hele brugerens private mobil, opretter du en “arbejdsboble” på enheden.

Android Work Profile:

• En separat arbejdsprofil på brugerens mobil.
• Arbejdsapps og -data ligger i en krypteret container, du kan styre.
• Du kan fjernslette arbejdsprofilen uden at slette brugerens private billeder osv.

iOS managed apps & data:

• Du “ejer” og styrer bestemte apps (mail, OneDrive, Teams osv.) via MDM.
• Du kan forhindre copy/paste fra arbejdsapps til private apps.
• Du kan fjerne adgang og data fra arbejdsapps uden at wipe hele enheden.

Hvorfor det er NIS2-relevant:

• Risikostyring: Du reducerer risikoen ved private devices.
• Adgangsstyring: Du har stadig kontrol over, hvem der har arbejdsdata på mobilen.
• Incident response: Du kan reagere hurtigt ved fratrædelse eller mistanke.

Hvis du vil nørde endnu mere mobil sikkerhed generelt, kan du også læse vores indlæg om sikker mobil i hverdagen, men her holder vi fokus på NIS2-vinklen.

Logging, incident response og fjernsletning (wipe)

NIS2 handler ikke kun om at forebygge. Du skal også kunne opdage og reagere, når noget går galt. Mobiler er her lidt tricky, fordi:

• de ofte er uden for virksomhedens netværk
• brugeren selv opdager tyveri/tab først
• logs ligger spredt mellem MDM, mail, identitetsplatform osv.

Hvad du som minimum bør kunne

• Se, hvilke enheder der har adgang til virksomhedens tjenester.
• Stoppe en enheds adgang hurtigt (disable account / revoke sessions).
• Fjernslette en enhed eller arbejdsprofil (wipe).
• Se basale sikkerhedshændelser: jailbreak/root, mistet compliance, mange fejlede loginforsøg.

Incident-scenarier du bør have en plan for:

• Mobil mistet eller stjålet.
• Medarbejder fratræder pludseligt (evt. i konflikt).
• Enhed mistænkes for at være kompromitteret (malware, phishing, usædvanlig aktivitet).

Sådan gør du det operationelt:

• Sørg for at IT (eller den ansvarlige) har hurtig adgang til MDM og identitetsstyring 24/7.
• Lav en kort playbook: “Hvis en telefon forsvinder, gør vi 1) disable konto, 2) remote wipe, 3) dokumentér hændelsen”.
• Træn servicedesk eller driftsfolk i at udføre de her skridt uden at skulle ringe til en konsulent hver gang.

Sådan dokumenterer du det til NIS2:

• En simpel incident-procedure specifikt for mobiler.
• Eksempel på en log fra en faktisk (eller test) hændelse.
• Beskrivelse af, hvordan mobil-logs kobles med øvrige sikkerhedslogs (SIEM, SOC osv.).

Du kan evt. koble det her sammen med jeres generelle beredskabsplan, som vi skriver om i vores artikel om beredskab i erhvervstelefoni.

BYOD vs COPE vs COBO – hvilken model kan du reelt styre?

Nu rammer vi en af de større diskussioner: Hvem ejer mobilen? Og hvor meget må du styre?

De tre klassiske modeller:

• BYOD (Bring Your Own Device) – medarbejderen ejer telefonen.
• COPE (Corporate Owned, Personally Enabled) – virksomheden ejer, men den må også bruges privat.
• COBO (Corporate Owned, Business Only) – ren arbejds-telefon.

Min erfaring:

• BYOD er fleksibel, men svær at styre stramt nok til NIS2, hvis mobilen har fuld adgang til mail, filer og systemer.
• COPE er ofte det bedste kompromis: du ejer enheden og kan kræve MDM, men medarbejderen kan stadig have privatliv.
• COBO giver mest kontrol, men er upraktisk for mange roller og bliver ofte omgået i praksis.

Hvis din virksomhed er NIS2-omfattet, vil jeg typisk anbefale noget i stil med:

• Ledelse, økonomi, IT og andre højrisko-roller: COPE eller COBO.
• Almindelige kontorroller: COPE eller stramt styret BYOD med work profile/managed apps.
• Feltarbejde/produktion: COBO eller COPE med stærke begrænsninger (scannere, lagerapps osv.).

Det vigtigste er, at du kan svare klart på:

• Hvem må bruge privat mobil til arbejde, og på hvilke vilkår?
• Hvad kræver I af dem (MDM, kode, opdateringer, remote wipe-accept)?
• Hvad gør I, hvis de ikke vil acceptere de vilkår?

Og ja, her kommer jura og HR også i spil. NIS2 er ikke bare et IT-projekt, det er et organisationsprojekt. Så få jeres jurist eller compliance-ansvarlige med om bord, inden I ændrer alt for meget.

Dokumentation du kan lave på 1 dag

Hvis du lige nu sidder og tænker “vi har ikke tid til en halv romans værdi af politikker” så er her en mere jordnær tilgang. Få styr på det vigtigste først.

1. En kort mobil-sikkerhedspolitik (max 3-4 sider)

Den skal beskrive:

• Hvem må få en virksomhedsmobil.
• Hvilke sikkerhedskrav der gælder (kode, kryptering, opdateringer osv.).
• Hvordan I håndterer BYOD vs COPE vs COBO.
• Hvad medarbejderen forpligter sig til (melde tab/tyveri hurtigt, ikke jailbreake osv.).

Brug almindeligt sprog. Det skal være noget, en travl sælger faktisk gider læse, ikke kun noget til audit-mappen.

2. Et teknisk kontrol-katalog til IT

Her skriver du ned, hvad MDM rent faktisk skal håndhæve. Det kan være i tabel- eller punktform, f.eks.:

• Skærmlås: minimum 6-cifret PIN, auto-lock max 2 minutter.
• Kryptering: krævet på alle enheder, ellers ingen adgang.
• OS-version: minimum iOS 16 / Android 11.
• Opdateringer: sikkerhedsopdateringer max 14 dage gamle.
• MFA: krævet til mail, Teams, SharePoint, CRM.
• App-styring: kun godkendte arbejdsapps i managed profil.
• Unknown sources (Android): deaktiveret.
• Remote wipe: muligt for alle managed enheder.

Det her dokument er guld, når du skal tale med både revisor, leverandører og din egen ledelse om, hvad I “faktisk gør”.

3. En simpel ansvarsfordeling

Meget NIS2 falder fra hinanden, fordi ingen helt ved, hvem der har bolden. Så skriv 1 side, hvor du svarer på:

• Hvem er systemejer for MDM og mobilpolitikken?
• Hvem må godkende nye typer apps til virksomheden?
• Hvem reagerer på alarmer og incident på mobiler (fx tab, tyveri, kompromittering)?
• Hvem følger op på compliance-rapporter hver måned/kvartal?

Det behøver ikke være smukt, bare klart.

4. Et kort disclaimer-afsnit (vigtigt)

Til sidst: Husk, at teknisk opsætning ikke i sig selv er lig med juridisk NIS2-compliance. Brug en linje eller to i jeres dokumenter til at skrive noget i stil med:

“Denne beskrivelse omhandler den tekniske sikring af virksomhedens mobiltelefoner. Den erstatter ikke juridisk vurdering af NIS2, og skal løbende koordineres med virksomhedens overordnede informationssikkerhedspolitik og juridiske rådgivning.”

Det samme gælder denne artikel: Jeg kan hjælpe dig med den tekniske og praktiske del, men du bør altid spille bolden videre til jeres juridiske/compliance-ansvarlige, før du lægger dig fast på endelige løsninger.

Hvad gør du så i morgen?

Hvis jeg stod i din stol med NIS2 og en bunke virksomhedsmobiler foran mig, ville jeg gøre det her i morgen:

• Trække en rapport fra MDM (eller mailsystemet), så jeg ved, hvor mange enheder der er i spil, og hvilke typer.
• Bestemme mig for en model: BYOD, COPE, COBO – og skrive det kort ned.
• Skærpe de 3 vigtigste policies: skærmlås, kryptering, OS-minimum.
• Slå Conditional Access til for mail og filer, så kun sikre enheder får adgang.
• Skitsere en 1-sides incident-procedure for tabte/kompromitterede mobiler.

Når det første lag er på plads, kan du bygge videre med finere granulære regler, bedre logging og tættere integration til jeres øvrige sikkerhedsarbejde. Hvis du vil have mere inspiration til, hvordan telefoner spiller sammen med resten af jeres it-setup, kan du også kigge på vores artikel om Teams-telefoni i virksomheden.

Jeg plejer at sige: Du behøver ikke være perfekt for at være markant mere sikker end i dag. Spørgsmålet er mere, hvor moden jeres mobil-sikkerhed skal være, den dag nogen faktisk spørger ind til jeres NIS2-setup. Om et par år tror jeg, at forskellen mellem “vi gjorde det minimumsnødvendige” og “vi tog mobilflåden seriøst” bliver meget tydelig.