NL-P-03 requirements

This page lists every requirement of NL-P-03 (Secure Software Development & Vulnerability Management Practices for Wallet and PID Providers, version RC1.0) as published on 6 November 2026. The PDF is authoritative: each requirement links to the page it is on. You can also read the full text or search all requirements.

122 entries: 122 requirements (CR). Obligation: 122 mandatory.

Legal basis of the document: CRA, CIR 2024/2981.

4.2 Product Context Documentation

Read section 4.2 in the full text

5.2-CR-01

The product context shall be identified and documented, covering the product's intended purpose and reasonably foreseeable use (IPRFU), its functions, its operational environment, an architectural overview, a description of its users including their experience level and security-relevant objectives, and where relevant and useful: general product insights from the market segments involved, including market expectations.

Requirement (CR) · obligation: mandatory · PDF page 10

• Source: RMA-01-RQ-01, Input clause (40000-1-2 6.2)

5.2-CR-02

Where the product includes remote data processing solutions (RDPS), the RDPS shall be considered to be included in the product context.

Requirement (CR) · obligation: mandatory · PDF page 11

• Source: RMA-01-RQ-02 (40000-1-2)

5.2-CR-03

A documented procedure shall be maintained for establishing and updating the product context, including defined triggers for re-evaluation when the application, its RDPS, or its operational environment changes.

Requirement (CR) · obligation: mandatory · PDF page 11

4.3 Risk Acceptance Criteria

Read section 4.3 in the full text

5.3-CR-01

The cybersecurity risk acceptance criteria shall be established. At minimum, the criteria shall account for the product context, regulatory factors, supply chain aspects, the nature of risks, the current state of the art, and user needs.

Requirement (CR) · obligation: mandatory · PDF page 12

• Source: RMA-02-RQ-01 (40000-1-2) and corresponding assessment criteria (user needs)

4.4 Product Cybersecurity Asset Identification

Read section 4.4 in the full text

5.4-CR-01

When conducting a product cybersecurity risk assessment, all cybersecurity assets relevant to the product shall be identified, and it shall be determined which cybersecurity properties (confidentiality, integrity, availability, authenticity, and others as applicable) need to be ensured for each. This identification shall be grounded in the product context established under section 5.2, and the resulting asset list with associated cybersecurity properties shall be included in the product's technical documentation. The asset scope is broad and shall consider data assets (e.g. credentials, keys, personal data, configuration data, safety signals, firmware images, logs), functional assets, hardware and software components and interfaces, user-objective assets (health, safety, privacy, availability), and environmental assets (adjacent networks, third parties, public interest, and assets involved in RDPS).

Requirement (CR) · obligation: mandatory · PDF page 13

5.4-CR-02

In case the application employs AI models, AI-specific assets shall be included in the considerations to identify cybersecurity assets.

Requirement (CR) · obligation: mandatory · PDF page 14

4.5 Product Cybersecurity Risk Identification

Read section 4.5 in the full text

5.5-CR-01

Drawing on the established product context, product cybersecurity risks shall be identified. Each identified risk shall specify which asset(s) are targeted, which cybersecurity objective(s) of those assets may be compromised, and the cause of that potential compromise.

Requirement (CR) · obligation: mandatory · PDF page 15

• Source: RMA-04-RQ-01 (40000-1-2)

5.5-CR-02

Where publicly known vulnerabilities exist that are relevant to the product's assets and their associated cybersecurity properties, those publicly known vulnerabilities shall be identified. This obligation is conditional on the availability of such information.

Requirement (CR) · obligation: mandatory · PDF page 15

• Source: RMA-04-RQ-02 (40000-1-2)

5.5-CR-03

A documented threat modelling procedure specific to mobile applications shall be established and maintained, defining the methodology to be applied (e.g., STRIDE, PASTA, attack trees), the threat catalogues to use, the roles responsible for conducting threat modelling, and the trigger conditions under which threat modelling shall be performed or repeated (e.g., new feature introduction, platform OS update, third-party SDK integration).

Requirement (CR) · obligation: mandatory · PDF page 16

4.6 Product Cybersecurity Risk Analysis

Read section 4.6 in the full text

5.6-CR-01

For each product cybersecurity risk identified in accordance with 5.5, the likelihood of the associated cybersecurity incident occurring shall be estimated.

Requirement (CR) · obligation: mandatory · PDF page 16

• Source: RMA-05-RQ-01 (40000-1-2)

5.6-CR-02

For each product cybersecurity risk identified in accordance with 5.5, the severity of impact of the associated cybersecurity incident shall be estimated.

Requirement (CR) · obligation: mandatory · PDF page 17

• Source: RMA-05-RQ-02 (40000-1-2)

5.6-CR-03

For each product cybersecurity risk identified in accordance with 5.5, the cybersecurity incident scenario in which that risk could materialize shall be documented.

Requirement (CR) · obligation: mandatory · PDF page 17

• Source: RMA-05-RQ-03 (40000-1-2)

5.6-CR-04

A repeatable risk analysis methodology for cybersecurity risks shall be defined and documented, specifying the rating scale, criteria, and scoring rationale to be applied consistently across all risk assessments.

Requirement (CR) · obligation: mandatory · PDF page 18

5.6-CR-05

The rationale and evidence supporting each likelihood and severity result shall be documented, enabling independent review and auditability of the risk analysis.

Requirement (CR) · obligation: mandatory · PDF page 18

4.7 Product Cybersecurity Risk Evaluation and Risk Acceptance

Read section 4.7 in the full text

5.7-CR-01

