---
url: 'https://www.corbado.com/blog/remember-me-passkeys'
title: 'Remember Me & Passkeys: Risk Analysis for Banks'
description: 'Does "remember me" weaken passkey login on shared devices? A risk analysis for banks: autofill baseline, threat model, controls and the evidence risk needs.'
lang: 'en'
author: 'Vincent Delitz'
date: '2026-10-02T12:40:02.342Z'
lastModified: '2026-10-02T12:45:25.303Z'
keywords: 'remember me passkeys, remember username passkeys, passkeys shared device risk, passkey risk assessment bank, remember me security, passkey login banking'
category: 'Passkeys Strategy'
---

# Remember Me & Passkeys: Risk Analysis for Banks

## Key Facts

- With passkeys, **remembered usernames** are routing state only. Prefilling the identifier does not change the cryptographic assertion that authenticates the user.
- Chrome has ignored **autocomplete='off'** on password fields since Chrome 34 in 2014. Aggregate Corbado Credential Intelligence shows identifiers are already autofilled in 15-45% of logins and passwords in 35-45% of logins.
- Across all three attack vectors, **remember me** changes no risk outcome. Passkeys reduce phishing and malware exposure equally with or without a prefilled identifier.
- The real security controls are **device binding**, passkey user verification and step-up on high-risk actions. None are weakened by a prefilled identifier.

## 1. Introduction

