The fix that doesn't need SK

The signing relay works because two live sessions exist where the victim believes there is one. The victim's browser holds a window relayed pixel by pixel from a container the attacker controls. The container holds the actual authenticated session with the bank. When the victim scans the QR code or reads out a verification code, the confirmation that reaches the bank travels through the attacker's session, not the victim's.

That gap is visible without touching the Smart-ID protocol at all, because it is not a property of the signature, it is a property of the session the bank is already terminating. In this relay the attacker runs a real browser in a container, so its low-level fingerprint — TLS handshake shape, HTTP/2 or HTTP/3 frame timing — is a genuine browser’s, and will not stand out on its own. What tends to differ is further up: the IP address, the ASN, the geography, and the device history behind the session. Comparing a session only to itself would not catch the relay either: the container holds one continuous connection to the bank across both the QR issuance and the PIN2 confirmation, so it looks self-consistent the whole way through. The narrower question worth asking is whether that session matches what the bank already knows about this account's usual device and network from prior logins, not whether it was consistent with itself for the length of one transaction. A mismatch there is a risk signal a relay makes more likely, not proof a relay is present.

This is not a new idea. Paršovs listed exactly these heuristics in January 2026 — logins from new devices or unusual locations, access from a device in a different country from the Smart-ID device, IP reputation — and LHV already notifies clients when their account is accessed from a new device. PSD2’s strong-authentication rules already oblige banks to run this kind of monitoring: Delegated Regulation 2018/389 Art. 2 requires transaction monitoring that covers signs of malware in a session and known fraud scenarios. What is new here is pointing it at the relay case. It does not need SK to change the ACSP_V2 message, does not need a bank to change what its app shows the user, and does not need a regulator to write anything new down. It needs a bank's own backend to keep a fingerprint of the session transacting right now and compare it against the fingerprint history already on file for that account.

The scope is narrow. The sixth fix is a check for the cross-device, attacker-initiated case this report documents: a QR flow relayed through infrastructure the attacker controls. It has nothing to say about victim-initiated transfers, where the victim’s own usual session moves the money and there is nothing anomalous to compare it against. It is also useful against classic attacker-session vishing, where the attacker logs in from their own device and the victim only approves PINs. Against both, the report's own second fix, same-device Smart-ID+, does better than any continuity check could, because same-device removes the second session the attack needs.

So the sixth fix is not a replacement for the report's five. It is the tool for the gap between them: the gap between the phishing-resistant flow existing and the phishing-resistant flow being the default everywhere, which the report's own numbers show has lasted more than a year so far.

The case for the sixth fix is narrow and specific: a bank’s own fraud or security team can build it, on infrastructure that bank already operates, without a vendor's roadmap or a legislature's calendar standing between the decision and the deployment.

The limit is the same one this site makes about every client-side or network-side signal: it is a gate, not a verdict. A session-continuity mismatch is a reason to add friction, ask for a second confirmation, or hold a transfer for review. It is not proof of fraud on its own, and a system that treats it as a verdict will eventually lock out a legitimate user whose network path changed for an ordinary reason. Use it the way the report says to use everything else here: as one signal among several, never as the whole decision.

A privacy limit too. A device-and-network history is personal data, so this check sits under the GDPR. Fraud prevention is a recognised legitimate interest for processing it (Recital 47), but the usual duties apply: keep the minimum, set a retention period, and run a DPIA before deploying it at scale. The argument here does not depend on any specific vendor, mine included, being the one a bank chooses; see the disclosure at the top.

Corrections, 4 October 2026: an earlier version said SK ID Solutions is "owned by Swedbank and SEB" (it is co-owned, among others), that SK still had to "ship" Smart-ID+ (SK made it available in 2025; the banks have to roll it out), and that binding the approval needs SK to change the app (PSD2’s dynamic-linking rule already requires the bank to send the amount and payee). This version also credits Paršovs and LHV for the device and location heuristics, notes that PSD2 RTS Art. 2 already requires this monitoring, adds a GDPR note, moves the conflict-of-interest disclosure to the top, and fixes the dead corpus link.