TL;DR: Browser consolidation can simplify patching and standardise the user experience, but it also shifts more control into a single runtime layer that now sits between employees, web apps, and legacy IE-dependent workflows, according to Island. For IAM and security teams, the governance question is not browser count, but how access, patching, and compatibility controls are enforced across the productivity surface.

NHIMG editorial — based on content published by Island: Updated: WWLW Ep. 11: The case of browser consolidation

Questions worth separating out

Q: How should security teams govern browser consolidation in enterprise environments?

A: Security teams should govern browser consolidation as a control-plane decision, not an IT convenience project.

Q: When does browser standardisation reduce risk versus create hidden dependency risk?

A: Browser standardisation reduces risk when it removes patch variability, simplifies support, and eliminates uncontrolled client drift.

Q: What breaks when legacy web apps still depend on Internet Explorer?

A: What breaks is the assumption that one browser policy can cover the whole workforce without exception.

Practitioner guidance

• Standardise browser governance ownership Assign a named owner for browser patch policy, legacy compatibility exceptions, and user access policy so the control surface does not fragment across IT and security teams.
• Inventory legacy IE-dependent applications Create a complete list of applications that still require Internet Explorer behaviour, then attach each exception to a business justification and expiry review.
• Measure patching and exception drift together Track automatic patch compliance, legacy mode usage, and the number of browser exceptions in the same reporting cycle so standardisation effects are visible.

What's in the full article

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

• How the enterprise browser handles automatic patching across a standardised workforce estate
• How the integrated IE Legacy mode supports older applications without requiring browser switching
• How the product fits into browser consolidation decisions for government and enterprise environments
• How the browser experience is positioned for public sector productivity and application compatibility

👉 Read Island's post on enterprise browser consolidation and legacy app support →

Browser consolidation for enterprise work: what changes for IAM teams?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Passwords remain the #1 attack vector for breaches, and the article argues that weak reuse, phishing, and stored credentials make user-managed authentication structurally unreliable, according to Unixi. The case for eliminating password dependence is less about convenience than removing a persistent identity abuse path.

NHIMG editorial — based on content published by Unixi: passwords and identity security in browser-based access

By the numbers:

• At Unixi, our weekly enterprise discoveries reveal weak or default passwords in 100% of organizations we assess.
• Traditional SSO helps, but as many as 50% of enterprise apps still don’t support SAML integration.
• Passkeys are supported by only 100–200 apps, while FIDO keys work with about 800.

Questions worth separating out

Q: How should IAM teams reduce password-related productivity loss?

A: They should start by measuring where password failures interrupt work most often, then redesign the highest-friction journeys first.

Q: Why do weak passwords keep causing breaches even when users are trained?

A: Training does not change the underlying constraint that people are asked to invent and remember complex secrets under cognitive load.

Q: What breaks when password policies are not enforced across legacy systems?

A: The control breaks where the organisation cannot apply rotation, logging, or recovery consistently.

Practitioner guidance

• Map password exception debt across the application estate Inventory every browser-based application that still relies on passwords, including legacy apps, external SaaS, and admin portals.
• Prioritise secret removal over password complexity rules Shift from forcing longer passwords to eliminating user-held credentials where practical.
• Review recovery and fallback paths as part of authentication design Test what happens when users lose devices, miss enrollment, or need break-glass access.

What's in the full article

Unixi's full article covers the operational detail this post intentionally leaves for the source:

• A vendor-specific breakdown of how Universal SSO and KDA handle browser-based authentication across legacy and SaaS applications.
• Implementation claims around password disappearance, phishing resistance, and application coverage gaps that are not unpacked here.
• The article’s comparison of passwordless approaches with traditional SSO, passkeys, and FIDO from the vendor’s perspective.
• Commercial and rollout context that practitioners would need before deciding whether the approach fits their environment.

👉 Read Unixi’s article on eliminating password risk in browser-based IAM →

Enterprise passwords and identity risk: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Application capability grants, tsnet, and Funnel can be combined to build a lightweight identity provider that authorises users from tailnet context and supports custom OAuth and OIDC flows, according to Tailscale. The governance question is not whether this works, but which identity and access assumptions break when application identity is embedded into the network layer.

NHIMG editorial — based on content published by Tailscale: Building on Tailscale: How we made a tiny identity provider

Questions worth separating out

Q: How should security teams govern application-level identity decisions that depend on network context?

A: Security teams should treat network context as part of the authorisation workflow, not as a separate infrastructure concern.

Q: What breaks when dynamic client registration is exposed to too many users or groups?

A: Control over OAuth client creation becomes fragmented, and applications can accumulate unreviewed access paths that are difficult to trace back to accountable owners.

