Before approving the next municipal WLAN architecture review, security leadership wants a written allowlist of AKM suites (for example SAE and 802.1X-SHA256) that APs may advertise. Why does that policy artifact matter?
Select an answer to reveal the explanation.
Short Explanation
If it isn’t on the allowlist, it shouldn’t show up in the beacon. Writing down permitted AKMs—SAE, solid Enterprise suites, and friends—stops “temporary” weak suites from becoming permanent city policy by accident.
Full Explanation
Before approving the next municipal WLAN architecture review, a written allowlist of AKM suites—for example SAE and 802.1X-SHA256—matters because it documents which AKM components and processes are permitted by policy so design and operations cannot silently re-enable weaker suites. The artifact turns tribal knowledge into enforceable configuration gates for beacons, templates, and change control. Without it, temporary compatibility suites tend to become permanent city settings that auditors rediscover years later. An allowlist does not replace the need for RSN information in beacons; clients still read the air, not a PDF on SharePoint. It should not force every SSID to use the same global PSK regardless of Personal or Enterprise intent. It is not merely a purchasing checklist for AP antennas with no AKM meaning for security architecture. Exam caveat: allowlists must be versioned and mapped to SSID classes such as staff, guest/OWE, and IoT, because one flat list rarely fits every civic use case without creating harmful exceptions. Operational check: compare each production SSID’s advertised AKM suites to the current allowlist during architecture review, open remediation tickets for any unauthorized suite, and require allowlist updates through the same governance path as other security standards.