EMV® Mobile Payment: Software-based Mobile Payment Security Requirements

EMV® Mobile Payment Software-based Mobile Payment Security Requirements Version 1.5 January 2025 © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Legal Notice Page 2 / 48 The EMV® Specifications are provided “AS IS” without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in these Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT, AS TO THESE SPECIFICATIONS. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to determine whether any implementation of the EMV® Specifications may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of the EMV® Specifications should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, the Specifications may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement these Specifications is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party’s infringement of any intellectual property rights in connection with the EMV® Specifications. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 3 / 48 Version 1.0 Date December 2016 Version History Description First publication. This document provides security guidance and defines generic security requirements for applications and interfaces involved in payment transactions that do not involve a Secure Element. 1.1 September 2018 Minor updates and addition of attestation requirements. 1.2 February 2019 Minor updates and addition of Software Protection Tools requirements. 1.3 April 2020 Minor updates and addition of definitions. 1.4 August 2020 Addition of In-App Payment definition. 1.5 January 2025 Requirements update (#2.1, new #8.6). © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 4 / 48 Contents Legal Notice ........................................................................................................................ 2 Version History ................................................................................................................... 3 Tables .................................................................................................................................. 6 Figures................................................................................................................................. 7 Requirements ...................................................................................................................... 8 1 Introduction ................................................................................................................... 9 1.1 Objective ................................................................................................................ 9 1.2 Audience ................................................................................................................ 9 1.3 Scope ................................................................................................................... 10 1.4 References ........................................................................................................... 10 1.5 Definitions ............................................................................................................ 10 1.6 Notational Conventions ........................................................................................ 16 1.6.1 Abbreviations ............................................................................................ 16 1.6.2 Terminology and Conventions................................................................... 17 1.7 Support................................................................................................................. 18 2 Software-based Mobile Payments.............................................................................. 19 2.1 Mobile Application ................................................................................................ 19 2.1.1 Software Development Kit......................................................................... 19 2.1.2 Software Library........................................................................................ 20 2.2 Credential Manager .............................................................................................. 20 2.3 Credential Storage................................................................................................ 20 2.4 Consumer Device Platform................................................................................... 22 2.4.1 Basic Platform........................................................................................... 22 2.4.2 Enhanced Platform ................................................................................... 23 2.5 System Overview ................................................................................................. 24 3 Mobile Application Software Life Cycle and Best Practices .................................... 25 3.1 Application Design and Development ................................................................... 26 3.1.1 3.1.2 3.1.3 Secure Communication Channels ............................................................. 27 Platform Security....................................................................................... 27 Application and Device Attestation ............................................................ 27 3.2 Mobile Application Download and Installation ....................................................... 28 3.3 User Enrolment .................................................................................................... 29 3.4 Provisioning and Credential Issuance................................................................... 29 3.5 Card Credential Replenishment............................................................................ 30 © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 5 / 48 3.6 Monitoring and Reporting Information................................................................... 30 3.7 Mobile Application Security and Management ...................................................... 31 3.7.1 Application and Platform Update Mechanism............................................ 31 3.8 Application Removal............................................................................................. 31 4 Mobile Application Security Architecture.................................................................. 32 4.1 Architecture of the Mobile Application................................................................... 32 4.1.1 Interface Endpoints ................................................................................... 33 4.2 Mobile Application Security Model ........................................................................ 34 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 Security Objective ..................................................................................... 34 Attacker Goal ............................................................................................ 34 Payment Threats....................................................................................... 34 Scenarios.................................................................................................. 35 Threat Model............................................................................................. 35 Attacks...................................................................................................... 36 4.3 Assurance Level ................................................................................................... 38 4.4 Mobile Application Assets..................................................................................... 39 5 Mobile Application Security Requirements ............................................................... 42 5.1 MA-SEC-REQ-1: Security Guidance and Usage Instructions .............................. 42 5.2 MA-SEC-REQ-2: Asset Protection....................................................................... 43 5.3 MA-SEC-REQ-3: Mobile Application Protection ................................................... 44 5.4 MA-SEC-REQ-4: Authentication–Identification and Verification ........................... 45 5.5 MA-SEC-REQ-5: Consumer Authentication......................................................... 45 5.6 MA-SEC-REQ-6: Reporting and Attestation......................................................... 46 5.7 MA-SEC-REQ-7: Cryptographic Keys, Methods, and Random Numbers............. 47 5.8 MA-SEC-REQ-8: Secure Mobile Application Design, Development and Maintenance......................................................................................................... 48 © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 6 / 48 Tables Table 1.1: Table 1.2: Table 1.3: Table 4.1: Table 4.2: References........................................................................................................ 10 Definitions ......................................................................................................... 10 Abbreviations .................................................................................................... 16 Attacks on the Mobile Application ...................................................................... 36 Mobile Application Assets.................................................................................. 40 © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 7 / 48 Figures Figure 2.1: Provisioning of Card Credentials ...................................................................... 21 Figure 2.2: Basic Mobile Payment System Overview (Example) ........................................ 22 Figure 2.3: Enhanced Mobile Payment System Overview (Example) ................................. 23 Figure 3.1: Mobile Application SLC Model.......................................................................... 25 © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 8 / 48 Requirements 5.1 MA-SEC-REQ-1: Security Guidance and Usage Instructions .............................. 42 5.2 MA-SEC-REQ-2: Asset Protection ...................................................................... 43 5.3 MA-SEC-REQ-3: Mobile Application Protection................................................... 44 5.4 MA-SEC-REQ-4: Authentication–Identification and Verification........................... 45 5.5 MA-SEC-REQ-5: Consumer Authentication ........................................................ 45 5.6 MA-SEC-REQ-6: Reporting and Attestation ........................................................ 46 5.7 MA-SEC-REQ-7: Cryptographic Keys, Methods, and Random Numbers ............ 47 5.8 MA-SEC-REQ-8: Secure Mobile Application Design and Development............... 48 © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 9 / 48 1 Introduction The payment industry has concentrated its efforts for several years on leveraging the existing chip card ecosystem and processes, where security models are well known and defined. With the deployment of mobile consumer devices and the opportunity for easier deployments, the payment industry is interested in a trust model that does not rely solely on the use of a Secure Element (SE) to store and process payment transactions. This new model comes with its challenges and requires, in particular, specific attention to the security aspect of such designs and implementations. There are many different available architectures to implement software-based mobile applications. Such applications can be installed, for example, in a Rich Execution Environment (REE), the combination of an REE and a Trusted Execution Environment (TEE), or the combination of an REE and a Secure Element (SE). The architecture choice has an impact on the final security assurance level of the payment product. This document aims to establish a common security understanding around using a Consumer Device (such as a mobile phone) and applications (Mobile Applications) present on the device, for payment. This document does not focus on any specific type of payment; rather it: • Provides an overview of the system architecture, both for the issuance of Card Credentials and for payment transactions using these credentials. It also defines the various roles involved in issuance of, and transactions conducted with, these credentials. • Describes various models of management for the Mobile Application and for the Card Credentials and the Mobile Application software life cycle. 1.1 Objective This document provides security guidance and defines generic security requirements for software-based mobile applications and the relevant interfaces involved in payment transactions. Functional requirements are out of scope of this document. 1.2 Audience This document is intended for use by Payment System staff, architects and developers of software-based payment solutions, Consumer Device architects, payment service and Token Service Providers, security laboratories, and Issuers of software-based payment products. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 10 / 48 1.3 Scope The scope of this document is the software-based mobile application as it could be downloaded, installed, provisioned, and used on any type of device and for any payment services (e.g. proximity payment and remote payment). The concepts explained in this document apply for all types of Operating Systems (OS) as well as most known Consumer Device architectures (including the use of multiple devices such as wearables connected to a mobile phone). They also apply to platforms where a TEE, TPM, and/or SE are available for hardware support. 1.4 References The following documents contain provisions that are referenced in this specification. The latest version including all published amendments shall apply unless a publication date is explicitly stated. Reference [Pmt Card Mgmt] [TPM] Table 1.1: References Document EMVCo – EMV Contactless Mobile Payment – Payment Card Management Whitepaper Trusted Computing Group, TPM Main Specification http://www.trustedcomputinggroup.org/resources/tpm_main_specifi cation 1.5 Definitions The following terms are used in this document: Term Acquirer Table 1.2: Definitions Description An entity that has a commercial relationship with the Merchant and with the Payment System and processes payment transactions on behalf of the Merchant. Application Program A set of routines, protocols, and tools for building software Interface (API) applications. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 11 / 48 Term Attestation Attestation System Authentication Basic Platform Card Card Credentials Cardholder Verification Method (CVM) CDCVM Solution Code lifting Consumer Consumer Device Consumer Device Cardholder Verification Method (CDCVM) Description Verifying the integrity of a configuration of software and hardware components. The set of components of the SBMP System that performs Mobile Application attestation. The presentation of credentials as proof that the User is who (s)he claims to be. A Consumer Device platform that does not provide verifiable hardware security for protection of sensitive or security related assets. A card is used here as a generic term for the payment application linked to an account by virtue of its PAN or Payment Token. A set of data elements, sensitive assets, and security related assets necessary to enable payments. The method used to check that the valid cardholder is using the card. Examples of CVM include signature, online PIN, and offline PIN. The CDCVM Processing Environments together with the Authenticator API and its secure storage that provide shared CDCVM on the consumer device. Transferring executable code to another system while retaining the functionality without the need to fully reverse engineer it. The user of the Card Credentials used for payment transaction. The device, typically a mobile phone or a tablet, which hosts the Mobile Application used for payment by the consumer. A form of consumer authentication performed on a Consumer Device. Verification of the CDCVM serves to verify whether the person presenting the Consumer Device is a legitimate user of the device. Examples of CDCVM include numeric passcode, a pattern (e.g. used for Android device unlock), or a biometric authentication (e.g. fingerprint, iris, facial). © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 12 / 48 Term Credential Manager Description The entity that manages the Card Credentials to be provisioned to the Mobile Application. The Credential Manager has the capability to establish a secure communication with the Mobile Application for the provisioning and management of Card Credentials. Device Attestation A mechanism that allows a Consumer Device to present evidence to the requesting party about the integrity of its security model. Device Binding Using device information or hardware features to make it hard or impossible to operate software on a different device or platform. Enhanced Platform A Consumer Device platform that provides verifiable hardware security for protection of security assets. Ephemeral asset Data existing in memory only for the brief period necessary to process the data. In-App Payment In-app payment refers to the buying of goods and services within an application using stored or accessible Card Credentials. These Card Credentials are considered throughout this document when they are stored or accessible directly to a Mobile Application and transmitted online to facilitate processing of the payment. Information Binding Using unique device information to make it hard to operate the software elsewhere without obtaining this information from the device. Issuer The entity that manages the account linked to the Card Credentials on the Consumer’s Mobile Device. Library A collection of pre-written code, classes, procedures, scripts, configuration data, and more, intended to provide one specific function (e.g. cryptographic library). All of the available functions within a software library can be called/used within the program body without defining them explicitly. Long-lived asset Data existing in memory for the period necessary to make use of the data over multiple sessions. Merchant An entity that sells goods or services to the Consumer and is equipped to process a software-based mobile payment transaction. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 13 / 48 Term Mobile Application Description A software-based application that may be downloaded from an application store or may come pre-loaded in the Consumer Device. In the context of mobile payment and in its most complex form, it may store several sets of Card Credentials linked to various Issuers and Payment Systems and enables the Consumer to manage and transact with them. For example, a Payment Card Manager as described in [Pmt Card Mgmt]. Mobile Application Provider The entity responsible for installing and managing the Mobile Application on the Consumer Device. Monitoring Server-side controls able to detect a compromise occurring on a remote device. Obfuscation Hiding information about program state, execution flow, and data streams to make it hard to understand the meaning and functionality. Includes obfuscation of: • Data • Key(s) • Code / program The objective of obfuscated code is to conceal its purpose (security through obscurity), its logic, or implicit values embedded in it, in order to prevent tampering and deter reverse engineering. Open Web Application Security Project (OWASP) A worldwide not-for-profit charitable organization focused on improving the security of software. http://www.owasp.org Payment System An entity that has a commercial relationship with the Issuer and with the Acquirer. The Payment System specifies the payment related Card Credentials and the behaviour of Mobile Application(s). It may provide a Software Development Kit (SDK) that can be integrated into a Mobile Application to facilitate the deployment and/or usage of Card Credentials. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 14 / 48 Term QR Code Rich Execution Environment (REE) Rooting Short-lived asset Software Development Kit (SDK) Description QR Codes are two-dimensional machine-readable barcodes, which are increasingly used to facilitate mobile payments at the point-ofsale. The EMV QR Code Specification for Payment Systems supports two differing QR Code payment use cases: • Consumer-presented – the customer displays the QR Code on their mobile device and the merchant uses an optical scanner to read the code. In such use case, QR Code will be considered as Card Credentials throughout this document. • Merchant-presented – the merchant displays the QR Code and the customer uses their mobile device to scan the code. The Rich Execution Environment, also called Normal World (as opposed to the Secure World) is the non-secure operating system running alongside the TEE. It consists in the non-secure kernel and the user applications. The process by which a Consumer Device user attains privileged control or root access to run privileged commands. Rooting is often performed with the goal of overcoming limitations that carriers and hardware manufacturers put on some devices. Data existing in memory for the period necessary to make use of the data over a session. A set of software development tools that allows for the creation of a mobile application. In particular, an SDK can be one or more application programming interfaces (APIs) in the form of some libraries to interface with a particular programming language or to include sophisticated hardware that can communicate with a particular embedded system. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 15 / 48 Term Software Protection Tools Description Specialized software that provides security services to be integrated with general software. Such tools, when correctly configured, are intended to alleviate the necessity for a development team to focus on specific aspects of security. Such tools may include one or more of the following concepts, and a development team may need to use multiple such tools to achieve the level of security required: • White-Box Cryptography • Obfuscation • Attestation • Monitoring • Anti-hooking Token Service Provider A role within the Payment Tokenisation ecosystem that is authorised by a Token Programme to provide Payment Tokens to registered Token Requestors. Trusted Application (TA) Authorized software that can be securely executed inside the Trusted Execution Environment (TEE) and that exports results of security related functionality to Mobile Applications outside of the TEE. Trusted Execution Environment (TEE) A secure area of a main processor – also called Secure World – which provides security features such as an isolated execution environment for Trusted Applications. It protects security assets from general software attacks, defines safeguards as to data and functions that an application can access, and resists a set of defined threats. Virtual Trusted Execution Environment (vTEE) A Virtual Trusted Execution Environment is a TEE with little to no specific hardware support. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 16 / 48 Term White-Box Cryptography Description Transformation of a specific cryptographic algorithm (e.g. AES) with a cryptographic key into a White-Box Cryptography secure program. Anyone that knows the secure White-Box Cryptography program can execute it on any input and get the expected output, but is unable to learn anything more than such input-output pairs. The White-Box Cryptography program prevents exposure of the used cryptographic key and avoids reverse engineering of the White-Box Cryptography transformation. There is no standard White-Box Cryptography transformation method, so implementations may vary. 1.6 Notational Conventions 1.6.1 Abbreviations The following abbreviations are used in this document. Abbreviation API ATC BLE C CDCVM CVM DBI I I+ ID&V NFC Table 1.3: Abbreviations Description Application Programming Interface Application Transaction Counter Bluetooth Low Energy Confidentiality Consumer Device Cardholder Verification Method Cardholder Verification Method Dynamic Binary Instrumentation Integrity Integrity with the addition of accountability/authentication Identification and Verification Near Field Communication © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Abbreviation OEM OS OSSAP OTA OWASP PAN PCI SSC PII PIN PTC REE SDK SE SLC TA TEE TPM vTEE Description Original Equipment Manufacturer Operating System OWASP Software Security Assurance Process Over-The-Air Open Web Application Security Project Primary Account Number Payment Card Industry Security Standards Council Personally Identifiable Information Personal Identification Number PIN Try Counter Rich Execution Environment Software Development Kit Secure Element Software Life Cycle Trusted Application Trusted Execution Environment Trusted Platform Module Virtual Trusted Execution Environment Page 17 / 48 1.6.2 Terminology and Conventions The following words are used often in this specification and have a specific meaning: Shall Defines a product or system capability which is mandatory. May Defines a product or system capability which is optional or a statement which is informative only and is out of scope of this specification. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Should Defines a product or system capability which is recommended. Page 18 / 48 The following conventions apply: Requirement Numbering Requirements in this document are uniquely numbered with the number appearing next to each requirement: For example: 3.1 The Mobile Application must be securely installed. A requirement may have different numbers in different versions of the document. Hence, all references to a requirement should include the version of the document as well as the requirement’s number. Requirements may include informative statements. In this case the statement is written in the italic font and the verb ‘may’ instead of ‘shall’ is used. 1.7 Support For help and support about this document, contact the EMVCo Security Evaluation Secretariat at sbmpsecurity@emvco.com. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 19 / 48 2 Software-based Mobile Payments The term Software-based Mobile Payments is used to identify payment transactions where the Consumer Device is a mobile device such as a mobile phone. Commercially available software protection solutions must be used to provide the required software security controls and protections. 2.1 Mobile Application The big advantage of software-based Mobile Payments is that it provides a way to offer services without needing to use a hardware-based Secure Element. Therefore, there is no dependency on SE providers and less need to work in partnership with other parties (such as mobile operators or handset manufacturers). It also provides more flexibility to integrate Issuer payment programmes with their other mobile customer services. This document only describes requirements for a mobile application as an end-user product that is deployment ready. Most of the time however, software-only mobile applications are based on a Software Development Kit (SDK). An SDK provides all the generic mobile application payment functionality (e.g. interface with the NFC controller and the Credential Manager), meets most of the security requirements, and can make use of commercially available Software Protection Tools (e.g. attestation, white-box cryptography, or obfuscation functionality). 2.1.1 Software Development Kit The developer of an SDK for a payment Mobile Application focuses on the common functional and security requirements that can be used by many Mobile Applications. A validated SDK comes with a developer security guidance document which clearly describes how the SDK can be securely integrated into a Mobile Application. This allows a Mobile Application developer to focus on the integration of the SDK into their application without requiring them to be knowledgeable about every facet of the security, functions and interfaces needed to implement a fully functional, secure application. Security testing of the final mobile application will be limited to a security evaluation that the SDK security guidance has been properly implemented (this includes outstanding mobile application requirements not covered by the SDK). This SDK approach will yield compliant products while drastically reducing the amount of development and testing time of the final mobile application resulting in time and cost savings. In addition, in case of a security issue, the SDK products that might have an issue can be quickly identified and updated. The SDK requirements are a subset of the Mobile Application requirements, as some requirements might not apply to an SDK and can therefore be excluded. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 20 / 48 2.1.2 Software Library A software library provides a specific function (e.g. cryptographic library or device attestation) and can be open source or commercially available. A library consists of pre-written code, classes, procedures, scripts, configuration data, and more. A Mobile Application or SDK can use these available functions within a software library without redefining them. Software libraries that provide security services will be especially beneficial when their security has been previously evaluated and does not have to be re-evaluated during a Mobile Application evaluation. 2.2 Credential Manager The Credential Manager has the ability to establish secure communication with the Mobile Application for the provisioning and management of Card Credentials. Depending on the model used for the management of the Mobile Application and Software Cards, the Credential Manager may be any of several entities, such as an Issuer, a Token Service Provider, a Wallet Service Provider, or another Mobile Application Provider. Besides the security requirements described in this document, the security of Card Credential implementations relies on the Credential Manager having strong security controls. 2.3 Credential Storage In software-based Mobile Payments, credentials may be stored in an application located in the Rich Execution Environment (REE) or in the Trusted Execution Environment (TEE) of the Consumer Device, as applicable. The Consumer Device REE is considered to be untrustworthy and subject to arbitrary compromise. A TEE is considered to be more trustworthy but not to a level commensurate with an SE. In addition to providing secure storage and processing, a TEE can also provide trusted user interfaces for entering and displaying information. Security assets may also be split. For example, cryptographic keys may be stored in the TEE whilst non-sensitive parts of the Card Credentials may be stored in the REE. The credentials in such an application, even when split, are referred to as Card Credentials. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Figure 2.1: Provisioning of Card Credentials Credential Manager Secure communication Page 21 / 48 Mobile Application MyBank C MyBank B Card MyBan k A1234 5678 9012 3456 Credentials 1234 5678 9012 3456 12/17 LEE M. CARDHOLDER 1234 5678 9012 3456 12/17 LEE M. CARDHOLDER 12/17 LEE M. CARDHOLDER Consumer Device In Figure 2.1, the Credential Manager is the entity that provisions the Card Credentials to the Mobile Application. The Mobile Application is the entity that hosts the Card Credentials. A secure connection must be provided to ensure that the Card Credentials are protected endto-end regardless of the deployment model. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 22 / 48 2.4 Consumer Device Platform The Consumer Device platform can be software only and untrusted (i.e. Basic Platform; see Figure 2.2) or can have some level of trust due to added security functionality and hardware support (i.e. Enhanced Platform; see Figure 2.3). 2.4.1 Basic Platform The Mobile Application runs on a Consumer Device platform. This platform should be considered untrusted and may even be insecure (for example, if the device has been rooted). Note that being rooted does not mean being insecure. Being rooted is a threat if the root privileges are used to monitor or circumvent security measures used by the Mobile Application to protect the assets. Solutions that depend purely on software security are based on a model that does not rely on verifiable hardware security for protection of security assets. The software model forces the developer to create a solution that provides cryptographic services and protects those services against attack. Therefore, the Mobile Application should implement countermeasures (e.g. white-box cryptography, obfuscation, and binary protection), make use of Software Protection Tools, and / or make use of a virtual TEE (vTEE) to enhance its security and protect sensitive information and security assets. Figure 2.2: Basic Mobile Payment System Overview (Example) App Store App Download Enrolment / Management Card Credential download Mandatory Optional Interface Non-payment functionality Payment Assets App N Operating System F C Consumer Device Platform Issuance System Reader Authorization System Acquirer © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 23 / 48 2.4.2 Enhanced Platform The Mobile Application, or parts of it, can also be implemented as a Trusted Application (TA) in the Trusted Execution Environment (TEE) of the Consumer Device. The TEE is a separate execution environment that runs alongside the REE and hosts trusted services offered to that REE. The TEE can provide security features such as: • hardware-based isolation or dedicated security core • hardware root of trust • trusted boot process • hardware unique key embedded in the application processor and accessible by trusted OS only • hardware-based resources and peripherals for access control (e.g. fingerprint sensors) Trusted Applications are given controlled access to security resources and services via TEE Internal APIs. Because of its hardware protection, cryptographic root of trust, Consumer Device authentication, and possibly consumer authentication services, the TEE allows for secure remote management and update, as well as secure communication via protected channels; it may also simplify the protection of Mobile Applications, avoiding the need for White-Box Cryptography. As with Secure Elements, use of the TEE implies working in partnership with other parties (such as mobile operators or device manufacturers) that control access to the TEE. Other options for hardware security enhancements can be provided by a Trusted Platform Module (TPM) or even embedded Secure Elements. Figure 2.3: Enhanced Mobile Payment System Overview (Example) App Store App Download Enrolment / Management Card Credential download Mandatory Optional Interface Non-payment functionality Payment Assets TA or TEE App N Operating System F C Consumer Device Platform Issuance System Reader Authorization System Acquirer © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 24 / 48 2.5 System Overview As described in section 2.4, a Software-based Mobile Payment solution is comprised of several components. The following focuses not on the system architecture components, but on the security functionality of the different components. Once built and tested, the Mobile Application has to be distributed to the Consumer Device. The Mobile Application could be pre-installed on the Consumer Device via the Original Equipment Manufacturer (OEM) and third parties; the Mobile Application will more likely be downloaded or updated by the user via a trusted application store or an Issuer’s web site (e.g. OTA to device). The Mobile Application resides on a basic or enhanced platform in the Consumer Device. For a payment to take place, a valid set of Card Credentials needs to be present (via enrolment and provisioning) within a Mobile Application. To manage risk effectively, these credentials may need to be replenished on a periodic basis. The Credential Manager provides card configuration data that can be used to provision Card Credentials on a Mobile Application to enable software-based mobile payments, including the initial set of parameters deployed to the Mobile Application. It also replenishes dynamic credential data, according to the Credential Manager’s preferences. Finally, it manages the life cycle of a card (e.g. suspend, resume, and remove) as determined or triggered by either the cardholder or the Issuer. Issuer host systems are the existing authorisation/authentication/risk management systems that an Issuer currently uses for authorising and authenticating transactions. These components are therefore not new, but will typically need to be modified and/or enhanced to adequately support software-based mobile payments. This Issuer host system plays an important role in its analysis of transaction data to maintain the security of the Card Credentials. The acquirer is the organisation that is responsible for signing up the merchant and acquiring the transaction. No changes are required to the acquirer systems in order to support softwarebased mobile payments. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 25 / 48 3 Mobile Application Software Life Cycle and Best Practices This chapter summarizes considerations that must be taken into account when designing, building, and deploying a secure Mobile Application. Software solutions can be made more secure by using a multi-layered and dynamic security model (e.g. no single point of failure). By reinforcing the weak areas, we can ensure that the combination is strong. Therefore, one should take a broad, systemic view – rather than focussing purely on how to secure the software components in isolation. This is especially important for software solutions that rely on Consumer Device platforms that do not provide verifiable hardware security (Basic Platforms) for protection of the security assets. Figure 3.1 provides an example of a Mobile Application Software Life Cycle (SLC) model. It highlights the different phases that must be considered when designing a Mobile Application solution. This chapter provides best practices for the different stages in the Mobile Application SLC as well as other security relevant aspects in the payment ecosystem. Figure 3.1: Mobile Application SLC Model Application Design and Development App Removal App Download User Enrolment App Update Credential Management Card Removal / Blocking Payment Capable Production State Credential Provisioning Credential Issuance Reader © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 26 / 48 3.1 Application Design and Development Mobile Applications and their relying components (e.g. SDK and Libraries) must be designed and developed based on a software development life cycle methodology. This includes security best practices such as those outlined in the OWASP Software Security Assurance Process (OSSAP). Following such processes will reduce the possibility of requirement oversights, design flaws, implementation bugs, and deployment configuration mistakes. There are several other methodologies that could be referenced, but the intent is to ensure that security practices are consistently applied to the Mobile Application and other components of the payment solution. Moreover, one must take full account of evolving and anticipated industry standards and draw upon communities (e.g. OWASP, PCI SSC) that are focussed on the security of Mobile Applications. Since software security standards evolve rapidly and best practices change quickly, it is important to ensure that the latest set of best practices are followed and to use the most recent generation of secure technologies. Specific design and development security requirements include the following: • The Mobile Application must be designed and built following security best practices. • Developers must perform a threat and vulnerability assessment and identify early in the development cycle the security requirements for the Mobile Application and how sensitive payment assets and security functions must be protected. • Developers must ensure that the application is developed in controlled development environments that conform to industry best practices. • Developers must conduct design reviews of the security architecture with business and technical resources. • Developers must conduct code analysis and secure code reviews. • Developers must conduct functional, security, and penetration testing early and often within the integration, validation, and production stages of the product life cycle. • To ensure the security enforcing features do not impact the functional requirements of the Mobile Application, all security measures must be in place and operational during approvals testing. • Security features must be balanced with performance of the Mobile Application. That is, the security enforcing features should not adversely affect the performance of Mobile Application to the extent that the user experience is degraded. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 27 / 48 3.1.1 Secure Communication Channels No matter how securely data is stored while at rest, it can still be at risk whilst in transit, so it must be protected accordingly. All communications from the consumer’s device, or a mobile application on the consumer’s device, to a Credential Manager (or other cloud-based systems) must apply end-to-end protection to ensure that sensitive information is protected at the required security level and not being exposed to a lower level of security. This will also ensure that security assets are not available in an unprotected format in any of the systems that route communication between endpoints and thereby mitigates the risk of man-in-the-middle attacks on third parties through which sensitive information passes. This end-to-end protection of data in transit may require specific additional field level cryptography (for example, to protect PII data) in addition to the protection provided by industry recognized security protocols. 3.1.2 Platform Security More often than not, the security of the Mobile Application relies on the security functionality provided by the platform of the Consumer Device. Although it is not always possible to secure this platform, it is often possible to verify its integrity and status, or to authenticate the environment. Ideally, the Mobile Application and its relying service-side and back-end controls should be able to monitor the platform it is running on, detect any abnormalities (e.g. reporting) that may arise in a compromised device, and act accordingly. Rooting is the process by which users of Consumer Devices attain privileged control within the device platform (the process is also known as jail-breaking). Unauthorized users (e.g. hackers or remote attackers) will use these elevated privileges to gain further access to the device for different purposes. Note that when a consumer roots a device, they can do this for a legitimate purpose and do not necessarily intend to attack the Mobile Application. In fact, users will generally root a device for completely benign purposes (such as having more flexibility in customising the Operating System). That said, a rooted device does open the door to numerous attack vectors or vulnerabilities, and one should consider carefully whether to allow the Mobile Application to operate in these circumstances. This might require additional root detection controls and risk mitigation strategies. 3.1.3 Application and Device Attestation The Mobile Application should periodically check its own integrity and the status of the device. Depending on the solution model used, the integrity of the Mobile Application most likely relies on the underlying hardware and/or on server-side controls. Therefore, the security of the solution cannot rely solely on the security of the Mobile Application. It may also rely on the security status of the Consumer Device and on server-side components and controls. Server-side controls might be able to detect a software-based solution or device compromise either by transactional data analysis (e.g. monitoring and fraud detection) or by information explicitly provided by the device (e.g. device attestation). © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 28 / 48 Device attestation is a mechanism that allows a Consumer Device to present fresh evidence to the server-side about the integrity of its security model. However, such an attestation does not necessarily provide reliable information on whether the Consumer Device is rooted. In order to make a risk-based interpretation of the evidence, the underlying attestation mechanism should be trustworthy and the evidence be securely conveyed to the server-side. As a Consumer Device runs in a potentially hostile environment, it may not be clear how this security functionality can be preserved, how the mechanism will respond to new attacks, or be securely updated. There are three important phases to (1) application attestation and (2) device attestation depending on an attestation policy: 1. Self-ruling response: The Mobile Application detects an application / platform / device condition and limits or disables its own execution. 2. Mobile Application Reporting: The Mobile Application detects an application / platform / device condition and reports it to a server-side component for further advice and/or action. 3. Server-based response: The Mobile Application makes a decision based on a received server-side component response. Application attestation, device attestation, and monitoring are important aspects of a software-based multi-layered security design. Once a device attestation mechanism has been compromised, the server-side cannot rely on this information. Therefore, transactional data analysis, by monitoring and fraud detection, is another important security layer in the software-based multi-layered security design. 3.2 Mobile Application Download and Installation Once built and tested, the Mobile Application has to be distributed to a Consumer Device. It could be pre-installed on the device via OEMs and third parties. The application will most likely be distributed via a trusted application store or a trusted web site (e.g. OTA to device). One must consider the following: • Make the Mobile Application available through recognized sources (e.g. the Google Play App store or the Issuer’s web site). • Downloading and installation should only be possible on Consumer Devices that support the functionality necessary for the intended payment service and for the application to properly operate. • Perform application and device integrity checks prior to Mobile Application installation on the Consumer Device (e.g. via signature verification and device attestation). • Have a verifiable audit trail of the Mobile Application installation process. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 29 / 48 3.3 User Enrolment User enrolment enables the cardholder to request the registration of their Software Card. It is an important life cycle event, normally conducted remotely (e.g. OTA), at the time a consumer wishes to enrol a payment card to the Mobile Application. Some Identification and Verification (ID&V) considerations that need to be taken into account are: • There must be defined and established ID&V requirements to be used during the user enrolment process. • The user enrolment process must verify, through remote device attestation, whether the device is in a trusted state before releasing protected data to, or storing private information on, the Consumer Device. 3.4 Provisioning and Credential Issuance Following enrolment, provisioning and credential issuance is defined as the configuration of the Card Credentials within the Consumer Device to be ready for use, possibly including device risk parameters. The greatest risks are likely to relate to the cardholder registration and provisioning processes. One will need to ensure that credentials are installed in and tightly bound to the right device, and that the process is not vulnerable to reverse engineering. The following must be considered: • Once a user has successfully enrolled, the Card Credentials must be securely provided to the Mobile Application. • The Card Credentials provisioned must be determined by the configuration parameters supported by a given Payment System, the Mobile Application model used, and regional/Issuer needs. • Once user enrolment and Card Credential provisioning are completed, the Mobile Application should be ready to conduct payments immediately. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 30 / 48 3.5 Card Credential Replenishment Card Credential replenishment initiates replenishment requests and processes new sets of credentials and possibly device risk parameters. The day-to-day operation of Software-based mobile payments will revolve around the on-going management and periodic replenishment of credentials, which determine whether it is possible for payments to take place, and therefore perform a critical risk management function. As with traditional card-based payments, the risks relating to lost and stolen devices can generally be mitigated though a robust cardholder verification method (CVM); however, even in the event of a compromised CVM, the following can limit fraud. • The Mobile Application must initially connect to the cloud-based system to obtain the credentials necessary to enable software-based mobile payments. • The Mobile Application must allow the Credential Manager to refresh/update the credentials when subsequent connections to the cloud-based system occur. If the old device is being disposed of, then card replenishment must invalidate all data bound to the old device and repeat provisioning and credential issuance on the alternate device. 3.6 Monitoring and Reporting Information Once the Mobile Application has been designed and built, it is important to develop monitoring and reporting functionality. This will enable relevant data to be retrieved and reported to control servers at specific points in the operation of the Mobile Application. The intelligent use of such data has several benefits, including: • Early detection of malware on Consumer Devices: A control server can collect the type of information that, when used intelligently, will help to establish the nature and size of an attack on any given portfolio, thereby limiting the potential damage. • Improvements in fraud detection: Fraud detection systems can draw on a more comprehensive set of data and will therefore become more adept at identifying potentially fraudulent transactions. • Enhancing the user experience: This level of data can help back-end systems to make better-informed decisions on transaction authentication and authorisation, thereby reducing the need for repeated or intrusive consumer verification. If a compromise is detected, appropriate action will need to be taken. Depending on the severity of the compromise, this could include a range of measures – from suspension of the payment capability and contacting the cardholder through full deactivation of the Mobile Application and deletion of all Card Credentials. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 31 / 48 3.7 Mobile Application Security and Management From the outset, one should accept that the Mobile Application will be targeted by attackers – possibly through malware, reverse engineering, opportunism, or attempts to infiltrate relying websites or back-end systems. It is important to protect the Mobile Application against any unauthorised modification or updates and to ensure that it can verify its own integrity at least at runtime. As the Mobile Application is downloaded and installed on a potentially hostile device, it is highly likely that any unauthorized application modification or update is the result of either malware or a malicious user. The Mobile Application should not only be able to resist such attacks but should also be able to report them to the appropriate relying system or to act appropriately (stop execution). 3.7.1 Application and Platform Update Mechanism Mobile Application updates are used to add new functionality or correct bugs. Sometimes it may be necessary to deploy an application or platform update to fix known security issues. In this case, and especially when a critical security vulnerability has been detected, it is important to have the ability to force an update – either automatically or by requiring the user to download and install the latest version of the Mobile Application. Mobile Applications for managing software-based mobile payment products and the platforms on which the Mobile Application is installed will be frequently updated in the field after deployment. Therefore, it is important that: • the Mobile Application has a secure update mechanism • the platform has a secure update mechanism The update mechanism must incorporate good version control, roll-back detection, as well as protection of the credential data. The Mobile Application might depend on the underlying platform to securely implement this functionality. Once a Mobile Application has been installed or updated, it is unusual (although not unheard of) for consumers to attempt to conduct a user-initiated roll-back to an earlier version of the application. 3.8 Application Removal If a user does not want to use the Mobile Application any longer, the Card Credentials must be securely deleted before removal of the Mobile Application. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 32 / 48 4 Mobile Application Security Architecture This chapter provides an overview of the Mobile Application security architecture. It introduces the Mobile Application security model including a description of the assets to be protected by the Mobile Application. 4.1 Architecture of the Mobile Application Depending upon implementation, the functionality of the Mobile Application can be distributed over a number of components. These components may be contained within the Consumer Device, but some components may be external; for example, a mobile phone used with a wearable accessory such as a watch. In addition to provisioning and authorisation functions necessary to manage the risk inherent in Software Card payments, there are also server-side components that contribute to Mobile Application security functionality; for example, detection of compromise of a device either by information explicitly provided by the device (e.g. via device attestation) or by transactional data analysis (e.g. by monitoring and fraud detection). There must be a clear specification of the protection required for each of the assets within the device and any associated external components. The level of protection required will depend on the lifetime of those assets and their sensitivity. The lifetime or sensitivity must be reduced (for example, by enhancing back-end server functionality providing additional detection for compromised devices), or the assets must be moved to a more secure location such as within a TEE. Additionally, mobile application protection must be applied (for example, white-box crypto, obfuscation, and binary protection), to augment the risk protection provided by the platform and server-side components. Types of Mobile Application Components The assurance provided by the Mobile Application will vary according to the architecture of the Mobile Application and the way in which it uses its components. For example, Mobile Application asset processing and storage may be wholly performed by an application executing in the REE. Alternatively, the Mobile Application may be distributed over components that use functionality provided by a TEE and REE and further supported by hardware components such as a TPM or SE. Specification of the Mobile Application architecture is important for evaluating the security afforded to assets by the implementation as they flow between components. A component may have some level of pre-existing assurance. Even so, it may have some limitations on the assurance it can provide. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 33 / 48 4.1.1 Interface Endpoints Assets will flow between components of the Mobile Application using available component interfaces. These interfaces may be internal or external to the Consumer Device and might have security support. For example, a Mobile Application payment processing component may be installed on a wearable accessory and provisioned from a Mobile Application component on the Consumer Device using Bluetooth Low Energy (BLE). This BLE connection must be securely configured. Mobile Application assets are transmitted over an interface between endpoints. An endpoint may be external to the Mobile Application; for example, the NFC Controller or the Credential Manager. An endpoint may also be integrated in the Mobile Application and could be a component that provides the required security services for the transmitted assets; for example, a TEE. The transmission of assets over interfaces between endpoints must not conflict with the required security services of the endpoints. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 34 / 48 4.2 Mobile Application Security Model 4.2.1 Security Objective The objective of the Mobile Application security model is to ensure that the Mobile Application provides required security functions to protect the Mobile Application assets identified below, by providing an attack surface that is uneconomic for an attacker to penetrate. However, it is recognized that an attacker may have other objectives (e.g. self-promotion, nation-state attack, or to discredit the product) to spend a lot more resources to break the system than is warranted by the direct financial fraud payback. 4.2.2 Attacker Goal The presumed goal of an attacker is to compromise Mobile Application assets on the Consumer Device to perform unauthorized payments, for financial gain, publicity, or other reasons (e.g. denial-of-service). Attacker capabilities, classes, and models are out of scope of this document. 4.2.3 Payment Threats The primary payment threats are the following: • The successful deployment of an attack (especially one that can infect and spread to multiple Consumer Devices) which proceeds undetected (for a period of time) and delivers active assets from compromised devices to unauthorized devices. • An attack which enables an unauthorized party to perform fraudulent payments via remote access to legitimate devices that have been compromised. • Mobile Application cloning where a single compromised Consumer Device duplicates (clones) its assets to unauthorized devices or where data is selectively duplicated so that multiple (partial) clones may all transact without detection. • A denial-of-service attack that would prevent a consumer from making a payment. • Unauthorized payments made with ‘lost and stolen’ devices. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 35 / 48 4.2.4 Scenarios Two scenarios are considered where an attacker tries to compromise Mobile Application assets, or identify and exploit vulnerabilities: • The attacker gains remote access to the Consumer Device through manipulation of one or more available logical interfaces. In this scenario, the security objective is to reduce the risk of logical attacks on the Mobile Application that achieve the attacker’s goal. • The attacker gains local access to the device through manipulation or eavesdropping of available physical or logical interfaces, or by physical tampering. Physical attacks are typically not scalable, but if it is possible to use the Mobile Application by straightforward physical means following the attack then any ‘lost and stolen’ prevention mechanism – such as device lock and/or consumer authentication requirements for payment – are no longer effective. 4.2.5 Threat Model An attacker might try to compromise the Mobile Application assets in the different phases of the Mobile Application’s life cycle with different windows of opportunity; for example, during enrolment, provisioning, card credential replenishment, payment, and Mobile Application update. For each stage of the life cycle, the threat model considers two phases: identification and exploitation. In the identification phase, the attacker tries to develop a successful attack. The exploitation phase corresponds to the effort required to repeat the identified attack in the field on a limited or large scale. In the identification phase, physical and logical analysis can be considered to identify potential attack paths. However, in the end the most important consideration is whether the attack can be easily exploited, and especially whether it is scalable. © 2016-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Mobile Payment Software-based Mobile Payment Security Requirements v1.5 Page 36 / 48 4.2.6 Attacks To compromise the inherent security of the Mobile Application, an attacker is likely to attempt one of the attacks listed in Table 4.1. Table 4.1: Attacks on the Mobile Application Attack Description 1 Bypass mobile Gain privileged platform (e.g. OS) access to Mobile security controls Application processing and assets. Attack Path A malware infection uses a published exploit or zero-day attack targeted at a specific platform vulnerability which can be used to escalate privilege. 2 Reverse engineer Recover sensitive Mobile Application source code and source code extract sensitive Mobile Application assets. Native code disassembly Java code de-compilation Code structure analysis Asset extraction Roll-back to previous version of Mobile Application 3 Modify Mobile Application code Alter behaviour of Mobile Application. Code is modified or malicious code injected, for example to present false information to the user. 4 Exploit interfaces between components Abuse the interfaces between the components that make up the payment application. Masquerade as a legitimate payment application in the REE interacting with a trusted application in the TEE. Compromise the results of consumer authentication, thereby fooling the Mobile Application into believing that CDCVM has been performed. Compromise payment application functionality to relay sufficient information to a remote endpoint, enabling payment to occur with that remote endpoint. 5 Extract assets in r