Brinks Home
A home security company, breached by a phone call. The structured customer table was the small part — 3.8 million support chat logs were the rest.
What happened?
ShinyHunters listed Brinks Home, claiming 4.9 million Salesforce records: more than 1.1 million customer rows, over 4,000 employee rows, and 3.8 million support chat logs. Reporting places the entry point at a Microsoft Entra vishing call on July 13, 2026 — a voice phishing call in which an attacker persuaded a person to grant access.
The claimed exposure includes customer names, addresses, and support interaction logs, plus employee names, email addresses, and job titles. As with all leak site claims, the figures are the attacker's and have not been independently verified. The technique is consistent with a documented 2026 pattern; Microsoft published guidance in July on defending SaaS applications against this group's methods.
What data was actually inside?
Look at the composition rather than the headline number. 1.1 million customer rows. 4,000 employee rows. 3.8 million support chat logs. The structured customer database is roughly a fifth of the claimed total. The overwhelming bulk is conversation transcripts.
A customer row contains what a form asked for: name, address, account details. A support chat log contains whatever a customer said while troubleshooting an alarm system. Those are not the same category of data, and only one of them has a schema.
Who gets hurt and how?
Home security customers are, definitionally, people who have paid money to be harder to burglarize. The support transcripts undo part of that. Over years of troubleshooting conversations, customers describe their system configuration, which sensors are installed where, which ones are faulty, when the house is empty, when they travel, and — in some cases — access codes and how to bypass a malfunctioning door contact.
No field in a CRM is labeled "when this family is not home." The support log holds it anyway, in free text, because a customer explained their schedule to justify a service appointment. Combined with the customer address from the structured table, that is operational targeting information for a physical crime — a harm profile distinct from the identity theft that dominates most breaches.
The 4,000 employee records with names, emails, and job titles support follow-on social engineering against the same organization, using the same technique that worked on July 13.
What did they think they were doing right?
Brinks Home was running Microsoft Entra for identity management — a modern identity platform, which is the correct architectural choice. Presumably with conditional access policies, presumably with multi-factor authentication. Identity is where the industry has told everyone to invest, and Brinks invested there.
Vishing defeats it by not attacking it. A voice call to a help desk or an employee does not exploit the identity platform; it uses the human process wrapped around the identity platform — the reset procedure, the enrollment exception, the urgent request from a caller who sounds legitimate. The access that results is entirely valid. Every subsequent action is an authorized user doing authorized things, which is precisely what detection tooling is calibrated not to alert on.
What did they not know about their own data?
Brinks could produce a schema for its Salesforce customer object in minutes. Every field, every data type, every downstream integration — that is what structured data governance produces, and most organizations have it.
Nobody can produce a schema for 3.8 million unstructured conversations, which is exactly why they were still sitting in the tenant. Support transcripts accumulate by default. No retention policy expires them because nobody classified them as sensitive; they are operational records of service interactions. Their sensitivity is emergent — it comes from what customers happened to say, not from what the system was designed to collect.
That is the inventory gap in its purest form. The data an organization can describe is inventoried and governed. The data it cannot describe is retained forever and shows up in the breach notification.
If you use Salesforce, you probably have the same data types—emails, names, addresses, phone numbers. Do you know which fields contain PII?
What does attribution look like the morning after?
Structured records are straightforward to attribute: 1.1 million rows, each with a customer identifier, each mapping to a person and a state statute. That part is a database query.
The 3.8 million chat logs are not. Determining whether notification is required means determining what the transcripts contain, which means reading them — or running classification across them and accepting the error rate. A transcript in which a customer read out a card number triggers different obligations than one about a low battery warning, and there is no metadata field that distinguishes the two. This is where breach response budgets are actually consumed, and why unstructured data extends timelines by months.
Notification obligations run through every state where a customer resides, including California's 30-day requirement under SB 446 effective January 1, 2026; filings appear on the California AG breach list. There is also a duty-of-care question specific to this sector that no statute addresses: what do you tell a customer whose alarm configuration may now be public?
What would have changed the outcome?
Knowing what was in the support transcripts before an attacker did — because a retention policy you cannot justify is one you never wrote.
Vishing will keep working; the human process around identity is not a solvable problem in the way a vulnerability is. What is controllable is the size of the prize behind that access. Three point eight million transcripts were retained because no one had ever established what they contained, and the only way to expire data safely is to know what it holds. Your structured data is inventoried. Your free text is not — and in this incident the free text was four times larger and considerably more dangerous. Compare the Ernst & Young breach, another ShinyHunters operation through a platform the victim did not build.
Brinks Home found out the hard way.
Your team could spend the next 6 months rebuilding systems, notifying customers, and answering legal questions. Or you could spend 24 hours finding out what's actually at risk.