Schatten-IT im Jahr 2026 sieht völlig anders aus als noch vor fünf Jahren. Das Problem sind jetzt KI-Agenten mit persistenten OAuth-Tokens, LLM-Sitzungen, die stillschweigend proprietären Quellcode verarbeiten, und verwaiste SaaS-Accounts, an deren Einrichtung sich niemand erinnert. Jedes einzelne Element erweitert die Angriffsfläche des Unternehmens weit über das hinaus, wofür ein traditioneller Netzwerkperimeter konzipiert war.

Laut dem State of Shadow AI-Bericht von UpGuard nutzen über 80 % der Mitarbeiter nicht genehmigte KI-Tools. Eine Gartner-Umfrage unter 302 Cybersicherheitsverantwortlichen (März–Mai 2025) ergab, dass 69 % der Organisationen entweder vermuten oder bestätigt haben, dass Mitarbeiter verbotene öffentliche GenAI-Tools nutzen. Gartner prognostiziert, dass bis 2030 mehr als 40 % der Unternehmen einen Sicherheits- oder Compliance-Vorfall im Zusammenhang mit nicht autorisierter Schatten-KI erleben werden.

Der DTEX/Ponemon-Bericht 2026 zu den Kosten von Insider-Risiken beziffert die jährlichen Kosten durch Insider-Fahrlässigkeit — hauptsächlich verursacht durch Schatten-KI — auf 10,3 Millionen US-Dollar pro Organisation. Diese Summe umfasst Vorfälle ohne böswillige Absicht: lediglich Mitarbeiter, die Tools nutzen, die die IT nie genehmigt hat, und Budgets, die stillschweigend Infrastruktur finanzieren, die niemand sehen oder absichern kann.

Wichtigste Erkenntnisse

• Schatten-IT im Jahr 2026 ist ebenso ein KI-Problem wie ein SaaS-Problem. KI-Agenten mit persistenten OAuth-Tokens, LLM-Sitzungen, die proprietären Quellcode verarbeiten, und verwaiste SaaS-Accounts, die ihre Besitzer überdauern, stellen jetzt die Risiken mit der höchsten Schwere dar.
• Schatten-KI unterscheidet sich grundlegend von traditioneller Schatten-IT. Nicht genehmigte SaaS-Tools speichern Daten am falschen Ort. Nicht genehmigte KI-Tools verarbeiten, analysieren und handeln auf deren Basis.
• Das finanzielle Risiko ist quantifiziert. IBMs Cost of a Data Breach Report 2025 ergab, dass die Beteiligung von Schatten-KI 670.000 US-Dollar zu den durchschnittlichen Kosten eines Datenlecks von 4,44 Millionen US-Dollar hinzufügt. Der DTEX/Ponemon-Bericht 2026 zu den Kosten von Insider-Risiken beziffert die jährlichen Kosten durch KI-bedingte Insider-Fahrlässigkeit auf 10,3 Millionen US-Dollar pro Organisation.
• Die Erkennung erfordert mindestens fünf parallel arbeitende Datenquellen. CASB, DNS-Protokollanalyse, EDR, Ausgabendatenprüfung und E-Mail-Integrations-Scans decken jeweils einen anderen Teil der Umgebung ab. Keine einzelne Methode erfasst gleichzeitig persönliche Geräte, Free-Tier-Accounts und verwaltete Endpunkte.
• Europäische Organisationen sind mehrschichtigen regulatorischen Risiken ausgesetzt. Nicht genehmigte SaaS-Tools verstoßen gegen DSGVO-Artikel 28, sobald sie personenbezogene Daten ohne unterzeichneten Auftragsverarbeitungsvertrag verarbeiten. NIS2-Artikel 21 behandelt ungeprüfte Drittanbieter-Tools als Lieferkettenrisiko. DORA-Artikel 28 verlangt von Finanzunternehmen, jeden IKT-Anbieter zu registrieren — ob Schatten oder nicht.
• Sperren ohne Ermöglichen scheitert durchgehend. Fast die Hälfte der Mitarbeiter nutzt persönliche KI-Accounts weiter, nachdem eine organisatorische Sperre verhängt wurde. Die wirksame Antwort besteht darin, den genehmigten Weg schneller als den Workaround zu gestalten: ein schlanker Genehmigungsworkflow, zentralisiertes Credential-Management und ein Security-Awareness-Programm, das das Risiko greifbar macht.
• Das 6-Schritte-Framework zur Schatten-IT-Governance — Entdecken und Klassifizieren, Credentials zentralisieren, Richtlinien etablieren, Genehmigungen optimieren, Offboarding automatisieren, Security-Awareness aufbauen — adressiert sowohl die technischen als auch die verhaltensbezogenen Aspekte des Problems. Tooling übernimmt die Erkennung. Das Framework verändert die Anreizstruktur, die die Schatten-IT-Nutzung überhaupt erst antreibt.

Was ist Schatten-IT?

Schatten-IT ist jede Technologie (Software, Cloud-Service, KI-Tool oder Hardware), die Mitarbeiter für die Arbeit ohne Wissen oder formale Genehmigung der IT nutzen. Sie reicht von einem persönlichen Dropbox-Ordner zum Teilen von Projektdateien bis hin zu einem KI-Coding-Assistenten mit OAuth-Zugriff auf Produktions-Repositories. Der gemeinsame Nenner: keine Sicherheitsüberprüfung, kein Beschaffungsnachweis, kein Audit-Trail.

Schatten-IT ist kein Nischenproblem. Gartner beziffert den Anteil der IT-Ausgaben für nicht genehmigte Tools in Großunternehmen auf 30-40 %. Die Analyse von Harmonic Security von 22,4 Millionen Unternehmens-KI-Prompts identifizierte 665 verschiedene generative KI-Tools, die in Unternehmensumgebungen laufen — doch nur 40 % dieser Organisationen hatten ein offizielles KI-Abonnement erworben. Der GenAI-Traffic stieg allein im Jahr 2024 um mehr als 890 %.

Schatten-IT vs. Schatten-KI: Wie sich die Risiken vergleichen

Was treibt Mitarbeiter zur Nutzung von Schatten-IT?

Mitarbeiter greifen zu nicht genehmigten Tools, wenn genehmigte Alternativen zu langsam, zu eingeschränkt oder schlicht noch nicht vorhanden sind. Die Reibung ist die Ursache: Ein Entwickler, der drei Wochen auf einen lizenzierten KI-Assistenten wartet, wird bis zum Ende des Tages einen kostenlosen gefunden haben.

Drei Muster wiederholen sich in Organisationen jeder Größe:

• Geschwindigkeit vor Prozess. Mitarbeiter greifen zu dem, was die Arbeit am schnellsten erledigt. Wenn genehmigte Tools nicht mit dem mithalten, was außerhalb des Unternehmens frei verfügbar ist, ist die Wahl offensichtlich: Das nutzen, was funktioniert.
• Beschaffungsverzögerung. Unternehmens-Softwarezyklen laufen in Quartalen. KI-Tooling wird in Wochen ausgeliefert. Bis die IT ein Tool evaluiert und genehmigt hat, haben Mitarbeiter bereits Workflows um dessen Free-Tier-Äquivalent aufgebaut.
• Funktionale Lücken. Genehmigte Tools decken oft keine Randfälle ab. Ein Datenanalyst, der eine schnelle Python-Umgebung benötigt, oder ein Designer, der einen bestimmten Bildgenerator braucht, wird zu dem greifen, was funktioniert, nicht zu dem, was auf der genehmigten Liste steht.
• Keine Feedback-Schleife. Mitarbeiter melden selten die Tools, die sie nutzen, weil es keinen einfachen Kanal dafür gibt. Die IT weiß nicht, was zu steuern ist. Die Sicherheitsabteilung weiß nicht, was zu prüfen ist. Die Kluft zwischen tatsächlicher Tool-Nutzung und genehmigtem Inventar wächst stillschweigend.
• Verbote halten nicht. Fast die Hälfte der Mitarbeiter nutzt persönliche KI-Accounts weiter, nachdem eine organisatorische Sperre verhängt wurde. Verbote eliminieren Schatten-IT nicht. Sie drängen sie nur aus dem Blickfeld, was die Erkennung erschwert und die Reaktion verlangsamt.

Diese Muster sind eine vorhersehbare Reaktion auf Governance-Strukturen, die nicht mit der Geschwindigkeit mitgehalten haben, mit der sich Tooling entwickelt. Diese Lücke macht Schatten-IT zu einem systemischen Risiko statt zu einem Disziplinproblem.

Die Entwicklung der Schatten-IT im Jahr 2026

Schatten-IT im Jahr 2026 geht weit über unverwalteten Cloud-Speicher hinaus. Sie umfasst jetzt KI-Tools, autonome Agenten und ganze SaaS-Ökosysteme, die die IT nie genehmigt, nie inventarisiert hat und nicht überwachen kann. Das durchschnittliche Unternehmen betreibt 305 SaaS-Anwendungen, gibt jährlich 55,7 Millionen US-Dollar für SaaS aus und hat ein Wachstum der Ausgaben für KI-native Apps von 108 % im Jahresvergleich erlebt — wobei der Großteil dieses Wachstums schneller stattfindet, als Governance-Teams es verfolgen können.

Von SaaS-Wildwuchs zu Schatten-KI

Die Zahl von 305 Anwendungen stammt aus dem Zylo SaaS Management Index 2026, der auf realen Ausgabendaten aus Tausenden von Organisationen basiert. Ein erheblicher Anteil dieser Anwendungen wurde nie formal genehmigt. Mitarbeiter adoptieren Tools eigenständig, und die IT erfährt Monate später davon, wenn überhaupt.

Schatten-KI beschleunigt diese Dynamik. Kostenlose KI-Assistenten, Code-Generatoren und autonome Agenten wurden schneller allgemein verfügbar, als Beschaffungszyklen reagieren konnten. Der Check Point Cloud Security Report 2026 ergab, dass 78-80 % der Arbeitnehmer persönliche KI-Tools bei der Arbeit nutzen. Die meisten dieser Sitzungen finden über persönliche Accounts statt, außerhalb von SSO, außerhalb von DLP und ohne Audit-Trail.

Der Unterschied sollte präzise benannt werden: 

• Traditionelle Schatten-IT erzeugt unverwaltete Datenresidenz: Dateien, die in einem nicht genehmigten Service liegen. 
• Schatten-KI erzeugt unverwaltete Datenverarbeitung: proprietäre Informationen, die von Systemen analysiert, zusammengefasst und verarbeitet werden, die Ihr Sicherheitsteam nie überprüft hat.

Warum die Angriffsfläche weiter wächst

Drei strukturelle Kräfte treiben dies an:

• Remote- und Hybridarbeit hat den Netzwerkperimeter als natürlichen Kontrollpunkt entfernt. Mitarbeiter, die von zu Hause aus arbeiten, adoptieren Tools, ohne Anfragen über die IT zu leiten.
• Free-Tiers sind überall. Die meisten SaaS-Tools bieten einen kostenlosen Einstieg. Keine Bestellung, kein Genehmigungsticket, keine Sichtbarkeit.
• Die Verbreitung von KI-Agenten hat die Einsätze verändert. Agenten arbeiten über delegierte OAuth-Berechtigungen — sie lesen Daten, lösen Workflows aus und ändern Datensätze autonom. Ein Entwickler, der einen KI-Coding-Assistenten mit seinem GitHub-Account verbindet, hat diesem Agenten möglicherweise Lese-/Schreibzugriff auf Repositories gewährt. Wenn der Entwickler das Unternehmen verlässt, bleibt die OAuth-Berechtigung bestehen.

Gartner prognostiziert, dass bis 2027 75 % der Mitarbeiter Technologie außerhalb der Sichtbarkeit der IT erwerben, modifizieren oder erstellen werden — ein Anstieg von 41 % im Jahr 2022. Die Richtung ist eindeutig.

Die verborgenen Risiken der Schatten-IT (die Realität 2026)

Schatten-IT im Jahr 2026 ist nicht nur ein Datenleck-Problem. Unverwaltete Tools schaffen persistenten unbefugten Zugriff, exponieren Credentials, lösen Regulierungsverstöße aus und speisen zunehmend Unternehmensdaten in KI-Modelle ein, die kein Sicherheitsteam genehmigt hat oder überwachen kann.

Der Schatten-KI-Risikomultiplikator: Datenverarbeitung vs. Datenspeicherung

Traditionelle Schatten-IT speichert Daten am falschen Ort. Schatten-KI macht etwas damit. Das Einfügen eines Kundenvertrags in ein öffentliches LLM sendet diese Daten an mindestens drei Orte: eine Trainingspipeline, ein Logging-System und potenziell ein Modell, das andere Benutzer abfragen können.

IBMs Cost of a Data Breach Report 2025 beziffert dies: Datenlecks mit hohem Schatten-KI-Anteil fügten durchschnittlich 670.000 US-Dollar zu den Gesamtkosten des Datenlecks hinzu, wodurch der Durchschnitt bei Schatten-KI-Beteiligung auf etwa 5,11 Millionen US-Dollar stieg — gegenüber einem globalen Basiswert von 4,44 Millionen US-Dollar. Derselbe Bericht ergab, dass 97 % der KI-bezogenen Sicherheitsvorfälle Systeme ohne angemessene Zugriffskontrollen betrafen.

Credential-Exposition und Passwort-Wiederverwendung

Schatten-IT ist im Kern ein Identitätsproblem. Jede nicht genehmigte App ist ein neuer Account. Jeder neue Account ist ein Credential. Und die meisten dieser Credentials werden wiederverwendet.

Laut dem Data Breach Investigations Report 2026 von Verizon tauchten gestohlene Credentials bei 39 % aller bestätigten Datenlecks auf, nicht nur als initialer Zugriffsvektor, sondern durchgehend bei Lateral Movement und Persistenz. Wenn ein Mitarbeiter sein Unternehmenspasswort bei einem kostenlosen SaaS-Tool wiederverwendet, das später ein Datenleck erleidet, müssen Angreifer nichts knacken. Sie melden sich einfach an.

Infostealer verschärfen dies. Im Jahr 2025 indexierte Recorded Future 1,95 Milliarden malware-basierte Credential-Expositionen, von denen 31 % aktive Session-Cookies enthielten, die MFA vollständig umgehen. Schatten-IT-Accounts, unüberwacht, oft ohne konfiguriertes MFA, sind genau die Art von Ziel, für die Infostealer gebaut sind.

Das Passwort-Wiederverwendungsrisiko ist ein dokumentiertes, automatisiertes Angriffsmuster im industriellen Maßstab.

Der Offboarding-Albtraum: Verwaiste Accounts

Wenn ein Mitarbeiter das Unternehmen verlässt, werden seine verwalteten Accounts deprovisioniert. Seine Schatten-IT-Accounts nicht. Niemand weiß, dass sie existieren.

Der Figma-Workspace des ehemaligen Entwicklers, die persönliche HubSpot-Testversion des Vertriebsmitarbeiters mit exportierten CRM-Daten, die Notion-Seite des Auftragnehmers mit internen Architekturnotizen: All dies bleibt unbegrenzt bestehen, nachdem die Person das Unternehmen verlassen hat.

Die Konsequenzen können schwerwiegend sein. In einem dokumentierten Fall griff ein ehemaliger Cisco-Mitarbeiter fünf Monate nach seiner Kündigung auf eine in AWS gehostete virtuelle Maschinen-Infrastruktur zu und löschte 456 virtuelle Maschinen, wodurch mehr als 16.000 WebEx-Teams-Accounts fast zwei Wochen lang offline waren.

Das US-Justizministerium bestätigte, dass der Vorfall Cisco etwa 2,4 Millionen US-Dollar an Behebungskosten und Kundenerstattungen kostete, und der ehemalige Mitarbeiter wurde zu 24 Monaten Bundesgefängnis verurteilt (United States v. Sudhish Kasaba Ramesh, Case No. 5:20-cr-00102). Das war ein verwaltetes System. Verwaiste Schatten-IT-Accounts sind schwieriger zu finden und brauchen länger zum Schließen — falls sie überhaupt geschlossen werden.

KI-Agenten und unverwaltete OAuth-Berechtigungen

Dies ist die Bedrohung, die die meisten Organisationen noch nicht verfolgen. KI-Agenten arbeiten über delegierte OAuth-Berechtigungen: Ein Benutzer gewährt dem Agenten Zugriff auf Google Drive, GitHub oder Slack, und der Agent kann kontinuierlich auf diesem Zugriff lesen, schreiben und handeln — nicht nur während der Sitzung.

Wenn sich der Benutzer abmeldet, bleibt die OAuth-Berechtigung bestehen. Wenn der Benutzer das Unternehmen verlässt, bleibt die OAuth-Berechtigung bestehen. Der Agent hat möglicherweise noch Wochen oder Monate nach dem Ausscheiden der Person, die ihn autorisiert hat, Zugriff auf Unternehmens-Repositories, E-Mail-Threads und freigegebene Laufwerke.

Der Okta-Bericht AI Agents at Work 2026 ergab, dass 58 % der Organisationen im vergangenen Jahr einen KI-bezogenen Sicherheitsvorfall erlitten haben, doch 90 % der Führungskräfte gaben an, keinen vollständigen Überblick darüber zu haben, welche KI-Agenten in ihrer Organisation arbeiten. Die Lücke zwischen Adoption und Governance ist der Ort, an dem das Risiko lebt.

Compliance-Verstöße und regulatorische Bußgelder

Nicht genehmigte Apps erfüllen nicht die Anforderung von DSGVO-Artikel 32 nach „geeigneten technischen und organisatorischen Maßnahmen" zum Schutz personenbezogener Daten. Sie erfüllen nicht die technischen Schutzanforderungen von HIPAA unter 45 CFR § 164.312. Sie erfüllen nicht PCI-DSS-Anforderung 12.8 für die Verwaltung von Drittanbieter-Dienstleistern.

Der EU AI Act fügt eine weitere Ebene hinzu. Hochrisiko-KI-Systeme, die ohne ordnungsgemäße Governance eingesetzt werden, können mit Strafen von bis zu 15 Millionen Euro oder 3 % des weltweiten Jahresumsatzes gemäß Artikel 99(4) belegt werden.

Der Finanzdienstleistungssektor hat bereits erfahren, wie regulatorische Durchsetzung in der Praxis aussieht. Im September 2022 verhängten die SEC und CFTC gegen 16 Wall-Street-Firmen zusammen 1,8 Milliarden US-Dollar Bußgelder, weil Mitarbeiter WhatsApp und andere nicht genehmigte Messaging-Apps für geschäftliche Kommunikation nutzten — ein klassischer Schatten-IT-Verstoß, den die Aufsichtsbehörden als Verstoß gegen die Aufzeichnungspflicht behandelten. Die Pressemitteilung der SEC macht deutlich, dass die „weit verbreitete und langjährige" Nutzung von Off-Channel-Kommunikation kein mildernder Faktor ist; es ist ein erschwerender.

Europäische regulatorische Exposition: DSGVO, NIS2 und DORA

Für Organisationen, die in der EU tätig sind, erzeugt Schatten-IT mehrschichtige regulatorische Exposition über drei verschiedene Rahmenwerke hinweg. Jedes zielt auf eine andere Dimension des Problems ab, und zusammen lassen sie sehr wenig Raum für „wir wussten es nicht".

DSGVO: Nicht autorisierte Auftragsverarbeiter und grenzüberschreitende Übermittlungen

DSGVO-Artikel 32 ist die Vorschrift, die die meisten Organisationen zitieren. Aber Artikel 28 ist derjenige, gegen den Schatten-IT zuerst verstößt. Jedes nicht genehmigte SaaS-Tool, das personenbezogene Daten verarbeitet, ist nach DSGVO-Terminologie ein Auftragsverarbeiter. Artikel 28 verlangt vor Beginn der Verarbeitung einen schriftlichen Auftragsverarbeitungsvertrag (AV-Vertrag) mit jedem solchen Auftragsverarbeiter. Ein Mitarbeiter, der sich mit seiner geschäftlichen E-Mail für ein kostenloses KI-Tool anmeldet und es mit Kundendaten füttert, hat eine nicht autorisierte Auftragsverarbeiterbeziehung geschaffen — ohne AV-Vertrag, ohne Due Diligence und ohne Nachweis.

Die Artikel 44 bis 49 verstärken die Exposition. Viele US-basierte SaaS- und KI-Tools übermitteln personenbezogene Daten außerhalb des Europäischen Wirtschaftsraums. Ohne einen gültigen Übermittlungsmechanismus (Standardvertragsklauseln, Angemessenheitsbeschluss oder verbindliche interne Datenschutzvorschriften) verstößt diese Übermittlung gegen die DSGVO, unabhängig davon, wie das Tool eingeführt wurde. Mitarbeiter, die Tools eigenständig auswählen, haben keine Sichtbarkeit darüber, wo Daten verarbeitet oder gespeichert werden.

Europäische Datenschutzbehörden haben beide Vorschriften durchgesetzt. Im Jahr 2023 verhängte die Irish Data Protection Commission gegen Meta ein Bußgeld von 1,2 Milliarden Euro gemäß Artikel 46 für rechtswidrige Datenübermittlungen in die USA — das höchste DSGVO-Bußgeld bisher. Obwohl dieser Fall einen Plattformbetreiber und keinen Unternehmensendnutzer betraf, gilt das zugrunde liegende Prinzip: Das Fehlen eines gültigen Übermittlungsmechanismus ist ein Verstoß, unabhängig von der Absicht.

NIS2: Zugriffskontrolle und Lieferkettenpflichten

Die NIS2-Richtlinie (Richtlinie EU 2022/2555), die seit Oktober 2024 für wesentliche und wichtige Einrichtungen in der EU gilt, adressiert direkt die Bedingungen, die Schatten-IT schafft. Artikel 21(2) legt zehn Mindestmaßnahmen für das Cybersicherheits-Risikomanagement fest. Drei sind direkt von Schatten-IT betroffen:

• Artikel 21(2)(d): Sicherheit der Lieferkette, einschließlich Sicherheitsaspekte hinsichtlich der Beziehungen zwischen jeder Einrichtung und ihren direkten Lieferanten oder Dienstleistern. Jedes nicht genehmigte SaaS-Tool ist faktisch eine ungeprüfte Lieferantenbeziehung.
• Artikel 21(2)(i): Richtlinien und Verfahren bezüglich der Nutzung von Kryptographie und, wo angemessen, Verschlüsselung.
• Artikel 21(2)(j): Personalsicherheit, Zugriffskontrollrichtlinien und Asset-Management.

NIS2-Strafen erreichen 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes für wesentliche Einrichtungen und 7 Millionen Euro oder 1,4 % für andere. Die Umsetzung in den Mitgliedstaaten variiert, aber das Rahmenwerk ist jetzt in der gesamten EU aktiv.

Die NIS2-Compliance-Seite von Passwork erläutert detailliert, wie zentralisiertes Credential-Management auf die Anforderungen von NIS2-Artikel 21 abgestimmt ist.

DORA: IKT-Drittparteirisiko für Finanzunternehmen

Der Digital Operational Resilience Act (DORA, Verordnung EU 2022/2554) gilt seit Januar 2025 für Finanzunternehmen, die in der EU tätig sind: Banken, Versicherer, Wertpapierfirmen, Zahlungsdienstleister und ihre kritischen IKT-Anbieter. Artikel 28 verlangt von Finanzunternehmen, ein Register aller IKT-Drittanbieter zu führen und vor der Einbindung eines neuen Anbieters eine vorvertragliche Due Diligence durchzuführen.

Schatten-SaaS fällt direkt in den Anwendungsbereich. Ein Mitarbeiter bei einer Bank, der ein nicht genehmigtes Projektmanagement-Tool oder einen KI-Assistenten einführt, hat eine nicht registrierte IKT-Drittparteibeziehung geschaffen. Nach DORA ist das kein IT-Governance-Problem; es ist ein regulatorischer Verstoß. Die Europäischen Aufsichtsbehörden (EBA, ESMA, EIOPA) haben die Befugnis zur Untersuchung und Sanktionierung. In Jurisdiktionen, in denen die nationale Umsetzung dies vorsieht, kann auch eine strafrechtliche Haftung auf Managementebene gelten.

Für IT- und Compliance-Teams im Finanzsektor ist die Erkennung von Schatten-IT nicht mehr nur Best Practice. Nach DORA ist es eine gesetzliche Pflicht.

Die finanziellen Auswirkungen: Quantifizierung der Kosten von Schatten-IT

Schatten-IT verursacht zwei unterschiedliche Kostenarten: Datenleck-Exposition und verschwendete Ausgaben. IBMs Cost of a Data Breach Report 2025 ergab, dass die Beteiligung von Schatten-KI 670.000 US-Dollar zu den durchschnittlichen Kosten eines Datenlecks von 4,44 Millionen US-Dollar hinzufügt. Auf der Ausgabenseite beziffert der Zylo SaaS Management Index 2026 die durchschnittlich verschwendeten Lizenzausgaben auf 21 Millionen US-Dollar pro Jahr — verursacht durch redundante Tools, ungenutzte Plätze und Käufe, von denen die IT nie wusste.

IBM-Daten 2025: Die 670.000-Dollar-Schatten-KI-Strafe

IBMs Cost of a Data Breach Report 2025 ist der maßgeblichste verfügbare Benchmark zum Verständnis der finanziellen Konsequenzen unverwalteter KI. Die Hauptzahlen:

• Globale durchschnittliche Kosten eines Datenlecks: 4,44 Millionen US-Dollar
• Die Beteiligung von Schatten-KI fügt diesem Durchschnitt 670.000 US-Dollar hinzu, wodurch die Zahl bei Schatten-KI-Beteiligung auf etwa 5,11 Millionen US-Dollar steigt
• 97 % der KI-bezogenen Vorfälle betrafen Systeme ohne angemessene Zugriffskontrollen
• 20 % der Organisationen meldeten 2025 einen Sicherheitsvorfall, der direkt mit Schatten-KI verbunden war

Der Aufschlag von 670.000 US-Dollar ist der inkrementelle Aufwand für Untersuchung, Eindämmung, Benachrichtigung und Behebung, wenn KI-Systeme beteiligt sind, von denen Sicherheitsteams nichts wussten.

Verschwendete IT-Ausgaben und redundante Lizenzierung

Organisationen zahlen für genehmigte Tools, während Mitarbeiter stillschweigend kostenlose oder günstigere Alternativen einführen. Das Ergebnis: doppelte Funktionalität, verwaiste Lizenzen und Ausgaben, für die niemand verantwortlich ist.

Laut dem Zylo SaaS Management Index 2026 verschwendet die durchschnittliche Organisation jährlich 21 Millionen US-Dollar allein für ungenutzte SaaS-Lizenzen — und die durchschnittliche Nutzungsrate über Unternehmens-SaaS-Portfolios hinweg liegt bei nur 47 %. Für mittelständische Unternehmen mit 500 oder weniger Mitarbeitern erreicht diese Zahl immer noch 4,2 Millionen US-Dollar jährlich an verschwendeten Lizenzausgaben.

Das Muster ist vorhersehbar: Dezentralisierte Beschaffung bedeutet, dass Teams Tools eigenständig anmelden, oft ohne zu wissen, dass bereits ein Unternehmensvertrag für dieselbe Kategorie existiert. Wenn dann noch ein Sicherheitsvorfall hinzukommt, summieren sich die Behebungskosten zusätzlich zur grundlegenden Verschwendung zu einer erheblichen finanziellen Exposition.

Wie man Schatten-IT und Schatten-KI erkennt

Die Erkennung von Schatten-IT im Jahr 2026 erfordert die Kombination von mindestens fünf Datenquellen: CASB-Deployment (Cloud Access Security Broker), DNS-Protokollanalyse, EDR (Endpoint Detection and Response), Ausgabendatenprüfung und E-Mail-Integrations-Scanning. Jede Methode deckt einen anderen Teil der Umgebung ab. Keine deckt alles ab. Blinde Flecken sind strukturell, nicht zufällig — kein einzelnes Tool sieht gleichzeitig persönliche Geräte, Free-Tier-Accounts und verwaltete Endpunkte.

Endpunkt-Monitoring und Browser-Erweiterungen

EDR-Tools und Browser-Erweiterungs-Audits können nicht autorisierte SaaS-Nutzung direkt auf dem Gerät aufdecken. Browser-Verlaufsanalyse, Erweiterungsinventare und agentenbasiertes Monitoring erfassen Aktivitäten, die nie das Unternehmensnetzwerk berühren.

Die Einschränkung: BYOD-Umgebungen (Bring Your Own Device) und persönliche Geräte, die für die Arbeit genutzt werden, sind für Endpunkt-Tools weitgehend unsichtbar, es sei denn, die Organisation hat MDM (Mobile Device Management) mit entsprechendem Umfang bereitgestellt.

Netzwerkanalyse: DNS- und Proxy-Protokolle

DNS-Abfrageprotokolle und Web-Proxy-Daten zeigen, auf welche Domains Mitarbeiter zugreifen. Spitzen im Traffic zu unbekannten SaaS-Domains, KI-Services oder File-Sharing-Plattformen erscheinen deutlich in DNS-Protokollen, selbst wenn der Inhalt verschlüsselt ist.

Diese Methode funktioniert gut für Unternehmensnetzwerk-Traffic. Sie verfehlt alles, was über Mobilfunkverbindungen, Heimnetzwerke oder VPNs geschieht, die außerhalb des Unternehmens-Proxys routen. DNS-over-HTTPS (DoH) und DNS-over-TLS (DoT) verschlüsseln Abfragen Ende-zu-Ende und umgehen traditionelle DNS-Inspektion vollständig, ohne zusätzliche Firewall-Richtlinien zur Blockierung.

CASB: Stärken und Einschränkungen

Ein CASB (Cloud Access Security Broker) sitzt zwischen Benutzern und Cloud-Services und bietet Sichtbarkeit, Richtliniendurchsetzung und Data-Loss-Prevention für genehmigte und nicht genehmigte Apps. CASBs sind das am besten geeignete Tool zur Erkennung von Schatten-IT und können Tausende von Cloud-Services identifizieren, die in einer Organisation genutzt werden.

Die praktische Einschränkung ist die Abdeckung. CASBs funktionieren am besten, wenn Traffic durch sie geleitet wird — am effektivsten für verwaltete Geräte in Unternehmensnetzwerken. Mitarbeiter, die persönliche Accounts auf persönlichen Geräten nutzen, oder KI-Tools, auf die über den Browser ohne SSO zugegriffen wird, sind möglicherweise nicht sichtbar. Schatten-KI-Funktionen, die in bereits genehmigten SaaS-Tools eingebettet sind, werden typischerweise ebenfalls nicht erkannt, da die übergeordnete Domain bereits genehmigt ist.

Ein 6-Schritte-Framework zur Verwaltung von Schatten-IT

Das Schatten-IT-Governance-Framework ist ein sechsstufiger Prozess: Entdecken und Klassifizieren, Credentials zentralisieren, Richtlinien etablieren, Genehmigungen optimieren, Offboarding automatisieren und ein Security-Awareness-Programm aufbauen. Es adressiert sowohl die technischen als auch die verhaltensbezogenen Dimensionen des Problems. Das Blockieren nicht genehmigter Tools ohne schnellere genehmigte Alternativen scheitert durchgehend.

Schritt 1. Entdecken und klassifizieren

Was nicht sichtbar ist, kann nicht gesteuert werden. Beginnen Sie mit einer umfassenden Entdeckungsanalyse unter Verwendung einer Kombination aus DNS-Protokollanalyse, CASB-Deployment, Endpunkt-Monitoring und Ausgabendatenprüfung. Das Ergebnis sollte ein klassifiziertes Inventar sein: genehmigt, toleriert (bekannt, aber nicht formal genehmigt) und nicht genehmigt.

Klassifizieren Sie jede Anwendung nach Datensensibilität. Ein kostenloser Grammatik-Checker, der auf E-Mail-Entwürfe zugreift, hat ein anderes Risikoprofil als ein KI-Coding-Assistent mit Repository-Zugriff.

Schritt 2. Sicheres Credential-Management implementieren

Jeder Schatten-IT-Account ist ein unverwaltetes Credential. Die Lösung besteht nicht darin, Accounts zu verbieten; es geht darum, Credentials unter zentralisierte Kontrolle zu bringen.

Ein zentralisierter Tresor mit rollenbasierter Zugriffskontrolle (RBAC) gibt Mitarbeitern einen sicheren, bequemen Ort zum Speichern und Teilen von Credentials für genehmigte und neu genehmigte Tools. Wenn der Zugriff zentralisiert ist, wird Offboarding deterministisch: Entziehen Sie den Tresor-Zugriff, und der Mitarbeiter verliert den Zugriff auf jedes dort gespeicherte Credential.

Passwork ist als Self-Hosted-Deployment oder in der Cloud verfügbar und gibt Teams die Flexibilität zu wählen, wo Credential-Daten gespeichert werden. Das Self-Hosted-Modell hält alles in Ihrer eigenen Infrastruktur ohne Abhängigkeit von Cloud-Services Dritter; die Cloud-Option ermöglicht den schnellen Start ohne Verwaltung eines eigenen Server-Stacks. In beiden Fällen erhalten Administratoren vollständige Sichtbarkeit darüber, wer Zugriff auf was hat, sowie ein vollständiges Audit-Protokoll jeder Credential-Operation. Weitere Informationen zu Deployment und Integration finden Sie in den technischen Anleitungen.

Schritt 3. Klare KI- und SaaS-Richtlinien etablieren

Ein pauschales Verbot wird selbst von den Personen ignoriert, die es durchsetzen. Eine Richtlinie, die definiert, wie Tools genehmigt werden, welche Datenklassifizierungen in KI-Tools zulässig sind und was mit OAuth-Berechtigungen geschieht, wenn ein Mitarbeiter das Unternehmen verlässt, ist umsetzbar.

Die Richtlinie sollte speziell adressieren:

• Verbotene Datenklassifizierungen für KI-Tool-Eingaben (personenbezogene Daten, Quellcode, Finanzdaten, Credentials)
• OAuth-Berechtigungsgenehmigung und Überprüfungszyklen
• Maximale Zeit bis zur Genehmigung für neue SaaS-Anfragen (langsame Genehmigungsprozesse sind der Hauptgrund, warum Mitarbeiter die IT umgehen)
• Konsequenzen bei Richtlinienverstößen

Schritt 4. Den Genehmigungsprozess optimieren

Schatten-IT existiert, weil der genehmigte Weg zu langsam ist. Wenn ein Mitarbeiter heute ein Tool benötigt und der Genehmigungsprozess drei Wochen dauert, wird er das Tool ohne Genehmigung nutzen und später um Verzeihung bitten, falls überhaupt.

Bauen Sie einen schlanken Genehmigungsworkflow auf: ein kurzes Antragsformular, ein 48-Stunden-SLA für risikoarme Tools und ein klares Entscheidungsframework basierend auf Datensensibilität und Anbieter-Sicherheitsstatus. Das Ziel ist, „über die IT gehen" schneller zu machen als „selbst herausfinden".

Schritt 5. Offboarding-Workflows automatisieren

Manuelles Offboarding ist der Ort, an dem verwaiste Accounts entstehen. Wenn ein Mitarbeiter das Unternehmen verlässt, deprovisioniert die IT typischerweise die ihr bekannten Accounts. Schatten-IT-Accounts stehen per Definition nicht auf dieser Liste.

Automatisierte Offboarding-Workflows, ausgelöst durch HRIS-Kündigungsereignisse, sollten:

• SSO- und IdP-Zugriff sofort widerrufen
• Alle im zentralisierten Tresor für diesen Benutzer gespeicherten Credentials rotieren oder ungültig machen
• OAuth-Berechtigungen, die mit der Unternehmensidentität des Benutzers verbunden sind, prüfen und widerrufen
• Eigentümerschaft freigegebener Ressourcen übertragen, bevor der Zugriff entzogen wird

Die Passwork-Benutzeranleitungen behandeln Credential-Tresor-Offboarding-Workflows im Detail, einschließlich des Umgangs mit geteilten Passwörtern und Service-Account-Credentials, die rotiert werden müssen, nicht nur widerrufen.

Schritt 6. Ein Security-Awareness-Programm aufbauen

Richtlinien und Tooling allein ändern kein Verhalten. Mitarbeiter nutzen Schatten-IT, weil sie das Risiko nicht verstehen, die genehmigte Alternative nicht kennen oder den genehmigten Weg als zu langsam empfinden. Ein Security-Awareness-Programm adressiert die ersten beiden direkt.

• Das Risiko greifbar machen: Mitarbeitern ein reales Beispiel zu zeigen, wie ein Credential-Wiederverwendungsangriff funktioniert, wirkt stärker als eine Folie über „Datenschutz". Machen Sie das genehmigte Toolkit bekannt; Mitarbeiter, die wissen, dass eine schnelle, genehmigte Alternative existiert, greifen seltener zu einer nicht genehmigten. 
• Eine Meldekultur schaffen: Mitarbeiter sollten sich wohl dabei fühlen, Tools zu melden, die sie bereits nutzen, ohne sofortige Bestrafung befürchten zu müssen. Entdeckung durch Selbstmeldung ist schneller und günstiger als Entdeckung durch ein Datenleck.
• Jährliche Schulungen reichen nicht aus. Vierteljährliche Mikro-Schulungen (10-15 Minuten, szenariobasiert) übertreffen in Retentionsstudien durchgehend jährliche Compliance-Module. Phishing-Simulationen, die gefälschte SaaS-Anmeldeaufforderungen enthalten — nicht nur E-Mail-Köder — testen genau das Verhalten, das Schatten-IT-Governance ändern soll.

Verfolgen Sie die Auswirkungen des Programms auf die Schatten-IT-Erkennungsraten, nicht nur auf Schulungsabschlussquoten. Abschluss ist eine Input-Metrik. Die Reduzierung der Nutzung nicht genehmigter Tools ist der Output, der zählt.

Fazit: Den genehmigten Weg schneller machen als den Workaround

Die Organisationen, die Schatten-IT effektiv verwalten, sind diejenigen, die den genehmigten Weg schneller als den Workaround gemacht haben. Nicht diejenigen mit den strengsten Blockierungsrichtlinien.

Das bedeutet ein Entdeckungsprogramm, das kontinuierlich läuft. Einen Credential-Tresor, den Mitarbeiter tatsächlich nutzen wollen, weil er ihnen Zeit spart. Einen Offboarding-Workflow, der automatisch ausgelöst wird, sobald ein HRIS-Kündigungsereignis eintritt. Eine KI-Richtlinie, die Mitarbeitern sagt, was sie mit KI-Tools tun können, nicht nur, was sie nicht dürfen. Und ein Security-Awareness-Programm, das das Risiko real macht statt abstrakt.

Für europäische Organisationen sind die Einsätze noch höher. DSGVO-Artikel 28, NIS2-Artikel 21 und DORA-Artikel 28 behandeln Schatten-IT nicht als Governance-Unannehmlichkeit; sie behandeln sie als Compliance-Verstoß mit quantifizierten Strafen. Der Aufschlag von 670.000 US-Dollar für Schatten-KI aus IBMs Bericht 2025 ist keine Abstraktion. Es ist das, was passiert, wenn Governance der Adoption hinterherhinkt. Schließen Sie diese Lücke, bevor das nächste Datenleck das Argument für Sie liefert.

Häufig gestellte Fragen

10 Remote-Work-Sicherheitsfehler (und wie Sie sie beheben)

10 Remote-Work-Sicherheitsfehler — und das eine Prinzip hinter allen: Sicherheit bricht dort, wo der sichere Weg mehr Reibung hat als der unsichere. Echte Fälle, realistische Lösungen, eine 5-Schichten-Baseline, gegen die Ihr Team prüfen kann.

Passwork BlogAlex Muntyan

Schatten-IT vs. Schatten-KI: Warum KI die größere Bedrohung ist

Mitarbeiter nutzen KI-Tools, die Sie nicht genehmigt haben, auf Accounts, die Sie nicht überwachen können, mit Daten, die Sie nicht wiederherstellen können. So sieht das Risiko tatsächlich aus und was Governance adressieren muss.

Passwork BlogAlex Muntyan

Leitfaden zur Lieferkettensicherheit: Lieferantenrisiken, Vorschriften, Zugriffskontrolle im Jahr 2026

48 % der Datenlecks betreffen jetzt eine Drittpartei. Dieser Leitfaden behandelt die Angriffsmuster hinter SolarWinds, MOVEit und XZ Utils — sowie die Zugriffskontrollen, Credential-Management-Praktiken und regulatorischen Anforderungen, die sie tatsächlich stoppen.

Passwork BlogAlex Muntyan

Shadow IT in 2026 looks nothing like it did five years ago. The problem now is AI agents with persistent OAuth tokens, LLM sessions quietly processing proprietary source code, and orphaned SaaS accounts no one remembers provisioning. Each one extends the corporate attack surface well past anything a traditional network perimeter was designed to handle.

According to UpGuard's State of Shadow AI report, over 80% of employees use unapproved AI tools. A Gartner survey of 302 cybersecurity leaders (March–May 2025) found that 69% of organizations either suspect or have confirmed employees using prohibited public GenAI tools. Gartner predicts that by 2030, more than 40% of enterprises will experience a security or compliance incident tied to unauthorized shadow AI.

The DTEX/Ponemon 2026 Cost of Insider Risks report puts the annual cost of insider negligence driven primarily by shadow AI at $10.3 million per organization. That figure covers incidents where no malicious intent was involved: just employees using tools IT never approved, and budgets quietly funding infrastructure no one can see or secure.

Key takeaways

• Shadow IT in 2026 is an AI problem as much as a SaaS problem. AI agents with persistent OAuth tokens, LLM sessions processing proprietary source code, and orphaned SaaS accounts that outlive their owners are now the highest-severity risks.
• Shadow AI is categorically different from traditional shadow IT. Unsanctioned SaaS tools store data in the wrong place. Unsanctioned AI tools process, analyze, and act on it.
• The financial exposure is quantified. IBM's 2025 Cost of a Data Breach Report found that shadow AI involvement adds $670,000 to the average breach cost of $4.44 million. The DTEX/Ponemon 2026 Cost of Insider Risks report puts the annual cost of AI-driven insider negligence at $10.3 million per organization.
• Detection requires at least five data sources working in parallel. CASB, DNS log analysis, EDR, expense data review, and email integration scanning each cover a different slice of the environment. No single method sees personal devices, free-tier accounts, and managed endpoints simultaneously.
• European organizations face layered regulatory exposure. Unsanctioned SaaS tools violate GDPR Article 28 the moment they process personal data without a signed DPA. NIS2 Article 21 treats unvetted third-party tools as supply chain risk. DORA Article 28 requires financial entities to register every ICT provider — shadow or otherwise.
• Blocking without enabling consistently fails. Nearly half of employees continue using personal AI accounts after an organizational ban. The effective response is making the approved path faster than the workaround: a lightweight approval workflow, centralized credential management, and a security awareness program that makes the risk concrete.
• The 6-step Shadow IT Governance Framework — discover and classify, centralize credentials, establish policy, streamline approvals, automate offboarding, build security awareness — addresses both the technical and behavioral sides of the problem. Tooling handles detection. The framework changes the incentive structure that drives shadow IT adoption in the first place.

What is shadow IT?

Shadow IT is any technology (software, cloud service, AI tool, or hardware) that employees use for work without IT's knowledge or formal approval. It ranges from a personal Dropbox folder used to share project files, to an AI coding assistant with OAuth access to production repositories. The common thread: no security review, no procurement record, no audit trail.

Shadow IT is not a niche problem. Gartner puts the share of IT spending consumed by unsanctioned tools at 30-40% in large enterprises. Harmonic Security's analysis of 22.4 million enterprise AI prompts identified 665 distinct generative AI tools running across enterprise environments — yet only 40% of those organizations had purchased an official AI subscription. GenAI traffic surged more than 890% in 2024 alone.

Shadow IT vs. Shadow AI: How the risks compare

What drives employees to use shadow IT?

Employees turn to unsanctioned tools when approved alternatives are too slow, too limited, or simply don't exist yet. The friction is the cause: a developer waiting three weeks for a licensed AI assistant will find a free one by end of day.

Three patterns repeat across organizations of every size:

• Speed over process. Employees reach for whatever gets the job done fastest. When approved tools don't match what's freely available outside the enterprise, the choice is obvious: use what works.
• Procurement lag. Enterprise software cycles run on quarters. AI tooling ships on weeks. By the time IT evaluates and approves a tool, employees have already built workflows around its free-tier equivalent.
• Functional gaps. Approved tools often don't cover edge cases. A data analyst who needs a quick Python environment, or a designer who needs a specific image generator, will reach for whatever works, not whatever's on the approved list.
• No feedback loop. Employees rarely report the tools they're using because there's no easy channel to do so. IT doesn't know what to govern. Security doesn't know what to audit. The gap between actual tool usage and approved inventory widens silently.
• Bans don't hold. Nearly half of employees continue using personal AI accounts after an organizational ban. Prohibition doesn't eliminate shadow IT. It just pushes it out of sight, making detection harder and response slower.

These patterns are a predictable response to governance structures that haven't kept pace with how fast tooling moves. That gap is exactly what makes shadow IT a systemic risk rather than a discipline problem.

The evolution of shadow IT in 2026

Shadow IT in 2026 has moved well beyond unmanaged cloud storage. It now spans AI tools, autonomous agents, and entire SaaS ecosystems that IT never approved, never inventoried, and cannot monitor. The average enterprise runs 305 SaaS applications, spends $55.7 million on SaaS annually, and has seen AI-native app spend jump 108% year over year — most of that growth happening faster than governance teams can track it.

From SaaS sprawl to shadow AI

The 305-application figure comes from Zylo's 2026 SaaS Management Index, which draws on real-world spend data across thousands of organizations. A significant share of those applications were never formally approved. Employees adopt tools independently and IT finds out months later, if at all.

Shadow AI accelerates this dynamic. Free AI assistants, code generators, and autonomous agents became widely available faster than procurement cycles could respond. Check Point's 2026 Cloud Security Report found that 78-80% of workers use personal AI tools at work. Most of those sessions happen through personal accounts, outside SSO, outside DLP, and with no audit trail.

The distinction is worth being precise about: 

• Traditional shadow IT creates unmanaged data residency: files sitting in an unsanctioned service. 
• Shadow AI creates unmanaged data processing: proprietary information being analyzed, summarized, and acted upon by systems your security team has never reviewed.

Why the attack surface keeps expanding

Three structural forces drive this:

• Remote and hybrid work removed the network perimeter as a natural control point. Employees working from home adopt tools without routing requests through IT.
• Free tiers are everywhere. Most SaaS tools offer a no-cost entry point. No purchase order, no approval ticket, no visibility.
• AI agent proliferation changed the stakes. Agents operate through delegated OAuth permissions — reading data, triggering workflows, and modifying records autonomously. A developer who connects an AI coding assistant to their GitHub account may have granted that agent read/write access to repositories. When the developer leaves, the OAuth grant stays.

Gartner projects that by 2027, 75% of employees will acquire, modify, or create technology outside IT's visibility — up from 41% in 2022. The direction is unambiguous.

The hidden risks of shadow IT (the 2026 reality)

Shadow IT in 2026 is not just a data leakage problem. Unmanaged tools create persistent unauthorized access, expose credentials, trigger regulatory violations, and increasingly feed enterprise data into AI models that no security team has approved or can monitor.

The shadow AI risk multiplier: Data processing vs. data storage

Traditional shadow IT stores data in the wrong place. Shadow AI does things with it. Pasting a customer contract into a public LLM sends that data into at least three places: a training pipeline, a logging system, and potentially a model that other users can query.

IBM's 2025 Cost of a Data Breach Report puts a number on this: breaches involving high levels of shadow AI added an average of $670,000 to the total breach cost, bringing the shadow-AI-involved average to approximately $5.11 million against a global baseline of $4.44 million. The same report found that 97% of AI-related security incidents involved systems lacking proper access controls.

Credential exposure and password reuse

Shadow IT is, at its root, an identity problem. Every unsanctioned app is a new account. Every new account is a credential. And most of those credentials are reused.

According to Verizon's 2026 Data Breach Investigations Report, stolen credentials appeared in 39% of all confirmed breaches, not just as the initial access vector, but throughout lateral movement and persistence. When an employee reuses their corporate password on a free SaaS tool that later suffers a breach, attackers don't need to break anything. They just log in.

Infostealers make this worse. In 2025, Recorded Future indexed 1.95 billion malware-sourced credential exposures, 31% of which included active session cookies that bypass MFA entirely. Shadow IT accounts, unmonitored, often without MFA configured, are exactly the kind of target infostealers are built for.

The password reuse risk is a documented, automated, industrial-scale attack pattern.

The offboarding nightmare: Orphaned accounts

When an employee leaves, their managed accounts get deprovisioned. Their shadow IT accounts don't. Nobody knows they exist.

That former developer's Figma workspace, the sales rep's personal HubSpot trial with exported CRM data, the contractor's Notion page with internal architecture notes: all of these persist indefinitely after the person walks out the door.

The consequences can be severe. In one documented case, a former Cisco employee accessed an AWS-hosted virtual machine infrastructure five months after termination and deleted 456 virtual machines, taking down more than 16,000 WebEx Teams accounts for nearly two weeks. =

The US Department of Justice confirmed the incident cost Cisco approximately $2.4 million in remediation and customer refunds, and the former employee was sentenced to 24 months in federal prison (United States v. Sudhish Kasaba Ramesh, Case No. 5:20-cr-00102). That was a managed system. Orphaned shadow IT accounts are harder to find and take longer to close — if they're ever closed at all.

AI agents and unmanaged OAuth permissions

This is the threat most organizations aren't tracking yet. AI agents operate through delegated OAuth permissions: a user grants the agent access to Google Drive, GitHub, or Slack, and the agent can read, write, and act on that access continuously — not just during the session.

When the user logs out, the OAuth grant remains. When the user leaves the company, the OAuth grant remains. The agent may still have access to corporate repositories, email threads, and shared drives weeks or months after the person who authorized it is gone.

Okta's AI Agents at Work 2026 report found that 58% of organizations suffered an AI-related security incident in the past year, yet 90% of executives reported lacking full visibility into which AI agents are operating within their organization. The gap between adoption and governance is where the risk lives.

Compliance violations and regulatory fines

Unsanctioned apps don't comply with GDPR Article 32's requirement for "appropriate technical and organisational measures" to protect personal data. They don't satisfy HIPAA's technical safeguard requirements under 45 CFR § 164.312. They don't meet PCI-DSS Requirement 12.8 for managing third-party service providers.

The EU AI Act adds another layer. High-risk AI systems used without proper governance carry penalties of up to €15 million or 3% of global annual turnover under Article 99(4).

The financial services sector has already seen what regulatory enforcement looks like in practice. In September 2022, the SEC and CFTC fined 16 Wall Street firms a combined $1.8 billion for employees using WhatsApp and other unapproved messaging apps for business communications — a textbook shadow IT violation that regulators treated as a recordkeeping failure. The SEC's press release makes clear that "widespread and longstanding" use of off-channel communications is not a mitigating factor; it's an aggravating one.

European regulatory exposure: GDPR, NIS2, and DORA

For organizations operating in the EU, shadow IT creates layered regulatory exposure across three distinct frameworks. Each targets a different dimension of the problem, and together they leave very little room for "we didn't know."

GDPR: Unauthorized processors and cross-border transfers

GDPR Article 32 is the provision most organizations cite. But Article 28 is the one shadow IT actually violates first. Every unsanctioned SaaS tool that processes personal data is, in GDPR terms, a data processor. Article 28 requires a written data processing agreement (DPA) with every such processor before processing begins. An employee who signs up for a free AI tool using their corporate email and feeds it customer data has created an unauthorized processor relationship — with no DPA, no due diligence, and no record.

Articles 44 through 49 compound the exposure. Many US-based SaaS and AI tools transfer personal data outside the European Economic Area. Without a valid transfer mechanism (Standard Contractual Clauses, an adequacy decision, or Binding Corporate Rules), that transfer violates GDPR regardless of how the tool was adopted. Employees choosing tools independently have no visibility into where data is processed or stored.

European DPAs have enforced both provisions. In 2023, the Irish Data Protection Commission fined Meta €1.2 billion under Article 46 for unlawful data transfers to the US — the largest GDPR fine to date. While that case involved a platform operator rather than an enterprise end user, the underlying principle applies: the absence of a valid transfer mechanism is a violation, regardless of intent.

NIS2: Access control and supply chain obligations

The NIS2 Directive (Directive EU 2022/2555), applicable to essential and important entities across the EU since October 2024, directly addresses the conditions that shadow IT creates. Article 21(2) sets out ten minimum cybersecurity risk-management measures. Three are directly implicated by shadow IT:

• Article 21(2)(d): Supply chain security, including security aspects concerning the relationships between each entity and its direct suppliers or service providers. Every unsanctioned SaaS tool is, in effect, an unvetted supplier relationship.
• Article 21(2)(i): Policies and procedures regarding the use of cryptography and, where appropriate, encryption.
• Article 21(2)(j): Human resources security, access control policies, and asset management.

NIS2 penalties reach €10 million or 2% of global annual turnover for important entities, and €7 million or 1.4% for others. Member state transposition varies, but the framework is now active across the EU.

Passwork's NIS2 compliance page covers how centralized credential management maps to NIS2 Article 21 requirements in detail.

DORA: ICT third-party risk for financial entities

The Digital Operational Resilience Act (DORA, Regulation EU 2022/2554) has been in force since January 2025 for financial entities operating in the EU: banks, insurers, investment firms, payment processors, and their critical ICT providers. Article 28 requires financial entities to maintain a register of all ICT third-party service providers and conduct pre-contractual due diligence before onboarding any new provider.

Shadow SaaS is directly in scope. An employee at a bank who adopts an unsanctioned project management tool or AI assistant has created an unregistered ICT third-party relationship. Under DORA, that's not an IT governance issue; it's a regulatory breach. The European Supervisory Authorities (EBA, ESMA, EIOPA) have supervisory authority to investigate and sanction. In jurisdictions where national transposition provides for it, management-level criminal liability may also apply.

For financial sector IT and compliance teams, shadow IT discovery is no longer a best practice. Under DORA, it's a legal obligation.

The financial impact: Quantifying the cost of shadow IT

Shadow IT carries two distinct financial costs: breach exposure and wasted spend. IBM's 2025 Cost of a Data Breach Report found that shadow AI involvement adds $670,000 to the average breach cost of $4.44 million. On the spend side, Zylo's 2026 SaaS Management Index puts average wasted license spend at $21 million per year — driven by redundant tools, unused seats, and purchases IT never knew about.

IBM 2025 data: the $670K shadow AI penalty

IBM's 2025 Cost of a Data Breach Report is the most authoritative benchmark available for understanding the financial consequences of unmanaged AI. The headline numbers:

• Global average breach cost: $4.44 million
• Shadow AI involvement adds $670,000 to that average, bringing the shadow-AI-involved figure to approximately $5.11 million
• 97% of AI-related incidents involved systems without proper access controls
• 20% of organizations reported a security incident directly linked to shadow AI in 2025

The $670,000 adder is the incremental cost of investigation, containment, notification, and remediation when AI systems are involved that security teams didn't know about.

Wasted IT spend and redundant licensing

Organizations pay for approved tools while employees quietly adopt free or cheaper alternatives. The result: duplicate functionality, stranded licenses, and spend that nobody owns.

According to Zylo's 2026 SaaS Management Index, the average organization wastes $21 million a year on unused SaaS licenses alone — and the average utilization rate across enterprise SaaS portfolios sits at just 47%. For mid-market firms running 500 or fewer employees, that figure still reaches $4.2 million annually in wasted license spend.

The pattern is predictable: decentralized purchasing means teams sign up for tools independently, often unaware that an enterprise contract for the same category already exists. When a security incident occurs on top of that, remediation costs compound the baseline waste into a material financial exposure.

How to detect shadow IT and shadow AI

Detecting shadow IT in 2026 requires combining at least five data sources: CASB (Cloud Access Security Broker) deployment, DNS log analysis, EDR (Endpoint Detection and Response), expense data review, and email integration scanning. Each method covers a different slice of the environment. None covers all of it. Blind spots are structural, not incidental — no single tool sees personal devices, free-tier accounts, and managed endpoints simultaneously.

Endpoint monitoring and browser extensions

EDR tools and browser extension audits can surface unauthorized SaaS usage directly on the device. Browser history analysis, extension inventories, and agent-based monitoring catch activity that never touches the corporate network.

The limitation: BYOD (Bring Your Own Device) environments and personal devices used for work are largely invisible to endpoint tools unless the organization has deployed MDM (Mobile Device Management) with appropriate scope.

Network analysis: DNS and proxy logs

DNS query logs and web proxy data reveal which domains employees are accessing. Spikes in traffic to unknown SaaS domains, AI services, or file-sharing platforms show up clearly in DNS logs even when the content is encrypted.

This method works well for corporate network traffic. It misses everything that happens over cellular connections, home networks, or VPNs that route outside the corporate proxy. DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) encrypt queries end-to-end, bypassing traditional DNS inspection entirely without additional firewall policy to block them.

CASB: strengths and limitations

A CASB (Cloud Access Security Broker) sits between users and cloud services, providing visibility, policy enforcement, and data loss prevention for sanctioned and unsanctioned apps. CASBs are the most purpose-built tool for shadow IT detection and can identify thousands of cloud services in use across an organization.

The practical limitation is coverage. CASBs work best when traffic routes through them — most effective for managed devices on corporate networks. Employees using personal accounts on personal devices, or AI tools accessed via browser without SSO, may not be visible. Shadow AI features embedded inside already-sanctioned SaaS tools are also typically undetected, since the parent domain is already approved.

A 6-step framework to manage shadow IT

The Shadow IT Governance Framework is a six-step process: discover and classify, centralize credentials, establish policy, streamline approvals, automate offboarding, and build a security awareness program. It addresses both the technical and behavioral dimensions of the problem. Blocking unsanctioned tools without enabling faster approved alternatives consistently fails.

Step 1. Discover and classify

You cannot govern what you cannot see. Start with a comprehensive discovery sweep using a combination of DNS log analysis, CASB deployment, endpoint monitoring, and expense data review. The output should be a classified inventory: sanctioned, tolerated (known but not formally approved), and unsanctioned.

Classify each application by data sensitivity. A free grammar checker accessing email drafts is a different risk profile than an AI coding assistant with repository access.

Step 2. Implement secure credential management

Every shadow IT account is an unmanaged credential. The fix is not to prohibit accounts; it's to bring credentials under centralized control.

A centralized vault with role-based access control (RBAC) gives employees a secure, convenient place to store and share credentials for both approved and newly-approved tools. When access is centralized, offboarding becomes deterministic: revoke vault access, and the employee loses access to every credential stored there.

Passwork is available as a self-hosted deployment or in the cloud, giving teams the flexibility to choose where credential data lives. The self-hosted model keeps everything within your own infrastructure with no dependency on third-party cloud services; the cloud option gets you up and running without managing your own server stack. Either way, administrators get full visibility into who has access to what and a complete audit log of every credential operation. See the technical guides for deployment and integration details.

Step 3. Establish clear AI and SaaS policies

A blanket prohibition will be ignored even by the people enforcing it. A policy that defines how to get tools approved, what data classifications are permissible in AI tools, and what happens to OAuth grants when an employee leaves is actionable.

The policy should specifically address:

• Prohibited data classifications for AI tool input (PII, source code, financial data, credentials)
• OAuth grant approval and review cycles
• Maximum time-to-approval for new SaaS requests (slow approval processes are the primary reason employees go around IT)
• Consequences for policy violations

Step 4. Streamline the approval process

Shadow IT exists because the approved path is too slow. If an employee needs a tool today and the approval process takes three weeks, they'll use the tool without approval and ask for forgiveness later, if they ask at all.

Build a lightweight approval workflow: a short intake form, a 48-hour SLA for low-risk tools, and a clear decision framework based on data sensitivity and vendor security posture. The goal is to make "go through IT" faster than "figure it out yourself."

Step 5. Automate offboarding workflows

Manual offboarding is where orphaned accounts are born. When an employee leaves, IT typically deprovisions the accounts it knows about. Shadow IT accounts, by definition, aren't on that list.

Automated offboarding workflows, triggered by HRIS termination events, should:

• Revoke SSO and IdP access immediately
• Rotate or invalidate all credentials stored in the centralized vault for that user
• Audit and revoke OAuth grants associated with the user's corporate identity
• Transfer ownership of shared resources before access is cut

The Passwork user guides cover credential vault offboarding workflows in detail, including how to handle shared passwords and service account credentials that need to be rotated, not just revoked.

Step 6. Build a security awareness program

Policy and tooling alone don't change behavior. Employees adopt shadow IT because they don't understand the risk, don't know the approved alternative exists, or find the approved path too slow. A security awareness program addresses the first two directly.

• Make the risk concrete: showing employees a real example of how a credential reuse attack works lands harder than a slide about "data protection." Publicize the approved toolkit; employees who know a fast, sanctioned alternative exists are less likely to reach for an unapproved one. 
• Create a reporting culture: employees should feel comfortable flagging tools they're already using without fear of immediate punishment. Discovery through self-reporting is faster and cheaper than discovery through a breach.
• Annual training is not enough. Quarterly micro-training sessions (10-15 minutes, scenario-based) consistently outperform annual compliance modules in retention studies. Phishing simulations that include fake SaaS sign-up prompts — not just email lures — test exactly the behavior shadow IT governance is trying to change.

Track the program's effect on shadow IT discovery rates, not just training completion percentages. Completion is an input metric. Reduction in unsanctioned tool adoption is the output that matters.

Conclusion: Make the approved path faster than the workaround

The organizations that manage shadow IT effectively are the ones that made the approved path faster than the workaround. Not the ones with the strictest blocking policies.

That means a discovery program that runs continuously. A credential vault that employees actually want to use because it saves them time. An offboarding workflow that fires automatically the moment an HRIS termination event triggers. An AI policy that tells employees what they can do with AI tools, not just what they can't. And a security awareness program that makes the risk real rather than abstract.

For European organizations, the stakes are higher still. GDPR Article 28, NIS2 Article 21, and DORA Article 28 don't treat shadow IT as a governance inconvenience; they treat it as a compliance failure with quantified penalties attached. The $670,000 shadow AI cost adder from IBM's 2025 report isn't an abstraction. It's what happens when governance lags adoption. Close that gap /before the next breach makes the case for you.

Frequently asked questions

10 Remote Work Security Fails (And How to Fix Them)

10 remote work security fails — and the one principle behind all of them: security breaks where the secure path has more friction than the insecure one. Real cases, realistic fixes, a 5-layer baseline your team can audit against.

Passwork BlogAlex Muntyan

Shadow IT vs Shadow AI: Why AI is the bigger threat

Employees are using AI tools you didn’t approve, on accounts you can’t monitor, with data you can’t recover. Here’s what the risk actually looks like and what governance needs to address.

Passwork BlogAlex Muntyan

Supply chain security guide: Vendor risks, regulations, access control in 2026

48% of breaches now involve a third party. This guide covers the attack patterns behind SolarWinds, MOVEit, and XZ Utils — and the access controls, credential management practices, and regulatory requirements that actually stop them.

Passwork BlogAlex Muntyan

Esta semana trajo varios incidentes importantes, y todos apuntan en la misma dirección. La escala del compromiso de credenciales sigue batiendo récords. FortiBleed: 86.000 dispositivos en 194 países. La filtración de Elasticsearch: 24 mil millones de registros de decenas de fuentes. HIBP añadió 124 millones de contraseñas robadas por infostealers en el momento de uso. Estos datos ya están en circulación.

• Dos métodos de ataque recibieron confirmación concreta esta semana. Los atacantes cada vez más evitan las contraseñas por completo: la brecha de Klue comenzó con una cuenta de servicio olvidada y terminó con tokens OAuth robados — sin introducir ninguna contraseña en ningún momento.
• Los agentes de IA se han convertido en un vector de ataque independiente: un repositorio de prueba de código envenenado permitió a un atacante exfiltrar credenciales de AWS desde la estación de trabajo de un desarrollador en 111 segundos, sin generar alertas en el endpoint.
• La presión regulatoria avanza en dos frentes. En Europa, el Consejo de Europa y la plataforma gubernamental francesa Tchap fueron vulnerados, la autoridad italiana Garante multó a una empresa por almacenar contraseñas en texto plano, y se publicaron nuevas plantillas de notificación de incidentes del EDPB y NIS2 — todo en una sola semana.
• En EE. UU., el presidente Trump firmó dos órdenes ejecutivas estableciendo plazos federales estrictos para la migración a criptografía poscuántica, señalando que la ventana de preparación es más corta de lo que la mayoría de las organizaciones habían asumido.

Este resumen cubre los 14 eventos más significativos del 15 al 22 de junio de 2026.

EE. UU. establece plazos federales para la migración a criptografía poscuántica (PQC)

El 22 de junio de 2026, el presidente Trump firmó dos órdenes ejecutivas sobre tecnología cuántica. La orden ejecutiva «Securing the Nation Against Advanced Cryptographic Attacks» requiere que las agencias federales designen un responsable de migración PQC, transicionen los activos de alto valor a criptografía poscuántica para 2030 y completen la migración total para 2031.

Una segunda orden dirige el desarrollo de un ordenador cuántico tolerante a fallos para 2028. Ambas órdenes citan los ataques «harvest now, decrypt later» como el principal factor de amenaza — adversarios recopilando datos cifrados hoy para descifrarlos en el futuro. Barron's informa que algunos analistas sitúan la capacidad viable de descifrado cuántico tan pronto como 2029.

Por qué es importante: Los plazos federales de 2030-2031 no permanecerán dentro del gobierno. Los contratos de adquisición y la regulación sectorial específica tienden a seguir el precedente federal, por lo que cualquier organización que interactúe con infraestructura gubernamental u opere en una industria regulada debería tratar esto como una señal temprana. El punto de partida práctico es saber qué se tiene: qué sistemas dependen de RSA o ECC, dónde residen realmente las claves criptográficas y los certificados, y quién los controla.

Fuente: Reuters / White House — 22 jun 2026

FortiBleed: Más de 86.000 credenciales de dispositivos Fortinet comprometidas en 194 países

Una campaña de robo de credenciales a gran escala ha compilado una base de datos verificada de más de 86.644 credenciales funcionales para firewalls FortiGate de Fortinet y dispositivos SSL VPN expuestos a internet — aproximadamente el 50% de todos esos dispositivos expuestos a internet. La campaña incluyó interceptación de autenticación SSL VPN, descifrado de hashes en un clúster de 45 GPU y pivoteo en Active Directory.

Los atacantes ejecutaron aproximadamente 1.160 millones de intentos de credenciales contra más de 320.000 objetivos FortiGate. CISA emitió un aviso urgente el 18 de junio de 2026, requiriendo que las organizaciones terminen las sesiones activas, restablezcan todas las credenciales, habiliten MFA resistente al phishing y apliquen hash de contraseñas PBKDF2 para cuentas de administrador. Huntress confirmó que 845 organizaciones asociadas fueron directamente afectadas.

Por qué es importante: Las organizaciones que parchearon las vulnerabilidades de Fortinet pero nunca rotaron las credenciales permanecen completamente expuestas. Este es el evento de seguridad de credenciales definitorio de la semana. Cualquier organización con infraestructura Fortinet expuesta a internet debería tratar esto como un incidente activo que requiere rotación inmediata de credenciales — no como una tarea de mantenimiento programada.

Fuente: SecurityWeek — 19 jun 2026

24 mil millones de credenciales robadas expuestas en una filtración colosal de Elasticsearch

Investigadores de Cybernews descubrieron un clúster de Elasticsearch públicamente accesible que contenía 24 mil millones de registros de credenciales robadas en 8,3 terabytes de datos, extraídos de 36 fuentes distintas incluyendo registros de malware infostealer, canales de cibercrimen en Telegram y compilaciones de brechas. Más de 1.700 millones de registros se originaron en canales de Telegram.

Críticamente, el clúster también contenía aproximadamente 9.500 registros CVE vinculados a repositorios activos de GitHub — evidencia de que el operador estaba construyendo un pipeline de priorización de ataques para cruzar referencias de vulnerabilidades explotables con credenciales robadas disponibles. La base de datos ha sido desconectada, pero las credenciales permanecen en circulación activa.

Por qué es importante: El pipeline de ataque enriquecido con CVE cambia el cálculo de riesgo: rotar credenciales después de una brecha puede ser demasiado tarde si un atacante ya sabe qué servicios sin parchear desbloquean. Los registros frescos de infostealer también contienen cookies de sesión activas que evitan el MFA por completo. Las credenciales únicas por servicio siguen siendo la defensa estructural principal.

Fuente: Cybernews — 17 jun 2026

124 millones de contraseñas únicas de infostealer añadidas a Have I Been Pwned

El 15 de junio de 2026, Have I Been Pwned (HIBP) incorporó 56,3 millones de direcciones de correo electrónico únicas y 124 millones de contraseñas únicas provenientes de registros de malware infostealer. A diferencia de los datos de brechas tradicionales, estas credenciales fueron robadas directamente de los dispositivos de las víctimas en el momento de uso — lo que significa que son actuales y no han sido rotadas. El conjunto de datos ahora es consultable a través de la API de Pwned Passwords, que está integrada en numerosos gestores de contraseñas empresariales y plataformas de identidad.

Por qué es importante: Las organizaciones que utilizan gestores de contraseñas con integración HIBP ahora verán alertas para un grupo sustancialmente mayor de credenciales en riesgo. El peligro aquí es la frescura: los empleados que no han cambiado sus contraseñas desde que su dispositivo fue infectado permanecen completamente expuestos. Este es un impulso directo para ejecutar una auditoría de credenciales comprometidas en toda su organización.

Fuente: Have I Been Pwned — 15 jun 2026

Ataque a la cadena de suministro SaaS de Klue: Tokens OAuth robados, datos CRM exfiltrados de múltiples proveedores de seguridad

Un nuevo grupo de extorsión llamado Icarus (activo desde abril de 2026) obtuvo acceso inicial a la plataforma de inteligencia de mercado Klue a través de una credencial heredada comprometida asociada con una cuenta de servicio de integración abandonada. Los atacantes luego robaron tokens OAuth utilizados por los clientes de Klue para conectarse a Salesforce y Gong, y ejecutaron scripts automatizados contra la REST API de Salesforce durante hasta 24 horas de extracción masiva de datos CRM.

Las víctimas confirmadas incluyen Huntress, Recorded Future, Tanium, Gong, Sprout Social, Jamf e Insurity. Salesforce deshabilitó la integración de Klue.

Por qué es importante: Una credencial de cuenta de servicio heredada olvidada fue el vector de acceso inicial. Una vez dentro, el atacante no necesitó contraseñas ni códigos MFA — el token OAuth robado era la identidad desde la perspectiva de Salesforce. El ataque se ejecutó sin ser detectado durante 24 horas. Las credenciales de cuentas de servicio y las integraciones OAuth de terceros merecen la misma disciplina de monitoreo que las cuentas de empleados.

Fuente: The Hacker News — 19 jun 2026

Más de 1.230 claves API y tokens JWT codificados encontrados en archivos de instrucciones de agentes IA en más de 7.000 repositorios públicos

Mitiga Labs escaneó más de 50.000 archivos de instrucciones de IA (reglas de Cursor, CLAUDE.md, configuraciones MCP, archivos de cerebro de agentes) en más de 7.000 repositorios públicos de GitHub y encontró más de 1.230 claves API y tokens JWT codificados en servicios que incluyen Anthropic Claude, OpenAI GPT-5, Google Gemini, Databricks, Supabase, Vercel y Google Cloud Storage.

Por separado, GitGuardian informó que 28,65 millones de secretos fueron filtrados en GitHub público en 2025 (un aumento interanual del 34%) con filtraciones de servicios de IA aumentando un 81%.

Por qué es importante: Los archivos de configuración de agentes de IA se están convirtiendo en un vector principal para la exposición de credenciales codificadas. Estos archivos son frecuentemente creados por usuarios sin conciencia de seguridad — product managers, investigadores, fundadores — que no aplican las prácticas estándar de higiene de secretos. Las políticas de escaneo de secretos de la mayoría de las organizaciones aún no cubren archivos de instrucciones, configuraciones MCP y archivos de contexto de agentes. Deberían hacerlo.

Fuente: Mitiga Labs — 15 jun 2026

Una prueba de código envenenada causa que un agente IA robe credenciales de AWS en menos de 2 minutos

Mitiga documentó un ataque del mundo real en el que un repositorio falso de evaluación de código para llevar a casa contenía instrucciones ocultas en archivos .cursor/rules, README.md y CLAUDE.md. Cuando un desarrollador abrió el repositorio en Cursor con la ejecución automática habilitada, el agente de codificación IA ejecutó de forma autónoma cat ~/.aws/credentials, aws sts get-caller-identity, cat ~/.kube/config, terraform state list y un grep de secretos — luego exfiltró todos los datos recopilados a un endpoint controlado por el atacante a través de una llamada de herramienta MCP envenenada. Toda la cadena se completó en 1 minuto y 51 segundos. No se instaló malware; no se generaron alertas en el endpoint.

Por qué es importante: Las credenciales de nube de larga duración almacenadas en estaciones de trabajo de desarrolladores son ahora un objetivo principal para ataques mediados por agentes IA. Cada acción fue realizada por una herramienta legítima usando comandos legítimos — ningún control de endpoint se activó. La mitigación principal es reemplazar las credenciales de larga duración con tokens OIDC de corta duración y autenticación federada.

Fuente: Mitiga Labs — 19 jun 2026

ShinyHunters reclama la brecha del Consejo de Europa: 297 GB de registros de RRHH, nóminas y médicos expuestos

El colectivo hacker ShinyHunters reclamó la responsabilidad de una brecha en el Consejo de Europa, alegando el robo de 297 GB de datos que comprenden más de 429.000 archivos — incluyendo 409.000 nóminas que cubren más de 10.000 empleados durante 15 años, 14.000 CVs, 3.700 expedientes de personal y registros sensibles incluyendo direcciones domiciliarias, salarios, datos bancarios, información fiscal y registros médicos. A fecha del 21 de junio de 2026, ShinyHunters publicó los datos de forma permanente después de que el Consejo de Europa no respondiera a las demandas de rescate.

Por qué es importante: Los registros expuestos crean vectores efectivos de spear-phishing contra una institución sensible. ShinyHunters ahora ha reclamado la Comisión Europea (marzo de 2026), el Consejo de Europa (junio de 2026) y la teleco holandesa Odido (febrero de 2026) en un solo año. Los equipos de seguridad europeos deberían tratar esto como una campaña de ataque sostenida, no como incidentes aislados.

Fuente: Cybernews — 15 jun 2026

La plataforma de mensajería gubernamental francesa Tchap vulnerada: 73.467 cuentas de funcionarios comprometidas

La plataforma soberana de mensajería gubernamental de Francia, Tchap (utilizada por más de 825.000 empleados gubernamentales), fue vulnerada el 7 de junio de 2026 por un actor de amenazas autodenominado «misere». DINUM confirmó que 73.467 cuentas gubernamentales fueron afectadas, con datos expuestos que incluyen nombres, direcciones de correo electrónico y entidades gubernamentales afiliadas.

El actor de amenazas además afirma haber robado 13,5 GB de archivos incluyendo más de 643.000 mensajes. Se cree que el vector de ataque involucra el secuestro de cuentas, posiblemente a través de credenciales obtenidas de registros de stealer.

Por qué es importante: La brecha ilustra cómo el compromiso de credenciales (potencialmente a través de registros de stealer) puede ser utilizado como arma contra la infraestructura de comunicación gubernamental soberana a escala. Los expertos en seguridad señalaron que el ataque puede no haber requerido zero-days: la extracción de datos basada en API utilizando credenciales legítimas es suficiente para esta escala de exfiltración. Bajo NIS2, los servicios digitales gubernamentales están clasificados como entidades esenciales, lo que activa la notificación obligatoria de incidentes a ANSSI.

Fuente: SecurityWeek — 15 jun 2026

Velvet Ant (nexo con China) instala puertas traseras en módulos PAM de Linux y OpenSSH para robo de credenciales durante una década

El equipo de respuesta a incidentes de Sygnia descubrió la Operación Highland, una campaña de espionaje de casi una década por el actor de amenazas Velvet Ant vinculado a China. Activo desde al menos 2016-2017, el grupo modificó los Módulos de Autenticación Conectables (PAM) de Linux — específicamente pam_unix.so — para aceptar una contraseña de puerta trasera codificada, recolectar credenciales de intentos de autenticación legítimos y suprimir todo el registro de actividad del atacante. Se encontraron nueve instancias del módulo PAM con puerta trasera en los hosts comprometidos. El grupo también instaló puertas traseras en binarios de OpenSSH para mantener acceso persistente.

Por qué es importante: Este ataque no robó contraseñas — subvirtió la capa de autenticación en sí. Al modificar los módulos PAM, Velvet Ant podía autenticarse como cualquier usuario y recolectar cada contraseña introducida en los hosts comprometidos. Las contraseñas fuertes no ofrecen protección cuando la pila de autenticación está comprometida. Los operadores de infraestructura crítica en energía, manufactura y defensa enfrentan riesgos directamente análogos.

Fuente: CyberSecurityNews / Sygnia — 15 jun 2026

La autoridad italiana Garante multa a una consultora con 85.000 € por almacenar contraseñas en texto plano tras una brecha de 61.000 usuarios

La autoridad de protección de datos de Italia, la Garante, impuso una multa de 85.000 € a una consultora tras una brecha de datos que expuso datos personales de más de 61.000 usuarios. La Garante encontró que ciertas contraseñas estaban almacenadas en texto plano o protegidas con algoritmos criptográficos obsoletos, y que las credenciales de sistemas no utilizados se habían conservado más allá de su período necesario. Los individuos afectados fueron notificados aproximadamente dos meses después del descubrimiento — y solo después de que se emitiera una orden correctiva.

Por qué es importante: La Garante citó explícitamente el almacenamiento de contraseñas en texto plano y la criptografía obsoleta como las principales infracciones del RGPD. Esto establece un precedente claro de aplicación: el Artículo 32 requiere hash moderno de contraseñas, y retener credenciales para sistemas fuera de servicio viola el principio de limitación del almacenamiento. Las organizaciones de la UE deberían auditar sus implementaciones de almacenamiento de contraseñas contra esta decisión.

Fuente: Gibson Dunn Europe Data Protection — 15 jun 2026

El EDPB adopta una plantilla armonizada de notificación de brechas de datos para toda la UE bajo el RGPD

El Comité Europeo de Protección de Datos (EDPB) ha adoptado una plantilla estandarizada para las notificaciones de brechas de datos personales bajo el Artículo 33 del RGPD, abierta a consulta pública hasta el 5 de agosto de 2026. La plantilla proporciona a las organizaciones de toda la UE un único formulario estructurado para informar brechas de datos personales a las autoridades de supervisión, reemplazando los formatos nacionales actualmente fragmentados.

Por qué es importante: La plantilla armonizada afecta directamente cómo las organizaciones informan incidentes de exposición de credenciales bajo el Artículo 33 del RGPD, requiriendo divulgación estructurada de tipos de datos comprometidos, individuos afectados y consecuencias probables. Los equipos de cumplimiento y legales deberían revisar el borrador antes de la fecha límite de consulta del 5 de agosto.

Fuente: LexisNexis UK/EU Risk & Compliance — 18 jun 2026

ANSSI dejará de certificar productos de seguridad sin cifrado resistente a la computación cuántica a partir de 2027

La agencia nacional de ciberseguridad de Francia, ANSSI, anunció que dejará de certificar productos de seguridad (incluyendo gestores de contraseñas, VPNs y soluciones de autenticación) que no incorporen criptografía resistente a la computación cuántica (poscuántica) a partir de 2027.

El anuncio acompaña a la estrategia cibernética nacional más amplia de Francia, que incluye una inversión gubernamental de 200 millones de euros en infraestructura de ciberseguridad y herramientas de criptografía poscuántica.

Por qué es importante: Los gestores de contraseñas y bóvedas de credenciales dependen de primitivas criptográficas teóricamente vulnerables a ataques de computación cuántica. El requisito de certificación de ANSSI exige algoritmos poscuánticos para la aprobación del gobierno francés, convirtiendo a Francia en el primer estado miembro de la UE en establecer una fecha límite estricta. El marco de ANSSI es ampliamente referenciado en toda Europa y se espera que influya en el Esquema Europeo de Certificación de Ciberseguridad de ENISA.

Fuente: Reuters — 16 jun 2026

Gartner identifica tres cambios en la gestión de secretos que los equipos de seguridad no pueden ignorar

Gartner identifica tres cambios estratégicos en la gestión de secretos:

1. Gestión de acceso de cargas de trabajo — pasar de secretos estáticos a emisión de credenciales dinámicas y justo a tiempo para cargas de trabajo.
2. Arquitectura sin secretos — eliminar completamente los secretos de larga duración en favor del acceso basado en identidad usando SPIFFE/SPIRE.
3. Gobernanza multi-bóveda — gestionar secretos de forma consistente a través de múltiples plataformas de bóvedas a medida que las organizaciones acumulan almacenes de secretos dispares en HashiCorp Vault, AWS Secrets Manager, Azure Key Vault y otros.

Por qué es importante: Estos tres cambios mapean directamente a los modos de fallo expuestos esta semana. FortiBleed demuestra el riesgo de credenciales estáticas nunca rotadas (Cambio 1). La brecha OAuth de Klue demuestra el riesgo de credenciales heredadas de larga duración (Cambio 2). La deriva de credenciales a través de entornos multi-nube es el problema que aborda el Cambio 3. Este marco proporciona a los líderes de seguridad y TI una forma estructurada de evaluar su madurez actual en gestión de secretos frente a los incidentes de la semana.

Fuente: Akeyless Blog (citando investigación de Gartner) — 17 jun 2026

Resumen de esta semana

El patrón a través de los incidentes de esta semana es lo suficientemente consistente como para nombrarlo: credenciales estáticas, cuentas de servicio olvidadas y tokens de larga duración son los puntos de entrada que los atacantes están explotando activamente.

La aplicación regulatoria está alcanzando. La multa de 85.000 € de la Garante italiana por almacenamiento de contraseñas en texto plano, los plazos federales de PQC de EE. UU. y el límite de certificación de ANSSI para 2027 añaden una dimensión prospectiva: los fundamentos criptográficos del almacenamiento de credenciales están bajo un plazo estricto.

Tres acciones se derivan directamente de los eventos de esta semana:

• Primero, audite las cuentas de servicio e integraciones OAuth de terceros — el ataque de Klue comenzó con una olvidada.
• Segundo, ejecute una verificación de credenciales comprometidas contra el conjunto de datos de HIBP ahora expandido con 124 millones de contraseñas provenientes de infostealers.
• Tercero, revise cómo viven los secretos en las estaciones de trabajo de los desarrolladores. Las credenciales de nube de larga duración son ahora un objetivo explícito de agentes IA.

Las credenciales fuera de cualquier sistema gestionado son la raíz común — claves API codificadas, credenciales de VPN no rotadas, contraseñas en texto plano en servicios fuera de servicio. Passwork proporciona a los equipos de TI y seguridad visibilidad centralizada sobre las contraseñas corporativas y los secretos técnicos, con registros de acceso, seguimiento de rotación y alertas de credenciales comprometidas integrados. Comience con lo que puede controlar

Ciclo de vida de rotación de secretos: Desde la creación hasta la revocación

La rotación de secretos falla cuando se trata como una tarea programada en lugar de un ciclo de vida. Esta guía cubre las siete etapas — desde la creación y propiedad hasta la rotación segura, revocación de emergencia y evidencia de auditoría.

Passwork BlogAlex Muntyan

10 fallos de seguridad en el trabajo remoto (y cómo solucionarlos)

10 fallos de seguridad en el trabajo remoto — y el único principio detrás de todos ellos: la seguridad se rompe donde el camino seguro tiene más fricción que el inseguro. Casos reales, soluciones realistas, una línea base de 5 capas contra la que su equipo puede auditar.

Passwork BlogAlex Muntyan

Controles de acceso NIS2 para la seguridad de la cadena de suministro

El 48% de las brechas ahora involucran a terceros. El Artículo 21 de NIS2 convierte la gobernanza del acceso de proveedores en una obligación legal. Aquí se explica cómo mapear el acceso de proveedores, aplicar MFA y privilegio mínimo, y mantener la evidencia de auditoría que demuestre que sus controles funcionan.

Passwork BlogAlex Muntyan

Diese Woche brachte mehrere schwerwiegende Vorfälle, und alle weisen in dieselbe Richtung. Das Ausmaß der Credential-Kompromittierung bricht weiterhin Rekorde. FortiBleed: 86.000 Geräte in 194 Ländern. Das Elasticsearch-Leck: 24 Milliarden Datensätze aus Dutzenden von Quellen. HIBP fügte 124 Millionen Passwörter hinzu, die von Infostealern zum Zeitpunkt der Nutzung gestohlen wurden. Diese Daten sind bereits im Umlauf.

• Zwei Angriffsmethoden erhielten diese Woche konkrete Bestätigung. Angreifer umgehen Passwörter zunehmend vollständig: Der Klue-Breach begann mit einem vergessenen Dienstkonto und endete mit gestohlenen OAuth-Tokens — ohne dass an irgendeinem Punkt ein Passwort eingegeben wurde.
• KI-Agenten sind zu einem eigenständigen Angriffsvektor geworden: Ein vergiftetes Coding-Test-Repository ermöglichte es einem Angreifer, AWS-Credentials von der Workstation eines Entwicklers in 111 Sekunden zu exfiltrieren, ohne dass Endpoint-Alerts ausgelöst wurden.
• Der regulatorische Druck bewegt sich an zwei Fronten. In Europa wurden der Europarat und die französische Regierungsplattform Tchap kompromittiert, die italienische Garante verhängte eine Geldstrafe gegen ein Unternehmen wegen Speicherung von Passwörtern im Klartext, und neue EDPB- sowie NIS2-Meldepflichtvorlagen wurden veröffentlicht — alles innerhalb einer einzigen Woche.
• In den USA unterzeichnete Präsident Trump zwei Executive Orders, die verbindliche Bundesfristen für die Migration zur Post-Quanten-Kryptographie festlegen. Dies signalisiert, dass das Zeitfenster zur Vorbereitung kürzer ist, als die meisten Organisationen angenommen haben.

Dieser Digest behandelt die 14 bedeutendsten Ereignisse vom 15. bis 22. Juni 2026.

USA setzen Bundesfristen für die Migration zur Post-Quanten-Kryptographie (PQC)

Am 22. Juni 2026 unterzeichnete Präsident Trump zwei Executive Orders zur Quantentechnologie. Die EO „Securing the Nation Against Advanced Cryptographic Attacks" verpflichtet Bundesbehörden, einen PQC-Migrationsverantwortlichen zu benennen, hochwertige Vermögenswerte bis 2030 auf Post-Quanten-Kryptographie umzustellen und die vollständige Migration bis 2031 abzuschließen.

Eine zweite Anordnung weist die Entwicklung eines fehlertoleranten Quantencomputers bis 2028 an. Beide Anordnungen nennen „Harvest Now, Decrypt Later"-Angriffe als primären Bedrohungstreiber — Angreifer sammeln heute verschlüsselte Daten für eine zukünftige Entschlüsselung. Barron's berichtet, dass einige Analysten eine funktionsfähige Quantenentschlüsselungsfähigkeit bereits für 2029 prognostizieren.

Warum es wichtig ist: Die Bundesfristen 2030–2031 werden nicht innerhalb der Regierung bleiben. Beschaffungsverträge und branchenspezifische Regulierungen folgen typischerweise dem Bundesvorbild, daher sollte jede Organisation, die mit Regierungsinfrastruktur zu tun hat oder in einer regulierten Branche tätig ist, dies als frühes Signal betrachten. Der praktische Ausgangspunkt ist zu wissen, was man hat: Welche Systeme von RSA oder ECC abhängen, wo sich kryptographische Schlüssel und Zertifikate tatsächlich befinden und wer sie kontrolliert.

Quelle: Reuters / White House — 22. Jun 2026

FortiBleed: Über 86.000 Fortinet-Geräte-Credentials in 194 Ländern kompromittiert

Eine groß angelegte Credential-Diebstahl-Kampagne hat eine verifizierte Datenbank mit über 86.644 funktionierenden Credentials für internetfähige Fortinet FortiGate Firewalls und SSL-VPN-Appliances zusammengestellt — etwa 50 % aller solcher dem Internet ausgesetzten Geräte. Die Kampagne umfasste das Abfangen von SSL-VPN-Authentifizierung, Hash-Cracking auf einem 45-GPU-Cluster und Active-Directory-Pivoting.

Angreifer führten ungefähr 1,16 Milliarden Credential-Versuche gegen über 320.000 FortiGate-Ziele durch. CISA gab am 18. Juni 2026 eine dringende Warnung heraus, die Organisationen verpflichtet, aktive Sitzungen zu beenden, alle Credentials zurückzusetzen, Phishing-resistente MFA zu aktivieren und PBKDF2-Passwort-Hashing für Admin-Accounts anzuwenden. Huntress bestätigte, dass 845 Partnerorganisationen direkt betroffen waren.

Warum es wichtig ist: Organisationen, die Fortinet-Schwachstellen gepatcht, aber ihre Credentials nie rotiert haben, bleiben vollständig exponiert. Dies ist das entscheidende Credential-Sicherheitsereignis der Woche. Jede Organisation mit internetfähiger Fortinet-Infrastruktur sollte dies als aktiven Vorfall behandeln, der eine sofortige Credential-Rotation erfordert — nicht als geplante Wartungsaufgabe.

Quelle: SecurityWeek — 19. Jun 2026

24 Milliarden gestohlene Credentials durch massives Elasticsearch-Leck exponiert

Cybernews-Forscher entdeckten einen öffentlich zugänglichen Elasticsearch-Cluster mit 24 Milliarden gestohlenen Credential-Datensätzen über 8,3 Terabyte an Daten, die aus 36 verschiedenen Quellen stammten, darunter Infostealer-Malware-Logs, Telegram-Cybercrime-Kanäle und Breach-Sammlungen. Mehr als 1,7 Milliarden Datensätze stammten von Telegram-Kanälen.

Kritisch ist, dass der Cluster auch ungefähr 9.500 CVE-Datensätze enthielt, die mit aktiven GitHub-Repositories verknüpft waren — ein Beweis dafür, dass der Betreiber eine Angriffs-Priorisierungspipeline aufbaute, um ausnutzbare Schwachstellen mit verfügbaren gestohlenen Credentials abzugleichen. Die Datenbank wurde offline genommen, aber die Credentials befinden sich weiterhin im aktiven Umlauf.

Warum es wichtig ist: Die CVE-angereicherte Angriffspipeline verändert die Risikokalkulation: Die Rotation von Credentials nach einem Breach kann zu spät sein, wenn ein Angreifer bereits weiß, welche ungepatchten Dienste sie entsperren. Frische Infostealer-Logs enthalten auch aktive Session-Cookies, die MFA vollständig umgehen. Einzigartige Credentials pro Dienst bleiben die primäre strukturelle Verteidigung.

Quelle: Cybernews — 17. Jun 2026

124 Millionen einzigartige Infostealer-Passwörter zu Have I Been Pwned hinzugefügt

Am 15. Juni 2026 nahm Have I Been Pwned (HIBP) 56,3 Millionen einzigartige E-Mail-Adressen und 124 Millionen einzigartige Passwörter auf, die aus Infostealer-Malware-Logs stammen. Anders als traditionelle Breach-Daten wurden diese Credentials direkt von den Geräten der Opfer zum Zeitpunkt der Nutzung gestohlen — was bedeutet, dass sie aktuell und nicht rotiert sind. Der Datensatz ist jetzt über die Pwned Passwords API durchsuchbar, die in zahlreiche Unternehmens-Passwort-Manager und Identitätsplattformen integriert ist.

Warum es wichtig ist: Organisationen, die Passwort-Manager mit HIBP-Integration verwenden, werden nun Warnungen für einen wesentlich größeren Pool gefährdeter Credentials anzeigen. Die Gefahr hier ist die Aktualität: Mitarbeiter, die ihre Passwörter seit der Infektion ihres Geräts nicht geändert haben, bleiben vollständig exponiert. Dies ist ein direkter Anlass, ein Audit kompromittierter Credentials in Ihrer gesamten Organisation durchzuführen.

Quelle: Have I Been Pwned — 15. Jun 2026

Klue-SaaS-Supply-Chain-Angriff: OAuth-Tokens gestohlen, CRM-Daten von mehreren Sicherheitsanbietern exfiltriert

Eine neue Erpressergruppe namens Icarus (aktiv seit April 2026) verschaffte sich über ein kompromittiertes Legacy-Credential, das mit einem aufgegebenen Integrations-Dienstkonto verknüpft war, Erstzugang zur Market-Intelligence-Plattform Klue. Die Angreifer stahlen dann OAuth-Tokens, die von Klues Kunden zur Verbindung mit Salesforce und Gong verwendet wurden, und führten automatisierte Skripte gegen die Salesforce REST API für bis zu 24 Stunden Massen-CRM-Datenextraktion aus.

Bestätigte Opfer sind Huntress, Recorded Future, Tanium, Gong, Sprout Social, Jamf und Insurity. Salesforce deaktivierte die Klue-Integration.

Warum es wichtig ist: Ein vergessenes Legacy-Dienstkonto-Credential war der initiale Zugangsvektor. Einmal eingedrungen, benötigte der Angreifer keine Passwörter und keine MFA-Codes — das gestohlene OAuth-Token war aus Salesforce-Perspektive die Identität. Der Angriff lief 24 Stunden unentdeckt. Dienstkonto-Credentials und OAuth-Integrationen von Drittanbietern verdienen dieselbe Überwachungsdisziplin wie Mitarbeiterkonten.

Quelle: The Hacker News — 19. Jun 2026

Über 1.230 hartcodierte API-Schlüssel und JWT-Tokens in KI-Agenten-Anweisungsdateien in über 7.000 öffentlichen Repos gefunden

Mitiga Labs scannte über 50.000 KI-Anweisungsdateien (Cursor-Regeln, CLAUDE.md, MCP-Configs, Agent-Brain-Dateien) in über 7.000 öffentlichen GitHub-Repositories und fand über 1.230 hartcodierte API-Schlüssel und JWT-Tokens für Dienste wie Anthropic Claude, OpenAI GPT-5, Google Gemini, Databricks, Supabase, Vercel und Google Cloud Storage.

Separat berichtete GitGuardian, dass 28,65 Millionen Secrets 2025 auf öffentlichem GitHub geleakt wurden (ein Anstieg von 34 % im Jahresvergleich), wobei Leaks von KI-Diensten um 81 % zunahmen.

Warum es wichtig ist: KI-Agenten-Konfigurationsdateien werden zu einem primären Vektor für die Exponierung hartcodierter Credentials. Diese Dateien werden häufig von Benutzern ohne Sicherheitsbewusstsein erstellt — Produktmanager, Forscher, Gründer — die keine standardmäßigen Secrets-Hygienepraktiken anwenden. Die Secrets-Scanning-Richtlinien der meisten Organisationen decken Anweisungsdateien, MCP-Configs und Agent-Kontextdateien noch nicht ab. Das sollten sie.

Quelle: Mitiga Labs — 15. Jun 2026

Vergifteter Coding-Test veranlasst KI-Agenten, AWS-Credentials in unter 2 Minuten zu stehlen

Mitiga dokumentierte einen realen Angriff, bei dem ein gefälschtes Take-Home-Coding-Assessment-Repository versteckte Anweisungen in .cursor/rules-, README.md- und CLAUDE.md-Dateien enthielt. Als ein Entwickler das Repository in Cursor mit aktiviertem Auto-Run öffnete, führte der KI-Coding-Agent autonom cat ~/.aws/credentials, aws sts get-caller-identity, cat ~/.kube/config, terraform state list und einen Grep nach Secrets aus — und exfiltrierte dann alle gesammelten Daten über einen vergifteten MCP-Tool-Aufruf zu einem vom Angreifer kontrollierten Endpunkt. Die gesamte Kette wurde in 1 Minute 51 Sekunden abgeschlossen. Es wurde keine Malware installiert; es wurden keine Endpoint-Alerts generiert.

Warum es wichtig ist: Langlebige Cloud-Credentials, die auf Entwickler-Workstations gespeichert sind, sind jetzt ein primäres Ziel für KI-Agenten-vermittelte Angriffe. Jede Aktion wurde von einem legitimen Tool mit legitimen Befehlen durchgeführt — keine Endpoint-Kontrollen wurden ausgelöst. Die primäre Gegenmaßnahme ist das Ersetzen langlebiger Credentials durch kurzlebige OIDC-Tokens und föderierte Authentifizierung.

Quelle: Mitiga Labs — 19. Jun 2026

ShinyHunters beansprucht Europarat-Breach: 297 GB an HR-, Gehalts- und Medizindaten exponiert

Das Hackerkollektiv ShinyHunters übernahm die Verantwortung für einen Breach des Europarats und behauptete, 297 GB an Daten mit über 429.000 Dateien gestohlen zu haben — darunter 409.000 Gehaltsabrechnungen für über 10.000 Mitarbeiter über 15 Jahre, 14.000 Lebensläufe, 3.700 Personalakten und sensible Datensätze einschließlich Privatadressen, Gehälter, Bankdaten, Steuerinformationen und Krankenakten. Zum 21. Juni 2026 veröffentlichte ShinyHunters die Daten dauerhaft, nachdem der Europarat nicht auf Lösegeldforderungen reagiert hatte.

Warum es wichtig ist: Die exponierten Datensätze schaffen effektive Spear-Phishing-Vektoren gegen eine sensible Institution. ShinyHunters hat nun innerhalb eines einzigen Jahres die Europäische Kommission (März 2026), den Europarat (Juni 2026) und den niederländischen Telekommunikationsanbieter Odido (Februar 2026) für sich beansprucht. Europäische Sicherheitsteams sollten dies als eine anhaltende gezielte Kampagne betrachten, nicht als isolierte Vorfälle.

Quelle: Cybernews — 15. Jun 2026

Frankreichs Tchap-Regierungs-Messaging-Plattform gehackt: 73.467 Beamtenkonten kompromittiert

Frankreichs souveräne Regierungs-Messaging-Plattform Tchap (genutzt von über 825.000 Regierungsangestellten) wurde am 7. Juni 2026 von einem Bedrohungsakteur namens „misere" gehackt. DINUM bestätigte, dass 73.467 Regierungskonten betroffen waren, wobei die exponierten Daten Namen, E-Mail-Adressen und zugehörige Regierungsstellen umfassten.

Der Bedrohungsakteur behauptet zusätzlich, 13,5 GB an Dateien einschließlich über 643.000 Nachrichten gestohlen zu haben. Der Angriffsvektor soll Account-Hijacking beinhalten, möglicherweise über Infostealer-gestützte Credentials.

Warum es wichtig ist: Der Breach illustriert, wie Credential-Kompromittierung (möglicherweise über Stealer-Logs) gegen souveräne Regierungs-Kommunikationsinfrastruktur in großem Maßstab als Waffe eingesetzt werden kann. Sicherheitsexperten stellten fest, dass der Angriff möglicherweise keine Zero-Days erforderte: API-basierte Datenextraktion mit legitimen Credentials reicht für dieses Ausmaß an Exfiltration aus. Unter NIS2 werden digitale Regierungsdienste als wesentliche Einrichtungen klassifiziert, was eine obligatorische Vorfallsmeldung an ANSSI auslöst.

Quelle: SecurityWeek — 15. Jun 2026

Velvet Ant (China-Nexus) installiert Backdoors in Linux-PAM-Modulen und OpenSSH für jahrzehntelangen Credential-Diebstahl

Das Incident-Response-Team von Sygnia deckte Operation Highland auf, eine fast zehn Jahre andauernde Spionagekampagne des mit China verbundenen Bedrohungsakteurs Velvet Ant. Seit mindestens 2016–2017 aktiv, modifizierte die Gruppe Linux Pluggable Authentication Modules (PAM) — insbesondere pam_unix.so — um ein hartcodiertes Backdoor-Passwort zu akzeptieren, Credentials aus legitimen Authentifizierungsversuchen zu sammeln und jegliche Protokollierung von Angreiferaktivitäten zu unterdrücken. Neun Instanzen des mit Backdoor versehenen PAM-Moduls wurden auf kompromittierten Hosts gefunden. Die Gruppe installierte auch Backdoors in OpenSSH-Binärdateien, um persistenten Zugang aufrechtzuerhalten.

Warum es wichtig ist: Dieser Angriff stahl keine Passwörter — er unterwanderte die Authentifizierungsschicht selbst. Durch die Modifizierung von PAM-Modulen konnte Velvet Ant sich als beliebiger Benutzer authentifizieren und jedes auf kompromittierten Hosts eingegebene Passwort abgreifen. Starke Passwörter bieten keinen Schutz, wenn der Authentifizierungs-Stack kompromittiert ist. Betreiber kritischer Infrastrukturen in den Bereichen Energie, Fertigung und Verteidigung stehen vor direkt analogen Risiken.

Quelle: CyberSecurityNews / Sygnia — 15. Jun 2026

Italienische Garante verhängt Geldstrafe von 85.000 € gegen Beratungsfirma wegen Speicherung von Passwörtern im Klartext nach 61.000-Benutzer-Breach

Italiens Datenschutzbehörde, die Garante, verhängte eine Geldstrafe von 85.000 € gegen eine Beratungsfirma nach einem Datenschutzvorfall, bei dem personenbezogene Daten von mehr als 61.000 Benutzern exponiert wurden. Die Garante stellte fest, dass bestimmte Passwörter im Klartext gespeichert oder mit veralteten kryptographischen Algorithmen geschützt waren und dass Credentials für nicht mehr genutzte Systeme über ihre notwendige Aufbewahrungsdauer hinaus gespeichert worden waren. Betroffene Personen wurden etwa zwei Monate nach der Entdeckung benachrichtigt — und erst nach Erlass einer Korrekturanordnung.

Warum es wichtig ist: Die Garante nannte ausdrücklich die Speicherung von Passwörtern im Klartext und veraltete Kryptographie als primäre DSGVO-Verstöße. Dies etabliert einen klaren Durchsetzungspräzedenzfall: Artikel 32 erfordert modernes Passwort-Hashing, und das Aufbewahren von Credentials für stillgelegte Systeme verstößt gegen das Grundprinzip der Speicherbegrenzung. EU-Organisationen sollten ihre Implementierungen zur Passwortspeicherung anhand dieser Entscheidung überprüfen.

Quelle: Gibson Dunn Europe Data Protection — 15. Jun 2026

EDPB verabschiedet harmonisierte EU-weite Vorlage für Datenschutzverletzungsmeldungen gemäß DSGVO

Der Europäische Datenschutzausschuss (EDPB) hat eine standardisierte Vorlage für Meldungen von Verletzungen des Schutzes personenbezogener Daten gemäß DSGVO Artikel 33 verabschiedet, die bis zum 5. August 2026 zur öffentlichen Konsultation steht. Die Vorlage bietet Organisationen in der gesamten EU ein einheitliches strukturiertes Formular zur Meldung von Verletzungen des Schutzes personenbezogener Daten an Aufsichtsbehörden und ersetzt die derzeit fragmentierten nationalen Formate.

Warum es wichtig ist: Die harmonisierte Vorlage wirkt sich direkt darauf aus, wie Organisationen Credential-Expositionsvorfälle gemäß DSGVO Artikel 33 melden. Sie erfordert eine strukturierte Offenlegung der kompromittierten Datentypen, betroffenen Personen und wahrscheinlichen Folgen. Compliance- und Rechtsteams sollten den Entwurf vor Ablauf der Konsultationsfrist am 5. August prüfen.

Quelle: LexisNexis UK/EU Risk & Compliance — 18. Jun 2026

ANSSI wird ab 2027 keine Sicherheitsprodukte mehr ohne quantenresistente Verschlüsselung zertifizieren

Frankreichs nationale Cybersicherheitsbehörde ANSSI kündigte an, dass sie ab 2027 keine Sicherheitsprodukte (einschließlich Passwort-Manager, VPNs und Authentifizierungslösungen) mehr zertifizieren wird, die keine quantenresistente (Post-Quanten) Kryptographie integrieren.

Die Ankündigung begleitet Frankreichs breitere nationale Cyber-Strategie, die eine staatliche Investition von 200 Millionen Euro in Cybersicherheitsinfrastruktur und Post-Quanten-Kryptographie-Tools umfasst.

Warum es wichtig ist: Passwort-Manager und Credential-Tresore basieren auf kryptographischen Primitiven, die theoretisch anfällig für Quantencomputing-Angriffe sind. ANSSIs Zertifizierungsanforderung schreibt Post-Quanten-Algorithmen für die französische Regierungszulassung vor, womit Frankreich der erste EU-Mitgliedstaat ist, der eine harte Frist setzt. Das ANSSI-Rahmenwerk wird in ganz Europa weithin referenziert und wird voraussichtlich das Europäische Cybersicherheits-Zertifizierungsschema der ENISA beeinflussen.

Quelle: Reuters — 16. Jun 2026

Gartner identifiziert drei Veränderungen im Secrets-Management, die Sicherheitsteams nicht ignorieren können

Gartner identifiziert drei strategische Veränderungen im Secrets-Management:

1. Workload Access Management — der Wechsel von statischen Secrets zu dynamischer, Just-in-Time-Credential-Ausgabe für Workloads.
2. Secretless Architecture — die vollständige Eliminierung langlebiger Secrets zugunsten von identitätsbasiertem Zugriff mittels SPIFFE/SPIRE.
3. Multi-Vault Governance — konsistentes Management von Secrets über mehrere Tresor-Plattformen hinweg, da Organisationen unterschiedliche Secrets-Speicher über HashiCorp Vault, AWS Secrets Manager, Azure Key Vault und andere ansammeln.

Warum es wichtig ist: Diese drei Veränderungen korrespondieren direkt mit den diese Woche aufgedeckten Fehlermodi. FortiBleed demonstriert das Risiko statischer, nie rotierter Credentials (Veränderung 1). Der Klue-OAuth-Breach demonstriert das Risiko langlebiger Legacy-Credentials (Veränderung 2). Credential-Drift über Multi-Cloud-Umgebungen ist das Problem, das Veränderung 3 adressiert. Dieses Rahmenwerk gibt Sicherheits- und IT-Führungskräften eine strukturierte Möglichkeit, ihre aktuelle Secrets-Management-Reife anhand der Vorfälle dieser Woche zu bewerten.

Quelle: Akeyless Blog (unter Berufung auf Gartner-Forschung) — 17. Jun 2026

Zusammenfassung dieser Woche

Das Muster über die Vorfälle dieser Woche hinweg ist konsistent genug, um es zu benennen: Statische Credentials, vergessene Dienstkonten und langlebige Tokens sind die Einstiegspunkte, die Angreifer aktiv ausnutzen.

Die regulatorische Durchsetzung holt auf. Die Geldstrafe von 85.000 € der italienischen Garante für Klartext-Passwortspeicherung, die US-Bundesfristen für PQC und ANSSIs Zertifizierungsfrist 2027 fügen eine zukunftsorientierte Dimension hinzu: Die kryptographischen Grundlagen der Credential-Speicherung selbst stehen unter einer harten Frist.

Drei Maßnahmen ergeben sich direkt aus den Ereignissen dieser Woche:

• Erstens: Prüfen Sie Dienstkonten und OAuth-Integrationen von Drittanbietern — der Klue-Angriff begann mit einem vergessenen Konto.
• Zweitens: Führen Sie eine Prüfung kompromittierter Credentials gegen den HIBP-Datensatz durch, der jetzt um 124 Millionen Infostealer-gestützte Passwörter erweitert wurde.
• Drittens: Überprüfen Sie, wie Secrets auf Entwickler-Workstations gespeichert werden. Langlebige Cloud-Credentials sind jetzt ein explizites KI-Agenten-Ziel.

Credentials außerhalb jedes verwalteten Systems sind die gemeinsame Wurzel — hartcodierte API-Schlüssel, nicht rotierte VPN-Credentials, Klartext-Passwörter in stillgelegten Diensten. Passwork bietet IT- und Sicherheitsteams zentrale Transparenz über Unternehmenspasswörter und technische Secrets, mit integrierten Zugriffsprotokollen, Rotations-Tracking und Warnungen zu kompromittierten Credentials. Beginnen Sie mit dem, was Sie kontrollieren können

Secrets-Rotations-Lebenszyklus: Von der Erstellung bis zum Widerruf

Secret-Rotation scheitert, wenn sie als geplante Aufgabe statt als Lebenszyklus behandelt wird. Dieser Leitfaden behandelt alle sieben Phasen — von der Erstellung und Eigentümerschaft bis zur sicheren Rotation, Notfall-Widerruf und Audit-Nachweisen.

Passwork BlogAlex Muntyan

10 Sicherheitsfehler bei Remote-Arbeit (und wie man sie behebt)

10 Sicherheitsfehler bei Remote-Arbeit — und das eine Prinzip hinter allen: Sicherheit bricht dort zusammen, wo der sichere Weg mehr Reibung hat als der unsichere. Echte Fälle, realistische Lösungen, eine 5-Schichten-Baseline, gegen die Ihr Team prüfen kann.

Passwork BlogAlex Muntyan

NIS2-Zugriffskontrollen für Supply-Chain-Sicherheit

48 % der Breaches betreffen mittlerweile Drittparteien. NIS2 Artikel 21 macht Lieferanten-Zugangs-Governance zur rechtlichen Pflicht. So kartieren Sie Lieferantenzugang, setzen MFA und Least Privilege durch und bewahren die Audit-Nachweise auf, die belegen, dass Ihre Kontrollen funktionieren.

Passwork BlogAlex Muntyan

This week brought several major incidents, and all of them point in the same direction. The scale of credential compromise keeps breaking records. FortiBleed: 86,000 devices across 194 countries. The Elasticsearch leak: 24 billion records from dozens of sources. HIBP added 124 million passwords stolen by infostealers at the moment of use. This data is already in circulation.

• Two attack methods received concrete confirmation this week. Attackers are increasingly bypassing passwords altogether: the Klue breach started with a forgotten service account and ended with stolen OAuth tokens — no password entered at any point. 
• AI agents have become an independent attack vector: a poisoned coding test repository allowed an attacker to exfiltrate AWS credentials from a developer's workstation in 111 seconds, with no endpoint alerts generated.
• Regulatory pressure is moving on two fronts. In Europe, the Council of Europe and French government platform Tchap were breached, the Italian Garante fined a firm for storing passwords in cleartext, and new EDPB and NIS2 incident reporting templates dropped — all within a single week. 
• In the U.S., President Trump signed two executive orders setting hard federal deadlines for post-quantum cryptography migration, signaling that the window for preparation is shorter than most organizations have assumed.

This digest covers the 14 most significant events from 15 to 22 June 2026.

U.S. sets federal deadlines for post-quantum cryptography (PQC) migration

On 22 June 2026, President Trump signed two executive orders on quantum technology. EO "Securing the Nation Against Advanced Cryptographic Attacks" requires federal agencies to designate a PQC migration lead, transition high-value assets to post-quantum cryptography by 2030, and complete full migration by 2031.

A second order directs development of a fault-tolerant quantum computer by 2028. Both orders cite "harvest now, decrypt later" attacks as the primary threat driver — adversaries collecting encrypted data today for future decryption. Barron's reports that some analysts put viable quantum decryption capability as early as 2029.

Why it matters: The 2030–2031 federal deadlines will not stay inside the government. Procurement contracts and sector-specific regulation tend to follow federal precedent, so any organization that touches government infrastructure or operates in a regulated industry should treat this as an early signal. The practical starting point is knowing what you have: which systems depend on RSA or ECC, where cryptographic keys and certificates actually live, and who controls them.

Source: Reuters / White House — 22 Jun 2026

FortiBleed: 86,000+ fortinet device credentials compromised across 194 countries

A large-scale credential theft campaign has compiled a verified database of over 86,644 working credentials for internet-facing Fortinet FortiGate firewalls and SSL VPN appliances — roughly 50% of all such devices exposed to the internet. The campaign involved SSL VPN authentication interception, hash-cracking on a 45-GPU cluster, and Active Directory pivoting.

Attackers executed approximately 1.16 billion credential attempts against 320,000+ FortiGate targets. CISA issued an urgent advisory on 18 June 2026, requiring organizations to terminate active sessions, reset all credentials, enable phishing-resistant MFA, and apply PBKDF2 password hashing for admin accounts. Huntress confirmed 845 partner organizations were directly impacted.

Why it matters: Organizations that patched Fortinet vulnerabilities but never rotated credentials remain fully exposed. This is the defining credential security event of the week. Any organization with internet-facing Fortinet infrastructure should treat this as an active incident requiring immediate credential rotation — not a scheduled maintenance task.

Source: SecurityWeek — 19 Jun 2026

24 billion stolen credentials exposed in colossal Elasticsearch leak

Cybernews researchers discovered a publicly accessible Elasticsearch cluster containing 24 billion stolen credential records across 8.3 terabytes of data, drawn from 36 distinct sources including infostealer malware logs, Telegram cybercrime channels, and breach compilations. More than 1.7 billion records originated from Telegram channels.

Critically, the cluster also contained approximately 9,500 CVE records linked to active GitHub repositories — evidence the operator was building an attack-prioritization pipeline to cross-reference exploitable vulnerabilities with available stolen credentials. The database has been taken offline, but the credentials remain in active circulation.

Why it matters: The CVE-enriched attack pipeline changes the risk calculation: rotating credentials after a breach may be too late if an attacker already knows which unpatched services they unlock. Fresh infostealer logs also contain active session cookies that bypass MFA entirely. Unique credentials per service remain the primary structural defense.

Source: Cybernews — 17 Jun 2026

124 million unique infostealer passwords added to Have I Been Pwned

On 15 June 2026, Have I Been Pwned (HIBP) ingested 56.3 million unique email addresses and 124 million unique passwords sourced from infostealer malware logs. Unlike traditional breach data, these credentials were stolen directly from victims' devices at the time of use — meaning they are current and unrotated. The dataset is now searchable via the Pwned Passwords API, which is integrated into numerous enterprise password managers and identity platforms.

Why it matters: Organizations using password managers with HIBP integration will now surface alerts for a substantially larger pool of at-risk credentials. The danger here is freshness: employees who have not changed passwords since their device was infected remain fully exposed. This is a direct prompt to run a compromised credential audit across your organization.

Source: Have I Been Pwned — 15 Jun 2026

Klue SaaS supply chain attack: OAuth tokens stolen, CRM data exfiltrated from multiple security vendors

A new extortion group called Icarus (active since April 2026) gained initial access to market intelligence platform Klue via a compromised legacy credential associated with an abandoned integration service account. Attackers then stole OAuth tokens used by Klue's customers to connect to Salesforce and Gong, and ran automated scripts against the Salesforce REST API for up to 24 hours of bulk CRM data extraction.

Confirmed victims include Huntress, Recorded Future, Tanium, Gong, Sprout Social, Jamf, and Insurity. Salesforce disabled the Klue integration.

Why it matters: A forgotten legacy service account credential was the initial access vector. Once inside, the attacker needed no passwords and no MFA codes — the stolen OAuth token was the identity from Salesforce's perspective. The attack ran undetected for 24 hours. Service account credentials and third-party OAuth integrations warrant the same monitoring discipline as employee accounts.

Source: The Hacker News — 19 Jun 2026

1,230+ hardcoded API keys and JWT tokens found in AI agent instruction files across 7,000+ public repos

Mitiga Labs scanned 50,000+ AI instruction files (Cursor rules, CLAUDE.md, MCP configs, agent brain files) across 7,000+ public GitHub repositories and found over 1,230 hardcoded API keys and JWT tokens across services including Anthropic Claude, OpenAI GPT-5, Google Gemini, Databricks, Supabase, Vercel, and Google Cloud Storage.

Separately, GitGuardian reported that 28.65 million secrets were leaked on public GitHub in 2025 (a 34% year-on-year increase) with AI service leaks up 81%.

Why it matters: AI agent configuration files are becoming a primary vector for hardcoded credential exposure. These files are frequently created by non-security-aware users — product managers, researchers, founders — who do not apply standard secrets hygiene. Most organizations' secrets scanning policies do not yet cover instruction files, MCP configs, and agent context files. They should.

Source: Mitiga Labs — 15 Jun 2026

Poisoned coding test causes AI agent to steal AWS credentials in under 2 minutes

Mitiga documented a real-world attack in which a fake take-home coding assessment repository contained hidden instructions in .cursor/rules, README.md, and CLAUDE.md files. When a developer opened the repository in Cursor with auto-run enabled, the AI coding agent autonomously executed cat ~/.aws/credentials, aws sts get-caller-identity, cat ~/.kube/config, terraform state list, and a grep for secrets — then exfiltrated all collected data to an attacker-controlled endpoint via a poisoned MCP tool call. The entire chain completed in 1 minute 51 seconds. No malware was dropped; no endpoint alerts were generated.

Why it matters: Long-lived cloud credentials stored on developer workstations are now a primary target for AI-agent-mediated attacks. Every action was performed by a legitimate tool using legitimate commands — no endpoint controls triggered. The primary mitigation is replacing long-lived credentials with short-lived OIDC tokens and federated authentication.

Source: Mitiga Labs — 19 Jun 2026

ShinyHunters claims Council of Europe breach: 297 GB of HR, payroll, and medical records exposed

The hacker collective ShinyHunters claimed responsibility for a breach of the Council of Europe, alleging theft of 297 GB of data comprising over 429,000 files — including 409,000 payslips covering 10,000+ staff over 15 years, 14,000 CVs, 3,700 personnel files, and sensitive records including home addresses, salaries, bank details, tax information, and medical records. As of 21 June 2026, ShinyHunters published the data permanently after the Council of Europe did not respond to ransom demands.

Why it matters: The exposed records create effective spear-phishing vectors against a sensitive institution. ShinyHunters has now claimed the European Commission (March 2026), the Council of Europe (June 2026), and Dutch telecom Odido (February 2026) within a single year. European security teams should treat this as a sustained targeting campaign, not isolated incidents.

Source: Cybernews — 15 Jun 2026

France's Tchap government messaging platform breached: 73,467 officials' accounts compromised

France's sovereign government messaging platform Tchap (used by over 825,000 government employees) was breached on 7 June 2026 by a threat actor calling itself "misere." DINUM confirmed 73,467 government accounts were affected, with exposed data including names, email addresses, and affiliated government entities.

The threat actor additionally claims to have stolen 13.5 GB of files including over 643,000 messages. The attack vector is believed to involve account hijacking, possibly via infostealer-sourced credentials.

Why it matters: The breach illustrates how credential compromise (potentially via stealer logs) can be weaponized against sovereign government communication infrastructure at scale. Security experts noted the attack may not have required zero-days: API-based data extraction using legitimate credentials is sufficient for this scale of exfiltration. Under NIS2, government digital services are classified as essential entities, triggering mandatory incident reporting to ANSSI.

Source: SecurityWeek — 15 Jun 2026

Velvet Ant (China-Nexus) backdoors Linux PAM modules and OpenSSH for decade-long credential theft

Sygnia's incident response team uncovered Operation Highland, a near-decade-long espionage campaign by the China-linked Velvet Ant threat actor. Active since at least 2016–2017, the group modified Linux Pluggable Authentication Modules (PAM) — specifically pam_unix.so — to accept a hardcoded backdoor password, harvest credentials from legitimate authentication attempts, and suppress all logging of attacker activity. Nine instances of the backdoored PAM module were found across compromised hosts. The group also backdoored OpenSSH binaries to maintain persistent access.

Why it matters: This attack did not steal passwords — it subverted the authentication layer itself. By modifying PAM modules, Velvet Ant could authenticate as any user and harvest every password entered on compromised hosts. Strong passwords offer no protection when the authentication stack is compromised. Critical infrastructure operators in energy, manufacturing, and defense face directly analogous risks.

Source: CyberSecurityNews / Sygnia — 15 Jun 2026

Italian Garante fines consulting firm €85,000 for storing passwords in cleartext after 61,000-user breach

Italy's data protection authority, the Garante, imposed an €85,000 fine on a consulting firm following a data breach exposing personal data of more than 61,000 users. The Garante found that certain passwords were stored in cleartext or protected with outdated cryptographic algorithms, and that credentials for unused systems had been retained beyond their necessary period. Affected individuals were notified approximately two months after discovery — and only after a corrective order was issued.

Why it matters: The Garante explicitly cited cleartext password storage and obsolete cryptography as the primary GDPR infringements. This establishes a clear enforcement precedent: Article 32 requires modern password hashing, and retaining credentials for decommissioned systems violates the storage limitation principle. EU organizations should audit their password storage implementations against this decision.

Source: Gibson Dunn Europe Data Protection — 15 Jun 2026

EDPB adopts harmonized EU-wide data breach notification template under GDPR

The European Data Protection Board (EDPB) has adopted a standardized template for personal data breach notifications under GDPR Article 33, open for public consultation until 5 August 2026. The template provides organizations across the EU with a single structured form for reporting personal data breaches to supervisory authorities, replacing the currently fragmented national formats.

Why it matters: The harmonized template directly affects how organizations report credential exposure incidents under GDPR Article 33, requiring structured disclosure of compromised data types, affected individuals, and likely consequences. Compliance and legal teams should review the draft before the 5 August consultation deadline.

Source: LexisNexis UK/EU Risk & Compliance — 18 Jun 2026

ANSSI will stop certifying security products without quantum-resistant encryption from 2027

France's national cybersecurity agency ANSSI announced it will cease certifying security products (including password managers, VPNs, and authentication solutions) that do not incorporate quantum-resistant (post-quantum) cryptography starting from 2027.

The announcement accompanies France's broader national cyber strategy, which includes a €200 million government investment in cybersecurity infrastructure and post-quantum cryptography tooling.

Why it matters: Password managers and credential vaults rely on cryptographic primitives theoretically vulnerable to quantum computing attacks. ANSSI's certification requirement mandates post-quantum algorithms for French government approval, making France the first EU member state to set a hard deadline. ANSSI's framework is widely referenced across Europe and is expected to influence ENISA's European Cybersecurity Certification Scheme.

Source: Reuters — 16 Jun 2026

Gartner identifies three shifts in secrets management security teams cannot ignore

Gartner identifies three strategic shifts in secrets management:

1. Workload Access Management — moving from static secrets to dynamic, just-in-time credential issuance for workloads.
2. Secretless Architecture — eliminating long-lived secrets entirely in favor of identity-based access using SPIFFE/SPIRE.
3. Multi-Vault Governance — managing secrets consistently across multiple vault platforms as organizations accumulate disparate secrets stores across HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and others.

Why it matters: These three shifts map directly to the failure modes exposed this week. FortiBleed demonstrates the risk of static credentials never rotated (Shift 1). The Klue OAuth breach demonstrates the risk of long-lived legacy credentials (Shift 2). Credential drift across multi-cloud environments is the problem Shift 3 addresses. This framework gives security and IT leadership a structured way to assess their current secrets management maturity against the week's incidents.

Source: Akeyless Blog (citing Gartner research) — 17 Jun 2026

This week's recap

The pattern across this week's incidents is consistent enough to name: static credentials, forgotten service accounts, and long-lived tokens are the entry points attackers are actively exploiting.

Regulatory enforcement is catching up. The Italian Garante's €85,000 fine for cleartext password storage, the U.S. federal PQC deadlines, and ANSSI's 2027 certification cutoff add a forward-looking dimension: the cryptographic foundations of credential storage are themselves under a hard timeline.

Three actions follow directly from this week's events:

• First, audit service accounts and third-party OAuth integrations — the Klue attack started with a forgotten one.
• Second, run a compromised credential check against the HIBP dataset now expanded by 124 million infostealer-sourced passwords.
• Third, review how secrets live on developer workstations. Long-lived cloud credentials are now an explicit AI-agent target.

Credentials outside any managed system are the common root — hardcoded API keys, unrotated VPN credentials, cleartext passwords in decommissioned services. Passwork gives IT and security teams centralized visibility over corporate passwords and technical secrets, with access logs, rotation tracking, and compromised credential alerts built in. Start with what you can control

Secrets rotation lifecycle: From creation to revocation

Secret rotation fails when it’s treated as a scheduled task rather than a lifecycle. This guide covers all seven stages — from creation and ownership to safe rotation, emergency revocation, and audit evidence.

Passwork BlogAlex Muntyan

10 Remote Work Security Fails (And How to Fix Them)

10 remote work security fails — and the one principle behind all of them: security breaks where the secure path has more friction than the insecure one. Real cases, realistic fixes, a 5-layer baseline your team can audit against.

Passwork BlogAlex Muntyan

NIS2 access controls for supply chain security

48% of breaches now involve third parties. NIS2 Article 21 makes supplier access governance a legal obligation. Here’s how to map vendor access, enforce MFA and least privilege, and keep the audit evidence that proves your controls work.

Passwork BlogAlex Muntyan

Noch vor wenigen Jahren war der Standardrat einfach: Prüfen Sie Ihre Anbieter, unterzeichnen Sie eine Geheimhaltungsvereinbarung, führen Sie einen jährlichen Fragebogen durch. Dann kam SolarWinds, dann MOVEit, dann XZ Utils — eine Hintertür, die über zwei Jahre legitimer Open-Source-Beiträge eingeschleust und von einem Ingenieur entdeckt wurde, dem auffiel, dass ein Prozess 500 ms langsamer lief als erwartet. Jeder dieser Angriffe erfolgte über eine vertrauenswürdige Beziehung.

Das Muster ist bei jedem größeren Vorfall gleich. Die Beteiligung von Drittanbietern macht laut Verizons 2026 DBIR mittlerweile 48 % aller Datenschutzverletzungen aus (gegenüber 30 % im Vorjahr), und die durchschnittliche Kompromittierung der Lieferkette kostet 4,91 Millionen US-Dollar und benötigt 267 Tage zur Eindämmung, laut IBMs Cost of a Data Breach Report 2025. 

Die meisten Organisationen reagieren weiterhin mit Fragebögen und jährlichen Audits. Diese haben ihren Platz. Aber ein Fragebogen verhindert keine Sicherheitsverletzung. Das Widerrufen der permanenten Berechtigungen eines Anbieters schon. Dieser Leitfaden behandelt Lieferkettensicherheit als das, was sie tatsächlich ist: ein IAM- und Credential-Control-Problem mit einer Compliance-Ebene darüber.

Wichtige Erkenntnisse

• Die Beteiligung von Drittanbietern macht mittlerweile 48 % aller Datenschutzverletzungen aus — gegenüber 30 % im Vorjahr, laut Verizons 2026 DBIR. Lieferkettenangriffe sind der dominierende Angriffsvektor.
• Die durchschnittliche Kompromittierung der Lieferkette kostet 4,91 Millionen US-Dollar und benötigt 267 Tage zur Eindämmung. Diese Verweildauer macht permanente Anbieterberechtigungen so gefährlich — Angreifer müssen sich nicht beeilen, wenn die Anmeldedaten nie ablaufen.
• Jeder größere Lieferkettenvorfall erfolgte über eine vertrauenswürdige Beziehung. SolarWinds, MOVEit, XZ Utils — in jedem Fall nutzte der Angreifer Zugriff, der bereits bereitgestellt und bereits als vertrauenswürdig eingestuft war.
• Fragebögen und jährliche Audits verhindern keine Sicherheitsverletzungen. Das Widerrufen permanenter Anbieterberechtigungen schon. Die entscheidenden Kontrollen sind technischer Natur: Credential-Vaulting, JIT-Zugriff, RBAC mit Beschränkung auf den Auftrag und Phishing-resistente MFA.
• NIS2, DORA und der EU Cyber Resilience Act machen Lieferkettensicherheit zur gesetzlichen Pflicht. NIS2 Artikel 21, DORA Artikel 28–30 und CRA-Anforderungen gelten mit gestaffelten Fristen bis 2027.
• 70 % der Top-50-Anbieter, die von Global-2000-Unternehmen gemeinsam genutzt werden, weisen mindestens eine ungepatchte KEV-Schwachstelle auf, laut Black Kites Third-Party Breach Report 2026.

Was ist Cyber Supply Chain Risk Management (C-SCRM)?

Cyber Supply Chain Risk Management (C-SCRM) ist die Disziplin der Identifizierung, Bewertung und Minderung von Cybersicherheitsrisiken, die aus dem erweiterten Netzwerk von Lieferanten, Anbietern, Dienstleistern und Software-Abhängigkeiten einer Organisation stammen. Es umfasst alles von den SaaS-Tools, die Ihre Entwickler nutzen, bis hin zum Managed Service Provider (MSP) mit Admin-Zugriff auf Ihre Produktionsumgebung.

C-SCRM liegt an der Schnittstelle von Beschaffung, IT-Sicherheit und Compliance. NIST SP 800-161 Rev. 1 bietet das detaillierteste föderale Framework dafür und definiert C-SCRM als strukturierten Prozess zur Steuerung der Exposition gegenüber Cybersicherheitsrisiken während des gesamten Lieferketten-Lebenszyklus — von der ersten Anbieterauswahl bis zur Vertragsbeendigung und Zugriffsentzug.

Der Umfang ist größer, als den meisten Teams bewusst ist. Ihre Lieferkette umfasst:

• Softwareanbieter und Open-Source-Abhängigkeiten
• Cloud-Infrastruktur und SaaS-Anbieter
• Managed-Service- und IT-Support-Anbieter
• Hardwarehersteller und Firmware-Lieferanten
• Beratungsunternehmen mit Netzwerk- oder Datenzugriff

Jeder dieser Bereiche ist ein potenzieller Eintrittspunkt. Die Vorfälle SolarWinds, MOVEit und XZ Utils nutzten diesen Eintrittspunkt auf unterschiedliche Weise aus.

Der Stand der Lieferkettenangriffe 2025–2026

Lieferkettenangriffe erreichten 2025–2026 Rekordniveaus. Verizons 2026 DBIR verzeichnete eine Drittanbieterbeteiligung bei 48 % aller analysierten Sicherheitsverletzungen — der höchste Wert in der Geschichte des Berichts und ein Anstieg um 60 % gegenüber den 30 % des Vorjahres. IBMs Cost of a Data Breach Report 2025 beziffert die durchschnittliche Kompromittierung der Lieferkette auf 4,91 Millionen US-Dollar mit einem durchschnittlichen Lebenszyklus von 267 Tagen von der Erkennung bis zur Eindämmung.

Bedrohungsakteure haben gelernt, dass die Kompromittierung eines vertrauenswürdigen Anbieters gleichzeitig Zugang zu Dutzenden oder Hunderten von nachgelagerten Organisationen ermöglicht. Die Wirtschaftlichkeit begünstigt den Angreifer: ein erfolgreicher Einbruch, multipliziert über die gesamte Kundenbasis eines Anbieters.

Laut Black Kites Third-Party Breach Report 2026 weisen 70 % der Top-50-Anbieter, die von Global-2000-Unternehmen gemeinsam genutzt werden, mindestens eine ungepatchte Schwachstelle aus dem CISA Known Exploited Vulnerabilities (KEV) Katalog auf. Dies sind keine theoretischen Risiken — CISA kennzeichnet KEV-Einträge speziell deshalb, weil sie aktiv in freier Wildbahn ausgenutzt werden.

Lehren aus SolarWinds, MOVEit und XZ Utils

Alle drei Vorfälle haben einen gemeinsamen Nenner: Der initiale Zugriffsvektor war vertrauenswürdig. Vertrauenswürdige Software, vertrauenswürdiger Anbieter, vertrauenswürdiger Mitwirkender. Einmal drinnen, bewegte sich der Angreifer lateral mit Anmeldedaten und Zugriff, die bereits bereitgestellt waren.

SolarWinds (2020)

Angreifer kompromittierten die Build-Pipeline direkt und fügten eine Hintertür in ein signiertes Software-Update ein, das als routinemäßiger Patch an Kunden verteilt wurde. Etwa 18.000 Organisationen installierten es. Die rechtlichen Folgen zogen sich über Jahre hin: Die SEC reichte im Oktober 2023 eine zivilrechtliche Klage gegen SolarWinds und seinen CISO ein, wobei der Fall schließlich 2025 vollständig abgewiesen wurde.

Die Lehre: Kontrollen der Software-Integrität und SBOM-Transparenz (Software Bill of Materials) sind genauso wichtig wie Netzwerkperimeterkontrollen — und die Haftungsexposition durch eine Build-Pipeline-Kompromittierung reicht weit über die ursprüngliche Sicherheitsverletzung hinaus.

MOVEit (2023)

Eine Zero-Day-SQL-Injection-Schwachstelle (CVE-2023-34362) in einem Managed-File-Transfer-Produkt gab der Cl0p-Ransomware-Gruppe Zugang zu Daten von über 2.700 Organisationen — von denen viele keine direkte Beziehung zu MOVEit hatten, aber durch die Nutzung bei ihren Anbietern betroffen waren. Die endgültige Opferzahl erreichte etwa 95 Millionen Personen. 

Die Lehre: Ihre Angriffsfläche umfasst Software, die Ihre Anbieter betreiben, nicht nur Software, die Sie selbst betreiben.

XZ Utils (2024)

Eine mehrjährige Social-Engineering-Kampagne fügte eine Hintertür in eine weit verbreitete Open-Source-Kompressionsbibliothek ein. Der Angreifer trug zwei Jahre lang legitimen Code bei, bevor er die schädliche Payload einführte — und die Hintertür wurde nicht durch einen formalen Sicherheitsprozess entdeckt, sondern von einem Microsoft-Ingenieur, dem eine 500-ms-Verzögerung bei SSH-Logins auffiel. 

Die Lehre: Das Risiko von Open-Source-Abhängigkeiten ist real, SBOMs sind der einzige systematische Weg, es zu verfolgen, und Ihre Erkennungskontrollen müssen Verhalten abdecken, nicht nur Signaturen.

Die größten Anbieterrisiken in der modernen Lieferkette

Die fünf häufigsten Kategorien von Lieferkettenrisiken sind:

• Geteilte Anmeldedaten und mangelhafte Zugangskontrolle
• Schwachstellen in Software-Abhängigkeiten
• Hardware- und Komponenten-Manipulation
• Shadow AI und Datenexposition durch Dritte
• Anbieter-Konzentrationsrisiko

Jede erfordert eine eigene Kontrollmaßnahme. Fehler bei geteilten Anmeldedaten sind ein Prozessproblem. Hardware-Manipulation erfordert physische Herkunftsverifizierung.

Geteilte Anmeldedaten und mangelhafte Zugangskontrolle

Das häufigste und am leichtesten vermeidbare Lieferkettenrisiko ist auch das am wenigsten spektakuläre: gemeinsam genutzte Konten. Ein Anbieter-Support-Team erhält einen einzigen Satz Anmeldedaten für den Zugriff auf Ihre Umgebung. Diese Anmeldedaten werden unter den Mitarbeitern des Anbieters geteilt, in einer Tabelle oder E-Mail-Kette gespeichert und nach Ende des Auftrags nie rotiert.

Wenn dieser Anbieter kompromittiert wird oder ein verärgerter Mitarbeiter das Unternehmen verlässt, haben Sie keine Möglichkeit zu wissen, wer diese Anmeldedaten wann verwendet hat oder worauf zugegriffen wurde. Sie haben keinen Audit-Trail. Sie haben keine Möglichkeit, den Zugriff für eine einzelne Person zu widerrufen, ohne die Anmeldedaten für alle zu ändern.

Verizons 2026 DBIR identifiziert Authentifizierungsfehler (fehlende oder umgangene MFA, gestohlene Anmeldedaten) als den primären Mechanismus bei Drittanbieter-Sicherheitsverletzungen. Dies ist ein Prozessfehler.

Schwachstellen in der Software-Lieferkette und die Notwendigkeit von SBOMs

Eine Software Bill of Materials (SBOM) ist ein maschinenlesbares Inventar aller Komponenten eines Softwareprodukts: Bibliotheken, Abhängigkeiten, Versionen und ihre bekannten Schwachstellen. Die U.S. Executive Order 14028 (2021) schrieb SBOMs für Software vor, die an Bundesbehörden verkauft wird. Der EU Cyber Resilience Act (CRA) erweitert ähnliche Anforderungen auf Produkte, die auf dem europäischen Markt verkauft werden, wobei Schwachstellen-Meldepflichten ab September 2026 und vollständige Produktanforderungen ab Dezember 2027 gelten.

Ohne eine SBOM können Sie die Frage „Nutzen wir die verwundbare Version von Log4j?" nicht innerhalb von 24 Stunden beantworten. Mit einer schon. Dieser Geschwindigkeitsunterschied ist die Lücke zwischen einem eingedämmten Vorfall und einer Sicherheitsverletzung, deren Behebung 267 Tage dauert.

Hardware- und Komponenten-Manipulation

Das Hardware-Lieferkettenrisiko unterscheidet sich vom Softwarerisiko und wird oft unterschätzt. Gefälschte oder manipulierte Komponenten — Netzwerkausrüstung, Server-Hardware, Firmware — können persistente Hintertüren einführen, die eine Betriebssystem-Neuinstallation überleben und für Software-Layer-Sicherheitskontrollen unsichtbar sind.

Der EU Cyber Resilience Act adressiert explizit Hardwareprodukte mit digitalen Elementen und verlangt von Herstellern, die Lieferkettensicherheit für physische Komponenten zu bewerten und zu dokumentieren. Für Organisationen, die Netzwerkinfrastruktur oder industrielle Steuerungssysteme beschaffen, bedeutet dies die Verifizierung der Komponentenherkunft, das Anfordern von Firmware-Integritätsnachweisen von Lieferanten und die Führung eines Inventars von Hardware-Versionen, das einer Software-SBOM entspricht.

Shadow AI und Datenexposition durch Dritte

Verizons 2026 DBIR identifiziert Shadow AI als eines der drei größten Insider-Verhaltensweisen — Mitarbeiter, die nicht autorisierte KI-Tools nutzen, die Organisationsdaten außerhalb genehmigter Kanäle verarbeiten. Der Lieferkettenaspekt: Viele dieser Tools sind Drittanbieter-SaaS-Produkte mit eigenen Datenaufbewahrungsrichtlinien, Unterauftragnehmervereinbarungen und Sicherheitslagen, die Ihre Organisation nie überprüft hat.

Wenn ein Entwickler Datenbank-Anmeldedaten in einen KI-Assistenten einfügt, um eine Abfrage zu debuggen, können diese Anmeldedaten aufbewahrt, protokolliert oder für das Modelltraining verwendet werden. Das Anbieterrisiko ist nicht nur der KI-Anbieter — es ist jeder Unterauftragnehmer in deren Kette.

Verfügbarkeitsunterbrechungen und Anbieter-Konzentrationsrisiko

Ein Sicherheitsversagen in der Lieferkette bedeutet nicht immer eine Datenschutzverletzung. Anbieterausfälle, Ransomware-Angriffe auf kritische Lieferanten und Single Points of Failure in gemeinsam genutzter Infrastruktur können den Betrieb vollständig unterbrechen. DORAs Mandat zur operativen Resilienz existiert genau deshalb, weil der EU-Finanzsektor erkannt hat, dass Verfügbarkeitsrisiken durch ICT-Drittanbieter ebenso wesentlich sind wie Vertraulichkeitsrisiken.

Konzentrationsrisiko verstärkt dies: Wenn 70 % der Forbes Global 2000-Unternehmen dieselben Top-50-Anbieter nutzen, verbreitet sich eine einzelne Kompromittierung in großem Maßstab. Die Kartierung Ihrer kritischen Anbieterabhängigkeiten und die Pflege dokumentierter Kontinuitätspläne für Tier-1-Lieferantenausfälle ist eine Anforderung von DORA Artikel 28 für Finanzunternehmen.

Europäische und internationale regulatorische Anforderungen für Lieferkettensicherheit

NIS2, DORA und der EU Cyber Resilience Act bilden zusammen den verbindlichen regulatorischen Rahmen für Lieferkettensicherheit auf dem europäischen Markt. NIST CSF 2.0 und SP 800-161 sind US-Frameworks — keine EU-Rechtsverpflichtungen — werden aber von multinationalen Organisationen weitgehend referenziert und bieten operatives Detail, das die EU-Anforderungen ergänzt.

NIS2-Richtlinie (Artikel 21)

NIS2 Artikel 21 verlangt von den betroffenen Einrichtungen die Implementierung von „Sicherheit der Lieferkette, einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen jeder Einrichtung und ihren direkten Lieferanten oder Dienstleistern." Dies ist eine rechtliche Verpflichtung für wesentliche und wichtige Einrichtungen in 18 Sektoren, deren Durchsetzung die EU-Mitgliedstaaten Ende 2024 begonnen haben.

In der Praxis bedeutet Artikel 21, dass Sie die Sicherheitslage Ihrer direkten Anbieter bewerten, Sicherheitsanforderungen in Verträge aufnehmen und einen dokumentierten Prozess für das Management von anbieterbezogenen Vorfällen pflegen müssen. Für das Credential-Management bedeutet dies konkret: keine gemeinsam genutzten Konten, dokumentierte Verfahren für Zugriffsbereitstellung und -entzug sowie Audit-Protokolle, die bei einer Aufsichtsprüfung vorgelegt werden können.

Eine detaillierte Aufschlüsselung, wie NIS2 auf Zugangskontrollanforderungen abbildet, finden Sie im NIS2-Compliance-Leitfaden von Passwork.

DORA (Digital Operational Resilience Act)

DORA gilt für Finanzunternehmen und ihre ICT-Drittanbieter, die in der EU tätig sind. Die Artikel 28 bis 30 etablieren ein detailliertes ICT-Drittanbieter-Risikomanagement-Framework, einschließlich der Anforderungen, ein Register aller ICT-Anbieter zu führen, Risikobewertungen vor dem Onboarding durchzuführen und sicherzustellen, dass Verträge Bestimmungen für Auditrechte und Vorfallsmeldungen enthalten.

DORA führt auch das Konzept der „kritischen ICT-Drittanbieter" (CTPPs) ein, die von den europäischen Aufsichtsbehörden für direkte Überwachung designiert werden können. Wenn Ihre Organisation ein CTPP ist — oder von einem abhängt — ist die Prüfung Ihrer Lieferketten-Sicherheitskontrollen erheblich strenger. Das oben beschriebene Verfügbarkeitsunterbrechungsrisiko ist ebenso ein DORA-Anliegen wie ein Sicherheitsanliegen: Artikel 28 verlangt ausdrücklich dokumentierte Kontinuitätspläne für kritische Drittanbieterabhängigkeiten.

EU Cyber Resilience Act (CRA)

Der CRA wurde 2024 verabschiedet und gilt mit gestaffeltem Zeitplan. Schwachstellen- und Vorfallsmeldepflichten treten ab dem 11. September 2026 in Kraft. Vollständige Produktanforderungen — einschließlich SBOM-Mandate und Konformitätsbewertungen für Produkte mit digitalen Elementen — gelten ab dem 11. Dezember 2027. Organisationen, die vernetzte Hardware oder Software auf dem EU-Markt verkaufen, müssen jetzt mit der Compliance-Arbeit beginnen; die Frist 2027 kommt schneller, als die meisten Produktentwicklungszyklen zulassen.

NIST CSF 2.0 und NIST SP 800-161

NIST CSF 2.0, veröffentlicht im Februar 2024, fügte „Govern" als sechste Kernfunktion hinzu. Die GV.SC-Unterkategorie adressiert explizit das Lieferketten-Risikomanagement und verlangt von Organisationen, C-SCRM in die unternehmensweite Risiko-Governance zu integrieren — es nicht als separates IT-Projekt zu behandeln. Für EU-Organisationen ist CSF 2.0 keine rechtliche Anforderung, bietet aber eine nützliche operationelle Struktur, die gut auf NIS2- und DORA-Verpflichtungen abbildet.

NIST SP 800-161 Rev. 1 liefert das operationelle Detail: wie Lieferantenbewertungen durchzuführen sind, welche Kontrollen in Verträgen verlangt werden sollen und wie ein C-SCRM-Programm über den gesamten Beschaffungslebenszyklus strukturiert werden kann. Für US-Bundesauftragnehmer wird die Ausrichtung an SP 800-161 zunehmend zur Beschaffungsanforderung.

So sichern Sie den Anbieterzugriff: Der technische Bauplan

Die vier wirkungsvollsten Kontrollen für die Sicherheit des Anbieterzugriffs sind RBAC mit Beschränkung auf den Auftrag, Just-in-Time-Zugriff auf privilegierte Ressourcen, zentralisiertes Credential-Vaulting und Phishing-resistente MFA. In dieser Reihenfolge angewendet, adressieren sie die häufigsten Fehlermodi — permanente Berechtigungen, gemeinsam genutzte Konten und Authentifizierungslücken — ohne in den meisten Umgebungen neue Infrastruktur zu erfordern.

Strikte rollenbasierte Zugriffskontrolle (RBAC) durchsetzen

Rollenbasierte Zugriffskontrolle (RBAC) weist Berechtigungen Rollen zu, nicht Einzelpersonen. Ein Support-Ingenieur des Anbieters erhält die Rolle „Nur-Lese-Produktionsüberwachung", nicht ein persönliches Admin-Konto. Wenn der Auftrag endet, entfernen Sie die Rollenzuweisung. Wenn der Anbieter sein Personal wechselt, müssen Sie keine einzelnen Konten verfolgen — die Rolle definiert, worauf zugegriffen werden kann.

Für den Anbieterzugriff sollte RBAC auf das Minimum beschränkt sein, das für den Auftrag erforderlich ist. Ein Datenbankanbieter, der ein Performance-Audit durchführt, benötigt keinen Schreibzugriff auf die Anwendungskonfiguration. Definieren Sie die Rolle vor der Zugriffsbereitstellung, nicht danach.

Just-in-Time (JIT) privilegierten Zugriff implementieren

Just-in-Time (JIT) Zugriff bedeutet, dass privilegierte Anmeldedaten für ein definiertes Zeitfenster ausgestellt und automatisch widerrufen werden, wenn dieses Fenster geschlossen wird. Ein Anbieter-Ingenieur fordert Zugriff für ein zweistündiges Wartungsfenster an; das System gewährt ihn, protokolliert die Sitzung und widerruft ihn nach zwei Stunden, unabhängig davon, ob der Ingenieur daran denkt, sich abzumelden.

JIT-Zugriff eliminiert permanente Berechtigungen: den persistenten, immer aktiven Zugriff, den Angreifer während der durchschnittlich 267 Tage dauernden Verweildauer einer Lieferketten-Sicherheitsverletzung ausnutzen. Es gibt nichts zu stehlen, wenn die Anmeldedaten ablaufen, bevor der Angreifer sie nutzen kann. JIT ist besonders wirksam für Break-Glass-Szenarien: Notfall-Anbieterzugriff während eines Vorfalls, bei dem Geschwindigkeit wichtig ist, aber auch Verantwortlichkeit.

Sicheres Anbieter-Credential-Vaulting

Gemeinsam genutzte Anbieterkonten sind eine Haftung. Die Alternative ist ein Credential-Vault: ein zentralisierter, verschlüsselter Speicher, in dem Anbieter-Anmeldedaten von Ihrer Organisation gehalten werden, nicht vom Anbieter. Der Anbieter authentifiziert sich am Vault, checkt Anmeldedaten für seine Sitzung aus, und der Vault protokolliert jedes Zugriffsereignis.

Dieser Ansatz gibt Ihnen einen vollständigen Audit-Trail darüber, wer wann auf was zugegriffen hat, die Möglichkeit, Anmeldedaten ohne Abstimmung mit dem Anbieter zu rotieren, automatischen Widerruf bei Ende der Anbieterbeziehung und Compliance-Nachweise für die Auditrechtsanforderungen von NIS2 Artikel 21 und DORA Artikel 30.

Passworks Enterprise-Passwort- und Secrets-Manager unterstützt zeitlich begrenztes Credential-Sharing, Sitzungsprotokollierung und Integration mit AD/LDAP- und SSO-Infrastruktur — mit AES-256-Client-seitiger Verschlüsselung und einer vollständigen REST API für die Integration in bestehende Bereitstellungs-Workflows.

Phishing-resistente MFA für Dritte vorschreiben

MFA ist die einzelne Kontrolle mit dem höchsten ROI für den Drittanbieterzugriff. Verizons 2026 DBIR ordnet die Mehrheit der Drittanbieter-Sicherheitsverletzungsszenarien Authentifizierungsfehlern zu — und die meisten dieser Fehler sind fehlende MFA, nicht umgangene MFA.

Für privilegierten Anbieterzugriff auf Produktionssysteme sollte der Standard Phishing-resistente MFA sein: FIDO2/WebAuthn-Hardwareschlüssel oder Passkeys, nicht SMS OTP. SMS-basierte MFA ist anfällig für SIM-Swapping und Echtzeit-Phishing-Proxies. Fordern Sie Phishing-resistente MFA von Anbietern vertraglich als Zugangsbedingung. Nehmen Sie es in Ihren Anbieter-Sicherheitsanhang auf, nicht nur in Ihre interne Richtlinie.

Die meisten der in diesem Leitfaden beschriebenen Zugangskontrollfehler haben dieselbe Ursache: Anbieter-Anmeldedaten, die nie richtig in einem Vault gespeichert, begrenzt oder widerrufen wurden. Passwork adressiert das direkt — zentralisiertes Credential-Vaulting, rollenbasierter Zugriff, zeitlich begrenztes Teilen und ein vollständiger Audit-Trail, der an benannte Identitäten gebunden ist. Verfügbar als Self-hosted oder als Cloud-Bereitstellung, integriert es sich mit AD/LDAP und SAML SSO und ist ISO 27001 zertifiziert.

Aufbau eines Anbieter-Risikobewertungs-Frameworks

Ein Anbieter-Risikobewertungs-Framework klassifiziert Dritte nach Zugangslevel und wendet verhältnismäßige Sicherheitsanforderungen auf jede Stufe an. Das 5-Stufen-Modell unten skaliert von Tier-1-Anbietern mit privilegiertem Produktionszugriff, die vollständige Sicherheitsbewertungen und jährliche Reviews erfordern — bis hin zu Tier-5-Anbietern ohne Daten- oder Systemzugriff, bei denen Standard-Beschaffungs-Due-Diligence ausreicht.

Das 5-Stufen-Anbieter-Risikoklassifizierungsmodell:

Die Klassifizierung bestimmt den verhältnismäßigen Aufwand. Sie benötigen keinen vollständigen Penetrationstestbericht von Ihrem Bürobedarfslieferanten. Von dem MSP mit Admin-Zugriff auf Ihr Active Directory schon.

Checkliste für Anbieterzugangskontrolle

Die folgende Pre-Audit-Checkliste für Anbieterzugriff bildet direkt auf die Anforderungen von NIS2 Artikel 21, DORA Artikel 28 und NIST SP 800-161 ab. Verwenden Sie sie beim Anbieter-Onboarding und bei jeder jährlichen Überprüfung.

Vor der Zugriffsbereitstellung:

•  Anbieter nach Stufe basierend auf Zugangslevel klassifiziert
•  Minimaler notwendiger Zugriffsumfang schriftlich definiert
•  Benannte Personen identifiziert (keine gemeinsam genutzten/generischen Konten)
•  MFA-Anforderung bestätigt und getestet
•  Zugriff über Credential-Vault bereitgestellt, nicht durch direkte Weitergabe von Anmeldedaten
•  Sitzungsprotokollierung aktiviert

Während des Auftrags:

•  Zugriffsumfang überprüft, wenn sich der Auftragsumfang ändert
•  Ungewöhnliche Zugriffsmuster zur Überprüfung gekennzeichnet
•  Anbieter-Vorfallsbenachrichtigungsklausel im Vertrag aktiv

Zugriffsentzug:

•  Offboarding-Auslöser definiert (Vertragsende, Personalwechsel, Vorfall)
•  Anmeldedaten sofort beim Offboarding rotiert
•  Vault-Zugriff widerrufen und Audit-Protokoll exportiert
•  Zugriffsüberprüfung für Compliance-Unterlagen dokumentiert

Fazit: Lieferkettensicherheit operationalisieren

Organisationen, die dies gut handhaben, haben nicht weniger Anbieter; sie haben strengere Kontrollen darüber, wie sich diese Anbieter authentifizieren, worauf sie zugreifen können und für wie lange.

Der technische Bauplan ist klar: Anbieter nach Zugriffsstufe klassifizieren, gemeinsam genutzte Konten eliminieren, Anmeldedaten zentral in einem Vault speichern, JIT-Zugriff für privilegierte Sitzungen durchsetzen und Phishing-resistente MFA verlangen. NIS2, DORA und der CRA bieten die Governance-Struktur und die vertragliche Hebelwirkung, um Anbieter am selben Standard zu messen.

Beginnen Sie mit Ihren Tier-1-Anbietern — denen mit privilegiertem Zugriff auf Produktionssysteme. Prüfen Sie deren aktuellen Zugriffsumfang, bestätigen Sie die Zuweisung einzelner Konten und verifizieren Sie, dass MFA aktiv ist. Dieser einzelne Durchgang wird mehr handlungsfähiges Risiko aufdecken als ein Jahr voller Fragebögen.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Lieferkettensicherheit und Anbieter-Risikomanagement?

Anbieter-Risikomanagement (Vendor Risk Management, VRM) ist die breitere Disziplin, die finanzielle, operative, reputationsbezogene und Cyber-Risiken von Dritten abdeckt. Lieferkettensicherheit ist die cybersicherheitsspezifische Untermenge: der Schutz von Systemen, Daten und Software-Integrität vor Bedrohungen, die über Lieferantenbeziehungen eintreten. VRM informiert Beschaffungsentscheidungen; Lieferkettensicherheit regelt technische Zugriffskontrollen und Software-Integrität.

Welche Vorschriften erfordern Lieferketten-Sicherheitskontrollen in 2025–2026?

NIS2-Richtlinie Artikel 21 verlangt von wesentlichen und wichtigen EU-Einrichtungen, Lieferantensicherheitsrisiken zu bewerten und zu managen. DORA Artikel 28–30 erlegt EU-Finanzunternehmen ICT-Drittanbieter-Risikomanagement-Verpflichtungen auf. Der EU Cyber Resilience Act verlangt Schwachstellenmeldungen ab September 2026 und vollständige SBOM- und Konformitätsanforderungen ab Dezember 2027. In den USA setzen NIST SP 800-161 und Executive Order 14028 C-SCRM-Erwartungen für Bundesauftragnehmer.

Was ist Just-in-Time (JIT) Zugriff und warum ist er für Anbietersicherheit wichtig?

JIT-Zugriff stellt privilegierte Anmeldedaten für ein definiertes Zeitfenster aus und widerruft sie automatisch, wenn dieses Fenster geschlossen wird. Er eliminiert permanente Berechtigungen — persistenten Zugriff, den Angreifer während der für Lieferketten-Sicherheitsverletzungen typischen verlängerten Verweildauer ausnutzen. IBMs Daten von 2025 zeigen, dass Lieferkettenkompromittierungen durchschnittlich 267 Tage benötigen, um identifiziert und eingedämmt zu werden; JIT-Zugriff reduziert das ausnutzbare Fenster auf Stunden, nicht Monate.

Wie reduzieren SBOMs das Lieferkettenrisiko?

Eine Software Bill of Materials (SBOM) ist ein maschinenlesbares Inventar aller Softwarekomponenten und ihrer Versionen. Wenn eine neue Schwachstelle offengelegt wird — wie Log4Shell 2021 — ermöglicht Ihnen eine SBOM, innerhalb von Minuten festzustellen, ob eines Ihrer Systeme oder eine vom Anbieter bereitgestellte Software die betroffene Komponente enthält. Ohne SBOM kann dieselbe Feststellung Tage oder Wochen dauern, während derer die Schwachstelle ungepatcht und ausnutzbar bleibt.

Was sollte ein Anbieter-Sicherheitsvertragsanhang enthalten?

Mindestens: eine Anforderung für benannte einzelne Konten (keine gemeinsam genutzten Anmeldedaten), Phishing-resistente MFA für privilegierten Zugriff, Benachrichtigungspflichten innerhalb von 24–72 Stunden nach einem Sicherheitsvorfall, Auditrechte, die Ihrer Organisation die Überprüfung von Zugriffsprotokollen ermöglichen, und ein definierter Offboarding-Prozess einschließlich Credential-Rotation. NIS2 Artikel 21 und DORA Artikel 30 verlangen beide vertragliche Sicherheitsbestimmungen — der Anhang ist Ihr Compliance-Nachweis.

Wie sollten Organisationen Anbieter für Risikobewertungszwecke klassifizieren?

Klassifizieren Sie nach Zugangslevel, nicht nach Vertragswert oder Anbietergröße. Ein kleines Beratungsunternehmen mit Admin-Zugriff auf Ihre Produktionsumgebung ist risikoreicher als ein großer Softwareanbieter ohne direkten Systemzugriff. Das oben dargestellte 5-Stufen-Anbieter-Risikoklassifizierungsmodell bietet eine praktische Struktur: Tier 1 (privilegierter Produktionszugriff) bis Tier 5 (kein Daten- oder Systemzugriff), mit entsprechend skalierten Bewertungsanforderungen und Überprüfungshäufigkeiten.

Was ist der häufigste Zugangskontrollfehler bei Drittanbieter-Sicherheitsverletzungen?

Gemeinsam genutzte Anmeldedaten ohne individuelle Verantwortlichkeit. Ein einzelner Satz Anmeldedaten, der einem Anbieterteam ausgestellt, außerhalb eines Vaults gespeichert, nie rotiert und nie widerrufen wird, wenn der Auftrag endet. Verizons 2026 DBIR identifiziert Authentifizierungsfehler als den primären Mechanismus bei Drittanbieter-Sicherheitsverletzungsszenarien. Die Lösung sind einzelne benannte Konten, Credential-Vaulting und ein dokumentierter Offboarding-Prozess — nicht komplexere Technologie.

Was ist Hardware-Lieferkettenrisiko und wie unterscheidet es sich vom Software-Lieferkettenrisiko?

Hardware-Lieferkettenrisiko umfasst gefälschte oder manipulierte physische Komponenten — Netzwerkausrüstung, Server-Hardware, Firmware — die persistente Hintertüren einführen können, die für Software-Layer-Sicherheitskontrollen unsichtbar sind. Im Gegensatz zu Software-Schwachstellen überlebt Hardware-Manipulation eine Betriebssystem-Neuinstallation. Der EU Cyber Resilience Act adressiert dies direkt und verlangt von Herstellern, die Lieferkettensicherheit für Hardwareprodukte mit digitalen Elementen zu dokumentieren.

Einblick in reale Lieferkettenangriffe: Bitwarden CLI, Axios und Vercel

Warum Ihr Netzwerk kompromittieren, wenn Angreifer eine vertrauenswürdige Abhängigkeit mit Millionen von Downloads kompromittieren und sich lautlos in Tausende von Organisationen gleichzeitig einschleichen können? Drei Kampagnen aus 2026 beweisen, dass Lieferkettenangriffe keine Einzelfälle mehr sind.

Passwork BlogAlex Muntyan

Shadow IT vs. Shadow AI: Warum KI die größere Bedrohung ist

Mitarbeiter nutzen KI-Tools, die Sie nicht genehmigt haben, auf Konten, die Sie nicht überwachen können, mit Daten, die Sie nicht wiederherstellen können. Hier erfahren Sie, wie das Risiko tatsächlich aussieht und was die Governance adressieren muss.

Passwork BlogAlex Muntyan

NIS2-Zugriffskontrollen für Lieferkettensicherheit

48 % der Sicherheitsverletzungen betreffen jetzt Dritte. NIS2 Artikel 21 macht die Lieferanten-Zugriffs-Governance zur gesetzlichen Pflicht. Hier erfahren Sie, wie Sie den Anbieterzugriff kartieren, MFA und Least Privilege durchsetzen und die Audit-Nachweise aufbewahren, die beweisen, dass Ihre Kontrollen funktionieren.

Passwork BlogAlex Muntyan

Hace unos años, el consejo estándar era simple: evalúe a sus proveedores, firme un NDA, realice un cuestionario anual. Entonces ocurrió SolarWinds, luego MOVEit, luego XZ Utils — una puerta trasera plantada durante dos años de contribuciones legítimas a código abierto, detectada por un ingeniero que notó un proceso ejecutándose 500ms más lento de lo debido. Todos esos ataques entraron a través de una relación de confianza.

El patrón se mantiene en cada incidente importante. La participación de terceros ahora representa el 48% de todas las filtraciones de datos (frente al 30% del año anterior) según el DBIR 2026 de Verizon, y el compromiso promedio de la cadena de suministro cuesta 4,91 millones de dólares y tarda 267 días en contenerse, según el informe Cost of a Data Breach 2025 de IBM. 

La mayoría de las organizaciones todavía responden con cuestionarios y auditorías anuales. Estos tienen su lugar. Pero un cuestionario no detiene una filtración. Revocar los privilegios permanentes de un proveedor sí lo hace. Esta guía trata la seguridad de la cadena de suministro como lo que realmente es: un problema de IAM y control de credenciales, con una capa de cumplimiento normativo encima.

Puntos clave

• La participación de terceros ahora representa el 48% de todas las filtraciones de datos — frente al 30% del año anterior, según el DBIR 2026 de Verizon. Los ataques a la cadena de suministro son el vector de filtración dominante.
• El compromiso promedio de la cadena de suministro cuesta 4,91 millones de dólares y tarda 267 días en contenerse. Ese tiempo de permanencia es lo que hace tan peligrosos los privilegios permanentes de los proveedores — los atacantes no necesitan moverse rápido si las credenciales nunca expiran.
• Todos los incidentes importantes de cadena de suministro entraron a través de una relación de confianza. SolarWinds, MOVEit, XZ Utils — en cada caso, el atacante utilizó acceso que ya estaba aprovisionado y ya era de confianza.
• Los cuestionarios y las auditorías anuales no detienen las filtraciones. Revocar los privilegios permanentes de los proveedores sí lo hace. Los controles que importan son técnicos: almacenamiento de credenciales en bóvedas, acceso JIT, RBAC limitado al alcance del compromiso y MFA resistente al phishing.
• NIS2, DORA y la Ley de Ciberresiliencia de la UE convierten la seguridad de la cadena de suministro en una obligación legal. El artículo 21 de NIS2, los artículos 28-30 de DORA y los requisitos de la CRA se aplican en un calendario escalonado hasta 2027.
• El 70% de los 50 principales proveedores compartidos por las empresas del Global 2000 tienen al menos una vulnerabilidad KEV sin parchear, según el informe Third-Party Breach Report 2026 de Black Kite.

¿Qué es la gestión de riesgos de la cadena de suministro cibernética (C-SCRM)?

La gestión de riesgos de la cadena de suministro cibernética (C-SCRM) es la disciplina de identificar, evaluar y mitigar los riesgos de ciberseguridad que se originan en la red extendida de proveedores, vendedores, prestadores de servicios y dependencias de software de una organización. Abarca todo, desde las herramientas SaaS que usan los desarrolladores hasta el proveedor de servicios gestionados (MSP) con acceso de administrador a su entorno de producción.

C-SCRM se sitúa en la intersección de adquisiciones, seguridad de TI y cumplimiento normativo. NIST SP 800-161 Rev. 1 proporciona el marco federal más detallado para ello, definiendo C-SCRM como un proceso estructurado para gestionar la exposición a riesgos de ciberseguridad a lo largo del ciclo de vida de la cadena de suministro — desde la selección inicial del proveedor hasta la terminación del contrato y la revocación del acceso.

El alcance es más amplio de lo que la mayoría de los equipos imaginan. Su cadena de suministro incluye:

• Proveedores de software y dependencias de código abierto
• Infraestructura en la nube y proveedores SaaS
• Proveedores de servicios gestionados y soporte de TI
• Fabricantes de hardware y proveedores de firmware
• Empresas de servicios profesionales con acceso a la red o los datos

Cada uno de estos es un punto de entrada potencial. Los incidentes de SolarWinds, MOVEit y XZ Utils explotaron ese punto de entrada de diferentes maneras.

El estado de los ataques a la cadena de suministro en 2025–2026

Los ataques a la cadena de suministro alcanzaron niveles récord en 2025–2026. El DBIR 2026 de Verizon registró la participación de terceros en el 48% de todas las filtraciones analizadas — el más alto en la historia del informe y un aumento del 60% respecto al 30% del año anterior. El informe Cost of a Data Breach 2025 de IBM sitúa el compromiso promedio de la cadena de suministro en 4,91 millones de dólares, con un ciclo de vida promedio de 267 días desde la detección hasta la contención.

Los actores de amenazas han aprendido que comprometer a un proveedor de confianza proporciona acceso a docenas o cientos de organizaciones posteriores simultáneamente. La economía favorece al atacante: una intrusión exitosa, multiplicada por toda la base de clientes de un proveedor.

Según el informe Third-Party Breach Report 2026 de Black Kite, el 70% de los 50 principales proveedores compartidos por las empresas del Global 2000 tienen al menos una vulnerabilidad sin parchear del catálogo de Vulnerabilidades Explotadas Conocidas (KEV) de CISA. Estos no son riesgos teóricos — CISA marca las entradas KEV específicamente porque están siendo explotadas activamente.

Lecciones de SolarWinds, MOVEit y XZ Utils

Los tres incidentes comparten un hilo común: el vector de acceso inicial era de confianza. Software de confianza, proveedor de confianza, colaborador de confianza. Una vez dentro, el atacante se movió lateralmente utilizando credenciales y acceso que ya estaban aprovisionados.

SolarWinds (2020)

Los atacantes comprometieron directamente el pipeline de compilación, insertando una puerta trasera en una actualización de software firmada que se distribuyó a los clientes como un parche rutinario. Aproximadamente 18.000 organizaciones la instalaron. Las consecuencias legales se prolongaron durante años: la SEC presentó una acción de cumplimiento civil contra SolarWinds y su CISO en octubre de 2023, y el caso finalmente se desestimó por completo en 2025.

La lección: los controles de integridad del software y la visibilidad del SBOM (Software Bill of Materials) importan tanto como los controles del perímetro de red — y la exposición a responsabilidad por un compromiso del pipeline de compilación se extiende mucho más allá de la filtración inicial.

MOVEit (2023)

Una vulnerabilidad de inyección SQL de día cero (CVE-2023-34362) en un producto de transferencia de archivos gestionada dio al grupo de ransomware Cl0p acceso a datos de más de 2.700 organizaciones — muchas de las cuales no tenían relación directa con MOVEit pero se vieron afectadas por el uso que sus proveedores hacían de él. El recuento final de víctimas alcanzó aproximadamente 95 millones de personas. 

La lección: su superficie de ataque incluye el software que ejecutan sus proveedores, no solo el software que ejecuta usted.

XZ Utils (2024)

Una campaña de ingeniería social de varios años insertó una puerta trasera en una biblioteca de compresión de código abierto ampliamente utilizada. El atacante contribuyó código legítimo durante dos años antes de introducir la carga maliciosa — y la puerta trasera fue detectada no por ningún proceso de seguridad formal, sino por un ingeniero de Microsoft que notó un retraso de 500ms en los inicios de sesión SSH. 

La lección: el riesgo de dependencias de código abierto es real, los SBOMs son la única forma sistemática de rastrearlo, y sus controles de detección necesitan cubrir el comportamiento, no solo las firmas.

Principales riesgos de proveedores en la cadena de suministro moderna

Las cinco categorías de riesgo de cadena de suministro más comunes son:

• Credenciales compartidas y control de acceso deficiente
• Vulnerabilidades en dependencias de software
• Manipulación de hardware y componentes
• Shadow AI y exposición de datos de terceros
• Riesgo de concentración de proveedores

Cada una requiere una respuesta de control distinta. Los fallos de credenciales compartidas son un problema de proceso. La manipulación de hardware requiere verificación de procedencia física.

Credenciales compartidas y control de acceso deficiente

El riesgo de cadena de suministro más común y más prevenible es también el menos glamuroso: cuentas compartidas. Un equipo de soporte de proveedor obtiene un único conjunto de credenciales para acceder a su entorno. Esas credenciales se comparten entre el personal del proveedor, se almacenan en una hoja de cálculo o hilo de correo electrónico, y nunca se rotan después de que termina el compromiso.

Cuando ese proveedor es vulnerado, o cuando un empleado descontento se va, no hay forma de saber quién usó esas credenciales, cuándo o a qué accedió. No hay rastro de auditoría. No hay forma de revocar el acceso de un individuo sin cambiar las credenciales para todos.

El DBIR 2026 de Verizon identifica los fallos de autenticación (MFA ausente o eludida, credenciales robadas) como el mecanismo principal en los escenarios de filtración de terceros. Este es un fallo de proceso.

Vulnerabilidades en la cadena de suministro de software y la necesidad de SBOMs

Un Software Bill of Materials (SBOM) es un inventario legible por máquina de cada componente en un producto de software: bibliotecas, dependencias, versiones y sus vulnerabilidades conocidas. La Orden Ejecutiva 14028 de EE.UU. (2021) exigió SBOMs para el software vendido a agencias federales. La Ley de Ciberresiliencia (CRA) de la UE extiende requisitos similares a los productos vendidos en el mercado europeo, con obligaciones de notificación de vulnerabilidades aplicables desde septiembre de 2026 y requisitos completos de producto desde diciembre de 2027.

Sin un SBOM, no puede responder «¿Estamos ejecutando la versión vulnerable de Log4j?» en menos de 24 horas. Con uno, sí puede. Esa diferencia de velocidad es la brecha entre un incidente contenido y una filtración que tarda 267 días en cerrarse.

Manipulación de hardware y componentes

El riesgo de la cadena de suministro de hardware es distinto del riesgo de software y a menudo se subestima. Los componentes falsificados o manipulados — equipos de red, hardware de servidor, firmware — pueden introducir puertas traseras persistentes que sobreviven a la reinstalación del sistema operativo y son invisibles para los controles de seguridad de la capa de software.

La Ley de Ciberresiliencia de la UE aborda explícitamente los productos de hardware con elementos digitales, exigiendo a los fabricantes que evalúen y documenten la seguridad de la cadena de suministro para los componentes físicos. Para las organizaciones que adquieren infraestructura de red o sistemas de control industrial, esto significa verificar la procedencia de los componentes, exigir atestación de integridad del firmware a los proveedores y mantener un inventario de versiones de hardware equivalente a un SBOM de software.

Shadow AI y exposición de datos de terceros

El DBIR 2026 de Verizon identifica shadow AI como uno de los tres principales comportamientos internos — empleados que utilizan herramientas de IA no autorizadas que procesan datos organizacionales fuera de los canales aprobados. El ángulo de la cadena de suministro: muchas de estas herramientas son productos SaaS de terceros con sus propias políticas de retención de datos, acuerdos de subprocesadores y posturas de seguridad que su organización nunca revisó.

Cuando un desarrollador pega credenciales de base de datos en un asistente de IA para depurar una consulta, esas credenciales pueden ser retenidas, registradas o utilizadas para el entrenamiento del modelo. El riesgo del proveedor no es solo el proveedor de IA — es cada subprocesador en su cadena.

Interrupciones de disponibilidad y riesgo de concentración de proveedores

Un fallo de seguridad de la cadena de suministro no siempre significa una filtración de datos. Las interrupciones de proveedores, los ataques de ransomware a proveedores críticos y los puntos únicos de fallo en la infraestructura compartida pueden interrumpir las operaciones por completo. El mandato de resiliencia operativa de DORA existe precisamente porque el sector financiero de la UE reconoció que el riesgo de disponibilidad de terceros de TIC es tan material como el riesgo de confidencialidad.

El riesgo de concentración agrava esto: cuando el 70% de las empresas del Forbes Global 2000 comparten los mismos 50 principales proveedores, un único compromiso se propaga a escala. Mapear las dependencias de proveedores críticos y mantener planes de continuidad documentados para fallos de proveedores de Nivel 1 es un requisito del artículo 28 de DORA para las entidades financieras.

Requisitos regulatorios europeos e internacionales para la seguridad de la cadena de suministro

NIS2, DORA y la Ley de Ciberresiliencia de la UE forman juntos el marco regulatorio vinculante para la seguridad de la cadena de suministro en el mercado europeo. NIST CSF 2.0 y SP 800-161 son marcos estadounidenses — no obligaciones legales de la UE — pero son ampliamente referenciados por organizaciones multinacionales y proporcionan detalle operativo que complementa los requisitos de la UE.

Directiva NIS2 (Artículo 21)

El artículo 21 de NIS2 exige a las entidades cubiertas implementar «seguridad de la cadena de suministro, incluidos los aspectos relacionados con la seguridad en las relaciones entre cada entidad y sus proveedores directos o prestadores de servicios». Esta es una obligación legal para las entidades esenciales e importantes en 18 sectores, con una aplicación que los estados miembros de la UE comenzaron a implementar a finales de 2024.

En la práctica, el artículo 21 significa que debe evaluar la postura de seguridad de sus proveedores directos, incluir requisitos de seguridad en los contratos y mantener un proceso documentado para gestionar incidentes relacionados con proveedores. Para la gestión de credenciales específicamente, esto se traduce en: sin cuentas compartidas, procedimientos documentados de aprovisionamiento y revocación de acceso, y registros de auditoría que puedan presentarse durante una revisión de supervisión.

Para un desglose detallado de cómo NIS2 se relaciona con los requisitos de control de acceso, consulte la guía de cumplimiento de NIS2 de Passwork.

DORA (Ley de Resiliencia Operativa Digital)

DORA se aplica a las entidades financieras y sus proveedores de servicios de TIC terceros que operan en la UE. Los artículos 28 a 30 establecen un marco detallado de gestión de riesgos de TIC de terceros, incluyendo requisitos para mantener un registro de todos los proveedores de TIC, realizar evaluaciones de riesgo antes de la incorporación y garantizar que los contratos incluyan disposiciones para derechos de auditoría y notificación de incidentes.

DORA también introduce el concepto de «proveedores de TIC terceros críticos» (CTPPs), que las Autoridades Europeas de Supervisión pueden designar para supervisión directa. Si su organización es un CTPP — o depende de uno — el escrutinio sobre sus controles de seguridad de la cadena de suministro es sustancialmente mayor. El riesgo de interrupción de disponibilidad descrito anteriormente es una preocupación de DORA tanto como de seguridad: el artículo 28 exige explícitamente planes de continuidad documentados para dependencias de terceros críticos.

Ley de Ciberresiliencia de la UE (CRA)

La CRA fue adoptada en 2024 y se aplica en un calendario escalonado. Las obligaciones de notificación de vulnerabilidades e incidentes entran en vigor a partir del 11 de septiembre de 2026. Los requisitos completos de producto — incluyendo mandatos de SBOM y evaluaciones de conformidad para productos con elementos digitales — se aplican a partir del 11 de diciembre de 2027. Las organizaciones que venden hardware o software conectado en el mercado de la UE deben comenzar el trabajo de cumplimiento ahora; el plazo de 2027 llega más rápido de lo que permiten la mayoría de los ciclos de desarrollo de productos.

NIST CSF 2.0 y NIST SP 800-161

NIST CSF 2.0, publicado en febrero de 2024, añadió «Gobernar» como una sexta función central. La subcategoría GV.SC aborda explícitamente la gestión de riesgos de la cadena de suministro, exigiendo a las organizaciones integrar C-SCRM en la gobernanza de riesgos empresariales — no tratarlo como un proyecto de TI separado. Para las organizaciones de la UE, CSF 2.0 no es un requisito legal pero proporciona una estructura operativa útil que se corresponde bien con las obligaciones de NIS2 y DORA.

NIST SP 800-161 Rev. 1 proporciona el detalle operativo: cómo realizar evaluaciones de proveedores, qué controles exigir en los contratos y cómo estructurar un programa C-SCRM a lo largo de todo el ciclo de vida de adquisición. Para los contratistas federales de EE.UU., la alineación con SP 800-161 es cada vez más un requisito de adquisiciones.

Cómo asegurar el acceso de proveedores: El modelo técnico

Los cuatro controles de mayor impacto para la seguridad del acceso de proveedores son RBAC limitado al alcance del compromiso, acceso privilegiado justo a tiempo, almacenamiento centralizado de credenciales en bóveda y MFA resistente al phishing. Aplicados en ese orden, abordan los modos de fallo más comunes — privilegios permanentes, cuentas compartidas y brechas de autenticación — sin requerir nueva infraestructura en la mayoría de los entornos.

Aplique un control de acceso basado en roles (RBAC) estricto

El control de acceso basado en roles (RBAC) asigna permisos a roles, no a individuos. Un ingeniero de soporte del proveedor obtiene el rol de «monitoreo de producción de solo lectura», no una cuenta de administrador personal. Cuando termina el compromiso, se elimina la asignación del rol. Cuando el proveedor rota su personal, no necesita rastrear cuentas individuales — el rol define lo que es accesible.

Para el acceso de proveedores específicamente, RBAC debe estar limitado al mínimo requerido para el compromiso. Un proveedor de base de datos que realiza una auditoría de rendimiento no necesita acceso de escritura a la configuración de la aplicación. Defina el rol antes de aprovisionar el acceso, no después.

Implemente acceso privilegiado justo a tiempo (JIT)

El acceso justo a tiempo (JIT) significa que las credenciales privilegiadas se emiten para una ventana de tiempo definida y se revocan automáticamente cuando esa ventana se cierra. Un ingeniero del proveedor solicita acceso para una ventana de mantenimiento de dos horas; el sistema lo concede, registra la sesión y lo revoca a las dos horas independientemente de si el ingeniero recuerda cerrar sesión.

El acceso JIT elimina los privilegios permanentes: el acceso persistente y siempre activo que los atacantes explotan durante el tiempo de permanencia promedio de 267 días de una filtración de cadena de suministro. No hay nada que robar si las credenciales expiran antes de que el atacante pueda usarlas. JIT es particularmente efectivo para escenarios de emergencia: acceso de proveedor de emergencia durante un incidente, donde la velocidad importa pero también la responsabilidad.

Almacenamiento seguro de credenciales de proveedores en bóveda

Las cuentas de proveedor compartidas son una responsabilidad. La alternativa es una bóveda de credenciales: un almacén centralizado y cifrado donde las credenciales del proveedor son mantenidas por su organización, no por el proveedor. El proveedor se autentica en la bóveda, retira las credenciales para su sesión, y la bóveda registra cada evento de acceso.

Este enfoque le proporciona un rastro de auditoría completo de quién accedió a qué y cuándo, la capacidad de rotar credenciales sin coordinarse con el proveedor, revocación automática cuando termina la relación con el proveedor, y evidencia de cumplimiento para los requisitos de derechos de auditoría del artículo 21 de NIS2 y el artículo 30 de DORA.

El gestor empresarial de contraseñas y secretos de Passwork soporta compartición de credenciales con tiempo limitado, registro de sesiones e integración con infraestructura AD/LDAP y SSO — con cifrado AES-256 del lado del cliente y una REST API completa para integración en flujos de trabajo de aprovisionamiento existentes.

Exija MFA resistente al phishing para terceros

MFA es el control con mayor retorno de inversión para el acceso de terceros. El DBIR 2026 de Verizon atribuye la mayoría de los escenarios de filtración de terceros a fallos de autenticación — y la mayoría de esos fallos son MFA ausente, no MFA eludida.

Para el acceso privilegiado de proveedores a sistemas de producción, el estándar debe ser MFA resistente al phishing: llaves de hardware FIDO2/WebAuthn o passkeys, no OTP por SMS. MFA basada en SMS es vulnerable al intercambio de SIM y proxies de phishing en tiempo real. Exija contractualmente MFA resistente al phishing a los proveedores como condición de acceso. Inclúyalo en su anexo de seguridad del proveedor, no solo en su política interna.

La mayoría de los fallos de control de acceso descritos en esta guía se remontan a la misma causa raíz: credenciales de proveedor que nunca se almacenaron correctamente en bóveda, no se limitaron en alcance o no se revocaron. Passwork aborda eso directamente — almacenamiento centralizado de credenciales en bóveda, acceso basado en roles, compartición con tiempo limitado y un registro de auditoría completo vinculado a identidades nominativas. Disponible autoalojado o como despliegue en la nube, se integra con AD/LDAP y SAML SSO y tiene certificación ISO 27001.

Construyendo un marco de evaluación de riesgos de proveedores

Un marco de evaluación de riesgos de proveedores clasifica a los terceros por nivel de acceso y aplica requisitos de seguridad proporcionales a cada nivel. El modelo de 5 niveles a continuación escala desde proveedores de Nivel 1 con acceso privilegiado a producción, que requieren evaluaciones de seguridad completas y revisiones anuales — hasta proveedores de Nivel 5 sin acceso a datos o sistemas, donde la debida diligencia de adquisiciones estándar es suficiente.

El modelo de clasificación de riesgos de proveedores de 5 niveles:

La clasificación impulsa un esfuerzo proporcional. No necesita un informe de prueba de penetración completo de su proveedor de suministros de oficina. Sí lo necesita del MSP con acceso de administrador a su Active Directory.

Lista de verificación de control de acceso de proveedores

La siguiente lista de verificación de acceso de proveedores previa a la auditoría se corresponde directamente con los requisitos del artículo 21 de NIS2, el artículo 28 de DORA y NIST SP 800-161. Úsela en la incorporación de proveedores y en cada revisión anual.

Antes del aprovisionamiento de acceso:

•  Proveedor clasificado por nivel según el nivel de acceso
•  Alcance de acceso mínimo necesario definido por escrito
•  Individuos identificados por nombre (sin cuentas compartidas/genéricas)
•  Requisito de MFA confirmado y probado
•  Acceso aprovisionado a través de bóveda de credenciales, no compartición directa de credenciales
•  Registro de sesiones habilitado

Durante el compromiso:

•  Alcance de acceso revisado si el alcance del compromiso cambia
•  Patrones de acceso inusuales marcados para revisión
•  Cláusula de notificación de incidentes del proveedor activa en el contrato

Revocación de acceso:

•  Disparador de desvinculación definido (fin de contrato, cambio de personal, incidente)
•  Credenciales rotadas inmediatamente en la desvinculación
•  Acceso a la bóveda revocado y registro de auditoría exportado
•  Revisión de acceso documentada para registros de cumplimiento

Conclusión: Hacer operativa la seguridad de la cadena de suministro

Las organizaciones que gestionan esto bien no tienen menos proveedores; tienen controles más estrictos sobre cómo se autentican esos proveedores, a qué pueden acceder y durante cuánto tiempo.

El modelo técnico es claro: clasifique a los proveedores por nivel de acceso, elimine las cuentas compartidas, almacene las credenciales centralmente en bóveda, aplique acceso JIT para sesiones privilegiadas y exija MFA resistente al phishing. NIS2, DORA y la CRA proporcionan la estructura de gobernanza y el apalancamiento contractual para exigir a los proveedores el mismo estándar.

Comience con sus proveedores de Nivel 1 — los que tienen acceso privilegiado a sistemas de producción. Audite su alcance de acceso actual, confirme la asignación de cuentas individuales y verifique que MFA esté activo. Ese único pase revelará más riesgo accionable que un año de cuestionarios.

Preguntas frecuentes

¿Cuál es la diferencia entre seguridad de la cadena de suministro y gestión de riesgos de proveedores?

La gestión de riesgos de proveedores (VRM) es la disciplina más amplia que cubre riesgos financieros, operacionales, reputacionales y cibernéticos de terceros. La seguridad de la cadena de suministro es el subconjunto específico de ciberseguridad: proteger sistemas, datos e integridad del software de amenazas que entran a través de relaciones con proveedores. VRM informa las decisiones de adquisición; la seguridad de la cadena de suministro gobierna los controles técnicos de acceso y la integridad del software.

¿Qué regulaciones requieren controles de seguridad de la cadena de suministro en 2025–2026?

El artículo 21 de la Directiva NIS2 exige a las entidades esenciales e importantes de la UE evaluar y gestionar los riesgos de seguridad de los proveedores. Los artículos 28–30 de DORA imponen obligaciones de gestión de riesgos de TIC de terceros a las entidades financieras de la UE. La Ley de Ciberresiliencia de la UE exige la notificación de vulnerabilidades desde septiembre de 2026 y requisitos completos de SBOM y conformidad desde diciembre de 2027. En EE.UU., NIST SP 800-161 y la Orden Ejecutiva 14028 establecen expectativas de C-SCRM para contratistas federales.

¿Qué es el acceso justo a tiempo (JIT) y por qué importa para la seguridad de proveedores?

El acceso JIT emite credenciales privilegiadas para una ventana de tiempo definida y las revoca automáticamente cuando esa ventana se cierra. Elimina los privilegios permanentes — acceso persistente que los atacantes explotan durante el tiempo de permanencia extendido típico de las filtraciones de cadena de suministro. Los datos de IBM de 2025 muestran que los compromisos de cadena de suministro tardan en promedio 267 días en identificarse y contenerse; el acceso JIT reduce la ventana explotable a horas, no meses.

¿Cómo reducen los SBOMs el riesgo de la cadena de suministro?

Un Software Bill of Materials (SBOM) es un inventario legible por máquina de todos los componentes de software y sus versiones. Cuando se divulga una nueva vulnerabilidad — como Log4Shell en 2021 — un SBOM le permite determinar en minutos si alguno de sus sistemas o software suministrado por proveedores contiene el componente afectado. Sin un SBOM, esa misma determinación puede llevar días o semanas, durante las cuales la vulnerabilidad permanece sin parchear y explotable.

¿Qué debe incluir un anexo de seguridad del contrato con el proveedor?

Como mínimo: un requisito de cuentas individuales nominativas (sin credenciales compartidas), MFA resistente al phishing para acceso privilegiado, obligaciones de notificación dentro de 24–72 horas de un incidente de seguridad, derechos de auditoría que permitan a su organización revisar los registros de acceso, y un proceso de desvinculación definido que incluya rotación de credenciales. Tanto el artículo 21 de NIS2 como el artículo 30 de DORA requieren disposiciones de seguridad contractuales — el anexo es su evidencia de cumplimiento.

¿Cómo deben las organizaciones clasificar a los proveedores para propósitos de evaluación de riesgos?

Clasifique por nivel de acceso, no por valor del contrato o tamaño del proveedor. Una pequeña consultoría con acceso de administrador a su entorno de producción es de mayor riesgo que un gran proveedor de software sin acceso directo al sistema. El modelo de clasificación de riesgos de proveedores de 5 niveles anterior proporciona una estructura práctica: Nivel 1 (acceso privilegiado a producción) hasta Nivel 5 (sin acceso a datos o sistemas), con requisitos de evaluación y frecuencia de revisión escalados en consecuencia.

¿Cuál es el fallo de control de acceso más común en las filtraciones de terceros?

Credenciales compartidas sin responsabilidad individual. Un único conjunto de credenciales emitido a un equipo de proveedor, almacenado fuera de una bóveda, nunca rotado, y nunca revocado cuando termina el compromiso. El DBIR 2026 de Verizon identifica los fallos de autenticación como el mecanismo principal en escenarios de filtración de terceros. La solución son cuentas individuales nominativas, almacenamiento de credenciales en bóveda y un proceso de desvinculación documentado — no tecnología más compleja.

¿Qué es el riesgo de la cadena de suministro de hardware y cómo se diferencia del riesgo de la cadena de suministro de software?

El riesgo de la cadena de suministro de hardware involucra componentes físicos falsificados o manipulados — equipos de red, hardware de servidor, firmware — que pueden introducir puertas traseras persistentes invisibles para los controles de seguridad de la capa de software. A diferencia de las vulnerabilidades de software, la manipulación de hardware sobrevive a la reinstalación del sistema operativo. La Ley de Ciberresiliencia de la UE aborda esto directamente, exigiendo a los fabricantes documentar la seguridad de la cadena de suministro para productos de hardware con elementos digitales.

Dentro de ataques reales a la cadena de suministro: Bitwarden CLI, Axios y Vercel

¿Por qué vulnerar su red cuando los atacantes pueden comprometer una dependencia de confianza con millones de descargas y deslizarse silenciosamente en miles de organizaciones a la vez? Tres campañas de 2026 demuestran que los ataques a la cadena de suministro ya no son incidentes aislados.

Passwork BlogAlex Muntyan

Shadow IT vs Shadow AI: Por qué la IA es la mayor amenaza

Los empleados están usando herramientas de IA que usted no aprobó, en cuentas que no puede monitorear, con datos que no puede recuperar. Así es como realmente se ve el riesgo y qué debe abordar la gobernanza.

Passwork BlogAlex Muntyan

Controles de acceso NIS2 para seguridad de la cadena de suministro

El 48% de las filtraciones ahora involucran a terceros. El artículo 21 de NIS2 convierte la gobernanza del acceso de proveedores en una obligación legal. Así es cómo mapear el acceso de proveedores, aplicar MFA y privilegio mínimo, y mantener la evidencia de auditoría que demuestra que sus controles funcionan.

Passwork BlogAlex Muntyan

A few years ago, the standard advice was simple: vet your vendors, sign an NDA, run an annual questionnaire. Then SolarWinds happened, then MOVEit, then XZ Utils — a backdoor planted over two years of legitimate open-source contributions, caught by an engineer who noticed a process running 500ms slower than it should. Every one of those attacks entered through a trusted relationship.

The pattern holds across every major incident. Third-party involvement now accounts for 48% of all data breaches (up from 30% the previous year) according to Verizon's 2026 DBIR, and the average supply chain compromise costs $4.91 million and takes 267 days to contain, per IBM's 2025 Cost of a Data Breach Report. 

Most organizations still respond with questionnaires and annual audits. Those have their place. But a questionnaire doesn't stop a breach. Revoking a vendor's standing privileges does. This guide treats supply chain security as what it actually is: an IAM and credential control problem, with a compliance layer on top.

Key takeaways

• Third-party involvement now accounts for 48% of all data breaches — up from 30% the previous year, according to Verizon's 2026 DBIR. Supply chain attacks are the dominant breach vector.
• The average supply chain compromise costs $4.91 million and takes 267 days to contain. That dwell time is what makes standing vendor privileges so dangerous — attackers don't need to move fast if the credentials never expire.
• Every major supply chain incident entered through a trusted relationship. SolarWinds, MOVEit, XZ Utils — in each case, the attacker used access that was already provisioned and already trusted.
• Questionnaires and annual audits don't stop breaches. Revoking standing vendor privileges does. The controls that matter are technical: credential vaulting, JIT access, RBAC scoped to the engagement, and phishing-resistant MFA.
• NIS2, DORA, and the EU Cyber Resilience Act make supply chain security a legal obligation. NIS2 Article 21, DORA Articles 28–30, and CRA requirements apply on a staggered timeline through 2027.
• 70% of the top 50 vendors shared by Global 2000 companies carry at least one unpatched KEV vulnerability, per Black Kite's 2026 Third-Party Breach Report.

What is cyber supply chain risk management (C-SCRM)?

Cyber Supply Chain Risk Management (C-SCRM) is the discipline of identifying, assessing, and mitigating cybersecurity risks that originate from an organization's extended network of suppliers, vendors, service providers, and software dependencies. It covers everything from the SaaS tools your developers use to the managed service provider (MSP) with admin access to your production environment.

C-SCRM sits at the intersection of procurement, IT security, and compliance. NIST SP 800-161 Rev. 1 provides the most detailed federal framework for it, defining C-SCRM as a structured process for managing exposure to cybersecurity risks throughout the supply chain lifecycle — from initial vendor selection through contract termination and access revocation.

The scope is broader than most teams realize. Your supply chain includes:

• Software vendors and open-source dependencies
• Cloud infrastructure and SaaS providers
• Managed service and IT support providers
• Hardware manufacturers and firmware suppliers
• Professional services firms with network or data access

Each of these is a potential entry point. The SolarWinds, MOVEit, and XZ Utils incidents all exploited that entry point in different ways.

The state of supply chain attacks in 2025–2026

Supply chain attacks reached record levels in 2025–2026. Verizon's 2026 DBIR recorded third-party involvement in 48% of all breaches analyzed — the highest in the report's history and a 60% increase over the prior year's 30%. IBM's 2025 Cost of a Data Breach Report puts the average supply chain compromise at $4.91 million, with a 267-day average lifecycle from detection to containment.

Threat actors have learned that compromising one trusted vendor yields access to dozens or hundreds of downstream organizations simultaneously. The economics favor the attacker: one successful intrusion, multiplied across an entire vendor's customer base.

According to Black Kite's 2026 Third-Party Breach Report, 70% of the top 50 vendors shared by Global 2000 companies carry at least one unpatched vulnerability from CISA's Known Exploited Vulnerabilities (KEV) catalog. These aren't theoretical risks — CISA flags KEV entries specifically because they are being actively exploited in the wild.

Lessons from SolarWinds, MOVEit, and XZ Utils

All three incidents share a common thread: the initial access vector was trusted. Trusted software, trusted vendor, trusted contributor. Once inside, the attacker moved laterally using credentials and access that were already provisioned.

SolarWinds (2020)

Attackers compromised the build pipeline directly, inserting a backdoor into a signed software update that went out to customers as a routine patch. Roughly 18,000 organizations installed it. The legal fallout ran for years: the SEC filed a civil enforcement action against SolarWinds and its CISO in October 2023, with the case finally dismissed in full in 2025.

The lesson: software integrity controls and SBOM (Software Bill of Materials) visibility matter as much as network perimeter controls — and the liability exposure from a build pipeline compromise extends well beyond the initial breach.

MOVEit (2023)

A zero-day SQL injection vulnerability (CVE-2023-34362) in a managed file transfer product gave the Cl0p ransomware group access to data held by over 2,700 organizations — many of which had no direct relationship with MOVEit but were affected through their vendors' use of it. Final victim counts reached approximately 95 million individuals. 

The lesson: your attack surface includes software your vendors run, not just software you run.

XZ Utils (2024)

A multi-year social engineering campaign inserted a backdoor into a widely used open-source compression library. The attacker contributed legitimate code for two years before introducing the malicious payload — and the backdoor was caught not by any formal security process, but by a Microsoft engineer who noticed a 500ms delay in SSH logins. 

The lesson: open-source dependency risk is real, SBOMs are the only systematic way to track it, and your detection controls need to cover behavior, not just signatures.

Top vendor risks in the modern supply chain

The five most common supply chain risk categories are:

• Shared credentials and poor access control
• Software dependency vulnerabilities
• Hardware and component tampering
• Shadow AI and third-party data exposure
• Vendor concentration risk

Each requires a distinct control response. Shared credential failures are a process problem. Hardware tampering requires physical provenance verification.

Shared credentials and poor access control

The most common and most preventable supply chain risk is also the least glamorous: shared accounts. A vendor support team gets a single set of credentials to access your environment. Those credentials are shared across the vendor's staff, stored in a spreadsheet or email thread, and never rotated after the engagement ends.

When that vendor is breached, or when a disgruntled employee leaves, you have no way to know who used those credentials, when, or what they accessed. You have no audit trail. You have no way to revoke access for one individual without changing credentials for everyone.

Verizon's 2026 DBIR identifies authentication failures (missing or bypassed MFA, stolen credentials) as the primary mechanism in third-party breach scenarios. This is a process failure.

Software supply chain vulnerabilities and the need for SBOMs

A Software Bill of Materials (SBOM) is a machine-readable inventory of every component in a software product: libraries, dependencies, versions, and their known vulnerabilities. The U.S. Executive Order 14028 (2021) mandated SBOMs for software sold to federal agencies. The EU's Cyber Resilience Act (CRA) extends similar requirements to products sold in the European market, with vulnerability reporting obligations applying from September 2026 and full product requirements from December 2027.

Without an SBOM, you cannot answer "Are we running the vulnerable version of Log4j?" in under 24 hours. With one, you can. That speed difference is the gap between a contained incident and a breach that takes 267 days to close.

Hardware and component tampering

Hardware supply chain risk is distinct from software risk and often underestimated. Counterfeit or tampered components — network equipment, server hardware, firmware — can introduce persistent backdoors that survive OS reinstallation and are invisible to software-layer security controls.

The EU Cyber Resilience Act explicitly addresses hardware products with digital elements, requiring manufacturers to assess and document supply chain security for physical components. For organizations procuring network infrastructure or industrial control systems, this means verifying component provenance, requiring firmware integrity attestation from suppliers, and maintaining an inventory of hardware versions equivalent to a software SBOM.

Shadow AI and third-party data exposure

Verizon's 2026 DBIR identifies shadow AI as a top-three insider behavior — employees using unauthorized AI tools that process organizational data outside approved channels. The supply chain angle: many of these tools are third-party SaaS products with their own data retention policies, subprocessor agreements, and security postures that your organization never reviewed.

When a developer pastes database credentials into an AI assistant to debug a query, those credentials may be retained, logged, or used for model training. The vendor risk is not just the AI provider — it is every subprocessor in their chain.

Availability disruptions and vendor concentration risk

A supply chain security failure does not always mean a data breach. Vendor outages, ransomware attacks on critical suppliers, and single points of failure in shared infrastructure can disrupt operations entirely. DORA's operational resilience mandate exists precisely because the EU financial sector recognized that availability risk from ICT third parties is as material as confidentiality risk.

Concentration risk compounds this: when 70% of Forbes Global 2000 companies share the same top 50 vendors, a single compromise propagates at scale. Mapping your critical vendor dependencies and maintaining documented continuity plans for Tier 1 supplier failures is a DORA Article 28 requirement for financial entities.

European and international regulatory requirements for supply chain security

NIS2, DORA, and the EU Cyber Resilience Act together form the binding regulatory framework for supply chain security in the European market. NIST CSF 2.0 and SP 800-161 are U.S. frameworks — not EU legal obligations — but are widely referenced by multinational organizations and provide operational detail that complements the EU requirements.

NIS2 Directive (Article 21)

NIS2 Article 21 requires covered entities to implement "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers." This is a legal obligation for essential and important entities across 18 sectors, with enforcement that EU member states began applying in late 2024.

In practice, Article 21 means you must assess the security posture of your direct vendors, include security requirements in contracts, and maintain a documented process for managing vendor-related incidents. For credential management specifically, this translates to: no shared accounts, documented access provisioning and revocation procedures, and audit logs that can be produced during a supervisory review.

For a detailed breakdown of how NIS2 maps to access control requirements, see Passwork's NIS2 compliance guide.

DORA (Digital Operational Resilience Act)

DORA applies to financial entities and their ICT third-party service providers operating in the EU. Articles 28 through 30 establish a detailed ICT third-party risk management framework, including requirements to maintain a register of all ICT providers, conduct risk assessments before onboarding, and ensure contracts include provisions for audit rights and incident notification.

DORA also introduces the concept of "critical ICT third-party providers" (CTPPs), which the European Supervisory Authorities can designate for direct oversight. If your organization is a CTPP — or relies on one — the scrutiny on your supply chain security controls is substantially higher. The availability disruption risk described above is a DORA concern as much as a security one: Article 28 explicitly requires documented continuity plans for critical third-party dependencies.

EU Cyber Resilience Act (CRA)

The CRA was adopted in 2024 and applies in a staggered timeline. Vulnerability and incident reporting obligations take effect from 11 September 2026. Full product requirements — including SBOM mandates and conformity assessments for products with digital elements — apply from 11 December 2027. Organizations selling connected hardware or software in the EU market need to begin compliance work now; the 2027 deadline arrives faster than most product development cycles allow.

NIST CSF 2.0 and NIST SP 800-161

NIST CSF 2.0, released in February 2024, added "Govern" as a sixth core function. The GV.SC subcategory explicitly addresses supply chain risk management, requiring organizations to integrate C-SCRM into enterprise risk governance — not treat it as a separate IT project. For EU organizations, CSF 2.0 is not a legal requirement but provides useful operational structure that maps well onto NIS2 and DORA obligations.

NIST SP 800-161 Rev. 1 provides the operational detail: how to conduct supplier assessments, what controls to require in contracts, and how to structure a C-SCRM program across the full acquisition lifecycle. For U.S. federal contractors, alignment with SP 800-161 is increasingly a procurement requirement.

How to secure vendor access: The technical blueprint

The four highest-impact controls for vendor access security are RBAC scoped to the engagement, just-in-time privileged access, centralized credential vaulting, and phishing-resistant MFA. Applied in that order, they address the most common failure modes — standing privileges, shared accounts, and authentication gaps — without requiring new infrastructure in most environments.

Enforce strict role-based access control (RBAC)

Role-based access control (RBAC) assigns permissions to roles, not individuals. A vendor support engineer gets the "read-only production monitoring" role, not a personal admin account. When the engagement ends, you remove the role assignment. When the vendor rotates their staff, you don't need to track individual accounts — the role defines what's accessible.

For vendor access specifically, RBAC should be scoped to the minimum required for the engagement. A database vendor performing a performance audit does not need write access to application configuration. Define the role before provisioning access, not after.

Implement just-in-time (JIT) privileged access

Just-in-time (JIT) access means privileged credentials are issued for a defined time window and automatically revoked when that window closes. A vendor engineer requests access for a two-hour maintenance window; the system grants it, logs the session, and revokes it at hour two regardless of whether the engineer remembers to log out.

JIT access eliminates standing privileges: the persistent, always-on access that attackers exploit during the 267-day average dwell time of a supply chain breach. There is nothing to steal if the credentials expire before the attacker can use them. JIT is particularly effective for break-glass scenarios: emergency vendor access during an incident, where speed matters but so does accountability.

Secure vendor credential vaulting

Shared vendor accounts are a liability. The alternative is a credential vault: a centralized, encrypted store where vendor credentials are held by your organization, not the vendor. The vendor authenticates to the vault, checks out credentials for their session, and the vault logs every access event.

This approach gives you a complete audit trail of who accessed what and when, the ability to rotate credentials without coordinating with the vendor, automatic revocation when the vendor relationship ends, and compliance evidence for NIS2 Article 21 and DORA Article 30 audit rights requirements.

Passwork's enterprise password and secrets manager supports time-limited credential sharing, session logging, and integration with AD/LDAP and SSO infrastructure — with AES-256 client-side encryption and a full REST API for integration into existing provisioning workflows.

Mandate phishing-resistant MFA for third parties

MFA is the single highest-ROI control for third-party access. Verizon's 2026 DBIR attributes the majority of third-party breach scenarios to authentication failures — and most of those failures are missing MFA, not bypassed MFA.

For privileged vendor access to production systems, the bar should be phishing-resistant MFA: FIDO2/WebAuthn hardware keys or passkeys, not SMS OTP. SMS-based MFA is vulnerable to SIM-swapping and real-time phishing proxies. Contractually require phishing-resistant MFA from vendors as a condition of access. Include it in your vendor security addendum, not just your internal policy.

Most of the access control failures described in this guide trace back to the same root cause: vendor credentials that were never properly vaulted, scoped, or revoked. Passwork addresses that directly — centralized credential vaulting, role-based access, time-limited sharing, and a full audit log tied to named identities. Available self-hosted or as a cloud deployment, it integrates with AD/LDAP and SAML SSO and is ISO 27001 certified.

Building a vendor risk assessment framework

A vendor risk assessment framework classifies third parties by access level and applies proportionate security requirements to each tier. The 5-tier model below scales from Tier 1 vendors with privileged production access, which require full security assessments and annual reviews — down to Tier 5 vendors with no data or system access, where standard procurement due diligence is sufficient.

The 5-tier vendor risk classification model:

The classification drives proportionate effort. You don't need a full penetration test report from your office supply vendor. You do need one from the MSP with admin access to your Active Directory.

Vendor access control checklist

The following pre-audit vendor access checklist maps directly to NIS2 Article 21, DORA Article 28, and NIST SP 800-161 requirements. Use it at vendor onboarding and at each annual review.

Pre-access provisioning:

•  Vendor classified by tier based on access level
•  Minimum necessary access scope defined in writing
•  Named individuals identified (no shared/generic accounts)
•  MFA requirement confirmed and tested
•  Access provisioned via credential vault, not direct credential sharing
•  Session logging enabled

During the engagement:

•  Access scope reviewed if engagement scope changes
•  Unusual access patterns flagged for review
•  Vendor incident notification clause active in contract

Access revocation:

•  Offboarding trigger defined (contract end, staff change, incident)
•  Credentials rotated immediately on offboarding
•  Vault access revoked and audit log exported
•  Access review documented for compliance records

Conclusion: Making supply chain security operational

Organizations that manage this well don't have fewer vendors; they have tighter controls on how those vendors authenticate, what they can access, and for how long.

The technical blueprint is clear: classify vendors by access tier, eliminate shared accounts, vault credentials centrally, enforce JIT access for privileged sessions, and require phishing-resistant MFA. NIS2, DORA, and the CRA provide the governance structure and the contractual leverage to hold vendors to the same standard.

Start with your Tier 1 vendors — the ones with privileged access to production systems. Audit their current access scope, confirm individual account assignment, and verify MFA is active. That single pass will surface more actionable risk than a year of questionnaires.

Frequently asked questions

What is the difference between supply chain security and vendor risk management?

Vendor risk management (VRM) is the broader discipline covering financial, operational, reputational, and cyber risks from third parties. Supply chain security is the cybersecurity-specific subset: protecting systems, data, and software integrity from threats that enter through supplier relationships. VRM informs procurement decisions; supply chain security governs technical access controls and software integrity.

Which regulations require supply chain security controls in 2025–2026?

NIS2 Directive Article 21 requires EU essential and important entities to assess and manage supplier security risks. DORA Articles 28–30 impose ICT third-party risk management obligations on EU financial entities. The EU Cyber Resilience Act requires vulnerability reporting from September 2026 and full SBOM and conformity requirements from December 2027. In the U.S., NIST SP 800-161 and Executive Order 14028 set C-SCRM expectations for federal contractors.

What is just-in-time (JIT) access and why does it matter for vendor security?

JIT access issues privileged credentials for a defined time window and revokes them automatically when that window closes. It eliminates standing privileges — persistent access that attackers exploit during the extended dwell time typical of supply chain breaches. IBM's 2025 data shows supply chain compromises average 267 days to identify and contain; JIT access reduces the exploitable window to hours, not months.

How do SBOMs reduce supply chain risk?

A Software Bill of Materials (SBOM) is a machine-readable inventory of all software components and their versions. When a new vulnerability is disclosed — such as Log4Shell in 2021 — an SBOM lets you determine within minutes whether any of your systems or vendor-supplied software contains the affected component. Without an SBOM, that same determination can take days or weeks, during which the vulnerability remains unpatched and exploitable.

What should a vendor security contract addendum include?

At minimum: a requirement for named individual accounts (no shared credentials), phishing-resistant MFA for privileged access, notification obligations within 24–72 hours of a security incident, audit rights allowing your organization to review access logs, and a defined offboarding process including credential rotation. NIS2 Article 21 and DORA Article 30 both require contractual security provisions — the addendum is your compliance evidence.

How should organizations classify vendors for risk assessment purposes?

Classify by access level, not by contract value or vendor size. A small consultancy with admin access to your production environment is higher risk than a large software vendor with no direct system access. The 5-tier vendor risk classification model above provides a practical structure: Tier 1 (privileged production access) through Tier 5 (no data or system access), with assessment requirements and review frequency scaled accordingly.

What is the most common access control failure in third-party breaches?

Shared credentials with no individual accountability. A single set of credentials issued to a vendor team, stored outside a vault, never rotated, and never revoked when the engagement ends. Verizon's 2026 DBIR identifies authentication failures as the primary mechanism in third-party breach scenarios. The fix is individual named accounts, credential vaulting, and a documented offboarding process — not more complex technology.

What is hardware supply chain risk and how is it different from software supply chain risk?

Hardware supply chain risk involves counterfeit or tampered physical components — network equipment, server hardware, firmware — that can introduce persistent backdoors invisible to software-layer security controls. Unlike software vulnerabilities, hardware tampering survives OS reinstallation. The EU Cyber Resilience Act addresses this directly, requiring manufacturers to document supply chain security for hardware products with digital elements.

Inside real supply chain attacks: Bitwarden CLI, Axios, and Vercel

Why breach your network when attackers can compromise a trusted dependency with millions of downloads and slip silently into thousands of organizations at once? Three 2026 campaigns prove supply chain attacks are no longer isolated incidents.

Passwork BlogAlex Muntyan

Shadow IT vs Shadow AI: Why AI is the bigger threat

Employees are using AI tools you didn’t approve, on accounts you can’t monitor, with data you can’t recover. Here’s what the risk actually looks like and what governance needs to address.

Passwork BlogAlex Muntyan

NIS2 access controls for supply chain security

48% of breaches now involve third parties. NIS2 Article 21 makes supplier access governance a legal obligation. Here’s how to map vendor access, enforce MFA and least privilege, and keep the audit evidence that proves your controls work.

Passwork BlogAlex Muntyan

LDAP (Lightweight Directory Access Protocol) ist ein Client-Server-Protokoll zum Lesen und Schreiben von Verzeichnisdiensten über ein Netzwerk. Definiert in RFC 4511, bietet es Anwendungen eine standardisierte Möglichkeit, ein Verzeichnis abzufragen — mit Fragen wie „Existiert dieser Benutzer?", „Zu welchen Gruppen gehört er?" und „Auf welche Ressourcen hat er Zugriff?"

Obwohl LDAP erstmals Anfang der 1990er Jahre standardisiert wurde, bleibt es auch 2026 das Rückgrat der Unternehmens-Identitätsinfrastruktur. Active Directory, das auf LDAP basiert, ist nach wie vor bei etwa 90 % der Organisationen weltweit im Einsatz.

Wichtigste Erkenntnisse

• LDAP ist ein Protokoll. Es definiert, wie Anwendungen ein Verzeichnis abfragen — Benutzerkonten, Gruppenmitgliedschaften, Zugriffsrechte. Active Directory implementiert es, aber LDAP läuft unabhängig auf OpenLDAP und anderen Servern ohne jegliche Microsoft-Software.
• AD kann ohne LDAP nicht funktionieren. Jedes Nicht-Windows-System, das sich gegen Active Directory authentifiziert, tut dies über LDAP. Ohne LDAP verliert AD die Fähigkeit, Drittanbieteranwendungen, Netzwerkgeräte und Linux-Infrastruktur zu bedienen.
• Port 389 ist in Produktionsumgebungen nicht akzeptabel. Standard-LDAP überträgt Anmeldedaten im Klartext. LDAPS auf Port 636 verschlüsselt die gesamte Sitzung. Microsoft setzt seit 2020 Anforderungen für Signierung und Channel Binding durch.
• Zwei kritische Schwachstellen wurden 2025 gepatcht. CVE-2025-26663 ermöglicht nicht authentifizierte Remote-Code-Ausführung auf Domänencontrollern durch einen Speicherfehler im Windows-LDAP-Dienst. CVE-2025-54918 umgeht Channel-Binding- und Signierungsschutz durch NTLM-Relay. Für beide gibt es Patches — ungepatchte Domänencontroller haben höchste Priorität bei der Behebung.
• LDAP und moderne Protokolle sind keine Alternativen. SAML übernimmt browserbasiertes SSO. OAuth übernimmt API-Autorisierung. LDAP übernimmt Verzeichnisabfragen für Systeme, die keines von beiden sprechen. Die meisten Unternehmensumgebungen betreiben alle drei gleichzeitig.
• Manuelle Zugriffsverwaltung schafft Lücken. Wenn AD-Gruppenänderungen nicht automatisch an abhängige Systeme weitergegeben werden, bleiben Konten länger aktiv als sie sollten. Die Synchronisierung des Anmeldedatenzugriffs mit der Verzeichnis-Gruppenmitgliedschaft eliminiert diese Verzögerung.

LDAP verstehen: Die Grundlagen

LDAP ist ein Standardprotokoll für den Zugriff auf und die Verwaltung von verteilten Verzeichnisinformationsdiensten. Es arbeitet mit einem hierarchischen Datenmodell, das vom X.500-Standard abgeleitet ist, und ermöglicht Clients die Authentifizierung von Benutzern, das Nachschlagen von Attributen und das Abrufen von Gruppenmitgliedschaften aus einem zentralen Verzeichnis. Organisationen nutzen es, um eine grundlegende Frage im großen Maßstab zu beantworten: Wer darf was tun und wo?

Die Daten, die LDAP organisiert, befinden sich in einem Directory Information Tree (DIT) — einer hierarchischen Struktur von Einträgen, die jeweils durch einen Distinguished name (DN) identifiziert werden. Ein typischer DN sieht so aus:

Copycn=jane.doe,ou=engineering,dc=company,dc=com

Jeder Eintrag enthält Attribute: Ein Benutzereintrag könnte mail, uid, memberOf und userPassword enthalten. Anwendungen fragen diese Attribute ab, um Authentifizierungs- und Autorisierungsentscheidungen zu treffen.

Wie funktioniert LDAP? (Client-Server-Modell)

Ein LDAP-Client sendet eine Anfrage an einen LDAP-Server (genannt Directory System Agent oder DSA). Der Server verarbeitet die Operation gegen seine Verzeichnisdatenbank und gibt eine Antwort zurück. Die in RFC 4511 definierten Kernoperationen umfassen:

• Bind — authentifiziert einen Client beim Verzeichnis
• Search — fragt Einträge ab, die einem Filter entsprechen
• Compare — prüft, ob ein Eintrag einen bestimmten Attributwert hat
• Modify / Add / Delete — Schreiboperationen auf Verzeichniseinträgen
• Unbind — beendet die Sitzung

Die Bind-Operation ist der Ort, an dem die Authentifizierung stattfindet. Ein Client sendet einen DN und Anmeldedaten. Der Server validiert diese und gewährt oder verweigert die Sitzung. Die meisten Unternehmensanwendungen verwenden LDAP-Bind, um die Benutzeridentität vor der Gewährung des Zugriffs zu überprüfen.

LDAP-Port 389 vs. LDAPS-Port 636

Standard-LDAP läuft auf TCP-Port 389 und überträgt Daten im Klartext. Das bedeutet, dass Anmeldedaten, einschließlich Passwörter, unverschlüsselt über das Netzwerk übertragen werden. In jeder Umgebung, in der Netzwerkverkehr abgefangen werden könnte (was jede Umgebung ist), ist dies inakzeptabel.

LDAPS (LDAP über SSL/TLS) läuft auf TCP-Port 636 und umhüllt die gesamte LDAP-Sitzung mit TLS, wodurch der gesamte Datenverkehr einschließlich der Bind-Anmeldedaten verschlüsselt wird. Eine dritte Option, StartTLS, aktualisiert eine bestehende Port-389-Verbindung mitten in der Sitzung auf TLS, führt jedoch zu Verhandlungskomplexität und ist fehleranfälliger bei der korrekten Konfiguration.

Microsoft schreibt seit 2020 schrittweise LDAP-Channel-Binding und LDAP-Signierung vor, wobei die Durchsetzung in nachfolgenden Windows-Server-Updates verschärft wurde. Unverschlüsseltes LDAP auf Port 389 in der Produktion zu betreiben, ist eine Sicherheitslücke. Port 636 ist die korrekte Standardeinstellung.

LDAP vs. Active Directory: Was ist der Unterschied?

Active Directory (AD) ist kein Ersatz für LDAP — es ist ein Verzeichnisdienst, der LDAP als eines seiner Zugriffsprotokolle verwendet. Die Verwechslung beider ist eines der häufigsten Missverständnisse in der Unternehmens-IT. Die Abhängigkeit besteht nur in eine Richtung: LDAP steht für sich allein, AD nicht.

Kann LDAP ohne AD betrieben werden?

Ja. LDAP ist ein Protokoll — es definiert, wie ein Client einen Verzeichnisserver nach Informationen fragt und wie dieser Server antwortet. Es kann unabhängig von jeglicher Microsoft-Software eingesetzt werden.

OpenLDAP ist die am weitesten verbreitete Open-Source-Implementierung. 389 Directory Server und Apache Directory Server sind gängige Alternativen. Diese eigenständigen Server speichern Benutzeridentitäten und Gruppenmitgliedschaften und stellen sie Linux/Unix-Systemen, Mailservern und benutzerdefinierten Anwendungen zur Verfügung.

Kann AD ohne LDAP betrieben werden?

Nein. Active Directory ist ein vollständiger Verzeichnisdienst, der von Microsoft auf Basis des X.500-Datenmodells entwickelt wurde. Domänencontroller verwenden LDAP intern zum Lesen, Schreiben und Replizieren von Verzeichnisdaten: Benutzer, Computer, Gruppenrichtlinien. Jede Drittanbieteranwendung oder Nicht-Windows-Maschine, die sich gegen AD authentifiziert, tut dies über LDAP.

Ohne LDAP kann AD nicht mit dem Rest Ihrer Infrastruktur kommunizieren.

Wie sie in der Praxis zusammenhängen

Wenn sich ein Linux-Server gegen Active Directory authentifiziert, spricht er LDAP. Wenn sich eine Windows-Workstation anmeldet, verwendet sie Kerberos. AD unterstützt beides — aber LDAP ist das, was AD für den Rest Ihrer Infrastruktur zugänglich macht.

Moderne Alternativen: LDAP vs. SAML, OAuth und OpenID Connect

LDAP wurde für die interne Netzwerkauthentifizierung konzipiert — das Abfragen eines Verzeichnisses innerhalb eines Unternehmensperimeters. Die Protokolle, die ihm folgten, wurden für eine andere Welt entwickelt: föderierte Identität über Organisationsgrenzen hinweg, Webanwendungen und mobile Clients.

Diese Protokolle ersetzen LDAP nicht — sie arbeiten auf einer anderen Ebene. SAML und OpenID Connect übernehmen browserbasiertes SSO. LDAP übernimmt Verzeichnisabfragen und Anwendungsauthentifizierung für Systeme, die SAML nicht sprechen können. Die meisten Unternehmensumgebungen betreiben alle gleichzeitig.

Ist LDAP 2026 noch relevant? (Die Hybrid-Cloud-Realität)

LDAP ist nach wie vor das dominierende Unternehmens-Authentifizierungsprotokoll, das durch Active-Directory-Implementierungen bei etwa 90 % der Organisationen weltweit präsent ist. Die Cloud-Adoption hat daran nichts geändert.

Die meisten Unternehmen sind nicht vollständig cloud-nativ. Sie betreiben ein Hybridmodell: einige Workloads in Azure oder AWS, andere vor Ort, mit Active Directory als Identitätsanker für beide. Microsoft Entra ID (ehemals Azure AD) verbindet sich über Synchronisation mit dem lokalen AD, aber das lokale AD (und damit LDAP) bleibt für viele Identitätsentscheidungen die maßgebliche Quelle.

Die Rolle von LDAP in der Zero-Trust-Architektur

Zero Trust erfordert kontinuierliche Verifizierung: Jede Zugriffsanfrage muss authentifiziert und autorisiert werden, unabhängig vom Netzwerkstandort. LDAP sitzt an einem kritischen Knotenpunkt in diesem Modell, da es oft das System ist, das diese Verifizierungsanfragen beantwortet.

Die Herausforderung besteht darin, dass LDAP nicht mit Zero-Trust-Prinzipien im Sinn entwickelt wurde. Es setzt Netzwerknähe voraus, verwendet persistente Verbindungen und exponiert in seiner unverschlüsselten Form Anmeldedaten bei der Übertragung. Die Einbindung von LDAP in eine Zero-Trust-Architektur erfordert kompensierende Kontrollen:

• Obligatorisches LDAPS
• Strikte Firewall-Regeln
• Einschränkung, welche Systeme Port 636 erreichen können
• Durchsetzung der LDAP-Signierung
• Überwachung von Bind-Versuchen auf anomale Muster

LDAP bricht Zero Trust nicht, erfordert aber gezielte Härtung, um es zu unterstützen. Organisationen, die LDAP als Legacy-Komponente behandeln und es unkonfiguriert lassen, schaffen genau die Art von implizitem Vertrauen, das Zero Trust beseitigen soll.

DevOps und CI/CD-Secrets-Management

Automatisierte Pipelines stellen eine spezifische LDAP-Herausforderung dar. CI/CD-Systeme (Jenkins, GitLab CI, GitHub Actions Runner) müssen sich oft gegen LDAP authentifizieren, um auf interne Ressourcen zuzugreifen. Diese Authentifizierung umfasst typischerweise ein Dienstkonto: einen dedizierten LDAP-Bind-DN mit einem statischen Passwort.

Statische Dienstkonto-Anmeldedaten sind ein anhaltendes Risiko. Sie werden selten rotiert, werden oft über Pipelines hinweg gemeinsam genutzt, und wenn sie in Build-Logs oder Konfigurationsdateien erscheinen, sind sie schwer zu erkennen und zu widerrufen. Die Lösung besteht darin, diese Anmeldedaten über einen dedizierten Secrets-Manager zu verwalten, anstatt sie in der Pipeline-Konfiguration hart zu kodieren.

Kritische LDAP-Sicherheitsrisiken 2026

LDAP ist nicht nur ein Legacy-Protokoll mit theoretischen Risiken. Es ist eine aktive Angriffsfläche mit dokumentierten, ausgenutzten Schwachstellen.

Die Bedrohung durch Anmeldedatendiebstahl und Ransomware

Laut dem X-Force Threat Intelligence Index 2026 von IBM war das Abgreifen von Anmeldedaten die häufigste Angriffsauswirkung, die 2025 beobachtet wurde. Bedrohungsakteure sammelten Anmeldedaten durch Phishing und Infostealer und fügten sich dann in normale Authentifizierungsströme ein, um sich lateral zu bewegen. LDAP-Dienstkonto-Anmeldedaten passen genau in dieses Muster: anwendungsübergreifend wiederverwendet, selten rotiert und fast nie auf anomale Bind-Aktivitäten überwacht.

Die Angriffskette ist gut dokumentiert: Kompromittierung einer LDAP-Anmeldedaten durch Phishing oder Password Spraying, Nutzung zur Aufzählung des Verzeichnisses, Identifizierung privilegierter Konten und Eskalation. Der Digital Defense Report von Microsoft hat durchgängig die Kompromittierung von AD/LDAP-Anmeldedaten mit Ransomware-Bereitstellung in Verbindung gebracht. Das Verzeichnis ist eine Karte der gesamten Zugriffsstruktur einer Organisation, und Angreifer lesen sie, bevor sie handeln.

Aktuelle Schwachstellen: CVE-2025-26663 und CVE-2025-54918

Zwei kritische Schwachstellen, die 2025 offengelegt wurden, zeigen, dass die Angriffsfläche von LDAP aktiv wächst.

CVE-2025-26663 ist eine Use-after-free-Schwachstelle für Remote-Code-Ausführung in Windows LDAP, die im April 2025 offengelegt wurde. Ein Angreifer kann einen Speicherverwaltungsfehler im Windows-LDAP-Dienst (speziell in wldap32.dll) ausnutzen, um beliebigen Code auf einem Zielserver ohne gültige Anmeldedaten auszuführen.

Der Angriff erfordert nur Netzwerkzugriff auf den LDAP-Dienst. Domänencontroller, die LDAP naturgemäß exponieren, sind die Hauptziele. Ungepatchte Domänencontroller mit dieser Schwachstelle sind praktisch offen für nicht authentifizierte Remote-Code-Ausführung (RCE) von jedem System, das Port 389 oder 636 erreichen kann.

CVE-2025-54918, offengelegt im September 2025, ist eine Privilegieneskalations-Schwachstelle, die NT LAN Manager Relay mit erzwungener Authentifizierung kombiniert, um LDAP-Channel-Binding- und Signierungsschutz zu umgehen. Ein Angreifer mit einem niedrig privilegierten Domänenkonto kann einen Domänencontroller zwingen, sich bei einem vom Angreifer kontrollierten System zu authentifizieren, die NTLM-Authentifizierungspakete während der Übertragung manipulieren und die modifizierte Authentifizierung zurück an den Domänencontroller weiterleiten — und so SYSTEM-Level-Zugriff erlangen. Der Angriff ist besonders gefährlich, weil er Kontrollen umgeht, auf die sich Organisationen üblicherweise als Härtungsmaßnahmen verlassen.

Best Practices zur Absicherung von LDAP im Unternehmen

Die folgende Checkliste umfasst die Mindestkontrollen für eine LDAP-Produktionsbereitstellung. Dies sind Empfehlungen, die einen spezifischen, dokumentierten Angriffsvektor adressieren.

1. LDAPS auf Port 636 durchsetzen. Klartext-LDAP auf Port 389 für den gesamten Produktionsverkehr deaktivieren. TLS-Zertifikate von Ihrer internen CA oder einer vertrauenswürdigen öffentlichen CA konfigurieren.
2. LDAP-Signierung und Channel Binding aktivieren. Verhindert Relay-Angriffe. Erforderlich zur Minderung von CVE-2025-54918 — wobei zu beachten ist, dass CVE-2025-54918 diese Kontrollen auf ungepatchten Systemen umgeht, sodass das Patchen weiterhin obligatorisch ist.
3. Alle Windows-Sicherheitsupdates anwenden. Für CVE-2025-26663 und CVE-2025-54918 gibt es Patches. Ungepatchte Domänencontroller sind das Behebungselement mit höchster Priorität.
4. LDAP-Zugriff nach IP einschränken. Nur Systeme, die legitimerweise LDAP abfragen müssen, sollten Port 636 erreichen können. Firewall-Regeln sollten dies durchsetzen, nicht nur Annahmen zur Netzwerksegmentierung.
5. Dienstkonto-Anmeldedaten auditieren. Jeden Bind-DN identifizieren, der in Ihrer Umgebung verwendet wird. Passwörter nach einem Zeitplan rotieren. Konten entfernen, die nicht mehr benötigt werden.
6. Bind-Versuche überwachen. Ungewöhnliche Bind-Muster — wiederholte Fehlschläge, Binds von unerwarteten Quell-IPs, Binds zu ungewöhnlichen Zeiten — sind frühe Indikatoren für Credential Stuffing oder laterale Bewegung.
7. Anonyme LDAP-Binds deaktivieren. Anonyme Abfragen ermöglichen nicht authentifizierte Aufzählung von Verzeichnisinhalten. Die meisten modernen Implementierungen haben keine legitime Verwendung für anonyme Binds.
8. Dienstkonten nach Funktion trennen. Ein Dienstkonto, das von einem VPN verwendet wird, sollte nicht die gleichen Berechtigungen haben wie eines, das von einem Backup-System verwendet wird. Das Prinzip der geringsten Rechte gilt auch für LDAP-Bind-Konten.

Unternehmens-Zugriff mit der Passwork-LDAP-Integration optimieren

Der operative Aufwand der LDAP-basierten Zugriffsverwaltung summiert sich im Laufe der Zeit. Benutzer wechseln Teams, treten Projekten bei und verlassen die Organisation — und jeder Übergang erfordert Zugriffsänderungen über mehrere Systeme hinweg. Wenn diese Änderungen manuell erfolgen, hinken sie hinterher. Konten bleiben länger aktiv als sie sollten. Anmeldedaten sammeln sich an Orten an, die niemand verfolgt.

Passwork verbindet sich direkt mit Active Directory oder jedem LDAP-kompatiblen Verzeichnis und ordnet Gruppenmitgliedschaften automatisch dem Tresor-Zugriff zu:

• Fügen Sie einen Benutzer zur SRE-Gruppe in AD hinzu — die korrekten Anmeldedaten erscheinen in seinem Passwork-Tresor, keine separate Admin-Aktion erforderlich
• Entfernen Sie ihn aus der Gruppe — der Zugriff wird widerrufen
• Das Verzeichnis bleibt die einzige Wahrheitsquelle dafür, wer auf was Zugriff hat

Für selbst gehostete Umgebungen wird Passwork vollständig innerhalb Ihres eigenen Perimeters bereitgestellt. Anmeldedaten verlassen ihn nie. SAML SSO wird neben LDAP unterstützt, sodass Teams, die beide Protokolle für verschiedene Anwendungsebenen verwenden, ihre Identitätsarchitektur nicht neu aufbauen müssen.

Jedes Lesen, Schreiben, Teilen und Exportieren wird im Audit-Log aufgezeichnet — relevant sowohl für interne Sicherheitsüberprüfungen als auch zum Nachweis der Compliance mit SOC 2 CC6.1 und DSGVO Artikel 32.

Fazit

LDAP wird nicht verschwinden. Der Markt für Verzeichnissoftware wurde 2025 auf 8,4 Milliarden US-Dollar geschätzt und soll laut der Marktforschung von Dataintelo bis 2034 19,7 Milliarden US-Dollar erreichen — eine Zahl, die fortgesetzte Unternehmensinvestitionen in Verzeichnisinfrastruktur widerspiegelt, nicht eine Technologie im Niedergang. Mit 90 % der Unternehmen, die noch Active Directory betreiben, bleibt LDAP das verbindende Gewebe des Unternehmens-Identitätsmanagements.

Was sich geändert hat, ist die Bedrohungsumgebung. CVE-2025-26663 und CVE-2025-54918 sind aktiv gepatchte Schwachstellen, die auf die LDAP-Dienste abzielen, die Ihre Domänencontroller gerade jetzt exponieren.

Die praktische Maßnahme ist einfach: LDAPS durchsetzen, Ihre Domänencontroller patchen, Ihre Dienstkonto-Anmeldedaten auditieren und sicherstellen, dass Zugriffsänderungen in Ihrem Verzeichnis automatisch an die Systeme weitergegeben werden, die davon abhängen. Manuelle Zugriffsverwaltung im Maßstab, in dem die meisten Unternehmen operieren, ist dort, wo Lücken entstehen.

Häufig gestellte Fragen zu LDAP

Wofür wird LDAP verwendet?

LDAP wird zur Authentifizierung von Benutzern und zum Nachschlagen von Verzeichnisinformationen verwendet — Gruppenmitgliedschaften, E-Mail-Adressen, Kontoattribute — über Unternehmensanwendungen hinweg. Häufige Anwendungsfälle umfassen VPN-Authentifizierung, Mailserver-Benutzerabfrage, Anwendungs-SSO und zentralisierte Benutzerverwaltung. Die meisten Unternehmensanwendungen, die eine Identität gegen ein Unternehmensverzeichnis verifizieren müssen, verwenden LDAP.

Was ist der Unterschied zwischen LDAP und Active Directory?

LDAP ist ein offenes Protokoll (RFC 4511) für den Zugriff auf Verzeichnisdienste. Active Directory ist der Verzeichnisdienst von Microsoft, der LDAP als eines seiner Zugriffsprotokolle verwendet. AD verwendet auch Kerberos für die Windows-Authentifizierung. LDAP kann ohne Active Directory verwendet werden (z. B. über OpenLDAP), aber Active Directory ist auf LDAP angewiesen, um Verzeichnisabfragen an Nicht-Windows-Anwendungen zu bedienen.

Was ist LDAPS und warum ist es wichtig?

LDAPS ist LDAP über TLS, läuft auf Port 636. Standard-LDAP auf Port 389 überträgt Anmeldedaten im Klartext, wodurch sie für jeden sichtbar sind, der Netzwerkverkehr abfangen kann. LDAPS verschlüsselt die gesamte Sitzung. Im Jahr 2026 ist das Betreiben von unverschlüsseltem LDAP in der Produktion nicht vertretbar — Microsoft setzt seit 2020 Anforderungen für LDAP-Signierung und Channel Binding durch, und sowohl CVE-2025-26663 als auch CVE-2025-54918 zielen direkt auf LDAP-Dienste ab.

Wird LDAP 2026 noch verwendet?

Ja. Active Directory, das auf LDAP angewiesen ist, wird bei etwa 90 % der Unternehmen weltweit eingesetzt. Die Cloud-Adoption hat dies nicht verdrängt — die meisten Organisationen betreiben Hybridumgebungen, in denen das lokale AD die maßgebliche Identitätsquelle bleibt. LDAP ist auch in Tausenden von Anwendungen eingebettet, die sich gegen Unternehmensverzeichnisse authentifizieren und ohne erhebliche Umgestaltung nicht durch SAML oder OAuth ersetzt werden.

Wie passt LDAP in eine Zero-Trust-Architektur?

LDAP kann Zero Trust unterstützen, wenn es korrekt gehärtet wird. Zero Trust erfordert kontinuierliche Verifizierung jeder Zugriffsanfrage, und LDAP ist oft das System, das diese Anfragen beantwortet. Die Anforderungen: LDAPS durchsetzen (Port 636), Signierung und Channel Binding aktivieren, Verzeichniszugriff nach Quell-IP einschränken, Bind-Versuche überwachen und Dienstkonto-Anmeldedaten regelmäßig rotieren. Die Standardkonfiguration von LDAP ist nicht Zero-Trust-kompatibel — aber das Protokoll selbst ist nicht das Hindernis.

Was sind die wichtigsten Sicherheitsrisiken bei LDAP?

Die primären Risiken sind die Exponierung von Anmeldedaten über unverschlüsselte Verbindungen (Port 389), Diebstahl von Dienstkonto-Anmeldedaten, NTLM-Relay-Angriffe (CVE-2025-54918) und nicht authentifizierte RCE über Speicherkorruptions-Schwachstellen (CVE-2025-26663). Der X-Force Threat Intelligence Index 2025 von IBM ergab, dass identitätsbasierte Angriffe — viele auf Verzeichnis-Anmeldedaten abzielend — 2024 30 % aller Einbrüche ausmachten. Patchen, LDAPS-Durchsetzung und Dienstkonto-Hygiene adressieren die Mehrheit dieser Risiken.

Kann LDAP durch SAML oder OAuth ersetzt werden?

Nicht vollständig. SAML und OAuth übernehmen browserbasierte föderierte Authentifizierung bzw. API-Autorisierung. LDAP übernimmt Verzeichnisabfragen und Anwendungsauthentifizierung für Systeme, die SAML nicht sprechen können. Die meisten Unternehmensumgebungen betreiben alle drei Protokolle für verschiedene Ebenen ihres Anwendungsstacks. Die Frage ist nicht, welches gewählt werden soll — sondern welche Anwendungen LDAP erfordern und ob diese Verbindungen ordnungsgemäß gesichert sind.

Schatten-IT vs. Schatten-KI: Warum KI die größere Bedrohung ist

Mitarbeiter nutzen KI-Tools, die Sie nicht genehmigt haben, auf Konten, die Sie nicht überwachen können, mit Daten, die Sie nicht wiederherstellen können. So sieht das Risiko wirklich aus und was Governance adressieren muss.

Passwork BlogAlex Muntyan

Unsichere Passwortweitergabe: Risiken und sichere Lösungen 2026

Jedes Mal, wenn Anmeldedaten über Slack oder E-Mail übertragen werden, verlieren Sie Verantwortlichkeit, Audit-Trail und Compliance-Haltung in einem Schritt. Dieser Leitfaden behandelt die realen Risiken unsicherer Passwortweitergabe 2026, warum Mitarbeiter es trotzdem tun, und wie Sie auf tresor-vermittelten Zugriff umsteigen, ohne Ihr Team zu stören.

Passwork BlogAlex Muntyan

Passwork gewinnt Top Performer Frühjahr 2026 auf SourceForge

Passwork wurde von SourceForge als Top Performer Frühjahr 2026 ausgezeichnet und rangiert unter den Top 10 % von über 100.000 Lösungen. Die Auszeichnung basiert ausschließlich auf verifizierten Bewertungen — 4,8 Sterne insgesamt, mit einer perfekten 5,0 für Support.

Passwork BlogAlex Muntyan

LDAP (Lightweight Directory Access Protocol) es un protocolo cliente-servidor para leer y escribir servicios de directorio a través de una red. Definido en RFC 4511, proporciona a las aplicaciones una forma estándar de consultar un directorio — respondiendo preguntas como «¿existe este usuario?», «¿a qué grupos pertenece?» y «¿a qué recursos puede acceder?»

A pesar de haber sido estandarizado por primera vez a principios de los años 90, LDAP sigue siendo la columna vertebral de la infraestructura de identidad empresarial en 2026. Active Directory, que funciona sobre LDAP, todavía está implementado en aproximadamente el 90% de las organizaciones en todo el mundo.

Puntos clave

• LDAP es un protocolo. Define cómo las aplicaciones consultan un directorio — cuentas de usuario, membresías de grupos, derechos de acceso. Active Directory lo implementa, pero LDAP funciona de forma independiente en OpenLDAP y otros servidores sin ningún software de Microsoft.
• AD no puede funcionar sin LDAP. Cada sistema que no es Windows y que se autentica contra Active Directory lo hace a través de LDAP. Si se elimina, AD pierde la capacidad de servir a aplicaciones de terceros, dispositivos de red e infraestructura Linux.
• El puerto 389 no es aceptable en producción. LDAP estándar transmite credenciales en texto plano. LDAPS en el puerto 636 cifra toda la sesión. Microsoft ha estado aplicando requisitos de firma y vinculación de canal desde 2020.
• Dos vulnerabilidades críticas fueron parcheadas en 2025. CVE-2025-26663 permite la ejecución remota de código no autenticada en controladores de dominio a través de un fallo de memoria en el servicio LDAP de Windows. CVE-2025-54918 elude las protecciones de vinculación de canal y firma mediante retransmisión NTLM. Ambas tienen parches — los controladores de dominio sin parchear son el elemento de remediación de mayor prioridad.
• LDAP y los protocolos modernos no son alternativas. SAML maneja SSO basado en navegador. OAuth maneja la autorización de API. LDAP maneja las búsquedas de directorio para sistemas que no hablan ninguno de los dos. La mayoría de los entornos empresariales ejecutan los tres simultáneamente.
• La gestión manual de accesos crea brechas. Cuando los cambios en grupos de AD no se propagan automáticamente a los sistemas dependientes, las cuentas permanecen activas más tiempo del debido. Sincronizar el acceso a credenciales con la membresía de grupos del directorio elimina ese retraso.

Entendiendo LDAP: Los fundamentos

LDAP es un protocolo estándar para acceder y gestionar servicios de información de directorio distribuidos. Opera en un modelo de datos jerárquico derivado del estándar X.500 y permite a los clientes autenticar usuarios, buscar atributos y recuperar membresías de grupos desde un directorio central. Las organizaciones lo utilizan para responder una pregunta fundamental a escala: ¿quién tiene permitido hacer qué y dónde?

Los datos que LDAP organiza residen en un Árbol de Información de Directorio (DIT) — una estructura jerárquica de entradas, cada una identificada por un Distinguished Name (DN). Un DN típico tiene este aspecto:

Copycn=jane.doe,ou=engineering,dc=company,dc=com

Cada entrada contiene atributos: una entrada de usuario puede contener mail, uid, memberOf y userPassword. Las aplicaciones consultan estos atributos para tomar decisiones de autenticación y autorización.

¿Cómo funciona LDAP? (modelo cliente-servidor)

Un cliente LDAP envía una solicitud a un servidor LDAP (llamado Directory System Agent, o DSA). El servidor procesa la operación contra su base de datos de directorio y devuelve una respuesta. Las operaciones principales definidas en RFC 4511 incluyen:

• Bind — autenticar un cliente en el directorio
• Search — consultar entradas que coincidan con un filtro
• Compare — verificar si una entrada tiene un valor de atributo específico
• Modify / Add / Delete — operaciones de escritura en entradas del directorio
• Unbind — terminar la sesión

La operación bind es donde ocurre la autenticación. Un cliente envía un DN y credenciales. El servidor las valida y concede o deniega la sesión. La mayoría de las aplicaciones empresariales utilizan LDAP bind para verificar la identidad del usuario antes de conceder acceso.

Puerto LDAP 389 vs. puerto LDAPS 636

LDAP estándar funciona en el puerto TCP 389 y transmite datos en texto plano. Esto significa que las credenciales, incluidas las contraseñas, viajan por la red sin cifrar. En cualquier entorno donde el tráfico de red pueda ser interceptado (que es cualquier entorno) esto es inaceptable.

LDAPS (LDAP sobre SSL/TLS) funciona en el puerto TCP 636 y envuelve toda la sesión LDAP en TLS, cifrando todo el tráfico incluyendo las credenciales de bind. Una tercera opción, StartTLS, actualiza una conexión existente del puerto 389 a TLS a mitad de sesión, pero introduce complejidad en la negociación y es más propenso a errores de configuración.

Microsoft ha estado exigiendo progresivamente la vinculación de canal LDAP y la firma LDAP desde 2020, con aplicación reforzada en actualizaciones posteriores de Windows Server. Ejecutar LDAP sin cifrar en el puerto 389 en producción es una brecha de seguridad. El puerto 636 es el valor predeterminado correcto.

LDAP vs. Active Directory: ¿Cuál es la diferencia?

Active Directory (AD) no es un reemplazo de LDAP — es un servicio de directorio que utiliza LDAP como uno de sus protocolos de acceso. Confundir los dos es uno de los conceptos erróneos más comunes en TI empresarial. La dependencia solo va en una dirección: LDAP funciona de forma independiente, AD no.

¿Se puede ejecutar LDAP sin AD?

Sí. LDAP es un protocolo — define cómo un cliente solicita información a un servidor de directorio y cómo ese servidor responde. Se puede implementar independientemente de cualquier software de Microsoft.

OpenLDAP es la implementación de código abierto más utilizada. 389 Directory Server y Apache Directory Server son alternativas comunes. Estos servidores independientes almacenan identidades de usuarios y membresías de grupos y los sirven a sistemas Linux/Unix, servidores de correo y aplicaciones personalizadas.

¿Se puede ejecutar AD sin LDAP?

No. Active Directory es un servicio de directorio completo construido por Microsoft sobre el modelo de datos X.500. Los controladores de dominio utilizan LDAP internamente para leer, escribir y replicar datos del directorio: usuarios, equipos, políticas de grupo. Cualquier aplicación de terceros o máquina que no sea Windows que se autentique contra AD lo hace hablando LDAP.

Si se elimina LDAP, AD no puede comunicarse con el resto de la infraestructura.

Cómo se relacionan en la práctica

Cuando un servidor Linux se autentica contra Active Directory, habla LDAP. Cuando una estación de trabajo Windows inicia sesión, utiliza Kerberos. AD soporta ambos — pero LDAP es lo que hace que AD sea accesible para el resto de la infraestructura.

Alternativas modernas: LDAP vs. SAML, OAuth y OpenID Connect

LDAP fue diseñado para la autenticación de red interna — consultar un directorio dentro de un perímetro corporativo. Los protocolos que le siguieron fueron diseñados para un mundo diferente: identidad federada a través de límites organizacionales, aplicaciones web y clientes móviles.

Estos protocolos no reemplazan a LDAP — operan en una capa diferente. SAML y OpenID Connect manejan SSO basado en navegador. LDAP maneja búsquedas de directorio y autenticación de aplicaciones para sistemas que no pueden hablar SAML. La mayoría de los entornos empresariales ejecutan todos ellos simultáneamente.

¿Sigue siendo relevante LDAP en 2026? (la realidad de la nube híbrida)

LDAP sigue siendo el protocolo de autenticación empresarial dominante, presente en aproximadamente el 90% de las organizaciones en todo el mundo a través de sus implementaciones de Active Directory. La adopción de la nube no ha cambiado esto.

La mayoría de las empresas no son completamente nativas de la nube. Ejecutan un modelo híbrido: algunas cargas de trabajo en Azure o AWS, otras en las instalaciones, con Active Directory como ancla de identidad para ambos. Microsoft Entra ID (anteriormente Azure AD) se conecta al AD local a través de sincronización, pero el AD local (y por lo tanto LDAP) sigue siendo la fuente autorizada para muchas decisiones de identidad.

El rol de LDAP en la arquitectura de confianza cero

La confianza cero requiere verificación continua: cada solicitud de acceso debe ser autenticada y autorizada, independientemente de la ubicación en la red. LDAP se encuentra en una intersección crítica en este modelo porque a menudo es el sistema que responde a esas solicitudes de verificación.

El desafío es que LDAP no fue diseñado con los principios de confianza cero en mente. Asume proximidad de red, utiliza conexiones persistentes y en su forma sin cifrar expone credenciales en tránsito. Adaptar LDAP a una arquitectura de confianza cero requiere controles compensatorios:

• LDAPS obligatorio
• reglas de firewall estrictas
• limitar qué sistemas pueden alcanzar el puerto 636
• aplicación de firma LDAP
• monitorización de intentos de bind para detectar patrones anómalos

LDAP no rompe la confianza cero pero requiere un endurecimiento deliberado para soportarla. Las organizaciones que tratan LDAP como un componente heredado y lo dejan sin configurar están creando exactamente el tipo de confianza implícita que la confianza cero está diseñada para eliminar.

DevOps y gestión de secretos en CI/CD

Los pipelines automatizados presentan un desafío específico de LDAP. Los sistemas CI/CD (Jenkins, GitLab CI, ejecutores de GitHub Actions) a menudo necesitan autenticarse contra LDAP para acceder a recursos internos. Esa autenticación típicamente implica una cuenta de servicio: un DN de bind LDAP dedicado con una contraseña estática.

Las credenciales estáticas de cuentas de servicio son un riesgo persistente. Rara vez se rotan, a menudo se comparten entre pipelines, y cuando aparecen en registros de compilación o archivos de configuración, son difíciles de detectar y revocar. La respuesta es gestionar estas credenciales a través de un gestor de secretos dedicado en lugar de codificarlas en la configuración del pipeline.

Riesgos críticos de seguridad de LDAP en 2026

LDAP no es solo un protocolo heredado con riesgos teóricos. Es una superficie de ataque activa con vulnerabilidades documentadas y explotadas.

La amenaza del robo de credenciales y ransomware

Según el X-Force Threat Intelligence Index 2026 de IBM, la recolección de credenciales fue el impacto de ataque más común observado en 2025. Los actores de amenazas recolectaron datos de inicio de sesión mediante phishing e infostealers, luego se mezclaron en flujos de autenticación normales para moverse lateralmente. Las credenciales de cuentas de servicio LDAP encajan precisamente en este patrón: reutilizadas entre aplicaciones, rara vez rotadas y casi nunca monitorizadas para detectar actividad de bind anómala.

La cadena de ataque está bien documentada: comprometer una credencial LDAP a través de phishing o password spraying, usarla para enumerar el directorio, identificar cuentas privilegiadas y escalar. El Digital Defense Report de Microsoft ha vinculado consistentemente el compromiso de credenciales AD/LDAP con el despliegue de ransomware. El directorio es un mapa de toda la estructura de acceso de la organización, y los atacantes lo leen antes de actuar.

Vulnerabilidades recientes: CVE-2025-26663 y CVE-2025-54918

Dos vulnerabilidades críticas divulgadas en 2025 demuestran que la superficie de ataque de LDAP se está expandiendo activamente.

CVE-2025-26663 es una vulnerabilidad de ejecución remota de código use-after-free en Windows LDAP, divulgada en abril de 2025. Un atacante puede explotar un fallo de gestión de memoria en el servicio LDAP de Windows (específicamente en wldap32.dll) para ejecutar código arbitrario en un servidor objetivo sin credenciales válidas.

El ataque solo requiere acceso de red al servicio LDAP. Los controladores de dominio, que exponen LDAP por diseño, son los objetivos principales. Los controladores de dominio sin parchear que ejecutan esta vulnerabilidad están efectivamente abiertos a Ejecución Remota de Código (RCE) no autenticada desde cualquier sistema que pueda alcanzar el puerto 389 o 636.

CVE-2025-54918, divulgada en septiembre de 2025, es una vulnerabilidad de escalada de privilegios que combina retransmisión NT LAN Manager con autenticación forzada para eludir las protecciones de vinculación de canal y firma LDAP. Un atacante con una cuenta de dominio de bajo privilegio puede forzar a un controlador de dominio a autenticarse en un sistema controlado por el atacante, manipular los paquetes de autenticación NTLM en tránsito y retransmitir la autenticación modificada de vuelta al controlador de dominio — logrando acceso de nivel SYSTEM. El ataque es particularmente peligroso porque elude controles en los que las organizaciones comúnmente confían como medidas de endurecimiento.

Mejores prácticas para asegurar LDAP en la empresa

La siguiente lista de verificación cubre los controles mínimos para una implementación LDAP en producción. Estas son recomendaciones que abordan un vector de ataque específico y documentado.

1. Aplicar LDAPS en el puerto 636. Deshabilitar LDAP en texto plano en el puerto 389 para todo el tráfico de producción. Configurar certificados TLS de su CA interna o una CA pública de confianza.
2. Habilitar firma LDAP y vinculación de canal. Previene ataques de retransmisión. Requerido para la mitigación de CVE-2025-54918 — aunque tenga en cuenta que CVE-2025-54918 elude estos controles en sistemas sin parchear, por lo que el parcheo sigue siendo obligatorio.
3. Aplicar todas las actualizaciones de seguridad de Windows. CVE-2025-26663 y CVE-2025-54918 tienen parches. Los controladores de dominio sin parchear son el elemento de remediación de mayor prioridad.
4. Restringir el acceso LDAP por IP. Solo los sistemas que legítimamente necesitan consultar LDAP deberían poder alcanzar el puerto 636. Las reglas de firewall deberían aplicar esto, no solo las suposiciones de segmentación de red.
5. Auditar credenciales de cuentas de servicio. Identificar cada DN de bind en uso en su entorno. Rotar contraseñas según un calendario. Eliminar cuentas que ya no se necesitan.
6. Monitorizar intentos de bind. Patrones de bind inusuales — fallos repetidos, binds desde IPs de origen inesperadas, binds a horas inusuales — son indicadores tempranos de credential stuffing o movimiento lateral.
7. Deshabilitar binds LDAP anónimos. Las consultas anónimas permiten la enumeración no autenticada del contenido del directorio. La mayoría de las implementaciones modernas no tienen un uso legítimo para binds anónimos.
8. Separar cuentas de servicio por función. Una cuenta de servicio utilizada por una VPN no debería tener los mismos permisos que una utilizada por un sistema de respaldo. El principio de mínimo privilegio también aplica a las cuentas de bind LDAP.

Optimizando el acceso empresarial con la integración LDAP de Passwork

La carga operativa de la gestión de acceso basada en LDAP se acumula con el tiempo. Los usuarios cambian de equipo, se unen a proyectos y abandonan la organización, y cada transición requiere cambios de acceso en múltiples sistemas. Cuando esos cambios son manuales, se retrasan. Las cuentas permanecen activas más tiempo del debido. Las credenciales se acumulan en lugares que nadie está rastreando.

Passwork se conecta directamente a Active Directory o cualquier directorio compatible con LDAP y mapea la membresía de grupos al acceso a bóvedas automáticamente:

• Añadir un usuario al grupo SRE en AD — las credenciales correctas aparecen en su bóveda de Passwork, sin necesidad de acción administrativa separada
• Eliminarlo del grupo — el acceso se revoca
• El directorio permanece como la única fuente de verdad para quién tiene acceso a qué

Para entornos autoalojados, Passwork se implementa completamente dentro de su propio perímetro. Las credenciales nunca lo abandonan. SSO SAML está soportado junto con LDAP, por lo que los equipos que usan ambos protocolos para diferentes capas de aplicación no necesitan reconstruir su arquitectura de identidad.

Cada lectura, escritura, compartición y exportación se registra en el registro de auditoría — relevante tanto para revisiones de seguridad internas como para demostrar cumplimiento con SOC 2 CC6.1 y GDPR Artículo 32.

Conclusión

LDAP no va a desaparecer. El mercado de software de directorio se valoró en 8,4 mil millones de dólares en 2025 y se proyecta que alcanzará los 19,7 mil millones de dólares para 2034, según la investigación de mercado de Dataintelo — una cifra que refleja la inversión empresarial continua en infraestructura de directorio, no una tecnología en declive. Con el 90% de las empresas todavía ejecutando Active Directory, LDAP sigue siendo el tejido conectivo de la gestión de identidad corporativa.

Lo que ha cambiado es el entorno de amenazas. CVE-2025-26663 y CVE-2025-54918 son vulnerabilidades activamente parcheadas que apuntan a los servicios LDAP que sus controladores de dominio exponen ahora mismo.

La acción práctica es sencilla: aplicar LDAPS, parchear los controladores de dominio, auditar las credenciales de cuentas de servicio y asegurarse de que los cambios de acceso en el directorio se propaguen automáticamente a los sistemas que dependen de él. La gestión manual de acceso a la escala a la que operan la mayoría de las empresas es donde aparecen las brechas.

Preguntas frecuentes sobre LDAP

¿Para qué se utiliza LDAP?

LDAP se utiliza para autenticar usuarios y buscar información de directorio — membresías de grupos, direcciones de correo electrónico, atributos de cuentas — en aplicaciones empresariales. Los casos de uso comunes incluyen autenticación VPN, búsqueda de usuarios en servidores de correo, SSO de aplicaciones y gestión centralizada de usuarios. La mayoría de las aplicaciones empresariales que necesitan verificar identidad contra un directorio corporativo utilizan LDAP.

¿Cuál es la diferencia entre LDAP y Active Directory?

LDAP es un protocolo abierto (RFC 4511) para acceder a servicios de directorio. Active Directory es el servicio de directorio de Microsoft, que utiliza LDAP como uno de sus protocolos de acceso. AD también utiliza Kerberos para la autenticación de Windows. Se puede usar LDAP sin Active Directory (a través de OpenLDAP, por ejemplo), pero Active Directory depende de LDAP para servir consultas de directorio a aplicaciones que no son de Windows.

¿Qué es LDAPS y por qué es importante?

LDAPS es LDAP sobre TLS, funcionando en el puerto 636. LDAP estándar en el puerto 389 transmite credenciales en texto plano, haciéndolas visibles para cualquiera que pueda interceptar el tráfico de red. LDAPS cifra toda la sesión. En 2026, ejecutar LDAP sin cifrar en producción es indefendible — Microsoft ha estado aplicando requisitos de firma LDAP y vinculación de canal desde 2020, y tanto CVE-2025-26663 como CVE-2025-54918 apuntan directamente a servicios LDAP.

¿Todavía se usa LDAP en 2026?

Sí. Active Directory, que depende de LDAP, está implementado en aproximadamente el 90% de las empresas en todo el mundo. La adopción de la nube no lo ha desplazado — la mayoría de las organizaciones ejecutan entornos híbridos donde el AD local sigue siendo la fuente de identidad autorizada. LDAP también está integrado en miles de aplicaciones que se autentican contra directorios empresariales y no será reemplazado por SAML u OAuth sin una reingeniería significativa.

¿Cómo encaja LDAP en una arquitectura de confianza cero?

LDAP puede soportar la confianza cero si se endurece correctamente. La confianza cero requiere verificación continua de cada solicitud de acceso, y LDAP a menudo es el sistema que responde a esas solicitudes. Los requisitos: aplicar LDAPS (puerto 636), habilitar firma y vinculación de canal, restringir el acceso al directorio por IP de origen, monitorizar intentos de bind y rotar credenciales de cuentas de servicio regularmente. La configuración predeterminada de LDAP no es compatible con la confianza cero — pero el protocolo en sí no es el obstáculo.

¿Cuáles son los principales riesgos de seguridad con LDAP?

Los riesgos principales son la exposición de credenciales a través de conexiones sin cifrar (puerto 389), robo de credenciales de cuentas de servicio, ataques de retransmisión NTLM (CVE-2025-54918) y RCE no autenticado a través de vulnerabilidades de corrupción de memoria (CVE-2025-26663). El X-Force Threat Intelligence Index 2025 de IBM encontró que los ataques basados en identidad — muchos dirigidos a credenciales de directorio — representaron el 30% de todas las intrusiones en 2024. El parcheo, la aplicación de LDAPS y la higiene de cuentas de servicio abordan la mayoría de estos riesgos.

¿Puede LDAP ser reemplazado por SAML u OAuth?

No completamente. SAML y OAuth manejan la autenticación federada basada en navegador y la autorización de API respectivamente. LDAP maneja búsquedas de directorio y autenticación de aplicaciones para sistemas que no pueden hablar SAML. La mayoría de los entornos empresariales ejecutan los tres protocolos para diferentes capas de su stack de aplicaciones. La pregunta no es cuál elegir — es qué aplicaciones requieren LDAP y si esas conexiones están debidamente aseguradas.

Shadow IT vs Shadow AI: Por qué la IA es la mayor amenaza

Los empleados están usando herramientas de IA que usted no aprobó, en cuentas que no puede monitorizar, con datos que no puede recuperar. Aquí está cómo se ve realmente el riesgo y qué necesita abordar la gobernanza.

Passwork BlogAlex Muntyan

Compartir contraseñas de forma insegura: Riesgos y soluciones seguras en 2026

Cada vez que una credencial viaja por Slack o correo electrónico, se pierde responsabilidad, registro de auditoría y postura de cumplimiento en un solo paso. Esta guía cubre los riesgos reales de compartir contraseñas de forma insegura en 2026, por qué los empleados lo hacen de todos modos, y cómo migrar a acceso mediado por bóveda sin interrumpir a su equipo.

Passwork BlogAlex Muntyan

Passwork gana Top Performer Primavera 2026 en SourceForge

Passwork ha sido nombrado Top Performer Primavera 2026 por SourceForge, clasificándose en el 10% superior de más de 100.000 soluciones. La insignia se basa completamente en reseñas verificadas — 4,8 estrellas en general, con un 5,0 perfecto para soporte.

Passwork BlogAlex Muntyan

LDAP (Lightweight Directory Access Protocol) is a client-server protocol for reading and writing directory services over a network. Defined in RFC 4511, it gives applications a standard way to query a directory — asking questions like "does this user exist?", "what groups do they belong to?", and "what resources can they access?"

Despite being first standardized in the early 1990s, LDAP remains the backbone of enterprise identity infrastructure in 2026. Active Directory, which runs on LDAP, is still deployed at approximately 90% of organizations worldwide.

Key takeaways

• LDAP is a protocol. It defines how applications query a directory — user accounts, group memberships, access rights. Active Directory implements it, but LDAP runs independently on OpenLDAP and other servers without any Microsoft software.
• AD cannot function without LDAP. Every non-Windows system that authenticates against Active Directory does so over LDAP. Remove it, and AD loses the ability to serve third-party applications, network devices, and Linux infrastructure.
• Port 389 is not acceptable in production. Standard LDAP transmits credentials in plaintext. LDAPS on port 636 encrypts the entire session. Microsoft has been enforcing signing and channel binding requirements since 2020.
• Two critical vulnerabilities were patched in 2025. CVE-2025-26663 allows unauthenticated remote code execution on domain controllers via a memory flaw in the Windows LDAP service. CVE-2025-54918 bypasses channel binding and signing protections through NTLM relay. Both have patches — unpatched domain controllers are the highest-priority remediation item.
• LDAP and modern protocols are not alternatives. SAML handles browser-based SSO. OAuth handles API authorization. LDAP handles directory lookups for systems that speak neither. Most enterprise environments run all three simultaneously.
• Manual access management creates gaps. When AD group changes don't propagate automatically to dependent systems, accounts stay active longer than they should. Synchronizing credential access to directory group membership eliminates that lag.

Understanding LDAP: The basics

LDAP is a standard protocol for accessing and managing distributed directory information services. It operates on a hierarchical data model derived from the X.500 standard and allows clients to authenticate users, look up attributes, and retrieve group memberships from a central directory. Organizations use it to answer one fundamental question at scale: who is allowed to do what, and where?

The data LDAP organizes sits in a Directory Information Tree (DIT) — a hierarchical structure of entries, each identified by a Distinguished Name (DN). A typical DN looks like this:

Copycn=jane.doe,ou=engineering,dc=company,dc=com

Each entry holds attributes: a user entry might contain mail, uid, memberOf, and userPassword. Applications query these attributes to make authentication and authorization decisions.

How does LDAP work? (client-server model)

An LDAP client sends a request to an LDAP server (called a Directory System Agent, or DSA). The server processes the operation against its directory database and returns a response. Core operations defined in RFC 4511 include:

• Bind — authenticate a client to the directory
• Search — query entries matching a filter
• Compare — check whether an entry has a specific attribute value
• Modify / Add / Delete — write operations on directory entries
• Unbind — terminate the session

The bind operation is where authentication happens. A client sends a DN and credentials. The server validates them and either grants or denies the session. Most enterprise applications use LDAP bind to verify user identity before granting access.

LDAP port 389 vs. LDAPS port 636

Standard LDAP runs on TCP port 389 and transmits data in plaintext. That means credentials, including passwords, travel across the network unencrypted. In any environment where network traffic could be intercepted (which is every environment) this is unacceptable.

LDAPS (LDAP over SSL/TLS) runs on TCP port 636 and wraps the entire LDAP session in TLS, encrypting all traffic including bind credentials. A third option, StartTLS, upgrades an existing port 389 connection to TLS mid-session, but it introduces negotiation complexity and is more error-prone to configure correctly.

Microsoft has been progressively mandating LDAP channel binding and LDAP signing since 2020, with enforcement tightened in subsequent Windows Server updates. Running unencrypted LDAP on port 389 in production is a security gap. Port 636 is the correct default.

LDAP vs. Active Directory: What's the difference?

Active Directory (AD) is not a replacement for LDAP — it is a directory service that uses LDAP as one of its access protocols. Conflating the two is one of the most common misconceptions in enterprise IT. The dependency only runs one way: LDAP stands alone, AD does not.

Can you run LDAP without AD?

Yes. LDAP is a protocol — it defines how a client asks a directory server for information and how that server responds. You can deploy it independently of any Microsoft software.

OpenLDAP is the most widely used open-source implementation. 389 Directory Server and Apache Directory Server are common alternatives. These standalone servers store user identities and group memberships and serve them to Linux/Unix systems, mail servers, and custom applications.

Can you run AD without LDAP?

No. Active Directory is a full directory service built by Microsoft on top of the X.500 data model. Domain controllers use LDAP internally to read, write, and replicate directory data: users, computers, group policies. Any third-party application or non-Windows machine that authenticates against AD does so by speaking LDAP to it.

Remove LDAP, and AD cannot communicate with the rest of your infrastructure.

How they relate in practice

When a Linux server authenticates against Active Directory, it speaks LDAP. When a Windows workstation logs in, it uses Kerberos. AD supports both — but LDAP is what makes AD accessible to the rest of your infrastructure.

Modern alternatives: LDAP vs. SAML, OAuth, and OpenID Connect

LDAP was designed for internal network authentication — querying a directory inside a corporate perimeter. The protocols that followed it were designed for a different world: federated identity across organizational boundaries, web applications, and mobile clients.

These protocols do not replace LDAP — they operate at a different layer. SAML and OpenID Connect handle browser-based SSO. LDAP handles directory lookups and application authentication for systems that cannot speak SAML. Most enterprise environments run all of them simultaneously.

Is LDAP still relevant in 2026? (the hybrid cloud reality)

LDAP is still the dominant enterprise authentication protocol, present in approximately 90% of organizations worldwide through their Active Directory deployments. Cloud adoption has not changed this.

Most enterprises are not fully cloud-native. They run a hybrid model: some workloads in Azure or AWS, others on-premises, with Active Directory as the identity anchor for both. Microsoft Entra ID (formerly Azure AD) connects to on-premises AD through synchronization, but the on-premises AD (and therefore LDAP) remains the authoritative source for many identity decisions.

The role of LDAP in zero trust architecture

Zero trust requires continuous verification: every access request must be authenticated and authorized, regardless of network location. LDAP sits at a critical junction in this model because it is often the system that answers those verification requests.

The challenge is that LDAP was not designed with zero trust principles in mind. It assumes network adjacency, uses persistent connections, and in its unencrypted form exposes credentials in transit. Fitting LDAP into a zero trust architecture requires compensating controls:

• mandatory LDAPS
• strict firewall rules
• limiting which systems can reach port 636
• LDAP signing enforcement
• monitoring of bind attempts for anomalous patterns

LDAP does not break zero trust but it requires deliberate hardening to support it. Organizations that treat LDAP as a legacy component and leave it unconfigured are creating exactly the kind of implicit trust that zero trust is designed to eliminate.

DevOps and CI/CD secrets management

Automated pipelines present a specific LDAP challenge. CI/CD systems (Jenkins, GitLab CI, GitHub Actions runners) often need to authenticate against LDAP to access internal resources. That authentication typically involves a service account: a dedicated LDAP bind DN with a static password.

Static service account credentials are a persistent risk. They rarely rotate, they are often shared across pipelines, and when they appear in build logs or configuration files, they are difficult to detect and revoke. The answer is to manage these credentials through a dedicated secrets manager rather than hardcoding them in pipeline configuration.

Critical LDAP security risks in 2026

LDAP is not just a legacy protocol with theoretical risks. It is an active attack surface with documented, exploited vulnerabilities.

The threat of credential theft and ransomware

According to IBM's X-Force Threat Intelligence Index 2026, credential harvesting was the most common attack impact observed in 2025. Threat actors harvested login data via phishing and infostealers, then blended into normal authentication flows to move laterally. LDAP service account credentials fit this pattern precisely: reused across applications, rarely rotated, and almost never monitored for anomalous bind activity.

The attack chain is well-documented: compromise an LDAP credential through phishing or password spraying, use it to enumerate the directory, identify privileged accounts, and escalate. Microsoft's Digital Defense Report has consistently linked AD/LDAP credential compromise to ransomware deployment. The directory is a map of the entire organization's access structure, and attackers read it before they act.

Recent vulnerabilities: CVE-2025-26663 and CVE-2025-54918

Two critical vulnerabilities disclosed in 2025 demonstrate that LDAP's attack surface is actively expanding.

CVE-2025-26663 is a use-after-free remote code execution vulnerability in Windows LDAP, disclosed in April 2025. An attacker can exploit a memory management flaw in the Windows LDAP service (specifically in wldap32.dll) to execute arbitrary code on a target server without valid credentials.

The attack requires only network access to the LDAP service. Domain controllers, which expose LDAP by design, are the primary targets. Unpatched domain controllers running this vulnerability are effectively open to unauthenticated Remote Code Execution (RCE) from any system that can reach port 389 or 636.

CVE-2025-54918, disclosed in September 2025, is a privilege escalation vulnerability that combines NT LAN Manager relay with coerced authentication to bypass LDAP channel binding and signing protections. An attacker with a low-privileged domain account can coerce a domain controller into authenticating to an attacker-controlled system, manipulate the NTLM authentication packets in transit, and relay the modified authentication back to the domain controller — achieving SYSTEM-level access. The attack is particularly dangerous because it bypasses controls that organizations commonly rely on as hardening measures.

Best practices for securing LDAP in the enterprise

The following checklist covers the minimum controls for a production LDAP deployment. These are recommendations that address a specific, documented attack vector.

1. Enforce LDAPS on port 636. Disable plaintext LDAP on port 389 for all production traffic. Configure TLS certificates from your internal CA or a trusted public CA.
2. Enable LDAP signing and channel binding. Prevents relay attacks. Required for CVE-2025-54918 mitigation — though note that CVE-2025-54918 bypasses these controls on unpatched systems, so patching is still mandatory.
3. Apply all Windows security updates. CVE-2025-26663 and CVE-2025-54918 both have patches. Unpatched domain controllers are the highest-priority remediation item.
4. Restrict LDAP access by IP. Only systems that legitimately need to query LDAP should be able to reach port 636. Firewall rules should enforce this, not just network segmentation assumptions.
5. Audit service account credentials. Identify every bind DN in use across your environment. Rotate passwords on a schedule. Remove accounts that are no longer needed.
6. Monitor bind attempts. Unusual bind patterns — repeated failures, binds from unexpected source IPs, binds at unusual hours — are early indicators of credential stuffing or lateral movement.
7. Disable anonymous LDAP binds. Anonymous queries allow unauthenticated enumeration of directory contents. Most modern deployments have no legitimate use for anonymous binds.
8. Separate service accounts by function. A service account used by a VPN should not have the same permissions as one used by a backup system. Least privilege applies to LDAP bind accounts too.

Streamlining enterprise access with Passwork LDAP integration

The operational burden of LDAP-based access management compounds over time. Users change teams, join projects, and leave the organization and each transition requires access changes across multiple systems. When those changes are manual, they lag. Accounts stay active longer than they should. Credentials accumulate in places no one is tracking.

Passwork connects directly to Active Directory or any LDAP-compatible directory and maps group membership to vault access automatically:

• Add a user to the SRE group in AD — the correct credentials appear in their Passwork vault, no separate admin action required
• Remove them from the group — access is revoked
• The directory stays the single source of truth for who has access to what

For self-hosted environments, Passwork deploys entirely within your own perimeter. Credentials never leave it. SAML SSO is supported alongside LDAP, so teams using both protocols for different application layers don't need to rebuild their identity architecture.

Every read, write, share, and export is recorded in the audit log — relevant both for internal security reviews and for demonstrating compliance with SOC 2 CC6.1 and GDPR Article 32.

Conclusion

LDAP is not going away. The directory software market was valued at $8.4 billion in 2025 and is projected to reach $19.7 billion by 2034, according to Dataintelo's market research — a figure that reflects continued enterprise investment in directory infrastructure, not a technology in decline. With 90% of enterprises still running Active Directory, LDAP remains the connective tissue of corporate identity management.

What has changed is the threat environment. CVE-2025-26663 and CVE-2025-54918 are actively patched vulnerabilities targeting the LDAP services your domain controllers expose right now.

The practical action is straightforward: enforce LDAPS, patch your domain controllers, audit your service account credentials, and make sure access changes in your directory propagate automatically to the systems that depend on it. Manual access management at the scale most enterprises operate is where gaps appear.

Frequently asked questions about LDAP

What is LDAP used for?

LDAP is used to authenticate users and look up directory information — group memberships, email addresses, account attributes — across enterprise applications. Common use cases include VPN authentication, email server user lookup, application SSO, and centralized user management. Most enterprise applications that need to verify identity against a corporate directory use LDAP.

What is the difference between LDAP and Active Directory?

LDAP is an open protocol (RFC 4511) for accessing directory services. Active Directory is Microsoft's directory service, which uses LDAP as one of its access protocols. AD also uses Kerberos for Windows authentication. You can use LDAP without Active Directory (via OpenLDAP, for example), but Active Directory relies on LDAP to serve directory queries to non-Windows applications.

What is LDAPS and why does it matter?

LDAPS is LDAP over TLS, running on port 636. Standard LDAP on port 389 transmits credentials in plaintext, making them visible to anyone who can intercept network traffic. LDAPS encrypts the entire session. In 2026, running unencrypted LDAP in production is indefensible — Microsoft has been enforcing LDAP signing and channel binding requirements since 2020, and both CVE-2025-26663 and CVE-2025-54918 target LDAP services directly.

Is LDAP still used in 2026?

Yes. Active Directory, which relies on LDAP, is deployed at approximately 90% of enterprises worldwide. Cloud adoption has not displaced it — most organizations run hybrid environments where on-premises AD remains the authoritative identity source. LDAP is also embedded in thousands of applications that authenticate against enterprise directories and will not be replaced by SAML or OAuth without significant re-engineering.

How does LDAP fit into a zero trust architecture?

LDAP can support zero trust if hardened correctly. Zero trust requires continuous verification of every access request, and LDAP is often the system answering those requests. The requirements: enforce LDAPS (port 636), enable signing and channel binding, restrict directory access by source IP, monitor bind attempts, and rotate service account credentials regularly. LDAP's default configuration is not zero trust-compatible — but the protocol itself is not the obstacle.

What are the main security risks with LDAP?

The primary risks are credential exposure over unencrypted connections (port 389), service account credential theft, NTLM relay attacks (CVE-2025-54918), and unauthenticated RCE via memory corruption vulnerabilities (CVE-2025-26663). IBM's X-Force Threat Intelligence Index 2025 found that identity-based attacks — many targeting directory credentials — accounted for 30% of all intrusions in 2024. Patching, LDAPS enforcement, and service account hygiene address the majority of these risks.

Can LDAP be replaced by SAML or OAuth?

Not entirely. SAML and OAuth handle browser-based federated authentication and API authorization respectively. LDAP handles directory lookups and application authentication for systems that cannot speak SAML. Most enterprise environments run all three protocols for different layers of their application stack. The question is not which to choose — it is which applications require LDAP and whether those connections are secured properly.

Shadow IT vs Shadow AI: Why AI is the bigger threat

Employees are using AI tools you didn’t approve, on accounts you can’t monitor, with data you can’t recover. Here’s what the risk actually looks like and what governance needs to address.

Passwork BlogAlex Muntyan

Insecure password sharing: 2026 risks and secure solutions

Every time a credential moves through Slack or email, you lose accountability, audit trail, and compliance posture in one step. This guide covers the real risks of insecure password sharing in 2026, why employees do it anyway, and how to migrate to vault-mediated access without disrupting your team.

Passwork BlogAlex Muntyan

Passwork wins Top Performer Spring 2026 on SourceForge

Passwork has been named a Top Performer Spring 2026 by SourceForge, ranking in the top 10% of 100,000+ solutions. The badge is based entirely on verified reviews — 4.8 stars overall, with a perfect 5.0 for support.

Passwork BlogAlex Muntyan

La mayoría de las brechas no comienzan con un ataque sofisticado. Comienzan con una contraseña que alguien usó en dos sitios web diferentes. Según el Informe de Investigaciones de Brechas de Datos 2026 de Verizon, las credenciales robadas aparecieron en algún punto del 39% de todas las brechas confirmadas — no solo como puerta de entrada, sino a lo largo del movimiento lateral, la persistencia y el robo de datos. 

La explotación de vulnerabilidades ha superado a las credenciales como el principal vector de acceso inicial, pero los atacantes no han abandonado el abuso de credenciales. Lo han integrado más profundamente en la cadena de intrusión. Si sus empleados reutilizan contraseñas (y estadísticamente, la mayoría lo hace), su empresa está asumiendo riesgos de reutilización de contraseñas que no se manifiestan hasta que los atacantes ya están dentro.

Puntos clave

• Una sola contraseña reutilizada crea un riesgo sistémico inmediato. Cuando una credencial se filtra de cualquier fuente personal o corporativa, las herramientas automatizadas la prueban en toda su red en cuestión de horas.
• El relleno de credenciales es altamente automatizado e inmediato. Los atacantes ejecutan bases de datos automatizadas de credenciales filtradas contra portales corporativos en cuestión de horas tras una brecha pública.
• El secuestro de sesión elude completamente la autenticación multifactor. Los infostealers roban cookies de sesión activas junto con las contraseñas guardadas en el navegador, permitiendo a los atacantes clonar sesiones legítimas sin activar solicitudes de MFA.
• La rotación forzada de contraseñas debilita la seguridad corporativa. Los cambios obligatorios cada 90 días generan patrones predecibles. Los estándares modernos (incluido NIST SP 800-63B) recomiendan una longitud mínima de 15 caracteres y rotación solo ante un compromiso real.
• Eliminar la reutilización requiere un enfoque estructurado de tres pilares. Las organizaciones deben actualizar políticas obsoletas, realizar auditorías de credenciales para identificar shadow IT y desplegar una bóveda centralizada para que los hábitos seguros sean fáciles de adoptar.
• El control sistémico debe reemplazar la responsabilidad individual. El gestor de contraseñas automatiza la higiene de credenciales escaneando continuamente en busca de duplicados, asegurando cuentas de servicio huérfanas y gestionando el acceso granular de proveedores en una bóveda centralizada.

Por qué la reutilización de contraseñas es peligrosa: el panorama de 2026

La reutilización de contraseñas crea un punto único de fallo en todas las cuentas que comparten la misma credencial. Cuando los atacantes obtienen esa credencial de cualquier fuente (corporativa o personal), las herramientas automatizadas la prueban contra el correo electrónico corporativo, portales VPN y aplicaciones en la nube en cuestión de horas. En 2025, Recorded Future indexó 1.950 millones de exposiciones de credenciales procedentes de malware, de las cuales el 31% incluía cookies de sesión activas que eluden completamente el MFA (autenticación multifactor).

Los delincuentes crean e intercambian combolists: archivos estructurados de pares de correo electrónico/contraseña filtrados, agregados de años de brechas de datos. Las herramientas automatizadas prueban estos pares contra páginas de inicio de sesión corporativas, portales VPN y aplicaciones en la nube en cuestión de horas tras la aparición de una nueva lista en mercados de la dark web. El ataque es mecánico: tomar una lista de credenciales conocidas, ejecutarlas contra una página de inicio de sesión y recopilar los aciertos.

Los infostealers son el canal más rápido y peligroso. Este malware se ejecuta silenciosamente en un dispositivo infectado, extrae todas las contraseñas guardadas del navegador, recopila las cookies de sesión activas y exfiltra el paquete — a menudo en cuestión de minutos. Si el atacante tiene un token de sesión válido, no se dispara ningún evento de inicio de sesión, no aparece ninguna solicitud de MFA y el acceso parece completamente legítimo.

El volumen en 2025 fue asombroso. El Informe de Panorama de Amenazas de Identidad 2025 de Recorded Future (publicado en marzo de 2026) detectó 1.950 millones de exposiciones de credenciales de combolists de malware a lo largo del año, con un volumen acelerándose drásticamente — el último trimestre produjo un 90% más de credenciales indexadas que el primero. El Informe de Brechas de Identidad 2026 de Constella Intelligence encontró que casi el 60% de los conjuntos de datos de brechas ingeridos eran compilaciones de credenciales recicladas — un aumento respecto al año anterior.

Un detalle de los datos de Recorded Future merece atención: 276 millones de las credenciales indexadas en 2025 incluían cookies de sesión activas. Eso es el 31% de las credenciales procedentes de malware eludiendo completamente el MFA, por diseño. La reutilización de contraseñas es peligrosa. La reutilización de credenciales combinada con el secuestro de sesión es una categoría diferente de problema.

11 riesgos de reutilización de contraseñas que toda empresa debe conocer

La reutilización de contraseñas crea una cadena de vulnerabilidades. Cada riesgo a continuación es independiente, pero en una intrusión real se combinan. Un atacante que explota el riesgo #1 a menudo obtiene la posición para explotar los riesgos #3, #7 y #11 en la misma sesión.

1. Los ataques de inicio de sesión automatizados alcanzan todas las cuentas a la vez

Cuando una contraseña aparece en una brecha, los atacantes la ejecutan contra el correo electrónico de su empresa, el sistema de recursos humanos, el almacenamiento en la nube y el portal VPN simultáneamente. Esto es relleno de credenciales — completamente automatizado, ejecutándose a escala en cuestión de horas tras la aparición de una nueva combolist. Según la investigación adicional del DBIR 2025 de Verizon sobre relleno de credenciales, la proporción diaria mediana de relleno de credenciales en los registros de proveedores de SSO fue del 19% de todos los intentos de autenticación. Casi uno de cada cinco intentos de inicio de sesión, en un día promedio.

2. Una brecha en un dispositivo personal se convierte en su problema

Si el portátil doméstico de un empleado recibe malware infostealer (a través de un enlace de phishing o una descarga comprometida), todas las contraseñas guardadas en su navegador son robadas. Si alguna de esas contraseñas coincide con la que usan en el trabajo, sus sistemas ahora están expuestos. Usted no tuvo participación en esa brecha. Aun así, asume las consecuencias.

El Informe Anual de Exposición de Identidad 2025 de SpyCloud encontró que el 91% de las organizaciones informaron haber sufrido un incidente relacionado con la identidad en el último año — casi el doble de las cifras del año anterior — siendo el malware infostealer un impulsor principal. La infección no necesita ocurrir en una máquina de la empresa para convertirse en un problema de la empresa.

3. Una contraseña abre muchas puertas

Dentro de una empresa, los sistemas están conectados. Un atacante que accede a una cuenta con una contraseña reutilizada puede usar esa misma credencial para sondear otros sistemas internos. Lo que comienza como acceso a una sola cuenta de empleado puede expandirse a servidores de archivos, herramientas internas o consolas de administrador. Para cuando se detecta, el atacante ha estado dentro durante semanas.

4. Las aplicaciones no rastreadas crean puertas traseras ocultas

Los empleados se registran en herramientas por su cuenta (gestores de proyectos, plataformas de diseño, aplicaciones de comunicación) usando su correo electrónico del trabajo y, a menudo, una contraseña que también usan en el trabajo. TI no sabe que estas cuentas existen. Cuando una de esas aplicaciones sufre una brecha, el atacante tiene una credencial funcional para sus sistemas corporativos, a través de una puerta que nadie sabía que estaba abierta.

Esto es shadow IT, y es uno de los riesgos de reutilización de contraseñas más difíciles de gestionar porque la exposición ocurre completamente fuera de su visibilidad.

5. La autenticación de dos factores no siempre le salvará

2FA vale la pena tenerlo. No es una solución completa para la reutilización de contraseñas. Los atacantes interceptan el proceso de autenticación en tiempo real, capturando tanto la contraseña como el token de sesión temporal que demuestra que la verificación de 2FA ya se ha completado. Una vez que tienen ese token, están dentro — y 2FA ya ha cumplido su función en lo que respecta al sistema.

2FA reduce el riesgo significativamente. Una contraseña reutilizada sigue dando a los atacantes un punto de partida con el que pueden trabajar, y el secuestro de sesión elimina completamente el MFA de la ecuación.

6. Las contraseñas reutilizadas pueden hacer que falle su próxima auditoría

Si su empresa maneja datos de pago, información personal u opera bajo cualquier marco de seguridad formal, las prácticas de contraseñas son examinadas. Los estándares de seguridad como SOC 2, ISO 27001 y PCI DSS requieren que los controles de acceso se gestionen adecuadamente — y los auditores verifican si su organización aplica calidad en las contraseñas. Encontrar reutilización generalizada de contraseñas es una señal de alerta que puede resultar en hallazgos de auditoría, certificaciones fallidas o brechas de cumplimiento que necesitan remediación formal antes de poder cerrar un trato o renovar un contrato.

7. El acceso de proveedores es parte de su superficie de ataque

Los contratistas y proveedores externos a menudo necesitan acceso a sus sistemas. Si esas credenciales se comparten descuidadamente — o si el propio personal del proveedor reutiliza contraseñas — una brecha en el proveedor se convierte en una brecha en su organización. El DBIR 2026 de Verizon encontró que el 48% de las brechas involucraron a un tercero en alguna capacidad, un aumento del 60% respecto al año anterior. Las cuentas de proveedores frecuentemente se olvidan después de que termina un proyecto. El acceso permanece activo, la contraseña nunca cambia y nadie la supervisa.

8. Los empleados también reutilizan contraseñas de sistemas

Las cuentas de servicio y las credenciales de sistema reciben mucha menos atención que las cuentas de empleados. Un desarrollador que gestiona tres entornos de base de datos con la misma contraseña no aparecerá en ninguna lista de baja de recursos humanos. Nadie es propietario de esa credencial, por lo que nadie la audita. Cuando un entorno se ve comprometido, cada sistema que comparte esa credencial queda expuesto.

Estas cuentas no aparecen en un directorio de empleados estándar. Ninguna persona individual es propietaria de ellas. Ese es el hueco por el que caminan los atacantes.

9. Las cuentas de trabajo y personales se contaminan mutuamente

La línea entre las contraseñas personales y profesionales se ha difuminado casi por completo. Según el Informe Anual de Exposición de Identidad 2025 de SpyCloud, el 70% de los usuarios expuestos en brechas reutilizaron contraseñas previamente expuestas en múltiples cuentas. SpyCloud describe esto como una tasa histórica — lo que significa que refleja el comportamiento de reutilización acumulativo a través de cada brecha en su conjunto de datos, no una instantánea de un solo año. Un empleado que usa su contraseña de trabajo en una cuenta personal expone a la empresa cuando esa cuenta personal sufre una brecha. Lo contrario es igualmente cierto.

Los datos de SpyCloud también muestran que las exposiciones procedentes de infostealers mezclan cada vez más datos de identidad personal y corporativa del mismo dispositivo, haciendo que el límite personal/profesional sea funcionalmente irrelevante para un atacante que ya tiene la credencial.

10. Los cambios de contraseña forzados son contraproducentes

Muchas empresas todavía requieren que los empleados cambien las contraseñas cada 90 días. El resultado suele ser que Password123! se convierte en Password124! — un cambio que satisface la política sin proporcionar protección real. Las personas hacen el cambio más pequeño posible para que desaparezca el recordatorio.

NIST SP 800-63B-4 (2025) recomienda no hacer rotación periódica obligatoria exactamente por esta razón. Los cambios forzados producen patrones predecibles. El estándar requiere un mínimo de 15 caracteres para contraseñas elegidas por el usuario cuando la contraseña es el único autenticador, y recomienda rotación solo ante evidencia de compromiso — no según un calendario.

11. Las credenciales robadas son difíciles de detectar

Cuando un atacante usa una contraseña de empleado real y válida, su actividad parece comportamiento normal de usuario. No se dispara ninguna alarma, no se bloquea ningún inicio de sesión, no aparece ninguna señal obvia de que algo está mal. Pueden permanecer dentro de sus sistemas durante semanas — leyendo correos electrónicos, accediendo a archivos, mapeando su estructura interna — antes de que alguien lo note. Según el Informe de Costo de una Brecha de Datos 2025 de IBM, las organizaciones tardaron una media de 158 días en identificar una brecha — y otros 83 días en contenerla, para un ciclo de vida total de 241 días, un mínimo de nueve años pero aún tiempo suficiente para que un atacante con una credencial válida cause daños graves.

Cómo alejar a su equipo de la reutilización de contraseñas

Cambiar los hábitos de contraseñas en un equipo no ocurre enviando un documento de política. Requiere eliminar la fricción que hace que la reutilización parezca necesaria en primer lugar. La estructura a continuación (la Estrategia de Defensa de Contraseñas de 3 Pilares: Política, Auditoría y Bóveda) aborda cada capa donde la reutilización echa raíces.

Pilar 1 — Política: cambie las reglas, no solo los recordatorios.

Elimine el requisito de rotación cada 90 días. Siga en su lugar las directrices NIST SP 800-63B: requiera contraseñas de al menos 15 caracteres, verifique las nuevas contraseñas contra listas de brechas conocidas y deje de aplicar reglas de complejidad que solo producen patrones como Summer2026!. Comunique el cambio a su equipo con una razón clara — «estamos eliminando la rotación forzada porque estaba produciendo contraseñas predecibles, no seguras». Las personas siguen las reglas que entienden.

Pilar 2 — Auditoría: descubra con qué está tratando realmente.

Antes de poder solucionar el problema, necesita mapearlo. En esta etapa, no está auditando contraseñas — está auditando la superficie de ataque. Obtenga una lista de cada sistema, aplicación y servicio al que accede su equipo. Verifique su directorio AD/LDAP en busca de cuentas activas, cuentas obsoletas y credenciales compartidas. Identifique dónde SSO ya cubre la autenticación y dónde no. El resultado es una imagen clara: cuántas contraseñas separadas está gestionando realmente su equipo y qué sistemas conllevan más riesgo si esas credenciales se ven comprometidas.

Este es el trabajo preparatorio para el Pilar 3. Una vez que el gestor de contraseñas está desplegado, ejecuta el segundo paso — escaneando en busca de contraseñas débiles, duplicadas u obsoletas en todo lo que está fuera de SSO. Ahí es cuando emerge la imagen completa.

Pilar 3 — Bóveda: haga que la opción segura sea la opción fácil.

Despliegue un gestor de contraseñas con uso obligatorio para cada cuenta fuera de SSO. El objetivo es hacer que la opción segura sea la predeterminada. Cuando la herramienta genera y completa credenciales automáticamente, la reutilización deja de ser una opción. Despliegue equipo por equipo, comenzando con los grupos que tienen acceso a los sistemas más sensibles. Acompáñelo con una breve sesión de incorporación, no con un extenso documento de formación.

Cómo Passwork aborda la reutilización de contraseñas a nivel organizacional

Gestionar la reutilización de contraseñas requiere la transición de la responsabilidad individual al control sistémico. La tabla a continuación describe cómo Passwork mitiga los principales riesgos de reutilización de contraseñas identificados en esta guía.

El panel de auditoría de seguridad de Passwork escanea cada bóveda continuamente. Las credenciales débiles y obsoletas aparecen automáticamente — no se requiere verificación manual. Los administradores obtienen una vista consolidada de todos los equipos y cuentas. Esa es la capa de visibilidad que hace que una auditoría de credenciales funcione a escala.

El control de acceso basado en roles (RBAC) significa que las contraseñas se comparten a través de la bóveda, no a través de mensajes de chat o hilos de correo electrónico. Cuando un miembro del equipo se une a un proyecto, obtiene acceso a las credenciales relevantes automáticamente. Cuando se va, el acceso se revoca en un solo paso. No hay que buscar a qué carpetas compartidas todavía tiene acceso.

Para organizaciones con requisitos estrictos de residencia de datos o cumplimiento, Passwork está disponible como despliegue autoalojado — todo se ejecuta en infraestructura que usted controla, sin dependencia de un proveedor externo. Los equipos que desean un despliegue más rápido sin gestionar sus propios servidores pueden usar Passwork Cloud, que ofrece el mismo conjunto de funciones sin la sobrecarga de infraestructura.

Conclusión

La reutilización de contraseñas persiste porque los sistemas que las rodean hacen que la reutilización sea el camino de menor resistencia. Cuando el 70% de los usuarios expuestos en brechas reutilizan contraseñas previamente expuestas en múltiples cuentas, la respuesta no es un memorando más contundente sobre higiene — es eliminar las condiciones que hacen que la reutilización parezca necesaria.

La Estrategia de Defensa de Contraseñas de 3 Pilares proporciona a su equipo un camino práctico hacia adelante. Primero los cambios de política, porque auditar contra las reglas equivocadas es una pérdida de tiempo. Luego la auditoría, porque no se puede arreglar lo que no se puede ver. Luego la bóveda, porque la aplicación sin herramientas es solo documentación.

El primer mes revelará una larga lista de riesgos de reutilización de contraseñas hechos visibles. Eso no es un problema — eso es la auditoría haciendo su trabajo. Ejecute la auditoría primero. Todo lo demás se deriva de lo que revela.

Preguntas frecuentes

¿Es un problema la reutilización de contraseñas si la contraseña es muy fuerte?

Sí. Una contraseña fuerte expuesta en una brecha es inmediatamente utilizable por los atacantes — no necesitan descifrarla, ya la tienen en texto plano de la base de datos de la brecha. La fortaleza solo importa contra ataques de adivinación. Contra una lista de credenciales robadas, una contraseña de 20 caracteres no ofrece más protección que una de 6 caracteres. La unicidad es lo que importa, no la complejidad.

¿Cómo se audita la reutilización de contraseñas en una empresa?

Utilice un gestor de contraseñas empresarial con auditoría de seguridad integrada que marque automáticamente las credenciales duplicadas, débiles u obsoletas en todas las cuentas. Las verificaciones manuales no escalan y pasan por alto cuentas de servicio, inicios de sesión compartidos y shadow IT. El escaneo automatizado proporciona visibilidad continua en lugar de una instantánea única.

¿La autenticación de dos factores detiene los ataques de reutilización de contraseñas?

No completamente. Los atacantes pueden capturar tanto la contraseña como el token de sesión activo en tiempo real, eludiendo 2FA después de que ya se ha completado. Recorded Future encontró que el 31% de las credenciales procedentes de malware en 2025 incluían cookies de sesión activas — lo que significa que el MFA fue eludido por diseño, no eludido. 2FA es una capa importante de defensa, pero no cancela el riesgo creado por las contraseñas reutilizadas.

¿Qué es una combolist?

Una combolist es un archivo que contiene millones de pares de nombre de usuario y contraseña filtrados, recopilados de varias brechas de datos y vendidos en mercados criminales. Los atacantes usan estas listas para probar automáticamente credenciales contra sistemas de inicio de sesión. Si su contraseña aparece en una — de cualquier brecha, en cualquier lugar — cada cuenta donde la haya reutilizado está en riesgo.

¿Puede una auditoría de seguridad detectar la reutilización de contraseñas?

Sí. Los auditores que evalúan el cumplimiento de SOC 2, ISO 27001 o PCI DSS buscan evidencia de que los controles de acceso se gestionan adecuadamente. La reutilización generalizada de contraseñas se trata como un fallo de control y típicamente resulta en un hallazgo formal que debe abordarse antes de que se otorgue la certificación o atestación.

¿Cuál es la diferencia entre el relleno de credenciales y un ataque de fuerza bruta?

El relleno de credenciales usa pares de nombre de usuario/contraseña conocidos y ya robados de bases de datos de brechas y los prueba contra otros servicios. Los ataques de fuerza bruta intentan adivinar una contraseña desconocida generando combinaciones. El relleno de credenciales es más rápido, más barato y más efectivo contra contraseñas reutilizadas — porque el atacante ya tiene la respuesta correcta, solo está encontrando qué cerraduras abre.

¿Qué dice NIST sobre la rotación de contraseñas?

NIST SP 800-63B-4 (final, julio de 2025) recomienda no hacer rotación periódica obligatoria. Los cambios forzados producen patrones incrementales predecibles — Password1 se convierte en Password2 — sin mejorar la seguridad. El estándar recomienda rotación solo cuando hay evidencia de compromiso, y establece una longitud mínima de 15 caracteres para contraseñas elegidas por el usuario utilizadas como único autenticador.

Shadow AI: La amenaza oculta que cuesta a las empresas $670K por brecha

Shadow AI cuesta a las empresas $670K extra por brecha — y la mayoría se origina en credenciales pegadas en LLMs públicos. Aprenda cómo es realmente shadow AI, por qué es más difícil de detener que shadow IT y cómo gobernarlo.

Passwork BlogAlex Muntyan

Gestión de contraseñas para equipos: La solución que toda PYME necesita

Almacenar contraseñas en Slack y navegadores expone su negocio a brechas. Descubra por qué las herramientas personales fallan en los equipos, cómo dar de baja de forma segura a empleados que se marchan con un solo clic, y por qué las últimas directrices NIST recomiendan no forzar la rotación de contraseñas.

Passwork BlogAlex Muntyan

Ataques de fuerza bruta en 2026: Tipos, ejemplos y cómo prevenirlos

Clústeres de GPU, listas de palabras asistidas por IA, botnets de 2,8 millones de dispositivos. La fuerza bruta ha escalado. Esta guía cubre seis variantes de ataque, casos reales de 2025 y una estrategia de defensa por capas que su equipo puede implementar hoy.

Passwork BlogAlex Muntyan

Die meisten Sicherheitsverletzungen beginnen nicht mit einem ausgeklügelten Angriff. Sie beginnen mit einem Passwort, das jemand auf zwei verschiedenen Websites verwendet hat. Laut dem Data Breach Investigations Report 2026 von Verizon tauchten gestohlene Anmeldedaten irgendwo in 39 % aller bestätigten Sicherheitsverletzungen auf — nicht nur als Einstiegspunkt, sondern auch bei lateraler Bewegung, Persistenz und Datendiebstahl. 

Die Ausnutzung von Schwachstellen hat Anmeldedaten als einzelnen Top-Vektor für den Erstzugang überholt, aber Angreifer haben den Missbrauch von Anmeldedaten nicht aufgegeben. Sie haben ihn tiefer in die Angriffskette integriert. Wenn Ihre Mitarbeiter Passwörter wiederverwenden (und statistisch gesehen tun das die meisten), trägt Ihr Unternehmen Risiken durch Passwortwiederverwendung, die erst sichtbar werden, wenn Angreifer bereits im System sind.

Wichtige Erkenntnisse

• Ein einziges wiederverwendetes Passwort erzeugt sofort ein systemisches Risiko. Wenn Anmeldedaten aus einer privaten oder geschäftlichen Quelle geleakt werden, testen automatisierte Tools sie innerhalb von Stunden in Ihrem gesamten Netzwerk.
• Credential Stuffing ist hochgradig automatisiert und unmittelbar. Angreifer führen automatisierte Datenbanken mit geleakten Anmeldedaten innerhalb von Stunden nach einem öffentlichen Datenleck gegen Unternehmensportale aus.
• Session Hijacking umgeht die Multi-Faktor-Authentifizierung vollständig. Infostealer stehlen aktive Session-Cookies zusammen mit gespeicherten Browser-Passwörtern und ermöglichen es Angreifern, legitime Sitzungen zu klonen, ohne MFA-Abfragen auszulösen.
• Erzwungene Passwortrotation schwächt die Unternehmenssicherheit. Obligatorische 90-Tage-Änderungen führen zu vorhersehbaren Mustern. Moderne Standards (einschließlich NIST SP 800-63B) empfehlen eine Mindestlänge von 15 Zeichen und Rotation nur bei tatsächlicher Kompromittierung.
• Die Eliminierung von Wiederverwendung erfordert einen strukturierten Drei-Säulen-Ansatz. Organisationen müssen veraltete Richtlinien aktualisieren, Credential-Audits durchführen, um Schatten-IT aufzudecken, und einen zentralisierten Tresor bereitstellen, um sichere Gewohnheiten reibungslos zu gestalten.
• Systemische Kontrolle muss individuelle Verantwortung ersetzen. Ein Passwort-Manager automatisiert die Credential-Hygiene durch kontinuierliches Scannen nach Duplikaten, Absicherung verwaister Dienstkonten und Verwaltung granularer Lieferantenzugriffe in einem zentralisierten Tresor.

Warum Passwortwiederverwendung gefährlich ist: Das Bild 2026

Passwortwiederverwendung schafft einen Single Point of Failure für alle Konten, die dieselben Anmeldedaten teilen. Wenn Angreifer diese Anmeldedaten aus einer beliebigen Quelle (geschäftlich oder privat) erhalten, testen automatisierte Tools sie innerhalb von Stunden gegen Unternehmens-E-Mail, VPN-Portale und Cloud-Anwendungen. Im Jahr 2025 indexierte Recorded Future 1,95 Milliarden Credential-Expositionen aus Malware-Quellen, von denen 31 % aktive Session-Cookies enthielten, die MFA (Multi-Faktor-Authentifizierung) vollständig umgehen.

Kriminelle erstellen und handeln Combolists: strukturierte Dateien mit geleakten E-Mail/Passwort-Paaren, die aus Jahren von Datenlecks aggregiert wurden. Automatisierte Tools testen diese Paare innerhalb von Stunden nach Erscheinen einer neuen Liste auf Dark-Web-Märkten gegen Unternehmens-Anmeldeseiten, VPN-Portale und Cloud-Anwendungen. Der Angriff ist mechanisch: Nehmen Sie eine Liste bekannter Anmeldedaten, führen Sie sie gegen eine Anmeldeseite aus, sammeln Sie die Treffer.

Infostealer sind die schnellere, gefährlichere Pipeline. Diese Malware läuft unbemerkt auf einem infizierten Gerät, extrahiert jedes im Browser gespeicherte Passwort, sammelt aktive Session-Cookies und exfiltriert das Paket — oft innerhalb von Minuten. Wenn der Angreifer einen gültigen Session-Token hat, wird kein Login-Ereignis ausgelöst, keine MFA-Abfrage erscheint, und der Zugriff sieht völlig legitim aus.

Das Volumen im Jahr 2025 war beeindruckend. Der Identity Threat Landscape Report 2025 von Recorded Future (veröffentlicht März 2026) erkannte 1,95 Milliarden Malware-Combolist-Credential-Expositionen über das Jahr, mit einem starken Volumenanstieg — das letzte Quartal produzierte 90 % mehr indexierte Anmeldedaten als das erste. Der Identity Breach Report 2026 von Constella Intelligence stellte fest, dass fast 60 % der aufgenommenen Datenleck-Datensätze recycelte Credential-Zusammenstellungen waren — ein Anstieg gegenüber dem Vorjahr.

Ein Detail aus den Daten von Recorded Future verdient Aufmerksamkeit: 276 Millionen der Anmeldedaten, die 2025 indexiert wurden, enthielten aktive Session-Cookies. Das sind 31 % der Malware-basierten Anmeldedaten, die MFA konstruktionsbedingt vollständig umgehen. Passwortwiederverwendung ist gefährlich. Credential-Wiederverwendung kombiniert mit Session Hijacking ist eine andere Kategorie von Problem.

11 Risiken der Passwortwiederverwendung, die jedes Unternehmen kennen sollte

Passwortwiederverwendung erzeugt eine Kette von Schwachstellen. Jedes unten aufgeführte Risiko ist unabhängig, aber bei einem echten Angriff verstärken sie sich gegenseitig. Ein Angreifer, der Risiko Nr. 1 ausnutzt, erlangt oft die Position, um die Risiken Nr. 3, Nr. 7 und Nr. 11 in derselben Sitzung auszunutzen.

1. Automatisierte Login-Angriffe treffen alle Konten gleichzeitig

Wenn ein Passwort in einem Datenleck auftaucht, führen Angreifer es gleichzeitig gegen Ihre Unternehmens-E-Mail, Ihr HR-System, Ihren Cloud-Speicher und Ihr VPN-Portal aus. Das ist Credential Stuffing — vollständig automatisiert, läuft im großen Maßstab innerhalb von Stunden nach Erscheinen einer neuen Combolist. Laut der zusätzlichen DBIR-Forschung 2025 von Verizon zu Credential Stuffing lag der mediane tägliche Anteil von Credential Stuffing in SSO-Provider-Logs bei 19 % aller Authentifizierungsversuche. Fast einer von fünf Anmeldeversuchen, an einem durchschnittlichen Tag.

2. Ein Datenleck auf einem privaten Gerät wird zu Ihrem Problem

Wenn der private Laptop eines Mitarbeiters Infostealer-Malware aufschnappt (durch einen Phishing-Link oder einen kompromittierten Download), wird jedes im Browser gespeicherte Passwort gestohlen. Wenn eines dieser Passwörter mit dem übereinstimmt, das bei der Arbeit verwendet wird, sind Ihre Systeme jetzt exponiert. Sie hatten keinen Anteil an diesem Datenleck. Sie tragen trotzdem die Konsequenzen.

Der Annual Identity Exposure Report 2025 von SpyCloud stellte fest, dass 91 % der Organisationen angaben, im vergangenen Jahr einen identitätsbezogenen Vorfall erlitten zu haben — fast doppelt so viele wie im Vorjahr — wobei Infostealer-Malware ein Haupttreiber war. Die Infektion muss nicht auf einem Firmenrechner stattfinden, um ein Firmenproblem zu werden.

3. Ein Passwort öffnet viele Türen

Innerhalb eines Unternehmens sind Systeme verbunden. Ein Angreifer, der mit einem wiederverwendeten Passwort in ein Konto gelangt, kann dieselben Anmeldedaten verwenden, um andere interne Systeme zu sondieren. Was als Zugriff auf ein einzelnes Mitarbeiterkonto beginnt, kann sich auf Dateiserver, interne Tools oder Administratorkonsolen ausweiten. Bis es bemerkt wird, war der Angreifer wochenlang im System.

4. Nicht nachverfolgte Apps erzeugen versteckte Hintertüren

Mitarbeiter melden sich selbstständig bei Tools an (Projekt-Tracker, Design-Plattformen, Kommunikations-Apps) mit ihrer Arbeits-E-Mail und oft einem Passwort, das sie auch bei der Arbeit verwenden. Die IT-Abteilung weiß nicht, dass diese Konten existieren. Wenn eine dieser Apps gehackt wird, hat der Angreifer funktionierende Anmeldedaten für Ihre Unternehmenssysteme durch eine Tür, von der niemand wusste, dass sie offen war.

Das ist Schatten-IT, und sie ist eines der am schwierigsten zu verwaltenden Risiken der Passwortwiederverwendung, da die Exposition vollständig außerhalb Ihrer Sichtbarkeit stattfindet.

5. Zwei-Faktor-Authentifizierung rettet Sie nicht immer

2FA ist wertvoll. Es ist keine vollständige Lösung für Passwortwiederverwendung. Angreifer fangen den Authentifizierungsprozess in Echtzeit ab und erfassen sowohl das Passwort als auch den temporären Session-Token, der beweist, dass die 2FA-Prüfung bereits bestanden wurde. Sobald sie diesen Token haben, sind sie drin — und 2FA hat seine Aufgabe aus Sicht des Systems bereits erfüllt.

2FA reduziert das Risiko erheblich. Ein wiederverwendetes Passwort gibt Angreifern jedoch immer noch einen Ausgangspunkt, mit dem sie arbeiten können, und Session Hijacking eliminiert MFA vollständig aus der Gleichung.

6. Wiederverwendete Passwörter können Ihr nächstes Audit scheitern lassen

Wenn Ihr Unternehmen Zahlungsdaten oder personenbezogene Daten verarbeitet oder unter einem formalen Sicherheitsrahmen operiert, werden Passwortpraktiken genau unter die Lupe genommen. Sicherheitsstandards wie SOC 2, ISO 27001 und PCI DSS verlangen alle, dass Zugriffskontrollen ordnungsgemäß verwaltet werden — und Auditoren prüfen, ob Ihre Organisation Passwortqualität durchsetzt. Das Auffinden weit verbreiteter Passwortwiederverwendung ist ein Warnsignal, das zu Audit-Feststellungen, fehlgeschlagenen Zertifizierungen oder Compliance-Lücken führen kann, die vor dem Abschluss eines Geschäfts oder der Verlängerung eines Vertrags formell behoben werden müssen.

7. Lieferantenzugriff ist Teil Ihrer Angriffsfläche

Auftragnehmer und Drittanbieter benötigen oft Zugriff auf Ihre Systeme. Wenn diese Anmeldedaten nachlässig geteilt werden — oder wenn das Personal des Anbieters selbst Passwörter wiederverwendet — wird ein Datenleck beim Anbieter zu einem Datenleck in Ihrer Organisation. Der DBIR 2026 von Verizon stellte fest, dass 48 % der Sicherheitsverletzungen in irgendeiner Form einen Dritten involvierten, ein Anstieg von 60 % gegenüber dem Vorjahr. Lieferantenkonten werden häufig nach Projektende vergessen. Der Zugriff bleibt aktiv, das Passwort wird nie geändert, und niemand überwacht es.

8. Mitarbeiter verwenden auch Systempasswörter wieder

Dienstkonten und Systemanmeldedaten erhalten weit weniger Aufmerksamkeit als Mitarbeiterkonten. Ein Entwickler, der drei Datenbankumgebungen mit demselben Passwort verwaltet, erscheint auf keiner HR-Offboarding-Liste. Niemand besitzt diese Anmeldedaten, also prüft sie auch niemand. Wenn eine Umgebung kompromittiert wird, ist jedes System, das diese Anmeldedaten teilt, exponiert.

Diese Konten erscheinen nicht in einem Standard-Mitarbeiterverzeichnis. Keine einzelne Person besitzt sie. Das ist die Lücke, durch die Angreifer gehen.

9. Geschäftliche und private Konten kontaminieren sich gegenseitig

Die Grenze zwischen privaten und beruflichen Passwörtern ist fast vollständig verschwommen. Laut dem Annual Identity Exposure Report 2025 von SpyCloud verwendeten 70 % der in Datenlecks exponierten Benutzer zuvor exponierte Passwörter über mehrere Konten hinweg wieder. SpyCloud beschreibt dies als eine Allzeit-Rate — was bedeutet, dass sie das kumulative Wiederverwendungsverhalten über jedes Datenleck in ihrem Datensatz widerspiegelt, nicht eine Momentaufnahme eines einzelnen Jahres. Ein Mitarbeiter, der sein Arbeitspasswort für ein privates Konto verwendet, exponiert das Unternehmen, wenn dieses private Konto gehackt wird. Das Umgekehrte gilt gleichermaßen.

Die Daten von SpyCloud zeigen auch, dass Infostealer-basierte Expositionen zunehmend private und geschäftliche Identitätsdaten vom selben Gerät vermischen, was die Grenze zwischen privat und beruflich für einen Angreifer, der die Anmeldedaten bereits hat, funktionell irrelevant macht.

10. Erzwungene Passwortänderungen haben gegenteilige Wirkung

Viele Unternehmen verlangen noch immer, dass Mitarbeiter ihre Passwörter alle 90 Tage ändern. Das Ergebnis ist normalerweise, dass Password123! zu Password124! wird — eine Änderung, die die Richtlinie erfüllt, aber keinen echten Schutz bietet. Menschen nehmen die kleinstmögliche Änderung vor, um die Erinnerung loszuwerden.

NIST SP 800-63B-4 (2025) rät aus genau diesem Grund von obligatorischer periodischer Rotation ab. Erzwungene Änderungen erzeugen vorhersehbare Muster. Der Standard verlangt mindestens 15 Zeichen für benutzerdefinierte Passwörter, wenn das Passwort der einzige Authentifikator ist, und empfiehlt Rotation nur bei Nachweis einer Kompromittierung — nicht nach einem Kalenderplan.

11. Gestohlene Anmeldedaten sind schwer zu erkennen

Wenn ein Angreifer ein echtes, gültiges Mitarbeiterpasswort verwendet, sieht seine Aktivität wie normales Benutzerverhalten aus. Kein Alarm wird ausgelöst, kein Login wird blockiert, kein offensichtliches Zeichen erscheint, dass etwas nicht stimmt. Sie können wochenlang in Ihren Systemen sitzen — E-Mails lesen, auf Dateien zugreifen, Ihre interne Struktur kartieren — bevor es jemand bemerkt. Laut dem Cost of a Data Breach Report 2025 von IBM benötigten Organisationen durchschnittlich 158 Tage, um einen Sicherheitsvorfall zu identifizieren — und weitere 83 Tage, um ihn einzudämmen, für einen Gesamtlebenszyklus von 241 Tagen, ein Neun-Jahres-Tief, aber immer noch lang genug für einen Angreifer mit gültigen Anmeldedaten, um erheblichen Schaden anzurichten.

So bringen Sie Ihr Team weg von der Passwortwiederverwendung

Passwortgewohnheiten in einem Team zu ändern, geschieht nicht durch das Versenden eines Richtliniendokuments. Es erfordert die Beseitigung der Reibung, die Wiederverwendung überhaupt erst notwendig erscheinen lässt. Die folgende Struktur (die 3-Säulen-Passwort-Verteidigungsstrategie: Richtlinie, Audit und Tresor) adressiert jede Ebene, auf der Wiederverwendung Fuß fasst.

Säule 1 — Richtlinie: Ändern Sie die Regeln, nicht nur die Erinnerungen.

Streichen Sie die 90-Tage-Rotationsanforderung. Folgen Sie stattdessen den NIST SP 800-63B-Richtlinien: Verlangen Sie Passwörter mit mindestens 15 Zeichen, prüfen Sie neue Passwörter gegen bekannte Datenleck-Listen und hören Sie auf, Komplexitätsregeln durchzusetzen, die nur Summer2026!-Muster erzeugen. Kommunizieren Sie die Änderung an Ihr Team mit einem klaren Grund — „Wir streichen die erzwungene Rotation, weil sie vorhersehbare Passwörter erzeugt hat, keine sicheren." Menschen befolgen Regeln, die sie verstehen.

Säule 2 — Audit: Finden Sie heraus, womit Sie es tatsächlich zu tun haben.

Bevor Sie das Problem beheben können, müssen Sie es kartieren. In dieser Phase prüfen Sie nicht Passwörter — Sie prüfen die Angriffsfläche. Erstellen Sie eine Liste aller Systeme, Anwendungen und Dienste, auf die Ihr Team zugreift. Überprüfen Sie Ihr AD/LDAP-Verzeichnis auf aktive Konten, veraltete Konten und gemeinsam genutzte Anmeldedaten. Identifizieren Sie, wo SSO die Authentifizierung bereits abdeckt und wo nicht. Das Ergebnis ist ein klares Bild: wie viele separate Passwörter Ihr Team tatsächlich verwaltet und welche Systeme das größte Risiko tragen, wenn diese Anmeldedaten kompromittiert werden.

Das ist die Grundlage für Säule 3. Sobald der Passwort-Manager bereitgestellt ist, führen Sie den zweiten Durchgang durch — Scannen nach schwachen, duplizierten oder veralteten Passwörtern über alles außerhalb von SSO. Dann entsteht das vollständige Bild.

Säule 3 — Tresor: Machen Sie die sichere Option zur einfachen Option.

Führen Sie einen Passwort-Manager mit obligatorischer Nutzung für jedes Konto außerhalb von SSO ein. Das Ziel ist, die sichere Option zum Standard zu machen. Wenn das Tool Anmeldedaten automatisch generiert und ausfüllt, ist Wiederverwendung keine Wahlmöglichkeit mehr. Führen Sie die Einführung teamweise durch, beginnend mit den Gruppen, die Zugriff auf die sensibelsten Systeme haben. Kombinieren Sie es mit einer kurzen Onboarding-Sitzung, nicht mit einem langen Schulungsdokument.

Wie Passwork Passwortwiederverwendung auf Organisationsebene adressiert

Die Verwaltung von Passwortwiederverwendung erfordert den Übergang von individueller Verantwortung zu systemischer Kontrolle. Die folgende Tabelle zeigt, wie Passwork die primären in diesem Leitfaden identifizierten Risiken der Passwortwiederverwendung mindert.

Das Sicherheitsaudit-Dashboard von Passwork scannt jeden Tresor kontinuierlich. Schwache und veraltete Anmeldedaten werden automatisch angezeigt — keine manuelle Prüfung erforderlich. Administratoren erhalten eine konsolidierte Ansicht über alle Teams und Konten. Das ist die Sichtbarkeitsebene, die ein Credential-Audit im großen Maßstab funktionieren lässt.

Rollenbasierte Zugriffskontrolle (RBAC) bedeutet, dass Passwörter über den Tresor geteilt werden, nicht über Chat-Nachrichten oder E-Mail-Threads. Wenn ein Teammitglied einem Projekt beitritt, erhält es automatisch Zugriff auf die relevanten Anmeldedaten. Wenn es geht, wird der Zugriff in einem Schritt widerrufen. Kein Suchen danach, auf welche freigegebenen Ordner es noch Zugriff hat.

Für Organisationen mit strengen Anforderungen an Datenresidenz oder Compliance ist Passwork als Self-Hosted-Deployment verfügbar — alles läuft auf Infrastruktur, die Sie kontrollieren, ohne Abhängigkeit von einem externen Anbieter. Teams, die eine schnellere Bereitstellung ohne Verwaltung eigener Server wünschen, können Passwork Cloud nutzen, das denselben Funktionsumfang ohne den Infrastrukturaufwand bietet.

Fazit

Passwortwiederverwendung besteht fort, weil die Systeme um sie herum Wiederverwendung zum Weg des geringsten Widerstands machen. Wenn 70 % der in Datenlecks exponierten Benutzer zuvor exponierte Passwörter über mehrere Konten hinweg wiederverwenden, ist die Antwort kein stärkeres Memo über Hygiene — sondern die Beseitigung der Bedingungen, die Wiederverwendung notwendig erscheinen lassen.

Die 3-Säulen-Passwort-Verteidigungsstrategie gibt Ihrem Team einen praktischen Weg nach vorn. Zuerst Richtlinienänderungen, weil Audits gegen die falschen Regeln Zeitverschwendung sind. Dann das Audit, weil Sie nicht beheben können, was Sie nicht sehen. Dann der Tresor, weil Durchsetzung ohne Tools nur Dokumentation ist.

Der erste Monat wird eine lange Liste von wiederverwendeten und schwachen sichtbar gemachten Risiken der Passwortwiederverwendung aufdecken. Das ist kein Problem — das bedeutet, dass das Audit seine Aufgabe erfüllt. Führen Sie zuerst das Audit durch. Alles andere folgt aus dem, was es aufdeckt.

Häufig gestellte Fragen

Ist Passwortwiederverwendung ein Problem, wenn das Passwort sehr stark ist?

Ja. Ein starkes Passwort, das in einem Datenleck exponiert wurde, ist für Angreifer sofort nutzbar — sie müssen es nicht knacken, sie haben es bereits im Klartext aus der Datenleck-Datenbank. Stärke zählt nur gegen Rateangriffe. Gegen eine gestohlene Anmeldedatenliste bietet ein 20-Zeichen-Passwort nicht mehr Schutz als ein 6-Zeichen-Passwort. Einzigartigkeit ist das, was zählt, nicht Komplexität.

Wie prüft man Passwortwiederverwendung in einem Unternehmen?

Verwenden Sie einen Enterprise-Passwort-Manager mit integriertem Sicherheitsaudit, der automatisch doppelte, schwache oder veraltete Anmeldedaten über alle Konten hinweg markiert. Manuelle Prüfungen skalieren nicht und übersehen Dienstkonten, gemeinsam genutzte Logins und Schatten-IT. Automatisiertes Scannen gibt Ihnen kontinuierliche Sichtbarkeit anstelle einer einmaligen Momentaufnahme.

Stoppt Zwei-Faktor-Authentifizierung Angriffe durch Passwortwiederverwendung?

Nicht vollständig. Angreifer können sowohl das Passwort als auch den aktiven Session-Token in Echtzeit abfangen und 2FA umgehen, nachdem es bereits bestanden wurde. Recorded Future stellte fest, dass 31 % der Malware-basierten Anmeldedaten im Jahr 2025 aktive Session-Cookies enthielten — was bedeutet, dass MFA konstruktionsbedingt umgangen wurde, nicht umgangen werden musste. 2FA ist eine wichtige Verteidigungsschicht, aber es hebt das durch wiederverwendete Passwörter geschaffene Risiko nicht auf.

Was ist eine Combolist?

Eine Combolist ist eine Datei, die Millionen von geleakten Benutzername-und-Passwort-Paaren enthält, die aus verschiedenen Datenlecks gesammelt und auf kriminellen Märkten verkauft werden. Angreifer verwenden diese Listen, um Anmeldedaten automatisch gegen Anmeldesysteme zu testen. Wenn Ihr Passwort in einer erscheint — aus irgendeinem Datenleck, irgendwo — ist jedes Konto, bei dem Sie es wiederverwendet haben, gefährdet.

Kann ein Sicherheitsaudit Passwortwiederverwendung markieren?

Ja. Auditoren, die SOC 2, ISO 27001 oder PCI DSS Compliance bewerten, suchen nach Nachweisen, dass Zugriffskontrollen ordnungsgemäß verwaltet werden. Weitverbreitete Passwortwiederverwendung wird als Kontrollversagen behandelt und führt in der Regel zu einer formellen Feststellung, die behoben werden muss, bevor Zertifizierung oder Attestierung erteilt wird.

Was ist der Unterschied zwischen Credential Stuffing und einem Brute-Force-Angriff?

Credential Stuffing verwendet bekannte, bereits gestohlene Benutzername/Passwort-Paare aus Datenleck-Datenbanken und testet sie gegen andere Dienste. Brute-Force-Angriffe versuchen, ein unbekanntes Passwort durch Generieren von Kombinationen zu erraten. Credential Stuffing ist schneller, günstiger und effektiver gegen wiederverwendete Passwörter — weil der Angreifer bereits die richtige Antwort hat und nur herausfindet, welche Schlösser sie öffnet.

Was sagt NIST zur Passwortrotation?

NIST SP 800-63B-4 (final, Juli 2025) rät von obligatorischer periodischer Rotation ab. Erzwungene Änderungen erzeugen vorhersehbare inkrementelle Muster — Password1 wird zu Password2 — ohne die Sicherheit zu verbessern. Der Standard empfiehlt Rotation nur bei Nachweis einer Kompromittierung und setzt eine Mindestlänge von 15 Zeichen für benutzerdefinierte Passwörter fest, die als einziger Authentifikator verwendet werden.

Shadow AI: The hidden threat costing enterprises $670K per breach

Shadow AI costs enterprises $670K extra per breach — and most of it traces back to credentials pasted into public LLMs. Learn what shadow AI actually looks like, why it's harder to stop than shadow IT, and how to govern it.

Passwork BlogAlex Muntyan

Password management for teams: The fix every SMB needs

Storing passwords in Slack and browsers exposes your business to breaches. Discover why personal tools fail teams, how to securely offboard departing employees in one click, and why the latest NIST guidelines recommend against forced password rotation.

Passwork BlogAlex Muntyan

Brute force attacks in 2026: Types, examples & how to prevent them

GPU clusters, AI-assisted wordlists, botnets of 2.8M devices. Brute force has scaled. This guide covers six attack variants, real-world cases from 2025, and a layered defense strategy your team can implement today.

Passwork BlogAlex Muntyan

Most breaches don't start with a sophisticated attack. They start with a password someone used on two different websites. According to Verizon's 2026 Data Breach Investigations Report, stolen credentials appeared somewhere in 39% of all confirmed breaches — not just as the front door, but throughout lateral movement, persistence, and data theft. 

Vulnerability exploitation has overtaken credentials as the single top initial access vector, but attackers haven't abandoned credential abuse. They've folded it deeper into the intrusion chain. If your employees are reusing passwords (and statistically, most of them are) your business is carrying password reuse risks that don't show up until they're already inside.

Key takeaways

• A single reused password creates instant systemic risk. When a credential is leaked from any personal or corporate source, automated tools test it across your entire network within hours.
• Credential stuffing is highly automated and immediate. Attackers run automated databases of leaked credentials against corporate portals within hours of a public breach.
• Session hijacking bypasses multi-factor authentication entirely. Infostealers steal active session cookies alongside saved browser passwords, allowing attackers to clone legitimate sessions without triggering MFA prompts.
• Forced password rotation weakens corporate security. Mandatory 90-day changes lead to predictable patterns. Modern standards (including NIST SP 800-63B) recommend a 15-character minimum length and rotation only upon actual compromise.
• Eliminating reuse requires a structured three-pillar approach. Organizations must update outdated policies, run credential audits to surface shadow IT, and deploy a centralized vault to make secure habits friction-free.
• Systemic control must replace individual responsibility. Password manager automates credential hygiene by continuously scanning for duplicates, securing orphaned service accounts, and managing granular vendor access in a centralized vault.

Why password reuse is dangerous: The 2026 picture

Password reuse creates a single point of failure across every account sharing the same credential. When attackers obtain that credential from any source (corporate or personal) automated tools test it against corporate email, VPN portals, and cloud applications within hours. In 2025, Recorded Future indexed 1.95 billion malware-sourced credential exposures, 31% of which included active session cookies that bypass MFA (multi-factor authentication) entirely.

Criminals build and trade combolists: structured files of leaked email/password pairs aggregated from years of data breaches. Automated tools test these pairs against corporate login pages, VPN portals, and cloud applications within hours of a new list appearing on dark web markets. The attack is mechanical: take a list of known credentials, run them against a login page, collect the hits.

Infostealers are the faster, more dangerous pipeline. This malware runs silently on an infected device, pulls every saved password from the browser, harvests active session cookies, and exfiltrates the package — often within minutes. If the attacker has a valid session token, no login event fires, no MFA prompt appears, and the access looks entirely legitimate.

The volume in 2025 was staggering. Recorded Future's 2025 Identity Threat Landscape Report (published March 2026) detected 1.95 billion malware combolist credential exposures across the year, with volume accelerating sharply — the final quarter produced 90% more indexed credentials than the first. Constella Intelligence's 2026 Identity Breach Report found that nearly 60% of breach datasets ingested were recycled credential compilations — an increase from the prior year.

One detail from Recorded Future's data deserves attention: 276 million of the credentials indexed in 2025 included active session cookies. That's 31% of malware-sourced credentials bypassing MFA entirely, by design. Password reuse is dangerous. Credential reuse combined with session hijacking is a different category of problem.

11 password reuse risks every business should know

Password reuse creates a chain of vulnerabilities. Each risk below is independent, but in a real intrusion they compound. An attacker who exploits risk #1 often gains the position to exploit risks #3, #7, and #11 in the same session.

1. Automated login attacks hit every account at once

When a password appears in a breach, attackers run it against your company email, HR system, cloud storage, and VPN portal simultaneously. This is credential stuffing — fully automated, running at scale within hours of a new combolist appearing. According to Verizon's additional 2025 DBIR research on credential stuffing, the median daily share of credential stuffing in SSO provider logs was 19% of all authentication attempts. Nearly one in five login attempts, on an average day.

2. A breach on a personal device becomes your problem

If an employee's home laptop picks up infostealer malware (through a phishing link or a compromised download) every password saved in their browser gets stolen. If any of those passwords match what they use at work, your systems are now exposed. You had no part in that breach. You bear the consequences anyway.

SpyCloud's 2025 Annual Identity Exposure Report found that 91% of organizations reported suffering an identity-related incident in the past year — nearly double the previous year's numbers — with infostealer malware as a primary driver. The infection doesn't need to happen on a company machine to become a company problem.

3. One password opens many doors

Inside a business, systems are connected. An attacker who gets into one account with a reused password can use that same credential to probe other internal systems. What starts as access to a single employee account can expand into file servers, internal tools, or administrator consoles. By the time it's noticed, the attacker has been inside for weeks.

4. Untracked apps create hidden backdoors

Employees sign up for tools on their own (project trackers, design platforms, communication apps) using their work email and, often, a password they also use at work. IT doesn't know these accounts exist. When one of those apps gets breached, the attacker has a working credential for your corporate systems, through a door nobody knew was open.

This is shadow IT, and it's one of the hardest password reuse risks to manage because the exposure happens entirely outside your visibility.

5. Two-factor authentication doesn't always save you

2FA is worth having. It's not a complete fix for password reuse. Attackers intercept the authentication process in real time, capturing both the password and the temporary session token that proves the 2FA check has already passed. Once they have that token, they're in — and 2FA has already done its job as far as the system is concerned.

2FA reduces risk significantly. A reused password still gives attackers a starting point they can work with, and session hijacking removes MFA from the equation entirely.

6. Reused passwords can fail your next audit

If your business handles payment data, personal information, or operates under any formal security framework, password practices get scrutinized. Security standards like SOC 2, ISO 27001, and PCI DSS all require that access controls are properly managed — and auditors look at whether your organization enforces password quality. Finding widespread password reuse is a red flag that can result in audit findings, failed certifications, or compliance gaps that need formal remediation before you can close a deal or renew a contract.

7. Vendor access is part of your attack surface

Contractors and third-party vendors often need access to your systems. If those credentials are shared carelessly — or if the vendor's own staff reuse passwords — a breach at the vendor becomes a breach at your organization. Verizon's 2026 DBIR found that 48% of breaches involved a third party in some capacity, a 60% increase from the previous year. Vendor accounts are frequently forgotten after a project ends. The access stays active, the password never changes, and nobody is watching it.

8. Employees reuse system passwords too

Service accounts and system credentials get far less attention than employee accounts. A developer who manages three database environments with the same password won't appear on any HR offboarding list. Nobody owns that credential, so nobody audits it. When one environment is compromised, every system sharing that credential is exposed.

These accounts don't appear in a standard employee directory. No single person owns them. That's the gap attackers walk through.

9. Work and personal accounts contaminate each other

The line between personal and professional passwords has blurred almost completely. According to SpyCloud's 2025 Annual Identity Exposure Report, 70% of users exposed in breaches reused previously-exposed passwords across multiple accounts. SpyCloud describes this as an all-time rate — meaning it reflects cumulative reuse behavior across every breach in their dataset, not a single year's snapshot. An employee who uses their work password on a personal account exposes the business when that personal account is breached. The reverse is equally true.

SpyCloud's data also shows that infostealer-sourced exposures increasingly blend personal and corporate identity data from the same device, making the personal/professional boundary functionally irrelevant to an attacker who already has the credential.

10. Forced password changes backfire

Many businesses still require employees to change passwords every 90 days. The result is usually Password123! becoming Password124! — a change that satisfies the policy while providing no real protection. People make the smallest possible change to get the reminder to go away.

NIST SP 800-63B-4 (2025) recommends against mandatory periodic rotation for exactly this reason. Forced changes produce predictable patterns. The standard requires a minimum of 15 characters for user-chosen passwords when the password is the sole authenticator, and recommends rotation only on evidence of compromise — not on a calendar schedule.

11. Stolen credentials are hard to detect

When an attacker uses a real, valid employee password, their activity looks like normal user behavior. No alarm fires, no login gets blocked, no obvious sign appears that anything is wrong. They can sit inside your systems for weeks — reading emails, accessing files, mapping your internal structure — before anyone notices. According to IBM's 2025 Cost of a Data Breach Report, organizations took a mean of 158 days to identify a breach — and another 83 days to contain it, for a total lifecycle of 241 days, a nine-year low but still long enough for an attacker with a valid credential to cause serious damage.

How to move your team away from password reuse

Changing password habits across a team doesn't happen by sending a policy document. It requires removing the friction that makes reuse feel necessary in the first place. The structure below (the 3-Pillar Password Defense Strategy: Policy, Audit, and Vaulting) addresses each layer where reuse takes root.

Pillar 1 — Policy: change the rules, not just the reminders.

Drop the 90-day rotation requirement. Follow NIST SP 800-63B guidelines instead: require passwords of at least 15 characters, screen new passwords against known breach lists, and stop enforcing complexity rules that just produce Summer2026! patterns. Communicate the change to your team with a clear reason — "we're dropping forced rotation because it was producing predictable passwords, not secure ones." People follow rules they understand.

Pillar 2 — Audit: find out what you're actually dealing with.

Before you can fix the problem, you need to map it. At this stage, you're not auditing passwords — you're auditing the attack surface. Pull a list of every system, application, and service your team accesses. Check your AD/LDAP directory for active accounts, stale accounts, and shared credentials. Identify where SSO already covers authentication and where it doesn't. The output is a clear picture: how many separate passwords your team is actually managing, and which systems carry the most risk if those credentials are compromised.

This is the groundwork for Pillar 3. Once the password manager is deployed, you run the second pass — scanning for weak, duplicated, or stale passwords across everything outside SSO. That's when the full picture emerges.

Pillar 3 — Vaulting: make the secure option the easy option.

Roll out a password manager with mandatory use for every account outside SSO. The goal is to make the secure option the default. When the tool generates and fills credentials automatically, reuse stops being a choice. Deploy team by team, starting with the groups that have access to the most sensitive systems. Pair it with a short onboarding session, not a lengthy training document.

How Passwork addresses password reuse at the organizational level

Managing password reuse requires transition from individual responsibility to systemic control. The table below outlines how Passwork mitigates the primary password reuse risks identified in this guide.

Passwork's security audit dashboard scans every vault continuously. Weak and outdated credentials surface automatically — no manual check required. Administrators get a consolidated view across all teams and accounts. That's the visibility layer that makes a credential audit work at scale.

Role-based access control (RBAC) means passwords are shared through the vault, not through chat messages or email threads. When a team member joins a project, they get access to the relevant credentials automatically. When they leave, access is revoked in one step. No hunting down which shared folders they still have access to.

For organizations with strict data residency or compliance requirements, Passwork is available as a self-hosted deployment — everything runs on infrastructure you control, with no dependency on an external provider. Teams that want faster deployment without managing their own servers can use Passwork Cloud, which delivers the same feature set without the infrastructure overhead.

Conclusion

Password reuse persists because the systems around them make reuse the path of least resistance. When 70% of users exposed in breaches reuse previously-exposed passwords across multiple accounts, the answer isn't a stronger memo about hygiene — it's removing the conditions that make reuse feel necessary.

The 3-Pillar Password Defense Strategy gives your team a practical path forward. Policy changes first, because auditing against the wrong rules wastes time. Then the audit, because you can't fix what you can't see. Then vaulting, because enforcement without tooling is just documentation.

The first month will surface a long list of reused and weak password reuse risks made visible. That's not a problem — that's the audit doing its job. Run the audit first. Everything else follows from what it surfaces.

Frequently asked questions

Is password reuse a problem if the password is very strong?

Yes. A strong password exposed in a breach is immediately usable by attackers — they don't need to crack it, they already have it in plain text from the breach database. Strength only matters against guessing attacks. Against a stolen credential list, a 20-character password offers no more protection than a 6-character one. Uniqueness is what matters, not complexity.

How do you audit password reuse in a business?

Use an enterprise password manager with built-in security auditing that automatically flags duplicate, weak, or outdated credentials across all accounts. Manual checks don't scale and miss service accounts, shared logins, and shadow IT. Automated scanning gives you continuous visibility rather than a one-time snapshot.

Does two-factor authentication stop password reuse attacks?

Not completely. Attackers can capture both the password and the active session token in real time, bypassing 2FA after it has already been passed. Recorded Future found that 31% of malware-sourced credentials in 2025 included active session cookies — meaning MFA was bypassed by design, not circumvented. 2FA is an important layer of defense, but it doesn't cancel out the risk created by reused passwords.

What is a combolist?

A combolist is a file containing millions of leaked username-and-password pairs, collected from various data breaches and sold on criminal markets. Attackers use these lists to automatically test credentials against login systems. If your password appears in one — from any breach, anywhere — every account where you've reused it is at risk.

Can a security audit flag password reuse?

Yes. Auditors assessing SOC 2, ISO 27001, or PCI DSS compliance look for evidence that access controls are properly managed. Widespread password reuse is treated as a control failure and typically results in a formal finding that must be addressed before certification or attestation is granted.

What's the difference between credential stuffing and a brute-force attack?

Credential stuffing uses known, already-stolen username/password pairs from breach databases and tests them against other services. Brute-force attacks try to guess an unknown password by generating combinations. Credential stuffing is faster, cheaper, and more effective against reused passwords — because the attacker already has the correct answer, they're just finding which locks it opens.

What does NIST say about password rotation?

NIST SP 800-63B-4 (final, July 2025) recommends against mandatory periodic rotation. Forced changes produce predictable incremental patterns — Password1 becomes Password2 — without improving security. The standard recommends rotation only when there is evidence of compromise, and sets a minimum length of 15 characters for user-chosen passwords used as the sole authenticator.

Shadow AI: The hidden threat costing enterprises $670K per breach

Shadow AI costs enterprises $670K extra per breach — and most of it traces back to credentials pasted into public LLMs. Learn what shadow AI actually looks like, why it’s harder to stop than shadow IT, and how to govern it.

Passwork BlogAlex Muntyan

Password management for teams: The fix every SMB needs

Storing passwords in Slack and browsers exposes your business to breaches. Discover why personal tools fail teams, how to securely offboard departing employees in one click, and why the latest NIST guidelines recommend against forced password rotation.

Passwork BlogAlex Muntyan

Brute force attacks in 2026: Types, examples & how to prevent them

GPU clusters, AI-assisted wordlists, botnets of 2.8M devices. Brute force has scaled. This guide covers six attack variants, real-world cases from 2025, and a layered defense strategy your team can implement today.

Passwork BlogAlex Muntyan

Shadow AI bezeichnet die nicht genehmigte Nutzung von KI-Tools, Modellen und Agenten durch Mitarbeiter ohne Wissen oder Genehmigung der IT-Abteilung. Diese Praxis ist weit verbreitet und für Sicherheitsteams weitgehend unsichtbar — genau das macht sie so kostspielig.

Laut dem IBM-Bericht 2025 zahlen Organisationen mit hohem Shadow-AI-Anteil 670.000 $ mehr pro Datenpanne als solche mit geringem oder keinem Shadow-AI-Anteil. Das ergibt eine erwartete Gesamtsumme von 4,63 Mio. $. Diese Differenz spiegelt unkontrollierte Datenflüsse, ungesteuerten Modellzugriff und Zugangsdaten wider, die außerhalb jedes Sicherheitsperimeters an KI-Dienste Dritter übermittelt werden.

Das Ausmaß lässt sich schwerer abtun, als die meisten Sicherheitsteams erwarten. Entwickler, Finanzabteilungen, HR und der operative Bereich setzen KI-Tools nach eigenem Ermessen ein. Dieser Artikel erläutert, wie Shadow AI in Unternehmensumgebungen tatsächlich aussieht, warum es zu Sicherheits- und Compliance-Risiken führt und was IT-Teams tun können, um dem zuvorzukommen.

Was ist Shadow AI?

Shadow AI umfasst jedes KI-Tool, Modell, Plugin oder jeden Agenten, der innerhalb einer Organisation ohne ausdrückliche IT- oder Sicherheitsgenehmigung verwendet wird. Es befindet sich an der Schnittstelle zwischen Shadow IT und generativer KI und erbt die Governance-Blindstellen des ersteren, während es die Datenverarbeitungsrisiken der letzteren hinzufügt. Laut Varonis-Daten haben 98 % der Organisationen Mitarbeiter, die nicht genehmigte Apps nutzen, einschließlich Shadow AI.

Der Umfang ist größer, als die meisten Sicherheitsteams annehmen.

KI-Agenten stellen eine qualitative Verschiebung des Risikos dar. Eine Tabelle, die in einem nicht genehmigten Cloud-Speicher liegt, ist ein Datenexpositionsproblem. Ein KI-Agent mit delegiertem Zugriff auf E-Mail, Kalender und Dateisystem ist ein Access-Governance-Problem.

Shadow IT vs. Shadow AI: Den Risikomultiplikator verstehen

Shadow IT und Shadow AI haben gemeinsam, dass Mitarbeiter Tools außerhalb der Sichtbarkeit der IT nutzen. Das Risikoprofil ist jedoch grundlegend unterschiedlich.

Shadow IT (nicht genehmigte SaaS, privater Cloud-Speicher, nicht verwaltete Geräte) verursacht primär Datenhaltungs- und Compliance-Probleme. Daten liegen irgendwo, wo die IT keine Kontrolle hat. Die Exposition ist größtenteils statisch.

Shadow AI verarbeitet Daten. Es analysiert sie, fasst sie zusammen, generiert Ausgaben daraus und handelt im Fall von agentenbasierten Systemen autonom danach. Die Exposition ist dynamisch und oft irreversibel.

Das SaaS-Wildwuchs-Problem verstärkt dies. Mitarbeiter nutzen über 665 KI-Tools in einer typischen Unternehmensumgebung, laut der Analyse von Harmonic Security von 22 Millionen KI-Prompts in Unternehmen (2025). Sechs Anwendungen sind für 92,6 % der Exposition sensibler Daten verantwortlich, aber die verbleibenden 659 zu blockieren ist operativ zwecklos und zerstört die Produktivität. Die Governance-Herausforderung liegt in Sichtbarkeit, Klassifizierung und kontrolliertem Zugriff.

Die finanziellen Auswirkungen: Warum Shadow AI Unternehmen 670.000 $ pro Datenpanne kostet

Laut dem IBM-Bericht „Cost of a Data Breach" 2025 erhöhen Datenpannen mit hohem Shadow-AI-Anteil die durchschnittlichen Kosten um 670.000 $ im Vergleich zu solchen mit geringem oder keinem Shadow-AI-Anteil — ein Anstieg von 16 %, der die erwartete Gesamtsumme auf 4,63 Mio. $ pro Vorfall bringt.

Zwei zugrunde liegende Statistiken erklären den Mechanismus:

• 97 % der Organisationen, die einen KI-bezogenen Sicherheitsvorfall erlebten, hatten keine angemessenen KI-Zugriffskontrollen.
• 63 % der betroffenen Organisationen hatten keine Governance-Richtlinien für die Verwaltung von KI oder die Erkennung nicht autorisierter Nutzung.

Die Kausalkette ist direkt. Mitarbeiter führen KI-Tools schneller ein, als Sicherheitsteams sie bewerten können. Ohne Zugriffskontrollen fließen sensible Daten in Modelle, die die IT nie genehmigt hat und nicht auditieren kann. Wenn eine Datenpanne auftritt, verlängert das Fehlen von Logging und Governance die Erkennungs- und Eindämmungszeit — und in der Ökonomie von Datenpannen ist Zeit der primäre Kostentreiber.

Für CFOs ist die Rechnung eindeutig: Die erwarteten Kosten einer Shadow-AI-bezogenen Datenpanne betragen 4,63 Mio. $. Die Kosten eines KI-Governance-Programms für Unternehmen — Zugriffskontrollen, CASB-Bereitstellung, Lizenzierung genehmigter Tools, Credential-Management — sind nur ein Bruchteil davon. Das risikobereinigte Argument für Governance-Investitionen ist nicht mehrdeutig.

Sicherheitsteams haben auch eine DLP-Blindstelle (Data Loss Prevention): Die meisten DLP-Tools prüfen strukturierte Datenübertragungen. Konversationelle KI-Prompts sind unstrukturierter Text. Ein Mitarbeiter, der einen Datenbank-Verbindungsstring in einen Free-Tier-LLM-Account eingibt, löst keinen DLP-Alarm aus. Die Daten verlassen die Organisation unbemerkt.

Die versteckte Bedrohung: Credential-Exposition und KI-Agenten

Das direkteste und am wenigsten berichtete Shadow-AI-Risiko ist die Credential-Exposition. Mitarbeiter fügen ständig Secrets in öffentliche LLMs ein, weil es der schnellste Weg ist, Hilfe zu bekommen.

Ein Entwickler, der ein Produktionsproblem debuggt, fügt einen Datenbank-Verbindungsstring zusammen mit dem Fehlerprotokoll in ChatGPT ein. Ein DevOps-Ingenieur teilt eine Kubernetes-Konfigurationsdatei, einschließlich eingebetteter API-Keys, mit einem KI-Assistenten, um nach einem Deployment-Fehler zu fragen. Ein Finanzanalyst lädt eine Q3-Prognosetabelle in ein nicht genehmigtes KI-Zusammenfassungs-Tool hoch, um sich auf eine Vorstandssitzung vorzubereiten.

Laut der Analyse von Harmonic Security von 22,4 Millionen KI-Prompts in Unternehmen (2025) machen Code, juristische Dokumente und Finanzdaten 74,5 % der an KI-Tools exponierten sensiblen Daten aus. Quellcode allein enthält eingebettete Secrets (fest codierte API-Keys, Zugriffstokens und Dienstkonto-Credentials), die die meisten Entwickler als Konfigurationsdetails und nicht als sicherheitskritisches Material behandeln.

Die agentenbasierte Risikoebene fügt eine zweite Angriffsfläche hinzu. KI-Agenten — Systeme, die delegierte OAuth-Berechtigungen zum Lesen von Dateien, Senden von E-Mails, Abfragen von Datenbanken und Aufrufen externer APIs verwenden — arbeiten mit breiten Zugriffserteilungen, die nie für autonome Nutzung konzipiert wurden. Wenn ein Mitarbeiter einen Produktivitäts-KI-Agenten autorisiert, auf seine Unternehmens-E-Mails und seinen Dateispeicher zuzugreifen, hat dieser Agent möglicherweise breitere effektive Berechtigungen, als es die Rolle des Mitarbeiters rechtfertigen würde.

Die meisten Organisationen haben kein Inventar darüber, welche Agenten welche OAuth-Erteilungen halten, und keinen Prozess, um sie zu widerrufen, wenn ein Mitarbeiter ausscheidet.

16,9 % aller Expositionen sensibler Daten im Datensatz von Harmonic flossen durch private Free-Tier-Accounts — wo die IT keine Sichtbarkeit, keinen Audit-Trail hat und Daten zum Training öffentlicher Modelle verwendet werden können (Harmonic Security, 2025).

Die Kombination aus Credential-Exposition und agentenbasiertem Zugriff erzeugt ein kumulierendes Risiko: Ein kompromittierter KI-Agent mit Zugriff auf einen Tresor nicht verwalteter Secrets kann weit mehr exfiltrieren als ein einzelner geleakter API-Key.

Reale Datenpannen im Zusammenhang mit Shadow AI

Diese drei Vorfälle haben einen gemeinsamen Nenner: In jedem Fall griff eine KI-Komponente, die innerhalb einer vertrauenswürdigen Umgebung operierte, auf weit mehr Daten zu, als irgendjemand ausdrücklich autorisiert hatte.

Microsoft AI Research: 38 TB interner Daten exponiert

Was geschah. Ein Microsoft-KI-Forschungsteam veröffentlichte einen offenen Datensatz auf GitHub zum Training von Bilderkennungsmodellen. Um die Dateien zu teilen, verwendeten sie einen Azure-SAS-Token — konfigurierten ihn aber mit vollem Zugriff auf das gesamte Storage-Konto anstatt nur auf den Zielordner. Jeder, der dem Repository-Link folgte, erhielt uneingeschränkten Zugriff auf 38 TB privater Unternehmensdaten.

Was geleakt wurde. Workstation-Backups von zwei Mitarbeitern, über 30.000 interne Microsoft-Teams-Nachrichten von 359 Mitarbeitern, private Schlüssel, Dienstpasswörter und geheime Tokens. Der Token hatte „Vollzugriff"-Berechtigungen und war auf ein Ablaufdatum im Jahr 2051 eingestellt.

Warum dies ein Shadow-AI-Vorfall ist. Die Datenpanne geschah direkt im Rahmen der KI-Datensatzarbeit. Forscher, die schnell KI-Modelle ausliefern wollten, umgingen standardmäßige Zugriffsprüfungsverfahren. Wiz Research, das die Exposition entdeckte, beschrieb es als „eine neue Risikoklasse, der Organisationen bei beschleunigter KI-Einführung gegenüberstehen". Da der Token Schreibzugriff gewährte, hätte ein Angreifer bösartigen Code in KI-Modelle einschleusen können, die andere Entwickler aktiv herunterluden.

Reaktion. Wiz machte den Vorfall im September 2023 öffentlich. Microsoft widerrief den Token und schloss den Zugriff. Der Fall wurde zu einem Referenzbeispiel im IBM-Bericht „Cost of a Data Breach" 2025.

Slack AI: Datenexfiltration aus privaten Kanälen via Prompt Injection

Was geschah. Forscher bei PromptArmor fanden eine kritische Schwachstelle in Slack AI — dem integrierten Assistenten, der es Mitarbeitern ermöglicht, ihre gesamte Slack-Historie in natürlicher Sprache abzufragen. Die Angriffsklasse war indirekte Prompt Injection: Ein Bedrohungsakteur postet eine Nachricht in einem öffentlichen Kanal, die versteckte Anweisungen für das LLM enthält. Wenn ein Ziel Slack AI verwendet, um nach Informationen zu suchen, behandelt das Modell die bösartigen Anweisungen als legitim und führt sie aus.

Was gefährdet war. API-Keys und andere Secrets, die in privaten Kanälen gespeichert waren, auf die der Angreifer keinen direkten Zugriff hatte. Slack AI aggregierte Daten sowohl aus öffentlichen als auch aus privaten Kanälen bei der Beantwortung von Benutzeranfragen — dieser kanalübergreifende Zugriff war der Angriffsvektor. Ein zweites Szenario ermöglichte es Slack AI, einen Phishing-Link zu rendern, um Credentials abzufangen.

Warum dies ein Shadow-AI-Vorfall ist. Slack AI ist ein Lehrbuchfall für eingebettete Shadow AI: eine KI-Funktion, die innerhalb eines bereits genehmigten Unternehmenstools aktiviert wird, ohne separate Sicherheitsprüfung ihrer KI-Komponente. IT-Teams hatten keine Sichtbarkeit darüber, dass der Assistent auf private Kanäle zugreifen und als Exfiltrationsvektor dienen konnte. Am 14. August 2024 (am selben Tag, an dem die Schwachstelle offengelegt wurde) erweiterte Slack die Fähigkeiten des Assistenten, um hochgeladene Dokumente und Google-Drive-Dateien zu indexieren, was die Angriffsfläche weiter vergrößerte.

Reaktion. Slack klassifizierte das Verhalten zunächst als „beabsichtigt", veröffentlichte dann aber einen Patch. Das Unternehmen erklärte, es gebe „keine Hinweise auf unbefugten Zugriff auf Kundendaten". Der Vorfall wurde weithin als erster dokumentierter Fall von Datenexfiltration via Prompt Injection in einem produktiven Enterprise-SaaS-Produkt behandelt.

Microsoft 365 Copilot: EchoLeak, Zero-Click-Datenexfiltration

Was geschah. Forscher bei Aim Security veröffentlichten CVE-2025-32711 (CVSS 9.3 — Kritisch) in Microsoft 365 Copilot, genannt EchoLeak. Es ist die erste dokumentierte Zero-Click-Prompt-Injection mit bestätigter Datenexfiltration in einem produktiven KI-System. Der Angriff erforderte keine Aktion des Opfers.

Wie es funktionierte. Ein Angreifer sendete dem Ziel eine E-Mail mit versteckten Anweisungen, die als Markdown-Links im Referenzstil getarnt waren. Als Copilot die E-Mail verarbeitete, umging es den eingebauten XPIA-Klassifikator (Prompt-Injection-Schutz) und den Link-Schwärzungsmechanismus. Copilot griff dann automatisch auf die Dateien des Opfers in OneDrive, SharePoint und Teams zu, konstruierte eine URL über die Microsoft Teams Proxy API — die auf Copilots Whitelist steht — und sendete die Daten an den Server des Angreifers. Keine Klicks erforderlich.

Was gefährdet war. Jede Datei oder Konversation, auf die der Benutzer innerhalb von Microsoft 365 zugreifen konnte: OneDrive-Dokumente, SharePoint-Dateien, Teams-Nachrichten. Bis Mitte 2024 betrieben laut Netrix Global bereits mehr als 10.000 Unternehmen Microsoft 365 Copilot.

Warum dies ein Shadow-AI-Vorfall ist. EchoLeak repräsentiert die nächste Generation des Shadow-AI-Risikos: ein KI-Agent mit breitem Zugriff auf Unternehmensdaten, der innerhalb eines genehmigten Tools operiert, ohne angemessene Sicherheitsprüfung seiner KI-Komponente. Der Angriff hinterließ keine Spuren in Standard-Überwachungssystemen — der gesamte Datenverkehr lief über vertrauenswürdige Microsoft-Domains.

Reaktion. Microsoft veröffentlichte im Juni 2025 einen Notfall-Patch. Der Fall veränderte grundlegend, wie die Branche das Risiko für KI-Agenten mit breiten Zugriffsberechtigungen bewertet.

Shadow AI im Unternehmen erkennen und verhindern

Erkennung und Prävention erfordern einen strukturierten Ansatz. KI vollständig zu verbieten funktioniert nicht — die Daten von Harmonic zeigen, dass Mitarbeiter KI-Tools unabhängig von Richtlinien nutzen, oft über private Geräte und Accounts, die Unternehmenskontrollen vollständig umgehen. Das Ziel ist Governance, nicht Verbot.

Das 5-Schritte-Framework für Shadow-AI-Governance

1. KI-Exposition ermitteln. Setzen Sie Netzwerküberwachung ein, um ausgehenden Datenverkehr zu bekannten KI-Domains zu identifizieren. Verwenden Sie einen Cloud Access Security Broker (CASB), um Einblick in die SaaS-Nutzung auf verwalteten Geräten zu erhalten. Prüfen Sie Browser-Erweiterungen auf Unternehmens-Endpunkten — viele KI-Tools operieren als Erweiterungen mit breitem Zugriff auf Seiteninhalte. Erstellen Sie ein Inventar dessen, was tatsächlich verwendet wird, bevor Sie Richtlinien schreiben.
2. Richtlinien für akzeptable Nutzung definieren. Klassifizieren Sie KI-Tools in drei Stufen: genehmigt (Enterprise-lizenziert, Datenverarbeitungsvereinbarungen vorhanden), bedingt (nur für nicht sensible Aufgaben erlaubt) und verboten (keine Datensouveränitätskontrollen, öffentliches Modelltraining). Veröffentlichen Sie die Richtlinie.
3. RBAC für KI-Tools implementieren. Rollenbasierte Zugangskontrolle (RBAC) gilt für den Zugriff auf KI-Tools genauso wie für jedes andere System. Entwickler sollten keinen Zugriff auf Finanz-KI-Tools haben. Finanzteams sollten keinen Zugriff auf Code-Repositories haben, die in KI-Pipelines eingespeist werden. Beschränken Sie Zugriffserteilungen auf das für jede Rolle erforderliche Minimum. Prüfen Sie vierteljährlich.
4. Genehmigte Alternativen bereitstellen. Mitarbeiter setzen Shadow AI ein, weil genehmigte Tools zu langsam zu beschaffen oder für die Aufgabe unzureichend sind. Stellen Sie für jede verbotene Tool-Kategorie eine genehmigte Alternative mit gleichwertiger Funktionalität bereit. Wenn Entwickler einen KI-Coding-Assistenten benötigen, geben Sie ihnen einen mit Enterprise-Datenkontrollen. Governance ohne Befähigung erzeugt Unmut und Workarounds.
5. Die zugrunde liegenden Credentials sichern. Dies ist der Schritt, den die meisten Governance-Frameworks überspringen. Selbst mit Richtlinien und CASB können Mitarbeiter, die direkten Zugriff auf rohe API-Keys, Datenbankpasswörter und Dienstkonto-Credentials haben, diese in jedes Tool einfügen. Die Zentralisierung des Secrets-Managements — sodass Credentials gespeichert, injiziert und programmatisch rotiert werden, anstatt manuell kopiert zu werden — entfernt den direktesten Pfad von Shadow AI zur Credential-Kompromittierung.

Wie Passwork die Grundlage gegen Shadow-AI-Risiken sichert

Sie können einen Mitarbeiter nicht physisch daran hindern, einen Browser-Tab zu öffnen und in ein öffentliches LLM zu tippen. Was Sie kontrollieren können, ist, worauf er Zugriff zum Einfügen hat.

Das Kernprinzip: Klartext aus der Gleichung entfernen

Wenn API-Keys, Datenbank-Credentials, Produktions-Secrets und Dienstkonto-Passwörter in einem zentralisierten verschlüsselten Tresor liegen — auf den programmatisch zugegriffen wird anstatt manuell zu kopieren — sinkt das Credential-Expositionsrisiko durch Shadow AI erheblich. Der Entwickler, der ein Produktionsproblem mit einem KI-Assistenten debuggen möchte, kann den Datenbank-Verbindungsstring nicht einfügen, weil er ihn nie im Klartext hatte.

Was Passwork bietet

Passwork ist sowohl als Self-Hosted-Deployment als auch als Cloud-gehostete Lösung verfügbar. Beide teilen dieselbe Kernarchitektur: AES-256-Verschlüsselung unter einem Zero-Knowledge-Modell, bei dem Credentials clientseitig verschlüsselt werden, bevor sie das Gerät verlassen.

Vier Kontrollen sind im Shadow-AI-Kontext am wichtigsten:

• Rollenbasierte Zugangskontrolle. Administratoren beschränken den Tresorzugriff auf bestimmte Teams und Rollen. Ein Entwickler erhält Zugriff auf Entwicklungsumgebungs-Secrets, nicht auf Produktion. Der Zugriff wird nach Funktion gewährt, nicht nach Seniorität oder Bequemlichkeit.
• Audit-Logs. Jedes Zugriffsereignis wird aufgezeichnet: wer welches Credential abgerufen hat, wann und von welchem System. Wenn ein Credential an einem unerwarteten Ort auftaucht, haben Sie einen Nachweis.
• Dienstkonto-Management. Das Shadow-AI-Risiko beschränkt sich nicht auf Menschen, die Secrets in Chat-Fenster einfügen. KI-Agenten und automatisierte Pipelines laufen unter Dienstkonten — und diese Konten sammeln im Laufe der Zeit Berechtigungen an, ohne dass jemand sie aktiv überprüft. Passwork ermöglicht es, Dienstkonto-Credentials genauso zu speichern, zu rotieren und zu beschränken wie menschlichen Zugriff: mit expliziten Rollen, Ablaufrichtlinien und einer vollständigen Zugriffshistorie.
• API-first Credential-Bereitstellung. Die REST API von Passwork ermöglicht es Pipelines und Anwendungen, Secrets programmatisch zur Laufzeit abzurufen, anstatt sie aus Umgebungsdateien oder Konfigurations-Repositories zu lesen. Das Credential berührt nie die Zwischenablage eines Entwicklers. Es geht direkt vom Tresor zum Prozess, der es benötigt — und der Abruf wird protokolliert.

Self-Hosted vs. Cloud

Die Self-Hosted-Option hält alle Daten innerhalb der eigenen Infrastruktur der Organisation — die richtige Wahl für Teams mit strengen Datenstandortanforderungen oder regulierten Umgebungen. Die Cloud-Option entfernt den operativen Aufwand des Betriebs einer eigenen Instanz bei gleichzeitiger Beibehaltung derselben Verschlüsselungsgarantien und Zugriffskontrollen. Keine der Optionen sendet Klartext-Credentials an Passwork-Server.

Wie Passwork Shadow-AI-Risiken adressiert

Fazit

Die Mehrkosten von 670.000 $ pro Datenpanne durch Shadow AI sind die Kosten der KI-Nutzung ohne Governance. Die Organisationen, die diese Mehrkosten zahlen, sind keine Ausreißer. Es sind die 63 %, die keine KI-Governance-Richtlinien hatten, und die 97 %, denen es bei einem Vorfall an angemessenen Zugriffskontrollen mangelte.

Governance beginnt auf der Credential-Ebene. Ein Mitarbeiter, der keinen Zugriff auf rohe Produktions-Secrets hat, kann diese nicht versehentlich exponieren — unabhängig davon, welches KI-Tool er öffnet. Das ist der Kontrollpunkt, den die meisten Shadow-AI-Frameworks übersehen, und derjenige, der die unmittelbarste Risikoreduktion liefert.

Prüfen Sie noch heute, auf welche Credentials Ihre Teams im Klartext zugreifen können. Diese Liste ist Ihre Shadow-AI-Expositionsfläche.

FAQ: Shadow AI im Unternehmen

Wie erkennt man Shadow AI?

Organisationen können Shadow AI erkennen, indem sie Netzwerkprotokolle auf ungewöhnlichen ausgehenden Datenverkehr zu KI-Domains überwachen, einen Cloud Access Security Broker (CASB) einsetzen, um die SaaS-Nutzung auf verwalteten Geräten zu prüfen, und Browser-Erweiterungen auf Unternehmens-Endpunkten überprüfen. Endpoint-DLP-Tools können große Textübertragungen zu bekannten KI-Diensten markieren, obwohl private Free-Tier-Accounts eine hartnäckige Blindstelle bleiben.

Was ist ein Beispiel für Shadow AI?

Ein häufiges Beispiel ist ein Entwickler, der proprietären Quellcode in einen privaten ChatGPT-Account einfügt, um ein Produktionsproblem zu debuggen — dabei werden fest codierte API-Keys und interne Architektur exponiert. Ein weiteres ist ein Marketingteam, das vertrauliche Kundendaten in ein nicht genehmigtes KI-Zusammenfassungs-Tool hochlädt, oder ein Finanzanalyst, der Q3-Prognosen mit einem Free-Tier-KI-Assistenten teilt, um Vorstandsmaterialien vorzubereiten.

Warum ist Shadow AI gefährlicher als Shadow IT?

Shadow IT verursacht Datenstandortprobleme — Daten liegen irgendwo, wo die IT keine Kontrolle hat. Shadow AI verarbeitet Daten: Es analysiert sie, generiert Outputs daraus und handelt bei agentenbasierten Deployments autonom danach. Die Exposition durch Shadow AI ist oft irreversibel, besonders wenn Daten durch Free-Tier-Accounts fließen, wo sie zum Training öffentlicher Modelle verwendet werden können.

Welche Credentials sind am meisten durch Shadow AI gefährdet?

API-Keys, Datenbank-Verbindungsstrings, OAuth-Tokens und Dienstkonto-Passwörter sind die am höchsten gefährdeten Credentials. Dies sind die Secrets, die Entwickler und DevOps-Ingenieure am wahrscheinlichsten in KI-Prompts einfügen, wenn sie debuggen oder um Konfigurationshilfe bitten. Fest codierte Secrets im Quellcode sind besonders exponiert, da Code die größte Einzelkategorie sensibler Daten ist, die mit KI-Tools geteilt werden (Harmonic Security, 2025).

Verhindert das Verbot von KI-Tools Shadow AI?

Nein. Die Analyse von Harmonic Security von 22,4 Millionen Enterprise-Prompts ergab, dass Mitarbeiter in über 90 % der Organisationen aktiv KI-Tools nutzen, meist über private Accounts, die die IT nie genehmigt hat. Pauschale Verbote verlagern die Nutzung auf private Geräte und Accounts mit noch weniger Sichtbarkeit. Effektive Governance kombiniert genehmigte Alternativen, klare Richtlinien für akzeptable Nutzung und technische Kontrollen auf der Zugriffsebene.

Passwortverwaltung für Teams: Die Lösung, die jedes KMU braucht

Das Speichern von Passwörtern in Slack und Browsern setzt Ihr Unternehmen Datenpannen aus. Erfahren Sie, warum persönliche Tools für Teams versagen, wie Sie ausscheidende Mitarbeiter mit einem Klick sicher offboarden und warum die neuesten NIST-Richtlinien von erzwungener Passwortrotation abraten.

Passwork BlogAlex Muntyan

VaultJacking: Wie eine PIN einen Google Password Manager-Tresor exponieren kann

VaultJacking zielt auf die Google Password Manager-PIN ab, um Ihren gesamten Tresor zu entsperren. Eine abgefangene PIN exponiert jedes gespeicherte Passwort und jeden Passkey. Erfahren Sie, wie der Angriff funktioniert, wer gefährdet ist und was zu tun ist, wenn Sie gephisht wurden.

Passwork BlogAlex Muntyan

Mitarbeiter-Offboarding: Leitfaden zur sicheren Zugriffsentziehung 2026

Das Deaktivieren eines SSO-Accounts widerruft keinen Zugriff. API-Keys, KI-Agent-Credentials und geteilte Passwörter überleben es. Dieser Leitfaden behandelt das vollständige Offboarding-Playbook — von Zero-Hour-Triggern bis zur NHI-Bereinigung.

Passwork BlogAlex Muntyan

Shadow AI es el uso no autorizado de herramientas, modelos y agentes de IA por parte de empleados sin conocimiento ni aprobación del departamento de TI. Esta práctica está muy extendida y es en gran medida invisible para los equipos de seguridad — lo cual es precisamente lo que la hace costosa.

Según el informe de 2025 de IBM, las organizaciones con altos niveles de shadow AI pagan 670.000 $ más por brecha que aquellas con niveles bajos o sin shadow AI, elevando el total esperado a 4,63 millones de dólares. Esa diferencia refleja flujos de datos no monitoreados, acceso a modelos sin gobernanza y credenciales transferidas a servicios de IA de terceros fuera de cualquier perímetro de seguridad.

La magnitud es más difícil de ignorar de lo que la mayoría de los equipos de seguridad esperan. Desarrolladores, personal financiero, recursos humanos y operaciones están adoptando herramientas de IA según sus propios criterios. Este artículo analiza cómo se manifiesta realmente shadow AI en entornos empresariales, por qué genera exposición de seguridad y cumplimiento, y qué pueden hacer los equipos de TI para adelantarse.

¿Qué es Shadow AI?

Shadow AI es cualquier herramienta, modelo, plugin o agente de IA utilizado dentro de una organización sin aprobación explícita de TI o seguridad. Se sitúa en la intersección de Shadow IT y la IA generativa, heredando los puntos ciegos de gobernanza del primero y añadiendo los riesgos de procesamiento de datos de la segunda. Según datos de Varonis, el 98% de las organizaciones tienen empleados que utilizan aplicaciones no autorizadas, incluida shadow AI.

El alcance es más amplio de lo que la mayoría de los equipos de seguridad suponen.

Los agentes de IA representan un cambio cualitativo en el riesgo. Una hoja de cálculo almacenada en una unidad en la nube no aprobada es un problema de exposición de datos. Un agente de IA con acceso delegado a su correo electrónico, calendario y sistema de archivos es un problema de gobernanza de accesos.

Shadow IT vs. Shadow AI: comprender el multiplicador de riesgo

Shadow IT y Shadow AI implican que los empleados utilicen herramientas fuera de la visibilidad de TI. El perfil de riesgo es fundamentalmente diferente.

Shadow IT (SaaS no autorizado, almacenamiento personal en la nube, dispositivos no gestionados) genera principalmente problemas de residencia de datos y cumplimiento. Los datos residen en algún lugar que TI no controla. La exposición es en gran medida estática.

Shadow AI procesa datos. Razona sobre ellos, los resume, genera resultados a partir de ellos y, en el caso de sistemas agénticos, actúa sobre ellos. La exposición es dinámica y a menudo irreversible.

El problema de la proliferación de SaaS agrava esto. Los empleados utilizan más de 665 herramientas de IA en un entorno empresarial típico, según el análisis de Harmonic Security de 22 millones de prompts empresariales de IA (2025). Seis aplicaciones representan el 92,6% de la exposición de datos sensibles, pero bloquear las 659 restantes es operativamente inútil y destruye la productividad. El desafío de gobernanza es la visibilidad, la clasificación y el acceso controlado.

El impacto financiero: por qué Shadow AI cuesta a las empresas 670.000 $ por brecha

Según el Informe del Coste de una Brecha de Datos 2025 de IBM, las brechas que involucran altos niveles de shadow AI añaden 670.000 $ al coste medio de la brecha en comparación con aquellas con niveles bajos o sin shadow AI — un aumento del 16%, elevando el total esperado a 4,63 millones de dólares por incidente.

Dos estadísticas subyacentes explican el mecanismo:

• El 97% de las organizaciones que experimentaron un incidente de seguridad relacionado con IA carecían de controles de acceso a IA adecuados.
• El 63% de las organizaciones que sufrieron brechas no tenían políticas de gobernanza para gestionar la IA o detectar el uso no autorizado.

La cadena causal es directa. Los empleados adoptan herramientas de IA más rápido de lo que los equipos de seguridad pueden evaluarlas. Sin controles de acceso, los datos sensibles fluyen hacia modelos que TI nunca aprobó y no puede auditar. Cuando ocurre una brecha, la ausencia de registro y gobernanza extiende el tiempo de detección y contención — y en la economía de las brechas, el tiempo es el principal factor de coste.

Para los directores financieros, el cálculo es sencillo: el coste esperado de una brecha relacionada con shadow AI es de 4,63 millones de dólares. El coste de un programa de gobernanza de IA empresarial — controles de acceso, despliegue de CASB, licencias de herramientas aprobadas, gestión de credenciales — es una fracción de eso. El caso ajustado al riesgo para la inversión en gobernanza no es ambiguo.

Los equipos de seguridad también enfrentan un punto ciego de DLP (Prevención de Pérdida de Datos): la mayoría de las herramientas DLP inspeccionan transferencias de datos estructurados. Los prompts de IA conversacional son texto no estructurado. Un empleado que escribe una cadena de conexión de base de datos en una cuenta LLM de nivel gratuito no genera ninguna alerta DLP. Los datos abandonan la organización silenciosamente.

La amenaza oculta: exposición de credenciales y agentes de IA

El riesgo de shadow AI más directo y menos reportado es la exposición de credenciales. Los empleados pegan secretos en LLMs públicos constantemente porque es la forma más rápida de obtener ayuda.

Un desarrollador que depura un problema de producción pega una cadena de conexión de base de datos en ChatGPT junto con el registro de errores. Un ingeniero DevOps comparte un archivo de configuración de Kubernetes, incluidas las claves API incrustadas, con un asistente de IA para preguntar sobre un fallo de despliegue. Un analista financiero sube una hoja de proyecciones del tercer trimestre a una herramienta de resumen de IA no aprobada para preparar una reunión de la junta directiva.

Según el análisis de Harmonic Security de 22,4 millones de prompts empresariales de IA (2025), el código, los documentos legales y los datos financieros comprenden el 74,5% de los datos sensibles expuestos a herramientas de IA. El código fuente por sí solo contiene secretos incrustados (claves API hardcodeadas, tokens de acceso y credenciales de cuentas de servicio) que la mayoría de los desarrolladores tratan como detalles de configuración en lugar de material crítico para la seguridad.

La capa de riesgo agéntico añade una segunda superficie de ataque. Los agentes de IA — sistemas que utilizan permisos OAuth delegados para leer archivos, enviar correos electrónicos, consultar bases de datos y llamar a APIs externas — operan con concesiones de acceso amplias que nunca fueron diseñadas para uso autónomo. Cuando un empleado autoriza a un agente de IA de productividad a acceder a su correo electrónico corporativo y almacenamiento de archivos, ese agente puede tener permisos efectivos más amplios de lo que el rol del propio empleado justifica.

La mayoría de las organizaciones no tienen un inventario de qué agentes poseen qué concesiones OAuth, ni un proceso para revocarlas cuando un empleado se va.

El 16,9% de todas las exposiciones de datos sensibles en el conjunto de datos de Harmonic fluyeron a través de cuentas personales de nivel gratuito — donde TI no tiene visibilidad, no hay registro de auditoría y los datos pueden usarse para entrenar modelos públicos (Harmonic Security, 2025).

La combinación de exposición de credenciales y acceso agéntico crea un riesgo compuesto: un agente de IA comprometido con acceso a una bóveda de secretos no gestionados puede exfiltrar mucho más que una única clave API filtrada.

Brechas reales vinculadas a Shadow AI

Estos tres incidentes comparten un hilo común: en cada caso, un componente de IA operando dentro de un entorno de confianza accedió a muchos más datos de los que alguien había autorizado explícitamente.

Microsoft AI Research: 38 TB de datos internos expuestos

Qué ocurrió. Un equipo de investigación de IA de Microsoft publicó un conjunto de datos abierto en GitHub para entrenar modelos de reconocimiento de imágenes. Para compartir los archivos, utilizaron un token SAS de Azure — pero lo configuraron con acceso completo a toda la cuenta de almacenamiento en lugar de la carpeta objetivo. Cualquiera que siguiera el enlace del repositorio obtenía acceso sin restricciones a 38 TB de datos privados de la empresa.

Qué se filtró. Copias de seguridad de estaciones de trabajo de dos empleados, más de 30.000 mensajes internos de Microsoft Teams de 359 miembros del personal, claves privadas, contraseñas de servicios y tokens secretos. El token tenía permisos de «control total» y estaba configurado para expirar en 2051.

Por qué este es un incidente de Shadow AI. La brecha ocurrió directamente en el curso del trabajo con conjuntos de datos de IA. Los investigadores, moviéndose rápido para lanzar modelos de IA, eludieron los procedimientos estándar de revisión de acceso. Wiz Research, que descubrió la exposición, lo describió como «una nueva clase de riesgo que enfrentan las organizaciones a medida que aceleran la adopción de IA». Debido a que el token otorgaba acceso de escritura, un atacante podría haber inyectado código malicioso en modelos de IA que otros desarrolladores estaban descargando activamente.

Respuesta. Wiz divulgó el incidente públicamente en septiembre de 2023. Microsoft revocó el token y cerró el acceso. El caso se convirtió en un ejemplo de referencia en el informe del Coste de una Brecha de Datos 2025 de IBM.

Slack AI: exfiltración de datos de canales privados mediante inyección de prompts

Qué ocurrió. Investigadores de PromptArmor encontraron una vulnerabilidad crítica en Slack AI — el asistente integrado que permite a los empleados consultar todo su historial de Slack en lenguaje natural. La clase de ataque fue inyección indirecta de prompts: un actor de amenazas publica un mensaje en un canal público que contiene instrucciones ocultas para el LLM. Cuando un objetivo utiliza Slack AI para buscar información, el modelo trata las instrucciones maliciosas como legítimas y las ejecuta.

Qué estaba en riesgo. Claves API y otros secretos almacenados en canales privados a los que el atacante no tenía acceso directo. Slack AI agregaba datos tanto de canales públicos como privados al responder consultas de usuarios — ese acceso entre canales era el vector de ataque. Un segundo escenario permitía que Slack AI mostrara un enlace de phishing para capturar credenciales.

Por qué este es un incidente de Shadow AI. Slack AI es un caso de libro de texto de shadow AI incrustada: una función de IA activada dentro de una herramienta corporativa ya aprobada, sin una revisión de seguridad separada de su componente de IA. Los equipos de TI no tenían visibilidad del hecho de que el asistente podía acceder a canales privados y servir como vector de exfiltración. El 14 de agosto de 2024 (el mismo día en que se divulgó la vulnerabilidad), Slack amplió las capacidades del asistente para indexar documentos cargados y archivos de Google Drive, ampliando aún más la superficie de ataque.

Respuesta. Slack inicialmente clasificó el comportamiento como «previsto», y luego emitió un parche. La empresa declaró que «no había evidencia de acceso no autorizado a datos de clientes». El incidente fue ampliamente cubierto como el primer caso documentado de exfiltración de datos mediante inyección de prompts en un producto SaaS empresarial en producción.

Microsoft 365 Copilot: EchoLeak, exfiltración de datos sin clic

Qué ocurrió. Investigadores de Aim Security divulgaron CVE-2025-32711 (CVSS 9.3 — Crítico) en Microsoft 365 Copilot, denominado EchoLeak. Es la primera inyección de prompts sin clic documentada con exfiltración de datos confirmada en un sistema de IA en producción. El ataque no requería ninguna acción de la víctima.

Cómo funcionó. Un atacante enviaba al objetivo un correo electrónico que contenía instrucciones ocultas disfrazadas de enlaces Markdown de estilo referencia. Cuando Copilot procesaba el correo electrónico, eludía el clasificador XPIA integrado (protección contra inyección de prompts) y el mecanismo de redacción de enlaces. Copilot entonces accedía automáticamente a los archivos de la víctima en OneDrive, SharePoint y Teams, construía una URL a través de la API del Proxy de Microsoft Teams — que está en la lista de permitidos de Copilot — y enviaba los datos al servidor del atacante. Sin clics requeridos.

Qué estaba en riesgo. Cualquier archivo o conversación accesible para el usuario dentro de Microsoft 365: documentos de OneDrive, archivos de SharePoint, mensajes de Teams. Para mediados de 2024, más de 10.000 empresas ya estaban ejecutando Microsoft 365 Copilot, según Netrix Global.

Por qué este es un incidente de Shadow AI. EchoLeak representa la próxima generación de riesgo de shadow AI: un agente de IA con amplio acceso a datos corporativos, operando dentro de una herramienta autorizada, sin una revisión de seguridad adecuada de su componente de IA. El ataque no dejó rastros en los sistemas de monitorización estándar — todo el tráfico se movió a través de dominios de confianza de Microsoft.

Respuesta. Microsoft emitió un parche de emergencia en junio de 2025. El caso cambió fundamentalmente cómo la industria evalúa el riesgo de los agentes de IA con amplios permisos de acceso.

Cómo detectar y prevenir Shadow AI en la empresa

La detección y prevención requieren un enfoque estructurado. Prohibir la IA por completo no funciona — los datos de Harmonic muestran que los empleados utilizan herramientas de IA independientemente de la política, a menudo a través de dispositivos personales y cuentas que eluden completamente los controles corporativos. El objetivo es la gobernanza, no la prohibición.

El marco de gobernanza de Shadow AI en 5 pasos

1. Descubrir la exposición a IA. Despliegue monitorización de red para identificar tráfico saliente a dominios de IA conocidos. Utilice un Cloud Access Security Broker (CASB) para obtener visibilidad del uso de SaaS en dispositivos gestionados. Audite las extensiones de navegador en los endpoints corporativos — muchas herramientas de IA operan como extensiones con amplio acceso al contenido de las páginas. Construya un inventario de lo que realmente se está usando antes de escribir políticas.
2. Definir políticas de uso aceptable. Clasifique las herramientas de IA en tres niveles: aprobadas (con licencia empresarial, acuerdos de procesamiento de datos vigentes), condicionales (permitidas solo para tareas no sensibles) y prohibidas (sin controles de soberanía de datos, entrenamiento de modelos públicos). Publique la política.
3. Implementar RBAC para herramientas de IA. El control de acceso basado en roles (RBAC) se aplica al acceso a herramientas de IA de la misma manera que se aplica a cualquier otro sistema. Los desarrolladores no deberían tener acceso a herramientas de IA financieras. Los equipos de finanzas no deberían tener acceso a repositorios de código alimentados en pipelines de IA. Limite las concesiones de acceso al mínimo requerido para cada rol. Revise trimestralmente.
4. Proporcionar alternativas autorizadas. Los empleados adoptan shadow AI porque las herramientas aprobadas son lentas de adquirir o inadecuadas para la tarea. Para cada categoría de herramienta prohibida, proporcione una alternativa autorizada con capacidad equivalente. Si los desarrolladores necesitan un asistente de codificación con IA, deles uno con controles de datos empresariales. La gobernanza sin habilitación genera resentimiento y soluciones alternativas.
5. Asegurar las credenciales subyacentes. Este es el paso que la mayoría de los marcos de gobernanza omiten. Incluso con políticas y CASB implementados, los empleados que tienen acceso directo a claves API sin procesar, contraseñas de bases de datos y credenciales de cuentas de servicio pueden pegarlas en cualquier herramienta. Centralizar la gestión de secretos — para que las credenciales se almacenen, inyecten y roten programáticamente en lugar de copiarse manualmente — elimina la ruta más directa desde shadow AI hasta el compromiso de credenciales.

Cómo Passwork asegura la base contra los riesgos de Shadow AI

No se puede impedir físicamente que un empleado abra una pestaña del navegador y escriba en un LLM público. Lo que sí se puede controlar es a qué tiene acceso para pegar.

El principio fundamental: eliminar el texto plano de la ecuación

Si las claves API, las credenciales de bases de datos, los secretos de producción y las contraseñas de cuentas de servicio residen en una bóveda cifrada centralizada — accedida programáticamente en lugar de copiada manualmente — el riesgo de exposición de credenciales por shadow AI se reduce sustancialmente. El desarrollador que quiere depurar un problema de producción con un asistente de IA no puede pegar la cadena de conexión de la base de datos porque nunca la tuvo en texto plano para empezar.

Qué ofrece Passwork

Passwork está disponible tanto como despliegue autoalojado como solución alojada en la nube. Ambas comparten la misma arquitectura central: cifrado AES-256 bajo un modelo de conocimiento cero, donde las credenciales se cifran en el lado del cliente antes de abandonar el dispositivo.

Cuatro controles son los más importantes en el contexto de shadow AI:

• Control de acceso basado en roles. Los administradores limitan el acceso a la bóveda a equipos y roles específicos. Un desarrollador obtiene acceso a los secretos del entorno de desarrollo, no a los de producción. El acceso se otorga por función, no por antigüedad o conveniencia.
• Registros de auditoría. Cada evento de acceso se registra: quién recuperó qué credencial, cuándo y desde qué sistema. Si una credencial aparece en algún lugar donde no debería, tiene un rastro.
• Gestión de cuentas de servicio. El riesgo de shadow AI no se limita a humanos pegando secretos en ventanas de chat. Los agentes de IA y los pipelines automatizados se ejecutan bajo cuentas de servicio — y esas cuentas acumulan permisos con el tiempo sin que nadie los revise activamente. Passwork permite almacenar, rotar y limitar las credenciales de cuentas de servicio de la misma manera que gestiona el acceso humano: con roles explícitos, políticas de expiración y un historial de acceso completo.
• Entrega de credenciales basada en API. La REST API de Passwork permite que los pipelines y las aplicaciones recuperen secretos programáticamente en tiempo de ejecución en lugar de leerlos de archivos de entorno o repositorios de configuración. La credencial nunca toca el portapapeles del desarrollador. Va directamente desde la bóveda al proceso que la necesita — y la recuperación queda registrada.

Autoalojado vs. nube

La opción autoalojada mantiene todos los datos dentro de la propia infraestructura de la organización — la elección correcta para equipos con requisitos estrictos de residencia de datos o entornos regulados. La opción en la nube elimina la carga operativa de ejecutar su propia instancia mientras preserva las mismas garantías de cifrado y controles de acceso. Ninguna opción envía credenciales en texto plano a los servidores de Passwork.

Cómo Passwork aborda los riesgos de Shadow AI

Conclusión

El sobrecoste de 670.000 $ por brecha debido a shadow AI es el coste de usar IA sin gobernanza. Las organizaciones que pagan ese sobrecoste no son casos atípicos. Son el 63% que no tenía políticas de gobernanza de IA y el 97% que carecía de controles de acceso adecuados cuando ocurrió un incidente.

La gobernanza comienza en la capa de credenciales. Un empleado que no puede acceder a secretos de producción sin procesar no puede exponerlos accidentalmente — independientemente de qué herramienta de IA abra. Ese es el punto de control que la mayoría de los marcos de shadow AI omiten, y el que ofrece la reducción de riesgo más inmediata.

Audite a qué credenciales pueden acceder sus equipos en texto plano hoy. Esa lista es su superficie de exposición a shadow AI.

Preguntas frecuentes: Shadow AI en la empresa

¿Cómo se detecta Shadow AI?

Las organizaciones pueden detectar shadow AI monitorizando los registros de red en busca de tráfico saliente inusual hacia dominios de IA, desplegando un Cloud Access Security Broker (CASB) para auditar el uso de SaaS en dispositivos gestionados y revisando las extensiones de navegador en los endpoints corporativos. Las herramientas DLP de endpoint pueden marcar grandes transferencias de texto a servicios de IA conocidos, aunque las cuentas personales de nivel gratuito siguen siendo un punto ciego persistente.

¿Cuál es un ejemplo de Shadow AI?

Un ejemplo común es un desarrollador que pega código fuente propietario en una cuenta personal de ChatGPT para depurar un problema de producción — exponiendo claves API hardcodeadas y arquitectura interna en el proceso. Otro es un equipo de marketing que sube datos confidenciales de clientes a una herramienta de resumen de IA no aprobada, o un analista financiero que comparte proyecciones del tercer trimestre con un asistente de IA de nivel gratuito para preparar materiales para la junta directiva.

¿Por qué Shadow AI es más peligrosa que Shadow IT?

Shadow IT crea problemas de residencia de datos — los datos residen en algún lugar que TI no controla. Shadow AI procesa datos: razona sobre ellos, genera resultados a partir de ellos y, en despliegues agénticos, actúa sobre ellos de forma autónoma. La exposición a través de shadow AI es a menudo irreversible, especialmente cuando los datos fluyen a través de cuentas de nivel gratuito donde pueden usarse para entrenar modelos públicos.

¿Qué credenciales corren más riesgo por Shadow AI?

Las claves API, las cadenas de conexión de bases de datos, los tokens OAuth y las contraseñas de cuentas de servicio son las credenciales de mayor riesgo. Estos son los secretos que los desarrolladores e ingenieros DevOps tienen más probabilidades de incluir en prompts de IA cuando depuran o piden ayuda con configuraciones. Los secretos hardcodeados en el código fuente están particularmente expuestos, ya que el código es la categoría más grande de datos sensibles compartidos con herramientas de IA (Harmonic Security, 2025).

¿Prohibir las herramientas de IA previene Shadow AI?

No. El análisis de Harmonic Security de 22,4 millones de prompts empresariales encontró que los empleados de más del 90% de las organizaciones utilizan activamente herramientas de IA, principalmente a través de cuentas personales que TI nunca aprobó. Las prohibiciones generales empujan el uso hacia dispositivos y cuentas personales con aún menos visibilidad. Una gobernanza efectiva combina alternativas aprobadas, políticas claras de uso aceptable y controles técnicos en la capa de acceso.

Gestión de contraseñas para equipos: la solución que toda pyme necesita

Almacenar contraseñas en Slack y navegadores expone su negocio a brechas. Descubra por qué las herramientas personales fallan para los equipos, cómo dar de baja de forma segura a empleados que se van con un solo clic, y por qué las últimas directrices del NIST recomiendan no forzar la rotación de contraseñas.

Passwork BlogAlex Muntyan

VaultJacking: cómo un único PIN puede exponer una bóveda de Google Password Manager

VaultJacking ataca el PIN de Google Password Manager para desbloquear toda su bóveda. Un único PIN capturado expone todas las contraseñas y passkeys guardadas. Descubra cómo funciona el ataque, quién está en riesgo y qué hacer si ha sido víctima de phishing.

Passwork BlogAlex Muntyan

Baja de empleados: guía de revocación segura de accesos 2026

Deshabilitar una cuenta SSO no revoca el acceso. Las claves API, las credenciales de agentes de IA y las contraseñas compartidas sobreviven. Esta guía cubre el manual completo de baja — desde los disparadores de hora cero hasta la limpieza de NHI.

Passwork BlogAlex Muntyan

Shadow AI is the unsanctioned use of AI tools, models, and agents by employees without IT knowledge or approval. The practice is widespread and largely invisible to security teams — which is exactly what makes it expensive.

According to IBM's 2025 report, organizations with high levels of shadow AI pay $670,000 more per breach than those with low or no shadow AI, bringing the expected total to $4.63M. That gap reflects unmonitored data flows, ungoverned model access, and credentials passed to third-party AI services outside any security perimeter.

The scale is harder to dismiss than most security teams expect. Developers, finance staff, HR, and operations are all adopting AI tools on their own terms. This article breaks down what shadow AI actually looks like in enterprise environments, why it creates security and compliance exposure, and what IT teams can do to get ahead of it.

What is Shadow AI?

Shadow AI is any AI tool, model, plugin, or agent used within an organization without explicit IT or security approval. It sits at the intersection of Shadow IT and generative AI, inheriting the governance blind spots of the former and adding the data-processing risks of the latter. According to Varonis data, 98% of organizations have employees using unsanctioned apps, including shadow AI.

The scope is wider than most security teams assume.

AI agents represent a qualitative shift in risk. A spreadsheet stored in an unapproved cloud drive is a data exposure problem. An AI agent with delegated access to your email, calendar, and file system is an access governance problem.

Shadow IT vs. Shadow AI: Understanding the risk multiplier

Shadow IT and Shadow AI both involve employees using tools outside IT's visibility. The risk profile is fundamentally different.

Shadow IT (unauthorized SaaS, personal cloud storage, unmanaged devices) primarily creates data residency and compliance problems. Data sits somewhere IT doesn't control. The exposure is largely static.

Shadow AI processes data. It reasons over it, summarizes it, generates outputs from it, and in the case of agentic systems, acts on it. The exposure is dynamic and often irreversible.

The SaaS sprawl problem compounds this. Employees use 665+ AI tools across a typical enterprise environment, according to Harmonic Security's analysis of 22 million enterprise AI prompts (2025). Six applications account for 92.6% of sensitive data exposure but blocking the remaining 659 is operationally futile and destroys productivity. The governance challenge is visibility, classification, and controlled access.

The financial impact: Why Shadow AI costs enterprises $670K per breach

According to IBM's 2025 Cost of a Data Breach Report, breaches involving high levels of shadow AI add $670,000 to the average breach cost compared to those with low or no shadow AI — a 16% increase, bringing the expected total to $4.63M per incident.

Two underlying statistics explain the mechanism:

• 97% of organizations that experienced an AI-related security incident lacked proper AI access controls.
• 63% of breached organizations had no governance policies for managing AI or detecting unauthorized use.

The causal chain is direct. Employees adopt AI tools faster than security teams can evaluate them. Without access controls, sensitive data flows into models that IT never approved and cannot audit. When a breach occurs, the absence of logging and governance extends detection and containment time — and in breach economics, time is the primary cost driver.

For CFOs, the calculation is straightforward: the expected cost of a shadow AI-related breach is $4.63M. The cost of an enterprise AI governance program — access controls, CASB deployment, approved tool licensing, credential management — is a fraction of that. The risk-adjusted case for governance investment is not ambiguous.

Security teams also face a DLP (Data Loss Prevention) blind spot: most DLP tools inspect structured data transfers. Conversational AI prompts are unstructured text. An employee typing a database connection string into a free-tier LLM account generates no DLP alert. The data leaves the organization silently.

The hidden threat: Credential exposure and AI agents

The most direct and underreported shadow AI risk is credential exposure. Employees paste secrets into public LLMs constantly because it's the fastest path to getting help.

A developer debugging a production issue pastes a database connection string into ChatGPT along with the error log. A DevOps engineer shares a Kubernetes config file, including embedded API keys, with an AI assistant to ask about a deployment failure. A finance analyst uploads a Q3 projection spreadsheet to an unapproved AI summarization tool to prepare for a board meeting.

According to Harmonic Security's analysis of 22.4 million enterprise AI prompts (2025), code, legal documents, and financial data comprise 74.5% of sensitive data exposed to AI tools. Source code alone carries embedded secrets (hardcoded API keys, access tokens, and service account credentials) that most developers treat as configuration details rather than security-critical material.

The agentic risk layer adds a second attack surface. AI agents — systems that use delegated OAuth permissions to read files, send emails, query databases, and call external APIs — operate with broad access grants that were never designed for autonomous use. When an employee authorizes a productivity AI agent to access their corporate email and file storage, that agent may have broader effective permissions than the employee's own role warrants.

Most organizations have no inventory of which agents hold which OAuth grants, and no process for revoking them when an employee leaves.

16.9% of all sensitive data exposures in Harmonic's dataset flowed through personal free-tier accounts — where IT has zero visibility, no audit trail, and data may be used to train public models (Harmonic Security, 2025).

The combination of credential exposure and agentic access creates a compounding risk: a compromised AI agent with access to a vault of unmanaged secrets can exfiltrate far more than a single leaked API key.

Real breaches tied to Shadow AI

These three incidents share a common thread: in each case, an AI component operating inside a trusted environment accessed far more data than anyone had explicitly authorized.

Microsoft AI Research: 38 TB of internal data exposed

What happened. A Microsoft AI research team published an open dataset on GitHub for training image recognition models. To share the files, they used an Azure SAS token — but configured it with full access to the entire Storage Account instead of the target folder. Anyone following the repository link got unrestricted access to 38 TB of private company data.

What leaked. Workstation backups from two employees, over 30,000 internal Microsoft Teams messages from 359 staff members, private keys, service passwords, and secret tokens. The token carried "full control" permissions and was set to expire in 2051.

Why this is a Shadow AI incident. The breach happened directly in the course of AI dataset work. Researchers, moving fast to ship AI models, bypassed standard access review procedures. Wiz Research, which discovered the exposure, described it as "a new class of risk organizations face as they accelerate AI adoption." Because the token granted write access, an attacker could have injected malicious code into AI models that other developers were actively downloading.

Response. Wiz disclosed the incident publicly in September 2023. Microsoft revoked the token and closed access. The case became a reference example in IBM's Cost of a Data Breach 2025 report.

Slack AI: Data exfiltration from private channels via prompt injection

What happened. Researchers at PromptArmor found a critical vulnerability in Slack AI — the built-in assistant that lets employees query their entire Slack history in natural language. The attack class was indirect prompt injection: a threat actor posts a message in a public channel containing hidden instructions for the LLM. When a target uses Slack AI to search for information, the model treats the malicious instructions as legitimate and executes them.

What was at risk. API keys and other secrets stored in private channels the attacker had no direct access to. Slack AI aggregated data from both public and private channels when answering user queries — that cross-channel access was the attack vector. A second scenario allowed Slack AI to render a phishing link to capture credentials.

Why this is a Shadow AI incident. Slack AI is a textbook embedded shadow AI case: an AI feature activated inside an already-approved corporate tool, with no separate security review of its AI component. IT teams had no visibility into the fact that the assistant could reach private channels and serve as an exfiltration vector. On August 14, 2024 (the same day the vulnerability was disclosed) Slack expanded the assistant's capabilities to index uploaded documents and Google Drive files, widening the attack surface further.

Response. Slack initially classified the behavior as "intended," then issued a patch. The company stated there was "no evidence of unauthorized customer data access." The incident was widely covered as the first documented case of data exfiltration via prompt injection in a production enterprise SaaS product.

Microsoft 365 Copilot: EchoLeak, zero-click data exfiltration

What happened. Researchers at Aim Security disclosed CVE-2025-32711 (CVSS 9.3 — Critical) in Microsoft 365 Copilot, named EchoLeak. It is the first documented zero-click prompt injection with confirmed data exfiltration in a production AI system. The attack required no action from the victim.

How it worked. An attacker sent the target an email containing hidden instructions disguised as reference-style Markdown links. When Copilot processed the email, it bypassed the built-in XPIA classifier (prompt injection protection) and the link-redaction mechanism. Copilot then automatically accessed the victim's files in OneDrive, SharePoint, and Teams, constructed a URL through the Microsoft Teams Proxy API — which sits on Copilot's allowlist — and sent the data to the attacker's server. No clicks required.

What was at risk. Any file or conversation accessible to the user within Microsoft 365: OneDrive documents, SharePoint files, Teams messages. By mid-2024, more than 10,000 companies were already running Microsoft 365 Copilot, according to Netrix Global.

Why this is a Shadow AI incident. EchoLeak represents the next generation of shadow AI risk: an AI agent with broad access to corporate data, operating inside a sanctioned tool, with no adequate security review of its AI component. The attack left no traces in standard monitoring systems — all traffic moved through trusted Microsoft domains.

Response. Microsoft issued an emergency patch in June 2025. The case fundamentally changed how the industry assesses risk for AI agents with wide access permissions.

How to detect and prevent Shadow AI in the enterprise

Detection and prevention require a structured approach. Banning AI entirely does not work — Harmonic's data shows employees use AI tools regardless of policy, often through personal devices and accounts that bypass corporate controls entirely. The goal is governance, not prohibition.

The 5-step Shadow AI governance framework

1. Discover AI exposure. Deploy network monitoring to identify outbound traffic to known AI domains. Use a Cloud Access Security Broker (CASB) to gain visibility into SaaS usage across managed devices. Audit browser extensions on corporate endpoints — many AI tools operate as extensions with broad page-content access. Build an inventory of what's actually in use before writing policy.
2. Define acceptable use policies. Classify AI tools into three tiers: approved (enterprise-licensed, data processing agreements in place), conditional (permitted for non-sensitive tasks only), and prohibited (no data sovereignty controls, public model training). Publish the policy.
3. Implement RBAC for AI tools. Role-based access control (RBAC) applies to AI tool access the same way it applies to any other system. Developers should not have access to financial AI tools. Finance teams should not have access to code repositories fed into AI pipelines. Scope access grants to the minimum required for each role. Review quarterly.
4. Provide sanctioned alternatives. Employees adopt shadow AI because approved tools are slow to procure or inadequate for the task. For every prohibited tool category, provide a sanctioned alternative with equivalent capability. If developers need an AI coding assistant, give them one with enterprise data controls. Governance without enablement creates resentment and workarounds.
5. Secure the underlying credentials. This is the step most governance frameworks skip. Even with policies and CASB in place, employees who have direct access to raw API keys, database passwords, and service account credentials can paste them into any tool. Centralizing secrets management — so that credentials are stored, injected, and rotated programmatically rather than copied manually — removes the most direct path from shadow AI to credential compromise.

How Passwork secures the foundation against Shadow AI risks

You cannot physically prevent an employee from opening a browser tab and typing into a public LLM. What you can control is what they have access to paste.

The core principle: remove plaintext from the equation

If API keys, database credentials, production secrets, and service account passwords live in a centralized encrypted vault — accessed programmatically rather than copied manually — the credential exposure risk from shadow AI drops substantially. The developer who wants to debug a production issue with an AI assistant cannot paste the database connection string because they never had it in plaintext to begin with.

What Passwork provides

Passwork is available as both a self-hosted deployment and a cloud-hosted solution. Both share the same core architecture: AES-256 encryption under a zero-knowledge model, where credentials are encrypted client-side before leaving the device.

Four controls matter most in the shadow AI context:

• Role-based access control. Administrators scope vault access to specific teams and roles. A developer gets access to development environment secrets, not production. Access is granted by function, not by seniority or convenience.
• Audit logs. Every access event is recorded: who retrieved which credential, when, and from which system. If a credential surfaces somewhere it shouldn't, you have a trail.
• Service account management. Shadow AI risk isn't limited to humans pasting secrets into chat windows. AI agents and automated pipelines run under service accounts — and those accounts accumulate permissions over time with no one actively reviewing them. Passwork lets you store, rotate, and scope service account credentials the same way you manage human access: with explicit roles, expiry policies, and a full access history.
• API-first credential delivery. Passwork's REST API lets pipelines and applications retrieve secrets programmatically at runtime instead of reading them from environment files or config repositories. The credential never touches a developer's clipboard. It goes directly from the vault to the process that needs it — and the retrieval is logged.

Self-hosted vs. cloud

The self-hosted option keeps all data within the organization's own infrastructure — the right choice for teams with strict data residency requirements or regulated environments. The cloud option removes the operational overhead of running your own instance while preserving the same encryption guarantees and access controls. Neither option sends plaintext credentials to Passwork's servers.

How Passwork addresses Shadow AI risks

Conclusion

The $670K breach cost premium for shadow AI is the cost of using AI without governance. The organizations paying that premium are not outliers. They are the 63% that had no AI governance policies and the 97% that lacked proper access controls when an incident occurred.

Governance starts at the credential layer. An employee who cannot access raw production secrets cannot accidentally expose them — regardless of which AI tool they open. That is the control point that most shadow AI frameworks miss, and the one that delivers the most immediate risk reduction.

Audit which credentials your teams can access in plaintext today. That list is your shadow AI exposure surface.

FAQ: Shadow AI in the enterprise

How do you detect Shadow AI?

Organizations can detect shadow AI by monitoring network logs for unusual outbound traffic to AI domains, deploying a Cloud Access Security Broker (CASB) to audit SaaS usage across managed devices, and reviewing browser extensions on corporate endpoints. Endpoint DLP tools can flag large text transfers to known AI services, though free-tier personal accounts remain a persistent blind spot.

What is an example of Shadow AI?

A common example is a developer pasting proprietary source code into a personal ChatGPT account to debug a production issue — exposing hardcoded API keys and internal architecture in the process. Another is a marketing team uploading confidential customer data to an unapproved AI summarization tool, or a finance analyst sharing Q3 projections with a free-tier AI assistant to prepare board materials.

Why is Shadow AI more dangerous than Shadow IT?

Shadow IT creates data residency problems — data sits somewhere IT doesn't control. Shadow AI processes data: it reasons over it, generates outputs from it, and in agentic deployments, acts on it autonomously. Exposure through shadow AI is often irreversible, especially when data flows through free-tier accounts where it may be used to train public models.

What credentials are most at risk from Shadow AI?

API keys, database connection strings, OAuth tokens, and service account passwords are the highest-risk credentials. These are the secrets developers and DevOps engineers are most likely to include in AI prompts when debugging or asking for configuration help. Hardcoded secrets in source code are particularly exposed, since code is the single largest category of sensitive data shared with AI tools (Harmonic Security, 2025).

Does banning AI tools prevent Shadow AI?

No. Harmonic Security's analysis of 22.4 million enterprise prompts found that employees at over 90% of organizations actively use AI tools, mostly through personal accounts that IT never approved. Blanket bans push usage to personal devices and accounts with even less visibility. Effective governance combines approved alternatives, clear acceptable-use policies, and technical controls at the access layer.

Password management for teams: The fix every SMB needs

Storing passwords in Slack and browsers exposes your business to breaches. Discover why personal tools fail teams, how to securely offboard departing employees in one click, and why the latest NIST guidelines recommend against forced password rotation.

Passwork BlogAlex Muntyan

VaultJacking: How one PIN can expose a Google password manager vault

VaultJacking targets the Google Password Manager PIN to unlock your entire vault. One captured PIN exposes every saved password and passkey. Learn how the attack works, who’s at risk, and what to do if you’ve been phished.

Passwork BlogAlex Muntyan

Employee offboarding: Secure access revocation guide 2026

Disabling an SSO account doesn’t revoke access. API keys, AI agent credentials, and shared passwords survive it. This guide covers the full offboarding playbook — from zero-hour triggers to NHI cleanup.

Passwork BlogAlex Muntyan

Stellen Sie sich einen Montagmorgen vor. Jemand aus dem Marketing-Team muss etwas auf Instagram posten. Die Person, die das Passwort kennt, ist krank. Jemand fragt in Slack nach. Jemand anderes fügt es ein. Jetzt befindet sich dieses Passwort in einem Chat-Verlauf, auf einem privaten Smartphone und möglicherweise auf einem Laptop, der das Unternehmen vor sechs Monaten verlassen hat.

Die Absicherung dieses Workflows erfordert keine komplexe IT-Initiative oder monatelange Planung. Diese Schwachstellen können an einem einzigen Nachmittag beseitigt werden.

Ein Team-Passwortmanager (ein gemeinsamer, verschlüsselter Tresor) ermöglicht es Ihrem Team, Zugangsdaten zu speichern und abzurufen, ohne sie jemals per E-Mail oder Slack zu versenden. Er bietet präzise Kontrolle darüber, wer welche Passwörter sieht, und ermöglicht es, den Zugriff sofort zu widerrufen, wenn ein Mitarbeiter das Unternehmen verlässt. Die meisten Teams richten das System innerhalb weniger Stunden ein.

Wichtige Erkenntnisse

• Die Wurzel des Passwort-Chaos: Die meisten Zugangsdaten kleiner Unternehmen sammeln sich in Slack-Kanälen, Tabellenkalkulationen und persönlichen Browsern an, weil Teams kein zentrales System haben — das schafft einfache Einstiegspunkte für Angreifer.
• Die Browser-Einschränkung: Im Browser gespeicherte Passwörter gehören zu einzelnen Accounts und bieten keine sichere Freigabe, keine rollenbasierte Zugriffskontrolle und keine Audit-Protokolle — das macht sie ungeeignet für Team-Umgebungen.
• Der blinde Fleck beim Offboarding: Das Deaktivieren der E-Mail eines ausscheidenden Mitarbeiters lässt Zugang zu Anbieterportalen, Social-Media-Konten und gemeinsamen Postfächern bestehen. Diese unkontrollierten Zugangsdaten bleiben monatelang aktiv, wenn sie nicht systematisch erfasst und rotiert werden.
• Moderne Passwort-Standards: Die neuesten NIST-Richtlinien empfehlen, auf erzwungene 90-Tage-Passwortänderungen zu verzichten. Obligatorische Rotationen führen zu vorhersehbaren Mustern und schwächen dadurch aktiv die Sicherheit.
• Einrichtung an einem Nachmittag: Der Umstieg auf einen dedizierten Team-Passwortmanager dauert nur wenige Stunden. Für Organisationen mit strengen Anforderungen an die Datenresidenz hält die Self-Hosted-Bereitstellung alle Zugangsdaten vollständig innerhalb der eigenen Infrastruktur.

Wo die Passwörter Ihres Teams gerade wirklich gespeichert sind

In den meisten kleinen Unternehmen landen Passwörter verstreut in Slack-Nachrichten, gemeinsamen Tabellenkalkulationen, persönlichen Browser-Accounts und auf Haftnotizen — nicht weil die Leute nachlässig sind, sondern weil nie ein dediziertes System eingerichtet wurde. Laut dem 2025 Verizon Data Breach Investigations Report beginnen 22 % aller bestätigten Datenschutzverletzungen mit gestohlenen oder kompromittierten Zugangsdaten, und 88 % der Angriffe auf einfache Webanwendungen beinhalten gestohlene Logins.

Hier landen Passwörter typischerweise:

• Eine Slack-DM oder ein Gruppenchat — durchsuchbar für jeden im Workspace
• Eine Tabelle namens passwords_final_v3.xlsx auf einem gemeinsamen Laufwerk
• Der persönliche Browser von jemandem, verknüpft mit dessen privatem Google-Account
• Eine gemeinsame Notizen-App, auf die drei Personen Zugriff haben und die niemand verwaltet
• Der persönliche Passwortmanager-Account von jemandem, über den das Unternehmen keine Kontrolle hat

Das sammelt sich Stück für Stück an — ein gemeinsames Login nach dem anderen. Niemand hat beschlossen, Passwörter in Slack zu speichern. Es passierte einfach, weil es nie eine bessere Option gab. Angreifer gehen zur einfachsten Tür. Ein in einen Chat-Kanal eingefügtes Passwort ist eine sehr einfache Tür.

Warum das Speichern von Passwörtern im Browser für ein Team nicht ausreicht

Im Browser gespeicherte Passwörter funktionieren gut für eine einzelne Person, die ihre eigenen Accounts verwaltet. Für ein Team bricht das Modell zusammen, sobald jemand Zugriff teilen muss, das Unternehmen verlässt oder ein Projekt übergibt — denn Browser-Passwörter sind an den Account einer Person gebunden und wurden nie dafür konzipiert, geteilt oder gruppenübergreifend verwaltet zu werden.

Das Kernproblem: Im Browser gespeicherte Passwörter gehören zum Gerät und Account einer einzelnen Person. Wenn diese Person geht, gehen diese Passwörter entweder mit ihr oder bleiben in einem Account gesperrt, über den das Unternehmen keine Kontrolle mehr hat. Es gibt ein noch größeres Risiko: Alle im Browser gespeicherten Passwörter werden zusammen gespeichert, sodass ein kompromittiertes Gerät oder Account bedeutet, dass alles durchsickert — nicht nur ein Passwort.

Teilen ist die andere Lücke. Es gibt keine Möglichkeit, einem Teammitglied Zugriff auf ein im Browser gespeichertes Passwort zu geben, ohne es abzutippen, einen Screenshot zu machen oder es in einen Messenger einzufügen. Laut der 2025-Analyse von Heimdal Security wurden 94 % der geleakten Passwörter wiederverwendet oder über mehrere Accounts hinweg dupliziert — genau das Muster, das informelles Teilen fördert.

Es gibt auch keine Audit-Protokolle. Keine Aufzeichnung darüber, wer sich freitagabends um 23 Uhr in das E-Mail-Marketing-Tool eingeloggt hat. Keine Möglichkeit, den Zugriff auf ein bestimmtes Konto zu widerrufen, ohne das Passwort überall zu ändern und allen das neue mitzuteilen — was den ganzen Kreislauf von vorne beginnt.

Der Browser ist ein persönliches Werkzeug, das für den Team-Einsatz zweckentfremdet wird. Er wurde nie dafür gebaut.

Das Problem, über das niemand spricht — wenn ein Mitarbeiter geht

Die meisten Unternehmen handhaben das Offboarding, indem sie die E-Mail deaktivieren, den Laptop einsammeln und die Person aus Slack entfernen. Das deckt nur einen Bruchteil des eigentlichen Zugriffsproblems ab. Die Passwörter, die diese Person kannte (für gemeinsam genutzte Tools, Anbieterportale, Social-Media-Accounts und das Büro-WLAN), stehen fast nie auf der Checkliste. Und dieser Zugriff wird selten schnell erkannt — laut IBMs Cost of a Data Breach Report 2025 dauert es bei Zugangsdaten-basierten Datenschutzverletzungen durchschnittlich 246 Tage, bis sie identifiziert und eingedämmt werden. Das sind 8 Monate offener Zugriff, bevor irgendjemand bemerkt, dass etwas nicht stimmt.

Denken Sie an einen Kundensupport-Manager, der seit zwei Jahren im Unternehmen ist. Diese Person kannte das Passwort für die Helpdesk-Software, das gemeinsame Support-Postfach, den Social-Media-Planer, den Canva-Account des Unternehmens und das WLAN. Nichts davon wird durch „Google-Workspace-Account deaktivieren" abgedeckt. SSO — der „Mit Google anmelden"-Button — deckt nur Apps ab, die mit Ihrem Identity Provider verbunden sind. Die meisten Tools, die ein typisches kleines Unternehmen nutzt, sind das nicht.

Das 3-Fragen-Offboarding-Audit

Wenn jemand geht, stellen Sie diese drei Fragen vor dem letzten Arbeitstag:

• Auf welche gemeinsam genutzten Accounts hatte die Person Zugriff? Denken Sie über E-Mail hinaus — Software-Abonnements, Social Media, Anbieterportale, gemeinsame Postfächer, WLAN.
• Welche dieser Passwörter müssen geändert werden? Jeder Account, auf den regelmäßig zugegriffen wurde und der nicht durch SSO abgedeckt ist.
• Wer ist für die Änderung verantwortlich? Benennen Sie eine konkrete Person. „Jemand aus der IT" ist keine Antwort, wenn Sie keine IT-Abteilung haben.

Dieses Audit dauert beim ersten Mal 15 Minuten — aber es funktioniert nur, wenn bereits bekannt ist, welche Accounts existieren und wer darauf Zugriff hatte. Ohne dieses Inventar werden aus den 15 Minuten ein Gespräch, das mit „Ich glaube, die hatten Zugriff darauf, bin mir nicht sicher" endet. Ohne Passwortmanager ist Frage drei eine Verhandlung — wer hat Zeit, wer weiß welche Accounts existieren, wer wird das wirklich durchziehen. Mit einem ist es eine Checkliste: Das Security Dashboard öffnen, jede Zugangsdaten sehen, die diese Person berührt hat, genau diese rotieren.

Was ein Team-Passwortmanager tatsächlich leistet

Ein Team-Passwortmanager ist ein gemeinsamer, verschlüsselter Tresor, in dem alle auf die Passwörter zugreifen, die sie brauchen — und nur auf diese. Er ersetzt verstreute Zugangsdaten durch ein kontrolliertes System. Die meisten Teams sind innerhalb eines Nachmittags vollständig eingerichtet.

Worauf bei der Auswahl zu achten ist:

• Rollenbasierte Zugriffskontrolle (RBAC). Das Marketing-Team sieht die Social-Media-Passwörter. Finance sieht die Logins für die Buchhaltungssoftware. Der CEO sieht alles. Wenn jemand neu anfängt, wird die Person zum Tresor ihres Teams hinzugefügt und hat sofort Zugriff. Beim Ausscheiden wird der Zugriff in einem Schritt widerrufen — und das Security Dashboard von Passwork zeigt sofort jedes Passwort, auf das Zugriff bestand, sodass genau diese Zugangsdaten rotiert werden können. Kein Rätselraten, kein manuelles Audit darüber, wer was hatte.
• Zero-Knowledge-Verschlüsselung bedeutet, dass Passwörter auf Ihrem Gerät verschlüsselt werden, bevor sie den Server erreichen. Der Server speichert Chiffretext, keine Zugangsdaten — sodass weder die Hosting-Infrastruktur noch der Systemadministrator lesen kann, was drin ist. Zugriff auf den Server bedeutet nicht Zugriff auf die Passwörter.
• Audit-Protokolle. Jede Anmeldung, jede Passwort-Ansicht, jede Änderung wird protokolliert. Wenn etwas schiefgeht, wissen Sie genau, wer wann auf was zugegriffen hat — keine grobe Schätzung.
• Einfaches Onboarding. Ein Tool, das niemand nutzt, ist kein Sicherheitstool. Achten Sie auf einen Einrichtungsprozess, der kein dediziertes IT-Projekt erfordert: Import aus CSV, Browser-Erweiterung, klare Ordnerstruktur vom ersten Tag an.
• Eine Benutzeroberfläche, die Ihr Team tatsächlich nutzen wird. Reibung ist der Feind der Akzeptanz. Wenn das Finden eines Passworts mehr als drei Klicks erfordert, gehen die Leute zurück zu Slack.
• Zwei-Faktor-Authentifizierung. Eine zweite Bestätigung bei der Anmeldung bedeutet, dass ein gestohlenes Masterpasswort allein nicht ausreicht, um reinzukommen. Nicht verhandelbar für jeden Business-Account.

Für Unternehmen mit strengen Datenanforderungen (Gesundheitswesen, Finanzen, Recht) können einige Tools auf den eigenen Servern gehostet werden statt in einer Drittanbieter-Cloud. Passwork ist speziell für Self-Hosted-Bereitstellung konzipiert und hält alle Zugangsdaten innerhalb der eigenen Infrastruktur. Teams, die sehen möchten, wie Passwortsicherheit weniger lästig gestaltet werden kann, werden feststellen, dass das Modell unkompliziert zu übernehmen ist.

Die neuen Passwort-Regeln: Was die neuesten NIST-Richtlinien wirklich sagen

Das U.S. National Institute of Standards and Technology (NIST) hat seine Passwort-Richtlinien 2025 aktualisiert, und die Haupterkenntnis ist kontraintuitiv: Erzwungene Passwortrotation — Mitarbeiter dazu zu zwingen, ihr Passwort alle 60 oder 90 Tage zu ändern — verschlechtert die Sicherheit. NIST SP 800-63B empfiehlt jetzt ausdrücklich, auf obligatorische periodische Zurücksetzungen zu verzichten, es sei denn, es gibt Hinweise auf eine Kompromittierung.

Der Grund ist vorhersehbares menschliches Verhalten. Wenn Menschen gezwungen werden, Passwörter ständig zu ändern, nehmen sie die kleinstmögliche Änderung vor: Summer2024! wird zu Summer2025!. Die Struktur bleibt gleich, das Muster ist offensichtlich, und das Ergebnis ist nicht sicherer als vorher — nur nerviger.

Was NIST stattdessen empfiehlt:

• Längere Passwörter — eine Passphrase wie correct-horse-battery-staple ist stärker als P@$$w0rd1 und viel leichter zu merken
• Keine erzwungene Rotation, es sei denn, es gibt Hinweise auf eine Verletzung oder Kompromittierung
• Prüfung neuer Passwörter gegen bekannte Breach-Datenbanken, sodass bereits geleakte Zugangsdaten bei der Erstellung abgelehnt werden

Wenn Ihre Unternehmensrichtlinie immer noch 90-Tage-Zurücksetzungen vorschreibt, lohnt es sich, das zu überdenken. Ein guter Team-Passwortmanager übernimmt die schwierigen Teile automatisch — er generiert starke, einzigartige Passwörter für jeden Account und markiert alle, die in bekannten Breach-Datenbanken aufgetaucht sind.

So richten Sie die Passwortverwaltung für Ihr Team ein — ein praktischer Startpunkt

Die Einrichtung eines Team-Passwortmanagers erfordert keine technische Expertise oder eine dedizierte IT-Person. Diese fünf Schritte bringen die Passwörter Ihres Teams aus Slack und Tabellenkalkulationen in einen gemeinsamen, verschlüsselten Tresor — die meisten Teams schließen den Prozess an einem einzigen Nachmittag ab.

Die 5-Schritte-Team-Tresor-Einrichtung

1. Inventur des Bestands. Verbringen Sie 30 Minuten damit, jeden gemeinsam genutzten Account aufzulisten, den Ihr Team verwendet — Software-Abonnements, Social-Media-Profile, Anbieterportale, gemeinsame Postfächer, WLAN-Passwörter. Versuchen Sie nicht, vollständig zu sein. Erfassen Sie zuerst die offensichtlichen; der Rest taucht im Laufe der Zeit auf.
2. Wählen Sie ein Tool, das zu Ihrem Team passt. Für die meisten kleinen Unternehmen funktioniert ein Cloud-basierter Team-Tresor gut und erfordert keine technische Einrichtung. Wenn Ihr Unternehmen sensible Kundendaten verarbeitet und alles intern gespeichert werden muss, suchen Sie nach Tools, die Self-Hosted-Bereitstellung anbieten — das bedeutet, die Software läuft auf Ihren eigenen Servern, nicht in der Cloud des Anbieters. In jedem Fall sollten Sie Tools priorisieren, die Zero-Knowledge-Verschlüsselung und Zwei-Faktor-Authentifizierung bieten.
3. Richten Sie Passwort-Tresore nach Team oder Funktion ein. Marketing bekommt die Marketing-Passwörter. Finance bekommt die Finance-Passwörter. Halten Sie die Struktur einfach — weitere Tresore können später hinzugefügt werden. Komplexität bei der Einrichtung ist der Hauptgrund, warum Teams das Tool in der zweiten Woche aufgeben.
4. Migrieren Sie zuerst ein Team. Versuchen Sie nicht, das gesamte Unternehmen auf einmal umzustellen. Beginnen Sie mit einer Abteilung, gewöhnen Sie sie an den Workflow und erweitern Sie dann. Ein reibungsloser Rollout mit fünf Personen ist besser als ein chaotischer mit fünfzig.
5. Aktualisieren Sie Ihre Offboarding-Checkliste. Fügen Sie eine Zeile hinzu: „Aus dem Passwort-Tresor entfernen." Das ist die ganze Änderung. Das System erledigt den Rest.

So handhabt Passwork das in der Praxis

Passwork ist ein Passwort- und Secrets-Manager, der für Business-Teams entwickelt wurde. Er bietet IT-Administratoren einen zentralen Ort, um Zugangsdaten zu speichern, zu teilen und den Zugriff zu kontrollieren — ohne auf Browser-Tresore, gemeinsame Tabellenkalkulationen oder Messenger-Threads angewiesen zu sein.

Das wird direkt abgedeckt:

• Gemeinsamer Tresor mit strukturiertem Zugriff. Passwörter sind in Ordnern nach Team oder Funktion organisiert. Marketing sieht, was Marketing braucht. DevOps sieht, was DevOps braucht. Niemand sieht mehr als seine Rolle erfordert.
• Rollenbasierte Zugriffskontrolle. Berechtigungen werden Rollen zugewiesen, nicht Einzelpersonen. Das Hinzufügen eines neuen Mitarbeiters zur richtigen Rolle gibt ihm sofortigen Zugriff auf die benötigten Zugangsdaten. Das Entfernen eines ausscheidenden Mitarbeiters widerruft ihn sofort über alle gemeinsamen Ordner hinweg.
• Security Dashboard fürs Offboarding. Wenn jemand geht, zeigt das Dashboard jede Zugangsdaten, auf die Zugriff bestand. Genau diese rotieren — nicht mehr, nicht weniger. Keine Rekonstruktion aus dem Gedächtnis, kein Rätselraten darüber, was sichtbar war.
• SSO-Integration. Passwork verbindet sich über SAML mit Ihrem bestehenden Identity Provider. Wenn der Zugriff bereits über Active Directory oder ein ähnliches System verwaltet wird, fügt sich Passwork in diese Struktur ein, anstatt außerhalb davon zu stehen.
• Bereitstellungsoptionen. Passwork läuft als Cloud-Service oder als Self-Hosted-Installation auf Ihrer eigenen Infrastruktur. Für Teams im Gesundheitswesen, Finanzwesen oder Rechtswesen — wo Zugangsdaten die Server der Organisation nicht verlassen dürfen — hält die Self-Hosted-Bereitstellung alles innerhalb des eigenen Perimeters.

Die oben genannten Funktionen sind keine neuen Konzepte — RBAC, Audit-Protokolle und SSO existieren in Enterprise-Tools, deren Bereitstellung Monate dauert. Passwork bündelt sie für Teams, die keine dedizierte Sicherheitsabteilung haben und bis Freitag einsatzbereit sein müssen.

Die Passwörter Ihres Teams unter Kontrolle bringen

Die Technologie ist der einfache Teil. Ein Team-Passwortmanager ist unkompliziert einzurichten, und die meisten Teams bemerken den Unterschied innerhalb einer Woche — weniger „Hat jemand das Login für X?"-Nachrichten, keine Passwort-Tabellenkalkulationen mehr und eine klare Antwort auf „Was passiert, wenn jemand geht?"

Die schwierigere Arbeit sind die ersten Wochen: Inventur der bereits existierenden Zugangsdaten, Entscheidung darüber, wer welche Ordner besitzt, und Ablösung des bisherigen Systems. Beginnen Sie mit der Inventur. Alles andere folgt daraus, dass bekannt ist, was tatsächlich vorhanden ist.

Passwork läuft in der Cloud oder auf Ihren eigenen Servern — Ihre Wahl. Teams mit Anforderungen an die Datenresidenz oder internen Sicherheitsrichtlinien, die Drittanbieter-Cloud-Speicher ausschließen, können es On-Premises bereitstellen. Alle anderen können noch am selben Tag in der Cloud einsatzbereit sein.

Häufig gestellte Fragen

Brauchen wir wirklich einen Team-Passwortmanager, wenn wir ein kleines Team sind?

Ja. Kleine Teams sind oft stärker gefährdet, gerade weil es keine dedizierte IT-Person gibt, die auf Probleme achtet. Ein Team-Passwortmanager ist in etwa einem Nachmittag eingerichtet und beseitigt einen der häufigsten Einstiegspunkte für Datenschutzverletzungen — gemeinsame Zugangsdaten ohne Zugriffskontrollen. Je kleiner das Team, desto schneller die Einrichtung.

Ist es sicher, alle unsere Passwörter an einem Ort zu speichern?

Ein seriöser Passwortmanager ist weitaus sicherer als die Alternativen — Slack-Nachrichten, Tabellenkalkulationen oder Haftnotizen. Die Daten werden mit Zero-Knowledge-Verschlüsselung geschützt, was bedeutet, dass die Passwörter selbst dann unlesbar wären, wenn jemand in die Server des Anbieters einbrechen würde. Das Risiko der Konsolidierung ist viel geringer als das Risiko verstreuter, unkontrollierter Zugangsdaten.

Was ist mit Apps, die „Mit Google anmelden" unterstützen?

SSO deckt Apps ab, die mit Ihrem Identity Provider verbunden sind, aber die meisten kleinen Unternehmen nutzen eine Mischung aus SSO-kompatiblen und nicht kompatiblen Tools. Ein Team-Passwortmanager handhabt alles, was SSO nicht erreicht — Anbieterportale, Legacy-Software, gemeinsame Social-Media-Accounts und jedes Tool, das ein eigenes Login erfordert.

Wie bringen wir das Team dazu, es tatsächlich zu nutzen?

Das Tool funktioniert nur, wenn es konsequent genutzt wird. Der schnellste Weg zur Akzeptanz: Es einfacher machen als die Alternative. Wenn der Tresor eingerichtet ist, mit den Passwörtern gefüllt, die die Leute tatsächlich brauchen, und vom ersten Tag an auf ihren Geräten zugänglich ist, wechseln die meisten ohne Reibung. Machen Sie es zunächst für gemeinsame Accounts verpflichtend, die persönlichen Workflow-Gewohnheiten folgen.

10 Sicherheitsfehler bei Remote-Arbeit (und wie man sie behebt)

10 Sicherheitsfehler bei Remote-Arbeit — und das eine Prinzip dahinter: Sicherheit versagt dort, wo der sichere Weg mehr Reibung hat als der unsichere. Echte Fälle, realistische Lösungen, eine 5-Schichten-Baseline, gegen die Ihr Team prüfen kann.

Passwork BlogAlex Muntyan

Brute-Force-Angriffe 2026: Arten, Beispiele und wie man sie verhindert

GPU-Cluster, KI-unterstützte Wortlisten, Botnets mit 2,8 Millionen Geräten. Brute Force hat sich skaliert. Dieser Leitfaden behandelt sechs Angriffsvarianten, reale Fälle aus 2025 und eine mehrschichtige Verteidigungsstrategie, die Ihr Team heute umsetzen kann.

Passwork BlogAlex Muntyan

Shadow IT vs. Shadow AI: Warum KI die größere Bedrohung ist

Mitarbeiter nutzen KI-Tools, die Sie nicht genehmigt haben, mit Accounts, die Sie nicht überwachen können, mit Daten, die Sie nicht wiederherstellen können. So sieht das Risiko tatsächlich aus und was die Governance adressieren muss.

Passwork BlogAlex Muntyan