Sophos Mobile: Safely Verify SCEP Certificates and Connectivity

SCEP can install and renew certificates in Sophos Mobile (MDM). This procedure covers tenant-side SCEP integration and the distinct connections involved—not a complete setup guide for a Windows CA, Wi-Fi/VPN infrastructure, or every Android, Apple, and Windows policy payload. SCEP installation and renewal under this procedure do not support Chromebooks.

Before changing production: The CA/PKI, network, and MDM owners, along with the Wi-Fi/VPN authentication service owner where applicable, must agree on the affected devices and enrollment modes, whether and how a particular service can use the SCEP certificate, and how devices will remain reachable if network access fails. Neither Save nor a deployed policy proves that a client certificate was issued, renewed, or associated with a Wi-Fi/VPN profile.

Three connections, not one blanket port rule

Sophos Fusion connects to your SCEP-enabled CA; the managed device communicates separately with Sophos Mobile. Subsequent authentication to a Wi-Fi/VPN service using that specific SCEP certificate is not automatic and must be verified for each platform and profile. Tenant here means your Sophos Mobile environment; MDM is its device management system.

Identify the tenant region. In Sophos Fusion, go to My Products > Mobile and check the URL in your browser’s address bar. The region is in the first part of the hostname, before the first dot, directly after smc-user-if-cloudstation-. In the example smc-user-if-cloudstation-eu-west-1, the region is eu-west-1. For firewall rules, use the region from your own browser URL, not the example value or matching text in the URL path or query parameters. The hosting region is selected when the Sophos Fusion account is created; for existing accounts, identify it here from the actual browser URL. This admin host is neither the device endpoint nor the SCEP server. The same region lookup applies to Mobile Threat Defense, but it does not establish a separate MTD SCEP capability.
Fusion to your servers (inbound): The current regional source-IP list for deciding which inbound traffic to allow specifies TCP 443 for SCEP and TCP 636 for the separate LDAP/AD connection. Allow only the Mobile source IPs currently published there for the actual tenant region to reach the intended SCEP or AD destination, respectively. Do not copy the example region or create a global or unrestricted inbound rule. The LDAP/AD connection is used for user authentication with AD credentials during device registration through Apple Business (formerly Apple Business Manager), Google Zero-touch, or Samsung KME. This authentication is neither the initial SCEP client-certificate issuance to a managed device nor its later certificate renewal.
Device to Sophos Mobile (outbound): Managed devices need HTTPS 443 to the regional smc-device-if-cloudstation- host. The full device destinations are smc-device-if-cloudstation-eu-central-1.prod.hydra.sophos.com for eu-central-1, smc-device-if-cloudstation-eu-west-1.prod.hydra.sophos.com for eu-west-1, smc-device-if-cloudstation-us-west-2.prod.hydra.sophos.com for us-west-2, and smc-device-if-cloudstation-us-east-2.prod.hydra.sophos.com for us-east-2, each over HTTPS 443. Use only the destination for the actual tenant region identified above; these device destinations are neither the admin host nor your own SCEP destinations. Additional connections are required for push notifications, enrollment, and other platform functions. The separate checks and internal platform guides below distinguish these by device type and function actually used; the four regional device hosts are not a complete egress list. These additional destinations are neither SCEP inbound source IPs nor a blanket SCEP port list.

Keep other device egress dependencies separate:

Windows push: For Windows computers, *.notify.windows.com, *.wns.windows.com, and *.notify.live.net are documented destinations for Windows Notification Service (WNS) and Microsoft Push Notification Service (MPNS), each over HTTPS 443. These are Windows push connections, not inbound SCEP ports.
Android enrollment and provisioning: For Android, consult the Android Enterprise guide, and for QR/Zero-touch/KME prerequisites, the provisioning guide; firewall allowances still need to be checked there for the specific device and mode.
Apple management push: For management of iPhones, iPads, and Macs, check the Apple push path separately; the APNs guide explains certificate identity, renewal, and the reachability check available on iPhone/iPad.
Apple update information and compliance: Separately, Sophos Mobile needs information about available Apple updates: if the Apple service used for this is unreachable, this information is missing and compliance rules requiring updates have no effect. Check your own network path and the platform, OS, and enrollment limitations in the compliance guide. Apple management push and update information are device egress requirements, not SCEP inbound or certificate-issuance endpoints.
IXM app traffic: For iPhone/iPad with Sophos Intercept X for Mobile (IXM), check the separate app connections in the IXM network guide; it describes service/port mappings and limitations by app version, edition, management type, and function actually used. These are not SCEP inbound connections; an Apple heading in a network list does not establish IXM applicability to Macs.

A documented destination address does not prove reachability on your own network.

When troubleshooting, record separately whether (a) Fusion can reach your SCEP endpoint, (b) the device can reach Sophos Mobile and receive its policy, and (c) the Wi-Fi/VPN service accepts the issued certificate. Success on one path does not replace checks on the other two.

Establish trust and responsibilities first

