VPN hard tokens gave way to app-based MFA in a remote work pivot

At a glance

What this is: This is a short operational lesson on replacing hard-token MFA with app-based authentication during a remote-work transition, with the key finding that real user resistance was far lower than expected.

Why it matters: It matters because IAM teams often overestimate adoption friction and underuse current data, which can delay authentication changes across human identity programmes and distract from the real operational constraints.

By the numbers:

• In two days, the team pushed a major auth change out to over 14k people and saved $400k on hard token renewals over the next three years.
• 1% of users had any difficulty with the, y with the new authenticator app rollout.

👉 Read SailPoint's account of the remote-work MFA transition

Context

Identity teams often plan authentication changes around assumptions about user pushback, but those assumptions can be years out of date. In this case, the problem was not technical feasibility alone, but whether the programme could move thousands of people from hard-token MFA to app-based authorisation fast enough to support a sudden remote-work shift.

For IAM practitioners, the lesson is that authentication migration is as much about operational evidence as it is about security design. When the environment changes quickly, programmes that validate current user behaviour can make better decisions than teams relying on inherited organisational lore.

This is a human identity story, but the governance lesson extends to NHI and autonomous programmes as well. In every case, identity change succeeds when teams test assumptions against present-day conditions rather than legacy expectations.

Key questions

Q: How should security teams validate user resistance before changing MFA methods?

A: Security teams should validate user resistance with current pilot data, help desk trends, and enrolment completion rates rather than rely on old stories or anecdotal objections. A small, monitored rollout reveals whether friction is real, where support is needed, and which exceptions must be built into the process. That approach reduces guesswork and prevents avoidable delays.

Q: Why do hard-token MFA programmes become fragile during rapid workforce changes?

A: Hard-token programmes become fragile because they depend on physical inventory, replacement logistics, and distribution timelines. When a workforce shift happens quickly, those dependencies can outlast the security decision itself. App-based MFA removes much of that operational drag, but only if enrolment and recovery are already designed for scale.

Q: What do organisations get wrong about MFA migration resistance?

A: Organisations often mistake long-standing internal lore for current user behaviour. That leads teams to overestimate pushback and underinvest in rollout support, documentation, and exception handling. In reality, many users will adopt a new factor if the purpose is clear and the process is well supported.

Q: Who should be accountable when a large authentication change affects thousands of users?

A: Accountability should sit with the identity programme owner, the operational support team, and the business approver who accepted the migration risk. Large authentication changes need clear ownership for enrolment, exceptions, communications, and recovery. Without that, a control change becomes a support incident instead of a managed transition.

Technical breakdown

Why hard-token MFA became the bottleneck

Hard tokens create a hardware dependency in the authentication chain. They are reliable when issued and managed at scale, but they also introduce procurement delay, inventory constraints, replacement overhead, and a single point of failure when supply chains tighten. In a sudden workforce shift, the weakest link is often not the MFA protocol itself but the logistics around token distribution and recovery. Moving to app-based MFA removes the physical shipment problem, but it also changes support, enrolment, and exception handling. Practical implication: model authentication as an operational supply chain, not just a control choice.

Practical implication: treat MFA dependencies as part of continuity planning, including enrolment, replacement, and exception workflows.

What changed when authorization moved to the authenticator app

Authenticator-app authorization replaces a physical possession factor with a software-bound factor that can be provisioned and supported remotely. In practice, that shifts control from inventory management to identity proofing, device readiness, and help desk orchestration. The governance question is not whether the app is stronger in the abstract, but whether it can be rolled out, validated, and recovered faster than the old factor it replaces. For large workforces, the decisive issue is often rollout velocity, not cryptographic novelty. Practical implication: design the migration path before the control change.

Practical implication: build an enrolment and recovery path before you change the primary MFA factor.

Why user resistance is often overstated

Identity programmes frequently inherit stale beliefs about user behaviour, especially when those beliefs are passed down informally over time. This story shows that actual resistance can be much lower than expected when the why is clear and the process is supported with documentation, help desk coverage, and a limited exception path. That does not mean every workforce will respond the same way, but it does mean assumptions should be revalidated before they are used to block security changes. Practical implication: separate anecdote from evidence before delaying a control shift.

Practical implication: validate adoption concerns with current data before using them to stall an authentication change.

