Beyond the Alarm: Inside Cequra’s Bet on Maritime Decision-Making

As vessels drown in data but starve for clarity, Andrew Sallay, Co-Founder and CEO of Cequra, explains why the next frontier in maritime cyber-physical risk isn’t detection — it’s deciding what to do next, and proving you were right to do it

Maritime operators have spent the last decade wiring their fleets with sensors, cybersecurity platforms, OT monitors and fleet management dashboards. Yet when navigation, cyber and operational signals start telling different stories — as they increasingly do amid GNSS jamming incidents in the Strait of Hormuz, the Red Sea and beyond — many bridge and shore teams find themselves with more data than ever and no clearer picture of what to do next.

That gap is the reason Cequra exists. Founded to sit above the point solutions already running on a vessel, the company describes itself not as another alarm system but as a “cyber-physical decision layer” — a platform designed to help operators work out which signals to trust, what a conflicting picture actually means operationally, and how to build an evidentiary record once the moment has passed. Maritime Gateway spoke to Andrew Sallay, Co-Founder and CEO of Cequra, about the thinking behind the platform, how it earns operator trust, and why the biggest resistance he encounters is organisational rather than technical.

For readers coming across Cequra for the first time, how would you describe the problem you set out to solve, and what was the gap you saw in the existing maritime tech stack?

Cequra was built around a very practical problem: when something unusual happens at sea, the vessel and shore teams often have more data than ever before, but not necessarily more clarity.

Many maritime operators have invested heavily in digital systems, sensors, connectivity, ECDIS, AIS, OT monitoring, cybersecurity tools and fleet management platforms. But those systems usually operate in separate silos. Navigation systems produce one set of signals. Cybersecurity tools produce another. OT systems produce another. Shore teams may see something different again.

The gap is not simply detection. The gap is decision-making when those signals conflict. Cequra addresses that gap. We help operators answer three questions in moments of uncertainty: what data can we trust, what should we do next, and how do we prove afterwards that the right decision was made?

You’ve described Cequra as a “cyber-physical decision layer” rather than a point solution. Could you unpack what that distinction means in practice for a vessel operator?

A point solution usually addresses one problem in one domain. It may detect GNSS interference, monitor OT assets, identify a cyber anomaly or track AIS inconsistencies. Those tools can be valuable, but they usually produce alerts within their own field of view.

A cyber-physical decision layer has a different role. It sits across those domains and helps the operator interpret what the combined picture means. For a vessel operator, the question is not only, “Did something happen?” It is, “Does this matter operationally, is it connected to anything else, and what should the crew or shore team do now?”

That is the distinction. Cequra is not intended to add another isolated alarm. It is intended to support better decisions when navigation, cyber, OT and operational signals no longer agree.

Digital transformation has given maritime operators more sensors, more systems and more data than ever before. Why hasn’t that translated into more operational clarity, in your experience?

Because data alone does not create clarity. Context creates clarity.

The industry has digitised many parts of vessel operations, but the information architecture remains fragmented. A navigation system, an OT system, a cybersecurity platform and a fleet operations dashboard may all be technically advanced, but they do not necessarily understand each other.

That becomes a real problem during fast-moving situations. The crew may not have time to interpret multiple dashboards. Shore teams may not have the full onboard picture. Different systems may each produce their own alerts. So the challenge is no longer the absence of data. The challenge is knowing which data matters, which data can be trusted, and which action is justified.

When onboard systems start producing conflicting or contradictory signals, what typically goes wrong for a vessel or shore team trying to make a decision in that moment?

The first problem is time. These situations often arise when the bridge team is already under pressure. If the vessel’s reported position, AIS picture, ECDIS display, sensor data or OT status starts to diverge, the team has to decide whether this is a technical fault, a cyber event, GNSS interference or simply a false alarm.

The second problem is fragmentation. The people who hold different parts of the answer may not be looking at the same evidence. The bridge may see one thing, the cyber team another, and the shore team something else.

The result can be delay, overreaction or underreaction. A vessel may continue when it should slow down or escalate. Or it may stop operations unnecessarily because nobody can establish confidence in the underlying data. The real issue is not just the anomaly. It is the lack of a trusted decision process.

