Plan Apple Wi-Fi, certificates, VPN and proxy with Sophos Mobile

Scope: Sophos Mobile in Sophos Fusion (formerly Sophos Central), on iPhone and iPad with iOS/iPadOS. This guidance distinguishes iOS device policies (Device Policy) from iOS user policies (User Policy). It is not a tested step-by-step configuration for a specific tenant, a macOS guide, or approval for production-scale deployment. First check the operating-system version, enrollment mode, supervision status, policy type and features available in your tenant on the target device.

⚠️ Do not cut off connectivity: An incorrect Wi-Fi/EAP certificate, an unreachable SCEP CA, faulty PAC/WPAD or a VPN tunnel can also interrupt the return path for MDM tasks. Before making changes, verify a connection independent of the profile being changed and a local recovery path. A rollback saved in the console does not automatically reach a device that has been locked out and is offline.

Distinguish the management mode first

Device Enrollment does not automatically mean supervision: Automated Device Enrollment supervises the device, but other methods do not necessarily do so. Apple User Enrollment never supervises the device and concerns managed data rather than the entire personal device. For BYOD, a Managed Apple Account and consent are prerequisites. There is no global HTTP proxy, no ordinary device-wide VPN and no proxy settings in the managed Wi-Fi configuration; Sophos cannot query the MAC address, UDID or IMEI for NAC identification.

Sophos limits profile-based User Enrollment to iOS/iPadOS 17 or earlier; this does not mean account-driven User Enrollment has generally been discontinued. On unenrollment, the managed APFS volume and the managed Apple Account are removed from the device; this is not a general Wi-Fi or VPN rollback. Apple describes per-app VPN as a possible User Enrollment feature, not as proof of a working Sophos app-assignment path.

Plan Wi-Fi and the certificate chain together

Isolate the BYOD pilot before every change: For iOS/iPadOS user policies, Sophos synchronizes changes automatically whenever the device reconnects to Sophos Mobile; manual Update devices is not required. Therefore, use a separate user policy assigned only to the approved BYOD test device, and check its current assignments and target-device count before editing and before Save. Do not change a policy already shared with production BYOD devices during the pilot. Subsequent assignment to selected test devices does not limit synchronization of the change on other devices already assigned to the same policy. This scope rule also applies to certificate changes and rollback corrections; synchronization alone confirms neither network function nor the MDM return path.

Who verifies whom? With enterprise Wi-Fi using EAP (authentication between device and network), the device verifies the RADIUS server name and certificate chain. With certificate-based authentication, RADIUS in turn verifies the issued client identity. The server CA and client identity therefore serve different purposes. The Identity certificate selectable in the Wi-Fi configuration requires a Client certificate configuration in the same policy; the server certificate under Trusted certificates requires a Root certificate configuration there.

Fictitious placeholders only—do not copy them into use: radius.test.invalid as the server name, Test-CA as the trusted server CA, and CN=Testperson,OU=Pilot,O=Beispiel as the X.500 subject (fields for the client identity). Replace all values with the names, CA and identity fields confirmed by your PKI/RADIUS team. On a test device, check that the configured server identity matches the real chain and that RADIUS accepts the issued client certificate. The root certificate is an X.509 certificate in PEM/DER format; an imported client certificate is PKCS#12 (.pfx). Uploading a .pfx does not automatically make it reusable across multiple policies: if you need the client certificate in another policy, you must upload it again there. Check the CA’s provenance, key ownership, validity and intended usage. Uploading a root CA does not prove universal trust by all apps.

For Root certificate in an iOS device policy, open the configuration on Edit policy through Add configuration > Root certificate. Use Upload a file to select the X.509 file in PEM/DER format, then Open to open it. After upload, Certificate name displays the Distinguished Name (DN) of the issuer, not the client identity. Use Apply to save the configuration, then Save on Edit policy to save the policy. According to Sophos, assigning the policy installs the uploaded root certificate on the device. The display and saving alone prove neither trust nor validity nor successful installation. Each additional root certificate requires its own Root certificate configuration in the same policy.

For Root certificate in an iOS user policy, Sophos describes importing the certificate on Edit policy through Add configuration > Root certificate. Use Upload a file to select the X.509 file in PEM/DER format, then Open to open it. After upload, Certificate name displays the issuer’s Distinguished Name. Use Apply to save the configuration, then Save on Edit policy to save the policy. Add a separate Root certificate configuration for each additional root certificate. According to Sophos, assigning the user policy installs the certificate on the device; within the same policy, it can be used, for example, as the EAP server certificate for Wi-Fi. Neither the upload display nor a saved policy proves successful installation, certificate trust or working Wi-Fi authentication.

