Passkeys Implementation for UK SMBs: The Complete Technical Guide to Deploying Phishing-Resistant Authentication in 2026

Right. You’ve decided to implement passkeys. Congratulations on not waiting until you’re explaining to the ICO why your compromised credentials led to a data breach.

Now comes the hard part: actually deploying this stuff without your users staging a revolt or accidentally locking everyone out of critical systems.

This isn’t a theoretical discussion about how wonderful passkeys are. This is the practical, tested guide to rolling out FIDO2 authentication across a UK small business. I’m going to assume you’ve got Microsoft 365 (because 73% of UK SMBs do), you’ve got a mix of Windows and possibly Mac devices, and you’ve got users who think “passkey” sounds like something from a spy film.

Understanding What You’re Actually Deploying

Before you touch any settings, let’s be brutally clear about what passkeys actually are and how they differ from what you’re using now.

Traditional MFA: You have a secret (password), you prove you have another secret (TOTP code or push notification), service trusts you.

Passkeys: Your device has a private key that never leaves the device. The service has your public key. Device proves it has the private key using cryptographic challenge-response. No secrets transmitted that can be phished.

This matters because your deployment approach depends on whether you’re supplementing existing auth or replacing it entirely. Spoiler: you’re going to supplement first, then gradually replace. Anyone who tells you to rip out all existing MFA and go passkey-only on day one has never supported real users.

The Three Types of Passkeys You Need to Understand

Device-bound passkeys: Tied to a single device (TPM chip, Secure Enclave). Most secure but least convenient for users with multiple devices. Windows Hello and Mac Touch ID create these.

Synced passkeys: Stored in password managers or platform accounts (Apple Keychain, Google Password Manager, Windows 11 22H2+). More convenient, slightly less secure because they sync across devices.

Security keys: External hardware tokens (YubiKey, Authentrend ATKey.Card Pro). Most portable, work on any device, but users can lose them.

For a typical UK SMB, you’ll deploy all three: device-bound for primary work devices, synced for users who need cross-device access, and security keys as backup/admin access method.

Pre-Deployment Technical Requirements

Let’s talk about what you actually need before you start configuring policies.

Microsoft 365 Licensing

Minimum requirement: Microsoft 365 Business Premium or Enterprise E3/E5.

Why? Because you need Azure AD Premium P1 for conditional access policies. If you’re on Business Basic or Business Standard, passkeys technically work, but you can’t enforce them consistently or create fallback policies for compatibility issues.

Check your current licensing: Microsoft 365 Admin Centre → Billing → Licenses. If you’re not on Premium/E3/E5, budget for the upgrade. Business Premium is currently about £16.60/user/month in the UK. Yes, that’s more expensive than Business Standard’s £10/user/month. No, you don’t have a choice if you want proper security.

Device Requirements

Windows devices:

• Windows 10 version 1903 or later (May 2019 Update)

• Windows 11 (any version)

• TPM 2.0 chip (check with tpm.msc command)

• Webcam + IR sensor for facial recognition, OR fingerprint reader

• If no biometrics: USB-A or USB-C port for security keys

Mac devices:

• macOS Ventura (13.0) or later for native passkey support

• Touch ID sensor (2016 models and newer)

• For Macs without Touch ID: USB port for security keys

Mobile devices:

• iOS 16+ for iPhone (Face ID or Touch ID)

• Android 9+ with biometric authentication

Run a device audit before you start. Use Microsoft Endpoint Manager or Intune to pull hardware specs if you’ve got it deployed. If not, send your users a Microsoft Forms survey: “Does your laptop have a fingerprint reader or facial recognition?” You’ll be surprised how many people don’t know.

Network and Identity Infrastructure

Required:

• Microsoft Entra ID (formerly Azure AD) sync set up

• Hybrid Join or Azure AD Join configured

• TLS 1.2 or higher for all authentication endpoints

• No legacy authentication protocols enabled (looking at you, SMTP AUTH)

Strongly Recommended:

• Microsoft Entra Connect Health monitoring

• Conditional Access policies already in use (so users are familiar with location/device-based restrictions)

