The Shared Login: Why One Password for the Whole Shop Breaks Everything Else
One login for the shop, one for the store, one for the branch — passed between shifts and written inside a drawer. It is the most common security arrangement in Kenyan SMEs, and it silently disables every other control you have paid for.
It starts as a licensing decision and becomes an operating arrangement. Rather than five accounts, the shop gets one — "shop1" — and everyone on the counter uses it. The password is short enough to remember, shared verbally, and eventually written somewhere near the till because a new person started on a Saturday and nobody senior was available.
Nothing about this is stupid. It is a rational response to per-user pricing, to staff turnover, and to the friction of onboarding somebody for a three-week trial. But it has a consequence that is rarely made explicit at the time: it converts your system from a record of what individuals did into a record of what a location did. And almost every control you might later want depends on the first thing.
The two other halves of this problem
Shared logins are one of three account risks that reinforce each other. The other two — passwords that are one breach away from public, and accounts belonging to people who left — are covered in logins, MFA and the leaver problem, which is also where the distinction between an employee record and a user account is worked through properly.
What a shared login actually costs
The cost is not primarily a break-in risk, though that exists. The cost is that a whole category of question becomes permanently unanswerable, and you find out which questions those are at the worst possible moment.
With one login per location
- The audit log says "shop1" did it — which is a place, not a person
- Till variance cannot be attributed, so it gets absorbed
- A discount or refund pattern belongs to nobody
- Roles are meaningless — the shared account needs every permission anyone needs
- A leaver still knows the password, and so does everyone they told
- A data protection question about who accessed a record has no answer
- Nobody can be cleared, which is worse for honest staff than for anyone else
With one login per person
- Every action carries a name, which is what an audit trail requires
- Variance is per cashier, so a pattern is visible in a month
- Refunds and discounts are attributable without an investigation
- Roles work — each person gets what their job needs and no more
- A leaver is deactivated once and access ends
- Access to personal data can be shown per person
- Good work is visible too, which is the half nobody mentions
The last point on the right deserves more attention than it gets. Individual accounts are usually sold as accountability, which staff correctly hear as surveillance. But the same specificity that attributes a shortage also attributes a clean six months, the fastest counter, the person whose counts always tie. A shared login flattens performance as thoroughly as it flattens fault.
A shared login does not just prevent you from finding out who caused a shortage. It prevents you from clearing everybody else — which is a cost your honest staff pay.
The three things to fix, in order
Account security in a small business does not need to be sophisticated. It needs three ordinary things done deliberately, in this order, because each one makes the next one meaningful.
-
One person, one login — including the temporary staff
This is first because nothing after it works without it. The awkward cases are casuals, trial hires and the person covering a shift at short notice, and the answer is that creating an account has to be fast enough that nobody is tempted to skip it. If your licensing punishes this, that is a commercial conversation worth having explicitly rather than absorbing as a security compromise.
-
Multi-factor authentication, set to required rather than recommended
A password shared once is shared forever, and a password written near a till is public. A second factor on a phone makes a leaked password insufficient on its own. Set as an organisation-wide requirement it applies to everyone; left as a recommendation it applies to the two people who were going to do it anyway.
-
A leaver process that ends access the same day
Not eventually, not at the next review. Dormant accounts belonging to people who no longer work for you are the most attractive thing on your system, and the person who left is the one who knows exactly what it can do.
The uncomfortable question worth asking today
How many active accounts do you have, and how many people work for you? If the first number is larger, the difference is your exposure and it needs no further analysis. If the first number is much smaller, you have shared logins whether or not anyone has described them that way.
The controls available beyond a password
Once individual accounts exist, a handful of further controls become worth turning on. Each is a setting rather than a project, and each is off or permissive until somebody decides otherwise.
| Control | What it does | When it is worth it |
|---|---|---|
| Organisation-wide MFA requirement | Every user must have a second factor before they can work | Always, and particularly once anyone can approve a payment |
| MFA reminder period | Nudges users toward setup while the policy is still recommended | During the transition, before you switch to required |
| IP restriction | Access only from addresses you list | A single fixed-line office; painful for field or remote staff |
| Device tracking | Each device fingerprinted and visible, with lock and revoke | Anywhere staff use their own phones — which is most places |
| Session timeout | An idle session ends rather than sitting logged in | Shared physical terminals, shop floors, front desks |
| Failed-attempt logging | Repeated attempts against one account become visible | Always — it costs nothing and is the earliest signal you get |
IP restriction deserves a caution rather than a recommendation. It is genuinely strong for a business that operates from one office with a fixed connection, and it is actively harmful for one with field staff, branch managers on mobile data, or anyone working from home — because the failure mode is a locked-out user at the worst moment and a support call to remove the control entirely. Turn it on only where the network reality is stable.
What the product enforces, and what it leaves to you
What AWRA OpsHub does today
- Multi-factor authentication with an organisation-wide policy that can be set to required, in which case users are routed to set it up before they can continue, with a configurable reminder period while it is still recommended.
- IP allowlisting per organisation, which refuses access from any address not on your list once the list is non-empty.
- Device fingerprinting — each device is recorded per user and can be locked or revoked, which logs the user out.
- Idle session timeout with a logout and a redirect to login rather than a silently expired page.
- Failed authentication logged with the reason, so repeated attempts against one account are visible rather than invisible.
- Deactivation that ends access properly, clearing sessions and API tokens rather than waiting for expiry.
- Support impersonation logged as a distinct event type, so access by us on your behalf never blends into your own staff's activity.
- Sensitive personal fields encrypted at the application layer — bank account names and numbers, mobile money numbers, statutory identity numbers.
What it does not do
- No detection of a shared login. Nothing notices that one account is used from four devices in three places by different people. This is the single biggest security weakness in most Kenyan SMEs and the product cannot see it — only your own account count against your headcount will tell you.
- No automatic lockout after repeated failed attempts as a configurable per-organisation policy. Failures are logged; the response is yours.
- No password policy you configure per organisation — no minimum length, complexity or rotation rules you set yourself.
- No time-bound access. A temporary account for a three-week casual has no expiry and will not deactivate itself.
- No enforced leaver process. Deactivation is an action somebody takes; nothing chases you when an employee record is marked as having left.
The first and last items in that column are the same problem in two forms: the security of your accounts is a function of a human process, not a setting. An account created for a casual worker in 2024 and never closed is invisible to every control listed on the left, because as far as the system is concerned it is simply a user who has not logged in for a while.
Making individual accounts actually stick
The reason shared logins survive good intentions is friction. Every arrangement below reduces the friction rather than appealing to discipline, which is why they work.
- Make account creation a thirty-second task for a named manager, not a request to head office. If onboarding a Saturday casual requires somebody who is not there on Saturday, the shared login will be used.
- Create the account when the person is hired, not when they need the system. The gap between those two events is where "just use shop1 for now" is born, and "for now" is permanent.
- Tie deactivation to the leaver process rather than to memory. Whoever handles the exit handles the account, on the same checklist — see employee records and contracts.
- Explain the accountability honestly rather than obscuring it. Staff know that individual logins make actions attributable. Saying so directly — including that it works both ways — is more durable than presenting it as a technical requirement.
- Count your accounts against your headcount quarterly. Two numbers, once a quarter. It is the only reliable detector of both shared logins and dormant leavers.
Why this is upstream of everything else
Individual identity is the prerequisite that the rest of this category assumes. Access control allocates permissions to people, which requires people to be distinguishable. The audit trail is only as specific as its identities. Till variance attributed to a location tells you nothing you can act on. And a data subject access request under the Data Protection Act asks who accessed a person's records — a question a shared account cannot answer at all.
Which is why, of everything in this category, this is the cheapest thing to fix and the one that unlocks the most. It costs the price of the accounts and an afternoon of process design.
Our take
Fix identity before anything else, because every other control assumes it. One person one login including the casuals, MFA set to required rather than recommended, and deactivation on the day someone leaves — those three, in that order. Be honest with staff that individual accounts make actions attributable, and equally honest that this is what allows anyone to be cleared. Then count your active accounts against your headcount every quarter, because nothing in the system will tell you that four people are sharing one login, and that is the weakness most likely to be present right now.
See the account security controls
Organisation-wide MFA enforcement, IP allowlisting, device fingerprinting with lock and revoke, idle session timeout, and failed authentication logged with the reason.
Explore security operationsFrequently asked questions
Is a shared login really that serious if we trust our staff?
The problem is not trust, it is that a whole category of question becomes permanently unanswerable. Till variance cannot be attributed and so gets absorbed; a refund pattern belongs to nobody; roles are meaningless because the shared account needs every permission anyone on that counter needs; a leaver still knows the password. And the group most disadvantaged is your honest staff, because nobody can be cleared — a shortage attaches to everyone who used the account.
Will the system tell us if an account is being shared?
No, and this is worth stating plainly because it is the most common weakness we see. Nothing detects one account used from several devices in several places by different people. The only reliable detector is arithmetic you perform yourself: count active accounts against headcount, quarterly. If accounts are far fewer than people, you have shared logins whether or not anyone calls them that.
Should we require MFA for everyone or just for finance?
Everyone, and set it as an organisation-wide requirement rather than a recommendation — a recommendation is adopted by the two people who were going to do it anyway. The reason to include the shop floor rather than only finance is that a counter account with a written-down password is the easiest way into your system, and once inside, the interesting question is what that account can reach rather than what it was intended for.
Is IP restriction worth turning on?
Only if your network reality is genuinely stable — one office, one fixed connection, no field staff. It is a strong control in that situation. For a business with branch managers on mobile data, field officers or anyone working from home it is actively harmful, because the failure mode is a locked-out user at a bad moment followed by a support call to remove the control entirely. A control that gets switched off in an emergency is worse than one you never enabled.
What happens to access when someone leaves?
Deactivation ends it properly — sessions and API tokens are cleared rather than left to expire — but somebody has to perform the deactivation, and nothing chases you when an employee is marked as a leaver. That gap is where dormant accounts come from, and dormant accounts belonging to former staff are the most attractive thing on your system because the person who left knows exactly what theirs could do. Put it on the exit checklist rather than relying on anyone remembering.
