Passkeys vs Passwords: What Businesses Need to Know

A passkey replaces a password with a cryptographic key pair stored on your device and unlocked by your fingerprint, face or device PIN. The private half never leaves the device and is never sent to the website, which means there is nothing for an attacker to steal in a breach and nothing for a fake login page to capture. That is the difference that matters: a password can be phished, reused or leaked, and a passkey cannot. For Australian businesses the practical question is not whether passkeys are better, because they are, but how far coverage extends across the systems you run.

Key facts

• A passkey is a key pair. The private key stays on your device or in your password manager, and the site only ever holds the public half, which is useless to an attacker on its own.
• Passkeys are resistant to phishing by design, because the key is bound to the real site's domain and will not respond to a lookalike.
• There is no shared secret to breach. A company that is compromised cannot leak your passkey the way it can leak a password hash.
• Passkeys are built on the FIDO2 and WebAuthn standards, backed by Apple, Google and Microsoft, so this is an industry direction rather than one vendor's feature.
• Passkeys can be stored in a business password manager as well as in the device keychain, which is what makes them workable across a managed fleet.
• Coverage is the limitation. Major platforms support passkeys, but plenty of line of business and industry-specific applications do not yet, so most businesses will run both for some years.

How does a passkey work?

When you create a passkey, your device generates two mathematically linked keys. The public key goes to the website and the private key stays on your device, protected by the hardware and unlocked with your fingerprint, face or PIN. When you sign in later, the site sends a challenge, your device signs it with the private key, and the site verifies the signature against the public key it holds. The private key is never transmitted and the site never learns it.

Two consequences follow. First, a breach of that website exposes nothing useful, because a public key cannot be used to sign in. Second, phishing stops working, because the passkey is tied to the real domain. A convincing fake login page can ask all it likes, and the browser will not offer a passkey that does not belong to that site. Compare that with a password and a one-time code, where a well-built phishing site can capture both and relay them within the code's validity window.

Are passkeys really more secure than a password with multi-factor authentication?

Yes, and the reason is specific rather than general. A password with an app-generated or texted code is a large improvement over a password alone, but both factors are still things a user can be tricked into handing over. Attack kits that sit between the user and the real site, capture the password and the code, and pass them through in real time are widely available, and they defeat that combination routinely. Texted codes carry an additional weakness in SIM swapping.

A passkey removes the thing that can be handed over. There is no code to read out, no password to type into the wrong box, and the cryptographic binding to the domain means the user cannot be socially engineered into using it in the wrong place. This is why passkeys are described as phishing-resistant rather than simply strong, and it is a different category of protection rather than a stronger version of the same one. None of which makes multi-factor authentication redundant: it remains essential everywhere passkeys are not yet available, which is still most places.

What breaks, and what should a business watch for?

Recovery is the main one. If a passkey lives only on a single device and that device is lost, you need a route back in, which means either passkeys synced through the platform keychain or held in a business password manager, plus a fallback method on the account. Businesses that enable passkeys without planning recovery create lockouts, and the usual reflex is to leave a weak password enabled as a backup, which quietly undoes the phishing resistance you were buying.

Shared accounts are the second. A passkey is bound to a person's device or vault, which is a poor fit for a login four people use. That is a reason to move shared logins to individual accounts rather than a reason to avoid passkeys, but it does need planning. Third is the mixed estate: staff will have passkeys on some systems and passwords on others for years, so the password policy and the password manager both stay in place. Anyone selling passkeys as the end of password management is overstating it.

Should an Australian SME start using passkeys now?

Yes, selectively. Enable them where they are supported and where the account matters, which in practice means Microsoft 365 and Google Workspace sign-in, administrative accounts, and any high-value service that offers them. Those are the accounts phishing targets, so that is where phishing resistance earns the most. Store them in your business password manager rather than only in individual device keychains, so access survives a lost phone and can be managed centrally.

Then leave the rest alone for now and revisit as vendors catch up. Treat this as a gradual migration rather than a project with an end date, and keep the password manager, the password policy and multi-factor authentication running throughout, because they will still be carrying most of your systems. See password management for how this fits with credential handling generally, and identity and access management for the sign-in layer around it.

Frequently asked questions

What happens to my passkey if I lose my phone?

It depends on where the passkey was stored. If it syncs through your platform account or sits in a business password manager, it is available on your other devices and nothing is lost. If it existed only on that one device with no sync, you need the account's fallback recovery method, which is exactly why recovery should be planned before passkeys are enabled. In a managed business setup, storing passkeys in the company password manager is the usual answer, because it survives device loss and can be administered centrally.

Can passkeys be phished?

Not in the way passwords and one-time codes can. A passkey is cryptographically bound to the legitimate site's domain, so a lookalike phishing page cannot trigger it, and there is no secret for the user to read out or type into the wrong place. That said, the account around it can still be attacked: if a weak password or an SMS code is left enabled as a fallback, an attacker will target that instead. The passkey is only as strong as the weakest sign-in method still active on the account.

Do passkeys replace our password manager?

No, and not for years. Passkey support is good across the major platforms and patchy elsewhere, so a typical Australian business will have passkeys on a handful of important accounts and passwords on everything else, including many line of business applications. A password manager is also where passkeys are best stored for a business, so the two work together rather than one replacing the other.

Is a passkey the same as a fingerprint login?

Not quite, and the distinction matters. The fingerprint or face scan unlocks the passkey on your device; it is not the credential itself and it is never sent to the website. Your biometric data stays on the device. What the site receives is a signed cryptographic challenge, which is why a passkey works even on a device where you use a PIN rather than biometrics.

If you want passkeys enabled on the accounts where they matter, with recovery planned properly and the rest of your credentials still managed well, we can work through it with you. Request a callback and we will map out where passkeys fit in your environment.