A clinic staff SSID uses PEAP with MSCHAPv2 as the inner method. What weakness class should assessors recognize at concept level?

When a clinic staff SSID uses PEAP with MSCHAPv2 as the inner method, assessors should recognize at concept level that MSCHAPv2 inner authentication has known weakness classes if challenge and response credential material is obtained under suitable conditions, especially when combined with evil-twin or validation failures. PEAP-MSCHAPv2 is not cryptographically identical to EAP-TLS client certificates, which avoid password-based inner methods when properly deployed. MSCHAPv2 inner methods do not make evil-twin attacks impossible; weak client trust settings can still expose inner material. PEAP does not remove the need for server certificate validation forever—validation remains a primary control against rogue authenticators. Exam caveat: discuss weakness classes and conditions without turning the explanation into an exploit recipe; OSWP-aligned items test recognition, not payload steps. Operational check: inventory municipal EAP methods, flag PEAP-MSCHAPv2 for risk discussion, and verify whether endpoints enforce server certificate checks before recommending passwordless or TLS upgrades. For municipal and campus engagements, keep the finding language tied to authorized scope, name the building or SSID class affected, and state the residual risk to residents or staff if the rejected option had been chosen. Re-validate after the next change window that the selected control still matches inventory, monitoring, and RoE abort criteria used by the city wireless program.