Write an IT Password Policy Your Technicians Can Follow

Define Where Each Kind of Secret Belongs

Use the approved credential system as the record for credentials your MSP is authorized to hold. Put references in tickets and documentation instead of the secret itself. Distinguish client credentials, the MSP's own administration, service credentials, and emergency access so each has a clear owner and approved use.

A vault is like a key cabinet: knowing where it is doesn't establish who should hold each key. Write the access decision beside the storage decision. Don't make possession of a vault login the only test for access to every client.

For each credential record, capture the relevant system, client, account purpose, owner, and access method without copying the secret into those descriptions. Identify dependencies that must be considered when the credential changes. Keep the procedure usable without making its notes another credential store.

The MSP Outpost model calls for a standard stack and staff training. Apply that discipline to the approved storage workflow. If someone needs an exception, give them a route to request it rather than leaving a second unofficial store unrecorded.

Limit Access to the Work Assigned

Create a role-and-client access map. Record who can view or use a credential, who can change it, who can share it, and who can export records. Verify the controls supported by your actual product and subscription instead of assuming a role name guarantees the boundary you intend.

I'd require a named approval for access beyond someone's normal duties. Record the work, client, approver, and condition for removing the access. Where the system supports temporary grants, test their end behavior; where it doesn't, assign someone the removal and confirmation.

The model places MFA in its included security baseline.

Test What an Ordinary Technician Can Reach

Use an approved test account or controlled exercise to inspect the permissions a normal technician receives. Check the clients and record types they should access, then check a record they should not. Include sharing and export paths where your product exposes them.

Say a technician moves from one client group to another. The intended outcome is a documented grant for the new work and removal of access no longer required. The test needs to inspect the effective access after the change, not just whether a manager approved a ticket.

If access is broader than intended, have the credential-system owner correct the role or grouping. Then repeat the check and record the result. Don't ask technicians to ignore records that the system still permits them to retrieve.

Review the logs your product actually provides. Assign someone to inspect relevant access, permission, and export events, with a route for unexplained activity. A retained log has limited operational value until somebody is responsible for using it.

Separate User-Password Changes From Secret Management

Write the policy for each credential type and supported system. Human passwords, service credentials, recovery material, and emergency accounts can have different dependencies and controls. Use current vendor guidance and applicable client requirements when defining the lifecycle, and have the security owner resolve conflicts.

For a planned service-credential change, identify the applications and jobs that depend on it. Agree the supported replacement method, authorization, test, and recovery plan before making the change. Record how the operator will confirm that required services still work and that old access has been removed where intended.

For suspected compromise, use the approved incident-response process rather than treating it as routine maintenance. The response owner decides containment and credential actions with the relevant system owners. A scheduled change window shouldn't become a reason to leave a suspected exposure unaddressed.

Include the Access That Survives the Vault

Removing a person's vault membership doesn't establish that all access to client systems has ended. The offboarding procedure needs to inspect the actual accounts, permissions, authenticators, and sessions involved, using the supported controls for each system. Assign the confirmation to the system owner.

Identify shared secrets the person could have retrieved and review their replacement under the approved process. Keep necessary service dependencies visible. A blanket change without that record can interrupt client work; skipping the review can leave the intended access removal incomplete.

Record emergency access separately. Define who can authorize its use, how an authorized person retrieves it during an outage, and how use is reviewed afterward. Test the approved recovery route so the plan doesn't rely on the same unavailable system it is intended to recover.

The right recovery arrangement depends on the vault's supported design, client access requirements, and the systems needed during an outage. Have the security owner document those dependencies. There isn't a universal offboarding button that can decide them for every environment.

Give Technicians a Route for Mistakes and Exceptions

If a secret appears in a ticket, message, or other unapproved location, the technician should report it through the approved security route. Record the affected credential and exposure without spreading it into more records. Have the response owner determine replacement, containment, and evidence handling rather than treating deletion of the visible text as proof the exposure is resolved.

Keep exceptions specific. Record the unsupported system, the required access, the responsible owner, and the plan to remove or manage the exception. Review the exception when that system or responsibility changes.

Start with a real support workflow and an approved test record. Ask the technician to locate the credential reference, obtain the authorized access, complete the work, and record the action without copying the secret. Then test access removal and the recovery route with the responsible owners. The policy earns its place when those checks produce the intended result.