NIST SP 800-121 Rev. 2 (Guide to Bluetooth Security), explained

NIST SP 800-121 Revision 2, "Guide to Bluetooth Security," gives organizations a working reference for Bluetooth's built-in security modes and a checklist for hardening the devices, firmware and policies around them. Its own Introduction frames the purpose directly: "to provide information to organizations on the security capabilities of Bluetooth and provide recommendations to organizations employing Bluetooth wireless technologies on securing them effectively." Authored by John Padgette, John Bahr, Mayank Batra, Marcel Holtmann, Rhonda Smithbey, Lily Chen and Karen Scarfone, it was originally published in May 2017 and received a substantive errata correction on 19 January 2022 (a clarification to the Security Mode 1 Level 4 cryptography description in Section 3.2.1). NIST's publication page lists it as Final, covering Bluetooth versions 1.1 through 4.2 — explicitly not Bluetooth 5.0, which the Introduction states "is not in the scope of this document."

Why a vendor-neutral device maker should care

Bluetooth is embedded in a huge range of the devices SoftWSP's customers build and scan: wearables, medical devices, industrial sensors, access-control hardware, and consumer IoT of every kind. SP 800-121 is one of the few vendor-neutral, publicly free references that explains which Bluetooth security mode and level a given radio chipset actually implements, and whether that implementation represents the strongest option available for its Bluetooth version — information a firmware security assessment can check against, the same way a firmware SBOM checks component inventory against known CVEs.

BR/EDR/HS security modes: 1 through 4

Section 3 states that "the family of Bluetooth BR/EDR/HS specifications defines four security modes. Each Bluetooth device must operate in one of these modes, called Security Modes 1 through 4."

Mode	How it behaves	NIST's guidance
Mode 1	Never initiates security; no authentication, no encryption	"NIST recommends never using Security Mode 1"
Mode 2	Service-level-enforced: security may start after link establishment but before logical channel setup	Authentication/encryption implemented in the controller; superseded in 2.1+ by Mode 4
Mode 3	Link-level-enforced: a device initiates security procedures before the link is fully established	Recommended for Bluetooth 2.0 and older devices
Mode 4	Service-level-enforced using Secure Simple Pairing (SSP) with ECDH key agreement	Mode 4 Level 4 recommended for 4.1 BR/EDR/HS devices; Mode 4 Level 3 recommended for 2.1 through 4.0 devices

The Executive Summary is explicit about the hierarchy: "For Bluetooth 4.1 devices that have BR, EDR, and High Speed (HS) features, Security Mode 4, Level 4 is recommended because it requires Secure Connections, which uses authenticated pairing and encryption using 128-bit strength keys generated using FIPS-approved Advanced Encryption Standard (AES) encryption."

Low energy (LE) security modes and pairing

Low energy devices (Bluetooth 4.0 and later) use a separate pair of security modes, defined in Section 3.2.1:

• LE Security Mode 1 — levels tied to encryption, from Level 1 (no security) up to Level 4, added in Bluetooth 4.2, which "requires authenticated low energy Secure Connections pairing with encryption" using AES-CMAC and P-256 elliptic curve for pairing and AES-CCM for encryption. NIST "strongly recommends its use for all low energy connections in 4.2."
• LE Security Mode 2 — levels tied to data signing (integrity, not confidentiality).

A sharp warning in Section 3.2.2: LE Legacy Pairing (the 4.0/4.1 pairing method, renamed once 4.2 introduced Secure Connections pairing) "should be considered broken" for every pairing method except out-of-band with a 128-bit temporary key, "because if an attacker can capture the pairing frames, he or she can determine the resulting LTK" — the Long-Term Key used to encrypt the link. Bluetooth 4.2 also added a Secure Connections Only Mode, which forces every service except the no-security Level 1 case onto LE Security Mode 1 Level 4, guaranteeing only FIPS-approved algorithms are used on the physical transport — at the cost of breaking backward compatibility with 4.0/4.1 LE devices, which don't support the P-256 curve.

Named threats in Section 4.2

The guide names several Bluetooth-specific attacks on top of general wireless threats (denial of service, eavesdropping, MITM, message modification):

• Bluesnarfing — exploits "a firmware flaw in older (circa 2003) devices" to force a connection and read stored data, including the device's IMEI.
• Bluejacking — sending unsolicited messages to a Bluetooth device's owner, "resembles spam and phishing attacks."
• Bluebugging — exploits "a security flaw in the firmware of some older (circa 2004) Bluetooth devices" to run the device's commands (placing calls, eavesdropping, sending messages) without the owner's knowledge.
• Car Whisperer — exploits a standard, non-random passkey in hands-free car kits to transmit or receive audio.
• Fuzzing attacks and pairing eavesdropping — malformed-data probing, and capturing PIN/Legacy or LE Legacy pairing frames to recover the secret key.
• Secure Simple Pairing attacks — forcing a device into the unauthenticated "Just Works" method, which provides no MITM protection.

The three attacks tied to "older (circa 2003-2004)" firmware flaws are a direct reminder that Bluetooth security is a firmware property, not just a protocol-configuration one — the same device can carry a vulnerable Bluetooth stack years after the spec itself added stronger modes, which is exactly what a firmware SBOM and vulnerability match are built to catch.

The Section 4.4 checklist

Table 4-2, the Bluetooth Piconet Security Checklist, organizes recommendations under Management (write a Bluetooth security policy, run regular assessments, maintain a device inventory by BD_ADDR, train users) and Technical headings (change default settings, disable unused profiles/services, use the strongest available mode), each marked Recommended Practice or Should Consider, with a blank Status column meant for literal use as an audit checklist. Appendix C cross-references a subset of these recommendations to specific NIST SP 800-53 Revision 4 control numbers, letting an assessor tie a Bluetooth finding directly to a control family — the same cross-reference pattern SP 800-128 uses for its own configuration-management checklist.

A workable starting point

1. Identify the actual Bluetooth version and security mode each device implements before assuming it supports the strongest option — a chip from 2015 may be stuck on Mode 3 even though Mode 4 existed since Bluetooth 2.1.
2. Treat Security Mode 1 (and LE Legacy Pairing without out-of-band exchange) as a finding, not a default. NIST's own language is "should never be used" / "should be considered broken."
3. Run Table 4-2 as a literal audit against each product line — policy and inventory items first, then the technical defaults.
4. Remember the scope boundary: this guide stops at Bluetooth 4.2. For 5.x radios, use this guide's threat categories and checklist structure as background, and confirm current mode/level guidance against Bluetooth SIG and NIST's more recent publications before relying on specific recommendations.

SoftWSP's device and firmware security assessments check which Bluetooth stack version and security mode a product actually ships, matched against known firmware-level vulnerabilities: see Device & Firmware Security.

This guide summarises NIST SP 800-121 Revision 2 (May 2017, including the January 2022 errata update); it is not a substitute for the full text and does not constitute compliance or legal advice.