In the Client certificate configuration of the iOS device policy, select Upload a file under File, then select the PKCS#12 certificate file (.pfx). Under Certificate name, Sophos Mobile displays the name read from the certificate file. This name alone does not prove trust, validity or successful installation.

Before configuring SCEP: If you use the SCEP connection configured in Sophos setup with the variables below, first check the SCEP prerequisites and certificate workflow: reachability from Sophos Fusion to the CA, region-scoped firewall permissions and, for this documented Windows CA path, an account authorized to create challenges and enroll certificates. Before SCEP, provide the SCEP server’s CA certificate as Root certificate in the same policy. This server trust is separate from RADIUS server trust and the issued client identity; this does not assert Windows as a prerequisite for every direct SCEP implementation.

SCEP (Simple Certificate Enrollment Protocol) lets a device request a certificate from the CA. This requires a reachable CA URL or the correctly configured Sophos SCEP proxy variable. Have the PKI team align X.500 subject fields and SAN/UPN (additional identity names), the challenge, retry parameters for pending requests, key length and usage bits with your CA. For the SCEP configuration of an iOS device policy, the following decisions matter:

• CA endpoint and name: URL is the CA server’s web address. %_SCEPPROXYURL_% refers to the server URL on the SCEP tab of Sophos setup. CA name is a name understood by the CA; it can, for example, distinguish CA instances. Confirm the name expected by your CA with the PKI team. This field is neither the Certificate name display for an imported certificate nor the example name of the trusted RADIUS server CA.
• User or device identity: Subject may contain placeholders for user data or device properties. Sophos gives CN=%_USERNAME_% for a user and CN=%_DEVPROP(SerialNumber)_% for an iPhone or iPad. These are documented syntax examples, not values tested for your tenant. Have the PKI team approve the intended identity, and check that the data is available and that the subject is a valid X.500 name after substitution. BYOD: A documented serial-number placeholder does not prove that a serial-number-based identity can be resolved under User Enrollment; Sophos cannot query device identifiers there. Verify the subject and issuance with a test user.
• SAN type and value: Under Type of Subject Alternative Name, select the type approved by the PKI team and enter the corresponding value under Value of Subject Alternative Name. RFC 822 name means a valid email address. For this iOS SCEP configuration, Sophos describes DNS name as the DNS name of the CA server and Uniform resource identifier as its fully qualified URL—not as the RADIUS server name or challenge address. AD user logon name is separate and refers to the UPN set in Active Directory. Challenge is the web address from which the device obtains a challenge password from the SCEP server. %_CACHALLENGE_% refers to the challenge URL configured on the SCEP tab of Sophos setup, not to the password itself. Do not copy real secrets into public examples or tickets.
• Pending requests: Retries sets the number of retries when the server responds with pending; it is not a general retry counter for all network errors. Retry delay is the interval between these attempts in seconds. Agree on the count and interval with the PKI team; do not confuse them with certificate renewal.
• Keys and intended usage: Key size is the size of the public key in the issued certificate and must match the size configured on the SCEP server. Certificate usage defines the permitted usage: Use as digital signature for digital signatures, Use for encryption for data encryption. The selection must match PKI requirements and the target service; it proves neither successful Wi-Fi/VPN authentication nor encryption of all device traffic.

When creating a policy, there is a SCEP renewal interval field. Review the interval, expiry, revocation and replacement with the PKI team; setting an interval guarantees neither successful renewal nor recovery of a device that has remained offline.

Identity substitution in device and user policies: In the example CN=%_USERNAME_% above, %_USERNAME_% is replaced by the Exchange Login of the user assigned to the device, not necessarily their display name and not automatically their AD UPN. Check the correct user assignment and this property value before assignment; the substituted subject must still be a valid X.500 name approved by the PKI team. AD user logon name remains the separate UPN field.

For SCEP in an iOS user policy, define the endpoints separately. URL is the CA server’s web address. The variable %_SCEPPROXYURL_% refers to the server URL on the SCEP tab of Sophos setup. Challenge is the URL for retrieving a challenge password from the SCEP server, not the password itself. %_CACHALLENGE_% refers to the challenge URL configured on that SCEP tab. As with the request parameters described above, Retries counts only retries after a pending response; Retry delay gives the interval between them in seconds. Key size must match the public-key size configured on the SCEP server. Confirm these parameters with the PKI team; they are neither renewal intervals nor proof of successful issuance.

