Wi-Fi Protected Setup™ Protocol

and Usability Best Practices

Version 2.0.2
Wi-Fi Alliance®
December 2020

The following document, and the information contained herein regarding Wi-Fi Alliance programs and expected dates of
launch, is subject to revision or removal at any time without notice. THIS DOCUMENT IS PROVIDED ON AN "AS IS",
"AS AVAILABLE" AND "WITH ALL FAULTS" BASIS. WI-FI ALLIANCE MAKES NO REPRESENTATIONS,
WARRANTIES, CONDITIONS OR GUARANTEES AS TO THE USEFULNESS, QUALITY, SUITABILITY, TRUTH,
ACCURACY OR COMPLETENESS OF THIS DOCUMENT AND THE INFORMATION CONTAINED IN THIS
DOCUMENT.
Revision History

Date Version Summary of Changes

Dec 20, 2010 2.0.0 Initial release for Wi-Fi Protected Setup 2.0

Apr 20, 2011 2.0.1 Added sections 3.20 and 3.21

Dec 1, 2020 2.0.2 Editorial update

Table of Contents
1 Introduction .................................................................................................................. 4
1.1 Purpose........................................................................................................................ 4
1.2 Scope ........................................................................................................................... 4
1.3 Related Documents ..................................................................................................... 4
2 List of Acronyms and Definitions ................................................................................. 5
3 Wi-Fi Protected Setup Best Practices ......................................................................... 6
3.1 Push Button Configuration ........................................................................................... 6
3.2 AP Static PINs and Lock-down State .......................................................................... 7
3.3 PIN Checksum Calculation .......................................................................................... 8
3.4 Wi-Fi Protected Setup Discovery Phase for PIN method ............................................ 8
3.5 Weak Diffie-Hellman Private Key .............................................................................. 11
3.6 Registrar Support for all PIN Implementations .......................................................... 11
3.7 Option to Disable Wi-Fi Protected Setup ................................................................... 12
3.8 Consistent Push Button LED Implementation ........................................................... 12
3.9 Dual-band AP & Client Implementations ................................................................... 12
3.10 Use of Dynamic PIN by Mobile APs with Display Capability ..................................... 13
3.11 Required and Optional User Actions ......................................................................... 13
3.12 Required and Optional User Actions in PIN method ................................................. 13
3.13 User-facing Error Messaging ..................................................................................... 14
3.14 Client Joining via PIN method ................................................................................... 16
3.15 Enrollee Session Overlap Detection after WSC Protocol Run (Multiple Registrars
Detected) ................................................................................................................... 16
3.16 AP/Registrar Session Overlap Detection after WSC Protocol Run (Multiple Enrollees
Detected) ................................................................................................................... 17
3.17 External Registrar Configuration of AP in "Configured" State ................................... 17
3.18 Consistent Visual Identification on Labels and UIs for PIN and Push Button ........... 18
3.19 Device Identification Fields ........................................................................................ 18
3.20 Dual-band AP Possible Configurations ..................................................................... 19
3.21 AP With Multiple Credentials (e.g. Dual-band or Virtual APs) ................................... 19
4 Appendices ................................................................................................................ 21
4.1 Dual-band AP and Client Implementations................................................................ 21
1 Introduction
1.1 Purpose
The purpose of this document is to provide additional technical guidance and recommended best
practices for specific features of the Wi-Fi Protected Setup™ Specification.
Although the guidelines mentioned in this document are not mandatory for Wi-Fi Protected Setup
certification, their use will contribute towards enhancing the robustness and flexibility of Wi-Fi
Protected Setup implementations.

1.2 Scope
This document applies to Wi-Fi Protected Setup implementations of Enrollees, Access Points and
Registrars where applicable.
This document contains clarifications, guidelines, and recommendations for Wi-Fi Protected
Setup. These recommendations are not normative, and they do not supersede the generic
protocol specification. For example, this document gives recommendations on interactions
between Wi-Fi Protected Setup and 802.1X/802.11 protocols that apply only to Wi-Fi Protected
Setup use.

1.3 Related Documents

Document Location

Wi-Fi Protected Setup Specification https://www.wi-fi.org/discover-wi-fi/specifications

Wi-Fi Alliance Brand Style Guide https://www.wi-fi.org/file/wi-fi-alliance-brand-

styleguide

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 4 of 29

2 List of Acronyms and Definitions

AP Access Point

CRC Cyclic Redundancy Check

EAP Extensible Authentication Protocol

GUI Graphical User Interface

IE Information Element

LED Light Emitting Diode

Legacy Client Client that does not support Wi-Fi Protected Setup

MODP Modular Exponential

PBC Push Button Configuration

PIN Personal Identification Number

RSSI Receive Signal Strength Indicator

SSID Service Set Identifier

UI User Interface

UUID Universally Unique Identifier

WLAN Wireless LAN

WPA2™ Wi-Fi Protected Access® version 2

WSC Wi-Fi Simple Configuration, used for Wi-Fi Protected Setup

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 5 of 29

3 Wi-Fi Protected Setup Best Practices
3.1 Push Button Configuration
The Push Button Configuration requires the user to press a button on both the Enrollee and on
the AP (or Registrar) within the two-minute interval called the Walk Time. The user can trigger
this sequence from either the AP or the Enrollee. The recommended sequence for a typical Wi-Fi
Protected Setup Enrollee addition follows:

3.1.1 The user purchases a new Wi-Fi Protected Setup device and triggers an Enrollee
addition with either a physical button press or an appropriate alternative option (e.g. a
soft button on a display UI).
• Certified Wi-Fi Protected Setup Enrollees should clearly designate the Wi-Fi Protected
Setup button, preferably using the Wi-Fi Protected Setup Identifier Mark (see Section
3.18).
• The device may conditionally present the WSC trigger sequence if Wi-Fi Protected
Setup-capable APs are detected in the vicinity. Alternately, the Enrollee may allow a
manual WSC connection with any AP in an 802.11 channel scan list in order to
accommodate environments where interference from multiple APs on the same channel
may reduce the ability for Enrollees to see WSC IEs.
• The user typically presses the button until the device WSC visual indicator activates,
indicating a WSC session.
• The WSC visual indicator should change status less than one second from the time it is
triggered by a button press.
• If capable, the device UI should next direct the user to trigger the AP's button.

3.1.2 The user triggers the WSC process with a button press on their Wi-Fi Protected Setup
AP.
• Certified Wi-Fi Protected Setup APs should clearly designate the Wi-Fi Protected Setup
button, preferably using the Wi-Fi Protected Setup Identifier Mark (see Section 3.18).
• The user should be able to trigger a Wi-Fi Protected Setup AP with a single simple button
press. Wi-Fi Protected Setup ease-of-use will be drastically degraded if long vs. short or
single vs. multiple button presses are required. The recommended maximum required
press time should be less than two seconds.
• Push Buttons should not be dual-purposed (i.e. a button that activates more than one
function on the device, depending on condition or length of button press). This is
especially problematic if the alternative purpose of the button is to reset security or reset
the device to factory defaults.

3.1.3 The user confirms the successful completion of the WSC sequence through the
Enrollee's WSC visual indicator.
• When providing instructions, vendors should not assume the presence or behavior of any
WSC visual indicators on other vendors' devices, as visual indicators may vary from
vendor to vendor.
• The following recommended WSC visual indicator LED flashing frequencies make WSC
In-Progress and WSC Error conditions more distinguishable to the user:

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 6 of 29

 On 2 2 2
1 1 •••
Off seconds
In-Progress

On 0.25 0.25 0.25 0.25

0.25 0.25 0.25 •••
Off seconds

Error

On 0.25
0.25 •••
Off seconds
2.0 0.5
Session Overlap Detected

On 300
Off seconds
Success

Figure 1 – WSC Visual Indicator LED Flashing Frequencies

3.2 AP Static PINs and Lock-down State

Issue:
An AP that uses a static label PIN must track multiple failed attempts to authenticate an external
Registrar and then enter a lock-down state (see Section 4.3.1 of the Wi-Fi Protected Setup
Specification). After three failed PIN authentication attempts within 60 seconds, an AP must enter
the lock-down state for 60 seconds. The AP may be designed to stay in lock-down state for a
longer or indefinite period, depending on security requirements.
Some external Registrars may make continuous failed PIN attempts over a period of some
minutes when supplied with an incorrect PIN by a legitimate user. This may cause an AP to go
into lock-down state unless the AP has the capability to distinguish between failed PIN attempts
using the same PIN and failed PIN attempts using different PINs. If the AP is designed to stay in
lock-down state for an extended or indefinite period then the user experience may be adversely
affected.
Solution:
External Registrars that receive a WSC NACK after sending message M2 or M4 should signal the
user that the PIN may be incorrect and should not make further PIN attempts until the correct PIN
is re-entered.
An AP that stays in lock-down state for an extended or indefinite period should either have the
capability to distinguish between failed PIN attempts using the same PIN (indicating mistyping)
versus failed PIN attempts using different PINs (indicating an attack), or use a different heuristic
for locking the AP for long periods. For example, the first lock-down period could be 60 seconds
with each successive lock-down period being progressively longer (e.g. multiplied by two on each
successive attack).

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 7 of 29

3.3 PIN Checksum Calculation
Issue:
The Wi-Fi Protected Setup Specification defines both default and user-specified PIN types for
entry into a Registrar by the user (machine PIN is intended to be a large number not entered
manually by the user). Although length is not specified, four or eight digits are recommended for
both default and user-specified PIN values. Moreover, 8-digit default PIN values require a
checksum, but user-specified PIN values do not. A Registrar may not know whether an Enrollee
PIN is a user-specified or default PIN and, therefore, would not know whether to apply the
checksum calculation.
When an Enrollee PIN is entered in a Registrar before the M1 message is sent by the Enrollee,
the Registrar cannot bind the anonymous PIN to a specific Enrollee UUID or PIN type. If the
Registrar then receives a subsequent M1 message from an Enrollee, the Registrar cannot
determine whether the pre-entered PIN value is associated with that specific Enrollee and,
therefore, cannot assume the PIN type.
Solution:
To avoid usability issues between default and user-specified PIN values, an AP should only
provide a warning to the user on a PIN checksum failure rather than prevent the user from using
the PIN value. PIN checksums and associated warnings should only be performed on 8-digit PIN
values. The only time the AP can apply the PIN checksum with certainty is when the PIN is input
in response to a M1 message from the Enrollee with a Device Password ID of “default PIN.”

3.4 Wi-Fi Protected Setup Discovery Phase for PIN method

Issue:
As shown in Figure 2, the Wi-Fi Protected Setup v1.0 discovery phase for PIN method required
an Enrollee to associate with each Wi-Fi Protected Setup-capable AP within range and initiate the
Registration Protocol by sending M1 in order to discover which Registrar was ready to run the
Registration Protocol. For PIN method, APs were not required to include the Selected Registrar
attribute set to TRUE in Beacons and Probe Responses.

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 8 of 29

