Eigene Zugänge statt gemeinsamer Logins

• Weil der Beitrag schnell zeigt, wann ein gemeinsamer Login Probleme macht, warum eigene Zugänge fast immer besser sind und wie die Umstellung ohne Chaos klappt.
• Der Artikel übersetzt abstrakte Sicherheitsgrundsätze in einfache Regeln für kleine Teams. Statt allgemeiner Warnungen liefert er einen klaren Entscheidungsrahmen, typische Ausnahmen und konkrete Freigabe- und Notfallregeln für den Alltag.

Die Leserfrage sofort beantworten: Für kleine Teams sind eigene Zugänge pro Person in der Regel die bessere Lösung. Danach kurz zeigen, dass der Artikel nicht abstrakt bleibt, sondern Risiken, Ausnahmen und eine einfache Umstellung erklärt.

Woran merkt ein Team, dass ein gemeinsamer Login nicht mehr reicht?

Ein gemeinsamer Login wirkt am Anfang oft wie die einfachste Lösung. Eine Person legt das Konto an, alle kennen das Passwort, und das Thema scheint erledigt. Für ein kleines Team kippt das aber meist schnell, sobald mehrere Personen regelmäßig im selben Tool arbeiten.

Das wichtigste Warnsignal ist fehlende Nachvollziehbarkeit. Wenn später nicht mehr klar ist, wer eine Einstellung geändert, etwas gelöscht oder eine Freigabe erteilt hat, fehlt die saubere Zuordnung. Genau diese klare Zuordnung ist ein Kernpunkt offizieller Sicherheitsleitlinien: CISA empfiehlt individuelle Konten statt geteilter Konten, weil Verantwortlichkeit und Prüfbarkeit sonst leiden.

Ein zweites Warnsignal ist das ständige Weitergeben von Zugangsdaten. Das passiert oft schleichend: Das Passwort liegt im Chat, in einer Notiz oder wird bei Urlaub und Vertretung schnell weitergereicht. NIST weist ausdrücklich darauf hin, dass Menschen Passwörter, Einmalcodes und andere Anmeldeverfahren tatsächlich teilen. Schon das zeigt: Geteilte Zugänge sind kein seltener Sonderfall, aber eben auch kein sauberes Modell für den Alltag.

Spätestens problematisch wird es, wenn ein Passwortwechsel mehrere Personen zugleich trifft. Dann hängt die Arbeit des Teams an einem einzigen Zugang. Nach einem Vorfall, bei einem Mitarbeiterwechsel oder einfach nach einer Sicherheitsänderung entsteht schnell Unordnung. Wer hat schon das neue Passwort? Wer arbeitet noch mit alten Daten? Und wer sollte den Zugang jetzt eigentlich noch haben? Diese Reibung ist oft ein klares Zeichen, dass das Konto für mehrere Menschen falsch zugeschnitten ist.

Hinzu kommt die Grundlogik moderner Identitätsstandards. NIST geht davon aus, dass jede aktive Person ein eigenes Nutzerkonto haben sollte. Für kleine Teams heißt das nicht automatisch ein großes Rechtesystem. Es heißt vor allem: Sobald mehrere Personen mit einem wichtigen Tool arbeiten, sollten ihre Zugriffe getrennt sein. So lassen sich Aktionen einer Person zuordnen und Zugänge bei Bedarf einzeln ändern oder entziehen.

Eine einfache Prüffrage hilft im Alltag: Wenn Ihr Team bei einem Vorfall oder Mitarbeiterwechsel nicht in wenigen Minuten sagen kann, wer Zugriff hatte und wer zuletzt etwas geändert hat, reicht ein gemeinsamer Login meist nicht mehr.

Für selten genutzte Nebenkonten kann es enge Ausnahmen geben. Sobald aber echte Zusammenarbeit, Freigaben oder sensible Daten im Spiel sind, sprechen die Quellen klar für eigene Zugänge pro Person.

Mehr praktische Team-Regeln dazu finden Sie auch in unserem Beitrag 5 einfache Regeln für sichere Team-Zugänge.

