Product guides

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

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

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

SaaS credential management is the practice of tracking every password, shared login, and access key a company uses for cloud apps like Salesforce or Slack, and controlling who can see and use each one. It means treating every credential as inventory you can find, share on purpose, and revoke when people leave. The goal is one controlled vault for human passwords and machine secrets — not five tools that each hold a slice of the truth

Most companies use more SaaS apps than IT officially tracks: a CRM login in a browser profile, a Gmail password shared over Slack, staging database strings sitting in a private repo. Nobody centrally owns any of these logins, which means nobody is watching them either. Each one is an open entry point that could sit there for months before anyone notices it's been misused.

Passwork is built for that job: a business password and secrets manager you can run on your own servers or as a cloud service, with shared vaults, role-based access, LDAP/SSO, and a REST API for automation. The five steps below work the same way for teams already running Passwork and for teams still evaluating a system.

What counts as a SaaS credential

A SaaS credential is anything used to prove identity and get access: a password, a shared login, an API key, or a security certificate. A company's list of SaaS apps (what it pays for) is not the same as its list of credentials (how each app is actually accessed). One app can have several: ten people logging in through SSO, one shared billing account, and an API key a script uses to pull reports.

Knowing the apps a company uses shows what it's paying for. Knowing the credentials shows who can get in, and that's the list that matters for security.

Step 1: Build your SaaS credential management inventory

Start with a SaaS credential list. Group by risk. Do not "clean up" during this step. Cleaning mid-inventory creates a second mess. Capture, then move. For each SaaS app and internal service, write:

• Which tool this is (SaaS app name)
• Who owns the account (person or team)
• Where the secret sits today (chat, wiki, CI variable, sticky note)
• Who needs it next quarter (upcoming hires, projects, or teams)
• What breaks if it disappears (dependent workflows, integrations, or services)

Example:

One entry like this tells anyone exactly who to ask, where to look, and what's at stake.

Step 2: Design vaults and folders that match how you work

A password vault only helps SaaS credential management when its folder hierarchy matches how teams already search for access, not how the old, chaotic system grew. Centralization fails when the new store just relocates the mess. Pick a hierarchy someone can explain in one sentence. Group vaults by department or product, then split infrastructure secrets by environment.

Nesting stays shallow in most branches. Two levels are usually enough: a vault for the team, a folder for the tool category. Add a third level only when a second-level folder isn't uniform on its own. If a folder already describes everything inside it, stop there.

Data hierarchy example:

Two audiences use this same tree differently. Humans browse by team name. Pipelines fetch by folder ID, which is why onboarding docs for DevOps recommend environment-first folders: a job can pull everything it needs with one --folder-id instead of stitching SaaS credentials into code.

Naming rules help more than nested depth:

• Prefer stripe-prod-dashboard over New password (2)
• Put the environment in the name or the folder, not only in someone's head
• Use custom fields for non-password secrets (API keys, client IDs) instead of stuffing everything into the password field

The last decision is who sees the vault at all. Corporate vaults are where team SaaS credentials belong. Private vaults are for personal work logins that should not outlive the employee.

Step 3: Migrate once, then delete the parallel stores

SaaS credential migration only reduces cloud management risk when the old storage gets shut down on a fixed date. Running a chat channel, a spreadsheet, and a password manager side by side as competing sources of truth just recreates the sprawl the migration was supposed to fix.

Import beats retyping. Passwork accepts structured imports (JSON, CSV and common password-manager export formats). Move a pilot department first — enough records that people feel the pain of the old way, not so many that a bad folder design becomes permanent.

Rules that keep migration honest:

1. One source of truth after cutover. The Slack channel and the shared Google Sheet become read-only archives, then get deleted on a published date.
2. Rotate SaaS credentials after import when the old channel was shared. Anything that lived in chat is compromised by definition. Changing the password in the SaaS app, then updating the vault, beats updating the vault first and hoping the app still accepts the old value.
3. Shortcuts instead of copies. If two teams need the same SaaS credential, share access or use a shortcut rather than duplicating the secret. Duplicates drift.

Expect a messy two weeks. That is normal. The failure mode is leaving Notion and the password vault both "official" for six months.

Step 4: Gate access with roles, groups, and vault permissions

Central SaaS credential storage without least privilege turns a password vault into a very large, searchable pastebin. Effective SaaS credential management separates what a person can do to the platform itself from what they can do to a specific set of shared secrets.

Passwork separates two layers:

• System roles — what someone can do to the instance (invite users, change SSO, read the activity log). Built-ins include Owner, Admin, and User. Unlimited custom roles let you carve out Support or Auditor without handing out full admin.
• User groups — what they can do to shared SaaS credentials. Levels run from Forbidden through Read, Edit, and Full access up to Admin on that resource.

Grant access to groups, then map people into groups. When someone joins Support, they inherit vault access with the group. When they leave, you remove them once. LDAP/AD can sync group membership so directory changes flow into the password vault instead of waiting on a ticket.

Be strict with Admin on vaults. Most people need Read on the apps they use. Admin is for team leads who organize folders and review who has access.

Step 5: Connect identity, automation, and offboarding

A password vault used only for interactive logins covers half of SaaS credential management. The other half is the machine-to-machine secrets pipelines pull at build or deploy time. Wiring the vault to SSO, LDAP/AD, and a CI-friendly API turns it into the single control point for both human logins and automated cloud management workflows.

• SAML SSO so people enter the password vault with the same IdP they use for the rest of the SaaS stack (Azure AD, Okta, ADFS, Google Workspace, and similar).
• LDAP/AD when the directory is the source of truth for accounts and group-based vault access.
• Browser extension and desktop/mobile clients so the daily path is autofill, not copy-paste from a web tab.

For the machine side of the stack, keep humans out of CI:

• Use a service account with an API key (or session tokens consumed by passwork-cli), scoped to the vaults and folders the pipeline needs for SaaS credential access.
• Pull secrets at job time. Do not bake them into images.
• Rotate: update the secret in the target system first, then save the new value in the password vault — the reverse order creates silent outages.
• Review the activity log (and Syslog/CEF export to SIEM if you have one) for copies, exports, and access changes.

Offboarding is where this setup pays off. Disable the departing user's account, revoke their API sessions, and confirm they're removed from every group. If a shared SaaS admin password lived only in the vault, rotating it is one action, not a search through five inboxes to see who else had a copy.

What SaaS credential management done right looks like

SaaS credential management is centralized when access flows through groups instead of DMs, offboarding revokes password vault access in one action, and every credential lookup can be traced in an activity log. None of this needs a long program — inventory, structure, and migration run in parallel over a few weeks.

You are centralized when:

• A new hire gets vault access through a group, not a DM with five passwords
• A departing hire loses SaaS reach without a scavenger hunt
• Engineers can point a pipeline at a folder ID and stop committing .env files
• Security can answer "who could see the Stripe login last month?" from the activity log

None of that requires a twelve-month program. Inventory in a week. Structure and pilot in another. Migrate in waves. Permissions and SSO in parallel with the waves. Automation last — after the folders exist.

Conclusion

Centralizing SaaS credentials only works if the tool holding them enforces who's accountable for each vault, keeps human logins and service accounts on separate tracks, and produces a record you can hand to security without reconstructing it from memory.

Passwork ties that accountability to a role you define upfront, not to whoever happened to click "create vault" first. So when the person who set up the Marketing vault leaves the company, oversight doesn't leave with them — it stays with the role. Service accounts handle the machine side the same way: a CI pipeline gets its own scoped identity instead of quietly running on someone's personal login long after that person has moved teams.

Human passwords and machine secrets end up on the same platform, under one price. That's one vendor to manage instead of two, and one activity log to check instead of piecing together exports from a password manager and a separate secrets tool.

Frequently asked questions

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

What is Privileged Access Management? A Complete Guide

Privileged accounts are the highest-value targets for attackers. One compromised admin credential gives full control over infrastructure, data, and applications. PAM addresses this through credential vaulting, session monitoring, and least privilege enforcement. Here’s how it works in practice.

Passwork BlogAlex Muntyan

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

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

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

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

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

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

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

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

Controles de administrador, visibilidad y seguimiento de riesgos

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

Permisos basados en roles

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

Registro de auditoría completo

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

Información a nivel de dispositivo

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

Seguimiento de exposición

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

Política desactivada por defecto

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

Aspectos esenciales del modo sin conexión

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

Limitaciones del modo sin conexión

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

Controles de archivos adjuntos

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

Mejoras en búsqueda y navegación

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

Aplicaciones de escritorio y móviles

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

Nuevo: Guías de incorporación

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

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

Passwork gana Top Performer Verano 2026 en SourceForge

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

PassworkPasswork Team

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

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

PassworkPasswork Team

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

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

PassworkAlex Muntyan

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

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

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

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

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

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

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

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

Admin-Steuerung, Transparenz und Risikoverfolgung

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

Rollenbasierte Berechtigungen

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

Vollständiger Audit-Trail

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

Geräteebenen-Einblick

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

Expositionsverfolgung

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

Standardmäßig deaktiviert

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

Offline-Grundlagen

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

Offline-Einschränkungen

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

Dateianhang-Steuerung

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

Such- und Navigationsverbesserungen

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

Desktop- und mobile Apps

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

Neu: Onboarding-Anleitungen

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

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

Passwork gewinnt Top Performer Sommer 2026 auf SourceForge

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

