Bluetooth, RFID and NFC Security Guide: Short-Range Wireless Risks and Controls

Short-range wireless is trusted because it is short range, yet Bluetooth, RFID badges and NFC each carry identity and access decisions that an attacker within a few metres can observe, clone or downgrade. Bluetooth headsets, keyboards, medical and industrial sensors pair with corporate laptops and phones; proximity badges open doors; NFC carries payments, transit tickets and security key sign-ins. Many of these deployments still use pairing modes, card technologies or reader wiring that published standards describe as weak. This guide covers Bluetooth BR/EDR and Low Energy security modes, the main flaw classes and how to defend against them, RFID badge cloning and the move to secure credentials, and NFC for payments and authentication. It is written for security architects, endpoint and physical security teams, and anyone writing a short-range wireless policy.

Key takeaways

• Pairing mode decides most Bluetooth risk. NIST SP 800-121 Rev. 2 says Just Works gives no man-in-the-middle protection and LE Legacy pairing should be considered broken; LE Secure Connections and Secure Connections Only mode are the targets.
• Most serious Bluetooth flaws are fixed by patching the stack. BlueBorne, KNOB and BLURtooth were implementation or specification flaws addressed by vendor updates and Bluetooth SIG errata, so firmware and OS currency is the main control.
• A card that only sends an identifier can be copied. NIST SP 800-116 Rev. 1 explains that a cloned static identifier passes identifier-only checks but not challenge-response with a private key that never leaves the card.
• The reader wiring matters as much as the card. Legacy Wiegand links carry credentials in clear; OSDP Secure Channel with AES-128 protects the reader to panel link.
• NFC is safest when the card does cryptography. EMV contactless and FIDO security keys use dynamic cryptographic responses; plain NFC tags and identifier-only cards do not.

Short-range technologies compared

Bluetooth security modes and pairing

NIST SP 800-121 Rev. 2 is the main reference for enterprise Bluetooth policy. Its recommendations reduce to choosing the strongest mode both ends support and refusing the rest.

BR/EDR (Classic)

• Security Mode 1: never initiates security. NIST says never use it.
• Security Mode 2: service-level enforcement with authorisation.
• Security Mode 3: link-level enforcement, authentication and encryption on every connection; recommended only for Bluetooth 2.0 and older devices.
• Security Mode 4: service-level enforcement with Secure Simple Pairing, introduced in 2.1 + EDR. Level 4 requires an authenticated link key using Secure Connections and is recommended for 4.1 and later; Level 3 (authenticated link key) is the strongest available for 2.1 to 4.0.
• Secure Connections Only mode: refuses devices without Secure Connections and uses only FIPS-approved algorithms. It breaks backward compatibility, which is the point.

Low Energy

Association models

• Numeric Comparison: both devices show a six-digit number and the user confirms a match. Authenticated.
• Passkey Entry: a six-digit number shown on one device is typed on the other. Authenticated, but in LE Legacy pairing it gives at most 20 bits of entropy.
• Out of Band: keys or discovery data are exchanged over another channel, often NFC. Authenticated, and in LE Legacy pairing the only method NIST does not treat as broken (with a 128-bit temporary key).
• Just Works: no display or keypad needed, no MITM protection. In LE Legacy pairing the temporary key is all zeros, so an eavesdropper who captures pairing can derive the long-term key.

Policy settings that follow: keep devices non-discoverable except while pairing, pair infrequently and in physically secure areas, set a minimum encryption key size, disable unneeded profiles and services, remove stale pairings, and turn Bluetooth off where it is not needed. Where a fixed PIN is unavoidable on old BR/EDR devices, NIST suggests eight alphanumeric characters for higher-risk use. Endpoint teams can enforce many of these through MDM restrictions; see the Mobile Device Security Guide.

LE privacy and tracking

A device that advertises a fixed address can be tracked. The Bluetooth SIG describes LE Privacy, available since Core 4.0 and improved in 4.2, which replaces the advertised address with a random value that changes at intervals the manufacturer sets. Paired devices exchange an Identity Resolution Key (IRK) so that trusted peers can resolve the random address. When buying wearables, badges or asset tags, ask whether LE Privacy is enabled and how often the address rotates.

