TL;DR: Organizations, Collections, secure notes, and read-only sharing extend password manager workflows into controlled team sharing for passwords, cards, and sensitive procedures, while emphasizing master-password reprompting and limited access, according to Bitwarden’s guide. The governance issue is not storage alone, but whether shared credentials stay scoped to the right people and permissions.
NHIMG editorial — based on content published by Bitwarden: a guide to using Organizations and Collections for shared vault access
Questions worth separating out
Q: How should teams share secrets without expanding access too far?
A: Teams should share secrets through tightly scoped collections, not through broad vault access.
Q: Why do shared vaults create governance risk for identity teams?
A: Shared vaults create governance risk because they make access easy to distribute and hard to unwind.
Q: What do security teams get wrong about password manager sharing?
A: They often focus on passwords and ignore the other secrets stored alongside them, such as API keys, procedures, and secure notes.
Practitioner guidance
- Separate private and shared vault scopes Use Organizations and Collections to keep team secrets out of personal vaults, and avoid cross-contamination between private items and shared operational data.
- Make collection membership reviewable Tie each Collection to a named business purpose and review membership whenever team composition, vendors, or projects change.
- Default shared items to read-only Reserve write permission for a small set of owners so accidental edits do not alter shared credentials, procedures, or deployment notes.
What's in the full article
Bitwarden's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step instructions for creating an Organization in the web app and assigning Collections correctly.
- The exact invite flow for sharing a Collection with another user and controlling their access.
- Plan-level limits for Free, Families, Teams, and Enterprise accounts, useful when evaluating rollout scope.
- Configuration details for using secure notes, custom fields, and master-password reprompting in shared items.
👉 Read Bitwarden's guide to shared vaults, Organizations, and Collections →
Shared vaults and collections: what they mean for team access control?
Explore further
Shared vault governance is really non-human identity governance in disguise. Once a team starts storing API keys, secure notes, and login material in one shared system, the problem shifts from password hygiene to access lifecycle control. The key issue is not whether the vault encrypts well, but whether the shared items have clear ownership, collection boundaries, and revocation paths. Practitioners should treat every shared vault as an NHI governance surface, not a collaboration feature.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure.
A question worth separating out:
Q: How do organisations keep shared secrets from becoming a standing privilege problem?
A: By limiting write access, reviewing collection membership, and revoking shares when the business need ends. Shared secrets should not remain available by default after a project closes or a team changes. The goal is to make access temporary, specific, and easy to remove.
👉 Read our full editorial: Bitwarden shared vaults expand password management into team governance