Terms for this decision: PKI is the certificate infrastructure; the CA is its issuing authority. SCEP requests the client certificate. Subject and SAN (Subject Alternative Name), and UPN (user identifier) where applicable, determine the identity to verify. EAP is a Wi-Fi authentication method. A PKCS #12 import (.pfx) is a different deployment method from SCEP; its certificate is not automatically renewed by the SCEP renewal interval.

Decide the following three trust questions separately, even if the same CA fills several roles in your PKI:

Connection to the SCEP server: Before configuring SCEP, the MDM team deploys a Root certificate configuration containing the SCEP server’s CA certificate in the appropriate policy. For Android Enterprise device policies, also select that certificate in the SCEP Root certificate field from the certificates in the same policy. This is not the issued client certificate and does not prove client identity.
Issued client identity: On Android Enterprise and iOS, the Subject must be a valid X.500 name for the intended person or device after all placeholders have been replaced. Set the SAN type and value separately; in device SCEP fields, AD user logon name means the user’s AD UPN, not an arbitrary device identifier. The iOS CA name field is a name understood by the CA, for example to distinguish its instances—not evidence of the issuer or a trust anchor. The PKI/CA team therefore checks the actual issued certificate for the issuing CA and chain, permitted Subject/SAN/UPN values, key usage, and access to the private key. The MDM and service teams agree on the identity matching actually performed by the consuming service; do not use example placeholders.
Service trust: If Wi-Fi/VPN is to use the client certificate, the consuming service must trust its CA chain. With EAP, also check that the device trusts the Wi-Fi server certificate. SCEP server trust alone establishes none of this.

Owners before approval:

PKI/CA team: Check the SCEP-enabled Windows CA, reachability of /CertSrv/MSCEP_ADMIN and /CertSrv/MSCEP, and permissions to generate challenges and enroll certificates. Do not put challenge passwords, service credentials, or private keys in tickets or screenshots. The historical Windows 2003 note in the Sophos help is not a current server-support commitment.
Network team: Check the target FQDN, TLS/HTTP proxy path, and narrowly scoped regional source-IP allowance against the actual topology. Separately check device egress, push connectivity, and an independent management/network path for emergencies. Do not replace these checks by disabling filters wholesale.
MDM/service team: Establish the platform, device or user policy type, and enrollment mode before configuration. Use an Android Enterprise device policy for the Android Enterprise device workflow described here; a Work Profile policy covers a different management scope. The Android Enterprise guide explains this choice of mode. Treat the iOS device SCEP payload separately and do not use it as evidence for iOS user policies. Shared and platform-specific SCEP fields are checked separately in the pilot procedure below. Stop unless the policy type and a supported enrollment mode have been confirmed.

Stop if the intended identity or CA trust chain is unclear, the device type or mode does not match the tested policy, or the device would be manageable only through the very Wi-Fi/VPN connection being changed and there is no independent recovery path.

Certificate issuance is not Wi-Fi/VPN certificate mapping

The SCEP configuration requests a certificate from the CA. Before changing Wi-Fi/VPN, check these separately:

Wi-Fi selection field: In Android Enterprise device policies and iOS device policies, Identity certificate selects a certificate from a Client certificate configuration in the same policy. This configuration imports a PKCS #12 file (.pfx); it is a different deployment method from SCEP. This does not establish that a SCEP-issued certificate can be selected in the Wi-Fi selection field. An EAP Wi-Fi network for Android Enterprise must not be hidden: the SSID must be broadcast.
Renewal and server trust: Plan the import, validity, and replacement of PKCS #12 certificates separately; SCEP renewal interval does not renew them automatically. Do not assume the root certificate for the EAP server in the Wi-Fi policy is the same as the SCEP server trust certificate.

VPN does not provide a uniform SCEP integration either: On Android Enterprise, the policy selects an already installed managed Google Play VPN app; connection parameters reside in its Managed Configuration. On iOS, certificate authentication and certificate selection depend on the connection type. This selection alone does not establish that a SCEP certificate can be used. Before a Wi-Fi/VPN pilot, confirm supported certificate mapping and behavior after renewal for the platform, policy type, authentication method, and VPN client if applicable, using relevant vendor documentation or a bounded pilot. Without this evidence, limit the pilot to SCEP issuance and renewal; do not migrate Wi-Fi/VPN or withdraw the existing trust chain.

Configure SCEP only in a limited pilot

