Holding a security certificate and being able to repel a cyberattack on the power system are two different things. JC-STAR★1 is a self-declared check of sixteen functional requirements on a single device. IPA, which runs the label, told us in writing that the label "does not mean the product is securely installed and operated" and that the scheme "does not adopt the concept of boundary defence". Auditing the manufacturing process or the country of manufacture does not close the operational-stage entry points: cloud control planes, update distribution, administrator accounts, and vulnerabilities disclosed after certification. The attacker does not even need to be involved in manufacturing. No protective effect of the ★1 requirement against these paths has been demonstrated, and its effectiveness is doubtful. This article documents the basis for that judgement with public primary sources and a reproducible model, and states the conditions under which it would be refuted.
Video explainer (about 9 minutes; ja / en / zh)
Executive summary
Conclusion. Making JC-STAR★1 a necessary condition for grid interconnection has no demonstrated protective effect against the attack paths that are actually being used: compromise of cloud control planes, of update servers and signing keys, of legitimate administrator accounts, vulnerabilities disclosed after certification, and remote attacks pivoting through third-country infrastructure. Its effectiveness is doubtful. This is not proof that it has no effect. It is a finding that the designers of the requirement have not shown the basis for one.
- ★1 looks at one device. The scope is the IoT device plus its essential accompanying services; "systems" are out of scope. The sixteen requirements are self-declared; IPA does not verify conformity. Validity is two years. Contact through the supply chain is explicitly "not assumed" as an attack surface [J02]. IPA told us that "label obtained" does not mean "securely installed and operated" and that "the concept of boundary defence has not been adopted" [J05].
- Country of manufacture tells you nothing about the attacker. Russian APT28 malware queried the Chinese model Qwen2.5-Coder [A02]; a campaign Anthropic attributes to the Chinese state used the US model Claude [A10]. An attacker needs only one of cloud, update infrastructure or admin privilege, and need not touch manufacturing. Of seven attack paths, checking the country of manufacture closes one (Chapter 2).
- AI has changed the economics of attack. As of September 2026 no agency has observed a fully autonomous attack pipeline in the wild [A05, A08]. AI-assisted vulnerability discovery and exploitation are nonetheless demonstrated [M09, M10, M14], and attackers run open-weight models locally to evade commercial API monitoring [A05, A13]. A defence premised on the provenance of products or the goodwill of vendors does not hold when attack capability is this widely available (Chapter 3).
- An alternative exists and the authorities have not compared it. A boundary-protection model based on IEC 62443 zones and conduits and NIST SP 800-82 boundary protection and loss-of-communication behaviour reduces the capacity moved by one compromise by an order of magnitude (base case 2,500 MW → 250 MW, assumptions). The energy agency told us it holds "no comparison material" on alternatives, boundary defence or IEC 62443, and has "no plan to guarantee" third-party verification [G10].
- The cost is small, and that is not evidence of effect. In our model the certification burden on an operator is about ¥265 per year for a 5 kW low-voltage site, one to two orders of magnitude below a boundary device (Chapter 8, assumptions). Cheapness is not a substitute for reach. Cost-effectiveness requires first knowing what is being prevented.
- If the requirement is to be kept, the authorities must show necessity, additional safety and cost-effectiveness. This article puts nineteen public questions (Chapters 2, 10, 11). If they are not answered, the requirement should be revised, an alternative means of compliance admitted, and withdrawal considered.
Throughout, confirmed facts (backed by primary sources), technical inferences, assessments (our judgement) and I-S3 proposals are set in separate boxes. Every claim maps to the reference list and to evidence/evidence_ledger.csv.
1. The reality of attacks: intrusion without touching manufacturing
Real attacks on power and energy assets do not tamper with the factory. They enter through the legitimate paths of systems in operation.
- Ukraine 2015. Spear-phishing into the corporate network, VPN into the control network, remote operation of the distribution HMI. About 225,000 customers lost power [I01]. No product defect; a legitimate remote-operation path was used.
- Industroyer 2016 / 2022. Malware that speaks substation protocols (IEC 60870-5-104 and others) correctly [I02]. The equipment behaved to specification.
- SolarWinds 2020. The vendor's build environment was compromised and malicious code was shipped inside legitimately signed updates to customers including US federal agencies [I03]. The target was the update infrastructure, not the place of manufacture.
- KA-SAT 2022. A misconfigured management VPN gave access to the management network; destructive commands were sent to satellite modems. About 5,800 Enercon wind turbines in Germany lost remote monitoring [I04].
- Denmark 2023. Twenty-two energy companies sharing a common boundary device (Zyxel firewalls) were compromised simultaneously through a vulnerability in that device; some moved to island operation [I05]. Boundary devices are themselves a common cause; Chapters 6 and 8 face this directly.
- Solar clouds 2024–2025. An authorisation flaw in the Solarman/Deye cloud gave researchers access to roughly 195 GW of devices (disclosure, no reported harm) [I07]. Forty-six vulnerabilities in Sungrow, Growatt and SMA ran from cloud account takeover to remote inverter control [I06].
- United States 2021–2024. US and allied agencies disclosed that a PRC state actor (Volt Typhoon) maintained persistent access to US critical-infrastructure IT environments using valid credentials and built-in OS tools alone [I10]: no malware, no tampered product.
- Japan 2024. About 800 remote-monitoring units were compromised and used as a pivot for bank fraud. The government's own slide notes "the devices have no output-control function, so there is no grid impact" [I08, G07].
What these share is that the attacker had no part in manufacturing the product. Entry was through update distribution, a cloud control plane, a management VPN, a shared boundary device, or a disclosed vulnerability. Checking the functional requirements of each device does not close these doors.
The May 2025 report of "rogue communication devices in Chinese inverters" [I09] rests on anonymous sources; no vendor, count or verification method was published. The Japanese government told the Diet that "no case of suspicious communication devices has been reported by the relevant bodies" [D02]. This article does not rely on that report. Manufacturing-stage tampering is possible; the confirmed cases are mostly elsewhere.
2. Checking the country of manufacture does not tell you who the attacker is
This is the central chapter. The claim that auditing the manufacturing process or the manufacturer prevents cyberattack rests on two unstated premises: that attackers enter through manufacturing, and that the attacker's nationality matches the product's country of origin. Neither holds.
Place of manufacture, development, cloud hosting and attacker are different places
In a typical supply structure for inverters and batteries, manufacturing is in country A, firmware development in country B, the cloud in a data centre in country C, and operation in Japan. Checking the country of manufacture tells you about the left two columns only. Intrusion arrives from the right: a third-country cloud, a compromised pivot host, a legitimate administrator account.
Primary threat-intelligence sources confirm that attacker nationality and tool origin do not coincide.
- APT28's PROMPTSTEAL malware (Russia) called Alibaba's open-weight Qwen2.5-Coder-32B-Instruct via the Hugging Face API to generate commands; Google calls this "our first observation of malware querying an LLM deployed in live operations" [A02].
- GTG-1002, which Anthropic attributes with high confidence to the Chinese state, used the US-made Claude Code against about thirty targets [A10].
- Actors observed in 2026 switched between Claude, Gemini and Codex with a routing tool, and deployed open-weight models locally inside compromised environments to avoid commercial API monitoring [A05]. OpenAI reports Chinese operations running DeepSeek and Qwen locally [A13].
If the tools cross borders, so does the attack surface. A path to a Japanese operational system can be built without passing through any company or person in the product's country of manufacture.
Attack-path comparison: origin checks close one of seven
| Attack path | Does the attacker need a role in manufacturing? | Stopped by checking country of origin? | Stopped by auditing the manufacturing/development process? | Blocked or contained by boundary protection? | Example |
|---|---|---|---|---|---|
| Code implanted at manufacture | Yes | Only partly, and only if origin = attacker location | Within scope of process audit, but ★1 "does not assume" supply-chain contact [J02] | Not blocked; destination/rate limits contain misbehaviour | No confirmed public case [D02] |
| Compromise of update infrastructure (servers, signing keys) | No | No | No; a sound process at audit time can be compromised later | Contained by limiting destinations and timing; content cannot be verified | SolarWinds [I03] |
| Compromise of the cloud control plane | No | No | No; essential accompanying services are in scope, but the sixteen requirements do not assess service-side operation (admin privilege, API authorisation scope, any mechanism to stop mass commands) [J02, J05] | Blocked if write commands are dropped at the boundary | Solarman/Deye, SUN:DOWN [I06, I07] |
| Takeover of a legitimate administrator account | No | No | No; the presence of authentication is checked, valid credentials pass | Contained by limiting operation types and reach | Ukraine 2015, KA-SAT [I01, I04] |
| Unknown vulnerability disclosed after certification | No | No | No; an audit is a snapshot | Not exploitable if unreachable from outside, before or after disclosure | RDI test: all 9 models non-compliant [F05] |
| Remote attack via third-country infrastructure | No | No; path unrelated to origin | No | Path limited by enumerating permitted destinations | APT28 × Qwen [A02] |
| Insider / physical access | No | No | No | Not stopped alone; privilege separation narrows reach | — |
An origin check works only on the first row, and only when the country of manufacture coincides with the attacker's location. For the other six, the attacker need not touch manufacturing at all. Compromising any one available surface—cloud, communication path, update infrastructure, administrator privilege—achieves the objective.
What a process audit sees, and what remains during operation
Asset life is 15–20 years. A manufacturing/development audit sees the first few months and the product's functions at one point in time. For the rest—operation and updates—the cloud control plane, administrator accounts, communication paths, post-disclosure vulnerabilities, update distribution and maintenance laptops remain. ★1 is valid for two years [J02], but re-declaration every two years re-checks product functions; it does not inspect the operational attack surface.
Consistency with the government's explanation
The government told the Diet that JC-STAR "is not a scheme that prohibits products of specific countries or companies, but one that confirms and certifies whether a device meets a certain level of cybersecurity" [D04], and repeated that it "does not have specific countries' companies or products in mind" [D05]. The minister for economic security likewise stated that the policy "does not have any specific country in mind" [D03]. At the same time, the ★1 document carries a footnote that IPA consults government agencies on supply-chain risk before issuing a label, with unpublished criteria [J02, J05].
If the official purpose is "confirming functional level", the table shows the paths it closes are few. If the actual purpose were "filtering by country of manufacture", the paths closed would still be the first row only. On either reading, no protective effect against the five paths—update infrastructure, cloud, admin accounts, unknown vulnerabilities, third-country pivots—has been demonstrated.
Public questions to the authorities (attacker non-specificity)
- Which attack paths, specifically, does the government assess as prevented by investigating the manufacturer or the development process?
- Did the design consider that excluding products of a particular country still leaves third-country pivots and cloud compromise open?
- What threat model was adopted on the premise that the attacker's nationality or location need not match the product's country of manufacture?
- Was the cost-effectiveness of product audit compared with that of IEC 62443 boundary protection?
- Is the spread of AI-enabled attack capability reflected in the assessment of the requirement's effectiveness?
- For attacks that manufacturing/development audits cannot prevent, which scheme or technology is planned to prevent harm?
- Can the rationale for making product certification a necessary condition for interconnection be explained in terms of actual protective effect?
Existing answers are mapped in the table in Chapter 10.
3. The spread of AI attack capability: why provenance-based defence no longer holds
What is confirmed and what is not
Confirmed.
- State-sponsored use of AI has been observed continuously since 2024; Google reports actors from more than twenty countries using Gemini [A01].
- AI-assisted vulnerability discovery and exploitation are demonstrated. Google's Big Sleep found an unknown SQLite vulnerability and had reported twenty by August 2025 [M09]. In the DARPA AIxCC final, autonomous systems found 54 vulnerabilities including 18 real ones at about $152 per task [M10]. XBOW's autonomous pentester topped HackerOne's US leaderboard [M11]. Anthropic reported in 2026 that Mythos Preview autonomously found and exploited zero-days in major operating systems and browsers and found 6,202 issues across 1,000 open-source projects [M14]; Japan's National Cybersecurity Office named the model in an alert to critical-infrastructure operators [A19].
- In May 2026 Google reported "for the first time" a threat actor using a zero-day exploit it believes was developed with AI (criminal actor) [A04]; the same report describes a suspected China-nexus actor using AI attack frameworks against Japanese technology companies.
- In August 2025 Anthropic described a criminal with basic skills building and selling ransomware with Claude Code [A09]. Its September 2026 report concludes that "the main distinguishing feature between these classes of actors is no longer sophistication but intent" and that "none of the operations depended on some entirely novel technique… the economics of the attacks have changed" [A12]. One actor in that report claimed to an energy company that it could remotely control the charging current of residential EV chargers.
- Open-weight models ship under commercial-use licences (DeepSeek-R1: MIT; Qwen3: Apache 2.0; gpt-oss: Apache 2.0) and run quantised on consumer hardware [M01, M02, M03, M06]. NIST CAISI found downloads of PRC models rose about 1,000% after DeepSeek-R1's release and that R1-0528 followed agent-hijacking instructions twelve times as often as US frontier models [A17]. Safety tuning can be removed with ten examples for under $0.20 (peer-reviewed) [M07] or from Llama 2 for under $200 (preprint) [M08].
- The UK NCSC rates "AI-assisted vulnerability research and exploit development" the largest change and notes that "the time between disclosure and exploitation has shrunk to days" [A15].
Not confirmed.
- As of September 2026, Google, Microsoft and NCSC each state they have not observed fully autonomous attack pipelines in the wild [A05, A08, A15].
- There is no confirmed case of AI autonomously attacking a power grid; the Dragos and ENISA OT annual reports contain no DER incident with explicit AI involvement [A21, A20].
- Anthropic's "80–90% of tactical operations" is self-reported; IOCs and TTPs were withheld and outside analysts questioned attribution and autonomy [A10, A11]. The report itself notes that Claude "frequently overstated findings and occasionally fabricated data".
- Published CVEs rose from 28,961 (2023) to 40,077 (2024) to 48,244 (2025), but the main driver is the expansion of CVE numbering authorities; there is no primary evidence attributing the rise to AI [M15].
What this article takes from AI
This article does not rely on a claim that autonomous attacks are happening. It relies on three points, each confirmed by primary sources.
- Capability supply and attacker have decoupled. Russian actors use Chinese models, Chinese actors use US models [A02, A10]. Looking at the provenance of a product or model does not tell you who will attack.
- The marginal cost of attack has fallen. Automated discovery, exploit development and reconnaissance are demonstrated [M09, M10, M11, M14]; disclosure-to-exploitation is measured in days [A15]. Row 5 of the table in Chapter 2 is exploited faster, cheaper and more widely than before.
- Monitoring can be evaded. Running open-weight models locally defeats detection at the commercial API [A05, A13]. Deterrence that relies on model providers' goodwill does not reach state actors.
A design of "connect only products from trusted vendors" is therefore no basis for safety when attack capability is this available and this indifferent to origin. What is needed is a structure that stops harm to the grid even when compromised devices or clouds are present (Chapter 6).
The energy agency has produced no document on how the change in AI-enabled capability was reflected in its threat model (Chapter 10, Q4).
4. What JC-STAR★1 actually protects: what the scheme documents say
Criticism must address what the scheme actually is. We take the scope of ★1 from IPA's published document and its answers to us.
Scope and method (JST-CR-01-01-2024R1 v1.1, December 2024) [J02]
- The object is the "IoT product" = IoT device + essential accompanying services (cloud or app essential to the device's function); "systems" are out of scope (p.5). Accompanying services are assessed as requirements seen from the device (protected communication, authentication); service-side operation—administrator privilege management, API authorisation scope, any mechanism to stop mass commands under compromise—is not among the sixteen requirements.
- The method is self-declaration: "IPA does not confirm whether the product conforms to the criteria at the time the label is issued. The reliability of the evaluation therefore depends on the reliability of the vendor" (p.4).
- Validity two years (p.6). Footnote 1: before issuing a label IPA consults government agencies on supply-chain risk; the criteria are unpublished [J05].
- Five attack surfaces are assumed (network, radio, physical ports, UI, accompanying services). "The attack surface of 'contact through the supply chain in product development and procurement' is not assumed"; "the threat of 'unauthorised modification' is out of scope" (pp.9–10).
- Sixteen conformity criteria, S1.1-01 to 16 (pp.12–31); the Diet was told ★1 "boils down to sixteen security requirements" [D01].
What the sixteen requirements cover (summary)
They address the basic hygiene of a single device: no universal default passwords and protected authentication, a software update capability with authenticity verification, protection of communications and stored data, disabling unnecessary services, logging, a vulnerability-disclosure contact and a published support period. The original wording is in [J02] pp.12–31; this is a summary and does not quote individual items.
★2 and above. The ★2 criteria, evaluation guide and checklist are "in preparation" as of 23 October 2026, with applications "planned to open from 2026 onwards" [J04]. The agency told the Diet it is "working toward drafting and requiring a ★2 that reflects threats specific to the power sector" [D06], but told us that no document states a timeline [G10]. The OCCTO paper states that requirements "for ★2 and above" will also be pursued [G09].
IPA's answers (July 2026) [J05]
- "The concept of 'boundary defence' has not been adopted."
- "'Label obtained' does not mean 'securely installed and operated'; it indicates that the product has the conformity requirements demanded by ★1."
- The object of evaluation "is assumed to receive direct communication from outside."
- There is "no" public document on the supply-chain check.
The sixteen requirements define the basic hygiene of a device exposed directly to the internet. Retiring default passwords and providing updates work against row 1 of the table in Chapter 2. That is a meaningful requirement and this article does not deny it.
But the sixteen do not address a cloud control plane issuing mass commands through a legitimate API, a stolen signing key making a malicious update look legitimate, or a maintenance laptop operating devices with valid administrator credentials. IPA's answer states this accurately: the label "does not mean securely installed and operated". Within the scheme documents and IPA's own explanation, ★1 claims no protective effect against rows 2–7.
The problem is not the content of ★1. It is that in placing ★1 as a necessary condition for interconnection, the designers expect an effect beyond ★1's protective range. When the committee chair warned that "a cyberattack that stops many inverters in a short time would collapse the grid completely", the agency replied that it would "start with JC-STAR★1 to lower the probability" [G07]. But an attack on the scale of "collapsing the grid" comes through paths outside ★1's scope, as this chapter shows.
5. Why a manufacturing-process audit is insufficient: the operational attack surface
Figure 1 puts the paths from manufacture to operation on one sheet. JC-STAR★1 evaluates the "product functions" box at the right edge only; the manufacturing process, development process, update servers and signing keys, cloud control plane, communication paths, administrator accounts and site network are outside its evaluation [J02, J05].
The limits of process audit, by example
- An audited process is compromised later. SolarWinds' build environment was compromised after products had been delivered [I03]. Confirming a process at one point in time does not detect later compromise.
- A product that passes is compromised in operation. The Dutch regulator RDI found all nine inverter models it tested non-compliant with ETSI EN 303 645 test items [F05]. ★1 is "harmonised" with ETSI EN 303 645 and NISTIR 8425 [J01, S04, S05]; if the same class of product self-declares ★1, IPA does not verify it [J02]. Note that the RDI result also supports the government's argument that baseline product requirements are needed. This article does not deny that. The problem is making product requirements a necessary condition for interconnection while having no system-side requirement.
- Legitimate paths become attack paths. KA-SAT and Ukraine 2015 were legitimate management VPNs and legitimate HMI operations [I01, I04]. The products behaved to specification.
- Third-party-certified products are compromised after certification. Ivanti Connect Secure received NIAP (US Common Criteria) certification about a month after CISA issued Emergency Directive 24-01 against it; the DoD Inspector General found that disclosed vulnerabilities "were not analyzed" by the evaluation lab [I12]. FortiOS 7.2.8 obtained EAL4+ in February 2026 with SSL-VPN "disallowed" in the evaluated configuration—while real-world compromise came through that SSL-VPN [I12]. ROCA factored RSA keys in FIPS 140-2 and CC EAL5+ certified devices, tens of millions of them [I13]. Certification guarantees "the evaluated requirements, in the evaluated configuration, at the time of evaluation"—which is exactly what IEC 62443-2-1:2024 says of conformity [S01].
- Device-only test results. When NREL ran ten certification test items on commercial PV inverters in 2021, the inverters alone failed nine; with a bump-in-the-wire device in front they passed all ten [S10]. That is evidence that baseline product requirements are needed—and also that the shortest route to meeting them was a device outside the inverter.
A manufacturing/development audit excludes the time axis after the audit and the infrastructure outside the product. Of a 15–20-year asset life, the audit covers the first few months; in space, it covers the inside of the enclosure. The attacker's time and space lie outside both.
To explain a manufacturing audit as "raising the security of the power system", one must show that attacks occurring in the audited process form the main part of the threat to the grid. The distribution of confirmed cases in Chapters 1 and 2 is the reverse. The authorities' risk analysis is qualitative, following IPA's risk-analysis guide, with no quantified probability or impact by path [G06].
6. IEC 62443 and boundary protection: protecting the grid even with untrusted devices
Two models
Product-certification-centred model (left). The trust boundary is at each device. The cloud control plane and update distribution connect directly to every unit, so they become the common point of failure. Even if each unit is sound, a compromised control plane moves all units at once.
Boundary-protection-centred model (right). The trust boundary moves to the site boundary. Commands from the cloud are checked at a boundary device for destination, protocol, function code and rate. A local EMS inside keeps an output floor and a defined behaviour on loss of communication. The common point of failure does not disappear; it moves to the boundary device type. Hence: diversify types and stage updates.
This is not our invention; it is what control-system security standards have prescribed for more than a decade.
- IEC 62443-3-2:2020 defines a zone as a "grouping of logical or physical assets based upon risk or other criteria, such as criticality of assets, operational function, physical or logical location, required access… or responsible organization", a conduit as a "logical grouping of communication channels that share common security requirements connecting two or more zones", and a security level as a "measure of confidence that the SUC, security zone or conduit is free from vulnerabilities and functions in the intended manner"; it requires defining the SUC, partitioning into zones and conduits, assessing risk per zone, setting a target SL and documenting it, including separation of business from IACS assets and of devices connected via external networks [S01].
- IEC 62443-2-1:2024 requires the asset owner to "have policies and procedures segmenting IACS from non-IACS zones and limiting any interconnections to the minimum necessary for IACS operations" (NET 1.1). Use of certified products is "desirable", and conformity is positioned as verified "at the time the control system was assessed" [S01].
- IEC 62443-3-3: system requirements organised in seven foundational requirements (FR1 identification and authentication control, FR2 use control, FR3 system integrity, FR4 data confidentiality, FR5 restricted data flow, FR6 timely response to events, FR7 resource availability) and security levels SL1–4 [S01].
- IEC 62443-4-1 / 4-2: product development lifecycle and component requirements. ★1 can correspond at most to this layer.
- NIST SP 800-82 Rev.3: defence in depth, network segmentation, boundary protection and continued operation on loss of communication as the basics of OT security [S02].
- NIST SP 800-207: network location is not a basis for trust (zero trust). Boundary protection here means "verify at the boundary and separate privilege inside", not "trust everything inside" [S03].
Quotations are limited to the 62443-3-2 definitions and 62443-2-1 NET 1.1 confirmed in IEC's public previews. The text of 62443-3-3 and 4-2 has not been examined; FR names follow IEC's official summary.
★1 against IEC 62443
| IEC 62443-3-3 foundational requirement | Meaning | Covered by ★1's sixteen? | Who provides it in the boundary model |
|---|---|---|---|
| FR1 Identification and authentication control | Who and what is connecting | Device-level authentication: yes | Mutual authentication of boundary device and EMS; separate vendor path from grid-operator path |
| FR2 Use control | What an authenticated party may do | No (valid credentials pass) | Allow-list by function code, drop writes, limit reach |
| FR3 System integrity | Detect tampering | Update authenticity: yes | Limit update destinations and timing, staged rollout |
| FR4 Data confidentiality | Encryption in transit and at rest | Yes (communication and stored data) | Terminate at the boundary, audit inside |
| FR5 Restricted data flow | Control of inter-zone traffic | No ("the concept of boundary defence has not been adopted" [J05]) | The boundary device itself |
| FR6 Timely response to events | Detection, logging, response | Logging: yes | Detection at the boundary, cross-site correlation |
| FR7 Resource availability | Continued operation under loss of comms or attack | No | Local EMS default behaviour, output floor, manual recovery |
★1 covers the device side of FR1, FR3 and FR4 in part. Nothing in the current requirement provides FR2, FR5 or FR7. Rows 2–6 of the table in Chapter 2—cloud, update infrastructure, admin accounts, unknown vulnerabilities, third-country pivots—are exactly the paths that FR2, FR5 and FR7 stop.
A distributed-energy system with boundary protection
Vendor A's inverter, vendor B's inverter, vendor C's battery and an OCPP charger are protected by the same site boundary. Traffic from vendor clouds and the charging-station management system (CSMS) is checked at the boundary device; the grid operator's command path (blue) is separated from the vendor maintenance path (red). The local EMS inside keeps the default behaviour on loss of communication and the output floor.
What happens under compromise. Suppose vendor A's cloud is compromised and issues "output zero" to every unit. In the certification model, the command arrives via a legitimate API with a legitimate signature and every unit obeys. In the boundary model, the boundary device drops the write function code, or the EMS absorbs it with an output floor (for example, rejecting a step below 50% of the trailing 10-minute average). Vendor A's inverters keep running on the grid operator's command path.
What boundary protection does not stop
This article does not present boundary protection as a cure-all.
- Vulnerabilities in the boundary device itself. Denmark 2023 was a compromise of a shared boundary device [I05]. The boundary model introduces a new common cause. Type diversity (five types cap it at 2,000 MW in the Chapter 8 calculation) and staged updates are mandatory.
- Content verification. A malicious update with a legitimate signature (SolarWinds type) can be limited in destination and timing at the boundary, but its content cannot be judged there.
- Insiders and physical access. Ineffective against those already inside; privilege separation and audit only narrow the reach.
- Lateral movement inside a zone. NIST SP 800-82r3 states that "boundary protection devices between zones do not mitigate lateral movement risks within a zone" [S02]. Privilege must be separated between inverters, EMS and maintenance laptops inside the boundary too. The same document notes that PLCs and HMIs may not support zero-trust integration—which is why a boundary layer is needed where zero trust cannot reach.
- Misconfiguration and operational lapses. Our model puts the probability that a boundary device works as designed at ρ = 0.9 (0.7–0.98) and lets one in ten through. The RDI finding of "all nine non-compliant" [F05] is the reason not to set it to 1.
- Device cooperation. The configuration requires devices that accept local control inside the boundary. Chapter 7 checks published specifications.
I-S3 proposal: boundary protection as an alternative means of compliance. Position the following in the grid-interconnection technical requirements as a measure equivalent to "use of JC-STAR★1-labelled devices".
- Define the DER control zone in the IEC 62443-3-2 sense and concentrate external communication in a boundary device on the conduit.
- The boundary device holds an allow-list of destination, protocol, function code and rate; write commands are limited to the grid operator's path.
- A local EMS holds the default behaviour on loss of communication and a floor on output step changes, with manual recovery.
- Boundary-device types are not consolidated to one per operator; updates are staged.
- The configuration is recorded in a form a third party can verify (destination list, blocking rules, test results).
The OCCTO paper recommends closed networks and similar measures "in addition to" the label [G08]. Our proposal is to admit them as an alternative. If both are to be required, the reason both are necessary must be shown.
7. Inverters, batteries and EV chargers: can boundary protection be built with these devices?
Boundary protection presumes that devices accept control locally and can hold a default behaviour without the cloud. We check that premise against published specifications of major devices.
The following records the presence of functions in each vendor's public documentation (versions and dates in the references); we have not verified every item on hardware. Behaviour varies by firmware version, country setting and commissioning configuration. Confirm on your own equipment before relying on it. We have sent 21 manufacturers a public enquiry on update distribution, signing keys and remote-control limits [X07] and will update this table as answers arrive.
| Device / family | Published local control | Cloud-dependent path | Behaviour on loss of comms (per public docs) | Treatment in the boundary model |
|---|---|---|---|---|
| SolarEdge inverters (SetApp) | SunSpec Modbus TCP (off by default, port 1502, LAN only, single leader). Power Control Open Protocol exposes R/W registers for export limits and grid-protection settings; dynamic control falls back to a default on timeout [V01] | Remote settings and firmware updates from the monitoring platform (device-initiated connection) | "Designed to perform their duties even without internet connectivity… PV production, grid and regulatory compliance… continue." A "Safe mode (one-way communication)" drops all incoming cloud commands. Data buffered up to two weeks [V01] | Restrict Modbus TCP writes at the boundary to the grid-operator path; enable Safe mode; cloud path send-only. Whether Modbus writes need extra authentication is not stated publicly |
| Huawei SUN2000 + SmartLogger3000 | Northbound Modbus TCP, IEC 60870-5-104, DI dry-contact control. The third-party Modbus TCP server is off by default because it has "no security authentication mechanism"; up to five allowed IPs [V02] | FusionSolar (Modbus TCP client over TLS, port 27250) for remote settings and updates; "Management system communication" can be disabled | "Limit inverter power upon active power scheduling timeout" defaults to Disable (no automatic curtailment on loss of the scheduler). An "automatic OFF on communication interruption" setting exists where national codes require it [V02] | SmartLogger inside the boundary; FusionSolar traffic restricted at the boundary; remote control mode set to Secure (parameter changes only via local connection). No explicit statement on long-term operation without a management system was found |
| Victron (Cerbo GX family) | Modbus TCP (off by default, port 502, "Write allowed" or read-only), local MQTT (off by default), Node-RED; ESS Mode 3 is driven by local writes [V03] | VRM Remote Console, Remote VEConfigure and remote updates—only when VRM is set to "Full" | VRM setting "Off / Read-only / Full": Read-only disables remote setting changes and updates, Off stops transmission; logs are kept locally for days and can be uploaded manually. ESS Mode 3 drops to Passthru if the 60-second write stops [V03] | VRM Read-only, Remote support left Disabled, Modbus TCP read-only for monitoring; control from the EMS inside the boundary |
| OCPP chargers (1.6J / 2.0.1) | CSMS-initiated SetChargingProfile, RemoteStart/Stop, ChangeAvailability, Reset, UpdateFirmware. Security profiles 1–3 (profile 1 is plaintext with Basic auth, "only… in trusted networks"). A 2.0.1 Local Controller can impose charge limits independently of the CSMS [V04] | The CSMS is the de facto control plane; a compromised CSMS means simultaneous commands to all chargers. MITM on 1.6J plaintext WebSockets and duplicate-connection DoS have been demonstrated [I15] | 1.6 §3.5: "the Charge Point is designed to operate stand-alone" without the Central System; received TxProfile continues offline, otherwise TxDefaultProfile [V04]. Actual support must be checked per model in the OCA certificate (C-01) | Authenticate and restrict the CSMS path at the boundary with profile 3; a local controller or EMS caps load. The current draft does not cover EV chargers [G02] |
| Japanese curtailment-capable inverters (LV/HV) | ECHONET Lite (PV and battery classes; curtailment setting is writable) [V05]. Curtailment works by the device pulling a fixed schedule (400 days) and update schedules from the utility server over HTTPS; inbound sessions are prohibited by specification | Vendor monitoring cloud (varies). Omron's measurement unit has automatic software update on by default [V05] | On loss of the utility server, the device continues on schedules already held. But generation stops when the fixed schedule expires, five minutes after a communication fault between the curtailment unit and the inverter, and on loss of clock until restored [V05] | HEMS/EMS and curtailment unit inside the boundary; allow only device-initiated HTTPS 443 to the utility server; restrict vendor-cloud traffic. The annual fixed-schedule refresh path must be kept or the plant stops |
| Industrial boundary devices | Moxa EDR-G9010: Modbus/TCP "Read Only / Write Only / Read/Write / Manual" profiles, function-code lists, also IEC 104, MMS, DNP3; IEC 62443-4-2 SL2 certified [V06]. Phoenix Contact mGuard: Modbus TCP DPI with Accept/Drop per function code and PDU address, but requires a separate licence (Modbus TCP Inspector); absent in 10.4, re-added in 10.5 [V07]. FortiGate: signature-based detection/blocking per function code (allow-list mode unconfirmed); Siemens SCALANCE SC-600: no function-code filtering documented [V08] | — | — | The "boundary device" of this article; type diversity is a precondition. Only street prices confirmed (Moxa about $3,000; mGuard entry model about €940, DPI licence support unconfirmed) |
| Local EMS (SunSpec / ECHONET Lite / OpenEMS) | Public information models allow vendor-independent local control. OpenEMS allows external writes only to "channels explicitly listed" and has SolarEdge and Huawei implementations [V08, V05] | — | — | The basis on which a boundary device or EMS can write allow-lists across vendors |
For SolarEdge, Huawei and Victron inverters and gateways and for OCPP chargers, vendor documents or the protocol specification confirm that generation or charging continues when the cloud is cut, and all accept local control over Modbus TCP (SunSpec) or ECHONET Lite. The boundary model can be built with existing equipment. What is needed is not replacement but wiring and configuration: restrict the cloud path at the boundary, and use the local path for the grid operator's commands.
Japanese curtailment-capable inverters carry one condition that comes from the scheme design rather than the vendor: generation stops on fixed-schedule expiry, on a fault between the curtailment unit and the inverter, and on loss of clock [V05]. Inside a boundary, the rule must therefore pass device-initiated HTTPS to the utility server. That is not an obstacle to boundary protection; it is precisely the configuration that keeps only the grid operator's path open. On the device side, at least two vendors—Moxa and Phoenix Contact—document function-code-level write blocking, subject to licence and version [V06, V07]. The proposal to diversify boundary-device types presupposes more than one option, and that presupposition currently holds.
The EV-charger gap
The draft contains no occurrence of "electric vehicle", "EV" or "demand-side facility"; EV chargers are outside it [G02]. Yet an OCPP charger can have its charging current changed en masse by SetChargingProfile from the CSMS [V04], and Anthropic's September 2026 report describes an actor claiming to an energy company that it could remotely control residential EV charger current [A12]. The UK proposes ETSI EN 303 645 compliance and a randomised delay of up to ten minutes for EV chargers and home batteries from 31 December 2027 [F07].
For the grid, generation stopping all at once and demand starting all at once produce the same frequency deviation. By what risk assessment does the government justify imposing product certification on generation while imposing nothing on demand-side devices with the same control plane (Chapter 10, Q5)? The boundary model treats generation and demand at the same boundary.
8. Cost-effectiveness: a reproducible model with explicit assumptions
One point first. Cheapness is not a substitute for protective effect. Chapter 2 showed that ★1 closes few paths. This chapter does not ask "is ★1 still justified on cost?" but "what appears when both models' cost and reach are placed in one table?"
Model
All inputs are in data/assumptions.csv with low/base/high values and a kind (fact-range / assumption / to-confirm). model/cost_model.py runs on the standard library.
Model A (certification-centred): the operator's annual cost is the pass-through of certification cost plus lost generation when like-for-like replacement ceases to be a "minor change".
Model B (boundary-centred): annualised boundary device plus operations plus (short) replacement delay.
Here \(F_{cert}\) is the application fee per model (unconfirmed, base ¥30,000), \(F_{int}\) the internal effort for self-declaration (base ¥1.5 million), \(N_{units}\) units shipped per model (base 20,000), \(T_{valid}\) validity two years (IPA published value [J02]), \(P\) site capacity in kW, \(\lambda\) annual inverter replacement rate (base 2%), \(d_A, d_B\) replacement delay in days (base 45 / 3), \(CF\) capacity factor 0.14, \(v\) value of lost energy ¥15/kWh, \(K_B\) boundary device plus installation (LV ¥80,000 / HV and EHV ¥500,000), \(L_B\) replacement cycle 7 years, \(O_B\) operations (LV ¥12,000 / HV and EHV ¥120,000 per year).
Capacity moved at once (Cyber Blast Radius; definition in [X01]): with fleet capacity \(S\), share under one cloud control plane \(s_{cloud}\), probability the boundary works \(\rho\), and share of one boundary-device type \(s_{bnd}\),
\(R_B^{cm}\) is the common-cause term of the boundary device type, a risk specific to B.
Results
| Site class | A per year | B per year | A ¥/kW | B ¥/kW | Break-even boundary capex |
|---|---|---|---|---|---|
| LV residential (5 kW) | ¥265 | ¥23,444 | 53 | 4,689 | ¥0 (B never below A) |
| LV commercial (49.5 kW) | ¥2,284 | ¥23,578 | 46 | 476 | ¥0 |
| HV (500 kW) | ¥22,718 | ¥192,941 | 45 | 386 | ¥0 |
| EHV (5,000 kW) | ¥226,838 | ¥206,549 | 45 | 41 | ¥642,028 |
(Base case; results/cost_per_site.csv, results/break_even.csv.)
On cost. The certification burden on operators is small: a per-model cost divided by units shipped comes to tens or hundreds of yen per unit. Most of A's cost is replacement delay when like-for-like replacement is no longer a "minor change" [G05], and that depends on how the rule is administered (HV: ¥38 per year at zero delay, ¥60,518 at 120 days). The boundary device is one to two orders higher at LV and comparable at EHV.
How to read this. It does not read as "A is cheap, therefore justified". A is cheap partly because A does nothing about most paths; in the Chapter 2 table A closes one or two of seven, and the cost of the paths it does not close is zero. B's cost is the cost of the device and operations that provide FR2, FR5 and FR7. Cost comparison is meaningful only between options of equal reach.
data/assumptions.csv. [SVG]| Scenario (base case, fleet 10,000 MW) | Capacity moved at once |
|---|---|
| A: one cloud control plane compromised (25% share) | 2,500 MW |
| B: same compromise, boundary works with ρ = 0.9 | 250 MW |
| B-specific: all sites on one boundary-device type (ceiling) | 10,000 MW |
| B-specific: two boundary-device types | 5,000 MW |
| B-specific: five boundary-device types | 2,000 MW |
| B-specific: expected value at 5% per year exploitation (two types) | 250 MW/year |
(results/blast_radius.csv. SolarPower Europe/DNV assess that a simultaneous 3 GW compromise would seriously affect the European grid and that more than twelve companies each control over 3 GW [F08].)
On common-cause risk. The weakness of the boundary model shows honestly in the numbers. Consolidate boundary devices to one type and a vulnerability in it can move the whole fleet; Denmark 2023 is this type of risk [I05], and in 2019 a US renewables operator lost about ten hours of visibility through a known vulnerability in its perimeter firewalls [I14]. CISA's Known Exploited Vulnerabilities catalogue (21 Oct 2026, 1,754 entries) lists Fortinet 32, Ivanti 36, Citrix 27, Palo Alto 16 and Zyxel 13 boundary-device entries; our assumption of a 5% annual rate of exploitable boundary-device vulnerabilities rests on that record [I12]. That is why the proposal in Chapter 6 includes "do not consolidate to one type" and "stage updates". With five types the ceiling is 2,000 MW, below A's single cloud compromise of 2,500 MW.
The certification model's common cause is supply convergence onto labelled vendors. If few vendors obtain ★1, \(s_{cloud}\) rises. A Diet member stated that "major Chinese manufacturers have not yet obtained ★1" [D05]; whether the requirement concentrates supply is something the designers should examine. The conditions under which an exclusion rule raises the target value of the remaining products are treated in [X03].
Sensitivity
results/tornado.csv holds one-variable sensitivities. A's annual cost is driven by replacement delay and inverter replacement rate; the certification term barely moves it. B is driven by device capex and operations. Capacity moved at once is driven by \(s_{cloud}\), \(\rho\) and \(s_{bnd}\), all of which are set by scheme design and operation.
What this chapter does not say
- The application fee \(F_{cert}\) has not been confirmed from a primary source as of 23 October 2026 and is an assumption; replacing it with the published figure changes little.
- Boundary-device costs are assumptions from retail price bands, not quotations.
- The social cost of outages is not included; it would turn the difference in \(R\) into a cost difference directly, but no primary data on probability exists, so we do not compute it.
9. Is tying the label to the grid code justified? Form and substance
Confirmed facts
- The consultation is published on e-Gov as a "voluntary call for comments" (legal basis "–"), open until 23:59 on 6 November 2026 [G01]. The notice states that "discussion has proceeded in the direction of requiring the use of devices that have obtained JC-STAR★1" and that "individual responses will not be given" [G03].
- Application is by contract-application date: HV and EHV solar, storage and wind from 1 April 2027; LV solar and storage from 1 October 2027; fuel cells from 1 April 2028. Wind alone may use "a device with equivalent functions" [G02].
- "Replacement with the identical device is not a 'minor change'." Logical separation does not exempt. Full self-consumption is covered [G05].
- Devices are covered "even when not directly exposed to the internet" [G04]. The Diet was also told that "devices using only serial communication, with no function to communicate directly with the internet, are not covered" [D05]: devices with IP capability are covered regardless of topology; only non-IP devices fall outside.
- The authorities' risk analysis follows IPA's guide Ver 2.0 and is qualitative, without quantified probability or impact [G06]. Vendor interviews cite 3.5–4 years to develop a compliant product and costs "on the order of ¥10 million" for a data-deletion function [G06].
- The energy agency's written answers: threat model and risk analysis "see the power sub-working-group materials" (no document identified); comparison of IP vs non-IP or with IEC 62443 "is not the viewpoint of the requirement"; comparison with boundary defence or alternatives "no comparison material exists"; a timeline for ★2 or above "no document states one"; third-party verification "no plan to guarantee it" [G10].
- OCCTO states that "ensuring cybersecurity by measures other than JC-STAR is not denied" while recommending closed networks "in addition to" the label [G08].
Comparison with other jurisdictions
| Scheme | Object | Instrument | Difference from Japan's requirement |
|---|---|---|---|
| EU Cyber Resilience Act [F01] | Products with digital elements | Manufacturer obligations (vulnerability handling, reporting); third-party assessment for important products only; applies 11 Dec 2027 | A product-side obligation, not a condition of interconnection; the EU separately has a grid-side network code on electricity cybersecurity [F09] |
| EU NIS2 [F02] | Essential and important entities | Operator risk-management duties; coordinated supply-chain risk assessment (Art. 22) | Entity-level system obligations, not a product label |
| Lithuania, Electricity Law Art. 73-3 [F04] | Generating installations above 100 kW | Ensure that entities from states deemed national-security threats cannot remotely change output or start/stop (in force 1 May 2025) | Regulates the remote-control path, not product certification; states its purpose openly |
| UK Energy Smart Appliances draft [F07] | EV chargers, electric heating, home batteries | ETSI EN 303 645 compliance, randomised delay up to 10 minutes, from 31 Dec 2027 | Targets demand-side remote-controllable devices; standalone solar inverters outside phase one |
| US NERC CIP [S07] | Bulk Electric System | Operator asset classification and system-level requirements; not applicable to distribution-connected DER | Boundaries (ESP) and requirements defined per system, not per product label |
| Netherlands RDI [F05] | Inverters on the market | Market-surveillance testing (all nine models non-compliant) | A third party tested and published results |
| German federal government reply [F06] | Solar inverters | Estimates Chinese share in Europe at 70–80%; cross-ministry review under way (June 2026) | Neither a product ban nor mandatory certification adopted; the review is public |
The major schemes abroad are each one of: (a) product-side obligations (CRA), (b) entity-level system obligations (NIS2, NERC CIP), (c) regulation of the remote-control path (Lithuania), or (d) published third-party testing (RDI). The combination of a self-declared product label as a necessary condition for interconnection, no admitted alternative, and no guaranteed third-party verification is, as far as we have found, unique to Japan's draft.
The formal issues—a guideline of "standard indicators" that in practice sets every utility's tariff requirement uniformly, a voluntary consultation with no individual replies, and the removal of like-for-like replacement from "minor changes"—are treated in our earlier article [X04]. This article's point sits before those. Placing a requirement whose effectiveness has not been shown as a necessary condition, in good form, is the problem.
Foreseeability
As of 23 October 2026, before the requirement takes effect, this article records the following with public sources and technical grounds.
- Attack paths exist that product certification alone cannot stop (Chapters 1, 2).
- The threat environment has changed with the spread of AI-enabled attack capability (Chapter 3).
- Alternatives—boundary protection, network separation, containment—exist and can be built with existing devices (Chapters 6, 7).
- Over-reliance on product certification may crowd out investment in effective measures (Chapter 8).
- Replacement delays and market constraints from mandatory certification may cause additional social loss (Chapter 8, [X04]).
We have put written questions to the energy agency and IPA since July 2026 [X02] and filed a comment in October (receipt no. 620340012420402491) [X04]; the sequence is recorded with dates in the ledger [X05]. Should harm occur after the requirement takes effect, we will test against this record whether the harm fell within the threats the scheme targets, which defence failed, and whether the measures proposed in advance would have prevented or reduced it.
10. What the authorities must explain: public questions and answer status
Formatted as a letter of questions. Status is drawn from the written answers we have received [G10, J05] and public documents, and distinguished as answered / unanswered / no document exists (per the authority) / under enquiry.
| # | Question | Status | Basis |
|---|---|---|---|
| Q1 | By how much, quantitatively, does obtaining JC-STAR★1 reduce cyber risk to the power system as a whole? | No document exists | Risk analysis is qualitative [G06]; only "lower the probability" [G07] |
| Q2 | If the cloud management platform is compromised, what stops malicious commands to certified inverters? | Unanswered | IPA: the label "does not mean securely installed and operated" [J05]; no stopping mechanism described |
| Q3 | If IEC 62443 boundary protection is not admitted as an alternative means of compliance, what is the technical reason? | No document exists | "No comparison material"; "not the viewpoint of the requirement" [G10]; closed networks recommended only "in addition" [G08] |
| Q4 | How is the spread of AI-enabled attack capability reflected in the threat model? | Unanswered | Threat model: "see the sub-working-group materials" [G10]; those materials [G06] contain nothing on AI |
| Q5 | By what risk assessment is the regulatory gap with remote-controllable demand-side devices such as EV chargers justified? | Unanswered | Draft contains nothing on EV or demand-side devices [G02] |
| Q6 | Was the cost of product audit compared with the cost of the boundary-protection alternative? | No document exists | "No comparison material on alternative measures" [G10] |
| Q7 | By what indicators will safety improvement be measured after entry into force, and under what conditions will the scheme be revised? | Unanswered | Third-party verification "not planned" [G10]; no document on review conditions |
| Q8–Q14 | The seven questions of Chapter 2 (attacker non-specificity) | Q8–Q10 unanswered; Q11 no document exists [G10]; Q12–Q14 unanswered | Including consistency with "not a scheme that prohibits products of specific countries or companies" [D04] |
| Q15–Q19 | The five questions of Chapter 11 (accountability and review conditions) | Unanswered | — |
Full text in briefs/open_questions_to_government.md. Answers will be reflected here and in the ledger [X05].
11. Security policy without demonstrated effect, and political and administrative responsibility
Four kinds of responsibility, each with its test
To keep accountability from dissolving into general blame, we separate four kinds and name what each is tested against.
| Kind | Tested against | What this article found |
|---|---|---|
| Political | Mismatch between aim and instrument; delay in revising; explanation to the public | The aim is stated as "confirming cybersecurity level" [D04]; the instrument is self-declaration on a single device. The link—"protecting the grid"—is not explained (Chapters 4, 10) |
| Administrative | Soundness of risk assessment, comparison of alternatives, cost-effectiveness analysis, response to foreseeable harm | Risk assessment qualitative [G06]; alternatives and cost "no comparison material" [G10]; third-party verification "not planned" [G10] |
| Legal | Unlawfulness, duty of care, causation, damage—the elements of liability | This article does not decide. We do not assert that legal liability follows automatically; nor do we let the difficulty of proving it blur the political and administrative tests |
| Economic | Unnecessary certification cost, replacement delay, lost generation, outage and recovery cost | Direct certification burden is small (Chapter 8). Replacement-delay cost depends on administration: ¥38 to over ¥60,000 per year for a 500 kW HV site. Outage cost not computed for lack of probability data |
The central claim
Among the gravest failures in cybersecurity policy is to treat a measure of undemonstrated effect as proof of safety, and in consequence to neglect effective defence.
If the state makes a particular certification scheme a de facto condition of market entry, it has a duty to explain what that scheme prevents.
If serious harm occurs while the vulnerabilities and attack paths pointed out in advance remain inadequately addressed, the existence of the scheme and the count of labels issued cannot be claimed as policy success.
What is then called into question is not only the attacker's responsibility. It is the rationality of the policy decision: why this measure was chosen, why alternatives were not adopted, and why prior warnings were not adequately answered.
Having imposed cost and obligation on citizens and operators, the administration bears the responsibility to verify outcomes and to correct course.
Explanations we ask of the authorities (accountability and review)
- Proof of protective effect. Which attacks, specifically, does mandatory JC-STAR certification prevent, and what risk reduction is expected?
- Comparison of alternatives. Against IEC 62443 boundary protection and system-level safety assessment, what was the basis for adopting the current scheme?
- Evaluation on policy failure. If certified equipment suffers a large-scale cyberattack with serious social loss, by what indicators will the scheme's effectiveness be re-evaluated?
- Conditions for review. What harm, cost overrun or malfunction of the certification scheme would trigger revision or withdrawal of the interconnection requirement?
- Record of decision. What threat model, technical verification, cost-effectiveness analysis and comparison of alternatives were performed when the scheme was adopted, and who approved the decision?
Names and offices of officials are given only for public statements made in office (Diet records [D01]–[D07]). Institutional responsibility and individual wrongdoing are distinct.
The final question of this article is not "was a certification scheme introduced?" but "did that policy decision actually protect the public and the power system?" The current scheme has no indicator and no verification mechanism to answer it.
12. Conclusion: judge safety by actual defensive capability, not by certification
Checking the country of manufacture does not tell you the attacker's nationality.
Auditing the development process does not stop intrusion during operation.
Excluding the products of a particular country does not exclude the threat actors associated with that country.
The attacker need not be involved in manufacturing at all. Compromising any available surface—cloud, communication path, update infrastructure, administrator privilege—achieves the objective.
The spread of AI-enabled attack capability makes this worse.
A regulatory design that makes the safety of the power system depend on trust in a product's provenance or manufacturing process must therefore be tested rigorously for effectiveness.
What is needed is not to connect only products certified as trustworthy, but a structure that stops harm to the grid as a whole even when untrusted devices and compromised systems are present.
At its centre are boundary protection, privilege restriction, network separation and containment, grounded in international standards such as IEC 62443.
Our conclusions:
- Product certification and operational safety are not the same thing. This is not our opinion; it is IPA's written answer [J05].
- No protective effect may be presumed for attacks that certification does not address. Against cloud control planes, update infrastructure, administrator accounts, unknown vulnerabilities and third-country pivots, the ★1 requirement has no demonstrated effect and its effectiveness is doubtful. This is a finding that the basis has not been shown, not proof of no effect. Refutation is simple: the authorities publish a threat model by path and an estimate of effect.
- In the age of AI, defence that depends on attacker nationality or product provenance is insufficient. Tool origin and attacker have decoupled, marginal cost has fallen, and monitoring can be evaded [A02, A05, A10, A15].
- An alternative centred on boundary protection and containment should be examined. It can be built with published interfaces of existing devices (Chapter 7), cuts capacity moved at once by an order of magnitude (Chapter 8, assumptions), and its own common cause is controlled by type diversity.
- If the interconnection requirement is kept, necessity, additional safety and cost-effectiveness must be shown. None has been documented to date [G10].
- If they are not shown, revision, an alternative means of compliance, and if necessary withdrawal should be considered. Comments are accepted until 6 November 2026 [G01].
The final issue is not who manufactured the device, but whether the grid can be protected no matter who attacks.
What this article does not say
- It does not say the sixteen requirements of ★1 are meaningless; retiring default passwords and providing updates work against single-device exposure.
- It does not say products of any particular country are safe, or unsafe. Country of manufacture is not the point.
- It does not say boundary protection stops everything; what it does not stop is listed in Chapter 6.
- It does not say legal liability arises; Chapter 11 separates four kinds of responsibility.
- It does not say AI has attacked a power grid; no confirmed case exists [A21].
FAQ
Is an inverter with a JC-STAR★1 label secure?
No. IPA states that "label obtained" does not mean "securely installed and operated"; it indicates the product has the sixteen requirements [J05]. ★1 is a self-declaration of single-device functions; attacks via cloud, update infrastructure or administrator accounts are outside it [J02].
Does checking the country of manufacture exclude attackers?
No. The only path closed by an origin check is code implanted at manufacture, and only when the country of manufacture coincides with the attacker's location. Russian actors used a Chinese AI model [A02] and Chinese actors used a US model [A10]; tool origin and attacker do not coincide. Update infrastructure, cloud, administrator accounts, unknown vulnerabilities, third-country pivots and insiders are usable regardless of origin.
What is boundary protection and where is it in IEC 62443?
Define the DER as a zone, concentrate external communication in a boundary device on the conduit, and check destination, protocol, function code and rate. IEC 62443-3-2 defines zones and conduits; 62443-3-3 defines FR5 (restricted data flow) and FR7 (resource availability) [S01]. NIST SP 800-82 Rev.3 likewise makes boundary protection and loss-of-communication behaviour fundamental [S02].
Are there attacks boundary protection cannot stop?
Yes: vulnerabilities in the boundary device itself (Denmark 2023 [I05]), the content of a legitimately signed malicious update, insiders and physical access, and misconfiguration. Our model sets the probability that the boundary works at 0.9 and lets one in ten through. Type diversity, staged updates and restricted update destinations are the countermeasures.
Can boundary protection be built with existing inverters?
Vendor documents confirm that SolarEdge, Huawei, Victron and OCPP chargers keep generating or charging when the cloud is cut, and all accept local control over Modbus TCP (SunSpec) or ECHONET Lite [V01, V02, V03, V04, V05]. It is wiring and configuration—restrict the cloud path at the boundary, use the local path for the grid operator—rather than replacement. Japanese curtailment inverters need the path to the utility server kept open or they stop on schedule expiry; allow that path only. Behaviour varies by version and settings; confirm before relying on it.
Which is cheaper?
In direct operator cost, the ★1 requirement (model A). Base case: ¥265 vs ¥23,444 per year at 5 kW LV, comparable at 5,000 kW EHV (assumptions). But A is cheap partly because the cost of the paths it does not address is zero. Cost comparison is meaningful only between options of equal reach.
Did the authorities compare alternatives?
No. The energy agency stated in writing that it holds no comparison material on boundary defence, alternatives or IEC 62443, and has no plan to guarantee third-party verification [G10]. The originals are published in our answer dataset [X02].
Has AI attacked a power grid?
No confirmed case [A21, A20]. What this article takes from AI is not "autonomous attacks are happening" but three points: capability supply and attacker have decoupled, marginal cost has fallen, and monitoring can be evaded [A02, A05, A10, A15].
Where can comments be filed?
e-Gov case 620340012, until 23:59 JST on 6 November 2026 [G01]. Our own submission is published [X04].
How can the numbers be checked?
Edit data/assumptions.csv and run python3 model/cost_model.py; results/ is regenerated. Primary sources are recorded in evidence/evidence_ledger.csv with document, issuer, date, location, URL and how each was verified. All under CC BY 4.0.
Claims and evidence
Principal claims and the primary sources or results that support them. IDs match claim_id in evidence/evidence_ledger.csv.
| ID | Claim | Kind | Evidence |
|---|---|---|---|
| C01 | ★1 is self-declared; IPA does not verify conformity | Confirmed fact | [J02] p.4 |
| C02 | ★1 covers device + essential accompanying services; "systems" excluded | Confirmed fact | [J02] p.5 |
| C03 | ★1 "does not assume" supply-chain contact | Confirmed fact | [J02] pp.9–10 |
| C07 | IPA: "boundary defence not adopted"; label ≠ secure installation and operation | Confirmed fact | [J05] |
| C09 | Application dates: HV/EHV Apr 2027, LV Oct 2027, fuel cells Apr 2028 | Confirmed fact | [G02] |
| C10 | The draft contains nothing on EV chargers or demand-side devices | Confirmed fact | [G02] full-text search |
| C11 | Like-for-like replacement is not a "minor change"; logical separation does not exempt | Confirmed fact | [G05] |
| C12 | Authorities hold no comparison with alternatives, boundary defence or IEC 62443 | Confirmed fact | [G10] |
| C13 | Authorities' risk analysis is qualitative, no quantified values | Confirmed fact | [G06] |
| C16 | Government: "not a scheme that prohibits specific countries or companies" | Confirmed fact | [D04, D05] |
| C17 | Russian APT28 used Chinese Qwen2.5-Coder | Confirmed fact | [A02] |
| C18 | China-attributed campaign used US Claude (80–90% is self-reported) | Confirmed fact | [A10, A11] |
| C19 | Attackers deploy open-weight models locally to evade monitoring | Confirmed fact | [A05, A13, A12] |
| C20 | No fully autonomous attack pipeline observed as of Sept 2026 | Confirmed fact | [A05, A08, A15] |
| C21 | No confirmed case of AI autonomously attacking a power grid | Confirmed fact | [A21, A20] |
| C27 | SolarWinds: malicious code in legitimately signed updates | Confirmed fact | [I03] |
| C29 | Denmark: 22 operators compromised via a shared boundary device | Confirmed fact | [I05] |
| C37 | RDI: all nine inverters non-compliant with ETSI EN 303 645 | Confirmed fact | [F05] |
| C40 | SolarEdge, Huawei, Victron and OCPP keep operating when the cloud is cut and expose local control paths | Confirmed fact (public documents, versions cited) | [V01, V02, V03, V04] |
| C45 | Japanese curtailment inverters stop on fixed-schedule expiry or unit–inverter communication fault | Confirmed fact | [V05] §6.2, 7.6, 8 |
| C46 | NREL test: commercial PV inverters alone failed 9 of 10 items; all passed with a bump-in-the-wire device | Confirmed fact | [S10] Table 1 |
| C47 | NIAP/CC-certified boundary devices were exploited around the time of certification, via functions outside the evaluated configuration | Confirmed fact | [I12] |
| C48 | IEC 62443-2-1:2024 positions conformity as "at the time assessed" and requires IACS segmentation (NET 1.1) | Confirmed fact (preview text) | [S01] |
| C49 | At least two vendors document function-code-level write blocking in boundary devices (licence/version dependent) | Confirmed fact | [V06, V07] |
| C41 | Origin checks close one of seven paths | Technical inference | Chapter 2 table; [J02, J05, A02, A10, I03, I04] |
| C42 | Boundary devices block T2–T6 conditionally and are a new common cause | Technical inference | [S02, I05, I11]; results/coverage_matrix.csv |
| C43 | Cost results depend on assumptions; cheapness and reach are separate axes | Technical inference | results/summary.json |
| C44 | No demonstrated effect of the ★1 requirement against origin-independent paths; effectiveness doubtful | Assessment | C07, C12, C13, C41 |
Revision history
- 23 October 2026: v1.0 published, before the close of the consultation (6 November 2026). Chapter 7 rests on vendor public documents (versions cited); replies from the 21-manufacturer enquiry [X07] not yet reflected.
- 23 October 2026: video explainers added (Japanese, English, Simplified Chinese; 7.5–9 minutes). The videos summarise this article; narration corrections are in each video's description.
Tell us the PCS, battery and EV charger makes and where they connect; we will work through where the boundary device goes and how to define behaviour on loss of communication.
Ask how to set up boundary protection for your own siteCitation and reuse
Of the attachments, the CSV, JSON and Python files (data/, model/, results/, evidence/) are released under CC BY 4.0. Cite I-S3 Co., Ltd. and this article's URL and you may reuse, modify and redistribute them, including commercially. If you publish recomputed results, keep the attribution to the original model.
Text and figures (SVG) may be quoted with attribution. For wholesale reproduction of figures, or if you hold different data or assumptions, use the contact form.
Suggested citation
English
Masuda, S. (2026). Product audits cannot protect the power grid: boundary protection and effective cybersecurity in the age of AI. I-S3 Co., Ltd. https://www.i-s3.com/jc-star-grid-cyber-effectiveness-2026-en.html
Japanese
益田周防海（2026）「製品審査では電力系統を守れない——AI時代の境界防護と実効的サイバーセキュリティ」株式会社I-S3、2026年10月23日公開、https://www.i-s3.com/jc-star-grid-cyber-effectiveness-2026.html
BibTeX
@misc{masuda2026jcstar_effectiveness,
author = {Masuda, Suomi},
title = {Product audits cannot protect the power grid: boundary protection and effective cybersecurity in the age of AI},
year = {2026},
publisher = {I-S3 Co., Ltd.},
url = {https://www.i-s3.com/jc-star-grid-cyber-effectiveness-2026-en.html},
note = {Japanese original: https://www.i-s3.com/jc-star-grid-cyber-effectiveness-2026.html. Model, data and evidence ledger (CC BY 4.0): https://www.i-s3.com/jc-star-grid-cyber-effectiveness-2026.html#assets}
}
Reproduce: python3 model/cost_model.py && python3 model/make_figures.py (README).
Attachments
The files below are generated with the same assumptions and calculations as the text; use them to check numbers or recompute.
Assumptions and data
data/assumptions.csv— 前提値 low/base/high・種別（fact-range／assumption／to-confirm）・根拠
Model (Python 3, standard library only)
model/cost_model.py— 年間費用・損益分岐・到達可否・同時に動く容量・感度model/make_figures.py— 図 1〜7 の SVG 生成（日英）
Results (CSV / JSON)
results/cost_per_site.csv— サイト規模別の年間費用results/break_even.csv— 損益分岐の境界装置費用results/coverage_matrix.csv— 攻撃経路ごとの到達可否results/blast_radius.csv— 侵害時に同時に動く容量results/tornado.csv— 一変数感度results/summary.json— 要約
Evidence ledger and review
evidence/evidence_ledger.csv— 一次資料の台帳（資料名・発行者・日付・該当箇所・URL・確認方法）review/red_team_report.md— 反証テスト（10 項目）の結果と反映briefs/open_questions_to_government.md— 行政への公開質問（全文）briefs/faq.md— FAQbriefs/sns.md— SNS 用の紹介文
Text
article/index.md— 日本語原稿（Markdown）article/index.en.md— English manuscript (Markdown)article/references.md— 出典一覧README.md— 再現手順とライセンス
References
ID は本文と evidence/evidence_ledger.csv から参照する。J＝JC-STAR 制度（IPA）、G＝系統連系要件化（資源エネルギー庁・広域機関）、D＝国会会議録、A＝AI と攻撃能力（脅威インテリジェンス・政府機関）、M＝モデル公開・研究、S＝規格・ガイダンス、I＝攻撃事例、V＝メーカー公開仕様、F＝海外の制度、X＝当社の先行記事・回答データ。確認日は特記なき限り 2026-10-23。「本文取得」は原文（HTML／PDF）を取得して該当箇所を読んだもの。
J. JC-STAR 制度（IPA）
- [J01] IPA「セキュリティ要件適合評価及びラベリング制度（JC-STAR）」トップページ。制度の目的（「ETSI EN 303 645 や NISTIR 8425 等の国内外の規格とも調和しつつ、独自に定める適合基準…に基づき、IoT 製品に対する適合基準への適合性を確認・可視化する」）、2025-11-06 日英相互承認覚書、2026-03-18 日・シンガポール覚書。最終更新 2026-07-31。本文取得。 https://www.ipa.go.jp/security/jc-star/index.html
- [J02] IPA「JC-STAR ★1（レベル1）適合基準・評価手法（1.1版）」JST-CR-01-01-2024R1、2024年12月（2024-12-05 公開）、38 頁。p.4 自己適合宣言（「適合ラベル交付時に定められた適合基準に適合しているかを IPA は確認しない。つまり、評価の信頼性はベンダーの信頼性に依存する」）、p.5 対象の定義（IoT 機器＋必須付随サービス、「システム」は対象外）、p.6 有効期間 2 年・脚注 1（ラベル発行前にサプライチェーン・リスクを政府関係機関に照会）、p.9–10 アタックサーフェス 5 種と「『製品開発・調達等のサプライチェーンにおける接触』のアタックサーフェスは想定しない」「『不正改造』の脅威は対象外」、p.12–31 適合基準 S1.1-01〜16。本文取得。 https://www.ipa.go.jp/security/jc-star/tekigou-kizyun-guide/label1/begoj90000004zgc-att/JC-STARlevel1_tekigoukizyun_hyouka.pdf
- [J03] IPA「★1 の文書構成の変更に向けた事前告知」2026-02-26。表記のみの変更で「適合要件自体の内容に変更はございません」。本文取得。 https://www.ipa.go.jp/security/jc-star/tekigou-kizyun-guide/label1/begoj90000004zgc-att/pre-notification_of_STAR1_document_structure_change_20260225.pdf
- [J04] IPA ★2 適合基準ページ（適合基準・評価ガイド・チェックリストはすべて「準備中」、申請受付は「2026 年以降の開始を計画」）および ★3・★4 ページ（★3 は通信機器・ネットワークカメラのセキュリティ要件 JST-SR-03-01/02-2026 のみ公開）。2026-10-23 時点。本文取得。 https://www.ipa.go.jp/security/jc-star/tekigou-kizyun-guide/label2/index.html
- [J05] IPA セキュリティセンター 技術評価部から当社への文書回答（2026-07-19・07-25・07-26）。「『境界防御』という考えは導入していません」（第1回）、「『適合ラベル取得済み』は、『安全に設置・運用されている』ことではなく…★1 で要求する適合要件を有していることを示す」「外部からの直接通信を受信することを前提」（第3回）、サプライチェーン確認の公開文書は「ありません」。原文は [X02]。
G. 系統連系要件化（資源エネルギー庁・電力広域的運営推進機関）
- [G01] 資源エネルギー庁「『電力品質確保に係る系統連系技術要件ガイドライン』改定案に対する意見公募」e-Gov 案件番号 620340012。区分「任意の意見募集」（根拠法令条項「-」）、公示 2026-10-06、受付締切 2026-11-06 23:59。本文取得。 https://public-comment.e-gov.go.jp/pcm/detail?CLASSNAME=PCMMSTDETAIL&id=620340012
- [G02] 同 改定案本文（34 頁）。第1章 1「系統連系技術要件（託送供給等約款別冊）に対して統一的な方針を示し」、第1章 5「標準的な指標」、第2章第1節 5「分散型電源のサイバーセキュリティ対策」（対象機器の定義、適用開始日: 特高・高圧の太陽光・蓄電池・風力 2027-04-01、低圧の太陽光・蓄電池 2027-10-01、燃料電池 2028-04-01、既設の増設・交換、猶予の 3 条件、風力のみ「又はこれと同等の機能を有する機器」）。「電気自動車」「EV」「需要設備」の語は 0 件。本文取得。 https://public-comment.e-gov.go.jp/pcm/download?seqNo=0000322029
- [G03] 同 意見公募要領（3 頁、令和 8 年 10 月 6 日）。「JC-STAR★1 を取得した機器の使用を要件化する方向で議論を行ってまいりました」「個別の回答はいたしかねます」。本文取得。 https://public-comment.e-gov.go.jp/pcm/download?seqNo=0000322028
- [G04] 資源エネルギー庁「系統連系技術要件の改定について（JC-STAR★1 要件化）」第13回 次世代電力系統ワーキンググループ 資料4（2026-10-06、9 頁）。p.2 背景（「50kW 未満…サイバーセキュリティの確保に特化した明確な技術基準の規定までは存在しない」）、p.4 対象範囲（PCS・BMS・EMS 等の出力制御装置、遠隔監視装置、「インターネット等に直接露出していない場合であっても…対象」）、p.5 適用タイミング、p.9 年度内に大臣認可申請予定。本文取得。 https://www.meti.go.jp/shingikai/enecho/denryoku_gas/saisei_kano/smart_power_grid_wg/pdf/013_04_00.pdf
- [G05] 資源エネルギー庁「電力分野のサイバーセキュリティについて」ページ（最終更新 2026-10-16）および FAQ（5 頁）。「同一機器への交換であっても『軽微な変更』とはなりません」、猶予例示は 2026 年 3 月末までの延長保証・予備品、FAQ Q7「論理的切断による分離がされていたとしても、全て JC-STAR★1 を取得製品の使用が求められます」、Q13 完全自家消費でも対象。本文取得。 https://www.enecho.meti.go.jp/category/electricity_and_gas/other/cybersecurity/ ／ FAQ https://www.enecho.meti.go.jp/category/electricity_and_gas/other/cybersecurity/data/01.pdf
- [G06] 産業サイバーセキュリティ研究会 WG1 電力サブワーキンググループ 第18回（2025-02-04）資料6-1「小規模太陽光発電設備のサイバーセキュリティ対策について」および議事要旨。IPA「制御システムセキュリティリスク分析ガイド Ver2.0」に基づく定性的リスク分析（不正アクセス・不正操作・高負荷攻撃・不正媒体・サプライチェーン攻撃が高リスク）、攻撃シナリオ例（外部から複数 PCS へ不正な出力制御指令）、メーカーヒアリング（準拠製品の開発に 3.5〜4 年、データ削除機能に 1,000 万円オーダー）。発生確率・影響量の定量値はない。本文取得。 https://www.meti.go.jp/shingikai/mono_info_service/sangyo_cyber/wg_seido/wg_denryoku/018.html
- [G07] 電力広域的運営推進機関 第20回 グリッドコード検討会（2025-12-16）資料4（ファイル名 gridcode_20_05.pdf）および議事録。座長「IBR に対して短時間に多数の電源を停止させるようなサイバー攻撃があれば、系統は完全につぶれてしまう」→ 資源エネルギー庁「ご指摘いただいたようなケースが実績としてあるわけではないが、一方で可能性としては十分考えられる…JC-STAR★1 から取り組み、蓋然性を低くしたい」。p.7 国内事例（2024-05 遠隔監視装置約 800 台、「対象機器は出力制御機能を有さないため、系統への影響はない」）、p.8・p.11 既存ガイドラインとの関係。本文取得。 https://www.occto.or.jp/iinkai/gridcode/20.html
- [G08] 同 第19回（2025-06-25）資料6「分散型電源のサイバーセキュリティ対策の要件化に係る今後の対応について」。「JC-STAR 制度によらない対策によりサイバーセキュリティを確保することは否定されるものではなく、むしろ、JC-STAR のラベル取得に加えて、…閉域網を活用し…対策を行うことは推奨されるべき」（追加であって代替ではない）。全文テキストを取得。 https://www.occto.or.jp/assets/iinkai/gridcode/2025/files/gridcode_19_06.pdf
- [G09] 同 第21回（2026-03-31）資料4。風力はゲートウェイのファイアウォール限定・2027-04、燃料電池 2028-04、「今後、JC-STAR 制度★2 以上の基準の整備や導入についても…要件化を進めていく」。本文取得。 https://www.occto.or.jp/iinkai/gridcode/21.html
- [G10] 資源エネルギー庁 電力基盤整備課から当社公開質問への文書回答（2026-07-13・07-16・07-30、28 問）。Q7・Q8 脅威モデル・リスク分析＝「電力サブワーキンググループ資料をご参照」（資料名の特定なし）、Q9・Q10 IP／非 IP の比較・IEC 62443 との比較＝「要件化の観点ではございません」、Q14 境界防御等との比較＝「比較資料ございません」、Q18 代替措置＝「代替措置の比較資料はございません」、Q23 ★2 以上へのロードマップ＝「時期を明言した資料は存在いたしません」、Q27 第三者検証可能性＝「担保する予定はございません」。原文は [X02]。
D. 国会会議録（kokkai.ndl.go.jp、職務上の発言のみ）
- [D01] 2025-04-09 参議院 地方創生及びデジタル社会の形成等に関する特別委員会、西村秀隆 経済産業省大臣官房サイバーセキュリティ・情報化審議官「十六項目のセキュリティー要件に集約される星1の運用を開始」。本文取得。 https://kokkai.ndl.go.jp/txt/121715360X00420250409/13
- [D02] 2025-05-26 参議院 決算委員会、武藤容治 経済産業大臣「現時点では、関係団体からは不審な通信機器が搭載されているという事例は報告されていない」。本文取得。 https://kokkai.ndl.go.jp/txt/121714103X00820250526/243
- [D03] 2025-11-14 参議院 予算委員会、小野田紀美 内閣府特命担当大臣（経済安全保障）「我が国の経済安全保障の取組は特定の国を念頭に置いたものではない」。本文取得。 https://kokkai.ndl.go.jp/txt/121915261X00320251114/167
- [D04] 2026-05-15 衆議院 内閣委員会、久米孝 資源エネルギー庁電力・ガス事業部長「諸外国において、太陽光の PCS に関し、特定の国の製品の使用を禁止するような制度が設けられているとは把握してございません。今回活用する JC-STAR 制度は、特定の国や企業の製品の使用を禁止するような制度ではなく、一定のサイバーセキュリティー水準を満たす機器であるかどうかを確認、認証する制度」。本文取得。 https://kokkai.ndl.go.jp/txt/122104889X01220260515/50
- [D05] 2026-06-12 衆議院 経済産業委員会、久米孝 同部長「シリアル通信のように、インターネットと直接通信する機能を持たず…通信方法のみを利用する機器は対象となりません」、赤澤亮正 経済産業大臣「特定国の企業や製品を念頭に置いたものではない」。同日、阿部司議員（質問側）「主要中国メーカーは現時点でこの JC-STAR 星1 を取得できていないと承知」。本文取得。 https://kokkai.ndl.go.jp/txt/122104080X01320260612/180
- [D06] 2026-06-19 衆議院 経済産業委員会、久米孝 同部長「電力分野固有の脅威や特性等を踏まえた JC-STAR 星2 の策定や要件化に向け、その効果や事業者にかかる負担なども考慮しつつ…検討を進めてまいります」。本文取得。 https://kokkai.ndl.go.jp/txt/122104080X01520260619/156
- [D07] 2026-05-27 衆議院 内閣委員会、松本尚 デジタル大臣（サイバー安全保障担当）。重要インフラの安全基準等策定指針で JC-STAR を参照、★3 は「本年中にはまとめていきたい」。本文取得。 https://kokkai.ndl.go.jp/txt/122104889X01520260527/11
A. AI と攻撃能力（脅威インテリジェンス・政府機関）
- [A01] Google Threat Intelligence Group, "Adversarial Misuse of Generative AI" (2025-01-29). 「not yet the game-changer」「we do not see indications of them developing novel capabilities」、20 か国超の国家支援アクターが Gemini を利用（イラン・中国・北朝鮮・ロシア）。本文取得。 https://cloud.google.com/blog/topics/threat-intelligence/adversarial-misuse-generative-ai
- [A02] GTIG, "GTIG AI Threat Tracker: Advances in Threat Actor Usage of AI Tools" (2025-11-05). PROMPTSTEAL（ロシア APT28、Qwen2.5-Coder-32B-Instruct を Hugging Face API 経由で呼ぶ、「our first observation of malware querying an LLM deployed in live operations」）、PROMPTFLUX（実験段階）。本文取得。 https://cloud.google.com/blog/topics/threat-intelligence/threat-actor-usage-of-ai-tools
- [A03] GTIG, "GTIG AI Threat Tracker: Distillation, Experimentation, and (Continued) Integration" (2026-02-12). 「has not yet observed APT or IO actors achieving breakthrough capabilities」、モデル抽出（蒸留）攻撃は世界中の民間主体・研究者から。本文取得。 https://cloud.google.com/blog/topics/threat-intelligence/distillation-experimentation-integration-ai-adversarial-use
- [A04] GTIG, "Adversaries Leverage AI for Vulnerability Exploitation, Augmented Operations, and Initial Access" (2026-05-11). 「For the first time, GTIG has identified a threat actor using a zero-day exploit that we believe was developed with AI」（犯罪系）、中国系と疑われるアクターが Hexstrike・Strix 等を日本の技術企業に対して使用、複数ベンダーのアカウントプール。本文取得。 https://cloud.google.com/blog/topics/threat-intelligence/ai-vulnerability-exploitation-initial-access
- [A05] GTIG, "GTIG AI Threat Tracker: From Prompting to Autonomy" (2026-09-08). 「GTIG has not yet observed threat actors deploying fully autonomous pipelines against targets in the wild」、UNC6508 が侵害環境にオープンウェイトモデルをローカル展開して商用 API 監視を回避、CC Switch で Claude・Gemini・Codex を切替。本文取得。 https://cloud.google.com/blog/topics/threat-intelligence/from-prompting-to-autonomy-the-evolution-of-adversarial-ai
- [A06] Microsoft Threat Intelligence / OpenAI, "Staying ahead of threat actors in the age of AI" (2024-02-14). 「not yet observed particularly novel or unique AI-enabled attack or abuse techniques」。本文取得。 https://www.microsoft.com/en-us/security/blog/2024/02/14/staying-ahead-of-threat-actors-in-the-age-of-ai/
- [A07] Microsoft, "Microsoft Digital Defense Report 2025" (2025-10-16). 国家主体の AI 利用の加速。本文取得。 https://cdn-dynmedia-1.microsoft.com/is/content/microsoftcorp/microsoft/bade/documents/products-and-services/en-us/security/Microsoft-Digital-Defense-Report-2025-v4-05Nov25.pdf
- [A08] Microsoft, "AI as tradecraft: How threat actors operationalize AI" (2026-03-06). 「Microsoft has not yet observed large-scale use of agentic AI by threat actors」「human operators retain control over objectives, targeting, and deployment decisions」。本文取得。 https://www.microsoft.com/en-us/security/blog/2026/03/06/ai-as-tradecraft-how-threat-actors-operationalize-ai/
- [A09] Anthropic, "Detecting and countering misuse of AI: August 2025" (2025-08-27). 「Agentic AI has been weaponized」、Claude Code を使った 17 組織への恐喝、基礎的スキルの犯罪者によるランサムウェア作成・販売。本文取得。 https://www.anthropic.com/news/detecting-countering-misuse-aug-2025
- [A10] Anthropic, "Disrupting the first reported AI-orchestrated cyber espionage campaign" (2025-11-13) およびフルレポート。GTG-1002（中国国家支援と「high confidence」で評価）、約 30 標的・成功は少数、「80–90% of tactical operations independently」、同時に「Claude frequently overstated findings and occasionally fabricated data…remains an obstacle to fully autonomous cyberattacks」。本文取得。 https://www.anthropic.com/news/disrupting-AI-espionage
- [A11] BleepingComputer, "Anthropic claims of Claude AI-automated cyberattacks met with doubt" (2025-11) ほか。IOC・TTP の非開示、自律度の主張と捏造の記述の矛盾、帰属の外部裏付けの欠如を指摘する批判（二次資料。批判が存在した事実の根拠としてのみ用いる）。本文取得。 https://www.bleepingcomputer.com/news/security/anthropic-claims-of-claude-ai-automated-cyberattacks-met-with-doubt/
- [A12] Anthropic, "Detecting and countering misuse of AI: September 2026" (2026-09). 「The main distinguishing feature between these classes of actors is no longer sophistication but intent」「None of the operations in this report depended on some entirely novel technique…the economics of the attacks have changed」、GTG-50014（エネルギー企業で「家庭用 EV 充電器の充電電流を遠隔制御できると主張」）、一部作戦はオンプレ LLM で稼働。本文取得。 https://www.anthropic.com/threat-intelligence-report-september-2026
- [A13] OpenAI, "Disrupting malicious uses of AI" シリーズ（2024-02〜2026-06）。2025-10 版「bolt AI onto old playbooks to move faster, not gain novel offensive capability」、2026-02 版で中国の作戦が DeepSeek・Qwen をローカル展開。本文取得。 https://openai.com/index/disrupting-malicious-uses-of-ai/
- [A14] UK National Cyber Security Centre, "The near-term impact of AI on the cyber threat" (2024-01-24). 「AI will almost certainly increase the volume and heighten the impact of cyber attacks over the next two years」。本文取得。 https://www.ncsc.gov.uk/report/impact-of-ai-on-cyber-threat
- [A15] UK NCSC, "Impact of AI on cyber threat from now to 2027" (2025-05-07). 「AI-assisted vulnerability research and exploit development (VRED)」が最大の変化、「The time between disclosure and exploitation has shrunk to days」、「The development of fully automated, end-to-end advanced cyber attacks is unlikely to 2027」、オープンソースモデルが参入障壁を下げる。本文取得。 https://www.ncsc.gov.uk/report/impact-ai-cyber-threat-now-2027
- [A16] CISA, NSA, FBI ほか 9 機関, "Principles for the Secure Integration of Artificial Intelligence in Operational Technology" (2025-12-03). LLM を OT の安全判断に使うべきでない。本文取得。 https://www.cisa.gov/sites/default/files/2026-01/joint-guidance-principles-for-the-secure-integration-of-artificial-intelligence-in-operational-technology-508cV2.pdf
- [A17] NIST Center for AI Standards and Innovation, "Evaluation of DeepSeek AI Models" (2025-09-30). R1-0528 はエージェント乗っ取り指示に米国フロンティアモデルの 12 倍従いやすく、一般的なジェイルブレイクで 94% が応答、R1 公開後に PRC モデルのダウンロードが約 1,000% 増。本文取得。 https://www.nist.gov/system/files/documents/2025/09/30/CAISI_Evaluation_of_DeepSeek_AI_Models.pdf
- [A18] IPA「情報セキュリティ10大脅威 2026」(2026-01-29)。組織向け 3 位「AI の利用をめぐるサイバーリスク」（初選出）。本文取得。 https://www.ipa.go.jp/security/10threats/10threats2026.html
- [A19] 国家サイバー統括室「AI 性能の高度化を踏まえたサイバーセキュリティ対策の強化（Project YATA-Shield）」(2026-05-18)。Claude Mythos Preview を名指しし重要インフラ事業者に注意喚起。本文取得。 https://www.cyber.go.jp/pdf/press/20260518_AI_CS_Critical_Infrastructure.pdf
- [A20] ENISA, "ENISA Threat Landscape 2025" (2025-10-01). 2025 年初頭からのスタンドアロン悪性 AI システムの出現、OT を狙うハクティビスト（重大な運用影響の報告なし）。本文取得。 https://www.enisa.europa.eu/publications/enisa-threat-landscape-2025
- [A21] Dragos, "OT/ICS Cybersecurity Year in Review 2026" (2026-02-17). ELECTRUM が 2025-12 にポーランドの分散型エネルギー資源を標的、KAMACITE が米国の制御ループをマッピング。AI が自律で OT を操作した事例の記載はない。本文取得。 https://www.dragos.com/blog/dragos-2026-ot-cybersecurity-year-in-review
- [A22] IEA, "Energy and AI — AI and energy security" (2025). 「Cyberattacks on energy utilities have tripled in the past four years and have become more sophisticated because of AI」（Check Point の集計を引用した分析値）。本文取得。 https://www.iea.org/reports/energy-and-ai/ai-and-energy-security
M. モデル公開・能力実証・研究
- [M01] DeepSeek, "DeepSeek-R1" 公開（2025-01-20、MIT ライセンス、蒸留版 1.5B〜70B は Qwen・Llama ベース、「Distill & commercialize freely!」）。本文取得。 https://github.com/deepseek-ai/DeepSeek-R1
- [M02] Alibaba Qwen Team, "Qwen3" (2025-04-29、Apache 2.0、「Ollama, LMStudio, MLX, llama.cpp…are highly recommended」)。本文取得。 https://qwenlm.github.io/blog/qwen3/
- [M03] OpenAI, "gpt-oss-120b / gpt-oss-20b" (2025-08-05、Apache 2.0、20b は 16 GB メモリで動作)。本文取得。 https://openai.com/index/introducing-gpt-oss/
- [M04] Mistral AI, "Mistral Small 3" (2025-01-30、Apache 2.0、量子化で RTX 4090 または 32 GB Mac でローカル実行)。本文取得。 https://mistral.ai/news/mistral-small-3
- [M05] Moonshot AI, "Kimi K2" (2025-07-11、Modified MIT)；Z.ai, "GLM-4.5" (2025-07-28、MIT)；Meta, "Llama 4" (2025-04-05、Llama 4 Community License)。各公式ページ。本文取得。 https://huggingface.co/moonshotai/Kimi-K2-Instruct
- [M06] ggml-org, "llama.cpp" (MIT)。1.5〜8 bit 量子化、Apple Silicon を第一級対応。本文取得。 https://github.com/ggml-org/llama.cpp
- [M07] X. Qi et al., "Fine-tuning Aligned Language Models Compromises Safety, Even When Users Do Not Intend To!" ICLR 2024 (oral), arXiv:2310.03693。10 例・0.20 ドル未満の微調整で GPT-3.5 Turbo の安全策を無効化。本文取得。 https://arxiv.org/abs/2310.03693
- [M08] P. Gade et al., "BadLlama: cheaply removing safety fine-tuning from Llama 2-Chat 13B" arXiv:2311.00117 (2023-10-31、プレプリント)。200 ドル未満で安全微調整を除去。本文取得。 https://arxiv.org/abs/2311.00117
- [M09] Google Project Zero, "From Naptime to Big Sleep" (2024-11-01) および Google, "Cybersecurity updates summer 2025"。SQLite の未知の脆弱性を AI エージェントが発見、CVE-2025-6965 を悪用前に阻止、2025-08 に 20 件。本文取得。 https://googleprojectzero.blogspot.com/2024/10/from-naptime-to-big-sleep.html
- [M10] DARPA, "AIxCC results" (2025-08-08)。決勝で合成脆弱性 54 件発見・43 件修正、実在の脆弱性 18 件、タスクあたり約 152 ドル。本文取得。 https://www.darpa.mil/news/2025/aixcc-results
- [M11] XBOW, "How XBOW did it" (2025-06-24)。自律ペンテスターが HackerOne 米国リーダーボード首位。本文取得。 https://xbow.com/blog/top-1-how-xbow-did-it
- [M12] R. Fang et al., "LLM Agents can Autonomously Exploit One-day Vulnerabilities" arXiv:2404.08144 (2024-04)。CVE 記述ありで GPT-4 が 15 件中 87% を悪用、記述なしでは 7%。本文取得。 https://arxiv.org/abs/2404.08144
- [M13] OpenAI, "GPT-5.3-Codex System Card" (2026-02-05)。「the first launch we are treating as High capability in the Cybersecurity domain」（予防的）。本文取得。 https://openai.com/index/gpt-5-3-codex-system-card/
- [M14] Anthropic, "Assessing Claude Mythos Preview's cybersecurity capabilities" (2026-04-07) および "Project Glasswing initial update" (2026-05-22)。主要 OS・ブラウザのゼロデイを自律的に発見・悪用、OSS 1,000 プロジェクトで 6,202 件。本文取得。 https://www.anthropic.com/research/mythos-preview
- [M15] CVE Program, "Metrics"。公開 CVE 件数 2023 年 28,961、2024 年 40,077、2025 年 48,244。増加の主因はサードパーティ CNA で、AI を原因とする一次証拠はない。本文取得。 https://www.cve.org/About/Metrics
S. 規格・ガイダンス
- [S01] IEC 62443 シリーズ。IEC TS 62443-1-1:2009（用語・概念）、62443-2-1:2024 Ed.2（資産所有者のセキュリティプログラム。無料プレビューで 8.2.1 NET 1.1「The asset owner shall have policies and procedures segmenting IACS from non-IACS zones and limiting any interconnections to the minimum necessary」、認証製品の使用は「desirable」で適合は「at the time the control system was assessed」の状態、を本文確認）、62443-2-4:2023（サービス提供者）、62443-3-2:2020（無料プレビューで 3.1 定義を本文確認: zone「grouping of logical or physical assets based upon risk or other criteria…」、conduit「logical grouping of communication channels that share common security requirements connecting two or more zones」、security level「measure of confidence that the SUC, security zone or conduit is free from vulnerabilities and functions in the intended manner」、ZCR 3.1〜3.6 の項目名）、62443-3-3:2013（システム要件と SL。FR1〜FR7 の名称は IEC 公式要約で確認、本文未確認）、62443-4-1:2018（「only apply to the developer and maintainer of the product」）、62443-4-2:2019（SL-C を定義、SL-T／SL-A は範囲外。本文未確認）。本記事は公開スコープ・プレビューで確認できた文言だけを引用する。 https://webstore.iec.ch/en/publication/30727 ／ https://webstore.iec.ch/en/publication/62883
- [S10] NREL, "Cybersecurity Certification Recommendations for Interconnected Grid Edge Devices and Inverter Based Resources" NREL/TP-5R00-80581 (November 2021)。10 の認証試験項目を市販 PV インバータで実施、Table 1: 市販 PV 単体は 9 項目「Failed」、前置装置（bump-in-the-wire、DERCyST）を置くと全項目 Passed。本文取得。 https://docs.nlr.gov/docs/fy22osti/80581.pdf
- [S11] CISA / FBI / EPA / DOE, "Primary Mitigations to Reduce Cyber Threats to Operational Technology" (2025-05-06)。「Remove OT connections to the public internet」「Segment IT and OT networks」「Practice and maintain the ability to operate OT systems manually」、設定不備は「the system integrator… managed service provider, or… the system manufacturer」のいずれからも入る。本文取得。 https://www.cisa.gov/resources-tools/resources/primary-mitigations-reduce-cyber-threats-operational-technology
- [S12] FERC Order No. 901 (Docket RM22-12-000, 2023-10-19)。IBR 向けの新しいサイバー基準の策定は指示せず「NERC should evaluate whether there are gaps」。配電接続の IBR-DER は対象外。本文取得（Federal Register）。 https://www.federalregister.gov/documents/2023/10/30/2023-23581/reliability-standards-to-address-inverter-based-resources
- [S02] NIST SP 800-82 Rev. 3, "Guide to Operational Technology (OT) Security" (2023-09)。5.1.2「prevent single points of failure in cybersecurity defenses and to assume no single origin of threats」、5.2.3.1「Firewalls… constitute the primary mechanism for protecting OT devices」、5.2.3.4「boundary protection devices between zones do not mitigate lateral movement risks within a zone」「Some OT components (e.g., PLCs, controllers, HMI) may not support the technologies… required to fully integrate with a ZTA」。本文取得。 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r3.pdf
- [S03] NIST SP 800-207, "Zero Trust Architecture" (2020-08)。基本原則 7 項。本文取得。 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
- [S04] ETSI EN 303 645 V3.1.3 (2024-09), "Cyber Security for Consumer Internet of Things: Baseline Requirements"。消費者向け IoT のベースライン。本文取得。 https://www.etsi.org/deliver/etsi_en/303600_303699/303645/03.01.03_60/en_303645v030103p.pdf
- [S05] NISTIR 8425, "Profile of the IoT Core Baseline for Consumer IoT Products" (2022-09)。本文取得。 https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8425.pdf
- [S06] CISA, "Secure by Design" (2023-04 初版、2023-10 改訂)。製造者側の設計責任。本文取得。 https://www.cisa.gov/securebydesign
- [S07] NERC, CIP-002-5.1a / CIP-005 および白書 "Cybersecurity for DERs and DER Aggregators"。「NERC CIP standards are not applicable to systems or assets connected to the distribution system」、BES 定義 Inclusion I4（75 MVA・100 kV）。本文取得。 https://www.nerc.com/globalassets/our-work/white-papers/white_paper_cybersecurity_for-ders_and_der_aggregators.pdf
- [S08] IEEE Std 1547.3-2023, "Guide for Cybersecurity of Distributed Energy Resources Interconnected with Electric Power Systems"（2023-12-11、ガイドであり要件ではない）。「The communication protocols used for DER interactions, even those with well-defined security standards, are almost never implemented with their security capabilities. Even if they are purchased with their security capabilities, these are rarely enabled.」部分本文。 https://standards.ieee.org/ieee/1547.3/10173/
- [S09] 資源エネルギー庁「電力制御システムに関するサプライチェーン・セキュリティ対策の手引き」(2025-06)。改定案の猶予条件 ③ で参照。 https://www.enecho.meti.go.jp/category/electricity_and_gas/other/cybersecurity/
I. 攻撃事例
- [I01] SANS ICS / E-ISAC, "Analysis of the Cyber Attack on the Ukrainian Power Grid" (2016-03-18)。2015-12-23、スピアフィッシング→VPN→HMI の遠隔操作、約 22.5 万需要家が停電。
- [I02] ESET, "Industroyer" (2017-06) および ESET/CERT-UA, "Industroyer2" (2022-04-12)。IEC 60870-5-104 等の変電所プロトコルを直接操作するマルウェア。 https://www.welivesecurity.com/2022/04/12/industroyer2-industroyer-reloaded/
- [I03] CISA, "Emergency Directive 21-01: Mitigate SolarWinds Orion Code Compromise" (2020-12-13)。ベンダーのビルド環境に侵入し正規署名付き更新に不正コードを混入。 https://www.cisa.gov/news-events/directives/ed-21-01-mitigate-solarwinds-orion-code-compromise
- [I04] Viasat, "KA-SAT Network cyber attack overview" (2022-03-30)。管理用 VPN の設定不備→管理網→モデムへ破壊的コマンド。ドイツ Enercon 社の風力発電機約 5,800 基が遠隔監視を喪失。 https://news.viasat.com/blog/corporate/ka-sat-network-cyber-attack-overview
- [I05] SektorCERT, "The attack against Danish, critical infrastructure" (2023-11)。22 事業者が共通して使う Zyxel 製ファイアウォールの脆弱性で同時侵害、一部はアイランド運転へ。 https://sektorcert.dk/wp-content/uploads/2023/11/SektorCERT-The-attack-against-Danish-critical-infrastructure-TLP-CLEAR.pdf
- [I06] Forescout Vedere Labs, "SUN:DOWN" (2025-03-27)。Sungrow・Growatt・SMA の 46 件の脆弱性。「Most cases affected solar monitoring products… or cloud backends… Interestingly, there are few instances of vulnerabilities directly affecting solar inverters」、Growatt はパスワードリセットでアカウント乗っ取り、ENTSO-E の基準事故 3 GW。本文取得。 https://www.forescout.com/research-labs/sun-down/
- [I07] Bitdefender Labs, "60 Hurts per Second" (2024-08-07)。Solarman/Deye クラウドの認可不備で約 195 GW 相当の機器にアクセス可能だった。 https://www.bitdefender.com/en-us/blog/labs/60-hurts-per-second-how-we-got-access-to-enough-solar-power-to-run-the-united-states
- [I08] 2024-05 コンテック社 SolarView Compact の脆弱性悪用（約 800 台、インターネットバンキング不正送金の踏み台）。第 83 回 電力・ガス基本政策小委員会 資料6（2024-11-20）、[G07] p.7 に引用。
- [I09] Reuters, "Rogue communication devices found in Chinese solar power inverters" (2025-05-14)。匿名情報源に基づく報道。メーカー名・台数は非開示。日本政府は「関係団体からは…事例は報告されていない」[D02]。二次資料。 https://www.reuters.com/sustainability/climate-energy/ghost-machine-rogue-communication-devices-found-chinese-inverters-2025-05-14/
- [I10] CISA / NSA / FBI, "PRC State-Sponsored Actors Compromise and Maintain Persistent Access to U.S. Critical Infrastructure" (AA24-038A, 2024-02-07)。Volt Typhoon。 https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-038a
- [I11] CrowdStrike, "Preliminary Post Incident Review" (2024-07-24)。信頼済み更新チャネルによる約 850 万台の同時停止（攻撃ではないが共通原因の典型）。 https://www.crowdstrike.com/falcon-content-update-remediation-and-guidance-hub/
- [I12] CISA, "Emergency Directive 24-01: Mitigate Ivanti Connect Secure and Ivanti Policy Secure Vulnerabilities" (2024-01-19)。DoD IG, "Management Advisory: NIAP's Evaluation and Certification Process for COTS Products" DODIG-2025-165 (2025-09)「On February 23, 2024, NIAP certified ICS and IPS… after Ivanti disclosed vulnerabilities… that were not analyzed by the CCTL」。Common Criteria Portal: FortiOS 7.2.8 EAL4+ (2026-02-17) の Security Target 1.5.7.2 で SSL VPN は「disallowed」、一方 CISA 2025-04-11 アラートは SSL-VPN 経由の悪用（CVE-2024-21762 等）。CISA KEV（2026-10-21 版、1,754 件）: Fortinet 32・Ivanti 36・Citrix 27・Palo Alto 16・Zyxel 13。本文取得。 https://www.cisa.gov/news-events/directives/ed-24-01-mitigate-ivanti-connect-secure-and-ivanti-policy-secure-vulnerabilities ／ https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
- [I13] M. Nemec et al., "The Return of Coppersmith's Attack: Practical Factorization of Widely Used RSA Moduli" (ROCA, CVE-2017-15361), ACM CCS 2017。「The library in question is found in NIST FIPS 140-2 and CC EAL 5+ certified devices… at least tens of millions」。本文取得。 https://acmccs.github.io/papers/p1631-nemecA.pdf
- [I14] NERC, Lesson Learned "Risks Posed by Firewall Firmware Vulnerabilities" (2019-09)。2019-03-05、境界ファイアウォールの Web インターフェースの脆弱性で再起動を繰り返し約 10 時間監視を喪失（発電への影響なし）。「a firmware update to address the exploited vulnerability had been released prior to the event」。DOE CESER 2022-11 ブリーフィングは事業者を sPower、機器を Cisco ファイアウォールと明記。本文取得。 https://www.nerc.com/globalassets/programs/event-analysis/lessons-learned/20190901_risks_posed_by_firewall_firmware_vulnerabilities.pdf
- [I15] SaiFlow, "Hijacking EV Charge Points to Cause DoS" (2023-02)（OCPP 1.6J で同一充電器の二重接続を CSMS が扱えない）、INL/DOE OSTI 2431391（OCPP 1.6 の平文 WebSocket への MITM で充電セッション終了・root 取得・不正ファームウェア更新を実証）、Pen Test Partners (2021-07-30)「One platform had no authorisation at all: knowing a short, predictable device ID allowed full remote control」「potential to cause stability problems for the power grid」。本文取得。 https://www.osti.gov/servlets/purl/2431391
V. メーカー公開仕様
版・国別設定で挙動は変わる。本記事は公開資料に記載された機能の有無だけを根拠にし、実機検証は行っていない。「ミラー」はメーカー発行文書を第三者サイトの再掲から取得したもの（内容・版は文書内記載）。メーカー 21 社への照会 [X07] の回答が届き次第更新する。
- [V01] SolarEdge Technologies, "Cybersecurity Technical Overview" V1.0 (Aug 2026)。「designed to perform their duties even without internet connectivity… PV production, grid and regulatory compliance… continue」、「Safe mode – one-way communication… all incoming commands to the device (from the SolarEdge cloud) are dropped」、遠隔更新は機器発の接続が前提、接続先 FQDN・ポート一覧。同 "Technical Note: SunSpec Logging Interface" Version 3.3 (October 2026)（Modbus TCP 既定無効・ポート 1502・LAN 専用・単一リーダー）、"Power Control Open Protocol for SolarEdge Inverters" Version 1.3 (Nov. 2017、ミラー)（出力制限・系統保護整定値の R/W レジスタ、Dynamic 制御のタイムアウトとフォールバック）。本文取得。 https://knowledge-center.solaredge.com/sites/kc/files/se-cybersecurity-technical-overview.pdf ／ https://knowledge-center.solaredge.com/sites/kc/files/sunspec-implementation-technical-note.pdf
- [V02] Huawei Digital Power, "SmartLogger3000 User Manual" Issue 23 (2024-12-30、ミラー)。北向き Modbus TCP・IEC 60870-5-104（第三者向け Modbus TCP サーバは「no security authentication mechanism」のため既定無効、許可 IP 最大 5 件）、「Limit solar inverter power upon active power scheduling timeout: The default value is Disable」、「Management system communication: Enable/Disable」、日本の出力制御サーバへ HTTPS 443。同 "Smart Dongle Networking… Commissioning Manual" 5.7 (2026-05-14)「Remote control mode: Standard／Secure／Emergency（Secure ではパラメータ変更はローカル接続のみ）」（スニペット）。 https://support.huawei.com/enterprise/en/doc/EDOC1100108365/
- [V03] Victron Energy, "Cerbo GX Manual" Rev 40 (04/2026)。VRM Portal 設定「Off – No connection to VRM / Read-only – … no remote setting changes or firmware updates / Full」、Remote support 既定 Disabled、Modbus TCP 既定無効（ポート 502、「Access permissions: Write allowed／read-only」）、MQTT 既定無効、Online updates 既定「Check only」、接続先 FQDN・ポート一覧。"ESS mode 2 and 3"（register 37 を 60 秒ごとに書かないと Passthru）。本文取得。 https://www.victronenergy.com/media/pg/Cerbo_GX/en/vrm-portal.html ／ https://www.victronenergy.com/live/ess:ess_mode_2_and_3
- [V04] Open Charge Alliance, "OCPP 1.6" edition 2 FINAL (2017-09-28)。§3.5「In the event of unavailability of the communications or even of the Central System, the Charge Point is designed to operate stand-alone」、§3.13.6 オフライン中は受領済み TxProfile を継続、第 5 章 Central System 発の操作（Remote Start/Stop、Set Charging Profile、Change Availability、Reset、Update Firmware ほか）。"OCPP 1.6 Security Whitepaper" Edition 3（Profile 1 Basic 認証／2 TLS＋Basic／3 TLS＋クライアント証明書、A00.FR.005 ダウングレード禁止）、現行は Edition 4 (2026-02-05)。"OCPP 2.0.1 Part 2 – Specification" Edition 3 FINAL (2024-05-06)（K06・K07 オフライン Smart Charging）、"Part 1 – Architecture & Topology" (2020-03-31) §8.3 Local Controller。 https://openchargealliance.org/protocols/open-charge-point-protocol/ ／ https://openchargealliance.org/ocpp-info-whitepapers/
- [V05] 関西電力送配電「出力制御機能付PCS 等（高低圧）技術仕様書」2021-04 制定・2023-11 改定。6.2「内部通信が異常となってから、5 分以内で発電出力を停止」、7.3 時計消失時は復旧まで停止、7.6「通信途絶した場合でも、固定スケジュールを含めた既取得済のスケジュールで出力制御可能」、8 章 固定スケジュール 400 日・年 1 回以上更新。同 お知らせ 2024-03-06「固定スケジュールが設定されなかった場合は…発電が停止します」「損失補償はいたしません」。オムロン「モニタリングユニット 施工・保守 補足説明書（出力制御編）」（2025-08 掲載版）「固定スケジュールの期限が過ぎた場合、発電を停止します」「通信障害…が発生するとパワーコンディショナは５分後に発電を停止」。JEMA「出力制御機能付PCSの開発に向けた補足説明 第6版」(2025-09-05)。ECHONET Lite「住宅用太陽光発電・HEMS コントローラ間 AIF 仕様書」Ver.1.20 (2024-01-26)（出力制御設定 0xA0/0xA1 は Set 可）。本文取得。 https://www.kansai-td.co.jp/consignment/renewable-energy/kansai/pdf/spec_01.pdf ／ https://www.jema-net.or.jp/engineering/dispersed/050.html ／ https://echonet.jp/spec_g/
- [V06] Moxa, "EDR-G9010 Series User Manual" Version 2.0 (September 2022) および Datasheet v2.8。Protocol Filter の Modbus/TCP Object「Profile: Read Only, Write Only, Read/Write, Manual」、Function Code 0–255 をカンマ列挙、既定アクション Reset。DPI 対応: Modbus TCP/UDP・IEC 60870-5-104・IEC 61850 MMS・DNP3。IEC 62443-4-2 SL2 認証。本文取得。 https://www.moxa.com/getmedia/a4d3401f-e5bc-4c30-8121-b33108f109ac/moxa-edr-g9010-series-manual-v2.0.pdf
- [V07] Phoenix Contact, "UM EN MGUARD 8.9" (105661_en_18, 2024-04-18)、"UM EN FW MGUARD10" 10.4／10.5。「Deep Packet Inspection… Packets which use specific function codes can be “dropped” or “accepted” via defined rules」「Modbus TCP rule sets can only be used when a suitable license key is installed (Modbus TCP Inspector)」。mGuard 10.4 では Modbus DPI 非対応、10.5.0 で再追加。本文取得。 https://help.mguard.com/pdf/en/mguard8/manual/8.9/UM_EN_MGUARD_8.9_105661_en_18.pdf
- [V08] SunSpec Alliance, "SunSpec Modbus" 仕様群。OpenEMS "Controller.Api.ModbusTcp.ReadWrite"（「Only channels explicitly listed can be written」、SolarEdge・Huawei の実装あり）。Fortinet "FortiOS 8.0.1 Administration Guide – IPS Modbus TCP decoder"（Modbus ファンクションコード単位のシグネチャ、OT シグネチャは既定除外）。Siemens "SCALANCE SC-600 WBM Configuration Manual" V3.0（L3/L4 ステートフルのみ、Modbus DPI の記載なし）。 https://sunspec.org/sunspec-modbus-specifications/ ／ https://openems.github.io/openems.io/openems/latest/
F. 海外の制度
- [F01] Regulation (EU) 2024/2847 (Cyber Resilience Act)。本則適用 2027-12-11、報告義務 2026-09-11。 https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
- [F02] Directive (EU) 2022/2555 (NIS2)。国内法化期限 2024-10-17、Art.22 重要 ICT サプライチェーンの協調リスク評価。 https://eur-lex.europa.eu/eli/dir/2022/2555/oj
- [F03] 欧州委員会 Virkkunen 副委員長回答 E-002219/2025 (2025-07-29)。太陽光インフラ（インバータ含む）の EU レベルリスク評価を計画。 https://www.europarl.europa.eu/doceo/document/E-10-2025-002219_EN.html
- [F04] リトアニア 電力法 第 73-3 条（2024-11-12 法 Nr. XIV-3092 で新設、2025-05-01 施行）。100 kW 超の設備について、国家安全保障戦略で脅威と位置付けられる国の主体が遠隔で出力変更・起動停止できないよう確保。 https://www.infolex.lt/ta/21215:str73-3
- [F05] Rijksinspectie Digitale Infrastructuur (RDI), "Onderzoek storingsproblematiek en cyberveiligheid omvormers voor zonnepanelen" (2023-05-30)。試験した 9 台（8 メーカー）すべてが ETSI EN 303 645 の試験項目に不適合。 https://www.rdi.nl/documenten/2023/05/30/onderzoek-storingsproblematiek-en-cyberveiligheid-omvormers-voor-zonnepanelen
- [F06] Deutscher Bundestag, Drucksache 21/6433 (2026-06-10)。欧州の中国製インバータ比率を 70〜80% と推計、省庁横断で検討中。 https://dserver.bundestag.de/btd/21/064/2106433.pdf
- [F07] UK DESNZ, "Energy Smart Appliances Regulations 2026" 協議案 (2025-12)。EV 充電器・電気暖房・家庭用蓄電池に ETSI EN 303 645 準拠を 2027-12-31 から要求、最大 10 分のランダム遅延。太陽光インバータ単体は第 1 フェーズ対象外。 https://assets.publishing.service.gov.uk/media/692d7e20a245b0985f03432a/consultation-draft-energy-smart-appliances-regulations-2026.pdf
- [F08] SolarPower Europe / DNV, "Solutions for PV Cyber Risks to Grid Stability" (2025-04-29)。3 GW の同時侵害が欧州系統に重大な影響、12 社超が 3 GW 超を保有、業界固有基準と域外からの遠隔制御の制限を推奨。 https://www.solarpowereurope.org/insights/thematic-reports/solutions-for-pv-cyber-risks-to-grid-stability
- [F09] Commission Delegated Regulation (EU) 2024/1366 (Network Code on Cybersecurity for the electricity sector)。 https://eur-lex.europa.eu/eli/reg_del/2024/1366/oj
X. 当社の先行記事・回答データ
- [X01] 益田周防海「CybersecurityからCyber-Resilienceへ——完全には守れない世界で、数千万台の分散電源をどう接続すべきか」(2026-10-07)。Cyber Blast Radius の定義とモデル。 https://www.i-s3.com/cyber-resilience-der-blast-radius.html
- [X02] 株式会社I-S3「JC-STAR 行政回答データセット」(CC BY 4.0)。資源エネルギー庁 28 問回答・IPA 回答の原文（行政側の個人名のみマスク）。 https://www.i-s3.com/jc-star-answers/
- [X03] 益田周防海「狙われないと考える根拠は、どこにもない——製品を外す規則が標的の価値を上げる三つの条件」(2026-10-17)。 https://www.i-s3.com/jc-star-target-structure-20261017.html
- [X04] 益田周防海「様式は整い、本質は動かず、交換は重くなった——改定案の検証」(2026-10-08) および提出した意見全文（受付番号 620340012420402491）。 https://www.i-s3.com/jc-star-grid-code-draft-verdict-20261008.html
- [X05] 株式会社I-S3「JC-STAR 予見可能性の台帳」。日付と参照番号つきの経過記録。 https://www.i-s3.com/jc-star-foreseeability-ledger.html
- [X06] 益田周防海「JC-STAR と IEC 62443 の矛盾」「太陽光発電所の信頼境界」(2026-07)。 https://www.i-s3.com/jc-star-iec62443-contradiction.html
- [X07] 株式会社I-S3「メーカー 21 社への公開仕様照会」(2026-10-17) と回答状況。 https://www.i-s3.com/jc-star-manufacturer-inquiry-20261017.html
Suomi Masuda / I-S3 Co., Ltd. Based on public sources, written answers received from the authorities and an open calculation model. Not an evaluation of a specific product or company, and not advice for a specific contract, lawsuit or investment.