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.msccommand)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.0Alternative: 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.
| 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 |