Translate Like a Pro | Login, MFA & Recovery Localization

Authentication language is security language. A mistranslated login prompt, MFA challenge or password-recovery instruction can cause more than confusion: it can train users to approve the wrong action, reveal secrets, abandon stronger authentication or misunderstand whether a code proves identity, authorizes a transaction or merely confirms possession of one device.

Searches for authentication localization, login translation, MFA localization, password reset translation, OTP localization, passkey localization, security message translation and password recovery localization describe a high-stakes localization job. NIST SP 800-63B-4, published in 2025, is the current US federal guidance focused on authentication and authenticator management, reinforcing how precisely authentication states and authenticator types need to be distinguished.

This guide explains how to localize sign-in, password, passkey, one-time code, authenticator-app, recovery and reauthentication flows without changing their security semantics. It covers actor and device identity, code secrecy, action confirmation, phishing-resistant authenticators, recovery codes, rate-limit messages, lockouts, account enumeration, help text, channel consistency and in-context security review.

This article is part of eduKateSG’s Master Art of Translation architecture. It extends the professional localization layer without taking ownership away from the established translation, terminology, file-preparation, release or quality owners.

Quick answer

Preserve the exact security state first, then translate. The target text must make clear who is authenticating, which account or device is involved, what the user must do, what information must remain secret, whether the step proves identity or simply continues a recovery process, and what happens if the action was not initiated by the user. Security meaning outranks stylistic elegance.

Model the state: sign-in, enrollment, challenge, recovery and approval are distinct.
Name the authenticator: password, passkey, security key, authenticator app, code and recovery code are not synonyms.
Protect secrets: never suggest sharing passwords or one-time codes.
Clarify action: tell users exactly what they are approving.
Limit leakage: error messages should follow product security policy.
Recover safely: recovery is a security-sensitive lifecycle, not ordinary help copy.
Test: run genuine and hostile-looking scenarios in context.

1. Translate authentication states as distinct concepts

Login, enrollment, verification, reauthentication, approval and recovery are different security states. Using one generic verb can hide what evidence the system is asking for.

Professional method. Map every screen and message to the product’s authentication state machine before translating. The decision should be documented so that another translator, reviewer, designer or engineer can apply the same rule to the next occurrence without reconstructing the whole problem from memory.

Failure mode. A target uses ‘verify’ for both email ownership and transaction approval. Entering a code to enroll an authenticator is not the same action as approving a new sign-in.

Verification. Ask a reviewer to describe what security state follows each message. If the result still depends on guesswork, return to authoritative locale data, source meaning, product context or the system that owns the underlying fact.

2. Keep authenticator names precise

Password, passkey, security key, authenticator app and one-time code are not interchangeable. Users need to know which credential or device the system expects.

Professional method. Use the product’s approved security terminology and current platform names, with explanatory text where the concept is unfamiliar. The decision should be documented so that another translator, reviewer, designer or engineer can apply the same rule to the next occurrence without reconstructing the whole problem from memory.

Failure mode. A translator calls a passkey a password because both allow sign-in. A hardware security key may need a distinct localized term from a passkey stored on a phone.

Verification. Match the translated label to the actual authenticator type used in the flow. If the result still depends on guesswork, return to authoritative locale data, source meaning, product context or the system that owns the underlying fact.

3. Do not imply that MFA always means SMS

Multi-factor authentication can use different authenticator types. Localization that equates MFA with text-message codes becomes wrong when users choose an authenticator app, security key or passkey.

Professional method. Use generic factor language only at choice screens and specific labels once the authenticator is known. The decision should be documented so that another translator, reviewer, designer or engineer can apply the same rule to the next occurrence without reconstructing the whole problem from memory.

Failure mode. The help centre says ‘Enter the SMS code’ even for authenticator-app users. A challenge screen can say ‘Enter the code from your authenticator app’.

Verification. Run every supported authenticator path. If the result still depends on guesswork, return to authoritative locale data, source meaning, product context or the system that owns the underlying fact.

4. Protect one-time codes as secrets

Authentication codes should be treated as sensitive security values. Users are commonly targeted by phishing and social engineering that asks them to reveal codes.