PassworkPasswork Team

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

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

PassworkPasswork Team

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

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

PassworkAlex Muntyan

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

Secure offline access for desktop and mobile apps

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

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

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

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

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

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

Admin controls, visibility, and risk tracking

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

Role-based permissions

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

Full audit trail

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

Device-level insight

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

Exposure tracking

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

Default-off policy

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

Offline essentials

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

Offline limitations

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

File attachment controls

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

Search and navigation improvements

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

Desktop and mobile apps

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

New: Onboarding guides

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

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

Passwork wins Top Performer Summer 2026 on SourceForge

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

PassworkPasswork Team

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

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

PassworkPasswork Team

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

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

PassworkAlex Muntyan

Tresor-Richtlinien in Passwork (auch als Tresortypen bezeichnet): eine konfigurierbare Governance-Ebene, mit der Administratoren für jede Kategorie von Tresoren festlegen können, wer die permanenten Administratoren sind, welches Zugangslevel die Ersteller des Tresors erhalten und wer Tresore dieses Typs erstellen darf. Einmal festgelegt, gelten diese Regeln automatisch für jeden Tresor, der unter diesem Typ erstellt wird.

Die meisten Unternehmen können nicht mit Sicherheit sagen, wer Administratorrechte über den gemeinsamen Anmeldedaten-Tresor eines bestimmten Teams hat, da Admin-Zugriff informell gewährt wird, ohne eine zugrundeliegende Richtlinie. Enterprise-Passwort-Tresor-Richtlinien beheben dies, indem sie Admin-Rechte an die Tresor-Richtlinie selbst binden und nicht an denjenigen, der den Tresor zufällig erstellt hat.

Dieser Leitfaden erklärt, wie die Tresortypen-Architektur von Passwork CIOs und CISOs ein funktionierendes Modell für Tresor-Governance bietet, das über einfache Passwortregeln hinausgeht.

Was sind Tresor-Richtlinien und warum CIOs sie benötigen

Tresor-Richtlinien sind Governance-Regeln, die festlegen, wer einen Tresor erstellen kann, wer automatisch Administratorzugriff erhält und wer nicht von diesem Zugriff entfernt werden kann. Sie verlagern das Gespräch von „Passwort-Komplexitätsanforderungen" zu Tresor-Governance: strukturelle Kontrolle über die Speicherung von Unternehmensanmeldedaten, nicht nur über die Anmeldedaten selbst.

Drei Kategorien von Tools beanspruchen, dieses Problem zu lösen: 

• Consumer-Passwortmanager handhaben die gemeinsame Nutzung von Anmeldedaten für Einzelpersonen oder kleine Teams gut, wurden aber nicht für abteilungsübergreifende Governance im großen Maßstab entwickelt. 
• Privileged Access Management (PAM)-Plattformen sichern Infrastruktur- und Dienstkonten ab, verursachen aber Kosten und Komplexität, die die meisten Anwendungsfälle für die gemeinsame Nutzung von Anmeldedaten nicht benötigen. 
• Enterprise-Passwortmanager mit dedizierten Tresor-Richtlinien-Engines befinden sich zwischen beiden — und dieser Ansatz ist der Fokus dieses Artikels.

Handlungsempfehlung für CIOs: Führen Sie in Ihrer Organisation ein Audit nach „Schatten-Tresoren" durch — gemeinsame Ordner oder Team-Tresore, die ohne Wissen der IT erstellt wurden, oft innerhalb eines Consumer-Tools, das eine einzelne Abteilung eigenständig eingeführt hat.

Die Architektur hinter Tresor-Richtlinien: Wie Passwork die Zugangskontrolle strukturiert

Passwork 7.1 führte eine Tresortypen-Architektur ein, bei der jede Tresor-Richtlinie ihre eigenen Administratoren, Ersteller-Berechtigungen und Erstellungsregeln definiert, bevor ein einziger Tresor existiert. Jeder neue Tresor, der unter dieser Richtlinie erstellt wird, erbt automatisch die zugewiesenen Administratoren, und der Besitzer des Tresors kann diese nicht entfernen.

Zwei grundlegende Tresortypen werden standardmäßig mitgeliefert: Benutzer-Tresore, private oder gemeinsame Anmeldedatenspeicher, die vollständig von ihrem Ersteller kontrolliert werden, und Unternehmens-Tresore, die immer die Unternehmensadministratoren der Organisation einschließen. Darüber hinaus können Administratoren unbegrenzt viele benutzerdefinierte Tresortypen erstellen — einen pro Abteilung, Projekt oder Zugangsstufe — jeweils mit eigenen zugewiesenen Administratoren und Erstellungsregeln.

Dies führt zu drei konkreten Ergebnissen für das Unternehmen:

• Kontrolle über Team-Tresore ohne einen einzelnen Super-Administrator, der einen Masterschlüssel zu jedem Passwort im Unternehmen besitzt.
• Ein Wiederherstellungspfad, der funktioniert, wenn jemand das Unternehmen verlässt oder den Zugriff verliert, durch ein vorab bereitgestelltes Wiederherstellungskonto, dessen Masterpasswort offline gespeichert ist.
• Kein obligatorischer „Ein-Knopf"- oder Masterschlüssel, der alle Anmeldedaten der gesamten Organisation auf einmal entsperrt.

Version 7.4 fügte Einschränkungskontrollen speziell für Benutzer-Tresore hinzu, mit denen Administratoren auch auf der Ebene der persönlichen Tresore Freigabe- und Erstellungsberechtigungen einschränken können. Dies schließt eine Lücke, die die grundlegenden Tresortypen allein nicht abdeckten.

Handlungsempfehlung für CIOs: Ordnen Sie Ihre Organisationsstruktur den Tresortypen zu — einen pro Abteilung oder Projekt — und weisen Sie Unternehmensadministratoren zu, bevor Teams beginnen, eigenständig Tresore zu erstellen.

Wie Passwork im Vergleich zu anderen Ansätzen zur Tresor-Zugangskontrolle abschneidet

Für jedes Tool zur Verwaltung von Anmeldedaten ist entscheidend, ob die Admin-Rolle vorab an eine Richtlinie gebunden ist und ob die Wiederherstellung des Zugriffs einen Schlüssel erfordert, der gleichzeitig alles andere in der Organisation öffnet. In der folgenden Tabelle ist „Nein" in der Spalte „Einzelner Schlüssel" die gewünschte Antwort: Es bedeutet, dass es keinen eingebauten Single Point of Failure gibt.

Consumer-orientierte Passwortmanager erlauben es Team-Admins oft, einen gemeinsamen Tresor zu verwalten, wenden diese Richtlinie aber selten automatisch auf jeden neuen Tresor an, den eine Abteilung erstellt. 

Einige Tools setzen auf einen einzelnen Super-Admin, der das Passwort jedes Benutzers zurücksetzen und auf jeden gemeinsamen Ordner im Unternehmen zugreifen kann. Andere binden alle Unternehmens-Tresore an einen einzigen gemeinsamen Verschlüsselungsschlüssel, sodass die Kompromittierung dieses Schlüssels alles auf einmal offenlegt. 

PAM-Plattformen lösen ein anderes Problem: Sie sichern privilegierte Infrastruktur-Anmeldedaten, oft hinter einem eigenen Master- oder Breakglass-Schlüssel, anstatt die Passwort-Freigabe auf Teamebene zu regeln.

Handlungsempfehlung für CIOs: Bewerten Sie Ihr aktuelles Anmeldedaten-Tool anhand dieser drei Kriterien: richtliniengebundene Admin-Zuweisung, ein funktionierender Wiederherstellungspfad und das Fehlen eines obligatorischen universellen Schlüssels.

Die 5-Punkte-Tresor-Governance-Checkliste, die jeder CIO umsetzen sollte

Fünf spezifische Konfigurationsentscheidungen verwandeln die Bereitstellung eines Passwortmanagers in funktionierende Tresor-Governance. Jede adressiert einen bestimmten Fehlermodus, der bei echten Incident-Response-Einsätzen beobachtet wurde — kein theoretisches Risiko.

• Deaktivieren Sie die Erstellung und Freigabe privater Tresore, wo sie nicht benötigt wird. Uneingeschränkte private Tresore sind genau der Weg, wie Schatten-Tresore außerhalb der Sichtbarkeit der IT entstehen. Beschränken Sie die Erstellung privater Tresore auf Rollen, die sie wirklich benötigen.
• Weisen Sie jeder Team- und Abteilungs-Tresor-Richtlinie Unternehmensadministratoren zu. Dies garantiert eine kontinuierliche Aufsicht, ohne davon abhängig zu sein, dass sich jemand daran erinnert, sich selbst hinzuzufügen.
• Definieren Sie eine Notfallzugriffsrichtlinie, bevor Sie sie benötigen. Entscheiden Sie sich zwischen einem einzigen organisationsweiten Wiederherstellungsbereich oder separaten Wiederherstellungskonten pro Abteilung und speichern Sie die Master-Anmeldedaten für dieses Wiederherstellungskonto offline.
• Implementieren Sie RBAC (rollenbasierte Zugangskontrolle) über Active Directory oder LDAP. Die automatische Synchronisierung von Gruppen und Rollen wendet das Prinzip der minimalen Rechtevergabe an und eliminiert manuelle Bereitstellungsfehler, wenn Mitarbeiter ihre Rollen wechseln.
• Richten Sie Passwortlänge und Rotationsregeln an den aktuellen NIST-Richtlinien aus. NIST SP 800-63B Rev. 4 (2025) setzt ein Minimum von 15 Zeichen für Passwörter fest, die als einziger Authentifizierungsfaktor verwendet werden, und schafft die obligatorische 90-Tage-Rotationsanforderung offiziell ab (NIST SP 800-63B, 2025) [exakte Veröffentlichungs-URL vor dem Druck überprüfen]. Erzwungene Rotation ohne Hinweise auf eine Kompromittierung führt dazu, dass Benutzer vorhersehbare, inkrementierte Passwörter verwenden — genau das Ergebnis, das die Richtlinie jetzt unterbinden soll.