Figure 2 – Wi-Fi Protected Setup v1.0 PIN method Discovery Phase

Solution:
The following paragraphs summarize the PIN method discovery phase for a Wi-Fi Protected
Setup Enrollee, as per the Wi-Fi Protected Setup Specification. The summary is followed by a
recommendation for PIN method discovery when the environment includes both Wi-Fi Protected
Setup v1.0 and Wi-Fi Protected Setup v2.0 APs.
As shown in Figure 3, the Wi-Fi Protected Setup discovery phase was modified to allow an
Enrollee to more easily identify which Registrar is ready to run the Registration Protocol for PIN
method (see Wi-Fi Protected Setup Specification Section 4.2). Information about the Enrollee,
equivalent to the information in message M1, is now sent by the Enrollee in the WSC IE in its
Probe Requests. The Enrollee may include the optional Request To Enroll sub-element set to
TRUE to indicate that it is specifically requesting to start Registration and not just performing
discovery. This allows the AP or external Registrar user interfaces to provide the user with
specific indicators containing details of the prospective Enrollee, for example.
The AP must proxy the Enrollee’s Probe Request to the internal or any attached external
Registrar. The AP must include the Selected Registrar attribute set to TRUE in Beacons and
Probe Responses when it receives a SetSelectedRegistrar message with the Selected Registrar
attribute TRUE from a Registrar. Note that some Registrars may send a SetSelectedRegistrar
message with the Selected Registrar attribute TRUE when the user navigates to a GUI page that
allows selection of the Enrollee, so for PIN method the presence of the Selected Registrar
attribute TRUE alone in Beacons and Probe Responses does not guarantee that the Registrar is
ready to run the Registration Protocol.
Once the PIN is entered into the Registrar, it must send a SetSelectedRegistrar message to the
AP with the Selected Registrar attribute TRUE and an AuthorizedMACs sub-element which
includes either the Enrollee MAC address or the wildcard MAC address (FF:FF:FF:FF:FF:FF).

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 9 of 29

The Registrar will include the wildcard MAC address in cases where the Registrar does not know
the Enrollee MAC address yet, for example when the Registration Protocol is started on the
Registrar side first. The AP or external Registrar user interface may also have an option to
specifically enter the Enrollee MAC address to be included in the AuthorizedMACs sub-element,
or the user interface may allow the selection of the Enrollee MAC address from a list of those
Enrollees currently performing discovery.
On receiving the SetSelectedRegistrar message with the Selected Registrar attribute TRUE and
an AuthorizedMACs sub-element with a list of MAC addresses, the AP will include the Selected
Registrar attribute and the AuthorizedMACs sub-element in Beacons and Probe Responses to
indicate that the Registrar is ready to start the Registration Protocol.

Figure 3 – Wi-Fi Protected Setup v2.0 PIN method Discovery Phase

Once the Enrollee receives a Beacon or Probe Response with the Selected Registrar attribute
TRUE and with an AuthorizedMACs sub-element containing either its own MAC address or the
wildcard MAC address, it may start the Registration Protocol. In the case where the wildcard
MAC address is advertised, and not the Enrollee’s MAC address, the PIN attempt may fail if the
Registrar is expecting a different Enrollee. In another case, the Enrollee may receive an M2D
message following its M1 message if a Wi-Fi Protected Setup v1.0 external Registrar is attached
to the AP and the external Registrar is not yet ready to run the Registration Protocol. An Enrollee
must handle both cases.
Note that for the PIN method, an Enrollee may also perform discovery as for Wi-Fi Protected
Setup v1.0 by associating and sending M1, i.e. before receiving a Beacon or Probe Response
with the Selected Registrar attribute TRUE and an AuthorizedMACs sub-element containing
either its own MAC address or the wildcard MAC address. An Enrollee may use this form of
discovery to discover available Registrars.

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 10 of 29

In a mixed environment with both Wi-Fi Protected Setup v1.0 and Wi-Fi Protected Setup v2.0
APs, an Enrollee should be prepared to run both the Wi-Fi Protected Setup v1.0 and Wi-Fi
Protected Setup v2.0 forms of discovery. An Enrollee may scan available channels and then
order PIN attempts with prospective APs as follows:
1. Wi-Fi Protected Setup v2.0 AP with the Selected Registrar attribute TRUE and the Enrollee’s
MAC address in the AuthorizedMACs sub-element in Beacons and Probe Responses.
2. Wi-Fi Protected Setup v2.0 APs with the Selected Registrar attribute TRUE and the wildcard
MAC address in the AuthorizedMACs sub-element in Beacons and Probe Responses,
ordered by decreasing RSSI.
3. Wi-Fi Protected Setup v1.0 APs, ordered by decreasing RSSI.

If option 1 is available, options 2 and 3 should be unnecessary.

3.5 Weak Diffie-Hellman Private Key

