Intune requirements explained

What are Intune requirement rules?

Requirement rules describe the conditions a device must satisfy before Intune considers the app applicable to it. You configure them on the Requirements tab of a Win32 app. When the Intune Management Extension (IME) processes the app on a device, it checks the requirement rules first. If every rule passes, the app is "applicable" and the workflow proceeds to detection and, if needed, installation. If any rule fails, the app is reported as not applicable and nothing is downloaded or run on that device.

This is a deliberate design. Requirements let you publish a single app to a broad group while still ensuring it only lands on devices that can actually run it. The cost of getting them wrong is that a perfectly healthy device silently never receives the app, with no install error to point at, because the install never started.

Where do requirements run in the deployment flow?

Evaluation order matters when you are troubleshooting. The IME walks the same sequence on every device, and requirements are the first real gate after the assignment is targeted.

Because requirements come first, they short-circuit everything downstream. If a device fails a requirement, the detection rules are never reached and the install/uninstall command never fires. That is why "app not applicable" in the device install status almost always points back to a requirement, not a packaging or command problem.

What built-in requirements can you set?

Intune ships several built-in checks that cover the common eligibility questions without any scripting. Two of them are effectively mandatory and the rest are optional thresholds:

• Operating system architecture — choose x86 (32-bit), x64 (64-bit), and/or ARM64. This guards a build that only ships for one architecture. Select every architecture the package supports; a 64-bit-only app left at 32-bit will never apply to 64-bit devices.
• Minimum operating system — the lowest Windows release that may install the app. Devices on an older build are filtered out. Set this to the oldest version you have actually validated, not the newest in your fleet.
• Disk space required (MB) — minimum free space on the system drive before the install is attempted.
• Physical memory required (MB) — minimum installed RAM.
• Minimum number of logical processors and Minimum CPU speed (MHz) — coarse performance gates for apps that are demanding to run.

The disk, memory, and CPU fields are optional and frequently left blank. Set them only when the app genuinely needs the threshold, because every value you add is one more way to exclude a device you intended to reach.

How do custom file, registry, and script requirements work?

When the built-in checks are not specific enough, add a custom requirement rule. Three types are available:

• File — check that a file or folder exists (or does not exist), or compare its version, size, or modified date against a value. Useful for confirming a prerequisite runtime or agent is present.
• Registry — test a key or value with an operator such as Exists, Equals, Greater than, or Less than. Common for gating on a feature flag, a baseline policy value, or a previously deployed component.
• Custom script (PowerShell) — run a script and turn its result into a pass/fail. This is the most flexible option and the one with the strictest contract.

A custom requirement script must exit with code 0 and write output to STDOUT. Intune then compares that output against the data type, operator, and value you configured. If the script exits non-zero, or exits 0 but writes nothing, the rule fails and the app is treated as not applicable. You also choose whether the script runs as a 32-bit process and whether to enforce signature checking. Keep these scripts fast and side-effect free; they run on every applicable check-in, not just once.

# Custom requirement: PASS only when the corp baseline value is present
$val = (Get-ItemProperty -Path "HKLM:\SOFTWARE\Contoso\Baseline" -Name "Ready" -ErrorAction SilentlyContinue).Ready
if ($val -eq 1) { Write-Output "Eligible"; exit 0 } else { exit 1 }

With the script above you would set the output data type to String and the rule to pass when the value equals Eligible. The script writes that string only on the success path, so any other outcome correctly fails the requirement.

What does the Requirements dialog look like?

The compact mockup below shows the fields that decide eligibility for a typical line-of-business app.

Which requirement type should you use?

The table below maps each requirement type to its typical use and the mistake that most often makes it backfire.

When are requirements re-evaluated?

Requirements are not a one-time check. The IME re-evaluates Win32 app policy roughly every hour, and also after a device restart or when the Intune Management Extension service restarts. A device that failed a requirement today can become eligible later — for example after a Windows feature update raises its build past your minimum OS, or after a prerequisite the script tests for is installed. To pull a fresh evaluation on demand during testing, trigger a manual device sync from Settings > Accounts > Access work or school, or from Company Portal, rather than waiting for the next automatic cycle.

Keep in mind that the general Windows MDM check-in (every several hours) is separate from this ~1 hour Win32 policy cycle. When you change a requirement in the portal, give the device a sync before concluding the change had no effect.

Why is my app not installing because of requirements?

Most "assigned but never installs" cases trace back to a requirement filtering the device out. Because the install command never runs, there is no failed exit code — the device simply reports the app as not applicable. Work through these checks before suspecting the package itself:

• Compare the device architecture and Windows build against the architecture and minimum OS you set. An x64 device with only 32-bit selected will never qualify.
• Re-check any disk, memory, or CPU thresholds against the lowest-spec device in your target group.
• For custom rules, confirm the script exits 0 and writes the expected STDOUT value, and that the configured data type and operator match what the script returns.
• Remember that file and registry rules run in System context by default, so a per-user path will not be visible. See the broader Win32 troubleshooting checklist when requirements check out but installs still fail.

Requirements also interact with how you assign the app. If you are using an Available assignment, an ineligible device simply will not show the app in Company Portal; with a Required assignment it is reported as not applicable in the device install status.