Bromcom confirmed a breach of its legacy sign-on service: email addresses only, each tagged with the sign-in provider used. I run AliasFleet, an email-alias service: one address per site, so a leak names its source. It is a phishing kit, and it is aimed at the one credential you cannot rotate.
What Bromcom confirmed
The first public sign came on 24 September, in a post on the EduGeek forum by an account called Bromcom_Alastair: an unauthorised third party had accessed and retrieved email addresses and limited information tied to SSO registrations. The Register reported the customer notification on 6 October; Bromcom's own FAQ was updated 30 September.
The honest split:
| Confirmed | Still unconfirmed |
|---|---|
| The disclosure: Bromcom notified customers; its own FAQ was updated 30 September | The full nature and scope; the forensic investigation is still running |
| The component: legacy SSO registration functionality in the Communication Server environment, identified 6 September after reports of SSO access problems; the legacy functionality has been withdrawn from production | How the intruder got in; no attack vector has been named |
| The data: email addresses tied to SSO registrations, the provider used (Microsoft or Google), registration and last sign-in dates where held, internal user and registration reference numbers | How many records, schools or individuals were affected; no count has been disclosed |
| No passwords or authentication tokens were held by the component, so none were taken | Whether the retrieved data has been copied, sold or misused |
| No evidence the school MIS database was accessed | Whether a root cause analysis will be published |
A Bromcom spokesperson said:
"We recently identified, contained and began investigating an IT incident. Our investigation is ongoing to determine the nature and scope of any data involved, and we have already taken steps to resolve any disruption. We are liaising with the relevant schools and trusts, as well as the appropriate authorities."
SC Media also picked up the story, citing The Register's reporting.
The email list is the attack
Picture the email this leak enables. It arrives addressed to a teacher by name. It mentions Bromcom and SSO. It warns of a sign-in problem and asks the reader to re-authenticate through their usual Microsoft or Google flow. The teacher really does sign in to Bromcom through Microsoft or Google. The branding is right. The context is right. Only the link is wrong.
For school staff, the work email is the identity anchor: payroll portals, suppliers, personal accounts signed up years ago, recovery addresses on other services. One security write-up of Bromcom's earlier FAQ noted that some pupil registrations used personal email addresses. That detail comes second-hand, from a security firm summarising the older FAQ, so treat it as reported rather than confirmed. But if it holds, the blast radius follows a child into their personal inbox, where school IT warnings never reach.
Bromcom knows exactly what it has enabled. Its FAQ warns everyone to stay alert for suspicious messages, calls or emails, and it names the exact lures: click a link, hand over credentials, approve a sign-in request, reset a password. That is not boilerplate. That is a company describing the attack its own breach just made cheaper.
Assume the lure is coming. Until this investigation closes, verify any message about Bromcom or SSO through a channel you already trust: your school's official site, a number you already have. The attacker's version will look exactly like the real warning, because it is built from real details.
Bromcom has not notified the UK data regulator, because it processed the data as a data processor. The schools and trusts are the data controllers, and they get to decide whether to notify the ICO or affected individuals. So your leaked email may reach you via the school, via Bromcom, or via nobody at all. If your school runs Bromcom, do not wait for a letter that might never come.
A dead service kept alive by one caller
The detail that explains this breach is painfully ordinary. The legacy SSO registration functionality had been superseded. It stayed in production anyway, because, in Bromcom's own words, it was still being called by an internal system. The replacement shipped. The old endpoint never got switched off. What the intruder did with it from there is a matter for the forensic team, and Bromcom is not saying. I will not fill in the gap.
This is the oldest failure pattern in enterprise software. A service is retired on paper while one forgotten dependency keeps it reachable, still holding real identity data, reviewed by nobody because it is officially dead. Every IT team reading this has an endpoint like it somewhere. Decommissioning means checking what still calls the thing, not just shipping the replacement.
The one field you can take back
You cannot change your work email the way you rotate a password. It is on business cards, baked into recovery flows, known by every service you ever signed up for. That permanence is exactly why it should not be the address you hand to every service in the first place.
The mechanism is a dedicated email alias per account: one forwarding address for the school system, reaching your real inbox. When a breach notice names the school software vendor, the alias tells you instantly which address the attackers hold. A phishing email quoting Bromcom, landing on an address only the school system ever had, has identified its own source. Kill the alias and the whole channel dies while the inbox you actually read stays clean. That is the leak-tracing mechanism aimed at precisely this attack, and the set-up guide takes about two minutes.
One boundary, so the pitch does not overclaim. An alias would not have prevented this breach, and it does not stop a well-written forgery from landing in your inbox. What it does is narrower and more useful: it turns the leaked address into something you can switch off, so the blast radius ends at the alias instead of following your real address into every account tied to it.
What affected staff and pupils should do now
Nobody likes learning their inbox is now a target. Here is the short list.
- Expect a tailored lure, not generic spam. Any message about Bromcom, SSO or a sign-in problem that asks you to click a link is hostile until proven otherwise. Type the address yourself and go there directly.
- Never approve a sign-in request you did not start. Push MFA fatigue is exactly what this dataset enables: the attacker knows your email, knows you use Microsoft or Google, and only needs one tap.
- Do not hand over credentials or reset passwords from any link in an email about this incident. If your school's IT team reaches out, verify through a channel you trust, not the one that contacted you.
- Warn older pupils. If personal email addresses were in the file, phishing can land in a personal inbox that school IT warnings never reach. A two-minute conversation beats a compromised account.
- Check Have I Been Pwned once the incident is listed, and switch on its breach notifications so the next one finds you first.
- Walk the breach-response order of operations: it is written for exactly this situation.
What to watch in the Bromcom investigation
The next number to watch is a count: records, schools, individuals. The FAQ currently answers that question only with "investigation ongoing". A number would turn this from an incident into a measurable event. Then whether the dataset surfaces anywhere public, which would confirm the phishing risk is live rather than theoretical. And finally whether Bromcom publishes a root cause analysis when the investigation closes. The "kept alive by one internal caller" explanation raises the obvious follow-up: how many other retired endpoints are still holding data. What happens next is whether Bromcom answers any of those three questions in public.
Top comments (0)