case study / identity & security

Moving 15,000 people off Okta and onto Windows Hello

A state government department replaced its Okta sign-in with Windows Hello for Business as part of a wider identity and security overhaul. I worked on the Level 2 and 3 escalation team that kept people signed in while it happened.

Okta sign-inCutoverEscalation (L2/3)StabilisedWindows Hello

01

The change

The department was changing how every member of staff proves who they are. Sign-in moved from Okta to Windows Hello for Business, which ties a person's credential to their device and unlocks it with a PIN or biometrics.

On paper that is a platform swap. In practice it changes the first thing 15,000 people do every morning, and during the cutover the old world and the new one have to work side by side.

02

Where I sat

I was on the Level 2 and 3 escalation team. Anything the front line could not resolve came to us: we diagnosed it, fixed it, and worked out whether it was one person's problem or the first sign of a pattern.

That distinction was most of the job. At this scale a fault that hits one percent of users is 150 people who cannot sign in.

03

What the work was

Most escalations fell into a few families:

  • →Enrolment that would not complete, so a user was left with neither the old sign-in nor the new one.
  • →Devices that were not in the right state to enrol, where the fix was on the device or its directory record, not on the user.
  • →Access that had not followed the user across, so they could sign in but could not reach what they needed.
  • →Post-change verification: confirming after each wave that sign-in, access and security controls behaved as intended before the next wave started.

04

How I worked it

I treated repeats as a pattern, not as tickets. The second time the same fault appeared, the fix was written up once, properly, so the front line could resolve the third one themselves and the escalation queue stayed for the things that were actually new.

The other habit was closing the loop after a change: not assuming a fix had held, but checking it had, and stabilising access for the people affected before calling it done.

05

What I took from it

This project is the reason I build agents the way I do. The valuable work was never answering one request. It was noticing that fifty requests were the same request, and removing the cause.

That is the job I now hand to software: watch the stream, find the pattern, propose the fix, and wait for a person to approve it. Having been the person on the receiving end of a migration at this scale is why the approval step is not optional in anything I build.