Set up Intune app protection in Sophos Mobile and renew the Azure certificate

Intune app protection (MAM) restricts business data in supported apps based on user identity. The policy applies to an assigned user’s work account, not indiscriminately to their personal accounts or the entire device. Sophos Mobile device enrolment is not required. MAM can also be used on an already managed device, but it is neither Intune MDM enrolment nor a Sophos Mobile device policy. It also does not set up the separate Intune Mobile Threat Defense connector for security status from Sophos Intercept X for Mobile.

Before making changes: tenant, permissions and scope

Record the Sophos Mobile tenant and intended Microsoft Entra/Intune tenant in writing. Identify an authorised Sophos Mobile administrator, the responsible Microsoft app/Intune administrator and the person authorised to grant tenant-level consent. Before registration, ask the Microsoft team to inspect the application name, tenant, Application (client) ID, requested API permissions with their permission types and scopes, consent status, required roles and any existing app registrations as actually displayed, and to approve them for this specific tenant. Sophos requires an Azure app registration, application ID, certificate upload and required permissions, but its setup guide does not specify the API scopes, consent type or required RBAC roles. Even familiar Microsoft Graph permission names are therefore not confirmed requirements of the Sophos wizard. Stop here until the actual permission request has been reviewed and approved; do not grant permissions on a guess.
Sophos specifies Microsoft Entra ID P1 or P2 and an Intune licence assigned to the relevant Entra account. Outlook requires an Exchange Online mailbox and an appropriate licence; Word, Excel and PowerPoint require a Microsoft 365 Business or Enterprise licence on the account. Also check the entitlement to use mobile Office apps under the specific subscription. A visible Sophos menu option does not replace a licence or permission check.
Choose Android or iOS/iPadOS, a supported Microsoft 365 app or another app with the Intune App SDK integrated that is already in the correct tenant’s Intune app inventory, and a small Microsoft Entra ID security group. Document the work account, group membership, existing app protection policies and intended business-data flows. Check the effective behaviour of existing overlapping policies and Conditional Access before the pilot; do not assume the new Sophos policy alone takes precedence.
Before piloting on managed devices, work with the authorised Intune administrator to check the actual enrolment type, app type and targeting by device management status (all app types or specifically managed or unmanaged devices). For Android Enterprise, Microsoft’s policy deployment troubleshooting guidance describes personally owned devices with a work profile for the usual personal work-profile scenario; do not read that as excluding documented Shared Device Mode exceptions. Microsoft’s app protection overview also documents app protection policies for Intune-managed Android Enterprise dedicated devices with Shared Device Mode and userless AOSP devices with Shared Device Mode; dedicated devices without that mode are not supported. For Shared Device Mode, Microsoft notes an exception when PIN for access or work or school account credentials for access are enforced; if blocked during a PIN reset, the affected user must unblock access using Remove account. Do not infer general support for other enrolment types or every app and setting combination: check the specific device type, app, setting and effectively applied policy on the pilot device. If targeting only Intune-managed iOS/iPadOS devices, the required MDM app configuration values must also be in effect for the affected apps in addition to the app protection policy: IntuneMAMUPN and IntuneMAMOID for MDM-managed apps (managed by Intune or a third-party EMM), and IntuneMAMDeviceID as the device ID token for MDM-managed third-party and LOB apps. With only DeviceID, Intune treats the device as unmanaged for this protection. Check the existing values and effective assignment for each pilot app and device; do not set keys or broad targeting on a guess. A policy displayed in Sophos or group membership alone does not establish protection on managed devices.
Clarify sign-in prerequisites for each platform with the Microsoft administrator. On Android, the Intune Company Portal app is required to receive the app protection policy. For Microsoft 365 apps, Microsoft also requires Microsoft Entra device registration for Android MAM; account for the broker app when app-based Conditional Access is in use. On iOS/iPadOS, Microsoft Authenticator may be required as a broker. Broker installation or Entra device registration is not Intune MDM or Sophos Mobile MDM enrolment. Observe sign-in, MFA and Conditional Access during the pilot rather than claiming a universal device requirement.
For Word, Excel or PowerPoint, provide a managed storage location through the granular Save As capability of Microsoft’s Save copies of org data setting. If OneDrive is the storage location, also assign the OneDrive app to the pilot user through an app protection policy and configure the work or school account in the Office app. A new file not saved in a business storage location may be treated as personal; test with a file known to be business data.

