Migrate to 6 GHz and Wi-Fi 7 with Cisco Wireless

Introduction

This document describes design and configuration guidelines to optimize the performance of Wi-Fi 7 and fully leverage the 6 GHz spectrum.

CX Design Guide

CX Design Guides are written by specialists from Cisco CX in collaboration with engineers from other departments and peer-reviewed by experts within Cisco; the guides are based on Cisco leading practices as well as knowledge and experience gained from countless customer implementations over many years. Networks designed and configured in line with the recommendations in this document help avoid common pitfalls and improve network operation.

Why 6 GHz and Wi-Fi 7

The 6 GHz band became available for WLAN operations in 2020 and was required for Wi-Fi 6E certification. While Wi-Fi 6 operates in the 2.4 GHz and 5 GHz bands, Wi-Fi 6E utilises the same IEEE 802.11ax standard but extends its functionality to the 6 GHz band, provided specific requirements are met.
The new Wi-Fi 7 certification is based on the IEEE 802.11be standard and supports operations in the 2.4 GHz, 5 GHz, and 6 GHz bands. Wi-Fi 7 also introduces new features and enhancements compared to previous certifications.

Supporting the 6 GHz band and/or Wi-Fi 7 comes with specific requirements, often necessitating new configurations and RF designs, especially when compared to the established practices for the 2.4 GHz and 5 GHz bands with Wi-Fi 6.

For instance, just as using outdated WEP security prevents the adoption of 802.11 standards beyond 802.11a/b/g, newer standards impose even stricter security prerequisites to encourage the deployment of more secure networks.

Conversely, the introduction of the 6 GHz band offers access to cleaner frequencies, improved performance, and support for new use cases. It also enables a more seamless implementation of existing applications, such as voice and video conferencing.

Base requirements for 6 GHz operations and Wi-Fi 7

These are the security requirements written in the certifications for 6 GHz and Wi-Fi 7 operations.

6 GHz band requirements

The 6 GHz band only allows WPA3 or Enhanced Open WLANs, which means one of these security options:

• WPA3-Enterprise with 802.1X authentication
• WPA3 Simultaneous Authentication of Equals (SAE) (a.k.a. WPA3-Personal) with passphrase. SAE-FT (SAE with Fast Transition) is another possible AKM and is actually recommended for use since the SAE handshake is not trivial, and FT allows skipping that longer exchange.
• Enhanced Open with Opportunistic Wireless Encryption (OWE)

While, as per the WPA3 v3.4 specifications (Section 11.2), Enhanced Open transition mode is not supported with 6 GHz, a lot of vendors (including Cisco up to IOS® XE 17.18) do not enforce that yet. Therefore, it is technically possible to configure, for example, an Open SSID on 5 GHz, a corresponding Enhanced Open SSID on 5 and 6 GHz, both with Transition Mode enabled, and all of this without complying with the standards specifications. However, in such a scenario, it must be expected that we rather configure an Enhanced Open SSID without transition mode and available on 6 GHz only (clients supporting 6 GHz typically support Enhanced Open too), while keeping our regular Open SSID on 5 GHz, also without transition mode.

There are no new specific ciphers or algorithm requirements for WPA3-Enterprise, apart from 802.11w/Protected Management Frame (PMF) enforcement. Many vendors, including Cisco, consider 802.1X-SHA256 or "FT + 802.1X" (which actually is 802.1X with SHA256 and Fast Transition on top) only to be WPA3 compliant and plain 802.1X (which uses SHA1) is considered part of WPA2, therefore not fit/supported for 6 GHz.

Wi-Fi 7 requirements

With the Wi-Fi 7 certification of the 802.11be standard, the Wi-Fi Alliance increased the security requirements. Some of them allow to use of the 802.11be data rates and protocol improvements, while some others are specific for supporting Multi-Link Operations (MLO), allowing compatible devices (clients and/or APs) to use multiple frequency bands while maintaining the same association.

In general, Wi-Fi 7 mandates one of these security types:

• WPA3-Enterprise with AES(CCMP128) and 802.1X-SHA256 or FT + 802.1X (which still uses SHA256, even if it is not explicit in its naming). This does not represent a change compared to previously existing WPA3 security prerequisites for the 6 GHz band.
• WPA3-Personal with GCMP256 and SAE-EXT-KEY and/or FT + SAE-EXT-KEY (AKM 24 or 25). Wi-Fi 6E mandates WPA3 SAE and/or FT + SAE with regular AES(CCMP128) and no additional extended key usages; this means that a new cipher was specifically introduced for Wi-Fi 7.
• Enhanced Open / OWE with GCMP256. While AES(CCMP128) can still be configured on the same SSID, clients using AES 128 do not support Wi-Fi 7. Before Wi-Fi 7, most clients supporting Enhanced Open were using AES 128 only, so this is a new, stronger requirement. As for 6 GHz support, no transition mode is allowed.

Regardless of the selected security type, Protected Management Frames (PMF) and Beacon Protection are required to support Wi-Fi 7 on the WLAN.

Because Wi-Fi 7 is still a recent certification at the time of this writing, with an as early as possible release, many vendors did not enforce all these security requirements from the beginning.

More recently, Cisco has been progressively enforcing the configuration options to be compliant with the Wi-Fi 7 certification. Here are the version-specific behaviors:

IOS XE 17.15.3 and later 17.15.x versions

In this branch, all the WLANs are broadcasted as Wi-Fi 7 SSIDs, provided that Wi-Fi 7 is enabled globally and regardless of the security settings.

A client can associate as Wi-Fi 7 capable and achieve Wi-Fi 7 data rates regardless of the security method it uses, provided it’s still supported by the WLAN. However, the client can only associate as MLO capable (on one or more bands) if it respects the strict requirements for Wi-Fi 7 security, or else it is rejected.

This could potentially cause issues when some early Wi-Fi 7 clients unable to support more secure ciphers, like GCMP256, try to associate as Wi-Fi 7 MLO capable to a WLAN, whose security settings do not match the Wi-Fi 7 requirements. In such a situation, the client is rejected because of the invalid security settings (still allowed to be configured under the WLAN).

IOS XE 17.18.1 and later

17.18.1 and later Cisco IOS XE only advertise a WLAN as Wi-Fi 7 and MLO capable if the appropriate security requirements are enabled on the WLAN settings. For example, a WLAN only advertising SAE and not SAE-EXT is broadcasted as MLO-incapable.

The 17.18 branch introduces the feature of an 802.11be Profile, to be attached to a WLAN Profile, for controlling the activation of Wi-Fi 7 on a per-SSID and even per-radio basis.

A new dedicated menu is added under Configuration > Tags & Profiles > 802.11be, where by default a pre-configured 802.11be Profile already exists, under the name of “default-dot11be-profile”.

The four main settings for enabling or disabling Wi-Fi 7 are under the “MLO Group” section. By disabling all four of them, we disable Wi-Fi 7 for all bands of the WLAN Profile, which we attach the 802.11be Profile to. By enabling only some or all of them, we enable Wi-Fi 7 on the corresponding bands/radios of the WLAN Profile, which we attach the 802.11be Profile to.
The “default-dot11be-profile” enables MLO and Wi-Fi 7 on all radios, and it is attached by default to any WLAN Profile.
By creating a new 802.11be Profile with all "MLO Group" settings disabled and attaching it to some specific WLAN Profiles, we can for example selectively disable Wi-Fi 7 for some of our SSIDs.

Under the “Advanced” settings tab of each WLAN Profile, a corresponding 802.11be Profile is attached:

As we can see in the example, the “default-dot11be-profile” is attached by default to any WLAN Profile.

Note: if Wi-Fi 7 is not globally enabled on the controler, as explained later, Wi-Fi 7 is disabled for all WLAN Profiles and 802.11be Profiles are not applied.

Radio design considerations for 6 GHz coverage

Without meaning to become a full prescriptive guide on site surveys, this section briefly describes some base considerations when designing for 6 GHz coverage, especially if there is an already existing installation for 2.4/5 GHz that we would like to migrate to Wi-Fi 6E or 7.
As for any new Wi-Fi deployment we were used to on 2.4 and/or 5 GHz, a new wireless project on 6 GHz must include a corresponding dedicated 6 GHz site survey too.

When pre-Wi-Fi 6E/7 APs are already positioned for specific 5 GHz coverage and needs, in some cases, we can expect to be able to replace them with Wi-Fi 6E/7 capable APs and still obtain good coverage on 6 GHz. For this theory to work, our existing APs must already provide correct 5 GHz coverage for the intended needs (data only, voice, specific applications, and so on) while already being at least 3-4 transmit power levels under their maximum limit. APs typically have 7 to 8 power levels, and each power level divides the transmit power by half. This means a comfortable spot to be is when APs are using the medium of their allowed transmit power range.

