Nikkei and Iris Ohyama breaches: Japan's autumn 2026 wave, cloud credentials and APPI duties

Short answer. On 16 October 2026, Nikkei Inc. said that a cloud service it uses for system development was accessed with stolen credentials on the morning of 7 October, and that about 1.83 million personal records leaked. About 150,000 of those records hold a name, email address, postal address, phone number or date of birth. The rest are identifiers that Nikkei says cannot identify a person on their own. No card data was involved (Nikkei notice). It was Nikkei's third breach disclosure in twelve days, after two notices on 4 October about hijacked employee accounts on Google Workspace and Microsoft 365.

Three weeks later, household goods maker Iris Ohyama said its e-commerce arm, Iris Plaza, had found a suspicious file in an external cloud service on 28 October. By 5 November the company put up to about 7.7 million people in scope: roughly 5.8 million current and former members and 1.9 million non-members. Card data was not stored in that cloud service. The online store is still offline (Netshop Tantosha Forum, BleepingComputer).

A note on the headline number: some summaries of the Nikkei incident read "18M records". Nikkei's own notice says 約183万件, about 1.83 million, and we use that figure.

Neither company has named its cloud provider, and neither has published a full root cause. Both reported to Japan's Personal Information Protection Commission (PPC) within days. Both fit a pattern that has run through Japanese corporate incidents all year: a credential or an external service, not an exotic exploit, opened the door. This post sets out what is confirmed, what is only reported, what Japanese law requires next, and what readers, shoppers and security teams can do this week.

At a glance

Nikkei: three disclosures in twelve days

Nikkei is a business news and financial information group. It publishes The Nikkei, owns the Financial Times, and reports more than 10,100 employees and annual revenue of about ¥393.8 billion, according to BleepingComputer. It also holds a large pool of reader and subscriber data, which is what makes the third disclosure the one that matters most.

The three October notices describe three different entry points. Read together, they show an organisation under sustained pressure on its identity layer.

Disclosure 1: a Google Workspace account, open since late July

On 4 October, Nikkei said a Google Workspace account that one employee used for work had been logged into from outside "since late July" (7月下旬以降). The company learned of it in early August through a notification from Google. It changed the password at once and says it has seen no unauthorized logins since. Information on 1,646 people, such as names and email addresses, may have leaked. Nikkei says the affected people are employees and business partners, and that the data does not include readers or interview sources. It reported the matter to the PPC (Nikkei notice 1547).

Note that the provider spotted the problem, not Nikkei, and that late July to early August is a dwell time of one to two weeks on a mailbox.

Disclosure 2: a Microsoft 365 account used to send about 9,000 spoofed emails

The same day, Nikkei published a second notice. An employee's Microsoft 365 account had "likely" been logged into without authorization, and on 30 September it sent about 9,000 impersonation emails to staff and to outside contacts, including news sources. Some emails pointed to malicious websites. Nikkei changed the password, contacted recipients one by one and asked them to delete the messages, and reported to the PPC. Names, email addresses and parts of some emails may have been exposed. Nikkei warned that more emails impersonating Nikkei or group staff may follow (Nikkei notice 1554, BleepingComputer).

A trusted newsroom mailbox that emails its own sources is a strong phishing platform. Recipients expect mail from that address. Some of them are the people a journalist protects.

Nikkei has not said whether the two account takeovers are linked, and it has not named an attacker.

Disclosure 3: about 1.83 million records from a development cloud

On 16 October came the larger notice. In Nikkei's words, "a cloud service that Nikkei uses for system development was accessed without authorization, and as of the 16th about 1.83 million items of personal information leaked" (日本経済新聞社がシステム開発に利用するクラウドサービスが不正アクセスを受け、16日時点で約183万件の個人情報が漏洩しました). The access happened in the early morning to morning of 7 October. The credentials used to reach the cloud service "were stolen by some means" (認証情報が何らかの手段で窃取されました). Nikkei has since invalidated them (Nikkei notice 1561).

