Da jeg første gang låste 40 firmamobiler på én gang (og hvad jeg ville gøre anderledes i dag)

• Medarbejderen der siger “jeg kan da bare bruge WhatsApp”
• Firmamobilen med 4-cifret kode, som alle i teamet kender
• “Jeg skal nok opdatere den senere” på en 3 versioner gammel Android
• Den tidligere medarbejders iPhone der stadig står som “Marias mobil” i iCloud

Hvis du nikkede til mindst et punkt, så er du præcis den type virksomhed, der får meget ud af at få styr på jeres MDM politikker til firmamobiler.

MDM til firmamobiler i virkeligheden: Hvad er problemet, du prøver at løse?

Jeg har efterhånden talt med en del små og mellemstore virksomheder, hvor MDM enten er blevet et kæmpe kontrolværktøj, som alle forsøger at slippe uden om, eller noget man “har købt”, men aldrig rigtig har sat ordentligt op. Sandheden ligger et sted imellem: Du behøver ikke 117 regler for at være nogenlunde sikker, men du kan heller ikke nøjes med “brugerne passer på”.

MDM (Mobile Device Management) handler i bund og grund om tre ting:

• At kunne styre, hvad der sker, hvis en mobil bliver væk eller stjålet
• At sikre, at enhederne ikke er håbløst usikre (gamle versioner, svag kode osv.)
• At skille arbejde og privatliv nogenlunde ad, især hvis det er BYOD

De klassiske trusler, du forsøger at beskytte jer mod, er ikke “hemmelig stats-spionage”, men meget mere kedelige ting som:

• En sælger der mister en Android med åbent mailprogram og kundedata
• En leder der godkender løn i en app på en rooted mobil
• En tidligere ansat der stadig kan læse Teams-beskeder på sin gamle iPhone

Her giver det mening at tænke i et “minimums-setup”: Hvad er det mindste sæt MDM politikker for firmamobiler, som faktisk flytter jer fra “vi krydser fingre” til “vi kan sove nogenlunde roligt om natten”.

Hvis I er underlagt strengere krav, fx pga. NIS2, så skal I et skridt længere. Jeg har skrevet om det i en mere regulerings-tung vinkel i artiklen om NIS2 og virksomhedsmobiler, men her holder vi fokus på det minimum, der fungerer for de fleste.

Minimumspolitikker der altid bør være slået til

Jeg vil starte med det sæt politikker, jeg helt ærligt aldrig ville undvære, uanset om du bruger Intune, Jamf, Kandji eller noget helt fjerde. De beskytter jer mod de mest almindelige scenarier, og brugerirritationen er til at leve med, hvis man sætter det ordentligt op.

1. Skærmlås og adgangskrav: stærk kode uden at gøre folk vanvittige

Skærmlås er kedeligt, men uundgåeligt. Her ser jeg tit to ekstremer: Enten får alle lov at have 4-cifret pin “for det er hurtigere”, eller også vælger IT 15-tegns kode, som ingen kan overskue i hverdagen.

Et fornuftigt minimum for firmamobiler:

• iPhone: 6-cifret kode som minimum, gerne med Face ID/Touch ID slået til
• Android: 6-cifret pin eller stærk mønsterlås, ansigts- eller fingeraftrykslogin tilladt
• Auto-lås: maks 2-3 minutter uden aktivitet
• Antal forsøg: efter fx 10 forkerte forsøg bliver mobilen låst og kræver IT-hjælp eller kontoadgang

Sikkerhedsværdi: Høj. Det gør ondt på en tyv eller den, der finder mobilen, hvis de ikke bare kan åbne alt.

Bruger-irritation: Lav til mellem. De fleste er vant til kode og biometri privat. Problemet opstår, hvis du sætter skærmlåsetiden for lavt, så sælgeren skal låse op midt i hver eneste kundesamtale.

2. Kryptering: du kan lige så godt gøre det obligatorisk

Både moderne iPhones og de fleste nyere Android-enheder er krypterede som standard, så snart der er en kode på. Her handler MDM-politikken mere om at sikre, at ingen kan slå det fra, og at ældre Android-enheder ikke slipper igennem uden kryptering.

Et minimumskrav i din MDM politik til firmamobiler bør være:

• Enheden skal være krypteret, ellers er den ikke compliant
• Ingen mulighed for at fjerne skærmlås (for så ryger krypteringen typisk også)

Sikkerhedsværdi: Meget høj. Kryptering gør, at selv hvis nogen får fysisk fat i mobilen og forsøger at trække data ud, er det ubrugeligt uden koden.

Bruger-irritation: Nærmest nul. De færreste mærker overhovedet, at kryptering er slået til.

