RFID, NFC & UWB · Study deck

NFC Real-World Applications

Picture a technician tapping a label on a pump.

Radio Remi is your guide for this deck.

appsrealworld

Radio Remi, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Classify real NFC deployments by operating mode, data owner, credential owner, and backend decision point.
Explain how payment, access, product-authentication, smart-poster, commissioning, and maintenance workflows use the tap differently.
Separate tag data, user intent, credential proof, and authorization policy in an application design.
Identify deployment evidence needed before an NFC rollout: device support, mounting surface, fallback path, privacy review, and retest triggers.

Major section

Start With the Story

The tap can find the pump record, but it must not grant anyone the right to change the pump settings.

A gateway means a device or service that joins two message paths.
Near field communication, or NFC, lets nearby devices exchange small records.
The app and its policy still decide what the tap may trigger.

Major section

Start With the Story (continued)

This runway does not make proximity a credential or prove every phone works.

NFC appears in payments, access, product labels, commissioning, posters, and maintenance, but the tap is only the visible moment.
Behind it are credentials, records, policies, secure elements, cloud lookups, and fallback paths.
For each workflow, separate the user action from the proof, then decide which boundary carries trust and which evidence must be checked before release.

Major section

In 60 Seconds · Minimum Viable Understanding

Real NFC deployments use the tap as a proof of user intent, object proximity, or credential presentation.

Payment and access flows need issuer-grade credential controls.
Product, maintenance, and poster flows usually need trusted URLs, tag write controls, read-back evidence, and a fallback path.
Smart-home and commissioning flows use NFC to start an action, then the app, gateway, or cloud policy decides what is allowed.

Major section

Application Pattern Map

The same NFC radio can support very different trust boundaries.

A public information tag can open a controlled reference without carrying private data.
An action trigger may pass a target to an app, but the app must still decide whether the user and state permit the action.
The tag should contain a public reference, not private data.

Six NFC real-world application patterns grouped into public-reference flows and credential or proof flows, each naming its trust boundary.

Major section

Application Pattern Map (continued)

The same close-range exchange can support each use, yet the trust evidence and fallback needed for a museum label differ from those needed for a door or service action.

Action trigger: A home, facility, or maintenance tag starts a workflow.
The app or controller must decide whether the action is allowed.
Credential presentation: A phone, wearable, card, or secure tag acts as a credential.
The verifier needs issuer policy, revocation, audit, and replay controls.

Major section

Payments And Access

Payments, transit, door access, and mobile keys are credential systems.

NFC supplies the close-range exchange; it does not own the whole security model.
The reader and verifier must reject copied, stale, malformed, revoked, or wrong-reader evidence; a static UID is not proof.

NFC credential trust path follows a tap to credential proof, reader, allow-or-deny decision, backend policy, audit record and fallback. The close-range exchange alone does not make the trust decision.

Major section

Payment Security Lives Above The NFC Radio

A useful review starts by naming what the tap proves.

Each tap generates a dynamic cryptogram under EMV contactless rules, so a captured transaction cannot simply be replayed.
A tokenized phone wallet presents a payment token instead of the underlying card PAN; a physical contactless card can present its PAN.
The release evidence should name the NFC mode, payload owner, verifier owner, backend decision point, fallback path, and privacy exposure.

Major section

Cryptograms, Tokenization, And Verifier Policy

A maintenance tag should store an asset reference, not a role or command, and the app should reject unknown hosts, excessive payload length, unexpected record types, and retired schema versions.

Together they mean a tokenized contactless credential has transaction-specific proof without exposing the underlying PAN.
For a facility access badge, the checklist is different from a poster tag.
For public tags, the practitioner work is about content and operations rather than issuer-grade cryptography.

Major section

Secure Element, HCE, And Card-Emulation Boundaries

The secure-element die in Figure: A magnified secure-element die makes the hardware boundary makes the hardware key boundary visible.

The photograph cannot prove how a particular product stores or uses keys.
In this design, card-emulation keys may stay in a secure element.
Those features do not authorize an application action by themselves.

Real photograph of secure element chip (se/hsm key storage)

Major section

Secure Element, HCE, And Card-Emulation Boundaries (continued)

The chip may also run cryptographic operations instead of the host.

The host still has to request an operation and interpret its result under application policy.
A close-range tap and a secure chip are different pieces of evidence.
Protected key storage and isolated cryptographic processing keep sensitive operations in the secure element.

Secure element architecture with hardware-isolated cryptographic processing, protected non-extractable key storage, secure boot and attestation support, and tamper-resistant packaging.

Major section

Secure Element, HCE, And Card-Emulation Boundaries (continued)

A secure element keeps the secret in tamper-resistant silicon.

Figure: Secure element architecture with hardware-isolated cryptographic processing shows the key and cryptographic operations assigned to the hardware boundary.
The host, verifier, and backend still need a policy and a record of the result.
A door reader observing a mobile credential is card-emulation or credential-presentation territory: the reader sends a challenge or APDU-like exchange, then the verifier applies policy.

