Skip to main content
A Dot1x Context’s Client Authentication Methods card has two independent master switches — EAP-PEAP and EAP-TLS. They’re not exclusive. Turning both on lets you run certificate-based Groups (for employees on MDM-enrolled devices) and password-based Groups (for audiences whose identities aren’t cert-backed — contractor firms, event staff, flex-workforce, student cohorts) side-by-side on one Context, with shared RADIUS endpoint, IP allow-list, Attribute Profiles, and audit log. The method is chosen per-Group. A Context with both methods enabled opens all three Group types in the Create Group dropdown:
  • 802.1X-PEAP — usernames and passwords for populations outside your Entra tenant.
  • 802.1X-TLS with User Certificate — per-user certs for employees mapped to Entra user groups.
  • 802.1X-TLS with Device Certificate — per-device certs for unattended equipment, with embedded MAB fallback.

​
The typical mixed Context

Most Organizations running EAP-TLS-with-Entra also have at least one non-Entra audience. The combined deployment shape tends to look like:
  • Employees on Intune-enrolled laptops. EAP-TLS User Certificate Groups mapped to Corporate Staff, Finance, Engineering.
  • Unattended kiosks and factory workstations. EAP-TLS Device Certificate Groups mapped to Managed Laptops (for the compliant fleet), Reception Kiosks, Factory Workstations. MAB Device List inside each of the Device-Cert Groups covers the printers, phones, and sensors on the same infrastructure.
  • Audiences without cert-backed identities. EAP-PEAP Groups named per audience — the employer’s Corporate Staff Group mapped to Entra; contractor firms like Acme Consulting or HVAC Contractors with local Personal PEAP Accounts; timeboxed cohorts like Summer Interns 2026. Each Group’s lead self-administers their own roster. See EAP-PEAP overview.
One Context. One RADIUS endpoint. One secret to coordinate. Three audiences served cleanly.

​
Turning both methods on

If the Context was created with only EAP-PEAP enabled and you want to add EAP-TLS (or vice versa):
1

Open Configuration → Basic Configuration

From the Context’s configuration surface.
2

Toggle the missing method in Client Authentication Methods

The master switch. Leave the existing one on.
3

Click Update Authentication Methods

Saves. New Group types become available in the Create Group dropdown from this point.
4

Prepare the method-specific prerequisites

  • For EAP-TLS: upload at least one Trusted CA to the Context and (if new) set the Identity Store to Microsoft Entra ID. See Trusted certificates and Entra connection.
  • For EAP-PEAP: pick the Identity Store (either local or Entra — for contractors, local is the usual answer). See EAP-PEAP overview.
Turning a method off later is also safe — existing Groups that used the method become unreachable (no authentication succeeds against them) but aren’t deleted. Useful when migrating a population from PEAP to EAP-TLS: flip the PEAP Groups to EAP-TLS (or delete the Groups and recreate), then turn PEAP off when the population’s moved.

​
Identity Store sharing

Both methods share the Context’s Identity Store configuration:
  • When the Identity Store is Microsoft Entra ID, both methods authenticate against Entra — PEAP validates the user’s Entra credentials, EAP-TLS maps the certificate’s bearer to an Entra user or device.
  • When the Identity Store is No Backend Identity Store, only PEAP Groups work (they use local Personal PEAP Accounts); EAP-TLS Groups have nowhere to resolve their certs.
For the mixed shape above — employees on Entra-mapped certs, contractors on local PEAP — you pick Microsoft Entra ID as the Identity Store. PEAP Groups for the contractors still create local Personal PEAP Accounts because they aren’t mapped to any Entra group.

​
Attribute Profile reuse

A Profile is Context-scoped. The same VLAN 210 — Acme profile attached to an Acme Consulting PEAP Group can also attach to a Device-Cert Group for Acme’s on-site kiosks if those kiosks should share the VLAN. Profiles don’t know what method a Group uses — they’re the RADIUS response, not the authentication mechanism. This is especially useful for staged migrations. A firm starts on PEAP (no MDM onboarding), then later migrates specific managed devices onto certificate authentication. Reuse the Profile, and the VLAN treatment stays consistent through the migration.

​
Operational coordination

  • The per-Context RADIUS shared secret is shared across methods. Rotating the secret affects every attached WLAN controller and switch, regardless of which Group type they serve. Plan the rotation during a change window that spans every audience.
  • Trusted CA rotation is EAP-TLS-only. PEAP Groups aren’t affected.
  • Entra API Status failure affects both methods. If the Identity Store’s Entra credentials expire, both PEAP-Entra and EAP-TLS Groups fail until the secret is rotated. See Entra connection.
  • Audit Log aggregates. Every Group change, regardless of method, lands in the Context’s Audit Log — so change-management review sees the whole picture at once.

EAP-PEAP overview

Password-based 802.1X with delegated per-firm Self-Service.

Entra group mapping

The one-to-one Group-to-Entra-group shape for EAP-TLS.

Attribute Profiles

Reuse one Profile across PEAP, TLS, and MAB Groups.

RADIUS clients

One Context, one RADIUS endpoint, one shared secret.