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 la versión internacional 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 son desarrolladas y preparadas para su lanzamiento por el equipo de Passwork Europe S.L. sin depender de actualizaciones de código fuente de Passwork FZ-LLC.

El ritmo de publicación de versiones no cambia. Las actualizaciones regulares de funciones y de 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 der internationalen Version von Passwork eigenständig.

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 vom Team von Passwork Europe S.L. entwickelt und vorbereitet, ohne auf Quellcode-Updates von Passwork FZ-LLC zurückzugreifen.

Der Release-Rhythmus bleibt unverändert. Reguläre 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.

Passwork has been included in the Capterra Shortlist 2026 for Password Management. The Shortlist recognizes products with the highest user ratings and the strongest category popularity, based on verified customer reviews collected through Capterra's platform. Passwork holds a 4.7 overall rating from 79 reviews.

What customers say about Passwork

Customers name two factors that matter most to them: security that meets enterprise-level requirements, and an interface teams learn quickly, without lengthy training.

"Password management with role-based vaults and private vaults, ease of use for the end-users, user management via LDAP and SAMLv2, and a usable API was the key features for us when deciding on a web-based password vault solution." — Infrastructure Architect

That ease of use carries into daily operations as well as the initial buying decision.

"We wanted a simple and secure way to manage shared passwords instead of sending credentials through chat or keeping them in spreadsheets. Passwork solved that problem well and their support is very responsive." — Head of Success

Users highlight the simplicity of installation and the ease of migrating from other access management solutions.

“Passwork’s pros: - Ease of installation (for a self hosted server) - Easy migration from our legacy tool via CSV export/import - Folder structure, great search function - Productivity boost thank to the browser integration.” – Software Engineer

About Capterra

Capterra is a U.S.-based platform that helps businesses research and compare software based on verified user reviews, side-by-side comparisons, and category rankings. Vendors don't pay for placement in the Shortlist itself; the ranking is calculated from rating volume and satisfaction scores across the category.

"We build Passwork to fit naturally into the way organizations already work. That means a clear interface for everyday users, responsive technical support, and integrations that help IT teams connect Passwork with their existing infrastructure and workflows. We’re glad to see that these efforts have earned Passwork a place on the Capterra Shortlist 2026." – Alex Muntyan, CEO Passwork

Verified reviews are a solid starting point for evaluating a password manager. The next step is seeing how that experience translates to your own AD setup and existing integrations.

Passwork named Best for User Interface and recognized as a 2026 FrontRunner

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

PassworkPasswork Team

Password management best practices for enterprise security in 2026

If your password policy still mandates 90-day rotations and eight-character minimums, it’s out of date. This guide covers enterprise password management best practices for 2026: policy, privileged accounts, non-human identities, MFA, and compliance.

PassworkAlex Muntyan

SaaS credential management: 5 steps to centralize your app stack

SaaS credential management turns scattered passwords and API keys into one inventory you can share on purpose and revoke on exit. Here’s the five-step framework: inventory, structure, migration, access control, and automation.

PassworkPasswork Team

August's cybersecurity news had a common thread: attackers found ways around the login itself instead of attacking it directly. Authentication bypasses, forged tokens, stolen sessions, exposed API keys, and leaked machine credentials repeatedly provided access without requiring attackers to crack a password or defeat MFA.

• More than 9,300 active AWS access keys were found in public repositories, build logs, and container images. Among the corporate keys were 526 root keys and 242 IAM keys with full AdministratorAccess permissions.
• The March LiteLLM supply-chain incident may have exposed more than 2,500 organizations and 434,000 CI/CD pipelines, according to an impact assessment published in August.
• Researchers found 4,576 n8n API tokens in public GitHub repositories; among reachable instances tested, 36% accepted at least one leaked key.
• Mirage2FA targeted 9,426 Microsoft 365 email addresses and compromised up to 4,532 of them by stealing authenticated sessions after MFA.

The same pattern showed up in four disclosed vulnerabilities: N-able N-central, Citrix NetScaler, Keycloak, and SharePoint all disclosed flaws capable of bypassing authentication or identity controls. Separately, password-spraying activity rose 155-fold as attackers probed for gaps in MFA enforcement.

The incidents below show how authentication is expanding beyond passwords and login screens — and where IT and security teams need to adjust their controls.

Active exploitation of a critical authentication bypass in N-able N-central remote management platform (CVE-2026-18577)

What happened: The vulnerability CVE-2026-18577 (CVSS 8.1) allows a remote, unauthenticated attacker to fully bypass authentication and gain administrative access to N-central servers. The flaw stems from an incomplete fix for a previous vulnerability, CVE-2026-18556. Active in-the-wild exploitation has been recorded since August 1, 2026, with attackers using the legitimate Take Control feature to reach customer endpoints after compromise and deploying a cloudflared tunnel for persistent remote access.

Why it matters: Remote monitoring and management (RMM) platforms hold the highest privilege level across an organization's entire infrastructure and its connected clients. An authentication bypass in such software immediately creates a supply-chain exposure risk across the whole client base.

The defensive takeaway: IT teams must urgently check their platform version and confirm that N-able hotfix 2026.3.1.10 (2026.3.1 Hotfix 2) is installed. A review of active privileged sessions is also critical.

Source: Rapid7 – August 4, 2026

Remote, zero-interaction authentication bypass in Citrix NetScaler Gateway (CVE-2026-19490)

What happened: Citrix patched a critical alternate-path authentication vulnerability, CVE-2026-19490 (CVSS score 9.3), in NetScaler ADC and NetScaler Gateway. An unauthenticated remote attacker can exploit the flaw on affected gateway configurations without any user interaction. Preconditions vary by version: newer affected builds require a SAML configuration in addition to a Gateway or AAA setup, so not every NetScaler deployment is exposed the same way.

Why it matters: Remote access gateways serve as the primary perimeter defense for corporate networks. A successful authentication bypass at this layer completely negates the value of employee corporate credentials and MFA policies.

The defensive takeaway: Because these appliances are directly exposed to the internet, IT teams should perform an emergency update to the patched builds provided by Citrix (14.1-73.32 or 13.1-63.21 and later).

Source: SecurityWeek – August 20, 2026

Critical Keycloak password-reset vulnerability (CVE-2026-18963) leading to remote account takeover

What happened: A critical vulnerability, CVE-2026-18963 (CVSS score 9.1 per Red Hat), was found in Keycloak's password recovery (reset-credentials) flow. Due to improper state validation, a remote, unauthenticated attacker can reset any user's password, including administrators'. Fixes have been released in Keycloak 26.7.2, as well as Red Hat build of Keycloak 26.4.15 and 26.6.6.

Why it matters: Validation flaws in account-recovery flows undermine any strict password-complexity requirements or initial MFA, giving attackers a direct path to compromising the identity provider (IdP).

The defensive takeaway: IT teams should prioritize patching Keycloak servers and test password-reset and account-recovery flows with the same rigor applied to primary authentication methods.

Source: The Hacker News – August 24, 2026

Critical remote code execution vulnerability CVE-2026-69836 (CVSS 10.0) fixed in Microsoft Entra ID's cloud directory

What happened: Microsoft fixed a critical remote code execution vulnerability, CVE-2026-69836, in Entra ID's cloud service, related to deserialization of untrusted data. Unlike the other flaws in this digest, this is a remote code execution issue in cloud infrastructure, not a credential or authentication bypass. Microsoft resolved the issue server-side, requiring no action from customers. The flaw was initially flagged as exploited in real-world attacks, but Microsoft later revised the status to "not exploited."

Why it matters: Entra ID is the central hub for access control and authorization for thousands of companies. Maximum-severity vulnerabilities in identity providers' cloud infrastructure create global risks across the entire trusted ecosystem.

The defensive takeaway: Despite the automatic patch applied by the provider, security teams should monitor for anomalies in cloud identity logs and revisit risk assumptions about access during incidents affecting key service providers.

Source: SecurityWeek / heise online – August 21-24, 2026

Mass exposure of active AWS keys threatens full takeover of corporate accounts

What happened: Research by Truffle Security identified more than 9,300 AWS access keys leaked into public repositories, build logs, and container images, keys that remained valid and active for years. Of these, 817 belonged to companies, including 526 root keys and 242 IAM keys with full AdministratorAccess permissions, granting complete control over cloud infrastructure.

Why it matters: Leaked long-lived access keys, especially those with administrator rights, give attackers unimpeded access to cloud resources, bypassing standard authorization portals and MFA entirely.

The defensive takeaway: IT teams must prohibit the use of AWS root accounts in routine processes, set up continuous scanning of public sources for exposed secrets, and immediately revoke and rotate any compromised keys, following AWS's own root user best practices.

Source: Truffle Security – August 19, 2026

CloudSEK report maps potential exposure from the March LiteLLM supply-chain incident

What happened: On August 11, CloudSEK published an impact assessment of the March 24 compromise involving malicious LiteLLM releases 1.82.7 and 1.82.8. The report estimates that the short-lived PyPI exposure (the packages were publicly available for roughly 40 minutes) may have affected more than 2,500 organizations and over 434,000 CI/CD pipelines worldwide.

The assessment focuses on the potential exposure of high-value machine credentials available to affected development and build environments. CloudSEK’s figures describe reconstructed exposure risk, not confirmed compromise of every named organization or pipeline.

Why it matters: AI development and build automation environments now hold the highest concentration of non-human (machine) secrets in an organization. Compromising tooling at the build stage lets attackers strike deep inside the infrastructure, and the delay between the original incident and a full exposure estimate shows how long that risk can go unquantified.

The defensive takeaway: Machine credentials require strict lifecycle control, rotation, and access-rights auditing. IT teams need to implement security monitoring for third-party libraries and protect environment variables in CI/CD pipelines. Passwork's technical guides cover API-based secret rotation patterns that fit directly into this kind of pipeline hardening.

Source: CloudSEK – August 11, 2026

Vulnerability in the N-able Passportal browser extension exposes users' password vault master keys

What happened: The Passportal browser extension accepted messages from third-party websites and iframe elements. Attackers could send a request and obtain extension access tokens containing secret keys. This allowed extraction of the entire contents of the password vault, including seeds for generating one-time TOTP codes. N-able released a patch adding origin-checking for requests in July 2026; Dark Reading's August coverage detailed the flaw and its impact.

Why it matters: Password managers concentrate an organization's most critical secrets. Compromising a password manager's browser extension effectively bypasses the entire security architecture, MFA factors included. The risk was compounded by refresh tokens remaining valid for 100 days.

The defensive takeaway: Organizations need to enforce regular automatic updates of browser extensions on employee devices, and when selecting IAM solutions, evaluate whether they support end-to-end encryption of client-side operations.

Source: Dark Reading – August 20, 2026

Mirage2FA phishing campaign bypasses Microsoft 365 multi-factor authentication through session theft

What happened: The Mirage2FA platform uses adversary-in-the-middle (AiTM) phishing to intercept legitimate Microsoft 365 session authorization tokens. The campaign compromised up to 4,532 email addresses, roughly 48% of the 9,426 addresses targeted, across 3,518 organization domains in the US and EU.

Why it matters: Session cookies effectively become the equivalent of user credentials once initial MFA verification has passed. Session theft bypasses standard protection factors without requiring a password or code to be re-entered.

The defensive takeaway: Traditional SMS- or app-code-based MFA is no longer sufficient to protect cloud systems on its own. Organizations need to adopt phishing-resistant authentication methods, shorten session token lifetimes, and set up monitoring for anomalous session behavior.

Source: The Hacker News – August 25, 2026

JWT authentication bypass in Microsoft SharePoint (CVE-2026-55040) allows impersonation of any user

What happened: A vulnerability, CVE-2026-55040, was discovered in SharePoint Server Subscription Edition that lets a remote, unauthenticated attacker generate a forged JWT token and impersonate any user or portal administrator. Microsoft patched the flaw in July 2026. Rapid7's August technical analysis detailed the chain of defects behind it, including a disabled token signature requirement and weak validation of token elements, and confirmed active exploitation.

Why it matters: JWT validation errors let attackers fully bypass authentication without needing to steal user passwords.

The defensive takeaway: Service-to-service trust relationships and token validation must be checked and controlled by IT teams with the same rigor applied to user passwords and MFA sessions.

Source: Rapid7 blog – August 11, 2026

Exploitation of an SSRF vulnerability in MLflow (CVE-2026-64849) for covert credential exfiltration from cloud environments

What happened: A server-side request forgery (SSRF) vulnerability with a CVSS score of 9.3, CVE-2026-64849, was found in the model registry of the MLflow Tracking Server. It lets an unauthenticated attacker bypass webhook safeguards and reach internal cloud metadata services to exfiltrate short-lived credentials. The issue affects all MLflow versions prior to 3.15.0.

Why it matters: Cloud metadata services often issue short-lived access keys that, once compromised, can be used by attackers for rapid lateral movement inside a company's cloud environment.

The defensive takeaway: Teams running machine learning platforms need to patch MLflow to version 3.15.0 and restrict network access to metadata services from containers and AI tooling, following the pattern in AWS's IMDSv2 configuration guidance.

Source: SecurityWeek – August 20, 2026

Thousands of leaked n8n API tokens found in GitHub repositories, threatening compromise of connected IT services

What happened: Researchers found 4,576 unique n8n API tokens in public GitHub repositories, linked to 1,255 hosts. Testing against accessible instances found that 36% of them (321 of 896 reachable hosts) accepted at least one leaked key. With a privileged token, attackers could view automation workflow structures, execution logs, and extract credentials stored in n8n for third-party database and service integrations.

Why it matters: Automation and integration platforms act as hubs where passwords, API keys, and access rights to numerous corporate IT systems accumulate. A single leaked API token to such a hub creates massive risk of cascading compromise across the entire IT infrastructure, even though the exposure itself is not tracked as a CVE.

The defensive takeaway: IT departments need to extend secret-scanning policies beyond core application code, covering configuration files of automation and integration tools as well.

Source: The Hacker News – August 5, 2026

155-fold surge in password-spraying attacks exploiting MFA misconfigurations and exceptions

What happened: Analysts recorded a 155-fold increase in the scale of password-spraying attacks in the first half of 2026. Analysis of 23 affected companies found that 8 of them had no multi-factor authentication (MFA) at all. In the remaining 15 cases, MFA was enabled but failed to work, because IT departments had configured exceptions for "trusted locations," limited policy enforcement to a subset of applications or user groups, or left MFA running in report-only (audit) mode.

Why it matters: Deploying MFA does not guarantee protection if blind spots remain in security policies. Attackers actively search for loopholes and applications left unprotected by MFA to gain initial network access.

The defensive takeaway: IT teams need to eliminate "trusted IP address" exceptions, implement comprehensive MFA coverage across all external entry points, and regularly audit how security policies are actually enforced.

Source: BleepingComputer – August 19, 2026

Unverified claims by hacker "TheHatman" of mass credential theft from Microsoft Entra corporate customers

What happened: Between August 1 and 17, 2026, a hacker forum user going by "TheHatman" posted offers to sell employee data from large enterprises, allegedly obtained from Microsoft Entra cloud environments through compromised credentials. Unit 42 researchers were unable to confirm a specific entry vector or an actual breach of the Entra service itself, leaving the threat classified as an "unverified breach via account credential theft."

Why it matters: Even though the hacker's claims of breaching the provider's infrastructure remain unconfirmed, the incident drew wide attention and illustrated how attackers use compromised passwords to compromise cloud tenants. Unverified claims of this kind should be treated by IT teams as a signal to check their own systems, not as proof that the platform itself was breached.

The defensive takeaway: IT and security teams need to set up regular monitoring for leaked employee credentials and watch for signs of MFA fatigue and password-spraying attempts against cloud identity directories. Unverified threats should be used to build threat-hunting hypotheses, not to trigger panic responses.

Source: Unit 42 report – August 18, 2026

Comparative analysis of SOC response effectiveness based on CISA red team tests

What happened: The Cybersecurity and Infrastructure Security Agency (CISA) evaluated the defenses of two organizations through red team penetration testing. One organization completely missed and failed to contain the attackers' actions, while the other quickly detected initial compromise attempts and isolated the affected hosts. CISA's recommendations include maintaining baseline detection profiles, using Conditional Access policies for workload identities, and promptly rotating and revoking tokens.

Why it matters: Monitoring tools are useless without well-honed incident-response processes. Protecting cloud and hybrid environments depends directly on integrating identity and access management (IAM) systems with security team on-call playbooks.

The defensive takeaway: Privilege inventory processes, Conditional Access verification, and emergency session-token revocation need to be practiced regularly through drills and attack simulations.

Source: CISA Advisory – August 25, 2026

August 2026 recap

In August, attackers went around authentication using forged tokens, stolen sessions, leaked keys and much of this activity doesn't trip the alerts most organizations rely on. In practice, that means password policy alone no longer covers most of your attack surface: sessions, tokens, and machine credentials need the same lifecycle controls that passwords already have.

Three priorities for September:

1. Patch the four disclosed authentication bypasses. N-central and SharePoint had confirmed in-the-wild exploitation this review period. NetScaler and Keycloak warrant urgent patching given their severity, even without confirmed exploitation to date.
2. Audit authentication end to end, not just the login screen. MFA at sign-in provides limited protection if account recovery, JWT validation, session lifetimes, or Conditional Access coverage have gaps. Mirage2FA and CaptiveCrunch both bypassed MFA by stealing a session or token after authentication, not by defeating it.
3. Scan repositories and CI/CD pipelines for exposed keys, the way GitGuardian and Truffle Security did in August, and build revocation and rotation into routine operations rather than incident response.

These three issues share a root cause: credentials and secrets scattered across repos, pipelines, and inboxes, with no single place to see who has access to what. Passwork addresses that with one encrypted vault for passwords and secrets, role-based access, audit logs, and API-driven rotation.

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

The state of secrets sprawl in 2026: Key findings from GitGuardian’s report

28.65 million secrets leaked on public GitHub in 2025. AI is accelerating the problem. Internal repos are 6× more exposed than public ones. And 64% of secrets from 2022 are still valid today. Here is what the data means for your security posture.

PassworkAlex Muntyan

A password-management rollout becomes effective only when end users can turn their first invitation into a secure, repeatable everyday workflow. Passwork supports this with role-based onboarding: each group gets a scenario built around what they need to do on the platform.

• Department managers — set up team structures and delegate access without involving IT for every request
• IT administrators and system owners — deploy the platform, configure vaults, and manage organization-wide settings
• DevOps engineers and integrators — connect Passwork to existing infrastructure through the API and CLI
• Security specialists and compliance officers — configure audit logging, access policies, and controls tied to regulatory requirements
• End users — move from their first invitation to secure daily work

This guide focuses on the last scenario: what end users go through, step by step, from the moment they receive an invitation.

The user journey at a glance

The User Onboarding scenario takes approximately 15–30 minutes and covers five stages: activating the account, installing everyday tools, securing sign-in, learning the core actions, and working with shared credentials in the right vaults.

The sequence helps users move from gaining access to establishing the habits they will need later: using Passwork where credentials are required, generating passwords instead of creating them manually, and understanding where personal and corporate credentials belong. This focus on usability is reflected in Passwork being named Best for User Interface in Software Advice’s 2026 selection.

Start with the right sign-in and account setup

The first step depends on how the organization has configured Passwork. Employees may authenticate through Single Sign-On (SSO) with a corporate identity provider, through Lightweight Directory Access Protocol (LDAP) integration with Active Directory, or with a local Passwork account. Local account registration may also require administrator approval.

Organizations using client-side encryption add the master password. Passwork uses it to encrypt the user’s private key on the device, and the master password itself is never transmitted to the server. It must be different from the user’s Passwork login password, where applicable, and from their domain or SSO password. Unlike a regular account password, it has no recovery mechanism. An administrator can reset it, but doing so results in the loss of the user’s private encrypted data.

Make the secure workflow convenient

Once the account is active, Passwork moves closer to where employees use credentials. The browser extension provides autofill, password generation, and vault access directly in the browser. After installing the extension from the browser’s store, users enter their organization’s Passwork URL in the host address field and sign in with their credentials. The mobile app brings the same workflow to iOS and Android, while a Windows and Linux desktop application can be deployed in environments where a browser extension is less suitable. Availability depends on organizational permissions and configuration.

The mobile app is connected from the desktop version of Passwork by scanning a QR code, giving users a straightforward way to authorize the app for their organization.

We also recommend disabling the browser's built-in password manager after installing the extension. Running both can create autofill conflicts and make the intended workflow less predictable.

Convenience here serves a security purpose: routine tasks such as signing in or creating a credential can happen inside the managed workflow instead of around it.

Secure the account before routine work begins

Account protection comes early in the Users scenario. Two-factor authentication (2FA) adds another verification step to sign-in, so possession of the account password alone is insufficient for access.

Depending on organizational policy and configuration, users can connect the Passwork 2FA app, a Time-based One-Time Password (TOTP) authenticator such as Google Authenticator or Microsoft Authenticator, or WebAuthn-compatible security keys and biometric authentication.

Passkeys may also be available when enabled for the user’s role. They use device biometrics or a compatible physical security key for passwordless authentication, and users can register multiple passkeys for different devices.

Putting these options into the initial user journey helps make account protection part of setup rather than a task employees have to remember later.

Teach the three everyday actions

Most employees only need a small set of actions to start working productively:

• Save a credential
• Generate a password
• Use autofill

Together, these three actions cover much of the daily interaction an employee has with a password manager.

When adding an entry, users provide its name, login, password, URL, and optional description. The URL has a practical role beyond documentation: Passwork uses it to match saved credentials with the appropriate website for autofill. An incorrect or missing URL can prevent the expected entry from appearing.

For new accounts and password changes, users can generate credentials either while creating an entry or through the browser extension. Password length and character sets can be configured in the generator, while the organization's own password policy should determine the requirements employees follow.

Put personal and shared credentials in the right place

Knowing where to save a credential is as important as knowing how to save one.

A private vault is visible only to its user and is intended for personal credentials and notes. Corporate vaults hold credentials used by a team or department, including shared service accounts, with access managed by the vault owner or administrator.

The distinction has an operational consequence. A team credential stored in someone’s private vault remains available only to that person. Storing it in the appropriate corporate vault keeps it accessible to colleagues who have the required permissions, including when the original employee is unavailable.

Users only see corporate vaults and folders they have permission to access. When something required for their work is missing, the onboarding guide directs them to request access from their department manager or Passwork administrator rather than create a parallel storage arrangement.

