NEC Subcontractor Breach: Osaka Metropolitan Ransomware, 77,851 Leaked

On 20 October 2026 NEC said a company it uses for system development and maintenance was attacked in late September, and that stolen but valid accounts from that company were used against NEC customers. Osaka Metropolitan University lost about 500 servers to ransomware. Osaka University says 77,851 people's data leaked from a shared cloud folder. Check every vendor account and every shared folder now.

Two different failures sit inside this one incident. At Osaka Metropolitan University (OMU), someone logged in with a maintenance account that was supposed to be there, from a device that was supposed to be used, and encrypted a virtualisation platform. At Osaka University, nobody broke into the university at all: a file sharing folder run by NEC, used with a partner company the university had never been told about, still held personal data after the work had ended, and a third party downloaded it.

We work from NEC's apology of 20 October, OMU's fifth report of 21 October and its related notices, Osaka University's notice of 21 October, and official guidance from Japan's Personal Information Protection Commission (PPC), the National Cybersecurity Office (NCO, formerly NISC), the Information-technology Promotion Agency (IPA) and NIST. Japanese sources are our translations. Neither NEC nor the universities have named the subcontractor or any ransomware group, and we do not either.

What happened

NEC's notice, dated 20 October 2026, says a company to which it outsources system development and maintenance work suffered a cyberattack in late September. Credentials for legitimate accounts were stolen from that company and then misused. NEC says this caused unauthorised access at its customers and leaks of information that included personal data. It says it has already contacted each of the affected customers, of which there are several, individually.

NEC lists two main types of damage. First, someone used legitimate accounts "from the contractor's terminals" to access customers' system environments; files on servers were encrypted and systems stopped working. Second, files leaked from a cloud storage service that NEC created and used to share information between customers and NEC, and between NEC and its contractors. NEC says those files contained customers' personal data and system information. After discovering the incident, NEC says it began lending NEC-managed devices to the contractor, and it will tighten contractor management and personal data management.

Press reports summarised by piyolog say NEC told reporters three customers' information leaked, two with personal data. NEC's own notice names no customers and no contractor.

Two customers have identified themselves.

Osaka Metropolitan University: ransomware on the core platform

OMU is the public university formed by merging Osaka City University and Osaka Prefecture University. Its fifth report, published at 11:30 JST on 21 October, says that on 20 October NEC, which it pays to maintain and operate its core systems, told it the cause of the 2 October outage. A business to which NEC re-outsources development and maintenance work (OMU's word is 再委託先, a sub-subcontractor from OMU's point of view) was attacked in late September, and that business's legitimate account was used to access OMU's systems without authorisation.

The same report says NEC confirmed that "personal information and system-related information relating to the university" leaked from cloud storage NEC used. The contents and number of records were still being confirmed with NEC as of 21 October.

According to OMU's 5 October press materials, as summarised by piyolog, the maintenance contractor saw servers stopping one after another at about 00:20 JST on 2 October; engineers on site later found the virtual server group down and signs of data tampering.

At a press conference on 5 October, the university said it judged the incident to be a ransomware attack. Press reports, including Business+IT, said about 500 servers on the virtualisation platform stopped and much of the backup data was also encrypted. The university declined to say whether a ransom was demanded, according to NHK via piyolog.

Osaka University: a shared folder, not an intrusion

Osaka University's notice of 21 October is short and unusually direct. NEC operates the university's campus-wide educational computer system. On 9 October 2026, NEC told the university that on 26 September a third party had downloaded files that contained the university's personal data.

The university's follow-up found three things:

1. A partner company (協力会社) that had never been reported to the university was involved in part of the work.
2. NEC was sharing files with personal data on cloud storage with that partner, "not based on the contract" with the university.
3. NEC still held files it should have deleted after the work ended, and those were the files downloaded.

The university says 77,851 people are affected as currently confirmed, with duplicates removed: 59,014 graduates, 15,035 current students and 3,802 staff. It says NEC's investigation found no trace of unauthorised access to the educational computer system itself, and that it regards the unreported partner and the non-contract sharing and retention as a serious problem.