The breakdown, from the notice:

• About 150,000 records contain at least one of name, email address, postal address, phone number or date of birth.
• About 120,000 of those include an email address.
• About 1.68 million records contain only identifiers that, in Nikkei's words, cannot identify an individual on their own.
• No credit card information is included.

Nikkei reported to the PPC on 11 October, four days after the access. As of 16 October it had not confirmed any secondary harm, and it had seen no system shutdown or data tampering. It will notify affected people individually and is still investigating scope and cause.

The PHP footnote

Two short updates were added to the same notice. On 23 October, Nikkei wrote that "following the confirmation of a vulnerability in the programming language PHP, the inquiry form has been changed" (プログラム言語「PHP」に脆弱性が確認されたことを受け、お問い合わせフォームを変更しております). On 26 October it said the maintenance was complete and the normal inquiry form had reopened.

Nikkei does not say the PHP issue is connected to the breach, and we do not suggest it is. The lesson is ordinary: the form affected people use to contact the company needed emergency maintenance mid-incident. Your incident response plan has a public-facing component, and it needs the same patch discipline as everything else.

What Nikkei has not said

As of its latest update, Nikkei has not disclosed:

• which cloud service it was, or which provider runs it;
• how the credentials were stolen (phishing, malware on a device, reuse, a leaked configuration file or something else);
• whether the October account takeovers and the development cloud access are related;
• what the 1.68 million identifier-only records are, or whether they can be joined to other datasets;
• why personal data sat in a development service at all.

The last question is the one every security team reading this should ask about its own estate.

Why a development environment held personal data

Development and test systems collect production data for understandable reasons. Developers want realistic records to reproduce a bug. A migration needs a full copy to rehearse. An analytics prototype needs real volumes. The copy gets made once and nobody deletes it.

Those environments then tend to sit under weaker controls than production. Fewer people review access. Long-lived service credentials get shared in team chats or committed to configuration. Monitoring is thinner because "it is only dev". When an attacker holds a working credential, the environment's label does not matter. The data is the data.

Nikkei's notice does not tell us whether this is what happened. It does tell us the target was a cloud service used for system development, and that it held identifying data on about 150,000 people. That alone is a lesson.

The repeat pattern

These are not Nikkei's first incidents. In November 2025, Nikkei said its Slack workspace had been compromised using credentials stolen after malware infected an employee's computer. Names, email addresses and chat histories of 17,368 registered users were exposed. Nikkei said that data fell outside mandatory reporting under Japan's personal information law but notified the PPC voluntarily (BleepingComputer, November 2025). BleepingComputer also records a May 2022 ransomware attack on Nikkei's Singapore subsidiary and a September 2019 business email compromise at Nikkei America that cost about $29 million.

Each event has a different technical story. The common thread is identity. A password, a session or a mailbox in the wrong hands, used to reach a service the organisation does not fully watch. We come back to what repeat breaches mean for a security programme later in this post.

Iris Ohyama: 7.7 million people and a suspicious file in an external cloud

Iris Ohyama is a large Japanese maker of household goods and appliances. Iris Plaza is the group company that runs its own online store, with related brands such as SIMPLE STYLE. Iris Tech Service runs appliance subscriptions and delivery and installation services.

We could not open the company's notices directly; the site returned an access error to our tools. The facts below come from the notice text as reported and translated by Netshop Tantosha Forum (Impress), Security Affairs, BleepingComputer and NHK, and they agree with each other on every point we use.

Timeline

• 28 October 2026. Iris Plaza found a suspicious file in an external cloud service it used. It suspended the Iris Plaza site and related systems and investigated, then confirmed unauthorized access by a third party. SIMPLE STYLE and the Iris Tech Service sites were suspended the same day as a precaution.
• 29 October. First public notice. NHK reported that evening that the company had confirmed unauthorized access to its online shop and stopped the site "to secure the safety of users" (利用者の安全確保のためにサイトを一時停止した). The company reported to the police and the PPC the same day.
• 5 November. Update: data stored in the external cloud service may have leaked, covering up to about 7.7 million people. The actual number is still under investigation.

