Remember Me & Passkeys: Risk Analysis for Banks

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 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:

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.

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 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 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 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.

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 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"?

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.

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, 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, so a look-alike domain cannot obtain a valid signature. The FIDO Alliance 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.

• 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#

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.

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.

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 or the PSD2 SCA 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 decision belongs in the same paragraph of the risk paper.

6.2 Passkey User Verification#

User verification must remain required on every assertion, which WebAuthn enforces through userVerification: "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 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 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 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 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 captures that layer on top of the existing login with one script, without touching the authentication itself.

See Login Funnel in Corbado Observe →

• 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 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 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: one customer's login timeline, reconstructed when fraud or support asks what happened on that account.

Corbado 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.

About Corbado

Corbado is the Passkey Intelligence Platform for large-scale CIAM teams running consumer authentication. We help you see what IDP logs and generic analytics tools can't: where passkeys, passwords, OTP, social login and fallback journeys succeed, stall or fail, which devices and browsers create friction, and when an OS update silently breaks login. Two products: Corbado Observe layers process mining and observability across authentication journeys. Corbado Connect adds managed passkeys with analytics built in alongside your IDP. VicRoads runs passkeys for 5M+ users with Corbado (+80% passkey activation). Talk to a Passkey Expert →

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.