The Achilles' heel of Estonia's e-state — Smart-ID / eID research

The obvious way to attack Smart-ID is to stand between the bank and SK ID Solutions: intercept the traffic, replace the endpoint, answer the bank’s requests yourself. This does not work, and the protocol is explicit about why.

The Smart-ID relying-party API requires every integration to pin the endpoint’s certificate. From the official API documentation: the RP must "verify the X.509 certificate of the HTTPS endpoint belongs to the well-known public key of the Smart-ID API. The RP must implement HTTPS key (or certificate) pinning." That is an application-layer check, not a TLS nicety. A fake SK server with a different certificate is rejected regardless of DNS, proxy, or CA compromise.

The bank itself is authenticated in the other direction, by a different mechanism: "RP API clients are authenticated based on their originating IP-address and relyingPartyUUID protocol parameter combinations." An attacker who has already won the network still cannot impersonate a bank to SK, because the trust is keyed to IP plus UUID, not to the network path.

There is also no server side to clone. SK’s own client-library list and public code hosts turn up relying-party libraries in many languages, among them PHP, Java, Rust, Go and Ruby, plus Django integrations. All of them are relying-party consumers. There is no open-source implementation of the SK-side infrastructure (account registration, mobile app communication, session management, certificate lifecycle). The server is proprietary, which is a defensible design decision: there is nothing to download and self-host.

Even with full network access, the attacker cannot forge the response itself. Authentication in Smart-ID uses the ACSP_V2 signature protocol. The phone signs a constructed message binding together random values from all three parties: the literal prefixes "smart-id" and "ACSP_V2", the server random, the RP challenge, the user challenge, the Base64-encoded relying-party and brokered-RP names, a Base64-encoded SHA-256 of the interactions, the interaction type, the initial callback URL, and the flow type. The digest is the hash of that UTF-8-encoded message. Signing requests use a different protocol, RAW_DIGEST_SIGNATURE, in which the phone signs the digest of the document itself; the key-on-device argument below applies to both.

The signature is made with the user’s private key, which is generated and stored inside the Smart-ID app and never leaves the device. The bank verifies it against the user’s certificate, and the official response-verification checklist covers session secrets, response state and result, the user challenge, certificate chain validation against the configured trust anchors (SK’s roots), scheme and certificate-purpose checks, assurance level, identity match, signature verification, session invalidation, and signed-document visibility. To pass the signature check, the attacker would need the user’s private key, and inside the protocol the only way to use it is physical access to the phone plus knowledge of the PIN. There is a route around the key that never touches the protocol: as Paršovs notes, scammers have begun exploiting weaknesses in the Smart-ID issuance process itself. An account fraudulently issued to the attacker in the victim’s name needs neither the victim’s phone nor their PIN.

The MITM conclusion follows: no amount of network access lets an attacker forge an authentication or signing response. Whatever is wrong with Smart-ID, it is not the protocol layer; the weaknesses are in issuance and, above all, in the approval step.

The attack surface that actually gets exploited is the consent step, and it has been for years. Large-scale phishing in Estonia began in 2019, when banks phased out password cards and moved customers to Smart-ID. Arnis Paršovs, a cybersecurity researcher at the University of Tartu, made the uncomfortable comparison in an ERR opinion piece in January 2026: password cards were clunky, but a scammer on the phone had to explicitly ask a victim for passwords, which raised suspicion. With Smart-ID, all the scammer needs is for the victim to confirm a request. That is exactly how the system is designed to be used. Payments authorized with password cards had daily limits of a few hundred euros; banks introduced no comparable limits for Smart-ID despite its known issues.

The scale of the problem is now public. RIA, Estonia’s Information System Authority, reported that people in Estonia lost 29 million euros to fraudsters in 2025, three times the year before by RIA’s count; the police’s own 2024 figure, 16 million, makes it nearly double. Eesti Pank counted 13.5 million euros in payment fraud in 2024, up 4 percent. The two figures measure different things: RIA’s covers scam losses broadly, Eesti Pank’s covers card and credit-transfer fraud, so they are not one series and the 2024 numbers should not be compared. The mechanics are textbook vishing: a caller posing as a bank employee or police officer, a story about an unauthorized transaction, and repeated requests to enter Smart-ID or Mobile-ID PIN codes. The same RIA writeup describes a nonprofit organization that lost over 120,000 euros this way: a fake "switchboard installer" call was followed by callers posing as police and bank employees, and by repeated PIN entries.

Paršovs’ central argument is that the burden is placed on the wrong party. The main security weakness of Smart-ID is that its safety depends entirely on users being able to recognize phishing websites or verify the identity of callers. Decades of empirical research show the average user’s ability to identify phishing is close to random guessing, and even technically knowledgeable users are frequently fooled by well-crafted pages. Meanwhile banks warn customers not to approve Smart-ID requests during suspicious calls, and their own helplines identify customers with the very same method. As he puts it: "Human error is expected and safety must be built into the system."

