How to Collect Logins and Account Access from Clients Securely

TLDR: Never collect client passwords over email or chat. Use delegated access (invite your account into the client’s account) wherever the platform supports it, so no password changes hands at all. For everything else, collect credentials through a secure, encrypted intake behind an expiring link. Request access by category, ask for the least you need, and confirm you can actually log in before the kickoff so work is not blocked on day one.

A new client signs. Before you can do anything useful, you need to get in: the ad accounts, the analytics, the CMS, the domain registrar, maybe the hosting panel and the CRM. So you send the email. “Can you send over the logins for these?” A day later, the client replies with a plain-text password to their entire Google Ads account, and now that credential lives in your inbox forever, backed up, forwarded, and searchable for years.

Collecting logins and account access is one of the most sensitive parts of client onboarding, and one of the least discussed. For agencies, MSPs, consultants, and anyone who works inside a client’s systems, it is also unavoidable. The question is not whether you collect access. It is whether you collect it in a way that protects the client, protects you, and does not stall the project on day one. This guide covers all three.

Why emailing passwords is a real liability

Email was built to deliver messages, not to guard secrets. When a client emails you a password, that credential does not just sit in one place. It is stored on their mail server and yours, copied into backups, synced to phones, and often forwarded to a colleague who “also needs it.” Delete the message and the copies remain. A single compromised inbox, yours or theirs, exposes every credential ever sent to it.

There is a second problem that owners underestimate: liability. Once a client’s password is in your inbox, you are holding sensitive access you cannot easily revoke, rotate, or audit. If you work in or around regulated data, that is a compliance exposure, and it is the same reason you should not be collecting documents through email either. Shared Google Docs and spreadsheets of passwords are no better. A link that “only people with the link can see” is one accidental share away from public, and it never expires on its own.

The uncomfortable truth is that the fast way to collect access and the safe way to collect access are usually not the same thing. The good news is that the safe way is not much slower once you set it up as a repeatable step.

The three ways to collect client access, ranked

Not every credential should be handled the same way. There are really three methods, and you should reach for them in this order.

Delegated access is the winner almost every time. Most serious platforms let the client invite your Google account or business account as a user with a specific role, so you never see or store a password at all. When the engagement ends, the client removes your access with one click, and nothing sensitive lingers in your systems. Ask for invited access first, and only fall back to collecting an actual credential when the platform genuinely does not support roles.

When a real credential has to change hands (an old membership site, an FTP login, a shared utility account), collect it through an encrypted intake, not a message. The difference between “text me the password” and “enter it in this secure field behind a link that expires in 72 hours” is the difference between a permanent liability and a one-time, controlled handoff. Retrieve it, use it, and where possible have the client rotate it afterward.

What access should you actually request?

Vague requests get vague responses. “Send me your logins” makes the client stop and think, which is where onboarding stalls. Instead, request access by category, tied to the specific work you were hired to do. Ask for the least access that lets you do the job, and reserve admin or owner roles for cases where you genuinely need them.

Here is a starting checklist you can adapt. Trim it to your engagement rather than sending the whole thing:

• Marketing and analytics. Google Ads, Meta Business Manager, LinkedIn Ads, Google Analytics 4, Google Search Console, Google Tag Manager. Almost all support invited access by email.
• Website and hosting. CMS admin (WordPress, Webflow, Shopify), domain registrar, DNS, hosting control panel, and any staging environment. Prefer creating you a user account over sharing the master login.
• Communication and CRM. Email marketing platform, CRM, help desk, and any shared inbox. Request a seat, not the owner’s password.
• Industry-specific systems. Accounting software, practice management, booking tools, or whatever platform is central to the client’s operation. For finance and legal work, treat these with the same care you would client documents.
• Brand and asset access. Logo files, brand guidelines, and content libraries. These are files, not credentials, so route them through your normal secure file upload flow.

For each item, be explicit about three things: which account, what access level (viewer, editor, admin), and whether you want an invite or an actual credential. That specificity alone cuts the back-and-forth roughly in half, the same way it does when you request documents with clear, named items.

How to make the request so clients complete it

Even a secure process fails if the client never finishes it. The mechanics of asking matter as much as the security. Three things move completion the most.

First, put everything in one place. If the client has to bounce between an email listing the accounts, a separate tool to enter each credential, and a chat thread asking clarifying questions, most will do part of it and go quiet. One secure request that shows the full list, the access level, and where to complete each item is far more likely to get done. This is the same consolidation principle behind why a client portal beats a pile of emails.

