An MSP holds client credentials whether or not its PSA provides a safe place for them. Without a controlled vault, those credentials tend to collect in spreadsheets, personal notes, or chat threads where access is difficult to limit and harder to review.

The Password Vault gives the team a shared operational record without making every secret available to every technician. Credentials are envelope-encrypted at rest, access can be granted for each credential, reveals are recorded, and time-based one-time password (TOTP) codes can be generated from a stored seed.

The Password Vault is an Enterprise Edition feature of AlgaPSA. It is not part of AlgaDesk — an AlgaDesk tenant that opens the vault URL is shown an upgrade prompt rather than the feature. On a self-hosted appliance it requires a Pro license; Essentials runs the free feature set. Open it from Passwords; the page breadcrumb is also Passwords. The page subtitle states Passwords are hidden, and all reveals are recorded.

Understand the protection model

The vault combines several controls. Each one addresses a different part of credential handling.

Control	What it protects	Operational result
Envelope encryption at rest	The stored credential material	Secrets are not stored as readable values in the underlying data store.
Per-credential access list	Each individual credential	A user may have vault-related permissions without being allowed to open every entry.
Recorded reveals	Credential access activity	Reveal events are recorded server-side, but v1.5.0 does not provide an audit-log screen.
TOTP support	Shared MFA seeds and current codes	Technicians do not need to pass screenshots of one-time codes through chat.
Hudu connectivity	Credentials already documented in Hudu	The MSP can keep Hudu in its documentation workflow instead of manually maintaining two credential stores.

Envelope encryption protects stored data, but it does not replace access discipline. Once an authorized user opens a credential, that user can use or copy it. Keep each access list narrow, review it as assignments change, and rotate secrets when continued confidentiality is uncertain.

For the tenant-wide role and resource permissions that surround vault access, see 10.17. Configure Roles, Permissions (RBAC), and API Keys for Your MSP.

The permission resource is Credential, and it is available across five roles. Use the role permission together with each password's access settings.

Read the vault list

Open Passwords in the main navigation, between Assets and Inventory. The page header states "Passwords are hidden, and all reveals are recorded."

Figure 1: One list across every client, filtered by client or by source. Nothing is shown in the clear until someone selects Reveal.

Above the list, a search field sits alongside an All clients filter and an All sources filter — sources being where a credential lives, which distinguishes entries held in AlgaPSA from those read out of Hudu. New password adds an entry.

Each credential is listed with its name, the username it belongs to, and the client it serves. Row actions are Reveal, edit, manage access, and delete. Nothing is shown in the clear until you choose Reveal, and that choice is what gets recorded.

Use those fields to confirm that the entry belongs to the intended client, identify whether the value is managed locally or in Hudu, and check whether two-factor authentication and access restrictions apply before revealing it.

Separate role permission from credential access

Holding a role is not the same as holding access to a specific credential. This distinction prevents a broad job assignment from becoming blanket access to every client's secrets.

Consider a technician who supports GreenLeaf Dental Group. The technician may have the general permission needed to work with credentials, but should appear only on the access lists for GreenLeaf credentials required by that assignment. Being assigned to GreenLeaf does not grant access to credentials for Harbor Point, Sterling, or any other client.

Check	Question to ask
Role or resource permission	Is this user allowed to perform credential-related work at all?
Per-credential access	Does this user need this particular secret for an assigned responsibility?
Client assignment	Does the current client relationship explain the business need for access?
Ongoing review	Does that need still exist after a project, escalation, or staffing change?

Use both layers deliberately. A broad technician role can support normal ticket work while each credential remains limited to the people who need it.

User lifecycle changes are covered in 10.2. Create Users, Assign Roles (Admin, Technician, Dispatcher), and Manage Accounts. Coordinate those changes with credential access reviews rather than assuming deactivation alone completes the security response.

Add a credential with a narrow access list

Before adding a credential, identify its owner, the client or system it belongs to, and the smallest group that needs to use it.

Select New password to open the entry form.

Figure 2: The entry form. Name the credential for the system it opens, not the client — the client is a separate field.

