Sophos Mobile EAS access: distinguishing proxy and PowerShell modes

The name Sophos Mobile EAS proxy refers to two different ways of controlling Exchange ActiveSync (EAS), the mobile synchronization protocol for mail. In proxy mode, EAS requests from devices configured to use it pass through the separately installed Sophos proxy to the mail server. In PowerShell mode, devices connect directly to Exchange; the Sophos service controls device access through a separate management connection. Confusing these paths can lead to planning the wrong network routes or overlooking a change to Exchange access. This is a decision aid, not a setup, migration or repair guide.

Stop before organization-wide quarantine or a production change: Changing the Exchange default access level from “Allow” to “Quarantine” can immediately affect already-connected EAS devices unless a device access rule or an individual Allow/Block decision applies. Do not switch without a documented baseline, checked device and compliance states, demonstrated sign-in and an approved backout path; this is not a switch for a single pilot device.

Decision path: First determine the target mail service and the EAS mail apps actually in use. For Exchange Server, proxy mode is an option for the mail path; for Exchange Online, Sophos lists only PowerShell mode with direct device access. IBM Traveler is a separate proxy target. Compare modes only for the relevant target. If device identity, client sign-in, management sign-in or target-server support cannot be verified, stop here rather than treating the choice of mode as approval.

A migration or implementation must be planned and approved separately; for incidents, see EAS troubleshooting.

License and platform gate: This EAS guidance belongs to Sophos Mobile device management, not to a stand-alone Sophos Mobile Threat Defense license. Before choosing either mode, verify the tenant’s actual Sophos Mobile or Sophos Mobile Device Management entitlement, the enrollment and compliance reporting of each intended Android or iPhone/iPad device, and its actual mail app and protocol. A Microsoft 365 Exchange Online plan named in Sophos’s server list is a mail-service prerequisite, not proof of Mobile entitlement or that EAS controls cover Outlook’s native sync. Do not infer coverage for Macs or other non-EAS clients.

Where does mobile mail traffic flow?

Privacy boundary: In proxy mode, mail traffic crosses the separately operated proxy; in PowerShell mode, mail traffic bypasses it, but Sophos still handles device identity and compliance information for access decisions. Neither mail path establishes what content or metadata is logged, stored or retained. Verify the actual deployment’s logging, access and retention before approval.

• Proxy mode: Device → Sophos Mobile EAS proxy → supported mail server (for Exchange: on-premises Exchange Server; Sophos also lists IBM Traveler). On the devices, the proxy must be configured as the EAS mail server for incoming and outgoing mail; this does not imply a separate SMTP configuration. The proxy connects to Sophos Mobile through an HTTPS web interface, checks device identity and required policy status, and forwards eligible EAS requests. The proxy can also be configured to block specific devices; this is separate from the compliance check and individual Exchange ABQ entries. The actual mail server does not have to be directly accessible from the internet for this proxy mail path. This does not guarantee that every request is checked: the Traveler exception described below still applies. Here the proxy is in the mail path: proxy availability and throughput matter to mobile mail access.
• PowerShell mode: Device → Exchange directly; separately, Sophos Mobile EAS service → Exchange management interface. The Sophos service also connects to Sophos Mobile through an HTTPS web interface. Mail traffic does not pass through the Sophos proxy, so its host does not need a firewall port for incoming mail. Exchange reachability and the management and control connections still need to be planned. Sophos lists Exchange Server 2016/2019 and Microsoft 365 with an Exchange Online plan as targets. This product statement does not yet establish that the installed proxy version, the specific client, its sign-in and the tenant work together today. Mail-relay sizing from proxy mode cannot be carried over to this mode.

Network paths in the dated client-certificate example: The Sophos architecture diagram (English page dated April 12, 2023, German page dated April 27, 2023) places Sophos Mobile, the EAS proxy, and Exchange inside a dashed customer environment labelled “Customer”; devices are outside it. This illustrates a customer-operated topology, not a universal requirement for Sophos Mobile deployments or evidence of a firewall or DMZ boundary. Alongside the EAS mail path, there is a separate MDM path from device → Sophos Mobile over HTTPS; in the diagram, this device-management path does not pass through the EAS proxy. It is distinct from the EAS proxy → Sophos Mobile HTTPS control connection already described.

The diagram’s endpoint table contains only schematic example values, not operational endpoints to adopt or blanket firewall approvals:

The names smc.company.com and eas.company.com and the target ports belong to this example. By contrast, the EAS proxy → Exchange arrow is labelled only http/s; no backend port is specified. This retains the schematic HTTP/HTTPS representation but neither requires unencrypted backend traffic nor grants blanket approval for it. It also establishes nothing about TLS termination or certificate trust. Actual endpoints, ports, and the secured backend connection must be checked and approved separately for your environment; the arrow directions do not exclude response traffic. The diagram extends neither the product and version limits below nor the supported mail-server matrix.

Central example with a separate customer environment: Another archived architecture places Sophos Mobile in Central within Sophos Central, while EAS proxy and Exchange are within Customer. Devices are outside both areas. Their separate MDM path runs over HTTPS to Sophos Mobile in Central; the text box names central.sophos.com for this path. By contrast, the ActiveSync mail path runs over HTTPS to eas.company.com at the customer-operated EAS proxy and from there over http/s to Exchange. A separate HTTPS arrow from the EAS proxy to Sophos Mobile in Central also shows the control connection crossing the illustrated customer/Central boundary. MDM, mail and proxy control are therefore three distinct paths, not a shared route through Central.

The endpoint table in this Central example contains exactly one mapping: https://eas.company.com/Microsoft-Server-ActiveSync → HTTPS → EAS Proxy:443. It specifies neither a Central MDM destination port nor an Exchange backend port. Here too, the hostnames are schematic archive examples, not operational endpoints for your own tenant. The dashed areas do not establish a firewall or DMZ layout; http/s neither authorizes unencrypted traffic nor establishes how TLS is terminated.

For proxy mode, Sophos describes multiple supported Exchange or Traveler mail servers with one EAS proxy instance per mail server.

Scaling a mail path is a separate matter: instances can run on several computers behind a load balancer. Client certificates are also supported: select a certificate from a certification authority (CA); the client certificates must derive from that CA. In the client-certificate mode illustrated by Sophos (architecture example dated April 12, 2023), the EAS proxy checks the presented client certificates against the selected CA certificate and blocks both clients without a client certificate and clients with an invalid client certificate. This documented blocking condition applies only to the illustrated client-certificate mode; it proves neither enforcement in your own build nor specific invalidity or revocation checks. Keep this client authentication separate from the PowerShell connection certificates later uploaded to Sophos Mobile. Instances, load balancing and certificate trust must be planned and tested for the specific environment.

Specific load balancing in the archived example: The load-balancer diagram places Sophos Mobile, a load balancer, two EAS proxies and Exchange inside Customer, with devices outside. The device MDM path runs over HTTPS directly to Sophos Mobile (smc.company.com); the device ActiveSync path runs over HTTPS to the load balancer (eas.company.com). Two separate arrows, jointly labelled http/s, lead from the load balancer to the two proxies. Each proxy has its own HTTPS control connection to Sophos Mobile and its own http/s mail path to Exchange. In this illustration, control therefore does not run from the load balancer to Sophos Mobile.

The complete mappings in the image’s table can be presented without a wide table:

• MDM: https://smc.company.com/* → HTTPS → SMC Server:443; both subsequent table fields are -. The asterisk is part of the illustrated example URL.
• ActiveSync, Proxy 1: https://eas.company.com/Microsoft-Server-ActiveSync → HTTPS → Load balancer:443 → http/s → EAS Proxy 1:81.
• ActiveSync, Proxy 2: https://eas.company.com/Microsoft-Server-ActiveSync → HTTPS → Load balancer:443 → http/s → EAS Proxy 2:81.

Port 81 here identifies the proxy destinations behind the load balancer, not Exchange. The image specifies no Exchange backend port. This schematic archive illustration is neither blanket firewall approval nor evidence of TLS offloading, certificate forwarding, session affinity, health checks, a particular load-balancing algorithm or guaranteed high availability. The frontend/proxy port mapping does not replace planning and approval of the actual connections.

Distinguish the PowerShell image from textual evidence: The archived Central PowerShell image places EAS Proxy within Company, Sophos Mobile in the separate Sophos Central area, and Office 365 Exchange Online with outlook.office365.com in a separate area below with no visible name. The labels https and Query device compliance list appear between Company and Sophos Central. Beside the EAS proxy is Needs PowerShell 3.0 or higher. This is a historical image label, not a current minimum version or proof of support; the checks of the specific build and PowerShell host required below remain decisive. Connecting arrows cannot be reliably identified in these archived pixels. The distinction above between the direct device mail path and the separate Exchange management connection is therefore a documented textual statement, not an arrow direction read from this image. The image also provides neither numeric ports nor an endpoint table; the hostname label does not establish a current Exchange Online sign-in or transport path.

