Passkeys in Banking, Part 2: Securing Passkey Enrolment with Browser Registration

Passkey enrolment in banking can be secured by requiring browsers to register before they are permitted to hold a passkey. Registration demands a liveness checked selfie in the bank mobile app together with a scan of an ephemeral QR code, preventing remote credential issuance from stolen knowledge alone. A rotating profile cookie restores clone detection that synchronised passkeys removed.

This is the second of two articles. Part one, Passkeys in Banking: What They Actually Fix, and What They Quietly Don’t, sets out the benefits and the risks. This part addresses what a bank can do about the risk that matters most.

In short. A passkey is a strong credential, and the strength of a credential has never been the whole of the problem, because whoever controls the process that issues a credential controls the account it protects. This article describes a pattern in which a browser must earn the right to hold a passkey before it is given one. The four points that follow are the substance of it.

• Passkey enrolment, rather than passkey authentication, is where a determined attacker now concentrates, so that is where the control belongs.
• A session key and a profile cookie answer different questions and should never be combined into a single artefact, because one carries authority and should be short lived while the other carries none and should be long lived.
• Registration requires a selfie checked for liveness in the bank’s mobile application together with a scan of an ephemeral QR code, which means a credential can no longer be issued remotely on the strength of stolen knowledge alone.
• A profile cookie whose value rotates on every login restores the clone detection signal that synchronised passkeys have quietly taken away from banks.

1. Why passkey enrolment is the real target

Part one of this series set out the risk picture in detail, and three of its findings bear directly on everything below.

The first is that passkeys largely defeat phishing and credential theft, which is precisely why attackers stop attacking the login and start attacking the flows that issue and restore credentials instead. An attacker who finds the front door locked does not stand outside admiring the lock.

The second is that research published by Palo Alto Networks Unit 42 in August 2026 demonstrated that malware already resident on a customer’s machine can extract synchronised passkey material and then use it from somewhere else entirely, which punctures the comfortable assumption that a passkey cannot leave the device that created it.

The third is that the signal WebAuthn provides for detecting a cloned credential, known as the signature counter, returns a constant value for synchronised passkeys and therefore tells a bank nothing whatsoever.

Those three findings share a shape. Not one of them is a weakness in the cryptography, and every one of them is answered better at the level of the browser than at the level of the credential.

2. Session keys versus profile cookies, which answer different questions

A cookie is a small piece of data that a website asks the browser to store and then to send back on subsequent requests, which is how a website remembers anything at all between one click and the next. Cookies serve very different purposes depending on their lifetime and their contents, and the distinction that matters here is between a session key and a profile cookie.

A session key, carried in a session cookie, is short lived and answers the question of whether a particular request belongs to a live authenticated sitting. It comes into existence when the customer logs in, it is destroyed when they log out or when it expires, and while it exists it carries the authority to act on the account. It is what an attacker steals when they wish to ride an authenticated session without ever holding a credential of their own.

A profile cookie answers a completely different question, which is whether the bank has seen and vetted this particular browser before. It is deliberately long lived, it outlives any individual session, and on its own it confers no authority to do anything at all. It is closer to a membership card for the browser than a key to the account, and its value lies in what it allows the bank to refuse rather than in what it allows the customer to do.

Conflating the two is a common design error, because an artefact that is both long lived and authority bearing is the worst of both worlds. Keeping them separate means the session key can be aggressively short lived without inconveniencing anybody, while the profile cookie can persist for a very long time without ever becoming a credential worth stealing.

3. How browser registration works, using a liveness checked selfie and an ephemeral QR code

The control is that a browser must be registered with the bank before it is permitted to enrol or use a passkey at all. Registration is not a silent background process, and it is deliberately demanding of the customer, because it happens rarely and it establishes the trust that everything afterwards depends upon.

The customer is asked to do two things at the same moment. First, they authenticate in the bank’s mobile application by taking a selfie, which is checked for liveness and matched against the biometric record the bank already holds, so that the person present is verified as the accountholder rather than merely as somebody who knows the right answers. Second, the browser displays a QR code, which is a machine readable pattern on the screen, and the customer scans that code using the same mobile application. The codes are ephemeral, meaning that each one is valid for a short window and for one registration only, after which it expires and cannot be presented again.

Only once both of those steps succeed does the browser receive its profile cookie and become a registered browser, and only then may the customer create or use a passkey within it.

4. Why browser registration secures passkey vending

The passkey itself is rarely the weak point, because an attacker who finds the front door locked turns to the flows that issue and restore credentials instead. Gating passkey enrolment behind a verified selfie and a scanned code answers that directly, since it fortifies the step attackers actually target rather than the step they have already given up on.

An attacker who has stolen a password, or intercepted a one time code, or even recovered synchronised passkey material from a compromised machine in the manner Unit 42 describes, still arrives at a browser the bank has never registered. Registering one requires the accountholder’s face and the accountholder’s phone, so a credential can no longer be vended remotely on the strength of stolen knowledge alone.