Use the guide as part of your rollout

For implementation teams, the Users scenario can become part of the rollout communication itself. Send it with the Passwork invitation and tell employees who can help with missing vault access or account issues.

Keep the message focused on the user journey. Authentication methods, client-side encryption, 2FA options, passkeys, and application availability depend on the organization’s configuration, so employees need the path relevant to their environment rather than administrative details about every possible setup.

A deployed password manager becomes useful when employees know how to incorporate it into their daily work. The Passwork Users guide connects account activation with that outcome: secure sign-in, convenient access to credentials, a few repeatable actions, and a clear distinction between private and corporate data.

Share the User onboarding scenario scenario with new employees as part of your Passwork rollout and give them a defined path from invitation to everyday use.

If your team shares credentials through spreadsheets, chat, or browser storage, Passwork gives you a self-hosted vault with RBAC, audit logging, and one-click offboarding, without enterprise pricing. Set up Passwork on your infrastructure and stop wondering who still has the Wi-Fi password from three hires ago.

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

SaaS credential management: 5 steps to centralize your app stack

SaaS credential management turns scattered passwords and API keys into one inventory you can share on purpose and revoke on exit. Here’s the five-step framework: inventory, structure, migration, access control, and automation.

PassworkPasswork Team

Passwork’s vault policies: a CIO’s guide to enterprise security

Passwork’s Vault Types bind admin rights to the vault policy itself, not to whoever created it, closing a gap most enterprises don’t even know exists. This guide gives CIOs and CISOs a working model for vault governance, mapped to NIS2 and ISO 27001 requirements.

PassworkPasswork Team

Teach children password security with one repeatable habit: create a unique passphrase, protect it with a second sign-in step, and ask for help when a login or message looks wrong. A password is the secret that opens an account.

Most families only think about this after something happens: a Roblox account taken over by a stranger, a classmate who guessed a password from a birthday, a message that looks like it's from the school asking to "confirm" a login. The Create, Protect, Recover routine below takes about ten minutes to teach and keeps working as a child moves from their first gaming account to the school and email logins they manage alone.

Create a password and motivation to protect important things 

A password protects the things your child cares about online, including schoolwork, game progress, messages, photos, and personal information. Describe it as a key to a digital room: someone who gets the key may enter the room, change what is inside, or lock its owner out.

This analogy gives children a reason to care without frightening them. Start by showing your child what each account holds.

