Logins, MFA & the Leaver Problem: Access That Ends When Employment Does
Two things account for most of the account risk in a small business: passwords that are one breach away from being public, and accounts belonging to people who no longer work there. Neither is exotic, both are cheap to fix, and only one of them is anybody's job.
Ask a business owner how someone would get into their operations system without permission and you will hear about hackers. Ask what actually happened the last three times an account was misused and you will hear about a shared password, a phone left unlocked at a desk, and a former employee whose login still worked four months after the handover lunch.
The gap between those two answers is the whole subject. Account security in a growing business is not a technical arms race. It is two unglamorous disciplines — a second factor on the login, and an exit process that actually ends access — and almost nobody owns the second one.
Why a password alone stopped being enough
A password is a secret that has to survive being typed on shared computers, reused across a dozen services, remembered by a human, and sometimes written on a note in a drawer. It also has to survive an unrelated website being breached, because if the same password protects your accounting system and a forum somebody joined in 2019, the strength of your system is the strength of that forum.
A second factor breaks that chain. It means possessing the password is no longer sufficient — an attacker also needs the phone in the user's pocket, generating a code that expires in thirty seconds. It is the single largest security improvement available to a small organization, and it costs nothing but a few minutes per person.
AWRA OpsHub uses time-based one-time codes from an authenticator app, with recovery codes issued at enrolment for the day somebody changes phone. Organizations can set the policy to recommended, where staff are prompted and reminded on a schedule you choose, or to required, where it is enforced.
Recommended or required?
Where to put your organization on the enforcement scale
Optional and unmentioned
The default state of most small businesses. Perhaps two enthusiasts have it enabled. Effectively unprotected.
Recommended with reminders
Staff are prompted and re-prompted on your reminder interval. Adoption climbs slowly and unevenly, and the people who skip it are frequently the senior ones with the widest access.
Required for privileged roles
The pragmatic middle. Anyone who can approve money, change permissions or export data must have it. Currently a policy you administer rather than a per-role toggle.
Required for everyone
One setting, no exceptions, no ongoing argument. Costs one awkward week of rollout and then stops being a topic.
Most organizations land at "recommended" and stay there for years because it is the setting that avoids a conversation. If you are going to end up at required eventually, the cheapest week to do it is the one where you have fewest staff.
The leaver problem
Every organization has an offboarding checklist. Almost none of them are executed on the last working day, because the last working day is busy with handover, goodwill and a cake. Access removal drifts to "when IT gets to it", and IT is frequently the same person who is covering the leaver's work.
What makes this specifically dangerous in an operations system, rather than merely untidy, is that the departing person's access is contextual. They know which supplier is not checked, which stock line is never counted, and which approval nobody reads. Access without knowledge is a small risk. Access with knowledge is the whole risk.
Where an exit actually goes wrong
What the checklist says
Usually accurate, usually written, usually done eventually.
- Collect the laptop and any keys
- Return company phone and SIM
- Final payslip and dues calculated
- Handover notes to the successor
- Exit interview scheduled
What is left running
Nobody owns these, so they survive the exit.
- Any login with no employee record behind it
- Assets held in their custody, still assigned to them
- Approval permissions on live requests
- Their address on scheduled report deliveries
- Shared credentials they knew and others still use
The two facts that must cross the boundary on the day
- Employment ended on this date — which HR knows and the system does not, unless somebody tells it.
- These assets and these approvals were theirs — which the register knows and HR does not, unless somebody looks.
The failure is almost never negligence. It is that the two halves of the information sit with two different people, and no single step in the process forces them into the same conversation.
An exit that actually closes
-
Change the employment status on the last day of employment, not the last day in the office
These are different dates when someone is on garden leave, terminal leave or notice worked from home. Terminating the employee revokes a linked login and clears its sessions — so the date you record is the date access actually ends.
-
Reassign before you deactivate
Pending approvals, assigned tickets, open tasks and assets in their custody all have to land on a named person. Deactivating first turns each of them into an orphan somebody discovers weeks later.
-
Check the asset register by custodian
Filter assets to the leaver and check every one in. A laptop returned to a desk but never checked in on the register is, as far as the register is concerned, still theirs — and that is what the auditor sees.
-
Change anything they knew that is shared
Shared logins to third-party portals, the router password, the safe combination. This is the step that survives their account being disabled, because it was never their account.
-
Record the removal
The deactivation is an administrative action and lands in the audit log with the actor and time — which is what lets you prove, later, that access ended when you say it did.
Reassign before you deactivate. Disabling the account first does not close the exit — it just turns everything they were holding into somebody's future surprise.
The controls worth knowing about
Beyond a second factor and a clean exit there are a few controls that suit particular shapes of organization. None of them is a substitute for the two basics, and layering them on top of an environment where half the team shares one login achieves nothing.
- IP allowlisting — restricting access to known addresses. Powerful for a back-office team that works from one building; obstructive for anyone genuinely mobile.
- Device trust — treating a recognised device differently from an unrecognised one, so the unusual login is the one that gets friction.
- Login activity review — being able to ask when and from where an account signed in, which is how "that was not me" becomes a checkable statement.
- Impersonation logging — when support access to your account happens, it is recorded as its own event rather than appearing as you.
What we do and do not do
What AWRA OpsHub does today
- App-based one-time codes (TOTP) with recovery codes issued at enrolment.
- An organization-wide MFA policy of recommended or required, with a reminder interval you set.
- IP allowlisting per organization, with a label on each entry so you know why it is there.
- Device trust signals and login activity that is queryable and summarisable.
- Impersonation request logging, so support access is an event with a record rather than an invisible session.
- A security control centre that surfaces signals and incidents instead of leaving them in the raw log.
- Offboarding wired to the employee record — terminating or archiving an employee revokes their linked login and clears active sessions, and a reconciliation screen lists anyone who is offboarded but still holds an active login.
- Logins with no employee record are surfaced too — shipped 2026-08-01. The reconciliation screen now has a fourth section listing every active login with no employee behind it: contractors, auditors, agency users and administrators created straight on the Users screen. Sorted by how long they have been dormant, with never-used accounts first, and each can be revoked and signed out from there.
More we can add to your workspace
- Passkeys or hardware security keys for the main login. WebAuthn exists in the product for attendance verification, not as a sign-in method — do not read the two as the same thing.
- SMS or email one-time codes as a second factor. Codes come from an authenticator app.
- Per-role MFA enforcement. One policy covers the organization today; requiring it of finance alone is the build.
- An account expiry date. Contractor access that lapses on a stated day, which is what actually solves this rather than relying on somebody reading a list.
Where we point you to a specialist
- Automatic revocation of unlinked accounts is one we decline, and deliberately. They have no employment status to read, and an owner or integration account is indistinguishable from a forgotten contractor to any rule that runs by itself. They are a list to review, not a rule that runs.
Until 2026-08-01 this section said contractor and administrator accounts were outside the loop entirely — they were the ones that survive an exit, and nothing flagged them. They are now on the reconciliation screen. Be clear about what that buys you: it makes the forgotten account visible on a screen somebody has to open, on a rhythm somebody has to keep. The stronger control is an expiry date on the account itself, which is on the list above.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsOur take
Turn MFA on as required during your quietest week, and give one named person ownership of a five-step exit that reassigns work and custody before disabling the account. Those two moves close the overwhelming majority of realistic account risk in a business under a hundred people, and neither needs a budget.
See device trust and access controls
MFA policy, recovery codes, IP allowlisting, device trust and login activity, with administrative actions recorded in the audit log.
Explore device trustFrequently asked questions
Should we make MFA required or leave it recommended?
Required, if you can absorb one awkward week. Recommended is the setting organizations choose to avoid a conversation, and the people who then skip enrolment are disproportionately the senior ones with approval rights and export permissions — which inverts the whole point. If you are not ready for organization-wide enforcement today, at minimum enrol everyone who can approve money, change permissions or export data, and put a date in the calendar for the switch.
What happens when someone loses the phone with their authenticator?
That is what recovery codes are for — they are issued at enrolment and each one works once. The practical failure is that people store them in the same phone they lost, so say plainly at enrolment that recovery codes belong somewhere else: a password manager, a printed copy in the safe, anywhere that is not the device they protect. Where recovery codes are gone too, re-enrolment is an administrative action, which is exactly why it is recorded.
Does terminating an employee in HR remove their login?
Where the employee record is linked to a login, yes — terminating or archiving the employee revokes that login and clears its active sessions, and re-enabling is deliberately a separate, explicit administrative action rather than something that happens by accident. There is also a reconciliation screen listing anyone offboarded who still holds active access. The gap to watch is people who have a login but no employee record — contractors, consultants, administrators created directly — because nothing connects their departure to their access at all.
Can we require MFA only for finance and administrators?
Not today — the policy applies to the whole organization. If a full rollout is not possible yet, the workable interim is to enrol privileged users as a matter of process and audit the list, rather than relying on enforcement to do it. Note the direction of travel though: the group you would exempt is usually the group with the least sensitive access, which makes organization-wide enforcement less disruptive than it sounds.
Is IP allowlisting worth turning on?
It depends entirely on how your people work. For a finance team that operates from one office it is a strong, cheap control and the disruption is near zero. For a business with field staff, branch managers on mobile data, or anyone who works from home two days a week, it produces lockouts that get resolved by widening the list until it protects nothing. Decide based on the honest working pattern rather than the one in the policy document.
