EMV credential generation versus device-side execution

1. What EMV signs

EMV’s credential authentication is built around the Authorization Request Cryptogram (ARQC), specified in EMV Book 2 (Security and Key Management) [1] and referenced through the application flow in Book 3 [2]. On contact and contactless card-present transactions the ARQC is generated by the chip. On tokenised mobile flows the cryptogram is generated using a network-issued Limited-Use Key (LUK) — a scheme/tokenisation construct (Visa VTS, Mastercard MDES) issued to the device by the Token Service Provider. Where the LUK is held depends on the device and the wallet: Apple Pay binds it to the per-device Secure Element; on Android, the LUK is held under Host Card Emulation (HCE) and may be backed by StrongBox / TEE-backed Keystore on devices that expose a hardware-backed signer, or by software-backed Keystore on devices that do not. The cryptogram is computed over the inputs the card-issuer profile specifies via the CDOL, including the amount, currency, transaction date, unpredictable number, application transaction counter, and additional fields the issuer’s profile selects.

The cryptogram is verified by the issuer using a key shared with the card or the tokenisation service. When the issuer accepts the ARQC, two assertions are settled at the rail layer: the credential is genuine, and the transaction inputs supplied through the protocol have not been altered between the chip and the issuer. This is what EMV is for. It does what it specifies extremely well.

2. What sits before the signed boundary

EMV’s cryptographic authentication starts at the moment the chip or secure element receives its inputs and produces a cryptogram. Everything before that moment is a flow that produced the inputs: on a contact or contactless card-present transaction, the inputs come from a terminal whose own integrity is attested by a separate regime (PCI PTS, scheme terminal certification). On a mobile or remote card-not-present transaction, the inputs come from the device-side application:

• The PAN is supplied either by the card hardware (NFC) or by application logic — token from the wallet, card-on-file lookup, user-typed value.
• The amount is supplied by the application after a UI flow in which the user confirmed a value rendered on screen.
• The consent moment — biometric, PIN, or implicit by tap — is registered by the application, the OS, or the embedded SDK.

Each of these supplies an input to the cryptogram. Each is part of the transaction. None is part of what the cryptogram itself authenticates.

3. EMV 3DS — adjacent, not the same boundary

EMV 3DS (3-D Secure) is an authentication protocol adjacent to — not an extension of — the EMV authorisation rail. Version 2.x introduces structured collection of device-environment data — a defined set of fields the 3DS SDK or browser passes to the issuer’s Access Control Server [3]. The collected data includes browser characteristics, SDK-collected device attributes, network environment, and transaction context, transported with message-level integrity protection between the SDK, the Directory Server, and the ACS.

Two structural points apply. First, the 3DS device data is descriptive — it is a snapshot of attributes, not a signed trajectory of execution events. Second, the 3DS data is collected once at authentication initiation; the runtime sequence between that initiation and the cryptogram generation is not what 3DS covers. EMV 3DS and execution evidence are adjacent: 3DS gives the issuer a description of the device at one moment; execution evidence gives the operator a signed account of what the runtime did across the interval. The two compose. Neither replaces the other. This relationship is documented at /architecture/runtime-coherence.

4. Where the device-side flow is observable

The device-side flow that produced the cryptogram inputs is observable, but not by EMV. It is observable by mechanisms that operate inside the runtime: the PAN-entry surface, the amount confirmation rendering, the consent acquisition, the payload assembly. Each is a discrete framework or system-call event with a clear boundary that can be signed at the moment it happens. Execution Evidence Infrastructure (EEI) — the device-identity infrastructure layer for banking and payments — observes these events through the Trusted Runtime Primitive and signs them. The signed events compose with the issuer-verified ARQC: the credential is authenticated at the rail; the device-side execution that produced the inputs is authenticated at the runtime. Operators that consume both have a closed loop between credential identity and the runtime that supplied the credential’s inputs.

5. Cross-references

• Sibling articles in this theme: the-play-integrity-gap, the-fido2-submission-gap, the-sca-settlement-gap
• Architecture: /architecture/runtime-coherence, /architecture/threat-model
• Glossary: /glossary — Trusted Runtime Primitive, Evidence Token

6. External references

[1] EMVCo. EMV Integrated Circuit Card Specifications for Payment Systems, Book 2 — Security and Key Management, v4.4. www.emvco.com/specifications/. Cited 2025-10-05.

[2] EMVCo. EMV Integrated Circuit Card Specifications for Payment Systems, Book 3 — Application Specification, v4.4. www.emvco.com/specifications/. Cited 2025-10-05.

[3] EMVCo. EMV 3-D Secure Protocol and Core Functions Specification, v2.3.1. www.emvco.com/specifications/. Cited 2025-10-05.