Every identified risk shall be systematically assessed against the pre-established risk acceptance criteria to determine whether it can be accepted as-is or shall be subjected to treatment measures.

Requirement (CR) · obligation: mandatory · PDF page 19

• Source: RMA-06-RQ-01 (40000-1-2)

5.7-CR-02

A risk may be deemed acceptable only when it demonstrably aligns with the predetermined risk acceptance criteria defined in 5.3. Risks that do not meet these criteria shall not be accepted, regardless of other considerations such as cost or feasibility.

Requirement (CR) · obligation: mandatory · PDF page 19

• Source: RMA-06-RQ-02 (40000-1-2)

5.7-CR-03

When residual risks are shared with users - because the product relies on the operational environment or user action to provide necessary controls - it shall be verified that the required user mitigations are realistic and achievable for the intended user base, given their expected knowledge and capability. Risk acceptance under these conditions is contingent on this verification.

Requirement (CR) · obligation: mandatory · PDF page 19

• Source: RMA-06-RQ-03 (40000-1-2)

5.7-CR-04

For each accepted or residual risk, a documented acceptance justification shall be produced and retained explaining why the risk is considered acceptable. This justification shall reference the risk acceptance criteria from 5.3 and shall describe any conditions of use or operational environment assumptions on which the acceptance is predicated.

Requirement (CR) · obligation: mandatory · PDF page 20

4.8 Product Cybersecurity Risk Treatment

Read section 4.8 in the full text

5.8-CR-01

For every risk that does not satisfy the established risk acceptance criteria, a treatment option that is appropriate to the product context shall be applied.

Requirement (CR) · obligation: mandatory · PDF page 20

• Source: RMA-07-RQ-01 (40000-1-2)

5.8-CR-02

For each risk subject to treatment, documentation shall be made of the treatment option selected and the justification for why that option is appropriate given the product context together with the applicable risk acceptance criteria.

Requirement (CR) · obligation: mandatory · PDF page 21

• Source: RMA-07-RQ-02 (40000-1-2)

5.8-CR-03

Following the application of any risk treatment measure, the affected risks shall be reevaluated to determine whether residual risks indeed meet the established acceptance criteria.

Requirement (CR) · obligation: mandatory · PDF page 21

• Source: RMA-07-RQ-03 (40000-1-2)

4.9 Product Cybersecurity Risk Communication

Read section 4.9 in the full text

5.9-CR-01

Risk communication directed at users shall employ language and methods appropriate to the audience; where the audience consists of consumers, the language used shall be clear and free of technical jargon to the extent practicable.

Requirement (CR) · obligation: mandatory · PDF page 22

• Source: RMA-08-RQ-01 (40000-1-2)

5.9-CR-02

Where a product is subject to applicable accessibility obligations or where the intended user base includes individuals with impairments, risk communication shall consider formats and using language to ensure each user can meaningfully access the information.

Requirement (CR) · obligation: mandatory · PDF page 22

• Source: RMA-08-RQ-02 (40000-1-2)

5.9-CR-03

Risk communication documentation shall address a minimum set of elements: the circumstances and foreseeable misuse scenarios that could give rise to significant cybersecurity risks; the mitigation measures users are expected to implement; and the operational conditions under which the product may be used securely.

Requirement (CR) · obligation: mandatory · PDF page 22

• Source: RMA-08-RQ-03 (40000-1-2)

4.10 Product Cybersecurity Risk Review

Read section 4.10 in the full text

5.10-CR-01

Reviews of product cybersecurity risk management activities shall be conducted at planned intervals, where the frequency of those intervals is determined by the risk assessment and the context in which the product operates, and at least once a year - despite design staying the same.

Requirement (CR) · obligation: mandatory · PDF page 23

• Source: RMA-09-RQ-01 (40000-1-2)

Referenced by: 5.10-CR-03

5.10-CR-02

In addition to planned-interval reviews, a review of risk management activities shall be initiated when trigger conditions are met, including product modification, context changes, changes to risk acceptance criteria, changes in cybersecurity risk exposure (including threat landscape changes), identification of a known exploitable vulnerability, occurrence of a severe incident, or obsolescence of a component with cybersecurity impact.

Requirement (CR) · obligation: mandatory · PDF page 23

• Source: RMA-09-RQ-02 (40000-1-2)

Referenced by: 5.10-CR-03

5.10-CR-03

Where a review conducted under 5.10-CR-01 or 5.10-CR-02 reveals that existing risk assessment documentation is affected, the relevant documentation produced under Clause 5 shall be updated accordingly.

Requirement (CR) · obligation: mandatory · PDF page 24

• Source: RMA-09-RQ-03 (40000-1-2)

5.2 Product Cybersecurity Planning

Read section 5.2 in the full text

6.2-CR-01

The product cybersecurity plan shall take the product context from 5.2 into account, when available, and define, at minimum, every applicable cybersecurity activity defined in Clauses 6 and 7.

Requirement (CR) · obligation: mandatory · PDF page 25

6.2-CR-02

Throughout the entire product lifecycle, the product cybersecurity plan shall be kept current through regular maintenance and review, and the execution of all planned activities shall be actively tracked. Review shall take place not only on a regular schedule but also upon occurrence of defined triggers.

Requirement (CR) · obligation: mandatory · PDF page 26

5.3 Product Cybersecurity Requirements

Read section 5.3 in the full text

6.3-CR-01

Product cybersecurity requirements shall be derived from and grounded in the product context, the decisions made regarding treatment of product cybersecurity risks, and all applicable regulatory requirements.

