🛡 Get audit

How Freelancers Should Store Client Passwords and API Keys Safely

Freelancers occupy an unusual position in credential management: you are effectively a one-person security team, often juggling logins and API keys across multiple clients’ systems, without any of the shared-vault infrastructure a full team would use. This guide covers the specific practices that matter for freelancers, building on our broader password manager comparison.

Why client credentials need separate handling from personal ones

Mixing client credentials into the same undifferentiated vault as your personal logins makes it harder to know exactly what access you are holding for which client, and complicates the process of securely returning or deleting that access once a project ends. Organize client credentials into separate, clearly labeled folders or vaults within your password manager — one per client — so you can see at a glance what access you currently hold and confidently clean it up when a project wraps.

Handling API keys specifically

API keys deserve the same careful storage as passwords, but are more often mishandled — pasted into a chat message, left in a code comment, or saved in a plain text file “temporarily” that never gets cleaned up. Store API keys in your password manager’s secure notes or dedicated fields just like a password, and never commit them directly into code, even in a private repository, since private repositories can still be accidentally made public or shared more broadly than intended.

When a client provides an API key, move it into your password manager immediately rather than leaving it in the original email or message where it was shared, and delete or archive that original message once the key is safely stored, reducing the number of places a sensitive credential exists at any given time.

Offboarding yourself from a completed project

When a client engagement ends, actively clean up your access rather than letting old credentials sit unused indefinitely in your vault. Delete client-specific entries you no longer need, and where the credential was something you had shared access to rather than your own individually created account, ask the client to revoke or rotate that access on their end as part of a standard offboarding conversation.

This protects both you and your former client: you are not carrying access you have no legitimate ongoing reason to hold, and if your own accounts were ever compromised later, that old client access is no longer available to be exploited through you.

What to do when a client insists on sharing a password insecurely

It is common for a client to simply email or message a plaintext password rather than using any secure sharing method. When this happens, immediately move the credential into your password manager and, where practical, suggest a more secure approach for future sharing — most password managers support sending a one-time, expiring secure link to share a credential, which is a small suggestion that meaningfully improves security for both parties on future projects.

Two-factor authentication across multiple client accounts

Managing two-factor authentication across several different clients’ systems can get unwieldy if not organized well. Use an authenticator app that supports organizing entries with clear labels (client name plus service) rather than a flat, unlabeled list that becomes hard to navigate as the number of client accounts grows. Where a client’s system supports it, prefer an authenticator app over SMS-based two-factor for the reasons covered in our two-factor authentication guide, which apply just as much to client-provided access as to your own accounts.

Keeping a personal audit trail as a solo operator

Without a team’s shared vault activity logs, freelancers benefit from keeping a simple personal record of which clients they currently hold access for and roughly when that access was granted. This does not need to be elaborate — a note within each client’s password manager folder stating when the engagement started is often enough. This habit pays off specifically during the offboarding step, making it easy to confirm you have addressed every credential associated with a wrapped-up project rather than relying on memory alone months after the engagement ended.

It also helps during a less common but real scenario: if a former client’s system is later compromised and they ask former contractors whether they still had access at the time, having a clear record of exactly when your access was granted and removed makes that conversation considerably easier to navigate confidently.

A simple system that scales as you take on more clients

1. Create a separate folder or sub-vault per client within your password manager.
2. Move any credential a client shares with you into the password manager immediately, deleting it from wherever it was originally sent.
3. Store API keys the same way, never in code, chat, or plain text files.
4. At the end of each engagement, review and clean up that client’s folder, and request the client rotate any shared credentials on their end.
5. Periodically review your full vault for old client folders that should have been cleaned up but were missed.

Frequently asked questions

Should freelancers use a business-tier password manager or a personal one?
A personal tier is generally sufficient for an individual freelancer with no need to share vaults with anyone else, since the primary value of business tiers — team sharing and centralized admin — is not needed by a single-person operation. Organization through folders within a personal-tier plan handles the client-separation need well.

What if a client asks me to use their company’s password manager instead of my own?
This is reasonable for credentials specifically belonging to that client’s systems, and many clients now expect this for security-conscious engagements. Continue using your own password manager for your personal accounts and any credentials not specifically issued through the client’s system.

How should I handle credentials for a client I am no longer actively working with but might return to later?
If there is a genuine, concrete possibility of returning, keep the folder but flag it clearly as inactive, and confirm with the client whether the access is still valid rather than assuming old credentials remain usable after a long gap.

For more on securing your freelance workflow, see our password manager comparison and shared vault guide.

Leave a Comment