Designing an App Protection Policy that don’t backfire on your unmanaged devices

An App Protection Policy for unmanaged devices is often described as a lighter form of device management. That description is inaccurate. It is not a reduced version of MDM. It exists because there is no device control in the first place. In an unmanaged scenario, the device is not enrolled. There is no compliance signal. No configuration baseline. No guarantee that you can enforce encryption, passcode strength, or system restrictions. From a management perspective, the device is outside your control. Yet corporate data still enters that device. Email is synchronized. Documents are opened. Links are shared. Collaboration continues as if the device were managed.

This is exactly where Mobile Application Management makes sense. Authentication through Conditional Access decides whether access is granted. The App Protection Policy decides what is allowed to happen with the data after access is granted. For unmanaged devices, the app becomes the only enforceable boundary. Identity is the anchor. The Intune SDK inside the app evaluates the policy tied to that identity. Protection is applied at the moment the user interacts with corporate data, not at enrollment and not at the operating system level.

This post focuses specifically on that model. An App Protection Policy designed for unmanaged devices. Why it exists. What it actually controls. How to design a solid baseline before creating it. And how delivery and verification work when there is no device management layer underneath it.

Why App Protection Policies exist

Device management assumes ownership. Once a device is enrolled, you can configure it, evaluate compliance, and block access before the user ever reaches corporate data. That model only works when the device is under management. In an unmanaged scenario, that assumption disappears. The device is not enrolled. There is no compliance signal to evaluate. No configuration profile to rely on. BYOD, external users, and platforms that restrict device level control all fall into this category.

Access itself is usually not the issue. Authentication works. Conditional Access evaluates identity, risk, and location. The user gets in. The real problem starts after sign in. Corporate data is now displayed inside an app running on a device you do not control. At that point, Conditional Access has finished its job. App Protection Policies for unmanaged devices exist to close that exact gap. They do not attempt to manage the device.

They control how corporate data is handled inside the app. Copy and paste behavior. Allowed save locations. Screenshot and print restrictions. Offline access limits. Selective wipe actions. All enforced at the application layer. In this model, trust does not come from device state. It comes from the combination of user identity and application context.

The policy is evaluated when the identity becomes active inside the app. Not during enrollment. Not during a device check in cycle. Without an App Protection Policy, protection effectively stops at authentication. With it, protection continues while the data is in use, enforced through the Intune SDK and coordinated by Microsoft Intune.

What is an App Protection Policy

An App Protection Policy is not a configuration profile and it is not device management without enrollment. It is a rule set evaluated by the application itself, tied to a signed in identity.

The policy lives in Microsoft Intune, but it is not pushed to the device. There is no device channel. No MDM check in. The policy is requested by the app when the user signs in and the Intune SDK initializes. From that moment on, the app enforces the rules locally. Data handling. Access conditions. User actions. The operating system is not the decision maker here. The SDK is.

The scope is always the combination of user and app. The same device can hold multiple identities, each with a different policy state. The same app can behave differently depending on which account is active. There is no global policy state on the device. This also explains why App Protection Policies feel invisible when they work and confusing when they do not. Nothing shows up in device management views. No compliance status flips. Everything happens inside the app process. At its core, an App Protection Policy defines how corporate data may exist inside an app. When it can be accessed. How it can be shared. And when it must be removed.

Designing an App Protection policy

A baseline App Protection Policy starts long before you open Intune. The moment you create the policy, every toggle reflects a decision you either made deliberately or avoided. The baseline defines two things. Where corporate data is allowed to exist and how users are expected to handle it.

Begin with the data boundary. Which storage locations do you trust. Which ones do you not. Corporate cloud storage is often acceptable. Personal storage usually is not. But do not stop there. Think about what saving really means in daily work. Local files on the device. Offline availability. Temporary downloads that users forget about. If you do not define this clearly, users will default to what is easiest.

After storage comes movement. Data rarely leaks because it was saved somewhere. It leaks because it was shared. Copy and paste into another app. Opening a document in a different editor. Sending content to a consumer app. Your baseline needs a clear rule for where data can flow. Allowing movement only between protected apps is often the balance point. Users can still work, but the boundary remains intact.

Then address access protection. On unmanaged devices, you cannot assume anything about device compliance or passcode strength. Decide whether access to corporate data requires an app level PIN. For many organizations, this is the only reliable control available. Biometrics can reduce friction, but the requirement itself should be intentional, not something you leave at default.

Offline behavior is where security and productivity meet directly. How long can the app function without checking back in. A short window reduces risk if a device is lost. A longer window supports users who travel or work with unstable connectivity. There is no universal answer. The right value reflects how your users actually operate.

Now consider the quieter paths of data exposure. Screenshots. Printing. Cloud backups. Operating system features that process or analyze content outside the app context. These are not always part of daily workflows, but they are common sources of accidental leakage. In most baselines, blocking them reduces risk with limited impact on productivity.

