Whenever the screen shows authentication codes, recovery values, approval prompts, or other data that can be used to prove identity or authorise access. If that content can be observed indirectly, the display becomes part of the trust boundary. Identity teams should govern it with the same care as credentials and tokens.
When display content crosses into identity control
Sensitive display content becomes an identity risk when the screen is no longer just informational and starts carrying proof, approval, or recovery value. Authentication codes, reset values, step-up prompts, and transaction approvals can all be replayed, relayed, or socially engineered if they are visible to the wrong person or captured through screenshots, remote support, shared screens, or notification previews.
The practical test is simple: if a user could use the displayed content to get in, regain access, or authorise an action, then the display is part of the identity trust chain. That means app teams should treat the presentation layer as security-relevant, not merely a UI concern, because the display itself may be the last control standing between an attacker and access.
What kinds of content belong in that risk class
The highest-risk examples are one-time passcodes, recovery codes, magic links, verification numbers, approval dialogs, device trust confirmations, and any screen that reveals enough context to satisfy a challenge or complete an authorisation step. The same logic applies when the content is not a secret in the strict sense but still acts as a bearer signal for identity or privilege.
This is why teams should distinguish between ordinary status text and content that changes the security state of a session or account. A password reset token shown in a browser, an approve/deny prompt on a companion app, or a “confirm login” banner on a shared workstation can all create a direct path from observation to compromise if the display channel is weakly controlled.
For identity-heavy applications, the display itself needs lifecycle thinking. The right question is not only whether the value is encrypted in transit or stored safely, but also whether it is exposed on lock screens, cached in notifications, persisted in logs, mirrored to connected devices, or readable through assistive technologies in ways the business did not intend.
How app teams should design for safe exposure
Design the UI so the least necessary identity value is shown for the shortest possible time, and only to the intended user context. Use truncation, masking, time limits, explicit re-entry for sensitive actions, and contextual warnings where the content is likely to be observed indirectly. Where practical, move sensitive approval or recovery steps into channels that support stronger verification and tighter session binding.
Teams should also treat display events as auditable security events when they materially affect authentication or authorisation. That means knowing when a code was rendered, whether it was dismissed, whether the screen was backgrounded, and whether the user changed device context before completing the action. Identity and access guidance for service and application identities is useful here because the same trust-boundary thinking applies whether the actor is human or non-human.
For product teams, the key control question is whether the display can be captured, forwarded, or replayed in a way that preserves its security value. If the answer is yes, then the UI needs stronger containment, and security review should cover screenshot policy, notification behaviour, session timeout, and any step that lets one device observe another device’s trust prompt.
Risk and Threat Considerations
Sensitive display content is attractive to attackers because it often bypasses technical controls by targeting the user’s eyes, devices, or support channels instead of the backend. If approval prompts, recovery values, or one-time codes are visible during screen sharing, remote assistance, shoulder surfing, or notification previews, the attacker may not need to break encryption or guess a password at all.
Failure mechanism: The application exposes a value that can complete or unlock an identity step, and the exposure survives long enough to be observed, copied, or relayed. That can happen through screenshots, synced notifications, remote access tools, poor masking, reused devices, or prompts that do not bind the approval to the right action, session, or context.
Impact: A leaked display value can enable account takeover, fraudulent approval, unauthorized recovery, or privilege escalation. In the worst case, the attacker uses a legitimate-looking interaction to cross the trust boundary and make the compromise hard to distinguish from normal user behaviour.
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 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Sensitive display content often includes authenticators or recovery values that need lifecycle control. |
| IA-2 — Identification and Authentication (Organizational Users) | Displayed codes and prompts can directly affect user authentication outcomes. | |
| AC-6 — Least Privilege | Approval prompts and recovery flows can expose more authority than needed if screens are overbroad. | |
| Recommendation — Limit exposure, lifetime, and reuse of authenticators and recovery values shown to users. Bind display-dependent authentication steps to the intended user session and context. Restrict displayed approval and recovery actions to the minimum authority required. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Screened identity data can grant access, so display handling is part of access control. |
| Recommendation — Apply access-control rules to what identity-sensitive content can be revealed on screen. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Displayed codes and recovery values are secret material when they can be used to prove identity. |
| Recommendation — Prevent secret values from being rendered, logged, or exposed through UI paths. | ||
Practitioner Guidance
What to verify: Confirm whether every sensitive display element is tied to a specific identity event, whether it expires quickly, and whether it remains usable after capture. If a prompt or code can still be acted on after it is observed outside the intended context, treat that as a control gap rather than a cosmetic issue.
Common mistake: Teams often harden the backend while leaving the screen channel open. That misses the real failure mode, which is not only credential theft but also trust-boundary leakage through UI, notifications, and human-assisted workflows.
What good looks like: The display reveals only the minimum necessary information, the value is time-bounded, the action is context-bound, and sensitive events leave an auditable trail. The safest implementation is the one that assumes the screen can be observed and still does not expose a reusable trust artifact.
Practitioner takeaway: If a displayed value can help someone authenticate, recover, or approve, treat it like identity material from the moment it is rendered, not from the moment it is stored.
Related resources from NHI Mgmt Group
- When should teams treat a machine identity as high risk?
- Why do app-native identity workflows create governance risk for IAM teams?
- Why do automated content pipelines create identity risk for IAM teams?
- How should security teams decide between data-layer security and access graph controls when identity risk and sensitive data exposure overlap?