prEN 50765:2026

SLOVENSKI STANDARD
01-marec-2026
Zahteve za kibernetsko varnost za mikroprocesorje in mikrokrmilnike z
varnostnimi funkcijami
Cybersecurity requirements for microprocessors and microcontrollers with security-
related functionalities
Cybersicherheitsanforderungen für Mikroprozessoren und Mikrocontroller mit
sicherheitsrelevanten Funktionen
Exigences de cybersécurité pour les microprocesseurs et microcontrolleurs avec
fonctions liées à la sécurité
Ta slovenski standard je istoveten z: prEN 50765:2026
ICS:
35.030 Informacijska varnost IT Security
35.160 Mikroprocesorski sistemi Microprocessor systems
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD DRAFT
prEN 50765
NORME EUROPÉENNE
EUROPÄISCHE NORM
January 2026
ICS 35.030; 35.160 -
English Version
Cybersecurity requirements for microprocessors and
microcontrollers with security-related functionalities
Exigences de cybersécurité pour les microprocesseurs et Cybersicherheitsanforderungen für Mikroprozessoren und
microcontrolleurs avec fonctions liées à la sécurité Mikrocontroller mit sicherheitsrelevanten Funktionen
This draft European Standard is submitted to CENELEC members for enquiry.
Deadline for CENELEC: 2026-04-10.

It has been drawn up by CLC/TC 47X.

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
© 2026 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Project: 80923 Ref. No. prEN 50765:2026 E