Requirement (CR) · obligation: mandatory · PDF page 26

• Source: CLA-02-RQ-01 (40000-1-2)

6.3-CR-02

Whenever any of the defined inputs - product context, risk assessment outcomes, risk treatment decisions, or applicable regulatory requirements - undergo change, the product cybersecurity requirements shall be reviewed and updated as necessary to remain current and accurate.

Requirement (CR) · obligation: mandatory · PDF page 27

6.3-CR-03

Changes to product cybersecurity requirements shall be communicated to all affected development, testing, and operations teams in a timely and documented manner, with impact assessment by each affected party.

Requirement (CR) · obligation: mandatory · PDF page 27

5.4 Cybersecurity Architecture and Design

Read section 5.4 in the full text

6.4-CR-01

A specification of the product's cybersecurity architecture and design shall be produced. This specification shall include the selection of cybersecurity controls chosen to satisfy the cybersecurity requirements established in 6.3.

Requirement (CR) · obligation: mandatory · PDF page 28

• Source: CLA-03-RQ-01 (40000-1-2)

5.5 Secure Implementation

Read section 5.5 in the full text

6.5-CR-01

The product shall be developed and maintained securely by using a secure development environment to prevent unauthorized access, to an extent appropriate given the product's risk profile, design, and scope. This shall be demonstrated by including the development environment in the scope of the provider’s Information Security Management System certified against ISO/IEC 27001 by an accredited certification body.

Requirement (CR) · obligation: mandatory · PDF page 29

• Source: CLA-04-RQ-01(40000-1-2), SOTA (27001 for this security level)

6.5-CR-02

The product shall implement all cybersecurity requirements established in 6.3, in conformance with the cybersecurity architecture and design defined in 6.4.

Requirement (CR) · obligation: mandatory · PDF page 29

• Source: CLA-04-RQ-02 (40000-1-2)

6.5-CR-03

A documented secure coding standard shall be adopted and enforced, applicable to the programming languages and frameworks used in the mobile application, covering at minimum: prohibited functions, memory safety practices, input validation, output encoding, error handling, preventing common security weaknesses, and prohibition of hard-coded credentials.

Requirement (CR) · obligation: mandatory · PDF page 29

• Source: SOTA and guidance

6.5-CR-04

A process shall be established for identifying, reviewing, and approving the use of memoryunsafe programming languages or constructs in the mobile application, and shall document the rationale and compensating controls where their use cannot be avoided.

Requirement (CR) · obligation: mandatory · PDF page 30

6.5-CR-05

Where secure implementation activities produce deviations from the cybersecurity architecture and design, reviews shall be triggered of the cybersecurity risk management activities, as defined in 5.10 and all affected cybersecurity product lifecycle activities.

Requirement (CR) · obligation: mandatory · PDF page 30

• Source: CLA-04-RQ-06 (40000-1-2)

6.5-CR-06

The product shall use cryptographic mechanisms that reflect the state of the art and that conform to the cryptographic requirements applicable to the product and agreed within its certification, regulatory, or sectoral context - covering the selection of algorithms, parameters, key sizes, operational modes, random number generation, key lifecycle management, and the deprecation policy. Where the applicable requirements do not designate a specific cryptographic reference, the agreed cryptographic mechanisms defined in the ECCG “Agreed Cryptographic Mechanisms” (ACM) shall be used as the recognised baseline. Where the product is subject to a European Digital Identity Wallet certification scheme or to the EUCC, the applicable ACM version is the one required by that scheme (via the EUCC “Guidelines on Cryptography”) at the time of the conformity assessment or surveillance evaluation; versions issued as drafts or for public review are excluded until adopted. Where the applicable requirements or the ACM do not address a specific mechanism, equivalent state-of-the-art cryptographic guidance shall be applied. Continued conformity as the applicable requirements or the applicable ACM version evolve shall be maintained in accordance with 6.5-CR-09.

Requirement (CR) · obligation: mandatory · PDF page 30

• Legal references: EUCC

6.5-CR-07

The product shall protect cryptographic keys through secure hardware modules. If hardwarebased protection is not feasible, the product shall use secure software modules to protect cryptographic keys.

Requirement (CR) · obligation: mandatory · PDF page 32

• Source: REQ-CON-003 (40000-10)

6.5-CR-08

A process shall be established for inventorying and verifying all locations in the mobile application and its RDPS where cryptographic keys are generated, stored, used, and destroyed. Verification shall ensure that each location meets the cryptographic requirements in this document.

Requirement (CR) · obligation: mandatory · PDF page 32

• Source: SOTA

6.5-CR-09

A process shall be established for periodically reviewing the protocol inventory (see technical documentation in 6.6) against current state-of-the-art guidance and for identifying protocols that have been deprecated, are vulnerable, or require compensating measures in accordance with 6.5-CR-10.

Requirement (CR) · obligation: mandatory · PDF page 32

Referenced by: 6.5-CR-06

6.5-CR-10

When the product relies on legacy or vulnerable protocols, the product shall implement security measures mitigating protocol issues - such as, but not limited to, multi-factor authentication - sufficient to maintain a security level commensurate with the risks introduced by those protocols.

Requirement (CR) · obligation: mandatory · PDF page 33

• Source: REQ-EMM-002 (40000-10)

Referenced by: 6.5-CR-09

5.6 Technical Product Documentation

Read section 5.6 in the full text

6.6-CR-01