Issue:
Any vendor using a weak Diffie-Hellman Private Key could be vulnerable to an exploit that would
allow the compromise of any WSC transactions involving that vendor.
If the Diffie-Hellman Private Key value used in WSC is too short or the value is not random, the
cryptographic security of the WSC message exchange is compromised and the network key is
more easily discovered by a third party who is observing the WSC message exchange.
WSC uses 1536-bit MODP group 5 from RFC 3526. The security level of this group is about 60-
80 bits. The advised length of the private exponent is two times this value, which equates to a
length of 160 bits for this group. As such, the minimum recommended length of Diffie-Hellman
Private Key is 160 bits.
The Diffie-Hellman Private Key may have been made deliberately short in a particular
implementation because it reduces the processing time required for cryptographic operations
when there is limited processing power available on the target platform.
It is also important that the Diffie-Hellman Private Key is generated randomly. Implementations
should not restrict the private key value to numbers whose binary representation has low
Hamming weight to speed up exponentiation. It is very important to advise against such special
choices.
Solution:
Wi-Fi Alliance recommends using a high-entropy private key with a length more than 160 bits for
security. Any vendor not following the recommendation needs to be aware that this may
compromise the security of any WSC procedures in which they participate.

3.6 Registrar Support for all PIN Implementations

Issue:
Some Registrar implementations may prefer or limit connections to Enrollees that have a dynamic
PIN (and are advertising "display" in their probe request or association request) over Enrollees
that have a static PIN (and are advertising "label").
For example, a vendor may implement an External Registrar that prefers Enrollees with dynamic
PINs, (e.g. for security reasons) but this will cause user experience issues. Both static and
dynamic PINs are allowed in WSC and both should be supported. Headless devices may be
unable to generate or display a dynamic PIN, and a user may be unable to change the PIN from
static to dynamic. As a result an Enrollee may be unable to join the network at all.
Solution:
Registrars should allow an Enrollee to join with any valid PIN method.

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 11 of 29

3.7 Option to Disable Wi-Fi Protected Setup
Issue:
Users have requested the option to disable Wi-Fi Protected Setup.
As Enrollees are not required to have Wi-Fi Protected Setup enabled out-of-box, many
implementations allow a user to enable and disable this feature. However, as APs are required to
have Wi-Fi Protected Setup enabled out-of-box, many AP implementations do not provide an
option to disable it.
Solution:
All Wi-Fi Protected Setup devices and software should provide the user with the option to disable
and re-enable this feature (e.g. in the device UI) if possible.

3.8 Consistent Push Button LED Implementation

Issue:
Push Button LED implementations are not mandated due to vendor needs and vendor
differentiation. Users are unable to differentiate between multiple flashing (or blinking) states.
Solution:
Recommendation for a two-color LED:

Blink Solid

Color 1 In Progress Success

For secure networks, the LED should stay
solid until WSC is In Progress again.
For Open (no security-enabled) networks,
the LED should stay solid for 120
seconds and then revert back to the
previous (off) state

Color 2 Session Overlap Error

The LED should Blink for 120 The LED should be Solid for 120 seconds
seconds, and then revert back to and then revert back to the previous state
the previous state

3.9 Dual-band AP & Client Implementations

Issue:
A dual-band AP may appear as two APs to a Client, possibly causing an erroneous Session
Overlap failure in PBC mode.
A dual-band AP may appear as two APs to a Client, requiring the Client to select which AP to join
in PIN mode.
In addition, the Specification does not explicitly define how dual-band devices will behave while
executing Wi-Fi Protected Setup.
Solution:
In PBC mode, all Clients should compare the UUIDs in AP beacons to determine Session
Overlaps (and non-Session Overlaps).

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 12 of 29

In PIN mode with AP Embedded Registrars, all Clients should compare the UUIDs in AP beacons
to determine which bands are available for that AP.
All permutations of dual-band APs and Clients in both PBC and PIN modes are included in
Section 4.1 for completeness.

3.10 Use of Dynamic PIN by Mobile APs with Display Capability

Issue:
Mobile APs that support configuration or Enrollee addition by an External Registrar require a PIN.
Static PINs are vulnerable to brute force attack by attackers posing as External Registrars. In
addition, it may not be convenient to place a static label PIN on the outside of some devices that
may have Mobile AP functionality, such as dual-mode phones or smartphones.
Solution:
Mobile AP devices that support configuration or Enrollee addition by an external Registrar, and
which have a display, should use dynamic PINs and generate a new PIN each time they run the
Registration protocol as Enrollee in initial AP setup mode (see Section 4.3.1 of the Wi-Fi
Protected Setup Specification).

3.11 Required and Optional User Actions

Issue:
Some implementations require the user to select either PIN or PBC before the protocol will run.
While device UIs are not defined by Wi-Fi Protected Setup, this is an unnecessary extra step for
the user to take.
Solution:
AP, Client, and Registrar devices should not require the user to select a specific WSC method
before starting the protocol. The user interface should be as simple as possible and the number
of steps should be minimized based on individual device requirements.

3.12 Required and Optional User Actions in PIN method

Issue:
The Wi-Fi Protected Setup Specification allows the implementation of multiple user interaction
models. As a result, some current implementations of the PIN method require user action at the
Enrollee or Registrar before the Enrollee can be added via PIN to a Registrar.
Examples are:
1. Requiring a user to "enable" Wi-Fi Protected Setup
2. Requiring a user to "enable" the PIN method
3. Requiring a user to "select" a PIN
4. Requiring a user to "activate" a PIN
5. Requiring a user to pre-select the SSID of the target AP before the PIN is active

Requiring user actions at the Enrollee or Registrar before an Enrollee can be added via PIN
decreases the ease-of-use of the Wi-Fi Protected Setup system. These additional tasks can be
even more difficult in the case of a headless Enrollee.
One of the primary goals of the Wi-Fi Protected Setup certification program was to allow a user to
configure and add devices to a secure WLAN without prior knowledge of the SSID and security
settings.

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 13 of 29

