Microsoft Authenticator Saying Your Device Is Rooted or Compromised: Every Fix

A growing number of Android users — particularly those on newer Samsung devices including the Galaxy S25 series — are seeing a warning in Microsoft Authenticator stating their device is rooted, compromised, or does not meet security requirements. In most cases, the phone has not been rooted. This is a consequence of Microsoft switching to a stricter device integrity checking system in late 2024, and there are multiple possible causes ranging from a single sideloaded app to a phone setting that has been enabled and forgotten. This guide covers every known cause and how to fix each one.

What the Warning Means

The warning message varies but typically reads one of the following:

• “Your device may be rooted”
• “Your device doesn’t meet the security requirements set by your organisation”
• “This device doesn’t comply with your organisation’s security policies”
• “Device integrity check failed”

All of these stem from the same underlying check failing. Microsoft Authenticator is checking device integrity — whether your phone is in a trusted, unmodified state as certified by Google’s Play Integrity API. When that API returns a result that falls below Microsoft’s required threshold, the warning appears. The check is not assessing your behaviour or your Microsoft account; it is assessing the phone itself.

Why This Is Happening Now: The Play Integrity API Change

Microsoft Authenticator moved from Google’s deprecated SafetyNet attestation system to the newer Play Integrity API in 2024. Play Integrity is considerably stricter and operates across three levels of certification:

• MEETS_BASIC_INTEGRITY — the device passes basic software checks
• MEETS_DEVICE_INTEGRITY — the device is running certified Android on approved hardware (this is the minimum level now required by Microsoft Authenticator)
• MEETS_STRONG_INTEGRITY — hardware-backed attestation, required under the strictest organisational security policies

Microsoft Authenticator now requires at minimum MEETS_DEVICE_INTEGRITY. Anything that causes the device to fail this check triggers the warning — even on a completely unrooted phone. Newer Samsung devices (S24 and S25 series running One UI 6 and One UI 7) have been particularly affected because of how Samsung’s own system modifications interact with the Play Integrity attestation process. The phone is not broken, and it has not been tampered with, but one or more settings or installed apps may be causing it to fail the check.

All Known Causes and How to Fix Each One

Multiple causes can apply simultaneously. Work through each one in order rather than stopping at the first fix you apply — several may need to be addressed before the warning clears.

Cause 1: Sideloaded APK Installed (Most Common)

Any app installed from outside the Google Play Store — via an APK file — can trigger the integrity check to fail, particularly if the app hooks into telephony, accessibility services, or system-level functions. This is the single most common cause reported by users who have not intentionally modified their device.

How to check: Open the Google Play Store, tap your profile icon, go to Manage apps and device, then the Manage tab. Alternatively, open My Files, navigate to Downloads, and look for any .apk files — their presence indicates a sideloaded app was recently installed.

Fix: Uninstall the sideloaded app. Go to Settings > Apps, find the application, and tap Uninstall. Then open My Files, go to Downloads, and delete the APK file itself.

Note that not every sideloaded app will cause the issue — it depends on what the app does. Apps that interact with calls, notifications, accessibility services, or system settings are the most likely to trigger a failure.

Cause 2: Install Unknown Apps Permission Still Granted

Even after uninstalling a sideloaded app, the permission granted to the browser or file manager used to install it may remain active. Play Integrity can flag this as an indicator that the device is configured in a non-standard state.

Fix: Go to Settings > Apps, tap the three-dot menu, select Special access, then Install unknown apps. Review every app listed and tap any shown as Allowed, then toggle the permission off. After revoking all permissions, restart the phone.

Cause 3: Developer Options Enabled

Enabling Developer Options — which requires tapping Build Number seven times in the About Phone menu — is treated by Play Integrity as a signal that the device may be in a modified or developer state. Even if Developer Options were enabled accidentally or out of curiosity, having the menu toggled on can cause the integrity check to fail.

How to check: Go to Settings and scroll down — if a Developer Options menu is visible and toggled on, it is active.

Fix: Go to Settings > Developer Options and toggle off the switch at the very top of the screen. Restart the phone after disabling it.

Cause 4: USB Debugging Enabled

