Sam Na writes practical freelance security and workflow guides that help independent professionals handle client access without turning sensitive credentials into everyday messages and documents.
Contact: seungeunisfree@gmail.com
The safest client password is often the one a freelancer never needs to see, copy, paste, or send in the first place.
Secure password sharing with clients does not begin by finding a safer way to paste a password into a message. It begins by asking whether the password needs to be shared at all.
Freelancers regularly need access to systems they do not own. A designer may need a website administrator account. A marketer may need access to an advertising platform or social account. A developer may need a hosting panel, source repository, domain service, cloud environment, or analytics tool. A virtual assistant may work with scheduling, email, CRM, and document systems. Asking for access is normal. Turning a client's permanent password into ordinary email or chat content should not be.
There is an important difference between sharing access and sharing a credential. Many modern business services let the client invite another person, assign a role, grant permission to a workspace, or create a separate user account. In that situation, the client keeps control of the account while the freelancer signs in under an individual identity. The client can later remove that access without changing a password used by everyone else.
That is usually cleaner than a shared login because individual access preserves accountability. The service can often record which user made a change. Permissions may be limited to the work that person actually needs. When the project ends, the client's administrator can remove the freelancer instead of wondering who still knows a shared password.
Sometimes, however, the service does not provide delegation. An older website may have one administrator login. A specialized business tool may support only a single account. A client may use a system whose plan does not include additional users. In those cases, a shared credential may still be necessary.
That is where a shared password vault for a freelancer or another dedicated secure-sharing feature becomes useful. Instead of placing the password directly in an email, Slack message, project comment, text message, or document, the credential remains inside a purpose-built password system. The freelancer receives controlled access to the item or to a client-specific vault, depending on what the tool supports.
The important point is not that email or chat can never carry anything related to access. An invitation or a protected sharing link may still arrive through email or a messaging channel. The difference is that the reusable secret itself is not written into the conversation history as ordinary text. Where the sharing system provides controls such as named recipients, expiration, revocation, permissions, or access history, those controls can make the workflow easier to manage than a password copied into a permanent message thread.
The first question is not “How should the client send the password?” Ask whether the platform can invite you, delegate access, or create your own user account. Share the underlying credential only when the business system genuinely requires a shared login.
The UK National Cyber Security Centre recommends using delegation instead of shared accounts wherever possible. When a genuine business need for shared access remains, it recommends restricting the password to the smallest possible group, reviewing access, changing the password when someone should no longer have it, and considering a password manager that supports controlled sharing.
This guide turns those principles into a freelancer workflow. It explains how to ask clients for access without sounding overly technical, how to choose between an individual account, shared vault, and temporary secure share, how to keep different clients separated, what to do with MFA on a shared account, and how to remove access cleanly when the work ends.
Ask for delegated access before asking for a password
Access and password sharing are not the same request
When a project begins, freelancers often ask, “Can you send me the login?” That wording quietly assumes that the client's username and password must be transferred to another person. A better first question is, “Can this platform invite me as a separate user?”
Many business tools support individual accounts, team members, collaborators, administrators, editors, agencies, partners, guests, or delegated access. The exact label varies, but the principle is similar: the client authorizes your identity without giving you the password that controls the client's own identity.
This has several advantages. The client does not have to reveal a reusable secret. You can often use your own MFA. The service may record your activity under your user account. The client can reduce your permissions. Most importantly, removing your access later does not require every remaining user to learn a new shared password.
Separate user accounts preserve accountability
Shared credentials create ambiguity. If three people know the same administrator password and a setting changes, the platform may record the shared account name rather than the person who performed the action. That makes ordinary troubleshooting harder even when nobody has done anything malicious.
Individual accounts provide a clearer operational history. A client can see that one user published a page, another changed billing information, and another exported a report if the service provides appropriate logs. That accountability is useful during routine work, not only during security incidents.
NIST describes individual accountability as the ability to associate a user's identity with the time, method, and degree of access to a system. For a solo freelancer, you do not need enterprise identity software to benefit from that principle. Whenever a client platform can identify you separately, use that option before requesting the client's own credentials.
Ask for only the role you actually need
Getting your own login does not automatically mean you should receive full administrator privileges. If you need to edit website content, an editor role may be enough. If you manage advertising campaigns, the platform may offer campaign permissions without billing administration. If you upload files, you may not need permission to add or remove other users.
This is the principle of least privilege in everyday freelance language: ask for enough access to do the agreed work, but not more access simply because a broader role is easier to assign.
The rule protects both sides. The client's sensitive settings stay limited to people who need them, while you avoid responsibility for areas of the account that have nothing to do with the project.
Know when a shared login is genuinely unavoidable
Some services simply do not offer a second user. This is common with older tools, small niche services, certain device interfaces, or plans designed for a single operator. In that case, telling the client to “just create another account” may not solve anything.
Confirm the limitation rather than assuming it. Look at the service's user-management or permissions documentation. Ask the client whether the subscription has team features. If individual access is impossible or commercially unreasonable for the project, then treat the shared credential as an exception that requires a more controlled sharing method.
Client invites you as an individual user.
Your identity, permissions, MFA, and eventual removal can be managed separately from the client's login.
Client grants access without exposing the main credential.
Useful when a platform supports roles, partners, agencies, guests, editors, or other delegated permissions.
Use only when the platform requires it.
Treat the credential as a controlled exception rather than the standard way every client grants access.
Ask only for what the project requires.
A separate user account is most useful when its permissions are also limited to the actual work.
The cleanest form of client credential sharing is often not credential sharing at all. Use individual users, delegated roles, partner access, or guest accounts before asking a client for the password to an existing account.
Choose the right secure sharing model
Use a shared vault for recurring access
If a project requires a shared login for several weeks or months, a client-specific shared vault can be easier to manage than repeated one-time transfers. The credential stays in a password-management system, and the people who need access are granted access to the relevant item or vault according to the product's permission model.
This creates a central source of truth. If the client changes the password and the manager synchronizes updates to authorized users, everyone does not need a new message containing the latest version. If a freelancer no longer needs access, the client or vault owner can remove the person's vault access.
Do not assume that removal makes every previously visible secret unknowable. A person who had permission to reveal or copy a password may have copied it while access was active. If that matters at offboarding, the credential should be changed after access is removed.
Use temporary secure sharing for one-time handoffs
A full shared vault may be unnecessary when a client needs to provide one credential once. Some password managers offer encrypted item-sharing or secret-sharing features that generate a protected link instead of placing the password itself into the message.
Where your chosen service supports them, useful controls may include an expiration time, named recipients, email verification, a maximum number of views, manual revocation, or an additional access password. The exact controls vary, so read the current documentation for the tool rather than assuming every secure-sharing link behaves the same way.
The communication channel may still carry the link. The important distinction is that the ordinary email or chat history does not contain the reusable password in plain text. If the share is revocable or expires automatically, the access path can also have a shorter life than a permanent message.
Choose who should own the sharing system
For client-owned credentials, client ownership is often the cleanest long-term arrangement. If the client already operates a business password manager, ask to be added to the appropriate vault, collection, group, or guest access area rather than copying the credential into your own private system.
This makes offboarding simpler because the client retains administrative control. The client can remove you without depending on you to delete a copy later. The credential remains inside the client's operating system rather than becoming part of the freelancer's permanent personal archive.
If the client does not have a password-sharing system and the project requires one, agree on ownership before building a new vault. A freelancer-created vault may be practical for a small project, but the client should understand how credentials will be returned, transferred, changed, or deleted when the engagement ends.
Do not confuse encryption with unlimited trust
A secure sharing tool protects the transfer and storage process. It does not change the fact that the recipient is being trusted with access. If the recipient can view the password, that person may be able to copy it, write it down, or enter it outside the password manager.
That is why secure sharing should still follow the minimum-access rule. Share only the credential needed for the task. Do not expose a vault containing unrelated client systems simply because the sharing platform encrypts the vault.
Shared client vault.
Useful when authorized people need recurring access and the password may change during the engagement.
Protected temporary share.
Useful when one secret must be transferred once without creating a long-term shared vault relationship.
Join the client's workflow.
Avoid making a second unmanaged copy simply because you personally use a different password manager.
Agree on ownership first.
Know who controls the vault, billing, recovery, permissions, and final credential handoff before storing client secrets there.
Use a client-controlled shared vault for recurring shared credentials and a protected temporary sharing method for one-time transfers. The password should remain inside the credential system rather than becoming ordinary text in a permanent conversation.
Build a client vault around least access
Create a separate boundary for each client
A freelancer who works with several businesses should not build one giant vault called “Clients” and give multiple clients or collaborators access to it. The separation should follow the ownership boundary.
Client A's credentials belong in a place that Client B cannot reach. If a contractor helps only with Client C, that contractor should not receive credentials for Clients A, B, or D. The exact implementation may be separate vaults, collections, groups, guest areas, or another access-control structure supported by your password manager.
This is more than visual organization. It reduces the consequences of assigning the wrong person to the wrong group and makes offboarding easier because you know which access belongs to which relationship.
Keep the vault smaller than the project folder
A password vault is not a place to store everything related to a client. Contracts belong in the document system. Creative briefs belong in project management. Raw client data belongs in the storage environment appropriate for that data. A vault should contain the credentials and authentication information that genuinely need password-manager protection.
Keeping the vault focused also makes permissions easier to understand. If the vault contains only the three systems needed for the project, sharing that vault has a predictable meaning. If it contains years of unrelated credentials, API keys, private notes, financial data, and old project access, every invitation becomes harder to evaluate.
Do not copy more credentials than the freelancer needs
Clients sometimes respond to an access request by sending a large document containing every login they have. That may feel efficient, but it creates unnecessary exposure. A freelancer redesigning a website probably does not need the client's accounting login, payroll credentials, private mailbox, or payment processor administration unless those systems are specifically part of the work.
Ask for access in stages. Start with the systems required for the next task. Add another credential only when the scope requires it. This reduces the amount of sensitive material both sides have to manage.
The approach can also make clients more comfortable. Instead of saying “Send all your passwords,” you can name the exact platform and permission required for the current milestone.
Label ownership and purpose clearly
A credential titled only “WordPress” or “Hosting” may be difficult to understand six months later. Use labels that identify the client and the purpose without putting sensitive secrets into the title itself.
If several people have access to the vault, clear naming reduces the chance that someone edits or rotates the wrong item. It also helps during offboarding because the freelancer and client can quickly review what was actually shared.
Credentials for unrelated clients are not exposed through the same permission group.
The vault contains what the agreed work needs rather than every login the client owns.
It is obvious whether the credential belongs to the client, your own business, or another collaborator.
Someone reviewing the vault later can identify the service and purpose without opening several unrelated records.
You know who can add or remove people, change permissions, recover the vault, and transfer ownership when the engagement ends.
A shared password vault for freelancer access should be narrow and client-specific. Separate clients from one another, include only credentials needed for the work, and make ownership clear before additional people are invited.
Share access without putting the password in chat
Verify the access request before sending anything
A secure sharing tool cannot correct an incorrect recipient. Before a client sends a credential, both sides should know who requested the access, which account is being shared, and why it is needed.
This matters when the request arrives unexpectedly. An attacker who compromises a freelancer's email or impersonates a project participant may ask a client for “the login” in a way that looks routine. A client under deadline pressure may comply because sharing access is already part of the project.
For sensitive systems, verify unusual access requests through a known channel or established project contact. You do not need an elaborate ceremony for every low-risk tool. You do need enough context that the client is not sending a credential solely because an unfamiliar message said it was urgent.
Send the invitation or secure share, not the secret itself
Once the recipient and account are confirmed, use the platform's invitation system or the password manager's secure sharing function. The email or project chat can contain a message such as “I sent access through our password manager” or a protected share link generated by that tool.
Avoid following the secure link with the actual password in the next sentence “just in case.” That defeats the purpose of moving the credential out of the conversation history.
The same rule applies to screenshots. A screenshot of the password is still the password. It may be easier to send, but it can remain in chat history, device photo libraries, desktop downloads, automatic backups, and notification previews.
Use expiration and recipient restrictions when the tool provides them
Some secure-sharing systems allow the sender to choose how long a shared item remains accessible. Others can restrict access to a named email address, require verification, limit the number of views, add an access password, or let the sender revoke the share manually.
Use those controls when they fit the situation. A credential needed for a one-hour troubleshooting session does not require a share that remains open for several weeks. A secret intended for one person does not need to be accessible to anyone who obtains the link if the tool supports a more restrictive recipient setting.
If you use an additional password to protect a secure share, do not put both the protected link and its unlocking secret together in the same message if the product specifically supports separate-channel delivery. Follow the vendor's current instructions because secure-sharing designs differ.
Confirm access without asking the recipient to repeat the password
After sending the access, the client does not need to ask the freelancer to paste the credential back into chat as proof that it arrived. The useful confirmation is whether the freelancer can sign into the intended account successfully.
If the login fails, troubleshoot the account, permissions, URL, username, MFA requirement, or share settings without copying the password into a less secure channel. The point of a controlled credential workflow is to keep the secret inside that workflow even when setup becomes inconvenient.
Know which freelancer needs which account and why before granting access.
Create or invite an individual user instead of revealing the client's password.
Grant access through a shared vault or purpose-built secure-sharing feature rather than ordinary message text.
Use recipient restrictions, expiration, view limits, or other available controls when they match the project's needs.
Confirm successful access without pasting the credential back into email or chat.
Do not write the reusable password into an ordinary email.
The conversation can be forwarded, retained, indexed, backed up, or accessed later from another device.
Do not treat direct messages as a password vault.
Convenience does not provide the access controls, expiration, or credential management of a purpose-built sharing system.
A secure-sharing link can be the transport mechanism.
Use the recipient and expiration controls available in your chosen product and remember that some links themselves are sensitive.
Best for recurring access when a shared login is unavoidable.
Keep membership limited and review who can reveal, copy, edit, or share each credential.
Email and chat can coordinate access, but they should not become the credential store. Send an invitation or controlled sharing mechanism, keep the reusable secret inside the password system, and use expiration or recipient restrictions where available.
Handle MFA and recovery on shared accounts deliberately
Separate user accounts make MFA much easier to understand
MFA is another reason to prefer individual client accounts. If the client invites you as your own user, you can normally enroll the authentication method associated with your identity, subject to the platform's rules. The client's own authenticator remains private.
A shared login is more complicated. The account may have one password but an MFA code generated on one person's phone. If the freelancer needs to ask the client for a fresh code every time, the workflow quickly becomes inconvenient. That inconvenience often leads people to weaken MFA or move recovery information into unsafe channels.
Before sharing a login that has MFA enabled, decide how authentication is supposed to work. Check the service's supported methods instead of inventing a workaround.
Do not casually share recovery codes as if they are normal OTPs
A recovery code can provide an alternate way into an account when normal MFA is unavailable. It therefore deserves different treatment from an ordinary project message.
Do not paste a permanent set of recovery codes into a shared project channel simply because several people need occasional access. If the account is truly designed for multiple people, look for individual users, multiple authenticators, delegated access, or another officially supported multi-user workflow.
When the service has no better option, the client should decide how recovery credentials are controlled and who is authorized to use them. The solution should be documented enough that access can be restored without creating an uncontrolled copy in every team member's notes.
Do not disable MFA merely because sharing becomes inconvenient
A shared login can expose a design problem: the account was built for one person but several people now need it. Turning off MFA may make the workflow easier, but it removes an important layer of protection from the shared account.
Instead, reconsider the access model. Can the client upgrade to a plan with multiple users? Can the service register more than one supported authenticator? Can a password manager or identity system provide an approved workflow? Can one authorized person perform the sensitive action rather than distributing the entire account?
The goal is not to force MFA into an impossible setup. It is to avoid solving an access-management problem by weakening authentication without considering alternatives.
Assume a visible password can be copied
Some password managers provide controls intended to limit whether users can reveal or copy stored passwords. These can reduce casual exposure and help guide normal workflow. They should not be interpreted as a guarantee that a person who can use a credential can never capture it through another method.
Plan access based on trust and business need. If someone must never know or retain a privileged secret, the better solution is often a system that gives them delegated or mediated access without revealing the underlying credential.
If several people need one account, solve the multi-user problem before weakening the authentication.
Prefer individual accounts, supported delegation, or multiple authorized authenticators. Treat recovery codes as emergency credentials rather than reusable team passwords.
Shared credentials and MFA require an intentional design. Individual user accounts are easier to authenticate and revoke. When a shared login is unavoidable, follow the service's supported MFA model and keep recovery secrets out of routine project conversations.
Remove access and rotate credentials when the work ends
Offboarding should be part of onboarding
The easiest time to decide how access ends is before the freelancer receives it. When the project begins, record which accounts were granted, who owns them, how access was provided, and what should happen at completion.
That list does not need to be complicated. It may simply say that the freelancer has an individual website account, access to one shared marketing vault, and temporary access to a legacy analytics login. When the engagement closes, those three items create the offboarding checklist.
Without that record, clients often remember the obvious platform but forget secondary accounts provided months earlier.
Remove individual accounts instead of changing unrelated passwords
Delegated access pays off at offboarding. If the freelancer has an individual user account, the client can disable or remove that identity. The client's own password does not need to change solely because one collaborator left.
Review connected applications, active sessions, API access, personal access tokens, and other service-specific permissions when they are part of the project. Removing a visible user account may not automatically revoke every separate authorization the service issued.
The exact cleanup depends on the platform, so follow its official offboarding guidance for important systems.
Remove shared-vault membership, then evaluate password rotation
When a freelancer had access to a shared password vault, remove that person's vault access as part of project closure. Then ask whether the actual credential also needs to change.
If the freelancer could view or copy the password, changing the password after access ends may be appropriate because removing vault membership cannot erase a secret that may already have been copied. NCSC specifically advises changing a shared password when someone is no longer permitted to access it.
If the system provided delegated access without exposing the underlying password, a password rotation may not be necessary solely because the freelancer left. This is another practical benefit of individual identities.
Revoking a sharing link does not revoke knowledge already obtained
A temporary share link can stop future retrieval when it expires or is revoked. It cannot make a recipient forget a password already viewed or copied.
This distinction matters when choosing an offboarding action. If the secret was never accessed and the link is revoked, no credential change may be needed for that reason alone. If the recipient viewed the reusable password and should no longer be able to use it, changing the password is the reliable way to invalidate that knowledge.
After rotating the credential, update the authorized password system so remaining users receive the current version rather than keeping stale records.
Clean up your own copies too
Freelancers have responsibilities during offboarding as well. Remove client credentials from personal notes, browser storage, old exports, temporary files, test documents, and other locations created during the project if those copies are no longer authorized or required.
If the client owned the password vault, leaving the vault may handle much of the normal access automatically. Still review any exceptional copies you created during troubleshooting or migration.
Do not keep client credentials indefinitely because “they might hire me again.” If a future engagement begins, the client can grant current access through the proper process.
Use the onboarding list rather than relying on memory months later.
Disable or delete the freelancer's identity according to the service's normal offboarding workflow.
Revoke vault permissions and any temporary sharing links that are no longer required.
If someone who should no longer have access knew or could copy the credential, replace it and update authorized users.
Clean up temporary notes, browser saves, exported files, screenshots, or other unauthorized duplicates.
The client should verify that the former user's normal sign-in or delegated access no longer works where appropriate.
Access removal is not one button in every situation. Remove the person's account or vault permission, revoke temporary shares, and change reusable passwords when former users may still know the secret. Build this exit path into the project from the beginning.
Create a repeatable client-access workflow
Make secure access part of client onboarding
A freelancer should not have to invent a credential process every time a client says, “I'll send you the passwords later.” Include a short access step in your normal onboarding process.
Ask which systems the project requires. For each one, ask whether the service supports an additional user, delegated permission, agency access, partner access, or another role-based method. If it does, provide the email address or business identity the client should invite.
Only after those options are ruled out should you move to shared credentials. If the client already uses a password manager, follow that system. If not, agree on a controlled sharing method that fits the project.
Give clients a simple explanation, not a security lecture
Some clients will automatically paste a password into email because nobody has ever asked them to do anything else. Correct the workflow without making them feel careless.
A simple explanation is enough: “If the platform supports adding me as a user, please invite me instead of sending your password. If it requires a shared login, let's use a secure password-sharing method so the password does not remain in email or chat history.”
That tells the client exactly what to do and why without turning onboarding into a technical seminar.
Use one rule for unexpected credentials
Even with a good process, a client may suddenly paste a password into a message. Decide in advance how you will respond.
Move the workflow to the approved access method as soon as practical. If the credential is sensitive and has already been exposed in a channel where it should not have been stored, consider whether the client should change it after establishing the new access method.
Do not keep quoting or forwarding the original message, because that multiplies the number of places containing the secret.
Keep a lightweight access register
For complex projects, keep a list of systems you can access without writing the passwords themselves into that list. Record the service, owner, access method, permission level, and expected offboarding action.
For example, the record can say that a website uses an individual editor account, the advertising platform uses partner access, and one legacy service is stored in the client's shared vault. There is no reason for the project-management record to contain the actual passwords.
This gives you an operational map without creating a second credential database.
Review shared access when the scope changes
A six-month project can change considerably. A freelancer may start with website copy and later manage analytics. A subcontractor may join for one month. A client may replace an old platform with one that supports proper individual users.
When the scope changes, update access rather than automatically preserving everything that was granted before. Remove credentials that are no longer needed and replace shared access with delegated access when a better option becomes available.
The goal is not a perfectly static vault. It is an access model that continues to reflect the work people are actually authorized to perform.
Start with invitations, roles, delegation, or partner access.
Confirm that the service genuinely requires one reusable account.
Use a shared vault or protected share rather than email, project comments, documents, or ordinary chat messages.
Only people who need the account should receive access to the corresponding credential or vault.
Your project notes can identify what you can access without becoming another password database.
Know whether project completion means removing a user, revoking a vault, expiring a share, rotating a password, or several of these actions.
The easiest way to share passwords securely as a freelancer is to make client access a normal onboarding and offboarding process. Ask for delegated access first, keep unavoidable shared credentials inside a controlled system, and document how access will end before the project is finished.
Frequently Asked Questions
When the service supports it, the client should create or invite an individual user, guest, partner, agency account, or delegated role for the freelancer. This avoids revealing the client's own password and makes permissions and offboarding easier to manage.
A reusable password should not be treated as ordinary email content when a safer supported access method is available. Prefer an individual account, delegated access, a client-controlled shared password vault, or a purpose-built protected sharing feature.
A purpose-built secure-sharing link may use email or chat as the delivery channel, depending on the product's design. The important distinction is that the password itself is not written directly into the conversation. Use recipient restrictions, expiration, revocation, verification, or other available controls according to the sharing tool's current documentation.
For recurring access to a shared credential, a properly managed shared vault can provide a central credential record and clearer access management than repeatedly sending password updates. However, individual user accounts remain preferable when the underlying service supports them because they preserve separate identities and easier revocation.
Keeping client credentials separated is a useful default. The exact structure depends on the password manager, but unrelated clients should not receive access to the same collection of credentials simply because one freelancer works with both of them.
Remove the freelancer's user or vault access, revoke temporary sharing links, and review whether reusable passwords need to be changed. If the freelancer could see or copy a shared password and should no longer have access, changing that credential is an important offboarding step.
First check whether the service can provide individual users or support multiple authorized authenticators. Do not disable MFA simply because sharing is inconvenient. If the account truly must be shared, follow the service's supported MFA and recovery model and keep recovery codes out of routine project messages.
Move future access to the approved secure method rather than repeatedly forwarding or quoting the credential. For a sensitive account, consider whether the client should change the exposed password after the secure access method is established, especially if the message history is accessible to more people than intended.
Make secure access the easy default
Client credential sharing becomes much simpler when you stop treating every access request as a password-transfer problem.
First, ask whether the service can identify you separately. An invitation, guest account, editor role, agency connection, or delegated permission usually creates a cleaner relationship than sharing the client's main password. The client keeps ownership, your actions can be associated with your identity where the service supports logging, and your access can be removed without changing everyone else's credentials.
When a shared login is genuinely unavoidable, keep the secret inside a purpose-built credential system. A client-specific shared vault is useful for recurring access. A protected, expiring share can be more appropriate for a one-time handoff. Email and chat can coordinate the process or carry an approved secure-sharing link, but they should not become the permanent place where the reusable password itself lives.
Keep the scope narrow. Do not request credentials unrelated to the work. Do not mix unrelated clients in one broadly shared vault. Do not distribute recovery codes simply because several people share an account. Every person and every credential should have a clear reason for being part of the access model.
Then design the exit before the project ends. Individual users can be removed. Vault membership can be revoked. Temporary links can expire. Shared passwords can be rotated when former collaborators may still know them. Freelancer-side copies can be cleaned up instead of remaining in old browsers and notes indefinitely.
The final workflow is straightforward: request access, prefer individual identity, share secrets only when necessary, keep those secrets inside the credential system, and remove access deliberately when the business relationship changes.
That approach is not only safer. It is easier to explain to clients, easier to audit during a project, and easier to close cleanly when the work is complete.
Review the client accounts you currently access. For each one, ask a single question: “Could the client invite me as my own user instead?” Move any account that supports delegated access away from shared credentials. For the shared logins that remain necessary, place them in a client-specific secure sharing workflow and write down the exact offboarding action you will use when the project ends.
Sam Na writes BudgetFlow Studio guides for freelancers, consultants, creative professionals, and digital nomads who want practical systems for handling the operational side of independent work. His focus is on reducing unnecessary friction while keeping client access, credentials, project workflows, and business responsibilities clear enough to manage as relationships and tools change.
Contact: seungeunisfree@gmail.com
This guide provides general information about client account access and credential sharing for freelance work. The right approach can vary depending on the platform, client security policy, contract, industry requirements, password manager, authentication methods, and type of information involved. Before changing access to an important client system or handling regulated or highly sensitive credentials, review the service's current official documentation and the client's requirements, and seek appropriate professional or organizational guidance when needed.
The following official resources were used to verify the shared-access, individual-account, credential-management, and least-access principles discussed in this guide.
UK National Cyber Security Centre — Password Administration for System Owners NIST — SP 800-63B-4: Digital Identity Guidelines, Authentication and Authenticator Management Cybersecurity and Infrastructure Security Agency — Identity, Least Privilege, and Privileged Access Recommendations