prEN 50742:2025
(Main)Safety of machinery - Protection against corruption
Safety of machinery - Protection against corruption
This document provides requirements and recommendations to prevent accidental and intentional corruption of machines, including malicious third-party actions resulting in hazardous situations. This document applies to - hardware components, including interfaces to remote devices and control systems, that can transmit signals or data - software and data if they could influence the safety of the machine. This document will address the requirements of ((EU) 2023/1230 – Annex III, 1.1.9.), and associated requirements of (Annex III, 1.2.1. a) and f)). Note 1 Topics can overlap with the domain of cybersecurity but are not necessarily identical in their coverage. Note 2 This standard does not cover the safety of control systems in machinery.
Varnost strojev - Zaščita pred korupcijo
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-januar-2026
Varnost strojev - Zaščita pred korupcijo
Safety of machinery - Protection against corruption
Ta slovenski standard je istoveten z: prEN 50742:2025
ICS:
03.100.02 Upravljanje in etika Governance and ethics
13.110 Varnost strojev Safety of machinery
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
EUROPEAN STANDARD DRAFT
prEN 50742
NORME EUROPÉENNE
EUROPÄISCHE NORM
December 2025
ICS 13.110 -
English Version
Safety of machinery - Protection against corruption
To be completed To be completed
This draft European Standard is submitted to CENELEC members for enquiry.
Deadline for CENELEC: 2026-02-27.
It has been drawn up by CLC/TC 44X.
If this draft becomes a European Standard, CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which
stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
This draft European Standard was established by CENELEC in three official versions (English, French, German).
A version in any other language made by translation under the responsibility of a CENELEC member into its own language and notified to
the CEN-CENELEC Management Centre has the same status as the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the
Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Türkiye and the United Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to
provide supporting documentation.
Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without notice and
shall not be referred to as a European Standard.
European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2025 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Project: 77624 Ref. No. prEN 50742:2025 E
1 Contents Page
2 European foreword . 3
3 Introduction . 4
4 1 Scope . 5
5 2 Normative references . 5
6 3 Terms and definitions . 6
7 4 Protection against corruption . 8
8 4.1 General . 8
9 4.2 Connection of machinery . 8
10 4.3 General process requirements . 8
11 5 Process requirements .10
12 5.1 Introduction .10
13 6 Approach B process requirements .10
14 7 Product requirements .11
15 7.1 Interfaces .11
16 7.2 Security measures .11
17 7.2.1 General .11
18 7.2.2 Cryptography .11
19 7.3 Information collection .12
20 7.3.1 Types of interventions .12
21 7.3.2 Intervention evidence to be collected .12
22 7.3.3 Logging requirements .12
23 7.3.4 Storage duration requirements .13
24 7.3.5 Storage protection requirements .13
25 7.4 Protection measures against corruption .13
26 7.4.1 General .13
27 7.4.2 Safety-related Security levels .13
28 7.4.3 Security protection requirements .14
29 7.5 Identification of software versions and configuration .16
30 8 Approach B product requirements .17
31 8.1 General .17
32 8.2 Machinery systems .17
33 8.3 Machinery components .17
34 8.4 Identification .18
35 8.5 Persistency .18
36 9 Information for use .18
37 Annex A (informative) Examples of logging formats .19
38 Annex B (informative) Threat assessment .20
39 Annex C (informative) Threat modelling for safety systems .25
40 Annex D (informative) List of threats and mitigations .62
41 Annex ZZ (informative) Relationship between this European Standard and the essential
42 requirements of Regulation (EU) 2023/1230 aimed to be covered .66
43 Bibliography .67
44 European foreword
45 This document (prEN 50742:2025) has been prepared by CLC/TC 44X “Safety of machinery: electrotechnical
46 aspects”.
47 This document is currently submitted to the Enquiry.
48 The following dates are proposed:
• latest date by which the existence of this (doa) dav + 6 months
document has to be announced at national level
• latest date by which this document has to be (dop) dav + 12 months
implemented at national level by publication of
an identical national standard or by
endorsement
• latest date by which the national standards (dow) dav + 36 months
conflicting with this document have to be (to be confirmed or
withdrawn modified when voting)
49 This document has been prepared under a standardization request addressed to CENELEC by the European
50 Commission. The Standing Committee of the EFTA States subsequently approves these requests for its
51 Member States.
52 For the relationship with EU Legislation, see informative Annex ZZ, which is an integral part of this document.
53 Introduction
54 Machinery must be safe in order to prevent injuries and loss of life.
55 The communication with the machine must not lead to hazardous situations.
56 The manufacturer performs a risk assessment according to EN ISO 12100 to identify all potential hazards.
57 Vulnerabilities can lead to a corruption of the control system of the machine and hazards can lead to dangerous
58 situations.
59 By exploitation of vulnerabilities via communication with the machine, the machine could be operated outside
60 safe parameters or degrade safety functions.
61 Vulnerabilities cannot create new hazards.
62 The probability that someone will use a vulnerability for a malicious attempt cannot be predicted.
63 The risk can only be assessed in terms of its impact on functional safety.
64 Vulnerabilities are divided into several types.
65 This document provides two approaches:
66 — Approach A (Clause 5 and 7) has been developed to facilitate compliance for machinery developed without
67 references to EN IEC 62443 series of standards.
68 — Approach B (Clauses 6 and 8) has been provided to facilitate compliance for machinery developed in the
69 context of the EN IEC 62443-3-3:2019, EN IEC 62443-4-1:2018, EN IEC 62443-4-2:2019.
70 NOTE 1 The EN IEC 62443 series provides information and a methodology to approach cybersecurity.
71 This document is intended for use by machinery designers, control system manufacturers and integrators, and
72 others involved in the specification, design and validation of an SCS.
73 NOTE 2 See EN IEC 62443-4-1:2018; the manufacturer can be a product supplier or system integrator.
74 This document does not address the role of the user.
75 1 Scope
76 This document provides requirements and recommendations for protection against corruption for machinery,
77 related products and partly completed machinery referred to in this document as ‘machinery’.
78 This document provides requirements and recommendations to prevent accidental and intentional (including
79 malicious) corruption of machines resulting in hazardous situations.
80 This document applies to:
81 — hardware components, including interfaces to remote devices and control systems, that can transmit
82 signals or data;
83 — software and data;
84 if they could influence the safety of the machinery.
85 NOTE 1 Topics can overlap with the domain of cybersecurity but are not necessarily identical in their coverage.
86 NOTE 2 This document does not describe functional safety requirements of control systems in machinery.
87 This document specifies requirements to related risks in all lifecycle steps.
88 Machinery interfaces to external systems and services are in the scope of this document. External systems and
89 services are out of the scope of this document.
90 This document does not apply to machinery installed before the date of its publication.
91 This document specifies requirements related to protection against corruption related risks in all lifecycle steps
92 such as:
93 — development;
94 — manufacturing;
95 — commissioning;
96 — operation;
97 — maintenance;
98 — decommissioning.
99 2 Normative references
100 The following documents are referred to in the text in such a way that some or all of their content constitutes
101 requirements of this document. For dated references, only the edition cited applies. For undated references, the
102 latest edition of the referenced document (including any amendments) applies.
103 EN ISO 12100:2010, Safety of machinery - General principles for design - Risk assessment and risk reduction
104 (ISO 12100:2010)
105 EN IEC 62443-3-3:2019, Industrial communication networks - Network and system security - Part 3-3: System
106 security requirements and security levels
107 EN IEC 62443-4-1:2018, Security for industrial automation and control systems - Part 4-1: Secure product
108 development lifecycle requirements
As impacted by EN IEC 62443-3-3:2019/AC:2019.
109 EN IEC 62443-4-2:2019, Security for industrial automation and control systems - Part 4-2: Technical security
110 requirements for IACS components
111 3 Terms and definitions
112 For the purposes of this document, the following terms and definitions apply.
113 ISO and IEC maintain terminology databases for use in standardization at the following addresses:
114 — ISO Online browsing platform: available at https://www.iso.org/obp/
115 — IEC Electropedia: available at https://www.electropedia.org/
116 3.1
117 control system
118 system which responds to input signals from parts of the machinery, from operators, from external control
119 equipment or any combination of these and generates corresponding output signals to the machinery actuators,
120 causing the machine to perform in the intended manner
121 3.2
122 intervention
123 legitimate or illegitimate action or event that changes the software or data which modifies or interrupts the
124 behaviour, state or operation of the machinery temporarily or permanently
125 Note 1 to entry: Action taken on safety routines, safety variables, calibration data, firmware updates of safety-related parts
126 of software are considered interventions in the sense of this document.
127 Note 2 to entry: Normal operational changes to variables, such as opening a safety gate, does not constitute an intervention
128 in the sense of a change to data.
129 EXAMPLE
130 1) The modification of the installed software on the machinery due to an update or configuration change(s).
131 2) modular PLC, if a PLC module is replaced by an identical spare part it is not considered an intervention; if an additional
132 part is introduced; it is considered a modification.
133 3.3
134 modification
135 change caused by an intervention
136 Note 1 to entry: Including software version, sensor calibration, configuration data etc.
137 EXAMPLE Update of safety-related software.
138 3.4
139 evidence
140 anything that allows the detection that an event or action has happened
141 EXAMPLE log records, broken safety seals (anti-tampering seals) and scratch marks, damage to interface covers e.g.
142 RJ45 cover
143 3.5
144 corruption
145 accidental or illegitimate modification of machinery data potentially resulting in hazardous situations
As impacted by EN IEC 62443-4-2:2019/AC:2022-09.
146 3.6
147 security context
148 security provided to the machinery by the environment in which the machinery is intended to be used
149 Note 1 to entry: The security provided to the machinery by its intended environment can effectively restrict the threats that
150 are applicable to the machinery.
151 Note 2 to entry: See Clause C.5.
152 [SOURCE: EN IEC 62443-4-1:2018, 3.1.23, modified — removed the word product and substituted with the
153 word machinery]
154 3.7
155 countermeasure
156 action, device, procedure or technique that reduces a threat, a vulnerability or the consequences of an attack
157 by minimizing the harm the attack can cause or by discovering and reporting it so that corrective action can be
158 taken
159 [SOURCE: EN IEC 62443-4-2 :2019, 3.1.15]
160 3.8
161 compensating countermeasure
162 countermeasure employed in lieu of or in addition to inherent security capabilities to comply with one or more
163 security requirements
164 [SOURCE: EN IEC 62443-4-2 :2019, 3.1.9]
165 3.9
166 reasonably practicable
167 balancing of risk reduction against time, money and effort
168 3.10
169 tracing log
170 collection of data recording interventions that affect the safety related control system
171 3.11
172 vulnerability
173 flaw or weakness in a system's design, implementation, or operation and management that could be exploited
174 to corrupt the system's integrity
175 3.12
176 critical data
177 data whose manipulation can result in increase of hazard
178 3.13
179 safety-related application software
180 SRASW
181 software specific to the application and generally containing logic sequences, limits and expression that control
182 the appropriate inputs, outputs, calculations and decisions necessary to meet the safety-related part of a control
183 system (SRP/CS) requirements
184 [SOURCE: EN ISO 13849-1:2023, 3.1.41]
185 3.14
186 safety-related embedded software
187 SRESW
188 software that is part of the system supplied by the manufacturer and is not intended for modification by the end-
189 user
190 [SOURCE: EN ISO 13849-1:2023, 3.1.42, modified – Note 1 to entry deleted]
191 3.15
192 SRSL
193 Safety-Related Security Requirement
194 parameter representing the sum of security requirements that are related to a specific safety-related function
195 used in order to protect it against corruption of data
196 4 Protection against corruption
197 4.1 General
198 Either approach A (Clauses 5 and 7) or approach B (Clauses 6 and 8) shall be applied.
199 4.2 Connection of machinery
200 The design and the construction of machinery shall not allow hazardous situations via connections.
201 A connection (physical, logical and indirect) is any link that can exchange information, for example:
202 — a network link,
203 — a WIFI connection,
204 — a single wire,
205 — wires of the power supply,
206 — an optical link,
207 — a card reader interface,
208 — a connection from a machine to external systems:
209 — building networks
210 — cloud services
211 — service tools
212 NOTE 1 The connectivity can exist through equipment permanently available on site, or equipment temporarily brought
213 to the location during the installation, operation and maintenance, or decommissioning steps.
214 NOTE 2 Example of a machinery not to be considered is a simple drilling machine without any possibility of connection.
215 4.3 General process requirements
216 Following a risk assessment according to EN ISO 12100:2010, where all potential hazards have previously
217 been identified, the designer shall perform a threat assessment.
218 The content of the threat assessment can be limited to additional threats that are not covered by the minimum
219 security measures.
220 The designer shall define the security context for the machine.
221 The following principles shall be applied in order to protect a machine from threats that can lead to hazardous
222 situation(s):
223 a) Where vulnerabilities are present, eliminate those that can lead to hazardous situation(s).
224 EXAMPLE 1 To eliminate any unnecessary interfaces so that the threats cannot exploit this vulnerability.
225 EXAMPLE 2 JTAG interface(s) used during development and then disabled.
226 EXAMPLE 3 Elimination can be a result of redesign using different components (maybe from same vendor).
227 b) if it is not possible to eliminate vulnerabilities, the designer shall mitigate them.
228 EXAMPLE Mitigation, implementation of user authentication on an interface.
229 c) For any vulnerabilities that remain after steps a) and b), information for use shall provide all necessary
230 information for compensating countermeasure by the user. See Annex C.
231 EXAMPLE Manufacturer states in the instruction for use that the fieldbus connection of the machine is only designed
232 for internal(local) connections to another machine in a trusted network and is not allowed to be connected to an untrusted
233 network.
234 Vulnerabilities cannot create new hazards, but their exploitation can compromise the protective measures;
235 therefore, a threat assessment shall be performed.
236 NOTE By exploitation of vulnerabilities via communication with the machine, the machine could be operated outside
237 safe parameters or degrade safety functions. The risk can only be assessed in terms of its impact on functional safety.
238 Countermeasures shall not negatively affect the functional safety of the machinery.
239 EXAMPLE When a cryptographic function is implemented, it needs to be verified that it does not lead to hazardous
240 situations due to increased safety function response time.
241 The probability that someone will try to exploit a specific vulnerability for a malicious attempt cannot be predicted.
242 Therefore, the likelihood of being a target/victim shall not be relevant for the threat assessment.
243 In order to fulfil the essential requirements and recommendations to prevent accidental and intentional (including
244 malicious) corruption of machines resulting in hazardous situations, designers shall follow approach A in below
245 table.
246 However, if designers prefer to follow EN IEC 62443-3-3:2019, EN IEC 62443-4-1:2018,
247 EN IEC 62443-4-2:2019 for the security requirements for their machinery, they shall follow approach B.
248 Table 1 provides an overview of both approaches:
249 Table 1 — Process requirements overview
Common clauses to be followed:
— Risk assessment according to EN ISO 12100:2010
— Clause 4 - Protection against corruption
— Clause 9 - Information for use
Specific clauses to be followed:
Approach A Approach B
— Clause 5 for process requirements — Clause 6 for process requirements
— Clause 7 for product requirements — Clause 8 for product requirements
250 NOTE Both routes are equally allowed to be followed. The selected route depends to the effort the manufacturer needs
251 to do, as well as the value for the manufacturer, but also their knowledge, field of application, ect.
252 5 Process requirements
253 5.1 Introduction
255 Figure 1 — Risk assessment process including safety and security aspects
256 6 Approach B process requirements
257 The requirements of EN IEC 62443-4-1:2018 shall apply.
258 7 Product requirements
259 7.1 Interfaces
260 All machinery interfaces that are accessible and can affect the safety of the machinery shall be identified and
261 protected using countermeasures or compensating countermeasures.
262 Figure 2 shows an example of machinery interfaces which can be subject to an attack.
264 Figure 2 — Machinery interfaces example
265 Guidelines on second order attack are in Annex C.
266 7.2 Security measures
267 7.2.1 General
268 Security measures to protect against corruption of the machinery leading to hazardous situations shall be
269 selected on a risk-based approach in order to be adequate.
270 This risk-based approach shall consider both safety risks and threat risks of the machinery's intended use and
271 security context.
272 Security measures shall not negatively affect the functional safety.
273 7.2.2 Cryptography
274 Where cryptographic methods are used, only state of the art algorithm should be selected.
275 NOTE 1 Information related to state-of-the-art algorithms is available from organizations such as ENISA
276 www.enisa.europa.eu. A list of examples is available in the bibliography [2][3][4].
277 NOTE 2 When a cryptographic function is implemented, it can be verified that it does not lead to hazardous situations
278 due to increased safety function response time.
279 7.3 Information collection
280 7.3.1 Types of interventions
281 The following list provides types of interventions that shall be considered:
282 a. safety parametrization/configuration parameters (via identification means like CRC…),
283 EXAMPLE connecting or disconnecting flash drive or SD card, when being used for storing configuration data and
284 logging data that is relevant for compliance of machinery
285 b. SRESW update/modification (via identification means only, such as version number, CRC, ect…),
286 c. SRASW updates/modification (via identification means only, such as version number, CRC, ect…),
287 d. parametrization of human-machine interfaces if it can creates hazards,
288 e. software relevant for displaying safety instructions.
289 NOTE 1 Any intervention that does not result in changes of the data listed above does not need to be logged (e.g.
290 successful/unsuccessful authorized interventions).
291 NOTE 2 Actions on the machine triggering a safe state of the machine e.g. triggering safety light curtain, are not in scope.
292 NOTE 3 The version of the SRASW binaries or SRESW binaries does not need to be kept in the tracing log.
293 7.3.2 Intervention evidence to be collected
294 Digital evidence of a legitimate or illegitimate action or event that changes or interrupts the behaviour, state or
295 operation of the machinery temporarily or permanently, that changes the software or data shall be recorded and
296 shall contain the following data as a minimum:
297 a. an indication of the type of intervention that affects software relied on for risk reduction according to the risk
298 assessment,
299 b. means to allow correlation of logged events, (e.g. timestamping referring to absolute or relative system
300 time), boot counts, system times, running counters,
301 c. deletion of the log file.
302 NOTE Timestamping can be provided by the device making the log event or the remote log collector.
303 7.3.3 Logging requirements
304 The machine shall provide digital or physical means for traceability related to interventions.
305 Digital evidence of interventions shall be readable and accessible.
306 The documentation shall provide information on how to access and interpret the recorded evidence.
307 If a binary format is used, the format should be documented as part of the information for use, so that anyone
308 can program a converter to make the logs intelligible.
309 Where collection of digital evidence is not reasonably practicable, physical evidence (e.g. tampering of a seal)
310 shall be used.
311 Evidence collection of interventions is required and shall be done automatically by the machinery or related
312 product.
313 NOTE See Annex A for examples of recognized industry practice on logging standards.
314 The log records may be stored in the control system, the components inside the machine or in a component for
315 storing the data external to the machinery (e.g. Network Attached Storage (NAS), local hard drive, etc…).
316 7.3.4 Storage duration requirements
317 Log storage shall contain, as a minimum, the evidence of the last intervention of each type.
318 Tracing log data records of each intervention shall be stored for at least five years.
319 The tracing log shall be enabled, as a minimum, from the time the machine is put into service.
320 7.3.5 Storage protection requirements
321 Logs shall be properly secured to protect against tampering.
322 Log deletion, if applicable, shall only be possible by an authorized procedure.
323 7.4 Protection measures against corruption
324 7.4.1 General
325 Corruption can compromise the integrity and effectiveness of the risk-reduction measures, leading to potentially
326 hazardous consequences.
327 To safeguard against such risks, it is essential to first determine the required level of protection.
328 This involves identifying the vulnerabilities and specific needs of the application in question and defining Safety-
329 related Security levels (SRSL) for the individual risk-reduction measures.
330 Once the appropriate level of protection is identified, adequate measures can be applied to mitigate the threats
331 effectively.
332 These measures are intended to preserve the integrity and reliability of the safety control system.
333 7.4.2 Safety-related Security levels
334 For each identified safety function, a Safety-related security level (SRSL) shall be determined and documented.
335 The determination of the SRSL shall be based on the result of the threat assessment and shall correlate to the
336 risk-reduction applied by the protective measure and to the likelihood of a successful threat exploitation.
337 Four SRSL levels are defined, where SRSL0 gives no specific additional requirements, and SRSL1 to SRSL3
338 correspond from low to high security levels.
339 NOTE Annex B provides guidance for the determination of the SRSL. The likelihood of a successful threat exploitation
340 can be expressed as an attack potential (AP) being a function of several parameters such as Attacker Capability (AC),
341 Window of Opportunity (WoO) and Exposure Level (EL).
342 The measures associated with an appropriate Safety Related Security Level (SRSL) shall be selected to protect
343 safety functions.
344 Table 2 — SRSL description
SRSL Description
SRSL0 This level shall be used for completely isolated safety system.
(e.g. completely isolated networks within the machine; or where safety functions have no
external interfaces.)
SRSL1 This level (or higher) shall be selected to protect safety functions when the attack potential is
low, where an attack can only occur under very specific circumstances. When the severity of
the harm is reversible, it might also be selected for a moderate attack potential where an
attack has a reasonable likelihood of occurring.
SRSL2 This level (or higher) shall be selected to protect safety functions when the attack potential is
moderate, where an attack has a reasonable likelihood of occurring. When the severity of the
SRSL Description
harm is reversible, it might also be selected for a significant attack potential where an attack
has a high likelihood of occurring.
SRSL3 This level (or higher) shall be selected to protect safety functions when the attack potential is
significant or critical, where an attack has a high likelihood of occurring or an attack is almost
guaranteed to occur.
This can be used for connection to untrusted networks e.g. connection to internet.
345 7.4.3 Security protection requirements
346 7.4.3.1 General
347 The machinery shall meet, as a minimum, the security protection requirements listed below corresponding to
348 the determined SRSL.
349 The security protection requirements shall apply to their respective safety functions and their related interfaces.
350 NOTE Interface can be “logical interfaces” (Modbus/TCP, Webserver….) on “physical interfaces” (RJ45, USB).
351 7.4.3.2 Authentication requirements
352 7.4.3.2.1 Authentication
353 SRSL0:
354 None.
355 SRSL1:
356 Entities shall be authenticated.
357 SRSL2:
358 Entities shall be authenticated.
359 SRSL3:
360 Entities shall be uniquely authenticated.
361 NOTE 1 In this context the word “entities” relates to human users, software processes, device capable of intervention.
362 NOTE 2 Authentication means include but are not limited to: passwords/ PIN/ dongle/ biometrics/ certificates/ RFID/
363 NFC/ logical identifiers (e.g. UID, HID, cookies, etc…) or via cryptographic authentication mechanisms such as random
364 challenge, TLS-handshake, X509 certificate, etc ….
365 7.4.3.3 Authorization requirements
366 7.4.3.3.1 Authorization enforcement
367 SRSL0:
368 None.
369 SRSL1:
370 Interventions shall require authorization.
371 SRSL2:
372 Interventions shall require authorization.
373 SRSL3:
374 Interventions shall require authorization with specific privileges (e.g. role-based access control).
375 7.4.3.4 Integrity requirements
376 7.4.3.4.1 Software and information integrity
377 SRSL0:
378 None.
379 SRSL1:
380 The integrity of software and other critical information such as safety-related configurations, shall be verified at
381 startup (e.g. by use of checksums).
382 SRSL2:
383 The integrity of software and other critical information, such as safety-related configurations, shall be verified at
384 startup and periodically (e.g. by use of checksums).
385 SRSL3:
386 The integrity of software and other critical information shall be cryptographically verified at startup and
387 periodically during operation (e.g. by use of cryptographic hashes, HMACs, CMACs).
388 7.4.3.4.2 Integrity of boot process
389 SRSL0:
390 None.
391 SRSL1:
392 Integrity of the boot process shall be protected and shall be verified at startup (e.g. checksums).
393 SRSL2:
394 Integrity of the boot process shall be protected and shall be verified at startup.
395 SRSL3:
396 A secure boot process shall be implemented (e.g. cryptographic signature verification with trusted roots, rollback
397 or safe state upon verification failure).
398 7.4.3.4.3 Information exchange integrity
399 SRSL0:
400 None.
401 SRSL1:
402 The integrity of exchanged information shall be verified.
403 SRSL2:
404 The integrity of exchanged information shall be verified.
405 SRSL3:
406 The integrity of exchanged information shall be guaranteed by implementing secure cryptographic protocols
407 that detect and reject modified or replayed messages.
408 7.4.3.4.4 Input data validation
409 SRSL0:
410 None
411 SRSL1:
412 Input data shall be validated against defined boundaries.
413 Invalid input data shall be rejected.
414 SRSL2:
415 Input data shall be validated rigorously, including syntax, semantics, format correctness, and data-type
416 verification.
417 Invalid input data shall be rejected.
418 SRSL3:
419 Input data shall be validated rigorously using strict, context-aware validation including syntactical, semantic,
420 boundary, and protocol-specific constraints.
421 Invalid input data shall be rejected.
422 7.4.3.4.5 Physical tampering
423 SRSL0:
424 None.
425 SRSL1:
426 Physical tampering shall be detected e.g. seal breaking.
427 SRSL2:
428 Physical tampering shall be detected e.g. seal breaking.
429 SRSL3:
430 Physical tampering shall be detected e.g. seal breaking.
431 7.4.3.5 Authenticity requirements
432 7.4.3.5.1 Authenticity of SRESW/SRASW
433 SRSL0:
434 None.
435 SRSL1:
436 None.
437 SRSL2:
438 The authenticity of critical data (e.g. SRESW/SRASW, and critical configuration data) shall be verified via e.g.
439 cryptographic signatures or equivalent at installation time.
440 SRSL3:
441 The authenticity of critical data (e.g. SRESW/SRASW, and critical configuration data) shall be verified via
442 cryptographic signatures or equivalent at installation time.
443 7.5 Identification of software versions and configuration
444 Identification of software versions and configuration information relevant for protection against corruption shall
445 be available on demand. Software identification and configuration information shall be available in human
446 readable form, either by a built-in system or by an external tool.
447 NOTE 1 A laptop or a mobile phone with a readily available application can be considered as an example of a commonly
448 available tool.
449 NOTE 2 Distinction needed for machinery identification and related products identification through system (HW).
450 8 Approach B product requirements
451 8.1 General
452 Machinery (as per the definition in the scope of this document) are systems composed of components.
453 EN IEC 62443 series defines requirements for systems and components, as well as for the respective roles of
454 system integrator and product suppliers. The EN IEC 62443 series structure ensures coherence between
455 system and component requirements. This Clause defines the requirements for both machinery systems and
456 machinery components.
457 8.2 Machinery systems
458 Machinery systems shall comply with EN IEC 62443-3-3:2019 with the security requirements listed in Table 3
459 for their safety function(s).
460 Table 3
Foundational Requirement (FR) Security Level Security Requirements
FR 1 – Identification and authentication control (IAC) SL-C2 SR1.1
FR 2 – Use control (UC) SL-C2 SR2.1, SR2.8, SR2.9
FR 3 – System integrity (SI) SL-C2 SR3.1, SR3.4, SR3.5, SR3.6
FR 4 – Data confidentiality None None
FR 5 – Restricted data flow (RDF) SL-C1 SR5.1
FR 6 – Timely response to events (TRE) SL-C1 SR6.1
FR 7 – Resource availability (RA) SL-C2 SR7.1, SR7.2
461 NOTE 1 In Table 3, for each foundational requirement, the listed security requirements are the required subset of the
462 requirements defined by the security level.
463 NOTE 2 The essential functions as per EN IEC 62443-3-3:2019 include the safety functions of the machinery.
464 8.3 Machinery components
465 Machinery components shall comply with EN IEC 62443-4-2:2019 with the security requirements of Table 4 for
466 their safety function(s).
467 Table 4
Foundational Requirement (FR) Security Level Security Requirements
FR 1 – Identification and authentication control (IAC) SL-C2 CR1.1, CR1.2
FR 2 – Use control (UC) SL-C2 CR2.1, CR2.6, CR2.8, CR2.9,
CR2.12, EDR 2.13
FR 3 – System integrity (SI) SL-C2 CR3.1, CR3.4, CR3.5, CR3.6,
EDR3.2, EDR3.11, EDR3.14
FR 4 – Data confidentiality None
FR 5 – Restricted data flow (RDF) SL-C1 CR 5.1
FR 6 – Timely response to events (TRE) SL-C1 CR 6.1
FR 7 – Resource availability (RA) SL-C2 CR 7.1, CR7.2
468 NOTE 1 In Table 4, for each foundational requirement, the listed security requirements are the required subset of the
469 requirements defined by the security level.
470 NOTE 2 The essential functions as per EN IEC 62443-4-2:2019 include the safety functions of the machinery.
471 Machinery components shall comply with EN IEC 62443-4-2:2019, 4.2 support of essential functions (CCSC 1)
472 and 4.4 least privilege (CCSC 3).
473 Compensating countermeasures implemented in the machinery system may be taken into account for achieving
474 the security requirements of machinery components as per EN IEC 62443-4-2:2019, 4.3 (CCSC2). A machinery
475 component may have a lower SL-C than required in Table 4 if this machinery component is part of a machinery
476 system providing the compensating countermeasures ensuring that this system fulfils the SL-C required in
477 Table 3. In this case, the information for use of the component shall specify the need for compensating
478 countermeasures and shall specify the security requirements the machinery component does not fulfil.
479 Machinery components used for both safety function and non-safety functions shall also comply with the security
480 levels or security requirements of Table 4.
481 8.4 Identification
482 Identification of software versions and configuration information relevant for safety functions shall be available
483 on demand. Software identification and configuration information shall be available in human readable form,
484 either by a built-in system or by an external tool.
485 NOTE Typical external tools include laptop, portable device or a mobile phone with a readily available application.
486 8.5 Persistency
487 Audit records as per EN IEC 62443-4-2:2019, 6.10 (CR 2.8 – Auditable events) shall be persistent for at least
488 5 years.
489 NOTE As per definition of the scope, persistency requirement applies to safety functions only.
490 9 Information for use
491 Information for use shall include:
492 — information about the security context for the machine,
493 — identification of software versions and configuration information relevant for safety function,
494 — instruction on how to access the information about the software versions and configuration relevant to
495 safety functions and changes to them,
496 — information about permission and/or prohibition of modifications.
497 Annex A
498 (informative)
500 Examples of logging formats
501 This is an informative annex to provide the reader of the standard further information relating to logging formats.
502 It is however not necessary to follow these examples in order to meet the essential requirements outlined in this
503 document
504 CLF - Common Log Format: The Common Log Format is a file format that is used for logging web server
505 requests.
506 NOTE 1 See also RFC 6872; examples can be found here: https://www.rfc-editor.org/rfc/rfc6872
507 Syslog: Syslog is a protocol for recording and transmitting log messages common on a wide range of systems.
508 Many types of network devices, IoT systems, desktops, and servers support the protocol and its standard
509 plaintext format makes messages easy for machines and humans to read.
510 NOTE 2 See also RFC 5424.
511 W3C extended Log File Format: the extended log file format is designed to meet the following needs:
512 — permit control over the data recorded,
513 — support needs of proxies, clients and servers in a common format,
514 — provide robust handling of character escaping issues,
515 — allow exchange of demographic data,
516 — allow summary data to be expressed.
517 The log file format described permits customized logfiles to be recorded in a format readable by generic
518 analysis tools.
519 NOTE 3 Examples can be found here: https://www.w3.org/TR/WD-logfile
520 CEF - Common Event Format: The Common Event Format (CEF) is an industry standard format used in
521 conjunction with syslog messages by many security vendors to enable interoperability of events between
522 different platforms
523 The Common Event Format (CEF) is a standardized logging format developed by ArcSight (now part of Micro
524 Focus), a security information and event management (SIEM) solution provider. CEF is designed to simplify the
525 process of logging security-related events and making it easier to integrate logs from different sources into a
526 single system. CEF is based on the syslog format, which is a standard for message logging that is supported
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.