Observable condition
The finance team shares one login for the bank portal, because logging in separately for each person was slow on pay day. The warehouse supervisor keeps administrator rights on the stock system, because he once needed to fix a stuck order at six in the morning and nobody wanted to repeat that call. A developer's personal credentials are embedded in a scheduled export, because setting up a proper service account would have taken a week. A password for the shared router lives on a sticky note, which is where the contractor found it last year.
Each of these arrangements began as a sensible response to a real problem. Work had to get done, and the secure way was slower, more awkward or required someone's approval. The shortcut was quicker, harmless on the day, and then permanent.
An illustrative example: a Pretoria services firm with seventy staff suffers a fraudulent payment instruction that appears to come from a manager's mailbox. In the review, nobody finds a sophisticated attack. They find a shared mailbox password last changed three years ago, no second step at sign-in because it "slowed the team down", and a former intern whose access was never removed.
Realisation
Most business security failures are not clever. They are ordinary arrangements that made someone's day easier and that no one later reviewed. The weakness was introduced by the business itself, in good faith, to remove friction.
The reason this goes unnoticed is that convenience is felt immediately and the cost is deferred. A shortcut saves two minutes every day and costs nothing until the day it costs a great deal. The people who chose it are rarely the people who pay.
The US Cybersecurity and Infrastructure Security Agency makes a related point about multifactor authentication: a second step at sign-in means that a stolen password alone is no longer enough. The extra step is also the one that many teams remove first, because it is the one they notice.
Realisation prompt: name one thing in your business that is done a slightly insecure way because the secure way was slower. When did anyone last look at it?
Identification
This is a pattern of convenience-driven exposure. The visible symptom is a collection of small workarounds: shared accounts, permanent access, unmanaged credentials and exceptions that never expire. The common assumption is that security failures come from outside attackers. The structural cause is that the business has made it easier to be insecure than secure, and has no routine for reviewing the shortcuts it has accumulated.
The Pattern the hidden risk of shared accounts and the Pattern when everyone has more system access than their job needs describe two frequent forms. This Pattern is about the cause underneath them: the working conditions that make the shortcut attractive.
Diagnosis
- The secure path is the slow path. If approvals, new logins or access requests take days, staff will find a quicker route, and they will be praised for getting the job done.
- Exceptions are granted but not retired. A temporary admin right, a disabled control or a shared password is given for a deadline. Nobody sets the end date, so the exception outlives the reason.
- Access accumulates. People change roles and keep old permissions. NIST's definition of least privilege describes giving a user only the access needed to perform their duties. In practice access is usually added far more often than it is removed.
- Credentials are tied to people, not purposes. Automated jobs, integrations and reports run on an individual's login. When that person leaves or changes their password, the job fails, so the password is never changed.
- Security is owned by no one in daily operations. IT is blamed when something goes wrong, but operational managers make the choices that create the risk, such as sharing a login to hit a deadline.
- Controls are judged by complaints. The NCSC's guidance on password administration for system owners treats the usability of a control as part of its design: a rule that people routinely work around is not providing the protection it appears to.
Commercial impact
The commercial value at stake is financial loss, regulatory exposure, business continuity and customer trust.
Direct loss is the most visible: payment fraud, ransom demands, stolen stock or data, and the cost of investigation and recovery. Because a shared or over-privileged account hides who did what, the business also loses the ability to establish what happened, which weakens insurance claims and disciplinary action alike.
In South Africa, the Protection of Personal Information Act adds a legal dimension. Section 19 requires a responsible party to take appropriate, reasonable technical and organisational measures to protect personal information in its possession. A breach that traces back to a shared password and an unreviewed leaver account is hard to describe as reasonable, and notification, investigation and reputational costs follow.
Continuity is another cost. An attack that locks the finance system for a week stops invoicing and payroll, however good the product is. Larger customers increasingly ask suppliers about access controls in procurement questionnaires, so weak basics can lose a contract before any incident occurs. The Impact page shared passwords, lost accountability and breach exposure sets out the financial side in more detail.
Common misidentification
The usual response after an incident is to buy another security product. The Impact page security products without basic controls explains why this disappoints: a monitoring tool does not help when the problem is that everyone knows the password. A second response is to issue a stricter policy and a warning email. A policy that makes the job slower, without a faster compliant alternative, produces more workarounds, not fewer.
A third response is to blame the individual who took the shortcut. They were usually responding rationally to a deadline, and the same shortcut will be taken by their replacement unless the conditions change.
Possibility
In a better state, the secure way is also the easy way. Each person has their own login, sign-in is quick, a second step is built into routine use, and access requests are approved the same day. Automated jobs use dedicated accounts with limited rights. Elevated access is granted for a stated time and removed automatically.
Exceptions are recorded with an owner and an expiry date, and a short review each quarter asks what has been left open. Staff do not need to be heroic about security, because the system does not punish them for following it.
Intervention
- List the shortcuts. Ask each team lead what they do differently from policy to keep work moving. Treat the answers as information, not confessions.
- Rank by consequence. Start with anything touching money, customer data or administrator rights. A shared bank login matters more than a shared meeting-room account.
- Fix the friction that created each shortcut. If new access takes a week, speed up the approval. If pay-day logins are slow, set up individual accounts with delegated rights.
- Give every account an owner and every exception an end date. Use roles, and automate expiry where tools allow it. The Insight why giving AI access to more systems is not automatically better applies the same principle to newer tools.
- Turn on multifactor authentication where it matters most. Begin with email, banking and administrator accounts.
- Review quarterly. Check leavers, role changes, shared credentials and open exceptions, and report the results to a manager with authority to act.
Diagnostic questions
- Which shared logins exist in finance, operations and IT today?
- Who holds administrator rights, and when was that last reviewed?
- How long does a legitimate access request take?
- Which temporary exceptions have lasted more than three months?
- Whose name is next to each automated job's credentials?
Bottom line
Security problems often begin with operational convenience because the shortcut pays back immediately and the risk arrives later. Removing the friction that makes shortcuts attractive, giving each account an owner and putting an end date on every exception is cheaper than recovering from the breach they invite.
Sources and further reading
- least privilege - Glossary - CSRC (last verified 10 October 2026)
- Password administration for system owners (last verified 10 October 2026)
- Section 19 Security measures on integrity and confidentiality of personal information - POPIA (last verified 10 October 2026)
Related Mellorca reading
- Why Do Former Employees Still Have Access?
- When AI Agents Can Act but Governance Cannot See Them
- Why Reporting Problems Often Begin With Data Capture