When the Ship's Identity Was a Writable Field: The FURUNO FA-50 AIS Advisory (ICSA-26-237-07) Through an IEC 63154 and IACS UR E27 Lens

Most ICS advisories describe a device losing control of itself. This one describes a device losing control of who it says it is. The FA-50 broadcasts a Maritime Mobile Service Identity over VHF every thirty seconds, and every radar, chart plotter and ECDIS within range treats that number as the primary key for the vessel it just painted. CISA's advisory says an attacker on the boat's own network can change it. The vendor's mitigation is to lock the boat. There is no patch, and there is not going to be one, because the product stopped being built in October 2020 - eight months before the cybersecurity standard for this equipment class was published.

I have written a lot of these posts about automotive ECUs, avionics LRUs and hydropower SCADA. This is the first maritime one, and the domain turns out to expose something the others mostly hide: what happens when a safety-critical broadcast identity is not protected by anything except the assumption that only friendly people can reach the wire.

The public record

On August 25, 2026, CISA published ICS advisory ICSA-26-237-07 covering the FURUNO FA-50 Class B AIS transponder. The advisory lists the product as deployed worldwide in the Transportation Systems critical infrastructure sector, and marks all versions as affected. Two CVEs, both reserved on August 4, 2026 and published August 25, both assigned by JPCERT/CC as CNA, and coordinated through JVN as JVNVU#95422936.

CVE-2026-59769 — use of hard-coded credentials. CVSS v3.1 base score 9.1, vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H. CWE-798. The CVE text is two sentences and worth reading exactly as written: "FA-50 all versions contain hard-coded credentials. An attacker, who knows the credentials and has access to the vessel's internal network, can operate the settings screen using that credentials to alter the identification number."

The identification number is the MMSI.

CVE-2026-67578 — missing authentication for critical function. CVSS v3.1 base score 7.5, vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N. CWE-306. "FA-50 all versions miss authentication for some configuration. An attacker with access to the vessel's internal network can manipulate the product's settings screen to alter some configuration parameters."

Note what the vectors have in common. Confidentiality impact None on both. Integrity impact High on both. Nothing is being stolen here. Something is being rewritten. That is an unusual shape for a CVSS pair and it is telling you, in the crude language of the metric, that this is not a data-breach finding — it is a data-authenticity finding on a device whose only real output is data.

The remediation section is the part that makes this a systems problem rather than a product problem. Production of the FA-50 ended in October 2020, and FURUNO states software updates will no longer be provided. The vendor's recommended mitigations are that users not connect the product directly to the internet, and that "the vessel on which the product is installed should be properly locked and managed."

Read that last one again. The residual risk control for a CVSS 9.1 integrity defect on a safety-of-navigation device is a door key.

For architecture, the FA-50's own specification sheet is the primary source. It declares conformance to IMO MSC.140(76), IEC 62287-1, ITU-R M.1371-2, ITU-R M.825-3 and IEC 60945 Ed.4. It has a 10/100BASE-T Ethernet port and an RS-422 / IEC 61162-1 serial port. The interconnection diagram puts the Ethernet port on a hub shared with NavNet TZtouch multifunction displays, an FR-8xx5 series radar, and a PC. The external display list includes ECDIS and a pilot plug. The transmitted static data set is MMSI, ship's name, type of ship, cargo, call sign, length and beam, and the position-fixing antenna offset.

So: a small bulkhead-mounted box, IP20, 1.7 kg, sitting on a flat unsegmented marine Ethernet segment alongside the chart plotter, the radar and whatever laptop the last technician plugged in — holding a settings screen that will rewrite the vessel's identity for anyone who knows a password that is the same on every unit ever shipped.

The standards lens

There are four distinct frames that should have caught this, and the interesting thing is that three of them did not exist yet when this device was type-approved.

IEC 62287-1 — the type-approval standard for Class B AIS. This is the standard the datasheet leads with, and it governs the operational and performance requirements for Class B CSTDMA shipborne AIS on craft outside the SOLAS Chapter V carriage mandate. Its treatment of MMSI is as a static installation parameter: a number issued under a ship station licence, bound to one hull, entered once at commissioning by the installing dealer against a copy of the licence or MMSI registration, and thereafter not a user-adjustable setting. That is a real requirement and FURUNO honoured its spirit at the human-interface layer — the FA-50 has no front panel MMSI editor. What it has is a maintenance path behind a credential. The requirement was satisfied for the operator and quietly unsatisfied for the network.

IEC 63154:2021 — cybersecurity for maritime navigation and radiocommunication equipment. This is the standard that speaks directly to the finding. It specifies requirements, test methods and required test results for a basic level of protection against cyber incidents for shipborne navigational equipment and GMDSS radio equipment, and its general requirements clause covers exactly this class of defect: protection of equipment interfaces against unauthorised access, and authentication controls that are not defeated by shared or factory-set secrets. It was published in 2021. FA-50 production ended in October 2020. The device was never assessable against it, was never required to be, and cannot now be brought into scope because there is no software maintenance channel to change anything with.

