Japan didn't write its own medical device cybersecurity rulebook. It adopted the international one and made it enforceable. Two standards carry the weight: JIS T 2304, Japan's implementation of IEC 62304, and JIS T 81001-5-1, harmonized with IEC 81001-5-1. One disciplines the software lifecycle. The other embeds cybersecurity inside it.
JIS T 2304 governs the software life cycle for medical devices, mirroring IEC 62304. Manufacturers have to show defined development processes covering planning, implementation, verification, and release. They also need structured software maintenance, meaning vulnerabilities and defects get addressed across the device's whole operational life, plus risk management that traces software decisions back to patient safety outcomes.
For connected devices, the hard part isn't building compliant software once. It's maintaining defensible evidence, year after year, that risk is still being managed. Compliance at release is a moment. The standard describes a practice.
JIS T 81001-5-1 extends that discipline to cybersecurity specifically. The expectations read like a list of everything that can't be bolted on afterward: security requirements identified during design, continuous risk analysis of vulnerabilities and threats, secure implementation and verification, postmarket monitoring, and documentation showing that every risk acceptance or mitigation decision was defensible.
That last item deserves the most attention. The standard doesn't just want fixes. It wants a record showing why you fixed what you fixed and why you accepted what you accepted. Which is exactly the evidence most vulnerability programs never produce.
Read together, the two standards close the loop most programs leave open. JIS T 2304 makes maintenance a formal lifecycle phase with the same weight as development. JIS T 81001-5-1 makes security a property of every phase. You can't satisfy either with an annual assessment and a folder of PDFs, because both keep asking what changed since the last one.
None of this is theoretical. Devices in Japanese hospitals sit on connected networks, use wireless protocols, and talk to cloud and mobile applications. The standards exist because the operating environment demands them.
We built ELTON to produce this evidence continuously instead of episodically. SBOM monitoring runs across device, mobile, and cloud components, so open source and third-party vulnerabilities surface as they're disclosed. That's the maintenance obligation JIS T 2304 describes, running as a background process instead of a quarterly scramble.
Each finding is then mapped to the device's architecture and operational context rather than carried at its generic CVSS score. Context is what turns a no-fix decision from an assertion into an argument, the kind JIS T 81001-5-1 expects you to document. ELTON also analyzes how vulnerabilities chain, because findings that look minor in isolation can escalate when they interact inside an architecture. Connected systems are where that happens.
And the record stays live from premarket testing through postmarket surveillance: vulnerabilities, exploitability analysis, and mitigation actions in one traceable history. Regulators, customers, and auditors all see the same story, which is what makes it credible. Audit week stops being a reconstruction project.
Here's the upside hiding in Japan's approach. Because JIS T 2304 and JIS T 81001-5-1 are harmonized with IEC 62304 and IEC 81001-5-1, the evidence you build for Japan travels. The FDA's Secure Product Development Framework leans on the same lifecycle logic. One disciplined process, one body of evidence, many markets. Manufacturers who treat each jurisdiction as a separate compliance project pay for that choice repeatedly. The ones who run a single process mostly just translate the cover page.
Start with one device. We build the twin from documentation your quality system already produces, run AI discovery remotely, and show you the graph: the handful to fix, and the evidence for everything else.