iOS and macOS 802.1X troubleshooting: a deployment checklist for Intune, Jamf and Entra ID

Apple devices fail 802.1X for four main reasons. The WiFi payload's trusted server names or certificate anchors do not match the RADIUS certificate. The identity certificate is missing or sits in the wrong keychain. A macOS profile runs in the wrong mode, or the profile targets the wrong Entra ID group. The eapolclient and RADIUS logs show which.

What does an 802.1X failure look like on an iPhone or Mac?

Apple devices rarely give a precise error. The symptom itself is your first clue, so record it exactly before you change any profile.

• The iPhone refuses to join an EAP-TLS network and asks for a username and password that should never be needed. The device has no usable identity certificate, so it falls back to a credential prompt.
• The Mac shows a certificate trust dialog naming your RADIUS server. The profile either does not pin server trust, or it allows the person to override a mismatch.
• The Mac connects after sign-in but not at the login window. Network accounts and FileVault unlocks then fail on shared machines.
• Some devices work and others never see the network. This usually points to group scoping, not cryptography.
• Everything worked for months, then failed on one morning. That pattern almost always follows a RADIUS certificate renewal.

What usually causes iPhones and Macs to fail EAP-TLS or PEAP?

Server trust does not match the RADIUS certificate

Apple's WiFi payload pins server trust in two places. Trusted server certificate names must match the name on your RADIUS server certificate. Trusted certificates must include the root that issued it. If either is wrong, the device stops the TLS handshake.

This is why macOS asks you to trust the RADIUS certificate. With no anchor in the profile, Apple hands the decision to the person at the keyboard. With trust pinned and a mismatch, the connection fails silently instead. The Intune WiFi profile server trust guide covers the naming rules in depth.

The identity certificate is missing or in the wrong keychain

EAP-TLS needs a client certificate and its private key on the device. The WiFi payload must reference that certificate, delivered by a SCEP or PKCS payload. On macOS, a device-level profile installs certificates in the System keychain. A user-level profile installs them in the login keychain. A network configured at device level cannot reach a certificate in the login keychain.

macOS system, login-window and user mode are mixed up

macOS supports three 802.1X contexts. System mode connects before anyone signs in, using a machine certificate. Login-window mode uses the credentials typed at the login window. User mode connects only after sign-in, with credentials or a certificate tied to that account. Choose the mode that matches when the Mac needs the network.

Profiles are scoped to the wrong Entra ID group

Microsoft's Intune documentation says to assign the trusted certificate, SCEP or PKCS, and WiFi profiles to the same groups. Assign one to a device group and another to a group of staff accounts, and some devices receive only half the chain. Shared iPads and Macs with no primary account never receive profiles aimed at people.

PEAP against cloud-only Entra ID accounts

PEAP-MSCHAPv2 needs a RADIUS server that can validate the password. Entra ID has no native RADIUS service, so cloud-only accounts usually cannot authenticate this way. Most Entra ID estates move Apple devices to EAP-TLS for this reason.

Symptom	Most likely cause	Evidence to look for	Fix
Trust dialog on Mac	No trusted certificate anchor in the profile	eapolclient shows a trust evaluation failure	Add the RADIUS root as a trusted certificate payload
Silent failure after certificate renewal	Trusted server names no longer match	RADIUS shows the EAP session start, then the client abandons it	Add the new server name and root before rotating
Password prompt on EAP-TLS network	Identity certificate not delivered	No client certificate in the keychain	Assign SCEP or PKCS profile to the same group as the WiFi profile
Works after sign-in, fails at login window	User-mode profile on a shared Mac	Certificate sits in login keychain	Redeploy at device level in system mode
Some devices never see the network	Profiles split across device and account groups	Profile missing from the device's installed list	Align all three payloads to one group
RADIUS reject naming the client certificate	RADIUS does not trust your issuing CA	Reject reason cites the client chain	Add the issuing CA to the RADIUS trust list

How do you work out which cause you have?

Work from the device outwards, in this order.

1. Confirm the profiles arrived. Check the installed profiles list on the device. On a Mac, sudo profiles show lists them from Terminal.
2. Confirm the certificate and private key. Open Keychain Access on a Mac and check the System or login keychain against the profile level.
3. Read the eapolclient log. This tells you whether the device rejected the server.
4. Read the RADIUS log. This tells you whether the server rejected the device.

Where are 802.1X logs on macOS?

macOS hands 802.1X to a process called eapolclient. Open Console, select the Mac, start streaming, and filter on the process name eapolclient. Then reproduce the failure. From Terminal, log show --predicate 'process == "eapolclient"' --last 1h pulls the same entries.

Look for three things: the outer identity sent, the server certificate presented, and the trust evaluation result. A trust failure here means the problem is in your WiFi payload. For an iPhone or iPad, connect it to a Mac and stream its log through Console.

What the RADIUS log tells you

The RADIUS log is the other half of the conversation.

• No request at all. The profile is missing, the SSID name is wrong, or the device never reached the access point.
• The EAP session starts but never completes. The device rejected the server certificate. Return to the trust settings.
• An explicit reject. The server rejected the device. The reason usually names an untrusted client chain, an unknown account or a policy mismatch.

How do you fix it in Intune and in Jamf?

Both platforms deliver the same three Apple payloads. They differ in how they scope and level them.

Task	Microsoft Intune	Jamf Pro
Server trust anchor	Trusted certificate profile	Certificate payload in the configuration profile
Identity certificate	SCEP or PKCS certificate profile	SCEP or Certificate payload
Network settings	WiFi profile (enterprise)	WiFi payload (mobile) or Network payload (computers)
Mac keychain choice	Deployment channel: user or device keychain	Profile level: computer or user
Login-window connection	Device channel with a machine certificate	Computer-level profile set for login window use
Targeting	Entra ID groups	Smart groups and static groups