Professional method. Translate warnings unambiguously and preserve any product policy stating not to share a code. The decision should be documented so that another translator, reviewer, designer or engineer can apply the same rule to the next occurrence without reconstructing the whole problem from memory.

Failure mode. A literal translation softens ‘Never share this code’ into optional advice. A message can state that support staff will not ask for the code if that is true for the service.

Verification. Have a security owner review code-related messages. If the result still depends on guesswork, return to authoritative locale data, source meaning, product context or the system that owns the underlying fact.

5. Make approval prompts transaction-specific

Users should understand what action they are approving. Generic ‘Approve?’ dialogs are vulnerable to habitual confirmation.

Professional method. Include device, location, account, transaction or other product-approved context where available and safe. The decision should be documented so that another translator, reviewer, designer or engineer can apply the same rule to the next occurrence without reconstructing the whole problem from memory.

Failure mode. The target-language prompt says only ‘Confirm’ while the source says ‘Approve sign-in on a new device’. A push MFA request can identify that it is a login request rather than a payment approval.

Verification. Test whether a user can distinguish two different approval types from the wording alone. If the result still depends on guesswork, return to authoritative locale data, source meaning, product context or the system that owns the underlying fact.

6. Preserve denial and rejection options clearly

Security prompts need a visible path for ‘This was not me’. Users must be able to reject suspicious requests.

Professional method. Translate allow/deny actions as true opposites and test button order, colour and accessibility labels. The decision should be documented so that another translator, reviewer, designer or engineer can apply the same rule to the next occurrence without reconstructing the whole problem from memory.

Failure mode. Two target buttons both sound like variations of ‘continue’. Approve and Deny should remain semantically unambiguous even when UI conventions change.

Verification. Ask a native reviewer which button they would press for an unexpected request. If the result still depends on guesswork, return to authoritative locale data, source meaning, product context or the system that owns the underlying fact.

7. Distinguish password change from password reset

A password change usually starts from an authenticated session; a reset is account recovery. The risk, evidence and user expectations differ.

Professional method. Use separate terms and flows in the target language, aligned to product state. The decision should be documented so that another translator, reviewer, designer or engineer can apply the same rule to the next occurrence without reconstructing the whole problem from memory.

Failure mode. Help text says ‘change password’ while the user has forgotten it and must recover the account. A settings screen and a recovery email should not use one generic action label.

Verification. Follow both flows and compare terminology. If the result still depends on guesswork, return to authoritative locale data, source meaning, product context or the system that owns the underlying fact.

8. Treat account recovery as a high-risk process

Recovery can bypass normal authenticators. NIST authentication guidance treats authenticator lifecycle and recovery as security-sensitive management.

Professional method. Translate proofing requirements, delays, recovery codes and support escalation exactly; do not simplify away conditions. The decision should be documented so that another translator, reviewer, designer or engineer can apply the same rule to the next occurrence without reconstructing the whole problem from memory.

Failure mode. A translator removes a waiting-period qualifier because it sounds bureaucratic. A recovery process may intentionally delay high-risk changes.

Verification. Compare target instructions against the actual recovery policy and system behavior. If the result still depends on guesswork, return to authoritative locale data, source meaning, product context or the system that owns the underlying fact.

9. Keep recovery codes distinct from one-time login codes

Recovery codes may be long-lived emergency credentials rather than ordinary transient OTPs. Users need to store and handle them differently.

Professional method. Use an explicit target term and explain storage/use constraints accurately. The decision should be documented so that another translator, reviewer, designer or engineer can apply the same rule to the next occurrence without reconstructing the whole problem from memory.

Failure mode. The target calls every numeric token a ‘verification code’. A set of backup codes can be downloaded and stored securely for future account recovery.

Verification. Check the target instructions against the code lifecycle. If the result still depends on guesswork, return to authoritative locale data, source meaning, product context or the system that owns the underlying fact.

10. Translate passkey explanations without promising too much

Passkeys can improve phishing resistance, but product behavior depends on platform and implementation. Marketing-style translation can overstate universality or device availability.

Professional method. Preserve the source’s actual claims and name platform sync or device requirements where the product provides them. The decision should be documented so that another translator, reviewer, designer or engineer can apply the same rule to the next occurrence without reconstructing the whole problem from memory.

