13  How NFC Taps Work

13.1 Start With the Story

An NFC tap feels simple because the devices are close and the action is deliberate. Under that simple gesture are separate layers: field activation, mode choice, tag or card behavior, NDEF payload, policy decision, and application handoff.

This chapter starts with the tap and follows it downward. Treat proximity as a user-intent clue, not a complete security proof, then decide which layer must carry the evidence for the workflow.

13.2 Overview: What an NFC Tap Can Prove

Near Field Communication, or NFC, is the deliberate-tap member of the RFID family. It uses a 13.56 MHz near-field magnetic link so a phone, reader, tag, secure element, or card-emulation device can exchange a small record at very close range. In IoT, the useful claim is usually not "NFC is available." The useful claim is that a local tap selected the intended object, record, credential, setup flow, or service workflow under named conditions.

That boundary matters because proximity is useful but not complete proof. A tap can support user intent and object selection, but it does not automatically prove identity, authorization, payload authenticity, object state, privacy safety, or application correctness. Those decisions belong in the payload parser, application session, credential verifier, backend policy, audit trail, and retest plan.

Work through a simple maintenance example. A gateway label contains an NDEF URI such as https://ops.example/assets/GW-142. A successful tap proves that this phone and this mounted label exchanged a readable record under the tested placement, case, and orientation. It does not prove that the URI host is approved, that GW-142 still exists, that the technician is assigned to the work order, or that starting service is safe while the gateway is active. The review has to convert the tap into evidence: decoded host and path, payload hash, parser result, signed-in session, asset state, allowed action, audit row, and fallback if the tag is unreadable.

The same boundary prevents overclaiming in other NFC uses. A pairing tap can carry Bluetooth or Wi-Fi setup material, but the faster radio still carries the ongoing traffic. A card-emulation tap can present a credential, but freshness, revocation, and verifier policy still decide whether access is allowed. A passive tag can help identify a product or asset, but copied public data must be treated differently from a managed credential. In every case, the tap is a strong local gesture only when the design says exactly what was selected, what was validated, and what remains outside the NFC proof.

NFC Data Exchange

If you only need the intuition, this layer is enough: approve NFC as a bounded local-selection signal. Name the mode, tag or device role, payload type, parser checks, application policy, fallback, owner, and retest trigger before treating a tap workflow as ready.

The Four NFC Layers

Field and roles

The initiator creates the near field. A passive tag may harvest energy, while a powered phone, reader, or emulated card has its own operating constraints.

Protocol mode

Reader/writer, card emulation, and peer-to-peer modes assign different owners for the field, exchanged data, credentials, replay controls, and audit evidence.

Payload meaning

NDEF records, tag memory, handoff references, and credential protocols must be parsed, bounded, versioned, and checked before an application acts.

Application policy

The app or backend decides whether the selected object, user, role, asset state, fallback, privacy boundary, and audit record make the action allowed.

Beginner Examples

• A setup tag can select a gateway record. It should not store a long-lived password or silently complete configuration without app policy.
• A maintenance tag can open an asset record. It does not prove the technician is authorized or that the asset state allows the requested work order.
• A contactless credential can be presented to a verifier. Treat copied identifiers, static text, and public URIs differently from managed credential protocols.
• A peer-to-peer or handover flow can reduce typing. It is not a bulk data channel and still needs validation after the handoff.

Overview Knowledge Check

13.3 Practitioner: Build the NFC Design Record

A practical NFC review record should let another engineer repeat the decision. It names why a deliberate tap is useful, which mode is in scope, what payload or credential is exchanged, how the parser rejects unsafe input, which application policy authorizes the next step, and what physical conditions were tested.

Early design may record assumptions and required tests. A release review should replace assumptions with evidence from representative tags, phones, readers, labels, enclosures, app versions, network states, fallback paths, and support procedures. Keep the approval narrow enough that later changes have clear retest triggers.

Evidence Area

Review Question

Evidence to Record

Failure If Missing

Workflow intent

Why should this action require a deliberate local tap?

Object or credential selected, user action expected, business event in scope, and non-NFC fallback.

The design uses NFC as a label without proving what the local action means.

Mode and role

Who creates the field, who responds, and which mode is approved?

Reader/writer, card emulation, or peer-to-peer scope, with tag type, phone behavior, reader role, and ownership.

Evidence from one mode is transferred to another mode with different trust and device assumptions.

Payload and parser

What is read, written, or presented, and how is it checked?

NDEF or protocol type, scheme, host, length, version, encoding, unsupported-record behavior, read-back, and lock state.

A copied URI, malformed payload, stale reference, or unsupported tag causes unsafe or confusing application behavior.

Application policy

What must be true before the app or backend acts?

User session, role, credential freshness, object state, replay handling, audit, privacy boundary, and exception path.

The tap is mistaken for authorization, or a valid object reference triggers the wrong workflow state.

Physical release

Does the final installation behave like the reviewed case?