Another primary goal is to decrease the number of steps a user must take in order to configure
and add devices to a secure WLAN. However, in some circumstances additional steps may be
considered an improvement to the user experience.
Solution:
The preferred implementation for an Enrollee, particularly a headless Enrollee, would be to have
the PIN always active when Wi-Fi Protected Setup is enabled. The Enrollee should attempt to
associate with (1) any Wi-Fi Protected Setup AP that advertises the AuthorizedMACs attribute,
containing either the Enrollee’s MAC address or the wildcard MAC address, and advertises
SelectedRegistrar equal to TRUE, or with (2) any Wi-Fi Protected Setup v1.0 AP that advertises
SelectedRegistrar equal to TRUE until it finds a Registrar that has its (the Enrollee's) PIN
correctly entered (also see Section 3.4).

3.13 User-facing Error Messaging

Issue:
Inconsistent user-facing instructions and error messaging decrease the ease-of-use of the Wi-Fi
Protected Setup system.
Solution:
When possible, vendors should provide clear and consistent user-facing messaging in response
to system errors. Recommended messaging text for error codes provided in Table 33 of the Wi-Fi
Protected Setup Specification is included below. Messaging is conditional based on the current
logical function of the device displaying the message. For example, when an AP is acting as a
Registrar, it should display the Registrar messaging as appropriate; however, when the AP is
acting as an Enrollee, it should display the Enrollee messaging as appropriate. In some cases,
the Enrollee or Registrar messages may only apply to an AP or Client acting in those functions as
indicated below.

# Description Enrollee Text Registrar Text

(Client or AP) (AP or Client)

0 No error (no message) or (no message) or

In Progress In Progress

1 Out-of-band Interface Error, the security settings Error, the security settings
Read Error cannot be detected. Please try cannot be configured. Please
again. try again.

2 Decryption CRC Error, the security settings Error, the security settings
Failure cannot be detected. Please try cannot be configured. Please
again. try again.

3 2.4 channel not The 2.4 GHz band is not The 2.4 GHz band is not
supported supported by the current supported by the current
network. network.

4 5.0 channel not The 5.0 GHz band is not The 5.0 GHz band is not
supported supported by the current supported by the current
network. network.

5 Signal too weak N/A N/A

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 14 of 29

 # Description Enrollee Text Registrar Text
(Client or AP) (AP or Client)

6 Network auth failure N/A N/A

7 Network association N/A N/A

failure

8 No DHCP response N/A N/A

9 Failed DHCP config N/A N/A

10 IP address conflict N/A N/A

11 Couldn’t connect to AP: Error, this device was Client/ER: N/A

Registrar unable to join the network.

12 Multiple PBC Error. Multiple devices in your Error. Multiple devices in your
sessions detected area have had their buttons area have had their buttons
pushed recently, which may be a pushed recently, which may be
security risk. Please wait two a security risk. Please wait two
minutes and try again. minutes and try again.

13 Rogue activity (vendor specific) (vendor specific)

suspected

14 Device busy Error. Another session of Wi-Fi Error. Another session of Wi-Fi
Protected Setup is running; this Protected Setup is running; this
device is busy at this time. device is busy at this time.
Please wait and try again. Please wait and try again.

15 Setup locked AP: Error. This device has been Client/ER: Error. Due to
locked due to multiple failed multiple failed configuration
configuration attempts that may attempts, the device you are
indicate a security risk. Please attempting to access has been
(insert vendor specific locked. Please wait two minutes
instructions for continuing) and try again, or read the
device's user guide for further
instructions.

16 Message timeout N/A N/A

17 Registration session N/A N/A

timeout

18 Device password auth Error. The PIN used to add this Error. The PIN used to add the
failure device may have been entered new device may have been
incorrectly. Please check the entered incorrectly. Please
PIN and try again. check the PIN and try again.

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 15 of 29

3.14 Client Joining via PIN method
Issue:
The Wi-Fi Protected Setup Specification does not define how and when an Enrollee must begin
"listening" for (1) a Wi-Fi Protected Setup AP that is advertising the AuthorizedMACs attribute,
containing either the Enrollee’s MAC address or the wildcard MAC address, and
SelectedRegistrar equal to TRUE, or for (2) a Wi-Fi Protected Setup v1.0 AP that is advertising
SelectedRegistrar equal to TRUE, and as a result, there are inconsistent implementations and
inconsistent user actions required. For example, a headless Enrollee may not have a UI option to
pre-select an AP, but still should be able to automatically discover and connect to the correct
WLAN.
There is no definition for:
1. How does the Client automatically "start" listening for any AP advertising the
AuthorizedMACs attribute and/or SelectedRegistrar equal to TRUE?
2. How/when does the Client select an AP to associate to?
3. How often does the Client begin listening again? And when does the Client associate to
another AP? (e.g. when a Client is inadvertently already associated with an incorrect (open)
AP)

Solution:
Recommendations for Client (also see Section 3.4):
Start listening:

• on boot
• on idle (connected, but no data frames exchanged for x time, or predefined timer) if
connected to an open AP
1. Connect to (or stay connected to): previously connected (or currently connected) profile if
profile is for a secure AP
2. If not connected (and no profile for a secure AP is retained): search for an AP advertising the
AuthorizedMACs attribute and/or SelectedRegistrar equal to TRUE
3. If no Wi-Fi Protected Setup AP or Wi-Fi Protected Setup v1.0 AP advertising the required
attributes and values is found then go back to vendor defaults or last connected profile

3.15 Enrollee Session Overlap Detection after WSC Protocol Run (Multiple Registrars
Detected)
Issue:
The current Specification includes a two-minute Walk Time during which an Enrollee can find a
Registrar.
However, there is an opportunity for the Enrollee to join a rogue network if a rogue Registrar
initiates PBC mode before the legitimate Registrar does.
Solution:
The Specification requires the Enrollee to scan through all channels to verify that there is only
one AP/Registrar in PBC mode before starting the WSC protocol run. Vendors may improve
security by requiring the Enrollee to do a full scan (but without PBC request in Probe Request
frames) after a successfully completed protocol run. If another PBC Registrar is found at that
point, the Enrollee should report session overlap to the user and may reject the credentials
received during the protocol run.

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 16 of 29

There would be no changes to the actual WSC protocol run and from the Enrollee view point
there would simply be one more standard scan afterward.

3.16 AP/Registrar Session Overlap Detection after WSC Protocol Run (Multiple Enrollees
Detected)
Issue:
The current Specification includes a two-minute Monitor Time which is intended to determine that
one (and only one) Enrollee is in PBC mode. Otherwise, the Specification requires the Registrar
to declare a Session Overlap. In addition, the Specification requires the AP/Registrar to continue
to monitor for additional Enrollees during the WSC protocol run.
However, there is still an opportunity for a rogue Enrollee to join the network if the rogue Enrollee
initiates PBC mode during the Monitor Time, but the legitimate Enrollee initiates PBC mode after
the Registrar successfully completes the protocol run with the rogue Enrollee.
In addition, there is another opportunity for a rogue Enrollee to join the network if the rogue
Enrollee initiates PBC mode after the Registrar initiates PBC mode and successfully completes
the protocol run before the legitimate Enrollee initiates PBC mode.
Solution:
The Specification requires the AP/Registrar to verify that there is only one Enrollee in PBC mode
before starting and during the WSC protocol run. Vendors may improve security by requiring the
AP/Registrar to continue to monitor for Enrollees attempting to associate via PBC mode after a
successfully completed protocol run for up to two minutes.
If another PBC Enrollee is found at that point, the AP/Registrar may message to the user that
there may be a problem. The message may indicate that another Enrollee has been found and
that the user should confirm that the intended Enrollee has joined the network. The device can
provide additional information about what the user can do if a rogue Enrollee has joined the
network.
However, vendors are cautioned that providing this additional Monitor Time might increase
security at the risk of confusing or unnecessarily alarming the user. It is possible for the
AP/Registrar to falsely identify a second (legitimate) Enrollee that is attempting to start a new
WSC session if the user presses the Enrollee's button within two minutes of the previous WSC
session ending, and before pressing the button on the AP/Registrar again. For this reason, if
vendors do choose to implement this additional security feature, it is strongly recommended that
vendors keep the messaging as informational only and avoid alarming language.
There would be no changes to the actual WSC protocol run and from the AP/Registrar view point
there would simply be an additional verification afterward.

3.17 External Registrar Configuration of AP in "Configured" State

Issue:
When an External Registrar registers with an AP which is in the “Not Configured” state, the
External Registrar provides the AP with configuration settings and may then re-associate (if
connected via wireless) and add Enrollees using those settings. The AP moves from the “Not
Configured” to the “Configured” state after being provisioned by the External Registrar, or for
other reasons listed in the Wi-Fi Protected Setup Specification (see Wi-Fi Simple Configuration
State in Section 12 Data Element Definitions, p125).
When an External Registrar registers with an AP which is in “Configured” state it may either (1)
discover the AP’s current settings and then re-associate (if connected via wireless) and add
Enrollees using those settings, or (2) both discover and change the current settings before re-
associating (if connected via wireless) and adding Enrollees. In the latter case, the user may or
may not be aware that the AP’s configuration has changed.

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 17 of 29

Solution:
It is recommended that an External Registrar should inform the user before changing the
configuration of an AP that is in the “Configured” state. This is to prevent a user from unknowingly
reconfiguring their AP. An implementer may also choose to prompt the user before changing the
AP configuration, i.e. the External Registrar user interface could require the user to confirm a
configuration change to an AP that is in “Configured” state before it is committed by the External
Registrar. Note that the user would need to confirm the change before the AP’s WSC state
machine times out waiting for message M8 from the External Registrar.

3.18 Consistent Visual Identification on Labels and UIs for PIN and Push Button
Issue:
A user may be unable to locate the correct PIN or the correct button to press for Wi-Fi Protected
Setup.
Devices (APs and clients) from different manufacturers label the PIN differently. Some common
ways of indicating the PIN are WPS PIN, PIN, PIN CODE, and SECURITY CODE. Also, the
labels on devices often have additional numbers such as serial numbers and MAC addresses that
can confuse the user.
Solution:
The Wi-Fi Protected Setup Identifier Mark PIN method Physical Label should be printed along
with the PIN to clearly provide a visual indication to the user. Additional numbers, such as serial
numbers or MAC addresses, should not be combined with the label. Software Labels should
replicate as closely as possible the layout of the Physical Labels.
It is recommended that a physical Push Button have the Wi-Fi Protected Setup Identifier Mark or
Solo Mark printed directly on it, if possible, or immediately adjacent. Software buttons should
replicate as closely as possible the layout of the physical Push Buttons.
Manufacturers should refer to the Wi-Fi Alliance Brand Style Guide for additional detail.

3.19 Device Identification Fields

Issue:
There are WSC protocol fields that are available in the discovery process that vendors will
choose to display in device user interfaces. The user may identify and connect to devices based
on this device description information. If the device description information is not correct or not
consistent, users will have difficulty identifying and connecting their Wi-Fi Protected Setup
enabled devices.
Solution:
The following guidelines are recommended for each of the device description fields:

UUID (UUID-E and The UUID must be unique. It is recommended that the UUID field be
UUID-R) based on the MAC Address of one interface on the device and that the
UUID must be used on all interfaces. It is recommended that the UUID
is derived as Version 5 Name-based UUID as described in RFC 4122,
Chapter 4.3.

Manufacturer, Model The Manufacturer, Model Name and Model Number should match any
Name and Model similar information displayed on the outside of the device or its
Number packaging.

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 18 of 29

 Serial Number Where this information is available, the Serial Number should be
included. If it is not available, the field should be empty.

Primary Device The Primary Device Type field should be populated with a value that
Type best represents the user’s view of the type of the device.

Device Name Where possible the default value of this field should be populated with a
fairly unique friendly name for the device. The user should have the
able to rename the device by changing this field.

3.20 Dual-band AP Possible Configurations

Issue:
There are four possible combinations of SSID and security settings for a dual-band AP:
• SSIDs are different, security settings are different
• SSIDs are the same, security settings are different (Note: this combination is strongly
discouraged)
• SSIDs are different, security settings are the same
• SSIDs are the same, security settings are the same
This list obviously expands with multi-band (three or more) APs, and can also apply to an AP with
multiple "virtual APs" in the same band.
The Wi-Fi Protected Setup Specification does not define how the AP should be configured by
WSC when multiple virtual or physical APs are supported. Wi-Fi Alliance baseline certifications do
not mandate how an AP should be configured by default, nor do they mandate what combinations
end customers are allowed to configure.
Solution:
There are use cases that benefit from creating different SSIDs. For example, a vendor might wish
to encourage the end customer to connect to one band for media and another band for data,
using the SSID as a method of identifying which band should be used. As another example, when
virtual APs are used on the same band, a different SSID could be used to identify which virtual
network should be used for "guests". When different SSIDs are used, the security settings can be
the same or different.
There are use cases that benefit from using the same SSID on both (or all) bands. For example,
a vendor might wish to allow data offloading from one band to another, or otherwise hide the fact
that there are multiple wireless networks to choose from. When the same SSIDs are used, the
security settings should also be the same.

3.21 AP With Multiple Credentials (e.g. Dual-band or Virtual APs)

Issue:
If an AP is dual- or multi-band, or has virtual APs in the same band, each supported AP may have
different credentials (i.e. SSID and security settings).
The Wi-Fi Protected Setup Specification defines how multiple credentials can be shared during
Wi-Fi Protected Setup negotiation.
Solution:
During WSC, if the SSID and security settings are the same, the AP’s Registrar provides the
credential for all bands or virtual APs.

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 19 of 29

During WSC, if the SSID and security settings are different, the AP’s Registrar may provide all
credentials for all bands and all virtual APs. However, the AP vendor may choose to include only
a single credential based on which band or virtual AP the client device used to initiate WSC, or if
WSC is intended to only apply to one of the networks. For example the push button might only
apply to the local home network and not a guest network.

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 20 of 29

4 Appendices
4.1 Dual-band AP and Client Implementations

PB Client parallel PB AP

Client search 2.4 parallel Client search 5 AP broadcast 2.4

Client find AP in
2.4

Client find any

Yes Session overlap
other APs?

No

Continue WPS –
etc.
(2.4)

Success

Figure 4 – Scenario 1: PBC → PBC, Client = 2.4 GHz / 5 GHz, AP = 2.4 GHz

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 21 of 29

 PB Client parallel PB AP

Client search 2.4

AP broadcast 2.4 parallel AP broadcast 5

Client find AP in
2.4

Client find any

Yes Session overlap
other APs?

No

Continue WPS –
etc.
(2.4)

Success

Figure 5 – Scenario 2: PBC → PBC, Client = 2.4 GHz, AP = 2.4 GHz / 5 GHz

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 22 of 29

 PB Client parallel PB AP

Client search 2.4 parallel Client search 5 AP broadcast 2.4 parallel AP broadcast 5

Client find AP in
parallel Client find AP in 5
2.4

Client compare
UUID, validate
same AP

Same AP? No

Yes

Client find any

Yes Session overlap
other APs?

No

Client Choose
based on Device
Default*

Continue WPS –
etc.

Success

Figure 6 – Scenario 3: PBC → PBC, Client = 2.4 GHz / 5 GHz, AP = 2.4 GHz / 5 GHz

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 23 of 29

 Select WPS
enabled AP from
Scan List Note: Even if the AP that is selected
isn’t actually the correct AP

Choose to
use WPS

PB Client parallel PB AP

Client search 2.4 parallel Client search 5 AP broadcast 2.4

Client find AP in
2.4

Client find any

Yes Session overlap
other APs?

No

Continue WPS –
etc.
(2.4)

Success

Figure 7 – Scenario 4: PBC from Scan List on Client, Client = 2.4 GHz / 5 GHz, AP = 2.4 GHz

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 24 of 29

 Select WPS
enabled AP from
Scan List Note; Even if the AP that is selected
isn’t actually the correct AP

Choose to
use WPS

PB Client parallel PB AP

Client search 2.4 AP broadcast 2.4 parallel AP broadcast 5

Client find AP in
2.4

Client find any

Yes Session overlap
other APs?

No

Continue WPS –
etc.
(2.4)

Success

Figure 8 – Scenario 5: PBC → PBC from Scan List on Client, Client = 2.4 GHz, AP = 2.4 GHz / 5 GHz

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 25 of 29

 Select WPS
enabled AP from
Scan List
Note: Even if the AP that is selected
isn’t actually the correct AP

Choose to
use WPS

PB Client parallel PB AP

Client search 2.4 parallel Client search 5 AP broadcast 2.4 parallel AP broadcast 5

Client find AP in
parallel Client find AP in 5
2.4

Client compare
UUID, validate
same AP

Same AP? No

Yes

Client find any Yes Session overlap

other APs?

No

Client Choose
based on which
band chosen at
Site Survey step

Continue WPS –
etc.

Success

Figure 9 – Scenario 6: PBC → PBC from Scan List on Client, Client = 2.4 GHz / 5 GHz, AP = 2.4 GHz /
5 GHz

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 26 of 29

 Enter Client PIN
in AP/Registrar

AP broadcast 2.4
– looking for a
client w/ this PIN
Notes:

1) Client scan* for beacons from APs that are broadcasting that
they have a PIN entered and are ready to register an enrolee
2) If Client finds an AP per (1), client will disassociate from
whatever (if anything) it is currently connected/associated to, and
associate to the target AP
Client search 2.4 parallel Client search 5 3) If PIN is correct, continue WPS, (stop scanning)
4) If PIN is incorrect, disassociate and move to the next PIN-
broadcasting AP
5) If no more PIN-broadcasting AP, go back to the previously
associated AP (with the previous encryption key/settings if
necessary)

