prEN 40002-3:2026
(Main)Cybersecurity requirements for tamper-resistant microprocessors and microcontrollers
- Abstract
This document specifies the technical requirements for general-purposes tamper-resistant microprocessors and microcontrollers intended for integration into products that rely on them as a foundational security component. The microprocessors and microcontrollers in scope are designed for deployment in environments where the security features of the product integrating the platform are of importance, and where the threat landscape includes attackers with low but non-negligeable attack potential, corresponding to AVA_VAN.2 to AVA_VAN.3 as defined in [13].
- Status
- Not Published
- Publication Date
- 10-Feb-2027
- Technical Committee
- CLC/TC 47X - Semiconductor devices and trusted chips
- Drafting Committee
- WG 02 - CLC/TC 47X/WG 02
- Current Stage
- 4060 - Enquiry results established and sent to TC, SR, BTTF - Enquiry
- Start Date
- 10-Apr-2026
- Due Date
- 18-Dec-2025
- Completion Date
- 10-Apr-2026
- Mandate
- M/XXX - M/XXX
prEN 40002-3:2026 is a CLC draft European Standard for cybersecurity requirements for tamper-resistant microprocessors and microcontrollers. It specifies the technical requirements for general-purpose platforms that are integrated into products as a foundational security component, for use where attackers have low but non-negligible attack potential.
The document is aimed at platform makers, product integrators, assessors, and security reviewers who need a common basis for design, integration, testing, and evidence.
What does prEN 40002-3:2026 specify?
prEN 40002-3:2026 specifies what tamper-resistant microprocessors and microcontrollers shall provide, how their applicability is determined, and how compliance is assessed. The scope covers platforms intended for integration into products that depend on them for security, especially where the threat model includes attackers with AVA_VAN.2 to AVA_VAN.3 attack potential.
The document is organized into:
- Clause 5, which defines how to apply the document and how requirements are structured and assessed
- Clause 6, which sets the product context, users, environments, and foreseeable misuse
- Clause 7, which covers vulnerability handling
- Clause 8, which lists the technical requirements for implementation, functions, and operation
- Annexes A, B, C, and ZZ, which support security analysis, applicability, assessment methodology, and the link to EU law
| Annex | What it covers |
|---|---|
| Annex A | Security analysis, including assets, incidents, threats, security objectives, and risk environments |
| Annex B | Platform categories and an applicability overview |
| Annex C | Support for European security evaluation methodologies and SESIP profile analysis |
| Annex ZZ | Relationship with the essential requirements of Regulation (EU) 2024/2847 |
What are the key requirements of prEN 40002-3:2026?
prEN 40002-3:2026 combines a common assessment model with a set of platform security requirements. In practice, it tells you what security functions the platform must provide, when a requirement applies, and what evidence an assessor should review.
How does the document tell you to apply requirements?
Clause 5 defines a common structure for every technical requirement:
- the requirement itself
- implementation options
- applicability
- assessment
- assessment verdict
- assessment evidence
This matters because the document is not just a list of features. It also tells manufacturers and assessors how to judge whether a platform has implemented them correctly, and what documentation or test results should support the claim.
Clause 5 also states three applicability patterns:
- mandatory without exception
- mandatory with authorized exceptions
- based on risk assessment
That means the platform integrator has to check whether a requirement is always expected, conditionally expected, or driven by the product’s risk assessment.
What product context does the standard expect?
Clause 6 defines the platform as hardware, with optional firmware and/or operating system or application execution environment, and possibly a remote data processing solution. It also separates logical and physical environments, and distinguishes trusted and untrusted environments and users.
This matters in practice because the security profile depends on where the platform is used and who can interact with it. For example:
- untrusted logical environments may require isolation from external components
- untrusted physical environments require tamper-resistant platforms
- untrusted end-users and attackers require the PTF-MTR category
Clause 6 also identifies foreseeable misuse such as wrong platform selection for the environment, wrong platform selection for the user model, or integration without following the platform guidance. That helps buyers and integrators check that the platform choice matches the intended deployment.
What does Clause 7 require?
Clause 7 requires a vulnerability handling process in compliance with prEN 40000-1-3:2025. For the threat environment covered by this document, no additional enhancements from that vulnerability-handling standard are required.
This is important because security does not end at design and test. The platform manufacturer has to manage vulnerabilities as part of the product lifecycle, and assessors can use that process as part of the conformity argument.
What are the main technical requirement groups in Clause 8?
Clause 8 is the core of the document. It covers:
- implementation best practices: TR_IMP
- no known exploitable vulnerabilities: TR_EXP
- secure configuration: TR_CFG
- platform identification and authentication: TR_PID and TR_PAU
- secure initialisation, updates, erasure, and reset: TR_INI, TR_SUP, TR_SUD, TR_ERA, and SRD_RST
- isolation, access control, storage, communications, and cryptography: TR_ISO, TR_ACC, TR_STO, TR_COM, and TR_CRY
- security event reporting and availability support: TR_REP and TR_AVS
- tamper-resistance: TR_RES
- application of platform security guidance: TR_SEG
In practical terms, these requirements cover the full security lifecycle of the platform. They are meant to protect the platform itself and the assets it handles, while also supporting dependent components that rely on the platform’s security functions.
How is compliance demonstrated?
Clause 5 and Annex C make clear that compliance is based on input verification, functional testing, and resistance testing. The document expects evidence such as test reports, logs, configuration files, audit traces, screenshots, captures, or console outputs.
That matters because assessors are not only checking design claims. They are checking that the security feature works, that it resists attack, and that there is traceable evidence for the result.
What terms does prEN 40002-3:2026 define?
prEN 40002-3:2026 defines the terms it uses for platforms, threats, users, and security functions. These definitions matter because the applicability of the requirements depends on them.
- Access control - a mechanism that grants permission to a subject on an object.
- Asset - data, code, or function that needs protection so it is not lost or disrupted.
- Device - the composition of a platform and dependent components.
- Platform - the tangible element, or assembly of tangible elements, at minimum composed of a microprocessor or microcontroller implementing security functionalities.
- Security functionality - a function provided by the platform to dependent components for protecting assets, such as secure storage or cryptographic operations.
- Tamper-resistance - the security property intended to prevent successful exploitation of vulnerabilities by logical and/or physical attacks.
- Tamper-evidence - the property intended to detect logical and/or physical attacks that lead to identified threats.
- Tamper-response - the property intended to react to detected logical and/or physical attacks.
- CPU, MCU, MPU - CPU means central processing unit, MCU means microcontroller, and MPU means microprocessor.
- TR, SP, SOP, SOE, PI, SA - TR means technical requirement, SP means security policy, SOP means security objectives for the platform, SOE means security objectives for the platform environment, PI means potential incident, and SA means security assumption.
Who uses prEN 40002-3:2026?
prEN 40002-3:2026 is used by semiconductor vendors, platform developers, product integrators, security evaluators, and buyers who need a tamper-resistant base for connected products. It is relevant to teams defining the security properties of MCUs and MPUs before they are built into a device.
Typical users and tasks include:
- chip designers, who implement the required security functions in hardware and firmware
- platform manufacturers, who define secure configuration, update, erasure, storage, and reporting behavior
- product integrators, who select the right platform category for the intended environment and user model
- security and quality managers, who align requirements with the risk assessment and collect evidence
- evaluation laboratories and assessors, who perform input verification, functional testing, and resistance testing
- buyers and product architects, who compare platform capability against the needs of the final device
The use cases mentioned in the document include consumer devices, industrial devices, IoT edge devices, sensors, actuators, low-cost automation, smartphones, tablets, networking equipment, computers, robotics, ECUs, and medical imaging devices.
Which standards are used with prEN 40002-3:2026?
prEN 40002-3:2026 uses prEN 40000-1-1:2025 and prEN 40000-1-3:2025 as normative references. The first provides the common vocabulary for products with digital elements, and the second provides the vulnerability handling framework referenced by Clause 7.
The document also uses related standards and methods to support assessment and resistance testing:
- prEN 40000-1-2:2025 - principles for cyber resilience used in the bibliography
- EN 17927:2023 - SESIP methodology for cybersecurity assessment and reuse
- EN ISO/IEC 15408-2:2023 - security functional components
- EN ISO/IEC 15408-3:2023 - security assurance components
- EN 17640:2022 - fixed-time cybersecurity evaluation methodology
- EUCC and GlobalPlatform attack-potential and attack-method documents - used for resistance testing and attack analysis
These references matter because they connect the platform requirements to established evaluation and testing approaches.
What does the prEN 40002-3:2026 document contain?
prEN 40002-3:2026 contains a common requirement structure, a product-context model, a vulnerability-handling clause, and a detailed set of platform technical requirements. It also includes a generic security analysis in Annex A, which organizes assets, incidents, threats, assumptions, objectives, and risk environments.
Annex B provides a platform category and applicability overview, which helps readers decide which requirements fit a given use case. Annex C explains how existing European evaluation methodologies can support the assessment activities, including SESIP-style compliance demonstration and the mapping of requirements to evaluation profiles.
Annex ZZ maps the document to the essential requirements of Regulation (EU) 2024/2847. For readers working on market access or conformity arguments, this is the part that links the technical clauses to the EU cybersecurity framework.
Get Certified
Connect with accredited certification bodies for this standard
BSI Group
BSI (British Standards Institution) is the business standards company that helps organizations make excellence a habit.
Bureau Veritas
Bureau Veritas is a world leader in laboratory testing, inspection and certification services.
DNV
DNV is an independent assurance and risk management provider.
Sponsored listings
Frequently Asked Questions
prEN 40002-3:2026 is a draft published by CLC. Its full title is "Cybersecurity requirements for tamper-resistant microprocessors and microcontrollers". This standard covers: This document specifies the technical requirements for general-purposes tamper-resistant microprocessors and microcontrollers intended for integration into products that rely on them as a foundational security component. The microprocessors and microcontrollers in scope are designed for deployment in environments where the security features of the product integrating the platform are of importance, and where the threat landscape includes attackers with low but non-negligeable attack potential, corresponding to AVA_VAN.2 to AVA_VAN.3 as defined in [13].
This document specifies the technical requirements for general-purposes tamper-resistant microprocessors and microcontrollers intended for integration into products that rely on them as a foundational security component. The microprocessors and microcontrollers in scope are designed for deployment in environments where the security features of the product integrating the platform are of importance, and where the threat landscape includes attackers with low but non-negligeable attack potential, corresponding to AVA_VAN.2 to AVA_VAN.3 as defined in [13].
prEN 40002-3:2026 is classified under the following ICS (International Classification for Standards) categories: 35.030 - IT Security; 35.160 - Microprocessor systems. The ICS classification helps identify the subject area and facilitates finding related standards.
prEN 40002-3:2026 is associated with the following European legislation: EU Directives/Regulations: 2024/2847; Standardization Mandates: M/606, M/XXX. When a standard is cited in the Official Journal of the European Union, products manufactured in conformity with it benefit from a presumption of conformity with the essential requirements of the corresponding EU directive or regulation.
prEN 40002-3:2026 is available in PDF format for immediate download after purchase. The document can be added to your cart and obtained through the secure checkout process. Digital delivery ensures instant access to the complete standard document.
Standards Content (Sample)
SLOVENSKI STANDARD
01-marec-2026
Zahteve za kibernetsko varnost za mikroprocesorje in mikrokrmilnike, odporne
proti nedovoljenim posegom
Cybersecurity requirements for tamper-resistant microprocessors and microcontrollers
Cybersicherheitsanforderungen für sichere Mikroprozessoren und Mikrocontroller mit
oder ohne Anwendungsumgebung oder Betriebssystem
Exigences de cybersécurité pour les microprocesseurs et microcontrôleurs sécurisés
avec ou sans environnement d’application ou système d’exploitation
Ta slovenski standard je istoveten z: prEN 50766: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 50766
NORME EUROPÉENNE
EUROPÄISCHE NORM
January 2026
ICS 35.030; 35.160 -
English Version
Cybersecurity requirements for tamper-resistant
microprocessors and microcontrollers
Exigences de cybersécurité pour les microprocesseurs et Cybersicherheitsanforderungen für sichere
microcontrôleurs sécurisés avec ou sans environnement Mikroprozessoren und Mikrocontroller mit oder ohne
d'application ou système d'exploitation Anwendungsumgebung oder Betriebssystem
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: 80924 Ref. No. prEN 50766:2026 E
prEN 50766:2026 (E)
Contents Page
17 European foreword . 5
18 1 Scope . 6
19 2 Normative references . 6
20 3 Terms and definitions . 6
21 4 Symbols and abbreviated terms . 8
22 5 Application of this document . 9
23 5.1 General . 9
24 5.2 Technical requirement structure and common application instructions . 9
25 5.2.1 Requirement . 9
26 5.2.2 Implementation options . 9
27 5.2.3 Applicability. 9
28 5.2.4 Assessment . 9
29 5.2.5 Assessment verdict .10
30 5.2.6 Assessment evidence .11
31 6 Product context .11
32 6.1 Product’s intended and reasonably foreseeable use .11
33 6.2 Product’s functions .12
34 6.3 Product’s operational environment of use .12
35 6.4 Product’s system overview .12
36 6.5 Product’s user .13
37 6.6 Product’s reasonably foreseeable misuse.13
38 7 Vulnerability handling activities and outcomes — TR_VUL Vulnerability handling process
39 .13
40 7.1 Requirement .13
41 7.2 Applicability.14
42 7.3 Assessment .14
43 8 Product technical requirements .14
44 8.1 General .14
45 8.2 Technical requirements related to platform implementation .14
46 8.2.1 TR_IMP Implementation best practices .14
47 8.2.2 TR_EXP No known exploitable vulnerabilities .16
48 8.2.3 TR_CFG Secure configuration of platform .17
49 8.3 Technical requirements related to platform functionalities .18
50 8.3.1 TR_PID Identification of platform .18
51 8.3.2 TR_PAU Authentication of platform .21
52 8.3.3 TR_INI Secure initialisation support .23
53 8.3.4 TR_SUP Secure update of platform .27
54 8.3.5 TR_SUD Secure update of dependent components .31
55 8.3.6 TR_ERA Secure erasure of data .33
56 8.3.7 TR_ISO Isolation mechanisms .35
57 8.3.8 TR_ACC Access control to security functionalities .38
58 8.3.9 TR_STO Secure storage .40
59 8.3.10 TR_COM Secure communications .45
60 8.3.11 TR_CRY Secure cryptographic features .49
61 8.3.12 TR_REP Reporting of security events .50
62 8.3.13 TR_AVS Advanced availability support of basic and essential functions .53
63 8.3.14 SRD_RST Reset of platform to initial state .55
64 8.3.15 TR_RES Tamper-resistance of platform .57
65 8.4 Technical requirements related to platform operation .61
66 8.4.1 TR_SEG Application of platform security guidance .61
67 Annex A (informative) Security analysis .63
prEN 50766:2026 (E)
68 A.1 General . 63
69 A.2 Assets . 64
70 A.3 Security incidents . 65
71 A.3.1 General . 65
72 A.3.2 PI_DUD Disclosure of user data . 65
73 A.3.3 PI_MUD Manipulation of user data . 65
74 A.3.4 PI_MBD Modification of the behaviour of the device . 65
75 A.3.5 PI_MCD Malicious control of the device . 65
76 A.3.6 PI_UEB Unavailability of essential and basic functions of the device . 65
77 A.3.7 PI_MDO Malicious use of the device against other devices or networks . 65
78 A.3.8 Completeness of incidents identification . 65
79 A.4 Security problem definition . 66
80 A.4.1 General . 66
81 A.4.2 Threats . 66
82 A.4.3 Organizational security policies . 67
83 A.4.4 Security assumptions . 67
84 A.4.5 Risks analysis coverage . 68
85 A.5 Security objectives . 68
86 A.5.1 General . 68
87 A.5.2 Security objectives for the platform . 68
88 A.5.3 Security objectives for the environment . 69
89 A.5.4 Security problem definition coverage . 69
90 A.5.5 Security objectives coverage . 70
91 A.6 Risk environments . 72
92 A.6.1 General . 72
93 A.6.2 Example of platform risk environment (attack potential) information reuse . 72
94 Annex B (informative) Platform categories and applicability overview . 74
95 Annex C (informative) Support of European security evaluation methodologies . 77
96 C.1 General . 77
97 C.2 Compliance demonstration support . 77
98 C.2.1 Assessment of applicability . 77
99 C.2.2 TR_IMP Implementation best practices . 77
100 C.2.3 TR_EXP No known exploitable vulnerabilities . 77
101 C.2.4 TR_CFG Secure configuration of platform . 78
102 C.2.5 TR_PID Identification of platform . 78
103 C.2.6 TR_PAU Authenticity of platform . 79
104 C.2.7 TR_INI Secure initialisation support . 79
105 C.2.8 TR_SUP Secure update of platform . 80
106 C.2.9 TR_SUD Secure update of dependent component . 82
prEN 50766:2026 (E)
107 C.2.10 TR_ERA Secure erasure of data .83
108 C.2.11 TR_ISO Isolation mechanisms .84
109 C.2.12 TR_ACC Access control to security functionalities .85
110 C.2.13 TR_STO Secure storage .86
111 C.2.14 TR_COM Secure communication .88
112 C.2.15 TR_CRY Secure cryptographic features .89
113 C.2.16 TR_REP Reporting of security events .90
114 C.2.17 TR_AVS Advanced availability support of basic and essential functions .91
115 C.2.18 TR_RST Reset of platform to initial state .92
116 C.2.19 TR_RES Tamper resistance of platform .93
117 C.2.20 TR_SEG Application of platform security guidance .94
118 C.3 SESIP profiles analysis of compliance support .94
119 Annex ZZ (informative) Relationship between this European Standard and the essential
120 requirements of Regulation (EU) 2024/2847 aimed to be covered .99
121 Bibliography .102
prEN 50766:2026 (E)
122 European foreword
123 This document (prEN 50766:2026) has been prepared by CLC TC47X “semiconductors and trusted chips
124 implementation”.
125 This document is currently submitted to the Enquiry
126 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)
127 This document has been prepared under a standardization request addressed to CENELEC by the European
128 Commission. The Standing Committee of the EFTA States subsequently approves these requests for its
129 Member States.
130 For the relationship with EU Legislation, see informative Annex ZZ, which is an integral part of this document.
prEN 50766:2026 (E)
131 1 Scope
132 This document specifies the technical requirements for general-purposes tamper-resistant microprocessors and
133 microcontrollers intended for integration into products that rely on them as a foundational security component.
134 The microprocessors and microcontrollers in scope are designed for deployment in environments where the
135 security features of the product integrating the platform are of importance, and where the threat landscape
136 includes attackers with low but non-negligeable attack potential, corresponding to AVA_VAN.2 to
137 AVA_VAN.3 as defined in [13].
138 2 Normative references
139 The following documents are referred to in the text in such a way that some or all of their content constitutes
140 requirements of this document. For dated references, only the edition cited applies. For undated references, the
141 latest edition of the referenced document (including any amendments) applies.
142 prEN 40000-1-1:2025, Cybersecurity requirements for products with digital elements - Vocabulary
143 prEN 40000-1-3:2025, Cybersecurity requirements for products with digital elements — Vulnerability handling
144 3 Terms and definitions
145 For the purposes of this document, the terms and definitions given in prEN 40000-1-1:2025 and the following
146 apply.
147 ISO and IEC maintain terminology databases for use in standardization at the following addresses:
148 — ISO Online browsing platform: available at https://www.iso.org/obp/
149 — IEC Electropedia: available at https://www.electropedia.org/
150 3.1
151 access control
152 mechanism granting permission to a subject on an object
153 3.2
154 application
155 dependent component that provides a direct service to the end-user
156 3.3
157 asset
158 data, code or function that needs protection to prevent loss or disruption caused by a potential incident
159 3.4
160 best practices for cryptography
161 measures based on cryptographic techniques that have been shown to provide appropriate security for the
162 corresponding use case
163 3.5
164 dependent component
165 software or hardware component using a functionality of a platform and not providing any functionality to the
166 platform
167 3.6
168 device
169 composition of a platform and dependent components
prEN 50766:2026 (E)
170 3.7
171 end-user
172 user of the device
173 3.8
174 external entity
175 any entity in interaction with the platform
176 EXAMPLE Application, other dependent components or devices in physical or logical interaction with the platform.
177 3.9
178 firmware
179 set of executable instructions which are optionally provided as a part of the platform and which can be immutable
180 and/or mutable
181 3.10
182 isolation mechanism
183 in a system separated in parts, security mechanism regulating the accesses to assets between those different
184 parts
185 3.11
186 physical attack
187 an attack requiring the close presence of the attacker to the platform
188 3.12
189 platform
190 tangible element (or assembly of tangible elements) at a minimum composed of a microprocessor or
191 microcontroller implementing security functionalities
192 Note 1 to entry: Platforms can be non-application-specific.
193 3.13
194 platform code
195 code that is part of the implementation of the platform functionality
196 3.14
197 platform data
198 all data handled by the platform i.e. user data, user code and platform manufacturer data
199 3.15
200 platform manufacturer data
201 data owned by the platform manufacturer handled by the platform
202 3.16
203 potential incident
204 specific event that could occur due to a threat exploiting a vulnerability
205 3.17
206 risk
207 result from the likelihood and magnitude of each threat
208 3.18
209 security functionality
210 functionality provided by the platform to the dependent components for the protection of assets (for example
211 but not limited to secure storage, cryptographic operations)
prEN 50766:2026 (E)
212 3.19
213 sensitive data
214 data that if compromised could harm the security functionalities of the platform or of the environment of the
215 platform
216 3.20
217 tamper-evidence
218 security property of a platform intended to ensure the detection of logical and/or physical attacks leading to
219 achievement of threats identified in the risk assessment
220 3.21
221 tamper-resistance
222 security property of a platform intended to prevent the successful exploitation of vulnerabilities by logical and/or
223 physical attacks leading to achievement of threats identified in the risk assessment
224 3.22
225 tamper-response
226 security property of a platform intended to provide the ability to react to the detection of logical and/or physical
227 attacks leading to achievement of threats identified in the risk assessment
228 3.23
229 threat
230 potential circumstance or cause that could lead to an incident on the product that results in loss or disruption
231 Note 1 to entry: Loss and disruption might happen amongst others on the product or its environment.
232 3.24
233 update package
234 bundle containing platform firmware and/or software code and/or data, potentially associated with metadata
235 3.25
236 user
237 platform user
238 generic term to designate any of the entities that will make use of the platform (including end-user)
239 3.26
240 user code
241 code implementing the dependent component
242 3.27
243 user data
244 data owned by (or associated to) the user handled by the platform
245 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
prEN 50766:2026 (E)
TR technical requirement
246 5 Application of this document
247 5.1 General
248 This document determines a set of technical requirements to be implemented by platforms based on a generic
249 security analysis detailed in Annex A as well as the applicability conditions and assessment criteria for each of
250 the technical requirement.
251 In this document each technical requirement and associated information are presented in a dedicated clause
252 that follows a consistent structure. The next clause explains that structure and provide application instructions
253 common to all technical requirements where needed.
254 5.2 Technical requirement structure and common application instructions
255 5.2.1 Requirement
256 This subclause states the requirement to be implemented by the platform. It can cover one or several security
257 aspects.
258 5.2.2 Implementation options
259 This subclause lists the approved implementation options for fulfilling each security aspect of the requirement
260 clause.
261 5.2.3 Applicability
262 This subclause specifies the conditions under which the technical requirement applies.
263 Technical requirement applicability status is one of the followings:
264 — mandatory without exception;
265 — mandatory with authorized exceptions, subject to usage restrictions or delegation to other products;
266 — based on risk assessment in accordance with defined guidance.
267 In certain cases, individual security aspects of a requirement are subject to different applicability status.
268 5.2.4 Assessment
269 5.2.4.1 General
270 Each requirement is associated with assessment specifications structured according to the following
271 subclauses.
272 NOTE Each technical requirement ensures that all data it relies on to ensure security are always protected. For
273 example, if cryptographic keys or internal status flags are involved, their generation, import and/or storage is part of any
274 technical requirement relying on them. Therefore, the security assessment of each technical requirement also covers secure
275 handling at any time of all data involved in fulfilling the technical requirement.
276 5.2.4.2 Assessment objective
277 This assessment clause identifies the security property or capability to verify, ensuring that the assessment
278 remains focused on the intent of the requirement.
279 5.2.4.3 Assessment preparation
280 This assessment clause specifies the information and/or resources to be prepared and provided as input for the
281 assessment.
prEN 50766:2026 (E)
282 5.2.4.4 Assessment activities
283 5.2.4.4.1 General
284 This assessment clause defines the assessment steps to be carried out, organized according to the following
285 subclauses.
286 Annex C provides the analysis how existing evaluation methodologies can be used to cover the following
287 assessment activities.
288 5.2.4.4.2 Input verification
289 This subclause specifies how to verify that the technical requirement is fulfilled based on input provided as part
290 of the assessment preparation.
291 5.2.4.4.3 Functional testing
292 This subclause specifies the functional tests to be performed to verify the full implementation of the requirement,
293 covering all security aspects.
294 The functional tests execution may be split between the developer and the assessor.
295 5.2.4.4.4 Resistance testing
296 This subclause defines the specific aspects of the resistance testing, such as:
297 — The attack scenario and relevant considerations to be applied;
298 — The implementation parts (e.g. mechanism, function, interface) to be targeted.
299 In accordance with those specific aspects, the resistance testing may apply the following common instructions:
300 — Consider the relevant attacks listed in [15] 5 (“Examples of attack methods”) and/or [16] 5 (“Examples
301 of attack methods”) as part of the analysis and/or alternative attack methods recognized relevant for
302 specific use cases or platform subcategories;
303 — Apply the attack potential level aligned with the applicable risk environment (see Clause A.6) using by
304 default the attack rating calculation defined in [15] 4 (“Identification of factors”) and/or [16] 4
305 (“Identification of factors”), and/or another calculation recognized relevant for specific use cases or
306 platform subcategories.
307 The penetration testing is based on the identification of areas of concern and prioritization of tests based on
308 vulnerability assessment.
309 5.2.5 Assessment verdict
310 This assessment clause defines the conditions under which the assessment is considered valid.
311 For technical requirements where applicability is established, the verdict is PASS if:
312 — The input verification justifications are all satisfied;
313 — All applicable functional tests produce results consistent with the specified outputs;
314 — The resistance testing did not succeed in compromising the technical requirement.
315 For mandatory technical requirements where applicability exceptions are claimed, the verdict is PASS if required
316 corresponding security guidelines are addressed in 8.4.1.
317 In all cases, the verdict is FAIL if:
318 — An applicable technical requirement is not implemented;
319 — Any of the conditions for a PASS verdict are not fulfilled.
prEN 50766:2026 (E)
320 5.2.6 Assessment evidence
321 This assessment subclause defines the evidence that can be collected to demonstrate that the requirement has
322 been assessed and fulfilled.
323 Such evidence include, where applicable:
324 — test or assessment reports showing the steps performed and results obtained;
325 — logs, configuration files, or audit traces demonstrating the implementation of the requirement;
326 — screenshots, captures, or console outputs confirming the correct execution or protection behaviour.
327 6 Product context
328 6.1 Product’s intended and reasonably foreseeable use
329 In this document, products refer to microcontrollers and microprocessors, also known as platforms, that are
330 designed to be complemented with other components software and/or hardware to form a complete device.
331 They are intended to be used across a wide range of industries and applications, able to support multiple end
332 functions.
333 NOTE In some cases, particular configurations can be optimized for a specific final purpose, however fully closed
334 platforms not intended to be completed to achieve a final function are outside the scope of this document.
335 Microcontrollers are typically compact, cost-sensitive, low-power, and integrating a CPU, memory and
336 peripherals into a single package. This makes them fitting for small and simple systems, such as consumer and
337 industrial devices (e.g. household appliances, toys, medical instruments, industrial machinery), IoT edge
338 devices, sensors, actuators, low-cost automation, real-time processing tasks.
339 Microprocessors offer higher performance but usually do not include integrated memory or peripherals. They
340 are suited for more complex systems that rely on rich operating systems, such as smartphones, tablets,
341 consumer electronics, human-machine interfaces, networking and connectivity solution, computers, high-
342 performance embedded systems (e.g. robotics, ECUs, medical imaging devices).
343 Additionally, the platforms covered in this document, are considered tamper-resistant, implementing protection
344 against attacks with a potential corresponding to AVA_VAN.2 or AVA_VAN.3, as defined in [13]. They are then
345 suitable for integration into devices that operate in environments where the threat landscape includes attackers
346 with a low, but non-negligeable, attack potential, whether through remote-only or physical access to the device.
347 Different categories of platforms can be defined based on the type of security functionalities they offer, which
348 correspond to expected usage scenarios for integrating devices.
349 All platforms in scope at minimum belong to the following categories:
350 — Core security category (PTF-COR) – platforms that implement the essential mandatory security features
351 forming the foundational baseline for platform-level protection.
352 — Medium tamper-resistance category (PTF-MTR) – platform that implement protection against logical and/or
353 physical attacks with a potential corresponding to AVA_VAN.2 or AVA_VAN.3 as defined in [13].
354 Then, platforms may additionally belong to one or more of the following additional categories, depending on the
355 extended security functionalities they provide:
356 — Advanced features category (PTF -ADV) - platforms that propose advanced internal features, intended to
357 extend security functionalities for the use to other products, network or services, such as isolation, access
358 control, advanced availability support, or reinitialization capabilities.
359 — Security services category (PTF-SER) - platforms that offer security functionalities on which higher level
360 security services can be built, such as authenticity proof generation, cryptographic features, secure storage,
361 secure communications, reporting of security events.
prEN 50766:2026 (E)
362 These last two categories support configurable combination of selectable security features (see Annex B). The
363 selection of features for integration is determined by the product intended use case and the results of its risk
364 assessment.
365 6.2 Product’s functions
366 The essential function of platforms is to provide generic security functionalities to the dependent components
367 via hardware and/or firmware and/or software. Platforms in scope of this document ensure protections against
368 attacks with a potential corresponding to AVA_VAN.2 or AVA_VAN.3, as defined in [13].
369 Platforms are capable of independently implementing all applicable security functionalities necessary for their
370 intended purpose, as determined by their risk assessment. However, certain specific aspects that are not
371 relevant to the platforms are typically handled by the operating system or other external components.
372 — Automatic aspects of secure updates;
373 — Mechanisms for end-users to opt out of secure updates, including notifications and options to postpone
374 updates;
375 — Mechanisms for end-users to opt out of reporting of security events.
376 6.3 Product’s operational environment of use
377 Platforms environment consists of two distinct parts: logical and physical. Each part can be categorized as
378 follows:
379 — Logical environment: this refers to software and hardware components outside the platform but that can
380 interact with it, either directly through defined interfaces, or indirectly via shared resources such as memory
381 or buses. The logical environment of the platform falls into one of the two categories:
382 — Trusted logical environment (ENV-TRL): environment where the interacting components are not
383 expected to intentionally compromise the platform (USR-TRE), or where no such components are
384 present.
385 — Untrusted logical environment (ENV-NTL): environment where the interacting components are
386 considered potential vectors of attack (USR-NTE). In these environments, platforms from the PTF-
387 ADV category that implement logical isolation from external component are required.
388 — Physical environment: this refers to users who have physical access to the platform. The physical
389 environment of the platform falls into one of the two categories:
390 — Trusted physical environment (ENV-TRP): environment where such users are not expected to
391 intentionally attempt to compromise the platform (USR-TRI and USR-TRE).
392 — Untrusted physical environment (ENV-NTP): environment where such users are considered potential
393 attackers or vectors of attacks. In such environments, platforms belonging to the PTF-MTR category
394 are required.
395 The environment categories to be selected depend on the integrating product use case and its corresponding
396 risk assessment.
397 When platform includes a remote data processing solution, it is possible for the core platform and its remote
398 part to operate in different environments. Each part therefore requires a distinct set of technical requirements
399 aligned with the specific environment.
400 6.4 Product’s system overview
401 Platforms in scope are composed of hardware and optionally firmware and/or operating system or application
402 execution environment.
prEN 50766:2026 (E)
403 The platform is also optionally composed of a remote data processing solution under the responsibility of the
404 platform manufacturer.
405 6.5 Product’s user
406 Platforms in scope interact with one or several of the following category of users:
407 — Trusted intermediate users (USR-TRI): users operating within a development phase, before deployment to
408 end-users, in which the platform is complemented with additional software and/or hardware layers to build
409 the final device to be commercialized, such as manufacturers of end products. These users are considered
410 trustworthy and are not expected to, or be used to, attempt compromising the platform. Such users may
411 belong to any category of environment. All categories of platforms are suitable for use cases involving such
412 users.
413 NOTE Intermediate users might not always be considered trustworthy by the platform manufacturer, who may
414 choose to implement additional protections to ensure platform-related intellectual property. However, such concerns
415 are outside the scope of this document.
416 — Trusted end-users (USR-TRE): legitimate users of the device integrating the platform, who are not expected
417 to, or be used to, attempt corrupting their own device. Such users may belong to any category of
418 environment. All categories of platforms are suitable for use cases involving such users.
419 — Untrusted end-users (USR-NTE): legitimate users of the device integrating the platform, who are
420 considered potential attacker or vector of attacks, typically in scenarios where the device enforces
421 restrictions on certain features. These users may attempt to bypass or compromise the platform security
422 functionalities. Such users can only belong to environment categories ENV-NTP or ENV-NTL. The platform
423 category PTF-MTR is required for use cases involving such users.
424 — Attackers (USR-ATT): individuals interacting with the device integrating the platform with the intent to
425 compromise it, directly or via other components. Their attack potential of attack corresponds to AVA_VAN.2
426 and AVA_VAN.3 as defined in [13], depending on their level of access, respectively remote only or including
427 physical access. Such users can only belong to environment categories ENV-NTP or ENV-NTL. The
428 platform category PTF-MTR is required for use cases involving such users.
429 The user categories to be considered depend on the integrating product use case and its corresponding risk
430 assessment.
431 6.6 Product’s reasonably foreseeable misuse
432 For platforms in scope, the following categories of intentional or accidental misuses are reasonably foreseeable:
433 — Environment misuse (MIS-ENV): wrong category of platform is used regarding the environment identified
434 during the integrating product risk assessment. This is relevant for all platform categories.
435 — User misuse (MIS-USR): wrong category of platform is used regarding the applicable users identified during
436 the integrating product risk assessment. This is relevant for all platform categories.
437 — Integration misuse (MIS-INT): platform in scope is integrated without following the platform integration
438 guidelines.
439 7 Vulnerability handling activities and outcomes — TR_VUL Vulnerability handling
440 process
441 7.1 Requirement
442 A platform vulnerability handling process shall be put in place in compliance with prEN 40000-1-3:2025.
prEN 50766:2026 (E)
443 Given the intended risk environment for the platforms in scope, i.e. resistant to AVA_VAN.2 or AVA_VAN.3
444 attack potential as defined in [13], none of the requirement enhancements from prEN 40000-1-3:2025, 5.1.2.1
445 are required.
446 7.2 Applicability
447 This technical requirement is mandatory.
448 7.3 Assessment
449 All assessment aspects of this technical requirement are covered by prEN 40000-1-3:2025.
450 The verdict PASS is assigned to the assessment case if the assessment verdict for all requirements in
451 prEN 40000-1-3:2025 are PASS.
452 8 Product technical requirements
453 8.1 General
454 The technical requirements specified in this clause define what is to be implemented by the platform to fulfil its
455 intended purpose. They have been established following a generic risk assessment for platforms described in
456 Annex A. Therefore, the risk assessment specific to a platform can be constructed by refining the activities
457 described in Annex A with platform specific information as follows:
458 — the platform context refines the information from 5.2.5 as needed;
459 — the platform assets list is established by refining the assets identified in Clause A.2 as needed;
460 — the incidents to be avoided are listed by refining the incidents identified in Clause A.3, with justification for
461 any excluded incident;
462 — the expected risk environment of the platform from Clause A.6 is determined;
463 — the threats to be prevented are listed by refining the threats identified in A.4.2, with justification for any
464 excluded threats.
465 The technical requirements presented in this clause are of three types:
466 — Technical requirements for the platform related to its implementation;
467 — Technical requirements for the platform, implemented by the platform itself which provide the expected
468 security functionalities and the associated robustness protections;
469 — Technical requirements related to the operation of the platform which ensure either:
470 — the security of the platform itself if the platform cannot ensure its self-protection, or
471 — the security of assets of the platform or of assets exported to the environment.
472 The implementation of technical requirements is submitted to a security assessment to ensure their application,
473 efficiency and robustness.
474 8.2 Technical requirements related to platform implementation
475 8.2.1 TR_IMP Implementation best practices
476 8.2.1.1 Requirement
477 The platform implementation shall reflect the application of rules covering best practices for secure design and
478 coding.
prEN 50766:2026 (E)
479 8.2.1.2 Implementation options
480 The best practices to be reflected in the platform implementation shall at minimum include the princip
...