Pairing is the moment a product decides who to trust, and it is usually the least examined moment in the design. "Just Works" modes authenticate nothing, research has shown that most consumer and even industrial IoT devices ship with pairing that offers no protection against man-in-the-middle attacks. The device authenticates; the controller does not.
The consequence is not theoretical. A pairing process that verifies the product but fails to bind the controller allows an attacker to enroll as a new peer and inherit the trust relationship. From there, the protocol state machine governs what the attacker can reach, and state machines designed for user convenience, not for adversaries, routinely expose privileged commands in early or recovery states.
Even correctly paired sessions face replay and spoofing: a captured command that changes product state, re-sent because freshness is not enforced; a spoofed peer identity accepted because the trust decision checks presence, not binding. Encryption without authentication policy is a sealed envelope delivered to whoever asks.
Wireless trust depends on several technical assumptions.
- Discovery exposure Is the device discoverable by anyone, and what does the exchange leak before authentication?
- Pairing mode Which mode is used (Just Works, Passkey, Numeric Comparison, OOB), and does it actually authenticate both peers?
- Peer binding Does the protocol bind the correct controller, or does the next requester get enrolled?
- Freshness & replay Are sequence numbers, nonces or counters enforced on state-changing commands?
- Spoofing resistance Can a forged peer identity be accepted at the trust decision point?
- State-machine exposure Which commands are available in each protocol state, including early, recovery and error states?
- Authorization after pairing Does the trusted peer get everything, or is privileged functionality separately authorized?
Paired once, trusted forever, controlled by whoever asked next.
The product authenticates itself during pairing. The controller is not strongly bound. An attacker in radio range enrolls as a new peer during the next pairing window, the protocol accepts, because enrollment is what pairing does.
With the trust relationship established, the attacker reaches the authorized command set. The state machine was designed to be convenient: early states already expose configuration. No cryptographic check fails, the trust decision simply answered the wrong question.
Attack the trust relationship, not just the radio.
We test pairing as the trust decision it is: attempting enrollment as an attacker, replaying captured commands against freshness enforcement, spoofing peer identities at the decision point, and walking the protocol state machine to find which states expose privileged behavior.
- New wireless product before release
- New pairing or onboarding process
- Mobile application controls a physical product
- Device-to-device communication introduced
- Re-pairing or reset behavior changed
- A reported vulnerability involves pairing, replay or RF behavior
- Compliance or customer assurance requires wireless security evidence