*SCANNING / Start Listening

Client find AP in
A) On boot and on idle (no data frames exchanged for X time) (or
2.4
predefined timer)
B) Stay on, or connect to, or prefer previously connected (or
currently connected) profile if profile is encrypted
C) If not connected (and no profile per B) - search for AP with PIN
D) If no AP with PIN found, go back to defaults or last connected
profile (open)

Continue WPS –
etc.
(2.4)

Success

Figure 10 – Scenario 7: PIN (Client as Enrollee), Client = 2.4 GHz / 5 GHz, AP = 2.4 GHz

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 27 of 29

 Enter Client PIN One entry applies to both bands
in AP/Registrar

AP broadcast 2.4 AP broadcast 5 – Notes:

– looking for a parallel looking for a client
client w/ this PIN w/ this PIN 1) Client scan* for beacons from APs that are broadcasting
that they have a PIN entered and are ready to register an
enrolee
2) If Client finds an AP per (1), client will disassociate from
whatever (if anything) it is currently connected/associated to,
and associate to the target AP
3) If PIN is correct, continue WPS, (stop scanning)
4) If PIN is incorrect, disassociate and move to the next PIN-
Client search 2.4
broadcasting AP
5) If no more PIN-broadcasting AP, go back to the previously
associated AP (with the previous encryption key/settings if
necessary)