The gap between finding the file and telling regulators was one day. That is fast by any standard.

Who and what is in scope

Former members' passwords are not included. Some items, including passwords, were stored encrypted. Card data was not kept in the affected cloud service, and the company says it was not affected. As of 5 November there were no reports of fraud or financial loss. No unauthorized access was found at SIMPLE STYLE, Iris Tech Service, or the Iris Plaza stores on Rakuten Ichiba, Yahoo! Shopping and au PAY Market, which kept trading.

Security Affairs makes a point worth repeating: 7.7 million is the number of people whose data was stored in the affected cloud service, not a confirmed count of stolen records. Some outlets have reported it as stolen. The company's own wording is "may have leaked" while the investigation continues.

"Encrypted" passwords: the question to ask next

The notice says passwords were encrypted. It does not say how. That matters a great deal.

If "encrypted" means a modern, salted, slow password hash such as bcrypt, scrypt or Argon2, an attacker who copied the file has a slow and expensive job ahead. If it means reversible encryption, the question becomes where the key lived. If the key sat in the same cloud account, the protection is thin. If it means an old fast hash, common passwords fall quickly.

This is why the company's advice to change reused passwords is right whatever the answer turns out to be. Shoppers should not wait to find out.

What is still open

• Which external cloud service was involved, and whether the cause was a stolen credential, a misconfigured storage permission, a vulnerable integration or something else.
• What the "suspicious file" was: a staging file left by an attacker, an export, or a tool.
• The exact password storage scheme.
• When the attacker first gained access, and how long they stayed.
• Whether anyone has made a ransom demand. BleepingComputer reports the company has had no direct contact from the attacker and has not identified who it is.
• When Iris Plaza will reopen. The company says it will restart after it has identified the cause and put prevention measures in place.

The business cost of a store that stays dark

Iris Plaza's own store has been closed since 28 October. Orders already placed are being prepared, some with delays. Customers who want to cancel must contact the company, and are told to refuse delivery if a cancelled item ships anyway. Affected customers will be contacted individually, mainly by email, once the investigation allows (Netshop Tantosha Forum).

Closing the store was the safe call, and it shows how a data incident in a supporting cloud service becomes a revenue incident for the main channel. The marketplace storefronts kept trading because they did not depend on the affected service. Know those dependencies before something goes wrong.

The wider picture: Japanese companies in 2026

Japan's IPA had already flagged these risks. Its annual "10 Major Information Security Threats" for organisations, published on 29 January 2026, ranks ransomware first, attacks on supply chains and contractors second, and AI-related cyber risk third, a new entry this year. Exploitation of system vulnerabilities is fourth and business email compromise is tenth (IPA).

The year has borne that out. Here is a short, sourced selection of large corporate incidents. Figures are the companies' own unless marked as reported.

Asahi Group: a 2025 attack whose bill arrived in 2026

Asahi disclosed a "system failure caused by a cyberattack" on 29 September 2025 that stopped ordering, shipping and call centres in Japan. The Qilin ransomware group claimed it and said it took about 27 GB of files. Asahi later said data on about 1.9 million people may have been exposed, most of them (1.525 million) people who had contacted customer service, plus employees, their families and external contacts. The entry point, as reported, was compromised network equipment at a group data centre facility in Japan, with ransomware deployed the same day (The Register).

The cost showed up in 2026. In March, Asahi estimated the attack cost about ¥5 billion in revenue and ¥2 billion in profit, and said it had refused to pay. Its CEO said that paying would not guarantee full restoration. The company moved to a phased restoration and continuous monitoring (BeverageDaily).

Aflac Japan: 4.38 million customers

