Passkeys are the most material shift in authentication since multi-factor authentication itself. They replace the password with a cryptographic credential bound to the device and the user, resist phishing by design, and remove the most exploited attacker pathway — credential theft. CERT NZ continues to report credential compromise as the leading cause of incidents reported by NZ businesses, and passkeys are the control that finally moves the needle.
This post explains what a passkey actually is, where it fits in an SME's identity stack, and the practical rollout sequence that does not lock anyone out.
---
What a Passkey Actually Is
A passkey is a public-private key pair generated on the user's device. The public key is registered with the service. The private key never leaves the device and is unlocked by the device's biometric or PIN. When the user signs in:
- The service sends a challenge to the device
- The device unlocks the private key after biometric or PIN verification
- The challenge is signed and sent back
- The service verifies the signature with the stored public key
Nothing the user can disclose, no string that can be phished, no shared secret that can be reused. Passkeys are built on the FIDO2 and WebAuthn standards and are now supported by Apple, Google, Microsoft, and the major password managers.
Why Passkeys Beat Passwords + MFA
Even passwords with MFA carry exploitable gaps:
- Phishing kits that proxy the login and capture both the password and the MFA code in real time
- SMS interception for SMS-based MFA — a known weakness covered in SMS MFA is not enough
- Push fatigue attacks that approve a malicious sign-in after repeated prompts
- Credential reuse across services where one breach compromises many accounts
Passkeys close all four. The credential cannot be phished because it is bound to the legitimate origin. There is no SMS to intercept. There is no push to approve under fatigue. And the credential is unique to each service, so reuse is mathematically impossible.
Where Passkeys Fit First
For most SMEs the rollout sequence that works:
- Identity provider sign-in — Microsoft Entra, Google Workspace, Okta. This is the foundation account. A passkey here protects everything downstream.
- Highest-value SaaS — finance platforms, payroll, banking, customer relationship management
- Administrative accounts — every privileged account, every break-glass account
- General workforce — once IT support has handled the early adopters and the kinks are worked out
- Customer-facing applications — depending on the business model
The order matters. Securing the identity provider first means a single compromise no longer cascades. Securing privileged accounts next removes the highest-impact attacker pathway.
Synced vs Device-Bound Passkeys
There are two flavours, and the choice affects security and recovery:
- Synced passkeys — stored in the user's iCloud Keychain, Google Password Manager, or 1Password vault, and synced across the user's devices. Easier to recover, easier to roll out, but the cloud account becomes the new high-value target.
- Device-bound passkeys — stored only on the device that created them, often a hardware security key or TPM. Harder to lose, harder to recover, and the standard for high-assurance scenarios.
For most SMEs, synced passkeys are the right starting point with strong protection on the cloud account itself. Device-bound passkeys belong on administrative accounts, break-glass accounts, and any role with regulated access.
The Recovery Problem
Passkeys solve phishing. They introduce a new operational question: what happens when a user loses their device?
The recovery options need to be designed up front:
- Multiple passkeys per account so a backup device exists
- Hardware security keys held by IT for emergency access
- A verified recovery process that itself cannot be social-engineered
- Documented break-glass procedure for the identity provider
The most common rollout mistake is treating passkey recovery as an afterthought. The first lockout will be the test of the design.
Rollout Sequence
A realistic sequence for an SME:
- Audit current authentication — what is using passwords + MFA, what supports passkeys today?
- Pick a pilot group — IT and a sympathetic team. Two weeks. Capture friction points.
- Document the recovery process — including what the helpdesk does when called
- Update onboarding and offboarding — passkey registration on day one, deprovisioning on departure
- Roll out to high-risk roles — finance, executive, administrators
- Roll out to general workforce — phased by department, with allow-list of supported applications
- Phase out legacy MFA where possible — particularly SMS
Most SMEs complete the core rollout in eight to twelve weeks, depending on the SaaS landscape and how much custom application support is needed.
What Passkeys Do Not Solve
Passkeys are not a complete answer. They do not protect against:
- Account takeover through compromised session cookies
- Insider abuse of legitimate credentials
- Social engineering that bypasses authentication entirely (deepfakes, voice fraud)
- Vulnerabilities in the application itself
The full identity stack still needs session management, conditional access, monitoring, and the broader controls covered in the MFA guide for small business. Passkeys remove one whole category of attack; the rest of the programme continues.
Practical Takeaway
- Audit which of your platforms support passkeys today — most major SaaS now do
- Start with the identity provider and the highest-value accounts
- Decide synced vs device-bound for each tier of account
- Design and document the recovery process before rolling out
- Mandate passkeys for privileged and break-glass accounts
- Phase out SMS-based MFA wherever passkeys are available
- Train staff on what passkeys are and how to register them
- Track rollout coverage as a metric and report it monthly
Start your free SecureAZ trial to train your team on passkeys, MFA upgrades, and credential security.
External references: