Proving Security, Function and Recovery by Test
Turning CRA requirements into test conditions, pass criteria and evidence for marine equipment
For a marine equipment maker, the hardest CRA question is not "does the product have a password?" but "when someone attacks it, does it refuse, keep doing its job, and come back cleanly?" Answering that needs tests built for each product, with conditions, pass criteria and records that hold up in front of an authority. This part sets out five test groups, a step-by-step test flow using a networked monitoring panel as the example, and what it takes to run such tests repeatedly.
EU CRA for Marine Equipment Makers: the series
- What the CRA is and how it differs from IACS UR E26/E27
- The CRA in numbers: fines, deadlines and the reporting clock
- From E27 evidence to CRA evidence: what suppliers must add
- Proving security, function and recovery by test (this article)
- A CRA roadmap for marine equipment suppliers
1. Why Paper Evidence Is Not Enough
The CRA asks for effective and regular tests and reviews of product security (Annex I, Part II(3)), and for products that protect the availability of essential and basic functions, also after an incident, including resilience against denial-of-service attacks (Annex I, Part I(2)(h)). UR E27 makes a parallel demand from the ship's side: security measures shall not adversely affect the availability of essential systems, and shall not cause loss of safety, control or monitoring functions (E27 2.3).
Both point to the same thing. It is not enough to show that a security function exists. The supplier has to show what the equipment does when the function is triggered and when something goes wrong: whether readings still update, alarms still raise, outputs stay safe and the unit returns to normal. That means turning each requirement into concrete test conditions and pass criteria for the specific product, then analysing the results, fixing what falls short and testing again.
2. Five Test Groups
These five groups cover most of what a networked marine product needs to demonstrate. The CRA references show which requirement each group supports.
| Test group and basis | What is done to the product | What is measured or observed | Pass criteria and evidence |
|---|---|---|---|
| Unauthorised access and commands Annex I, Part I(2)(d) |
Wrong accounts, commands outside a user's rights and unauthorised connection attempts on management and control interfaces | Whether access or commands are accepted; changes in settings or outputs; audit records | Refused as the role definitions and access policy say. Keep the requests, responses, settings and logs. |
| Malformed input and traffic load Annex I, Part I(2)(f), (h), (j) |
Messages of wrong length, format or order; repeated connections; rising traffic and request rates | Error handling, CPU and memory, response time, restarts, loss or degradation of function | Compared against the protocol specification, availability requirements and risk assessment. Keep the input data, load conditions and product response. |
| Communication loss and reconnection Availability and resilience |
Delay, packet loss and disconnection, then recovery | Data refresh, communication-failure alarm, output state, automatic or manual return to normal | Compared against the behaviour defined for loss and return of communication. Keep the time of failure, inputs and outputs, alarms and recovery time. |
| Update authenticity and integrity Annex I, Part II(7) |
Tampered files, unauthorised updates, packages for the wrong product or version | Whether the package is verified and rejected; whether it installs; effect on existing version and settings | Handled as the approved-package and compatibility policy says. Keep package identifiers and the verification and installation records. |
| Update interruption and recovery Updates and availability, risk-based |
Power or communication cut at each stage of download and installation, then recovery | Boot state, running version, preserved settings, recovery of functions and interfaces | Compared against the product's update and recovery design and functional specification. Keep the stage interrupted, boot result, version and recovery outcome. |
3. A Worked Example: Losing Communication on a Monitoring Panel
Take a networked measuring and monitoring panel, the kind that displays tank levels, temperatures or pressures received over a fieldbus or Ethernet link and raises alarms. A single test run follows four steps, and each step leaves a record.
4. Where It Gets Difficult
- 1 Deciding the test scope. Separating what existing evidence already proves from what needs a new test, for each product variant.
- 2 Setting product-specific criteria. Defining test conditions, acceptable behaviour and recovery criteria for each model, configuration and operating condition. A two-second alarm delay may be fine for one panel and unacceptable for another.
- 3 Interpreting results and confirming fixes. Combining communication captures, logs and input/output records to find the real cause of a failure, then proving the fix worked without breaking something else.
Suppliers that lack in-house test expertise often find these three steps, rather than running the test itself, the main bottleneck.
5. Making It Repeatable: A Test Bench
Because the CRA expects testing again whenever the product or its software changes, a one-off test campaign is not enough. Suppliers with several product lines should consider a reusable bench that can inject faults and measure the product's response automatically. A typical bench has five modules:
| Module | What it does |
|---|---|
| Communication and fault injection | Generates normal and malformed messages; creates delay, loss, disconnection and reconnection |
| Signal generation and measurement | Produces analogue, contact and digital input signals; measures the product's outputs |
| Power control | Cuts and restores power at defined test steps and records the actual power state |
| Observation and logging | Captures data refresh, alarms, contact outputs, boot and recovery states |
| Test execution and reporting | Runs scenarios, aligns all records on one timeline, helps judge pass or fail and produces the report |
Once connections, measurements and records are set up for one product, they can be adjusted for similar equipment from other makers, so the effort pays back across a product range.
※ This article describes a general testing approach. The exact tests and criteria for a product depend on its risk assessment, its specification and, once published, the harmonised standards under the CRA.
Ship engineers already know how to test equipment for function: commissioning and FAT are built on it. The CRA asks for the same discipline applied to the moment security and function collide. A firewall rule that blocks an attack but also blocks the alarm feed is a failure, not a success.
The suppliers who will find the CRA easiest are those who treat security tests as part of functional testing, recorded on the same timeline, rather than as a separate box to tick.
Primary sources:
| Regulation / standard | Type | Link |
|---|---|---|
| EU CRA, Regulation (EU) 2024/2847 | EUR-Lex | View text ↗ |
| IACS UR E27 Rev.1 (Sep 2023) | Download PDF ↗ | |
| CRA requirements–standards mapping | Download PDF ↗ |
Related reading:
Maritime 4.0 · shipyard-side experience in maritime cybersecurity and IACS UR E26/E27 compliance, writing at the intersection of AI, data, and ship cyber resilience.
⚓ Join the ShipPaulJobs Community
Join →
Comments
Post a Comment