prEN 40004-3:2026

• Abstract:

  This document specifies the technical requirements for general-purpose Application Specific Integrated Circuits (ASICs) and Field Programmable Gate Arrays (FPGAs) with security features, related to cybersecurity. The products with digital elements in scope, thereafter "platforms": — are specified within the "technical description" of the "category of product" number "NN" by the Commission Implementing Regulation (EU) 2025/2392 [16] as: • “Application specific integrated circuits (ASIC) with security-related functionalities are products with digital elements that are integrated circuits, fully or partially custom-designed to perform a specific function or implement a specific application, and which additionally provide security-related functionalities that aim to secure other products, networks or services beyond the ASIC itself, such as trusted execution environments or secure communication interfaces.” • “Field-programmable gate arrays (FPGA) with security-related functionalities are products with digital elements that are integrated circuits characterized by a matrix of configurable logic blocks designed to be reprogrammable after manufacturing to perform a specific function or implement a specific application, and which additionally provide security-related functionalities that aim to secure other products, networks or services beyond the FPGA itself, such as trusted execution environments or secure communication interfaces.” — are only covered within the product context described in Clause 4. The present document covers those products to demonstrate compliance with essential cybersecurity requirements in the Regulation (EU) 2024/2847 [16] Annex I Part I under the conditions identified in Annex ZZ. ASICs and FPGAs additionally provide security-related functionalities, such as encryption, authentication, secure key storage, random number generation, trusted execution environment, or other hardware- based protection mechanisms, that aim to secure other products, networks or services beyond the ASIC or FPGA itself, such as secure boot chain, virtualization or secure communication interfaces Such ASICs and FPGAs are intended to be integrated in a larger system, complemented by application software, and optionally by additional hardware components by integrators to build a device corresponding to a given intent of use. The intent of use of the platform integrated into a device is likely be known to the manufacturer of the ASIC with security-related functionalities, while the intent of use of the platform integrated into a device may not be known to the manufacturer of the FPGA with security-related functionalities. The ASICs and FPGAs 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/medium attack potential.

• Status: Not Published
• Publication Date: 21-Nov-2027
• ICS: 31.200 - Integrated circuits. Microelectronics
• ICS: 35.030 - IT Security
• Technical Committee: CLC/TC 47X - Semiconductor devices and trusted chips
• Drafting Committee: WG 04 - ASIC and FPGA with security-related functionalities
• Current Stage: 4020 - Enquiry circulated - Enquiry
• Start Date: 25-Sep-2026
• Due Date: 17-Jul-2026
• Completion Date: 25-Sep-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
• Ref Project: oSIST prEN 40004-3:2026 - Cybersecurity requirements for Field Programmable Gate Arrays and Application Specific Integrated Circuits with security-related functionalities

prEN 40004-3:2026 is a CENELEC draft European Standard on cybersecurity requirements for Field Programmable Gate Arrays (FPGAs) and Application Specific Integrated Circuits (ASICs) with security-related functionalities. It specifies technical requirements and compliance assessment criteria for these platforms when they are used to secure other products, networks or services, and it is aimed at manufacturers, integrators, assessors and buyers working under the EU Cyber Resilience Act.

What does prEN 40004-3:2026 specify?

prEN 40004-3:2026 specifies cybersecurity requirements for general-purpose ASICs and FPGAs with security features, but only within the product context described in Clause 4. The standard links those platforms to compliance with the essential cybersecurity requirements of Regulation (EU) 2024/2847, under the conditions set out in Annex ZZ.

The document is organized into six clauses and five annexes. Clause 4 sets the product context and use cases, Clause 5 gives the technical requirements, and Clause 6 gives the assessment criteria and compliance verification procedures.

Annex	What it covers
Annex A	Security analysis, including assets, threats and threat coverage
Annex B	Platform requirements and implementation options
Annex C	Support for European security evaluation methodologies
Annex K	Cryptographic algorithms, crypto agility and related assessment criteria
Annex ZZ	Relationship with the essential cybersecurity requirements of Regulation (EU) 2024/2847

Clause 4 describes the operational environment, user roles and deployment use cases that determine which requirements apply. That matters in practice because the standard is risk-based: a manufacturer does not apply every requirement to every platform, but selects the relevant set from the intended use and threat context.

What are the key requirements of prEN 40004-3:2026?

prEN 40004-3:2026 is built around a risk-based selection of technical requirements, followed by evidence-based assessment. In practice, a manufacturer first defines the use case and environment, then implements the applicable security functions, and finally demonstrates compliance through the Clause 6 assessment process.

1. Clause 4 defines the product context before any technical requirement applies

