How Small Businesses Set Up Mobile Application Management Without the Creepy Factor

On January 19, 2026, Microsoft flipped a switch. Organizations running outdated versions of Outlook, Teams, and OneDrive on employee phones found those apps suddenly locked out of corporate data. Once enforcement hit, there was not much room to react. If the app didn’t meet Intune’s new minimum SDK version requirements, it simply wouldn’t open. Adelia Risk helps small and midsized businesses set up mobile application management (MAM) in Microsoft Intune, and we fielded a wave of calls that week from IT teams scrambling to figure out why half their staff couldn’t check email on their phones. The pattern was the same every time: a company had MAM configured but hadn’t kept up with Microsoft’s evolving requirements. That January enforcement was a useful reminder that MAM is not a one-time setup. Another deadline is coming in June 2026: Microsoft says it will stop enforcing the ‘Require approved client app’ grant in Conditional Access, so organizations that have not migrated to app protection policy-based controls could end up with weaker protection than they expect.

This article walks through what mobile application management actually does, why it’s different from the device management that makes employees nervous, how to set it up correctly, and what to watch for during rollout. We’ve deployed this for dozens of SMBs using our MAM configuration checklist, and the settings below reflect what we’ve learned works in practice.

How Mobile Application Management Differs from Mobile Device Management

The most common question we hear from business owners is some version of “will this let my company spy on my phone?” The answer with MAM is no, and that distinction matters. But before the privacy question, the more basic one: what is MAM, and what does it actually do on an employee’s phone?

The difference between MAM and MDM comes down to scope. Mobile application management and mobile device management solve different problems. MDM manages the device more broadly. It can enforce device passwords, deploy apps, configure Wi-Fi, apply device-level settings, and, on supported company-owned devices, provide more control over location and full device wipe. This level of control makes sense for company-issued devices. On personal phones, it is often more control than employees are comfortable with.

MAM takes a narrower approach. It only controls what happens inside work apps like Outlook, Teams, and OneDrive. It can encrypt company data within those apps, require a PIN to open them, restrict copy/paste from work apps to personal apps, and wipe corporate data if someone leaves the company. It does all of this without enrolling the device, without seeing personal data, and without giving IT the kind of device-wide control that worries employees.

Neither MAM nor MDM gives the organization access to calling history, text messages, personal email, contacts, personal calendar, passwords, photos, or browsing history.

That privacy guarantee is why MAM works for BYOD. Microsoft publishes a full list of what your organization can never see on employee devices, and that transparency is a big reason MAM adoption goes smoothly. When employees can verify for themselves that the company can’t touch their personal data, most of the resistance disappears.

The Verizon 2025 Mobile Security Index found that 85% of organizations said mobile device attacks are on the rise. The same report says 50% experienced a mobile or IoT-related incident that resulted in data loss, and 46% reported downtime. For most SMBs with a BYOD policy, MAM is often the right balance between protecting company data and respecting employee privacy.

When MDM Makes More Sense

Intune MAM vs MDM isn’t an either-or decision for every organization. If your business issues company-owned phones, MDM solutions for small business environments give you more control. If you handle Controlled Unclassified Information (CUI) under CMMC Level 2, NIST SP 800-171 controls that apply to external and mobile devices often push organizations toward fuller device management rather than app-only controls. And if you need to deploy apps remotely, configure VPN settings, or enforce device-level encryption, MAM can’t do those things on its own. For most SMBs using Microsoft 365 with a mix of personal and company devices, MAM covers the gap.

Two Deadlines You Can’t Afford to Miss

• Check your apps for current Intune MAM version compliance: Starting January 19, 2026, or soon after, Microsoft began blocking launches for outdated supported apps. Android devices need Intune Company Portal version 5.0.6726.0 or later. On iOS, wrapped and SDK-integrated apps need Microsoft’s current supported Intune SDK or wrapper versions.
• Migrate off the ‘Require Approved Client App’ Conditional Access grant before June 30, 2026: After this date, Microsoft stops enforcing that grant control, so any policy that still relies on it will no longer apply as intended. Move to ‘Require app protection policy’ as part of the migration.