Create and validate a narrowly scoped MAM policy

The following English menu names come from Sophos guides. Your current console may use different labels; if so, confirm the actual steps with the authorised administrator rather than choosing a similarly named MDM or Threat Defense menu item.

Connect the tenant and create the policy

In the interface described by Sophos, open Setup > Sophos setup > Microsoft Azure and the Microsoft Azure registration wizard. The wizard guides registration across both portals: the authorised Microsoft administrator creates an application for Sophos Mobile in the Microsoft Azure portal. Enter its application ID in Sophos Mobile and check it against the approved tenant and intended application. Then upload the Sophos Mobile certificate to this Azure application. Compare the requested permissions with the preapproved list, grant only the approved permissions and give only the approved consent. If anything differs, stop before granting permissions. After completion, Sophos specifies Policies > Intune app protection. The appearance of this menu proves neither effective API permissions nor an active policy.
Open Policies > Intune app protection. When opening the policy and assignment pages, Sophos may redirect you to a Microsoft page for authentication. On the verified Microsoft page, the authorised administrator signs in with the intended Microsoft Azure administrator account for the correct tenant; this is distinct from the pilot user’s subsequent sign-in within the app. On Policies - Intune app protection, use Add > Android policy or Add > iOS policy to create the appropriate pilot policy; Sophos requires separate policies for Android and iOS/iPadOS. Enter the approved settings on Edit policy. Allow data transfers between apps, Save As, clipboard, contacts and app access according to the data flow, and check them by platform. The English Sophos settings pages are dated 22 November 2022, and the German pages 3 March 2025; both contain older labels such as Managed Browser. Neither this label nor the page date establishes current browser support. Data transfers can have exceptions, and some iOS apps ignore restrictions on incoming data. Do not promise that all data paths are blocked. Record the following decisions, including offline thresholds, with the authorised Intune administrator before selecting Save.

Decide on data flows before Save

The effects of these options are described in the English Sophos settings pages dated 22 November 2022. Use them to plan the pilot, not as evidence of current console fields or app support. Each selected feature must match the actual console, app and device type.

Choose outgoing transfers and incoming data separately: Allow app to transfer data to other apps controls destinations; Allow app to receive data from other apps controls where data comes from. For both Android and iOS/iPadOS, Policy-managed apps allows only other apps managed by an Intune policy; All apps allows any app, and No apps blocks the respective direction. Account for the documented transfer exceptions; some iOS apps allow all incoming data despite reception restrictions. For outgoing transfers on iOS/iPadOS, Sophos also describes blocking Siri searches for data within the app when Policy-managed apps or No apps is selected.
Limit the clipboard separately: Under Restrict cut, copy, and paste with other apps, Blocked blocks cutting, copying and pasting between apps; Policy-managed apps allows these only between policy-managed apps. Policy-managed with paste in allows cutting or copying only between those apps, but permits content from any app to be pasted into the protected app. All apps leaves the clipboard unrestricted in either direction. The paste-in option therefore treats outgoing data differently from incoming content.
Treat storage locations as one connected decision: According to Sophos, Prevent “Save As” disables the Save As function. When this option is selected, destinations selected under Storage locations remain available for business data; other destinations are blocked. This complements the Office storage planning above; the older Sophos field names should not be treated as identical to Microsoft’s current Save copies of org data setting. OneDrive assignment and a work account remain prerequisites for the corresponding Office pilot.
Choose contact export deliberately: According to both platform pages, Disable contacts sync prevents the app from saving data in the Contacts app. This does not establish that previously exported contacts are deleted. For iOS/iPadOS, also record whether Prevent iTunes and iCloud backups should prevent app data backups to those destinations and whether Disable printing should prevent printing in the app. Do not enable every option indiscriminately; check only the approved data flows.
Understand iOS/iPadOS encryption: According to Sophos, Encrypt app data uses device encryption, not separate app encryption. When device is locked protects app data while the device is locked; When device is locked and there are open files excludes data in files that are currently open. When device restart describes protection after a restart until the first unlock; Use device settings follows the device settings. Document the option appropriate to the pilot device and its limits with the administrator; do not assume a current default.