• Self-service password reset enabled (because users will lock themselves out testing passkeys)

Browser Compatibility

This is where it gets annoying. Passkey support varies wildly by browser.

Excellent support:

• Edge (Chromium) 108+

• Chrome 108+

• Safari 16+

Acceptable support:

• Firefox 122+ (requires manual config flag changes initially, now default)

Terrible or no support:

• Internet Explorer (obviously)

• Legacy Edge (retire this immediately)

Check browser usage: Microsoft 365 Admin Centre → Reports → Usage → Browser. If more than 5% of your users are on unsupported browsers, mandate Edge via Group Policy before deploying passkeys. Force the update, deal with the complaints, move on.

Step-by-Step Deployment Process

Right. You’ve audited devices, confirmed licensing, and mentally prepared yourself for user resistance. Time to actually configure this.

Phase 1: Enable FIDO2 Security Keys (Week 1)

This gives you a fallback option and lets you test authentication flow without risking device-bound passkeys locking users out.

• Navigate to Entra Admin Centre (entra.microsoft.com)

• Go to Protection → Authentication methods → Policies

• Enable FIDO2 security keys:

Target: Start with a pilot group (IT admins + willing volunteers)

• Attestation enforcement: NOT required (too restrictive for initial rollout)

• Key restrictions: None initially (you can lock down to specific manufacturers later)

• Configure enforcement:

Require key for high-risk sign-ins: Yes

• Allow as single-factor: No (always require passkey + device compliance)

• Test with 3-5 pilot users:

Give them YubiKey 5 NFC or Authentrend ATKey.Card Pro

• Have them register keys at microsoft.com/security

• Verify they can sign in to Outlook web, Teams, SharePoint

• Document every issue they encounter

Expected failure rate: 15-20% will have some issue in pilot. That’s normal. Common problems:

• Browser not recognising USB security key (update browser)

• User clicking “Cancel” on WebAuthn prompt thinking it’s phishing (training issue)

• USB port not providing enough power to security key (use different port or powered hub)

Budget 2-3 hours of IT support time per pilot user. Yes, really.

Phase 2: Deploy Windows Hello for Business (Week 2-3)

This is your primary authentication method for Windows devices. Free, built-in, works brilliantly when configured properly.

Important: Do NOT enable this organisation-wide immediately. Staged rollout prevents disaster.

• Configure via Intune/Endpoint Manager:

Devices → Windows → Configuration profiles → Create profile

• Profile type: Templates → Identity Protection

• Settings:

Use Windows Hello for Business: Yes

• Require Trusted Platform Module: Yes (prevents software-only Hello)

• Minimum PIN length: 6 characters

• Use biometrics: Allowed (not required, accommodates devices without biometric sensors)

• Create conditional access policy:

Require Windows Hello or FIDO2 for high-risk sign-ins

• Grace period: 14 days (users have two weeks to enrol before policy blocks them)

• Excluded users: Break glass admin accounts (critical!)

• Deploy to pilot group first (20% of users):

IT team

• Early adopter volunteers

• Executive assistants (they’re usually tech-savvy and patient)

• Monitor sign-in logs for authentication failures:

Entra Admin Centre → Monitoring → Sign-in logs

• Filter by authentication method: Windows Hello

• Look for error codes 50074, 50173, 53003 (common Hello enrolment issues)

• Expand to broader deployment after 1 week of successful pilot:

Week 3: 50% of users

• Week 4: 75% of users

• Week 5: Remaining users

• Never: Mac users (obviously)

Troubleshooting the inevitable Windows Hello issues:

Error: “We couldn’t set up Windows Hello”

• Cause: TPM not enabled in BIOS

• Fix: Reboot, enter BIOS (usually F2 or Del during startup), enable TPM 2.0

• Alternative: User doesn’t have local admin rights to enrol (grant temporarily via Intune)

Error: “This device doesn’t meet the requirements”

• Cause: TPM 1.2 instead of 2.0, or software TPM

• Fix: Check with tpm.msc, verify version 2.0

• Alternative: Device too old, deploy security key instead

