Most MSPs don’t need a full privileged access management platform. CyberArk starts at tens of thousands of dollars per year. BeyondTrust and Delinea aren’t far behind. These tools make sense for enterprises with dedicated security teams — they don’t make sense for a 15-person MSP trying to make sure the right technician has the right access to a client’s server admin account.
What most MSPs actually need is simpler: a way to know who accessed which credential, when, and — ideally — why. And a way to make sure the most sensitive passwords in a vault aren’t accessible to every technician with access to that client.
Weavestream’s per-password access controls are built for exactly that. They sit inside the credential vault every Weavestream tenant already has, and they require no additional tooling, no separate licensing, and no external integration.
The Problem with Vault-Level Access Control
Role-based access control in most IT documentation platforms operates at the tenant level. A technician either has access to Client A’s vault or they don’t. That’s a reasonable starting point, but it breaks down in two situations that MSPs encounter constantly.
The first is the mixed-sensitivity vault. Most client vaults contain a mix of credentials: Meraki dashboard login, Microsoft 365 admin, a vendor portal for ordering supplies, a CCTV management system. These are not equally sensitive. The Microsoft 365 Global Admin password is worth a lot more to an attacker than the CCTV login. Treating them identically, from an access control perspective, is a risk most MSPs accept by default — not by design.
The second is accountability at reveal time. Knowing that Technician A has access to Client B’s vault tells you who could have accessed a credential. It doesn’t tell you who did, or why. In a post-incident investigation, or when a client asks who accessed their admin password last Tuesday, “they had permission to access it” is not a satisfying answer.
Weavestream’s per-password controls address both problems.
Reason to View: Creating Accountability at the Moment of Access
The first control is a reason-to-view prompt. When enabled on a password record, any technician who attempts to reveal the secret sees a dialog box asking them to enter a justification before the password is decrypted and displayed.
This is a simple mechanism with a disproportionate effect. The prompt doesn’t prevent access — a technician who needs the password can get it. But it changes the psychological dynamic around accessing sensitive credentials. Requiring a justification creates a moment of friction that discourages casual or exploratory access. More importantly, the reason is logged.
Every reveal event generates an audit log entry that captures:
- The actor (who revealed it)
- The timestamp
- The IP address
- The reason they provided
That log is append-only and tamper-resistant. You can’t edit or delete the entry after the fact. If a client asks why their admin password was accessed at 11pm on a Friday, you can tell them exactly who did it, what machine they were on, and what reason they gave.
For MSPs working with compliance-conscious clients — healthcare organisations, financial services, legal firms — this is the kind of evidence that demonstrates you’re operating with appropriate controls. It’s not a checkbox audit entry; it’s a real access record.
User Whitelists: Restricting Sensitive Credentials to Specific Technicians
The second control is a per-password user whitelist. When configured, only the users on the whitelist can reveal the credential’s secret — even if other technicians have full access to that client’s vault.
This lets you build tiered access within a single tenant’s vault without creating separate tenant structures or roles. In practice, this looks like:
- The Microsoft 365 Global Admin password is restricted to senior technicians and the account manager. Junior techs can work in the client’s vault but can’t reveal that specific record.
- A client’s backup console admin password is restricted to the two engineers responsible for backup management, so access is both intentional and traceable.
- Emergency access credentials (domain administrator, firewall emergency recovery) are whitelisted to a small group — visible in the vault so technicians know they exist, but not revealable without the right permissions.
The whitelist operates at reveal time only. Non-whitelisted users can see the credential record exists — its name, username, and URL are visible — but clicking “Reveal” returns a permission error. This is a deliberate design decision: technicians can see what credentials a client has without being able to use all of them.
Client Portal Visibility Control
A third per-password flag controls whether a credential appears in the client-facing portal. Weavestream’s client portal gives read-only access to a subset of your tenant’s documentation — useful for clients who want visibility into their own environment.
Credentials are not exposed in the client portal by default. Enabling visible to clients on a specific password record opts it into the portal. This is the right model for MSPs who want clients to be able to look up certain account details themselves — say, a shared Wi-Fi password or a vendor portal login the client manages — without exposing the full credential vault.
The combination of user whitelists and portal visibility flags means you can have a single vault per client with fine-grained control over who sees what, at what level of access.
How This Fits the Audit Trail
These controls are most valuable when they’re paired with the rest of Weavestream’s audit infrastructure. Every change to a password record — not just reveals, but edits, deletions, and archiving — is written to the platform-wide audit log. The log captures before-and-after values for every field change, so you have a complete version history of what the credential was, who changed it, and when.
Combined with reason-to-view logging, this means the lifecycle of a sensitive credential is documented end to end: created, updated (with diffs), revealed (with reasons), and — if applicable — archived. For an MSP that needs to demonstrate appropriate handling of client credentials to a client, a regulator, or their own internal review, this is the kind of record that holds up.
Setting This Up in Practice
Per-password access controls are configured from the credential’s detail panel in Weavestream. Open a password record, navigate to the settings tab, and you’ll find:
- Visible to clients — toggle to expose in the client portal
- Reason to view — toggle to require a justification before each reveal
- User whitelist — add specific users who are permitted to reveal the secret
These controls can be applied to individual records without affecting anything else in the vault. You don’t need to reconfigure your tenant structure, create new roles, or change how other credentials work. Adding a reason-to-view prompt to your most sensitive credentials takes about 30 seconds per record.
The reveal audit trail is always active — regardless of whether the reason-to-view prompt is enabled. Even without the prompt, every reveal is logged with actor, timestamp, and IP. Enabling the prompt adds the justification field to that log entry.
Who This Is For
If your MSP has ever had to answer the question “who accessed that password?” and struggled to give a definitive answer, these controls are worth configuring on your highest-sensitivity credentials today.
If you’re working toward SOC 2, ISO 27001, or a client-specific security requirement that asks about privileged access management, the combination of user whitelists, reason-to-view prompts, and the reveal audit trail gives you a documented control you can point to — without deploying a separate PAM platform.
And if you’re evaluating Weavestream as an alternative to IT Glue, Hudu, or a standalone vault like Passportal, these per-password controls are something worth testing. The vault that comes with your self-hosted IT documentation platform already includes the credential access oversight most MSPs actually need.
Weavestream is free, self-hosted, and open source. The per-password access controls described here are available in every deployment, with no add-on required. Find out more at weavestream.io.