Browser handling is another decision that shapes the boundary. When a user taps a link, where does it open. In any browser on the device or only in a managed one. That single choice often determines whether the protected context continues or ends immediately.

Finally, define the scope with precision. Is this baseline designed for unmanaged devices only. For managed devices with an extra layer of protection. Or for both scenarios. Blending these intents into one policy leads to unpredictable behavior and unexpected blocks.

A strong baseline is not defined by how strict it is. It is defined by consistency. Every control has a clear purpose that can be explained without opening the Intune portal. When that reasoning is solid, creating the policy becomes implementation, not experimentation.

Creating an App Protection Policy for unmanaged devices

In older App Protection policy templates, you could explicitly choose whether the policy applied to managed devices or unmanaged devices. That switch made the intent clear at creation time.

That option no longer exists in the same way. The policy itself is no longer split by device management state. If you want different behavior for managed and unmanaged devices, you now have to model that separation yourself. The practical solution is using two filters. One filter targets devices that are enrolled. The other targets devices that are not. Each policy is then assigned with the appropriate filter, even if both are scoped to the same user group.

Therefore, we are going to create two filters managed and unmanaged how to we can find here

Filter managed = (app.deviceManagementType -eq “Managed”)

Filter unmanaged = (app.deviceManagementType -eq “Unmanaged”)

Now we can create the policy, we now will create iOS app protection policy, therefore we need to go to Intune | Apps | iOS/iPadOS | Protection and click on +Create and iOS/iPadOS

Give the policy a Name and Description and click Next

In first step of the policy, we can set our baseline for MAM protection apps, when creating an App Protection Policy, targeting all supported apps is usually the safest starting point. It ensures that any app integrating the Intune SDK automatically falls under the same protection rules.

If the policy only targets a small set of apps, it becomes easy to miss one. A newly introduced Microsoft app or a third party app that supports App Protection could allow corporate data without the expected restrictions simply because it was never added to the assignment.

Targeting all apps avoids that gap. The policy becomes consistent across the entire managed app ecosystem instead of depending on a manually maintained list. As soon as an app supports App Protection and the user signs in with a work identity, the same rules apply.

This approach keeps the policy predictable and reduces the chance that data handling differs between apps that users perceive as part of the same work environment. So set Target policy to All Apps

The next part of the policy focuses on data protection. This is where the Data Loss Prevention controls are defined. These settings determine how corporate data can move inside and outside the app. Actions such as cut, copy, paste, and save as are controlled here. The goal is simple: allow users to work with their data, while preventing it from ending up in locations or apps that are not protected.

Decisions made in this section directly influence daily workflows, so they should balance security with usability. In this picture below we pasted a piece of our baseline.

The next section focuses on access requirements. This is where you define how users authenticate before accessing corporate data inside the app. These settings control things such as whether an app PIN is required, how complex that PIN must be, and whether biometrics can be used. The goal is to ensure that corporate data inside the app is protected, even when the device itself is not managed.

The requirements should add protection without interrupting normal use more than necessary.

The final section focuses on conditional launch. These settings define under which conditions the app is allowed to start and provide access to corporate data.

Here you configure the security requirements that must be met before the app can be used in a work context. Examples include device conditions such as a jailbroken or compromised device, outdated app versions, or required operating system levels.

For each condition you define both the requirement and the action that should be taken if the requirement is not met. Depending on the scenario, the app can block access immediately or allow access temporarily while warning the user.

Conditional launch settings ensure that even on unmanaged devices, basic security checks still influence whether the app is allowed to continue operating in a work context.

Now we can assign this policy or to a user group where all our user will be a member of or all devices. this is the part where we add the filter we created earlier.

How the App Protection Policy comes down

To make things clear nothing is pushed.

App Protection Policies do not sync like device policies. There is no check in cycle, no scheduled refresh, no manual sync button. Everything starts with identity. The moment a user signs in to a protected app, the app initializes the Intune SDK. That SDK asks one question. Is there a policy for this user and this app. If the answer is yes, the policy is requested and evaluated locally.

This is why timing matters. If the user signs in before the policy exists, nothing happens. If the policy is created later, the app will not magically update itself. The next policy request only happens on a trigger.

Those triggers are limited. App launch. Account sign in. In some cases, token renewal. That is it. Closing and reopening the app often does more than waiting an hour.

The policy itself is not applied in one go. Some settings are checked immediately during sign in. Others are enforced while the app is already running. A PIN requirement shows up right away. A data transfer rule only shows itself when the user tries to share something. That difference matters when troubleshooting.

There is also no single policy state on the device. The policy is evaluated per app, per identity. The same device can behave differently depending on which account is active inside the app. That is expected behavior, not a bug.

This is also why App Protection Policies feel unpredictable when something is off. The delivery path is invisible. No device view in Intune will tell you what the app actually received. From Intune’s perspective, the policy exists. From the app’s perspective, it may not.

Understanding this flow is essential. Without it, every issue looks random. With it, most issues turn out to be timing, identity, or trigger related.