Q: Why do network-aware identity patterns complicate IAM governance?

A: Because the access decision is no longer made only in a central identity provider.

Practitioner guidance

• Map identity decisions to runtime boundaries Inventory every place where application behaviour depends on request identity, capability grants, or network membership.
• Govern dynamic client registration explicitly If applications can register OAuth clients dynamically, define who may do so, what approval is required, and how those registrations are reviewed and revoked.
• Review custom claims before they reach tokens Document every extraClaims field that can alter OAuth or OIDC tokens, then validate whether each claim is necessary, accurate, and aligned with token-minimisation rules.

What's in the full article

Tailscale's full post covers the implementation detail this analysis intentionally leaves for the source:

• The tsnet setup pattern for embedding Tailscale connectivity directly into a Go application
• The .WhoIs call flow that returns user, node, and application capability grant context
• The ACL grant JSON structure that drives admin UI access, dynamic client registration, and custom claims
• The Funnel pattern for exposing public endpoints while keeping /authorize private

👉 Read Tailscale’s build guide for tsnet, grants, and Funnel-based identity flows →

Tailscale-aware identity providers: what changes for IAM teams?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Weak authentication, stolen credentials, and lateral movement remain the main failure points in perimeter-era security, according to Yoti. Zero Trust shifts the control point to verified identity, but the governance challenge is whether organisations can prove who is accessing systems before trust is extended.

NHIMG editorial — based on content published by Yoti: Zero Trust identity controls and verified authentication

Questions worth separating out

Q: How should security teams implement Zero Trust for non-human identities?

A: Start by inventorying every machine identity, assigning an owner, and mapping its access to a specific business function.

Q: Why do valid credentials still create so much risk in zero trust environments?

A: Because a credential can be valid and still be unsafe if it has more privilege than the current task requires.

Q: What do security teams get wrong about passwordless authentication?

A: The most common mistake is treating passwordless as a user-experience upgrade instead of an identity control change.

Practitioner guidance

• Map high-risk access paths to identity-first controls Identify applications, admin consoles, and customer journeys where network trust still substitutes for strong identity verification.
• Prioritise passwordless rollout where phishing risk is highest Start with privileged users, remote workers, and customer flows that are repeatedly targeted through credential theft.
• Treat biometric checks as an impersonation control Use liveness detection and secure capture to reduce replay, screenshot, and deepfake abuse.

What's in the full article

Yoti's full article covers the operational detail this post intentionally leaves for the source:

• How the digital ID flow supports reusable authentication across employee and customer journeys
• How biometric checks and liveness detection are positioned to reduce impersonation risk
• How passwordless login is described as a practical alternative to password-based access
• How the platform fits into SaaS integrations and SDK-based deployment patterns

👉 Read Yoti's analysis of Zero Trust identity controls and verified authentication →

Zero trust identity controls: what it means for IAM teams?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: High-value targeting pushes pentesting to focus on the systems and accounts attackers value most, using business context to prioritise domain controllers, privileged users, and critical servers, according to Horizons.ai. That framing matters because identity and attack-path significance, not raw vulnerability count, now determines blast radius and response urgency.

NHIMG editorial — based on content published by Horizons.ai: Introducing NodeZero High-Value Targeting, Think Like an Attacker, Prioritize What Matters

By the numbers:

• 17 minutes and as quickly as 9 minutes, cly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

Questions worth separating out

Q: How should security teams prioritise identities and systems that matter most to attackers?

A: They should rank identities and systems by blast radius, not just exposure count.

Q: Why do attackers focus on a small number of high-value identities and systems?

A: Because those assets turn limited access into broad control.

Q: What do security teams get wrong about vulnerability prioritisation?

A: Security teams often treat vulnerability scores as if they represent operational risk on their own.

Practitioner guidance

• Define identity blast radius tiers Classify accounts, services, and systems by the consequence of compromise, not by technical label alone.
• Feed business context into attack-path prioritisation Add department, environment, and service ownership context to vulnerability and exposure data so prioritisation reflects operational impact.
• Re-score privileged identities after each new discovery Update attack-path analysis whenever new credentials, trust relationships, or reachable services appear.

What's in the full article

Horizons.ai's full blog covers the operational detail this post intentionally leaves for the source:

• The full attack-path workflow showing how the prioritisation engine re-ranks targets as new systems and credentials appear.
• Examples of hostname, service, and directory signals used to classify high-value systems in practice.
• The author’s own explanation of AWS Bedrock usage, model handling, and runtime isolation choices.
• Expanded examples of how business-risk labels are mapped to specific asset and identity classes.

