Consider a hypothetical recovery case: a customer’s phone is stolen on a journey. Her bank application had used a fingerprint prompt to make signing in feel effortless, but the new handset does not yet hold the account credential. The customer has a national ID card, a mobile number and years of account history. The fraud team, correctly, does not want a criminal with the same information to take over the account. The service centre, also correctly, cannot leave her without access to wages, payments or urgent support.
This is where many authentication projects fail. The sign-in demonstration is smooth; the recovery route is improvised. Passkeys address a genuine weakness in password-and-code journeys, but their success is determined by the whole account lifecycle. A passkey programme is not complete when a customer can sign in with a device unlock. It is complete when the organisation can restore legitimate access, revoke compromised credentials and support device change without making fraud or exclusion the price of convenience.
That matters particularly for services whose primary relationship with a customer is through a phone: digital finance, government portals, health platforms, enterprise tools and commerce applications. It is a security decision and a service-design decision at once.
What a passkey changes, and what it does not
A passkey is a public-key credential used to authenticate to an application or website. The private part is held by an authenticator, such as a phone, computer or hardware security key; the service stores the associated public key. The user approves the sign-in through the local mechanism used to unlock the device, such as a PIN or biometric check. The local biometric itself is not sent to the service.
The W3C Web Authentication specification, commonly called WebAuthn, defines the browser API for creating and using these public-key credentials. Level 3 became a W3C Recommendation on 25 August 2026. A credential is scoped to a relying-party identifier, or RP ID, based on a domain name, rather than necessarily to one exact origin. Browser checks and the service’s validation of the origin and RP ID protect the authentication ceremony, including permitted multi-origin arrangements. Unlike a password, there is no shared secret that the user types into a lookalike page and the service stores for later comparison.
This is a meaningful improvement, but it does not prove every assertion often made about “passwordless” systems. A passkey authenticates a credential bound to an account; it does not establish how rigorously the person was identified when the account was created. It does not decide whether a transaction needs additional confirmation. It does not secure a weak customer-support process, a compromised email inbox or a recovery policy that allows an attacker to reset access with easily obtained information.
NIST’s SP 800-63B-4, published in July 2025, provides a useful assurance model, not a claim about Kenyan or other African legal requirements. Authentication Assurance Level 2 (AAL2) requires two distinct factors and an offered phishing-resistant option. AAL3 requires phishing-resistant authentication with a non-exportable, hardware-protected key and two distinct factors; synced credentials are not permitted at that level. A device-bound credential is not automatically AAL3-compliant. A product team should decide the risk of each action before selecting a sign-in method, rather than select a fashionable method and then declare the whole service secure.
Recovery is the security boundary that users will meet
Every credential has lifecycle events. Devices are lost, replaced, repaired, sold, shared within a household or reset. Employees change roles. A user may have an old device nearby, a second trusted device, a hardware key, a recovery code, an established support relationship or none of these. The recovery system must distinguish those situations without treating them all as the same emergency.
The weakest route becomes the attacker’s preferred route. If a financial service adds passkeys but allows a caller to reset an account after answering predictable questions, the security gain can evaporate. If it requires an impossible in-person process for every replacement phone, legitimate customers will find informal alternatives or cease using the service.
A strong design separates restricted service access from full account recovery. A service might offer tightly limited access while a recovery case is assessed, but even view-only access can expose sensitive information. It must not allow weaker evidence to bind a new full-power credential or bypass the account’s assurance target. NIST’s account-recovery requirements distinguish recovery methods by account assurance and identity-proofing level, and require notification. Cooling-off periods, customer notification and restricted high-risk actions can supplement the required proof; they cannot replace it.
Treat support as a controlled channel. Support staff need narrowly defined actions, role-based access, case evidence and escalation rules. They should never need to know a customer’s device PIN or ask for a biometric. They should be able to explain the next step in plain language, record the basis for an exception and trigger revocation of a lost credential. Those controls protect customers and staff from social-engineering pressure.
Device reality should shape the deployment model
Passkeys can be synchronised between a user’s devices by a credential provider, or kept bound to a particular device or security key. Neither approach is universally correct. Synced credentials can make a normal phone upgrade much easier. Device-bound credentials can limit key export in high-risk or tightly managed environments, subject to the authenticator’s actual protections. WebAuthn supports both platform authenticators and roaming authenticators such as USB, Bluetooth Low Energy or NFC security keys.
The right choice depends on the service, the value at risk, the user population, the available support model and the organisation’s ability to operate recovery safely. It is not simply a question of whether people own recent smartphones.
Across African markets, that design must accommodate varied conditions without treating the continent as one use case. A customer may use a lower-spec phone, switch SIMs, share a handset, have intermittent data, or obtain support through an agent network. A workforce application may run on shared computers in a branch or field office. A cross-device flow that assumes a personal laptop and continuous Bluetooth may be elegant in a laboratory and fragile in a real service journey.
This is not an argument for retaining passwords indefinitely. It is an argument for offering more than one safe enrolment and recovery path. For a high-value workforce role, a managed device plus a hardware security key may be suitable. For a consumer service, a passkey on a phone can become the preferred method while an existing verified device, a staged recovery flow and supervised support remain available. The organisation should publish the conditions under which an account can be recovered and test them with real users before forcing a migration.
A passkey is not a reason to collect more identity data
Authentication systems tend to accumulate data because each exception seems to justify another identifier, document or behavioural signal. That can create a large, attractive target and make a simple access problem harder to understand. Passkeys offer a chance to make the normal sign-in path less dependent on reusable secrets and repeated personal-data collection.
Privacy still requires deliberate engineering. A service should retain the public-key credential and the limited metadata needed to manage it, apply strong access control to account and recovery records, log significant lifecycle changes, and set a clear retention purpose for support evidence. It should not mistake local biometric processing for a complete privacy posture. Telemetry, customer identifiers, recovery records, device information and staff access can all expose people if they are poorly governed.
For public services, the distinction between authentication and identity is especially important. A digital credential can show that a returning account is controlled by the same authenticator as before. It does not, by itself, authorise a staff member to access every record connected to a person, nor does it justify copying foundational-identity information into every service database. Use the minimum attributes and assurance needed for the service decision, with clear accountability for the institutions that issue, verify and correct those records.
Measure the recovery journey, not only adoption
A dashboard that counts passkeys enrolled may look encouraging while the service quietly creates support demand or abandons people after a handset change. The operational measures should follow the full journey: successful enrolment, successful normal sign-in, recovery completion time, recovery abandonment, credential revocation after a loss, support escalation, suspected account takeover and false-positive intervention.
Review the data by channel and operating condition. Are customers who use a lower-cost device unable to enrol? Are agents repeatedly working around a recovery control? Does a particular handset migration generate excessive failure? Do new recovery rules reduce fraud but disproportionately delay a group of legitimate customers? These findings should drive a design change, not merely an exception report.
A disciplined rollout can begin with one service and a well-defined group of voluntary users. Establish a baseline for password resets, SMS delivery failure, sign-in abandonment and account-takeover incidents. Test enrolment, device replacement, lost-phone recovery and staff escalation before expanding. Simulate the difficult cases, including a user with no old device, a customer who can only use an assisted channel and a fraudulent request containing convincing personal information.
The new sign-in should leave people with more control
The business case for passkeys is not that every password will disappear at once. It is that services can reduce reliance on a credential model that is easy to phish, reuse and reset badly. The gain becomes durable only when it is joined to clear lifecycle governance and a recovery service that customers can actually use.
Organisations modernising authentication can start by mapping the account-recovery routes that already exist: self-service, contact centre, agent, branch and administrator override. Xelius supports teams to design secure service journeys, assess data and access controls, and build maintainable software around real operating conditions.
A secure sign-in is valuable. A secure way back in, after life changes or a device disappears, is what makes it a dependable public or commercial service.
