MSC.1/Circ.1704: What the New Bridge Software Maintenance Guidelines Cover, and What They Don’t

On 6 July 2026, IMO issued MSC.1/Circ.1704, Guidelines for Software Maintenance of Shipboard Computer-Based Navigation and Communication Equipment and Systems — approved at MSC 111 (13 to 22 May 2026) and developed by the NCSR Sub-Committee. It is the first IMO-level instrument to set a standardised process for how software on bridge and radio equipment gets updated, who is allowed to do it, and what has to be recorded when it happens.

The scope question is the one that matters first, because it decides whether any of this applies to a given piece of equipment at all.

What the Bridge Software Maintenance Guidelines Actually Cover

The Guidelines apply, under paragraph 2.1, to “shipboard computer-based equipment and systems specified or referred to in chapters IV (Radiocommunications) and V (Safety of Navigation) of SOLAS… that are capable of undergoing software maintenance.” In practical terms, that reaches the equipment most ships already carry to satisfy SOLAS V/18 and V/19: ECDIS, VDR and S-VDR, radar and ARPA, AIS, gyrocompass, echo sounder, speed and distance log, and autopilot, together with GMDSS radiocommunications equipment under chapter IV — DSC, NAVTEX, Inmarsat and similar terminals. If it is computer-based, sits on that carriage list, and can receive a software update, it is inside the mandatory scope.

A second, voluntary tier sits in Appendix 3: systems the Guidelines may be applied to at the Company’s discretion, including alarm and monitoring systems for propulsion, ballast transfer valve remote control, bilge level detection, electric power and power management systems, dynamic positioning (equipment classes 2 and 3), and steering control systems, among others. These are not required to follow the Guidelines, but nothing prevents a Company from choosing to.

The Certification, Reporting and Recordkeeping Framework

The Guidelines build a chain of accountability around four roles: the Manufacturer, the Contracted Service Provider, the Certified Service Technician, and the Company. The core obligations:

Technician certification. Anyone carrying out software maintenance must hold a Manufacturer-issued certificate, valid for no more than five years, specifying exactly which equipment and which maintenance methods — onboard, onshore, remote — it covers. The certificate becomes invalid the moment the technician changes employer.

A Plan of approach before the work starts. Prepared by the Certified Service Technician in consultation with the Company, covering the scope of work, risk assessment, HSE requirements, and post-completion validation procedures.

An electronic service report per event, built to the minimum content standard set out in Appendix 1 — ship and equipment details, category and method of maintenance, cybersecurity checks on any removable media used, and sign-off by both the technician and the Company’s representative.

An onboard software log, per Appendix 2, retained for a minimum of five years and linking every maintenance event to its service report. It can be built into an existing inventory management system rather than run as a standalone register.

Cybersecurity conditions on remote maintenance: multi-factor authentication, a controlled-network-only requirement, and the master’s express permission before every individual remote session — not a standing authorisation.

What “Software Maintenance” Does Not Cover

The Guidelines are precise about what triggers all of the above, and it’s worth stating plainly because the term gets used loosely in practice. Paragraph 3.13 defines software maintenance as “updating, re-configuring, and associated checking of the software within shipboard computer-based equipment and systems.” The associated checking referred to there is checking that follows a change — confirming the update installed correctly, confirming interfaces still function — not an independent review of equipment performance carried out on its own.

That distinction matters because two activities that sound adjacent to software maintenance are, in fact, governed elsewhere and untouched by MSC.1/Circ.1704 entirely.

Annual performance testing of VDR and other carriage-required equipment remains governed by its own performance standards — for VDR, resolution MSC.333(90) and the equivalent testing regime — a different instrument, with no certification or service-report requirement under 1704 unless the test itself involves updating or reconfiguring software.

Third-party navigational assessment using VDR and ECDIS data — reviewing what happened on the bridge during a voyage, independent of whether any software was touched — sits under a separate body of guidance entirely, principally OCIMF’s A Guide to Best Practice for Navigational Assessments and Audits. It does not update, reconfigure, or check software as part of a maintenance event, so it falls outside 3.13’s definition regardless of how central VDR data is to the exercise.

One Cross-Reference Worth Checking

Paragraph 4.4 of the Guidelines requires that all software maintenance-related training and operations follow Guidelines on maritime cyber risk management “(MSC-FAL.1/Circ.3, as revised).” At the time 1704 was drafted, that meant Rev.3. MSC 111 — the same session that approved 1704 — also co-approved a further revision, MSC-FAL.1/Circ.3/Rev.4, following prior approval by FAL 50. A Company aligning its software maintenance procedures to 1704’s cybersecurity cross-reference should be working from Rev.4, not an earlier version sitting in an older procedure manual.

What This Means on Board

1. Confirm which of your bridge and radio equipment sits inside the mandatory scope — anything referred to under SOLAS IV or V that takes a software update — and check that your OEMs and service agents can produce a valid Certified Service Technician certificate before the next update is due.
2. Expect an electronic service report per maintenance event, built to the Appendix 1 minimum content, countersigned by your representative and filed against the ship.
3. Set up, or fold into an existing system, an onboard software log retained for five years, linked to those service reports.
4. If any remote software maintenance is used, check that the provider’s arrangements include multi-factor authentication and that your procedures require the master’s permission before each session, not a blanket standing approval.
5. Keep software maintenance and equipment testing or auditing on separate tracks in your documentation. They are different obligations under different instruments, and a Certified Service Technician’s certificate has no bearing on who is qualified to conduct a performance test or a navigational assessment, or vice versa.

The Guidelines close a real gap — software updates on SOLAS-carriage bridge and radio equipment have never had a standardised certification and recordkeeping regime before. What they don’t do is fold every activity that touches that same equipment into one obligation. A performance standard, a maintenance guideline, and an audit framework can all govern the same ECDIS unit without any one of them absorbing the other two.

More from the Amendment Log