The product shall maintain an identified list of all integrated components including at least the top-level dependencies and the transitive dependencies when technically feasible, in a commonly used machine-readable format. This is referred to as an SBOM (Software Bill Of Materials). A list entry shall include the type of dependency, software producer, unique component identifier (e.g. producer, component name, and component version). The SBOM shall contain the identity of the SBOM author, a version indicator, and a timestamp. When integrating third-party components, the intended purpose and user instructions to address cybersecurity risks of those components are the conditions that shall be adhered to.

Requirement (CR) · obligation: mandatory · PDF page 34

6.6-CR-02

A mapping of upstream dependencies and interdependencies, apart from components, shall be available to support coordination and notification when a vulnerability is discovered, so that related issues can be resolved without undue delay. In case the application employs AI models, any externally supplied element for this employment shall be part of this mapping, including third-party models, training data, augmentation data, MCP servers and agentic skills.

Requirement (CR) · obligation: mandatory · PDF page 35

6.6-CR-03

If a new software build or release is created, or if an inaccuracy is found in the current SBOM, a revised SBOM shall be issued.

Requirement (CR) · obligation: mandatory · PDF page 35

6.6-CR-04

Technical documentation and user instructions shall be written in language easily understood by the user and shall include at least: a) documentation of all logical and physical interfaces and transport protocols with their security properties; b) cybersecurity prerequisites for the deployment environment; c) a description of implemented security functions; d) usage instructions covering installation and hardening; e) data deletion and decommissioning procedures; and f) detailed configuration and maintenance instructions. These topics shall at least cover when applicable: configuration baselines, safe defaults, backup and restore, patching and updating, key rotation, log management including synchronization of time, incident response hooks, and interactions with platform security services (iOS Keychain, Android Keystore, biometric APIs, app sandboxing).

Requirement (CR) · obligation: mandatory · PDF page 36

6.6-CR-05

The product's technical documentation shall provide a detailed specification of all cryptographic mechanisms employed, including the algorithms used, their parameters, key sizes, operational modes, random generation methods, key lifecycle management, and policy of deprecation.

Requirement (CR) · obligation: mandatory · PDF page 37

• Source: REQ-CON-001(40000-10)

6.6-CR-06

The product's technical documentation shall include an artefact - such as a coverage matrix - that explicitly links each identified risk to the security function or functions that address it.

Requirement (CR) · obligation: mandatory · PDF page 38

• Source: REQ-SBD-002 (40000-10)

5.7 Cybersecurity Verification and Validation

Read section 5.7 in the full text

6.7-CR-01

Verification and validation shall take key elements as input:

• the product implementation including relevant hardware, software, and remote data processing solutions;
• the technical documentation, together with user information and instructions;
• the cybersecurity requirements;
• the product cybersecurity context including relevant information about use from for example customer input and support cases;
• the cybersecurity state-of-the art as described in publications, standards, and guidelines;
• the evolving threat landscape applicable to the product, including information on vulnerabilities found in similar products including components.

Requirement (CR) · obligation: mandatory · PDF page 38

6.7-CR-02

The cybersecurity verification and validation process shall confirm that the product is sufficiently secure, meaning it satisfies the cybersecurity requirements established in 6.3 and the levels of the identified risks (see 5.5) meet the acceptance criteria (see 5.3).

Requirement (CR) · obligation: mandatory · PDF page 39

6.7-CR-03

Threat scenarios and attack profiles shall be defined, documented, and used as the basis for validation testing, derived from the applicable attack potential level (e.g., AVA_VAN level), the risk assessment and the product's cybersecurity context . Each validation testing cycle, these shall be reviewed. The validation testing shall include advanced penetration testing calibrated to the goal, and specialized techniques - including where applicable protocol robustness testing, deep fuzzing, verification of hardened configurations, testing of secure boot/attestation, assessment of hardware key protection, and verifying supply chain integrity. A process for conducting these penetration tests shall be defined including: the scope of testing (including the mobile client, associated RDPS, and communication channels), the minimum qualifications required of testers, the testing methodology to be followed, and the criteria for determining when re-testing is required following remediation.

Requirement (CR) · obligation: mandatory · PDF page 39

6.7-CR-04

The V&V process shall validate that all cybersecurity risks associated with integrated components - including third-party software - have been identified and adequately addressed in the product's implemented design.

Requirement (CR) · obligation: mandatory · PDF page 40

• Source: CLA-05-RQ-05 (40000-1-2)

6.7-CR-05

A process shall be established for assessing supply chain integrity as part of cybersecurity V&V, including verification that the application binary and its dependencies are built from verified sources, that the build pipeline is protected against tampering, and that the deployed artefact matches the verified build output.

Requirement (CR) · obligation: mandatory · PDF page 40

• Source: SOTA

6.7-CR-06

Where appropriate to the product's design, risk assessment, and cybersecurity context, the V&V process shall encompass key elements: artefact analysis including architecture review, error-handling and input validation, external interface and protocol assessment (including deprecation and encryption/integrity checks), additional security testing, documentation review, and risk treatment alignment verification. See guidance for these key elements.

Requirement (CR) · obligation: mandatory · PDF page 41

6.7-CR-07

A process shall be established for selecting, configuring, and maintaining static application security testing (SAST) tools and dynamic application security testing (DAST) tools appropriate for the mobile platform(s) in scope (iOS, Android, or cross-platform), and the rationale for tool selection relative to the product's technology stack and cybersecurity requirements shall be documented.

Requirement (CR) · obligation: mandatory · PDF page 42

6.7-CR-08

Products shall undergo code review conducted by suitably qualified reviewers who are independent of the code's authors; the review scope shall encompass at least misuse patterns and all critical findings shall be remediated prior to release.

