Configure EAP types for Windows Wi-Fi authentication
This guide applies to Windows devices
Numerous options are available for authenticating to Wi-Fi networks, especially if your infrastructure supports more than one authentication method. Each method has unique settings you need to configure. This article covers the most common EAP configuration options available in the Configure the Wi-Fi Library Item for Windows.
Your network infrastructure must support the selected EAP type and be configured correctly to allow authentication. If you do not know how your network is configured, work with your network administrators to confirm how they want network clients to authenticate.
When you select Enterprise Wi-Fi in Iru Endpoint, Identity certificate and Certificate trust settings always appear in the UI, regardless of which EAP type you select. These fields are not required, and in some EAP types they do not apply. If your EAP type does not use certificates, you can leave these fields blank.
EAP-TLS uses Transport Layer Security and an identity certificate to authenticate the device to the network.
You must provide an identity certificate to use EAP-TLS.
1
Select EAP Type
Select TLS under Accepted EAP Types.
2
Choose credential source
Under Credential source, choose how the client should locate the identity certificate.
Most deployments use Certificate Store.
3
Enable simple certificate selection (recommended)
Enable Simple certificate selection so Windows automatically selects the correct certificate during authentication.
If disabled, users may be prompted to choose from available certificates.
4
Configure server validation (recommended)
Configure the validation options based on how your RADIUS/certificate infrastructure is deployed:
Perform server validation (recommended for production)
Disable user prompt for server validation
Accept server name
5
Configure EKU filtering (optional)
If your environment uses EKU filtering, configure:
Tunneled Transport Layer Security (TTLS) uses a TLS tunnel to encrypt another authentication protocol. It typically does not require an identity certificate, and most deployments authenticate using a username and password (or device credentials depending on infrastructure).
1
Select EAP Type
Select TTLS under Accepted EAP Types.
2
Enable identity privacy (optional but recommended)
If your infrastructure supports identity privacy, enable Enable identity privacy.
When enabled, the client sends an anonymous outer identity during the initial exchange and only reveals the real identity inside the encrypted tunnel.
3
Configure server validation (recommended)
Configure:
Perform server validation
Disable user prompt for server validation
Accept server name
4
Configure inner authentication
Under Inner authentication, select the authentication protocol that will be used inside the TLS tunnel (as required by your RADIUS configuration).
Identity certificate settings may appear in the UI but are not typically used for TTLS unless your infrastructure explicitly requires a certificate.
Protected Extensible Authentication Protocol (PEAP) uses a TLS tunnel to protect credentials exchanged using an inner authentication method. Like TTLS, PEAP typically does not require an identity certificate, and most commonly uses username/password authentication inside the tunnel.
1
Select EAP Type
Select PEAP under Accepted EAP Types.
2
Configure optional PEAP behavior
Depending on your environment, configure:
Enable fast reconnect (improves roaming performance)
Require cryptobinding (recommended when supported; helps protect against some tunneling attacks)
Enable NAP quarantine checks (legacy; usually disabled in modern deployments)
3
Control trust behavior for untrusted server certificates (recommended)
Configure Allow user to accept untrusted server certificates.
If enabled, users may be prompted when the server CA is not trusted.
If disabled, the connection will fail automatically if the server cannot be validated.
4
Configure server validation (recommended)
Configure:
Perform server validation
Disable user prompt for server validation
Accept server name
5
Enable identity privacy (optional but recommended)
Enable Enable identity privacy if your deployment supports anonymous outer identities.
6
Configure inner authentication
Select an Inner authentication method based on your RADIUS requirements.
PEAP typically does not use an identity certificate, even though the identity certificate fields may appear.
Tunneled EAP (TEAP) is a modern tunneled EAP method that supports multiple inner authentication mechanisms and stronger extensibility than PEAP/TTLS. Many TEAP deployments authenticate using username/password, certificates, or a combination.
1
Select EAP Type
Select TEAP under Accepted EAP Types.
2
Configure trust behavior for manually accepted server certificates (optional)
Configure Auto-trust servers accepted by the user.
If enabled, when a user manually accepts a server certificate and the connection succeeds, additional roots pushed by the server can be added to the trusted CA list.
3
Configure server validation (recommended)
Configure:
Perform server validation
Disable user prompt for server validation
Accept server name
4
Enable identity privacy (optional)
Enable Enable identity privacy if supported by your infrastructure.
5
Configure inner authentication
TEAP can use multiple inner methods. Configure:
Primary inner authentication
Secondary inner authentication (optional)
Some TEAP deployments may use identity certificates, depending on your authentication strategy. If your TEAP deployment does not use certificates, you can leave certificate fields blank.
EAP-SIM uses a SIM card for authentication. It is commonly used in carrier or enterprise environments that use SIM-based identity for access control.
1
Select EAP Type
Select SIM under Accepted EAP Types.
2
Require strong cipher keys (optional)
Configure Require strong cipher keys to require stronger encryption keys (three RANDs).
If this is not configured, either two or three RANDs may be allowed depending on server behavior.
EAP-AKA’ is an enhanced version of EAP-AKA with improvements to identity binding and key derivation. It is used in some modern SIM-based deployments.
1
Select EAP Type
Select AKA’ under Accepted EAP Types.
2
Validate network name from server (optional)
Configure Validate network name from server to control whether the client verifies the network name it expects against what is advertised by the server.
3
Enable fast reauthentication (optional)
Configure Enable fast reauthentication to allow shorter, faster AKA’ exchanges when possible.
If disabled or not configured, every connection will use full authentication.
Use server validation whenever possible. Disabling validation or allowing untrusted server certificates increases exposure to credential interception and man-in-the-middle risks.
Enable identity privacy when available, especially in TTLS/PEAP/TEAP environments.
Only use EAP-SIM / AKA / AKA’ when your organization supports SIM/USIM-based identity authentication. These are uncommon in standard enterprise Wi-Fi deployments.
If you are unsure which EAP type to use, consult your Wi-Fi/RADIUS team to confirm what methods are enabled on your infrastructure.