Two weeks after a cyberattack affecting 15 Haruko clients was first reported, calls for fuller disclosure are putting the spotlight on what technology providers should tell institutional customers after a breach.
Is a cyber breach worse than the silence that follows it?
CoinDesk reported on 18 September that 15 clients of institutional crypto technology provider Haruko had been affected after an attacker exploited a vulnerability and gained access to process memory. Some client funds may also have been lost.
Haruko did not publicly comment on the incident. It did, however, communicate with at least some affected clients in the immediate aftermath. Messages seen by The Fintech Times (TFT) and attributed to CTO Adam Carlile said the company had mitigated the vulnerability, refreshed server-side secrets and would provide a full technical post-mortem.
Nearly two weeks after the incident was first reported, Haruko had still not published an update and did not respond to questions from TFT about the extent of the breach, reported fund losses or whether the promised technical post-mortem had been shared.
Its website news section and LinkedIn page also remain silent on the incident; its last public posts, from before the breach, covered a client golf day and serving gelato at an industry event.
Silence after the breach
CoinRoutes CEO Ian Weisberger is among those calling for more information. CoinRoutes provides trading technology for institutional crypto firms, connecting clients to exchanges and liquidity venues, and also integrates with Haruko. The two companies also share some institutional clients.
Weisberger told TFT that after the cyberattack, some of those shared clients contacted CoinRoutes to ask whether its own systems had also been affected and whether their connections were safe.
He remains concerned about what Haruko’s clients still do not know: what was exposed, what was not, and whether they have enough information to satisfy their own regulators, shareholders or customers.
Messages seen by TFT appear to show that, more than a week after the attack, at least one Haruko client was still asking Haruko for the promised post-mortem, whether login credentials had been compromised and how reported fund losses had occurred.
CoinRoutes’ own contact with Haruko has also gone quiet. Weisberger said Haruko removed the company from a shared Slack channel without warning. Yet CoinRoutes’ integration with Haruko remains in place and continues to send trade data into the platform.
“It’s putting us in a bit of a precarious situation as well because they’ve cut off communication with us, and we’re still sending them data,” he said. “Should we even be doing this?”
Weisberger said CoinRoutes and Haruko once worked closely, with CoinRoutes referring clients to Haruko before the two began offering some of the same capabilities. For him, the issue now is not whether Haruko answers CoinRoutes directly – it is whether affected clients have been given enough information about what happened.
Read-only, but money moved?
Haruko’s platform connects institutional clients to exchanges, custodians and DeFi protocols, giving it access to information across their trading activity and positions.
We spoke to Professor Alan Woodward, a cybersecurity and digital forensics expert at the University of Surrey about how serious the incident appears from the information shared so far and what affected clients should reasonably have been told.
He described the incident as “contained in extent but serious in nature”. But also picked up on one detail in the reporting that does not quite tally with the information shared in reports so far.
“The detail that doesn’t add up is the lost funds. Read-only keys cannot move assets,” he said. “Either some clients had issued keys with wider permissions and those were captured alongside the rest, or something beyond read-only material was in that process memory. Haruko needs to say which.”
We also asked Haruko whether any client funds were lost and whether any credentials carrying permissions beyond read-only access were exposed, but still no response at the time of publication.
Woodward said capturing process memory can expose more than a credential itself.
“Memory is where secrets sit unencrypted, so a memory capture takes whatever was loaded at that moment,” he said. “Rotating keys at the exchange is the right first step. But trading data, positions and counterparties don’t expire with a key rotation, and clients have their own investors and regulators to answer to.”
“Telling clients to rotate keys and promising a post-mortem is the correct first message,” he said, but weeks on, “it isn’t enough.” By then, he said, clients should have been told what was actually exposed rather than what might have been, whether other clients’ credentials were held in the same process and when the full technical account would arrive.
One vendor, many connections
Banks, trading firms and other institutions often rely on outside providers for payments, trading, data and infrastructure, meaning a security incident at one provider can quickly become somebody else’s problem.
Shashi Kiran, chief GTM officer at secure networking company Nile, said a trusted third-party connection effectively extends an institution’s attack surface beyond its own systems.
“The institution itself may not have been breached, but an attacker could now have a path through a partner, contractor or technology provider that already has authorised access,” he said.
Nile’s 2026 State of Networking, Security & AI in Financial Services research, based on a survey of 322 IT, security and risk professionals, reveals that only 21.1 per cent of financial institutions fully segment third-party access from core banking or trading systems using enforced policy controls.
Kiran said firms need to know exactly what an outside provider can access and be able to restrict that connection quickly if the provider is compromised.
“The institution should understand what happened at the provider: what was compromised, when the compromise began, which credentials or systems may have been exposed and whether the attacker could have used that access to interact with the institution,” he said.
In some cases, he added, reducing or temporarily suspending access until the scope is understood may be the safest option.
Does a company have to say anything?
Not every cyber breach comes with a legal requirement to announce it publicly.
Aselle Ibraimova, partner at Mishcon de Reya, says there is “a plethora of laws under which a technology provider may need to notify a security incident to its customers”.
Which rules apply depends on the data involved, the service being provided and the roles of both provider and customer, she explained. For technology suppliers working with regulated financial institutions, contracts can be particularly important. Customers may require providers to notify them promptly of significant incidents so they can meet their own regulatory obligations.
Ashley Avery, partner and head of commercial, tech & data at Foot Anstey, said suppliers providing business-critical services would often be expected to have specific reporting requirements written into their agreements.
“In circumstances where the services being provided by a supplier are business critical or where a breach of the supplier’s systems could otherwise have a significant impact on the client, we would expect the company to be contractually obliged to report cyber incidents promptly, provide ongoing updates, where necessary support regulatory reporting by the client and provide information about what caused the incident and what steps are being taken to remedy it.”
That is different from producing a complete forensic report within a day or two.
Martin Summerhayes, managed and technical services director at Northdoor, works with regulated financial services and insurance firms and signs contracts containing incident-notification provisions.
“The law sets the floor; the contract sets the timetable,” he said.
Summerhayes said the first 24 to 48 hours should generally cover what happened, what is affected, what has been contained and what remains unknown. A complete root-cause investigation can take considerably longer.
Avery also said companies do not need every answer before they start communicating.
“Early communication to regulators and key stakeholders is important even where limited information is available,” she said. “Most regulators will expect early notification followed by regular updates as information emerges.”
Some of those we spoke to said a full post-mortem can take longer than 48 hours, but clients should still be kept updated while the investigation continues.
Industry expectations
Weisberger points to the response to a separate security incident at Bitget as an example of how he believes that can be handled. He praised CEO Gracy Chen for promptly acknowledging the incident, disclosing approximately $351million in affected assets, addressing customer protection and committing to further updates.
“The difference? Bitget’s honesty and transparency,” he says. “This is the accountability institutional clients deserve.”
Weisberger suggests the lack of disclosure around the Haruko incident “makes the industry look unprofessional”, particularly when institutional clients have their own reporting obligations to meet.
He does not argue that every cyber incident needs an instant public statement as public disclosure during a fast-moving situation “can be more complicated” but said affected clients should be kept informed.
“When you’re an institutional firm, you have to communicate with your clients,” he said. “Protect your clients before an incident. Be transparent with them afterward.”
The post Haruko Breach Puts Crypto’s Cyber Disclosure Standards Under Scrutiny appeared first on The Fintech Times.
