Mobile banking app security

The attack profile

A banking app does not get a generic attack. What it gets is a combination of credentials leaked from other services, automation spread across residential proxies to defeat IP blocking, and clients that imitate the real app by reading its traffic or repackaging the binary.

The intermediate goal is rarely to move money straight away: first the attacker establishes which credentials work, and that cleaned list has value on its own.

What the European regulatory framework asks for

PSD2 and its regulatory technical standards require strong customer authentication and elements that bind a transaction to the device, along with traceability of access.

A unique per-device certificate sits naturally in that binding requirement, because it turns the device into something verifiable cryptographically rather than an identifier the client declares about itself. Actual compliance depends on your implementation and your supervisor: this is a technical building block, not a compliance ruling.

Where it fits in a layered defence

Per-device mTLS does not replace your fraud engine, your 2FA or your transaction monitoring. It sits in front of all of them and takes work off their hands: it filters out, during the handshake, traffic that does not even come from your app.

• Before sign-in: only clients presenting a certificate issued to a registered install get through.
• During the session: the certificate keeps binding every request to that specific device.
• After an incident: revoking the certificate cuts that device off without touching anyone else.

What it does not solve

This is worth stating plainly. A per-device certificate does nothing against social engineering of the user, against a banking trojan operating inside the legitimate device, or against stolen credentials used from the victim's own genuine app. That is what the other layers are for.