Aflac Life Insurance Japan found on 25 June 2026 that an unauthorized third party had accessed certain systems between 15 and 25 June. In the parent company's SEC filing, Aflac said "certain impacted files contain policy and coverage details, personal information, and bank account information", that it notified the Japan Financial Services Agency and other authorities, and that the incident "is limited to systems in Japan" (Aflac Form 8-K). Aflac Japan's FAQ put the number of affected customers at 4.38 million (BleepingComputer). The affected systems include the customer website Aflac Yoriso Net, according to Security Affairs. MLex reported that bank account details were involved for about 230,000 customers; we have not seen that figure in a company document.

Nidec: ransomware at a Taiwanese subsidiary

Nidec said ransomware damage was confirmed on 22 June 2026 on part of a server at Nidec Chaun Choung Technology, its Taiwanese subsidiary, and that it shut down the affected server and network. The Blackfield group claimed the attack and, as reported, asked for $2 million to delete the data, $400,000 for an immediate download link and $5,000 per day to extend its deadline (BleepingComputer). In its second report on 4 August, Nidec said forensics had found "no explicit evidence (e.g., logs) showing any data leak", but that part of a list of folder and file names had appeared on the attacker's site, so it was "difficult to deny possible leak" (Nidec second report).

That last sentence is a model of honest disclosure. Missing logs are not proof that nothing left.

JR East: a cloud provider's ransomware and a leak that was later ruled out

On 7 October 2026, IDC Frontier, a SoftBank subsidiary, was hit by ransomware that took its IDCF Cloud service down for hundreds of customer organisations (IBTimes UK). On 9 October JR East said an external email delivery service used for its Eki-net and Otona no Kyujitsu Club members had been partly disrupted as a result, and that email addresses and related data might have been viewed or taken. Japanese reports put JR East's upper estimate at about 1.67 million Eki-net records and 390,000 club records. Some English-language reports, which also counted View Card customers, gave about 6.09 million accounts. In a later update, JR East said the email service operator had judged that no personal data leaked (ScanNetSecurity).

This is a good reminder that early scope numbers are ceilings, not counts. It is also a fourth-party story: a rail operator affected because its email vendor ran on a cloud provider that was attacked.

The rest of the autumn

IBTimes UK collected several more reported incidents in October: car-sharing operator Times Mobility (Park24 group), where about 6.6 million accounts were affected and about 1.6 million documents such as driver's licence images were accessed; BookOff, with up to 6.43 million customers possibly affected; karaoke operator Daiichikosho, with about 8.72 million customers potentially exposed through a system run by an external contractor; and travel site Skyticket's operator Adventure, with about 14.64 million sets of personal information potentially affected. It also cites a Yomiuri Shimbun and Trend Micro count of more than 500 reported cyberattack cases in Japan in 2026. In November, furniture retailer Nitori said up to 37.62 million records may have leaked after access that likely began in mid-October (BleepingComputer).

Put the list side by side and the shape is clear. Retail, travel, insurance, media, manufacturing and transport. Loyalty and e-commerce databases with names, addresses, phone numbers and birth dates. Contractors, email vendors and cloud services in the path. Very few of these stories involve a novel exploit. Most involve someone else's system or someone's password.

What APPI requires after a breach

Japan's Act on the Protection of Personal Information (APPI) is the law that governs both incidents. The PPC administers it. Here is what it asks of a company in Nikkei's or Iris Ohyama's position, with the official sources. Only the Japanese text has legal effect; the English translations are for reference.

When a report to the PPC is required

Article 26(1) of the APPI requires a business to report "leaks, loss or damage and other situations concerning the security of the personal data they handle" to the PPC, as prescribed by Commission rules (APPI, English translation). The PPC's guidance lists the cases that trigger a report for private businesses (PPC leak reporting page):

1. personal data that includes special care-required information, such as medical or criminal record data;
2. personal data whose misuse could cause financial damage, such as card numbers or login credentials for services that handle payments;
3. a leak that may have been carried out with a wrongful purpose, which covers external attackers and insiders;
4. a leak involving more than 1,000 people.

