Encrypted resource metadata extends end-to-end protection from secrets to the surrounding context, including resource names, usernames and URIs. This reduces information disclosure if a database or backup is exposed and aligns better with data minimisation expectations in standards such as GDPR and ISO 27001.
New Cloud instances created after Passbolt 5.5 have encrypted resource metadata enabled by default. Existing instances can enable it and migrate their data at their own pace. Check out the last section below to learn how.
But this release is not just about security, it enables a whole new set of capabilities. Let’s dive in!
Multiple URIs
A single password can sometimes be valid on more than one URL, think of the same directory‑based account used on your wiki, issue tracker, and intranet, or a web application that serves its sign‑in form from different sub-domains. In earlier versions you had to create duplicate entries so autofill would pick up each address.
Encrypted resource metadata lets you attach several URIs to the same resource (see Fig. “Multiple URIs” in the edit dialog). Autofill now recognises any listed URI, saving you the manual search and paste routine and reducing the chance of entering credentials on the wrong page.
This is the first step toward a more flexible autofill system, future releases will add finer‑grained controls and additional matching options. For now, try linking your multi‑page or multi‑app credentials and tell us where the workflow still feels rough; your feedback will steer the next improvements.
Custom Icons & Colours
Scrolling through long lists of text-only credentials can quickly become overwhelming. Encrypted resource metadata solves this by letting you add simple visual cues, icons and colours, to each resource. The initial collection of icons is borrowed directly from the KeePass set, ensuring that imports and exports maintain their familiar appearance.
You could, for example, assign a specific icon to your database credentials, differentiating them clearly by colour: red for production, blue for staging. This makes critical distinctions instantly visible, reducing errors and speeding up your workflow.
If you prefer a text-only view, you can hide the icons column without affecting any other functionality.
Custom fields
Custom fields were one of the most-requested features from the community. It allows users to attach additional key–value pairs to a password entry or even create standalone key–value entries.
Teams often need to store information that doesn’t fit neatly into standard username and password fields. Custom fields make it possible to attach that extra context directly to credentials, keeping related information in one place. This helps reduce duplication, improve clarity, and make operational workflows easier to maintain, especially in setups with more complex infrastructure where automation is needed.
For example, teams can centralise CI/CD pipeline variables or store environment-specific configuration values with a credential, rather than cramming those details into a general text note.
Standalone notes
Many security teams manage snippets that are sensitive but not passwords: SSH configs, API tokens, deployment instructions, certificate chains, etc. Earlier versions left this material attached to credentials, which fragmented workflows, access control and auditing.
Standalone notes formalise this content as a new resource type. Notes carry the same end-to-end encryption, sharing model, and audit trail as passwords, and support up to 50 KB of plaintext. When encrypted resource metadata is enabled, notes sit alongside other resource types in the workspace and are rendered obfuscated by default with an in-place visibility toggle.
Enabling encrypted resource metadata
Passbolt 5.5 made encrypted resource metadata the default for new Cloud workspaces and introduced zero-knowledge mode. Existing Cloud instances created before Sep 23, 2025 can now enable it using the steps above.
Administrators can enable the capability from the browser extension. If the organisation has not configured metadata settings yet, the “Getting started” shortcut in the organisation settings.
When settings already exist, an administrator generates a shared metadata key, enables encrypted resource metadata, sets it as the default format so new items use it automatically, and optionally allows users to upgrade their own items.
Shared metadata key rotation
Shared metadata key rotation allows administrators to rotate the organisation’s metadata key from the settings. Rotation supports policy requirements and limits access for former members by ensuring new metadata is encrypted under a new key.
Zero-knowledge mode for metadata
Zero-knowledge mode prevents the server from accessing resource metadata. Administrators explicitly share the metadata key with users when appropriate, which strengthens confidentiality for organisations that prioritise privacy over server-side inspection. Until a user receives the key, actions that require shared metadata remain intentionally restricted.
Migrating existing content
Enabling encrypted resource metadata affects only new items. To migrate earlier content, a Migrate metadata setting page is available for administrators in the organisation settings.
Choose the appropriate scope and start the migration after taking a verified backup. Organisations with custom API or CLI integrations that read metadata should adapt those integrations before migrating to avoid breakage.
For more information, check-out The road to Passbolt version 5 - Getting started with the new resource types blog post.
That’s a wrap!
All related capabilities are now available on Passbolt Cloud, enabled by default on new workspaces and can be enabled on existing instances created before the Passbolt 5.5 release.
Stay tuned for more news and improvements in the coming month.
The Passbolt Team
