Passkeys: the end of passwords at work, in practice

July 16, 2026 · 3 min read · SOVALYX Technologies

Passwords rest on a shared secret: what can be remembered can be guessed, what can be typed can be stolen, what is stored can be breached. Passkeys replace that secret with a cryptographic key pair — nothing to remember, nothing to type, nothing to replay elsewhere — and make credential phishing largely inoperative. What remains is deploying them without falling into the traps.

The principle, in plain terms

A passkey is a key pair: a public key, held by the service, and a private key that never leaves your device — phone, computer or physical security key. At sign-in, the service sends a challenge; the device signs it with the private key after a local unlock — fingerprint, face or PIN — and the service verifies the signature with the public key. No secret travels, no secret is stored server-side.

All of this rests on open standards — FIDO2 and WebAuthn — supported by current browsers and operating systems. Concretely, a passkey can be bound to a single device (a physical security key: demanding, but its rights do not wander) or synchronised across a user's devices through a manager.

Why phishing stops working

Phishing lives off the replayable secret: a look-alike page gets you to type your password, sometimes your one-time code, and replays them in real time on the genuine site. Passkeys break that mechanism in three places. There is nothing to type, so nothing to extract. The passkey is bound to the domain it was created for: on a look-alike site, it simply does not trigger — the check is done by the machine, not by the user's vigilance. And the service's database holds only public keys: stolen, it lets no one log in anywhere.

That is the fundamental difference with code-based MFA: a code can be relayed in real time; a domain-bound signature cannot. Passkeys do not remove every risk — a compromised device remains a compromised device — but they close the single most used attack path against business accounts.

A rollout plan, step by step

1. Inventory: which services accept passkeys? If your applications sit behind a directory and a single sign-on portal, equip that first — the effect propagates to everything behind it.
2. Privileged accounts first: administrators, finance, executives. Small population, maximal risk, immediate gain; physical security keys belong here.
3. Pilot with volunteers: document enrolment, measure the real blockers — incompatible device, unclear procedure — before scaling up.
4. Roll out by population, temporarily keeping password plus classic MFA as a fallback.
5. Tighten: progressively restrict the weak methods until they are reserved for controlled recovery procedures.

The pitfalls to anticipate

The first trap is account recovery: when the password disappears, the attack moves to enrolment. A fraudster who convinces the help desk to register « his » new passkey on an executive's account bypasses all the cryptography. Recovery procedures must therefore be as strong as the authentication itself: reinforced identity checks, an imposed delay, a second validation for sensitive accounts.

Second trap: shared devices — front desk, workshop, counter. A passkey synchronised on a personal session has no place there; individual physical keys that each person carries are the answer. Third: synchronisation through personal accounts. Set the policy before the rollout — a company-managed manager, or hardware keys for critical accounts. Finally, legacy applications that support nothing: give them a documented fallback perimeter and shrink it at every upgrade. These choices tie back to the fundamentals of an SME security baseline and harden the remote access behind secure remote working along the way.

Deployment checklist

• Inventory compatible services and equip the single sign-on portal first.
• Start with privileged accounts, with physical keys for the most sensitive.
• Write the recovery procedure before the first enrolment — and test it against a social-engineering scenario.
• Decide the synchronisation policy: company-managed manager or hardware keys.
• Handle shared workstations with individual keys, never shared sessions.
• Document enrolment step by step, with a reachable point of contact.
• Keep a temporary fallback, then restrict it on an announced schedule.
• Track adoption and authentications per method — outside support helps sequence the rollout without breaking access.

🧰 The companion tool: Would your backups survive a ransomware attack? — free · 2 minutes.

Reviewed and optimised by AI.