NHI Mgmt Group analysis

Legacy beliefs about user resistance are a governance risk, not a people problem. The article shows that a long-held internal story about employees refusing authenticator apps did not survive contact with current conditions. That matters because identity programmes often defer change on the basis of assumptions that were never re-tested. Practitioners should treat stale behavioural beliefs as control debt, not as evidence.

Authentication migration succeeds when operational evidence replaces inherited lore. The decisive factor here was not technology novelty, but the willingness to validate rollout risk in non-production, document the process, and provide support at scale. That is a governance pattern worth preserving: identity change should be justified by present-day evidence, not by what someone remembers from a previous cycle. The implication is that programme owners need a habit of re-baselining user and operational assumptions.

Human identity controls still fail when exception handling is treated as an afterthought. The rollout worked because the team accounted for hotspots, non-smartphone users, and help desk support instead of assuming a perfect workforce. That is the part many programmes miss. If exceptions are not designed into the change, they become the reason the change is delayed. Practitioners should plan for the edge cases first, not last.

Validated adoption risk is a better security input than organisational mythology. The post is a reminder that identity governance decisions should be made with current telemetry, not anecdotes passed through the business for a decade. That applies equally to MFA, access reviews, and lifecycle decisions. The practical conclusion is simple: if a risk cannot be measured in the present, it should not be used as a blocker in the programme.

Hard-token dependence created an avoidable continuity constraint. The rollout exposed how physical MFA factors can become operationally brittle when supply and time are tight. That is not a product complaint, but a programme design lesson. The broader implication is that resilience plans should assume fast factor substitution may be necessary, especially when workforce operating models change suddenly.

From our research:

• From our research: 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Our research also shows that only 20% have formal processes for offboarding and revoking API keys, which helps explain why control changes often fail after the first approval step.
• For teams building a stronger operating model, Ultimate Guide to NHIs is the right starting point for lifecycle, visibility, and rotation discipline.

What this signals

The programme lesson is not limited to MFA: identity teams should assume that legacy beliefs about users, devices, and exceptions are often the first constraint to break under operational pressure. When that happens, the strongest programmes are the ones that already have current evidence, documented fallbacks, and a support path for edge cases.

Behavioural debt: identity programmes accumulate risk when they keep acting on old assumptions about how people will respond. The practical signal is simple: if you cannot show recent adoption data, your change plan is probably carrying more folklore than evidence.

For practitioners

• Revalidate behavioural assumptions before changing controls. Replace inherited claims about user resistance with current evidence from pilot groups, help desk tickets, and enrolment completion rates. Use that data to decide whether a proposed authentication change is genuinely risky or just culturally uncomfortable.
• Design the exception path before the migration starts. Map non-standard cases such as users without smartphones, users without home internet, and users who still require a hard token. Build the support flow, documentation, and approval logic before rollout so exceptions do not stall the programme.
• Treat MFA factor changes as continuity planning. Assess whether your current authentication model can survive supply chain disruption, device shortages, or sudden remote-work expansion. If the answer is no, document a fallback factor strategy and the conditions that trigger it.
• Measure rollout friction with operational metrics. Track enrolment completion, help desk volume, exception rates, and failed sign-in attempts during the first production wave. Those signals tell you whether the change is manageable in practice, not just acceptable in theory.

Key takeaways

• Authentication changes fail less often because of user behaviour than because teams fail to test old assumptions against current data.
• A rollout to over 14k users with less than 1% difficulty shows that perceived resistance can be far lower than programme folklore suggests.
• The control lesson is to design fallback factors, exception handling, and support workflows before a migration begins.

Key terms

• Authentication Factor Migration: The controlled replacement of one authentication method with another across a user population. It is a governance exercise as much as a technical one, because it affects enrolment, exceptions, recovery, support capacity, and user communications at the same time.
• Exception Handling: The set of processes used to support users who cannot follow the standard identity or access path. Good exception handling prevents a security change from stalling when edge cases appear, while poor handling turns rare cases into programme-wide friction.
• Operational Evidence: Current, measurable data used to decide whether an identity change is safe, usable, and supportable. It includes pilot results, enrolment completion, help desk volume, and failure rates, and it matters because old stories are not a reliable control input.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by SailPoint: Blog Facepalm Files, Much ado about nothing. Read the original.