Skip to main content
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.

Configure EAP-TLS

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:
  • Client authentication EKU
  • Any purpose EKU
  • All purpose EKU

Configure EAP-TTLS

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.

Configure EAP-PEAP

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.

Configure EAP-TEAP

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.

Configure EAP-SIM

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.
3

Hide permanent subscriber identity (IMSI) (optional)

Configure Hide permanent subscriber identity (IMSI) to prevent revealing the IMSI when a pseudonym identity exists from previous authentications.
4

Configure provider and realm (optional)

  • Provider name (limits authentication to SIMs matching this provider)
  • Realm configuration (controls the realm used when sending identity to the server)

Configure EAP-AKA

EAP-AKA uses USIM-based authentication, commonly used in mobile carrier and SIM-enabled enterprise deployments.
1

Select EAP Type

Select AKA under Accepted EAP Types.
2

Hide permanent subscriber identity (IMSI) (optional)

Configure Hide permanent subscriber identity (IMSI) based on whether you want the IMSI protected when pseudonyms exist.
3

Configure provider and realm (optional)

  • Provider name
  • Realm configuration

Configure EAP-AKA’

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.
4

Hide permanent subscriber identity (IMSI) (optional)

Configure IMSI protection settings if required by your environment.
5

Configure provider and realm (optional)

  • Provider name
  • Realm configuration

Recommendations & Best Practices

  • 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.