Handlungsempfehlung für CIOs: Führen Sie in diesem Quartal ein Gap-Audit gegen alle fünf Richtlinien durch und weisen Sie für jede Feststellung einen Verantwortlichen zu, anstatt das Audit als einmaligen Bericht zu behandeln.

Erfüllung von NIS2- und ISO 27001-Anforderungen mit Tresor-Governance

Tresor-Richtlinien ordnen sich direkt zwei Anforderungen zu, die Prüfer zuerst überprüfen: dokumentierte Zugangskontrolle und ein überprüfbarer Audit-Trail. Die NIS2-Richtlinie (EU) 2022/2555, Artikel 21(2), verlangt Zugangskontrollrichtlinien und Multi-Faktor-Authentifizierung als Teil der Cybersicherheits-Risikomanagementmaßnahmen einer Einrichtung. Die Kontrollen 5.15 und 8.15 von ISO/IEC 27001:2022 erfordern dieselbe Kombination: ein definiertes Zugangsmodell plus einen Nachweis darüber, wer es wann genutzt hat.

An eine Tresor-Richtlinie gebundene Unternehmensadministratoren decken die Zugangskontrollseite ab, ohne eine manuelle Tabelle zu erfordern. Zeitgestempelte, exportierbare Audit-Logs decken den Rest ab.

Verizons 2026 DBIR stellte fest, dass Anmeldedaten in irgendeiner Phase bei 39 % der Sicherheitsverletzungen eine Rolle spielten, in 13 % der bestätigten Sicherheitsverletzungen der initiale Zugriffsvektor waren und der führende Vektor bei 52 % der Basic Web Application Attacks. IBMs 2026 Cost of a Data Breach Report beziffert die globalen durchschnittlichen Kosten einer Sicherheitsverletzung auf 4,99 Millionen US-Dollar — ein Anstieg von 12 % gegenüber dem Vorjahr und ein Rekordhoch.

Handlungsempfehlung für CIOs: Fordern Sie diesen Monat von Ihrem Sicherheitsteam einen aktuellen NIS2-Zugangskontroll-Abdeckungsbericht an — bevor ein Prüfer zuerst danach fragt.

Was das für Ihren Rollout bedeutet

Tresor-Governance ist eine strukturelle Entscheidung, die genauso getroffen wird wie Netzwerksegmentierung: Sie wird um Abteilungen und Risikostufen herum entworfen, bevor ein Vorfall eine Neugestaltung erzwingt. Die Organisationen, die dies richtig machen, behandeln es von Anfang an so. Unter NIS2 und DSGVO ist diese Struktur nun eine Anforderung für Unternehmen im Geltungsbereich.

Beginnen Sie mit dem Audit, nicht mit dem Tool. Erfassen Sie, welche Tresore heute existieren, wer sie tatsächlich kontrolliert und wo der Wiederherstellungspfad unterbrochen wird, wenn eine Person das Unternehmen verlässt.

Häufig gestellte Fragen

Las políticas de bóvedas de Passwork (también llamadas Tipos de Bóveda): una capa de gobernanza configurable que permite a los administradores definir, para cada categoría de bóveda, quiénes son sus administradores permanentes, qué nivel de acceso obtienen los creadores de bóvedas y quién tiene permitido crear bóvedas de ese tipo. Una vez establecidas, estas reglas se aplican automáticamente a cada bóveda creada bajo ese tipo.

La mayoría de las empresas no pueden afirmar con certeza quién tiene derechos de administrador sobre la bóveda de credenciales compartidas de un equipo determinado, porque el acceso de administrador se otorga de manera informal, sin una política detrás. Las políticas de bóvedas de contraseñas empresariales solucionan esto vinculando los derechos de administrador a la política de la bóveda en sí, no a quien la creó.

Esta guía explica cómo la arquitectura de Tipos de Bóveda de Passwork proporciona a los CIO y CISO un modelo funcional para la gobernanza de bóvedas, más allá de las reglas básicas de contraseñas.

Qué son las políticas de bóvedas y por qué los CIO las necesitan

Las políticas de bóvedas son reglas de gobernanza que determinan quién puede crear una bóveda, quién obtiene automáticamente acceso de administrador a ella y quién no puede ser removido de ese acceso. Cambian la conversación de «requisitos de complejidad de contraseñas» a gobernanza de bóvedas: control estructural sobre el almacenamiento de credenciales corporativas, no solo sobre las credenciales en sí.

Tres categorías de herramientas afirman resolver esto: 

• Los gestores de contraseñas de consumo manejan bien el intercambio de credenciales personales o de equipos pequeños, pero no fueron diseñados para la gobernanza departamental a escala. 
• Las plataformas de gestión de acceso privilegiado (PAM) aseguran cuentas de servicio y de nivel de infraestructura, pero añaden costos y complejidad que la mayoría de los casos de uso de intercambio de credenciales no necesitan. 
• Los gestores de contraseñas empresariales con motores de políticas de bóvedas dedicados se sitúan entre ambos, y ese es el enfoque en el que se centra este artículo.

Acción para el CIO: Audite su organización en busca de «bóvedas no autorizadas» — carpetas compartidas o bóvedas de equipo creadas sin conocimiento de TI, a menudo dentro de una herramienta de consumo que un departamento individual adoptó de forma independiente.

La arquitectura detrás de las políticas de bóvedas: cómo Passwork estructura el control de acceso

Passwork 7.1 introdujo una arquitectura de tipos de bóveda donde cada política de bóveda define sus propios administradores, permisos del creador y reglas de creación antes de que exista una sola bóveda. Cada nueva bóveda construida bajo esa política hereda automáticamente sus administradores designados, y el propietario de la bóveda no puede eliminarlos.

Dos tipos de bóveda básicos vienen por defecto: Bóvedas de usuario, almacenes de credenciales privados o compartidos controlados completamente por su creador, y Bóvedas de empresa, que siempre incluyen a los administradores corporativos de la organización. Más allá de estos, los administradores pueden crear tipos de bóveda personalizados ilimitados, uno por departamento, proyecto o nivel de acceso, cada uno con sus propios administradores designados y reglas de creación.

Esto produce tres resultados concretos para el negocio:

• Control sobre las bóvedas de equipo sin un único superadministrador que posea una clave maestra para todas las contraseñas de la empresa.
• Una ruta de recuperación que funciona cuando alguien se va o pierde acceso, a través de una cuenta de recuperación preaprovisionada cuya contraseña maestra se almacena fuera de línea.
• Sin «un botón» obligatorio ni clave maestra que desbloquee todas las credenciales de la organización a la vez.

La versión 7.4 añadió controles de restricción específicamente para Bóvedas de usuario, permitiendo a los administradores limitar los permisos de compartir y creación también en el nivel de bóveda personal, cerrando una brecha que los tipos de bóveda básicos por sí solos no cubrían.

Acción para el CIO: Mapee su estructura organizacional a tipos de bóveda, uno por departamento o proyecto, y asigne administradores corporativos antes de que los equipos comiencen a crear bóvedas por su cuenta.

Cómo se compara Passwork con otros enfoques de control de acceso a bóvedas

Lo que importa para cualquier herramienta de gestión de credenciales es si el rol de administrador está vinculado a una política de antemano, y si recuperar el acceso requiere una clave que también abre todo lo demás en la organización. En la tabla siguiente, «No» en la columna de clave única es la respuesta deseada: significa que no hay un único punto de fallo incorporado.

Los gestores de contraseñas orientados al consumidor a menudo permiten que los administradores de equipo gestionen una bóveda compartida, pero rara vez aplican esa política automáticamente a cada nueva bóveda que crea un departamento. 

Algunas herramientas dependen de un único superadministrador que puede restablecer la contraseña de cualquier usuario y acceder a cada carpeta compartida en la empresa. Otras vinculan todas las bóvedas corporativas a una única clave de cifrado compartida, de modo que comprometer esa clave expone todo a la vez. 

Las plataformas PAM resuelven un problema diferente: almacenan credenciales privilegiadas de infraestructura, a menudo detrás de su propia clave maestra o de emergencia, en lugar de gobernar el intercambio de contraseñas a nivel de equipo.

Acción para el CIO: Evalúe su herramienta de credenciales actual contra estos tres criterios: asignación de administradores vinculada a políticas, una ruta de recuperación funcional y la ausencia de una clave universal obligatoria.

La lista de verificación de 5 políticas de gobernanza de bóvedas que todo CIO debería implementar

Cinco decisiones de configuración específicas convierten una implementación de gestor de contraseñas en gobernanza de bóvedas funcional. Cada una aborda un modo de fallo distinto observado en compromisos reales de respuesta a incidentes, no un riesgo teórico.