*SCANNING / Start Listening

A) On boot and on idle (no data frames exchanged for X time)
Client find AP in (or predefined timer)
2.4 B) Stay on, or connect to, or prefer previously connected (or
currently connected) profile if profile is encrypted
C) If not connected (and no profile per B) - search for AP with
PIN
D) If no AP with PIN found, go back to defaults or last
connected profile (open)

Continue WPS –
etc.
(2.4)

Success

Figure 11 – Scenario 8: PIN (Client as Enrollee), Client = 2.4 GHz, AP = 2.4 GHz / 5 GHz

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 28 of 29

 Notes:

1) Client scan* for beacons from APs that are

broadcasting that they have a PIN entered and are
Enter Client PIN One entry applies to both bands ready to register an enrolee
in AP/Registrar 2) If Client finds an AP per (1), client will disassociate
from whatever (if anything) it is currently connected/
associated to, and associate to the target AP
3) If PIN is correct, continue WPS, (stop scanning)
4) If PIN is incorrect, disassociate and move to the
next PIN-broadcasting AP
AP broadcast 2.4 AP broadcast 5 – 5) If no more PIN-broadcasting AP, go back to the
– looking for a parallel looking for a client previously associated AP (with the previous encryption
client w/ this PIN w/ this PIN key/settings if necessary)

