prEN 18330

SLOVENSKI STANDARD
01-marec-2026
Zahteve za kibernetsko varnost pametnih kartic ali podobnih naprav, vključno z
varnostnimi elementi - Aplikacijska plast
Cybersecurity requirements for smartcards or similar devices, including secure elements
- Application layer
Smartcards, ähnliche Komponenten und Secure Elements - Kriterien zur Erfüllung der
wesentlichen Anforderungen der Verordnung (EU) 2024/2847
Ta slovenski standard je istoveten z: prEN 18330
ICS:
35.030 Informacijska varnost IT Security
35.240.15 Identifikacijske kartice. Čipne Identification cards. Chip
kartice. Biometrija cards. Biometrics
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

DRAFT
EUROPEAN STANDARD
NORME EUROPÉENNE
EUROPÄISCHE NORM
January 2026
ICS 35.030; 35.240.15
English Version
Cybersecurity requirements for smartcards or similar
devices, including secure elements - Application layer
Smartcards, ähnliche Komponenten und Secure
Elements - Kriterien zur Erfüllung der wesentlichen
Anforderungen der Verordnung (EU) 2024/2847
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee
CEN/TC 224.
If this draft becomes a European Standard, CEN 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 CEN in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
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 STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2026 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 18330:2026 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
2 Normative references . 5
3 Terms, definitions, symbols and abbreviated terms . 5
3.1 Terms and definitions . 5
3.2 Symbols and abbreviated terms . 7
4 Product context . 8
4.1 Intended purpose and foreseeable use . 8
4.2 Product functions. 8
4.3 Product architecture . 9
4.4 Operational environment . 11
4.5 Distribution of security functions . 12
4.6 Users . 12
4.7 Use cases . 12
5 Security requirements . 14
5.1 General notes on security requirements . 14
5.2 Product security . 14
5.3 Essential vulnerability handling requirements . 23
5.4 Additional security requirements . 26
6 Conformity assessment . 26
6.1 Assessment of product security . 26
6.2 Assessment of essential vulnerability handling . 33
6.3 Additional security requirements . 35
Annex A (normative) Extended SARs and SFRs . 36
Annex B (informative) Risk acceptance criteria and risk management methodology . 51
Annex C (informative) Governmental use cases . 54
Annex D (informative) UICC and eUICC use cases . 56
Annex ZA (informative) Relationship between this European Standard and the essential
requirements of Regulation (EU) 2024/2847 aimed to be covered . 57
Bibliography . 59