Enterprise Wi-Fi and private Wi-Fi addresses

For an isolated device Wi-Fi pilot, the following path connects network settings with policy assignment. First secure the independent network and recovery path described in the pilot section; do not edit a policy assigned in production.

1. Under Policies, open the Apple platform appropriate for the target device, use Create to create a device policy, and enter its name, description and organization name. On Edit policy, use Add configuration to add the Wi-Fi configuration, then open its name to edit it. For enterprise Wi-Fi, first provide the required client and root certificates in the same policy as described above; Apply in the root certificate configurations does not replace Save for the entire policy.
2. Under SSID, enter the Wi-Fi name confirmed by the network team and align Security type with the actual method, including its Personal/Enterprise variant. Personal requires the Wi-Fi password; for Enterprise, use the EAP, authentication and trust settings described below. Connect automatically connects automatically when the network is available; Hidden network identifies a network that does not broadcast its SSID. Choose both options only as appropriate for the intended network, not as proof of security.
3. Review all configurations and use Save on Edit policy to save the policy. For subsequent assignment, use the “Create and assign a policy” workflow: select the saved pilot policy, select only the approved individual test devices, and compare the list and count before Finish. Observe the scheduling and iPadOS caveats there. Then observe task/assignment status, actual Wi-Fi authentication and MDM check-in separately against the test criteria below; saving and assigning are not confirmed connection results.

For the Wi-Fi configuration of an iOS device policy, first select the Security type that matches the network. A Personal variant provides the Wi-Fi password option. Only an Enterprise variant offers Protocols, Authentication and Trusted certificates. Under Accepted EAP types, align the methods accepted by the device with the RADIUS team’s network authentication design. The client and root certificates described above remain bound to the same policy.

Under Authentication in the iOS device policy, User is the Wi-Fi username and Password is the Wi-Fi password for credential-based authentication. According to Sophos, Require password on each connect sends the password with every authentication; the option does not promise an interactive password prompt. Coordinate the credential path and this selection with the RADIUS team. For certificate-based authentication, instead select the appropriate Identity certificate from a Client certificate configuration in the same device policy. On the test device, verify RADIUS acceptance of either the credentials or the client certificate according to the chosen path; server identity and the trust chain still need separate checks in both cases.

For TTLS, Internal identity specifies the protocol for user authentication inside the tunnel. It is not the outer identity. For EAP-FAST, a Protected Access Credential (PAC) can be configured; this PAC is not a proxy auto-configuration script. Clarify the TTLS protocol and, where applicable, the EAP-FAST credential with the RADIUS team, then test authentication on the target device. Without this clarification, leave the relevant EAP branch out of the pilot.

For EAP, set both TLS bounds or leave both unset. Sophos describes Outer identity for TTLS, PEAP and EAP-FAST and requires an outer identity for TLS 1.3. Do not use usernames or secrets for it because the outer identity is sent in plain text. If needed, have the PKI/RADIUS team verify an anonymous outer identity with an appropriate realm for routing. Observe the negotiated authentication and TLS version on the test device; the selection alone does not prove a successful connection.

Turn off private address makes the device use its hardware MAC address for this Wi-Fi network instead of a network-specific address generated by iOS. This reduces privacy. Use the option only if the device must be identified by the same MAC address across your networks. According to Sophos, Synchronized Security does not work with private MAC addresses: Sophos Fusion Wireless knows only the private address, while Sophos Mobile knows only the hardware address. Disabling private addresses alone does not guarantee working Synchronized Security; verify the mapping and intended behavior in the planned network. Do not treat it as a BYOD workaround for NAC. Under User Enrollment, Sophos cannot obtain the MAC address for NAC.

For Wi-Fi in an iOS user policy, Sophos also distinguishes Personal from Enterprise under Security type. Personal uses the Wi-Fi password. Protocols, Authentication and Trusted certificates are available only for Enterprise. For credential-based authentication, User is the Wi-Fi username and Password is the Wi-Fi password. According to Sophos, Require password on each connect sends the password with every authentication. Coordinate this selection with the RADIUS team; do not interpret it as a promise of a password prompt. For certificate-based authentication, instead select the appropriate Identity certificate from a Client certificate configuration in the same user policy. The server certificate under Trusted certificates also requires a Root certificate configuration in that policy. Use the client certificate and its acceptance by RADIUS as test criteria only for the certificate-based authentication path.