Contents Page
1 European foreword . 5
2 1 Scope . 6
3 2 Normative references . 6
4 3 Terms and definitions . 6
5 4 Symbols and abbreviated terms . 8
6 5 Application of this document . 9
7 5.1 General . 9
8 5.2 Technical requirement structure and common application instructions . 9
9 5.2.1 Requirement . 9
10 5.2.2 Implementation options . 9
11 5.2.3 Applicability. 9
12 5.2.4 Assessment . 9
13 5.2.5 Assessment verdict .10
14 5.2.6 Assessment evidence .11
15 6 Product context .11
16 6.1 Product’s intended and reasonably foreseeable use .11
17 6.2 Product’s functions .12
18 6.3 Product’s operational environment of use .12
19 6.4 Product’s system overview .12
20 6.5 Product’s user .13
21 6.6 Product’s reasonably foreseeable misuse.13
22 7 Vulnerability handling activities and outcomes — TR_VUL Vulnerability handling process
23 .13
24 7.1 Requirement .13
25 7.2 Applicability.13
26 7.3 Assessment .14
27 8 Product technical requirements .14
28 8.1 General .14
29 8.2 Technical requirements related to platform implementation .14
30 8.2.1 TR_IMP Implementation best practices .14
31 8.2.2 TR_EXP No known exploitable vulnerabilities .16
32 8.2.3 TR_CFG Secure configuration of platform .17
33 8.3 Technical requirements related to platform functionalities .18
34 8.3.1 TR_PID Identification of platform .18
35 8.3.2 TR_PAU Authentication of platform .21
36 8.3.3 TR_INI Secure initialisation support .24
37 8.3.4 TR_SUP Secure update of platform .27
38 8.3.5 TR_SUD Secure update of dependent components .31
39 8.3.6 TR_ERA Secure erasure of data .33
40 8.3.7 TR_ISO Isolation mechanisms .35
41 8.3.8 TR_ACC Access control to security functionalities .38
42 8.3.9 TR_STO Secure storage .41
43 8.3.10 TR_COM Secure communications .45
44 8.3.11 TR_CRY Secure cryptographic features .49
45 8.3.12 TR_REP Reporting of security events .51
46 8.3.13 TR_AVS Advanced availability support of basic and essential functions .54
47 8.3.14 TR_RST Reset of platform to initial state .56
48 8.3.15 TR_RES Tamper-resistance of platform .58
49 8.4 Technical requirements related to platform operation .61
50 8.4.1 TR_SEG Application of platform security guidance . 61
51 Annex A (informative)  Security analysis . 64
52 A.1 General . 64
53 A.2 Assets . 65
54 A.3 Security incidents . 66
55 A.3.1 General . 66
56 A.3.2 PI_DUD Disclosure of user data . 66
57 A.3.3 PI_MUD Manipulation of user data . 66
58 A.3.4 PI_MBD Modification of the behaviour of the device . 66
59 A.3.5 PI_MCD Malicious control of the device . 66
60 A.3.6 PI_UEB Unavailability of essential and basic functions of the device . 66
61 A.3.7 PI_MDO Malicious use of the device against other devices or networks . 66
62 A.3.8 Completeness of incidents identification . 66
63 A.4 Security problem definition . 67
64 A.4.1 General . 67
65 A.4.2 Threats . 67
66 A.4.3 Organizational security policies . 68
67 A.4.4 Security assumptions . 68
68 A.4.5 Risks analysis coverage . 69
69 A.5 Security objectives . 69
70 A.5.1 General . 69
71 A.5.2 Security objectives for the platform . 69
72 A.5.3 Security objectives for the environment . 70
73 A.5.4 Security problem definition coverage . 70
74 A.5.5 Security objectives coverage . 71
75 A.6 Risk environments . 73
76 A.6.1 General . 73
77 Annex B (informative) Platform categories and applicability overview . 74
78 Annex C (informative) Support of European security evaluation methodologies . 77
79 C.1 General . 77
80 C.2 Compliance demonstration support . 77
81 C.2.1 Assessment of applicability . 77
82 C.2.2 TR_IMP Implementation best practices . 77
83 C.2.3 TR_EXP No known exploitable vulnerabilities . 77
84 C.2.4 TR_CFG Secure configuration of platform . 77
85 C.2.5 TR_PID Identification of platform . 77
86 C.2.6 TR_PAU Authenticity of platform . 78
87 C.2.7 TR_INI Secure initialisation support . 79
88 C.2.8 TR_SUP Secure update of platform . 80
89 C.2.9 TR_SUD Secure update of dependent component .81
90 C.2.10 TR_ERA Secure erasure of data .82
91 C.2.11 TR_ISO Isolation mechanisms .83
92 C.2.12 TR_ACC Access control to security functionalities .84
93 C.2.13 TR_STO Secure storage .85
94 C.2.14 TR_COM Secure communication .86
95 C.2.15 TR_CRY Secure cryptographic features .86
96 C.2.16 TR_REP Reporting of security events .87
97 C.2.17 TR_AVS Advanced availability support of basic and essential functions .88
98 C.2.18 TR_RST Reset of platform to initial state .89
99 C.2.19 TR_RES Tamper resistance of platform .90
100 C.2.20 TR_SEG Application of platform security guidance .90
101 Annex ZZ (normative) Relationship between this European Standard and the essential
102 requirements of Regulation (EU) 2024/2847 aimed to be covered .92
103 Bibliography .95
104 European foreword
105 This document (prEN 50765:2026) has been prepared by CLC/TC 47X “Semiconductors and trusted chips
106 implementation”
107 This document is currently submitted to the Enquiry.
108 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)
109 This document has been prepared under a standardization request addressed to CENELEC by the European
110 Commission. The Standing Committee of the EFTA States subsequently approves these requests for its
111 Member States.
112 For the relationship with EU Legislation, see informative Annex ZZ, which is an integral part of this document.
113 1 Scope
114 This document specifies the security assessment requirements for platforms that include microprocessors and
115 microcontrollers with security-related functionalities. These platforms aim to secure other
116 products/networks/services beyond the microprocessors and microcontrollers themselves and are intended to
117 provide assurance at a level AVA_VAN.1 as defined in [2], or without AVA_VAN claim.
118 2 Normative references
119 The following documents are referred to in the text in such a way that some or all of their content constitutes
120 requirements of this document. For dated references, only the edition cited applies. For undated references, the
121 latest edition of the referenced document (including any amendments) applies.
122 prEN 40000-1-3:2025, Cybersecurity requirements for products with digital elements — Vulnerability handling
123 3 Terms and definitions
124 For the purposes of this document, the terms and definitions given in prEN 40000-1-1:2025 and the following
125 apply.
126 ISO and IEC maintain terminology databases for use in standardization at the following addresses:
127 — ISO Online browsing platform: available at https://www.iso.org/obp/
128 — IEC Electropedia: available at https://www.electropedia.org/
129 3.1
130 access control
131 mechanism granting permission to a subject on an object
132 3.2
133 application
134 dependent component that provides a direct service to the end-user
135 3.3
136 asset
137 data, code or function that needs protection to prevent loss or disruption caused by a potential incident
138 3.4
139 best practices for cryptography
140 measures based on cryptographic techniques that have been shown to provide appropriate security for the
141 corresponding use case
142 3.5
143 dependent component
144 software or hardware component using a functionality of a platform and not providing any functionality to the
145 platform
146 3.6
147 device
148 composition of a platform and dependent components
149 3.7
150 end-user
151 user of the device
152 3.8
153 external entity
154 any entity in interaction with the platform
155 EXAMPLE Application, other dependent components or devices in physical or logical interaction with the platform
156 3.9
157 firmware
158 set of executable instructions which are optionally provided as a part of the platform and which can be immutable
159 and/or mutable
160 3.10
161 isolation mechanism
162 in a system separated in parts, security mechanism regulating the accesses to assets between those different
163 parts
164 3.11
165 physical attack
166 attack requiring the close presence of the attacker to the platform
167 3.12
168 platform
169 tangible element (or assembly of tangible elements) at a minimum composed of a microprocessor or
170 microcontroller implementing security functionalities
171 Note 1 to entry: Platforms can be non-application-specific.
172 3.13
173 platform code
174 code that is part of the implementation of the platform functionality
175 3.14
176 platform data
177 data handled by the platform i.e. user data, user code and platform manufacturer data
178 3.15
179 platform manufacturer data
180 data owned by the platform manufacturer handled by the platform
181 3.16
182 potential incident
183 specific event that could occur due to a threat exploiting a vulnerability
184 3.17
185 risk
186 result from the likelihood and magnitude of each threat
187 3.18
188 security functionality
189 functionality provided by the platform to the dependent component for the protection of assets (for example but
190 not limited to secure storage, cryptographic operations)
191 3.19
192 sensitive data
193 data that if compromised could harm the security functionalities of the platform or of the environment of the
194 platform
195 3.20
196 tamper-evidence
197 security property of a platform intended to ensure the detection of logical and/or physical attacks leading to
198 achievement of threats identified in the risk assessment
199 3.21
200 tamper-resistance
201 security property of a platform intended to prevent the successful exploitation of vulnerabilities by logical and/or
202 physical attacks leading to achievement of threats identified in the risk assessment
203 3.22
204 tamper-response
205 security property of a platform intended to provide the ability to react to the detection of logical and/or physical
206 attacks leading to achievement of threats identified in the risk assessment
207 3.23
208 threat
209 potential circumstance or cause that could lead to an incident on the product that results in loss or disruption
210 Note 1 to entry: Loss and disruption might happen amongst others on the product or its environment.
211 3.24
212 update package
213 bundle containing platform firmware and/or software code and/or data, potentially associated with metadata
214 3.25
215 user
216 platform user
217 generic term to designate any of the entities that will make use of the platform (including end-user)
218 3.26
219 user code
220 code implementing the dependent component
221 3.27
222 user data
223 data owned by (or associated to) the user handled by the platform
224 4 Symbols and abbreviated terms
CPU central processing unit
MCU microcontroller
MPU microprocessor
PI potential incident
SA security assumption
SOE security objectives for the platform environment
SOP security objectives for the platform
SP security policy
TR technical requirement
225 5 Application of this document
226 5.1 General
227 This document determines a set of technical requirements to be implemented by platforms based on a generic
228 security analysis detailed in Annex A, as well as the applicability conditions and assessment criteria for each of
229 the technical requirement.
230 In this document each technical requirement and associated information are presented in a dedicated clause
231 that follows a consistent structure. The next clause explains that structure and provide application instructions
232 common to all technical requirements where needed.
233 5.2 Technical requirement structure and common application instructions
234 5.2.1 Requirement
235 This subclause states the requirement to be implemented by the platform. It can cover one or several security
236 aspects.
237 5.2.2 Implementation options
238 This subclause lists the approved implementation options for fulfilling each security aspect of the requirement
239 clause.
240 5.2.3 Applicability
241 This subclause specifies the conditions under which the technical requirement applies.
242 Technical requirement applicability status is one of the followings:
243 — mandatory without exception;
244 — mandatory with authorized exceptions, subject to usage restrictions or delegation to other products;
245 — based on risk assessment in accordance with defined guidance.
246 In certain cases, individual security aspects of a requirement are subject to different applicability status.
247 5.2.4 Assessment
248 5.2.4.1 General
249 Each requirement is associated with assessment specifications structured according to the following
250 subclauses.
251 NOTE Each technical requirement ensures that all data it relies on to ensure security are always protected. For
252 example, if cryptographic keys or internal status flags are involved, their generation, import and/or storage is part of any
253 technical requirement relying on them. Therefore, the security assessment of each technical requirement also covers secure
254 handling at any time of all data involved in fulfilling the technical requirement.
255 5.2.4.2 Assessment objective
256 This assessment subclause identifies the security property or capability to verify, ensuring that the assessment
257 remains focused on the intent of the requirement.
258 5.2.4.3 Assessment preparation
259 This assessment subclause specifies the information and/or resources to be prepared and provided as input for
260 the assessment.
261 5.2.4.4 Assessment activities
262 5.2.4.4.1 General
263 This assessment subclause defines the assessment steps to be carried out, organized according to the following
264 subclauses.
265 Annex C provides the analysis how existing evaluation methodologies can be used to cover the following
266 assessment activities.
267 5.2.4.4.2 Input verification
268 This subclause specifies how to verify that the technical requirement is fulfilled based on input provided as part
269 of the assessment preparation.
270 5.2.4.4.3 Functional testing
271 This subclause specifies the functional tests to be performed to verify the full implementation of the requirement,
272 covering all security aspects.
273 The functional tests execution may be split between the developer and the assessor.
274 5.2.4.4.4 Resistance testing
275 This subclause defines the specific aspects of the resistance testing, such as:
276 — The attack scenario and relevant considerations to be applied;
277 — The implementation parts (e.g. mechanism, function, interface) to be targeted.
278 In accordance with those specific aspects, the resistance testing may apply the following common instructions:
279 — Consider the relevant attacks listed in [11] 5 (“Examples of attack methods”) and/or [12] 5 (“Examples of
280 attack methods”) as part of the analysis and/or alternative attack methods recognized relevant for specific
281 use cases or platform subcategories;
282 — Apply the attack potential level aligned with the applicable risk environment (see Clause A.6) using by
283 default the attack rating calculation defined in [11] 4 (“Identification of factors”) and/or [12] 4 (“Identification
284 of factors”), and/or another calculation recognized relevant for specific use cases or platform subcategories.
285 The penetration testing is based on the identification of areas of concern and prioritization of tests based on
286 vulnerability assessment.
287 5.2.5 Assessment verdict
288 This assessment subclause defines the conditions under which the assessment is considered valid.
289 For technical requirements where applicability is established, the verdict is PASS if:
290 — The input verification justifications are all satisfied;
291 — All applicable functional tests produce results consistent with the specified outputs;
292 — The resistance testing did not succeed in compromising the technical requirement.
293 For mandatory technical requirements where applicability exceptions are claimed, the verdict is PASS if required
294 corresponding security guidelines are addressed in 8.4.1.
295 In all cases, the verdict is FAIL if:
296 — An applicable technical requirement is not implemented;
297 — Any of the conditions for a PASS verdict are not fulfilled.
298 5.2.6 Assessment evidence
299 This assessment subclause defines the evidence that can be collected to demonstrate that the requirement has
300 been assessed and fulfilled.
301 Such evidence include, where applicable:
302 — test or assessment reports showing the steps performed and results obtained;
303 — logs, configuration files, or audit traces demonstrating the implementation of the requirement;
304 — screenshots, captures, or console outputs confirming the correct execution or protection behaviour.
305 6 Product context
306 6.1 Product’s intended and reasonably foreseeable use
307 In this document, products refer to microcontrollers and microprocessors, also known as platforms, that are
308 designed to be complemented with other components, software and/or hardware, to form a complete device.
309 They are intended to be used across a wide range of industries and applications, able to support multiple end
310 functions.
311 NOTE In some cases, particular configurations can be optimized for a specific final purpose, however fully closed
312 platforms, not intended to be completed to achieve a final function, are outside the scope of this document.
313 Microcontrollers are typically compact, cost-sensitive, low-power, and integrating a CPU, memory and
314 peripherals into a single package. This makes them fitting small and simple systems, such as consumer and
315 industrial devices (e.g. household appliances, toys, medical instruments, industrial machinery), IoT edge
316 devices, sensors, actuators, low-cost automation, real-time processing tasks.
317 Microprocessors offer higher performance but usually do not include integrated memory or peripherals. They
318 are suited for more complex systems that rely on rich operating systems, such as smartphones, tablets,
319 consumer electronics, human-machine interfaces, networking and connectivity solution, computers, high-
320 performance embedded systems (e.g. robotics, ECUs, medical imaging devices).
321 Different categories of platforms can be defined based on the type of security functionalities they offer, which
322 correspond to expected usage scenarios for integrating devices.
323 All platforms in scope at minimum belong to the following category:
324 — Core security category (PTF-COR) – platforms that implement the essential mandatory security features
325 forming the foundational baseline for platform-level protection.
326 Then, platforms may additionally belong to one or more of the following additional categories, depending on the
327 extended security functionalities they provide:
328 — Low tamper resistance (PTF-LTR) - platforms that offer additional protections against logical/physical
329 attacks, at an attack potential level AVA_VAN.1 as defined in [2].
330 — Advanced features category (PTF -ADV) - platforms that propose advanced internal features, intended to
331 extend security functionalities for the use to other products, network or services, such as isolation, access
332 control, advanced availability support, or reinitialization capabilities.
333 — Security services category (PTF-SER) - platforms that offer security functionalities on which higher level
334 security services can be built, such as authenticity proof generation, cryptographic features, secure storage,
335 secure communications, reporting of security events.
336 These last two categories support configurable combination of selectable security features (see Annex B). The
337 selection of features for integration is determined by the product intended use case and the results of its risk
338 assessment.
339 6.2 Product’s functions
340 The essential function of platforms is to provide generic security functionalities to the dependent components
341 via hardware and/or firmware and/or software. Platforms in scope of this document ensure protections against
342 attacks at an attack potential below AVA_VAN.2.
343 Platforms are capable of independently implementing all applicable security functionalities necessary for their
344 intended purpose, as determined by their risk assessment. However, certain specific aspects that are not
345 relevant to the platforms are typically handled by the operating system or other external components.
346 — Automatic aspects of secure updates;
347 — Mechanisms for end-users to opt out of secure updates, including notifications and options to postpone
348 updates;
349 — Mechanisms for end-users to opt out of reporting of security events.
350 6.3 Product’s operational environment of use
351 Platforms environment consists of two distinct parts: logical and physical. Each part can be categorized as
352 follows:
353 — Logical environment: this refers to software and hardware components outside the platform but that can
354 interact with it, either directly through defined interfaces, or indirectly via shared resources such as memory
355 or buses. The logical environment of the platform falls into one of the two categories:
356 — Trusted logical environment (ENV-TRL): environment where the interacting components are not
357 expected to intentionally compromise the platform (USR-TRE), or where no such components are
358 present.
359 — Untrusted logical environment (ENV-NTL): environment where the interacting components are
360 considered potential vectors of attack (USR-NTE). In these environments, platforms from the PTF-
361 ADV category that implement logical isolation from external component are required.
362 — Physical environment: this refers to users who have physical access to the platform. The physical
363 environment of the platform falls into one of the two categories:
364 — Trusted physical environment (ENV-TRP): environment where such users are not expected to
365 intentionally attempt to compromise the platform (USR-TRI and USR-TRE).
366 — Untrusted physical environment (ENV-NTP): environment where such users are considered potential
367 attackers or vectors of attacks. In such environments, platforms belonging to the PTF-MTR category
368 are required.
369 The environment categories to be selected depend on the integrating product use case and its corresponding
370 risk assessment.
371 When platform includes a remote data processing solution, it is possible for the core platform and its remote
372 part to operate in different environments. Each part therefore requires a distinct set of technical requirements
373 aligned with the specific environment.
374 6.4 Product’s system overview
375 Platforms in scope are composed of hardware and optionally firmware and/or operating system or application
376 execution environment.
377 The platform is also optionally composed of a remote data processing solution under the responsibility of the
378 platform manufacturer.
379 6.5 Product’s user
380 Platforms in scope interact with one or several of the following category of users:
381 — Trusted intermediate users (USR-TRI): users operating within a development phase, before deployment to
382 end-users, in which the platform is complemented with additional software and/or hardware layers to build
383 the final device to be commercialized, such as manufacturers of end products. These users are considered
384 trustworthy and are not expected to, or be used to, attempt compromising the platform. Such users may
385 belong to any category of environment. All categories of platforms are suitable for use cases involving such
386 users.
387 NOTE Intermediate users might not always be considered trustworthy by the platform manufacturer, who may
388 choose to implement additional protections to ensure platform-related intellectual property. However, such concerns
389 are outside the scope of this document.
390 — Trusted end-users (USR-TRE): legitimate users of the device integrating the platform, who are not expected
391 to, or be used to, attempt corrupting their own device. Such users may belong to any category of
392 environment. All categories of platforms are suitable for use cases involving such users.
393 — Untrusted end-users (USR-NTE): legitimate users of the device integrating the platform, who are
394 considered potential attacker or vector of attacks, typically in scenarios where the device enforces
395 restrictions on certain features. These users may attempt to bypass or compromise the platform security
396 functionalities. Such users can only belong to environment categories ENV-NTP or ENV-NTL. The platform
397 category PTF-LTR is required for use cases involving such users.
398 — Attackers (USR-ATT): individuals interacting with the device integrating the platform with the intent to
399 compromise it, directly or via other components. Such users can only belong to environment categories
400 ENV-NTP or ENV-NTL. The platform category PTF-LTR is required for use cases involving such users.
401 The user categories to be considered depend on the integrating product use case and its corresponding risk
402 assessment.
403 6.6 Product’s reasonably foreseeable misuse
404 For platforms in scope, the following categories of intentional or accidental misuses are reasonably foreseeable:
405 — Environment misuse (MIS-ENV): wrong category of platform is used regarding the environment identified
406 during the integrating product risk assessment. This is relevant for all platform categories.
407 — User misuse (MIS-USR): wrong category of platform is used regarding the applicable users identified during
408 the integrating product risk assessment. This is relevant for all platform categories.
409 — Integration misuse (MIS-INT): platform in scope is integrated without following the platform’s integration
410 guidelines.
411 7 Vulnerability handling activities and outcomes — TR_VUL Vulnerability handling
412 process
413 7.1 Requirement
414 A platform vulnerability handling process shall be put in place in compliance with prEN 40000-1-3:2025.
415 Given the intended risk environment for the platforms in scope, i.e. resistant to AVA_VAN.1 attack potential as
416 defined in [2] or without AVA_VAN claim, none of the requirement enhancements from prEN 40000-1-3:2025
417 5.1.2.1 are required.
418 7.2 Applicability
419 This technical requirement is mandatory.
420 7.3 Assessment
421 All assessment aspects of this technical requirement are covered by prEN 40000-1-3:2025.
422 The verdict PASS is assigned to the assessment case if the assessment verdict for all requirements in
423 prEN 40000-1-3:2025 are PASS.
424 8 Product technical requirements
425 8.1 General
426 The technical requirements specified in this clause define what is to be implemented by the platform to fulfil its
427 intended purpose. They have been established following a generic risk assessment for platforms described in
428 Annex A. Therefore, the risk assessment specific to a platform can be constructed by refining the activities
429 described in Annex A with platform specific information as follows:
430 — the platform context refines the information from 5.2.5 as needed;
431 — the platform assets list is established by refining the assets identified in Clause A.2 as needed;
432 — the incidents to be avoided are listed by refining the incidents identified in Clause A.3, with justification for
433 any excluded incident;
434 — the expected risk environment of the platform from Clause A.6 is determined;
435 — the threats to be prevented are listed by refining the threats identified in A.4.2, with justification for any
436 excluded threats.
437 The technical requirements presented in this clause are of three types:
438 — Technical requirements for the platform related to its implementation;
439 — Technical requirements for the platform, implemented by the platform itself which provide the expected
440 security functionalities and the associated robustness protections;
441 — Technical requirements related to the operation of the platform which ensure either:
442 — the security of the platform itself if the platform cannot ensure its self-protection, or
443 — the security of assets of the platform or of assets exported to the environment.
444 The implementation of technical requirements is submitted to a security assessment to ensure their application,
445 efficiency and robustness.
446 8.2 Technical requirements related to platform implementation
447 8.2.1 TR_IMP Implementation best practices
448 8.2.1.1 Requirement
449 The platform implementation shall reflect the application of rules covering best practices for secure design and
450 coding.
451 8.2.1.2 Implementation options
452 The best practices to be reflected in the platform implementation shall at minimum include the principles
453 described in [1] 5.3.
454 8.2.1.3 Applicability
455 This technical requirement is by default mandatory.
456 However, exception applies in case of organizational constraints (e.g. legacy platforms) provided that the verdict
457 to all applicable technical requirements is PASS.
458 8.2.1.4 Assessment
459 8.2.1.4.1 Assessment objective
460 The purpose of this assessment is to verify that the platform implementation design effectively ensures its
461 security.
462 8.2.1.4.2 Assessment preparation
463 Platform user manual(s) including:
464 — the intended support provided by the platform to dependent components and/or other external entities; and
465 — description of all exposed interfaces, with their specific intended purpose and data parameters.
466 Assessment verdicts for all mandatory technical requirements and for those resulting from the risk assessment.
467 Platform implementation information in the form of description and/or source code and/or platform samples
468 (representative of the product to be put on the market).
469 8.2.1.4.3 Assessment activities
470 8.2.1.4.3.1 Input verification
471 The input verification for each aspect of the implementation best practices requirement relies on the activities
472 outlined in Table 1 below:
473 Table 1 — TR_IMP input verification activities
Requirement aspects Verification activities
Eff
...