The January 2026 SDK enforcement has already caught organizations off guard. If Android devices don’t have Company Portal version 5.0.6726.0 or later, every managed app on that device gets locked out. One outdated app can take down Outlook, Teams, and OneDrive access at the same time. You can check your current status in the Intune admin center under Apps > Monitor > App protection status.

The June 2026 deadline is the one many teams have not planned for yet. Microsoft is retiring the ‘Require Approved Client App’ Conditional Access grant. If your Conditional Access policies still rely on that grant, Microsoft says it will stop enforcing it after June 30, 2026\. The migration path is straightforward: move those policies to ‘Require app protection policy’ and test the impact before the deadline.

At Adelia Risk, we check for both of these during every Microsoft 365 security review. The SDK enforcement issue is fixable in a few minutes per device. The Conditional Access migration takes more planning but is straightforward if you start now.

What You Need Before You Start

Before You Start

• Confirm your Microsoft 365 license includes Intune: Microsoft 365 Business Premium and Microsoft 365 E3 both include Intune Plan 1, which covers mobile application management. As of Microsoft’s current US pricing pages, Business Premium is listed at $22 user/month paid yearly, and Microsoft 365 E3 is at $36 user/month paid yearly.
• Verify admin access to the Intune admin center: The admin console is at intune.microsoft.com. You’ll need Global Administrator or Intune Administrator rights.
• Pick 1-2 test users: Choose people who are comfortable reporting issues and who use both iOS and Android, if possible.
• Tell employees they will need to use Outlook for work email if you want Intune app protection on mobile email: app protection policies apply to supported Intune-managed apps, not to whatever mail client a user prefers.

The licensing question comes up a lot, and for most SMBs, the answer is fairly simple. If you already have Microsoft 365 Business Premium, Intune Plan 1 is included. That gives you the core Intune capabilities you need for MAM without a separate add-on. If you are on a different Microsoft 365 plan, the standalone Intune Plan 1 is listed by Microsoft at $8 user/month paid yearly.

The Outlook requirement trips people up. If an employee reads work email in a mail client that does not sit inside Intune app protection, that data falls outside the controls you thought you had. That means no app-level PIN, no selective wipe, and no app-protection data controls. We still see environments where MAM is technically configured, but users are working in the wrong app, so the policy is not doing the job people think it is.

Employees sometimes push back on the Outlook requirement, especially iPhone users who prefer Apple Mail. The practical point is that MAM needs a supported app boundary if you want app-level protection to work consistently. If that does not fit the business, the alternative is fuller device management on company-owned phones. Once people understand that tradeoff, the conversation usually gets easier.

The admin console lives at intune.microsoft.com (not the older endpoint.microsoft.com URL, which still redirects, but should be updated in your bookmarks and documentation).

Setting Up Intune App Protection Policies

Create App Protection Policies

• Create a new iOS App Protection Policy: Go to intune.microsoft.com > Apps > Manage Apps > Protection. Select “Create policy” and choose iOS/iPadOS. Target “Core Microsoft Apps” and set it to apply to all device types.
• Configure core data protection settings: Block backups to iCloud. Set “Send org data to other apps” to “None.” Set “Encrypt org data” to Require.
• Create a new Android App Protection Policy: Same path, but select Android. Target “Core Microsoft Apps” on all device types.
• Verify Company Portal is installed on Android devices: Intune app protection on Android requires the Company Portal app to be installed, even when the device itself is not enrolled. If Company Portal is missing or badly out of date, policy delivery can fail.

You’ll create two separate policies: one for iOS, one for Android. This isn’t optional. Each platform has different security capabilities. iOS lets you restrict third-party keyboards (which can log keystrokes). Android has screen capture and Google Assistant controls. A single cross-platform policy means you miss platform-specific settings.

The core data protection settings are the same on both platforms. Block backups to iCloud or Android backup services, so company data doesn’t end up in an employee’s personal cloud backup. Set “Send org data to other apps” to None, which keeps work files from leaking into personal apps. Require encryption for org data.

The Tradeoff Settings

Some settings involve real tradeoffs between security and convenience. Our checklist calls these out specifically because they need an internal discussion before you pick values.

