Bromcom Legacy SSO Incident Exposes School Email and Entra ID Registration Data

What Bromcom says happened​

In a post on the EduGeek forum, a Bromcom representative described an incident involving the company's legacy SSO service, a separate comms server unconnected to the MIS. They said an unauthorised third party had accessed and retrieved email addresses and limited information tied to SSO registrations. Bromcom's FAQ puts the component inside its Communication Server environment.

According to the company, it first detected the incident on 6 September, after reports of SSO access problems. It has since withdrawn the legacy functionality from production and restored SSO access to limit disruption. The Register reported the story on 5 October. Bromcom's FAQ was last updated on 30 September, and the company says its investigation with external forensic specialists is continuing.

What data was involved​

The affected service held:

• email addresses associated with SSO registrations;
• the SSO provider used, such as Microsoft or Google;
• registration and last sign-in dates, where held; and
• internal user and registration reference numbers.

Bromcom's 25 September FAQ said the investigation had confirmed this personal data was retrieved from the SSO service. The later FAQ says the investigation is still working out the full nature and scope. It does not say how many records or schools were involved.

Bromcom says the component did not hold account passwords, access tokens, refresh tokens or session tokens. It also says the incident did not give access to anyone's Microsoft or Google account, because those providers' authentication services are separate. It reports no evidence that MIS data or the MIS database was accessed. It also reports no evidence of a successful unauthorised sign-in to the MIS, MyChildAtSchool or a Bromcom user account.

Parents appear to be outside the blast radius. Bromcom says the SSO service relates to staff and pupil registrations, and that the parent app does not use it. Security firm Black Swan Cyber, summarising the 25 September FAQ, noted that the affected registrations covered staff and pupils, and some pupil registrations used personal email addresses.

The root cause: a forgotten dependency​

Bromcom's explanation of why the service was still running is short. The functionality had been superseded but remained in production because an internal system was still calling it.

An earlier version of the FAQ, dated 25 September, was more specific about the flaw. It said certain read, delete and PIN-related functions could be called without verifying who was making the request or whether they were authorised to act on the registration. The same version says a technical investigation on 7 September established that SSO registration records had been deleted. That fits the access problems that first alerted Bromcom. Bromcom's later FAQ says the email-address records were recovered and that recovery work was done for SSO registrations. It does not say every record was restored.

This is a familiar failure pattern. A newer replacement ships, the old one is "retired" on paper, and one forgotten caller keeps it alive. No one reviews the old endpoint, because it is officially dead. The result is an authentication-adjacent service with weak access control, still reachable and still holding data.

This is an inference from Bromcom's account, not a finding about the company's wider security practices. But the lesson applies to any IT team:

• Decommissioning needs a dependency check, not just a new release.
• Retired functions should be blocked or logged until you confirm nothing still calls them.
• Anything that maps identities to tenants or schools deserves the same authorisation checks as the main product.

Bromcom's fixes​

Bromcom lists four changes:

1. It withdrew the legacy SSO functionality from production.
2. It added school and account authorisation checks.
3. It restricted self-service removal to the signed-in user's own registration.
4. It improved operation-specific logging and security audit records.

The third item suggests the delete path was part of the problem, which matches the earlier FAQ's description of deleted registrations. Bromcom has not published a root cause analysis. It says it will consider next steps once the investigation is complete.

Why a Microsoft 365 admin should care​

Bromcom's staff SSO documentation says the feature lets schools' staff sign in to the MIS with an existing Microsoft or Google account instead of a separate Bromcom username and password. The registration data in this incident is the link between your Entra or Google identity and a Bromcom user. It is not the identity itself.

An EduGeek poster relaying school communications said the incident wasn't related to Entra but specific to Bromcom. That is a forum comment, not an official statement, but it matches Bromcom's own position that the Microsoft and Google authentication services were separate.

The practical risk is phishing, and that is an inference rather than a confirmed outcome. A list of verified school email addresses, tagged with the identity provider each person uses, makes it easier to craft a convincing "your Microsoft sign-in needs attention" lure. Black Swan Cyber makes a similar point about phishing. Bromcom has not reported any misuse of the data.

What schools and trusts can do​

Bromcom says there are no specific steps schools must take because of the incident. It still advises vigilance for suspicious messages, calls or emails, especially any asking people to click links, provide credentials, approve sign-in requests or reset passwords. Sensible, low-cost measures follow from that. These are general good practice rather than Bromcom instructions:

• Warn staff, and where appropriate older pupils, to expect tailored phishing that mentions Bromcom or SSO.
• Remind users never to approve a multifactor prompt they did not start.
• Check that phishing-resistant MFA or conditional access is in place for staff accounts where your licensing allows it.
• Review sign-in logs for unusual activity from the affected addresses.
• Confirm your own contact details with Bromcom, since it says it is mapping affected schools to data controllers.

Data protection: who decides on the ICO?​

Bromcom says it has not notified the UK Information Commissioner's Office. Its reasoning is that it processes the data as a data processor. It is contacting the data controllers, meaning the schools, local authorities and trusts, so they can assess the incident and decide what to do. Bromcom's FAQ does not make that decision for them. Whether to notify the ICO or affected individuals is a call for each controller, ideally with their data protection officer.

Bromcom also says the impact varies from school to school. Black Swan Cyber, citing the FAQ, warns that an absence of login disruption does not show a school was unaffected.

Open questions​

• How many records, schools and individuals were affected?
• Was the data copied or exfiltrated, or only read and deleted? Bromcom's FAQ does not yet answer this.
• Will Bromcom publish a root cause analysis?
• Why did it take until late September to notify customers about an incident first detected on 6 September? Bromcom says it wanted to give schools accurate, verified information.

The takeaway​

On Bromcom's account, this was not a break-in at the MIS, a theft of Microsoft credentials or a hijack of school accounts. It was a neglected legacy endpoint that leaked identity-linking metadata. That is serious mainly because it can make phishing more convincing. For admins, the sensible response is to tighten sign-in defences and then audit your own estate for retired services that something still quietly depends on.