This matters most in precisely the scenario that makes the Unit 42 research uncomfortable. Those attacks assume malware already present on the customer’s machine, and the most severe of them yields passkey private keys that the attacker can carry away and use from their own environment. A registration requirement does not prevent that theft, and yet it substantially devalues it, because stolen material presented from an unregistered browser is simply refused, and the attacker cannot register a browser of their own without the customer participating in person.

5. Profile cookie design, using a selector, a value and rotation after every login

The profile cookie carries two items, a selector and a value, and both are universally unique identifiers, meaning randomly generated numbers large enough that the chance of any two ever colliding is negligible.

They do separate jobs. The selector is the stable part and is used only to find the right record in the store, which means the bank never has to look a record up by its secret. The value is the part that actually proves the browser is the one it claims to be, and it is therefore the part that must be protected.

The important property is that the value is replaced with a freshly generated one after every login. A copy of the cookie taken at any moment is consequently good only until the next authentication, at which point it becomes stale. This is what is meant by saying that the profile cookie cannot be exported, and the claim is worth stating precisely, because the file can of course still be copied by anybody with access to it. What rotation achieves is that a copy stops working almost immediately, and, better still, that its use becomes visible. If an attacker presents the current value and it rotates in their favour, the legitimate browser then arrives carrying a value one generation behind, and a stale but recognised value is a strong indication that the cookie has been cloned. Rotation therefore converts a theft that would otherwise be entirely silent into a detectable event that the bank can alarm on and answer by forcing registration again.

That last property deserves dwelling on, because it recovers something the passkey ecosystem has quietly lost. WebAuthn provides a signature counter intended to reveal when the same credential is being used by more than one authenticator, and synchronised passkeys return a constant value for it, so a bank relying on that signal learns nothing. A rotating profile cookie restores an equivalent clone detection signal at the level of the browser, and it does so under the bank’s own control rather than leaving it dependent on the behaviour of a credential provider it does not operate.

6. What an ephemeral QR code proves, and what it does not

This is the part of the design that repays the most careful thought, because ephemerality does real security work while leaving one specific path open, and the two cases are easy to conflate.

What it closes is the relay that happens later, which we might call the asynchronous case. A code that has been photographed and forwarded to somebody who intends to use it in an hour, or captured in a screenshot and shared onward, is worthless by the time it arrives, and the single use constraint means that a code already scanned cannot be presented a second time to register another browser. Both properties are meaningful and both are good reasons to prefer ephemeral codes over static ones.

What it does not close is the relay that happens in real time, because there the attacker controls the timing and a short window costs them nothing. It is worth being precise about which direction the danger runs. The case that sounds alarming is a customer sharing their screen while their own code is displayed, and that turns out to matter rather little, because a code generated by the customer’s browser registers the customer’s browser and is of limited value to anybody else. The case that should concern us is the reverse. An attacker opens the bank’s website on their own machine, obtains a perfectly valid and perfectly fresh ephemeral code of their own, and then persuades the customer to scan it and complete the selfie, at which point the browser that becomes registered belongs to the attacker. Expiry is no obstacle whatsoever in that flow, since the attacker generates the code and talks the customer through scanning it inside the same telephone call, and that is precisely the shape of the remote support and investment scams that are common in the South African retail market.

The underlying point is that a scan, ephemeral or not, does not actually establish proximity. It establishes that the customer’s phone saw some screen, and it says nothing at all about whose screen that was. The FIDO Alliance met this same problem in its own flows for authenticating across devices, and it pairs the QR code with a Bluetooth check for exactly this reason, because a browser that must be physically near the phone cannot be a browser sitting in another province.

Where adding a proximity channel is not immediately practical, the compensating control is context at the moment of confirmation. The mobile application should state plainly what is about to happen, naming the device type, the operating system, the approximate location and the network of the browser being registered, and then ask the customer to confirm that they themselves have just opened the site on that machine. A customer being coached by a stranger then has at least one clear opportunity to notice that the computer described is not the computer in front of them. Notifying the customer over a separate channel whenever a new browser is registered, and applying velocity checks across registrations, both give the bank a second chance to catch whatever the ceremony itself allowed through.

7. Recovery, inclusion and obligations under POPIA

Recovery is where the real perimeter now sits, and a registration requirement creates a great deal of it. Every customer who buys a new laptop, clears their cookies or opens a browser in private mode arrives as an unregistered browser, and the volume of that will be considerable rather than marginal. The registration ceremony must therefore be strong enough to serve as the front door rather than as a supported path around it, since a repeat registration flow that quietly falls back to an SMS code would undo the entire control and would do so invisibly, because nothing in the logs would look like a failure.

Inclusion and privacy deserve to be considered together. Requiring a selfie in a mobile application presumes a smartphone capable of running it, which will exclude some customers and calls for a considered alternative rather than a weaker one, and an alternative that is merely more convenient becomes the path every attacker takes. Processing facial images is also the processing of biometric data, which the Protection of Personal Information Act treats as special personal information attracting specific obligations around consent, purpose limitation and retention, so that is a conversation to have with the privacy office at design time rather than after launch.

8. How profile cookies, passkeys and session binding layer together