Paršovs’ counterfactual makes the point sharper: every Estonian resident has an ID card whose authentication is phishing-resistant. An ID-card authentication performed on a phishing website cannot be reused by an attacker to impersonate the user at a bank. No bank advises customers to use the ID card, because that would require acknowledging Smart-ID’s weakness.

SK made Smart-ID+ available to integrators on 26 June 2025. Instead of the bank initiating a request the user then confirms, the user initiates the operation themselves by scanning a QR code. That makes call-based phishing dramatically harder, because there is no incoming request to be tricked into approving. The feature can go further: as Paršovs notes, when the flow is initiated on the same mobile device that runs the Smart-ID app, the process becomes fully phishing-resistant, matching the ID-card level.

Adoption is the problem. As of Paršovs’ January 2026 article, only LHV had enabled the verification-code feature, a separate feature from Smart-ID+, which requires the user to check a code by selecting the correct one from multiple choices. Smart-ID+ itself reached Estonian banks a year after SK made it available: Bigbank launched it in June 2026 (on 11 June), the first Estonian bank to do so, and LHV rolled out Smart-ID+ login across its Internet Bank from 16 June 2026. SEB said it expects to have it in place within 2026, and Swedbank also said later in 2026. At the launch, SK board member Liisa Luukin said call-based login attacks were "now over". For the login step that is close to true; the relay section below explains why it is not true for everything after the login. Paršovs is blunt about why the rest of the market lags: Swedbank and SEB, which dominate Estonia’s retail banking market, are among the owners of SK ID Solutions, giving them an obvious interest in promoting Smart-ID and downplaying concerns about its security. SK’s paying customers are banks and service providers, not users. Convenience wins, and users cannot opt into stronger security even if they want it.

The company that builds the national authentication rail is co-owned by two of the banks that decide whether to harden it. That is a misaligned incentive, and the timeline fits it: a phishing-resistant flow available to integrators from June 2025, live at Bigbank and LHV only from June 2026, with SEB expecting it "within this year" and Swedbank later in 2026. The first two banks to ship it are not among SK’s owners; the two that are come last.

The Smart-ID+ QR flow makes the call-based attack much harder, but it opens a new question: what happens when the QR code the user scans is generated inside a context the attacker controls? The answer is the interactive signing-relay class of attack. The class itself is not new. It combines browser-in-the-browser, remote-browser phishing and QRLJacking, the label I used when reporting it to SK. What this report adds is how it applies to Smart-ID+ and to the verification-code mitigation.

Static phishing pages fail against Smart-ID+ for a concrete reason: a dynamic QR code will not be generated in a phishing context, because the legitimate service controls the session that mints it. The relay solves that by not cloning the page at all. Instead of a fake login form, the attacker serves a fake browser window, rendered in HTML and CSS, that embeds a live stream of a real browser session running in a container. The victim sees the legitimate login portal, the legitimate QR code, the legitimate SSL indicators. They are looking at the real thing, relayed pixel by pixel.

The victim logs in, or scans the QR code, inside that remote session. The session cookie lands in the attacker’s browser, not the victim’s. From here the attack becomes an interactive relay. The attacker’s automation watches the authenticated session, initiates a sensitive operation such as a transfer, and the bank responds with a PIN2 challenge carrying a four-digit verification code. The attacker reads that code from the page and mirrors it into the fake window the victim is watching, with a message telling the victim to enter the code and confirm with PIN2. The victim checks their phone, sees the same code, and approves. They have just authorized the attacker’s transaction, and every security indicator they checked said the operation was legitimate, because the code they verified was genuine. It was just verified against the attacker’s presentation of it, not the bank’s.

That step depends on how the bank confirms payments. The relay as described works where the bank, after a Smart-ID+ login, confirms the transfer with the older notification flow and its verification code. SK says its Smart-ID+ flows do not ask the user to compare a code at all. A payment confirmed with a second cross-device QR scan is a different relay question, not one this report answers; LHV said in January 2026 that QR flows stay vulnerable when the fraudster is in live contact with the victim.

The relay defeats the verification-code mitigation structurally. A code that exists to bind an approval to its context is only as good as the context it is displayed in, and the relay controls the display. It also defeats the drag test, the usual advice for spotting browser-in-the-browser tricks: a real popup can be dragged off the browser onto the desktop, a fake one cannot. That heuristic assumes the victim knows to run it.

A caveat. This attack class was implemented as a proof of concept in a research environment against SK’s public DEMO environment, with automation for the relay pipeline. I reported the QR/MITM relay vectors to SK in November 2025. On 5 December 2025 SK replied that the weakness was "known to us during development" and that "for a certain period we have consciously accepted this risk". A CVE was requested; SK disputes the finding, calling it an "architectural feature". The pipeline was implemented and the mechanism demonstrated piecewise in the research environment; an end-to-end run of the full relay chain was still pending when this report was written. The claim here is not that this exact chain has been run against a live bank; it is that the architecture of cross-device QR flows makes the relay possible, and that the verification-code mitigation does not stop it. The production flow does not change the underlying design.