👉 Read Horizons.ai's blog on high-value targeting for attacker-style prioritisation →

High-value targeting in pentesting: what IAM teams should notice?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Remote Browser Isolation protects only a narrow slice of web traffic, typically 1% to 2%, while leaving collaboration, file sharing, SaaS, and other common paths outside its coverage, according to Island. The security problem is not just browser exploits but the mismatch between enterprise use cases and a control that was designed for suspicious content, not everyday work.

NHIMG editorial — based on content published by Island: Rethinking Remote Browser Isolation

Questions worth separating out

Q: When does Remote Browser Isolation fail to protect enterprise users?

A: Remote Browser Isolation fails when organisations rely on it for traffic that never enters the isolated path.

Q: Why do browser security decisions matter for IAM teams?

A: Because the browser is where users enter credentials, approve OAuth grants, and reuse sessions, so it has become an identity control surface.

Q: What do security teams get wrong about browser isolation?

A: Teams often assume isolation solves the whole risk problem, when it actually only changes where the browser executes.

Practitioner guidance

• Measure actual RBI coverage against real browser traffic Compare isolated traffic to total web usage across SaaS, collaboration, file sharing, and contractor workflows so you know what percentage of sessions the control never touches.
• Classify browser use cases by identity risk Separate privileged user browsing, BYOD access, third-party access, and internal application use before deciding where RBI belongs and where native browser policy controls are needed.
• Treat browser isolation as one layer in the control stack Use RBI only where quarantined rendering is appropriate, and pair it with identity-aware policy enforcement, posture assessment, and session controls for everyday enterprise access.

What's in the full article

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

• A side-by-side feature comparison between enterprise browsers and Remote Browser Isolation for everyday work patterns
• Specific browser security capabilities such as arbitrary code guard, control flow enforcement, and extension control
• The full use-case list for SaaS, BYOD, contractor, and privileged-user browsing scenarios
• Implementation detail on how the vendor detects and blocks malicious JavaScript across browser APIs

👉 Read Island's analysis of why Remote Browser Isolation falls short for enterprise browsing →

Remote browser isolation: what the enterprise browser gap means?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Identity has become the primary security perimeter, and Torq’s guide argues that IAM maturity now depends on extending governance from humans to service accounts, API keys, and cloud credentials, with 88.5% of organisations saying non-human IAM lags human IAM in Aembit’s 2024 report. The structural problem is that access review cycles, standing privilege assumptions, and fragmented tooling were built for slower human-paced identities, not high-volume machine identities.

NHIMG editorial — based on content published by torq: IAM best practices and the three-phase identity maturity model

Questions worth separating out

Q: How should security teams govern non-human identities in cloud environments?

A: Start with complete discovery, because you cannot govern what you cannot see.

Q: What problem does ownership attribution solve for service accounts and API keys?

A: It closes the gap between exposure detection and accountable remediation.

Q: What breaks when non-human identities are not monitored and reviewed?

A: Detection, accountability, and incident response all weaken at the same time.

Practitioner guidance

• Inventory all non-human identities across cloud and SaaS Build a complete inventory of service accounts, API keys, tokens, certificates, and automation credentials, then assign each one an accountable owner and a business purpose.
• Eliminate standing privilege for machine credentials Replace persistent elevated access with task-scoped access where possible, and require automatic expiry for temporary credentials.
• Move secrets out of code and shared channels Force all credentials into a managed secrets vault and prohibit storage in source files, chat, email, or shared drives.

What's in the full article

Torq's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step IAM maturity sequencing across foundational, dynamic, and governance phases
• Specific examples of IAM controls for MFA, SSO, JIT access, and access certification
• Operational guidance on automating certificate and attestation workflows across environments
• Case-management detail for identity alerts and compliance reporting in a SOC workflow

👉 Read Torq's guide to IAM best practices and non-human identity governance →

Non-human identity governance in IAM: where the maturity gap shows?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Large browser platforms need purpose-built test orchestration and observability, not just more tests, according to Island. It describes how it built a custom end-to-end testing service to manage browser-scale CI/CD across six platforms, roughly 300 machines, and hundreds of tests per release, reducing flaky-test disruption and improving developer throughput.

NHIMG editorial — based on content published by Island: Engineering Reliability at Scale, a deep dive into its custom automated E2E testing service

By the numbers:

• We maintain approximately 300 physical and virtual machines, requiring proactive and efficient management to quickly address problems and minimize disruptions.

Questions worth separating out

Q: How should teams reduce flaky tests in large browser CI environments?

A: Start by separating test logic from test state.

Q: Why do shared test users create reliability problems in automation pipelines?

A: Shared test users create collisions in state, permissions, and rate limits.

