oSIST prEN 50766:2026

• 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
• Public Enquiry End Date: 31-Mar-2026
• ICS: 35.030 - IT Security
• ICS: 35.160 - Microprocessor systems
• Technical Committee: I11 - Imaginarni 11
• Current Stage: 4020 - Public enquire (PE) (Adopted Project)
• Start Date: 20-Jan-2026
• Due Date: 09-Jun-2026
• Completion Date: 26-Mar-2026
• Directive: 2024/2847 - Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act) (Text with EEA relevance)
• Mandate: M/606 - on a standardisation request to European Standards Organisations in support of Union policy on cybersecurity requirements for products with digital elements
• Mandate: M/XXX - M/XXX
• Ref Project: prEN 40002-3:2026 - Cybersecurity requirements for tamper-resistant microprocessors and microcontrollers

oSIST prEN 50766:2026 is the Slovenian standard identical to the draft European Standard prEN 50766:2026, published by SIST/CENELEC for cybersecurity of tamper-resistant microprocessors and microcontrollers. It specifies technical requirements for general-purpose platforms that are integrated into larger products and act as a foundational security component. The document is aimed at engineers, product integrators, quality teams, buyers, and assessors who need a platform designed for environments where attackers have low but non-negligible attack potential.

What does oSIST prEN 50766:2026 specify?

oSIST prEN 50766:2026 specifies the technical requirements for general-purpose tamper-resistant microprocessors and microcontrollers that are intended to be integrated into products. The scope is framed around products whose security features depend on the platform, and it targets threat conditions corresponding to AVA_VAN.2 to AVA_VAN.3.

oSIST prEN 50766:2026 is organized as follows: clauses 1 to 4 cover scope, references, terms, and symbols; clause 5 explains how to apply the document; clause 6 sets the product context; clause 7 covers vulnerability handling; and clause 8 gives the product technical requirements. The document also includes informative annexes for security analysis, platform categories, evaluation methodology support, and the relationship with EU cybersecurity law.

Annex	What it covers
Annex A	Security analysis: assets, incidents, threats, security objectives, assumptions, and risk environments
Annex B	Platform categories and applicability overview
Annex C	Support of European security evaluation methodologies and SESIP profile analysis
Annex ZZ	Relationship with Regulation (EU) 2024/2847

The scope excludes fully closed platforms that are not intended to be completed into a final function. In practice, that means the standard is meant for platforms that become part of a broader device and need to be selected, integrated, and assessed in that role.

What are the key requirements of oSIST prEN 50766:2026?

oSIST prEN 50766:2026 combines a generic risk-based structure with detailed technical requirements. For users, the main point is that the platform must be designed, configured, handled, and assessed as a security component, not just as hardware.

How does the document structure compliance and assessment?

oSIST prEN 50766:2026 uses a common structure for each technical requirement: requirement, implementation options, applicability, assessment, assessment verdict, and assessment evidence. Clause 5 matters in practice because it tells teams what must be implemented, what can be justified by risk or exception, and what evidence must be kept for evaluation.

Clause 5.2.4 requires three assessment activities: input verification, functional testing, and resistance testing. That matters because conformity is not based only on documentation - it also depends on test results and on whether resistance testing can break the claimed security property.

Clause 5.2.5 defines the PASS and FAIL logic. If a requirement is applicable, the verdict depends on successful verification, functional testing, and resistance testing; where exceptions are claimed, the required security guidance must be addressed.

How does the document classify the platform context?

oSIST prEN 50766:2026 uses product-context classifications to connect the platform to its real deployment environment. Clause 6 matters because the selected platform category depends on the integrating product, the environment, and the user model.

The document distinguishes trusted and untrusted logical environments, and trusted and untrusted physical environments. In practice, untrusted environments drive stronger requirements, and platforms in the PTF-MTR category are required where physical users can be attackers or attack vectors.

Clause 6.1 also defines platform categories: PTF-COR, PTF-MTR, PTF-ADV, and PTF-SER. This matters because buyers and integrators can match the chip’s security capabilities to the device use case - for example baseline platform protection, tamper-resistance, advanced isolation or availability support, or security services such as secure storage and secure communications.

The user categories also matter: trusted intermediate users, trusted end-users, untrusted end-users, and attackers. In practice, the platform category and the user category have to match the integrating product’s risk assessment.

What does the vulnerability handling process require?

oSIST prEN 50766:2026 requires a platform vulnerability handling process in clause 7 that complies with prEN 40000-1-3:2025. That is important because security maintenance is treated as part of the platform’s lifecycle, not a one-time design task.

Clause 7 is mandatory, and the assessment is passed when the assessment verdict for all requirements in prEN 40000-1-3:2025 is PASS. In practice, suppliers need a documented process for handling vulnerabilities and for linking that process to the platform’s security claims.

What are the main technical requirements?

oSIST prEN 50766:2026 groups the core platform requirements in clause 8. The most important ones are:

• TR_IMP - Implementation best practices: the platform implementation must reflect secure design and coding best practices. In practice, developers need to show that the implementation follows secure engineering principles, not just that it works.
• TR_EXP - No known exploitable vulnerabilities: the platform must not contain known exploitable vulnerabilities that are not excluded by vulnerability risk assessment or addressed by user guidance. In practice, known issues must be removed, justified, or mitigated before the platform is integrated.
• TR_CFG - Secure configuration of platform: the platform must be released in a secure configuration that protects platform assets. In practice, the default state and deployment settings matter, especially before market release.
• TR_PID, TR_PAU, TR_INI, TR_SUP, TR_SUD, and TR_ERA: these cover identification, authentication, secure initialisation, secure update of the platform, secure update of dependent components, and secure erasure of data. In practice, the platform must support controlled startup, updates, and data removal.
• TR_ISO, TR_ACC, TR_STO, and TR_COM: these cover isolation mechanisms, access control to security functionalities, secure storage, and secure communications. In practice, the platform has to protect assets both inside the chip and across its interfaces.
• TR_CRY, TR_REP, and TR_AVS: these cover secure cryptographic features, reporting of security events, and advanced availability support of basic and essential functions. In practice, the platform has to protect secrets, report relevant events, and keep essential functions available where required.
• SRD_RST, TR_RES, and TR_SEG: these cover reset to initial state, tamper-resistance, and application of platform security guidance. In practice, the chip must be able to recover, resist attacks, and be integrated according to the supplied guidance.

Clause 8 also makes clear that some requirements depend on risk assessment, platform category, or environment, and that operation guidance can be necessary for the security of the platform or the larger device.

What terms does oSIST prEN 50766:2026 define?

oSIST prEN 50766:2026 defines the terms it uses so that platform selection, assessment, and integration are interpreted consistently.

• Platform - a tangible element, at minimum a microprocessor or microcontroller, that implements security functionalities; in practice, this is the security base that the rest of the device depends on.
• Dependent component - a software or hardware component that uses a platform function without providing functions to the platform; in practice, this is the application or module the platform serves.
• Tamper-resistance - a security property intended to prevent successful exploitation of vulnerabilities by logical or physical attacks; in practice, it describes resistance to attack rather than just detection.
• Security functionality - a function provided by the platform to protect assets, such as secure storage or cryptographic operations; in practice, this is what the integrator relies on.
• Potential incident (PI) - a specific event that can occur when a threat exploits a vulnerability; in practice, it is the harm scenario used in the security analysis.
• Update package - a bundle containing platform firmware and/or software code and/or data, possibly with metadata; in practice, this is what secure update mechanisms control.
• Technical requirement (TR) - one of the platform requirements defined in clause 8; in practice, it is a security feature or control that has to be implemented and assessed.

Who uses oSIST prEN 50766:2026?

oSIST prEN 50766:2026 is used by semiconductor vendors, microprocessor and microcontroller designers, device manufacturers, product integrators, security engineers, quality managers, and evaluation teams. It is also relevant to buyers who need to compare platform security capabilities before selecting components.

The document fits products in consumer and industrial devices, IoT edge devices, sensors, actuators, low-cost automation, smartphones, tablets, networking and connectivity solutions, computers, high-performance embedded systems, robotics, ECUs, medical instruments, and medical imaging devices. In practice, it helps teams decide which platform category to integrate, how to configure it, and what evidence to collect for security assessment.

Which standards are used with oSIST prEN 50766:2026?

oSIST prEN 50766:2026 is built to be used with prEN 40000-1-1:2025 for vocabulary and prEN 40000-1-3:2025 for vulnerability handling. Those references set the common language and the lifecycle process that this document depends on.

The bibliography also names prEN 40000-1-2:2025 for principles for cyber resilience, EN 17927:2023 for SESIP methodology, EN ISO/IEC 15408-2:2023 and EN ISO/IEC 15408-3:2023 for security functional and assurance components, and EN 17640:2022 for fixed-time cybersecurity evaluation methodology. In practice, these documents support assessment planning, evidence gathering, and the reuse of evaluation results.

What does the oSIST prEN 50766:2026 document contain?

oSIST prEN 50766:2026 contains the detailed structure needed to assess a tamper-resistant platform as a security component. Clause 5 explains the assessment logic, including input verification, functional testing, resistance testing, verdicts, and evidence such as reports, logs, configuration files, and captures.

Annex A provides the security-analysis framework: assets, incidents, threats, security policies, assumptions, security objectives, and risk environments. Annex C explains how European security evaluation methodologies can support the assessment activities, including the analysis of specific technical requirements.

The document also includes correspondence material in Annex ZZ showing how its clauses relate to Regulation (EU) 2024/2847. For a reader, that means the standard is not just a list of requirements - it also gives the analysis model, the assessment approach, and the regulatory mapping needed for real product work.

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
...