SaaS-Zugänge aufräumen: So schließen Unternehmen vergessene Konten

Vergessene SaaS-Zugänge sind wie unbezahlte Mitgliedsbeiträge im Fitnessstudio: Man merkt erst spät, dass man noch drin ist – und dann meist, weil jemand anderes die Tür genutzt hat. Nur dass es bei SaaS-Zugängen nicht um zwölf Euro im Monat geht, sondern um Zugriff auf CRM, Buchhaltung, Confluence-Wikis und manchmal die Produktionspipeline. Laut Kaseya-Report für 2026 haben 69 Prozent der überwachten SaaS-Accounts mehr Gastzugänge als lizenzierte Nutzer. Das ist keine Randnotiz, das ist der Normalzustand in vielen Unternehmen.

Das Pikante daran: Niemand hat diese Zugänge böswillig offen gelassen. Sie sind einfach übrig geblieben. Praktikant, der vor zwei Jahren ging. Agentur, deren Vertrag ausgelaufen ist. Kollegin, die in ein anderes Team wechselte und ihre alten Tool-Zugänge behielt, weil niemand widersprochen hat. Jeder dieser Zugänge ist ein offenes Fenster in einem Haus, dessen Grundriss die IT-Abteilung selbst nicht mehr vollständig kennt.

Warum vergessene SaaS-Zugänge zum Sicherheitsrisiko werden

Ein inaktives Konto ist nicht automatisch harmlos. Es ist ein Konto ohne Aufsicht – niemand prüft mehr, ob das Passwort noch stark ist, ob Zwei-Faktor-Authentifizierung aktiv bleibt, ob die E-Mail-Adresse dahinter überhaupt noch existiert. Genau solche Zugänge landen in Credential-Stuffing-Listen, die nach Datenlecks kursieren. Wer ein Passwort aus einem alten Leak wiederverwendet hat und dessen SaaS-Zugang seit Monaten niemand kontrolliert, liefert Angreifern ein bequemes Einfallstor, ohne dass es jemandem auffällt.

Der Clou an vergessenen Zugängen: Sie tauchen in klassischen Sicherheitsaudits oft gar nicht auf, weil Audits sich meist auf aktive Systeme konzentrieren. Ein Konto, das niemand mehr benutzt, generiert auch keine Alarme, keine Logs, keine Aufmerksamkeit. Bis jemand es doch benutzt – und dann meist nicht die Person, die ursprünglich damit arbeitete.

Für IT-Teams bedeutet das: Die Angriffsfläche eines Unternehmens wächst nicht linear mit der Zahl aktiver Mitarbeitender, sondern mit der Summe aller jemals angelegten SaaS-Zugänge. Und diese Summe kennt in vielen Firmen niemand genau. Wenig überraschend, dass genau hier ein wachsender Teil der Sicherheitsvorfälle ansetzt, die mit gestohlenen oder wiederverwendeten Zugangsdaten beginnen.

Das Gastzugänge-Problem: mehr Gäste als Lizenzen

Gastzugänge sind praktisch. Ein externer Berater braucht kurz Zugriff auf ein Slack-Workspace, eine Agentur soll Dateien in Google Drive einsehen, ein Freelancer bekommt Zugriff auf Notion. Das Problem beginnt, wenn „kurz“ zu „dauerhaft“ wird, weil niemand den Rückbau eingeplant hat. Genau das zeigt der Kaseya-Befund: Mehr Gastkonten als reguläre lizenzierte Nutzer sind in vielen überwachten SaaS-Accounts keine Ausnahme, sondern die Regel.

Dazu kommt ein zweites Muster aus demselben Berichtszeitraum: Bei mehr als 278 Millionen überwachten Dateien im Jahr 2025 waren rund 35 Prozent außerhalb der jeweiligen Organisation freigegeben. Das heißt nicht automatisch, dass jede dieser Freigaben ein Risiko ist – ein Kundenvertrag, der bewusst geteilt wird, ist unproblematisch. Aber ein erheblicher Teil dieser Freigaben dürfte schlicht vergessen worden sein, weil niemand externe Freigaben regelmäßig zurücksetzt.