Requirement (CR) · obligation: mandatory · PDF page 42

• Source: REQ-KEV-010 (40000-10)

6.7-CR-09

The V&V process shall document and identify all test methods and selected test tools for cybersecurity V&V activities, including the rationale for their selection relative to the product's risk profile and design, and any deviations from the planned test scope together with their justification.

Requirement (CR) · obligation: mandatory · PDF page 43

6.7-CR-10

Cybersecurity V&V activities shall recur throughout the product lifecycle in alignment with the vulnerability management activities described in 6.9 and shall not be limited to final development stages. For this purpose, a documented schedule for recurring cybersecurity V&V activities shall be established that specifies, at minimum, the trigger conditions for re-testing (e.g., new release, significant code change, newly disclosed vulnerability affecting a component, change in threat landscape) and the V&V activities required for each trigger type.

Requirement (CR) · obligation: mandatory · PDF page 43

6.7-CR-11

A security test and review plan shall be developed that is grounded in the product's context, its cybersecurity architecture and design, the defined cybersecurity requirements for the product, the results of the risk assessment, and the results of tests and reviews. The plan shall define what tests and reviews are to be performed, what methodologies to apply, how often, and at what intervals, calibrated to the risk profile associated with the product's intended use.

Requirement (CR) · obligation: mandatory · PDF page 44

5.8 Secure Production and Distribution

Read section 5.8 in the full text

6.8-CR-01

Software products and software updates that are distributed as software images or other distribution artefacts shall be protected against manipulation throughout the entire distribution lifecycle, covering both network transit and storage at rest. For this purpose, a documented build and release pipeline shall be maintained, including automated integrity controls and verification at defined points in the pipeline, including compilation, packaging, signing (conformant to 6.8-CR-05), and release or upload to the distribution channel.

Requirement (CR) · obligation: mandatory · PDF page 44

6.8-CR-02

Where justified by the product's risk assessment and cybersecurity context, the production and distribution activities for digital software products shall incorporate access authentication.

Requirement (CR) · obligation: mandatory · PDF page 45

• Source: CLA-06-RQ-02 without the authenticity overlap already covered in CLA-06-RQ-01 (40000-1-2)

6.8-CR-03

Where applicable, user-facing information and instructions distributed digitally shall be protected against manipulation or unauthorized disclosure during distribution, including protection of the communication channels through which they are delivered.

Requirement (CR) · obligation: mandatory · PDF page 45

• Source: CLA-06-RQ-03 (40000-1-2)

6.8-CR-04

Where applicable, information and instructions intended for the user shall be delivered and presented in a manner that is accessible to the intended user population.

Requirement (CR) · obligation: mandatory · PDF page 46

• Source: CLA-06-RQ-04 (40000-1-2)

6.8-CR-05

A code-signing process shall be established and maintained for mobile application distribution artefacts that defines:

• the lifecycle management of signing credentials, including Android signing keys/keystores and iOS distribution certificates and provisioning profiles, as applicable;
• the roles authorized to approve and perform signing operations; and
• the conditions under which signing is permitted. Signing keys used for Android (keystore) or iOS (provisioning profiles and certificates) shall be stored in a secrets management system (e.g. HashiCorp Vault, AWS Secrets Manager) and not in the repository.

Requirement (CR) · obligation: mandatory · PDF page 46

• Source: SOTA

Referenced by: 6.8-CR-01

6.8-CR-06

Multi-factor authentication (MFA) and role-based access controls shall be enforced for all accounts with the ability to publish, update, or manage mobile application releases on distribution platforms (e.g. Google Play Console, Apple App Store Connect), and an access review process shall be maintained for these accounts.

Requirement (CR) · obligation: mandatory · PDF page 46

6.8-CR-07

The product shall be made identifiable by recording, at minimum, the manufacturer's name, the product name, and a version for recognizability and traceability to support for example vulnerability handling, down-stream software bill of materials (SBOM) generation and verification, and vulnerability information sharing and reporting.

Requirement (CR) · obligation: mandatory · PDF page 47

• Source: PRE-6-RQ-01 (40000-1-3) – with version made mandatory

6.8-CR-08

A communication mechanism shall be provided through which security-related information - including advisories, release notes, installation guidance, and notifications - is made available for the product.

Requirement (CR) · obligation: mandatory · PDF page 47

• Source: PRE-10-RQ-02 (40000-1-3)

6.8-CR-09

Where the product type, connectivity, and operational context make it feasible, a mechanism enabling security updates to be distributed automatically or semi-automatically shall be provided.

Requirement (CR) · obligation: mandatory · PDF page 47

• Source: PRE-10-RQ-03 (40000-1-3)

5.9 Product Cybersecurity Monitoring and Issue Management

Read section 5.9 in the full text

6.9-CR-01

Periodic procedures, automated where possible, shall be performed for monitoring of internal and external information that may affect the product's risk assessment as defined in 5.4 to 5.7, covering at least cybersecurity incidents and vulnerabilities, at intervals that are justifiable given the product context. Documentation shall include activities, frequency, sources, and the roles responsible for execution and review.

Requirement (CR) · obligation: mandatory · PDF page 48

6.9-CR-02

The risks of verified cybersecurity incidents, changes in the threat landscape, and discovered vulnerabilities shall be assessed aligned with the risk assessment methodology established under 5.4 to 5.7.

Requirement (CR) · obligation: mandatory · PDF page 49

6.9-CR-03

Upon discovery of a new vulnerability, documentation of that vulnerability shall be produced and communicated to relevant parties where the risk assessment and cybersecurity context make such communication appropriate.

