Skip to main content
Category: Transaction Processing

Near Field Communication

Also known as: NFC, near-field communication, contactless communication
Simply put

Near Field Communication (NFC) is a short-range wireless technology that lets two devices, such as a phone and a payment terminal, communicate when held very close together, typically within a few centimeters. It is commonly used for contactless payments where a customer taps or holds a card or device near a reader. NFC is based on radio-frequency identification (RFID) technology and requires close proximity, which limits communication to devices that are near one another.

Formal definition

NFC is a set of contactless, close-proximity radio communication protocols derived from RFID technology, operating at a base frequency of 13.56 MHz with a typical effective range on the order of a few centimeters (commonly cited around 4 cm). It enables data exchange between two electronic devices, or between a device and a passive NFC tag, over short distances. In payment acceptance, NFC provides the physical and link-layer transport for contactless card-present transactions between a consumer device or card and a reader; the underlying transaction security, cryptographic authentication, and data handling are governed by separate specifications (for example EMV contactless and applicable PCI standards) rather than by NFC itself. NFC as a transport does not by itself define how cardholder data or sensitive authentication data are protected, so applicable data-protection and storage controls must be evaluated against the relevant standards and their current published requirements.

Why it matters

NFC is the transport layer behind the tap-to-pay experience that has become common at physical points of sale, whether a customer presents a contactless card or a phone or wearable. Because it functions only over very short distances, typically on the order of a few centimeters, it requires deliberate proximity between the consumer device and the reader. This close-range constraint is a property of the radio technology itself, not a comprehensive security control, and it should not be confused with the cryptographic and data-protection measures that actually secure a payment.

For security and compliance teams, the key point is that NFC only provides the physical and link-layer means for two devices to communicate. The security of a contactless card-present transaction depends on separate specifications layered on top of NFC, such as EMV contactless for cryptographic authentication and the applicable PCI standards for how cardholder data and sensitive authentication data are handled. Treating NFC as inherently secure because taps happen at close range can lead teams to overlook where the real protections must be evaluated and validated.

Because NFC as a transport does not by itself define how cardholder data or sensitive authentication data are protected, applicable data-protection and storage controls must be assessed against the relevant standards and their current published requirements rather than assumed from the use of contactless acceptance. This matters when scoping an acceptance environment, since the presence of NFC alone tells you little about whether a given implementation reduces or affects PCI DSS scope.

Who it's relevant to

Merchants and merchant risk teams
Merchants accepting contactless payments rely on NFC as the tap-to-pay transport at the point of sale. Their risk teams should recognize that supporting NFC acceptance does not by itself establish how cardholder data is protected, and that the applicable data-protection controls must be evaluated against the relevant standards and their current published requirements.
Payment processors and acquirers
Processors and acquirers handling contactless card-present transactions work with NFC as the link-layer transport carrying data between a consumer device or card and a reader. They should treat the transaction security and cryptographic authentication as governed by separate specifications such as EMV contactless, not by NFC itself.
Compliance officers and QSAs
Those scoping and validating an environment should not infer PCI DSS scope or data-protection status from the use of NFC alone. Because NFC as a transport does not define how cardholder data or sensitive authentication data are protected, storage and protection controls must be assessed against the applicable PCI standards and their current published requirements.
Security engineers and terminal integrators
Engineers building or integrating readers and consumer-device acceptance need to distinguish the NFC physical and link layer from the specifications layered above it. Cryptographic authentication and data handling for contactless payments are defined by EMV contactless and applicable PCI standards rather than by NFC, so those layers require separate design and validation.

Inside NFC

NFC radio interface
A short-range wireless communication technology operating at 13.56 MHz that enables data exchange between two devices, such as a contactless card or mobile wallet and a point-of-sale reader, when brought into close proximity (typically a few centimeters).
Contactless payment application
The payment application residing on an NFC-enabled card or device that carries out the transaction. In card payment contexts these commonly follow EMV contactless specifications, which govern chip-based authentication for the tap transaction.
Tokenized or device-specific credential
Many mobile wallet implementations present a token or device-specific account number over NFC rather than the actual PAN. Whether tokenization reduces PCI DSS scope depends on the specific implementation and validation, not on the presence of NFC alone.
Contactless reader (acceptance point)
The merchant-side hardware that receives the NFC transmission and passes transaction data into the payment processing environment. The reader and its surrounding systems may fall within PCI DSS scope depending on how cardholder data and sensitive authentication data are handled.
Cryptographic transaction data
EMV contactless transactions generate dynamic cryptographic values for the tap. As with any transaction, sensitive authentication data must not be stored after authorization, even when encrypted, while defined cardholder data elements may be stored only under applicable controls.

Common questions

Answers to the questions practitioners most commonly ask about NFC.