Put dated sizing guidance in context: In its Sizing Considerations dated April 14, 2022, Sophos describes low CPU and memory requirements for the EAS proxy, identifies bandwidth as the main limitation, and recommends 1 CPU and 2 GB of RAM. For large installations, this source recommends multiple EAS proxy instances behind a load balancer; PowerShell mode does not require this mail-relay arrangement. This is a dated recommendation from documentation, not a benchmark, a verified current minimum or a capacity guarantee. Check the specific build, mail load and available network paths with the operations team, and validate sizing in an authorized environment before approval; these figures alone do not authorize production use.

Before setup, clarify network integration with the operations team: record the device mail path, Sophos Mobile HTTPS control connection and, where applicable, Exchange management connection separately. Sophos lists supported mail servers in the Requirements section of the Mobile release notes. For handoff, confirm the mail-server matrix applicable to the intended build, the target build and its lifecycle; a general product list is not enough. Host, network and installation prerequisites belong in the separate EAS installation preflight, not in an implicit approval based on this mode selection.

Both variants control EAS, not arbitrary mobile mail protocols. Sophos excludes Macs from this control path, citing the lack of ActiveSync support in macOS; this is not a statement about every possible third-party mail client on a Mac. With IBM Traveler, requests from non-iOS devices without a device ID may be passed through without the proxy being able to check their authorization.

In proxy mode, Outlook on Android/iOS may fail to associate a user with an ActiveSync ID, for example when several devices are not yet known or when reinstalling the app creates a new ActiveSync ID that does not match the stored entry. Not every reinstallation necessarily causes this error; an identical failure in PowerShell mode is not established by this. According to Sophos, this specific association problem does not occur with Gmail on Android or Mail on iOS because Sophos Mobile receives their ActiveSync ID during enrollment. This does not rule out other mail errors. Check the mail apps, protocols and device IDs actually used in both modes. For failed to resolve active sync id, first use EAS troubleshooting for read-only investigation. An association error authorizes neither an ID reset nor a changed user assignment; agree any necessary repair with the operations team only after unambiguously identifying the device and obtaining separate approval.

Separate Exchange Online Outlook/Conditional Access exception: When a user signs in to Outlook for iOS or Android, Microsoft says Exchange Online mobile device access Allow/Block/Quarantine (ABQ) rules are skipped if a Microsoft Entra Conditional Access policy applied to that user includes Exchange Online or Office 365 as the cloud app, iOS and/or Android as the device platform, “Mobile apps and desktop client” as the client apps, and at least one grant control: require a compliant device, an approved client app or an app protection policy. This is not a bypass for every Outlook user or every Conditional Access policy, and Conditional Access may still restrict access. Microsoft warns that ABQ alone provides no security guarantee: a client spoofing the DeviceType header may evade a device-type block. For Exchange Online, also check whether Basic Mobility and Security policies or access rules apply: after enrollment in that service, its policies and access rules override Exchange mobile device mailbox policies and device access rules for the device. Do not treat either an ABQ decision or the absence of this particular Conditional Access exception as a security boundary. It is distinct from the proxy-mode Outlook ActiveSync-ID association problem above. For Exchange Online, Microsoft describes Outlook mobile’s native sync path rather than EAS; confirm the actual client protocol before attributing access to EAS controls. The EAS-specific sign-in checks below apply only where EAS is actually used; for other clients test the real mail-app sign-in and data path. For this qualifying route, do not assume that Sophos-backed Exchange ABQ decisions or quarantine enforce access merely because the PowerShell management connection works. Before recommending the architecture, check the target tenant’s effective user identity, mail app, applied Conditional Access cloud-app/platform/client-app/grant conditions and Exchange device access decision; verify each representative device’s actual sign-in, sending, receiving and synchronization under authorized tests.

Assess Exchange Online and the server lifecycle separately

