```meta
description: How much of a cyberattack can a JC-STAR label actually stop? A technical and quantitative review of AI-enabled attack capability, cloud compromise, IEC 62443 boundary protection, and whether tying the label to Japan's grid code is justified. Checking where a device was made tells you nothing about who will attack it.
keywords: JC-STAR,grid code,IEC 62443,boundary protection,cybersecurity,solar inverter,battery storage,power grid,AI cyberattack,supply chain,distributed energy resources,cyber resilience
verdict: **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.
share_text_en: Checking where a PCS was made tells you nothing about who will attack it. Auditing the development process does not stop intrusion during operation. We tested what Japan's JC-STAR★1 grid-code requirement (comments due 6 Nov 2026) does and does not protect, using the regulators' own written answers and an open model.
share_text_ja: 製造国を調べても、攻撃者の国籍は分からない。開発工程を調べても、運用中の侵入は防げない。JC-STAR★1 の系統連系要件化（意見募集 2026年11月6日締切）が何を防ぎ、何を防がないかを、IPA・資源エネルギー庁の文書回答と公開モデルで検証した。
```
# Product audits cannot protect the power grid: boundary protection and effective cybersecurity in the age of AI

Does making JC-STAR★1 a precondition for grid interconnection (e-Gov case 620340012, comments accepted until 6 November 2026) protect Japan's power system from cyberattack? A review based on public primary sources, written answers from the authorities, and a reproducible model.

## Executive summary

:::verdict
**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. **★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].
2. **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).
3. **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).
4. **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].
5. **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.
6. **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.

:::fact
- **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].
:::

:::inference
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

![Figure A](figures/fig02_origin_vs_attack_path.svg)

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.

:::fact
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 | — |

:::inference
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

![Figure B](figures/fig03_audit_scope_vs_operation.svg)

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

:::fact
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].
:::

:::evaluation
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)

1. Which attack paths, specifically, does the government assess as prevented by investigating the manufacturer or the development process?
2. Did the design consider that excluding products of a particular country still leaves third-country pivots and cloud compromise open?
3. What threat model was adopted on the premise that the attacker's nationality or location need not match the product's country of manufacture?
4. Was the cost-effectiveness of product audit compared with that of IEC 62443 boundary protection?
5. Is the spread of AI-enabled attack capability reflected in the assessment of the requirement's effectiveness?
6. For attacks that manufacturing/development audits cannot prevent, which scheme or technology is planned to prevent harm?
7. 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

:::fact
**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

:::inference
This article does not rely on a claim that autonomous attacks are happening. It relies on three points, each confirmed by primary sources.

1. **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.
2. **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.
3. **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.

:::fact
**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.
:::

:::inference
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.
:::

:::evaluation
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](figures/fig01_attack_paths.svg)

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.

:::inference
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.
:::

:::evaluation
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

![Figure 2](figures/fig04_cert_vs_boundary_models.svg)

**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.

:::fact
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 |

:::inference
★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

![Figure 3](figures/fig05_boundary_protected_der.svg)

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

:::warning
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.
:::

:::proposal
**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".

1. Define the DER control zone in the IEC 62443-3-2 sense and concentrate external communication in a boundary device on the conduit.
2. The boundary device holds an allow-list of destination, protocol, function code and rate; write commands are limited to the grid operator's path.
3. A local EMS holds the default behaviour on loss of communication and a floor on output step changes, with manual recovery.
4. Boundary-device types are not consolidated to one per operator; updates are staged.
5. 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.

:::warning
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 |

:::inference
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

:::fact
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].
:::

:::evaluation
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".

\[ C_A = \frac{F_{cert} + F_{int}}{N_{units}\, T_{valid}} \cdot \frac{P}{P_{unit}} + \lambda\, d_A\, P\, CF \cdot 24 \cdot v \]

**Model B (boundary-centred)**: annualised boundary device plus operations plus (short) replacement delay.

\[ C_B = \frac{K_B}{L_B} + O_B + \lambda\, d_B\, P\, CF \cdot 24 \cdot v \]

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_A = S\, s_{cloud}, \qquad R_B = S\, s_{cloud}\,(1-\rho), \qquad R_B^{cm} = S\, 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`.)

![Figure 5](figures/fig07_cost_comparison.svg)

:::inference
**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.
:::

![Figure 4](figures/fig06_blast_radius.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].)

:::inference
**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

:::fact
- 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 |

:::evaluation
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)

1. **Proof of protective effect.** Which attacks, specifically, does mandatory JC-STAR certification prevent, and what risk reduction is expected?
2. **Comparison of alternatives.** Against IEC 62443 boundary protection and system-level safety assessment, what was the basis for adopting the current scheme?
3. **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?
4. **Conditions for review.** What harm, cost overrun or malfunction of the certification scheme would trigger revision or withdrawal of the interconnection requirement?
5. **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.

:::evaluation
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:

1. **Product certification and operational safety are not the same thing.** This is not our opinion; it is IPA's written answer [J05].
2. **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.
3. **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].
4. **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.
5. **If the interconnection requirement is kept, necessity, additional safety and cost-effectiveness must be shown.** None has been documented to date [G10].
6. **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.