Secure by design for enterprise browsers and identity controls

At a glance

What this is: This is Island’s explanation of how its enterprise browser aligns with CISA’s Secure by Design Pledge and extends identity controls into the browser layer.

Why it matters: It matters because IAM, PAM, and security architects need to understand when browser-enforced policy can complement existing identity controls across managed and unmanaged devices.

By the numbers:

• Island says its Enterprise Browser uses only about 40 percent of the Chromium source code.

👉 Read Island's post on how its enterprise browser aligns with CISA Secure by Design

Context

Secure by design pushes security into the development lifecycle rather than treating it as a post-release add-on. In identity terms, that matters because authentication, password policy, and session handling are often enforced too late, after users and devices have already reached the application.

This post uses the enterprise browser as the control plane for last-mile identity enforcement. The interesting question for IAM teams is not whether browsers can replace identity platforms, but where browser-enforced policy can reduce gaps in MFA, password hygiene, telemetry, and conditional access across managed and unmanaged devices.

Key questions

Q: How should security teams decide where to enforce MFA in browser-based access flows?

A: Teams should enforce MFA as close to the application entry point as possible, then verify that the same requirement holds for unmanaged devices, contractors, and legacy apps. If the browser is acting as the enforcement point, governance must define when it is authoritative and when native identity controls still take precedence.

Q: Why do browser-based identity controls matter for unmanaged devices?

A: Unmanaged devices often sit outside standard endpoint trust assumptions, so browser-enforced controls can restore a degree of policy consistency at the access boundary. That matters when the application cannot distinguish trusted from untrusted endpoints on its own and when security teams need the same access rule to follow the user everywhere.

Q: What do security teams get wrong about risk assessment in identity programmes?

A: They often treat assessment output as the goal rather than the start of remediation. If findings do not map to an owner, a control, and a closure condition, the programme produces visibility without reduction in exposure. Identity risk needs operational follow-through, especially when the issue involves certificates, delegated access, or privileged directories.

Q: Who should own browser-based identity risk in an enterprise?

A: Ownership should sit across IAM, security operations, and endpoint teams, because the risk spans authentication, session handling, and device posture. If browser-based attacks are only treated as endpoint issues, identity abuse will be missed. If they are only treated as IAM issues, device and browser context will be ignored. Shared ownership is the only workable model.

Technical breakdown

Browser-enforced MFA and application access

The browser can act as the policy enforcement point when the application itself does not provide strong authentication controls. In this model, MFA is attached to access to the app, to specific high-risk actions, and in some cases to physical access to idle machines. That makes the browser part of the authentication path rather than a passive rendering layer. The technical value is not that MFA exists, but that enforcement can follow the user flow instead of depending entirely on application-native support.

Practical implication: teams should map which applications rely on browser-side authentication enforcement versus native identity controls.

Password policy enforcement at the application layer

Application-layer password policy enforcement changes where credential rules are applied. Instead of relying only on directory policy or user training, the browser can block weak, reused, or expired passwords during the interaction itself. That is useful where legacy apps or third-party portals do not expose modern identity controls. The limitation is that policy only helps if it is consistently enforced across all entry points, including unmanaged devices and external access paths.

Practical implication: inventory legacy applications where browser-layer password controls compensate for missing identity features.

Zero trust telemetry and forensic-grade browser visibility

In a zero trust model, the browser becomes an observation point for user, device, network, application, and data signals. Island describes the browser as issuing the TLS handshake and producing detailed logs, anomaly signals, and session telemetry that remain useful even when the endpoint is compromised. That matters because forensic evidence at the browser layer can preserve visibility when endpoint trust is already broken, which is a common blind spot in modern work environments.

Practical implication: integrate browser telemetry into incident response workflows and treat it as evidence, not just user activity logging.

Threat narrative

Attacker objective: The attacker aims to gain durable access to business applications and session data while avoiding detection in the browser layer.

1. Entry occurs through weak browser or application authentication paths that allow users to reach sensitive workflows without consistent MFA or password hygiene.
2. Escalation follows when attackers exploit unmanaged devices, reused passwords, or credential remnants in memory and session state.
3. Impact emerges when compromised browser sessions expose keystrokes, tokens, or application actions that accelerate lateral abuse and hinder containment.

Breaches seen in the wild

• Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secure by design is becoming an identity governance issue, not just a software assurance issue. When a browser becomes the policy enforcement point for MFA, password rules, and telemetry, it is participating in identity control rather than merely consuming it. That shifts accountability for authentication outcomes across product, security, and IAM teams. Practitioners should treat browser policy as part of the control surface, not a cosmetic layer.

Browser-level identity enforcement fills a specific gap that many IAM programmes still leave open. Legacy and third-party applications often do not support modern controls cleanly, especially across unmanaged devices and mixed trust environments. A browser that can enforce MFA and application-layer password rules helps close the last mile, but it also creates a new dependency on the browser becoming policy consistent. The practitioner takeaway is to decide explicitly which controls live in the browser and which must remain in core IAM.

Forensics at the browser layer can materially improve incident response, but only if the telemetry is governed. Session logs, anomaly signals, and per-connection visibility are useful because they survive some endpoint compromise scenarios. That also means the browser is now an evidence source that must be protected, retained, and scoped like any other sensitive identity telemetry. Security teams should include browser-originated evidence in their logging and retention model.

Secure by design is pushing security controls closer to the user interaction boundary. That trend will continue because enterprises want fewer assumptions about device trust, app trust, and session trust. The governance question is no longer whether identity is controlled centrally, but how far enforcement should extend into the client layer without fragmenting responsibility. IAM and security architects need a clear model for browser, application, and directory control boundaries.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Another 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which shows how quickly identity control can disappear outside core IAM.
• For a broader control model, see Ultimate Guide to NHIs , Key Challenges and Risks for the visibility and privilege gaps that browser-enforced policy often has to compensate for.

What this signals

Browser policy will increasingly be judged by how well it reduces control fragmentation. For identity teams, that means measuring whether browser-enforced MFA, password rules, and telemetry reduce exceptions across unmanaged devices and legacy apps rather than merely adding another layer of control.

With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, governance now has to follow the execution environment as much as the identity itself. The browser is one of the places where that environment is actually enforced, observed, and audited.

Identity teams should expect secure-by-design language to move from software assurance into access governance. When that happens, the practical question is whether browser-originated signals can be operationalised in SIEM, PAM, and access review workflows without creating a separate policy island.

For practitioners

• Define where browser policy ends and IAM begins Map MFA, password, and conditional access responsibilities across browser, application, IdP, and endpoint controls so no team assumes another layer is enforcing the same rule. Use the map to identify overlapping or missing enforcement paths.
• Inventory applications that depend on browser-side enforcement Prioritise legacy, SaaS, and contractor access paths where the browser is compensating for missing native MFA or password policy support. Mark unmanaged-device scenarios separately because they are the most likely to bypass central assumptions.
• Treat browser telemetry as security evidence Route browser-generated logs and anomaly signals into SIEM and incident response playbooks with clear retention, access, and integrity controls. Browser telemetry is most useful when it is preserved as evidence rather than used only for troubleshooting.
• Validate secure by design claims against control outcomes Ask whether a browser control actually reduces credential exposure, improves MFA coverage, or increases evidence quality before accepting the architecture as secure by default. Measure outcomes, not design language.

Key takeaways

• Browser-enforced identity controls are becoming part of the access architecture, not just the user interface.
• The main governance question is whether MFA, password policy, and telemetry actually reduce risk across legacy and unmanaged access paths.
• Security teams should define the browser’s role in the identity stack before secure-by-design claims become operational ambiguity.

Key terms

• Policy Enforcement Point: A policy enforcement point is the control that applies an authorization decision at the place where an action occurs. In distributed systems, it may sit inside an API gateway, application, or workflow engine, and it depends on a consistent decision format to avoid bespoke integrations.
• Secure-by-Design: Secure-by-design means security requirements are built into the development process rather than added after release. The practical aim is to define minimum acceptable controls early, then enforce them consistently so products cannot ship without passing baseline security checks.
• Zero Trust: A security model that assumes no identity — human or non-human — should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.

What's in the full article

Island's full blog post covers the operational detail this post intentionally leaves for the source:

• How Island maps its browser controls to the seven Secure by Design goals across product lifecycle and deployment.
• Specific examples of MFA enforcement in application flows, idle-machine access, and unmanaged-device scenarios.
• The browser telemetry and logging detail behind its zero trust claims, including how evidence is captured and retained.
• The Chromium fork and patching model that Island says reduces attack surface and speeds remediation.

👉 Island's full blog post covers browser enforcement, zero trust telemetry, and patching detail.

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 building or maturing an IAM programme, it is worth exploring.