💡 IACS UR E27 IEC 62443 ISO/IEC 42001 · 23894 · 27090 Supplier & Class Approval

IACS UR E27 Asks You to Prove Up to 41 Applicable Security Capabilities — None of Them Inspect the Model

UR E27 asks equipment suppliers to demonstrate by test up to 41 applicable security capabilities. Much of its verification framework relies on repeatable and predictable test outcomes — an assurance challenge for probabilistic systems now arriving at class review.

Julius

Maritime Technical Consultant · Shipboard Cybersecurity & Compliance
- LinkedIn : https://www.linkedin.com/in/abysstoinfinity

IACS UR E27 tells equipment suppliers to demonstrate, by test, that their system provides a defined list of security capabilities. Each capability is mapped clause-by-clause to IEC 62443. It is a precise document. And that precision rests on an assumption: that software is deterministic.

Primary source: UR E27 Rev.1, 20pp, full-text verified IEC 62443 cited 58× "AI" cited 0× 4 capabilities in direct conflict Clause 3.1.3 — the opening already there Suppliers · Yards · Owners · Class

---

1. First, UR E26 and UR E27 Are Different Documents

They came into force around the same time and their titles are similar, so they are often discussed as one. But they address different readers.

UR E26 — the vessel

Zones and conduits
Integrated risk assessment
Owner's obligations in service

Reader: yards, integrators, owners

UR E27 — the product

Security capabilities per CBS
Documents the supplier submits
Type approval and factory test

Reader: the equipment supplier

UR E27 clause 1.3 defines its scope as "computer based systems specified in UR E26." E26 draws the ship; E27 fills in the parts. A two-tier structure.

A footnote in UR E27 Rev.1 records that the April 2022 edition was withdrawn before it came into force on 1 January 2024, and that Rev.1 is to be uniformly implemented by IACS Societies on ships contracted for construction on or after 1 July 2024.

2. I Ran a Full-Text Sweep of All 20 Pages

For this article I extracted the complete text of UR-E27-Rev.1-Sep-2023 and counted terms.

Search term	Occurrences
artificial intelligence / machine learning	0
neural / training data / autonomous	0
supply chain	0
IEC 62443	58
supplier	24
software	37
integrator	9
zone / conduit	6 / 1

Here the decisive contrast with its sister document appears. The body of UR E26 never mentions "62443" once — it absorbs the zone and conduit concepts without citing their source. UR E27 cites IEC 62443 fifty-eight times. Not as conceptual acknowledgement, but as clause-level mapping. Each capability carries a parenthetical source such as (IEC 62443-3-3/SR 3.5). The SDLC requirements in section 5 name 62443-4-1 processes directly.

UR E27 is the most explicitly 62443-anchored document in the IACS cyber framework.

That is a strength — and the origin of the constraint.

IEC 62443 was written for industrial automation and control systems, and in that world software returns the same output for the same input.

That AI appears zero times is not, in itself, a defect. It is technology-neutral drafting. The problem lies elsewhere: UR E27 is a document that demands capabilities be proven by test, and a test cannot be neutral.

---

3. Four Clauses That Collide Head-On With AI

Clause 4.1 sets out 30 required security capabilities; clause 4.2 adds further capabilities that apply when the system connects to untrusted networks. Most apply identically whether or not a model is aboard. Account management, session lock, audit logging and cryptography are needed either way. Four are different.

Capability #20

Deterministic Output

"The CBS shall provide the capability to set outputs to a predetermined state if normal operation cannot be maintained as a result of an attack. The predetermined state could be: unpowered state, last-known value, or fixed value." (IEC 62443-3-3/SR 3.6)

The clause is named "deterministic output." Its structure is: (a) detect that normal operation cannot be maintained, then (b) transition to a safe state.

(b) is implementable in an AI system. A fallback that discards model output and holds the last-known value is a design you can build. (a) is the problem. In a probabilistic inference system, what determines that "normal operation cannot be maintained"?

poisoned training data → anomaly reclassified as normal → process alive, outputs in range → fallback never fires

The failure SR 3.6 anticipates is inability to function.
The characteristic failure of AI is the confident wrong answer.

Capability #39

Input Validation

"The CBS shall validate the syntax, length and content of any input data via untrusted networks that is used as process control input or input that directly impacts the action of the CBS." (IEC 62443-3-3/SR 3.5)

This clause reads as though it were aimed squarely at prompt injection and adversarial examples. It is not.

▸ An adversarial example has valid syntax. It is a legitimate sensor reading, a legitimate image file.

▸ Its length is normal — a well-formed packet of the expected size.

▸ Its content is formally valid — values sit within physically plausible ranges.

What is malicious lives at the semantic layer. An input that looks ordinary to a human has been tuned precisely enough to cross the model's decision boundary. A syntax, length and content validator passes it. It was designed to pass it.

Layered on top of this is the difficulty of defence itself. NIST AI 100-2 E2025, "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations" (finalized March 2025) sets out mitigations for each attack category — and pairs each with an assessment of that mitigation's limitations. Prompt injection, direct and indirect, is treated as its own attack class against generative AI. In short: at present, input validation is presented as a way to reduce risk, not as a way to eliminate the threat.

