Japan's Active Cyber Defense Law: What It Means for Open Source and EOL Software

Japan has long been regarded as a reactive player in the global cybersecurity landscape — a nation that built robust defensive perimeters but stopped short of offensive or preemptive cyber action. That era ended on May 16, 2025, when the National Diet enacted the Active Cyber Defense Law ("ACD Law" or "ACDA"), the most consequential shift in Japan's cybersecurity posture since the Basic Act on Cybersecurity was introduced a decade earlier.

For technology leaders at companies operating in Japan's critical infrastructure sectors — or for IT vendors whose software powers that infrastructure — the ACD Law is not simply a national security story. It is an operational compliance obligation with direct implications for every layer of your software stack, including the open source components that most teams have never thought of as a regulatory liability. End-of-life open source software sits squarely in that gap.

‍

What the Active Cyber Defense Law Is — and Who It Applies To

Enacted in May 2025 and scheduled for full enforcement by 2027, the ACD Law restructures Japan's cybersecurity framework around four pillars: strengthened public-private sector collaboration, government monitoring of communications data for threat detection, authorized counter-access to neutralize attack sources, and institutional reform — most notably, the conversion of the National Center of Incident Readiness and Strategy for Cybersecurity (NISC) into the newly empowered National Cybersecurity Office (NCO) in July 2025.

The first two pillars create the most direct compliance obligations for private-sector organizations. They apply to two categories of entities:

Critical Infrastructure Operators (CIOs): Entities designated under Japan's Economic Security Promotion Act operating in 15 covered sectors — including electricity, gas, telecommunications, finance, transportation, water, healthcare, and government services. These organizations face mandatory incident reporting, new system notification requirements, and direct exposure to government-initiated vulnerability remediation requests.

IT Vendors and Software Suppliers: Manufacturers, importers, distributors, and providers of computers or software embedded in Critical Systems. While the ACD Law's obligations fall primarily on the CIO, IT vendors are indirectly exposed: if a CIO suffers a cybersecurity incident involving vendor-supplied software, the CIO may compel that vendor to cooperate in fulfilling its reporting obligations — placing the vendor's own security practices under government scrutiny.

‍

Covered Sectors and the Open Source Stack Beneath Them

SectorCovered Entity TypeTypical EOL Open Source ExposureElectricity & EnergyPower grid operators, utilitiesIndustrial control system web UIs, SCADA dashboards often built on EOL Node.js or AngularTelecommunicationsCarriers, ISPs, network infrastructure providersAPI gateways, provisioning portals, and OSS/BSS systems frequently running EOL Spring Boot or DjangoFinance & BankingBanks, securities firms, payment processorsCustomer-facing portals and internal tooling with deep Angular or React version dependenciesTransportationRailways, airlines, port operatorsScheduling and logistics platforms commonly running multiple EOL framework versionsHealthcareHospitals, medical device networksPatient management systems and device firmware interfaces with long-lived EOL Java and Python stacksGovernment / Defense SuppliersIT vendors to designated CIOsDefense software products built on open source components that predate current supported releases

Representative EOL open source exposure patterns across Japan's 15 designated critical infrastructure sectors. Actual component inventories will vary by organization.

‍

The Four ACD Law Obligations That EOL Open Source Directly Implicates

The ACD Law does not mention open source software by name. But four of its core private-sector obligations create direct, concrete exposure for any organization whose systems depend on open source frameworks that have reached end of life.

1. Critical System Notification

CIOs must notify the relevant regulatory ministry when introducing certain important systems designated as Critical Systems — those whose compromise could suspend or degrade the functions of the infrastructure services they support. This notification triggers a regulatory review of the system's security posture.

EOL open source components embedded in a Critical System cannot be patched through standard vendor channels. If a regulator or assessor identifies an EOL dependency with known, unpatched CVEs during the notification review process, the CIO faces the immediate challenge of demonstrating either a remediation path or an adequate mitigation — neither of which is straightforward when the upstream maintainer has ceased support.

2. Mandatory Incident Reporting

CIOs must report cybersecurity incidents or credible potential threats involving Critical Systems to both the relevant ministry and the Prime Minister's Office. The ACD Law grants the newly established NCO authority to promptly supervise critical infrastructure and request operators to address zero-day vulnerabilities as they emerge.