A leak "or the possibility of one" counts. Both incidents in this post meet at least the third and fourth tests on the facts disclosed.

The clocks

The PPC page sets two deadlines from the day the company becomes aware:

• Preliminary report: promptly, within 3 to 5 days of discovery (発覚日から、3〜5日以内).
• Final report: within 30 days of discovery, extended to 60 days where the leak may have been carried out with a wrongful purpose (不正な目的で行われたおそれがある場合は、発覚日から、60日以内).

For ransomware and other cyberattacks, the PPC accepts a joint Excel reporting format by email. Where My Number data is or may be involved, a specific form applies.

Measured against these clocks, both companies moved quickly. Nikkei reported on 11 October, four days after the access on 7 October. Iris Ohyama reported on 29 October, one day after it found the suspicious file. Because both cases involve unauthorized access, the 60-day window for the final report applies to each.

Notifying the people affected

Article 26(2) requires the business to notify the people affected. The exception is where notifying them "is difficult", in which case the business must take necessary alternative measures to protect them, such as a public notice (APPI). Both companies have said they will contact affected people individually once their investigations allow.

Security controls and supervision of contractors

Two other articles bear directly on the causes in this wave. Article 23 requires a business to take "the necessary and appropriate measures for managing the security of personal data". Article 25 says that when a business entrusts the handling of personal data to someone else, it "must exercise the necessary and adequate supervision over the person it entrusts" (APPI). An external cloud service that stores customer records sits squarely inside that duty. So does an email delivery vendor or a contractor that runs a membership system.

Enforcement today, and what changes

Under Article 148, the PPC can recommend that a business stop or correct a violation, order it to comply if it does not, and in urgent cases order it directly. Violating an order can bring up to one year of imprisonment or a fine of up to ¥1 million for the individual (Article 178), and the company can be fined up to ¥100 million under the dual liability provision (Article 184) (APPI).

The law is changing. An amendment passed the Diet on 10 July 2026 and was promulgated on 17 July 2026 as Act No. 56 of 2026. It introduces an administrative surcharge for certain serious violations where the company received money for the conduct, failed to take reasonable care, caused significant harm and affected more than 1,000 people. The surcharge provisions start on a date set by Cabinet Order, no later than 17 July 2028, while tougher criminal penalties start on 17 January 2027. The amendment also allows the PPC to exempt low-risk breaches from direct notification to individuals where other protective steps are taken (A&O Shearman).

The surcharge targets profit-driven misuse rather than being breached. Still, "failed to exercise reasonable care" is the kind of phrase a company does not want examined after its third incident in a month. A documented, working security programme is the best answer to it.

Lesson 1: cloud credentials are the perimeter

Nikkei's largest incident started with a stolen credential for a cloud service. Its two account takeovers in October, and its Slack incident in 2025, also began with access to an identity. This is not unusual. Verizon's 2025 Data Breach Investigations Report found that "credential abuse (22%) and exploitation of vulnerabilities (20%) continue to be the leading initial attack vectors" (Verizon).

A credential for a SaaS or cloud service is different from a network login in three ways that matter:

• It works from anywhere. No VPN, no office network. If the service accepts the password or token from any IP address, an attacker in another country is one request away.
• It is often non-human. Development services run on API keys, service account keys and personal access tokens that do not expire, are not covered by MFA, and are shared across a team.
• It is quiet. A valid login looks like a valid login. The signal is in context: a new location, a new client, an unusual volume of reads.

The cloud security best practice sheets published in March 2024 are a useful checklist here, especially the ones on cloud identity and access management and on securing data in the cloud. Phishing-resistant MFA for people, short-lived and scoped credentials for machines, conditional access, and logging that someone actually reads.

Nikkei's 2025 Slack incident came from credentials taken by malware on an employee's computer. One infected endpoint can open every SaaS service that person uses.

Lesson 2: development environments are production for an attacker

