Daiwa Securities says it was not breached. Up to 110,000 of its clients may still have had their names, email addresses and securities account numbers taken. The Japanese brokerage said on 5 October that its vendor, Scala Communications, had found evidence of unauthorised access to its servers and of client data being leaked. The company was told on 3 October.
There is not much technical detail yet. The incident is still a useful reminder of a simple fact: the people you hand data to have their own security, and you inherit the result.
What is confirmed
According to Daiwa's statement as reported by Bloomberg, the Japan Times and Investing.com, the vendor reported on Saturday that it had found evidence of leaked client data after unauthorised access. Daiwa says about 220,000 records may be affected, of which roughly 110,000 contain personal information: names, email addresses and securities account numbers. One summary puts the intrusion between the evening of 2 October and the morning of 3 October.
Daiwa says the data cannot be used to log in to securities accounts or trade online, that it has seen no suspicious transactions linked to the incident, and that its own systems were not breached. It says it is contacting affected clients individually and warning them about phishing. The vendor has reportedly put emergency security measures in place and an investigation is under way.
What is not known
- What Scala Communications does for Daiwa. The reporting we reviewed does not describe the service, so we do not know why the vendor held client contact details and account numbers.
- How the intruder got in, and who they are. Nothing published says. There is also no word on whether the data has been offered for sale or published.
- Other customers of the vendor. It is not clear whether anyone else was affected.
- Whether the figures will move. Daiwa says the records “may” have leaked, and the numbers are the company's early estimate.
Why this data is useful even without a password
Daiwa's reassurance is accurate as far as it goes: a name, an email address and an account number do not open an account. They do make a very convincing message. A phishing email that addresses a client by name and quotes their real account number looks like it can only have come from the brokerage. That is what makes this kind of leak dangerous after the headlines fade: the exposure becomes a pretext for fraud weeks later, aimed at the one thing the attacker still needs, which is a password, a one-time code or a transfer.
If you are a client of an affected firm
- Treat any message about this incident with suspicion, especially one that asks you to click a link, log in or read out a code. Go to the firm's official site or app yourself.
- Never share a one-time code or password with anyone who contacts you first, including someone claiming to be from the brokerage.
- Turn on the strongest sign-in protection the firm offers, such as an authenticator app or passkey, and check recent activity and registered contact details.
- Be careful with the email address involved. If you reuse it for important accounts, those accounts become more attractive targets, so make sure each one has its own strong password.
If you are the company with a vendor
- Inventory what each supplier holds. For every vendor that sends messages, runs a campaign, hosts a form or processes support requests, list the fields it receives. If a field is not needed for the job, stop sending it.
- Share the least that works. A message vendor often needs an address and a template, not an account number. Pseudonymous references that only you can map back are safer than the real identifiers.
- Set retention for supplier copies. Contractually require deletion of lists and logs after the job, and ask for proof.
- Rotate what you gave them. API keys, SMTP credentials, SFTP logins and single sign-on connections to the vendor should be treated as exposed when the vendor reports an intrusion. Rotate them, then check logs for use you do not recognise.
- Prepare the customer message before you need it. The notice should say what is known, what is not, and how clients can verify a genuine message from you. Say plainly that you will never ask for a password or code by email.
- Agree incident contacts and delivery paths in advance. When a vendor reports a breach on a Saturday, nobody wants to be asking who has the new credentials, or pasting them into a group chat.
Where Secretus fits, and where it does not
Secretus covers the narrow human step in that last item: a person handing another a short text secret, such as a rotated vendor API key or an SFTP password. The sender encrypts it in the browser and shares a link that stops working after the expiry they set or the first successful open, so the value is not left in a chat log or email thread that the vendor or you may later lose.
It is not a vendor-risk platform or a data loss prevention system. It does not decide what you send to suppliers, stop a supplier from keeping it, or protect a customer list that is already on someone else's server. Those are procurement, contract and engineering decisions. A one-time link helps with one step in them: getting the next credential to the right person without leaving a copy behind.