Login er den afhængighed, der kan ramme hele virksomheden på samme tid, fordi medarbejderne bruger samme konto til mange systemer. Bor identiteten hos en leverandør, I mister eller forlader, mister I også vejen ind til systemer, der intet fejler. Derfor skal exit-planen behandle login som et system for sig med sin egen liste over alt, der hænger på det.
Tre ting, der ofte bor samme sted
Når der tales om login, er det som regel tre forskellige funktioner, som leverandøren har samlet.
- Brugerkataloget er listen over medarbejdere, grupper og rettigheder.
- Fælles login, single sign-on, betyder, at andre systemer spørger kataloget, om en person er den, vedkommende siger. Så slipper medarbejderne for en adgangskode pr. system.
- To-faktor er det ekstra trin ved login, typisk en app, en kode eller en fysisk nøgle.
I hverdagen er samlingen en fordel. Den gør det lettere at lukke en konto, når en medarbejder stopper, og den er en god sikkerhedsbeslutning, som denne artikel ikke vil have jer til at omgøre. Kravet om to-faktor skal stå ved magt. Spørgsmålet her er, hvad planen siger, den dag kataloget er væk.
To situationer med hver sin plan
Adgangen er væk. En konto spærres, en tjeneste ligger ned i flere dage, eller en leverandør lukker. Så kan medarbejderne hverken komme til mail eller til de systemer, der bruger samme login, selv om de kører fint hos en anden leverandør. Se også kontoen lukkes uden varsel.
I skifter ordnet. Her virker alt, men hvert system, der bruger det gamle login, skal kobles om, og alle medarbejdere skal registrere to-faktor igen. Arbejdet er overskueligt pr. system. Planlægges det uden etaper, rammer det til gengæld alle på samme dag.
Begge situationer begynder med samme kortlægning.
Sådan kortlægger I systemerne bag samme login
De fleste identitetstjenester har en administratorside med en liste over tilkoblede applikationer. Hent den, og brug den som begyndelse. Den viser dog kun det, der er koblet på centralt. Spørg også, hvor folk bruger knappen “log ind med” fra en stor leverandør, for de koblinger er ofte lavet af medarbejderne selv og findes måske ikke på listen.
Lav et ark med disse felter pr. system.
- System og ejer · hvem i virksomheden svarer for systemet.
- Måde at logge ind på · fælles login gennem en åben standard, en leverandørbestemt kobling eller egne adgangskoder.
- Lokal adgang · kan nogen logge ind, hvis det fælles login er væk?
- Kobling · hvem kan flytte systemet til et andet login, og er det jer eller systemets leverandør?
- Rettigheder · bor grupper og roller i systemet selv, eller kommer de fra kataloget?
- Maskinkonti · findes der servicekonti og integrationer, der også bruger kataloget?
Det sidste felt overses let. En integration, der logger ind med en servicekonto, stopper sammen med kataloget, og det bliver først synligt, når data udebliver. Læg dem også ind i tællingen af integrationer.
Åbne standarder gør arbejdet lettere, når systemet understøtter dem. SAML og OpenID Connect er de to almindelige, og hos mange systemer er omkoblingen en opgave for en administrator. Nogle systemer kræver dog en dyrere udgave eller en henvendelse til leverandøren, og det skal stå i arket.
Nødadgang
Den enkleste forbedring kan I lave nu. Opret for hvert kritisk system en administratorkonto, som ikke bruger det fælles login, og som har sin egen stærke to-faktor. Sådan en konto kaldes tit en nødkonto.
Beskriv, hvor oplysningerne opbevares, hvem der må hente dem, hvordan brugen logges, og hvordan I lukker for den igen. En nødkonto er en kraftig adgang, og den skal behandles sådan. Få IT-sikkerheden til at godkende fremgangsmåden. Prøv den derefter med faste mellemrum, for en konto, der ikke er prøvet, virker måske ikke, når den skal bruges.
Tænk også på to-faktor. Står alle koder i en app, som hører til den leverandør, I mister, skal alle registreres igen på en ny måde. Planen skal sige, hvordan I bekræfter, hvem medarbejderne er, når de skal det. Det sker typisk samtidig med, at supporten har allermest travlt.
Hvad Data Act kan bruges til
Skifter I en cloudtjeneste, kan adgangsrettigheder høre til de digitale aktiver, der skal kunne flyttes, når I har brugsretten uafhængigt af udbyderen. Det fremgår af Kommissionens FAQ, punkt 53, som er vejledende. Det er vores læsning, at det ikke løser selve omkoblingen. Rettigheder, der kan eksporteres, skal stadig kunne læses af det nye katalog, og det skal testes.
Hvad det kræver, og hvad det koster at lade være
Kortlægningen kræver en administrator med adgang til kataloget og samtaler med systemejerne. Nødkonti kræver lidt tid pr. system og en fast afprøvning. Skriv det i et dateret overslag med bedste og værste bud.
Det koster at lade være, fordi login rammer bredt. Et stop her rammer alle medarbejdere i alle systemer bag samme login. Regn tabet pr. dag i egne tal, og læg afdelingerne sammen.
Sammenhold det med arbejdet, og tag gevinsten med. Listen viser jer, hvem der har adgang hvortil, hjælper med at lukke gamle koblinger og giver et enkelt svar, når kunder og bestyrelser spørger, om I kan komme ind, hvis jeres vigtigste leverandør er væk.
Det skal I lade være med
- At droppe to-faktor for at gøre exit lettere · sikkerheden i hverdagen går forud.
- At regne login for ét system · tæl alt, der hænger på det.
- At oprette nødkonti uden kontrol · de skal logges, prøves og have en ejer.
Det skal planen kunne vise
- ☐ En liste over systemer bag det fælles login.
- ☐ Lokal adgang og nødkonti pr. kritisk system.
- ☐ Maskinkonti og integrationer, der bruger samme katalog.
- ☐ Metoden til at bekræfte brugere ved ny to-faktor.
- ☐ Dato og resultat for seneste prøve af nødadgangen.
Kilder
- Europa-Kommissionen: FAQ om Data Act, version 1.4 af 22. januar 2026: punkt 53 om digitale aktiver. Vejledende.
Senest gennemgået: november 2026.
Næste skridt
Bed administratoren hente listen over tilkoblede systemer i denne uge, og afprøv én nødadgang på det vigtigste. Tag bagefter stilling til, om login skal have sin egen plan.
Læs også: Reserveløsning · Brugerne i planen
→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT
