Software verkopen aan Japanse kritieke infrastructuur

Wat er op 1 oktober 2026 is veranderd

De twee wijzigingen worden vaak als één geheel beschreven, maar ze hebben een andere juridische basis en een andere doelgroep.

	Active Cyber Defense-wet	Uniforme Standaarden
Wat het is	Act No. 42 of 2025, in het Japans サイバー対処能力強化法	Een standaard die het Cybersecurity Strategic Headquarters op 31 juli 2026 heeft vastgesteld
Voor wie	Aangewezen exploitanten van kerninfrastructuur (基幹インフラ)	Overheidsinstanties en, via hen, exploitanten in 16 sectoren van kritieke infrastructuur
Wat het vraagt	Belangrijke bedrijfsmiddelen aanmelden en incidenten melden bij de overheid	Sectoroverstijgende beveiligingsmaatregelen, van governance en ketenrisico's tot kwetsbaarheidsbeheer
Bindende kracht	Wettelijke plichten met sancties	Op zichzelf niet afdwingbaar. Exploitanten worden bereikt via de veiligheidsnormen van elke sector

De 16 sectoren zijn informatie en communicatie, financiën, luchtvaart, luchthavens, spoorwegen, elektriciteit, gas, overheidsdiensten, medische diensten, water, logistiek, chemie, krediet, olie, havens en postdiensten.

Naast de standaarden publiceerde het Japanse National Cybersecurity Office een richtlijn voor het opstellen van die veiligheidsnormen, die eveneens van kracht is sinds 1 oktober. Voor een leverancier is dit het nuttigste document, omdat het uitlegt wat er van exploitanten wordt verwacht ten aanzien van de bedrijven waarvan ze afnemen.

Waarom dit leveranciers bereikt

De verplichtingen liggen bij de exploitant, dus het effect op u is eerder commercieel dan juridisch: het komt binnen als contractvoorwaarden, inkoopcriteria en vragenlijsten. Wat voor een bepaalde klant geldt, hangt af van zijn sector en zijn eigen veiligheidsnormen, dus vraag het de klant in plaats van het aan te nemen.

De Uniforme Standaarden vragen exploitanten te begrijpen hoe hun kritieke systemen afhankelijk zijn van de keten, te weten hoe het met de beveiliging bij hun leveranciers staat en beveiligingseisen vast te leggen wanneer ze producten en diensten inkopen. De richtlijn werkt dat uit in concrete punten.

Wat exploitanten u kunnen vragen

De richtlijn maakt onderscheid tussen maatregelen die exploitanten zouden moeten nemen en maatregelen die wenselijk zijn. De tabel toont beide, met het deel van het bewijs dat uit uw build kan komen.

Wat de richtlijn beschrijft	Niveau	Bewijs uit de build
Beveiligingseisen die in contracten worden vastgelegd, met voorbeelden zoals hoe ernstige kwetsbaarheden worden afgehandeld en gemeld (2.9 ②-2)	Zou moeten	Een vastlegging van elke kwetsbaarheid, van triage tot de gerepareerde release
Leveranciers van aangekochte systemen melden kwetsbaarheden, handelen ze af en maken ze openbaar onder het onderhoudscontract (3.6 ①-2)	Zou moeten	Doorlopende monitoring van wat u hebt geleverd, en de releases die elke kwetsbaarheid raakt
Een manier om snel informatie met de leverancier te delen wanneer een kwetsbaarheid of incident wordt ontdekt (2.9 ③-3)	Zou moeten	Buildgeschiedenis die laat zien welke releases een pakket bevatten
Waar de inkoop transparantie nodig heeft, de leverancier vragen een SBOM op te stellen en te verstrekken (2.9 ③-4)	Wenselijk	Een SBOM uit elke build, geëxporteerd als CycloneDX of SPDX
Nagaan of de leverancier ontwikkelt volgens veilige softwareontwikkelpraktijken (2.9 ③-4)	Wenselijk	Geïsoleerde buildjobs en een afgedwongen egressbeleid

Vereist Japan een SBOM?

Niet volgens de Uniforme Standaarden, die SBOM's niet noemen. De richtlijn noemt ze als optie: een exploitant die bij de inkoop transparantie nodig heeft, kan een leverancier vragen er een op te stellen en te verstrekken, en de richtlijn verwijst naar de SBOM-gids van METI, versie 2.0. Het is waarschijnlijk toch de moeite waard om op zo'n verzoek in te gaan, omdat een contract een optie voor u bindend kan maken.