This obligation transforms the risk calculus around EOL open source in a fundamental way. Under a purely reactive security posture, an unpatched EOL component is a latent risk. Under the ACD Law's mandatory reporting regime, an incident exploiting that component becomes a regulatory event — one that exposes not just the breach itself, but the underlying failure to maintain a patched, supported software environment. Regulators reviewing an incident report that traces to an EOL framework with a known, publicly disclosed CVE will ask the obvious question: why was this vulnerability not remediated?

3. Government Vulnerability Remediation Requests

When the NCO or a competent minister identifies a vulnerability in a Critical System, the law grants authority to notify relevant IT vendors, publish remediation guidance, and formally request corrective action. While these requests are not binding obligations in the strictest legal sense, the law is clear that vendors and operators must make reasonable efforts to respond — and failure to do so invites further regulatory attention.

For EOL open source components, a government remediation request creates an untenable position: the competent authority has identified a vulnerability, formal guidance has been issued, and the organization has no upstream vendor to turn to for a patch. The only paths available are self-developed remediation, compensating controls that may not satisfy the "reasonable efforts" standard, or an accelerated migration that carries its own risk and timeline.

4. IT Vendor Cooperation in Incident Response

The ACD Law recognizes that critical infrastructure security is a supply chain problem, not just an operator problem. When a CIO is subject to an incident reporting obligation, it may formally request cooperation from the IT vendors whose software was implicated in the incident. This pulls vendors directly into the regulatory process — requiring them to provide information, documentation, and potentially corrective commitments to support the CIO's report to the government.

An IT vendor whose product contains an EOL open source dependency that contributed to the incident has limited defensible ground. The absence of a security maintenance relationship with the EOL component's maintainer signals, at minimum, a failure of supply chain risk management — and potentially a more serious liability exposure depending on the nature of the incident and the vendor's contractual obligations to the CIO.

‍

Why End-of-Life Open Source Is a Uniquely Difficult Problem Under the ACD Law

Most cybersecurity compliance frameworks assume the existence of a vendor relationship: a software supplier who issues patches, publishes advisories, and maintains a security lifecycle for its products. The ACD Law's architecture is built on the same assumption. Its vulnerability remediation request mechanism presupposes that someone is responsible for fixing identified vulnerabilities and can be asked to do so.

