Compliance frameworks are how a company makes "we are doing wireless security correctly" auditable. The problem with wireless — specifically — is that the authoritative guidance is fragmented across multiple agencies, multiple decades, and multiple radio technologies. NIST SP 800-153 covers Wi-Fi. NIST SP 800-121 R2 covers Bluetooth. NIST SP 800-97 covers 802.1X / EAP. IEEE 802.11i is the cryptographic substrate. ISO/IEC 27033-6 covers wireless network security at a higher level. There is no single document a CISO can hand to a hardware-team lead and say "do this and we are good."
This post proposes one. It is the same baseline SF365 ships as the Wireless Security Baseline compliance framework: 24 controls grouped by surface, each mapped to an auditable check and an underlying source standard.
Design goal. Each control must be either (a) statically detectable from source / configuration, or (b) verifiable by a documented operational procedure. "Trust the team" is not a control.
Wi-Fi controls (WIFI.01–07)
| ID | Control | How it is evidenced | Source |
|---|---|---|---|
WIFI.01 | WEP / WPA-TKIP must not be enabled in any production profile. | Static scan of hostapd.conf, sdkconfig, supplicant code paths. | NIST 800-153 §4.1; IEEE 802.11i |
WIFI.02 | WPA3-Personal (SAE) or WPA3 Transition Mode is the default for new SSIDs. | AP configuration audit; client capability log review. | NIST 800-153 §4.4 |
WIFI.03 | Protected Management Frames (IEEE 802.11w) are required (ieee80211w=2). | Static scan + AP runtime check. | IEEE 802.11w; NIST 800-153 §4.5 |
WIFI.04 | Wi-Fi Protected Setup (WPS) is disabled in production builds. | Static scan; runtime probe. | NIST 800-153 §4.3 |
WIFI.05 | SSIDs and PSKs are not stored in source / firmware as constants. | SecretScanner pattern; build-config review. | NIST 800-153 §3.2 |
WIFI.06 | "Open" SSIDs in production use Enhanced Open (OWE) or are off. | AP configuration audit. | NIST 800-153 §4.6 |
WIFI.07 | Enterprise (802.1X) deployments use EAP-TLS or EAP-PEAP/MSCHAPv2 with proper certificate validation. | Supplicant config + RADIUS audit. | NIST 800-97 §4 |
Bluetooth controls (BT.01–08)
| ID | Control | How it is evidenced | Source |
|---|---|---|---|
BT.01 | Default PINs (0000, 1234, 123456) must not appear in source. | Static scan of pairing init code. | NIST 800-121 §3.4 |
BT.02 | Bluetooth Classic devices use Secure Simple Pairing (SSP) or Secure Connections; legacy pairing is disabled. | Stack configuration review. | NIST 800-121 §3.3 |
BT.03 | Devices are not permanently discoverable. | Static scan: setDiscoverable with no timeout; runtime probe. | NIST 800-121 §3.6 |
BT.04 | BLE peripherals do not declare NoInputNoOutput IO Capabilities for sensitive characteristics. | Static scan of BLE init code. | NIST 800-121 §4.4 |
BT.05 | LE Secure Connections (LESC) is enabled and required (BLE 4.2+). | Static scan: sm_sc=1 / SC_PAIR_ONLY. | NIST 800-121 §4.3 |
BT.06 | GATT characteristics handling sensitive data require encryption + authentication. | Static scan of GATT flag declarations. | NIST 800-121 §4.5 |
BT.07 | Passkeys and bonding keys are not hardcoded constants. | SecretScanner pattern; static scan. | NIST 800-121 §4.4 |
BT.08 | Minimum encryption key size is 16 bytes (mitigates KNOB / CVE-2019-9506). | Stack config review: min_key_size=16. | NIST 800-121 §3.5; CVE-2019-9506 |
Sub-GHz RF controls (RF.01–03)
| ID | Control | How it is evidenced | Source |
|---|---|---|---|
RF.01 | Remote-control products use rolling-code or AES-encrypted protocols, not fixed codes. | Source review of tx / rx code paths. | NIST IR 8228 §4.2 |
RF.02 | ISM-band frequencies and modulation are not the only "secret" the product depends on. | Threat-model review; documented design decision. | NIST IR 8228 §4.2 |
RF.03 | LoRa deployments use LoRaWAN cryptography (NwkSKey + AppSKey), not raw LoRa. | Source review; LoRaWAN spec compliance. | LoRaWAN 1.0.4 Spec §6 |
NFC / RFID controls (NFC.01–02)
| ID | Control | How it is evidenced | Source |
|---|---|---|---|
NFC.01 | MIFARE Classic is not used for new deployments; existing deployments have a migration plan. | Source review; product-decision record. | NIST 800-98 §6.4 |
NFC.02 | Authorisation must not depend on the card UID alone; cryptographic challenge-response is required. | Source review of access-control code. | NIST 800-98 §5.3 |
IoT transport controls (IOT.01–04)
| ID | Control | How it is evidenced | Source |
|---|---|---|---|
IOT.01 | Zigbee deployments do not use the default trust-centre key (ZigBeeAlliance09); install codes / per-device keys are required. | Source review; provisioning audit. | Zigbee 3.0 Spec; NIST IR 8228 |
IOT.02 | MQTT brokers serving production traffic require TLS (mqtts:// port 8883), not plaintext (mqtt:// port 1883). | Source review + broker config. | NIST IR 8228 §4.3 |
IOT.03 | CoAP endpoints use DTLS (coaps://), not plain CoAP. | Source review. | RFC 7252 §9 |
IOT.04 | Device identity material (cloud SAS, JWT signing keys, device certs) is not embedded as build constants. | SecretScanner pattern (10 IoT/wireless cloud regexes). | NIST IR 8228 §4.4 |
How a control gets evidenced
For each of the 24 controls, the SF365 portal accepts three states — Passed, Partial, Violated — and ties them to artefacts:
- Static evidence — findings from the WirelessScanner and the SecretScanner. If
WIFI-01fired,WIFI.01is marked Violated. - Configuration evidence — the AP / supplicant / broker configuration files committed to the repo.
- Operational evidence — documented procedures linked from the control. For RF and physical controls, this is often the only available evidence.
The /wireless-security dashboard rolls up the 24 controls into a single "baseline coverage" KPI (the percentage marked Passed). The Wireless Assessment PDF report exports the full table with per-control evidence so an external auditor can use it directly.
Why this works as a 2026 baseline
- It covers all six surfaces. Most existing wireless frameworks are Wi-Fi-only; a few cover Wi-Fi + Bluetooth. None of the public ones address RF + NFC + IoT transports together.
- It maps to authoritative sources. Every control cites NIST or IEEE so an auditor can verify the underlying expectation, not just the SF365 phrasing.
- It is automatable. Sixteen of the 24 controls are statically detectable from source. The remaining eight require human judgement — which is fine, that's what compliance reviews are for.
- It composes with what you already have. If you are already tracking PCI DSS, HIPAA or SOC 2, the Wireless Security Baseline is additive: it covers a surface those frameworks barely touch.
Where to start
Pick the surface your product actually uses. A pure Wi-Fi product needs WIFI.01–07. A BLE peripheral needs BT.04–08. An IoT gateway probably touches all five surface groups. Walk down the relevant control list once, mark each Passed / Partial / Violated, and accept that the first pass will not be all-green. The point is to make the gaps visible.
From there: every control marked Violated becomes a backlog item, every Partial becomes a follow-up review, and the percentage of controls marked Passed becomes a single number a board member can read.
The 24-control baseline ships in SF365 today
Findings, dashboard, PDF report, and per-control NIST / IEEE references — out of the box. Compliance for the wireless surface, finally auditable.
See the Baseline in Action