Welche Probleme machen geteilte Logins im Alltag?

Ein geteilter Login wirkt zuerst praktisch. Alle nutzen dieselben Zugangsdaten, und niemand muss extra eingerichtet werden. Im Alltag entstehen daraus aber schnell drei Probleme: schlechte Übersicht, unklare Verantwortung und unnötiger Zusatzaufwand.

Das erste Problem ist die Passwortweitergabe. Ein gemeinsamer Zugang bedeutet fast immer, dass Benutzername und Passwort an mehrere Personen verteilt oder an einem gemeinsamen Ort gespeichert werden. Genau das macht die Sache fehleranfällig. Offizielle CISA-Leitfäden raten deshalb ausdrücklich davon ab, Passwörter zu teilen und empfehlen, gemeinsame oder generische Konten möglichst zu vermeiden. Microsoft beschreibt beim klassischen Teilen von Zugangsdaten denselben Nachteil: Die Daten müssen an alle Berechtigten weitergegeben oder gemeinsam abgelegt werden.

Das zweite Problem ist fehlende Klarheit. Wenn fünf Personen dasselbe Konto nutzen, sieht man später oft nur, dass etwas passiert ist, aber nicht sicher, wer es war. Einfach gesagt: Das Konto hat gehandelt, nicht die einzelne Person. CISA beschreibt genau diesen Verlust an Verantwortlichkeit. Microsoft nennt als Nachteil gemeinsam genutzter Zugangsdaten außerdem, dass man oft weder sauber sehen kann, wer Zugriff hat, noch wer die Anwendung tatsächlich genutzt hat.

Das dritte Problem zeigt sich bei Änderungen im Team. Verlässt eine Person das Team oder soll keinen Zugriff mehr haben, reicht es bei einem Sammelkonto nicht, nur diese eine Person zu entfernen. Meist muss das gemeinsame Passwort geändert und an alle übrigen Personen neu verteilt werden. Das kostet Zeit und führt leicht dazu, dass alte Daten noch irgendwo in Chats, Notizen oder Passwortlisten liegen.

Dazu kommt ein stilles Alltagsrisiko: Je mehr gemeinsame Konten ein Team hat, desto eher entstehen unsaubere Gewohnheiten. Menschen schreiben Passwörter auf, speichern sie an zu vielen Orten oder schicken sie schnell per Nachricht weiter. Microsoft nennt dieses Risiko ausdrücklich bei mehreren geteilten Zugangsdaten.

Die praktische Einordnung für kleine Teams: Ein gemeinsamer Login spart nur am Anfang ein paar Minuten. Danach wird es oft schwerer, den Überblick zu behalten, Änderungen sauber umzusetzen und Verantwortung klar zuzuordnen. Genau deshalb sind geteilte Logins meist keine gute Dauerlösung, auch wenn sie zunächst einfach wirken.

Was eigene Zugänge im Teamalltag einfacher machen

Eigene Zugänge lösen kein Problem nur auf dem Papier. Sie machen den Alltag im Team oft spürbar einfacher. Die Grundidee ist schlicht: Jede Person arbeitet mit dem eigenen Konto, zusammengearbeitet wird trotzdem in einem gemeinsamen Bereich des Tools. Genau so funktionieren viele bekannte Team-Tools. Bei Google Workspace hat jede Person ein eigenes Nutzerkonto. Bei GitHub melden sich Menschen mit ihrem persönlichen Konto an und arbeiten dann gemeinsam in einer Organisation.

Der erste Vorteil ist mehr Ordnung. Wenn jede Person einen eigenen Zugang nutzt, lässt sich besser zuordnen, wer etwas angelegt, geändert oder freigegeben hat. Das hilft nicht nur bei Sicherheit, sondern auch bei ganz normalen Rückfragen im Arbeitsalltag. Ein gemeinsamer Login macht solche Zuordnung schnell unklar.

Der zweite Vorteil sind passendere Rechte. Nicht jede Person braucht denselben Zugriff. Offizielle Herstellerdokumentation zeigt hier ein klares Muster: Rechte und Admin-Aufgaben lassen sich einzelnen Personen gezielt zuweisen. So muss nicht das ganze Team mit demselben vollen Zugang arbeiten.

