Industrial control systems · OT cybersecurity

OT cybersecurity for systems that have to keep running.

Meridian helps operators, integrators and suppliers turn OT cybersecurity requirements into practical engineering work for industrial projects, product delivery and operational systems. That includes ICS risk, architecture and assurance, using IEC 62443 where it applies.

Cybersecurity usually arrives as a project problem.

The trigger depends on what your organisation is responsible for. Start with the situation your team needs to resolve.

Asset Owner / Operator

Your organisation now owns an OT cybersecurity requirement, but responsibilities, procedures, evidence and engineering priorities are not yet clear.

System Integrator / IACS Service Provider

Your customer specification now requires IEC 62443 evidence, zones and conduits, secure architecture or FAT/SAT cybersecurity, and the engineering team has to respond.

Product Supplier / Product Developer

A customer, product roadmap or certification requirement means you need to establish and evidence a secure product-development process, including relevant IEC 62443-4-1 or 4-2 responsibilities.

OEM / Machine Builder / Package Supplier

Your package has to connect into somebody else's OT environment, and the cybersecurity requirements, interfaces and responsibility split need resolving before delivery.

Turn the requirement into defined engineering work.

The work starts with the installed system and the decision that has to be made, then turns that context into an agreed scope, usable records and evidence for delivery.

Define the work around

  • Scope and system boundary
  • Installed architecture and required communications
  • Operating constraints and project interfaces
  • Responsibilities across the owner, integrator and suppliers
  • Available design, process and verification evidence

Produce decisions and evidence

  • Defined work package and responsibility split
  • Risk, architecture or requirements records
  • Review comments and accountable actions
  • Verification, FAT/SAT or handover evidence
Explore technical capabilities

Different responsibilities. Different IEC 62443 requirements.

Start with the organisation's responsibility for the system, service or product. The relevant IEC 62443 context follows from that role and the agreed boundary.

Asset Owner / Operator

Owns or operates the industrial system and remains accountable for operational risk, governance and acceptance decisions.

  • • IEC 62443-2-1 for the asset owner security programme
  • • IEC 62443-3-2 and 3-3 for system risk, design requirements and verification

System Integrator / IACS Service Provider

Designs, integrates, commissions or maintains industrial automation systems within an agreed customer and project scope.

  • • IEC 62443-2-4 for security programme requirements for IACS service providers
  • • IEC 62443-3-2 and 3-3 where the scope includes system risk, design or verification

Product Supplier / Product Developer

Develops or supplies industrial automation products and is responsible for the product lifecycle and stated component capabilities.

  • • IEC 62443-4-1 for the secure product development lifecycle
  • • IEC 62443-4-2 for technical security requirements of IACS components where applicable

OEM / Machine Builder / Package Supplier

Delivers a machine or packaged system that combines products, integration work and project-specific interfaces.

  • • IEC 62443-2-4 where the organisation performs integration or service-provider activities
  • • IEC 62443-3-2 and 3-3 for the packaged system where system responsibilities are in scope
  • • IEC 62443-4-1 and 4-2 only where the organisation develops products or claims component capabilities

The applicable IEC 62443 publications and requirements depend on the organisational role, system or product boundary, lifecycle stage, contractual requirements and agreed scope. These references do not state certification or compliance.

Frameworks used where applicableIEC 62443NCSC CAFNIS and sector requirementsClient cybersecurity specifications

Industrial context matters.

The detail changes by sector, but uptime, safety, legacy assets, supplier dependencies and controlled change shape what can be done and how it should be evidenced.

From first discussion to agreed actions.

  1. 01

    Arrange a discovery call

    Start with a 30-minute introductory discussion about your system, requirement and project stage. No obligation or payment is required for the call.

  2. 02

    Agree the scope

    Define the system boundary, available evidence, operational constraints and expected deliverables before work begins.

  3. 03

    Review and report

    Assess the evidence, discuss findings with the relevant teams and document practical actions with clear ownership.

How an engagement works

Bring us the requirement, even if the scope is not clear yet

Discuss the project, requirement and current stage in a 30-minute introductory call. Keep sensitive site details out of the booking form.