The Nikkei notice is specific: the service was one "used for system development". It still held identifying data on about 150,000 people and 1.68 million identifier records.

Treat any environment that holds real personal data as production, whatever its name. In practice:

• Use synthetic or masked data by default. Generate test data, or mask and tokenise copies so that a leak of a dev dataset is a non-event.
• Put an expiry on every copy. A production extract made for a migration rehearsal should delete itself after a set period unless someone renews it.
• Give dev the same identity controls as prod. SSO, MFA, short-lived credentials and access reviews. The weakest environment sets the bar.
• Inventory where personal data lives. You cannot protect, minimise or notify on data you did not know you had.

The "identifiers only" category deserves care too. An identifier that cannot identify a person alone can often be joined to another dataset that can, and APPI's definition of personal information already covers data that can be readily collated with other information to identify someone. Nikkei's split is a reasonable first cut, not a reason to relax.

Lesson 3: external cloud services drift out of view

Iris Plaza's data sat in "an external cloud service". We do not know which service or what went wrong. We do know the general patterns from many incidents: a storage bucket or share with permissions wider than intended, a long-lived access key in a script or integration, an administrator account without MFA, a third-party tool connected with broad scopes and then forgotten.

Each is a configuration problem that stays invisible unless someone looks. Practical controls:

• Keep an inventory of every external service that stores customer data, with a named owner, the data categories it holds, and how it is accessed.
• Check public and cross-account exposure continuously, not once a year. Storage permissions change with every new integration.
• Alert on bulk reads and exports. A query that returns millions of member rows should be rare enough to page someone.
• Place canary records in each customer database and external store. If a fake customer receives an email at a unique address, you know the data has left.

The JR East case adds the fourth-party layer. Your email vendor's hosting provider is part of your attack surface. You will not control it, but you can ask about it, and you can design for its failure.

Lesson 4: repeat breaches are a programme problem

Three disclosures in twelve days, following a Slack compromise a year earlier, are worth reading as a pattern rather than as separate events. They suggest that the identity and SaaS layer as a whole needs attention, not each incident on its own.

Signs that an organisation is in a repeat pattern:

• each incident is closed by resetting one password, without asking how the credential was obtained;
• the same class of entry point (mailbox, chat workspace, cloud console) shows up more than once;
• the provider, not the security team, spots the problem;
• personal data keeps turning up in places nobody listed.

Breaking the pattern takes structural moves. Enforce phishing-resistant MFA and conditional access on every SaaS and cloud console, not just email. Rotate machine credentials after every incident, including ones that look unrelated. Centralise SaaS audit logs with alerting. After each incident, ask where else the same data sits. Then report those controls to the board as measures, so the next review asks whether they work.

Lesson 5: third parties are now in most of the story

Verizon's 2025 report also found that "third-party involvement in breaches has doubled to 30%" (Verizon). Iris Plaza's external cloud service, JR East's email vendor and Daiichikosho's external contractor all sit in that category. APPI Article 25 already puts supervision of those parties on the company that entrusts them with data.

Supervision means more than a signed contract. It means knowing which vendors hold which fields, getting evidence of their controls, monitoring changes in their risk, and having a breach notice clause short enough to let you meet your own 3 to 5 day clock.

What customers should do

If you are a Nikkei reader, subscriber or contact

1. Expect an individual notice if your data was in the 1.83 million records. Nikkei says it will contact affected people directly.
2. Treat emails that appear to come from Nikkei staff with care. Nikkei itself warned that impersonation emails may increase. Do not click links in unexpected mail; go to the site directly.
3. If you received one of the roughly 9,000 emails sent on 30 September and clicked a link, change the password for any account you entered there and run a malware scan on that device.
4. Use Nikkei's official inquiry form on its support site for questions. The form was changed during PHP maintenance in late October and the normal form has since reopened.

If you have ever bought from Iris Plaza