3. OS-opdateringer: stop de værste huller uden at ødelægge driften

Her bliver mange enten for pæne eller for aggressive. Enten er opdateringer helt frivillige (“brugerne har jo travlt”), eller også tvinger man alt igennem dag 1, og så står man med en vigtig business-app, der ikke virker efter en stor iOS-opdatering.

Jeg plejer at anbefale en mellemvej:

• Mindstekrav til OS-version, fx “seneste version minus én”
• En grace-periode, fx 14 dage til at opdatere, før enheden bliver markeret som ikke-compliant
• Opdateringer sker automatisk uden for arbejdstid, hvor det er muligt

Sikkerhedsværdi: Høj, især mod kendte sårbarheder. Mange større angreb rammer enheder, der ikke har fået helt almindelige sikkerhedsopdateringer.

Bruger-irritation: Mellem. Nogle vil brokke sig over, at mobilen “pludselig” opdaterer. Det hjælper meget at kommunikere på forhånd, hvornår det typisk sker, og at der er en frist.

Minimumspolitikker til når noget går galt

Næste pakke handler om, hvad du gør, når skaden er sket: mobilen er væk, medarbejderen stopper, eller en enhed opfører sig mistænkeligt. Det er her, MDM virkelig viser sin værdi.

4. Fjernsletning og lås: hvem må trykke på den røde knap?

Fjernsletning lyder voldsomt, og det kan det også være, især på BYOD. Men på rene firmamobiler er det et must, at du kan:

• Fjerne arbejdsdata (mail, Teams, CRM-apps osv.) ved fratrædelse
• Fjernslette hele enheden, hvis den er stjålet eller umulig at få tilbage
• Fjernlåse enheden, så den ikke kan bruges, selv om nogen har den fysisk

Det afgørende er, at du beslutter, hvem der må godkende fjernsletning (fx IT + nærmeste leder) og hvornår du går fra “fjernarbejdsdata” til “slet alt”. Dokumenter det i jeres politik.

Sikkerhedsværdi: Meget høj ved tyveri og fratrædelse.

Bruger-irritation: Høj, hvis det bruges uden klare regler. Lav, hvis du har tydelig kommunikation og holder fingrene fra BYOD-privatdata (mere om det senere).

5. Backup-krav: hvor må firmadata leve?

Backup er lidt speciel på mobiler, fordi vi ofte ikke vil have, at hele mobilen spejles et sted, hvor vi ikke har styr på sikkerheden. Fokus er typisk:

• At mails, Teams, filer og CRM-data ligger centralt i Office 365, Google Workspace eller lignende
• At vigtige fag-apps har server-side backup, ikke kun lokalt på mobilen
• At brugerne ikke laver private iCloud/Google Drive-backups af arbejdsprofiler eller virksomheds-apps

Din MDM-politik kan fx kræve, at firmadata kun må ligge i godkendte cloud-tjenester, og at synkronisering til tredjeparts-backup er slået fra. Mange MDM-løsninger har kontrolelementer til det.

Sikkerhedsværdi: Mellem til høj. Det handler lige så meget om compliance som ren sikkerhed.

Bruger-irritation: Lav, hvis du forklarer, at deres private billeder og beskeder stadig er deres og ligger i deres egen backup.

6. “Find enhed” og inventar: når 50 mobiler pludselig bare er “ude i marken”

“Find min iPhone” og tilsvarende på Android er ikke kun til privatbrug. Som virksomhed er det guld værd at kunne:

• Se om en mistet mobil ligger på kontoret, i bilen eller et helt tredje sted
• Have styr på, hvilke enheder der overhovedet eksisterer og tilhører hvem
• Se sidste aktivitet, før du vælger fjernsletning

MDM gør det langt nemmere at holde et opdateret device-inventar. Kombiner det med en simpel proces ved ansættelse og fratrædelse (som jeg har skrevet mere om i artiklen om at få styr på mobilrodet), så slipper du for “ej, jeg troede, den mobil var afleveret for længst”.

Sikkerhedsværdi: Mellem. Det hjælper ikke direkte på hacking, men meget på kontrol og hurtig reaktion.

Bruger-irritation: Lav, hvis du ikke bruger det til at overvåge, hvor folk er. Vær eksplicit om, at det ikke er formålet.

App-styring: hvad skal være obligatorisk, og hvad skal være frivilligt?

App-politik er der, hvor konflikterne ofte starter. En ting er kode og kryptering, noget andet er, når IT begynder at slette folks yndlingsapps eller blokere hele Play Store. Her er det vigtigt at skelne mellem:

• Obligatoriske apps: dem, arbejdet ikke fungerer uden
• Beskyttede apps: dem, der håndterer følsomme data
• Privat zone: hvor du blander dig mindst muligt

Obligatoriske apps: “uden dem virker jobbet ikke”

Her taler vi typisk om mail, kalender, Teams/Slack, CRM, tidsregistrering og eventuelt branche-specifikke apps. På firmamobiler giver det mening at:

• Push-installere de apps, der skal være der
• Automatisk konfigurere dem med virksomhedens standardindstillinger
• Gøre det svært, men ikke umuligt, at afinstallere dem (afhængigt af jobtype)

På BYOD går man mere forsigtigt til værks og bruger fx app protection policies (særligt i Microsoft Intune), så firmadata inde i appen kan beskyttes uden at kontrollere hele telefonen.

App protection policies: lås på selve virksomhedens data

Hvis du bruger en løsning som Intune, kan du beskytte de apps, der håndterer firmadata, med ekstra lag:

• Kræve ekstra PIN eller biometri for at åbne apps med firmadata
• Blokere copy/paste fra firmadata til private apps
• Blokere gemning af filer på usikre steder (lokalt, privat cloud osv.)
• Auto-slette firmadata i appen, hvis enhed ikke har tjekket ind i X dage

Det er en god løsning til BYOD, fordi du siger “vi kontrollerer vores data, ikke din telefon”. Og det er også stærkt på firmamobiler, hvis der ligger følsom kunde- eller sundhedsdata.

Hvad du sjældent bør gøre (i hvert fald ikke som det første)

Jeg ser nogle ting, der næsten altid skaber unødigt modtryk:

• Total-blokering af App Store/Play Store til almindelige brugere
• Forbud mod alle sociale medier, selv om de ikke håndterer firmadata
• Overdrevent mange sikkerheds-popups i hver eneste app

Start hellere med styr på de apps, der faktisk indeholder noget vigtigt, og lad resten være, så længe brugerne holder sig inden for almindelig fornuft.

BYOD vs firmatelefon: to setups der faktisk kan fungere

Her bliver det følsomt. Mange mindre virksomheder ender i den der klassiker: “Den dag chefen bad folk bruge deres egen mobil”, og så opdager man, at det både er juridisk, praktisk og menneskeligt mere kompliceret, end det lød i frokostpausen. Hvis du overvejer BYOD, så overvej også at læse den artikel.

Setup 1: Klassisk firmamobil med fuld MDM

Her ejer virksomheden mobilen. Det gør det hele meget nemmere:

• Fuld MDM-styring, inkl. fjernsletning af hele enheden
• Stramme krav til kode, kryptering og opdateringer
• Firmadata og apps kan fjernes ved fratrædelse uden diskussion

Du kan godt tillade privat brug, men vær tydelig: Det er virksomhedens enhed, og I kan i yderste konsekvens slette den helt uden at skulle sortere i private billeder, hvis den bliver stjålet.

Setup 2: BYOD med stram databeskyttelse, mild enhedskontrol

Her ejer medarbejderen mobilen, og det er deres primære privat-enhed. Dit fokus bliver:

• App protection policies på mail, Teams og andre firmadata-apps
• Let enhedskontrol (fx krav om skærmlås, men ikke fuld indsigt i apps og lokation)
• Mulighed for at fjerne firmadata fra apps uden at røre resten af mobilen

Her er det ekstra vigtigt, at du ikke giver dig selv flere rettigheder end nødvendigt. Brug MDM features, der er designet til BYOD, ikke de samme, som du ville bruge på firmamobiler.

Friktions-matrix: hvor meget må det irritere for at være det værd?

En ting jeg ofte gør sammen med små IT-afdelinger, er at lave en lille “friktions-matrix”: En simpel vurdering af hver politik ud fra to akser:

• Sikkerhedsværdi (lav, mellem, høj)
• Bruger-irritation (lav, mellem, høj)

Din første bølge af MDM politikker til firmamobiler bør primært bestå af:

• Høj sikkerhedsværdi + lav irritation: kryptering, skærmlås, minimum OS-version
• Mellem/høj sikkerhedsværdi + lav/mellem irritation: fjernsletning, “find enhed”, app protection

Gem de ting, der både har høj irritation og lav/mellem sikkerhedsværdi, til senere (eller helt drop dem). Det kan være ting som ekstremt korte auto-lås intervaller, forbud mod alle privatapps eller daglige tvungne skift af kode.

Implementeringsplan på 2 uger: minimum først, resten senere