Requirement (CR) · obligation: mandatory · PDF page 49

• Source: CLA-08-RQ-04 (40000-1-2)

6.9-CR-04

Verified cybersecurity incidents and discovered vulnerabilities shall be treated in a timely manner, with the urgency and nature of treatment proportionate to the risk assessment outcome and the specific cybersecurity context of the product.

Requirement (CR) · obligation: mandatory · PDF page 49

• Source: CLA-08-RQ-05 (40000-1-2)

6.9-CR-05

Where cybersecurity incident or vulnerability have residual risk, that risk shall be communicated to stakeholders using the communication processes and channels established under Clause 5.9, where relevant.

Requirement (CR) · obligation: mandatory · PDF page 49

• Source: CLA-08-RQ-06 (40000-1-2)

6.9-CR-06

At a minimum, the following designated internal and external sources shall be drawn upon when monitoring for vulnerabilities: the EU Vulnerability Database, externally reported vulnerabilities, outputs from regular testing, and regular review activities.

Requirement (CR) · obligation: mandatory · PDF page 50

• Source: RCP-2-RQ-02 (40000-1-3)

5.10 Secure Decommissioning

Read section 5.10 in the full text

6.10-CR-01

Secure decommissioning shall be prepared by identifying cybersecurity aspects of decommissioning, all confidential assets requiring deletion and their location, establishing appropriate actions for any third-party-operated components, defining the method of user communication and what that communication needs to include, and documenting all manufacturer-side activities required to achieve secure decommissioning.

Requirement (CR) · obligation: mandatory · PDF page 50

• Source: CLA-09-RQ-01 (40000-1-2)

6.10-CR-02

Where user-facing decommissioning instructions are required, those instructions shall address, as applicable: removal and export of user data, removal of security-relevant configuration data, disconnection from the operational environment, secure disposal of the product, and advance notice of any automated data deletion including its scope and timing.

Requirement (CR) · obligation: mandatory · PDF page 51

• Source: CLA-09-RQ-02 (40000-1-2)

5.11 Third-Party Component Cybersecurity Management

Read section 5.11 in the full text

6.11-CR-01

Before selecting and integrating any third-party component into a product, due diligence shall be carried out on a number of aspects when applicable. This shall include verifying alignment of the component's intended purpose with its planned use in the product, confirming the absence of known vulnerabilities, and determining whether additional cybersecurity testing is needed. For commercial components, the availability of CE marking and an EU Declaration of Conformity shall be checked. For FOSS components, assessment shall be performed of maintenance activity, availability of a vulnerability disclosure process, stewardship by a recognized organization, evidence of cybersecurity-by-design practices, and availability of security updates. In addition, license obligations shall be identified, documented, and managed prior to integration and throughout the component lifecycle.

Requirement (CR) · obligation: mandatory · PDF page 52

6.11-CR-02

Both the third-party component itself and the manner in which it is integrated into the product shall be addressed within the risk assessment and risk treatment activities required by Clause 5.

Requirement (CR) · obligation: mandatory · PDF page 52

• Source: CLA-10-RQ-02 (40000-1-2)

6.11-CR-03

Third-party components and their integration into the product shall be included in verification and validation specified in clause 6.7.

Requirement (CR) · obligation: mandatory · PDF page 52

• Source: CLA-10-RQ-04 (40000-1-2)

6.11-CR-04

Ongoing monitoring of third-party components shall be maintained for the duration of the product's lifecycle, so that vulnerabilities relevant to the product can be identified, in line with the monitoring activities set out in clause 6.9. This is a continuous obligation and does not end once initial integration is complete.

Requirement (CR) · obligation: mandatory · PDF page 53

• Source: CLA-10-RQ-05 (40000-1-2)

6.11-CR-05

Where a vulnerability is discovered in a commercial third-party component, the vulnerability shall be documented, disclosed to the responsible third-party, and remediated following the applicable vulnerability disclosure and handling procedures. The responsible third-party may be a supplier, service provider, or any party capable of facilitating handling of the vulnerability.

Requirement (CR) · obligation: mandatory · PDF page 53

• Source: CLA-10-RQ-06 (40000-1-2)

6.11-CR-06

Where the manufacturer discovers a vulnerability in a FOSS component and develops a fix, that fix shall be communicated to the open-source project concerned. Where it is possible to do so, the fix shall also be contributed upstream to the original project, under the terms of the applicable source code license.

Requirement (CR) · obligation: mandatory · PDF page 53

• Source: CLA-10-RQ-07 (40000-1-2)

6.11-CR-07

Third-party component suppliers shall be assessed for maintenance activity (level of support or having reached end-of-support) on an annual basis. A documented policy shall be established and maintained to define the maximum permissible period between the public disclosure of a vulnerability in a third-party component and the release of a remediated version or the implementation of an accepted compensating control, differentiated by vulnerability severity. If a supplier fails to meet the timeframe or support is below the documented threshold, a risk assessment shall be performed on the potential consequences of this support issue, which may lead to eventually deprecating the corresponding component(s).

Requirement (CR) · obligation: mandatory · PDF page 53

6.1 Operational Security of Vulnerability Handling

Read section 6.1 in the full text

7.1-CR-01

Operational security measures shall be maintained across all activities involving the receipt and communication of vulnerability information or reports.

Requirement (CR) · obligation: mandatory · PDF page 55

7.1-CR-02

Access to vulnerability information shall be restricted, when it has not yet been publicly disclosed, where applicable, to only those individuals who require it in order to fulfil their responsibilities within the vulnerability handling process.