• Desactive la creación y el intercambio de bóvedas privadas donde no sea necesario. Las bóvedas privadas sin restricciones son exactamente cómo se forman las bóvedas no autorizadas fuera de la visibilidad de TI. Restrinja la creación de bóvedas privadas a los roles que realmente lo necesiten.
• Asigne administradores corporativos a cada política de bóveda de equipo y departamental. Esto garantiza supervisión continua sin depender de que ningún individuo recuerde añadirse a sí mismo.
• Defina una política de acceso de emergencia antes de necesitarla. Decida entre un contorno de recuperación único para toda la organización o cuentas de recuperación separadas por departamento, y almacene las credenciales maestras de esa cuenta de recuperación fuera de línea.
• Implemente RBAC (control de acceso basado en roles) a través de Active Directory o LDAP. La sincronización de grupos y roles aplica automáticamente el principio de mínimo privilegio y elimina errores de aprovisionamiento manual cuando el personal cambia de rol.
• Alinee las reglas de longitud y rotación de contraseñas con la guía NIST actual. NIST SP 800-63B Rev. 4 (2025) establece un mínimo de 15 caracteres para contraseñas usadas como único factor de autenticación y retira formalmente el requisito de rotación obligatoria cada 90 días (NIST SP 800-63B, 2025) [verificar URL de publicación exacta antes de imprimir]. La rotación forzada sin evidencia de compromiso empuja a los usuarios hacia contraseñas predecibles e incrementadas, que es precisamente el resultado que la guía ahora desaconseja.

Acción para el CIO: Realice una auditoría de brechas contra las cinco políticas este trimestre, y asigne un responsable para cada hallazgo en lugar de tratar la auditoría como un informe único.

Cumplimiento de los requisitos de NIS2 e ISO 27001 con gobernanza de bóvedas

Las políticas de bóvedas se mapean directamente a dos requisitos que los auditores verifican primero: control de acceso documentado y una pista de auditoría verificable. La Directiva NIS2 (UE) 2022/2555, Artículo 21(2), requiere políticas de control de acceso y autenticación multifactor como parte de las medidas de gestión de riesgos de ciberseguridad de una entidad. Los controles 5.15 y 8.15 de ISO/IEC 27001:2022 requieren la misma combinación: un modelo de acceso definido más un registro de quién lo ejerció y cuándo.

Los administradores corporativos vinculados a una política de bóveda cubren el lado del control de acceso sin una hoja de cálculo manual. Los registros de auditoría con marca de tiempo y exportables cubren el resto.

El DBIR 2026 de Verizon encontró credenciales presentes en alguna etapa del 39% de las brechas, como vector de acceso inicial en el 13% de las brechas confirmadas, y como vector principal detrás del 52% de los Ataques Básicos a Aplicaciones Web. El informe Cost of a Data Breach 2026 de IBM sitúa el costo promedio global de una brecha en $4,99 millones, un aumento del 12% respecto al año pasado y un máximo histórico.

Acción para el CIO: Solicite a su equipo de seguridad un informe actual de cobertura de control de acceso NIS2 este mes, antes de que un auditor lo solicite primero.

Qué significa esto para su implementación

La gobernanza de bóvedas es una decisión estructural, tomada de la misma manera que la segmentación de red: diseñada en torno a departamentos y niveles de riesgo antes de que un incidente fuerce un rediseño. Las organizaciones que hacen esto bien lo tratan así desde el principio. Bajo NIS2 y GDPR, esa estructura es ahora un requisito para las empresas dentro del alcance.

Comience con la auditoría, no con la herramienta. Mapee qué bóvedas existen hoy, quién las controla realmente y dónde se rompe la ruta de recuperación si una persona se va.

Preguntas frecuentes

Passwork's vault policies (also called Vault Types): a configurable governance layer that lets administrators define, for each category of vault, who its permanent administrators are, what access level vault creators get, and who is allowed to create vaults of that type. Once set, these rules apply automatically to every vault created under that type.

Most enterprises can't say with certainty who has administrator rights over a given team's shared credential vault, because admin access gets granted informally, without a policy behind it. Enterprise password vault policies fix this by binding admin rights to the vault's policy itself, not to whoever happened to create it.

This guide explains how Passwork's Vault Types architecture gives CIOs and CISOs a working model for vault governance, beyond basic password rules.

What are vault policies and why CIOs need them

Vault policies are governance rules that determine who can create a vault, who is automatically granted administrator access to it, and who cannot be removed from that access. They shift the conversation from "password complexity requirements" to vault governance: structural control over corporate credential storage, not just the credentials themselves.

Three categories of tools claim to solve this: 

• Consumer password managers handle personal or small-team credential sharing well but were not built for departmental governance at scale. 
• Privileged access management (PAM) platforms secure infrastructure-level and service accounts but add cost and complexity that most credential-sharing use cases don't need. 
• Enterprise password managers with dedicated vault policy engines sit between the two, and that's the approach this article focuses on.

CIO action item: Audit your organization for "rogue vaults" — shared folders or team vaults created without IT's knowledge, often inside a consumer tool an individual department adopted independently.

The architecture behind vault policies: how Passwork structures access control

Passwork 7.1 introduced a vault types architecture where each vault policy defines its own administrators, creator permissions, and creation rules before a single vault exists. Every new vault built under that policy automatically inherits its designated administrators, and the vault's owner cannot remove them.

Two basic vault types ship by default: User vaults, private or shared credential stores controlled entirely by their creator, and Company vaults, which always include the organization's corporate administrators. Beyond these, administrators can create unlimited custom vault types, one per department, project, or access tier, each with its own designated administrators and creation rules.

This produces three concrete outcomes for the business:

• Command over team vaults without a single super-administrator holding a master key to every password in the company.
• A recovery path that works when someone leaves or loses access, through a pre-provisioned recovery account whose master password is stored offline.
• No mandatory "one button" or master key that unlocks the entire organization's credentials at once.

Version 7.4 added restriction controls specifically for User vaults, letting administrators limit sharing and creation permissions on the personal-vault tier too, closing a gap that basic vault types alone didn't cover.

CIO action item: Map your organizational structure to vault types, one per department or project, and assign corporate administrators before teams start creating vaults on their own.

How Passwork compares to other approaches to vault access control

What matters for any credential management tool is whether the admin role is bound to a policy in advance, and whether recovering access requires a key that also opens everything else in the organization. In the table below, "No" in the single-key column is the answer you want: it means there's no built-in single point of failure.

Consumer-oriented password managers often let team admins manage a shared vault, but rarely apply that policy automatically to every new vault a department creates. 

Some tools rely on a single super admin who can reset any user's password and reach every shared folder in the company. Others tie all corporate vaults to one shared encryption key, so compromising that key exposes everything at once. 

PAM platforms solve a different problem: they vault privileged infrastructure credentials, often behind their own master or breakglass key, rather than governing team-level password sharing.

CIO action item: Score your current credential tool against these three criteria: policy-bound admin assignment, a working recovery path, and the absence of a mandatory universal key.

The 5-policy vault governance checklist every CIO should implement

Five specific configuration decisions turn a password manager deployment into functioning vault governance. Each addresses a distinct failure mode observed in real incident response engagements, not a theoretical risk.

• Disable private vault creation and sharing where it isn't required. Unrestricted private vaults are exactly how rogue vaults form outside IT's visibility. Restrict private vault creation to roles that genuinely need it.
• Assign corporate administrators to every team and departmental vault policy. This guarantees continuous oversight without depending on any single individual remembering to add themselves.
• Define an emergency access policy before you need one. Decide between a single organization-wide recovery contour or separate recovery accounts per department, and store master credentials for that recovery account offline.
• Implement RBAC (role-based access control) through Active Directory or LDAP. Syncing groups and roles automatically applies the principle of least privilege and removes manual provisioning errors when staff change roles.
• Align password length and rotation rules with current NIST guidance. NIST SP 800-63B Rev. 4 (2025) sets a 15-character minimum for passwords used as the sole authentication factor and formally retires the mandatory 90-day rotation requirement (NIST SP 800-63B, 2025) [verify exact publication URL before print]. Forced rotation without evidence of compromise pushes users toward predictable, incremented passwords, which is precisely the outcome the guidance now discourages.

CIO action item: Run a gap audit against all five policies this quarter, and assign an owner for each finding rather than treating the audit as a one-time report.

Meeting NIS2 and ISO 27001 requirements with vault governance

Vault policies map directly onto two requirements auditors check first: documented access control and a verifiable audit trail. NIS2 Directive (EU) 2022/2555, Article 21(2), requires access control policies and multi-factor authentication as part of an entity's cybersecurity risk-management measures. ISO/IEC 27001:2022 controls 5.15 and 8.15 require the same pairing: a defined access model plus a record of who exercised it and when.

Corporate administrators bound to a vault policy cover the access-control side without a manual spreadsheet. Timestamped, exportable audit logs cover the rest.

Verizon's 2026 DBIR found credentials present at some stage of 39% of breaches, as the initial access vector in 13% of confirmed breaches, and the lead vector behind 52% of Basic Web Application Attacks. IBM's 2026 Cost of a Data Breach Report puts the global average breach cost at $4.99 million, a 12% increase over last year and a record high.

CIO action item: Ask your security team for a current NIS2 access-control coverage report this month, before an auditor asks for it first.

What this means for your rollout

