EAP Method Selection for Managed, BYOD, and IoT Devices

The method should follow device capability, not a single university-wide preference.

Managed Windows/macOS laptops: EAP-TLS. These devices can receive client certificates from the internal CA through GPO or JAMF. EAP-TLS gives per-device identity, avoids reusable passwords, and supports certificate revocation. Because the supplicant can validate the RADIUS server certificate against the internal root CA and the configured SAN, it also resists evil-twin attacks. Operationally, autoenrollment and renewal must be designed before rollout, or expired certificates will cause helpdesk spikes.

BYOD phones/tablets: EAP-TTLS or PEAP with a strong inner method, but only with mandatory server validation and onboarding. The CIO wants no reusable passwords, but most BYOD devices cannot receive a corporate certificate without an onboarding step. The realistic options are: (a) use EAP-TTLS with an inner method that carries an OTP or a short-lived credential, or (b) use PEAP-MSCHAPv2 but require a managed supplicant profile that pins the RADIUS server name and root CA. Option (b) still uses an AD password, so it does not fully meet the CIO’s goal. A better judgment is to deploy a BYOD onboarding flow that issues a device certificate via SCEP/EST after the user authenticates once, then move the device to EAP-TLS. Until that is ready, do not leave PEAP-MSCHAPv2 in place without server-validation enforcement; the audit finding is specifically about missing validation.

IoT devices: WPA2-Personal with unique per-device PSKs if the infrastructure supports it, otherwise isolated WPA2-Personal with compensating controls. These devices cannot do 802.1X and should not be forced onto a user SSID. Use a separate IoT SSID/VLAN, per-device PSK or group PSK by device type, ACLs to only required destinations, and NAC profiling. Treat this as a documented exception to the no-password goal, not as an acceptable user authentication method.

Therefore, the design is EAP-TLS for managed laptops, certificate-based BYOD after onboarding, and isolated PSK-based IoT with segmentation.

The audit finding is not solved by changing the EAP method alone; it is solved by making the client prove it is talking to the real RADIUS server and by removing reusable secrets where possible.

Server-side controls:

• Issue RADIUS server certificates from the internal Enterprise CA with a SAN that exactly matches the realm clients are configured to use (for example, radius.university.edu).
• Configure each RADIUS server with the same certificate and require EAP server certificate validation.
• Publish the root CA to managed devices by GPO/JAMF and to BYOD devices through the onboarding profile.
• Enable CRL or OCSP checking so a revoked server certificate cannot be used.

Client-side controls:

• For managed laptops, push a wireless profile that sets “Validate server certificate,” specifies the trusted root CA, and restricts the server name. Do not allow users to bypass the warning.
• For BYOD, use an onboarding app or MDM profile that installs the root CA and the wireless profile before the device joins the corporate SSID. If the device cannot be managed, require a manual profile install and test it.
• Disable PEAP-MSCHAPv2 on any SSID where the supplicant cannot validate the server certificate. If PEAP must remain temporarily, pair it with a supplicant that prompts only after successful server validation and train the helpdesk to treat certificate warnings as failures.

Certificate lifecycle:

• Use autoenrollment for managed devices, short-lived BYOD certificates (for example, one year), and automated renewal reminders.
• Monitor CA issuance and revocation for anomalies, such as a spike in certificates issued to unknown device names.
• Test the evil-twin scenario with a rogue RADIUS server using a certificate from a public CA; the client must reject it because the root CA and server name do not match.

This combination reduces the likelihood of credential theft because the client will not send credentials to an unvalidated server, and it reduces impact because EAP-TLS credentials are per-device and revocable.

The CIO’s goal is achievable, but only if BYOD onboarding is treated as a certificate-provisioning workflow, not as a guest captive portal.

Recommended flow:

1. The user connects to a registration SSID that is isolated and has no access to internal resources.
2. The registration portal authenticates the user with an enterprise identity provider-SAML/OIDC to the university’s IdP-or with a one-time code issued by the helpdesk. This is a one-time authentication, not a reusable WLAN password.
3. After authentication, the portal provisions a device certificate through SCEP/EST and installs the root CA and wireless profile on the device. The profile includes the corporate SSID, EAP-TLS settings, and server-name validation.
4. The device reconnects to the corporate SSID using EAP-TLS. The registration SSID does not permit general network access.
5. Access is role-based: BYOD devices can reach student/staff services but not administrative VLANs. NAC can posture-check the device and enforce OS updates or screen lock.

Why this does not weaken security: The user’s identity is proven once during onboarding, but the WLAN credential is a per-device certificate that can be revoked if the device is lost or the user leaves. There is no shared PSK and no reusable WLAN password. The risk shifts to the onboarding portal, so protect it with MFA, rate limiting, and monitoring for bulk certificate issuance.

Fallback: If the device cannot support certificate provisioning, place it on a limited BYOD network with captive-portal authentication and no internal access. Do not silently fall back to PEAP-MSCHAPv2 on the corporate SSID, because that recreates the audit finding.