Bromcom found a legacy sign-on breach on 6 September; its first dated public post came 18 days later

18 days from finding the breach to the first public post, and what that does not prove

Bromcom, a UK supplier of school management information systems, says it first identified a personal data breach in a legacy single sign-on (SSO) service on 6 September 2026, a Sunday. The earliest publicly readable statement we can date is a post by a Bromcom account on the EduGeek forum on 24 September. That is 18 days, or 432 hours, which is six lots of 72 hours. The Register reported it on 5 October, 29 days after identification and 11 after the forum post. The day counts are ours (derived). The dates come from Bromcom's FAQ and the forum thread.

What that does not establish. It does not date the first notice to schools: the FAQ says schools are being contacted and gives no date, and the opening post of the same thread says a trust had already had communications. It does not show a breach of any law: the UK GDPR 72 hours runs for each school, as controller, from its own awareness, and a processor such as Bromcom must tell its controllers "without undue delay", which has no hours. It does not say data was misused, and it does not say when the third party arrived, because Bromcom has not said. Every state below was read between 06:35 and 07:00 BST on Tuesday 6 October 2026, and several could change within the hour.

How we know. Bromcom's documentation site answered a command-line request with a plain 403 and loaded normally in an ordinary browser. No bot check was shown and none was bypassed. We read the FAQ there, and in two Internet Archive captures of it (20:05 UTC on 30 September and 06:40 UTC on 1 October) whose text matches the live page. The Bromcom Community announcement that the forum post links to sits in a members-only space: a logged-out visitor gets a page-not-found message, and we did not sign in. The Register is a pointer to the primaries, and we use it only for the date of its own report.

What is stated, and what is not

Position at about 07:00 BST on 6 October 2026. Stated: Bromcom's FAQ (updated 30 September), the forum post of 24 September, Bromcom's home page and status page. Not stated: what those pages do not say, which we checked for.

1. Item

   Dates

   Stated

   Identified 6 September, after reports of SSO access problems. Forum post 24 September. FAQ updated 30 September.

   Not stated

   When access began. When schools were first told. When the legacy service was withdrawn.

2. Item

   Component

   Stated

   Legacy SSO registration functionality in the Communication Server environment. Superseded, but kept because "it was still being called by an internal system".

   Not stated

   What that internal system was, or for how long the service had been superseded.

3. Item

   Data

   Stated

   Email addresses, the SSO provider (Microsoft or Google), registration and last sign-in dates where held, and internal user and registration reference numbers. No passwords, access, refresh or session tokens.

   Not stated

   Whether the list is complete. Customer posts add school names, school security codes and some PIN identifiers (unverified). The FAQ has a question on PIN-related information but no PIN field in its list.

4. Item

   People

   Stated

   The service relates to SSO registrations for "staff and pupil accounts". Parents are not in it: the parent app does not use this service.

   Not stated

   Whether staff, pupils or both were among the affected records, and how many of each.

5. Item

   Scale

   Stated

   Bromcom's home page claims 3.3m users, 1.2m+ students, 5.6K+ schools and 390+ MATs. That is the customer base, not a victim count.

   Not stated

   How many registrations, people or schools were affected. A Bromcom forum reply confirms per-school figures went to schools. No total is public.

6. Item

   Cause

   Stated

   Fixes listed: additional school and account authorisation checks, self-service removal limited to the signed-in user's own registration, better logging.

   Not stated

   How the third party got in, what was exploited, who it was. A root-cause analysis: Bromcom says it will "consider the appropriate next steps" once the investigation ends.

7. Item

   Misuse

   Stated

   No successful unauthorised sign-in to the MIS, MyChildAtSchool or a Bromcom account has been identified. No evidence school MIS data was accessed.

   Not stated

   Whether data was copied, published or misused. Whether all deleted records were restored: the FAQ says the email-address records were recovered.

8. Item

   Notification

   Stated

   School controllers are being contacted directly. Bromcom has not notified the ICO, saying it processes this data as a processor.

   Not stated

   The date of the first notice. Whether individuals have been told. Whether any school or trust has told the ICO.

9. Item

   Public record

   Stated

   FAQ updated 30 September. Status page at about 06:40 BST: no incident and no announcement listed, with a note that not every incident is listed.

   Not stated

   Any statement from the ICO or the NCSC (none found). The Community announcement, which is members-only.