The profile cookie establishes that a browser has been vetted, the passkey establishes that the right person is authenticating within that browser, and session binding, through Device Bound Session Credentials in a browser or sender constrained tokens for programmatic clients, establishes that the requests which follow genuinely originate from the same place.

All three are necessary, because each answers a question the other two cannot. A passkey in an unvetted browser tells the bank who is present but not where. A profile cookie without a passkey tells it where but not who. And both together say nothing about the requests that arrive after the login has succeeded. It is also worth remembering that a profile cookie between rotations remains a bearer artefact, meaning that anybody holding it can present it, which is exactly why it should not be asked to carry the whole weight by itself.

The pattern is not a perimeter, then, and it does not need to be. What it does is move the hardest remaining attack from something that can be done quietly from another country to something that requires a conversation with the customer, which is a considerably better place for the fight to happen.

9. Frequently asked questions

What is the difference between a session key and a profile cookie? A session key proves that a request belongs to a live authenticated session and it carries the authority to act on the account, so it should be short lived and destroyed at logout. A profile cookie proves only that the bank has vetted this browser before, it carries no authority at all, and it deliberately persists across sessions. They answer different questions and combining them into one artefact produces something long lived that is also worth stealing.

Can a profile cookie be stolen or exported? The file can be copied by anything with access to it, so the honest answer is yes. What rotation changes is the value of doing so, because the copy stops working at the next login, and the legitimate browser then presents a value one generation behind, which is a reliable indication that a clone exists. Theft becomes short lived and, more importantly, becomes visible.

Does an ephemeral QR code prove that the phone and the browser are in the same place? No. It proves that the phone saw a screen, and it says nothing about whose screen. Ephemerality defeats an attacker who forwards a code to use later, and it does nothing against an attacker generating a fresh code on their own machine while talking a customer through scanning it. Genuine proximity requires a channel that resists relaying, which is why FIDO pairs its own QR flow with a Bluetooth check.

Does browser registration stop the Unit 42 passkey attacks? It does not prevent the theft of passkey material from a compromised machine, because nothing at the level of the relying party can. What it does is devalue the theft, since credentials presented from a browser the bank has never registered are refused, and the attacker cannot register a browser without the accountholder present. The attack moves from silent and remote to noisy and participatory.

What happens when a customer buys a new laptop or clears their cookies? They arrive as an unregistered browser and must complete registration again, which will be common rather than rare. This is the flow to protect most carefully, because a repeat registration path that quietly falls back to a weaker method such as an SMS code would defeat the entire control while appearing in the logs as an ordinary success.

Is a profile cookie the same thing as device fingerprinting? No, and the difference is worth keeping clear. A fingerprint is inferred from characteristics the browser happens to expose, it is probabilistic, and it can be imitated by anything willing to present the same characteristics. A profile cookie is issued deliberately by the bank after a ceremony the bank controls, it is a secret rather than an observation, and it rotates, which makes its misuse detectable in a way that a fingerprint’s never is.

10. Related reading

Internal links to add before publishing, using the relevant existing posts:

• Contextual authentication and customer coercion, which bears directly on the coached scan scenario in section 6
• SIM swap and the USSD threat model, as the fallback path that a registration requirement must not quietly restore
• Session and token theft, which is the layer that section 8 argues sits beyond both the profile cookie and the passkey
• Transaction authorisation versus login authentication, since a registered browser and a passkey together still do not authorise a payment

11. References

• Pass the Passkey: A Novel Attack Surface in Passwordless Authentication, by Arie Olshtein, Palo Alto Networks Unit 42, 3 August 2026
• W3C Web Authentication Level 2, on authenticator data, the User Verified flag and the signature counter
• Client to Authenticator Protocol, version 2.2, FIDO Alliance, on the hybrid transport that pairs a QR code with a Bluetooth proximity check
• Passkeys, FIDO Alliance, on authentication across devices
• RFC 9562: Universally Unique Identifiers, IETF, on the generation and properties of the identifiers used in the profile cookie
• Device Bound Session Credentials, Chrome
• RFC 9449: OAuth 2.0 Demonstrating Proof of Possession, IETF
• NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, on syncable authenticators and recovery risk
• Information Regulator of South Africa, on obligations under the Protection of Personal Information Act, including the treatment of biometric data as special personal information

12. SEO fields, for the publishing form rather than the article

Copy these into the corresponding fields in Yoast or RankMath. This section is working material and should not be published as part of the post.

SEO title. Securing Passkey Enrolment with Browser Registration

Slug. securing-passkey-enrolment-browser-registration-profile-cookies

Meta description. Passkeys are strong, but whoever controls enrolment controls the account. How browser registration and a rotating profile cookie secure passkey vending.

Focus keyphrase. passkey enrolment security

Secondary keyphrases. browser registration, profile cookie, ephemeral QR code, passkey vending, session key versus profile cookie

Category. Banking Security

Tags. passkeys, WebAuthn, authentication, browser registration, profile cookie, banking security, POPIA

Schema. Mark section 9 as FAQPage if the plugin supports it, and set the article type to BlogPosting with part one named as the related article.