Android 6.0 Permissions Model is the runtime permission system introduced for Android apps. It asks users to grant sensitive permissions when an app needs them, rather than only at installation, so access to camera, location, contacts, and similar resources can be reviewed and revoked more granularly.
What the Android 6.0 permissions model changed
Android 6.0 moved sensitive access decisions from install time to runtime. That shift matters because users can decide after seeing the app in context, and because the app must now justify why it needs camera, location, contacts, or other protected capabilities at the moment it actually requests them.
This model improved granularity, but it also made permission handling part of the app’s live trust boundary. A well-designed app must expect denials, partial grants, and later revocation, rather than assuming broad access is permanently available.
How runtime permissions affect app design
Runtime permissions change the shape of the user experience and the code path. Features that depend on sensitive resources need to degrade cleanly when permission is not yet granted, and the app should request access only when the action makes the need understandable to the user.
That timing matters for trust. Asking too early can feel coercive; asking too late can break a workflow. The best implementations separate core app function from permission-gated features so that the app remains usable even when access is refused.
Because the decision is contextual, the model also reduces the value of one-time consent screens. Users can review permission requests in a way that is closer to actual use, which improves transparency but also means the app must be ready to re-handle permission state throughout its lifecycle.
Security and privacy implications
The main security benefit is reduced overexposure. Sensitive device data is not automatically available just because the app was installed, which lowers the blast radius of a malicious or overly curious app and gives users a chance to revoke access later.
That does not eliminate abuse. A legitimate-looking app can still request permissions that are broader than its stated purpose, and once granted, those permissions can support tracking, data harvesting, or misuse of device sensors and personal data. Permission prompts therefore remain a trust signal, not a guarantee of benign behaviour.
The model also creates a governance issue for developers and reviewers: the permission set should match the feature set. When an app requests capabilities that are not clearly needed, users have less reason to trust the request and security teams have less confidence in the app’s declared behaviour.
Operational patterns and common implementation pitfalls
Apps built for runtime permissions need explicit handling for denial, “don’t ask again” choices, and later revocation in system settings. If those states are not handled cleanly, users experience broken features, confusing errors, or repeated prompts that encourage unsafe approval habits.
Another common pitfall is coupling app startup to permission approval. That design creates fragile software and can push users toward granting access just to make the app function, even when the permission is only needed for an optional feature.
A better pattern is to ask at the point of need, explain the feature dependence in plain language, and keep the rest of the app available. That approach makes the permission model work as intended, as a selective access control layer rather than a blanket gate.
Risk and Threat Considerations
The security risk is not the permission prompt itself, but the misuse of granted access. If an app obtains sensitive permissions unnecessarily, it can expose personal data, sensor data, or location information far beyond what the user expected.
Failure mechanism: Overbroad permission requests, misleading feature justifications, or weak post-grant handling can turn a normal app into a data collection path or a privacy abuse vector.
Impact: Users may lose confidentiality over device data and become vulnerable to tracking, profiling, or broader compromise if the app is malicious or later updated with harmful behaviour.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Runtime permissions limit access to protected device resources to what the app needs. |
| IA-5 — Authenticator Management | Permission state is an access grant that must be managed, reviewed and revocable over time. | |
| AC-3 — Access Enforcement | The OS enforces whether an app may use sensitive functions after the user decision. | |
| Recommendation — Apply AC-6 to request only the permissions required for the current feature. Track granted permissions as controlled access state and revoke unnecessary access promptly. Enforce permission checks at the point of access and fail closed when permission is absent. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org