Besonders deutlich wird der Nutzen beim Mitarbeiterwechsel. Kommt jemand neu ins Team, wird ein eigener Zugang hinzugefügt. Geht jemand, kann genau diese Person entfernt werden. In GitHub lässt sich ein Mitglied gezielt aus der Organisation entfernen und verliert damit den Zugriff auf geschützte Inhalte. Das ist viel sauberer, als ein gemeinsames Passwort nach jedem Wechsel überall zu ändern und neu zu verteilen.

Für kleine Teams ist das meist die praktischste Regel: persönliche Zugänge zuerst, Zusammenarbeit über Rollen, Teams oder Organisationsrechte. Wenn du tiefer in einfache Grundregeln einsteigen willst, passt dazu auch unser Beitrag zu sicheren Team-Zugängen.

Wann kann ein gemeinsamer Login trotzdem okay sein?

Kurz gesagt: nur in wenigen Ausnahmen.

Fuer normale Teamarbeit ist ein gemeinsamer Login keine gute Dauerloesung. Besser ist fast immer: jede Person hat ihren eigenen Zugang, und gemeinsame Inhalte werden ueber Freigaben geteilt. Genau so bauen es viele moderne Werkzeuge auf: eigene Konten pro Person, dazu gemeinsame Bereiche fuer Passwoerter, Dateien oder Projekte.

Eine Ausnahme kann ein rein technischer Zugang sein. Einfach gesagt: kein Mensch meldet sich damit an, sondern ein Skript, eine Automatisierung oder ein Hintergrundprozess. Solche Zugaenge sind fuer einen festen Zweck gedacht und sollten nicht als Sammelkonto fuer mehrere Personen missbraucht werden.

Eine zweite Ausnahme kann ein sehr kurzer Uebergang sein, zum Beispiel bei einem alten Tool, das noch keine getrennten Nutzer zulaesst. Dann sollte das Team offen sagen: Das ist nur eine Zwischenloesung. Es braucht einen festen Plan, bis wann eigene Zugaenge oder eine bessere Freigabe eingerichtet werden.

Wichtig ist auch der Notfallzugriff. Wenn eine wichtige Person ausfaellt oder sich nicht anmelden kann, ist ein gemeinsam bekanntes Master-Passwort nicht die beste Antwort. Sicherer ist ein geplanter Wiederherstellungsweg. Das bedeutet: Eine zweite verantwortliche Person kann helfen, den Zugriff sauber wiederherzustellen, ohne dass alle dasselbe Passwort kennen muessen.

Wenn ein gemeinsamer Login ausnahmsweise doch noch im Einsatz ist, sollte das Team mindestens diese Regeln festhalten:

• Nur fuer einen klaren Sonderfall. Nicht fuer die normale taegliche Arbeit.
• Moeglichst kurz nutzen. Von Anfang an ein Enddatum oder einen Wechselplan festlegen.
• Nur an wenige Personen geben. Nicht an das ganze Team weiterleiten.
• Sicher aufbewahren. Wenn Zugangsdaten geteilt werden muessen, dann ueber einen dafuer gedachten geteilten Tresor oder Passwort-Manager, nicht per Chat oder E-Mail.
• Verantwortung klar benennen. Eine Person pflegt den Zugang, eine zweite Person ist fuer den Notfall eingeplant.
• Nach jedem Wechsel pruefen. Wenn jemand das Team verlaesst oder die Aufgabe abgibt, muss der Zugang sofort geaendert oder ersetzt werden.

Die praktische Regel fuer kleine Teams ist daher einfach: Gemeinsame Inhalte ja, gemeinsamer menschlicher Login nur selten und nur befristet. Wenn mehrere Menschen dauerhaft mit einem Tool arbeiten, ist das fast immer ein Zeichen, dass jeder einen eigenen Zugang bekommen sollte.

Welche Regeln Freigaben, Vertretung und Notfälle brauchen