Item	Stated	Not stated
Dates	Identified 6 September, after reports of SSO access problems. Forum post 24 September. FAQ updated 30 September.	When access began. When schools were first told. When the legacy service was withdrawn.
Component	Legacy SSO registration functionality in the Communication Server environment. Superseded, but kept because "it was still being called by an internal system".	What that internal system was, or for how long the service had been superseded.
Data	Email addresses, the SSO provider (Microsoft or Google), registration and last sign-in dates where held, and internal user and registration reference numbers. No passwords, access, refresh or session tokens.	Whether the list is complete. Customer posts add school names, school security codes and some PIN identifiers (unverified). The FAQ has a question on PIN-related information but no PIN field in its list.
People	The service relates to SSO registrations for "staff and pupil accounts". Parents are not in it: the parent app does not use this service.	Whether staff, pupils or both were among the affected records, and how many of each.
Scale	Bromcom's home page claims 3.3m users, 1.2m+ students, 5.6K+ schools and 390+ MATs. That is the customer base, not a victim count.	How many registrations, people or schools were affected. A Bromcom forum reply confirms per-school figures went to schools. No total is public.
Cause	Fixes listed: additional school and account authorisation checks, self-service removal limited to the signed-in user's own registration, better logging.	How the third party got in, what was exploited, who it was. A root-cause analysis: Bromcom says it will "consider the appropriate next steps" once the investigation ends.
Misuse	No successful unauthorised sign-in to the MIS, MyChildAtSchool or a Bromcom account has been identified. No evidence school MIS data was accessed.	Whether data was copied, published or misused. Whether all deleted records were restored: the FAQ says the email-address records were recovered.
Notification	School controllers are being contacted directly. Bromcom has not notified the ICO, saying it processes this data as a processor.	The date of the first notice. Whether individuals have been told. Whether any school or trust has told the ICO.
Public record	FAQ updated 30 September. Status page at about 06:40 BST: no incident and no announcement listed, with a note that not every incident is listed.	Any statement from the ICO or the NCSC (none found). The Community announcement, which is members-only.

Bromcom's wording on whether data was taken changed in six days

On 24 September a Bromcom account wrote on the forum that an unauthorised third party "has accessed and retrieved email addresses and limited information associated with SSO registrations". The Register's report repeats that sentence. On 30 September the FAQ was updated. Asked whether the personal data was actually accessed or only potentially exposed, it now answers: "Our investigation is ongoing to determine the nature and scope of the data involved." It gives the same answer to whether the information was copied, downloaded or exfiltrated, and to how many users or records were involved.

Bromcom's own wording on the same questions. Sources: the Bromcom account's posts of 24 and 25 September on the EduGeek thread, and the FAQ updated 30 September. Both read on 6 October 2026.

1. Question

   Was data retrieved?

   Forum, 24 and 25 September

   A third party "has accessed and retrieved" email addresses and limited SSO registration information.

   FAQ, 30 September

   Actually accessed or only potentially exposed: investigation ongoing.

2. Question

   How many?

   Forum, 24 and 25 September

   Per-school figures were given to schools, "based on a detailed technical investigation", and may change.

   FAQ, 30 September

   How many users or records: investigation ongoing. No total.

3. Question

   Was the MIS reached?

   Forum, 24 and 25 September

   No evidence of unauthorised access to the MIS or its data.

   FAQ, 30 September

   No evidence school MIS data was accessed. Unchanged.

Question	Forum, 24 and 25 September	FAQ, 30 September
Was data retrieved?	A third party "has accessed and retrieved" email addresses and limited SSO registration information.	Actually accessed or only potentially exposed: investigation ongoing.
How many?	Per-school figures were given to schools, "based on a detailed technical investigation", and may change.	How many users or records: investigation ongoing. No total.
Was the MIS reached?	No evidence of unauthorised access to the MIS or its data.	No evidence school MIS data was accessed. Unchanged.

What this does and does not establish. It does not show that the 24 September sentence was wrong: the FAQ does not retract it. It does show that Bromcom's public position on the central question for any controller, was the data taken, moved from a statement to "ongoing" within six days, and the FAQ does not say why. Black Swan Cyber, a UK security consultancy that sells email and account protection to schools, read it the same way on 1 October: its note says the 25 September FAQ "explicitly confirmed unauthorised retrieval" and that the revised wording "does not, by itself, establish that the previous findings were incorrect". We could not read the 25 September FAQ, because no archive capture of it exists, so the earlier wording rests on the forum post and on that note.