Failure mode. The target says passkeys ‘cannot be stolen’ when the source says they are phishing-resistant. A passkey prompt can explain using a device unlock method without revealing internal cryptographic detail.

Verification. Security/product reviewers approve the localized claim strength. If the result still depends on guesswork, return to authoritative locale data, source meaning, product context or the system that owns the underlying fact.

11. Handle lockout and rate-limit messages carefully

Security systems may intentionally limit attempts. Messages can leak account existence, rate thresholds or defensive details if translated or expanded carelessly.

Professional method. Follow source/product security policy and do not add diagnostic detail not present in the approved source. The decision should be documented so that another translator, reviewer, designer or engineer can apply the same rule to the next occurrence without reconstructing the whole problem from memory.

Failure mode. A translator helpfully explains the exact lockout threshold when the product intentionally avoids it. A generic ‘Try again later’ may be deliberate.

Verification. Security owner confirms that the target does not reveal extra system information. If the result still depends on guesswork, return to authoritative locale data, source meaning, product context or the system that owns the underlying fact.

12. Avoid account enumeration through localization

Sign-in and recovery errors may intentionally avoid saying whether an account exists. A specific target translation can accidentally defeat that protection.

Professional method. Preserve equivalently generic wording when product security requires it. The decision should be documented so that another translator, reviewer, designer or engineer can apply the same rule to the next occurrence without reconstructing the whole problem from memory.

Failure mode. Source says ‘If an account exists, we’ll send a link’ but target says ‘We sent a link to your registered email’. Recovery confirmation can remain noncommittal until identity is established.

Verification. Test existing and non-existing accounts and compare user-visible messages. If the result still depends on guesswork, return to authoritative locale data, source meaning, product context or the system that owns the underlying fact.

13. Preserve device and session distinctions

Current device, trusted device, remembered browser and active session are different objects. Users act differently depending on which one is being revoked or trusted.

Professional method. Use a controlled terminology set tied to product definitions. The decision should be documented so that another translator, reviewer, designer or engineer can apply the same rule to the next occurrence without reconstructing the whole problem from memory.

Failure mode. A target says ‘log out this device’ while the action revokes all sessions. Security settings can distinguish ‘Sign out this session’ from ‘Sign out everywhere’.

Verification. Perform the action and confirm the label matches the resulting state. If the result still depends on guesswork, return to authoritative locale data, source meaning, product context or the system that owns the underlying fact.

14. Keep phishing-warning language action-oriented

Security warnings must help users choose safely. Abstract technical jargon can be translated correctly yet fail as protective communication.

Professional method. Preserve factual threat language while telling users the safe next step, exactly within approved policy. The decision should be documented so that another translator, reviewer, designer or engineer can apply the same rule to the next occurrence without reconstructing the whole problem from memory.

Failure mode. A warning says ‘This might be phishing’ but offers no clear safe action. A product can tell users not to enter a code into a site reached from an unexpected message.

Verification. Usability/security review confirms the user can act safely. If the result still depends on guesswork, return to authoritative locale data, source meaning, product context or the system that owns the underlying fact.

15. Coordinate email, SMS and in-app security wording

Authentication flows often cross channels. If the email calls something a verification code and the app calls it a security token, users may distrust the legitimate flow.

Professional method. Use shared authenticator terminology across transactional messaging and product UI. The decision should be documented so that another translator, reviewer, designer or engineer can apply the same rule to the next occurrence without reconstructing the whole problem from memory.

Failure mode. Each channel is localized by a different team. The same password-reset event should use consistent account and action names in email and app.

Verification. Walk the full cross-channel recovery path. If the result still depends on guesswork, return to authoritative locale data, source meaning, product context or the system that owns the underlying fact.

16. Localize security help without exposing secrets

Help text can explain process without revealing internal defensive implementation. Translators may expand terse source copy in ways security did not approve.

Professional method. Keep additions within the approved support content and route deeper detail to official security documentation. The decision should be documented so that another translator, reviewer, designer or engineer can apply the same rule to the next occurrence without reconstructing the whole problem from memory.