prEN 40004-3:2026 uses Clause 4 to classify the platform, the device it supports, and the environment in which it operates. It distinguishes trusted and untrusted logical environments, trusted and untrusted physical environments, and low-risk and medium-risk contexts.

That matters because the same FPGA or ASIC can be used in very different devices. The environment classification drives the threat analysis and decides whether requirements such as isolation, secure update, secure storage or tamper-resistance are relevant.

2. Clause 4.6 groups the common use cases

prEN 40004-3:2026 defines use cases for authenticated, verified-component, cleaned, multi-security-domain, multi-application, access-controlled, storage, exchanging, crypto-anchor, monitoring, availability-critical and restorable environments. These use cases are the bridge between the product context and the technical requirements in Clause 5.

For a reader, this means the standard is not just a list of controls. It gives a way to match a platform to the security role it is expected to play inside a larger device.

3. Clause 5.2 sets baseline implementation expectations

prEN 40004-3:2026 starts Clause 5 with requirements on implementation best practices, absence of known exploitable vulnerabilities, and secure configuration of the platform. These are the foundation for all later functional requirements.

In practice, this means the platform is expected to be designed and configured so that its security features are not undermined by weak implementation choices or by a poor default setup.

4. Clause 5.3 covers the main platform security functions

prEN 40004-3:2026 requires a platform, where applicable, to support functions such as identification, authentication, secure initialisation, secure update, secure handling of dependent components, secure erasure, isolation, access control, secure storage, secure communications, secure cryptographic features, reporting of security events, advanced availability support, reset to initial state and tamper-resistance.

These are the functions that a manufacturer, integrator or evaluator will usually need to trace from threat to mechanism to evidence. They matter because the standard is focused on the platform as a security-enabling component, not only on general product hygiene.

5. Annex K controls which cryptographic mechanisms can be used

prEN 40004-3:2026 includes a normative Annex K for cryptographic algorithms and related mechanisms. Annex K covers cryptography, crypto agility, ACM-extended cryptographic mechanisms and interoperability-based cryptographic mechanisms, each with its own requirement and assessment route.

This is important in practice because the standard does not leave cryptography open-ended. If a platform uses cryptographic functions, those functions must fit the listed mechanisms and conditions for the intended platform function or external specification.

6. Clause 6 turns the requirements into an assessment process

prEN 40004-3:2026 defines assessment objectives, preparation, activities, verdicts and evidence in Clause 6, then gives separate assessment subclauses for each technical requirement in Clause 5. That makes the document usable for verification, audit and certification work, not only for design.

For a team preparing a declaration or review, Clause 6 is where the implementation is checked against the selected requirement set. It tells the assessor what evidence to collect and how to judge compliance.

7. Annex ZZ maps the standard to the Cyber Resilience Act

prEN 40004-3:2026 includes Annex ZZ to show how its clauses correspond to the essential cybersecurity requirements of Regulation (EU) 2024/2847 Annex I Part I. Where the standard is cited in the Official Journal of the European Union, that mapping supports presumption of conformity within the scope of the document.

For a buyer or compliance manager, this is the practical legal link. It shows which clauses are meant to support which regulatory expectations.

What terms does prEN 40004-3:2026 define?

prEN 40004-3:2026 defines the vocabulary used to describe the platform, the device around it and the security functions it provides. The most useful terms for readers are:

• Access control - a mechanism that grants permission to a subject on an object.
• Dependent component - software or hardware that uses a functionality of a platform.
• Device - a composition of one or more platforms and dependent components.
• Platform - an FPGA or ASIC, optionally with firmware, software and/or a remote data processing solution.
• Platform code - code that is part of the implementation of the platform functionality, including the platform aspects of the FPGA bitstream.
• Platform data - data handled by the platform, including user data, user code and platform manufacturer data.
• Security functionality - functionality provided by the platform to dependent components for protecting assets.
• Tamper-resistance - a security property intended to prevent successful exploitation of vulnerabilities by logical and/or physical attacks.

Who uses prEN 40004-3:2026?

prEN 40004-3:2026 is used by semiconductor manufacturers, platform designers, device integrators, cybersecurity assessors and compliance teams. It is also useful for buyers who need to specify secure ASICs or FPGAs for a device design.

Manufacturers use it to define the product context, select the applicable use case and implement the required security functions. Integrators use it to decide whether a platform fits the intended device environment, and assessors use Clause 6 and the annexes to verify compliance evidence.

Which standards are used with prEN 40004-3:2026?

prEN 40004-3:2026 names one normative reference and several related standards that support risk management, evaluation and domain-specific assurance.

