1Password’s browser extension changes how in-page notifications work

At a glance

What this is: 1Password’s browser extension now handles in-page notifications as a stacked, stateful flow rather than a single transient prompt, reducing lost actions and duplicate pop-ups.

Why it matters: For IAM and browser-extension practitioners, the change shows how identity and trust prompts need durable state handling when passkeys, device trust, and login guidance must survive page navigation.

Context

1Password’s article is about the governance and UX problem created when security and identity prompts only exist as one-off overlays in the browser. In-page notifications have become a control surface for saving credentials, passkey sign-in, third-party login suggestions, breach alerts, and device trust remediation, so the notification layer now carries operational identity work, not just messaging.

The old design could show only one notification at a time, and a second prompt could displace the first before the user acted. That made the browser extension brittle for identity workflows that depend on context persistence across tabs and pages. The article’s core point is that the notification layer needed to behave like a governed state system, not a disposable UI event.

For identity teams, this is a browser-extension governance story as much as a product note. The underlying issue is not visual polish, but whether important authentication and remediation prompts remain available long enough to be completed.

Key questions

Q: How should security teams handle browser identity prompts that can be lost during navigation?

A: Treat browser prompts as governed workflow state, not disposable UI events. Persist the notification state outside the page renderer, preserve priority across tabs and navigation, and ensure the action remains available until the user completes or dismisses it. That prevents security-relevant prompts from disappearing mid-flow and reduces missed remediation.

Q: Why do stacked browser notifications matter for passkeys and device trust flows?

A: Stacking matters because identity actions often arrive in quick succession, and only one prompt should not be allowed to erase another. A stack preserves ordering and context, so passkey, trust, and remediation prompts remain actionable instead of being overwritten by the next event.

Q: What breaks when browser-extension notification state lives only in the interface layer?

A: When the interface owns state, page changes and redraws can destroy the control context that a user still needs to finish the task. That creates duplicate prompts, missing alerts, and incomplete identity workflows. The failure is architectural, because the control boundary is too shallow to preserve state.

Q: Should teams separate fullscreen security prompts from ordinary browser notifications?

A: Yes. Blocking identity prompts should have explicit precedence over informational or lower-priority notifications, because they alter the user’s ability to continue. Mixing them without clear ordering creates ambiguity about which prompt governs the session and can delay critical authentication or trust actions.

Technical breakdown

Why transient browser prompts fail for identity workflows

In-page notifications are the browser-extension pattern used to present identity-relevant actions directly inside a web page. When each prompt exists as a separate UI event, the extension can lose state as the user navigates, which means the security action and the prompt that triggered it no longer stay aligned. That is why stacking matters: it preserves priority, context, and order when several identity events arrive close together. For passkeys, device trust, and breach remediation, the control is only useful if the prompt survives long enough to be acted on. Practical implication: design browser-extension identity prompts as persistent workflow objects, not disposable overlays.

Practical implication: treat browser-extension prompts as workflow state that must survive navigation, not as single-use pop-ups.

How a service worker changes notification state management

The article says notification state moved from the user interface to the service worker, with storage kept locally in chrome.storage.session. In practice, that shifts the browser extension from a presentation layer that merely renders prompts to a control plane that owns notification truth, deduplication, and lifecycle. The UI then asks the service worker what should be shown, instead of inventing state on its own. That architecture is important because it reduces duplicate prompts and lets the extension track what is already visible on each tab. Practical implication: put notification truth in the extension layer that can preserve state across UI redraws and page changes.

Practical implication: keep notification truth in the service worker so the interface only renders governed state.

Why fullscreen notifications need separate flow handling

Fullscreen notifications are used when a user must complete a security-sensitive step before interacting with the web page, such as passkey or Device Trust flows. The article notes that stacked notifications and fullscreen mode had to be rebuilt together so the fullscreen item can temporarily hide the remaining stack, then restore it after completion. That matters because fullscreen is not just a larger prompt. It is a gating mechanism that changes execution order and user attention. Practical implication: treat fullscreen identity prompts as a separate interaction class with explicit precedence over lower-priority notifications.

Practical implication: give blocking identity prompts explicit precedence rules before mixing them with non-blocking notifications.

Threat narrative

Attacker objective: The practical objective is not attack execution but preservation of user action integrity, so the browser extension can keep security prompts visible until they are resolved.