Bluetooth flaw classes, described defensively

The pattern is consistent: specification downgrades are fixed by refusing weak options (Secure Connections Only, minimum key length, no Just Works), and implementation bugs are fixed by patching. Devices that cannot be patched, which includes many embedded sensors and cheap peripherals, should be isolated or replaced. Bluetooth is also a data path: MITRE ATT&CK tracks T1011.001 Exfiltration Over Bluetooth, which is a reason to restrict which Bluetooth profiles corporate laptops allow. Testing teams should follow the Wireless Penetration Testing Guide for authorised assessment.

RFID badges: cloning risk and the move to secure credentials

The badge is a physical access credential, and the risk is the same as a password that never changes. NIST SP 800-116 Rev. 1, written for PIV cards in physical access control systems, sets out the principle that applies to any badge: a card that presents only a signed or static identifier, such as the PIV CHUID, can be skimmed and copied into a partial clone that passes identifier-only checks. It cannot pass PKI-CAK or PKI-AUTH, because the private key cannot be copied. NIST deprecates CHUID authentication and says newly purchased systems must support other mechanisms. It also notes that skimming at about 25 cm and sniffing at about 10 m have been reported.

Phased migration from proximity badges

1. Inventory: list reader models, card technologies, controller firmware and the wiring protocol on every door. Mark doors still accepting low-frequency cards.
2. Secure the wiring: replace Wiegand reader links with OSDP and enable Secure Channel (AES-128). The Security Industry Association publishes OSDP, standardised as IEC 60839-11-5:2020, with an OSDP Verified test programme.
3. Deploy multi-technology readers: readers that accept both old and new cards let you reissue badges without a weekend cutover.
4. Reissue by risk: data centres, network rooms and executive floors first, then general office space.
5. Test before switching off: run a pilot floor in parallel mode and confirm that the new credential is checked cryptographically, not by UID; check revocation by disabling a test card.
6. Disable legacy acceptance: turn off low-frequency and UID-only formats door by door, keeping a documented rollback setting on the controller for a short window.
7. Govern the keys: card encoding keys and reader configuration cards are master secrets; store them in an HSM or under dual control.

Always deny access when a status check shows a revoked credential, and use online validation where the latest status matters, as NIST SP 800-116 advises. See the Smart Card and PIV/CAC Authentication Guide and the Physical Security Guide for Security Teams.

RFID beyond badges: asset tags and supply chain

NIST SP 800-98 groups RFID risk into four categories, which make a useful risk register structure:

• Business process risk: a warehouse that depends only on RFID cannot ship if the system fails or is jammed.
• Business intelligence risk: a competitor or criminal reading tags learns what a container holds.
• Privacy risk: tag data correlated across systems can reveal identity and location.
• Externality risk: badly configured networked readers can expose enterprise systems.

Controls listed by NIST include tag lock and kill commands, access passwords, cryptography where tags support it (mostly contactless smart cards, not cheap asset tags), RF shielding, frangible tags, cover-coding on EPC Gen 2, non-revealing identifier formats and secure tag disposal. Treat fixed RFID readers as networked IoT devices with patching and credentials; see the IoT Security Guide.

NFC: payments, authentication and tags

