NEC Contractor Hacked: Stolen Accounts Used to Encrypt Customers' Servers, Including Osaka Metropolitan University

Key takeaways

• NEC, one of Japan's largest IT services companies, said on October 20, 2026 that a company it uses for system development and maintenance was hacked in late September.
• The attackers used that company's legitimate account credentials to get into NEC customers' systems from the contractor's own computers, and encrypted files on their servers, leaving systems unusable.
• Files in a cloud storage service NEC used to share project information with customers and contractors also leaked. They included customers' personal data and system information. According to Nikkei and the Yomiuri Shimbun, information on three customers leaked, two of them including personal data.
• NEC has not named the contractor or the customers. Osaka Metropolitan University, whose 500 servers stopped on October 2, has said it is one of them.
• In our view, the lesson reaches far beyond NEC: in Japan's layered IT outsourcing, every subcontractor account that can reach a customer's systems is part of that customer's attack surface.

What NEC disclosed#

NEC's notice, published in Japanese on October 20, is short. It says:

Who was hacked	A company NEC contracts for system development and maintenance. Not named
When	Late September 2026
How customers were reached	Stolen legitimate account credentials were used to access customers' system environments from the contractor's terminals
Damage at customers	Files on servers encrypted; various systems unusable
Data leaked	Files in a cloud storage NEC set up to share information between customers and NEC, and between NEC and the contractor. They included customers' personal data and system-related information
Customers affected	"Multiple". Contacted individually; not named
Response	NEC now lends NEC-managed computers to the contractor, and will tighten its management of contractors and personal data

The notice does not say this was ransomware. Encrypted servers and leaked files often point that way, and Osaka Metropolitan University has described the attack on its own systems as ransomware, but NEC has not confirmed it for the incident as a whole, and we do not assume it. The notice also does not say how the contractor was hacked, how many customers were affected, or what personal data the cloud storage held. Nikkei and the Yomiuri Shimbun report that information on three customers leaked, and that two of those leaks included personal data.

As of October 21, we found no listing for NEC or its customers on the ransomware leak sites tracked by ransomware.live. If a group does claim the attack, the name it posts may well be the contractor's, since that is the company it actually broke into, rather than NEC's or a customer's. That would make the listing hard to connect to this incident, because the contractor has not been named.

Osaka Metropolitan University#

The first customer to identify itself is Osaka Metropolitan University, one of Japan's largest public universities. Early on October 2, about 500 servers on its virtualization platform stopped, most backups were encrypted, and classes were cancelled for a week.

On October 21, the university said NEC, which maintains and operates its core systems, had told it the day before that the attackers came in through a company NEC subcontracts, using that company's legitimate account. Data "related to the university", personal and system information, also leaked from NEC's cloud storage. The university says this is separate from the roughly 130,000 academic records on its own platform, whose possible leak it is still investigating.

The university's own timeline shows how the vendor relationship worked on the night: it was the maintenance vendor that saw servers stopping one after another at about 00:20 and alerted the university. The same chain of vendors turned out to be the way in.

What we don't know yet#

NEC has not said:

• Which company was hacked, and how: phishing, malware, a VPN, or something else
• Whether this was a ransomware attack, and whether a ransom has been demanded
• How many customers' systems were reached, as opposed to the three whose information reportedly leaked
• Who the other customers are, and whether any are public bodies besides the university
• What personal data was in the shared cloud storage, and how many people it covers
• Whether the contractor's accounts were protected by multi-factor authentication, and why they could reach customers' servers directly
• When NEC learned that the contractor was the source, and why it took until October 20 to say so publicly

Our analysis#

The contractor's laptop is part of your perimeter#

Japanese organizations rarely run their own core IT. They hire a systems integrator such as NEC, which often brings in subcontractors, which may bring in their own. Each layer needs accounts, and often remote access, to build and maintain the customer's systems. In our view, this incident shows the cost of that structure plainly: the attackers did not need to break into the university, or into NEC. They broke into a company two steps removed from the university, and used its legitimate access.

It is the same pattern we noted in our analysis of ransomware groups targeting Japan, where many confirmed victims were reached through group companies or IT contractors, and in the IDCF Cloud attack and the Studio breach, where one provider's compromise reached hundreds of customers. The account that does the damage is often one the victim never issued.

Even a leader finds it hard#

NEC is not a company that ignores its suppliers. Its Cybersecurity Management Report 2026, which in our view is one of the most useful public documents a Japanese company has published on the subject, sets out a supplier program that many organizations would struggle to match:

• Suppliers are graded by security level, and work is given only to those at the right level
• Re-subcontracting is prohibited without NEC's prior written approval, and each project must declare its subcontractors
• The supplier security standard was rebuilt in 2022 on NIST SP 800-171, on the assumption that incidents will happen, and suppliers submit a system security plan every year
• About 1,800 suppliers go through document inspections every year; about 100 key software development suppliers get closer attention; in fiscal 2025, about 70 NEC staff inspected 220 suppliers in person or remotely

And yet a supplier's legitimate credentials, used from the supplier's own computers, were enough to reach customers' servers. In our view, that is the uncomfortable point of this incident. Contracts, standards, self-assessments and audits show whether a supplier has the controls. They do not stop an attacker who already holds a valid account and a trusted device. What would have limited the damage is how access is built: whether vendor access goes only through devices the integrator controls, requires strong authentication, is open only when work is scheduled, and is watched while it is open. NEC's response, lending its own managed computers to the contractor, moves in exactly that direction.

If an integrator with NEC's resources finds the supply chain this hard to secure, most organizations should assume theirs has gaps they have not found.

Shared project folders are attack intelligence#

The second leak is easy to overlook. NEC's shared cloud storage held customers' personal data, but also system-related information: in a system integration project, that typically means designs, configurations, network diagrams and operating procedures. In our view, that kind of material deserves the same protection as the systems it describes. For an attacker, it is a map. Project storage shared across companies tends to collect far more than any one participant would keep, and to outlive the project.

Lending a laptop is the right fix, but a late one#

NEC's main remedy, lending NEC-managed computers to the contractor, is sensible: it brings the devices that touch customers' systems under the integrator's control. But it raises the obvious question of why customer systems could be reached from a subcontractor's own devices in the first place. Customers should not assume their integrator has already asked that question about every company in its chain.

Who tells the customers' customers?#

NEC has told its customers privately. Osaka Metropolitan University, as a public body, told the public. The other affected customers have not, as far as we can find. Under Japan's breach notification rules, each customer that holds personal data has its own duty to report and to notify the people concerned. In our view, when the cause is a shared supplier, a short public statement from each affected customer, even one that only says "we are one of them", would help the people whose data was in those folders know where to look.

What this means for readers#

• Ask your systems integrator which subcontractors can reach your systems, from which devices, with what authentication, and whether that access is switched off when it is not needed.
• Require managed devices and MFA for any vendor access to production, and log vendor sessions where you can see them.
• Review shared project storage: what is in it, who can reach it, and whether personal data and system designs need to be there at all.
• If you are an NEC customer and have not been contacted, ask NEC directly whether your systems or data were in scope.
• If you studied or worked at Osaka Metropolitan University, watch for the university's notice on what was in NEC's cloud storage.

Japanese terms at a glance#

Japanese	Reading	Meaning
委託先	itakusaki	Contractor
再委託先	sai-itakusaki	Subcontractor (a contractor's contractor)
正規アカウント	seiki akaunto	Legitimate (authorized) account
認証情報	ninshō jōhō	Credentials
端末の貸与	tanmatsu no taiyo	Lending (issuing) managed devices
多重下請け	tajū shitauke	Multi-layered subcontracting