1. Entry occurs when the browser extension receives identity-relevant events such as passkey use, breach detection, third-party sign-in suggestions, or device trust remediation.
2. Credential or prompt handling breaks down when only one notification can exist at a time, causing earlier actions to disappear or be lost during page navigation.
3. Impact is user friction and missed security actions, including duplicate prompts, lost remediation steps, and incomplete identity workflows.

Breaches seen in the wild

• Gitloker GitHub extortion campaign: Phishing via GitHub notifications tricked developers into authorising malicious OAuth apps; Gitloker then wiped repos and demanded contact.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Stateful notification handling is now part of identity governance in the browser. When a browser extension becomes the place where credential saves, passkey sign-ins, breach alerts, and device trust remediation are initiated, the notification layer stops being cosmetic. It becomes a control surface that determines whether an identity action is completed or lost. The practitioner lesson is that browser UX and identity governance now meet in the same execution path.

Prompt persistence is the real control requirement, not prompt count. The problem the article exposes is not simply that users saw too few messages. It is that security-relevant prompts had no durable state model, so one notification could displace another before the action was finished. That is a governance failure in miniature: the control existed only while the interface stayed still. The implication is that browser-extension security needs lifecycle-aware state, not static overlays.

Fullscreen identity prompts need precedence rules because they change user readiness. Passkey and Device Trust flows are blocking by design, which means they sit above lower-priority prompts in the interaction hierarchy. If that hierarchy is not explicit, the browser extension creates ambiguity about which identity action matters first. Practitioners should read this as evidence that workflow ordering is part of access control, not just user experience.

Extensibility is the hidden maintenance gain in this design. The article describes migration away from bespoke notification variants toward a shared in-page system, which reduces drift between similar identity prompts. That matters because every bespoke exception becomes a future governance exception when the control surface evolves. The practical conclusion is that identity workflows in browser extensions should be built as reusable state machines, not one-off interaction paths.

Browser-extension controls are becoming a distributed identity plane. As more trust, authentication, and remediation work lands inside the browser, the extension has to act consistently across tabs, pages, and interaction modes. That makes the service worker, UI, and storage layer part of the same control boundary. Practitioners should treat browser extensions as governed identity infrastructure, not as thin client code.

What this signals

Prompt state is becoming an identity control plane. Browser extensions increasingly mediate authentication, trust, and remediation steps that used to live elsewhere in the stack. That means teams need to think about notification lifecycle, not just prompt design, because the state model now determines whether users can complete security actions without interruption.

Notification stacking is a form of access workflow governance. If several identity events can arrive together, the system must preserve priority and sequence or it will create accidental control loss. The practical signal for IAM and browser-extension teams is that user-visible security actions need the same state discipline that back-end identity workflows already require.

For practitioners

• Define notification precedence for browser identity flows Map which prompts must stay visible across navigation, which may stack, and which must temporarily suppress lower-priority notifications.
• Move notification truth out of the UI layer Keep notification state in the browser-extension service worker or equivalent control layer so duplicate prompts and lost actions are prevented by design.
• Separate blocking and non-blocking identity prompts Treat passkey and Device Trust interactions as fullscreen or gating flows, with explicit restore logic for any queued notifications afterward.
• Migrate bespoke prompts into a shared workflow model Consolidate custom notification variants into a common state machine so identity and remediation prompts behave consistently across channels.

Key takeaways

• Browser-extension notifications are now part of the identity workflow, so losing prompt state can directly interrupt credential, passkey, and trust actions.
• The article’s architectural shift is to keep notification truth in the service worker, which makes duplicate suppression and cross-page persistence possible.
• Practitioners should treat browser prompts as governed stateful controls, with explicit precedence for fullscreen security flows and shared lifecycle handling for all notifications.

Key terms

• In-page notification system: A browser-extension mechanism that displays identity or security prompts inside the page context rather than in a separate app window. In practice, it becomes part of the access experience, so its state, timing, and priority directly affect whether users complete security actions reliably.
• Service worker state: A browser-extension pattern where background logic, not the visible interface, owns the current state of an interaction. For identity workflows, this helps preserve prompt continuity across tabs and reloads while keeping sensitive information local to the device.
• Fullscreen notification: A blocking prompt that interrupts normal page interaction until a required identity or trust action is completed. It is appropriate when the control is mandatory, not optional, and should be reserved for flows such as passkey use or device trust remediation.
• Notification Stack: A grouped presentation model that keeps multiple prompts visible in ordered form rather than replacing one with another. For identity and security workflows, stacking prevents prompt loss when several actions arrive in quick succession and helps preserve execution order.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.