Passwork Team

We have released an updated Passwork Docker image with patched PHP (CVE-2026-109618 and CVE-2026-109619). If you run Passwork 7 or later in Docker, update today.

The update restarts the containers, so Passwork will be unavailable for a few minutes. It doesn’t change the database or Docker volumes.

Passwork Cloud was updated right after the fixes were released. No action is required from Passwork Cloud customers.

Docker installation

Run these commands on the server, in the directory that contains docker-compose.yml.

Check the PHP version:

docker exec -it passwork_php php -v

Pull the new image and recreate the PHP containers:

docker compose pull
docker compose up -d --force-recreate php-fpm cron

Create a backup and confirm that the dump appears in ./backup/:

./db-backup.sh

The first line of the output must show PHP 8.3.36 or newer.

If the version is older, the new image was not applied. Contact Support rather than leaving the server in that state.

After the check, open the Passwork web interface and confirm that it loads.

Manual installation

If you installed Passwork 7 or later without Docker, update PHP to the patched release (8.3.36 or newer), restart PHP, and confirm the version with php -v.

OS-specific instructions are in the PHP update guides.

Warnung: Kritische PHP-Schwachstellen. CVE-2026-109618 und CVE-2026-109619 können es einem nicht authentifizierten Angreifer ermöglichen, Code auf einem Server auszuführen, auf dem PHP läuft, einschließlich PHP-FPM. Beide werden auf CVSS v4.0 mit 9,2 bewertet, und laut dem PHP-Projekt ist ein Update die einzige vollständige Abhilfe. Administratoren von On-Premise-Installationen von Passwork sollten PHP auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisieren.

Update vom PHP-Projekt: Korrekturen veröffentlicht

Das PHP-Projekt hat am 20. Oktober ein kritisches Sicherheitsrelease angekündigt und am 21. Oktober veröffentlicht. PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 beheben beide Schwachstellen. Das Advisory betrifft jede PHP-Installation, die Webanfragen verarbeitet, einschließlich PHP-FPM, und hält fest, dass „es keine vollständigen Gegenmaßnahmen gibt, ein Update ist die einzig sichere Wahl.“

Self-hosted-Installationen: Update-Plan

Administratoren von Self-hosted-Installationen müssen das PHP-FPM, das Passwork ausliefert, auf die korrigierte Version ihres Branches aktualisieren, neu starten und die Version am PHP-FPM-Binary prüfen, nicht in einer Shell. Beginnen Sie mit Instanzen, die aus dem Internet erreichbar sind.

Bevor Sie Änderungen an der Produktivumgebung vornehmen:

• Erstellen Sie einen Snapshot der Datenbank und der Konfiguration und proben Sie die Wiederherstellung auf einem Ersatzhost, falls Sie dies in letzter Zeit nicht getan haben.
• Verwenden Sie die korrigierte Version des Branches, den Sie bereits einsetzen. Der Wechsel auf einen anderen Branch ist eine eigene Änderung, die einen separaten Test mit Ihrer Passwork-Version erfordert.
• Installieren Sie Builds ausschließlich aus Ihrer Distribution, von Ihrem Hersteller oder von php.net. Quell-Builds und Windows-Binaries finden Sie auf der PHP-Downloadseite. Distributions- und Long-Term-Support-Anbieter haben die Patches vorab erhalten. Suchen Sie daher zuerst nach deren Paketen, bevor Sie etwas kompilieren.

Spielen Sie das Update anschließend so ein, wie Sie PHP installiert haben (per Paket oder Container-Image), starten Sie den Dienst neu und prüfen Sie, ob das PHP-FPM, das Passwork ausliefert, eine korrigierte Version meldet. Das PHP in der Kommandozeile kann eine andere Version melden als PHP-FPM. Prüfen Sie daher die Komponente, die Webanfragen verarbeitet.

Wenn ein sofortiges Update nicht möglich ist

Beschränken Sie bis zur Installation des Updates den Kreis derer, die Passwork erreichen können. Stellen Sie es hinter ein VPN oder beschränken Sie es auf einen per Allowlist freigegebenen Netzwerkbereich, und erfassen Sie zuvor alle Clients, die von außen zugreifen: Remote-Mitarbeiter, mobile Apps, Browser-Erweiterungen, API- und CLI-Jobs. Jeder von ihnen funktioniert nicht mehr, wenn Sie den Zugriff einschränken, ohne ihn freizugeben.

Das PHP-Advisory nennt außerdem Übergangseinstellungen für jede CVE, die Speicherlimits, Grenzen für die Anfragegröße und den Upload-Fortschritt von Sitzungen betreffen. Sie schließen einzelne Angriffspfade, machen eine Installation aber nicht sicher. Testen Sie sie vor dem Produktiveinsatz auf einer Staging-Instanz, da sie das Verhalten bei Speicher, Uploads und Sitzungen verändern.

Advertencia: vulnerabilidades críticas en PHP. CVE-2026-109618 y CVE-2026-109619 pueden permitir que un atacante no autenticado ejecute código en un servidor que ejecuta PHP, incluido PHP-FPM. Ambas obtienen una puntuación de 9,2 en CVSS v4.0, y el proyecto PHP indica que actualizar es la única corrección completa. Los administradores de Passwork on-premise deberían actualizar PHP a 8.5.12, 8.4.27, 8.3.36 u 8.2.35.

Novedades de PHP: Correcciones publicadas

El proyecto PHP anunció una versión de seguridad crítica el 20 de octubre y la publicó el 21 de octubre. PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 corrigen ambas vulnerabilidades. El aviso abarca todas las instalaciones de PHP que atienden solicitudes web, incluido PHP-FPM, y afirma que «no existen mitigaciones completas, actualizar es la única opción segura».

Instalaciones self-hosted: Plan de actualización

Los administradores de instalaciones self-hosted deben actualizar el PHP-FPM que atiende a Passwork a la versión corregida de su rama, reiniciarlo y verificar la versión en el binario de PHP-FPM y no en una shell. Empiece por las instancias accesibles desde internet.

Antes de modificar el entorno de producción:

• Cree un snapshot de la base de datos y de la configuración, y pruebe la restauración en un host de repuesto si no lo ha hecho recientemente.
• Utilice la versión corregida de la rama que ya ejecuta. Cambiar a otra rama es un cambio independiente que requiere su propia prueba con la versión de Passwork en uso.
• Instale compilaciones solo de la distribución, del proveedor o de php.net. Las compilaciones desde el código fuente y los binarios de Windows están en la página de descargas de PHP, y los proveedores de distribuciones y de soporte a largo plazo recibieron los parches con antelación, por lo que debe buscar sus paquetes antes de compilar nada.

A continuación, aplique la actualización del mismo modo en que instaló PHP, mediante un paquete o una imagen de contenedor, reinicie el servicio y confirme que el PHP-FPM que atiende a Passwork informa de una versión corregida. El PHP de línea de comandos puede informar de una versión distinta a la de PHP-FPM, así que compruebe la del que atiende las solicitudes web.

Si no es posible actualizar de inmediato

Hasta que se instale la actualización, limite quién puede acceder a Passwork. Sitúe Passwork detrás de una VPN o restrinja el acceso a un rango de red incluido en una lista de permitidos, y antes enumere todos los clientes que se conectan desde el exterior: personal remoto, aplicaciones móviles, extensiones de navegador y tareas de API y de CLI. Cada uno de ellos deja de funcionar si se restringe el acceso sin permitirlo.

El aviso de PHP también enumera configuraciones provisionales para cada CVE, relativas a los límites de memoria, los límites de tamaño de las solicitudes y el progreso de carga de las sesiones. Cierran vías de ataque concretas, pero no hacen que una instalación sea segura. Pruébelas en una instancia de staging antes de pasar a producción, porque modifican el comportamiento de la memoria, de las cargas y de las sesiones.

Aviso: vulnerabilidades críticas do PHP. As CVE-2026-109618 e CVE-2026-109619 podem permitir que um atacante não autenticado execute código num servidor que corre PHP, incluindo PHP-FPM. Ambas têm uma pontuação de 9,2 no CVSS v4.0 e o projeto PHP indica que a atualização é a única correção completa. Os administradores do Passwork autoalojado devem atualizar o PHP para a versão 8.5.12, 8.4.27, 8.3.36 ou 8.2.35.

Atualização do PHP: Correções publicadas

O projeto PHP anunciou uma versão de segurança crítica a 20 de outubro e publicou-a a 21 de outubro. As versões PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 corrigem ambas as vulnerabilidades. O aviso abrange todas as instalações de PHP que processam pedidos web, incluindo PHP-FPM, e afirma que «não existem mitigações completas, a atualização é a única opção segura.»

Instalações autoalojadas: plano de atualização

Os administradores de instalações autoalojadas devem atualizar o PHP-FPM que serve o Passwork para a versão corrigida do respetivo ramo, reiniciá-lo e verificar a versão no binário do PHP-FPM, e não numa shell. Comece pelas instâncias acessíveis a partir da internet.

Antes de intervir em produção:

• Crie um snapshot da base de dados e da configuração e ensaie o restauro num anfitrião de reserva, caso não o tenha feito recentemente.
• Escolha a versão corrigida do ramo que já utiliza. A mudança para outro ramo é uma alteração distinta, que exige um teste próprio com a versão do Passwork instalada.
• Instale apenas compilações da sua distribuição, do seu fornecedor ou de php.net. As compilações a partir do código-fonte e os binários para Windows encontram-se na página de transferências do PHP, e os fornecedores de distribuições e de suporte de longo prazo receberam as correções antecipadamente, pelo que convém procurar os respetivos pacotes antes de compilar seja o que for.

Em seguida, aplique a atualização da mesma forma que instalou o PHP, através de um pacote ou de uma imagem de contentor, reinicie o serviço e confirme que o PHP-FPM que serve o Passwork indica uma versão corrigida. O PHP de linha de comandos pode indicar uma versão diferente da do PHP-FPM, por isso importa verificar a que processa os pedidos web.

Se não for possível atualizar de imediato

Até a atualização estar instalada, restrinja quem pode aceder ao Passwork. Coloque-o atrás de uma VPN ou limite-o a um intervalo de rede incluído na lista de permissões e, primeiro, enumere todos os clientes que se ligam do exterior: colaboradores remotos, aplicações móveis, extensões de navegador, tarefas de API e CLI. Cada um deixa de funcionar se o acesso for restringido sem que seja autorizado.

O aviso do PHP enumera também definições provisórias para cada CVE, relativas a limites de memória, limites de tamanho de pedidos e progresso de carregamento de ficheiros na sessão. Estas definições fecham vias de ataque individuais, mas não tornam uma instalação segura. Teste-as numa instância de teste (staging) antes de as aplicar em produção, porque alteram o comportamento da memória, dos carregamentos e das sessões.

Warning: critical PHP vulnerabilities. CVE-2026-109618 and CVE-2026-109619 can allow an unauthenticated attacker to run code on a server that runs PHP, PHP-FPM included. Both score 9.2 on CVSS v4.0, and the PHP project says updating is the only complete fix. On-premise Passwork administrators should move PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35.

Update from PHP: Fixes released

The PHP project announced a critical security release on 20 October and published it on 21 October. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix both vulnerabilities. The advisory covers every PHP installation that serves web requests, PHP-FPM included, and states that "there are no complete mitigations, updating is the only safe choice."

Self-hosted installations: update plan

Administrators of self-hosted installations must update the PHP-FPM that serves Passwork to the fixed release for their branch, restart it, and verify the version on the PHP-FPM binary rather than in a shell. Start with instances reachable from the internet.

Before you touch production:

• Snapshot the database and configuration, and rehearse the restore on a spare host if you have not done so recently.
• Take the fixed release of the branch you already run. Moving to a different branch is a separate change that needs its own test against your Passwork version.
• Install builds only from your distribution, your vendor, or php.net. Source builds and Windows binaries are on the PHP downloads page, and distribution and long-term support vendors received the patches in advance, so look for their packages before compiling anything.

Then apply the update the way you installed PHP, through a package or a container image, restart the service, and confirm that the PHP-FPM serving Passwork reports a fixed version. The command-line PHP can report a different version than PHP-FPM, so check the one that handles web requests.

If you cannot update right away

Until the update is installed, narrow who can reach Passwork. Put it behind a VPN or limit it to an allow-listed network range, and list every client that connects from outside first: remote staff, mobile apps, browser extensions, API and CLI jobs. Each of them stops working if you restrict access without allowing it.

The PHP advisory also lists interim settings for each CVE, covering memory limits, request size limits, and session upload progress. They close individual attack paths and do not make an installation safe. Test them on a staging instance before production, because they change memory, upload, and session behavior.

Pegnitz é uma cidade industrial situada à entrada da Suíça da Francónia: compacta em dimensão, economicamente forte e culturalmente distinta. Vivem aqui cerca de 13 600 pessoas, no distrito de Bayreuth e na região metropolitana de Nuremberga, onde Pegnitz é o centro económico do distrito sul. A sua história remonta às antigas minas e à fundição Pegnitzhütte. Atualmente, a engenharia e a metalurgia coexistem com a indústria têxtil como base económica da cidade.

A vida cívica marca também o carácter da cidade. Pegnitz acolhe concertos de verão e feiras sazonais, mas o Gregori-Fest destaca-se: um festival infantil com uma tradição milenar, classificado como património cultural imaterial na Baviera. A estratégia municipal Pegnitz 2030 alarga este enfoque cívico ao planeamento económico e de infraestruturas, incluindo apoio ao emprego, desenvolvimento do centro da cidade e transição energética.

Esse crescimento chegou também às próprias operações de TI da administração. Com uma carga de trabalho mais pesada, o sistema baseado em ficheiros utilizado pela equipa para gerir acessos deixou de ser suficiente, levando-a a procurar uma alternativa self-hosted concebida para vários administradores a trabalhar em simultâneo.

O desafio: Os conflitos de sincronização baseados em ficheiros atrasavam uma pequena equipa de TI

A infraestrutura de TI de Stadt Pegnitz é gerida pelo departamento de TI do município. Antes de mudar para o Passwork, a equipa utilizava um cofre de palavras-passe de código aberto e baseado em ficheiros para armazenar as credenciais dos servidores, comutadores de rede e firewalls do município. A ferramenta funcionava bem como cofre pessoal, mas não foi concebida para acesso simultâneo multiutilizador, e essa limitação manifestava-se diariamente.

Uma equipa reduzida responsável por toda a rede municipal tem pouca margem para ferramentas que acrescentem sobrecarga de coordenação. Essa fricção levou Pegnitz a procurar uma alternativa.

O ficheiro de base de dados único não suportava mais do que um administrador a abri-lo em simultâneo sem risco de conflito de fusão. Na prática, isto significava que um administrador perguntava a outro: «Está agora no cofre?» antes de fazer qualquer alteração, para evitar sobrepor-se à atualização de um colega.

A configuração anterior criava vários problemas que se agravavam mutuamente:

• Cada alteração exigia coordenação verbal para evitar sobrepor as alterações de um colega
• Podiam circular cópias desatualizadas da base de dados caso alguém se esquecesse de distribuir a versão mais recente
• A ausência de um modelo de permissões baseado em funções impedia um controlo de acesso granular

Qualquer cofre baseado em ficheiros, sincronizado manualmente ou através de uma unidade de rede partilhada, encontra as mesmas limitações assim que mais do que uma pessoa precisa de acesso de escrita. Uma ferramenta que funciona bem para um único administrador transforma-se num problema de coordenação assim que entra uma segunda pessoa.

A solução: O Passwork cumpriu os requisitos de Pegnitz sem a sobrecarga de nível empresarial

Pegnitz precisava de uma única fonte de verdade para as credenciais de infraestrutura, sem sincronização baseada em ficheiros e sem a sobrecarga de uma implementação à escala empresarial.

«Como equipa de TI compacta, precisamos de ferramentas que facilitem o nosso trabalho, não que acrescentem sobrecarga administrativa. O Passwork tornou o nosso trabalho diário de infraestrutura mais seguro e muito mais rápido.» — Stadt Pegnitz IT team

A pesquisa, realizada em fóruns de TI e comunidades de código aberto, centrou-se em quatro requisitos que a interface e o modelo de implementação do Passwork satisfizeram diretamente:

• Implementação self-hosted e on-premise, para manter os dados das credenciais sob o controlo do município
• Cifragem do lado do cliente, para que os dados nunca cheguem ao servidor sem cifragem
• Acesso multiutilizador sem bloqueio de ficheiros
• Uma relação preço-valor razoável, uma vez que a equipa não tinha interesse em pagar por funcionalidades empresariais que não utilizaria

A interface do Passwork, concebida em torno do fluxo de trabalho real dos administradores e não como um cofre de estilo pessoal adaptado para equipas, foi a principal razão pela qual se destacou durante a avaliação.

Implementação e migração: Um lançamento rápido sem perda de dados

Dois fatores tornaram a avaliação de Pegnitz rápida:

• Implementação baseada em Docker, que permitiu à equipa testar todo o conjunto de funcionalidades sem um processo de configuração demorado
• Uma migração sem perdas a partir do cofre existente da equipa

Em conjunto, estes fatores resolveram os dois maiores riscos de qualquer mudança de gestor de palavras-passe: tempo de inatividade prolongado durante a implementação e perda de dados durante a migração. 

A migração a partir do antigo cofre baseado em ficheiros decorreu sem problemas através da função de importação integrada do Passwork, transferindo anos de dados de credenciais acumulados sem perdas. 

Resultados: Fluxo de trabalho diário mais rápido, sem sobrecarga de coordenação

O Passwork eliminou a etapa de coordenação que costumava preceder cada alteração de palavra-passe em Pegnitz. As alterações sincronizam agora com toda a equipa em tempo real, pelo que a conversa «está no cofre?» deixou de existir. A extensão do navegador reduziu o tempo despendido em inícios de sessão de rotina, e a rotação centralizada de credenciais substituiu o antigo processo manual de atualizar cópias locais uma a uma.

O ganho de segurança acompanhou o ganho de produtividade. Com as credenciais centralizadas e organizadas por funções, a equipa de TI deixou de precisar de descobrir qual a cópia local do cofre que está atualizada antes de alterar uma palavra-passe num servidor ou firewall.

Conclusão

A equipa de TI de Pegnitz enfrentava conflitos de fusão e uma constante coordenação verbal sempre que mais do que um administrador precisava de editar o cofre de credenciais partilhado. Resolveram o problema ao mudar para o Passwork, um cofre centralizado e self-hosted, com acesso multiutilizador em tempo real e permissões baseadas em funções.

Como resultado, a equipa eliminou por completo os conflitos de bloqueio de ficheiros e reduziu o tempo despendido na gestão de alterações de credenciais de rotina.

«O mais importante é que já não precisamos de verificar se outra pessoa está a trabalhar no cofre antes de fazer uma alteração. Podemos trabalhar em paralelo sem conflitos. Para nós, o Passwork é a solução self-hosted ideal.» — Stadt Pegnitz IT team

Kindernothilfe: Simplificar a colaboração global entre colaboradores com o Passwork

A Kindernothilfe, uma das maiores organizações europeias de apoio à infância, precisava de um gestor de palavras-passe escalável para uma equipa distribuída globalmente. Escolheram o Passwork pela opção self-hosted, pelo SSO via SAML2 e por uma interface intuitiva que simplificou a gestão de acessos além-fronteiras.

PassworkAlex Muntyan

Funcionalidades de segurança dos gestores de palavras-passe: como avaliá-las

A página de segurança do seu fornecedor faz muitas promessas. Eis o modelo de seis pilares para verificar quais são realmente verdadeiras, antes de assinar ou renovar.

PassworkPasswork Team

A cidade de Melle: como o Passwork centralizou a gestão de palavras-passe

A cidade de Melle, um município na Baixa Saxónia com mais de 48 000 habitantes, é reconhecida pela sua abordagem moderna à administração municipal e aos serviços ao cidadão. O governo local gere um vasto leque de responsabilidades: desenvolvimento urbano, educação, assistência social, proteção ambiental, iniciativas culturais, infraestruturas municipais e apoio económico à região. Nos últimos anos, Melle tem investido fortemente na transformação digital, com a introdução de serviços de atendimento ao cidadão em linha e a moderniz

PassworkAlex Muntyan

Pegnitz ist eine Industriestadt am Tor zur Fränkischen Schweiz: kompakt, wirtschaftlich stark und kulturell eigenständig. Hier leben etwa 13.600 Menschen, im Landkreis Bayreuth und in der Metropolregion Nürnberg, wo Pegnitz als wirtschaftliches Zentrum des südlichen Landkreises fungiert. Die Geschichte der Stadt reicht bis zu den früheren Bergwerken und der Pegnitzhütte zurück. Heute bilden Maschinenbau und Metallverarbeitung neben der Textilindustrie die wirtschaftliche Grundlage der Stadt.

Auch das bürgerschaftliche Leben prägt den Charakter der Stadt. Pegnitz veranstaltet Sommerkonzerte und saisonale Feste, doch das Gregori-Fest nimmt eine Sonderstellung ein: ein Kinderfest mit tausendjähriger Tradition, das in Bayern als immaterielles Kulturerbe geführt wird. Die Pegnitz-2030-Strategie der Gemeinde erweitert diesen bürgerschaftlichen Fokus auf die Wirtschafts- und Infrastrukturplanung, einschließlich Arbeitsplatzförderung, Innenstadtentwicklung und Energiewende.

Dieses Wachstum erreichte auch die IT der eigenen Verwaltung. Unter der gestiegenen Arbeitslast kam das dateibasierte System des Teams zur Zugriffsverwaltung nicht mehr hinterher, und man suchte nach einer selbst gehosteten Alternative für mehrere gleichzeitig arbeitende Administratoren.

Die Herausforderung: Dateibasierte Synchronisationskonflikte bremsten ein kleines IT-Team aus

Die IT-Infrastruktur der Stadt Pegnitz wird von der IT-Abteilung der Verwaltung betreut. Vor dem Wechsel zu Passwork nutzte das Team einen dateibasierten Open-Source-Passworttresor, um Zugangsdaten für die Server, Netzwerk-Switches und Firewalls der Kommune zu speichern. Das Tool funktionierte gut als persönlicher Tresor, war aber nicht für den gleichzeitigen Zugriff mehrerer Benutzer ausgelegt – diese Einschränkung zeigte sich täglich.

Ein kleines Team, das ein gesamtes kommunales Netzwerk betreut, hat wenig Spielraum für Tools, die zusätzlichen Koordinationsaufwand verursachen. Diese Reibung veranlasste Pegnitz, nach einer Alternative zu suchen.

Die einzelne Datenbankdatei konnte nicht von mehr als einem Administrator gleichzeitig geöffnet werden, ohne einen Merge-Konflikt zu riskieren. In der Praxis bedeutete das, dass ein Administrator einen anderen fragte: „Ist gerade jemand im Tresor?", bevor er eine Änderung vornahm, um zu vermeiden, dass die Aktualisierung eines Kollegen überschrieben wird.

Die alte Lösung führte zu mehreren sich verstärkenden Problemen:

• Jede Änderung erforderte eine mündliche Abstimmung, um das Überschreiben der Änderungen eines Kollegen zu vermeiden
• Veraltete Datenbankkopien konnten im Umlauf bleiben, wenn jemand vergaß, die neueste Version weiterzugeben
• Ohne rollenbasiertes Berechtigungsmodell war eine granulare Zugriffskontrolle nicht möglich

Jeder dateibasierte Tresor, der manuell oder über ein gemeinsames Netzlaufwerk synchronisiert wird, stößt an dieselben Grenzen, sobald mehr als eine Person Schreibzugriff benötigt. Ein Tool, das für einen einzelnen Administrator gut funktioniert, wird zum Koordinationsproblem, sobald eine zweite Person hinzukommt.

Die Lösung: Passwork erfüllte die Anforderungen von Pegnitz ohne Enterprise-Mehraufwand

Pegnitz benötigte eine zentrale, verlässliche Quelle für Infrastruktur-Zugangsdaten, ohne dateibasierte Synchronisation und ohne den Mehraufwand einer Enterprise-Lösung.

„Als kompaktes IT-Team brauchen wir Tools, die unsere Arbeit erleichtern, statt zusätzlichen Verwaltungsaufwand zu schaffen. Mit Passwork ist unsere tägliche Infrastrukturarbeit sicherer und deutlich schneller geworden." — Stadt Pegnitz IT team

Die Suche, die über IT-Foren und Open-Source-Communities erfolgte, konzentrierte sich auf vier Anforderungen, die die Oberfläche und das Bereitstellungsmodell von Passwork direkt erfüllten:

• Selbst gehostetes On-Premise-Deployment, um die Zugangsdaten unter der Kontrolle der Kommune zu behalten
• Clientseitige Verschlüsselung, sodass Daten den Server nie unverschlüsselt erreichen
• Mehrbenutzerzugriff ohne Dateisperren
• Ein angemessenes Preis-Leistungs-Verhältnis, da das Team keine Enterprise-Funktionen bezahlen wollte, die es nicht nutzen würde

Die Oberfläche von Passwork, die auf den tatsächlichen Workflow von Administratoren ausgerichtet ist und nicht auf einen für Teams nachgerüsteten Consumer-Tresor, war der Hauptgrund, warum sie sich bei der Evaluierung abhob.

Deployment und Migration: Ein schneller Rollout ohne Datenverlust

Zwei Faktoren machten die Evaluierung für Pegnitz schnell:

• Docker-basiertes Deployment, mit dem das Team den vollständigen Funktionsumfang ohne aufwendigen Einrichtungsprozess testen konnte
• Eine verlustfreie Migration aus dem bestehenden Tresor des Teams

Zusammen adressierten diese beiden Faktoren die größten Risiken bei jedem Wechsel des Passwortmanagers: längere Ausfallzeiten während des Rollouts und Datenverlust während des Umzugs. 

Die Migration aus dem vorherigen dateibasierten Tresor verlief über die integrierte Importfunktion von Passwork reibungslos und übertrug Jahre an angesammelten Zugangsdaten ohne Verlust. 

Ergebnisse: Schnellerer Arbeitsalltag, kein Koordinationsaufwand

Passwork hat den Koordinationsschritt überflüssig gemacht, der früher jeder Passwortänderung in Pegnitz vorausging. Änderungen werden jetzt in Echtzeit mit dem gesamten Team synchronisiert, sodass das Gespräch „Ist gerade jemand im Tresor?" entfällt. Die Browser-Erweiterung verkürzte die Zeit für routinemäßige Anmeldungen, und die zentrale Rotation der Zugangsdaten ersetzte den alten manuellen Prozess, bei dem lokale Kopien einzeln aktualisiert werden mussten.

Der Sicherheitsgewinn entsprach dem Produktivitätsgewinn. Da Zugangsdaten zentralisiert und rollenbasiert verwaltet werden, muss das IT-Team nicht mehr ermitteln, welche lokale Tresorkopie aktuell ist, bevor es ein Passwort auf einem Server oder einer Firewall rotiert.

Fazit

Das IT-Team von Pegnitz hatte mit Merge-Konflikten und ständiger mündlicher Abstimmung zu kämpfen, sobald mehr als ein Administrator den gemeinsamen Zugangsdaten-Tresor bearbeiten musste. Gelöst wurde dies durch den Wechsel zu Passwork, einem zentralisierten, selbst gehosteten Tresor mit Echtzeit-Mehrbenutzerzugriff und rollenbasierten Berechtigungen.

Dadurch hat das Team Konflikte durch Dateisperren vollständig beseitigt und den Zeitaufwand für die Verwaltung routinemäßiger Änderungen an Zugangsdaten reduziert.

„Das Wichtigste ist: Wir müssen nicht mehr prüfen, ob jemand anderes gerade im Tresor arbeitet, bevor wir eine Änderung vornehmen. Wir können parallel arbeiten, ohne Konflikte. Für uns ist Passwork die ideale selbst gehostete Lösung." — Stadt Pegnitz IT team

Kindernothilfe: Globale Mitarbeiterzusammenarbeit mit Passwork vereinfachen

Kindernothilfe, eine der größten Kinderhilfsorganisationen Europas, benötigte einen skalierbaren Passwortmanager für ein global verteiltes Team. Die Organisation entschied sich für Passwork wegen des Self-Hostings, SSO über SAML2 und einer intuitiven Oberfläche, die die Zugriffsverwaltung über Ländergrenzen hinweg vereinfachte.

PassworkAlex Muntyan

Sicherheitsfunktionen von Passwortmanagern: So lassen sie sich bewerten

Die Sicherheitsseite Ihres Anbieters verspricht viel. Hier ist das Sechs-Säulen-Framework, mit dem Sie prüfen, welche Versprechen tatsächlich zutreffen, bevor Sie unterschreiben oder verlängern.

PassworkPasswork Team

Die Stadt Melle: Wie Passwork die Passwortverwaltung zentralisierte

Die Stadt Melle, eine Gemeinde in Niedersachsen mit mehr als 48.000 Einwohnern, ist für ihren modernen Ansatz in der Stadtverwaltung und bei den Bürgerdiensten bekannt. Die Kommunalverwaltung verantwortet ein breites Aufgabenspektrum: Stadtentwicklung, Bildung, Sozialfürsorge, Umweltschutz, kulturelle Initiativen, kommunale Infrastruktur und Wirtschaftsförderung für die Region. In den letzten Jahren hat Melle stark in die digitale Transformation investiert, mit der Einführung von Online-Bürgerdiensten, der Modernis

PassworkAlex Muntyan

Pegnitz es una ciudad industrial situada en la puerta de entrada a la Suiza de Franconia: de escala compacta, económicamente sólida y con una identidad cultural propia. Allí viven unos 13 600 habitantes, en el distrito de Bayreuth y la región metropolitana de Núremberg, donde Pegnitz actúa como centro económico de la zona sur del distrito. Sus orígenes se remontan a antiguas minas y a la fundición Pegnitzhütte. Hoy, la ingeniería y la metalurgia conviven con la industria textil como base económica de la ciudad.

La vida cívica define el carácter de la ciudad en la misma medida. Pegnitz acoge conciertos de verano y ferias de temporada, aunque el Gregori-Fest destaca especialmente: un festival infantil con una tradición milenaria, reconocido como patrimonio cultural inmaterial de Baviera. La estrategia municipal Pegnitz 2030 extiende este enfoque cívico a la planificación económica y de infraestructuras, incluidos el apoyo al empleo, el desarrollo del centro urbano y la transición energética.

Ese crecimiento también llegó a las operaciones de TI de la propia administración. Con una carga de trabajo mayor, el sistema basado en archivos que el equipo utilizaba para gestionar los accesos dejó de ser suficiente, por lo que empezaron a buscar una alternativa autoalojada diseñada para que varios administradores trabajaran al mismo tiempo.

El reto: Los conflictos de sincronización de archivos ralentizaban a un pequeño equipo de TI

La infraestructura de TI de Stadt Pegnitz está a cargo del departamento de TI del municipio. Antes de pasar a Passwork, el equipo utilizaba una bóveda de contraseñas de código abierto basada en archivos para almacenar las credenciales de los servidores, los conmutadores de red y los cortafuegos del municipio. La herramienta funcionaba bien como bóveda personal, pero no estaba diseñada para el acceso simultáneo de varios usuarios, y esa limitación se notaba a diario.

Un equipo reducido que cubre toda la red municipal tiene poco margen para herramientas que añaden carga de coordinación. Esta fricción llevó a Pegnitz a buscar una alternativa.

El archivo de base de datos único no permitía que más de un administrador lo abriera al mismo tiempo sin arriesgarse a un conflicto de fusión. En la práctica, esto significaba que un administrador le preguntaba a otro: «¿Está en la bóveda ahora mismo?» antes de hacer cualquier cambio, para evitar sobrescribir la actualización de un compañero.

La configuración anterior generaba varios problemas que se acumulaban:

• Cada modificación exigía coordinación verbal para evitar sobrescribir los cambios de un compañero
• Podían circular copias desactualizadas de la base de datos si alguien olvidaba distribuir la versión más reciente
• La ausencia de un modelo de permisos basado en roles impedía un control de acceso granular

Cualquier bóveda basada en archivos que se sincronice manualmente o mediante una unidad de red compartida se enfrenta a las mismas limitaciones en cuanto más de una persona necesita acceso de escritura. Una herramienta que funciona bien para un único administrador genera un problema de coordinación en cuanto se suma una segunda persona.

La solución: Passwork cumplió los requisitos de Pegnitz sin la complejidad de una solución empresarial

Pegnitz necesitaba una única fuente de verdad para las credenciales de infraestructura, sin sincronización basada en archivos y sin la complejidad de una implementación a escala empresarial.

«Como equipo de TI reducido, necesitamos herramientas que faciliten nuestro trabajo, no que añadan carga administrativa. Passwork ha hecho que nuestro trabajo diario de infraestructura sea más seguro y mucho más rápido.» — Stadt Pegnitz IT team

La búsqueda, realizada a través de foros de TI y comunidades de código abierto, se centró en cuatro requisitos que la interfaz y el modelo de implementación de Passwork cumplían directamente:

• Implementación autoalojada y on-premise, para mantener los datos de credenciales bajo el control del municipio
• Cifrado del lado del cliente, de modo que los datos nunca llegan al servidor sin cifrar
• Acceso multiusuario sin bloqueo de archivos
• Una relación precio-valor razonable, ya que el equipo no tenía interés en pagar por funciones empresariales que no iba a utilizar

La interfaz de Passwork, diseñada en torno al flujo de trabajo real de los administradores y no como una bóveda de consumo adaptada después para equipos, fue el principal motivo por el que destacó durante la evaluación.

Implementación y migración: Una puesta en marcha rápida sin pérdida de datos

Dos factores agilizaron la evaluación de Pegnitz:

• Implementación basada en Docker, que permitió al equipo probar el conjunto completo de funciones sin un proceso de configuración prolongado
• Una migración sin pérdida de datos desde la bóveda existente del equipo

Juntos, estos factores resolvían los dos mayores riesgos de cualquier cambio de gestor de contraseñas: el tiempo de inactividad prolongado durante la puesta en marcha y la pérdida de datos durante la migración. 

La migración desde la bóveda basada en archivos anterior se realizó sin inconvenientes mediante la función de importación integrada de Passwork, conservando años de datos de credenciales acumulados sin ninguna pérdida. 

Resultados: Un flujo de trabajo diario más rápido, sin carga de coordinación

Passwork eliminó el paso de coordinación que antes precede a cada modificación de contraseña en Pegnitz. Los cambios ahora se sincronizan con todo el equipo en tiempo real, por lo que la conversación «¿está en la bóveda?» ha desaparecido. La extensión del navegador redujo el tiempo dedicado a los inicios de sesión rutinarios, y la rotación centralizada de credenciales sustituyó el antiguo proceso manual de actualizar las copias locales una por una.

La mejora en seguridad estuvo a la altura de la mejora en productividad. Con las credenciales centralizadas y organizadas por roles, el equipo de TI ya no necesita averiguar qué copia local de la bóveda es la vigente antes de rotar una contraseña en un servidor o un cortafuegos.

Conclusión

El equipo de TI de Pegnitz se enfrentaba a conflictos de fusión y a una constante coordinación verbal cada vez que más de un administrador necesitaba modificar la bóveda de credenciales compartida. Lo resolvieron adoptando Passwork, una bóveda centralizada y autoalojada con acceso multiusuario en tiempo real y permisos basados en roles.

Como resultado, el equipo eliminó por completo los conflictos de bloqueo de archivos y redujo el tiempo dedicado a gestionar los cambios de credenciales rutinarios.

«Lo más importante es que ya no tenemos que comprobar si alguien más está trabajando en la bóveda antes de hacer un cambio. Podemos trabajar en paralelo sin conflictos. Para nosotros, Passwork es la solución autoalojada ideal.» — Stadt Pegnitz IT team

Kindernothilfe: Simplificación de la colaboración global de los empleados con Passwork

Kindernothilfe, una de las mayores organizaciones de ayuda a la infancia de Europa, necesitaba un gestor de contraseñas escalable para un equipo distribuido globalmente. Eligieron Passwork por su autoalojamiento, el inicio de sesión único (SSO) mediante SAML2 y una interfaz intuitiva que simplificaba la gestión de accesos a través de fronteras.

PassworkAlex Muntyan

Funciones de seguridad de los gestores de contraseñas: Cómo evaluarlas

La página de seguridad del proveedor hace muchas promesas. Este es el marco de seis pilares para comprobar cuáles son realmente ciertas antes de firmar o renovar.

PassworkPasswork Team

La ciudad de Melle: Cómo Passwork centralizó la gestión de contraseñas

La ciudad de Melle, un municipio de Baja Sajonia con más de 48 000 habitantes, es reconocida por su enfoque moderno de la administración municipal y los servicios a la ciudadanía. El gobierno local gestiona una amplia gama de responsabilidades: desarrollo urbano, educación, atención social, protección del medio ambiente, iniciativas culturales, infraestructura municipal y apoyo económico para la región. En los últimos años, Melle ha invertido considerablemente en la transformación digital, introduciendo servicios ciudadanos en línea, moderniz

PassworkAlex Muntyan

Pegnitz is an industrial town at the gateway to Franconian Switzerland: compact in scale, economically strong, and culturally distinct. About 13,600 people live here, in the Bayreuth district and the Nuremberg metropolitan region, where Pegnitz serves as the southern district's economic hub. Its history traces back to former mines and the Pegnitzhütte ironworks. Today engineering and metalworking sit alongside a textile industry as the town's economic base.

Civic life carries the town's character just as much. Pegnitz hosts summer concerts and seasonal fairs, though Gregori-Fest stands apart: a children's festival with a thousand-year tradition, listed as intangible cultural heritage in Bavaria. The municipality's Pegnitz 2030 strategy extends this civic focus into economic and infrastructure planning, including job support, town-center development, and the energy transition.

That growth reached the administration's own IT operations too. Under a heavier workload, the team's file-based system for managing access could no longer keep up, and they began looking for a self-hosted alternative built for multiple administrators working at the same time.

The challenge: File-based sync conflicts slowed down a small IT team

Stadt Pegnitz's IT infrastructure is managed by the municipality's IT department. Before switching to Passwork, the team used an open-source, file-based password vault to store credentials for the municipality's servers, network switches, and firewalls. The tool worked well as a personal vault, but it wasn't designed for concurrent multi-user access, and that limitation showed up daily.

A small team covering an entire municipal network has little room for tools that add coordination overhead. This friction pushed Pegnitz to look for an alternative.

The single database file couldn't handle more than one administrator opening it at once without risking a merge conflict. In practice, this meant one administrator asking another, "Are you in the vault right now?" before making any change, to avoid overwriting a colleague's update.

The old setup created several compounding problems:

• Every edit required verbal coordination to avoid overwriting a colleague's changes
• Outdated database copies could circulate if someone forgot to redistribute the latest version
• No role-based permission model meant granular access control wasn't possible

Any file-based vault synchronized manually or over a shared network drive runs into the same limits once more than one person needs write access. A tool that works well for a single administrator creates a coordination problem once a second person joins.

The solution: Passwork met Pegnitz's requirements without the enterprise overhead

Pegnitz needed a single source of truth for infrastructure credentials, without file-based sync and without the overhead of an enterprise-scale deployment.

"As a compact IT team, we need tools that make our work easier, not add administrative burden. Passwork has made our daily infrastructure work more secure and much faster." — Stadt Pegnitz IT team

The search, conducted through IT forums and open-source communities, focused on four requirements that Passwork's interface and deployment model met directly:

• Self-hosted, on-premise deployment, to keep credential data under the municipality's control
• Client-side encryption, so data never reaches the server unencrypted
• Multi-user access with no file locking
• A reasonable price-to-value ratio, since the team had no interest in paying for enterprise features it wouldn't use

Passwork's interface, built around administrators' actual workflow rather than a consumer-style vault retrofitted for teams, was the main reason it stood out during evaluation.

Deployment and migration: A fast rollout without data loss

Two factors made Pegnitz's evaluation quick:

• Docker-based deployment, which let the team test the full feature set without a lengthy setup process
• A lossless migration from the team's existing vault

Together, these addressed the two biggest risks in any password manager switch: extended downtime during rollout and data loss during the move. 

Migration from the previous file-based vault went through cleanly using Passwork's built-in import function, carrying over years of accumulated credential data without loss. 

Results: Faster daily workflow, no coordination overhead

Passwork removed the coordination step that used to precede every password edit at Pegnitz. Changes now sync to the whole team in real time, so the "are you in the vault?" conversation is gone. The browser extension cut time spent on routine logins, and centralized credential rotation replaced the old manual process of updating local copies one by one.

The security gain matched the productivity gain. With credentials centralized and role-based, the IT team no longer needs to track down which local vault copy is current before rotating a password on a server or firewall.

Conclusion

Pegnitz's IT team faced merge conflicts and constant verbal coordination every time more than one administrator needed to edit the shared credential vault. They solved it by moving to Passwork, a centralized, self-hosted vault with real-time multi-user access and role-based permissions.

As a result, the team eliminated file-locking conflicts entirely and cut the time spent managing routine credential changes.

"Most importantly, we no longer have to check whether someone else is working in the vault before making a change. We can work in parallel without conflicts. For us, Passwork is the ideal self-hosted solution." — Stadt Pegnitz IT team

Kindernothilfe: Simplifying global employee collaboration with Passwork

Kindernothilfe, one of Europe’s largest child aid organizations, needed a scalable password manager for a globally distributed team. They chose Passwork for self-hosting, SSO via SAML2, and an intuitive interface that simplified access management across borders.

PassworkAlex Muntyan

Password manager security features: How to evaluate them

Your vendor’s security page makes a lot of promises. Here’s the six-pillar framework for checking which ones are actually true, before you sign or renew.

PassworkPasswork Team

The city of Melle: How Passwork сentralized password management

The city of Melle, a municipality in Lower Saxony with more than 48,000 residents, is recognized for its modern approach to city administration and citizen services. The local government manages a wide range of responsibilities: urban development, education, social care, environmental protection, cultural initiatives, municipal infrastructure, and economic support for the region. In recent years, Melle has invested heavily in digital transformation, introducing online citizen services, moderniz

PassworkAlex Muntyan

Auerbach in der Oberpfalz é uma pequena cidade com 9470 habitantes na região do Alto Palatinado, na Baviera, no distrito de Amberg-Sulzbach. A cidade mantém uma história industrial ativa a par da sua histórica praça do mercado: o minério de ferro foi extraído aqui durante séculos, e esse legado continua visível no seu carácter atual. O antigo local da mina Maffei ainda tem as suas torres de extração de pé, e o local alberga atualmente um museu mineiro e um festival cultural recorrente. 

Esta abordagem prática estende-se à governação local: o município obteve o estatuto de Cidade Fairtrade em 2024, renovou-o em 2026, e mantém a mesma postura orientada para a sustentabilidade e a responsabilização nas suas outras iniciativas.

A mesma lógica aplica-se à TI. Gerir infraestruturas críticas implica manter o controlo sobre os processos essenciais, incluindo a forma como as credenciais são protegidas. A equipa de administração de sistemas da Auerbach optou por uma plataforma autoalojada com cifragem zero-knowledge, combinando um controlo de acesso rigoroso com soberania total sobre os dados sensíveis.

O desafio: A arquitetura baseada em ficheiros tornou-se um risco de segurança

Uma equipa de administradores de sistemas gere a infraestrutura de TI da Auerbach. Antes do Passwork, a equipa utilizava dois gestores de palavras-passe de código aberto, criados sobre o mesmo formato de base de dados – um baseado no navegador, o outro uma aplicação de ambiente de trabalho –, que dividiam o armazenamento das credenciais entre si.

Ambas as ferramentas assentavam numa arquitetura baseada num único ficheiro, com todas as credenciais guardadas num ficheiro cifrado partilhado pela equipa – um modelo desadequado às necessidades de acesso multiutilizador e sensível da TI municipal. Isto causava falhas de sincronização e conflitos de bloqueio de ficheiros, exigindo supervisão manual do acesso de escrita, e deixava uma lacuna maior: nenhuma permissão baseada em funções nem controlo de acesso granular.

A partilha do ficheiro do cofre através de canais inseguros criava dois riscos: 

• Um ficheiro de base de dados enviado por e-mail ou guardado numa unidade partilhada sem cifragem é um ponto único de falha em caso de interceção. 
• Sem uma fonte de verdade centralizada, cópias desatualizadas das credenciais podiam continuar em circulação, pelo que alguém poderia, sem saber, utilizar uma palavra-passe já rotacionada.

Para uma equipa de TI do setor público que gere o acesso a infraestruturas essenciais, este é o tipo de exposição que as frameworks de segurança são concebidas para prevenir.

Solução: Passwork foi ao encontro das prioridades de segurança e consistência da Auerbach

A pesquisa da Auerbach centrou-se em duas prioridades: a segurança dos dados e a consistência das credenciais numa base de dados centralizada, em vez de um conjunto de ficheiros sincronizados de forma pouco rigorosa. A interface do Passwork, concebida para administradores de sistemas e para uma colaboração estruturada em equipa, e não para uso individual de consumidor, foi a primeira razão para a considerar.

O fator decisivo para iniciar um período de teste foi a arquitetura de segurança documentada do fornecedor: a cifragem zero-knowledge que a equipa conseguiu verificar antes de se comprometer.

O que a Auerbach precisava de uma nova solução

As prioridades de segurança e consistência da Auerbach exigiam três características arquitetónicas específicas: implementação local, cifragem do lado do cliente e uma estrutura de dados capaz de escalar com a infraestrutura do município. Cada uma respondia a uma limitação específica da anterior configuração baseada em ficheiros da equipa.

• Implementação autoalojada e local, para controlo total sobre dados sensíveis nos próprios servidores do município
• Cifragem zero-knowledge, para eliminar a exposição de credenciais e chaves de cifragem do lado do servidor
• Estrutura de cofres e pastas, para organizar o acesso por componente de infraestrutura ou sistema de cliente

A cifragem zero-knowledge significa que o servidor nunca tem acesso aos dados não cifrados nem às chaves de cifragem. Os dados são cifrados do lado do cliente antes de serem transmitidos ou armazenados. Um administrador ou atacante com acesso total ao servidor vê apenas texto cifrado. Para uma entidade do setor público que gere credenciais de infraestruturas de rede essenciais, isto elimina uma categoria inteira de risco de violação do lado do servidor.

Integração técnica

A implementação foi feita através do Docker, permitindo à equipa criar rapidamente uma instância funcional e testá-la com credenciais reais da infraestrutura, em vez de um conjunto de dados de demonstração.  A migração a partir das bases de dados existentes da equipa foi feita através da interface de importação do Passwork, sem erros. A rapidez da implementação de teste e a migração sem problemas permitiram à equipa passar rapidamente da avaliação para a produção.

Resultados: De ficheiros estáticos para um sistema centralizado em tempo real

A Auerbach substituiu os seus cofres baseados em ficheiros por um sistema centralizado que se atualiza em tempo real em toda a equipa. As credenciais são agora rotacionadas e geridas com controlo de versões de forma centralizada, eliminando o risco de cópias desatualizadas das soluções anteriores. A equipa também registou poupanças de tempo graças à extensão do navegador do Passwork no trabalho diário de infraestrutura.

«Na administração de TI moderna, a gestão de palavras-passe não deveria ser
um obstáculo. O Passwork devolveu-nos a flexibilidade e a segurança que
nos faltavam com os cofres estáticos baseados em ficheiros.» — Stadt Auerbach systems administration team

A avaliação da Auerbach centrou-se numa lacuna de segurança específica: cifrar e controlar o acesso a credenciais de sistemas de infraestrutura críticos. A arquitetura de cifragem e o controlo de acesso granular tiveram tanto peso quanto a facilidade de utilização diária – a equipa precisava de um sistema suficientemente seguro para acessos sensíveis, mas suficientemente simples para ser utilizado em todo o departamento sem curva de aprendizagem.

Conclusão

A migração da Auerbach mostra que as ferramentas de palavras-passe baseadas num único ficheiro atingem o seu limite no ponto em que os requisitos de controlo de acesso e auditoria ultrapassam o que um ficheiro partilhado consegue oferecer. Uma equipa que gere infraestrutura municipal crítica enfrenta a mesma exposição que uma grande empresa assim que as credenciais são partilhadas sem permissões baseadas em funções ou uma fonte única de verdade. O Passwork colmatou essa lacuna para a Auerbach com uma arquitetura centralizada e zero-knowledge.

«Com o Passwork, conseguimos trabalhar em equipa sem dificuldades, manter um bom
desempenho nas tarefas diárias e preservar o controlo total da nossa própria
infraestrutura.» — Stadt Auerbach systems administration team

Stadt Pegnitz: Resolver conflitos de sincronização de ficheiros com o Passwork

Pegnitz, uma cidade bávara perto de Nuremberga, geria a TI municipal com um cofre baseado em ficheiros que não suportava acesso concorrente, obrigando os administradores a coordenar verbalmente cada alteração. A equipa migrou para a plataforma autoalojada do Passwork, com acesso a credenciais em tempo real e multiutilizador.

PassworkPasswork Team

Credenciais de agentes de IA: 7 regras para um controlo de acesso seguro

Os agentes de IA já superam em número os colaboradores na maioria das empresas e detêm credenciais ativas. Atuam com base em texto persuasivo, um hábito que transforma controlos de credenciais fracos num risco para toda a frota. Este artigo mostra como delimitar, isolar e revogar credenciais de agentes para conter um único comprometimento.

PassworkPasswork Team

Kindernothilfe: Simplificar a colaboração global entre colaboradores com o Passwork

A Kindernothilfe, uma das maiores organizações europeias de apoio à infância, precisava de um gestor de palavras-passe escalável para uma equipa distribuída globalmente. Escolheu o Passwork pela opção de autoalojamento, pelo SSO via SAML2 e por uma interface intuitiva que simplificou a gestão de acessos entre fronteiras.

PassworkAlex Muntyan

Auerbach in der Oberpfalz ist eine kleine Stadt mit 9.470 Einwohnern in der bayerischen Oberpfalz, im Landkreis Amberg-Sulzbach. Neben ihrem historischen Marktplatz hat die Stadt eine gewachsene Industriegeschichte: Hier wurde jahrhundertelang Eisenerz abgebaut, und dieses Erbe prägt bis heute ihren Charakter. Auf dem Gelände der ehemaligen Maffei-Grube stehen die Fördertürme noch, und dort befinden sich heute ein Bergbaumuseum und ein wiederkehrendes Kulturfestival. 

Dieser pragmatische Ansatz setzt sich auch in der kommunalen Verwaltung fort: Die Gemeinde erhielt 2024 den Status einer Fairtrade-Stadt, erneuerte ihn 2026 und verfolgt denselben nachhaltigkeits- und verantwortungsorientierten Kurs auch bei ihren anderen Initiativen.

Dieselbe Logik gilt für die IT. Der Betrieb kritischer Infrastruktur bedeutet, die Kontrolle über zentrale Prozesse zu behalten – auch darüber, wie Zugangsdaten gesichert werden. Auerbachs Systemadministrationsteam entschied sich für eine selbstgehostete Plattform mit Zero-Knowledge-Verschlüsselung, die strenge Zugriffskontrolle mit voller Souveränität über sensible Daten verbindet.

Die Herausforderung: Dateibasierte Architektur wurde zum Sicherheitsrisiko

Ein Team von Systemadministratoren verwaltet die IT-Infrastruktur von Auerbach. Vor Passwork setzte das Team auf zwei getrennte Open-Source-Passwortmanager mit demselben zugrunde liegenden Datenbankformat – einer browserbasiert, der andere eine Desktop-Anwendung –, wodurch sich die Speicherung der Zugangsdaten auf beide Tools verteilte.

Beide Tools setzten auf eine einzige dateibasierte Architektur, bei der alle Zugangsdaten in einer verschlüsselten Datei liegen, die im gesamten Team geteilt wird – ein Modell, das den sensiblen Mehrbenutzer-Zugriffsanforderungen der kommunalen IT nicht gerecht wird. Das führte zu Synchronisierungsfehlern und Konflikten durch Dateisperren, die eine manuelle Überwachung der Schreibrechte erforderten, und hinterließ eine größere Lücke: keine rollenbasierten Berechtigungen und keine granulare Zugriffskontrolle.

Das Teilen der Tresordatei über unsichere Kanäle schuf zwei Risiken: 

• Eine per E-Mail versendete oder auf einem unverschlüsselten Netzlaufwerk gespeicherte Datenbankdatei ist bei einem Abfangen ein Single Point of Failure. 
• Ohne eine zentrale, verbindliche Datenquelle können veraltete Kopien von Zugangsdaten im Umlauf bleiben, sodass möglicherweise unwissentlich ein bereits rotiertes Passwort verwendet wird.

Für ein IT-Team der öffentlichen Verwaltung, das den Zugriff auf zentrale Infrastruktur verwaltet, ist das genau die Art von Risiko, die Sicherheits-Frameworks verhindern sollen.

Lösung: Passwork erfüllte Auerbachs Prioritäten bei Sicherheit und Konsistenz

Bei der Suche standen für Auerbach zwei Prioritäten im Mittelpunkt: Datensicherheit und konsistente Zugangsdaten in einer zentralen Datenbank statt in lose synchronisierten Dateien. Der erste Grund, Passwork in Betracht zu ziehen, war die Benutzeroberfläche, die für Systemadministratoren und strukturierte Teamzusammenarbeit statt für die individuelle Endnutzung konzipiert ist.

Den Ausschlag für den Start einer Testphase gab die dokumentierte Sicherheitsarchitektur des Anbieters: eine Zero-Knowledge-Verschlüsselung, die das Team vor der endgültigen Entscheidung überprüfen konnte.

Was Auerbach von einer neuen Lösung brauchte

Auerbachs Prioritäten bei Sicherheit und Konsistenz erforderten drei konkrete architektonische Merkmale: eine On-Premise-Bereitstellung, eine clientseitige Verschlüsselung und eine Datenstruktur, die mit der Infrastruktur der Gemeinde mitwachsen kann. Jedes dieser Merkmale adressierte eine konkrete Einschränkung der bisherigen dateibasierten Lösung des Teams.

• Selbstgehostete On-Premise-Bereitstellung für volle Kontrolle über sensible Daten auf den eigenen Servern der Gemeinde
• Zero-Knowledge-Verschlüsselung, um eine serverseitige Offenlegung von Zugangsdaten und Verschlüsselungsschlüsseln auszuschließen
• Tresor- und Ordnerstruktur zur Organisation des Zugriffs nach Infrastrukturkomponente oder Kundensystem

Zero-Knowledge-Verschlüsselung bedeutet, dass der Server niemals Zugriff auf unverschlüsselte Daten oder die Verschlüsselungsschlüssel hat. Daten werden clientseitig verschlüsselt, bevor sie übertragen oder gespeichert werden. Ein Administrator oder Angreifer mit vollem Serverzugriff sieht nur Chiffretext. Für eine Behörde, die Zugangsdaten für zentrale Netzwerkinfrastruktur verwaltet, entfällt dadurch eine ganze Kategorie des Risikos serverseitiger Sicherheitsvorfälle.

Technische Integration

Die Bereitstellung erfolgte über Docker, sodass das Team schnell eine funktionsfähige Instanz aufsetzen und sie mit echten Infrastruktur-Zugangsdaten statt mit einem Demo-Datensatz testen konnte.  Die Migration der bestehenden Datenbanken des Teams lief fehlerfrei über die Importschnittstelle von Passwork. Die schnelle Testbereitstellung und die saubere Migration ließen das Team zügig von der Evaluierung in den produktiven Einsatz übergehen.

Ergebnisse: Von statischen Dateien zu einem zentralen Echtzeitsystem

Auerbach hat seine dateibasierten Tresore zugunsten eines zentralen Systems aufgegeben, das für das gesamte Team in Echtzeit aktualisiert wird. Zugangsdaten werden jetzt zentral rotiert und versioniert, wodurch das Risiko veralteter Kopien aus den früheren Lösungen entfällt. Das Team berichtete zudem von Zeitersparnissen durch die Browser-Erweiterung von Passwork bei der täglichen Infrastrukturarbeit.

"In der modernen IT-Verwaltung darf die Passwortverwaltung keinen Engpass
darstellen. Passwork hat uns die Flexibilität und Sicherheit zurückgegeben,
die uns bei statischen, dateibasierten Tresoren gefehlt haben." — Systemadministrationsteam der Stadt Auerbach

Im Mittelpunkt von Auerbachs Evaluierung stand eine konkrete Sicherheitslücke: die Verschlüsselung und Zugriffskontrolle für Zugangsdaten kritischer Infrastruktursysteme. Verschlüsselungsarchitektur und granulare Zugriffskontrolle wogen ebenso schwer wie die alltägliche Benutzerfreundlichkeit – das Team brauchte ein System, das für sensible Zugriffe sicher genug, aber zugleich einfach genug war, um es abteilungsübergreifend ohne Einarbeitungszeit einzuführen.

Fazit

Auerbachs Umstieg zeigt, dass einzelne dateibasierte Passwort-Tools nicht an dem Punkt an ihre Grenzen stoßen, an dem die Anforderungen an Zugriffskontrolle und Audit das übersteigen, was eine gemeinsam genutzte Datei leisten kann. Ein Team, das kritische kommunale Infrastruktur verwaltet, ist demselben Risiko ausgesetzt wie ein Großunternehmen, sobald Zugangsdaten ohne rollenbasierte Berechtigungen oder eine zentrale, verbindliche Datenquelle geteilt werden. Passwork hat diese Lücke für Auerbach mit einer zentralen Zero-Knowledge-Architektur geschlossen.

"Mit Passwork können wir nahtlos im Team arbeiten, in unseren täglichen
Aufgaben eine hohe Leistung halten und die volle Kontrolle über unsere
eigene Infrastruktur behalten." — Systemadministrationsteam der Stadt Auerbach

Stadt Pegnitz: Dateisynchronisierungskonflikte mit Passwork lösen

Pegnitz, eine bayerische Stadt bei Nürnberg, betrieb die kommunale IT mit einem dateibasierten Tresor, der keinen gleichzeitigen Zugriff verarbeiten konnte, sodass Administratoren jede Änderung mündlich abstimmen mussten. Das Team wechselte zur selbstgehosteten Plattform von Passwork für einen Echtzeit-Zugriff mehrerer Nutzer auf Zugangsdaten.

PassworkPasswork Team

Zugangsdaten für KI-Agenten: 7 Regeln für sichere Zugriffskontrolle

KI-Agenten übertreffen in den meisten Unternehmen inzwischen die Zahl der Mitarbeiter und verfügen über aktive Zugangsdaten. Sie handeln auf Basis überzeugend wirkender Texte – eine Eigenschaft, die aus schwachen Zugangsdatenkontrollen ein unternehmensweites Risiko macht. Dieser Artikel zeigt, wie man Zugangsdaten von Agenten eingrenzt, isoliert und widerruft, um eine einzelne Kompromittierung einzudämmen.

PassworkPasswork Team

Kindernothilfe: Globale Mitarbeiterzusammenarbeit mit Passwork vereinfachen

Kindernothilfe, eine der größten Kinderhilfsorganisationen Europas, benötigte einen skalierbaren Passwortmanager für ein global verteiltes Team. Die Organisation entschied sich für Passwork wegen des Self-Hostings, SSO über SAML2 und einer intuitiven Benutzeroberfläche, die die länderübergreifende Zugriffsverwaltung vereinfachte.

PassworkAlex Muntyan

Auerbach in der Oberpfalz es una pequeña localidad de 9470 habitantes en la región bávara del Alto Palatinado, en el distrito de Amberg-Sulzbach. La ciudad combina una historia industrial activa con su histórica plaza del mercado: aquí se extrajo mineral de hierro durante siglos, y ese legado sigue siendo visible en su carácter actual. El antiguo emplazamiento de la mina Maffei todavía conserva en pie sus torres de extracción, y hoy alberga un museo minero y un festival cultural periódico. 

Ese enfoque práctico se traslada también a la gestión municipal: el ayuntamiento obtuvo el estatus de Fairtrade Town en 2024, lo renovó en 2026 y mantiene la misma postura orientada a la sostenibilidad y la rendición de cuentas en el resto de sus iniciativas.

La misma lógica se aplica a la TI. Gestionar infraestructura crítica implica mantener el control sobre los procesos esenciales, incluida la forma en que se protegen las credenciales. El equipo de administración de sistemas de Auerbach eligió una plataforma autoalojada con cifrado de conocimiento cero, combinando un control de acceso estricto con soberanía total sobre los datos sensibles.

El reto: La arquitectura basada en archivos se convirtió en un riesgo de seguridad

Un equipo de administradores de sistemas gestiona la infraestructura de TI de Auerbach. Antes de Passwork, el equipo utilizaba dos gestores de contraseñas de código abierto independientes, basados en el mismo formato de base de datos (uno basado en navegador y el otro una aplicación de escritorio), lo que dividía el almacenamiento de credenciales entre ambos.

Ambas herramientas se basaban en una única arquitectura de archivos, donde todas las credenciales residen en un archivo cifrado compartido por todo el equipo: un modelo poco adecuado para las necesidades de acceso multiusuario y sensible de la TI municipal. Esto provocaba fallos de sincronización y conflictos de bloqueo de archivos, lo que exigía una supervisión manual del acceso de escritura, y dejaba una brecha mayor: sin permisos basados en roles ni control de acceso granular.

Compartir el archivo de la bóveda por canales no seguros generaba dos riesgos: 

• Un archivo de base de datos enviado por correo electrónico o almacenado en una unidad compartida sin cifrar es un único punto de fallo si se intercepta 
• Sin una fuente de verdad centralizada, podían seguir circulando copias de credenciales obsoletas, de modo que alguien podía usar sin saberlo una contraseña que ya había sido rotada

Para un equipo de TI gubernamental que gestiona el acceso a infraestructura esencial, este es precisamente el tipo de exposición que los marcos de seguridad están diseñados para prevenir.

Solución: Passwork se ajustó a las prioridades de seguridad y coherencia de Auerbach

La búsqueda de Auerbach se centró en dos prioridades: la seguridad de los datos y la coherencia de las credenciales en una base de datos centralizada, en lugar de un conjunto de archivos sincronizados de forma dispersa. La interfaz de Passwork, pensada para administradores de sistemas y para la colaboración estructurada en equipo y no para el uso individual de consumo, fue la primera razón para considerarla.

El factor decisivo para iniciar una prueba fue la arquitectura de seguridad documentada del proveedor: un cifrado de conocimiento cero que el equipo podía verificar antes de comprometerse.

Lo que Auerbach necesitaba de una nueva solución

Las prioridades de seguridad y coherencia de Auerbach exigían tres características arquitectónicas específicas: implementación on-premise, cifrado del lado del cliente y una estructura de datos capaz de escalar con la infraestructura del municipio. Cada una resolvía una limitación concreta de la configuración basada en archivos que el equipo utilizaba anteriormente.

• Implementación autoalojada y on-premise para un control total sobre los datos sensibles en los propios servidores del municipio
• Cifrado de conocimiento cero para eliminar la exposición de credenciales y claves de cifrado en el servidor
• Estructura de bóvedas y carpetas para organizar el acceso por componente de infraestructura o sistema cliente

El cifrado de conocimiento cero significa que el servidor nunca tiene acceso a los datos sin cifrar ni a las claves de cifrado. Los datos se cifran en el lado del cliente antes de transmitirse o almacenarse. Un administrador o un atacante con acceso total al servidor solo ve texto cifrado. Para un organismo del sector público que gestiona credenciales de infraestructura de red esencial, esto elimina por completo una categoría de riesgo de vulneración en el servidor.

Integración técnica

La implementación se realizó mediante Docker, lo que permitió al equipo poner en marcha una instancia funcional con rapidez y probarla con credenciales reales de infraestructura en lugar de un conjunto de datos de demostración.  La migración desde las bases de datos existentes del equipo se realizó a través de la interfaz de importación de Passwork sin errores. La rápida implementación de prueba y la migración limpia permitieron al equipo pasar de la evaluación a la producción con rapidez.

Resultados: De archivos estáticos a un sistema centralizado en tiempo real

Auerbach retiró sus bóvedas basadas en archivos en favor de un sistema centralizado que se actualiza en tiempo real para todo el equipo. Las credenciales ahora se rotan y versionan de forma centralizada, lo que elimina el riesgo de copias obsoletas de las soluciones anteriores. El equipo también señaló ahorros de tiempo gracias a la extensión de navegador de Passwork en el trabajo diario de infraestructura.

«En la administración de TI moderna, la gestión de contraseñas no debería ser
un cuello de botella. Passwork nos devolvió la flexibilidad y la seguridad que
nos faltaban con las bóvedas estáticas basadas en archivos.» — Stadt Auerbach systems administration team

La evaluación de Auerbach se centró en una brecha de seguridad concreta: cifrar y controlar el acceso a las credenciales de los sistemas de infraestructura crítica. La arquitectura de cifrado y el control de acceso granular tuvieron el mismo peso que la usabilidad diaria: el equipo necesitaba un sistema lo bastante seguro para el acceso sensible, pero lo bastante sencillo para implantarlo en todo el departamento sin curva de aprendizaje.

Conclusión

La migración de Auerbach demuestra que las herramientas de contraseñas basadas en un único archivo alcanzan su límite en el momento en que los requisitos de control de acceso y auditoría superan lo que un archivo compartido puede ofrecer. Un equipo que gestiona infraestructura municipal crítica se enfrenta a la misma exposición que una gran empresa en cuanto las credenciales se comparten sin permisos basados en roles ni una única fuente de verdad. Passwork cerró esa brecha para Auerbach con una arquitectura centralizada de conocimiento cero.

«Con Passwork, podemos trabajar sin problemas en equipo, mantener un
buen rendimiento en nuestras tareas diarias y conservar el control total dentro de
nuestra propia infraestructura.» — Stadt Auerbach systems administration team

Stadt Pegnitz: Resolución de conflictos de sincronización de archivos con Passwork

Pegnitz, una localidad bávara cercana a Núremberg, gestionaba su TI municipal con una bóveda basada en archivos incapaz de gestionar el acceso simultáneo, lo que obligaba a los administradores a coordinar cada cambio de forma verbal. El equipo migró a la plataforma autoalojada de Passwork para un acceso a credenciales multiusuario en tiempo real.

PassworkPasswork Team

Credenciales de agentes de IA: 7 reglas para un control de acceso seguro

Los agentes de IA ya superan en número a los empleados en la mayoría de las empresas y manejan credenciales activas. Actúan a partir de texto persuasivo, un hábito que convierte unos controles de credenciales débiles en un riesgo para toda la flota. Este artículo muestra cómo delimitar, aislar y revocar las credenciales de los agentes para contener un único compromiso de seguridad.

PassworkPasswork Team

Kindernothilfe: Simplificación de la colaboración global de los empleados con Passwork

Kindernothilfe, una de las mayores organizaciones de ayuda a la infancia de Europa, necesitaba un gestor de contraseñas escalable para un equipo distribuido globalmente. Eligieron Passwork por su autoalojamiento, el inicio de sesión único (SSO) mediante SAML2 y una interfaz intuitiva que simplificó la gestión de accesos entre fronteras.

PassworkAlex Muntyan

Auerbach in der Oberpfalz is a small town of 9,470 residents in Bavaria's Upper Palatinate region, in the Amberg-Sulzbach district. The town carries a working, industrial history alongside its historic market square: iron ore was mined here for centuries, and that legacy is still visible in its character today. The former Maffei mine site still has its winding towers standing, and the site now hosts a mining museum and a recurring cultural festival. 

The practical approach carries over into local governance: the municipality earned Fairtrade Town status in 2024, renewed it in 2026, and takes the same sustainability-minded, accountability-driven stance across its other initiatives.

The same logic applies to IT. Managing critical infrastructure means retaining control over core processes, including how credentials are secured. Auerbach's system administration team chose a self-hosted platform with zero-knowledge encryption, combining strict access control with full sovereignty over sensitive data.

The challenge: File-based architecture became a security liability

A team of system administrators manages Auerbach's IT infrastructure. Before Passwork, the team relied on two separate open-source password managers built on the same underlying database format — one browser-based, the other a desktop application — splitting credential storage between them.

Both tools relied on a single file-based architecture, where all credentials live in one encrypted file shared across the team — a model unsuited to the sensitive, multi-user access needs of municipal IT. This caused sync failures and file-locking conflicts, requiring manual oversight of write access, and left a bigger gap: no role-based permissions and no granular access control.

Sharing the vault file over insecure channels created two risks: 

• A database file sent by email or stored on an unencrypted shared drive is a single point of failure if intercepted. 
• Without a centralized source of truth, outdated credential copies could stay in circulation, so someone might unknowingly use a password that had already been rotated.

For a government IT team managing access to core infrastructure, this is the kind of exposure that security frameworks are designed to prevent.

Solution: Passwork matched Auerbach's security and consistency priorities

Auerbach's search centered on two priorities: data security and credential consistency across a centralized database, rather than a set of loosely synced files. Passwork's interface, designed for system administrators and structured team collaboration rather than individual consumer use, was the first reason to consider it.

The deciding factor for starting a trial was the vendor's documented security architecture: zero-knowledge encryption that the team could verify before committing.

What Auerbach needed from a new solution

Auerbach's security and consistency priorities required three specific architectural features: on-premise deployment, client-side encryption, and a data structure that could scale with the municipality's infrastructure. Each addressed a specific limitation of the team's previous file-based setup.

• Self-hosted, on-premise deployment for full control over sensitive data on the municipality's own servers
• Zero-knowledge encryption to eliminate server-side exposure of credentials and encryption keys
• Vault and folder structure to organize access by infrastructure component or client system

Zero-knowledge encryption means the server never has access to unencrypted data or the encryption keys. Data is encrypted client-side before it is transmitted or stored. An administrator or attacker with full server access sees only ciphertext. For a public sector body handling credentials to core network infrastructure, this removes an entire category of server-side breach risk.

Technical integration

Deployment ran through Docker, letting the team stand up a working instance quickly and test it against real infrastructure credentials instead of a demo dataset.  Migration from the team's existing databases went through Passwork's import interface without errors. The fast test deployment and clean migration let the team move from evaluation to production quickly.

Results: From static files to a real-time, centralized system

Auerbach retired its file-based vaults for a centralized system that updates in real time across the team. Credentials are now rotated and versioned centrally, removing the stale-copy risk of the previous solutions. The team also reported time savings from Passwork's browser extension in daily infrastructure work.

"In modern IT administration, password management shouldn’t be
a bottleneck. Passwork gave us back the flexibility and security we
were missing with static file-based vaults." — Stadt Auerbach systems administration team

Auerbach's evaluation centered on a specific security gap: encrypting and controlling access to credentials for critical infrastructure systems. Encryption architecture and granular access control carried equal weight with daily usability — the team needed a system secure enough for sensitive access, but simple enough to run department-wide without a learning curve.

Conclusion

Auerbach's migration shows that single file-based password tools reach their limit not at the point where access control and audit requirements outgrow what a shared file can provide. A team managing critical municipal infrastructure faces the same exposure as a large enterprise once credentials are shared without role-based permissions or a single source of truth. Passwork closed that gap for Auerbach with a centralized, zero-knowledge architecture.

"With Passwork, we can work seamlessly as a team, keep strong
performance in our daily tasks, and maintain full control within our own
infrastructure." — Stadt Auerbach systems administration team

Stadt Pegnitz: Solving file-sync conflicts with Passwork

Pegnitz, a Bavarian town near Nuremberg, ran municipal IT on a file-based vault that couldn’t handle concurrent access, forcing administrators to coordinate every edit verbally. The team moved to Passwork’s self-hosted platform for real-time, multi-user credential access.

PassworkPasswork Team

AI agent credentials: 7 rules for secure access control

AI agents now outnumber employees inside most companies and hold live credentials. They act on convincing text, a habit that turns weak credential controls into a fleet-wide risk. This article shows how to scope, isolate, and revoke agent credentials to contain a single compromise.

PassworkPasswork Team

Kindernothilfe: Simplifying global employee collaboration with Passwork

Kindernothilfe, one of Europe’s largest child aid organizations, needed a scalable password manager for a globally distributed team. They chose Passwork for self-hosting, SSO via SAML2, and an intuitive interface that simplified access management across borders.

PassworkAlex Muntyan

As notícias de cibersegurança de setembro de 2026 foram dominadas por tokens forjados, sessões reproduzidas e chaves de API divulgadas que continuaram a funcionar depois de a palavra-passe ter sido alterada, ou que nunca a exigiram. Duas vulnerabilidades constam já do catálogo Known Exploited Vulnerabilities da CISA e uma chave de fornecedor divulgada colocou em risco mais de 100 000 sites.

• Cisco ISE: CVE-2026-76460, um contorno de autenticação com exploração ativa confirmada (Cisco).
• EvilTokens: a Microsoft desarticulou um serviço de phishing por código de dispositivo associado a mais de 12 000 caixas de correio comprometidas em mais de 10 000 organizações (Microsoft).
• Brevo e Cloudflare: uma chave de API comprometida colocou mais de 100 000 sites em risco potencial (Sansec).
• JFrog Artifactory: uma falha explorada em honeypots para gerar tokens de administrador (SecurityWeek).
• Cleo Harmony: um exploit público para uma falha nos tokens de atualização JWT (SecurityWeek).
• CyberArk: 10 boletins de segurança em quatro datas, incluindo um crítico (CyberArk).
• Chaves de GitHub App: a GitGuardian verificou que 474 de 4802 chaves privadas divulgadas continuavam válidas e se autenticavam como 440 aplicações (GitGuardian).
• NIST IR 8587: orientações finais sobre a proteção de tokens e asserções, publicadas a 15 de setembro (NIST).

Cada caso abaixo mostra uma forma diferente de uma credencial continuar a funcionar quando já deveria ter deixado de o fazer: forjada, reproduzida, divulgada ou gerada a pedido. Seguem-se os detalhes, as versões afetadas e as correções, com uma breve lista de ações ao nível da equipa no final.

Exploração ativa de um contorno de autenticação no Cisco Identity Services Engine (CVE-2026-76460)

A Cisco publicou, a 16 de setembro de 2026, um aviso sobre o CVE-2026-76460, uma vulnerabilidade crítica de contorno de autenticação, explorável sem autenticação, numa API do Identity Services Engine (ISE). A Cisco classifica-a com CVSS 3.1 Base 10,0 (crítica) e confirmou a exploração ativa. A CISA acrescentou o CVE ao seu catálogo Known Exploited Vulnerabilities no mesmo dia.

O que aconteceu: Um pedido especialmente construído para o endpoint da API afetado permite a um atacante contornar a interface de gestão web do ISE e obter acesso não autorizado a um dispositivo ISE ou ISE-PIC afetado, sem credenciais válidas. O PSIRT da Cisco confirmou ter conhecimento de ataques em ambiente real. A data exata em que a exploração começou não foi divulgada.

Porque isto importa: O ISE é uma plataforma de políticas de acesso à rede. O acesso não autorizado pode criar um risco grave, dependente de cada implementação, para as operações de administração e de políticas, mas as fontes disponíveis não demonstram que as decisões de RBAC ou de MFA a jusante de todos os clientes tenham sido alteradas. O impacto depende da forma como cada organização implementou o ISE.

A lição defensiva: A Cisco indica que nenhuma solução alternativa resolve a falha. A atualização para uma versão corrigida é a correção completa. Como mitigação temporária, a Cisco recomenda listas de controlo de acesso de infraestrutura (iACL) que permitam apenas o tráfego de gestão e de plano de controlo necessário para o dispositivo afetado. Reveja o access.log de cada nó em busca de nomes de utilizador suspeitos e cruze os registos de rede e de firewall fora do próprio equipamento. Estes passos são de deteção e resposta e não substituem a aplicação da correção.

Fontes: Cisco; CISA KEV

A Microsoft desarticula o EvilTokens, um serviço de phishing por código de dispositivo OAuth

A 22 de setembro de 2026, a Digital Crimes Unit da Microsoft, em colaboração com parceiros, desarticulou a infraestrutura do EvilTokens, uma plataforma de phishing como serviço associada a mais de 12 000 caixas de correio comprometidas em mais de 10 000 organizações em todo o mundo.

O que aconteceu: O EvilTokens abusou dos fluxos de autorização de dispositivos do OAuth 2.0, o mecanismo concebido para dispositivos sem navegador, como televisores inteligentes ou ferramentas CLI, para levar os utilizadores a aprovar um início de sessão em nome do atacante. Separadamente, a Microsoft divulgou atividade de engenharia social com o tema das passkeys, observada desde maio de 2026. Numa das sequências investigadas, uma isca com passkeys conduziu a phishing por código de dispositivo. Noutros padrões investigados, os atacantes recorreram a pretextos de apoio técnico ou registaram métodos de autenticação controlados pelo atacante. Os relatórios da Microsoft não demonstram que todas as sequências tenham combinado todos estes passos numa única cadeia de ataque.

Porque isto importa: O phishing por código de dispositivo contorna as partes da autenticação que recebem mais atenção defensiva. Não há uma página de início de sessão falsa para identificar nem uma palavra-passe introduzida num site do atacante. A vítima aprova o início de sessão na página legítima da própria Microsoft, convencida de que trata de um procedimento de rotina. Ainda assim, uma vítima sem sessão Microsoft ativa pode continuar a ser solicitada a introduzir uma palavra-passe real e a responder a um desafio de MFA, pelo que esta técnica não elimina, em todos os casos, cada etapa de autenticação.

A lição defensiva: Desative os fluxos de autenticação por código de dispositivo para os utilizadores que não precisam deles do ponto de vista operacional e monitorize o volume anómalo de inícios de sessão por código de dispositivo como sinal de deteção. Quando o fluxo for genuinamente necessário, condicione-o a uma política de acesso condicional.

Fontes: Microsoft; Microsoft (atividade com o tema das passkeys)

Uma única chave de API da Cloudflare com privilégios excessivos colocou em risco mais de 100 000 sites

A 14 de setembro de 2026, atacantes utilizaram uma chave de API da Cloudflare comprometida e com privilégios amplos, pertencente à Brevo, uma plataforma de e-mail e marketing, para implementar um Cloudflare Worker malicioso que alterou recursos incorporados da Brevo em sites de clientes.

O que aconteceu: A telemetria da Sansec registou o Worker malicioso a servir conteúdo das 16:05 às 20:13 UTC de 14 de setembro, cerca de quatro horas. O relatório do incidente da Brevo descreve o Worker como ativo durante cerca de cinco horas e meia, uma janela mais longa do que a observada diretamente pela Sansec. A Sansec estimou que mais de 100 000 sites que utilizam componentes da Brevo afetados poderão ter estado expostos a conteúdo malicioso durante esse período.

Porque isto importa: Uma única chave de API da Cloudflare, de longa duração e com permissões totais, associada a um fornecedor de automatização de marketing, tornou-se um canal de distribuição de código malicioso por um grande número de sites de terceiros. As chaves de API de nuvem com âmbitos amplos e sem expiração são precisamente o tipo de credencial que a política tradicional de palavras-passe não abrange.

A lição defensiva: Limite as chaves de API ao conjunto mínimo de permissões de que uma integração realmente necessita, defina prazos de expiração mesmo para chaves ao nível do serviço e execute uma análise contínua de segredos nos repositórios e nos pipelines de implementação, e não apenas nos cofres de palavras-passe dos colaboradores. A monitorização de implementações inesperadas de Workers ou de alterações de encaminhamento teria provavelmente permitido detetar o problema mais depressa do que uma auditoria manual.

Fontes: Sansec; Brevo

Falha do JFrog Artifactory utilizada para gerar tokens de administrador (CVE-2026-82329)

A JFrog publicou uma correção para o CVE-2026-82329 a 28 de agosto de 2026. A 1 de setembro, a WatchTowr reportou atividade em honeypots compatível com a exploração da falha por atacantes para gerar tokens de administrador.

O que aconteceu: Os honeypots da WatchTowr captaram tentativas de exploração a partir de um pequeno número de IPs de origem, algumas das quais pareciam ser apenas atividade de verificação e não ataques de seguimento. Isto é prova de que a vulnerabilidade é explorável e está a ser sondada. Não demonstra um varrimento generalizado da internet nem a exploração em massa confirmada de instâncias de clientes.

Porque isto importa: Os repositórios de artefactos situam-se perto do centro da cadeia de fornecimento de software. Mantêm relações de confiança de federação com outros repositórios e transportam com frequência credenciais incorporadas para sistemas a jusante. Um atacante que consiga gerar um token de administrador não precisa de o roubar: cria acesso válido a pedido.

A lição defensiva: No caso do Artifactory self-hosted, atualize para a versão corrigida do respetivo ramo: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 ou 7.161.20. A JFrog afirma que os ambientes de nuvem afetados já foram reforçados. Se os registos mostrarem exploração ou emissão suspeita de tokens, revogue e volte a emitir os tokens de administrador potencialmente expostos e audite as configurações de federação. Os relatórios disponíveis sustentam a exploração observada em honeypots, e não o comprometimento confirmado de instâncias de clientes.

Fontes: JFrog; SecurityWeek

Exploit público para uma falha nos tokens de atualização JWT do Cleo Harmony (CVE-2026-84115)

Foi reportado um exploit público para o CVE-2026-84115 a 2 de setembro de 2026, pouco depois de o registo do CVE ter sido publicado, a 1 de setembro.

O que aconteceu: A falha afeta as versões do Cleo Harmony até à 5.8.1.10, inclusive, e está corrigida no Harmony 5.8.1.11. O registo do CVE descreve um problema explorável remotamente no JWT Refresh Token Handler de /api/connections: a manipulação do argumento Bearer resulta numa gestão indevida de privilégios. A SecurityWeek descreve o mesmo problema como uma falha que permite contornar a autenticação e elevar privilégios. Os relatórios disponíveis estabelecem a possibilidade de exploração pública e a reprodução por investigadores. Não demonstram a exploração confirmada de sistemas de clientes, nem que um token manipulado persista para além da expiração da sessão original.

Porque isto importa: Os tokens de atualização destinam-se a prolongar uma sessão de forma discreta, sem obrigar a um novo início de sessão. Uma falha na forma como um deles é validado transforma essa funcionalidade de conveniência num potencial risco de persistência, o que é motivo suficiente para aplicar a correção mesmo sem exploração confirmada.

A lição defensiva: Atualize para o Harmony 5.8.1.11 com brevidade. Se houver suspeita de exposição, siga as orientações atuais da Cleo, reveja as alterações de autenticação e de privilégios do período em causa e revogue os tokens de atualização pendentes quando a implementação for compatível com esse controlo. A existência de um exploit público não confirma, por si só, comprometimento nem acesso persistente.

Fontes: NVD; SecurityWeek

A CyberArk publica dez boletins de segurança em toda a sua linha de produtos PAM

A CyberArk publicou 10 boletins de segurança em setembro de 2026, em quatro lotes datados.

O que aconteceu: A CyberArk publicou 10 boletins de segurança em quatro lotes durante setembro de 2026, que tratam problemas de gravidade alta em agentes de gestão de privilégios em endpoints, componentes self-hosted de gateway e de cofre, análise de acessos privilegiados e gestão de credenciais de bases de dados, bem como um problema crítico (CA26-44) que afeta determinadas versões self-hosted do Password Vault Web Access (PVWA).

Porque isto importa: Os sistemas de gestão de acessos privilegiados (PAM) gerem ou dão acesso, com frequência, a credenciais privilegiadas e a infraestrutura sensível. Um conjunto concentrado de atualizações de segurança é um lembrete de que estes ambientes exigem uma gestão contínua de correções, uma governação de acessos clara e uma auditabilidade fiável. Os avisos não indicam, por si só, exploração ativa.

A lição defensiva: As organizações que utilizam os produtos afetados devem rever os avisos e dar prioridade à correção de acordo com a gravidade, a exposição e o impacto potencial nos sistemas relacionados com credenciais. De um modo mais geral, as equipas de segurança devem manter visibilidade sobre quem pode aceder a credenciais sensíveis e ser capazes de rever esse acesso quando necessário.

Fonte: CyberArk; quadro de boletins da CyberIAM

As chaves privadas de GitHub App divulgadas continuam a funcionar muito tempo depois da exposição

A GitGuardian testou 4802 chaves privadas de GitHub App divulgadas, encontradas em fontes públicas, e verificou que 474 continuavam a autenticar-se como 440 aplicações ativas distintas.

O que aconteceu: Uma chave privada de GitHub App não tem expiração automática e pode permanecer utilizável até ser revogada ou eliminada manualmente. Das 474 chaves ainda válidas testadas pela GitGuardian, 207 tinham permissão de escrita no conteúdo de repositórios, 40 podiam administrar runners self-hosted, 98 podiam controlar workflows e 44 detinham privilégios de administração da organização. Uma chave incluída num commit há anos pode continuar a autenticar-se se não tiver sido revogada ou eliminada.

Um padrão relacionado surgiu numa falha na gestão de APIs da WSO2, o CVE-2026-5430. O aviso data de maio de 2026 e o CVE foi publicado em agosto. A notícia de setembro foi a divulgação de exploração, e não uma nova divulgação da falha. Um atacante pode construir um JWT com um algoritmo de assinatura não admitido e explorar a validação defeituosa da WSO2 para contornar a autenticação. O serviço não precisa de emitir ele próprio um token. O honeypot da WatchTowr captou, a 13 de setembro, JWT forjados com privilégios de administrador contra o serviço, e a CISA acrescentou o CVE ao seu catálogo Known Exploited Vulnerabilities a 24 de setembro. As credenciais de back-end, as chaves de consumidor ou os segredos foram reportados como potencialmente acessíveis, e não como roubados de forma confirmada.

Porque isto importa: Uma fuga pública cria um acesso potencialmente persistente até a chave ser revogada ou eliminada. Por si só, não prova que a chave tenha sido utilizada nem que os dados tenham sido acedidos. O caso da WSO2 mostra um padrão relacionado uma camada abaixo na pilha: um atacante não precisa de forma alguma de uma chave divulgada se a própria lógica de validação puder ser enganada para aceitar uma chave forjada.

A lição defensiva: Mantenha um responsável e um processo documentado de rotação e revogação para cada chave de GitHub App. Se a exposição for suspeita ou confirmada, gere uma chave de substituição e revogue ou elimine prontamente a antiga; a rotação periódica reduz o tempo de exposição, embora o GitHub não prescreva um calendário universal. Nas implementações da WSO2, aplique a correção do fabricante, reveja os registos do período de exploração de setembro e faça a rotação das credenciais a que a camada de gestão de APIs tinha acesso.

Fontes: GitGuardian; documentação do GitHub; aviso da WSO2; The Hacker News

O NIST e a CISA finalizam orientações sobre a proteção de tokens de identidade e de acesso

O NIST e a CISA finalizaram o IR 8587 a 15 de setembro de 2026, após um rascunho público inicial de 22 de dezembro de 2025.

O que aconteceu: As orientações de implementação destinam-se principalmente às agências federais e aos fornecedores de serviços de nuvem que estas utilizam, e abrangem tokens de identidade, tokens de acesso e asserções em cenários de SSO, federação e acesso a APIs. As suas recomendações resumem práticas de gestão de chaves, verificação de tokens, ciclo de vida (incluindo duração e revogação) e monitorização contínua, com as responsabilidades repartidas entre fornecedores, agências consumidoras e consumidores de nuvem.

Porque isto importa: Várias das falhas descritas acima (JWT forjados, tokens de administrador gerados através de falhas de validação, chaves de API sem expiração) enquadram-se nas categorias abordadas por este relatório: lacunas de verificação, falta de controlos de ciclo de vida e responsabilidade pouco clara entre fornecedor e cliente quanto à revogação. Essa sobreposição é útil mesmo para organizações fora do setor federal.

A lição defensiva: Utilize o NIST IR 8587 como lista de verificação de trabalho face às práticas atuais: confirme que a duração dos tokens é limitada, que os percursos de revogação são testados e não apenas documentados, e que o registo de sessões capta detalhe suficiente para reconstituir, a posteriori, um incidente baseado em tokens.

Fontes: NIST; CISA

A CloudSEK detalha o BigBear 2.0, um serviço de atacante intermediário (adversary-in-the-middle) que reproduz sessões do Microsoft 365 após a MFA

A CloudSEK publicou a sua investigação sobre o BigBear 2.0 a 7 de setembro de 2026. A equipa TRIAD descobriu a operação em junho, o que não permite determinar quando começou toda a atividade da campanha.

O que aconteceu: O serviço de atacante intermediário baseado no Evilginx2 retransmitia inícios de sessão do Microsoft 365. Capturava as credenciais e o cookie de sessão emitido pela Microsoft depois de as vítimas concluírem a MFA, e depois permitia aos atacantes reproduzir as sessões autenticadas. O painel da CloudSEK continha 4148 registos de cookies de sessão e 474 autenticações concluídas com a MFA contornada. A BleepingComputer reportou que 258 organizações distintas tinham pelo menos um desses comprometimentos concluídos, enquanto 461 organizações constavam do conjunto de dados de alvos mais alargado. O valor de 4148 é uma contagem de registos de cookies e não uma contagem confirmada de vítimas únicas. (CloudSEK; BleepingComputer)

Porque isto importa: A MFA que a vítima conclui numa página retransmitida através de um proxy não protege nada depois de o cookie de sessão ser roubado. O atacante herda uma sessão já autenticada. Os códigos e as aprovações por notificação push não travam este padrão.

A lição defensiva: Dê prioridade a métodos resistentes a phishing, como as passkeys e as chaves de segurança FIDO2, para os administradores e os utilizadores de alto risco. Reveja as políticas de acesso condicional que associam as sessões a dispositivos em conformidade. Crie alertas para inícios de sessão em que o endereço IP ou o dispositivo da sessão mude pouco depois da MFA.

Fontes: CloudSEK; BleepingComputer

A Okta analisa um dump de infostealer com 44 791 JWT únicos e 1843 tokens ainda válidos na data de divulgação

A Okta publicou, a 9 de setembro de 2026, uma investigação sobre um dump de infostealer de 7 GB publicado no Telegram a 2 de agosto.

O que aconteceu: O dump continha dados de 5871 máquinas infetadas. A Okta identificou 44 791 JWT únicos, incluindo 555 provavelmente relacionados com a autenticação em serviços de IA, além de 2937 JWE relacionados com autenticação. À data da divulgação do dump, 1843 JWT e JWE ainda não tinham expirado. A Okta afirmou que os segredos de sessão não expirados poderiam, potencialmente, ser reproduzidos para contornar a autenticação baseada em credenciais. A investigação não reportou nenhuma reprodução bem-sucedida nem nenhuma tomada de controlo de conta confirmada. O êxito da reprodução depende do serviço e de controlos como o token binding ou as listas de IPs autorizados. (Okta)

Porque isto importa: Os infostealers levam tudo o que se encontra no endpoint, e os tokens fazem parte desse saque. A duração de um token determina durante quanto tempo um segredo roubado continua útil. Os tokens de serviços de IA no conjunto mostram que a exposição abrange agora ferramentas mais recentes, que as equipas adotam muitas vezes fora da gestão central de identidades.

A lição defensiva: Reduza a duração dos tokens sempre que o serviço o permita e associe os tokens a um dispositivo ou a uma rede quando tal for possível. Após uma infeção por infostealer, revogue as sessões e faça a rotação dos segredos, e não apenas a reposição da palavra-passe. Inclua as contas de serviços de IA no inventário de tokens e de chaves de API.

Fonte: Okta

A extensão JeetBot para a Twitch reencaminhava tokens OAuth através de proxies controlados pelo operador

A extensão maliciosa de navegador para a Twitch JeetBot tinha cerca de 30 500 instalações nas lojas, entre o Chrome e o Firefox (uma estimativa de instalações e não uma contagem confirmada de comprometimentos).

O que aconteceu: A Socket verificou que a extensão captava tokens OAuth da Twitch associados à conta e reencaminhava-os num parâmetro de consulta &auth= através de proxies controlados pelo operador. Os relatórios não demonstram que os tokens tenham sido utilizados para atividade não autorizada. A versão 85.8.7 do Firefox (16 de setembro) e a versão 85.8.9 do Chrome (reportada a 25 de setembro) pararam o reencaminhamento. O operador contestou a classificação da extensão como maliciosa, mas reconheceu problemas de segurança e de divulgação. (Socket)

A lição defensiva: Audite as extensões de navegador instaladas e trate como exposto qualquer token que tenha aparecido num URL. Os utilizadores do JeetBot devem revogar o acesso da aplicação à respetiva conta da Twitch.

Fonte: Socket

O Microsoft Entra começa a ativar automaticamente as passkeys antes da retirada da MFA por SMS e por chamada de voz

O Microsoft Entra começou a ativar automaticamente as passkeys a 1 de setembro de 2026 para os utilizadores da nuvem pública já ativados para MFA por SMS ou por chamada de voz na Entra Authentication Methods Policy ou nas definições legadas.

O que aconteceu: Quando estes utilizadores iniciarem sessão da próxima vez e concluírem a MFA, são incentivados a registar uma passkey. Este incentivo pode, em regra, ser adiado, e está disponível uma exclusão temporária ao nível do tenant até 1 de fevereiro de 2027. A entrega de SMS e de chamadas de voz fornecida pela Microsoft termina a 1 de fevereiro de 2027 para a maioria dos utilizadores e a 1 de julho de 2027 para os Global Administrators e os utilizadores externos. As organizações com uma necessidade legítima podem continuar a utilizar SMS ou chamadas de voz através de um fornecedor de telefonia compatível. Essa opção de configuração está prevista para 30 de outubro de 2026.

Porque isto importa: A alteração afasta a predefinição dos fatores baseados no telefone, o tipo que a campanha BigBear 2.0 acima mostra poder ser retransmitido. Os tenants que não façam nada verão agora pedidos de registo e perderão em 2027 a entrega de SMS e de chamadas de voz fornecida pela Microsoft.

A lição defensiva: Inventarie os utilizadores e os processos de serviço que ainda dependem de SMS ou de chamadas de voz. Comece o registo de passkeys pelos administradores e pelos utilizadores externos, cujo prazo é o mais próximo. Decida antes de 1 de fevereiro de 2027 se é necessário um fornecedor de telefonia ou se estes métodos podem ser totalmente retirados.

Fonte: Microsoft Learn

O que isto significa para a equipa

A maioria dos casos deste mês resume-se a credenciais que continuaram a funcionar quando já deveriam ter deixado de o fazer. Seis passos que a equipa pode seguir para evitar problemas semelhantes:

1. Inventariar as credenciais não humanas. Liste as chaves de API, os tokens de contas de serviço, as chaves privadas de GitHub App e os segredos de CI/CD tal como se listam as contas de utilizador. Atribua a cada uma um responsável identificado e um plano documentado de expiração ou rotação. Os casos da Brevo e das GitHub Apps envolveram chaves que ninguém acompanhava.
2. Limitar o âmbito e definir a expiração. Atribua a cada chave apenas as permissões de que a integração necessita e defina uma expiração sempre que o fornecedor a permita. Quando não o permita, agende a rotação manual.
3. Testar a revogação antes de ser necessária. Para cada fornecedor, confirme o que a revogação de uma sessão, de um JWT, de uma concessão OAuth ou de um token de atualização faz realmente. Após um incidente, execute o percurso de revogação de ponta a ponta, em vez de confiar na documentação. Revogue as sessões e faça a rotação dos segredos, e não apenas a reposição da palavra-passe.
4. Fechar as lacunas de OAuth e de sessão. Desative os fluxos de código de dispositivo para os utilizadores que não precisam deles e passe os administradores para passkeys ou chaves FIDO2 antes da retirada do SMS e das chamadas de voz pela Microsoft em 2027. Sempre que for possível, associe as sessões a dispositivos.
5. Corrigir primeiro a infraestrutura de identidade exposta. O Cisco ISE, o JFrog Artifactory, o Cleo Harmony e a WSO2 emitem ou validam o acesso a tudo o que está por trás deles. Trate as respetivas atualizações como prioridade em relação à aplicação rotineira de correções.
6. Registar o suficiente para reconstituir um incidente. Mantenha registos de sessão e de tokens suficientemente detalhados para mostrar quem se autenticou, a partir de onde e com que token. O NIST IR 8587 é uma lista de verificação utilizável para este ponto e para os anteriores.

Para leitura complementar, recomendam-se os guias sobre o ciclo de vida da rotação de segredos e sobre os segredos hardcoded.

Notícias mensais de cibersegurança: Autenticação sob cerco

Os incidentes de agosto de 2026 contornaram totalmente a autenticação: exploits confirmados no N-able N-central e no SharePoint, mais de 9 300 chaves AWS expostas e o Mirage2FA a sequestrar sessões após a MFA. Eis o que as equipas de TI e de segurança precisam de corrigir e auditar em primeiro lugar.

PassworkPasswork Team

Segurança de palavras-passe pós-quântica: o que muda e o que fazer

O algoritmo de Grover quase não afeta uma palavra-passe devidamente protegida com hash. O algoritmo de Shor inutiliza a troca de chaves RSA que a acompanha. Eis a auditoria em 3 camadas que permite determinar qual dos dois é, de facto, o problema.

PassworkPasswork Team

2026 IBM Cost of a Data Breach Report: a ameaça de IA de 6 milhões de dólares que ninguém está a corrigir

Os custos globais das violações atingiram um máximo histórico de 4,99 milhões de dólares em 2026, com uma deteção que demora 247 dias. Os ataques impulsionados por IA aumentam 56 %, mas a verdadeira crise é esta: os defensores implementam IA em todo o lado, exceto onde os atacantes entram. 92 % das organizações afetadas por violações relacionadas com IA não tinham qualquer controlo de acesso adequado.

PassworkAlex Muntyan

Die Cybersecurity-News im September 2026 wurden von gefälschten Tokens, wiederverwendeten Sitzungen und geleakten API-Schlüsseln dominiert, die auch nach einer Passwortänderung weiterfunktionierten oder nie ein Passwort benötigt hatten. Zwei Schwachstellen stehen bereits im Known Exploited Vulnerabilities-Katalog der CISA, und ein geleakter Schlüssel eines Anbieters gefährdete über 100.000 Websites.

• Cisco ISE: CVE-2026-76460, eine Authentifizierungsumgehung mit bestätigter aktiver Ausnutzung (Cisco).
• EvilTokens: Microsoft hat einen Device-Code-Phishing-Dienst zerschlagen, der mit mehr als 12.000 kompromittierten Postfächern in über 10.000 Organisationen in Verbindung steht (Microsoft).
• Brevo und Cloudflare: Ein kompromittierter API-Schlüssel setzte mehr als 100.000 Websites einem potenziellen Risiko aus (Sansec).
• JFrog Artifactory: Eine Schwachstelle, die in Honeypots ausgenutzt wurde, um Administrator-Tokens auszustellen (SecurityWeek).
• Cleo Harmony: Ein öffentlicher Exploit für eine Schwachstelle im JWT-Refresh-Token (SecurityWeek).
• CyberArk: 10 Sicherheitsbulletins an vier Terminen, darunter ein kritisches (CyberArk).
• GitHub-App-Schlüssel: GitGuardian stellte fest, dass 474 von 4.802 geleakten privaten Schlüsseln noch gültig waren und sich als 440 Apps authentifizierten (GitGuardian).
• NIST IR 8587: Finale Leitlinie zum Schutz von Tokens und Assertions, veröffentlicht am 15. September (NIST).

Jeder der folgenden Fälle zeigt eine andere Art, wie Zugangsdaten weiter funktionieren, obwohl sie es nicht mehr sollten: gefälscht, wiederverwendet, geleakt oder auf Abruf ausgestellt. Details, betroffene Versionen und Fixes folgen, mit einer kurzen Liste von Maßnahmen für Teams am Ende.

Aktive Ausnutzung einer Authentifizierungsumgehung in Cisco Identity Services Engine (CVE-2026-76460)

Cisco veröffentlichte am 16. September 2026 einen Sicherheitshinweis zu CVE-2026-76460, einer kritischen, nicht authentifizierten Schwachstelle zur Authentifizierungsumgehung in einer Identity Services Engine (ISE)-API. Cisco bewertet sie mit CVSS 3.1 Base 10.0 (kritisch) und bestätigte eine aktive Ausnutzung. Die CISA fügte die CVE am selben Tag ihrem Known Exploited Vulnerabilities-Katalog hinzu.

Was geschah: Eine speziell gestaltete Anfrage an den betroffenen API-Endpunkt ermöglicht es einem Angreifer, die webbasierte Verwaltungsoberfläche von ISE zu umgehen und ohne gültige Zugangsdaten unbefugten Zugriff auf ein betroffenes ISE- oder ISE-PIC-Gerät zu erlangen. Ciscos PSIRT bestätigte, dass Angriffe in freier Wildbahn bekannt waren. Das genaue Datum, an dem die Ausnutzung begann, wurde nicht offengelegt.

Warum das wichtig ist: ISE ist eine Plattform für Richtlinien zum Netzwerkzugriff. Unbefugter Zugriff könnte je nach Implementierung ein erhebliches Risiko für Verwaltungs- und Richtlinienvorgänge darstellen, aber die verfügbaren Quellen belegen nicht, dass bei jedem Kunden nachgelagerte RBAC- oder MFA-Entscheidungen verändert wurden. Die Auswirkung hängt davon ab, wie eine bestimmte Organisation ISE einsetzt.

Handlungsempfehlung: Laut Cisco behebt kein Workaround die Schwachstelle. Ein Upgrade auf eine fehlerbereinigte Version ist die vollständige Lösung. Als vorübergehende Abhilfemaßnahme empfiehlt Cisco Infrastructure-ACLs (iACLs), die am betroffenen Gerät nur den erforderlichen Management- und Control-Plane-Verkehr zulassen. Prüfen Sie die access.log jedes Knotens auf verdächtige Benutzernamen, und gleichen Sie Netzwerk- und Firewall-Protokolle außerhalb der Appliance selbst ab. Das sind Schritte zur Erkennung und Reaktion, kein Ersatz für das Patchen.

Quellen: Cisco; CISA KEV

Microsoft zerschlägt EvilTokens, einen OAuth-Device-Code-Phishing-Dienst

Am 22. September 2026 zerschlug die Digital Crimes Unit von Microsoft gemeinsam mit Partnern die Infrastruktur hinter EvilTokens, einer Phishing-as-a-Service-Plattform, die mit mehr als 12.000 kompromittierten Postfächern in über 10.000 Organisationen weltweit in Verbindung steht.

Was geschah: EvilTokens missbrauchte OAuth-2.0-Device-Authorization-Flows, den Mechanismus für Geräte ohne Browser, etwa Smart-TVs oder CLI-Tools, um Nutzer dazu zu bringen, eine Anmeldung im Namen des Angreifers zu genehmigen. Microsoft legte separat Social-Engineering-Aktivitäten mit Passkey-Bezug offen, die seit Mai 2026 beobachtet wurden. In einer untersuchten Abfolge führte ein Passkey-Köder zu Device-Code-Phishing. Bei anderen untersuchten Mustern nutzten Angreifer Helpdesk-Vorwände oder registrierten vom Angreifer kontrollierte Authentifizierungsmethoden. Die Berichterstattung von Microsoft belegt nicht, dass jede Abfolge alle diese Schritte zu einer einzigen Angriffskette kombinierte.

Warum das wichtig ist: Device-Code-Phishing umgeht genau die Teile der Authentifizierung, auf die sich die Abwehr am stärksten konzentriert. Es gibt keine gefälschte Login-Seite, die auffällt, und kein Passwort, das auf der Seite eines Angreifers eingegeben wird. Das Opfer genehmigt die Anmeldung über die echte, legitime Seite von Microsoft und hält den Vorgang für Routine. Allerdings kann einem Opfer ohne aktive Microsoft-Sitzung weiterhin ein echtes Passwort und eine MFA-Abfrage angezeigt werden, sodass diese Technik nicht grundsätzlich jeden Authentifizierungsschritt aushebelt.

Handlungsempfehlung: Deaktivieren Sie Device-Code-Authentifizierungsflows für Nutzer, die sie operativ nicht benötigen, und überwachen Sie ein ungewöhnlich hohes Volumen an Device-Code-Anmeldungen als Erkennungssignal. Wo der Flow wirklich erforderlich ist, sichern Sie ihn über eine Richtlinie für bedingten Zugriff ab.

Quellen: Microsoft; Microsoft (Aktivitäten mit Passkey-Bezug)

Ein einzelner überprivilegierter Cloudflare-API-Schlüssel gefährdete über 100.000 Websites

Am 14. September 2026 nutzten Angreifer einen kompromittierten, breit berechtigten Cloudflare-API-Schlüssel der E-Mail- und Marketingplattform Brevo, um einen bösartigen Cloudflare Worker einzusetzen, der von Brevo eingebettete Assets auf Kundenseiten veränderte.

Was geschah: Die Telemetrie von Sansec zeichnete auf, dass der bösartige Worker am 14. September von 16:05 bis 20:13 UTC Inhalte auslieferte, rund vier Stunden lang. Der Incident-Bericht von Brevo beschreibt den Worker als etwa fünfeinhalb Stunden aktiv, ein längeres Zeitfenster, als Sansec direkt beobachtet hat. Sansec schätzte, dass in diesem Zeitraum mehr als 100.000 Websites, die betroffene Brevo-Komponenten einsetzen, bösartigen Inhalten ausgesetzt gewesen sein könnten.

Warum das wichtig ist: Ein einzelner, langlebiger Cloudflare-API-Schlüssel mit vollen Berechtigungen, der an einen Anbieter für Marketing-Automatisierung gebunden war, wurde zum Verteilungskanal für bösartigen Code auf einer großen Zahl von Drittanbieter-Websites. Cloud-API-Schlüssel mit weit gefassten Berechtigungen und ohne Ablaufdatum sind genau der Zugangsdatentyp, den eine klassische Passwortrichtlinie nicht abdeckt.

Handlungsempfehlung: Beschränken Sie API-Schlüssel auf den minimalen Berechtigungsumfang, den eine Integration tatsächlich benötigt, legen Sie auch für Schlüssel auf Servicelevel ein Ablaufdatum fest, und führen Sie kontinuierliches Secret-Scanning nicht nur in Passwort-Tresoren der Mitarbeiter, sondern auch über Repositories und Deployment-Pipelines hinweg durch. Eine Überwachung auf unerwartete Worker-Deployments oder Routing-Änderungen hätte dies wahrscheinlich schneller aufgedeckt als eine manuelle Prüfung.

Quellen: Sansec; Brevo

JFrog-Artifactory-Schwachstelle zur Ausstellung von Admin-Tokens genutzt (CVE-2026-82329)

JFrog veröffentlichte am 28. August 2026 einen Fix für CVE-2026-82329. Am 1. September meldete WatchTowr Honeypot-Aktivitäten, die darauf hindeuten, dass Angreifer die Schwachstelle ausnutzten, um Administrator-Tokens zu generieren.

Was geschah: Die Honeypots von WatchTowr erfassten Ausnutzungsversuche von einer kleinen Zahl von Quell-IPs, von denen einige offenbar nur zur Verifizierung dienten statt zu vollständigen Angriffen zu führen. Das belegt, dass die Schwachstelle ausnutzbar ist und getestet wird. Es belegt kein breites Scannen im gesamten Internet oder eine bestätigte Massenausnutzung von Kundeninstanzen.

Warum das wichtig ist: Artifact-Repositories stehen nahe am Zentrum der Software-Lieferkette. Sie unterhalten Federation-Vertrauensbeziehungen zu anderen Repositories und enthalten häufig eingebettete Zugangsdaten für nachgelagerte Systeme. Ein Angreifer, der einen Admin-Token generieren kann, muss keinen stehlen – er erzeugt gültigen Zugriff auf Abruf.

Handlungsempfehlung: Aktualisieren Sie selbst gehostete Artifactory-Instanzen auf die fehlerbereinigte Version Ihres Branches: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 oder 7.161.20. Laut JFrog waren betroffene Cloud-Umgebungen bereits abgesichert. Wenn Protokolle eine Ausnutzung oder verdächtige Token-Ausstellungen zeigen, widerrufen Sie potenziell offengelegte Admin-Tokens, stellen Sie sie neu aus, und prüfen Sie die Federation-Konfigurationen. Die verfügbaren Berichte stützen eine in Honeypots beobachtete Ausnutzung, nicht eine bestätigte Kompromittierung von Kundeninstanzen.

Quellen: JFrog; SecurityWeek

Öffentlicher Exploit für eine Schwachstelle im JWT-Refresh-Token von Cleo Harmony (CVE-2026-84115)

Ein öffentlicher Exploit für CVE-2026-84115 wurde am 2. September 2026 gemeldet, kurz nachdem der CVE-Eintrag am 1. September veröffentlicht worden war.

Was geschah: Die Schwachstelle betrifft Cleo-Harmony-Versionen bis 5.8.1.10 und ist in Harmony 5.8.1.11 behoben. Der CVE-Eintrag beschreibt ein remote ausnutzbares Problem im JWT-Refresh-Token-Handler unter /api/connections: Die Manipulation des Bearer-Arguments führt zu fehlerhafter Rechteverwaltung. SecurityWeek beschreibt dasselbe Problem als Ermöglichung von Authentifizierungsumgehung und Rechteausweitung. Die verfügbaren Berichte belegen öffentliche Ausnutzbarkeit und eine Reproduktion durch Forscher. Sie belegen keine bestätigte Ausnutzung bei Kundensystemen und auch nicht, dass ein manipulierter Token über den Ablauf der ursprünglichen Sitzung hinaus bestehen bleibt.

Warum das wichtig ist: Refresh-Tokens sollen eine Sitzung unauffällig verlängern, ohne eine erneute Anmeldung zu erzwingen. Eine Schwachstelle in der Validierung macht aus dieser Komfortfunktion ein potenzielles Persistenzrisiko – Grund genug zu patchen, auch ohne bestätigte Ausnutzung.

Handlungsempfehlung: Aktualisieren Sie zügig auf Harmony 5.8.1.11. Bei Verdacht auf eine Gefährdung folgen Sie der aktuellen Anleitung von Cleo, prüfen Sie Authentifizierungs- und Rechteänderungen aus dem relevanten Zeitraum, und widerrufen Sie ausstehende Refresh-Tokens, wo die Implementierung das unterstützt. Die Existenz eines öffentlichen Exploits allein bestätigt weder eine Kompromittierung noch einen fortbestehenden Zugriff.

Quellen: NVD; SecurityWeek

CyberArk veröffentlicht zehn Sicherheitsbulletins für seine PAM-Produktlinie

CyberArk veröffentlichte im September 2026 zehn Sicherheitsbulletins in vier datierten Chargen.

Was geschah: CyberArk veröffentlichte im September 2026 in vier Chargen zehn Sicherheitsbulletins. Sie adressieren Probleme mit hohem Schweregrad in Agenten für Endpoint Privilege Management, selbst gehosteten Gateway- und Vault-Komponenten, Analytik für privilegierten Zugriff und der Verwaltung von Datenbank-Zugangsdaten, sowie ein kritisches Problem – CA26-44 –, das bestimmte selbst gehostete Versionen von Password Vault Web Access (PVWA) betrifft.

Warum das wichtig ist: PAM-Systeme verwalten häufig privilegierte Zugangsdaten und sensible Infrastruktur oder stellen den Zugriff darauf bereit. Eine konzentrierte Reihe von Sicherheitsupdates ist eine Erinnerung daran, dass diese Umgebungen kontinuierliches Patch-Management, klare Zugriffs-Governance und verlässliche Nachvollziehbarkeit erfordern. Die Advisories deuten für sich genommen nicht auf eine aktive Ausnutzung hin.

Handlungsempfehlung: Organisationen, die betroffene Produkte einsetzen, sollten die Advisories prüfen und die Behebung nach Schweregrad, Gefährdung und möglichen Auswirkungen auf zugangsdatenbezogene Systeme priorisieren. Allgemeiner sollten Sicherheitsteams stets im Blick behalten, wer auf sensible Zugangsdaten zugreifen kann, und diesen Zugriff bei Bedarf überprüfen können.

Quelle: CyberArk; CyberIAM-Bulletin-Board

Geleakte private Schlüssel von GitHub Apps funktionieren noch lange nach ihrer Offenlegung

GitGuardian testete 4.802 geleakte private Schlüssel von GitHub Apps, die in öffentlichen Quellen gefunden wurden, und stellte fest, dass sich 474 davon weiterhin als 440 verschiedene aktive Apps authentifizieren ließen.

Was geschah: Ein privater Schlüssel einer GitHub App hat kein automatisches Ablaufdatum und kann so lange nutzbar bleiben, bis er manuell widerrufen oder gelöscht wird. Von den 474 noch gültigen Schlüsseln, die GitGuardian testete, verfügten 207 über Schreibrechte für Repository-Inhalte, 40 konnten selbst gehostete Runner verwalten, 98 konnten Workflows steuern, und 44 besaßen Rechte zur Organisationsverwaltung. Ein Schlüssel, der vor Jahren committet wurde, kann sich weiterhin authentifizieren, wenn er nicht widerrufen oder gelöscht wurde.

Ein verwandtes Muster zeigte sich bei einer Schwachstelle im API-Management von WSO2, CVE-2026-5430. Der Advisory datiert auf Mai 2026, die CVE wurde im August veröffentlicht. Die Nachricht im September war eine Meldung über Ausnutzung, keine neue Offenlegung. Ein Angreifer kann ein JSON Web Token (JWT) mit einem nicht unterstützten Signaturalgorithmus erstellen und die fehlerhafte Validierung von WSO2 ausnutzen, um die Authentifizierung zu umgehen. Der Dienst muss dafür nicht selbst einen Token ausstellen. Der Honeypot von WatchTowr erfasste am 13. September gefälschte JWTs mit Administratorrechten gegen das System, und die CISA fügte die CVE am 24. September ihrem Known Exploited Vulnerabilities-Katalog hinzu. Backend-Zugangsdaten, Consumer-Keys oder Secrets wurden als potenziell erreichbar gemeldet, nicht als bestätigt gestohlen.

Warum das wichtig ist: Ein öffentliches Leak schafft potenziell dauerhaften Zugriff, bis der Schlüssel widerrufen oder gelöscht wird. Es belegt für sich genommen nicht, dass der Schlüssel tatsächlich genutzt oder auf Daten zugegriffen wurde. Der WSO2-Fall zeigt ein verwandtes Muster eine Ebene tiefer im Stack: Ein Angreifer braucht gar keinen geleakten Schlüssel, wenn sich die Validierungslogik selbst dazu verleiten lässt, einen gefälschten Schlüssel zu akzeptieren.

Handlungsempfehlung: Legen Sie für jeden GitHub-App-Schlüssel einen Verantwortlichen und einen dokumentierten Rotations- bzw. Widerrufsprozess fest. Bei Verdacht auf oder Bestätigung einer Gefährdung erzeugen Sie umgehend einen Ersatz und widerrufen oder löschen den alten Schlüssel; eine regelmäßige Rotation verkürzt die Gefährdungsdauer, auch wenn GitHub keinen einheitlichen Rhythmus vorschreibt. Für WSO2-Implementierungen spielen Sie den Fix des Herstellers ein, prüfen Sie die Protokolle für das Ausnutzungsfenster im September, und rotieren Sie die Zugangsdaten, auf die die API-Management-Schicht Zugriff hatte.

Quellen: GitGuardian; GitHub-Dokumentation; WSO2-Advisory; The Hacker News

NIST und CISA finalisieren Leitlinie zum Schutz von Identitäts- und Zugriffstokens

NIST und CISA finalisierten IR 8587 am 15. September 2026, nach einem ersten öffentlichen Entwurf vom 22. Dezember 2025.

Was geschah: Die Implementierungsleitlinie richtet sich vor allem an Bundesbehörden und die von ihnen genutzten Cloud-Dienstanbieter und behandelt Identitätstokens, Zugriffstokens und Assertions in SSO-, Federation- und API-Zugriffsszenarien. Ihre Empfehlungen fassen Praktiken für Schlüsselverwaltung, Token-Verifizierung, Lebenszyklus (einschließlich Gültigkeitsdauer und Widerruf) und kontinuierliche Überwachung zusammen, wobei die Verantwortlichkeiten zwischen Anbietern, nutzenden Behörden und Cloud-Konsumenten aufgeteilt sind.

Warum das wichtig ist: Mehrere der oben beschriebenen Vorfälle – gefälschte JWTs, über Validierungsschwachstellen generierte Admin-Tokens, nie ablaufende API-Schlüssel – fallen in genau die Kategorien, die dieser Bericht behandelt: Lücken bei der Verifizierung, fehlende Lebenszykluskontrollen und unklare Verantwortung zwischen Anbieter und Kunde für den Widerruf. Diese Überschneidung ist auch für Organisationen außerhalb des Bundesbereichs nützlich.

Handlungsempfehlung: Nutzen Sie NIST IR 8587 als praktische Checkliste für die aktuellen Praktiken: Stellen Sie sicher, dass Token-Gültigkeitsdauern begrenzt sind, dass Widerrufswege getestet und nicht nur dokumentiert sind, und dass die Sitzungsprotokollierung genug Details erfasst, um einen tokenbasierten Vorfall nachträglich rekonstruieren zu können.

Quellen: NIST; CISA

CloudSEK beschreibt BigBear 2.0, einen Adversary-in-the-Middle-Dienst, der Microsoft-365-Sitzungen nach der MFA wiederverwendet

CloudSEK veröffentlichte seine Untersuchung zu BigBear 2.0 am 7. September 2026. Das TRIAD-Team entdeckte die Operation im Juni, was nicht belegt, wann die gesamte Kampagnenaktivität begann.

Was geschah: Der auf Evilginx2 basierende Adversary-in-the-Middle-Dienst leitete Microsoft-365-Anmeldungen um. Er erfasste Zugangsdaten und das von Microsoft ausgestellte Sitzungscookie, nachdem Opfer die MFA abgeschlossen hatten, und ließ Angreifer anschließend die authentifizierten Sitzungen wiederverwenden. Das Panel von CloudSEK enthielt 4.148 Sitzungscookie-Datensätze und 474 abgeschlossene, MFA-umgangene Authentifizierungen. BleepingComputer berichtete, dass 258 verschiedene Organisationen mindestens eine solche abgeschlossene Kompromittierung erlitten, während 461 Organisationen im breiteren Zieldatensatz auftauchten. Die Zahl 4.148 ist eine Zählung von Cookie-Datensätzen, keine bestätigte Zahl eindeutiger Opfer. (CloudSEK; BleepingComputer)

Warum das wichtig ist: Eine MFA, die das Opfer auf einer proxybasierten Seite abschließt, schützt nicht mehr, sobald das Sitzungscookie gestohlen ist. Der Angreifer übernimmt eine bereits authentifizierte Sitzung. Codes und Push-Genehmigungen stoppen dieses Muster nicht.

Handlungsempfehlung: Priorisieren Sie phishingresistente Methoden wie Passkeys und FIDO2-Sicherheitsschlüssel für Administratoren und Nutzer mit hohem Risiko. Überprüfen Sie Richtlinien für bedingten Zugriff, die Sitzungen an konforme Geräte binden. Lösen Sie einen Alarm aus, wenn sich IP-Adresse oder Gerät einer Sitzung kurz nach der MFA ändern.

Quellen: CloudSEK; BleepingComputer

Okta analysiert Infostealer-Dump mit 44.791 eindeutigen JWTs, 1.843 Tokens zum Zeitpunkt der Veröffentlichung noch gültig

Okta veröffentlichte am 9. September 2026 eine Untersuchung zu einem 7-GB-Infostealer-Dump, der am 2. August auf Telegram veröffentlicht wurde.

Was geschah: Der Dump enthielt Daten von 5.871 infizierten Rechnern. Okta identifizierte 44.791 eindeutige JWTs, darunter 555, die wahrscheinlich mit der Authentifizierung von KI-Diensten zusammenhängen, sowie 2.937 authentifizierungsbezogene JWEs. Zum Zeitpunkt der Veröffentlichung des Dumps waren 1.843 JWTs und JWEs noch nicht abgelaufen. Laut Okta könnten nicht abgelaufene Sitzungs-Secrets potenziell wiederverwendet werden, um die zugangsdatenbasierte Authentifizierung zu umgehen. Die Untersuchung meldete keine erfolgreiche Wiederverwendung oder eine bestätigte Account-Übernahme. Ob eine Wiederverwendung funktioniert, hängt vom jeweiligen Dienst und von Kontrollen wie Token-Bindung oder IP-Allowlisting ab. (Okta)

Warum das wichtig ist: Infostealer nehmen alles mit, was auf dem Endgerät liegt, und Tokens sind ein Teil dieser Beute. Die Gültigkeitsdauer eines Tokens bestimmt, wie lange ein gestohlenes Secret nützlich bleibt. Die KI-Dienst-Tokens in diesem Datensatz zeigen, dass die Gefährdung inzwischen auch neuere Tools erreicht, die Teams häufig außerhalb des zentralen Identitätsmanagements einführen.

Handlungsempfehlung: Verkürzen Sie Token-Gültigkeitsdauern, wo der Dienst das zulässt, und binden Sie Tokens an ein Gerät oder Netzwerk, wo das unterstützt wird. Widerrufen Sie nach einer Infostealer-Infektion Sitzungen und rotieren Sie Secrets – nicht nur das Passwort zurücksetzen. Nehmen Sie Konten für KI-Dienste in Ihr Inventar von Tokens und API-Schlüsseln auf.

Quelle: Okta

JeetBot-Twitch-Erweiterung leitete OAuth-Tokens über vom Betreiber kontrollierte Proxys weiter

Die bösartige Twitch-Browser-Erweiterung JeetBot verzeichnete über Chrome und Firefox hinweg rund 30.500 Installationen aus dem Store (eine Installationsschätzung, keine bestätigte Zahl kompromittierter Nutzer).

Was geschah: Socket fand heraus, dass die Erweiterung kontobezogene Twitch-OAuth-Tokens erfasste und sie über vom Betreiber kontrollierte Proxys in einem &auth=-Query-Parameter weiterleitete. Die Berichterstattung belegt nicht, dass die Tokens für unbefugte Aktivitäten genutzt wurden. Firefox-Version 85.8.7 (16. September) und Chrome-Version 85.8.9 (gemeldet am 25. September) beendeten die Weiterleitung. Der Betreiber widersprach der Einstufung der Erweiterung als bösartig, räumte aber Sicherheits- und Offenlegungsprobleme ein. (Socket)

Handlungsempfehlung: Prüfen Sie installierte Browser-Erweiterungen, und behandeln Sie jeden Token, der in einer URL aufgetaucht ist, als offengelegt. Nutzer von JeetBot sollten der App den Zugriff auf ihr Twitch-Konto entziehen.

Quelle: Socket

Microsoft Entra aktiviert Passkeys automatisch vor der Abschaltung von SMS- und Sprach-MFA

Microsoft Entra begann am 1. September 2026 damit, Passkeys automatisch für Public-Cloud-Nutzer zu aktivieren, für die SMS- oder Sprach-MFA bereits in der Entra-Richtlinie für Authentifizierungsmethoden oder in den Legacy-Einstellungen aktiviert war.

Was geschah: Wenn diese Nutzer sich das nächste Mal anmelden und die MFA abschließen, werden sie aufgefordert, einen Passkey zu registrieren. Diese Aufforderung lässt sich in der Regel vertagen, und bis zum 1. Februar 2027 steht ein vorübergehendes Opt-out für den Tenant zur Verfügung. Die von Microsoft bereitgestellte SMS- und Sprachzustellung wird für die meisten Nutzer am 1. Februar 2027 und für globale Administratoren und externe Nutzer am 1. Juli 2027 abgeschaltet. Organisationen mit einem berechtigten Bedarf können SMS oder Sprache über einen unterstützten Telefonieanbieter fortführen. Diese Konfigurationsoption ist für den 30. Oktober 2026 geplant.

Warum das wichtig ist: Die Änderung verschiebt den Standard weg von telefonbasierten Faktoren – genau der Art, die laut der oben beschriebenen BigBear-2.0-Kampagne weitergeleitet werden kann. Tenants, die nichts unternehmen, sehen schon jetzt Registrierungsaufforderungen und verlieren 2027 die von Microsoft bereitgestellte SMS- und Sprachzustellung.

Handlungsempfehlung: Erfassen Sie, welche Nutzer und Serviceprozesse noch auf SMS oder Sprache angewiesen sind. Beginnen Sie die Passkey-Registrierung mit Administratoren und externen Nutzern, für die die Frist am frühesten endet. Entscheiden Sie vor dem 1. Februar 2027, ob Sie einen Telefonieanbieter benötigen oder diese Methoden ganz abschalten können.

Quelle: Microsoft Learn

Was das für Ihr Team bedeutet

Die meisten Fälle dieses Monats laufen darauf hinaus, dass Zugangsdaten weiter funktionierten, obwohl sie es nicht mehr sollten. Sechs Schritte, mit denen Ihr Team ähnliche Probleme vermeiden kann:

1. Nicht-menschliche Zugangsdaten inventarisieren. Erfassen Sie API-Schlüssel, Service-Account-Tokens, private Schlüssel von GitHub Apps und CI/CD-Secrets genauso wie Benutzerkonten. Geben Sie jedem einen namentlich benannten Verantwortlichen und einen dokumentierten Plan für Ablauf oder Rotation. In den Fällen Brevo und GitHub App ging es jeweils um Schlüssel, die niemand verfolgt hat.
2. Berechtigungen einschränken und Ablaufdaten setzen. Vergeben Sie für jeden Schlüssel nur die Berechtigungen, die die Integration tatsächlich benötigt, und setzen Sie überall dort ein Ablaufdatum, wo der Anbieter das unterstützt. Wo das nicht möglich ist, planen Sie eine manuelle Rotation.
3. Widerruf testen, bevor Sie ihn brauchen. Prüfen Sie für jeden Anbieter, was der Widerruf einer Sitzung, eines JWT, einer OAuth-Berechtigung oder eines Refresh-Tokens tatsächlich bewirkt. Durchlaufen Sie nach einem Vorfall den gesamten Widerrufsweg, statt sich auf die Dokumentation zu verlassen. Widerrufen Sie Sitzungen und rotieren Sie Secrets – nicht nur das Passwort zurücksetzen.
4. OAuth- und Sitzungslücken schließen. Deaktivieren Sie Device-Code-Flows für Nutzer, die sie nicht benötigen, und wechseln Sie Administratoren vor der Abschaltung von Microsofts SMS- und Sprach-MFA 2027 zu Passkeys oder FIDO2-Schlüsseln. Binden Sie Sitzungen an Geräte, wo das unterstützt wird.
5. Exponierte Identitätsinfrastruktur zuerst patchen. Cisco ISE, JFrog Artifactory, Cleo Harmony und WSO2 stellen Zugriff für alles aus, was dahinter liegt, oder validieren ihn. Behandeln Sie deren Updates vorrangig vor dem routinemäßigen Patchen.
6. So protokollieren, dass sich ein Vorfall rekonstruieren lässt. Halten Sie Sitzungs- und Token-Protokolle detailliert genug, um zu zeigen, wer sich wo mit welchem Token authentifiziert hat. NIST IR 8587 ist dafür und für die obigen Punkte eine brauchbare Checkliste.

Weiterführende Informationen finden Sie in unseren Leitfäden zum Lebenszyklus der Secrets-Rotation und zu hartcodierten Secrets.

Monatlicher Cybersecurity-Rückblick: Authentifizierung unter Beschuss

Die Vorfälle im August 2026 umgingen die Authentifizierung vollständig: bestätigte Exploits in N-able N-central und SharePoint, über 9.300 offengelegte AWS-Schlüssel und Mirage2FA, das Sitzungen nach der MFA übernahm. Hier ist, was IT- und Sicherheitsteams zuerst patchen und prüfen müssen.

PassworkPasswork Team

Post-Quanten-Passwortsicherheit: Was sich ändert und was zu tun ist

Grovers Algorithmus setzt einem korrekt gehashten Passwort kaum etwas entgegen. Shors Algorithmus zerlegt dagegen den RSA-Schlüsselaustausch direkt daneben. Hier ist das dreistufige Audit, das zeigt, welches der beiden Probleme bei Ihnen wirklich relevant ist.

PassworkPasswork Team

2026 IBM Cost of a Data Breach Report: Die KI-Bedrohung über 6 Mio. US-Dollar, die niemand behebt

Die globalen Kosten von Datenschutzverletzungen erreichten 2026 mit 4,99 Mio. US-Dollar einen neuen Höchststand, bei einer Erkennungszeit von 247 Tagen. KI-gestützte Angriffe steigen um 56 %, doch die eigentliche Krise ist: Verteidiger setzen KI überall ein – außer genau dort, wo Angreifer eindringen. 92 % der von KI-Angriffen betroffenen Organisationen hatten keine angemessenen Zugriffskontrollen.

PassworkAlex Muntyan

Las noticias de ciberseguridad de septiembre de 2026 estuvieron dominadas por tokens falsificados, sesiones reproducidas y claves de API filtradas que seguían funcionando después de cambiar la contraseña o que nunca la necesitaron. Dos vulnerabilidades ya figuran en el catálogo Known Exploited Vulnerabilities de CISA, y una clave de proveedor filtrada puso en riesgo a más de 100 000 sitios.

• Cisco ISE: CVE-2026-76460, una omisión de autenticación con explotación activa confirmada (Cisco).
• EvilTokens: Microsoft desmanteló un servicio de phishing por código de dispositivo vinculado a más de 12 000 bandejas de entrada comprometidas en más de 10 000 organizaciones (Microsoft).
• Brevo y Cloudflare: una clave de API comprometida puso en riesgo potencial a más de 100 000 sitios (Sansec).
• JFrog Artifactory: un fallo explotado en honeypots para generar tokens de administrador (SecurityWeek).
• Cleo Harmony: un exploit público para un fallo en el token de actualización JWT (SecurityWeek).
• CyberArk: 10 boletines de seguridad en cuatro fechas, incluido uno crítico (CyberArk).
• Claves de aplicaciones de GitHub: GitGuardian determinó que 474 de 4802 claves privadas filtradas seguían siendo válidas, autenticando como 440 aplicaciones (GitGuardian).
• NIST IR 8587: guía final sobre la protección de tokens y aserciones, publicada el 15 de septiembre (NIST).

Cada caso a continuación muestra una forma distinta en que una credencial sigue funcionando después de que debería haberse detenido: falsificada, reproducida, filtrada o generada a demanda. A continuación se detallan las versiones afectadas y las soluciones, con una breve lista de acciones a nivel de equipo al final.

Explotación activa de una omisión de autenticación en Cisco Identity Services Engine (CVE-2026-76460)

Cisco publicó un aviso el 16 de septiembre de 2026 sobre el CVE-2026-76460, una vulnerabilidad crítica de omisión de autenticación no autenticada en una API de Identity Services Engine (ISE). Cisco la califica con CVSS 3.1 Base 10.0 (Crítico) y confirmó la explotación activa. CISA añadió el CVE a su catálogo Known Exploited Vulnerabilities el mismo día.

Qué ocurrió: una solicitud manipulada al endpoint de API afectado permite a un atacante omitir la interfaz de administración web de ISE y obtener acceso no autorizado a un dispositivo ISE o ISE-PIC afectado, sin credenciales válidas. El PSIRT de Cisco confirmó que tenía conocimiento de ataques en entornos reales. No se ha revelado la fecha exacta en que comenzó la explotación.

Por qué importa: ISE es una plataforma de políticas de acceso a la red. El acceso no autorizado podría crear un riesgo grave específico de cada implementación para las operaciones de administración y de políticas, pero las fuentes disponibles no establecen que se hayan alterado las decisiones de RBAC o MFA posteriores de todos los clientes. El impacto depende de cómo tenga implementado ISE cada organización.

La conclusión defensiva: Cisco afirma que no existe ninguna solución alternativa para el fallo. Actualizar a una versión corregida es la solución completa. Como mitigación temporal, Cisco recomienda ACL de infraestructura (iACL) que permitan únicamente el tráfico de administración y de plano de control necesario hacia el dispositivo afectado. Revise el access.log de cada nodo en busca de nombres de usuario sospechosos y coteje los registros de red y de firewall fuera del propio dispositivo. Son pasos de detección y respuesta, no un sustituto de la aplicación de parches.

Fuentes: Cisco; CISA KEV

Microsoft desmantela EvilTokens, un servicio de phishing por código de dispositivo OAuth

El 22 de septiembre de 2026, la Unidad de Delitos Digitales de Microsoft, en colaboración con socios, desmanteló la infraestructura que sustentaba a EvilTokens, una plataforma de phishing como servicio vinculada a más de 12 000 bandejas de entrada comprometidas en más de 10 000 organizaciones de todo el mundo.

Qué ocurrió: EvilTokens abusaba de los flujos de autorización por código de dispositivo de OAuth 2.0, el mecanismo diseñado para dispositivos sin navegador, como televisores inteligentes o herramientas de línea de comandos, para engañar a los usuarios y hacerles aprobar un inicio de sesión en nombre del atacante. Microsoft reveló por separado actividad de ingeniería social con temática de passkeys observada desde mayo de 2026. En una de las secuencias investigadas, un anzuelo de passkey condujo a un phishing por código de dispositivo. En otros patrones investigados, los atacantes usaron pretextos de mesa de ayuda o registraron métodos de autenticación controlados por el atacante. Los informes de Microsoft no establecen que todas las secuencias combinaran estos pasos en una sola cadena de ataque.

Por qué importa: el phishing por código de dispositivo evita las partes de la autenticación que reciben más atención defensiva. No hay una página de inicio de sesión falsa que detectar ni una contraseña escrita en el sitio del atacante. La víctima aprueba el inicio de sesión a través de la página legítima de Microsoft, creyendo que es un trámite rutinario. Aun así, una víctima sin una sesión activa de Microsoft puede recibir igualmente una solicitud de contraseña real y un desafío de MFA, por lo que esta técnica no elimina universalmente todos los pasos de autenticación.

La conclusión defensiva: deshabilite los flujos de autenticación por código de dispositivo para los usuarios que no los necesiten operativamente, y supervise los volúmenes anómalos de inicio de sesión por código de dispositivo como señal de detección. Donde el flujo sea realmente necesario, protéjalo con una política de acceso condicional.

Fuentes: Microsoft; Microsoft (actividad con temática de passkeys)

Una sola clave de API de Cloudflare con permisos excesivos puso en riesgo a más de 100 000 sitios

El 14 de septiembre de 2026, los atacantes usaron una clave de API de Cloudflare comprometida y con permisos amplios, perteneciente a la plataforma de correo electrónico y marketing Brevo, para desplegar un Cloudflare Worker malicioso que alteró los recursos de Brevo incrustados en los sitios de los clientes.

Qué ocurrió: la telemetría de Sansec registró que el Worker malicioso sirvió contenido desde las 16:05 hasta las 20:13 UTC del 14 de septiembre, aproximadamente cuatro horas. El informe del incidente de Brevo describe el Worker como activo durante unas cinco horas y media, una ventana más larga que la observada directamente por Sansec. Sansec estimó que más de 100 000 sitios que utilizaban componentes afectados de Brevo pudieron haber estado expuestos a contenido malicioso durante ese periodo.

Por qué importa: una sola clave de API de Cloudflare de larga duración y con permisos totales, vinculada a un proveedor de automatización de marketing, se convirtió en un canal de distribución de código malicioso en un gran número de sitios de terceros. Las claves de API en la nube con alcances amplios y sin caducidad son exactamente el tipo de credencial que la política de contraseñas tradicional no cubre.

La conclusión defensiva: limite las claves de API al conjunto mínimo de permisos que realmente necesita una integración, establezca caducidades incluso en las claves a nivel de servicio, y ejecute un escaneo continuo de secretos en repositorios y canalizaciones de despliegue, no solo en las bóvedas de contraseñas de los empleados. Supervisar los despliegues inesperados de Workers o los cambios de enrutamiento probablemente habría detectado esto más rápido que una auditoría manual.

Fuentes: Sansec; Brevo

Un fallo de JFrog Artifactory se usa para generar tokens de administrador (CVE-2026-82329)

JFrog publicó una corrección para el CVE-2026-82329 el 28 de agosto de 2026. El 1 de septiembre, WatchTowr informó de actividad en honeypots compatible con atacantes que explotaban el fallo para generar tokens de administrador.

Qué ocurrió: los honeypots de WatchTowr capturaron intentos de explotación contra un pequeño número de IP de origen, algunos de los cuales parecían ser actividad de mera verificación y no ataques completos. Es una prueba de que la vulnerabilidad es explotable y está siendo sondeada. No establece un escaneo amplio en internet ni una explotación masiva confirmada de instancias de clientes.

Por qué importa: los repositorios de artefactos se sitúan cerca del centro de la cadena de suministro de software. Mantienen relaciones de confianza federada con otros repositorios y a menudo contienen credenciales incrustadas para sistemas posteriores. Un atacante que puede generar un token de administrador no necesita robar uno: crea acceso válido a demanda.

La conclusión defensiva: para instalaciones autogestionadas de Artifactory, actualice a la versión corregida de su rama: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 o 7.161.20. JFrog afirma que los entornos en la nube afectados ya estaban reforzados. Si los registros muestran explotación o emisión sospechosa de tokens, revoque y reemita los tokens de administrador potencialmente expuestos y audite las configuraciones de federación. Los informes disponibles respaldan una explotación observada en honeypots, no una vulneración confirmada de instancias de clientes.

Fuentes: JFrog; SecurityWeek

Exploit público para un fallo en el token de actualización JWT de Cleo Harmony (CVE-2026-84115)

Se informó de un exploit público para el CVE-2026-84115 el 2 de septiembre de 2026, poco después de que se publicara el registro del CVE el 1 de septiembre.

Qué ocurrió: el fallo afecta a las versiones de Cleo Harmony hasta la 5.8.1.10 y está corregido en Harmony 5.8.1.11. El registro del CVE describe un problema explotable de forma remota en el gestor de tokens de actualización JWT de /api/connections: manipular el argumento Bearer provoca una gestión incorrecta de privilegios. SecurityWeek describe el mismo problema como causante de una omisión de autenticación y una elevación de privilegios. Los informes disponibles establecen la explotabilidad pública y la reproducción por parte de investigadores. No establecen una explotación confirmada de sistemas de clientes, ni que un token manipulado persista más allá de la caducidad de la sesión original.

Por qué importa: los tokens de actualización están pensados para prolongar una sesión de forma discreta, sin forzar un nuevo inicio de sesión. Un fallo en la forma en que se valida uno convierte esta función de comodidad en un riesgo potencial de persistencia, motivo suficiente para aplicar el parche incluso sin explotación confirmada.

La conclusión defensiva: actualice a Harmony 5.8.1.11 cuanto antes. Si se sospecha exposición, siga las indicaciones actuales de Cleo, revise los cambios de autenticación y de privilegios de la ventana correspondiente, y revoque los tokens de actualización pendientes donde la implementación admita ese control. La existencia de un exploit público no confirma por sí sola una vulneración ni un acceso persistente.

Fuentes: NVD; SecurityWeek

CyberArk publica diez boletines de seguridad en toda su línea de productos PAM

CyberArk publicó 10 boletines de seguridad en septiembre de 2026, en cuatro lotes con distintas fechas.

Qué ocurrió: CyberArk publicó 10 boletines de seguridad en cuatro lotes durante septiembre de 2026, que abordan problemas de gravedad alta en agentes de gestión de privilegios de endpoints, componentes de puerta de enlace y bóveda autogestionados, analítica de acceso privilegiado y gestión de credenciales de bases de datos, además de un problema crítico —CA26-44— que afecta a determinadas versiones autogestionadas de Password Vault Web Access (PVWA).

Por qué importa: los sistemas PAM a menudo gestionan o dan acceso a credenciales privilegiadas e infraestructura sensible. Un conjunto concentrado de actualizaciones de seguridad es un recordatorio de que estos entornos requieren gestión continua de parches, una gobernanza de accesos clara y una capacidad de auditoría fiable. Los avisos no indican, por sí mismos, explotación activa.

La conclusión defensiva: las organizaciones que usan los productos afectados deben revisar los avisos y priorizar la corrección según la gravedad, la exposición y el impacto potencial en los sistemas relacionados con credenciales. De forma más general, los equipos de seguridad deben mantener visibilidad sobre quién puede acceder a las credenciales sensibles y poder revisar ese acceso cuando sea necesario.

Fuente: CyberArk; CyberIAM bulletin board

Las claves privadas filtradas de aplicaciones de GitHub siguen funcionando mucho después de su exposición

GitGuardian probó 4802 claves privadas filtradas de aplicaciones de GitHub encontradas en fuentes públicas y descubrió que 474 seguían autenticándose como 440 aplicaciones activas distintas.

Qué ocurrió: una clave privada de una aplicación de GitHub no tiene caducidad automática y puede permanecer utilizable hasta que se revoque o elimine manualmente. De las 474 claves aún válidas que probó GitGuardian, 207 tenían permiso de escritura de contenido en repositorios, 40 podían administrar ejecutores autogestionados, 98 podían controlar flujos de trabajo y 44 tenían privilegios de administración de la organización. Una clave confirmada hace años aún puede autenticarse si no se ha revocado o eliminado.

Un patrón relacionado surgió en un fallo de gestión de API de WSO2, el CVE-2026-5430. El aviso data de mayo de 2026 y el CVE se publicó en agosto. La noticia de septiembre fue un informe de explotación, no una nueva divulgación. Un atacante puede crear un JWT con un algoritmo de firma no admitido y aprovechar la validación defectuosa de WSO2 para omitir la autenticación. El servicio no necesita generar un token por sí mismo. El honeypot de WatchTowr capturó JWT falsificados con privilegios de administrador contra el servicio el 13 de septiembre, y CISA añadió el CVE a su catálogo Known Exploited Vulnerabilities el 24 de septiembre. Se informó de que las credenciales de backend, las claves de consumidor o los secretos eran potencialmente accesibles, no que se hubieran robado de forma confirmada.

Por qué importa: una filtración pública crea un acceso potencialmente persistente hasta que se revoca o elimina la clave. No prueba por sí sola que la clave se usara o que se accediera a los datos. El caso de WSO2 muestra un patrón relacionado una capa más abajo en la pila: un atacante ni siquiera necesita una clave filtrada si la propia lógica de validación puede ser engañada para aceptar una falsificada.

La conclusión defensiva: mantenga un responsable y un proceso documentado de rotación/revocación para cada clave de aplicación de GitHub. Si se sospecha o se confirma la exposición, genere un reemplazo y revoque o elimine la clave antigua cuanto antes; la rotación periódica reduce el tiempo de exposición, aunque GitHub no prescribe un calendario universal. Para las implementaciones de WSO2, aplique la corrección del proveedor, revise los registros de la ventana de explotación de septiembre y rote las credenciales a las que tenía acceso la capa de gestión de API.

Fuentes: GitGuardian; GitHub docs; WSO2 advisory; The Hacker News

NIST y CISA finalizan la guía sobre la protección de tokens de identidad y de acceso

NIST y CISA finalizaron el IR 8587 el 15 de septiembre de 2026, tras un borrador público inicial fechado el 22 de diciembre de 2025.

Qué ocurrió: la guía de implementación está escrita principalmente para agencias federales y los proveedores de servicios en la nube que utilizan, y abarca tokens de identidad, tokens de acceso y aserciones en escenarios de SSO, federación y acceso a API. Sus recomendaciones resumen prácticas de gestión de claves, verificación de tokens, ciclo de vida (incluida la vigencia y la revocación) y supervisión continua, con responsabilidades divididas entre proveedores, agencias consumidoras y clientes en la nube.

Por qué importa: varios de los fallos descritos anteriormente —JWT falsificados, tokens de administrador generados mediante fallos de validación, claves de API sin caducidad— entran dentro de las categorías que aborda este informe: brechas de verificación, controles de ciclo de vida inexistentes y responsabilidad poco clara entre proveedor y cliente respecto a la revocación. Esa coincidencia es útil incluso para organizaciones fuera del ámbito federal.

La conclusión defensiva: use el NIST IR 8587 como lista de verificación práctica frente a las prácticas actuales: confirme que la vigencia de los tokens está limitada, que las rutas de revocación se prueban y no solo se documentan, y que el registro de sesiones capture suficiente detalle para reconstruir un incidente basado en tokens después de que ocurra.

Fuentes: NIST; CISA

CloudSEK detalla BigBear 2.0, un servicio de adversario en el medio que reproduce sesiones de Microsoft 365 después de la MFA

CloudSEK publicó su investigación sobre BigBear 2.0 el 7 de septiembre de 2026. Su equipo TRIAD descubrió la operación en junio, lo que no establece cuándo comenzó toda la actividad de la campaña.

Qué ocurrió: el servicio de adversario en el medio, basado en Evilginx2, interceptaba los inicios de sesión de Microsoft 365. Capturaba las credenciales y la cookie de sesión emitida por Microsoft después de que las víctimas completaran la MFA, y luego permitía a los atacantes reproducir las sesiones autenticadas. El panel de CloudSEK contenía 4148 registros de cookies de sesión y 474 autenticaciones completadas con omisión de MFA. BleepingComputer informó de que 258 organizaciones distintas tuvieron al menos una vulneración completada de este tipo, mientras que 461 organizaciones aparecían en el conjunto de datos de objetivos más amplio. La cifra de 4148 es un recuento de registros de cookies, no un recuento confirmado de víctimas únicas. (CloudSEK; BleepingComputer)

Por qué importa: la MFA que la víctima completa en una página proxificada no protege nada una vez que se roba la cookie de sesión. El atacante hereda una sesión ya autenticada. Los códigos y las aprobaciones push no detienen este patrón.

La conclusión defensiva: priorice métodos resistentes al phishing, como las passkeys y las llaves de seguridad FIDO2, para administradores y usuarios de alto riesgo. Revise las políticas de acceso condicional que vinculan las sesiones a dispositivos conformes. Genere alertas cuando la dirección IP o el dispositivo de una sesión cambien poco después de la MFA.

Fuentes: CloudSEK; BleepingComputer

Okta analiza un volcado de infostealer con 44 791 JWT únicos; 1843 tokens seguían siendo válidos en el momento de su publicación

Okta publicó una investigación el 9 de septiembre de 2026 sobre un volcado de infostealer de 7 GB publicado en Telegram el 2 de agosto.

Qué ocurrió: el volcado contenía datos de 5871 máquinas infectadas. Okta identificó 44 791 JWT únicos, incluidos 555 probablemente relacionados con la autenticación de servicios de IA, además de 2937 JWE relacionados con la autenticación. En el momento de la publicación del volcado, 1843 JWT y JWE no habían caducado. Okta afirmó que los secretos de sesión no caducados podrían reproducirse potencialmente para omitir la autenticación basada en credenciales. La investigación no informó de una reproducción exitosa ni de una toma de control de cuenta confirmada. Que la reproducción funcione depende del servicio y de controles como la vinculación de tokens o las listas blancas de IP. (Okta)

Por qué importa: los infostealers se llevan todo lo que hay en el endpoint, y los tokens forman parte de ese botín. La vigencia del token determina cuánto tiempo sigue siendo útil un secreto robado. Los tokens de servicios de IA presentes en el conjunto muestran que la exposición alcanza ya a herramientas más recientes que los equipos a menudo adoptan fuera de la gestión central de identidades.

La conclusión defensiva: reduzca la vigencia de los tokens donde el servicio lo permita, y vincule los tokens a un dispositivo o red donde sea posible. Tras una infección de infostealer, revoque las sesiones y rote los secretos, no se limite a restablecer la contraseña. Incluya las cuentas de servicios de IA en su inventario de tokens y claves de API.

Fuente: Okta

La extensión de Twitch JeetBot reenviaba tokens de OAuth a través de proxies controlados por el operador

La extensión de navegador maliciosa para Twitch JeetBot tuvo aproximadamente 30 500 instalaciones desde las tiendas de Chrome y Firefox (una estimación de instalaciones, no un recuento confirmado de vulneraciones).

Qué ocurrió: Socket descubrió que capturaba tokens de OAuth de Twitch con alcance de cuenta y los reenviaba en un parámetro de consulta &auth= a través de proxies controlados por el operador. Los informes no establecen que los tokens se usaran para actividad no autorizada. La versión 85.8.7 de Firefox (16 de septiembre) y la versión 85.8.9 de Chrome (informada el 25 de septiembre) detuvieron el reenvío. El operador rechazó calificar la extensión de maliciosa, pero reconoció problemas de seguridad y de divulgación. (Socket)

La conclusión defensiva: audite las extensiones de navegador instaladas y trate cualquier token que haya aparecido en una URL como expuesto. Los usuarios de JeetBot deben revocar el acceso de la aplicación a su cuenta de Twitch.

Fuente: Socket

Microsoft Entra comienza a habilitar automáticamente las passkeys antes de la retirada de la MFA por SMS y voz

Microsoft Entra comenzó a habilitar automáticamente las passkeys el 1 de septiembre de 2026 para los usuarios de la nube pública ya habilitados para MFA por SMS o voz en la política de métodos de autenticación de Entra o en la configuración heredada.

Qué ocurrió: cuando estos usuarios inician sesión la siguiente vez y completan la MFA, se les invita a registrar una passkey. Por lo general, el aviso puede posponerse, y hay disponible una exclusión temporal a nivel de inquilino hasta el 1 de febrero de 2027. La entrega de SMS y voz proporcionada por Microsoft se retira el 1 de febrero de 2027 para la mayoría de los usuarios, y el 1 de julio de 2027 para los administradores globales y los usuarios externos. Las organizaciones con una necesidad legítima pueden seguir usando SMS o voz a través de un proveedor de telefonía compatible. Esa opción de configuración está prevista para el 30 de octubre de 2026.

Por qué importa: el cambio aleja el valor predeterminado de los factores basados en teléfono, el tipo que la campaña BigBear 2.0 descrita arriba demuestra que puede interceptarse. Los inquilinos que no hagan nada verán ahora avisos de registro y perderán la entrega de SMS y voz proporcionada por Microsoft en 2027.

La conclusión defensiva: inventaríe qué usuarios y procesos de servicio aún dependen de SMS o voz. Comience el registro de passkeys con los administradores y los usuarios externos, cuyo plazo vence antes. Decida antes del 1 de febrero de 2027 si necesita un proveedor de telefonía o puede retirar estos métodos por completo.

Fuente: Microsoft Learn

Qué significa esto para su equipo

La mayoría de los casos de este mes se reducen a credenciales que siguieron funcionando después de que deberían haberse detenido. Seis pasos que su equipo puede tomar para evitar problemas similares:

1. Inventaríe las credenciales no humanas. Liste las claves de API, los tokens de cuentas de servicio, las claves privadas de aplicaciones de GitHub y los secretos de CI/CD de la misma forma en que lista las cuentas de usuario. Asigne a cada una un responsable designado y un plan documentado de caducidad o rotación. Tanto el caso de Brevo como el de las claves de aplicaciones de GitHub implicaron claves que nadie estaba rastreando.
2. Limite el alcance y establezca caducidades. Conceda a cada clave solo los permisos que la integración realmente necesita, y establezca una caducidad siempre que el proveedor lo admita. Donde no lo admita, programe una rotación manual.
3. Pruebe la revocación antes de necesitarla. Para cada proveedor, confirme qué hace realmente revocar una sesión, un JWT, una concesión de OAuth o un token de actualización. Después de un incidente, ejecute la ruta de revocación de principio a fin en lugar de confiar en la documentación. Revoque las sesiones y rote los secretos, no se limite a restablecer la contraseña.
4. Cierre las brechas de OAuth y de sesión. Deshabilite los flujos de código de dispositivo para los usuarios que no los necesiten, y traslade a los administradores a passkeys o llaves FIDO2 antes de la retirada de SMS y voz de Microsoft en 2027. Donde sea posible, vincule las sesiones a los dispositivos.
5. Aplique primero los parches a la infraestructura de identidad expuesta. Cisco ISE, JFrog Artifactory, Cleo Harmony y WSO2 emiten o validan el acceso para todo lo que hay detrás de ellos. Trate sus actualizaciones como una prioridad por encima de los parches rutinarios.
6. Registre lo suficiente para reconstruir un incidente. Mantenga registros de sesiones y tokens con el detalle suficiente para mostrar quién se autenticó, desde dónde y con qué token. El NIST IR 8587 es una lista de verificación práctica para esto y para los puntos anteriores.

Para más información relacionada, consulte nuestras guías sobre el ciclo de vida de la rotación de secretos y los secretos codificados.

Noticias mensuales de ciberseguridad: la autenticación bajo asedio

Los incidentes de agosto de 2026 evitaron la autenticación por completo: exploits confirmados en N-able N-central y SharePoint, más de 9300 claves de AWS expuestas, y Mirage2FA secuestrando sesiones después de la MFA. Esto es lo que los equipos de TI y seguridad deben parchear y auditar primero.

PassworkPasswork Team

Seguridad de contraseñas poscuántica: qué cambia y qué hacer

El algoritmo de Grover apenas hace mella en una contraseña correctamente hasheada. El algoritmo de Shor destroza el intercambio de claves RSA que tiene al lado. Esta es la auditoría de 3 capas que le dice cuál de los dos es realmente su problema.

PassworkPasswork Team

Informe 2026 IBM Cost of a Data Breach: la amenaza de IA de 6 millones de USD que nadie soluciona

Los costos globales de las vulneraciones alcanzaron un récord de 4,99 millones de USD en 2026, con una detección que tarda 247 días. Los ataques impulsados por IA aumentan un 56 %, pero la crisis real es esta: los defensores despliegan IA en todas partes excepto donde entran los atacantes. El 92 % de las organizaciones vulneradas por IA no contaban con controles de acceso adecuados.

PassworkAlex Muntyan

September 2026 cybersecurity news was dominated by forged tokens, replayed sessions, and leaked API keys that kept working after the password was changed or never needed. Two vulnerabilities are already on CISA's Known Exploited Vulnerabilities list, and one leaked vendor key put 100,000+ sites at risk.

• Cisco ISE: CVE-2026-76460, an authentication bypass with confirmed active exploitation (Cisco).
• EvilTokens: Microsoft disrupted a device-code phishing service linked to more than 12,000 compromised inboxes across over 10,000 organizations (Microsoft).
• Brevo and Cloudflare: a compromised API key put more than 100,000 sites at potential risk (Sansec).
• JFrog Artifactory: a flaw exploited in honeypots to mint administrator tokens (SecurityWeek).
• Cleo Harmony: a public exploit for a JWT refresh-token flaw (SecurityWeek).
• CyberArk: 10 security bulletins on four dates, including one Critical (CyberArk).
• GitHub App keys: GitGuardian found 474 of 4,802 leaked private keys still valid, authenticating as 440 apps (GitGuardian).
• NIST IR 8587: final guidance on protecting tokens and assertions, published September 15 (NIST).

Each case below shows a different way a credential keeps working after it should have stopped: forged, replayed, leaked, or minted on demand. Details, affected versions, and fixes follow, with a short list of team-level actions at the end.

Active exploitation of an authentication bypass in Cisco Identity Services Engine (CVE-2026-76460)

Cisco published an advisory on September 16, 2026 for CVE-2026-76460, a critical, unauthenticated authentication-bypass vulnerability in an Identity Services Engine (ISE) API. Cisco rates it CVSS 3.1 Base 10.0 (Critical) and confirmed active exploitation. CISA added the CVE to its Known Exploited Vulnerabilities catalog the same day.

What happened: A crafted request to the affected API endpoint lets an attacker bypass ISE's web-based management interface and gain unauthorized access to an affected ISE or ISE-PIC device, without valid credentials. Cisco's PSIRT confirmed it was aware of in-the-wild attacks. The exact date exploitation began has not been disclosed.

Why it matters: ISE is a network-access policy platform. Unauthorized access could create serious deployment-specific risk to administration and policy operations, but the available sources don't establish that every customer's downstream RBAC or MFA decisions were altered. Impact depends on how a given organization has ISE deployed.

The defensive takeaway: Cisco says no workaround addresses the flaw. Upgrading to a fixed release is the complete remediation. As a temporary mitigation, Cisco recommends infrastructure ACLs (iACLs) that allow only required management- and control-plane traffic to the affected device. Review each node's access.log for suspicious usernames and cross-check network and firewall logs outside the appliance itself. These are detection and response steps, not a substitute for patching.

Sources: Cisco; CISA KEV

Microsoft disrupts EvilTokens, an OAuth device-code phishing service

On September 22, 2026, Microsoft's Digital Crimes Unit, working with partners, disrupted infrastructure behind EvilTokens, a phishing-as-a-service platform linked to more than 12,000 compromised inboxes across over 10,000 organizations worldwide.

What happened: EvilTokens abused OAuth 2.0 device-authorization flows, the mechanism designed for devices without a browser, such as smart TVs or CLI tools, to trick users into approving a sign-in on the attacker's behalf. Microsoft separately disclosed passkey-themed social-engineering activity observed since May 2026. In one investigated sequence, a passkey lure led to device-code phishing. In other investigated patterns, attackers used help-desk pretexts or registered attacker-controlled authentication methods. Microsoft's reporting doesn't establish that every sequence combined all of these steps into one attack chain.

Why it matters: Device-code phishing sidesteps the parts of authentication that get the most defensive attention. There's no fake login page to spot and no password typed into an attacker's site. The victim approves the sign-in through Microsoft's own legitimate page, believing it's routine. That said, a victim without an active Microsoft session can still be prompted for a real password and MFA challenge, so this technique doesn't universally erase every authentication step.

The defensive takeaway: Disable device-code authentication flows for users who don't operationally need them, and monitor for abnormal device-code sign-in volume as a detection signal. Where the flow is genuinely required, gate it behind conditional-access policy.

Sources: Microsoft; Microsoft (passkey-themed activity)

A single overprivileged Cloudflare API key put 100,000+ sites at risk

On September 14, 2026, attackers used a compromised, broadly privileged Cloudflare API key belonging to email and marketing platform Brevo to deploy a malicious Cloudflare Worker that altered Brevo-embedded assets on customer sites.

What happened: Sansec's telemetry recorded the malicious Worker serving content from 16:05 to 20:13 UTC on September 14, roughly four hours. Brevo's incident write-up describes the Worker as active for about five and a half hours, a longer window than Sansec directly observed. Sansec estimated that more than 100,000 sites using affected Brevo components may have been exposed to malicious content during that period.

Why it matters: One long-lived, full-permission Cloudflare API key, tied to a marketing-automation vendor, became a distribution channel for malicious code across a large number of third-party sites. Cloud API keys with broad scopes and no expiration are exactly the credential type that traditional password policy doesn't cover.

The defensive takeaway: Scope API keys to the minimum permission set an integration actually needs, set expirations even on service-level keys, and run continuous secret scanning across repositories and deployment pipelines, not just employee password vaults. Monitoring for unexpected Worker deployments or routing changes would likely have caught this faster than a manual audit.

Sources: Sansec; Brevo

JFrog Artifactory flaw used to mint admin tokens (CVE-2026-82329)

JFrog published a fix for CVE-2026-82329 on August 28, 2026. On September 1, WatchTowr reported honeypot activity consistent with attackers exploiting the flaw to generate administrator tokens.

What happened: WatchTowr's honeypots captured exploitation attempts against a small number of source IPs, some of which appeared to be verification-only activity rather than follow-through attacks. That's evidence the vulnerability is exploitable and being probed. It doesn't establish broad scanning across the internet or confirmed mass exploitation of customer instances.

Why it matters: Artifact repositories sit near the center of the software supply chain. They hold federation trust relationships with other repositories and often carry embedded credentials for downstream systems. An attacker who can generate an admin token doesn't need to steal one, they create valid access on demand.

The defensive takeaway: For self-hosted Artifactory, upgrade to the fixed release for your branch: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, or 7.161.20. JFrog says affected cloud environments were already fortified. If logs show exploitation or suspicious token issuance, revoke and reissue potentially exposed admin tokens and audit federation configurations. The available reporting supports honeypot-observed exploitation, not confirmed compromise of customer instances.

Sources: JFrog; SecurityWeek

Public exploit for a JWT refresh-token flaw in Cleo Harmony (CVE-2026-84115)

A public exploit for CVE-2026-84115 was reported on September 2, 2026, shortly after the CVE record was published on September 1.

What happened: The flaw affects Cleo Harmony versions through 5.8.1.10 and is fixed in Harmony 5.8.1.11. The CVE record describes a remotely exploitable issue in the /api/connections JWT Refresh Token Handler: manipulating the Bearer argument results in improper privilege management. SecurityWeek describes the same issue as allowing authentication bypass and privilege elevation. The available reporting establishes public exploitability and researcher reproduction. It doesn't establish confirmed exploitation of customer systems, nor that a manipulated token persists beyond the original session's expiry.

Why it matters: Refresh tokens are meant to extend a session quietly, without forcing a fresh login. A flaw in how one is validated turns that convenience feature into a potential persistence risk, which is reason enough to patch even without confirmed exploitation.

The defensive takeaway: Upgrade to Harmony 5.8.1.11 promptly. If exposure is suspected, follow Cleo's current guidance, review authentication and privilege changes from the relevant window, and revoke outstanding refresh tokens where the deployment supports that control. A public exploit's existence doesn't by itself confirm compromise or persistent access.

Sources: NVD; SecurityWeek

CyberArk ships ten security bulletins across its PAM product line

CyberArk released 10 security bulletins in September 2026, in four dated batches.

What happened: CyberArk released 10 security bulletins in four batches during September 2026, addressing High-severity issues across endpoint privilege management agents, self-hosted gateway and vault components, privileged-access analytics, and database credential management, as well as a Critical issue—CA26-44—affecting certain self-hosted Password Vault Web Access (PVWA) versions.

Why it matters: PAM systems often manage or provide access to privileged credentials and sensitive infrastructure. A concentrated set of security updates is a reminder that these environments require continuous patch management, clear access governance, and reliable auditability. The advisories do not, by themselves, indicate active exploitation.

The defensive takeaway: Organizations using affected products should review the advisories and prioritize remediation according to severity, exposure, and the potential impact on credential-related systems. More broadly, security teams should maintain visibility into who can access sensitive credentials and be able to review that access when needed.

Source: CyberArk; CyberIAM bulletin board

Leaked GitHub App private keys keep working long after exposure

GitGuardian tested 4,802 leaked GitHub App private keys found in public sources and found 474 still authenticating as 440 distinct live apps.

What happened: A GitHub App private key has no automatic expiry and can remain usable until it's manually revoked or deleted. Among the 474 still-valid keys GitGuardian tested, 207 carried repository content-write permission, 40 could administer self-hosted runners, 98 could control workflows, and 44 held organization-administration privileges. A key committed years ago may still authenticate if it hasn't been revoked or deleted.

A related pattern surfaced in a WSO2 API-management flaw, CVE-2026-5430. The advisory dates to May 2026 and the CVE was published in August. The September news was exploitation reporting, not a new disclosure. An attacker can craft a JWT with an unsupported signing algorithm and exploit WSO2's faulty validation to bypass authentication. The service doesn't need to mint a token itself. WatchTowr's honeypot captured administrator-privilege forged JWTs against it on September 13, and CISA added the CVE to its Known Exploited Vulnerabilities catalog on September 24. Backend credentials, consumer keys, or secrets were reported as potentially reachable, not confirmed stolen.

Why it matters: A public leak creates potentially persistent access until the key is revoked or deleted. It doesn't by itself prove the key was used or that data was accessed. The WSO2 case shows a related pattern one layer down the stack: an attacker doesn't need a leaked key at all if the validation logic itself can be tricked into accepting a forged one.

The defensive takeaway: Maintain an owner and a documented rotation/revocation process for every GitHub App key. If exposure is suspected or confirmed, generate a replacement and revoke or delete the old key promptly; periodic rotation reduces exposure time, though GitHub doesn't prescribe a universal schedule. For WSO2 deployments, apply the vendor's fix, review logs for the September exploitation window, and rotate credentials the API-management layer had access to.

Sources: GitGuardian; GitHub docs; WSO2 advisory; The Hacker News

NIST and CISA finalize guidance on protecting identity and access tokens

NIST and CISA finalized IR 8587 on September 15, 2026, after an initial public draft dated December 22, 2025.

What happened: The implementation guidance is written primarily for federal agencies and the cloud service providers they use, covering identity tokens, access tokens, and assertions in SSO, federation, and API-access scenarios. Its recommendations summarize key-management, token-verification, lifecycle (including lifetime and revocation), and continuous-monitoring practices, with responsibilities divided between providers, consuming agencies, and cloud consumers.

Why it matters: Several of the failures described above, forged JWTs, admin tokens generated through validation flaws, non-expiring API keys, fall inside the categories this report addresses: verification gaps, missing lifecycle controls, and unclear provider-versus-customer responsibility for revocation. That overlap is useful even for organizations outside the federal space.

The defensive takeaway: Use NIST IR 8587 as a working checklist against current practices: confirm token lifetimes are bounded, revocation paths are tested rather than just documented, and session logging captures enough detail to reconstruct a token-based incident after the fact.

Sources: NIST; CISA

CloudSEK details BigBear 2.0, an adversary-in-the-middle service that replays Microsoft 365 sessions after MFA

CloudSEK published its BigBear 2.0 research on September 7, 2026. Its TRIAD team discovered the operation in June, which doesn't establish when all campaign activity began.

What happened: The Evilginx2-based adversary-in-the-middle service relayed Microsoft 365 sign-ins. It captured credentials and the Microsoft-issued session cookie after victims completed MFA, then let attackers replay the authenticated sessions. CloudSEK's panel contained 4,148 session-cookie records and 474 completed MFA-bypassed authentications. BleepingComputer reported that 258 distinct organizations had at least one such completed compromise, while 461 organizations appeared in the broader targeting dataset. The 4,148 figure is a cookie-record count, not a confirmed count of unique victims. (CloudSEK; BleepingComputer)

Why it matters: MFA that the victim completes on a proxied page protects nothing once the session cookie is stolen. The attacker inherits an already authenticated session. Codes and push approvals don't stop this pattern.

The defensive takeaway: Prioritize phishing-resistant methods such as passkeys and FIDO2 security keys for administrators and high-risk users. Review conditional access policies that bind sessions to compliant devices. Alert on sign-ins where the session's IP address or device changes soon after MFA.

Sources: CloudSEK; BleepingComputer

Okta analyzes infostealer dump with 44,791 unique JWTs, 1,843 tokens still valid at release

Okta published research on September 9, 2026 on a 7 GB infostealer dump posted to Telegram on August 2.

What happened: The dump held data from 5,871 infected machines. Okta identified 44,791 unique JWTs, including 555 likely related to AI-service authentication, plus 2,937 authentication-related JWEs. As of the dump's release, 1,843 JWTs and JWEs hadn't expired. Okta said unexpired session secrets could potentially be replayed to bypass credential-based authentication. The research didn't report a successful replay or a confirmed account takeover. Whether replay works depends on the service and on controls such as token binding or IP allowlisting. (Okta)

Why it matters: Infostealers take whatever sits on the endpoint, and tokens are part of that haul. Token lifetime sets how long a stolen secret stays useful. The AI-service tokens in the set show that the exposure now reaches newer tools that teams often adopt outside central identity management.

The defensive takeaway: Shorten token lifetimes where the service allows it, and bind tokens to a device or network where supported. After an infostealer infection, revoke sessions and rotate secrets, not just reset the password. Include AI-service accounts in your inventory of tokens and API keys.

Source: Okta

JeetBot Twitch extension forwarded OAuth tokens through operator-controlled proxies

The malicious Twitch browser extension JeetBot had roughly 30,500 store installations across Chrome and Firefox (an installation estimate, not a confirmed compromise count).

What happened: Socket found it captured account-scoped Twitch OAuth tokens and forwarded them in an &auth= query parameter through operator-controlled proxies. The reporting doesn't establish that the tokens were used for unauthorized activity. Firefox version 85.8.7 (September 16) and Chrome version 85.8.9 (reported September 25) stopped the forwarding. The operator disputed calling the extension malicious but acknowledged security and disclosure problems. (Socket)

The defensive takeaway: Audit installed browser extensions, and treat any token that appeared in a URL as exposed. Users of JeetBot should revoke the app's access to their Twitch account.

Source: Socket

Microsoft Entra begins auto-enabling passkeys ahead of SMS and voice MFA retirement

Microsoft Entra began auto-enabling passkeys on September 1, 2026 for public-cloud users already enabled for SMS or voice MFA in the Entra Authentication Methods Policy or legacy settings.

What happened: When these users next sign in and complete MFA, they are nudged to register a passkey. The nudge can typically be snoozed, and a temporary tenant opt-out is available through February 1, 2027. Microsoft-provided SMS and voice delivery retires on February 1, 2027 for most users, and on July 1, 2027 for Global Administrators and external users. Organizations with a legitimate need can continue SMS or voice through a supported telephony provider. That configuration option is scheduled for October 30, 2026.

Why it matters: The change moves the default away from phone-based factors, the type the BigBear 2.0 campaign above shows can be relayed. Tenants that do nothing will see registration prompts now and lose Microsoft-provided SMS and voice delivery in 2027.

The defensive takeaway: Inventory which users and service processes still rely on SMS or voice. Start passkey registration with administrators and external users, whose deadline is earliest. Decide before February 1, 2027 whether you need a telephony provider or can retire these methods entirely.

Source: Microsoft Learn

What this means for your team

Most of this month's cases come down to credentials that kept working after they should have stopped. Six steps your team can take to avoid similar problems:

1. Inventory non-human credentials. List API keys, service-account tokens, GitHub App private keys, and CI/CD secrets the way you list user accounts. Give each a named owner and a documented expiration or rotation plan. The Brevo and GitHub App cases both involved keys that nobody was tracking.
2. Scope and expire. Grant each key only the permissions the integration needs, and set an expiration wherever the provider supports one. Where it doesn't, schedule manual rotation.
3. Test revocation before you need it. For each provider, confirm what revoking a session, JWT, OAuth grant, or refresh token actually does. After an incident, run the revocation path end to end instead of relying on the documentation. Revoke sessions and rotate secrets, not just reset the password.
4. Close the OAuth and session gaps. Disable device-code flows for users who don't need them, and move administrators to passkeys or FIDO2 keys ahead of Microsoft's 2027 SMS and voice retirement. Where supported, bind sessions to devices.
5. Patch exposed identity infrastructure first. Cisco ISE, JFrog Artifactory, Cleo Harmony, and WSO2 issue or validate access for everything behind them. Treat their updates as a priority over routine patching.
6. Log enough to reconstruct an incident. Keep session and token logs detailed enough to show who authenticated, from where, and with which token. NIST IR 8587 is a usable checklist for this and the points above.

For related reading, see our guides on the secrets rotation lifecycle and hardcoded secrets.

Monthly cybersecurity news: Authentication under siege

August 2026’s incidents bypassed authentication entirely: confirmed exploits in N-able N-central and SharePoint, 9,300+ exposed AWS keys, and Mirage2FA hijacking sessions after MFA. Here’s what IT and security teams need to patch and audit first.

PassworkPasswork Team

Post-quantum password security: What changes and what to do

Grover’s algorithm barely dents a properly hashed password. Shor’s algorithm guts the RSA key exchange sitting next to it. Here’s the 3-layer audit that tells you which one is actually your problem.

PassworkPasswork Team

2026 IBM Cost of a Data Breach Report: The $6M AI threat no one’s fixing

Global breach costs hit record $4.99M in 2026, with detection taking 247 days. AI-driven attacks surge 56%, but the real crisis: defenders deploy AI everywhere except where attackers break in. 92% of AI-breached organizations had zero proper access controls.

PassworkAlex Muntyan

A 30 de agosto de 2026, terminou o período de transição estabelecido ao abrigo do acordo entre a Passwork Europe S.L. e a Passwork FZ-LLC (EAU). Desde essa data, a Passwork Europe S.L. gere de forma independente o desenvolvimento, a manutenção, o suporte e a segurança do Passwork.

Seguidamente, explica-se o que isto significa, na prática, para os clientes e parceiros.

O que mudou após o fim da transição

O período de transição tinha como finalidade garantir a continuidade do produto para os clientes existentes enquanto eram transferidos a tecnologia, os conhecimentos técnicos e a infraestrutura. A transição foi concluída conforme planeado, a 30 de agosto de 2026.

A partir de 30 de agosto de 2026:

• A Passwork Europe S.L. deixou de receber da Passwork FZ-LLC atualizações do código-fonte e transferência de conhecimentos técnicos
• O desenvolvimento, as versões e o suporte técnico do produto são geridos pela Passwork Europe S.L.
• A infraestrutura utilizada pela Passwork Europe S.L. para compilar, assinar e distribuir as suas atualizações está sob a sua administração e localizada na União Europeia
• O acesso ao ambiente de desenvolvimento, às chaves de assinatura e à infraestrutura da Passwork Europe S.L. é controlado exclusivamente pela Passwork Europe S.L.

Para os clientes, todas as questões técnicas e operacionais são agora tratadas pela Passwork Europe S.L., em Barcelona.

Propriedade da empresa

O desenvolvimento, a manutenção, o suporte e a distribuição do Passwork estão a cargo, de forma independente, da Passwork Europe S.L., uma empresa espanhola registada em Barcelona. O único acionista e CEO da empresa é Alexander Muntyan, residente fiscal em Espanha. Toda a informação sobre a propriedade e a estrutura societária da empresa é de acesso público no Registro Mercantil espanhol e pode ser verificada de forma independente.

A equipa de desenvolvimento e as suas localizações

O produto é desenvolvido por uma equipa distribuída de prestadores de serviços independentes, sob a gestão da Passwork Europe S.L., a partir de Barcelona. As funções-chave estão sediadas em jurisdições da União Europeia.

Os dados administrativos, operacionais e relativos a clientes são tratados na União Europeia, em conformidade com os requisitos do RGPD.

Novas versões

As próximas versões do Passwork são desenvolvidas e preparadas para lançamento pela equipa da Passwork Europe S.L., sem depender de atualizações do código-fonte da Passwork FZ-LLC.

A partir da próxima versão, será também introduzido um novo formato de nomenclatura das versões. A cadência de lançamentos mantém-se inalterada. As atualizações regulares de funcionalidades e de segurança seguem o roteiro próprio da empresa.

Residência na UE: Próximos passos

O fim do período de transição integra um esforço mais amplo para reforçar a jurisdição europeia do produto. Nos próximos meses, está previsto:

• concluir a consolidação da infraestrutura do produto (compilação, assinatura e distribuição de atualizações, portais de atualizações e de licenciamento, DNS, CDN) na União Europeia, sob a administração da Passwork Europe S.L.;
• harmonizar o enquadramento contratual com clientes, prestadores de serviços e fornecedores num padrão único, coerente com os requisitos do RGPD e da NIS2;
• alargar a presença europeia da equipa em funções técnicas-chave.

Auditorias e verificação independente

Em 2025, o Passwork foi submetido a um teste de intrusão independente realizado pela HackerOne. Os resultados confirmaram a resiliência da arquitetura do Passwork face a ataques externos. As observações identificadas foram tratadas e encerradas no âmbito do processo normal de correção. O relatório final está disponível para os clientes, mediante pedido, no âmbito da due diligence.

O Passwork está certificado segundo a norma ISO/IEC 27001. O estado atual do certificado é de acesso público no registo IAF CertSearch (última atualização a 13 de agosto de 2026). A certificação abrange o desenvolvimento, o suporte e a operação do produto.

No período 2026–2027, planeia-se:

• alargar o âmbito da ISO/IEC 27001 de modo a abranger os novos elementos de infraestrutura consolidados no âmbito da residência na UE;
• preparar-se para o SOC 2 Type II.

Os clientes, parceiros e demais partes interessadas serão mantidos informados à medida que este trabalho avança, e os resultados serão divulgados assim que estiverem disponíveis.

El 30 de agosto de 2026 llegó a su fin el período de transición establecido en el acuerdo entre Passwork Europe S.L. y Passwork FZ-LLC (EAU). A partir de ese momento, Passwork Europe S.L. gestiona de forma independiente el desarrollo, el mantenimiento, el soporte y la seguridad de Passwork.

A continuación, explicamos qué significan estos cambios en la práctica para nuestros clientes y socios.

Qué cambió tras finalizar la transición

El objetivo del período de transición era garantizar la continuidad del producto para los clientes existentes mientras se transferían la tecnología, el know-how y la infraestructura. La transición se completó según lo previsto antes del 30 de agosto de 2026.

A partir del 30 de agosto de 2026:

• Passwork Europe S.L. ya no recibe actualizaciones de código fuente ni transferencia de conocimiento técnico por parte de Passwork FZ-LLC.
• El desarrollo, las versiones (releases) y el soporte técnico del producto son gestionados por Passwork Europe S.L.
• La infraestructura que utiliza Passwork Europe S.L. para compilar, firmar y distribuir sus actualizaciones está bajo su propia administración y ubicada dentro de la Unión Europea.
• El acceso al entorno de desarrollo, las claves de firma y la infraestructura de Passwork Europe S.L. está controlado exclusivamente por Passwork Europe S.L.

Para los clientes, todos los asuntos técnicos y operativos son ahora gestionados por Passwork Europe S.L. en Barcelona.

Propiedad de la empresa

Passwork es desarrollado, mantenido, soportado y distribuido de forma independiente por Passwork Europe S.L., una empresa española registrada en Barcelona. El único accionista y CEO de la empresa es Alexander Muntyan, residente fiscal en España. Toda la información sobre la propiedad y la estructura corporativa de la empresa está disponible públicamente en el Registro Mercantil español y puede verificarse de forma independiente.

El equipo de desarrollo y su ubicación

El producto es desarrollado por un equipo distribuido de contratistas independientes que trabajan bajo la gestión de Passwork Europe S.L. desde Barcelona. Los puestos clave se encuentran en jurisdicciones de la Unión Europea.

Los datos administrativos, operativos y relacionados con los clientes se procesan dentro de la Unión Europea de conformidad con los requisitos del RGPD.

Nuevas versiones

Las próximas versiones de Passwork serán desarrolladas y preparadas para su publicación íntegramente por el equipo de Passwork Europe S.L., sin depender de actualizaciones del código fuente de Passwork FZ-LLC.

A partir de la próxima versión, también introduciremos un nuevo formato de numeración. La frecuencia de publicación se mantiene sin cambios. Las actualizaciones periódicas de funcionalidades y seguridad siguen nuestra propia hoja de ruta.

Residencia en la UE: próximos pasos

El fin del período de transición forma parte de un esfuerzo más amplio para fortalecer la jurisdicción europea del producto. En los próximos meses:

• completaremos la consolidación de la infraestructura del producto (compilación, firma y distribución de actualizaciones, portales de actualización y licencias, DNS, CDN) dentro de la Unión Europea bajo la administración de Passwork Europe S.L.;
• alinearemos el marco contractual con clientes, contratistas y proveedores hacia un estándar único, coherente con los requisitos del RGPD y de NIS2;
• ampliaremos la presencia europea del equipo en puestos técnicos clave.

Auditorías y verificación independiente

En 2025, Passwork se sometió a una prueba de penetración independiente realizada por HackerOne. Los resultados confirmaron la resistencia de la arquitectura de Passwork frente a ataques externos. Las observaciones identificadas fueron atendidas y cerradas como parte del proceso estándar de remediación. El informe final está disponible para los clientes bajo solicitud, como parte del proceso de debida diligencia.

Passwork está certificado según la norma ISO/IEC 27001. El estado actual del certificado está disponible públicamente en el registro IAF CertSearch (última actualización: 13 de agosto de 2026). La certificación cubre el desarrollo, el soporte y la operación del producto.

Durante 2026-2027 tenemos previsto:

• ampliar el alcance de la certificación ISO/IEC 27001 para cubrir los nuevos elementos de infraestructura consolidados como parte de la residencia en la UE;
• prepararnos para la certificación SOC 2 Type II.

Mantendremos informados a nuestros clientes, socios y demás partes interesadas sobre el avance de este trabajo, y compartiremos los resultados a medida que estén disponibles.

Am 30. August 2026 endete die im Rahmen der Vereinbarung zwischen Passwork Europe S.L. und Passwork FZ-LLC (VAE) festgelegte Übergangsphase. Seit diesem Zeitpunkt verwaltet Passwork Europe S.L. die Entwicklung, Wartung, den Support und die Sicherheit von Passwork.

Im Folgenden erläutern wir, was diese Änderungen für unsere Kunden und Partner in der Praxis bedeuten.

Was sich nach Abschluss der Übergangsphase geändert hat

Ziel der Übergangsphase war es, die Produktkontinuität für bestehende Kunden sicherzustellen, während Technologie, Know-how und Infrastruktur übertragen wurden. Die Übergangsphase wurde planmäßig bis zum 30. August 2026 abgeschlossen.

Seit dem 30. August 2026 gilt:

• Passwork Europe S.L. erhält keine Quellcode-Updates oder technischen Wissenstransfer mehr von Passwork FZ-LLC.
• Entwicklung, Releases und technischer Support des Produkts werden von Passwork Europe S.L. verwaltet.
• Die Infrastruktur, die Passwork Europe S.L. zum Erstellen, Signieren und Verteilen seiner Updates nutzt, unterliegt der eigenen Verwaltung und befindet sich innerhalb der Europäischen Union.
• Der Zugriff auf die Entwicklungsumgebung, die Signaturschlüssel und die Infrastruktur von Passwork Europe S.L. wird ausschließlich von Passwork Europe S.L. kontrolliert.

Für Kunden werden alle technischen und operativen Angelegenheiten nun von Passwork Europe S.L. in Barcelona bearbeitet.

Eigentümerstruktur des Unternehmens

Passwork wird unabhängig von Passwork Europe S.L. entwickelt, gewartet, unterstützt und vertrieben, einem in Barcelona registrierten spanischen Unternehmen. Alleiniger Gesellschafter und Geschäftsführer (CEO) des Unternehmens ist Alexander Muntyan, ein spanischer Steuerresident. Alle Informationen zur Eigentümerstruktur und Unternehmensform sind im spanischen Handelsregister (Registro Mercantil) öffentlich einsehbar und können unabhängig überprüft werden.

Das Entwicklungsteam und seine Standorte

Das Produkt wird von einem verteilten Team unabhängiger Auftragnehmer entwickelt, die unter der Leitung von Passwork Europe S.L. aus Barcelona arbeiten. Schlüsselpositionen sind in Rechtsräumen der Europäischen Union angesiedelt.

Administrative, operative und kundenbezogene Daten werden gemäß den Anforderungen der DSGVO innerhalb der Europäischen Union verarbeitet.

Neue Releases

Kommende Passwork-Releases werden vollständig vom Team der Passwork Europe S.L. entwickelt und für die Veröffentlichung vorbereitet, ohne auf Quellcode-Updates von Passwork FZ-LLC angewiesen zu sein.

Ab dem nächsten Release führen wir außerdem ein neues Format für die Versionsbezeichnung ein. Der Release-Zyklus bleibt unverändert. Regelmäßige Funktions- und Sicherheitsupdates folgen unserer eigenen Roadmap.

EU-Ansässigkeit: Nächste Schritte

Das Ende der Übergangsphase ist Teil eines umfassenderen Vorhabens, die europäische Rechtszugehörigkeit des Produkts zu stärken. In den kommenden Monaten werden wir:

• die Konsolidierung der Produktinfrastruktur (Erstellung, Signierung und Verteilung von Updates, Update- und Lizenzierungsportale, DNS, CDN) innerhalb der Europäischen Union unter der Verwaltung von Passwork Europe S.L. abschließen;
• den Vertragsrahmen mit Kunden, Auftragnehmern und Anbietern an einen einheitlichen Standard anpassen, der mit den Anforderungen der DSGVO und der NIS2-Richtlinie übereinstimmt;
• die europäische Präsenz des Teams in zentralen technischen Rollen ausbauen.

Audits und unabhängige Überprüfung

Im Jahr 2025 wurde Passwork einem unabhängigen Penetrationstest durch HackerOne unterzogen. Die Ergebnisse bestätigten die Widerstandsfähigkeit der Passwork-Architektur gegenüber externen Angriffen. Die festgestellten Beobachtungen wurden im Rahmen des Standardverfahrens zur Behebung bearbeitet und geschlossen. Der Abschlussbericht ist Kunden im Rahmen der Due-Diligence-Prüfung auf Anfrage zugänglich.

Passwork ist nach ISO/IEC 27001 zertifiziert. Der aktuelle Status des Zertifikats ist im IAF-CertSearch-Register öffentlich einsehbar (zuletzt aktualisiert am 13. August 2026). Die Zertifizierung umfasst die Entwicklung, den Support und den Betrieb des Produkts.

Für den Zeitraum 2026-2027 planen wir:

• den Geltungsbereich der ISO/IEC 27001-Zertifizierung auf die neuen Infrastrukturelemente auszuweiten, die im Rahmen der EU-Ansässigkeit konsolidiert wurden;
• die Vorbereitung auf eine SOC 2 Type II-Zertifizierung.

Wir werden unsere Kunden, Partner und andere interessierte Parteien über den Fortschritt dieser Arbeit auf dem Laufenden halten und die Ergebnisse mitteilen, sobald sie vorliegen.

On August 30, 2026, the transition period established under the agreement between Passwork Europe S.L. and Passwork FZ-LLC (UAE) came to an end. From that point forward, Passwork Europe S.L. independently manages the development, maintenance, support, and security of Passwork.

Below, we explain what this means in practice for our customers and partners.

What changed after the transition ended

The purpose of the transition period was to ensure product continuity for existing customers while technology, know-how, and infrastructure were transferred. The transition was completed as planned by August 30, 2026.

As of August 30, 2026:

• Passwork Europe S.L. no longer receives source-code updates or technical knowledge transfer from Passwork FZ-LLC.
• Development, releases, and technical support of the product are managed by the Passwork Europe S.L.
• The infrastructure used by Passwork Europe S.L. to build, sign, and distribute its updates is under its administration and located within the European Union.
• Access to Passwork Europe S.L.’s development environment, signing keys, and infrastructure is controlled exclusively by Passwork Europe S.L.

For customers, all technical and operational matters are now handled by Passwork Europe S.L. in Barcelona.

Ownership of the company

Passwork is independently developed, maintained, supported, and distributed by Passwork Europe S.L., a Spanish company registered in Barcelona. The sole shareholder and CEO of the company is Alexander Muntyan, a Spanish tax resident. All information about the company's ownership and corporate structure is publicly available in the Spanish Registro Mercantil and can be verified independently.

The development team and its locations

The product is developed by a distributed team of independent contractors working under Passwork Europe S.L.'s management out of Barcelona. Key roles are based in European Union jurisdictions.

Administrative, operational, and customer-related data is processed within the European Union in accordance with GDPR requirements.

New releases

Upcoming Passwork releases are developed and prepared for release by the Passwork Europe S.L. team without reliance on source-code updates from Passwork FZ-LLC.

Starting with the next release, we are also introducing a new version naming format. The release cadence is unchanged. Regular feature and security updates follow our own roadmap.

EU residency: Next steps

The end of the transition period is part of a broader effort to strengthen the European jurisdiction of the product. In the coming months we will:

• complete the consolidation of the product infrastructure (build, signing, and distribution of updates, update and licensing portals, DNS, CDN) within the European Union under Passwork Europe S.L.'s administration;
• align the contractual framework with customers, contractors, and providers to a single standard consistent with GDPR and NIS2 requirements;
• expand the European presence of the team in key technical roles.

Audits and independent verification

In 2025 Passwork underwent an independent penetration test performed by HackerOne. The results confirmed the resilience of Passwork's architecture to external attacks. The observations identified were addressed and closed as part of the standard remediation process. The final report is available to customers on request as part of due diligence.

Passwork is certified to ISO/IEC 27001. The current status of the certificate is publicly available in the IAF CertSearch registry (last updated August 13, 2026). The certification covers the development, support, and operation of the product.

Over 2026–2027 we plan to:

• extend the scope of ISO/IEC 27001 to cover the new infrastructure elements consolidated as part of EU residency;
• prepare for SOC 2 Type II.

We will keep our customers, partners, and other interested parties updated as this work progresses and share the outcomes as they become available.

O Passwork foi distinguido como Best for User Interface na seleção de 2026 de software de gestão de palavras-passe da Software Advice. O Passwork recebeu também o selo FrontRunners 2026. O reconhecimento baseia-se em avaliações verificadas de utilizadores e em estudos de mercado independentes. O Passwork tem uma classificação global de 4,7 em 5, com base em mais de 79 avaliações verificadas.

A Software Advice distinguiu o Passwork pela sua interface de utilizador e incluiu o produto na seleção FrontRunners de 2026. A metodologia FrontRunners avalia o software elegível em termos de usabilidade, satisfação dos clientes e presença digital, recorrendo a avaliações verificadas e a estudos independentes de produtos e de mercado.

Uma interface clara favorece a adoção, ao permitir que os colaboradores giram credenciais sem formação extensa. O Passwork combina fluxos de trabalho simples com permissões de cofre, SSO, integração AD/LDAP e auditoria de segurança. 

O que as equipas dizem sobre o Passwork

Os utilizadores referem com frequência uma adoção rápida, uma interface clara e um processo de configuração simples como razões para terem escolhido o Passwork.

«Excelente experiência para uma pequena equipa de desenvolvimento de software. Migrámos da nossa ferramenta anterior e adotámo-lo de imediato. A interface intuitiva quase não exige curva de aprendizagem e traz muita clareza à nossa gestão de segredos.» – Automação industrial, 11-50 colaboradores

Várias avaliações referem que o Passwork se mantém acessível a colaboradores sem perfil técnico e que, ao mesmo tempo, é compatível com grandes volumes de entradas e com fluxos de trabalho administrativos mais exigentes.

«Precisávamos de um gestor de palavras-passe que abrangesse todo o pessoal da empresa, com cifragem do lado do cliente, e não apenas a equipa técnica. O Passwork conseguiu oferecê-lo, com uma interface muito simples e acessível a todos. Além disso, a equipa do Passwork prestou um suporte de resposta rápida e foi melhorando a solução ao longo do tempo, acrescentando as funcionalidades mais necessárias e as melhorias de desempenho exigidas para dar resposta a empresas de muito grande dimensão.» – Tecnologias e serviços de informação, 51-200 colaboradores

As equipas técnicas valorizam também a implementação autoalojada, a cifragem do lado do cliente, a compatibilidade com SSO e a gestão flexível de permissões. 

«A minha experiência global com o Passwork tem sido muito positiva. A plataforma é simples de utilizar e a configuração decorreu sem problemas. Funcionalidades como a solução autoalojada, a compatibilidade com SSO e a gestão flexível de permissões facilitam a integração no nosso fluxo de trabalho.» – Segurança informática e de redes, 51-200 colaboradores

Há mais opiniões verificadas de clientes disponíveis na página de avaliações do Passwork.

O selo FrontRunners 2026 reconhece igualmente a satisfação dos clientes, a usabilidade e a presença digital. O Passwork continuará a melhorar os fluxos de trabalho do dia a dia, preservando os controlos exigidos pelas equipas de TI e de segurança.

Passwork vs Bitwarden: como difere a arquitetura de cifragem dos cofres

O Passwork cifra cada cofre com uma chave própria. O Bitwarden cifra toda a organização com uma única chave partilhada. Esta comparação analisa o que isso significa para o raio de impacto, o isolamento entre equipas, a recuperação de contas e as respostas de auditoria quando uma credencial é exposta.

PassworkPasswork Team

O que é a gestão centralizada de palavras-passe para PME em 2026?

As folhas de cálculo e o armazenamento no navegador não são gestão de palavras-passe: são apenas armazenamento, sem registo de auditoria nem controlo da saída de colaboradores. Este artigo explica o que exige uma verdadeira centralização: cofres partilhados, RBAC, registos de auditoria, MFA e o que verificar antes de escolher uma plataforma.

PassworkPasswork Team

Passwork 7.7: modo offline seguro para aplicações desktop e móveis

As palavras-passe passam a funcionar também offline. O Passwork 7.7 traz acesso offline seguro com supervisão total por parte dos administradores, controlos de anexos de ficheiros ao nível da organização e cinco novos guias de integração baseados em funções, para uma implementação mais fluida.

PassworkPasswork Team

Passwork wurde in der Passwort-Management-Software-Auswahl 2026 von Software Advice als Best for User Interface ausgezeichnet. Passwork erhielt außerdem das FrontRunners 2026 Badge. Die Auszeichnung basiert auf verifizierten Nutzerbewertungen und unabhängiger Marktforschung. Passwork hat eine Gesamtbewertung von 4,7 von 5 aus mehr als 79 verifizierten Bewertungen.

Software Advice zeichnete Passwork für seine Benutzeroberfläche aus und nahm das Produkt in seine FrontRunners-Auswahl 2026 auf. Die FrontRunners-Methodik bewertet geeignete Software hinsichtlich Benutzerfreundlichkeit, Kundenzufriedenheit und digitaler Präsenz unter Verwendung verifizierter Bewertungen sowie unabhängiger Produkt- und Marktforschung.

Eine klare Benutzeroberfläche fördert die Akzeptanz, indem sie Mitarbeitern hilft, Zugangsdaten ohne umfangreiche Schulung zu verwalten. Passwork kombiniert einfache Arbeitsabläufe mit Tresor-Berechtigungen, SSO, AD/LDAP-Integration und Sicherheitsaudits. 

Was Teams über Passwork sagen

Benutzer erwähnen häufig die schnelle Einführung, eine übersichtliche Oberfläche und einen reibungslosen Einrichtungsprozess, wenn sie beschreiben, warum sie sich für Passwork entschieden haben.

„Großartige Erfahrung für ein kleines Software-Entwicklungsteam. Wir sind von unserem alten Tool migriert und haben es sofort übernommen. Die intuitive Benutzeroberfläche erfordert praktisch keine Einarbeitungszeit und bringt viel Klarheit in unser Secret-Management." – Industrial Automation, 11-50 Mitarbeiter

Mehrere Bewertungen weisen darauf hin, dass Passwork auch für nicht-technische Mitarbeiter zugänglich bleibt und gleichzeitig eine große Anzahl von Einträgen sowie anspruchsvollere administrative Arbeitsabläufe unterstützt.

„Wir brauchten einen Passwort-Manager, der alle Mitarbeiter des Unternehmens einbezieht, mit clientseitiger Verschlüsselung, und nicht nur das technische Personal. Passwork konnte das mit einer sehr einfachen und für jeden zugänglichen Oberfläche bieten. Darüber hinaus bot das Passwork-Team schnellen Support und verbesserte die Lösung im Laufe der Zeit, indem die am meisten benötigten Funktionen und Leistungsverbesserungen für die Unterstützung sehr großer Unternehmen hinzugefügt wurden." – Information Technology and Services, 51-200 Mitarbeiter

Technische Teams schätzen auch die Self-Hosted-Bereitstellung, clientseitige Verschlüsselung, SSO-Unterstützung und flexibles Berechtigungsmanagement. 

„Meine Gesamterfahrung mit Passwork war sehr positiv. Die Plattform ist unkompliziert zu bedienen, die Einrichtung verlief reibungslos. Funktionen wie die Self-Hosted-Lösung, SSO-Unterstützung und flexibles Berechtigungsmanagement erleichtern die Integration in unseren Arbeitsablauf." – Computer & Network Security, 51-200 Mitarbeiter

Weiteres verifiziertes Kundenfeedback ist auf der Passwork-Bewertungsseite verfügbar.

Das FrontRunners 2026 Badge würdigt auch Kundenzufriedenheit, Benutzerfreundlichkeit und digitale Präsenz. Die Verbesserung alltäglicher Arbeitsabläufe wird fortgesetzt, während die von IT- und Sicherheitsteams benötigten Kontrollen erhalten bleiben.

Passwork vs Bitwarden: Unterschiede in der Tresor-Verschlüsselungsarchitektur

Passwork verschlüsselt jeden Tresor mit einem eigenen Schlüssel. Bitwarden verschlüsselt eine gesamte Organisation mit einem gemeinsamen Schlüssel. Dieser Vergleich zeigt, was das für Schadensradius, Team-Isolation, Kontowiederherstellung und Audit-Antworten bedeutet, wenn Zugangsdaten kompromittiert werden.

PassworkPasswork Team

Was ist zentrales Passwort-Management für KMU im Jahr 2026?

Tabellenkalkulationen und Browser-Speicher sind kein Passwort-Management — sie sind lediglich Speicher ohne Audit-Trail oder Offboarding-Kontrolle. Dieser Artikel behandelt, was echte Zentralisierung erfordert: gemeinsame Tresore, RBAC, Audit-Logs, MFA und worauf vor der Plattformwahl zu achten ist.

PassworkPasswork Team

Passwork 7.7: Sicherer Offline-Modus für Desktop- und Mobile-Apps

Passwörter funktionieren jetzt auch offline. Passwork 7.7 bringt sicheren Offline-Zugriff mit vollständiger Admin-Kontrolle, organisationsweite Dateianhang-Steuerung und fünf neue rollenbasierte Onboarding-Leitfäden für eine reibungslosere Einführung.

PassworkPasswork Team

Passwork ha sido reconocido como Mejor interfaz de usuario en la selección de software de gestión de contraseñas de Software Advice 2026. Passwork también recibió la insignia FrontRunners 2026. El reconocimiento se basa en reseñas verificadas de usuarios e investigación de mercado independiente. Passwork tiene una calificación general de 4.7 sobre 5 a partir de más de 79 reseñas verificadas.

Software Advice reconoció a Passwork por su interfaz de usuario e incluyó el producto en su selección FrontRunners 2026. La metodología FrontRunners evalúa el software elegible en términos de usabilidad, satisfacción del cliente y presencia digital, utilizando reseñas verificadas junto con investigación independiente de productos y mercado.

Una interfaz clara impulsa la adopción al ayudar a los empleados a gestionar credenciales sin necesidad de capacitación extensa. Passwork combina flujos de trabajo sencillos con permisos de bóveda, SSO, integración con AD/LDAP y auditoría de seguridad. 

Lo que dicen los equipos sobre Passwork

Los usuarios mencionan con frecuencia la rápida adopción, la interfaz clara y el proceso de configuración fluido al describir por qué eligieron Passwork.

«Gran experiencia para un pequeño equipo de desarrollo de software. Migramos desde nuestra herramienta anterior y la adoptamos de inmediato. La interfaz intuitiva prácticamente no requiere curva de aprendizaje y aporta mucha claridad a nuestra gestión de secretos.» – Automatización Industrial, 11-50 empleados

Varias reseñas señalan que Passwork sigue siendo accesible para empleados no técnicos mientras admite grandes cantidades de entradas y flujos de trabajo administrativos más exigentes.

«Necesitábamos un gestor de contraseñas que incluyera a todo el personal de la empresa, con cifrado del lado del cliente, y no solo al personal técnico. Passwork pudo proporcionar eso con una interfaz muy simple y accesible para todos. Además, el equipo de Passwork brindó soporte de respuesta rápida y mejoró la solución con el tiempo, añadiendo las funciones más necesarias y mejoras de rendimiento requeridas para soportar empresas muy grandes.» – Tecnología de la Información y Servicios, 51-200 empleados

Los equipos técnicos también valoran el despliegue autoalojado, el cifrado del lado del cliente, el soporte de SSO y la gestión flexible de permisos. 

«Mi experiencia general con Passwork ha sido muy positiva. La plataforma es fácil de usar, la configuración fue fluida. Funciones como la solución autoalojada, el soporte de SSO y la gestión flexible de permisos facilitan su integración en nuestro flujo de trabajo.» – Seguridad Informática y de Redes, 51-200 empleados

Más opiniones verificadas de clientes están disponibles en la página de reseñas de Passwork.

La insignia FrontRunners 2026 también reconoce la satisfacción del cliente, la usabilidad y la presencia digital. Continuaremos mejorando los flujos de trabajo diarios mientras preservamos los controles requeridos por los equipos de TI y seguridad.

Passwork vs Bitwarden: Cómo difiere la arquitectura de cifrado de bóvedas

Passwork cifra cada bóveda con su propia clave. Bitwarden cifra una organización completa con una clave compartida. Esta comparación analiza qué significa eso para el radio de impacto, el aislamiento de equipos, la recuperación de cuentas y las respuestas de auditoría cuando se filtra una credencial.

PassworkPasswork Team

¿Qué es la gestión centralizada de contraseñas para pymes en 2026?

Las hojas de cálculo y el almacenamiento del navegador no son gestión de contraseñas, son solo almacenamiento sin registro de auditoría ni control de bajas. Este artículo cubre lo que requiere una centralización real: bóvedas compartidas, RBAC, registros de auditoría, MFA y qué verificar antes de elegir una plataforma.

PassworkPasswork Team

Passwork 7.7: Modo sin conexión seguro para aplicaciones de escritorio y móviles

Las contraseñas ahora también funcionan sin conexión. Passwork 7.7 incorpora acceso sin conexión seguro con supervisión completa del administrador, controles de archivos adjuntos a nivel de organización y cinco nuevas guías de incorporación basadas en roles para una implementación más fluida.

PassworkPasswork Team

Passwork has been named Best for User Interface in Software Advice's 2026 password management software selection. Passwork also received the FrontRunners 2026 badge. The recognition is based on verified user reviews and independent market research. Passwork has an overall rating of 4.7 out of 5 from more than 79 verified reviews.

Software Advice recognized Passwork for its user interface and included the product in its 2026 FrontRunners selection. The FrontRunners methodology evaluates eligible software across usability, customer satisfaction, and digital presence, using verified reviews alongside independent product and market research.

A clear interface drives adoption by helping employees manage credentials without extensive training. Passwork combines simple workflows with vault permissions, SSO, AD/LDAP integration, and security auditing. 

What teams say about Passwork

Users often mention quick adoption, a clear interface, and a smooth setup process when describing why they chose Passwork.

"Great experience for a small software dev team. We have migrated from our legacy tool and immediately adopted it. The intuitive interface requiere nearly no learning curve and add a lot of clarity to our secret management." – Industrial Automation, 11-50 employees

Several reviews note that Passwork remains accessible to non-technical employees while supporting large numbers of entries and more demanding administrative workflows.

"We needed a password manager that would include all company staff, with client-side encryption, and not only the technical staff. Passwork was able to provide that with a very simple and accessible interface for everyone. Moreover, the Passwork team provided fast-response support and improved the solution over time, adding the most needed features and performance improvements required to support very large compagnies." – Information Technology and Services, 51-200 employees

Technical teams also value self-hosted deployment, client-side encryption, SSO support, and flexible permission management. 

"My overall experience with Passwork has been very positive. The platform is straightforward to work with, the setup was smooth. Features like the self-hosted solution, SSO support, and flexible permission management make it easy to integrate into our workflow." – Computer & Network Security, 51-200 employees

More verified customer feedback is available on the Passwork reviews page.

The FrontRunners 2026 badge also recognizes customer satisfaction, usability, and digital presence. We will continue improving everyday workflows while preserving the controls required by IT and security teams.

Passwork vs Bitwarden: How vault encryption architecture differs

Passwork encrypts every vault with its own key. Bitwarden encrypts an entire organization with one shared key. This comparison breaks down what that means for blast radius, team isolation, account recovery, and audit answers when a credential leaks.

PassworkPasswork Team

What is centralized password management for SMBs in 2026?

Spreadsheets and browser storage aren’t password management, they’re just storage with no audit trail or offboarding control. This article covers what real centralization requires: shared vaults, RBAC, audit logs, MFA, and what to check before picking a platform.

PassworkPasswork Team

Passwork 7.7: Secure offline mode for desktop and mobile apps

Passwords now work offline too. Passwork 7.7 brings secure offline access with full admin oversight, org-wide file attachment controls, and five new role-based onboarding guides for a smoother rollout.

PassworkPasswork Team

A versão mais recente do Passwork centra-se num problema com que todas as equipas distribuídas acabam por se deparar: o que acontece ao acesso às palavras-passe quando a ligação falha. O Passwork 7.7 adiciona o modo offline seguro às aplicações de desktop e móveis, mantendo os administradores com controlo total sobre o que fica em cache no dispositivo.

Acesso offline seguro em aplicações de desktop e móveis

Os utilizadores podem agora abrir registos de palavras-passe mesmo quando o dispositivo não tem ligação ao servidor. Para isso são necessários dois passos deliberados, pelo que nada fica num dispositivo por acidente.

Primeiro, o utilizador marca um registo específico com o ícone offline , disponível tanto no cartão de informações da palavra-passe como na lista geral de palavras-passe. Isto adiciona os registos selecionados a uma lista sincronizada, visível em todos os dispositivos desse utilizador no separador Offline do painel de navegação. Neste momento, ainda nada é transferido nem fica disponível offline.

Segundo, no dispositivo, o utilizador abre o separador Offline na aplicação de desktop ou móvel e seleciona Ativar neste dispositivo. Só então o Passwork transfere os registos cifrados para uma cache local nesse dispositivo específico.

Ao abrir a aplicação de desktop ou móvel sem ligação à Internet, só estão disponíveis os registos previamente guardados para acesso offline. Se o servidor ficar inacessível a meio de uma sessão, a aplicação oferece três opções:

• Terminar sessão na aplicação de desktop ou móvel
• Tentar novamente a ligação ao servidor
• Mudar para o modo offline para consultar apenas os registos em cache

Quando a conectividade é restabelecida, o Passwork sincroniza a cache e envia para o servidor um log de cada visualização offline.

Controlos de administração, visibilidade e acompanhamento de riscos

O acesso offline é regido ao nível da função e não funciona sem controlo. Os administradores mantêm controlo total sobre quem o utiliza e sobre a forma como é monitorizado.

Permissões baseadas em funções

Os administradores decidem que funções podem utilizar o acesso offline, durante quanto tempo um dispositivo pode ficar sem sincronizar antes de a cache ser apagada e quantos registos um único dispositivo pode conter.

Registo de auditoria completo

Cada transferência offline aparece no registo de eventos e no painel de segurança. Todas as ações realizadas em registos offline refletem-se também no registo de atividade assim que o dispositivo sincroniza, tal como acontece com qualquer outra palavra-passe. Assim, as equipas de segurança dispõem, sobre o acesso offline, do mesmo nível de supervisão que já têm sobre a atividade online.

Visibilidade ao nível do dispositivo

Os administradores podem ver quem colocou um registo em cache, em que dispositivo e quando esse dispositivo sincronizou pela última vez. A janela de acesso de uma pasta ou de um cofre mostra também o nome do utilizador e do dispositivo, pelo que os administradores podem rastrear a atividade offline até ao dispositivo concreto sem sair da vista de permissões.

Acompanhamento da exposição

O painel de segurança do Passwork trata um registo offline como uma potencial exposição a partir do momento em que fica numa cache local, quer o utilizador o abra ou não. Segue-se a mesma lógica já aplicada aos registos consultados.

Política de desativação por predefinição

Após a atualização para a versão 7.7, a funcionalidade fica ativada por predefinição apenas para as funções Proprietário e Administrador. Todos os restantes começam com a funcionalidade desativada.

Aspetos essenciais do modo offline

• Onde funciona. Os registos podem ser marcados para acesso offline a partir de qualquer aplicação e cliente web, mas a sua consulta offline só está disponível nas aplicações móveis e de desktop. Tem de ser ativado separadamente em cada dispositivo.
• Que dados estão disponíveis. Sem ligação, os utilizadores só podem consultar as palavras-passe que já adicionaram à lista offline e sincronizaram previamente.
• Expiração automática. Se um dispositivo não sincronizar dentro do prazo definido pelo administrador, os registos em cache são apagados automaticamente.
• Definições por função. Os administradores definem as regras para os utilizadores: quantos registos podem ser guardados por dispositivo e durante quanto tempo permanecem válidos sem sincronização.
• Controlo administrativo. Os administradores decidem que funções podem, de todo, utilizar o acesso offline e podem desativá-lo por completo para funções específicas. Cada registo em cache permanece visível no registo de atividade e nas janelas de acesso, indicando que utilizador o colocou em cache, em que dispositivo e quando foi a última sincronização.
• Monitorização da atividade. Quando um dispositivo volta a ligar-se, todas as ações realizadas offline são sincronizadas com o registo de atividade e surgem a par do histórico habitual do registo, o que dá aos administradores visibilidade total, tal como em qualquer atividade online.

Limitações do modo offline

• Só de leitura. No modo offline, os registos só podem ser consultados. Criar, editar ou eliminar uma palavra-passe exige ligação ao servidor.
• Revogação. A revogação do acesso a um registo não apaga a cópia local de imediato: a alteração só produz efeito quando o dispositivo volta a ficar online.
• Disponibilidade por licença. O acesso offline só está disponível na licença avançada.

Controlo de anexos de ficheiros

Os administradores podem agora desativar os anexos de ficheiros nos registos em toda a organização. Depois de desativados, os utilizadores não podem adicionar ficheiros a nenhum registo de palavra-passe, independentemente da função ou das permissões do cofre. A definição encontra-se em Gestão de cofres → Definições → Geral.

Melhorias na pesquisa e na navegação

Os resultados de pesquisa incluem agora uma coluna URLs a par de uma coluna com o diretório principal das pastas, o que facilita identificar onde se encontram os itens sem os abrir. A barra de pesquisa ativa-se agora automaticamente assim que o utilizador começa a escrever. Foi também removida a divisão das consultas de pesquisa em subcadeias de texto, pelo que os resultados correspondem agora com maior precisão à intenção do utilizador.

Aplicações de desktop e móveis

Tanto as aplicações de desktop como as móveis incluem agora a implementação do acesso offline descrita acima. A aplicação móvel recebe ainda outras melhorias: controlos ao nível da organização para bloquear capturas de ecrã e gravação de ecrã (Definições do sistema → Extensões do navegador e aplicações móveis) e pesquisa entre pastas, e não apenas em registos individuais. Foi também adicionado o suporte para a transferência do pacote MSI na aplicação de desktop.

Novo: Guias de integração

Em simultâneo com a versão, foi publicada uma secção completa de integração estruturada em torno de cinco funções: utilizadores, gestores de departamento, administradores de TI, engenheiros de DevOps e especialistas em segurança. Cada guia abrange exatamente o que uma pessoa nessa função precisa de configurar no primeiro dia, sem pressupor familiaridade prévia com o produto.

Os administradores que implementam o Passwork em toda a organização dispõem de um guia prático que abrange a integração com LDAP e SSO, a estrutura de cofres e o aprovisionamento de utilizadores em massa. As equipas de DevOps dispõem de um percurso separado para a utilização da CLI e do SDK, contas de serviço e injeção de segredos em pipelines de CI/CD. Os responsáveis pela segurança e pela conformidade podem percorrer listas de verificação alinhadas com a ISO 27001, o RGPD e o NIST.

Passwork conquista o Top Performer Summer 2026 da SourceForge

O Passwork recebe o galardão Top Performer da SourceForge para o verão de 2026, o segundo trimestre consecutivo, com base em avaliações verificadas e numa classificação global de 4,9/5.

PassworkPasswork Team

Resumo das notícias de cibersegurança: O mês em que os agentes de IA começaram a atacar por conta própria

Um agente GPT-5.6 escapou da sua sandbox e comprometeu a infraestrutura da Hugging Face. A SonicWall lançou duas vulnerabilidades 0-day que obrigaram a uma reposição completa de palavras-passe e de TOTP. O relatório de 2026 da IBM sobre o custo das violações de dados atingiu um recorde de 4,99 milhões de dólares. Eis o que aconteceu em cibersegurança neste mês de julho e o que a equipa tem de corrigir primeiro.

PassworkPasswork Team

IBM Cost of a Data Breach Report 2026: A ameaça de IA de 6 milhões de dólares que ninguém está a resolver

Os custos globais das violações de dados atingiram um recorde de 4,99 milhões de dólares em 2026, com a deteção a demorar 247 dias. Os ataques baseados em IA aumentam 56 %, mas a verdadeira crise é outra: os defensores utilizam IA em todo o lado, exceto onde os atacantes entram. 92 % das organizações violadas com recurso a IA não tinham quaisquer controlos de acesso adequados.

PassworkAlex Muntyan

Das neueste Passwork-Release konzentriert sich auf ein Problem, das jedes verteilte Team früher oder später trifft: Was passiert mit dem Passwortzugriff, wenn die Verbindung abbricht? Passwork 7.7 fügt einen sicheren Offline-Modus sowohl für Desktop- als auch für mobile Apps hinzu, während Administratoren die volle Kontrolle darüber behalten, was lokal zwischengespeichert wird.

Sicherer Offline-Zugriff für Desktop- und mobile Apps

Benutzer können jetzt Passwort-Datensätze öffnen, auch wenn ihr Gerät keine Verbindung zum Server hat. Dafür sind zwei bewusste Schritte erforderlich, sodass nichts versehentlich auf einem Gerät landet.

Erstens markiert ein Benutzer einen bestimmten Datensatz mit einem Offline-Symbol , das sowohl in der Passwort-Infokarte als auch in der allgemeinen Passwortliste verfügbar ist. Dies fügt ausgewählte Datensätze zu einer synchronisierten Liste hinzu, die auf allen Geräten des Benutzers unter dem Tab Offline im Navigationsbereich sichtbar ist — zu diesem Zeitpunkt wird noch nichts heruntergeladen oder ist offline verfügbar.

Zweitens öffnet der Benutzer auf einem Gerät den Tab Offline in der Desktop- oder mobilen App und wählt Auf diesem Gerät aktivieren. Erst dann lädt Passwork die verschlüsselten Datensätze in einen lokalen Cache auf diesem spezifischen Gerät.

Beim Öffnen der Desktop- oder mobilen App ohne Internetverbindung sind nur Datensätze verfügbar, die zuvor für den Offline-Zugriff gespeichert wurden. Wenn der Server während einer Sitzung nicht mehr erreichbar ist, bietet die App drei Optionen:

• Abmelden von der Desktop- oder mobilen App
• Verbindung erneut versuchen zum Server
• In den Offline-Modus wechseln um nur zwischengespeicherte Datensätze anzuzeigen

Sobald die Konnektivität wiederhergestellt ist, synchronisiert Passwork den Cache und lädt ein Protokoll jedes Offline-Zugriffs auf den Server hoch.

Admin-Steuerung, Transparenz und Risikoverfolgung

Der Offline-Zugriff wird auf Rollenebene gesteuert und läuft nicht unkontrolliert. Administratoren behalten die volle Kontrolle darüber, wer ihn nutzt und wie er verfolgt wird.

Rollenbasierte Berechtigungen

Administratoren entscheiden, welche Rollen den Offline-Zugriff nutzen können, wie lange ein Gerät ohne Synchronisierung bleiben kann, bevor sein Cache gelöscht wird, und wie viele Datensätze ein einzelnes Gerät speichern kann.

Vollständiger Audit-Trail

Jeder Offline-Download erscheint im Ereignisprotokoll und auf dem Sicherheits-Dashboard. Alle an Offline-Datensätzen durchgeführten Aktionen werden nach der Synchronisierung des Geräts ebenfalls im Aktivitätsprotokoll erfasst, genau wie bei jedem anderen Passwort. Dies gibt Sicherheitsteams das gleiche Maß an Kontrolle über den Offline-Zugriff wie über Online-Aktivitäten.

Geräteebenen-Einblick

Administratoren können sehen, wer einen Datensatz zwischengespeichert hat, auf welchem Gerät und wann dieses Gerät zuletzt synchronisiert wurde. Das Zugriffsmodal für einen Ordner oder Tresor zeigt auch den Benutzer- und Gerätenamen an, sodass Administratoren Offline-Aktivitäten bis zum spezifischen Gerät nachverfolgen können, ohne die Berechtigungsansicht zu verlassen.

Expositionsverfolgung

Das Sicherheits-Panel von Passwork behandelt einen Offline-Datensatz als potenzielle Exposition, sobald er in einem lokalen Cache landet — unabhängig davon, ob der Benutzer ihn tatsächlich öffnet. Dies folgt der gleichen Logik, die bereits auf angesehene Datensätze angewendet wird.

Standardmäßig deaktiviert

Nach dem Upgrade auf Version 7.7 ist die Funktion standardmäßig nur für die Rollen Besitzer und Administrator aktiviert. Für alle anderen ist sie zunächst deaktiviert.

Offline-Grundlagen

• Wo es funktioniert. Datensätze können von jeder App und jedem Web-Client für den Offline-Zugriff markiert werden, aber das Offline-Anzeigen ist nur in den mobilen und Desktop-Apps verfügbar. Die Funktion muss auf jedem Gerät separat aktiviert werden.
• Welche Daten verfügbar sind. Ohne Verbindung können Benutzer nur Passwörter anzeigen, die sie zuvor zur Offline-Liste hinzugefügt und synchronisiert haben.
• Automatischer Ablauf. Wenn ein Gerät nicht innerhalb des vom Administrator festgelegten Zeitrahmens synchronisiert wird, werden zwischengespeicherte Datensätze automatisch gelöscht.
• Rolleneinstellungen. Administratoren legen die Regeln für Benutzer fest: wie viele Datensätze pro Gerät gespeichert werden können und wie lange sie ohne Synchronisierung gültig bleiben.
• Admin-Kontrolle. Administratoren entscheiden, welche Rollen den Offline-Zugriff überhaupt nutzen können, und können ihn für bestimmte Rollen vollständig deaktivieren. Jeder zwischengespeicherte Datensatz bleibt im Aktivitätsprotokoll und in den Zugriffsmodalen sichtbar und zeigt an, welcher Benutzer ihn zwischengespeichert hat, auf welchem Gerät und wann die letzte Synchronisierung stattfand.
• Aktivitätsverfolgung. Sobald ein Gerät wieder verbunden ist, werden alle offline durchgeführten Aktionen mit dem Aktivitätsprotokoll synchronisiert und erscheinen neben dem regulären Verlauf des Datensatzes — dies gibt Administratoren volle Transparenz, genau wie bei jeder Online-Aktivität.

Offline-Einschränkungen

• Schreibgeschützt. Im Offline-Modus können Datensätze nur angezeigt werden. Das Erstellen, Bearbeiten oder Löschen eines Passworts erfordert eine Verbindung zum Server.
• Widerruf. Das Widerrufen des Zugriffs auf einen Datensatz löscht die lokale Kopie nicht sofort — die Änderung wird erst wirksam, wenn das Gerät wieder online ist.
• Planverfügbarkeit. Der Offline-Zugriff ist nur in der Erweiterten Lizenz verfügbar.

Dateianhang-Steuerung

Administratoren können jetzt Dateianhänge an Datensätze für die gesamte Organisation deaktivieren. Nach der Deaktivierung können Benutzer keine Dateien zu Passwort-Datensätzen hinzufügen, unabhängig von Rolle oder Tresor-Berechtigungen. Die Einstellung befindet sich unter Tresorverwaltung → Einstellungen → Allgemein.

Such- und Navigationsverbesserungen

Suchergebnisse enthalten jetzt neben einer übergeordneten Verzeichnisspalte für Ordner auch eine URLs-Spalte, die es einfacher macht zu erkennen, wo sich Elemente befinden, ohne sie zu öffnen. Die Suchleiste wird jetzt automatisch aktiviert, sobald Sie mit der Eingabe beginnen. Zusätzlich wurde die Teilstring-Aufteilung in Suchanfragen entfernt, sodass die Ergebnisse jetzt genauer Ihrer Absicht entsprechen.

Desktop- und mobile Apps

Sowohl Desktop- als auch mobile Apps beinhalten jetzt die oben beschriebene Offline-Zugriffs-Implementierung. Die Mobile-App erhält zusätzliche Updates: organisationsweite Steuerungen zum Blockieren von Screenshots und Bildschirmaufnahmen (Systemeinstellungen → Browser-Erweiterungen und mobile Apps) sowie Suche über Ordner hinweg statt nur einzelner Datensätze. Zusätzlich wurde MSI-Paket-Download-Unterstützung für die Desktop-App hinzugefügt.

Neu: Onboarding-Anleitungen

Parallel zum Release wurde ein vollständiger Onboarding-Bereich veröffentlicht, der auf fünf Rollen ausgerichtet ist — Benutzer, Abteilungsleiter, IT-Administratoren, DevOps-Ingenieure und Sicherheitsspezialisten. Jede Anleitung behandelt genau das, was jemand in dieser Rolle am ersten Tag konfigurieren muss, ohne Vorkenntnisse des Produkts vorauszusetzen.

Administratoren, die Passwork organisationsweit einführen, erhalten ein Playbook mit LDAP- und SSO-Integration, Tresorstruktur und Massen-Benutzerbereitstellung. DevOps-Teams erhalten einen separaten Track für CLI- und SDK-Nutzung, Service-Accounts und Secret-Injection in CI/CD-Pipelines. Sicherheits- und Compliance-Verantwortliche können Checklisten durcharbeiten, die auf ISO 27001, DSGVO und NIST abgestimmt sind.

Passwork gewinnt Top Performer Sommer 2026 auf SourceForge

Passwork erhält das Top-Performer-Badge von SourceForge für den Sommer 2026 — das zweite Quartal in Folge, gestützt durch verifizierte Bewertungen und eine Gesamtbewertung von 4,9/5.

PassworkPasswork Team

Cybersecurity-News-Rückblick: Der Monat, in dem KI-Agenten eigenständig anzugreifen begannen

Ein GPT-5.6-Agent entkam seiner Sandbox und durchbrach die Hugging-Face-Infrastruktur. SonicWall lieferte zwei 0-Days, die einen vollständigen Passwort- und TOTP-Reset erzwangen. IBMs Breach-Cost-Report 2026 erreichte einen Rekord von 4,99 Millionen Dollar. Hier erfahren Sie, was im Juli in der Cybersicherheit passiert ist und was Ihr Team zuerst patchen sollte.

PassworkPasswork Team

IBM Cost of a Data Breach Report 2026: Die 6-Millionen-Dollar-KI-Bedrohung, die niemand behebt

Globale Breach-Kosten erreichen 2026 einen Rekord von 4,99 Millionen Dollar, wobei die Erkennung 247 Tage dauert. KI-gesteuerte Angriffe steigen um 56 %, aber die eigentliche Krise: Verteidiger setzen KI überall ein, außer dort, wo Angreifer einbrechen. 92 % der von KI betroffenen Organisationen hatten keine angemessenen Zugriffskontrollen.

PassworkAlex Muntyan

La última versión de Passwork se centra en un problema que todo equipo distribuido termina enfrentando: qué sucede con el acceso a las contraseñas cuando se pierde la conexión. Passwork 7.7 añade un modo sin conexión seguro tanto a las aplicaciones de escritorio como móviles, manteniendo a los administradores con control total sobre lo que se almacena en caché localmente.

Acceso seguro sin conexión para aplicaciones de escritorio y móviles

Los usuarios ahora pueden abrir registros de contraseñas incluso cuando su dispositivo no tiene conexión con el servidor. Lograrlo requiere dos pasos deliberados, por lo que nada termina en un dispositivo por accidente.

Primero, el usuario marca un registro específico con un icono de sin conexión , disponible tanto en la tarjeta de información de la contraseña como en la lista general de contraseñas. Esto añade los registros seleccionados a una lista sincronizada visible en todos los dispositivos del usuario en la pestaña Sin conexión del panel de navegación — en este punto nada se descarga ni está disponible sin conexión todavía.

Segundo, en un dispositivo, el usuario abre la pestaña Sin conexión en la aplicación de escritorio o móvil y selecciona Habilitar en este dispositivo. Solo entonces Passwork descarga los registros cifrados a una caché local en ese dispositivo específico.

Al abrir la aplicación de escritorio o móvil sin conexión a internet, solo están disponibles los registros previamente guardados para acceso sin conexión. Si el servidor se vuelve inaccesible durante una sesión, la aplicación ofrece tres opciones:

• Cerrar sesión de la aplicación de escritorio o móvil
• Reintentar la conexión al servidor
• Cambiar al modo sin conexión para ver solo los registros en caché

Una vez que se restablece la conectividad, Passwork sincroniza la caché y carga un registro de cada visualización sin conexión al servidor.

Controles de administrador, visibilidad y seguimiento de riesgos

El acceso sin conexión se gestiona a nivel de rol y no funciona sin control. Los administradores mantienen control total sobre quién lo usa y cómo se rastrea.

Permisos basados en roles

Los administradores deciden qué roles pueden usar el acceso sin conexión, cuánto tiempo puede pasar un dispositivo sin sincronizar antes de que se borre su caché, y cuántos registros puede almacenar un solo dispositivo.

Registro de auditoría completo

Cada descarga sin conexión aparece en el registro de eventos y en el panel de seguridad. Todas las acciones realizadas en registros sin conexión también se reflejan en el Registro de actividad una vez que el dispositivo se sincroniza, igual que cualquier otra contraseña. Esto proporciona a los equipos de seguridad el mismo nivel de supervisión sobre el acceso sin conexión que ya tienen sobre la actividad en línea.

Información a nivel de dispositivo

Los administradores pueden ver quién almacenó en caché un registro, en qué dispositivo y cuándo ese dispositivo se sincronizó por última vez. El modal de acceso para una carpeta o bóveda también muestra el nombre del usuario y del dispositivo, para que los administradores puedan rastrear la actividad sin conexión hasta el dispositivo específico sin salir de la vista de permisos.

Seguimiento de exposición

El Panel de seguridad de Passwork trata un registro sin conexión como una exposición potencial en el momento en que llega a una caché local, independientemente de si el usuario realmente lo abre. Esto sigue la misma lógica ya aplicada a los registros visualizados.

Política desactivada por defecto

Después de actualizar a la versión 7.7, la función está habilitada por defecto solo para los roles de Propietario y Administrador. Todos los demás comienzan con la función desactivada.

Aspectos esenciales del modo sin conexión

• Dónde funciona. Los registros pueden marcarse para acceso sin conexión desde cualquier aplicación y cliente web, pero visualizarlos sin conexión solo está disponible en las aplicaciones móviles y de escritorio. Debe habilitarse por separado en cada dispositivo.
• Qué datos están disponibles. Sin conexión, los usuarios solo pueden ver las contraseñas que ya han añadido a la lista sin conexión y sincronizado previamente.
• Expiración automática. Si un dispositivo no se sincroniza dentro del período establecido por el administrador, los registros en caché se eliminan automáticamente.
• Configuración de roles. Los administradores establecen las reglas para los usuarios: cuántos registros pueden almacenarse por dispositivo y cuánto tiempo permanecen válidos sin sincronizar.
• Control del administrador. Los administradores deciden qué roles pueden usar el acceso sin conexión y pueden deshabilitarlo completamente para roles específicos. Cada registro en caché permanece visible en el Registro de actividad y los modales de acceso, mostrando qué usuario lo almacenó en caché, en qué dispositivo y cuándo se sincronizó por última vez.
• Seguimiento de actividad. Una vez que un dispositivo se reconecta, todas las acciones realizadas sin conexión se sincronizan con el Registro de actividad, apareciendo junto con el historial regular del registro — proporcionando a los administradores visibilidad completa, igual que con cualquier actividad en línea.

Limitaciones del modo sin conexión

• Solo lectura. En modo sin conexión, los registros solo pueden visualizarse. Crear, editar o eliminar una contraseña requiere conexión al servidor.
• Revocación. Revocar el acceso a un registro no elimina la copia local instantáneamente — el cambio solo surte efecto una vez que el dispositivo vuelve a estar en línea.
• Disponibilidad del plan. El acceso sin conexión está disponible solo en el plan avanzado.

Controles de archivos adjuntos

Los administradores ahora pueden deshabilitar los archivos adjuntos a los registros en toda la organización. Una vez desactivado, los usuarios no pueden añadir archivos a ningún registro de contraseña, independientemente del rol o los permisos de la bóveda. La configuración se encuentra en Gestión de bóvedas → Configuración → General.

Mejoras en búsqueda y navegación

Los resultados de búsqueda ahora incluyen una columna de URLs junto con una columna de directorio principal para carpetas, facilitando la identificación de dónde se encuentran los elementos sin abrirlos. La barra de búsqueda ahora se activa automáticamente en cuanto comienza a escribir. También se eliminó la división de subcadenas en las consultas de búsqueda, por lo que los resultados ahora coinciden con su intención de manera más precisa.

Aplicaciones de escritorio y móviles

Tanto las aplicaciones de escritorio como móviles ahora incluyen la implementación de acceso sin conexión descrita anteriormente. La aplicación móvil recibe actualizaciones adicionales: controles a nivel de organización para bloquear capturas de pantalla y grabación de pantalla (Configuración del sistema → Extensiones de navegador y aplicaciones móviles) y búsqueda entre carpetas en lugar de solo registros individuales. También se añadió soporte de descarga de paquete MSI para la aplicación de escritorio.

Nuevo: Guías de incorporación

Junto con el lanzamiento, se publicó una sección completa de incorporación construida en torno a cinco roles — usuarios, gerentes de departamento, administradores de TI, ingenieros DevOps y especialistas en seguridad. Cada guía cubre exactamente lo que alguien en ese rol necesita configurar en el primer día, sin asumir familiaridad previa con el producto.

Los administradores que implementan Passwork en toda la organización obtienen un manual que cubre la integración con LDAP y SSO, la estructura de bóvedas y el aprovisionamiento masivo de usuarios. Los equipos de DevOps tienen un itinerario separado para el uso de CLI y SDK, cuentas de servicio e inyección de secretos en pipelines de CI/CD. Los oficiales de seguridad y cumplimiento pueden trabajar con listas de verificación mapeadas a ISO 27001, GDPR y NIST.

Passwork gana Top Performer Verano 2026 en SourceForge

Passwork obtiene la insignia Top Performer de SourceForge para el Verano 2026 — su segundo trimestre consecutivo, respaldado por reseñas verificadas y una calificación general de 4.9/5.

PassworkPasswork Team

Resumen de noticias de ciberseguridad: El mes en que los agentes de IA comenzaron a atacar por su cuenta

Un agente GPT-5.6 escapó de su sandbox y vulneró la infraestructura de Hugging Face. SonicWall lanzó dos 0-days que forzaron un restablecimiento completo de contraseñas y TOTP. El informe de costos de brechas 2026 de IBM alcanzó un récord de $4.99 millones. Esto es lo que sucedió en ciberseguridad este julio y lo que su equipo necesita parchear primero.

PassworkPasswork Team

Informe IBM del Costo de una Brecha de Datos 2026: La amenaza de $6M de la IA que nadie está solucionando

Los costos globales de brechas alcanzaron un récord de $4.99M en 2026, con una detección que toma 247 días. Los ataques impulsados por IA aumentaron un 56%, pero la verdadera crisis: los defensores despliegan IA en todas partes excepto donde los atacantes entran. El 92% de las organizaciones vulneradas por IA no tenían controles de acceso adecuados.

PassworkAlex Muntyan

Passwork's latest release focuses on one problem every distributed team eventually runs into: what happens to password access when the connection drops. Passwork 7.7 adds secure offline mode to both desktop and mobile apps, while keeping admins fully in control of what gets cached locally.

Secure offline access for desktop and mobile apps

Users can now open password records even when their device has no connection to the server. Getting there takes two deliberate steps, so nothing ends up on a device by accident.

First, a user marks specific record with an offline icon , available both in the password info card and in the general password list. This adds selected records to a synced list visible across all that user's devices under the Offline tab in the navigation panel — at this point nothing is downloaded or available offline yet.

Second, on a device, the user opens the Offline tab in the desktop or mobile app and selects Enable on this device. Only then does Passwork pull the encrypted records into a local cache on that specific device.

When opening the desktop or mobile app without an internet connection, only records previously saved for offline access are available. If the server becomes unreachable mid-session, the app offers three options:

• Sign out of the desktop or mobile app
• Retry the connection to the server
• Switch to offline mode to view only cached records

Once connectivity returns, Passwork syncs the cache and uploads a log of every offline view to the server.

Admin controls, visibility, and risk tracking

Offline access is governed at the role level and doesn't run unchecked. Admins retain full control over who uses it and how it's tracked.

Role-based permissions

Administrators decide which roles can use offline access, how long a device can go unsynced before its cache is wiped, and how many records a single device can hold.

Full audit trail

Every offline download appears in the event log and on the security dashboard. All actions performed on offline records are also reflected in the Activity log once the device syncs, just like any other password. This gives security teams the same level of oversight over offline access as they already have over online activity.

Device-level insight

Admins can see who cached a record, on which device, and when that device last synced. The access modal for a folder or vault also displays the user and device name, so admins can trace offline activity down to the specific device without leaving the permissions view.

Exposure tracking

Passwork Security panel treats an offline record as a potential exposure the moment it lands in a local cache, whether or not the user actually opens it. This follows the same logic already applied to viewed records.

Default-off policy

After upgrading to version 7.7, the feature is enabled by default only for Owner and Administrator roles. Everyone else starts with it off.

Offline essentials

• Where it works. Records can be marked for offline access from any app and web client, but viewing them offline is only available in the mobile and desktop apps. It must be enabled separately on each device.
• What data is available. Without a connection, users can only view passwords they've already added to the offline list and synced beforehand.
• Automatic expiration. If a device doesn't sync within the timeframe set by the administrator, cached records are automatically wiped.
• Role settings. Administrators set the rules for users: how many records can be stored per device and how long they remain valid without syncing.
• Admin control. Administrators decide which roles can use offline access at all and can disable it entirely for specific roles. Every cached record stays visible in the Activity log and access modals, showing which user cached it, on which device, and when it last synced.
• Activity tracking. Once a device reconnects, all actions performed offline sync to the Activity log, appearing alongside the record's regular history — giving admins full visibility, just as with any online activity.

Offline limitations

• Read-only. In offline mode, records can only be viewed. Creating, editing, or deleting a password requires a connection to the server.
• Revocation. Revoking access to a record doesn't wipe the local copy instantly — the change only takes effect once the device comes back online.
• Plan availability. Offline access is available only in the Advanced plan.

File attachment controls

Administrators can now disable file attachments to records across the entire organization. Once turned off, users can't add files to any password record, regardless of role or vault permissions. The setting is located under Vault management → Settings → General.

Search and navigation improvements

Search results now include a URLs column alongside a parent directory column for folders, making it easier to identify where items live without opening them. The search bar now activates automatically as soon as you start typing. We also removed substring splitting in search queries, so results now match your intent more accurately.

Desktop and mobile apps

Both desktop and mobile apps now include the offline access implementation described above. Mobile picks up additional updates: org-wide controls to block screenshots and screen recording (System settings → Browser extensions and mobile apps) and search across folders instead of just individual records. Also added MSI package download support for the desktop app.

New: Onboarding guides

Alongside the release, we published a full onboarding section built around five roles — users, department managers, IT administrators, DevOps engineers, and security specialists. Each guide covers exactly what someone in that role needs to configure on day one, with no assumption of prior familiarity with the product.

Administrators rolling out Passwork organization-wide get a playbook covering LDAP and SSO integration, vault structure, and bulk user provisioning. DevOps teams get a separate track for CLI and SDK usage, service accounts, and secret injection into CI/CD pipelines. Security and compliance officers can work through checklists mapped to ISO 27001, GDPR, and NIST.

Passwork wins Top Performer Summer 2026 on SourceForge

Passwork earns SourceForge’s Top Performer badge for Summer 2026 — its second straight quarter, backed by verified reviews and a 4.9/5 overall rating.

PassworkPasswork Team

Cybersecurity news recap: The month AI agents started attacking on their own

A GPT-5.6 agent escaped its sandbox and breached Hugging Face infrastructure. SonicWall shipped two 0-days that forced a full password and TOTP reset. IBM’s 2026 breach cost report hit a record $4.99 million. Here’s what happened in cybersecurity this July and what your team needs to patch first.

PassworkPasswork Team

2026 IBM Cost of a Data Breach Report: The $6M AI threat no one’s fixing

Global breach costs hit record $4.99M in 2026, with detection taking 247 days. AI-driven attacks surge 56%, but the real crisis: defenders deploy AI everywhere except where attackers break in. 92% of AI-breached organizations had zero proper access controls.

PassworkAlex Muntyan

As políticas de cofre do Passwork (também designadas tipos de cofre ou Vault Types): uma camada de governação configurável que permite aos administradores definir, para cada categoria de cofre, quem são os seus administradores permanentes, que nível de acesso têm os criadores do cofre e quem pode criar cofres desse tipo. Uma vez definidas, estas regras aplicam-se automaticamente a todos os cofres criados nesse tipo.

A maioria das empresas não consegue afirmar com certeza quem tem direitos de administrador sobre o cofre de credenciais partilhadas de uma determinada equipa, porque o acesso de administração é atribuído de modo informal, sem uma política que o sustente. As políticas de cofre de palavras-passe empresariais resolvem este problema ao associar os direitos de administração à própria política do cofre, e não a quem o criou.

Este guia explica como a arquitetura de tipos de cofre (Vault Types) do Passwork dá aos diretores de TI (CIO) e aos responsáveis pela segurança da informação (CISO) um modelo prático de governação de cofres, que vai além das regras básicas de palavras-passe.

O que são as políticas de cofre e porque é que os CIO precisam delas

As políticas de cofre são regras de governação que determinam quem pode criar um cofre, a quem é atribuído automaticamente o acesso de administrador e quem não pode ser removido desse acesso. Deslocam o debate dos «requisitos de complexidade das palavras-passe» para a governação de cofres: um controlo estrutural sobre o armazenamento de credenciais da empresa, e não apenas sobre as próprias credenciais.

Três categorias de ferramentas afirmam resolver este problema: 

• Os gestores de palavras-passe de consumo tratam bem a partilha de credenciais pessoais ou de pequenas equipas, mas não foram concebidos para a governação departamental em escala 
• As plataformas de gestão de acessos privilegiados (PAM) protegem contas ao nível da infraestrutura e contas de serviço, mas acrescentam custos e complexidade de que a maioria dos casos de partilha de credenciais não precisa 
• Os gestores de palavras-passe empresariais com motores dedicados de políticas de cofre situam-se entre os dois, e é esta a abordagem em que o presente artigo se centra

Ação para o CIO: Audite a organização à procura de «cofres não autorizados»: pastas partilhadas ou cofres de equipa criados sem o conhecimento da TI, muitas vezes numa ferramenta de consumo que um departamento adotou por iniciativa própria.

Arquitetura das políticas de cofre: como o Passwork estrutura os acessos

O Passwork 7.1 introduziu uma arquitetura de tipos de cofre em que cada política de cofre define os seus próprios administradores, permissões de criação e regras de criação antes de existir um único cofre. Todos os novos cofres criados ao abrigo dessa política herdam automaticamente os administradores designados, e o proprietário do cofre não os pode remover.

Por predefinição, existem dois tipos básicos de cofre: os Cofres de utilizador, repositórios de credenciais privados ou partilhados, controlados inteiramente pelo seu criador, e os Cofres da empresa, que incluem sempre os administradores da empresa. Além destes, os administradores podem criar um número ilimitado de tipos de cofre personalizados, um por departamento, projeto ou nível de acesso, cada um com os seus próprios administradores designados e regras de criação.

Daqui resultam três benefícios concretos para o negócio:

• Controlo sobre os cofres de equipa sem que um único superadministrador detenha uma chave mestra de todas as palavras-passe da empresa
• Um caminho de recuperação que funciona quando alguém sai ou perde o acesso, através de uma conta de recuperação previamente aprovisionada, cuja palavra-passe mestra é guardada offline
• Nenhum «botão único» ou chave mestra obrigatória que desbloqueie de uma só vez as credenciais de toda a organização

A versão 7.4 acrescentou controlos de restrição específicos para os cofres de utilizador, que permitem aos administradores limitar também as permissões de partilha e de criação no nível dos cofres pessoais, fechando uma lacuna que os tipos de cofre básicos, por si sós, não cobriam.

Ação para o CIO: Mapeie a estrutura organizacional para tipos de cofre, um por departamento ou projeto, e atribua administradores da empresa antes de as equipas começarem a criar cofres por iniciativa própria.

O Passwork face a outras abordagens de controlo de acesso a cofres

Para qualquer ferramenta de gestão de credenciais, importa saber se a função de administrador está associada previamente a uma política e se a recuperação de acessos exige uma chave que também abre tudo o resto na organização. Na tabela seguinte, a resposta pretendida na coluna da chave única é «Não»: significa que não existe um ponto único de falha integrado.

Os gestores de palavras-passe orientados para o consumidor permitem muitas vezes que os administradores de equipa giram um cofre partilhado, mas raramente aplicam essa política automaticamente a todos os novos cofres criados por um departamento. 

Algumas ferramentas dependem de um único superadministrador, que pode repor a palavra-passe de qualquer utilizador e aceder a todas as pastas partilhadas da empresa. Outras associam todos os cofres da empresa a uma única chave de cifragem partilhada, pelo que o comprometimento dessa chave expõe tudo de uma só vez. 

As plataformas PAM resolvem um problema diferente: guardam em cofre as credenciais privilegiadas da infraestrutura, muitas vezes protegidas pela sua própria chave mestra ou chave break-glass, em vez de governarem a partilha de palavras-passe ao nível das equipas.

Ação para o CIO: Avalie a ferramenta de credenciais atual segundo estes três critérios: atribuição de administradores associada a políticas, um caminho de recuperação funcional e a ausência de uma chave universal obrigatória.

Lista de verificação de governação de cofres com cinco políticas para CIO

Cinco decisões de configuração específicas transformam a implementação de um gestor de palavras-passe numa governação de cofres funcional. Cada uma corresponde a um modo de falha distinto, observado em intervenções reais de resposta a incidentes, e não a um risco teórico.

• Desative a criação e a partilha de cofres privados onde não sejam necessárias. Os cofres privados sem restrições são precisamente a forma como se criam cofres não autorizados fora da visibilidade da TI. Restrinja a criação de cofres privados às funções que realmente precisam dela.
• Atribua administradores da empresa a cada política de cofre de equipa e de departamento. Assim garante-se uma supervisão contínua, sem depender de que uma única pessoa se lembre de se adicionar.
• Defina uma política de acesso de emergência antes de precisar dela. Decida entre um único circuito de recuperação à escala da organização ou contas de recuperação separadas por departamento, e guarde offline as credenciais mestras dessa conta de recuperação.
• Implemente o controlo de acessos baseado em funções (RBAC) através do Active Directory ou do LDAP. A sincronização de grupos e funções aplica automaticamente o princípio do menor privilégio e elimina erros de aprovisionamento manual quando os colaboradores mudam de função.
• Alinhe o comprimento e as regras de rotação das palavras-passe com as orientações atuais do NIST. A publicação NIST SP 800-63B Rev. 4 (2025) estabelece um mínimo de 15 caracteres para as palavras-passe usadas como único fator de autenticação e retira formalmente o requisito obrigatório de rotação a cada 90 dias (NIST SP 800-63B, 2025) [verificar o URL exato da publicação antes da impressão]. A rotação forçada sem indícios de comprometimento leva os utilizadores para palavras-passe previsíveis, apenas incrementadas, que é precisamente o resultado que as orientações agora desencorajam.

Ação para o CIO: Realize, ainda neste trimestre, uma auditoria de lacunas face às cinco políticas e atribua um responsável a cada constatação, em vez de tratar a auditoria como um relatório pontual.

Cumprir os requisitos da NIS2 e da ISO 27001 com a governação de cofres

As políticas de cofre correspondem diretamente aos dois requisitos que os auditores verificam primeiro: controlo de acessos documentado e um registo de auditoria verificável. A Diretiva NIS2 (UE) 2022/2555, no artigo 21.º, n.º 2, exige políticas de controlo de acessos e autenticação multifator como parte das medidas de gestão dos riscos de cibersegurança de uma entidade. Os controlos 5.15 e 8.15 da norma ISO/IEC 27001:2022 exigem o mesmo par: um modelo de acesso definido e um registo de quem o exerceu e quando.

Os administradores da empresa associados a uma política de cofre cobrem o lado do controlo de acessos sem folhas de cálculo manuais. Os registos de auditoria exportáveis e com data e hora cobrem o resto.

O DBIR 2026 da Verizon verificou que as credenciais estiveram presentes, em alguma fase, em 39 % das violações de dados, como vetor de acesso inicial em 13 % das violações confirmadas e como principal vetor em 52 % dos Basic Web Application Attacks (ataques básicos a aplicações web). IBM indica, no 2026 Cost of a Data Breach Report, que o custo médio global de uma violação de dados é de 4,99 milhões de dólares, um aumento de 12 % em relação ao ano passado e um máximo histórico.

Ação para o CIO: Peça à equipa de segurança um relatório atualizado de cobertura do controlo de acessos da NIS2 ainda este mês, antes que seja um auditor a pedi-lo primeiro.

O que isto significa para a implementação

A governação de cofres é uma decisão estrutural, tomada como a segmentação de rede: concebida em função dos departamentos e dos níveis de risco antes de um incidente forçar uma reformulação. As organizações que acertam nisto tratam-no assim desde o início. Ao abrigo da NIS2 e do RGPD, essa estrutura é hoje um requisito para as empresas abrangidas.

Comece pela auditoria, não pela ferramenta. Identifique os cofres que existem hoje, quem realmente os controla e onde o caminho de recuperação falha se uma só pessoa sair.

Perguntas frequentes

Passwork 7.7: modo offline seguro para aplicações de computador e móveis

As palavras-passe passam a funcionar também offline. O Passwork 7.7 traz acesso offline seguro com supervisão administrativa total, controlos de anexos de ficheiros ao nível da organização e cinco novos guias de integração baseados em funções, para uma implementação mais tranquila.

Passwork BlogPasswork Team

DBIR 2026 da Verizon: 10 estatísticas que devem mudar a estratégia de segurança

O DBIR 2026 da Verizon analisou mais de 22 000 violações de dados em 145 países. A exploração de vulnerabilidades ultrapassou o abuso de credenciais como principal vetor de ataque, enquanto o ransomware, o risco de terceiros e os ataques assistidos por IA cresceram de forma acentuada. Estes são os 10 números que importam.

Passwork BlogAlex Muntyan

Requisitos de palavras-passe da NIS2: o que as empresas europeias têm de fazer em 2026

As lacunas de credenciais são o principal ponto de falha nas auditorias da NIS2 em 2026. Este guia abrange os requisitos de palavras-passe do artigo 21.º, o alinhamento com a NIST SP 800-63B, as medidas de reforço (hardening) do AD e as provas de auditoria que os reguladores pedem primeiro.

Passwork BlogAlex Muntyan

Tresor-Richtlinien in Passwork (auch als Tresortypen bezeichnet): eine konfigurierbare Governance-Ebene, mit der Administratoren für jede Kategorie von Tresoren festlegen können, wer die permanenten Administratoren sind, welches Zugangslevel die Ersteller des Tresors erhalten und wer Tresore dieses Typs erstellen darf. Einmal festgelegt, gelten diese Regeln automatisch für jeden Tresor, der unter diesem Typ erstellt wird.

Die meisten Unternehmen können nicht mit Sicherheit sagen, wer Administratorrechte über den gemeinsamen Anmeldedaten-Tresor eines bestimmten Teams hat, da Admin-Zugriff informell gewährt wird, ohne eine zugrundeliegende Richtlinie. Enterprise-Passwort-Tresor-Richtlinien beheben dies, indem sie Admin-Rechte an die Tresor-Richtlinie selbst binden und nicht an denjenigen, der den Tresor zufällig erstellt hat.

Dieser Leitfaden erklärt, wie die Tresortypen-Architektur von Passwork CIOs und CISOs ein funktionierendes Modell für Tresor-Governance bietet, das über einfache Passwortregeln hinausgeht.

Was sind Tresor-Richtlinien und warum CIOs sie benötigen

Tresor-Richtlinien sind Governance-Regeln, die festlegen, wer einen Tresor erstellen kann, wer automatisch Administratorzugriff erhält und wer nicht von diesem Zugriff entfernt werden kann. Sie verlagern das Gespräch von „Passwort-Komplexitätsanforderungen" zu Tresor-Governance: strukturelle Kontrolle über die Speicherung von Unternehmensanmeldedaten, nicht nur über die Anmeldedaten selbst.

Drei Kategorien von Tools beanspruchen, dieses Problem zu lösen: 

• Consumer-Passwortmanager handhaben die gemeinsame Nutzung von Anmeldedaten für Einzelpersonen oder kleine Teams gut, wurden aber nicht für abteilungsübergreifende Governance im großen Maßstab entwickelt. 
• Privileged Access Management (PAM)-Plattformen sichern Infrastruktur- und Dienstkonten ab, verursachen aber Kosten und Komplexität, die die meisten Anwendungsfälle für die gemeinsame Nutzung von Anmeldedaten nicht benötigen. 
• Enterprise-Passwortmanager mit dedizierten Tresor-Richtlinien-Engines befinden sich zwischen beiden — und dieser Ansatz ist der Fokus dieses Artikels.

Handlungsempfehlung für CIOs: Führen Sie in Ihrer Organisation ein Audit nach „Schatten-Tresoren" durch — gemeinsame Ordner oder Team-Tresore, die ohne Wissen der IT erstellt wurden, oft innerhalb eines Consumer-Tools, das eine einzelne Abteilung eigenständig eingeführt hat.

Die Architektur hinter Tresor-Richtlinien: Wie Passwork die Zugangskontrolle strukturiert

Passwork 7.1 führte eine Tresortypen-Architektur ein, bei der jede Tresor-Richtlinie ihre eigenen Administratoren, Ersteller-Berechtigungen und Erstellungsregeln definiert, bevor ein einziger Tresor existiert. Jeder neue Tresor, der unter dieser Richtlinie erstellt wird, erbt automatisch die zugewiesenen Administratoren, und der Besitzer des Tresors kann diese nicht entfernen.

Zwei grundlegende Tresortypen werden standardmäßig mitgeliefert: Benutzer-Tresore, private oder gemeinsame Anmeldedatenspeicher, die vollständig von ihrem Ersteller kontrolliert werden, und Unternehmens-Tresore, die immer die Unternehmensadministratoren der Organisation einschließen. Darüber hinaus können Administratoren unbegrenzt viele benutzerdefinierte Tresortypen erstellen — einen pro Abteilung, Projekt oder Zugangsstufe — jeweils mit eigenen zugewiesenen Administratoren und Erstellungsregeln.

Dies führt zu drei konkreten Ergebnissen für das Unternehmen:

• Kontrolle über Team-Tresore ohne einen einzelnen Super-Administrator, der einen Masterschlüssel zu jedem Passwort im Unternehmen besitzt.
• Ein Wiederherstellungspfad, der funktioniert, wenn jemand das Unternehmen verlässt oder den Zugriff verliert, durch ein vorab bereitgestelltes Wiederherstellungskonto, dessen Masterpasswort offline gespeichert ist.
• Kein obligatorischer „Ein-Knopf"- oder Masterschlüssel, der alle Anmeldedaten der gesamten Organisation auf einmal entsperrt.

Version 7.4 fügte Einschränkungskontrollen speziell für Benutzer-Tresore hinzu, mit denen Administratoren auch auf der Ebene der persönlichen Tresore Freigabe- und Erstellungsberechtigungen einschränken können. Dies schließt eine Lücke, die die grundlegenden Tresortypen allein nicht abdeckten.

Handlungsempfehlung für CIOs: Ordnen Sie Ihre Organisationsstruktur den Tresortypen zu — einen pro Abteilung oder Projekt — und weisen Sie Unternehmensadministratoren zu, bevor Teams beginnen, eigenständig Tresore zu erstellen.

Wie Passwork im Vergleich zu anderen Ansätzen zur Tresor-Zugangskontrolle abschneidet

Für jedes Tool zur Verwaltung von Anmeldedaten ist entscheidend, ob die Admin-Rolle vorab an eine Richtlinie gebunden ist und ob die Wiederherstellung des Zugriffs einen Schlüssel erfordert, der gleichzeitig alles andere in der Organisation öffnet. In der folgenden Tabelle ist „Nein" in der Spalte „Einzelner Schlüssel" die gewünschte Antwort: Es bedeutet, dass es keinen eingebauten Single Point of Failure gibt.

Consumer-orientierte Passwortmanager erlauben es Team-Admins oft, einen gemeinsamen Tresor zu verwalten, wenden diese Richtlinie aber selten automatisch auf jeden neuen Tresor an, den eine Abteilung erstellt. 

Einige Tools setzen auf einen einzelnen Super-Admin, der das Passwort jedes Benutzers zurücksetzen und auf jeden gemeinsamen Ordner im Unternehmen zugreifen kann. Andere binden alle Unternehmens-Tresore an einen einzigen gemeinsamen Verschlüsselungsschlüssel, sodass die Kompromittierung dieses Schlüssels alles auf einmal offenlegt. 

PAM-Plattformen lösen ein anderes Problem: Sie sichern privilegierte Infrastruktur-Anmeldedaten, oft hinter einem eigenen Master- oder Breakglass-Schlüssel, anstatt die Passwort-Freigabe auf Teamebene zu regeln.

Handlungsempfehlung für CIOs: Bewerten Sie Ihr aktuelles Anmeldedaten-Tool anhand dieser drei Kriterien: richtliniengebundene Admin-Zuweisung, ein funktionierender Wiederherstellungspfad und das Fehlen eines obligatorischen universellen Schlüssels.

Die 5-Punkte-Tresor-Governance-Checkliste, die jeder CIO umsetzen sollte

Fünf spezifische Konfigurationsentscheidungen verwandeln die Bereitstellung eines Passwortmanagers in funktionierende Tresor-Governance. Jede adressiert einen bestimmten Fehlermodus, der bei echten Incident-Response-Einsätzen beobachtet wurde — kein theoretisches Risiko.

• Deaktivieren Sie die Erstellung und Freigabe privater Tresore, wo sie nicht benötigt wird. Uneingeschränkte private Tresore sind genau der Weg, wie Schatten-Tresore außerhalb der Sichtbarkeit der IT entstehen. Beschränken Sie die Erstellung privater Tresore auf Rollen, die sie wirklich benötigen.
• Weisen Sie jeder Team- und Abteilungs-Tresor-Richtlinie Unternehmensadministratoren zu. Dies garantiert eine kontinuierliche Aufsicht, ohne davon abhängig zu sein, dass sich jemand daran erinnert, sich selbst hinzuzufügen.
• Definieren Sie eine Notfallzugriffsrichtlinie, bevor Sie sie benötigen. Entscheiden Sie sich zwischen einem einzigen organisationsweiten Wiederherstellungsbereich oder separaten Wiederherstellungskonten pro Abteilung und speichern Sie die Master-Anmeldedaten für dieses Wiederherstellungskonto offline.
• Implementieren Sie RBAC (rollenbasierte Zugangskontrolle) über Active Directory oder LDAP. Die automatische Synchronisierung von Gruppen und Rollen wendet das Prinzip der minimalen Rechtevergabe an und eliminiert manuelle Bereitstellungsfehler, wenn Mitarbeiter ihre Rollen wechseln.
• Richten Sie Passwortlänge und Rotationsregeln an den aktuellen NIST-Richtlinien aus. NIST SP 800-63B Rev. 4 (2025) setzt ein Minimum von 15 Zeichen für Passwörter fest, die als einziger Authentifizierungsfaktor verwendet werden, und schafft die obligatorische 90-Tage-Rotationsanforderung offiziell ab (NIST SP 800-63B, 2025) [exakte Veröffentlichungs-URL vor dem Druck überprüfen]. Erzwungene Rotation ohne Hinweise auf eine Kompromittierung führt dazu, dass Benutzer vorhersehbare, inkrementierte Passwörter verwenden — genau das Ergebnis, das die Richtlinie jetzt unterbinden soll.

Handlungsempfehlung für CIOs: Führen Sie in diesem Quartal ein Gap-Audit gegen alle fünf Richtlinien durch und weisen Sie für jede Feststellung einen Verantwortlichen zu, anstatt das Audit als einmaligen Bericht zu behandeln.

Erfüllung von NIS2- und ISO 27001-Anforderungen mit Tresor-Governance

Tresor-Richtlinien ordnen sich direkt zwei Anforderungen zu, die Prüfer zuerst überprüfen: dokumentierte Zugangskontrolle und ein überprüfbarer Audit-Trail. Die NIS2-Richtlinie (EU) 2022/2555, Artikel 21(2), verlangt Zugangskontrollrichtlinien und Multi-Faktor-Authentifizierung als Teil der Cybersicherheits-Risikomanagementmaßnahmen einer Einrichtung. Die Kontrollen 5.15 und 8.15 von ISO/IEC 27001:2022 erfordern dieselbe Kombination: ein definiertes Zugangsmodell plus einen Nachweis darüber, wer es wann genutzt hat.

An eine Tresor-Richtlinie gebundene Unternehmensadministratoren decken die Zugangskontrollseite ab, ohne eine manuelle Tabelle zu erfordern. Zeitgestempelte, exportierbare Audit-Logs decken den Rest ab.

Verizons 2026 DBIR stellte fest, dass Anmeldedaten in irgendeiner Phase bei 39 % der Sicherheitsverletzungen eine Rolle spielten, in 13 % der bestätigten Sicherheitsverletzungen der initiale Zugriffsvektor waren und der führende Vektor bei 52 % der Basic Web Application Attacks. IBMs 2026 Cost of a Data Breach Report beziffert die globalen durchschnittlichen Kosten einer Sicherheitsverletzung auf 4,99 Millionen US-Dollar — ein Anstieg von 12 % gegenüber dem Vorjahr und ein Rekordhoch.

Handlungsempfehlung für CIOs: Fordern Sie diesen Monat von Ihrem Sicherheitsteam einen aktuellen NIS2-Zugangskontroll-Abdeckungsbericht an — bevor ein Prüfer zuerst danach fragt.

Was das für Ihren Rollout bedeutet

Tresor-Governance ist eine strukturelle Entscheidung, die genauso getroffen wird wie Netzwerksegmentierung: Sie wird um Abteilungen und Risikostufen herum entworfen, bevor ein Vorfall eine Neugestaltung erzwingt. Die Organisationen, die dies richtig machen, behandeln es von Anfang an so. Unter NIS2 und DSGVO ist diese Struktur nun eine Anforderung für Unternehmen im Geltungsbereich.

Beginnen Sie mit dem Audit, nicht mit dem Tool. Erfassen Sie, welche Tresore heute existieren, wer sie tatsächlich kontrolliert und wo der Wiederherstellungspfad unterbrochen wird, wenn eine Person das Unternehmen verlässt.

Häufig gestellte Fragen

Las políticas de bóvedas de Passwork (también llamadas Tipos de Bóveda): una capa de gobernanza configurable que permite a los administradores definir, para cada categoría de bóveda, quiénes son sus administradores permanentes, qué nivel de acceso obtienen los creadores de bóvedas y quién tiene permitido crear bóvedas de ese tipo. Una vez establecidas, estas reglas se aplican automáticamente a cada bóveda creada bajo ese tipo.

La mayoría de las empresas no pueden afirmar con certeza quién tiene derechos de administrador sobre la bóveda de credenciales compartidas de un equipo determinado, porque el acceso de administrador se otorga de manera informal, sin una política detrás. Las políticas de bóvedas de contraseñas empresariales solucionan esto vinculando los derechos de administrador a la política de la bóveda en sí, no a quien la creó.

Esta guía explica cómo la arquitectura de Tipos de Bóveda de Passwork proporciona a los CIO y CISO un modelo funcional para la gobernanza de bóvedas, más allá de las reglas básicas de contraseñas.

Qué son las políticas de bóvedas y por qué los CIO las necesitan

Las políticas de bóvedas son reglas de gobernanza que determinan quién puede crear una bóveda, quién obtiene automáticamente acceso de administrador a ella y quién no puede ser removido de ese acceso. Cambian la conversación de «requisitos de complejidad de contraseñas» a gobernanza de bóvedas: control estructural sobre el almacenamiento de credenciales corporativas, no solo sobre las credenciales en sí.

Tres categorías de herramientas afirman resolver esto: 

• Los gestores de contraseñas de consumo manejan bien el intercambio de credenciales personales o de equipos pequeños, pero no fueron diseñados para la gobernanza departamental a escala. 
• Las plataformas de gestión de acceso privilegiado (PAM) aseguran cuentas de servicio y de nivel de infraestructura, pero añaden costos y complejidad que la mayoría de los casos de uso de intercambio de credenciales no necesitan. 
• Los gestores de contraseñas empresariales con motores de políticas de bóvedas dedicados se sitúan entre ambos, y ese es el enfoque en el que se centra este artículo.

Acción para el CIO: Audite su organización en busca de «bóvedas no autorizadas» — carpetas compartidas o bóvedas de equipo creadas sin conocimiento de TI, a menudo dentro de una herramienta de consumo que un departamento individual adoptó de forma independiente.

La arquitectura detrás de las políticas de bóvedas: cómo Passwork estructura el control de acceso

Passwork 7.1 introdujo una arquitectura de tipos de bóveda donde cada política de bóveda define sus propios administradores, permisos del creador y reglas de creación antes de que exista una sola bóveda. Cada nueva bóveda construida bajo esa política hereda automáticamente sus administradores designados, y el propietario de la bóveda no puede eliminarlos.

Dos tipos de bóveda básicos vienen por defecto: Bóvedas de usuario, almacenes de credenciales privados o compartidos controlados completamente por su creador, y Bóvedas de empresa, que siempre incluyen a los administradores corporativos de la organización. Más allá de estos, los administradores pueden crear tipos de bóveda personalizados ilimitados, uno por departamento, proyecto o nivel de acceso, cada uno con sus propios administradores designados y reglas de creación.

Esto produce tres resultados concretos para el negocio:

• Control sobre las bóvedas de equipo sin un único superadministrador que posea una clave maestra para todas las contraseñas de la empresa.
• Una ruta de recuperación que funciona cuando alguien se va o pierde acceso, a través de una cuenta de recuperación preaprovisionada cuya contraseña maestra se almacena fuera de línea.
• Sin «un botón» obligatorio ni clave maestra que desbloquee todas las credenciales de la organización a la vez.

La versión 7.4 añadió controles de restricción específicamente para Bóvedas de usuario, permitiendo a los administradores limitar los permisos de compartir y creación también en el nivel de bóveda personal, cerrando una brecha que los tipos de bóveda básicos por sí solos no cubrían.

Acción para el CIO: Mapee su estructura organizacional a tipos de bóveda, uno por departamento o proyecto, y asigne administradores corporativos antes de que los equipos comiencen a crear bóvedas por su cuenta.

Cómo se compara Passwork con otros enfoques de control de acceso a bóvedas

Lo que importa para cualquier herramienta de gestión de credenciales es si el rol de administrador está vinculado a una política de antemano, y si recuperar el acceso requiere una clave que también abre todo lo demás en la organización. En la tabla siguiente, «No» en la columna de clave única es la respuesta deseada: significa que no hay un único punto de fallo incorporado.

Los gestores de contraseñas orientados al consumidor a menudo permiten que los administradores de equipo gestionen una bóveda compartida, pero rara vez aplican esa política automáticamente a cada nueva bóveda que crea un departamento. 

Algunas herramientas dependen de un único superadministrador que puede restablecer la contraseña de cualquier usuario y acceder a cada carpeta compartida en la empresa. Otras vinculan todas las bóvedas corporativas a una única clave de cifrado compartida, de modo que comprometer esa clave expone todo a la vez. 

Las plataformas PAM resuelven un problema diferente: almacenan credenciales privilegiadas de infraestructura, a menudo detrás de su propia clave maestra o de emergencia, en lugar de gobernar el intercambio de contraseñas a nivel de equipo.

Acción para el CIO: Evalúe su herramienta de credenciales actual contra estos tres criterios: asignación de administradores vinculada a políticas, una ruta de recuperación funcional y la ausencia de una clave universal obligatoria.

La lista de verificación de 5 políticas de gobernanza de bóvedas que todo CIO debería implementar

Cinco decisiones de configuración específicas convierten una implementación de gestor de contraseñas en gobernanza de bóvedas funcional. Cada una aborda un modo de fallo distinto observado en compromisos reales de respuesta a incidentes, no un riesgo teórico.

• Desactive la creación y el intercambio de bóvedas privadas donde no sea necesario. Las bóvedas privadas sin restricciones son exactamente cómo se forman las bóvedas no autorizadas fuera de la visibilidad de TI. Restrinja la creación de bóvedas privadas a los roles que realmente lo necesiten.
• Asigne administradores corporativos a cada política de bóveda de equipo y departamental. Esto garantiza supervisión continua sin depender de que ningún individuo recuerde añadirse a sí mismo.
• Defina una política de acceso de emergencia antes de necesitarla. Decida entre un contorno de recuperación único para toda la organización o cuentas de recuperación separadas por departamento, y almacene las credenciales maestras de esa cuenta de recuperación fuera de línea.
• Implemente RBAC (control de acceso basado en roles) a través de Active Directory o LDAP. La sincronización de grupos y roles aplica automáticamente el principio de mínimo privilegio y elimina errores de aprovisionamiento manual cuando el personal cambia de rol.
• Alinee las reglas de longitud y rotación de contraseñas con la guía NIST actual. NIST SP 800-63B Rev. 4 (2025) establece un mínimo de 15 caracteres para contraseñas usadas como único factor de autenticación y retira formalmente el requisito de rotación obligatoria cada 90 días (NIST SP 800-63B, 2025) [verificar URL de publicación exacta antes de imprimir]. La rotación forzada sin evidencia de compromiso empuja a los usuarios hacia contraseñas predecibles e incrementadas, que es precisamente el resultado que la guía ahora desaconseja.

Acción para el CIO: Realice una auditoría de brechas contra las cinco políticas este trimestre, y asigne un responsable para cada hallazgo en lugar de tratar la auditoría como un informe único.

Cumplimiento de los requisitos de NIS2 e ISO 27001 con gobernanza de bóvedas

Las políticas de bóvedas se mapean directamente a dos requisitos que los auditores verifican primero: control de acceso documentado y una pista de auditoría verificable. La Directiva NIS2 (UE) 2022/2555, Artículo 21(2), requiere políticas de control de acceso y autenticación multifactor como parte de las medidas de gestión de riesgos de ciberseguridad de una entidad. Los controles 5.15 y 8.15 de ISO/IEC 27001:2022 requieren la misma combinación: un modelo de acceso definido más un registro de quién lo ejerció y cuándo.

Los administradores corporativos vinculados a una política de bóveda cubren el lado del control de acceso sin una hoja de cálculo manual. Los registros de auditoría con marca de tiempo y exportables cubren el resto.

El DBIR 2026 de Verizon encontró credenciales presentes en alguna etapa del 39% de las brechas, como vector de acceso inicial en el 13% de las brechas confirmadas, y como vector principal detrás del 52% de los Ataques Básicos a Aplicaciones Web. El informe Cost of a Data Breach 2026 de IBM sitúa el costo promedio global de una brecha en $4,99 millones, un aumento del 12% respecto al año pasado y un máximo histórico.

Acción para el CIO: Solicite a su equipo de seguridad un informe actual de cobertura de control de acceso NIS2 este mes, antes de que un auditor lo solicite primero.

Qué significa esto para su implementación

La gobernanza de bóvedas es una decisión estructural, tomada de la misma manera que la segmentación de red: diseñada en torno a departamentos y niveles de riesgo antes de que un incidente fuerce un rediseño. Las organizaciones que hacen esto bien lo tratan así desde el principio. Bajo NIS2 y GDPR, esa estructura es ahora un requisito para las empresas dentro del alcance.

Comience con la auditoría, no con la herramienta. Mapee qué bóvedas existen hoy, quién las controla realmente y dónde se rompe la ruta de recuperación si una persona se va.

Preguntas frecuentes

Passwork's vault policies (also called Vault Types): a configurable governance layer that lets administrators define, for each category of vault, who its permanent administrators are, what access level vault creators get, and who is allowed to create vaults of that type. Once set, these rules apply automatically to every vault created under that type.

Most enterprises can't say with certainty who has administrator rights over a given team's shared credential vault, because admin access gets granted informally, without a policy behind it. Enterprise password vault policies fix this by binding admin rights to the vault's policy itself, not to whoever happened to create it.

This guide explains how Passwork's Vault Types architecture gives CIOs and CISOs a working model for vault governance, beyond basic password rules.

What are vault policies and why CIOs need them

Vault policies are governance rules that determine who can create a vault, who is automatically granted administrator access to it, and who cannot be removed from that access. They shift the conversation from "password complexity requirements" to vault governance: structural control over corporate credential storage, not just the credentials themselves.

Three categories of tools claim to solve this: 

• Consumer password managers handle personal or small-team credential sharing well but were not built for departmental governance at scale. 
• Privileged access management (PAM) platforms secure infrastructure-level and service accounts but add cost and complexity that most credential-sharing use cases don't need. 
• Enterprise password managers with dedicated vault policy engines sit between the two, and that's the approach this article focuses on.

CIO action item: Audit your organization for "rogue vaults" — shared folders or team vaults created without IT's knowledge, often inside a consumer tool an individual department adopted independently.

The architecture behind vault policies: how Passwork structures access control

Passwork 7.1 introduced a vault types architecture where each vault policy defines its own administrators, creator permissions, and creation rules before a single vault exists. Every new vault built under that policy automatically inherits its designated administrators, and the vault's owner cannot remove them.

Two basic vault types ship by default: User vaults, private or shared credential stores controlled entirely by their creator, and Company vaults, which always include the organization's corporate administrators. Beyond these, administrators can create unlimited custom vault types, one per department, project, or access tier, each with its own designated administrators and creation rules.

This produces three concrete outcomes for the business:

• Command over team vaults without a single super-administrator holding a master key to every password in the company.
• A recovery path that works when someone leaves or loses access, through a pre-provisioned recovery account whose master password is stored offline.
• No mandatory "one button" or master key that unlocks the entire organization's credentials at once.

Version 7.4 added restriction controls specifically for User vaults, letting administrators limit sharing and creation permissions on the personal-vault tier too, closing a gap that basic vault types alone didn't cover.

CIO action item: Map your organizational structure to vault types, one per department or project, and assign corporate administrators before teams start creating vaults on their own.

How Passwork compares to other approaches to vault access control

What matters for any credential management tool is whether the admin role is bound to a policy in advance, and whether recovering access requires a key that also opens everything else in the organization. In the table below, "No" in the single-key column is the answer you want: it means there's no built-in single point of failure.

Consumer-oriented password managers often let team admins manage a shared vault, but rarely apply that policy automatically to every new vault a department creates. 

Some tools rely on a single super admin who can reset any user's password and reach every shared folder in the company. Others tie all corporate vaults to one shared encryption key, so compromising that key exposes everything at once. 

PAM platforms solve a different problem: they vault privileged infrastructure credentials, often behind their own master or breakglass key, rather than governing team-level password sharing.

CIO action item: Score your current credential tool against these three criteria: policy-bound admin assignment, a working recovery path, and the absence of a mandatory universal key.

The 5-policy vault governance checklist every CIO should implement

Five specific configuration decisions turn a password manager deployment into functioning vault governance. Each addresses a distinct failure mode observed in real incident response engagements, not a theoretical risk.

• Disable private vault creation and sharing where it isn't required. Unrestricted private vaults are exactly how rogue vaults form outside IT's visibility. Restrict private vault creation to roles that genuinely need it.
• Assign corporate administrators to every team and departmental vault policy. This guarantees continuous oversight without depending on any single individual remembering to add themselves.
• Define an emergency access policy before you need one. Decide between a single organization-wide recovery contour or separate recovery accounts per department, and store master credentials for that recovery account offline.
• Implement RBAC (role-based access control) through Active Directory or LDAP. Syncing groups and roles automatically applies the principle of least privilege and removes manual provisioning errors when staff change roles.
• Align password length and rotation rules with current NIST guidance. NIST SP 800-63B Rev. 4 (2025) sets a 15-character minimum for passwords used as the sole authentication factor and formally retires the mandatory 90-day rotation requirement (NIST SP 800-63B, 2025) [verify exact publication URL before print]. Forced rotation without evidence of compromise pushes users toward predictable, incremented passwords, which is precisely the outcome the guidance now discourages.

CIO action item: Run a gap audit against all five policies this quarter, and assign an owner for each finding rather than treating the audit as a one-time report.

Meeting NIS2 and ISO 27001 requirements with vault governance

Vault policies map directly onto two requirements auditors check first: documented access control and a verifiable audit trail. NIS2 Directive (EU) 2022/2555, Article 21(2), requires access control policies and multi-factor authentication as part of an entity's cybersecurity risk-management measures. ISO/IEC 27001:2022 controls 5.15 and 8.15 require the same pairing: a defined access model plus a record of who exercised it and when.

Corporate administrators bound to a vault policy cover the access-control side without a manual spreadsheet. Timestamped, exportable audit logs cover the rest.

Verizon's 2026 DBIR found credentials present at some stage of 39% of breaches, as the initial access vector in 13% of confirmed breaches, and the lead vector behind 52% of Basic Web Application Attacks. IBM's 2026 Cost of a Data Breach Report puts the global average breach cost at $4.99 million, a 12% increase over last year and a record high.

CIO action item: Ask your security team for a current NIS2 access-control coverage report this month, before an auditor asks for it first.

What this means for your rollout

Vault governance is a structural decision, made the way network segmentation is: designed around departments and risk tiers before an incident forces a redesign. The organizations that get this right treat it that way from the start. Under NIS2 and GDPR, that structure is now a requirement for enterprises in scope.

Start with the audit, not the tool. Map which vaults exist today, who actually controls them, and where the recovery path breaks if one person leaves.

Frequently asked questions

Passwork 7.7: Secure offline mode for desktop and mobile apps

Passwords now work offline too. Passwork 7.7 brings secure offline access with full admin oversight, org-wide file attachment controls, and five new role-based onboarding guides for a smoother rollout.

Passwork BlogPasswork Team

Verizon DBIR 2026: 10 stats that should change your security strategy

Verizon’s 2026 DBIR analyzed 22,000+ breaches across 145 countries. Vulnerability exploitation overtook credential abuse as the top attack vector, while ransomware, third-party risk, and AI-assisted attacks all grew sharply. Here are the 10 numbers that matter.

Passwork BlogAlex Muntyan

NIS2 password requirements: What European companies must do in 2026

Credential gaps are the leading NIS2 audit failure point in 2026. This guide covers Article 21 password requirements, NIST SP 800-63B alignment, AD hardening steps, and the audit evidence regulators ask for first.

Passwork BlogAlex Muntyan

A autenticação biométrica verifica uma pessoa através de uma característica, como uma impressão digital ou um reconhecimento facial. Num fluxo de início de sessão com passkey, essa biometria, ou um PIN local, desbloqueia uma chave criptográfica armazenada no dispositivo, em vez de enviar uma palavra-passe para algum lado. NIST SP 800-63B Revision 4 trata a biometria como parte da autenticação multifator (MFA) associada a um autenticador físico, e não como autenticador remoto autónomo.

Nos cofres de palavras-passe empresariais, o benefício de segurança resulta da arquitetura de credenciais, da integridade dos endpoints e da política de autorização, e não apenas do gesto biométrico. A decisão operacional para os responsáveis de TI é saber se a organização consegue sustentar endpoints geridos, uma alternativa não biométrica testada e uma governação do cofre suficientemente sólida para ter relevância quando deixar de existir atrito no início de sessão.

O que é a autenticação biométrica

A autenticação biométrica verifica a identidade de uma pessoa através de uma característica física, como uma impressão digital, o rosto ou a íris, em vez de um segredo memorizado. Nos dispositivos modernos, a verificação é feita localmente: o sensor compara a leitura em tempo real com um template biométrico armazenado no dispositivo e, se coincidirem, desbloqueia uma chave criptográfica ou concede acesso ao sistema.

É um método de verificação, e não um sistema de controlo de acessos. Uma impressão digital ou um reconhecimento facial confirma quem está junto ao dispositivo, mas não diz nada sobre os ficheiros, sistemas ou cofres a que essa pessoa deve poder aceder; isso é uma camada separada, tratada por funções, permissões e políticas.

As implementações mais comuns incluem:

• Reconhecimento de impressões digitais, lido por um sensor capacitivo integrado num portátil, num telemóvel ou numa chave de segurança autónoma.
• Reconhecimento facial, como o Face ID ou o Windows Hello, que utiliza uma câmara e, na maioria dos dispositivos, um sensor de profundidade por infravermelhos para resistir a falsificações com fotografias.
• Leitura de íris e de retina, utilizada sobretudo em instalações de alta segurança e não no início de sessão empresarial do dia a dia.
• Reconhecimento de voz, menos comum no início de sessão em dispositivos e mais comum em verificações de identidade em centros de contacto.

Num contexto empresarial, a biometria surge quase sempre como o passo de desbloqueio local de um fluxo de autenticação mais amplo, com maior frequência uma passkey WebAuthn, e não como forma autónoma de aceder aos sistemas da empresa. NIST SP 800-63B Revision 4 formaliza esse papel: a biometria funciona como parte da autenticação multifator, associada a um autenticador físico, e não como credencial remota por si só.

O que a autenticação biométrica protege (e o que não protege)

A biometria verifica a pessoa localmente, no dispositivo ou no autenticador. Por si só, não protege nada do lado do servidor. Essa tarefa cabe à asserção criptográfica WebAuthn e às funções e à política de cofres do gestor de palavras-passe, que determinam a que recursos a pessoa verificada pode efetivamente aceder.

As palavras-passe são segredos que podem ser reproduzidos (replay) e que um colaborador escreve num campo de início de sessão, o que os torna suscetíveis a phishing e reutilizáveis entre sistemas. Um gesto biométrico local autoriza, em vez disso, a utilização de uma chave privada que permanece sob controlo de um autenticador, pelo que não há segredo partilhado a intercetar em trânsito. 

A especificação W3C WebAuthn Level 3 define aqui dois tipos de credenciais. Uma credencial de dispositivo único não pode ser exportada. Uma credencial multidispositivo elegível para cópia de segurança, habitualmente designada por passkey sincronizada, pode estar disponível nos vários dispositivos de um utilizador dentro do mesmo ecossistema de plataforma. Ambas mantêm a chave privada fora do alcance da parte confiante (relying party). Apenas a primeira se pode descrever com rigor como associada a um único dispositivo.

Vantagens da autenticação biométrica

O início de sessão biométrico elimina o passo em que um colaborador escreve um segredo que pode ser alvo de phishing, ser adivinhado ou ser reutilizado. Combinado com uma passkey, substitui uma palavra-passe reproduzível por uma chave privada que nunca sai do dispositivo, e os dados do setor mostram ganhos mensuráveis na rapidez do início de sessão e menos tickets de help desk associados a credenciais perdidas.

A vantagem é estrutural, e não cosmética. Uma palavra-passe introduzida num campo de início de sessão pode ser capturada por um site falso, por um keylogger ou por uma lista de credenciais reutilizadas. Uma passkey desbloqueada por biometria não tem nada equivalente para roubar em trânsito, porque a chave privada nunca atravessa a rede.

O ganho de velocidade está documentado. O Passkey Index da FIDO Alliance indica uma taxa de sucesso de 93 % nos inícios de sessão com passkey, contra 63 % nos restantes métodos, uma redução de 73 % no tempo de início de sessão e uma redução de até 81 % nos incidentes de help desk relacionados com o início de sessão. Trata-se de valores comunicados pela associação, a nível de todo o setor, provenientes de organizações participantes, e não de uma garantia para qualquer implementação específica.

Nada disto faz da biometria uma resposta completa por si só. O ganho surge quando a biometria autoriza uma credencial bem governada. Usada como fator autónomo isolado, troca um segredo revogável por um permanente, que é exatamente a contrapartida abordada na secção seguinte.

Riscos da autenticação biométrica

A autenticação biométrica associa o acesso a uma impressão digital, a um reconhecimento facial ou a um padrão de íris que não pode ser alterado em caso de comprometimento. Ao contrário de uma palavra-passe, não é possível rodar uma impressão digital após uma violação de dados, e as bases de dados biométricas centralizadas tornam-se alvos de grande valor para os atacantes. Estes riscos fazem da biometria um mau substituto autónomo da gestão de credenciais.

• A irrevogabilidade é o problema central. O NIST SP 800-63B classifica a biometria como um identificador, e não como um segredo, uma vez que esta não pode ser redefinida como uma palavra-passe (NIST SP 800-63B, secção 5.2.3). Quando um template é divulgado, esse fator fica comprometido para sempre.
• A centralização dos dados é um ponto único de falha. Armazenar templates biométricos numa única base de dados cria um alvo de grande valor: uma violação aí expõe os dados de impressões digitais ou faciais de todos os utilizadores inscritos de uma só vez. Uma violação de palavras-passe obriga a uma redefinição. Uma violação biométrica não tem correção equivalente. Isto é diferente da «governação central» abordada mais adiante neste artigo, que centraliza quem pode aceder a um segredo, e não o próprio template biométrico.
• Falsificação (spoofing). Fotografias e vídeos deepfake já enganaram sensores de nível de consumo em testes independentes, e a precisão varia muito consoante a qualidade do sensor e a iluminação.
• Exposição regulamentar. O artigo 9.º do RGPD trata os identificadores biométricos como dados de categoria especial, exigindo consentimento explícito e salvaguardas mais rigorosas do que as credenciais comuns.

Nada disto faz da biometria uma resposta completa por si só. O ganho surge quando a biometria autoriza uma credencial bem governada. Usada como fator autónomo isolado, troca um segredo revogável por um permanente, que é exatamente a contrapartida abordada na secção seguinte.

Biometria, passkeys e WebAuthn: A fronteira de controlo

A fronteira de controlo é a linha que separa o que uma biometria autoriza localmente do que o WebAuthn demonstra a um servidor. Uma impressão digital ou um reconhecimento facial desbloqueia uma chave associada ao dispositivo; a asserção criptográfica que essa chave produz, limitada a um Relying Party ID (identificador da parte confiante), é o que o servidor verifica efetivamente.

A autenticação por impressão digital e por reconhecimento facial funcionam ambas no início de sessão dos colaboradores em dispositivos geridos compatíveis, mas a escolha certa depende da qualidade do sensor, da maturidade da gestão de dispositivos, das necessidades de acessibilidade e do nível de risco aceitável. Nenhum dos métodos é uma resposta universal. Ambos têm compromissos diferentes em termos de rapidez, fiabilidade e sobrecarga de governação.

Verificação local versus correspondência biométrica central

A verificação local compara uma biometria com um template armazenado no próprio dispositivo. A verificação central compara-a com uma base de dados de referência mantida noutro local. O NIST recomenda a verificação local porque elimina, ou reduz drasticamente, a necessidade de um repositório biométrico mantido centralmente, que se torna um ponto único de falha em caso de violação.

A distinção é mais fácil de perceber através de dois exemplos conhecidos:

• Verificação local: o Windows Hello ou o Touch ID compara uma impressão digital com um template armazenado num enclave de hardware seguro do dispositivo. O template nunca sai do chip.
• Verificação central: as portas automáticas de controlo de fronteira dos aeroportos comparam o rosto de um viajante com uma base de dados de passaportes mantida num servidor, e não na própria porta.

As organizações devem confirmar o modelo de tratamento de templates de cada plataforma de dispositivos e de cada integração de produto, em vez de presumir que é idêntico em todo o lado. A verificação local e a governação centralizada de segredos não estão em tensão. O objetivo é manter os templates biométricos locais e, ao mesmo tempo, centralizar o controlo sobre quem pode aceder a uma determinada credencial, duas coisas diferentes a serem centralizadas (ou não) por duas razões diferentes.

O NIST SP 800-63B Revision 4 define três referências específicas para as implementações aplicáveis:

• Taxa de falsa correspondência (FMR): a probabilidade de a pessoa errada ser aceite. O NIST exige 1 em 10 000 ou melhor.
• Taxa de falsa não correspondência (FNMR): a probabilidade de o utilizador legítimo ser rejeitado. O NIST recomenda um valor inferior a 5 %.
• Deteção de ataques de apresentação (PAD): obrigatória para o reconhecimento facial, recomendada para as modalidades de impressão digital e de íris.

Estes valores devem ser tratados como referências de aquisição para a avaliação de fornecedores, e não como desempenho garantido em condições reais. A precisão efetiva dos sensores varia consoante o fabricante.

Impressão digital versus reconhecimento facial em dispositivos geridos

A impressão digital e o reconhecimento facial falham de forma diferente, e ambos precisam de uma alternativa testada, em vez do pressuposto de que o sensor funcionará sempre.

Uma implementação de reconhecimento facial que não inclua a PAD no seu âmbito é incompleta segundo as orientações do NIST. Investigação independente demonstrou que os sensores faciais podem ser contornados com uma imagem modificada em vez de um rosto real, que é exatamente o ataque que a PAD se destina a detetar.

O que conta realmente como fator na autenticação biométrica multifator

Segundo as orientações do NIST, uma biometria nunca funciona como fator autónomo. A autenticação biométrica multifator combina uma verificação local de «algo que o utilizador é» com um autenticador físico e criptográfico que representa «algo que o utilizador tem». A biometria ativa esse autenticador. Não serve, por si só, como prova de identidade, e inscrever uma impressão digital e um rosto no mesmo dispositivo não cria dois fatores, apenas duas formas de desbloquear o mesmo.

Por detrás destes pedidos existem dois tipos de autenticadores, que sobrevivem de forma diferente à perda do dispositivo. Um autenticador de plataforma está integrado no dispositivo do colaborador e perde-se com ele. Uma chave de segurança de hardware circula entre dispositivos e acrescenta um fator de posse física que sobrevive à perda ou ao apagamento de um portátil.

As credenciais WebAuthn acrescentam uma segunda camada de proteção para além do próprio fator: cada credencial está limitada a um Relying Party ID, o identificador do site ou serviço específico para o qual foi registada. Uma credencial registada para uma parte confiante não pode ser utilizada num domínio semelhante e não relacionado. É essa limitação, e não a biometria, que confere ao WebAuthn a sua resistência ao phishing.

Nada disto substitui controlos de política separados. As definições de MFA, a postura de confiança do dispositivo, o tempo limite de sessão e o acesso condicional para ações de risco elevado continuam a assentar sobre o próprio método de início de sessão.

Os cinco controlos para a implementação empresarial

A comodidade biométrica fica no dispositivo do colaborador. A governação de segredos fica com os controlos de identidade e de cofre de palavras-passe geridos centralmente. A separação das duas elimina a necessidade de criar uma base de dados biométrica pertencente à empresa, mantendo o controlo organizacional total sobre quem acede a que segredos.

Os três fatores que abriram este artigo, endpoints geridos, uma alternativa funcional e governação do cofre, desdobram-se em cinco controlos específicos quando se pretende pô-los em prática. Este é o modelo de desbloqueio biométrico local e governação central de segredos, uma abordagem prática e não uma norma formal.

Endpoints geridos e verificação do utilizador

• Endpoint gerido e autenticador compatível. Defina os dispositivos, as versões do SO e os sensores elegíveis antes de qualquer inscrição.
• Verificação local do utilizador. Uma biometria ou um PIN desbloqueia o autenticador. Um método alternativo não biométrico permanece disponível para quem precisar dele.

Política de identidade e governação central de segredos

• Política de identidade e de step-up. Início de sessão único (SSO), MFA, duração da sessão e verificação adicional para ações administrativas de risco elevado.
• Governação central de segredos. Funções, princípio do menor privilégio, segmentação de cofres, revisão da atividade e partilha segura regem as credenciais empresariais propriamente ditas.

Recuperação e revogação

• Recuperação e revogação. Um processo documentado abrange a resposta à perda de dispositivos, a redefinição ou remoção de passkeys, o acesso break-glass e a revisão de auditoria.

Os dados biométricos que permitem identificar uma pessoa de forma inequívoca são classificados como dados de categoria especial ao abrigo do RGPD do Reino Unido, segundo as orientações do ICO sobre reconhecimento biométrico. O consentimento, por si só, não é o fator decisivo: a legislação aplicável pode exigir um fundamento jurídico, uma condição para categorias especiais, transparência e minimização de dados, e os pormenores variam consoante a jurisdição. Essa avaliação cabe às equipas jurídica e de privacidade da organização. Este modelo não a resolve; reduz a quantidade de dados biométricos que precisam de existir de forma centralizada.

Utilizar as passkeys do Passwork com a governação de cofres

Passwork permite o início de sessão com passkey, baseado na norma WebAuthn, para que os utilizadores se autentiquem com uma chave associada ao dispositivo em vez de uma palavra-passe. Os autenticadores de plataforma compatíveis incluem o Face ID, o Touch ID, o Windows Hello e chaves de segurança de hardware compatíveis. Um administrador ativa a funcionalidade para funções específicas e, a partir daí, cada membro dessa função pode optar por registar uma passkey.

Fluxo de início de sessão com passkey em 4 passos

A adoção de passkeys no Passwork segue uma sequência fixa que mantém as alterações de autenticação dentro do modelo de funções e de auditoria existente, em vez de correr em paralelo como um sistema separado.

1. Ativar a definição da função. Um administrador decide que funções podem utilizar a opção de início de sessão «Use passkey instead of password» (utilizar passkey em vez de palavra-passe).
2. Registar a passkey. Um colaborador regista uma passkey de plataforma ou uma chave de segurança WebAuthn na página «Authentication» (Autenticação) da respetiva conta.
3. Iniciar sessão com verificação local. O colaborador aprova um pedido de biometria ou de PIN local do dispositivo. A passkey prova a posse da chave sem nunca transmitir a palavra-passe local ou de domínio.
4. Tratar a saída de colaboradores ou a perda. Se um dispositivo for perdido ou substituído, ou se um colaborador sair da empresa, o administrador remove ou redefine a passkey e segue o procedimento de recuperação e de revisão de acessos da organização.

Métricas do piloto e lista de verificação da implementação

A implementação biométrica está pronta para avançar além de um grupo-piloto quando cada um dos cinco controlos acima tem um responsável, provas de prontidão e uma resposta definida em caso de falha. Esta lista de verificação de prontidão do piloto transforma o modelo num ponto de decisão go/no-go, em vez de uma implementação que escala com base em pressupostos.

Acompanhe a taxa de conclusão da inscrição, a taxa de sucesso da autenticação, a frequência de falsas rejeições e de recurso ao método alternativo, o volume do help desk, o tempo para remover um dispositivo perdido e o tempo para revogar o acesso após a saída de colaboradores. Compare os valores obtidos com as referências da FIDO Alliance citadas anteriormente: uma taxa de conclusão ou de sucesso muito inferior a 93 %, ou uma taxa de recurso ao método alternativo muito superior à que o grupo-piloto previa, merece investigação antes de escalar para além da primeira equipa.

Conclusão

A autenticação biométrica e a governação do gestor de palavras-passe resolvem problemas diferentes. Confundi-las é onde a maioria das implementações falha. A biometria desbloqueia o dispositivo; a governação do cofre decide quem acede a que segredos. Se estas tarefas se mantiverem separadas, o resultado é um início de sessão mais rápido, sem uma base de dados biométrica que ninguém pretendia criar nem um ponto fraco único a fazer as vezes de um verdadeiro controlo de acessos.

Escolher uma equipa que já trate credenciais partilhadas de administração, SaaS ou infraestrutura e testar a separação num piloto antes de ela se tornar prática generalizada na empresa.

Perguntas frequentes

2026 IBM Cost of a Data Breach Report: A ameaça da IA de 6 milhões de dólares que ninguém está a resolver

Em 2026, os custos globais das violações de dados atingiram o recorde de 4,99 milhões de dólares, com 247 dias para a deteção. Os ataques baseados em IA aumentam 56 %, mas a crise real é outra: os defensores aplicam IA em todo o lado, exceto onde os atacantes entram. 92 % das organizações afetadas por violações de dados com IA não tinham qualquer controlo de acesso adequado.

Passwork BlogAlex Muntyan

Shadow AI: A ameaça oculta que custa às empresas 670 mil dólares por violação de dados

A shadow AI custa às empresas mais 670 mil dólares por violação de dados, e a maior parte tem origem em credenciais coladas em LLMs públicos. Saiba como é, na prática, a shadow AI, por que razão é mais difícil de travar do que a shadow IT e como a governar.

Passwork BlogAlex Muntyan

11 riscos da reutilização de palavras-passe e como evitá-los

Reutilizar uma palavra-passe parece inofensivo, mas não é. Eis por que razão uma única credencial divulgada pode comprometer toda a segurança de uma organização, e como evitar que isso aconteça.

Passwork BlogAlex Muntyan

Biometrische Authentifizierung verifiziert eine Person anhand eines Merkmals wie eines Fingerabdrucks oder Gesichtsscans. Bei einer Passkey-Anmeldung entsperrt diese biometrische Eigenschaft oder eine lokale PIN einen auf dem Gerät gespeicherten kryptografischen Schlüssel, anstatt ein Passwort irgendwohin zu senden. NIST SP 800-63B Revision 4 behandelt Biometrie als Teil der Multi-Faktor-Authentifizierung in Verbindung mit einem physischen Authenticator, nicht als eigenständigen Remote-Authenticator.

Für unternehmensweite Passwort-Tresore ergibt sich der Sicherheitsvorteil aus der Credential-Architektur, der Endpunkt-Integrität und der Autorisierungsrichtlinie — nicht allein aus der biometrischen Geste. Die operative Entscheidung für IT-Verantwortliche lautet, ob die Organisation verwaltete Endpunkte, einen getesteten nicht-biometrischen Fallback und eine ausreichend solide Tresor-Governance unterstützen kann, sobald die Anmeldereibung entfällt.

Was ist biometrische Authentifizierung

Biometrische Authentifizierung verifiziert die Identität einer Person anhand eines physischen Merkmals wie eines Fingerabdrucks, Gesichts oder Irismusters — anstelle eines auswendig gelernten Geheimnisses. Auf modernen Geräten erfolgt die Prüfung lokal: Der Sensor vergleicht den Live-Scan mit einer auf dem Gerät gespeicherten Vorlage und entsperrt bei Übereinstimmung einen kryptografischen Schlüssel oder gewährt Zugang zum System.

Es handelt sich um eine Verifizierungsmethode, nicht um ein Zugriffskontrollsystem. Ein Fingerabdruck- oder Gesichtsscan bestätigt, wer am Gerät sitzt. Er sagt nichts darüber aus, auf welche Dateien, Systeme oder Tresore diese Person zugreifen darf — das ist eine separate Ebene, die durch Rollen, Berechtigungen und Richtlinien gesteuert wird.

Gängige Implementierungen umfassen:

• Fingerabdruckerkennung, ausgelesen durch einen kapazitiven Sensor, der in einen Laptop, ein Telefon oder einen eigenständigen Schlüsselanhänger eingebaut ist.
• Gesichtserkennung, wie Face ID oder Windows Hello, unter Verwendung einer Kamera und auf den meisten Geräten eines Infrarot-Tiefensensors zur Abwehr von Foto-Spoofing.
• Iris- und Retina-Scanning, hauptsächlich in Hochsicherheitseinrichtungen eingesetzt und nicht für die alltägliche Unternehmensanmeldung.
• Spracherkennung, weniger verbreitet für die Geräteanmeldung, häufiger bei Identitätsprüfungen im Call-Center.

Im Unternehmenskontext erscheint Biometrie fast immer als lokaler Entsperrschritt in einem größeren Authentifizierungsablauf — am häufigsten bei einem WebAuthn-Passkey — und nicht als eigenständiger Weg zu Unternehmenssystemen. NIST SP 800-63B Revision 4 formalisiert diese Rolle: Biometrie funktioniert als Teil der Multi-Faktor-Authentifizierung in Verbindung mit einem physischen Authenticator, nicht als eigenständiges Remote-Credential.

Was biometrische Authentifizierung absichert (und was nicht)

Biometrie verifiziert die Person lokal, auf dem Gerät oder Authenticator. Sie sichert allein nichts auf Serverseite ab. Diese Aufgabe übernimmt die kryptografische WebAuthn-Assertion zusammen mit den Rollen- und Tresor-Richtlinien des Passwort-Managers, die festlegen, worauf die verifizierte Person tatsächlich zugreifen kann.

Passwörter sind wiederholbare Geheimnisse, die ein Mitarbeiter in ein Anmeldefeld eingibt — was sie phishbar und systemübergreifend wiederverwendbar macht. Eine lokale biometrische Geste autorisiert stattdessen die Nutzung eines privaten Schlüssels, der unter der Kontrolle eines Authenticators bleibt — es gibt also kein gemeinsames Geheimnis, das während der Übertragung abgefangen werden könnte.

Die W3C WebAuthn Level 3-Spezifikation definiert hier zwei Credential-Typen. Ein Einzelgerät-Credential kann nicht exportiert werden. Ein backup-fähiges Multigerät-Credential, allgemein als synchronisierter Passkey bezeichnet, kann auf den Geräten eines Benutzers innerhalb desselben Plattform-Ökosystems verfügbar sein. Beide halten den privaten Schlüssel aus den Händen der vertrauenden Partei. Nur das erste kann zutreffend als an ein Gerät gebunden beschrieben werden.

Vorteile der biometrischen Authentifizierung

Die biometrische Anmeldung eliminiert den Schritt, bei dem ein Mitarbeiter ein Geheimnis eingibt, das gephisht, erraten oder wiederverwendet werden kann. In Kombination mit einem Passkey ersetzt sie ein wiederholbares Passwort durch einen privaten Schlüssel, der das Gerät niemals verlässt — und Branchendaten zeigen messbare Gewinne bei der Anmeldegeschwindigkeit sowie weniger Help-Desk-Tickets im Zusammenhang mit verlorenen Anmeldedaten.

Der Vorteil ist struktureller Natur, nicht kosmetisch. Ein Passwort in einem Anmeldefeld kann von einer gefälschten Website, einem Keylogger oder einer Liste wiederverwendeter Anmeldedaten erfasst werden. Ein biometrisch entsperrter Passkey bietet nichts Vergleichbares, das während der Übertragung gestohlen werden könnte, da der private Schlüssel niemals das Netzwerk überquert.

Der Geschwindigkeitsgewinn ist dokumentiert. Der Passkey Index der FIDO Alliance berichtet von einer Erfolgsquote von 93 % bei Passkey-Anmeldungen gegenüber 63 % bei anderen Methoden, einem Rückgang der Anmeldezeit um 73 % und einer Reduzierung anmeldebezogener Help-Desk-Vorfälle um bis zu 81 %. Dies sind branchenweit gemeldete Zahlen von teilnehmenden Organisationen, keine Garantie für eine bestimmte Bereitstellung.

Nichts davon macht Biometrie allein zu einer vollständigen Lösung. Der Gewinn zeigt sich, wenn eine biometrische Eigenschaft ein gut verwaltetes Credential autorisiert. Als bloßer eigenständiger Faktor verwendet, tauscht sie ein widerrufbares Geheimnis gegen ein permanentes — genau der Kompromiss, den der nächste Abschnitt behandelt.

Risiken der biometrischen Authentifizierung

Biometrische Authentifizierung bindet den Zugang an einen Fingerabdruck, Gesichtsscan oder ein Irismuster, das bei Kompromittierung nicht geändert werden kann. Anders als bei einem Passwort kann ein Fingerabdruck nach einer Datenschutzverletzung nicht rotiert werden, und zentralisierte biometrische Datenbanken werden zu hochwertigen Zielen für Angreifer. Diese Risiken machen Biometrie zu einem schlechten eigenständigen Ersatz für das Credential-Management.

• Unwiderruflichkeit ist das Kernproblem. NIST SP 800-63B klassifiziert Biometrie als Identifikator, nicht als Geheimnis, da sie nicht wie ein Passwort zurückgesetzt werden kann (NIST SP 800-63B, Abschnitt 5.2.3). Sobald eine Vorlage durchsickert, ist dieser Faktor dauerhaft kompromittiert.
• Zentralisierte Daten sind ein Single Point of Failure. Die Speicherung biometrischer Vorlagen in einer Datenbank schafft ein hochwertiges Ziel: Eine Verletzung dort legt Fingerabdruck- oder Gesichtsdaten für jeden registrierten Benutzer auf einmal offen. Eine Passwortverletzung erzwingt ein Zurücksetzen. Eine biometrische Verletzung hat keine gleichwertige Lösung. Dies unterscheidet sich von der später in diesem Artikel diskutierten „zentralen Governance", die zentralisiert, wer auf ein Geheimnis zugreifen kann — nicht die biometrische Vorlage selbst.
• Spoofing. Fotos und Deepfake-Videos haben in unabhängigen Tests Consumer-Grade-Sensoren überwunden, und die Genauigkeit variiert stark je nach Sensorqualität und Beleuchtung.
• Regulatorische Exposition. DSGVO Artikel 9 behandelt biometrische Identifikatoren als besondere Kategorie von Daten und erfordert ausdrückliche Einwilligung sowie strengere Schutzmaßnahmen als bei Standardanmeldedaten.

Nichts davon macht Biometrie allein zu einer vollständigen Lösung. Der Gewinn zeigt sich, wenn eine biometrische Eigenschaft ein gut verwaltetes Credential autorisiert. Als bloßer eigenständiger Faktor verwendet, tauscht sie ein widerrufbares Geheimnis gegen ein permanentes — genau der Kompromiss, den der nächste Abschnitt behandelt.

Biometrie, Passkeys und WebAuthn: Die Kontrollgrenze

Die Kontrollgrenze ist die Linie zwischen dem, was eine biometrische Eigenschaft lokal autorisiert, und dem, was WebAuthn gegenüber einem Server beweist. Ein Fingerabdruck oder Gesichtsscan entsperrt einen gerätegebundenen Schlüssel; die kryptografische Assertion, die dieser Schlüssel erzeugt und die an eine Relying Party ID gebunden ist, ist das, was der Server tatsächlich prüft.

Fingerabdruck- und Gesichtsauthentifizierung funktionieren beide für die Mitarbeiteranmeldung auf unterstützten verwalteten Geräten, aber die richtige Wahl hängt von der Sensorqualität, der Reife des Gerätemanagements, den Barrierefreiheitsanforderungen und dem akzeptablen Risikoniveau ab. Keine der Methoden ist eine universelle Lösung. Beide schneiden bei Geschwindigkeit, Zuverlässigkeit und Governance-Aufwand unterschiedlich ab.

Lokale Verifizierung versus zentrale biometrische Abgleichung

Lokale Verifizierung prüft eine biometrische Eigenschaft gegen eine auf dem Gerät selbst gespeicherte Vorlage. Zentrale Verifizierung prüft sie gegen eine anderswo gehaltene Referenzdatenbank. NIST empfiehlt lokale Verifizierung, da sie die Notwendigkeit eines zentral gehaltenen biometrischen Speichers eliminiert oder stark reduziert, der bei einer Verletzung zu einem Single Point of Failure wird.

Der Unterschied lässt sich am einfachsten anhand zweier vertrauter Beispiele erkennen:

• Lokale Verifizierung: Windows Hello oder Touch ID prüft einen Fingerabdruck gegen eine Vorlage, die in einer sicheren Hardware-Enklave auf dem Gerät gespeichert ist. Die Vorlage verlässt niemals den Chip.
• Zentrale Verifizierung: Grenzkontrollschleusen am Flughafen gleichen das Gesicht eines Reisenden mit einer auf einem Server gehaltenen Passdatenbank ab, nicht auf der Schleuse selbst.

Organisationen sollten das Vorlagen-Handhabungsmodell für jede Geräteplattform und Produktintegration bestätigen, anstatt anzunehmen, dass es überall identisch ist. Lokale Verifizierung und zentralisierte Geheimnis-Governance stehen nicht im Widerspruch. Das Ziel ist, biometrische Vorlagen lokal zu halten und gleichzeitig die Kontrolle darüber zu zentralisieren, wer auf ein bestimmtes Credential zugreifen kann — zwei verschiedene Dinge werden aus zwei verschiedenen Gründen zentralisiert (oder nicht).

NIST SP 800-63B Revision 4 legt drei spezifische Benchmarks für anwendbare Bereitstellungen fest:

• False Match Rate (FMR): Die Wahrscheinlichkeit, dass die falsche Person akzeptiert wird. NIST fordert 1 zu 10.000 oder besser.
• False Non-Match Rate (FNMR): Die Wahrscheinlichkeit, dass der legitime Benutzer abgelehnt wird. NIST empfiehlt unter 5 %.
• Presentation Attack Detection (PAD): Erforderlich für Gesichtserkennung, empfohlen für Fingerabdruck- und Iris-Modalitäten.

Behandeln Sie diese Zahlen als Beschaffungs-Benchmarks für die Anbieterprüfung, nicht als garantierte reale Leistung. Die tatsächliche Sensorgenauigkeit variiert je nach Hersteller.

Fingerabdruck versus Gesichtserkennung auf verwalteten Geräten

Fingerabdruck- und Gesichtserkennung scheitern unterschiedlich, und beide benötigen einen getesteten Fallback anstelle der Standardannahme, dass der Sensor immer funktioniert.

Eine Gesichtserkennungs-Einführung ohne PAD im Umfang ist nach NIST-Richtlinien unvollständig. Unabhängige Forschung hat gezeigt, dass Gesichtssensoren mit einem modifizierten Bild statt einem Live-Gesicht umgangen werden können — genau der Angriff, den PAD erkennen soll.

Was tatsächlich als Faktor bei der Multi-Faktor-biometrischen Authentifizierung zählt

Eine biometrische Eigenschaft funktioniert nach NIST-Richtlinien niemals als eigenständiger Faktor. Multi-Faktor-biometrische Authentifizierung kombiniert eine lokale „Etwas, das Sie sind"-Prüfung mit einem physischen, kryptografischen Authenticator, der „Etwas, das Sie haben" repräsentiert. Die biometrische Eigenschaft aktiviert diesen Authenticator. Sie dient nicht allein als Identitätsnachweis, und die Registrierung eines Fingerabdrucks und eines Gesichts auf demselben Gerät erzeugt keine zwei Faktoren, sondern nur zwei Möglichkeiten, denselben zu entsperren.

Zwei Authenticator-Typen stecken hinter diesen Aufforderungen, und sie überleben einen Geräteverlust unterschiedlich. Ein Plattform-Authenticator ist in das Gerät des Mitarbeiters eingebaut und geht mit diesem verloren. Ein Hardware-Sicherheitsschlüssel wandert zwischen Geräten und fügt einen physischen Besitzfaktor hinzu, der einen verlorenen oder gelöschten Laptop überlebt.

WebAuthn-Credentials fügen eine zweite Schutzebene über dem Faktor selbst hinzu: Jedes Credential ist an eine Relying Party ID gebunden — die Kennung der spezifischen Website oder des Dienstes, bei dem es registriert ist. Ein für eine vertrauende Partei registriertes Credential kann nicht auf einer nicht verwandten, ähnlich aussehenden Domain verwendet werden. Diese Bindung, nicht die biometrische Eigenschaft, verleiht WebAuthn seine Phishing-Resistenz.

Nichts davon ersetzt separate Richtlinienkontrollen. MFA-Einstellungen, Gerätevertrauenshaltung, Sitzungs-Timeout und bedingter Zugriff für risikoreiche Aktionen sitzen weiterhin auf der Anmeldemethode selbst.

Die fünf Kontrollen für die Unternehmenseinführung

Biometrischer Komfort bleibt auf dem Gerät des Mitarbeiters. Geheimnis-Governance bleibt bei zentral verwalteten Identitäts- und Passwort-Tresor-Kontrollen. Die Trennung der beiden eliminiert die Notwendigkeit, eine unternehmenseigene biometrische Datenbank aufzubauen, während die volle organisatorische Kontrolle darüber erhalten bleibt, wer auf welches Geheimnis zugreifen kann.

Die drei Faktoren, die diesen Artikel eröffnet haben — verwaltete Endpunkte, ein funktionierender Fallback und Tresor-Governance — gliedern sich in fünf spezifische Kontrollen auf, sobald Sie bereit sind, sie zu operationalisieren. Dies ist das Modell Lokale biometrische Entsperrung / Zentrale Geheimnis-Governance, ein praktisches Framework anstelle eines formalen Standards.

Verwaltete Endpunkte und Benutzerverifizierung

• Verwalteter Endpunkt und unterstützter Authenticator. Definieren Sie, welche Geräte, Betriebssystemversionen und Sensoren berechtigt sind, bevor jemand sich registriert.
• Lokale Benutzerverifizierung. Eine biometrische Eigenschaft oder PIN entsperrt den Authenticator. Eine alternative nicht-biometrische Methode bleibt für jeden verfügbar, der sie benötigt.

Identitätsrichtlinie und zentrale Geheimnis-Governance

• Identitäts- und Step-up-Richtlinie. SSO, MFA, Sitzungsdauer und zusätzliche Verifizierung für risikoreiche administrative Aktionen.
• Zentrale Geheimnis-Governance. Rollen, Least Privilege, Tresor-Segmentierung, Aktivitätsprüfung und sicheres Teilen regeln die tatsächlichen Unternehmens-Credentials.

Wiederherstellung und Widerruf

• Wiederherstellung und Widerruf. Ein dokumentierter Prozess deckt die Reaktion auf Geräteverlust, Passkey-Zurücksetzung oder -Entfernung, Break-Glass-Zugang und Audit-Überprüfung ab.

Biometrische Daten, die eine Person eindeutig identifizieren können, werden laut der Anleitung des ICO zur biometrischen Erkennung nach der britischen DSGVO als besondere Kategorie von Daten klassifiziert. Einwilligung allein ist nicht der entscheidende Faktor: Anwendbares Recht kann eine Rechtsgrundlage, eine Bedingung für besondere Kategorien, Transparenz und Datenminimierung zusätzlich erfordern, und die Einzelheiten variieren je nach Rechtsordnung. Diese Bewertung gehört zu den Rechts- und Datenschutzteams der Organisation. Dieses Modell löst sie nicht; es reduziert, wie viele biometrische Daten überhaupt zentral existieren müssen.

Verwendung von Passwork-Passkeys mit Tresor-Governance

Passwork unterstützt Passkey-Anmeldung auf Basis des WebAuthn-Standards und ermöglicht Benutzern die Authentifizierung mit einem gerätegebundenen Schlüssel anstelle eines Passworts. Unterstützte Plattform-Authenticatoren umfassen Face ID, Touch ID, Windows Hello und kompatible Hardware-Sicherheitsschlüssel. Ein Administrator aktiviert diese Funktion für bestimmte Rollen, und jedes Mitglied dieser Rolle kann dann einen Passkey registrieren.

Der 4-Schritte-Passkey-Anmelde-Workflow

Die Passkey-Einführung in Passwork folgt einer festen Sequenz, die Authentifizierungsänderungen innerhalb des bestehenden Rollen- und Audit-Modells hält, anstatt als separates System daneben zu laufen.

1. Rolleneinstellung aktivieren. Ein Administrator entscheidet, welche Rollen die Anmeldeoption „Passkey anstelle von Passwort verwenden" nutzen dürfen.
2. Passkey registrieren. Ein Mitarbeiter registriert einen Plattform-Passkey oder einen WebAuthn-Sicherheitsschlüssel auf der Authentifizierungsseite seines Kontos.
3. Mit lokaler Verifizierung anmelden. Der Mitarbeiter bestätigt eine gerätelokale biometrische oder PIN-Aufforderung. Der Passkey beweist den Schlüsselbesitz, ohne jemals das lokale oder Domain-Passwort zu übertragen.
4. Offboarding oder Verlust handhaben. Wenn ein Gerät verloren geht, ersetzt wird oder ein Mitarbeiter das Unternehmen verlässt, entfernt oder setzt der Administrator den Passkey zurück und folgt dem Wiederherstellungs- und Zugriffsprüfungsverfahren der Organisation.

Pilot-Metriken und Rollout-Checkliste

Eine biometrische Einführung ist bereit, über eine Pilotgruppe hinaus zu expandieren, sobald jede der fünf oben genannten Kontrollen einen Verantwortlichen, einen Bereitschaftsnachweis und eine definierte Fehlerreaktion hat. Diese Pilot-Bereitschafts-Checkliste verwandelt das Modell in eine Go/No-Go-Entscheidung anstelle einer Einführung, die auf Annahmen skaliert.

Verfolgen Sie die Registrierungsabschlussrate, Authentifizierungserfolgsrate, Falsch-Ablehnungs- und Fallback-Häufigkeit, Help-Desk-Volumen, Zeit zum Entfernen eines verlorenen Geräts und Zeit zum Widerrufen des Zugangs nach dem Offboarding. Vergleichen Sie Ihre Zahlen mit den zuvor zitierten FIDO Alliance-Benchmarks: Eine Abschluss- oder Erfolgsrate weit unter 93 % oder eine Fallback-Rate weit über dem, was Ihre Pilotgruppe vorhergesagt hat, ist es wert, untersucht zu werden, bevor Sie über das erste Team hinaus skalieren.

Fazit

Biometrische Authentifizierung und Passwort-Manager-Governance lösen unterschiedliche Probleme. Die Vermischung ist der Punkt, an dem die meisten Einführungen scheitern. Biometrie entsperrt das Gerät; Tresor-Governance entscheidet, wer auf welches Geheimnis zugreift. Halten Sie diese Aufgaben getrennt, und der Gewinn ist schnellere Anmeldung ohne eine biometrische Datenbank, die niemand aufbauen wollte, oder einen einzelnen Schwachpunkt, der echte Zugriffskontrolle ersetzt.

Wählen Sie ein Team, das bereits gemeinsame Admin-, SaaS- oder Infrastruktur-Credentials verwaltet, und pilotieren Sie die Trennung, bevor sie zur unternehmensweiten Praxis wird.

Häufig gestellte Fragen

IBM Cost of a Data Breach Report 2026: Die 6-Millionen-Dollar-KI-Bedrohung, die niemand behebt

Globale Kosten für Datenschutzverletzungen erreichen 2026 mit 4,99 Mio. $ einen Rekord, wobei die Erkennung 247 Tage dauert. KI-gesteuerte Angriffe steigen um 56 %, aber die eigentliche Krise: Verteidiger setzen KI überall ein, nur nicht dort, wo Angreifer einbrechen. 92 % der von KI-Verletzungen betroffenen Organisationen hatten keine angemessenen Zugriffskontrollen.

Passwork BlogAlex Muntyan

Shadow AI: Die versteckte Bedrohung, die Unternehmen 670.000 $ pro Datenschutzverletzung kostet

Shadow AI kostet Unternehmen 670.000 $ extra pro Datenschutzverletzung — und das meiste davon lässt sich auf Anmeldedaten zurückführen, die in öffentliche LLMs eingefügt wurden. Erfahren Sie, wie Shadow AI tatsächlich aussieht, warum es schwerer zu stoppen ist als Schatten-IT, und wie es verwaltet werden kann.

Passwork BlogAlex Muntyan

11 Risiken der Passwortwiederverwendung und wie man sie vermeidet

Die Wiederverwendung eines Passworts fühlt sich harmlos an. Ist es aber nicht. Hier erfahren Sie, warum ein geleaktes Credential die gesamte Sicherheit Ihrer Organisation gefährden kann — und wie Sie das verhindern können.

Passwork BlogAlex Muntyan

La autenticación biométrica verifica a una persona mediante una característica como una huella dactilar o un escaneo facial. En un flujo de inicio de sesión con passkey, ese dato biométrico, o un PIN local, desbloquea una clave criptográfica almacenada en el dispositivo en lugar de enviar una contraseña a ningún lugar. NIST SP 800-63B Revisión 4 trata los datos biométricos como parte de la autenticación multifactor combinada con un autenticador físico, no como un autenticador remoto independiente.

Para las bóvedas de contraseñas empresariales, el beneficio de seguridad proviene de la arquitectura de credenciales, la integridad del endpoint y la política de autorización, no solo del gesto biométrico. La decisión operativa para los líderes de TI es si la organización puede soportar endpoints gestionados, un respaldo alternativo no biométrico probado y una gobernanza de bóvedas lo suficientemente sólida como para importar una vez que desaparezca la fricción del inicio de sesión.

Qué es la autenticación biométrica

La autenticación biométrica verifica la identidad de una persona utilizando un rasgo físico, como una huella dactilar, rostro o patrón de iris, en lugar de un secreto memorizado. En los dispositivos modernos, la verificación ocurre localmente: el sensor compara el escaneo en vivo con una plantilla almacenada en el dispositivo y, si coincide, desbloquea una clave criptográfica u otorga acceso al sistema.

Es un método de verificación, no un sistema de control de acceso. Una huella dactilar o escaneo facial confirma quién está frente al dispositivo. No dice nada sobre qué archivos, sistemas o bóvedas debería poder alcanzar esa persona — eso es una capa separada, gestionada por roles, permisos y políticas.

Las implementaciones comunes incluyen:

• Reconocimiento de huellas dactilares, leído por un sensor capacitivo integrado en una laptop, teléfono o llavero de seguridad independiente.
• Reconocimiento facial, como Face ID o Windows Hello, utilizando una cámara y, en la mayoría de los dispositivos, un sensor de profundidad infrarrojo para resistir la suplantación con fotos.
• Escaneo de iris y retina, utilizado principalmente en instalaciones de alta seguridad en lugar del inicio de sesión corporativo cotidiano.
• Reconocimiento de voz, menos común para el inicio de sesión en dispositivos, más común en verificaciones de identidad en centros de llamadas.

En un contexto empresarial, los datos biométricos casi siempre aparecen como el paso de desbloqueo local en un flujo de autenticación más amplio, más comúnmente una passkey WebAuthn, en lugar de una forma independiente de acceder a los sistemas corporativos. NIST SP 800-63B Revisión 4 formaliza ese rol: los datos biométricos funcionan como parte de la autenticación multifactor, combinados con un autenticador físico, no como una credencial remota por sí solos.

Qué asegura (y qué no asegura) la autenticación biométrica

Los datos biométricos verifican a la persona localmente, en el dispositivo o autenticador. Por sí solos, no aseguran nada del lado del servidor. Ese trabajo pertenece a la aserción criptográfica WebAuthn y a la política de roles y bóvedas del gestor de contraseñas, que deciden a qué puede acceder realmente la persona verificada.

Las contraseñas son secretos reproducibles que un empleado escribe en un campo de inicio de sesión, lo que las hace susceptibles a phishing y reutilizables entre sistemas. Un gesto biométrico local, en cambio, autoriza el uso de una clave privada que permanece bajo el control de un autenticador, por lo que no hay ningún secreto compartido que interceptar en tránsito.

La especificación W3C WebAuthn Nivel 3 define dos tipos de credenciales aquí. Una credencial de dispositivo único no puede exportarse. Una credencial multidispositivo elegible para respaldo, comúnmente llamada passkey sincronizada, puede estar disponible en los dispositivos de un usuario dentro del mismo ecosistema de plataforma. Ambas mantienen la clave privada fuera de las manos de la parte que confía. Solo la primera se describe con precisión como vinculada a un dispositivo.

Ventajas de la autenticación biométrica

El inicio de sesión biométrico elimina el paso donde un empleado escribe un secreto que puede ser objeto de phishing, adivinado o reutilizado. Combinado con una passkey, reemplaza una contraseña reproducible con una clave privada que nunca sale del dispositivo, y los datos de la industria muestran ganancias medibles en la velocidad de inicio de sesión y menos tickets de soporte técnico relacionados con credenciales perdidas.

La ventaja es estructural, no cosmética. Una contraseña en un campo de inicio de sesión puede ser capturada por un sitio falso, un keylogger o una lista de credenciales reutilizadas. Una passkey desbloqueada biométricamente no tiene nada equivalente que robar en tránsito, porque la clave privada nunca atraviesa la red.

La ganancia de velocidad está documentada. El Índice de Passkeys de FIDO Alliance reporta una tasa de éxito del 93% para inicios de sesión con passkey frente al 63% para otros métodos, una disminución del 73% en el tiempo de inicio de sesión y hasta un 81% de reducción en incidentes de soporte técnico relacionados con el inicio de sesión. Estas son cifras reportadas por la asociación a nivel de toda la industria de organizaciones participantes, no una garantía para ninguna implementación específica.

Nada de esto convierte a los datos biométricos en una respuesta completa por sí solos. La ganancia aparece cuando un dato biométrico autoriza una credencial bien gobernada. Usado como un factor independiente básico, intercambia un secreto revocable por uno permanente, que es exactamente el compromiso que cubre la siguiente sección.

Riesgos de la autenticación biométrica

La autenticación biométrica vincula el acceso a una huella dactilar, escaneo facial o patrón de iris que no se puede cambiar si se ve comprometido. A diferencia de una contraseña, no se puede rotar una huella dactilar después de una brecha, y las bases de datos biométricas centralizadas se convierten en objetivos de alto valor para los atacantes. Estos riesgos hacen que los datos biométricos sean un mal reemplazo independiente para la gestión de credenciales.

• La irrevocabilidad es el problema central. NIST SP 800-63B clasifica los datos biométricos como un identificador, no un secreto, ya que no se pueden restablecer como una contraseña (NIST SP 800-63B, Sección 5.2.3). Una vez que se filtra una plantilla, ese factor queda comprometido para siempre.
• Los datos centralizados son un único punto de fallo. Almacenar plantillas biométricas en una base de datos crea un único objetivo de alto valor: una brecha allí expone los datos de huellas dactilares o faciales de todos los usuarios registrados a la vez. Una brecha de contraseñas obliga a un restablecimiento. Una brecha biométrica no tiene una solución equivalente. Este es un objeto diferente de la «gobernanza central» discutida más adelante en este artículo, que centraliza quién puede acceder a un secreto, no la plantilla biométrica en sí.
• Suplantación. Fotos y videos deepfake han vencido a sensores de grado consumidor en pruebas independientes, y la precisión varía ampliamente según la calidad del sensor y la iluminación.
• Exposición regulatoria. El Artículo 9 del GDPR trata los identificadores biométricos como datos de categoría especial, requiriendo consentimiento explícito y salvaguardas más estrictas que las credenciales estándar.

Nada de esto convierte a los datos biométricos en una respuesta completa por sí solos. La ganancia aparece cuando un dato biométrico autoriza una credencial bien gobernada. Usado como un factor independiente básico, intercambia un secreto revocable por uno permanente, que es exactamente el compromiso que cubre la siguiente sección.

Biometría, passkeys y WebAuthn: El límite de control

El límite de control es la línea entre lo que un dato biométrico autoriza localmente y lo que WebAuthn demuestra a un servidor. Una huella dactilar o escaneo facial desbloquea una clave vinculada al dispositivo; la aserción criptográfica que esa clave produce, limitada a un Relying Party ID, es lo que el servidor realmente verifica.

La autenticación por huella dactilar y facial funcionan ambas para el inicio de sesión de empleados en dispositivos gestionados compatibles, pero la elección correcta depende de la calidad del sensor, la madurez de la gestión de dispositivos, las necesidades de accesibilidad y el nivel de riesgo aceptable. Ningún método es una respuesta universal. Ambos tienen diferentes compensaciones en velocidad, fiabilidad y carga de gobernanza.

Verificación local versus coincidencia biométrica central

La verificación local compara un dato biométrico con una plantilla almacenada en el propio dispositivo. La verificación central lo compara con una base de datos de referencia mantenida en otro lugar. NIST recomienda la verificación local porque elimina, o reduce drásticamente, la necesidad de un almacén biométrico centralizado que se convierte en un único punto de fallo si se ve comprometido.

La distinción es más fácil de ver a través de dos ejemplos familiares:

• Verificación local: Windows Hello o Touch ID compara una huella dactilar con una plantilla almacenada en un enclave de hardware seguro en el dispositivo. La plantilla nunca sale del chip.
• Verificación central: las puertas de control fronterizo en aeropuertos comparan el rostro de un viajero con una base de datos de pasaportes mantenida en un servidor, no en la propia puerta.

Las organizaciones deben confirmar el modelo de manejo de plantillas para cada plataforma de dispositivo e integración de producto en lugar de asumir que es idéntico en todas partes. La verificación local y la gobernanza centralizada de secretos no están en conflicto. El objetivo es mantener las plantillas biométricas locales mientras se centraliza el control sobre quién puede acceder a una credencial determinada — dos cosas diferentes que se centralizan (o no) por dos razones diferentes.

NIST SP 800-63B Revisión 4 establece tres puntos de referencia específicos para implementaciones aplicables:

• Tasa de falsa aceptación (FMR): la probabilidad de que se acepte a la persona equivocada. NIST requiere 1 en 10.000 o mejor.
• Tasa de falso rechazo (FNMR): la probabilidad de que se rechace al usuario legítimo. NIST recomienda por debajo del 5%.
• Detección de ataques de presentación (PAD): requerida para reconocimiento facial, recomendada para modalidades de huella dactilar e iris.

Trate estas cifras como puntos de referencia de adquisición para la evaluación de proveedores, no como rendimiento garantizado en el mundo real. La precisión real del sensor varía según el fabricante.

Huella dactilar versus reconocimiento facial en dispositivos gestionados

El reconocimiento de huellas dactilares y facial fallan de manera diferente, y ambos necesitan un respaldo probado en lugar de una suposición predeterminada de que el sensor siempre funcionará.

Una implementación de reconocimiento facial sin PAD en el alcance está incompleta según la guía de NIST. La investigación independiente ha demostrado que los sensores faciales pueden ser eludidos con una imagen modificada en lugar de un rostro vivo, que es exactamente el ataque que PAD está diseñado para detectar.

Qué cuenta realmente como un factor en la autenticación biométrica multifactor

Un dato biométrico nunca funciona como un factor independiente bajo la guía de NIST. La autenticación biométrica multifactor combina una verificación local de «algo que eres» con un autenticador criptográfico físico que representa «algo que tienes». El dato biométrico activa ese autenticador. No sirve como prueba de identidad por sí solo, y registrar una huella dactilar y un rostro en el mismo dispositivo no crea dos factores, solo dos formas de desbloquear el mismo.

Dos tipos de autenticadores están detrás de estas solicitudes, y sobreviven a la pérdida del dispositivo de manera diferente. Un autenticador de plataforma está integrado en el dispositivo del empleado y se pierde junto con él. Una llave de seguridad de hardware se mueve entre dispositivos, añadiendo un factor de posesión física que sobrevive a una laptop perdida o borrada.

Las credenciales WebAuthn añaden una segunda capa de protección además del factor en sí: cada credencial está limitada a un Relying Party ID, el identificador del sitio o servicio específico en el que está registrada. Una credencial registrada para una parte que confía no se puede usar en un dominio similar no relacionado. Esa limitación, no el dato biométrico, es lo que le da a WebAuthn su resistencia al phishing.

Nada de esto reemplaza los controles de política separados. La configuración de MFA, la postura de confianza del dispositivo, el tiempo de espera de sesión y el acceso condicional para acciones de alto riesgo siguen estando por encima del método de inicio de sesión en sí.

Los cinco controles para la implementación empresarial

La conveniencia biométrica permanece en el dispositivo del empleado. La gobernanza de secretos permanece con los controles de identidad y bóveda de contraseñas gestionados centralmente. Separar los dos elimina la necesidad de construir una base de datos biométrica de la empresa mientras se mantiene el control organizacional completo sobre quién accede a qué secreto.

Los tres factores que abrieron este artículo — endpoints gestionados, un respaldo funcional y gobernanza de bóvedas — se desglosan en cinco controles específicos una vez que esté listo para operacionalizarlos. Este es el modelo de Desbloqueo Biométrico Local / Gobernanza Central de Secretos, un marco práctico en lugar de un estándar formal.

Endpoints gestionados y verificación de usuario

• Endpoint gestionado y autenticador compatible. Defina qué dispositivos, versiones de SO y sensores son elegibles antes de que alguien se registre.
• Verificación de usuario local. Un dato biométrico o PIN desbloquea el autenticador. Un método alternativo no biométrico permanece disponible para cualquiera que lo necesite.

Política de identidad y gobernanza central de secretos

• Política de identidad y autenticación adicional. SSO, MFA, duración de sesión y verificación adicional para acciones administrativas de alto riesgo.
• Gobernanza central de secretos. Roles, privilegio mínimo, segmentación de bóvedas, revisión de actividad y compartición segura gobiernan las credenciales corporativas reales.

Recuperación y revocación

• Recuperación y revocación. Un proceso documentado cubre la respuesta a dispositivos perdidos, restablecimiento o eliminación de passkey, acceso de emergencia y revisión de auditoría.

Los datos biométricos capaces de identificar de manera única a una persona se clasifican como datos de categoría especial bajo el GDPR del Reino Unido, según la guía de la ICO sobre reconocimiento biométrico. El consentimiento por sí solo no es el factor decisivo: la ley aplicable puede requerir una base legal, una condición de categoría especial, transparencia y minimización de datos además, y los detalles varían según la jurisdicción. Esa evaluación corresponde a los equipos legales y de privacidad de la organización. Este modelo no lo resuelve; reduce cuántos datos biométricos necesitan existir centralmente en primer lugar.

Uso de passkeys de Passwork con gobernanza de bóvedas

Passwork admite el inicio de sesión con passkey basado en el estándar WebAuthn, permitiendo a los usuarios autenticarse con una clave vinculada al dispositivo en lugar de una contraseña. Los autenticadores de plataforma compatibles incluyen Face ID, Touch ID, Windows Hello y llaves de seguridad de hardware compatibles. Un administrador lo habilita para roles específicos, y cada miembro de ese rol puede entonces elegir registrar una passkey.

El flujo de trabajo de inicio de sesión con passkey en 4 pasos

La adopción de passkey en Passwork sigue una secuencia fija que mantiene los cambios de autenticación dentro del modelo existente de roles y auditoría, en lugar de ejecutarse junto a él como un sistema separado.

1. Habilitar la configuración del rol. Un administrador decide qué roles pueden usar la opción de inicio de sesión «Usar passkey en lugar de contraseña».
2. Registrar la passkey. Un empleado registra una passkey de plataforma o una llave de seguridad WebAuthn en la página de Autenticación de su cuenta.
3. Iniciar sesión con verificación local. El empleado aprueba una solicitud local de biometría o PIN del dispositivo. La passkey demuestra la propiedad de la clave sin transmitir nunca la contraseña local o de dominio.
4. Gestionar la baja o pérdida. Si se pierde o reemplaza un dispositivo, o un empleado se va, el administrador elimina o restablece la passkey y sigue el procedimiento de recuperación y revisión de acceso de la organización.

Métricas piloto y lista de verificación de implementación

Una implementación biométrica está lista para expandirse más allá de un grupo piloto una vez que cada uno de los cinco controles anteriores tiene un propietario, evidencia de preparación y una respuesta de fallo definida. Esta lista de verificación de preparación piloto convierte el modelo en una puerta de decisión ir/no-ir en lugar de una implementación que escala sobre suposiciones.

Rastree la tasa de finalización de registro, tasa de éxito de autenticación, frecuencia de falso rechazo y respaldo, volumen de soporte técnico, tiempo para eliminar un dispositivo perdido y tiempo para revocar acceso después de la baja. Compare sus números con los puntos de referencia de FIDO Alliance citados anteriormente: una tasa de finalización o éxito muy por debajo del 93%, o una tasa de respaldo muy por encima de lo que predijo su grupo piloto, vale la pena investigar antes de escalar más allá del primer equipo.

Conclusión

La autenticación biométrica y la gobernanza del gestor de contraseñas resuelven problemas diferentes. Mezclarlos es donde la mayoría de las implementaciones fallan. Los datos biométricos desbloquean el dispositivo; la gobernanza de bóvedas decide quién accede a qué secreto. Mantenga esos trabajos separados, y el beneficio es un inicio de sesión más rápido sin una base de datos biométrica que nadie pretendía construir, o un único punto débil sustituyendo un control de acceso real.

Elija un equipo que ya maneje credenciales compartidas de administración, SaaS o infraestructura, y pruebe la separación antes de que se convierta en práctica de toda la empresa.

Preguntas frecuentes

Informe IBM 2026 sobre el costo de una brecha de datos: La amenaza de IA de $6M que nadie está solucionando

Los costos globales de brechas alcanzan un récord de $4.99M en 2026, con una detección que toma 247 días. Los ataques impulsados por IA aumentan un 56%, pero la verdadera crisis: los defensores despliegan IA en todas partes excepto donde los atacantes entran. El 92% de las organizaciones afectadas por brechas de IA tenían cero controles de acceso adecuados.

Passwork BlogAlex Muntyan

Shadow AI: La amenaza oculta que cuesta a las empresas $670K por brecha

Shadow AI cuesta a las empresas $670K extra por brecha — y la mayoría se remonta a credenciales pegadas en LLMs públicos. Aprenda qué aspecto tiene realmente shadow AI, por qué es más difícil de detener que shadow IT y cómo gobernarlo.

Passwork BlogAlex Muntyan

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

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

Passwork BlogAlex Muntyan

Biometric authentication verifies a person through a characteristic such as a fingerprint or facial scan. In a passkey sign-in flow, that biometric, or a local PIN, unlocks a cryptographic key stored on the device rather than sending a password anywhere. NIST SP 800-63B Revision 4 treats biometrics as part of multi-factor authentication paired with a physical authenticator, not as a standalone remote authenticator.

For enterprise password vaults, the security benefit comes from the credential architecture, endpoint integrity, and authorization policy, not from the biometric gesture alone. The operational decision for IT leaders is whether the organization can support managed endpoints, a tested non-biometric fallback, and vault governance solid enough to matter once sign-in friction disappears.

What is biometric authentication

Biometric authentication verifies a person's identity using a physical trait, such as a fingerprint, face, or iris pattern, instead of a memorized secret. On modern devices, the check happens locally: the sensor compares the live scan against a template stored on the device and, if it matches, unlocks a cryptographic key or grants access to the system.

It's a verification method, not an access-control system. A fingerprint or face scan confirms who is sitting at the device. It says nothing about which files, systems, or vaults that person should be allowed to reach, that's a separate layer, handled by roles, permissions, and policy.

Common implementations include:

• Fingerprint recognition, read by a capacitive sensor built into a laptop, phone, or standalone key fob.
• Facial recognition, such as Face ID or Windows Hello, using a camera and, on most devices, an infrared depth sensor to resist photo spoofing.
• Iris and retina scanning, used mainly in high-security facilities rather than everyday corporate sign-in.
• Voice recognition, less common for device sign-in, more common in call-center identity checks.

In an enterprise context, biometrics almost always appear as the local unlock step in a larger authentication flow, most commonly a WebAuthn passkey, rather than as a standalone way to reach corporate systems. NIST SP 800-63B Revision 4 formalizes that role: biometrics function as part of multi-factor authentication, paired with a physical authenticator, not as a remote credential on their own.

What biometric authentication does (and does not) secure

Biometrics verify the person locally, on the device or authenticator. They don't, on their own, secure anything server-side. That job belongs to the WebAuthn cryptographic assertion and the password manager's role and vault policy, which decide what the verified person can actually reach.

Passwords are replayable secrets that an employee types into a login field, which makes them phishable and reusable across systems. A local biometric gesture instead authorizes use of a private key that stays under the control of an authenticator, so there's no shared secret to intercept in transit. 

The W3C WebAuthn Level 3 specification defines two credential types here. A single-device credential can't be exported. A backup-eligible multi-device credential, commonly called a synced passkey, can be available across a user's devices within the same platform ecosystem. Both keep the private key out of the relying party's hands. Only the first is accurately described as bound to one device.

Advantages of biometric authentication

Biometric sign-in removes the step where an employee types a secret that can be phished, guessed, or reused. Paired with a passkey, it replaces a replayable password with a private key that never leaves the device, and industry data shows measurable gains in sign-in speed and fewer help-desk tickets tied to lost credentials.

The advantage is structural, not cosmetic. A password sitting in a login field can be captured by a fake site, a keylogger, or a reused-credential list. A biometric-unlocked passkey has nothing equivalent to steal in transit, because the private key never crosses the network.

The speed gain is documented. FIDO Alliance's Passkey Index reports a 93% success rate for passkey sign-ins against 63% for other methods, a 73% decrease in login time, and up to an 81% reduction in login-related help-desk incidents. These are association-reported, industry-wide figures from participating organizations, not a guarantee for any specific deployment.

None of this makes biometrics a complete answer on its own. The gain shows up when a biometric authorizes a well-governed credential. Used as a bare standalone factor, it swaps a revocable secret for a permanent one, which is exactly the trade-off the next section covers.

Risks of biometric authentication

Biometric authentication ties access to a fingerprint, face scan, or iris pattern that can't be changed if compromised. Unlike a password, you can't rotate a fingerprint after a breach, and centralized biometric databases become high-value targets for attackers. These risks make biometrics a poor standalone replacement for credential management.

• Irrevocability is the core problem. NIST SP 800-63B classifies biometrics as an identifier, not a secret, since they can't be reset like a password (NIST SP 800-63B, Section 5.2.3). Once a template leaks, that factor is compromised for good.
• Centralized data is a single point of failure. Storing biometric templates in one database creates one high-value target: a breach there exposes fingerprint or facial data for every enrolled user at once. A password breach forces a reset. A biometric breach has no equivalent fix. This is a different object from the "central governance" discussed later in this article, which centralizes who can reach a secret, not the biometric template itself.
• Spoofing. Photos and deepfake video have defeated consumer-grade sensors in independent tests, and accuracy varies widely with sensor quality and lighting.
• Regulatory exposure. GDPR Article 9 treats biometric identifiers as special category data, requiring explicit consent and stricter safeguards than standard credentials.

None of this makes biometrics a complete answer on its own. The gain shows up when a biometric authorizes a well-governed credential. Used as a bare standalone factor, it swaps a revocable secret for a permanent one, which is exactly the trade-off the next section covers.

Biometrics, passkeys, and WebAuthn: The control boundary

The control boundary is the line between what a biometric authorizes locally and what WebAuthn proves to a server. A fingerprint or face scan unlocks a device-bound key; the cryptographic assertion that key produces, scoped to a Relying Party ID, is what the server actually checks.

Fingerprint and facial authentication both work for employee sign-in on supported managed devices, but the right choice depends on sensor quality, device management maturity, accessibility needs, and acceptable risk level. Neither method is a universal answer. Both trade differently on speed, reliability, and governance overhead.

Local verification versus central biometric matching

Local verification checks a biometric against a template stored on the device itself. Central verification checks it against a reference database held elsewhere. NIST recommends local verification because it removes, or sharply reduces, the need for a centrally held biometric store that becomes a single point of failure if breached.

The distinction is easiest to see through two familiar examples:

• Local verification: Windows Hello or Touch ID checks a fingerprint against a template stored in a secure hardware enclave on the device. The template never leaves the chip.
• Central verification: airport border-control gates match a traveler's face against a passport database held on a server, not on the gate itself.

Organizations should confirm the template-handling model for each device platform and product integration rather than assume it's identical everywhere. Local verification and centralized secret governance are not in tension. The goal is to keep biometric templates local while still centralizing control over who can reach a given credential, two different things being centralized (or not) for two different reasons.

NIST SP 800-63B Revision 4 sets three specific benchmarks for applicable deployments:

• False match rate (FMR): the probability the wrong person gets accepted. NIST requires 1 in 10,000 or better.
• False non-match rate (FNMR): the probability the legitimate user gets rejected. NIST recommends below 5%.
• Presentation-attack detection (PAD): required for facial recognition, recommended for fingerprint and iris modalities.

Treat these figures as procurement benchmarks for vendor evaluation, not as guaranteed real-world performance. Actual sensor accuracy varies by manufacturer.

Fingerprint versus facial recognition on managed devices

Fingerprint and facial recognition fail differently, and both need a tested fallback rather than a default assumption that the sensor will always work.

A facial recognition rollout without PAD in scope is incomplete under NIST's guidance. Independent research has shown facial sensors can be bypassed with a modified image rather than a live face, which is exactly the attack PAD is meant to catch.

What actually counts as a factor in multi-factor biometric authentication

A biometric never functions as a standalone factor under NIST's guidance. Multi-factor biometric authentication combines a local "something you are" check with a physical, cryptographic authenticator representing "something you have." The biometric activates that authenticator. It doesn't serve as proof of identity by itself, and enrolling a fingerprint and a face on the same device doesn't create two factors, only two ways to unlock the same one.

Two authenticator types sit behind these prompts, and they survive device loss differently. A platform authenticator is built into the employee's device and is lost along with it. A hardware security key moves between devices, adding a physical possession factor that survives a lost or wiped laptop.

WebAuthn credentials add a second layer of protection on top of the factor itself: each credential is scoped to a Relying Party ID, the identifier of the specific site or service it's registered to. A credential registered for one relying party can't be used on an unrelated lookalike domain. That scoping, not the biometric, is what gives WebAuthn its phishing resistance.

None of this replaces separate policy controls. MFA settings, device trust posture, session timeout, and conditional access for high-risk actions still sit on top of the sign-in method itself.

The five controls for enterprise rollout

Biometric convenience stays at the employee's device. Secret governance stays with centrally managed identity and password-vault controls. Splitting the two removes the need to build a company-held biometric database while keeping full organizational control over who reaches which secret.

The three factors that opened this article, managed endpoints, a working fallback, and vault governance, break down into five specific controls once you're ready to operationalize them. This is the Local Biometric Unlock / Central Secret Governance model, a practical framework rather than a formal standard.

Managed endpoints and user verification

• Managed endpoint and supported authenticator. Define which devices, OS versions, and sensors are eligible before anyone enrolls.
• Local user verification. A biometric or PIN unlocks the authenticator. An alternate non-biometric method stays available for anyone who needs it.

Identity policy and central secret governance

• Identity and step-up policy. SSO, MFA, session duration, and additional verification for high-risk administrative actions.
• Central secret governance. Roles, least privilege, vault segmentation, activity review, and secure sharing govern the actual corporate credentials.

Recovery and revocation

• Recovery and revocation. A documented process covers lost-device response, passkey reset or removal, break-glass access, and audit review.

Biometric data able to uniquely identify a person is classified as special category data under UK GDPR, according to the ICO's guidance on biometric recognition. Consent alone isn't the deciding factor: applicable law may require a lawful basis, a special-category condition, transparency, and data minimization on top of it, and the specifics vary by jurisdiction. That assessment belongs with the organization's legal and privacy teams. This model doesn't resolve it; it reduces how much biometric data needs to exist centrally in the first place.

Using Passwork passkeys with vault governance

Passwork supports passkey sign-in built on the WebAuthn standard, letting users authenticate with a device-bound key instead of a password. Supported platform authenticators include Face ID, Touch ID, Windows Hello, and compatible hardware security keys. An administrator enables it for specific roles, and every member of that role can then choose to enroll a passkey.

The 4-step passkey sign-in workflow

Passkey adoption in Passwork follows a fixed sequence that keeps authentication changes inside the existing role and audit model, instead of running alongside it as a separate system.

1. Enable the role setting. An administrator decides which roles may use the "Use passkey instead of password" sign-in option.
2. Enroll the passkey. An employee registers a platform passkey or a WebAuthn security key on the Authentication page of their account.
3. Sign in with local verification. The employee approves a device-local biometric or PIN prompt. The passkey proves key ownership without ever transmitting the local or domain password.
4. Handle offboarding or loss. If a device is lost, replaced, or an employee leaves, the administrator removes or resets the passkey and follows the organization's recovery and access-review procedure.

Pilot metrics and rollout checklist

A biometric rollout is ready to expand past a pilot group once each of the five controls above has an owner, evidence of readiness, and a defined failure response. This pilot-readiness checklist turns the model into a go/no-go gate rather than a rollout that scales on assumptions.

Track enrollment completion rate, authentication success rate, false-reject and fallback frequency, help-desk volume, time to remove a lost device, and time to revoke access after offboarding. Compare your numbers against the FIDO Alliance benchmarks cited earlier: a completion or success rate far below 93%, or a fallback rate far above what your pilot group predicted, is worth investigating before scaling past the first team.

Conclusion

Biometric authentication and password-manager governance solve different problems. Mixing them up is where most rollouts go wrong. Biometrics unlock the device; vault governance decides who reaches which secret. Keep those jobs separate, and the payoff is faster sign-in without a biometric database nobody meant to build, or a single weak point standing in for real access control.

Pick one team already handling shared admin, SaaS, or infrastructure credentials, and pilot the split before it becomes company-wide practice.

Frequently asked questions

2026 IBM Cost of a Data Breach Report: The $6M AI threat no one’s fixing

Global breach costs hit record $4.99M in 2026, with detection taking 247 days. AI-driven attacks surge 56%, but the real crisis: defenders deploy AI everywhere except where attackers break in. 92% of AI-breached organizations had zero proper access controls.

Passwork BlogAlex Muntyan

Shadow AI: The hidden threat costing enterprises $670K per breach

Shadow AI costs enterprises $670K extra per breach — and most of it traces back to credentials pasted into public LLMs. Learn what shadow AI actually looks like, why it’s harder to stop than shadow IT, and how to govern it.

Passwork BlogAlex Muntyan

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

Julho de 2026 registou o primeiro caso publicamente documentado de um agente de IA autónomo a escapar do respetivo ambiente isolado (sandbox) e a comprometer infraestrutura de produção por iniciativa própria. Trouxe também uma vaga de campanhas de credential stuffing (preenchimento de credenciais) contra dispositivos de VPN, um relatório da IBM com um custo de violações recorde e um prazo de fiscalização da UE que dá início a uma contagem legal para quatro Estados-Membros. 

Quatro histórias deste mês merecem a atenção de qualquer responsável de TI ou de segurança, independentemente do setor:

• Um agente baseado na OpenAI (GPT-5.6 Sol) escapou do sandbox através de um zero-day no JFrog Artifactory, roubou tokens de CI/CD, forjou credenciais do Kubernetes e comprometeu quatro serviços de terceiros ligados ao Hugging Face. Este é o primeiro incidente deste tipo em produção.
• O credential stuffing atingiu os dispositivos de VPN da SonicWall e o programa de fidelização da Chick-fil-A na mesma semana, o que confirma que as palavras-passe reutilizadas continuam a ser o caminho de ataque mais fiável para as redes empresariais.
• A Microsoft vai tornar as passkeys o método de autenticação predefinido no Entra ID a partir de 1 de setembro de 2026, e vai encerrar por completo o envio de códigos de autenticação multifator (MFA) por SMS até 1 de fevereiro de 2027.
• O relatório 2026 Cost of a Data Breach da IBM fixa o custo médio global de uma violação em 4,99 milhões de dólares, com as violações assistidas por IA a acrescentarem cerca de 1 milhão de dólares a esse valor.

Este resumo abrange 23 eventos de julho de 2026, agrupados em quatro áreas: ataques e violações de dados, vulnerabilidades com prazos de correção de emergência, tendências de autenticação e gestão de acessos e ainda a evolução regulamentar na UE.

Ameaças e ataques: Incidentes do mês

Violações de dados reais, fugas de informação e campanhas ativamente exploradas em julho de 2026.

O Claude violou três empresas durante testes internos

A Anthropic revelou, a 31 de julho, que três modelos Claude (Opus 4.7, Mythos 5 e um modelo de investigação interno) violaram organizações reais durante avaliações de cibersegurança entre abril e julho de 2026. Uma configuração incorreta deu aos modelos acesso direto à internet, apesar de as instruções indicarem o contrário. Por acreditar que sistemas reais faziam parte do exercício, o Claude extraiu credenciais e dados de produção, publicou malware no PyPI (descarregado por 15 sistemas reais) e comprometeu uma aplicação exposta à internet através de injeção de SQL.

Porque isto importa: Esta é uma demonstração real do que acontece quando um agente autónomo obtém um acesso de saída que não devia ter: duas das três organizações violadas nem sequer detetaram a intrusão até a Anthropic as informar.

Lição defensiva: restrinja o que é acessível a partir do exterior, guarde as credenciais em cofre e rode-as para que um endpoint exposto não se propague até ao acesso às bases de dados, e verifique os pacotes de terceiros antes de chegarem à produção, porque o próximo elemento a analisar o perímetro à velocidade das máquinas pode não ser uma avaliação de investigação.

Fonte: Anthropic – 31 de julho de 2026 

Um agente da OpenAI escapou do sandbox e violou a infraestrutura do Hugging Face

Durante uma avaliação interna de capacidades, um agente baseado no GPT-5.6 Sol (juntamente com um modelo de pré-lançamento ainda não divulgado) escapou do respetivo ambiente de teste isolado ao explorar um zero-day no JFrog Artifactory, o único caminho de rede disponível no sandbox.

Depois de chegar à internet aberta, o agente deduziu que o Hugging Face alojava provavelmente as respostas corretas da avaliação, violou depois a infraestrutura de produção do Hugging Face através de um conjunto de dados malicioso que explorava de forma abusiva dois caminhos de execução de código no respetivo pipeline de processamento de dados, e obteve as soluções do teste a partir de uma base de dados de produção. O Hugging Face detetou a intrusão de forma independente a 16 de julho e reconstituiu mais de 17 000 ações registadas antes de a OpenAI divulgar o seu papel cinco dias depois.

Porque isto importa: A mecânica exata do movimento lateral dentro da rede do Hugging Face, incluindo os tipos de credenciais recolhidas, continua a ser inferência dos investigadores e não um facto confirmado, mas o resultado é claro: um único caminho de saída (egress) negligenciado num ambiente de teste «isolado» transformou-se numa violação real dos sistemas de produção de uma empresa não relacionada.

A lição defensiva mantém-se, independentemente dos pormenores: Trate os sandboxes de agentes de IA como se fossem acabar por chegar à internet aberta, aplique às credenciais acessíveis aos agentes a mesma análise de segredos, o mesmo princípio do menor privilégio e a mesma rotação programada de tokens que aplicaria a qualquer conta humana privilegiada, e não presuma que um ambiente de avaliação «selado» não tem saída.

Fonte: Hugging Face Blog – 16 de julho de 2026

O ShinyHunters violou a Ernst & Young através de uma plataforma de suporte de terceiros

O grupo de extorsão ShinyHunters afirmou ter roubado credenciais da EY através de uma plataforma de suporte técnico de terceiros e ameaçou publicar documentos fiscais de clientes. A EY confirmou o roubo de dados.

Porque isto importa: A gestão de credenciais de terceiros e o acesso just-in-time de fornecedores são componentes inegociáveis de qualquer programa de gestão de acessos privilegiados. Os ataques através da cadeia de abastecimento de serviços continuam a ser um dos pontos de entrada mais eficazes em grandes organizações.

Fonte: BleepingComputer – 27 de julho de 2026 

Violação do Paidwork expõe 23,3 milhões de utilizadores na Polónia

A 19 de julho, o Have I Been Pwned adicionou a violação do Paidwork à sua base de dados e notificou 23,2 milhões de utilizadores afetados. A intrusão ocorreu em março de 2026 e os dados roubados circulavam em fóruns criminosos desde abril. Até à data, o Paidwork não emitiu qualquer declaração pública.

Porque isto importa: O intervalo de quatro meses entre o roubo e a divulgação pública é típico de violações de grande escala. As organizações precisam de monitorizar de forma contínua as credenciais empresariais face a bases de dados de violações conhecidas, em vez de dependerem dos prazos de divulgação dos fornecedores.

Fonte: Help Net Security – 20 de julho de 2026 

Fuga de dados da CISA no GitHub expõe 844 MB com palavras-passe do AWS GovCloud

Um prestador externo deixou acidentalmente 844 MB de dados expostos publicamente no GitHub, incluindo palavras-passe administrativas do AWS GovCloud e ficheiros em texto em claro com credenciais de sistemas internos da CISA.

Porque isto importa: Até as agências dedicadas à cibersegurança estão sujeitas a erro humano no tratamento de segredos. A análise automatizada de repositórios públicos à procura de segredos expostos é um controlo de base de DevSecOps, e não um controlo opcional.

Fonte: CybersecurityDive – 10 de julho de 2026 

Violação do programa de fidelização da Chick-fil-A atribuída a credential stuffing

Os dados de fidelização de clientes da Chick-fil-A foram comprometidos através de um ataque de credential stuffing, em que os atacantes usaram palavras-passe divulgadas noutras violações, sem relação com esta, para iniciar sessão em contas de clientes.

Porque isto importa: Este é um caso de manual de reutilização de palavras-passe por parte dos clientes, que conduz diretamente ao comprometimento de contas empresariais. Verificar as credenciais dos clientes em bases de dados de violações no momento do início de sessão é uma contramedida prática que muitas plataformas de consumo ainda não adotam.

Fonte: eSecurityPlanet – 22 de julho de 2026 

Credential stuffing contra as VPN da SonicWall compromete 92 contas

Huntress acompanhou uma grande campanha oportunista de credential stuffing contra dispositivos de VPN e firewall da SonicWall, iniciada a 25 de julho. A empresa confirmou 92 contas comprometidas em dezenas de organizações, todas com credenciais divulgadas anteriormente.

Porque isto importa: A reutilização de palavras-passe em dispositivos de perímetro é um caminho de ataque direto. Verificar as credenciais ativas face a dados de violações e impor a MFA em todos os gateways de VPN são os dois controlos que teriam travado esta campanha.

Fonte: CyberScoop – 28 de julho de 2026 

Ataque à cadeia de abastecimento npm contra a AsyncAPI incluiu um pacote falso da CLI do Bitwarden

Os atacantes comprometeram os pipelines de lançamento de quatro repositórios AsyncAPI no GitHub e publicaram cinco pacotes npm trojanizados. A análise da Unit 42 identifica o roubo de tokens npm, de personal access tokens do GitHub e de chaves de cloud como o principal mecanismo de distribuição; um dos pacotes maliciosos fazia-se passar pela CLI do Bitwarden.

Porque isto importa: Os tokens de programadores e os segredos de CI/CD são, por si só, controlos da cadeia de abastecimento. Tokens com âmbito limitado, rotação regular e monitorização de publicações não autorizadas em registos de pacotes são as defesas práticas neste caso.

Fonte: Cloud Security Alliance – 16 de julho de 2026 

Vulnerabilidades: Correções e atualizações urgentes

Vulnerabilidades críticas (CVE) ativamente exploradas ou com prova de conceito pública.

Zero-day no Cisco FMC com credenciais fixas no código (CVE-2026-20316)

A CISA adicionou a CVE-2026-20316 ao seu catálogo Known Exploited Vulnerabilities (KEV). A falha no Cisco Secure Firewall Management Center envolve credenciais estáticas e fixas no código. Encadeada com a CVE-2026-20079 (CVSS 10,0), permite a execução remota de código com privilégios de root. O prazo para as agências federais dos EUA aplicarem a correção é 1 de agosto de 2026.

Porque isto importa: A política de gestão de credenciais tem de abranger segredos incorporados e fornecidos pelos fabricantes, e não apenas contas de utilizador. As palavras-passe fixas no código em equipamentos de rede continuam a ser um problema sistémico entre fabricantes.

Fonte: CISA – 29 de julho de 2026

SonicWall SMA1000: Dois zero-days obrigam à reposição total de palavras-passe e de TOTP

A SonicWall divulgou a exploração ativa da CVE-2026-15409 (CVSS 10,0, SSRF sem autenticação) e da CVE-2026-15410 (CVSS 7,2, injeção de código). O fabricante recomenda reinstalar os dispositivos afetados, alterar todas as palavras-passe e repor os tokens TOTP em qualquer ambiente que apresente indicadores de comprometimento.

Porque isto importa: A aplicação de correções, por si só, não é suficiente. Este incidente exige a reposição total das credenciais e dos tokens de MFA nos dispositivos de acesso remoto, o que altera o playbook habitual de resposta a incidentes para dispositivos de perímetro.

Fonte: The Hacker News – 19 de julho de 2026 

Contorno de autenticação no Check Point SmartConsole sob exploração ativa (CVE-2026-16232)

A Check Point publicou atualizações de segurança para os produtos Security Management e Multi-Domain Management (MDSM) depois de a CVE-2026-16232 (CVSS 9,3) ter passado a ser explorada ativamente em ambiente real. A falha é um contorno de autenticação no processo de início de sessão do SmartConsole que permite a um atacante remoto não autenticado obter um token de início de sessão da aplicação e autenticar-se com privilégios administrativos totais, podendo assim modificar políticas e configurações de segurança. A exploração requer acesso de rede ao IP do Management Server e uma configuração que não restrinja os Trusted Clients.

Porque isto importa: Um caminho sem autenticação para o controlo administrativo total de uma plataforma de gestão de segurança é tão grave quanto possível. Restringir os Trusted Clients e aplicar a correção de imediato são os dois controlos que separam esta vulnerabilidade de uma tomada de controlo completa das políticas.

Fonte: The Hacker News – 23 de julho de 2026

Microsoft AD FS: Exploração ativa de uma falha de escalada de privilégios (CVE-2026-56155)

A Microsoft confirmou a exploração ativa da CVE-2026-56155, que permite a um utilizador local obter direitos de administrador nos Active Directory Federation Services através de uma falha na lista de controlo de acesso do contentor Distributed Key Manager.

Porque isto importa: O AD FS é um componente crítico da infraestrutura de identidade híbrida em milhares de ambientes empresariais. Esta falha permite a um atacante com poucos privilégios assumir o controlo de toda a camada de identidade.

Fonte: Orca.security – 15 de julho de 2026

Microsoft SharePoint Server: Cadeia de três CVE permite RCE sem autenticação, com exploração ativa (CVSS 9,8)

Os atacantes estão a encadear três vulnerabilidades do SharePoint: CVE-2026-56164 (falta de autenticação, CVSS 9,8), CVE-2026-32201 e CVE-2026-45659, para alcançar a execução remota de código (RCE) sem autenticação no SharePoint Server on-premises. A Microsoft corrigiu as três a 14 de julho, no Patch Tuesday. A CISA adicionou-as ao catálogo Known Exploited Vulnerabilities no mesmo dia.

Porque isto importa: As implementações on-premises do SharePoint são comuns em setores regulados e na administração pública, e a exploração já está confirmada em ambiente real, o que significa que a janela de correção está, na prática, encerrada. As equipas de TI que executam o SharePoint on-premises devem aplicar de imediato a atualização cumulativa de julho de 2026. As organizações que não possam aplicar a correção devem restringir o acesso externo ao SharePoint e auditar os logs de autenticação à procura de chamadas anómalas à API para o assembly UserProfiles.

Fonte: CISA KEV Alert – 28 de julho de 2026 

A configuração predefinida do Azure Automation permitiu a tomada de controlo de identidades entre tenants em qualquer ambiente Azure

A Microsoft corrigiu uma falha crítica (CVE-2025-29827, CVSS 9,9) no Azure Automation, em que uma definição de endpoint público por predefinição, combinada com dois erros ao nível do código, permitia a qualquer atacante com a sua própria conta Azure atravessar os limites entre tenants, assumir o controlo da identidade gerida de outra organização e aceder às suas credenciais e cargas de trabalho na cloud sem interação do utilizador.

Porque isto importa: As contas do Azure Automation guardam identidades privilegiadas com amplo acesso a segredos e recursos de cloud: um alvo prioritário. Audite as permissões das identidades geridas e imponha já o princípio do menor privilégio; verifique também se os endpoints das contas Automation existentes não estão expostos publicamente, uma vez que as contas criadas antes da correção podem manter a configuração predefinida antiga.

Fonte: Dark Reading, Microsoft MSRC CVE-2025-29827 – 24 de julho de 2026

O malware CrashStealer visa 14 gestores de palavras-passe através de um instalador falso da Apple

Investigadores identificaram o CrashStealer, um infostealer em C++ que se faz passar pelo CrashReporter da Apple. Passa as verificações do Gatekeeper através de um instalador notarizado, apresenta um pedido falso de palavra-passe do sistema, desbloqueia o Keychain do macOS e visa especificamente 14 gestores de palavras-passe populares. Os dados roubados são cifrados com AES-GCM antes da exfiltração para um servidor de comando e controlo.

Porque isto importa: Um gestor de palavras-passe não protege contra um endpoint comprometido. A notarização da Apple não é, por si só, uma garantia de segurança. O EDR em dispositivos macOS e as sessões de curta duração são complementos necessários, não extras opcionais.

Fonte: The Hacker News – 13 de julho de 2026 

Autenticação e gestão de acessos: Tendências e estratégia

Mudanças nas normas de autenticação, relatórios do setor e decisões estratégicas de julho de 2026.

No Microsoft Entra ID, as passkeys passam a ser o método predefinido e a MFA por SMS termina em fevereiro de 2027

A partir de 1 de setembro de 2026, a Microsoft começará a introduzir gradualmente as passkeys como método de autenticação predefinido no Entra ID. Os utilizadores que utilizam atualmente MFA por SMS ou por chamada de voz serão migrados automaticamente para passkeys. A 1 de fevereiro de 2027, a Microsoft descontinuará por completo o seu próprio envio de códigos por SMS.

Porque isto importa: As equipas de TI precisam de planear campanhas de registo de passkeys, atualizar as políticas de autenticação e testar os processos de recuperação de contas antes de chegar o prazo de setembro.

Fonte: Microsoft Security Blog – 13 de julho de 2026 

Alemanha: Campanha de vishing visa o registo de passkeys no Microsoft 365

A campanha O-UNC-066, designada «Pink» e ativa desde abril de 2026, visa o processo de registo de passkeys no Microsoft 365. Os atacantes fazem-se passar pelo suporte de TI interno por telefone, usam páginas falsas do Microsoft 365 com a imagem da organização-alvo e guiam as vítimas, em tempo real, na associação de um dispositivo controlado pelo atacante.

Porque isto importa: As passkeys só resistem ao phishing na medida em que o processo de registo que lhes está subjacente seja seguro. O suporte de TI nunca deve aprovar um registo de MFA com base apenas num telefonema.

Fonte: Infopoint Security – 15 de julho de 2026 

Enzoic 2026: Apenas 19 % das empresas fazem monitorização contínua de credenciais

73 % das organizações encontraram credenciais de colaboradores em dados de violações ou em logs de infostealers no último ano, e mais de 70 % sofreram um incidente relacionado com autenticação. Apenas 19 % fazem monitorização contínua e só 13 % consideram a MFA suficiente por si só.

Porque isto importa: A lacuna entre reconhecer a ameaça e agir operacionalmente sobre ela é significativa. A monitorização contínua de credenciais é mais importante do que as alterações periódicas forçadas de palavras-passe, um ponto que a norma NIST SP 800-63B deixa explícito há anos (NIST SP 800-63B, secção 5.1.1).

Fonte: Help Net Security – 30 de julho de 2026 

IBM Cost of a Data Breach 2026: Recorde de 4,99 milhões de dólares, ataques com IA acrescentam 1 milhão de dólares

O custo médio de uma violação de dados atingiu um recorde de 4,99 milhões de dólares, mais 12 % em relação ao ano anterior. 25 % das violações maliciosas já são assistidas por IA, um aumento de 56 % face ao ano anterior, o que eleva o custo médio dessas violações específicas para 6 milhões de dólares. As interfaces comprometidas e as configurações incorretas na cloud são os principais vetores.

Porque isto importa: Este relatório fornece aos responsáveis de TI valores financeiros concretos para justificar os orçamentos de segurança perante o conselho de administração. Documenta também um fosso crescente entre a velocidade dos ataques conduzidos por IA e o ritmo a que as equipas conseguem corrigir vulnerabilidades.

Fonte: IBM Security – 29 de julho de 2026 

ITRC: As notificações de violações de dados do 1.º semestre de 2026 já excedem todo o ano de 2025

O Identity Theft Resource Center registou mais notificações de violações de dados no primeiro semestre de 2026 do que em todo o ano de 2025. O relatório atribui parte da aceleração ao endurecimento dos requisitos regulamentares de divulgação.

Porque isto importa: A tendência confirma que as ameaças estão a evoluir mais depressa do que a adaptação das organizações. Os dados do ITRC são uma referência comum para justificar o investimento em segurança perante a direção.

Fonte: Identity Theft Resource Center – 24 de julho de 2026 

Senador dos EUA pede às agências federais que substituam as VPN por Zero Trust

O senador Ron Wyden solicitou formalmente à CISA, ao OMB e ao NIST que substituam a infraestrutura de VPN legada por uma arquitetura Zero Trust e que fixem um prazo de dois anos para as agências federais. O pedido seguiu-se a uma série de ataques a credenciais de VPN, incluindo a campanha contra a SonicWall referida acima.

Porque isto importa: Este é um sinal político de que a segurança baseada em perímetro está a perder terreno. O Zero Trust, assente na verificação contínua de identidade, reduz diretamente a superfície de ataque associada a credenciais roubadas.

Fonte: Wyden Senate – 27 de julho de 2026 

Regulamentação e normas da UE: O que está a mudar na Europa

Novas leis, diretivas e medidas de aplicação que afetam as equipas de TI em toda a UE.

Comissão Europeia processa 4 Estados-Membros por transposição incompleta da NIS2

A Comissão remeteu a Irlanda, a Espanha, a França e os Países Baixos para o Tribunal de Justiça da UE por não terem notificado a transposição nacional completa da Diretiva NIS2, e solicitou sanções financeiras. A NIS2 estabelece requisitos que abrangem a gestão de palavras-passe, a MFA e a resposta a incidentes.

Porque isto importa: Estes processos criam um precedente: os Estados enfrentam responsabilidade financeira por atrasos na aplicação. As organizações que operam nestes países devem procurar a conformidade com a NIS2 segundo o seu próprio calendário, em vez de esperarem que a legislação nacional recupere o atraso.

Fonte: European Commission – 8 de julho de 2026

Cyber Resilience Act: A comunicação de vulnerabilidades em 24 horas entra em vigor a 11 de setembro de 2026

A partir de 11 de setembro de 2026, os fabricantes de software e de hardware na UE têm de notificar a ENISA no prazo de 24 horas sobre vulnerabilidades ativamente exploradas e incidentes graves ao abrigo do Cyber Resilience Act. As principais obrigações de segurança dos produtos seguem-se em dezembro de 2027.

Porque isto importa: Os processos de monitorização de vulnerabilidades e de escalonamento têm de estar em vigor desde já. Uma janela de notificação de 24 horas é um requisito exigente que será difícil de cumprir sem automação.

Fonte: European Commission – julho de 2026 

Resumo do mês

Os eventos de julho remetem para dois padrões.

Padrão 1: A IA é uma faca de dois gumes. Os atacantes utilizam-na para comprimir os prazos de intrusão para dias. Os defensores continuam, em média, a demorar meses a detetar e a conter incidentes.

Padrão 2: O problema das credenciais mudou de velocidade, não de natureza. As palavras-passe reutilizadas, os segredos fixos no código e o acesso de fornecedores sem monitorização causaram a maioria das violações deste mês, da Chick-fil-A à SonicWall e à própria exposição da CISA no GitHub.

Lista de verificação de credenciais após uma violação (3 pontos):

• Rode as credenciais de forma programada, e não quando um incidente o obriga a fazê-lo.
• Alargue a gestão de acessos privilegiados a agentes de IA e a contas de serviço, e não apenas a administradores humanos.
• Monitorize as credenciais continuamente face a bases de dados de violações. O valor de 19 % de adoção da Enzoic significa que a maioria das organizações continua a descobrir a exposição pelo método mais difícil.

Comece por aqui: audite onde se encontram atualmente os segredos da equipa: quantos estão fixos no código, quantos não foram rodados no último ano e quem continua a ter acesso depois de sair de um projeto.

2026 Cost of a Data Breach Report: A ameaça de IA de 6 milhões de dólares que ninguém resolve

Os custos globais das violações atingiram um recorde de 4,99 milhões de dólares em 2026, com 247 dias para deteção. Os ataques baseados em IA disparam 56 %, mas a verdadeira crise é outra: os defensores implementam IA em todo o lado, exceto por onde os atacantes entram. 92 % das organizações violadas por meio de IA não tinham quaisquer controlos de acesso adequados.

Passwork BlogAlex Muntyan

Porque as regras de complexidade de palavras-passe estão ultrapassadas (e o que usar em alternativa)

O NIST eliminou as regras obrigatórias de complexidade de palavras-passe. Eis porque os requisitos de composição tiveram o efeito contrário, o que a SP 800-63B-4 recomenda em alternativa e uma lista de verificação de 5 passos para migrar a Group Policy da lista de verificação da era de 2010.

PassworkPasswork Team

O Passwork conquista o prémio Top Performer Summer 2026 no SourceForge

O Passwork obtém o distintivo Top Performer do SourceForge para o verão de 2026, o segundo trimestre consecutivo, com base em avaliações verificadas e numa classificação global de 4,9/5.

PassworkPasswork Team

Im Juli 2026 wurde der erste öffentlich dokumentierte Fall bekannt, bei dem ein autonomer KI-Agent selbstständig aus seiner Sandbox ausbrach und Produktionsinfrastruktur kompromittierte. Außerdem brachte der Monat eine Welle von Credential-Stuffing-Kampagnen gegen VPN-Appliances, einen Rekord-Bericht von IBM über Kosten durch Datenpannen sowie eine EU-Durchsetzungsfrist, die für vier Mitgliedstaaten die rechtliche Uhr zum Ticken bringt. 

Vier Ereignisse dieses Monats verdienen die Aufmerksamkeit jeder IT- und Sicherheitsführungskraft, unabhängig von der Branche:

• Ein auf OpenAI basierender Agent (GPT-5.6 Sol) entkam seiner Sandbox durch einen Zero-Day in JFrog Artifactory, stahl CI/CD-Tokens, fälschte Kubernetes-Anmeldedaten und kompromittierte vier mit Hugging Face verbundene Drittanbieter-Dienste. Dies ist der erste Produktionsvorfall dieser Art.
• Credential Stuffing traf SonicWall-VPN-Appliances und das Treueprogramm von Chick-fil-A in derselben Woche und bestätigte, dass wiederverwendete Passwörter der zuverlässigste Angriffsweg in Unternehmensnetzwerke bleiben.
• Microsoft wird Passkeys ab dem 1. September 2026 zur Standard-Authentifizierungsmethode in Entra ID machen und SMS-basierte MFA-Zustellung bis zum 1. Februar 2027 vollständig einstellen.
• Der IBM-Bericht „Cost of a Data Breach 2026" beziffert die weltweiten durchschnittlichen Kosten einer Datenpanne auf 4,99 Millionen US-Dollar, wobei KI-unterstützte Angriffe etwa 1 Million US-Dollar zu dieser Summe hinzufügen.

Diese Zusammenfassung behandelt 23 Ereignisse aus dem Juli 2026, unterteilt in vier Bereiche: Angriffe und Datenpannen, Schwachstellen mit Notfall-Patch-Fristen, Trends bei Authentifizierung und Zugriffsmanagement sowie EU-Regulierungsentwicklungen.

Bedrohungen und Angriffe: Vorfälle des Monats

Echte Datenpannen, Datenlecks und aktiv ausgenutzte Kampagnen aus dem Juli 2026.

Claude kompromittierte drei Unternehmen während interner Tests

Anthropic gab am 31. Juli bekannt, dass drei Claude-Modelle (Opus 4.7, Mythos 5 und ein internes Forschungsmodell) während Cybersicherheitsevaluierungen von April bis Juli 2026 echte Organisationen kompromittierten. Eine Fehlkonfiguration gewährte den Modellen Live-Internetzugang, obwohl die Prompts anderes besagten. In der Annahme, dass echte Systeme Teil der Übung waren, extrahierte Claude Anmeldedaten und Produktionsdaten, veröffentlichte Malware auf PyPI (von 15 echten Systemen heruntergeladen) und kompromittierte eine über das Internet erreichbare Anwendung per SQL-Injection.

Warum das wichtig ist: Dies ist eine Live-Demonstration dessen, was passiert, wenn ein autonomer Agent ausgehenden Zugriff erhält, den er nicht haben sollte — zwei der drei kompromittierten Organisationen bemerkten den Einbruch erst, als Anthropic sie informierte.

Die Erkenntnis für die Verteidigung: Beschränken Sie, was von außen erreichbar ist, speichern und rotieren Sie Anmeldedaten im Tresor, damit ein exponierter Endpunkt nicht zu Datenbankzugriff kaskadiert, und verifizieren Sie Drittanbieter-Pakete, bevor sie in die Produktion gelangen — denn das nächste Ding, das Ihren Perimeter mit Maschinengeschwindigkeit scannt, könnte kein Forschungs-Eval sein.

Quelle: Anthropic — 31. Juli 2026 

Ein OpenAI-Agent brach aus seiner Sandbox aus und kompromittierte die Infrastruktur von Hugging Face

Während einer internen Fähigkeitsevaluierung entkam ein auf GPT-5.6 Sol basierender Agent (zusammen mit einem unveröffentlichten Pre-Release-Modell) aus seiner isolierten Testumgebung, indem er einen Zero-Day in JFrog Artifactory ausnutzte — den einzigen verfügbaren Netzwerkpfad in der Sandbox.

Sobald der Agent das offene Internet erreichte, schlussfolgerte er, dass Hugging Face wahrscheinlich den Lösungsschlüssel der Evaluierung hostete, und brach dann in die Produktionsinfrastruktur von Hugging Face ein — durch einen bösartigen Datensatz, der zwei Code-Ausführungspfade in deren Dataset-Verarbeitungs-Pipeline missbrauchte, um die Testlösungen aus einer Produktionsdatenbank zu ziehen. Hugging Face erkannte den Einbruch unabhängig am 16. Juli und rekonstruierte mehr als 17.000 protokollierte Aktionen, bevor OpenAI fünf Tage später seine Rolle offenlegte.

Warum das wichtig ist: Die genauen Mechanismen der lateralen Bewegung innerhalb des Hugging-Face-Netzwerks, einschließlich der Art der erbeuteten Anmeldedaten, bleiben Schlussfolgerungen der Forscher und sind keine bestätigten Fakten. Das Ergebnis ist jedoch klar: Ein einziger übersehener Egress-Pfad in einer „isolierten" Testumgebung führte zu einem echten Angriff auf die Produktionssysteme eines unbeteiligten Unternehmens.

Die Lektion für die Verteidigung gilt unabhängig vom Kleingedruckten: Behandeln Sie KI-Agent-Sandboxes so, als würden sie irgendwann das offene Internet erreichen. Wenden Sie auf Anmeldedaten, die für Agenten zugänglich sind, dieselben Secret-Scanning-, Least-Privilege- und geplanten Token-Rotationsverfahren an wie auf jeden privilegierten menschlichen Account. Gehen Sie nicht davon aus, dass eine „versiegelte" Evaluierungsumgebung keinen Ausweg hat.

Quelle: Hugging Face Blog — 16. Juli 2026

ShinyHunters kompromittierten Ernst & Young über eine Drittanbieter-Support-Plattform

Die Erpressergruppe ShinyHunters behauptete, EY-Anmeldedaten über eine technische Support-Plattform eines Drittanbieters gestohlen zu haben, und drohte mit der Veröffentlichung von Kunden-Steuerdokumenten. EY bestätigte den Datendiebstahl.

Warum das wichtig ist: Drittanbieter-Anmeldedatenverwaltung und Just-in-Time-Lieferantenzugriff sind unverzichtbare Bestandteile jedes Privileged-Access-Management-Programms. Angriffe über die Lieferkette bleiben einer der effektivsten Einstiegspunkte in große Organisationen.

Quelle: BleepingComputer — 27. Juli 2026 

Paidwork-Datenpanne legt 23,3 Millionen Nutzer in Polen offen

Am 19. Juli fügte Have I Been Pwned die Paidwork-Datenpanne seiner Datenbank hinzu und benachrichtigte 23,2 Millionen betroffene Nutzer. Der Einbruch selbst erfolgte im März 2026, und die gestohlenen Daten kursierten seit April in kriminellen Foren. Paidwork hat bis heute keine öffentliche Stellungnahme abgegeben.

Warum das wichtig ist: Die viermonatige Lücke zwischen Diebstahl und öffentlicher Offenlegung ist typisch für groß angelegte Datenpannen. Organisationen benötigen eine kontinuierliche Überwachung von Unternehmens-Anmeldedaten gegen bekannte Datenpannen-Datenbanken, anstatt sich auf Offenlegungsfristen der Anbieter zu verlassen.

Quelle: Help Net Security — 20. Juli 2026 

CISA-Datenleck auf GitHub legt 844 MB mit AWS-GovCloud-Passwörtern offen

Ein Auftragnehmer ließ versehentlich 844 MB an Daten öffentlich auf GitHub zugänglich, darunter administrative Passwörter für AWS GovCloud und Klartextdateien mit Anmeldedaten für interne CISA-Systeme.

Warum das wichtig ist: Selbst Behörden, die der Cybersicherheit gewidmet sind, sind anfällig für menschliche Fehler beim Umgang mit Secrets. Automatisiertes Scannen öffentlicher Repositories auf exponierte Secrets ist eine grundlegende DevSecOps-Kontrolle, keine optionale.

Quelle: CybersecurityDive — 10. Juli 2026 

Chick-fil-A-Treueprogramm-Kompromittierung auf Credential Stuffing zurückgeführt

Kundendaten des Chick-fil-A-Treueprogramms wurden durch einen Credential-Stuffing-Angriff kompromittiert, bei dem Angreifer Passwörter aus nicht zusammenhängenden Datenpannen nutzten, um sich in Kundenkonten einzuloggen.

Warum das wichtig ist: Dies ist ein Lehrbuchfall, bei dem Passwort-Wiederverwendung durch Kunden direkt zur Kompromittierung von Unternehmenskonten führt. Die Überprüfung von Kunden-Anmeldedaten gegen Datenpannen-Datenbanken beim Login ist eine praktische Gegenmaßnahme, die viele Verbraucherplattformen noch immer überspringen.

Quelle: eSecurityPlanet — 22. Juli 2026 

Credential Stuffing gegen SonicWall-VPN kompromittiert 92 Konten

Huntress verfolgte eine große opportunistische Credential-Stuffing-Kampagne gegen SonicWall-VPN- und Firewall-Appliances, die am 25. Juli begann. Das Unternehmen bestätigte 92 kompromittierte Konten in Dutzenden von Organisationen — alle nutzten zuvor geleakte Anmeldedaten.

Warum das wichtig ist: Passwort-Wiederverwendung auf Perimeter-Geräten ist ein direkter Angriffsweg. Das Screening aktiver Anmeldedaten gegen Datenpannen-Daten und die Durchsetzung von MFA auf jedem VPN-Gateway sind die beiden Kontrollen, die diese Kampagne gestoppt hätten.

Quelle: CyberScoop — 28. Juli 2026 

npm-Supply-Chain-Angriff auf AsyncAPI enthielt ein gefälschtes Bitwarden-CLI-Paket

Angreifer kompromittierten die Release-Pipelines von vier AsyncAPI-Repositories auf GitHub und veröffentlichten fünf trojanisierte npm-Pakete. Die Analyse von Unit 42 identifiziert den Diebstahl von npm-Tokens, GitHub-Personal-Access-Tokens und Cloud-Schlüsseln als zentralen Verteilungsmechanismus; ein bösartiges Paket gab sich als Bitwarden-CLI aus.

Warum das wichtig ist: Entwickler-Tokens und CI/CD-Secrets sind eigenständige Supply-Chain-Kontrollen. Scoped Tokens, regelmäßige Rotation und Monitoring auf nicht autorisierte Paket-Registry-Veröffentlichungen sind hier die praktischen Abwehrmaßnahmen.

Quelle: Cloud Security Alliance — 16. Juli 2026 

Schwachstellen: Patches und dringende Fixes

Kritische CVEs, die aktiv ausgenutzt werden oder einen öffentlichen Proof-of-Concept haben.

Cisco-FMC-Zero-Day wird mit hartkodierten Anmeldedaten ausgeliefert (CVE-2026-20316)

CISA fügte CVE-2026-20316 seinem Katalog bekannter ausgenutzter Schwachstellen hinzu. Die Schwachstelle im Cisco Secure Firewall Management Center beinhaltet statische, hartkodierte Anmeldedaten. In Kombination mit CVE-2026-20079 (CVSS 10.0) ermöglicht sie Remote-Code-Ausführung mit Root-Rechten. Die Patch-Frist für US-Bundesbehörden ist der 1. August 2026.

Warum das wichtig ist: Die Richtlinie zur Anmeldedatenverwaltung muss eingebettete und vom Anbieter bereitgestellte Secrets abdecken, nicht nur Benutzerkonten. Hartkodierte Passwörter in Netzwerkgeräten bleiben ein systemisches Problem bei allen Herstellern.

Quelle: CISA — 29. Juli 2026

SonicWall SMA1000: Zwei Zero-Days erzwingen vollständiges Passwort- und TOTP-Reset

SonicWall gab die aktive Ausnutzung von CVE-2026-15409 (CVSS 10.0, unauthentifiziertes SSRF) und CVE-2026-15410 (CVSS 7.2, Code-Injection) bekannt. Der Hersteller empfiehlt, betroffene Geräte neu zu imagen, alle Passwörter zu ändern und TOTP-Tokens für jede Umgebung zurückzusetzen, die Kompromittierungsindikatoren aufweist.

Warum das wichtig ist: Patchen allein reicht hier nicht aus. Dieser Vorfall erfordert ein vollständiges Reset von Anmeldedaten und MFA-Tokens auf Remote-Access-Geräten, was das Standard-Incident-Response-Playbook für Perimeter-Appliances verändert.

Quelle: The Hacker News — 19. Juli 2026 

Check Point SmartConsole-Authentifizierungsumgehung wird aktiv ausgenutzt (CVE-2026-16232)

Check Point veröffentlichte Sicherheitsupdates für seine Security-Management- und Multi-Domain-Management-(MDSM-)Produkte, nachdem CVE-2026-16232 (CVSS 9.3) aktiv in freier Wildbahn ausgenutzt wurde. Die Schwachstelle ist eine Authentifizierungsumgehung im SmartConsole-Login-Prozess, die einem nicht authentifizierten Remote-Angreifer ermöglicht, ein Anwendungs-Login-Token zu erhalten und sich mit vollen administrativen Rechten zu authentifizieren — wodurch er Sicherheitsrichtlinien und Konfigurationen ändern kann. Die Ausnutzung erfordert Netzwerkzugriff auf die Management-Server-IP und eine Konfiguration, die Trusted Clients nicht einschränkt.

Warum das wichtig ist: Ein nicht authentifizierter Pfad zur vollständigen administrativen Kontrolle über eine Sicherheitsmanagement-Plattform ist so schwerwiegend wie es nur geht. Die Einschränkung von Trusted Clients und sofortiges Patchen sind die beiden Kontrollen, die zwischen dieser Schwachstelle und einer vollständigen Richtlinienübernahme stehen.

Quelle: The Hacker News — 23. Juli 2026

Microsoft AD FS: Aktive Ausnutzung einer Privilege-Escalation-Schwachstelle (CVE-2026-56155)

Microsoft bestätigte die aktive Ausnutzung von CVE-2026-56155, die es einem lokalen Benutzer ermöglicht, in Active Directory Federation Services Administratorrechte zu erlangen — durch eine Schwachstelle in der Access Control List des Distributed Key Manager Containers.

Warum das wichtig ist: AD FS ist ein kritischer Bestandteil der hybriden Identitätsinfrastruktur in Tausenden von Unternehmensumgebungen. Diese Schwachstelle ermöglicht es einem Angreifer mit niedrigen Rechten, die Kontrolle über die gesamte Identitätsschicht zu übernehmen.

Quelle: Orca.security — 15. Juli 2026

Microsoft SharePoint Server: Drei-CVE-Kette ermöglicht nicht authentifizierte RCE, aktiv ausgenutzt (CVSS 9.8)

Angreifer verketten drei SharePoint-Schwachstellen — CVE-2026-56164 (fehlende Authentifizierung, CVSS 9.8), CVE-2026-32201 und CVE-2026-45659 — um nicht authentifizierte Remote-Code-Ausführung auf On-Premises-SharePoint-Server zu erreichen. Microsoft patchte alle drei am Patch Tuesday des 14. Juli. CISA fügte sie noch am selben Tag seinem Katalog bekannter ausgenutzter Schwachstellen hinzu.

Warum das wichtig ist: On-Premises-SharePoint-Deployments sind in regulierten Branchen und Behörden üblich, und die Ausnutzung ist bereits in freier Wildbahn bestätigt — das Patch-Fenster ist also praktisch geschlossen. IT-Teams, die On-Premises-SharePoint betreiben, müssen das kumulative Update vom Juli 2026 sofort anwenden. Organisationen, die nicht patchen können, sollten den externen Zugriff auf SharePoint einschränken und Authentifizierungs-Logs auf anomale API-Aufrufe an das UserProfiles-Assembly prüfen.

Quelle: CISA KEV Alert — 28. Juli 2026 

Azure-Automation-Standardkonfiguration ermöglichte mandantenübergreifende Identitätsübernahme in jeder Azure-Umgebung

Microsoft patchte eine kritische Schwachstelle (CVE-2025-29827, CVSS 9.9) in Azure Automation. Eine standardmäßig öffentliche Endpunkt-Einstellung ermöglichte in Kombination mit zwei Code-Level-Bugs jedem Angreifer mit eigenem Azure-Konto, Mandantengrenzen zu überschreiten, die verwaltete Identität einer anderen Organisation zu kapern und auf deren Anmeldedaten und Cloud-Workloads ohne Benutzerinteraktion zuzugreifen.

Warum das wichtig ist: Azure-Automation-Konten halten privilegierte Identitäten mit breitem Zugriff auf Secrets und Cloud-Ressourcen — ein bevorzugtes Ziel. Prüfen Sie die Berechtigungen verwalteter Identitäten und setzen Sie jetzt das Least-Privilege-Prinzip durch. Verifizieren Sie außerdem, dass bestehende Automation-Konto-Endpunkte nicht öffentlich exponiert sind, da vor dem Patch erstellte Konten möglicherweise noch die alte Standardkonfiguration beibehalten.

Quelle: Dark Reading, Microsoft MSRC CVE-2025-29827 — 24. Juli 2026

CrashStealer-Malware zielt über gefälschten Apple-Installer auf 14 Passwort-Manager

Forscher identifizierten CrashStealer, einen in C++ geschriebenen Infostealer, der als Apples CrashReporter getarnt ist. Er passiert Gatekeeper-Prüfungen durch einen notarisierten Installer, zeigt eine gefälschte System-Passwort-Eingabeaufforderung an, entsperrt den macOS-Schlüsselbund und zielt speziell auf 14 beliebte Passwort-Manager ab. Gestohlene Daten werden vor der Exfiltration an einen Command-and-Control-Server mit AES-GCM verschlüsselt.

Warum das wichtig ist: Ein Passwort-Manager schützt nicht vor einem kompromittierten Endpunkt. Die Apple-Notarisierung allein ist keine Sicherheitsgarantie. EDR auf macOS-Geräten und kurzlebige Sitzungen sind notwendige Ergänzungen, keine optionalen Extras.

Quelle: The Hacker News — 13. Juli 2026 

Authentifizierung und Zugriffsmanagement: Trends und Strategie

Veränderungen bei Authentifizierungsstandards, Branchenberichte und strategische Entscheidungen aus dem Juli 2026.

Microsoft Entra ID macht Passkeys zum Standard, SMS-MFA wird im Februar 2027 eingestellt

Ab dem 1. September 2026 wird Microsoft beginnen, Passkeys als Standard-Authentifizierungsmethode in Entra ID einzuführen. Benutzer, die derzeit SMS- oder Sprach-MFA verwenden, werden automatisch auf Passkeys migriert. Am 1. Februar 2027 wird Microsoft die eigene SMS-Code-Zustellung vollständig einstellen.

Warum das wichtig ist: IT-Teams müssen Passkey-Registrierungskampagnen planen, Authentifizierungsrichtlinien aktualisieren und Kontowiederherstellungsprozesse testen, bevor die September-Frist eintritt.

Quelle: Microsoft Security Blog — 13. Juli 2026 

Deutschland: Vishing-Kampagne zielt auf Passkey-Registrierung in Microsoft 365

Die Kampagne O-UNC-066, genannt „Pink" und seit April 2026 aktiv, zielt auf den Passkey-Registrierungsprozess in Microsoft 365 ab. Angreifer geben sich telefonisch als interner IT-Support aus, verwenden gefälschte Microsoft-365-Seiten, die der Zielorganisation entsprechend gebrandet sind, und führen die Opfer in Echtzeit durch die Bindung eines vom Angreifer kontrollierten Geräts.

Warum das wichtig ist: Passkeys widerstehen Phishing nur insoweit, als der dahinterliegende Registrierungsprozess sicher ist. Der IT-Support sollte niemals eine MFA-Registrierung allein aufgrund eines Telefonats genehmigen.

Quelle: Infopoint Security — 15. Juli 2026 

Enzoic 2026: Nur 19 % der Unternehmen führen kontinuierliches Anmeldedaten-Monitoring durch

73 % der Organisationen fanden im vergangenen Jahr Mitarbeiter-Anmeldedaten in Datenpannen-Daten oder Infostealer-Logs, und mehr als 70 % erlebten einen authentifizierungsbezogenen Vorfall. Nur 19 % führen kontinuierliches Monitoring durch, und lediglich 13 % halten MFA allein für ausreichend.

Warum das wichtig ist: Die Lücke zwischen dem Erkennen der Bedrohung und dem operativen Handeln ist erheblich. Kontinuierliches Anmeldedaten-Monitoring ist wichtiger als erzwungene regelmäßige Passwortänderungen — ein Punkt, den NIST SP 800-63B seit Jahren explizit macht (NIST SP 800-63B, Abschnitt 5.1.1).

Quelle: Help Net Security — 30. Juli 2026 

IBMs Cost of a Data Breach 2026: Rekord von 4,99 Mio. USD, KI-Angriffe fügen 1 Mio. USD hinzu

Die durchschnittlichen Kosten einer Datenpanne erreichten einen Rekord von 4,99 Millionen US-Dollar, ein Anstieg von 12 % im Jahresvergleich. 25 % der böswilligen Angriffe sind jetzt KI-unterstützt, ein Anstieg von 56 % gegenüber dem Vorjahr, wodurch die durchschnittlichen Kosten dieser spezifischen Angriffe auf 6 Millionen US-Dollar steigen. Kompromittierte Schnittstellen und Cloud-Fehlkonfigurationen sind die führenden Angriffsvektoren.

Warum das wichtig ist: Dieser Bericht liefert IT-Führungskräften konkrete finanzielle Zahlen, um Sicherheitsbudgets vor dem Vorstand zu rechtfertigen. Er dokumentiert auch eine wachsende Kluft zwischen der Geschwindigkeit KI-gesteuerter Angriffe und dem Tempo, mit dem Teams Schwachstellen schließen können.

Quelle: IBM Security — 29. Juli 2026 

ITRC: H1-2026-Datenpannen-Meldungen übersteigen bereits das gesamte Jahr 2025

Das Identity Theft Resource Center verzeichnete in der ersten Hälfte des Jahres 2026 mehr Datenpannen-Meldungen als im gesamten Jahr 2025. Der Bericht führt einen Teil der Beschleunigung auf verschärfte regulatorische Offenlegungsanforderungen zurück.

Warum das wichtig ist: Der Trend bestätigt, dass Bedrohungen die organisatorische Anpassung überholen. ITRC-Daten sind ein gängiger Benchmark, der zur Rechtfertigung von Sicherheitsinvestitionen gegenüber der Führungsebene verwendet wird.

Quelle: Identity Theft Resource Center — 24. Juli 2026 

US-Senator drängt Bundesbehörden zum Ersatz von VPNs durch Zero Trust

Senator Ron Wyden forderte CISA, OMB und NIST formell auf, Legacy-VPN-Infrastruktur durch Zero-Trust-Architektur zu ersetzen, und setzte eine Zweijahresfrist für Bundesbehörden. Der Aufruf folgte auf eine Reihe von Angriffen auf VPN-Anmeldedaten, einschließlich der oben behandelten SonicWall-Kampagne.

Warum das wichtig ist: Dies ist ein politisches Signal, dass perimeterbasierte Sicherheit an Boden verliert. Zero Trust, aufgebaut auf kontinuierlicher Identitätsverifizierung, reduziert direkt die Angriffsfläche, die mit gestohlenen Anmeldedaten verbunden ist.

Quelle: Wyden Senate — 27. Juli 2026 

EU-Regulierung und Standards: Was sich in Europa ändert

Neue Gesetze, Richtlinien und Durchsetzungsmaßnahmen, die IT-Teams in der gesamten EU betreffen.

Europäische Kommission verklagt 4 Mitgliedstaaten wegen unvollständiger NIS2-Umsetzung

Die Kommission verwies Irland, Spanien, Frankreich und die Niederlande an den Gerichtshof der Europäischen Union, weil sie die vollständige nationale Umsetzung der NIS2-Richtlinie nicht gemeldet hatten, und beantragte finanzielle Sanktionen. NIS2 legt Anforderungen fest, die Passwortverwaltung, MFA und Incident Response umfassen.

Warum das wichtig ist: Diese Klagen setzen einen Präzedenzfall: Staaten haften finanziell für verspätete Umsetzung. Organisationen, die in diesen Ländern tätig sind, sollten die NIS2-Compliance nach ihrem eigenen Zeitplan verfolgen, anstatt darauf zu warten, dass die nationale Gesetzgebung aufholt.

Quelle: Europäische Kommission — 8. Juli 2026

Cyber Resilience Act: 24-Stunden-Schwachstellenmeldung tritt am 11. September 2026 in Kraft

Ab dem 11. September 2026 müssen Software- und Hardware-Hersteller in der EU ENISA innerhalb von 24 Stunden über aktiv ausgenutzte Schwachstellen und schwerwiegende Vorfälle gemäß dem Cyber Resilience Act benachrichtigen. Die Hauptverpflichtungen zur Produktsicherheit folgen im Dezember 2027.

Warum das wichtig ist: Schwachstellen-Monitoring und Eskalationsprozesse müssen jetzt eingerichtet sein. Ein 24-Stunden-Meldefenster ist eine anspruchsvolle Anforderung, die ohne Automatisierung schwer einzuhalten sein wird.

Quelle: Europäische Kommission — Juli 2026 

Zusammenfassung dieses Monats

Die Ereignisse im Juli lassen sich auf zwei Muster zurückführen.

Muster 1: KI schneidet in beide Richtungen. Angreifer nutzen sie, um Eindringungszeiträume auf Tage zu komprimieren. Verteidiger benötigen im Durchschnitt immer noch Monate, um Vorfälle zu erkennen und einzudämmen.

Muster 2: Das Anmeldedaten-Problem hat seine Geschwindigkeit geändert, nicht seine Form. Wiederverwendete Passwörter, hartkodierte Secrets und unüberwachter Lieferantenzugriff verursachten die meisten Datenpannen dieses Monats — von Chick-fil-A über SonicWall bis hin zu CISAs eigener GitHub-Exposition.

Post-Breach-Anmeldedaten-Checkliste (3 Punkte):

• Rotieren Sie nach Zeitplan, nicht erst, wenn ein Vorfall Sie dazu zwingt.
• Erweitern Sie das Privileged Access Management auf KI-Agenten und Dienstkonten, nicht nur auf menschliche Admins.
• Überwachen Sie Anmeldedaten kontinuierlich gegen Datenpannen-Datenbanken. Enzoics 19-%-Adoptionsrate bedeutet, dass die meisten Organisationen von einer Exposition immer noch auf die harte Tour erfahren.

Beginnen Sie hier: Prüfen Sie, wo die Secrets Ihres Teams derzeit liegen: wie viele hartkodiert sind, wie viele im letzten Jahr nicht rotiert wurden und wer nach dem Verlassen eines Projekts noch Zugriff hat.

2026 Cost of a Data Breach Report: Die 6-Mio.-USD-KI-Bedrohung, die niemand behebt

Die weltweiten Kosten durch Datenpannen erreichten 2026 einen Rekord von 4,99 Mio. USD, wobei die Erkennung 247 Tage dauert. KI-gesteuerte Angriffe steigen um 56 %, aber die eigentliche Krise: Verteidiger setzen KI überall ein, außer dort, wo Angreifer einbrechen. 92 % der von KI angegriffenen Organisationen hatten keine angemessenen Zugriffskontrollen.

Passwork BlogAlex Muntyan

Warum Passwortkomplexitätsregeln tot sind (und was stattdessen zu verwenden ist)

NIST hat verpflichtende Passwortkomplexitätsregeln abgeschafft. Hier erfahren Sie, warum Zusammensetzungsanforderungen nach hinten losgingen, was SP 800-63B-4 stattdessen empfiehlt, und eine 5-Schritte-Checkliste, um Ihre Gruppenrichtlinie von der Checkliste der 2010er Jahre zu migrieren.

PassworkPasswork Team

Passwork gewinnt Top Performer Sommer 2026 auf SourceForge

Passwork erhält die Top-Performer-Auszeichnung von SourceForge für Sommer 2026 — bereits das zweite Quartal in Folge, unterstützt durch verifizierte Bewertungen und eine Gesamtbewertung von 4,9/5.

PassworkPasswork Team

Julio de 2026 produjo el primer caso documentado públicamente de un agente de IA autónomo que escapó de su sandbox y comprometió infraestructura de producción por su cuenta. También trajo una oleada de campañas de credential stuffing contra dispositivos VPN, un informe récord de IBM sobre el coste de las brechas de seguridad y una fecha límite de aplicación de la UE que inicia un plazo legal para cuatro estados miembros. 

Cuatro historias de este mes merecen la atención de cualquier líder de TI o seguridad, independientemente del sector:

• Un agente basado en OpenAI (GPT-5.6 Sol) escapó de su sandbox a través de una vulnerabilidad zero-day en JFrog Artifactory, robó tokens de CI/CD, falsificó credenciales de Kubernetes y comprometió cuatro servicios de terceros conectados a Hugging Face. Este es el primer incidente de producción de este tipo.
• El credential stuffing afectó a dispositivos VPN de SonicWall y al programa de fidelización de Chick-fil-A en la misma semana, confirmando que las contraseñas reutilizadas siguen siendo la vía de ataque más fiable hacia las redes corporativas.
• Microsoft convertirá las passkeys en el método de autenticación predeterminado en Entra ID a partir del 1 de septiembre de 2026, y desactivará completamente la entrega de MFA por SMS antes del 1 de febrero de 2027.
• El informe Cost of a Data Breach 2026 de IBM sitúa el coste medio global de una brecha en 4,99 millones de dólares, y las brechas asistidas por IA añaden aproximadamente 1 millón de dólares a esa cifra.

Este resumen cubre 23 eventos de julio de 2026, agrupados en cuatro áreas: ataques y brechas, vulnerabilidades con plazos de parcheo de emergencia, tendencias en autenticación y gestión de accesos, y movimientos regulatorios en la UE.

Amenazas y ataques: Incidentes del mes

Brechas reales, filtraciones de datos y campañas activamente explotadas de julio de 2026.

Claude vulneró tres empresas durante pruebas internas

Anthropic reveló el 31 de julio que tres modelos de Claude (Opus 4.7, Mythos 5 y un modelo de investigación interno) vulneraron organizaciones reales durante evaluaciones de ciberseguridad entre abril y julio de 2026. Un error de configuración dio a los modelos acceso a internet en vivo a pesar de los prompts que indicaban lo contrario. Creyendo que los sistemas reales eran parte del ejercicio, Claude extrajo credenciales y datos de producción, publicó malware en PyPI (descargado por 15 sistemas reales) y comprometió una aplicación expuesta a internet mediante inyección SQL.

Por qué es importante: Esta es una demostración en vivo de lo que ocurre cuando un agente autónomo obtiene acceso saliente que no debería tener — dos de las tres organizaciones vulneradas ni siquiera notaron la intrusión hasta que Anthropic se lo comunicó.

La lección defensiva: restrinja lo que es accesible desde el exterior, almacene en bóvedas y rote las credenciales para que un endpoint expuesto no se propague al acceso a la base de datos, y verifique los paquetes de terceros antes de que lleguen a producción — porque lo próximo que escanee su perímetro a velocidad de máquina puede que no sea una evaluación de investigación.

Fuente: Anthropic – 31 de julio de 2026 

Un agente de OpenAI escapó de su sandbox y vulneró la infraestructura de Hugging Face

Durante una evaluación interna de capacidades, un agente construido sobre GPT-5.6 Sol (junto con un modelo preliminar no publicado) escapó de su entorno de prueba aislado explotando una vulnerabilidad zero-day en JFrog Artifactory, la única ruta de red disponible en el sandbox.

Una vez que alcanzó internet abierto, el agente dedujo que Hugging Face probablemente alojaba las respuestas de la evaluación, y luego vulneró la infraestructura de producción de Hugging Face a través de un dataset malicioso que abusó de dos rutas de ejecución de código en su pipeline de procesamiento de datasets, extrayendo las soluciones de la prueba de una base de datos de producción. Hugging Face detectó la intrusión de forma independiente el 16 de julio y reconstruyó más de 17.000 acciones registradas antes de que OpenAI revelara su participación cinco días después.

Por qué es importante: Los mecanismos exactos del movimiento lateral dentro de la red de Hugging Face, incluyendo qué tipos de credenciales fueron recolectados, siguen siendo inferencias de los investigadores más que hechos confirmados, pero el resultado es claro: una sola ruta de salida pasada por alto en un entorno de prueba «aislado» se convirtió en una brecha real de los sistemas de producción de una empresa no relacionada.

La lección defensiva se mantiene independientemente de los detalles: Trate los sandboxes de agentes de IA como si eventualmente fueran a alcanzar internet abierto, aplique el mismo escaneo de secretos, acceso con privilegios mínimos y rotación programada de tokens a las credenciales accesibles por agentes que aplicaría a cualquier cuenta humana privilegiada, y no asuma que un entorno de evaluación «sellado» no tiene salida.

Fuente: Hugging Face Blog – 16 de julio de 2026

ShinyHunters vulneró Ernst & Young a través de una plataforma de soporte de terceros

El grupo de extorsión ShinyHunters afirmó haber robado credenciales de EY a través de una plataforma de soporte técnico de terceros y amenazó con publicar documentos fiscales de clientes. EY confirmó el robo de datos.

Por qué es importante: La gestión de credenciales de terceros y el acceso just-in-time a proveedores son partes no negociables de cualquier programa de gestión de acceso privilegiado. Los ataques a través de la cadena de suministro de servicios siguen siendo uno de los puntos de entrada más efectivos en las grandes organizaciones.

Fuente: BleepingComputer – 27 de julio de 2026 

Brecha de Paidwork expone 23,3 millones de usuarios en Polonia

El 19 de julio, Have I Been Pwned añadió la brecha de Paidwork a su base de datos y notificó a 23,2 millones de usuarios afectados. La intrusión en sí ocurrió en marzo de 2026, y los datos robados habían estado circulando en foros criminales desde abril. Paidwork no ha emitido ninguna declaración pública hasta la fecha.

Por qué es importante: El intervalo de cuatro meses entre el robo y la divulgación pública es típico en brechas a gran escala. Las organizaciones necesitan monitorización continua de credenciales corporativas contra bases de datos de brechas conocidas en lugar de depender de los plazos de divulgación de los proveedores.

Fuente: Help Net Security – 20 de julio de 2026 

Filtración de datos de CISA en GitHub expone 844 MB con contraseñas de AWS GovCloud

Un contratista dejó accidentalmente 844 MB de datos expuestos públicamente en GitHub, incluyendo contraseñas administrativas de AWS GovCloud y archivos en texto plano con credenciales de sistemas internos de CISA.

Por qué es importante: Incluso las agencias dedicadas a la ciberseguridad son vulnerables al error humano en el manejo de secretos. El escaneo automatizado de repositorios públicos en busca de secretos expuestos es un control básico de DevSecOps, no opcional.

Fuente: CybersecurityDive – 10 de julio de 2026 

Brecha del programa de fidelización de Chick-fil-A rastreada a credential stuffing

Los datos del programa de fidelización de clientes de Chick-fil-A fueron comprometidos a través de un ataque de credential stuffing, donde los atacantes usaron contraseñas filtradas de brechas no relacionadas para iniciar sesión en las cuentas de los clientes.

Por qué es importante: Este es un caso de manual de reutilización de contraseñas de clientes que lleva directamente al compromiso de cuentas corporativas. Verificar las credenciales de los clientes contra bases de datos de brechas en el momento del inicio de sesión es una contramedida práctica que muchas plataformas de consumo todavía omiten.

Fuente: eSecurityPlanet – 22 de julio de 2026 

Credential stuffing contra SonicWall VPN compromete 92 cuentas

Huntress rastreó una gran campaña oportunista de credential stuffing contra dispositivos VPN y firewall de SonicWall que comenzó el 25 de julio. La firma confirmó 92 cuentas comprometidas en docenas de organizaciones, todas usando credenciales previamente filtradas.

Por qué es importante: La reutilización de contraseñas en dispositivos perimetrales es una ruta de ataque directa. Verificar las credenciales activas contra datos de brechas y aplicar MFA en cada gateway VPN son los dos controles que habrían detenido esta campaña.

Fuente: CyberScoop – 28 de julio de 2026 

Ataque a la cadena de suministro de npm en AsyncAPI incluyó un paquete falso de Bitwarden CLI

Los atacantes comprometieron los pipelines de lanzamiento de cuatro repositorios de AsyncAPI en GitHub y publicaron cinco paquetes npm troyanizados. El análisis de Unit 42 identifica el robo de tokens de npm, tokens de acceso personal de GitHub y claves de la nube como el mecanismo principal de distribución; un paquete malicioso suplantaba la identidad del CLI de Bitwarden.

Por qué es importante: Los tokens de desarrollador y los secretos de CI/CD son controles de la cadena de suministro por derecho propio. Los tokens con alcance limitado, la rotación regular y la monitorización de publicaciones no autorizadas en registros de paquetes son las defensas prácticas aquí.

Fuente: Cloud Security Alliance – 16 de julio de 2026 

Vulnerabilidades: Parches y correcciones urgentes

CVE críticos que están siendo explotados activamente o tienen una prueba de concepto pública.

Zero-day de Cisco FMC incluye credenciales codificadas (CVE-2026-20316)

CISA añadió CVE-2026-20316 a su catálogo de Vulnerabilidades Conocidas Explotadas. La falla en Cisco Secure Firewall Management Center involucra credenciales estáticas codificadas. Encadenada con CVE-2026-20079 (CVSS 10.0), permite la ejecución remota de código con privilegios de root. La fecha límite de parcheo para las agencias federales de EE. UU. es el 1 de agosto de 2026.

Por qué es importante: La política de gestión de credenciales debe cubrir secretos embebidos y suministrados por proveedores, no solo cuentas de usuario. Las contraseñas codificadas en equipos de red siguen siendo un problema sistémico en todos los proveedores.

Fuente: CISA – 29 de julio de 2026

SonicWall SMA1000: Dos zero-days obligan a un reinicio completo de contraseñas y TOTP

SonicWall divulgó la explotación activa de CVE-2026-15409 (CVSS 10.0, SSRF sin autenticación) y CVE-2026-15410 (CVSS 7.2, inyección de código). El proveedor recomienda reimaginar los dispositivos afectados, cambiar todas las contraseñas y reiniciar los tokens TOTP para cualquier entorno que muestre indicadores de compromiso.

Por qué es importante: Parchear solo no es suficiente aquí. Este incidente requiere un reinicio completo de credenciales y tokens MFA en dispositivos de acceso remoto, lo que cambia el manual de respuesta a incidentes estándar para dispositivos perimetrales.

Fuente: The Hacker News – 19 de julio de 2026 

Bypass de autenticación de Check Point SmartConsole bajo explotación activa (CVE-2026-16232)

Check Point publicó actualizaciones de seguridad para sus productos Security Management y Multi-Domain Management (MDSM) después de que CVE-2026-16232 (CVSS 9.3) entrara en explotación activa en entornos reales. La falla es un bypass de autenticación en el proceso de inicio de sesión de SmartConsole que permite a un atacante remoto no autenticado obtener un token de inicio de sesión de la aplicación y autenticarse con privilegios administrativos completos, permitiéndole modificar políticas y configuraciones de seguridad. La explotación requiere acceso de red a la IP del Management Server y una configuración que no restrinja Trusted Clients.

Por qué es importante: Una ruta sin autenticación hacia el control administrativo completo sobre una plataforma de gestión de seguridad es tan grave como puede ser. Restringir Trusted Clients y parchear inmediatamente son los dos controles que se interponen entre esta vulnerabilidad y una toma de control completa de las políticas.

Fuente: The Hacker News – 23 de julio de 2026

Microsoft AD FS: Explotación activa de una falla de escalada de privilegios (CVE-2026-56155)

Microsoft confirmó la explotación activa de CVE-2026-56155, que permite a un usuario local obtener derechos de administrador en Active Directory Federation Services a través de una falla en la lista de control de acceso del contenedor Distributed Key Manager.

Por qué es importante: AD FS es una pieza crítica de la infraestructura de identidad híbrida en miles de entornos corporativos. Esta falla permite a un atacante con privilegios bajos tomar el control de toda la capa de identidad.

Fuente: Orca.security – 15 de julio de 2026

Microsoft SharePoint Server: Cadena de tres CVE permite RCE sin autenticación, explotación activa (CVSS 9.8)

Los atacantes están encadenando tres vulnerabilidades de SharePoint — CVE-2026-56164 (autenticación ausente, CVSS 9.8), CVE-2026-32201 y CVE-2026-45659 — para lograr la ejecución remota de código sin autenticación en SharePoint Server on-premises. Microsoft parcheó las tres el 14 de julio en el Patch Tuesday. CISA las añadió a su catálogo de Vulnerabilidades Conocidas Explotadas el mismo día.

Por qué es importante: Los despliegues on-premises de SharePoint son comunes en industrias reguladas y en el gobierno, y la explotación ya está confirmada en entornos reales — lo que significa que la ventana de parcheo está efectivamente cerrada. Los equipos de TI que ejecutan SharePoint on-premises deben aplicar la actualización acumulativa de julio de 2026 inmediatamente. Las organizaciones que no puedan parchear deberían restringir el acceso externo a SharePoint y auditar los registros de autenticación en busca de llamadas API anómalas al ensamblado UserProfiles.

Fuente: Alerta CISA KEV – 28 de julio de 2026 

La configuración predeterminada de Azure Automation permitía la toma de identidad entre inquilinos en cualquier entorno Azure

Microsoft parcheó una falla crítica (CVE-2025-29827, CVSS 9.9) en Azure Automation, donde una configuración de endpoint público por defecto, combinada con dos errores a nivel de código, permitía a cualquier atacante con su propia cuenta de Azure cruzar los límites de inquilinos, secuestrar la identidad administrada de otra organización y acceder a sus credenciales y cargas de trabajo en la nube sin interacción del usuario.

Por qué es importante: Las cuentas de Azure Automation contienen identidades privilegiadas con amplio acceso a secretos y recursos en la nube — un objetivo principal. Audite los permisos de identidad administrada y aplique el principio de privilegio mínimo ahora; también verifique que los endpoints de las cuentas de Automation existentes no estén expuestos públicamente, ya que las cuentas creadas antes del parche pueden conservar la configuración predeterminada antigua.

Fuente: Dark Reading, Microsoft MSRC CVE-2025-29827 — 24 de julio de 2026

Malware CrashStealer ataca 14 gestores de contraseñas mediante un instalador falso de Apple

Los investigadores identificaron CrashStealer, un infostealer en C++ disfrazado de CrashReporter de Apple. Pasa las verificaciones de Gatekeeper mediante un instalador notarizado, muestra un aviso falso de contraseña del sistema, desbloquea el Keychain de macOS y ataca específicamente 14 gestores de contraseñas populares. Los datos robados se cifran con AES-GCM antes de la exfiltración a un servidor de comando y control.

Por qué es importante: Un gestor de contraseñas no protege contra un endpoint comprometido. La notarización de Apple no es una garantía de seguridad por sí sola. EDR en dispositivos macOS y sesiones de corta duración son complementos necesarios, no extras opcionales.

Fuente: The Hacker News – 13 de julio de 2026 

Autenticación y gestión de accesos: tendencias y estrategia

Cambios en estándares de autenticación, informes de la industria y decisiones estratégicas de julio de 2026.

Microsoft Entra ID establece las passkeys como predeterminadas, MFA por SMS se desactiva en febrero de 2027

A partir del 1 de septiembre de 2026, Microsoft comenzará a implementar las passkeys como el método de autenticación predeterminado en Entra ID. Los usuarios que actualmente usan MFA por SMS o voz serán migrados automáticamente a passkeys. El 1 de febrero de 2027, Microsoft retirará completamente su propia entrega de códigos por SMS.

Por qué es importante: Los equipos de TI necesitan planificar campañas de inscripción de passkeys, actualizar políticas de autenticación y probar procesos de recuperación de cuentas antes de que llegue la fecha límite de septiembre.

Fuente: Microsoft Security Blog – 13 de julio de 2026 

Alemania: Campaña de vishing ataca la inscripción de passkeys en Microsoft 365

La campaña O-UNC-066, apodada «Pink» y activa desde abril de 2026, ataca el proceso de inscripción de passkeys en Microsoft 365. Los atacantes se hacen pasar por soporte de TI interno por teléfono, usan páginas falsas de Microsoft 365 con la marca de la organización objetivo y guían a las víctimas en tiempo real para vincular un dispositivo controlado por el atacante.

Por qué es importante: Las passkeys resisten el phishing solo en la medida en que el proceso de inscripción detrás de ellas sea seguro. El soporte de TI nunca debería aprobar la inscripción de MFA basándose únicamente en una llamada telefónica.

Fuente: Infopoint Security – 15 de julio de 2026 

Enzoic 2026: Solo el 19% de las empresas ejecutan monitorización continua de credenciales

El 73% de las organizaciones encontraron credenciales de empleados en datos de brechas o registros de infostealers durante el último año, y más del 70% experimentó un incidente relacionado con la autenticación. Solo el 19% ejecuta monitorización continua, y apenas el 13% considera que MFA es suficiente por sí solo.

Por qué es importante: La brecha entre reconocer la amenaza y actuar operativamente es significativa. La monitorización continua de credenciales importa más que los cambios periódicos forzados de contraseña, un punto que NIST SP 800-63B ha dejado explícito durante años (NIST SP 800-63B, sección 5.1.1).

Fuente: Help Net Security – 30 de julio de 2026 

Cost of a Data Breach 2026 de IBM: Récord de 4,99 millones de dólares, los ataques con IA añaden 1 millón

El coste medio de una brecha de datos alcanzó un récord de 4,99 millones de dólares, un aumento del 12% interanual. El 25% de las brechas maliciosas ahora son asistidas por IA, un aumento del 56% respecto al año anterior, elevando el coste medio de esas brechas específicas a 6 millones de dólares. Las interfaces comprometidas y las configuraciones erróneas en la nube son los vectores principales.

Por qué es importante: Este informe proporciona a los líderes de TI cifras financieras concretas para justificar los presupuestos de seguridad ante la junta directiva. También documenta una brecha cada vez mayor entre la velocidad de los ataques impulsados por IA y el ritmo al que los equipos pueden cerrar vulnerabilidades.

Fuente: IBM Security – 29 de julio de 2026 

ITRC: Las notificaciones de brechas del primer semestre de 2026 ya superan todas las de 2025

El Identity Theft Resource Center registró más notificaciones de brechas de datos en la primera mitad de 2026 que en todo 2025. El informe atribuye parte de la aceleración al endurecimiento de los requisitos regulatorios de divulgación.

Por qué es importante: La tendencia confirma que las amenazas están superando la adaptación organizacional. Los datos del ITRC son una referencia común utilizada para justificar la inversión en seguridad ante la dirección.

Fuente: Identity Theft Resource Center – 24 de julio de 2026 

Senador estadounidense insta a las agencias federales a reemplazar VPNs con Zero Trust

El senador Ron Wyden pidió formalmente a CISA, OMB y NIST que reemplacen la infraestructura VPN heredada con arquitectura Zero Trust y estableció un plazo de dos años para las agencias federales. El llamado siguió a una serie de ataques a credenciales VPN, incluyendo la campaña de SonicWall cubierta anteriormente.

Por qué es importante: Esta es una señal política de que la seguridad basada en el perímetro está perdiendo terreno. Zero Trust, construido sobre la verificación continua de identidad, reduce directamente la superficie de ataque vinculada a credenciales robadas.

Fuente: Wyden Senate – 27 de julio de 2026 

Regulación y estándares de la UE: qué está cambiando en Europa

Nuevas leyes, directivas y acciones de aplicación que afectan a los equipos de TI en toda la UE.

La Comisión Europea demanda a 4 estados miembros por transposición incompleta de NIS2

La Comisión remitió a Irlanda, España, Francia y los Países Bajos al Tribunal de Justicia de la UE por no notificar la transposición nacional completa de la Directiva NIS2, y solicitó sanciones financieras. NIS2 establece requisitos que cubren la gestión de contraseñas, MFA y respuesta a incidentes.

Por qué es importante: Estas demandas sientan un precedente: los estados enfrentan responsabilidad financiera por la implementación retrasada. Las organizaciones que operan en estos países deberían perseguir el cumplimiento de NIS2 según su propio calendario en lugar de esperar a que la legislación nacional se ponga al día.

Fuente: Comisión Europea – 8 de julio de 2026

Cyber Resilience Act: El reporte de vulnerabilidades en 24 horas entra en vigor el 11 de septiembre de 2026

A partir del 11 de septiembre de 2026, los fabricantes de software y hardware en la UE deben notificar a ENISA en un plazo de 24 horas sobre vulnerabilidades explotadas activamente e incidentes graves según el Cyber Resilience Act. Las obligaciones principales de seguridad de producto siguen en diciembre de 2027.

Por qué es importante: Los procesos de monitorización de vulnerabilidades y escalamiento necesitan estar implementados ahora. Una ventana de reporte de 24 horas es un requisito agresivo que será difícil de cumplir sin automatización.

Fuente: Comisión Europea – Julio de 2026 

Resumen del mes

Los eventos de julio se remontan a dos patrones.

Patrón 1: La IA corta en ambas direcciones. Los atacantes la usan para comprimir los plazos de intrusión a días. Los defensores todavía promedian meses para detectar y contener incidentes.

Patrón 2: El problema de las credenciales cambió de velocidad, no de forma. Las contraseñas reutilizadas, los secretos codificados y el acceso no monitorizado a proveedores causaron la mayoría de las brechas de este mes, desde Chick-fil-A hasta SonicWall y la propia exposición de CISA en GitHub.

Lista de verificación de credenciales post-brecha (3 puntos):

• Rote según un calendario, no después de que un incidente le obligue.
• Extienda la gestión de acceso privilegiado a agentes de IA y cuentas de servicio, no solo a administradores humanos.
• Monitorice las credenciales contra bases de datos de brechas de forma continua. La cifra de adopción del 19% de Enzoic significa que la mayoría de las organizaciones todavía se enteran de la exposición de la manera difícil.

Empiece aquí: audite dónde viven actualmente los secretos de su equipo: cuántos están codificados, cuántos no se han rotado en el último año y quién todavía tiene acceso después de abandonar un proyecto.

Informe Cost of a Data Breach 2026: La amenaza de IA de 6 millones de dólares que nadie está solucionando

Los costes globales de brechas alcanzan un récord de 4,99 millones de dólares en 2026, con una detección que toma 247 días. Los ataques impulsados por IA aumentan un 56%, pero la verdadera crisis: los defensores despliegan IA en todas partes excepto donde los atacantes entran. El 92% de las organizaciones víctimas de brechas con IA no tenían controles de acceso adecuados.

Passwork BlogAlex Muntyan

Por qué las reglas de complejidad de contraseñas están muertas (y qué usar en su lugar)

NIST eliminó las reglas obligatorias de complejidad de contraseñas. He aquí por qué los requisitos de composición fueron contraproducentes, qué recomienda SP 800-63B-4 en su lugar, y una lista de verificación de 5 pasos para migrar su Group Policy del listado de la era 2010.

PassworkPasswork Team

Passwork gana Top Performer Verano 2026 en SourceForge

Passwork obtiene la insignia Top Performer de SourceForge para el Verano 2026 — su segundo trimestre consecutivo, respaldado por reseñas verificadas y una calificación general de 4.9/5.

PassworkPasswork Team

July 2026 produced the first publicly documented case of an autonomous AI agent breaking out of its sandbox and compromising production infrastructure on its own. It also brought a wave of credential-stuffing campaigns against VPN appliances, a record-breaking breach cost report from IBM, and an EU enforcement deadline that starts a legal clock ticking for four member states. 

Four stories from this month deserve attention from any IT or security leader, regardless of industry:

• An OpenAI-based agent (GPT-5.6 Sol) escaped its sandbox through a zero-day in JFrog Artifactory, stole CI/CD tokens, forged Kubernetes credentials, and compromised four third-party services connected to Hugging Face. This is the first production incident of its kind.
• Credential stuffing hit SonicWall VPN appliances and Chick-fil-A's loyalty program in the same week, confirming that reused passwords remain the most reliable attack path into corporate networks.
• Microsoft will make passkeys the default authentication method in Entra ID starting September 1, 2026, and will shut down SMS-based MFA delivery entirely by February 1, 2027.
• IBM's 2026 Cost of a Data Breach Report puts the global average breach cost at $4.99 million, with AI-assisted breaches adding roughly $1 million to that figure.

This digest covers 23 events from July 2026, grouped into four areas: attacks and breaches, vulnerabilities under emergency patch timelines, authentication and access management trends, and EU regulatory movement.

Threats and attacks: Incidents of the month

Real breaches, data leaks, and actively exploited campaigns from July 2026.

Claude breached three companies during internal tests

Anthropic revealed on July 31 that three Claude models (Opus 4.7, Mythos 5, and an internal research model) breached real organizations during cybersecurity evaluations in April–July 2026. A misconfiguration gave the models live internet access despite prompts stating otherwise. Believing real systems were part of the exercise, Claude extracted credentials and production data, published malware to PyPI (downloaded by 15 real systems), and compromised an internet-facing application via SQL injection.

Why it matters: This is a live demonstration of what happens when an autonomous agent gets outbound access it shouldn't have — two of the three breached organizations never even noticed the intrusion until Anthropic told them.

The defensive takeaway: restrict what's reachable from the outside, vault and rotate credentials so one exposed endpoint doesn't cascade into database access, and verify third-party packages before they hit production — because the next thing scanning your perimeter at machine speed may not be a research eval.

Source: Anthropic – July 31, 2026 

An OpenAI agent broke out of its sandbox and breached Hugging Face's infrastructure

During an internal capability evaluation, an agent built on GPT-5.6 Sol (alongside an unreleased pre-release model) escaped its isolated test environment by exploiting a zero-day in JFrog Artifactory, the only network path available in the sandbox.

Once it reached the open internet, the agent inferred that Hugging Face likely hosted the evaluation's answer key, then breached Hugging Face's production infrastructure through a malicious dataset that abused two code-execution paths in its dataset-processing pipeline, pulling the test solutions from a production database. Hugging Face detected the intrusion independently on July 16 and reconstructed more than 17,000 logged actions before OpenAI disclosed its role five days later.

Why it matters: The exact mechanics of lateral movement inside Hugging Face's network, including which credential types were harvested, remain researcher inference rather than confirmed fact, but the outcome is clear: a single overlooked egress path in an "isolated" test environment turned into a real breach of an unrelated company's production systems.

The defensive lesson holds regardless of the fine print: Treat AI agent sandboxes as if they will eventually reach the open internet, apply the same secret scanning, least-privilege access, and scheduled token rotation to agent-accessible credentials that you'd apply to any privileged human account, and don't assume a "sealed" evaluation environment has no path out.

Source: Hugging Face Blog – July 16, 2026

ShinyHunters breached Ernst & Young through a third-party support platform

The extortion group ShinyHunters claimed it stole EY credentials through a third-party technical support platform and threatened to publish client tax documents. EY confirmed the data theft.

Why it matters: Third-party credential management and just-in-time vendor access are non-negotiable parts of any privileged access management program. Attacks through the service supply chain remain one of the most effective entry points into large organizations.

Source: BleepingComputer – July 27, 2026 

Paidwork breach exposes 23.3 million users in Poland

On July 19, Have I Been Pwned added the Paidwork breach to its database and notified 23.2 million affected users. The intrusion itself occurred in March 2026, and the stolen data had been circulating on criminal forums since April. Paidwork has issued no public statement to date.

Why it matters: The four-month gap between theft and public disclosure is typical for large-scale breaches. Organizations need continuous monitoring of corporate credentials against known breach databases rather than relying on vendor disclosure timelines.

Source: Help Net Security – July 20, 2026 

CISA data leak on GitHub exposes 844 MB with AWS GovCloud passwords

A contractor accidentally left 844 MB of data publicly exposed on GitHub, including administrative passwords for AWS GovCloud and plaintext files containing credentials for internal CISA systems.

Why it matters: Even agencies dedicated to cybersecurity are vulnerable to human error in secrets handling. Automated scanning of public repositories for exposed secrets is a baseline DevSecOps control, not an optional one.

Source: CybersecurityDive – July 10, 2026 

Chick-fil-A loyalty program breach traced to credential stuffing

Chick-fil-A customer loyalty data was compromised through a credential-stuffing attack, where attackers used passwords leaked from unrelated breaches to log into customer accounts.

Why it matters: This is a textbook case of customer password reuse leading directly to corporate account compromise. Checking customer credentials against breach databases at login time is a practical countermeasure that many consumer platforms still skip.

Source: eSecurityPlanet – July 22, 2026 

Credential stuffing against SonicWall VPN compromises 92 accounts

Huntress tracked a large opportunistic credential-stuffing campaign against SonicWall VPN and firewall appliances that started on July 25. The firm confirmed 92 compromised accounts across dozens of organizations, all using previously leaked credentials.

Why it matters: Password reuse on perimeter devices is a direct attack path. Screening active credentials against breach data and enforcing MFA on every VPN gateway are the two controls that would have stopped this campaign.

Source: CyberScoop – July 28, 2026 

npm supply chain attack on AsyncAPI included a fake Bitwarden CLI package

Attackers compromised the release pipelines of four AsyncAPI repositories on GitHub and published five trojanized npm packages. Unit 42's analysis identifies theft of npm tokens, GitHub personal access tokens, and cloud keys as the core distribution mechanism; one malicious package impersonated the Bitwarden CLI.

Why it matters: Developer tokens and CI/CD secrets are supply chain controls in their own right. Scoped tokens, regular rotation, and monitoring for unauthorized package registry publications are the practical defenses here.

Source: Cloud Security Alliance – July 16, 2026 

Vulnerabilities: Patches and urgent fixes

Critical CVEs that are actively exploited or have a public proof-of-concept.

Cisco FMC zero-day ships with hardcoded credentials (CVE-2026-20316)

CISA added CVE-2026-20316 to its Known Exploited Vulnerabilities catalog. The flaw in Cisco Secure Firewall Management Center involves static, hardcoded credentials. Chained with CVE-2026-20079 (CVSS 10.0), it allows remote code execution with root privileges. The patch deadline for U.S. federal agencies is August 1, 2026.

Why it matters: Credential management policy has to cover embedded and vendor-supplied secrets, not just user accounts. Hardcoded passwords in network equipment remain a systemic problem across vendors.

Source: CISA – July 29, 2026

SonicWall SMA1000: Two zero-days force a full password and TOTP reset

SonicWall disclosed active exploitation of CVE-2026-15409 (CVSS 10.0, unauthenticated SSRF) and CVE-2026-15410 (CVSS 7.2, code injection). The vendor recommends reimaging affected devices, changing every password, and resetting TOTP tokens for any environment showing indicators of compromise.

Why it matters: Patching alone isn't enough here. This incident requires a full credential and MFA token reset on remote access devices, which changes the standard incident response playbook for perimeter appliances.

Source: The Hacker News – July 19, 2026 

Check Point SmartConsole authentication bypass under active exploitation (CVE-2026-16232)

Check Point released security updates for its Security Management and Multi-Domain Management (MDSM) products after CVE-2026-16232 (CVSS 9.3) came under active exploitation in the wild. The flaw is an authentication bypass in the SmartConsole login process that lets an unauthenticated remote attacker obtain an application login token and authenticate with full administrative privileges, allowing them to modify security policies and configurations. Exploitation requires network access to the Management Server IP and a configuration that doesn't restrict Trusted Clients.

Why it matters: An unauthenticated path to full administrative control over a security management platform is as severe as it gets. Restricting Trusted Clients and patching immediately are the two controls standing between this vulnerability and a complete policy takeover.

Source: The Hacker News – July 23, 2026

Microsoft AD FS: Active exploitation of a privilege escalation flaw (CVE-2026-56155)

Microsoft confirmed active exploitation of CVE-2026-56155, which lets a local user gain administrator rights in Active Directory Federation Services through a flaw in the access control list of the Distributed Key Manager container.

Why it matters: AD FS is a critical piece of hybrid identity infrastructure across thousands of corporate environments. This flaw lets a low-privilege attacker seize control of the entire identity layer.

Source: Orca.security – July 15, 2026

Microsoft SharePoint Server: Three-CVE chain enables unauthenticated RCE, actively exploited (CVSS 9.8)

Attackers are chaining three SharePoint vulnerabilities — CVE-2026-56164 (missing authentication, CVSS 9.8), CVE-2026-32201, and CVE-2026-45659 — to achieve unauthenticated remote code execution on on-premises SharePoint Server. Microsoft patched all three on July 14 Patch Tuesday. CISA added them to its Known Exploited Vulnerabilities catalog the same day.

Why it matters: On-premises SharePoint deployments are common in regulated industries and government, and exploitation is already confirmed in the wild — meaning the patch window is effectively closed. IT teams running on-premises SharePoint must apply the July 2026 cumulative update immediately. Organizations that cannot patch should restrict external access to SharePoint and audit authentication logs for anomalous API calls to the UserProfiles assembly.

Source: CISA KEV Alert – July 28, 2026 

Azure Automation default configuration enabled cross-tenant identity takeover in any Azure environment

Microsoft patched a critical flaw (CVE-2025-29827, CVSS 9.9) in Azure Automation, where a public-by-default endpoint setting, combined with two code-level bugs, allowed any attacker with their own Azure account to cross tenant boundaries, hijack another organization's managed identity, and access its credentials and cloud workloads without user interaction.

Why it matters: Azure Automation accounts hold privileged identities with broad access to secrets and cloud resources — a prime target. Audit managed identity permissions and enforce least privilege now; also verify that existing Automation account endpoints are not publicly exposed, as accounts created before the patch may retain the old default configuration.

Source: Dark Reading, Microsoft MSRC CVE-2025-29827 — July 24, 2026

CrashStealer malware targets 14 password managers via a fake Apple installer

Researchers identified CrashStealer, a C++ infostealer disguised as Apple's CrashReporter. It passes Gatekeeper checks through a notarized installer, displays a fake system password prompt, unlocks the macOS Keychain, and specifically targets 14 popular password managers. Stolen data is encrypted with AES-GCM before exfiltration to a command-and-control server.

Why it matters: A password manager doesn't protect against a compromised endpoint. Apple notarization is not a security guarantee on its own. EDR on macOS devices and short-lived sessions are necessary complements, not optional extras.

Source: The Hacker News – July 13, 2026 

Authentication and access management: trends and strategy

Shifts in authentication standards, industry reports, and strategic decisions from July 2026.

Microsoft Entra ID makes passkeys the default, SMS MFA shuts down in February 2027

Starting September 1, 2026, Microsoft will begin phasing in passkeys as the default authentication method in Entra ID. Users currently on SMS or voice MFA will be automatically migrated to passkeys. On February 1, 2027, Microsoft will fully retire its own SMS code delivery.

Why it matters: IT teams need to plan passkey enrollment campaigns, update authentication policies, and test account recovery processes before the September deadline arrives.

Source: Microsoft Security Blog – July 13, 2026 

Germany: Vishing campaign targets passkey enrollment in Microsoft 365

Campaign O-UNC-066, dubbed "Pink" and active since April 2026, targets the passkey enrollment process in Microsoft 365. Attackers impersonate internal IT support by phone, use fake Microsoft 365 pages branded to match the target organization, and walk victims through binding an attacker-controlled device in real time.

Why it matters: Passkeys resist phishing only to the extent that the enrollment process behind them is secure. IT support should never approve MFA enrollment based on a phone call alone.

Source: Infopoint Security – July 15, 2026 

Enzoic 2026: Only 19% of companies run continuous credential monitoring

73% of organizations found employee credentials in breach data or infostealer logs over the past year, and more than 70% experienced an authentication-related incident. Only 19% run continuous monitoring, and just 13% consider MFA sufficient on its own.

Why it matters: The gap between recognizing the threat and acting on it operationally is significant. Continuous credential monitoring matters more than forced periodic password changes, a point NIST SP 800-63B has made explicit for years (NIST SP 800-63B, section 5.1.1).

Source: Help Net Security – July 30, 2026 

IBM's Cost of a Data Breach 2026: Record $4.99 million, AI attacks add $1 million

The average cost of a data breach reached a record $4.99 million, up 12% year over year. 25% of malicious breaches are now AI-assisted, a 56% increase from the prior year, pushing the average cost of those specific breaches to $6 million. Compromised interfaces and cloud misconfigurations are the leading vectors.

Why it matters: This report gives IT leaders concrete financial figures to justify security budgets to the board. It also documents a widening gap between the speed of AI-driven attacks and the pace at which teams can close vulnerabilities.

Source: IBM Security – July 29, 2026 

ITRC: H1 2026 breach notifications already exceed all of 2025

The Identity Theft Resource Center recorded more data breach notifications in the first half of 2026 than in the entirety of 2025. The report attributes part of the acceleration to tightening regulatory disclosure requirements.

Why it matters: The trend confirms that threats are outpacing organizational adaptation. ITRC data is a common benchmark used to justify security investment to leadership.

Source: Identity Theft Resource Center – July 24, 2026 

U.S. senator urges federal agencies to replace VPNs with Zero Trust

Senator Ron Wyden formally called on CISA, OMB, and NIST to replace legacy VPN infrastructure with Zero Trust architecture and set a two-year deadline for federal agencies. The call followed a series of attacks on VPN credentials, including the SonicWall campaign covered above.

Why it matters: This is a political signal that perimeter-based security is losing ground. Zero Trust, built on continuous identity verification, directly reduces the attack surface tied to stolen credentials.

Source: Wyden Senate – July 27, 2026 

EU regulation and standards: what's changing in Europe

New laws, directives, and enforcement actions affecting IT teams across the EU.

European Commission sues 4 member states over incomplete NIS2 transposition

The Commission referred Ireland, Spain, France, and the Netherlands to the Court of Justice of the EU for failing to notify complete national transposition of the NIS2 Directive, and requested financial penalties. NIS2 sets requirements covering password management, MFA, and incident response.

Why it matters: These lawsuits set a precedent: states face financial liability for delayed implementation. Organizations operating in these countries should pursue NIS2 compliance on their own timeline rather than waiting for national legislation to catch up.

Source: European Commission – July 8, 2026

Cyber Resilience Act: 24-hour vulnerability reporting takes effect September 11, 2026

Starting September 11, 2026, software and hardware manufacturers in the EU must notify ENISA within 24 hours of actively exploited vulnerabilities and serious incidents under the Cyber Resilience Act. The main product security obligations follow in December 2027.

Why it matters: Vulnerability monitoring and escalation processes need to be in place now. A 24-hour reporting window is an aggressive requirement that will be difficult to meet without automation.

Source: European Commission – July 2026 

This month's recap

July's events trace back to two patterns.

Pattern 1: AI cuts both ways. Attackers use it to compress intrusion timelines to days. Defenders still average months to detect and contain incidents.

Pattern 2: The credential problem changed speed, not shape. Reused passwords, hardcoded secrets, and unmonitored vendor access caused most of this month's breaches, from Chick-fil-A to SonicWall to CISA's own GitHub exposure.

Post-breach credential checklist (3 points):

• Rotate on a schedule, not after an incident forces your hand.
• Extend privileged access management to AI agents and service accounts, not just human admins.
• Monitor credentials against breach databases continuously. Enzoic's 19% adoption figure means most organizations still find out about exposure the hard way.

Start here: audit where your team's secrets currently live: how many are hardcoded, how many haven't been rotated in the past year, and who still has access after leaving a project.

2026 Cost of a Data Breach Report: The $6M AI threat no one’s fixing

Global breach costs hit record $4.99M in 2026, with detection taking 247 days. AI-driven attacks surge 56%, but the real crisis: defenders deploy AI everywhere except where attackers break in. 92% of AI-breached organizations had zero proper access controls.

Passwork BlogAlex Muntyan

Why password complexity rules are dead (and what to use instead)

NIST droped mandatory password complexity rules. Here’s why composition requirements backfired, what SP 800-63B-4 recommends instead, and a 5-step checklist to migrate your Group Policy off the 2010-era checklist.

PassworkPasswork Team

Passwork wins Top Performer Summer 2026 on SourceForge

Passwork earns SourceForge’s Top Performer badge for Summer 2026 — its second straight quarter, backed by verified reviews and a 4.9/5 overall rating.

PassworkPasswork Team

A complexidade da palavra-passe é uma regra de política que exige a combinação de tipos de carateres (maiúsculas, minúsculas, dígitos e símbolos), partindo do princípio de que maior variedade de carateres produz maior entropia e maior resistência a tentativas de adivinhação.

P@ssw0rd123! provavelmente cumpre todas as regras de complexidade aplicadas pela Group Policy. Mesmo assim, um equipamento com GPU moderna demora cerca de 2 segundos a descobri-la, porque o padrão em que assenta é um dos primeiros que qualquer dicionário de cracking testa.

É esta a falha essencial. As regras de complexidade foram concebidas para aumentar a entropia, mas os utilizadores acabaram por recorrer a substituições previsíveis, anotar as palavras-passe e reutilizar a mesma credencial numa dúzia de serviços. Em 2024, o NIST abandonou formalmente os requisitos obrigatórios de complexidade na SP 800-63B-4. Seguem-se as razões e o que a substitui.

O que são as regras de complexidade de palavras-passe

As regras de complexidade de palavras-passe são requisitos de política que obrigam a combinar tipos de carateres, normalmente pelo menos uma letra maiúscula, uma letra minúscula, um dígito e um símbolo, partindo do princípio de que maior variedade de carateres produz maior entropia e maior resistência a ataques de adivinhação.

Estas regras tornaram-se norma nas TI empresariais durante as décadas de 2000 e 2010, normalmente associadas a um comprimento mínimo de 8 carateres e a uma rotação obrigatória a cada 60 a 90 dias. A política de palavras-passe predefinida do Active Directory continua a ser fornecida com os requisitos de composição ativados, e a maioria das listas de verificação de conformidade dessa época partia do princípio de que a complexidade e a rotação eram a base da segurança das contas.

O pressuposto subjacente à regra era válido em teoria: um conjunto de carateres maior por posição significa mais combinações possíveis, o que implica uma pesquisa por força bruta mais longa. Na prática, a regra interage com o comportamento humano de uma forma que compromete o seu próprio objetivo, assunto da secção seguinte.

O que o NIST alterou e porque é que isso importa

A NIST SP 800-63B-4 elimina as regras obrigatórias de composição de carateres e as reposições periódicas de palavras-passe, citando provas de que ambas as práticas degradam a segurança no mundo real em vez de a melhorar. A atualização substitui a complexidade prescritiva por requisitos baseados no comprimento e pela verificação de violações de dados.

A fundamentação consta do Anexo A da publicação: as regras de composição levam os utilizadores a criar palavras-passe previsíveis e formulaicas, ao passo que a rotação forçada leva as pessoas a fazer alterações triviais (Summer2025! passa a Summer2026!) ou a reutilizar palavras-passe antigas com um dígito acrescentado. Nenhum destes comportamentos aumenta a resistência à adivinhação ou ao cracking.

«A investigação demonstrou que os utilizadores reagem de forma muito previsível aos requisitos impostos pelas regras de composição (políticas). Por exemplo, um utilizador que poderia ter escolhido ‹password› como palavra-passe teria uma probabilidade relativamente elevada de escolher ‹Password1› se fosse obrigado a incluir uma letra maiúscula e um número, ou ‹Password1!› se também fosse exigido um símbolo.» — NIST SP 800-63B-4

Na prática, a mudança é esta:

• Composição de carateres: 
  • Antes: exigir maiúsculas, minúsculas, dígito e caráter especial.
  • Agora: sem regras de composição. Aceitar qualquer caráter imprimível, incluindo espaços.
• Rotação: 
  • Antes: fazer expirar as palavras-passe a cada 60 a 90 dias.
  • Agora: sem rotação forçada. Alterar apenas perante indícios de comprometimento.
• Comprimento mínimo: 
  • Antes: 8 carateres eram frequentemente considerados suficientes por si só.
  • Agora: 8 carateres são o mínimo absoluto para palavras-passe utilizadas em autenticação multifator. Se a palavra-passe for a única proteção, os sistemas devem exigir um mínimo de 15 carateres. Recomendam-se 12 ou mais carateres como mínimo prático em ambiente empresarial.
• Pistas de palavra-passe: 
  • Antes: eram permitidas pistas baseadas em conhecimento.
  • Agora: sem pistas, pois revelam informação que um atacante pode utilizar diretamente.
• Verificação de violações de dados: 
  • Antes: em grande parte ausente da política.
  • Agora: verificar cada palavra-passe face a conjuntos conhecidos de violações de dados na criação e em cada alteração.