Industrial Cyber Security for UK Design Engineers

Industrial cyber security is often treated as a specialist IT activity that can be added after the control-system architecture has already been designed.

That approach is too late.

Cyber security affects the system boundary, network architecture, equipment selection, remote-maintenance arrangements, safety-system independence, user access, software support, testing, handover and long-term operation of an industrial automation and control system.

These are engineering decisions.

For a design engineer, industrial cyber security is not principally about buying a firewall, installing antivirus software or completing a vulnerability scan. It is about designing an industrial system that can continue to perform its required functions without unacceptable exposure to accidental misuse, equipment failure, supply-chain weakness or deliberate attack.

In the United Kingdom, this work sits within several connected layers:

1. UK legislation and regulation, including the Network and Information Systems Regulations 2018.
2. Regulatory and assurance frameworks, particularly the National Cyber Security Centre Cyber Assessment Framework.
3. Engineering standards, principally the IEC 62443 series and its adopted British and European publications.
4. Project engineering controls, including risk assessments, zones and conduits, segmentation, secure remote access, testing and lifecycle documentation.

The important distinction is:

UK law establishes duties. Regulators define sector expectations. The NCSC CAF describes cyber-resilience outcomes. IEC 62443 provides industrial security processes and technical requirements that can help deliver those outcomes.

These layers support one another, but they are not interchangeable.

Current-status note — 13 July 2026: The Network and Information Systems Regulations 2018 remain in force. The Cyber Security and Resilience (Network and Information Systems) Bill has passed the House of Commons and entered the House of Lords, but it has not yet received Royal Assent and should not be described as current law.¹²

What is industrial cyber security?

Industrial cyber security protects the programmable systems and devices that monitor, control or support physical processes.

These systems are commonly described as operational technology, or OT, and may include:

• Distributed control systems.
• Supervisory control and data acquisition systems.
• Programmable logic controllers.
• Remote terminal units.
• Safety instrumented systems.
• Fire and gas systems.
• Human-machine interfaces.
• Engineering workstations.
• Historians.
• Alarm servers.
• Industrial networks.
• Intelligent electrical devices.
• Protection relays.
• Variable-speed drives.
• Packaged equipment control systems.
• Building-management systems.
• Virtualised control-system servers.
• Remote-access platforms.
• Supporting identity, time, backup and monitoring services.

The consequence of a cyber failure may be physical rather than purely informational.

A compromised industrial system can result in:

• Loss of control.
• Loss of process visibility.
• Unauthorised changes to setpoints or logic.
• Suppressed or falsified alarms.
• Equipment damage.
• Environmental release.
• Unsafe plant conditions.
• Loss of production.
• Loss of utility supply.
• Failure of protective systems.
• Corruption of engineering records.
• Extended recovery because specialist equipment is obsolete or difficult to replace.

The purpose of industrial cyber security is not to make every device invulnerable. It is to reduce cyber risk to a tolerable level while preserving the safety, integrity, availability and recoverability of the process.

IT security and OT security are not the same problem

Modern industrial systems increasingly use standard Ethernet, Microsoft Windows, Linux, virtualisation, cloud services and commercially available network equipment. This creates overlap between IT and OT, but it does not remove the engineering differences.

This does not mean that confidentiality is irrelevant in OT or that availability must always override security. It means that controls must be selected against the real process consequences.

Automatically isolating a compromised workstation may be correct. Automatically isolating a controller during a critical process state could create a more serious hazard than temporarily allowing controlled operation to continue.

The engineering decision depends on:

• The controlled process.
• The safe state.
• The consequence of loss of view.
• The consequence of loss of control.
• The independence of protective systems.
• The operating mode.
• The recovery time.
• The threat being addressed.
• The ability to operate manually or in a degraded state.

The UK industrial cyber-security framework

A useful way to understand the UK position is as a four-layer structure.

The Network and Information Systems Regulations 2018

The Network and Information Systems Regulations 2018, usually called the NIS Regulations, are the main cross-sector UK cyber-security regulations applying to designated operators of essential services and relevant digital service providers.

The regulations cover essential-service sectors including energy, transport, health, drinking water and digital infrastructure, together with specified digital services.³

