Case studies.

The problem

Setting up a new hire took about two and a half hours. Someone ordered a laptop, imaged it by hand, then copied another person's permissions because that was quicker than working out what the role actually needed. It worked. It also meant access quietly spread to people who were never meant to have it, and every new hire cost someone an afternoon.

What I changed

I made the HR system the starting point instead of a place someone remembered to check. A hire there fired an automation that told me who was joining and what role they were in. Hardware was ordered against that, and because Miradore was tied into Apple's enrolment, the machine configured itself before it ever reached the person. Okta provisioned their access from the role, not from whoever sat nearby.

What it gave back

About thirty minutes instead of two and a half hours, and most of that is waiting. More than 250 people went through it. Nobody imaged a laptop again, and access matched the job description instead of an accident of seating. The same machinery ran in reverse when people left.

The problem

Onboarding gets attention because somebody is waiting and visibly unhappy. Leaving gets none, because the person who would complain has gone. So access lingers. A resignation on Friday becomes a live account on Tuesday, still holding a session, still inside the applications, waiting for someone to remember to file the ticket.

The uncomfortable version of the question is this: if someone left badly this afternoon, how long would they keep their access? Any answer measured in days is a real answer, and it is not a good one.

What I built

HiBob was already where HR recorded the truth about who worked at the company, so it became the trigger at both ends. When HR marked someone as terminated, that change flowed into Okta and access was revoked across everything at once. IT did not need to be told, because IT was not the one who knew first. HR was.

That is the whole idea. Every slow offboarding I have seen was slow because it waited on a human relay: HR knows, HR tells a manager, a manager files a ticket, a ticket reaches someone with the right permissions. Cut the relay and the delay goes with it.

Proving it, not just believing it

Automation you cannot audit is a story you tell yourself. SOC 2 asks you to demonstrate periodically who has access to what, so I ran access review campaigns against Snipe-IT, which held the record of what had been issued to whom. Reviews are only answerable if something has been keeping score, and that was the thing keeping score.

The reviews paid for themselves twice. They confirmed that leavers were genuinely gone, and they surfaced the quieter problem: people still holding tools they had stopped needing a role change ago. Those licences came back too, which turned a security control into a line of recovered budget.

What the automation assumed

Both halves of the lifecycle worked. HR hired someone and the accounts appeared; HR marked someone as leaving and the accounts vanished. I was pleased with it. It handled every case I had thought of, which turned out to be the problem, because I had drawn the lifecycle as a line with a beginning and an end.

What actually happened

Someone left, and about three months later they came back. Nothing in the pipeline knew what to do with that. They already existed in HiBob, so there was no new person to create, and HiBob had no way to express the idea that a previous employee was an employee again. It could hire and it could terminate. It could not restore. Workflows broke, and the automation I had built to remove human effort quietly handed the work back to a human.

The half I had not thought about

The account was the easy part. Offboarding does not only take access away, it moves things: when this person left, their data had been handed to a colleague so the work could carry on. That was correct at the time and it was now in the way. Bringing someone back meant unwinding a transfer of custody, taking data off the person who had inherited it and returning it to the person it started with.

I had built a process that assumed the handover was permanent, because when I built it, every handover had been.

What I changed

I could have patched around the one person. Instead I put a rehired state into HiBob and synced it to Okta, so a returning employee is a case the system recognises: accounts created properly, access restored to what the role calls for. Alongside it, a defined path for reversing the data handover instead of working it out from memory each time. The hiring workflow itself changed, which is the part I would point at.

What I took from it

The automation was not buggy. It did exactly what it was built to do, and it was complete for the model it was built on. The failure was in the model, which is a harder kind of mistake to catch, because everything you test passes.

People do not move through an organisation in a straight line. They leave and return, they change roles, they go on leave, they come back into a different team. Since then I design for the loop rather than the line, and I ask what happens on the way back through.

The problem

Single sign-on is a convenience and a risk at once. Put every application behind one login and you have made that login worth stealing. A password and a session cookie will let someone in from anywhere in the world, and the system has no reason to think anything is wrong.

What I built

Sign-in had to come from a device we managed. It had to come from a country on our approved list, enforced through Okta network zones, so a laptop carried somewhere we did not operate simply would not authenticate. Sessions lasted a day, after which you re-authenticated with your YubiKey rather than a code anyone could be talked into reading out. For the accounts that could reach the most, device and country were not enough on their own and the IP had to match too.

The part people forget

A policy this strict fails the moment someone flies somewhere for two weeks. So travel outside the approved list went through a review: what is this person's role, what data do they actually touch, and what do they need while they are away. The answer was either approval or a window with an end date on it.

The moment

Awareness training lowers how often this happens. It does not take it to zero, and planning as though it will is how organisations end up improvising during the one hour that matters. Somebody clicked. The interesting part is not that it happened, it is what the next twenty minutes looked like.

The sequence

Access first. Revoke it immediately, before working out how bad it is, because the cost of revoking access to someone who turned out to be fine is an apology and a coffee. The cost of waiting while you investigate is measured differently.