IACS UR E26 and UR E27. E26 covers the cyber resilience of the ship as an integrated system; E27 covers the cyber resilience of onboard systems and equipment, including the security capabilities suppliers must document and deliver — network segmentation, access control on the onboard network, and an accounting of default and service credentials. Both became mandatory for ships contracted for construction on or after 1 July 2024. A Class B transponder discontinued in 2020, installed on a fishing boat or a workboat or a yacht, is in scope of neither.

33 CFR Part 101 Subpart F — the USCG Cybersecurity in the Marine Transportation System rule, effective 16 July 2025, with the Cybersecurity Officer designation, cybersecurity assessment and plan approval due by 16 July 2027. It applies to owners and operators of U.S.-flagged vessels and facilities already required to hold a security plan under 33 CFR Parts 104, 105 and 106. The overwhelming majority of hulls carrying a Class B AIS unit are not MTSA-regulated and never will be.

That is the whole structural problem in one paragraph. AIS is a shared safety service whose integrity is set by its least-regulated participant. The Class A transponder on a SOLAS tanker sits inside E26, E27, MSC.428(98) cyber risk management in the ISM safety management system, and possibly the USCG rule. The Class B transponder on the sport fisherman crossing its bow sits inside none of them, transmits into the same VHF data link on the same two channels, and populates the same target table on the same ECDIS.

A worked snippet: the identity-falsification threat scenario

Here is the row I would expect to find in the threat and risk assessment for this device, written in the IEC 62443-3-2 style — asset, threat, consequence, and a security level target derived from the consequence rather than from the component's CVSS.

| Field | Value | |---|---| | Asset | AIS static data store (MMSI, name, call sign, ship type, dimensions), FA-50 | | Zone | Onboard navigation LAN (FA-50, MFD, radar, PC, pilot plug) — currently one flat zone | | Threat agent | Anyone with layer-2 access: crew, contractor, chandler's technician, owner, boarding party, or malware on the shared PC | | Threat scenario | Attacker reaches the FA-50 settings screen over 10/100BASE-T, authenticates with the fleet-wide hard-coded credential (CVE-2026-59769) or with no credential at all on the unauthenticated parameters (CVE-2026-67578), and writes a new MMSI and static data set | | Attack vector | Network, adjacent-to-local; no privilege, no user interaction (AV:N/AC:L/PR:N/UI:N) | | Security property violated | Integrity and authenticity of own-ship identity; non-repudiation of AIS transmissions | | Safety consequence | Corrupted target association on receiving vessels; broken DSC/GMDSS addressing to own ship; degraded SAR response | | Security consequence | Vessel identity laundering — MMSI rotation to fragment the historical track, or impersonation of a legitimate hull | | Detection | None onboard. No alarm, no log, no annunciation. The ALR sentence covers AIS operational alarms, not configuration change | | Existing controls | Physical access control to the vessel; installer discipline at commissioning | | Residual SL-T | SL 2 minimum required (protection against simple means, low resources, generic skills). Achieved SL: 0 |

The detection row is the one I would lose an afternoon arguing about in a review. There is no mechanism anywhere in the chain by which the master of the vessel finds out the number changed. AIS is a broadcast-only transmitter: nothing ever tells you what your own transponder is saying about you.

Fault tree — top event: own-ship AIS identity is falsified and the crew does not know.

TOP: Own-ship AIS identity falsified, undetected by crew
                    |
                   AND
        ________________________
       |                        |
  [G1] Identity written    [G2] Change not annunciated
       |                        |
      OR                       AND
   ____|____            ________|________
  |         |          |                 |
[B1]      [B2]      [B3]              [B4]
Hard-     Unauth.   No config-       No own-ship
coded     config    change event     AIS loopback
cred      params    log in FA-50     display / readback
(CWE-798) (CWE-306) 

[B1] CVE-2026-59769  |  P(access) = f(LAN reachability), P(credential known) -> 1 over time
[B2] CVE-2026-67578  |  no credential required at all
[B3] design omission |  no audit requirement in IEC 62287-1 or IEC 60945 Ed.4
[B4] design omission |  VDO sentence exists on the wire but is not surfaced as a
                       verified identity readback to the operator

The load-bearing observation is that [G2] is entirely built from design omissions, not from CVEs. Patch both CVEs tomorrow and the left branch closes; the right branch is untouched. A device that can have its identity changed and tells nobody is a different failure from a device that can have its identity changed. The advisory only covers the first one.