Exchange Online—no Basic fallback: Microsoft has disabled Basic Authentication for EAS client sign-ins and for Remote PowerShell in all tenants; it cannot be re-enabled for either. A Basic fallback would therefore fix neither management sign-in nor an EAS mail app that uses Basic sign-in. The Sophos setup guide dated September 9, 2026 does not describe a “modern authentication, then Basic on failure” flow; its absence does not establish any other sign-in flow used by the service either. Sophos setup text still mentions /powershell-liveid; Microsoft supports REST connections for Exchange Online PowerShell. Whether a particular Sophos build uses that path is not established by this. Sophos instructions for Basic on the on-premises Exchange PowerShell directory are not instructions for Exchange Online. Do not enable Basic or WinRM Basic as a remedy for Exchange Online.

Exchange Online—check TLS and sign-in separately: The Sophos “Allow all certificates” option disables server certificate validation and weakens connection security; it does not demonstrate a supported TLS or REST management path and does not solve the Basic Authentication shutdown. Check certificate trust and the TLS connection rather than bypassing certificate validation. Obtain confirmation from Sophos for your environment of support for the exact proxy build, the ExchangeOnlineManagement module version, the PowerShell host actually used by the service and its version, the Windows version and the .NET Framework or .NET version according to Microsoft’s module/host/OS matrix, the cloud, the OAuth/REST management path, account permissions, MFA and Conditional Access. Neither installing a module nor having a compatible host version proves which transport the Sophos service actually uses or whether its sign-in works. Two separate checks are needed in an authorized test tenant: Can the service manage Exchange (connection and permissions), and can the intended devices sign in to EAS and synchronize using their actual mail app? A successful management connection does not prove mail access.

On-premises Exchange Server: The Sophos setup guide requires enabling BasicAuthentication for the on-premises Exchange PowerShell directory path. This does not establish that every on-premises management connection always uses Basic; it concerns neither EAS client sign-in nor Exchange Online and is not blanket approval to enable Basic locally. Local authentication and hardening require separate security approval. Sophos lists Exchange 2016/2019; Microsoft’s regular support for both ended on October 14, 2025. Exchange Server Subscription Edition (SE) is not included in that Sophos statement. A Microsoft migration option is not a Sophos certification. Obtain separate confirmation of the server build, lifecycle or any special support arrangements, and Sophos support for this exact target instead of inferring production approval from an architecture diagram.

What an approved PowerShell setup includes

PowerShell setup includes host preparation, a dedicated Exchange service account, the instance connection and its certificate association. The documented steps and fields below help with handoff to the operations team; they replace neither verification of the specific build and sign-in path nor an approved change. The separate EAS installation preflight covers host, service-account and installation checks, but is not an approved setup runbook either. Do not change execution policies, on-premises Basic settings or system-wide proxy settings, or restart services, solely on the basis of this article. Document and approve their baseline, impact and backout path separately.

Host, on-premises Exchange and service account

• On the EAS host: Sophos mentions installing Windows PowerShell if needed. Before installation, confirm its version and suitability for the specific build with the operations team. The guide then describes changing the execution policy to RemoteSigned in a PowerShell session opened as administrator. This preparation does not establish which PowerShell host the Sophos service uses or whether it is compatible with it.
• On-premises Exchange Server only: In the Exchange Management Shell, Sophos describes a separate RemoteSigned step, followed by identifying the actual PowerShell directory with Get-PowerShellVirtualDirectory -Server <server name>. The placeholder represents the Exchange Server computer name, not the EAS host or instance name. Sophos names PowerShell (Default Web Site) as the directory only for a default installation. In the official guide, enabling BasicAuthentication for the relevant virtual directory follows only after this identification. That change is reserved for separately approved on-premises setup; it explicitly does not belong in an Exchange Online setup.
• Service account: Sophos uses a dedicated user account on the Exchange mail server to execute PowerShell commands. Account creation differs between Exchange Server and Exchange Online; clarify account creation, permissions and sign-in methods with the Exchange team for the specific target as part of the EAS installation preflight. A password field is not enough; do not create an account or roles here.

Connection wizard and completion

The connection is prepared in the installation wizard; running it is reserved for the separately approved installation change. The following fields are documented on EAS Proxy instance setup:

• Instance type: PowerShell Exchange/Office 365.
• Instance name: A name you choose to identify the instance unambiguously.
• Exchange server: For on-premises Exchange, the server name or its IP address; for the global Microsoft 365 service, Sophos specifies outlook.office365.com. For other clouds, confirm the appropriate connection endpoint separately with the Exchange team; Sophos refers to the -ConnectionUri mapping of Connect-ExchangeOnline. According to Sophos, https:// and /powershell-liveid are not entered in this field because the wizard adds them. This documents field behaviour, not an Exchange Online transport verified for 2026. Do not guess a replacement endpoint; the build, cloud and sign-in checks required above remain necessary.
• Service account and Password: The name and password of the previously created service account. Do not put credentials in audit files, examples or tickets; the fields alone do not establish an authentication method.