Requirement (CR) · obligation: mandatory · PDF page 55

• Source: PRE-3-RQ-01 (40000-1-3)- but access restriction made mandatory instead of considered

6.2 Facilities for Vulnerability Handling

Read section 6.2 in the full text

7.2-CR-01 — A vulnerability handling policy shall be established, implemented, and followed.

A vulnerability handling policy shall be established, implemented, and followed.

Requirement (CR) · obligation: mandatory · PDF page 56

• Source: PRE-1-RQ-01 (40000-1-3)

7.2-CR-02

The vulnerability handling policy shall describe the organization’s overall direction, principles, and responsibilities for handling potential vulnerabilities in products; set out how information about those vulnerabilities will be safeguarded against disclosure before remediation is available; establish a planned timeframe for remediation development; and explain the approach to the regular testing and review activities defined in 6.7.

Requirement (CR) · obligation: mandatory · PDF page 56

• Source: PRE-1-RQ-02 (40000-1-3)

7.2-CR-03 — Continuous monitoring shall be in place whether the vulnerability handling process is operating effectively.

Continuous monitoring shall be in place whether the vulnerability handling process is operating effectively.

Requirement (CR) · obligation: mandatory · PDF page 57

• Source: PRE-1-RQ-03 (40000-1-3)

7.2-CR-04

The vulnerability handling policy shall support all activities defined in the vulnerability disclosure policy described in 7.3

Requirement (CR) · obligation: mandatory · PDF page 57

• Source: PRE-1-RQ-05 (40000-1-3)

7.2-CR-05

A documented process shall be established for evaluating, approving, and recording decisions to delay full vulnerability publication under the conditions specified in 7.7-CR-05, including defined criteria for the risk evaluation, designated approval authority, maximum permissible delay duration, and a procedure for communicating the disclosure date to affected users of the mobile application.

Requirement (CR) · obligation: mandatory · PDF page 57

• Source: SOTA

6.3 Coordinated Vulnerability Disclosure Facilities

Read section 6.3 in the full text

7.3-CR-01

A coordinated vulnerability disclosure policy shall be established, implemented, followed, and made publicly available in an accessible form

Requirement (CR) · obligation: mandatory · PDF page 58

• Source: PRE-2-RQ-01 (40000-1-3)

7.3-CR-02

The CVD policy shall include contact mechanisms accessible through multiple sensory modalities, ensuring users with diverse impairments are not excluded.

Requirement (CR) · obligation: mandatory · PDF page 58

• Source: PRE-2-RC-01 (40000-1-3)

Referenced by: 7.3-CR-09

7.3-CR-03

The CVD policy shall explicitly set out what parties can expect with respect to ongoing communication throughout the vulnerability disclosure process.

Requirement (CR) · obligation: mandatory · PDF page 59

• Source: PRE-2-RQ-03 (40000-1-3)

7.3-CR-04

The CVD policy shall address each of the following areas: the expected contents of a vulnerability report; options for secure communication; the scope of the program; publication arrangements; and recognition of reporters.

Requirement (CR) · obligation: mandatory · PDF page 59

• Source: PRE-2-RC-02 (40000-1-3)

7.3-CR-05

A disclosure process shall be established so that details about a vulnerability are not made public until the vulnerability has been remediated.

Requirement (CR) · obligation: mandatory · PDF page 59

• Source: PRE-2-RC-03 (40000-1-3)

7.3-CR-06 — Secure communication mechanisms for vulnerability disclosure shall be made known to reporters and stakeholders.

Secure communication mechanisms for vulnerability disclosure shall be made known to reporters and stakeholders.

Requirement (CR) · obligation: mandatory · PDF page 60

• Source: PRE-5-RQ-01-RE (40000-1-3)

7.3-CR-07

The vulnerability reporting process shall include an option that allows reporters to submit information without disclosing their identity.

Requirement (CR) · obligation: mandatory · PDF page 60

• Source: PRE-5-RC-03 (40000-1-3)

7.3-CR-08

Security controls applied to communication channels shall not create unreasonable barriers that prevent external parties from contacting the organization.

Requirement (CR) · obligation: mandatory · PDF page 60

• Source: PRE-5-RC-04 (40000-1-3)

7.3-CR-09

A public reporting channel shall be made available, using the accessible methods specified in 7.3-CR-02, so that vulnerability information or reports can be received.

Requirement (CR) · obligation: mandatory · PDF page 60

7.3-CR-10

A system for assigning and maintaining identifiers or tracking numbers to reported vulnerabilities shall be implemented to support ongoing traceability of each report.

Requirement (CR) · obligation: mandatory · PDF page 61

• Source: RCP-1-RQ-02 (40000-1-3)

7.3-CR-11

Receipt shall be confirmed of a potential vulnerability report to the reporter within a response window that is defined and published as part of the coordinated vulnerability disclosure policy.

Requirement (CR) · obligation: mandatory · PDF page 61

• Source: RCP-1-RQ-03 (40000-1-3)

7.3-CR-12

Vulnerability reports submitted through channels that do not meet the security standards described in 7.1 should still be accepted rather than rejected on the basis of the submission method alone.

Requirement (CR) · obligation: mandatory · PDF page 61

• Source: RCP-1-RC-01 (40000-1-3)

6.4 Intake in Vulnerability Handling

Read section 6.4 in the full text

7.4-CR-01

Where a vulnerability report does not contain enough detail to support assessment, the necessary additional information shall be requested from the reporter.

Requirement (CR) · obligation: mandatory · PDF page 62

