{"id":9123,"date":"2026-08-11T13:30:02","date_gmt":"2026-08-11T13:30:02","guid":{"rendered":"https:\/\/dextora.agency\/insights\/passkeys-and-the-password-that-stays\/"},"modified":"2026-08-11T13:30:02","modified_gmt":"2026-08-11T13:30:02","slug":"passkeys-and-the-password-that-stays","status":"publish","type":"insight","link":"https:\/\/dextora.agency\/en\/insights\/passkeys-and-the-password-that-stays\/","title":{"rendered":"Passkeys and the Password That Stays: What Actually Changed by 2026"},"content":{"rendered":"<p>There are now <a href=\"https:\/\/fidoalliance.org\/five-billion-passkeys-a-milestone-not-a-finish-line\/\" target=\"_blank\" rel=\"noopener\">five billion passkeys in active use<\/a>, ninety percent of consumers know what one is, and three quarters have enabled at least one. On any reasonable reading, passkeys have won the argument.<\/p>\n<p>And yet 57% of organisations still use a password as the primary way their own staff sign in every morning. Both facts come from the same body of research, and the gap between them is the entire practical story. Passkeys are not a switch anyone flips. They are a second door added beside the first one, and the first door usually stays open for years.<\/p>\n<h2>What a passkey actually is, in business terms<\/h2>\n<p>The cryptography is not the useful part to understand. Three properties are.<\/p>\n<ul>\n<li><strong>There is nothing to type, so there is nothing to steal in transit.<\/strong> The credential never leaves the device in a form anyone else can use. A leaked database of passkey records does not give an attacker a way in, which is not true of a leaked database of password hashes.<\/li>\n<li><strong>It is bound to your exact domain.<\/strong> This is the property that matters most and the one nobody mentions. A passkey created for your real site will not offer itself on a convincing copy of your site. Phishing does not fail because the user is careful; it fails because the credential is not applicable.<\/li>\n<li><strong>It cannot be reused across sites.<\/strong> Every passkey is specific to one service. The single most common way small businesses actually get compromised \u2014 a password reused from somewhere that was breached years ago \u2014 has no equivalent here.<\/li>\n<\/ul>\n<p>What people usually picture is the unlock gesture: a fingerprint, a face, a device PIN. That is only the local step that permits the device to use the key. The biometric is not sent anywhere and is not what authenticates you, which is worth knowing because it is the objection you will hear first from staff and customers.<\/p>\n<h2>The numbers, read carefully<\/h2>\n<p>The 2026 figures come from two parallel surveys run by Sapio Research in April 2026 \u2014 11,000 consumers and 1,400 decision-makers across ten countries. Read them with one caveat that changes their meaning for most readers of this note.<\/p>\n<table>\n<thead>\n<tr>\n<th>Finding<\/th>\n<th>Figure<\/th>\n<th>What it actually tells you<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Passkeys in active use<\/td>\n<td>5 billion<\/td>\n<td>The technology is mainstream, not emerging<\/td>\n<\/tr>\n<tr>\n<td>Consumers aware of passkeys<\/td>\n<td>90%<\/td>\n<td>You no longer have to explain the concept<\/td>\n<\/tr>\n<tr>\n<td>Consumers with at least one enabled<\/td>\n<td>75%<\/td>\n<td>Enabled once is not the same as used habitually<\/td>\n<\/tr>\n<tr>\n<td>Consumers using them whenever possible<\/td>\n<td>49%<\/td>\n<td>Roughly half your customers will not<\/td>\n<\/tr>\n<tr>\n<td>Organisations deploying or piloting for staff<\/td>\n<td>68%<\/td>\n<td>Measured in companies with 500+ employees<\/td>\n<\/tr>\n<tr>\n<td>Organisations whose primary staff sign-in is still password-based<\/td>\n<td>57%<\/td>\n<td>Deployment and elimination are different things<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>The caveat is the workforce sample: organisations with more than five hundred employees. If you have eleven staff and a WordPress site, that 68% is a description of a different world \u2014 companies with an identity team, managed devices and a helpdesk. It tells you where the industry is going. It does not tell you what your Tuesday should look like.<\/p>\n<div class=\"accent-block\">\n<p>The honest summary of 2026 is that passkeys are winning as an <em>additional<\/em> method and losing as a <em>replacement<\/em>. Enabling a passkey is a moment; abandoning the password requires shutting the old door, and the old door is what your account recovery, your support process and your least technical customer all quietly depend on. Anyone selling you &#8220;going passwordless&#8221; as a project with an end date is selling the easy 80%.<\/p>\n<\/div>\n<h2>Why this is a conversion question, not only a security one<\/h2>\n<p>The security case is well rehearsed. The commercial case gets less attention and is often larger: nearly half of consumers report having abandoned a purchase because they could not remember a password.<\/p>\n<p>That is the same category of loss as any other checkout obstacle, and it behaves the same way \u2014 invisible in your reporting, because an abandoned session leaves no complaint. It is worth reading beside the other resolvable frictions in our note on <a href=\"https:\/\/dextora.agency\/en\/insights\/checkout-that-loses-revenue-what-baymard-data-shows\/\">where checkouts lose revenue<\/a>, since a forgotten password at the sign-in step and a surprise delivery cost at the payment step do exactly the same damage to the same order.<\/p>\n<p>Two consequences follow for anyone with customer accounts. First, the login screen deserves the same scrutiny as the checkout, and almost never gets it. Second, if you add passkeys as an option rather than an obligation, the upside is asymmetric: the customers who use them log in faster, and the customers who ignore them are no worse off than today.<\/p>\n<h2>Where your site actually sits<\/h2>\n<p>Three situations, three completely different amounts of work. The mistake is to reason about all of them at once.<\/p>\n<table>\n<thead>\n<tr>\n<th>Your situation<\/th>\n<th>Priority<\/th>\n<th>What to do<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>A site with a handful of admin logins<\/td>\n<td>High, and cheap<\/td>\n<td>Protect the admins first \u2014 few people, high value<\/td>\n<\/tr>\n<tr>\n<td>A shop with customer accounts<\/td>\n<td>Medium<\/td>\n<td>Offer passkeys, never require them<\/td>\n<\/tr>\n<tr>\n<td>A client portal or SaaS product<\/td>\n<td>High<\/td>\n<td>Design recovery before you design sign-in<\/td>\n<\/tr>\n<tr>\n<td>A brochure site with no accounts<\/td>\n<td>Low<\/td>\n<td>Your risk is plugins and hosting, not sign-in<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>Note the first row. For most business websites the entire exposed surface is between two and six administrator accounts, and one of them is a former contractor&#8217;s. Compromising an admin account is the shortest path to a compromised site, and it needs no vulnerability at all. That is the same access-hygiene problem set out in our note on <a href=\"https:\/\/dextora.agency\/en\/insights\/wordpress-security-how-sites-get-hacked-guide\/\">how sites actually get hacked<\/a>, where the answer is usually credentials rather than clever exploitation.<\/p>\n<p>One WordPress-specific note, since that is what most business sites run on: as of August 2026 core still does not ship passkey support, so it arrives through a plugin or through whatever identity layer your host provides. That is worth saying plainly because of the irony involved \u2014 you are adding a plugin to the layer that produces most WordPress compromises in order to harden the login. It is still usually worth doing for a handful of administrators, but choose the plugin the way you would choose any other privileged one: recent updates, a maintainer you can identify, and a plan for what happens if it is abandoned. The exposure maths behind that judgement is in our note on <a href=\"https:\/\/dextora.agency\/en\/insights\/wordpress-plugin-vulnerabilities-five-hour-exposure-window\/\">the window between disclosure and patch<\/a>.<\/p>\n<h2>The parts the vendor slides leave out<\/h2>\n<p>Four practical problems. All four are solvable, and none is mentioned in the marketing.<\/p>\n<p><strong>Account recovery becomes the weakest link, and it always did.<\/strong> A passkey that cannot be phished sits behind a recovery flow that usually can. If losing a phone means &#8220;email us a reset link&#8221;, then your authentication is only as strong as the email account and the person reading the support inbox. Fix recovery first; the sign-in method is the easy half.<\/p>\n<p><strong>Shared accounts do not map onto passkeys.<\/strong> Passkeys belong to people and devices, not to a team. Any business where three people use one login is going to discover this during rollout. The correct fix \u2014 individual accounts with roles \u2014 is the fix you needed anyway, and it is easier to justify while you are already changing the login.<\/p>\n<p><strong>Device loss is a support event, not a security event.<\/strong> Synced passkeys reduce this considerably, since the credential lives in a platform account rather than on one handset. But someone with one device and no sync will eventually be locked out on a Friday afternoon, and your process needs an answer that is not &#8220;we will have to delete the account&#8221;.<\/p>\n<p><strong>The password path stays open, so the old risks stay too.<\/strong> As long as a password can still sign in, phishing still works \u2014 an attacker simply asks for the method that is phishable. This is precisely why 57% of organisations that have moved on paper have not moved in practice. Passkeys reduce risk when they replace something; alongside everything, they mostly add convenience.<\/p>\n<h2>A proportionate plan<\/h2>\n<p>Five steps, in this order, for a business with a website rather than an identity department.<\/p>\n<ol>\n<li><strong>Count your privileged accounts and delete the dead ones.<\/strong> Every business site has at least one administrator who left. This costs nothing, takes twenty minutes, and removes more risk than any authentication change.<\/li>\n<li><strong>Put the strongest available method on the remaining admins.<\/strong> Passkeys where your platform supports them; a hardware key or an authenticator app where it does not. Four accounts is a small enough number to do properly.<\/li>\n<li><strong>Fix the recovery path before touching customer sign-in.<\/strong> Write down what happens when someone loses their device, and check that the answer does not reduce to &#8220;whoever controls the email address controls the account&#8221;.<\/li>\n<li><strong>Offer passkeys to customers as an option.<\/strong> Alongside the existing password, with a plain one-line explanation and no forced migration. Then measure adoption before deciding whether the next step is worth anything.<\/li>\n<li><strong>Leave the password in place, deliberately.<\/strong> Not as a failure of nerve, but as a documented decision with a date to revisit \u2014 the same discipline applied to the baseline controls in our note on <a href=\"https:\/\/dextora.agency\/en\/insights\/cybersecurity-for-small-business-baseline-protection-guide\/\">what small-business security actually requires<\/a>.<\/li>\n<\/ol>\n<p>What not to do: force a migration on customers, buy a passwordless platform to protect four logins, or treat the presence of a passkey option as evidence that the account-takeover problem has been dealt with.<\/p>\n<h2>What to ask your developer<\/h2>\n<p>Three questions establish whether this is real on your site or a checkbox on a plugin page.<\/p>\n<p><strong>&#8220;Which of our logins support passkeys today, and who has enabled one?&#8221;<\/strong> The second half is the real question. Support without enrolment is a feature nobody uses.<\/p>\n<p><strong>&#8220;What happens if I lose this phone?&#8221;<\/strong> Ask them to walk you through it, on the real site, rather than describe it. Recovery flows are where the gap between design and reality lives.<\/p>\n<p><strong>&#8220;Can an attacker still sign in with just the password?&#8221;<\/strong> If yes \u2014 and it usually is \u2014 then you have added a convenience, not closed a hole, and you should know which one you bought. The same clarity applies to the credential-separation question in our note on <a href=\"https:\/\/dextora.agency\/en\/insights\/npm-worm-front-end-build-security-boundary\/\">why the build step is now a security boundary<\/a>.<\/p>\n<h2>Key takeaways<\/h2>\n<ul>\n<li><strong>Five billion passkeys are in active use and 90% of consumers know the term,<\/strong> so this is mainstream technology rather than an experiment.<\/li>\n<li><strong>57% of organisations still sign their own staff in with passwords,<\/strong> which is the gap between deploying passkeys and eliminating passwords.<\/li>\n<li><strong>The workforce figures describe companies with 500+ employees.<\/strong> They show the direction of travel, not a benchmark for an eleven-person business.<\/li>\n<li><strong>The unphishable property comes from domain binding,<\/strong> not from the fingerprint \u2014 the biometric never leaves the device and is not what authenticates you.<\/li>\n<li><strong>Nearly half of consumers have abandoned a purchase over a forgotten password,<\/strong> making the login screen a conversion surface as well as a security one.<\/li>\n<li><strong>Start with your two-to-six admin accounts<\/strong> and fix account recovery before customer sign-in; recovery is where an unphishable credential is usually undone.<\/li>\n<li><strong>While a password still works, the phishing risk still exists.<\/strong> Keep it if you must, but keep it as a decision with a review date.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Five billion passkeys are in use and 90% of consumers know the term \u2014 yet 57% of organisations still sign their own staff in with a password. Why passkeys win as an addition and lose as a replacement, and the five steps worth taking on a business website.<\/p>\n","protected":false},"author":5,"featured_media":9113,"template":"","insight_category":[156],"insight_tag":[168,170,186],"class_list":["post-9123","insight","type-insight","status-publish","has-post-thumbnail","hentry","insight_category-trends","insight_tag-business-process","insight_tag-conversion","insight_tag-security"],"acf":[],"_links":{"self":[{"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/insight\/9123","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/insight"}],"about":[{"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/types\/insight"}],"author":[{"embeddable":true,"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/users\/5"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/media\/9113"}],"wp:attachment":[{"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/media?parent=9123"}],"wp:term":[{"taxonomy":"insight_category","embeddable":true,"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/insight_category?post=9123"},{"taxonomy":"insight_tag","embeddable":true,"href":"https:\/\/dextora.agency\/en\/wp-json\/wp\/v2\/insight_tag?post=9123"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}