Then the device. Quarantine it rather than trusting it, and only then start answering questions: what was the email, what did they click, what ran, what was installed. From there the wider question of whether anything else was reached, which is the one that decides whether this is an incident or an event.

The device came back to them once it was confirmed clean. Not once it seemed fine, and not once the person asked nicely, which they did.

What we did anyway

Because the company worked in the cloud rather than on the endpoint, the exposure was limited, and it would have been easy to treat the whole thing as a scare and move on. We followed the full protocol anyway.

What I was told to do

On my first day I was handed the plan: walk to each computer with a USB stick and upgrade it by hand. Roughly 1,500 machines across more than forty dealerships. Windows 7 was reaching end of life and they were not wrong that the machines had to move. They were wrong about how.

So I asked what systems the company already had, and the answer included Kaseya. It was sitting there, paid for, and nobody was using it for this. I spent the day working out how far it could be pushed, got a rolling upgrade running, and showed them. That was the first thing I did at the company.

Why I pushed back on day one

Walking a USB stick to 1,500 machines is not a plan, it is the absence of one. We work in IT. Automating the tedious thing is not a luxury we earn once the real work is done, it is the job. A new person arguing with the plan on their first morning is a risk, but the alternative was months of my life and everyone else's spent on something a tool we already owned could do on its own.

The constraint that shaped it

Dealerships do not close so that IT can have a quiet weekend. Every one of those sites was selling and servicing cars while we worked, and a machine that came back wrong meant a salesperson standing in front of a customer with nothing.

What I did

I ran it with Kaseya, in waves, grouped by geography rather than by department or alphabetically. Each wave was a handful of dealerships close to one another. If something went wrong, the damage was concentrated somewhere I could drive to, instead of scattered across the province in ones and twos. Nobody lost a working day to the migration.

The part that could not be upgraded

Some machines ran software that only worked on Windows XP. That was not a preference, it was the vendor. Upgrading them was not possible and leaving them on the network was not acceptable, so I segmented them off from everything else and kept management access through Kaseya. They stayed reachable for patching and support while losing the ability to reach anything that mattered.

What I walked into

Twenty-five people across eight clinics, running on paper. Patient files in cabinets. Follow-ups written on sticky notes, which is fine until one falls behind a desk. If you needed to know something, you asked the person who knew, and if that person was on vacation you waited until they came back. All of it under PHIPA, Ontario's health-privacy law.

What I built

I digitised the filing system and had the paper shredded. BitLocker went on every machine, because encrypted records in a cabinet nobody locks is not a plan. The sticky notes became automated reminders on a daily, weekly, and monthly schedule, so the work arrives instead of being remembered. Payment tracking became automatic too: who still owes for their dentures, and for how long. Where the clinic software's own reporting was thin, I built on top of it rather than around it.

The knowledge base

The piece that changed the most was writing things down. Procedures, troubleshooting, onboarding, access rules, all of it in one searchable place with access matched to role, so people see what belongs to their job. An answer that used to take a day, or weeks if the one person who knew was away, now takes seconds and does not depend on anybody being at their desk.

Tracking a denture through the lab

The harder half was production. A denture passes through several stages and several pairs of hands, and the way you knew where one had gotten to was to remember the case, look at a whiteboard, or walk over and ask. When a patient called to ask how much longer, somebody had to go and find out.

So I built DentureFlow, which the labs now run on. Taking a patient's impressions opens a case. A barcode follows it through every stage, so who has it, and who had it before, is a matter of record rather than memory. Work is routed with a time estimate weighted by what the assignee already has on their bench. It syncs with the hardware that prints the dentures. Reception can answer where a case is without leaving the desk.

It has carried more than three hundred cases.

The offices that refer to us

Some of the work arrives by referral from dental offices. That used to mean collecting the same details twice, once from the office and once from the patient, and a run of calls to fill the gaps. Referring offices now have their own accounts and send the details before the first visit, so the information is there when the patient walks in. Management hands out that access.

What it says about the work

I was the whole IT department for this. No team to delegate to, no budget to throw at it, and a staff who did not sign up to learn software.

The problem with a helpful assistant

An internal wiki is only useful if people find things in it, and ours was large enough that they often did not. The obvious fix is an assistant that answers questions from the documentation. The less obvious problem is that a naive one will happily tell anybody anything it has read, which turns your access model into a suggestion.

What I built at Aiven

An assistant over the internal knowledge base that answered according to the asker's role. Someone in one team asking a question got what their role was entitled to see, and nothing from behind a boundary they were not on the right side of. It is the same role-based access control I was already running in Okta, applied to retrieval instead of applications.

The same idea under health privacy

In my current job the constraint is sharper: patient information cannot leave the building. So the automation runs on a local model rather than an API somewhere else. It reviews call recordings to find where reception can improve, with rules added as new situations come up, and checks patient records for missing or outdated details so someone can follow up before it matters. The privacy requirement decided the architecture.