Q: What do security and platform teams get wrong about CI observability?

A: They often stop at pass or fail metrics.

Practitioner guidance

• Separate test identity lifecycle from test logic Assign unique users or credentials to each parallel test context, then refresh or retire them on a defined schedule so shared state does not pollute results.
• Add a coordination layer for dynamic test allocation Use a central service to track suites, cases, agent availability, and rerun state so failed jobs can move without losing context.
• Treat flaky tests as governance signals Classify recurring failures by root cause, branch, or machine history instead of only suppressing them, then route the pattern to the right owner.

What's in the full article

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

• The test-suite and test-case model used to distribute work across agents in real time
• The Ignore Rules workflow for suppressing flaky tests without blocking the entire CI pipeline
• The user-management pattern that assigns unique test users per machine and refreshes them daily
• The Grafana dashboards and alerting logic used to surface node history and test flakiness patterns

👉 Read Island's full post on engineering reliability at scale with automated E2E testing →

Enterprise browser test automation: what it means for CI reliability?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Sensitive cookies can persist in browser memory after use and remain exposed to physical memory dump tools, even when plaintext handling is wrapped in safer abstractions, according to Island. The practical lesson is that browser-side secret handling needs memory hygiene, not just disk encryption and deallocation discipline.

NHIMG editorial — based on content published by Island: How Island Protects Sensitive Data In Browser Memory Engineering

Questions worth separating out

Q: How should security teams reduce the risk of browser session token theft?

A: Security teams should tighten token scope, shorten session lifetime where the business can tolerate it, and build fast revocation into identity operations.

Q: Why do browser-based secrets create more risk than simple disk storage controls suggest?

A: Because many identity values are used in memory before they are discarded, and that use phase can leave recoverable plaintext behind.

Q: What breaks when sensitive strings are not fully cleared from memory?

A: Residual plaintext can remain available to memory acquisition tools, which turns a normal session object into a reusable credential source.

Practitioner guidance

• Map sensitive browser data flows Identify where cookies, tokens, and other secrets are decrypted, copied, serialized, and freed inside browser and desktop clients.
• Zeroise freed secret material Require deallocation paths for sensitive strings to overwrite memory before release, not merely drop references.
• Add memory-dump regression testing Use automated tests that emulate physical-memory inspection against known secret patterns so leaked plaintext is caught before release.

What's in the full article

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

• Step-by-step analysis of Winpmem’s PTE remapping approach and why it enabled memory acquisition.
• Code-level examples of the deallocation hooks used to detect plaintext cookies before release.
• The automated validation framework used to repeat secret-leak tests during development.
• Implementation details of the browser-side memory scanner and test harness used in CI.

👉 Read Island’s analysis of browser memory leakage and secret exposure →

Browser memory leakage: are your controls keeping up with dump tools?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Passwords still fail through brute force, reuse, phishing, malware, session hijacking, and weak MFA, even when enterprises use a password manager, according to Island. The core issue is that password hygiene alone does not control the browser, device, and session-layer attack paths that attackers actually exploit.

NHIMG editorial — based on content published by Island: Enterprise password management: Avoiding common attacks

By the numbers:

• Have I Been Pwned tracks over 850 websites and some 14.2 billion accounts that have been compromised.

Questions worth separating out

Q: How should security teams reduce password reset risk in large enterprises?

A: Security teams should make password recovery a governed identity workflow, not a help desk exception.

Q: Why do enterprise password managers still leave security gaps?

A: Because many tools secure the vault but not the behaviour around the credential.

Q: What breaks when users reuse passwords across multiple services?

A: One exposed credential can become many compromised accounts.

Practitioner guidance

• Harden authentication beyond password policy Replace SMS-based MFA with phishing-resistant methods such as FIDO2 or WebAuthn for users and applications that justify stronger assurance.
• Reduce credential reuse across services Enforce unique passwords for all applications, including legacy and third-party systems that sit outside the identity provider's native scope.
• Treat browser state as an identity control point Protect cookies, cache, and local password storage with browser and device controls that limit session hijack and token theft.

What's in the full article

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

• Side-by-side attack mapping for password complexity, reuse, phishing, MitM, MitB, and session hijack scenarios.
• Browser and device protection recommendations for cookie handling, keystroke capture, and local password storage.
• Practical guidance on stronger MFA choices, including when WebAuthn and FIDO2 reduce replay risk better than SMS codes.
• Specific enterprise browser controls that help limit web-based and physically local attacks.

👉 Read Island's analysis of enterprise password management attacks →

Password manager controls: where enterprise teams still get exposed?

Explore further

View Full Forum →  |  NHI Foundation Course →