Eigene Zugänge funktionieren im Alltag nur dann wirklich gut, wenn das Team ein paar einfache Regeln festlegt. Die Grundidee ist: normale Arbeit läuft immer über persönliche Konten. Ein Notfallzugang ist nur für seltene Ausnahmen da, nicht als bequemer Zweitweg für den Alltag.

Für Freigaben heißt das: Rechte werden nicht über ein gemeinsames Passwort verteilt, sondern über klar benannte Rollen oder Gruppen. Eine Rolle ist einfach die Festlegung, was jemand in einem Tool darf. So bekommt jede Person nur den Zugriff, den sie für ihre Aufgabe wirklich braucht. Wenn sich die Aufgabe ändert, lässt sich die Berechtigung gezielt anpassen, ohne den Zugang des ganzen Teams umzubauen.

Für Vertretungen gilt dieselbe Logik. Wenn jemand im Urlaub ist oder kurzfristig ausfällt, sollte die Vertretung nicht einfach denselben Login nutzen. Besser ist ein eigener Zugang mit befristeten Rechten. Danach werden diese Zusatzrechte wieder entfernt. Das ist sauberer und später leichter nachvollziehbar.

Ein Notfallzugang kann trotzdem sinnvoll sein, etwa wenn ein kritisches System dringend erreichbar sein muss. Aber auch dann braucht er feste Leitplanken. Gute Sicherheitsleitlinien empfehlen dafür einen klaren Prozess: Der Zugriff sollte überwacht werden, auffällige Nutzung sollte geprüft werden, und der Einsatz sollte nicht folgenlos bleiben. Nach einem Notfall sollten Zugangsdaten oder Schlüssel erneuert und der Vorgang kurz nachgeprüft werden. So wird aus einem Ausnahmezugang kein stiller Dauerzugang.

Für kleine Teams reicht oft schon dieses Regelset:

• Persönliche Konten sind der Standard.
• Rechte nur so breit wie nötig vergeben.
• Vertretungen zeitlich begrenzen.
• Notfallzugänge nur für echte Ausnahmen einrichten.
• Nutzung von Notfallzugängen protokollieren und prüfen.
• Nach dem Einsatz Zugangsdaten erneuern und den Fall kurz nachbereiten.

Wenn ein Team diese Regeln früh festlegt, bleiben Freigaben übersichtlich. Vertretungen werden einfacher. Und Notfälle lassen sich abfangen, ohne dass ein gemeinsames Passwort dauerhaft durchs Team wandert.

Wie ein kleines Team auf eigene Zugänge umstellt

Die Umstellung muss kein großes Projekt sein. Für kleine Teams reicht oft eine klare Reihenfolge. Wichtig ist vor allem: Der gemeinsame Login sollte nicht der Dauerzustand bleiben. Herstellerdokumentation wie von Google legt Konten ausdrücklich auf eine einzelne Person aus. Das passt zu dem Grundprinzip dieses Artikels: Was einer Person zugeordnet werden kann, lässt sich später auch besser verwalten.

Ein praktischer Start ist eine kurze Liste aller betroffenen Tools. Markiert zuerst die Konten, die heute von mehreren Personen genutzt werden. Danach legt ihr für jede beteiligte Person einen eigenen Zugang an. Erst wenn diese persönlichen Zugänge funktionieren, sollten Rechte verteilt und der alte Sammelzugang schrittweise geleert werden.

Im Alltag ist genau das der große Vorteil persönlicher Konten: Wenn jemand das Team verlässt oder nur vorübergehend keine Berechtigung mehr braucht, kann der Zugriff gezielt gesperrt oder entfernt werden. Bei Atlassian ist genau dieses Vorgehen vorgesehen: Nutzer lassen sich sperren oder entfernen, ohne dass das ganze Team denselben Login neu organisieren muss.

Für die Umstellung hilft diese einfache Reihenfolge:

1. Gemeinsame Logins erfassen.
   Schreibt auf, welche Tools heute mit einem Sammelkonto genutzt werden.

2. Persönliche Zugänge anlegen.
   Jede Person bekommt ihr eigenes Konto.