Add puts the connection in the Instances list. For additional Exchange Server instances, Sophos describes repeating this configuration and then completing the wizard. Despite this field overview, Allow all certificates is not a recommended shortcut: check certificate trust rather than disabling server validation.

Optional outbound connection proxy: If the EAS host must reach Exchange Server or Exchange Online through a network proxy, Sophos describes a WinHTTP step on the EAS host in a command prompt opened with Run as administrator. The actual WinHTTP configuration is reserved for the operations team and the approved installation change; it is not proxy mode for device mail. The setting is system-wide and may affect other programs on the Windows host. Before such a change, these dependencies also need a documented baseline and an approved backout path; this is not a general proxy fix for sign-in errors.

To complete setup, Sophos describes uploading the PowerShell connection certificate generated during configuration under My Products > Mobile > Setup > Sophos setup > EAS proxy > External > Upload a file. With multiple instances, upload all instance certificates, then select Save and perform an approved restart of EASProxy in the Windows Services dialog. Agree the maintenance window, service state and backout path with the operations team. Saved certificates or a new Last active value prove neither successful device sign-in nor mail delivery: sign-in, sending, receiving and sync must still be checked for each affected device before and after the change.

Before any change to EAS access

With an already configured and verified PowerShell control connection, Exchange can be configured to quarantine devices not enrolled in Sophos Mobile and deny them mail access. This applies only where the protocol and ABQ limitations described above permit this control. Blocking unenrolled devices is a separate organization-wide access change for the Exchange/Mobile operations team, not the final step of installation. Its architecture and security preflight follow here; setting up the control connection belongs in the separate EAS installation preflight. Sophos describes an Exchange notification asking users to enroll. In the documented example, Set-ActiveSyncOrganizationSettings with -DefaultAccessLevel quarantine sets the organization-wide default; -UserMailInsert adds a customizable enrollment notice to the quarantine email. This article does not recommend executing the command. Prerequisites, impact and the approved backout path must be clarified first.

The administration context differs: on-premises Exchange Server uses the Exchange Management Shell; the cloud requires a separately verified Exchange Online PowerShell connection with an appropriate account and supported sign-in/transport path. A local shell or its Basic setting does not replace a verified cloud connection.

Organization-wide Exchange quarantine is not a pilot switch for a single test device. Where Exchange ABQ is actually enforced, changing the Exchange default access level from “Allow” to “Quarantine” can immediately affect already-connected EAS devices, not just unknown or new devices, unless a device access rule or an individual Allow/Block decision applies. Do not assume this effect for the qualifying Exchange Online Outlook/Conditional Access route described above: Exchange ABQ rules are skipped there. In PowerShell mode, even already-enrolled devices can enter quarantine if their compliance status is unknown after a missed synchronization or when the connection to Sophos Mobile is disrupted, provided ABQ applies to their route. Automatic approval after successful enrollment depends on a working control connection; it is not a guaranteed recovery mechanism.

Before an approved change, record the existing Exchange DefaultAccessLevel, notification text, existing device access rules and individual Allow/Block entries, as well as the device and mail-app inventory, current sync and compliance status, certificate trust and responsible owners. Observe allowed, unknown and temporarily unassessable devices for test mailboxes; inspect available Sophos, Exchange and Entra events for decisions and connection failures, and verify their association with each device in the target tenant. Before the change, use agreed test mailboxes to check actual EAS sign-in, sending, receiving and sync for each affected device; events alone do not prove the impact. In the Sophos menu My Products > Mobile > Setup > Sophos setup > EAS proxy, the External > Last active value for each proxy instance shows only its last contact with Sophos Mobile, not successful sign-in, delivery or authorization for every device.

The approved backout path must cover restoring the documented default access level, rules, individual decisions and notification text, with assigned responsibility and abort criteria. Restoring only the default is not proof of recovery: Devices may remain in an unexpected state; after backing out, individually check actual EAS sign-in, sending, receiving and sync for affected devices with the agreed test mailboxes, including after stale compliance status or a failure of the Sophos control connection. Until authentication, the mail path and the backout path have been demonstrated and the change approved, this article recommends neither installation nor switching to quarantine nor migration.