Accounts
Ilia Zavialov on the shared login, and what a small team puts in its place
A shared login is the cheapest decision a small team ever makes. One password, one license, everybody working by lunchtime. The bill arrives later, on the day somebody leaves in a hurry or a payment lands in an account nobody recognizes, and it arrives in full. Ilia Zavialov treats the shared account as an operational question with a measurable price: what does an organization lose at the moment it can no longer say who did what. The answer runs through attribution, revocation and recovery, and through every procedure that quietly depends on all three.
English version for the United States.
01
The saving that is booked in advance
Shared logins are rarely decided on. They accumulate. A tool is needed on a Tuesday, one seat costs less than four, and the fastest way to get three people working is to drop a password into the group chat. Nobody writes the moment down, because at the time it does not feel like a decision. Six months on, that same password opens a service holding invoices, client addresses and a stored payment method.
What travels is never only a password. With it goes the mailbox that receives the reset link, the phone that receives the code, and the habit of pasting credentials into whichever window happens to be open. Copies settle into chat history, personal notes and a spreadsheet somebody exported once for convenience. Within weeks the organization has lost count of how many copies exist, and that count only grows.
The saving is genuine. A small team on a single license pays less every month, and for a long stretch nothing at all happens. The whole cost is deferred to one day and settled there: the day a person leaves on bad terms, a laptop disappears, or money moves somewhere unfamiliar. Seen that way, a shared account is a loan taken against an incident that has not occurred yet, at an interest rate nobody has calculated.
02
Attribution: a log that names nobody
Every serious service keeps a log. It records the time, the address, the action and the account. Under a shared login it records the account and stays silent about the person, which turns any inquiry into a conversation about who was probably at their desk that afternoon. Memory and calendars become the evidence, and both are weak.
Two things break at once. An honest mistake cannot be traced to its author, so the same mistake will be repeated by the same person for months. A deliberate act cannot be attached to anyone, so it cannot be proved, cannot be disciplined and cannot be reported with confidence to a bank or an insurer. Small teams discover the second problem exactly once, usually at the worst possible moment.
The quieter damage falls on the people who did nothing. Where five colleagues hold the same password, suspicion spreads evenly across all five, and none of them has any way to clear their name. Trust inside a small team is a working asset, and an unattributable log spends it fast. Named access protects careful staff at least as much as it exposes careless ones.
03
Revocation: the password everybody already knows
Removing one person from a shared account means changing a credential that the whole team uses. That is a coordinated operation: someone has to generate the new password, distribute it, update the saved copies, and handle the two colleagues who are on holiday. Because it is an operation, it gets scheduled. Because it gets scheduled, it slips.
Slipping becomes permanent quickly. Former contractors keep working access for months, simply because no calm hour ever appeared for the rotation and nobody owned the task. Most of the time nothing comes of it, and that quiet is precisely why the habit survives. Access that outlives the relationship is the single most common finding in a small business review.
A revocation routine should be measured in elapsed minutes, and measured honestly. A procedure that needs an afternoon will never be run at seven on a Friday evening, which is when leavers actually happen. If closing one person's access cannot be done by one administrator in a few minutes without disturbing anybody else, the access model itself is the thing to change.
04
Recovery sits on somebody's personal phone
The password is the visible part. Underneath it sit the recovery channels: a second factor in an authenticator app, a phone number for codes, a backup mailbox for reset links. In most small teams all three belong to whoever set the account up, usually the founder or the first employee to need the tool.
That arrangement holds until the person is unreachable. Illness, a lost handset, a resignation or a dispute is enough to leave an organization locked out of its own advertising account, its own domain registrar or its own payment dashboard. Support desks are reluctant to help, and they are right to be, because from the outside the request looks exactly like an attempted takeover.
There is a short test for ownership. Ask whether the company could recover this account tomorrow without the cooperation of any named individual. If the answer requires a person, the account belongs to that person and always did. Recovery channels pointed at company controlled addresses, with a second administrator on every critical service, cost almost nothing to set up and are close to impossible to retrofit during a crisis.
05
The shared inbox as a target
Attackers care very little about which tool a team uses. They care about the accounts that can authorize money or speak in the organization's name, and a shared mailbox does both while belonging to nobody in particular. Ownerless accounts are attractive because no single person feels responsible for reading their security notifications.
The scale is documented. For 2025 the FBI Internet Crime Complaint Center recorded 1,008,597 complaints and losses of almost 21 billion dollars, twenty six per cent above the previous year. Business email compromise alone accounted for 3.046 billion dollars and stood second among all reported categories. The Federal Trade Commission counted more than a million impersonation reports over the same period, with 3.5 billion dollars lost, close to one report in every three.
Impersonation of companies made up around a billion dollars of that figure, and the heaviest individual losses came from callers presenting themselves as staff at the victim's bank. The mechanism is unglamorous. Someone reads a mailbox long enough to learn how invoices are phrased, waits for a real payment, and sends a correction to the bank details from a familiar looking address. In a shared inbox that correction can sit unquestioned for days, because each reader assumes a colleague has already dealt with it.
06
When a familiar voice stops being evidence
Small organizations run on recognition. People know how a colleague writes, how the director sounds when in a hurry, which supplier always calls before sending an invoice. This informal layer of verification carried most teams through the last two decades and required no policy at all.
That layer has thinned. A convincing clone of a voice can now be assembled from a recording of about three seconds and reaches roughly eighty five per cent accuracy. In one experiment listeners separated a genuine voice from a synthetic one in 37.5 per cent of attempts, worse than guessing. Voice phishing built on cloned audio grew by 1633 per cent within a single quarter, which is the shape of a technique moving from demonstration to routine use.
The operational answer is dull and effective. Any instruction that moves money or changes access gets confirmed on a channel the caller did not choose, at a number held in the organization's own records. The rule has to apply to everyone, founders and directors first, because an exception granted to authority is exactly what the caller is imitating. Call center operations combining fake technical support with impersonation of government services produced over 80,000 complaints and more than 2.9 billion dollars in reported losses, and every one of them relied on a person trusting a voice.
07
Named accounts and the size of a role
The replacement for a shared login starts with one account per person wherever the service supports it. That much is obvious and usually gets done. The part that gets skipped is sizing the role: an accounts assistant who needs to raise invoices receives the permission to raise invoices and nothing further.
Administrative rights deserve to be treated as a temporary state. Someone needs them to configure a service, and after configuration the same person can work perfectly well with an ordinary role. In a team of six this discipline takes a few minutes a month and shrinks the blast radius of every future compromise, because an attacker inherits only the permissions of the account they actually reached.
The cost objection is honest and worth answering plainly. Individual seats cost more than one shared seat, sometimes several times more, and for a small budget that is a real constraint. The comparison to make is with the working days lost to reconstructing an incident nobody can attribute. Where the budget genuinely does not stretch, the shared credential belongs in a vault with a named owner and a review date, recorded as a deliberate exception with a review date in the diary.
08
The vault, and access as a grant that can be withdrawn
Plenty of services still offer a single user and no roles at all, particularly older suppliers and local utilities. For those the password lives in a shared vault, and the vault entry becomes the unit of access. People receive entries, use them through the vault, and never learn the underlying string by heart.
The difference shows up on one specific day. Withdrawing a vault entry takes effect immediately, because the person never held the secret independently. Withdrawing a password that was pasted into a group chat has never worked, since every copy that was ever made remains valid until the credential is rotated. This is the whole argument for a vault, and it does not depend on which product is chosen.
Around the vault sit three habits that keep it useful. Credentials never travel through chat, e-mail or documents, so the vault stays the only distribution channel. Anything a leaver could have memorised is rotated on their last day, and the leaver checklist says so explicitly. A sealed emergency credential exists for the case where the vault itself is unavailable, kept offline, and its use is logged and reviewed afterwards.
09
The register that makes the leaver routine possible
None of the above survives without a record of who holds what. The register that works has five columns: person, service, role, date, and who approved. It lives where the people who grant access already work, and editing it requires no approval of its own, because a register with a gatekeeper stops being updated within a month.
The trigger matters more than the format. The line is written at the moment access is granted, by the person granting it, in the same minute. Written later it will be written never, since the memory of a routine grant lasts about a day. Teams that get this right tend to be the ones who added the register to the same checklist that already covers a new starter's equipment.
The register earns its keep twice. It turns a departure into a scan of a table, which is how a leaver routine finishes inside a few minutes on the final day. It also supports a quarterly comparison against reality, where surplus access is closed and forgotten subscriptions surface. Running that comparison once with the whole team present is the fastest way to find out how much access the organization had stopped tracking.
10
Where a shared account is still reasonable
There is a narrow case where sharing costs nothing. Read only access to material that is neither confidential nor actionable, a public status board or a subscription to an industry news service, carries none of the three problems. Nobody can spend from it, nobody can speak from it, and losing it would be an inconvenience.
The boundary is drawn by capability. Anything that can move money, send messages in the organization's name, change access for others or reach customer data falls outside the exception at any team size, including a team of two. Size changes the volume of the consequences and leaves their nature untouched, which is why the same rule fits a partnership and a company of forty.
The workable version of this policy is written down and short. Exceptions are named, each one has an owner and a date, and they are read through at the same quarterly review as the register. That single habit is what keeps an exception from quietly becoming the standard, which is how most shared logins were born in the first place.
| Question on the day of an incident | One shared login | Named accounts with roles |
|---|---|---|
| Who performed this action | Cannot be established from the log | Recorded against a person |
| Closing access to one person | Rotate a password the whole team uses | Disable one account |
| Realistic time to revoke | An afternoon of coordination | A few minutes |
| Account recovery depends on | A personal phone and inbox | An owner inside the organization |
| Reach of a compromise | Everything the login opens | Only the role that person held |
| Monthly license cost | One seat | One seat per person |
| Cost after an incident | Days of reconstruction | A short review of the log |
Questions and answers
Why do shared accounts break?
They remove the link between an action and a person, which disables attribution, revocation and recovery at the same time. Nothing goes wrong for months, and then all three failures arrive together on the day of an incident.
Is a shared account ever acceptable in a small team?
Yes, for read only material that is neither confidential nor actionable, such as a public dashboard or a news subscription. Anything that can move money, speak in the organization's name or reach customer data falls outside that exception at any team size.
What do you do when a service offers no user roles?
Keep the credential in a shared vault with a named owner, so access is granted and withdrawn as a vault entry. Rotate the password when anyone with that entry leaves, because a memorised secret cannot be revoked.
How should access be removed when an employee leaves?
Work from the access register, disabling named accounts and withdrawing vault entries in one pass on the final day. Rotate every shared credential the person could have memorised, and record the time the pass was completed.
Can you trust a phone call from a colleague asking to change payment details?
Confirm it on a channel the caller did not choose, using a number from the organization's own records. A convincing voice clone can be built from about three seconds of audio, and in testing listeners identified synthetic speech in only 37.5 per cent of attempts.
Is it worth paying for a separate seat for every employee?
Compare the monthly difference with the working days spent reconstructing an incident that nobody can attribute. Where the budget genuinely will not stretch, put the shared credential in a vault with an owner and a review date, and treat it as a documented exception.