According to the Wi-Fi description, the EAP decisions above also apply to this user policy. Align Accepted EAP types with network authentication; for TTLS, clarify the protocol under Internal identity, and for EAP-FAST, clarify the Protected Access Credential (PAC) where applicable. This credential is not a proxy PAC script. Set both TLS bounds or leave both unset. Outer identity is described for TTLS, PEAP and EAP-FAST and is required for TLS 1.3. Follow the plain-text and realm guidance above. Infer neither availability of all options in your tenant nor successful authentication from this; the exclusion of a managed Wi-Fi proxy and the MAC/NAC caveat for User Enrollment still apply.

Proxy and VPN are different interventions

• Wi-Fi proxy: Configurable manually or through PAC (a file containing proxy rules) in the iOS device policy. Under Apple User Enrollment, the Wi-Fi configuration supports no proxy. Sophos cites WPAD (automatic proxy discovery) at the access point and a user-set HTTP Proxy: Automatic option in Wi-Fi settings as a possible workaround—not as a remotely managed BYOD proxy payload. Test PAC/WPAD, DNS and reachability separately.
• Global HTTP proxy: Sophos permits this iOS device configuration only for supervised devices; configure it manually with server/port/credentials if needed, or automatically with a PAC URL. In manual mode, Server is the name or IP address of the HTTP proxy and Port is its port number. Authentication is the username for connecting to the proxy server, and Password is the corresponding password. It is neither a BYOD option nor a promise of fail-safe operation.
• Device-wide VPN: The iOS device policy specifies connection type, server and authentication; with Custom SSL/TLS, the provider app must be installed. Do not carry this configuration over to Apple User Enrollment: Apple does not allow an ordinary device-wide VPN there.
• Per-app VPN: A separate configuration for selected apps, not the same as a device VPN. Check the provider app, server, authentication, optional certificates/proxy, on-demand behavior and domain rules for Safari/other browsers, Calendar, Contacts and Mail separately. Also verify the actual scope of Send all traffic through VPN; do not infer universal app isolation or device-wide effect from its name. Sophos documentation is inconsistent here: The User Policy description includes per-app VPN, but the app-assignment instructions name only Device Policies as a prerequisite and selection. Therefore, do not claim a working BYOD assignment click path: first demonstrate it in the current tenant with a test app and test device.

Device VPN: provider, authentication and traffic routing

The following details belong to the VPN configuration of an iOS device policy, not to the per-app VPN configuration or Apple User Enrollment. Check availability and provider support in your tenant. Connection name is the connection name displayed on the device. Under Server, enter the VPN server’s hostname or IP address; confirm the appropriate endpoint with the VPN administrator.

• Under Connection type, select the appropriate provider or connection type. For a VPN provider app from the App Store, Sophos describes Custom SSL/TLS. The app must be installed; enter its identifier in reverse-DNS format under Identifier (reverse DNS format). If the provider specifies custom connection parameters, enter the confirmed keys and values as connection properties under Third-party settings. Do not copy keys or values from other providers’ configurations.
• User authentication concerns user authentication. Account is the user account for the VPN connection; Group can specify an authentication group required for it. Under Password, specify the VPN password; under Certificate, specify the VPN authentication certificate. Clarify with the VPN administrator whether a group is required and which identity is used. These credentials are not proxy credentials.
• Device authentication is separate. For Keys (Shared Secret)/Group name, enter the required group under Group name and the shared key under Keys (Shared Secret). Sophos also lists Use hybrid authentication and Request password, but this page only says to select them as needed. Their effects and required selection are not clarified here; include these two options in the pilot only after confirmation from the provider. Under Certificate, select the required device authentication certificate. According to Sophos, Including user PIN optionally includes the user’s PIN in device authentication. Do not apply any of these branches to every provider without verification, and do not record real keys or PINs in tickets.
• Send all traffic through VPN is the setting for routing all traffic through this VPN connection. Sophos describes it as sending all traffic through the VPN. Verify the actual traffic route on the test device in the chosen provider/tunnel mode, and check the MDM return path separately. This is not proof of complete traffic capture or app isolation.
• Under Proxy, specify the proxy for this VPN connection. No proxy means no connection proxy. For Manually, enter the proxy address and port under Server and port; Authentication is the proxy username and Password is its password. For Automatic, enter the URL of the server containing the proxy settings under Proxy server URL. This selection is neither the Wi-Fi proxy nor the global HTTP proxy payload; do not infer a supervision requirement or fail-safe behavior from it.
• Provider type distinguishes the transport layer, not the provider selected under Connection type. App proxy carries traffic in the VPN tunnel at the application layer; Packet tunnel carries it at the network layer. App proxy is therefore not synonymous with per-app VPN. Which selection the provider supports and which traffic it actually captures must still be checked on the target device.