• Contactless payments: EMVCo states that contactless cards and devices support the same cryptographic functions as contact chip cards, which makes them more secure than magnetic stripe. Each transaction produces a dynamic response, so copying a card's static data is not enough to make a valid payment.
• Tokenisation: EMV Payment Tokenisation replaces the card number with a token that should not be usable beyond a specific merchant, device or payment scenario, and issuers can replace tokens without reissuing the card. Mobile wallets use this model. See the Payment Fraud Guide.
• Relay risk: because a contactless transaction is live, the residual risk is relaying it while it happens, often combined with social engineering that persuades a victim to tap a card on their own phone or install a malicious app. Defences sit with issuers (transaction risk scoring, CVM and velocity limits) and users (only install apps from official stores, never tap a payment card on a phone at a caller's request, switch off NFC when unused).
• Security keys and authentication: FIDO security keys over NFC perform origin-bound challenge and response, so a relayed or phished login to a fake site fails. Plain NFC badges that only present an identifier are not authentication. See the Hardware Security Keys Guide.
• NFC tags and smart packaging: a tag that opens a URL is untrusted input, like a QR code. For product verification or anti-counterfeiting, use tags that produce a cryptographic signature or a per-tap message authentication code checked by the brand's server, and lock tag memory so content cannot be rewritten.
• Bluetooth Out of Band pairing: NFC is a good OOB channel for Bluetooth pairing because of its short range, giving authenticated pairing without Just Works.

Where identity fits

Every paired peripheral, badge and NFC credential is an identity with a lifecycle. Bluetooth link keys are long-term machine secrets that should be removed when a device is lost or reassigned. Badge credentials belong in joiner, mover and leaver processes alongside directory accounts, with physical access revoked as fast as logical access. Card encoding keys, reader configuration credentials and the service accounts that sync the physical access system to HR or the identity provider are non-human identities with wide reach. See the Device and IoT Identity Guide.

Detection and measurement

• Bluetooth: MDM and EDR inventory of Bluetooth state, paired devices and stack versions; alerts on new peripherals of unexpected classes on servers and kiosks.
• Physical access: access control logs for denied reads, reads from cards reported lost, the same badge at two distant doors in a short time, and reads at doors outside a cardholder's normal pattern.
• Readers: OSDP supervision alerts for disconnected or tampered readers.

Common failure patterns

• Buying a secure card and reading only its serial number: the system ignores the card's cryptography, so the badge is as cloneable as an old proximity card.
• Leaving Wiegand in place after a card upgrade: the credential is protected in the air and exposed on the wire behind the reader.
• Accepting Just Works for sensitive peripherals: keyboards, medical and industrial sensors paired without MITM protection.
• Unpatchable Bluetooth devices left in service: embedded stacks that will never receive BlueBorne or KNOB-class fixes.
• Treating NFC tags as trusted: rewritable tags in public places pointing users to phishing pages.
• Physical access outside joiner, mover and leaver: badges stay active after the directory account is disabled.

Framework mapping

In ISO/IEC 27001:2022 Annex A, the closest controls are A.7.2 Physical entry, A.8.1 User endpoint devices and A.8.20 Networks security.

Practitioner checklist

• Publish a Bluetooth standard: Secure Connections Only or LE Security Mode 1 Level 4 where supported, no Just Works for keyboards and sensitive devices, non-discoverable by default.
• Enforce Bluetooth restrictions through MDM and remove stale pairings on device reassignment.
• Track Bluetooth stack patch levels and isolate or replace devices that cannot be updated.
• Require LE Privacy and authenticated pairing in procurement for wearables, tags and medical or industrial sensors.
• Find every door accepting 125 kHz or UID-only credentials and set a retirement date.
• Move reader links to OSDP Secure Channel and put card encoding keys under HSM or dual control.
• Use challenge-response credentials (PKI-CAK, PKI-AUTH or equivalent) for sensitive areas and always deny revoked credentials.
• Join badge revocation to the leaver process and measure the gap.
• Use FIDO security keys, not NFC identifiers, for NFC sign-in, and use signed tags for product verification.

Standards and references

• NIST: SP 800-121 Rev. 2, Guide to Bluetooth Security
• NIST: SP 800-116 Rev. 1, Guidelines for the Use of PIV Credentials in Facility Access
• NIST: SP 800-98, Guidelines for Securing Radio Frequency Identification (RFID) Systems
• CERT/CC: VU#918987 Bluetooth BR/EDR key negotiation (KNOB)
• CERT/CC: VU#589825 Bluetooth Cross-Transport Key Derivation (BLURtooth)
• CERT/CC: VU#240311 BlueBorne Bluetooth vulnerabilities
• Security Industry Association: Open Supervised Device Protocol (OSDP)
• EMVCo: EMV Payment Tokenisation

Related NHI Mgmt Group resources: Wi-Fi Security Guide · IoT Security Guide · Device and IoT Identity Guide · Mobile Device Security Guide · Smart Card and PIV/CAC Authentication Guide