Error: Facial recognition works but fingerprint doesn’t

• Cause: Fingerprint driver not Windows Hello compatible

• Fix: Update biometric drivers from manufacturer, not Windows Update

• Alternative: Use face recognition only, disable fingerprint in policy

Phase 3: Configure MacOS Passkey Support (Week 4)

Macs with Touch ID can use platform passkeys. Macs without Touch ID get security keys.

• Verify macOS version across Mac fleet:

Minimum: Ventura 13.0

• Recommended: Sonoma 14.0 or later

• Force update via MDM if you have Jamf/Kandji deployed

• Configure Company Portal app:

Users authenticate to Microsoft 365 via Company Portal

• Platform passkeys automatically available in Safari 16+

• Chrome/Edge require manual passkey creation at microsoft.com/security

• Test authentication flow:

Sign out of all Microsoft services

• Open Safari, go to office.com

• Sign in with username

• Touch ID prompt should appear automatically

• If not: Check Safari → Settings → Passwords → Use passkeys for autofill

• Create conditional access policy for Macs:

Require compliant device OR FIDO2 security key

• Don’t require Windows Hello (obviously won’t work)

• Grace period: 14 days for passkey enrolment

Mac-specific gotchas:

• Chrome doesn’t use macOS Keychain by default, needs manual config

• Older MacBook Airs without Touch ID can’t use platform passkeys

• macOS Monterey (12.x) has FIDO2 support but it’s buggy; force Ventura upgrade

• Some MDM solutions interfere with Touch ID enrolment; test thoroughly

Phase 4: Mobile Device Configuration (Ongoing)

iOS and Android devices need passkey setup, but deployment is easier because mobile users are already familiar with biometric auth.

iOS Configuration:

• User opens Microsoft Authenticator app

• Adds work account

• System prompts to save passkey in iCloud Keychain

• Verify: Settings → Passwords → microsoft.com entry should show “Passkey”

Android Configuration:

• User opens Microsoft Authenticator app

• Adds work account

• System prompts to save passkey in Google Password Manager

• Verify: Settings → Google → Autofill → Password Manager → microsoft.com entry

Mobile-specific issues:

• Users with older Android phones (pre-Android 9) need security keys

• iOS users without Face ID or Touch ID need security keys

• Some Android devices have buggy biometric implementations; Samsung and Google Pixel are most reliable

• Users with multiple Microsoft accounts get confused about which passkey to use; clear labelling required

Conditional Access Policy Design

Right. You’ve got authentication methods configured. Now you need policies that actually enforce them without creating a support ticket apocalypse.

Policy 1: Require Phishing-Resistant MFA for High-Risk Sign-Ins

Target: All users Conditions:

• Sign-in risk: High

• Locations: All locations Grant controls:

• Require authentication strength: Phishing-resistant MFA

• Require compliant device: Yes Session controls:

• Sign-in frequency: Every time (no persistent sessions for high-risk)

This catches AITM attacks attempting to replay stolen tokens.

Policy 2: Step-Up Authentication for Sensitive Apps

Target: All users Conditions:

• Cloud apps: Azure Portal, Exchange Admin Centre, Entra Admin Centre, Intune

• Locations: All locations Grant controls:

• Require authentication strength: Phishing-resistant MFA

• Require MFA: Yes Session controls:

• Sign-in frequency: 8 hours (reasonable balance between security and usability)

This ensures attackers can’t access admin portals even with stolen session tokens.

Policy 3: Block Legacy Authentication

Target: All users Conditions:

• Client apps: Exchange ActiveSync, other clients (legacy protocols)

• Locations: All locations Grant controls: Block access

Legacy protocols don’t support MFA of any kind. Kill them with fire.

Policy 4: Gradual Passkey Enforcement

Target: Pilot group (first 2 weeks), then expand Conditions:

• Locations: All locations

• Platforms: Windows 10+, macOS 13+, iOS 16+, Android 9+ Grant controls:

• Require authentication strength: Phishing-resistant MFA OR compliant device Session controls:

• Sign-in frequency: 30 days (longer session for passkey users as reward)

