The enterprise case for a password manager, made simply
After another year of major credential breaches, the argument for a corporate password manager is no longer mainly technical. It is an operational risk argument.
2016 has been another record year for credential theft. LinkedIn's 2012 breach turned out to involve 117 million accounts - only revealed this year. Yahoo disclosed in September that 500 million accounts were compromised in 2014. Dropbox confirmed a 2012 breach affecting 68 million users. The pattern is clear: credentials stolen years ago are still being used, sold, and reused.
In that context, I keep having the same conversation with clients about corporate password management. The conversation should be simple but it often is not, because "password manager" sounds like IT hygiene rather than risk management. I want to reframe it.
What the actual risk looks like
The risk is not primarily that an employee uses a weak password for a critical system. That is bad, but it is contained.
The higher risk is credential reuse across systems. An employee uses the same password for their work email, a SaaS tool, and a personal account on a service that was breached two years ago. The credential from that old breach surfaces, gets tested against the work email, and succeeds. Nothing in your own infrastructure failed. The vector was entirely external.
This is the breach pattern that dominated 2016. It is called credential stuffing, and it does not require any technical sophistication to execute.
What a corporate password manager actually addresses
A properly deployed password manager for a team addresses three things:
First, it makes unique passwords practical. Without a manager, asking employees to maintain 40 unique strong passwords is asking them to do something genuinely difficult. With a manager, it is a habit change of medium difficulty, not a memory challenge.
Second, it creates a rotation and revocation process. When an employee leaves, shared service credentials stored in the manager can be rotated cleanly. Without that, offboarding is a partial exercise - you remove access where you know to look, but not necessarily everywhere.
Third, it gives the security team visibility. Most enterprise password managers have audit logs. You can see what credentials are being used, whether they have been shared, and when they were last changed. Without this, you are operating blind.
The objections I hear
"Our team is small, this is enterprise software." Most password manager vendors have small business plans. The cost per seat is low enough that the per-incident savings from avoiding one credential breach easily justify it.
"We have SSO for everything." You almost certainly do not have SSO for everything. There is always a long tail of SaaS tools, third-party portals, and vendor access consoles that are outside the SSO umbrella. The password manager covers exactly that tail.
"Employees will not adopt it." This is the real objection. Adoption requires a policy, not a request. If the policy says shared service credentials must be stored in the manager, adoption follows.
Starting point
Audit the shared credentials your team currently uses - email them around, keep in spreadsheets, store in notes apps. List every service. That list is the scope of the problem. Then pick a tool and migrate that list. The technical work is small. The policy and habit work is most of the effort.