1. Change your password anywhere you reused your Iris Plaza password. Do this now, whatever the encryption scheme turns out to be.
2. Be wary of contact that claims to be from Iris Ohyama, Iris Plaza or the authorities. The company says it will never ask for your password, PIN or authentication code when it contacts you, as quoted by Security Affairs.
3. Watch for parcel and refund scams. Name, address and phone number are enough for a convincing "delivery problem" text or call about a real order.
4. If you placed an order you want to cancel, contact the company's inquiry window, and refuse delivery if the item arrives after you cancelled.
5. Turn on MFA for your email account. Your email is the reset path for everything else.

For anyone in Japan this autumn

With so many companies reporting incidents, assume scammers know your name, address, phone and email. Use unique passwords and passkeys where offered, and be most suspicious of messages that know something real about you.

Fix it without waiting for upstream

You cannot see inside Nikkei's or Iris Ohyama's investigations, and you cannot make a cloud provider or vendor finish faster. You can shrink your own exposure today. None of these steps needs anyone else's cooperation.

1. Rotate the keys to every external store of personal data. Cloud storage access keys, database passwords, API tokens for e-commerce, CRM and email delivery services. Start with anything older than 90 days.
2. Revoke OAuth grants nobody can explain in your identity provider, Google Workspace or Microsoft 365 tenant, and chat workspace.
3. Block sign-in from unexpected countries on admin consoles where the provider supports conditional access or IP allowlists.
4. Close public links and broad shares. Search your cloud storage and file sharing for "anyone with the link" and public bucket policies on folders that hold exports.
5. Delete stale exports. Old CSVs of members, orders and campaign entrants sitting in shared drives and buckets are breach material with no business value.
6. Mask the dev copy. If a development or test database holds real customer data, replace names, emails, phones and birth dates with synthetic values today, even if a full data programme comes later.
7. Add canary customers with unique email addresses to each customer store, and watch those inboxes.
8. Pre-write the notices. Draft the PPC preliminary report fields, the customer notice and a scam warning now, so a real incident starts on day one rather than day three.
9. Brief your contact centre. Leaked order and address data drives pretext calls. Give agents a script, and require verification before changing delivery addresses or payment details.
10. Ask your top ten data-holding vendors three questions this week: what is your breach notice deadline to us, which sub-processors and cloud providers hold our data, and when did you last rotate the credentials your staff use to reach it?

Every one of these steps helps whether or not the root causes of these two incidents are ever published.

How Safeguard helps with this class of problem

Nikkei and Iris Ohyama disclosed these incidents themselves, and Safeguard played no part in finding them. Our part is to help teams manage the vendor, software and compliance risk that incidents like these expose. These are the generally available capabilities that map to the lessons above.

Third-Party Risk Manager (TPRM). TPRM keeps your vendor list in one place with owners, risk tiers and contracts, and lets you request SBOMs, projects or product evidence from vendors and track each request. Each vendor gets a risk score, and continuous monitoring flags changes such as new critical vulnerabilities or known-exploited components in what they ship to you. That turns APPI Article 25 "supervision" from an annual questionnaire into a running view.

Compliance automation. The compliance suite brings frameworks, controls, evidence, monitoring, questionnaires, risks and vendors into one workspace. Teams use it to map controls and collect evidence for SOC 2, ISO/IEC 27001 and GDPR, including the access control, logging and supplier controls this post discusses, and to keep that evidence current between audits. Safeguard is itself SOC 2 Type I and Type II audited, so we answer the same vendor questions we suggest you ask.

SCA and SBOM monitoring. Safeguard generates and analyses SBOMs in SPDX and CycloneDX and enriches vulnerabilities with EPSS and CISA KEV data. When a component in your own applications, or in a vendor's SBOM, becomes known-exploited, it moves to the top of the queue, and you can answer "where do we run this?" in minutes. A web stack like the PHP runtime behind a public inquiry form is exactly the kind of component worth tracking this way.

