Small IT teams often manage a large number of credentials with limited staff and tooling. The goal is not to reproduce the infrastructure of a large security organization. It is to establish a small number of clear rules that prevent passwords and tokens from spreading through mailboxes, spreadsheets, tickets, and personal notes.
Separate persistent storage from temporary delivery
Persistent credentials that the team needs repeatedly should live in an approved password vault or secrets-management system. Temporary credentials that only need to move from one person to another can use a one-time delivery mechanism. Mixing these use cases creates confusion and unnecessary copies.
Use named accounts whenever possible
Shared administrator passwords are difficult to audit and expensive to rotate. Prefer individual accounts with role-based access. When a team member leaves or changes responsibilities, remove that person's access without changing credentials for everyone else.
Create an inventory of high-value secrets
You do not need to document the secret values themselves. Maintain an inventory that identifies the system, credential owner, purpose, storage location, rotation expectation, and recovery contact. This makes it easier to discover forgotten service accounts and credentials with no clear owner.
Define where secrets are allowed
A simple policy should state where persistent credentials may be stored and where they must not be stored. Common prohibited locations include team chat, email, support tickets, shared spreadsheets, source code, wiki pages, and personal text files. The policy should also explain the approved method for temporary transfer.
Handle service accounts differently
Service accounts and integration credentials may need long lifetimes, but they still require ownership and rotation. Avoid using a human employee's account for an automated process. Store application secrets in a controlled location and document which systems depend on them before rotating.
Plan employee onboarding and offboarding
Onboarding should grant the minimum access needed for the role. Offboarding should disable the user identity, revoke remote access, remove shared-vault permissions, invalidate individual API tokens, and review any credentials the departing employee administered. A checklist prevents access from remaining active because one system was forgotten.
Use temporary access for support and vendors
Contractors and support vendors rarely need permanent shared passwords. Create named, time-limited access where possible. If a temporary password must be delivered, keep it out of tickets and require rotation or automatic expiration after the work is complete.
Make rotation practical
Rotation fails when nobody knows what depends on a credential. Before changing a service credential, identify dependent applications, scheduled tasks, appliances, and integrations. Rotate in a controlled sequence and verify the dependent systems afterward.
Keep an audit trail
Record that access was issued, approved, changed, or revoked without recording the secret itself. A ticket can reference the vault entry or state that a temporary credential was delivered through an approved method.
Start small and improve
A useful first phase is: choose one approved password manager, stop storing secrets in tickets and chat, use named accounts, document critical service credentials, and establish an offboarding checklist. Once those controls are reliable, add automated expiration, privileged access workflows, centralized logging, and secret-scanning tools as needed.