How do malicious browser extensions undermine phishing-resistant auth?

How browser extensions break the trust model

Phishing-resistant authentication depends on the browser preserving signals that let the identity system tell a real browser flow from a replay or relay. A privileged extension can sit inside that trust boundary, observe requests, and modify headers or page behaviour before the authentication layer sees them. That makes the extension part of the authentication path, even if it is not part of the IdP itself.

Once an extension can tamper with request context, it can blur the distinction between a legitimate user action and a relayed or manipulated flow. In practice, that means the assurance comes not only from the authenticator, but also from the browser environment, extension policy, and what the extension is allowed to read or change.

That is why phishing resistance should be treated as an end-to-end property, not just a passkey or FIDO2 feature. If browser context is a trust input, then anything with permission to rewrite that context can weaken the control.

Which browser signals are most exposed

The most fragile signals are the ones the relying party uses to confirm origin and continuity. If an extension can alter the OpenID Connect Core 1.0 flow, a browser trust decision that depends on headers, redirects, or client-side state can be bypassed or confused. That is especially dangerous when the system expects the browser to act as a trustworthy enforcement point.

Extensions can also affect cookies, DOM content, form fields, and page scripting. For authentication, the practical question is not whether an extension can “steal a password”, but whether it can alter the conditions that the browser and identity stack use to decide that a request is genuine. If the answer is yes, the assurance boundary has moved.

For teams standardising on modern sign-in, NIST’s guidance on phishing-resistant authenticators is the right baseline, but it does not remove the need to control the browser layer. NIST SP 800-63 Digital Identity Guidelines treats authenticator assurance as part of the overall identity proofing and authentication model, which means the surrounding execution environment still matters.

Why extension permissions become an auth assurance problem

Extension permissions are effectively delegated capabilities. A benign-looking add-on may be able to read page content, inspect requests, or rewrite traffic in ways that are invisible to the user. That matters because the user may still see a passkey prompt or strong MFA ceremony while the browser context underneath has already been distorted.

This is the same reason browser compromise is so valuable to attackers: it gives them a place to interfere after the user has made a legitimate trust decision. In an authentication flow, that can mean turning a strong method into a weaker one by removing contextual checks, changing request metadata, or bridging the gap between a real origin and a malicious relay.

The control implication is straightforward, extensions with broad browser permissions should be treated like part of the authentication surface, not just productivity tooling. Workforce Identity Security Guide and the MFA Guide both reinforce the same operational reality, phishing-resistant methods still fail when the surrounding session and browser trust model is not controlled.

Risk and Threat Considerations

Malicious or overprivileged extensions create a high-value bypass path because they operate inside the user’s browser, where authentication decisions are often being made. The risk is not limited to credential theft. It includes trust signal manipulation, relay enablement, session abuse, and silent weakening of controls that assume the browser is honest.

Failure mechanism: An extension with sufficient permissions can rewrite request context, hide or replace origin indicators, or interfere with page logic so the identity system sees a manipulated flow rather than the real browser event.

Impact: Phishing-resistant authentication can be reduced to a weaker browser-mediated process, increasing the chance of successful relay, account compromise, or false confidence in strong-auth deployment.

Practitioner Guidance

What to verify: Confirm which extensions are allowed in managed browsers, what permissions they hold, and whether they can read or modify authentication-related pages, headers, or storage. If an extension can touch sign-in flows, treat it as a security-relevant dependency, not a convenience feature.

What good looks like: High-assurance sign-in flows are paired with tight extension allowlisting, browser hardening, and monitoring for unexpected extension drift. The goal is not “no extensions”, but no extension that can alter the signals your auth system trusts.

Decision rule: If the browser or extension layer can influence the authenticity of the request context, address that risk before declaring the authentication method phishing-resistant in practice. Passwordless and Passkeys Guide is useful here because passkeys raise the floor, but the browser still remains part of the assurance chain.

Practitioner takeaway: Strong authentication is only as strong as the browser environment allowed to present it, so extension policy must be governed with the same seriousness as credential policy.

Related resources from NHI Mgmt Group

• What are the signs that browser security controls are failing against AI-generated phishing and malicious extensions?
• Why do malicious browser extensions and phishing sites create such high fraud risk for financial firms?
• How can security teams detect malicious browser extensions in practice?
• Why do malicious extensions and browser-based malware create outsized risk for developers working with cloud and CI/CD systems?