• Source: VRF-1-RQ-01 (40000-1-3)

7.4-CR-02 — A structured triage of each reported vulnerability shall be performed.

A structured triage of each reported vulnerability shall be performed.

Requirement (CR) · obligation: mandatory · PDF page 62

• Source: VRF-1-RQ-02 (40000-1-3)

7.4-CR-03 — Risk resulting from the vulnerability shall be evaluated aligned with the methodology specified in 5.4 to 5.7.

Risk resulting from the vulnerability shall be evaluated aligned with the methodology specified in 5.4 to 5.7.

Requirement (CR) · obligation: mandatory · PDF page 63

7.4-CR-04

Each vulnerability shall be assigned a handling priority, derived from both the risk evaluation result and the risk profile specific to the product.

Requirement (CR) · obligation: mandatory · PDF page 63

• Source: VRF-2-RQ-02 (40000-1-3)

7.4-CR-05

If the assessed risk level of a vulnerability surpasses the manufacturer's defined risk threshold, the vulnerability resolution process shall be expedited.

Requirement (CR) · obligation: mandatory · PDF page 63

• Source: VRF-2-RQ-03 (40000-1-3)

7.4-CR-06

When a vulnerability has been reported through a coordinated disclosure process, the originating reporter shall be notified of the outcome of the intake activity, if possible.

Requirement (CR) · obligation: mandatory · PDF page 64

• Source: VRF-2-RQ-04 (40000-1-3)

6.5 Communication with Stakeholders in Vulnerability Handling

Read section 6.5 in the full text

7.5-CR-01

Communication with reporters and all relevant stakeholders shall be initiated and sustained throughout the vulnerability handling process.

Requirement (CR) · obligation: mandatory · PDF page 64

7.5-CR-02

When communicating with users, communication channels and formats shall be employed that are accessible to a broad range of users.

Requirement (CR) · obligation: mandatory · PDF page 65

• Source: PRE-4-RQ-02 (40000-1-3)

6.6 Remediation in Vulnerability Handling

Read section 6.6 in the full text

7.6-CR-01

A formal remediation decision shall be made and documented for each identified vulnerability, determining the course of action to address it.

Requirement (CR) · obligation: mandatory · PDF page 65

7.6-CR-02

Following the remediation decision, a concrete action plan shall be established that specifies what steps will be taken and sets a defined timeline for their completion.

Requirement (CR) · obligation: mandatory · PDF page 66

7.6-CR-03

Once a decision to remediate a vulnerability has been made, the necessary activities shall be carried out to produce that remediation.

Requirement (CR) · obligation: mandatory · PDF page 66

• Source: RMD-2-RQ-01 (40000-1-3)

7.6-CR-04

Where it is technically feasible to do so, security updates shall be delivered independently of functional updates, rather than bundled together.

Requirement (CR) · obligation: mandatory · PDF page 66

• Source: RMD-2-RQ-02 (40000-1-3)

7.6-CR-05

Any remediation applied to address a vulnerability shall undergo testing to confirm that the associated risk has been adequately reduced and that no unacceptable adverse effects on the product or its users have been introduced.

Requirement (CR) · obligation: mandatory · PDF page 67

• Source: RMD-3-RQ-01 (40000-1-3)

6.7 Release of Security Updates and Information in Vulnerability Handling

Read section 6.7 in the full text

7.7-CR-01

Security updates shall be made available at no cost, except where a manufacturer and a business user have explicitly agreed otherwise for a purpose-built product with digital elements.

Requirement (CR) · obligation: mandatory · PDF page 68

• Source: RLS-1-RQ-01 (40000-1-3)

7.7-CR-02 — After a security update has been made ready, it shall be released to users without undue delay.

After a security update has been made ready, it shall be released to users without undue delay.

Requirement (CR) · obligation: mandatory · PDF page 68

• Source: RLS-1-RQ-02 (40000-1-3)

7.7-CR-03

Where the delivery of a security update is not entirely automated, clear installation instructions shall be supplied to users.

Requirement (CR) · obligation: mandatory · PDF page 68

• Source: RLS-1-RQ-03 (40000-1-3)

7.7-CR-04

After a vulnerability has been resolved, information shall be provisioned in line with the coordinated vulnerability disclosure (CVD) policy established under 7.3; where suitable, such information may be presented in summarized or aggregated form, in a format readable by humans, in a widely recognized machine-readable format, and include, as a minimum, the following elements to allow recipients to assess relevance and take appropriate remediation action:

• a description of the vulnerability
• a vulnerability identifier
• information sufficient to identify the affected product
• the potential impact of the vulnerability
• the severity of the vulnerability
• detailed remediation instructions
• the date of release and any subsequent update date

Requirement (CR) · obligation: mandatory · PDF page 69

7.7-CR-05

Complete publication of vulnerability information shall be deferred in order to allow adequate time for security update distribution, in case all three of the following conditions are simultaneously satisfied:

• the risks associated with full disclosure outweigh its security benefits at that time.
• Sufficient information about the resolved vulnerability is made available to users in a manner that does not enable an attacker to exploit it.
• Users are notified of the scheduled date on which all vulnerability information will be publicly disclosed.

Requirement (CR) · obligation: mandatory · PDF page 70

Referenced by: 7.2-CR-05

7.7-CR-06

Following the release of a remediation, post-release activities shall be executed that encompass maintaining the vulnerability case record and tracking the effectiveness of the applied remediation.

Requirement (CR) · obligation: mandatory · PDF page 70

• Source: PRA-1-RQ-01 (40000-1-3)