Under Setup > Sophos setup > SCEP, agree with the PKI team on the SCEP server URL https://<server>/CertSrv/MSCEP and challenge URL https://<server>/CertSrv/MSCEP_ADMIN. Use an authorized user in username@domain format and their password; check allowed challenge character types and permissions with the PKI team. Select the agreed character types for the challenge password in the Challenge characters field before selecting Save; keep the Sophos default challenge length. Treat a different PKI requirement only as a separately documented, approved, and tested exception. If an HTTP proxy is enabled, Use HTTP proxy initially applies to this connection; disable it only if Sophos Mobile is deliberately meant to reach the SCEP server without going through the proxy.
Select Save and document the connection test to the SCEP server. If it fails, check the URL, certificate trust, proxy, permissions, and allowed source IPs with the relevant owners—do not immediately change policies across the fleet.
First, create a policy or edit an existing policy appropriate for the pilot mode. Consult the policy guide for creation, configuration editing, saving, and subsequent pilot assignment; verify the platform and supported policy type beforehand. In this policy, configure Root certificate with the SCEP server’s CA certificate first, then SCEP and SCEP renewal interval. For the SCEP URL and Challenge fields, the Android Enterprise and iOS device policy guides describe the placeholders %_SCEPPROXYURL_% and %_CACHALLENGE_%, respectively, for the previously configured SCEP server and challenge URLs. Agree on Subject, SAN/UPN, key size, and intended use with the PKI team and consuming service for the specific platform. Assign the policy only to the bounded pilot group. Beforehand, PKI and MDM must establish where policy delivery, device certificates, and PKI issuance/renewal can be observed for this particular platform and policy mode; if Wi-Fi/VPN mapping has also been established, identify the service log too. Do not assume identical status fields or log names on every device. SCEP renewal interval determines when the device requests renewal, not whether renewal succeeds.
Platform-specific SCEP fields: In Android Enterprise device policies, set a recognisable Alias name for selection dialogues and, in the Root certificate field, select the SCEP server’s CA certificate from the same policy. In iOS device policies, agree on CA name with the CA; Retries counts retries after a server response of pending, and Retry delay sets the interval in seconds. Do not present these iOS fields as Android fields. Key size must match the SCEP server configuration. For Certificate usage, agree separately with the PKI team and service on the intended use as Use as digital signature or Use for encryption; do not invent a default size or selection.
For Type of Subject Alternative Name and Value of Subject Alternative Name, check the documented type and value separately: RFC 822 name for a valid email address, DNS name for the CA server’s DNS name, or Uniform resource identifier for its full URL. AD user logon name remains the user’s AD UPN. The field description does not replace identity verification against the actual issued certificate.
Initial issuance after policy delivery: On the pilot device, compare the issuer/chain, Subject and SAN/UPN, serial number, validity start and end, and key usage with approved PKI requirements. AD device registration does not count as SCEP client-certificate issuance. If issuance is not observed: stop; do not approve rotation.
Later renewal: PKI and MDM define an observation period based on the interval and certificate validity. During that period, verify on the device a new valid certificate with a new serial number and matching identity/issuer values, as well as the corresponding confirmed PKI event. If renewal cannot be observed or does not occur during the pilot period, do not approve rotation as validated.
Only if Wi-Fi/VPN mapping is established in the pilot: In the consuming service’s log, attribute successful authentication before and after renewal to that specific pilot device and certificate. Without the service log or confirmed mapping: no Wi-Fi/VPN cutover.

Rotation and recovery path

Before changing the SCEP URL, challenge credentials, or CA, or making a separately validated Wi-Fi/VPN profile change, record the old and new policy assignments, trust anchors, and affected groups for each device class in the pilot record. PKI, network, and MDM owners must agree on a management path that is actually reachable and independent of the certificate-based network being changed, a designated local recovery owner, and a stop criterion. The specific way to reassign or remove a policy and its effect on devices must be validated in the pilot for the platform and enrollment mode; there is no universal reset procedure here. According to Sophos, Uninstall policy is available only for Android device, Knox container, and iOS device policies; for other types, including Android Enterprise device policies, update the policy or assign another one instead. Whether that removes or restores an already installed CA certificate or client certificate is not established.

Decision before rollout: Deploy the new trust chain first in the pilot only if the specific mode supports parallel deployment. Verify new issuance and genuine later renewal. For a planned Wi-Fi/VPN change, also verify established profile mapping and service authentication before and after renewal. Remove old profiles and trust anchors only after controlled acceptance and a planned rollout. Do not withdraw the old CA prematurely if existing connections still need it.

If something fails, decide based on reachability:

Stop all further assignments and withdrawals. Keep the previous CA, profiles, and trust anchors; involve the PKI, network, and MDM owners using the pilot record.
Device reachable via the tested independent path: The MDM team uses the assignment/removal method previously validated for this mode to restore the documented previous policy/network/CA association; PKI and network teams check their respective parts. If Wi-Fi/VPN changed, retest authentication in the service log.
Device offline or without an independent path: The previously designated local recovery owner uses only the local recovery procedure planned and tested beforehand; then retests reachability and, where applicable, service authentication. Merely reverting a cloud setting is not a proven rollback for devices that have gone offline. If the local procedure has not been validated, do not claim that safe remote recovery is possible or expand the change.

Without observed initial issuance, renewal, and a tested recovery path, the production SCEP change remains blocked. A Wi-Fi/VPN change additionally requires established certificate mapping and successful use before and after renewal.

Evidence limit: This is a source-based draft, not tested in a tenant or on devices. Supported OS/server versions, client behavior during offline renewal, and the specific EAP/VPN identity matching must be confirmed separately in your environment.