Flare's triage example is the part of the guide worth keeping. Two alerts arrive the same morning: one is a six-month-old log holding an employee's old password for a consumer website, the other was collected yesterday and carries corporate identity credentials plus an authenticated browser session for the organization's identity provider [9]. Standard tooling files both under employee credential exposure, and Flare's argument is that they are not the same event [9].
A reset revokes the password and nothing else in the log. Flare's asset priority follows from that, weighting corporate domains and subdomains, enterprise identity providers, session cookies, VPN and RDP endpoints and cloud consoles, with SSO identities at Microsoft Entra ID, Okta or Google Cloud Identity singled out for attention [10].
In the case Flare opens with, Vidar landed on an employee's personal computer hundreds of miles from the company's offices, and the log still held a corporate SaaS username and password, browser cookies for live sessions, and further credentials saved in files [6]. None of that sits on hardware the employer can query. The complement of the 46 percent is where ordinary incident response still applies: 54 percent of corporate-credential logs come from devices Flare does not flag as likely unmanaged or personal [12]. On the other half, a single infection that can yield hundreds or thousands of records [8] has to be assessed from the outside, using the log itself as the only forensic artifact.
The growth estimate sets a clock. At 29 percent a year, exposure of SaaS credentials and sessions doubles in about 2.7 years, since ln(2) divided by ln(1.29) is 2.72 [11]. Resale sets a shorter one: by the time the analyst opens the ticket, Flare says the same record may already be with an initial access broker, ransomware affiliate or opportunistic attacker [14].
Every figure here is Flare's, and the write-up gives no sample size and no collection methodology for the 46, 29 or 90 percent [15]. Read them as descriptions of what one commercial collector sees. The Telegram share is the most self-referential of the three, because a monitoring vendor's channel coverage decides what it can count. The response logic survives that caveat, since it needs only two fields from the log: the collection date, and whether a cookie is in it.