A magnified secure-element die makes the hardware boundary concrete: card-emulation keys and cryptographic operations can remain inside dedicated tamper-resistant silicon instead of general host storage. Photo: Kawe Mazidjatari, CC BY-SA 4.0

Major section

Secure Element, HCE, And Card-Emulation Boundaries (continued)

HCE, introduced in Android 4.4, let wallets emulate cards without a physical secure element by moving the applet to the host and leaning on tokenization and limited-use keys refreshed from the cloud.

A phone reading a passive maintenance tag is reader/writer mode: the phone reads NDEF, validates the host and asset reference, then asks the app or backend what the user may do.
A commissioning tag may only carry a setup reference, after which Bluetooth LE, Wi-Fi, Thread, or cloud enrollment handles the longer session.
A concrete release review can trace one tap end to end.

Major section

Tags For Posters, Products, And Assets · Smart Home And Device Commissioning

Public-facing tags are easier to deploy than credential systems, but they still need controls.

A bad tag can redirect users, expose private information, or make support teams chase stale labels.
Content lives in a server record that can be updated without rewriting every label.

NFC tag application path showing physical tag, NDEF payload, app or browser validation, backend record, analytics and privacy review, and replacement process.

Major section

Product Authentication

Authentication tags need stronger evidence than normal smart posters.

A product label that only stores a fixed URL can be copied.
A stronger design uses dynamic evidence and server-side checks.
A dynamic tag can answer a challenge or provide signed evidence; the verifier app must validate its schema and signature.

NFC product-authentication evidence path from tap through dynamic tag response, verifier app, backend record, risk decision, and customer or technician result.

Major section

Release Evidence · Common Pitfalls

Physical evidence: Final installed tags pass tap tests on target phones, cases, and surfaces.

Security evidence: The tag only selects the asset.
Treating tag data as trusted: Validate all payloads, even when the tag was installed by your own team.
Using NFC as the only fallback: Public and operational systems need a manual path when a phone model, case, or surface blocks the read.

Major section

Summary · Key Takeaway

Payment and access use NFC as a close-range credential exchange, but authorization depends on issuer, verifier, and backend policy.

Smart posters, product labels, and asset tags should store validated references rather than sensitive data.
Device setup and smart-home flows often use NFC to start a workflow, then hand off to the app, controller, or network protocol.
A rollout is not ready until payload, security, privacy, physical installation, fallback, support, and retest evidence are recorded.

Deck summary

Key takeaways

The tap can find the pump record, but it must not grant anyone the right to change the pump settings.

This runway does not make proximity a credential or prove every phone works.
Real NFC deployments use the tap as a proof of user intent, object proximity, or credential presentation.
The same NFC radio can support very different trust boundaries.
The same close-range exchange can support each use, yet the trust evidence and fallback needed for a museum label differ from those needed for a door or service action.

Retrieval practice

Recall check 1 of 3

Radio Remi says: answer from memory, then check your reasoning.

Q1A facility NFC tag opens a maintenance record for a gateway. How do you keep the tag from becoming an unsafe authorization shortcut?

AStore the technician's login credentials directly on the tag itself

BUse the tag only as an asset reference and let the authenticated app and backend decide

CGrant the action to anyone who can physically tap the tag

DEncrypt the tag UID and treat that UID as the login token

Show answer

Answer: B An NFC tap should be an asset reference; the authenticated app and backend must decide whether an action is allowed.

Retrieval practice

Recall check 2 of 3

Radio Remi says: answer from memory, then check your reasoning.

Q2An attacker records a shopper's contactless payment tap in full. Why can they not reuse it, even though NFC has no RF-layer encryption?

ANFC encrypts the radio link itself, so the recording comes out unreadable.

BThe tap contains the real card number, but it is hashed so it cannot be reversed.

CEach EMV transaction uses a one-time dynamic cryptogram; a prior recording cannot supply a fresh one.

DOnly Secure Element phones are safe, whereas host-card-emulation taps can be replayed.

Show answer

Answer: C Contactless payment replay protection comes from transaction-specific EMV cryptograms, independent of SE versus HCE.

Retrieval practice

Recall check 3 of 3

Radio Remi says: answer from memory, then check your reasoning.

Q3A facility tag opens a maintenance app record for a gateway. Which design keeps the NFC tag from becoming an unsafe authorization shortcut?

AStore the technician's service role in the NDEF payload so the app can grant access offline.

BUse the tag only as an asset reference, then let the authenticated app and backend decide.

CLook up the tag UID in the approved asset register and grant the service rights stored for that asset.

DAvoid backend validation because NFC's short range already proves the user's identity.

Show answer

Answer: B A safe real-world NFC app separates object selection from authorization.

Print reference

Answers

Answer key.

B · An NFC tap should be an asset reference; the authenticated app and backend must decide whether an action is allowed.
C · Contactless payment replay protection comes from transaction-specific EMV cryptograms, independent of SE versus HCE.
B · A safe real-world NFC app separates object selection from authorization.