Passkeys: An implementation guide

Let us assume you are committed to moving your organization from MFA (or an even older authentication method) to a passkey experience. This document describes how Sophos moved from our existing implementation to a state in which passkeys are the simplest and more secure option for the IT and Security teams, and the user base.

It took three attempts.

Our experience reflects the realities of a global, primarily remote security company with a 60/40 Windows/Mac split and a BYOD policy permitting access to corporate resources via personal mobile phones. Your path will depend on factors such as your workforce profile, device landscape, and regulatory requirements, but the principles and pitfalls we encountered are broadly applicable.

Point zero, where implementation begins

As with most enterprises, we built our passkey program on what we already had in place, asking ourselves what needed to be done (or better understood) to make the move. At the time of project launch, the following parameters were in place:

• MFA was already in place across the company, using Microsoft Authenticator with number-matching for primary authentication.
• Single sign-on was also in use.
• Our user device inventory was 60/40 Windows/Mac. There is a smattering of corporate-issued mobile devices, but most are personal handsets per our BYOD policy. We believed our inventory to be compliant with current requirements for passkey use:
  • Supported operating systems: Windows 10 or newer, macOS Ventura or newer, ChromeOS 109 or newer
  • Supported mobile operating systems: iOS 16 or newer (iOS 17 or later for Mac folk using Microsoft Authenticator), Android 9 or newer (Android 14 or later for Microsoft Authenticator)
  • Supported browsers: Chrome 109 or newer, Safari 16 or newer, Edge 109 or newer (Microsoft Password Manager has been available in Edge’s stable release since version 142, released in October 2025)

As we prepared for passkeys, we determined the following:

• We would use Microsoft’s passkey solution and our existing Entra infrastructure.
• We were aware of no compliance regime that contraindicated use of a passkey process.

One is the loneliest number

Our first attempt was wholly owned by the Security team, with low IT involvement. It focused mainly on users in the most security-aware and sensitive positions at the company — the security enthusiasts, if you will — and focused on physical keys (dongles). The close attention and elevated user understanding provided us with some useful feedback, but the trade-off — logistical challenges, plus low adoption — wasn’t worth it.

Lessons learned:

• The Security team does not have the depth of experience or processes that IT does with issuing and managing gear such as physical keys. Security cannot do this alone.
• Enthusiasts may understand why passkeys are good, but that doesn’t mean they can articulate the benefits to others.
• Even enthusiasts will resist adoption if the new tool adds friction — which may be as trivial as taking a dongle out of their pocket and plugging it into the laptop.

Two to tangle

For our next attempt, we invited IT to lead the project and partner with Security. This approach was useful because we broadened our pilot cohort (though we turned out to be somewhat arrogant in assuming we understood all the “corner” cases or, indeed, the state of user-owned infrastructure such as mobile phones). Moreover, we were able to leverage previous work that brought the vast majority of our applications under the umbrella of OpenID Connect / Security Assertion Markup Language (OIDC/SAML) implementation. The process required a physical key for our Mac users; for our Windows users, it required a physical key plus Windows Hello.

This time, we were able to identify certain logistics issues: the challenges of getting the physical keys to our highly remote workforce, the poor user experience for Mac and mobile users, and the heavy lift represented by manual onboarding. Worst, we realized that moving adoption beyond technical security enthusiasts was likely to go poorly during and after rollout. The key-requisition process was incoherent, users excel at losing small gadgets they haven’t paid for, and our service and support teams were unprepared to handle user issues and questions as they arose.

We paused to better understand the implications of the data, since we clearly weren’t ready to go big. At this point, we let go of our hardware-key focus for all but those employees in need of that highest level of security, and we refocused on using employees’ phones as a medium of passkey storage. The user experience had to be improved, especially to meet the expectations of Mac and mobile users. Above all, we realized that we weren’t exactly selling the dream — the “what’s in it for me” proposition for users was unclear to them. Our next attempt had to present passkeys as not just the default authentication option but the easiest.

Lessons learned:

• Physical keys offer the highest possible level of security, but most people simply do not want to deal with a dongle and will resist using it.
• User experience extends far beyond the hardware or software, and users who hit a tech-support roadblock will quickly sour on the project. (They will also likely convey their frustration to colleagues, which can affect goodwill and passkey adoption.) Thorough support and helpdesk staff training is key to success.
  • Make accurate information available to your support team, and clearly define escalation paths.
  • Publish and update documentation on your intranet, and link to reliable consumer-focused guidance that explains passkeys to help users understand how they differ from previous authentication solutions.
  • Ensure that support team training and the documentation include guidance for all major operating systems.
