Does NFC Forum certification replace RED or FCC radio certification?

No. NFC Forum certification is a private trademark licensing programme run by an industry consortium, distinct from regulatory radio obligations. An NFC product must obtain both NFC Forum certification (to use the N-Mark logo and claim compliance with the specifications) and RED article 3.2 compliance in the European Union, or 47 CFR Part 15.225 in the United States, for inductive emission at 13.56 MHz.

Does NFC Forum certification cover contactless payment use?

No. NFC Forum certification covers the near field communication layer as defined by the Forum specifications (Digital Protocol, Activity, Tag operations, NDEF). Contactless payment use is governed by a separate programme operated by EMVCo, which builds on the NFC radio but adds its own requirements (EMV Contactless Specifications, EMVCo Type Approval). A payment terminal goes through both programmes.

What is the difference between an NFC Forum tag type and a MIFARE card?

Tag types T1 to T5 are defined by the NFC Forum and guarantee interoperability with any certified reader. MIFARE is a family of NXP proprietary products. MIFARE Ultralight and DESFire EV2 or EV3 can be operated as tag type 2 and tag type 4 respectively, but MIFARE Classic is not an NFC Forum tag type and is not guaranteed compatible with all certified readers.

What is NDEF and why does it matter?

NDEF (NFC Data Exchange Format) is the common binary format for NFC message exchange. An NDEF message contains one or more records (URI, text, MIME, smart poster, signature). Without NDEF, a certified reader and tag could communicate at the lower layers but could not interpret application data. NFC Forum certification verifies NDEF compliance.

Is re-certification required when integrating an already certified NFC controller?

Generally no, for the controller part, provided the integration meets the conditions of the parent certificate (same reference antenna, same firmware, same stack configuration). The finished product still has the obligation to declare itself to the NFC Forum and to verify application-level interoperability before using the N-Mark. Any antenna or NFC firmware change triggers a new evaluation.

Does NFC Forum certification cover Secure Element security?

No. NFC Forum certification covers NFC interoperability, not the security of the Secure Element (SE) or of the Trusted Execution Environment (TEE) used in Host Card Emulation. SE security is governed by Common Criteria (typically EAL4+ or EAL5+ for banking SEs). For the overall security of a payment terminal, EMVCo and the schemes add their own requirements.

Which lab certifies an NFC Forum product?

The NFC Forum publishes a list of Authorized Test Labs (ATL). The applicant submits a physical sample and the technical dossier to the lab of its choice. Tests cover the Digital Protocol, Activity and RF Analog layers and, where applicable, NDEF and tag operations. The test report is filed with the Forum, which issues the certificate and licenses use of the N-Mark logo.

NFC Forum certification and the N-Mark trademark

Author Hugues Orgitello Last updated 27 May 2026 ~13 min read

Guide . NFC Forum certification

NFC Forum certification occupies a specific place in the near field communication ecosystem. It is neither radio certification (RED, FCC), which governs inductive emission at 13.56 MHz, nor payment certification (EMVCo), which governs contactless transaction interoperability. The NFC Forum is a private industry consortium that publishes a corpus of specifications (Digital Protocol, Activity, NDEF, Tag operations) and licenses the N-Mark trademark to products that have passed the tests of an Authorized Test Lab. This page sets out the programme structure, the NFC modes, tag types T1 to T5, the relationship with ISO/IEC 14443 and 18092, and the pitfalls associated with incomplete certification.

Why a consortium certification distinct from radio

The NFC Forum, founded in 2004 by Sony, Philips (now NXP) and Nokia, now gathers hundreds of members: chip vendors, integrators, credential issuers, transport authorities, payment solution providers. The Forum owns the N-Mark trademark and licenses its use to products whose compliance has been verified. As with the Bluetooth SIG or the Wi-Fi Alliance, certification is contractual, not regulatory: its purpose is not placing on the market within the meaning of EU directives or FCC rules, but the right to use a brand and the assurance of interoperability.

