For a long time, data breach monitoring was built around a simple idea: find out whether someone’s email address, password, or personal information appeared in a leaked database. A company was hacked, a database was dumped, and security teams searched the exposed records for their users, employees, domains, or customers. The alert usually sounded something like this: “Your email appeared in a breach.”
That alert was useful. It still is. It tells people that some part of their digital identity has been exposed and may be used for phishing, fraud, credential stuffing, or account takeover. It gives security teams a reason to reset passwords, warn users, and check whether exposed credentials were reused across systems. Reports like the Verizon Data Breach Investigations Report continue to show that stolen credentials, phishing, and social engineering remain central to many real-world breaches.
But that model was built for an older version of the internet.
Today, some of the most dangerous breaches do not start with a stolen database. They start with an infected device. An employee, contractor, developer, executive, or vendor downloads something malicious, opens a compromised file, installs a fake app, or gets infected through a cracked software package. In the background, an infostealer collects whatever it can from the machine: browser cookies, saved passwords, autofill data, authentication tokens, cloud keys, session data, crypto wallets, files, screenshots, system details, and credentials stored inside applications.
The result is not just a leaked email address. It is a map of access.
That is the real shift. The old model says, “Your email appeared in a breach.” The new model says, “An employee device infected by an infostealer exposed a live browser session, SSO access, a GitHub token, and cloud credentials that could let an attacker move into these specific systems.”
Those two alerts describe very different levels of risk. The first alert tells you that data about a person was exposed. The second tells you that access into the business may already be in the hands of an attacker. One is a warning about information. The other is a warning about operational compromise.
This distinction matters because modern attackers often do not need to “hack” their way into a company in the traditional sense. They can log in. If they have the right session cookie, OAuth token, API key, cloud credential, or SSO access, they may be able to enter through legitimate services and look like a valid user. They may not need to bypass the firewall. They may not need to exploit a vulnerability. They may not even need the user’s password if the stolen session is still active. That is why Mandiant’s recent research on how attackers are harvesting session cookies, OAuth tokens, and cloud credentials is so important for understanding where the market is going.
Traditional breach monitoring was designed to identify exposed records. It was not designed to identify exposed access paths.
A password reset may be a reasonable response to an old breach record. It is not a sufficient response to an infostealer infection. If a device has exposed active browser sessions, OAuth tokens, developer credentials, or cloud keys, the response needs to be much broader. Security teams may need to revoke sessions, rotate tokens, review identity provider logs, check SaaS activity, audit cloud access, investigate source code repositories, inspect suspicious logins, and determine whether the infected device was managed or unmanaged.
Multi-factor authentication helps, but it does not eliminate the problem. MFA is very effective against many forms of password theft, but infostealers often target the material that exists after authentication has already happened. A browser session cookie can sometimes allow an attacker to access a service without entering a password or completing a new MFA challenge. OAuth tokens and API keys can create the same kind of risk. Developer tokens can be even more sensitive because they may grant direct access to code, infrastructure, customer data, CI/CD systems, or production environments.
This is why browser and identity-layer protections are becoming more important. Google’s work on browsers starting to bind sessions to devices is a good example of the industry recognizing that stolen session material has become a serious attack path. The goal is to make stolen session cookies less useful when they are removed from the original device. That kind of protection does not remove every risk from infostealers, but it shows where the defense model is heading.
In this new reality, the key question is no longer only “Was this person’s data leaked?” The better question is “What could an attacker do with what was stolen?”
That requires context. An exposed email address by itself tells you very little. An exposed corporate login from a personal device tells you more. An exposed SSO session belonging to a finance executive, cloud engineer, support admin, or DevOps contractor tells you much more. An exposed GitHub token tied to production repositories or an AWS key with meaningful permissions may be an urgent incident.
The value is not in knowing that an identity appeared somewhere in a leaked dataset. The value is in understanding whether that identity creates a path into the company.
This is also why the boundary of the organization has changed. In the past, companies focused heavily on protecting corporate networks and company-managed endpoints. That is still important, but modern business runs through SaaS tools, cloud platforms, contractors, remote workers, agencies, vendors, APIs, and personal devices. A company’s real attack surface now includes every identity and every token that can access its systems, even if the exposure happens outside the company’s direct control.
A contractor’s infected laptop can become a breach risk. A developer’s personal browser profile can become a supply-chain risk. A marketing agency account can become a SaaS compromise risk. A former employee with lingering access can become an open door. A vendor with access to shared systems can become the first step in an attack that eventually reaches customers.
This is the uncomfortable truth behind the rise of infostealers: companies can be exposed through devices they do not own, networks they do not manage, and identities they do not monitor closely enough.
That is why the industry needs to move from breach monitoring to identity exposure intelligence.
Breach monitoring asks whether an email, password, or record appeared in leaked data. Identity exposure intelligence asks whether a real person, account, session, or token can be used to access real systems today. It connects external exposure data with internal business context. It does not stop at “this user was found.” It asks who the user is, what they can access, whether the account is privileged, whether the exposed material is still valid, whether the device is managed, whether suspicious logins followed the infection, and which systems should be checked first.
A weak alert says, “user@company.com was found in stealer logs.”
A useful alert says that a device used by that person was infected on a specific date, that the log included access to the company’s SSO portal, GitHub, Slack, Google Workspace, and AWS, that browser cookies and saved credentials were present, that the user has admin access to several repositories, and that the recommended response is to revoke active sessions, rotate developer tokens, review cloud activity, and investigate recent logins from unusual infrastructure.
The difference is not formatting. It is the difference between noise and action.
Security teams already have too many alerts. Telling them that another email appeared in another dataset does not help unless the alert explains why it matters. The next generation of breach intelligence must prioritize exposures based on impact. A low-privilege personal account in an old breach is one kind of risk. A fresh infostealer log containing an active SSO session for a cloud administrator is another. Treating them the same wastes time and creates blind spots.
The same is true for remediation. The old workflow was often built around password resets. The new workflow must be built around access containment. Passwords may need to be changed, but sessions must also be revoked. Tokens must be rotated. OAuth grants must be reviewed. API keys must be invalidated. Cloud activity must be audited. SaaS logs must be checked. Privileged accounts must be examined. For teams thinking about the technical side of this problem, MITRE’s description of stealing web session cookies as a known attacker technique and OWASP’s guide to practical defenses against cookie theft are useful starting points.
This is especially important for developers and technical teams. A single infected developer machine can expose much more than a login. It can expose GitHub tokens, package registry credentials, cloud keys, SSH keys, CI/CD secrets, internal documentation, source code access, and admin portals. That kind of exposure can turn a device infection into a supply-chain incident. It can also give attackers the information they need to move quietly, escalate access, or prepare a larger attack.
The business impact is therefore much bigger than account takeover. Infostealer exposure can lead to source code theft, customer data exposure, cloud compromise, SaaS tenant abuse, ransomware preparation, data extortion, financial fraud, regulatory reporting obligations, and loss of customer trust. A single infected endpoint can become the beginning of a company-wide incident if the exposed identity has enough reach.
This is the reason the language of breach monitoring needs to change. The phrase “your email appeared in a breach” belongs to a world where the main unit of risk was a leaked record. The new unit of risk is exposed access. It is not only about what data was stolen from a company. It is about what access to the company was stolen from people and devices around it.
The companies that adapt will build security programs around identity, context, and remediation. They will look at external exposure not as a public relations issue or a compliance checkbox, but as an early warning system for real compromise. They will connect infostealer intelligence to identity providers, endpoint management, SaaS applications, cloud platforms, developer tools, and incident response workflows. They will ask not only whether something leaked, but whether that leak can be used to move inside the business.
The future of this market will not be won by the vendor with the largest collection of leaked emails. It will be won by the vendor that can explain what those exposures mean. Which identities are at risk? Which systems are reachable? Which tokens are still valid? Which users are privileged? Which third parties are involved? Which actions should the security team take first?
That is the difference between data and intelligence.
The old model helped people understand that their information had been exposed. The new model helps organizations understand that their access may be exposed right now.
That is where breach monitoring is going. It is becoming identity exposure intelligence. And for modern security teams, that shift is not optional. It is the difference between knowing that something leaked and knowing whether an attacker can use it to get in.
Previous post