• Don’t assume that everyone has a “modern” mobile phone, a mobile phone that can easily support passkeys, or a mobile phone that they are willing to use for a corporate passkey. Alternate options such as Windows Hello must be offered, and users should be guided through setup.
• Manual onboarding does not scale.
• “Because it’s required” is not a user-adoption strategy; uptake will be slow and shadow-IT patterns (that is, users’ attempts to circumvent your system) will be prolific.
• Security plus IT is a good partnership, but neither team is particularly adept at making the passkey case to other constituencies. Worse, they have a limited view of potential corner cases and broader user realities. Worse still, they are not experts in the kinds of issues that passkey adoption may raise with other stakeholders such as Legal and HR. Even together, Security and IT cannot do this alone.

Third time’s the charm

We formed a cross-discipline workstream that brought together IT (still owning procedures and logistics), Security (still owning architecture and guardrails), service desk representatives, in-house communications, and end-user computing teams. Some companies would have included HR and Legal in the workstream, but we chose to consult with them on an ad hoc basis. We also incorporated project management elements — providing senior leadership visibility and soliciting sponsorship (with regular feedback to our senior leadership team), creating progress dashboards, developing FAQs for managers, and clearly communicating and adhering to deadlines. We created a generalized version of our project structure as a rollout template (available for download from the passkey playbook page) that includes a stakeholder RACI matrix, milestone tracker, readiness checklist, and support scripts we wish we'd had from the start.

We started taking user perception and experience seriously. In addition to telling users that passkey adoption was the simplest way they could help secure Sophos, we emphasized the personal benefits: provably faster sign-in, fewer prompts to answer, and less of the object-juggling our previous MFA solutions required. We backed it up with a serious reworking of the user experience. Since we’d learned that manual onboarding would not scale, we built an automated onboarding flow with clear, tested in-app guidance. We also offered a third-party tool that let our users test their own setup and decide when they were ready to make the move. For our Mac users, we rolled out macOS Platform SSO; for mobile users, we chose to support device-bound passkeys via the Authenticator app.

Lessons learned:

• Seek a cross-section of stakeholders, including those who can act as SMEs in areas in which Security and IT are weak, such as communications and legal issues. Security is — as always — a team sport.
• With proper project management in place, allowance could easily be made for a nuanced rollout. For instance, new hires at Sophos were passkey-first by default many months before the company at large had transitioned. This was only possible with crisp deadline adherence and early cross-team buy-in.
• With a 60/40 Windows/Mac split, supporting both platforms natively was essential, not optional. Consider whether customization or additional tooling is needed to accommodate devices that are not supported in your default configuration. For example, if your organization uses Microsoft Entra ID and has Mac users, you will need to deploy macOS Platform SSO to deliver a seamless passkey experience. Without it, Mac users face a degraded authentication flow. Microsoft did not initially accept Touch ID as sufficiently secure attestation. This gap between the Windows and Mac experience was a significant source of user frustration until we addressed it.
• Concrete benefits sell adoption. Clarify to employees how passkeys are a win for not only the organization’s security, but for their own convenience and ease of use. In our experience, the average 30-second login process became a 10-second process with passkeys across all platforms. This improvement wasn’t necessarily a gamechanger for every user but turned out to be incredibly compelling for sales teams, a constituency we assumed would be less eager to adopt passkeys.
• Listen when users express concerns. For instance, some users prefer not to use biometric credentials, so be ready to offer solutions such as PIN unlock.

For the future

And now? Our rollout is underway and users are embracing the change. With automated enrollment in place, we are currently delivering passkey functionality to 250 additional users every week.

Challenges ahead:

• Not all apps, particularly mobile apps, support passkeys or other modern authentication flows. Our core applications are accounted for, and this problem is apt to diminish over time. But it will recur.
• Sophos makes heavy use of VMs, and VMs are often not compatible with passkey use. Likewise, third-party virtual desktop infrastructure (VDI), where we cannot control pass-through for security keys, continues to pose issues.
• Not all mobile devices support passkeys yet. In addition to older devices, some Android models are not compliant with passkey requirements. In our own implementation, we discovered a handful of specific models used in the Asia-Pacific region that were not passkey compatible.
• As discussed further in the FAQ, machine identity is the other half of the situation and is an industry-wide issue to be addressed. We are watching the situation with interest and will adapt and grow as things progress.