Installed label, surface, metal or liquid risk, phone cases, tap-zone marking, environmental handling, replacement, and retest trigger.

A desk test passes, but the mounted tag fails or reads inconsistently in the real workflow.

Worked Review: Maintenance Asset Tap

A maintenance team wants technicians to tap equipment labels with managed phones. The safe design uses reader/writer mode and stores an HTTPS asset reference, not a password or private credential. The app checks the approved host, path pattern, asset identifier format, payload length, technician session, role, work-order state, and audit rule before allowing any action.

The approval statement should stay narrow: this tag selects this asset record under the reviewed label placement and phone conditions. It does not authenticate the technician, prove the equipment is genuine, approve service, or remain valid after label material, app parser, asset-state policy, or mounting changes.

Example Review Record

nfc_design_record: workflow: maintenance asset lookup and work-order start mode: reader/writer target: passive NFC tag mounted on equipment label payload: HTTPS asset reference, not a password or private credential parser_checks: approved host, path pattern, asset id format, payload length app_policy: authenticated technician session, role, work-order state, audit log physical_tests: final label, mounting surface, phone case, tap-zone marking fallback: printed asset id and manual search in the maintenance app retest_trigger: payload schema, label, enclosure, app policy, or support flow change

Practitioner Knowledge Check

13.4 Under the Hood: Handoffs and Failure Boundaries

NFC systems fail when a lower-layer observation is treated as a complete application decision. Field coupling can work while the wrong tag is selected. A tag can return a valid NDEF record that points to an unapproved host. A credential can be presented while the verifier lacks freshness, revocation, or audit policy. A release test can pass on a desk and fail after a label is mounted near metal or hidden behind dense material.

The review should preserve enough handoff evidence to diagnose where the claim stopped being proven: physical coupling, activation, payload parsing, credential handling, application state, privacy, fallback, or operations. That separation keeps NFC approvals from expanding beyond the evidence.

Handoff

What It Proves

What It Does Not Prove

Retest Trigger

Field to target

The reader and target can couple under the tested distance, orientation, antenna, phone, case, surface, and material conditions.

Payload safety, credential validity, application authorization, or behavior after installation changes.

Label, enclosure, mounting surface, phone fleet, reader antenna, protective case, or tap-zone marking change.

Activation to mode

The expected tag technology, reader/writer behavior, card-emulation exchange, or peer-to-peer handoff can start.

That the selected mode has the same trust boundary as another NFC mode or another RFID family.

Mode, tag family, secure element, wallet, reader firmware, app entitlement, or operating-system behavior change.

Payload to parser

The app can read a bounded NDEF record, memory value, reference, or protocol response and reject unsupported input.

That the referenced object is current, the host is trusted, the user is authorized, or copied content is harmless.

Payload schema, host, version, encoding, length, lock state, replacement process, or parser rule change.

Policy to action

The application or verifier can turn the selected object or credential into an allowed workflow decision.

That future roles, revocation state, fallback handling, privacy rules, and support procedures remain valid.

Role model, credential lifecycle, backend state, privacy policy, audit rule, workflow, or support ownership change.

Diagnosis Pattern

1. Name the failing boundary. Separate unreadable tag, multiple targets, unsupported record, wrong host, stale asset reference, unauthorized action, privacy issue, and installed-placement failure.
2. Check the closest lower proof. If the app opens the wrong record, inspect payload parsing before changing antennas. If reads are intermittent, inspect label placement and phone orientation before changing authorization policy.
3. Change one variable at a time. Tag type, record size, lock state, surface material, phone case, app parser, session rule, and fallback flow can each change the evidence trail.
4. Write the unsupported claim. If the test covered one label, one phone fleet, or one payload schema, keep approval limited to that boundary.

Under-the-Hood Knowledge Check

13.5 Summary

• NFC is a 13.56 MHz near-field technology for deliberate local interactions, not a general proof of identity or authorization.
• Reader/writer, card-emulation, and peer-to-peer modes have different field owners, data owners, trust boundaries, and evidence requirements.
• NDEF makes common tag records portable, but it does not provide secrecy, authenticity, freshness, authorization, or anti-cloning by itself.
• A production NFC design should record workflow intent, mode, payload checks, application policy, physical placement, fallback, owner, and retest triggers.
• Most NFC failures become easier to diagnose when the review separates field coupling, mode activation, payload parsing, policy, and operations.

13.6 Key Takeaway

Approve NFC only when the tap is tied to a bounded workflow: local selection, validated payload, application policy, fallback, owner, and retest evidence.

13.7 See Also

NFC Modes and Protocols

Separate reader/writer, card-emulation, peer-to-peer, handover, tag technology, and trust boundaries.

NFC Tags and NDEF Format

Plan tag type, record format, capacity, write state, validation, replacement, and read-back evidence.

NFC Tag Programming

Turn NFC payload planning into safe write, read-back, controller, and release workflows.

NFC Security and Comparisons

Compare NFC with neighboring technologies while keeping proximity, payload, credential, and relay boundaries explicit.