Per-app VPN: inputs and connection startup

For Per app VPN in an iOS device policy, Sophos describes the following inputs and behavior; their effects still need to be tested in the pilot. These details do not resolve the User Policy app-assignment contradiction noted above.

For Per app VPN in both iOS device policies and iOS user policies, Connection name is the connection name displayed on the device. This is the visible connection label, not the provider app’s reverse-DNS identifier, the server address or the user account.

• Provider app: If the VPN provider has an App Store app that provides the VPN connection, select Custom SSL/TLS. This VPN app must be installed on the device; under Identifier (reverse DNS format), enter its identifier in reverse-DNS format, not the identifier of the business app whose traffic should use the tunnel.
• VPN authentication: Server is the VPN server’s hostname or IP address, and Account is the user account for authenticating the connection. Under User authentication, choose Password or Certificate, then specify the VPN password under Password or the VPN authentication certificate under Certificate. These details are separate from the credentials for a connection proxy.
• Connection startup: With Connect automatically on demand enabled, Sophos says the device activates the VPN when the app establishes a network connection. With the option disabled, users must turn the VPN on themselves. Test both flows on the intended test device.
• Connection proxy: Proxy offers No proxy, Manually and Automatic. For manual configuration, enter the valid proxy address and port under Server and port, the proxy username under Authentication, and its password under Password. For automatic configuration, enter the URL of the server containing the proxy settings under Proxy server URL. This is the proxy for this VPN connection, not the global HTTP proxy payload.

The same input syntax applies to Domains in Safari, Domains in Calendar, Domains in Contacts and Domains in Mail: one domain, partial domain or hostname per line. A partial domain matches when all dot-separated components match starting from the right; leading and trailing dots are ignored. A string without a dot matches only the host with that name, not arbitrary domains with that suffix. The additional second-level-domain rule for Calendar, Contacts and Mail also applies; the pilot section describes the appropriate positive test.

Per-app VPN in the user policy and app assignment

Sophos’s description of Per app VPN in an iOS user policy also documents the inputs explained above for the installed VPN provider app and its reverse-DNS identifier, authentication with Password or Certificate, on-demand connection startup, the connection proxy and domain syntax. These documented similarities do not prove a working assignment path under Apple User Enrollment.

Sophos documents the following conditional fields for Per app VPN in both iOS device policies and iOS user policies. The conditions apply to both policy types; check availability and provider support in your tenant:

• Third-party settings lets you enter connection properties specified by the VPN provider. This field is available only for Custom SSL/TLS. Use Add to enter the confirmed Key and Value. These connection properties are not the Managed configuration of the business app whose traffic should use the tunnel.
• Group specifies the group required for authentication. This field is available only for Cisco AnyConnect and Cisco Legacy AnyConnect. Do not apply this condition to other connection types.
• Under Provider type, App proxy carries traffic in the VPN tunnel at the application layer, and Packet tunnel at the network layer. This setting is unavailable for Cisco AnyConnect. Check which selection the provider supports and which traffic it actually captures on the intended test device. The transport layer alone proves neither app isolation nor device-wide VPN effects.

Assigning an existing connection to the business app belongs to the app-delivery workflow in “Check managed configuration and app behavior”. There, Assign per-app VPN is explicitly limited to existing device policies. Policy administrators provide the appropriate connection; app administrators select it in VPN connection used by the app. This reference does not resolve the user-policy uncertainty described above or authorize an untested BYOD assignment path.

Check prerequisites, observe the pilot and isolate failures

