Stop legacy authentication i Microsoft 365, sådan finder du det og blokerer det sikkert
Legacy login er lidt som en gammel nøgle, der stadig passer i bagdøren. Den virker, men den er nem at kopiere, og den passer ikke til moderne låse. I Microsoft 365 er “legacy authentication” typisk gamle protokoller, der bruger brugernavn og adgangskode uden moderne sikkerhedslag.
Hvis målet er bedre it-sikkerhed uden driftsstop, kræver det en plan: find trafikken, pilottest blokering, håndtér undtagelser, og rul ud med ro i maven. Det her er skrevet til SMV’er, hvor tiden er knap, og hvor it-support ofte også dækker alt fra firewall og antivirus til backup og brugerhjælp.
Hvad er legacy authentication, og hvorfor er det et problem?
Et simpelt sikkerheds-overblik med tydelig advarsel og blokering af gamle login-metoder, skabt med AI.
Legacy authentication (også kaldet “basic auth”) dækker login-metoder, hvor klienten sender et password på en måde, der ikke understøtter MFA (multi-factor authentication). Det ses ofte i:
- IMAP og POP (mail-klienter og enheder)
- Exchange ActiveSync (ældre mobil-synk)
- EWS og ældre MAPI-scenarier
- SMTP AUTH (ofte “scan-to-mail” og ældre systemer)
Problemet er ikke, at protokollen “altid” er kompromitteret. Problemet er, at den mangler moderne kontrol . Man kan ikke på samme måde kræve MFA, enhedskrav eller risikobaseret adgang. Det gør angreb som password spray og credential stuffing langt mere effektive.
Microsoft har en praktisk oversigt over anbefalinger og blokering via Conditional Access i vejledningen til at blokere legacy authentication.
Sådan finder du legacy authentication i din tenant
Det er fristende bare at blokere alt med det samme. I en SMV er det tit dér, hvor printeren stopper med at sende scannede fakturaer, og nogen råber “mailen virker ikke”. Start med synlighed.
1) Tjek sign-in logs i Entra ID
Kig efter “Client app” eller tilsvarende felt, hvor du kan se legacy-klienttyper. Filtrér på fejl og på brugere, så du hurtigt ser mønstre.
2) Brug workbook til at samle billedet
Microsoft har en workbook, der er lavet til netop dette formål. Den hjælper med at svare på det vigtige spørgsmål: “Hvem bruger legacy, og hvor?” Se Sign-ins using legacy authentication workbook.
3) Notér tre ting pr. fund
Hold det lavpraktisk. For hver legacy sign-in, notér:
- Hvilken bruger eller servicekonto
- Hvilken protokol (IMAP, POP, SMTP, ActiveSync)
- Hvilken app eller enhed (printer, gammel klient, gateway)
Når man gør det, bliver blokering et kontrolleret projekt, ikke en brandøvelse.
Blokér legacy authentication sikkert med Conditional Access (SMV-model)
En før og efter-illustration af skiftet fra gamle protokoller til MFA og Conditional Access, skabt med AI.
Her er en model, der passer til de fleste SMB-miljøer. Den er enkel, og den kan rulles ud uden at gætte sig frem.
Trin 1: Opret en pilotgruppe (lille og relevant)
Vælg 5 til 15 brugere, som repræsenterer virkeligheden:
- En fra økonomi (scanning, faktura-flow)
- En fra salg (mobil, CRM)
- En it-administrator
- En “tung” mailbruger
- En med ældre enhed eller special-app
Kommunikér kort til piloten: hvad ændrer sig, og hvem de skriver til ved fejl. Change management i mini-format.
Trin 2: Policy i Report-only (først)
Eksempel: “Block legacy auth, Pilot, Report-only”
- Users: Pilotgruppen
- Cloud apps: All cloud apps
- Conditions, Client apps: “Other clients” (legacy)
- Access controls: Block access
- Mode: Report-only
Lad den køre nogle dage. Tjek logs. Ret de ting, der reelt bryder.
Microsoft beskriver selve policy-opsætningen i Block legacy authentication with Conditional Access.
Trin 3: Skift pilot til “On”, derefter bred udrulning
Når pilotgruppen er stabil:
- Klon policy
- Udvid målgruppen til “All users”
- Ekskludér nød- og servicekonti (mere om det nedenfor)
- Skift til “On”
Praktisk tommelfingerregel: Lav én global blokeringspolitik, og undgå mange små variationer. Det gør drift og fejlsøgning lettere.
Typiske undtagelser (og hvad man gør i praksis)
SMV’er har ofte de samme tre “legacy fælder”. De er til at løse, men man skal vælge den rigtige løsning, ikke bare lave et hul i hegnet.
Multifunktionsprintere og scannere der sender mail
Den klassiske “scan-to-email” bruger SMTP AUTH med basic auth. Løsningerne er typisk:
- Opgradér firmware eller skift til en model, der kan moderne auth (OAuth) eller en sikker relay-model
- Brug en dedikeret mail-relay eller gateway med kontrolleret adgang
- Undgå personlige brugere til printere. Brug servicekonto og stram rettigheder
Vigtigt i januar 2026: SMTP AUTH er ofte den sidste rest, og Microsoft strammer løbende kravene. Planlæg udskiftning eller omlægning, så man ikke rammes af en pludselig blokering i foråret 2026.
Gamle ERP/CRM-klienter og lokale add-ins
Ældre klienter kan bruge gamle Exchange-protokoller eller indlejrede login-vinduer. Her er det sjældent “en enkelt setting”.
- Afdæk version og leverandørens support for modern auth
- Opdatér klienten, eller skift integrationsmetode (API, app-registrering)
- Hvis det er et script, så skift til moderne adgang (app-registrering og mindst mulige rettigheder)
Tredjeparts mail-gateways og sikkerhedstjenester
Nogle gateways logger ind for at hente eller sende mail. Løsningen er normalt:
- Brug moderne forbindelser og dokumenterede connector-setup
- Begræns adgang med IP, certifikater eller dedikerede konti
- Tjek leverandørens anbefalinger, og test i pilot før bred udrulning
Hvis Exchange Online stadig har basic auth-relaterede rester, så brug den officielle reference som udgangspunkt: Disable Basic authentication in Exchange Online.
Bedste praksis der gør blokeringen stabil
Når legacy er væk, falder støjen, men kun hvis fundamentet er på plads.
MFA overalt : MFA er standard for brugere, også ledelse og eksterne samarbejder. Legacy auth kan ikke løftes med MFA, så blokkér i stedet for at håbe.
App passwords udfases : Hvis der stadig findes app passwords, så planlæg udfasning. De bliver ofte brugt som “en nem genvej”, og de lever længe i miljøet.
Servicekonti : Brug dedikerede servicekonti, og giv mindst mulige rettigheder. Dokumentér formål, ejer og livscyklus.
Break-glass konti (min. 2) : Hav to nød-konti, udelukket fra blokeringspolitikker. Opbevar adgang sikkert, test logon jævnligt, og overvåg dem i logs.
Logning og monitorering : Sæt alarmer på “legacy client app” forsøg og gentagne fejl. Det er ofte tidlige tegn på angreb.
Og husk helheden: Conditional Access er én kontrol. Stabil it-sikkerhed i en SMV kræver også backup, antivirus og en korrekt opsat firewall. Hos NetDK ser man ofte, at de ting hænger sammen i praksis, især når man supporter brugere i århus og lystrup med blandede enheder og arbejdsmønstre.
Risiko vs. indsats (hurtigt overblik til SMV)
| Tiltag | Sikkerhedsgevinst | Indsats | Typisk faldgrube |
|---|---|---|---|
| Find legacy sign-ins (logs/workbook) | Høj | Lav | Man stopper efter første fund |
| CA blokering i pilot, så “On” | Meget høj | Mellem | For bredt scope uden pilot |
| Håndtér printer, ERP/CRM, gateways | Høj | Mellem til høj | Man laver permanente undtagelser |
| Break-glass + monitorering | Mellem | Lav | Konti bliver glemt, aldrig testet |
Næste skridt (praktisk tjekliste)
En IT-ansvarlig, der følger en enkel tjekliste til sikker udrulning, skabt med AI.
- Kør en uge med overblik: sign-ins, protokoller, enheder.
- Opret pilotgruppe og CA-policy i Report-only.
- Luk de kendte huller først (printer, gateway, gammel klient).
- Skift pilot til “On”, derefter alle brugere.
- Sæt monitorering på forsøg, og dokumentér undtagelser.
At stoppe legacy authentication Microsoft 365 handler mest om disciplin, ikke drama. Når det er gjort rigtigt, får man roligere drift, færre kompromitterede konti og et Microsoft 365-miljø, der er nemmere at supportere med faste it-løsninger og forudsigelig it-support.
