Why a password manager isn't enough for an MSP

Every MSP has a password manager, and most have a good one. Secrets are encrypted, access is grouped by client, sharing is logged, and the team stopped keeping credentials in a spreadsheet years ago. All of that is real progress and none of it is in question here.

The gap is narrower and more specific. A password manager answers: which of my people can see this secret? It has nothing to say about the question that actually causes incidents: should this secret leave my team right now, for the person currently asking?

The moment that matters

Consider what happens when a client rings for the Wi-Fi key on a new site, the admin password for a line-of-business application, or a licence key for a machine being rebuilt. The engineer opens the vault — legitimately, they are authorised — copies the secret, and reads it out.

The vault records that the engineer opened it. That log is entirely accurate and entirely beside the point. What nobody recorded is who was on the phone, whether they were verified, and on what basis the engineer decided they were entitled to it. The audit trail is precise about your side of the transaction and silent about the other.

The log says who opened the safe. Nobody wrote down who they handed it to.

Why the gap persists

Not through negligence. It persists because the two halves of the decision live in different systems:

• The request is in the ticketing system.
• The person — their role, their registered channels, whether they are allowed to ask for this — is in the CRM or a client onboarding document.
• The secret is in the password manager.
• The rule about who may authorise a release is usually in someone's head, or a policy document nobody has open.

To do this properly the engineer would have to consult four places while a caller waits. Under any load at all, they will not, and it would be strange to expect otherwise. The process is not being ignored; it is impractical, which amounts to the same thing.

What closing it looks like

The release has to be treated as what it is: a sensitive action performed on behalf of a third party. In practice that means four things happen in one place:

1. The caller is verified against factors held on their contact record before the vault opens.
2. The sensitivity of the specific credential determines whether a named approver at the client has to agree.
3. The release is attached to the ticket that caused it, not just to the person who performed it.
4. The whole sequence — who asked, what was checked, who approved, what was released — is written once and cannot be edited.

That is the reasoning behind gating the credentials vault with the same check as the rest of the desk. Not because a standalone password manager is badly built, but because it cannot see the request, the requester, or the rule — it was never given them.

The question to ask yourself

Pick a credential you released for a client in the last month. Can you produce, without asking anyone to remember: who requested it, how they proved who they were, who authorised the release, and which ticket it was attached to?

If the honest answer is that you could name the engineer and the time but not the rest, that is not a failure of the password manager. It is a sign that the vault is doing the job it was designed for, and the job next to it has quietly been left to whoever picked up the phone.