Password Management for IT Teams: Beyond the Sticky Note

Every IT team has a password problem. It's usually one of three versions.

Version one: credentials are stored in a spreadsheet, a shared document, or a text file somewhere. Access is uncontrolled. When someone leaves, you don't know what they had access to.

Version two: there's a password manager, but nobody uses it consistently. Critical credentials are still in email threads, in someone's personal manager, or in a note on a whiteboard.

Version three: there's a password manager and policy, but the shared account credentials are rotated so rarely they might as well be permanent, and nobody's sure who has access to what.

Most shops are version two. Here's how to get to something better.

What you're actually protecting

IT credential management has two distinct problems that need different solutions.

Shared service credentials: The local admin account on servers. The network equipment login. The monitoring tool. These are used by multiple people and can't be tied to an individual identity in the traditional sense.

Individual privileged accounts: Domain admin credentials, root accounts, cloud console access. These should be individual, auditable, and time-limited where possible.

The mistake is managing both the same way. Shared credentials need to be in a shared vault with controlled access. Individual privileged accounts should follow least-privilege principles and ideally have their usage logged.

Password manager selection for IT teams

Personal password managers (1Password, Bitwarden, Dashlane) are built for individuals. They work for IT teams, but with limitations around sharing, access control, and audit trails.

IT-specific credential vaults (IT Glue, Hudu, PassPortal, Keeper for Enterprise) are built around shared team access, client organization, and offboarding controls. If you manage credentials for multiple clients or environments, the IT-specific tools are worth the cost.

For a solo IT professional or very small team managing one environment, a business plan on a standard password manager is usually sufficient.

The criteria that matter for IT use:

• Can you share a credential with a colleague without giving them your master password?
• Can you revoke access when someone leaves without rotating every credential they touched?
• Is there an audit log of who accessed what and when?
• Can you organize by client or environment?

If you're evaluating tools, answer those four questions for each one before anything else.

Practical credential hygiene

One vault per client or environment. Mixing credentials across clients is how you accidentally paste the wrong password into the wrong system. Keep them separated.

Record more than just the password. For each credential: what it's for, where it's used, when it was last changed, and any relevant notes (account email, recovery method, associated MFA seed). The notes field saves more time than the password does.

Separate the "break glass" credentials. Every environment should have a recovery path that doesn't depend on the password manager being accessible. A local admin password, a backdoor account, something. Document where these live separately, because they're the ones you need when everything else is broken.

Define a rotation schedule and actually follow it. Most shops rotate credentials when they remember to or after a security incident. A regular schedule (annual for most, quarterly for high-privilege accounts) is more defensible and catches compromised credentials before they cause damage.

Offboarding is where credential management breaks down

When a team member leaves, the standard process is: revoke their access, change the shared passwords they knew.

The problem is that "the shared passwords they knew" is often unknown. People share credentials informally. Someone might have the router login because they needed it once and wrote it down somewhere. The email from six months ago with the backup password is still in their inbox.

A vault with proper access control solves this. If every credential is in the vault and every vault access is controlled by membership, offboarding is straightforward: remove them from the vault. The credentials themselves don't have to change because the access is revoked at the vault level.

This only works if you actually got to that point. If credentials are scattered across email, notes, and personal managers, offboarding is still a guessing game.

MFA for privileged access

Multi-factor authentication should be on every privileged account. No exceptions for "it's inconvenient" or "I can't figure out how to set it up."

For shared accounts that use MFA: the MFA seed (the QR code or secret key used to set up the authenticator) needs to be stored in the vault alongside the password, not only in one person's authenticator app. When that person leaves, you're locked out of your own account.

This is an extremely common problem. The MFA was set up correctly. The account is secure. And now nobody can get in.

Store the MFA seed. Treat it with the same care as the password.

The simplest possible starting point

If you're starting from nothing: spend an afternoon going through every system you manage and putting every credential in a vault. Don't optimize the organization yet. Just get them in one place.

Once they're in one place, you can fix the organization, set up proper access controls, and establish rotation schedules. None of that works until the credentials are actually in the vault.

The first step is also the hardest, and it's the step most teams skip because there's always something more urgent. There isn't. A credential that walks out the door with a former employee is more urgent, you just don't know it yet.