Meine Einschätzung dazu: Gastzugänge sind das am stärksten unterschätzte Risiko im SaaS-Alltag, weil sie sich anders anfühlen als interne Konten. Niemand denkt bei einem externen Gastzugang automatisch an Offboarding-Pflichten – dabei ist genau das die Lücke, die Angreifer am liebsten finden.

Schritt 1: Inventar bauen, bevor Sie aufräumen können

Man kann nicht schließen, was man nicht kennt. Der erste und mühsamste Schritt bei jedem SaaS-Aufräumprojekt ist deshalb die Inventarisierung: alle Anwendungen, alle Konten, alle Zugriffsrechte an einem Ort zusammenführen. Praktisch heißt das, mehrere Datenquellen zu kombinieren – SSO-Protokolle, Finanzbuchungen für SaaS-Abonnements, Browser- oder Proxy-Signale und Admin-Exports aus den einzelnen Tools selbst.

Warum so umständlich? Weil Schatten-IT sich genau in den Lücken zwischen diesen Datenquellen versteckt. Ein Tool, das über die Kreditkarte einer Fachabteilung bezahlt wird, taucht in keinem SSO-Log auf. Ein Konto, das über ein persönliches Google-Profil angelegt wurde, erscheint in keiner Rechnung. Erst die Kombination mehrerer Quellen macht sichtbar, wie viele SaaS-Zugänge tatsächlich existieren – und die Zahl liegt in aller Regel deutlich über der offiziellen Schätzung der IT-Abteilung.

Realistisch sollten Unternehmen bei diesem Schritt mit Überraschungen rechnen. Abteilungen, die eigene Tools eingeführt haben, ohne die IT zu informieren. Zugänge, die formal gekündigt, aber nie technisch deaktiviert wurden. Das ist unangenehm, aber besser jetzt entdeckt als nach einem Vorfall.

Schritt 2: Owner zuordnen – ohne Verantwortliche keine Freigabe

Ein Inventar allein räumt nichts auf. Der nächste Schritt ist, jedem SaaS-Zugang eine verantwortliche Person zuzuordnen – fachlich und technisch. Wer braucht dieses Tool wirklich? Wer entscheidet, ob ein Konto bestehen bleibt? Ohne klaren Owner gilt die einfache Regel: kein automatisches Fortbestehen des Zugangs.

Das klingt bürokratisch, ist aber der entscheidende Hebel gegen Zombie-Konten. In der Praxis zeigt sich immer wieder derselbe Effekt: Sobald ein Konto einen Namen bekommt, der dafür geradestehen muss, schrumpft die Zahl der „irgendwie noch aktiven“ Zugänge spürbar. Niemand will als Owner eines Kontos dastehen, das seit anderthalb Jahren niemand mehr genutzt hat.

Wichtig dabei: Owner-Zuordnung ist kein einmaliges Projekt. Menschen wechseln Teams, Verantwortlichkeiten verschieben sich, Tools werden von anderen Abteilungen übernommen. Ohne einen Prozess, der diese Zuordnung regelmäßig aktualisiert, verwaist die Owner-Liste genauso wie die Zugänge selbst.

Schritt 3: Rezertifizierung – Zugriffe regelmäßig bestätigen lassen

Rezertifizierung ist das Gegenteil von „einmal vergeben, nie wieder angefasst“. Vorgesetzte, Applikations-Owner oder System-Owner bestätigen in festgelegten Abständen, dass ein Zugriff noch gebraucht wird – oder entziehen ihn. Für besonders sensible Systeme empfiehlt sich ein kürzerer Rhythmus, für weniger kritische Tools reicht ein größerer Abstand.

Der Haken an klassischer Rezertifizierung: Wenn sie manuell in Excel-Tabellen läuft, wird sie schnell zur Alibi-Übung. Ein Vorgesetzter bekommt eine Liste mit vierzig Namen, klickt „alles bestätigen“ und macht mit seinem eigentlichen Job weiter. Genau deshalb setzen immer mehr Unternehmen auf automatisierte Workflows, die gezielt nach Auffälligkeiten filtern – etwa Konten ohne Login seit Monaten, Gastzugänge ohne aktives Projekt oder externe Freigaben ohne aktuellen Geschäftsbezug.