1. Inventory and return path: Record ownership, enrollment, supervision, iOS/iPadOS version, affected policy and assignment. For both a supervised company test device and a voluntary BYOD test device, document an independent network path (for example, cellular or another Wi-Fi network) and a responsible contact. Do not deploy a potentially connectivity-blocking change without this path. For changes to iOS device policies, use a test policy assigned only to the company pilot device; before updating it, check its current assignments and the number of target devices. Do not modify a policy already assigned in production for the pilot.
2. Dependencies: Test reachability of DNS, APNs/MDM, CA/SCEP/RA, RADIUS/EAP servers, PAC/WPAD and the VPN endpoint before and after the change. Check the certificate chain, server names, expiry and planned replacement; do not copy private keys, challenges or credentials into tickets. A valid policy assignment alone is not proof that Wi-Fi or VPN works.
3. Targeted pilot: Start with separate test devices and minimal assignment. Record these as test criteria, not confirmed results: the device accepts the verified RADIUS server identity and connects to the enterprise Wi-Fi network. For certificate-based authentication, also verify receipt of the client certificate and its acceptance by RADIUS; for username-and-password authentication, verify the intended credential path. For per-app VPN, check the tunnel traffic of the assigned managed test app; use access by other apps as a negative test only if those apps are neither subject to another VPN assignment nor matched by a configured domain rule. If domains are configured for Safari/other browsers, Calendar, Contacts or Mail, also check the intended access to matching domains; do not assume categorically that “other access has no tunnel.” Test Safari/browser domains separately: For positive tests with Calendar, Contacts and Mail, Sophos additionally requires the second-level domain of the configured domain to match that of the VPN server. A domain that does not match is not a valid positive tunnel test, and the absence of a tunnel for it alone does not prove VPN deployment failed. Verify domain rules in your own tenant rather than turning this into an untested configuration recipe. Verify the effect of Send all traffic through VPN separately on the test device in the chosen provider/tunnel mode; do not infer untested device-wide effects or app isolation. For User Policy per-app VPN, demonstrate the app assignment actually available or leave the feature out for now. For PAC/WPAD, observe the defined web/proxy failure path; after each change, confirm a new MDM check-in and actual network function separately. If check-in fails or the independent network path is missing, stop the pilot and assign no further devices.
4. Isolate failures: If Wi-Fi is unavailable, first check the SSID and security type, EAP server name and trusted CA; for credential-based authentication, check the username, password and intended RADIUS authentication path; for certificate-based authentication, check the issued client identity and CA reachability; if web access fails, check PAC/WPAD/DNS and proxy access; if an app fails, check the provider app, tunnel, certificate and assignment. Observe task/check-in and actual connectivity separately. Do not cause a second outage by removing certificates or profiles without control.

Roll back without resetting the device

Before the pilot, prepare a working replacement policy and replacement trust chain with a reachable network. Remove the old CA and identity certificates only after the replacement is confirmed on the target device and an MDM check-in has succeeded.

For iOS device policies, Sophos says changes require Update devices: this creates an update task for all devices assigned to the edited policy, not just the pilot device. Therefore, update only the isolated pilot policy after checking its current target devices; a targeted Assign policy task for selected devices is not the same as updating a policy shared by multiple devices. The targeted Uninstall policy task is intended for Device Enrollment but may itself remove the network path. For iOS user policies on User Enrollment devices, this Uninstall policy task is not available: Sophos instead provides the targeted Unassign iOS user policy task. Updating or assigning another policy may also make sense depending on the failure. Do not confuse the targeted task with Unassign for all devices.

iPadOS: distinguish direct actions from task types. The policy guide explains the inconsistent naming of direct update and uninstall paths: the type overview names iOS/iPadOS, while the direct instructions name only iOS device policies. Do not apply their click sequence to iPadOS without checking it; clarify the available direct path in the tenant and on the pilot device. This does not mean iPadOS rollback is generally undocumented or impossible: the iOS/iPadOS task types document Uninstall policy for Device Enrollment and Unassign iOS user policy for User Enrollment. The mode-specific task-bundle workflow describes this selection; continue checking task transfer and actual rollback effects separately.

Test rollback separately on a reachable company test device with Device Enrollment and a reachable BYOD test device with User Enrollment: on the company device, try the appropriate targeted Uninstall policy task for that device alone; on the BYOD device, try the targeted Unassign iOS user policy task. For each device, confirm task/check-in status and the policy state actually synchronized; then retest Wi-Fi/VPN function and MDM contact independently of each other. Limit further assignments or rollbacks to the test devices actually verified until both recovery paths have been demonstrated. A saved or sent task does not automatically reach a device that has been locked out and is offline. That requires the previously planned independent network path and local recovery path; Unassign for all devices is not a low-risk immediate remedy. Neither a complete Wipe nor user unenrollment is a general policy rollback.