CWSR common mistakes
CWSR · Understand the traps and how to avoid them.
Treating WEP, WPA, WPA2, and WPA3 as a simple progression where each newer label automatically means 'secure,' and answering questions as if WPA2-Personal and WPA2-Enterprise offer equivalent protection.
Candidates memorize version names and dates instead of the underlying mechanisms: WEP's RC4 with weak IVs, WPA's TKIP with per-packet key mixing as a stopgap, WPA2's CCMP/AES, and WPA3's SAE and 192-bit suite. They also blur the Personal (PSK) versus Enterprise (802.1X) split, so they miss why PSK networks are vulnerable to offline dictionary attacks on captured handshakes while Enterprise networks shift risk to credential and certificate handling.
What to do instead
Build a one-page comparison matrix: cipher and integrity mechanism, key hierarchy, authentication mode, known attack class, and minimum hardware era for each of WEP, WPA, WPA2-Personal, WPA2-Enterprise, WPA3-Personal (SAE), WPA3-Enterprise, and WPA3-192-bit. For every practice question, first classify the scenario by authentication mode before evaluating the encryption claim.
Confusing the 802.11 management, control, and data frame classes and misidentifying which frames are protected under 802.11w (Management Frame Protection) and which are not.
Candidates learn that 'management frames are unprotected' as a blanket statement and then apply it to all frames, missing that PMF protects specific robust management frames such as deauthentication, disassociation, and certain action frames, while beacon and probe frames remain unprotected by design. They also conflate PMF with encryption of the payload.
What to do instead
Memorize the robust management frame list and the difference between PMF capable and PMF required. Practice classifying frames: beacon, probe request/response, authentication, association, deauth, disassoc, action, and data. For each, state whether it is encrypted, integrity-protected, or open, and note that 802.11w prevents forgery of protected frames but does not hide SSIDs or encrypt beacons.
Mixing up the four-way handshake, the group key handshake, and the 802.1X EAP exchange, and attributing the wrong keys or messages to each phase.
The key hierarchy (PSK or MSK feeding the PMK, then the PTK and GTK, with the ANonce and SNonce) is abstract, so candidates collapse it into 'the client authenticates and then traffic is encrypted.' They then misplace where the pairwise key is derived, where the group key is delivered, and where the EAP success message sits relative to the handshake.
What to do instead
Draw the sequence from memory: 802.1X/EAP exchange producing the MSK, PMK derivation, four-way handshake with ANonce/SNonce/MIC/install, then the group key handshake. Label which messages are protected by which key (KCK, KEK) and where replay protection and the GTK rekey fit. Re-draw it weekly until the order is automatic.
Selecting EAP methods by name recognition rather than by their security properties, for example recommending LEAP or EAP-MD5 in a new design, or assuming PEAP and EAP-TTLS validate the client with certificates by default.
Candidates group all EAP methods as '802.1X authentication' and miss the distinctions: EAP-TLS requires certificates on both sides, PEAP and EAP-TTLS create a TLS tunnel that protects an inner method but server-side certificate validation must be enforced and client credentials may be password-based, while EAP-MD5 and LEAP lack mutual authentication and are deprecated. They also overlook that without strict server certificate validation, the tunnel is vulnerable to an evil twin RADIUS server.
What to do instead
Create a table of EAP-TLS, PEAPv0/EAP-MSCHAPv2, EAP-TTLS, EAP-FAST, EAP-SIM/AKA, EAP-MD5, and LEAP with columns for mutual authentication, server certificate required, client certificate required, tunneled inner method, and known weaknesses. For design questions, default to EAP-TLS where certificate management is feasible and require server certificate validation with a trusted CA and name checking for any tunneled method.
Treating RADIUS as a simple password check and ignoring shared secrets, attribute handling, proxy chains, and the accounting versus authentication roles.
Candidates reduce RADIUS to 'the server that says yes or no' and then cannot reason about why a weak shared secret between the authenticator and the RADIUS server is a serious risk, how Access-Challenge and tunneled attributes work, or how RADIUS proxying and realms affect trust boundaries and logging.
What to do instead
Study the RADIUS message flow: Access-Request, Access-Challenge, Access-Accept, Access-Reject, Accounting-Request. Note that the shared secret authenticates the authenticator and protects certain attributes but does not encrypt the whole packet, and that EAP payloads inside RADIUS rely on the EAP method's own tunnel. Review how realms and proxies extend the trust boundary and why accounting records matter for incident response.
Assuming that deploying WPA2-Enterprise or WPA3 automatically secures the WLAN, and failing to identify residual risks such as rogue APs, evil twins, unmanaged supplicants, and misconfigured SSIDs that bypass the intended policy.
Candidates equate strong cryptography with a complete security posture. They overlook that a strong protocol on a misconfigured or rogue infrastructure still yields compromise, and they miss risk-assessment framing such as threat modeling, asset classification, and likelihood-impact reasoning that the exam expects in scenario questions.
What to do instead
Practice writing short risk statements in the form asset, threat, vulnerability, likelihood, impact, and control. For any scenario, ask separately whether the protocol is strong, whether the infrastructure is trustworthy, and whether the client configuration enforces the policy. Include rogue AP detection, WIPS coverage, and supplicant hardening as distinct control categories.
Conflating certificate roles in the WLAN PKI: using the same certificate for RADIUS server authentication and client authentication, ignoring the trust chain and CRL/OCSP revocation, or forgetting that the supplicant must trust the issuing CA.
Candidates see 'certificate' as a single concept and do not separate server certificates, client certificates, and the CA hierarchy. They then miss why an expired or revoked server certificate should cause the supplicant to fail authentication, or why a private CA requires distributing the root to clients and servers.
What to do instead
Map the PKI end to end: root CA, intermediate CA, server certificate with the correct SAN and EKU for server authentication, client certificates with client authentication EKU, and revocation via CRL or OCSP. Trace what each party validates and what happens on failure. Practice questions about certificate expiry, name mismatch, and revocation during an incident.
Treating WLAN monitoring as 'look at the controller dashboard' and failing to distinguish the roles of WIPS, spectrum analysis, and protocol analysis, or to describe a defensible incident response sequence for a wireless event.
Candidates do not separate detection technologies: WIPS classifies threats such as rogue APs, honeypots, and deauth floods; spectrum analysis addresses RF interference; protocol capture addresses frame-level behavior. Without that separation, incident response answers become vague and skip containment, evidence preservation, and eradication steps.
What to do instead
Learn the detection categories and the sensor placement model (overlay versus integrated AP sensors). For incident response, rehearse a fixed sequence: detect and classify, contain by locating and disabling the rogue device or isolating the client, preserve captures and logs with timestamps, eradicate and remediate, then recover and document lessons. Tie each step to a specific wireless artifact such as a BSSID, channel, or RADIUS log entry.
Designing guest and BYOD access as 'open SSID with a captive portal' without addressing client isolation, bandwidth and ACL restrictions, onboarding of personal devices, or the risk of guest traffic reaching internal resources.
Candidates focus on the user experience of getting guests online and skip the segmentation and policy questions. They also miss the BYOD lifecycle: registration, device profiling, certificate or credential provisioning, posture checks, and offboarding. As a result they cannot explain why guest traffic should be tunneled to a dedicated DMZ or why client isolation matters on a shared SSID.
What to do instead
Design guest and BYOD as separate SSIDs mapped to separate VLANs with ACLs that deny internal subnets, client isolation enabled, rate limiting, and a captive portal with terms and sponsorship where appropriate. For BYOD, describe onboarding with certificate enrollment, device inventory, posture or MDM integration, and a defined offboarding step that revokes credentials and certificates.
Answering policy and compliance questions with generic statements such as 'follow best practices' or 'comply with the standard' instead of naming the specific control, the standard family, and the evidence that demonstrates compliance.
Candidates memorize framework names without knowing what each one actually requires of a wireless program, so they cannot map a requirement to a control or an artifact. They also forget that policy must be enforceable and auditable, with defined ownership, review cycles, and exception handling.
What to do instead
For each framework family you are likely to see, write one sentence on its scope and two wireless-relevant controls. Then practice mapping a control to concrete evidence: an SSID inventory, a configuration baseline, a RADIUS authentication log, a vulnerability scan report, or a change record. Include policy elements such as acceptable use, key and credential rotation, exception approval, and periodic review.