How Agencies Can Manage 2FA for Client Accounts

Ask each client to add you as yourselves, rather than to send you their login. Almost every platform an agency works in has a way to grant an outside organisation access: partner access, a member invitation, a cross-account role, your own user in their CMS. Where that exists there is no shared password and no shared second factor to manage.

What remains after that is a short list per client: the accounts with no delegation, the ones on a plan that reserves it for enterprise, the ones set up by someone who left. Those need a custody arrangement you can audit while the engagement runs and unwind cleanly when it ends.

The constraint that makes agency 2FA different

An in-house team owns its accounts. If the second factor is sitting in the wrong place, they can move it: reset 2FA, add a second administrator, move the account to a shared mailbox. It is awkward, it is possible.

An agency has none of those levers. The accounts belong to the client, they were configured two years ago by someone in their finance team, and your influence over that configuration is a polite request during onboarding. You cannot fix the account. You can only fix your side of it.

The second difference is arithmetic. An in-house team has maybe fifteen shared accounts in total. An agency has some number of them per client. At three clients you can hold all of it in your head. At forty, informal practice is not a style choice, it is the thing that is going to fail, and it will fail on someone else’s property.

The general reasoning about custody on shared accounts is in shared account 2FA: how should teams handle it. What follows is the agency operating model on top of it.

What to ask for instead of a password

The shapes of proper access

The names differ per platform, the shape does not. Somebody outside the client’s organisation is granted a defined level of access to a defined asset, using their own login and their own second factor.

The client benefits more than you do, which is what makes it an easy conversation. They can see which changes were yours, they can remove you without resetting anything for their own staff, and no password of theirs ends up sitting in an email thread. Say that when you ask.

The tool-specific versions of this are covered elsewhere: a shared Stripe account, a shared AWS account, and shared social media accounts, where the partner-access model is furthest along.

How to run the conversation

Ask at kickoff, in writing, per account. An engagement that starts with an emailed password never revisits the question.

Two things make it land. Ask the person who actually administers the account, not the marketing manager who will forward your request to someone on leave. And send the steps rather than the request: a short numbered list of what to click, per platform, removes the effort that is the real objection. “For security reasons” reads as your problem; “so you can see what we changed and switch us off in one click” reads as theirs.

Expect a fortnight and a couple of reminders on some accounts. Do not let the work stall behind it.

When the client insists on sending the password anyway

Some will. A one-person business where the owner is the only administrator, a client whose IT provider does not answer, a platform with genuinely no delegation. Refusing the credential is not a real option, so reduce the exposure instead:

• Move it out of the mailbox on receipt. The copy in your inbox and the copy in their sent folder are both still there, and you control only one of them.
• Ask them to rotate the password once you hold it, or rotate it yourself if you are authorised to. That kills the emailed copy, which is the only thing you can actually do about it.
• Never accept the 2FA enrolment code. Not the QR screenshot, not the string underneath it, in any channel. If they offer, decline and explain why: it is the permanent credential rather than a password, copies cannot be counted or taken back, and undoing one means resetting 2FA on the account. The mechanics are in how TOTP secrets work.
• If they mention having emailed it to a previous supplier, tell them to treat it as compromised and reset. Uncomfortable message, correct advice.
• Write down what you received, from whom, and when. This habit is what makes the end of the engagement possible.

None of this makes an emailed password safe in retrospect. It shortens the window and gives you a record.

One client, one boundary

At forty clients, separation is the property that keeps a small incident small.

One entry per client account. Named by client and by account, never a shared “client logins” pile. The pile is what makes every subsequent rule unenforceable.

Access granted per person, for the clients they work on. The account manager on one retainer has no reason to reach another client’s registrar. This is not distrust of your own staff; it means a stolen laptop is one client’s problem and a leaver is one conversation.

A register you actually maintain. Not a document written once at kickoff:

A review in a fixed slot, attached to the retainer review or the invoice run. Access that is never reviewed only accumulates.

The honest cost: separation will block someone, usually whoever is covering a colleague’s client at short notice. The answer is a grant that takes thirty seconds, not standing access for everybody. If granting is slow, people route around it, and they route around it with a password in a chat message.

Onboarding a client

Treat access intake as a deliverable with an owner and a date, like the kickoff call.

1. List the accounts the work actually needs, not everything the client has. Scope creep in access is how agencies end up holding a registrar login they never use.
2. Find out who administers each one and what delegation it supports. The second question is usually answered by their own settings page.
3. Request delegated access, with the steps attached.
4. For whatever is left, agree custody explicitly: who at the agency holds the credential, where it lives, and who can read codes for it.
5. Record all of it, including the accounts you asked for and did not get.
6. Agree the end state now, while goodwill is high: what you will hand back, what you will remove, what you will ask them to rotate.

Step 6 costs five minutes at kickoff and saves a negotiation later, when a retainer is ending and nobody is feeling generous.

Offboarding a client

Staff offboarding gets discussed. Client offboarding is the one clients actually notice, and it is usually worse.

