# Manage client pages without passwords

Ask every client for delegated access to the page instead of a password, so you work from your own login and they can remove you at any time. Content OS finds, writes and posts for pages you can already reach, and it never holds a client credential.

## Why do clients end up sending passwords at all?

Because it is the fastest thing to do in a chat window, and nobody stops to offer a better option. The client wants the work to start today, and a password feels like the shortest path to that.

The threads where freelancers ask this question usually end with someone recommending a shared password vault, which leaves the real problem untouched. A vault protects the secret while it travels. It does not change the fact that you now hold a credential you cannot revoke, belonging to a person who may forget you ever had it.

## What are the four access models?

There are four ways you can end up working on a client page, and only the first two leave the client in control. We call this the four access models, and it is the first thing we send a freelancer who asks us before signing a new client.

| Access model | What the client does | What happens when the work ends |
|---|---|---|
| Delegated access to the page | Adds your own account to their page with a named role | They remove your account, and nothing else about the page changes |
| Partner access between business accounts | Links your business account to theirs as a partner | They end the partnership from their side, in one place |
| A login the client created for the job | Sends you a separate login made only for this work | They change that password, if they remember it exists |
| The client's own personal password | Sends the credentials they use for everything | Nothing is contained, and every other account they own is exposed |

## What should you ask a client for?

Ask to be added to the page in your own name, with the smallest role that still lets you publish. That one request settles the credential question, the offboarding question, and most of the awkward half of the contract at the same time.

Put the wording in your onboarding message so the client never has to invent it: "Please add my account to the page with a posting role, and I will never need your password." Clients agree to this far more often than freelancers expect, because it is obviously safer for them too.

## What should you never accept?

Never accept a personal password, and never accept a login that also reaches the client's payment methods or their personal profile. If the only way in is the credentials the client uses everywhere, the honest answer is that the page is not ready to be handed over yet.

## Does Content OS handle client accounts for you?

No. We will say the uncomfortable part plainly: Content OS does not solve credential custody, and client login, white-label surfaces and client-facing reporting are not built yet.

What it does today is find the story, write the post and publish it for pages you can already reach. There is no approval step, so if a client needs to sign off each post, that has to happen outside it.

## What does a password-free setup look like in practice?

You keep one login of your own, the client keeps ownership of their page, and each page carries its own scheduled jobs and its own topics. Nothing is shared between two clients except you.

That separation is also what makes the work explainable. When a client asks why a particular post went out on a particular morning, you can show the post and the run log for that page alone: when the run happened and whether it worked. A record of which story won and what it beat is designed, not built yet. No screenshots of a calendar, no memory games, no access to anything that belongs to another client.

## Where does the time go once passwords are out of the way?

Access is the first friction, but it is not the biggest one. The hours go into deciding what each page should say next, week after week, which is the part covered in [how much time social media really takes](/guides/automation/time-social-media-takes).

If you want the rest of the straight answers on running pages that are not yours, the [social media managers section](/social-media-managers) collects them, and the [FAQ](/faq) carries the short versions.

If you run several client pages and want to see how the scheduled runs are shaped for that, read [what this looks like for freelancers](/for-freelancers).