Skip to main content

NL-CS Part 4 requirements

This page lists every requirement of NL-CS Part 4 (NL-CS Audit Instruction for Operational Processes, 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.

24 entries: 24 audit criteria. Obligation: 24 mandatory.

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

4.1 Version control (VC)​

Read section 4.1 in the full text

VC1​

Every release of the certified Wallet Instance is uniquely identified by application identifier, version name, version code and build or release identifier, and these match the identifiers on the functional certificate and in the FIT ST.

Audit criterion · obligation: mandatory · PDF page 8

  • Source: [NP001] 6.2, 6.2.1

VC2​

The source code and build configuration of every release are held under version control with traceable history and controlled access, so that the delivered package can be related to a source revision.

Audit criterion · obligation: mandatory · PDF page 8

  • Source: [proposed]; supports [NP001] Annex C items 1 to 5

VC3​

The signing key and the signing process are controlled, and a change of the signing key is notified to the CB before it is used.

Audit criterion · obligation: mandatory · PDF page 8

  • Source: [NP001] 6.6 (signing key change)

VC4 — The list of third-party components, libraries and SDKs per release is maintained.​

The list of third-party components, libraries and SDKs per release is maintained.

Audit criterion · obligation: mandatory · PDF page 8

  • Source: [proposed]; [NP001] Annex C item 6

4.2 Change management (CM)​

Read section 4.2 in the full text

CM1 — Planned changes to the certified product are notified to the CB before implementation.​

Planned changes to the certified product are notified to the CB before implementation.

Audit criterion · obligation: mandatory · PDF page 8

  • Source: [NP001] 3.4; [NP002] 7.4

CM2​

Every change is recorded with a description of all differences, not only those the developer considers security relevant, so that a delta assessment is possible.

Audit criterion · obligation: mandatory · PDF page 8

  • Source: [NP001] Annex C item 4

CM3​

Each change is assessed for security impact, including against the list of changes in [NP001] section 6.6 that shall not be concluded as covered without new analysis: the user authentication protocol or factors, the interface with the WSCA-BE or WSCD, key handling, attestation handling, resilience mechanisms, trusted list and revocation handling, target platform API level, signing key, distribution channel.

Audit criterion · obligation: mandatory · PDF page 8

  • Source: [NP001] 6.6

CM4​

Changes to the TOE boundary, to the assumptions on the operational environment, to the environmental requirements or to the identity or version of a certified component are identified as such and are not treated as covered by delta assessment.

Audit criterion · obligation: mandatory · PDF page 8

  • Source: [NP001] 6.6

CM5​

Changes to the target platform and to the variants for categories of end user devices are tracked, because wallet instances are expected to need frequent updates.

Audit criterion · obligation: mandatory · PDF page 8

4.3 Update delivery (UD)​

Read section 4.3 in the full text

UD1​

The product has a feature to perform updates of each software component, and the update process is described and operated as described.

Audit criterion · obligation: mandatory · PDF page 8

UD2​

Updates are produced from controlled builds, signed with the controlled key, and the integrity and authenticity of an update is verified before installation.

Audit criterion · obligation: mandatory · PDF page 9

  • Source: [proposed]

UD3 — The distribution channel is the one stated in the FIT ST and any change of channel is notified ([NP001] section 6.6).​

The distribution channel is the one stated in the FIT ST and any change of channel is notified ([NP001] section 6.6).

Audit criterion · obligation: mandatory · PDF page 9

  • Source: [NP001] 6.6

UD4​

The time between availability of a security update and its delivery to users, and the share of users on supported versions, are monitored.

Audit criterion · obligation: mandatory · PDF page 9

  • Source: [proposed]

UD5​

The Wallet Instance's mechanism for verifying, per wallet unit, that the platform satisfies the assumptions on the end user device remains effective after updates, including the minimum platform version.

Audit criterion · obligation: mandatory · PDF page 9

4.4 Vulnerability management (VM)​

Read section 4.4 in the full text

VM1​

The product developer has a vulnerability management policy and procedures that take into account [ISO/IEC 30111], and that meet the requirements of Annex I to the Cyber Resilience Act as required by Article 5(7) of [IR 2981].

Audit criterion · obligation: mandatory · PDF page 9

VM2​

Sources of vulnerability information (public databases, dependency advisories, platform security bulletins, researcher reports) are monitored and the monitoring is evidenced.

Audit criterion · obligation: mandatory · PDF page 9

  • Source: [proposed]

VM3 — Each vulnerability is assessed for severity and impact in the context of the certified wallet.​

Each vulnerability is assessed for severity and impact in the context of the certified wallet.

Audit criterion · obligation: mandatory · PDF page 9

  • Source: [NP001] 6.4

VM4​

Critical vulnerabilities and active exploits are notified to the CB within 24 hours of discovery, and high-severity vulnerabilities within 72 hours. Other vulnerabilities and changes are notified within the timeline of the scheme.

Audit criterion · obligation: mandatory · PDF page 9

  • Source: [NP001] 3.4, 6.4

VM5​

A vulnerability impact analysis report is prepared for any vulnerability that affects the software components of the wallet, with the content of Article 5(5), and transmitted to the CB without undue delay.

Audit criterion · obligation: mandatory · PDF page 9

VM6 — Remediation is carried out commensurately with severity and potential impact, with remediation delays recorded.​

Remediation is carried out commensurately with severity and potential impact, with remediation delays recorded.

Audit criterion · obligation: mandatory · PDF page 9

VM7 — Publicly known and remediated vulnerabilities are disclosed and registered in the repositories of Annex V.​

Publicly known and remediated vulnerabilities are disclosed and registered in the repositories of Annex V.

Audit criterion · obligation: mandatory · PDF page 9

4.5 Continued validity of the certification basis (CV)​

Read section 4.5 in the full text

CV1​

The functional certificate remains valid for the certified version, and its suspension, withdrawal or expiry is notified to the CB without undue delay.

Audit criterion · obligation: mandatory · PDF page 10

  • Source: [NP001] 3.4, 6.2

CV2​

The product developer monitors the validity, version and certification status of the WSCD certificate and of other certificates recorded as environmental requirements, and notifies the CB of any change.

Audit criterion · obligation: mandatory · PDF page 10

  • Source: [NP001] 5.4, 6.6

CV3​

The assumptions on the operational environment and the environmental requirements of the Protection Profile remain valid for the lifetime of the certificate.

Audit criterion · obligation: mandatory · PDF page 10

  • Source: [NP001] 2.4