Uzbekistan Medical Device Registration: Software and Cybersecurity Documentation

1. Key takeaways

Item 2.13 of Annex 3a of Resolution No. 738 sets out a distinct group of requirements for dedicated software: verification and validation results, software architecture and life cycle information, cybersecurity measures covering integrity controls, access controls, data protection, and tamper resistance, identification and marking, manufacturer test results, and a compliance tracking system. At the same time, several items of Annex 3a are explicitly stated not to apply to software, but cybersecurity and verification and validation are not among them: they are the core questions every software device must answer. Registration Order No. 3888 reinforces the software identity framework by requiring each device to carry a single GMDN code and a single UDI code and by bringing software versions into the device identity information.

2. Legal basis

3. Expert insights

Insight 1: the center of gravity of a software dossier shifts from manufacturing to verification and cybersecurity. In Annex 3a, item 2.3 (the production-related parts of manufacturer information) and item 2.4 (development and production information, including technical drawings and the process flow) do not apply to software. This is not a lowering of the bar but a relocation of scrutiny to the risk dimensions specific to software: whether functions are realized as designed, addressed by verification and validation; whether the structure is traceable, addressed by the architecture and life cycle information; and whether the product resists attack and tampering, addressed by the cybersecurity measures. A software dossier built around a hardware-style manufacturing narrative will answer questions the reviewer is not asking and leave the real ones open.

Insight 2: cybersecurity is broken down into four concrete directions. Item 2.13 refines the cybersecurity measures into integrity controls, access controls, data protection, and tamper resistance. These four can be used directly as an evidence checklist: each direction corresponds to a set of measures and supporting verification evidence, and a missing direction is a missing item. For each direction, the dossier should state the control implemented, the threat it addresses, and the test or analysis that demonstrates it works, so the reviewer can move from requirement to proof without inference.

Insight 3: the software version enters the device identity, and change management therefore becomes stricter. Registration Order No. 3888 requires a single GMDN code and a single UDI code, and item 2.1 requires a description of the device and its composition. Once a software version is updated, the device identity changes, and an assessment is needed of whether the update triggers a change filing. This echoes the identical configuration requirement applied in the recognition pathway: the software version is part of the configuration. Version discipline in development, mirrored in the regulatory identity, prevents the situation where the marketed version no longer matches the registered one.

Insight 4: the compliance tracking system is a software-specific continuing obligation. Item 2.13 requires information on the compliance tracking system. This means a software device, after certification, must maintain a mechanism that traces the correspondence between software versions and their compliance status, rather than treating the registration as a one-time delivery. The system should record each released version, the evidence set supporting it, and any pending or approved change filings, so that every version in the field can be mapped to a registered state on demand.

4. Practical recommendations

1. Build the software evidence list around the item 2.13 sub-elements: verification and validation, architecture, life cycle, cybersecurity, identification and marking, test results, and compliance tracking.
2. Prepare cybersecurity measures and verification evidence separately for each of the four directions: integrity controls, access controls, data protection, and tamper resistance.
3. Bring the software version number into the device master data and govern it together with the GMDN and UDI codes.
4. Assess before every software release whether the update triggers a change filing, especially where it affects model identification or the intended use.
5. Establish and document the compliance tracking system, stating the correspondence between software versions, change records, and compliance status.

5. Verification checklist

• □ All item 2.13 sub-elements are covered (verification and validation, architecture, life cycle, cybersecurity, identification and marking, test results, compliance tracking)
• □ Cybersecurity is evidenced separately for integrity controls, access controls, data protection, and tamper resistance
• □ The software version number is in the device master data and governed with the GMDN and UDI codes
• □ Software exemptions in Annex 3a have been checked item by item (items 2.3, 2.4, 2.8, 2.19, 2.20)
• □ A mechanism for assessing change filings before software updates is in place
• □ The compliance tracking system is documented and sustainably maintained

GRZAN supports manufacturers, importers, and authorized representatives with medical device registration in Uzbekistan, including software documentation under item 2.13, cybersecurity evidence, and change management for software updates. For assistance, contact info@grzanglobal.com.

Regulatory information verified as of October 29, 2026.