The flow

What happens after you change the policy

Changing an App Protection Policy in Intune does not do anything by itself. There is no push. No notification to the device. No signal to the app that something has changed. From the device perspective, nothing happened. The new policy only exists on the service side. Until the app asks again, it will keep enforcing whatever it already has cached.

That request does not happen automatically. It requires a trigger. Most of the time that trigger is an app restart. Sometimes it is a full sign out and sign in. Rarely it is token renewal while the app stays open. Waiting does not count as a trigger. This is where expectations usually break. Admins change a setting, test immediately, and see no difference. Not because the policy is wrong, but because the app is still enforcing the previous version.

Not every change behaves the same. Some settings are evaluated at sign in. PIN requirements. Access conditions. Identity related checks. These almost always require the app to restart and the user to authenticate again.

Other settings are evaluated at runtime. Data sharing. Save locations. Screenshot behavior. These only show up when the user performs the action. If the user never hits that path, the change looks like it never applied. There is also no guarantee that every app reacts instantly after a restart. Apps cache state differently. Some keep the SDK alive longer. Some clear it aggressively. This is app behavior, not Intune behavior.

Another important detail. Policy changes do not merge. The app does not receive “just the delta”. It requests the policy again and replaces what it had before. If targeting changes or identity changes, a completely different policy can suddenly apply.

This is why troubleshooting after a change should always start with the same questions. Did the app restart. Did the user sign in again. Is the same identity still active. Without a fresh trigger, you are testing old behavior. Policy changes feel slow because the model is pull based. Once you accept that, the behavior becomes predictable.

Verifying the policy on the device

Intune can tell you that a policy exists and that it is assigned. It cannot tell you what the app actually received or is enforcing. Verification always happens on the device, inside the app.

The first thing to verify is identity. App Protection Policies are tied to the signed in account inside the app, not to the device and not to the OS user. If the wrong account is active, the wrong policy is enforced. This includes guest accounts, secondary tenants, and cached identities that users often forget about.

Next, confirm that the app is actually capable of enforcing App Protection Policies. Only apps that include the Intune SDK can do this. If the app is not MAM enabled, no policy will ever apply, regardless of what Intune shows.

Creating the MAM diagnostic file

On iOS and iPadOS, verification starts by exporting the App Protection diagnostic log. This log is generated by the Intune SDK inside the app. It is not an iOS system log and it does not require device enrollment.

The exact menu names differ per app, but the flow is consistent.

1. Open the affected app
2. Ensure the work account is signed in and active
3. Open the app settings
4. Look for Help, Support, About, or Diagnostics
5. Select Export diagnostics or Send logs
6. The app generates a diagnostic file containing MAM state
7. Save or share the file
8. Use Files, AirDrop, or email to move it off the device

If the app does not expose a diagnostics option, it usually means the app does not support App Protection Policies or the Intune SDK never initialized. The diagnostic file is a snapshot. It reflects what the app and SDK believe at that moment.

• Export it before sign in and the identity will be missing.
• Export it without restarting after a policy change and it may show old behavior.
• Export it with the wrong identity active and the log will be correct but misleading.

What to verify on the device

Do not look for a single “policy applied” indicator. It does not exist. Each rule is evaluated in context. PIN enforcement appears when the app starts or resumes. Data transfer rules appear only when sharing is attempted. Screenshot blocking appears only when the user tries to take one. Observed behavior must always be matched to the moment the rule is evaluated.

Forcing a fresh policy evaluation

If the policy does not appear to be present, force a new request.

• Fully close the app.
• Reopen it.
• If needed, remove the work account and sign in again.
• This resets the SDK state and triggers a fresh policy pull. Waiting does nothing.

Understanding the limitation

There is no device level view in Intune that shows MAM enforcement. There is no sync button. There is no guarantee that two apps on the same device are enforcing the same policy at the same time.

Verification is not about checking boxes in Intune. It is about confirming that the identity, the app, and the enforcement context line up on the device.

Conclusion

App Protection Policies for unmanaged devices only make sense once you stop thinking in device terms. There is no enrollment channel. Nothing is pushed. Nothing syncs on a schedule. Everything revolves around identity, app behavior, and timing. Design is the first control. If it is unclear where corporate data is allowed to exist and how it may be handled, the policy will feel inconsistent. If those rules are clearly defined, enforcement becomes predictable, even when users report unexpected behavior.

Delivery follows a pull model. The app decides when it asks for policy. Until that trigger happens, changing a setting in Intune has no effect on the device. The service can be updated, but the app will continue enforcing whatever it last received. Verification does not happen in the portal. It happens inside the app. You validate identity. You confirm that the SDK initialized. You check the diagnostic log. If the wrong account is active, the wrong policy is evaluated. If no new trigger occurred, the new policy never arrived.

Once you understand this model, App Protection for unmanaged devices stops feeling unreliable. It becomes structured. Not immediate. Not always visible. But explainable.