USB Debugging is a sub-option within Developer Options but can sometimes appear to remain active independently. It signals that the device can accept ADB commands from a connected computer — a capability that represents a meaningful security exposure and one that Play Integrity may flag.

Fix: Go to Settings > Developer Options > USB Debugging and toggle it off. If Developer Options is also enabled, disable the entire section as described in Cause 3 above.

Cause 5: Google Play Services or Play Store Out of Date

Play Integrity runs through Google Play Services. An outdated version of Play Services can return incorrect attestation results, causing devices that are actually compliant to fail the check.

Fix: Open the Google Play Store, tap your profile icon, go to Manage apps and device, and check for available updates. Update both Google Play Services and the Google Play Store itself if updates are shown. Restart the phone after updating.

Cause 6: Google Play Services Cache Corrupted

A corrupted Play Services cache can independently cause integrity check failures — entirely separate from whether the device is actually compromised or non-compliant.

Fix: Go to Settings > Apps, tap the three-dot menu and select Show system apps, then find Google Play Services. Tap Storage, then Clear Cache. Do not clear data — clear cache only. Repeat this process for the Google Play Store app. Restart the phone.

Cause 7: Microsoft Authenticator App Needs Updating or Cache Clearing

An outdated version of the Authenticator app may not correctly interpret Play Integrity responses, or a previously cached integrity result may be stale and stuck showing a failure from an earlier device state.

Fix: Update Microsoft Authenticator via the Play Store. Then go to Settings > Apps > Microsoft Authenticator > Storage and tap Clear Cache. Restart the app and check whether the warning is still present.

Cause 8: Samsung Good Lock or Samsung Labs Features

Certain Samsung-specific system customisation tools — particularly Good Lock modules and some experimental features within Samsung Labs — operate at a system level that can affect Play Integrity results. Modules that modify the home screen, lock screen, notification system, or multitasking behaviour are the most likely to cause issues.

How to check: Search for Good Lock in the Play Store — if it is installed, open it and review which modules are currently active.

Fix: Disable or uninstall active Good Lock modules, particularly any that modify core system UI. For Samsung Labs: go to Settings > Advanced Features > Samsung Labs and disable any active experimental features. Restart after making changes.

Cause 9: Accessibility Services with Elevated Permissions

Apps granted Accessibility access can read screen content and interact with other apps — a level of system access that Play Integrity can interpret as a potential security risk, particularly when granted to non-essential apps.

How to check: Go to Settings > Accessibility > Installed apps (labelled as Downloaded apps on some Samsung devices) and review anything listed with access enabled.

Fix: Disable accessibility permissions for any app that does not genuinely require them for its core function. Common offenders include call recording apps, automation apps such as Tasker or MacroDroid, and screen reader tools installed for testing purposes.

Cause 10: Bootloader Status

If a device has ever had its bootloader unlocked — even if subsequently re-locked — the hardware attestation record may be permanently affected. This is uncommon on consumer Samsung devices purchased through standard UK retailers but is more likely on devices acquired second-hand or through grey import channels.

How to check: Go to Settings > About Phone > Software Information and look for a bootloader status indicator. On Samsung devices, a Knox warranty void flag (such as a 0x1 Knox status) will indicate the bootloader has been unlocked at some point in the device’s history.

If the bootloader has been unlocked and re-locked, this may not be recoverable via a factory reset — and on some devices, the hardware attestation status cannot be restored at all. This is a situation that requires escalation to your IT administrator.

Cause 11: VPN App Using System-Level Hooks

Some VPN applications — particularly those from smaller or less established providers — request device administrator or system-level VPN permissions that interact with network traffic at a level Play Integrity may flag.

Fix: Go to Settings > Apps, tap the three-dot menu, select Special access, then Device admin apps — revoke administrator access from any VPN app not currently in use. Also check Settings > Connections > More connection settings > VPN and remove any inactive VPN profiles.

Cause 12: Work Profile or MDM Conflict

If your organisation uses a Mobile Device Management (MDM) solution — such as Microsoft Intune, Jamf, or another Enterprise Mobility Management platform — a policy conflict or incomplete enrolment can cause compliance failures that surface in Authenticator as a device integrity warning.