Decide on app access and time limits

Here too, the effects described come from the dated Sophos pages, not from verified behaviour on the pilot device. Obtain approval for the access method and time limits before saving:

PIN or work password: According to Sophos, Require PIN for access prompts users to set up a PIN when they first sign in with their work account. The Android page states that Intune-managed Android apps share the same PIN; on iPhone and iPad, this applies only to apps from the same publisher. Require corporate credentials for access requires the work password instead and takes precedence over the other PIN requirements. The Shared Device Mode exception above still applies; not every device type supports every access setting.
When using a PIN on iOS/iPadOS: Under Password type, choose between Numeric (digits only) and Passcode (at least one letter, special character or symbol from the English keyboard); some apps do not support Passcode. Record the minimum length, prohibition of simple PINs, failed-sign-in threshold for a PIN reset and whether Touch ID/Face ID is allowed. For Passcode, Forbid simple PIN requires at least one digit, one letter and one special character or symbol. According to the source, Forbid fingerprint and Forbid facial recognition prohibit Touch ID and Face ID respectively as substitutes for the PIN. The reset threshold triggers a PIN reset, not a data wipe. Numeric values and available biometric alternatives must match the approved pilot app and test device; the source provides no defaults.
Recheck access: Access requirements timeout is a period in minutes after which access requirements are checked again when the app starts. Within that period, Sophos describes using other Intune-managed apps without entering another PIN after the first PIN entry: across Android apps, but only for the same publisher on iOS/iPadOS. This timer is neither the offline grace period nor the offline wipe interval. Document the approved value and expected repeat prompt for the selected app.
Allowed devices and versions: For iOS/iPadOS, record whether Block managed apps from running on jailbroken devices should block work-account use on those devices. Distinguish required minimum versions for iOS/iPadOS, the app and, where applicable, the Intune app protection SDK from recommended minimum versions for the operating system and app. Required is an access condition; according to the source, Recommended produces a dismissible message, and an empty version field ignores that condition. If the Android pilot uses version limits, the same distinction applies there to the operating system, app and security patch level; the patch date uses YYYY-MM-DD. Record both enabled limits and those deliberately left unused; choose specific minimum versions from the approved requirements and app compatibility. The source provides no defaults. An observed warning is not evidence that access is blocked.

Distinguish the independently configurable offline grace period (minutes) for rechecking access from the offline interval before business app data is wiped (days): when either threshold is reached, the app requires a network connection and reauthentication. For the wipe interval, business app data is wiped only if reauthentication fails. Confirm the actual thresholds in the pilot rather than assuming a fixed order. Both dated Sophos platform pages explicitly state that, for Outlook, wiping app data also removes data saved in the Contacts app; this has not been tested here with a current app version in the tenant. This is not an automatic device wipe merely because time has passed. Test destructive thresholds and contact synchronisation only after approval and with a non-production test account, not with production contacts.

Save, assign and validate in the pilot

Save the approved policy values on Edit policy using Save. Back on Policies - Intune app protection, open the blue triangle next to the intended policy and select Assign apps. Select only the intended apps for the appropriate platform and save this app assignment using Save. According to Sophos, the list contains apps already added to the Microsoft Intune account.
On the same policy list, open the blue triangle next to this policy again and select Assign user groups. Assign Microsoft Entra ID security groups separately from the apps: Include includes members, Exclude takes precedence even when a member is also in an Include group, and Not assigned does not exclude members included through another group. After selecting the groups and their states, save the user group assignment separately using Save. Only members with an assigned Intune licence are affected. Both the app assignment and effective user assignment are required; neither Sophos device groups nor a device MDM assignment is the targeting mechanism here.
As documented by Sophos, view the saved policy and the app and user assignments in the Microsoft Azure portal, and check them against the intended platform and pilot scope. If the display is out of date, you may need to sign in to the portal again. Sophos does not specify a current submenu path for this; confirm the actual portal view with the authorised Microsoft administrator. Then use a licensed pilot account to open the supported app in the work context, complete broker and sign-in requirements, and observe a nondestructive restriction and a business storage location; test a personal account separately. If managed devices are in scope, also verify the enrolment type checked earlier, the iOS app configuration status and the app protection policy effectively applied in the target app on the specific pilot device. Record the tenant, app, platform, account, groups, policy and observed result. A visible policy alone is not proof of enforcement. If the result differs, stop the rollout and check permissions/consent, certificate, licence, app support, broker/Conditional Access and effective group membership.

