Mobile App Permissions: Android and iOS Permissions Explained and Governed

Mobile app permissions are the switches that decide which of your phone's data and hardware an app may use, and a single wrong "Allow" can hand an app your messages, location or full control of the screen. On Android and iOS, apps run in a sandbox and must ask before reaching outside it: to your camera, microphone, contacts, photos, location, notifications or text messages. This guide explains, in plain language, how those permissions work on both platforms, which ones are genuinely high risk, how to check and remove them, and how organisations govern them with app vetting and mobile device management. It is for anyone deciding whether to tap "Allow", and for the security and IT teams who set policy for work phones. Platforms are listed alphabetically, Android then iOS; order is not a ranking.

Key takeaways

• Not all permissions are equal. Camera and location are visible and familiar; accessibility access, SMS access, "display over other apps" and notification access are rarer and far more dangerous because they let an app read or act on everything else.
• Grant the narrowest option offered. Both platforms offer one-time or "while using the app" access, and approximate instead of precise location. Choose those unless the app genuinely needs more.
• Permissions can be changed at any time. Android settings and iOS Settings, Privacy & Security both let you review and revoke access per app, and iOS Safety Check can reset app privacy permissions in one step.
• Store policies help but do not decide for you. Google Play restricts SMS, call log and accessibility access to declared, approved uses, and Apple requires apps to explain every request. Neither removes the need to read the prompt.
• Organisations should govern, not just advise. App vetting, managed app stores and MDM permission policies stop risky grants on work devices before a user ever sees the prompt.

What it is

A mobile app permission is a named capability the operating system lets an app use only after it is granted. Without permissions, an app can see little beyond its own files. With them, it can read your contacts, record audio, track where you are or post notifications. The operating system enforces the decision, so an app cannot simply read your location because it wants to.

How it works

Android

• Runtime prompts: apps must request sensitive permissions while running and should check each time, because the user may have revoked them. From Android 11, location, microphone and camera prompts offer Only this time, which ends shortly after you leave the app.
• Denying twice means no: if you tap Deny twice for the same permission, Android stops showing the prompt for that app. The app must send you to settings instead, which is a useful signal: an app that keeps nagging through its own screens wants something badly.
• Location choices: from Android 10, background location is a separate permission from foreground location. From Android 12, users can grant Approximate rather than Precise location.
• Notifications: from Android 13, posting notifications is a runtime permission (POST_NOTIFICATIONS), and new installs of apps that target Android 13 start with notifications off.
• Visibility: from Android 12, a status bar indicator shows when an app uses the camera or microphone, global camera and microphone toggles sit in Quick Settings and the Privacy screen, and a toast appears when an app reads clipboard content copied in another app.
• Auto-reset: for apps targeting Android 11 or later, sensitive runtime permissions are reset automatically if the app goes unused for a few months.

iOS

• Prompt once, then remember: the system prompts the first time an app touches a protected resource, remembers the answer, and does not ask again. Changes are made in Settings at any time.
• Mandatory explanation: each protected resource needs a purpose string in the app (for example NSLocationWhenInUseUsageDescription for location while in use). Apps that access protected resources without one are rejected by App Review, and third-party code inside the app is covered by the same rule.
• Location: location prompts include Allow Once for a single session.
• App Privacy Report: on iOS 15.2 or later, Settings, Privacy & Security, App Privacy Report shows which apps accessed location, camera, microphone and other data and which network domains they contacted over the past seven days. It is off until you turn it on and stays on the device.
• Safety Check: on iOS 16 or later, Settings, Privacy & Security, Safety Check offers Emergency Reset, which stops sharing with all people and apps at once and can reset system privacy permissions for apps, and Manage Sharing & Access for item-by-item review.

Why it matters

The permissions that matter most are those that let an app see or control what other apps show. Mobile malware relies on exactly these, and MITRE ATT&CK for Mobile records the techniques.

Store policy reflects the same risk ranking. Google Play restricts the SMS and call log permission groups (including READ_SMS, RECEIVE_SMS, SEND_SMS and READ_CALL_LOG) to apps registered as the default SMS, Phone or Assistant handler, plus listed exceptions, all declared through the Permissions Declaration Form. Its AccessibilityService policy allows the isAccessibilityTool flag only for tools designed to help people with disabilities, and requires other apps to show a prominent in-app disclosure and obtain affirmative consent. All files access is restricted in the same way. These rules apply to Play; apps installed from other sources face none of them, which is one reason sideloading is high risk. See the Mobile Malware Guide.