For an operator of essential services, Regulation 10 requires appropriate and proportionate technical and organisational measures to:

• Manage risks posed to the security of network and information systems supporting the essential service.
• Prevent and minimise the impact of incidents.
• Support continuity of the essential service.
• Provide a level of security appropriate to the risk, having regard to the state of the art.
• Take account of relevant guidance issued by the competent authority.⁴

Regulation 11 imposes incident-notification duties where an incident has a significant impact on continuity of the essential service.

The NIS Regulations do not prescribe a universal network architecture, a particular firewall or blanket compliance with IEC 62443. They establish risk-based duties. Sector competent authorities then provide oversight, guidance and enforcement.

For a design engineer, this means that the project must identify:

• Whether the operator and service are within NIS scope.
• Which systems support the essential function.
• The relevant competent authority.
• The applicable sector guidance.
• The required CAF profile or sector overlay.
• Regulatory reporting and assurance requirements.
• The evidence that the project must produce.

A cyber-security specification that refers only to “NIS compliance” is incomplete unless these points are defined.

Sector competent authorities

The UK NIS regime uses different competent authorities for different sectors and, in some cases, different nations or subsectors.

The exact authority and guidance must be confirmed for the project. Examples include government departments, economic regulators and sector bodies.

In downstream gas and electricity, Ofgem and the Department for Energy Security and Net Zero publish sector-specific NIS guidance and a CAF overlay. Ofgem updated its guidance and reporting material in January 2026, including expectations for risk management, lifecycle security, third-party dependencies, incident reporting and assurance.⁵

A system that is acceptable in one sector may therefore require additional evidence, reporting or assurance in another.

The Cyber Security and Resilience Bill

The Cyber Security and Resilience (Network and Information Systems) Bill proposes substantial changes to the NIS regime.

As of 13 July 2026, it is still a Bill and not an Act. It has completed its Commons stages and is progressing through the House of Lords.⁶

The Bill proposes measures concerning areas such as:

• Managed service providers.
• Data centres.
• Large load controllers.
• Critical suppliers.
• Expanded incident reporting.
• Stronger regulatory and government powers.
• Greater flexibility to update the regulatory scope.⁷

Projects should track the Bill where future operational obligations could affect the system. Proposed duties should not be described as current legal requirements until the legislation is enacted and commenced.

Health and safety law

Industrial cyber risk can also become a health and safety issue.

Where a cyber event can cause dangerous plant behaviour, defeat a protective function or increase the likelihood of a major accident, cyber security forms part of the management of process and functional-safety risk.

Relevant legislation may include:

• Health and Safety at Work etc. Act 1974.
• Management of Health and Safety at Work Regulations 1999.
• Control of Major Accident Hazards Regulations 2015.
• Offshore safety-case legislation.
• Sector-specific safety duties.

The Health and Safety Executive describes cyber security in the major-hazard context as the security of industrial automation and control systems, including basic process-control systems and instrumented safety systems that can initiate or protect against major accidents.⁸

HSE operational guidance OG86 addresses cyber security for industrial automation and control systems and is publicly available to help COMAH operators understand the standards expected by inspectors.⁹

The practical engineering principle is:

A cyber vulnerability capable of defeating, altering or preventing a safety-related function is also a process-safety issue.

The cyber-security process should therefore connect with:

• HAZOP.
• LOPA.
• Safety requirements specifications.
• Safety integrity level allocation.
• SIS independence.
• Cause-and-effect design.
• Alarm management.
• Management of change.
• Proof testing.
• Emergency response.
• Major-accident prevention arrangements.

Cyber security does not replace functional safety. Functional safety does not remove the need for cyber security.

Computer Misuse Act 1990

The Computer Misuse Act 1990 addresses unauthorised access to computer material and unauthorised acts affecting computer operation or data.¹⁰

This is directly relevant when planning:

• Vulnerability scanning.
• Penetration testing.
• Password testing.
• Protocol fuzzing.
• Exploitation testing.
• Red-team activity.
• Supplier or third-party assessment.

Testing must have documented authorisation, scope, boundaries, safeguards and stop conditions.