Vault governance is a structural decision, made the way network segmentation is: designed around departments and risk tiers before an incident forces a redesign. The organizations that get this right treat it that way from the start. Under NIS2 and GDPR, that structure is now a requirement for enterprises in scope.

Start with the audit, not the tool. Map which vaults exist today, who actually controls them, and where the recovery path breaks if one person leaves.

Frequently asked questions

Passwork 7.7: Secure offline mode for desktop and mobile apps

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

Passwork BlogPasswork Team

Verizon DBIR 2026: 10 stats that should change your security strategy

Verizon’s 2026 DBIR analyzed 22,000+ breaches across 145 countries. Vulnerability exploitation overtook credential abuse as the top attack vector, while ransomware, third-party risk, and AI-assisted attacks all grew sharply. Here are the 10 numbers that matter.

Passwork BlogAlex Muntyan

NIS2 password requirements: What European companies must do in 2026

Credential gaps are the leading NIS2 audit failure point in 2026. This guide covers Article 21 password requirements, NIST SP 800-63B alignment, AD hardening steps, and the audit evidence regulators ask for first.

Passwork BlogAlex Muntyan

Tresortypen

Passwork 7.1 führt eine robuste Tresortypen-Architektur ein, die unternehmensgerechte Zugangskontrolle für verbesserte Sicherheit und Verwaltung bietet. Tresortypen adressieren eine zentrale Herausforderung für Administratoren: die Kontrolle des Datenzugriffs und die Delegation der Tresorverwaltung in großen Organisationen. Bisher war die Auswahl auf zwei Typen beschränkt. Jetzt können Sie benutzerdefinierte Tresortypen erstellen, die auf jede Aufgabe oder Organisationsstruktur zugeschnitten sind.

Für jede Abteilung oder jedes Projekt können Sie einen dedizierten Tresortyp erstellen, spezifische Administratoren zuweisen, Ersteller-Berechtigungen festlegen und definieren, wer Tresore dieses Typs erstellen darf.

Beispielsweise können Sie separate Tresore für die IT-Abteilung, Finanzen, Personalwesen oder temporäre Projektteams erstellen. Administratoren, die einem bestimmten Tresortyp zugewiesen sind, werden automatisch zu allen neuen Tresoren dieses Typs hinzugefügt, was kontinuierliche Kontrolle und Transparenz gewährleistet.

Was sind Tresortypen

Tresortypen ermöglichen es Administratoren, Tresorvorlagen mit vordefinierten Zugriffsverwaltungseinstellungen zu erstellen. Für jeden Tresortyp können Sie spezifische Administratoren bestimmen, Ersteller-Berechtigungen konfigurieren und Regeln oder Einschränkungen für die Erstellung neuer Tresore festlegen.

Sie können Tresore nach Abteilung, Projekt oder Zugangslevel organisieren und so sicherstellen, dass Berechtigungen präzise zugewiesen werden

Wenn ein Tresor erstellt wird, erhalten die in den Tresortyp-Einstellungen angegebenen Administratoren automatisch Zugriff. Diese Administratoren können nicht entfernt oder herabgestuft werden, was sicherstellt, dass Schlüsselpersonen — wie Abteilungsleiter oder IT-Administratoren — stets die Kontrolle über kritische Daten behalten.

Grundlegende Tresortypen

Passwork verfügt über zwei grundlegende Tresortypen: Benutzertresore und Unternehmenstresore — diese können nicht gelöscht oder umbenannt werden:

• Benutzertresore: Standardmäßig sind diese nur für ihre Ersteller zugänglich und werden entweder als privat oder geteilt kategorisiert. Ein privater Tresor wird geteilt, wenn der Besitzer dieses Tresors anderen Benutzern Zugriff gewährt.
• Unternehmenstresore: Diese Tresore sind sowohl für den Ersteller als auch für Unternehmensadministratoren verfügbar, die automatisch Zugriff erhalten. Unternehmensadministratoren können nicht entfernt oder herabgestuft werden, was kontinuierliche Überwachung und Kontrolle gewährleistet.

Neben den grundlegenden Typen können Sie unbegrenzt benutzerdefinierte Tresortypen erstellen.

Vorteile von Tresortypen

Tresortypen ermöglichen es Passwork-Administratoren zu kontrollieren, wer Tresore erstellen kann, automatisch Administratoren zuzuweisen, die nicht entfernt werden können, und Ersteller-Berechtigungen effektiv zu verwalten.

• Kontinuierliche Kontrolle: Neue Tresore eines bestimmten Typs enthalten automatisch nicht entfernbare Administratoren, was kontinuierlichen Zugriff auf kritische Daten und konsistente Sicherheitsstandards über alle Tresore desselben Typs gewährleistet.
• Flexibilität bei Berechtigungen: Sie können Benutzern erlauben, Tresore zu erstellen, während Sie bestimmte Aktionen einschränken, wie z. B. das Verbot, andere Benutzer einzuladen.
• Delegation: Tresortypen ermöglichen eine granulare Berechtigungsverteilung — beispielsweise kann der IT-Leiter IT-Tresore verwalten, während der Vertriebsleiter die Tresore der Vertriebsabteilung überwacht.
• Audit und Analyse: Sehen Sie einfach alle Tresore im System zusammen mit ihren Typen und zugehörigen Benutzern ein und passen Sie Tresortypen bei Bedarf schnell an.
• Vereinfachte Tresorerstellung: Keine Notwendigkeit, Berechtigungen jedes Mal von Grund auf neu zu konfigurieren.

Tresore aller Typen unterstützen eine mehrstufige, ordnerbasierte Struktur, die es Administratoren ermöglicht, Hierarchien mit verschachtelten Elementen zu erstellen

Tresortypen verwalten

Auf der Seite Tresoreinstellungen können Sie alle Tresortypen verwalten, ihre Liste einsehen und Berechtigungen für Aktionszugriffe konfigurieren. Der Zugriff auf diesen Bereich wird durch individuelle Rollen-Berechtigungen gesteuert, was sicherstellt, dass nur autorisierte Benutzer kritische Einstellungen ändern können.

Tresortypen erstellen

Sie können aus grundlegenden Tresortypen wählen oder eigene benutzerdefinierte Typen erstellen. Um einen benutzerdefinierten Tresortyp einzurichten, klicken Sie auf Tresortyp erstellen.

Das Fenster zur Tresortyp-Erstellung bietet folgende Optionen:

• Name — geben Sie den Namen des Tresortyps an.
• Administratoren — wählen Sie Benutzer aus, die automatisch zu allen Tresoren dieses Typs mit Administrator-Berechtigungen hinzugefügt werden.
• Ersteller-Zugriff — definieren Sie das Zugangslevel, das Benutzern gewährt wird, die Tresore dieses Typs erstellen. Beispielsweise können Sie Mitarbeitern erlauben, Tresore zu erstellen, ohne ihnen zu gestatten, andere Benutzer einzuladen.
• Wer kann Tresore erstellen — bestimmen Sie, wer Tresore dieses Typs erstellen darf: bestimmte Benutzer, Gruppen, Rollen oder alle Benutzer.

Tresortypen bearbeiten

Benutzer mit Zugriff auf den Reiter Tresortypen können Tresortypen ändern, indem sie diese umbenennen, Administratoren hinzufügen oder entfernen und Tresorerstellungs-Berechtigungen aktualisieren. Um einen Tresortyp zu bearbeiten, wählen Sie ihn aus der Liste aller Typen aus und passen Sie die erforderlichen Felder an.

Wenn ein Benutzer als Administrator zu einem bestehenden Tresortyp hinzugefügt wird, müssen Sie die Anfrage bestätigen, um ihm Zugriff auf die entsprechenden Tresore zu gewähren.

Tresortypen löschen

Um einen Tresortyp zu löschen, wählen Sie einen oder mehrere Typen im Reiter Tresortypen aus und klicken Sie auf Löschen im Dropdown-Menü oben in der Liste.

Audit und Tresortyp-Änderung

Im Reiter Alle Tresore können Sie alle Tresore zusammen mit ihren Typen, Benutzerlisten und Administratoren einsehen. Zusätzlich können Sie den Typ eines Tresors schnell ändern — beispielsweise wenn eine Abteilung reorganisiert wird oder ein neues Projekt erstellt wird.

Sie haben die Möglichkeit, Tresore nach Typ zu filtern oder nur diejenigen anzuzeigen, auf die Sie Zugriff haben.

Einstellungen

Der Reiter Einstellungen ermöglicht es, das erforderliche Mindestzugangslevel für die Ausführung bestimmter Aktionen innerhalb von Verzeichnissen zu definieren sowie die maximale Dateigröße für Anhänge festzulegen, die mit Passwörtern verknüpft sind.

Migration von früheren Versionen

Bei der Migration von früheren Versionen können Sie importierten Tresoren im Tresor-Import-Fenster einen Tresortyp zuweisen, sofern Sie die Option wählen, in das Stammverzeichnis zu importieren.

Beim Upgrade von Passwork 6 auf Version 7 konvertiert das System bestehende Tresore automatisch:

• Private Tresore bleiben privat und erhalten den Typ Benutzertresore. Ihre Berechtigungen und Zugriffsrechte bleiben unverändert.
• Geteilte Tresore erhalten ebenfalls den Typ Benutzertresore. Alle Benutzer und ihre Berechtigungen bleiben erhalten.
• Organisationstresore werden in den Unternehmens-Tresortyp konvertiert. Administratoren werden wiederhergestellt und werden nicht entfernbar, wobei die Zugriffsstruktur erhalten bleibt.

