How to ask a client for a password, and store it after

You’re rebuilding a client’s website and need their hosting login, or you’ve just signed a new managed IT client and need the admin account for their firewall. Here’s how to ask a client for a password without it ending up in an email thread: first ask whether they can give you your own login instead. If they can’t, send them a secret request, which is a link to a one-time form, with a short note saying exactly what you need and why. Move whatever comes back into your password manager the same day.

Clients default to email because nobody has given them anything easier. The scripts below give them something easier, and make you look like the careful supplier you are.

Ask for your own login first

A named account for your team is better than the client’s password in almost every way. You get your own MFA, the client’s audit log shows who did what, and at the end of the contract they remove your account without changing anything they use themselves. Most platforms agencies and MSPs work in support it.

Where there’s no such option (an old hosting control panel, a supplier portal with one login per customer, a router’s admin page, the office Wi-Fi), you need the password itself. That’s what the rest of this page is for.

Send a secret request, not an email

A secret request flips the usual direction of sharing. You create the request, the client gets a link to a one-time form, they paste the password in, and it arrives in your account. It never sits in their Sent folder or your inbox, and they don’t have to understand any of the reasons why.

In ShareShield, secret requests work like this:

1. Create the request from the dashboard. Add a message saying exactly what you need: which system, which account, what it’s for. The message can be up to 500 characters, which is plenty.
2. Choose how long it stays open. One, three or seven days; three is the default. Pick one day if you’re blocked on it, seven if the client is slow on email.
3. Send it to an address you already have for them, from your CRM or contract, not one that turned up in a new email thread.
4. Tell them it’s coming through another channel. A line on your weekly call or in your ticketing portal (“you’ll get a request from ShareShield for the hosting login”) means they know it’s genuine and won’t ignore it as spam.
5. When it’s fulfilled, you’re notified. The secret it creates opens once: reveal it, save it to your vault, and it’s gone.

If your plan includes file secrets, the client can answer a request with a file instead: a certificate, an SSH key, a recovery codes PDF.

Scripts you can copy

Adjust the tone to the client. These are written to be short enough that people actually read them.

The request (the message inside the secret request, or a covering note):

Hi Sam, to move your site to the new hosting we need the login for your current cPanel account (the one at host.example.net). The link below opens a one-time form. Paste the username and password there and it comes straight to us, without sitting in anyone’s email. If you’d rather create a separate login for us, that’s even better and I’m happy to walk you through it.

When they’ve already emailed it:

Thanks, that’s come through. One small thing for next time: passwords in email stay in both our mailboxes and backups for years, so we use one-time links instead. Once we’ve finished the migration, could you change that password? We’ll send you a reminder.

When they want to read it out over the phone:

I’d rather not take it over the phone, as it’s easy to mishear and I’d have to write it down. I’ll send you a short form now, and it’ll take you about thirty seconds.

At the end of the engagement:

We’ve finished the work, so here’s the list of access we hold for you: the cPanel login, the Cloudflare account and the WordPress admin user. We’ve deleted our copies. Please change the cPanel password and remove our Cloudflare and WordPress users. Reply here once that’s done and we’ll close the ticket.

What not to accept

If a client sends a password in a way you’d refuse, don’t reply quoting it: that’s another copy. Save it, delete the message, and decide with them whether it needs changing. A Wi-Fi password for a site visit doesn’t merit the same fuss as the domain registrar login.

Store it properly once you have it

• One vault or collection per client in your password manager (1Password, Bitwarden, Keeper), with access only for the people working on that account. When someone leaves your team, removing them from the client’s vault is one action, not a hunt.
• Record where it came from. In the item’s notes: who gave it to you, when, what it’s for, and when to review it. You’ll need that at the end of the engagement and in any security questionnaire.
• Use MSP documentation tools if that’s your stack. IT Glue and Hudu store credentials with access control and an audit trail, and that’s what they’re for. Your PSA’s tickets (ConnectWise, Autotask, HaloPSA) and your CRM are not.
• Never in the project tool or shared drive. Not in a Notion page, not in a Trello card, not in client-passwords.xlsx.

Why the client’s auditor will care

Larger clients increasingly ask suppliers how they handle access. If a client is certified to ISO/IEC 27001:2022, controls 5.19 and 5.20 in Annex A cover information security in supplier relationships and agreements, and their auditor may well ask how you hold their credentials. Under UK GDPR, if those systems hold personal data, you’re probably a processor, and your contract will require appropriate security for it.

Being able to say “we ask for named accounts, collect anything else through one-time requests, store it in a per-client vault and hand back a list at the end” is a good answer. It’s also a selling point in a proposal. When the work ends, offboarding shared credentials has the rotation order for anything that was shared both ways, and how to send a password securely covers the times you’re the one sending.