Eine ehrliche Frage an dieser Stelle: Wie oft überprüft Ihr Unternehmen eigentlich, wer noch Zugriff auf welches Tool hat? Wenn die Antwort „gar nicht“ oder „unregelmäßig“ lautet, ist das kein Einzelfall – aber ein guter Anlass, den Prozess jetzt aufzusetzen, bevor ein Vorfall ihn erzwingt.

Schritt 4: Automatisiertes Deprovisioning statt Zettelwirtschaft

Deprovisioning ist der eigentliche Schließvorgang: Konten deaktivieren, Zugriffsrechte entziehen, verwaiste Freigaben löschen. Manuell ist das fehleranfällig, weil es niemandes Kernaufgabe ist und deshalb gerne aufgeschoben wird. Automatisierte Deprovisioning-Workflows arbeiten dagegen mit klaren Regeln: Ablaufdaten für temporäre Zugänge, automatische Sperrungen nach definierter Inaktivität, Wiederbestätigungspflichten für Gastkonten.

Praktisch bedeutet das etwa: Ein externer Gastzugang läuft nach 90 Tagen automatisch aus, wenn er nicht aktiv verlängert wird. Ein internes Konto ohne Login über einen längeren Zeitraum wird zunächst eingeschränkt und dann deaktiviert, statt einfach weiterzulaufen. Solche Regeln lassen sich in vielen Identity-Management-Systemen konfigurieren, ohne dass jemand jede Woche manuell durch Nutzerlisten scrollen muss.

Das Minimalprinzip gehört in diesen Schritt fest hinein: Zugänge sollten von Anfang an nur die Rechte bekommen, die für die konkrete Aufgabe nötig sind. Wer ein Tool nur zum Lesen braucht, bekommt keine Admin-Rechte. Das reduziert nicht nur das Risiko im Ernstfall, sondern macht auch das spätere Aufräumen leichter, weil weniger kritische Berechtigungen im Umlauf sind.

Konsolidierung: Weniger Tools, weniger Angriffsfläche

Ein Nebeneffekt jedes SaaS-Aufräumprojekts: Man entdeckt, wie viele Tools eigentlich dieselbe Aufgabe erfüllen. Mehrere Teams nutzen unterschiedliche Projektmanagement-Apps, zwei Abteilungen zahlen parallel für ähnliche Umfrage-Tools, irgendwo läuft noch eine File-Sharing-Lösung, die vor drei Jahren durch eine andere ersetzt werden sollte, aber nie offiziell abgeschaltet wurde. Genau dieses Muster beschreibt auch die Diskussion um SaaS-Konsolidierung, bei der es darum geht, den Tool-Wildwuchs in Unternehmen zu stoppen, statt ihn weiter wachsen zu lassen.

Jede zusätzliche SaaS-Anwendung ist nicht nur eine Kostenposition, sondern auch ein zusätzlicher Satz an Zugängen, Berechtigungen und potenziellen Schwachstellen. Weniger parallele Tools heißt weniger Angriffsfläche, weniger Owner-Listen, weniger Stellen, an denen ein vergessenes Konto überhaupt entstehen kann. Konsolidierung ist deshalb kein reines Finanzthema, auch wenn Einkaufsabteilungen es meistens so verkaufen.

Der aktuelle Stand des SaaS-Markts macht deutlich, warum das Thema nicht kleiner wird: Der globale SaaS-Markt wurde für 2025 auf rund 315,68 Milliarden US-Dollar geschätzt, mit anhaltendem Wachstum. Mehr Anwendungen, mehr Anbieter, mehr Auswahl – und damit auch mehr potenzielle Zugänge, die irgendwann wieder aufgeräumt werden müssen. Der BetterCloud State of SaaS Report für 2026 bestätigt diesen Trend aus einer eigenen Datenperspektive und zeigt, dass SaaS-Management längst eine eigenständige operative Disziplin geworden ist, nicht nur ein Nebenprojekt der IT.

Kennzahlen, die zeigen, ob das Aufräumen wirkt

Ohne Messung bleibt jedes Aufräumprojekt ein gutes Vorhaben ohne Beweis. Sinnvolle Kennzahlen sind unter anderem der Anteil ungenutzter Lizenzen, die Zahl inaktiver Konten über einen definierten Zeitraum, die durchschnittliche Zeit bis zum tatsächlichen Deprovisioning nach Vertragsende oder Teamwechsel, sowie der Anteil der Zugänge, die im letzten Rezertifizierungszyklus tatsächlich bestätigt wurden.