Give the email password special attention. Email services often receive password-reset links for other accounts, so access to email may lead to access elsewhere. CEOP Education (the UK National Crime Agency's child safety programme) advises families to use a separate, strong password for email.

Ask what your child wants to keep safe in each account. Their answer might be a drawing, a message from a friend, or saved game progress. Password safety for kids makes more sense when the password protects something they value.

Teach children password security in a way that is age-appropriate 

Teach children password security by matching responsibility to their age, confidence, and account type. Give every account its own long passphrase, then increase independence gradually. Keep a clear route for asking for help with forgotten passwords, suspicious messages, lost devices, and account recovery.

A passphrase is a longer password made from several words. Choose words the child can remember but other people cannot connect to them. Leave out names, birthdays, school names, addresses, pets, favourite teams, and details posted online.

Each account needs a different passphrase. If a reused password appears in a data breach, someone can try it on the child's other accounts.

NIST's 2025 consumer guidance recommends at least 15 characters when a password is required and treats length as the main priority. Use that figure as guidance for parents rather than a test the child must pass. A password manager can store long passwords that are difficult to remember.

Avoid forcing children to add symbols and numbers unless the website requires them. Substituting a number for a letter often creates an easy-to-predict pattern. Follow the website's rules while prioritising length and uniqueness.

Ages 5–8: Learn the privacy rule

Children in this age range can learn that a password stays secret from friends, classmates, other players, and strangers. A parent or guardian may help them create, enter, store, or recover it.

Keep the lesson short. Say: "This password opens your account. We keep it private, and you can always ask me for help."

Ages 9–12: Create a passphrase together

Let the child choose several unrelated words. Check that the words contain no personal facts, then explain that the finished passphrase belongs to one account.

Ask the child to explain the rule back to you. If they can describe why password reuse is risky, they have understood the reason behind the rule.

Teens: Hand over responsibility gradually

Teens can create and store their own passwords, review recovery options, and manage a second sign-in check. Agree in advance on what they should do if they lose access or respond to a suspicious message.

Respect their growing privacy while keeping a no-shame help rule. Reporting a mistake early should lead to calm action. UNICEF's online privacy checklist for parents recommends giving older children age-appropriate responsibility for their privacy and security.

Try this tonight: The five-minute passphrase check

• Choose one low-risk account your child already uses.
• Ask what information or activity the account protects.
• Check that its password is unique and contains no personal facts.
• Decide where the family will store it safely.
• Practice this sentence: "Something looks wrong with my account, so I need help."

Protect the password after it is made

A good passphrase works only when the family can keep it private, store it safely, and recover the account if something goes wrong. Start with email, school, gaming, shopping, and social accounts. They may contain personal information, saved purchases, private messages, or payment details.

Use the Create, Store, Add a Second Check plan:

• Create a unique password for each account. Use a long passphrase when the child needs to type or remember it. Let a password manager generate a random password when memorisation is unnecessary.
• Store it securely. A password manager is a tool that creates and stores different passwords so the family does not need to remember them all. Its master password opens the password vault, so the responsible parent should create and protect it carefully.
• Add a second check. Two-factor authentication (2FA) adds another check after the password. This might be an approval on a device or a code from an app. You may also see this called 2-step verification, 2SV, or MFA.

Turn on 2FA for important accounts when the service offers it. Keep recovery codes private and store them separately from the password. Anyone with a working recovery code may be able to enter the account.

A passkey lets someone approve a sign-in with a device PIN, fingerprint, or face scan instead of typing a password. If you see this option, check how the account can be recovered if the device is lost or replaced.

The UK's National Cyber Security Centre recommends passkeys where supported and 2-step verification where passkeys are unavailable. Recovery options still differ by service and the child's age.

Recognize phishing and keep the password private

Give children one exact boundary: "Never share a password with a friend, classmate, other player, or stranger." Younger children may need help from a parent or guardian. As children become more independent, agree on recovery and reporting rules instead of demanding access to every account.

A request for a password can sound friendly or urgent. Another player might offer free game items. A message that seems to come from school might claim the child's account will close unless they sign in immediately.

Phishing is a fake message or website that tries to steal a password, verification code, or personal information. Children do not need to judge every message alone. Teach them to pause and ask for help.

Pause before you sign in

• Stop. Do not reply or enter a password.
• Do not click the link. Show the message to a trusted adult.
• Open the official app, use an existing bookmark, or type a known address.

The FTC gives the same advice. Contact an organisation through an app, phone number, or website you already know is genuine, rather than using details in the suspicious message.

A game message might say, "Confirm your account now to keep your items." Tell your child to stop. If appropriate, take a screenshot and ask an adult to check the account through the normal app.

Never blame a child for clicking. Shame delays reporting. A quick report gives the family more time to change the password, review activity, and stop further changes.

Recover an account without panic

Recover an account through the service's official route, change the exposed password, and check what happened. The child should tell a trusted adult first. Together, they can review recent activity, remove unknown devices, restore the second sign-in check, and store new recovery details safely.

Use the Recover part of the Create, Protect, Recover routine:

• Tell a trusted adult. Explain what happened, including any link opened, password entered, code shared, purchase noticed, or unexpected sign-in reported.
• Open the official service. Use its known app, a saved bookmark, or an address that the parent types directly. Avoid links and phone numbers from the suspicious message.
• Reset the password. Follow the service's official account-recovery process on a familiar, updated device. Create a new, unique password. If the old password was reused, change it on every account where it appears.
• Review account activity and devices. Look for unfamiliar sign-ins, messages, purchases, profile changes, or recovery addresses. Sign out of devices the family does not recognise, if the service offers that option.
• Restore account protection. Turn 2FA back on, confirm that the passkey still works, and replace any recovery codes that may have been exposed. Treat recovery codes as private credentials and store them securely.

What to check after a reset

• The new password is unique.
• The recovery email address or phone number is correct.
• Unknown devices have been signed out where possible.
• 2FA or the passkey remains active.
• Purchases, messages, and profile changes look familiar.
• Saved passwords on shared devices have been updated.
• Parental controls and privacy settings remain correct.

Recovery steps differ by service. For example, Google says that changing the password of a supervised child account turns off 2-Step Verification. Families using that account type need to turn it on again after the reset.

Make password security a family habit

To teach children password security, practise the Create, Protect, Recover routine until asking for help feels normal. Start with one account today: review its passphrase, add a second sign-in check if available, and ask your child who they would tell if a login looked wrong.

Frequently asked questions

How to create a strong password you won’t forget (2026 guide)

Complexity rules failed. Adding @ to your dog’s name doesn’t make a password strong — it makes it predictable. This guide covers what NIST SP 800-63B actually requires, why Diceware beats every complexity rule, and the one-passphrase system that solves the rest.

PassworkPasswork Team

10 remote work security fails: How to fix your environment

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

PassworkAlex Muntyan

How to choose a corporate password manager: 10 criteria for enterprise IT teams

A structured 10-factor framework for evaluating corporate password managers — covering encryption architecture, access control, compliance, deployment model, audit logging, and TCO. Built for IT and security teams who need a defensible decision, not just a demo.

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

Passwork encrypts every vault with its own independent key. Bitwarden encrypts an entire organization with one shared key. That single design choice decides how far a stolen credential can reach: a per-vault key exposes one vault, while a single shared organization key may compromise every corporate item the company owns.

This difference determines the blast radius after a compromise, how account recovery works, and whether one team's incident can spread into another team's data. Both approaches are documented, legitimate zero-knowledge designs. They just carry different operational consequences, and that's what this comparison covers.

You'll feel this difference concretely during an offboarding, during an acquisition where two teams' vaults suddenly need separate handling, or in a post-incident review where you have to state exactly what an attacker could reach with one stolen key. Naming that up front makes the rest of this comparison easier to apply to your own environment, whichever password manager you run today.

How Passwork encrypts vaults

Passwork runs on a zero-knowledge architecture: the server never holds enough information to decrypt vault data, and the master password never leaves the user's device. Every cryptographic key is generated client-side, so the server stores only ciphertext and public keys (security overview, cryptography overview).

Two layers of encryption

Passwork runs two layers of encryption. Server-side encryption (AES-256) protects everything at rest and is always active. Client-side encryption protects sensitive fields before they ever leave the device.

The key hierarchy: From master password to vault key

What matters most for this comparison is the key hierarchy. A master password derives a master key through PBKDF2. That master key decrypts a private RSA key. The private RSA key then decrypts a vault key: a symmetric AES-256 key generated on the client specifically for one vault.

Every vault gets its own vault key, generated independently the moment the vault is created. Each user with access holds a separate encrypted copy of that key, wrapped with their own public RSA key, and only the matching private key can unwrap it. Compromising one vault's key does not expose the key of any other vault.

Isolation below the vault: Records and attachments

The isolation continues below the vault. Each record gets its own record key, encrypted with the vault key, and each file attachment gets its own attachment key, encrypted with the record key. A leaked record key exposes one record, not the whole vault. A leaked attachment key exposes one file. The vault key sits in the middle of that chain, separating one vault's records from every other vault's records, which is the layer this comparison focuses on.

Sharing without exposing the key

Sharing follows the same pattern. Granting a colleague access means the current holder decrypts the vault key with their own private key and re-encrypts it with the recipient's public key. The server only ever handles ciphertext (sharing mechanics). Access levels such as View, Edit, Full access, and Administrator are enforced by the application, not by the cryptography: everyone with access to a vault holds the same underlying key, and permissions govern what the interface lets each person do with it.

How Bitwarden encrypts organization data

Bitwarden encrypts all organization-owned vault data with one shared key: a CSPRNG-derived Organization Symmetric Key generated once for the entire organization. According to Bitwarden's own security whitepaper, this single key decrypts every corporate vault item. The unprotected key itself is never stored on Bitwarden's servers.

One organization key, many cipher keys

Individual items still get their own key. Each cipher (Bitwarden's term for a stored item) has a unique 64-byte Cipher Key. That Cipher Key is wrapped by either a personal User Symmetric Key or, for anything the organization owns, the single Organization Symmetric Key. Unwrapping that one organization key exposes every corporate cipher key at once, because they all trace back to the same parent key.

Collections control access, not encryption

Collections, Bitwarden's grouping mechanism, sit on top of this without changing the cryptography. A collection controls which members and groups can see which items, but adds no separate collection-level key. A single organization key decrypts the contents of every collection belonging to that org, a point confirmed both by Bitwarden's own server documentation. Removing someone from a collection revokes access through membership, not through a cryptographic boundary tied to that specific collection.

Account recovery relies on the same shared key

Account recovery follows the same single-key pattern. When a member enrolls in Bitwarden's account recovery feature, their personal User Symmetric Key gets wrapped with the organization's RSA public key, forming what Bitwarden calls the Account Recovery Key. To recover a locked-out member, the organization's private RSA key unwraps that Account Recovery Key and yields the member's personal encryption key. A single admin holding the Manage account recovery permission can do this for any enrolled member.

Vault policies vs collections

Passwork distinguishes vaults by type, not only by owner. The documentation defines two basic vault types: Company vaults, shared storage with configurable access rights for a team, and Personal vaults, storage created by and initially belonging to a single user.

Both types get identical per-vault key treatment, so a Personal vault is as cryptographically isolated from a Company vault as any two Company vaults are from each other.

Personal vaults can become shared vaults

A Personal vault isn't locked to one person permanently. Its owner can share it with colleagues, and at that point it functions as a shared vault, with access governed the same way as any other shared vault in Passwork.

Custom vault types and mandatory admin assignment

Passwork also lets administrators define an unlimited number of custom vault types, each with its own set of designated administrators and its own access rules. That gives an organization a way to enforce, say, one admin group for finance vaults and a different one for engineering vaults, without relying on ad hoc permission assignments after the fact.

Administrators can also disable Personal vault creation altogether, forcing all data into Company or custom vault types where the admin assignment is mandatory.

How this compares to Bitwarden collections and Enterprise Policies

Bitwarden has no equivalent typed-vault abstraction. Its closest analogue, collections, group items inside an organization but don't isolate them cryptographically: as covered earlier, a single Organization Symmetric Key decrypts every collection's contents, and removing a member from a collection revokes access through membership, not through a separate key boundary. Collections also carry no concept of a dedicated administrator set the way Passwork's Company and custom vault types do.

Bitwarden's Enterprise Policies work at a different layer entirely. Policies like Single organization, Centralize organization ownership, Master password requirements, Require two-step login, and Account recovery administration apply organization-wide, not per collection or vault type (Bitwarden policies documentation). An administrator applying a master-password-strength policy, for example, sets a rule for the whole organization. There's no per-collection or per-vault-type equivalent to scope that rule more narrowly.

The practical difference

Passwork's vault policies give an administrator a structural way to separate individual data from team data, assign accountable admins per type, and keep every instance of either type on its own key. Bitwarden's collections organize access within a single shared key, and its policies configure behavior across an organization that already shares that key, regardless of which collection or data type a given policy targets.

What this means in practice

The key architecture behind each product produces four concrete operational differences: blast radius after a compromise, how cleanly teams can be isolated, how recovery works, and how an audit answers "what could this credential decrypt."

Blast radius of a single compromised secret

In Passwork, a leaked vault key, a leaked private RSA key, or a compromised master password limits an attacker to one vault or to that one user's shared vaults, not the whole organization. In Bitwarden, because every corporate cipher key traces back to one Organization Symmetric Key, compromising that key exposes every vault item the organization owns.

Multi-team isolation

An organization running several teams in Passwork can give each team its own vault, each on its own key, so an incident in one team's vault has no cryptographic path into another team's vault. In Bitwarden, teams are typically separated with collections inside the same organization, which is access control layered on top of one shared organization key.

Recovery model

Passwork's recovery process doesn't restore the original master key. It establishes a new one, and a user keeps access only to vaults where access was already shared with another account beforehand. Bitwarden's account recovery relies on a single organization RSA key pair, so one admin with the right permission can recover any enrolled member without that member having pre-shared anything (account recovery documentation). That's operationally convenient. It also means the organization's recovery RSA private key is a single point of exposure for every enrolled member's vault.

Audit and compliance scoping

When an auditor asks "what could this credential decrypt," Passwork's per-vault model gives a short, specific answer: one vault, or a named list of vaults this user had access to. In Bitwarden's single-organization-key model, the honest answer to the same question is "everything the organization owns," because there's no cryptographic subdivision below the organization level to point to. Neither answer is wrong, but they document very differently in an audit evidence package.

Comparison table

The table below summarizes where the two architectures diverge, from the root key down to sharing and recovery.

Getting practical about it

The question isn't which vendor's cryptography is better in the abstract. It's whether your data actually needs single-key or per-vault isolation. Teams handling regulatory-scoped secrets, a specific client's infrastructure, or a compliance boundary that has to stay separate get a direct benefit from per-vault keys. Teams where everyone already shares full mutual trust get less benefit from the extra isolation.

Both architectures qualify as zero-knowledge. The difference is what a single stolen key can reach afterward: one vault, or the whole organization. That's the number to check against your own risk model before your next security review.

Want to see per-vault key isolation on your own data before deciding? Try Passwork free and test how vault types, admin assignment, and key boundaries hold up against your own security review.

Frequently asked questions

SaaS credential management: 5 steps to centralize your app stack

SaaS credential management turns scattered passwords and API keys into one inventory you can share on purpose and revoke on exit. Here’s the five-step framework: inventory, structure, migration, access control, and automation.

PassworkPasswork 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.

PassworkAlex Muntyan

Passwork’s vault policies: a CIO’s guide to enterprise security

Passwork’s Vault Types bind admin rights to the vault policy itself, not to whoever created it, closing a gap most enterprises don’t even know exists. This guide gives CIOs and CISOs a working model for vault governance, mapped to NIS2 and ISO 27001 requirements.

PassworkPasswork Team

"Can I migrate from [competitor] in one click?" is one of the most common questions vendors hear on sales calls, especially right after a competitor's breach makes headlines. Vendors present one-click migration as a convenience feature. In enterprise environments, it's only the starting point.

A working password manager migration recreates vault hierarchy, ownership, permissions, service accounts, automation, and integrations. The quality of that reconstruction decides whether users, applications, and infrastructure keep operating securely after cutover.

Verizon's 2026 Data Breach Investigations Report found that 39% of System Intrusion breaches involved stolen credentials, while 84% involved servers. As password managers become part of the infrastructure control plane, migration accuracy directly affects operational reliability and security.

This article explains why enterprise migration is an engineering project and how to run one without breaking production access on the way.

Migration starts with mapping access models

No universal import tool can accurately recreate an organization's access model, because security models rarely match between platforms.

Different password managers implement role-based access control, permission inheritance, shared vault ownership, and group membership differently. Even when two systems support the same concepts, they often implement them with different assumptions.

Consider three organizations:

• Company A organizes vaults by business function.
• Company B organizes them by product teams.
• Company C organizes them by customers and projects.

Hierarchy is only the visible part of the problem. The real challenge is translating security semantics between systems.

A source platform may inherit permissions through nested groups. The destination may require explicit assignments instead. Shared vault ownership might have no direct equivalent. An administrative role may bundle privileges that need to become multiple roles after migration. RBAC models almost never map one-to-one.

Passwork's own vault types show why. A shared company vault and a shared user vault carry different assumptions about who can see what. An importer has to make that call, not infer it from a folder name.

The same logic applies to structure handling. During import, an admin can:

• Rebuild the source hierarchy under an existing folder
• Flatten everything into one destination
• Recreate the full vault tree at the root

Each option is a deliberate choice about how the organization wants to operate going forward, and that choice depends on how the organization actually works.

A generic importer copies field values. Deciding which permissions to preserve, translate, merge, or drop requires judgment a script doesn't have.

Attackers increasingly target legitimate administrative access, exactly what's being migrated: trusted accounts and the paths that make privileged operations work. A correct migration keeps those paths behaving as intended after cutover.

Some objects can be copied, others must be redesigned

Enterprise password manager migration reshapes an organization's access model across four distinct layers: identity context, access policies, operational integrations, and trust boundaries. Each layer introduces technical constraints that a flat import file cannot represent.

The gap between copied and redesigned shows up clearly in real migration tooling. Passwork's official Bitwarden importer, for example, moves login items, secure notes, collections, folder structure, URLs, and TOTP codes automatically. It deliberately skips attachments and any item type it doesn't recognize, logging each skip instead of guessing at a mapping. That's a design decision, not a limitation: some objects can be copied safely, and some need a human to decide what happens to them.

Service accounts without clear owners, inherited permissions, obsolete integrations, and long-forgotten shared vaults fall into the second category. A successful migration preserves only what still reflects the organization's intended access model.

Any one of these handled incorrectly creates a gap: an orphaned integration, a contractor retaining production access, or an automation account authenticating against the wrong destination. None of these appear as import errors. They usually surface weeks later as incidents.

The right mental model for migration, and how Passwork applies it

Once migration is treated as an architectural transformation, the implementation naturally follows the same engineering principles used elsewhere in infrastructure projects: make every step explicit, reviewable, and reproducible.

Rather than relying on a black-box importer to interpret an organization's structure, the migration process should expose every transformation as code. Engineers should be able to inspect exported data, define how it is translated, and control exactly how every object is recreated in the destination system.

Passwork supports three migration paths, chosen by source and volume rather than by convenience:

The first two cover most real-world moves. The third makes the "transformation as code" principle visible. A migration script built on Passwork's Python connector authenticates, creates the destination vault and folder structure explicitly, and writes each item with exactly the fields the organization wants preserved:

from passwork_client import PassworkClient

passwork = PassworkClient("https://passwork.example.com")
passwork.set_tokens(access_token, refresh_token)
passwork.set_master_key(master_key)

vault_type = passwork.find_vault_type(code="company")
vault_id = passwork.create_vault("Migrated – IT", vault_type["id"])
vault = passwork.get_vault(vault_id)

folder = passwork.call("POST", "/api/v1/folders", {
    "name": "Databases",
    "vaultId": vault["id"],
})

passwork.create_item({
    "name": "Postgres primary",
    "login": "app_rw",
    "password": "...",
    "urls": ["https://db.internal"],
    "description": "Imported from Bitwarden",
    "vaultId": vault["id"],
    "folderId": folder["id"],
    "customs": [
        {"name": "TOTP", "value": "otpauth://...", "type": "totp"},
    ],
})

Nothing lands in a vault, a folder, or a permission set unless the script says so. For a full Passwork-to-Passwork move, the same logic scales to bulk REST endpoints — vaults/import, folders/import, and items/import — which return a sourceId → id map so parent objects are created before their children and every relationship stays intact.

The transformation stage is where migration becomes predictable. Engineers can encode migration rules explicitly: rename vaults, remap owners, split administrative roles, flatten inherited permissions, or exclude obsolete records altogether. Those decisions become reviewable code rather than assumptions hidden inside a generic import wizard. If the migration needs to be repeated or audited later, the transformation logic stays transparent and reproducible.

This also changes how the migration itself is secured. Traditional one-click imports typically generate an intermediate plaintext export, often a CSV, that is then processed by a generic parser with limited understanding of the destination environment. Each stage introduces its own security considerations.

If something goes wrong mid-batch, recovery is manual: delete or bin the affected vault, then re-run the script against staging. That's exactly why a dry run is worth the extra hour before a production cutover.

Validate behavior, not just imported records

Import and migration mark two separate checkpoints. Import confirms that credentials exist in the destination vault. Migration confirms that the environment behaves exactly as intended once production workloads depend on it.

A practical validation phase should answer questions such as:

• Can every authorized user access the vaults they're expected to use?
• Are unauthorized users correctly denied access?
• Do CI/CD pipelines, infrastructure automation, and API integrations retrieve secrets without modification?
• Are service accounts functioning with the expected permissions?
• Do audit logs record authentication events, permission changes, and administrative actions correctly?

These checks often surface issues that appear only after import completes. A migrated credential may sit in the correct folder while remaining inaccessible to the automation that depends on it. A role translation error may silently grant broader access than intended, passing import validation cleanly.

Passwork's activity log (events like item_imported and vault_imported) gives auditors a paper trail for exactly this kind of check, and the Security Dashboard flags weak or duplicate passwords that came along for the ride from the old vault, so they can be rotated rather than carried forward. Records missing a URL are worth a second pass too: autofill won't work on them until someone fixes the field.

Successful migration is measured by operational behavior. The destination system should enforce the same security model as before, or a deliberately improved one, rather than merely hold the same secrets.

Turning password manager migration into a security audit

Migration is often the only moment when an organization reviews every stored credential and every permission at the same time.

Day-to-day administration tends to be incremental: users are added, projects evolve, integrations accumulate, and access rights gradually expand. A migration interrupts that process and forces every object to justify its place in the new environment. That's why a structured migration often doubles as the most comprehensive access review an organization has performed in years.

During this review, teams typically discover:

• Orphaned secrets belonging to employees who left months ago
• Duplicate credentials for the same service stored across multiple vaults
• Inactive users still holding production access
• API keys that expired but were never removed
• Personal credentials stored inside corporate vaults
• Credentials for systems decommissioned long ago but never deleted

A bulk import silently carries these problems into the new platform. A transformation-based migration exposes them, because every credential, owner, and permission must be evaluated before it's recreated.

Verizon's 2026 DBIR reports that 27% of ransomware victims had evidence of an infostealer or credential leak during the previous year, and among those organizations, half were exposed within 95 days before the ransomware incident occurred. Migration is one of the few opportunities to revoke exposed or obsolete credentials before they become part of an attack chain.

The same report also notes that resolving weak passwords and permission misconfigurations across third-party cloud environments takes organizations nearly eight months on average. Doing that review during migration compresses those eight months into a planned engineering activity instead of a prolonged remediation effort.

Under GDPR Article 32, organizations must implement technical and organizational measures appropriate to the risks of processing personal data. Removing stale access and orphaned credentials during migration demonstrates those controls in practice rather than simply documenting them.

Seven steps that reduce migration risk before production

The Passwork migration workflow treats migration as an engineering project with explicit checkpoints rather than a single import operation.

1. Inventory

Document existing vaults, service accounts, integrations, automation, and external dependencies before writing any migration code.

2. Export

Extract data from the source system in a structured format. JSON is generally preferable because it preserves hierarchical relationships — Passwork's own JSON export keeps vault and folder structure intact, while CSV flattens everything into a table.

3. Review

Identify stale, duplicate, orphaned, or over-privileged credentials before they're migrated.

4. Transform

Implement migration rules that map the source environment to the destination hierarchy, ownership model, RBAC configuration, and naming conventions.

5. Test import

Run the migration against a staging environment to verify objects are created correctly before touching production. Passwork's own guidance for the Bitwarden script is explicit on this point: back up the destination database and dry-run on staging before a real cutover.

6. Validate permissions

Confirm that:

• authorized users have access;
• unauthorized users do not;
• service accounts authenticate successfully;
• CI/CD pipelines and integrations continue to function;
• audit logs capture expected security events.

7. Production migration

Execute the production migration in phases rather than one sweep — shared IT and infrastructure credentials first, then department vaults one team at a time, then private vaults once users are activated. Run the old and new systems in parallel for two to four weeks, spot-check with each department owner, and only decommission the source platform once adoption is real, not assumed.

Skipping either the testing or permission validation stages usually doesn't eliminate the work. It postpones it until production users or automated systems start failing after cutover.

Getting migration right

The easiest migrations move passwords. Successful migrations recreate how an organization operates: who owns each credential, how permissions are inherited, which systems depend on shared secrets, and which access paths should no longer exist.

One-click imports optimize for speed. Enterprise migrations optimize for correctness, auditability, and predictable behavior after cutover. Those goals rarely point in the same direction.

If there's one action worth taking before scheduling a migration, it's the first step in the workflow above: build an accurate inventory of your vaults, service accounts, integrations, and permission model before writing a single line of migration logic.

The best migration scripts document every migration decision along the way. Long after cutover, those transformation rules become a record of why access was mapped the way it was — making future audits, troubleshooting, and repeat migrations significantly easier.

Password manager migration FAQ

Data sovereignty and password management: Keeping credentials where they belong

Data sovereignty for credentials requires three controls (location, encryption, access) not just GDPR compliance. Compares on-premise, air-gapped, and EU cloud models, showing where zero-knowledge architecture like Passwork’s actually closes the sovereignty gap.

PassworkPasswork Team

Passwork’s vault policies: a CIO’s guide to enterprise security

Passwork’s Vault Types bind admin rights to the vault policy itself, not to whoever created it, closing a gap most enterprises don’t even know exists. This guide gives CIOs and CISOs a working model for vault governance, mapped to NIS2 and ISO 27001 requirements.

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

Zentralisierte Passwortverwaltung für KMU bezeichnet die Praxis, alle Geschäftszugangsdaten über eine einzige gesicherte Plattform zu speichern, zu teilen und zu kontrollieren — anstatt über Tabellen, Browser oder Chat-Nachrichten. Sie bietet kleinen und mittelständischen Unternehmen dieselbe Kontrolle über Zugangsdaten, auf die auch Großunternehmen setzen — ohne das Preisschild und ohne das Sicherheitsteam, das für den Betrieb erforderlich wäre.

Die meisten kleinen und mittelständischen Unternehmen „verwalten Passwörter" bereits auf irgendeine Weise. Jemand speichert Zugangsdaten im Browser. Jemand anderes nutzt einen kostenlosen lokalen persönlichen Tresor wie KeePass. Gemeinsam genutzte Admin-Logins für Stripe, Google Workspace oder das ERP befinden sich in einem Slack-Thread vom letzten Jahr. Das ist Passwortspeicherung. Es ist keine zentralisierte Passwortverwaltung.

Im Jahr 2026 bedeutet zentralisierte Passwortverwaltung für KMU ein unternehmenseigenes System, in dem Team-Zugangsdaten in gemeinsamen Tresoren liegen, Zugriff bewusst gewährt wird und ausscheidende Mitarbeiter keine Firmen-Logins mehr sehen — ohne aufwendige Suche. Derselbe Zugangsdaten-Tresor kann menschliche Passwörter und maschinelle Geheimnisse (API-Schlüssel, Tokens, Datenbank-Verbindungsstrings) aufnehmen, da der Stack nicht mehr zwischen „Apps, die Menschen anklicken" und „Apps, die Pipelines aufrufen" unterscheidet.

Was zentralisierte Passwortverwaltung tatsächlich bedeutet

Zentralisierte Passwortverwaltung bedeutet, dass ein unternehmenseigenes System alle gemeinsam genutzten Geschäftszugangsdaten speichert und kontrolliert — mit definierten Rollen, Berechtigungsstufen und einem Nachweis darüber, wer auf was zugegriffen hat. Sie unterscheidet sich von einem persönlichen Passwort-Manager (z. B. KeePass), der die Logins einer einzelnen Person schützt, und von Enterprise Privileged Access Management (PAM), das zusätzlich Sitzungsaufzeichnung und Just-in-Time-Erhöhung für Infrastrukturzugriff bietet.

Ein persönlicher Passwort-Manager löst das Login-Problem einer einzelnen Person. Zentralisierte Passwortverwaltung löst das Problem der Organisation: Wer kann auf was zugreifen, wann und mit wessen Genehmigung. Diese Unterscheidung ist der entscheidende Punkt.

In der Praxis basiert Zentralisierung auf fünf Mechanismen:

1. Ein System of Record für Unternehmenszugangsdaten — nicht fünf inoffizielle Kopien, die über verschiedene Tools verstreut sind.
2. Gemeinsame Tresore und Ordner nach Teams oder Abteilungen strukturiert, sodass die gemeinsame Nutzung von Zugangsdaten dem Organigramm folgt.
3. Zugangslevel, von Nur-Lesen bis Tresor-Admin, damit niemand einen einzigen gemeinsamen Master-Login für das gesamte Büro benötigt.
4. Ein Aktivitätsprotokoll, das beantwortet, wer bestimmte Zugangsdaten angesehen, geändert oder exportiert hat.
5. Raum zum Wachsen. Die Plattform sollte LDAP/AD oder SSO unterstützen, sobald das Unternehmen dafür bereit ist, damit das Identitätsmanagement mit dem Team skaliert, anstatt später ein neues Tool zu erfordern.

Persönliche Passwort-Manager bleiben nützlich für persönliche Konten. Sie versagen, wenn die Zugangsdaten dem Unternehmen gehören: Rechnungsverantwortliche wechseln, Auftragnehmer rotieren, und niemand kann nachweisen, wer noch das AWS-Root-E-Mail-Passwort hat.

Warum KMU dies 2026 stärker spüren

Vier Belastungen kommen gleichzeitig zusammen, und keine davon existierte in dieser Kombination vor fünf Jahren. Ein 40-Personen-Unternehmen betreibt heute Dutzende von SaaS-Tools ohne ein dediziertes Sicherheitsteam, verteilt seine Belegschaft auf Home-Netzwerke und Cafés und fügt zunehmend Zugangsdaten in KI-Tools ein, die niemand geprüft hat.

• SaaS-Wildwuchs ohne eine IT-Abteilung von zwanzig Mitarbeitern. Ein kleines Unternehmen kann am Ende Dutzende von Cloud-Tools betreiben, ohne dass jemand dediziert für die Zugriffsverwaltung zuständig ist. Jedes Tool benötigt ein Admin-Login, und die meisten Teams lösen dies auf die schnelle Art: ein gemeinsames Postfach und ein Passwort, das irgendwo notiert ist, wo jeder es finden kann. Sechs Monate später ist niemand mehr für dieses Passwort verantwortlich, und niemand erinnert sich, wer es gesehen hat.
• Hybrides und Remote-Arbeiten. Ein Passwort über Slack oder E-Mail zu senden war schon riskant, als alle im selben Büro arbeiteten. Wenn sich Mitarbeiter über Heimrouter und private Laptops einloggen, ist Autofill aus einem gemeinsamen Tresor die einzige Option, die kein Eintippen eines Passworts in ein Chat-Fenster erfordert.
• Offboarding-Risiko. Wenn jemand geht, geht alles mit, was in seinem persönlichen Tresor, Browser oder Notizen-App gespeichert war. Ein zentralisierter Passwort-Manager ermöglicht es, das Konto zu deaktivieren, die Person aus jeder Gruppe zu entfernen und die gemeinsamen SaaS-Logins zu rotieren, die nur auf deren Laptop existierten. Ohne dies findet eine Zugriffsüberprüfung erst statt, nachdem etwas schiefgegangen ist.
• Schatten-KI ist das neueste Leck. Mitarbeiter fügen jetzt API-Schlüssel, Datenbank-Strings und Passwörter bei der Fehlerbehebung in ChatGPT oder Copilot ein, und keine dieser Aktivitäten berührt einen Tresor oder ein Audit-Protokoll. Laut IBMs Cost of a Data Breach Report 2026 war Schatten-KI an 43 % der Sicherheitsverletzungen beteiligt — gegenüber 20 % im Vorjahr — und 92 % der Organisationen, die von einer KI-bezogenen Verletzung betroffen waren, fehlten grundlegende KI-Zugriffskontrollen.

Wo steht Ihr Unternehmen tatsächlich bei der Passwortverwaltung

Die meisten KMU befinden sich in einer von vier erkennbaren Phasen — von Ad-hoc-Chaos bis hin zu zentralisierter Governance. Jede Phase birgt ein spezifisches Risiko, und der Übergang zur nächsten schließt es.

Phase 1: Ad-hoc-Chaos

Tabellen, Haftnotizen, Slack-Direktnachrichten mit eingefügtem Passwort.

Phase 2: Browser-basierte Speicherung

Chrome oder Edge speichert die Passwörter.

Phase 3: Einfacher Passwort-Manager

Ein Team hat ein Tool eingeführt, aber niemand verwaltet es.

Phase 4: Zentralisierte Governance

Ein strukturierter Tresor, RBAC, Audit-Protokollierung und eine durchgesetzte Richtlinie arbeiten zusammen. Das Risiko sinkt deutlich.

Laut Verizons Data Breach Investigations Report 2026 tauchten gestohlene oder wiederverwendete Zugangsdaten bei 39 % aller Sicherheitsverletzungen auf — in der Regel gepaart mit einer ausgenutzten Schwachstelle oder einem kompromittierten Drittanbieter, anstatt allein zu agieren. Diese Angreifer passen ihre Methoden nicht an die Unternehmensgröße an. CrowdStrikes State of SMB Cybersecurity Survey 2025 stellte fest, dass unter KMU, die einen Cyber-Vorfall erlebten, 29 % derjenigen mit weniger als 25 Mitarbeitern von Ransomware betroffen waren — die höchste Rate aller Unternehmensgrößengruppen, größere KMU eingeschlossen.

Die kleinsten Teams sind am wenigsten in der Lage, diesen Treffer zu verkraften. Teams in den Phasen 1 und 2 haben keinen Mechanismus, um kompromittierte Zugangsdaten zu erkennen oder schnell zu widerrufen, weil überhaupt nichts zentralisiert genug ist, um es zu überprüfen. Genau diese Lücke schließt Phase 4.

Warum KMU das Ziel sind, nicht die Ausnahme

KMU sind denselben Verletzungsmustern ausgesetzt wie Organisationen jeder Größe, und Angreifer wählen sie selten nach Branche oder Umsatz aus. Laut Verizons Data Breach Investigations Report 2026 bleibt System Intrusion das häufigste Verletzungsmuster bei kleinen Organisationen — dasselbe Muster, das auch bei Großunternehmen führend ist — und finanziell motivierte externe Akteure führen die meisten dieser Angriffe durch.

„Wir sind zu klein, um interessant zu sein" ist die falsche Einschätzung der Bedrohungslage. Verizons eigene Forscher formulieren es direkt: Angreifer, die KMU treffen, „werfen weite Netze aus" in der Hoffnung, dass genug Opfer zahlen — ohne vorher Unternehmensgröße oder Branche zu recherchieren. Was entscheidet, wer angegriffen wird, ist einfacher und banaler: ob ihre Zugangsdaten bereits kompromittiert waren oder ihre Edge-Geräte eine ungepatchte Lücke hatten.

Die Daten auf Aktionsebene bestätigen dies. Unter den von Verizon analysierten KMU-Verletzungen trat Ransomware in 83 % der Vorfälle auf, die Verwendung gestohlener Zugangsdaten in 39 % und ausgenutzte Schwachstellen in 30 %. Die Ransomware-Zahlen treffen speziell die kleinsten Unternehmen am härtesten: Bei den Ransomware-Fällen, bei denen Verizon die Organisationsgröße bestätigen konnte, waren etwa 96 % der Opfer KMU.

Vor dem Hintergrund solcher Zahlen ist eine Passwort-Plattform mit Preis pro Benutzer pro Monat keine diskussionswürdige Ausgabe. Es sind kleine, vorhersehbare Kosten gegen eine Bedrohung, die nicht nach Unternehmensgröße diskriminiert.

Die Lücke zu schließen, die gestohlene Zugangsdaten hinterlassen, erfordert kein großes Budget oder eine lange Einführungsphase. Testen Sie Passwork kostenlos und sehen Sie, wie ein strukturierter Tresor, rollenbasierte Zugriffskontrolle und Audit-Protokollierung in Ihrer eigenen Infrastruktur aussehen.

Worauf Sie bei einer zentralisierten Passwortverwaltungs-Plattform achten sollten

Eine zentralisierte Passwortverwaltungs-Plattform für KMU benötigt gemeinsame Tresore mit Ordnerstruktur, granulare RBAC, vollständige Audit-Protokollierung, erzwungene MFA und ein Bereitstellungsmodell, das zu Ihren Compliance-Anforderungen passt — ob Self-Hosted oder Cloud-Hosted. Automatisiertes Offboarding und API-Zugriff werden relevant, sobald das Team über eine Handvoll Personen hinauswächst.

Hier ist, was Sie vor der Auswahl prüfen sollten:

Tresorstruktur

Ordner oder Tags, die nach Abteilungen organisiert sind, halten Zugangsdaten auffindbar, ohne dass eine Suchleiste die ganze Arbeit erledigen muss.

Passwork organisiert Zugangsdaten in Tresoren und verschachtelten Ordnern, die auf Abteilungen und Projekte abgebildet sind. Das Hinzufügen eines neuen Benutzers sollte nicht bedeuten, durch zwanzig Passwörter klicken zu müssen. Die spätere Zuordnung von Verzeichnisgruppen (LDAP/AD) ist optional — die Gruppen-Gewohnheit sollte vom ersten Tag an beginnen.

RBAC-Granularität

Gute Plattformen trennen zwei Berechtigungsebenen: Systemrollen (wer kann Benutzer einladen, SSO konfigurieren, Protokolle lesen) und Ressourcen-Zugangslevel (wer kann einen bestimmten Tresor oder Ordner sehen oder bearbeiten). Die meisten Mitarbeiter benötigen nur Lese- oder Schreibzugriff auf den Tresor ihres eigenen Teams. Admin-Rollen sollten selten bleiben.

Passwork wird mit vordefinierten Rollen ausgeliefert und ermöglicht das Erstellen benutzerdefinierter Rollen, wie AD Administrator oder DevOps, die genau auf die Berechtigungen beschränkt sind, die diese Rolle benötigt. Diese Trennung ist in der Praxis wichtig: Ein Auditor, der das Protokoll überprüfen kann, sollte nicht automatisch Tresorinhalte bearbeiten können, und ein Systemadministrator, der LDAP-Sync verwaltet, sollte keinen Zugriff auf die Zugangsdaten der Finanzabteilung benötigen.

Audit-Protokollierung

Das Protokoll sollte Ansichten, Bearbeitungen und Exporte abdecken — nicht nur Anmeldungen. Ohne dies hat „Wer hat letzten Monat auf die Datenbank-Zugangsdaten des Kunden zugegriffen" keine Antwort.

Das Aktivitätsprotokoll von Passwork zeichnet jede Aktion im System auf. Wenn sich die Berechtigungen eines Ordners ändern oder ein Masterpasswort zurückgesetzt wird, erscheint der Eintrag sofort — durchsuchbar nach Benutzer, Datum oder Aktionstyp.

MFA-Durchsetzung

NIST SP 800-63B empfiehlt Multi-Faktor-Authentifizierung für jedes Konto mit erhöhtem Zugriff. Erzwingen Sie sie für jede Rolle, die sensible Tresore sehen kann — nicht nur für das Admin-Konto.

Passwork unterstützt MFA auf Kontoebene und ermöglicht es Administratoren, sie organisationsweit zu verlangen, anstatt sie pro Benutzer optional zu belassen. Das schließt die Lücke, bei der der CEO Zwei-Faktor-Authentifizierung aktiviert, aber der Auftragnehmer mit Datenbankzugriff sich nie darum kümmert.

Automatisiertes Offboarding

Ein Klick sollte den Tresorzugriff eines ausscheidenden Mitarbeiters über jeden gemeinsamen Ordner hinweg deaktivieren, den er berührt hat — nicht fünfzehn separate Widerrufe.

In Passwork widerruft das Deaktivieren eines einzelnen Benutzerkontos sofort dessen Zugriff auf alle Tresore und Ordner, für die Berechtigungen bestanden — unabhängig davon, wie viele Teams oder Projekte das umfasste.

Das Sicherheits-Dashboard zeigt genau, worauf dieses Konto vor der Deaktivierung zugreifen konnte, sodass ein Administrator, der einen Offboarding-Fall überprüft, die Zugriffshistorie nicht aus dem Gedächtnis oder allein aus dem Audit-Protokoll rekonstruieren muss.

Browser-Erweiterung, Desktop- und Mobile-Apps

Autofill aus einem gemeinsamen Tresor schlägt das Kopieren eines Passworts aus einem Chat-Thread. Die Akzeptanz hängt davon ab.

Die Browser-Erweiterung von Passwork funktioniert mit Chrome, Firefox, Edge und Safari und füllt Zugangsdaten direkt aus gemeinsamen Tresoren aus, ohne die Seite zu verlassen. Mobile- und Desktop-Apps decken denselben Bereich für Mitarbeiter ab, die Tresorzugriff außerhalb eines Browsers benötigen — insbesondere Außendiensttechniker und Remote-Vertriebsmitarbeiter.

Das Sicherheits-Dashboard zeigt genau, worauf dieses Konto vor der Deaktivierung zugreifen konnte, sodass ein Administrator, der einen Offboarding-Fall überprüft, die Zugriffshistorie nicht aus dem Gedächtnis oder allein aus dem Audit-Protokoll rekonstruieren muss.

API-Zugriff

Anfangs optional. Wird relevant, sobald Teams beginnen, Geheimnisse in CI/CD-Pipelines zu ziehen, anstatt sie in .env-Dateien zu committen.

Die REST API von Passwork ermöglicht es DevOps-Teams, Geheimnisse zum Zeitpunkt des Deployments programmatisch abzurufen, Zugangsdaten nach einem Zeitplan zu rotieren und den Tresorzugriff in bestehende Automatisierung zu integrieren, anstatt Schlüssel manuell zwischen Systemen zu kopieren. Dies ist der Punkt, an dem ein Passwort-Manager aufhört, eine Browser-Bequemlichkeit zu sein, und beginnt, als Infrastruktur zu fungieren.

Raum zum Wachsen: SSO und LDAP

Nichts davon erfordert SSO oder LDAP am ersten Tag. Ein Fünf-Personen-Team kann vollständig mit lokalen Konten und manuellen Einladungen arbeiten. In dem Moment, in dem die Mitarbeiterzahl 20 bis 30 überschreitet, oder die Organisation bereits Active Directory für alles andere betreibt, wird die manuelle Benutzerverwaltung zu einem Teilzeitjob.

Die LDAP/AD-Integration synchronisiert Ihre bestehende Verzeichnisstruktur in das Gruppen- und Rollensystem von Passwork. Ein neuer Mitarbeiter, der der „Developer"-AD-Gruppe hinzugefügt wird, erbt automatisch den entsprechenden Tresorzugriff — ohne separaten Bereitstellungsschritt in Passwork selbst.

Der praktische Nutzen zeigt sich wieder beim Offboarding. Deaktivieren Sie einen Benutzer in Active Directory, und sein Passwork-Zugriff verschwindet im selben Synchronisierungszyklus.

Fazit

Zentralisierte Passwortverwaltung ist keine Enterprise-Funktion, die für kleine Teams herunterskaliert wurde. Es ist eine gezielte Kontrolle gegen den Angriffsvektor, der KMU am härtesten trifft: Zugangsdaten, die gültig blieben, nachdem sie hätten widerrufen werden sollen.

Beginnen Sie diese Woche mit einer Pilotabteilung. Importieren Sie deren Zugangsdaten in Passwork, richten Sie gruppenbasierten Zugriff ein und legen Sie einen Umstellungstermin fest, um die Tabelle endgültig außer Dienst zu stellen.

Wenn Ihr Team Zugangsdaten über Tabellen, Chat oder Browser-Speicherung teilt, bietet Passwork einen Self-Hosted-Tresor mit RBAC, Audit-Protokollierung und Offboarding mit einem Klick — ohne Enterprise-Preise. Richten Sie Passwork auf Ihrer Infrastruktur ein und hören Sie auf, sich zu fragen, wer noch das WLAN-Passwort von vor drei Einstellungen hat.

Häufig gestellte Fragen

Was ist Schatten-KI: Die versteckte Bedrohung, die Unternehmen 670.000 $ pro Sicherheitsverletzung kostet

Schatten-KI kostet Unternehmen 670.000 $ extra pro Sicherheitsverletzung — und das meiste davon lässt sich auf Zugangsdaten zurückführen, die in öffentliche LLMs eingefügt wurden. Erfahren Sie, wie Schatten-KI tatsächlich aussieht, warum sie schwerer zu stoppen ist als Schatten-IT und wie man sie steuert.

PassworkAlex Muntyan

SaaS-Zugangsdatenverwaltung: 5 Schritte zur Zentralisierung Ihres App-Stacks

SaaS-Zugangsdatenverwaltung verwandelt verstreute Passwörter und API-Schlüssel in ein Inventar, das Sie gezielt teilen und beim Ausscheiden widerrufen können. Hier ist das Fünf-Schritte-Framework: Inventur, Struktur, Migration, Zugriffskontrolle und Automatisierung.

PassworkPasswork Team

Passwork gewinnt Top Performer Sommer 2026 auf SourceForge

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

PassworkPasswork Team

La gestión centralizada de contraseñas para pymes es la práctica de almacenar, compartir y controlar todas las credenciales empresariales a través de una plataforma segura en lugar de hojas de cálculo, navegadores o mensajes de chat. Proporciona a las pequeñas y medianas empresas el mismo control de credenciales en el que confían las grandes corporaciones, sin el coste elevado ni el equipo de seguridad necesario para gestionarlo.

La mayoría de las pequeñas y medianas empresas ya «gestionan contraseñas». Alguien guarda las credenciales en un navegador. Otra persona utiliza una bóveda personal local gratuita como KeePass. Los inicios de sesión de administrador compartidos para Stripe, Google Workspace o el ERP están en un hilo de Slack del año pasado. Eso es almacenamiento de contraseñas. No es gestión centralizada de contraseñas.

En 2026, la gestión centralizada de contraseñas para pymes significa un sistema propiedad de la organización donde las credenciales del equipo residen en bóvedas compartidas, el acceso se otorga de forma intencional y los empleados que se marchan dejan de ver los inicios de sesión de la empresa sin necesidad de una búsqueda exhaustiva. La misma bóveda de credenciales puede contener contraseñas humanas y secretos de máquinas (claves API, tokens, cadenas de conexión de bases de datos) porque la infraestructura ya no separa «aplicaciones que las personas usan» de «aplicaciones que los pipelines invocan».

Qué significa realmente la gestión centralizada de contraseñas

La gestión centralizada de contraseñas significa que un sistema propiedad de la organización almacena y controla todas las credenciales empresariales compartidas, con roles definidos, niveles de permisos y un registro de quién accedió a qué. Es distinta de un gestor de contraseñas personal (por ejemplo, KeePass), que protege los inicios de sesión de una sola persona, y de la gestión de acceso privilegiado (PAM) empresarial, que añade grabación de sesiones y elevación justo a tiempo para el acceso a infraestructura.

Un gestor de contraseñas personal resuelve el problema de inicio de sesión de una persona. La gestión centralizada de contraseñas resuelve el problema de la organización: quién puede acceder a qué, cuándo y con la aprobación de quién. Esa distinción es el punto central.

En la práctica, la centralización se basa en cinco mecanismos:

1. Un sistema único de registro para las credenciales de la empresa, no cinco copias no oficiales dispersas entre herramientas.
2. Bóvedas y carpetas compartidas mapeadas a equipos o departamentos, para que el intercambio de credenciales siga el organigrama.
3. Niveles de acceso, desde solo lectura hasta administrador de bóveda, para que nadie necesite un único inicio de sesión maestro compartido para toda la oficina.
4. Un registro de actividad que responda quién vio, cambió o exportó una credencial determinada.
5. Capacidad de crecimiento. La plataforma debe soportar LDAP/AD o SSO cuando la empresa esté preparada, para que la gestión de identidades escale con el equipo en lugar de requerir una nueva herramienta más adelante.

Los gestores de contraseñas personales siguen siendo útiles para cuentas personales. Fallan cuando la credencial pertenece a la empresa: los propietarios de facturación cambian, los contratistas rotan y nadie puede demostrar quién todavía tiene la contraseña del correo raíz de AWS.

Por qué las pymes lo sienten más difícil en 2026

Cuatro presiones se acumulan a la vez, y ninguna existía en esta combinación hace cinco años. Una empresa de 40 personas ahora ejecuta docenas de herramientas SaaS sin un equipo de seguridad dedicado, divide su fuerza laboral entre redes domésticas y cafeterías, y cada vez más pega credenciales en herramientas de IA que nadie ha evaluado.

• Proliferación de SaaS sin un departamento de TI de veinte personas. Una pequeña empresa puede terminar ejecutando docenas de herramientas en la nube sin nadie dedicado a gestionar el acceso. Cada herramienta necesita un inicio de sesión de administrador, y la mayoría de los equipos resuelven esto de forma rápida: un buzón compartido y una contraseña escrita en algún lugar donde todos puedan encontrarla. Nadie es propietario de esa contraseña seis meses después, y nadie recuerda quién la ha visto.
• Trabajo híbrido y remoto. Enviar una contraseña por Slack o correo electrónico ya era arriesgado cuando todos trabajaban desde una sola oficina. Con personas iniciando sesión desde routers domésticos y portátiles personales, el autocompletado desde una bóveda compartida es la única opción que no implica escribir una contraseña en una ventana de chat.
• Riesgo en la baja de empleados. Cuando alguien se va, lo que residía en su bóveda personal, navegador o aplicación de notas se va con esa persona. Un gestor de contraseñas centralizado permite desactivar la cuenta, eliminarla de todos los grupos y rotar los inicios de sesión SaaS compartidos que existían solo en su portátil. Sin él, la revisión de acceso ocurre solo después de que algo sale mal.
• La IA en la sombra es la fuga más reciente. Los empleados ahora pegan claves API, cadenas de bases de datos y contraseñas en ChatGPT o Copilot mientras solucionan problemas, y ninguna de esas actividades toca una bóveda o un registro de auditoría. Según el informe Cost of a Data Breach 2026 de IBM, la IA en la sombra estuvo involucrada en el 43% de las brechas, frente al 20% del año anterior, y el 92% de las organizaciones afectadas por una brecha relacionada con IA carecían de controles básicos de acceso a IA.

¿En qué punto se encuentra realmente su empresa en la gestión de contraseñas?

La mayoría de las pymes se encuentran en una de cuatro etapas reconocibles, desde el caos improvisado hasta la gobernanza centralizada. Cada etapa conlleva un riesgo específico, y pasar a la siguiente lo cierra.

Etapa 1: Caos improvisado

Hojas de cálculo, notas adhesivas, mensajes directos de Slack con una contraseña pegada.

Etapa 2: Almacenamiento en el navegador

Chrome o Edge guardan las contraseñas.

Etapa 3: Gestor de contraseñas básico

Un equipo adoptó una herramienta, pero nadie la gobierna.

Etapa 4: Gobernanza centralizada

Una bóveda estructurada, RBAC, registro de auditoría y una política aplicada trabajan juntos. El riesgo se reduce drásticamente.

Según el Data Breach Investigations Report 2026 de Verizon, las credenciales robadas o reutilizadas aparecieron en el 39% de todas las brechas, generalmente combinadas con una vulnerabilidad explotada o un tercero comprometido en lugar de actuar solas. Estos atacantes no calibran sus métodos según el tamaño de la empresa. La encuesta State of SMB Cybersecurity Survey 2025 de CrowdStrike encontró que entre las pymes que experimentaron un incidente cibernético, el 29% de aquellas con menos de 25 empleados fueron afectadas por ransomware, la tasa más alta de cualquier grupo de tamaño de empresa, incluidas las pymes más grandes.

Los equipos más pequeños son los menos preparados para absorber ese golpe. Los equipos que se encuentran en las etapas 1 y 2 no tienen ningún mecanismo para detectar una credencial comprometida o revocarla rápidamente, porque nada está lo suficientemente centralizado como para verificar en primer lugar. Esa brecha es exactamente lo que cierra la etapa 4.

Por qué las pymes son el objetivo, no la excepción

Las pymes enfrentan los mismos patrones de brecha que las organizaciones de cualquier tamaño, y los atacantes rara vez las seleccionan según su industria o ingresos. Según el Data Breach Investigations Report 2026 de Verizon, la intrusión en sistemas sigue siendo el principal patrón de brecha en las organizaciones pequeñas, el mismo patrón que lidera en las grandes empresas también, y los actores externos con motivación financiera llevan a cabo la mayoría de estos ataques.

«Somos demasiado pequeños para importar» es una lectura incorrecta de la amenaza. Los propios investigadores de Verizon lo expresan claramente: los atacantes que golpean a las pymes están «lanzando redes amplias» esperando que suficientes víctimas paguen, no investigando primero el tamaño o sector de la empresa. Lo que decide quién sufre una brecha es más simple y mundano: si sus credenciales ya estaban comprometidas o si sus dispositivos perimetrales tenían un agujero sin parchear.

Los datos a nivel de acción respaldan esto. Entre las brechas de pymes que Verizon analizó, el ransomware apareció en el 83% de los incidentes, el uso de credenciales robadas en el 39% y las vulnerabilidades explotadas en el 30%. Las cifras de ransomware golpean más fuerte específicamente a las empresas más pequeñas: de los casos de ransomware donde Verizon pudo confirmar el tamaño de la organización, aproximadamente el 96% de las víctimas eran pymes.

Frente a números como estos, una plataforma de contraseñas con precio por usuario al mes no es un gasto que valga la pena debatir. Es un coste pequeño y predecible frente a una amenaza que no discrimina por tamaño de empresa.

Cerrar la brecha que dejan las credenciales robadas no requiere un gran presupuesto ni una implementación prolongada. Pruebe Passwork gratis y vea cómo una bóveda estructurada, control de acceso basado en roles y registro de auditoría funcionan en su propia infraestructura.

Qué buscar en una plataforma de gestión centralizada de contraseñas

Una plataforma de gestión centralizada de contraseñas para pymes necesita bóvedas compartidas con estructura de carpetas, RBAC granular, registro de auditoría completo, MFA obligatorio y un modelo de implementación que coincida con sus necesidades de cumplimiento, ya sea autoalojado o en la nube. La baja automatizada y el acceso API son importantes una vez que el equipo crece más allá de un puñado de personas.

Esto es lo que debe verificar antes de elegir una:

Estructura de la bóveda

Las carpetas o etiquetas organizadas por departamento mantienen las credenciales localizables sin que la barra de búsqueda haga todo el trabajo.

Passwork organiza las credenciales en bóvedas y carpetas anidadas que se mapean a departamentos y proyectos. Añadir un nuevo usuario no debería significar hacer clic en veinte contraseñas. Mapear grupos de directorio (LDAP/AD) más adelante es opcional — el hábito de grupos debería comenzar desde el primer día.

Granularidad del RBAC

Las buenas plataformas separan dos capas de permisos: roles del sistema (quién puede invitar usuarios, configurar SSO, leer registros) y niveles de acceso a recursos (quién puede ver o editar una bóveda o carpeta específica). La mayoría del personal solo necesita acceso de lectura o escritura a la bóveda de su propio equipo. Los roles de administrador deberían ser escasos.

Passwork viene con roles predefinidos y permite crear roles personalizados, como AD Administrator o DevOps, delimitados exactamente a los permisos que ese rol necesita. Esta separación importa en la práctica: un auditor que puede revisar el registro no debería automáticamente poder editar el contenido de la bóveda, y un administrador del sistema que gestiona la sincronización LDAP no debería necesitar acceso a las credenciales de Finanzas.

Registro de auditoría

El registro debe cubrir visualizaciones, ediciones y exportaciones, no solo inicios de sesión. Sin esto, «quién accedió a las credenciales de la base de datos del cliente el mes pasado» no tiene respuesta.

El registro de actividad de Passwork registra cada acción en el sistema. Cuando los permisos de una carpeta cambian o se restablece una contraseña maestra, la entrada aparece inmediatamente, buscable por usuario, fecha o tipo de acción.

Aplicación de MFA

NIST SP 800-63B recomienda la autenticación multifactor para cualquier cuenta con acceso elevado. Aplíquelo a cualquier rol que pueda ver bóvedas sensibles, no solo a la cuenta de administrador.

Passwork soporta MFA a nivel de cuenta y permite a los administradores requerirlo en toda la organización en lugar de dejarlo como opcional por usuario. Esto cierra la brecha donde el CEO habilita la autenticación de dos factores pero el contratista con acceso a la base de datos nunca se molesta.

Baja automatizada

Un solo clic debería desactivar el acceso a la bóveda de un empleado saliente en todas las carpetas compartidas que tocó, no quince revocaciones separadas.

En Passwork, desactivar la cuenta de un solo usuario revoca inmediatamente su acceso en todas las bóvedas y carpetas en las que tenía permisos, independientemente de cuántos equipos o proyectos abarcara.

El panel de Seguridad muestra exactamente a qué podía acceder esa cuenta antes de la desactivación, para que un administrador revisando un caso de baja no tenga que reconstruir el historial de acceso de memoria o solo del registro de auditoría.

Extensión de navegador, aplicaciones de escritorio y móvil

El autocompletado desde una bóveda compartida supera copiar una contraseña de un hilo de chat. La adopción depende de ello.

La extensión de navegador de Passwork funciona con Chrome, Firefox, Edge y Safari, autocompletando credenciales directamente desde bóvedas compartidas sin salir de la página. Las aplicaciones móviles y de escritorio cubren el mismo terreno para el personal que necesita acceso a la bóveda fuera de un navegador, técnicos de campo y representantes de ventas remotos en particular.

El panel de Seguridad muestra exactamente a qué podía acceder esa cuenta antes de la desactivación, para que un administrador revisando un caso de baja no tenga que reconstruir el historial de acceso de memoria o solo del registro de auditoría.

Acceso API

Opcional al principio. Se vuelve relevante una vez que los equipos comienzan a extraer secretos en pipelines CI/CD en lugar de confirmarlos en archivos .env.

La REST API de Passwork permite a los equipos de DevOps extraer secretos programáticamente en el momento del despliegue, rotar credenciales en un horario e integrar el acceso a la bóveda en la automatización existente en lugar de copiar manualmente claves entre sistemas. Este es el punto donde un gestor de contraseñas deja de ser una comodidad de navegación y comienza a funcionar como infraestructura.

Capacidad de crecimiento: SSO y LDAP

Nada de lo anterior requiere SSO o LDAP desde el primer día. Un equipo de cinco personas puede funcionar completamente con cuentas locales e invitaciones manuales. En el momento en que el personal supera los 20 a 30, o la organización ya ejecuta Active Directory para todo lo demás, la gestión manual de usuarios se convierte en un trabajo a tiempo parcial.

La integración LDAP/AD sincroniza su estructura de directorio existente en el sistema de grupos y roles de Passwork, de modo que un nuevo empleado añadido al grupo AD «Developer» hereda automáticamente el acceso correspondiente a la bóveda, sin un paso de aprovisionamiento separado en Passwork mismo.

El beneficio práctico aparece en la baja, nuevamente. Desactive un usuario en Active Directory, y su acceso a Passwork desaparece en el mismo ciclo de sincronización.

Conclusión

La gestión centralizada de contraseñas no es una función empresarial reducida para equipos pequeños. Es un control específico contra el vector de brecha que golpea más fuerte a las pymes: credenciales que permanecieron válidas después de que deberían haber sido revocadas.

Comience con un departamento piloto esta semana. Importe sus credenciales en Passwork, configure el acceso basado en grupos y elija una fecha de transición para retirar la hoja de cálculo definitivamente.

Si su equipo comparte credenciales a través de hojas de cálculo, chat o almacenamiento del navegador, Passwork le ofrece una bóveda autoalojada con RBAC, registro de auditoría y baja con un solo clic, sin precios empresariales. Configure Passwork en su infraestructura y deje de preguntarse quién todavía tiene la contraseña del Wi-Fi de hace tres contrataciones.

Preguntas frecuentes

Qué es la IA en la sombra: La amenaza oculta que cuesta a las empresas $670K por brecha

La IA en la sombra cuesta a las empresas $670K adicionales por brecha — y la mayoría se remonta a credenciales pegadas en LLMs públicos. Aprenda cómo es realmente la IA en la sombra, por qué es más difícil de detener que la TI en la sombra, y cómo gobernarla.

PassworkAlex Muntyan

Gestión de credenciales SaaS: 5 pasos para centralizar su stack de aplicaciones

La gestión de credenciales SaaS convierte contraseñas dispersas y claves API en un inventario que puede compartir de forma intencional y revocar a la salida. Aquí está el marco de cinco pasos: inventario, estructura, migración, control de acceso y automatización.

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

Centralized password management for SMBs is the practice of storing, sharing, and controlling every business credential through one secured platform instead of spreadsheets, browsers, or chat messages. It gives small and mid-sized businesses the same credential control enterprises rely on, minus the price tag and the security team required to run it.

Most small and mid-sized businesses already "manage passwords." Someone keeps credentials in a browser. Someone else uses a free local personal vault like KeePass. Shared admin logins for Stripe, Google Workspace, or the ERP sit in a Slack thread from last year. That is password storage. It is not centralized password management.

In 2026, centralized password management for SMBs means one organization-owned system where team credentials live in shared vaults, access is granted on purpose, and leaving employees stop seeing company logins without a scavenger hunt. The same credential vault can hold human passwords and machine secrets (API keys, tokens, database strings) because the stack no longer separates "apps people click" from "apps pipelines call."

What centralized password management actually means

Centralized password management means one organization-owned system stores and controls every shared business credential, with defined roles, permission levels, and a record of who accessed what. It is distinct from a personal password manager (e.g., KeePass), which protects one person's logins, and from enterprise privileged access management (PAM), which adds session recording and just-in-time elevation for infrastructure access.

A personal password manager solves one person's login problem. Centralized password management solves the organization's problem: who can access what, when, and with whose approval. That distinction is the whole point.

In practice, centralization rests on five mechanics:

1. One system of record for company credentials, not five unofficial copies scattered across tools.
2. Shared vaults and folders mapped to teams or departments, so credential sharing follows the org chart.
3. Access levels, from read-only to vault admin, so nobody needs a single shared master login for the whole office.
4. An activity log that answers who viewed, changed, or exported a given credential.
5. Room to grow. The platform should support LDAP/AD or SSO once the company is ready for them, so identity management scales with the team instead of requiring a new tool later.

Personal password managers remain useful for personal accounts. They break down when the credential belongs to the company: billing owners change, contractors rotate, and nobody can prove who still has the AWS root email password.

Why SMBs feel this harder in 2026

Four pressures stack at once, and none of them existed in this combination five years ago. A 40-person company now runs dozens of SaaS tools without a dedicated security team, splits its workforce across home networks and coffee shops, and increasingly pastes credentials into AI tools nobody vetted.

• SaaS sprawl without an IT department of twenty. A small company can end up running dozens of cloud tools without anyone dedicated to managing access. Each tool needs an admin login, and most teams solve this the fast way: a shared inbox and a password written down somewhere everyone can find it. Nobody owns that password six months later, and nobody remembers who has seen it.
• Hybrid and remote work. Sending a password over Slack or email was already risky when everyone worked from one office. With people logging in from home routers and personal laptops, autofill from a shared vault is the only option that doesn't involve typing a password into a chat window.
• Offboarding risk. When someone leaves, whatever lived in their personal vault, browser, or notes app leaves with them. A centralized password manager lets you disable the account, pull them from every group, and rotate the shared SaaS logins that existed only in their laptop. Without it, access review happens only after something goes wrong.
• Shadow AI is the newest leak. Employees now paste API keys, database strings, and passwords into ChatGPT or Copilot while troubleshooting, and none of that activity touches a vault or an audit log. According to IBM's Cost of a Data Breach Report 2026, shadow AI was involved in 43% of breaches, up from 20% the year before, and 92% of organizations hit by an AI-related breach lacked basic AI access controls.

Where does your business actually stand on password management

Most SMBs fall into one of four recognizable stages, from ad-hoc chaos to centralized governance. Each stage carries a specific risk, and moving to the next closes it.

Stage 1: Ad-hoc chaos

Spreadsheets, sticky notes, Slack DMs with a password pasted in.

Stage 2: Browser-based storage

Chrome or Edge saves the passwords.

Stage 3: Basic password manager

A team adopted a tool, but nobody governs it.

Stage 4: Centralized governance

A structured vault, RBAC, audit logging, and an enforced policy work together. Risk drops sharply.

According to Verizon's 2026 Data Breach Investigations Report, stolen or reused credentials showed up in 39% of all breaches, usually paired with an exploited vulnerability or a compromised third party rather than acting alone. These attackers don't calibrate their methods to company size. CrowdStrike's 2025 State of SMB Cybersecurity Survey found that among SMBs that experienced a cyber incident, 29% of those with fewer than 25 employees were hit by ransomware, the highest rate of any company size group, larger SMBs included.

The smallest teams are the least equipped to absorb that hit. Teams sitting at stages 1 and 2 have no mechanism to detect a compromised credential or revoke it quickly, because nothing is centralized enough to check in the first place. That gap is exactly what stage 4 closes.

Why SMBs are the target, not the exception

SMBs face the same breach patterns as organizations of any size, and attackers rarely single them out based on industry or revenue. According to Verizon's 2026 Data Breach Investigations Report, System Intrusion remains the top breach pattern in small organization breaches, the same pattern that leads across large enterprises too, and financially motivated external actors carry out most of these attacks.

"We're too small to matter" is the wrong read on the threat. Verizon's own researchers put it plainly: attackers hitting SMBs are "casting out wide nets" hoping enough victims pay, not researching company size or sector first. What decides who gets breached is simpler and more mundane: whether their credentials were already compromised or their edge devices had an unpatched hole.

The action-level data backs this up. Among the SMB breaches Verizon analyzed, ransomware appeared in 83% of incidents, the use of stolen credentials in 39%, and exploited vulnerabilities in 30%. The ransomware numbers land hardest on the smallest companies specifically: of the ransomware cases where Verizon could confirm organization size, about 96% of the victims were SMBs.

Set against numbers like these, a password platform priced per user per month is not an expense worth debating. It is a small, predictable cost against a threat that does not discriminate by company size.

Closing the gap that stolen credentials leave open doesn't require a big budget or a long rollout. Try Passwork free and see how a structured vault, role-based access control, and audit logging look in your own infrastructure.

What to look for in a centralized password management platform

A centralized password management platform for SMBs needs shared vaults with folder structure, granular RBAC, complete audit logging, enforced MFA, and a deployment model that matches your compliance needs, whether that's self-hosted or cloud-hosted. Automated offboarding and API access matter once the team scales past a handful of people.

Here is what to check before choosing one:

Vault structure

Folders or tags organized by department keep credentials findable without a search bar doing all the work.

Passwork organizes credentials into vaults and nested folders that map to departments and projects. Adding a new user should not mean clicking through twenty passwords. Mapping directory groups (LDAP/AD) later is optional — the group habit should start on day one.

RBAC granularity

Good platforms separate two layers of permission: system roles (who can invite users, configure SSO, read logs) and resource access levels (who can see or edit a specific vault or folder). Most staff only need read or write access to their own team's vault. Admin roles should stay rare.

Passwork ships with predefined roles and lets you build custom ones, such as AD Administrator or DevOps, scoped to exactly the permissions that role needs. This separation matters in practice: an auditor who can review the log shouldn't automatically be able to edit vault contents, and a system administrator managing LDAP sync shouldn't need access to Finance's credentials.

Audit logging

The log should cover views, edits, and exports, not just logins. Without this, "who accessed the client's database credentials last month" has no answer.

Passwork's activity log records every action in the system. When a folder's permissions change or a master password gets reset, the entry shows up immediately, searchable by user, date, or action type.

MFA enforcement

NIST SP 800-63B recommends multi-factor authentication for any account with elevated access. Enforce it on any role that can see sensitive vaults, not just the admin account.

Passwork supports MFA at the account level and lets administrators require it organization-wide rather than leaving it opt-in per user. That closes the gap where the CEO enables two-factor authentication but the contractor with database access never bothers.

Automated offboarding

One click should disable a departing employee's vault access across every shared folder they touched, not fifteen separate revocations.

In Passwork, disabling a single user's account immediately revokes their access across every vault and folder they had permissions to, regardless of how many teams or projects that spanned.

The Security dashboard shows exactly what that account could reach before deactivation, so an admin reviewing an offboarding case doesn't have to reconstruct access history from memory or the audit log alone.

Browser extension, desktop and mobile apps

Autofill from a shared vault beats copying a password out of a chat thread. Adoption depends on it.

Passwork's browser extension works with Chrome, Firefox, Edge, and Safari, autofilling credentials directly from shared vaults without leaving the page. Mobile and desktop apps cover the same ground for staff who need vault access outside a browser, field technicians and remote sales reps in particular.

The Security dashboard shows exactly what that account could reach before deactivation, so an admin reviewing an offboarding case doesn't have to reconstruct access history from memory or the audit log alone.

API access

Optional at first. Becomes relevant once teams start pulling secrets into CI/CD pipelines instead of committing them to .env files.

Passwork's REST API lets DevOps teams pull secrets programmatically at deploy time, rotate credentials on a schedule, and integrate vault access into existing automation instead of manually copying keys between systems. This is the point where a password manager stops being a browsing convenience and starts functioning as infrastructure.

Room to grow: SSO and LDAP

None of the above requires SSO or LDAP on day one. A five-person team can run entirely on local accounts and manual invites. The moment headcount crosses 20 to 30, or the org already runs Active Directory for everything else, manual user management turns into a part-time job.

LDAP/AD integration syncs your existing directory structure into Passwork's group and role system, so a new hire added to the "Developer" AD group automatically inherits the matching vault access, no separate provisioning step in Passwork itself.

The practical benefit shows up at offboarding, again. Disable a user in Active Directory, and their Passwork access disappears in the same sync cycle.

Bottom line

Centralized password management isn't an enterprise feature scaled down for small teams. It's a targeted control against the breach vector that hits SMBs hardest: credentials that stayed valid after they should have been revoked.

Start with one pilot department this week. Import its credentials into Passwork, set up group-based access, and pick a cutover date to retire the spreadsheet for good.

If your team shares credentials through spreadsheets, chat, or browser storage, Passwork gives you a self-hosted vault with RBAC, audit logging, and one-click offboarding, without enterprise pricing. Set up Passwork on your infrastructure and stop wondering who still has the Wi-Fi password from three hires ago.

Frequently asked questions

What is 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.

PassworkAlex Muntyan

SaaS credential management: 5 steps to centralize your app stack

SaaS credential management turns scattered passwords and API keys into one inventory you can share on purpose and revoke on exit. Here’s the five-step framework: inventory, structure, migration, access control, and automation.

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

Datensouveränität ist die Fähigkeit, physisch, rechtlich und kryptografisch zu bestimmen, wer auf bestimmte Daten zugreifen kann und unter welcher Gerichtsbarkeit. Ein Unternehmen kann auf dem Papier vollständig DSGVO-konform sein und dennoch keine echte Kontrolle darüber haben, wo seine Passwörter gespeichert sind. Bei Unternehmens-Zugangsdaten ist diese Lücke zwischen „konform" und „unter Kontrolle" der Punkt, an dem Sicherheitsverletzungen, behördliche Anfragen und fehlgeschlagene Audits ihren Ursprung haben.

Die Datenschutz-Grundverordnung (DSGVO) setzt die Grundlage, die die meisten Organisationen zur Beurteilung ihrer Datenpraktiken heranziehen: Sie regelt, wie personenbezogene Daten erhoben, gespeichert und übertragen werden. Gemäß Artikel 3 erstreckt sich ihr räumlicher Anwendungsbereich auf jedes Unternehmen, das Daten von EU-Bürgern verarbeitet — unabhängig davon, wo dieses Unternehmen seinen Hauptsitz hat. 

Passwörter und Geheimnisse sind keine gewöhnlichen Daten, weshalb die Passwortverwaltung ein eigenes Souveränitätsmodell benötigt, das von der allgemeinen Dateispeicherung getrennt ist. Sie öffnen den Zugang zu allem anderen, werden ständig zwischen Mitarbeitern weitergegeben und durchlaufen selten die Data Loss Prevention (DLP)- oder Klassifizierungstools, die Verträge und Kundendaten überwachen. Zugangsdaten, die auf dem falschen Server, im falschen Land und unter fremden Verschlüsselungsschlüsseln gespeichert sind, stellen eine Haftung dar, die die meisten Compliance-Checklisten nicht erfassen.

Dieser Artikel erläutert, was Souveränität auf drei Ebenen bedeutet: physischer Standort, Verschlüsselung und Zugriffsgovernance. Er vergleicht On-Premise-, Air-Gapped- und EU-Cloud-Modelle und zeigt, wo ein selbstgehosteter Zero-Knowledge-Passwortmanager wie Passwork in diese Entscheidung passt.

Was Datensouveränität für Zugangsdaten wirklich bedeutet

Datensouveränität ist die Kombination aus drei separaten Kontrollen: wo sich Daten physisch befinden, wer die Verschlüsselungsschlüssel hält und wer den Zugriff darauf regelt. Der Verlust einer dieser drei Komponenten bricht die Souveränität, selbst wenn die anderen beiden solide sind. Die meisten Anbieter bewerben nur die erste.

• Physischer Standort beantwortet, wo sich die Server befinden. Ein in Frankfurt gehosteter Passwortmanager unterliegt weiterhin dem räumlichen Anwendungsbereich der DSGVO — aber das gilt auch für einen in Virginia gehosteten, wenn er Daten von EU-Bürgern verarbeitet. Der Standort ist relevant für die Gerichtsbarkeit, nicht automatisch für die rechtliche Gefährdung.
• Verschlüsselungskontrolle beantwortet, wer die Daten entschlüsseln kann. Wenn der Anbieter die Schlüssel hält, können behördliche Anfragen, Insider oder ein Sicherheitsvorfall in der Infrastruktur des Anbieters Ihre Zugangsdaten offenlegen — unabhängig vom Serverstandort.
• Zugriffsgovernance beantwortet, wer innerhalb Ihrer Organisation was sehen kann. Rollenbasierte Zugriffskontrolle (RBAC) und Audit-Logs bestimmen, ob der Zugriff eines ausscheidenden Mitarbeiters innerhalb von Minuten widerrufen oder erst sechs Monate später entdeckt wird.

Echte Datensouveränität erfordert alle drei Elemente. Das Weglassen einer Komponente reduziert die Architektur auf eine formale Compliance-Checkliste.

Warum Zugangsdaten eine eigene Datenklasse sind

Zugangsdaten verdienen eine separate Behandlung, weil sie hochwertig, weit verbreitet und für Standard-Data-Governance-Tools weitgehend unsichtbar sind. Ein geleakter Kundendatensatz legt einen Datensatz offen. Ein geleaktes Admin-Passwort legt jedes System offen, auf das dieser Admin zugreifen kann — und es funktioniert weiter, bis jemand es rotiert.

Der Data Breach Investigations Report 2026 von Verizon ergab, dass gestohlene Zugangsdaten 13 % der initialen Zugriffsvektoren ausmachten. Diese Zahl verdreifachte sich jedoch (39 %) über den gesamten Verlauf der Sicherheitsverletzung. Passwörter bewegen sich auch ständig: Sie werden beim Onboarding geteilt, in Tickets kopiert, in Chat-Threads eingefügt und weitergeleitet, wenn ein Projekt den Besitzer wechselt. DLP-Tools, die für das Erkennen von Dokumenten-Exfiltration entwickelt wurden, erfassen selten ein Passwort, das in einer Slack-Nachricht gepostet wird.

Diese Kombination aus hoher Auswirkung und geringer Sichtbarkeit ist der Grund, warum die Speicherung von Zugangsdaten ein eigenes Souveränitätsmodell benötigt, anstatt die Richtlinien für allgemeine Dateispeicherung zu übernehmen.

Wo Standard-Cloud-Speicherung rechtliche Reibungspunkte verursacht

Standard-Cloud-Passwortmanager verursachen rechtliche Gefährdung durch Unterauftragsverarbeiter-Ketten, grenzüberschreitende Datenübertragungen und Zugriff durch Anbieter-Mitarbeiter — selbst wenn der Anbieter vollständig DSGVO-konform ist. Verschlüsselung im Ruhezustand beseitigt diese Risiken nicht, wenn der Anbieter und nicht der Kunde die Entschlüsselungsschlüssel hält.

Drei spezifische Reibungspunkte treten bei Beschaffungsprüfungen wiederholt auf:

• Unterauftragsverarbeiter. Die meisten Cloud-Anbieter nutzen unterbeauftragte Infrastruktur-, Monitoring- oder Support-Anbieter. Jeder Unterauftragsverarbeiter ist eine separate Einheit mit eigener Zugriffsoberfläche. Artikel 28(2) der DSGVO verlangt, dass der Auftragsverarbeiter ohne vorherige gesonderte oder allgemeine schriftliche Genehmigung des Verantwortlichen keinen weiteren Auftragsverarbeiter (Unterauftragsverarbeiter) hinzuziehen darf.
• Drittstaaten-Übermittlungen. Kapitel V der DSGVO regelt die Übermittlung personenbezogener Daten außerhalb der EU/des EWR. Artikel 44 legt den Grundsatz fest, dass jede Übermittlung das durch die Verordnung garantierte Schutzniveau nicht untergraben darf. Artikel 46 verlangt geeignete Garantien, wie Standardvertragsklauseln, wenn kein Angemessenheitsbeschluss vorliegt. Zugangsdaten-Tresore, die in einem Drittland gehostet oder zu Backup-Zwecken dorthin repliziert werden, fallen direkt unter dieses Kapitel.
• Anbieter-Mitarbeiterzugriff und rechtliche Anfragen. Wenn der Anbieter technisch in der Lage ist, Kundendaten zu entschlüsseln, unterliegen diese Daten rechtlichen Verfahren in der Gerichtsbarkeit des Anbieters. Eine Vorladung, ein Durchsuchungsbeschluss oder eine ausländische Offenlegungsanordnung kann den Zugriff erzwingen — unabhängig davon, wo Ihr Unternehmen registriert ist.

NIS2 fügt einen vierten Aspekt hinzu: Artikel 21(2)(d) verlangt von wesentlichen und wichtigen Einrichtungen, die Sicherheit der Lieferkette zu bewerten — einschließlich der Anbieter und Tools, die sie zur Verwaltung von Zugangsdaten verwenden. Ein Passwort-Tresor, der bei einem nicht geprüften Drittanbieter-Unterauftragsverarbeiter liegt, fällt genau unter diese Anforderung.

Nichts davon macht Cloud-Speicherung per se nicht-konform. Es bedeutet, dass „DSGVO-konform" eine notwendige, aber keine hinreichende Bedingung für die Souveränität über Zugangsdaten ist.

Die drei Ebenen auf Bereitstellungsmodelle abbilden

Eine Lücke in einer einzelnen Ebene öffnet erneut die Gefährdung, die die anderen beiden schließen sollten. Die folgende Tabelle wendet die drei Kontrollen aus dem ersten Abschnitt — Standort, Entschlüsselung und Zugriff — auf die Modelle an, zwischen denen Organisationen tatsächlich wählen.

• Air-Gapped beschreibt Infrastruktur ohne jeglichen Netzwerkpfad zum Internet — die strengste Form der physischen Isolation.
• Zero-Knowledge bedeutet, dass der Anbieter Ihre Daten unter keinen Umständen lesen kann. 
• Clientseitige Verschlüsselung ist der Mechanismus, der diese Garantie erzeugt: Verschlüsselung und Entschlüsselung erfolgen auf dem Gerät des Benutzers unter Verwendung eines Masterpassworts, das der Anbieter niemals erhält oder speichert. Der Server hält und überträgt somit nur Chiffretext. 

Ein schlecht implementiertes clientseitiges Verschlüsselungsschema — eines mit einem wiederherstellbaren Masterpasswort oder einer schwachen Schlüsselableitungsfunktion — liefert nicht automatisch eine echte Zero-Knowledge-Garantie. Diese Unterscheidung bestimmt, ob „in der Cloud verschlüsselt" tatsächlich etwas für die Souveränität bedeutet.

On-Premise und Air-Gapped: Vollständige Isolation auf Kosten des Betriebsaufwands

On-Premise-Bereitstellung gibt einer Organisation die vollständige physische und kryptografische Kontrolle über ihren Zugangsdaten-Tresor, da die Daten niemals die Infrastruktur verlassen, die die Organisation besitzt und verwaltet. Air-Gapping geht einen Schritt weiter: Die Infrastruktur hat überhaupt keinen Netzwerkpfad zum Internet — das einzige Setup, das externe Netzwerkabhängigkeit vollständig beseitigt.

Isolation vom Anbieter: Zero-Knowledge-Verschlüsselung

Passwork läuft vollständig innerhalb des Unternehmensperimeters, auf Infrastruktur, die die Organisation von Anfang bis Ende kontrolliert. Der Passwort- und Geheimnismanager verschlüsselt und entschlüsselt Daten vollständig auf der Clientseite unter Verwendung eines Schlüssels, der vom Masterpasswort des Benutzers abgeleitet wird. Der Server erhält oder speichert zu keinem Zeitpunkt Klartext — er hält nur verschlüsselte Blobs und verfügt über keinen Schlüssel, der sie entschlüsseln könnte. Für Organisationen mit Air-Gap-Anforderungen und strengen Segmentierungsrichtlinien ist dies oft die einzige Architektur, die interne Sicherheitsrichtlinien erfüllt. 

Eine solche Behauptung sollte nicht auf Vertrauen basieren. Der Quellcode von Passwork ist für das eigene Sicherheitsteam der Organisation zur direkten Prüfung verfügbar — Zeile für Zeile — anstatt sich auf die Beschreibung des Anbieters zu verlassen, wie die Verschlüsselung implementiert ist.

Der operative Kompromiss

Dieses Maß an Isolation hat seinen Preis — bezahlt in operativem Aufwand. On-Premise verlagert Serverwartung, Patching, Backup-Management und Verfügbarkeitsverantwortung vom Anbieter auf Ihr eigenes IT-Team. Jemand muss Updates einspielen, Speicherplatz überwachen, TLS-Zertifikate verwalten und Disaster Recovery handhaben. Für ein kleines IT-Team, das bereits mit anderen Prioritäten ausgelastet ist, sind das echte Kosten. Organisationen, die Self-Hosting wählen, benötigen entweder eine dedizierte Systemadministrator-Ressource oder einen verwalteten internen Prozess, um die Bereitstellung aktuell zu halten.

Die Zero-Knowledge-Verschlüsselung von Passwork hält Ihre Daten für alle außer Ihren eigenen Benutzern unlesbar. Prüfen Sie die Architektur in den Benutzerhandbüchern, bevor Sie Infrastruktur bereitstellen, oder testen Sie die vollständige Bereitstellung kostenlos, um sie auf Ihren eigenen Servern laufen zu sehen.

EU-Cloud-Hosting: Tragfähig, aber nur mit clientseitiger Verschlüsselung

EU-Cloud-Hosting kann jurisdiktionelle Anforderungen für kleinere Teams ohne dediziertes Infrastrukturpersonal erfüllen — aber nur, wenn der Anbieter obligatorische clientseitige Verschlüsselung (CSE) implementiert. Ohne CSE lässt ein EU-gehosteter Tresor den Anbieter weiterhin in der Lage, Kundendaten zu entschlüsseln, was dieselbe Gefährdung wieder öffnet, die das Hosting in der EU schließen sollte.

Bei einem ordnungsgemäßen CSE-Modell verlässt das Masterpasswort niemals das Gerät des Benutzers, und die Server des Anbieters verarbeiten und speichern nur Chiffretext. Selbst mit vollem physischen Zugriff auf den Server kann der Anbieter den Inhalt des Tresors nicht lesen. Dies ist eine wesentlich andere Garantie als „unsere Rechenzentren befinden sich in der EU", was die Gerichtsbarkeit adressiert, aber nichts darüber aussagt, wer die Schlüssel hält.

EU-Cloud-Hosting mit CSE verringert die rechtliche Gefährdung und erfüllt Datenresidenz-Anforderungen für viele Compliance-Frameworks, aber es ist nicht dieselbe Garantie wie vollständige On-Premise-Souveränität. Die Infrastruktur, Netzwerkschicht und physische Hardware bleiben außerhalb der direkten Kontrolle des Kunden. Für Organisationen mit Air-Gap-Vorgaben oder strengen Self-Hosting-Richtlinien ist EU-Cloud kein Ersatz — unabhängig von der Verschlüsselungsstärke.

On-Premise ohne Zero-Knowledge vertraut lokalen Administratoren dennoch Klartextzugriff an. EU-Cloud ohne Zero-Knowledge vertraut dem Infrastrukturpersonal des Anbieters. In beiden Fällen gilt die Garantie nur, wenn das Masterpasswort niemals das Gerät des Benutzers verlässt.

Anbieteraussagen überprüfen: Was der Einkauf prüfen sollte

Souveränitätsaussagen sind nur so glaubwürdig wie die Nachweise Dritter dahinter. Diese Prüfung gilt unabhängig davon, welches Bereitstellungsmodell Sie wählen: Ein Zertifikat sagt Ihnen nicht, wo sich Daten befinden, aber es sagt Ihnen, ob die anderen Aussagen eines Anbieters standhalten. Einkaufsteams sollten eine Self-Hosting-Entscheidung auf interne Admin-Kapazitäten und Richtlinienanforderungen stützen und dann den in die engere Wahl gezogenen Anbieter durch unabhängige Zertifizierung, eigene Prüfung und öffentliche Sicherheitstests validieren.

Vier Prüfungen sind in der Praxis relevant:

• ISO/IEC 27001-Zertifizierung bestätigt, dass ein Informationssicherheits-Managementsystem unabhängig nach dem internationalen Standard geprüft wurde. Passwork besitzt die ISO/IEC 27001:2022-Zertifizierung, ausgestellt von MSECB und überprüfbar über die IAF CertSearch-Datenbank.
• NIS2- und DSGVO-Bereitschaft ist relevant für jede Organisation, die unter den Geltungsbereich einer der beiden Verordnungen fällt. Die Lieferketten-Anforderungen in Artikel 21 von NIS2 erstrecken sich auf die Tools, die wesentliche und wichtige Einrichtungen zur Verwaltung von Zugangsdaten verwenden, während Artikel 32 der DSGVO „geeignete technische und organisatorische Maßnahmen", einschließlich Verschlüsselung, für jedes System verlangt, das personenbezogene Daten verarbeitet. Organisationen, die Anbieter gegen diese Anforderungen bewerten, können den Ansatz von Passwork zur NIS2-Compliance als einen Referenzpunkt heranziehen.
• Quellcode-Prüfrechte bestätigen, dass eine Zero-Knowledge-Behauptung tatsächlich wahr ist und keine Marketing-Sprache. Bei einem echten Zero-Knowledge-Design kann der Anbieter unter keinen Umständen das Masterpasswort eines einzelnen Benutzers wiederherstellen — nicht durch einen Backend-Reset, nicht durch ein Support-Ticket, nicht unter rechtlichem Druck. Wenn ein Benutzer es vergisst, sind die dahinter liegenden Daten absichtlich verloren, weil der Anbieter den Schlüssel nie besessen hat. Passwork öffnet seinen Quellcode für die eigenen Sicherheitsteams der Kunden genau aus diesem Grund: Es ist der Weg zu bestätigen, dass die Verschlüsselungsimplementierung der vom Anbieter beschriebenen Architektur entspricht.
• Öffentliche Penetrationstests liefern Nachweise über die selbst gemeldete Sicherheitslage hinaus. Passwork hat einen unabhängigen Penetrationstest über HackerOne abgeschlossen, der sichere Datenverarbeitung, die OWASP Top 10 und SANS Top 25, Authentifizierung und API-Zugriffskontrolle abdeckt.

Ein Bereitstellungsmodell wählen: Ein Entscheidungsrahmen

Das richtige Bereitstellungsmodell hängt von fünf praktischen Faktoren ab: 

• Air-Gap-Anforderungen 
• Obligatorisches EU-Hosting 
• Größe des Admin-Teams
• Interne Self-Hosting-Richtlinie
• Anforderungen an die Infrastrukturkontrolle

Das Abgleichen dieser Faktoren mit den Bereitstellungsoptionen vermeidet den häufigen Fehler, allein auf Basis von Preis oder Markenbekanntheit zu wählen. Verwenden Sie diese Entscheidungsmatrix für die Datenresidenz von Zugangsdaten, um organisatorische Einschränkungen einem Bereitstellungsmodell zuzuordnen:

Keine dieser Zeilen schließt sich in der Praxis gegenseitig aus. Ein Finanzinstitut könnte On-Premise für seinen Kern-Tresor betreiben und gleichzeitig Cloud-basierte Tools für Workflows mit geringerer Sensibilität akzeptieren. Die Matrix ist ein Ausgangspunkt für das Gespräch mit Sicherheits- und Compliance-Stakeholdern.

Wie die Architektur von Passwork auf diese Ebenen abgebildet wird

Die selbstgehostete Bereitstellung von Passwork adressiert die in diesem Artikel beschriebene Souveränitätslücke, indem sie physische Isolation, Zero-Knowledge-Verschlüsselung und vom Kunden kontrollierte Zugriffsgovernance in einer Architektur vereint. Der Tresor wird auf Infrastruktur bereitgestellt, die der Kunde besitzt — ob auf einem einzelnen Linux-Server, einer Windows Server-Umgebung oder einem Docker-Container in einem Air-Gapped-Netzwerk.

Die Verschlüsselung verwendet AES-256 mit einem Zero-Knowledge-Design, was bedeutet, dass die Infrastruktur — selbst wenn sie kompromittiert würde — nur Chiffretext enthält. Der Zugriff wird durch rollenbasierte Berechtigungen und ein vollständiges Audit-Log geregelt, sodass Administratoren sehen können, wer wann auf welche Zugangsdaten zugegriffen hat, und den Zugriff sofort widerrufen können, wenn jemand die Rolle wechselt oder das Unternehmen verlässt. Die Integration mit AD/LDAP und SAML SSO ermöglicht es, die Zugriffsgovernance an die bestehende Identitätsinfrastruktur anzubinden, anstatt als separates Silo zu laufen.

Dies ist bewusst keine Behauptung, dass Self-Hosting für jeden geeignet ist. Organisationen ohne Air-Gap-Anforderungen oder strenge Self-Hosting-Vorgaben können eine Cloud-Option mit ordnungsgemäßer clientseitiger Verschlüsselung als ausreichend erachten. Der Punkt ist, dass die Architektur strukturell dafür ausgelegt sein muss, wenn vollständige Souveränität die Anforderung ist.

Datensouveränität in der Passwortverwaltung: Wie Sie sie in Ihre Bewertung einbeziehen

Souveränität ist eine fortlaufende Abstimmung zwischen dem Ort, an dem sich Daten befinden, demjenigen, der die Schlüssel hält, und demjenigen, der den Zugriff regelt — und diese Abstimmung muss überprüft werden, wann immer sich Ihre Infrastruktur, Anbieterverträge oder der regulatorische Geltungsbereich ändern.

Beginnen Sie damit, Ihre eigene Organisation anhand der vier Faktoren in der Entscheidungsmatrix zu bewerten: Air-Gap-Anforderung, obligatorisches EU-Hosting, Größe des Admin-Teams und interne Self-Hosting-Richtlinie. Diese Zuordnung wird Ihnen mehr über das richtige Bereitstellungsmodell sagen als jede Marketingseite eines Anbieters.

Der einzige Weg zu bestätigen, dass eine selbstgehostete Architektur zu Ihrer Infrastruktur passt, ist sie dort auszuführen. Passwork bietet eine kostenlose Testversion, die Sie auf Ihren eigenen Servern bereitstellen können — mit vollem Funktionsumfang und ohne dass Daten jemals Ihre Umgebung verlassen.

Häufig gestellte Fragen

SaaS-Zugangsdatenverwaltung: 5 Schritte zur Zentralisierung Ihres App-Stacks

SaaS-Zugangsdatenverwaltung verwandelt verstreute Passwörter und API-Schlüssel in ein Inventar, das Sie gezielt teilen und bei Austritt widerrufen können. Hier ist das Fünf-Schritte-Framework: Inventarisierung, Strukturierung, Migration, Zugriffskontrolle und Automatisierung.

PassworkPasswork Team

Verizon DBIR 2026: 10 Statistiken, die Ihre Sicherheitsstrategie ändern sollten

Der DBIR 2026 von Verizon analysierte über 22.000 Sicherheitsverletzungen in 145 Ländern. Die Ausnutzung von Schwachstellen überholte den Missbrauch von Zugangsdaten als wichtigsten Angriffsvektor, während Ransomware, Drittanbieter-Risiken und KI-gestützte Angriffe stark zunahmen. Hier sind die 10 Zahlen, die zählen.

Passwork BlogAlex Muntyan

Was ist Zero-Knowledge-Verschlüsselung? Wie sie in 5 Minuten funktioniert

Zero-Knowledge-Verschlüsselung bedeutet, dass der Server niemals Ihre Entschlüsselungsschlüssel hält — nur Chiffretext. Erfahren Sie, wie die Schlüsselkette funktioniert, wovor sie schützt, wovor nicht, und wie Sie die Behauptung eines Anbieters überprüfen können.

PassworkPasswork Team

La soberanía de datos es la capacidad de determinar — física, legal y criptográficamente — quién puede acceder a un dato y bajo qué jurisdicción. Una empresa puede cumplir plenamente con el RGPD en el papel y aún así no tener control real sobre dónde residen sus contraseñas. Para las credenciales corporativas, esa brecha entre «cumplimiento» y «control» es donde comienzan las filtraciones, los requerimientos judiciales y las auditorías fallidas.

El Reglamento General de Protección de Datos (RGPD) establece la base que la mayoría de las organizaciones utilizan para evaluar sus prácticas de datos: regula cómo se recopilan, almacenan y transfieren los datos personales, y según el Artículo 3, su ámbito territorial se extiende a cualquier empresa que procese datos de residentes de la UE, independientemente de dónde tenga su sede. 

Las contraseñas y los secretos no son datos ordinarios, por eso la gestión de contraseñas necesita su propio modelo de soberanía, separado del almacenamiento general de archivos. Abren el acceso a todo lo demás, se mueven constantemente entre empleados y rara vez pasan por las herramientas de prevención de pérdida de datos (DLP) o clasificación que vigilan contratos y registros de clientes. Una credencial almacenada en el servidor equivocado, en el país equivocado, bajo las claves de cifrado de otra persona, es una responsabilidad que la mayoría de las listas de verificación de cumplimiento no detectan.

Este artículo desglosa lo que la soberanía realmente significa en tres niveles: ubicación física, cifrado y gobernanza de acceso. Compara los modelos on-premise, aislados y de nube en la UE, y muestra dónde encaja un gestor de contraseñas autoalojado y de conocimiento cero como Passwork en esa decisión.

Qué significa realmente la soberanía de datos para las credenciales

La soberanía de datos es la combinación de tres controles separados: dónde residen físicamente los datos, quién posee las claves de cifrado y quién gobierna el acceso. Perder cualquiera de los tres rompe la soberanía, incluso si los otros dos son sólidos. La mayoría de los proveedores solo publicitan el primero.

• La ubicación física responde dónde están los servidores. Un gestor de contraseñas alojado en Fráncfort todavía cae bajo el ámbito territorial del RGPD, pero también uno alojado en Virginia si procesa datos de residentes de la UE. La ubicación importa para la jurisdicción, no automáticamente para la exposición legal.
• El control del cifrado responde quién puede descifrar los datos. Si el proveedor tiene las claves, una solicitud gubernamental, un infiltrado o una brecha en la infraestructura del proveedor pueden exponer sus credenciales independientemente de la ubicación del servidor.
• La gobernanza de acceso responde quién dentro de su organización puede ver qué. El control de acceso basado en roles (RBAC) y los registros de auditoría determinan si el acceso de un empleado que se va se revoca en minutos o se descubre seis meses después.

La verdadera soberanía de datos requiere los tres elementos. Omitir cualquier componente reduce la arquitectura a una lista de verificación de cumplimiento formal.

Por qué las credenciales son una clase de datos distinta

Las credenciales merecen un tratamiento separado porque son de alto valor, alta circulación y en gran medida invisibles para las herramientas estándar de gobernanza de datos. Un registro de cliente filtrado expone un conjunto de datos. Una contraseña de administrador filtrada expone todos los sistemas a los que ese administrador puede acceder, y sigue funcionando hasta que alguien la rota.

El Informe de Investigaciones de Filtraciones de Datos 2026 de Verizon encontró que las credenciales robadas representaron el 13% de los vectores de acceso inicial, pero esa cifra se triplicó (39%) a lo largo de toda la progresión de la filtración. Las contraseñas también se mueven constantemente: compartidas durante la incorporación, copiadas en tickets, pegadas en hilos de chat, reenviadas cuando un proyecto cambia de manos. Las herramientas DLP diseñadas para detectar la exfiltración de documentos rara vez marcan una contraseña enviada en un mensaje de Slack.

Esa combinación de alto impacto y baja visibilidad es la razón por la que el almacenamiento de credenciales necesita su propio modelo de soberanía en lugar de heredar cualquier política que cubra el almacenamiento general de archivos.

Dónde el almacenamiento estándar en la nube introduce fricción legal

Los gestores de contraseñas estándar en la nube introducen exposición legal a través de cadenas de subprocesadores, transferencias de datos transfronterizas y acceso del personal del proveedor, incluso cuando el proveedor cumple plenamente con el RGPD. El cifrado en reposo no elimina estos riesgos si el proveedor, no el cliente, posee las claves de descifrado.

Tres puntos de fricción específicos aparecen repetidamente durante las revisiones de adquisiciones:

• Subprocesadores. La mayoría de los proveedores de nube dependen de infraestructura, monitoreo o proveedores de soporte subcontratados. Cada subprocesador es una entidad separada con su propia superficie de acceso. El Artículo 28(2) del RGPD requiere que el encargado no recurrirá a otro encargado (subprocesador) sin la autorización previa por escrito, específica o general, del responsable.
• Transferencias a terceros países. El Capítulo V del RGPD regula las transferencias de datos personales fuera de la UE/EEE. El Artículo 44 establece el principio general de que cualquier transferencia no debe socavar el nivel de protección garantizado por el reglamento, y el Artículo 46 requiere garantías apropiadas, como las Cláusulas Contractuales Tipo, cuando no aplica ninguna decisión de adecuación. Las bóvedas de credenciales alojadas en un tercer país, o replicadas a uno con fines de copia de seguridad, caen directamente bajo este capítulo.
• Acceso del personal del proveedor y solicitudes legales. Si el proveedor puede técnicamente descifrar los datos del cliente, esos datos están sujetos al proceso legal en la jurisdicción del proveedor. Una citación, orden judicial o solicitud de divulgación extranjera puede obligar el acceso independientemente de dónde esté registrada su empresa.

NIS2 añade un cuarto ángulo: el Artículo 21(2)(d) requiere que las entidades esenciales e importantes evalúen la seguridad de la cadena de suministro, incluyendo los proveedores y herramientas que utilizan para gestionar credenciales de acceso. Una bóveda de contraseñas situada con un subprocesador externo que no ha verificado cae directamente en ese requisito.

Nada de esto hace que el almacenamiento en la nube sea incumplidor por defecto. Significa que «cumple con el RGPD» es una condición necesaria para la soberanía de credenciales.

Mapeo de las tres capas a modelos de despliegue

Una brecha en cualquier capa individual reabre la exposición que las otras dos pretendían cerrar. La tabla siguiente aplica los tres controles de la primera sección — ubicación, descifrado y acceso — a los modelos entre los que las organizaciones realmente eligen.

• Aislado describe una infraestructura sin ninguna ruta de red a internet, la forma más estricta de aislamiento físico.
• Conocimiento cero significa que el proveedor nunca puede leer sus datos, bajo ninguna circunstancia. 
• Cifrado del lado del cliente es el mecanismo que produce esa garantía: el cifrado y descifrado ocurren en el dispositivo del usuario, usando una contraseña maestra que el proveedor nunca recibe ni almacena, por lo que el servidor solo recibe y transmite texto cifrado. 

Un esquema de cifrado del lado del cliente mal implementado — uno con una contraseña maestra recuperable o una función de derivación de clave débil — no proporciona automáticamente una verdadera garantía de conocimiento cero. Esta distinción determina si «cifrado en la nube» realmente significa algo para la soberanía.

On-premise y aislado: Aislamiento completo, a costa de carga operativa

El despliegue on-premise otorga a una organización control físico y criptográfico completo sobre su bóveda de credenciales, porque los datos nunca abandonan la infraestructura que la organización posee y administra. El aislamiento lleva esto un paso más allá: la infraestructura no tiene ninguna ruta de red a internet, que es la única configuración que elimina completamente la dependencia de la red externa.

Aislamiento del proveedor: Cifrado de conocimiento cero

Passwork se ejecuta completamente dentro del perímetro corporativo, en infraestructura que la organización controla de extremo a extremo. El gestor de contraseñas y secretos cifra y descifra los datos completamente en el lado del cliente, usando una clave derivada de la contraseña maestra del usuario. El servidor nunca recibe ni almacena texto sin formato en ningún momento — solo contiene blobs cifrados y no tiene ninguna clave capaz de descifrarlos. Para organizaciones con requisitos de aislamiento y políticas de segmentación estrictas, esta es a menudo la única arquitectura que satisface la política de seguridad interna. 

Una afirmación como esa no debería aceptarse por fe. El código fuente de Passwork está abierto para que el propio equipo de seguridad de la organización lo audite directamente, línea por línea, en lugar de depender de la descripción del proveedor sobre cómo se implementa el cifrado.

La contrapartida operativa

Ese nivel de aislamiento tiene un coste, pagado en esfuerzo operativo. On-premise traslada el mantenimiento del servidor, los parches, la gestión de copias de seguridad y la responsabilidad del tiempo de actividad del proveedor a su propio equipo de TI. Alguien tiene que aplicar actualizaciones, monitorear el espacio en disco, gestionar certificados TLS y manejar la recuperación ante desastres. Para un pequeño equipo de TI ya sobrecargado con otras prioridades, eso es un coste real. Las organizaciones que eligen el autoalojamiento necesitan un recurso de administrador de sistemas dedicado o un proceso interno gestionado para mantener el despliegue actualizado.

El cifrado de conocimiento cero de Passwork mantiene sus datos ilegibles para cualquiera excepto sus propios usuarios. Revise la arquitectura en las guías de usuario antes de comprometer infraestructura, o pruebe el despliegue completo gratis para verlo funcionando en sus propios servidores.

Alojamiento en la nube de la UE: Viable, pero solo con cifrado del lado del cliente

El alojamiento en la nube de la UE puede satisfacer los requisitos jurisdiccionales para equipos más pequeños sin personal de infraestructura dedicado, pero solo si el proveedor implementa cifrado obligatorio del lado del cliente (CSE). Sin CSE, una bóveda alojada en la UE todavía deja al proveedor capaz de descifrar los datos del cliente, lo que reabre la misma exposición que el alojamiento en la UE debía cerrar.

Bajo un modelo CSE adecuado, la contraseña maestra nunca abandona el dispositivo del usuario, y los servidores del proveedor procesan y almacenan solo texto cifrado. Incluso con acceso físico completo al servidor, el proveedor no puede leer el contenido de la bóveda. Esta es una garantía significativamente diferente a «nuestros centros de datos están en la UE», que aborda la jurisdicción pero no dice nada sobre quién tiene las claves.

El alojamiento en la nube de la UE con CSE reduce la exposición legal y satisface los requisitos de residencia de datos para muchos marcos de cumplimiento, pero no es la misma garantía que la soberanía on-premise completa. La infraestructura, la capa de red y el hardware físico permanecen fuera del control directo del cliente. Para organizaciones con mandatos de aislamiento o políticas estrictas de autoalojamiento, la nube de la UE no es un sustituto, independientemente de la fortaleza del cifrado.

On-premise sin conocimiento cero todavía confía a los administradores locales el acceso al texto sin formato. La nube de la UE sin él todavía confía al personal de infraestructura del proveedor. De cualquier manera, la garantía solo se mantiene cuando la contraseña maestra nunca abandona el dispositivo del usuario.

Verificación de las afirmaciones del proveedor: Qué debe comprobar el departamento de compras

Las afirmaciones de soberanía son tan creíbles como la evidencia de terceros que las respalda. Esta verificación se aplica independientemente del modelo de despliegue que elija: un certificado no le dice dónde residen los datos, pero sí le dice si las otras afirmaciones del proveedor se sostienen. Los equipos de compras deben basar una decisión de autoalojamiento en la capacidad administrativa interna y los requisitos de política, luego validar al proveedor preseleccionado a través de certificación independiente, auditoría propia y pruebas de seguridad públicas.

Cuatro verificaciones importan en la práctica:

• La certificación ISO/IEC 27001 confirma que un sistema de gestión de seguridad de la información ha sido auditado de forma independiente según el estándar internacional. Passwork posee certificación ISO/IEC 27001:2022, emitida por MSECB y verificable a través de la base de datos IAF CertSearch.
• La preparación para NIS2 y RGPD importa para cualquier organización que caiga bajo el alcance de cualquiera de las dos regulaciones. Los requisitos de cadena de suministro del Artículo 21 de NIS2 se extienden a las herramientas que las entidades esenciales e importantes utilizan para gestionar credenciales de acceso, mientras que el Artículo 32 del RGPD requiere «medidas técnicas y organizativas apropiadas», incluyendo cifrado, para cualquier sistema que maneje datos personales. Las organizaciones que evalúan proveedores contra estos requisitos pueden revisar el enfoque de Passwork sobre el cumplimiento de NIS2 como un punto de referencia.
• Los derechos de auditoría del código fuente confirman que una afirmación de conocimiento cero es realmente verdadera en lugar de lenguaje de marketing. En un diseño de conocimiento cero genuino, el proveedor no puede recuperar la contraseña maestra de un usuario individual bajo ninguna circunstancia — ni mediante un reinicio del backend, ni mediante un ticket de soporte, ni bajo presión legal. Si un usuario la olvida, los datos detrás de ella desaparecen por diseño, porque el proveedor nunca tuvo la clave en primer lugar. Passwork abre su código fuente a los propios equipos de seguridad de los clientes exactamente por esta razón: es la forma de confirmar que la implementación del cifrado coincide con la arquitectura que el proveedor describe.
• Las pruebas de penetración públicas proporcionan evidencia más allá de la postura de seguridad autodeclarada. Passwork ha completado una prueba de penetración independiente a través de HackerOne, que cubre el manejo seguro de datos, el OWASP Top 10 y SANS Top 25, autenticación y control de acceso a API.

Elección de un modelo de despliegue: Un marco de decisión

El modelo de despliegue correcto depende de cinco factores prácticos: 

• Requisitos de aislamiento 
• Alojamiento obligatorio en la UE 
• Tamaño del equipo de administración
• Política interna de autoalojamiento
• Requisitos de control de infraestructura

Mapear estos factores contra las opciones de despliegue evita el error común de elegir basándose solo en el precio o el reconocimiento de marca. Utilice esta matriz de decisión de residencia de credenciales para mapear las restricciones organizacionales a un modelo de despliegue:

Ninguna de estas filas es mutuamente excluyente en la práctica. Una institución financiera podría ejecutar on-premise para su bóveda principal mientras acepta herramientas basadas en la nube para flujos de trabajo de menor sensibilidad. La matriz es un punto de partida para la conversación con los interesados de seguridad y cumplimiento.

Cómo la arquitectura de Passwork se mapea a estas capas

El despliegue autoalojado de Passwork aborda la brecha de soberanía descrita a lo largo de este artículo combinando aislamiento físico, cifrado de conocimiento cero y gobernanza de acceso controlada por el cliente en una sola arquitectura. La bóveda se despliega en infraestructura que el cliente posee, ya sea un servidor Linux individual, un entorno de Windows Server o un contenedor Docker dentro de una red aislada.

El cifrado utiliza AES-256 con un diseño de conocimiento cero, lo que significa que la infraestructura, si alguna vez fuera comprometida, solo contiene texto cifrado. El acceso se gobierna a través de permisos basados en roles y un registro de auditoría completo, para que los administradores puedan ver quién accedió a qué credencial y cuándo, y revocar el acceso inmediatamente cuando alguien cambia de rol o se va. La integración con AD/LDAP y SAML SSO permite que la gobernanza de acceso se conecte a la infraestructura de identidad existente en lugar de funcionar como un silo separado.

Esto deliberadamente no es una afirmación de que el autoalojamiento sea adecuado para todos. Las organizaciones sin requisitos de aislamiento o mandatos estrictos de autoalojamiento pueden encontrar suficiente una opción en la nube con cifrado del lado del cliente apropiado. El punto es que cuando la soberanía total es el requisito, la arquitectura necesita soportarlo estructuralmente.

Soberanía de datos en la gestión de contraseñas: Cómo aplicarla a su evaluación

La soberanía es una alineación continua entre dónde residen los datos, quién tiene las claves y quién gobierna el acceso — y esa alineación necesita revisarse cada vez que cambia su infraestructura, contratos con proveedores o alcance regulatorio.

Comience mapeando su propia organización contra los cuatro factores de la matriz de decisión: requisito de aislamiento, alojamiento obligatorio en la UE, tamaño del equipo de administración y política interna de autoalojamiento. Ese mapeo le dirá más sobre el modelo de despliegue correcto que cualquier página de marketing de proveedores.

La única forma de confirmar que una arquitectura autoalojada se adapta a su infraestructura es ejecutarla allí. Passwork ofrece una prueba gratuita que puede desplegar en sus propios servidores, con funcionalidad completa y sin que ningún dato abandone su entorno.

Preguntas frecuentes

Gestión de credenciales SaaS: 5 pasos para centralizar su pila de aplicaciones

La gestión de credenciales SaaS convierte contraseñas dispersas y claves API en un inventario que puede compartir intencionalmente y revocar al salir. Aquí está el marco de cinco pasos: inventario, estructura, migración, control de acceso y automatización.

PassworkPasswork Team

Verizon DBIR 2026: 10 estadísticas que deberían cambiar su estrategia de seguridad

El DBIR 2026 de Verizon analizó más de 22.000 filtraciones en 145 países. La explotación de vulnerabilidades superó al abuso de credenciales como principal vector de ataque, mientras que el ransomware, el riesgo de terceros y los ataques asistidos por IA crecieron significativamente. Aquí están los 10 números que importan.

Passwork BlogAlex Muntyan

¿Qué es el cifrado de conocimiento cero? Cómo funciona en 5 minutos

El cifrado de conocimiento cero significa que el servidor nunca tiene sus claves de descifrado, solo texto cifrado. Aprenda cómo funciona la cadena de claves, contra qué protege, contra qué no, y cómo verificar la afirmación de un proveedor.

PassworkPasswork Team

Data sovereignty is the ability to determine, physically, legally, and cryptographically, who can access a piece of data and under which jurisdiction. A company can be fully GDPR-compliant on paper and still have no real control over where its passwords live. For corporate credentials, that gap between "compliant" and "in control" is where breaches, subpoenas, and failed audits start.

The General Data Protection Regulation (GDPR) sets the baseline most organizations use to judge their data practices: it governs how personal data is collected, stored, and transferred, and under Article 3 its territorial scope extends to any company processing EU residents' data, regardless of where that company is headquartered. 

Passwords and secrets are not ordinary data, which is why password management needs its own sovereignty model, separate from general file storage. They open access to everything else, they move between employees constantly, and they rarely pass through the data loss prevention (DLP) or classification tools that watch over contracts and customer records. A credential stored on the wrong server, in the wrong country, under someone else's encryption keys, is a liability that most compliance checklists don't catch.

This article breaks down what sovereignty actually means at three levels: physical location, encryption, and access governance. It compares on-premise, air-gapped, and EU cloud models, and shows where a self-hosted, zero-knowledge password manager like Passwork fits into that decision.

What data sovereignty actually means for credentials

Data sovereignty is the combination of three separate controls: where data physically sits, who holds the encryption keys, and who governs access to it. Losing any one of the three breaks sovereignty, even if the other two are solid. Most vendors advertise only the first.

• Physical location answers where the servers are. A password manager hosted in Frankfurt still falls under GDPR's territorial scope, but so does one hosted in Virginia if it processes EU residents' data. Location matters for jurisdiction, not automatically for legal exposure.
• Encryption control answers who can decrypt the data. If the vendor holds the keys, a government request, an insider, or a breach at the vendor's infrastructure can expose your credentials regardless of server location.
• Access governance answers who inside your organization can see what. Role-based access control (RBAC) and audit logs determine whether a departing employee's access is revoked in minutes or discovered six months later.

True data sovereignty requires all three elements. Omitting any component reduces the architecture to a formal compliance checklist.

Why credentials are a distinct data class

Credentials deserve separate handling because they are high-value, high-circulation, and largely invisible to standard data governance tools. A leaked customer record exposes one dataset. A leaked admin password exposes every system that admin can reach, and it keeps working until someone rotates it.

Verizon's 2026 Data Breach Investigations Report found stolen credentials accounted for 13% of initial access vectors, but that figure tripled (39%) across the full breach progression. Passwords also move constantly: shared during onboarding, copied into tickets, pasted into chat threads, forwarded when a project changes hands. DLP tools built to catch document exfiltration rarely flag a password dropped into a Slack message.

That combination of high impact and low visibility is why credential storage needs its own sovereignty model instead of inheriting whatever policy covers general file storage.

Where standard cloud storage introduces legal friction

Standard cloud password managers introduce legal exposure through subprocessor chains, cross-border data transfers, and vendor staff access, even when the vendor is fully GDPR-compliant. Encryption at rest does not remove these risks if the vendor, not the customer, holds the decryption keys.

Three specific friction points show up repeatedly during procurement reviews:

• Subprocessors. Most cloud vendors rely on subcontracted infrastructure, monitoring, or support providers. Each subprocessor is a separate entity with its own access surface. GDPR Article 28(2) requires that the processor shall not engage another processor (subprocessor) without prior specific or general written authorisation of the controller.
• Third-country transfers. GDPR Chapter V governs transfers of personal data outside the EU/EEA. Article 44 sets the general principle that any transfer must not undermine the level of protection guaranteed by the regulation, and Article 46 requires appropriate safeguards, such as Standard Contractual Clauses, when no adequacy decision applies. Credential vaults hosted in a third country, or replicated to one for backup purposes, fall squarely under this chapter.
• Vendor staff access and legal requests. If the vendor can technically decrypt customer data, that data is subject to legal process in the vendor's jurisdiction. A subpoena, warrant, or foreign disclosure order can compel access regardless of where your company is registered.

NIS2 adds a fourth angle: Article 21(2)(d) requires essential and important entities to assess supply chain security, including the vendors and tools they use to manage access credentials. A password vault sitting with a third-party subprocessor you haven't vetted falls squarely into that requirement.

None of this makes cloud storage non-compliant by default. It means "GDPR-compliant" is a necessary condition for credential sovereignty.

Mapping the three layers to deployment models

A gap in any single layer reopens the exposure the other two were meant to close. The table below applies the three controls from the first section, location, decryption, and access, to the models organizations actually choose between.

• Air-gapped describes infrastructure with no network path to the internet at all, the strictest form of physical isolation.
• Zero-knowledge means the vendor can never read your data, under any circumstances. 
• Client-side encryption is the mechanism that produces that guarantee: encryption and decryption happen on the user's device, using a master password the vendor never receives or stores, so the server only ever holds and transmits ciphertext. 

A poorly implemented client-side encryption scheme, one with a recoverable master password or a weak key derivation function, doesn't automatically deliver a true zero-knowledge guarantee. This distinction determines whether "encrypted in the cloud" actually means anything for sovereignty.

On-premise and air-gapped: Complete isolation, at the cost of operational load

On-premise deployment gives an organization complete physical and cryptographic control over its credential vault, because the data never leaves infrastructure the organization owns and administers. Air-gapping takes this a step further: the infrastructure has no network path to the internet at all, which is the only setup that removes external network dependency entirely.

Isolation from the provider: zero-knowledge encryption

Passwork runs entirely inside the corporate perimeter, on infrastructure the organization controls end to end. The password and secrets manager encrypts and decrypts data entirely on the client side, using a key derived from the user's master password. The server never receives or stores plaintext at any point, it holds only encrypted blobs and has no key capable of decrypting them. For organizations with air-gap requirements and strict segmentation policies, this is often the only architecture that satisfies internal security policy. 

A claim like that shouldn't be taken on faith. Passwork's source code is open for the organization's own security team to audit directly, line by line, instead of relying on the vendor's description of how encryption is implemented.

The operational trade-off

That level of isolation comes with a bill, paid in operational effort. On-premise shifts server maintenance, patching, backup management, and uptime responsibility from the vendor to your own IT team. Someone has to apply updates, monitor disk space, manage TLS certificates, and handle disaster recovery. For a small IT team already stretched across other priorities, that's a real cost. Organizations choosing self-hosting need either a dedicated sysadmin resource or a managed internal process for keeping the deployment current.

Passwork's zero-knowledge encryption keeps your data unreadable to anyone but your own users. Review the architecture in the user guides before committing infrastructure, or test the full deployment free to see it running on your own servers.

EU cloud hosting: Viable, but only with client-side encryption

EU cloud hosting can satisfy jurisdictional requirements for smaller teams without dedicated infrastructure staff, but only if the vendor implements mandatory client-side encryption (CSE). Without CSE, an EU-hosted vault still leaves the vendor capable of decrypting customer data, which reopens the same exposure that hosting in the EU was supposed to close.

Under a proper CSE model, the master password never leaves the user's device, and the vendor's servers process and store only ciphertext. Even with full physical access to the server, the vendor cannot read the vault's contents. This is a meaningfully different guarantee than "our data centers are in the EU," which addresses jurisdiction but says nothing about who holds the keys.

EU cloud hosting with CSE narrows legal exposure and satisfies data residency requirements for many compliance frameworks, but it isn't the same guarantee as full on-premise sovereignty. The infrastructure, network layer, and physical hardware remain outside the customer's direct control. For organizations with air-gap mandates or strict self-hosting policies, EU cloud is not a substitute, regardless of encryption strength.

On-premise without zero-knowledge still trusts local admins with plaintext access. EU cloud without it still trusts the vendor's infrastructure staff. Either way, the guarantee only holds when the master password never leaves the user's device.

Verifying vendor claims: What procurement should check

Sovereignty claims are only as credible as the third-party evidence behind them. This check applies regardless of which deployment model you choose: a certificate doesn't tell you where data sits, but it does tell you whether a vendor's other claims hold up. Procurement teams should base a self-hosting decision on internal admin capacity and policy requirements, then validate the shortlisted vendor through independent certification, own audit, and public security testing.

Four checks matter in practice:

• ISO/IEC 27001 certification confirms an information security management system has been independently audited against the international standard. Passwork holds ISO/IEC 27001:2022 certification, issued by MSECB and verifiable through the IAF CertSearch database.
• NIS2 and GDPR readiness matters for any organization that falls under either regulation's scope. NIS2 Article 21's supply chain requirements extend to the tools essential and important entities use to manage access credentials, while GDPR Article 32 requires "appropriate technical and organisational measures," including encryption, for any system handling personal data. Organizations evaluating vendors against these requirements can review Passwork's approach to NIS2 compliance as one reference point.
• Source code audit rights confirm that a zero-knowledge claim is actually true rather than marketing language. In a genuine zero-knowledge design, the vendor cannot recover an individual user's master password under any circumstance, not through a backend reset, not through a support ticket, not under legal pressure. If a user forgets it, the data behind it is gone by design, because the vendor never held the key in the first place. Passwork opens its source code to customers' own security teams for exactly this reason: it's the way to confirm the encryption implementation matches the architecture the vendor describes.
• Public penetration testing provides evidence beyond self-reported security posture. Passwork has completed an independent penetration test through HackerOne, covering secure data handling, the OWASP Top 10 and SANS Top 25, authentication, and API access control.

Choosing a deployment model: A decision framework

The right deployment model depends on five practical factors: 

• Air-gap requirements 
• Mandatory EU hosting 
• Admin team size
• Internal self-hosting policy
• Infrastructure control requirements

Matching these factors against deployment options avoids the common mistake of choosing based on price or brand recognition alone. Use this credential residency decision matrix to map organizational constraints to a deployment model:

None of these rows are mutually exclusive in practice. A financial institution might run on-premise for its core vault while accepting cloud-based tools for lower-sensitivity workflows. The matrix is a starting point for the conversation with security and compliance stakeholders.

How Passwork's architecture maps to these layers

Passwork's self-hosted deployment addresses the sovereignty gap described throughout this article by combining physical isolation, zero-knowledge encryption, and customer-controlled access governance in one architecture. The vault deploys on infrastructure the customer owns, whether that's a single Linux server, a Windows Server environment, or a Docker container inside an air-gapped network.

Encryption uses AES-256 with a zero-knowledge design, meaning the infrastructure, if it were ever compromised, holds only ciphertext. Access is governed through role-based permissions and a full audit log, so administrators can see who accessed which credential and when, and revoke access immediately when someone changes roles or leaves. Integration with AD/LDAP and SAML SSO lets access governance plug into existing identity infrastructure rather than running as a separate silo.

This is deliberately not a claim that self-hosting is right for everyone. Organizations without air-gap requirements or strict self-hosting mandates may find a cloud option with proper client-side encryption sufficient. The point is that when full sovereignty is the requirement, the architecture needs to support it structurally.

Data sovereignty in password management: How to apply it to your evaluation

Sovereignty is an ongoing alignment between where data sits, who holds the keys, and who governs access, and that alignment needs revisiting whenever your infrastructure, vendor contracts, or regulatory scope changes.

Start by mapping your own organization against the four factors in the decision matrix: air-gap requirement, mandatory EU hosting, admin team size, and internal self-hosting policy. That mapping will tell you more about the right deployment model than any vendor's marketing page.

The only way to confirm a self-hosted architecture fits your infrastructure is to run it there. Passwork offers a free trial you can deploy on your own servers, with full functionality and no data ever leaving your environment.

Frequently Asked Questions

SaaS credential management: 5 steps to centralize your app stack

SaaS credential management turns scattered passwords and API keys into one inventory you can share on purpose and revoke on exit. Here’s the five-step framework: inventory, structure, migration, access control, and automation.

PassworkPasswork 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

What is zero-knowledge encryption? How it works in 5 minutes

Zero-knowledge encryption means the server never holds your decryption keys, only ciphertext. Learn how the key chain works, what it protects against, what it doesn’t, and how to verify a vendor’s claim.

PassworkPasswork Team

SaaS-Zugangsdatenverwaltung bezeichnet die Praxis, jedes Passwort, jeden gemeinsam genutzten Login und jeden Zugriffsschlüssel zu erfassen, den ein Unternehmen für Cloud-Anwendungen wie Salesforce oder Slack verwendet, und zu kontrollieren, wer jeden einzelnen davon einsehen und nutzen kann. Es bedeutet, jede Zugangsdaten als Inventar zu behandeln, das Sie finden, gezielt teilen und entziehen können, wenn Mitarbeiter das Unternehmen verlassen. Das Ziel ist ein kontrollierter Tresor für menschliche Passwörter und maschinelle Secrets — nicht fünf Tools, von denen jedes nur einen Teil der Wahrheit enthält.

Die meisten Unternehmen nutzen mehr SaaS-Anwendungen, als die IT offiziell erfasst: ein CRM-Login in einem Browser-Profil, ein Gmail-Passwort, das über Slack geteilt wird, Staging-Datenbank-Strings, die in einem privaten Repository liegen. Niemand ist zentral für diese Logins verantwortlich, was bedeutet, dass auch niemand sie überwacht. Jedes einzelne ist ein offener Einstiegspunkt, der monatelang bestehen kann, bevor jemand bemerkt, dass er missbraucht wurde.

Passwork ist für genau diese Aufgabe konzipiert: ein Business-Passwort- und Secrets-Manager, den Sie auf Ihren eigenen Servern oder als Cloud-Dienst betreiben können, mit gemeinsam genutzten Tresoren, rollenbasiertem Zugriff, LDAP/SSO und einer REST API für die Automatisierung. Die fünf Schritte unten funktionieren gleichermaßen für Teams, die Passwork bereits nutzen, wie für Teams, die noch ein System evaluieren.

Was als SaaS-Zugangsdaten zählt

SaaS-Zugangsdaten sind alles, was verwendet wird, um Identität nachzuweisen und Zugang zu erhalten: ein Passwort, ein gemeinsam genutzter Login, ein API-Schlüssel oder ein Sicherheitszertifikat. Die Liste der SaaS-Anwendungen eines Unternehmens (wofür es bezahlt) ist nicht dasselbe wie die Liste seiner Zugangsdaten (wie auf jede Anwendung tatsächlich zugegriffen wird). Eine Anwendung kann mehrere haben: zehn Personen, die sich über SSO anmelden, ein gemeinsam genutztes Abrechnungskonto und ein API-Schlüssel, den ein Skript verwendet, um Berichte abzurufen.

Die Anwendungen zu kennen, die ein Unternehmen nutzt, zeigt, wofür es bezahlt. Die Zugangsdaten zu kennen zeigt, wer Zugang hat, und das ist die Liste, die für die Sicherheit relevant ist.

Schritt 1: Erstellen Sie Ihr SaaS-Zugangsdatenverwaltungs-Inventar

Beginnen Sie mit einer SaaS-Zugangsdatenliste. Gruppieren Sie nach Risiko. Führen Sie während dieses Schritts keine „Aufräumarbeiten" durch. Aufräumen während der Inventur schafft ein zweites Chaos. Erfassen, dann verschieben. Notieren Sie für jede SaaS-Anwendung und jeden internen Dienst:

• Um welches Tool es sich handelt (Name der SaaS-Anwendung)
• Wer für das Konto verantwortlich ist (Person oder Team)
• Wo das Secret aktuell liegt (Chat, Wiki, CI-Variable, Klebezettel)
• Wer es im nächsten Quartal benötigt (neue Mitarbeiter, Projekte oder Teams)
• Was ausfällt, wenn es verschwindet (abhängige Workflows, Integrationen oder Dienste)

Beispiel:

Ein solcher Eintrag sagt jedem genau, wen er fragen muss, wo er suchen soll und was auf dem Spiel steht.

Schritt 2: Gestalten Sie Tresore und Ordner entsprechend Ihrer Arbeitsweise

Ein Passwort-Tresor unterstützt die SaaS-Zugangsdatenverwaltung nur dann, wenn seine Ordnerhierarchie widerspiegelt, wie Teams bereits nach Zugriffen suchen — nicht wie das alte, chaotische System gewachsen ist. Zentralisierung scheitert, wenn der neue Speicherort das Chaos nur verlagert. Wählen Sie eine Hierarchie, die jemand in einem Satz erklären kann. Gruppieren Sie Tresore nach Abteilung oder Produkt, dann teilen Sie Infrastruktur-Secrets nach Umgebung auf.

Die Verschachtelung bleibt in den meisten Bereichen flach. Zwei Ebenen sind normalerweise ausreichend: ein Tresor für das Team, ein Ordner für die Tool-Kategorie. Fügen Sie eine dritte Ebene nur hinzu, wenn ein Ordner der zweiten Ebene allein nicht einheitlich ist. Wenn ein Ordner bereits alles beschreibt, was er enthält, hören Sie dort auf.

Beispiel für eine Datenhierarchie:

Zwei Zielgruppen nutzen denselben Baum unterschiedlich. Menschen navigieren nach Teamnamen. Pipelines rufen nach Ordner-ID ab, weshalb Onboarding-Dokumentationen für DevOps Umgebungs-basierte Ordner empfehlen: Ein Job kann alles, was er braucht, mit einer einzigen --folder-id abrufen, anstatt SaaS-Zugangsdaten in Code einzufügen.

Namensregeln helfen mehr als tiefe Verschachtelung:

• Bevorzugen Sie stripe-prod-dashboard gegenüber Neues Passwort (2)
• Setzen Sie die Umgebung in den Namen oder Ordner, nicht nur in jemandes Kopf
• Verwenden Sie benutzerdefinierte Felder für Nicht-Passwort-Secrets (API-Schlüssel, Client-IDs), anstatt alles in das Passwortfeld zu packen

Die letzte Entscheidung ist, wer den Tresor überhaupt sehen kann. Unternehmenstresore sind der Ort, an den Team-SaaS-Zugangsdaten gehören. Private Tresore sind für persönliche Arbeits-Logins, die den Mitarbeiter nicht überdauern sollten.

Schritt 3: Einmal migrieren, dann die parallelen Speicherorte löschen

Die Migration von SaaS-Zugangsdaten reduziert das Cloud-Management-Risiko nur dann, wenn der alte Speicherort zu einem festen Datum abgeschaltet wird. Einen Chat-Kanal, eine Tabelle und einen Passwort-Manager parallel als konkurrierende Wahrheitsquellen zu betreiben, reproduziert nur das Chaos, das die Migration eigentlich beheben sollte.

Import schlägt Neueintippen. Passwork akzeptiert strukturierte Importe (JSON, CSV und gängige Passwort-Manager-Exportformate). Migrieren Sie zuerst eine Pilotabteilung — genug Datensätze, damit die Leute den Schmerz der alten Methode spüren, aber nicht so viele, dass ein schlechtes Ordnerdesign permanent wird.

Regeln für eine ehrliche Migration:

1. Eine Wahrheitsquelle nach der Umstellung. Der Slack-Kanal und das gemeinsam genutzte Google Sheet werden zu schreibgeschützten Archiven und werden dann an einem veröffentlichten Datum gelöscht.
2. Rotieren Sie SaaS-Zugangsdaten nach dem Import, wenn der alte Kanal geteilt wurde. Alles, was im Chat existierte, ist per Definition kompromittiert. Das Passwort in der SaaS-Anwendung zu ändern und dann den Tresor zu aktualisieren, ist besser, als zuerst den Tresor zu aktualisieren und zu hoffen, dass die Anwendung den alten Wert noch akzeptiert.
3. Shortcuts statt Kopien. Wenn zwei Teams dieselben SaaS-Zugangsdaten benötigen, teilen Sie den Zugriff oder verwenden Sie einen Shortcut, anstatt das Secret zu duplizieren. Duplikate driften auseinander.

Rechnen Sie mit zwei chaotischen Wochen. Das ist normal. Der Fehlermodus ist, Notion und den Passwort-Tresor sechs Monate lang beide als „offiziell" zu belassen.

Schritt 4: Zugriff mit Rollen, Gruppen und Tresor-Berechtigungen steuern

Zentrale SaaS-Zugangsdatenspeicherung ohne Least-Privilege-Prinzip macht aus einem Passwort-Tresor eine sehr große, durchsuchbare Ablage. Effektive SaaS-Zugangsdatenverwaltung trennt, was eine Person mit der Plattform selbst tun kann, von dem, was sie mit einem bestimmten Satz gemeinsam genutzter Secrets tun kann.

Passwork trennt zwei Ebenen:

• Systemrollen — was jemand mit der Instanz tun kann (Benutzer einladen, SSO ändern, das Aktivitätsprotokoll lesen). Integrierte Rollen umfassen Besitzer, Admin und Benutzer. Unbegrenzte benutzerdefinierte Rollen ermöglichen es, Support- oder Auditor-Rollen zu erstellen, ohne vollständige Admin-Rechte zu vergeben.
• Benutzergruppen — was sie mit gemeinsam genutzten SaaS-Zugangsdaten tun können. Die Stufen reichen von Verboten über Lesen, Bearbeiten und Vollständiger Zugang bis hin zu Admin für diese Ressource.

Erteilen Sie Zugriff an Gruppen und ordnen Sie dann Personen den Gruppen zu. Wenn jemand dem Support beitritt, erbt er den Tresor-Zugriff mit der Gruppe. Wenn er geht, entfernen Sie ihn einmal. LDAP/AD kann die Gruppenmitgliedschaft synchronisieren, sodass Verzeichnisänderungen in den Passwort-Tresor fließen, anstatt auf ein Ticket zu warten.

Seien Sie streng mit Admin-Rechten für Tresore. Die meisten Personen benötigen Lese-Zugriff auf die Anwendungen, die sie nutzen. Admin ist für Teamleiter, die Ordner organisieren und überprüfen, wer Zugriff hat.

Schritt 5: Identität, Automatisierung und Offboarding verbinden

Ein Passwort-Tresor, der nur für interaktive Logins verwendet wird, deckt die Hälfte der SaaS-Zugangsdatenverwaltung ab. Die andere Hälfte sind die Machine-to-Machine-Secrets, die Pipelines zur Build- oder Deploy-Zeit abrufen. Die Anbindung des Tresors an SSO, LDAP/AD und eine CI-kompatible API macht ihn zum einzigen Kontrollpunkt für sowohl menschliche Logins als auch automatisierte Cloud-Management-Workflows.

• SAML SSO damit Personen den Passwort-Tresor mit demselben IdP betreten, den sie für den Rest des SaaS-Stacks verwenden (Azure AD, Okta, ADFS, Google Workspace und ähnliche).
• LDAP/AD wenn das Verzeichnis die Wahrheitsquelle für Konten und gruppenbasierten Tresor-Zugriff ist.
• Browser-Erweiterung und Desktop-/Mobile-Clients damit der tägliche Weg Autofill ist, nicht Kopieren-Einfügen aus einem Web-Tab.

Für die maschinelle Seite des Stacks halten Sie Menschen aus CI heraus:

• Verwenden Sie ein Service-Konto mit einem API-Schlüssel (oder Sitzungs-Tokens, die von passwork-cli verwendet werden), das auf die Tresore und Ordner beschränkt ist, die die Pipeline für den SaaS-Zugangsdatenzugriff benötigt.
• Rufen Sie Secrets zur Job-Zeit ab. Baken Sie sie nicht in Images ein.
• Rotieren: Aktualisieren Sie das Secret zuerst im Zielsystem, dann speichern Sie den neuen Wert im Passwort-Tresor — die umgekehrte Reihenfolge verursacht stille Ausfälle.
• Überprüfen Sie das Aktivitätsprotokoll (und Syslog/CEF-Export an SIEM, falls vorhanden) auf Kopien, Exporte und Zugriffsänderungen.

Offboarding ist der Punkt, an dem sich dieses Setup auszahlt. Deaktivieren Sie das Konto des ausscheidenden Benutzers, widerrufen Sie seine API-Sitzungen und bestätigen Sie, dass er aus jeder Gruppe entfernt wurde. Wenn ein gemeinsam genutztes SaaS-Admin-Passwort nur im Tresor lag, ist das Rotieren eine Aktion, keine Suche durch fünf Postfächer, um zu sehen, wer sonst noch eine Kopie hatte.

Wie richtige SaaS-Zugangsdatenverwaltung aussieht

SaaS-Zugangsdatenverwaltung ist zentralisiert, wenn der Zugriff über Gruppen statt über Direktnachrichten läuft, das Offboarding den Passwort-Tresor-Zugriff mit einer Aktion entzieht und jede Zugangsdatenabfrage in einem Aktivitätsprotokoll nachverfolgt werden kann. Nichts davon erfordert ein langes Programm — Inventur, Struktur und Migration laufen parallel über einige Wochen.

Sie sind zentralisiert, wenn:

• Ein neuer Mitarbeiter Tresor-Zugriff über eine Gruppe erhält, nicht über eine Direktnachricht mit fünf Passwörtern
• Ein ausscheidender Mitarbeiter den SaaS-Zugriff verliert, ohne eine Schnitzeljagd
• Entwickler eine Pipeline auf eine Ordner-ID richten können und aufhören, .env-Dateien zu committen
• Die Sicherheitsabteilung die Frage „Wer konnte den Stripe-Login letzten Monat sehen?" aus dem Aktivitätsprotokoll beantworten kann

Nichts davon erfordert ein Zwölf-Monats-Programm. Inventur in einer Woche. Struktur und Pilot in einer weiteren. Migration in Wellen. Berechtigungen und SSO parallel zu den Wellen. Automatisierung zuletzt — nachdem die Ordnerstruktur steht.

Fazit

Die Zentralisierung von SaaS-Zugangsdaten funktioniert nur, wenn das Tool, das sie verwaltet, durchsetzt, wer für jeden Tresor verantwortlich ist, menschliche Logins und Service-Konten auf getrennten Pfaden hält und einen Nachweis produziert, den Sie der Sicherheitsabteilung übergeben können, ohne ihn aus dem Gedächtnis zu rekonstruieren.

Passwork bindet diese Verantwortlichkeit an eine Rolle, die Sie im Voraus definieren, nicht an denjenigen, der zufällig zuerst auf „Tresor erstellen" geklickt hat. Wenn also die Person, die den Marketing-Tresor eingerichtet hat, das Unternehmen verlässt, verschwindet die Aufsicht nicht mit ihr — sie bleibt bei der Rolle. Service-Konten handhaben die maschinelle Seite auf dieselbe Weise: Eine CI-Pipeline erhält ihre eigene begrenzte Identität, anstatt still auf dem persönlichen Login von jemandem zu laufen, lange nachdem diese Person das Team gewechselt hat.

Menschliche Passwörter und maschinelle Secrets landen auf derselben Plattform, zu einem Preis. Das ist ein Anbieter statt zwei und ein Aktivitätsprotokoll statt zusammengestückter Exporte aus einem Passwort-Manager und einem separaten Secrets-Tool.

Häufig gestellte Fragen

Verizon DBIR 2026: 10 Statistiken, die Ihre Sicherheitsstrategie ändern sollten

Verizons DBIR 2026 analysierte über 22.000 Sicherheitsverletzungen in 145 Ländern. Die Ausnutzung von Schwachstellen überholte den Missbrauch von Zugangsdaten als häufigster Angriffsvektor, während Ransomware, Drittanbieter-Risiken und KI-gestützte Angriffe alle stark zunahmen. Hier sind die 10 Zahlen, die zählen.

PassworkAlex Muntyan

Passworks Tresor-Richtlinien: Ein CIO-Leitfaden für Unternehmenssicherheit

Passworks Tresor-Typen binden Admin-Rechte an die Tresor-Richtlinie selbst, nicht an denjenigen, der ihn erstellt hat, und schließen damit eine Lücke, von der die meisten Unternehmen nicht einmal wissen, dass sie existiert. Dieser Leitfaden gibt CIOs und CISOs ein funktionierendes Modell für Tresor-Governance, abgestimmt auf NIS2- und ISO 27001-Anforderungen.

PassworkPasswork Team

Was ist Privileged Access Management? Ein vollständiger Leitfaden

Privilegierte Konten sind die wertvollsten Ziele für Angreifer. Eine kompromittierte Admin-Zugangsdaten gibt volle Kontrolle über Infrastruktur, Daten und Anwendungen. PAM adressiert dies durch Credential Vaulting, Sitzungsüberwachung und Durchsetzung des Least-Privilege-Prinzips. So funktioniert es in der Praxis.

Passwork BlogAlex Muntyan

La gestión de credenciales SaaS es la práctica de rastrear cada contraseña, inicio de sesión compartido y clave de acceso que una empresa utiliza para aplicaciones en la nube como Salesforce o Slack, y controlar quién puede ver y usar cada una. Significa tratar cada credencial como un inventario que se puede encontrar, compartir de forma deliberada y revocar cuando las personas se van. El objetivo es una bóveda controlada única para contraseñas humanas y secretos de máquinas — no cinco herramientas que cada una guarda una parte de la verdad

La mayoría de las empresas usan más aplicaciones SaaS de las que TI rastrea oficialmente: un inicio de sesión de CRM en un perfil de navegador, una contraseña de Gmail compartida por Slack, cadenas de conexión de bases de datos de staging en un repositorio privado. Nadie es propietario central de ninguno de estos inicios de sesión, lo que significa que nadie los está vigilando tampoco. Cada uno es un punto de entrada abierto que podría permanecer ahí durante meses antes de que alguien note que ha sido mal utilizado.

Passwork está diseñado para ese trabajo: un gestor de contraseñas y secretos empresarial que puede ejecutarse en sus propios servidores o como servicio en la nube, con bóvedas compartidas, acceso basado en roles, LDAP/SSO y una REST API para automatización. Los cinco pasos a continuación funcionan de la misma manera para equipos que ya usan Passwork y para equipos que todavía están evaluando un sistema.

Qué cuenta como credencial SaaS

Una credencial SaaS es cualquier cosa utilizada para demostrar identidad y obtener acceso: una contraseña, un inicio de sesión compartido, una clave API o un certificado de seguridad. La lista de aplicaciones SaaS de una empresa (lo que paga) no es lo mismo que su lista de credenciales (cómo se accede realmente a cada aplicación). Una aplicación puede tener varias: diez personas iniciando sesión a través de SSO, una cuenta de facturación compartida y una clave API que un script usa para extraer informes.

Conocer las aplicaciones que usa una empresa muestra por qué está pagando. Conocer las credenciales muestra quién puede entrar, y esa es la lista que importa para la seguridad.

Paso 1: Construya su inventario de gestión de credenciales SaaS

Comience con una lista de credenciales SaaS. Agrupe por riesgo. No «limpie» durante este paso. Limpiar a mitad del inventario crea un segundo desorden. Capture, luego mueva. Para cada aplicación SaaS y servicio interno, escriba:

• Qué herramienta es (nombre de la aplicación SaaS)
• Quién es propietario de la cuenta (persona o equipo)
• Dónde está el secreto hoy (chat, wiki, variable de CI, nota adhesiva)
• Quién lo necesita el próximo trimestre (nuevas contrataciones, proyectos o equipos)
• Qué se rompe si desaparece (flujos de trabajo dependientes, integraciones o servicios)

Ejemplo:

Una entrada como esta le dice a cualquiera exactamente a quién preguntar, dónde buscar y qué está en juego.

Paso 2: Diseñe bóvedas y carpetas que coincidan con su forma de trabajar

Una bóveda de contraseñas solo ayuda a la gestión de credenciales SaaS cuando su jerarquía de carpetas coincide con la forma en que los equipos ya buscan el acceso, no con cómo creció el antiguo sistema caótico. La centralización falla cuando el nuevo almacén simplemente reubica el desorden. Elija una jerarquía que alguien pueda explicar en una oración. Agrupe las bóvedas por departamento o producto, luego divida los secretos de infraestructura por entorno.

El anidamiento se mantiene poco profundo en la mayoría de las ramas. Dos niveles suelen ser suficientes: una bóveda para el equipo, una carpeta para la categoría de herramienta. Añada un tercer nivel solo cuando una carpeta de segundo nivel no sea uniforme por sí misma. Si una carpeta ya describe todo lo que contiene, deténgase ahí.

Ejemplo de jerarquía de datos:

Dos audiencias usan este mismo árbol de manera diferente. Los humanos navegan por nombre de equipo. Los pipelines obtienen por ID de carpeta, por eso la documentación de incorporación para DevOps recomienda carpetas por entorno primero: un trabajo puede extraer todo lo que necesita con un solo --folder-id en lugar de incorporar credenciales SaaS en el código.

Las reglas de nomenclatura ayudan más que la profundidad de anidamiento:

• Prefiera stripe-prod-dashboard sobre Nueva contraseña (2)
• Ponga el entorno en el nombre o en la carpeta, no solo en la cabeza de alguien
• Use campos personalizados para secretos que no son contraseñas (claves API, IDs de cliente) en lugar de meter todo en el campo de contraseña

La última decisión es quién ve la bóveda en absoluto. Las bóvedas corporativas son donde pertenecen las credenciales SaaS del equipo. Las bóvedas privadas son para inicios de sesión de trabajo personales que no deberían sobrevivir al empleado.

Paso 3: Migre una vez, luego elimine los almacenes paralelos

La migración de credenciales SaaS solo reduce el riesgo de gestión en la nube cuando el almacenamiento antiguo se cierra en una fecha fija. Ejecutar un canal de chat, una hoja de cálculo y un gestor de contraseñas en paralelo como fuentes de verdad competidoras simplemente recrea la dispersión que la migración se suponía debía solucionar.

Importar es mejor que volver a escribir. Passwork acepta importaciones estructuradas (JSON, CSV y formatos de exportación comunes de gestores de contraseñas). Mueva primero un departamento piloto — suficientes registros para que las personas sientan el dolor de la forma antigua, no tantos como para que un mal diseño de carpetas se vuelva permanente.

Reglas que mantienen la migración honesta:

1. Una fuente de verdad única después de la transición. El canal de Slack y la hoja de cálculo compartida de Google se convierten en archivos de solo lectura, luego se eliminan en una fecha publicada.
2. Rote las credenciales SaaS después de importar cuando el canal antiguo era compartido. Cualquier cosa que vivió en el chat está comprometida por definición. Cambiar la contraseña en la aplicación SaaS, luego actualizar la bóveda, es mejor que actualizar la bóveda primero y esperar que la aplicación todavía acepte el valor antiguo.
3. Accesos directos en lugar de copias. Si dos equipos necesitan la misma credencial SaaS, comparta el acceso o use un acceso directo en lugar de duplicar el secreto. Los duplicados divergen.

Espere dos semanas desordenadas. Eso es normal. El modo de fallo es dejar Notion y la bóveda de contraseñas ambos «oficiales» durante seis meses.

Paso 4: Controle el acceso con roles, grupos y permisos de bóveda

El almacenamiento centralizado de credenciales SaaS sin privilegio mínimo convierte una bóveda de contraseñas en un pastebin muy grande y con búsqueda. La gestión efectiva de credenciales SaaS separa lo que una persona puede hacer a la plataforma en sí de lo que puede hacer a un conjunto específico de secretos compartidos.

Passwork separa dos capas:

• Roles del sistema — lo que alguien puede hacer a la instancia (invitar usuarios, cambiar SSO, leer el registro de actividad). Los incorporados incluyen Propietario, Admin y Usuario. Los roles personalizados ilimitados permiten crear Soporte o Auditor sin entregar acceso de admin completo.
• Grupos de usuarios — lo que pueden hacer con las credenciales SaaS compartidas. Los niveles van desde Prohibido a través de Lectura, Edición y Acceso completo hasta Admin en ese recurso.

Conceda acceso a grupos, luego asigne personas a los grupos. Cuando alguien se une a Soporte, hereda el acceso a la bóveda con el grupo. Cuando se va, lo elimina una vez. LDAP/AD puede sincronizar la membresía del grupo para que los cambios del directorio fluyan a la bóveda de contraseñas en lugar de esperar un ticket.

Sea estricto con Admin en las bóvedas. La mayoría de las personas necesitan Lectura en las aplicaciones que usan. Admin es para líderes de equipo que organizan carpetas y revisan quién tiene acceso.

Paso 5: Conecte identidad, automatización y baja de empleados

Una bóveda de contraseñas utilizada solo para inicios de sesión interactivos cubre la mitad de la gestión de credenciales SaaS. La otra mitad son los secretos de máquina a máquina que los pipelines extraen en el momento de compilación o despliegue. Conectar la bóveda a SSO, LDAP/AD y una API compatible con CI la convierte en el punto de control único tanto para inicios de sesión humanos como para flujos de trabajo automatizados de gestión en la nube.

• SAML SSO para que las personas entren a la bóveda de contraseñas con el mismo IdP que usan para el resto de la pila SaaS (Azure AD, Okta, ADFS, Google Workspace y similares).
• LDAP/AD cuando el directorio es la fuente de verdad para cuentas y acceso a bóvedas basado en grupos.
• Extensión de navegador y clientes de escritorio/móvil para que el camino diario sea autocompletar, no copiar y pegar desde una pestaña web.

Para el lado de máquinas de la pila, mantenga a los humanos fuera de CI:

• Use una cuenta de servicio con una clave API (o tokens de sesión consumidos por passwork-cli), con alcance limitado a las bóvedas y carpetas que el pipeline necesita para el acceso a credenciales SaaS.
• Extraiga secretos en el momento del trabajo. No los incorpore en las imágenes.
• Rote: actualice el secreto en el sistema de destino primero, luego guarde el nuevo valor en la bóveda de contraseñas — el orden inverso crea interrupciones silenciosas.
• Revise el registro de actividad (y la exportación Syslog/CEF a SIEM si tiene uno) para copias, exportaciones y cambios de acceso.

La baja de empleados es donde esta configuración da sus frutos. Desactive la cuenta del usuario que se va, revoque sus sesiones API y confirme que ha sido eliminado de cada grupo. Si una contraseña de admin SaaS compartida vivía solo en la bóveda, rotarla es una acción, no una búsqueda en cinco bandejas de entrada para ver quién más tenía una copia.

Cómo se ve la gestión de credenciales SaaS bien hecha

La gestión de credenciales SaaS está centralizada cuando el acceso fluye a través de grupos en lugar de mensajes directos, la baja revoca el acceso a la bóveda de contraseñas en una acción, y cada búsqueda de credenciales se puede rastrear en un registro de actividad. Nada de esto necesita un programa largo — inventario, estructura y migración se ejecutan en paralelo durante unas pocas semanas.

Está centralizado cuando:

• Un nuevo empleado obtiene acceso a la bóveda a través de un grupo, no un mensaje directo con cinco contraseñas
• Un empleado que se va pierde el alcance SaaS sin una búsqueda del tesoro
• Los ingenieros pueden apuntar un pipeline a un ID de carpeta y dejar de hacer commit de archivos .env
• Seguridad puede responder «¿quién pudo ver el inicio de sesión de Stripe el mes pasado?» desde el registro de actividad

Nada de eso requiere un programa de doce meses. Inventario en una semana. Estructura y piloto en otra. Migración en oleadas. Permisos y SSO en paralelo con las oleadas. Automatización al final — después de que las carpetas existan.

Conclusión

Centralizar las credenciales SaaS solo funciona si la herramienta que las contiene impone quién es responsable de cada bóveda, mantiene los inicios de sesión humanos y las cuentas de servicio en pistas separadas, y produce un registro que puede entregar a seguridad sin reconstruirlo de memoria.

Passwork vincula esa responsabilidad a un rol que define desde el principio, no a quien por casualidad hizo clic en «crear bóveda» primero. Así que cuando la persona que configuró la bóveda de Marketing deja la empresa, la supervisión no se va con ella — se queda con el rol. Las cuentas de servicio manejan el lado de las máquinas de la misma manera: un pipeline de CI obtiene su propia identidad con alcance limitado en lugar de ejecutarse silenciosamente con el inicio de sesión personal de alguien mucho después de que esa persona haya cambiado de equipo.

Las contraseñas humanas y los secretos de máquinas terminan en la misma plataforma, bajo un solo precio. Eso es un proveedor que gestionar en lugar de dos, y un registro de actividad que revisar en lugar de juntar exportaciones de un gestor de contraseñas y una herramienta de secretos separada.

Preguntas frecuentes

Verizon DBIR 2026: 10 estadísticas que deberían cambiar su estrategia de seguridad

El DBIR 2026 de Verizon analizó más de 22.000 brechas en 145 países. La explotación de vulnerabilidades superó al abuso de credenciales como el principal vector de ataque, mientras que el ransomware, el riesgo de terceros y los ataques asistidos por IA crecieron significativamente. Aquí están los 10 números que importan.

PassworkAlex Muntyan

Políticas de bóvedas de Passwork: guía para CIOs sobre seguridad empresarial

Los Tipos de Bóvedas de Passwork vinculan los derechos de admin a la política de la bóveda en sí, no a quien la creó, cerrando una brecha que la mayoría de las empresas ni siquiera saben que existe. Esta guía proporciona a CIOs y CISOs un modelo funcional para la gobernanza de bóvedas, mapeado a los requisitos de NIS2 e ISO 27001.

PassworkPasswork Team

¿Qué es la Gestión de Acceso Privilegiado? Una guía completa

Las cuentas privilegiadas son los objetivos de mayor valor para los atacantes. Una credencial de admin comprometida da control total sobre infraestructura, datos y aplicaciones. PAM aborda esto a través del almacenamiento de credenciales, monitorización de sesiones y aplicación del privilegio mínimo. Así es como funciona en la práctica.

Passwork BlogAlex Muntyan