A decommissioned support portal became the single point of failure for 45 insurers

Forty-five insurers have now found themselves answerable for a breach that began in a support portal their shared software supplier was already decommissioning. The personal records of hundreds of thousands of South African insurance clients were taken from MIP Holdings in June, CEO Richard Firth told TechCentral on 15 September.

The mechanism is familiar enough to anyone who has inherited a legacy support channel. The intruders did not break MIP's perimeter. They reached the Atlassian Jira platform through credentials an employee had reused on a personal laptop, then moved data out slowly from around 25 May until the company realised something was wrong on a Sunday in mid-June. Tickets on that platform were supposed to hold obfuscated data. In practice, client staff pasted screenshots and reports into tickets, and identity numbers, e-mail addresses and cellphone numbers sat in the clear.

That last point deserves more weight than the credential reuse. MIP had a policy that expected obfuscation. The live tickets simply did not meet it. A reviewer reading the policy, or answering an onboarding questionnaire, would have seen the control. A reviewer looking at the actual support portal would have seen the failure. The distance between those two views is the whole problem.

That same distance between policy and live practice is why cyber awareness training matters inside your own organisation. The entry point was not a zero-day; it was an employee's reused credentials, obtained from an unrelated service that had itself been breached. Phishing simulations and awareness training are how you surface credential-handling habits that a written policy cannot see. Our cyber awareness training and simulated phishing tests are built on that principle: test the live behaviour, coach the person, and make the exception visible before it becomes someone else's incident.

The number makes it a concentration event

MIP said the 45 organisations represent just under half of its client base, almost all life insurers, with hundreds of thousands of records taken. The Prudential Authority held a meeting where concerns were voiced that a breach touching a large share of the life insurance sector's administration layer could be a systemic risk. It concluded, according to Firth, that it was not. TechCentral has asked the authority how it treats concentration risk where a single unregulated software supplier serves a large share of one sector. As of publication, that answer has not come.

The regulator's conclusion matters less than the question it was forced to ask. One supplier, one support platform, one employee's reused credentials, and 45 separate organisations each became a responsible party with a notification obligation of its own. Under South Africa's Popia, the notification duty sits with each insurer as the responsible party rather than with the operator that processed data on its behalf. The legal architecture is likely to be similar in many data protection regimes: the downstream organisation owns the duty, even when the failure occurred in someone else's system.

For a security leader elsewhere, the geography changes but the structure remains. Your onboarding questionnaire probably asks whether a supplier encrypts data at rest and has an incident response plan. It probably does not ask what happens to the tickets, screenshots and reports that accumulate in a support channel while a legacy platform is being replaced, who still has access, and whether the data in those tickets is actually redacted day to day. MIP's policy expected obfuscated tickets. The live tickets did not comply.

This is where continuous monitoring changes the conversation. It gives you a way to test the questionnaire's answers against what is visible in live systems, and then to drive remediation with the supplier rather than accepting a written explanation. Our supply chain defense programme is built around that loop: analysts validate findings before they reach you, tier monitoring to the supplier's actual risk, and work the remediation directly with the third party.

Failover has to include the legacy path

MIP said its core administration systems were unaffected, which is why the encrypted material the attackers offered to return mattered little. The harm came from the old support channel, not the operational platform. That distinction is the test most failover planning gets wrong. A supplier can prove that the core system recovers, or that production data is isolated, and still leave a decommissioned Jira instance full of customer records reachable from a personal laptop.

Ask a shared service provider to demonstrate that the path you are leaving is dark: decommissioned portals, archived support tickets, migration tools, and the credentials of staff who no longer touch them. Backup recoverability is a separate test. If a supplier cannot answer the dark-path question for its own estate, your customers' data is part of its answer by default.

After the case, the concentration remains

MIP paid the extortionists after anti-money laundering checks, on the advice of the cyber and legal specialists it brought in on day one. The group later listed Hollard on its leak site, and MIP said it identified markers linking that material to the June data. The payment did not close the exposure.

TechCentral has asked the Information Regulator how many breach notifications it has received in connection with the MIP incident and whether its investigation extends to the insurers that used MIP as an operator. Those answers are still outstanding. What is already clear is that 45 insurers are now working through the same mess, each with their own customers, their own regulator contact and their own version of a notification queue.

The South African case will be litigated, investigated and eventually covered by the next breach. The structural point will outlast it: when a sector shares one supplier's legacy support channel, every customer inherits the supplier's decommissioning decisions. The time to test that is before the support ticket is the breach.