Intune Android Compliance: An SMB October 31 Checklist

A phone can still make calls while losing access to the work apps its owner needs. For an SMB, that can mean a field supervisor cannot open a job file or an operations manager cannot approve a request. The right preparation is not a blanket block or an instruction to buy everyone a new phone. It is a short, evidence-led review of devices, policies, and business workflows.

Microsoft says Intune will enforce Google's revised Strong Integrity requirements by October 31, 2026. The change concerns Android 13 and later: devices without a security update within the past 12 months will not meet that standard. Whether a user loses access depends on the policies applied to that user and device. Android 12 and earlier are outside this particular change, not automatically safe or suitable for continued business use. See Microsoft's current change notice.

ITECS recommendation: identify the affected population now, test representative phones, and give every unresolved device an update, replacement, or approved alternative-workflow owner before the deadline.

What Strong Integrity means for your Android fleet

Google's Strong Integrity verdict combines more than an OS version number. On Android 13 and later, it requires Device Integrity plus security updates within the last year across the device's partitions, including the Android OS and vendor partitions. A current-looking patch date is useful screening evidence, but it is not by itself proof that every integrity requirement passes. Google's integrity verdict documentation explains the distinction.

Do not confuse an app update, a major Android upgrade, and an Android security patch. Record the actual security patch level and test the resulting policy decision. Treat a missing date as an investigation item, not a pass.

Separate the three places access can fail

1. App protection: inspect the assigned Android app-protection policy, integrity evaluation, and conditional-launch action. The user may see a warning or a block when opening a protected work app, depending on its settings.
2. Device compliance: inspect the assigned Android Enterprise compliance policy and failed setting. The device may show as noncompliant, including in Company Portal.
3. Conditional Access: inspect the sign-in policy and whether it requires a compliant device. The user may be denied access to the covered company resource.

These are related controls, not interchangeable labels. A device can fail a required strong-integrity check without every application in the business being blocked. Conversely, a conditional-launch block can matter even when the team is focused only on enrolled-device compliance. Review Microsoft's Android app-protection settings, Android Enterprise compliance settings, and compliant-device Conditional Access guidance together.

1. Build an inventory that leads to a decision

Start in Intune at Apps > Monitor > App protection status. Microsoft's report includes the Android patch version, model, manufacturer, platform version, management type, policy name, and last sync. It reports app instances, so do not treat its row count as a count of unique phones. A stale sync also limits what the record proves. See the reporting reference.

Build a restricted-access working list, reconciled with enrolled-device inventory and your business owners. For each relevant phone or tablet, capture:

• Corporate or personal ownership, enrollment type, Android version, model, carrier, and latest observed patch date.
• The work apps and business tasks that depend on it, with the employee's manager or operational owner.
• Applicable app-protection, compliance, and Conditional Access policies, including exclusions and last observed evaluation.
• Available vendor updates, remaining support life, remediation owner, due date, and fallback device or workflow.

Prioritize people whose mobile access is difficult to substitute: on-call staff, field workers, approvers, and employees without a ready desktop alternative. Keep personal-device inventory limited to necessary work-access information. Do not collect private messages, photographs, passwords, or personal app contents to complete this exercise.

2. Check policy settings without creating a second outage

For app protection, review Min OS version and Min patch version. Microsoft supports warning and blocking actions, as well as a separate action to remove organizational app data; a patch date uses YYYY-MM-DD. For enrolled devices, inspect the applicable profile's Minimum security patch level and strong-integrity settings. Confirm the settings available for the actual enrollment type rather than assuming every Android profile is identical. The app-protection reference and compliance reference are the configuration authorities.

ITECS recommends treating minimum OS, patch recency, and integrity as separate acceptance checks. Choose your organization's supported OS baseline deliberately. Do not copy Android 13 into a policy simply because it marks the boundary of this change.

Document who maintains date-based thresholds. A fixed date entered today does not become a rolling 12-month rule by itself. Set a review reminder, and do not treat Google's annual limit as a recommendation to wait a year between security updates.

3. Pilot warnings, blocks, and real work