Copy/paste restrictions are the one that causes the fastest blowback. One of our clients turned on copy/paste restrictions, and within minutes, the CEO called IT asking why he couldn’t copy a physical address out of Outlook and paste it into Google Maps. That policy was reversed the same day. Since the “Send org data = None” setting already closes off a lot of app-to-app data movement, leaving copy and paste less restrictive can be a reasonable starting point for some organizations. You can tighten it later if the workflow risk justifies it.

Notification previews are another one. Blocking org data from lock screen notifications is more secure, but it means employees can’t glance at their phone to see who emailed them without unlocking the app. For some businesses, that tradeoff is worth it. For others, it’s more friction than the risk warrants.

We generally recommend starting with the baseline controls that actually protect company data, then tightening the higher-friction settings once people have adjusted. If you lock everything down on day one, people get frustrated fast, and frustrated employees usually find workarounds that create a different problem.

PIN and Biometric Settings

On both platforms, require an app PIN and allow biometrics as the easier unlock path. A numeric 4-digit minimum is a common baseline, though some teams choose to go stronger. If you want a tighter user-recheck window than Microsoft’s default, a 10-minute inactivity timeout is a reasonable house setting.

One setting that generates questions: “App PIN when device PIN is set.” We recommend setting this to Require. It means employees enter a separate PIN for work apps even if their phone already has a passcode. The practical reason is simple: the app-level PIN keeps work data behind its own control boundary instead of assuming the device passcode is enough.

Conditional Launch Rules

Set a maximum of 5 PIN attempts before resetting the PIN, and block jailbroken or rooted devices entirely. For offline grace periods, treat the numbers as policy choices rather than vendor defaults. A 12-hour block-access timer and a 90-day wipe timer can be a reasonably stricter baseline if the business can live with the user friction.

Pairing MAM with Conditional Access

Set Up Conditional Access

• Create a Conditional Access policy requiring an app protection policy: Without Conditional Access, MAM only protects users who sign into managed apps. A user could access the same data through a web browser with no protections applied.
• Use “Require app protection policy” (not “Require approved client app”): The old grant is being retired June 30, 2026\.

This is one of the most common mistakes we find during Intune audits. A business sets up app protection policies, tests them, and considers the job done. But without Conditional Access, those policies only apply when someone uses a managed app. If an employee opens a web browser and signs in through a path outside the app boundary, the app protection policy does not follow them there. That means the app-level PIN and data-transfer controls you expected are no longer doing the work.

Conditional Access closes that gap by requiring that any access to company data comes through an app that has a protection policy applied. If someone tries to access data through an unsupported app path, Conditional Access can block that access or push the user toward the managed app path you intended.

If you’re setting this up fresh, use the “Require app protection policy” grant from the start. If you’re migrating from the older “Require approved client app” grant, Microsoft recommends adding both grants temporarily with “Require one of the selected controls,” then removing the old one before the June 2026 deadline.

Rolling It Out Without Breaking Things

Test and Roll Out

• Deploy policies to your test group first: Assign policies to 1-2 test users. Have them sign into Outlook, Teams, and OneDrive and confirm that the PIN prompt appears.
• Walk test users through the first-time experience: Users may need to sign out of personal Microsoft accounts before adding their work account.
• Expand to a small pilot group: After the test group confirms everything works, add 5-10 more users.
• Switch to a dynamic “all employees” group: Create a dynamic security group in Entra ID that automatically includes all licensed employees.
• Communicate the change to all employees before it takes effect: Address the privacy concern head-on.

The phased rollout is the part that separates a smooth deployment from a help desk flood. We’ve seen businesses flip MAM on for all 50 employees at once and then spend the next two days answering the same questions over and over.

Start with one or two people who are comfortable with technology and willing to report issues. Have them test on both iPhone and Android if possible. The first sign-in can be bumpy. Users sometimes need to sign out of a personal Microsoft account first, then re-add their work account. The app may need a restart after the first sign-in. Document what happens so you can warn everyone else.

After the test group confirms everything works, expand to a small pilot of 5-10 people. Look for issues with specific phone models, older OS versions, or edge cases. Afterwards, switch to a dynamic security group in Entra ID that automatically includes all licensed employees.

The Employee Communication Part