Failure mode. The localized FAQ invents reasons why a particular check failed. The help page can say what evidence is required without describing fraud-detection thresholds.

Verification. Security/content owners review additions, not only literal translations. If the result still depends on guesswork, return to authoritative locale data, source meaning, product context or the system that owns the underlying fact.

17. Run hostile-state in-context review

Security localization should be tested under suspicious as well as normal scenarios. Unexpected login, wrong-code, locked account and failed recovery states carry the highest confusion.

Professional method. Use regression testing plus real in-context flows for valid, invalid and suspicious events. The decision should be documented so that another translator, reviewer, designer or engineer can apply the same rule to the next occurrence without reconstructing the whole problem from memory.

Failure mode. Only the successful password-reset journey is localized and tested. An unexpected MFA prompt should clearly offer denial and recovery guidance.

Verification. Run the complete state matrix before release. If the result still depends on guesswork, return to authoritative locale data, source meaning, product context or the system that owns the underlying fact.

A repeatable operating sequence

Authentication localization should follow the security state machine rather than a flat string list.

Map sign-in, enrollment, challenge, reauthentication and recovery states.
Define approved names for every authenticator type.
Identify secrets, codes and protected identifiers.
Translate full messages with exact security action and consequences.
Review account-enumeration and information-disclosure constraints.
Align email, SMS, push and in-product terminology.
Test every authenticator path and recovery branch.
Test invalid, rate-limited, suspicious and locked states.
Review high-risk messages with security ownership.
Add state-based localization regression coverage.

Treat the sequence as a loop rather than a one-way checklist. If final testing reveals a problem, trace it back to the earliest decision that created it—source wording, data structure, context, template, locale rule or product logic—and repair that source where possible.

Worked scenarios

1. Unexpected MFA push

The user did not initiate a login but receives an approval request. The controlling risk is ambiguous wording encouraging habitual approval.

Make the sign-in nature of the request clear and provide an unmistakable deny path according to product policy. Then test the decision under the real conditions in which the user will encounter it. Professional localization is strongest when the linguistic choice and the system behaviour confirm each other.

2. Password reset for unknown email

The service intentionally avoids confirming whether an account exists. The controlling risk is target translation revealing account enumeration information.

Preserve the conditional source wording and test both existing and non-existing addresses. Then test the decision under the real conditions in which the user will encounter it. Professional localization is strongest when the linguistic choice and the system behaviour confirm each other.

3. Passkey enrollment on shared device

The product warns that a credential may be available through the device’s account ecosystem. The controlling risk is translation reducing a security caveat to generic convenience copy.

Preserve the approved platform/account consequence and ensure the user understands where the passkey will be available. Then test the decision under the real conditions in which the user will encounter it. Professional localization is strongest when the linguistic choice and the system behaviour confirm each other.

4. Recovery code mistaken for OTP

A user stores a one-time recovery code set but the UI labels it like a temporary SMS code. The controlling risk is users discarding long-lived recovery credentials.

Use a distinct localized term and explain storage/use accurately. Then test the decision under the real conditions in which the user will encounter it. Professional localization is strongest when the linguistic choice and the system behaviour confirm each other.

5. Rate limit after failed attempts

The system does not disclose the precise threshold. The controlling risk is translator adding helpful but sensitive implementation detail.

Keep the approved generic wait/retry language and do not invent timing or thresholds. Then test the decision under the real conditions in which the user will encounter it. Professional localization is strongest when the linguistic choice and the system behaviour confirm each other.

6. Sign out everywhere

The account security page revokes all active sessions. The controlling risk is target wording sounding like only the current device will sign out.

Translate the scope explicitly and verify the resulting account state. Then test the decision under the real conditions in which the user will encounter it. Professional localization is strongest when the linguistic choice and the system behaviour confirm each other.

Authentication and recovery localization: twenty practice cases

These cases are deliberately varied. For each one, identify what must remain invariant, what may be localized, what evidence is required and what final test proves the result is safe to release.

1. A short label changes meaning when moved to another screen

Review the string in its actual component and user journey before changing the translation. State the reason for the decision and what would make you change it. That makes the rule transferable rather than personal.