Fix: Contact your IT administrator. This cannot be resolved from the device side alone and requires investigation at the MDM policy level. If your organisation uses Microsoft Intune, check whether the device shows as fully enrolled and compliant within the Intune Company Portal app.

Cause 13: Device Not Certified by Google (Rare)

Play Integrity requires devices to be certified by Google. Devices sold through unofficial channels, grey market imports, or certain budget Android handsets may not carry Google certification and will fail the integrity check regardless of their actual state.

How to check: Open the Google Play Store, tap your profile icon, go to Settings > About, and look for Play Protect certification. It should read “Device is certified.”

If the device shows as uncertified, this cannot be resolved through settings changes alone. It may require a factory reset combined with flashing official firmware — and in some cases cannot be resolved at all if the device was never certified. This is a situation that warrants contacting your IT administrator.

Step-by-Step Diagnostic Process

Work through these steps in order. After completing steps 1 through 8, check whether the warning has cleared before proceeding further.

1. Open My Files > Downloads and look for any APK files — uninstall any sideloaded apps and delete the APK files.
2. Go to Settings > Apps > Special access > Install unknown apps and revoke the permission from every app that has it enabled.
3. Go to Settings > Developer Options and toggle off the entire section if it is enabled.
4. Open the Play Store and update both Google Play Services and the Google Play Store itself.
5. Clear the cache for Google Play Services via Settings > Apps > Show system apps (cache only, not data).
6. Update Microsoft Authenticator from the Play Store, then clear its cache via Settings > Apps > Microsoft Authenticator > Storage.
7. Restart the phone.
8. Open Microsoft Authenticator and check whether the warning is gone.
9. If the warning is still showing: go to Settings > Accessibility and revoke unnecessary accessibility permissions from non-essential apps.
10. If still showing: open Good Lock (if installed) and disable active modules; check Samsung Labs and disable experimental features.
11. If still showing: contact your IT administrator to rule out an MDM or Intune compliance policy conflict.

If None of the Fixes Work

On newer Samsung devices — particularly the S24 and S25 series running One UI 7 — there are documented cases where the Play Integrity check fails intermittently due to how Samsung’s firmware interacts with the attestation process. This is not caused by anything the user has done. In these situations:

• Ensure all Samsung system updates and security patches are installed via Settings > Software update.
• Try completing the Authenticator approval using the number matching flow rather than the standard push notification, which may bypass the integrity check in some configurations.
• Report the issue to Microsoft directly from within the app: tap the three-dot menu inside Authenticator and select Send feedback.
• IT administrators can temporarily configure a Conditional Access policy exclusion for affected users while Microsoft investigates the underlying issue. Any such exclusion should be time-limited, clearly documented, and reviewed regularly.

For IT Administrators: Conditional Access and Play Integrity

Microsoft Intune’s device compliance policies can be configured to require either MEETS_DEVICE_INTEGRITY or MEETS_STRONG_INTEGRITY as the minimum attestation level for Android devices. If users begin reporting widespread failures following a device firmware update or a Microsoft Authenticator update, the first step is to determine whether a recent change to your compliance policy or App Protection Policy — or a change in how Authenticator interprets attestation results — has raised the effective threshold.

Review the App Protection Policy settings within Intune for the relevant Android policy and check the Play integrity verdict setting under device conditions. Microsoft’s documentation on App Protection Policies covers all Play Integrity configuration options available to administrators. Where a specific device model is known to be producing false-positive failures, a targeted exclusion group can be applied while the firmware or Authenticator issue is resolved upstream.

Will This Become More Common?

Yes. As Microsoft continues enforcing Play Integrity across its broader suite of mobile applications — not just Authenticator, but also Outlook, Teams, and OneDrive — any device modification or configuration that would have gone unnoticed under the older SafetyNet system will now produce compliance warnings. Users who regularly sideload apps, use automation tools, enable developer settings for testing purposes, or install apps from unofficial sources will encounter these warnings more frequently as Microsoft’s mobile security posture continues to tighten.

The majority of cases are resolved by uninstalling a sideloaded app, revoking the install unknown apps permission, and disabling Developer Options — often all three together. If the warning persists after all of those fixes have been applied, the remaining causes are less common and are likely to require IT administrator involvement to investigate at the policy or device management level.