- A SaaS vendor saying it "supports passkeys" is only the starting point; recovery, privileged roles and legacy paths decide the real risk.
- Pilot a small, representative group before renewal, then test a lost-device and leaver scenario without weakening the new sign-in policy.
- Passkeys reduce phishing risk, but they do not replace device security, session protection or a careful offboarding process.
Passkeys have crossed the line from interesting technology to a normal buying question. The FIDO Alliance says 68% of organisations have deployed or are actively deploying them for employee sign-ins. That does not mean a buyer can tick a "passwordless" box and call the risk solved. The decision that matters at renewal is whether the vendor's implementation works for the people and failure modes your company actually has.
This is not a case for removing every password in one quarter. CISA recommends aiming for phishing-resistant MFA, while the UK's National Cyber Security Centre says FIDO2 credentials, including passkeys, are as secure or more secure than traditional MFA against common credential attacks. A staged rollout that starts with the accounts that can do the most damage is usually more useful than a sweeping promise.
The seven questions to put in the renewal review
1. Does it work for every account type that matters?
Ask separately about ordinary employees, administrators, contractors, service accounts and emergency access. A vendor may support passkeys for a standard user while leaving its billing console or admin role on a password-and-code flow. Start with the most privileged accounts, but record every exception instead of assuming the feature covers the whole product.
2. Which credential choices can your policy support?
Clarify whether the service accepts platform passkeys, external FIDO2 security keys, or both. The right choice depends on your device policy and workforce—not on a universal ranking. A company with managed laptops may want a different control model from a team of contractors using personal devices. Do not turn on a method until you know where the credential lives and who can enrol it.
3. What happens when a person loses a device?
Recovery is the question most feature comparisons miss. Ask the vendor to describe the exact recovery path, the people who can approve it, the evidence required and the audit trail it creates. A strong sign-in flow can be undone by a weak help-desk reset or a forgotten fallback password. Decide in advance how a temporary access method expires and how a replacement credential is enrolled.
4. Can an administrator see, revoke and investigate credentials?
There should be a practical answer to three events: a device is lost, a worker leaves and an account looks suspicious. Confirm whether admins can view registered methods, revoke a credential, see a registration event and export useful sign-in logs. If the answer is only "the user manages it on their phone," that may be fine for a consumer app but needs a deliberate compensating control for business access.
5. Can you enforce the policy where the risk is highest?
Support without enforcement is an invitation, not a control. Ask whether passkeys can be required for administrators and high-risk applications, whether the registration journey respects your existing conditional-access or device rules, and whether an exception is time-limited and reviewable. Microsoft's June 2026 Entra update is a useful reminder that credential registration itself needs policy attention, not only the final sign-in.
6. Which paths still rely on passwords or weaker MFA?
Make the vendor name the gaps: old desktop clients, IMAP or SMTP access, API tokens, integrations, shared mailboxes, break-glass accounts and account-recovery flows. The point is not to reject a product because a gap exists. It is to know which compensating controls remain necessary and whether a promised roadmap belongs in the contract or is merely a sales-slide aspiration.
7. What will prove the pilot is ready to expand?
Run a small pilot that includes a normal employee, an administrator, a managed device and the awkward edge case your team worries about. Test sign-in, replacement-device enrolment, recovery, revocation and offboarding. Agree on success measures before the pilot begins: completion rate, help-desk burden, time to revoke and the number of remaining exceptions. If a recovery drill needs an undocumented workaround, the rollout is not ready.
A simple decision rule
Renew with confidence when the vendor can demonstrate broad role coverage, a documented recovery path, auditable administration and a time-bound plan for the remaining exceptions. Pilot when the core sign-in works but governance or recovery needs validation. Hold when a privileged account can still be socially engineered through a weak fallback.
Passkeys make phishing materially harder because the credential is tied to the legitimate service, but they are not a magic shield against a compromised device, stolen session or poor access governance. Keep browser and endpoint hygiene, least privilege, logging and offboarding in the same conversation. That wider discipline is also why a tool's apparent subscription saving can hide a much larger operational cost, as we found when looking at the hidden cost of switching SaaS tools.
Sources and further reading
- CISA: Require multifactor authentication
- UK NCSC: Passkeys are more secure than traditional ways to log in
- FIDO Alliance: State of Passkeys 2026 findings
- Microsoft: What's new in Entra, June 2026
Frequently asked questions
Do passkeys eliminate all account-takeover risk?
No. They are phishing-resistant, but device compromise, stolen sessions, poor recovery and excessive access can still create risk. Treat passkeys as one part of an access-security programme.
Should a small business wait until every SaaS tool supports passkeys?
No. Start with email, identity, finance and administrator access, then document the remaining exceptions and protect them with the strongest available MFA and careful recovery controls.