EAP-TEAP requirements, limitations, and FAQ

In this topic, you will learn about the requirements and limitations of EAP-TEAP support in Portnox™ Cloud, and find answers to frequently asked questions.

For general background on how EAP-TEAP works, see the following topic: EAP methods and their security. For instructions on enabling EAP-TEAP support in Portnox Cloud, see the following topic: Configure advanced RADIUS server options.

Which operating systems support EAP-TEAP?

The EAP-TEAP protocol is currently supported only by Windows 10 and Windows 11. This limitation is imposed by the operating system, not by Portnox, and applies to all NAC solutions, not only Portnox Cloud. It is not supported at all on macOS or on mobile operating systems.

For Linux: Support for EAP-TEAP exists in the source code of wpa_supplicant, the software most Linux distributions use for 802.1X authentication, but no mainstream Linux distribution ships a build with EAP-TEAP support compiled in. Users who want EAP-TEAP support on Linux would need to compile wpa_supplicant themselves with this option enabled.

Can AgentP configure or provision devices for EAP-TEAP?

Not currently. Configuration must be performed locally on the device, through Group Policy, or through your organization’s MDM solution.

Which MDM/UEM solutions support configuring EAP-TEAP on devices?

Microsoft Intune supports configuring EAP-TEAP for wired connections directly. For wireless connections, you must configure TEAP settings on a reference device first, export them as an XML profile, and upload that profile to Intune.

Other MDM/UEM solutions that support EAP-TEAP for Windows rely on a similar XML-based method. Since EAP-TEAP is a Windows-only authentication method, MDM solutions built for other platforms only, such as Jamf or Iru, do not support it.

In most implementations, EAP-TEAP is configured on devices using Group Policy.

What happens if either of the two authentication methods in EAP-TEAP fails?

Portnox Clouds treats this failure exactly the same way as with other EAP methods. The device is treated according to your authentication failure policy, for example moved to quarantine or assigned a restrictive access control list.

Can I require a certificate first, and fall back to credentials if no certificate is available?

Yes. Configure the certificate-based method (typically Machine Authentication, using EAP-TLS) as required, and the credential-based method (typically User Authentication, using PEAP-MSCHAPv2) as optional.

Because the credential-based inner method is PEAP-MSCHAPv2, this configuration is only usable when your authentication repository is Active Directory. PEAP-MSCHAPv2 is not supported with cloud repositories such as Entra ID, Google Workspace, or Okta. For more information, see the following topic: EAP methods and their security.

Can I control which credential, certificate or password, is checked first?

Yes. The Primary method is always checked first, and the Secondary method, if configured, is checked next.

Set the primary method to whichever credential you want checked first, then add the other credential type as the secondary method, and define whether it is required or optional.