Could you walk us through a realistic scenario — GNSS spoofing or jamming, for instance — and explain how Cequra helps a team distinguish a genuine threat from a sensor glitch or false alarm?

A realistic scenario would be a vessel operating in an area where GNSS disruption has been reported. The bridge may begin to see inconsistencies in the vessel’s reported position, traffic picture or navigation data. The crew and shore team then need to determine whether they are facing a genuine external threat, temporary signal disruption, a faulty sensor or a false alarm.

In that situation, the important question is not whether one instrument has produced an alert. The important question is whether the broader operational picture makes sense. Is the vessel behaving as expected? Are systems telling a consistent story? Are there other indicators that support or contradict the initial anomaly?

Cequra brings those signals into context so the team can move from uncertainty to a structured assessment. If the evidence points to a genuine interference event, the team can escalate with greater confidence. If the issue appears isolated, they can avoid unnecessary alarm and focus on verification.

The goal is not simply to detect an anomaly. It is to help the operator understand what is happening, how confident they should be, and what response is proportionate.

You mention correlating issues across cyber, GNSS, AIS, OT and operational systems. How does Cequra actually establish which data source to trust when they disagree with each other?

Trust is not binary. In real operations, the question is rarely whether one system is always right and another is always wrong. The question is how much confidence the operator should place in each source at a given moment.

Cequra looks at consistency across different layers of evidence. Is the data physically plausible? Is it consistent with vessel behaviour? Is it consistent with other onboard systems? Is there a cyber, OT or operational issue that could explain the divergence?

The result is a confidence-weighted view of the situation. The operator is not just looking at raw data. They are looking at the reliability of that data in context.

That matters because maritime operations are cyber-physical. A cyber issue can have a physical consequence. A navigation anomaly can affect safety. An OT issue can create operational or compliance implications. The challenge is interpreting those relationships before they become operational problems.

Is this primarily a detection tool, a decision-support tool, or both? Where does Cequra’s role end and the human operator’s judgement begin?

It is both, but the emphasis is on decision support.

Detection is necessary, but it is not sufficient. Operators do not need another system that simply identifies potential problems. They need help understanding whether an event matters, how it affects the vessel, and what response is proportionate.

Cequra’s role is to detect anomalies, correlate them, assess confidence, support response workflows and create a trusted record. The human operator remains in control of the decision. We are not replacing the master, the bridge team or the shore team. We are giving them a clearer, more defensible basis for judgement.

That distinction is important. In maritime, accountability remains human. Cequra is there to improve the quality, speed and evidentiary basis of the decision, not to remove human responsibility.

How does Cequra integrate with the systems already running on a vessel or at a shore-based operations centre? Is this a retrofit, or does it require new hardware or infrastructure?

Cequra is designed to work with the systems operators already have. We are not asking vessel owners to rip and replace existing navigation, OT, cybersecurity or fleet management infrastructure.

The platform integrates through an onboard edge layer and an API gateway. The edge component allows Cequra to operate close to vessel systems, including in degraded connectivity environments. The API gateway allows data to be ingested from existing onboard systems where integration is available.

That matters because maritime adoption has to be practical. Operators have mixed fleets, different vendors, different equipment ages and different connectivity profiles. A solution that ignores that reality will not scale.

For newbuilds, integration can be planned earlier with the yard, class, vendors and owner. For existing vessels, the approach is more retrofit-oriented and focused on the specific use case, vessel profile and available data sources.

You talk about producing a “trusted record” for response, compliance, claims and post-incident review. Why is this record-keeping function as important as the real-time detection itself?

Because after an incident, the question quickly changes from “What is happening?” to “What happened, who knew what, what action was taken, and was that action reasonable?”

That matters for internal review, insurance, charterer discussions, class, flag, audits, claims and potential disputes. If the evidence is scattered across screenshots, emails, log files, bridge notes and vendor systems, it becomes very difficult to reconstruct the event with confidence.

Cequra’s trusted record is designed to preserve the operational context: what signals were observed, how confidence changed, what recommendations or workflows were triggered, what actions were taken, and what evidence supported those actions.

That is valuable after serious incidents, but also for drills, compliance, near-miss analysis and continuous improvement. In many cases, the ability to prove that the organisation acted responsibly is almost as important as the initial detection.