Two objectives coexist within the programme:

N-Mark trademark protection. Ensuring that any device displaying the logo respects the NFC Forum specifications and does not degrade the ecosystem reputation.
Interoperability assurance. Verifying that a mobile phone, a reader, a card or a tag actually communicates with any other certified device, regardless of manufacturer.

The radio itself falls under a different regime. In the European Union, inductive emission at 13.56 MHz falls under article 3.2 of the RED directive ( 2014/53/EU ) and the harmonised standard EN 300 330 covering Short Range Devices in the 9 kHz - 25 MHz band. In the United States, the radio falls under 47 CFR Part 15.225 ( FCC Part 15.225 ), which governs intentional emission in the 13.553 - 13.567 MHz band. These two regimes check RF compliance (power, harmonics, out-of-band emissions). They say nothing about the upper layers and never authorise use of the N-Mark logo.

Position in the NFC stack

To place the Forum's scope properly, it helps to recall the stack.

Layer	Reference	Programme
Inductive radio 13.56 MHz	EN 300 330, FCC Part 15.225	RED article 3.2, FCC Part 15
RF Analog and low-level protocol	ISO/IEC 14443, ISO/IEC 18092	NFC Forum (compliance tests)
Activity (session establishment)	NFC Forum Activity Specification	NFC Forum
Digital Protocol (commands)	NFC Forum Digital Protocol	NFC Forum
NDEF (data format)	NFC Forum NDEF	NFC Forum
Tag operations T1-T5	NFC Forum Tag operations	NFC Forum
Payment application	EMV Contactless Specifications	EMVCo
SE security	Common Criteria (EAL4+ and above)	SOG-IS, CCRA

This stratification is central: a product never undergoes a single certification, but a combination depending on its end use.

NFC Forum membership

The Forum offers four membership levels, arranged as a pyramid of engagement and rights.

The highest governance tier. Sponsors sit on the Board of Directors, drive the Forum's strategy and participate in every working group. Historically reserved to major actors (silicon vendors, mobile OEMs, payment schemes).

Principal

Intermediate tier with access to most working groups, voting rights on specifications in progress, preferential certification rates.

Associate

Read access to specifications, limited participation in selected working groups. A frequent tier for NFC module integrators and downstream product manufacturers.

Implementer

The entry tier, designed for finished-product manufacturers that simply want to certify a device without participating in standards work. Grants the right to submit products to Authorized Test Labs and to use the N-Mark after certification.

Tier	Specifications access	Vote	Working groups	Product certification
Sponsor	Full, drafts	Board	All	Yes
Principal	Full, drafts	Committee votes	Most	Yes, preferential rates
Associate	Read	Limited	Selected	Yes
Implementer	Read, finalised only	No	No	Yes

For a manufacturer integrating an already certified NFC controller in a finished product, Implementer status is generally sufficient. Moving to Associate or Principal is justified for stack designers, middleware vendors and manufacturers wishing to influence the evolution of the specifications.

NFC modes

The NFC Forum defines three operating modes. A product can implement one, two or all three, and certification targets specifically the declared modes.

Reader/Writer

The device acts as an active reader (generates the RF field) and interacts with passive tags or contactless cards. Typical case: a mobile phone reading an NFC tag on a poster; an access terminal reading a badge; an industrial card reader.

In this mode, the product must support the declared T1 to T5 tag types, that is, know how to activate, read, write and close a session with each covered type.

Card Emulation

The device emulates a contactless card, that is, responds to commands from an external reader as if it were a tag or an ISO/IEC 14443 Type A or B card. Two variants exist:

Host Card Emulation (HCE). Emulation is implemented in software on the application processor, with no dedicated Secure Element. Widely adopted for mobile wallets (Google Pay, some Apple Pay variants although Apple still relies on a hardware SE), software access badges and non-banking transit use.
Secure Element (SE). Emulation is implemented in a dedicated secure component (soldered embedded SE, SIM UICC, secure microSD). The SE holds the sensitive cryptographic keys and exposes an ISO 7816 interface to the NFC controller. Required by most payment schemes and by some transit schemes.

Peer-to-Peer (P2P, deprecated)

A bidirectional exchange mode between two active NFC devices, based on the LLCP protocol. Historically used for file sharing (Android Beam), it is now deprecated by the NFC Forum: new specifications no longer emphasise it, and the main mobile platforms (iOS, modern Android) have removed it in favour of Reader/Writer combined with application protocols (Bluetooth bonding, Wi-Fi handover). A product may still declare it, but its commercial weight is low.

Mode	RF role	Typical use case	Status
Reader/Writer	Generates the field	Tag reader, access terminal	Active and widely adopted
Card Emulation (HCE)	Emulates a card	Mobile wallet, software badge	Active and widely adopted
Card Emulation (SE)	Emulates a card with SE	Bank payment, transit	Active and widely adopted
Peer-to-Peer	Active-active bidirectional	File sharing (historic)	Deprecated

Tag types T1 to T5

Tag types are a central NFC Forum concept. They are five families of passive tags or cards, each tied to an underlying ISO/IEC standard and to a capability range. Any certified reader must know how to talk to the types it declares to support.

Tag type	Underlying standard	Typical memory	Re-write	Product examples
T1	ISO/IEC 14443 Type A (variant)	Very small	Read/write, sometimes lockable	Innovision Topaz (historic)
T2	ISO/IEC 14443 Type A	Small to medium	Read/write, lockable	NXP MIFARE Ultralight, NTAG21x
T3	JIS X 6319-4 (FeliCa)	Medium	Read/write	Sony FeliCa
T4	ISO/IEC 14443 Type A or B + ISO 7816-4 APDU	Medium to large	Read/write	NXP MIFARE DESFire EV2 / EV3, J3R cards
T5	ISO/IEC 15693	Variable	Read/write	NXP ICODE, ST25TV

Key points:

MIFARE Classic is not an NFC Forum tag type. It is a proprietary NXP protocol based on ISO/IEC 14443 Type A but with the CRYPTO-1 cipher and a proprietary command set. Many NFC readers support it, but that support sits outside the NFC Forum certification and is not guaranteed.
MIFARE Ultralight and DESFire are typically operated as T2 and T4 respectively. A T4-certified reader knows how to dialogue with a DESFire card at the APDU level.
T5 (ISO/IEC 15693) is specific: it is a vicinity protocol (up to roughly one metre), distinct from the proximity protocols used for T1-T4. It has its own Tag operation specification within the Forum.

A reader product typically declares the subset of tag types it supports. Certification verifies correct behaviour (activation, polling, read, write, session close) for each declared type. Declaring T1 to T5 means going through tests for all five.

NDEF and tag operations

On top of the tag types, the NDEF (NFC Data Exchange Format) defines a common binary format for application data exchange.

NDEF message structure

An NDEF message is composed of one or more records. Each record carries an identified type (URI, text, MIME, signature, smart poster, external) and a payload. The NDEF specification imposes:

Header encoding (header byte, type length, payload length).
Record chaining (first, middle, last).
Reader-side validation rules (rejection of malformed messages).

The Record Type Definitions (RTD) published by the Forum describe the standardised formats: RTD-URI, RTD-Text, RTD-SmartPoster, RTD-Signature. A certified reader can at minimum interpret the mandatory RTDs.

Tag operations

To each tag type corresponds a Tag operation specification that describes the command sequence to write and read an NDEF message: activation, selection, NDEF TLV allocation, write, optional lock, session close. The certification test plan follows that specification for each declared type.

Certification effort therefore concentrates on three technical pillars:

The transport specifications (Digital Protocol, Activity, RF Analog) that drive the RF layer and the low-level session.
The tag operations for each declared type (T1 to T5).
The NDEF format and the applicable RTDs.

The certification process

The sequence of an NFC Forum certification, from lab selection to public listing.

Join the NFC Forum. Subscribe to at least Implementer status. Access the full set of finalised specifications and the certification portal.
Declare the scope. List the implemented modes (Reader/Writer, Card Emulation HCE, Card Emulation SE), the covered tag types (subset of T1-T5), the NDEF profiles, and the version of each Forum specification claimed.
Pick an Authorized Test Lab. The Forum publishes a list of accredited ATLs. The applicant submits the sample and technical dossier to the chosen lab.
Physical testing. The lab runs the applicable test plans: RF Analog, Digital Protocol, Activity, Tag operation per declared type, NDEF. Tests use reference tags or readers provided by the Forum.
Test report. The lab produces a detailed report, traceable to the specification versions used.
Submission to the Forum. The report and conformance declaration are filed with the Forum, with the certification fees. The Forum reviews the dossier and issues the certificate.
N-Mark application. The applicant can then apply the N-Mark logo on the product, its packaging and its documentation, in accordance with the brand book. Use is conditioned on continued compliance.
Listing in the public database. The product appears in the Forum's public certification database, consultable by buyers and integrators.

This sequence is independent of radio certification ( EN 300 330, FCC Part 15.225 ), which must be run in parallel.

Reuse via a certified controller

The programme economy rests largely on reuse. Major silicon vendors (NXP, ST Microelectronics, Infineon, Sony) publish already certified NFC controllers for Reader/Writer and Card Emulation modes, with a reference antenna and a verified firmware stack.

An integrator that picks up these components without modification can benefit from inherited certification under conditions:

Keep the certified NFC component without NFC firmware modification.
Respect the reference antenna or have the antenna revalidated by the lab.
Keep the certified NFC stack.
Declare the finished product to the Forum and provide proof of inheritance from the parent certificate.

Any antenna modification (gain, geometry, material), NFC firmware change or stack modification invalidates the inherited certification. The product must then be resubmitted for the affected layers. This is the main hidden cost in NFC projects: changing the antenna for mechanical reasons (size, position) often forces a re-certification of the RF Analog coupling.

Interaction with EMVCo

For contactless payment use, NFC Forum certification alone is not enough. The Visa, Mastercard, American Express, Discover and JCB schemes have entrusted EMVCo (a joint venture of the issuers) with the specification and certification of contactless transactions. The main reference is the EMV Contactless Specifications for Payment Systems (books A, B, C-1 to C-7), supplemented by EMVCo Type Approval for terminals and cards.

Criterion	NFC Forum	EMVCo
Nature	Multi-sector technical consortium	Payment issuers consortium
Subject	Generic NFC interoperability	Contactless payment interoperability
Key specifications	Digital Protocol, Activity, NDEF, Tag operations	EMV Contactless Books A-C, kernels C-1 to C-7
Brand	N-Mark	Scheme logos (Visa, Mastercard, etc.) + EMVCo logo
Perimeter	Any commercial NFC product	Payment terminals, cards and wallets
Layer	Transport and NDEF	Payment application
Coexistence	Required for a payment terminal	Required for a payment terminal

A contactless payment terminal in practice goes through:

National radio certification (RED / FCC).
NFC Forum certification (transport layer and tag types).
EMVCo Type Approval Level 1 (RF and low-level protocol for payment needs).
EMVCo Type Approval Level 2 (payment kernel).
The certifications of each accepted scheme (Visa, Mastercard, etc.).
PCI PTS certification for physical and logical security of the payment unit.

NFC Forum and EMVCo cooperate through recognition agreements but never substitute for one another.

Interaction with ISO/IEC 14443 and 18092

The ISO/IEC standards published independently of the Forum form the technical foundation:

ISO/IEC 14443. Four parts covering the physical layer (Part 1), modulation and initialisation protocol (Parts 2 and 3 for Type A and B), and transmission protocol (Part 4). The basis of tag types T1, T2 and T4.
ISO/IEC 15693. Vicinity standard (up to roughly one metre) underlying tag type T5. Used historically in object tracking and libraries.
ISO/IEC 18092. NFCIP-1, defining peer-to-peer mode and active-active interaction at 106, 212 and 424 kbit/s.
ISO/IEC 21481. NFCIP-2, specifying the automatic selection mechanism between 14443, 15693 and 18092 modes.

The NFC Forum profiles these standards: it selects options, adds constraints (timings, modulation parameters), and publishes its own test specifications. A product certified to 14443 by a different programme is not necessarily NFC Forum certified, and vice versa. The test grid is finer on the NFC Forum side, notably for the Activity layer and NDEF, which do not exist in 14443.

Security and Host Card Emulation

Host Card Emulation (HCE) introduces a particular security dimension. In HCE, the sensitive application keys (payment token, access credential) sit in the application processor's memory, without the shield of a hardware Secure Element. NFC Forum certification does not cover the security of those keys: its scope is interoperability, not confidentiality.

To ensure security, HCE architectures typically rely on:

Tokenisation of sensitive keys, with server-side rotation by the issuer.
TEE (Trusted Execution Environment) on ARM TrustZone or equivalent, to isolate cryptographic operations from the main operating system.
Visa Token Service, Mastercard Digital Enablement Service schemes that transform the PAN into a limited-use token.

When a hardware Secure Element is used (eSE, SIM UICC), its certification typically falls under Common Criteria with a banking protection profile (often EAL4+ or EAL5+ depending on the scheme). This level is mandatory for most payment schemes and usefully complements NFC Forum certification.

Common pitfalls

Confusing NFC Forum and EMVCo certification

The most widespread mistake in payment projects. A team that obtains the N-Mark may believe it has covered everything and discover late that Visa and Mastercard require EMVCo Type Approval Level 1 and Level 2, with their own lab, their own marks and an independent schedule. Budget for it from the commercial scoping phase.

Mistaking MIFARE Classic for an NFC Forum tag type

Many legacy products (urban transit, access control, ticketing) use MIFARE Classic. None of these products is NFC Forum compliant under tag types T1-T5. A certified reader may technically talk to MIFARE Classic, but that capability is not guaranteed by the certificate. Migrating to DESFire EV2 or EV3 (tag type 4) or to Ultralight (tag type 2) restores NFC Forum compliance.

Changing the antenna without re-certifying

RF Analog testing is sensitive to antenna geometry, substrate material, nearby metal elements and enclosure. Changing the antenna for mechanical reasons late in design without going back through RF Analog at the lab is a frequent cause of late non-conformity.

Forgetting the radio

The N-Mark licenses brand use. It does not authorise placing on the market. Without EN 300 330 in the EU or Part 15.225 in the United States, the product remains illegal in those markets despite a clean NFC Forum certificate. See RED pillar and FCC pillar.

Declaring more modes or tag types than actually supported

The test plan runs over the entire declared perimeter. Declaring T1-T5 for commercial appearance only multiplies the tests and the risk of failure on a type barely used in the final design. Declaring the strict minimum effectively supported is the rule.

Underestimating NDEF complexity

The NDEF format looks simple at first reading, but implementations often diverge on edge cases (empty records, chaining, UTF-8 versus UTF-16 encoding, payload length, malformed smart poster). A lab rejection on NDEF questions is common and avoidable through internal pre-testing.

Ignoring Secure Element security

An HCE product that claims to do payment without a Secure Element and without a solid TEE / token architecture exposes the issuers to a risk that no NFC Forum certification covers. The security discussion must run alongside the N-Mark discussion, leaning on Common Criteria for the SE and on the scheme requirements.