3. Rechte passend verteilen.
   Nicht alle brauchen Admin-Rechte. Oft reichen einfache Rollen für Nutzung, Bearbeitung oder Verwaltung.

4. Arbeitsinhalte sauber übergeben.
   Wenn Dateien, Ordner oder andere Inhalte bisher am Sammelkonto hingen, sollten sie geordnet an reale Personen oder Team-Bereiche übertragen werden. Dropbox beschreibt dafür die Möglichkeit, Kontoinhalte an andere Personen zu übertragen.

5. Sammelzugang leeren und abschalten.
   Erst wenn alle arbeiten können und wichtige Inhalte umgezogen sind, wird das alte gemeinsame Konto deaktiviert.

Gerade bei Mitarbeiterwechseln spart das später viel Aufwand. Statt überall Passwörter zu ändern oder weiter mit einem Alt-Konto zu leben, wird nur der Zugang der betroffenen Person gesperrt. Inhalte können, je nach Tool, an andere Personen übertragen werden. So bleibt die Arbeit im Team erhalten, ohne dass ein unscharfer Gemeinschaftszugang weitergeführt werden muss.

Wenn ein Tool keine saubere Mehrnutzerfunktion hat, ist Vorsicht sinnvoll. Dann kann eine Übergangslösung nötig sein. Aber auch dann bleibt die bessere Richtung klar: persönliche Konten zuerst, Sammelzugänge nur so kurz und so eng begrenzt wie möglich.

Wer den Umstieg klein halten will, startet am besten mit den wichtigsten Diensten: E-Mail, Dateispeicher, Projekttools und Abrechnung. Schon diese wenigen Schritte bringen meist deutlich mehr Ordnung in Freigaben, Offboarding und Vertretung.

Die eine Prüffrage für neue Tools

Für kleine Teams reicht oft eine einzige Grundregel: Sobald ein Tool von mehr als einer Person genutzt wird, sollte jede Person einen eigenen Zugang bekommen. Das ist nicht nur sauberer, sondern im Alltag fast immer einfacher.

Der Kern der Entscheidung ist Nachvollziehbarkeit. Also die Frage: Kann man später noch klar sehen, wer etwas gesehen, geändert, freigegeben oder gelöscht hat? Wenn diese Zuordnung wichtig ist, passt ein gemeinsamer Login nicht gut. Genau darauf zielen Sicherheitsleitlinien ab: Konten sollen einzelnen Personen zugeordnet sein, damit Verantwortung und Handlungen klar bleiben. Auch PCI DSS lehnt das Teilen von Authentifizierungsdaten zwischen Nutzern ab.

Daraus wird eine sehr praktische Prüffrage für jedes neue Tool:

Muss man hier später wissen, wer was getan hat oder braucht jemand einen eigenen Verantwortungsbereich?

Wenn die Antwort ja ist, dann spricht fast alles für eigene Zugänge.

Das betrifft nicht nur sensible Systeme. Es gilt auch für Alltags-Tools, etwa bei E-Mail, Cloud-Speicher, Website-Verwaltung, Buchhaltung, Werbung oder Support. Schon dort entstehen schnell Freigaben, Änderungen oder Löschungen, die später einer Person zugeordnet werden sollten.

Gemeinsame Logins bleiben höchstens enge Ausnahmen. Etwa bei alten Tools ohne Mehrnutzerfunktion oder bei rein technischen Konten für Automatisierungen. Für Menschen im Team sollte aber der Normalfall klar sein: eigener Zugang statt gemeinsames Passwort.

Wenn Sie sich bei einem neuen Tool unsicher sind, hilft daher dieser Merksatz: Sobald Handlungen einer Person zugeordnet werden müssen, ist ein Sammellogin die falsche Wahl.

Welche kurze Prüffrage hilft bei jedem neuen Tool?

Die einfachste Regel fuer kleine Teams ist kurz: Wenn mehrere Personen ein Tool nutzen, sollte jede Person einen eigenen Zugang haben.

Die passende Prueffrage dazu lautet: Muss spaeter klar sein, wer etwas gesehen, geaendert, freigegeben oder geloescht hat? Wenn die Antwort ja ist, ist ein gemeinsamer Login fast immer die falsche Wahl.

