Password Managers for Site Teams: Ending Shared Spreadsheets

Somewhere on your team’s Google Drive or Dropbox, there is a spreadsheet called something like logins.xlsx. It has the wp-admin password, the database credentials, the SFTP login, the Cloudflare account, and maybe the domain registrar too. It gets emailed to new hires, copied to laptops, and never fully deleted when someone leaves. This is how most credential-related incidents start, not with a sophisticated attack, but with a plain text file that outlived the person who last needed it.

Moving a site team onto a proper password manager fixes this permanently, and it is one of the highest-leverage security changes you can make with almost no technical lift.

Why the Spreadsheet Fails

A shared spreadsheet has three structural problems that no amount of discipline fixes:

• No access control. Anyone with the file can see every credential in it, including ones they will never use.
• No audit trail. You cannot tell who viewed a password, when, or whether it was copied somewhere else.
• No revocation. When someone leaves, you have to hope every copy of the file gets updated or deleted. In practice, it does not.

Password managers built for teams (1Password, Bitwarden, and similar tools all offer team or business tiers) solve all three at once with shared vaults, granular permissions, and centralized deprovisioning.

What a Shared Vault Actually Buys You

A shared vault is not just an encrypted spreadsheet replacement. The real value is in how it changes daily behavior:

• Credentials are never typed into chat or email. A team member requests access, gets it granted inside the vault, and copies the password directly from an autofill or a masked field. It never travels through Slack history or an inbox.
• Passwords can be strong and unique without anyone memorizing them. Once the vault handles retrieval, there is no reason to reuse a password across the CMS, the database, and the DNS registrar just because it is easier to remember.
• Sharing can be scoped to a single item. A contractor who needs FTP access for one task can be given that single credential without ever seeing the WordPress admin login or the Cloudflare account.

Role Scoping: Not Everyone Needs the Keys to Everything

The instinct on small teams is to put everyone in one big vault with everything in it. Resist this. Structure vaults around roles instead of convenience:

• A core infrastructure vault for hosting panel access, SFTP/SSH keys, database credentials, and the domain registrar. Limited to whoever actually manages the server and DNS.
• A content/editorial vault for WordPress admin or editor logins, used by writers and editors who never need server-level access.
• A third-party services vault for email delivery providers, payment gateways, analytics, and Cloudflare, since these often carry their own blast radius if compromised.

WordPress itself supports this kind of scoping natively. Instead of sharing the single admin password with every contributor, create individual accounts with appropriate roles (Editor, Author, Contributor) so access matches responsibility. If a contractor or plugin needs programmatic access, use application passwords rather than the primary login. From wp-cli:

wp user application-password create contractor_user "Deploy script" --porcelain

This generates a scoped credential you can revoke independently without touching the user’s main password, and it belongs in the vault next to a note describing exactly what it is for.

Offboarding: The Moment Most Teams Get Wrong

Onboarding gets attention because it is visible and urgent. Offboarding gets skipped because the person is already gone and nobody wants to be the one chasing loose ends. This is exactly backwards. Offboarding is the moment that actually matters for security.

A clean offboarding checklist for a WordPress site should include:

1. Remove the person from the password manager immediately, which cuts off their access to every shared vault item at once.
2. Rotate any credential they had direct knowledge of, not just the ones tied to their named account. If they knew a shared database password, that password needs to change, not just their personal login.
3. Revoke and reissue SSH keys if they had server access, and check for any application passwords or API keys created under their name.
4. Remove their WordPress user account or downgrade it, and check for any users they may have created that you did not know about.

From wp-cli, a quick audit of accounts before or after a departure takes seconds:

wp user list --fields=ID,user_login,user_email,roles

Run this periodically, not just during offboarding. It is a fast way to catch a stray admin account nobody remembers creating.

Credential Hygiene That Stops Incidents Early

Most WordPress compromises trace back to something mundane: a reused password, a credential that sat unrotated for years, or an old contractor account nobody deactivated. A password manager makes the fix easy to sustain:

• Generate, do not invent. Use the manager’s generator for every new credential so nothing is reused or guessable.
• Rotate on a schedule, not just after an incident. Database and hosting panel credentials in particular are worth rotating periodically even with no known compromise.
• Enable two-factor authentication everywhere it is offered, starting with the password manager itself, then the WordPress admin, then hosting and registrar accounts.
• Keep the vault itself locked down with a strong master password and its own two-factor authentication. A password manager is only as good as the door protecting it.

Server-side credentials deserve the same treatment as WordPress logins. A managed host like ServerBorn already isolates database and SFTP credentials per site behind its own access controls, but any credential a human on your team can see and copy still belongs in the vault, not in a note-taking app or a message thread.

Takeaway

A shared spreadsheet feels efficient until the day it becomes the reason a site gets compromised. Moving to a real password manager with scoped vaults, individual WordPress accounts backed by application passwords for automation, and a firm offboarding checklist closes off one of the most common and most preventable paths into a site. It costs a small setup effort once and pays back every time someone joins or leaves the team.