Define access requirements and conditional launch behaviors

  • 6 minutes

When configuring App Protection Policies (APP) in Microsoft Intune, Data Protection settings control what users can do with data after they are inside the app. Access Requirements and Conditional Launch settings control whether they're allowed to open the app in the first place.

By carefully configuring these two sections, you can ensure that corporate data is only accessed by verified users on healthy, up-to-date devices, balancing strict security with a smooth end-user experience.

Access requirements: guard the front door

Access requirements dictate the authentication hurdles a user must clear to launch a managed application like Microsoft Outlook or Teams.

  • PIN for access:
    • How it works: Forces the user to establish a specific PIN (usually 4 to 6 digits) that is completely separate from their device's lock screen password.
    • Best practice: Require this PIN for BYOD (unmanaged) devices, as you don't control the native device lock screen. For corporate (managed) devices that already enforce a strict device passcode via MDM, you might choose to disable the App PIN to reduce user fatigue.
  • Allow biometrics (Touch ID / Face ID):
    • How it works: Allows the user to bypass typing their App PIN by using their device's native biometric sensors.
    • Best practice: Allow this. It drastically improves the user experience while maintaining strong security. If the biometric sensor fails or is unavailable, the app gracefully falls back to requesting the App PIN.
  • Work or school account credentials for access:
    • How it works: Forces the user to fully authenticate with their Microsoft Entra ID password and MFA instead of just a PIN.
    • Best practice: Not required for daily use. Relying on the App PIN or biometrics is sufficient for daily access. Forcing a full Entra ID sign-in every time the app opens causes massive user frustration.

Conditional launch: the ongoing health check

While Access Requirements check who is opening the app, Conditional Launch settings evaluate the health and state of the device and the app itself. These conditions are checked every time the app is launched or resumed from the background.

You must configure a specific Action (Warn, Block access, or Wipe data) for each condition.

Key device conditions

  • Jailbroken / rooted devices:
    • Action: Block access or Wipe data. Compromised operating systems bypass native security sandboxes, making your App Protection Policies useless. Never allow corporate data on a rooted device.
  • Min OS version / Min app version:
    • Action: Warn (to give them a grace period), then Block access. This ensures users can't access corporate data using outdated software with known unpatched vulnerabilities.
  • Max allowed threat level:
    • Action: Block access or Wipe data when the device threat level exceeds your configured threshold. This condition integrates your application layer directly with Mobile Threat Defense (MTD) solutions, with Microsoft Defender providing the Microsoft-native mobile threat defense signal for real-time threat evaluation.
    • Details: The integration continuously evaluates the endpoint's active risk, categorizing it into one of four threat levels: Secured, Low, Medium, or High. You must set the maximum allowed risk level appropriate to the sensitivity of the data being accessed (for example, requiring a Secured or Low level for sensitive corporate environments). If a live threat (such as active malware or a man-in-the-middle network attack) triggers an escalation past your threshold, access to the corporate app context is severed or wiped.
    • Prerequisite: To leverage this capability, the corresponding MTD or Microsoft Defender connector must first be configured and enabled in the Intune admin center by navigating to Tenant administration > Connectors and tokens.

Key app conditions

  • Max PIN attempts:
    • Action: Set to 5 attempts, with the action to Reset PIN. If a user enters the wrong App PIN five times, Intune forces them to authenticate fully against Entra ID (with MFA) to prove their identity before they can create a new PIN.
  • Offline grace period:
    • How it works: Determines how long the app can run offline before it must "check in" with the Intune service to confirm the user still works for the company and the policies haven't changed.
    • Best practice:
      • Block access after 720 minutes (12 hours): If the device is offline for 12 hours, the app locks. The user simply needs to connect to Wi-Fi to unlock it.
      • Wipe data after 90 days: If a device has been offline for 3 months, assume it's lost or belongs to a terminated employee who is keeping it offline to read cached emails. A wipe command is queued and instantly deletes the corporate cache the moment the device connects to the internet.
  • Disabled account:
    • Action: Wipe data. If the HR department terminates an employee and their Microsoft Entra ID account is disabled, this setting ensures that the local corporate data cached inside the app is immediately wiped.

The user experience: block vs. wipe

It's critical to understand the difference between the automated actions you can select in the Conditional Launch menu, because they drastically impact the user experience:

  • Warn: The user sees a pop-up (for example, "Your iOS version is out of date. Please update soon.") but can select "Dismiss" and continue working.
  • Block access: The app opens, but an impenetrable screen blocks the data. The user can't read emails or view files until they remediate the issue (for example, connect to Wi-Fi, update the OS). No data is deleted.
  • Wipe data: This action is a Selective Wipe. Intune permanently deletes the cryptographic keys for the corporate container. All corporate emails, chats, and files stored within the app are instantly destroyed. The user's personal data on the device remains untouched.