Notifications
Clear all
Topic starter
02/08/2026 11:43 am
TL;DR: Omada Health says moving browser control into an enterprise browser reduced browser sprawl, cut support burden, expanded password-manager coverage to all users, and tightened review of extensions while protecting HIPAA-covered data, according to Island. The governance lesson is that browser-layer control increasingly sits inside identity and access management, not beside it.
NHIMG editorial — based on content published by Island: How Omada Health Keeps Patient Data Safer at Half the Cost with Island
By the numbers:
- Omada Health’s browser-based password manager was rolled out to 100% of end users, up from about 5% before.
- Omada Health serves more than 1,900 customers worldwide.
Questions worth separating out
Q: How should security teams govern browser-based access to sensitive applications?
A: Treat browser-based access as part of the privileged access surface when it reaches cloud consoles, admin portals, or operational systems.
Q: Why does browser sprawl create identity and access risk?
A: Browser sprawl creates risk because different browsers often have different patch states, extension sets, and policy behaviour.
Q: What do organisations get wrong about data security in cloud and SaaS environments?
A: They often assume classification alone will control exposure.
Practitioner guidance
- Standardise approved browser footprints Limit the number of browsers users can rely on for sensitive workflows so patching, extension approval, and policy enforcement stay consistent across managed endpoints.
- Treat extensions as governed access paths Require formal review and approval for every extension that can touch authentication, session data, or healthcare information, with audit logs for changes and exceptions.
- Map browser policy to identity provider controls Align browser session rules, sign-in handoff, and user exceptions with identity provider policy so the browser does not become an unmanaged access layer.
What's in the full article
Island's full post covers the operational detail this post intentionally leaves for the source:
- The customer story behind browser consolidation across Mac and Windows fleets, including the operational trade-offs.
- The browser and identity provider integration path used to streamline sign-in and policy enforcement.
- The details of how password-manager rollout and extension approval affected day-to-day administration.
- The AWS Security Hub integration for AI governance and how findings are surfaced for security teams.
👉 Read Island’s case study on enterprise browser control for Omada Health →
Enterprise browser control for healthcare data: what changes for IAM teams?
Explore further
02/08/2026 12:55 pm
Browser control is becoming an identity control surface, not a convenience layer. When the browser handles authentication handoff, extension policy, password management, and SaaS entry points, it sits inside the access path that IAM teams are already responsible for. That means browser governance can no longer be treated as endpoint hygiene alone. In regulated environments, browser policy is part of how trust is established and maintained across sessions. Practitioners should align browser governance with IAM operating models rather than leave it to ad hoc desktop management.
A question worth separating out:
Q: How do you know browser governance is actually working?
A: Look for fewer unauthorised extensions, consistent patching across approved browsers, broad password-manager coverage, and auditable identity provider handoff into SaaS applications. If users still bypass the approved browser or if exceptions are unmanaged, the control environment is fragmented. Effective governance shows up as standardisation and traceable policy enforcement, not just fewer tickets.
👉 Read our full editorial: Enterprise browser control reduces IT load and healthcare data risk