The fact that a test is intended to improve security does not remove the need for proper authority.

UK GDPR and the Data Protection Act 2018

Industrial systems may process personal data through:

• Named user accounts.
• Physical-access systems.
• CCTV.
• Biometrics.
• Operator logs.
• Audit trails.
• Maintenance records.
• Location records.
• Personnel-monitoring systems.
• Incident records.

The UK GDPR requires personal data to be processed securely through appropriate technical and organisational measures. It also requires data protection to be considered from the design stage and throughout the lifecycle.¹¹¹²

This does not mean every control system is primarily a data-protection system. It means the project must identify where personal data is processed and address:

• Lawful purpose.
• Access control.
• Data minimisation.
• Retention.
• Secure transfer.
• Logging.
• Backup.
• Disposal.
• Breach response.
• Supplier processing.
• Cross-border data transfer where applicable.

A security-monitoring design should collect enough data to support detection and investigation without collecting or retaining personal information without justification.

The NCSC Cyber Assessment Framework

The National Cyber Security Centre Cyber Assessment Framework, or CAF, provides a structured method for assessing how well cyber risks to essential functions are being managed.

CAF 4.0 is the current version as of July 2026. It is intended primarily for organisations operating essential services, UK critical national infrastructure, public functions and other systems where cyber compromise could have serious consequences.¹³

The CAF is outcome-based. It describes what an organisation should achieve rather than prescribing one universal technical solution.

CAF objectives and principles

Objective A — Managing security risk

• A1 Governance.
• A2 Risk management.
• A3 Asset management.
• A4 Supply chain.

Objective B — Protecting against cyber attack

• B1 Service-protection policies, processes and procedures.
• B2 Identity and access control.
• B3 Data security.
• B4 System security.
• B5 Resilient networks and systems.
• B6 Staff awareness and training.

Objective C — Detecting cyber-security events

• C1 Security monitoring.
• C2 Threat hunting.

Objective D — Minimising the impact of cyber-security incidents

• D1 Response and recovery planning.
• D2 Lessons learned.¹⁴

CAF 4.0 uses Basic and Enhanced profiles. The target profile is determined through the relevant oversight or regulatory context rather than selected by the design engineer in isolation.¹³

CAF and IEC 62443 are complementary

The CAF and IEC 62443 should not be treated as rival frameworks.

The CAF assesses outcomes at organisational and essential-function level. IEC 62443 provides industrially specific lifecycle processes, system requirements and component requirements.

A practical, non-normative mapping is shown below.

This is not a formal equivalence table.

Meeting an IEC 62443 requirement does not automatically prove that a CAF outcome has been achieved. A satisfactory CAF assessment also does not automatically establish IEC 62443 conformity.

Understanding the IEC 62443 series

IEC 62443 is not one standard. It is a family of standards and supporting publications addressing different roles and lifecycle stages.

The series is built around shared responsibility between:

• Asset owners and operators.
• Service providers and system integrators.
• Product suppliers.
• Supporting assessors and certification bodies.

An organisation may perform more than one role. The role depends on the activity being undertaken, not merely the company name.

The current published IEC 62443 family

The following table summarises the principal published parts current as of July 2026.

The IEC …4980 tokens truncated…eline.

Hardening must be based on vendor support and process requirements. Generic IT hardening applied without testing can disrupt industrial applications.

Asset inventory and configuration management

An organisation cannot reliably protect systems it does not know it owns.

An OT asset register should contain more than IP addresses.

Useful fields include:

• Asset identifier.
• Equipment tag.
• Manufacturer.
• Model.
• Serial number.
• Hardware revision.
• Firmware version.
• Operating system.
• Installed software and version.
• Physical location.
• System owner.
• Operational function.
• Safety relevance.
• Criticality.
• Network zone.
• IP and MAC addresses.
• Communication protocols.
• Open services.
• Support status.
• Patch level.
• Backup method.
• Recovery priority.
• Dependencies.
• Remote-access capability.
• Replacement availability.

Passive and active discovery

Discovery methods may include:

• Existing engineering records.
• Switch forwarding tables.
• Firewall logs.
• Passive network monitoring.
• Controller configuration files.
• Virtualisation platforms.
• Backup systems.
• Vendor records.
• Physical surveys.
• Carefully controlled active scanning.

Active scanning can affect fragile or poorly implemented industrial devices. The method must be assessed and approved before use on a live control network.

Configuration control

The asset and configuration baseline should be connected to:

• Engineering management of change.
• Hardware replacement.
• Software installation.
• Firmware updates.
• Patch management.
• Project handover.
• Decommissioning.
• Firewall changes.
• Network changes.

Asset management is a lifecycle process, not a spreadsheet produced once for an audit.

Vulnerability and patch management

Patching in OT is not simply slower IT patching.

A patch may:

• Change application behaviour.
• Break a vendor-supported configuration.
• Affect industrial communications.
• Require a restart.
• Interfere with a real-time process.
• Invalidate previous testing.
• Affect safety or regulatory approval.
• Make rollback difficult.

Not patching also creates risk.

The correct approach is controlled and risk-based.

A practical patch workflow

1. Identify affected assets

Map the advisory to the actual:

• Product.
• Version.
• Configuration.
• Enabled feature.
• Installed asset.
• Network exposure.

2. Assess the risk

Consider:

• Exploitability.
• Required access.
• Known exploitation.
• Existing mitigations.
• Zone exposure.
• Process consequence.
• Safety consequence.
• Availability consequence.
• Recovery capability.
• Vendor support.

A CVSS score alone does not determine industrial risk.

3. Obtain supplier guidance

Confirm:

• Whether the update is approved.
• Whether applications remain compatible.
• Whether firmware must also change.
• Whether a restart is required.
• Whether known issues exist.
• Whether rollback is supported.

4. Test

Use an appropriate method, such as:

• Representative test environment.
• Development system.
• Offline redundant node.
• Factory-test platform.
• Staged lower-criticality deployment.

Testing should cover both security and process functionality.

5. Plan deployment and recovery

Define:

• Backup requirements.
• Configuration export.
• Restore process.
• Rollback criteria.
• Maintenance window.
• Operational approval.
• Required specialists.
• Post-installation tests.
• Contingency arrangements.

6. Apply compensating controls when delayed

Compensating controls may include:

• Additional segmentation.
• More restrictive firewall rules.
• Disabling the vulnerable service.
• Removing external connectivity.
• Application allow-listing.
• Increased monitoring.
• Restricted access.
• Replacement planning.

7. Record the decision

The record should include:

• Vulnerability.
• Affected assets.
• Risk assessment.
• Decision.
• Approval.
• Planned action.
• Compensating controls.
• Completion evidence.
• Residual risk.

A decision not to patch is still an engineering decision and must be justified.

Logging, monitoring and threat hunting

Detection requires useful and trustworthy data.

Relevant sources may include:

• Firewalls.
• Network switches.
• Domain controllers.
• Remote-access gateways.
• Windows and Linux hosts.
• Virtualisation platforms.
• Endpoint-security tools.
• Authentication systems.
• Engineering workstations.
• Selected controllers and network devices.
• Physical-access systems.
• Time services.

The design should define:

• Which events are logged.
• Where logs are stored.
• Time synchronisation.
• Retention.
• Access protection.
• Alert thresholds.
• Monitoring responsibility.
• Escalation.
• Investigation process.
• Behaviour during loss of connectivity.

Passive OT network monitoring can provide useful visibility without actively interrogating field devices.

Threat hunting requires enough asset, network and event context to search for abnormal behaviour. It cannot be implemented effectively where the organisation does not know what normal communication looks like.

Backup, recovery and isolation

Backups are only useful if they can be restored.

The design should include:

• Controller programs.
• HMI and SCADA applications.
• Server images.
• Virtual-machine configurations.
• Network-device configurations.
• Firewall configurations.
• Historian configurations.
• Licence information.
• Security keys and certificates where appropriate.
• Engineering tools.
• Documentation.
• Known-good software and firmware.

Backups should be:

• Protected from unauthorised alteration.
• Separated from the live environment.
• Version controlled.
• Periodically tested.
• Available during a cyber incident.
• Supported by documented recovery procedures.