*SCANNING / Start Listening

A) On boot and on idle (no data frames exchanged for
X time) (or predefined timer)
B) Stay on, or connect to, or prefer previously
connected (or currently connected) profile if profile is
Client search 2.4 parallel Client search 5 encrypted
C) If not connected (and no profile per B) - search for
AP with PIN
D) If no AP with PIN found, go back to defaults or last
connected profile (open)

Note: this means that the Client may find the AP first in
Client find AP in the less preferable band – so the default/order of the
2.4 or 5 – stop scan should be device specific (per Vendor choice)
when find first
Implementation caution: that if the client stops
scanning after selecting an AP per above, then if the
client scans again, could find the second radio and
switch over, could end up switching back and forth...

Continue WPS –
etc.

Success

Figure 12 – Scenario 9: PIN (Client as Enrollee), Client = 2.4 GHz / 5 GHz, AP = 2.4 GHz / 5 GHz

Enter AP/
enrollee PIN in
ER

ER uses UPnP to
send profile(s) to
AP

Success

Figure 13 – Scenario 10: PIN (AP as Enrollee), Client = 2.4 GHz and/or 5 GHz, AP = 2.4 GHz and/or 5
GHz

Version 2.0.2 © 2020 Wi-Fi Alliance. All rights reserved. 29 of 29