How do insurers, flag states or classification societies view a solution like this? Is there growing recognition that this kind of trusted, auditable incident record could become a compliance expectation rather than a nice-to-have?

The direction is clearly toward more evidence-based cyber and operational resilience. The maritime industry is moving beyond policy documents and high-level declarations. Owners increasingly need to demonstrate that they understand their systems, can detect relevant anomalies, can respond appropriately, and can produce evidence afterwards.

I would be careful about saying that a trusted cyber-physical incident record is already a universal compliance requirement. It is not. But it is very consistent with where the industry is heading.

Insurers, class, flag states and charterers all care about operational resilience, risk controls and evidence after an event. A trusted record helps convert “we believe we acted properly” into “here is the evidence showing what happened and how we responded.”

Over time, I believe this type of evidence will become increasingly important, not only for compliance, but also because commercial counterparties will want greater confidence that cyber-physical risks are being managed in a disciplined and auditable way.

GNSS spoofing and jamming, and broader cyber-physical vulnerabilities, have been widely discussed following recent geopolitical disruptions in regions like the Strait of Hormuz and the Red Sea. Has that heightened operator interest in what Cequra offers?

Yes, absolutely. The heightened geopolitical risk has made the problem much more tangible.

For a long time, cyber and navigation integrity were often discussed separately. Cybersecurity was treated as an IT or OT problem. GNSS interference was treated as a navigation or regional risk problem. What recent events have made clear is that these issues converge operationally on the vessel.

If the bridge team cannot trust position data, if shore teams cannot see what is happening with confidence, and if systems are producing inconsistent signals, then the operator needs more than another dashboard. The operator needs a way to manage uncertainty.

That is where the conversation has changed. Operators are not only asking whether spoofing or jamming can be detected. They are asking what the vessel should do next: continue, slow down, escalate, switch procedures, notify shore, preserve evidence or prepare for a claim. That is the decision gap Cequra was created to address.

How do you see Cequra fitting alongside existing cybersecurity, navigation and OT monitoring vendors — as a layer above them, or in competition with some of them?

In most cases, we see ourselves as complementary.

There are many vendors solving important problems in cybersecurity, navigation, connectivity, OT monitoring and fleet operations. The issue is that most are optimised for their own domain. Cequra is designed to sit across those domains and help the operator make sense of the combined picture.

There may be overlap with point solutions in some use cases, but that is not the main point. The broader value is helping operators interpret signals across domains, especially when those signals do not agree.

Existing systems generate important signals. Cequra helps the operator decide which signals to trust, what they mean together, and what to do next.

What has adoption looked like so far — which types of operators or fleet segments have been early movers, and what has driven their decision to bring in a system like this?

The strongest pull is coming from operators for whom uncertainty has a direct operational, commercial or compliance cost.

That includes owners with large or high-value fleets, operators with newbuild programmes, and companies operating in regions where GNSS interference and cyber-physical risk are becoming more visible.

We are also seeing interest where there is a specific operational entry point. For some operators, the immediate concern is position integrity. For others, it is cyber-physical incident response, compliance evidence, newbuild documentation or shore-side visibility across the fleet.

That is an important point. We do not expect every operator to adopt a full cyber-physical decision platform on day one. The entry point may be a specific use case. But once operators see the value of correlating data across systems and preserving a trusted record, the broader platform logic becomes much easier to understand.

What’s the biggest resistance point you encounter when talking to vessel operators or shore teams about adopting a decision layer like Cequra?

The biggest resistance is not disagreement with the problem. Most experienced vessel operators and shore teams recognise it quickly. They know that when navigation, cyber, operational or compliance signals conflict, decision-making becomes harder.

The challenge is usually organisational. A platform like Cequra touches several parts of the company: navigation, cyber, compliance, technical operations, fleet management and sometimes risk or insurance. Each function may see the value, but procurement can become complex because budget ownership, technical evaluation and operational sponsorship may sit in different places.

That is why adoption has to be use-case led. Rather than asking an operator to adopt a broad platform all at once, we start with a clearly defined operational problem, such as position integrity, compliance evidence or incident response. That gives the project a clear owner, a measurable outcome and a practical path to deployment.

The key point is that a decision layer should not add complexity. It should reduce it. If it does not help the crew and shore team make faster, clearer and more defensible decisions, then it is not doing its job.