And [B4] is the cheap fix nobody specified. The FA-50 already emits VDO — own-vessel report — on both the serial and Ethernet outputs. The MFD receives it. Nothing in the chain says "display the MMSI you are currently transmitting, prominently, and raise a caution if it differs from the commissioned value." The data to detect this attack is already on the wire and already arriving at a screen. It is simply not a requirement, so nobody rendered it.

Derived requirements (excerpt)

Five requirements, written the way I would want them in a Class B AIS specification going forward. IDs are stable so they can be traced into a verification matrix.

| ID | Requirement | Verification | |---|---|---| | MAR-CSR-001 | The AIS transponder shall not contain hard-coded, default, or fleet-common credentials for any interface, including maintenance and service interfaces. Every authenticator shall be unique per unit and established at commissioning. | Firmware binary and filesystem inspection across a sample of 10 units from 3 production lots; grep for static credential material; confirm no two units share an authenticator. | | MAR-CSR-002 | Modification of AIS static data (MMSI, name, call sign, ship type, dimensions, antenna offset) shall require authenticated and authorised access. No static-data field shall be writable over any network interface without authentication. | Negative testing against every exposed service on the Ethernet and serial ports; attempt static-data write with no credential and with a credential harvested from a different unit. Both shall fail. | | MAR-CSR-003 | The transponder shall record every static-data modification as a tamper-evident event containing timestamp, changed field, previous value, new value and the authenticated identity that made the change. The log shall survive power cycling and shall not be clearable from the maintenance interface. | Change MMSI, power-cycle 5 times, confirm the event persists; attempt log clear from the maintenance path and confirm rejection. | | MAR-CSR-004 | The transponder shall assert a persistent caution to the connected display, within 60 s of power-up and within 10 s of any static-data change, whenever the transmitted MMSI differs from the commissioned MMSI recorded at installation. The caution shall be acknowledgeable but not silenceable while the mismatch persists. | Bench test with a commissioned reference value; verify annunciation timing on IEC 61162-1 and Ethernet outputs; verify the caution reappears after acknowledgement while mismatch remains. | | MAR-CSR-005 | The onboard navigation network shall be segmented such that the AIS transponder's configuration interface resides in a conduit separate from general-purpose devices (crew PCs, pilot plug, guest network), with the conduit enforcing an SL-T of at least SL 2 per IEC 62443-3-2. | Zone and conduit diagram review at installation; port-scan the transponder's configuration service from the general-purpose segment and confirm it is unreachable. |

MAR-CSR-004 is the one I would fight to keep if a programme manager came at this list with a red pen. It costs almost nothing — one comparison against a stored value and one sentence on an output that already exists — and it converts an undetectable attack into a noisy one. Every other requirement here is prevention. That one is detection, and detection is what you have left when prevention turns out to have been a shared password all along.

What the headline really tells us

The headline is "two vulnerabilities in a discontinued AIS transponder, no patch available." That framing makes it sound like an end-of-life problem, and end-of-life problems feel like somebody else's — the asset owner's, the fleet manager's, the person who should have refreshed the hardware.

It is not an end-of-life problem. It is a scope problem, and the scope was drawn a decade before anyone reached for the word cybersecurity.

When the FA-50 was designed, MMSI integrity was already a requirement. It was just written down in the wrong place. It lived in IEC 62287-1 as an installation constraint, in the dealer's file cabinet as a copy of a ship station licence, and in the shape of a front panel with no MMSI editor on it. Every one of those is a real control. Not one of them is a control that survives contact with an Ethernet port, because the threat model behind all three was the owner might fiddle with it, not someone might reach it.

The missing artifact is not a patch. It is the row in a threat analysis that asks: which of this product's outputs are treated as authoritative by systems outside our control, and what protects the integrity of those outputs when the local network is hostile? For a Class B AIS transponder the answer to the first half is "all of them" — the entire value of the device is that strangers believe what it says. And in 2020 the answer to the second half was a password printed in a service manual.

Everything downstream follows from that gap. The AIS spoofing that Lloyd's List Intelligence tracks across the shadow fleet — MMSI rotation to fragment a vessel's historical track, impersonation of a legitimate hull to defeat a port ban — is usually described as a crew behaviour, something done deliberately by people operating a ship they want to hide. CVE-2026-59769 says it is also a reachability property of an installed base. That is a different problem with a different owner, and the owner is the equipment designer, not the master.

I would like to be able to end this with a patch level. There isn't one. So here is the actionable version instead. If you operate anything with a Class B AIS transponder on it: find out whether that transponder's configuration interface is on the same network segment as anything a person plugs into. If it is, that is your finding, and it is a finding you can close this week with a cable and a switch, which is more than the vendor can offer.

And if you build navigation equipment: go look at what your product asserts about itself to the outside world, and ask what protects that assertion. Not what protects the box. What protects the claim.

— Jherrod Thomas, The Lion of Functional Safety™