Brugere og adgang

Fratrædelse og rolleskift i en app: luk adgang uden at slette historik

Når en medarbejder stopper, en konsulent afslutter arbejdet, eller en bruger skifter rolle, er det ikke nok at fjerne navnet fra en liste. Appen skal stoppe nye login, lukke eksisterende sessioner, fjerne gammel adgang, overføre ansvar og stadig bevare den historik, virksomheden har brug for.

Udgivet 8. oktober 2026 · Ca. 10 minutters læsetid

Det korte svar

Gør fratrædelse og rolleskift til en fast adgangsproces med en tydelig udløser, ansvarlig og deadline. Deaktivér brugerens mulighed for at logge ind, tilbagekald aktive sessioner, fjern roller og integrationer, overfør åbne opgaver og ejerskab, og kontrollér bagefter adgangen fra alle relevante indgange. Slet først kontoen, hvis historik, retention og forretningsbehov er afklaret.

Deaktivering og sletning er to forskellige beslutninger. Deaktivering stopper brugen. Sletning kan samtidig fjerne relationer, navn på gamle handlinger eller muligheden for at forstå, hvem der ejede en opgave.

Kortlæg hele adgangskæden

NCSC anbefaler en proces for personer, der starter, skifter rolle og stopper – ofte kaldet joiners, movers and leavers. For jeres egen app betyder det, at adgang ikke kun findes i loginløsningen. Den kan også ligge i appens database, virksomhedens roller, delte links, API-nøgler, integrationer og cloudplatforme.

Identitet: Firebase Auth, Supabase Auth, Entra ID eller en anden tjeneste, som godkender login.
Appens konto: Brugerstatus, virksomhedstilknytning, roller, særlige undtagelser og aktive sessioner.
Tilknyttede adgange: OAuth-forbindelser, personlige tokens, webhook-hemmeligheder og delte administrative konti.
Ansvar og data: Åbne sager, godkendelser, kundekontakt, planlagte jobs, rapporter og historiske handlinger.

Lav en lille adgangsoversigt med system, kontotype, ejer, handling ved rolleskift og handling ved fratrædelse. Gem ikke adgangskoder i oversigten. Formålet er at kunne se, hvilke steder processen skal ramme.

Lad en pålidelig hændelse starte processen

En sikker proces starter fra en kilde, virksomheden allerede stoler på: en godkendt ændring fra HR, en kundeadministrator eller en navngiven systemejer. Appen bør ikke lukke adgang alene på baggrund af en email fra en ukendt afsender eller en ændring, brugeren selv kan manipulere.

Personen stopper

Aftal præcist hvornår adgang skal ophøre, hvem der udfører handlingen, og hvem der bekræfter, at åbne opgaver og ejerskab er overført.

Personen skifter rolle

Beregn de nødvendige rettigheder på ny. Læg ikke bare den nye rolle oven på den gamle, for så kan brugeren ende med en kombination, ingen længere har godkendt.

En ekstern adgang udløber

Giv konsulenter, samarbejdspartnere og kundeadministratorer en ejer og en udløbsdato, så adgangen ikke overlever den opgave, den blev oprettet til.

Stop både nye login og eksisterende sessioner

En deaktiveret identitet forhindrer normalt nye login, men en allerede åben app kan have sin egen cookie eller et token, der fortsat accepteres. Microsoft beskriver netop, at identitetsudbyderen ikke direkte kan lukke en sessionscookie, som appen selv har udstedt. Appen skal derfor have sin egen måde at afvise deaktiverede brugere på.

Blokér nye login: Deaktivér identiteten eller fjern app-tildelingen i den loginplatform, I faktisk bruger.
Tilbagekald tokens: Brug platformens funktion til at tilbagekalde refresh tokens og andre langlivede adgangsmidler.
Kontrollér appens session: Lad backend kontrollere brugerens aktive status og afvis adgang, selv hvis browseren stadig har en gammel cookie.
Luk andre veje: Fjern personlige API-nøgler, OAuth-forbindelser, administratorroller og adgang til cloud, repository og supportværktøjer.

Et grønt “deaktiveret”-felt er ikke bevis. Prøv en eksisterende browserfane, en mobil session og et direkte API-kald efter den model, appen bruger. Resultatet skal være et sikkert afslag uden at lække data.

Overfør ansvar før adgangen forsvinder

Adgang kan være lukket korrekt og stadig efterlade driften i stå. Find derfor de objekter og processer, hvor brugeren er eneste ejer, modtager eller godkender, før kontoen deaktiveres eller slettes.

Åbne opgaver og sager: Overfør dem til en navngiven person eller kø, og registrér at ejerskabet er ændret.
Godkendelser og fire-øjne-princip: Erstat personen i ventende flows uden at lade samme person blive både bestiller og godkender.
Integrationer og automationer: Flyt jobs, webhooks og forbindelser væk fra personlige konti, hvor teknologien tillader det.
Notifikationer og alarmer: Sørg for, at driftsbeskeder stadig har en aktiv modtager og en eskalationsvej.