Diese Zahlen lassen sich quartalsweise vergleichen und zeigen relativ schnell, ob der Prozess greift oder ob er auf dem Papier existiert, aber im Alltag ignoriert wird. Ein Unternehmen, das nach einem Quartal die Zahl inaktiver Konten deutlich senken kann, hat einen echten Fortschritt gemacht. Bleibt die Zahl konstant, liegt das Problem meist nicht am Werkzeug, sondern an fehlender Verbindlichkeit im Prozess selbst.

Ich halte wenig von SaaS-Aufräumaktionen, die als einmaliges Projekt geplant werden. Der Wert entsteht erst, wenn Inventarisierung, Rezertifizierung und Deprovisioning zu einem laufenden Betrieb werden – so selbstverständlich wie Backups oder Patch-Management. Alles andere ist Frühjahrsputz, der im Herbst schon wieder vergessen ist.

Ein Praxisszenario: Wie ein einzelner Zugang zum Problem wird

Um zu verstehen, warum dieses Thema mehr ist als eine abstrakte Compliance-Übung, hilft ein durchgespieltes Beispiel – bewusst vorsichtig formuliert, weil es kein konkreter, belegter Einzelfall ist, sondern ein Muster, das sich aus vielen ähnlich gelagerten Situationen ableiten lässt. Eine Marketing-Mitarbeiterin verlässt ein Unternehmen nach mehreren Jahren. Ihr Zugang zum E-Mail-Marketing-Tool wird deaktiviert, ihr Slack-Konto ebenfalls. Übersehen wird jedoch ein Zugang zu einem Umfrage-Tool, das ihre Abteilung vor zwei Jahren für eine einzelne Kampagne angeschafft hat und das seither kaum noch jemand nutzt.

Dieser Zugang bleibt bestehen, weil niemand ihn explizit auf dem Radar hat – er steht in keiner zentralen Nutzerliste, weil das Tool über die Kreditkarte der Abteilung und nicht über den zentralen Softwarekatalog eingekauft wurde. Monate später wird das Passwort, das die ehemalige Mitarbeiterin auch privat nutzte, im Rahmen eines Datenlecks bei einem völlig anderen Dienst öffentlich. Wenn dieses Passwort wiederverwendet wurde und niemand es zurückgesetzt hat, ist der alte SaaS-Zugang plötzlich wieder relevant – nicht, weil jemand aktiv danach gesucht hätte, sondern weil automatisierte Angriffswerkzeuge genau solche Kombinationen aus alten Zugangsdaten und offenen Konten systematisch durchprobieren.

Das eigentliche Risiko in diesem Szenario liegt nicht in einer einzelnen bösartigen Handlung, sondern in der Kombination aus fehlender Sichtbarkeit, fehlendem Owner und fehlendem Rückbau. Genau diese drei Faktoren sind es, die ein strukturiertes SaaS-Zugangsmanagement adressieren soll. Wäre das Umfrage-Tool im zentralen Inventar erfasst gewesen, hätte es einen Owner gehabt, der beim Abteilungswechsel oder spätestens bei der nächsten Rezertifizierung aufgefallen wäre. Stattdessen blieb es ein blinder Fleck – genau der Typ von blindem Fleck, den Sicherheitsverantwortliche am meisten fürchten, weil er sich erst im Nachhinein zeigt.

Gegenargumente: Warum viele Unternehmen das Aufräumen verschieben

So einleuchtend die vier Schritte auch klingen, in der Praxis stoßen sie regelmäßig auf Widerstand – und dieser Widerstand ist nicht immer unvernünftig. Ein häufiges Gegenargument lautet, dass Inventarisierung und Rezertifizierung Ressourcen binden, die kleinere IT-Teams schlicht nicht übrig haben. Wer ohnehin am Limit arbeitet, priorisiert naturgemäß akute Störungen über präventive Aufräumarbeiten, deren Nutzen sich erst zeigt, wenn nichts passiert.

