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.
What it does not do
- No 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.
- No SMS or email one-time codes as a second factor. Codes come from an authenticator app.
- No per-role MFA enforcement. The policy is organization-wide; you cannot require it of finance and not of everyone else.
- Nothing covers logins with no employee record behind them. Revocation follows the employee → user link, so contractor, consultant and directly-created administrator accounts are outside it entirely. Those are the ones that survive an exit.
Note the shape of the remaining gap. Where an employee record is linked to a login, ending employment ends access. Where somebody was given an account without an employee record — which is most contractors and quite a few administrators — nothing connects their departure to their access, so the reconciliation screen will not flag them either.
Our 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.