Häufig gestellte Fragen

• Was ist der Unterschied zwischen Tresortypen und regulären Tresoren? Reguläre Tresore sind Container zur Speicherung von Passwörtern. Tresortypen sind Regeln und Vorlagen, die definieren, wie Tresore eines bestimmten Typs erstellt und verwaltet werden.
• Ist die Verwendung von Tresortypen obligatorisch? Nein, die Verwendung benutzerdefinierter Tresortypen ist nicht obligatorisch. Sie haben immer Zugang zu grundlegenden Typen: private Tresore für persönliche Passwörter und geteilte Tresore für Passwörter, die Benutzer selbstständig teilen.

• Wie unterscheiden sich Unternehmensadministratoren von regulären Administratoren? Unternehmensadministratoren sind Benutzer, die automatisch Administratorrechte in allen Tresoren eines bestimmten Typs erhalten. Die Zuweisung von Unternehmensadministratoren gewährleistet permanente Kontrolle über kritische Daten.

• Kann ich Administratoren in einem bestehenden Typ ändern? Ja, Sie können die Liste der Administratoren in den Tresortyp-Einstellungen ändern. Beim Hinzufügen eines neuen Benutzers erstellt das System automatisch Anfragen, den neuen Administrator zu allen bestehenden Tresoren dieses Typs hinzuzufügen.

• Wie schränke ich ein, wer Tresore eines bestimmten Typs erstellen kann? Beim Erstellen oder Bearbeiten eines Tresortyps gehen Sie zu Wer kann Tresore erstellen und wählen Sie eine der Optionen: Alle Benutzer — jeder Benutzer kann einen Tresor dieses Typs erstellen, oder eingeschränkter Zugang — nur ausgewählte Benutzer, Rollen oder Gruppen.
• Kann ich den Typ eines bestehenden Tresors ändern? Ja, Sie können den Typ eines bestehenden Tresors ändern, aber nur wenn Sie Administratorrechte in diesem Tresor haben. Beim Ändern des Typs werden Unternehmensadministratoren des neuen Typs automatisch zum Tresor hinzugefügt, neue Zugriffsregeln werden angewendet und Benutzerverbindungsanfragen werden erstellt.
• Warum kann ich bestimmte Administratoren nicht aus einem Tresor entfernen? Wenn Sie Administratoren nicht aus einem Tresor entfernen können, handelt es sich um Unternehmensadministratoren. Unternehmensadministratoren können nur durch Ändern der entsprechenden Tresortyp-Einstellung entfernt werden (erfordert Administratorrechte).

Grundlegende Anwendungsfälle

Erstellung privater Tresore verbieten

Aufgabe: Mitarbeiter daran hindern, private Tresore zu erstellen.
Lösung: Öffnen Sie in den Tresoreinstellungen den Typ Benutzertresore. Entfernen Sie unter Wer kann Tresore erstellen alle Benutzer oder belassen Sie nur diejenigen, die dieses Recht behalten sollen.

Tresore mit obligatorischen Administratoren

Aufgabe: Alle von Benutzern erstellten Tresore müssen Unternehmensadministratoren enthalten.
Lösung: Erstellen Sie in den Tresoreinstellungen einen oder mehrere neue Tresortypen. Fügen Sie im Abschnitt Administratoren die erforderlichen Benutzer (Unternehmensadministratoren) hinzu — sie werden automatisch zu allen Tresoren dieses Typs mit Rechten hinzugefügt, die nicht geändert oder widerrufen werden können. Verbieten Sie die Erstellung anderer Tresortypen.

Erstellung privater Tresore ohne Benutzereinladungsrechte

Aufgabe: Benutzern erlauben, eigene Tresore zu erstellen, aber das Einladen anderer Benutzer verbieten.
Lösung: Erstellen Sie in den Tresoreinstellungen einen neuen Typ mit dem Zugangslevel „Vollständiger Zugang" für den Ersteller — dieses Level verbietet das Hinzufügen anderer Benutzer.

Delegation administrativer Verantwortlichkeiten

Aufgabe: Das System so konfigurieren, dass verschiedene Abteilungen oder Projekte ihre eigenen Administratoren haben.
Lösung: Erstellen Sie in den Tresoreinstellungen separate Typen für jede Abteilung und fügen Sie entsprechende Rollen hinzu.

Tresorverwaltung einschränken

Aufgabe: Administratoren daran hindern, die Liste aller Tresore einzusehen, Tresortypen zu verwalten und Zugangslevel-Einstellungen zu ändern.
Lösung: Öffnen Sie in den Rolleneinstellungen die Administrator-Rolle. Deaktivieren Sie im Abschnitt Tresore die erforderlichen Berechtigungen — Sie können den Zugriff auf den Bereich mit der Liste aller Tresore oder auf die gesamte Seite Tresoreinstellungen einschränken.

Fazit: Datenkontrolle und Effizienz

Tresortypen adressieren eine zentrale Herausforderung für wachsende Unternehmen: die Kontrolle des Datenzugriffs ohne Überlastung der IT-Abteilung. Administratoren erhalten automatisch Zugriff auf neue Tresore ihres Typs, während Abteilungsleiter Daten eigenständig verwalten können. Passwork skaliert mit Ihrer Organisation und stellt sicher, dass Daten sicher bleiben, Prozesse automatisiert sind und Mitarbeiter effizient arbeiten können.

Weiterführende Lektüre

Incident response planning: Preparedness vs. reality

Discover key insights from Passwork webinar on incident response planning. Why teamwork and tools drive real cybersecurity resilience.

Passwork BlogTurpal Makh

GDPR password security: Guide to effective staff training

Learn proven strategies to train employees for GDPR password security compliance. Reduce breach risks with practical training methods.

Passwork BlogAna Moore

Passwork 7: Security verified by HackerOne

Passwork has successfully completed the penetration testing, carried out by HackerOne — the world's largest platform for coordinating bug bounty programs and security assessments. This independent evaluation confirmed Passwork's highest level of data protection and strong resilience against modern cyber threats. What the pentest covered Security architecture and data

Passwork BlogEirik Salmi

Tipos de bóvedas

Passwork 7.1 introduce una arquitectura robusta de tipos de bóvedas, proporcionando control de acceso de nivel empresarial para una seguridad y gestión mejoradas. Los tipos de bóvedas abordan un desafío clave para los administradores: controlar el acceso a los datos y delegar la gestión de bóvedas en organizaciones grandes. Anteriormente, la elección se limitaba a dos tipos. Ahora, puede crear tipos de bóvedas personalizados adaptados a cualquier tarea o estructura organizativa.

Para cada departamento o proyecto, puede crear un tipo de bóveda dedicado, asignar administradores específicos, elegir los permisos del creador y definir quién puede crear bóvedas de este tipo.

Por ejemplo, puede crear bóvedas separadas para el departamento de TI, finanzas, recursos humanos o equipos de proyectos temporales. Los administradores asignados a un tipo de bóveda específico se añadirán automáticamente a todas las nuevas bóvedas de este tipo, asegurando un control y transparencia constantes.

Qué son los tipos de bóvedas

Los tipos de bóvedas permiten a los administradores establecer plantillas de bóvedas con configuraciones de gestión de acceso predefinidas. Para cada tipo de bóveda, puede designar administradores específicos, configurar los permisos del creador de la bóveda y establecer reglas o restricciones para crear nuevas bóvedas.

Puede organizar las bóvedas por departamento, proyecto o nivel de acceso, asegurando que los permisos se asignen con precisión

Cuando se crea una bóveda, los administradores especificados en la configuración del tipo de bóveda reciben acceso automáticamente. Estos administradores no pueden ser eliminados ni degradados, asegurando que el personal clave — como jefes de departamento o administradores de TI — siempre mantenga el control sobre los datos críticos.

Tipos de bóvedas básicos

Passwork tiene dos tipos de bóvedas básicos: Bóvedas de usuario y Bóvedas de empresa — no pueden eliminarse ni renombrarse:

• Bóvedas de usuario: Por defecto, estas solo son accesibles para sus creadores y se categorizan como privadas o compartidas. Una bóveda privada se convierte en compartida cuando el propietario de esta bóveda otorga acceso a otros usuarios.
• Bóvedas de empresa: Estas bóvedas están disponibles tanto para el creador como para los administradores corporativos, quienes reciben acceso automáticamente. Los administradores corporativos no pueden ser eliminados ni degradados, asegurando una supervisión y control continuos.

Además de los tipos básicos, puede crear tipos de bóvedas personalizados ilimitados.

Ventajas de los tipos de bóvedas

Los tipos de bóvedas permiten a los administradores de Passwork controlar quién puede crear bóvedas, asignar automáticamente administradores que no pueden ser eliminados y gestionar eficazmente los permisos de los creadores.