1. Remove what you control. Leave the partner relationship, drop the assumed role, delete your own users where you have the rights to.
2. Send the client the list of what only they can remove. Named users, partner links, API keys, app passwords, integrations. They will not remember what you were given; your register does.
3. Delete the credentials you hold, and say so.
4. Name every account where you held a TOTP secret, and ask them to reset 2FA and sign out all sessions on each one. This is the step everyone skips.
5. Put it in one written handover, dated, with what you held, what you removed, and what you have asked them to rotate.

On proving you no longer hold anything: you cannot prove the absence of a copy, and an agency that claims to is overstating. What you can do is put the client in a position where anything you might still have is worthless. A rotated password and a reset second factor is the only real proof, it is theirs to perform, so build the handover around asking for it rather than around reassurance.

This is where an informal practice becomes visible. If the credentials lived in one place, with a record of who could read them, step 4 is a paragraph you can write honestly. If eleven people scanned enrolment codes over three years, you cannot write it at all, and writing a vaguer version is the part that should bother you.

Contractors and freelancers

Rotation is the normal condition, not the exception, and it interacts badly with anything permanent.

Grant per client, and diary the removal on the day you grant it. A freelancer on one client for six weeks should have access to one client for six weeks. That date is easy to set while you are already in the settings page and impossible to remember four months later.

Give them codes, never secrets. A subcontractor works on their own device, with their own password manager and their own backups. Anything they can copy, they keep after the invoice is paid, and no clause changes that. The distinction is the subject of how to share TOTP codes without sharing the secret.

Where the client’s platform allows it, get the freelancer their own client-side user. The client sees whose work it was, and removal is one action on their side that does not involve you.

Never let a freelancer be the enrolment point for a client’s 2FA. It happens by accident: they set the account up during a launch, the authenticator ends up on their phone, and two years later nobody can sign in and they have changed career. On some platforms that has no reliable exit, only a support queue.

Close out access at the end of the contract as reliably as you send the invoice. One of those two always gets done. Attach the other to it.

What to put in the engagement note

Operational, not legal: the contract wording is a question for a lawyer, and none of this is legal advice. But a paragraph in the statement of work or the onboarding email settles arguments in month nine, and it should cover:

• Which accounts the agency holds credentials for, and which it reaches through delegated access.
• That the client retains ownership and can revoke any access at any time, without notice or explanation.
• Who at the agency is authorised, and that access is per person rather than to the agency as a body.
• That 2FA enrolment codes and secrets are not sent by email or chat, in either direction.
• What happens at the end: the handover list, the removals the agency performs, and the rotations it will ask the client to make.
• Who to contact when a credential stops working, so nobody resolves it by posting a password into a channel at 7pm.

The value is not enforceability. It is that the conversation happens once, at the start, in a calm week.

What breaks when this stays informal

The recognisable failure modes, each one a consequence of the same missing structure.

The relay. Codes come from one account manager’s phone. Workable at four clients, and then that person takes a week off.

The leaver you cannot offboard. Someone leaves who enrolled their authenticator across a dozen client accounts. Doing it properly means contacting twelve clients to ask them to reset 2FA, and explaining why. Most agencies quietly do not, which means the next handover note contains a claim that is not true.

The account nobody can recover. Registered to a personal email or a personal phone number, by someone who is no longer reachable.

The question you cannot answer. A client asks who opened their ad account on the 14th. “One of four or five people, we think” is a bad answer to give a client about their own property, and it is usually the moment an agency changes how it works.

The blast radius. One shared pile means one compromised laptop is an incident for every client at once, and the disclosure conversation is forty conversations.

Where Share Auth fits

For the client accounts left after delegation: the ones with a single login, no partner model, and a client who is not going to restructure anything.

The secret is entered once and encrypted at rest. The people you invite see the current six-digit code and its countdown rather than the string behind it, which is what makes a subcontractor’s access something you can actually withdraw. Permissions are set per member and per account, so client separation is expressible instead of aspirational. Every view is written to an access log, so “who read the code on the 14th” has an answer with a name and a timestamp. Removing a member removes their access on every client account at once. One action, with no twelve-client reset. There is an API for the cases where a machine, not a person, needs the code. The free tier covers three secrets and three members with no card, which is enough to run one client through the whole cycle before deciding anything.

What it does not do: it will not get you delegated access, which remains the better answer wherever it exists, it does not maintain your register or your handover notes, and it cannot undo an enrolment code that has already been emailed. It is not a password manager either, and the password should stay in the one you already have, for the reason set out in how to share 2FA codes with your team securely. If you are still weighing the options, the mechanisms are compared in best ways to manage 2FA for shared accounts, and the underlying protocol is covered in the complete guide to TOTP for teams.

Where to start

Not forty clients at once.

1. Pick the client with the messiest access and build their register entry properly. An afternoon, and it tells you what the other thirty-nine look like.
2. Write two templates: the numbered request steps you send at kickoff, and the handover note with its rotation request. Written is what makes them get sent.
3. Ask every current client for delegated access where it exists, one client per week.
4. For the accounts that stay shared, put the secret in one place with per-person access to the codes, and reset 2FA on anything whose enrolment code was ever emailed or posted.

The end state is unglamorous: a client asks what you hold and who used it, and you answer the same day.