The Phone Stopped, the App Kept Running: System Separation That Survives an Attack, and the First Response That Stops the Spread

You call for a taxi by phone and none comes. The registration form for the "labor taxi" (a pre-arranged ride for going into labor) is down too. And yet, from the same company's app, "GO," you could hail a taxi just as usual. What produced this split?

In the early hours of July 11, 2026, Nihon Kotsu suffered external unauthorized access (a malware infection), and phone dispatch and the labor-taxi registration form, among others, went down. Meanwhile, requests via the ride-hailing app "GO" were unaffected, and the company advised customers to "please use the GO app to book." Even under attack, only some services survived — and behind that fact lie lessons that apply to every business: how you split your systems, and what you do first when you're attacked.

Using that case as an entry point, this article works through two more universal questions — "what is the first response (network isolation) that keeps a malware infection from spreading?" and "why, at the same company, do some services go down while others survive?" — from a hands-on infrastructure-operations perspective. So it reaches both taxi riders and the people who operate systems, every technical term comes with a one-line plain explanation. Note that the intrusion path and malware details have not been disclosed and are under investigation, so this article does not assert a cause; it reads the case through the disclosed facts and general mechanisms.

What happened — phone down, app normal: what survived and what stopped

First, the disclosed facts. The following is based on Nihon Kotsu's official announcement and news reports, with no speculation about the cause.

The sequence: in the early hours of July 11, Nihon Kotsu detected that its internal systems had suffered external unauthorized access (a malware infection). To prevent the damage from spreading, it immediately cut off and isolated the internal network. As a result, phone dispatch, hire web ordering, and the labor-taxi form — all dependent on internal systems — stopped. Requests via the "GO" app, however, were unaffected, and when the company disclosed the incident on July 13, it advised "please use the GO app to book." The company is working with external specialists on cause analysis and log (records of communication and operations) review, and states that no information leakage has been confirmed at this time (all official).

Two things stand out. First, what "stopped" was less the attack itself than the result of deliberately cutting off to contain the damage. Second, even the same act of "hailing a Nihon Kotsu taxi" split into life and death by which route you took. These two points are the subject of the sections that follow.

Why phone dispatch stopped but the GO app survived — the split of system separation

This is what puzzles most people: "It's the same company's taxi, so why is the phone down but the app fine?" The answer is that the two run on separate system foundations.

Phone dispatch and hire reservations run on Nihon Kotsu's internal systems. Because the internal network was isolated to stop the infection from spreading, the phone dispatch hanging off it stopped too. "GO," on the other hand, is a ride-hailing platform operated on the separate foundation of a separate company, GO Inc. Being decoupled from Nihon Kotsu's internal systems, it kept running on its own foundation even while the internal network was isolated — that is what split the outcome.

This is a fine example of system "separation" translating directly into business resilience (toughness). If every dispatch route had ridden on one internal system, isolation would have meant "zero ways to hail a taxi." In reality, running an external platform alongside worked, in effect, as an alternate route for business continuity. Don't load everything onto one point of failure — it's the flip side of the lesson from our previous article on how a halted core system takes the whole business down.

What "isolating the network" means — the first response that stops the spread

Now to the first universal theme: the first response that keeps a malware infection from spreading. The very first thing Nihon Kotsu did was network isolation (cutting an infected device or network off from the rest of the internal network and the internet).

Why cut it off "even at the cost of stopping a service"?

Malware — especially ransomware (a type that encrypts data and demands a ransom) — spreads once one machine is infected, moving across the internal network to widen the infected area (lateral movement). The surest way to stop that fire from spreading is to cut the burning section off from the building — that is, network isolation. Isolation stops that service, but if you don't, the infection sweeps the whole company, dragging in core systems and even backups, approaching "unrecoverable." You trade a near-term outage to prevent the worst company-wide damage. It's the same structure as firefighting's "sacrifice a part to stop the spread."

The value of "stopping it early"

Nihon Kotsu isolated immediately after detection and states that "the spread was contained" and "no information leakage has been confirmed at this time" (official). It's undramatic, but this is a first response you can rate well. What's frightening about an attack is being lurked in unnoticed for days, quietly widening the infection and data theft. Whether you detect the anomaly early and cut it off without hesitation decides how big the damage gets. The investigation continues, of course, and the final scope awaits future announcements. Organizations not used to incident response can also benefit from consulting a specialist body early, such as the JPCERT Coordination Center (JPCERT/CC).

Why a "only part survives" design works — separation and redundancy