Second, remove the login wall on your side. It is a little absurd to ask a client to jump through a password-protected portal just so they can hand you their passwords. The lowest-friction pattern is a magic-link portal: the client clicks one secure link, sees exactly what access you need, grants the invites and enters any credentials, and is done, with no account to create on your end.

Third, verify before you promise a start date. The most common day-one disaster is discovering that a login does not work, an invite went to the wrong email, or the client granted viewer access when you needed editor. Build a “test every login” step into your process and do it before the kickoff, not during it. A missing or broken credential should surface while there is still time to fix it, which is exactly what automatic reminders are for. Nudging a client about an outstanding access item, without you having to remember, is the same discipline as chasing documents automatically instead of manually.

Security must-haves for collecting credentials

If you are going to collect any credential directly, the tool you use to collect it should clear a short bar. Anything less and you are just moving the liability from email to a slightly nicer inbox. Insist on all of these:

• Encryption in transit and at rest. The credential should be encrypted (look for TLS in transit and AES-256 at rest) from the moment the client enters it until you retrieve it. It should never be stored or sent in plain text.
• Expiring, revocable links. The link the client uses should expire on its own and be revocable on demand, so a forwarded link does not become a permanent door.
• No credentials in email or chat. The collection channel should be separate from your messaging entirely. If the “secure” tool emails you the password, it is not secure.
• An audit trail. You should be able to see who accessed what and when, which matters for both trust and compliance.
• Least-privilege by default. Prefer invited roles over shared master logins, and viewer over admin, unless the work truly requires more.

These are the same controls that belong in any serious onboarding data-security checklist. Collecting logins is simply the highest-stakes version of collecting sensitive information, so hold it to the highest standard.

A repeatable workflow you can reuse for every client

You should not reinvent this for each engagement. Turn it into a fixed step in your onboarding that runs the same way every time:

1. List the accounts per service. Build a reusable access request for each type of engagement so you are not writing it from scratch. A paid-media client and a web-build client need different lists.
2. Default to invites. For every account, ask “does this platform support inviting my account?” first. Only collect a raw credential when the answer is no.
3. Collect the rest in one secure place. Give the client a single link that shows every access item, lets them grant invites, and provides an encrypted field for any credential that must change hands.
4. Automate the follow-up. Set reminders on any outstanding access item so a stalled login does not quietly become a stalled project.
5. Test every login before kickoff. Confirm you can actually get into each account at the access level you need. Fix wrong emails and wrong roles now.
6. Rotate and document. For any shared credential, have the client change it after the engagement or at least at offboarding, and keep a simple record of what access you hold so you can hand it back cleanly.

Purpose-built onboarding tools like OnboardMap are designed to collapse this into one flow. You describe what you need in a sentence, it builds the request, and each client gets a single magic link with no login to create. Invites, secure fields, and file uploads live in one place, everything is encrypted in transit and at rest behind expiring links, the tool tracks what is still outstanding, and it sends the reminders so you do not have to. It replaces the “email me the passwords” habit with a controlled, auditable handoff, without adding steps for the client. If you would rather assemble it from a password manager, delegated invites, and a checklist you maintain by hand, that works too, as long as no credential ever touches email.

However you build it, the principle does not change. Collect the least access you need, prefer invites over passwords, keep every credential out of your inbox, and confirm it all works before you start. Do that consistently and you remove one of the quietest risks in your business while making the client’s first week feel calm and professional, which is exactly the impression you want a new client to have.

Want a secure way to collect access and documents without wiring it together yourself? You can try OnboardMap free and have your first client portal ready in minutes.

Frequently asked questions

How should clients share passwords with me securely? The safest option is not to share passwords at all. Use delegated or invited access on platforms that support it, such as Google Ads, Meta Business Manager, Google Analytics, and most CMS and hosting tools, so the client grants your account permission without handing over a password. When a credential has to change hands, collect it through an encrypted intake behind an expiring link, never over email, text, or chat.

Why is emailing passwords a bad idea? Email is stored in plain text on multiple servers, forwarded, backed up, and searchable for years. A single compromised inbox exposes every credential ever sent to it. Emailed passwords also leave you holding sensitive client data you cannot easily revoke or audit, which is a liability for regulated industries.

What account access should I request during onboarding? Request access by category based on the work: marketing platforms (ad accounts, analytics, business manager), website and hosting (CMS, registrar, DNS, hosting panel), communication (email or CRM), and any industry-specific systems. Ask for the least access that lets you do the job, and request admin only when you genuinely need it.

How do I collect access without slowing down the project? Send one clear request that lists every account you need, the access level, and whether you want an invite or a credential. Give the client a single secure place to complete it, confirm you can actually log in to each account before the kickoff, and use automatic reminders so a missing login does not stall the whole engagement.