The password reset ticket is dying, and IT should help it along

The last password reset I did by hand took nineteen minutes. Fourteen of those were me reading characters out loud.

She was in a hotel two time zones away, on a laptop that had been closed for three weeks, and her password had expired while the machine slept. She could not get past the login window without a fresh credential. She could not get a fresh credential without reaching the corporate network, and she could not reach the corporate network without getting past the login window. So I generated a temporary password and read it to her over the phone. November. Yankee. Bravo. Three. Sierra. Sierra. Six. Dash. Mike.

She typed it wrong twice.

Nineteen minutes of two people's working day, burned on a control I had personally argued for.

A question got put to me a few years back that I have not been able to put down since. What if you never had to handle a ticket, a call, or a complaint about a password change again? Not fewer of them. None.

The append-a-digit era

You know this pattern because you have lived inside it. Rotation every 90 days. The user appends a 1. Next quarter, a 2. Then a 3. Around the fourth or fifth cycle they lose track of which digit they are on, try three variations, lock the account, and call you.

I argued for forced 90-day rotation in a policy meeting in 2016, and I won that argument. I was wrong. It took me years and one patient auditor to say so out loud, because the control looked like diligence and behaved like a ticket generator.

Rotation moves a secret around. It does nothing about how stealable the secret is, and stealable is the entire problem.

Why passkeys break the category

Here is the scene, deliberately boring, because the boring version is the one that works.

An email arrives with an important-looking document attached. Click to verify your email address before viewing. The link opens a login page that looks exactly like Box: right logo, right font, right shade of blue, plausible enough URL if you are not reading carefully at 4:40 on a Friday. The user types a real username and a real password. The page thinks for a moment, then shows a polite error, or opens a harmless PDF, or bounces them to the real Box. Nothing appears to have gone wrong. The attacker is now holding working credentials and nobody in your organization knows it.

Every mitigation you have for that scene is downstream of one fact: there was a password to type.

Passkeys and secure-enclave-backed credentials remove the thing being harvested. You cannot phish a password that does not exist. The term of art is phishing-resistant, and the resistance is real, but nobody serious says phishing-proof. Session cookies still exist, tokens can still be lifted off a compromised machine, and there is published work on exfiltrating SSO session cookies from a Mac with all the modern identity plumbing in place. What goes away is the single most common way real companies actually get taken, which is a person typing a credential into a page that was not theirs.

The half-truth everybody got excited about in 2022

When Platform SSO landed, the feature people repeated to each other was two-way password sync. I repeated it too, in writing, to a security team.

The accurate version goes like this. Enter a new identity provider password at the Mac lock screen and it does sync down to become the new local account password. That direction works, and it removes a genuinely irritating class of parity ticket. Change the local Mac password, though, and nothing travels back up to the IdP. The two-way promise holds in one direction and not the other, which makes it a fine feature and a bad thing to promise.

Twelve seconds to two

A traditional login costs roughly twelve seconds of human life: wake the machine, type a username, type a password, wait for the identity provider to answer. A badge tap is about two.

Six times faster sounds like a rounding error until you count logins.

Put a shared workstation on a hospital floor or a manufacturing line where people badge in and out forty times a shift, and ten seconds saved per login is six and a half minutes per person per shift. Twenty people on that station and you have handed back two hours a day to staff who were spending it looking at a password field. That arithmetic explains why healthcare, manufacturing, and shift-work environments are moving on this faster than the average software company, where everyone logs in twice a day and concludes the problem is small.

The other kind of login friction. In the spring of 2020 an enormous number of laptops went home and stayed there. Then passwords started expiring.

Machines that had cached credentials against an on-prem directory could no longer refresh them, because refreshing required being on the corporate network. The fix, in more organizations than anybody enjoys admitting, was physical: bring the machine back to a building, put it on the network, let it re-authenticate, send it home again. Couriers, parking lots, a folding table by the loading dock.

Anyone who ran that play even once designed their next identity stack specifically so it could never happen again, which is why the Kerberos ticket exchange inside Platform SSO gets more attention than a protocol from the 1980s has any right to expect.

The part nobody budgets for

Everything above is the pitch. The migration is the actual work, and the migration turns out to be mostly one small notification.

When the configuration profile lands on an existing Mac, the user gets a modest system prompt asking them to register with Okta or Microsoft. Reported reactions, roughly in order of frequency: ignore it, dismiss it, report it as a virus, escalate it as a security incident. There is no mechanism to force compliance on an existing fleet. The prompt can be dismissed forever, and it will be. Community tools exist for no purpose other than nagging harder, which tells you how well the built-in nag performs.

Simplified setup through Setup Assistant helps, and it helps exactly one population: brand-new machines. It does nothing at all for a person being migrated on the hardware they already have. Practitioners doing this at scale describe that experience as confusing and painful, with no way to nudge them.

The timeline deserves stating plainly too. Platform SSO was announced in 2022. Registration during Setup Assistant was announced in 2025, and was not actually deployable with Okta or Entra until May 2026. Nearly a full year between announced and usable. If your identity provider is Google, there is no Platform SSO support whatsoever, which is less a rollout problem than a wall.

The one genuinely lovely part. System Settings now shows a green or red registration-health indicator per local account. Picture somebody returning from six months of medical leave: no logins, no token refresh, SSO in a state that would previously have produced a baffled ticket and a forty-minute screen share. Now they open System Settings, see red, click re-register, and are working a minute later. Nobody calls. That is the first self-service identity repair I have seen that a non-technical person can genuinely complete alone, and I do not say that about much.

How I would sequence this on a fleet that already exists

1. Confirm your identity provider supports it before planning anything else. Entra and Okta do, Ping partially, Google not at all.
2. Do not push registration nags to existing machines. You will manufacture the exact tickets you are trying to eliminate.
3. Ride the refresh cycle. New devices and wiped devices get the new stack. Everything else keeps what it has.
4. Offer a self-service opt-in path for people who want it early. They are your best testers, and they will find the app-specific breakage your handpicked pilot group never will.
5. Budget 6 to 12 months, and accept the arithmetic: a laptop bought last year on a four-year cycle will probably sit on the old tooling for three more years. Parallel operation is the plan, not a failure of the plan.
6. Skip smart cards. In one informal poll of sixty-odd admins, four used them, and the consistent advice from those four was don't, unless a regulator is making you.

Obituaries

Passwords are a dumpster fire and we need to be running away from them. That is close to verbatim from a practitioner I trust, and I agree with the direction of travel.

I also want to be honest about where we are standing. A local Mac account absolutely still needs a password today. There is no fully passwordless local account, and the people closest to the problem say maybe five years. All of the above is about making the password stop being the thing a human interacts with, which is a smaller and more achievable goal than making it stop existing.

Passwords also have a remarkable record of outliving their obituaries. Radio was going to kill the newspaper. Then television was going to kill the newspaper. Then the internet was going to kill the newspaper, and the newspaper is thinner and stranger and still turning up.

So I do not expect the password reset ticket to die on a Tuesday. I expect it to thin out the way long-distance charges thinned out, with no memo and no announcement. One quarter you will look at your category breakdown, notice it has stopped being the top row, and be unable to say exactly when that happened.

Help it along anyway. Whatever identity decisions you make this year will still be running your fleet in 2036, and every one of those nineteen-minute phone calls is a vote you have already cast.

---

Foqal builds conversational ticketing for IT teams in Slack and Microsoft Teams, including the request types you would rather stop handling by hand.