• Control constante: Las nuevas bóvedas de un tipo específico incluyen automáticamente administradores no eliminables, asegurando un acceso continuo a los datos críticos y estándares de seguridad consistentes en todas las bóvedas del mismo tipo.
• Flexibilidad de permisos: Puede permitir que los usuarios creen bóvedas mientras restringe ciertas acciones, como prohibirles invitar a otros usuarios.
• Delegación: Los tipos de bóvedas permiten una distribución granular de permisos — por ejemplo, el director de TI puede gestionar las bóvedas de TI, mientras que el director de ventas supervisa las bóvedas del departamento de ventas.
• Auditoría y análisis: Vea fácilmente todas las bóvedas del sistema, junto con sus tipos y usuarios asociados, y ajuste rápidamente los tipos de bóvedas según sea necesario.
• Creación de bóvedas simplificada: No es necesario configurar los permisos desde cero cada vez.

Las bóvedas de todos los tipos admiten una estructura multinivel basada en carpetas, lo que permite a los administradores crear jerarquías con elementos anidados

Gestión de tipos de bóvedas

En la página Configuración de bóvedas, puede gestionar todos los tipos de bóvedas, ver su lista y configurar los permisos de acceso a acciones. El acceso a esta sección está controlado por permisos de rol individuales, asegurando que solo los usuarios autorizados puedan modificar configuraciones críticas.

Creación de tipos de bóvedas

Puede elegir entre los tipos de bóvedas básicos o crear sus propios tipos personalizados. Para configurar un tipo de bóveda personalizado, haga clic en Crear tipo de bóveda.

La ventana de creación de tipo de bóveda ofrece las siguientes opciones:

• Nombre — especifique el nombre del tipo de bóveda.
• Administradores — seleccione los usuarios que se añadirán automáticamente a todas las bóvedas de este tipo con permisos de administrador.
• Acceso del creador — defina el nivel de acceso otorgado a los usuarios que crean bóvedas de este tipo. Por ejemplo, puede permitir que los empleados creen bóvedas sin permitirles invitar a otros usuarios.
• Quién puede crear bóvedas — determine quién puede crear bóvedas de este tipo: usuarios específicos, grupos, roles o todos los usuarios.

Edición de tipos de bóvedas

Los usuarios con acceso a la pestaña Tipos de bóvedas pueden modificar los tipos de bóvedas renombrándolos, añadiendo o eliminando administradores y actualizando los permisos de creación de bóvedas. Para editar un tipo de bóveda, selecciónelo de la lista de todos los tipos y ajuste los campos necesarios.

Si se añade un usuario como administrador a un tipo de bóveda existente, debe confirmar la solicitud para otorgarle acceso a las bóvedas correspondientes.

Eliminación de tipos de bóvedas

Para eliminar un tipo de bóveda, seleccione uno o más tipos en la pestaña Tipos de bóvedas y haga clic en Eliminar en el menú desplegable en la parte superior de la lista.

Auditoría y cambio de tipo de bóveda

En la pestaña Todas las bóvedas, puede ver todas las bóvedas junto con sus tipos, listas de usuarios y administradores. Además, puede cambiar rápidamente el tipo de una bóveda — por ejemplo, cuando se reorganiza un departamento o se crea un nuevo proyecto.

Tiene la opción de filtrar las bóvedas por tipo o mostrar solo aquellas a las que tiene acceso.

Configuración

La pestaña Configuración permite definir el nivel de acceso mínimo requerido para realizar acciones específicas dentro de los directorios, así como establecer el tamaño máximo de archivo para los adjuntos vinculados a contraseñas.

Migración desde versiones anteriores

Al migrar desde versiones anteriores, puede asignar un tipo de bóveda a las bóvedas importadas en la ventana de importación de bóvedas, siempre que elija la opción de importar al directorio raíz.

Al actualizar de Passwork 6 a la versión 7, el sistema convierte automáticamente las bóvedas existentes:

• Las bóvedas privadas permanecen privadas y reciben el tipo Bóvedas de usuario. Sus permisos y derechos de acceso permanecen sin cambios.
• Las bóvedas compartidas también reciben el tipo Bóvedas de usuario. Todos los usuarios y sus permisos se conservan.
• Las bóvedas de organización se convierten al tipo de bóveda de empresa. Los administradores se restauran y se vuelven no eliminables, con la estructura de acceso conservada.

Preguntas frecuentes

• ¿Cuál es la diferencia entre los tipos de bóvedas y las bóvedas normales? Las bóvedas normales son contenedores para almacenar contraseñas. Los tipos de bóvedas son reglas y plantillas que definen cómo se crean y gestionan las bóvedas de un tipo específico.
• ¿Es obligatorio usar tipos de bóvedas? No, usar tipos de bóvedas personalizados no es obligatorio. Siempre tendrá acceso a los tipos básicos: bóvedas privadas para contraseñas personales y bóvedas compartidas para contraseñas que los usuarios comparten de forma independiente.

• ¿En qué se diferencian los administradores corporativos de los normales? Los administradores corporativos son usuarios que reciben automáticamente derechos de administrador en todas las bóvedas de un tipo específico. Asignar administradores corporativos garantiza un control permanente sobre los datos críticos.

• ¿Puedo cambiar los administradores en un tipo existente? Sí, puede modificar la lista de administradores en la configuración del tipo de bóveda. Al añadir un nuevo usuario, el sistema crea automáticamente solicitudes para añadir al nuevo administrador a todas las bóvedas existentes de ese tipo.

• ¿Cómo restrinjo quién puede crear bóvedas de un tipo específico? Al crear o editar un tipo de bóveda, vaya a Quién puede crear bóvedas y elija una de las opciones: Todos los usuarios — cualquier usuario puede crear una bóveda de este tipo, o acceso limitado — solo usuarios, roles o grupos seleccionados.
• ¿Puedo cambiar el tipo de una bóveda existente? Sí, puede cambiar el tipo de una bóveda existente, pero solo si tiene derechos de administrador en esa bóveda. Al cambiar el tipo, los administradores corporativos del nuevo tipo se añaden automáticamente a la bóveda, se aplican las nuevas reglas de acceso y se crean solicitudes de conexión de usuarios.
• ¿Por qué no puedo eliminar ciertos administradores de una bóveda? Si no puede eliminar administradores de una bóveda, son administradores corporativos. Los administradores corporativos solo pueden ser eliminados cambiando la configuración del tipo de bóveda correspondiente (requiere derechos de administrador).

Casos de uso básicos

Prohibir la creación de bóvedas privadas

Tarea: Impedir que los empleados creen bóvedas privadas.
Solución: En Configuración de bóvedas, abra el tipo Bóvedas de usuario. En Quién puede crear bóvedas, elimine a todos los usuarios o deje solo a aquellos que necesiten conservar este derecho.

Bóvedas con administradores obligatorios

Tarea: Todas las bóvedas creadas por usuarios deben incluir administradores corporativos.
Solución: En Configuración de bóvedas, cree uno o más nuevos tipos de bóvedas. En la sección Administradores, añada los usuarios requeridos (administradores corporativos) — estos se añadirán automáticamente a todas las bóvedas de este tipo con derechos que no pueden ser cambiados ni revocados. Prohíba la creación de otros tipos de bóvedas.

Creación de bóvedas privadas sin derechos de invitación de usuarios

Tarea: Permitir que los usuarios creen sus propias bóvedas pero prohibir invitar a otros usuarios.
Solución: En Configuración de bóvedas, cree un nuevo tipo con nivel de acceso completo para el creador — este nivel prohíbe añadir a otros usuarios.

Delegación de responsabilidades administrativas

Tarea: Configurar el sistema para que diferentes departamentos o proyectos tengan sus propios administradores.
Solución: En Configuración de bóvedas, cree tipos separados para cada departamento y añada los roles correspondientes.

Limitar la gestión de bóvedas

Tarea: Impedir que los administradores vean la lista de todas las bóvedas, gestionen los tipos de bóvedas y la configuración de niveles de acceso.
Solución: En la configuración de roles, abra el rol de Administrador. En la sección Bóvedas, deshabilite los permisos necesarios — puede restringir el acceso a la sección con la lista de todas las bóvedas o a toda la página de Configuración de bóvedas.

Conclusión: Control de datos y eficiencia

Los tipos de bóvedas abordan un desafío clave para las empresas en crecimiento: controlar el acceso a los datos sin sobrecargar al departamento de TI. Los administradores obtienen automáticamente acceso a las nuevas bóvedas de su tipo, mientras que los jefes de departamento pueden gestionar los datos de forma independiente. Passwork escala con su organización, asegurando que los datos permanezcan seguros, los procesos estén automatizados y los empleados puedan trabajar eficientemente.

Lecturas adicionales

Planificación de respuesta a incidentes: Preparación vs. realidad

Descubra información clave del webinar de Passwork sobre planificación de respuesta a incidentes. Por qué el trabajo en equipo y las herramientas impulsan la verdadera resiliencia en ciberseguridad.

Passwork BlogTurpal Makh

Seguridad de contraseñas GDPR: Guía para una formación eficaz del personal

Aprenda estrategias probadas para formar a los empleados en el cumplimiento de seguridad de contraseñas GDPR. Reduzca los riesgos de brechas con métodos de formación prácticos.

Passwork BlogAna Moore

Passwork 7: Seguridad verificada por HackerOne

Passwork ha completado exitosamente las pruebas de penetración, realizadas por HackerOne — la plataforma más grande del mundo para coordinar programas de bug bounty y evaluaciones de seguridad. Esta evaluación independiente confirmó el más alto nivel de protección de datos de Passwork y su fuerte resiliencia contra las amenazas cibernéticas modernas. Qué cubrió el pentest Arquitectura de seguridad y datos

Passwork BlogEirik Salmi