DAST. First-party dynamic testing of verified targets lets you scan the public web forms, contact pages and storefront flows that attackers and incident traffic both hit, so known weaknesses are found and fixed on your schedule.

Policies and gates. You can write organisation-wide policies, including from plain-English prompts, and enforce them at build, CI and release with actions to block, warn, notify or require approval. Examples: no release with a known-exploited component, or no deployment without an approved owner and data classification.

Asset discovery. Asset discovery inventories repositories, images, packages, SBOMs, vendors and workloads and applies guardrails to what it finds, so your list of systems starts from what is connected rather than from what someone remembers.

Package Firewall. For development teams, Package Firewall sits in front of package installs and blocks malicious, typosquatted and dependency-confusion packages before they reach a developer's machine or a build. That protects the same developer environments and credentials this wave shows attackers are after.

AI gateway and Guard. Where teams send customer data to AI tools or run AI agents against internal systems, the AI gateway and Guard runtime guardrails apply policies to prompts and outputs, including PII egress rules, so personal data does not leave through a new channel while you are closing the old ones.

You can see the platform at https://safeguard.sh.

FAQ

How many records were exposed in the Nikkei breach?

Nikkei says about 1.83 million personal records leaked from a cloud service it uses for system development. About 150,000 records include a name, email, address, phone number or date of birth, and about 120,000 of those include an email address. The other 1.68 million are identifiers that Nikkei says cannot identify a person on their own. The "18M" figure seen in some headlines is wrong.

How did attackers get into Nikkei's systems?

For the largest incident, Nikkei says attackers used stolen credentials for the development cloud service on the morning of 7 October 2026. It has not said how the credentials were stolen. Its two earlier October disclosures involved unauthorized logins to an employee's Google Workspace account and an employee's Microsoft 365 account.

Was payment card data stolen from Nikkei or Iris Ohyama?

No, according to both companies. Nikkei says no credit card information was included. Iris Ohyama says card data was not stored in the affected cloud service and was not affected.

How many people are affected by the Iris Ohyama breach?

Up to about 7.7 million: roughly 5.8 million current and former Iris Plaza members and 1.9 million non-members such as guest buyers and campaign entrants. That is the number of people whose data was stored in the affected cloud service. The company is still working out how many records were actually taken.

Which cloud provider was involved?

Neither company has named one. Nikkei describes "a cloud service used for system development", and Iris Ohyama describes "an external cloud service". We do not speculate on the provider.

Were Iris Plaza passwords exposed?

Member records may include passwords, which the company says were stored encrypted. Former members' passwords are not included. The encryption scheme has not been disclosed, so anyone who reused an Iris Plaza password elsewhere should change it now.

What does Japan's APPI require after a breach like these?

A report to the Personal Information Protection Commission when the leak involves sensitive data, risk of financial harm, a possible wrongful purpose such as an attack, or more than 1,000 people. The preliminary report is due within 3 to 5 days of discovery and the final report within 30 days, or 60 days for attacks. Affected people must be notified unless that is difficult, in which case alternative measures are required.

Did Nikkei and Iris Ohyama report on time?

On the published dates, yes. Nikkei reported to the PPC on 11 October, four days after the 7 October access. Iris Ohyama reported to the PPC and police on 29 October, one day after finding the suspicious file.

How does Safeguard help with this kind of risk?

Safeguard's generally available TPRM, compliance automation, SCA and SBOM monitoring with KEV enrichment, DAST, policies and gates, asset discovery, Package Firewall and AI guardrails help teams supervise vendors, keep evidence current and reduce exposure across their software and suppliers. Both incidents were disclosed by the companies themselves.

Sources

Primary: Nikkei notices 1547, 1554 and 1561; Iris Ohyama notices of 29 October and 5 November (as reported); Aflac Form 8-K; Nidec second report; APPI, English translation; PPC leak reporting guidance; IPA 10 Major Threats 2026; Cloud security best practice sheets, March 2024; Verizon 2025 DBIR release. Press reporting is linked inline where it is used.