End-of-life open source breaks this assumption entirely. When an open source project reaches end of life, no one is responsible for security patches. The upstream maintainers have moved on. CVEs are disclosed against the EOL version, security researchers publish proof-of-concept exploits, and JPCERT/CC (Japan's national incident response team) may issue advisories — but there is no vendor to receive a remediation request from a Japanese regulatory ministry, and there is no patch coming.

This creates a structural gap between what the ACD Law's enforcement mechanisms assume and what EOL open source actually delivers. An organization running EOL dependencies in a Critical System cannot demonstrate, in response to a government vulnerability disclosure or remediation request, that a patch has been or will be applied. It can only offer compensating controls, a migration timeline, or silence.

The problem is widespread. Open source underpins virtually every layer of modern enterprise software — from web frameworks and application servers to authentication libraries and data processing pipelines. Version lifecycle windows for major frameworks commonly run 18 to 36 months. An application built three years ago and operating reliably in production may already carry four or five EOL open source dependencies. The compliance exposure under the ACD Law is not a future risk; for many organizations, it exists today.

‍

How HeroDevs Closes the Compliance Gap

HeroDevs was built to solve the specific problem that the ACD Law now makes a regulatory obligation: providing active security maintenance for open source frameworks after their upstream maintainers have discontinued support. Through its Never-Ending Support (NES) product line, HeroDevs supplies backported security patches, CVE remediation, compliance documentation, and dedicated security engineering for a broad portfolio of EOL open source frameworks — without requiring organizations to immediately migrate to a new major version.

For organizations subject to the ACD Law, NES addresses each of the four obligation areas where EOL open source creates exposure:

Critical System Notification: Systems submitted for regulatory notification that include NES-backed components can demonstrate active security maintenance, a published patch cadence, and CVE coverage. The EOL dependency is no longer an unmanaged risk; it is a documented, mitigated one with a vendor relationship attached.

Incident Prevention and Reporting: By closing known CVEs in EOL frameworks before they can be exploited, NES reduces the probability of a reportable incident originating from unsupported software. When an incident does occur in an NES-covered environment, the organization can demonstrate that reasonable efforts to maintain security were actively in place.

Vulnerability Remediation Requests: When the NCO or a competent minister identifies a vulnerability in a Critical System component covered by NES, HeroDevs functions as the vendor relationship that the government's remediation mechanism assumes. HeroDevs engineers triage the reported vulnerability, produce a backported patch, and deliver it through the same drop-in compatible package mechanism that existing deployments already use.

IT Vendor Supply Chain Accountability: Software vendors supplying products to Japanese CIOs can use HeroDevs NES to demonstrate supply chain security diligence. When a CIO requests vendor cooperation following an incident, a vendor whose open source dependencies are under active NES maintenance has a documented security posture to present — rather than an admission that EOL components were left unmanaged.

‍

ACD Law Obligation Mapping: EOL Exposure vs. NES Resolution

ACD Law ObligationEOL Open Source ExposureHow HeroDevs NES HelpsCritical System Notification — pre-deployment review of new systemsEOL open source components embedded in a Critical System must be disclosed and assessed at notification time; EOL dependencies create immediate regulatory scrutiny.NES-backed components carry active security support documentation, enabling operators to demonstrate managed, mitigated dependencies rather than unpatched EOL software.Incident Reporting Obligation — prompt reporting to ministries and PM's OfficeA breach or incident traced to an EOL open source vulnerability triggers mandatory reporting — and exposes the underlying failure to maintain a patched software environment.By closing known CVEs in EOL frameworks before they are exploited, NES reduces the likelihood of a reportable incident originating from unsupported software.Vulnerability Remediation Request — competent minister may request corrective actionGovernment-identified vulnerabilities in Critical Systems that run EOL open source have no upstream vendor patch available; operators cannot demonstrate a credible remediation path.HeroDevs produces and delivers backported security patches for EOL frameworks, giving operators a concrete remediation action to report back to regulators.Supply Chain Risk / IT Vendor Cooperation — CIOs may require vendor cooperation in incident reportingIT vendors supplying software containing EOL open source to CIOs may be drawn into incident reporting obligations when their unpatched components are implicated in an attack.Vendors using HeroDevs NES can demonstrate active security maintenance of their open source dependencies, reducing liability exposure in cooperative reporting scenarios.Zero-Day & Ongoing Threat Response — government authority to request prompt zero-day remediationEOL open source components are disproportionately targeted by zero-day researchers and threat actors; without a vendor relationship, operators have no escalation path when new exploits emerge.NES provides a dedicated security engineering team that monitors, triages, and patches EOL frameworks — functioning as the vendor relationship that EOL software no longer has.

ACD Law obligations current as of enactment (May 2025). Full enforcement expected by 2027 following phased implementation. Specific implementing regulations for each covered sector may introduce additional requirements.

‍

NES Coverage Across the Open Source Stack

HeroDevs NES covers a broad and expanding portfolio of the open source frameworks most commonly found in Japanese enterprise and critical infrastructure environments, including Angular, AngularJS, Vue 2, React, Node.js, Spring Boot, Django, Elasticsearch, and many others. For each covered framework, HeroDevs delivers drop-in compatible packages that integrate into existing codebases without requiring architectural changes — preserving the engineering investment that organizations have made in their current systems while restoring a defensible security posture.

NES customers receive security advisories, CVE tracking, patch releases, and compliance documentation artifacts — the materials an organization needs not just to fix vulnerabilities, but to demonstrate to regulators, auditors, and counterparties that security obligations are being actively met.

‍

The Implementation Window Is Narrowing

The ACD Law was enacted in May 2025 and takes full effect by 2027, with specific sector-level obligations coming into force on a phased basis as implementing regulations are finalized. That timeline may feel comfortable, but it is not. Incident reporting obligations and Critical System notification requirements apply to systems that exist today — not just to systems built after the law's full enforcement date. Organizations operating Critical Systems with EOL open source dependencies are already exposed to the ACD Law's incident reporting framework; the 2027 date marks full enforcement, not the beginning of the regime.

The window to remediate EOL open source exposure is the window between now and when a reportable incident occurs, when a Critical System notification triggers a regulatory review, or when a government vulnerability remediation request arrives. HeroDevs NES can be deployed against existing codebases without a migration, allowing organizations to close compliance gaps on a timeline that aligns with their operational realities rather than a compliance crisis.

Learn more at herodevs.com or contact HeroDevs.