This engagement had nothing to do with PCI. It came to us because of PCI: the expertise that judges PIN security and payment cryptography is the expertise that reads a regulatory text about authentication and says what it means in practice.
The situation
A challenger bank for small businesses launched a corporate API: account data, IBAN management, attachments, webhooks and transfers. Every request carried a token signed with the client’s private key, bound to a certificate the bank’s own authority had issued at onboarding, plus a shared secret and a hash of the request. Onboarding itself required the two-factor login of the bank’s mobile app.
The bank’s question, in writing: does this count as strong customer authentication under PSD2? And if not, is it at least as secure as the two dedicated corporate protocols the national regulator recognises for the exemption that lets professional users skip strong customer authentication?
The analysis
The regulatory technical standards define strong customer authentication by its factors, and we took them one at a time.
- Knowledge was met. The secret issued at onboarding is something the customer knows.
- Independence of the factors was met. Compromising one did not compromise the others.
- Possession was not met, and this is the whole case. A private key file can be copied freely. An IP allow-list does not bind the key to a person. The standards put the duty to prevent copying on the bank, not on the customer, and nothing in the design prevented it.
- Inherence was absent by design, which is allowed; two factors suffice.
- Dynamic linking, the code tied to the amount and the payee for a payment, was not met. There was none.
Verdict: not strong customer authentication. But the design was comparable in security to the dedicated corporate protocols the regulator accepts, and so aligned with the exemption for professional users. The opinion went through three versions over four months as the analysis of possession deepened, because the first reading was too generous and we said so.
A signed token proves that someone holds a key file. It does not prove that the right person does.
Why it mattered
“Comparable to an exempted protocol” and “strong customer authentication” are very different sentences to say to a regulator, a customer or an auditor. The bank now knew which one it could say, and what it would have to change to say the other: a key the customer cannot export, in a hardware token or a secure element, and a dynamic link for payments.
It also knew where its real control now sat. If you rely on the corporate exemption, the security of your certificate authority, its registration process and its monitoring is the control that everything else rests on, and that is what should be tested.
What people get wrong
They treat good cryptography as authentication. A signed token proves that someone holds a key file. It does not prove that the right person does.
They read “possession” as owning a file. Regulators read it as something that cannot be duplicated. A file, by definition, can.
They ask the regulatory question after launch. The design was sound and the launch was done; the answer could not change the product, only the sentence about it.