Almost everything your business runs on now lives behind a browser tab. Email, file storage, accounting, CRM, payroll, and increasingly AI tools are all reached the same way, through Chrome or Edge or Safari on a laptop that may or may not be company-owned. The 2026 Verizon Data Breach Investigations Report, drawing on more than 22,000 confirmed breaches across 145 countries, shows attackers have followed that shift. The controls most businesses spent the last decade buying, email filtering and endpoint antivirus, largely cannot see what happens inside a browser session.
The reassuring part is that most of what makes browsers risky is configuration rather than some novel unstoppable technique. Browsers are usually installed by whoever set up the laptop, configured by the employee, and never looked at again. Bringing them under the same management as the rest of the environment is neither expensive nor slow, and it closes most of the gap.
The one thing to take away: resetting a password does not end an attacker’s session. If credentials are stolen, active sessions and tokens have to be revoked separately, or the intruder stays logged in through the reset.
Key Takeaways
- Stolen credentials remain the main way in. Even when attackers break in through an unpatched system, they pivot to stolen logins almost immediately. Credential abuse shows up in 39% of all breaches at some stage.
- There is usually a warning window before ransomware. Half of ransomware victims had a credential theft event in the 95 days beforehand, which is a real chance to intervene if anyone is watching for it.
- Multi-factor authentication alone no longer stops session theft. Modern phishing kits capture the logged-in session rather than the password, which sidesteps the MFA prompt entirely.
- Unsanctioned AI use is quietly moving data out. Two-thirds of users reach AI tools through personal accounts on company devices, putting company information somewhere with no retention policy and no audit trail.
- Browser extensions are unmanaged software with deep access. Many can read every page an employee opens, including internal systems, and send what they see to an outside server.
What the Latest Breach Data Shows About Browser Risk
The headline finding this year was the jump in vulnerability exploitation as an initial access method, but that reading undersells how central identity still is. Roughly 32% of initial access comes through identity-related routes, and credential abuse appears somewhere in 39% of breaches overall. That second number is the one that matters for planning, because it means a break-in that starts somewhere else still tends to run on stolen logins once it is inside.
| By the numbers (2026 DBIR) | Figure |
|---|---|
| Confirmed breaches analyzed | 22,000+ across 145 countries |
| Breaches involving credential abuse at some stage | 39% |
| Initial access through identity-related vectors | ~32% (phishing 16%, credential abuse 13%, pretexting 6%) |
| Initial access through vulnerability exploitation | 31%, up from 20% |
| Ransomware victims with a credential theft event in the prior 95 days | 50% |
| Users reaching AI tools via non-corporate accounts on company devices | 67% |
| Regular AI users on corporate devices | 45%, up from 15% |
| Social engineering incidents originating outside email | 41% |
| Breaches involving a third party | 48%, up from 30% |
For a business owner, the practical translation is short: password hygiene, phishing-resistant sign-in, and some way of knowing when company credentials turn up in a leak are not extras. They defend against the most common pattern in the data. Attackers are not breaking down the front door so much as picking up keys that were dropped somewhere else.
The 95-Day Warning Window
The most useful finding in this year’s report is a timeline. Half of ransomware victims experienced a credential theft or infostealer event within 95 days before the ransomware hit. That gap is not luck. It reflects a supply chain that has been refined into a reliable business.
The chain runs like this. An employee picks up infostealer malware, often from a malicious ad or a compromised site. The malware harvests saved passwords, browser cookies, and session tokens from the device. That haul is packaged into stealer logs and sold on. Brokers test the credentials, work out which ones open a business network worth attacking, and resell that access to ransomware crews, who then move laterally, take copies of the data, and encrypt what is left.
The gap between the first and last step is the opportunity. Catching a credential compromise inside that window, then revoking the stolen sessions and resetting what was exposed, breaks the chain before the extortion stage. That requires two things most small businesses do not currently have: monitoring for company email addresses and passwords surfacing in leaks, and a response process that starts within hours of a device being found compromised rather than days.
Shadow AI Is Moving Data Into Accounts Nobody Controls
AI adoption has created the widest new gap. Two-thirds of users are reaching AI services through personal accounts on company devices. Unsanctioned AI use is now the third most common non-malicious insider action in data loss prevention datasets, up fourfold year over year.
None of this is malicious. Employees are trying to finish work faster, and the tools genuinely help. The problem is what happens to the input. Proprietary code, customer records, pricing, and draft strategy documents pasted into a personal AI account sit outside any company agreement, with no visibility into retention and no way to pull them back.
Extensions widen the same gap. More than 15% of users have unauthorized AI browser extensions installed, and those extensions can quietly collect context from internal systems as employees work. They typically ask for permission to read and change page content, reach the clipboard, and talk to outside servers. Granted once and forgotten, that is a data channel with no logging on the business side of it.
The Browser Attacks Employees Have Never Been Trained to Spot
Social engineering has moved out of the inbox. 41% of incidents now start somewhere other than email, and voice-based phishing succeeds at a rate 40% higher than email campaigns. Meanwhile, most security awareness training still teaches one skill: spotting a suspicious message. That leaves employees well prepared for the 2019 version of this problem and unprepared for what actually lands in front of them now.
| Attack | What the employee sees | What it costs the business |
|---|---|---|
| ClickFix / fake CAPTCHA | A verification box or browser error telling them to paste a command and press Enter | Malware installed, saved passwords and session tokens harvested |
| Adversary-in-the-middle phishing | A normal login page, and an MFA prompt that works exactly as expected | The live session is stolen, MFA bypassed, access continues after a password reset |
| Malicious or over-permissioned extension | A useful free tool with good reviews | Page content from internal systems, clipboard data, and keystrokes sent outside |
| OAuth consent abuse | A routine “allow this app access” prompt | Standing access to mail, files, and calendar that needs no password and survives resets |
ClickFix and Fake CAPTCHA Prompts
ClickFix campaigns pair a fake CAPTCHA or error message with an instruction to run a command. An employee lands on a site, a prompt appears, and it tells them to press Windows Key + R, paste what is already on their clipboard, and hit Enter to prove they are human or to fix a browser problem. What they are actually doing is running the attacker’s code with their own permissions.
This one is cheap to defend against because the tell is absolute. No legitimate verification check has ever asked anyone to open a command window. Adding a single line to security training covers it: if a webpage asks you to run code to prove you are human, stop and report it. Employees also need to know that reporting it carries no blame, since the ones who realize halfway through are exactly the ones who go quiet.
Session Hijacking, and Why MFA Alone Does Not Stop It
Adversary-in-the-middle phishing skips the password entirely as a target. The phishing page sits between the employee and the real service, passing everything through in real time. The employee types their credentials, completes the MFA prompt, and reaches the service they expected. In the process, the attacker captures the session token, the artifact that proves someone already authenticated successfully. From then on the attacker is inside as that user, and the MFA prompt has already been satisfied.
Two things close this. Phishing-resistant sign-in, meaning security keys or passkeys rather than codes and push approvals, removes the relay attack’s leverage. Access policies tied to managed devices stop a stolen token from working on an unknown machine. Both are within reach for a business of any size, and passkey rollouts are a matter of weeks rather than years.
What to Do About It
Browsers need to be managed the way any other business system is managed: settings pushed centrally, changes monitored, and access decisions tied to identity. That does not have to start as a project.
Quick wins worth doing this month
- Enforce automatic browser updates centrally so patches land without anyone deciding to click Update Later.
- Block new extension installs by default, then audit what is already installed across every company device. The audit alone is usually the eye-opener.
- Turn off the browser’s built-in password saving and move those credentials into a managed password manager.
- Have the company domain checked against known credential leaks, and repeat it on a schedule.
- Add the ClickFix rule and one line about AI tools to security training. Two sentences, no new spend.
The longer program
Beyond the quick wins, the work is a sequence rather than a single deployment. Piloting each stage with a small group before a full rollout keeps productivity complaints manageable.
| Phase | What happens | Rough timeline |
|---|---|---|
| 1. Baseline audit | Inventory browsers and versions, catalog extensions and their permissions, identify unsanctioned AI and cloud use, list which business systems run in the browser | 1 to 2 weeks |
| 2. Lock the configuration | Device management pushes a standard set of browser settings, including safe browsing protections and removal of local admin rights that let users override them | 2 to 4 weeks |
| 3. Extension control | Default-deny with a documented approval path, permissions reviewed before approval, installed extensions re-audited on a schedule | 2 to 4 weeks, then ongoing |
| 4. Phishing-resistant sign-in | Security keys or passkeys piloted and rolled out, access policies restrict business systems to managed devices | Within a quarter |
| 5. Monitoring and response | Alerting on session anomalies, unusual downloads, and new app consent grants, plus a written response playbook | Ongoing |
Extension and app permissions
Extension reviews come down to four questions: what data can it read, which sites can it touch, can it see network traffic, and where does it send what it collects. Anything asking to read and change all data on all websites deserves a hard look and a named business reason.
App consent grants deserve the same scrutiny and rarely get it. When a user approves a third-party app’s access to company mail, files, or calendar, that permission persists until someone revokes it. Most businesses have never looked at the list, which means access granted to a tool nobody uses anymore is probably still live. Reviewing it once and then quarterly is a short exercise with a high return.
If a session may have been stolen
Speed determines whether one compromised laptop becomes a breach, so this belongs in writing before it is needed rather than improvised at 6pm on a Friday. The order matters:
- Revoke every active session for the affected account first, and invalidate refresh tokens so sessions cannot renew themselves.
- Reset the credentials after the sessions are gone, not before.
- Review what changed on the account: new authenticator registrations, new app consent grants, and mailbox forwarding rules, which are the three things attackers set up to get back in later.
- Scan the device for infostealers and assume anything saved in that browser is now public.
- Check whether the same credentials were reused anywhere else.
Vendors and contractors
48% of breaches now involve a third party, up from 30%. Remediation on the vendor side is slow: only 23% of third-party organizations fully fixed missing or misconfigured MFA on cloud accounts, and weak password and permission problems took a median of eight months to reach even 50% resolution. Waiting for vendors to tidy up on their own is not a strategy.
Practical requirements are short. Vendors accessing company systems use named accounts rather than shared logins, with MFA required. Access is reviewed on a schedule and removed when the engagement ends. Notification expectations for a security incident on their side are written into the agreement. For contractors and personal devices, isolating business access from the personal environment keeps one unmanaged laptop from becoming a route in.
Where This Leaves You
The pattern across all of this year’s findings is consistent. Attackers are going after the session, the identity, and the browser rather than the perimeter, because that is where the work now happens. The defenses that answer it are not exotic: managed browser settings, controlled extensions, sign-in that cannot be relayed, and a response process that revokes access as fast as it was taken.
