Cybersecurity for Marine Software and Equipment Makers
Ships now run on software from dozens of suppliers, and class rules and EU law expect each supplier to know what is in its software and to keep it secure. CRACI runs your GitHub Actions builds and records every component that goes into each release.
Which rules apply to which marine products
A marine supplier answers to three regimes that overlap but do not coincide: EU product law, classification rules for new ships, and the IMO's guidance for ship operators. Work out which applies to each product before you plan the evidence.
The CRA excludes Marine Equipment Directive equipment
Article 2(4) of the Cyber Resilience Act, Regulation (EU) 2024/2847, says: "This Regulation does not apply to equipment that falls within the scope of Directive 2014/90/EU." That directive, the Marine Equipment Directive (MED), covers equipment placed or to be placed on board an EU ship for which the IMO conventions require the approval of the flag State administration: the wheel-marked equipment. Examples are navigation equipment such as radar, ECDIS, AIS and voyage data recorders, radiocommunication equipment, fire protection and life-saving appliances. Check the current MED implementing list for your own item.
What stays in CRA scope
Products with digital elements placed on the EU market that are not MED equipment: onboard and shore software sold as a product, installed or downloaded; ship operations, accommodation, catering and hotel management systems; crew and passenger service systems; fleet and voyage management software; onboard IoT sensors and gateways; monitoring and automation equipment that does not need flag State approval. Software as a service on its own is outside the CRA unless it is the remote data processing of a product, though NIS2 may still apply to its provider.
Some cases need a legal view rather than a rule: equipment of a wheel-marked type sold for ships that do not fly an EU flag, and products that combine MED equipment with software modules outside the MED.
IACS UR E26 and E27
The unified requirements of the International Association of Classification Societies apply through classification, not EU law. Rev.1 of both applies to ships contracted for construction on or after 1 July 2024. They are mandatory for passenger ships and high-speed craft on international voyages, cargo ships of 500 GT and upwards on international voyages, mobile offshore drilling units and certain self-propelled offshore units, and serve as guidance for other ships. A product outside the CRA because of the MED can still be in E26 and E27 scope, and the other way round.
IMO
Resolution MSC.428(98) asks ship operators to address cyber risks in their safety management systems no later than the first annual verification of the company's Document of Compliance after 1 January 2021. The IMO Guidelines on maritime cyber risk management are non-mandatory, high-level guidance for operators. Their latest revision, of May 2026, says cyber risk management should consider third-party vendors, embedded systems and software and hardware supply chains, and asks operators to establish policies on software and hardware supply chain security for critical systems. That is why operators pass the question on to their suppliers.
| Product example | Wheel-marked (MED)? | Cyber Resilience Act | IACS UR E26 and E27 | What the supplier must show |
|---|---|---|---|---|
| ECDIS | Yes | Excluded (Article 2(4)) | Yes, on new ships in scope | MED approval; E27 documentation and software inventory |
| Engine automation system on a new-build cargo ship | Check | Yes, unless it is MED equipment | Yes: propulsion is a covered system | E27 documentation, inventory and secure development lifecycle; CRA technical documentation and SBOM |
| Hotel and catering management software | No | Yes, when sold as a product | Check: E26 covers its network interface to covered systems | SBOM and vulnerability handling for the CRA |
| Crew welfare network equipment | No | Yes | Check: E26 covers its interface to covered systems | SBOM and vulnerability handling for the CRA |
| Fleet management software as a service | No | Outside, unless it is the remote data processing of a product | No: it runs ashore | Answers to operators' supplier questionnaires; NIS2 may apply to the provider |
| Onboard condition-monitoring sensors | Check | Yes, unless they are MED equipment | Check: in scope when part of a covered system | CRA SBOM; E27 documentation when part of a covered system |
The rule of thumb: if your product needs a wheel mark, the CRA does not apply to it; if it goes on a ship contracted from July 2024, E27 probably does; if you sell software or connected products in the EU, assume the CRA does.
What E26 and E27 ask suppliers for
E27 is the requirement that reaches equipment suppliers directly. Section 3.1 lists the documents a supplier submits to the class society for a computer-based system, among them:
- An asset inventory (3.1.1): the hardware components, with the name, version and patch level of their system software, such as the operating system and firmware, and the software components, each with the hardware it is installed on, its manufacturer, model or type, purpose and software version.
- A description of the security capabilities (3.1.3) and their test procedure, security configuration guidelines, and plans for maintenance, incident response, recovery and management of change.
- Secure development lifecycle documents (3.1.6), which also describe how software updates and patching are handled.
Section 4 sets the required security capabilities, based on selected system requirements from IEC 62443-3-3, such as authentication and protection against malicious code. These are capabilities of the product.
Section 5 requires a secure development lifecycle covering requirements, design, implementation, verification, release, maintenance and end of life, recorded in a document the class society reviews. It must include controls taken from IEC 62443-4-1: protection of code-signing keys (SM-8), documentation of security updates for users (SUM-2), documentation of dependent component or operating system security updates (SUM-3), authentic delivery of updates (SUM-4), and defense-in-depth and hardening guidance (SG-1 to SG-3).
E26 closes the loop at ship level: the vessel asset inventory of hardware and software, with the fields from each supplier's E27 inventory, is kept up to date for the life of the ship, and software and hardware changes that may introduce new vulnerabilities are recorded in it.
What E27 does not say: it does not mention SBOMs. A per-release SBOM is the most precise way to produce the software versions for the inventory and the SUM-3 information on dependent components, but it supports those requirements rather than being one of them.
| E26 or E27 requirement | What the class society or yard expects | Evidence from the build | What stays with you |
|---|---|---|---|
| E27 asset inventory (3.1.1) | Every software component with its purpose and version, and the system software of each hardware component | An SBOM per release, with every component and its version | Which hardware each component is installed on, manufacturer and model details |
| SUM-2 and SUM-3 update documentation | Documented security updates, including for dependent components and operating systems | Vulnerability records and build history for the components in each release | The update notes and advisories you send to users |
| SM-8 and SUM-4 | Protected code-signing keys and authentic delivery of updates | None: CRACI does not sign software | Your signing process and key storage |
| Section 4 security capabilities | Authentication, malicious code protection and other product capabilities | None: these are product features | The product design and its testing |
| Section 5 lifecycle document | A reviewed description of how security is handled in each phase | Records that the release phase is controlled: what each build contained and what it could reach | Writing the document and running the process |
| E26 vessel asset inventory | The ship's inventory, kept up to date for its life | Your SBOM exports, handed to the integrator | Which version is installed on which ship, and the handover to the yard or integrator |
Why marine software is hard to keep track of
Ships outlive projects. A vessel stays in service for decades, and the support burden for the software on board outlasts the project that delivered it, the team that built it and often the supplier's own product line.
Many small suppliers and integrators. A single ship carries software from dozens of suppliers, assembled by an integrator, and every handover is a chance to lose track of what is in each release.
Onboard systems cannot be updated at will. Updates wait for port calls, class approval or a maintenance window, so old versions stay in service long after a fix exists. You need to know which ships still run which version.
Remote sites, limited connectivity. Ships at sea and remote installations are hard to reach, so the record of what was installed has to exist ashore, from the build, not from scanning the ship.
Spreadsheets as the system of record. We hear from marine software makers that SBOMs and related records live in many spreadsheets, kept by hand. They drift out of date with every release.
How to prepare, step by step
Security capabilities such as authentication belong to the product's design. The steps below cover the evidence about the software that goes into it.
- Map each product to its regime. For every product, decide whether it is MED equipment, a CRA product, in E26 and E27 scope, or several of these. The evidence plan follows from that map.
- Produce an SBOM for every release. Record what goes into each release of every product you build, including transitive dependencies, so the software inventory comes from the build and not from memory.
- Keep an inventory per installation. Track which version is installed on which ship and when it changed. This feeds the E27 asset inventory and the integrator's E26 vessel asset inventory, which records changes for the life of the ship.
- Monitor for vulnerabilities and report. Re-check shipped releases as new vulnerabilities are published. For products in CRA scope, reporting of actively exploited vulnerabilities and severe incidents has applied since 11 September 2026.
- Stop known-vulnerable packages entering builds. Block a build that would ship a known vulnerability, so it does not come back through a dependency update.
- Document security updates for customers and integrators. Tell customers and integrators what each security update fixes, including fixes in dependent components and the operating system, as SUM-2 and SUM-3 expect.
Where CRACI fits
CRACI runs your GitHub Actions builds on its own runners and records what goes into each release. That record is the shared evidence behind the CRA, your E27 documentation and your customers' questions.
Every release recorded
Your builds run on CRACI's GitHub Actions runners with runs-on: craci, and the runs still appear in GitHub. While each build runs, CRACI records every package it pulls in, npm and PyPI included, with the hidden dependencies no lockfile lists and a completeness state for each job. SBOMs export as CycloneDX or SPDX with transitive dependencies, declared licenses and the vulnerabilities found in their components: the raw material for the software part of an E27 asset inventory. More on build-time SBOMs.
Keep vulnerable packages out
Policy gates can block a build that contains a specific CVE, and license policy rules can block a build on a license. A known problem is caught in CI, before the release reaches a ship.
Know which releases are affected
CRACI keeps re-evaluating monitored SBOMs as new vulnerabilities are published, and build history shows which builds contained the vulnerable dependency, within your plan's retention, and the inventory view shows which software versions are deployed to which products. Security teams triage each finding and route it to the team that owns the fix. For products in CRA scope, CRACI prepares the content of the CRA notifications, and a person at your company submits them through the Single Reporting Platform.
A build that cannot leak your secrets
Each job runs in its own isolated virtual machine under an egress policy you can set to default deny, validated before the job starts and failing closed. With a default-deny policy, a connection to a host the build does not need is blocked and raises an alert.
When CRACI is not the answer
CRACI is for teams that build software. It does not fit these cases:
- Not for ship operators and owners looking for onboard network monitoring, intrusion detection, E26 compliance at vessel level or documentation for their safety management system. CRACI is for the people who build the software, not for the fleet that runs it.
- Not a CRA programme for MED equipment makers: wheel-marked equipment is outside the CRA. CRACI can still record the software builds behind it for E27 and for customer requests, if they run on GitHub Actions.
- Not for suppliers who do not build on GitHub Actions, who need Windows or macOS build machines, or who need runners inside their own cloud account. CRACI runs managed Linux runners on European infrastructure today; other CI systems, Windows and macOS runners and customer-hosted runners are on the roadmap.
- Not for hardware bills of materials. CRACI records software; it does not manage hardware BOMs.
- Not the E27 security capabilities or a class approval. CRACI does not implement authentication, malware protection or other product capabilities, does not sign software, does not write your secure development lifecycle document and does not deal with the class society for you.
- Not a remediation-metrics tool: CRACI does not report mean time to remediate or remediation deadlines.
Maritime cybersecurity, explained
Common questions about the CRA, IACS UR E26 and E27 and the IMO guidelines for marine suppliers
Does the Cyber Resilience Act apply to marine equipment?
Not to equipment within the scope of the Marine Equipment Directive, 2014/90/EU. Article 2(4) of the CRA excludes it outright. That covers wheel-marked equipment that needs flag State approval under the IMO conventions. Other connected products and software sold for ships, such as hotel systems, crew networks, sensors and fleet software installed on board, can still fall under the CRA.
Which marine products are excluded from the CRA?
Equipment within the scope of the Marine Equipment Directive: equipment placed on board EU ships for which the IMO conventions require flag State approval, such as radar, ECDIS, AIS, voyage data recorders, radiocommunication, fire protection and life-saving equipment. Check the current MED implementing list for your item, and get a legal view for mixed products or ships under other flags.
What is IACS UR E27, and who has to comply with it?
UR E27 is the unified requirement of the International Association of Classification Societies on the cyber resilience of onboard systems and equipment. Rev.1 applies to ships contracted for construction on or after 1 July 2024, and is mandatory for passenger ships, high-speed craft and cargo ships of 500 GT and upwards on international voyages, and certain offshore units. Suppliers of covered systems comply through the class society.
What do E26 and E27 require from equipment suppliers?
E27 asks suppliers for documentation including an asset inventory that lists each software component with its version, security capabilities drawn from IEC 62443-3-3, and a secure development lifecycle with controls from IEC 62443-4-1, such as documenting security updates. E26 is the ship-level requirement: the vessel asset inventory uses the same fields and is kept up to date for the life of the ship.
Does UR E27 require an SBOM?
No. E27 does not mention SBOMs. It asks for an asset inventory that lists each software component with its version, and for documentation of dependent component and operating system security updates. A per-release SBOM is the most precise way to produce that information, but it is not a requirement of E27.
Are the IMO cyber risk management guidelines mandatory?
No. The IMO Guidelines on maritime cyber risk management are non-mandatory guidance for ship operators, revised in May 2026. What is expected of operators comes from Resolution MSC.428(98), which asks them to address cyber risks in their safety management systems, and the guidelines now ask operators to set policies on software and hardware supply chain security.
Does the CRA apply to software sold to shipping companies?
Usually, if it is sold on the EU market as a product with digital elements, installed or downloaded, and is not MED equipment. Software offered purely as a service is outside the CRA unless it is the remote data processing of a product, though NIS2 may apply to its provider. Check the classification of each product.
See what goes into your releases
Book a demo and we will show every component your builds pull in, and which of your releases a new vulnerability affects.
Book a demo