The “OR compliant device” clause prevents lockouts during transition. Remove it after full deployment.

User Communication and Training

Technical configuration is maybe 30% of the work. Getting users to actually use passkeys without melting down your support queue is the other 70%.

Week Before Rollout: Announcement Email

Subject: Important Security Upgrade: New Login Method Coming

“Starting next week, we’re upgrading our login security to protect against the latest phishing attacks. You’ll set up biometric authentication (fingerprint or facial recognition) as your new way to access email, Teams, and other work apps.

Why? Recent attacks bypass traditional codes and push notifications. Biometric authentication can’t be stolen by phishing emails.

What you need to do:

• Check your laptop has a fingerprint reader or webcam (most devices since 2018 do)

• Set aside 10 minutes during your first login next week to set up biometric login

• Contact IT if your device doesn’t have biometric capability

Training session: [Teams meeting link] on [date] IT support hours: Extended 8am-7pm during rollout week

Questions? Reply to this email or pop into the IT help channel in Teams.”

Don’t use the word “passkey” in user communication. It confuses people. “Biometric login” is clearer.

During Rollout: Step-by-Step Guide

Create a 5-minute video showing:

• Login screen appears

• Enter username (not password initially)

• Windows Hello prompt: “Use Face ID or Fingerprint”

• Press fingerprint sensor OR look at camera

• Successfully signed in

Record this on actual work hardware, not a pristine demo device. Users need to see their exact hardware and interface.

Post video in: Teams general channel, intranet homepage, sent via email, printed QR code posters in kitchen.

Common User Questions and Approved Answers

“What if the fingerprint reader doesn’t work?” “You can use facial recognition instead, or we’ll provide you with a small USB security key that works the same way.”

“Is Microsoft scanning my fingerprint?” “No. Your fingerprint never leaves your device. It’s stored in a secure chip inside your laptop and is only used to unlock your login credential. Microsoft never sees it.”

“What if I’m working from my personal laptop?” “Personal devices need to be registered with our system first. Contact IT to set this up. For quick access from unregistered devices, you can use a security key we’ll provide.”

“This seems complicated.” “It’s actually simpler than codes. Instead of opening your phone, finding the app, typing six numbers, you just press your finger or look at your laptop. Most users prefer it after the first week.”

Training Session Content (30 minutes)

0-5 mins: Why we’re doing this (show news article about major UK breach) 5-15 mins: Live demo of Windows Hello setup 15-25 mins: Troubleshooting common issues 25-30 mins: Q&A

Record the session. Make it available on-demand. Some users will skip the live session and then need help later; recording reduces support tickets.

Measuring Deployment Success

You need metrics to know if this is working or turning into a disaster.

Track in Microsoft 365 Admin Centre:

Authentication methods report:

• Target: 100% of users enrolled in passkey within 30 days

• Reality: You’ll hit 85-90%, some users have incompatible hardware

Sign-in logs:

• Track “Authentication method” field

• Goal: 80%+ of sign-ins using Windows Hello or FIDO2 within 60 days

• Red flag: <60% adoption after 90 days indicates deployment problems

Support tickets:

• Categorise by type: enrollment issues, hardware incompatibility, user confusion

• Target: <5 tickets per 100 users

• Budget: 2 hours IT support time per 10 users during first 2 weeks

Conditional access policy blocks:

• Monitor users blocked by phishing-resistant MFA requirement

• Should drop to near-zero within 30 days

• Persistent blocks indicate training or hardware issues

Security improvements:

• Track AITM attack attempts via Identity Protection risk detections

• Should see detection of attacks, but no successful token replay after passkey deployment

• Successful replay post-deployment means policy misconfiguration

Troubleshooting and Support Escalation

When things go wrong (and they will), you need a structured approach.

Level 1: User Self-Service

Issue: “I can’t set up my fingerprint” Resolution:

• Open Settings → Accounts → Sign-in options

• Select “Fingerprint recognition”

• Click “Get started”

• If error: Update biometric drivers

• If still error: Escalate to Level 2

