RFID, NFC & UWB · Study deck
NFC IoT System Integration
Picture a nurse tapping a medicine cabinet with a phone.
Radio Remi is your guide for this deck.

After studying this chapter
Learning objectives
You will be able to:
- Design an NFC-to-IoT integration boundary that separates tag data from authorization.
- Define a compact event contract for tap events, gateway reads, application links, and controller actions.
- Choose where policy should live across mobile apps, local gateways, controllers, brokers, and backend services.
- Plan lab validation for offline operation, duplicate taps, replay risk, fallback, privacy, and audit records.
Major section
Start With the Story
The tap can identify the cabinet and start a request, but it should not decide by itself that the door may open.
- The system must connect the person, cabinet, intended action, current conditions, and final result.
- Near Field Communication (NFC) is a short-range link used during a deliberate close tap.
- A gateway is a device that passes a local event into another service path.
- This tap test does not prove every tag, phone, or cabinet.
Major section
Eddie's Math Bridge: Budget Five Years of NFC Wake Events · Integration Boundary
The mathematical gist.: A 220 mAh, 3 V coin cell has about 167 mAh or 502 mWh usable after five years of 1% self-discharge and a 20% design reserve.
- In most IoT systems, the tap identifies context; another layer decides the action.
Major section
NFC Starts the Workflow, Not the System
NFC moves only small amounts of data slowly over a few centimeters, so its highest-value role in IoT is often bootstrapping a faster radio or authenticated workflow.
- It makes the tap a strong selector for a setup workflow that still needs session checks, policy checks, and audit evidence.
Major section
NFC Starts the Workflow, Not the System (continued)
The app should not blindly configure that gateway.
- A deliberate tap can hand over the information a device needs to join Wi-Fi, pair over Bluetooth, open a Thread commissioning path, or request a backend setup token.
- Both target choice and confirm peer need evidence.
- The integration is a chain with visible boundaries.
Major section
NFC Starts the Workflow, Not the System (continued)
The audit stream records the tap, the decision, the action result, and the fallback path.
- For nfc starts the workflow, not the system, record the result beside not NFC.
- NFC selects the device and transfers a compact setup hint.
- The policy service decides whether this user may commission this asset now.
Major section
NFC Starts the Workflow, Not the System (continued)
The token can carry the Wi-Fi or BLE setup path for this gateway; the tag itself should not contain a reusable network password or permanent authority.
- BLE or Wi-Fi carries the bulk configuration and later telemetry.
- When those responsibilities are separate, a duplicate tap can refresh the same workflow instead of creating a second service record, and an offline app can present a designed fallback instead of guessing.
- The tap does two useful things at once: it proves physical intent because the user touched this exact device, and it transfers setup material out of band from the network being joined.
Major section
Gateway and Application Flow · Minimal Bridge Shape
The integration path depends on whether the tap is handled by a mobile app, a fixed gateway, an embedded reader, or a credential path.
- For the evidence behind gateway and application flow, set tag against route with it. Manual lookup makes the purpose concrete.
- Skipping route would leave manual lookup unsupported.
Major section
Connection Handover and Setup Tokens
The NFC Forum Connection Handover standard defines how a tap bootstraps another carrier.
- The NFC record is the handoff, not the long-running channel.
- A release-quality handover test should include both the radio path and the ownership boundary.
- A useful event can include tap_id, device_ref, reader_id, schema, payload_hash, session_id, network_state, and idempotency_key.
Major section
Connection Handover and Setup Tokens (continued)
For a sensor hub, the lab might use a static tag that carries an onboarding URL plus a device reference, not a shared building Wi-Fi password.
- The mobile app follows the URL, authenticates the user, requests a one-use setup token, then opens a BLE session to write network settings to the hub.
- Expected evidence includes decoded tag reference, token issued for the same hub, BLE connection established to the matching device identity, configuration write acknowledged, token consumed once, and audit row stored.
- It should avoid direct personal identifiers in topic names or tag payloads.
Major section
Connection Handover and Setup Tokens (continued)
If the same tag is tapped twice in 10 seconds, the idempotency key should return the existing setup workflow rather than issuing two active tokens.
- If the phone is offline, the app should either deny commissioning or use a documented cached policy with an expiry and a sync requirement.
- If the tag points to an approved host but the gateway is already assigned to another site, policy must reject even though the NDEF record is syntactically valid.
- For example, an MQTT topic like site/14/nfc/tap with a redacted event body is easier to govern than alice-smith/GW-142/tap.
Major section
Architecture Choice
The cache must have freshness rules, denial behavior, sync evidence, and a manual override path.
- Topic design must avoid leaking sensitive identifiers and must include replay/idempotency handling.
Major section
Energy Harvesting and Battery-Less Commissioning
A field-detection pin can also let a powered device sleep until an NFC field appears, spending nothing until someone taps.
- NFC can also power the device it configures.
- The same tap provides the data channel and the temporary power.
- Energy harvesting also changes the failure model.
Major section
Energy Harvesting and Battery-Less Commissioning (continued)
Battery-less commissioning lets a phone wake a headless unpowered device, deliver Wi-Fi or configuration data through an NFC-to-I2C bridge, store it, and then leave normal power to run the device later.
- The hard engineering detail is the power budget, not the phrase "battery-less." Treat harvested energy as a measured resource for one short transaction.
- If the wake-and-store sequence draws 2.8 mA at 1.8 V, the load is about 5.0 mW.
- If the final product adds a metal bracket that weakens coupling, the measurement must be repeated with that bracket installed.
Major section
Energy Harvesting and Battery-Less Commissioning (continued)
If the lab measurement at the planned tap position only supports 4.0 mW continuously, the design has negative steady-state margin and must not be released as battery-less commissioning.
- If a storage capacitor covers the shortfall, the evidence should show the capacitor voltage before and after the write, not just a successful demo video.
- A normal powered gateway can retry, log locally, and use a network fallback.
- A battery-less label may brown out halfway through a write, so records need a version, checksum or integrity marker, and a safe "not configured" state.
Major section
Release Evidence · Common Pitfalls
The conclusion in release evidence now has a named boundary.
- Using UID as authority.: A UID can identify a record, but it should not be the only proof for sensitive actions.
- Ignoring duplicate taps.: NFC users often tap twice when feedback is slow.
Major section
Summary · Key Takeaway
NFC IoT integration should separate tag parsing from authorization.
- A tap event needs schema, reader context, validation result, policy decision, idempotency, and audit fields.
- Mobile apps, fixed gateways, embedded controllers, brokers, and backend services have different ownership boundaries.
- Local, backend, and hybrid policy choices should be justified by offline behavior, revocation, audit, privacy, and support evidence.
Deck summary
Key takeaways
The tap can identify the cabinet and start a request, but it should not decide by itself that the door may open.
- The mathematical gist.: A 220 mAh, 3 V coin cell has about 167 mAh or 502 mWh usable after five years of 1% self-discharge and a 20% design reserve.
- NFC moves only small amounts of data slowly over a few centimeters, so its highest-value role in IoT is often bootstrapping a faster radio or authenticated workflow.
- The app should not blindly configure that gateway.
- The audit stream records the tap, the decision, the action result, and the fallback path.
Retrieval practice
Recall check 1 of 3

Radio Remi says: answer from memory, then check your reasoning.
Q1Why should an NFC-to-IoT integration never treat the decoded tag value as permission?
Show answer
Answer: A In NFC-to-IoT integration the tap only selects an object; policy and session authorization must gate the action.
Retrieval practice
Recall check 2 of 3

Radio Remi says: answer from memory, then check your reasoning.
Q2A headless smart speaker needs quick, secure setup that then streams audio. Why is NFC connection handover a strong choice, and what actually carries the audio?
Show answer
Answer: C NFC connection handover passes Bluetooth or Wi-Fi setup material in alternative-carrier records so a tap bootstraps a faster radio.
Retrieval practice
Recall check 3 of 3

Radio Remi says: answer from memory, then check your reasoning.
Q3An NFC tag on a gateway decodes to a valid service-record URL. What should the IoT application do before allowing a replacement action?
Show answer
Answer: B A valid NFC record identifies workflow context.
Print reference
Answers
Answer key.
- A · In NFC-to-IoT integration the tap only selects an object; policy and session authorization must gate the action.
- C · NFC connection handover passes Bluetooth or Wi-Fi setup material in alternative-carrier records so a tap bootstraps a faster radio.
- B · A valid NFC record identifies workflow context.