The Shadow IT Tax: Bromcom's Legacy SSO Breach as an Operational Warning

For enterprise software leaders, the phrase 'technical debt' is often treated as a manageable line item—a series of deferred upgrades or patches to be addressed during the next development cycle. However, the recent security failure at Bromcom reveals that neglecting legacy decommissioning is not merely a technical inconvenience; it is a critical operational liability.

As The Register first reported, Bromcom, a provider of information management software for the UK education sector, recently notified customers of a personal data breach linked to its single sign-on (SSO) technology. The breach, which was disclosed in a September 24 EduGeek post, serves as a textbook example of the 'shadow IT tax,' where the decision to keep obsolete systems active for the sake of internal convenience creates an overlooked attack surface.

### The Mechanism of Failure

The breach centered on legacy SSO registration functionality within Bromcom's Communication Server environment. As reported by The Register, an unauthorized third party accessed and retrieved email addresses and limited information tied to affected SSO registrations.

Crucially, Bromcom admitted that this legacy functionality had remained in production long after it had been superseded. The reason provided by the supplier was a classic operational trap: the outdated service was still being called by an internal system. In an effort to avoid the friction of updating an internal dependency, the company left a door open that intruders eventually found.

From a B2B operations lens, this is a failure of lifecycle management. When a system is superseded, the decommissioning process must be absolute. By allowing a legacy component to persist simply because it served a secondary internal function, Bromcom effectively created a shadow IT environment—a pocket of infrastructure that exists outside current security standards but remains connected to the broader ecosystem.

### The Scope of Exposure

The data retrieved by the unauthorized party included: * Email addresses associated with SSO registrations * The identity of the provider used (such as Google or Microsoft) * Registration dates * Last sign-in dates * Internal user and registration reference numbers

Bromcom clarified in an FAQ that the affected component did not contain authentication tokens or account passwords. Furthermore, the company stated that the incident did not grant access to the external Microsoft or Google accounts themselves, as those authentication services operate separately from the compromised component.

Bromcom also confirmed that there was no evidence suggesting its school Management Information System (MIS)—the core tool used for student attendance, behavior, administration, and data management—was compromised.

### Operational Impact and Response

The incident was identified on September 6, following reports of SSO access problems. According to The Register, Bromcom has since withdrawn the legacy functionality from production and is working with external forensic specialists to determine the full scope of the data involved.

In a statement provided to The Register, a Bromcom spokesperson noted that the company has "identified, contained and began investigating" the incident, and is currently liaising with appropriate authorities as well as the affected schools and trusts.

For the education sector, the stakes of such failures are high. More than 5,000 schools and 390 multi-academy trusts utilize Bromcom's software. Its client list includes high-profile entities such as the Northern Ireland Education Authority, the Ministry of Defence, Warwickshire County Council, and Newport City Council. When a provider of this scale suffers a breach due to legacy neglect, it undermines the trust required to manage sensitive institutional data.

### The ROI of Decommissioning

This incident highlights a fundamental truth in SaaS operations: the cost of decommissioning is always lower than the cost of a breach. The 'tax' paid by Bromcom in this instance includes not only the forensic costs of the investigation but the reputational risk associated with notifying thousands of educational institutions about a preventable vulnerability.

When internal systems rely on superseded tech, the immediate operational path of least resistance is to leave the old system running. However, this creates a compounding risk. The Bromcom case proves that any component left in production—regardless of how 'internal' its utility is—is a potential entry point for attackers.

True operational excellence requires a rigorous audit of all dependencies. If a legacy service is still being called, the solution is not to maintain the legacy service, but to migrate the internal system to the current standard. Anything less is simply gambling with the organization's security posture.