An Android developer flag intended to restrict screenshots and prevent sensitive screens from appearing in recents or on external displays. It is useful as a presentation-layer control, but it does not stop rendering itself, so it cannot by itself block attacks that recover information from the graphics pipeline.
Expanded Definition
FLAG_SECURE is an Android window-level setting that signals the operating system to suppress screenshots, block most screen recording paths, and keep protected content out of recent-task thumbnails and some external display paths. It is best understood as a presentation-layer safeguard, not a data protection boundary. In NHI and mobile application security work, it is used when a screen may expose credentials, approval workflows, recovery codes, device trust signals, or other sensitive operational data.
Definitions vary across vendors and application frameworks, but the security intent is consistent: reduce casual capture of content that would otherwise be visible during normal rendering. That makes it a useful control for UI exposure, especially when paired with stronger identity and access controls described in the NIST Cybersecurity Framework 2.0. It does not encrypt the pixels, prevent memory inspection, or stop downstream leakage from logs, accessibility services, overlays, rooted devices, or compromised screenshots taken before the flag is honored.
The most common misapplication is treating FLAG_SECURE as a complete secret-protection control, which occurs when teams assume blocking screenshots also prevents data extraction from the app, device, or graphics pipeline.
Examples and Use Cases
Implementing FLAG_SECURE rigorously often introduces usability and support friction, requiring organisations to weigh leakage reduction against legitimate user workflows such as troubleshooting, remote assistance, and accessibility review.
- A password manager or admin console marks its session screen secure so one-time codes and recovery material are less likely to appear in screenshots or app-switcher previews.
- A privileged mobile approval app uses FLAG_SECURE while displaying NHI-related actions, complementing the governance and lifecycle practices described in the Ultimate Guide to NHIs.
- A customer support flow hides account verification details on device previews, while server-side controls still enforce authentication and authorization independent of the UI.
- A security operations app enables the flag for screens showing API keys or certificate material, but also requires secret rotation because screenshot blocking cannot undo exposure after viewing.
- A regulated finance or healthcare app uses the flag during sensitive review steps, then disables it where compliance teams need legitimate evidence capture and audit handling.
Android platform guidance and ecosystem behavior evolve over time, so implementation should be validated on the exact OS versions and device classes in use, not assumed from a single test device or emulator image.
Why It Matters in NHI Security
FLAG_SECURE matters because NHI incidents often begin with visible secrets, not exotic exploitation. If a service credential, API token, or privileged approval screen can be photographed, mirrored, or previewed, then the exposure problem has already moved from device hygiene into identity governance. The risk is amplified in environments where secrets are already overexposed: NHI Mgmt Group reports that 79% of organisations have experienced secrets leaks and 96% store secrets outside secrets managers in vulnerable locations, which means UI-layer exposure can become one more path into an already fragile control set.
That is why FLAG_SECURE should be positioned as one layer in a broader control stack that includes secure secret storage, least privilege, rotation, and monitoring. It supports the visibility and exposure-reduction goals reflected in Ultimate Guide to NHIs, but it does not replace them. Practitioners should pair it with policy decisions rooted in NIST Cybersecurity Framework 2.0 so screen controls are treated as support for governance, not a substitute for it.
Organisations typically encounter the consequences only after a privileged screen is captured during incident response or user support, at which point FLAG_SECURE becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Presentation-layer exposure can leak secrets and NHI data if screens are not hardened. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access should extend to what privileged screens reveal on mobile devices. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires limiting exposure paths, including client-side presentation channels. |
| NIST AI RMF | AI risk governance covers sensitive interface exposure and downstream misuse of displayed data. | |
| CSA MAESTRO | Agentic workflows that show secrets need front-end protections plus back-end identity controls. |
Evaluate whether protected UI content could be captured, replayed, or repurposed by other systems.