• Where identity fits: SMS and notification access defeat SMS and push one-time codes, which is why phishing-resistant sign-in matters on mobile. See the Phishing-Resistant MFA Guide.

Governing permissions in an organisation

1. Decide device ownership models first: company-owned fully managed devices allow full permission control; personally owned devices with a work profile (Android) or user enrolment (iOS) allow control only inside the work container. See the Android Enterprise Security Guide and the Mobile Device Management Security Guide.
2. Vet apps before approval: review requested permissions against the app's purpose, the store privacy label, the developer and update history. Treat accessibility, SMS, overlay and notification-listener requests as automatic escalation for review. OWASP MASVS-PRIVACY gives testable criteria for app privacy behaviour.
3. Publish through a managed store: on work devices, allow only approved apps and block unknown sources.
4. Set permission policy: Android Enterprise policies include a default runtime permission policy and per-app permission grants, so an administrator can keep prompting as the default, pre-grant what a line-of-business app needs, and deny what it must never have. Pilot with a small ring and keep the prompt default until the per-app list is proven.
5. Roll back safely: if a policy breaks an app, revert that app's grant to user choice rather than switching the whole fleet to auto-grant.
6. Re-review on change: when an approved app update requests a new high-risk permission, suspend auto-update for it until reviewed.

Detection and measurement

• Monitor: MDM inventory of installed apps and granted permissions, especially accessibility and device administrator grants; mobile threat defence alerts for overlay and sideloaded apps; new permission requests in app updates.
• Metrics: percentage of managed devices with any non-approved app holding accessibility access (target zero); number of apps with SMS permission that are not the default messaging app; share of approved apps reviewed in the last 12 months; time from new high-risk permission request to review decision; percentage of devices blocking unknown sources.

Common misconceptions

• "If it is in the official store, it is safe": store review reduces risk but approved apps can still request more than they need, and updates can add requests later.
• "Denying a permission breaks the app": well-built apps keep working and ask again in context. An app that refuses to run at all without contacts or location is telling you about its business model.
• "Accessibility is only about accessibility": on Android it is one of the most powerful grants available, which is why Google restricts it. Cleaners, launchers, antivirus and password managers do not qualify as accessibility tools under Play policy.
• "Notifications are harmless": posting notifications is low risk, but notification access, which reads everyone else's notifications, is high risk. They are different settings.
• "I said no once, so I am covered": permissions granted years ago stay granted unless auto-reset removes them. Review every few months, or use App Privacy Report or Safety Check.
• "MDM sees everything on my phone": on personally owned devices with a work profile or user enrolment, the organisation manages the work container, and what it can see depends on the enrolment type and product, so check your organisation's privacy notice.

Related concepts

• Privacy labels: store listings describe the data an app collects; compare them with the permissions it requests. See the OWASP Mobile Top 10 M6 Inadequate Privacy Controls Guide.
• Desktop equivalents: macOS uses Transparency, Consent and Control for the same idea. See the macOS TCC and Privacy Permissions Management Guide.
• App developers: request the minimum, ask in context, and handle denial. See the Mobile App Security Guide.
• Framework mapping: NIST SP 800-53 Rev. 5 AC-3 (access enforcement) and CM-11 (user-installed software) apply on managed devices; NIST CSF 2.0 PR.AA-05 covers permissions defined and reviewed under least privilege; ATT&CK for Mobile techniques are listed in the table above.

Practitioner checklist

• Review every app holding accessibility, SMS, overlay or notification access on your own phone today and remove any you do not recognise.
• Prefer one-time, while-using and approximate location options; refuse background location unless the app's purpose needs it.
• Turn on App Privacy Report on iPhones used for sensitive work, and know where Safety Check is.
• On work devices, block unknown sources and publish apps only through a managed store.
• Escalate any app requesting accessibility, SMS, overlay or notification-listener access to security review.
• Set a per-app permission policy for line-of-business apps and keep prompting as the default for the rest.
• Report monthly on high-risk permission grants across the fleet.
• Move users off SMS codes to phishing-resistant sign-in where mobile malware is a realistic threat.

Standards and references

• Android Developers: Permissions on Android
• Android Developers: Request runtime permissions
• Android Developers: Android 12 behaviour changes for all apps
• Google Play: Use of SMS or Call Log permission groups
• Google Play: Use of the AccessibilityService API
• Apple: About App Privacy Report
• Apple: Safety Check for iPhone with iOS 16 or later
• OWASP: Mobile Application Security Verification Standard

Related NHI Mgmt Group resources: Android Enterprise Security Guide · Mobile Device Security Guide · Mobile Malware Guide · Mobile Spyware Infection Response Playbook