Genau hier liegt der Kern der Entscheidung. Ein geteilter Login macht vieles unklar. Dann laesst sich oft nicht mehr sauber sagen, wer eine Datei entfernt, eine Rechnung freigegeben oder eine wichtige Einstellung veraendert hat. Offizielle Leitlinien empfehlen deshalb getrennte Konten pro Person. So bleiben Handlungen nachvollziehbar und Zugaenge lassen sich einfacher steuern.

Fuer den Alltag hilft deshalb eine sehr einfache Denkweise: Sobald ein Tool einen eigenen Verantwortungsbereich beruehrt, braucht die Person auch ihren eigenen Zugang. Das gilt besonders bei Daten, Dateien, E-Mails, Freigaben oder Einstellungen, die Folgen fuer Kunden, Finanzen oder den laufenden Betrieb haben.

Geteilte Logins sind hoechstens eine enge Ausnahme. Das kann vorkommen, wenn ein altes Tool technisch keine getrennten Nutzer unterstuetzt oder wenn es voruebergehend keine sinnvolle Alternative gibt. Dann sollte das Team die Ausnahme aber klein halten: nur fuer wenige Personen, mit kontrolliertem Zugriff und mit regelmaessiger Pruefung, ob die gemeinsame Nutzung noch noetig ist.

Die Merkhilfe fuer neue Tools ist damit einfach:

Braucht hier jemand einen eigenen Verantwortungsbereich oder muss man spaeter wissen, wer was getan hat? Wenn ja, eigene Zugaenge.

Damit bleibt die Entscheidung auch ohne lange Sicherheitsdiskussion klar: Standard sind persoenliche Konten. Gemeinsame Logins brauchen einen echten Ausnahmegrund und feste Regeln.

Was B2B-Teams daraus ableiten sollten

Mit einer klaren Merkhilfe enden: Wenn später klar sein muss, wer etwas getan hat, braucht die Person ihren eigenen Zugang. Außerdem den Nutzen der kleinen Team-Regeln noch einmal knapp zusammenfassen.

• Ab wann ist ein gemeinsamer Login für ein kleines Team nicht mehr sinnvoll? Alltagssignale wie fehlende Übersicht, improvisierte Passwortweitergabe und unklare Zuständigkeit erklären.
• Welche konkreten Probleme entstehen durch geteilte Logins? Nachvollziehbarkeit, Verantwortung, Passwortwechsel und Teamwechsel einfach erklären.
• Warum sind eigene Zugänge pro Person meist besser? Klare Zuordnung, gezielte Rechte und einfacheres Entfernen einzelner Personen zeigen.
• Gibt es überhaupt Ausnahmen, in denen ein gemeinsamer Login noch okay ist? Nur enge Ausnahmefälle nennen und deutlich begrenzen.
• Was wird bei Mitarbeiterwechseln mit eigenen Zugängen einfacher? Einladen, sperren, entfernen und Inhalte geordnet übergeben erklären.

Quellenlage und offene Punkte

Die Einordnung stuetzt sich auf 8 Quellen. Besonders wichtig ist, dass die wichtigsten Themenbereiche jeweils mit eigener Quellenbasis und nachvollziehbarer Zuordnung behandelt werden.

• Viele starke Quellen sind allgemeine Sicherheitsleitlinien oder Herstellerdokumentation und nicht speziell für kleine Agenturen geschrieben.
• Mehrere Praxisempfehlungen für kleine Teams sind redaktionelle Verdichtungen aus gut belegten Grundsätzen, keine wörtlichen Behördenformulierungen.
• Einige Ausnahmefälle, etwa alte Tools ohne Mehrnutzerfunktion, sind praxisnahe Einordnungen statt direkt normierte Regeln.
• Herstellerquellen zeigen oft ihr eigenes Produktmodell; verallgemeinert werden nur die klar übertragbaren Muster.
• Es fehlen belastbare unabhängige Daten dazu, wie häufig kleine Teams tatsächlich noch Sammelkonten nutzen.