Strong customer authentication under PSD2 asks for two of three factors: something the customer knows, something the customer has, something the customer is. Knowledge and inherence are reasonably well understood. The factor that comes to us for a written opinion, again and again, is possession, because the regulatory technical standards define it by a property most implementations do not have. The thing the customer “has” must be something that cannot be copied without the bank noticing.
That one sentence rules out more designs than people expect.
What the standards actually ask for
The regulatory technical standards on strong customer authentication say three things about possession. Each factor must be independent, so that compromising one does not compromise another. The possession element must rely on measures that prevent its replication. And for a payment, the authentication code must be dynamically linked to the amount and the payee, so that a code captured for one transfer cannot approve a different one.
The European Banking Authority’s opinion on the elements of strong customer authentication says how possession can be evidenced: a one-time password generated by a device, or a digital signature produced by a key held on the device, among others. A device is evidence of possession when the bank can tell that this device, and not a copy of its data, produced the response.
That is where most of the difficulty sits.
What is not possession
An SMS code proves that someone can read messages sent to a number. The standards accept the SIM as a possession element in principle, with the caveat that the bank must deal with SIM swapping and number porting. In practice it is the weakest acceptable choice, and the one most often defeated.
A password-protected key file proves that someone holds the file. Files copy. The duty to prevent replication is the bank’s, and nothing about a file prevents it. We gave a challenger bank a written opinion to exactly this effect: careful cryptography, signed requests, certificates issued at onboarding, and still not possession, because the private key lived in a file. That story is a case study of its own.
A device identifier is not possession either. Advertising identifiers, device fingerprints, installation tokens: all of them can be read and replayed. Emulator farms do this at scale, presenting hundreds of plausible “devices” to an authentication server that checks identifiers rather than keys.
What is
A private key generated inside the device’s secure hardware, never exported, used to sign a challenge the server chose. On Apple devices that is the Secure Enclave. On Android it is the hardware-backed keystore, with StrongBox where the device has it. Keys created there cannot be read by the application, by the operating system or by someone who has imaged the phone. The application asks the hardware to sign; the hardware signs; the key never appears in memory the application can see.
Binding, then, means this: at enrolment, the application generates a key pair in the secure hardware, the public key is registered against the customer, and from then on every authentication is a signature over a fresh server challenge. For a payment, the challenge includes the amount and the payee, which gives you dynamic linking from the same mechanism.
Two details decide whether this holds up.
Attestation. The server should be able to verify that the key really was generated in secure hardware, on a real device, by your application. Both platforms provide this: Android key attestation and Play Integrity, Apple’s App Attest and DeviceCheck. Without attestation, an emulator can present a software key and claim it is hardware-backed. With it, the claim is a certificate chain you can check.
Lifecycle. A new phone means a new key, and the old one must be revoked. Re-enrolment on a new device is itself a sensitive operation and needs strong customer authentication of its own, through a factor the attacker who stole a password does not have. If re-enrolment is possible with a password and an SMS code, the hardware key protects nothing: the attacker simply enrols their own phone.
The engineering trap
Cross-platform frameworks are where good designs quietly fail. The secure hardware is reachable only through native code, and the generic keychain or keystore wrappers that come with React Native, Flutter and their peers do not always put the key where you think. A key in the ordinary keychain is still a file the operating system protects, which is better than nothing and not what the standards describe. If your application is cross-platform, the module that generates and uses the key must be native, must request hardware-backed storage explicitly, and must fail enrolment if the device cannot provide it.
Test this. Enrol on an emulator and on a rooted device, and check that the server refuses. Pull the key material from a device backup and check that it is not there. The evidence that possession is real is a test that tried to copy it and could not.
Possession is not owning a device. It is holding a key that cannot be copied without the bank noticing.
The other way to fail: enrolment
A design that is cryptographically right can still lock real customers out, and the regulators care about that too. One we watched from the customer’s side: a business banking application that enrolled a new phone by sending a text message, except that it could not send to foreign numbers; then offered a letter with a code to the registered address, except that the address on file was years out of date; then crashed during the attempt with a borrowed local number. Four months without a working card, while the same bank authenticated the same customer over the phone, by voice, several times a week.
The lesson is not that the bank’s authentication was weak. The in-app method, once enrolled, was fine. The lesson is that enrolment and recovery are part of the authentication design, and they were built as an afterthought. Enrolment needs more than one route, each as strong as the method it unlocks, and none of them dependent on a single national telephone network or on address data nobody has verified since onboarding.
What people get wrong
They treat the device as the factor. The factor is the key. A device with a copyable key is a password with extra steps.
They skip attestation. The server believes the application’s claim about the key, and an emulator makes the same claim.
They secure authentication and leave recovery weak. The attacker does not attack the signature. They enrol a new phone.
They ask the regulatory question after launch, when the answer can change only the sentence they say about the product, not the product.