The other universal theme this case teaches is "why do only some services survive?" The answer: don't build systems as one monolith — build them split and layered.

The key idea is eliminating single points of failure — "the one spot whose failure stops everything." If all dispatch is concentrated in one internal system, the moment it's taken hostage the business goes to zero. Conversely, if you split and multiply the routes — phone, own web, external app (GO) — one can fall and you still serve customers by another. GO surviving here may not have been an intended redundancy design, but it became a fine example of "having multiple channels functioning as a business continuity plan (BCP)."

At the same time, a shadow fell on the legacy (long-standing) phone system. Phone dispatch was tightly coupled to the internal systems, so it shared their fate under isolation. "The older and more core a system, the more every function gathers there and becomes a single point of failure" — a weakness common to many businesses. Separation helps not only when building anew, but also in the direction of untangling old tight coupling.

What businesses and operations teams should learn — a separation-and-response checklist

This is the practical core worth rereading months from now. To keep an attack from taking the whole business down, here's a list ordered by impact and feasibility. Start from the top, with what you can.

• 1.Partition the network so you can "cut" on infection (segmentation). Don't make the internals one flat network; divide it into sections by department or system. Only with partitions can you quickly isolate just the affected section.
• 2.Multiply the routes for critical services. Don't concentrate "stops-the-business-if-down" functions like ordering and reservations in one mechanism. As with GO here, running an external platform alongside is a realistic alternate route.
• 3.Decide the incident "decision rules" in advance. Document in peacetime "on which signs, by whose authority, how far do we cut off." Whether you can cut without hesitation at 3 a.m. in a crisis decides the damage.
• 4.Keep and monitor logs (records of communication and operations). Records to detect intrusion early and trace the path afterward support both fast response and cause analysis. EDR (software that detects and responds to suspicious behavior on each device) is effective too.
• 5.Keep backups separated from production. If the infection reaches backups, you can't recover. Keep one copy isolated from the production network (offline), and test regularly that you can restore — insurance that pairs with isolation.
• 6.Don't forget entrance defenses. To reduce intrusion in the first place, keep up multi-factor authentication (a second identity check beyond the password) and patching on internet-facing devices. See our explainer on VPN-based intrusion and defense.

At the root is the philosophy of "a build that doesn't all fall at once." You can't reduce attacks to zero. That's why holding a two-stage stance as a design — stop the spread even if breached (isolation), serve customers even if part falls (redundancy) — is the conclusion of someone who has watched outages in practice.

What users should do — keep an alternate means

Finally, for taxi riders. For this case, you can still use taxis fine via the "GO" app, or by taxi stands and hailing a passing empty cab. There's no need to panic just because the phone line won't connect.

As a more general mindset, it's worth holding the idea that life's infrastructure should "assume one means will fail, and keep an alternate ready." As here, the phone can be down while the app still works; conversely, when the app has an outage, the phone or a taxi stand may be alive. Especially for something like a labor taxi — "reliably needed when it matters" — don't narrow your registration to one place; keep same-day contact options (your clinic's number, several taxi companies or apps) on hand. Rather than blaming one company or app, holding multiple means is the most realistic preparation for outages like this.

Conclusion — the incident is the "entrance," the lesson is the asset

The Nihon Kotsu case will fade as an individual news item. But the two lessons it showed don't go stale: "network isolation, the first response that stops the spread," and "separation and redundancy so part can fall without taking down the business." The former rests on the runbook that supports the "courage to stop"; the latter on the daily design of eliminating single points of failure — both can be started today.

The phone stopped, but the app kept running. This small split points to how business should be built going forward. You can't reduce attacks to zero. Then stop the spread even if breached, and don't let all of it fall even if part does — building that into your design is the first move toward the next "business that doesn't stop."

FAQ

Update log

• 2026-07-14First published. Using Nihon Kotsu's service outage from unauthorized access (malware infection) as an entry point, we explain the first response of network isolation and the design of system separation and redundancy.
• PlannedWe'll add follow-ups on recovery status, the cause and intrusion path, and the final announcement on whether information leaked, as they emerge.

References

• ▸Apology and report on system stoppage due to unauthorized access (Nihon Kotsu, official, JP)
• ▸Temporary suspension of input forms due to the system failure (Nihon Kotsu, official, JP)
• ▸Nihon Kotsu hit by unauthorized access; phone dispatch down, GO unaffected (ITmedia NEWS, JP)
• ▸Nihon Kotsu system stoppage from malware infection and unauthorized access (Security Measures Lab, JP)