European foreword
This document (prEN 18330:2026) has been prepared by CEN/TC 224 Personal identification and
related personal devices with secure elements, systems, operations and privacy in a multi sectorial
environment.
This document is currently submitted to the CEN Enquiry.
This document has been prepared under a standardization request addressed to CEN-CENELEC by the
European Commission. The Standing Committee of the EFTA States subsequently approves these
requests for its Member States.
For the relationship with EU Legislation, see informative Annex ZA, which is an integral part of this
document.
Introduction
The growing dependence on secure elements—consisting of a secure integrated circuit or platform and
applications that perform secure operations—requires ongoing diligence and comprehensive cyber
resilience planning by manufacturers and developers. This is essential to design systems capable of
withstanding the threats outlined in [2], as well as other use case-specific risks.
Secure elements are extensively implemented in smart cards, key fobs, SIM cards, and similar devices,
and are increasingly integrated into mobile phones, connected consumer products, and IoT systems.
Within these environments, the application operating on the secure platform serves as a vital
component of trusted functionality; therefore, any deficiencies in its design or implementation can
potentially expose both the device and its ecosystem to significant security threats from malicious
entities.
The security requirements outlined in this standard are designed to reinforce the robustness of
applications running on secure elements and safeguard their security assets. These measures aim to
enhance the application's resilience against prevalent cybersecurity risks, including attacks leveraging
publicly known vulnerabilities, and to support the overall assurance of devices and systems that rely on
secure computation, protected communication channels, and effective safeguarding of sensitive
information.
1 Scope
This document defines cyber security requirements for products with digital elements belonging to
product category “application on the Smart Cards, Secure Elements, and similar devices” (hereinafter
called “Product”). It extends the prEN 50764:2026, which defines the cyber security requirements for
the platform underneath the application.
All products with digital elements having the form of a Smart Card or any similar device, where
application is not installed on a platform defined by prEN 50764:2026 are excluded from the scope of
this document.
More details about the product context in scope is given with Clause 4.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
EN ISO/IEC 15408-2:2023, Information security, cybersecurity and privacy protection - Evaluation
criteria for IT security - Part 2: Security functional components (ISO/IEC 15408-2:2022)
EN ISO/IEC 15408-3:2023, Information security, cybersecurity and privacy protection - Evaluation
criteria for IT security - Part 3: Security assurance components (ISO/IEC 15408-3:2022)
EN ISO/IEC 18045:2023, Information security, cybersecurity and privacy protection - Evaluation criteria
for IT security - Methodology for IT security evaluation (ISO/IEC 18045:2022)
prEN 40000-1-3:2026, Cybersecurity requirements for products with digital elements - Part 1-3:
Vulnerability Handling
prEN 50764:2026, Secure IC CRA standard – full reference to be available after publishing
3 Terms, definitions, symbols and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply:
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp/
— IEC Electropedia: available at https://www.electropedia.org/
3.1.1
application
software that provides service(s) to the user of the final product
3.1.2
application environment
firmware and/or software that provides functionalities to store and execute applications
3.1.3
platform
tangible or intangible element (or assembly of elements) composed at a minimum of a tamper-resistant
MCU/MPU and possibly including an application environment or operating system, designed to resist to
attacks requiring moderate or high attack potential
3.1.4
platform embedded software
software that is not part of the platform but is stored and executed in the platform
Note 1 to entry: This term designates the software composed or the application environment and/or the
applications depending on the nature of the platform (bare IC, Java Card, etc.).
3.1.5
user
entity interacting with the final product
Note 1 to entry: Users interact with the platform either directly or indirectly through the platform embedded
software if supported.
3.1.6
user data
data stored and/or processed in the platform on behalf of the user of the final product
EXAMPLE: A smartcard implementing Java Card application (Applet) stores and processes user data through
individual applications.
3.1.7
Java CardTM platform
smart card operating system or ICC platform implementing the java CardTM technology allowing secure
execution of Java CardTM based applications – named applets
Note 1 to entry: Java CardTM platform are dedicated to resources constraints devices such as IC.
Note 2 to entry: Java CardTM platform are used in payment cards, identity cards and UICC cards but also on Secure
Elements that are embedded into Smartphones, IoT devices, and more.
3.1.8
applet
application running on a Java CardTM platform
3.1.9
cyclone DX6
modular and extensible framework for representing software/hardware supply-chain information in a
machine-readable Bill of Materials (BOM)
3.2 Symbols and abbreviated terms
Table 1 — Terms and abbreviations
Abbreviation Explanation
CC Common Criteria
European Common Criteria–based Cybersecurity Certification
EUCC
Scheme
IC Integrated circuit
ICC Integrated Circuit Card
UICC A secure element as defined by ETSI SET specifications
UICC with remote provisioning capabilities, as defined by GSMA
eUICC
SGP.XX specifications
ISIM IP Multimedia Services Identity Module
USIM Universal Subscriber Identity Module
SWP Single Wire Protocol
International Civil Aviation Organization.
ICAO
Organization defining the specifications of eMRTDs.
eMRTD Electronic machine-readable travelling document
BAC Basic Access Control, as defined in ICAO Doc 9303 Ed8 Part 11
MCU Microcontroller unit
MPU Microprocessor unit
RDPS Remote Data Processing Solution
SE Secure Element
SFR Security Functional Requirement
SAR Security Assurance Requirement
SPDX Software Package Data eXchange as defined in
A unique identifier used to reference a specific license or software
SPDX-ID
component in an SPDX document.
URI Uniform Resource Identifier
TOE Target of Evaluation
4 Product context
4.1 Intended purpose and foreseeable use
Intended purpose of the Product in scope of this document is to perform following secure
computational operations on sensitive information in a tamper resistant environment based on
following capabilities:
a) Retrieval and communication of the sensitive information from and through the secure element’s
interfaces.
b) Processing of information, which includes performance of computational and cryptographic
operations.
c) Secure storage of retrieved and/or processed information.
Product may perform non-secure computations and handle non-sensitive data.
Foreseeable use of a Product considers usage of the listed capabilities by the functions in particular use
cases.
Figure 1 brings an example of one out of many possible relations:

Figure 1 — Example of relations between an intended purpose of a Product and functions within
use cases.
4.2 Product functions
The number of functions implemented in the product's use case is not exhaustive. Product’s security
functions make use of one or more intended purpose capabilities.
4.3 Product architecture
4.3.1 General notes on product architecture
Depending on the form factor and a use case, any of following architectures represent the Product. The
most relevant representation is given with the architectural description of the Secure Element, which
can be further embedded into smart cards or similar devices.
4.3.2 Secure element
Figure 2 describes the most rudimentary architecture of a secure element:

Figure 2 — Simplified architecture of a secure element
A Secure Element is composed of (1) an underlying Secure IC, (2) execution environment, and (3) at
least one application which is embedded and runs on that underlying IC. All three components may be
placed on the market independently from each other.
Once placed on the market, a Product is an intermediate industrial product which is not equipped with
all materials and circuitry needed to interact with an external device (e.g. contact plate, antenna, etc.).
4.3.3 Smart card
Within the scope of this standard, a smart card consists of a secure element that is embedded in a body
which has an ID1/TD1 form factor as defined in EN 7810:2019 [5].
Figure 3 — Representation of the ICCs and their division to the smart cards that are comprising
the Secure Element and other that may have different types of integrated circuit.
Following the distinction given by the Figure 3, ICCs that include ICs, MCUs, or MPUs, which do not meet
the definition of a Secure IC as outlined in prEN 50764:2026 but may have an execution environment
and one or more applications, are classified as application specific cards. These are not considered as
smart cards according to the scope of this document.
Once placed on the market, a smart card may still require further stages of graphical and physical
modifications to the card body (e.g. printing, embossing, etc.) which are out of the scope of this
document.
4.3.4 Similar devices
Figure 4 describes similar devices which comprise secure elements (as defined above) embedded in
bodies which (1) has a form factor different from the smart card, and (2) are optionally equipped with
additional electronic and digital devices.
Figure 4 — Some examples of similar devices that may contain SE.
Once placed on the market, a similar device may still require further stages of graphical or physical
modifications which are out of the scope of this document.
ICs, MCUs or MPUs which do not qualify as secure element which are embedded within a similar device
as defined above are not in the scope of this document.
4.4 Operational environment
Operational environment of a Product includes two aspects:
a) Platform, as described by prEN 50764:2026, which is supporting Application functionalities.
b) Environment supporting execution of the RDPS.
Any processing of the data transmitted to or from a Product is considered as a remote data processing
solution. Transmission of these data may happen via contact or contactless interfaces, and it may
involve multiple devices between the end points where processing is happening and the application
itself.
The transfer of the data to or from a Product may involve one or more devices such as but not limited
to:
1) Smartphones, RFID and biometric readers or smart lock, payment terminals, IoT devices with an
embedded MCU/MPU with a physical connection to a SE interface.
2) Any device that can communicate with an application on the SE via wireless or contactless protocol
supported by the SE platform, such as but not limited to protocols comprised within the NFC stack,
Bluetooth/BLE, UWB.
3) Devices and services behind the 1. and 2., such as but not limited to controllers, proxies, servers,
regardless of their physical distance to a SE, such as local / off-line services or cloud services.
Requirements on the remote data processing solution in relation to CRA compliance of the application
on the SE are given in 5.5.
4.5 Distribution of security functions
The Product covered by this standard refers to prEN 50764:2026 for security dependencies, where
composition of the product is described in Clause 1.3 [3].
As an intermediary, the Product does not meet functional needs on its own and shall be part of a
composed product, which may fall under other standards related to the CRA regulation. This may
require attention to how security functions are distributed across the value chain of such composed
product.
4.6 Users
The Product is utilized across numerous sectors of human activity, and its applications extend beyond
purely security-related functions. Consequently, the total number of users and their roles cannot be
precisely determined.
4.7 Use cases
Some but not all use cases for the Product can be associated with following vulnerability analysis levels
and Risk Profile assignment:
Table 2 — Use cases in relation to appropriate vulnerability analysis level
Risk Profile Vulnerability
Use case Comment
(see B.2) analysis level
This is the only agreed exception to
these levels is related to ICAO9303
compliant Basic Access Control
protocol which can reach the
eMRTD (ICAO-compliant) –
RP1 AVA_VAN.3 AVA_VAN.3 level; the exception is
BAC mode only
valid only for the application on the
Secure Element. The Platform
underneath the application shall be
evaluated for AVA_VAN.5.
Pay TV or subscription access
These assume attackers can invest in
Access control - corporate, side-channel attacks, fault injection,
smart home and hospitality RP2 AVA_VAN.4 reverse engineering, but with limited
budgets (universities, laboratories,
IoT – corporate, smart home
criminal organizations).
and hospitality
eMRTD (ICAO-compliant)
National ID / eGovernment
Banking and financial
applications (EMV credit/debit
cards, mobile payment)
Electronic driving licenses
Residence permits
These assume attackers have long
Qualified digital signatures
time frames, large budgets, highly
RP3 AVA_VAN.5
specialized equipment, and deep
Defense, intelligence, or
expertise.
military
Access control - critical
infrastructure
IoT – critical infrastructure
Root-of-trust applications
eUICC - eSIM
UICC – removable SIM
NOTE Details about establishment of the Risk Profiles (RP1–3) are given in Annex B.
5 Security requirements
5.1 General notes on security requirements
To achieve the CRA compliance for the Product according to this standard, the requirements defined in
5.2, 5.3 and 5.5 shall be followed and a Risk profile according to Annex B shall be established.
For essential security requirements 5.1.2 to 5.1.14, risk assessment shall be performed.
For all essential security requirements, following is valid:
— Product in an environment with a moderate attack potential shall refer to the following developer
(D) and content (C) requirements specified in EN ISO/IEC 15408-3:2023:
— AVA_VAN.4 for methodological vulnerability analysis.
— Product in an environment with a high attack potential shall refer to the following developer (D)
and content (C) requirements specified in EN ISO/IEC 15408-3:2023:
— AVA_VAN.5 for advanced methodological vulnerability analysis.
The only agreed exception to these levels is related to ICAO9303 compliant Basic Access Control
protocol which can reach the AVA_VAN.3 level; the exception is valid only for the application on the
Secure Element. The Platform underneath the application shall be evaluated for AVA_VAN.5.
5.2 Product security
5.2.1 Security by design
5.2.1.1 Requirements
— The security analysis of an application shall be performed to determine the target risk environment
and define the security problem in terms of threats and assumptions for operational environment
specific to the application. The application manufacturer identifies and implements the applicable
security requirements for their application.
— Recommendations from [7] for the state-of-the-art cryptography may be followed.
— Requirements specified in EN ISO/IEC 15408-3:2023 for the developer (D) and content (C) shall be
followed:
— ASE_INT.1 for applications narrative overview, reference, description.
— ASE_SPD.1 that defines security problems that application may encounter.
— ASE_OBJ.2 for security objectives of the application itself.
— ASE_REQ.1 defining security requirements of the application.
5.2.1.2 Applicability
Mandatory.
5.2.2 No known exploitable vulnerabilities
5.2.2.1 Requirements
— Known vulnerabilities, including the ones described in ENISA vulnerability database, shall be
addressed, either by mitigating their exploitation by attackers with up to significant resources and
skills (moderate or high attack potential as defined in EN ISO/IEC 15408-3:2023).
5.2.2.2 Applicability
Mandatory.
5.2.3 Secure-by-default configuration
5.2.3.1 Requirements
— Default configuration of the application shall ensure that it is secure, minimizing the need for end-
user intervention to achieve a secure state. This includes disabling unnecessary services and
interfaces, enforcing strong authentication and access controls, and enabling security features by
default.
— The application shall offer the ability to perform a reset command to enable the ability to restore
the product to its original, secure-by-default state.
— Requirement specified in A.2.1 shall be implemented:
— ADV_ARC.2
— Requirements specified in EN ISO/IEC 15408-3:2023 while focussing on specification of application
configuration management functions for the developer (D) and content (C), shall be followed:
— ADV_FSP.2
— ADV_TDS.1
— Requirements specified in EN ISO/IEC 15408-2:2023 shall be followed:
— FMT_SMF.1
— FMT_MOF.1
— FMT_SMR.1
5.2.3.2 Applicability
Mandatory.
Exceptions are possible for
— tailor-made products under condition that exception is agreed by the users of such products;
— operational environments where factory reset is not possible, particularly for smart card
applications;
— Product configurations where One-Time-Programmable types of memories are used.
An alternative to FMT_SMF.1 can be chosen for as long as it ensures at least equivalent specification of
the application configuration management functions.
Otherwise FMT_SMF.1 shall include functionality to reset the Product to its default state.
FMT_MOF.1 and FMT_SMR.1 shall be implemented when the usage of the reset command is restricted to
certain user roles only.
For eUICC, Resetting the product to the original state is covered by SGP.22 and SGP.32
ES10c.eUICCMemoryReset function. A loaded profile can also easily be deleted by the user, meaning the
eUICC will be back to its original state. FMT_MOF.1 is not applicable.
5.2.4 Enable secure update
5.2.4.1 Requirements
— A mechanism to offer the possibility to securely update the application and application’s associated
components (such as application specific libraries, remote processing routines, etc.) shall be
deployed. This includes ensuring the authenticity and integrity of updates through cryptographic
verification, protecting the update process from unauthorized manipulation, and providing secure
rollback or recovery mechanisms in case of failure.
— Automated means to offer such security updates shall be provided.
— The update mechanism shall be designed with an opt-out function that is accessible to authorized
users.
— The process for security update classification and management as described in [1], Annex 15: Patch
Management may be followed.
— Requirements specified in EN ISO/IEC 15408-3:2023 for the developer (D) and content (C) shall be
followed, while focusing on the secure update mechanism:
— AGD_OPE.1
— AGD_PRE.1
— ADV_FSP.2
— ADV_TDS.1
— ALC_DEL.1
— Information about all the changes related to this process after the application is placed on the
market shall be provided.
5.2.4.2 Applicability
Mandatory.
Vulnerabilities shall be addressed through the replacement of the Product or through security updates,
including, where applicable, through automatic security updates.
5.2.5 Prevent unauthorized access
5.2.5.1 Requirements
— Mechanisms to prevent unauthorized access to applications configurations, resources, data, and
functionalities shall be provided. This includes implementing robust authentication, access control
policies, session management, and protection of sensitive data in storage and transit.
— Requirements specified in EN ISO/IEC 15408-3:2023 for the developer (D) and content (C) shall be
followed, while focusing on user identification and authentication and timing therefore, as well as
notification and storage of unauthorized access attempt event:
— AGD_OPE.1
— AGD_PRE.1
— ADV_FSP.2
— ADV_TDS.1 or ADV_IMP.1
— ALC_CMC.5
— ATE_IND.2
— Requirements specified in EN ISO/IEC 15408-2:2023 shall be followed:
— FIA_UAU.1
— FIA_UID.1
— FAU_SAA.1
— FAU_STG.1
5.2.5.2 Applicability
Mandatory.
If a reliable timing source is not available in a system with a Secure Element, notifications of
unauthorized access events and logging related information can be performed in a sequential order,
without reference to the actual time when the events occurred.
5.2.6 Ensure data confidentiality
5.2.6.1 Requirements
— Confidentiality of applications sensitive data during storage, processing, and in transit shall be
ensured. This activity includes the use of cryptographic mechanisms that may be compliant with
[7], to protect data from unauthorized disclosure, enforcement of access controls, and secure
handling of cryptographic keys.
— Requirements specified in EN ISO/IEC 15408-3:2023 for the developer (D) and content (C) shall be
followed, while focusing confidentiality of data stored in memory by application:
— ADV_FSP.2
— ADT_TDS.1
— Requirements specified in EN ISO/IEC 15408-2:2023 shall be followed, while focusing
confidentiality of data stored in memory by application:
— FDP_SDC.1
— FCS_COP.1
— FTP_TRP.1
— Data model that enables data isolation by application shall be implemented in a way that enables
independent processing of isolated data sets.
5.2.6.2 Applicability
Mandatory.
5.2.7 Preserve integrity
5.2.7.1 Requirements
— The application shall protect integrity of personal and other data, commands, programs,
configurations during their execution, configuration, storage, processing, and transmission. This
protection includes cryptographic (which may be compliant with [7]) and other mechanisms to
detect and prevent unauthorized or accidental modification of data, such as, but not limited to
cryptographic checksums, cyclic redundancy checks (CRC), error-correcting codes (ECC),
redundancy and replication mechanisms, historic version audit integrity verification processes.
— Requirements specified in EN ISO/IEC 15408-3:2023 for the developer (D) and content (C) shall be
followed, while focusing on integrity protection of data at rest, during transfer between
applications, platforms and users:
— ADV_FSP.2
— ADT_TDS.1
— Requirements specified in EN ISO/IEC 15408-2:2023 shall be followed:
— FDP_SDI.1
— FAU_GEN.1
— FDP_SDI.2
— FTP_ITC.1
— FTP_TRP.1
— FCS_COP.1
5.2.7.2 Applicability
Mandatory.
5.2.8 Data minimization
5.2.8.1 Requirements
— The application shall process only personal and other data that are adequate, relevant, and limited
to what is necessary in relation to the intended purpose of the Product. This includes implementing
controls, such as but not limited to data collection restriction, purpose limitation enforcement, data
retention and sharing and sharing limitations.
— Requirement specified in A.2.2 shall be implemented:
— ADV_PDM.1
5.2.8.2 Applicability
Mandatory.
The data minimization requirement ADV_PDM.1 does not apply to an eUICC as provided by the eUICC
manufacturer.
5.2.9 Essential and basic functions
5.2.9.1 Requirements
— Availability of essential and basic functions, including after a security incident should be ensured.
This includes implementing resilience and recovery mechanisms, such as redundancy, failover,
backup and restore procedures, load balancing, automated recovery, and incident response
capabilities, as well as mitigation measures against denial-of-service (DoS) and distributed denial-
of-service (DDoS) attacks.
— Requirements specified in EN ISO/IEC 15408-3:2023 for the developer (D) and content (C) shall be
followed, while focusing on fault tolerance:
— ADV_FSP.2
— ADT_TDS.1
— Requirements specified in EN ISO/IEC 15408-2:2023 shall be followed:
— FRU_FLT.2
5.2.9.2 Applicability
Mandatory.
A security incident may temporarily or permanently stop certain functions, if such interrupts are
specified security function of the Product.
5.2.10 Minimize service disruption
5.2.10.1 Requirements
— The application shall be designed and configured to avoid disruptions and availability of services
provided by other devices or networks to which it is connected. This activity includes preventing
excessive resource consumption (e.g. bandwidth, CPU, memory), avoiding broadcast storms or
malformed traffic, and implementing safeguards to detect and mitigate unintended interference or
cascading failures. Depending on the use case specifics, the system shall incorporate one or more
mechanism such as – but not limited to:
— The application or asset management and isolation, such as sandboxing, memory quota
limitations, secure channel management
— Communication controls such as protocolized command rate limits, command integrity and
format validations, command flood detection, secure channel usage
— Fault detection and mitigations such as error code checking, atomicity and roll-back checks
— Redundancy and recovery mechanisms that involve persistent state validation, redundant data
storage, fail-safe defaults
— Requirements specified in EN ISO/IEC 15408-3:2023 for the developer (D) and content (C) shall be
followed, while focusing on secure state at power-on:
— ADV_FSP.2
— ADV_TDS.1
— ADV_ARC.1
— Requirements specified in EN ISO/IEC 15408-2:2023 shall be followed:
— AFPT_INI.1
— FPT_TST.1
5.2.10.2 Applicability
Mandatory.
5.2.11 Limit attack exposure
5.2.11.1 Requirements
— The application shall be designed, developed, configured and produced in a way that minimizes its
attack surface. This activity includes reduction of the number and complexity of exposed interfaces,
disablement of the unnecessary services and ports, enforcement of strict input validation, and
isolation of all critical components. External interfaces shall be protected through authentication,
access control, secure channel and secure communication protocols.
— The application shall maintain operational continuity and recoverability even under attack by
adversaries with moderate to high attack potential as defined in EN ISO/IEC 15408-3:2023; The
event of the security incident may allow a temporary or permanent discontinuation of
functionalities if such discontinuation is a specified security function of the Product.
— Requirements specified in EN ISO/IEC 15408-3:2023 for the developer (D) and content (C) shall be
followed:
— ADV_FSP.2
— AGD_PRE.1
— AGD_OPE.1
5.2.11.2 Applicability
Mandatory.
5.2.12 Mitigate incident impact
5.2.12.1 Requirements
— The application shall be designed, developed and produced in a way that reduces the impact of
security incidents by incorporating appropriate exploitation mitigation mechanisms and
techniques. This activity may include implementing one or multiple measures such as but not
limited to memory protection, sandboxing, privilege separation, secure coding practices, runtime
protections and usage of the attack sensory modules provided by the platform, in accordance with
the guidance documents of the platform; these measures shall limit the ability of attackers to
escalate privileges, persist, or move laterally within the system, even when a vulnerability is
exploited.
— Requirements specified in EN ISO/IEC 15408-3:2023 for the developer (D) and content (C) shall be
followed, while focussing on secure state preservation and automated recovery:
— ADV_FSP.2
— ADV_TDS.1
— ADV_ARC.1
— Requirements specified in EN ISO/IEC 15408-2:2023 shall be followed.
— FPT_FLS.1
— FPT_RCV.2
5.2.12.2 Applicability
Mandatory.
5.2.13 Monitor security activity
5.2.13.1 Requirements
— Recording and monitoring of relevant application-internal Requirements, including access to or
modification of data, services, or functions shall be ensured. This logging capability shall support
security auditing, incident detection, and forensic analysis. The system shall provide users with a
clear and accessible opt-out mechanism for non-essential monitoring, in compliance with privacy
and data protection regulations.
— Such logging shall be protected against tampering and unauthorized access and shall be resilient
against attackers with moderate to high attack potential as defined in EN ISO/IEC 15408-3:2023.
— Requirements specified in EN ISO/IEC 15408-3:2023 refer for the developer (D) and content (C)
shall be followed, while focusing on configuring and managing of security roles and audit
generation:
— ADV_FSP.2
— ADV_TDS.1
— ADV_ARC.1
— Requirements specified in EN ISO/IEC 15408-2:2023 shall be followed:
— FAU_GEN.1
— FMT_SMF.1
— FMT_SMR.1
5.2.13.2 Applicability
Mandatory.
Exceptions regarding the recording and monitoring may be considered only for cases where monitoring
of application-internal Requirements would exhaust computational, communication and storage
resources of the application environment (chip / OS platform) in the way that would violate compliance
to 5.2.9 and 5.2.10.
Exceptions from the opt-out-mechanism may be tolerated only in cases of applications where users:
— don’t own the application and Secure Element (example: governmental ID cards, MRTD) or the data
in question;
— access to applications functionality is permanently prevented for security reasons (example: read-
only smart cards), in which case user may physically destroy the Secure Element.
5.2.14 Ensure secure erasure
5.2.14.1 Requirements
— Users of the application shall have an option to securely and easily delete all personal data and
settings stored in application on a permanent basis. Where applicable, the application shall also
support the secure transfer of such data to other products or systems, ensuring confidentiality and
integrity during the transfer process.
— This option shall be designed to prevent data recovery or leakage and shall be resilient against
attackers with moderate to high attack potential as defined in EN ISO/IEC 15408-3:2023.
— Requirements specified in EN 15408-3 for the developer (D) and content (C) shall be followed,
while focusing on data removal and transport, permanent deletion of data, controlled export
process and data selection, secure channel for data transfer:
— ADV_FSP.2
— ADV_TDS.1
— Requirements specified in EN 15408-3 shall be followed:
— FMT_SMF.1
— FDP_RIP.1
— FDP_ETC.2
— FTP_ITC.1
5.2.14.2 Applicability
Mandatory.
Exceptions may be tolerated only in cases of applications where users:
— don’t own the application and Secure Element (example: governmental ID cards, MRTD) or the data
in question;
— access to applications functionality is permanently prevented for security reasons (example: read-
only smart cards);
— may physically destroy the Secure Element.
5.3 Essential vulnerability handling requirements
5.3.1 General notes
Following clauses shall complement the Annex ZA table of the prEN 40000-1-3:2026, with specifics
relevant to the Product.
Additional guideline on vulnerability handling that may be considered is given with [6].
5.3.2 Identify components and vulnerabilities
5.3.2.1 Requirements
— Up-to-date list of vulnerabilities as well as all application-related software components included
within the Secure Element (application Software Bill of Materials - SBOM) shall be identified,
documented, and maintained. This requirement applies regardless of whether the application is
present within the Product at the time the Product is placed on the market or added later during
the Product’s lifecycle.
— The SBOM shall be kept up to date, including for cases where security updates are developed, and
used to monitor and assess potential vulnerabilities throughout the entire lifecycle of the Product.
— Requirements given with in A.2.3 may be followed:
— ALC_SBM
5.3.2.2 Applicability
Mandatory.
Alternative to ALC_SBM may be chosen for as long as they provide equivalent or better method.
5.3.3 Address and remediate vulnerabilities
5.3.3.1 Requirements
— Procedures for timely remediation of vulnerabilities and issuance of application related security
updates shall be established. Where technically feasible, these security updates should be applied
independently from the new or enhanced functional updates. The process shall comply with CRA
timelines and avoid unnecessary delays.
— In circumstances where automated updates are not feasible, security updates may be implemented
through a replacement of the Product or a device containing the Product.
— Requirements given with in A.2.4 shall be followed:
— ALC_FLR.4
5.3.3.2 Applicability
Mandatory.
ALC_FLR.4 does not apply to the eUICC as there is no guarantee that a device is connected to a network
providing connectivity to an update server, automatic updates cannot happen immediately but only
when an active connection is established.
5.3.4 Regular testing
5.3.4.1 Requirements
— Regular security reviews and tests of the application until the end-of-life of the Product, after their
placement on the EU market, which predicates CRA compliance, shall be performed.
— Requirements given with in A.2.5 shall be followed:
— ALC_PSR.1
5.3.4.2 Applicability
Mandatory.
5.3.5 Public disclosure obligation
5.3.5.1 Requirements
— A detailed vulnerability description, estimation of impact and severity, procedure to identify
application affected by this vulnerability, and a clear instruction for remediations shall be
comprised and disclosed publicly; disclosure shall happen immediately after the security updates
are available.
— In alignment with manufacturers of the SE, smart cards, and similar devices, a disclosure may be
delayed for a limited and defined period, only for the cases where immediate publication of
disclosure would ev
...