Recovery planning should define:

• Minimum viable service.
• Recovery priorities.
• Required personnel.
• Replacement equipment.
• Offline engineering capability.
• Manual or degraded operation.
• Restoration order.
• Validation after restoration.
• Criteria for reconnecting systems.

An isolation plan should identify how external and inter-zone connections can be restricted during an incident without creating an uncontrolled process hazard.

Supply-chain security

Industrial systems rely heavily on suppliers.

Supply-chain risk includes:

• Vulnerable products.
• Compromised updates.
• Unsupported software.
• Weak remote support.
• Shared supplier accounts.
• Poor vulnerability disclosure.
• Inadequate secure-development processes.
• Unclear end-of-life arrangements.
• Subcontractors with uncontrolled access.

Procurement requirements should request evidence such as:

• IEC 62443-4-1 certification where relevant.
• IEC 62443-4-2 component capability where relevant.
• Secure configuration guidance.
• Hardening guidance.
• Vulnerability-disclosure process.
• Patch-release process.
• Support period.
• End-of-life notice period.
• Supported operating systems.
• Required network services.
• Backup and restore method.
• Default accounts.
• Remote-support requirements.
• Software bill of materials where contractually justified.

A claim that a product is “IEC 62443 certified” is insufficient.

Confirm:

• What was certified.
• Against which part.
• At what edition.
• To what scope.
• By which certification body.
• Whether the supplied version is covered.
• Whether certification covers the development process, component or complete system.
• Whether the product remains supported.

Secure components can still be assembled into an insecure system.

Cyber security across the project lifecycle

Cyber security must be included from project initiation.

Concept and feasibility

Define:

• Legal and regulatory context.
• Essential functions.
• Preliminary SuC.
• Process and safety consequences.
• External connectivity.
• Remote-support needs.
• Required availability.
• Applicable IEC 62443 roles.
• CAF or sector-assurance expectations.
• Preliminary cyber-risk strategy.

Front-end engineering design

Produce:

• Cyber-security design basis.
• Preliminary asset model.
• High-level architecture.
• Preliminary zones and conduits.
• Initial target security levels.
• Remote-access philosophy.
• Identity and access concept.
• Logging and monitoring philosophy.
• Backup and recovery philosophy.
• Product-security requirements.
• Lifecycle-support requirements.

Detailed design

Produce:

• Cyber-security risk assessment.
• Cyber-security requirements specification.
• Detailed network architecture.
• Data-flow diagrams.
• Zone and conduit register.
• Firewall-rule requirements.
• IP address schedule.
• Asset register.
• User and role matrix.
• Hardening requirements.
• Remote-access design.
• Time-synchronisation design.
• Logging architecture.
• Backup and restore design.
• Patch-management plan.
• Vulnerability-management plan.
• Cyber-security test specification.
• Deviation and compensating-control register.

Procurement

Include:

• Applicable standards and editions.
• Role allocation.
• Required product capabilities.
• Secure-development evidence.
• Support-period requirements.
• Vulnerability-notification requirements.
• Patch and update obligations.
• Secure configuration documentation.
• FAT evidence.
• Handover requirements.
• End-of-life notification.

Factory acceptance testing

Cyber-security FAT may include:

• Version verification.
• Unnecessary-service review.
• Default-account removal.
• Password and authentication checks.
• User-role testing.
• Network-port verification.
• Firewall-rule testing.
• Backup and restoration.
• Time synchronisation.
• Logging.
• Failover.
• Remote-access controls.
• Malware-control arrangements.
• Configuration export.
• Secure-build evidence.
• Vulnerability review.
• Documentation review.

Site acceptance and commissioning

Verify:

• Final physical connectivity.
• Switch and firewall configurations.
• Remote paths.
• User accounts.
• Temporary engineering access.
• Wireless interfaces.
• Vendor routers or gateways.
• Time services.
• Log forwarding.
• Backup completion.
• Recovery procedures.
• Asset register.
• As-built drawings.

Temporary commissioning arrangements must be removed or formally accepted into the permanent design.

Handover

The asset owner should receive:

• As-built architecture.
• Zone and conduit register.
• Asset register.
• Software and firmware baseline.
• Firewall rule set.
• Account and role matrix.
• Hardening records.
• Backup and restore procedures.
• Patch and vulnerability procedures.
• Remote-access procedure.
• Monitoring requirements.
• Recovery procedures.
• Known vulnerabilities.
• Accepted deviations.
• Residual risks.
• Supplier support details.
• End-of-life information.

Common industrial cyber-security design mistakes

Treating cyber security as an IT workstream

Network architecture, safety independence, controller selection and remote access are engineering decisions.

Writing “IEC 62443 compliant”

The requirement must identify the applicable part, edition, role, scope, target and evidence.

Using an obsolete IEC 62443 roadmap

Older diagrams include planned parts that were never published in that form and omit newer publications.

Building a flat network

A flat architecture allows faults and compromise to move between systems without meaningful control.

Treating VLANs as complete security boundaries

Segmentation requires enforcement.

Allowing direct enterprise-to-controller access

Connections should pass through controlled boundaries and intermediary services.

Installing a firewall without defining conduits

A firewall cannot enforce a communication policy that has not been specified.

Permanent vendor remote access

Remote access should be approved, limited, monitored and removable.

Shared administrator accounts

Shared accounts weaken accountability and access control.

Relying only on product certification

Certification of a component or supplier process does not prove that the integrated system is secure.

Patching solely from vulnerability scores

Patch decisions must consider process risk, exposure, compatibility and recovery.

Active scanning without operational assessment

Industrial equipment may respond poorly to aggressive scanning.

Failing to assess safety-system dependencies

Shared services can introduce common-cause vulnerabilities.

Ignoring temporary connections

Commissioning laptops, unmanaged switches, vendor routers and temporary rules frequently become permanent risks.

Incomplete handover

An asset owner cannot maintain security without accurate architecture, configuration, asset and recovery records.

Design engineer’s checklist

Before issuing an industrial control-system design, confirm that:

• The essential function is defined.
• The legal and regulatory scope is recorded.
• The competent authority is identified where relevant.
• The applicable CAF profile or sector overlay is known.
• IEC 62443 roles and responsibilities are allocated.
• The SuC is defined.
• Process and safety consequences are understood.
• Assets and dependencies are documented.
• External and third-party connections are identified.
• The system is divided into justified zones.
• Each conduit has a documented purpose.
• Target security requirements follow from risk.
• Enterprise and OT systems are separated.
• Safety-system independence is assessed.
• Firewall rules follow a default-deny approach.
• Remote access uses controlled intermediary systems.
• Named accounts and strong authentication are used.
• Administrative access is restricted and logged.
• Product security and support requirements are specified.
• Legacy limitations are recorded.
• Compensating controls are documented.
• Asset and configuration management are included.
• Patch and vulnerability processes are defined.
• Logging and monitoring are designed.
• Backups and restoration are tested.
• Isolation and recovery plans exist.
• Supply-chain requirements are included.
• Cyber-security controls are included in FAT and SAT.
• Temporary commissioning arrangements are removed.
• Final documents match the installed system.
• Residual risk is accepted by the correct authority.

Final perspective

Industrial cyber security is not achieved by installing a firewall or purchasing certified components.

It requires a controlled engineering process:

1. Understand the essential function and physical process.
2. Establish the UK legal and regulatory context.
3. Define the system and its dependencies.
4. Assess credible cyber paths to physical and operational consequences.
5. Divide the system into zones and conduits.
6. Establish risk-based security requirements.
7. Design controlled communication and access paths.
8. Select products with suitable capability and lifecycle support.
9. Configure and harden the integrated system.
10. Verify the implemented controls.
11. Maintain, monitor and recover the system throughout its operational life.

The strongest industrial cyber-security designs are not those containing the largest number of products or restrictions.

They are the designs in which every asset, connection, privilege and dependency has a defined purpose, a responsible owner, a justified level of protection and a credible recovery plan.

References

Disclaimer: This article provides a general engineering overview. It does not replace legislation, regulatory guidance, the applicable standards, project-specific risk assessment, sector requirements or competent professional judgement.