One more phrase matters. The FAQ asks "Were all deleted records restored?" and answers that the email-address records "have been recovered". The question presupposes that records were deleted. It does not say how many, by whom or when. That is our reading of the wording, not a stated finding, and it matters because the UK GDPR definition of a personal data breach covers "destruction, loss, alteration, unauthorised disclosure of, or access to" personal data. Deletion alone can be a breach even if nothing was copied.

Two comforting words: legacy, and single sign-on

Legacy. The word describes the age of the code, not its exposure. Bromcom's FAQ says the functionality "had been superseded but remained in production because it was still being called by an internal system". That is a dependency: a live service, reachable and holding data, that one internal system still needed. Superseded means a newer thing exists. It does not mean the old thing is off. Whether the old service sat on any retirement list is not stated, and we do not infer one. The NCSC's guidance on using software as a service tells organisations to prevent bypass of modern authentication by "disabling unused and legacy authentication protocols and interfaces". That is advice to the customer about its own configuration. The same hygiene applies inside a supplier, where the customer cannot see it.

Single sign-on. The phrase suggests one safe front door. Here the component was not the door but the register beside it, the layer that records which email address reaches a Bromcom account through which provider (our reading of the FAQ's field list). Microsoft and Google still authenticated the person, and Bromcom says no password or token was in the component and no Microsoft or Google account was reachable through it. Each registration record is still a small map: this address, with this provider, signs in to a school system. An address at a school's own domain already names the school. For anyone writing a convincing fake sign-in message, that is the useful part. The NCSC says federated sign-on "introduces a large single point of failure". In this case the weak point was the bookkeeping, not the door.

Customers' forum posts, relaying Bromcom's notices and not checked against a primary, add some detail. They say staff and pupil registrations are in scope, including some pupils on personal email addresses, and that the fields include school names, school security codes and some PIN identifiers. One customer says its affected count is nearly double its current active users, which would fit registrations that outlived the people they belonged to. That is one customer's reading, and the FAQ does not say. If it is right, the DfE standard's line on "disabling accounts as soon as someone leaves their role" does not reach a copy held on the supplier's side.

The dates, to scale

Same question, a different supplier

This site's briefing on Frontline Education asked the same question of a US supplier to school districts: how long between the supplier knowing and its customers hearing? Frontline's answer was 48 days, from a flaw found on 14 August to the first district letters reported on 1 October. The two cases are not like for like, and the table says where.

Frontline from our earlier briefing, Bromcom from the sources above. The day counts are derived. Different starting events and different first notices, so treat the comparison as a prompt, not a ranking.

1. Measure

   Starting event

   Frontline (US)

   14 August: security team identified a flaw in third-party software.

   Bromcom (UK)

   6 September: incident identified after reports of SSO access problems.

2. Measure

   First notice we can read

   Frontline (US)

   1 October: a district's account of a letter, reported by the press.

   Bromcom (UK)

   24 September: a forum post by a Bromcom account.

3. Measure

   Days

   Frontline (US)

   48

   Bromcom (UK)

   18

4. Measure

   Component named

   Frontline (US)

   No: a "third-party software product".

   Bromcom (UK)

   Yes: legacy SSO registration functionality in the Communication Server environment.

5. Measure

   Count of people

   Frontline (US)

   1,210 at one district. No total.

   Bromcom (UK)

   None in the public FAQ.

6. Measure

   Regulator

   Frontline (US)

   Frontline says it handles US state attorney general notices.

   Bromcom (UK)

   Bromcom has not told the ICO. It says schools, as controllers, decide.

Measure	Frontline (US)	Bromcom (UK)
Starting event	14 August: security team identified a flaw in third-party software.	6 September: incident identified after reports of SSO access problems.
First notice we can read	1 October: a district's account of a letter, reported by the press.	24 September: a forum post by a Bromcom account.
Days	48	18
Component named	No: a "third-party software product".	Yes: legacy SSO registration functionality in the Communication Server environment.
Count of people	1,210 at one district. No total.	None in the public FAQ.
Regulator	Frontline says it handles US state attorney general notices.	Bromcom has not told the ICO. It says schools, as controllers, decide.

Where Frontline named no product, Bromcom named the component and its role in plain words, which is useful to a defender. Where Frontline's clock ends in a letter a district showed a reporter, Bromcom's ends in a forum post, with the fuller notice in a members-only space. Neither case, on the dates alone, shows a breach of law. Both leave the same gap: the customer's own clock starts when the customer knows, and the supplier's dates are the only ones on the public record. We covered the regulator's side of that in an earlier briefing on the 72-hour clock.

The UK reading: the school's clock is its own, and Bromcom's FAQ hands it the decision

Bromcom says the data in this component is data it processes as a processor. Its FAQ says: "We have not notified the ICO about this incident." It is contacting the controllers so that they can assess it. That is consistent with the statute. Article 33(1) puts the duty to notify the regulator on the controller, "not later than 72 hours after having become aware", unless the breach "is unlikely to result in a risk to the rights and freedoms of natural persons". Article 33(2) says the processor "shall notify the controller without undue delay after becoming aware". There is no number of hours. Who the controller is, a school, a trust or a local authority, is for each customer to know. Bromcom says it is still mapping schools to controllers.

That makes the school's own date the one that matters. The EDPB's guidelines, whose earlier version the ICO's guide links and describes as continuing to be relevant, treat the controller, in principle, as aware once its processor has told it. They also say the processor need not assess the risk first: it must establish that a breach occurred and notify, and the EDPB recommends a prompt first notice with detail in phases. Bromcom's FAQ explains its pace by wanting a thorough review "so that you can make an informed decision". As an illustration only: a school that was told on 24 September, with enough detail to know it was affected, would count 72 hours to 27 September. A school first told later counts from then. No source dates any school's notice, and awareness turns on the facts, so this is arithmetic and not a finding.

Being a processor is not a safe harbour. Article 28(3) has the processor take "all measures required pursuant to Article 32" and assist the controller with Articles 32 to 36, and the contract is where breach-reporting terms belong, as the ICO's guide says. For an example of a processor fined directly, see Sweden's fine on Miljodata. Nothing here suggests Bromcom has been or will be.

Two points make this more than "email addresses". First, deletion counts as above. Second, Bromcom says the service relates to "staff and pupil accounts", so children's registration data is inside the component, although the FAQ has not said whether any pupil's record was among those retrieved. The DfE's guidance on managing breaches of data tells schools to establish the types of personal data and who the data subjects are, and contrasts "basic personal details of staff, such as name and email addresses" with full pupil records. An email address is the lower end of that scale, and a pupil's sign-in registration is not a full pupil record. Where it sits is the controller's judgement, and it must be written down either way: Article 33(5) has the controller document every breach, including those it does not report. A forum post relays Bromcom's view that the risk is not high. The FAQ itself gives no rating and answers the risk question with "ongoing".

The FAQ also tells schools: "There are no specific steps that schools need to apply as a result of this incident." In the same answer it urges vigilance for messages asking people to click links, provide credentials, approve sign-in requests or reset passwords. A controller cannot adopt the first sentence as its own conclusion. The assessment under Articles 33 and 34 is the school's. One administrative note: from 30 September 2026 the UK GDPR text on legislation.gov.uk says Article 33 notifications go to "the Commission", and the ICO says it transitioned to the Information Commission that day. Bromcom's FAQ and the regulator's own pages still say ICO, so we do too.

The risk Bromcom names is a believable sign-in email

Bromcom's FAQ names one risk by implication: its advice to be vigilant for suspicious messages, calls or emails, with a list of lures that ends in approving sign-in requests and resetting passwords. The fields it says were involved fit that lure. A person holding a school email address and the provider it uses (Microsoft or Google) can write a message that names the right provider and the right school system, and can cite a recent sign-in problem that staff really did experience. That last step is our inference. The NCSC's phishing guidance says criminals use information about you to make phishing messages more convincing.

That is a risk, not a report. We found no account of a phishing campaign using this data in the sources read. Black Swan Cyber's 1 October update says follow-on phishing "should not be presented as confirmed", and its sample lures are illustrations, not observed messages. It also sells in this space, which is not a reason to doubt the point, only a reason to weigh the framing. The useful reading is narrower: the one thing a controller can do before any evidence arrives is change what staff do with a sign-in prompt.

What to do, in the order worth doing it

Our judgement on the order, not a regulatory list. The first step comes first because a controller's clock cannot be recovered once it has been running unnoticed.

The DfE's termly review of the contracts register covers technology a school buys that has become or is about to become unsupported. It does not ask a supplier to list services it keeps running inside its own estate, so step six is our addition, not a DfE requirement. The NCSC's supply chain principles do point the same way: set minimum security requirements and put them in the contract, and build assurance activity, including a right to audit where it is possible, into those contracts (principle 10).

The question that exposes the gap

Bromcom says the old service stayed on because something inside the company still called it. Which superseded services is your own supplier still running on your staff and pupil data for the same reason, and which clause of your contract says you would hear about it before a stranger did?

Key facts