Don’t skip this. In our experience, the pushback isn’t usually about privacy fears. It’s more basic than that: employees feel like they shouldn’t have to install work applications on their personal phone. It’s an understandable reaction, even if it’s a little ironic.

Many of them are already using the same phone for MFA prompts or authenticator apps. Once we walk them through what MAM actually does (and, more importantly, what it can’t see), the objections usually go away. But if that communication is handled poorly, rollout gets harder than it needs to be. Getting the message right matters almost as much as getting the settings right.

Microsoft publishes a full list of what your organization can and can’t see on employee devices. We’ve had clients include that page in the rollout announcement email, and it answers most of the objections before they’re raised.

When Someone Leaves the Company

Set Up Offboarding Procedures

• Document the selective wipe process:
  • Step 1: Revoke the user’s sessions in Entra ID.
  • Step 2: Go to Intune admin center > Apps > App Selective Wipe and create a User-Level Wipe (not a “Wipe Request”).
• Know the difference between selective wipe and full device wipe: Selective wipe removes only company data from managed apps. Full device wipe erases the entire phone. For BYOD, selective wipe is usually the right approach.
• Delete the User-Level Wipe record if you ever need to reinstate a user: The wipe record stays in Intune. If that person returns, you must delete it before MAM policies reapply.

Selective wipe is one of MAM’s strongest features for BYOD environments. When an employee leaves, you remove company data from Outlook, Teams, and OneDrive on their phone without touching their personal photos, messages, or apps. This is a much cleaner offboarding conversation than asking to wipe the whole phone.

The process is two steps: First, revoke the user’s sessions in Entra ID. Second, create a User-Level Wipe in the Intune admin center (Apps > App Selective Wipe > User-Level Wipe tab). Use the User-Level Wipe tab, not the “Wipe Requests” tab. These are different features, and the Wipe Requests tab doesn’t work the way you’d expect for MAM-only devices.

One gotcha that catches admins: after a User-Level Wipe, the record stays in Intune until an administrator removes it. If that person comes back to the company, or if you wiped in error during testing, delete the User-Level Wipe entry before expecting the policy to apply normally again. We learned this one through our own testing. The wipe didn’t complete properly until we found the right tab and deleted the record afterward. It’s not a big deal once you know about it, but it’s easy to miss.

What to Do Today, This Week, and This Month

Do today:

Do this week:

Do this month:

How MAM Supports Compliance

MAM isn’t a compliance checkbox by itself, but it addresses specific technical requirements across several frameworks.

For HIPAA, Intune app protection policies address encryption of ePHI on mobile devices, remote wipe, and access controls, three areas that HHS guidance specifically calls out for mobile devices. MAM also blocks backups to personal cloud storage, which matters because HIPAA doesn’t allow ePHI in an employee’s personal iCloud account.

For SEC/FINRA, MAM can help steer work communication into managed apps and reduce the use of uncontrolled channels. This supports the broader off-channel communications problem, where the SEC says its recordkeeping sweep has produced more than $2 billion in penalties since December 2021. But MAM does not replace the archiving and retention controls firms need for Rule 17a-4. You will still need a separate archiving solution for that.

MAM documentation can also support cyber insurance applications, where underwriters increasingly ask about mobile device controls.

For any compliance-driven deployment, document your MAM configuration as part of the broader risk assessment and control record. The settings are part of the evidence that you have implemented mobile safeguards, but the documentation around them matters too.

When to Get Help

MAM is one of the more approachable Intune configurations for small businesses. If you’re comfortable in the Microsoft 365 admin center and willing to test with a small group first, you can handle the initial setup.

Where it gets tricky: Conditional Access policies that interact with existing authentication rules, separating policies for MDM-enrolled vs. BYOD devices, integrating Mobile Threat Defense, or mapping MAM settings to specific compliance framework requirements. If your environment has multiple device management states, legacy Conditional Access policies, or regulatory requirements that need documentation, having someone review the configuration is worth the investment.

Adelia Risk’s Virtual CISO service includes Intune configuration reviews as part of our Microsoft 365 security assessments. We’ll audit your current mobile application management and Conditional Access setup, flag gaps, and make sure your policies actually match what your compliance framework requires.