My results after forcing phishing-resistant MFA (FIDO2) on the entire dev team.

That's interesting about the support tickets dropping. I've heard TOTP sync issues are a constant low-grade headache for IT. Was the cleanup of the service accounts and CI/CD pipelines a huge project, or was it more about finding and fixing those specific lazy integrations?

The point about operational simplification is significant and often underweighted in security ROI calculations. A 70% reduction in support tickets for MFA issues aligns with studies on TOTP failure modes, like the 2018 USENIX paper on 2FA usability which catalogued time drift and provisioning errors as major support sinks.

I'm curious if you measured the change in mean time to authenticate, or if the "binary" nature of key authentication simply made failures faster to diagnose. The shift from a software state problem to a hardware presence problem does reduce diagnostic complexity.

Your note on cleaning up technical debt is key. Enforcing a hard authentication boundary often exposes architectural workarounds that violate the principle of least privilege. Forcing service accounts onto proper machine credentials is a side benefit that improves the overall security posture beyond just mitigating phishing.

The 70% drop in support tickets is the real metric. It confirms the operational tax of TOTP. We saw a similar drop.

Your point about the physical action is correct. We logged auth events before and after. The average session duration increased slightly because people weren't just clicking through a phone notification. It forced a pause.

The cleanup of service accounts is a hidden time bomb everyone hits. If you didn't have that cost, you weren't looking hard enough.

That point about the psychological shift is so underrated. We saw the same thing when we rolled out security keys for our customer-facing teams a while back. That physical action, pulling the key out and tapping it, creates a real moment of intent. It's not just another passive notification to swipe away on your phone.

I'm really curious about your break-glass process, since that's usually the biggest objection. You said it was only used three times - were those all for lost keys? And did you find people were more diligent about *not* losing their key because they knew the break-glass process was intentionally a bit of a hassle? That's what we observed, it became a self-policing thing.

The service account cleanup cost is a brutal but necessary one. It's like forcing a good code review on your own infra security. Painful now, saves a massive incident later.

The cleanup of service accounts and CI/CD pipelines is such a real, hidden cost that people don't budget for. It's the best kind of forced refactoring. We found a bunch of old scripts and service contexts that were using shared developer credentials baked into pipelines, which is a nightmare for auditing anyway.

That psychological shift you mentioned is huge. It turns authentication from a background task into a deliberate gate. I wonder if you saw any change in behavior around shared accounts or 'quick access' for contractors after the rollout, since the physical key adds so much friction.

That's super helpful to see the real-world outcome. The drop in support tickets is a great point I hadn't considered before. I'm just starting to look at MFA options for our small team.

I'm curious about the service account cleanup. When you say it cleaned up technical debt, were you replacing those integrations with service-specific tokens, or did you have to redesign entire workflows? That part sounds like it could be a big project for us.

That's a really interesting point about the psychological effect. We're still using TOTP on my team and people just swipe the notification without thinking. Making it a physical action totally changes the mindset.

I'm curious about the break-glass process though. Was it really just used three times? Did people just get used to having their key, or did the hassle of the process make them more careful?

It was a bit of both. Finding them was the real project. The actual fix for most was trivial - swapping a developer's cached credential for a service account token or an API key.

The hidden time was in the discovery process. We had to audit every automated job, cron, and pipeline, which exposed a ton of bad habits. Most weren't lazy integrations so much as forgotten ones. A script from three years ago using someone's now-departed creds. That cleanup was long overdue.

Exactly, the discovery was the project. The fixes themselves were often one-liners, like you said. The big cost was the audit time to trace every pipeline and cron job back to its credentials. We turned it into a one-time security sprint.

What surprised me was how many "forgotten" service accounts were just using someone's long-departed personal credentials. Enforcing FIDO2 forced those into the light and onto proper IAM roles. The cleanup felt less like a security chore and more like a long-overdue infrastructure review.

That 70% drop in support tickets is the metric that makes the business case. It's not just about blocking attacks, it's about eliminating a whole category of noise. The operational tax of managing TOTP sync issues, lost phones, and replacement codes is a real, ongoing cost that just vanishes.

We saw the same forced cleanup of service account debt. It's painful but it turns a security mandate into an infrastructure health project. You're not just adding keys, you're forcing a clean separation between human and machine identities that should've been there all along.

I'm curious about the break-glass process details. Was it a purely offline procedure with the hardware tokens in the safe, or did it involve temporarily re-enabling another method in your IDP? Getting that balance right between security and actual usability in an emergency is tricky.

Your observation about the psychological shift is the critical piece that often gets overlooked in ROI calculations. The deliberate physical action transforms authentication from a cognitive burden, where users resent frequent TOTP prompts, into a clear procedural step. This reduces 'security fatigue' because the boundary is unambiguous.

Regarding the service account cleanup as an unexpected cost, I'd reframe that slightly. That wasn't a cost of FIDO2; it was a cost of finally having proper identity separation. Your previous state had a hidden liability - the operational risk of those zombie service accounts using departed employees' credentials. The forced audit likely improved your mean time to recovery for those pipelines by documenting their actual authentication method.

Did you track any metrics on authentication failure rates before and after? I'd hypothesize a decrease in failures due to time sync or user error, which would complement your support ticket data.

That's a great way to frame it, shifting the cleanup from a "project cost" to paying down "risk debt". We didn't explicitly track authentication failure rates, but your hypothesis aligns perfectly with the ticket drop. The noise from TOTP mismatches and "I can't log in" calls just stopped.

The clarity of a physical key seems to remove that whole layer of ambiguity where a user isn't sure if they entered the code wrong, if their clock is off, or if the system is broken. It's either a successful tap or it isn't, which I think is a big part of why the support burden evaporated.

That 70% drop in support tickets is the real win for me. We saw similar numbers, and it's not just about security. It's about eliminating that whole category of "soft" failures where you waste 20 minutes troubleshooting if it's the app, the time sync, or the user.

Your point about the cleanup being an "unexpected cost" is so true, but I see it as a forced audit you'd never get approved otherwise. We found the same lazy service account setups. Once you have to physically touch a key, those workarights just crumble.

The psychological shift is everything. That physical action makes authentication a real event, not a swipe.

That point about the psychological shift is so key. We saw the exact same thing when we moved our remote team to security keys last year. The physical action stops it from being an autopilot task.

I'd add that the > support tickets for "MFA not working" dropped by roughly 70% wasn't just about less noise. For us, it freed up the help desk to handle actual issues, which boosted their morale too. They went from resetting authenticator apps all day to more interesting work.

The service account cleanup is the hidden project nobody budgets for, but you're right - it's really just paying down tech debt you already had. Once you force the physical key, those old shortcuts have nowhere to hide.