Rolling out a password manager across an organisation looks like an IT project and behaves like a change-management project. The software installation is the easy part. The hard part is designing shared folders that match how work actually gets done, setting policy that people will follow without being watched, and onboarding each group in a way that does not overwhelm them. Teams that get those three things right rarely need to enforce adoption; the tool sells itself.
Start with a pilot group, not the whole company
Choose a small group — ten to twenty people who do real work, represent different departments, and are willing to give honest feedback. A pilot group surfaces the questions that a plan cannot predict: which accounts are shared more often than expected, which folders become confusing, which people need edit access and which only need to view. Run the pilot for at least a month, collect the friction points, and adjust the design before expanding. A pilot that goes badly is cheap; a company-wide rollout that goes badly is expensive and hard to reverse.
Design folders around real work
The most common deployment mistake is creating a folder structure that mirrors the org chart rather than the work. People share credentials by task and by client, not by department. A marketing team may need one folder for social accounts, another for the analytics platform, and a third for the agency relationship. Ask the pilot group how they already share passwords, and build the folder structure around those answers. A folder that matches an existing workflow will be used; a folder that matches a diagram will be ignored.
Set policy people can actually follow
A security policy that nobody follows is worse than no policy, because it creates the illusion of control. Keep the rules short and specific: who may create shared folders, who may invite external people, what must never be stored in the vault, and how quickly access must be removed when someone leaves. Write the policy in plain language, publish it where people will see it, and make sure managers understand it well enough to answer questions without escalating to IT.
Plan the onboarding wave by wave
Onboarding everyone at once creates a support queue nobody can handle. Divide the organisation into waves, each small enough that the support team can respond to every question within a day. Give each wave a short orientation — fifteen minutes is usually enough — covering how to sign in, how to save a login, how to use a shared folder, and who to ask when something goes wrong. People learn password managers by using them on real accounts, not by reading documentation, so get them into the tool on day one.
Make shared folders the default for teams
Personal vaults are for personal credentials. Team credentials should live in shared folders from the beginning, so access can be managed centrally and removed cleanly when roles change. When a team member stores a shared credential in their personal vault, the organisation loses visibility and the credential becomes impossible to rotate systematically. Set the expectation early: if more than one person needs a login, it belongs in a shared folder.
Handle departures before they happen
The riskiest moment in any password deployment is the day someone leaves. Build the offboarding step into the standard exit checklist: remove the person from shared folders, rotate any credential they could have seen outside the vault, and confirm that no personal vault contains a credential the organisation still needs. Teams that prepare for departures in advance avoid the scramble that otherwise turns a routine resignation into a security incident.
Measure adoption honestly
Usage dashboards are easy to produce and easy to mislead. A better measure is the absence of workarounds: fewer passwords in spreadsheets, fewer credential-sharing messages in chat, fewer "what is the password for" questions in the support queue. Track those signals before and after each wave. If they are falling, the deployment is working. If they are not, the folder design or the onboarding needs attention, and no amount of additional training will fix a structure that does not match the work.
Support the people, not just the software
The most successful deployments treat support as part of the product. A named person who answers questions quickly, a short FAQ that addresses the questions people actually ask, and a clear path for escalating a real problem are worth more than any feature. Password managers change habits, and habits change slowly. Patience with the people using the tool is what turns a rollout into something that lasts. For help with the sign-in process itself, the ProtonPass portal covers the questions users ask most often.
Done this way, a Proton Pass deployment stops being an IT project with an end date and becomes quieter infrastructure: credentials in one controlled place, sharing that can be adjusted in seconds, and a workplace where the tedious part of the internet simply stopped being anyone's job.