Malicious Code Protection
A backdoor embedded in model weights is not code. It is not an executable instruction but an array of floating-point numbers. There is no signature, no CVE, nothing for a static analyser to look at. Whether it even falls within the wording — "malicious code or unauthorized software" — is a question of interpretation. A weights file updated through retraining may be entirely "authorized," formally released by the supplier. Only the training data was contaminated.
Security Functionality Verification
Clause 3.1.7 requires the corresponding document: instructions for how the user can verify correct operation of the system's security functions. Gradual degradation of model performance — drift — does not register as an anomaly in this frame, because the security functions are operating correctly. Access control, logging and encryption all behave exactly as intended. What has tilted is the model's judgement, and that is not what UR E27 defines as a "security function."
4. The Submitted Documents Have No Field for a Model
Clause 3.1 lists the documents to be submitted to the classification society for review and approval. Two are most telling from an AI standpoint: the asset inventory and the test procedure.
3.1.1 CBS asset inventory — what it requires for software components
☑ Brand / manufacturer
☑ Model / type
☑ Short description of functionality / purpose
☑ Version of software
Training data provenance, model architecture, retraining cadence, weights-file hash, the origin of a pre-trained model — none of these has a field. A retrained model may or may not carry a version increment. It depends entirely on whether the supplier treats it as a software release.
3.1.4 Test procedure — reproducibility as a premise
For deterministic systems that is a reasonable demand. For probabilistic systems it is, by definition, difficult to satisfy. Guaranteeing identical output for identical input means pinning inference parameters — and there is no guarantee that a test run that way represents in-service behaviour.
One door that 3.1.4 leaves open is worth noting: "Demonstration of compliance by analytic evaluation may be specially considered." There is practical room for this clause to carry AI systems. What UR E27 does not say is what standard "analytic evaluation" should be held to.
5. The SDLC Requirements Concentrate After Release
Section 5 requires a Secure Development Lifecycle, naming seven stages in prose: requirement analysis, design, implementation, verification, release, maintenance, end of life. The controlled processes actually adopted as normative clauses number seven.
| UR E27 clause | 62443-4-1 | Subject |
|---|---|---|
| 5.1 | SM-8 | Protection of code-signing private keys |
| 5.2 | SUM-2 | Documentation of product security updates |
| 5.3 | SUM-3 | Documentation of dependent component / OS updates |
| 5.4 | SUM-4 | Security update delivery and authenticity verification |
| 5.5 | SG-1 | Product defence-in-depth strategy documentation |
| 5.6 | SG-2 | Defence-in-depth measures expected from the environment |
| 5.7 | SG-3 | Product hardening guidelines |
IEC 62443-4-1 comprises eight practices — SM (security management), SR (security requirements specification), SD (secure design), SI (secure implementation), SVV (security verification and validation), DM (defect management), SUM (security update management) and SG (security guidelines).
What UR E27 carried across into normative clauses is three families: SM, SUM and SG — weight falls on documentation at the release and maintenance end. The design, implementation and verification practices (SR, SD, SI, SVV, DM) were not adopted as normative clauses in section 5.
The implication for AI is direct. Training data provenance and integrity, and model validation methodology, are territory that UR E27's SDLC clauses do not touch. Clause 5.7 (SG-3) requires guidance on "integration of the product, including third-party components" — but whether a pre-trained model counts as a third-party component, and what would be verified if it did, is left undefined.
One more thing. The phrase "supply chain" appears zero times in UR E27. It is a document of supplier requirements written without the word supply chain. Given that AI models almost always arrive from outside — pre-trained weights, open-source frameworks, third-party training datasets — that gap is not a small one.
6. Meanwhile, the Models Are Already Aboard
Everything above assumed AI might enter a CBS. That assumption is already history.
The systems in scope under UR E26 clause 1.3.2 include propulsion, power generation and distribution, steering, fire detection, and bilge and ballast. Across these systems, condition monitoring and predictive maintenance have become a standard feature set in commercial products. What those features do, at their core, is learn normal behaviour and flag departures from it — learning-based anomaly detection. The fact that classification societies have been issuing separate guidance on automated and autonomous operation points the same way: ClassNK published provisional guidelines for concept design of automated/autonomous operation in 2018, and in 2020 a set covering design development, installation and in-service maintenance management.
So some of the systems arriving at a UR E27 review table already contain learning-based components.
7. Classification Societies Are Already Filling the Gap Separately
There is a signal worth watching. While the unified requirements stay silent on AI, individual class practitioners have begun proposing their own frameworks.
Anil Kumar Korupoju of the Indian Register of Shipping (IRClass) proposed a minimum assurance framework for onboard AI in a March 2026 contribution:
Read that last item again. "Re-assessment on material performance drift." It aims precisely at what UR E27 clause 3.1.9 (management of change plan) and capability #19 cannot reach. That it surfaced as a practitioner-level proposal rather than a unified requirement is itself evidence that the gap is real and already causing friction in the field.
The difficulty is that if each society fills it differently, the point of a unified requirement erodes. UR E27 exists so that suppliers do not face different demands from every class society. If the AI portion diverges society by society, suppliers are back to fragmented requirements.
8. This Is Where Three ISO AI Standards Enter
The gap in UR E27 does not have to be closed by amending UR E27. Standards that already exist, or are about to, each cover a different layer.
ISO/IEC 42001:2023
"Is the supplier an organization that manages AI?"
Published in December 2023, the world's first AI management system (AIMS) standard. The essential point is that it is a certifiable management system standard. What ISO/IEC 27001 does for information security, ISO/IEC 42001 does for AI.
Its meaning in a UR E27 context is clear. E27 verifies the capabilities of the product. 42001 verifies the AI governance of the organization that built the product. Annex A of 42001 contains 38 controls across nine areas, A.2 through A.10, and A.10 addresses third-party and customer relationships — including the processes by which an organization manages suppliers and partners that provide or develop AI systems.
ISO/IEC 23894:2023
"AI risk across the whole lifecycle"
Published in 2023, guidance on AI risk management. It inherits the principles, framework and process of ISO 31000 and extends them for AI, covering the entire AI lifecycle from data collection and model training through deployment, monitoring and retirement.
42001 requires that you have an AI risk management process — but is deliberately light on what it should contain.
23894 supplies the contents.
The contrast with UR E27 section 5 — which lists a seven-stage lifecycle in prose but concentrates its actual control processes after release — is instructive. 23894 provides methodology for the front end: the risks of the training-data collection stage, the risks of the model training stage.
One caution: 23894 is guidance. It is not certifiable. It cannot substitute for UR E27's normative requirements, and it should not be asked to. Its proper place is as the methodology you consult while writing the section 5 SDLC documents.
ISO/IEC 27090
"The language for threats #18 and #39 cannot catch"
Its formal title is "Cybersecurity — Artificial Intelligence — Addressing security threats and compromises to artificial intelligence systems," under development by ISO/IEC JTC 1/SC 27. As of July 2026 it remains under development at ISO's FDIS stage (50.20); the final publication date should be confirmed in the ISO catalogue.
The threats it addresses are reported to include data poisoning, evasion attacks, model theft and prompt injection — precisely the set that capabilities #18 and #39 miss. One limitation has been noted: the standard focuses on deliberate, malicious attacks, leaving accidental threats and design flaws outside its scope. Non-malicious degradation such as model drift remains ISO/IEC 23894 territory.
27090 is an informative guidance document and is not certifiable on its own. Even once published, "submit your 27090 certificate" will not be a coherent demand. Its value lies elsewhere — in providing an internationally standardized taxonomy of AI threats.
Why that matters — clause 3.1.3
UR E27 clause 3.1.3 permits a supplier to propose compensating countermeasures where a requirement is not fully met. Those countermeasures should:
☑ Provide an equal level of protection
☑ Not be a control already required elsewhere in the UR
☑ Not introduce higher security risk
When an AI component cannot satisfy capability #39 as literally written, the supplier must propose a compensating countermeasure. But without a common language for defining "the same threats," neither the supplier can argue the case nor the surveyor assess it. That language is what ISO/IEC 27090 supplies. NIST AI 100-2 is worth watching as the equivalent at US federal level.
9. Where the Three Standards Sit
| Layer | Standard | Point of contact with UR E27 | Nature |
|---|---|---|---|
| Organization & governance | ISO/IEC 42001:2023 | Supporting evidence in section 5 SDLC supplier review | Certifiable |
| Risk methodology | ISO/IEC 23894:2023 | Reference methodology when drafting section 5 documents | Guidance |
| Threats & controls | ISO/IEC 27090 (FDIS) | Common language for arguing 3.1.3 compensating countermeasures | Guidance |
42001 asks "are you managing it?" · 23894 asks "how do you identify and
treat it?"
27090 asks "what are you defending against?"
And none of the three replaces UR E27's normative requirements. They are the tools that make the proof E27 demands performable against AI.
10. What to Do Now
Equipment suppliers (OEMs)
Shipyards and system integrators
Owners
Classification societies
11. Closing
UR E27 is a well-built document. It anchored itself in IEC 62443, enumerated capabilities concretely, required them to be proven by test, and even designed an exit — compensating countermeasures — for where they cannot be met. It is a serious attempt to make cyber resilience verifiable.
That same seriousness becomes the constraint in front of AI. Verifiability rests on reproducibility, and reproducibility rests on determinism. Trained models shake the floor beneath.
The conclusion here is not "amend UR E27." Amendment will move at the pace of IACS, and ships will be delivered in the meantime. The conclusion is this — deploy the tools that already exist, so that the proof UR E27 demands can also be performed for AI components. ISO/IEC 42001 for the organization, 23894 for the methodology, 27090 for the threat language.
UR E27 clause 3.1.3 already left the space open. The clause inviting compensating countermeasures is that space.
What is empty is not the clause, but our readiness to fill it.
Sources
Maritime Technical Consultant specializing in shipboard cybersecurity and compliance across the full ship design and build lifecycle. Expertise in cybersecurity architecture, governance, maritime cyber policy, and international relations. B.S. International Affairs, The George Washington University.
🌐 More Articles ↗📌 Field Note — Julius Shin
The problem this article identifies isn't a flaw in the regulation — it's a limitation in the worldview the regulation assumes. UR E27 is designed to verify 41 security capabilities on the premise of deterministic software behavior. But a trained AI model can produce probabilistically different outputs from identical inputs.
Deterministic output (item #20) is required, yet a poisoned model may reclassify an abnormal state as normal, causing the fallback itself to fail. Input validation (item #39) checks syntax, length, and content — but adversarial examples can satisfy every formal criterion while carrying malice only at the semantic layer. Onboard systems already use learning-based anomaly detection for propulsion, power, steering, and ballast monitoring — and these pass certification simply by listing "manufacturer/model/version," with the fact that they're learning-based often never surfacing in any document.
Rather than waiting for the regulation to be revised, the practical path is to bring ISO/IEC 42001, ISO/IEC 23894, and ISO/IEC 27090 into the compensatory measures provision under UR E27 clause 3.1.3.
A common misconception in practice:
"This equipment has E27 type approval, so AI-related risks are already covered." Learning-based components clear the approval process with nothing more than a formal "manufacturer/model/version" entry, and the fact that they are learning-based often goes undocumented entirely.
Key practical takeaways:
- Require suppliers to confirm whether the product contains learning-based components — for condition monitoring, anomaly detection, optimization, or similar functions.
- Prepare compensatory measures under clause 3.1.3 for items #39 (input validation) and #20 (deterministic output).
- Decide at the contract stage whether to require ISO/IEC 42001 or equivalent AI governance evidence in newbuild specifications.
⚓ Join the ShipPaulJobs Community
Join →
Excellent insight. One point that particularly stands out is that UR E27 is not merely asking suppliers to “implement cybersecurity” but to demonstrate objective evidence that security capabilities have been implemented.
ReplyDeleteThe distinction between the baseline 29 requirements and the additional requirements for systems connected to untrusted networks clearly illustrates that compliance is determined by operational context, not by a simple checklist. Ultimately, the real challenge for shipyards and system integrators is not collecting documents, but maintaining end-to-end traceability between supplier evidence, vessel-level design, testing, and the final as-built configuration.
This is exactly where effective systems integration becomes the key to successful E26/E27 compliance.