Vault types

Passwork 7.1 introduces a robust vault types architecture, providing enterprise-grade access control for enhanced security and management. Vault types address a key challenge for administrators: controlling data access and delegating vault management across large organizations. Previously, the choice was limited to two types. Now, you can create custom vault types tailored to any task or organizational structure.

For each department or project, you can create a dedicated vault type, assign specific administrators, choose creator permissions, and define who can create vaults of this type.

For example, you can create separate vaults for IT department, finance, HR, or temporary project teams. Administrators assigned to a specific vault type will be automatically added to all new vaults of this type, ensuring constant control and transparency.

What are vault types

Vault types allow administrators to establish vault templates with predefined access management settings. For each vault type, you can designate specific administrators, configure vault creator permissions, and set rules or restrictions for creating new vaults.

You can organize vaults by department, project, or access level, ensuring that permissions are assigned accurately

When a vault is created, administrators specified in the vault type settings are automatically granted access. These administrators cannot be removed or demoted, ensuring that key personnel — such as department heads or IT administrators — always retain control over critical data.

Basic vault types

Passwork has two basic vault types: User vaults and Company vaults — they cannot be deleted or renamed:

• User vaults: By default, these are accessible only to their creators and are categorized as either private or shared. A private vault becomes shared when the owner of this vault grants access to other users.
• Company vaults: These vaults are available to both the creator and corporate administrators, who are automatically assigned access. Corporate administrators cannot be removed or demoted, ensuring continuous oversight and control.

Besides basic types, you can create unlimited custom vault types.

Advantages of vault types

Vault types empower Passwork administrators to control who can create vaults, automatically assign administrators who cannot be removed, and effectively manage creator permissions.

• Constant control: New vaults of a specific type automatically include non-removable administrators, ensuring continuous access to critical data and consistent security standards across all vaults of the same type.
• Permission flexibility: You can allow users to create vaults while restricting certain actions, such as prohibiting them from inviting other users.
• Delegation: Vault types enable granular permission distribution — for example, the IT director can manage IT vaults, while the sales director oversees sales department vaults.
• Audit and analysis: Easily view all vaults in the system, along with their types and associated users, and quickly adjust vault types as needed.
• Streamlined vault creation: No need to configure permissions from scratch each time.

Vaults of all types support a multi-level, folder-based structure, allowing administrators to create hierarchies with nested elements

Managing vault types

On the Vault settings page, you can manage all vault types, view their list, and configure action access permissions. Access to this section is controlled by individual role permissions, ensuring that only authorized users can modify critical settings.

Creating vault types

You can choose from basic vault types or create your own custom types. To set up a custom vault type, click Create vault type.

The vault type creation window offers the following options:

• Name — specify the vault type name.
• Administrators — select users who will be automatically added to all vaults of this type with Administrator permissions.
• Creator access — define the access level granted to users who create vaults of this type. For example, you can allow employees to create vaults without permitting them to invite other users.
• Who can create vaults — determine who is allowed to create vaults of this type: specific users, groups, roles, or all users.

Editing vault types

Users with access to the Vault types tab can modify vault types by renaming them, adding or removing administrators, and updating vault creation permissions. To edit a vault type, select it from the list of all types and adjust the necessary fields.

If a user is added as an administrator to an existing vault type, you must confirm the request to grant them access to the corresponding vaults.

Deleting vault types

To delete a vault type, select one or more types on the Vault types tab and click Delete in the dropdown menu at the top of the list.

Audit and vault type change

On the All vaults tab, you can view all vaults along with their types, user lists, and administrators. Additionally, you can quickly change a vault’s type — for example, when a department is reorganized or a new project is created.

You have the option to filter vaults by type or display only those to which you have access.

Settings

The Settings tab makes it possible to define the minimum required access level for performing specific actions within directories, as well as set the maximum file size for attachments linked to passwords.

Migration from previous versions

When migrating from previous versions, you can assign a vault type to imported vaults in the vault import window, provided you choose the option to import to the root directory.

When upgrading from Passwork 6 to version 7, the system automatically converts existing vaults:

• Private vaults remain private and receive the User vaults type. Your permissions and access rights remain unchanged.
• Shared vaults also receive the User vaults type. All users and their permissions are preserved.
• Organization vaults are converted to company vault type. Administrators are restored and become non-removable, with the access structure preserved.

Frequently asked questions

• What's the difference between vault types and regular vaults? Regular vaults are containers for storing passwords. Vault types are rules and templates that define how vaults of a specific type are created and managed.
• Is it mandatory to use vault types? No, using custom vault types is not mandatory. You'll always have access to basic types: private vaults for personal passwords and shared vaults for passwords users share independently.

• How do corporate administrators differ from regular ones? Corporate administrators are users who automatically receive administrator rights in all vaults of a specific type. Assigning corporate administrators ensures permanent control over critical data.

• Can I change administrators in an existing type? Yes, you can modify the list of administrators in the vault type settings. When adding a new user, the system automatically creates requests to add the new administrator to all existing vaults of that type.

• How do I restrict who can create vaults of a specific type? When creating or editing a vault type, go to Who can create vaults and choose one of the options: All users — any user can create a vault of this type, or limited access — only selected users, roles, or groups.
• Can I change the type of an existing vault? Yes, you can change an existing vault's type, but only if you have administrator rights in that vault. When changing the type, corporate administrators of the new type are automatically added to the vault, new access rules are applied, and user connection requests are created.
• Why can't I remove certain administrators from a vault? If you cannot remove administrators from a vault, they are corporate administrators. Corporate administrators can only be removed by changing the corresponding vault type setting (requires administrator rights).

Basic use cases

Prohibit private vaults creation

Task: Prevent employees from creating private vaults.
Solution: In Vault settings, open the User vaults type. In Who can create vaults, remove all users or leave only those who need to retain this right.

Vaults with mandatory administrators

Task: All vaults created by users must include corporate administrators.
Solution: In Vault settings, create one or more new vault types. In the Administrators section, add the required users (corporate administrators) — they will automatically be added to all vaults of this type with rights that cannot be changed or revoked. Prohibit creation of other vault types.

Private vaults creation without user invitation rights

Task: Allow users to create their own vaults but prohibit inviting other users.
Solution: In Vault settings, create a new type with Full access level for the creator—this level prohibits adding other users.

Delegating administrative responsibilities

Task: Configure the system so different departments or projects have their own administrators.
Solution: In Vault settings, create separate types for each department and add corresponding roles.

Limit vault management

Task: Prevent administrators from viewing the list of all vaults, managing vault types, and access level settings.
Solution: In role settings, open the Administrator role. In the Vaults section, disable the necessary permissions — you can restrict access to the section with the list of all vaults or to the entire Vault settings page.

Conclusion: Data control and efficiency

Vault types address a key challenge for growing companies: controlling data access without overwhelming the IT department. Administrators automatically gain access to new vaults of their type, while department heads can manage data independently. Passwork scales with your organization, ensuring data remains secure, processes are automated, and employees can work efficiently.

Further reading

Incident response planning: Preparedness vs. reality

Discover key insights from Passwork webinar on incident response planning. Why teamwork and tools drive real cybersecurity resilience.

Passwork BlogTurpal Makh

GDPR password security: Guide to effective staff training

Learn proven strategies to train employees for GDPR password security compliance. Reduce breach risks with practical training methods.

Passwork BlogAna Moore

Passwork 7: Security verified by HackerOne

Passwork has successfully completed the penetration testing, carried out by HackerOne — the world’s largest platform for coordinating bug bounty programs and security assessments. This independent evaluation confirmed Passwork’s highest level of data protection and strong resilience against modern cyber threats. What the pentest covered Security architecture and data

Passwork BlogEirik Salmi

In the new version of Passwork, we have completely redesigned the System settings. They are now divided into three sections:

1. Global — organization settings that determine the operations of most of the Passwork functions
2. Default — the values of the settings that will be used if no other custom settings are specified
3. Custom — settings that can be set for individual users and roles

Now you can set up different interface languages, configure authorization methods, and enable mandatory two-factor authentication for individual users and roles.

To do this, click "Create a new settings group" in Сustom settings, add users or roles and select your desired settings. The newly created group will be added to the top of the list and will get the highest priority.

The following settings are now available:

• Ability to create organization vaults and private vaults
• Ability to create links to passwords
• Mandatory 2FA
• Time of automatic logout when inactive
• Authorization method (by local password, LDAP password or SSO)
• API usage
• Interface language

We're already working to add new settings.

If you are already using Passwork — update your Passwork
Or request a free demo at passwork.pro

The 2025 small business cybersecurity checklist: A complete guide | Passwork

Passwork’s 2025 cybersecurity checklist, based on the NIST framework, provides actionable steps to prevent data breaches and financial loss.

Passwork BlogEirik Salmi

How to protect your online business from cyberattacks

Protect your online business from cyber threats with actionable strategies, from employee education to advanced tools like Passwork. Learn about phishing, ransomware, and more while discovering how to enhance security with simple yet effective measures. Stay protected — read the full article!

Passwork BlogEirik Salmi

Why do employees ignore cybersecurity policies?

Employees often ignore cybersecurity rules not out of laziness, but because they feel generic, irrelevant, or disconnected from real work. True change starts with empathy, leadership, and context-driven policies. Read the full article to learn how to make security stick.

Passwork BlogIliya Garakh, CTO