According to free space loss calculations, 6 GHz signals are attenuated by 2 dB more than 5 GHz ones. On top of that, 6 GHz signals can also be more impacted by obstacles than their 5 GHz equivalents.

When a Cisco AP increases/decreases its transmit power by one level, it does so by a “jump” of 3 dB. An AP going from a power level of 4, with a transmit power of 11 dBm for example, to a power level of 3, increases its transmit power to 14 dBm (11 dBm for power level 4 and 14 dBm for power level 3 are just a generic example, as different models/generations of APs could have slightly different transmit power values in dBm for the same power level number).

If a pre-Wi-Fi 6E/7 AP already provides good coverage at 5 GHz on power level 4, for instance, a newer Wi-Fi 6E/7 AP with similar 5 GHz radio patterns could replace that former AP without any significant impact on the existing 5 GHz network.

Also, the 6 GHz radio of the new Wi-Fi 6E/7 AP could provide similar 6 GHz coverage to the 5 GHz one just by being at one transmit power level (so 3 dB) higher.

If 5 GHz is already correctly covered with the AP’s 5 GHz radio at 3-4 power levels under its maximum, the corresponding 6 GHz radio could hence be set at 2-3 power levels under its maximum for comparable coverage.

Also, if the 6 GHz radio already provides correct coverage at 2-3 power levels lower than its maximum, it could still exceptionally go even a couple of levels higher, for example to try working around temporary unexpected coverage holes (a neighbor AP’s failure, unannounced obstacles, new RF needs and so on).

Roaming behaviors between pre-Wi-Fi 6E/7 and Wi-Fi 6E/7 APs

Deploying APs supporting different standards and/or frequency bands in the same coverage area has always not been a recommended practice, especially if those different generations of APs are installed in a “salt and pepper” fashion (that is, mixed in the same zone).

While a wireless controller could handle operations (for example, dynamic channel assignment, transmit power control, PMK cache distribution, and so on) from a group of several AP models, clients moving between different standards and even different frequency bands are not always able to handle that properly and they could likely run into roaming issues for example.

On top of that, because of the newer standards, Wi-Fi 6E/7 APs support GCMP256 ciphers for WPA3. The same could however not always be true for some Wi-Fi 6 APs and earlier models. For passphrase/WPA3-Personal and Enhanced Open/OWE SSIDs, requiring the configuration of both AES(CCMP128) and GCMP256 ciphers, certain Wi-Fi 6 (like the 9105, 9115 and 9120 series) do not support GCMP256 and can offer AES(CCMP128) ciphers only to associating clients, including Wi-Fi 6E/7 capable ones. If these Wi-Fi 6E/7 clients needed to roam from/to neighboring Wi-Fi 6E/7 APs supporting GCMP256, they would have to go through a brand-new association, as renegotiating ciphers between AES(CCMP128) and GCMP256 is not supported for transparent roaming. Moreover, in general, it is not optimal to have APs offering different capabilities in the same area: this deployment does not allow clients to use these capabilities reliably while moving and may lead to stickiness or disconnections.
While this scenario must represent a corner case, we want to still keep in mind that, with GCMP256 ciphers configured under the WLAN, roaming of Wi-Fi 6E/7 clients between 9105/9115/9120 APs and 9130/9124/916x/917x APs can not be possible, as these latter series support GCMP256 and the former does not.

Channel widths of 40 MHz or more on 6 GHz can also cause stickiness for 6 GHz-capable clients, who can refuse to re-associate to other bands. This must be one more reason not to mix 6 GHz-capable APs and non-6 GHz-capable APs in the same roaming area.

Enabling Wi-Fi 7 globally

Enabling Wi-Fi 7 globally on IOS XE

When installing or upgrading to an IOS XE version supporting Wi-Fi 7, by default, support for Wi-Fi 7 is globally disabled.
To activate it, we need to navigate under the High Throughput configuration menu of each 2.4/5/6 GHz band and check the box to enable 11be.

Another option could also be to run these three command lines via SSH/console, in terminal configuration mode:

ap dot11 24ghz dot11be
ap dot11 5ghz dot11be
ap dot11 6ghz dot11be

