When the user is the attack surface: financial scams, susceptibility and the CRA’s definition of a vulnerability

The scenario

A customer using a mobile banking app receives a text message that looks like it came from their bank. It says a payment is pending and asks them to confirm. They open the banking app, a push notification appears, they tap approve. Minutes later the money is gone. Nobody broke the app’s encryption. Nobody bypassed authentication. The user did exactly what the app asked.

Is that a vulnerability under the Cyber Resilience Act?

The question matters because the answer decides whether a fraud problem is also a CRA problem. If it is, the mobile banking app’s manufacturer has to treat it in the Article 13 risk assessment, document it in the technical file, and potentially report it under Article 14. If it is not, the loss stays where it has always sat: with the payments and fraud teams under PSD2.

This blog dives into the details and explains where the line falls and what it means for banks whose mobile banking apps, and the remote data processing that supports them, are in scope of the CRA.

Three words, one definition

Article 3(40) of the CRA defines a vulnerability as a weakness, susceptibility or flaw of a product with digital elements that can be exploited by a cyber threat. Two parts of that sentence do the work here.

The first is “of a product with digital elements”. A vulnerability is a property of the product. It is not a property of the manufacturer’s organisation, of the network the product sits on, or of the person using it.

The second is the choice of three words rather than one. The regulation does not define them separately, and neither does the Commission’s Final Guidance or FAQ. Read in their ordinary sense, they divide the field like this.

Flaw. A defect in implementation. The product does something it was not meant to do. Memory corruption, missing input validation, a logic error in a permission check.

Weakness. A security measure that exists and works as designed but is not strong enough. Short keys, deprecated cipher suites or no lockout threshold for failed authentication attempts.

Susceptibility. A property of the product that makes it prone to a class of attack, or to compromise under foreseeable conditions, even where no individual control is defective. The product is built exactly as intended. The way it is built, configured or positioned still leaves it open to harm.

Susceptibility is the word that stops a manufacturer arguing “there is no bug and every control meets its specification, therefore there is no vulnerability”. It is also the word that matters for social engineering, because social engineering rarely needs a flaw. It needs a product that makes the wrong action easy and the right judgement hard.

The user is not the product

Go back to the smishing victim. If the app showed the correct payee, the correct amount and the fact that the payee was new, applied strong customer authentication, and the user read all of that and tapped approve, the product’s security functions did what they were designed to do. The user formed an intention, however badly informed, and the product executed it.

There is no CRA vulnerability in that scenario. The person was deceived; the product was not. Nothing is reportable to ENISA under Article 14, because there is no vulnerability being exploited and no incident affecting the product’s ability to protect the confidentiality, integrity, authenticity or availability of data or functions, which is the Article 3(44) test.

The loss is authorised push payment fraud. In the EU that is governed by PSD2 and the incoming Payment Services Regulation, which is where liability for impersonation fraud is being argued out. The bank’s own incident and operational-resilience duties under DORA may also come into play.

The word “susceptibility” does not change this. It qualifies the product, not the person.

Where the product becomes susceptible

Now change the facts slightly. The push notification said “Approve login?” when it was actually authorising a payment. Or the payment was pre-populated from a deep link in the text message and the confirmation screen was skipped. Or a malicious app drew an overlay across the confirmation and the user never saw the payee at all.

In each of those cases the user still tapped approve. But the product contributed something to the attack. It removed the information or the friction that would have let an ordinary person notice something was wrong. That is a susceptibility of the product, and it is squarely within Article 3(40).

The test is whether a reasonably foreseeable social-engineering attack succeeds because of how the product is designed, rather than purely because of the person. For a consumer banking app, smishing, vishing and remote-access scams are not edge cases. They are the dominant threat to the product’s users. A design that does not account for them is hard to defend as providing an appropriate level of cybersecurity based on the risks, which is the first essential requirement in Annex I.

The table below sets out the design characteristics we most often see, the attack they enable, and the Annex I requirement each one undermines.

Two observations about that table. First, none of the rows is a flaw. A code scanner will not find any of them, and none of them will ever carry a CVE. They are found by threat modelling with the user in the loop. Second, several rows are not only vulnerabilities to be tracked but non-conformities with an essential requirement. That changes who owns the finding and how urgently it has to be closed.

What the risk assessment has to say about it

