Over the past six months, half of UK IT leaders report their organizations now use passkeys. This isn't just a pilot phase, it's a full production deployment. With this shift, your team will face practical questions about implementing this technology.
These questions arise not from whitepapers or vendor webinars, but from real-world scenarios. They're asked in Slack channels when configuring WebAuthn flows, during architecture reviews defending roadmap decisions, and in security audits explaining how passkeys fit your threat model.
Here's what practitioners are actually asking, and what you need to know to answer them.
Do We Still Need MFA if We Deploy Passkeys?
Yes, but the architecture changes.
Passkeys satisfy the "something you have" factor through device-bound cryptographic credentials and the "something you are" factor through biometric unlock or device PIN. This is inherently Two-Factor Authentication (2FA). The FIDO2 standard requires user verification at the device level, your fingerprint or face scan isn't just unlocking the device, it's part of the authentication process.
However, your risk-based access policies remain important. You still need conditional access rules that evaluate device posture, network location, and behavioral signals. Passkeys solve the phishing-resistant authentication problem, but they don't eliminate the need for continuous verification in Zero Trust architectures.
Practically, retire your Time-Based One-Time Password infrastructure for human users, but keep your Policy Decision Point evaluating context signals. Your session policies still matter.
How Do Passkeys Work with Our Existing Directory?
They integrate as an authentication method, not a replacement identity store.
Your Active Directory or cloud directory still holds the authoritative identity record, User Principal Name, group memberships, entitlements. Passkeys replace the password verification step. When a user authenticates, the relying party (your app or identity provider) validates the cryptographic signature against the stored public key, then queries your directory for authorization decisions.
The technical flow: your device generates a key pair during registration. The private key stays in the device's secure enclave or Trusted Platform Module. The public key gets stored in your identity system alongside the user record. During sign-in, the device proves possession of the private key without ever transmitting it. Your directory never sees the private key, which is why credential stuffing attacks become irrelevant.
Integration pattern: if you're using Entra ID (formerly Azure AD), passkeys register as a FIDO2 security key authentication method. If you're running an on-premises environment, you'll need a FIDO2-compatible identity provider that can federate to your Domain Controller for authorization lookups. The authentication happens at the provider; the authorization still happens against your directory.
What Happens When Someone Loses Their Device?
This is where your account recovery workflow becomes critical.
Passkeys are device-bound by design. Lose the device, lose the credential. But the FIDO Alliance anticipated this: users can register multiple passkeys across different devices. Your iPhone, your laptop, your hardware security key, each gets its own key pair registered to your account.
Your recovery policy needs to address two scenarios:
Scenario one: User loses one device but has others registered. They authenticate with a surviving device and revoke the lost device's public key from their account. No help desk involvement needed.
Scenario two: User loses all registered devices. Now you need an out-of-band recovery mechanism. This might be a pre-registered recovery passkey stored securely offline, a video verification call with your help desk, or a time-limited recovery code sent to a verified email address. Avoid using SMS or email links as your primary recovery path to prevent phishing risks.
Document this in your Identity Lifecycle Management procedures. Your help desk needs a clear escalation path that doesn't undermine the security model you've built.
Can We Roll This Out to Third-Party Contractors and Partners?
Yes, but your federation architecture determines how smoothly it goes.
If your partners authenticate through SAML or OAuth 2.0 federation, your identity provider handles passkey authentication and asserts the claim to the relying party. From the partner's perspective, nothing changes, they receive the same assertion they always did, just generated through a different authentication method.
The friction point: device registration. Your partners need to register their passkeys against your identity provider, which means they need access to a registration portal and clear instructions. If you're managing thousands of contractor accounts, consider:
- Just-in-Time Provisioning workflows that trigger passkey registration as part of initial onboarding
- Self-service registration portals with video tutorials
- Grace periods where both passwords and passkeys are accepted during transition
For high-security partnerships, consider shipping hardware security keys pre-registered to specific accounts. The upfront cost is significant, but so is the reduction in account takeover risk.
What's Our Liability if Someone Clones a Passkey?
They can't, but let's be precise about what that means.
The private key is stored in hardware-backed secure storage, iOS Secure Enclave, Android StrongBox, Windows Hello TPM, or a FIDO2-certified Multi-Factor Cryptographic Device. These modules are designed to make private key extraction computationally infeasible. The key never leaves the device, even during authentication.
Could someone compromise the device itself? Yes. Malware with sufficient privileges could potentially trigger authentication ceremonies without the user's knowledge. But that's a device compromise scenario, not a passkey vulnerability. Your defense is device health attestation, requiring devices to prove they're running trusted software before allowing authentication.
From a liability perspective, document your reliance on FIDO2 certification and hardware-backed key storage in your risk register. If you're subject to regulatory requirements like eIDAS in the EU, passkeys meet the technical requirements for high-assurance authentication. Your auditors will want to see evidence that you're validating attestation statements during registration.
Do Passkeys Work for Service Accounts and API Authentication?
No, and that's by design.
Passkeys require user verification, a biometric or PIN entered by a human. Service accounts don't have humans attached. For machine-to-machine authentication, you still need:
- OAuth 2.0 client credentials with certificate-based client authentication
- Mutual TLS with short-lived certificates rotated through Vault Rotation
- Workload identity federation where cloud platforms assert machine identity
Don't try to force passkeys into non-human authentication patterns. They solve the human credential problem. Your service account problem needs a different solution, typically involving cryptographic credentials managed through a secrets management platform.
Where Do We Go from Here?
Start with a pilot cohort, your IT team is ideal because they can troubleshoot their own issues and provide detailed feedback. Measure two metrics: authentication failure rate and help desk ticket volume. If both drop, you've validated the approach.
Then expand to high-risk user populations: executives, finance teams, anyone with access to sensitive systems. These users represent your highest credential phishing risk and benefit most from phishing-resistant authentication.
Document your federation flows, recovery procedures, and device registration requirements before you scale. The technology works, but the operational procedures around it determine whether your deployment succeeds or creates new support burdens.
The FIDO Alliance publishes deployment guides and certification requirements. Your identity provider's documentation should include WebAuthn integration guides. Read both before you architect your rollout.