Hvis et job kun virker, mens en bestemt medarbejders refresh token er gyldigt, er det både et offboardingproblem og et ejerskabsproblem. Dokumentér undtagelsen og flyt den til en virksomhedsforankret identitet, når platformen understøtter det.

Bevar sporbarhed uden at holde kontoen åben

Historiske ordrer, sager og revisionsposter bør ikke være afhængige af, at en konto fortsat kan logge ind. Adskil derfor den aktive identitet fra registreringen af, hvem der udførte en tidligere handling.

Markér kontoen som inaktiv frem for straks at fjerne den fra alle relationer.
Bevar et stabilt internt bruger-id i historikken og vis tydeligt, at personen er inaktiv.
Undgå at genbruge en tidligere brugers id eller konto til en ny person.
Beslut opbevaring og sletning ud fra formål, lovgrundlag og dokumenterede frister – ikke ud fra loginstatus alene.

Persondata skal stadig slettes eller anonymiseres, når formålet og opbevaringsgrundlaget ophører. Det er en separat databeslutning, som bør hænge sammen med appens retention- og GDPR-proces.

Verificér lukningen som et lille sikkerhedstjek

Den person, der klikker “deaktivér”, bør ikke være den eneste, der vurderer resultatet. Brug en enkel, gentagelig kontrol, som både viser, at adgang er væk, og at driften fortsætter for de rigtige brugere.

1. Forsøg nyt login: Identiteten skal afvises uden at afsløre unødige kontooplysninger.
2. Genbrug en aktiv session: En åben fane eller klient må ikke fortsætte med at hente eller ændre beskyttede data.
3. Prøv direkte adgang: API, delte links og administrative indgange skal håndhæve den nye status.
4. Kontrollér ansvar: Opgaver, alarmer og godkendelser skal have en aktiv ejer.
5. Kontrollér spor: Revisionsloggen skal vise hvem der ændrede adgangen, hvornår og på hvilket grundlag.

Gennemgå også aktive brugere og særrettigheder med en fast rytme. NCSC fremhæver både gennemgang ved rolleskift og regelmæssig kontrol, så gammel adgang ikke kun opdages, når nogen husker den.

Typiske fejl

Brugeren slettes med det samme: Åbne opgaver mister ejer, og historiske handlinger bliver svære at forstå.
Kun loginplatformen opdateres: Appens egen session eller personlige API-nøgle kan stadig give adgang.
Den nye rolle lægges ovenpå: Gamle rettigheder bliver hængende og skaber en uventet kombination.
Delte konti skjuler personen: Ingen kan se, hvem der fortsat kender adgangskoden, eller hvem der udførte en handling.
Eksterne brugere glemmes: Konsulenter, partnere og tidligere kundeadministratorer beholder adgang uden aktivt behov.
Automation ejer sig selv: Integrationer og alarmer stopper, fordi de var bundet til personens konto.
Ingen efterkontrol: Processen er markeret færdig uden test af gamle sessioner, API og ejerskab.

Tjekliste ved rolleskift eller fratrædelse

☐ En godkendt kilde har startet ændringen med person, tidspunkt og ansvarlig.
☐ Appens identitet, konto, roller, særrettigheder og virksomhedstilknytning er kortlagt.
☐ Nye login er blokeret eller rettighederne genberegnet efter den nye rolle.
☐ Aktive sessioner og relevante tokens er tilbagekaldt.
☐ Personlige API-nøgler, OAuth-forbindelser og administrative adgange er lukket.
☐ Åbne opgaver, godkendelser, jobs, integrationer og alarmer har en aktiv ejer.
☐ Historiske handlinger kan stadig forstås uden at kontoen kan logge ind.
☐ Sletning og anonymisering følger dokumenterede retention- og GDPR-beslutninger.
☐ Nyt login, gammel session, direkte API-adgang og delte links er testet.
☐ Ændringen og efterkontrollen fremgår af et revisionsspor.
☐ Aktive brugere og særrettigheder gennemgås igen med en fast rytme.

Relaterede guides

Roller og rettigheder i appen Sikkert login, sessioner og kontogendannelse Revisionslog og ændringshistorik Dataretention og slettefrister Ejerskab og administratoradgang til cloudkonti Se hele guidebiblioteket

Officielle kilder

Den konkrete fremgangsmåde afhænger af appens loginplatform og sessionstype. Kilderne her dokumenterer adgangslivscyklus, gennemgang af rettigheder, deprovisionering og tilbagekaldelse af sessioner i NCSC-, Microsoft Entra- og Firebase-miljøer.