A risk-led penetration test can help mechanical engineering organisations assess defined cyber security scenarios without treating a single test as proof of security or compliance.
Why industrial testing needs a different approach
Connected machinery, Industrial Internet of Things (IIoT) services and operational technology (OT) can create dependencies between product, engineering and operational environments. Testing those environments requires care because reliability, process performance and physical safety considerations may differ from those in conventional IT.
A penetration test is one technique, not a catch-all term for every security assessment. Vulnerability scanning, configuration review and passive observation have different purposes and levels of interaction. A sensible assessment may combine them, depending on the objective and the environment.
The purpose of a penetration test should be explicit from the outset. It might be to validate selected controls, investigate an exploitable path or assess a defined scenario. The result is evidence about the agreed scope, techniques and period; it is not proof that a machine, product or organisation is secure or compliant.
Separate product testing from operational testing
It is important to distinguish security testing of a product from testing an installed machine, production cell or plant network. These activities can involve different owners, assets, evidence requirements and safety decisions.
For product developers and maintainers, IEC 62443-4-1 addresses secure product development, verification and validation, including product penetration testing. Testing a live operational environment is a separate exercise that needs planning with the relevant engineering and operational stakeholders.
A mechanical-engineering scope can be organised around the system under consideration, its zones and conduits, access points and dependencies, including relevant IIoT connections. IEC 62443-3-2 supports this risk-led system view. Zones and conduits can help make boundaries visible, but they do not by themselves establish conformity.
Define the objective and authorised scope
A well-run engagement starts with a shared understanding of what is being assessed and why. The test plan or rules of engagement should document:
- authorised systems, networks and interfaces
- exclusions and permitted or prohibited activities
- test origin, timing and named contacts
- data-handling arrangements
- incident and escalation procedures
- the process for agreeing any scope change.
Third-party or shared infrastructure may require the relevant owner's written consent. Scope changes should be agreed again before work proceeds.
NIST SP 800-115 provides general guidance on planning, authorisation, assessment activity, analysis and reporting. In industrial settings, that planning should also involve people with OT engineering, operational and, where relevant, safety knowledge.
Choose an appropriate test environment
For intrusive testing, a representative test environment, replica, virtualised system or simulation should be considered before work in production OT. This can allow teams to investigate relevant weaknesses while limiting interaction with operational equipment.
A representative environment has limits. It may not reproduce the timing, firmware, integrations or physical-process behaviour of a live installation. Any move into production should therefore be a separate risk decision. Production work may need to be aligned with a planned outage or undertaken while systems are offline, depending on the equipment, process state, technique and safeguards.
NIST SP 800-82 Rev. 3 explains why OT security testing needs to account for performance, reliability and safety constraints that can be specific to the environment.
Set OT-specific rules of engagement
Active scanning generates traffic and interacts directly with devices. In operational OT, it may cause instability or interfere with process state. The risk depends on the tool, probe, rate, protocol, device, process conditions and safeguards, so activity should be assessed and scheduled carefully.
Passive discovery can reduce direct interaction, but it has coverage limits. The agreed approach should set clear technical and operational boundaries, including reviewed network ranges, routes, jump hosts, tool settings and monitoring arrangements. These boundaries should prevent discovery, scanning or exploitation from extending into adjacent OT beyond the authorised scope. Segmentation is valuable, but it is not infallible.
The plan should also define stop conditions and escalation routes. Examples include unexpected device behaviour, safety alarms, process deviation, evidence of a real compromise or activity outside scope. Responsible operational and safety personnel should determine the authority and thresholds for stopping, isolating, restoring and restarting systems.
Select people with relevant expertise
The quality of an industrial penetration test depends on more than familiarity with tools. A suitable team needs the ability to work with product and OT stakeholders, understand the assessed architecture and interpret findings in their operational context.
Useful experience can include:
- industrial control systems, interfaces and communications architectures
- secure product development and validation practices
- OT operational constraints and change control
- risk assessment across system boundaries, zones and conduits
- the relationship between cyber security, availability and safety considerations.
The ISA overview of the ISA/IEC 62443 series is useful for understanding the different roles of asset owners, service providers and product developers. Those distinctions matter when deciding who can authorise work, provide evidence and accept operational risk.
Turn findings into practical action
A useful report does more than list vulnerabilities. It should distinguish between an observation, validated exploitability and inferred impact. A scanner severity score is not automatically a measure of plant risk.
Findings should be analysed and prioritised in their operational context, with assumptions, exclusions, untested paths, environmental differences and tool limitations made clear. The resulting actions may include remediation, configuration changes, compensating controls or improvements to development and test processes.
Retesting should follow normal change control and renewed safety checks. Independent validation can improve confidence in implemented controls, while recognising that penetration testing is only one possible exercise. The CISA Cybersecurity Performance Goals are voluntary and non-comprehensive; they do not prescribe a universal testing frequency, depth or production-OT method.
Use testing as part of a wider security programme
Penetration testing can provide focused evidence about realistic scenarios and help teams identify where controls, development practices or operational arrangements need attention. It does not replace functional-safety validation, machinery risk assessment, secure development, vulnerability management, monitoring, backup or incident response.
When objectives are clear, boundaries are controlled and findings are translated into agreed action, penetration testing can become a useful part of a wider, risk-led approach to cyber security in mechanical engineering.