Intune

Check that the trusted certificate, certificate and WiFi profiles all target the same Entra ID group. On macOS, set every profile to the same deployment channel. Mixing user and device keychains breaks the certificate reference. In the WiFi profile, list every RADIUS server name in certificate server names, and pick the matching root. Microsoft's own deployment guidance documents each field.

Jamf Pro

Build the certificate and network payloads into one computer-level profile for shared Macs. Use user-level profiles only when each person owns the Mac. Point the identity certificate setting at the SCEP or Certificate payload in the same profile. For mobile devices, the WiFi payload offers the same trusted server names and trusted certificates fields.

iPhone and iPad specifics

iOS and iPadOS have no login-window mode. The common failures are trust mismatches and missing identity certificates. Shared and userless iPads need device-group targeting, or they never receive the certificate.

Worked scenarios

A 200-room hotel after a RADIUS certificate renewal

Situation. A 200-room hotel issued Intune-managed iPhones to front-desk and housekeeping teams. The RADIUS certificate was renewed with a new hostname. The next morning, every staff iPhone dropped off the network.

What was done. The eapolclient-equivalent logs from a tethered iPhone showed the device abandoning the handshake. The RADIUS log confirmed sessions that started and never completed. The team added the new hostname to the certificate server names and assigned the new root to the same group.

Outcome. Devices reconnected as each one synced the updated profile, and failed authentications on the staff SSID dropped to zero that day. The team now publishes trust changes a week before any renewal. See how hotels run staff and guest networks on our Hotels page.

A council library service with shared Macs

Situation. A public-sector library service ran 60 shared Macs through Jamf Pro. The WiFi profile was user-level, so the certificate landed in the login keychain. New staff could not sign in at all, because their network accounts needed the network first.

What was done. The team rebuilt the profile at computer level in system mode, with a machine certificate in the System keychain.

Outcome. The Macs reached the network at the login window, and first-login failures stopped across all 60 machines. The same change unblocked overnight patching, which had also depended on a signed-in session.

How do you stop it happening again?

Most Apple 802.1X outages are self-inflicted during change. A short discipline prevents nearly all of them.

• Pin trust deliberately. Always specify trusted server names and a trusted root, so a mismatch fails loudly in testing rather than prompting staff.
• Stage certificate rotations. Add the new server name and root to the profile before you renew the RADIUS certificate. Remove the old ones afterwards.
• Keep the chain in one group. Trusted certificate, identity certificate and WiFi profile should always share a target.
• Match the mode to the device. Shared Macs use system mode. Personally assigned Macs can use user mode.
• Pilot first. Push profile changes to a small ring of iPhones and Macs, and check eapolclient and RADIUS logs before wider release.
• Automate joiners, movers and leavers. Certificate revocation should follow the directory, not a ticket queue.

Purple Staff WiFi delivers this through Identity-Based Networks. Our cloud RADIUS ties network access to Microsoft Entra ID, Okta or Google Workspace, so access follows group membership. Purple is hardware-agnostic. It runs on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. Purple is ISO 27001 certified and serves 80,000+ live venues (Purple's own data). The same identity approach applies across Retail, Healthcare and Trains.

For Android fleets, the Android 802.1X and EAP-TLS troubleshooting checklist covers the equivalent checks. For directory sign-in, read How to Enable Single Sign On.

Frequently asked questions

Does Purple Staff WiFi work with devices managed by Intune and Jamf?

Yes, Purple Staff WiFi authenticates Apple devices that receive their WiFi and certificate profiles from Intune or Jamf Pro. Your device management platform delivers the payloads, and Purple's cloud RADIUS validates the connection against Microsoft Entra ID, Okta or Google Workspace. You keep your existing device management tooling. Purple handles authentication and ties access to group membership, so leavers lose access when their directory account is disabled.

Do we need new access points to run certificate-based staff WiFi?

No, Purple is hardware-agnostic and layers on top of your existing network. Purple supports Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. Your access points need to support WPA2-Enterprise or WPA3-Enterprise and point at an external RADIUS server. For SecurePass, check the Passpoint requirements in our Security and Hardware Compatibility article.

Should we use EAP-TLS or PEAP for iPhones and Macs on Entra ID?

Use EAP-TLS. PEAP-MSCHAPv2 needs a RADIUS server that can validate the password, and Entra ID has no native RADIUS service for cloud-only accounts. EAP-TLS authenticates with a certificate that Intune or Jamf delivers automatically, so nobody types a password. It also removes credential prompts, which are one of the most common sources of Apple 802.1X helpdesk tickets.

Can we migrate from a pre-shared key without disrupting staff?

Yes, you can run the new 802.1X SSID alongside your existing pre-shared key network during migration. Push the trusted certificate, identity certificate and WiFi profiles to a pilot group first. Check the eapolclient and RADIUS logs, then widen the scope in stages. Retire the pre-shared key network only when RADIUS shows every device group authenticating successfully.

How does certificate-based WiFi affect GDPR and data handling?

Certificate-based WiFi reduces the personal data that crosses the network, because no password is transmitted. Authentication relies on a device certificate and directory group membership. Purple is GDPR compliant and holds ISO 27001, Cyber Essentials and B Corp certification. You should still record the RADIUS logs you retain and their retention period in your data protection documentation.

Does SecurePass replace 802.1X for staff devices?

No, SecurePass is designed for visitors, not managed staff devices. It replaces repeated captive portal logins with a digitally signed WiFi profile installed once in around 30 seconds, using WPA2 or WPA3-Enterprise. It runs alongside your existing portal. Staff devices should use Staff WiFi with certificates delivered by Intune or Jamf. See the SecurePass FAQ for detail.