For nondestructive validation, use a non-production, licensed test account and a test file recognised as business data. Record the expected result for each data flow beforehand:

Compare transfers and copying from the target app to an intended policy-managed app with transfers to an unapproved personal destination. Use synthetic business data, not confidential production data. Test incoming pasting separately, particularly with Policy-managed with paste in and with iOS apps that may ignore reception restrictions.
Try saving the test file to an allowed location and to a location blocked by the pilot policy. Using only a new personal file would not be a reliable test of business-data protection.
Observe the expected initial PIN or password prompt and the repeat access check when the app starts after the approved timeout. Do not force failed sign-ins to trigger a PIN reset; according to the source, it results from the configured failed-attempt threshold and is not evidence of data deletion. If version limits have been selected, assess warnings separately from access conditions. Do not root or jailbreak devices for testing.
Check other approved iOS data flows, such as backups, contacts or printing, only within the agreed test scope. If a data flow is unexpectedly allowed, do not approve that app, device and policy combination for rollout; investigate with the administrator and retest after a targeted correction.

Renew the certificate before it expires

Sophos states that the integration’s Microsoft Azure certificate is valid for one year. Without timely renewal, Intune app protection in Sophos Mobile stops working. According to Sophos, merely starting renewal temporarily interrupts the Intune app protection integration until the new certificate is uploaded. This does not establish whether policies already delivered to apps continue to be enforced unchanged during that time. Set a maintenance window and identify the responsible people for both portals; record the tenant, Application (client) ID, old fingerprint and expiration date beforehand. Do not start unless upload and immediate validation are possible.

Sophos describes the following renewal procedure; here too, check the actual console labels before making changes:

Open Fusion > My Products > Mobile > Setup > Sophos setup > Microsoft Azure. Check the expiry date under Certificate information > Expiration date. Select Renew certificate and confirm the dialogue using OK. Sophos creates a new certificate and updates Thumbprint, Start date and Expiration date. Record these values; they do not yet prove that the certificate has been uploaded or the integration restored. Use Download certificate to download the new certificate file.
Sign in to the Microsoft Azure portal with the approved Azure administrator account in the correct tenant. Search for App registrations, open the service and select the Sophos Mobile application with the same Application (client) ID. Under Certificates & secrets > Upload certificate, select precisely the new file downloaded from Sophos Mobile and complete the upload using Add. Do not register a new application for this renewal.
Compare the new fingerprint in both portals, then reread the integration and an existing pilot policy and check them with the work account. Remove the old certificate entry only after comparing fingerprints and completing an approved functional check: in the Microsoft Azure portal, open the existing Sophos Mobile application, go to Certificates & secrets and use Delete next to the old certificate. Do not delete the app registration or the new certificate. If the app ID is wrong, the upload fails or an unexpected outage occurs, do not preemptively delete the old entry; pause the change and escalate. Automatic reversion to the old certificate or recovery after expiration has not been established.

Safe rollback and approval status

If a pilot fails, document the previous settings and other policies, then work with the authorised Intune owners to selectively revert only the pilot app or pilot group, or the problematic setting. Recheck the effective policy and work account; do not promise immediate restoration. Do not remove the device from MDM or disable the Threat Defense connector. Removing an assignment or deleting the Azure app registration is not an established immediate selective data wipe. Deleting a certificate or app registration affects more than the pilot and requires separate approval.

Status: Editorial draft. The exact current Sophos wizard scopes, consent and roles, as well as tenant-side effects, certificate recovery and data consequences, have not been verified in practice; not approved for production changes.