As mentioned in the warning note, when trying to modify these settings, changing the status of 802.11be support results in a brief loss of connectivity for all clients across radios of Wi-Fi 7 APs. If you want to do MLO, which means clients connecting to several bands at the same time, you need to enable 11be on all the bands you want the client to connect to. It is not necessary to enable all the bands, but recommended simply for performance.

Enabling Wi-Fi 7 globally on Cisco Meraki Dashboard

When adding Wi-Fi 7-capable APs (for example CW9178I, CW9176I/D1) to a Cisco Meraki Dashboard network for the first time, support for 802.11be operation is on their default RF Profile.
To activate it, we need to navigate under Wireless > Radio Settings, click on the RF Profile tab and select the profile assigned to the AP (default: 'Basic Indoor Profile' for indoor APs).

In the General section, enable 802.11be (on) as shown in this screenshot:

If one or more WLANs are configured with security settings weaker than those required by the Wi-Fi 7 specification, the Dashboard displays a banner alerting users as shown hereafter.

While the Dashboard allows the configuration to be saved, Wi-Fi 7 is not enabled on the flagged SSIDs until compliance with the Wi-Fi 7 requirements is ensured.
As of this writing, all WLANs enabled in the network must meet the Wi-Fi 7 specification requirements to be enabled on firmware version MR 31.1.x and later (this behaviour changes in a future version of firmware MR 32.1.x).

Once the configuration of the SSID meets the Wi-Fi 7 minimum criteria, the banner disappears.

In the same RF Profile, make sure to enable 6 GHz operation on the APs.

This can be done either for all the SSIDs in bulk or per individual SSID.

Note that Band Steering is available only between 2.4 and 5 GHz.

Example of 6 GHz enablement for all the SSIDs.

Example of 6 GHz enablement for a single SSID.

Use cases

802.1X / WPA3-Enterprise networks

WPA3-Enterprise configuration on IOS XE 

Enterprise WLANs based on WPA2/3 with 802.1X authentication are the easiest to migrate to 6 GHz and/or Wi-Fi 7.

Enabling your 802.1X SSID for 6 GHz only requires enabling PMF support, even as optional, as well as 802.1X-SHA256 and/or FT + 802.1X AKMs, both of which are WPA3 compliant.

We can keep offering WPA2 with standard 802.1X (SHA1) on the same WLAN. Wi-Fi 7 support requires enabling Beacon Protection and setting PMF as required rather than optional; WPA2 802.1X (SHA1) can stay present on the WLAN as a backwards compatibility option. This means you can have all your corporate devices under a single SSID, provided they support 802.11w/PMF, which is quite common on current wireless NICs for laptops and other mobile endpoints.

From a typical WPA2 SSID with these L2 security settings:

We can migrate the configuration for WPA3, 6 GHz and Wi-Fi 7 support as shown here:

WPA3-Enterprise configuration on the Cisco Meraki dashboard

At the time of this writing, WPA3-Enterprise operation is available only with an external RADIUS server (aka "my RADIUS server").

WPA3-Enterprise is not available with Meraki Cloud Authentication.

Starting with MR 31.x, the WPA types are:

• 'WPA3 only', which uses the same ciphers as WPA2, but requires 802.11w (PMF).
• 'WPA3 192-bit', which allows only the EAP-TLS method with chipers TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, or TLS_DHE_RSA_WITH_AES_256_GCM_SHA384. This mode requires configuring the same chipers on the RADIUS server to enable this mode.
• 'WPA3 Transition Mode' (aka mixed mode), which allows the coexistence of WPA2 clients on the same WLAN used for WPA3. 

When using 'WPA3 only' or 'WPA3 192-bit Security', PMF is mandatory for all clients.

In most applications, FT (802.11r), while not mandatory, must better be enabled to mitigate the impact of roaming and re-authentication latency while using an external RADIUS server.

6 GHz operation requires enabling PMF (802.11w). 

When selecting WPA3 Transition Mode, all the clients capable of using WPA3 default to using PMF. All the clients operating on 6 GHz use WPA3.

In this mode, you can select if the legacy client using WPA2 must use PMF (802.11w required) or if that feature is optional (802.11w enabled).

Regardless of the WPA3 selection, Cisco Meraki APs require the GCMP 256 cipher suite to be enabled to operate in Wi-Fi 7 mode.

