When a Client Won't Give You Access to Their Accounts (Unblock the Build Without Nagging)
- A client who will not give you access is usually not difficult. They are busy, unsure what you need, worried about security, or waiting on someone else who owns the account. Repeating the same reminder does not fix any of those.
- Use the Profit Room's Access First method: send one written access list that says exactly what you need, why, and what level of access is enough. Ask to be invited as your own user instead of being sent their password. Then put the effect of the delay on the timeline, in writing, so the slip is not quietly yours.
- Prevent it next time. Make access a kickoff requirement in your agreement, collect it before the build clock starts, and offer a short screen-share where you walk the client through the invites together.
The Short Answer
When a client will not give you access to their accounts, stop sending vague reminders and send one clear access list instead. Name each account, say why you need it, and say the smallest level of access that will work. Ask the client to invite you as your own user rather than share their login. Then tell them, in writing, how the missing access affects the timeline, and offer a short call to set it up together.
That is the Access First method. It works because it removes the reasons access stalls: the client does not know exactly what you need, it feels risky to hand it over, or it feels like a chore with no deadline. A clear list, a safer way to grant it, and a visible effect on the schedule fix all three without you sounding like a nag.
Why Clients Hold Back Access
The reason shapes how you word the next message, so figure out which one it is.
- They do not know what you need. 'Send me access to everything' is hard to act on. They are not sure which account, which login, or where to find the settings.
- They are worried about security. Handing a stranger the keys to their website or customer data feels risky, and that is a fair instinct.
- Someone else owns the account. An old web developer, an IT provider, a partner, or a former employee set it up, and your contact cannot get in either. If your main contact changed, [when a client contact leaves mid-project](/blog/client-contact-leaves-mid-project) covers that case.
- It is not urgent to them. Access feels like admin, not progress, so it slides to the bottom of their list.
- They are having second thoughts. Rarely, slow access is a sign the client is hesitating on the whole project. If messages stop entirely, [what to do when a client goes silent](/blog/what-to-do-when-a-client-goes-silent) is the better playbook.
In nearly every case, the client wants the project to happen. Treat the delay as a setup problem you can help solve, not a test of who blinks first.
Run Access First
Send the access list the same day you notice the stall. Then follow these steps in order.
- List exactly what you need. For each account - hosting, domain, website or app builder, code repository, email or CRM, payment or booking tools - write what it is, why the build needs it, and the access level that is enough. Claude Code can help you turn your project plan into this list, but check every line yourself.
- Ask for invites, not passwords. Most modern tools let an owner add a collaborator, team member, or user with limited permissions. Ask to be added that way, under your own email. It is safer for them, it can be removed in one click when the project ends, and you never hold their personal login.
- Offer to do it together. A short screen-share where you walk them to the right settings page removes the 'I could not find it' problem. Keep it to the access list and nothing else.
- Put the delay on the timeline, in writing. Say plainly which parts of the build are waiting on which access, and that the delivery date moves by however long access takes. Calm and factual, not a threat.
- Keep building what you can. Work on the parts that do not need the missing access, so the project is not fully stopped and the client can see progress.
Access You Should Not Accept
Getting unblocked fast should never mean taking access in a way that puts you or the client at risk.
| What the client offers | The safer ask | Why it matters |
|---|---|---|
| Their personal password by email or text | An invite as your own user, or a shared password manager entry | Passwords in plain messages get forwarded, leaked, and never changed |
| Full owner or admin access to everything | The lowest permission level that lets you do the work | Less access means less risk if anything goes wrong |
| One shared login for the whole team | A separate user for you | Your actions are traceable and easy to remove later |
| Access to live customer or payment data you do not need | A test account, sample data, or no access to that part | Do not hold personal or payment data the build does not require |
Safer ways to get the access a build needs
If the client still cannot get access because nobody on their side owns the account anymore, recovering it is their job with the provider, not yours. Point them to the provider's own account recovery process and keep the rest of the build moving while they sort it out.
Set It Up So It Does Not Happen Again
The easiest fix is collecting access before the build clock starts. Add these to every project.
- Make access a kickoff requirement. Your agreement says the timeline starts once the access list is complete. [A one-page agreement before you build](/blog/one-page-agreement-before-you-build) shows where that line fits.
- Send the access list during onboarding. Include it in your welcome message so the client sees it on day one. [How to onboard a Claude Code client](/blog/onboard-a-claude-code-client) covers the rest of that first week.
- Book a short setup call. Offer it with the access list so the client can get everything done in one sitting.
- Say what happens if access is late. [Setting client expectations before a Claude Code build](/blog/set-client-expectations-before-a-claude-code-build) covers how to agree up front that delays on their side move the delivery date.
- Track it in your weekly update. A line in your [weekly client update](/blog/weekly-client-update-prevents-fires) listing anything still waiting on access keeps it visible without separate reminders. If a date slips anyway, [telling a client you will miss a deadline](/blog/tell-a-client-you-will-miss-a-deadline) covers the conversation.
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
What should I do when a client won't give me access to their accounts?
Send one written access list naming each account, why you need it, and the lowest access level that works. Ask to be invited as your own user, offer a short screen-share to set it up, and put the effect of the delay on the timeline in writing.
Should I ask a client for their passwords?
Avoid it. Ask to be invited as your own user with limited permissions instead. It is safer for the client, keeps your actions traceable, and is easy to remove when the project ends. If a shared login is truly the only option, use a password manager rather than email or text.
Does the deadline move if the client is late with access?
It should, and you should say so in writing as soon as the delay starts. Best practice is to agree in your contract that the timeline starts once access is complete and moves with any delay on the client's side.
What if nobody at the client can get into the account?
Recovering an account is between the client and the provider. Point them to the provider's own recovery process, and keep building the parts of the project that do not depend on that account.
What should happen to my access when the project ends?
Remove yourself, or ask the client to remove you, from every account at handover, and confirm it in writing. Keep a list of every account you were given during the project so nothing is missed.
Last reviewed October 16, 2026.
Co-founder of the Claude Code Profit Room. Built and sold AI services to real clients; writes about offers, pricing, outreach, and closing with receipts.
More from Duncan Rogoff →