How to hand over website passwords without putting them in the handover document

The short answer

Passwords, API keys and recovery codes should not be in a website handover document. The document records which accounts exist, what each one controls, who owns it, the administrative contact address and where access is managed. The credentials themselves are transferred separately, through a password manager or another channel that can expire, and the document notes only that the transfer happened and when.

That is a firm position rather than a cautious one, and the reasoning below is about where the document ends up rather than how careful anyone is being when they write it.

Why a handover document is the wrong container for a secret

A handover document is built to be copied. It is forwarded, printed, attached to email and inherited by people who were not part of the project. Every one of those copies is a copy you cannot revoke, so a credential inside one is a credential you have permanently lost control of.

The specific ways it gets away from you, all of which are ordinary rather than careless:

• It gets forwarded. To a bookkeeper, to a new marketing hire, to the client’s IT contractor. That is the document doing its job.
• PDFs get downloaded. Onto a laptop, a phone, a shared drive, a personal Dropbox. Each copy ages independently.
• Old versions survive. You send version four; versions one to three are still in three inboxes, with the passwords you have since changed.
• Printed copies exist. In a folder, in a drawer, in an office the client moved out of.
• Staff turn over on both sides. The document outlives the people. Access does not get reviewed when someone leaves, because nobody remembers the document contains access.
• Revocation is all-or-nothing. A shared password in five copies of a file can only be revoked by changing it and telling everyone who legitimately needs it — which is exactly the work you avoided by writing it down.

None of that requires anyone to behave badly. It only requires the document to be useful, which is the point of writing it.

What the document records instead

For each account: what the service is, what it controls, who owns it, the administrative contact address, and where access is managed. That is the half of the information that stays true. Passwords rotate; ownership does not.

This is not a weaker version of a credentials table. It answers a different and more durable question. A credentials table answers “how do I get in right now” and is wrong within months. An ownership record answers “whose account is this and who do I ask” and stays right for years.

Note the last row honestly: an ownership record is not nothing. It tells a reader which services a business depends on and who the administrators are, which is mildly useful to someone planning a phishing attempt. It is a very long way from handing them the keys, and the trade is worth making, but “harmless” is the wrong word for any document about a business.

How to move the credentials

Transfer access rather than passwords wherever the service allows it: invite the client as an owner or administrator on their own account and remove your access when the project ends. Where a shared login genuinely cannot be avoided, move it through a password manager’s sharing feature or another channel that expires, and never through email or chat.

Prefer transferring ownership

Most services the client depends on — analytics, search tools, business profiles, ad accounts, payment gateways, CMS logins — support named users with roles. When each person has their own login, there is no shared secret to hand over, removing someone is a single action, and the audit trail says who did what. The handover is then an invitation the client accepts, not a password you type into a document.

Where this is available it is strictly better, and it is available far more often than handover templates assume.

Where a shared login is unavoidable

Some hosting panels, older registrars and small third-party tools still have exactly one account. For those:

1. Use a password manager’s sharing feature if either side already has one. The credential stays in one place, access can be withdrawn, and nobody has a copy in a file. Password managers are a category worth adopting for this reason alone — which one is a separate argument, and not one this page needs to settle.
2. Or use a channel that expires. A one-time secret link that self-destructs after being opened, sent through a different channel from the one carrying the document.
3. Then have the client change it. The cleanest end state is that you no longer know the credential. Ask them to change the password once they have signed in, and record the date they did.
4. Note the transfer in the document, not the secret. “Hosting panel credentials sent separately on 14 March; client changed the password on 15 March” is the right level of detail.

The share links that are credentials

Some share links carry an access token in the URL itself, which means the link is the secret. A document with no passwords in it can still hand a stranger a client’s brand assets, design files or a folder of contracts, simply because someone pasted a link into it.

This is the rule that survives the rule, and it catches careful people. Links from file-sharing and design tools set to “anyone with the link” carry their access in the address. There is no login prompt, no audit trail, and no way to tell from the document that the link is any different from a link to a public website.

What to do about it, in order of preference:

• Record where the file lives rather than linking to it. “Brand assets in the client’s shared drive, Marketing › Brand” is a location. It requires the reader to already have access, which is the point.
• If a link is genuinely needed, use one that requires sign-in. Share to named people rather than to anyone with the link, so the address on its own is worthless.
• Review link-shared assets when the relationship ends. They are the most commonly forgotten form of access, because nobody thinks of a link as access.

Shared logins, leavers, and being able to revoke

The practical test for any access arrangement is how quickly one person can be removed from it. Named accounts pass that test in a single action. A shared password fails it, because removing one person means changing the credential and redistributing it to everyone else.

This matters most at the two moments a handover exists to survive: someone leaves the agency, and the client engages a different agency. Both are ordinary, and both should be a five-minute administrative task rather than a project.

Two habits make that true. Use named accounts wherever the service supports them, and put an annual “review who still has access” row in the maintenance schedule with a named owner. That review is the only thing that catches the accounts nobody thought about — the contractor added for one job, the old staging login, the analytics access granted to an agency that stopped working with the client two years ago.

What to ask the client to do

Three things: accept the ownership transfers rather than leaving the invitations pending, change any shared password once they have signed in, and keep their own credentials somewhere they will still have them in two years.

The first is the one that quietly fails. An invitation sent is not an ownership transfer; it is an email in somebody’s inbox. Check that each one was accepted before you record it as done, because “transferred” in a handover document is a claim you may have to stand behind later.

The third is worth raising even though it is not your responsibility. A client who keeps their logins in a notebook or a browser they later replace will be locked out of their own business eventually, and the call will come to you. Suggesting a password manager once, at handover, is a reasonable thing to do and costs a sentence. Where they store their credentials afterwards is theirs to decide.

How Handover is built, and why

Handover has no password or API-key fields anywhere, by design. It records which accounts exist, what they control, who owns them and where access is managed — and the manuals it produces contain nothing to sign in with.

That is a deliberate constraint rather than a missing feature. A tool that stored agencies’ clients’ credentials would be carrying the security liability for every one of those businesses, and the whole point of the document is that it can be shared freely. Those two things cannot both be true.

It also means Handover is not a password manager and is not trying to be one. It sits on the other side of the line: the durable record of ownership and responsibility, with the secrets handled by tools built for secrets. The one place where care is still needed is the assets section, where a pasted share link can carry a token — so the app warns on the markers it recognises rather than pretending the problem does not exist.

Related guides

• Website handover checklist

  The full list to run through before a project closes, with credentials handled as a separate step.

  Read the guide

• Website handover template

  The eleven sections a handover document needs — including how to record an account without recording its password.

  Read the guide

• Domain & DNS handover checklist

  Registrar access is the most valuable login in a handover. What to record about it, and what not to.

  Read the guide