• FprEN 40000-1-1:2026 - provides the base vocabulary used by Clause 3.
• prEN 40000-1-2:2025 - covers principles, product risk management and lifecycle activities.
• prEN 40000-1-3:2025 - covers vulnerability handling.
• prEN 40003-3:2026 - covers cybersecurity requirements for platforms of smartcards and similar devices including secure elements.
• EN 17927:2023, EN ISO/IEC 15408-2:2026, EN ISO/IEC 15408-3:2026, EN 17640:2022 and EN ISO/IEC 18045:2026 - appear in the bibliography and support the evaluation and assessment approach, which Annex C maps to external methodologies.
• ISO/SAE 21434:2021 and EN IEC 62443-4-1:2018 - are listed as related sector standards for automotive and industrial secure development lifecycles.

What does the prEN 40004-3:2026 document contain?

prEN 40004-3:2026 contains the product context in Clause 4, including product functions, architecture, operational environment, distribution of security functions, users and use cases. It then provides the technical cybersecurity requirements in Clause 5, with named requirements for implementation and platform functions.

Clause 6 contains the assessment criteria and compliance verification procedures, including the evidence expected for each requirement. Annex A provides the threat-analysis method, Annex B gives implementation options, Annex C maps the standard to external evaluation methodologies, Annex K lists and constrains cryptographic mechanisms, and Annex ZZ maps the clauses to the Cyber Resilience Act.

SLOVENSKI STANDARD
01-november-2026
Zahteve za kibernetsko varnost za programirljiva logična vezja in integrirana vezja
za določen namen z varnostno relevantnimi funkcijami
Cybersecurity requirements for Field Programmable Gate Arrays and Application
Specific Integrated Circuits with security-related functionalities
Technische Sicherheitsstandards für anwendungsspezifische integrierte Schaltkreise
(ASICs) und feldprogrammierbare Gate-Arrays (FPGAs) mit sicherheitsrelevanten
Funktionalitäten
Normes techniques de sécurité pour les circuits intégrés spécifiques à une application
(ASIC) et les circuits logiques programmables (FPGA) incluant des fonctionnalités de
sécurité de données
Ta slovenski standard je istoveten z: prEN 40004-3:2026
ICS:
31.200 Integrirana vezja, Integrated circuits.
mikroelektronika Microelectronics
35.030 Informacijska varnost IT Security
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD DRAFT
prEN 40004-3
NORME EUROPÉENNE
EUROPÄISCHE NORM
September 2026
ICS 31.200; 35.030 -
English Version
Cybersecurity requirements for Field Programmable Gate Arrays
and Application Specific Integrated Circuits with security-related
functionalities
Normes techniques de sécurité pour les circuits intégrés Technische Sicherheitsstandards für
spécifiques à une application (ASIC) et les circuits logiques anwendungsspezifische integrierte Schaltkreise (ASICs)
programmables (FPGA) incluant des fonctionnalités de und feldprogrammierbare Gate-Arrays (FPGAs) mit
sécurité de données sicherheitsrelevanten Funktionalitäten
This draft European Standard is submitted to CENELEC members for enquiry.
Deadline for CENELEC: 2026-11-20.

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: 82281 Ref. No. prEN 40004-3:2026 E

