One VPN, and a Company's Financial Close Stopped: How a Cyberattack Halts Securities Filings, and How to Defend

A listed company could not file its financial statements on time. It was not negligence. The company's own numbers had been encrypted — held hostage — by an attacker who got in through a single VPN appliance.

And that same entry point may be quietly ajar on your company's network right now. The March 2026 cyberattack on Japanese textile maker Omikenshi drew a straight line from a network entry point (a VPN) to the shutdown of core systems (the backbone that runs ordering, accounting, and more) and, ultimately, to a delay in filing its annual securities report (a listed company's yearly "report card" of results, submitted to regulators) — the extraordinary situation of "a company's financial close grinding to a halt." Using that incident as an entry point, this article works through two more universal questions — "how do you prevent VPN-based intrusion?" and "why does a cyberattack stop you from closing the books and filing financial reports?" — from a hands-on infrastructure and security perspective. So it reaches not only fellow engineers but also IT managers and executives worried about their own networks, every technical term comes with a one-line plain explanation.

What happened — one VPN, a halted core system, and a derailed financial close

First, the facts in order. This is the most vivid part of the article. Note that the following is based on news reports and the company's disclosures, and some details about the attack path and the perpetrator are not yet officially confirmed. Those points are flagged.

The key point is that this was not a one-night outage. From the mid-March intrusion, the shutdown of the core systems (the backbone that runs ordering, production, and accounting) dragged on until the company could no longer meet the deadline for its annual securities report (normally three months after fiscal year-end, i.e. June 30) and applied to extend it to September 30. In other words, a single cyberattack has been shaking the company's foundations for nearly half a year. That one point — "they got in through the VPN" — produces this whole chain, and the real subject of this article is the structure of that chain.

Ransomware (extortion malware that encrypts your files and demands money for the key) no longer ends at one company's data leak. Business stops, the financial close stops, and it ripples all the way to a listed company's disclosure obligations. From here we break down that chain in order: why the financial close stops, why the VPN becomes the entry point, why one device spreads to the whole company, and what to do about it.

Why a cyberattack stops you from closing the books and filing a securities report

This is where most people get stuck: why do "an IT outage" and "a securities report" belong in the same sentence? Surface news never explains it, yet this intersection is the heart of the incident.

The financial close rests on ledger data

