China put structure around medical device cybersecurity earlier than most manufacturers give it credit for. The Cybersecurity Law (CSL) set the national baseline, and the CFDA's 2018 Principles on Guiding Technology Examination of Medical Device Cybersecurity Registration made it specific to devices. The regulator has since become the National Medical Products Administration (NMPA), but the expectation carried over intact: every connected device goes through a formal cybersecurity risk assessment as part of registration review.
The scope is broad on purpose. If your device contains software, connects to a network, or moves patient or operational data electronically, these requirements apply. That covers nearly everything a manufacturer ships today.
Under the 2018 guidelines, a submission must include five things:
And reviewers expect the risk assessment to work at two levels. Software composition, meaning the third-party components you ship. And system architecture, meaning communication interfaces, trust zones, and access controls. A raw CVE list with no architecture story satisfies neither.
None of this should surprise anyone tracking FDA or EU expectations. The artifacts rhyme: architecture descriptions, risk assessments, control documentation, a postmarket process. What changes is the packaging and the reviewer. What doesn't change is the underlying model of the device that all of them describe.
Here's what I think manufacturers miss about the Chinese requirements. Those five artifacts aren't five separate writing projects. They're five views of the same underlying thing: an accurate model of how your device is built and how data moves through it. Get that model right and the documents fall out of it. Get it wrong and you're writing fiction five times.
That's why we start with the digital twin. ELTON builds a full system representation of the device: embedded software, communication paths, external interfaces, and data flows. The network security description and interface documentation the NMPA asks for come straight out of that model instead of being drawn by hand the week before submission.
The risk assessment works the same way. ELTON pulls vulnerability inputs from SBOMs, penetration testing, SAST and DAST, and live threat feeds, then evaluates each finding in the context of the architecture: what the attack path is, whether the component is reachable, whether findings chain into something worse. What comes out is the prioritized, risk-based evaluation the CFDA guidelines describe, not a scanner export with a cover page.
China's expectations don't end at registration. The CSL expects manufacturers to monitor product cybersecurity postmarket and to update their threat assessments as new CVEs are disclosed. So the documentation problem becomes a maintenance problem. The risk assessment you filed starts aging the day it's approved.
ELTON keeps a living record of each product's vulnerability status and security posture. Controls stay mapped to the architecture components they protect. When a vulnerability doesn't require remediation, the justification is stored alongside the system context that supports it, ready to export when an audit or a renewal asks for it. Nothing gets reconstructed from memory two years later.
My read on the Chinese market is simple. The NMPA wants product-specific evidence, maintained over time, and it has little patience for generic checklists. Manufacturers who treat the 2018 guidelines as a one-time documentation sprint redo the work at every renewal. The ones who maintain a real system model do the work once and keep it current. The second group reaches the market faster and stays there with less drama.
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.