Passwork Team

The two-year period from 2025 to 2026 produced the largest credential exposure in recorded history. A single support portal account with no MFA gave an attacker access to records on 60 million students and 10 million educators across 18,000 school districts. The most expensive cyberattack in British corporate history shut down factory production for weeks and cost an estimated £1.9–2.1 billion (around 2,2–2,5 billion €).

Large incidents get investigated thoroughly: root causes published, attack chains reconstructed, regulatory findings released. That makes them the clearest window into how attackers actually operate.

This article breaks down what made 2025–2026 different: the five structural shifts in attacker behavior, the specific breaches that defined the period, and a six-step framework for closing the credential gaps that made most of them possible.

Key takeaways

• Credential reuse is a structural risk, not a user behavior problem. 16 billion credentials in one searchable corpus means any reused password is effectively public. Unique credentials per service, enforced at the vault level, is the only reliable fix.
• Third-party access is your access surface. 48% of 2026 breaches traced to a vendor or SaaS integration. Your security posture is only as strong as the weakest OAuth grant you've forgotten about.
• Privileged accounts outside governance are the highest-risk accounts you have. SSA and PowerSchool both failed on the same point: accounts with unrestricted access that existed outside normal IAM controls.
• Unpatched ERP software is now a confirmed, financially quantified attack vector. CVE-2025-31324 cost JLR an estimated £1.9–2.1 billion. Patch windows for internet-facing enterprise software are measured in hours, not weeks.
• Data you don't delete is data you're responsible for. The University of Hawaiʻi was liable for records from 1993. Data minimization is a security control, not a compliance checkbox.
• Social engineering bypasses technical controls entirely. M&S lost £300 million not to zero-day but to a phone call to a helpdesk agent. No firewall stops that.

The shift in cyber threats: 2025-2026 trends 

The 2025–2026 period marked a structural shift in how attackers operate — away from encrypting systems and toward stealing data and threatening to publish it. 

Five trends defined the period.

1. Data-theft extortion replaced ransomware as the dominant model. Cybercriminal groups like ShinyHunters industrialized the approach: exfiltrate data, set a deadline, publish if unpaid. Attackers no longer need to manage decryption keys or negotiate recovery — exfiltration and a leak site are sufficient.

2. Third-party supply chain attacks became the primary entry vector. The Verizon 2025 DBIR found third-party involvement in 30% of confirmed incidents. By 2026, that share reached 48% — meaning nearly half of all breaches now trace back to a vendor, SaaS provider, or OAuth integration rather than a direct attack on the organization itself (Verizon 2026 DBIR).

3. Education and healthcare became high-value targets. Student information systems and patient records now hold SSNs, medical histories, and insurance data — and both sectors consistently lag on basic controls like MFA and privileged access monitoring. 

4. Vulnerability exploitation overtook credential theft as the top initial access vector — 31% versus 13% in 2026, the first time in the DBIR's history. AI compressed the window between disclosure and active exploitation from months to hours. Compromised credentials still appear in 39% of all breaches when the full attack chain is considered.

5. Privileged access became an attack surface in its own right. A single account with unrestricted access and no monitoring can expose more data than a sophisticated external intrusion — no privilege escalation required.

The breaches below show how each of these patterns played out in practice.

The 16-billion credential mega-leak (June 2025)

The June 2025 credential mega-leak is the largest password exposure in recorded history: 16 billion login credentials across 30 separate databases, discovered by Cybernews researchers. The data was an aggregation of infostealer malware logs and prior breach compilations, assembled into a searchable corpus available on darknet markets for $10.

Infostealers harvest saved credentials from browsers and session cookies after the user has already authenticated. Credential reuse turns a single infection into an enterprise problem: according to Heimdal Security's analysis of Verizon DBIR 2025 data, 94% of passwords appear in multiple accounts. An employee whose personal account credentials were harvested may be using the same password on a corporate VPN or cloud console.

A centralized password vault that generates unique credentials per service, combined with phishing-resistant MFA, eliminates credential reuse as an attack surface.

Passwork's self-hosted vault generates and stores unique credentials for every service, making credential reuse structurally impossible. Audit logs show exactly who accessed what, and when. See how it works — https://passwork.pro/

SaaS supply chain under attack: Klue, Salesforce Experience Cloud, and Volvo/Miljödata

Third-party SaaS risk operates at three distinct levels simultaneously: credential theft, misconfiguration, and vendor concentration. 

The Klue breach (June 2026)

The Klue breach illustrates the credential theft vector. A legacy service account credential — the kind that gets created during an integration project and never rotated — was used to harvest OAuth tokens across dozens of connected platforms. The affected companies included HackerOne, Recorded Future, Jamf, and Tanium. Their CRM data in Salesforce, HubSpot, and Gong was exposed not because those platforms were breached, but because a single stale credential in a connected service gave an attacker the OAuth token needed to read data across all of them. OAuth token abuse at this scale is a direct consequence of ungoverned third-party integrations — shadow IT that security teams often cannot see until after the fact.

The Salesforce Experience Cloud misconfiguration (2025–2026) 

ShinyHunters exploited a Salesforce Experience Cloud misconfiguration to expose data across telecom, finance, and government organizations. Administrators had granted guest users broader read permissions than intended. The platforms were not breached — they were misconfigured. ShinyHunters claimed to have stolen data from around 100 high-profile companies, but Salesforce did not confirm that figure. 

The Miljödata ransomware attack (August 2025)

The DataCarry group attacked Miljödata, a Swedish HR software provider serving Volvo Group, approximately 25 other private companies, 200 Swedish municipalities, and multiple educational institutions. One vendor breach became hundreds of victims. According to Have I Been Pwned, 870,000 accounts were exposed, including government-issued identity numbers. Volvo Group North America began notifying employees on September 29, 2025, confirming that names and Social Security numbers had been exposed — data that originated in Volvo's HR processes but was stored in a third-party system Volvo did not control.

Together, these three cases show that third-party risk management cannot be reduced to a vendor questionnaire. It requires continuous monitoring of OAuth grants, SaaS permission audits, and an honest assessment of how many critical processes depend on a single external provider.

Healthcare under fire: NYC Health + Hospitals, Conduent, and Navia

Healthcare is the most expensive sector to breach. According to the IBM 2025 Cost of a Data Breach Report, the average cost of a healthcare breach reached $7.42 million — nearly double the global average of $4.44 million. The 2025-2026 period produced three incidents that show why.

The NYC Health + Hospitals data breach (2025)

1.8 million patients' records were exposed via a third-party vendor compromise.The NYC Health + Hospitals data breach included biometric templates — fingerprints and palm prints. Unlike passwords, biometric identifiers cannot be changed. An employee whose password is stolen can reset it. An employee whose fingerprint template is stolen has no equivalent recovery option. The permanent nature of biometric exposure makes IAM controls around biometric data storage categorically more critical than those around password storage.

Navia breach (2025)

Health benefits administrator Navia exposed 2.7 million records through an unauthenticated public API endpoint reachable from the open internet — a misconfiguration that mirrors the database exposure pattern above, applied to the application layer.

The Conduent Business Services breach (2025)

Attackers from the SafePay group were inside Conduent's network for 84 days before detection. Conduent processes payments, documents, and medical records for insurers and government agencies across North America. 

By the time the full scope was confirmed in June 2026, the breach had affected 62.2 million individuals, making it the third-largest healthcare data breach in recorded history. Among the confirmed victims: Premera Blue Cross, Humana, and multiple Blue Cross Blue Shield branches. The attackers never touched the insurers directly. They went through the vendor.

Healthcare's combination of high-value data, legacy infrastructure, and complex vendor ecosystems makes it the sector most consistently hit by both credential-based and extortion-based attacks.

When privilege becomes a weapon: SSA and PowerSchool

The DOGE/SSA incident illustrates that the most dangerous credential threat is not always external. A single privileged account with unchecked access can expose more data than any external breach.

The Social Security Administration data export (2025) 

The SSA case is the clearest argument for why privileged access management (PAM) and the principle of least privilege matter even inside organizations. DOGE operators with privileged access to SSA systems allegedly exported a full live database dump of SSN records — covering more than 300 million Americans — to an unsecured external server. No external attacker was involved. 

The PowerSchool breach (2025) 

A single support portal account, lacking MFA, session monitoring, and anomaly detection, exposed records of 60 million students and 10 million educators across the US, Canada, and the UK. 83% of affected students had their Social Security numbers exposed, along with medical records. The support account already had unrestricted access — no privilege escalation or lateral movement was needed.

Both incidents point to the same gap in IAM architecture: privileged accounts that exist outside the normal credential governance process. Support portals, vendor accounts, and administrative backdoors are frequently excluded from password rotation policies, MFA enforcement, and audit logging — the exact controls that would have prevented both breaches.

Europe under attack: Marks & Spencer, Jaguar, and the cost of social engineering

Three European incidents from 2025–2026 produced the most financially documented losses of the period.

The Marks & Spencer breach (2025) 

The breach exposed personal data across M&S's customer base — names, addresses, phone numbers, dates of birth, and order history. M&S did not disclose the exact number of affected customers. Scattered Spider, a cybercriminal group known for stealing sensitive data from Fortune 500 companies, gained initial access through a third-party managed IT services provider by impersonating an employee to a helpdesk agent via SIM-swapping. From there, they moved through Active Directory. Online sales were suspended for 46 days. M&S confirmed a £300 million (around €353 million) profit impact in its annual results.

The Jaguar Land Rover breach (2025) 

It’s the most expensive security breach in British corporate history, estimated at £1.9–2.1 billion (around €2.4 billion) by the Cyber Monitoring Centre. An unpatched SAP NetWeaver vulnerability (CVE-2025-31324, patched April 2025) halted production at factories globally. Wholesale deliveries fell 24.2% year-on-year in JLR's fiscal second quarter and 43% in the third. The Bank of England's manufacturing PMI for September 2025 fell to 46.2, with JLR's shutdown cited as a contributing factor.

The France Titres / ANTS breach (2026) 

Attackers exfiltrated 11.7 million accounts from France's national passport and ID portal. Government identity portals hold verified, legally binding identity data — which makes them high-value targets precisely because the data cannot be disputed or replaced.

The M&S and JLR cases confirm two attack vectors that are now financially quantified: social engineering against third-party contractors, and exploitation of unpatched enterprise ERP software.

The shadow data problem: University of Hawaiʻi and the legacy archive risk

The University of Hawaiʻi breach (2025) exposed records from 1993 to 2007 — data that had never been deleted, encrypted, or audited, demonstrating that data minimization is a direct security control.

A ransomware attack exposed 1.2 million records, including research archives created before modern encryption standards existed. Data from 1993 to 2007 was never subject to current access controls, yet it remained on live infrastructure — queryable, exfiltrable, and legally the university's liability.

Shadow IT and shadow data are two sides of the same governance failure. Shadow IT is the unauthorized application running on your network. Shadow data is the dataset that was created for a project in 2001, never deleted, and never included in any data inventory. Both are invisible to security controls because they were never registered in the first place.

The control is data minimization: retain only what is operationally necessary, and audit legacy datasets on a defined schedule. Organizations that cannot answer "what data do we hold, where is it, and who can access it?" cannot defend it.

How to protect your enterprise from the next mega-leak

The Enterprise Credential Defense Framework maps each control directly to a breach pattern from this article.

Step 1. Deploy a centralized enterprise password vault.

Eliminates credential reuse and provides a single audit trail for all credential access. A centralized password vault with role-based access control means that when a credential is compromised, the blast radius is contained to what that credential was authorized to access — not everything the employee happened to know.

Step 2. Enforce minimum 15-character passwords and phishing-resistant MFA.

Legacy password policies — 90-day mandatory rotation, complexity rules requiring symbols and mixed case — are counterproductive. NIST SP 800-63B Rev. 4 removes both requirements. The reasoning is empirical: forced rotation produces predictable incremental changes (Password1! → Password2!), and complexity rules generate passwords that are hard for humans to remember but easy for automated tools to crack.

For MFA specifically: SMS-based OTP is not recommended at AAL2. Hardware keys and passkeys meet the phishing-resistant threshold. The Verizon 2025 DBIR notes that MFA bypass techniques are growing — token theft accounts for 31% of bypass methods, MFA fatigue for 22% — but having MFA enabled still eliminates the vast majority of credential-based attacks.

Step 3. Audit and revoke ungoverned third-party SaaS integrations and OAuth grants.

Run a quarterly audit of all OAuth grants in your identity provider. Revoke any grant that cannot be attributed to an active, documented integration. Legacy service accounts should be rotated on a defined schedule and decommissioned when the integration is retired.

Step 4. Apply PAM controls and the principle of least privilege.

No account — internal or external — should have access beyond what its documented function requires. Privileged accounts should be time-limited, session-recorded, and subject to the same MFA requirements as any other account.

Step 5. Enforce data minimization and audit legacy datasets.

Establish a data retention schedule. Run an annual audit of datasets older than five years. Data that has no current operational purpose should be deleted, not archived on a live server.

Step 6. Eliminate arbitrary password expiration; adopt compromise-driven rotation.

Rotate credentials when a compromise is detected or suspected — not on a calendar. Integrate your password vault with breach intelligence feeds so that rotation is triggered by evidence, not by a 90-day clock that trains users to make predictable changes.

Conclusion

Three root causes appear in breach after breach across this article: credentials that were unmanaged or reused, access that was unchecked or over-permissioned, and data retained long past any operational purpose. Every incident covered here, from the 16-billion credential dump to the £1.9 billion JLR shutdown, maps to at least one of those three failures.

Every control in the Enterprise Credential Defense Framework maps to a documented failure in a named breach above. The question for your organization: which of those failures are you replicating right now?

Start with a credential audit: every privileged account, every OAuth grant, every service account in your environment. If you cannot answer those questions in under an hour, you have a visibility problem before you have a security problem.

Passwork is a self-hosted password and secrets manager built for exactly that audit: centralized vaults, role-based access, and zero-knowledge encryption, so you always know who has access to what. Explore deployment options — passwork.pro

Frequently asked questions

Passwork vs 1Password: Best Password Manager for EU

GDPR, NIS2, ANSSI 2027 — the regulatory pressure keeps building. We compare Passwork and 1Password on the criteria that matter to European businesses: data sovereignty, audit readiness, deployment model, and real total cost of ownership.

Passwork BlogPasswork Team

Team password management: The complete guide for 2026

Learn how teams share credentials securely in 2026 — RBAC, audit logs, offboarding checklists, NIST SP 800-63B Rev. 4 requirements, and self-hosted vs. cloud deployment.

PassworkAlex Muntyan

11 password reuse risks and how to avoid them

Reusing a password feels harmless. It isn’t. Here’s why one leaked credential can unravel your entire organization’s security — and how to stop it from happening.

Passwork BlogAlex Muntyan

Die EU-Vertragsverletzungsmaschinerie ist im Juli 2026 von Warnungen zu Gerichtsverweisungen übergegangen. Irland, Spanien, Frankreich und die Niederlande sehen sich nun finanziellen Sanktionen gegenüber, weil sie die NIS2-Umsetzungsfrist vom Oktober 2024 verpasst haben — tägliche Strafen laufen auf, bis jedes Land der Kommission die vollständige Umsetzung meldet.

Gleichzeitig nimmt die Durchsetzungsinfrastruktur Gestalt an. Das deutsche BSI prüft aktiv registrierte Einrichtungen. Die Niederlande haben ihr nationales Gesetz einen Tag vor der Gerichtsverweisung verabschiedet. Die NIS-Kooperationsgruppe hat das bisher detaillierteste Mapping-Dokument zu Artikel 21 veröffentlicht. Und die Kommission hat NIS2 erstmals explizit mit KI-gestützter Bedrohungserkennung verknüpft.

Dieser Artikel behandelt alle wesentlichen NIS2-Entwicklungen: was sich geändert hat, welche Fristen aktuell gelten und worauf Ihr Team jetzt reagieren muss. Für die Entwicklungen des Vormonats siehe Aktuelle NIS2-Nachrichten: Mai 2026.

Wichtigste Erkenntnisse

• Gerichtsverweisungen gegen vier Mitgliedstaaten eingereicht. Am 8. Juli 2026 hat die Europäische Kommission Irland, Spanien, Frankreich und die Niederlande an den Gerichtshof der EU verwiesen, weil sie NIS2 nicht vollständig umgesetzt haben. Für jedes Land werden finanzielle Sanktionen beantragt.
• Das niederländische Cyberbeveiligingswet tritt am 15. August 2026 in Kraft. Der niederländische Senat hat das Gesetz am 7. Juli verabschiedet. Mehr als 8.000 Organisationen müssen sich beim NCSC registrieren, risikobasierte Sicherheitsmaßnahmen umsetzen und bis zu diesem Datum eine Aufsicht auf Vorstandsebene sicherstellen.
• Das deutsche BSI prüft jetzt aktiv, nicht nur Registrierungen. Die aktive Aufsichtsphase begann am 6. März 2026. Das BSI kann Nachweise über Sicherheitsmaßnahmen anfordern, ohne auf einen Vorfall zu warten. Eine sekundäre Registrierungsfrist vom 31. Juli gilt für den erheblichen Anteil der 29.000 betroffenen Einrichtungen, die den März-Termin verpasst haben.
• Die NIS-Kooperationsgruppe hat ihr Artikel-21-Mapping-Dokument veröffentlicht. Im Juni 2026 veröffentlicht, ordnet es NIS2-Pflichten und die Durchführungsverordnung 2024/2690 ISO 27001, NIST CSF 2.0, IEC 62443 und nationalen Rahmenwerken zu — die bisher konkreteste EU-weite Compliance-Orientierung.
• Irlands NCSC hat Leitlinien zur Cyber-Governance auf Vorstandsebene veröffentlicht. Am 7. Juli 2026 veröffentlicht, richtet sich das Dokument an CEOs, CIOs und CISOs in NIS2-regulierten Organisationen und basiert auf dem NIST-basierten CyFun-Framework.
• ENISA hat den Raumfahrtsektor auf hohe Kritikalität angehoben. Der NIS360-Bericht 2026 stellt Raumfahrt neben Banken, Elektrizität und Luftfahrt. Sieben Sektoren verbleiben in der Risikozone, wo die Reife hinter den Kritikalitätsanforderungen zurückbleibt.
• Der EU-Aktionsplan zu Cybersicherheit und KI wurde am 7. Juli 2026 veröffentlicht. Es ist das erste EU-Dokument, das NIS2-Compliance formal mit KI-gestützter Bedrohungserkennung als erwartete operative Praxis verknüpft.
• Das britische Cyber Security and Resilience Bill hat das Unterhaus am 16. Juni passiert. Es wurde am 17. Juni ins Oberhaus eingebracht und ist für eine zweite Lesung am 14. Juli vorgesehen. Managed-Service-Provider und Rechenzentrumsbetreiber fallen erstmals in den Geltungsbereich.

EU-Kommission verklagt Irland, Spanien, Frankreich und die Niederlande wegen NIS2-Verzögerungen

Am 8. Juli 2026 hat die Europäische Kommission Irland, Spanien, Frankreich und die Niederlande an den Gerichtshof der EU verwiesen, weil sie die vollständige Umsetzung der NIS2-Richtlinie nicht gemeldet haben. Die Verweisungen beinhalten einen Antrag auf finanzielle Sanktionen: einen Pauschalbetrag plus tägliche Strafen, die auflaufen, bis jedes Land die vollständige Umsetzung meldet.

Die Umsetzungsfrist war der 17. Oktober 2024. Die Kommission sandte im November 2024 förmliche Mahnschreiben an nicht konforme Mitgliedstaaten und im Mai 2025 mit Gründen versehene Stellungnahmen. Die Gerichtsverweisung ist die dritte und letzte Stufe des EU-Vertragsverletzungsverfahrens.

Der Zeitpunkt ist für die Niederlande bemerkenswert. Der niederländische Senat hat das Cyberbeveiligingswet am 7. Juli verabschiedet — einen Tag bevor die Verweisung eingereicht wurde (mehr dazu unten). Das Gesetz tritt am 15. August 2026 in Kraft, aber die förmliche Mitteilung der Umsetzung an die Kommission war zum Zeitpunkt der Verweisung noch nicht eingereicht. Die täglichen Strafen werden nicht mehr auflaufen, sobald die Mitteilung abgeschlossen ist.

Für Spanien, Frankreich und Irland ist kein entsprechendes nationales Gesetz verabschiedet worden. Spaniens Umsetzung wird für Ende 2026 erwartet. Frankreich und Irland haben keine festen Zeitpläne angekündigt.

Die Vertragsverletzungsverfahren haben individuelle Fallnummern:

• Irland (INFR(2024)0279)
• Spanien (INFR(2024)0270)
• Frankreich (INFR(2024)0274)
• Niederlande (INFR(2024)0288)

Die Verweisungen bekräftigen einen Punkt, den Compliance-Teams in diesen Ländern bereits kennen sollten: Die Anforderungen der NIS2-Richtlinie sind unabhängig vom nationalen Umsetzungsstatus verbindlich. Gerichtsverfahren setzen die zugrunde liegenden Verpflichtungen nicht aus — sie erhöhen den finanziellen Druck auf Regierungen, die Lücke schneller zu schließen.

Quelle: Europäische Kommission, 2026

Niederlande: Cyberbeveiligingswet verabschiedet, tritt am 15. August in Kraft

Am 7. Juli 2026 hat der niederländische Senat sowohl das Cyberbeveiligingswet (die niederländische Umsetzung von NIS2) als auch das Critical Entities Resilience Act (Wwke) verabschiedet, das die EU-Richtlinie über die Resilienz kritischer Einrichtungen (CER) umsetzt. Beide Gesetze treten am 15. August 2026 in Kraft.

Mehr als 8.000 Organisationen fallen in den Geltungsbereich: Ministerien, Gemeinden, Wasserbehörden, Provinzen, unabhängige Verwaltungsorgane und interkommunale Partnerschaften. Ab dem 15. August müssen sie:

1. Sich beim National Cyber Security Centre (NCSC) über das Entitätenregister registrieren.
2. Angemessene technische, betriebliche und organisatorische Maßnahmen auf Basis einer Risikobewertung umsetzen — einschließlich Lieferkettenabhängigkeiten.
3. Schwerwiegende Cybersicherheitsvorfälle dem zuständigen CSIRT und der zuständigen Aufsichtsbehörde innerhalb der gesetzlichen Fristen melden.
4. Aufsicht auf Vorstandsebene sicherstellen: Mitglieder der Leitungsorgane müssen über ausreichende Cybersicherheitskenntnisse verfügen und entsprechende Schulungen absolvieren.

Die Durchsetzung liegt bei den benannten Aufsichtsbehörden, einschließlich der niederländischen Behörde für digitale Infrastruktur. Das Cyberbeveiligingswet führt eine Geschäftsführerhaftung ein: Aufsichtsbehörden können verbindliche Anweisungen erteilen, Inspektionen durchführen und Geschäftsführer bei Bedarf suspendieren.

Für Organisationen des öffentlichen Sektors zählt die Einhaltung des Standards Baseline Information Security Government (BIO) 2 zur Erfüllung der Sicherheitsanforderungen des Cbw.

Das Inkrafttreten am 15. August ist eine harte Frist. Die Registrierung beim NCSC sollte vor diesem Datum beginnen — das NCSC selbst empfiehlt, sich im Voraus vorzubereiten, um Engpässe im Registrierungsprozess zu vermeiden.

Quelle: NL Digital Government, 2026

EU-weit: Neues Referenzdokument zu Sicherheitsmaßnahmen veröffentlicht

Im Juni 2026 veröffentlicht, gibt das Referenzdokument zu Sicherheitsmaßnahmen der NIS-Kooperationsgruppe Organisationen die bisher konkreteste EU-weite Orientierung zur Einhaltung von NIS2 Artikel 21. Das Dokument etabliert einen gemeinsamen europäischen Rahmen für Cybersicherheitsziele und enthält eine Mapping-Tabelle, die NIS2-Pflichten und die Europäische Durchführungsverordnung 2024/2690 verknüpft mit:

• ISO/IEC 27001
• IEC 62443
• NIST Cybersecurity Framework 2.0
• nationalen Cybersicherheitsrahmenwerken
• dem CyberFundamentals Framework, CyFun®

Das Dokument ist nicht verbindlich. Es ersetzt weder nationale NIS2-Gesetzgebung noch sektorspezifische Leitlinien. Aber für Compliance-Teams, die bereits gegen ISO 27001 oder NIST CSF 2.0 arbeiten, beantwortet es eine Frage, die seit Verabschiedung der Richtlinie offen war: Wie genau ordnen sich meine bestehenden Kontrollen den NIS2-Anforderungen zu?

Das Mapping ist besonders nützlich für Organisationen, die in mehreren Mitgliedstaaten tätig sind. Anstatt separate Gap-Analysen pro Jurisdiktion zu pflegen, können Teams das Referenzdokument als gemeinsame Basis verwenden und dann nationale Abweichungen darüber legen.

Zugangskontrolle, Authentifizierung und Privileged Access Management erscheinen explizit in den gemappten Zielen — Bereiche, in denen sich die Orientierung des Referenzdokuments direkt mit NIS2 Artikel 21(2)(j) zur Verwendung von Multi-Faktor-Authentifizierung und sicheren Kommunikationssystemen deckt.

Quellen: Center for Cybersecurity Belgium, 2026; Europäische Kommission, 2026

Irland: NCSC veröffentlicht Leitlinien zur Cyber-Governance auf Vorstandsebene für NIS2-Einrichtungen

Am 7. Juli 2026 hat Irlands National Cyber Security Centre Leitlinien zur Cyber-Governance für Mitglieder von Leitungsorganen in NIS2-regulierten Organisationen veröffentlicht. Das Dokument richtet sich an CEOs, Geschäftsführer, CIOs und CISOs — die Führungskräfte, die unter NIS2 persönlich für das Cybersicherheits-Risikomanagement verantwortlich sind.

Die Leitlinien konzentrieren sich auf das Cyber Fundamentals Framework (CyFun), Irlands bevorzugtes nationales Framework für NIS2-Compliance. CyFun basiert auf dem NIST Cybersecurity Framework und gibt Vorständen einen strukturierten, risikobasierten Ansatz zur Erfüllung ihrer rechtlichen Verpflichtungen, ohne tiefes technisches Fachwissen zu erfordern.

Das Dokument deckt drei praktische Bereiche ab: Verständnis, welche Fragen Vorstände zu Cyberrisiken stellen sollten, Identifizierung und Management von Lieferkettenrisiken sowie Aufbau einer Organisationskultur, in der Cybersicherheit als Governance-Thema behandelt wird, nicht als Problem der IT-Abteilung.

Der Zeitpunkt ist bewusst gewählt. Irland ist derzeit Gegenstand eines EU-Vertragsverletzungsverfahrens wegen nicht vollständiger Umsetzung von NIS2 in nationales Recht — die Kommission hat das Land am 8. Juli 2026 an den Gerichtshof verwiesen. Die Veröffentlichung von Leitlinien auf Vorstandsebene vor der formellen Umsetzung signalisiert, dass das NCSC Organisationen unabhängig vom Stand des Gesetzgebungsverfahrens zur Compliance führt.

Quelle: Offizielles Portal der irischen Regierung, 2026

ENISA NIS360 2026: Raumfahrtsektor auf hohe Kritikalität angehoben

Der ENISA NIS360-Bericht 2026 ist die dritte jährliche Bewertung der Cybersicherheitsreife und Kritikalität aller Sektoren aus Anhang I der NIS2-Richtlinie. Die Haupterkenntnis: Der Raumfahrtsektor hat sich zu Banken, Elektrizität, Luftfahrt und digital-nativen Diensten im höchsten Kritikalitätsband gesellt.

Die Anhebung spiegelt die wachsende Rolle der Raumfahrtinfrastruktur als Abhängigkeitsschicht für andere Sektoren wider: Navigation, Kommunikation, Finanzabwicklung und Militärlogistik laufen alle über Satellitensysteme. Höhere Abhängigkeit bedeutet höhere Auswirkungen bei Störungen und höhere Zeitkritikalität bei der Wiederherstellung.

Sieben Sektoren fallen in die NIS360-Risikozone 2026, in der die Cybersicherheitsreife hinter dem Niveau zurückbleibt, das ihre Kritikalität erfordert:

1. Gesundheit
2. Schienenverkehr
3. Seeverkehr
4. IKT-Dienstleistungsmanagement
5. Raumfahrt
6. Öffentliche Verwaltung
7. Trink- und Abwasser

Drei Sektoren erreichten das hohe Reifeband: Vertrauensdienste, Luftfahrt und Finanzmarktinfrastrukturen. Der Gassektor hat begonnen, sich aus der Risikozone zu bewegen, angetrieben durch verbesserten Informationsaustausch und stärkere Umsetzung von Risikomanagementmaßnahmen.

Die Zusammensetzung der Risikozone ist operativ relevant. Aufsichtsbehörden nutzen NIS360-Daten zur Priorisierung ihrer Auditkalender. Wenn Ihre Organisation im Gesundheitswesen, Schienenverkehr oder der öffentlichen Verwaltung tätig ist, erwarten Sie in der zweiten Jahreshälfte 2026 erhöhte aufsichtliche Aufmerksamkeit.

Die ENISA NIS Investments 2025-Studie ergab, dass 70% der befragten Organisationen NIS2-, DORA- und CRA-Compliance als Haupttreiber der Cybersicherheitsausgaben nannten — eine Zahl, die wahrscheinlich steigen wird, wenn Aufsichtsbehörden von der Registrierung zur aktiven Prüfung übergehen.

Quelle: ENISA, 2026

Deutschland: BSI tritt in aktive Aufsichtsphase ein

Das deutsche BSI trat am 6. März 2026 in die aktive Aufsichtsphase ein — das Datum, an dem die Registrierungsfrist gemäß dem NIS2-Umsetzungsgesetz (NIS2UmsuCG) ablief. Das Gesetz wurde am 6. Dezember 2025 erlassen. Bis Juni 2026 war es sechs Monate in Kraft.

Die Analyse von SecurityToday.de vom 16. Juni zum Aufsichtswechsel stellte fest, dass sich die Frage geändert hat: nicht mehr, ob eine Einrichtung registriert ist, sondern ob ihre gemeldeten Maßnahmen einer Prüfung standhalten.

Das BSI-Registrierungsportal wurde am 6. Januar 2026 eröffnet. Ein erheblicher Anteil der etwa 29.000 betroffenen Einrichtungen hat die März-Frist verpasst. Das BSI hat eine sekundäre Registrierungsfrist auf den 31. Juli 2026 gesetzt. Eine späte Registrierung bleibt möglich, schafft aber keinen sicheren Hafen — die Compliance-Pflichten gelten seit Dezember 2025, unabhängig vom Registrierungsstatus.

Was aktive Aufsicht in der Praxis bedeutet:

• Das BSI kann proaktiv Nachweise über Sicherheitsmaßnahmen anfordern — ohne auf einen Vorfall zu warten.
• Vor-Ort- und Fernprüfungen sind jetzt im Umfang enthalten.
• Bußgelder für wesentliche Einrichtungen erreichen bis zu 10 Millionen Euro oder 2% des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist.
• Mitglieder von Leitungsorganen tragen persönliche Haftung, einschließlich möglicher vorübergehender Verbote zur Ausübung von Leitungsfunktionen.

Deutschlands Umsetzung geht bei der Geschäftsführerhaftung über das EU-Minimum hinaus. Das NIS2UmsuCG verlangt ausdrücklich, dass Leitungsorgane Cybersicherheitsmaßnahmen genehmigen, deren Umsetzung überwachen und persönliche Kompetenz nachweisen. Aufsichtsbehörden können einzelne Führungskräfte persönlich für systemische Versäumnisse zur Verantwortung ziehen.

Es gibt einen praktischen Vorteil von Deutschlands strengerem Standard. Organisationen, die die NIS2UmsuCG-Anforderungen erfüllen, erfüllen das EU-Minimum mit Spielraum. Für Unternehmen, die in mehreren Mitgliedstaaten tätig sind, wird eine Sicherheitslage, die der BSI-Prüfung standhält, in der Regel auch bei benachbarten Aufsichtsbehörden bestehen.

Für späte Registranten ist die Prioritätenreihenfolge klar: zuerst registrieren, dann dokumentierte Nachweise über Maßnahmen erstellen. Wenn ein meldepflichtiger Vorfall eintritt, bevor Maßnahmen nachweislich vorhanden sind, ist eine versäumte oder verspätete Registrierung ein erschwerender Faktor.

Quelle: SecurityToday.de, 2026

EU-Aktionsplan zu Cybersicherheit und KI veröffentlicht

Am 7. Juli 2026 hat die Europäische Kommission den EU-Aktionsplan zu Cybersicherheit und Künstlicher Intelligenz veröffentlicht. Das Dokument legt einen koordinierten EU-Ansatz für KI-gestützte Cybersicherheit über Mitgliedstaaten, Behörden und Unternehmen hinweg fest.

Der Plan ist auf drei Ziele ausgerichtet: Förderung einer sicheren und verantwortungsvollen Nutzung fortschrittlicher KI, Stärkung der EU-Cybersicherheit und -Resilienz sowie Ausbau der KI-Fähigkeiten Europas für Cybersicherheitszwecke.

Auf der NIS2-Seite nennt der Aktionsplan explizit die NIS2-Richtlinie als Teil des bestehenden Rechtsrahmens, auf dem er aufbaut, und ermutigt Organisationen, die NIS2 unterliegen, KI (einschließlich Open-Source-Modelle) zur schnelleren Erkennung und Behebung von Schwachstellen einzusetzen. Dies ist das erste EU-Dokument, das NIS2-Compliance formal mit KI-gestützter Bedrohungserkennung als erwartete operative Praxis verknüpft.

Konkrete Maßnahmen umfassen:

• Einen European Blueprint für sicheren Zugang zu fortschrittlichen KI-Systemen für Cybersicherheitszwecke, der mit ENISA entwickelt werden soll.
• Eine sichere Testplattform für Organisationen in kritischen Sektoren (Energie, Verkehr, Gesundheit, Finanzen und öffentliche Verwaltung) zum sicheren Testen und Einsetzen von KI-Lösungen.
• Eine EU Grand Challenge zu KI für Cybersicherheit, die Industrie, Forscher und Open-Source-Communities zusammenbringt.

Der Aktionsplan steht neben dem AI Act, dem Cyber Resilience Act, DORA und dem Cyber Solidarity Act. Er schafft selbst keine neuen verbindlichen Verpflichtungen, signalisiert aber, wohin die Kommission erwartet, dass Durchsetzungsschwerpunkte und Investitionen im nächsten Gesetzgebungszyklus gehen.

Quelle: Europäische Kommission, 2026

UK: Cyber Security and Resilience Bill passiert Unterhaus, geht ins Oberhaus

Am 16. Juni 2026 hat das Cyber Security and Resilience (Network and Information Systems) Bill seine dritte Lesung und Berichtsphase im House of Commons abgeschlossen. Es erhielt seine erste Lesung im House of Lords am 17. Juni und ist für eine zweite Lesung im Lords am 14. Juli 2026 vorgesehen.

Das Gesetz wurde am 12. November 2025 ins Parlament eingebracht und aktualisiert die bestehenden Network and Information Systems Regulations 2018 (NIS1). Es setzt NIS2 nicht um (das Vereinigte Königreich ist nicht mehr an EU-Recht gebunden), aber es nähert die UK-Anforderungen erheblich dem NIS2-Standard in Umfang und Durchsetzung an.

Was das Gesetz hinzufügt:

• Managed-Service-Provider fallen erstmals in den Geltungsbereich. Relevant Managed Service Providers (RMSPs) müssen sich beim ICO registrieren, Risikomanagementmaßnahmen umsetzen und einen UK-Vertreter benennen, wenn sie nicht im UK ansässig sind.
• Rechenzentrumsbetreiber werden ebenfalls in den Geltungsbereich aufgenommen.
• Fristen für die Vorfallsmeldung werden verschärft: 24-Stunden-Erstmeldung, 72-Stunden-Vollmeldung — entsprechend der NIS2-Artikel-23-Struktur.
• Bezeichnung kritischer Lieferanten: Das ICO erhält die Befugnis, Lieferanten zu bezeichnen, deren Kompromittierung wesentliche Dienste oder RMSPs beeinträchtigen würde.
• Strafen steigen auf bis zu 17 Millionen Pfund oder 4% des weltweiten Jahresumsatzes bei schwerwiegenden Verstößen; bis zu 10 Millionen Pfund oder 2% bei weniger schwerwiegenden.

Die Vorfallsdefinition wird ebenfalls erweitert: Das Gesetz erfasst Vorfälle, die „geeignet sind, eine nachteilige Auswirkung" auf regulierte Dienste zu haben, nicht nur solche mit einer nachgewiesenen tatsächlichen Auswirkung. Dies ist eine bedeutsame Änderung für Organisationen, die derzeit ihre Meldeschwellen kalibrieren.

63 Änderungsanträge wurden während der Gesetzespassage vorgeschlagen. Zwei im Juni eingereichte Änderungsanträge, darunter einer zur Aufnahme der Lebensmittellieferkette als regulierten wesentlichen Dienst, erhielten in der Berichtsphase keine Entscheidung.

Die Regierung erwartet, 2026 eine Konsultation zu sekundärer Gesetzgebung durchzuführen, die spezifische Risikomanagementmaßnahmen und Meldepflichten abdeckt. Einige Bestimmungen werden ab dem ersten Tag oder zweiten Monat nach der königlichen Zustimmung in Kraft treten; andere werden durch sekundäre Gesetzgebung folgen.

Quellen: UK Parliament, 2026; Parallel Parliament, 2026

Zusammenfassung

Der Zeitraum von Juni bis Anfang Juli 2026 markiert den Punkt, an dem die NIS2-Durchsetzung von politischem Druck zu aktiven rechtlichen und aufsichtlichen Maßnahmen übergegangen ist. Gerichtsverweisungen sind eingereicht. Nationale Gesetze treten in Kraft. Aufsichtsbehörden fordern Nachweise über Sicherheitsmaßnahmen an, nicht nur Registrierungsbestätigungen.

Für Organisationen in Irland, Spanien, Frankreich und den Niederlanden ändern die Vertragsverletzungsverfahren nichts an den zugrunde liegenden Verpflichtungen. NIS2-Anforderungen sind seit Oktober 2024 verbindlich, unabhängig vom nationalen Umsetzungsstatus. Die Verfahren fügen finanzielle Konsequenzen für Regierungen hinzu — sie schaffen keine Schonfrist für regulierte Einrichtungen.

Für Organisationen in Deutschland und den Niederlanden ist der Compliance-Kalender jetzt festgelegt. Das BSI prüft. Das Cyberbeveiligingswet tritt am 15. August in Kraft. Das im Juni 2026 von der NIS-Kooperationsgruppe veröffentlichte Artikel-21-Mapping-Dokument ist das umsetzbarste Ergebnis dieses Zeitraums: Wenn Ihr Team bereits gegen ISO 27001 oder NIST CSF 2.0 arbeitet, bietet es einen direkten Weg, Ihre NIS2-Gap-Analyse abzuschließen, bevor eine Aufsichtsbehörde dies für Sie übernimmt.

NIS2-Zugangskontrollen für Lieferkettensicherheit

48% der Sicherheitsverletzungen betreffen mittlerweile Dritte. NIS2 Artikel 21 macht Lieferanten-Zugangs-Governance zu einer rechtlichen Verpflichtung. Hier erfahren Sie, wie Sie Lieferantenzugriffe erfassen, MFA und Least Privilege durchsetzen und Audit-Nachweise führen, die Ihre Kontrollen belegen.

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 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 Governance adressieren muss.

Passwork BlogAlex Muntyan

Mitarbeiter-Offboarding: Leitfaden zur sicheren Zugangsentziehung 2026

Das Deaktivieren eines SSO-Kontos entzieht nicht den Zugang. API-Schlüssel, KI-Agenten-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

El mecanismo de infracción de la UE pasó de las advertencias a las remisiones judiciales en julio de 2026. Irlanda, España, Francia y los Países Bajos enfrentan ahora sanciones económicas por incumplir el plazo de transposición de NIS2 de octubre de 2024 — con penalizaciones diarias que se acumulan hasta que cada país notifique la transposición completa a la Comisión.

Al mismo tiempo, la infraestructura de aplicación se está consolidando. La BSI de Alemania está auditando activamente a las entidades registradas. Los Países Bajos aprobaron su ley nacional un día antes de que se presentara la remisión. El Grupo de Cooperación NIS publicó el documento de mapeo del Artículo 21 más detallado hasta la fecha. Y la Comisión vinculó explícitamente NIS2 con la detección de amenazas asistida por IA por primera vez.

Este artículo cubre todos los desarrollos materiales de NIS2: qué cambió, qué plazos están vigentes y qué necesita abordar su equipo ahora. Para los desarrollos del mes anterior, consulte Últimas noticias de NIS2: mayo de 2026.

Puntos clave

• Remisiones judiciales presentadas contra cuatro Estados miembros. El 8 de julio de 2026, la Comisión Europea remitió a Irlanda, España, Francia y los Países Bajos al Tribunal de Justicia de la UE por no transponer completamente NIS2. Se solicitan sanciones económicas para cada país.
• La Cyberbeveiligingswet de los Países Bajos entra en vigor el 15 de agosto de 2026. El Senado neerlandés aprobó la ley el 7 de julio. Más de 8.000 organizaciones deben registrarse ante el NCSC, implementar medidas de seguridad basadas en riesgos y garantizar la supervisión a nivel de consejo directivo para esa fecha.
• La BSI de Alemania ahora audita, no solo registra. La fase de supervisión activa comenzó el 6 de marzo de 2026. La BSI puede solicitar evidencia de medidas de seguridad sin esperar a que ocurra un incidente. Un plazo de registro secundario del 31 de julio se aplica a la parte significativa de las 29.000 entidades dentro del ámbito que no cumplieron en marzo.
• El Grupo de Cooperación NIS publicó su documento de mapeo del Artículo 21. Publicado en junio de 2026, mapea las obligaciones de NIS2 y el Reglamento de Implementación 2024/2690 con ISO 27001, NIST CSF 2.0, IEC 62443 y marcos nacionales — la guía de cumplimiento más concreta a nivel de la UE publicada hasta la fecha.
• El NCSC de Irlanda publicó orientación sobre gobernanza cibernética a nivel de consejo directivo. Publicado el 7 de julio de 2026, el documento está dirigido a CEO, CIO y CISO en organizaciones reguladas por NIS2 y se basa en el marco CyFun basado en NIST.
• ENISA elevó el sector espacial a alta criticidad. El informe NIS360 2026 coloca el espacio junto con la banca, la electricidad y la aviación. Siete sectores permanecen en la zona de riesgo, donde la madurez no alcanza las demandas de criticidad.
• El Plan de Acción de la UE sobre Ciberseguridad e IA se publicó el 7 de julio de 2026. Es el primer documento a nivel de la UE que vincula formalmente el cumplimiento de NIS2 con la detección de amenazas asistida por IA como práctica operativa esperada.
• El proyecto de ley de Ciberseguridad y Resiliencia del Reino Unido fue aprobado por los Comunes el 16 de junio. Ingresó a los Lores el 17 de junio y está programado para una segunda lectura el 14 de julio. Los proveedores de servicios gestionados y los operadores de centros de datos entran en el ámbito por primera vez.

La Comisión de la UE lleva a Irlanda, España, Francia y los Países Bajos ante los tribunales por retrasos en NIS2

El 8 de julio de 2026, la Comisión Europea remitió a Irlanda, España, Francia y los Países Bajos al Tribunal de Justicia de la UE por no notificar la transposición completa de la Directiva NIS2. Las remisiones incluyen una solicitud de sanciones económicas: una suma global más penalizaciones diarias que se acumulan hasta que cada país notifique la transposición completa.

El plazo de transposición fue el 17 de octubre de 2024. La Comisión envió notificaciones formales a los Estados miembros incumplidores en noviembre de 2024 y dictámenes motivados en mayo de 2025. La remisión judicial es la tercera y última etapa del procedimiento de infracción de la UE.

El momento es notable para los Países Bajos. El Senado neerlandés aprobó la Cyberbeveiligingswet el 7 de julio — un día antes de que se presentara la remisión (más información al respecto a continuación). La ley entra en vigor el 15 de agosto de 2026, pero la notificación formal de transposición a la Comisión aún no se había presentado en el momento de la remisión. Las penalizaciones diarias dejarán de acumularse una vez que se complete la notificación.

Para España, Francia e Irlanda, no se ha aprobado ninguna ley nacional equivalente. Se espera que la transposición de España se realice a finales de 2026. Francia e Irlanda no han anunciado plazos firmes.

Los casos de infracción tienen números de caso individuales:

• Irlanda (INFR(2024)0279)
• España (INFR(2024)0270)
• Francia (INFR(2024)0274)
• Países Bajos (INFR(2024)0288)

Las remisiones refuerzan un punto que los equipos de cumplimiento en estos países ya deberían conocer: los requisitos de la Directiva NIS2 son vinculantes independientemente del estado de transposición nacional. Los procedimientos judiciales no suspenden las obligaciones subyacentes — añaden presión financiera sobre los gobiernos para cerrar la brecha más rápidamente.

Fuente: Comisión Europea, 2026

Países Bajos: Cyberbeveiligingswet aprobada, entra en vigor el 15 de agosto

El 7 de julio de 2026, el Senado neerlandés aprobó tanto la Cyberbeveiligingswet (la transposición neerlandesa de NIS2) como la Ley de Resiliencia de Entidades Críticas (Wwke), que implementa la Directiva de Resiliencia de Entidades Críticas (CER) de la UE. Ambas leyes entran en vigor el 15 de agosto de 2026.

Más de 8.000 organizaciones están dentro del ámbito: ministerios, municipios, autoridades del agua, provincias, organismos administrativos independientes y asociaciones intermunicipales. A partir del 15 de agosto, deben:

1. Registrarse ante el Centro Nacional de Ciberseguridad (NCSC) a través del Registro de Entidades.
2. Implementar medidas técnicas, operativas y organizativas apropiadas basadas en una evaluación de riesgos — incluyendo dependencias de la cadena de suministro.
3. Notificar incidentes de ciberseguridad importantes al CSIRT correspondiente y a la autoridad de supervisión competente dentro de los plazos legales.
4. Garantizar la supervisión a nivel de consejo directivo: los miembros del órgano de dirección deben tener conocimientos suficientes de ciberseguridad y completar la formación adecuada.

La aplicación recae en las autoridades de supervisión designadas, incluyendo la Autoridad Neerlandesa para la Infraestructura Digital. La Cyberbeveiligingswet introduce la responsabilidad de los directores: los supervisores pueden emitir instrucciones vinculantes, realizar inspecciones y suspender a los directores cuando sea necesario.

Para las organizaciones del sector público, el cumplimiento del estándar Baseline Information Security Government (BIO) 2 cuenta para cumplir los requisitos de seguridad de la Cbw.

La fecha de entrada en vigor del 15 de agosto es un plazo estricto. El registro ante el NCSC debería comenzar antes de esa fecha — el propio NCSC recomienda prepararse con antelación para evitar cuellos de botella en el proceso de registro.

Fuente: NL Digital Government, 2026

A nivel de la UE: Publicado nuevo documento de referencia sobre medidas de seguridad

Publicado en junio de 2026, el documento de referencia sobre medidas de seguridad del Grupo de Cooperación NIS ofrece a las organizaciones la guía más concreta a nivel de la UE sobre el cumplimiento del Artículo 21 de NIS2 hasta la fecha. El documento establece un marco europeo común para objetivos de ciberseguridad e incluye una tabla de mapeo que vincula las obligaciones de NIS2 y el Reglamento de Implementación Europeo 2024/2690 con:

• ISO/IEC 27001
• IEC 62443
• NIST Cybersecurity Framework 2.0
• marcos nacionales de ciberseguridad
• el CyberFundamentals Framework, CyFun®

El documento no es vinculante. No reemplaza la legislación nacional de NIS2 ni las directrices específicas del sector. Pero para los equipos de cumplimiento que ya trabajan con ISO 27001 o NIST CSF 2.0, responde a una pregunta que ha estado abierta desde que se aprobó la directiva: ¿cómo se mapean exactamente mis controles existentes con los requisitos de NIS2?

El mapeo es particularmente útil para organizaciones que operan en múltiples Estados miembros. En lugar de mantener análisis de brechas separados por jurisdicción, los equipos pueden usar el documento de referencia como una línea base compartida y luego añadir las desviaciones nacionales encima.

El control de acceso, la autenticación y la gestión de acceso privilegiado aparecen explícitamente en los objetivos mapeados — áreas donde la guía del documento de referencia se alinea directamente con el Artículo 21(2)(j) de NIS2 sobre el uso de autenticación multifactor y sistemas de comunicación seguros.

Fuentes: Centro de Ciberseguridad de Bélgica, 2026; Comisión Europea, 2026

Irlanda: El NCSC publica orientación sobre gobernanza cibernética a nivel de consejo directivo para entidades NIS2

El 7 de julio de 2026, el Centro Nacional de Ciberseguridad de Irlanda publicó orientación sobre gobernanza cibernética para miembros de consejos de administración en organizaciones reguladas por NIS2. El documento está dirigido a CEO, directores generales, CIO y CISO — los ejecutivos que asumen responsabilidad personal por la gestión de riesgos de ciberseguridad bajo NIS2.

La orientación se centra en el Cyber Fundamentals Framework (CyFun), el marco nacional preferido de Irlanda para el cumplimiento de NIS2. CyFun está basado en el NIST Cybersecurity Framework y proporciona a los consejos un enfoque estructurado y basado en riesgos para cumplir sus obligaciones legales sin requerir experiencia técnica profunda.

El documento cubre tres áreas prácticas: comprender qué preguntas deberían hacer los consejos sobre el riesgo cibernético, identificar y gestionar los riesgos de la cadena de suministro, y construir una cultura organizacional donde la ciberseguridad se trate como un tema de gobernanza, no como un problema del departamento de TI.

El momento es deliberado. Irlanda está actualmente sujeta a procedimientos de infracción de la UE por no transponer completamente NIS2 a la legislación nacional — la Comisión remitió al país al Tribunal de Justicia el 8 de julio de 2026. Publicar orientación a nivel de consejo directivo antes de la transposición formal señala que el NCSC está moviendo a las organizaciones hacia el cumplimiento independientemente de dónde se encuentre el proceso legislativo.

Fuente: Portal oficial del Gobierno de Irlanda, 2026

ENISA NIS360 2026: El sector espacial elevado a alta criticidad

El informe ENISA NIS360 2026 es la tercera evaluación anual de madurez y criticidad en ciberseguridad en todos los sectores del Anexo I bajo la Directiva NIS2. El hallazgo principal: el sector espacial se ha unido a la banca, la electricidad, la aviación y los servicios digitales por defecto en la banda de mayor criticidad.

La elevación refleja el creciente papel de la infraestructura espacial como capa de dependencia para otros sectores: la navegación, las comunicaciones, la liquidación financiera y la logística militar funcionan con sistemas satelitales. Mayor dependencia significa mayor impacto ante una interrupción y mayor criticidad temporal en la recuperación.

Siete sectores caen en la zona de riesgo de NIS360 2026, donde la madurez en ciberseguridad está por debajo del nivel que exige su criticidad:

1. Salud
2. Ferrocarril
3. Marítimo
4. Gestión de servicios TIC
5. Espacio
6. Administración pública
7. Agua potable y residual

Tres sectores alcanzaron la banda de alta madurez: servicios de confianza, aviación e infraestructuras del mercado financiero. El sector del gas ha comenzado a salir de la zona de riesgo, impulsado por una mejor compartición de información y una implementación más sólida de medidas de gestión de riesgos.

La composición de la zona de riesgo importa operativamente. Las autoridades de supervisión utilizan los datos de NIS360 para priorizar los calendarios de auditoría. Si su organización opera en salud, ferrocarril o administración pública, espere mayor atención supervisora en la segunda mitad de 2026.

El estudio ENISA NIS Investments 2025 encontró que el 70% de las organizaciones encuestadas citaron el cumplimiento de NIS2, DORA y CRA como el principal impulsor del gasto en ciberseguridad — una cifra que probablemente aumentará a medida que los supervisores pasen del registro a la revisión activa.

Fuente: ENISA, 2026

Alemania: La BSI entra en fase de supervisión activa

La BSI de Alemania entró en la fase de supervisión activa el 6 de marzo de 2026 — la fecha en que expiró el plazo de registro bajo la NIS2-Umsetzungsgesetz (NIS2UmsuCG). La ley se promulgó el 6 de diciembre de 2025. Para junio de 2026, había estado en vigor durante seis meses.

El análisis del 16 de junio de SecurityToday.de sobre el cambio de supervisión señaló que la pregunta ha cambiado: ya no se trata de si una entidad está registrada, sino de si las medidas declaradas resisten el escrutinio.

El portal de registro de la BSI abrió el 6 de enero de 2026. Una parte significativa de las aproximadamente 29.000 entidades dentro del ámbito no cumplió el plazo de marzo. La BSI estableció un plazo de registro secundario del 31 de julio de 2026. El registro tardío sigue siendo posible pero no crea ningún puerto seguro — las obligaciones de cumplimiento se aplican desde diciembre de 2025, independientemente del estado de registro.

Lo que significa la supervisión activa en la práctica:

• La BSI puede solicitar proactivamente evidencia de medidas de seguridad — sin esperar a que ocurra un incidente.
• Las auditorías presenciales y remotas están ahora dentro del ámbito.
• Las multas para entidades esenciales alcanzan hasta 10 millones de euros o el 2% de la facturación anual global, lo que sea mayor.
• Los miembros del órgano de dirección enfrentan responsabilidad personal, incluyendo posibles prohibiciones temporales para ejercer funciones de gestión.

La implementación de Alemania va más allá del mínimo de la UE en cuanto a responsabilidad ejecutiva. La NIS2UmsuCG requiere explícitamente que los órganos de dirección aprueben las medidas de ciberseguridad, supervisen su implementación y demuestren competencia personal. Los supervisores pueden responsabilizar personalmente a ejecutivos individuales por fallos sistémicos.

Hay una ventaja práctica en el estándar más estricto de Alemania. Las organizaciones que cumplen los requisitos de la NIS2UmsuCG satisfacen el mínimo de la UE con margen. Para las empresas que operan en múltiples Estados miembros, una postura de seguridad que pase el escrutinio de la BSI generalmente también se sostendrá ante las autoridades de supervisión vecinas.

Para los que se registran tarde, el orden de prioridades es claro: registrarse primero, luego establecer evidencia documentada de las medidas. Si ocurre un incidente notificable antes de que las medidas estén demostrablemente implementadas, un registro omitido o retrasado es un factor agravante.

Fuente: SecurityToday.de, 2026

Publicado el Plan de Acción de la UE sobre Ciberseguridad e IA

El 7 de julio de 2026, la Comisión Europea publicó el Plan de Acción de la UE sobre Ciberseguridad e Inteligencia Artificial. El documento establece un enfoque coordinado de la UE para la ciberseguridad impulsada por IA en los Estados miembros, autoridades públicas y empresas.

El plan se construye en torno a tres objetivos: promover el uso seguro y responsable de la IA avanzada, reforzar la ciberseguridad y la resiliencia de la UE, y ampliar las capacidades de IA de Europa para fines de ciberseguridad.

En cuanto a NIS2, el Plan de Acción nombra explícitamente la Directiva NIS2 como parte del marco legal existente sobre el que se construye, y alienta a las organizaciones sujetas a NIS2 a utilizar IA (incluyendo modelos de código abierto) para detectar y abordar vulnerabilidades más rápidamente. Este es el primer documento a nivel de la UE que vincula formalmente el cumplimiento de NIS2 con la detección de amenazas asistida por IA como práctica operativa esperada.

Las medidas concretas incluyen:

• Un Plan Europeo para el acceso seguro a sistemas de IA avanzados para fines de ciberseguridad, a desarrollar con ENISA.
• Una plataforma de pruebas segura para organizaciones en sectores críticos (energía, transporte, salud, finanzas y administración pública) para probar e implementar soluciones de IA de forma segura.
• Un Gran Desafío de la UE sobre IA para ciberseguridad, que reúne a la industria, investigadores y comunidades de código abierto.

El Plan de Acción se sitúa junto con la Ley de IA, la Ley de Ciberresiliencia, DORA y la Ley de Cibersolidaridad. No crea nuevas obligaciones vinculantes por sí solo, pero señala dónde espera la Comisión que se concentren el énfasis en la aplicación y la inversión durante el próximo ciclo legislativo.

Fuente: Comisión Europea, 2026

Reino Unido: El proyecto de ley de Ciberseguridad y Resiliencia es aprobado por los Comunes, ingresa a los Lores

El 16 de junio de 2026, el proyecto de ley de Ciberseguridad y Resiliencia (Sistemas de Redes e Información) completó su tercera lectura y etapa de informe en la Cámara de los Comunes. Recibió su primera lectura en los Lores el 17 de junio y está programado para una segunda lectura en los Lores el 14 de julio de 2026.

El proyecto de ley se presentó al Parlamento el 12 de noviembre de 2025 y actualiza los Reglamentos de Sistemas de Redes e Información de 2018 (NIS1) existentes. No transpone NIS2 (el Reino Unido ya no está vinculado por la legislación de la UE) pero acerca significativamente los requisitos del Reino Unido al estándar NIS2 en alcance y aplicación.

Lo que añade el proyecto de ley:

• Los proveedores de servicios gestionados entran en el ámbito por primera vez. Los Proveedores de Servicios Gestionados Relevantes (RMSP) deben registrarse ante el ICO, implementar medidas de gestión de riesgos y designar un representante en el Reino Unido si no están establecidos en el país.
• Los operadores de centros de datos también se incluyen en el ámbito.
• Los plazos de notificación de incidentes se acortan: informe inicial de 24 horas, notificación completa de 72 horas — coincidiendo con la estructura del Artículo 23 de NIS2.
• Designación de proveedores críticos: El ICO obtiene la facultad de designar proveedores cuyo compromiso afectaría a servicios esenciales o RMSP.
• Las sanciones aumentan hasta 17 millones de libras o el 4% de la facturación anual global por infracciones graves; hasta 10 millones de libras o el 2% por las menos graves.

La definición de incidente también se amplía: el proyecto de ley cubre incidentes «capaces de tener un efecto adverso» en los servicios regulados, no solo aquellos con un efecto real demostrado. Este es un cambio significativo para las organizaciones que actualmente calibran sus umbrales de notificación.

Se han propuesto 63 enmiendas durante el trámite del proyecto de ley. Dos enmiendas presentadas en junio, incluyendo una para añadir la cadena de suministro alimentario como servicio esencial regulado, no recibieron decisión en la etapa de informe.

El gobierno espera consultar en 2026 sobre la legislación secundaria que cubra medidas específicas de gestión de riesgos y requisitos de notificación. Algunas disposiciones entrarán en vigor desde el primer día o segundo mes después de la sanción real; otras seguirán mediante legislación secundaria.

Fuentes: Parlamento del Reino Unido, 2026; Parallel Parliament, 2026

Resumen

El período de junio a principios de julio de 2026 marca el punto en que la aplicación de NIS2 pasó de la presión política a la acción legal y de supervisión activa. Se presentaron remisiones judiciales. Las leyes nacionales están entrando en vigor. Las autoridades de supervisión están solicitando evidencia de medidas de seguridad, no solo confirmaciones de registro.

Para las organizaciones en Irlanda, España, Francia y los Países Bajos, los procedimientos de infracción no cambian nada sobre las obligaciones subyacentes. Los requisitos de NIS2 han sido vinculantes desde octubre de 2024 independientemente del estado de transposición nacional. Los procedimientos añaden consecuencias financieras para los gobiernos — no crean un período de gracia para las entidades reguladas.

Para las organizaciones en Alemania y los Países Bajos, el calendario de cumplimiento ya está establecido. La BSI está auditando. La Cyberbeveiligingswet entra en vigor el 15 de agosto. El documento de mapeo del Artículo 21 publicado por el Grupo de Cooperación NIS en junio de 2026 es el resultado más accionable de este período: si su equipo ya trabaja con ISO 27001 o NIST CSF 2.0, proporciona un camino directo para cerrar su análisis de brechas de NIS2 antes de que una autoridad de supervisión lo haga por usted.

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 demuestra que sus controles funcionan.

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. Aquí se muestra cómo es realmente el riesgo y qué debe abordar la gobernanza.

Passwork BlogAlex Muntyan

Offboarding de empleados: Guía de revocación segura de accesos 2026

Desactivar 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 playbook completo de offboarding — desde disparadores de hora cero hasta limpieza de NHI.

Passwork BlogAlex Muntyan

The EU infringement machine moved from warnings to court referrals in July 2026. Ireland, Spain, France, and the Netherlands now face financial sanctions for missing the October 2024 NIS2 transposition deadline — daily penalties accruing until each country notifies complete transposition to the Commission.

At the same time, enforcement infrastructure is filling in. Germany's BSI is actively auditing registered entities. The Netherlands passed its national law one day before the referral landed. The NIS Cooperation Group published the most detailed Article 21 mapping document to date. And the Commission tied NIS2 explicitly to AI-assisted threat detection for the first time.

This article covers every material NIS2 development: what changed, which deadlines are live, and what your team needs to act on now. For the previous month's developments, see NIS2 latest news: May 2026.

Key takeaways

• Court referrals filed against four member states. On July 8, 2026, the European Commission referred Ireland, Spain, France, and the Netherlands to the Court of Justice of the EU for failing to fully transpose NIS2. Financial sanctions are requested for each country.
• Netherlands' Cyberbeveiligingswet enters force August 15, 2026. The Dutch Senate approved the law on July 7. More than 8,000 organizations must register with the NCSC, implement risk-based security measures, and ensure board-level oversight by that date.
• Germany's BSI is now auditing, not just registering. The active supervision phase began March 6, 2026. The BSI can request evidence of security measures without waiting for an incident. A secondary registration deadline of July 31 applies to the significant share of the 29,000 in-scope entities that missed March.
• The NIS Cooperation Group published its Article 21 mapping document. Released in June 2026, it maps NIS2 obligations and Implementing Regulation 2024/2690 to ISO 27001, NIST CSF 2.0, IEC 62443, and national frameworks — the most concrete EU-level compliance guidance published to date.
• Ireland's NCSC published board-level cyber governance guidance. Released July 7, 2026, the document targets CEOs, CIOs, and CISOs in NIS2-regulated organizations and is built around the NIST-based CyFun framework.
• ENISA elevated the space sector to high criticality. The NIS360 2026 report places space alongside banking, electricity, and aviation. Seven sectors remain in the risk zone, where maturity falls below criticality demands.
• The EU Action Plan on Cybersecurity and AI was published July 7, 2026. It is the first EU-level document to formally link NIS2 compliance with AI-assisted threat detection as an expected operational practice.
• The UK's Cyber Security and Resilience Bill passed the Commons on June 16. It entered the Lords on June 17 and is scheduled for a second reading on July 14. Managed service providers and data centre operators come into scope for the first time.

EU Commission takes Ireland, Spain, France, and the Netherlands to court over NIS2 delays

On July 8, 2026, the European Commission referred Ireland, Spain, France, and the Netherlands to the Court of Justice of the EU for failing to notify full transposition of the NIS2 Directive. The referrals include a request for financial sanctions: a lump sum plus daily penalties accruing until each country notifies complete transposition.

The transposition deadline was October 17, 2024. The Commission sent formal notices to non-compliant member states in November 2024 and reasoned opinions in May 2025. Court referral is the third and final stage of the EU infringement procedure.

The timing is notable for the Netherlands. The Dutch Senate approved the Cyberbeveiligingswet on July 7 — one day before the referral was filed (more on this below). The law enters into force on August 15, 2026, but formal notification of transposition to the Commission had not yet been submitted at the time of the referral. Daily penalties will stop accruing once notification is complete.

For Spain, France, and Ireland, no equivalent national law has passed. Spain's transposition is expected in late 2026. France and Ireland have not announced firm timelines.

The infringement cases carry individual case numbers:

• Ireland (INFR(2024)0279)
• Spain (INFR(2024)0270)
• France (INFR(2024)0274)
• Netherlands (INFR(2024)0288)

The referrals reinforce a point compliance teams in these countries should already know: the NIS2 Directive's requirements are binding regardless of national transposition status. Court proceedings do not suspend the underlying obligations — they add financial pressure on governments to close the gap faster.

Source: European Commision, 2026

Netherlands: Cyberbeveiligingswet approved, enters force August 15

On July 7, 2026, the Dutch Senate approved both the Cyberbeveiligingswet (the Dutch transposition of NIS2) and the Critical Entities Resilience Act (Wwke), which implements the EU's Critical Entities Resilience (CER) Directive. Both laws enter into force on August 15, 2026.

More than 8,000 organizations fall in scope: ministries, municipalities, water authorities, provinces, independent administrative bodies, and inter-municipal partnerships. From August 15, they must:

1. Register with the National Cyber Security Centre (NCSC) via the Entities Register.
2. Implement appropriate technical, operational, and organizational measures based on a risk assessment — including supply chain dependencies.
3. Report major cybersecurity incidents to the relevant CSIRT and competent supervisory authority within statutory deadlines.
4. Ensure board-level oversight: governing body members must have sufficient cybersecurity knowledge and complete appropriate training.

Enforcement sits with designated supervisory authorities, including the Dutch Authority for Digital Infrastructure. The Cyberbeveiligingswet introduces director liability: supervisors can issue binding instructions, conduct inspections, and suspend directors where necessary.

For public sector organizations, compliance with the Baseline Information Security Government (BIO) 2 standard counts toward meeting the Cbw's security requirements.

The August 15 entry-into-force date is a hard deadline. Registration with the NCSC should begin before that date — the NCSC itself recommends preparing in advance to avoid bottlenecks in the registration process.

Source: NL Digital Government, 2026

EU-wide: New security measures reference document released

Published on June, 2026, the NIS Cooperation Group's reference document on security measures gives organizations the most concrete EU-level guidance on NIS2 Article 21 compliance to date. The document establishes a common European framework for cybersecurity objectives and includes a mapping table that links NIS2 obligations and the European Implementing Regulation 2024/2690 to:

• ISO/IEC 27001
• IEC 62443
• NIST Cybersecurity Framework 2.0
• national cybersecurity frameworks
• the CyberFundamentals Framework, CyFun®

The document is non-binding. It does not replace national NIS2 legislation or sector-specific guidelines. But for compliance teams already working against ISO 27001 or NIST CSF 2.0, it answers a question that has been open since the directive passed: how exactly do my existing controls map to NIS2 requirements?

The mapping is particularly useful for organizations operating across multiple member states. Rather than maintaining separate gap analyses per jurisdiction, teams can use the reference document as a shared baseline and then layer national deviations on top.

Access control, authentication, and privileged access management appear explicitly in the mapped objectives — areas where the reference document's guidance aligns directly with NIS2 Article 21(2)(j) on the use of multi-factor authentication and secure communication systems.

Sources: Center for Cybersecurity Belgium, 2026; European Commission, 2026

Ireland: NCSC publishes board-level cyber governance guidance for NIS2 entities

On July 7, 2026, Ireland's National Cyber Security Centre published guidance on cyber governance for management board members in NIS2-regulated organizations. The document targets CEOs, Managing Directors, CIOs, and CISOs — the executives who bear personal accountability for cybersecurity risk management under NIS2.

The guidance centers on the Cyber Fundamentals Framework (CyFun), Ireland's preferred national framework for NIS2 compliance. CyFun is built on the NIST Cybersecurity Framework and gives boards a structured, risk-based approach to meeting their legal obligations without requiring deep technical expertise.

The document covers three practical areas: understanding what questions boards should be asking about cyber risk, identifying and managing supply chain risks, and building an organizational culture where cybersecurity is treated as a governance issue, not an IT department problem.

The timing is deliberate. Ireland is currently subject to EU infringement proceedings for failing to fully transpose NIS2 into national law — the Commission referred the country to the Court of Justice on July 8, 2026. Publishing board-level guidance ahead of formal transposition signals that the NCSC is moving organizations toward compliance regardless of where the legislative process stands.

Source: The Irish Government's official portal, 2026

ENISA NIS360 2026: Space sector elevated to high criticality

The ENISA NIS360 2026 report is the third annual assessment of cybersecurity maturity and criticality across all Annex I sectors under the NIS2 Directive. The headline finding: the space sector has joined banking, electricity, aviation, and digital-by-default services in the highest criticality band.

The elevation reflects space infrastructure's growing role as a dependency layer for other sectors: navigation, communications, financial settlement, and military logistics all run on satellite systems. Higher dependency means higher impact from disruption, and higher time criticality in recovery.

Seven sectors fall into the NIS360 2026 risk zone, where cybersecurity maturity falls below the level their criticality demands:

1. Health
2. Railway
3. Maritime
4. ICT service management
5. Space
6. Public administration
7. Drinking and waste water

Three sectors reached the high maturity band: trust services, aviation, and financial market infrastructures. The gas sector has begun moving out of the risk zone, driven by improved information sharing and stronger implementation of risk management measures.

The risk zone composition matters operationally. Supervisory authorities use NIS360 data to prioritize audit calendars. If your organization operates in health, railway, or public administration, expect increased supervisory attention in the second half of 2026.

ENISA NIS Investments 2025 study found that 70% of surveyed organizations cited NIS2, DORA, and CRA compliance as the main driver of cybersecurity spending — a figure that will likely climb as supervisors shift from registration to active review.

Source: ENISA, 2026

Germany: BSI enters active supervision phase

Germany's BSI entered the active supervision phase on March 6, 2026 — the date the registration deadline under the NIS2-Umsetzungsgesetz (NIS2UmsuCG) expired. The law was enacted on December 6, 2025. By June 2026, it had been in force for six months.

SecurityToday.de's June 16 analysis of the supervisory shift noted that the question has changed: no longer whether an entity is registered, but whether its reported measures hold up under scrutiny.

The BSI registration portal opened January 6, 2026. A significant share of the approximately 29,000 in-scope entities missed the March deadline. The BSI set a secondary registration deadline of July 31, 2026. Late registration remains possible but creates no safe harbor — the compliance obligations have applied since December 2025, regardless of registration status.

What active supervision means in practice:

• The BSI can proactively request evidence of security measures — without waiting for an incident.
• On-site and remote audits are now within scope.
• Fines for essential entities reach up to €10 million or 2% of global annual turnover, whichever is higher.
• Management body members face personal liability, including potential temporary bans from exercising management functions.

Germany's implementation goes beyond the EU minimum on executive accountability. The NIS2UmsuCG explicitly requires management bodies to approve cybersecurity measures, supervise their implementation, and demonstrate personal competence. Supervisors can hold individual executives personally responsible for systemic failures.

There is a practical upside to Germany's stricter standard. Organizations that meet the NIS2UmsuCG requirements satisfy the EU minimum with margin. For companies operating across multiple member states, a security posture that passes BSI scrutiny will generally hold up with neighboring supervisory authorities as well.

For late registrants, the priority order is clear: register first, then establish documented evidence of measures. If a reportable incident occurs before measures are demonstrably in place, a missed or delayed registration is an aggravating factor.

Source: SecurityToday.de, 2026

EU Action Plan on Cybersecurity and AI published

On July 7, 2026, the European Commission published the EU Action Plan on Cybersecurity and Artificial Intelligence. The document sets out a coordinated EU approach to AI-driven cybersecurity across member states, public authorities, and businesses.

The plan is built around three objectives: promoting safe and responsible use of advanced AI, reinforcing EU cybersecurity and resilience, and scaling up Europe's AI capabilities for cybersecurity purposes.

On the NIS2 side, the Action Plan explicitly names the NIS2 Directive as part of the existing legal framework it builds on, and encourages organizations subject to NIS2 to use AI (including open-source models) to detect and address vulnerabilities faster. This is the first EU-level document to formally link NIS2 compliance with AI-assisted threat detection as an expected operational practice.

Concrete measures include:

• A European Blueprint for secure access to advanced AI systems for cybersecurity purposes, to be developed with ENISA.
• A secure testing platform for organizations in critical sectors (energy, transport, health, finance, and public administration) to safely test and deploy AI solutions.
• An EU Grand Challenge on AI for cybersecurity, bringing together industry, researchers, and open-source communities.

The Action Plan sits alongside the AI Act, the Cyber Resilience Act, DORA, and the Cyber Solidarity Act. It does not create new binding obligations on its own, but it signals where the Commission expects enforcement emphasis and investment to go over the next legislative cycle.

Source: European Commision, 2026

UK: Cyber Security and Resilience Bill passes Commons, enters Lords

On June 16, 2026, the Cyber Security and Resilience (Network and Information Systems) Bill completed its third reading and report stage in the House of Commons. It received its first reading in the Lords on June 17 and is scheduled for a Lords second reading on July 14, 2026.

The Bill was introduced to Parliament on November 12, 2025, and updates the existing Network and Information Systems Regulations 2018 (NIS1). It does not transpose NIS2 (the UK is no longer bound by EU law) but it moves UK requirements significantly closer to the NIS2 standard in scope and enforcement.

What the Bill adds:

• Managed service providers come into scope for the first time. Relevant Managed Service Providers (RMSPs) must register with the ICO, implement risk management measures, and nominate a UK representative if not established in the UK.
• Data centre operators are also brought into scope.
• Incident reporting timelines tighten: 24-hour initial report, 72-hour full notification — matching NIS2's Article 23 structure.
• Critical supplier designation: The ICO gains power to designate suppliers whose compromise would affect essential services or RMSPs.
• Penalties increase to up to £17 million or 4% of global annual turnover for serious breaches; up to £10 million or 2% for less serious ones.

The incident definition is also broadened: the Bill covers incidents "capable of having an adverse effect" on regulated services, not just those with a demonstrated actual effect. This is a meaningful change for organizations currently calibrating their reporting thresholds.

63 amendments have been proposed during the Bill's passage. Two amendments tabled in June, including one to add the food supply chain as a regulated essential service, received no decision at report stage.

The government expects to consult in 2026 on secondary legislation covering specific risk management measures and notification requirements. Some provisions will take effect from the first day or second month after Royal Assent; others will follow via secondary legislation.

Sources: UK Parliament, 2026; Parallel Parliament, 2026

Recap

The period from June to early July 2026 marks the point where NIS2 enforcement moved from political pressure to active legal and supervisory action. Court referrals are filed. National laws are entering force. Supervisory authorities are requesting evidence of security measures, not just registration confirmations.

For organizations in Ireland, Spain, France, and the Netherlands, the infringement proceedings change nothing about the underlying obligations. NIS2 requirements have been binding since October 2024 regardless of national transposition status. The proceedings add financial consequences for governments — they do not create a grace period for regulated entities.

For organizations in Germany and the Netherlands, the compliance calendar is now set. The BSI is auditing. The Cyberbeveiligingswet enters force August 15. The Article 21 mapping document published by the NIS Cooperation Group in June 2026 is the most actionable output from this period: if your team is already working against ISO 27001 or NIST CSF 2.0, it provides a direct path to closing your NIS2 gap analysis before a supervisory authority does it on your behalf.

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

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

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

Die Wahl eines Credential-Managers für ein europäisches Unternehmen im Jahr 2026 ist ebenso eine Compliance-Entscheidung wie eine Produktentscheidung. 

Der Missbrauch von Anmeldedaten bleibt einer der häufigsten Wege in Unternehmensumgebungen. Der Data Breach Investigations Report 2026 von Verizon bestätigt, dass 50 % der Ransomware-Opfer innerhalb von 95 Tagen vor dem Angriff ein Credential- oder Infostealer-Ereignis hatten. 

Gleichzeitig hat die DSGVO-Durchsetzung echte Durchschlagskraft. Im April 2026 verhängte die italienische Garante gegen das Beratungsunternehmen Ambrosetti ein Bußgeld von 85.000 € für die Speicherung von Passwörtern im Klartext und die Verwendung von MD5-Hashing, wobei ausdrücklich auf DSGVO-Artikel 32 als Grundlage verwiesen wurde. NIS2 ist kein Entwurf mehr: 23 von 27 EU-Mitgliedstaaten haben es laut dem ECSO-Transpositions-Tracker in nationales Recht umgesetzt. 

Bei der Bewertung von Lösungen wie Passwork und 1Password spielen Faktoren jenseits der Funktionen eine Rolle. Dieser Artikel vergleicht beide Produkte aus dieser Perspektive: Jurisdiktion, Datensouveränität, Bereitstellungsflexibilität, Audit-Bereitschaft, langfristige Compliance mit DSGVO und NIS2 sowie Gesamtbetriebskosten.

Die wichtigsten Erkenntnisse

• Beide Plattformen bieten Enterprise-Passwortverwaltung, verwenden jedoch unterschiedliche architektonische Ansätze. 1Password ist ein cloudbasierter Dienst, der auf seinem Secret-Key-Sicherheitsmodell aufbaut, während Passwork eine selbstgehostete Bereitstellung mit clientseitiger AES-256-Verschlüsselung bietet.
• Das Bereitstellungsmodell bestimmt, wer die Infrastruktur kontrolliert und wer dafür verantwortlich ist. Bei einer selbstgehosteten Bereitstellung verwaltet Ihre Organisation die Umgebung. Bei einem SaaS-Dienst betreibt der Anbieter die Infrastruktur und unterliegt den Gesetzen seiner eigenen Jurisdiktion.
• Datenresidenz und Datensouveränität adressieren unterschiedliche Aspekte der Daten-Governance. Die Wahl eines EU-Rechenzentrums bestimmt, wo Ihre Daten gespeichert werden. Es bestimmt jedoch nicht allein, welche Landesgesetze auf den Dienstanbieter Anwendung finden können.
• DSGVO und NIS2 konzentrieren sich darauf, wie Organisationen den Zugriff auf Anmeldedaten schützen und verwalten. Organisationen sollten in der Lage sein, angemessene technische Kontrollen, Zugangsverwaltung, Protokollierung und Audit-Nachweise nachzuweisen.
• Bei 100 Benutzern kostet Passwork Standardlizenz 3.600 €/Jahr gegenüber ca. 9.588 $/Jahr für 1Password Business. Passwork wird mit 3 €/Benutzer/Monat (Standardlizenz) oder 4,5 €/Benutzer/Monat (Erweiterte Lizenz) berechnet. 1Password Business kostet 7,99 $/Benutzer/Monat. Enterprise-Stufen werden bei beiden Anbietern individuell angeboten.
• Wählen Sie 1Password, wenn Ihr Team operativen Komfort und eine ausgefeilte Cloud-Erfahrung gegenüber strikter Datensouveränität priorisiert. Wählen Sie Passwork, wenn Ihre Organisation der DSGVO, NIS2 oder DORA unterliegt und nachweisen muss, dass Anmeldedaten niemals Ihre eigene Infrastruktur verlassen.

Das Compliance-Schlachtfeld: Datenresidenz vs. Datensouveränität

Europäische Organisationen, die Passwort-Manager evaluieren, müssen zwischen Datenresidenz und Datensouveränität unterscheiden. Datenresidenz definiert, wo Daten gespeichert werden. Datensouveränität definiert, welches Rechtssystem sie regiert. Eine cloudbasierte Lösung kann EU-Datenresidenz bieten, während sie dennoch einer nicht-europäischen Jurisdiktion unterliegt. Selbstgehostete Lösungen schließen diese Lücke, indem Anmeldedaten vollständig innerhalb der eigenen Infrastruktur der Organisation verbleiben — unter einem einzigen, vorhersehbaren Rechtsrahmen.

1Password bietet EU-Datenresidenz: Kunden können eine europäische Hosting-Region auswählen, und Tresor-Daten befinden sich auf Servern innerhalb der EU. Dies allein löst jedoch nicht alle Jurisdiktionsbedenken für Organisationen mit strengen Souveränitätsanforderungen.

Was grenzüberschreitender Datenzugriff für Cloud-Anbieter bedeutet

Wenn ein cloudbasierter Credential-Manager von einem Unternehmen außerhalb der EU betrieben wird, ist die zentrale Compliance-Frage nicht, wo sich die Server befinden, sondern welches Rechtssystem dieses Unternehmen zur Datenoffenlegung zwingen kann.

Jeder nicht-europäische Anbieter kann rechtmäßige Anfragen von Behörden in seiner Heimatjurisdiktion erhalten. Das anwendbare Recht hängt davon ab, wo der Anbieter eingetragen ist, nicht wo die Daten gespeichert werden.

Der U.S. CLOUD Act (2018) ist das bekannteste Beispiel. Er ermöglicht es US-amerikanischen Strafverfolgungsbehörden, von in den USA eingetragenen Anbietern die Herausgabe von weltweit gespeicherten Daten zu verlangen.

1Password ist kein US-Unternehmen. AgileBits Inc. ist in Kanada eingetragen, sodass der CLOUD Act nicht in gleicher Weise gilt wie für US-Anbieter. Kanada nimmt jedoch an internationalen Rahmenwerken für die Zusammenarbeit der Strafverfolgungsbehörden wie Five Eyes teil, was bedeutet, dass grenzüberschreitende rechtliche Anfragen weiterhin zu berücksichtigen sind.

DSGVO-Artikel 48 besagt, dass eine ausländische Gerichtsentscheidung allein keine gültige Rechtsgrundlage für die Übermittlung personenbezogener Daten aus der EU darstellt. Diese Einschränkung gilt in erster Linie für Ihre Organisation als Verantwortlicher.

Wie jeder cloudbasierte Credential-Manager, der von einer nicht-europäischen Einheit betrieben wird, führt 1Password eine Ebene jurisdiktioneller Komplexität ein, die eine selbstgehostete Bereitstellung nicht hat.

Wie eine On-Premise-Bereitstellung die Lücke schließt

Das selbstgehostete Modell von Passwork bedeutet, dass kein Dritter Ihre Anmeldedaten besitzt. Bereitgestellt auf Ihrer eigenen Infrastruktur innerhalb der EU-Jurisdiktion verlassen Tresorinhalte niemals Ihre Umgebung. Kein externes Unternehmen kann eine ausländische Regierungsanordnung für Daten erhalten, auf die es keinen Zugriff hat. Die Gesetze, die Ihre Daten regieren, sind die Gesetze der Jurisdiktion, in der sich Ihre Server befinden.

Passwork ist als selbstgehostete Lösung und in einer souveränen EU-Cloud verfügbar und gibt Ihnen die volle Kontrolle über Ihre Daten und Infrastruktur. Erkunden Sie die Bereitstellungsoptionen — passwork.pro

Funktionsvergleich: Passwork vs. 1Password

Passwork und 1Password auf der Business-Stufe teilen eine gemeinsame Basis: AES-256-Verschlüsselung, RBAC, SSO und Entwicklertools. Die Unterschiede zeigen sich auf architektonischer Ebene. Die selbstgehostete Bereitstellung von Passwork gibt der Organisation direkte Kontrolle über Verschlüsselungsschlüssel, Audit-Logs und den Admin-Perimeter — ohne Abhängigkeit von Anbieter-Infrastruktur oder ausgehender Konnektivität zu externen Diensten.

Sicherheitsarchitektur

Die Secret-Key-Architektur von 1Password erfordert einen 128-Bit-Schlüssel, der als 34-Zeichen-String codiert ist und bei der Geräteeinrichtung generiert wird. Dieser wird mit dem Masterpasswort kombiniert, um den Verschlüsselungsschlüssel abzuleiten. Selbst wenn die Server von 1Password kompromittiert würden, wäre es rechnerisch nicht machbar, verschlüsselte Tresore ohne den Secret Key zu entschlüsseln. Es ist ein gut konzipiertes Cloud-Sicherheitsmodell.

Passwork verwendet clientseitige Zero-Knowledge-Verschlüsselung auf einer selbstgehosteten Instanz. Ver- und Entschlüsselung erfolgen auf dem Client (Benutzergerät). Der Server speichert nur Chiffretext. Da Sie die Plattform hosten, behalten Sie die vollständige Kontrolle über den Anwendungsserver, Verschlüsselungsschlüssel und Audit-Logs. Diese Bereitstellung garantiert eine isolierte Umgebung, frei von gemeinsam genutzter Infrastruktur, Multi-Tenant-Risiken oder Abhängigkeit von Anbieter-Schlüsselverwaltung.

Enterprise-Administration: RBAC, AD/LDAP und SSO

Beide Plattformen decken die Enterprise-Administrationsfunktionen ab, die IT-Teams erwarten.

1Password Business umfasst SCIM-Provisioning, SSO-Integration über Okta und Azure AD sowie eine ausgereifte Admin-Konsole. Sein Extended Access Management-Produkt (verfügbar als separat lizenziertes Add-on) erweitert Gerätevertrauen und Anwendungszugriffskontrollen über den Passwort-Tresor hinaus.

Passwork bietet granulare rollenbasierte Zugriffskontrolle (RBAC), native Active Directory- und LDAP-Integration für Benutzer-Provisioning und Gruppensynchronisation sowie SAML SSO. Um die Verwaltung im großen Maßstab zu vereinfachen, trennt Passwork den Datenzugriff von administrativen Berechtigungen durch zwei unterschiedliche Mechanismen:

• Benutzergruppen steuern den Datenzugriff — Administratoren weisen Berechtigungen für Tresore und Ordner auf Gruppenebene zu. Wenn Benutzer einer Gruppe hinzugefügt werden, erben sie automatisch den Zugriff auf die entsprechenden Passwörter und Anmeldedaten. 
• Rollen definieren Systemrechte — Vordefinierte und benutzerdefinierte Rollen verwalten den Zugriff auf Systemeinstellungen, Benutzerverzeichnisse und Audit-Logs. Dies stellt sicher, dass Standardbenutzer nur mit ihren zugewiesenen Tresoren interagieren, während Administratoren die Infrastruktur verwalten, ohne unter dem Zero-Knowledge-Modell Zugriff auf tatsächliche Passwörter zu haben.

Für Organisationen, die AD-basierte Identitätsinfrastruktur betreiben (die Mehrheit der europäischen Unternehmen), bedeutet die LDAP-Integration, dass Onboarding und Offboarding über bestehende Verzeichnis-Workflows laufen. Sicherheitsgruppen werden automatisch synchronisiert, sodass Tresor-Berechtigungen und administrative Rollen mit Ihrem zentralen Verzeichnis abgestimmt bleiben.

Ein praktischer Unterschied, der erwähnt werden sollte: Da Passwork selbstgehostet ist, befinden sich Admin-Konsole, Audit-Logs und Benutzerverzeichnis alle innerhalb Ihres eigenen Netzwerkperimeters. Administrative Operationen haben keine Abhängigkeit von einem Verfügbarkeits-SLA des Anbieters.

DevOps und Secrets Management

1Password hat stark in Entwicklertools investiert. Seine CLI (op), Secrets Automation und native Integrationen mit GitHub Actions, Kubernetes und CI/CD-Pipelines machen es zu einem leistungsfähigen Secrets Manager für cloud-native Teams. Die Entwicklererfahrung ist ausgereift.

Passwork bietet eine vollständige REST API und CLI-Tools für DevOps-Workflows: Einspeisung von Secrets in Pipelines, programmatische Rotation von Anmeldedaten, Verwaltung von API-Schlüsseln und Datenbank-Anmeldedaten zusammen mit menschlichen Passwörtern in einem einheitlichen Tresor.

Für Teams, die in air-gapped oder strikt perimeter-kontrollierten Umgebungen arbeiten, ist der architektonische Unterschied relevant. 1Password bietet zwar einen selbstgehosteten Connect Server, der Secrets lokal zwischenspeichert und die Abhängigkeit von der 1Password-API reduziert, aber die Ersteinrichtung und periodische Synchronisation erfordern weiterhin ausgehende Konnektivität zur Cloud-Infrastruktur von 1Password. 

Passwork erfordert zu keinem Zeitpunkt eine solche Abhängigkeit: Der gesamte Stack läuft vom ersten Tag an innerhalb des eigenen Unternehmensperimeters, ohne Aufrufe zu externen Diensten. Für Organisationen, bei denen ausgehender Datenverkehr zur Cloud eines Anbieters durch Richtlinien oder Architektur nicht erlaubt ist, ist dieser Unterschied eine harte Anforderung.

Zukunftssicherheit: NIS2 und das Post-Quantum-Mandat 2027

NIS2 fügte eine Klausel hinzu, die Anbieter lieber übersehen würden

NIS2-Artikel 21 setzt die Sicherheit Ihrer IKT-Dienstleister auf Ihr Risikoregister. Nicht auf deren — auf Ihres. Ein cloudbasierter Passwort-Manager ist ein IKT-Dienstleister. Unter NIS2 ist Ihre Organisation dafür verantwortlich zu bewerten, ob die Sicherheitslage dieses Anbieters — einschließlich seiner rechtlichen Jurisdiktion und Incident-Response-Verpflichtungen — Ihrer Risikoschwelle entspricht.

Wenn ein Sicherheitsvorfall bei Ihrem Passwort-Manager-Anbieter Ihre Anmeldedaten offenlegt, können NIS2-Incident-Reporting-Verpflichtungen auf Ihrer Seite ausgelöst werden: Erstmeldung innerhalb von 24 Stunden, detaillierter Bericht innerhalb von 72 Stunden.

Die Bereitstellung einer selbstgehosteten Lösung verändert dieses Risikoprofil. Die Angriffsfläche ist Ihre Infrastruktur, die von Ihren Sicherheitskontrollen geregelt und von Ihrem Team auditiert wird. NIS2-Lieferketten-Risikobewertungen werden wesentlich einfacher, wenn die „Lieferkette" für die Credential-Speicherung intern ist.

Das ANSSI-Mandat 2027 für quantensichere Kryptographie

Frankreichs nationale Cybersicherheitsbehörde ANSSI kündigte an, ab 2027 keine Sicherheitsprodukte (einschließlich Passwort-Manager) mehr zu zertifizieren, die keine quantenresistente Verschlüsselung haben. Bis 2030 erwartet ANSSI, dass alle Geschäftsbeschaffungen quantensichere Kryptographie erfordern. Für Organisationen in Frankreich und in der gesamten EU schafft dies eine harte Zertifizierungsfrist innerhalb der nächsten 12–18 Monate.

Die relevante Frage für Beschaffungsteams ist nicht nur, ob ein Anbieter PQC unterstützt, sondern ob die Organisation kontrolliert, wann und wie diese Umstellung erfolgt.

Bei einem cloudbasierten Passwort-Manager erfolgt die Migration der Tresor-Verschlüsselungsschicht nach dem Zeitplan des Anbieters, über gemeinsam genutzte Infrastruktur. Bei einer selbstgehosteten Bereitstellung wendet Ihre Organisation kryptographische Updates (einschließlich NIST-standardisierter PQC-Algorithmen) nach Ihrem eigenen Zeitplan an, ohne Abhängigkeit vom Release-Zyklus eines Anbieters.

Preisgestaltung und Gesamtbetriebskosten

Übersicht der Preise

1Password Business wird mit 7,99 $ pro Benutzer pro Monat (jährliche Abrechnung) berechnet. Der Teams-Plan liegt bei 4,99 $/Benutzer/Monat. Enterprise-Preise erfordern ein individuelles Angebot.

Die Preisgestaltung von Passwork ist auf europäische Käufer ausgerichtet:

Bei 100 Benutzern kostet Passwork Standardlizenz 3.600 €/Jahr gegenüber 1Password Business mit etwa 9.588 $/Jahr. Die Differenz wächst mit zunehmender Skalierung.

TCO jenseits der Lizenzgebühr

On-Premise-Bereitstellung erfordert Server-Infrastruktur, Wartung und internen operativen Aufwand. Für Organisationen, die bereits On-Premises-Infrastruktur betreiben (die meisten europäischen Unternehmen in regulierten Sektoren), sind die Grenzkosten für das Hinzufügen einer selbstgehosteten Passwork-Instanz gering. Für Organisationen ohne On-Premises-Präsenz ist der Infrastruktur-Overhead eine echte Überlegung und sollte vor Vertragsunterzeichnung ehrlich eingeschätzt werden.

Die TCO-Berechnung benötigt auch eine Zeile für Compliance-Risiko. Ein Sicherheitsvorfall mit einem cloudbasierten Credential-Speicher kann DSGVO-Artikel 83-Bußgelder von bis zu 10 Millionen € oder 2 % des weltweiten Jahresumsatzes für Verstöße gegen die Sicherheitsanforderungen von Artikel 32 auslösen. DSGVO-Bußgelder haben bis 2026 kumulativ 6,31 Milliarden € überschritten. Der Ambrosetti-Fall (85.000 € für MD5-gehashte Passwörter) zeigt, dass Datenschutzbehörden jetzt die kryptographische Implementierung direkt prüfen — nicht nur Zeitpläne für Benachrichtigungen bei Sicherheitsvorfällen.

Fazit: Welcher Passwort-Manager passt zu EU-basierten Organisationen

Die Wahl eines Passwort-Managers für den Enterprise-Einsatz läuft auf die Frage hinaus: Wo endet Ihr Compliance-Perimeter? Cloud-native Teams mit modernen Identity-Stacks finden eine natürliche Passung in tiefen Ökosystem-Integrationen und plattformübergreifender UX. Organisationen, die unter DSGVO, NIS2 oder DORA operieren, stehen vor einer anderen Einschränkung — nicht Benutzerfreundlichkeit, sondern Jurisdiktion. 

Wählen Sie 1Password Business, wenn:

• Ihr Team global verteilt und cloud-native ist
• Sie Entwicklererfahrung und plattformübergreifende UX über Compliance-Architektur priorisieren
• Ihr regulatorisches Umfeld keine strikte Datensouveränität erfordert
• Sie Extended Access Management oder tiefe Integration mit einem modernen Cloud-Identity-Stack benötigen

Wählen Sie Passwork, wenn:

• Ihre Organisation der DSGVO, NIS2 oder DORA unterliegt und Datensouveränität nachweisen muss
• Sie in kritischer Infrastruktur, Finanzdienstleistungen, Gesundheitswesen oder dem öffentlichen Sektor tätig sind
• Sie AD/LDAP-native Integration innerhalb einer bestehenden On-Premises-Identitätsumgebung benötigen
• Sie sich auf ANSSI-Zertifizierung oder EU-Beschaffung im öffentlichen Sektor vorbereiten
• Ihr Sicherheitsteam die volle Kontrolle über die Verschlüsselungsschicht, Audit-Logs und Schlüsselverwaltung benötigt

Für europäische Unternehmen in regulierten Sektoren ist die Architektur, die bei allen fünf Kriterien „Ja" antwortet, selbstgehostet, On-Premise und jurisdiktionell sauber. 

Passwork bietet europäischen IT-Teams einen selbstgehosteten, DSGVO-konformen Credential-Tresor mit vollständiger Audit-Protokollierung, AD/LDAP-Integration und Zero-Knowledge-Verschlüsselung — alles innerhalb Ihrer eigenen Infrastruktur. Fordern Sie eine Demo an oder erkunden Sie den Leitfaden zur selbstgehosteten Bereitstellung — passwork.pro

Häufig gestellte Fragen

Elegir un gestor de credenciales para una empresa europea en 2026 es tanto una decisión de cumplimiento normativo como una decisión de producto.

El abuso de credenciales sigue siendo una de las vías más comunes de acceso a entornos corporativos. El informe Data Breach Investigations Report 2026 de Verizon confirma que el 50% de las víctimas de ransomware experimentaron un evento relacionado con credenciales o infostealers en los 95 días previos al ataque.

Al mismo tiempo, la aplicación del RGPD tiene consecuencias reales. En abril de 2026, el Garante italiano multó a la consultora Ambrosetti con 85.000 € por almacenar contraseñas en texto plano y usar hash MD5, citando explícitamente el Artículo 32 del RGPD como fundamento. NIS2 ya no es un borrador: 23 de los 27 estados miembros de la UE lo han transpuesto a la legislación nacional, según el rastreador de transposición de ECSO.

Al evaluar soluciones como Passwork y 1Password, los factores más allá de las funcionalidades empiezan a importar. Este artículo compara ambos productos desde esa perspectiva: jurisdicción, soberanía de datos, flexibilidad de despliegue, preparación para auditorías, cumplimiento a largo plazo con RGPD y NIS2, y coste total de propiedad.

Puntos clave

• Ambas plataformas proporcionan gestión de contraseñas empresarial, pero utilizan enfoques arquitectónicos diferentes. 1Password es un servicio basado en la nube construido en torno a su modelo de seguridad Secret Key, mientras que Passwork ofrece despliegue autoalojado con cifrado AES-256 del lado del cliente.
• El modelo de despliegue determina quién controla la infraestructura y quién es responsable de ella. Con un despliegue autoalojado, su organización gestiona el entorno. Con un servicio SaaS, el proveedor opera la infraestructura y permanece sujeto a las leyes de su propia jurisdicción.
• La residencia de datos y la soberanía de datos abordan aspectos diferentes de la gobernanza de datos. Elegir un centro de datos en la UE determina dónde se almacenan sus datos. Por sí solo, no determina qué leyes de qué país pueden aplicarse al proveedor del servicio.
• El RGPD y NIS2 se centran en cómo las organizaciones protegen y gestionan el acceso a las credenciales. Las organizaciones deben poder demostrar controles técnicos apropiados, gestión de accesos, registro de actividad y evidencia de auditoría.
• Con 100 usuarios, Passwork licencia estándar cuesta 3.600 €/año frente a ~9.588 $/año de 1Password Business. Passwork tiene un precio de 3 €/usuario/mes (licencia estándar) o 4,5 €/usuario/mes (licencia avanzada). 1Password Business cuesta 7,99 $/usuario/mes. Los niveles Enterprise tienen precios personalizados en ambos casos.
• Elija 1Password si su equipo prioriza la comodidad operativa y una experiencia en la nube pulida sobre la soberanía de datos estricta. Elija Passwork si su organización está sujeta al RGPD, NIS2 o DORA y necesita demostrar que los datos de credenciales nunca salen de su propia infraestructura.

El campo de batalla del cumplimiento: Residencia de datos vs. soberanía de datos

Las organizaciones europeas que evalúan gestores de contraseñas necesitan distinguir entre residencia de datos y soberanía de datos. La residencia de datos define dónde se almacenan los datos. La soberanía de datos define qué sistema legal los gobierna. Una solución basada en la nube puede ofrecer residencia de datos en la UE mientras sigue estando sujeta a jurisdicción fuera de la UE. Las soluciones autoalojadas eliminan esa brecha al mantener los datos de credenciales completamente dentro de la propia infraestructura de la organización, bajo un marco legal único y predecible.

1Password ofrece residencia de datos en la UE: los clientes pueden seleccionar una región de alojamiento europea, y los datos de la bóveda residen en servidores dentro de la UE. Sin embargo, esto por sí solo no resuelve todas las preocupaciones jurisdiccionales para organizaciones con requisitos estrictos de soberanía.

Qué significa el acceso transfronterizo a datos para los proveedores en la nube

Cuando un gestor de credenciales basado en la nube es operado por una empresa fuera de la UE, la pregunta clave de cumplimiento no es dónde están ubicados los servidores, sino qué sistema legal puede obligar a esa empresa a divulgar datos.

Cualquier proveedor fuera de la UE puede recibir solicitudes legales de las autoridades de su jurisdicción de origen. La ley aplicable depende de dónde está constituido el proveedor, no de dónde se almacenan los datos.

La CLOUD Act de EE. UU. (2018) es el ejemplo más conocido. Permite a las fuerzas del orden estadounidenses exigir a los proveedores constituidos en EE. UU. que entreguen datos almacenados en cualquier parte del mundo.

1Password no es una empresa estadounidense. AgileBits Inc. está constituida en Canadá, por lo que la CLOUD Act no se aplica de la misma manera que a los proveedores estadounidenses. Sin embargo, Canadá participa en marcos de cooperación internacional de aplicación de la ley como Five Eyes, lo que significa que las solicitudes legales transfronterizas siguen siendo una consideración.

El Artículo 48 del RGPD establece que una orden judicial extranjera por sí sola no es una base legal válida para transferir datos personales desde la UE. Esa restricción se aplica principalmente a su organización como responsable del tratamiento de datos.

Como cualquier gestor de credenciales basado en la nube operado por una entidad fuera de la UE, 1Password introduce una capa de complejidad jurisdiccional que un despliegue autoalojado no tiene.

Cómo el despliegue en las instalaciones cierra la brecha

El modelo autoalojado de Passwork significa que ningún tercero tiene sus datos de credenciales. Desplegado en su propia infraestructura dentro de la jurisdicción de la UE, el contenido de las bóvedas nunca abandona su entorno. Ninguna empresa externa puede recibir una orden de un gobierno extranjero para datos a los que no tiene acceso. Las leyes que gobiernan sus datos son las leyes de la jurisdicción donde se encuentran sus servidores.

Passwork está disponible como solución autoalojada y en una nube soberana de la UE, ofreciéndole control total sobre sus datos e infraestructura. Explore las opciones de despliegue — passwork.pro

Comparativa de funcionalidades: Passwork vs 1Password

Passwork y 1Password en el nivel Business comparten una base común: cifrado AES-256, RBAC, SSO y herramientas para desarrolladores. Las diferencias emergen a nivel arquitectónico. El despliegue autoalojado de Passwork otorga a la organización control directo sobre las claves de cifrado, los registros de auditoría y el perímetro de administración sin dependencia de la infraestructura del proveedor ni conectividad saliente a servicios externos.

Arquitectura de seguridad

La arquitectura Secret Key de 1Password requiere una clave de 128 bits codificada como una cadena de 34 caracteres generada en la configuración del dispositivo, combinada con la contraseña maestra, para derivar la clave de cifrado. Incluso si los servidores de 1Password fueran comprometidos, las bóvedas cifradas serían computacionalmente inviables de descifrar sin la Secret Key. Es un modelo de seguridad en la nube bien diseñado.

Passwork utiliza cifrado de conocimiento cero del lado del cliente en una instancia autoalojada. El cifrado y descifrado ocurren en el cliente (dispositivo del usuario). El servidor almacena solo texto cifrado. Dado que usted aloja la plataforma, mantiene control completo sobre el servidor de aplicaciones, las claves de cifrado y los registros de auditoría. Este despliegue garantiza un entorno aislado, libre de infraestructura compartida, riesgos de multitenencia o dependencia de la gestión de claves del proveedor.

Administración empresarial: RBAC, AD/LDAP y SSO

Ambas plataformas cubren las funcionalidades de administración empresarial que los equipos de TI esperan.

1Password Business incluye aprovisionamiento SCIM, integración SSO vía Okta y Azure AD, y una consola de administración madura. Su producto Extended Access Management (disponible como complemento con licencia separada) extiende la confianza de dispositivos y los controles de acceso a aplicaciones más allá de la propia bóveda de contraseñas.

Passwork proporciona control de acceso basado en roles (RBAC) granular, integración nativa con Active Directory y LDAP para aprovisionamiento de usuarios y sincronización de grupos, y SSO SAML. Para simplificar la gestión a escala, Passwork separa el acceso a datos de los privilegios administrativos mediante dos mecanismos distintos:

• Los grupos de usuarios controlan el acceso a datos — Los administradores asignan permisos a bóvedas y carpetas a nivel de grupo. Cuando los usuarios se añaden a un grupo, heredan automáticamente el acceso a las contraseñas y credenciales correspondientes.
• Los roles definen privilegios del sistema — Los roles predefinidos y personalizados gestionan el acceso a la configuración del sistema, directorios de usuarios y registros de auditoría. Esto asegura que los usuarios estándar solo interactúen con sus bóvedas asignadas, mientras que los administradores gestionan la infraestructura sin tener acceso a las contraseñas reales bajo el modelo de conocimiento cero.

Para organizaciones que ejecutan infraestructura de identidad basada en AD (la mayoría de las empresas europeas), la integración LDAP significa que la incorporación y baja de usuarios se ejecuta a través de los flujos de trabajo de directorio existentes. Los grupos de seguridad se sincronizan automáticamente, asegurando que los permisos de bóveda y los roles administrativos permanezcan alineados con su directorio central.

Una diferencia práctica que vale la pena mencionar: debido a que Passwork es autoalojado, la consola de administración, los registros de auditoría y el directorio de usuarios residen dentro de su propio perímetro de red. Las operaciones administrativas no tienen dependencia del SLA de disponibilidad de un proveedor.

DevOps y gestión de secretos

1Password ha invertido fuertemente en herramientas para desarrolladores. Su CLI (op), Secrets Automation e integraciones nativas con GitHub Actions, Kubernetes y pipelines CI/CD lo convierten en un gestor de secretos capaz para equipos cloud-native. La experiencia de desarrollador está pulida.

Passwork ofrece una API REST completa y herramientas CLI para flujos de trabajo DevOps: inyectar secretos en pipelines, rotar credenciales programáticamente, gestionar claves API y credenciales de bases de datos junto con contraseñas humanas en una bóveda unificada.

Para equipos que operan en entornos aislados o estrictamente controlados por perímetro, la diferencia arquitectónica importa. 1Password ofrece un Connect Server autoalojado que almacena secretos en caché localmente y reduce la dependencia de la API de 1Password, pero la configuración inicial y la sincronización periódica todavía requieren conectividad saliente a la infraestructura en la nube de 1Password.

Passwork no requiere tal dependencia en ninguna etapa: toda la pila se ejecuta dentro del propio perímetro de la empresa desde el primer día, sin llamadas a servicios externos. Para organizaciones donde el tráfico saliente a la nube de un proveedor no está permitido por política o arquitectura, esa distinción es un requisito indispensable.

Preparación para el futuro: NIS2 y el mandato post-cuántico de 2027

NIS2 añadió una cláusula que los proveedores preferirían que no notara

El Artículo 21 de NIS2 coloca la seguridad de sus proveedores de servicios TIC en su registro de riesgos. No en el de ellos — en el suyo. Un gestor de contraseñas basado en la nube es un proveedor de servicios TIC. Bajo NIS2, su organización es responsable de evaluar si la postura de seguridad de ese proveedor — incluyendo su jurisdicción legal y obligaciones de respuesta a incidentes — cumple con su umbral de riesgo.

Si una brecha en su proveedor de gestor de contraseñas expone sus credenciales, las obligaciones de notificación de incidentes de NIS2 pueden activarse de su lado: notificación inicial en 24 horas, informe detallado en 72 horas.

Desplegar una solución autoalojada modifica ese perfil de riesgo. La superficie de ataque es su infraestructura, gobernada por sus controles de seguridad, auditada por su equipo. Las evaluaciones de riesgo de la cadena de suministro de NIS2 se simplifican sustancialmente cuando la «cadena de suministro» para el almacenamiento de credenciales es interna.

El mandato de seguridad cuántica de ANSSI para 2027

La agencia nacional de ciberseguridad de Francia, ANSSI, anunció que dejará de certificar productos de seguridad (incluidos los gestores de contraseñas) que carezcan de cifrado resistente a la computación cuántica a partir de 2027. Para 2030, ANSSI espera que todas las adquisiciones empresariales requieran criptografía segura ante amenazas cuánticas. Para organizaciones en Francia y en toda la UE, esto crea un plazo de certificación firme en los próximos 12-18 meses.

La pregunta relevante para los equipos de adquisiciones no es solo si un proveedor soporta PQC, sino si la organización controla cuándo y cómo ocurre esa transición.

Con un gestor de contraseñas basado en la nube, la migración de la capa de cifrado de la bóveda ocurre según el calendario del proveedor, a través de infraestructura compartida. Con un despliegue autoalojado, su organización aplica actualizaciones criptográficas (incluidos los algoritmos PQC estandarizados por NIST) en su propio calendario, sin dependencia del ciclo de lanzamiento de un proveedor.

Precios y coste total de propiedad

Precios principales

1Password Business tiene un precio de 7,99 $ por usuario al mes (facturado anualmente). El plan Teams está en 4,99 $/usuario/mes. Los precios Enterprise requieren una cotización personalizada.

Los precios de Passwork están estructurados para compradores europeos:

Con 100 usuarios, Passwork licencia estándar cuesta 3.600 €/año frente a 1Password Business con aproximadamente 9.588 $/año. La diferencia aumenta a mayor escala.

TCO más allá de la tarifa de licencia

El despliegue en las instalaciones requiere infraestructura de servidores, mantenimiento y gastos operativos internos. Para organizaciones que ya ejecutan infraestructura en sus instalaciones (la mayoría de las empresas europeas en sectores regulados), el coste marginal de añadir una instancia autoalojada de Passwork es bajo. Para organizaciones sin presencia en instalaciones propias, los gastos de infraestructura son una consideración real y deben evaluarse honestamente antes de firmar.

El cálculo del TCO también necesita incluir el riesgo de cumplimiento. Una brecha que involucre un almacén de credenciales basado en la nube puede activar multas del Artículo 83 del RGPD de hasta 10 millones de euros o el 2% de la facturación anual global por violaciones de los requisitos de seguridad del Artículo 32. Las multas del RGPD han superado acumulativamente los 6.310 millones de euros para 2026. El caso Ambrosetti (85.000 € por contraseñas con hash MD5) ilustra que las autoridades de protección de datos ahora auditan la implementación criptográfica directamente, no solo los plazos de notificación de brechas.

Veredicto: Qué gestor de contraseñas se adapta a una organización con sede en la UE

Elegir un gestor de contraseñas para uso empresarial se reduce a la pregunta: ¿dónde termina su perímetro de cumplimiento? Los equipos cloud-native con pilas de identidad modernas encontrarán un ajuste natural en las integraciones profundas del ecosistema y la experiencia de usuario multiplataforma. Las organizaciones que operan bajo RGPD, NIS2 o DORA enfrentan una restricción diferente — no la usabilidad, sino la jurisdicción.

Elija 1Password Business si:

• Su equipo está distribuido globalmente y es cloud-native.
• Prioriza la experiencia de desarrollador y la UX multiplataforma sobre la arquitectura de cumplimiento.
• Su entorno regulatorio no requiere soberanía de datos estricta.
• Necesita Extended Access Management o integración profunda con una pila de identidad en la nube moderna.

Elija Passwork si:

• Su organización está sujeta al RGPD, NIS2 o DORA y necesita demostrar soberanía de datos.
• Opera en infraestructura crítica, servicios financieros, sanidad o sector público.
• Necesita integración nativa AD/LDAP dentro de un entorno de identidad existente en sus instalaciones.
• Se está preparando para la certificación ANSSI o adquisiciones del sector público de la UE.
• Su equipo de seguridad necesita control total sobre la capa de cifrado, los registros de auditoría y la gestión de claves.

Para empresas europeas en sectores regulados, la arquitectura que responde «sí» a los cinco criterios es autoalojada, en las instalaciones y jurisdiccionalmente limpia.

Passwork ofrece a los equipos de TI europeos una bóveda de credenciales autoalojada, preparada para el RGPD, con registro de auditoría completo, integración AD/LDAP y cifrado de conocimiento cero — todo dentro de su propia infraestructura. Solicite una demostración o explore la guía de despliegue autoalojado — passwork.pro

Preguntas frecuentes

Choosing a credential manager for a European enterprise in 2026 is a compliance decision as much as it is a product decision. 

Credential abuse remains one of the most common paths into corporate environments. Verizon's 2026 Data Breach Investigations Report confirms that 50% of ransomware victims had a credential or infostealer event within 95 days before the attack. 

At the same time, GDPR enforcement has real teeth. In April 2026, Italy's Garante fined a consulting firm Ambrosetti €85,000 for storing passwords in cleartext and using MD5 hashing, explicitly citing GDPR Article 32 as the basis. NIS2 is no longer a draft: 23 out of 27 EU member states have transposed it into national law, according to the ECSO transposition tracker. 

When evaluating solutions like Passwork and 1Password, factors beyond features start to matter. This article compares both products from that perspective: jurisdiction, data sovereignty, deployment flexibility, audit readiness, long-term compliance with GDPR and NIS2, and total cost of ownership.

Key takeaways

• Both platforms provide enterprise password management, but they use different architectural approaches. 1Password is a cloud-based service built around its Secret Key security model, while Passwork offers self-hosted deployment with client-side AES-256 encryption.
• Deployment model determines who controls the infrastructure and who is responsible for it. With a self-hosted deployment, your organization manages the environment. With a SaaS service, the provider operates the infrastructure and remains subject to the laws of its own jurisdiction.
• Data residency and data sovereignty address different aspects of data governance. Choosing an EU data center determines where your data is stored. It does not, by itself, determine which country's laws may apply to the service provider.
• GDPR and NIS2 focus on how organizations protect and manage access to credentials. Organizations should be able to demonstrate appropriate technical controls, access management, logging, and audit evidence.
• At 100 users, Passwork Standard costs €3,600/year versus ~$9,588/year for 1Password Business. Passwork is priced at €3/user/month (Standard) or €4.5/user/month (Advanced). 1Password Business is $7.99/user/month. Enterprise tiers are custom-quoted on both sides.
• Choose 1Password if your team prioritizes operational convenience and a polished cloud experience over strict data sovereignty. Choose Passwork if your organization is subject to GDPR, NIS2, or DORA and needs to demonstrate that credential data never leaves your own infrastructure.

The compliance battlefield: Data residency vs. data sovereignty

European organizations evaluating password managers need to distinguish between data residency and data sovereignty. Data residency defines where data is stored. Data sovereignty defines which legal system governs it. A cloud-based solution can offer EU data residency while still being subject to non-EU jurisdiction. Self-hosted solutions eliminate that gap by keeping credential data entirely within the organization's own infrastructure, under a single, predictable legal framework.

1Password offers EU data residency: customers can select a European hosting region, and vault data sits on servers inside the EU. It does not, however, by itself resolve all jurisdictional concerns for organizations with strict sovereignty requirements.

What cross-border data access means for cloud vendors

When a cloud-based credential manager is operated by a company outside the EU, the key compliance question is not where the servers are located, but which legal system can compel that company to disclose data.

Any non-EU provider can receive lawful requests from authorities in its home jurisdiction. The applicable law depends on where the provider is incorporated, not where the data is stored.

The U.S. CLOUD Act (2018) is the best-known example. It allows U.S. law enforcement to require U.S.-incorporated providers to produce data stored anywhere in the world.

1Password is not a U.S. company. AgileBits Inc. is incorporated in Canada, so the CLOUD Act does not apply in the same way it does to U.S. providers. Canada, however, participates in international law enforcement cooperation frameworks such as Five Eyes, meaning cross-border legal requests remain a consideration.

GDPR Article 48 states that a foreign court order alone is not a valid legal basis for transferring personal data from the EU. That restriction primarily applies to your organization as the data controller.

Like any cloud-based credential manager operated by a non-EU entity, 1Password introduces a layer of jurisdictional complexity that a self-hosted deployment does not.

How on-premise deployment closes the gap

Passwork's self-hosted model means no third party holds your credential data. Deployed on your own infrastructure within EU jurisdiction, vault contents never leave your environment. No external company can receive a foreign government order for data it doesn't have access to. The laws that govern your data are the laws of the jurisdiction where your servers sit.

Passwork is available as a self-hosted solution and in a sovereign EU cloud, giving you full control over your data and infrastructure. Explore deployment options — passwork.pro

Feature comparison: Passwork vs 1Password

Passwork and 1Password at the Business tier share a common baseline: AES-256 encryption, RBAC, SSO, and developer tooling. The differences emerge at the architectural level. Passwork’s self-hosted deployment gives the organization direct control over encryption keys, audit logs, and the admin perimeter with no dependency on vendor infrastructure or outbound connectivity to external services.

Security architecture

1Password's Secret Key architecture requires a 128-bit key encoded as a 34-character string generated on device setup, combined with the master password, to derive the encryption key. Even if 1Password's servers were compromised, encrypted vaults would be computationally infeasible to crack without the Secret Key. It is a well-designed cloud security model.

Passwork uses client-side, zero-knowledge encryption on a self-hosted instance. Encryption and decryption happen on the client (user device). The server stores only ciphertext. Because you host the platform, you maintain complete control over the application server, encryption keys, and audit logs. This deployment guarantees an isolated environment, free from shared infrastructure, multi-tenant risks, or reliance on vendor key management.

Enterprise administration: RBAC, AD/LDAP, and SSO

Both platforms cover the enterprise administration features IT teams expect.

1Password Business includes SCIM provisioning, SSO integration via Okta and Azure AD, and a mature admin console. Its Extended Access Management product (available as a separately licensed add-on) extends device trust and application access controls beyond the password vault itself.

Passwork provides granular role-based access control (RBAC), native Active Directory and LDAP integration for user provisioning and group sync, and SAML SSO. To simplify management at scale, Passwork separates data access from administrative privileges through two distinct mechanisms:

• User groups control data access — Administrators assign permissions to vaults and folders at the group level. When users are added to a group, they automatically inherit access to the corresponding passwords and credentials. 
• Roles define system privileges — Predefined and custom roles manage access to system settings, user directories, and audit logs. This ensures standard users only interact with their assigned vaults, while administrators manage the infrastructure without having access to actual passwords under the Zero-Knowledge model.

For organizations running AD-based identity infrastructure (the majority of European enterprises) the LDAP integration means onboarding and offboarding run through existing directory workflows. Security groups sync automatically, ensuring that vault permissions and administrative roles remain aligned with your central directory.

One practical difference worth noting: because Passwork is self-hosted, the admin console, audit logs, and user directory all sit within your own network perimeter. Administrative operations have no dependency on a vendor's availability SLA.

DevOps and secrets management

1Password has invested heavily in developer tooling. Its CLI (op), Secrets Automation, and native integrations with GitHub Actions, Kubernetes, and CI/CD pipelines make it a capable secrets manager for cloud-native teams. The developer experience is polished.

Passwork offers a full REST API and CLI tools for DevOps workflows: injecting secrets into pipelines, rotating credentials programmatically, managing API keys and database credentials alongside human passwords in a unified vault.

For teams operating in air-gapped or strictly perimeter-controlled environments, the architectural difference matters. 1Password does offer a self-hosted Connect Server that caches secrets locally and reduces dependency on the 1Password API, but initial setup and periodic synchronisation still require outbound connectivity to 1Password's cloud infrastructure. 

Passwork requires no such dependency at any stage: the entire stack runs inside company’s own perimeter from day one, with no calls to external services. For organisations where outbound traffic to a vendor's cloud is not permitted by policy or architecture, that distinction is a hard requirement.

Future-proofing: NIS2 and the 2027 post-quantum mandate

NIS2 added a clause vendors would prefer you not notice

NIS2 Article 21 puts the security of your ICT service providers on your risk register. A cloud-based password manager is an ICT service provider. Under NIS2, your organization is responsible for evaluating whether that vendor's security posture (including its legal jurisdiction and incident response obligations) meets your risk threshold.

If a breach at your password manager vendor exposes your credentials, NIS2 incident reporting obligations may be triggered on your side: initial notification within 24 hours, detailed report within 72 hours.

Deploying a self-hosted solution shifts that risk profile. The attack surface is your infrastructure, governed by your security controls, audited by your team. NIS2 supply chain risk assessments become substantially simpler when the "supply chain" for credential storage is internal.

The ANSSI 2027 quantum-safe mandate

France's national cybersecurity agency, ANSSI, announced it will stop certifying security products (including password managers) that lack quantum-resistant encryption starting in 2027. By 2030, ANSSI expects all business procurement to require quantum-safe cryptography. For organizations in France and across the EU, this creates a hard certification deadline within the next 12–18 months.

The relevant question for procurement teams is not only whether a vendor supports PQC, but whether the organization controls when and how that transition happens.

With a cloud-based password manager, the migration of the vault encryption layer occurs on the vendor's schedule, across shared infrastructure. With a self-hosted deployment, your organization applies cryptographic updates (including NIST-standardized PQC algorithms) on your own timeline, without dependency on a vendor's release cycle.

Pricing and total cost of ownership

Headline pricing

1Password Business is priced at $7.99 per user per month (billed annually). The Teams plan sits at $4.99/user/month. Enterprise pricing requires a custom quote.

Passwork's pricing is structured for European buyers:

At 100 users, Passwork Standard runs €3,600/year versus 1Password Business at approximately $9,588/year. The gap widens at scale.

TCO beyond the license fee

On-premise deployment requires server infrastructure, maintenance, and internal operational overhead. For organizations that already run on-premises infrastructure (most European enterprises in regulated sectors) the marginal cost of adding a self-hosted Passwork instance is low. For organizations with no on-premises footprint, the infrastructure overhead is a real consideration and should be scoped honestly before signing.

The TCO calculation also needs a line for compliance risk. A breach involving a cloud-based credential store can trigger GDPR Article 83 fines of up to €10 million or 2% of global annual turnover for violations of Article 32 security requirements. GDPR fines have cumulatively exceeded €6,31 billion by 2026. The Ambrosetti case (€85,000 for MD5-hashed passwords) illustrates that DPAs are now auditing cryptographic implementation directly, not just breach notification timelines.

Verdict: Which password manager fits EU-based organization

Choosing a password manager for enterprise use comes down to the question: where does your compliance perimeter end? Cloud-native teams with modern identity stacks will find a natural fit in deep ecosystem integrations and cross-platform UX. Organizations operating under GDPR, NIS2, or DORA have an additional, non-negotiable requirement: jurisdictional control over where credentials are stored and processed. 

Choose 1Password Business if:

• Your team is globally distributed and cloud-native
• You prioritize developer experience and cross-platform UX above compliance architecture
• Your regulatory environment does not require strict data sovereignty
• You need Extended Access Management or deep integration with a modern cloud identity stack

Choose Passwork if:

• Your organization is subject to GDPR, NIS2, or DORA and needs to demonstrate data sovereignty
• You operate in critical infrastructure, financial services, healthcare, or the public sector
• You need AD/LDAP-native integration within an existing on-premises identity environment
• You are preparing for ANSSI certification or EU public sector procurement
• Your security team needs full control over the encryption layer, audit logs, and key management

For European enterprises in regulated sectors, the architecture that answers "yes" to all five of those criteria is self-hosted, on-premise, and jurisdictionally clean. 

Passwork gives European IT teams a self-hosted, GDPR-ready credential vault with full audit logging, AD/LDAP integration, and zero-knowledge encryption — all within your own infrastructure. Request a demo or explore the self-hosted deployment guide — passwork.pro

Frequently asked questions

Die Vorfälle dieser Woche haben einen gemeinsamen Nenner: Zugangsdaten, die vor Wochen oder Monaten gestohlen wurden, öffnen noch immer Türen. Das Patchen der Schwachstelle, die den Diebstahl ermöglichte, macht bereits gestohlene Daten nicht ungültig. Drei Fälle dieser Woche verdeutlichen dies auf unterschiedliche Weise:

• FortiBleed bestätigte, dass über 15.000 verifizierte Fortinet-Admin- und VPN-Zugangsdaten (aus Firewall-Konfigurationsdateien in über 100 Ländern gesammelt) bereits im Umlauf sind. Die Botschaft von CISA war eindeutig: Nach einer Kompromittierung ist die Rotation von Zugangsdaten nicht optional, und Software-Updates allein schließen das Zeitfenster nicht.
• Operation Endgame störte die Infrastruktur hinter Amadey und StealC, zwei der aktivsten Infostealer-Familien. Europol stellte rund 27 Millionen gestohlene Zugangsdaten sicher und beschlagnahmte Hunderte von Servern. Die Infrastruktur ist abgeschaltet; die bereits im Umlauf befindlichen Zugangsdaten sind es nicht.
• Frankreichs FICOBA-Breach erforderte überhaupt keinen Exploit. Ein Angreifer nutzte einen einzigen kompromittierten Beamten-Account, um über zwei Wochen 3,5 Millionen Bankdatensätze zu durchsuchen: keine Software-Schwachstelle, nur ein nicht überwachtes Zugangsdatum, das aktiv blieb.

Die Woche brachte außerdem einen Supply-Chain-Breach bei LastPass über eine Drittanbieter-SaaS-Plattform, einen aktiv ausgenutzten Cisco-SD-WAN-Zero-Day, der Angreifern über zwei Monate Root-Zugriff und versteckte Admin-Konten ermöglichte, sowie eine mutmaßliche 200-GB-Exfiltration vom Europarat, die von ShinyHunters beansprucht wird. 

Auf Branchenseite sammelte das tschechische Unternehmen Wultra 3,5 Mio. € für Post-Quantum-Authentifizierung, und WALLIX kooperierte mit Inria, um das wachsende Problem der Maschinenidentitäten anzugehen: API-Schlüssel, Token und Servicekonten, die die meisten Organisationen noch immer nicht vollständig inventarisieren können.

Dieser Digest behandelt 8 bedeutende Ereignisse vom 22. bis 29. Juni 2026.

FortiBleed: Über 15.000 Fortinet-Admin-Zugangsdaten in über 100 Ländern gestohlen, CISA fordert sofortige Rotation

Sicherheitsforscher deckten eine groß angelegte Credential-Harvesting-Kampagne namens FortiBleed auf, die mehr als 15.000 verifizierte Administrator- und SSL-VPN-Zugangsdaten für Fortinet-FortiGate-Firewalls in über 100 Ländern offenlegte. Die Zugangsdaten, die über mehrere Jahre durch kompromittierte Firewall-Konfigurationsdateien gesammelt wurden, wurden mit Organisationen wie Siemens, DHL und einem türkischen Rüstungsunternehmen in Verbindung gebracht. 

Warum es wichtig ist: FortiBleed verdeutlicht eine kritische Unterscheidung: Das Patchen einer Schwachstelle beseitigt nicht das Risiko, sobald Zugangsdaten bereits gestohlen wurden. Nach der Offenlegung forderte CISA Organisationen auf, sofort zu handeln:

• Sitzungen beenden und Zugangsdaten zurücksetzen. Alle aktiven SSL-VPN- und Admin-Sitzungen beenden. Alle Fortinet-VPN- und Admin-Passwörter zurücksetzen, insbesondere auf internetexponierten Systemen.
• Sichere Speicherung von Zugangsdaten gewährleisten. Die Verwendung von PBKDF2 zur Speicherung von Administrator-Zugangsdaten bestätigen und schwächere Legacy-Hashes gemäß Fortinets Anleitung entfernen.
• Logs überprüfen. Firewall-, VPN-, Authentifizierungs- und Domain-Controller-Logs auf laterale Bewegungen, verdächtige Konten oder nicht autorisierte Konfigurationsänderungen prüfen.
• Phishing-resistente MFA aktivieren. Phishing-resistente MFA für alle Remote-Zugriffs- und Admin-Konten erforderlich machen, einschließlich aller externen Gateways und administrativen Schnittstellen.
• Angriffsfläche reduzieren und Verwaltungszugriff sperren. Die Firewall-Administration vom öffentlichen Internet fernhalten, Verwaltungsschnittstellen auf vertrauenswürdige interne Netzwerke beschränken und unnötige Konten deaktivieren.

Quellen: Dark Reading – 23. Juni 2026

LastPass-Kundensupport-Daten durch Klue-Supply-Chain-Breach gestohlen

LastPass informierte Benutzer, dass Kundensupport- und Vertriebsdaten gestohlen wurden, nachdem Angreifer Klue, eine Drittanbieter-Marktforschungsplattform, kompromittiert hatten. Die Erpressergruppe Icarus missbrauchte Berichten zufolge OAuth-Token, um auf Salesforce-Daten von rund 20 Cybersicherheitsunternehmen zuzugreifen, darunter LastPass, HackerOne und Recorded Future. LastPass erklärte, dass Passwort-Tresore nicht betroffen waren, aber die gestohlenen Daten enthielten Kundennamen, Telefonnummern, E-Mail- und physische Adressen, Support-Fall-Details und Vertriebsunterlagen. 

Warum es wichtig ist: Der Vorfall zeigt, wie SaaS-Integrationen sensible Kundendaten offenlegen können, selbst wenn Kernsysteme sicher bleiben. Für Unternehmen unterstreicht der Vorfall die Notwendigkeit, den SaaS-Zugriff von Drittanbietern zu bewerten, OAuth-Berechtigungen einzuschränken, Integrationsaktivitäten zu überwachen und Lieferanten-Governance als Teil der Identitätssicherheit zu behandeln. Im Rahmen von Regelwerken wie NIS2 werden Lieferantenrisiko und Zugangskontrolle zu Sicherheitsthemen auf Vorstandsebene.

Quellen: TechCrunch – 23. Juni 2026

Operation Endgame: Europol beschlagnahmt Hunderte von Servern, stellt 27 Millionen gestohlene Zugangsdaten aus Amadey- und StealC-Netzwerken sicher

Eine internationale Strafverfolgungsoperation unter Führung von Europol störte die Infrastruktur hinter den Malware-Familien Amadey und StealC, zwei der aktivsten Credential-Stealing-Plattformen. Die Behörden beschlagnahmten Hunderte von Servern und Domains, froren Kryptowährungen der Betreiber ein und stellten rund 27 Millionen gestohlene Zugangsdaten sicher. An der Operation waren mehrere europäische Länder beteiligt, darunter Deutschland, Frankreich, die Niederlande und Großbritannien. Microsoft schätzte, dass diese Malware-Familien während der jüngsten Kampagnen weltweit Hunderttausende von Geräten infizierten.

Warum es wichtig ist: Dies ist eine der größten Störungen des Infostealer-Ökosystems in jüngster Zeit. Organisationen sollten jedoch nicht davon ausgehen, dass das Risiko verschwunden ist. Millionen von gestohlenen Passwörtern und Sitzungstoken sind bereits auf kriminellen Märkten im Umlauf und werden weiterhin Account-Takeover-Angriffe befeuern. 

Quelle: The Hacker News / Europol – 24. Juni 2026

Cisco-SD-WAN-Zero-Day über 2+ Monate ausgenutzt: Angreifer erlangten Root-Zugriff und erstellten versteckte Admin-Konten

Cisco gab bekannt, dass Angreifer eine Zero-Day-Schwachstelle im Catalyst SD-WAN Manager mindestens zwei Monate vor der Offenlegung ausgenutzt hatten. Laut Mandiant erlangten die Angreifer Root-Privilegien, modifizierten Administrator-Zugangsdaten, erstellten versteckte privilegierte Konten und entfernten forensische Beweise, um langfristige Persistenz zu gewährleisten. Cisco veröffentlichte auch Informationen über eine verwandte Authentication-Bypass-Schwachstelle, die dieselbe Plattform betrifft.

Warum es wichtig ist: Viele Organisationen behandeln Netzwerkgeräte als vertrauenswürdige Infrastruktur, doch diese Geräte halten oft hoch privilegierte Zugangsdaten. Einmal kompromittiert, bieten sie Angreifern persistenten administrativen Zugriff über das gesamte Netzwerk. Patching sollte mit kontinuierlicher Überwachung privilegierter Identitäten kombiniert werden.

Quelle: The Hacker News / Google Mandiant – 25. Juni 2026

Kompromittierte Regierungszugangsdaten legen 3,5 Millionen Bankkonten bei französischem FICOBA-Registerbreach offen

Französische Behörden gaben bekannt, dass Angreifer kompromittierte Regierungszugangsdaten nutzten, um auf FICOBA, das nationale Bankkontoverzeichnis des Landes, zuzugreifen. Über einen Zeitraum von etwa zwei Wochen sahen Angreifer Informationen ein, die mit rund 3,5 Millionen Bankkonten verknüpft waren, darunter Namen, Adressen und IBAN-Nummern. Die Behörden berichteten, dass der Angreifer ein bestehendes Beamtenkonto missbrauchte, anstatt eine Software-Schwachstelle auszunutzen.

Warum es wichtig ist: Der Vorfall verdeutlicht, dass kompromittierte Zugangsdaten selbst in Regierungssystemen eine große Bedrohung bleiben. Starke Identitätskontrollen sind genauso wichtig wie Infrastruktursicherheit. Da die NIS2-Durchsetzung in Europa ausgeweitet wird, zeigen Vorfälle wie dieser, warum Identitätssicherheit zu einem Compliance-Thema auf Vorstandsebene wird.

Quelle: Shattered.io – 23. Juni 2026

ShinyHunters beansprucht 200 GB Diebstahl aus HR- und Gehaltsabrechnungssystemen des Europarats

Die Gruppe ShinyHunters übernahm die Verantwortung für den Einbruch in interne Systeme des Europarats und den Diebstahl von mehr als 200 GB an HR- und Gehaltsabrechnungsinformationen. Die Organisation bestätigte einen Cybersicherheitsvorfall, schränkte den Zugriff auf betroffene Systeme ein und leitete eine forensische Untersuchung ein. Zum Zeitpunkt der Veröffentlichung war das volle Ausmaß der Kompromittierung noch nicht bestätigt.

Warum es wichtig ist: Obwohl die Zuschreibung noch untersucht wird, folgt der Vorfall einem wachsenden Muster von Angriffen auf öffentliche Institutionen unter Verwendung gestohlener Zugangsdaten oder Phishing. Europäische Organisationen sollten erwarten, dass Angreifer weiterhin Identitätssysteme und nicht nur die Infrastruktur angreifen. Starke Zugangskontrollen und schnelle Incident Response bleiben sowohl für den öffentlichen als auch für den privaten Sektor unerlässlich.

Quelle: CyPro – 26. Juni 2026

Tschechisches Unternehmen Wultra sammelt 3,5 Mio. € für Post-Quantum-, Phishing-resistente Authentifizierung für europäische Banken

Das tschechische Cybersicherheitsunternehmen Wultra kündigte eine 3,5 Millionen Euro Series-A-Finanzierungsrunde an, um seine Authentifizierungsplattform in Europa zu erweitern. Das Unternehmen entwickelt Phishing-resistente Authentifizierungstechnologien für Banken, Finanzdienstleister und Anbieter digitaler Identität. Die Investition wird die Einführung von Post-Quantum-Kryptographie und Authentifizierungsmethoden unterstützen, die kommende europäische Vorschriften erfüllen sollen, darunter PSD3, PSR und eIDAS 2.0.

Warum es wichtig ist: Europäische Organisationen bereiten sich nicht nur auf heutige Identitätsbedrohungen vor, sondern auch auf zukünftige kryptographische Risiken. Da Regulierungsbehörden zunehmend stärkere Standards für digitale Identität fördern, verschieben sich Investitionen in Richtung Phishing-resistenter und Post-Quantum-Authentifizierung. Die Finanzierung spiegelt die wachsende Nachfrage nach Authentifizierungstechnologien wider, die langfristige Compliance unterstützen und gleichzeitig die Abhängigkeit von Passwörtern und Legacy-MFA-Methoden reduzieren können.

Quelle: The Recursive – 29. Juni 2026

WALLIX und Inria kooperieren zur Sicherung von Maschinenidentitäten

Der europäische IAM/PAM-Anbieter WALLIX und das französische Forschungsinstitut Inria haben eine Partnerschaft zur Entwicklung vertrauenswürdiger KI-Lösungen zur Sicherung von Maschinenidentitäten angekündigt. Die Zusammenarbeit zielt darauf ab, die strukturellen Risiken anzugehen, die durch das schnelle Wachstum von nicht-menschlichen Identitäten entstehen, einschließlich API-Schlüssel, Servicekonten, Token und Zertifikate, die in automatisierten Workflows und CI/CD-Pipelines verwendet werden. 

Warum es wichtig ist: Maschinenidentitäten übersteigen bereits die Zahl menschlicher Identitäten in den meisten Unternehmensumgebungen, und ihre Anzahl wächst mit jedem neuen Microservice und jeder Deployment-Pipeline weiter. Dennoch fehlt vielen Organisationen noch immer eine zentrale Kontrolle über diese Zugangsdaten, die über Konfigurationsdateien, Umgebungsvariablen und Source-Code-Repositories verstreut bleiben. Die wachsende Aufmerksamkeit großer europäischer Cybersicherheitsakteure bestätigt, dass das Management von Maschinenidentitäten zu einer der Top-Prioritäten für die Unternehmenssicherheit wird.

Quelle: Industrial Cyber – 26. Juni 2026

Zusammenfassung dieser Woche

Drei Dinge fallen als konsistente Lücken bei den Vorfällen dieser Woche auf:

• Credential Rotation wird als Post-Breach-Aufgabe behandelt, nicht als Routine. In allen drei Fällen hätte die Rotation von Zugangsdaten vor oder unmittelbar nach der initialen Kompromittierung den Schaden begrenzt.
• Der SaaS-Zugriff von Drittanbietern ist weitgehend ungeprüft. Der LastPass-Breach erfolgte über eine Marktforschungsplattform mit OAuth-Zugriff auf Salesforce. Die meisten Sicherheitsteams könnten nicht auf Anhieb jede OAuth-Integration in ihrer Umgebung auflisten.
• Maschinenidentitäten bleiben die am wenigsten kontrollierte Zugangsdatenklasse. Die WALLIX/Inria-Ankündigung und der Cisco-Fall weisen auf dieselbe Lücke hin: API-Schlüssel, Servicekonten und Token in Pipelines, die niemand aktiv überwacht.

Die guten Nachrichten von Operation Endgame sind real: Die Abschaltung der Amadey- und StealC-Infrastruktur ist bedeutsam. Aber Millionen von zuvor gestohlenen Zugangsdaten sind für Angreifer noch immer verfügbar.

Effektives Zugriffsmanagement begrenzt den Wert gestohlener Zugangsdaten, selbst nachdem der ursprüngliche Angriff vorbei ist. Passwork vereint Passwort- und Secrets-Management in einer einzigen Plattform — mit einer REST API, Python SDK und CLI für Teams, die eine zentrale Kontrolle über Maschinen-Zugangsdaten ohne den Overhead traditioneller PAM-Lösungen benötigen. Kontrollieren Sie Ihre Zugangsdaten, bevor Angreifer es tun.

Shadow IT in 2026: Risiken, Erkennung und Management

Shadow IT in 2026 umfasst KI-Agenten, verwaiste SaaS-Konten und unüberwachte LLM-Sitzungen — Risiken, die die meisten Organisationen nicht sehen können. Erfahren Sie, was sich geändert hat, was es kostet und wie ein 6-Schritte-Governance-Framework die Lücke schließt.

Passwork BlogAlex Muntyan

Secrets-Rotation-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 Zuständigkeit bis zur sicheren Rotation, Notfall-Widerruf und Audit-Nachweisen.

Passwork BlogAlex Muntyan

Leitfaden zur Supply-Chain-Sicherheit: Lieferantenrisiken, Vorschriften, Zugangskontrolle in 2026

48 % der Breaches betreffen mittlerweile einen Drittanbieter. Dieser Leitfaden behandelt die Angriffsmuster hinter SolarWinds, MOVEit und XZ Utils — sowie die Zugangskontrollen, Credential-Management-Praktiken und regulatorischen Anforderungen, die sie tatsächlich stoppen.

Passwork BlogAlex Muntyan

Los incidentes de esta semana comparten un hilo conductor: credenciales robadas hace semanas o meses siguen abriendo puertas. Parchear la vulnerabilidad que permitió el robo no invalida lo que ya fue sustraído. Tres casos de esta semana ilustran este punto de diferentes maneras:

• FortiBleed confirmó que más de 15.000 credenciales verificadas de administradores y VPN de Fortinet (recopiladas de archivos de configuración de firewalls en más de 100 países) ya están en circulación. El mensaje de CISA fue inequívoco: la rotación de credenciales no es opcional después de un compromiso, y las actualizaciones de software por sí solas no cierran la ventana.
• Operation Endgame desmanteló la infraestructura detrás de Amadey y StealC, dos de las familias de infostealers más activas. Europol recuperó alrededor de 27 millones de credenciales robadas y confiscó cientos de servidores. La infraestructura está caída; las credenciales que ya estaban en circulación no lo están.
• La brecha de FICOBA en Francia no requirió ningún exploit. Un atacante utilizó una única cuenta comprometida de un funcionario público para consultar 3,5 millones de registros bancarios durante dos semanas: ninguna vulnerabilidad de software, solo una credencial no monitoreada que permaneció activa.

La semana también trajo una brecha en la cadena de suministro de LastPass a través de una plataforma SaaS de terceros, un zero-day de Cisco SD-WAN explotado activamente que dio a los atacantes acceso root y cuentas de administrador ocultas durante más de dos meses, y una supuesta exfiltración de 200 GB del Consejo de Europa reclamada por ShinyHunters. 

En el ámbito industrial, la empresa checa Wultra recaudó 3,5 millones de euros para autenticación post-cuántica, y WALLIX se asoció con Inria para abordar el creciente problema de las identidades de máquinas: claves API, tokens y cuentas de servicio que la mayoría de las organizaciones todavía no pueden inventariar completamente.

Este resumen cubre 8 eventos significativos del 22 al 29 de junio de 2026.

FortiBleed: más de 15.000 credenciales de administrador de Fortinet robadas en más de 100 países, CISA exige rotación inmediata

Investigadores de seguridad descubrieron una campaña de recolección de credenciales a gran escala denominada FortiBleed, que expuso más de 15.000 credenciales verificadas de administrador y SSL VPN de firewalls FortiGate de Fortinet en más de 100 países. Las credenciales, recopiladas durante varios años a través de archivos de configuración de firewalls comprometidos, se han vinculado a organizaciones como Siemens, DHL y un contratista de defensa turco. 

Por qué es importante: FortiBleed destaca una distinción crítica: parchear una vulnerabilidad no elimina el riesgo una vez que las credenciales ya han sido robadas. Tras la divulgación, CISA instó a las organizaciones a actuar de inmediato:

• Terminar sesiones y restablecer credenciales. Finalice todas las sesiones activas de SSL VPN y administración. Restablezca todas las contraseñas de VPN y administrador de Fortinet, especialmente en sistemas expuestos a internet.
• Garantizar el almacenamiento seguro de credenciales. Confirme el uso de PBKDF2 para almacenar credenciales de administrador y elimine los hashes heredados más débiles según las directrices de Fortinet.
• Revisar registros. Verifique los registros de firewall, VPN, autenticación y controlador de dominio en busca de movimiento lateral, cuentas sospechosas o cambios de configuración no autorizados.
• Habilitar MFA resistente al phishing. Exija MFA resistente al phishing en todas las cuentas de acceso remoto y administración, incluyendo todas las puertas de enlace externas e interfaces administrativas.
• Reducir la superficie de ataque y restringir el acceso de gestión. Mantenga la administración del firewall fuera de internet público, restrinja las interfaces de gestión a redes internas de confianza y deshabilite las cuentas innecesarias.

Fuentes: Dark Reading – 23 jun 2026

Datos de soporte al cliente de LastPass robados a través de la brecha en la cadena de suministro de Klue

LastPass notificó a los usuarios que se robaron datos de soporte al cliente y ventas después de que los atacantes comprometieran Klue, una plataforma de investigación de mercado de terceros. Según los informes, el grupo de extorsión Icarus abusó de tokens OAuth para acceder a datos de Salesforce de alrededor de 20 empresas de ciberseguridad, incluyendo LastPass, HackerOne y Recorded Future. LastPass declaró que las bóvedas de contraseñas no se vieron afectadas, pero los datos robados incluían nombres de clientes, números de teléfono, direcciones de correo electrónico y físicas, detalles de casos de soporte y registros de ventas. 

Por qué es importante: El incidente muestra cómo las integraciones SaaS pueden exponer datos sensibles de clientes incluso cuando los sistemas principales permanecen seguros. Para las empresas, el incidente refuerza la necesidad de evaluar el acceso SaaS de terceros, restringir los permisos OAuth, monitorear la actividad de integración y tratar la gobernanza de proveedores como parte de la seguridad de identidad. Bajo marcos como NIS2, el riesgo de proveedores y el control de acceso se están convirtiendo en preocupaciones de seguridad a nivel de dirección.

Fuentes: TechCrunch – 23 jun 2026

Operation Endgame: Europol confisca cientos de servidores y recupera 27 millones de credenciales robadas de las redes Amadey y StealC

Una operación policial internacional liderada por Europol desmanteló la infraestructura detrás de las familias de malware Amadey y StealC, dos de las plataformas de robo de credenciales más activas. Las autoridades confiscaron cientos de servidores y dominios, congelaron criptomonedas vinculadas a los operadores y recuperaron alrededor de 27 millones de credenciales robadas. La operación involucró a varios países europeos, incluyendo Alemania, Francia, Países Bajos y Reino Unido. Microsoft estimó que estas familias de malware infectaron cientos de miles de dispositivos en todo el mundo durante las campañas recientes.

Por qué es importante: Esta es una de las mayores disrupciones recientes del ecosistema de infostealers. Sin embargo, las organizaciones no deben asumir que el riesgo ha desaparecido. Millones de contraseñas y tokens de sesión robados ya están circulando en mercados criminales y seguirán alimentando ataques de apropiación de cuentas. 

Fuente: The Hacker News / Europol – 24 jun 2026

Zero-day de Cisco SD-WAN explotado durante más de 2 meses: los atacantes obtuvieron acceso root y crearon cuentas de administrador ocultas

Cisco reveló que los atacantes habían estado explotando una vulnerabilidad zero-day en Catalyst SD-WAN Manager durante al menos dos meses antes de la divulgación. Según Mandiant, los atacantes obtuvieron privilegios root, modificaron credenciales de administrador, crearon cuentas privilegiadas ocultas y eliminaron evidencia forense para mantener persistencia a largo plazo. Cisco también publicó información sobre una vulnerabilidad relacionada de elusión de autenticación que afecta a la misma plataforma.

Por qué es importante: Muchas organizaciones tratan los dispositivos de red como infraestructura de confianza, sin embargo, estos dispositivos a menudo contienen credenciales altamente privilegiadas. Una vez comprometidos, proporcionan a los atacantes acceso administrativo persistente a través de la red. El parcheo debe ir acompañado de monitoreo continuo de identidades privilegiadas.

Fuente: The Hacker News / Google Mandiant – 25 jun 2026

Credenciales gubernamentales comprometidas exponen 3,5 millones de cuentas bancarias en la brecha del registro FICOBA en Francia

Las autoridades francesas revelaron que los atacantes utilizaron credenciales gubernamentales comprometidas para acceder a FICOBA, el registro nacional de cuentas bancarias del país. Durante un período de aproximadamente dos semanas, los atacantes visualizaron información vinculada a alrededor de 3,5 millones de cuentas bancarias, incluyendo nombres, direcciones y números IBAN. Las autoridades informaron que el atacante abusó de una cuenta existente de un funcionario público en lugar de explotar una vulnerabilidad de software.

Por qué es importante: El incidente destaca que las credenciales comprometidas siguen siendo una amenaza importante incluso en sistemas gubernamentales. Los controles de identidad sólidos son tan importantes como la seguridad de la infraestructura. A medida que la aplicación de NIS2 se expande por Europa, incidentes como este muestran por qué la seguridad de identidad se está convirtiendo en un tema de cumplimiento a nivel de dirección.

Fuente: Shattered.io – 23 jun 2026

ShinyHunters afirma haber robado 200 GB de los sistemas de RRHH y nóminas del Consejo de Europa

El grupo ShinyHunters se atribuyó la responsabilidad de vulnerar los sistemas internos del Consejo de Europa y robar más de 200 GB de información de RRHH y nóminas. La organización confirmó un incidente de ciberseguridad, restringió el acceso a los sistemas afectados e inició una investigación forense. Al momento de la publicación, no se había confirmado el alcance completo del compromiso.

Por qué es importante: Aunque la atribución sigue bajo investigación, el incidente sigue un patrón creciente de ataques contra instituciones públicas utilizando credenciales robadas o phishing. Las organizaciones europeas deben esperar que los atacantes continúen atacando sistemas de identidad en lugar de solo la infraestructura. Los controles de acceso sólidos y la respuesta rápida a incidentes siguen siendo esenciales tanto para el sector público como para el privado.

Fuente: CyPro – 26 jun 2026

La empresa checa Wultra recauda 3,5 millones de euros para desarrollar autenticación post-cuántica resistente al phishing para bancos europeos

La empresa checa de ciberseguridad Wultra anunció una ronda de financiación Serie A de 3,5 millones de euros para expandir su plataforma de autenticación por toda Europa. La empresa desarrolla tecnologías de autenticación resistentes al phishing para bancos, servicios financieros y proveedores de identidad digital. La inversión apoyará la adopción de criptografía post-cuántica y métodos de autenticación diseñados para cumplir con las próximas regulaciones europeas, incluyendo PSD3, PSR y eIDAS 2.0.

Por qué es importante: Las organizaciones europeas se están preparando no solo para las amenazas de identidad actuales, sino también para los riesgos criptográficos futuros. A medida que los reguladores promueven cada vez más estándares de identidad digital más sólidos, las inversiones se están desplazando hacia la autenticación resistente al phishing y post-cuántica. La financiación refleja una demanda creciente de tecnologías de autenticación que puedan respaldar el cumplimiento a largo plazo mientras reducen la dependencia de las contraseñas y los métodos MFA heredados.

Fuente: The Recursive – 29 jun 2026

WALLIX e Inria se asocian para proteger las identidades de máquinas

El proveedor europeo de IAM/PAM WALLIX y el instituto de investigación francés Inria han anunciado una asociación para desarrollar soluciones de IA de confianza para proteger las identidades de máquinas. La colaboración tiene como objetivo abordar los riesgos estructurales creados por el rápido crecimiento de las identidades no humanas, incluyendo claves API, cuentas de servicio, tokens y certificados utilizados en flujos de trabajo automatizados y pipelines CI/CD. 

Por qué es importante: Las identidades de máquinas ya superan en número a las identidades humanas en la mayoría de los entornos empresariales, y sus números continúan creciendo con cada nuevo microservicio y pipeline de despliegue. Sin embargo, muchas organizaciones todavía carecen de control centralizado sobre estas credenciales, que permanecen dispersas en archivos de configuración, variables de entorno y repositorios de código fuente. La creciente atención de los principales actores europeos de ciberseguridad confirma que la gestión de identidades de máquinas se está convirtiendo en una de las principales prioridades para la seguridad empresarial.

Fuente: Industrial Cyber – 26 jun 2026

Resumen de esta semana

Tres aspectos destacan como brechas consistentes en los incidentes de esta semana:

• La rotación de credenciales se trata como una tarea posterior a la brecha, no como una rutina. En los tres casos, rotar las credenciales antes o inmediatamente después del compromiso inicial habría contenido el daño.
• El acceso SaaS de terceros está en gran medida sin auditar. La brecha de LastPass llegó a través de una plataforma de investigación de mercado con acceso OAuth a Salesforce. La mayoría de los equipos de seguridad no podrían enumerar cada integración OAuth en su entorno en este momento.
• Las identidades de máquinas siguen siendo la clase de credenciales menos gobernada. El anuncio de WALLIX/Inria y el caso de Cisco apuntan a la misma brecha: claves API, cuentas de servicio y tokens en pipelines que nadie está monitoreando activamente.

Las buenas noticias de Operation Endgame son reales: desmantelar la infraestructura de Amadey y StealC importa. Pero millones de credenciales robadas previamente todavía están disponibles para los atacantes.

La gestión de acceso eficaz limita el valor de las credenciales robadas, incluso después de que el ataque original haya terminado. Passwork reúne la gestión de contraseñas y secretos en una única plataforma — con REST API, Python SDK y CLI para equipos que necesitan control centralizado sobre las credenciales de máquinas sin la sobrecarga del PAM tradicional. Controle sus credenciales antes de que lo hagan los atacantes.

Shadow IT en 2026: Riesgos, detección y cómo gestionarlo

El Shadow IT en 2026 abarca agentes de IA, cuentas SaaS huérfanas y sesiones LLM no monitoreadas — riesgos que la mayoría de las organizaciones no pueden ver. Descubra qué ha cambiado, cuánto cuesta y cómo un marco de gobernanza de 6 pasos cierra la brecha.

Passwork BlogAlex Muntyan

Ciclo de vida de la rotación de secretos: De la creación a 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 la propiedad hasta la rotación segura, la revocación de emergencia y la evidencia de auditoría.

Passwork BlogAlex Muntyan

Guía de seguridad de la cadena de suministro: Riesgos de proveedores, regulaciones y control de acceso en 2026

El 48% de las brechas ahora involucran a un tercero. Esta guía cubre los patrones de ataque detrás de SolarWinds, MOVEit y XZ Utils — y los controles de acceso, prácticas de gestión de credenciales y requisitos regulatorios que realmente los detienen.

Passwork BlogAlex Muntyan

This week's incidents share a single thread: credentials stolen weeks or months ago are still opening doors. Patching the vulnerability that enabled the theft doesn't invalidate what was already taken. Three cases from this week make that point in different ways:

• FortiBleed confirmed that over 15,000 verified Fortinet admin and VPN credentials (collected from firewall config files across 100+ countries) are already in circulation. CISA's message was unambiguous: rotating credentials is not optional after a compromise, and software updates alone don't close the window.
• Operation Endgame disrupted the infrastructure behind Amadey and StealC, two of the most active infostealer families. Europol recovered around 27 million stolen credentials and seized hundreds of servers. The infrastructure is down; the credentials already in circulation are not.
• France's FICOBA breach required no exploit at all. An attacker used a single compromised civil servant account to browse 3.5 million bank records over two weeks: no software vulnerability, just an unmonitored credential left active.

The week also brought a supply chain breach at LastPass through a third-party SaaS platform, an actively exploited Cisco SD-WAN zero-day that gave attackers root access and hidden admin accounts for over two months, and a suspected 200 GB exfiltration from the Council of Europe claimed by ShinyHunters. 

On the industry side, Czech firm Wultra raised €3.5M for post-quantum authentication, and WALLIX partnered with Inria to address the growing machine identity problem: API keys, tokens, and service accounts that most organizations still can't fully inventory.

This digest covers 8 significant events from 22 to 29 June 2026.

FortiBleed: 15,000+ Fortinet admin credentials stolen across 100+ countries, CISA demands immediate rotation

Security researchers uncovered a large-scale credential harvesting campaign dubbed FortiBleed, which exposed more than 15,000 verified administrator and SSL VPN credentials for Fortinet FortiGate firewalls across 100+ countries. The credentials, collected over several years through compromised firewall configuration files, have been linked to organizations including Siemens, DHL, and a Turkish defense contractor. 

Why it matters: FortiBleed highlights a critical distinction: patching a vulnerability does not eliminate the risk once credentials have already been stolen. Following the disclosure, CISA urged organizations to act immediately:

• Terminate sessions and reset credentials. End all active SSL VPN and admin sessions. Reset all Fortinet VPN and admin passwords, especially on internet-facing systems.
• Ensure secure credential storage. Confirm use of PBKDF2 for storing administrator credentials and remove weaker legacy hashes per Fortinet's guidance.
• Review logs. Check firewall, VPN, authentication, and domain controller logs for lateral movement, suspicious accounts, or unauthorized configuration changes.
• Enable phishing-resistant MFA. Require phishing-resistant MFA on all remote access and admin accounts, including all external gateways and administrative interfaces.
• Reduce the attack surface and lock down management access. Keep firewall administration off the public internet, restrict management interfaces to trusted internal networks, and disable unnecessary accounts.

Sources: Dark Reading – 23 Jun 2026

LastPass customer support data stolen through Klue supply chain breach

LastPass notified users that customer support and sales data was stolen after attackers compromised Klue, a third-party market research platform. The extortion group Icarus reportedly abused OAuth tokens to access Salesforce data from around 20 cybersecurity companies, including LastPass, HackerOne, and Recorded Future. LastPass said password vaults were not affected, but the stolen data included customer names, phone numbers, email and physical addresses, support case details, and sales records. 

Why it matters: The incident shows how SaaS integrations can expose sensitive customer data even when core systems remain secure. For enterprises, the incident reinforces the need to assess third-party SaaS access, restrict OAuth permissions, monitor integration activity, and treat supplier governance as part of identity security. Under frameworks like NIS2, vendor risk and access control are becoming board-level security concerns.

Sources: TechCrunch – 23 Jun 2026

Operation Endgame: Europol seizes hundreds of servers, recovers 27 million stolen credentials from Amadey and StealC networks

An international law enforcement operation led by Europol disrupted the infrastructure behind the Amadey and StealC malware families, two of the most active credential-stealing platforms. Authorities seized hundreds of servers and domains, froze cryptocurrency linked to the operators, and recovered around 27 million stolen credentials. The operation involved several European countries, including Germany, France, the Netherlands and the UK. Microsoft estimated that these malware families infected hundreds of thousands of devices worldwide during recent campaigns.

Why it matters: This is one of the largest recent disruptions of the infostealer ecosystem. However, organizations should not assume the risk has disappeared. Millions of stolen passwords and session tokens are already circulating in criminal markets and will continue to fuel account takeover attacks. 

Source: The Hacker News / Europol – 24 Jun 2026

Cisco SD-WAN zero-day exploited for 2+ months: attackers gained root access and created hidden admin accounts

Cisco disclosed that attackers had been exploiting a zero-day vulnerability in Catalyst SD-WAN Manager for at least two months before disclosure. According to Mandiant, attackers obtained root privileges, modified administrator credentials, created hidden privileged accounts and removed forensic evidence to maintain long-term persistence. Cisco also released information about a related authentication bypass vulnerability affecting the same platform.

Why it matters: Many organizations treat network appliances as trusted infrastructure, yet these devices often hold highly privileged credentials. Once compromised, they provide attackers with persistent administrative access across the network. Patching should be paired with continuous monitoring of privileged identities.

Source: The Hacker News / Google Mandiant – 25 Jun 2026

Compromised government credentials expose 3.5 million bank accounts in French FICOBA registry breach

French authorities disclosed that attackers used compromised government credentials to access FICOBA, the country's national bank account registry. Over a period of approximately two weeks, attackers viewed information linked to around 3.5 million bank accounts, including names, addresses and IBAN numbers. Authorities reported that the attacker abused an existing civil servant account rather than exploiting a software vulnerability.

Why it matters: The incident highlights that compromised credentials remain a major threat even in government systems. Strong identity controls are just as important as infrastructure security. As NIS2 enforcement expands across Europe, incidents like this show why identity security is becoming a board-level compliance issue.

Source: Shattered.io – 23 Jun 2026

ShinyHunters claims 200 GB stolen from Council of Europe HR and payroll systems

The ShinyHunters group claimed responsibility for breaching internal systems belonging to the Council of Europe and stealing more than 200 GB of HR and payroll information. The organization confirmed a cybersecurity incident, restricted access to affected systems and launched a forensic investigation. At the time of publication, the full scope of the compromise had not been confirmed.

Why it matters: Although attribution remains under investigation, the incident follows a growing pattern of attacks against public institutions using stolen credentials or phishing. European organizations should expect attackers to continue targeting identity systems rather than infrastructure alone. Strong access controls and rapid incident response remain essential for both public and private sectors.

Source: CyPro – 26 Jun 2026

Czech firm Wultra raises €3.5M to build post-quantum, phishing-resistant authentication for European banks

Czech cybersecurity company Wultra announced a €3.5 million Series A funding round to expand its authentication platform across Europe. The company develops phishing-resistant authentication technologies for banks, financial services and digital identity providers. The investment will support the adoption of post-quantum cryptography and authentication methods designed to meet upcoming European regulations, including PSD3, PSR and eIDAS 2.0.

Why it matters: European organizations are preparing not only for today's identity threats but also for future cryptographic risks. As regulators increasingly promote stronger digital identity standards, investments are shifting toward phishing-resistant and post-quantum authentication. The funding reflects growing demand for authentication technologies that can support long-term compliance while reducing dependence on passwords and legacy MFA methods.

Source: The Recursive – 29 Jun 2026

WALLIX and Inria partner to secure machine identities

European IAM/PAM vendor WALLIX and the French research institute Inria have announced a partnership to develop trusted AI solutions for securing machine identities. The collaboration aims to address the structural risks created by the rapid growth of non-human identities, including API keys, service accounts, tokens, and certificates used in automated workflows and CI/CD pipelines. 

Why it matters: Machine identities already outnumber human identities in most enterprise environments, and their numbers continue to grow with every new microservice and deployment pipeline. Yet many organizations still lack centralized control over these credentials, which remain scattered across configuration files, environment variables, and source code repositories. The growing attention from major European cybersecurity players confirms that machine identity management is becoming one of the top priorities for enterprise security.

Source: Industrial Cyber – 26 Jun 2026

This week's recap

Three things stand out as consistent gaps across this week's incidents:

• Credential rotation is treated as a post-breach task, not a routine one. In all three cases, rotating credentials before or immediately after the initial compromise would have contained the damage.
• Third-party SaaS access is largely unaudited. The LastPass breach came through a market research platform with OAuth access to Salesforce. Most security teams couldn't list every OAuth integration in their environment right now.
• Machine identities remain the least-governed credential class. The WALLIX/Inria announcement and the Cisco case both point to the same gap: API keys, service accounts, and tokens in pipelines that no one is actively monitoring.

The good news from Operation Endgame is real: taking down Amadey and StealC infrastructure matters. But millions of previously stolen credentials are still available to attackers.

Effective access management limits the value of stolen credentials, even after the original attack is over. Passwork brings password and secrets management into a single platform — with a REST API, Python SDK, and CLI for teams that need centralized control over machine credentials without the overhead of traditional PAM. Control your credentials before attackers do.

Shadow IT in 2026: Risks, detection, and how to manage it

Shadow IT in 2026 spans AI agents, orphaned SaaS accounts, and unmonitored LLM sessions — risks most organizations can’t see. Learn what’s changed, what it costs, and how a 6-step governance framework closes the gap.

Passwork BlogAlex Muntyan

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

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

Jahrzehntelang lautete die Antwort auf „Wie erstelle ich ein starkes Passwort?": Fügen Sie einen Großbuchstaben hinzu, setzen Sie ein Symbol ans Ende, hängen Sie eine Zahl an. Das Problem ist, dass Menschen unter Regeln vorhersehbar sind. Der Großbuchstabe steht am Anfang. Symbol und Zahl stehen am Ende. Cracking-Tools wissen das, weil sie mit Milliarden echter Passwörter von Menschen trainiert wurden, die genau demselben Instinkt folgten.

Sowohl das menschliche Gedächtnis als auch Cracking-Algorithmen arbeiten mit Mustern. Das ist der Konflikt, und er verschwindet nicht, indem Sie @ an den Namen Ihres Hundes anhängen. Dieser Leitfaden erklärt die Mechanismen, die einzige Ausnahme und wie ein nachhaltiges Zugangsdatensystem tatsächlich aussieht.

Wichtigste Erkenntnisse

• Je einfacher ein Passwort zu merken ist, desto einfacher ist es zu knacken. Merkbarkeit und Sicherheit ziehen in entgegengesetzte Richtungen. Diese Spannung ist strukturell bedingt: Sie ergibt sich aus der Funktionsweise des menschlichen Gedächtnisses.
• Symbolersetzungen und Komplexitätsregeln erhöhen die Sicherheit nicht wesentlich. Moderne Passwort-Cracking-Algorithmen sind speziell auf diese vorhersehbaren menschlichen Muster trainiert, sodass Angreifer sie mit optimierten Brute-Force-Angriffen umgehen können.
• Die aktuellen NIST SP 800-63B-Richtlinien streichen offiziell verpflichtende Komplexitätsregeln und 90-Tage-Rotationen und legen ein neues empfohlenes Minimum von 15 Zeichen fest.
• Der einzige Passworttyp, der sowohl merkbar als auch kryptografisch stark ist, ist eine Diceware-Passphrase: zufällige Wörter, die durch Würfel gewählt werden, nicht von Ihnen.
• Sie müssen sich genau ein Passwort merken: die Master-Passphrase, die Ihren Passwort-Manager entsperrt. Alle anderen Zugangsdaten sollten zufällig generiert und im Tresor gespeichert werden.

Was ist ein starkes Passwort

Ein starkes Passwort ist ein Zugangsdatum, das sowohl automatisierten Rateversuchen als auch gezielten Angriffen standhält. NIST SP 800-63B legt das Minimum auf 8 Zeichen fest, empfiehlt Systemen, bis zu 64 Zeichen zu akzeptieren, und streicht verpflichtende Komplexitätsregeln vollständig zugunsten von Länge und Einzigartigkeit. Der praktische Arbeitsstandard für die meisten Sicherheitsteams liegt bei 12-16 zufällig generierten Zeichen mit einer Entropie über 75 Bit.

Vier Parameter definieren, ob ein Passwort diese Baseline erfüllt:

• Länge. Die einzelne effektivste Variable. Jedes zusätzliche Zeichen multipliziert den Suchraum exponentiell. Bei 12 Zeichen erfordert eine vollständig zufällige alphanumerische Zeichenkette Milliarden von Jahren zum Brute-Forcen bei aktuellen Hardware-Geschwindigkeiten. Bei 8 Zeichen schrumpft dieses Fenster auf Stunden.
• Zufälligkeit. Von Menschen gewählte Passwörter gruppieren sich um vorhersehbare Muster: Namen, Daten, Wörterbuchwörter mit Ersetzungen. Ein Passwortgenerator eliminiert diese Gruppierung vollständig. Wenn Sie es gewählt haben, ist es wahrscheinlich schwächer, als es aussieht.
• Einzigartigkeit. Ein Zugangsdatum pro Account. Ein einzelnes kompromittiertes Passwort gewährt Zugriff auf jedes System, in dem es vorkommt. Wiederverwendung verwandelt einen isolierten Breach in eine Gelegenheit zur lateralen Bewegung.
• Kein Ablauf ohne Grund. NIST SP 800-63B lehnt verpflichtende periodische Rotation ausdrücklich ab. Erzwungene Rotation produziert vorhersehbare Inkremente (Password1 → Password2) und trainiert Benutzer, schwächere Basispasswörter zu wählen. Ändern Sie ein Zugangsdatum, wenn es Hinweise auf eine Kompromittierung gibt.

Das Merkbarkeits-Paradoxon: Warum Ihr Gehirn eine Schwachstelle ist

Jede Eigenschaft, die ein Passwort leichter merkbar macht, macht es auch leichter zu erraten. Das menschliche Gedächtnis kodiert Informationen durch Muster, Assoziationen und Bedeutung. Ein Passwort, das in Ihrem Gedächtnis haften bleibt, tut dies, weil es mit etwas verbunden ist, das Sie bereits kennen: ein Wort, ein Datum, ein Name, eine Tastaturform. Dieselben Verbindungen sind genau das, was Cracking-Tools ausnutzen.

PassGAN (Generative Adversarial Network für Passwort-Cracking) und ähnliche Tools sind mit Milliarden geleakter Zugangsdaten trainiert. Sie probieren nicht aaaaaaa vor p@ssword. Sie probieren die Dinge, die Menschen tatsächlich wählen, in der Reihenfolge, in der Menschen sie tatsächlich wählen. Das Ersetzen von @ für a in password ergibt p@ssword, das PassGAN innerhalb der ersten paar Tausend Versuche in weniger als einem Bruchteil einer Sekunde generiert. Den ersten Buchstaben großzuschreiben und 1 am Ende hinzuzufügen, sind Muster, die das Modell millionenfach gesehen hat.

Länge und Zeichensatz sind beide wichtig, aber nicht gleich wichtig. Die Passwort-Tabelle 2025 von Hive Systems, getestet gegen 12 × RTX 5090 GPUs mit bcrypt bei Arbeitsfaktor 10, zeigt, dass ein 8-Zeichen-Passwort, das nur Kleinbuchstaben verwendet, in drei Wochen fällt. Fügen Sie Großbuchstaben, Zahlen und Symbole hinzu, und diese Zahl erreicht 164 Jahre gegen dieselbe Hardware. Ein 12-Zeichen-Passwort mit demselben vollständigen gemischten Zeichensatz bringt die Tabelle in Jahrhunderte.

Die Tabelle wird jährlich aktualisiert, um aktuelle Consumer-GPU-Hardware widerzuspiegeln. Die Verschiebung von der Ausgabe 2024 zu 2025 spiegelt sowohl schnellere Hardware als auch realistischere Hash-Stärke-Annahmen wider, die aus dem gewonnen wurden, was Hive Systems in tatsächlichen Breach-Daten beobachtete.

Warum traditionelle Passwort-Ratschläge tot sind

Die alten Komplexitätsregeln (acht Zeichen, ein Großbuchstabe, eine Zahl, ein Symbol) scheiterten, weil sie sich bezüglich des menschlichen Verhaltens unter Einschränkungen irrten. Während das Merkbarkeits-Paradoxon ein kognitives Versagen beschreibt, produzierten verpflichtende Komplexitätsregeln ein Richtlinienversagen zusätzlich dazu.

Jahrelang war der dominierende Cracking-Ansatz der Wörterbuchangriff: automatisierte Tools, die bekannte Wörter und gängige Ersetzungen durchgingen. Sicherheitsteams reagierten mit verpflichtender Komplexität. Das Problem ist, dass Menschen unter Komplexitätsdruck vorhersehbar sind. Wenn sie aufgefordert werden, ein Symbol hinzuzufügen, fügen die meisten Menschen es am Ende hinzu. Wenn sie aufgefordert werden, einen Buchstaben zu ersetzen, wählen die meisten dieselben Ersetzungen. Die Regeln, die darauf ausgelegt waren, die Unvorhersehbarkeit zu erhöhen, produzierten eine neue Schicht vorhersehbaren Verhaltens.

Das andere Versagen alter Ratschläge war die 90-Tage-Rotationsrichtlinie. Erzwungene Zurücksetzungen produzieren Summer2025! gefolgt von Fall2025!. Der DBIR 2026 von Verizon, der über 22.000 bestätigte Breaches in 145 Ländern analysierte, stellte fest, dass die Ausnutzung von Schwachstellen den Diebstahl von Zugangsdaten als primären Breach-Einstiegspunkt überholt hat (31 %). Zugangsdaten-Missbrauch liegt bei 13 % als initialer Zugangsvektor, aber diese Zahl betrachtet nur die erste Aktion. Der DBIR stellte fest, dass Zugangsdaten-Missbrauch in 39 % aller Breaches auftaucht, wenn er über die gesamte Angriffskette gemessen wird — damit ist er die am weitesten verbreitete Technik im Datensatz.

Länge ist die primäre Verteidigung. Eine 15-Zeichen-Passphrase aus zufälligen Wörtern ist um Größenordnungen stärker als eine 8-Zeichen-Zeichenkette aus Symbolen, und ein Mensch kann sie tatsächlich behalten.

Der neue Standard: NIST SP 800-63B Rev. 4 Richtlinien

NIST SP 800-63B Rev. 4 (2025) legt die aktuelle Baseline für Passwortsicherheit fest. Wenn ein Passwort der einzige Authentifizierungsfaktor ist, müssen Systeme ein Minimum von 8 Zeichen verlangen und sollten mindestens 15 Zeichen verlangen. Verpflichtende Komplexitätsregeln (erzwungene Symbole, Zahlen, Groß-/Kleinschreibung) werden ausdrücklich gestrichen, ebenso der 90-Tage-Ablaufzyklus. Die Überprüfung neuer Passwörter gegen bekannte Breach-Zugangsdatenlisten ist jetzt erforderlich, nicht optional.

Die vollständige Richtlinienänderung sieht so aus:

Die Logik hinter dem Streichen der Komplexität ist gut dokumentiert. NISTs eigene Forschung ergab, dass Komplexitätsanforderungen Benutzer zu vorhersehbaren Mustern drängen und die Supportkosten erhöhen, ohne die Widerstandsfähigkeit gegen automatisierte Angriffe wesentlich zu verbessern. Länge hat eine direkte mathematische Beziehung zur Cracking-Schwierigkeit: Jedes zusätzliche Zeichen multipliziert den Suchraum exponentiell.

Für IT-Administratoren ist die praktische Implikation klar: Aktualisieren Sie Ihre Passwortrichtlinien, um 15+ Zeichen zu verlangen, entfernen Sie willkürliche Komplexitätsvorgaben und implementieren Sie Prüfungen gegen bekannte Breach-Passwortlisten wie den Have I Been Pwned-Datensatz, auf den NIST ausdrücklich verweist. Hören Sie auf, Rotationen nach einem Kalenderplan zu erzwingen.

Passwörter vs. Passphrasen

Eine Passphrase ist eine Sequenz zufälliger, nicht zusammenhängender Wörter, die als einzelnes Zugangsdatum verwendet wird. Wörter sind leichter zu behalten als zufällige Zeichen, und allein die Länge treibt die Entropie weit über das hinaus, was die meisten zeichenbasierten Passwörter erreichen. Vier Wörter übertreffen bereits eine typische 10-Zeichen-Zeichenkette mit Groß-/Kleinschreibung.

Passwort-Entropie misst, wie unvorhersehbar ein Zugangsdatum ist, ausgedrückt in Bit. Höhere Entropie bedeutet mehr mögliche Kombinationen, die ein Angreifer ausprobieren muss.

Tr0ub4dor&3 sieht komplex aus. Aber es ist ein Wörterbuchwort mit vorhersehbaren Ersetzungen, einem Großbuchstaben am Anfang und einem Symbol und einer Zahl am Ende — ein Muster, das Cracking-Tools explizit modellieren. Seine effektive Entropie ist weit niedriger, als es erscheint.

correct horse battery staple illustriert die Mathematik direkt. Vier zufällig aus dieser Liste gewählte Wörter ergeben ungefähr 44 Bit Entropie (log₂ von 2.000⁴). Sechs zufällige Wörter aus der Diceware-Liste (7.776 Wörter) erzeugen etwa 77 Bit — genug, um Brute-Force-Angriffen bei aktuellen Rechengeschwindigkeiten jahrzehntelang zu widerstehen.

Das kritische Wort ist zufällig. „Ich liebe meinen Hund Keks" ist eine Passphrase, aber sie ist nicht zufällig. Sie spiegelt persönliche Informationen und eine natürliche Satzstruktur wider, die Cracking-Tools modellieren können. Eine Passphrase, die Sie erfunden haben, ist nicht zufällig, weil Sie sie erfunden haben. Echte Zufälligkeit erfordert eine Methode, die die menschliche Wahl vollständig aus der Gleichung entfernt.

So erstellen Sie ein starkes Passwort, das Sie nicht vergessen

Die folgenden Techniken lösen ein spezifisches Problem: wie man eine einzelne Master-Passphrase erstellt und sich merkt. Diese Passphrase hat eine Aufgabe — Ihren Passwort-Manager zu entsperren. Für alle anderen Zugangsdaten, die Sie besitzen, ist die Antwort ein zufällig generiertes Passwort, das in diesem Manager gespeichert wird, keine Passphrase, die Sie konstruiert und auswendig gelernt haben.

Die Diceware-Methode

Die Diceware-Methode generiert kryptografisch zufällige Passphrasen unter Verwendung physischer Würfel und einer standardisierten Wortliste. Da die Zufälligkeit von Würfelwürfen stammt und nicht von menschlicher Wahl, hat die resultierende Passphrase nachweisbare Entropie und umgeht das Merkbarkeits-Paradoxon vollständig.

1. Laden Sie die EFF Large Wordlist herunter, die 7.776 Wörter enthält, die durch fünfstellige Würfelcodes indiziert sind (z. B. 16132 = cleft).
2. Würfeln Sie fünf sechsseitige Würfel (oder einen Würfel fünfmal). Notieren Sie das Ergebnis, zum Beispiel 2-4-1-3-6.
3. Suchen Sie das entsprechende Wort in der EFF-Liste. 24136 entspricht dragster.
4. Wiederholen Sie die Schritte 2-3 fünf weitere Male, um eine Sechs-Wort-Passphrase zu generieren.
5. Ihr Ergebnis könnte lauten: dragster cleft robin usage stomp anvil. Schreiben Sie es vorübergehend auf.

Sechs Wörter aus der EFF-Liste ergeben ungefähr 77,5 Bit Entropie. Das ist das Ziel. Fünf Wörter (64,6 Bit) sind für die meisten Anwendungsfälle akzeptabel; vier Wörter sind das absolute Minimum für ein Masterpasswort.

Keine Würfel? Verwenden Sie einen Generator

Wenn keine physischen Würfel verfügbar sind, wendet Passworks kostenloser Passphrasen-Generator dieselbe Logik in einem Browser an. Er läuft vollständig lokal — nichts wird gespeichert oder übertragen. Sie können die Wortanzahl, Trennzeichen und Großschreibung an Ihre Anforderungen anpassen. Die Ausgabe ist dasselbe nachweisbar zufällige Ergebnis wie bei Diceware, ohne das Nachschlagen in der Wortliste.

Die Satz-Methode

Die Satz-Methode eignet sich besser für Personen, die schnell ein starkes Masterpasswort erstellen müssen, ohne Würfel. Nehmen Sie einen Satz, der persönlich bedeutsam, aber nicht öffentlich bekannt ist, und leiten Sie ein Passwort aus seiner Struktur ab.

• Beispielsatz: „Mein erstes Auto war ein 1998er Honda und ich fuhr damit zur Uni."
• Abgeleitetes Passwort: MeAwe1998HuifdU

Dies erzeugt eine 15-Zeichen-Zeichenkette mit Groß-/Kleinschreibung und Zahlen, die keine Wörterbuchbeziehung hat. Der Satz selbst ist die Eselsbrücke: Sie merken sich den Satz, nicht das Passwort.

Die Einschränkung: Diese Methode erzeugt weniger Entropie als Diceware, weil Menschen merkbare Sätze wählen und merkbare Sätze vorhersehbaren grammatikalischen Mustern folgen. Verwenden Sie sie nur für das Masterpasswort, wenn Diceware nicht praktikabel ist. Für alles andere verwenden Sie einen Manager.

Die Gedächtnispalast-Technik

Der Gedächtnispalast (Loci-Methode) ist eine mnemonische Technik zum Behalten der Master-Passphrase, die Sie mit Diceware generiert haben. Sie funktioniert, indem jedes Wort mit einem bestimmten physischen Ort in einem vertrauten Raum verknüpft wird: Ihr Zuhause, Ihr Arbeitsweg, ein Gebäude, das Sie gut kennen.

Um sich dragster cleft robin usage stomp anvil zu merken:

1. Wählen Sie eine vertraute Route durch einen Raum, den Sie gut kennen: Ihre Haustür, Flur, Küche, Wohnzimmer, Treppe, Schlafzimmer.
2. Ordnen Sie jedem Ort ein Wort zu. Machen Sie das Bild lebendig und ungewöhnlich: ein Dragster, der durch Ihre Haustür rast, ein Spalt (cleft) im Felsen, der Ihren Flurboden teilt, ein Rotkehlchen (robin), das auf Ihrer Küchentheke sitzt.
3. Gehen Sie die Route mehrmals gedanklich durch, der Reihe nach. Je seltsamer das Bild, desto zuverlässiger bleibt es haften.
4. Nach 24 Stunden testen Sie das Erinnern, ohne auf die geschriebene Passphrase zu schauen. Die meisten Menschen können sich nach drei oder vier gedanklichen Durchgängen an alle sechs Wörter erinnern.

Der Gedächtnispalast funktioniert, weil das Gehirn räumliche und visuelle Informationen zuverlässiger kodiert als abstrakte Zeichenketten. Sie merken sich nicht dragster cleft robin usage stomp anvil. Sie merken sich einen Gang durch Ihr Haus.

Sobald die Passphrase auswendig gelernt ist, vernichten Sie die schriftliche Kopie.

Zu wissen, wie man eine Master-Passphrase konstruiert und behält, ist eine nützliche Fähigkeit. Aber Merkbarkeit ist eine Einschränkung, und Einschränkungen erzeugen Kompromisse. Ein Passwort-Manager entfernt diese Einschränkung vollständig: Er generiert Zugangsdaten mit voller Entropie, speichert sie verschlüsselt und ruft sie ab, ohne Sie zu bitten, sich an irgendetwas außer einer Passphrase zu erinnern. Die obigen Techniken existieren, um diese eine Passphrase zu schützen. Alles andere sollte generiert, nicht erfunden werden.

Der einzige Standard: Eine Passphrase, alles andere im Passwort-Manager

Das Merkbarkeits-Paradoxon hat eine einzige strukturelle Lösung. Sie merken sich eine zufällig generierte Master-Passphrase. Ein Passwort-Manager generiert und speichert alles andere und erzeugt vollständig zufällige, einzigartige Zugangsdaten für jedes Konto, die Sie nie sehen, eingeben oder sich merken müssen. Diese Struktur gilt, ob Sie fünf Konten oder fünfhundert haben.

In der Praxis bedeutet das:

• Keine Passwortwiederverwendung über Konten hinweg — jedes Zugangsdatum ist einzigartig und zufällig generiert.
• Eine Sache zum Merken — die Master-Passphrase, die Sie mit Diceware erstellt haben.
• Keine Sicherheitsentscheidungen beim Login — der Manager übernimmt Generierung, Speicherung und Autofill.

Passwork ist für diese Architektur gebaut. Es ist als selbstgehostete Bereitstellung oder als Cloud-Service verfügbar. Beide Optionen verwenden AES-256-Client-seitige Verschlüsselung: Zugangsdaten werden verschlüsselt, bevor sie Ihr Gerät verlassen, und Passwork sieht niemals Klartext-Passwörter.

Die beiden Bereitstellungsmodelle unterscheiden sich in einer Dimension:

• Die selbstgehostete Option behält alle Daten in Ihrer eigenen Infrastruktur.
• Die Cloud-Option entfernt den operativen Aufwand des Betriebs einer eigenen Instanz, ohne das Verschlüsselungsmodell zu ändern.

Rollenbasierte Zugriffskontrolle ermöglicht es Administratoren, Tresorberechtigungen an Teams statt an Einzelpersonen zuzuweisen — relevant, wenn Sie Zugangsdaten für ein Team verwalten und nicht nur für sich selbst. Ein neuer Ingenieur erbt ab dem ersten Tag Zugriff auf die richtigen Tresore und verliert ihn in dem Moment, in dem er geht, ohne dass manuelle Bereinigung erforderlich ist.

Für Teams mit Compliance-Anforderungen bieten Passworks Audit-Logs einen vollständigen Nachweis darüber, wer wann auf welches Zugangsdatum zugegriffen hat — die Art von Dokumentation, die SOC 2 CC6.1 und ISO 27001:2022 Annex A 5.15-Kontrollen erfordern. Die technischen Anleitungen behandeln AD/LDAP-Integration, SAML SSO und REST API-Zugriff für Teams, die Zugangsdatenverwaltung in bestehende Workflows einbetten müssen.

Beispiele für starke Passwörter: Wie gute Passwörter 2026 aussehen

Die Spalte „Empfohlene Verwendung" ist der Punkt. Diceware- und satzabgeleitete Passwörter erscheinen einmal in Ihrem Leben, als Master-Zugangsdatum. Jedes andere Konto erhält ein maschinell generiertes Passwort, das Sie nie sehen, nie eingeben und nie merken müssen.

In die Praxis umsetzen

Das Merkbarkeits-Paradoxon hat keinen Workaround — es hat eine Lösung. Merken Sie sich eine Sache, zufällig generiert, mit einer Methode, die Ihr Gehirn aus dem Prozess entfernt. Verwenden Sie diese, um einen Passwort-Manager zu entsperren, der alle anderen Zugangsdaten mit maschinell generierter Zufälligkeit verwaltet, über die Sie nie nachdenken müssen.

Generieren Sie eine 6-Wort-Diceware-Passphrase. Kodieren Sie sie mit einem Gedächtnispalast. Legen Sie alles andere in einen Tresor.

Häufig gestellte Fragen

Passwortverwaltung für Teams: Die Lösung, die jedes KMU braucht

Das Speichern von Passwörtern in Slack und Browsern setzt Ihr Unternehmen Breaches 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

11 Risiken der Passwortwiederverwendung und wie Sie sie vermeiden

Ein Passwort wiederzuverwenden fühlt sich harmlos an. Ist es aber nicht. Hier erfahren Sie, warum ein geleaktes Zugangsdatum die gesamte Sicherheit Ihrer Organisation gefährden kann — und wie Sie das verhindern.

Passwork BlogAlex Muntyan

Passwort-Chaos: Warum es ein Geschäftsproblem ist und wie Sie es beheben

Ein vergessenes Passwort kostet 70 $. Ein Breach kostet 4,44 Millionen $. Beides beginnt gleich — Zugangsdaten, die über Slack geteilt, in Tabellen gespeichert und nie rotiert werden. Hier erfahren Sie, was Passwort-Chaos tatsächlich kostet und wie Sie es eliminieren.

Passwork BlogAlex Muntyan

Durante décadas, la respuesta a «¿cómo creo una contraseña segura?» fue: añada una mayúscula, ponga un símbolo al final, agregue un número. El problema es que los humanos bajo reglas son predecibles. La mayúscula va al principio. El símbolo y el número van al final. Las herramientas de descifrado lo saben, porque fueron entrenadas con miles de millones de contraseñas reales de personas que siguieron exactamente el mismo instinto.

Tanto la memoria humana como los algoritmos de descifrado funcionan con patrones. Ese es el conflicto, y no desaparece añadiendo @ al final del nombre de su mascota. Esta guía explica la mecánica, la única excepción y cómo es realmente un sistema de credenciales sostenible.

Puntos clave

• Cuanto más fácil es recordar una contraseña, más fácil es descifrarla. La memorabilidad y la seguridad tiran en direcciones opuestas. Esa tensión es estructural: proviene de cómo funciona la memoria humana.
• Las sustituciones de símbolos y las reglas de complejidad no aumentan significativamente la seguridad. Los algoritmos modernos de descifrado de contraseñas están entrenados específicamente en estos patrones humanos predecibles, lo que permite a los atacantes eludirlos con ataques de fuerza bruta optimizados.
• Las últimas directrices NIST SP 800-63B eliminan oficialmente las reglas de complejidad obligatorias y las rotaciones de 90 días, estableciendo un nuevo mínimo recomendado de 15 caracteres.
• El único tipo de contraseña que es memorable y criptográficamente fuerte es una frase de contraseña Diceware: palabras aleatorias elegidas por dados, no por usted.
• Solo necesita memorizar una contraseña: la frase de contraseña maestra que desbloquea su gestor de contraseñas. Todas las demás credenciales deben generarse aleatoriamente y almacenarse en la bóveda.

Qué es una contraseña segura

Una contraseña segura es una credencial que resiste tanto los intentos automatizados como los ataques dirigidos. NIST SP 800-63B establece el mínimo en 8 caracteres, recomienda que los sistemas acepten hasta 64 caracteres y elimina por completo las reglas de complejidad obligatorias en favor de la longitud y la unicidad. La base práctica de trabajo para la mayoría de los equipos de seguridad es de 12-16 caracteres generados aleatoriamente, con una entropía superior a 75 bits.

Cuatro parámetros definen si una contraseña cumple esa base:

• Longitud. La variable más efectiva. Cada carácter adicional multiplica el espacio de búsqueda exponencialmente. Con 12 caracteres, una cadena alfanumérica completamente aleatoria requiere miles de millones de años para descifrar por fuerza bruta a las velocidades de hardware actuales. Con 8, esa ventana se reduce a horas.
• Aleatoriedad. Las contraseñas elegidas por humanos se agrupan en torno a patrones predecibles: nombres, fechas, palabras de diccionario con sustituciones. Un generador de contraseñas elimina esa agrupación por completo. Si usted la eligió, probablemente sea más débil de lo que parece.
• Unicidad. Una credencial por cuenta. Una sola contraseña comprometida otorga acceso a cada sistema donde aparece. La reutilización transforma una brecha aislada en una oportunidad de movimiento lateral.
• Sin caducidad sin causa. NIST SP 800-63B desaconseja explícitamente la rotación periódica obligatoria. La rotación forzada produce incrementos predecibles (Password1 → Password2) y entrena a los usuarios a elegir contraseñas base más débiles. Cambie una credencial cuando haya evidencia de compromiso.

La paradoja de la memorabilidad: Por qué su cerebro es una vulnerabilidad

Cualquier propiedad que hace que una contraseña sea más fácil de recordar también la hace más fácil de adivinar. La memoria humana codifica información a través de patrones, asociaciones y significado. Una contraseña que permanece en su mente lo hace porque se conecta con algo que ya conoce: una palabra, una fecha, un nombre, una forma de teclado. Esas mismas conexiones son exactamente lo que explotan las herramientas de descifrado.

PassGAN (Red Generativa Adversarial para descifrado de contraseñas) y herramientas similares están entrenadas con miles de millones de credenciales filtradas. No prueban aaaaaaa antes de p@ssword. Prueban las cosas que los humanos realmente eligen, en el orden en que los humanos realmente las eligen. Sustituir @ por a en password le da p@ssword, que PassGAN genera dentro de los primeros miles de intentos en menos de una fracción de segundo. Poner mayúscula en la primera letra y añadir 1 al final son patrones que el modelo ha visto millones de veces.

La longitud y el conjunto de caracteres importan, pero no importan igual. La tabla de contraseñas de Hive Systems de 2025, probada contra 12 × RTX 5090 GPUs con bcrypt en factor de trabajo 10, muestra que una contraseña de 8 caracteres usando solo letras minúsculas cae en tres semanas. Añada mayúsculas, números y símbolos, y esa cifra alcanza 164 años contra el mismo hardware. Una contraseña de 12 caracteres con el mismo conjunto completo de caracteres mixtos lleva la tabla a siglos.

La tabla se actualiza anualmente para reflejar el hardware GPU de consumo actual. El cambio de la edición de 2024 a 2025 refleja tanto hardware más rápido como suposiciones de fortaleza de hash más realistas extraídas de lo que Hive Systems observó en datos reales de brechas.

Por qué los consejos tradicionales sobre contraseñas están obsoletos

Las antiguas reglas de complejidad (ocho caracteres, una mayúscula, un número, un símbolo) fallaron porque estaban equivocadas sobre el comportamiento humano bajo restricciones. Mientras que la paradoja de la memorabilidad describe un fallo cognitivo, las reglas de complejidad obligatorias produjeron un fallo de política sobre él.

Durante años, el enfoque de descifrado dominante fueron los ataques de diccionario: herramientas automatizadas recorriendo palabras conocidas y sustituciones comunes. Los equipos de seguridad respondieron exigiendo complejidad. El problema es que los humanos bajo presión de complejidad son predecibles. Cuando se les dice que añadan un símbolo, la mayoría lo añade al final. Cuando se les dice que sustituyan una letra, la mayoría elige las mismas sustituciones. Las reglas diseñadas para aumentar la imprevisibilidad produjeron una nueva capa de comportamiento predecible.

El otro fallo de los consejos antiguos fue la política de rotación de 90 días. Los restablecimientos forzados producen Summer2025! seguido de Fall2025!. El DBIR de 2026 de Verizon, que analizó más de 22.000 brechas confirmadas en 145 países, encontró que la explotación de vulnerabilidades ha superado al robo de credenciales como principal punto de entrada de brechas (31%). El abuso de credenciales se sitúa en el 13% como vector de acceso inicial, pero esa cifra solo mira la primera acción. El DBIR encontró que el abuso de credenciales aparece en el 39% de todas las brechas cuando se mide a lo largo de toda la cadena de ataque, convirtiéndolo en la técnica más generalizada del conjunto de datos.

La longitud es la defensa principal. Una frase de contraseña de 15 caracteres construida con palabras aleatorias es órdenes de magnitud más fuerte que una cadena de símbolos de 8 caracteres, y un humano puede realmente recordarla.

El nuevo estándar: Directrices NIST SP 800-63B Rev. 4

NIST SP 800-63B Rev. 4 (2025) establece la base actual para la seguridad de contraseñas. Cuando una contraseña es el único factor de autenticación, los sistemas deben requerir un mínimo de 8 caracteres y deberían requerir al menos 15 caracteres. Las reglas de complejidad obligatorias (símbolos forzados, números, mayúsculas y minúsculas) se eliminan explícitamente, al igual que el ciclo de caducidad de 90 días. Verificar las nuevas contraseñas contra listas de credenciales conocidas filtradas es ahora obligatorio, no opcional.

El cambio completo en la política se ve así:

La lógica detrás de eliminar la complejidad está bien documentada. La propia investigación de NIST encontró que los requisitos de complejidad empujan a los usuarios hacia patrones predecibles y aumentan los costes de soporte sin mejorar significativamente la resistencia a ataques automatizados. La longitud tiene una relación matemática directa con la dificultad de descifrado: cada carácter adicional multiplica el espacio de búsqueda exponencialmente.

Para los administradores de TI, la implicación práctica es clara: actualice sus políticas de contraseñas para requerir más de 15 caracteres, elimine los mandatos de complejidad arbitrarios e implemente verificaciones contra listas de contraseñas filtradas conocidas como el conjunto de datos de Have I Been Pwned, al que NIST hace referencia explícitamente. Deje de forzar rotaciones en un calendario programado.

Contraseñas vs. frases de contraseña

Una frase de contraseña es una secuencia de palabras aleatorias y no relacionadas usadas como una sola credencial. Las palabras son más fáciles de retener que los caracteres aleatorios, y la longitud por sí sola eleva la entropía muy por encima de lo que logran la mayoría de las contraseñas basadas en caracteres. Cuatro palabras ya superan a una cadena típica de 10 caracteres con mayúsculas y minúsculas.

La entropía de contraseña mide cuán impredecible es una credencial, expresada en bits. Mayor entropía significa más combinaciones posibles que un atacante debe probar.

Tr0ub4dor&3 parece compleja. Pero es una palabra de diccionario con sustituciones predecibles, una mayúscula al principio y un símbolo y número añadidos al final, un patrón que las herramientas de descifrado modelan explícitamente. Su entropía efectiva es mucho menor de lo que parece.

correct horse battery staple ilustra las matemáticas directamente. Cuatro palabras elegidas aleatoriamente de esa lista dan aproximadamente 44 bits de entropía (log₂ de 2.000⁴). Seis palabras aleatorias de la lista Diceware (7.776 palabras) producen alrededor de 77 bits, suficiente para resistir ataques de fuerza bruta durante décadas a las velocidades de computación actuales.

La palabra crítica es aleatorio. «Amo a mi perro Galleta» es una frase de contraseña, pero no es aleatoria. Refleja información personal y una estructura de oración natural que las herramientas de descifrado pueden modelar. Una frase de contraseña que usted inventó no es aleatoria, porque usted la inventó. La verdadera aleatoriedad requiere un método que elimine la elección humana de la ecuación por completo.

Cómo crear una contraseña segura que no olvidará

Las técnicas a continuación resuelven un problema específico: cómo crear y recordar una única frase de contraseña maestra. Esa frase de contraseña tiene un solo trabajo — desbloquear su gestor de contraseñas. Para todas las demás credenciales que posee, la respuesta es una contraseña generada aleatoriamente almacenada dentro de ese gestor, no una frase de contraseña que construyó y memorizó.

El método Diceware

El método Diceware genera frases de contraseña criptográficamente aleatorias usando dados físicos y una lista de palabras estandarizada. Debido a que la aleatoriedad proviene de tiradas de dados en lugar de elección humana, la frase de contraseña resultante tiene entropía demostrable y evita la paradoja de la memorabilidad por completo.

1. Descargue la lista de palabras grande de EFF, que contiene 7.776 palabras indexadas por códigos de dados de cinco dígitos (p. ej., 16132 = cleft).
2. Lance cinco dados de seis caras (o un dado cinco veces). Registre el resultado, por ejemplo, 2-4-1-3-6.
3. Busque la palabra correspondiente en la lista de EFF. 24136 corresponde a dragster.
4. Repita los pasos 2-3 cinco veces más para generar una frase de contraseña de seis palabras.
5. Su resultado podría ser: dragster cleft robin usage stomp anvil. Escríbalo temporalmente.

Seis palabras de la lista de EFF dan aproximadamente 77,5 bits de entropía. Ese es el objetivo. Cinco palabras (64,6 bits) es aceptable para la mayoría de casos de uso; cuatro palabras es el mínimo absoluto para una contraseña maestra.

¿Sin dados? Use un generador

Si no hay dados físicos disponibles, el generador gratuito de frases de contraseña de Passwork aplica la misma lógica en un navegador. Se ejecuta completamente en local — nada se almacena ni transmite. Puede ajustar el número de palabras, separadores y capitalización según sus requisitos. El resultado es el mismo resultado demostrablemente aleatorio que Diceware, sin la búsqueda en la lista de palabras.

El método de la oración

El método de la oración es más adecuado para personas que necesitan crear una contraseña maestra segura rápidamente sin dados. Tome una oración que sea personalmente significativa pero no públicamente conocida, y derive una contraseña de su estructura.

• Oración de ejemplo: «Mi primer coche fue un Honda de 1998 y lo conduje a la universidad.»
• Contraseña derivada: MpcfuHd1998ylcalu

Esto produce una cadena de 17 caracteres con mayúsculas y minúsculas y números que no tiene relación con el diccionario. La oración misma es el mnemotécnico: recuerda la oración, no la contraseña.

La limitación: este método produce menos entropía que Diceware porque los humanos eligen oraciones memorables, y las oraciones memorables siguen patrones gramaticales predecibles. Úselo solo para la contraseña maestra cuando Diceware no sea práctico. Para todo lo demás, use un gestor.

La técnica del palacio de la memoria

El palacio de la memoria (Método de Loci) es una técnica mnemotécnica para retener la frase de contraseña maestra que generó con Diceware. Funciona asociando cada palabra con una ubicación física específica en un espacio familiar: su casa, su ruta de desplazamiento, un edificio que conoce bien.

Para memorizar dragster cleft robin usage stomp anvil:

1. Elija una ruta familiar a través de un espacio que conoce bien: su puerta de entrada, pasillo, cocina, sala de estar, escaleras, dormitorio.
2. Asigne una palabra a cada ubicación. Haga la imagen vívida e inusual: un dragster rugiendo a través de su puerta de entrada, una roca hendida partiendo el suelo de su pasillo, un petirrojo sentado en la encimera de su cocina.
3. Recorra la ruta mentalmente, en orden, varias veces. Cuanto más extraña sea la imagen, más fiablemente permanece.
4. Después de 24 horas, pruebe el recuerdo sin mirar la frase de contraseña escrita. La mayoría de las personas pueden recordar las seis palabras después de tres o cuatro recorridos mentales.

El palacio de la memoria funciona porque el cerebro codifica la información espacial y visual de manera más fiable que las cadenas abstractas. No está memorizando dragster cleft robin usage stomp anvil. Está memorizando un paseo por su casa.

Una vez memorizada la frase de contraseña, destruya la copia escrita.

Saber cómo construir y retener una frase de contraseña maestra es una habilidad útil. Pero la memorabilidad es una restricción, y las restricciones producen compromisos. Un gestor de contraseñas elimina esa restricción por completo: genera credenciales con entropía completa, las almacena cifradas y las recupera sin pedirle que recuerde nada más allá de una frase de contraseña. Las técnicas anteriores existen para proteger esa única frase de contraseña. Todo lo demás debe generarse, no inventarse.

El único estándar: Una frase de contraseña, todo lo demás en un gestor de contraseñas

La paradoja de la memorabilidad tiene una única solución estructural. Memoriza una frase de contraseña maestra generada aleatoriamente. Un gestor de contraseñas genera y almacena todo lo demás, produciendo credenciales completamente aleatorias y únicas para cada cuenta que nunca necesita ver, escribir ni recordar. Esa estructura se mantiene tanto si tiene cinco cuentas como quinientas.

En la práctica, esto significa:

• Cero reutilización de contraseñas entre cuentas — cada credencial es única y generada aleatoriamente.
• Una sola cosa que memorizar — la frase de contraseña maestra que creó con Diceware.
• Sin decisiones de seguridad que tomar al iniciar sesión — el gestor maneja la generación, almacenamiento y autocompletado.

Passwork está diseñado para esta arquitectura. Está disponible como despliegue autoalojado o como servicio en la nube. Ambas opciones utilizan cifrado AES-256 del lado del cliente: las credenciales se cifran antes de salir de su dispositivo, y Passwork nunca ve las contraseñas en texto plano.

Los dos modelos de despliegue difieren en una dimensión:

• La opción autoalojada mantiene todos los datos dentro de su propia infraestructura.
• La opción en la nube elimina la carga operativa de ejecutar su propia instancia sin cambiar el modelo de cifrado.

El control de acceso basado en roles permite a los administradores asignar permisos de bóveda a equipos en lugar de a individuos — relevante si gestiona credenciales para un equipo en lugar de solo para usted mismo. Un nuevo ingeniero hereda acceso a las bóvedas correctas desde el primer día y lo pierde en el momento en que se va, sin necesidad de limpieza manual.

Para equipos con requisitos de cumplimiento, los registros de auditoría de Passwork proporcionan un registro completo de quién accedió a qué credencial y cuándo — el tipo de documentación que requieren los controles SOC 2 CC6.1 e ISO 27001:2022 Anexo A 5.15. Las guías técnicas cubren la integración con AD/LDAP, SAML SSO y acceso REST API para equipos que necesitan integrar la gestión de credenciales en flujos de trabajo existentes.

Ejemplos de contraseñas seguras: Cómo luce una buena contraseña en 2026

La columna de «uso recomendado» es el punto. Las contraseñas Diceware y derivadas de oraciones aparecen una vez en su vida, como la credencial maestra. Todas las demás cuentas obtienen una contraseña generada por máquina que nunca ve, nunca escribe y nunca necesita recordar.

Poniéndolo en práctica

La paradoja de la memorabilidad no tiene un rodeo — tiene una solución. Memorice una cosa, generada aleatoriamente, usando un método que elimine su cerebro del proceso. Use eso para desbloquear un gestor de contraseñas que maneje todas las demás credenciales con aleatoriedad generada por máquina en la que nunca tiene que pensar.

Genere una frase de contraseña Diceware de 6 palabras. Codifíquela con un palacio de la memoria. Ponga todo lo demás en una bóveda.

Preguntas frecuentes

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 clic, y por qué las últimas directrices NIST recomiendan no forzar la rotación de contraseñas.

Passwork BlogAlex Muntyan

11 riesgos de reutilización de contraseñas y cómo evitarlos

Reutilizar una contraseña parece inofensivo. No lo es. Aquí le explicamos por qué una sola credencial filtrada puede desmoronar toda la seguridad de su organización — y cómo evitar que suceda.

Passwork BlogAlex Muntyan

Caos de contraseñas: Por qué es un problema empresarial y cómo solucionarlo

Una contraseña olvidada cuesta $70. Una brecha cuesta $4,44 millones. Ambas empiezan igual — credenciales compartidas por Slack, almacenadas en hojas de cálculo, nunca rotadas. Esto es lo que realmente cuesta el caos de contraseñas y cómo eliminarlo.

Passwork BlogAlex Muntyan

For decades, the answer to "how do I make a strong password?" was: add a capital letter, throw a symbol at the end, append a number. The problem is that humans under rules are predictable. The capital goes at the front. The symbol and number go at the back. Cracking tools know this, because they were trained on billions of real passwords from people who followed exactly the same instinct.

Both human memory and cracking algorithms run on patterns. That's the conflict, and it doesn't go away by adding @ to the end of your dog's name. This guide explains the mechanics, the one exception, and what a sustainable credential system actually looks like.

Key takeaways

• The easier a password is to remember, the easier it is to crack. Memorability and security pull in opposite directions. That tension is structural: it comes from how human memory works.
• Symbol substitutions and complexity rules do not meaningfully increase security. Modern password-cracking algorithms are trained specifically on these predictable human patterns, allowing attackers to bypass them with optimized brute-force attacks.
• The latest NIST SP 800-63B guidelines officially drop mandatory complexity rules and 90-day rotations, establishing a new recommended minimum of 15 characters.
• The only password type that is both memorable and cryptographically strong is a Diceware passphrase: random words chosen by dice, not by you.
• You need to memorize exactly one password: the master passphrase that unlocks your password manager. Every other credential should be randomly generated and stored in the vault.

What is a strong password

A strong password is a credential that resists both automated guessing and targeted attacks.  NIST SP 800-63B sets the minimum at 8 characters, recommends systems accept up to 64 characters, and drops mandatory complexity rules entirely in favor of length and uniqueness. The practical working baseline for most security teams is 12-16 randomly generated characters, with entropy above 75 bits.

Four parameters define whether a password meets that baseline:

• Length. The single most effective variable. Each additional character multiplies the search space exponentially. At 12 characters, a fully random alphanumeric string requires billions of years to brute-force at current hardware speeds. At 8, that window collapses to hours. 
• Randomness. Human-chosen passwords cluster around predictable patterns: names, dates, dictionary words with substitutions. A password generator removes that clustering entirely. If you chose it, it is probably weaker than it looks.
• Uniqueness. One credential per account. A single compromised password grants access to every system where it appears. Reuse transforms an isolated breach into a lateral movement opportunity.
• No expiration without cause. NIST SP 800-63B explicitly deprecates mandatory periodic rotation. Forced rotation produces predictable increments (Password1 → Password2) and trains users to choose weaker base passwords. Change a credential when there is evidence of compromise.

The memorability paradox: Why your brain is a liability

Any property that makes a password easier to remember also makes it easier to guess. Human memory encodes information through patterns, associations, and meaning. A password that sticks in your mind does so because it connects to something you already know: a word, a date, a name, a keyboard shape. Those same connections are exactly what cracking tools exploit.

PassGAN (Generative Adversarial Network for password cracking) and similar tools are trained on billions of leaked credentials. They do not try aaaaaaa before p@ssword. They try the things humans actually choose, in the order humans actually choose them. Substituting @ for a in password gives you p@ssword, which PassGAN generates within the first few thousand guesses in less than a fraction of a second. Capitalising the first letter and adding 1 at the end are patterns the model has seen millions of times.

Length and character set both matter, but they don't matter equally. Hive Systems' 2025 password table, tested against 12 × RTX 5090 GPUs with bcrypt at work factor 10, shows that an 8-character password using only lowercase letters falls in three weeks. Add uppercase, numbers, and symbols, and that figure reaches 164 years against the same hardware. A 12-character password with the same full mixed-character set takes the table into centuries.

The table is updated annually to reflect current consumer GPU hardware. The shift from the 2024 edition to 2025 reflects both faster hardware and more realistic hash strength assumptions drawn from what Hive Systems observed in actual breach data.

Why traditional password advice is dead

The old complexity rules (eight characters, one uppercase, one number, one symbol) failed, because they were wrong about human behaviour under constraints. Where the memorability paradox describes a cognitive failure, mandatory complexity rules produced a policy failure on top of it.

For years, the dominant cracking approach was dictionary attacks: automated tools cycling through known words and common substitutions. Security teams responded by mandating complexity. The problem is that humans under complexity pressure are predictable. When told to add a symbol, most people add it at the end. When told to substitute a letter, most choose the same substitutions. The rules designed to increase unpredictability produced a new layer of predictable behaviour.

The other failure of old advice was the 90-day rotation policy. Forced resets produce Summer2025! followed by Fall2025!. Verizon's 2026 DBIR, which analyzed over 22,000 confirmed breaches across 145 countries, found that vulnerability exploitation has now overtaken credential theft as the primary breach entry point (31%). Credential abuse sits at 13% as an initial access vector, but that figure looks at only the first action. The DBIR found that credential abuse appears in 39% of all breaches when measured across the full attack chain making it the single most pervasive technique in the dataset.

Length is the primary defense. A 15-character passphrase built from random words is orders of magnitude stronger than an 8-character string of symbols, and a human can actually remember it.

The new standard: NIST SP 800-63B Rev. 4 guidelines

NIST SP 800-63B Rev. 4 (2025) sets the current baseline for password security. When a password is the only authentication factor, systems must require a minimum of 8 characters and should require at least 15 characters. Mandatory complexity rules (forced symbols, numbers, mixed case) are explicitly dropped, as is the 90-day expiration cycle. Checking new passwords against known-breached credential lists is now required, not optional.

The full shift in policy looks like this:

The logic behind dropping complexity is well-documented. NIST's own research found that complexity requirements push users toward predictable patterns and increase support costs without meaningfully improving resistance to automated attacks. Length has a direct mathematical relationship with cracking difficulty: each additional character multiplies the search space exponentially.

For IT administrators, the practical implication is clear: update your password policies to require 15+ characters, remove arbitrary complexity mandates, and implement checks against known-breached password lists such as the Have I Been Pwned dataset, which NIST explicitly references. Stop forcing rotations on a calendar schedule.

Passwords vs. passphrases

A passphrase is a sequence of random, unrelated words used as a single credential. Words are easier to retain than random characters, and length alone pushes entropy well above what most character-based passwords achieve. Four words already outperform a typical 10-character mixed-case string .

Password entropy measures how unpredictable a credential is, expressed in bits. Higher entropy means more possible combinations an attacker must try.

Tr0ub4dor&3 looks complex. But it is a dictionary word with predictable substitutions, a capital at the start, and a symbol and number appended at the end, a pattern that cracking tools model explicitly. Its effective entropy is far lower than it appears.

correct horse battery staple illustrates the math directly. Four words chosen randomly from that list gives approximately 44 bits of entropy (log₂ of 2,000⁴). Six random words from the Diceware list (7,776 words) produces around 77 bits, enough to resist brute-force attacks for decades at current computing speeds.

The critical word is random. "I love my dog Biscuit" is a passphrase, but it is not random. It reflects personal information and a natural sentence structure that cracking tools can model. A passphrase you invented is not random, because you invented it. True randomness requires a method that removes human choice from the equation entirely.

How to create a strong password you won't forget

The techniques below solve one specific problem: how to create and remember a single master passphrase. That passphrase has one job — unlocking your password manager. For every other credential you own, the answer is a randomly generated password stored inside that manager, not a passphrase you constructed and memorized. 

The Diceware method

The Diceware method generates cryptographically random passphrases using physical dice and a standardized word list. Because the randomness comes from dice rolls rather than human choice, the resulting passphrase has provable entropy and sidesteps the memorability paradox entirely.

1. Download the EFF Large Wordlist, which contains 7,776 words indexed by five-digit dice codes (e.g., 16132 = cleft).
2. Roll five six-sided dice (or one die five times). Record the result, for example, 2-4-1-3-6.
3. Look up the corresponding word in the EFF list. 24136 maps to dragster.
4. Repeat steps 2-3 five more times to generate a six-word passphrase.
5. Your result might be: dragster cleft robin usage stomp anvil. Write it down temporarily. 

Six words from the EFF list gives approximately 77.5 bits of entropy. That is the target. Five words (64.6 bits) is acceptable for most use cases; four words is the absolute minimum for a master password.

No dice? Use a generator

If physical dice aren't available, Passwork's free passphrase generator applies the same logic in a browser. It runs entirely locally — nothing is stored or transmitted. You can adjust word count, separators, and capitalization to match your requirements. The output is the same provably random result as Diceware, without the wordlist lookup.

The sentence method

The sentence method is better suited for people who need to create a strong master password quickly without dice. Take a sentence that is personally meaningful but not publicly known, and derive a password from its structure.

• Example sentence: "My first car was a 1998 Honda and I drove it to college."
• Derived password: MfcWa1998HaIdItC

This produces a 16-character string with mixed case and numbers that has no dictionary relationship. The sentence itself is the mnemonic: you remember the sentence, not the password.

The limitation: this method produces less entropy than Diceware because humans choose memorable sentences, and memorable sentences follow predictable grammatical patterns. Use it only for the master password when Diceware is not practical. For everything else, use a manager.

The memory palace technique

The memory palace (Method of Loci) is a mnemonic technique for retaining the master passphrase you generated with Diceware. It works by associating each word with a specific physical location in a familiar space: your home, your commute route, a building you know well.

To memorize dragster cleft robin usage stomp anvil:

1. Choose a familiar route through a space you know well: your front door, hallway, kitchen, living room, stairs, bedroom.
2. Assign one word to each location. Make the image vivid and unusual: a dragster roaring through your front door, a cleft rock splitting your hallway floor, a robin sitting on your kitchen counter.
3. Walk the route mentally, in order, several times. The stranger the image, the more reliably it sticks.
4. After 24 hours, test recall without looking at the written passphrase. Most people can recall all six words after three or four mental walkthroughs.

The memory palace works because the brain encodes spatial and visual information more reliably than abstract strings. You are not memorizing dragster cleft robin usage stomp anvil. You are memorizing a walk through your house.

Once the passphrase is memorized, destroy the written copy.

Knowing how to construct and retain a master passphrase is a useful skill. But memorability is a constraint, and constraints produce compromises. A password manager removes that constraint entirely: it generates credentials with full entropy, stores them encrypted, and retrieves them without asking you to remember anything beyond one passphrase. The techniques above exist to protect that one passphrase. Everything else should be generated, not invented.

The only standard: One passphrase, everything else in a password manager

The memorability paradox has a single structural solution. You memorize one randomly generated master passphrase. A password manager generates and stores everything else, producing fully random, unique credentials for every account that you never need to see, type, or remember. That structure holds whether you have five accounts or five hundred.

In practice, this means:

• Zero password reuse across accounts — every credential is unique and randomly generated.
• One thing to memorize — the master passphrase you created with Diceware.
• No security decisions to make at login — the manager handles generation, storage, and autofill.

Passwork is built for this architecture. It is available as a self-hosted deployment or as a cloud service. Both options use AES-256 client-side encryption: credentials are encrypted before they leave your device, and Passwork never sees plaintext passwords.

The two deployment models differ in one dimension:

• The self-hosted option keeps all data within your own infrastructure.
• The cloud option removes the operational overhead of running your own instance without changing the encryption model.

Role-based access control lets administrators assign vault permissions to teams rather than individuals — relevant if you are managing credentials for a team rather than just yourself. A new engineer inherits access to the right vaults on day one and loses it the moment they leave, with no manual cleanup required.

For teams with compliance requirements, Passwork's audit logs provide a full record of who accessed which credential and when — the kind of documentation that SOC 2 CC6.1 and ISO 27001:2022 Annex A 5.15 controls require. The technical guides cover AD/LDAP integration, SAML SSO, and REST API access for teams that need to embed credential management into existing workflows.

Strong password examples: What good looks like in 2026

The "recommended use" column is the point. Diceware and sentence-derived passwords appear once in your life, as the master credential. Every other account gets a machine-generated password that you never see, never type, and never need to remember.

Putting it into practice

The memorability paradox does not have a workaround — it has a solution. Memorize one thing, generated randomly, using a method that removes your brain from the process. Use that to unlock a password manager that handles every other credential with machine-generated randomness you never have to think about.

Generate a 6-word Diceware passphrase. Encode it with a memory palace. Put everything else in a vault.

Frequently asked questions

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

11 password reuse risks and how to avoid them

Reusing a password feels harmless. It isn’t. Here’s why one leaked credential can unravel your entire organization’s security — and how to stop it from happening.

Passwork BlogAlex Muntyan

Password chaos: Why it’s a business problem and how to fix it

A forgotten password costs $70. A breach costs $4.44 million. Both start the same way — credentials shared over Slack, stored in spreadsheets, never rotated. Here’s what password chaos actually costs and how to eliminate it.

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

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

Wenn eine Datenbank kompromittiert wird, lautet die erste Frage immer gleich: Sind die gehashten Passwörter sicher? Die Antwort hängt vollständig davon ab, wie diese Hashes erzeugt wurden. SHA-256 selbst kann nicht entschlüsselt werden — es ist eine kryptografische Einweg-Hashfunktion, kein Verschlüsselungsalgorithmus. Aber „kann nicht entschlüsselt werden" bedeutet nicht dasselbe wie „kann nicht geknackt werden".

Was ist SHA-256

SHA-256 (Secure Hash Algorithm 256-bit) ist eine kryptografische Hashfunktion aus der SHA-2-Familie, die von der NSA entwickelt und 2001 vom NIST unter FIPS 180-4 veröffentlicht wurde. Sie nimmt eine Eingabe beliebiger Länge und erzeugt eine feste 256-Bit-(32-Byte-)Ausgabe — den Hash oder Digest. Die Ausgabe erscheint immer zufällig, und dieselbe Eingabe erzeugt immer dieselbe Ausgabe.

SHA-256 ist kein Verschlüsselungsalgorithmus. Es gibt keinen Schlüssel, und die Ausgabe kann nicht umgekehrt werden. Seine Aufgabe ist es, einen einzigartigen Fingerabdruck eines Datensatzes zu erzeugen — nicht diese Daten für eine spätere Wiederherstellung zu schützen.

Drei Eigenschaften definieren seine Sicherheit:

• Urbildresistenz. Bei gegebenem Hash kann die ursprüngliche Eingabe nicht gefunden werden.
• Kollisionsresistenz. Es können keine zwei verschiedenen Eingaben gefunden werden, die denselben Hash erzeugen.
• Lawineneffekt. Eine Änderung eines einzelnen Bits in der Eingabe kippt etwa die Hälfte der Ausgabe-Bits, wodurch das Ergebnis völlig unvorhersehbar wird.

SHA-256 wird in TLS-Zertifikaten, Code-Signierung, Git-Commit-Integrität, Bitcoins Proof-of-Work-Mechanismus und (in Kombination mit korrekter Schlüsselableitung) bei der Passwortspeicherung verwendet. Es ist eines der am weitesten verbreiteten kryptografischen Primitive in Produktivsystemen heute.

Hashing vs. Verschlüsselung: Warum SHA-256 nicht entschlüsselt werden kann

SHA-256 ist eine kryptografische Hashfunktion — eine Einweg-Transformation. Verschlüsselung ist eine Zweiwege-Operation: Daten werden mit einem Schlüssel verschlüsselt und mit einem Schlüssel entschlüsselt. Hashing hat keinen Schlüssel und keinen Rückweg. Bei einem gegebenen SHA-256-Digest gibt es keine mathematische Operation, die die ursprüngliche Eingabe wiederherstellt.

Die Eigenschaft, die dies ermöglicht, heißt Urbildresistenz: Es muss rechnerisch unmöglich sein, eine Eingabe m zu finden, sodass SHA256(m) = h für einen gegebenen Hash h gilt. Eine verwandte Eigenschaft, der Lawineneffekt, bedeutet, dass die Änderung eines einzelnen Bits in der Eingabe etwa die Hälfte der Ausgabe-Bits kippt — was es unmöglich macht, durch kleine Anpassungen „rückwärts zu arbeiten".

Die Unterscheidung ist in der Praxis wichtig. Wenn ein Entwickler Passwörter mittels AES-Verschlüsselung statt Hashing speichert, legt ein Verlust des Verschlüsselungsschlüssels jedes Passwort in der Datenbank offen. Ein Hash hat keinen Schlüssel, der gestohlen werden kann.

Wie der SHA-256-Algorithmus funktioniert (Schritt für Schritt)

SHA-256 ist in NIST FIPS 180-4 definiert und gehört zur SHA-2-Familie. Er verarbeitet Eingaben beliebiger Länge und erzeugt eine deterministische 256-Bit-Ausgabe. Die Kernstruktur ist die Merkle-Damgård-Konstruktion: Die Nachricht wird in Blöcke fester Größe aufgeteilt, jeder Block wird durch eine Kompressionsfunktion verarbeitet, und die Ausgaben werden verkettet.

Schritt 1: Vorverarbeitung und Padding

Die Eingabenachricht wird aufgefüllt, sodass ihre Gesamtlänge ein Vielfaches von 512 Bits ist. Das Padding beginnt immer mit einem 1-Bit, gefolgt von genügend 0-Bits, gefolgt von einer 64-Bit-Darstellung der ursprünglichen Nachrichtenlänge. Dieser Schritt ist obligatorisch, auch wenn die Nachricht bereits genau passt — der Algorithmus muss immer wissen, wo die Nachricht endet.

Schritt 2: Nachrichtenplanung

Die aufgefüllte Nachricht wird in 512-Bit-Blöcke zerlegt. Jeder Block wird in sechzehn 32-Bit-Wörter unterteilt. Diese sechzehn Wörter werden dann mithilfe einer Mischung aus bitweisen Rotationen und XOR-Operationen zu einem 64-Wort-Nachrichtenplan erweitert. Diese Erweiterung stellt sicher, dass jedes Bit der ursprünglichen Eingabe den Kompressionsschritt beeinflusst.

Schritt 3: Die Kompressionsfunktion

Hier findet die eigentliche Arbeit statt. SHA-256 verwaltet acht 32-Bit-Arbeitsvariablen (a bis h), die mit Konstanten initialisiert werden, die aus den Nachkommastellen der Quadratwurzeln der ersten acht Primzahlen abgeleitet sind. Über 64 Runden werden diese Variablen mithilfe von bitweisen AND-, OR-, XOR- und NOT-Operationen sowie modularer Addition aktualisiert. Zwei nichtlineare Funktionen — Ch(e, f, g) und Maj(a, b, c) — führen eine Komplexität ein, die die Beziehung zwischen Eingabe und Ausgabe undurchsichtig macht. Nach allen 64 Runden werden die Arbeitsvariablen wieder zu den Anfangswerten für diesen Block addiert.

Schritt 4: Endgültige Ausgabe

Nachdem alle Blöcke verarbeitet wurden, werden die acht Arbeitsvariablen verkettet, um den endgültigen 256-Bit-Digest zu erzeugen. Dieselbe Eingabe erzeugt immer dieselbe Ausgabe. Jede Änderung an der Eingabe — selbst ein einzelnes Zeichen — erzeugt einen völlig anderen Hash.

Wenn SHA-256 nicht entschlüsselt werden kann, wie knacken Hacker es dann?

SHA-256 ist mathematisch solide. Der Algorithmus selbst hat nach mehr als zwei Jahrzehnten Kryptoanalyse keine bekannten praktischen Schwächen. Was versagt, ist nicht der Algorithmus — es ist die Art und Weise, wie Passwörter damit gespeichert werden.

Brute-Force-Angriffe

Ein Brute-Force-Angriff kehrt den Hash nicht um. Er rät. Der Angreifer hasht Passwortkandidaten (Wörterbuchwörter, gängige Muster, Zeichenkombinationen) und vergleicht die Ausgabe mit dem gestohlenen Hash. Wenn die Hashes übereinstimmen, ist das Passwort gefunden. Die Geschwindigkeit von SHA-256 ist hier das Problem: Eine einzelne Nvidia RTX 4090 GPU kann etwa 164 Milliarden SHA-256-Hashes pro Sekunde berechnen (Specops Software, 2025). Bei dieser Rate wird ein achtstelliges Kleinbuchstaben-Passwort in Sekunden geknackt.

Rainbow-Table-Angriffe

Eine Rainbow Table ist eine vorberechnete Datenbank von Hash-zu-Klartext-Zuordnungen. Anstatt spontan zu hashen, schlägt der Angreifer den gestohlenen Hash in der Tabelle nach und liest das ursprüngliche Passwort ab. Tabellen für gängige Passwortformate können im Voraus generiert und für mehrere Datenlecks wiederverwendet werden. Kollisionsresistenz — die Eigenschaft, dass keine zwei Eingaben denselben Hash erzeugen sollten — ist nicht das, was Rainbow Tables ausnutzen. Sie nutzen die Tatsache aus, dass gängige Passwörter vorhersehbare, wiederholbare Hashes erzeugen.

Beide Angriffe haben eine gemeinsame Voraussetzung: Der Hash muss ungesalzen sein. Fügen Sie ein Salt hinzu, und beide Angriffe werden dramatisch teurer.

Warum reines SHA-256 für die Passwortspeicherung ungeeignet ist

SHA-256 wurde für Geschwindigkeit entwickelt. Für seine vorgesehenen Anwendungen — Überprüfung der Dateiintegrität, Signierung von Zertifikaten, Absicherung von Blockchain-Transaktionen — ist Geschwindigkeit ein Vorteil. Für die Passwortspeicherung ist Geschwindigkeit ein Nachteil.

Das Problem: SHA-256 ist zu schnell

Bei 164 Milliarden Hashes pro Sekunde auf Consumer-Hardware kann ein Angreifer den gesamten Raum von achtstelligen Passwörtern mit Groß- und Kleinbuchstaben, Ziffern und Symbolen in weniger als einer Stunde durchprobieren. Das OWASP Password Storage Cheat Sheet ist eindeutig: „Schnelle Hash-Algorithmen wie SHA-256 sind für die Passwortspeicherung nicht geeignet, da sie Angreifern ermöglichen, schnell eine große Anzahl von Versuchen durchzuführen."

Lösung 1: Salting

Ein Salt ist eine eindeutige, zufällig generierte Zeichenkette, die vor dem Hashen an jedes Passwort angehängt wird. SHA256("password") erzeugt immer denselben Hash. SHA256("password" + "x7kQ2mNp") erzeugt einen völlig anderen — und jeder Benutzer erhält ein anderes Salt. Dies macht Rainbow Tables vollständig wirkungslos: Der Angreifer kann keine Hashes für gesalzene Eingaben vorberechnen, ohne das Salt jedes Benutzers zu kennen. Es bedeutet auch, dass zwei Benutzer mit demselben Passwort unterschiedliche Hashes in der Datenbank haben.

Lösung 2: Key Stretching mit PBKDF2

Salting verhindert vorberechnete Lookups, verlangsamt aber keine Brute-Force-Angriffe. Dafür ist Key Stretching erforderlich. PBKDF2 (Password-Based Key Derivation Function 2) wendet eine pseudozufällige Funktion — typischerweise HMAC-SHA-256 — tausende Male nacheinander an. Jede Iteration kostet Zeit. Die 164 Milliarden Hashes pro Sekunde des Angreifers sinken auf einen Bruchteil davon, wenn jeder „Versuch" 600.000 Iterationen erfordert.

OWASP empfiehlt PBKDF2 mit HMAC-SHA-256 und mindestens 600.000 Iterationen für FIPS-140-Konformität. Argon2id ist die bevorzugte Wahl, wenn keine FIPS-Konformität erforderlich ist, da es zusätzlich Speicherhärte bietet.

Reines SHA-256 vs. PBKDF2-HMAC-SHA256: Sicherheitsvergleich bei der Passwortspeicherung

Ist SHA-256 anfällig für Quantencomputer?

Grovers Algorithmus gibt einem Quantencomputer eine quadratische Beschleunigung bei unstrukturierten Suchproblemen. Angewandt auf SHA-256 reduziert er die effektive Sicherheit von 2²⁵⁶ Operationen auf 2¹²⁸ Operationen. Das klingt alarmierend, bis man das Ausmaß berücksichtigt: 2¹²⁸ sind ungefähr 3,4×10³⁸. Ein Quantencomputer, der mit 10 Milliarden Operationen pro Sekunde läuft, würde etwa 3,4×10²⁸ Jahre benötigen, um die Hälfte des Suchraums zu durchsuchen — Größenordnungen länger als das Alter des Universums.

Shors Algorithmus, der RSA und Elliptische-Kurven-Kryptografie durch effizientes Faktorisieren großer ganzer Zahlen bricht, gilt nicht für Hashfunktionen. Die Sicherheit von SHA-256 basiert nicht auf der Faktorisierung ganzer Zahlen.

NIST standardisiert aktiv Post-Quanten-Algorithmen (FIPS 203, 204, 205 wurden 2024 finalisiert), hauptsächlich mit Fokus auf asymmetrische Kryptografie. SHA-256 steht für die absehbare Zukunft nicht auf der Ersatzliste. Die praktische Bedrohung für SHA-256 durch Quantencomputing bleibt theoretisch.

Wie Enterprise-Passwortmanager Kryptografie sicher einsetzen

Enterprise-Passwortmanager, die Zero-Knowledge-Prinzipien befolgen, wenden dieselben kryptografischen Bausteine an, die in diesem Artikel behandelt werden (SHA-256, PBKDF2, HMAC, AES-256), kombinieren sie jedoch zu einer mehrschichtigen Architektur, bei der der Server niemals Klartextdaten oder die Schlüssel zur Entschlüsselung besitzt. Die Sicherheitsgarantie ergibt sich aus dem Design, nicht aus dem Vertrauen in den Server.

Das Passwork-Zwei-Ebenen-Verschlüsselungsmodell

Zu wissen, dass reines SHA-256 für die Passwortspeicherung unzureichend ist, ist eine Sache. Die korrekte Alternative unternehmensweit zu implementieren, ist eine andere. Hier ist die Architektur des Tools genauso wichtig wie der Algorithmus.

Passwork basiert auf einer Zero-Knowledge-Architektur: Der Server besitzt niemals genügend Informationen, um Benutzerdaten zu entschlüsseln. Das Masterpasswort verlässt niemals das Gerät des Benutzers. Alle kryptografischen Schlüssel werden clientseitig generiert. Der Server speichert nur verschlüsselte Daten und verschlüsselte Schlüssel — die Entschlüsselung ist nur auf dem Client möglich.

Die Verschlüsselungskette funktioniert wie folgt, wie in Passworks Kryptografie-Übersicht dokumentiert:

1. Masterpasswort (vom Benutzer eingegeben) → PBKDF2 mit SHA-256, 300.000 Iterationen
2. Masterschlüssel (512 Bits) → AES-256-CBC
3. Privater RSA-Schlüssel (2048 Bits, RSA-OAEP)
4. Tresorschlüssel (256 Bits) → AES-256-CBC
5. Datensatzschlüssel (256 Bits) → AES-256-CBC
6. Datensatzdaten (Passwörter, Geheimnisse, Dateien — verschlüsselt im Ruhezustand)

Auf der Serverseite verschlüsselt eine separate AES-256-CFB-Schicht die Datenbank unabhängig. Jeder Datensatz ist doppelt verschlüsselt: einmal vom Client, bevor er das Gerät verlässt, einmal vom Server, bevor er auf die Festplatte geschrieben wird.

PBKDF2 mit 300.000 clientseitigen Iterationen entspricht den NIST-Empfehlungen (≥310.000 für SHA-256) und übertrifft das OWASP-Minimum für die meisten Einsatzszenarien. Das serverseitige PBKDF2 läuft mit 600.000 Iterationen — und erfüllt damit direkt die FIPS-140-Schwelle.

Diese Architektur bedeutet, dass ein Datenbankleck nichts Verwertbares liefert. Ein Angreifer, der die Datenbank exfiltriert, erhält AES-256-verschlüsselte Blobs, die von Schlüsseln abgeleitet wurden, die niemals auf dem Server gespeichert waren.

Fazit

SHA-256 ist theoretisch unknackbar. Der Algorithmus hat über zwei Jahrzehnte Kryptoanalyse ohne einen praktischen Angriff überstanden. Aber der Algorithmus ist nur so stark wie seine Implementierung. Speichern Sie Passwörter als reine SHA-256-Hashes, und eine einzelne GPU kann Milliarden von Kandidaten pro Sekunde testen. Fügen Sie ein Salt hinzu und wenden Sie PBKDF2 mit ausreichenden Iterationen an, und dieselbe Hardware wird gegen Ihre Datenbank nutzlos.

Die Lücke zwischen „SHA-256 ist sicher" und „unsere Passwörter sind sicher" wird durch korrekte Implementierung gefüllt — Salting, Key Stretching und eine Zero-Knowledge-Architektur, die sicherstellt, dass der Server niemals die Schlüssel besitzt, die zur Entschlüsselung von Benutzerdaten benötigt werden.

Wenn Ihr Team Unternehmensanmeldedaten verwaltet, schützt Passwork diese durch Zero-Knowledge-Architektur, clientseitige AES-256-Verschlüsselung und PBKDF2-Key-Stretching mit 300.000 Iterationen — sodass eine Serverkompromittierung nichts Verwertbares offenlegt. Passwork ist sowohl als selbstgehostete Bereitstellung für Organisationen verfügbar, die vollständige Infrastrukturkontrolle benötigen, als auch als Cloud-Lösung für Teams, die dieselben kryptografischen Garantien ohne eigene Serververwaltung wünschen.

FAQ: SHA-256 erklärt

Kann man SHA-256 entschlüsseln?

Nein. SHA-256 ist eine kryptografische Einweg-Hashfunktion. Es gibt keinen Schlüssel, keinen Umkehralgorithmus und keine mathematische Operation, die die ursprüngliche Eingabe aus einem Hash wiederherstellt. Was Angreifer tun können, ist raten — indem sie Passwortkandidaten hashen und die Ausgabe vergleichen. Das ist Knacken, nicht Entschlüsselung, und es funktioniert nur gegen schwache oder ungesalzene Hashes.

Was ist der Unterschied zwischen SHA-256-Hashing und Verschlüsselung?

Verschlüsselung ist mit dem richtigen Schlüssel umkehrbar. Hashing ist unter keinen Umständen umkehrbar. SHA-256 nimmt eine Eingabe beliebiger Länge und erzeugt eine feste 256-Bit-Ausgabe. Dieselbe Eingabe erzeugt immer dieselbe Ausgabe, aber der Prozess kann nicht rückwärts ausgeführt werden. Verschlüsselung bewahrt die Fähigkeit, die Originaldaten wiederherzustellen; Hashing zerstört sie absichtlich.

Was ist der Lawineneffekt bei SHA-256?

Der Lawineneffekt bedeutet, dass eine Änderung eines einzelnen Bits in der Eingabe etwa die Hälfte der Ausgabe-Bits kippt. Ändern Sie ein Zeichen in einem Passwort, und der resultierende SHA-256-Hash sieht völlig anders aus als der ursprüngliche. Diese Eigenschaft verhindert, dass Angreifer Teilwissen über eine Eingabe nutzen können, um den Hash-Suchraum einzugrenzen.

Was ist PBKDF2 und warum ist es für die Passwortsicherheit wichtig?

PBKDF2 (Password-Based Key Derivation Function 2) wendet eine pseudozufällige Funktion — typischerweise HMAC-SHA-256 — iterativ auf ein Passwort und Salt an. Jede Iteration erhöht den Rechenaufwand. Bei 600.000 Iterationen steigt die benötigte Zeit pro Versuch um den Faktor 600.000 im Vergleich zu einem einzelnen SHA-256-Hash. Dies macht Brute-Force-Angriffe gegen korrekt gespeicherte Passwörter selbst mit GPU-Rechenleistung unpraktikabel.

Ist SHA-256 anfällig für Quantencomputer-Angriffe?

Praktisch nicht. Grovers Algorithmus reduziert die effektive Sicherheit von SHA-256 von 2²⁵⁶ auf 2¹²⁸ Operationen. Bei 2¹²⁸ würde selbst ein hypothetischer Quantencomputer mit 10 Milliarden Operationen pro Sekunde mehr Zeit als das Alter des Universums benötigen, um den Suchraum zu durchsuchen. NISTʼs Post-Quanten-Kryptografie-Standardisierungsinitiative zielt auf asymmetrische Algorithmen ab, nicht auf SHA-256.

Was ist die Merkle-Damgård-Konstruktion?

Die Merkle-Damgård-Konstruktion ist das strukturelle Rahmenwerk, das SHA-256 zugrunde liegt. Die Eingabenachricht wird in 512-Bit-Blöcke unterteilt. Jeder Block wird durch eine Kompressionsfunktion verarbeitet, die den aktuellen Block und die Ausgabe des vorherigen Blocks als Eingaben nimmt. Die Ausgaben werden sequenziell verkettet, sodass der endgültige Hash von jedem Bit der gesamten Eingabenachricht abhängt.

Mitarbeiter-Offboarding: Leitfaden zur sicheren Zugriffsentziehung 2026

Das Deaktivieren eines SSO-Kontos entzieht nicht den Zugriff. API-Schlüssel, KI-Agenten-Anmeldedaten und geteilte Passwörter überleben es. Dieser Leitfaden behandelt das vollständige Offboarding-Playbook — von Stunde-Null-Auslösern bis zur NHI-Bereinigung.

Passwork BlogAlex Muntyan

Secrets-Rotation-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 Erstellung und Besitz bis zu sicherer Rotation, Notfallwiderruf und Audit-Nachweis.

Passwork BlogAlex Muntyan

Brute-Force-Angriffe 2026: Arten, Beispiele und Prävention

GPU-Cluster, KI-gestü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

Cuando se produce una brecha en una base de datos, la primera pregunta siempre es la misma: ¿están seguras las contraseñas hasheadas? La respuesta depende completamente de cómo se generaron esos hashes. SHA-256 en sí no se puede descifrar — es una función hash criptográfica unidireccional, no un algoritmo de cifrado. Pero «no se puede descifrar» no es lo mismo que «no se puede crackear».

Qué es SHA-256

SHA-256 (Secure Hash Algorithm de 256 bits) es una función hash criptográfica de la familia SHA-2, desarrollada por la NSA y publicada por el NIST en 2001 bajo FIPS 180-4. Toma una entrada de cualquier longitud y produce una salida fija de 256 bits (32 bytes) — el hash, o resumen. La salida siempre parece aleatoria, y la misma entrada siempre produce la misma salida.

SHA-256 no es un algoritmo de cifrado. No tiene clave, y su salida no puede revertirse. Su función es producir una huella digital única de un dato — no proteger ese dato para su recuperación posterior.

Tres propiedades definen su seguridad:

• Resistencia a la preimagen. Dado un hash, no se puede encontrar la entrada original.
• Resistencia a colisiones. No se pueden encontrar dos entradas diferentes que produzcan el mismo hash.
• Efecto avalancha. Un cambio de un solo bit en la entrada modifica aproximadamente la mitad de los bits de salida, haciendo el resultado completamente impredecible.

SHA-256 se utiliza en certificados TLS, firma de código, integridad de commits en Git, el mecanismo de prueba de trabajo de Bitcoin y (cuando se combina con una derivación de claves adecuada) almacenamiento de contraseñas. Es una de las primitivas criptográficas más ampliamente desplegadas en sistemas de producción actualmente.

Hash vs. cifrado: Por qué SHA-256 no se puede descifrar

SHA-256 es una función hash criptográfica — una transformación unidireccional. El cifrado es una operación bidireccional: se cifran datos con una clave y se descifran con una clave. El hashing no tiene clave ni camino de retorno. Dado un resumen SHA-256, no existe ninguna operación matemática que recupere la entrada original.

La propiedad que hace esto posible se llama resistencia a la preimagen: debe ser computacionalmente inviable encontrar cualquier entrada m tal que SHA256(m) = h para un hash dado h. Una propiedad relacionada, el efecto avalancha, significa que cambiar un solo bit en la entrada modifica aproximadamente la mitad de los bits de salida — haciendo imposible «trabajar hacia atrás» mediante pequeños ajustes.

La distinción es importante en la práctica. Si un desarrollador almacena contraseñas usando cifrado AES en lugar de hashing, una brecha de la clave de cifrado expone todas las contraseñas de la base de datos. Un hash no tiene clave que robar.

Cómo funciona el algoritmo SHA-256 (paso a paso)

SHA-256 está definido en NIST FIPS 180-4 y pertenece a la familia SHA-2. Procesa entradas de cualquier longitud y produce una salida determinista de 256 bits. La estructura central es la construcción Merkle-Damgård: el mensaje se divide en bloques de tamaño fijo, cada bloque se procesa a través de una función de compresión, y las salidas se encadenan.

Paso 1. Preprocesamiento y relleno

El mensaje de entrada se rellena para que su longitud total sea múltiplo de 512 bits. El relleno siempre comienza con un bit 1, seguido de suficientes bits 0, seguidos de una representación de 64 bits de la longitud del mensaje original. Este paso es obligatorio incluso si el mensaje ya encaja perfectamente — el algoritmo siempre debe saber dónde termina el mensaje.

Paso 2. Programación del mensaje

El mensaje rellenado se divide en bloques de 512 bits. Cada bloque se divide en dieciséis palabras de 32 bits. Esas dieciséis palabras se expanden luego en una programación de mensajes de 64 palabras usando una combinación de rotaciones a nivel de bits y operaciones XOR. Esta expansión asegura que cada bit de la entrada original influya en el paso de compresión.

Paso 3. La función de compresión

Aquí es donde ocurre el trabajo. SHA-256 mantiene ocho variables de trabajo de 32 bits (a hasta h), inicializadas con constantes derivadas de las partes fraccionarias de las raíces cuadradas de los primeros ocho números primos. A lo largo de 64 rondas, estas variables se actualizan usando operaciones AND, OR, XOR y NOT a nivel de bits, más suma modular. Dos funciones no lineales — Ch(e, f, g) y Maj(a, b, c) — introducen complejidad que hace opaca la relación entre entrada y salida. Después de las 64 rondas, las variables de trabajo se suman de nuevo a los valores iniciales de ese bloque.

Paso 4. Salida final

Después de procesar todos los bloques, las ocho variables de trabajo se concatenan para producir el resumen final de 256 bits. La misma entrada siempre produce la misma salida. Cualquier cambio en la entrada — incluso un solo carácter — produce un hash completamente diferente.

Si SHA-256 no se puede descifrar, ¿cómo lo crackean los hackers?

SHA-256 es matemáticamente sólido. El algoritmo en sí no tiene debilidades prácticas conocidas después de más de dos décadas de criptoanálisis. Lo que falla no es el algoritmo — es la forma en que se almacenan las contraseñas usándolo.

Ataques de fuerza bruta

Un ataque de fuerza bruta no revierte el hash. Adivina. El atacante hashea contraseñas candidatas (palabras de diccionario, patrones comunes, combinaciones de caracteres) y compara la salida con el hash robado. Si los hashes coinciden, la contraseña está encontrada. La velocidad de SHA-256 es el problema aquí: una sola GPU Nvidia RTX 4090 puede calcular aproximadamente 164 mil millones de hashes SHA-256 por segundo (Specops Software, 2025). A ese ritmo, una contraseña de ocho caracteres en minúsculas se crackea en segundos.

Ataques de tablas rainbow

Una tabla rainbow es una base de datos precalculada de mapeos hash-a-texto-plano. En lugar de hashear sobre la marcha, el atacante busca el hash robado en la tabla y lee la contraseña original. Las tablas para formatos de contraseña comunes pueden generarse con anticipación y reutilizarse en múltiples brechas. La resistencia a colisiones — la propiedad de que ninguna entrada debería producir el mismo hash — no es lo que explotan las tablas rainbow. Explotan el hecho de que las contraseñas comunes producen hashes predecibles y repetibles.

Ambos ataques comparten un único prerrequisito: el hash debe estar sin sal. Añada una sal, y ambos ataques se vuelven dramáticamente más costosos.

Por qué SHA-256 simple es malo para el almacenamiento de contraseñas

SHA-256 fue diseñado para ser rápido. Para sus usos previstos — verificar integridad de archivos, firmar certificados, asegurar transacciones blockchain — la velocidad es una característica. Para el almacenamiento de contraseñas, la velocidad es una vulnerabilidad.

El problema: SHA-256 es demasiado rápido

A 164 mil millones de hashes por segundo en hardware de consumo, un atacante puede agotar todo el espacio de contraseñas de ocho caracteres que contienen mayúsculas, minúsculas, dígitos y símbolos en menos de una hora. La guía de almacenamiento de contraseñas de OWASP es explícita: «Los algoritmos de hash rápidos como SHA-256 no son adecuados para el almacenamiento de contraseñas porque permiten a los atacantes realizar grandes cantidades de intentos rápidamente».

Solución 1: Salting

Una sal es una cadena única generada aleatoriamente que se añade a cada contraseña antes del hashing. SHA256("password") siempre produce el mismo hash. SHA256("password" + "x7kQ2mNp") produce uno completamente diferente — y cada usuario obtiene una sal diferente. Esto anula completamente las tablas rainbow: el atacante no puede precalcular hashes para entradas con sal sin conocer la sal de cada usuario. También significa que dos usuarios con la misma contraseña terminan con hashes diferentes en la base de datos.

Solución 2: Estiramiento de claves con PBKDF2

El salting anula las búsquedas precalculadas, pero no ralentiza los ataques de fuerza bruta. Eso requiere estiramiento de claves. PBKDF2 (Password-Based Key Derivation Function 2) aplica una función pseudoaleatoria — típicamente HMAC-SHA-256 — miles de veces en secuencia. Cada iteración toma tiempo. Los 164 mil millones de hashes por segundo del atacante se reducen a una fracción cuando cada «intento» requiere 600.000 iteraciones.

OWASP recomienda PBKDF2 con HMAC-SHA-256 y al menos 600.000 iteraciones para cumplimiento FIPS-140. Argon2id es la opción preferida donde no se requiere cumplimiento FIPS, ya que también añade resistencia de memoria.

SHA-256 simple vs. PBKDF2-HMAC-SHA256: Comparación de seguridad en almacenamiento de contraseñas

¿Es SHA-256 vulnerable a las computadoras cuánticas?

El algoritmo de Grover proporciona a una computadora cuántica una aceleración cuadrática en problemas de búsqueda no estructurada. Aplicado a SHA-256, reduce la seguridad efectiva de 2²⁵⁶ operaciones a 2¹²⁸ operaciones. Eso suena alarmante hasta que se considera la escala: 2¹²⁸ es aproximadamente 3,4×10³⁸. Una computadora cuántica funcionando a 10 mil millones de operaciones por segundo necesitaría aproximadamente 3,4×10²⁸ años para agotar la mitad del espacio de búsqueda — órdenes de magnitud más que la edad del universo.

El algoritmo de Shor, que rompe RSA y la criptografía de curva elíptica factorizando eficientemente números enteros grandes, no se aplica a las funciones hash. La seguridad de SHA-256 no se basa en la factorización de enteros.

El NIST está estandarizando activamente algoritmos post-cuánticos (FIPS 203, 204, 205 fueron finalizados en 2024), principalmente dirigidos a criptografía asimétrica. SHA-256 no está en la lista de reemplazo para el futuro previsible. La amenaza práctica a SHA-256 por la computación cuántica sigue siendo teórica.

Cómo los gestores de contraseñas empresariales usan la criptografía de forma segura

Los gestores de contraseñas empresariales que siguen principios de conocimiento cero aplican los mismos bloques de construcción criptográficos cubiertos en este artículo (SHA-256, PBKDF2, HMAC, AES-256) pero los combinan en una arquitectura por capas donde el servidor nunca tiene datos en texto plano ni las claves para descifrarlos. La garantía de seguridad proviene del diseño, no de confiar en el servidor.

El modelo de cifrado de dos niveles de Passwork

Saber que SHA-256 simple es insuficiente para el almacenamiento de contraseñas es una cosa. Implementar la alternativa correcta en toda una empresa es otra. Aquí es donde la arquitectura de la herramienta importa tanto como el algoritmo.

Passwork está construido sobre una arquitectura de conocimiento cero: el servidor nunca tiene suficiente información para descifrar los datos del usuario. La contraseña maestra nunca abandona el dispositivo del usuario. Todas las claves criptográficas se generan del lado del cliente. El servidor almacena solo datos cifrados y claves cifradas — el descifrado solo es posible en el cliente.

La cadena de cifrado funciona de la siguiente manera, como se documenta en la descripción general de criptografía de Passwork:

1. Contraseña maestra (introducida por el usuario) → PBKDF2 con SHA-256, 300.000 iteraciones
2. Clave maestra (512 bits) → AES-256-CBC
3. Clave privada RSA (2048 bits, RSA-OAEP)
4. Clave de bóveda (256 bits) → AES-256-CBC
5. Clave de registro (256 bits) → AES-256-CBC
6. Datos de registro (contraseñas, secretos, archivos — cifrados en reposo)

En el lado del servidor, una capa separada AES-256-CFB cifra la base de datos de forma independiente. Cada registro está doblemente cifrado: una vez por el cliente antes de que abandone el dispositivo, una vez por el servidor antes de escribirse en disco.

PBKDF2 a 300.000 iteraciones del lado del cliente se alinea con las recomendaciones del NIST (≥310.000 para SHA-256) y supera el mínimo de OWASP para la mayoría de los contextos de implementación. El PBKDF2 del lado del servidor se ejecuta a 600.000 iteraciones — cumpliendo directamente con el umbral FIPS-140.

Esta arquitectura significa que una brecha de base de datos no produce nada utilizable. Un atacante que exfiltra la base de datos obtiene blobs cifrados con AES-256 derivados de claves que nunca se almacenaron en el servidor.

Conclusión

SHA-256 es teóricamente irrompible. El algoritmo ha sobrevivido más de dos décadas de criptoanálisis sin un ataque práctico. Pero el algoritmo solo es tan fuerte como su implementación. Almacene contraseñas como hashes SHA-256 simples, y una sola GPU puede probar miles de millones de candidatos por segundo. Añada una sal y aplique PBKDF2 con suficientes iteraciones, y el mismo hardware se vuelve inútil contra su base de datos.

La brecha entre «SHA-256 es seguro» y «nuestras contraseñas son seguras» se llena con una implementación correcta — salting, estiramiento de claves y una arquitectura de conocimiento cero que asegure que el servidor nunca tenga las claves necesarias para descifrar los datos del usuario.

Si su equipo gestiona credenciales corporativas, Passwork las protege mediante arquitectura de conocimiento cero, cifrado AES-256 del lado del cliente y estiramiento de claves PBKDF2 a 300.000 iteraciones — de modo que un compromiso del servidor no expone nada utilizable. Passwork está disponible tanto como implementación autoalojada para organizaciones que requieren control total de la infraestructura, como solución en la nube para equipos que desean las mismas garantías criptográficas sin gestionar sus propios servidores.

Preguntas frecuentes: SHA-256 explicado

¿Se puede descifrar SHA-256?

No. SHA-256 es una función hash criptográfica unidireccional. No hay clave, no hay algoritmo inverso, y no hay operación matemática que recupere la entrada original de un hash. Lo que los atacantes pueden hacer es adivinar — hasheando contraseñas candidatas y comparando la salida. Eso es cracking, no descifrado, y solo funciona contra hashes débiles o sin sal.

¿Cuál es la diferencia entre el hashing SHA-256 y el cifrado?

El cifrado es reversible con la clave correcta. El hashing no es reversible bajo ninguna circunstancia. SHA-256 toma una entrada de cualquier longitud y produce una salida fija de 256 bits. La misma entrada siempre produce la misma salida, pero el proceso no puede ejecutarse en reversa. El cifrado preserva la capacidad de recuperar los datos originales; el hashing los destruye deliberadamente.

¿Qué es el efecto avalancha en SHA-256?

El efecto avalancha significa que un cambio de un solo bit en la entrada modifica aproximadamente la mitad de los bits de salida. Cambie un carácter en una contraseña, y el hash SHA-256 resultante parece completamente no relacionado con el original. Esta propiedad impide que los atacantes usen conocimiento parcial de una entrada para reducir el espacio de búsqueda del hash.

¿Qué es PBKDF2 y por qué importa para la seguridad de contraseñas?

PBKDF2 (Password-Based Key Derivation Function 2) aplica una función pseudoaleatoria — típicamente HMAC-SHA-256 — iterativamente a una contraseña y sal. Cada iteración añade coste computacional. A 600.000 iteraciones, el tiempo requerido por intento aumenta por un factor de 600.000 comparado con un solo hash SHA-256. Esto hace que los ataques de fuerza bruta contra contraseñas almacenadas correctamente sean impracticables incluso con hardware a escala de GPU.

¿Es SHA-256 vulnerable a ataques de computación cuántica?

No prácticamente. El algoritmo de Grover reduce la seguridad efectiva de SHA-256 de 2²⁵⁶ a 2¹²⁸ operaciones. A 2¹²⁸, incluso una hipotética computadora cuántica funcionando a 10 mil millones de operaciones por segundo requeriría más tiempo que la edad del universo para agotar el espacio de búsqueda. El esfuerzo de estandarización de criptografía post-cuántica del NIST se dirige a algoritmos asimétricos, no a SHA-256.

¿Qué es la construcción Merkle-Damgård?

La construcción Merkle-Damgård es el marco estructural subyacente a SHA-256. El mensaje de entrada se divide en bloques de 512 bits. Cada bloque se procesa a través de una función de compresión que toma el bloque actual y la salida del bloque anterior como entradas. Las salidas se encadenan secuencialmente, de modo que el hash final depende de cada bit de todo el mensaje de entrada.

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

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

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

When a database is breached, the first question is always the same: are the hashed passwords safe? The answer depends entirely on how those hashes were generated. SHA-256 itself cannot be decrypted — it is a one-way cryptographic hash function, not an encryption algorithm. But "cannot be decrypted" is not the same as "cannot be cracked."

What is SHA-256

SHA-256 (Secure Hash Algorithm 256-bit) is a cryptographic hash function from the SHA-2 family, developed by the NSA and published by NIST in 2001 under FIPS 180-4. It takes an input of any length and produces a fixed 256-bit (32-byte) output — the hash, or digest. The output always looks random, and the same input always produces the same output.

SHA-256 is not an encryption algorithm. It has no key, and its output cannot be reversed. Its job is to produce a unique fingerprint of a piece of data — not to protect that data for later retrieval.

Three properties define its security:

• Preimage resistance. Given a hash, you cannot find the original input.
• Collision resistance. You cannot find two different inputs that produce the same hash.
• Avalanche effect. A single-bit change in the input flips roughly half the output bits, making the result completely unpredictable.

SHA-256 is used in TLS certificates, code signing, Git commit integrity, Bitcoin's proof-of-work mechanism, and (when combined with proper key derivation) password storage. It is one of the most widely deployed cryptographic primitives in production systems today.

Hashing vs. encryption: Why SHA-256 cannot be decrypted

SHA-256 is a cryptographic hash function — a one-way transformation. Encryption is a two-way operation: you encrypt data with a key, and you decrypt it with a key. Hashing has no key and no reverse path. Given a SHA-256 digest, there is no mathematical operation that recovers the original input.

The property that makes this possible is called preimage resistance: it must be computationally infeasible to find any input m such that SHA256(m) = h for a given hash h. A related property, the avalanche effect, means that changing a single bit in the input flips roughly half of the output bits — making it impossible to "work backwards" by making small adjustments.

The distinction matters in practice. If a developer stores passwords using AES encryption rather than hashing, a breach of the encryption key exposes every password in the database. A hash has no key to steal.

How the SHA-256 algorithm works (step-by-step)

SHA-256 is defined in NIST FIPS 180-4 and belongs to the SHA-2 family. It processes input of any length and produces a deterministic 256-bit output. The core structure is the Merkle-Damgård construction: the message is split into fixed-size blocks, each block is processed through a compression function, and the outputs are chained together.

Step 1. Preprocessing and padding

The input message is padded so its total length is a multiple of 512 bits. Padding always begins with a 1 bit, followed by enough 0 bits, followed by a 64-bit representation of the original message length. This step is mandatory even if the message already fits neatly — the algorithm must always know where the message ends.

Step 2. Message scheduling

The padded message is parsed into 512-bit blocks. Each block is divided into sixteen 32-bit words. Those sixteen words are then expanded into a 64-word message schedule using a mix of bitwise rotations and XOR operations. This expansion ensures that every bit of the original input influences the compression step.

Step 3. The compression function

This is where the work happens. SHA-256 maintains eight 32-bit working variables (a through h), initialized to constants derived from the fractional parts of the square roots of the first eight prime numbers. Over 64 rounds, these variables are updated using bitwise AND, OR, XOR, and NOT operations, plus modular addition. Two non-linear functions — Ch(e, f, g) and Maj(a, b, c) — introduce complexity that makes the relationship between input and output opaque. After all 64 rounds, the working variables are added back to the initial values for that block.

Step 4. Final output

After all blocks are processed, the eight working variables are concatenated to produce the final 256-bit digest. The same input always produces the same output. Any change to the input — even a single character — produces a completely different hash.

If SHA-256 can't be decrypted, how do hackers crack it?

SHA-256 is mathematically sound. The algorithm itself has no known practical weaknesses after more than two decades of cryptanalysis. What fails is not the algorithm — it is the way passwords are stored using it.

Brute-force attacks

A brute-force attack does not reverse the hash. It guesses. The attacker hashes candidate passwords (dictionary words, common patterns, character combinations) and compares the output against the stolen hash. If the hashes match, the password is found. The speed of SHA-256 is the problem here: a single Nvidia RTX 4090 GPU can calculate approximately 164 billion SHA-256 hashes per second (Specops Software, 2025). At that rate, an eight-character lowercase password is cracked in seconds.

Rainbow table attacks

A rainbow table is a precomputed database of hash-to-plaintext mappings. Rather than hashing on the fly, the attacker looks up the stolen hash in the table and reads off the original password. Tables for common password formats can be generated in advance and reused across multiple breaches. Collision resistance — the property that no two inputs should produce the same hash — is not what rainbow tables exploit. They exploit the fact that common passwords produce predictable, repeatable hashes.

Both attacks share a single prerequisite: the hash must be unsalted. Add a salt, and both attacks become dramatically more expensive.

Why plain SHA-256 is bad for password storage

SHA-256 was designed to be fast. For its intended uses — verifying file integrity, signing certificates, securing blockchain transactions — speed is a feature. For password storage, speed is a liability.

The problem: SHA-256 is too fast

At 164 billion hashes per second on consumer hardware, an attacker can exhaust the entire space of eight-character passwords containing uppercase, lowercase, digits, and symbols in under an hour. OWASP's Password Storage Cheat Sheet is explicit: "Fast hashing algorithms such as SHA-256 are not suitable for password storage because they allow attackers to perform large numbers of guesses quickly."

Solution 1: Salting

A salt is a unique, randomly generated string appended to each password before hashing. SHA256("password") always produces the same hash. SHA256("password" + "x7kQ2mNp") produces a completely different one — and every user gets a different salt. This defeats rainbow tables entirely: the attacker cannot precompute hashes for salted inputs without knowing each user's salt. It also means two users with the same password end up with different hashes in the database.

Solution 2: Key stretching with PBKDF2

Salting defeats precomputed lookups, but it does not slow down brute-force attacks. That requires key stretching. PBKDF2 (Password-Based Key Derivation Function 2) applies a pseudorandom function — typically HMAC-SHA-256 — thousands of times in sequence. Each iteration takes time. The attacker's 164 billion hashes per second drops to a fraction of that when each "guess" requires 600,000 iterations.

OWASP recommends PBKDF2 with HMAC-SHA-256 and at least 600,000 iterations for FIPS-140 compliance. Argon2id is the preferred choice where FIPS compliance is not required, as it also adds memory hardness.

Plain SHA-256 vs. PBKDF2-HMAC-SHA256: password storage security comparison

Is SHA-256 vulnerable to quantum computers?

Grover's algorithm gives a quantum computer a quadratic speedup on unstructured search problems. Applied to SHA-256, it reduces the effective security from 2²⁵⁶ operations to 2¹²⁸ operations. That sounds alarming until you consider the scale: 2¹²⁸ is approximately 3.4×10³⁸. A quantum computer running at 10 billion operations per second would need roughly 3.4×10²⁸ years to exhaust half the search space — orders of magnitude longer than the age of the universe.

Shor's algorithm, which breaks RSA and elliptic-curve cryptography by factoring large integers efficiently, does not apply to hash functions. SHA-256's security is not based on integer factorization.

NIST is actively standardizing post-quantum algorithms (FIPS 203, 204, 205 were finalized in 2024), primarily targeting asymmetric cryptography. SHA-256 is not on the replacement list for the foreseeable future. The practical threat to SHA-256 from quantum computing remains theoretical.

How enterprise password managers use cryptography securely

Enterprise password managers that follow zero-knowledge principles apply the same cryptographic building blocks covered in this article (SHA-256, PBKDF2, HMAC, AES-256) but combine them into a layered architecture where the server never holds plaintext data or the keys to decrypt it. The security guarantee comes from the design, not from trusting the server.

The Passwork two-level encryption model

Knowing that plain SHA-256 is insufficient for password storage is one thing. Implementing the correct alternative across an enterprise is another. This is where the architecture of the tool matters as much as the algorithm.

Passwork is built on a zero-knowledge architecture: the server never holds enough information to decrypt user data. The master password never leaves the user's device. All cryptographic keys are generated client-side. The server stores only encrypted data and encrypted keys — decryption is only possible on the client.

The encryption chain works as follows, as documented in Passwork's cryptography overview:

1. Master password (entered by the user) → PBKDF2 with SHA-256, 300,000 iterations
2. Master key (512 bits) → AES-256-CBC
3. Private RSA key (2048 bits, RSA-OAEP)
4. Vault key (256 bits) → AES-256-CBC
5. Record key (256 bits) → AES-256-CBC
6. Record data (passwords, secrets, files — encrypted at rest)

On the server side, a separate AES-256-CFB layer encrypts the database independently. Every record is double-encrypted: once by the client before it leaves the device, once by the server before it is written to disk.

PBKDF2 at 300,000 client-side iterations aligns with NIST's recommendations (≥310,000 for SHA-256) and exceeds the OWASP minimum for most deployment contexts. The server-side PBKDF2 runs at 600,000 iterations — meeting the FIPS-140 threshold directly.

This architecture means that a database breach yields nothing actionable. An attacker who exfiltrates the database gets AES-256-encrypted blobs derived from keys that were never stored on the server.

Conclusion

SHA-256 is theoretically unbreakable. The algorithm has survived over two decades of cryptanalysis without a practical attack. But the algorithm is only as strong as its implementation. Store passwords as plain SHA-256 hashes, and a single GPU can test billions of candidates per second. Add a salt and apply PBKDF2 with sufficient iterations, and the same hardware becomes useless against your database.

The gap between "SHA-256 is secure" and "our passwords are secure" is filled by correct implementation — salting, key stretching, and a zero-knowledge architecture that ensures the server never holds the keys needed to decrypt user data.

If your team manages corporate credentials, Passwork protects them through zero-knowledge architecture, client-side AES-256 encryption, and PBKDF2 key stretching at 300,000 iterations — so a server compromise exposes nothing actionable. Passwork is available both as a self-hosted deployment for organizations that require full infrastructure control, and as a cloud solution for teams that want the same cryptographic guarantees without managing their own servers.

FAQ: SHA-256 explained

Can you decrypt SHA-256?

No. SHA-256 is a one-way cryptographic hash function. There is no key, no reverse algorithm, and no mathematical operation that recovers the original input from a hash. What attackers can do is guess — by hashing candidate passwords and comparing the output. That is cracking, not decryption, and it only works against weak or unsalted hashes.

What is the difference between SHA-256 hashing and encryption?

Encryption is reversible with the correct key. Hashing is not reversible under any circumstances. SHA-256 takes an input of any length and produces a fixed 256-bit output. The same input always produces the same output, but the process cannot be run in reverse. Encryption preserves the ability to recover the original data; hashing deliberately destroys it.

What is the avalanche effect in SHA-256?

The avalanche effect means that a single-bit change in the input flips approximately half of the output bits. Change one character in a password, and the resulting SHA-256 hash looks completely unrelated to the original. This property prevents attackers from using partial knowledge of an input to narrow down the hash search space.

What is PBKDF2 and why does it matter for password security?

PBKDF2 (Password-Based Key Derivation Function 2) applies a pseudorandom function — typically HMAC-SHA-256 — iteratively to a password and salt. Each iteration adds computational cost. At 600,000 iterations, the time required per guess increases by a factor of 600,000 compared to a single SHA-256 hash. This makes brute-force attacks against properly stored passwords impractical even with GPU-scale hardware.

Is SHA-256 vulnerable to quantum computing attacks?

Not practically. Grover's algorithm reduces SHA-256's effective security from 2²⁵⁶ to 2¹²⁸ operations. At 2¹²⁸, even a hypothetical quantum computer running at 10 billion operations per second would require more time than the age of the universe to exhaust the search space. NIST's post-quantum cryptography standardization effort targets asymmetric algorithms, not SHA-256.

What is the Merkle-Damgård construction?

The Merkle-Damgård construction is the structural framework underlying SHA-256. The input message is divided into 512-bit blocks. Each block is processed through a compression function that takes the current block and the output of the previous block as inputs. The outputs are chained sequentially, so the final hash depends on every bit of the entire input message.

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

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

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

AES-256-Verschlüsselung ist eine symmetrische Blockchiffre, die einen 256-Bit-Schlüssel verwendet, um Daten in 14 Transformationsrunden zu verschlüsseln. Kein klassischer oder Quantencomputer kann sie innerhalb eines praktisch relevanten Zeitrahmens per Brute-Force knacken. Dennoch erleiden Organisationen, die AES-256 verwenden, weiterhin katastrophale Datenschutzverletzungen — weil Angreifer selten versuchen, die Chiffre zu brechen. Sie brechen die Systeme drumherum.

Diese Unterscheidung ist 2026 wichtiger denn je. KI-gesteuerte Angriffe beschleunigen den Diebstahl von Anmeldedaten und die Kompromittierung von Endpunkten. Die „Harvest Now, Decrypt Later"-Strategie bedeutet, dass Gegner heute verschlüsselte Daten horten und auf zukünftige Entschlüsselungsfähigkeiten setzen. Und NIST hat seine ersten Post-Quanten-Kryptografiestandards finalisiert, was berechtigte Fragen aufwirft, ob AES-256 noch in Ihre Sicherheitsarchitektur gehört.

Die kurze Antwort: ja. Die längere Antwort erfordert ein genaues Verständnis dessen, wovor AES-256 schützt, wovor nicht, und wie man es so einsetzt, dass die theoretische Stärke des Algorithmus in tatsächliche Sicherheit übersetzt wird.

Wichtigste Erkenntnisse

• AES-256 hat keine praktische Schwachstelle. Kein klassischer oder Quantencomputer kann einen 256-Bit-Schlüssel innerhalb eines machbaren Zeitrahmens per Brute-Force knacken. Der Algorithmus selbst ist nicht das Risiko.
• Grovers Algorithmus halbiert die Sicherheit von AES-256, eliminiert sie aber nicht. Ein Quanten-Angreifer reduziert die effektive Sicherheit auf 128 Bit — immer noch unknackbar durch jede bekannte oder prognostizierte Hardware.
• Die eigentliche Bedrohung ist Harvest Now, Decrypt Later (HNDL), nicht der Q-Day. Gegner archivieren heute verschlüsselte Daten. Die Migration des asymmetrischen Schlüsselaustauschs zu Post-Quanten-Algorithmen ist eine gegenwärtige Priorität, keine zukünftige.
• AES-256-GCM ist der richtige Modus für neue Implementierungen. CBC bietet nur Vertraulichkeit. GCM fügt integrierte Authentifizierung hinzu und ist in TLS 1.3 obligatorisch.
• 62 % der Datenschutzverletzungen betreffen den menschlichen Faktor. Angreifer umgehen die Verschlüsselung durch gestohlene Anmeldedaten, kompromittierte Endpunkte und schlechtes Schlüsselmanagement — nicht durch das Brechen der Chiffre.
• Schlüsselmanagement ist das schwächste Glied. Hardcodierte Schlüssel, Schlüssel, die neben den zu schützenden Daten gespeichert werden, und Schlüssel, die nie rotiert werden, sind gefährlicher als jeder bekannte kryptoanalytische Angriff.
• Zero-Knowledge-Architektur eliminiert das serverseitige Risiko. Wenn der Server niemals Klartext oder Entschlüsselungsschlüssel besitzt, liefert eine vollständige Serverkompromittierung nur nutzlosen Chiffretext.
• AES-256 erfüllt HIPAA, DSGVO und PCI DSS. Compliance erfordert eine korrekte Implementierung — Verschlüsselung im Ruhezustand, während der Übertragung und dokumentiertes Schlüsselmanagement — nicht nur das Vorhandensein des Algorithmus.

Was ist AES-256?

AES-256 (Advanced Encryption Standard mit einem 256-Bit-Schlüssel) ist eine symmetrische Blockchiffre, die in NIST FIPS 197 standardisiert ist. Sie verschlüsselt Daten in 128-Bit-Blöcken unter Verwendung eines 256-Bit-Schlüssels über 14 Transformationsrunden. Derselbe Schlüssel verschlüsselt und entschlüsselt die Daten. Kein bekannter klassischer oder Quantenangriff kann sie innerhalb eines praktisch relevanten Zeitrahmens brechen.

AES-256 ist der Verschlüsselungsstandard, der in der gesamten US-Bundesregierung (einschließlich NSA-klassifizierter Systeme), TLS 1.3, bei der Festplattenverschlüsselung auf allen großen Betriebssystemen und bei Enterprise-Credential-Management-Tools verwendet wird. Wenn ein Anbieter sagt, sein Produkt verwende „Verschlüsselung auf Militärniveau", meint er fast immer AES-256.

Woher der Name stammt

Der AES-Teil bezieht sich auf den Algorithmus selbst — ein Substitutions-Permutations-Netzwerk, das von Joan Daemen und Vincent Rijmen entworfen wurde (ursprünglich Rijndael genannt) und 2001 von NIST nach einem fünfjährigen öffentlichen Wettbewerb ausgewählt wurde. Die „256" bezieht sich auf die Schlüssellänge in Bit. AES gibt es auch in 128-Bit- und 192-Bit-Varianten; die 256-Bit-Version verwendet 14 Transformationsrunden statt 10 (AES-128) oder 12 (AES-192). Mehr Runden bedeuten eine größere Sicherheitsmarge.

Was der 256-Bit-Schlüssel tatsächlich bedeutet

Ein 256-Bit-Schlüssel hat 2²⁵⁶ mögliche Werte — ungefähr 1,16×10⁷⁷. Um das physisch einzuordnen: Wenn jedes Atom im beobachtbaren Universum ein Computer wäre, der eine Milliarde Milliarden Schlüsselversuche pro Sekunde durchführt, würde das Durchprobieren des AES-256-Schlüsselraums immer noch um viele Größenordnungen länger dauern als das Alter des Universums. Deshalb beschreiben Kryptografen AES-256 als praktisch nicht durch Brute-Force angreifbar.

Die Schlüssellänge bestimmt auch die Quantenresistenz. Grovers Algorithmus — der bekannteste Quantenangriff auf symmetrische Chiffren — bietet eine quadratische Beschleunigung, die die Schlüssellänge effektiv halbiert. Gegen AES-256 reduziert diese Reduzierung die effektive Sicherheit auf 128 Bit. AES-128-Sicherheit ist selbst durch keine bekannte oder prognostizierte Hardware zu brechen. Die eigene Post-Quanten-Kryptografie-Dokumentation des NIST bestätigt, dass AES-256 gegen Quanten-Angreifer sicher bleibt.

AES-256 vs. AES-128: Ist der Unterschied bedeutsam?

Für die meisten Enterprise-Anwendungsfälle sind beide rechnerisch unknackbar. Die praktischen Gründe, AES-256 zu bevorzugen, sind:

• Regulatorische Anforderungen. NSAs CNSA 2.0 (2022, aktualisiert 2025) schreibt AES-256 für alle National Security Systems auf allen Klassifizierungsstufen vor. PCI DSS akzeptiert AES-128 als Minimum, aber AES-256 als empfohlenen Standard.
• Quantenmarge. AES-256 behält nach Grover 128-Bit-Sicherheit; AES-128 fällt auf 64 Bit, was sich der Machbarkeit für einen ausreichend fortgeschrittenen Quanten-Angreifer nähert.
• Langlebige Daten. Wenn die Daten, die Sie heute verschlüsseln, 20+ Jahre vertraulich bleiben müssen, ist AES-256 die konservative Wahl.

Der Leistungsunterschied zwischen AES-128 und AES-256 ist auf moderner Hardware mit AES-NI-Beschleunigung vernachlässigbar — typischerweise unter 20 % Durchsatzunterschied. Es gibt keinen praktischen Grund, AES-128 für neue Implementierungen zu wählen.

Wie AES-256 in eine breitere Sicherheitsarchitektur passt

AES-256 ist eine symmetrische Chiffre. Sie verarbeitet Massendatenverschlüsselung effizient, erfordert jedoch, dass beide Parteien denselben geheimen Schlüssel teilen — was ein Schlüsselverteilungsproblem schafft. In der Praxis wird asymmetrische Kryptografie (RSA, ECC oder Post-Quanten-Algorithmen wie ML-KEM aus FIPS 203) verwendet, um den AES-Schlüssel sicher auszutauschen, wonach AES-256 die eigentlichen Daten verarbeitet. Genau so funktioniert TLS 1.3: asymmetrischer Handshake, symmetrische Datenübertragung.

Die Chiffre ist nur so stark wie das System drumherum. AES-256 schützt Daten im Ruhezustand und während der Übertragung. Es schützt nicht gegen einen gestohlenen Schlüssel, einen kompromittierten Endpunkt oder einen autorisierten Benutzer mit böswilliger Absicht. Das ist keine Schwäche des Algorithmus — es ist die Grenze dessen, was jede Chiffre leisten kann.

Wie AES-256 funktioniert: Die Mathematik hinter der Chiffre

Die Chiffre verarbeitet Daten in festen 128-Bit-Blöcken. Jeder Block durchläuft 14 sequenzielle Transformationsrunden — mehr Runden als AES-128 (10) oder AES-192 (12). Jede Runde wendet vier Operationen an: Substitution, Zeilenverschiebung, Spaltenmischung und Schlüsseladdition. Das Kippen eines einzelnen Eingabebits ändert bis zum Ende der ersten Runde etwa die Hälfte der Ausgabebits.

Die 14 Transformationsrunden

AES-256 wendet 14 Runden von vier Operationen auf jeden 128-Bit-Datenblock an. Jede Runde besteht aus:

1. SubBytes — jedes Byte wird über eine feste Substitutionstabelle (S-Box) ersetzt, was Nichtlinearität einführt
2. ShiftRows — Zeilen der 4×4-Zustandsmatrix werden zyklisch verschoben, was Diffusion bewirkt
3. MixColumns — Spalten werden in einem Galois-Feld multipliziert, was die Daten weiter über Bytes hinweg mischt
4. AddRoundKey — der Rundenschlüssel (abgeleitet vom ursprünglichen 256-Bit-Schlüssel über Schlüsselexpansion) wird mit dem Zustand XOR-verknüpft

Die letzte Runde lässt MixColumns aus. Dieses Substitutions-Permutations-Netzwerk (SPN)-Design bedeutet, dass das Kippen eines einzelnen Eingabebits etwa die Hälfte der Ausgabebits ändert — der Lawineneffekt. Nach 14 Runden ist die Beziehung zwischen Klartext und Chiffretext ohne den Schlüssel rechnerisch nicht umkehrbar.

AES-GCM vs. AES-CBC: Warum der Modus genauso wichtig ist wie die Schlüssellänge

Die Chiffre selbst ist nur ein Teil der Geschichte. Wie Sie sie verwenden — der Betriebsmodus — bestimmt, ob Ihre Implementierung tatsächlich sicher ist.

AES-256-GCM ist ein Authenticated Encryption with Associated Data (AEAD)-Modus. Er verschlüsselt gleichzeitig die Daten und erzeugt einen Message Authentication Code (MAC), der sowohl Vertraulichkeit als auch Integrität in einer einzigen Operation garantiert. Wenn ein Angreifer den Chiffretext manipuliert, schlägt die Entschlüsselung fehl — der MAC wird nicht verifiziert.

AES-256-CBC bietet nur Vertraulichkeit. Ohne einen separaten MAC (zum Beispiel über HMAC-SHA256) ist eine CBC-verschlüsselte Nachricht anfällig für Padding-Oracle-Angriffe und Bit-Flipping. CBC erfordert auch sequenzielle Verarbeitung, was die Leistung auf moderner Multi-Core-Hardware einschränkt.

Für neue Implementierungen im Jahr 2026 ist AES-256-GCM die richtige Wahl. TLS 1.3 hat CBC-Cipher-Suites aus genau diesem Grund vollständig entfernt. Der einzige praktische Vorbehalt: GCM ist katastrophal gebrochen, wenn eine Nonce (Initialisierungsvektor) mit demselben Schlüssel wiederverwendet wird. Ihre Implementierung muss Nonce-Eindeutigkeit garantieren — typischerweise über einen kryptografisch sicheren Zufallszahlengenerator oder einen Zähler.

Quantencomputing und AES-256: Risiko von Rauschen trennen

Die Quantencomputer-Bedrohung für Verschlüsselung ist real, aber sie ist nicht einheitlich. Zu verstehen, welche Algorithmen verwundbar sind und in welchem Maße, ist essenziell für fundierte architektonische Entscheidungen heute.

Quantencomputer bedrohen asymmetrische Kryptografie (RSA, ECC, Diffie-Hellman) durch Shors Algorithmus, der große Zahlen faktorisieren und diskrete Logarithmusprobleme in polynomieller Zeit lösen kann. Ein ausreichend leistungsfähiger Quantencomputer, der Shors Algorithmus ausführt, würde RSA-2048 vollständig brechen. Dies ist die echte Krise, die die Post-Quanten-Kryptografie (PQC)-Standardisierungsarbeit des NIST antreibt, die FIPS 203, 204 und 205 im Jahr 2024 finalisiert hat.

Symmetrische Verschlüsselung steht einem anderen Algorithmus und einer anderen Bedrohungsstufe gegenüber.

Was Grovers Algorithmus tatsächlich mit AES-256 macht

Grovers Algorithmus ist die Quantenbedrohung für symmetrische Verschlüsselung. Er bietet eine quadratische Beschleunigung für unstrukturierte Suchprobleme: Wo ein klassischer Computer N Operationen benötigt, um einen Schlüsselraum zu durchsuchen, benötigt ein Quantencomputer mit Grovers Algorithmus ungefähr die Quadratwurzel von N. Auf AES-256 angewendet, halbiert dies effektiv die Schlüssellänge aus Sicherheitsperspektive — ein 256-Bit-Schlüssel bietet gegen einen Quanten-Angreifer etwa 128 Bit Sicherheit.

128-Bit-Sicherheit ist immer noch unknackbar. Konkret ausgedrückt: Ein klassischer Angriff auf AES-128 erfordert etwa 2¹²⁸ Operationen. Selbst wenn Sie eine Milliarde Milliarden (10¹⁸) Operationen pro Sekunde durchführen könnten, würde das Durchprobieren dieses Schlüsselraums länger dauern als das Alter des Universums. Grovers Algorithmus reduziert AES-256 auf dieses Niveau — er bricht es nicht. Die PQC-FAQ des NIST bestätigt ausdrücklich, dass AES mit 128-, 192- oder 256-Bit-Schlüsseln gegen Quantenangriffe sicher ist.

Die CNSA 2.0-Empfehlung der NSA (2022, aktualisiert 2025) schreibt AES-256 für alle National Security Systems auf allen Klassifizierungsstufen, einschließlich Top Secret, mit einer Übergangsfrist bis 2035 vor. Die Tatsache, dass die NSA AES-256 nicht ersetzt (nur die asymmetrischen Algorithmen), ist das klarste mögliche Signal über seine Quantenresistenz.

Harvest Now, Decrypt Later (HNDL): Die Bedrohung, die heute existiert

Der Q-Day (der Zeitpunkt, an dem ein kryptoanalytisch relevanter Quantencomputer existiert) wird von den meisten Forschern auf 10–20 Jahre geschätzt, obwohl die Zeitpläne wirklich unsicher sind. Die unmittelbarere Bedrohung ist HNDL: Nationalstaatliche Akteure und ausgeklügelte kriminelle Gruppen fangen heute verschlüsselten Datenverkehr ab und archivieren ihn, mit der Absicht, ihn zu entschlüsseln, sobald Quantenhardware ausgereift ist.

Für Daten mit einem langen Sensibilitätshorizont — klassifizierte Regierungskommunikation, geistiges Eigentum, Krankenakten, langfristige Finanzdaten — ist HNDL ein gegenwärtiges operatives Risiko, kein zukünftiges Hypothetisches. Die Reaktion besteht darin, asymmetrische Schlüsselaustauschprotokolle jetzt auf Post-Quanten-Algorithmen zu migrieren, während AES-256 weiterhin für symmetrische Verschlüsselung verwendet wird.

Wenn AES-256 unknackbar ist, warum passieren dann immer noch Datenschutzverletzungen?

AES-256-Verschlüsselung ist mathematisch solide. Die Verletzungen passieren überall sonst. Der 2026 Data Breach Investigations Report von Verizon stellte fest, dass der menschliche Faktor bei 62 % der Verletzungen präsent war — gestohlene Anmeldedaten, Privilegienmissbrauch, Social Engineering. Angreifer brechen nicht die Chiffre. Sie stehlen den Schlüssel, kompromittieren den Endpunkt oder nutzen die Person aus, die das Passwort hält.

Der 2026 DBIR markiert auch einen strukturellen Wandel: Zum ersten Mal in den 19 Jahren der Berichtsveröffentlichung hat die Ausnutzung von Schwachstellen gestohlene Anmeldedaten als Top-Erstzugriffsvektor überholt und macht 31 % aller Verletzungen aus, gegenüber 20 % im Vorjahr. KI beschleunigt dies — Bedrohungsakteure nutzen sie jetzt, um das Fenster zwischen Schwachstellenoffenlegung und aktiver Ausnutzung von Monaten auf Stunden zu verkürzen.

Der 2025 Cost of a Data Breach Report von IBM beziffert die finanziellen Auswirkungen dieser Versäumnisse auf durchschnittlich 4,44 Millionen Dollar pro Vorfall. Organisationen mit hohem Niveau an Shadow AI (Mitarbeiter, die nicht genehmigte KI-Tools auf Firmengeräten nutzen) zahlten zusätzliche 670.000 Dollar pro Verletzung. Der 2026 DBIR fügt Kontext hinzu: Shadow AI ist jetzt die dritthäufigste nicht-böswillige Insider-Datenleckage-Aktivität, wobei die regelmäßige KI-Tool-Nutzung unter Mitarbeitern innerhalb eines Jahres von 15 % auf 45 % gestiegen ist.

Diese Zahlen rahmen das eigentliche Problem: Verschlüsselung schützt Daten im Ruhezustand und während der Übertragung, aber sie kann nicht gegen einen autorisierten Benutzer schützen, der etwas Unautorisiertes tut, eine Schwachstelle, die acht Monate lang ungepatcht bleibt, oder einen Endpunkt, der bereits kompromittiert ist.

Die sechs Lücken, die Verschlüsselung umgehen

Hier ist ein strukturierter Ansatz, um zu verstehen, wo AES-256 in der Praxis versagt — nicht weil der Algorithmus schwach ist, sondern weil die umgebende Architektur es ist.

Das „Verschlüsselung ist nicht genug"-Lückenmodell:

1. Schlüsselmanagement-Versäumnisse. Hardcodierte Verschlüsselungsschlüssel im Quellcode, Schlüssel, die neben den zu schützenden Daten gespeichert werden, Schlüssel, die nie rotiert werden. Wenn der Schlüssel kompromittiert ist, ist die Verschlüsselung wertlos. Hardware Security Modules (HSMs) und Schlüsselableitungsfunktionen wie PBKDF2 existieren genau, um dies zu adressieren. Passwork beispielsweise leitet seinen Masterschlüssel vom Masterpasswort des Benutzers über PBKDF2 mit 300.000 Iterationen und SHA-256 ab — was Brute-Force des Masterpassworts selbst bei extrahierter verschlüsselter Datenbank rechenintensiv macht.
2. Kompromittierte Endpunkte. Malware, die auf einem Endpunkt läuft, liest Daten nach der Entschlüsselung, im RAM. Die Daten waren im Ruhezustand verschlüsselt, wurden zur Nutzung entschlüsselt, die Malware erfasste sie im Klartext. AES-256 bietet hier null Schutz. Deshalb sind Endpoint Detection and Response (EDR) und Privileged Access Workstations (PAWs) keine optionalen Schichten.
3. Insider-Bedrohungen. Autorisierte Benutzer mit legitimem Entschlüsselungszugang können Daten exfiltrieren. Verschlüsselung unterscheidet nicht zwischen einem legitimen Administrator und einem böswilligen. Rollenbasierte Zugriffskontrolle (RBAC), Least-Privilege-Prinzipien und Audit-Protokollierung sind die Kontrollen, die diese Lücke adressieren.
4. Schlechte Zugriffskontrolle. Geteilte Anmeldedaten, zu breite Berechtigungen und veraltete Konten, die nach dem Ausscheiden von Mitarbeitern aktiv bleiben, schaffen Exposition, die Verschlüsselung nicht mindern kann.
5. Metadaten-Exposition. Selbst wenn Inhalte verschlüsselt sind, können Metadaten (wer mit wem kommuniziert hat, wann, wie oft, Dateigrößen, Zugriffsmuster) sensible Informationen offenbaren. Verschlüsselung schützt die Nutzlast, nicht den Umschlag.
6. Kontrollverlust nach dem Teilen. Sobald eine verschlüsselte Datei geteilt und vom Empfänger entschlüsselt wurde, haben Sie keine Kontrolle mehr darüber, was als nächstes passiert. Digital Rights Management (DRM) und Zero-Trust-Dateifreigabe-Architekturen adressieren dies teilweise, aber keine Lösung ist vollständig.

Bekannte kryptoanalytische Angriffe auf AES-256 — und warum sie in der Praxis keine Rolle spielen

Der Vollständigkeit halber: Die bekanntesten Angriffe gegen vollständiges AES-256 sind der Biclique-Angriff (Rechenkomplexität von etwa 2²⁵⁴⋅⁴, knapp unter der Brute-Force-Grenze von 2²⁵⁶) und Related-Key-Angriffe (Komplexität um 2⁹⁹⋅⁵ unter hochspezifischen Bedingungen).

Keiner ist praktisch relevant. Der Biclique-Angriff erfordert mehr Rechenleistung als physisch machbar ist. Related-Key-Angriffe erfordern, dass der Angreifer die Beziehung zwischen mehreren Schlüsseln kontrolliert — eine Bedingung, die in keinem richtig konzipierten System existiert. Seitenkanalangriffe (Leistungsanalyse, Timing-Angriffe, Cache-Timing) sind ein echtes Problem, aber sie zielen auf die Implementierung, nicht auf den Algorithmus. Constant-Time-Implementierungen und Hardware-AES-Beschleunigung (AES-NI) mindern die meisten davon.

Enterprise-Best-Practices für AES-256 im Jahr 2026

AES-256 im Jahr 2026 korrekt einzusetzen bedeutet, in drei Ebenen zu denken: Daten im Ruhezustand, Daten während der Übertragung und Daten in Nutzung. Die meisten Organisationen haben die ersten beiden teilweise abgedeckt. Die dritte ist der Bereich, in dem die nächste Generation von Verletzungen auftreten wird.

Daten im Ruhezustand

Verwenden Sie AES-256-GCM für neue Implementierungen. Stellen Sie sicher, dass Schlüssel getrennt von den zu schützenden Daten verwaltet werden — idealerweise in einem HSM oder einem dedizierten Key-Management-Service. Rotieren Sie Schlüssel nach einem definierten Zeitplan und sofort bei Verdacht auf Kompromittierung. Verwenden Sie PBKDF2, bcrypt oder Argon2, um Verschlüsselungsschlüssel aus Passwörtern abzuleiten. Verwenden Sie niemals das Passwort direkt als Schlüssel.

Festplattenverschlüsselung (BitLocker unter Windows, FileVault unter macOS) bietet eine Baseline für Endpunktschutz, schützt aber nur gegen physischen Diebstahl eines ausgeschalteten Geräts. Sie schützt nicht gegen einen angemeldeten Benutzer oder einen laufenden Malware-Prozess.

Daten während der Übertragung

TLS 1.3 ist der aktuelle Standard. Es schreibt AEAD-Cipher-Suites vor (AES-256-GCM oder ChaCha20-Poly1305), entfernt schwache Cipher-Suites aus TLS 1.2 und bietet standardmäßig Forward Secrecy. Wenn Ihre Infrastruktur noch TLS 1.2 mit CBC-Cipher-Suites unterstützt, ist das eine Konfigurationsschuld, die es jetzt zu beheben gilt.

Daten in Nutzung — das ungelöste Problem

Daten in Nutzung sind Klartext im Speicher während der Verarbeitung. Confidential-Computing-Frameworks — Intel SGX (Software Guard Extensions) und AMD SEV (Secure Encrypted Virtualization) — schaffen hardware-isolierte Ausführungsumgebungen (Trusted Execution Environments oder TEEs), in denen selbst der Hypervisor oder das Betriebssystem die verarbeiteten Daten nicht lesen können. Dies ist die Frontier der Verschlüsselungsarchitektur und wird zunehmend relevant für Cloud-Workloads, die sensible Daten verarbeiten.

Zero-Knowledge-Architektur

Eine Zero-Knowledge-Architektur bedeutet, dass der Dienstanbieter (oder Server) niemals Zugriff auf Klartextdaten oder die Schlüssel zu deren Entschlüsselung hat. Client-seitige Verschlüsselung ist der Mechanismus: Daten werden auf dem Client vor der Übertragung verschlüsselt, und der Server speichert nur Chiffretext. Der Client-seitige Verschlüsselungsmodus von Passwork implementiert dies — der Masterschlüssel wird vom Masterpasswort des Benutzers abgeleitet und nie an den Server übertragen, was bedeutet, dass selbst eine vollständige Serverkompromittierung nur verschlüsselte Daten liefert.

Compliance-Anforderungen

AES-256 ist nicht nur eine technische Best Practice — es ist eine Compliance-Anforderung in mehreren Frameworks:

• HIPAA Safe Harbor (45 CFR §164.312(a)(2)(iv)) bezeichnet AES-256 als gültige Verschlüsselungsmethode für geschützte Gesundheitsinformationen (PHI), wodurch verletzte Daten als „nicht nutzbar, unlesbar oder unentschlüsselbar" gelten.
• DSGVO Artikel 32 verlangt „geeignete technische Maßnahmen" einschließlich Verschlüsselung zum Schutz personenbezogener Daten. AES-256 ist der De-facto-Standard zur Erfüllung dieser Anforderung.
• PCI DSS Anforderung 3 schreibt starke Kryptografie für gespeicherte Karteninhaberdaten vor. AES-256 erfüllt diese Anforderung; AES-128 ist das Minimum.
• NSA CNSA 2.0 schreibt AES-256 (nicht AES-128) für alle National Security Systems auf allen Klassifizierungsstufen vor.

Fazit

AES-256 bleibt 2026 das richtige Fundament für Datenverschlüsselung. Der Algorithmus hat keine praktische Schwachstelle (klassisch oder quantenbasiert) und diese Position wird sich innerhalb jedes für Ihre Organisation heute relevanten Planungshorizonts wahrscheinlich nicht ändern.

Die härtere Wahrheit ist, dass der Algorithmus nie das Problem war. Der 2026 DBIR fand den menschlichen Faktor bei 62 % der Verletzungen. Das ist kein Kryptografie-Versagen. Es ist ein Versagen beim Schlüsselmanagement, der Zugriffskontrolle, der Endpunkthygiene und der operativen Disziplin.

Drei Dinge sind es wert, jetzt priorisiert zu werden:

1. Prüfen Sie, wo Ihre Verschlüsselungsschlüssel liegen. Wenn welche hardcodiert sind oder neben den zu schützenden Daten gespeichert werden, ist das die dringendste Korrektur auf dieser Liste.
2. Migrieren Sie den asymmetrischen Schlüsselaustausch zu Post-Quanten-Algorithmen. HNDL ist ein gegenwärtiges Risiko für alle Daten mit mehrjährigem Sensibilitätshorizont.
3. Verlagern Sie das Credential-Management in einen strukturierten Tresor. Wenn Ihr Team sich immer noch auf Tabellenkalkulationen oder geteilte Dokumente verlässt, ist das Zugriffskontrollproblem dringender als jede kryptografische Frage.

AES-256 erfüllt seinen Zweck. Die Frage ist, ob alles drumherum das auch tut.

Häufig gestellte Fragen zur AES-256-Verschlüsselung

Ist AES-256-Verschlüsselung wirklich unknackbar?

AES-256 hat keinen bekannten praktischen Angriff, der es innerhalb eines machbaren Zeitrahmens bricht. Der beste klassische Angriff (Biclique) erreicht eine Komplexität von etwa 2²⁵⁴⋅⁴ Operationen — geringfügig unter Brute-Force, aber rechnerisch unmöglich auszuführen. Kein heute gebauter oder für das nächste Jahrzehnt prognostizierter klassischer oder Quantencomputer kann AES-256 durch direkten Angriff auf den Algorithmus brechen.

Können Quantencomputer AES-256 brechen?

Nein. Grovers Algorithmus — die relevante Quantenbedrohung für symmetrische Verschlüsselung — reduziert die effektive Sicherheit von AES-256 von 256 Bit auf etwa 128 Bit. 128-Bit-Sicherheit bleibt durch jede bekannte oder prognostizierte Quantenhardware unknackbar. NIST bestätigt ausdrücklich, dass AES mit 128-, 192- oder 256-Bit-Schlüsseln gegen Quantenangriffe sicher ist. Asymmetrische Algorithmen wie RSA sind diejenigen, die einem echten Quantenrisiko ausgesetzt sind.

Was ist der Unterschied zwischen AES-256-GCM und AES-256-CBC?

AES-256-GCM bietet authentifizierte Verschlüsselung (AEAD): Es verschlüsselt Daten und erzeugt einen Message Authentication Code in einem Durchgang, der sowohl Vertraulichkeit als auch Integrität garantiert. AES-256-CBC verschlüsselt nur — ohne separaten MAC ist es anfällig für Padding-Oracle- und Bit-Flipping-Angriffe. TLS 1.3 hat die CBC-Unterstützung vollständig entfernt. Für neue Deployments ist GCM die richtige Wahl.

Was ist „Harvest Now, Decrypt Later" und sollte ich mir Sorgen machen?

HNDL ist eine Strategie, bei der Gegner heute verschlüsselte Daten abfangen und speichern, mit der Absicht, sie zu entschlüsseln, sobald Quantencomputer dazu fähig werden. Für Daten mit einem langen Sensibilitätshorizont — klassifizierte Informationen, Krankenakten, langfristige Finanzdaten — ist dies ein gegenwärtiges Risiko. Die Mitigation besteht darin, asymmetrische Schlüsselaustauschprotokolle jetzt auf Post-Quanten-Algorithmen (FIPS 203/204/205) zu migrieren, während AES-256 weiterhin für symmetrische Verschlüsselung verwendet wird.

Warum werden Organisationen, die AES-256 verwenden, immer noch gehackt?

Weil Angreifer die Verschlüsselung umgehen, anstatt sie zu brechen. Gestohlene Anmeldedaten, kompromittierte Endpunkte, schlechtes Schlüsselmanagement, Insider-Bedrohungen und zu breite Zugriffsberechtigungen exponieren alle Klartextdaten, ohne jemals die Chiffre zu berühren.

Was ist eine Zero-Knowledge-Architektur in einem Passwort-Manager?

Eine Zero-Knowledge-Architektur bedeutet, dass der Server niemals Klartext-Anmeldedaten oder die Schlüssel zu deren Entschlüsselung empfängt oder speichert. Die Verschlüsselung erfolgt auf dem Client (im Browser oder der Anwendung), bevor die Daten übertragen werden. Selbst wenn der Server vollständig kompromittiert wird, erhält der Angreifer nur Chiffretext. Dies ist die Architektur, die für jedes Credential-Management-Tool erforderlich ist, das sensible Unternehmensgeheimnisse verarbeitet.

Erfüllt AES-256 die Anforderungen von HIPAA, DSGVO und PCI DSS?

Ja, für alle drei. HIPAAs Safe-Harbor-Bestimmung (45 CFR §164.312) bezeichnet AES-256 als gültigen Verschlüsselungsstandard für PHI. DSGVO Artikel 32 verlangt geeignete technische Maßnahmen einschließlich Verschlüsselung — AES-256 erfüllt dies. PCI DSS Anforderung 3 schreibt starke Kryptografie für gespeicherte Karteninhaberdaten vor, wobei AES-256 der akzeptierte Standard ist. Compliance erfordert eine korrekte Implementierung, nicht nur das Vorhandensein von Verschlüsselung.

Mitarbeiter-Offboarding: Leitfaden zur sicheren Zugriffsentziehung 2026

Das Deaktivieren eines SSO-Kontos entzieht keinen Zugriff. API-Schlüssel, KI-Agenten-Anmeldedaten 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 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. So sieht das Risiko tatsächlich aus und was Governance adressieren muss.

Passwork BlogAlex Muntyan

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-Nachweis.

Passwork BlogAlex Muntyan

El cifrado AES-256 es un cifrado de bloques simétrico que utiliza una clave de 256 bits para cifrar datos en 14 rondas de transformación. Ningún ordenador clásico o cuántico puede descifrarlo por fuerza bruta en un plazo de tiempo práctico. Sin embargo, las organizaciones que utilizan AES-256 siguen sufriendo filtraciones de datos catastróficas — porque los atacantes rara vez intentan romper el cifrado. Atacan los sistemas que lo rodean.

Esa distinción importa más en 2026 que nunca. Los ataques impulsados por IA están acelerando el robo de credenciales y el compromiso de endpoints. La estrategia «Harvest Now, Decrypt Later» (recopilar ahora, descifrar después) significa que los adversarios están almacenando datos cifrados hoy, apostando por futuras capacidades de descifrado. Y NIST ha finalizado sus primeros estándares de criptografía post-cuántica, lo que genera preguntas legítimas sobre si AES-256 todavía tiene lugar en su arquitectura de seguridad.

La respuesta corta: sí. La respuesta más larga requiere entender exactamente contra qué protege AES-256, contra qué no protege, y cómo implementarlo para que la fortaleza teórica del algoritmo se traduzca en seguridad real.

Puntos clave

• AES-256 no tiene debilidad práctica. Ningún ordenador clásico o cuántico puede descifrar por fuerza bruta una clave de 256 bits en un plazo de tiempo viable. El algoritmo en sí no es el riesgo.
• El algoritmo de Grover reduce a la mitad la seguridad de AES-256, no la elimina. Un adversario cuántico reduce la seguridad efectiva a 128 bits — todavía inquebrantable por cualquier hardware conocido o proyectado.
• La amenaza real es Harvest Now, Decrypt Later (HNDL), no el día Q. Los adversarios están archivando datos cifrados hoy. Migrar el intercambio de claves asimétricas a algoritmos post-cuánticos es una prioridad presente, no futura.
• AES-256-GCM es el modo correcto para nuevas implementaciones. CBC proporciona solo confidencialidad. GCM añade autenticación integrada y es obligatorio en TLS 1.3.
• El 62% de las filtraciones involucran el elemento humano. Los atacantes evitan el cifrado a través de credenciales robadas, endpoints comprometidos y mala gestión de claves — no rompiendo el cifrado.
• La gestión de claves es el eslabón más débil. Las claves codificadas de forma fija, las claves almacenadas junto a los datos que protegen y las claves que nunca se rotan son más peligrosas que cualquier ataque criptoanalítico conocido.
• La arquitectura de conocimiento cero elimina el riesgo del lado del servidor. Si el servidor nunca tiene acceso al texto plano ni a las claves de descifrado, un compromiso total del servidor solo produce texto cifrado inútil.
• AES-256 cumple con HIPAA, GDPR y PCI DSS. El cumplimiento requiere una implementación correcta — cifrado en reposo, en tránsito y gestión de claves documentada — no solo la presencia del algoritmo.

¿Qué es AES-256?

AES-256 (Advanced Encryption Standard con una clave de 256 bits) es un cifrado de bloques simétrico estandarizado en NIST FIPS 197. Cifra datos en bloques de 128 bits utilizando una clave de 256 bits a lo largo de 14 rondas de transformación. La misma clave cifra y descifra los datos. Ningún ataque clásico o cuántico conocido puede romperlo en un plazo de tiempo práctico.

AES-256 es el estándar de cifrado utilizado en todo el gobierno federal de EE. UU. (incluidos los sistemas clasificados de la NSA), TLS 1.3, el cifrado de disco completo en todos los sistemas operativos principales y las herramientas empresariales de gestión de credenciales. Cuando un proveedor dice que su producto utiliza «cifrado de grado militar», casi siempre se refiere a AES-256.

De dónde viene el nombre

La parte AES se refiere al algoritmo en sí — una red de sustitución-permutación diseñada por Joan Daemen y Vincent Rijmen (originalmente llamada Rijndael), seleccionada por NIST en 2001 después de una competición pública de cinco años. El «256» se refiere a la longitud de la clave en bits. AES también viene en variantes de 128 bits y 192 bits; la versión de 256 bits utiliza 14 rondas de transformación en lugar de 10 (AES-128) o 12 (AES-192). Más rondas significan un mayor margen de seguridad.

Qué significa realmente la clave de 256 bits

Una clave de 256 bits tiene 2²⁵⁶ valores posibles — aproximadamente 1,16×10⁷⁷. Para ponerlo en términos físicos: si cada átomo del universo observable fuera un ordenador realizando mil millones de miles de millones (10¹⁸) de intentos de clave por segundo, agotar el espacio de claves de AES-256 todavía llevaría más tiempo que la edad del universo por muchos órdenes de magnitud. Por eso los criptógrafos describen AES-256 como sin vulnerabilidad práctica de fuerza bruta.

La longitud de la clave también determina la resiliencia cuántica. El algoritmo de Grover — el mejor ataque cuántico conocido contra cifrados simétricos — proporciona una aceleración cuadrática, reduciendo efectivamente la longitud de la clave a la mitad. Contra AES-256, esa reducción lleva la seguridad efectiva a 128 bits. La seguridad de AES-128 en sí misma es inquebrantable por cualquier hardware conocido o proyectado. La documentación de criptografía post-cuántica del propio NIST confirma que AES-256 sigue siendo seguro contra adversarios cuánticos.

AES-256 vs. AES-128: ¿Es significativa la diferencia?

Para la mayoría de los casos de uso empresarial, ambos son computacionalmente inquebrantables. Las razones prácticas para preferir AES-256 son:

• Requisitos regulatorios. CNSA 2.0 de la NSA (2022, actualizado en 2025) exige AES-256 para todos los Sistemas de Seguridad Nacional en todos los niveles de clasificación. PCI DSS acepta AES-128 como mínimo pero AES-256 como el estándar recomendado.
• Margen cuántico. AES-256 retiene 128 bits de seguridad post-Grover; AES-128 cae a 64 bits, lo que se acerca a la viabilidad para un adversario cuántico suficientemente avanzado.
• Datos de larga duración. Si los datos que cifra hoy necesitan permanecer confidenciales durante más de 20 años, AES-256 es la opción conservadora.

La diferencia de rendimiento entre AES-128 y AES-256 es insignificante en hardware moderno con aceleración AES-NI — típicamente menos del 20% de diferencia en rendimiento. No hay razón práctica para elegir AES-128 en nuevas implementaciones.

Cómo encaja AES-256 en una arquitectura de seguridad más amplia

AES-256 es un cifrado simétrico. Maneja el cifrado masivo de datos de manera eficiente, pero requiere que ambas partes compartan la misma clave secreta — lo que crea un problema de distribución de claves. En la práctica, la criptografía asimétrica (RSA, ECC o algoritmos post-cuánticos como ML-KEM de FIPS 203) se utiliza para intercambiar de forma segura la clave AES, después de lo cual AES-256 maneja los datos reales. Así es exactamente como funciona TLS 1.3: handshake asimétrico, transferencia de datos simétrica.

El cifrado es tan fuerte como el sistema que lo rodea. AES-256 protege los datos en reposo y en tránsito. No protege contra una clave robada, un endpoint comprometido o un usuario autorizado con intenciones maliciosas. Eso no es una debilidad del algoritmo — es el límite de lo que cualquier cifrado puede hacer.

Cómo funciona AES-256: Las matemáticas detrás del cifrado

El cifrado procesa datos en bloques fijos de 128 bits. Cada bloque pasa por 14 rondas secuenciales de transformación — más rondas que AES-128 (10) o AES-192 (12). Cada ronda aplica cuatro operaciones: sustitución, desplazamiento de filas, mezcla de columnas y adición de clave. Cambiar un solo bit de entrada cambia aproximadamente la mitad de los bits de salida al final de la primera ronda.

Las 14 rondas de transformación

AES-256 aplica 14 rondas de cuatro operaciones a cada bloque de datos de 128 bits. Cada ronda consiste en:

1. SubBytes — cada byte se reemplaza mediante una tabla de sustitución fija (S-box), introduciendo no linealidad
2. ShiftRows — las filas de la matriz de estado 4×4 se desplazan cíclicamente, proporcionando difusión
3. MixColumns — las columnas se multiplican en un Campo de Galois, mezclando aún más los datos entre bytes
4. AddRoundKey — la clave de ronda (derivada de la clave original de 256 bits mediante expansión de clave) se combina mediante XOR con el estado

La ronda final omite MixColumns. Este diseño de red de sustitución-permutación (SPN) significa que cambiar un solo bit de entrada cambia aproximadamente la mitad de los bits de salida — el efecto avalancha. Después de 14 rondas, la relación entre el texto plano y el texto cifrado es computacionalmente intratable de revertir sin la clave.

AES-GCM vs. AES-CBC: Por qué el modo importa tanto como la longitud de la clave

El cifrado en sí es solo parte de la historia. Cómo se utiliza — el modo de operación — determina si su implementación es realmente segura.

AES-256-GCM es un modo de Cifrado Autenticado con Datos Asociados (AEAD). Cifra simultáneamente los datos y produce un código de autenticación de mensaje (MAC), garantizando tanto confidencialidad como integridad en una sola operación. Si un atacante manipula el texto cifrado, el descifrado falla — el MAC no se verificará.

AES-256-CBC proporciona solo confidencialidad. Sin un MAC separado (mediante HMAC-SHA256, por ejemplo), un mensaje cifrado con CBC es vulnerable a ataques de oráculo de relleno y manipulación de bits. CBC también requiere procesamiento secuencial, lo que limita el rendimiento en hardware moderno multinúcleo.

Para nuevas implementaciones en 2026, AES-256-GCM es la opción correcta. TLS 1.3 eliminó los conjuntos de cifrado CBC por completo por esta razón. La única advertencia práctica: GCM se rompe catastróficamente si un nonce (vector de inicialización) se reutiliza con la misma clave. Su implementación debe garantizar la unicidad del nonce — típicamente mediante un generador de números aleatorios criptográficamente seguro o un contador.

Computación cuántica y AES-256: Separando el riesgo del ruido

La amenaza de la computación cuántica al cifrado es real, pero no es uniforme. Entender qué algoritmos son vulnerables, y en qué medida, es esencial para tomar decisiones arquitectónicas sólidas hoy.

Los ordenadores cuánticos amenazan la criptografía asimétrica (RSA, ECC, Diffie-Hellman) a través del algoritmo de Shor, que puede factorizar grandes enteros y resolver problemas de logaritmo discreto en tiempo polinómico. Un ordenador cuántico suficientemente potente ejecutando el algoritmo de Shor rompería RSA-2048 por completo. Esta es la crisis genuina que impulsa el esfuerzo de estandarización de criptografía post-cuántica (PQC) de NIST, que finalizó FIPS 203, 204 y 205 en 2024.

El cifrado simétrico enfrenta un algoritmo diferente y un nivel de amenaza diferente.

Qué hace realmente el algoritmo de Grover a AES-256

El algoritmo de Grover es la amenaza cuántica al cifrado simétrico. Proporciona una aceleración cuadrática para problemas de búsqueda no estructurada: donde un ordenador clásico necesita N operaciones para buscar en un espacio de claves, un ordenador cuántico ejecutando Grover necesita aproximadamente la raíz cuadrada de N. Aplicado a AES-256, esto reduce efectivamente la longitud de la clave a la mitad desde una perspectiva de seguridad — una clave de 256 bits proporciona aproximadamente 128 bits de seguridad contra un adversario cuántico.

128 bits de seguridad siguen siendo inquebrantables. Para ser concretos: un ataque clásico a AES-128 requiere aproximadamente 2¹²⁸ operaciones. Incluso si pudiera realizar mil millones de miles de millones (10¹⁸) de operaciones por segundo, agotar ese espacio de claves llevaría más tiempo que la edad del universo. El algoritmo de Grover reduce AES-256 a ese nivel — no lo rompe. Las preguntas frecuentes de PQC del propio NIST afirman explícitamente que AES con claves de 128, 192 o 256 bits permanece seguro contra ataques cuánticos.

El aviso CNSA 2.0 de la NSA (2022, actualizado en 2025) exige AES-256 para todos los Sistemas de Seguridad Nacional en todos los niveles de clasificación, incluido Alto Secreto, con una fecha límite de transición de 2035. El hecho de que la NSA no esté reemplazando AES-256 (solo los algoritmos asimétricos) es la señal más clara posible sobre su resiliencia cuántica.

Harvest Now, Decrypt Later (HNDL): La amenaza que existe hoy

El día Q (el punto en el que existe un ordenador cuántico criptoanalíticamente relevante) se estima por la mayoría de los investigadores que está a 10-20 años de distancia, aunque los plazos son genuinamente inciertos. La amenaza más inmediata es HNDL: actores estatales y grupos criminales sofisticados están interceptando y archivando tráfico cifrado hoy, con la intención de descifrarlo una vez que el hardware cuántico madure.

Para datos con un horizonte de sensibilidad largo — comunicaciones gubernamentales clasificadas, propiedad intelectual, registros médicos, datos financieros a largo plazo — HNDL es un riesgo operativo presente, no un hipotético futuro. La respuesta es migrar los protocolos de intercambio de claves asimétricas a algoritmos post-cuánticos ahora, mientras se continúa utilizando AES-256 para el cifrado simétrico.

Si AES-256 es inquebrantable, ¿por qué siguen ocurriendo filtraciones de datos?

El cifrado AES-256 es matemáticamente sólido. Las filtraciones ocurren en todas partes menos ahí. El Informe de Investigaciones de Filtraciones de Datos 2026 de Verizon encontró que el elemento humano estuvo presente en el 62% de las filtraciones — credenciales robadas, mal uso de privilegios, ingeniería social. Los atacantes no rompen el cifrado. Roban la clave, comprometen el endpoint o explotan a la persona que tiene la contraseña.

El DBIR 2026 también marca un cambio estructural: por primera vez en 19 años de publicación del informe, la explotación de vulnerabilidades ha superado a las credenciales robadas como el principal vector de acceso inicial, representando el 31% de todas las filtraciones, frente al 20% del año anterior. La IA está acelerando esto — los actores de amenazas ahora la usan para reducir la ventana entre la divulgación de vulnerabilidades y la explotación activa de meses a horas.

El Informe de Costo de una Filtración de Datos 2025 de IBM cuantifica el peso financiero de estos fallos en 4,44 millones de dólares por incidente en promedio. Las organizaciones con altos niveles de shadow AI (empleados usando herramientas de IA no aprobadas en dispositivos corporativos) pagaron 670.000 dólares adicionales por filtración. El DBIR 2026 añade contexto: el shadow AI es ahora la tercera actividad de fuga de datos internos no maliciosa más común, con el uso regular de herramientas de IA entre empleados saltando del 15% al 45% en un solo año.

Estas cifras enmarcan el problema real: el cifrado protege los datos en reposo y en tránsito, pero no puede proteger contra un usuario autorizado haciendo algo no autorizado, una vulnerabilidad sin parchear durante ocho meses, o un endpoint que ya está comprometido.

Las seis brechas que evitan el cifrado

Aquí hay una forma estructurada de pensar sobre dónde falla AES-256 en la práctica — no porque el algoritmo sea débil, sino porque la arquitectura circundante lo es.

El modelo de brechas «El cifrado no es suficiente»:

1. Fallos en la gestión de claves. Claves de cifrado codificadas de forma fija en el código fuente, claves almacenadas junto a los datos que protegen, claves que nunca se rotan. Si la clave está comprometida, el cifrado no vale nada. Los Módulos de Seguridad Hardware (HSM) y las funciones de derivación de claves como PBKDF2 existen precisamente para abordar esto. Passwork, por ejemplo, deriva su clave maestra de la contraseña maestra del usuario mediante PBKDF2 con 300.000 iteraciones y SHA-256 — haciendo que la fuerza bruta de la contraseña maestra sea computacionalmente costosa incluso si la base de datos cifrada es exfiltrada.
2. Endpoints comprometidos. El malware que opera en un endpoint lee los datos después del descifrado, en RAM. Los datos estaban cifrados en reposo, se descifraron para ser utilizados, el malware los capturó en texto plano. AES-256 proporciona cero protección aquí. Por eso la detección y respuesta de endpoints (EDR) y las estaciones de trabajo de acceso privilegiado (PAWs) no son capas opcionales.
3. Amenazas internas. Los usuarios autorizados con acceso legítimo de descifrado pueden exfiltrar datos. El cifrado no distingue entre un administrador legítimo y uno malicioso. El control de acceso basado en roles (RBAC), los principios de mínimo privilegio y el registro de auditoría son los controles que abordan esta brecha.
4. Control de acceso deficiente. Credenciales compartidas, permisos demasiado amplios y cuentas obsoletas que permanecen activas después de la salida de empleados crean exposición que el cifrado no puede mitigar.
5. Exposición de metadatos. Incluso cuando el contenido está cifrado, los metadatos (quién se comunicó con quién, cuándo, con qué frecuencia, tamaños de archivo, patrones de acceso) pueden revelar información sensible. El cifrado protege la carga útil, no el sobre.
6. Pérdida de control post-compartición. Una vez que un archivo cifrado se comparte y el destinatario lo descifra, no tiene control sobre lo que sucede después. La gestión de derechos digitales (DRM) y las arquitecturas de compartición de archivos de confianza cero abordan parcialmente esto, pero ninguna solución es completa.

Ataques criptoanalíticos conocidos contra AES-256 — y por qué no importan en la práctica

Para ser exhaustivos: los mejores ataques conocidos contra AES-256 completo son el ataque biclique (complejidad computacional de aproximadamente 2²⁵⁴⋅⁴, apenas por debajo del límite de fuerza bruta de 2²⁵⁶) y los ataques de clave relacionada (complejidad de alrededor de 2⁹⁹⋅⁵ bajo condiciones muy específicas).

Ninguno es prácticamente relevante. El ataque biclique requiere más computación de la que es físicamente viable. Los ataques de clave relacionada requieren que el atacante controle la relación entre múltiples claves — una condición que no existe en ningún sistema correctamente diseñado. Los ataques de canal lateral (análisis de potencia, ataques de tiempo, temporización de caché) son una preocupación genuina, pero atacan la implementación, no el algoritmo. Las implementaciones de tiempo constante y la aceleración hardware de AES (AES-NI) mitigan la mayoría de estos.

Mejores prácticas empresariales para AES-256 en 2026

Implementar AES-256 correctamente en 2026 significa pensar en tres planos: datos en reposo, datos en tránsito y datos en uso. La mayoría de las organizaciones tienen los dos primeros parcialmente cubiertos. El tercero es donde ocurrirá la próxima generación de filtraciones.

Datos en reposo

Utilice AES-256-GCM para nuevas implementaciones. Asegúrese de que las claves se gestionen por separado de los datos que protegen — idealmente en un HSM o un servicio de gestión de claves dedicado. Rote las claves según un calendario definido e inmediatamente ante sospecha de compromiso. Utilice PBKDF2, bcrypt o Argon2 para derivar claves de cifrado de contraseñas. Nunca use la contraseña directamente como clave.

El cifrado de disco completo (BitLocker en Windows, FileVault en macOS) proporciona una línea base para la protección de endpoints, pero solo protege contra el robo físico de un dispositivo apagado. No protege contra un usuario conectado o un proceso de malware en ejecución.

Datos en tránsito

TLS 1.3 es el estándar actual. Exige conjuntos de cifrado AEAD (AES-256-GCM o ChaCha20-Poly1305), elimina los conjuntos de cifrado débiles presentes en TLS 1.2 y proporciona secreto perfecto hacia adelante por defecto. Si su infraestructura todavía soporta TLS 1.2 con conjuntos de cifrado CBC, esa es una deuda de configuración que vale la pena abordar ahora.

Datos en uso — el problema sin resolver

Los datos en uso son texto plano en memoria mientras se procesan. Los frameworks de computación confidencial — Intel SGX (Software Guard Extensions) y AMD SEV (Secure Encrypted Virtualization) — crean entornos de ejecución aislados por hardware (entornos de ejecución confiable, o TEEs) donde ni siquiera el hipervisor o el sistema operativo pueden leer los datos que se procesan. Esta es la frontera de la arquitectura de cifrado, y es cada vez más relevante para cargas de trabajo en la nube que manejan datos sensibles.

Arquitectura de conocimiento cero

Una arquitectura de conocimiento cero significa que el proveedor del servicio (o servidor) nunca tiene acceso a los datos en texto plano ni a las claves para descifrarlos. El cifrado del lado del cliente es el mecanismo: los datos se cifran en el cliente antes de la transmisión, y el servidor almacena solo texto cifrado. El modo de cifrado del lado del cliente de Passwork implementa esto — la clave maestra se deriva de la contraseña maestra del usuario y nunca se transmite al servidor, lo que significa que incluso un compromiso total del servidor solo produce datos cifrados.

Anclas de cumplimiento

AES-256 no es solo una mejor práctica técnica — es un requisito de cumplimiento en múltiples marcos:

• HIPAA Safe Harbor (45 CFR §164.312(a)(2)(iv)) designa AES-256 como un método de cifrado válido para información de salud protegida (PHI), haciendo que los datos filtrados sean «no utilizables, ilegibles o indescifrables».
• GDPR Artículo 32 requiere «medidas técnicas apropiadas» incluyendo cifrado para proteger datos personales. AES-256 es el estándar de facto para satisfacer este requisito.
• PCI DSS Requisito 3 exige criptografía fuerte para los datos de titulares de tarjetas almacenados. AES-256 cumple este requisito; AES-128 es el mínimo.
• NSA CNSA 2.0 exige AES-256 (no AES-128) para todos los Sistemas de Seguridad Nacional en todos los niveles de clasificación.

Conclusión

AES-256 sigue siendo la base correcta para el cifrado de datos en 2026. El algoritmo no tiene debilidad práctica (clásica o cuántica) y esa posición es poco probable que cambie dentro de cualquier horizonte de planificación que importe a su organización hoy.

La verdad más difícil es que el algoritmo nunca fue el problema. El DBIR 2026 encontró el elemento humano en el 62% de las filtraciones. Eso no es un fallo de criptografía. Es un fallo en la gestión de claves, el control de acceso, la higiene de endpoints y la disciplina operativa.

Tres cosas vale la pena priorizar ahora mismo:

1. Audite dónde residen sus claves de cifrado. Si alguna está codificada de forma fija o almacenada junto a los datos que protege, esa es la corrección más urgente de esta lista.
2. Migre el intercambio de claves asimétricas a algoritmos post-cuánticos. HNDL es un riesgo presente para cualquier dato con un horizonte de sensibilidad de varios años.
3. Traslade la gestión de credenciales a una bóveda estructurada. Si su equipo todavía depende de hojas de cálculo o documentos compartidos, el problema de control de acceso es más inmediato que cualquier cuestión criptográfica.

AES-256 hace su trabajo. La pregunta es si todo lo que lo rodea también lo hace.

Preguntas frecuentes sobre el cifrado AES-256

¿Es el cifrado AES-256 verdaderamente inquebrantable?

AES-256 no tiene ningún ataque práctico conocido que lo rompa en un plazo de tiempo viable. El mejor ataque clásico (biclique) logra una complejidad de aproximadamente 2²⁵⁴⋅⁴ operaciones — marginalmente por debajo de la fuerza bruta pero computacionalmente imposible de ejecutar. Ningún ordenador clásico o cuántico construido hoy, o proyectado para la próxima década, puede romper AES-256 atacando directamente el algoritmo.

¿Pueden los ordenadores cuánticos romper AES-256?

No. El algoritmo de Grover — la amenaza cuántica relevante para el cifrado simétrico — reduce la seguridad efectiva de AES-256 de 256 bits a aproximadamente 128 bits. 128 bits de seguridad siguen siendo inquebrantables por cualquier hardware cuántico conocido o proyectado. NIST confirma explícitamente que AES con claves de 128, 192 o 256 bits es seguro contra ataques cuánticos. Los algoritmos asimétricos como RSA son los que enfrentan un riesgo cuántico genuino.

¿Cuál es la diferencia entre AES-256-GCM y AES-256-CBC?

AES-256-GCM proporciona cifrado autenticado (AEAD): cifra los datos y produce un código de autenticación de mensaje en un solo paso, garantizando tanto confidencialidad como integridad. AES-256-CBC solo cifra — sin un MAC separado, es vulnerable a ataques de oráculo de relleno y manipulación de bits. TLS 1.3 eliminó el soporte de CBC por completo. Para nuevas implementaciones, GCM es la opción correcta.

¿Qué es «Harvest Now, Decrypt Later» y debería preocuparme?

HNDL es una estrategia donde los adversarios interceptan y almacenan datos cifrados hoy, con la intención de descifrarlos una vez que los ordenadores cuánticos sean capaces. Para datos con un horizonte de sensibilidad largo — información clasificada, registros médicos, datos financieros a largo plazo — este es un riesgo presente. La mitigación es migrar los protocolos de intercambio de claves asimétricas a algoritmos post-cuánticos (FIPS 203/204/205) ahora, mientras se continúa utilizando AES-256 para el cifrado simétrico.

¿Por qué las organizaciones que usan AES-256 siguen siendo vulneradas?

Porque los atacantes evitan el cifrado en lugar de romperlo. Las credenciales robadas, los endpoints comprometidos, la mala gestión de claves, las amenazas internas y los permisos excesivamente amplios exponen datos en texto plano sin siquiera tocar el cifrado.

¿Qué es una arquitectura de conocimiento cero en un gestor de contraseñas?

Una arquitectura de conocimiento cero significa que el servidor nunca recibe ni almacena credenciales en texto plano ni las claves para descifrarlas. El cifrado ocurre en el cliente (en el navegador o aplicación) antes de que los datos se transmitan. Incluso si el servidor es completamente comprometido, el atacante obtiene solo texto cifrado. Esta es la arquitectura requerida para cualquier herramienta de gestión de credenciales que maneje secretos corporativos sensibles.

¿Cumple AES-256 con los requisitos de HIPAA, GDPR y PCI DSS?

Sí, para los tres. La disposición Safe Harbor de HIPAA (45 CFR §164.312) designa AES-256 como un estándar de cifrado válido para PHI. El Artículo 32 del GDPR requiere medidas técnicas apropiadas incluyendo cifrado — AES-256 satisface esto. El Requisito 3 de PCI DSS exige criptografía fuerte para los datos de titulares de tarjetas almacenados, siendo AES-256 el estándar aceptado. El cumplimiento requiere una implementación correcta, no solo la presencia del cifrado.

Baja de empleados: Guía de revocación segura de accesos 2026

Desactivar una cuenta SSO no revoca el acceso. Las claves API, las credenciales de agentes de IA y las contraseñas compartidas lo sobreviven. Esta guía cubre el manual completo de baja — desde disparadores de hora cero hasta limpieza de NHI.

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

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

AES-256 encryption is a symmetric block cipher that uses a 256-bit key to encrypt data in 14 transformation rounds. No classical or quantum computer can brute-force it within any practical timeframe. Yet organizations using AES-256 still suffer catastrophic data breaches — because attackers rarely try to break the cipher. They break the systems around it.

That distinction matters more in 2026 than it ever has. AI-driven attacks are accelerating credential theft and endpoint compromise. The "Harvest Now, Decrypt Later" strategy means adversaries are stockpiling encrypted data today, betting on future decryption capabilities. And NIST has finalized its first post-quantum cryptography standards, prompting legitimate questions about whether AES-256 still belongs in your security architecture.

The short answer: yes. The longer answer requires understanding exactly what AES-256 protects against, what it doesn't, and how to deploy it so that the algorithm's theoretical strength translates into actual security.

Key takeaways

• AES-256 has no practical weakness. No classical or quantum computer can brute-force a 256-bit key within any feasible timeframe. The algorithm itself is not the risk.
• Grover's algorithm halves AES-256's security, not eliminates it. A quantum adversary reduces effective security to 128 bits — still unbreakable by any known or projected hardware.
• The real threat is Harvest Now, Decrypt Later (HNDL), not Q-Day. Adversaries are archiving encrypted data today. Migrating asymmetric key exchange to post-quantum algorithms is a present priority, not a future one.
• AES-256-GCM is the correct mode for new implementations. CBC provides confidentiality only. GCM adds built-in authentication and is mandatory in TLS 1.3.
• 62% of breaches involve the human element. Attackers bypass encryption through stolen credentials, compromised endpoints, and poor key management — not by breaking the cipher.
• Key management is the weakest link. Hardcoded keys, keys stored next to the data they protect, and keys that never rotate are more dangerous than any known cryptanalytic attack.
• Zero-knowledge architecture eliminates server-side risk. If the server never holds plaintext or decryption keys, a full server compromise yields only useless ciphertext.
• AES-256 satisfies HIPAA, GDPR, and PCI DSS. Compliance requires correct implementation — encryption at rest, in transit, and documented key management — not just the presence of the algorithm.

What is AES-256?

AES-256 (Advanced Encryption Standard with a 256-bit key) is a symmetric block cipher standardized in NIST FIPS 197. It encrypts data in 128-bit blocks using a 256-bit key across 14 transformation rounds. The same key encrypts and decrypts the data. No known classical or quantum attack can break it within any practical timeframe.

AES-256 is the encryption standard used across the U.S. federal government (including NSA-classified systems), TLS 1.3, full-disk encryption on every major OS, and enterprise credential management tools. When a vendor says their product uses "military-grade encryption," they almost always mean AES-256.

Where the name comes from

The AES part refers to the algorithm itself — a substitution-permutation network designed by Joan Daemen and Vincent Rijmen (originally named Rijndael), selected by NIST in 2001 after a five-year public competition. The "256" refers to the key length in bits. AES also comes in 128-bit and 192-bit variants; the 256-bit version uses 14 rounds of transformation instead of 10 (AES-128) or 12 (AES-192). More rounds mean a larger security margin.

What the 256-bit key actually means

A 256-bit key has 2²⁵⁶ possible values — approximately 1.16×10⁷⁷. To put that in physical terms: if every atom in the observable universe were a computer performing a billion billion key guesses per second, exhausting the AES-256 keyspace would still take longer than the age of the universe by many orders of magnitude. This is why cryptographers describe AES-256 as having no practical brute-force vulnerability.

The key length also determines quantum resilience. Grover's algorithm — the best known quantum attack on symmetric ciphers — provides a quadratic speedup, effectively halving the key length. Against AES-256, that reduction brings effective security to 128 bits. AES-128 security is itself unbreakable by any known or projected hardware. NIST's own post-quantum cryptography documentation confirms AES-256 remains secure against quantum adversaries.

AES-256 vs. AES-128: Is the difference meaningful?

For most enterprise use cases, both are computationally unbreakable. The practical reasons to prefer AES-256 are:

• Regulatory requirements. NSA's CNSA 2.0 (2022, updated 2025) mandates AES-256 for all National Security Systems at all classification levels. PCI DSS accepts AES-128 as a minimum but AES-256 as the recommended standard.
• Quantum margin. AES-256 retains 128-bit security post-Grover; AES-128 drops to 64 bits, which approaches feasibility for a sufficiently advanced quantum adversary.
• Long-lived data. If the data you encrypt today needs to remain confidential for 20+ years, AES-256 is the conservative choice.

The performance difference between AES-128 and AES-256 is negligible on modern hardware with AES-NI acceleration — typically under 20% throughput difference. There is no practical reason to choose AES-128 for new implementations.

How AES-256 fits into a broader security architecture

AES-256 is a symmetric cipher. It handles bulk data encryption efficiently, but it requires both parties to share the same secret key — which creates a key distribution problem. In practice, asymmetric cryptography (RSA, ECC, or post-quantum algorithms like ML-KEM from FIPS 203) is used to securely exchange the AES key, after which AES-256 handles the actual data. This is exactly how TLS 1.3 works: asymmetric handshake, symmetric data transfer.