The protocol layer of Smart-ID is strong, and the approval layer is weak. Most public arguments about Smart-ID pick one of those and ignore the other.

The relay attack is the sharpest form of the second fact, but it is not a new failure class. It is the same failure as the 2019-era vishing, upgraded. In vishing, the attacker deceives the user into approving a request they cannot inspect. In the relay, the attacker lets the user inspect everything, and then controls what they inspect. The vector is different; the structural problem is the same: the approval is not bound to the context it is approving. The phone reports that the user approved. It cannot report what the user was shown, because it never sees it.

That is the same lesson as client-side trust generally. Any attestation produced by a device is a report from a machine you do not control. It is a signal, never a verdict. The signing key on the phone is doing real cryptographic work, but the decision being signed is made by a human looking at a screen, and that screen is the attacker’s territory.

The cost of the gap is visible in national numbers: 29 million euros lost in 2025, nearly double the police’s 2024 figure, with abuse of Smart-ID and Mobile-ID PIN approvals recurring through the cases RIA describes. That banks chose not to fix the weakness, and that the state is left managing the consequences, is Paršovs’ argument, and the fraud statistics support it. And the accountability structure makes it worse. By law, banks are not obliged to refund fraudulent payments if they were authorized with the method agreed with the bank. The party with the least information, the user, carries the loss; the parties that chose the authentication method, the banks and the vendor two of them co-own, carry nearly none. Paršovs’ framing is that the security breach happens earlier than the PIN2 confirmation, at the moment the bank grants a scammer access to the account in the first place, and victims should stop blaming themselves and seek compensation from their bank instead. That is starting to change at EU level. Under the Payment Services Regulation agreed politically on 27 November 2025 and approved by the European Parliament’s ECON committee on 5 May 2026, a payment provider must refund the full amount in bank-impersonation fraud if the customer reports it to the police. Formal adoption was still pending at the time of this update.

Most of the fixes below already exist somewhere: in SK’s product, in one bank’s deployment, or in EU law that is already on the books. Liability shifting for authorized fraud is the exception; it is not in force in Estonia.

Make the verification-code check mandatory. The multiple-choice verification code exists, and at least one bank (LHV) uses it. It is not a silver bullet, as the relay shows, but it raises the cost of call-based attacks and closes the simplest paths. A regulator can require it: Finantsinspektsioon supervises banks, and RIA sets the national cyber requirements. Either can move.

Make Smart-ID+ the default, with the same-device flow where it is available. Same-device is the one variant Paršovs calls fully phishing-resistant: a flow initiated by the user on the device that holds the key, with no QR relay surface. SK made Smart-ID+ available in June 2025; Bigbank and LHV went live with it in June 2026, and SEB and Swedbank say later in 2026.

Bind the approval to the transaction, not just to a code. The approval screen should show the amount, the payee, and the purpose, and the app should refuse to approve when that context is missing. Transaction context shifts the burden: the phone shows the real payee and amount, so an attacker must display the true transaction and hope the victim does not notice they never initiated it. Most of this is enforcing a duty that already exists. PSD2’s rules on strong customer authentication (Delegated Regulation 2018/389, Art. 5(1)(a)) already require that the payer is made aware of the amount and the payee, and SK’s v3 API lets the bank send that display text to the app. Only the last step, an app that refuses to approve when the context is missing, needs SK.

Shift the liability. If banks choose the authentication method, banks should carry the fraud loss when that method is phished, as PSD2 Art. 74(2) already does when a bank skips strong customer authentication. The Payment Services Regulation’s impersonation-refund rule, described above, is a first step in that direction. The current structure, where the user carries the loss for a decision the bank made, is the real reason the fixes are not deployed. Liability is the only lever that has historically moved banks.

Use the regulatory floor. For banks it is already higher than the Smart-ID debate suggests. PSD2’s strong-authentication rules require transaction monitoring that covers known fraud scenarios and signs of malware in sessions (Delegated Regulation 2018/389, Art. 2) and the dynamic linking of amount and payee (Art. 5). DORA (Regulation 2022/2554) is the sector-specific ICT-risk regime for credit institutions. NIS2 adds a general layer: Estonia’s transposition, the amended Cybersecurity Act (KüTS), has applied since 1 January 2026 and covers credit institutions. eIDAS 2.0, in force since 20 May 2024, will require some private relying parties to accept EUDI-wallet authentication, but only those legally required to use strong user authentication, not micro or small enterprises, only at the user’s voluntary request, and only 36 months after the implementing acts (Art. 5f(2)). SK’s assurance-level description, published by RIA, rates Smart-ID at eIDAS level High. That rating says nothing about phishing resistance, and that gap is the regulatory problem.

None of this requires new cryptography. The protocol was never the weak link. The strongest part of the system is trusted to protect the weakest part, and the weakest part is a human looking at a screen the attacker can control.