OWE for Headless Wi-Fi Products: Decide What Encrypted Open Access Does Not Authenticate

Opportunistic Wireless Encryption can protect a password-free wireless link against passive observation. It cannot establish that the access point belongs to the intended operator. For a headless product, the engineering decision therefore has two separate parts: whether the selected connection must use OWE, and how the product authenticates the service that receives its data. An attractive network name answers neither question.

This guide uses RFC 8110 for the OWE security model and the official wpa_supplicant 2.11 release for concrete client settings. It assumes an infrastructure Wi-Fi client whose driver, firmware and access point have separately demonstrated OWE interoperability. It does not certify a module, cover Personal-mode transition networks, or prescribe a provisioning transport. RFC 9672 transferred continuing OWE maintenance to IEEE 802.11; RFC 8110 is the historical mechanism reference, not a claim about the newest complete IEEE specification. RFC 9672

Write the trust requirement before choosing the profile

OWE performs an unauthenticated key exchange and establishes link encryption without a shared password. That improves the passive-eavesdropping boundary but leaves active impersonation possible. An attacker-operated access point can participate in its own exchange with a client. The resulting encrypted link still terminates at that access point. It is not an authenticated tunnel to the product’s backend. These distinctions follow the security considerations in RFC 8110, section 7.

Product requirement	What OWE contributes	Additional acceptance evidence
Do not transmit application traffic over an unencrypted Wi-Fi association	A suitable link mechanism, if actually negotiated	Selected AKM and cipher evidence; reject open fallback
Join only an access point operated by a trusted organization	No AP identity assurance by itself	A separately suitable authenticated network-access design
Send records only to the intended backend	No end-to-end service identity assurance	Application peer authentication and authorization
Work without a Wi-Fi password on a public installation	Password-free encrypted access where supported	Discovery, compatibility and unattended recovery qualification

Make the first requirement precise. “Use OWE when available” permits a different outcome from “never accept an open association.” If a disconnected device must remain fail-closed, specify what it stores locally, how it indicates the condition, and which authorized recovery path remains available. Do not hide this product decision inside a connection-manager default.

Make transition behavior explicit

In wpa_supplicant 2.11, an OWE profile uses key_mgmt=OWE. Its documented owe_only=0 default allows transition-mode connection to either an OWE or an open BSS; owe_only=1 restricts that profile to OWE. The release’s example build configuration leaves CONFIG_OWE commented out, so a version string alone does not establish that the shipped executable contains the feature. These are release-specific implementation facts from wpa_supplicant 2.11, wpa_supplicant.conf and defconfig.

Record the actual executable build options, profile owner, generated profile contents and driver/firmware identifiers. If NetworkManager or another service owns the profile, change policy through that owner and verify the resulting effective configuration. Editing a temporary supplicant file can produce a reassuring snapshot that the manager later replaces. Also inventory other enabled profiles: restricting one OWE profile does not prohibit a separate open profile from being selected.

Use the selected BSSID, negotiated security and connection epoch as evidence. A visible SSID, a successful IP lease, or an “online” indicator is insufficient. Redact device identifiers in shared reports, and do not export private credentials merely to show that a password-free profile was chosen.

Qualify selection with controlled alternatives

1. Establish an OWE-only baseline. On an authorized test network, expose the intended OWE BSS, start from a documented profile state, and correlate client association status with AP logs. Record the chosen AKM and cipher, then verify that the application completes its own peer-authentication check.
2. Remove the encrypted choice. In an isolated setup, make only the intended open transition alternative available. For an OWE-required product, the pass condition is no open association through any enabled profile. A connection failure is expected evidence here, not automatically a defect to repair by relaxing policy.
3. Restore both alternatives. Repeat cold boot and reconnect with both visible. Confirm the actual selected security each time. Keep the network manager’s profile inventory in the trace so an unrelated saved profile cannot explain the result.
4. Separate hostile-network and service tests. Use an authorized imitation AP and a deliberately untrusted test service. OWE may still establish link encryption; the application must withhold protected operations when its service trust check fails. Never use production secrets for this experiment.
5. Exercise recovery without changing the requirement. Reboot the AP, temporarily remove coverage, and restore the approved configuration. Check bounded local buffering and operator-visible status. Do not interpret successful recovery as permission to enable an open fallback.

If the client never advertises or selects OWE, first inspect build capability and effective profile selection. If OWE negotiation starts but fails, correlate the precise rejection with AP and client releases before changing cryptographic settings. If association succeeds but the application rejects its peer, keep that result in the application-trust branch rather than weakening the Wi-Fi profile or server verification.

A hypothetical acceptance decision

Consider a battery-powered exhibit logger installed on a password-free visitor network. Its requirement permits an untrusted network operator but prohibits open wireless transport and requires authentication of its upload service. OWE with an explicit OWE-only selection policy can address the link requirement. The logger still needs independent service trust, and it must buffer records when only the open alternative is available.

If the same logger is instead required to recognize the venue’s AP identity, the acceptance decision changes. OWE alone cannot satisfy that requirement. The team must choose an authenticated network-access mechanism or revise the requirement through its normal approval process. Reusing the familiar SSID is not a substitute.

What was checked, and what remains

A host fixture built the unmodified wpa_supplicant 2.11 source with its no-radio driver and inert layer-two stub. Disabled synthetic profiles with owe_only=0 and 1 parsed successfully; value 2 was rejected. The build used GCC 14.2 and OpenSSL 3.5.7, with deprecated-API warnings made nonfatal. This checks configuration parsing only. It does not demonstrate RF behavior, open-fallback rejection, cryptographic interoperability or application authentication.

The release gate is therefore a target evidence bundle: exact build and profile ownership, observed negotiated security, negative open-only results, independent service-trust results, and recovery behavior. Keep these outcomes separate so a successful encrypted association cannot be mistaken for authenticated infrastructure.