Choose a small pilot that includes corporate devices, permitted personal-device configurations, different manufacturers and carriers, and at least one phone awaiting an update. Use spare or controlled test devices for expected failures rather than disrupting a critical employee.

Where the relevant setting supports it, use warnings to identify remediation needs before introducing a new block. A warning on one setting does not override another policy that already blocks access. For a new Conditional Access policy, Microsoft's guidance is to evaluate report-only results before turning enforcement on; review that deployment guidance rather than disabling an existing protection to make a pilot pass.

• Positive test: update the phone, obtain a fresh policy evaluation, and complete an approved work task in each required app.
• Negative test: confirm the intended warning or denial on the controlled nonqualifying test device, with a clear recovery message.
• Recovery test: remediate that device and verify access returns through the normal evaluation process.
• Stop condition: pause your rollout if supported, updated devices fail unexpectedly, essential workflows cannot be restored, or the help desk cannot identify the blocking layer.

Retain the policy version, test time, device cohort, expected result, observed result, and business-owner signoff. Use test documents and approved accounts, not customer information copied into screenshots.

4. Plan for phones that cannot receive the update

Microsoft notes that Android security-patch delivery depends on manufacturers and carriers in its Android Enterprise security guidance. An administrator cannot solve an unavailable vendor update merely by asking the employee to check again.

For company-owned devices, assign procurement a replacement or loaner decision with a delivery date, setup owner, and tested app access. For personal devices, explain the work-access requirement and offer the organization's approved alternative. Do not assume an employee must buy a particular phone or surrender personal data without an established BYOD agreement.

Any exception needs a named business approver, security review, limited scope, expiry, compensating controls, and an exit date. Record what protection would be relaxed. An exception does not make an old phone satisfy Strong Integrity, and a replacement order is not evidence that the employee can work.

5. Give users and the help desk a usable recovery path

Send a brief notice before enforcement: which work apps may be affected, how to check for the approved update, when to complete it, what downtime or restart to expect, and how to reach support if work email stops opening. Provide an approved phone number or other channel outside the potentially blocked app.

Use this help-desk sequence:

1. Confirm the affected work app, business impact, time of failure, model, Android version, and patch level. Avoid collecting unnecessary personal information.
2. Check the applied policy, latest sync, and specific failure. Separate app protection from device compliance and the sign-in decision.
3. Confirm connectivity and the appropriate Company Portal and work-app versions. Microsoft documents last-sync and connectivity checks in its app-protection troubleshooting guide.
4. Apply the approved update path, then recheck policy evaluation and the actual workflow. If patching is unavailable or integrity still fails, escalate to the device/vendor owner.
5. Record the outcome and provide the approved fallback. Do not suggest rooting, spoofing patch dates, disabling security controls, or using personal accounts to move company data.

6. Define rollback and the October 31 evidence pack

Before changing a policy, save its settings, assignments, exclusions, and change approval. A rollback restores a mistaken administrative change through the normal owner; it cannot roll back Google's verdict definition or Microsoft's service enforcement. If restoring the earlier configuration would weaken protection, require the documented risk decision and a time-limited alternative rather than a tenant-wide bypass.

By October 30, aim to have a decision for every at-risk cohort. After enforcement and on the next working day, review actual results. Keep the final evidence pack concise:

• Counts of updated, replaced, unresolved, and exception-covered devices, with evidence freshness noted.
• Policy and assignment snapshots, pilot results, and approved workflow checks.
• User notices, help-desk instructions, replacement dates, exception expirations, and accountable owners.
• A recurring review date so newly stale devices do not become the next surprise.

The completion test is not simply a green dashboard. It is evidence that approved users can complete required work, disallowed access is handled as intended, and every unresolved case has an owner.

Need help turning the inventory into an operating plan? Explore ITECS Microsoft 365 consulting or contact ITECS to discuss responsibility, remediation, and ongoing review within your managed or co-managed support arrangement.

Source review: October 19, 2026. This AI-assisted planning guide uses current Microsoft and Google documentation; it is not a tenant assessment or a claim of tested results in your environment. Recheck your tenant's Message center and the linked vendor guidance before making changes.