Passwordless isn't the future anymore. It's the baseline

01.What is wrong with passwords

A password is a secret that both you and the service know. That is the weakness. It can be guessed, because people pick predictable ones. It can be reused, because nobody remembers fifty different ones. It can be phished, because a convincing fake page will collect it. It can be leaked from a breach at some other service and tried against yours. And when it fails, it must be reset, which costs time and money.

Think about what a reset really involves. A user is locked out and cannot work. They raise a ticket or call. Someone verifies who they are, often badly, because the help desk has no good way to do it. A temporary password is issued. The user changes it, forgets it, and the cycle repeats. Every step is a chance for an attacker to impersonate the user and talk their way in.

Adding multi-factor authentication helps. But many common second factors, such as codes sent by SMS or typed from an app, can still be passed to an attacker's fake page in real time. The password is still there, just with a second hurdle.

02.How passkeys change the picture

A passkey uses a pair of cryptographic keys. The private key stays on your device, locked by a fingerprint, face scan or device PIN. The service holds only the public key. When you sign in, your device proves it holds the private key. Nothing secret is sent.

Two things follow from this design.

• There is nothing to phish. The sign-in is tied to the real website. A fake page on a different address gets no usable response.
• There is nothing to steal from the server. A breached database of public keys is of little use to an attacker.

For the user, it is a tap or a glance instead of typing. Sign-in becomes faster, which is rare for a security improvement. Many passkeys can also sync across a person's own devices through their platform account, which takes care of the "new phone" problem for most people. Hardware security keys give a stricter option for admins and high-risk roles.

03.Why move now

• Phishing-resistant by design. The strongest argument, and the one that matters most to security teams.
• Faster sign-in for users. People adopt what is easier. That makes rollout simpler than most security projects.
• Fewer reset tickets. If there is no password, there is nothing to forget.
• Supported by major platforms and browsers. You are not asking people to install exotic hardware.

04.A worked example

Take a company of a few hundred people with a typical estate: a cloud identity provider, email and documents in a suite, a dozen business apps and a handful of older internal tools. A reasonable first phase does not touch the older tools at all.

IT enrols first. The pilot group signs in to the identity provider with passkeys and keeps their passwords as a backup. After a few weeks, the notes from that group shape the guide: which browsers misbehave, which phones need an update, what to say when someone has a new laptop. Finance goes next, because their accounts are the most attractive to attackers. Only then does the wider company follow.

By the time you reach the last department, the process is routine. The help desk has a script. Managers know what to expect. The remaining password-only apps are on a list with dates.

05.How to start

Do not try to switch everyone on the same day. A sensible path looks like this:

• Pilot with IT. They find the rough edges and write the first guides.
• Expand to one department. Pick one with a mix of devices. Learn what real users struggle with.
• Keep a fallback. Plan for lost phones, new laptops and shared machines before you need to.
• Retire passwords app by app. Turn off password sign-in only where passkeys are working well. Track the apps that cannot support it yet.

Pick your fallbacks with care. If recovery is "email a link to anyone who asks", you have rebuilt the weak point. Recovery should need a second trusted device, a hardware key held by IT, or a proper identity check by the help desk.

06.What gets in the way

Honest answer: it is rarely the technology. It is the long tail.

• Shared devices. Kiosks, front-desk machines and shift workers cannot hold a personal passkey. Plan for hardware keys or other methods for these users.
• Older applications. Some apps only know passwords. Put them behind single sign-on, or a gateway, or schedule their replacement.
• Service accounts. Machines and scripts do not have fingers. They need their own controls, such as short-lived credentials and a vault.
• User confidence. People worry that a lost phone means a lost account. A short guide and a visible help channel solve most of this.

07.Choosing between passkeys, authenticator apps and hardware keys

You do not need one method for everyone. Match the method to the risk and the device.

• Passkeys on phones and laptops suit most staff. They are quick, and the user already owns the device.
• Hardware security keys suit admins, finance approvers and anyone whose account would be costly to lose. They are also the right answer for shared machines, where a personal passkey makes no sense.
• Authenticator apps are a reasonable bridge for older devices and for the weeks during rollout. They are better than SMS codes, but they can still be phished, so treat them as a step along the way.

Write this down as a short policy. A table of who gets what, kept to a page, saves the help desk from making it up as they go.

08.Measuring whether it is working

A rollout that is not measured drifts. Track four numbers weekly.

• Share of active users enrolled in a passkey.
• Share of sign-ins that actually use it, which can differ a lot from enrolment.
• Password reset tickets per week.
• Number of apps that still accept password-only sign-in.

If enrolment is high but use is low, people have a passkey but the sign-in page still offers the password first. Fix the defaults.

09.Common mistakes

• Turning off passwords before the fallback has been tested.
• Letting users add a new passkey with only a password as proof.
• Ignoring admin accounts. These should move first, not last.
• Measuring only enrolment. Track actual sign-ins by passkey, and reset tickets.
• Skipping training because "it is easier than a password". It is, but people still need to see it once.

10.What to do next

Start with an inventory of how people sign in today: which apps, which methods, which devices. Pick a pilot group. Choose your fallback ladder. Set three numbers to watch: adoption, reset tickets and the count of password-only apps.

If you want a second pair of hands, Brandsmashers designs and runs passwordless rollouts, from the inventory through to retiring passwords app by app. We are happy to talk through your setup on a short call, whether or not it leads to a project.