Ein zweites Gegenargument betrifft die Angst vor Betriebsstörungen. Wer ein Konto deaktiviert, das doch noch gebraucht wird, riskiert Frust in der Fachabteilung und zusätzlichen Aufwand, um den Zugang wiederherzustellen. Diese Sorge ist nicht aus der Luft gegriffen – schlecht kommunizierte Deprovisioning-Prozesse können tatsächlich Arbeitsabläufe stören, wenn niemand vorher informiert wurde. Genau deshalb sollte jedes automatisierte Deprovisioning mit angemessenen Vorlaufzeiten und klaren Benachrichtigungen arbeiten, statt Konten ohne Vorwarnung abzuschalten.

Ein drittes, oft unterschätztes Gegenargument ist die schlichte Ermüdung gegenüber Sicherheitsprozessen. Wenn Mitarbeitende ständig neue Freigabeanfragen, Rezertifizierungs-E-Mails und Sicherheitsschulungen bekommen, sinkt die Sorgfalt, mit der sie diese bearbeiten – das sogenannte Security-Fatigue-Phänomen. Ein Rezertifizierungsprozess, der zu häufig oder zu unspezifisch abläuft, produziert am Ende genauso viele Alibi-Klicks wie gar kein Prozess.

Diese Einwände sprechen nicht gegen das Grundprinzip, sondern gegen eine schlecht gestaltete Umsetzung. Wer Rezertifizierung gezielt auf auffällige Konten beschränkt, statt pauschal alle Zugänge im gleichen Rhythmus abzufragen, reduziert die Belastung deutlich. Wer Deprovisioning mit klaren Vorlaufzeiten und einfachen Wiederherstellungswegen versieht, nimmt Fachabteilungen die Angst vor Kontrollverlust. Der Punkt ist also nicht, ob Aufräumen sinnvoll ist, sondern wie es so gestaltet wird, dass es nicht an der eigenen Komplexität scheitert.

Checkliste für den Einstieg: Die ersten drei Monate

Wer nach der Lektüre dieses Artikels konkret starten möchte, muss nicht sofort ein vollständiges Identity-Management-Programm aufbauen. Sinnvoller ist ein gestufter Einstieg, der in wenigen Monaten erste sichtbare Ergebnisse liefert und damit auch intern leichter zu rechtfertigen ist.

• Im ersten Monat steht die grobe Bestandsaufnahme im Vordergrund: Welche SaaS-Tools sind über zentrale Rechnungen bekannt, welche über SSO-Protokolle sichtbar, welche taucht in keiner der beiden Quellen auf, sondern nur in Gesprächen mit Fachabteilungen?
• Im zweiten Monat folgt die Owner-Zuordnung für die wichtigsten und am meisten genutzten Tools zuerst – nicht für alle 200 Anwendungen gleichzeitig, sondern priorisiert nach Kritikalität und Nutzerzahl.
• Im dritten Monat wird ein erster, bewusst kleiner Rezertifizierungslauf gestartet – etwa für Gastzugänge oder für Konten ohne erkennbare Aktivität in den letzten Monaten, statt gleich das gesamte Unternehmen einzubeziehen.

Parallel dazu lohnt sich eine kurze interne Kommunikation, die erklärt, warum dieser Prozess eingeführt wird und was von den Fachabteilungen erwartet wird. Ein Prozess, der als reine Kontrollmaßnahme der IT wahrgenommen wird, stößt auf mehr Widerstand als einer, der als gemeinsame Absicherung gegen reale Vorfälle vermittelt wird – etwa mit Verweis auf die Art von Vorfällen, die häufig mit gestohlenen oder wiederverwendeten Zugangsdaten und dem daraus resultierenden automatisierten Missbrauch alter Zugänge beginnen. Wer diesen Bezug herstellt, bekommt in der Regel mehr Kooperationsbereitschaft als mit einer rein formalen Anweisung von oben.

Was bleibt?

Vergessene SaaS-Zugänge verschwinden nicht von selbst, sie sammeln sich einfach weiter an, solange niemand sie systematisch findet, einem Owner zuordnet und regelmäßig überprüft. Die Frage ist weniger, ob ein Unternehmen solche Zugänge hat – das haben praktisch alle –, sondern ob jemand weiß, wo sie liegen, bevor es jemand anderes herausfindet.