Does using NFC for a contactless payment make the transaction inherently secure or remove it from PCI DSS scope?
No. NFC is a short-range wireless communication method, not a security control in itself. Whether a contactless transaction is secure depends on the cryptographic protections applied on top of NFC, such as EMV chip authentication used in contactless mode, and any tokenization performed by the mobile wallet or scheme. NFC as a transport does not by itself remove a merchant environment from PCI DSS scope; scope reduction depends on what data the merchant systems receive, store, process, or transmit and on how that is validated, not on the presence of NFC.
Is an NFC contactless payment the same thing as a mobile wallet payment, and does it always tokenize the card number?
Not necessarily. NFC is the communication technology; a mobile wallet is one application that may use NFC to present credentials. A contactless payment can originate from a physical dual-interface card as well as from a mobile device. Tokenization is a separate function that may or may not be applied depending on the wallet, the scheme, and the implementation. Where a wallet substitutes a network token or device account reference for the PAN, that is a distinct process from NFC transport and its effect on data handling depends on the specific implementation and validation, not on the NFC label alone.
When an NFC contactless transaction runs in EMV contactless mode, what authentication actually takes place at the point of interaction?
In EMV contactless mode the chip credential participates in cryptographic authentication analogous to contact EMV, which is intended to help confirm the card credential is genuine and to help protect certain transaction data. This addresses card authentication at the point of interaction and is distinct from cardholder verification, from 3-D Secure used in card-not-present flows, and from multi-factor authentication of a user. Readers should confirm the exact behavior against the applicable EMV and card brand specifications, which vary and change.
If our POI accepts NFC payments, what data elements should we be careful not to retain?
The same data-handling rules apply as for other acceptance channels. Sensitive authentication data, such as full track-equivalent data, card verification values, and PINs or PIN blocks, must not be retained after authorization even if encrypted. Some cardholder data, such as PAN, may be stored only under defined controls and with appropriate protection such as truncation, masking, tokenization, or strong cryptography, according to the current PCI DSS. Confirm applicable requirements against the published standard for your version, as numbering and wording differ across versions.
How does NFC acceptance affect the PCI DSS scope of our point-of-interaction and connected systems?
Scope depends on how the NFC-enabled POI and any connected systems handle account data. If the device captures, processes, or transmits cardholder data or sensitive authentication data, those functions and connected systems are typically in scope. Where solutions such as validated point-to-point encryption or scheme tokenization are used, they may reduce the number of in-scope components, but that reduction depends on correct implementation and validation rather than on the acceptance method. Assess scope based on actual data flows and confirm against the current standard.
Where do standards other than PCI DSS come into play for NFC contactless acceptance?
Several PCI standards may be relevant depending on the design. If PINs are entered or processed, PCI PIN and applicable PIN security requirements govern that handling. If a validated point-to-point encryption solution is deployed at the POI, PCI P2PE governs that solution. Software running on the device may fall under the PCI Software Security Framework. EMV contactless behavior and network token services are governed by EMV and card brand specifications rather than PCI DSS. Identify the specific standard that applies to each control rather than assuming PCI DSS covers all of them.

Common misconceptions

NFC is a security control that prevents payment fraud.
NFC is a proximity communication technology, not a fraud control. It defines how data travels over a short-range radio link. Fraud risk is addressed by other mechanisms such as EMV chip authentication, tokenization, and issuer-side controls, and no single element eliminates fraud. NFC alone helps enable but does not guarantee secure transactions.
An NFC contactless transaction always transmits the actual PAN, so any NFC acceptance point is inherently in full PCI DSS scope.
Some NFC implementations, particularly mobile wallets, present tokens or device-specific credentials rather than the PAN. The effect on PCI DSS scope depends on the specific implementation and how it is validated, not on the use of NFC as a label.
Because NFC transactions involve encryption and cryptograms, related sensitive authentication data can safely be retained for analysis.
Sensitive authentication data must not be stored after authorization even when encrypted. The presence of cryptographic values in an EMV contactless transaction does not create an exception to this requirement; confirm handling rules against the current published PCI DSS.

Best practices

Treat NFC as a communication channel and layer it with appropriate authentication mechanisms, such as EMV contactless and, where applicable, cardholder verification, rather than relying on proximity as a security measure.
Confirm how your NFC acceptance implementation handles PAN, tokens, and sensitive authentication data, and validate the resulting PCI DSS scope against the current published standard instead of assuming NFC reduces scope.
Ensure sensitive authentication data captured during a contactless transaction is not stored after authorization, even in encrypted form, and verify data retention controls in the acceptance environment.
Where tokenization is used with NFC-based wallets, validate the tokenization implementation and its scope-reduction claims rather than accepting the label, and document the boundaries of the cardholder data environment.
Keep contactless readers and their supporting software maintained and patched, and confirm whether they fall under PCI DSS and any separately governing standards such as PCI PIN or PCI P2PE, depending on their function.
Verify liability and dispute handling for contactless transactions against the applicable card brand and network rules, recognizing that these rules vary by region and change over time.