Contents Page
11 European foreword . 5
12 Introduction . 6
13 1 Scope . 8
14 2 Normative references . 8
15 3 Terms and definitions . 8
16 4 Product context .11
17 4.1 Product functions .11
18 4.2 Product architecture .12
19 4.3 Operational environment .12
20 4.3.1 General .12
21 4.3.2 Adversary environment types .12
22 4.3.3 Device environment components .13
23 4.4 Distribution of security functions .14
24 4.5 Users .15
25 4.6 Use cases .15
26 5 Technical requirements for products .22
27 5.1 General .22
28 5.1.1 General .22
29 5.1.2 Requirement .22
30 5.1.3 Applicability.22
31 5.2 Technical requirements related to platform implementation .23
32 5.2.1 TR-IMP Implementation best practices .23
33 5.2.2 TR-EXP No known exploitable vulnerabilities .23
34 5.2.3 TR_CFG Secure configuration of platform .24
35 5.3 Technical requirements related to platform functionalities .25
36 5.3.1 TR-PID Identification of platform .25
37 5.3.2 TR-PAU Authentication of platform .25
38 5.3.3 TR-INI Secure initialisation support .27
39 5.3.4 TR-SUP Secure update of platform .27
40 5.3.5 TR-HDC Secure handling of dependent components .29
41 5.3.6 TR-ERA Secure erasure of data .29
42 5.3.7 TR-ISO Isolation mechanisms .30
43 5.3.8 TR-ACC Access control to security functionalities .31
44 5.3.9 TR-STO Secure storage .32
45 5.3.10 TR-COM Secure communications .34
46 5.3.11 TR-CRY Secure cryptographic features .36
47 5.3.12 TR-REP Reporting of security events .36
48 5.3.13 TR-AVS Advanced availability support of basic and essential functions .37
49 5.3.14 TR-RST Reset of platform to initial state .38
50 5.3.15 TR-RES Tamper-resistance of platform .39
51 6 Assessment criteria for compliance with technical requirements .41
52 6.1 Introduction to the assessment and compliance criteria .41
53 6.1.1 General .41
54 6.1.2 Assessment objective .41
55 6.1.3 Assessment preparation .41
56 6.1.4 Assessment activities .42
57 6.1.5 Assessment verdict .42
58 6.1.6 Assessment evidence .43
59 6.2 Technical requirements assessment .43
60 6.2.1 Assessment of TR-IMP .43
61 6.2.2 Assessment of TR-EXP .43
62 6.2.3 Assessment of TR-CFG .45
63 6.2.4 Assessment of TR-PID .46
64 6.2.5 Assessment of TR-PAU . 47
65 6.2.6 Assessment of TR-INI . 48
66 6.2.7 Assessment of TR-SUP. 49
67 6.2.8 Assessment of TR-HDC . 51
68 6.2.9 Assessment of TR-ERA . 52
69 6.2.10 Assessment of TR-ISO . 53
70 6.2.11 Assessment of TR-ACC . 54
71 6.2.12 Assessment of TR-STO. 55
72 6.2.13 Assessment of TR-COM. 57
73 6.2.14 Assessment of TR-CRY . 59
74 6.2.15 Assessment of TR-REP. 59
75 6.2.16 Assessment of TR-AVS. 61
76 6.2.17 Assessment of TR-RST . 61
77 6.2.18 Assessment of TR-RES. 62
78 Annex A (informative) Security analysis . 70
79 A.1 General . 70
80 A.2 Assets . 70
81 A.3 Threats . 71
82 A.3.1 General . 71
83 A.3.2 T_UDD Unauthorized disclosure of platform data . 71
84 A.3.3 T_UMD Unauthorized modification of platform data . 71
85 A.3.4 T_URD Unauthorized replacement of platform data . 71
86 A.3.5 T_UAD Unauthorized addition of platform data . 71
87 A.3.6 T_UED Unauthorized erasure of platform data . 71
88 A.3.7 T_UMC Unauthorized modification of platform code . 71
89 A.3.8 T_URC Unauthorized replacement of platform code . 71
90 A.3.9 T_UAC Unauthorized addition of platform code . 71
91 A.3.10 T_UEC Unauthorized erasure of platform code . 72
92 A.3.11 T_CCF Compromise of a cryptographic security functionality . 72
93 A.3.12 T_UAF Unauthorized access to the security functionalities of the platform . 72
94 A.3.13 T_DBF Disruption of essential and basic functions of the platform . 72
95 A.3.14 T_PER Impersonation of the platform . 72
96 A.4 Assets coverage . 72
97 A.5 Threats coverage . 73
98 Annex B (informative) Platform requirements and implementation options . 76
99 Annex C (informative) Support of European security evaluation methodologies . 79
100 C.1 General . 79
101 C.2 Mapping to external assessment methodologies . 79
102 C.3 Mapping of external security profiles . 83
103 Annex K (normative) Cryptographic algorithms . 88
104 K.1 General . 88
105 K.2 Cryptography . 88
106 K.2.1 Requirement . 88
107 K.2.2 Assessment of platform cryptographic mechanisms . 91
108 K.3 Crypto agility .95
109 K.3.1 Requirement .95
110 K.3.2 Assessment of crypto-agility.96
111 K.4 ACM-extended cryptographic mechanisms .97
112 K.4.1 Requirement .97
113 K.4.2 List of ACM-extended cryptographic mechanisms .97
114 K.4.3 Assessment .138
115 K.5 Interoperability-based cryptographic mechanisms .138
116 K.5.1 Requirement .138
117 K.5.2 List of interoperability-based cryptographic mechanisms .138
118 K.5.3 Assessment .153
119 Annex ZZ (informative) Relationship between this European Standard and the essential
120 cybersecurity requirements of Regulation (EU) 2024/2847 of the European Parliament and
121 of the Council of 23 October 2024 on horizontal cybersecurity requirements for products
122 with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and
123 Directive (EU) 2020/1828 (Cyber Resilience Act) aimed to be covered .154
124 Bibliography .157
126 European foreword
127 This document (prEN 40004-3:2026) has been prepared by CLC TC47X “semiconductors and trusted chips
128 implementation”.
129 This document is currently submitted to the Enquiry
130 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)
131 This document has been prepared under a standardization request addressed to CENELEC by the European
132 Commission. The Standing Committee of the EFTA States subsequently approves these requests for its
133 Member States.
134 For the relationship with EU Legislation, see informative Annex ZZ, which is an integral part of this document.
135 Introduction
136 This standard specifies the technical requirements to be fulfilled by Field Programmable Gate Arrays and
137 Application Specific Integrated Circuits with security-related functionalities, as defined in the Regulation (EU)
138 2025/2392 [21], to cover the Essential Cybersecurity Requirements set out in Annex I of the Regulation
139 2024/2847 (Cyber Resilience Act), and defines how compliance with those requirements is to be demonstrated.
140 Clause 4 does not contain technical requirements; it describes the product context that is considered for the
141 application of this standard. Clause 4 also defines use cases that represent the main deployment scenarios
142 reflecting the intended purpose and reasonably foreseeable use of the product, which serve as the basis for
143 identifying relevant cybersecurity risks.
144 Clause 5 specifies technical cybersecurity requirements for the product to mitigate the identified risks, including
145 their applicability conditions.
146 Clause 6 specifies the assessment criteria and compliance verification procedures with the requirements of
147 Clause 5.
148 Annex A informs about the methodology used to assess the security risks of the products in their context.
149 Annex B provides a synthetic mapping of the technical requirements with appropriate implementation options.
150 Annex C provides an analysis of the coverage of technical requirements evaluation by external methodologies.
151 Annex K supports the definition of the cryptographic requirements and assessment criteria used by the present
152 document.
153 Annex ZZ maps the technical requirements of the present document with the essential requirements of the
154 Regulation 2024/2847 Annex I Part I.
155 For each technical requirement, this standard specifies a set of valid implementation options and the
156 assessment activities to be performed in order to demonstrate compliance with those requirements.
157 The applicability of the technical requirements depends on the risks associated with the intended use of the
158 Field Programmable Gate Arrays and Application Specific Integrated Circuits with security-related
159 functionalities. This standard defines use cases and associates each of them with a corresponding set of
160 applicable technical requirements, as determined through threat analysis.
161 The use case of a Field Programmable Gate Arrays and Application Specific Integrated Circuits with security-
162 related functionalities is determined consistently with the cybersecurity risk assessment performed by the
163 manufacturer, as required under Article 13 of the Cyber Resilience Act.
164 This standard is defined at a level of granularity that is generic across different Field Programmable Gate Arrays
165 and Application Specific Integrated Circuits with security-related functionalities. Consequently, for a specific
166 product, the manufacturer’s risk assessment can conclude that certain technical requirements associated with
167 a given use case are not applicable without affecting the compliance of the platform with this standard. This
168 standard provides guidance on common technical reasons for such non-applicability; however, the
169 determination and justification of exclusions fall outside the scope of this standard and remain under the
170 manufacturer’s risk assessment obligation.
171 Platforms commonly include mechanisms beyond those necessary to fulfil technical requirements. Even if such
172 mechanisms are listed in this document as potential implementation options (e.g. storage, communication,
173 availability), those fall outside the scope of this document as they do not actively mitigate identified threats.
174 A platform can be deployed in environments exposing it to threats beyond those addressed by its defined use
175 case, thereby implying a redefinition of the use case of the integrating product, provided that any additional
176 required protections are implemented by the platform user. All such considerations are however outside the
177 scope of this standard.
178 In summary, the application of this standard by Field Programmable Gate Arrays and Application Specific
179 Integrated Circuits with security-related functionalities manufacturers follows the steps below:
180 — identification of the use case from Clause 4.6, based on the manufacturer’s risk assessment;
181 — identification of the associated technical requirements from Table 1 and Table 2 of Clause 4.6;
182 — identification the final set of technical requirements to be implemented, taking into account the identified
183 use case and any justified exclusions resulting from the manufacturer’s specific risk assessment;
184 — implementation of the identified technical requirements in accordance with the implementation options
185 specified in Clause 5.
186 — assessment of the platform implementation of each technical requirement in accordance in accordance
187 with Clause 6.
188 Users of Field Programmable Gate Arrays and Application Specific Integrated Circuits with security-related
189 functionalities can use this standard to identify the use case corresponding to their own intended use and select
190 the appropriate Field Programmable Gate Arrays or Application Specific Integrated Circuits.
191 1 Scope
192 This document specifies the technical requirements for general-purpose Application Specific Integrated Circuits
193 (ASICs) and Field Programmable Gate Arrays (FPGAs) with security features, related to cybersecurity. The
194 products with digital elements in scope, thereafter “platforms”:
195 — are specified within the “technical description” of the “category of product” number “NN” by the Commission
196 Implementing Regulation (EU) 2025/2392 [16] as:
197 • “Application specific integrated circuits (ASIC) with security-related functionalities are products with
198 digital elements that are integrated circuits, fully or partially custom-designed to perform a specific
199 function or implement a specific application, and which additionally provide security-related
200 functionalities that aim to secure other products, networks or services beyond the ASIC itself, such as
201 trusted execution environments or secure communication interfaces.”
202 • “Field-programmable gate arrays (FPGA) with security-related functionalities are products with digital
203 elements that are integrated circuits characterized by a matrix of configurable logic blocks designed to
204 be reprogrammable after manufacturing to perform a specific function or implement a specific
205 application, and which additionally provide security-related functionalities that aim to secure other
206 products, networks or services beyond the FPGA itself, such as trusted execution environments or
207 secure communication interfaces.”
208 — are only covered within the product context described in Clause 4.
209 The present document covers those products to demonstrate compliance with essential cybersecurity
210 requirements in the Regulation (EU) 2024/2847 [16] Annex I Part I under the conditions identified in Annex ZZ.
211 ASICs and FPGAs additionally provide security-related functionalities, such as encryption, authentication,
212 secure key storage, random number generation, trusted execution environment, or other hardware- based
213 protection mechanisms, that aim to secure other products, networks or services beyond the ASIC or FPGA
214 itself, such as secure boot chain, virtualization or secure communication interfaces
215 Such ASICs and FPGAs are intended to be integrated in a larger system, complemented by application
216 software, and optionally by additional hardware components by integrators to build a device corresponding to a
217 given intent of use. The intent of use of the platform integrated into a device is likely be known to the
218 manufacturer of the ASIC with security-related functionalities, while the intent of use of the platform integrated
219 into a device might not be known to the manufacturer of the FPGA with security-related functionalities.
220 The ASICs and FPGAs in scope are designed for deployment in environments where the security features of
221 the product integrating the platform are of importance, and where the threat landscape includes attackers with
222 low/medium attack potential.
223 2 Normative references
224 The following documents are referred to in the text in such a way that some or all of their content constitutes
225 requirements of this document. For dated references, only the edition cited applies. For undated references, the
226 latest edition of the referenced document (including any amendments) applies.
227 FprEN 40000-1-1:2026, Cybersecurity requirements for products with digital elements - Vocabulary
228 3 Terms and definitions
229 For the purposes of this document, the terms and definitions given in, FprEN 40000-1-1:2026 and the following
230 apply.
231 ISO and IEC maintain terminology databases for use in standardization at the following addresses:
232 — ISO Online browsing platform: available at https://www.iso.org/obp/
233 — IEC Electropedia: available at https://www.electropedia.org/
234 3.1
235 access control
236 mechanism granting permission to a subject on an object
237 3.2
238 application
239 dependent component that provides a direct service to the end-user
240 3.3
241 asset
242 data, code or function that needs protection to prevent loss or disruption caused by a potential incident
243 3.4
244 best practices for cryptography
245 measures based on cryptographic techniques that have been shown to provide appropriate security for the
246 corresponding use case
247 3.5
248 cryptographic mechanism
249 security-related procedure using cryptography
250 Note 1 to entry: The term “cryptographic mechanism” is used in this annex as an umbrella term covering the categories
251 used in the ECCG Agreed Cryptographic Mechanisms v2.0 catalogue, including cryptographic algorithms, primitives,
252 schemes, protocols, protocol profiles, cipher suites, modes of operation, constructions and parameter sets.
253 Note 2 to entry: The terms “cryptographic primitive”, “cryptographic construction”, “cryptographic scheme” and
254 “cryptographic protocol” are used consistently with the ECCG Agreed Cryptographic Mechanisms v2.0 catalogue.
255 Note 3 to entry: A cryptographic mechanism can be specified at different levels of abstraction. For example, AES is a
256 cryptographic primitive, AES-GCM is a mode of operation / authenticated encryption construction, TLS 1.3 is a protocol, a
257 TLS 1.3 restricted cipher-suite profile is a protocol profile, and TLS_AES_128_GCM_SHA256 is a cipher suite.
258 3.6
259 cryptographic property
260 property provided or supported by a cryptographic mechanism
261 Note 1 to entry: Cryptographic properties include, for example, confidentiality, integrity, authenticity, entity authentication,
262 message authentication, key establishment, key confirmation, replay protection, collision resistance, second-preimage
263 resistance, pre-image resistance, signature unforgeability, non-repudiation, forward secrecy and password-verifier
264 protection. Where relevant, a cryptographic property can be expressed using a formal cryptographic notion, for example
265 IND-CPA, IND-CCA, IND-CCA2, EUF-CMA, SUF-CMA or authenticated key exchange security.
266 Note 2 to entry: A cryptographic property is distinct from a product-level technical requirement, although it can support
267 such a requirement. For example, a secure communication requirement can rely on cryptographic properties such as
268 confidentiality, integrity and authentication.
269 3.7
270 dependent component
271 software or hardware component using a functionality of a platform
272 EXAMPLE The dependent component can also refer to the integrator’s design (configuration/programming bitstream)
273 mapped into the configurable hardware (FPGA logic).
274 3.8
275 device
276 composition of platform(s) and dependent component(s)
277 Note 1 to entry: When a platform is under assessment following this standard, other platforms and dependent components
278 are out of scope.
279 3.9
280 end-user
281 user of the device
282 3.10
283 external entity
284 entity in interaction with the platform
285 EXAMPLE Application, other dependent components or devices in physical or logical interaction with the platform.
286 3.11
287 firmware
288 set of executable instructions which are optionally provided as a part of the platform and which can be immutable
289 and/or mutable
290 3.12
291 isolation mechanism
292 security mechanism regulating the accesses to assets between the different parts in a system separated in
293 parts
294 3.13
295 logical attack
296 attack requiring only logical vector to disturb the platform
297 3.14
298 physical attack
299 attack requiring the close presence of the attacker to the platform
300 3.15
301 platform
302 FPGA or ASIC optionally with firmware, and/or any type of software, and/or remote data processing solution
303 Note 1 to entry: Platforms may be application-specific (ASICs) or generic devices (FPGAs).
304 Note 2 to entry: Software does not include user software.
305 3.16
306 platform code
307 code that is part of the implementation of the platform functionality
308 Note 1 to entry: Platform code also includes the platform aspects of the bitstream for FPGAs
309 3.17
310 platform data
311 data handled by the platform i.e. user data, user code and platform manufacturer data
312 3.18
313 platform manufacturer data
314 data owned by the platform manufacturer handled by the platform
315 3.19
316 potential incident
317 specific event that could occur due to a threat exploiting a vulnerability
318 3.20
319 security functionality
320 functionality provided by the platform to the dependent components for the protection of assets
321 EXAMPLE Secure storage, cryptographic operations.
322 3.21
323 tamper-evidence
324 security property of a platform intended to ensure the detection of logical and/or physical attacks leading to
325 achievement of threats identified in the risk assessment
326 3.22
327 tamper-resistance
328 security property of a platform intended to prevent the successful exploitation of vulnerabilities by logical and/or
329 physical attacks leading to realization of threats identified in the risk assessment
330 3.23
331 tamper-response
332 security property of a platform intended to provide the ability to react to the detection of logical and/or physical
333 attacks leading to realization of threats identified in the risk assessment
334 3.24
335 update package
336 bundle containing platform bitstream and/or firmware and/or software code and/or data, potentially associated
337 with metadata
338 3.25
339 user
340 platform user
341 entity that will make use of the platform (including software component, intermediate user and end-user)
342 3.26
343 user code
344 code implementing the (software) dependent component executed on the platform
345 3.27
346 user data
347 data owned by (or associated to) the user handled by the platform
348 4 Product context
349 4.1 Product functions
350 In this document, products refer to platforms as defined in Clause 3 that are intended to be combined with other
351 components, software and/or hardware, to form a complete device. Their essential function is to provide generic
352 security functionalities to these associated components, referred to as dependent components, by means of
353 their own hardware, optionally augmented by firmware and/or software. These platforms are intended to be
354 used across a wide range of industries and applications, able to support multiple end functions.
355 ASICs and FPGAs are intended to be integrated in a larger system, complemented by application software, and
356 initialization information optionally by additional hardware components by integrators to build a device
357 corresponding to a given intent of use. The intent of use of the platform integrated into a device is likely be
358 known to the manufacturer of the ASIC with security-related functionalities, while the intent of use of the platform
359 integrated into a device may not be known to the manufacturer of the FPGA with security-related functionalities.
360 Additionally, the platforms covered in this document range from those offering limited security capabilities
361 suitable for integration into devices that operate in environments where the threat landscape includes attackers
362 with a low, negligible attack potential through to those platforms offering protection against attacks with a
363 medium attack potential, whether through remote-only or physical access to the device.
364 4.2 Product architecture
365 Platforms in scope are composed of hardware, optionally augmented by firmware and/or any type of software.
366 The platform can also optionally rely on a remote data processing solution involving a communication channel
367 between the core of the platform and its remote part. All such platform components, including any remote part
368 and the connecting communication link, are affected by the threats outlined in 4.4; they consequently need to
369 implement the associated technical requirements.
370 Such platforms implement security functionalities that can be invoked by dependent component(s), which are
371 outside of the scope of this standard. These security functionalities at minimum mitigate the risks associated
372 with to the platform use case (see 4.6).
373 Additional security implementation that do not comply with the requirements of this standard may also be
374 included, provided that they do not compromise the compliance of the security functionalities subject to this
375 standard.
376 EXAMPLE A given functionality is supported by multiple cryptographic algorithms, including one(s) that comply with
377 this standard and others that do not, (because they are not intended for the European market).
378 4.3 Operational environment
379 4.3.1 General
380 Platforms operate within varying operational environments which influence the risks to be countered. These
381 environments can be categorized into two main types:
382 — Adversary environment, which refers to the external conditions and capabilities that shape the exposure of
383 the platform itself to attacks and, consequently, determines the security features required for its self-
384 protection.
385 — Device environment, which refers to the device assets and security functionalities and, consequently,
386 determines the platform security features required to ensure or support the device own security.
387 The environment categories to be selected depend on the integrating product use case and its corresponding
388 risk assessment.
389 4.3.2 Adversary environment types
390 4.3.2.1 Logical environment
391 The logical environment refers to software and hardware components outside the platform that can interact with
392 it either directly through exposed interfaces, or indirectly via shared resources such as memory or buses. It is
393 consequently capable of affecting the logical behaviour of the platform.
394 The logical environment of the platform falls into one of the two categories:
395 — Trusted logical environment (ENV-TRL): environment where the interacting components are not expected
396 to intentionally compromise the platform (USR-TRC as defined in 4.5), or where no such components are
397 present. In these environments, only attacks through the device external interfaces are applicable,
398 excluding attacks from other components of the device.
399 EXAMPLE 1 Devices with single trusted application with no software loader.
400 — Untrusted logical environment (ENV-NTL): environment where the interacting components are considered
401 potential vectors that could be compromised (USR-NTC as defined in 4.5). In these environments, isolation
402 of the platform from external component is required to mitigate attacks applicable in the risk context defined
403 in 4.3.2.3.
404 EXAMPLE 2 Open devices (loadable untrusted code), multi-application.
405 4.3.2.2 Physical environment
406 The physical environment refers to users who have physical access to the platform.
407 The physical environment of the platform falls into one of the two categories:
408 — Trusted physical environment (ENV-TRP): environment where such users are not expected to intentionally
409 attempt to compromise the platform (USR-TRI and USR-TRE as defined in 4.5). In these environments,
410 attacks requiring physical access to be exploited are not applicable.
411 EXAMPLE 1 Private locations such as homes, secure server rooms within company premises, or private areas situated
412 inside public buildings likes hospitals, libraries or shops.
413 — Untrusted physical environment (ENV-NTP): environment where such users are considered potential
414 attackers or vectors of attacks (USR-NTE as defined in 4.5). In such environments, secure implementation
415 of the platform and absence of vulnerabilities are expected to mitigate attacks requiring physical access to
416 be exploited.
417 EXAMPLE 2 Public areas or easily accessible without control such as transportation hubs, public kiosks, urban
418 infrastructure.
419 4.3.2.3 Risk context
420 In this standard, platforms are intended for integration into devices whose functionalities range from those which
421 are associated with an existing but low likelihood of vulnerability exploitation and low adverse impact in terms
422 of damage to users or other products, to those whose functionalities present a certain likelihood of vulnerability
423 exploitation and medium adverse impact in terms of harm to users or other products, networks or services
424 To address this context platforms are expected to provide well-designed and effective security functionalities
425 against attacks, physical and/or logical as determined by the logical and physical environment
426 The risk context falls into one of two categories
427 — Low risk environment (ENV_RKL);
428 — Medium risk environment (ENV_RKM).
429 Low risk context (ENV-RKL): in this case, platforms are intended for integration into devices where the
430 cybersecurity risk remains limited, based on the intended use and deployment context. To address this context,
431 platforms are required to provide well-designed and effective security functionalities with no vulnerability
432 Medium risk context (ENV-RKM): in this case, platforms are intended for integration into devices whose
433 functionalities present a certain likelihood of vulnerability exploitation and medium adverse impact in terms of
434 harm to users or other products, networks or services. To address this context, platforms are required to
435 demonstrate the resistance of its se
...