A web agency quickly handles dozens of logins: WordPress, Shopify, PrestaShop, hosting, domains, analytics, advertising platforms, CRM, email marketing, and support tools. The challenge is not merely storing them. You need to know which client owns them, who can use them, and how to remove access without disrupting the project.
A lightweight process is often enough to remove passwords scattered across Slack, Teams, email, and shared documents.
The three most common mistakes
One account is used by the entire agency
A generic account shared by every team member makes actions harder to attribute and departures harder to manage. When supported, create named accounts and assign suitable roles such as administrator, editor, analyst, or support.
Passwords are stored in the wrong tool
A task manager or messaging platform is not designed to manage a secret’s lifecycle. A password pasted into a ticket may be indexed, exported, or visible to people who are not working on that project.
Access is created but never removed
The end of a project, replacement of a freelancer, or departure of an employee should trigger a review. The CNIL recommends documenting onboarding and offboarding procedures, applying least privilege, and removing permissions as soon as they are no longer required.
Build a useful inventory, not a forgotten spreadsheet
For every client, list the services that are actually used. Each access record should include at least:
- a name everyone on the team understands;
- the exact sign-in address;
- the relevant client or project;
- an accountable owner;
- the authorized people or groups;
- a last-review date for sensitive access.
Avoid labels such as “Client admin” or “Main account.” Prefer “Shopify store — production — Client X” or “Google Ads — agency — Client Y.” A stable convention improves search and reduces mistakes.
Organize access by client and role
A good structure separates the agency’s internal vault from credentials owned by clients. Within each client space, groups can represent the teams that are actually involved: project, development, acquisition, or support.
Do not automatically grant every credential to every member. A developer working on a WordPress fix does not necessarily need the client’s bank, CRM, or advertising-console account.
When should you use an individual account or controlled sharing?
| Situation | Recommended solution |
|---|---|
| The service provides complete role management | Create an individual account |
| A common account is required | Share it through a revocable vault |
| The contractor only needs to sign in | Use connection-only access |
| Critical administrator access | Restrict it, enable MFA, and track changes |
Connection-only sharing reduces password disclosure, but it must not grant more permission than necessary on the target website. Native roles remain the first control when they are available.
A process for every new project
- Name the owner: the client should know who controls the main account.
- Collect securely: avoid sending passwords in chat and add them directly to the intended vault.
- Classify: associate each credential with the client and correct sign-in address.
- Assign: grant access only to the relevant people or groups.
- Test: verify autofill and recovery before an emergency occurs.
- Plan the exit: document what will be transferred or revoked at the end of the contract.
Monthly checklist for agency managers
- Completed projects no longer have unnecessary active shares.
- Former collaborators have been removed from groups.
- Critical accounts have MFA and controlled recovery methods.
- Duplicate credentials and credentials without an owner are corrected.
- Passwords disclosed during an incident or support session have been changed.
- The client can recover access without depending on one person at the agency.
How MYKEYNEST helps an agency
MYKEYNEST combines a vault, groups, secure sharing, and browser autofill. Agencies can organize credentials by team, pin frequently used accounts, and revoke a share when a contractor’s scope changes.
The goal is not to add a heavy process. It is to replace improvised exchanges with a workflow simple enough that people actually use it.
