Passkey and WebAuthn localization is security language about who is proving what to whom. A user may create a passkey, sign in with an authenticator, approve a biometric check, use a device PIN, scan a QR code for cross-device sign-in, choose among accounts or recover access when a familiar device is unavailable. Searches for passkey localization, WebAuthn translation, biometric sign-in localization, passwordless authentication translation, security key localization and passkey recovery UI all point to the same risk: a fluent target string can still be unsafe if it changes which identity is being verified, what credential is created or what fallback the user expects.
Good localization preserves the security model while making the experience understandable. A passkey is not simply “a password stored on your phone”. A fingerprint or face check is often a local method used to unlock an authenticator; the relying service does not need the user’s biometric template merely because the interface says “use your fingerprint”. A security key is an authenticator, but not every authenticator is a removable security key. “Verify it’s you” can mean local user verification, account reauthentication or a higher-risk approval step depending on the product. Those distinctions belong in the translation brief.
This guide explains how to localize passkeys, WebAuthn and biometric sign-in without changing identity, consent or recovery meaning. It covers registration, authentication, account choice, relying-party identity, authenticator selection, user presence, user verification, biometrics, PINs, security keys, synced passkeys, device-bound credentials, QR-based cross-device flows, resident credentials, display names, discoverable sign-in, fallback, account recovery, step-up authentication, error states, privacy, accessibility and the release question that matters most: would a target-language user know which account, device and credential they are authorizing at every step?
This article belongs to eduKateSG’s Master Art of Translation architecture. It extends the narrower passkey and WebAuthn layer without competing with the existing guide to login, MFA and password recovery, the guide to SSO, SAML and SCIM, or the guide to OAuth consent and third-party integrations.
Quick answer: translate the journey, preserve the credential and identity boundaries
A passkey flow has several layers that must remain distinct. The account belongs to a relying service. The credential is associated with that relying party and an account. The authenticator may be a device, security key or platform service. User verification may use a biometric or PIN locally. The website or app receives an authentication result rather than a copy of the user’s fingerprint or face. Recovery may involve a synced credential, another authenticator, an account recovery channel or a separate administrative process.
- Identity: keep the service, account and credential relationship clear.
- Registration: distinguish creating a passkey from signing in with one.
- Authenticator: name the device or security mechanism without implying more access than exists.
- Verification: distinguish local biometric or PIN verification from server-side identity claims.
- Fallback: explain alternative sign-in and recovery paths without making them sound equivalent.
- Verify: test real registration, sign-in, cancellation and recovery states in each target locale.
1. Start with the security journey, not the label “passkey”
The word passkey is only one visible part of a larger process. A user may first identify an account, then create a credential, then later authenticate with that credential, sometimes without typing a username. Translators need the full journey because the same short action word can appear during registration, authentication and recovery while meaning something different in each place.
Map at least four paths: create a passkey, sign in with a passkey, sign in from another device and recover when the usual credential is unavailable. Mark where the operating system or browser owns the prompt and where the application owns the text. That boundary matters because inconsistent terminology between system and app can make users think they are authorizing two different things.
Verification: run the complete flow and label each screen as application, browser, operating system or authenticator UI.
2. Distinguish passkey creation from passkey sign-in
Creating a passkey registers a new public-key credential for an account. Signing in uses an existing credential to prove control of the authenticator and satisfy the service’s authentication request. The target language should make those actions distinct.
“Create passkey”, “Save passkey” and “Add passkey” can each be appropriate depending on product language, but they should not be used where the user is merely authenticating. Likewise, “Sign in with passkey” should not imply a new credential will be stored. This is especially important in account settings, where creation and removal appear beside everyday sign-in controls.
Verification: observe whether a new credential appears in account settings after each localized action.
3. Preserve the relying-party identity
WebAuthn credentials are scoped to a relying party. The user should know which website, app or service is requesting authentication. Product branding, domain context and account labels must not drift across localized flows.
Do not translate domain names, relying-party identifiers or technical origins as ordinary text. A friendly service name can be localized if the brand policy allows it, but the security boundary should remain recognizable. If a passkey prompt appears for a different subdomain or environment, the application should not hide that fact behind a generic translated brand name.
Verification: compare the target-language prompt with the actual relying-party identifier and the account the credential will belong to.
4. Keep account display name separate from credential identity
A passkey can be associated with a user handle, account identifier and display name. Display names may change; stable internal identifiers should not. Translators should not treat account names or email addresses as translatable UI copy.
In an account chooser, the surrounding labels translate while the user’s actual account data remains exact. A person named Summer should not become the target-language word for the season. An email address should not be rewritten to match local punctuation. If the service allows localized profile names, that is user data, not ordinary interface translation.
Verification: test names containing accents, non-Latin scripts, emoji and right-to-left text in passkey account pickers.
5. Explain authenticator without turning every device into a “security key”
An authenticator can be built into a device, provided by a platform, stored on a removable hardware security key or reached through another device. “Security key” usually refers to a narrower class of authenticators and should not become the universal target term.
User-facing interfaces can often avoid the abstract word authenticator and say “this device”, “another device” or “security key” where the product knows the option. Technical help can retain authenticator as the umbrella concept. The localization goal is to make the choice concrete without misclassifying the mechanism.
Verification: test platform, roaming security-key and cross-device paths and confirm the target labels remain accurate for each.
6. Separate user presence from user verification
User presence generally means the authenticator confirms a person is actively participating, such as by touching a security key. User verification adds stronger local verification, such as a device PIN or biometric check. The concepts can be represented differently by platforms but should not be collapsed in technical or administrative localization.
A message equivalent to “Touch your security key” describes presence. “Verify with your device PIN” describes verification. If a product requirement specifically needs user verification, do not translate a fallback presence-only experience as equivalent assurance.
Verification: inspect authentication policy and confirm the target flow distinguishes simple interaction from verified local user identity where the product does.
7. Explain biometrics as local verification
When a device asks for a fingerprint or face check to unlock a passkey, the biometric process is typically local to the authenticator. The service receives a cryptographic authentication result rather than the biometric template itself. Product copy should not imply that the website is collecting the fingerprint merely because the user sees biometric UI.
Use wording such as “Use your fingerprint to unlock this passkey” when that accurately describes the platform. Avoid “Send your fingerprint to continue” or other phrasing that changes the privacy model. If the platform owns the biometric prompt, application copy should not contradict it with broader claims.
Verification: review the target text against the actual data flow and privacy documentation for the authenticator.
8. Treat device PIN as another local verification method
A device PIN used to unlock an authenticator is not necessarily the account password. Translating it as “password” can make users enter the wrong secret or believe the service stores the device credential.
Use the platform’s established target-language term for device PIN, passcode or local credential. If the application explains fallback from biometric to PIN, make clear that the choice belongs to the device or authenticator. Do not invent a service-specific PIN requirement when the operating system is handling verification.
Verification: disable biometrics and confirm the fallback prompt still makes sense without the account password.
9. Keep passwordless from becoming “no security”
Passwordless sign-in removes or reduces password use; it does not remove authentication. A literal target phrase equivalent to “login without security” would be badly misleading. Marketing language should still preserve that the user is proving control of a credential.
When a product offers password and passkey side by side, describe passkey as an alternative sign-in method rather than as the absence of a method. If the service eventually disables passwords after passkey enrollment, explain that policy separately from the technical meaning of passkey.
Verification: read the target copy to users unfamiliar with passkeys and ask what they believe protects the account.
10. Translate “use another device” as a real security path
Cross-device sign-in may let a user authenticate on one device using a passkey available on another. The target language should make clear which device is being used to continue and that the user is not simply moving the session visually.
“Use a passkey from another device” is clearer than a vague “Use another device” when passkey choice is the point. If the flow requires scanning a QR code and keeping devices nearby, explain those steps in order. Do not call it account transfer if no account data is being migrated.
Verification: complete the flow with a phone authenticating a browser on another device and confirm the target instructions identify the role of each device.
11. Treat QR codes as machine-readable handoff, not translated content
A QR code used in a cross-device authentication flow carries machine-readable data. The code itself should not be altered by localization. The instruction around it can be translated.
Use verbs that reflect the real action: “Scan this QR code with the device that has your passkey.” Avoid “photograph the code” if ordinary camera capture would not complete the flow. If the code expires, show that state clearly and offer a fresh code rather than a generic retry.
Verification: scan the code from every target-language screen and confirm the payload and expiry behavior remain unchanged.
12. Preserve proximity meaning in cross-device authentication
Some cross-device authentication flows use proximity signals to help ensure the approving device is near the requesting device. User instructions may say “keep your devices close together”. That is a security requirement, not decorative advice.
Translate proximity instructions so users understand physical closeness rather than network similarity. “On the same network” and “nearby” are not equivalent. If Bluetooth or another local mechanism is involved, avoid telling users to pair devices unless actual pairing is required.
Verification: test the flow with devices near and far apart and compare target instructions with actual success conditions.
13. Distinguish synced passkeys from device-bound credentials
Some passkeys can be synchronized across a user’s compatible devices through a credential provider; other credentials may remain on one authenticator. The target language should not promise “available on all your devices” unless the product knows that synchronization applies.
Where the distinction matters, describe storage and availability carefully: “Saved with your credential provider” or “Stored on this security key” may be appropriate. Avoid language that exposes implementation detail without benefit, but never reassure users about cross-device availability that the system cannot guarantee.
Verification: create credentials through each supported path and check whether they are usable from another device under the documented conditions.
14. Explain credential provider without assuming one brand
A credential provider may store or manage passkeys for the user. Product copy should avoid hard-coding one ecosystem’s terminology when the flow can involve several providers.
If the operating system presents the provider picker, let platform UI name the provider. Application help can use a neutral term such as “your passkey provider” and explain that availability depends on the user’s device and settings. Brand names and provider identifiers should remain exact.
Verification: test more than one provider configuration and ensure the target application copy still makes sense.
15. Keep discoverable sign-in distinct from username-first sign-in
Some passkey flows can present available accounts without requiring the user to type a username first. Other flows begin with account identification and then request a passkey for that account. The UI language should match the order.
A button labeled “Sign in with a passkey” may launch account discovery. After the user chooses an account, the app should not ask again for an email unless another policy requires it. Conversely, if the flow is account-specific, the prompt should make clear which account is being authenticated.
Verification: test with one account and several accounts available to the authenticator and inspect account-selection wording.
16. Preserve account-choice scope
An account chooser may show service accounts, device accounts or passkey credentials. Users need to know whether choosing an item selects an identity, a credential source or both.
Translate headings such as “Choose an account” or “Choose a passkey” according to the object actually listed. If one account has several credentials, avoid collapsing them in language if the user is expected to choose among devices or security keys. If the platform manages the choice automatically, do not add unnecessary application-level instructions.
Verification: create multiple credentials for one account and multiple accounts with credentials, then inspect the localized chooser behavior.
17. Treat credential names as user or system data, not ordinary translation
Products may let users name passkeys or display labels such as “Phone”, “Laptop” or “Security key”. Some are generated by the system; others are user-entered. The source of the name should decide whether it is translated.
User-entered names should remain as entered. System-generated device categories can be localized if they are presentation labels. Model names, hardware identifiers and provider names should generally remain exact. If the product shows “Created on 12 Sep” beside the label, localize date formatting while preserving the underlying timestamp.
Verification: inspect passkey lists containing user names, system labels and hardware identifiers together.
18. Localize remove-passkey actions without implying account deletion
Removing a passkey usually removes one sign-in credential from an account. It does not necessarily delete the account, sign out all devices or erase the credential from a separate provider. The target language should state the scope.
“Remove this passkey from your account” is safer than a generic “Delete access”. If the passkey remains stored in a credential provider after server-side removal, the product may need to explain that it can no longer sign in to this account. If the application can trigger local deletion as well, distinguish the two actions.
Verification: remove the server-side credential and inspect what remains on the authenticator or credential provider.
19. Distinguish revoke, remove and disable
Security administration interfaces may use revoke, remove or disable with different semantics. Revoke can mean the service no longer accepts the credential. Remove can mean deleting the credential record. Disable can mean temporarily preventing use while keeping the record.
Do not choose target words based only on tone. Document what can be reversed, what data remains and what the user sees afterward. If an administrator disables a credential, the account holder may need a message explaining why it cannot be used without suggesting the credential itself is damaged.
Verification: perform each administrative action and compare reversibility and resulting credential list state.
20. Translate registration failure around the real cause
Passkey creation can fail because the user cancels, an authenticator is unavailable, policy disallows the operation, the browser lacks required support, a duplicate credential condition occurs or the request expires. A generic “Something went wrong” should be the fallback, not the default.
Where the product can identify the cause safely, pair it with the right action. “Passkey creation was cancelled” needs no alarm. “This security key cannot be used for this account” needs a different method. “Request expired” can offer Try again. Avoid blaming the user for system or policy conditions.
Verification: create fixtures for cancellation, timeout, unsupported method and policy rejection.
21. Treat authentication cancellation as a user decision, not an error
Closing or cancelling an authenticator prompt may simply mean the user changed their mind. Red error language can make the action feel more serious than it is.
Return the user to a safe sign-in state and offer another method where appropriate. “Passkey sign-in cancelled” is enough in many contexts. If the user was approving a high-risk action rather than ordinary sign-in, the application may need to say that the action was not approved.
Verification: cancel at each authenticator stage and confirm no target message falsely says credentials are invalid.
22. Keep credential-not-found separate from account-not-found
The service may know the account but have no matching passkey. Or the authenticator may have no credential for the requested relying party. These are different from an unknown account.
Public sign-in screens also need to consider information disclosure: highly specific errors can reveal whether an account exists. Localization should preserve the product’s security decision about how much detail to expose. Administrative tools can often be more explicit because the audience is authorized.
Verification: test known accounts with no passkey, unknown accounts and valid passkey accounts under the same target locale.
23. Preserve timeout and expiry semantics
An authentication request can expire. A QR handoff can expire. A browser can stop waiting. These states do not necessarily mean the credential is invalid.
Use language such as “This sign-in request expired. Try again.” rather than “Your passkey expired” unless the passkey itself has an expiration property in the product. The distinction protects users from deleting or recreating credentials unnecessarily after a transient timeout.
Verification: deliberately let requests expire and confirm the target recovery action starts a fresh request without implying credential loss.
24. Keep passkey recovery separate from account recovery
If a user loses one device, a synced passkey may still be available elsewhere. If no usable passkey is available, the user may need another sign-in method or account recovery. These are different pathways.
Do not label every fallback “Recover passkey”. The service may not be able to recreate the lost credential at all; it may only help the user regain account access and then register a new passkey. Target language should describe what is being recovered: account access, not necessarily the original credential.
Verification: simulate lost-device scenarios with and without another synced or registered authenticator.
25. Translate fallback methods without implying equal strength
Products may offer password, one-time code, recovery code, email link, security key or support-assisted recovery beside passkeys. The methods do not necessarily provide equivalent assurance.
User-facing copy can simply say “Try another way” without ranking methods, while later screens explain each option. Administrative and security documentation may need to state which methods satisfy particular policies. Do not translate a fallback as “same security” unless the service explicitly treats it that way.
Verification: review policy decisions for each fallback and compare them with the target-language promises.
26. Keep step-up authentication distinct from initial sign-in
A signed-in user may be asked to authenticate again before changing security settings, exporting sensitive data or approving a payment. That is not a second ordinary login; it is a higher-confidence check tied to an action.
Translate the reason: “Verify it’s you to remove this passkey” or “Confirm your identity before changing recovery options.” This helps users recognize legitimate prompts and resist unrelated prompts that appear without context. The target wording should also make clear which action will continue after successful verification.
Verification: trigger step-up from several sensitive actions and confirm the target prompt preserves action context.
27. Explain attestation only to audiences who need it
Some organizations use authenticator attestation or related device information for policy. This is a specialist concept and usually should not appear in consumer UI without a clear reason.
In administrative interfaces, translate attestation consistently with security documentation and describe what evidence is evaluated. Avoid saying the service “verifies the device is genuine” if the actual policy only checks a subset of metadata or allowed authenticator properties. Strong security claims need precise evidence.
Verification: compare target-language policy text with the actual attestation fields and enforcement rules.
28. Preserve user-verification requirements in policy UI
Enterprise settings may require, prefer or discourage local user verification. Those options can look like ordinary preference language but change authentication assurance.
Translate requirement levels as policy, not suggestion. “Required” should remain mandatory; “Preferred” should not become “recommended to users” if the protocol meaning is that the authenticator should perform verification when possible. Explanatory text should distinguish policy behavior from end-user advice.
Verification: test authenticators with different capabilities under each localized policy value.
29. Keep browser or platform prompts aligned with app language
Passkey journeys cross ownership boundaries. The application can be translated perfectly and still confuse users if it calls the credential one thing while the operating system calls it another.
Use terminology established by the target platform where practical. If your product has a broader branded term, bridge it explicitly in help text. Avoid re-translating system terms into an internally preferred phrase that users will never see elsewhere on the device.
Verification: place application copy and system prompts side by side in each target locale and identify terminology drift.
30. Preserve phishing-resistant claims carefully
Passkey and WebAuthn systems can provide strong resistance to common phishing patterns because credentials are scoped to relying parties and authentication uses public-key cryptography. However, product copy should avoid absolute security promises such as “impossible to phish”.
Translate claims with the same scope and caution as the source: “helps protect against phishing” or a documented policy-specific statement. A user can still be socially engineered into other harmful actions, and account recovery paths can have their own risks. Security benefit should be explained without turning it into invulnerability.
Verification: security reviewers should approve the target claim as semantically equivalent, not merely grammatically fluent.
31. Localize privacy explanations around what the service does not receive
Users may fear that biometric sign-in sends fingerprints or face images to websites. A concise explanation can reduce that fear when it is accurate: the biometric check happens on the user’s device or authenticator, and the service receives the authentication result rather than the biometric template.
Do not overgeneralize beyond the product’s architecture. If separate identity verification features upload images or documents, keep those flows linguistically separate from passkey biometrics. “We never receive biometric data” is broader than “Your biometric check for this passkey happens on your device.”
Verification: review the target privacy sentence against the exact authentication data flow.
32. Make security-key insertion and touch instructions physical
Hardware security keys require actions such as insert, tap, touch or hold near the device depending on connection type. Literal translations can fail if the same verb means “press” in one context and “touch lightly” in another.
Write instructions around observable action: “Insert your security key”, “Touch the key when it flashes”, “Hold your key near the top of the phone”. If multiple connection methods are supported, avoid an instruction that assumes USB when wireless or contactless use is possible.
Verification: follow the target instructions with each supported hardware form factor without source-language help.
33. Test accessibility of account and authenticator choosers
Authentication UI must work for screen-reader, keyboard and switch users. Accessible names should distinguish accounts, passkeys, security keys and action buttons without exposing unnecessary sensitive information.
If a list contains two credentials with similar names, include enough context such as device label or creation date for the user to choose. Do not rely only on color or icon. For QR-based handoff, provide alternative instructions when the user cannot visually scan the screen.
Verification: complete passkey creation and sign-in using a screen reader and keyboard in the target language.
34. Test cancellation and interruption at every ownership boundary
A user can cancel in the application, dismiss a browser prompt, fail local verification, remove a security key or let a QR request expire. The resulting application state should reflect what actually happened rather than showing one generic failure.
Map cancellation across each layer and decide which messages the application can know reliably. If the browser only returns a generic error, do not invent a more specific target explanation than the source evidence supports. Recovery should offer a fresh sign-in attempt or another method as appropriate.
Verification: interrupt every step and compare the target message with the layer that owned the cancellation.
35. Build regression tests around account safety, not string presence
A passkey screen can be fully translated and still be unsafe if account names are mixed, a remove action affects the wrong credential, a fallback is mislabeled or a biometric sentence changes the privacy meaning.
Create end-to-end regression cases for one account, several accounts, one device, several authenticators, lost device, synced passkey, hardware key, cancellation, expired request, removed credential and recovery. Record the expected account and credential at every step. The localization pass should prove that target-language users make the same security decisions as source-language users.
Verification: run those cases after any authentication, platform or terminology change rather than treating localization as a one-time launch task.
A repeatable passkey and WebAuthn localization workflow
- Map registration, sign-in, cross-device use, removal and recovery as separate flows.
- Mark application, browser, operating-system and authenticator-owned screens.
- Protect relying-party IDs, domains, account data and machine identifiers.
- Define passkey, authenticator, security key, user presence and user verification in the glossary.
- Explain biometrics and device PINs as local verification where that matches the architecture.
- Separate registration from authentication in action labels.
- Document synced and device-bound credential behavior without overpromising availability.
- Keep account recovery distinct from recovering a specific passkey.
- Map fallback methods and policy strength separately.
- Test account choosers with multiple identities and multiple credentials.
- Test cancellation, timeout and unsupported authenticator states.
- Run accessibility and cross-device tests in every priority locale.
Worked scenario 1: creating a passkey after password sign-in
A user signs in with an existing method and opens Security settings. The page offers Add passkey. The action is registration, not authentication, so the target language should say the account is about to gain a new sign-in credential.
The platform asks the user to verify locally with a biometric or device PIN. That local verification unlocks the authenticator; the website does not need the biometric template. After successful registration, the account settings page lists the new credential with a device or provider label and creation date.
A useful success message is “Passkey added. You can use it to sign in to this account.” It does not say the password was deleted unless the product separately changed password policy. Registration success and password removal are different facts.
Worked scenario 2: signing in from a laptop with a passkey on a phone
A user opens the sign-in page on a laptop and chooses Use a passkey. The browser offers a cross-device option and displays a QR code. The localized application should explain that the user can use a passkey from another device, not that the account is being transferred to the phone.
The user scans the QR code with the phone, confirms the relying service and completes local verification. The laptop receives the authentication result and signs in. At no point should the target copy imply that the phone’s biometric image is sent to the laptop website.
This scenario demonstrates three separate identities: the laptop session requesting access, the phone authenticator holding or accessing the passkey, and the service account being authenticated. Clear localization keeps all three roles understandable.
Worked scenario 3: a user loses a device and thinks the passkey is lost
A user replaces a phone. If the passkey was synchronized through a credential provider, it may still be available on the new device after the provider account is restored. If it was device-bound, it may not be. The service should not make a universal promise either way.
The target recovery screen can say: “Try your passkey on another device or choose another sign-in method.” If no passkey is available, the user may recover account access through another approved path and then create a new passkey. Calling this “recover your old passkey” would be misleading if the original credential cannot be reconstructed.
After successful account recovery, the service can show old registered credentials and let the user remove ones associated with the lost device where appropriate.
Worked scenario 4: removing one passkey without deleting the account
An account has three registered passkeys. The user chooses one labeled “Old laptop” and taps Remove. The confirmation should identify the credential and explain the scope: that passkey will no longer sign in to this account. The account itself remains active and the other passkeys remain registered.
If the credential also exists in an external credential provider, removing the server-side registration may not erase the local provider entry automatically. The target success message should avoid promising that the passkey has been deleted everywhere unless the product controls that process.
This is why verbs such as remove, revoke and delete need operational definitions before translation. They describe different scopes across systems.
Release checklist for passkey, WebAuthn and biometric sign-in localization
- Passkey creation and passkey sign-in use distinct action language.
- Relying-party identity, domains and technical identifiers remain exact.
- User display names and account data are not translated as UI copy.
- Authenticator and security key are not treated as universal synonyms.
- User presence and user verification remain distinct where policy depends on them.
- Biometric wording reflects local verification rather than biometric transfer.
- Device PIN or passcode is not mislabeled as the account password.
- Passwordless language still communicates that authentication is occurring.
- Cross-device instructions identify which device has or uses the passkey.
- QR payloads remain untouched by translation.
- Proximity instructions are not confused with pairing or same-network requirements.
- Synced and device-bound credential availability is described accurately.
- Account chooser labels match whether the object is an account, credential or provider.
- Remove, revoke and disable actions preserve scope and reversibility.
- Cancellation is not mislabeled as credential failure.
- Request expiry is not described as passkey expiry.
- Passkey fallback is distinct from account recovery.
- Step-up prompts name the sensitive action being approved.
- Security claims preserve source scope and avoid absolute promises.
- Accessibility testing covers account choice, authenticator choice and cross-device flows.
Frequently asked questions
Is a passkey just a password stored on a device?
No. A passkey is based on public-key credentials associated with a service and account. The user does not type a shared secret that the service compares as a password. Localization should avoid teaching a false password mental model simply because it feels familiar.
Does biometric sign-in send my fingerprint or face to the website?
In standard passkey use, the biometric check is typically performed locally by the device or authenticator to unlock the credential. The service receives an authentication result, not the biometric template. Product wording should reflect the exact implementation and avoid broader claims than the architecture supports.
Is a security key the same as a passkey?
A security key is a type of authenticator that can hold or use credentials. A passkey is the credential used for authentication. The concepts are related but not interchangeable.
What does “use another device” mean?
It can mean using a passkey available on another nearby device to authenticate the session you are starting here. It does not necessarily transfer the account or credential to the current device.
Can a lost passkey be recovered?
It depends on how the credential is stored. A synchronized passkey may be available through another compatible device or provider. A device-bound credential may not be recoverable. The service may instead help the user recover account access and register a new passkey.
Should “passkey” always be translated?
Follow target-platform and market conventions. In some languages the established product term may be a localized equivalent; in others the English loanword may be familiar. Consistency with browser and operating-system terminology matters because the user moves across those surfaces during authentication.
What is the difference between removing and disabling a passkey?
That depends on the product. Removing often deletes or revokes the account’s registration for the credential, while disabling may preserve the record but prevent use temporarily. Translate from actual behavior, not from assumed dictionary differences.
What should be tested first?
Test one complete registration and sign-in journey, then a cross-device journey, a cancellation, a lost-device fallback and a credential removal. Use multiple accounts where possible. Those flows reveal identity and scope errors that isolated string review misses.
Final principle: security language should clarify trust, not decorate it
Passkeys can make authentication feel simpler, but the system underneath remains precise. There is a relying service, an account, a credential, an authenticator, a local verification step and a recovery model. Users do not need protocol diagrams to sign in, but they do need language that keeps those relationships trustworthy.
Professional localization makes the secure path easier to understand without inventing guarantees. It does not turn a biometric check into biometric data sharing, a device PIN into an account password, a request timeout into a dead credential, or account recovery into recovery of a specific lost passkey. When the target language preserves identity, scope, consent and fallback, the security model remains intact even as the words change.