Closing the books means finalizing a year of money movements into correct figures. The source of those figures is the ledger data and vouchers (the records that prove each transaction) inside the accounting or ERP system (the system that centrally manages a company's business data). Ransomware encrypts that very data. Suddenly the basis for confirming sales, inventory, and receivables collapses, and the raw material for computing "how much did we earn this period" is out of reach. The close stops not because staff slacked off, but because the source data is held hostage.

If the auditor "can't verify," disclosure can't move forward

A listed company's figures can only go public after an independent audit firm checks them against the actual transaction data. If that source data is encrypted and unreadable, the auditor cannot conclude "these numbers are correct." So both the company's close and its audit stall on the same data outage — which is why disclosure slips further the longer recovery takes (weeks to months).

The deadline is set by law — hence the "extension application"

The annual securities report is a document companies must file with Japan's Financial Services Agency (FSA) to protect investors. The governing law, the Financial Instruments and Exchange Act, sets the deadline at "within three months after fiscal year-end." However, when there is an "unavoidable reason," filing may be delayed within a period approved by the authorities. During COVID-19, the FSA even granted a blanket extension, and approved companies are published in the FSA's extension list. This filing extension follows that same mechanism. Everything is filed through EDINET (the FSA's electronic disclosure system).

So "a cyberattack means you can't file" works like this: core system encrypted → ledger data unreachable → financial figures can't be finalized → audit can't be completed → the legal deadline (June 30) is missed → an extension is applied for under the law (September 30). A single IT accident slides along the rails of the legal system all the way to a disclosure obligation. This is the "heart" of the story that no other coverage explained carefully.

Why the VPN becomes the entry point — why VPNs and ransomware go together

Now to the first universal theme: how to prevent VPN-based intrusion. A VPN (Virtual Private Network — a virtual tunnel for safely entering the corporate network from outside), especially a browser-based SSL-VPN, is by nature a device that keeps an "entry door" open to the internet at all times. It spread to every company with remote work — but to an attacker it looks like an authentication gate open to all.

Crucially, in the Omikenshi case the specific product and vulnerability (CVE) used for entry have not been disclosed (the company says intrusion is "highly likely via VPN" and the external investigation continues). So this article does not pin down any specific CVE. Instead it presents a "structural fact" that needs no such assertion: how continuously and how heavily VPN device vulnerabilities have actually been used in real attacks.

Structural fact #1: VPN CVEs are "actively exploited," repeatedly

The U.S. agency CISA publishes a catalog (KEV) of only those vulnerabilities confirmed to be exploited in real attacks. Following it shows that network edge devices — VPNs, firewalls — are disproportionately targeted as the attacker's initial foothold. Per several tallies, a large share of vulnerabilities newly classed as "used by ransomware" in 2025 concentrate on network appliances: Ivanti Connect Secure alone has over a dozen since 2024, alongside Fortinet SSL-VPN, Citrix (the so-called "CitrixBleed 2," CVE-2025-5777), Palo Alto GlobalProtect, and SonicWall. You can check which applies to your products by name in our CISA KEV dashboard (Japanese edition).

The attack pattern is consistent too: an "authentication bypass" that skips the login, paired with "remote code execution (RCE)" — a "get in and go" chain. Japan's IPA has also warned about "network-penetration attacks" that turn VPN devices into footholds. The VPN as entry point is not an accident; it is now a standard playbook.

Structural fact #2: how many such devices are "visible" in Japan right now

Attackers don't hunt for weak VPNs one by one. Using survey services that index internet-exposed devices (like Shodan or Censys, which provide a "map" of publicly reachable devices), they can mechanically narrow down "this vendor's VPN, at an unpatched generation." Attacker and defender read the same map.

The numbers make one thing plain: this is not "just a few old boxes." The ~86,000 devices whose credentials were harvested in FortiBleed in June 2026 were reported to represent a substantial share of all internet-facing Fortinet devices, and the U.S. agency CISA urged emergency hardening of Fortinet devices. Even after a critical flaw is disclosed, tens of thousands of devices worldwide stay exposed and unpatched for weeks — a pattern seen again and again in Shadowserver's observations and at Ivanti disclosures. Japan is on that map too.

What such exposure surveys make plain is simple: an unpatched VPN is visible to the whole world, and it's only a matter of when its number comes up. There is no need to assert what Omikenshi used. As long as this structure exists, the next one could be you — that is what to take away.

From one VPN to "the whole company down" — anatomy of the damage chain

If "the VPN was breached" were all, the damage might stop at one device. In reality it races to the encryption of the entire core system. Why? Here is the typical path an attacker takes (the attack chain, or kill chain), drawn as a generalized structural model. The following is not an assertion about a specific incident, but the standard flow common to ransomware attacks.

Stages ②–③ are the crux. Many corporate networks are "flat": once inside, moving sideways is easy. When all employees hang off the same Active Directory (the "family register" that centrally manages users and PCs) and admin rights are widely shared, an attacker uses one credential as a springboard for lateral movement (spreading the intrusion to neighboring servers one after another) across the whole estate. One entry device becomes a pass to the entire internal map.

And ④ is the blow that pushes damage toward "unrecoverable." Many organizations assume "we have backups, so we're fine," but attackers know this and find and destroy the backups first. If backups are always connected to the same network as production, they become hostages too. That is what makes ⑤ double extortion (not just encrypting to halt operations, but also threatening to publish stolen data unless paid) work. The disclosure that "external data transmission was confirmed on some servers" is exactly the trace of that exfiltration. A group calling itself "The Gentlemen" claimed responsibility, but sample data is unpublished and its authenticity is unclear, so this article does not assert who did it.

So your company doesn't follow the same path — a practical VPN-intrusion checklist

This is the practical core worth rereading months from now. Taking each kill-chain stage and asking "how do we cut it," here is a list ordered by impact and feasibility. You can't do everything at once — start from the top, with what you can.

Top priority (shut the entrance)

• 1.Make multi-factor authentication (MFA) mandatory on the VPN. MFA adds a second identity check (like a phone confirmation) on top of the password. Even if the password leaks, that one extra step stops most initial intrusions. It is the single most important first move.
• 2.Patch edge devices "exploited-first" (KEV priority). Rushing every patch equally is unrealistic, so use the KEV dashboard to prioritize vulnerabilities known to be actively exploited. Treat VPNs and firewalls as top tier.
• 3.Inventory and delete unused VPN and admin accounts. Dormant accounts from departed staff or testing are keys left lying by a back door. Pair regular inventory with long-term retention of access logs (records to trace the intrusion path later).

Next (limit the damage once they're in)

• 4.Segment the network and minimize privileges. Wall off core and accounting servers from the general business network (segmentation). Tight admin rights mean one stolen credential can't fuel lateral movement — a direct counter to stages ②③.
• 5.Use EDR to catch "post-intrusion" anomalies. EDR (Endpoint Detection and Response — software that detects and responds to suspicious behavior on each PC/server) is the last net for catching an attacker's lateral movement and rogue commands after the entrance is breached.
• 6.Back up with "3-2-1 + offline + restore drills." Three copies, on two media types, one kept off-site. Crucially, keep one copy disconnected from the production network (offline) — the only insurance against stage ④. And regularly test that you can actually restore. An untested restore is the same as none.

Longer term (reduce the entrance itself)

From "defend the perimeter" to "trust no one." A traditional VPN follows a "once you're in, the inside is trusted" model — the very breeding ground for lateral movement. The shift now is toward Zero Trust (verify the user and device on every access, inside or out) and its implementation, ZTNA (Zero Trust Network Access — grant only minimal, per-application connections). Instead of "opening one door and handing over the inside," you connect narrowly to just the needed app, verifying each time. A full replacement doesn't happen overnight, but this is the direction to head — the conclusion of someone who has watched the limits of perimeter defense in practice.

What executives should know — business impact and the reality of recovery

Finally, for executives, not just technical staff. A ransomware hit is no longer an IT-department problem. As this case shows, recovery runs from weeks to months, and throughout it operations, the financial close, and disclosure all stay frozen. Lost sales, shaken partner trust, accountability to shareholders and investors, and reputational damage — the cost swells far beyond any ransom.

Executives should decide at least three things in advance. First, make "we don't pay the ransom" the default and settle the decision-making path beforehand; paying guarantees no recovery, invites repeat targeting, and authorities are wary of it. Second, the sequence for disclosure and dealing with regulators; if personal data is involved, reporting duties arise, and for a listed company it reaches timely disclosure (promptly announcing material events to investors) and, as here, the deadlines of statutory filings. Third, don't let cyber insurance and business continuity planning (BCP) stay paper exercises — whether you've run the initial response, fallbacks, and contacts on the table even once in peacetime is what decides a crisis.

Security spending is often seen as a "cost with no visible return." But view this chain as one line — from a single VPN to a halted close to a delayed statutory filing — and it is clearly an investment that protects the business itself. Attackers open the weakest door at the lowest cost. Defenders, likewise, should shut it down starting from the single most effective move (first, MFA on the VPN).

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

The Omikenshi case will fade from memory as one specific incident. Whether the securities report, extended to September 30, is filed successfully, and whether the attack path is officially confirmed — we'll add follow-ups in the update log at the end. But the two questions this incident posed never go stale: "how do you prevent VPN-based intrusion?" and "why does a cyberattack stop the close and the securities report?" The former is answered by MFA, patching, segmentation, and Zero Trust; the latter by preparing for the single point of failure that is your core data. Both can be started today.

This is an era where a single VPN can hold a company's numbers hostage. So begin by adding one more lock to the entrance (multi-factor authentication). It is the surest first move to protect "your company" — which may be next in line.

FAQ

Update log

• 2026-07-14First published. Using the Omikenshi case (VPN intrusion → core system halt → securities report extension) as an entry point, we explain VPN-intrusion defense and how an attack stops the financial close.
• PlannedWe'll add the outcome of the September 30 filing, any official confirmation of the attack path, and new VPN-device CVEs added to KEV, as they become known.

References

• ▸Omikenshi cyberattack likely via VPN; ransomware group claims responsibility (Security Measures Lab, JP)
• ▸Omikenshi applies to extend securities report deadline after core-system halt (Security Measures Lab, JP)
• ▸On extending securities report deadlines (FSA, JP)
• ▸List of companies granted filing-deadline extensions (EDINET)
• ▸Warning on network-penetration attacks against VPN devices (IPA, JP)
• ▸Network appliance vulnerabilities exploited for ransomware (CyberScoop)
• ▸NVD - CVE-2025-5777 (Citrix, "CitrixBleed 2")