Sophos AP6: Wi-Fi sign-in with Microsoft Entra ID
Many organisations already manage their users in Microsoft Entra ID. Yet their corporate Wi-Fi still relies on a dedicated authentication server, sometimes alongside a local Active Directory that is barely needed for anything else. The new Wi-Fi sign-in integration with Microsoft Entra ID for Sophos AP6 addresses precisely this situation: existing cloud identities can also be used to access the wireless network.
Sophos introduced the feature with AP6 MR10, version 1.10.3192. It is configured in Sophos Fusion Wireless, the management platform previously known as Sophos Central. Our overview of Sophos Fusion explains the name change and its relationship with existing products.
The feature can reduce the need for local infrastructure. Whether it can replace an existing Wi-Fi authentication setup depends on the devices in use, identity policies and required network functions. Certificate-based device authentication and dynamic VLANs, in particular, warrant a closer look before a migration.
What changes for Wi-Fi access
A shared Wi-Fi password is quick to distribute but difficult to manage in everyday use. When someone leaves the organisation, their devices still know the password. Changing it affects every other device as well. An Enterprise Wi-Fi network, by contrast, provides access based on individual identities.
The new AP6 integration connects Microsoft Entra ID as an identity provider, or IdP. This workflow does not require a dedicated local RADIUS or NPS server. RADIUS is the service that traditional Enterprise Wi-Fi networks often use to check credentials and assign access rules.
The Sophos MR10 announcement explicitly describes the integration as a way to avoid local authentication infrastructure. This is useful for organisations with cloud identities and straightforward Wi-Fi requirements. An Entra account alone, however, does not guarantee successful sign-in on every device.
Requirements for Sophos AP6 and Microsoft Entra ID
Management, firmware and licensing
AP6 access points managed in Sophos Fusion are required, along with firmware that supports the Entra integration. MR10 is the version in which Sophos introduced the feature. For a new installation, check the currently approved firmware release rather than choosing an older version solely for this feature. The AP6 firmware update guide explains how to prepare and verify a staged rollout.
Every centrally managed AP6 requires a valid AP6 Support and Services Subscription. This includes management through Sophos Fusion and firmware updates, among other services. An AP6’s local web interface does not replace this cloud integration. The AP6 management and licensing overview explains the differences.
The centrally configured identity providers in this workflow are intended for AP6 SSIDs. AP6 support does not imply an equivalent commitment for APX or Wi-Fi managed by Sophos Firewall. Sophos documents this scope on its RADIUS page.
Entra tenant and app registration
The intended users must exist in Entra ID. An app registration for the organisation’s own tenant, a verified custom domain and permission to grant the required admin consent are also needed.
The connection requires Client ID, Tenant ID, domain name and Client Secret. Sophos specifies the Microsoft Graph permissions Domain.Read.All of type Application and User.Read of type Delegated. The setup guide reviewed does not specify an additional Entra ID P1 or P2 requirement; licensing requirements for the organisation’s identity policies must be checked separately.
The client secret needs an owner and a scheduled renewal date. A working setup on day one is not enough if nobody monitors its expiry date later. The complete setup is described in the KB guide to AP6 authentication with Entra ID.
Suitable Wi-Fi profiles on client devices
For this integration, Sophos supports only EAP-TTLS with PAP as the inner authentication method. For Windows and Android, the vendor requires the SSID mode WPA2/WPA3 Enterprise, because the documented TTLS/PAP combination is not supported with pure WPA3 Enterprise on those platforms. Apple devices need an installed Wi-Fi profile with TTLS and PAP; Sophos refers to Apple Configurator for this purpose.
These requirements come from the Sophos setup guide for Entra ID. A mixed device fleet should therefore have a small compatibility matrix prepared in advance: device, operating system version, Wi-Fi profile and test sign-in result. A successful Windows test does not establish compatibility with an Android phone or a Mac.
EAP-TTLS/PAP: why certificate trust matters
EAP-TTLS establishes a TLS tunnel. Password verification using PAP takes place inside this protected tunnel. Security therefore depends substantially on the client reliably verifying the authentication server’s identity.
If certificate validation is disabled or an unknown certificate is accepted without checking it, the device could send credentials to a rogue server. Microsoft explains this risk in its documentation on EAP and server certificate validation.
For managed operation, Wi-Fi profiles should specify the approved trust chain and expected server identity. The values must match the actual environment and be established before rollout. Recurring certificate prompts do not signify a completed setup; they are a reason to review the profile.
Automatic use of Windows sign-in credentials should not be assumed either. Microsoft documents the corresponding EAP-TTLS option for MS-CHAP v2, but not for PAP. This integration therefore does not automatically provide a confirmed Wi-Fi SSO guarantee for an Entra-joined Windows device.
Limitations that matter before a migration
User passwords rather than certificate-based device authentication
The documented TTLS/PAP workflow uses a password. It does not replace existing EAP-TLS authentication with device certificates. Organisations that currently authenticate devices independently of a user signing in should treat this difference as an architectural decision.
For example, a managed laptop may need network access before the user signs in. Printers and other devices without a suitable user identity do not automatically fit the same workflow either. A suitable RADIUS or NAC solution remains a possible alternative for these requirements. The AP6 guide to external RADIUS and Enterprise Wi-Fi describes this separate configuration route.
MFA and Conditional Access are not automatic Wi-Fi features
An Entra account that triggers an MFA challenge in Microsoft 365 does not establish such support for TTLS/PAP. The Wi-Fi workflow does not provide an interactive Microsoft browser dialogue. Successful password verification is therefore not equivalent to confirmed MFA authentication.
The Sophos guide reviewed does not provide a complete compatibility commitment for MFA, Conditional Access, passwordless accounts, guest accounts or federated identities. The intended scenarios must be tested against the tenant policies actually in force. If sign-in fails because of a security requirement, first clarify the supported workflow with Sophos rather than broadly relaxing the protection policy.
No dynamic VLANs, accounting or captive portal backend
Sophos excludes three functions from this Fusion RADIUS/Entra workflow:
- RADIUS-assigned VLAN: No dynamic VLAN assignment through this service.
- RADIUS Accounting: No accounting function through this service.
- Captive Portal backend authentication: Cannot be used as the authentication backend for a captive portal.
An organisation that assigns employees to different VLANs through a RADIUS policy, for example, cannot simply replace the existing service with the Entra IdP. The limitation concerns dynamic assignment, not a statically planned VLAN for an SSID in general. A separate SSID and VLAN design is still needed to ensure that an authenticated client can reach only the intended networks.
Multiple Enterprise SSIDs require a review of frequency bands
The interface manages RADIUS selections per SSID. At the same time, Sophos documents only one RADIUS server configuration per frequency band for AP6. Another Enterprise SSID with a different server can overwrite the existing selection on an overlapping band.
An additional test SSID on a production AP is therefore not automatically isolated from the existing configuration. Before assigning it, review all Enterprise SSIDs, frequency bands and authentication sources. A separate pilot AP is the more straightforward choice for the first test. Sophos describes this behaviour and the interruption when saving in its SSID settings documentation.
Setup and acceptance testing in practice
The configuration connects three components: the app in Entra ID, the IdP object in Sophos Fusion and the Wi-Fi profile on the client. In Fusion, the starting point is My Products > Wireless > SSIDs > RADIUS > Add > Add external identity provider. Enter the prepared Entra values there, check them with Test connection and save. The IdP is then assigned to an AP6 Enterprise SSID.
Test connection is a preliminary check, not full Wi-Fi acceptance testing. Only a real client sign-in tests how the EAP profile and user identity work together. IP addressing, DHCP, DNS and permitted network access must then also work.
The following checks are recommended for a pilot:
- Choose an AP and SSID whose modification will not affect existing authentication.
- Sign in with a normal test account and the intended client profiles. Server trust must be established without accepting an unverified certificate.
- Test every intended device type and identity policy, including a controlled negative test with a disabled test account. Disabling an account does not necessarily terminate an existing Wi-Fi session immediately; assess new sign-ins and ongoing sessions separately.
- Check addressing, DNS, permitted destinations and the intended network separation. Retest existing SSIDs after making changes.
- Add more APs only after documenting successful results. Include secret renewal, changes to Entra policies and behaviour when cloud connectivity is unavailable in the operational plan.
For organisations that already manage their users in Entra ID and do not need advanced RADIUS functions, the AP6 integration can simplify Wi-Fi infrastructure. The decisive comparison, however, is with the existing access model: Which identities are checked, which devices must work and which rules must be preserved during migration? These questions should be answered before a local authentication service is switched off.
