How should an agency store client passwords, if not in a shared spreadsheet?

The spreadsheet is a copy problem, not a storage problem

A shared spreadsheet is not really a storage problem. It is a copy problem. Every client login that lives in a sheet, a Slack thread or a project brief is a copy of that login, and every copy is readable by whoever can open it, on whatever device they happen to use, for as long as the file exists.

For an agency it matters more, because of what the logins open. Mimecast counted 6.4 million detections of Meta Business Manager and Google Ads account theft across four years, 1.86 million of them in the second half of 2025 alone, and noted that aged accounts with real spend history resell at two to four times the price of new ones (via Help Net Security, 29 July 2026). An agency custodies exactly those accounts, for several clients at once.

It is also where the wider breach data points. Verizon's 2026 Data Breach Investigations Report found third parties involved in 48% of breaches (via Help Net Security, 25 May 2026). To your clients, you are that third party. So the useful question is not where to put the spreadsheet. It is how many of those logins you need to hold at all.

Step one: replace shared logins with delegated access

The biggest improvement is not a better place to store passwords. It is holding fewer of them. The two platforms agencies touch most both have a way to work on a client's assets without the client's login changing hands:

• Meta. A client can add your agency as a partner to their business portfolio, either giving your organization access to specific assets such as a Facebook Page, or asking you to share assets with them. Meta's help center names an agency as the example partner, and documents removing a partner as its own step (Meta Business Help Center, consulted 24 September 2026).
• Google Ads. A manager account lets you link and manage multiple separate Google Ads accounts from one place. The link works by invitation: you request it with the client's customer ID, and the client accepts or declines from their own account's access settings (Google Ads Help, consulted 24 September 2026).

Delegated access changes three things at once. The client stays the owner of the asset. Either side can end the relationship without a password reset. And each person on your team signs in as themselves, with their own second factor, so the platform can tell who did what.

Before storing any new client login, ask one question: does this platform let the client add us as a user or a partner? If it does, use that, even when it takes the client ten minutes longer to set up.

Step two: a team password manager for what is left

Some logins will not go away: a hosting control panel, a domain registrar, an older tool with a single account per customer. Those belong in a password manager built for teams, not in a document. What to require of it, whichever product you choose:

1. One vault, or collection, per client. Access is granted per client, so someone working on one account cannot browse the credentials of the other eleven.
2. Sharing by role, not by forwarding. People get access because they are on the account team, and lose it when they leave the team. Nobody pastes a password into a chat to help a colleague.
3. A strong second factor on the manager itself. The vault is now the most valuable login you have. Protect it accordingly.
4. Client credentials never go in personal vaults. If a freelancer saves a client login in their own manager, you cannot take it back.
5. A clear owner on your side. One named person can add and remove people, and does it the same day.

A password manager also fixes the quiet problem of reuse. CISA's guidance is to use a different strong password for each account, at least 16 characters, and it describes a password manager as a program that generates, stores and fills them in (CISA, Secure Our World, consulted 24 September 2026).

What a good password policy looks like in 2026

If your internal rules still require complex passwords changed every 90 days, they are out of date. NIST's digital identity guidelines, SP 800-63B Revision 4, published in August 2025, set a different baseline (NIST, consulted 24 September 2026):

• Length over complexity. Passwords used as the only factor must be at least 15 characters. Passwords used as part of multi-factor authentication can be shorter, with a minimum of eight.
• No composition rules. Verifiers must not demand mixtures of character types.
• No scheduled rotation. Periodic forced changes are not allowed, but a change is required when there is evidence the password has been compromised.
• Password managers are expected. Verifiers must allow password managers and autofill, and should allow paste.

NIST writes those rules for the systems that check passwords, not for agencies. But they tell you what a sensible internal policy looks like: long, unique, generated, stored in the manager, and changed when something happens rather than when the calendar says so.

The part everyone forgets: where the second factor goes

A gap that is easy to miss is not the storage. It is the second factor. A shared login protected by a code that goes to one account manager's personal phone works until that person is on holiday, changes phones or leaves. Then the team either gets locked out or someone turns the second factor off to get the work done and never turns it back on.

For every shared login that remains, decide where the second factor lives and write it down. If your password manager can hold one-time codes alongside the credential, that keeps the factor with the team rather than with a person. That is a trade-off, since it puts both factors in one place, so the vault's own protection has to be strong.

Offboarding, and a one-page inventory to start with

Storage only works if removal works. When a freelancer or employee finishes, three things happen the same day: their access to the password manager ends, their user or partner access on client platforms is removed, and any shared credential they could see is changed. The last step is the easiest to skip. A departure is not proof of compromise, but anyone who could view a password could also have copied it, and you have no way to know.

To start, you do not need a project. A one-page inventory is enough: client, platform, how access works today (delegated or shared login), who can see it, where the second factor goes, and the date it was last reviewed. Give the most attention to the column for who can see it, because that is the one that grows without anyone deciding it should.