Field	How to use it
Name	Name the system, not the account: Veeam Backup & Replication Console, FortiGate 60F — Firewall Admin. A technician scanning the list should recognize the target at a glance.
Client	The client the credential belongs to. This is what the vault's client filter reads.
Username	The account name as the system expects it.
Password	Type it, or select Generate to have AlgaPSA produce one. A reveal control and a copy control sit beside the field.
Two-factor setup key (optional)	The TOTP seed. See below.
URL	Where the credential is used, so nobody hunts for the right console.
Notes	Context that distinguishes this entry from similarly named accounts.
Store in	Alga vault for credentials held in AlgaPSA. Entries read from Hudu stay in Hudu.

Select Save, then set the access list.

Open Password access and enable Restrict access when the entry must be limited. The control explains: When restricted, only the creator and the granted users and teams can see this password. Figure 3: Access is unrestricted until you turn it on. With the toggle off there is no grant list, because every user who can open the vault can open this entry.
Turning Restrict access on reveals Granted users and teams. Use Add user… and Add team… to grant the smallest practical set, then select Save access. While the toggle is off the panel shows only the toggle and its explanation, because an unrestricted password has no grant list to manage.
Confirm that a technician without entry-level access cannot open the credential, even if that technician holds a related role or works for another client.
Record the credential owner and rotation expectation in the MSP's operating procedure.

Do not use a per-credential access list as a permanent project roster. Remove temporary access when an escalation or migration ends.

Use TOTP without sharing screenshots

For accounts with shared MFA, the vault stores the TOTP seed and calculates the current time-based code. An authorized technician can retrieve the credential and current code from the same controlled record.

Getting the seed is the step teams stumble on, and the form says how: on the client's system, start two-factor setup and choose the option to enter a key manually instead of scanning the QR code. That key is what you paste into Two-factor setup key. AlgaPSA's own guidance puts it plainly — "If this system asks for a 6-digit code at sign-in, Alga can generate it."

This removes a common workaround: one person capturing a code and posting it into a chat thread. A screenshot can outlive the task, reach unintended participants, and separate the MFA event from the credential access record.

Treat the TOTP seed with the same care as the password. Anyone who obtains the seed can generate future codes, so its per-credential access list should be no broader than the account requires.

Keep Hudu as the documentation source where appropriate

If the MSP already manages credentials in Hudu, use the Hudu connection instead of copying values into a second manually maintained store. This reduces the chance that a rotated password is current in one system and stale in another.

Decide which system owns each credential, document that decision, and rotate at the source of record. The existing Hudu workflow can surface client passwords in AlgaPSA while Hudu remains authoritative. See 20.11. Hudu IT Documentation Integration: Surface Client Docs, Assets, and Passwords.

Per-password access lists apply only to Alga vault passwords. The access panel states: Per-password access settings are not available for Hudu passwords.

Rotate credentials after a technician leaves

Removing a departing technician's application account stops future authorized access, but it cannot make a previously viewed secret unknown. Rotate credentials the technician could have opened.

Deactivate the technician's user account and remove active assignments.
Review the credential access lists associated with that technician.
Build a rotation list from credentials the technician was permitted to access, along with any known reveals documented through the MSP's operating process.
Change each password or secret in the target system, then update its source-of-record entry.
Replace the TOTP seed when the external system supports resetting shared MFA and the risk assessment calls for it.
Remove the departed user from credential access lists and confirm the remaining users still reflect operational need.
Record completion through the MSP's normal offboarding or change-control process.

Prioritize privileged accounts, shared administrator accounts, recovery credentials, and credentials whose external system does not provide its own reliable access history.

Understand recorded reveals

AlgaPSA records password reveals server-side, but the credentials area in v1.5.0 has no audit or history interface. Do not document an audit-screen review as part of incident response, access recertification, or technician offboarding.

Until a supported retrieval workflow is confirmed, use current access lists, your MSP's ticket and change records, and the target system's own logs when investigating credential use. Narrow inappropriate access and rotate secrets whenever continued confidentiality is uncertain.

Navigation

7.8. Store and Share Client Credentials in the Password Vault