123% more reported CVEs per day in 2026 than last year.

Supply chain

Selling software to Japanese critical infrastructure

Two Japanese cybersecurity changes took effect on October 1, 2026. Neither is aimed at foreign software vendors, but both raise what critical infrastructure operators expect from the companies that supply them. Here is what changed, what your customers can now ask you for, and which of those requests your build can answer.

Updated

What changed on October 1, 2026

The two changes are often described as one, but they have different legal footing and different audiences.

Active Cyber Defense law Unified Standards
What it is Act No. 42 of 2025, in Japanese サイバー対処能力強化法 A standard decided by the Cybersecurity Strategic Headquarters on July 31, 2026
Who it addresses Designated operators of core infrastructure (基幹インフラ) Government agencies and, through them, operators in 16 critical infrastructure sectors
What it asks for Notifying key assets and reporting incidents to the government Cross-sector security measures, from governance and supply chain risk to vulnerability management
How it binds Legal duties with penalties Not enforceable by itself. It reaches operators through the safety standards of each sector

The 16 sectors are information and communications, finance, aviation, airports, railways, electric power, gas, government services, medical services, water, logistics, chemicals, credit, oil, ports and postal services.

Alongside the standards, Japan's National Cybersecurity Office published a guideline for writing those safety standards, also in effect from October 1. It is the most useful document for a supplier, because it spells out what operators are expected to do about the companies they buy from.

Why this reaches suppliers

The obligations sit with the operator, so the effect on you is commercial rather than legal: it arrives as contract terms, procurement criteria and questionnaires. What applies to a given customer depends on its sector and on its own safety standards, so ask the customer rather than assuming.

The Unified Standards tell operators to understand how their critical systems depend on the supply chain, to know where their suppliers stand on security, and to set out security requirements when they buy products and services. The guideline turns that into specific items.

What operators can ask you for

The guideline separates measures operators should take from measures that are desirable. The table shows both, with the part of the evidence that can come out of your build.

What the guideline describes Level Evidence from the build
Security requirements written into contracts, with examples such as how serious vulnerabilities are handled and reported (2.9 ②-2) Should take A record of each vulnerability from triage to the fixed release
Suppliers of purchased systems report, handle and disclose vulnerabilities under the maintenance contract (3.6 ①-2) Should take Ongoing monitoring of what you shipped, and the releases each vulnerability affects
A way to share information quickly with the supplier when a vulnerability or incident is found (2.9 ③-3) Should take Build history that shows which releases contain a package
Where procurement needs transparency, asking the supplier to create and provide an SBOM (2.9 ③-4) Desirable An SBOM from each build, exported as CycloneDX or SPDX
Confirming that the supplier develops under secure software development practices (2.9 ③-4) Desirable Isolated build jobs and an enforced egress policy

Does Japan require an SBOM?

Not under the Unified Standards, which do not mention SBOMs. The guideline names them as an option: an operator that needs transparency in procurement can ask a supplier to create and provide one, and it points to METI's SBOM guide, version 2.0. A request is still likely to be worth meeting, because a contract can make an option binding on you.

Other things your customer may look for

  • Third-party evaluation. The guideline suggests using outside evaluations to reduce the work of checking suppliers. It names ISMS conformity assessment and the SCS evaluation scheme from METI and the National Cybersecurity Office, which is planned to start around the end of Japan's fiscal 2026.
  • Product and service schemes. It also points operators to JC-STAR for IoT products, ISMAP for cloud services and JISEC for IT products when they set selection criteria.
  • Vulnerability assessments. Operators run periodic assessments of their own systems, and contract terms can extend assessment and reporting to you.
  • Data terms. Contracts can cover where data is located, stored, kept, transferred and disposed of.

What this means if you already prepare for the CRA

Much of the work carries over. The EU Cyber Resilience Act is a separate regime with obligations of its own, so meeting it does not satisfy what a Japanese customer asks for. But both come down to the same questions: what is in the software you shipped, which releases a vulnerability affects, and what you did about it. If those answers come from your build, you can reuse them for a Japanese customer rather than assemble them again.

Where CRACI fits

CRACI records what each GitHub Actions job actually pulled in and produces an SBOM from the build, then monitors what shipped and tracks vulnerabilities from triage to a fixed release. That gives you evidence for the requests in the table above.

It covers only part of what an operator may expect. CRACI does not run vulnerability assessments or penetration tests, does not patch deployed systems and does not report to Japanese authorities. It does not make you compliant with any sector standard. CRACI is hosted in Europe, and ISO/IEC 27001 is the only certification it holds, so check both against your customer's data terms and selection criteria.

Japan critical infrastructure: frequently asked questions

Does Japan's Active Cyber Defense law apply to foreign software vendors?

Its notification and incident reporting duties fall on designated infrastructure operators. A supplier is more likely to feel it through what those customers ask for in contracts, so check with the customer and with your legal adviser.

Are the Unified Standards mandatory?

Not by themselves. They mainly address government agencies and set out what sector safety standards should contain, so what binds an operator depends on its sector.

Which sectors are covered?

Sixteen: information and communications, finance, aviation, airports, railways, electric power, gas, government services, medical services, water, logistics, chemicals, credit, oil, ports and postal services.

Does Japan require an SBOM?

Not under the Unified Standards, which do not mention SBOMs. The guideline for safety standards names an SBOM as something an operator can ask a supplier for, and a contract can make that binding.

What does the vulnerability management section ask for?

Section 3.3.6 of the Unified Standards asks operators to check whether vulnerabilities affect systems in operation, assess their systems periodically and set patching procedures, taking into account that AI shortens the time from discovery to exploitation.

Does CRA preparation cover Japanese requirements?

No, but much of the evidence carries over. SBOMs, the record of which releases a vulnerability affects and the record of how it was handled are useful in both cases.

Evidence your customers can ask for

Get SBOMs and vulnerability records from every GitHub Actions job, without writing them by hand.

Book a demo