Founder Tool Credential Hygiene: Who Holds Your Shared Passwords
Most founders can name the software their business runs on. Far fewer can say, without checking, who holds the admin password to each one, which personal email addresses are tied to billing, or whether a former contractor still has a working login. This gap rarely causes trouble on a quiet day. It causes trouble when someone leaves, when a payment method expires, or when a vendor asks for a verification step that nobody on the current team can complete. This article takes a narrower angle than general access reviews: it focuses on credential ownership, meaning the question of which human or role is the recorded holder of each login, recovery route and billing relationship. The aim is to produce a short, honest map that you can maintain without specialist tooling, and to ask the right questions of each vendor before you assume anything about how it handles accounts. Nothing here describes what TechBlast UK provides to its readers or operators; it is a general method you can apply to any software stack.
Separate the three things a login can mean
When people talk about a software account, they usually mix three different things together: the login a person uses day to day, the administrative rights that let someone change settings or add users, and the billing relationship that determines who pays and who receives invoices. These can sit with different people, and in small companies they often do. A developer might hold the admin role, a finance contact might be the billing email, and a founder's personal address might be the recovery route for both. Treating them as one thing is how ownership quietly disappears.
Start by writing a row for each tool with four columns: the day-to-day user model (individual logins, shared logins, or single sign-on), the admin holders by name, the billing contact, and the recovery route, meaning the email address or phone number that receives password resets. Most founders discover at least one tool where the recovery address belongs to a person who no longer works with them, or where the only admin is a generic address nobody monitors.
Find the shared and orphaned logins
Shared logins are not automatically a problem, but they are hard to audit because the vendor's records show one person when several people act. Where a tool offers individual accounts, prefer them. Where it does not, record who knows the shared credential, how it is stored, and when it was last changed. Storing it in a password manager with access limited to named people is a reasonable pattern, provided you can say who has access and can remove them.
Orphaned accounts are the more dangerous case. These are logins belonging to people who have left, to contractors whose engagement ended, or to test accounts created for a trial and forgotten. To find them, export the user list from each tool that offers one, then compare it against your current staff and active contractor list. Any mismatch goes on a removal list. Be cautious about deleting accounts that own shared content or workflows; in those cases, transfer ownership first, then remove access.
Check recovery routes before you need them
A recovery route is the path a vendor uses to confirm it is really you when you reset a password or request an account change. If that route points to a mailbox you no longer control, you may be locked out at the worst moment. A useful habit is to test recovery on a low-risk account once a year: request a reset, confirm you receive it, and confirm the mailbox is monitored by someone currently responsible for the business.
Also check whether any tool depends on a phone number tied to a personal device. Ask the question directly when you evaluate a vendor: what verification methods does the account support, can more than one named person complete them, and what happens if the only verified device is lost? The answers vary, and you should not assume a specific method is available unless the vendor's documentation says so.
Questions to ask every vendor before you rely on it
Before adding or renewing a tool, put a short set of questions to the vendor or read their documentation for the answers. Can admin roles be assigned to more than one person? Can billing contacts be changed without support intervention? Is there an audit log of administrative changes, and who can read it? How are accounts removed, and is removal immediate or does it depend on a support ticket? What happens to content owned by a user who is deleted? If the answers are unclear, record that uncertainty in your decision log rather than filling the gap with an assumption.
Be specific about what you are asking. A general claim that a tool is secure tells you little. A question such as whether a departed user's login can be disabled in one step, without contacting the vendor, is answerable and shows you whether the control exists.
A practical quarterly checklist
Run this list once a quarter, or whenever someone joins or leaves a role with access. First, confirm the admin holders for every paid tool are current staff. Second, confirm each billing contact is a role-based address or a named person who still works with you. Third, export user lists from tools that allow it and remove anyone who should no longer have access. Fourth, confirm each recovery address is monitored by a person currently responsible for that tool. Fifth, record any shared credentials and who holds them. Sixth, note any tool where you could not complete a step, and add it to the next quarter's list as an open item.
Keep the output short: one page with a row per tool and the date it was last checked. The value comes from repeating the exercise, not from a perfect first pass. A founder who runs this routine for a year will know more about their own dependencies than most companies several times their size.