The adequacy of possession elements in the contexts of strong customer authentication depends on the architecture of the service i.e. the combination of elements used for authentication. Hence, each combination shall be assessed separately using a risk-based approach. Possession elements may evolve over time (e.g. wearable devices). The specific use of possession elements or combinations of possession elements shall be left to the service provider and supporting entities.

Behaviour based characteristics have the potential to support strong customer authentication. However, the use of behaviour-based characteristics shall be considered in combination with privacy issues of the PSU. Hence these elements need to be considered by the industry once they have matured in the context of concrete services.

Independence of authentication elements is largely linked to the question whether critical transactions should be sent from a single device combining all elements of customer authentication or whether two devices should be used. There is no simple answer to this question. Risk evolves with the evolution of technology (may increase or decrease) and the capabilities of the fraudsters. A dynamic risk based assessment of service architecture seems to be advisable.

Dynamic links are a valuable element of strong customer authentication. Since they are part of many technical communication standards, there should be no strong hurdle for the implementation of such features.

Mobile devices offer already today a variety of combinations of software and hardware security features. Depending on the risk to be mitigated, it might be advisable to combine software and hardware (SIM, eSIM, SE) security elements.

The clarifications are useful. Eventually the PSP shall make a conscious risk assessment and decide on mitigation measures accordingly.

Assuming that the PSP is in the lead for the determination of exemptions in the framework of the given legislation, the EBA should consider how to get evidence of the decision making process of the PSP and how to assess the adequacy of the considerations.

Due to the fast evolution of technical solutions, it seems to be advisable to leave it to the PSP to use transaction risk analysis features. EBA should refrain from setting RTS standards.

The EBA’s clarifications are in line with IT security requirement, i.e. stating that data shall be secured during creation, storage and transmission. However, PSPs need to decide on each component and transmission channel individually when creating a payment service. As stated by the EBA this requires a risk based approach by the PSP. Certification of components and channels might be a desirable information for the PSP. For example, EBA could invite potential providers of components and channels to certify their components. However, a heavily formalized process might slow down time to market and might even increase the risk if the certification process slows down the implementation of security upgrades of new securer components.

The personal behaviour of the user and particularly the exposure to social engineering causes additional risk.

Standards and products for enrolment processes are available on the market (TLS, CAs, electronic signature, SE, SIM, …). What matters is that standards, components and processes form a secure end-to-end process. The security level should be consistently high throughout the whole processing chain. Trusted Service Management undertaken by MNOs is an example of such an “end-to-end Ecosystem”. Solutions should be open for the seamless integration of new and securer components.

Certification made on behalf of the vendor might be a supporting sales argument. However due to the skills and resources of potential fraudsters certification cannot protect completely against vulnerabilities and security loopholes. It should be emphasized that eventually the security assessment and the risk appetite of the service provider matters.

See 11. The end user should be technically protected to the largest possible extent.

Security levels determined within standards and compatibility between standards are issues that require industry cooperation and willingness to invest in implementation of such standards. Requirements for such standards are evident and should not go beyond general descriptions unless there is a clear market failure. Eventually the PSPs and other supporting parties have the duty to combine tools and standards in the most appropriate way in line with the criticality of the business and threat analysis. Open standards like OpenID Connect and Mobile Connect are examples of successful standardisation efforts of the industry.

Based on standards and secure vendor products, the PSPs and supporting entities should cater for optimal solutions. There is little need for regulatory intervention.

The requirements should stay on a rather generic level (see also 15). Implementation should be left to the industry. To foster trust services, it might be one desirable solution to design a high-level process that allows PSPs to act as a trusted party in between end user and bank i.e. agreeing on specific credentials for each communication channel (end user PSP/PSP bank) separately but covering the whole processing chain.

In order to minimize regulatory overhead there should be strong efforts to (re)use the e-IDAS regulation to the largest extent possible.