Issue: “My fingerprint used to work, now doesn’t” Resolution:

• Clean fingerprint sensor with microfibre cloth

• Remove and re-register fingerprint

• If multiple fingerprints registered, remove all and start fresh

• If still error: Escalate to Level 2

Level 2: IT Support Helpdesk

Issue: “Device doesn’t have TPM 2.0” Resolution:

• Verify in TPM.msc (tpm version field)

• If 1.2: Check BIOS for TPM 2.0 option, may need firmware update

• If no TPM at all: Device too old, order security key, configure FIDO2-only access

• Document device for replacement planning

Issue: “Passkey works on Windows but not on iPhone” Resolution:

• Verify iOS version (Settings → General → About)

• Check Microsoft Authenticator app version (should be latest)

• Remove and re-add work account in Authenticator

• Verify passkey in Settings → Passwords → microsoft.com

• If still error: Escalate to Level 3

Level 3: Infrastructure/Policy Issues

Issue: “Entire department can’t use passkeys” Resolution:

• Check conditional access policy exclusions

• Verify authentication methods policy applies to affected users’ group

• Check Entra Connect sync status (could be group membership issue)

• Review sign-in logs for specific error codes

• Common culprit: MDM policy conflict disabling biometrics

Issue: “Admin accounts locked out after passkey enforcement” Resolution:

• This is why you create break-glass accounts with conditional access exclusions

• Use break-glass account to disable problematic policy

• Re-configure policy with admin account exclusions

• Test thoroughly before re-enabling

• Document lesson learned: never enforce authentication changes on admins without fallback

Cost Analysis and Budget Planning

Let’s talk money. Your board wants numbers.

Initial Setup Costs (One-Time)

Hardware security keys (20% of users as backup/admin):

• YubiKey 5 NFC: £45 per key

• Authentrend ATKey.Card Pro: £25 per key

• For 100-user business, estimate 25 keys needed: £625-£1,125

Microsoft 365 licensing upgrade (if needed):

• Business Basic → Business Premium: Additional £6.60/user/month

• Business Standard → Business Premium: Additional £6.60/user/month

• If you need to upgrade 50 users: £330/month = £3,960 annually

Device upgrades (if required):

• Estimate 5-10% of devices lack TPM 2.0 or biometric hardware

• For 100-device fleet, budget 8 devices needing upgrade

• Mid-range business laptops: £600-£900 each

• Total: £4,800-£7,200 (but spread over normal replacement cycle)

IT implementation time:

• Planning and testing: 40 hours @ £50/hour = £2,000

• Deployment and support: 60 hours @ £50/hour = £3,000

• Total labour: £5,000

Training materials:

• Video production: £500 (outsourced) or £0 (record in-house)

• Documentation: Internal effort, no external cost

• Support guides: Template-based, minimal cost

Total initial investment for 100-user business: £10,485-£17,285 depending on hardware refresh needs

Ongoing Costs (Annual)

Replacement security keys:

• Lost/damaged keys: 5% annual replacement rate

• For 25 deployed keys: 2 replacements/year

• Cost: £50-£90 annually

Licensing:

• Microsoft 365 Business Premium ongoing: Calculated above

• No additional authentication-specific licensing

Support overhead:

• Estimated 2 hours/month for passkey-related support tickets

• Cost: £100/month = £1,200 annually

Total ongoing costs: £1,250-£1,290 annually plus any licensing upgrades

Cost Avoidance (The Real ROI)

Prevented breach costs:

• Average UK SMB data breach cost: £2.5-£3.2 million (IBM 2025 report)

• Insurance premium reduction: Typically 5-15% for phishing-resistant MFA

• For £15,000 annual premium: £750-£2,250 savings

Productivity gains:

• Reduced password reset tickets: 30-40% reduction typical

• At 50 password resets/month × 15 minutes IT time × £50/hour = £625/month saved

• Annual: £7,500

Compliance benefits:

• Avoided ICO fines for inadequate security (up to 4% global turnover)

• Reduced audit remediation costs

• Faster tender responses (security questionnaires pre-filled with compliant answers)

ROI calculation for 100-user business:

• Initial investment: £15,000 (including licensing, hardware, labour)

• Annual costs: £1,250

• Annual savings: £8,250-£9,750 (insurance + productivity)

• Payback period: 1.8 years

• 5-year net benefit: £26,250-£33,750

And that’s before considering the incalculable cost avoidance of NOT having a breach that destroys customer trust and tanks your business.

Compliance and Regulatory Considerations

The UK regulatory landscape is shifting. What was “best practice” in 2024 is becoming “minimum compliance” in 2026.

NCSC Guidance

The National Cyber Security Centre updated their small business guidance in November 2024 to specifically recommend phishing-resistant authentication. From their documentation:

“Multi-factor authentication should use methods resistant to phishing, such as FIDO2 security keys or device-bound passkeys. SMS and authenticator app codes alone are no longer considered sufficient protection for business-critical systems.”

That’s not a suggestion. That’s the UK government’s technical authority on cybersecurity telling you that basic MFA doesn’t cut it anymore.

ICO Data Protection Expectations

The Information Commissioner’s Office evaluates “appropriate technical measures” for GDPR Article 32 compliance. Their Accountability Framework explicitly references authentication as a key control.

If you suffer a breach and your investigation reveals:

• Traditional MFA was in use

• NCSC guidance recommended phishing-resistant alternatives

• Commercial solutions were available and affordable

• You chose not to implement them

The ICO will not be sympathetic. They’ll argue you failed Article 32’s requirement for security “appropriate to the risk”. Expect a fine.

Cyber Essentials and Cyber Essentials Plus

The current Cyber Essentials scheme (version 3.1) requires MFA but doesn’t specify phishing-resistant methods. That will change.

IASME (the scheme certifier) is consulting on version 4.0 requirements expected in Q2 2026. Draft guidance includes explicit FIDO2 requirement for Cyber Essentials Plus certification.

If your business needs CE+ for public sector contracts, start passkey deployment now. Don’t wait for the official requirement and then scramble to comply during recertification.

Director Fiduciary Duties

Companies Act 2006 Section 172 requires directors to exercise reasonable care, skill, and diligence. That includes information security.

If NCSC publishes guidance, you’re aware of it, and you choose not to follow it without documented risk acceptance and compensating controls, you’re potentially breaching fiduciary duty.

The HSE enforcement model for workplace safety provides the precedent: directors can face personal prosecution for gross negligence. Cybersecurity is moving the same direction.

Document your passkey deployment decision. Document your risk assessment. Document your implementation plan. If something goes wrong, having that documentation is the difference between “unfortunate incident” and “negligent director liability”.

What This Means for Your Business

Stop treating authentication as an IT problem. It’s a board-level risk management decision with personal liability implications for directors.

If you do nothing else this week:

• Audit your device fleet for TPM 2.0 and biometric capability. Get real numbers, not guesses.

• Verify your Microsoft 365 licensing supports conditional access policies. If not, build upgrade cost into Q1 budget.

• Deploy Windows Hello to your IT team today. They need to understand the user experience before supporting broad deployment.

• Order 10 hardware security keys for pilot testing. YubiKey 5 NFC or Authentrend ATKey.Card Pro. Get them in staff hands.

• Document your deployment plan with timelines, costs, and risk assessment. Your board needs to formally approve this, and your auditor needs to see you took it seriously.

The attackers are already using AITM toolkits. The regulatory expectations are already shifting. The only question is whether you’ll be ahead of the curve or explaining to the ICO why you weren’t.

Sources

Source	Article
Microsoft Learn	Passwordless authentication options for Microsoft Entra ID
NCSC	Windows security guidance
FIDO Alliance	FIDO2: WebAuthn & CTAP specifications
Microsoft Tech Community	It’s time to hang up on phone transports for MFA
IASME	Cyber Essentials Scheme Requirements
ICO	Guide to data security including encryption
Microsoft Learn	Windows Hello for Business deployment guide
Apple Platform Security	Passkeys in macOS
Yubico	FIDO2 security key deployment case studies
Gartner	Market Guide for User Authentication