UR E27 says validate. The supplier fits a validator. The test passes. The threat remains.

Capability #18

Malicious Code Protection

"The CBS shall provide capability to implement suitable protection measures to prevent, detect and mitigate the effects due to malicious code or unauthorized software." (IEC 62443-3-3/SR 3.2)

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.

Capability #19

Security Functionality Verification

"The CBS shall provide the capability to support verification of the intended operation of security functions and report when anomalies occur during maintenance." (IEC 62443-3-3/SR 3.3)

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

☑ The hardware component where it is installed
☑ Brand / manufacturer
☑ Model / type
☑ Short description of functionality / purpose
☑ Version of software

That is the full list.

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

"Necessary test setup (i.e. to ensure the test can be repeated with the same expected result)."

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).

Note: SR here is 62443-4-1's "security requirements specification" — a different abbreviation from the SR (system requirement) that appears in the capability table above, which belongs to 62443-3-3.

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.

listed as "manufacturer / model / version" → passes reproducible 3.1.4 test → malware scan clean for #18 → on paper, fully compliant

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:

· A document defining the system's purpose, scope, data sources and limitations

· Validation reflecting real routes and seasonal conditions — laboratory scenarios alone being insufficient

· Documentation of known failure modes such as sensor dropout, AIS spoofing and degraded GNSS

· Traceable versioning with rollback capability, plus re-assessment on significant updates or material performance drift

Note: this is an individual expert contribution, not an official class rule.

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.

Certifiable

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.

Most practical point of contact

Requiring a 42001 certificate as supporting evidence in the section 5 SDLC review. Just as IEC 62443-4-1 evidences maturity in secure development processes, ISO/IEC 42001 evidences maturity in AI development and operational governance.

Guidance

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.

FDIS · Guidance

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:

☑ Protect against the same threats as the original requirement
☑ 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)

· Start by confirming whether your product contains learning-based components. If condition monitoring, anomaly detection or optimization functions use a trained model rather than fixed thresholds, this applies to you.

· Consider voluntarily recording model identifier, training data provenance and retraining history in the 3.1.1 inventory, separately from the software version. It is not required — but building it once it is required is too late.

· Prepare compensating countermeasures in advance for capabilities #39 and #20 under 3.1.3. These are not arguments to improvise in a review meeting.

· ISO/IEC 42001 certification is optional today. The rate at which it converts into a procurement requirement is worth watching.

Shipyards and system integrators

· Check whether the words "AI" or "learning" appear in the 3.1.3 description you receive from suppliers. If they do not, but the functional description says the system "automatically learns and detects anomalies," ask.

· When designing UR E26 zones, check whether learning-based CBSs connect to untrusted networks (shore data links). If they do, the additional capabilities in clause 4.2 — #39 in particular — are triggered.

Owners

· Decide whether newbuilding specifications will require ISO/IEC 42001 or equivalent AI governance evidence. UR E27 does not require it. If you want it, it has to come through contract.

· The owner's obligation under UR E26 to keep the in-service risk assessment updated is safest read as applying to model drift as well.

Classification societies

· The AI application criteria for 3.1.4's "demonstration of compliance by analytic evaluation" need to be settled internally.

· Society-level approaches are beginning to diverge. The longer IACS-level coordination takes, the heavier the burden on suppliers.

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

· IACS UR E27 Rev.1 (Sep 2023), "Cyber resilience of on-board systems and equipment," 20pp — primary source, full text verified

· IACS UR E26 Rev.1 (Nov 2023), "Cyber resilience of ships" — for scope comparison

· ISO/IEC 42001:2023, Information technology — Artificial intelligence — Management system

· ISO/IEC 23894:2023, Information technology — Artificial intelligence — Guidance on risk management

· ISO/IEC FDIS 27090, Cybersecurity — Artificial Intelligence — Addressing security threats and compromises to artificial intelligence systems

· NIST AI 100-2 E2025, "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations," 24 March 2025

· IEC 62443-4-1:2018, Secure product development lifecycle requirements

· Anil Kumar Korupoju (IRClass), "Why AI in maritime safety requires class discipline," Cyprus Shipping News, 31 March 2026

· ClassNK, Guidelines for Automated/Autonomous Operation of ships (2018 provisional / 2020)

Disclaimer — This article is an analysis based on published standards and secondary sources. It does not represent the official interpretation or approval criteria of any classification society. In application, confirm the latest guidance of the relevant society and the conditions of the individual project.

#IACSURE27 #MaritimeCybersecurity #IEC62443 #ISO42001 #AIGovernance #OTSecurity #ShipbuildingCompliance

Julius

Maritime Technical Consultant · Shipboard Cybersecurity & Compliance

Owner-side maritime cybersecurity advisor covering IACS UR E26/E27 compliance, zone and conduit design, and OT/IT security architecture for commercial vessels — working across LR, ClassNK, DNV, ABS, and BV newbuilding projects.

🌐 More Articles ↗

⚓ Join the ShipPaulJobs Community

Join →