In retail banking, a common question comes up shortly before a passkey rollout. Many
online-banking login pages carry a feature customers have used for years: after a
successful login, the bank offers to remember the customer ID in a browser cookie, so the
next visit starts with the identifier already in place. For years, nobody questions it.
Then [passkeys](https://www.corbado.com/passkeys-for-banking) arrive and remove the password step, and the risk
and fraud team asks a fair question: if the username is prefilled and the password is
gone, does a passkey login become too easy for the wrong person?

In project calls, the question usually sounds like this:

> "On a shared device, if you remember the client ID and you somehow got access to the
> local biometric, Windows Hello or Touch ID, I can now get into the account without
> knowing either the username or the password."

The question often has a second root. Many bank security teams run a hard rule against
account enumeration: nothing on the login page may reveal that an account or a passkey
exists before the customer has typed their identifier. A remembered identifier shows the
customer ID before anything has been proven. Two requirements that coexisted peacefully
in a password world suddenly look like they contradict each other. The project team then
has to either get a "yes, we are fine with this" from risk or document the residual risk
and find someone to accept it.

This article provides the analysis for that decision. It answers the questions a risk
committee, a fraud team and a product owner will ask when **remember me** meets passkeys:

- **What does a remembered username change in a passkey login?**
- **How much of the identifier and password is already stored on the device today?**
- **Which attacks does remember me affect, and which does it leave untouched?**
- **Where do the security controls sit for a regulated entity?**
- **What evidence should a risk committee ask for before it approves?**

Once the data is on the table, the conclusion is straightforward: with passkeys,
remembering the identifier is a UX decision. The security decisions live in device binding
and step-up.

## 2. What "Remember me" changes in a Passkey Login

### 2.1 Three returning-customer States

The cleanest way to isolate the decision is to compare three states a returning customer
can be in. Only the third one is new.

| State                                 | Who supplies the identifier                | What authenticates                                  |
| ------------------------------------- | ------------------------------------------ | --------------------------------------------------- |
| **Current: password and app MFA**     | Customer types it or the browser autofills | Password, then a push or code in the banking app    |
| **Option A: passkey, no prefill**     | Customer types it or the browser autofills | Silent device check, then passkey user verification |
| **Option B: passkey and remember me** | The bank prefills the opted-in identifier  | Silent device check, then passkey user verification |

![Three bank login states: password with app MFA, passkey without prefill and passkey with a remembered customer ID](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/banking_login_flow_1_f1c5237fd4.png)

Option A and option B differ in exactly one respect: who puts the identifier into the
field. Everything after that is identical. The device is checked, the passkey ceremony
runs, [user verification](https://www.corbado.com/glossary/user-verification) is required and the session is
issued. The decision in front of the risk committee is therefore narrow: may the bank
prefill an identifier the customer has asked it to remember, or does the customer need to
type it or let their password manager autofill it?

### 2.2 Identifier is Routing State, not a Credential

In the password world, the username was half of a secret. You needed the username and the
password, so remembering the username left one secret standing and it was fair to ask
what that cost. With passkeys, the identifier stops being part of the credential at all.
Its only job is to tell the server which passkey to ask for. The
[relying party](https://www.corbado.com/glossary/relying-party) then verifies a signature that only the private
key on that device can produce.

This has a practical consequence for how the feature should be implemented. A remembered
identifier must never be treated as proof of identity, as evidence that the browser is
trusted or as a completed authentication factor. It is untrusted input the customer could
have typed. As long as the design follows this rule, prefilling it does not touch the
authentication boundary.

### 2.3 Remember me is also the enumeration-safe Trigger

Remember me has a second function that risk discussions often miss. Many banks want a passkey login that starts without the customer typing
anything, either automatically on page load or through a one-tap button that shows part of
the identifier. Done naively, that leaks account existence: the page behaves differently
depending on whether an account with a passkey exists.

The safe pattern ties the identifier-less path to a device the bank has already seen. The
following flow shows how the login page decides which path to offer.

If the browser carries the remember-me state or the device-binding handle, the passkey can
start immediately. On an unknown device the customer types the identifier first, as today,
and the page behaves identically whether or not an account exists. Remove the remembered
identifier and you also remove the enumeration-safe way to offer one-tap passkey login.
[Conditional UI](https://www.corbado.com/blog/webauthn-conditional-ui-passkeys-autofill) solves the same problem
for banks whose security team allows the browser to list passkeys before the identifier is
typed, which many banks do not.

One nuance: in business banking, one device often serves several
users and services. Remember me has to be opt-in per account and the risk paper should
say so explicitly. The analysis below is about the retail case, where the same person logs
in to the same account from the same device the vast majority of the time.

## 3. Baseline nobody measured: the Identifier is already on the Device

### 3.1 "We don't support autocomplete"

When this objection comes up, the working assumption is often that the login page keeps
credentials off the device, because the form sets `autocomplete="off"` on the identifier
and password fields. That assumption has been wrong since 2014.

> "Chrome ignores autocomplete='off' for password fields. This allows the password manager
> to give more power to users to manage their credentials on websites. It is the security
> team's view that this is very important for user security."

That is the Chromium team on the chromium-dev mailing list in February 2014. The change
shipped in Chrome 34 and it is still current behavior. Safari, Edge and the third-party
password managers behave the same way in practice: the save prompt appears, the customer
accepts it once and from then on the identifier and the password are released after a
local device unlock. [MDN](https://developer.mozilla.org/en-US/docs/Web/Security/Practical_implementation_guides/Turning_off_form_autocompletion#managing_autofill_for_login_fields)
documents the same behavior: many modern browsers do not support `autocomplete="off"` for
login fields and still offer to remember the login.

### 3.2 Every tested Browser ignores autocomplete="off"

To verify this, we built a test page that mirrors a typical online-banking login form,
including its autocomplete attributes, and used dummy credentials. The
question for each platform was the same: is the identifier prefilled, is the password
prefilled and does the save prompt appear despite `autocomplete="off"`?

| Platform                                               | Identifier prefilled | Password prefilled | Save prompt despite `autocomplete="off"` |
| ------------------------------------------------------ | -------------------- | ------------------ | ---------------------------------------- |
| macOS · Chrome · Google Password Manager / 1Password   | Yes                  | Yes                | Yes                                      |
| macOS · Safari · Apple Passwords                       | Yes                  | Yes                | Yes                                      |
| iOS · Safari · Apple Passwords                         | Yes                  | Yes                | Yes                                      |
| Android · Chrome · Google Password Manager             | Yes                  | Yes                | Yes                                      |
| Windows · Chrome · Google Password Manager / 1Password | Yes                  | Yes                | Yes                                      |

![Autofill test on iOS Safari with Apple Passwords: Face ID fill, save prompt despite autocomplete off and autofilled form](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/ios_safari_native_autofill_1_209b514296.png)

![Autofill test on macOS Chrome with Google Password Manager: save prompt, autofilled form and autofill suggestion](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/macos_chrome_native_autofill_1_1192260d11.png)

The test proves browser behavior. How often it happens in practice needs a second data
point.

### 3.3 Identifiers are already autofilled in up to 45% of Logins

According to aggregate Corbado Credential Intelligence across more than one million logins
in August 2026, on user bases comparable to a retail bank, the browser or a password
manager supplied the identifier in 15-45% of logins and the password in 35-45% of logins,
depending on device class, operating system and browser. Android and Chrome sit at the
upper end for identifiers, Apple platforms at the upper end for passwords. More than half
of the autofilled passwords were handed over without any password-manager prompt at all,
because the device had been unlocked recently enough. If you are interested in the
detailed breakdown by platform or by industry, [reach out to us](https://www.corbado.com/contact).

![Share of logins with a prefilled customer ID and an autofilled password, based on aggregate Corbado Credential Intelligence from August 2026](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/credential_prefill_autofill_rates_2_cf2f11f2e3.png)

Both data points contradict the premise of the objection. For a large,
measurable share of customers, someone who can unlock the device can already obtain the
identifier and the password today, with no passkeys involved. Remember me adds a
further copy of the identifier to a device that often holds it already.

## 4. Threat Model: two Credential Problems and one Device-Custody Problem

A bank login faces three attack classes that matter at scale. Two are credential problems.
The third is a device-custody problem, and it is the one the objection is about.

### 4.1 Remote Phishing

The attacker controls a look-alike page or relays a login through a proxy. Phishing was
the most reported scam type in Australia in 2025 according to
[Scamwatch](https://www.scamwatch.gov.au/research-and-resources/targeting-scams-report), and
generative AI has lowered the cost of a convincing campaign further.

- **Password and app MFA:** exposed. The password can be captured on any look-alike page.
  App-based MFA remains a control but it is not origin-bound, so an adversary-in-the-middle
  relay can pass the approval through.
- **Passkey, with or without remember me:** materially reduced. The assertion is bound to
  the bank's origin through the
  [WebAuthn relying party ID](https://www.w3.org/TR/webauthn-3/#relying-party-identifier),
  so a look-alike domain cannot obtain a valid signature. The
  [FIDO Alliance](https://fidoalliance.org/passkeys/) calls passkeys "phishing resistant
  and secure by design". A prefilled
  identifier plays no part in the cryptographic check.

### 4.2 Info-Stealer Malware

The attacker runs code on the customer's machine and reads what is stored there. In the
first half of 2026 alone, infostealers harvested more than 1.7 billion credentials from
over 7.4 million infected devices, according to
[Flashpoint](https://flashpoint.io/resources/report/flashpoint-global-threat-intelligence-report-midyear-2026/).

- **Password and app MFA:** exposed. The saved password is readable from the credential
  store and gets exfiltrated with the rest of the log.
- **Passkey, with or without remember me:** materially reduced. The private key is
  non-exportable. A stolen identifier on its own is worthless without the device that holds
  the key and the person who can unlock it.

### 4.3 Someone holding the unlocked Device

A spouse, a child or a flatmate has the registered device and knows the local unlock. No
published frequency data exists for this case, which is part of why it dominates risk
discussions: it is easy to imagine and hard to size.

- **Password and app MFA:** equal. The credential manager releases the identifier and the
  password after the same local unlock, as shown above. App MFA may still be a separate
  gate depending on the trusted-device policy, but for many customers it is not.
- **Passkey, with or without remember me:** equal. Passkey user verification accepts the
  device PIN or pattern as a fallback to biometrics, so the person who knows the unlock can
  satisfy it.

### 4.4 Remember me adds no Risk on any Attack Vector

| Attack vector                       | Password + app MFA         | Option A: passkey          | Option B: passkey + remember me |
| ----------------------------------- | -------------------------- | -------------------------- | ------------------------------- |
| Remote phishing                     | Exposed                    | Materially reduced         | Materially reduced              |
| Info-stealer malware                | Exposed                    | Materially reduced         | Materially reduced              |
| Someone holding the unlocked device | Local unlock may authorize | Local unlock may authorize | Local unlock may authorize      |

![Threat matrix comparing remote phishing and local access for password with app MFA, passkey and passkey with remember me](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/passkey_attack_vector_comparison_1_f8f1c149ee.png)

Both passkey options win outright on the two vectors where the credential is the control.
The third vector is a tie across all three columns, and it is the narrowest of the three:
it requires physical possession of the device and knowledge of its unlock.
Optimizing the design for the tie costs you on the two where passkeys win. The
local-access change that does exist comes from relying on device-local verification at
all, which is inherent to passkeys and to every banking app already in customers' pockets.
It does not come from remembering the identifier.

## 5. "My Spouse knows my PIN": walking the Scenario both Ways

The most useful exercise for a risk committee is to walk the shared-device scenario step
by step, once with remember me switched on and once with it switched off.

**Remember me on, the feature as it works today:**

1. The person unlocks the device with the PIN they already know.
2. The customer ID is sitting in the field.
3. The passkey prompt appears and is satisfied by that same device unlock.
4. They are in.

**Remember me off, as risk teams often propose:**

1. The person unlocks the device with the PIN they already know.
2. Autofill or the password manager supplies the customer ID. If neither does, they open
   the passwords app on the same device and read it there, protected by the same unlock.
3. The passkey prompt appears and is satisfied by that same device unlock.
4. They are in.

![Local access scenario walked step by step for password with app MFA and for passkey with a remembered customer ID](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/local_access_threat_password_vs_passkey_1_92e6edbec7.png)

The only gate in either path is the device unlock. It is the same gate that already
protects the saved passwords on that device, the banking app on that device and, for many
customers, the email account that can reset everything else. Switching the feature off
removes a typing step and leaves access unchanged. The only person who reliably pays for that extra step
is the legitimate customer.

The cost side shows up quickly. If the remember-me cookie stops saving, for example after
a login-page release, successful logins can drop and support contacts can rise within
days. Few teams have measured how many customers rely on the feature. Removing it costs
the customer effort and gains nothing in security.

| Login state               | What the customer does                      | What actually authenticates                         | What an attacker on an unlocked device faces               |
| ------------------------- | ------------------------------------------- | --------------------------------------------------- | ---------------------------------------------------------- |
| Today: password + app MFA | The ID is prefilled, they type the password | The password, a copyable secret, then phishable MFA | The password, which autofill hands over 35-45% of the time |
| No prefill, then passkey  | They type the ID, then the passkey starts   | The passkey, released by the device unlock          | The device unlock                                          |
| Prefill, then passkey     | The ID is prefilled, the passkey starts     | The passkey, released by the device unlock          | The device unlock                                          |
| One-tap passkey button    | One click, the passkey starts               | The passkey, released by the device unlock          | The device unlock                                          |

All three passkey rows land on the same step because the identifier was never the thing
being checked.

## 6. Where the Controls sit for Regulated Entities

If remember me is not a control, the natural follow-up from a risk committee is: what is?
For a bank subject to [APRA CPS 234](https://www.corbado.com/blog/cps234) or the
[PSD2 SCA](https://www.corbado.com/blog/psd2-passkeys) regime, the answer is the same list, and most of it is
already in the passkey design. The following overview places each control on the login
path, from the untrusted identifier at the front to the step-up on the transaction at the
back.

### 6.1 Device Binding

Device binding limits passkey login to devices already linked to the account. It answers
the question "what if someone has a device that is not mine?" and narrows the residual
case to a device the customer registered and someone in their household who can unlock
it. The
[device-bound versus synced passkey](https://www.corbado.com/blog/device-bound-synced-passkeys) decision belongs
in the same paragraph of the risk paper.

### 6.2 Passkey User Verification

[User verification](https://www.corbado.com/glossary/user-verification) must remain required on every
assertion, which WebAuthn enforces through
[`userVerification: "required"`](https://www.w3.org/TR/webauthn-3/#dom-userverificationrequirement-required).
It is the step that ties the ceremony to a person present at the device. Do
not relax it for remembered devices to speed the flow up, because the remembered
identifier is precisely the thing that must not buy any trust.

### 6.3 Step-up on the Action

Payments to new payees, limit changes, contact-detail changes and passkey enrollment are
where a second factor is worth the friction. Front-door MFA spends that friction on every
customer at every login, including the majority with nothing at stake in that session.
[Step-up authentication](https://www.corbado.com/glossary/step-up-authentication) on the action is also where a
household attacker is actually stopped, because the harm is moving money, and that is
where the challenge belongs. [Securing passkey enrollment](https://www.corbado.com/blog/passkey-enrollment-security) is a separate topic,
because an attacker who can create a passkey has a persistent, phishing-resistant
credential of their own.

### 6.4 Step-up on the Signal

New device, new location, unusual velocity, an account that has just changed its recovery
details. Challenge the sessions that look different rather than the whole population.
[Adaptive MFA](https://www.corbado.com/glossary/adaptive-mfa) is what lets the front door stay quiet for the
vast majority of logins while still catching the session that needs a closer look.

### 6.5 Account Enumeration

The enumeration rule from section 2.3 survives intact. The identifier-less
passkey path is only offered on a device that carries the remember-me state or the
device-binding handle. On an unknown device the page behaves identically for every
identifier typed, whether an account exists or not.

### 6.6 What the remembered Identifier must never be used for

For the risk paper, one sentence is enough: the bank never treats a remembered
identifier as proof of identity, as browser trust or as a completed authentication factor.
It is opt-in, per account, revocable by the customer and it can be cleared by the bank at
any time without touching the passkey.

## 7. Approval Conditions: make the Decision measurable

The argument in sections 3 to 6 is sound, but a regulated entity should not approve a
login change on an argument. It should approve it on evidence and keep the evidence
flowing after launch. That is where most passkey projects find a gap.

### 7.1 Web Analytics cannot answer the Risk Committee's Questions

A large bank typically has years of web analytics: hundreds of millions of login-page
visits, millions of distinct customers, a clean split by device class, operating system
and browser. None of it answers the questions a risk committee asks here. Web
analytics explains channel scale and device mix. It does not reveal who supplied the
identifier, whether the device-binding check held, which passkey path completed, why a
ceremony was abandoned or whether a fraud case followed a particular login.

The rest of the picture sat in five other places: client-side journeys in the front end,
device binding and passkey assertions in the authentication backend, sessions in the
identity provider, API performance in the SIEM and outcomes in the fraud and support
systems. Each system is good at its own job. None of them joins a single login across all
of them.

### 7.2 A login-level Timeline

What a risk committee needs is one timeline per login attempt that consumes those existing
sources and answers three questions:

1. **Same-attempt sequence:** for each login, did the device check, the passkey
   verification and the session issuance complete in the approved order, and what did the
   client side experience along the way?
2. **Incremental effect:** did customers with remember me enabled reuse their passkey more
   often, with no adverse movement in recovery, fallback or support signals?
3. **Actionable diagnosis:** when something fails, which control failed and for which
   operating system and browser cohort? Should the bank hold, adjust or roll back?

This is the same [authentication observability](https://www.corbado.com/blog/authentication-observability) need
that any passkey rollout has. Remember me just makes it visible earlier, because it is the
first feature a risk team asks to see proven.

### 7.3 KPIs and Thresholds the Bank should own

The controls become measurable once the bank names the numbers and the thresholds that
trigger a hold. A workable starting set:

- **Identifier autofill share** by OS and browser, measured before launch. This is the
  baseline that decides whether the objection is real for your customer base.
- **Remember-me opt-in rate** and the share of logins that start from a remembered
  identifier.
- **Passkey reuse rate** for remembered versus non-remembered customers, which is the
  benefit side of the decision.
- **Fallback rate** to password and app MFA, split by reason where the client side can
  tell.
- **Recovery and support contacts** per thousand logins.
- **Account-takeover and fraud signals** for sessions that started from a remembered
  identifier, compared against the control cohort.

Thresholds are the bank's to set. What matters is that they exist before launch, that
someone owns them and that the data can be produced at that granularity. The
loop below is the shape the rollout takes once those three things are in place.

### 7.4 Recommendation Template

For the risk committee, the recommendation fits on one page and can read like this:

1. **Enable opt-in remember me for eligible passkey users.** Keep it per account and
   treat it as untrusted routing state.
2. **Retain device binding and passkey user verification** on every login. Neither is
   relaxed for a remembered device.
3. **Keep step-up on high-risk actions and on risk signals.** Front-door MFA is not
   reintroduced.
4. **Run the rollout against named KPIs** with hold and roll-back thresholds owned by
   risk, on login-level evidence rather than on page-view analytics.
5. **Where residual risk remains,** document it as the device-custody risk it is, name
   the accepting owner and record that the same exposure exists today through
   credential-manager autofill.

## 8. How Corbado can help

The number that unblocks this decision is the autofill share: how many customers already
have the identifier and the password released by a device unlock before passkeys enter
the picture. Most banks cannot produce it, because it is a client-side fact that never
reaches a server log. [Corbado Observe](https://www.corbado.com/observe) captures that layer on top of the
existing login with one script, without touching the authentication itself.

[Video: Login funnel](https://www.corbado.com/videos/features/login-funnel.mp4) ([See Login Funnel in Corbado Observe](https://www.corbado.com/observe/login-funnel))

- **Autofill baseline:** Observe records whether the identifier and password fields were
  typed or autofilled, and whether the credential manager asked for a device unlock first,
  per operating system, browser and credential manager. That is section 3 for your own
  customer base.
- **[Login funnel](https://www.corbado.com/observe/login-funnel) per identifier path:** remembered, autofilled
  and typed identifiers compared on completion, abandonment and fallback to password and
  app MFA, which is the incremental-effect question in section 7.
- **[Passkey errors](https://www.corbado.com/observe/passkey-errors) by cohort:** a failing device-binding check
  on one OS version shows up as a diagnosis with an owner rather than as a support spike.
- **[User debugging](https://www.corbado.com/observe/user-debugging):** one customer's login timeline,
  reconstructed when fraud or support asks what happened on that account.

[Corbado Connect](https://www.corbado.com/connect) is the other half for banks that want the flow itself: the
enumeration-safe one-tap passkey login on known devices, with identifier-first on unknown
ones, on top of the existing identity stack.

## 9. Conclusion

Remember me survived a decade of password logins without anyone asking whether it was a
security control, because in a password world it was not: the password stood
behind it. Passkeys removed the password and the question finally got asked. The answer,
once the autofill baseline is measured and the threat model is written down, is that the
identifier was never the thing being checked. The controls that matter are device
binding, user verification and step-up on the action and the signal, and all of them are
untouched by a prefilled username.

For a regulated entity, the main takeaway is the method. Risk committees block launch
features on unmeasured assumptions because nobody brings them a measurement. Bring the
baseline, walk the scenario both ways, name KPIs with thresholds and approve with
conditions. That decision can be audited, which matters for any change to a bank login.

## Frequently Asked Questions

### Does prefilling the username on a bank passkey login page reduce security?

Prefilling the username does not reduce security because the identifier is routing state only. It tells the server which passkey to request, but authentication depends on a device-bound private key. The cryptographic assertion is identical whether the customer types the identifier or the bank prefills it.

### How does the shared-device threat scenario compare between password MFA and passkeys with remember me?

The device-custody risk is equal across all three login states: password with app MFA, passkey without prefill and passkey with remember me. Someone who can unlock the device can access the credential manager, which releases the identifier and password after the same unlock. Removing remember me eliminates a typing step but leaves access unchanged.

### What security controls protect a bank passkey login if the username identifier carries no trust?

Device binding prevents any unknown device from completing a passkey ceremony at all. Passkey user verification must remain required on every assertion. Step-up authentication on payments, payee changes and limit changes is where a household attacker is actually stopped, because the harm is moving money and that is where the challenge belongs.

### What measurable evidence should a bank's risk committee require before approving remember me alongside passkeys?

A pre-launch autofill baseline by OS and browser establishes whether the identifier and password are already on the device for the customer base. Post-launch KPIs include passkey reuse rate for remembered versus non-remembered customers, fallback rate to password MFA, support contacts per thousand logins and fraud signals for sessions starting from a remembered identifier.