Lad mig skitsere en realistisk 2-ugers plan, hvor du får et “minimum viable” MDM-setup på plads, uden at du skal rykke ind på kontoret om aftenen.

Uge 1: Forberedelse og teknisk grundopsætning

Dag 1-2: Afklar scope og valg

• Beslut: Hvilke brugere og enheder er med i første bølge? (fx alle sælgere + ledelse)
• Beslut: BYOD, firmamobil eller en blanding?
• Vælg de 5-7 politikker, du starter med: kode, kryptering, OS-version, fjernsletning, app protection, obligatoriske apps

Dag 3-4: Sæt MDM op og test på få enheder

• Sæt MDM-systemet op efter leverandørens best practices (fx Microsoft, Apple, CIS)
• Enroll 3-5 test-enheder (gerne både iPhone og Android, forskellige brugertyper)
• Test policies: virker skærmlås-krav, bliver apps automatisk installeret, kan du fjernslette arbejdsprofiler?

Dag 5: Juster efter test og skriv kort brugerkommunikation

• Ret åbenlyse irritationsmomenter (fx for kort låse-tid eller for aggressive popups)
• Skriv en enkel mail eller intranet-tekst: hvad sker der, hvornår, og hvad betyder det for brugerne?

Uge 2: Rul ud og håndter de første problemer

Dag 6-7: Rolig udrulning til første gruppe

• Enroll den første gruppe brugere med støtte (evt. drop-in support eller små hold)
• Hold øje med compliance-oversigter: hvilke enheder fejler, og hvorfor?

Dag 8-9: Fintuning baseret på virkelige klager

• Samle feedback: Hvor går det galt? Er det login, opdateringer, app-krav?
• Juster et par ting, ikke alt. Målet er stabilitet, ikke at efterkomme hver eneste personlig præference.

Dag 10: Aftal næste trin

• Beslut, hvornår og hvordan næste gruppe kommer på
• Definér et par simple målepunkter, du vil følge de næste 3 måneder

Hvordan måler du, om dine MDM politikker faktisk virker?

Det er fristende bare at sige “nu har vi MDM, så er vi sikre”. Men ligesom med andre sikkerhedstiltag giver det mening at følge et par konkrete tal og hændelser.

Fire enkle målepunkter

• Compliance-rate: Hvor stor en andel af enhederne lever op til jeres minimumskrav? Hvis du ligger langt under 90 procent, er der et problem i enten politikkerne eller processen.
• Antal enheder uden opdateret OS: En god indikator for, om jeres opdateringspolitik fungerer i praksis.
• Hændelser med mistede/stjålne enheder: Hvor hurtigt kan I reagere med fjernlås eller sletning? Bliver det rent faktisk gjort?
• Supporttickets relateret til MDM: Spring ikke direkte til “brugerne er bare brokkehoveder”. Er der mønstre, der tyder på, at en policy er unødigt irriterende eller forvirrende?

Praktisk test af de vigtigste scenarier

Ud over tal er det værd at lave 3-4 manuelle tests hvert kvartal. Ikke store fancy øvelser, bare meget lavpraktisk:

• Test: Kan du fjernlåse og fjernslette en test-mobil uden panik?
• Test: Hvad sker der, når en mobil bliver ikke-compliant (fx gammel OS-version)? Får brugeren en forståelig besked?
• Test: Virker app protection som forventet (kan du copy/paste firmadata ud i Notes?)
• Test: Hvad sker der, når du fjerner en bruger fra systemet? Forsvinder firmadata rent faktisk?

Hvis du i forvejen arbejder med sikkerhed og compliance omkring telefoni, kan du lægge de her tests ind som en fast del af dine øvrige kontroller. Det behøver ikke være en kæmpe øvelse, men det skal være noget, der faktisk sker og ikke bare står i en mappe.

Et sidste ord om “policy-overload”

Jeg har set flere virksomheder starte ambitiøst med MDM og så ende med, at IT efter et år næsten ikke tør røre ved det mere, fordi hver lille ændring skaber bøvl. Det kan du undgå ved at love dig selv to ting:

• Du starter med et lille, men stærkt sæt politikker og lader det køre stabilt
• Du evaluerer efter fx 3 måneder, før du lægger mere ovenpå

Hvis du vil nørde endnu mere i valg af selve MDM-løsningen, har jeg skrevet om mine egne fejl i artiklen om at vælge forkert MDM første gang, men du behøver ikke have det perfekte værktøj for at få glæde af et godt minimums-setup.

Det allervigtigste råd er: Få styr på kode, kryptering, opdateringer og fjernsletning først, og gør det så lidt irriterende som muligt for de mennesker, der faktisk skal bruge telefonerne hver dag.