Furthermore, Beacon Protection is enabled by default on 2.4, 5, and 6 GHz when the APs are operating in Wi-Fi 7 mode.

Passphrase / WPA3-Personal / IoT networks

Enabling a passphrase SSID for 6 GHz, up to Wi-Fi 6E support, is simple and requires SAE and/or FT + SAE, along with other WPA2 PSK AKMs if needed. However, for Wi-Fi 7 support, the certification mandates adding SAE-EXT-KEY and/or FT + SAE-EXT-KEY AKMs, along with GCMP256 cipher. 

Cisco IOS XE 17.18.1 and later allow you to still configure WPA2-PSK on top of the four mentioned SAE AKMs. However this raises the concern of having potentially too many (from a bad client's driver perspective only, because this is legal) AKMs on the same SSID. It is advised that you verify in practice if your WPA2 clients can cope with all the AKMs enabled on the WLAN. In this situation, clients who decide to connect as WPA2 are not allowed to do MLO or Wi-Fi7 but clients connecting with SAE-EXT are allowed to do MLO and Wi-Fi7. The WLAN itself still advertises Wi-Fi 7 and MLO capabilities.

In such cases, we can configure a dedicated WPA3-only SSID with SAE, FT + SAE, SAE-EXT-KEY and FT + SAE-EXT-KEY, offering both AES(CCMP128) and GCMP256 ciphers, for more recent Wi-Fi 6E and Wi-Fi 7 clients.

In all these scenarios, we strongly recommend enabling FT when using SAE. The SAE frame exchange is costly in terms of resources and longer than the WPA2 PSK 4-way handshake.

Some device manufacturers like Apple expect to use SAE only when FT is enabled and can refuse to connect if not available.

WPA3-SAE and WPA2-Personal configuration on IOS XE 

Note: If (FT +) SAE is enabled on the WLAN and a Wi-Fi 7 client tries to associate with it instead of (FT +) SAE-EXT-KEY, it is rejected. As long as (FT +) SAE-EXT-KEY is enabled too, Wi-Fi 7 clients must anyway use this latter AKM, and this issue must not happen.

Although using a legacy WLAN with only PSK on top of a WPA-3 only WLAN increases the amount of total SSIDs, it allows to keep maximum compatibility on one SSID, where we can also potentially disable other advanced features that could impact compatibility and which could be helpful for many IoT scenarios, while offering maximum features and performances to more recent devices through the other SSID. This can be a prefered scenario if you have older or more sensitive IoT devices in the picture. If you do not have IoT devices, going for a single transition mode WLAN can be more efficient as you only advertise one SSID.

WPA3-SAE configuration on the Cisco Meraki dashboard

Up to firmware MR 30.x, the only supported WPA type is 'WPA3 only', and the dashboard does not let you select a different method.

PMF is mandatory in this configuration, while FT (802.11r) is recommended to be enabled when using SAE.

To allow Wi-Fi 7 operation, the GCMP 256 chiper suite and SAE-EXT AKM suite must be enabled upon configuration of the SSID.

They are disabled by default, and can be enabled under 'Advanced WPA3 settings.' 

As of this writing, all WLANs enabled in the network must meet the Wi-Fi 7 specification requirements to be enabled on firmware version MR 31.1.x and later.

This means that a Wi-Fi 7 SSID configured as described previously cannot coexist with another SSID using WPA2-Personal or WPA3-SAE Transition Mode.

If a WPA2-Personal SSID is configured in the dashboard network, all the Wi-Fi 7 APs would revert to Wi-Fi 6E operation.

This behaviour changes in a future version of firmware MR 32.1.x.

Open / Enhanced Open / OWE / Guest networks

Guest networks come with many flavors. Typically, they require no 802.1X credentials or passphrase to connect, and possibly imply a splash page or portal, which can require credentials or a code. This is traditionally handled with an Open SSID and either local or external guest portal solutions. However, SSIDs with open security (no encryption) are not allowed on 6 GHz or for Wi-Fi 7 support.

A first very conservative approach would be to dedicate guest networks to the 5 GHz band and Wi-Fi 6 at best. This leaves the 6 GHz band reserved for corporate devices, solves the complexity problem and brings maximum compatibility, although not up to Wi-Fi 6E/7 performances.

If, on one side Enhanced Open is a great security method offering privacy while keeping the “open” experience (end users do not need to enter any 802.1X credentials or passphrase), to this day it still has limited support among endpoints. Some clients still do not support it and, even when they do, this technique is not always handled smoothly (the device can show the connection as unsecured, while it actually is secure, or it can display it as passphrase protected, even if no passphrase is needed with OWE). A guest network being expected to work on all guest uncontrolled devices, it can be too early to provide just an Enhanced Open SSID and it is recommended to provide both options through separate SSIDs: an open one on 5 GHz and an OWE enabled one on 5 and 6 GHz, both with the same captive portal behind if this is a requirement too. Transition Mode is not supported on Wi-Fi 6E, 6 GHz (even though it could still be allowed on software) or Wi-Fi 7, so that is not an advised solution. All the portal redirection techniques (web authentication internal or external, Central Web Authentication, …) are still supported with OWE.

OWE configuration on IOS XE 

If we wanted to provide 6 GHz service to guests, the recommendation would be to create a separate SSID with Enhanced Open / OWE (Opportunistic Wireless Encryption). It could offer both AES(CCMP128) cipher, for maximum compatibility up to Wi-Fi 6E clients, as well as GCMP256 bits for Wi-Fi 7 capable clients.

OWE configuration on the Cisco Meraki dashboard

Similar to what was done on IOS XE, the recommendation is to create a separate Guest SSID with Enhanced Open / OWE operating on 6 GHz on the Cisco Meraki dashboard.
This can be configured again in Wireless > Access Control, and selecting 'Opportunistic Wireless Encryption (OWE)' as the Security method.

When running firmware up to MR 31, the only supported WPA type is 'WPA3 only', and the dashboard doesl not let you select a different method.

PMF is mandatory in this configuration, while FT (802.11r) cannot be enabled.

Note that the labelling 'WPA3 only' is overloaded as OWE is not part of the WPA3 standard; however, this configuration refers to OWE without Transition Mode.

OWE Transition Mode is made available as part of a future release of MR 32.1.x.

The AES(CCMP128) cipher is enabled by default for maximum compatibility up to Wi-Fi 6E clients.

GCMP256 bits can be enabled alongside CCMP128 for compliance with Wi-Fi 7 requirements.

Additional WPA3 and related options

While WPA3 options are best described and covered in the WPA3 deployment guide, this section covers some additional recommendations for WPA3 specifically related to 6 GHz and Wi-Fi 7 support.

Beacon protection

This is a feature that solves the vulnerability, where a malicious attacker can transmit beacons instead of the legitimate access point, while modifying some fields to change security or other settings of already associated clients. Beacon protection is an extra information element (Management MIC) in the beacon acting as a signature for the beacon itself, to prove that it was sent by the legitimate access point and that it has not been tampered with. Only associated clients with a WPA3 encryption key can verify the legitimacy of the beacon; probing clients have no means to verify it. The additional information element in the beacon must simply be ignored by clients not supporting it (this refers to non-Wi-Fi 7 clients), and it does not normally cause compatibility issues (unless with a poorly programmed client driver).

This screenshot  shows an example of the content of the Management MIC Information Element:

GCMP256

Until the Wi-Fi 7 certification, most clients implemented AES(CCMP128) cipher encryption. CCMP256 and GCMP256 are very specific variants related to SUITE-B 802.1X AKM. Although some first generations of Wi-Fi 7 clients on the market claim Wi-Fi 7 support, they sometimes still do not implement GCMP256 encryption, which can become an issue if Wi-Fi 7 APs enforcing the standard as expected prevent these clients from connecting without proper GCMP256 support.

When GCMP256 is enabled, the Robust Security Network Element (RSNE) in the Beacon Frames for the WLAN advertises the capability in the Pairwise Chiper Suite List as shown here.

Troubleshoot and verify

The Wireless Configuration Analyzer Express latest version (https://developer.cisco.com/docs/wireless-troubleshooting-tools/wireless-config-analyzer-express-gui/) has a Wi-Fi 7 readiness check that evaluates your 9800 configuration for all the Wi-Fi 7 requirements mentioned previously.

If you still have doubts whether your configuration is Wi-Fi 7 ready, the WCAE lets you know what is wrong.

References

1. Cisco Systems. “WPA3 Encryption and Configuration Guide.” 
2. Meraki WPA3 guide