Osaka University did not suffer ransomware. It is a data leak from a vendor's collaboration space.

Timeline

All times JST. Sources are listed at the end; secondary sources are marked.

What changed since first reports

Until 20 October, OMU's outage had no public cause beyond ransomware, and nothing linked it to a vendor. NEC's apology and the two universities' notices the next day turned a single university's ransomware story into a shared vendor's subcontractor problem. OMU's fifth report also separated two data questions: the roughly 130,000 records in its own platform are still under investigation, while the confirmed leak is a different set of files in NEC's cloud storage.

Who is affected

Technical details

There is no CVE, malware sample, hash list, IP list or ransom note in any public source for this incident. NEC, OMU and Osaka University have published none, and no government advisory names indicators. What is public is the access path, the blast radius and the data fields. Each line below is attributed.

Access path, as described by the victims

What is not public: how the credentials were stolen, which remote access method was used, what privileges the accounts held, whether multi factor authentication was in place, which cloud storage service was used, and which ransomware family encrypted the servers. ITmedia's @IT made the same point on 22 October.

That matters because a valid account used from the vendor's own device looks normal to most controls.

Blast radius at Osaka Metropolitan University

The eduroam line is worth a second look: eduroam passes each login to the user's home identity server, so with OMU's authentication service down, its users could not log in even at other institutions.

Personal data fields

Osaka University (confirmed leaked, 77,851 people). The university says the fields differ by person, and the main ones are:

• Name
• Osaka University personal ID
• University-issued email address (OUMail account and similar)
• Student number or staff number
• Affiliation

Osaka Metropolitan University, NEC cloud storage (confirmed leaked, contents and counts unknown). OMU describes it only as personal and system-related information about the university. No field list or count has been published.

Osaka Metropolitan University, its own platform (possible exposure, under investigation). At the 5 October press conference, according to press reports collected by piyolog, the systems held names, addresses, email addresses, ID card photos and mobile numbers, staff bank account details used for salary payments, and records for students back to 1995 (former Osaka City University) and 2005 (former Osaka Prefecture University). Reports put the academic records at about 130,000. OMU's own wording on 21 October is that whether anything leaked from its platform is still being investigated. That figure is not a confirmed leak.

What the leaked fields enable

Name, university email address, student or staff number and affiliation are exactly what a convincing phishing email to a university community needs. Osaka University says no misuse has been confirmed so far, and asks people to watch for phishing and spoofed email using the leaked information.

System-related information is the line defenders should worry about most. NEC and OMU both use the phrase. In an IT maintenance relationship that can mean network diagrams, server lists, configuration notes or operating procedures. Neither has said what it contained, but a team in that position should assume an attacker now knows more about the environment.

Indicators of compromise

None published. If you are an NEC customer, NEC says it is contacting affected customers individually; ask it directly for any indicators, account names and time windows it has. If you are not, the useful indicators are behavioural: vendor accounts logging in outside an approved change window, vendor sessions touching hypervisor management or backup consoles, and bulk downloads from shared folders by identities that are not on your list of approved parties.

The supply chain in three words

The three organisations use three different words for the company that was attacked, and the difference is the whole story.

Whether the attacked firm and Osaka University's unreported partner are the same company is not stated by any source. Treat them as possibly different.

Most organisations can name their direct IT vendors. Far fewer can name each vendor's subcontractors, the accounts those subcontractors hold, the devices those accounts log in from, and the folders where their data sits on the vendor's side.

What Japan's guidance already says

None of the controls that matter here are new. Japanese and US guidance both describe them.

The PPC on supervising contractors

The Personal Information Protection Commission's general guideline on the Act on the Protection of Personal Information sets out, under Article 25, that a business that outsources handling of personal data must supervise the contractor. It lists three measures: choose an appropriate contractor, sign a contract that covers safe handling and lets the business understand how data is handled, and check how the contractor actually handles the data, for example through regular audits.