The legal hook is Article 13(3). The cybersecurity risk assessment must analyse risks based on the “intended purpose and reasonably foreseeable use of the product”, and on its conditions of use, including the operational environment and the assets to be protected. For a retail banking app the operational environment is a consumer’s phone, the asset is their money, and the foreseeable use includes being targeted by fraudsters who know exactly how the app behaves.

The Commission’s Final Guidance goes further than most manufacturers expect. Paragraph 158 says that the intended users of the product are part of the operational environment the assessment must consider. Paragraph 160 says that where risks are identified, the manufacturer may need to shape the reasonably foreseeable use of the product through risk communication, user guidance or user-interface design, in order to steer user behaviour toward secure use patterns. The regulation is saying clearly that interface design is a cybersecurity control.

The CRA FAQ adds that the assessment should consider the intended or foreseeable category of user, and that conditions of use must be reasonable for low-skilled or vulnerable users in particular. A banking app cannot assume a security-aware user population.

In practice this means four things for the technical documentation.

1. Smishing, vishing and remote-access scams appear as named threats in the risk assessment, with the consumer user population recorded as a condition of use.
2. Each design characteristic in the table above is assessed as a potential susceptibility and mapped to the Annex I requirement it affects.
3. The exploitability test from Article 3(41) is applied and documented. A susceptibility that can only be used with physical access to an unlocked phone is a different finding from one that works from a text message.
4. The boundary is written down. The product is accountable for giving the user accurate information and proportionate friction at the moment of authorisation. It is not accountable for the user’s decision once those are in place.

Need a risk assessment that starts from your users rather than a CVE feed?  See how Attestra documents foreseeable use, threats and Annex I mapping in one place.

When a scam campaign becomes an Article 14 report

Article 14 has applied since 11 September 2026. It requires manufacturers to notify ENISA’s Single Reporting Platform within 24 hours of becoming aware of an actively exploited vulnerability.

A smishing campaign on its own is not an actively exploited vulnerability. Article 3(42) requires reliable evidence that a malicious actor has exploited a vulnerability in the product. If the attackers are exploiting the user’s trust and the product is behaving as designed, there is no product vulnerability in the chain and nothing to report. The bank reports the fraud under its payments and NIS2 obligations instead.

It becomes reportable when the evidence shows attackers are using one of the product susceptibilities described above to obtain approvals the user did not knowingly give. A campaign that depends on a deep-link flow skipping the confirmation screen, or on an overlay weakness in the authorisation prompt, is exploiting the product. At that point the 24-hour early warning applies, followed by the 72-hour notification and the final report.

The practical consequence is that fraud intelligence and product security need a shared triage step. When the fraud team sees a new scam pattern, someone with product knowledge has to ask one question: is this working because of something in the app, or in spite of it? The answer decides whether the case stays in the fraud queue or moves into the CRA vulnerability-handling process with a timestamped awareness decision behind it.

Attestra for risk assessment and vulnerability handling

Most CRA tooling starts from a CVE feed. That is the wrong starting point for the susceptibilities in this article, because none of them will ever appear in one.

Instead Attestra starts from the product and its users. It walks the team through intended purpose, foreseeable use and conditions of use as Article 13(3) requires, prompts for threat categories including social engineering against the user population, and maps each identified susceptibility to the Annex I requirement it affects. The output is the documented, versioned risk assessment the technical file needs, not a spreadsheet nobody owns.

When a fraud pattern does turn out to involve the product, the Vulnerability Handling and Reporting module takes over. It runs the triage question above as a guided workflow, records the exploitability decision, and drafts the 24-hour, 72-hour and final notifications if the finding crosses the Article 3(42) threshold. Every step is logged into an audit trail you can export straight into the Article 31 documentation pack.

Talk to a CRA specialist

Fraud prevention is now product cybersecurity

For two decades the design of a payment authorisation screen has been a fraud-team decision, measured in basis points of loss and governed by PSD2. The CRA does not take that away. It adds a second lens.

The same screen is now part of a product with digital elements, assessed under Article 13 against the threats its users actually face, and documented in a technical file a market surveillance authority can ask for. A confirmation prompt that hides the payee is no longer only a conversion-rate trade-off. It is a susceptibility of the product, and the manufacturer has to be able to show it was identified, assessed and either fixed or justified.

The user can still be deceived. The CRA does not pretend otherwise. What it asks is that the product does not make the deception easier than it needed to be.

Frequently asked questions