How should I share credentials with a contractor?

Issue a separate credential in their name wherever the system supports it, rather than sharing an existing one. Deliver it through a one-time secret link that expires, sent on a different channel from the one carrying the project work, and record the access so it can be revoked on the agreed end date.

Should I add a contractor to my password manager?

Only for longer engagements, and only in a vault scoped to that project. Most password managers support guest or limited-member access. For a short piece of work involving one or two credentials, the setup cost outweighs the benefit and a one-time link is the better fit.

What is the safest way to give a contractor access to a client account?

Ask the client to create an account for the contractor directly, so the credential belongs to the contractor and can be removed without disturbing anyone else. Where the platform has no multi-user support, use a one-time link with a passphrase sent separately, and change the password once the work is finished.

How do I revoke contractor access when the work ends?

Work from a written list made at the point access was granted, not from memory at the end. Delete or disable the accounts and keys issued to them, and change any shared password they were given. Offboarding is reliable only if onboarding recorded what to undo.

Is it safe to send credentials to a contractor by email?

No. The credential then lives in your sent folder and their inbox indefinitely, often on a device and mail account you have no visibility into, and it typically remains there long after the engagement ends. Use a delivery method that expires.

What should go in the contract about credentials?

State who owns the accounts created during the work, that credentials must not be reused or stored outside an approved password manager, that access ends on a stated date, and that any suspected exposure must be reported immediately. Clear expectations prevent most disputes and make revocation uncontroversial.

How to share credentials with contractors

Sharing a credential with a colleague is a solved problem: put it in a shared vault and move on. Contractors break that model in two ways. They start outside your password manager, and unlike an employee, their access is supposed to end. Handle the first and forget the second and you accumulate live credentials belonging to people who stopped working with you a year ago.

What follows is a process that survives contact with a real engagement.

1. Issue, do not share

Before thinking about how to transmit a credential, ask whether you need to transmit an existing one at all. Most systems that matter support multiple users:

Cloud platforms and SaaS: invite them as a user with a scoped role.
APIs: generate a key for them, not a copy of yours.
Servers: their own account and their own SSH public key.
Databases: a user with the permissions the task needs, nothing wider.
Repositories: a collaborator invitation, not the deploy key.

An issued credential is revocable in isolation. When the engagement ends you disable one account and nobody else is disturbed. A shared credential has to be changed for everyone, which is why in practice it never is.

This is also the answer to the awkward case where a contractor works for several clients at once. A credential in their own name creates a clean audit line. A shared one does not.

2. Scope it to the work and give it an end date

Grant the narrowest access the task requires. A contractor building a reporting view needs read access, not an admin role. This is not about trust - it is that narrow access limits what a mistake can cost, and contractors work in unfamiliar systems where mistakes are likelier.

Where the platform supports expiring tokens or time-limited invitations, use them. An expiry that fires on its own is worth more than a reminder you intend to act on.

3. Hand it over through something that expires

For the credentials you genuinely have to transmit - an initial password, an API key, a certificate - the delivery method matters, because a contractor's inbox is somewhere you have no visibility into and no ability to clean up.

Use a one-time secret link. The credential is encrypted, readable once, and deleted afterwards, so nothing accumulates on either side. It also needs no account, which matters when the recipient is not in your systems and has no reason to sign up for anything to receive one credential.

Two habits make it substantially stronger:

Send it on a different channel from the work. If the project runs in email, send the link by text message.
Add a passphrase and send that a third way. Agree it on the kickoff call. Now two unrelated channels have to be compromised rather than one.

If the recipient reports that the link has already been viewed, treat that as a signal rather than a nuisance: reissue the credential instead of resending the same one.

4. Write down what you granted, while you are granting it

This is the step that gets skipped, and it is the one that makes the ending work. At the moment you create access, record it - a shared document, a ticket, a line in the project notes:

What was granted, and on which system.
Whether it was issued to them or shared from an existing credential.
Who granted it and when.
The date it should be removed.

Reconstructing this from memory three months later is unreliable in a way that matters: the credential you forget is by definition the one nobody is watching.

5. Put the expectations in the contract

Short and specific beats long and legalistic. Four points cover most of it: accounts created during the work belong to you or your client; credentials are not to be reused or stored outside an approved password manager; access ends on a stated date; suspected exposure is reported immediately rather than quietly fixed.

The value is less in enforcement than in the fact that revoking access at the end becomes routine rather than a gesture of distrust.

6. Offboard on the date, not eventually

Take the list from step 4 and work through it:

Disable or delete accounts issued to them.
Revoke their API keys and tokens.
Remove their SSH keys from any server they touched.
Change any password that was shared rather than issued.
Remove them from repositories, shared vaults and chat workspaces.

Do it on the agreed date even when the relationship is good and you expect to work together again. Re-granting access takes minutes; discovering a forgotten live key during an incident takes considerably longer, and by then you are explaining it to someone else.

A short worked example

A contractor is joining for six weeks to work on a client's site.

The client invites them to the hosting platform as a user with deploy rights only.
You generate an API key in their name for the analytics service and send it as a one-time link by text message, with the passphrase agreed on the kickoff call.
The legacy CMS has one shared login and no multi-user support, so you send that by one-time link too, and note that it must be changed at the end.
All three go into the project notes with an end date.
Six weeks later you disable the platform user, revoke the analytics key, and change the CMS password.

Nothing here is difficult. What makes it work is that the ending was planned at the beginning, when you still knew exactly what you had handed over.