On subcontracting the guideline is specific. When a contractor wants to re-outsource, the business should receive advance reports or give approval covering who the subcontractor is, what work it does and how it will handle the personal data, and should audit regularly, directly or through the contractor. The same applies at further levels down.

The guideline also lists examples of failing to supervise. One reads, in our translation, as a case where the contract required the business to track subcontracting, but it never asked for reports, "unrecognised subcontracting" happened, and the subcontractor leaked data. We do not say that example describes this case; how the law applies here is for the regulator.

The PPC's guideline also sets the reporting clock for reportable leaks: a prompt preliminary report, then a final report within 30 days of learning of the event, or 60 days where the leak may have been carried out for an unlawful purpose, such as an attack.

The National Cybersecurity Office on outsourcing

Japan's National Cybersecurity Office (NCO), which took over the role of NISC, publishes the Unified Standards for government bodies, currently the FY2025 (Reiwa 7) edition, with guideline revisions as recent as June 2026. Alongside them it publishes a separate guide to writing procurement specifications that deal with supply chain risk in outsourced work. Both are written for government bodies, but the outsourcing guide is a ready template for contract language on subcontractors and data handling.

The IPA's ranking

The IPA's "10 Major Information Security Threats 2026" for organisations, published 29 January 2026, ranks ransomware first and "attacks targeting supply chains and contractors" second. The supply chain entry has been in the list for eight years running. This incident is both at once.

NIST SP 800-161 Rev. 1

NIST SP 800-161 Rev. 1 (May 2022, with updates as of 1 November 2024) is the US reference on cybersecurity supply chain risk management. Its public page describes guidance for identifying, assessing and mitigating supply chain risk at every level of an organisation, including policies, plans and risk assessments for products and services. In December 2025 NIST added a fillable version of its assessment scoping questionnaire, Table 26, which is a practical starting point for asking a vendor about its subcontractors.

What any organisation using an IT vendor should do now

These steps assume you are a customer of an outsourced IT operator, not NEC specifically. Commands are examples for common platforms; adapt names and paths.

1. Build the list of every outside account that can reach you

Start with identity, because that is where this incident started. List every account used by a vendor, a vendor's subcontractor or a maintenance contractor, in every directory you run.

For on premises Active Directory, if vendor accounts live in their own OU:

Get-ADUser -Filter * -SearchBase "OU=Vendors,DC=example,DC=local" `
  -Properties Enabled,LastLogonTimestamp,PasswordLastSet,Description,MemberOf |
  Select-Object SamAccountName,Enabled,
    @{n='LastLogon';e={[DateTime]::FromFileTime($_.LastLogonTimestamp)}},
    PasswordLastSet,Description |
  Sort-Object LastLogon -Descending

If they do not live in their own OU, that is your first finding. Search by description, naming convention or manager field instead.

For Microsoft Entra ID, list guest and member accounts from outside domains:

Connect-MgGraph -Scopes "User.Read.All","AuditLog.Read.All"
Get-MgUser -All -Filter "userType eq 'Guest'" -Property DisplayName,UserPrincipalName,CreatedDateTime,SignInActivity |
  Select-Object DisplayName,UserPrincipalName,CreatedDateTime,
    @{n='LastSignIn';e={$_.SignInActivity.LastSignInDateTime}}

For Linux hosts and hypervisor management servers, check who has keys and who logged in:

# Every authorised SSH key on the host, with the file it lives in
sudo find / -xdev -name authorized_keys -type f -exec sh -c 'echo "== $1"; cat "$1"' _ {} \;

# Recent logins with full timestamps
last -F | head -50

# SSH authentication events in the last 30 days (systemd hosts)
sudo journalctl -u ssh -u sshd --since "30 days ago" | grep -E "Accepted|Failed"

For each account, record: which company owns it, which named person uses it, which device it should log in from, what it can reach, and when it was last used. Any account whose owner nobody can name gets disabled today.

2. Ask each vendor for its subcontractor list, in writing

Send every IT vendor that holds accounts or data a short request:

1. Name every company that works on our systems or data on your behalf, at every level.
2. For each, list the accounts it uses in our environment and in yours.
3. Say which devices those accounts log in from, and who manages those devices.
4. List every place our data sits on your side: file shares, cloud storage, ticket systems, chat.
5. Confirm what you delete at the end of each piece of work, and show us how you check.

NIST's Table 26 questionnaire and the PPC's three supervision measures are good scaffolding for this. Answers that come back as "we will check" are themselves useful information.

3. Look for your data in collaboration spaces you did not approve

Osaka University's leak came from a cloud folder the university never agreed to. You cannot list a vendor's folders from your side, but you can check your own tenant for sharing that reaches outside organisations, and you can ask vendors to show theirs.

For SharePoint Online and OneDrive:

Connect-SPOService -Url https://example-admin.sharepoint.com
# Tenant-wide external sharing setting
Get-SPOTenant | Select-Object SharingCapability,DefaultSharingLinkType,RequireAnonymousLinksExpireInDays
# Sites that allow external sharing
Get-SPOSite -Limit All | Where-Object { $_.SharingCapability -ne 'Disabled' } |
  Select-Object Url,SharingCapability,Owner

Then pull audit records for files shared with external users or downloaded in bulk in the last 90 days, from your platform's audit log, and sort by external domain. Whatever your platform, the questions are the same: which outside domains can read our data, what did they download, and is the work they were given still running.

4. Put maintenance access behind a door you open

An always-on maintenance account is a standing invitation. Move vendor access to a pattern where:

• the account is disabled by default and enabled for a ticketed window, then disabled again;
• login requires phishing resistant authentication bound to a device you can identify;
• the session passes through a jump host or access broker that records it;
• the account cannot reach hypervisor management, backup consoles and the identity provider at the same time unless that specific job needs it.

NEC's own interim step, lending NEC-managed devices to its contractor, points the same way: the device a maintenance account logs in from should be one the accountable party manages.

5. Separate backups from the admin plane

OMU's backups were largely encrypted alongside production, according to press reports. The exact backup design has not been published, so we draw only the general lesson: if the same credentials or management path that run production can also delete or encrypt backups, one stolen account can take both.

Check:

• whether at least one backup copy is offline or immutable for a retention period an administrator cannot shorten;
• whether backup administration uses separate accounts, separate authentication and, ideally, a separate identity domain;
• whether you have restored a full system from that copy in the last six months, and how long it took.

6. Plan for your identity provider going down

OMU could not let people enrol a second factor for days and its eduroam federation stopped because its authentication service was offline. Write down, before you need it:

• how you will force reset every password if the directory is suspect;
• how people without a second factor will get one when the enrolment system is down;
• which outside services (federation, SaaS single sign on, mail) depend on your identity provider and what users will see when it is gone.

7. Prepare people for phishing

Osaka University's leaked fields are a phishing kit. Tell students, graduates and staff what was leaked, what you will never ask for by email, and where official notices will be posted. OMU used a separate temporary site, omu.moe, while its main domain was down, and both universities opened dedicated contact points. Decide your equivalent now, and publish its address in advance so people can check it.

What NEC customers specifically should ask

If you buy IT services from NEC, or from any large integrator, these are fair questions this week:

1. Were we one of the customers NEC contacted individually? If not, does NEC confirm in writing that we are not affected?
2. Was any of our data in the cloud storage NEC describes, and if so, which files and since when?
3. Which of our accounts did NEC or its subcontractors rotate after late September?

Open questions

• How were the contractor's credentials stolen, and did the accounts require multi factor authentication?
• Which remote access route reached OMU's virtualisation platform, and with what privileges?
• Is the attacked firm the same as Osaka University's unreported partner company?
• Which cloud storage service did NEC use, and how was it accessed on 26 September?
• What OMU data was in NEC's cloud storage, and how many people does it cover?
• Did anything leak from OMU's own platform, including the roughly 130,000 academic records?
• How many NEC customers are affected in total, and were others encrypted?
• Has any group claimed the attack or published data? No public source says so as of 25 October.

What would have helped

Practices any team can use

Nothing below would have required new technology. Each is a habit that shrinks how far a stolen vendor account can go.

1. A live register of outside accounts. Every vendor and sub-vendor account, its owner, its device and its last use, reviewed monthly. The PPC already expects advance reports on subcontracting; an account register is how you see it in practice.
2. Contract terms on subcontracting, data location and deletion, with evidence. Osaka University's three findings map exactly onto three clauses: no subcontracting without approval, no data outside approved locations, deletion at end of work with a certificate.
3. Just in time access for maintenance. Accounts that do not exist outside a change window cannot be used at midnight.
4. Device bound, phishing resistant login for vendor accounts. It does not stop an attacker sitting on the vendor's real device, which NEC's wording suggests, but it narrows the routes.
5. Separation between hypervisor, backup and identity administration. One account should not be able to stop 500 servers and encrypt their backups.
6. Immutable or offline backups with tested restores. Measured in hours to restore core services, not in "we have backups".
7. A plan for an offline identity provider. Forced resets, second factor enrolment and federation dependencies written down in advance.
8. Data minimisation in vendor work. If a support task needs a student list, give the vendor the minimum fields for the minimum time, and check that it is gone afterwards.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists. Gold Open Source at gold.safeguard.sh gives free CVE intelligence with affected and fixed versions. Neither is relevant to how this incident started: no software vulnerability has been named, and the entry point was a valid account. They matter for the next step in a recovery like OMU's, when teams rebuild hundreds of servers and need to know that the open source components and images they reinstall are on fixed versions.

Where Safeguard fits

Safeguard would not have stopped a stolen, valid maintenance account from logging in, and it does not recover encrypted virtual machines. It is also not a data loss prevention tool and does not watch a vendor's cloud storage. Here is where it does help:

• Rebuilding clean. When a team rebuilds systems after ransomware, Safeguard scans repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>), matches components against vulnerability databases and shows which projects contain a given component and version. That gives a starting inventory of what you are putting back.
• Fixing what the scan finds. Autonomous remediation can open fix pull requests (it ships off by default), and policies and gates evaluated in the platform can stop a vulnerable version from returning.
• Keeping a vendor register next to the software register. Safeguard's compliance suite includes Vendors, Questionnaires and Risks tabs. Teams can record each IT supplier, send the subcontractor questions above as a questionnaire and track open risks beside the software inventory, so the question "who touches this system" has an answer in the same place as "what is this system made of".
• Doing the work with approval. The Safeguard CLI's assistant can edit code and run commands with your approval, and the desktop and phone apps can send work to a computer running the CLI. In a rebuild, that keeps every change reviewable.

Common mistakes and troubleshooting

"Our vendor has MFA, so this does not apply to us." NEC says the logins came from the contractor's own terminals. Multi factor authentication bound to a device does not help if the attacker controls that device. Ask what happens after login: what the account can reach and when.

"We only have one contract, with the integrator." Both universities had one contract with NEC. The attacked firm and the unreported partner were further down the chain.

Disabling the vendor account but not its keys. Service accounts, SSH keys, API tokens and saved hypervisor credentials survive a disabled directory account. Inventory them separately.

Treating "possibly exposed" as "leaked" or "not leaked". OMU's 130,000 figure is under investigation. Communicate the uncertainty plainly to the people affected rather than rounding it either way.

Asking the vendor for "confirmation" of deletion and stopping there. Ask for the location, the method and a listing showing the folder is empty or gone.

FAQ

Which organisations are affected?

NEC says several customers were affected and has not named them. Osaka Metropolitan University and Osaka University have identified themselves. Press reports cited by piyolog say three customers' information leaked and two involved personal data.

Was Osaka University hit by ransomware?

No. Osaka University says files containing its personal data were downloaded by a third party on 26 September from cloud storage NEC shared with a partner company. NEC found no trace of unauthorised access to the university's computer system.

How many people are affected at Osaka University?

The university says 77,851 people as currently confirmed, without duplicates: 59,014 graduates, 15,035 current students and 3,802 staff. Fields include name, Osaka University personal ID, university email, student or staff number and affiliation.

Did 130,000 records leak from Osaka Metropolitan University?

That is not confirmed. On 5 October OMU said about 130,000 academic affairs records in its own systems might have been exposed. On 21 October it said that data is separate from the NEC cloud storage leak and that whether it leaked is still under investigation.

Who is the subcontractor, and which ransomware group was involved?

Neither has been named publicly by NEC, OMU or Osaka University. No group claim appears in the sources we checked.

Were there any CVEs or indicators of compromise?

No CVE, hashes, IP addresses or other indicators have been published. The entry point described by NEC is stolen credentials for legitimate accounts, not a software flaw.

What should students, graduates and staff do?

Treat email that mentions your student or staff number, affiliation or university ID with suspicion, and check official notices on the university's own sites. Osaka University says it will notify affected people individually. OMU opened a consultation form for graduates and parents on 23 October.

What should other organisations take from this?

List every vendor and sub-vendor account that can reach you, ask each vendor for its subcontractors and data locations in writing, put maintenance access behind time limited approval, and make sure at least one backup copy cannot be reached from the production admin plane.

Every recovery from an incident like this ends with rebuilding software, and that part is where Safeguard's remediation tools apply.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows NEC, either university or any ransomware recovery; each is a real Safeguard session applied here to a team rebuilding or governing systems after a vendor incident.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. A university IT team rebuilding a portal after an incident like OMU's could run /scan . in the portal's repository and ask the assistant to move each flagged dependency to its fixed version before the rebuilt service goes back online.

Click through it at your own pace, or open it full screen.

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. During a rebuild, an engineer could pick the folder for one restored service, ask for its vulnerable libraries to be upgraded, and approve or deny every change, so nothing is altered on a recovering system without a person seeing it.

Click through it at your own pace, or open it full screen.

This session connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. A risk team could connect Claude the same way and ask which of its projects contain a component named in a new advisory, keeping write tools switched off, while it works through the vendor questions in this post.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard and follow the CLI docs. For related reading, see the IDCF Cloud ransomware incident, ransomware at a cloud provider and third party risk, cloud provider concentration risk after IDCF and October 2026 security incidents and what would have helped.

Quick check

Sources

• NEC: Apology for customer system failures and information leaks caused by unauthorised access at a contractor (20 Oct 2026) (read via archived copy)
• Osaka Metropolitan University: 5th report, system failure and information leak from the contractor's cyberattack (21 Oct 2026)
• Osaka Metropolitan University: consultation desk for graduates and parents (23 Oct 2026)
• Osaka Metropolitan University: temporary notice site, all notices
• Osaka Metropolitan University: OMU authentication system and two-factor authentication (10 Oct 2026)
• Osaka Metropolitan University: OMUID consultation desk and forced password change (16 Oct 2026)
• Osaka Metropolitan University: eduroam and core systems unavailable (13 Oct 2026)
• Osaka Metropolitan University: OMU mail status for students (22 Oct 2026)
• Osaka University: Personal information leak at a contractor (21 Oct 2026)
• Personal Information Protection Commission: APPI guidelines, general rules (Article 25, supervision of contractors; leak reporting)
• Personal Information Protection Commission: responding to leaks
• IPA: 10 Major Information Security Threats 2026
• IPA: Supply chain risk management
• National Cybersecurity Office: Unified Standards for government cybersecurity and related manuals
• NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
• piyolog: Summary of the Osaka Metropolitan University system failure via a contractor (updated 22 Oct 2026)
• piyolog: Summary of unauthorised access at an NEC contractor (22 Oct 2026)
• ITmedia @IT: Osaka Metropolitan ransomware traced to NEC contractor (22 Oct 2026)
• Business+IT: Osaka Metropolitan University ransomware, 500 servers stopped (6 Oct 2026)

Last reviewed: 25 October 2026. This is a developing story; check the linked advisories for the latest status.