Waar uw klant verder op kan letten

• Evaluatie door derden. De richtlijn stelt voor externe evaluaties te gebruiken om het werk van het controleren van leveranciers te verminderen. Ze noemt de ISMS-conformiteitsbeoordeling en het SCS-evaluatieschema van METI en het National Cybersecurity Office, dat naar verwachting rond het einde van het Japanse begrotingsjaar 2026 van start gaat.
• Schema's voor producten en diensten. Ook wijst ze exploitanten op JC-STAR voor IoT-producten, ISMAP voor clouddiensten en JISEC voor IT-producten wanneer ze selectiecriteria vaststellen.
• Kwetsbaarheidsbeoordelingen. Exploitanten beoordelen hun eigen systemen periodiek, en contractvoorwaarden kunnen beoordeling en rapportage uitbreiden naar u.
• Datavoorwaarden. Contracten kunnen regelen waar data zich bevindt en hoe die wordt opgeslagen, bewaard, overgedragen en vernietigd.

Wat dit betekent als u zich al voorbereidt op de CRA

Veel van het werk is herbruikbaar. De EU Cyber Resilience Act is een apart kader met eigen verplichtingen, dus eraan voldoen betekent niet dat u voldoet aan wat een Japanse klant vraagt. Maar beide komen neer op dezelfde vragen: wat zit er in de software die u hebt geleverd, welke releases raakt een kwetsbaarheid en wat hebt u eraan gedaan? Als die antwoorden uit uw build komen, kunt u ze hergebruiken voor een Japanse klant in plaats van ze opnieuw samen te stellen.

De rol van CRACI

CRACI legt vast wat elke GitHub Actions-job daadwerkelijk heeft binnengehaald en maakt een SBOM uit de build, monitort vervolgens wat is geleverd en volgt kwetsbaarheden van triage tot een gerepareerde release. Dat geeft u bewijs voor de verzoeken in de tabel hierboven.

Het dekt maar een deel van wat een exploitant kan verwachten. CRACI voert geen kwetsbaarheidsbeoordelingen of penetratietests uit, patcht geen uitgerolde systemen en meldt niets aan Japanse autoriteiten. Het maakt u niet compliant met welke sectornorm dan ook. CRACI wordt gehost in Europa en ISO/IEC 27001 is de enige certificering die het heeft, dus toets beide aan de datavoorwaarden en selectiecriteria van uw klant.

Kritieke infrastructuur in Japan: veelgestelde vragen

Geldt de Japanse Active Cyber Defense-wet voor buitenlandse softwareleveranciers?

De plichten om aan te melden en incidenten te rapporteren rusten op aangewezen exploitanten van infrastructuur. Een leverancier merkt de wet eerder via wat die klanten in contracten vragen, dus overleg met de klant en met uw juridisch adviseur.

Zijn de Uniforme Standaarden verplicht?

Niet op zichzelf. Ze richten zich vooral op overheidsinstanties en beschrijven wat sectorale veiligheidsnormen zouden moeten bevatten, dus wat een exploitant bindt, hangt af van zijn sector.

Welke sectoren vallen eronder?

Zestien: informatie en communicatie, financiën, luchtvaart, luchthavens, spoorwegen, elektriciteit, gas, overheidsdiensten, medische diensten, water, logistiek, chemie, krediet, olie, havens en postdiensten.

Vereist Japan een SBOM?

Niet volgens de Uniforme Standaarden, die SBOM's niet noemen. De richtlijn voor veiligheidsnormen noemt een SBOM als iets wat een exploitant aan een leverancier kan vragen, en een contract kan dat bindend maken.

Wat vraagt het onderdeel over kwetsbaarheidsbeheer?

Paragraaf 3.3.6 van de Uniforme Standaarden vraagt exploitanten na te gaan of kwetsbaarheden systemen in gebruik raken, hun systemen periodiek te beoordelen en patchprocedures vast te stellen, rekening houdend met het feit dat AI de tijd van ontdekking tot misbruik verkort.

Dekt voorbereiding op de CRA de Japanse eisen?

Nee, maar veel van het bewijs is herbruikbaar. SBOM's, de vastlegging van welke releases een kwetsbaarheid raakt en de vastlegging van hoe die is afgehandeld, zijn in beide gevallen nuttig.