NL-CS-WSCA requirements

This page lists every requirement of NL-CS-WSCA (Protection Profile for WSCA in a remote HSM architecture, version RC1.1) 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.

59 entries: 59 security functional requirements (SFR). Obligation: 59 mandatory.

Legal basis of the document: CIR 2024/2979 Art. 5, CIR 2024/2981, EUCC.

Referenced in the document but not defined in it: FAU_COP.1, FIA_UID.1, FCS_RNG.1, FPT_STM.1, FCS_DRB.2, FCS_DRB.3, FDP_ACC.1/Key_Creation, FDP_ACF.1/Key_Creation, FTP_ITC.1/WSCA, FDP_ITC.1, FDP_ITC.2, FCS_RBG.2, FSC_RBG.3, FCS_RBG.3, FIA_UAU.1, FDP_IFC.1.

6.1 Class FAU — Security Audit

Read section 6.1 in the full text

FAU_GEN.1 — Audit Data Generation

FAU_GEN.1.1: The TSF shall generate an audit record of the following auditable events: a) TOE start-up and shutdown; b) All auditable events for the not specified level of audit; c) each signing operation, including the wallet user identifier; d) authentication failure; e) wallet instance and user lifecycle events (registration, suspension, deprovisioning); f) administrative and management operations (FMT_SMF.1); and g) all self-test results (FPT_TST.1) and secure initialization (FPT_INI.1). h) failures listed in FPT_FLS.1 and FPT_RCV.4. i) warning that audit trail is near full capacity (FAU_STG_EXT.3) j) failing checks related to transaction-bound authentication evidence (FIA_UAE_EXT.1) k) failure of establishing or detected attacks on a secure or trusted channel (FTP_PRO.3/* and FPT_ITC.1/*) l) failure of identification or authentication. m)detection of integrity or authenticity errors in stored user data. n) migration of user key bindings from one wallet user to another by the Wallet Provider o) [assignment: other specifically defined auditable events].
FAU_GEN.1.2: The TSF shall record within the audit data at least the following information: a) Date and time of the auditable event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; b) For each auditable event type, based on the auditable event definitions of the functional components included in the PP, PP-Module, functional package or ST, [assignment: other audit relevant information].

Security functional requirement (SFR) · obligation: mandatory · PDF page 35

FAU_GEN.2 — User identity association

FAU_GEN.2.1: For audit events resulting from actions of identified users, the TSF shall be able to associate each auditable event with the identity of the user that caused the event.

Security functional requirement (SFR) · obligation: mandatory · PDF page 35

FAU_SAR.1 — Audit review

FAU_SAR.1.1: The TSF shall provide Wallet Provider with the capability to read [assignment: list of audit information] from the audit data.
FAU_SAR.1.2: The TSF shall provide the audit data in a manner suitable for the user to interpret the information.

Security functional requirement (SFR) · obligation: mandatory · PDF page 35

FAU_STG_EXT.1 — Protected Audit Event Storage

FAU_STG_EXT.1.1: The TSF shall be able to transmit the generated audit data to an external IT entity.
FAU_STG_EXT.1.2: The TSF shall be able to store generated audit data on the TOE itself.
FAU_STG_EXT.1.3: The TSF shall maintain a [selection: log file, database, buffer, [assignment: other local logging method]] of audit records in the event that an interruption of communication with the remote audit server occurs.
FAU_STG_EXT.1.4: The TSF shall be able to store [selection: persistent, non-persistent] audit records locally with a minimum storage size of [assignment: number of records and/or file/buffer size(s)].
FAU_STG_EXT.1.5: The TSF shall reject remote API requests from Wallet Instances when the local storage space for audit data is full.
FAU_STG_EXT.1.6: The TSF shall ensure the authenticity and integrity of the audit data when stored on an external IT entity or the TOE itself with cryptographic means.

Security functional requirement (SFR) · obligation: mandatory · PDF page 35

FAU_STG_EXT.2 — Counting Lost Audit Data

FAU_STG_EXT.2.1: The TSF shall provide information about the number of dropped audit records the case where the local storage has been filled and the TSF takes one of the actions defined in FAU_STG_EXT.1.5.

Security functional requirement (SFR) · obligation: mandatory · PDF page 36

FAU_STG_EXT.3 — Notification in Case of Possible Audit Data Loss

FAU_STG_EXT.3.1: The TSF shall generate a warning to inform [selection: Wallet Provider, Technical Administrator] before the audit trail exceeds the local audit trail storage capacity.

Security functional requirement (SFR) · obligation: mandatory · PDF page 36

Referenced by: FAU_GEN.1

6.2 Class FCO — Communication

Read section 6.2 in the full text

FCO_NRO.2 — Enforced proof of origin

FCO_NRO.2.1: The TSF shall enforce the generation of evidence of origin for transmitted API requests from the Wallet Instance handled by the TOE at all times.
FCO_NRO.2.2: The TSF shall be able to relate the Wallet Instance identifier of the originator of the information, and the transaction identifier, UTC timestamp of the information to which the evidence applies.
FCO_NRO.2.3: The TSF shall provide a capability to verify the evidence of origin of information to the Wallet Provider given the corresponding audit record is retained by the audit log server.

Security functional requirement (SFR) · obligation: mandatory · PDF page 36

FCO_NRR.2 — Enforced proof of receipt

FCO_NRR.2.1: The TSF shall enforce the generation of evidence of receipt for received API requests from the Wallet Instance handled by the TOE at all times.
FCO_NRR.2.2: The TSF shall be able to relate the session identifier of the recipient of the information, and the Wallet Instance’s certificate, public key or thumbprint and the transaction identifier of the information to which the evidence applies.
FCO_NRR.2.3: The TSF shall provide a capability to verify the evidence of receipt of information to the Wallet Provider given the corresponding audit record is retained by the audit log server.

Security functional requirement (SFR) · obligation: mandatory · PDF page 36

6.3 Class FCS — Cryptographic Support

Read section 6.3 in the full text

FCS_CKM.1 — Cryptographic key generation

FCS_CKM.1.1: The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [assignment: cryptographic key generation algorithm] and specified cryptographic key sizes [assignment: cryptographic key sizes] that meet the following: [assignment: list of standards].

Security functional requirement (SFR) · obligation: mandatory · PDF page 37

FCS_CKM.2 — Cryptographic key distribution

FCS_CKM.2.1: The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method [assignment: cryptographic key distribution method] that meets the following: [assignment: list of standards].

Security functional requirement (SFR) · obligation: mandatory · PDF page 37

FCS_CKM.5 — Cryptographic key derivation

FCS_CKM.5.1: The TSF shall derive cryptographic keys [assignment: key type] from [assignment: input parameters] in accordance with a specified key derivation algorithm [assignment: key derivation algorithm] and specified cryptographic key sizes [assignment: list of key sizes] that meet the following: [assignment: list of standards].

Security functional requirement (SFR) · obligation: mandatory · PDF page 37

FCS_CKM.6 — Timing and event of cryptographic key destruction

FCS_CKM.6.1: The TSF shall destroy all TSF generated and/or maintained keys and key material, including per-key authorisation data when no longer needed, during revocation, deprovisioning, factory reset or authorized deletion is requested.
FCS_CKM.6.2: The TSF shall destroy cryptographic keys and keying material specified by FCS_CKM.6.1 in accordance with a specified cryptographic key destruction method [assignment: cryptographic key destruction method] that meets the following: [assignment: list of standards].

Security functional requirement (SFR) · obligation: mandatory · PDF page 37

FCS_COP.1 — Cryptographic operation

FCS_COP.1.1: The TSF shall perform [assignment: list of cryptographic operations]

Security functional requirement (SFR) · obligation: mandatory · PDF page 38

FCS_RBG.1 — Random bit generation (RBG)

FCS_RBG.1.1: The TSF shall perform deterministic random bit generation services using [assignment: RBG algorithm] in accordance with [assignment: list of standards] after initialization with a seed.
FCS_RBG.1.2: The TSF shall use a [selection: TSF noise source [assignment: name of noise source], TSF interface for seeding] for initialized seeding.
FCS_RBG.1.3: The TSF shall update the RBG state by [selection: reseeding, uninstantiating and re instantiating] using a [selection: TSF noise source [assignment: name of noise source], TSF interface for seeding] in the following situations: [selection: — never; — on demand; — on the condition: [assignment: condition]; — after [assignment: time]] in accordance with [assignment: list of standards].

Security functional requirement (SFR) · obligation: mandatory · PDF page 38

Referenced by: FIA_UAE_EXT.1

6.4 Class FDP — User Data Protection

Read section 6.4 in the full text

FDP_ACC.1/User_Creation — Access Control Policy

FDP_ACC.1.1/User_Creation: The TSF shall enforce the User Creation SFP on - Subject: Wallet Provider or Wallet Instance - Objects: Wallet User - Operations: Create new user The TOE creates a Wallet User with information provided by the subject.

Security functional requirement (SFR) · obligation: mandatory · PDF page 38

FDP_ACF.1/User_Creation — Access control functions

FDP_ACF.1.1/User_Creation: The TSF shall enforce the User Creation SFP to objects based on the following: whether the subject is a Wallet Provider or Wallet Instance authorised to create a new Wallet User.
FDP_ACF.1.2/User_Creation: The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: only a Wallet Provider or Wallet Instance who has been authorised for creation of new users can carry out the operation.
FDP_ACF.1.3/User_Creation: The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none.
FDP_ACF.1.4/User_Creation: The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects].

Security functional requirement (SFR) · obligation: mandatory · PDF page 38

FDP_ACC.1/Key_Management — Access Control Policy

FDP_ACC.1.1/Key_Creation: The TSF shall enforce the Key Creation SFP on - Subject: Wallet Instance - Objects: Asymmetric key pairs or symmetric keys - Operations: Create or delete new key or key pair Wallet Instances instructs the TOE to request the WSCD to generate/delete new keys/key pairs and assigns it to a Wallet User.

Security functional requirement (SFR) · obligation: mandatory · PDF page 39

FDP_ACF.1/Key_Management — Access control functions

FDP_ACF.1.1/Key_Creation: The TSF shall enforce the Key Creation SFP to objects based on the following: the wallet instance is authorised to create, delete a symmetric key or asymmetric key pairs for a Wallet User.
FDP_ACF.1.2/Key_Creation: The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: the wallet instance requesting the creation of the key or key pair is authorised to carry out the operation.
FDP_ACF.1.3/Key_Creation: The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none.
FDP_ACF.1.4/Key_Creation: The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects].

Security functional requirement (SFR) · obligation: mandatory · PDF page 39

FDP_ACC.1/Operation — Access Control Policy

FDP_ACC.1.1/Operation: The TSF shall enforce the Operation SFP on - Subject: Wallet User - Objects: Wallet User user-bound assets (including keys or key pairs) - Operations: (Per-key-authorized) Operations with Wallet User user-bound assets The TOE instructs the WSCD to carry out operations on and with the Wallet Users assets only where it corresponds to an assets within the WSCD-HSM that is bound to the identified Wallet User using per-key-authorization data provided by the wallet instance. - Subject: Wallet User - Objects: Wallet User user-bound assets (including keys or key pairs) - Operations: PIN reset The TOE instructs the WSCD to carry out PIN reset when the correct PUK was provided. - Subject: Wallet User - Objects: Wallet User user bound assets - Operation: Wallet User can clear or delete the Wallet User bound assets or migrate them to a different Wallet Instance. (This does not include the WSCD-stored plaintext private keys, only their reference, keyblobs and management).

Security functional requirement (SFR) · obligation: mandatory · PDF page 39

FDP_ACF.1/Operation — Access control functions

FDP_ACF.1.1/Operation: The TSF shall enforce the Operation SFP to objects based on the following: whether the subject is a Wallet User or Wallet Provider authorised to carry out the operation or resets the PIN using the correct PUK.
FDP_ACF.1.2/Operation: The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: • only an authorized Wallet User is allowed to carry out operations using the keys or key pairs • a Wallet User is only allowed to carry out operations using their user-bound keys. • the authentication evidence is valid and bound to the current transaction. • the identifier of the Wallet User does match the user bound to the key or key pair • the Wallet User is active. • the integrity of all operation related assets was verified. • the Wallet Provider carrying out operations is authorized and authenticated.
FDP_ACF.1.3/Operation: The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none.
FDP_ACF.1.4/Operation: The TSF shall explicitly deny access of subjects to objects based on the following additional rules: any direct key access or key export requests for keys residing in the WSCD shall be denied [assignment: additional rules, based on security attributes, that explicitly deny access of subjects to objects].

Security functional requirement (SFR) · obligation: mandatory · PDF page 39

FDP_RIP.2 — Full residual information protection

FDP_RIP.2.1: The TSF shall ensure that any previous information content of a resource is made unavailable upon the deallocation of the resource from all objects.

Security functional requirement (SFR) · obligation: mandatory · PDF page 40

FDP_SDI.1 — Stored data integrity monitoring

FDP_SDI.1.1: The TSF shall monitor user data stored in containers controlled by the TSF or in its operative environment for integrity or authenticity errors on all objects, based on the following attributes: the integrity and authenticity check value bound to each stored object.

Security functional requirement (SFR) · obligation: mandatory · PDF page 40

Referenced by: FIA_USB.1/Wallet

FDP_SDC.1 — Stored data confidentiality

FDP_SDC.1.1: The TSF shall ensure the confidentiality of the following user data: session keys and WSCA-stored private keys while it is stored in the persistent memory (including the external database).

Security functional requirement (SFR) · obligation: mandatory · PDF page 40

6.5 Class FIA — Identification and Authentication

Read section 6.5 in the full text

FIA_AFL.1/Wallet — Authentication failure handling

FIA_AFL.1.1/Wallet: The TSF shall detect when [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] unsuccessful authentication attempts occur related to the authentication of the wallet user following FIA_UAE_EXT.1.
FIA_AFL.1.2/Wallet: When the defined number of unsuccessful authentication attempts has been met, the TSF shall lock the wallet user and notify the wallet user via an out-of-band notification channel.

Security functional requirement (SFR) · obligation: mandatory · PDF page 40

FIA_AFL.1/Provider — Authentication failure handling

FIA_AFL.1.1/Provider: The TSF shall detect when [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] unsuccessful authentication attempts occur related to the authentication of the wallet provider.
FIA_AFL.1.2/Provider: When the defined number of unsuccessful authentication attempts has been met, the TSF shall [assignment: list of actions]

Security functional requirement (SFR) · obligation: mandatory · PDF page 40

FIA_AFL.1/Instance — Authentication failure handling

FIA_AFL.1.1/Instance: The TSF shall detect when [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] unsuccessful authentication attempts occur related to the authentication of the wallet instance.
FIA_AFL.1.2/Instance: When the defined number of unsuccessful authentication attempts has been met, the TSF shall [assignment: list of actions].

Security functional requirement (SFR) · obligation: mandatory · PDF page 41

FIA_ATD.1/Wallet — User attribute definition

FIA_ATD.1.1/Wallet: The TSF shall maintain the following list of security attributes belonging to individual users: a) wallet instance and wallet user identifier b) the registered Wallet Instance authentication credential, used both for authentication of the communication session and for verification of signatures over User Authentication Evidence c) the Authentication Reference Data against which the knowledge- and possession-based factor of the User Authentication Evidence is verified d) the binding records associating the wallet user with its wrapped key blobs, its attested key pairs and, where the WIA device-binding key pair is managed by the WSCA/WSCD, that key pair e) the per-key authorisation data associated with the wallet user for access to the WSCD-HSM, for the duration of the operation for which it was provided f) the authentication failure counter g) the wallet user status (active / suspended / deprovisioned) h) the integrity check value and version counter bound to the stored attributes of the wallet user i) [assignment: additional user security attributes].

Security functional requirement (SFR) · obligation: mandatory · PDF page 41

Referenced by: FIA_USB.1/Wallet

FIA_ATD.1/Provider — User attribute definition

FIA_ATD.1.1/Provider: The TSF shall maintain the following list of security attributes belonging to individual users: a) the Wallet Provider identifier b) the Wallet Provider authentication reference data c) [assignment: additional provider security attributes]

Security functional requirement (SFR) · obligation: mandatory · PDF page 41

FIA_USB.1/Wallet — User-subject binding

FIA_USB.1.1/Wallet: The TSF shall associate the following user security attributes with subjects acting on the behalf of that user: • the wallet instance and wallet user identifier • the wallet instance and wallet user authentication data • the wallet user status defined in FIA_ATD.1/Wallet • the binding records in FIA_ATD.1.1/Wallet • the per-key authorisation data in FIA_ATD.1.1/Wallet • [assignment: list of user security attributes]
FIA_USB.1.2/Wallet: The TSF shall enforce the following rules on the initial association of user security attributes with subjects acting on the behalf of users: • the wallet instance identifier and the registered Wallet Instance authentication credential shall be associated only after successful identification in accordance with FIA_UID.2 and successful establishment of a trusted channel in accordance with FTP_PRO.2/Wallet • the wallet user identifier, the wallet user status, the binding records and the per-key authorisation data shall be associated only after successful verification of authentication evidence in accordance with FIA_UAE_EXT.1 against the Authentication Reference Data registered for that wallet user • only the attributes of the wallet user for whom the identified wallet instance is registered shall be associated • only the binding records and per-key authorisation data for the keys bound to that wallet user shall be associated • no attribute shall be associated where the wallet user status is other than active • no attribute shall be associated where an integrity or authenticity error has been detected in accordance with FDP_SDI.1 on the stored attributes concerned • [assignment: rules for the initial association of attributes]
FIA_USB.1.3/Wallet: The TSF shall enforce the following rules governing changes to the user security attributes associated with subjects acting on the behalf of users: • the attributes associated under FIA_USB.1.2/Wallet • shall remain associated only for the operation for which the authentication evidence was verified, and shall be dissociated on completion of that operation or on expiry of the validity window of that evidence, whichever occurs first; • no associated attribute shall be modified at the request of the subject; • the authentication failure counter may change as a result of FIA_AFL.1; • a change of the wallet user status to suspended or deprovisioned shall take effect immediately and shall cause dissociation of all attributes associated with subjects acting on behalf of that wallet user; • a change to the binding records or to the per-key authorisation data shall take effect on the next association only. • [assignment: rules for the changing of attributes].

Security functional requirement (SFR) · obligation: mandatory · PDF page 41

Referenced by: FMT_MSA.1/User_Creation, FMT_MSA.1/Key_Management, FMT_MSA.1/Operation, FMT_MSA.2

FIA_USB.1/Provider — User-subject binding

FIA_USB.1.1/Provider: The TSF shall associate the following user security attributes with subjects acting on the behalf of that user: • the wallet provider identifier • the wallet provider authentication data • [assignment: list of user security attributes]
FIA_USB.1.2/Provider: The TSF shall enforce the following rules on the initial association of user security attributes with subjects acting on the behalf of users: • attributes shall be associated only after successful identification in accordance with FIA_UID.2 and successful establishment of a trusted channel in accordance with FTP_PRO.2/Provider. • only the attributes of the Wallet Provider identified by the presented credential shall be associated; • only the role and the management functions for which that Wallet Provider is authorised shall be associated.
FIA_USB.1.3/Provider: The TSF shall enforce the following rules governing changes to the user security attributes associated with subjects acting on the behalf of users: • no associated attribute shall change for the duration of the association; • revocation or modification of the Wallet Provider authentication reference data shall cause dissociation of all attributes associated with subjects acting on its behalf; • a change to the role or to the permitted management functions shall take effect on the next association only

Security functional requirement (SFR) · obligation: mandatory · PDF page 42

Referenced by: FMT_MSA.2

FIA_UAU.2 — User authentication before any action

FIA_UAU.2.1: The TSF shall require each user to be successfully authenticated before allowing any other TSF mediated actions on behalf of that user.

Security functional requirement (SFR) · obligation: mandatory · PDF page 43

FIA_UAU.6 — Re-authenticating

FIA_UAU.6.1: The TSF shall re-authenticate the user under the conditions before each signing request and for each credential management operation.

Security functional requirement (SFR) · obligation: mandatory · PDF page 43

FIA_UID.2 — User identification before any action

FIA_UID.2.1: The TSF shall require each user to be successfully identified before allowing any TSF-mediated actions on behalf of that user.

Security functional requirement (SFR) · obligation: mandatory · PDF page 43

Referenced by: FIA_USB.1/Wallet, FIA_USB.1/Provider

FIA_UAE_EXT.1 — Transaction-bound authentication evidence

FIA_UAE_EXT.1.1: The TSF shall generate, for each request to perform an operation in [assignment: list of operations requiring authentication evidence], a challenge with a minimum of 128 bits of entropy obtained from a random bit generation function meeting FCS_RBG.1.
FIA_UAE_EXT.1.2: The TSF shall construct, for each challenge, a transaction context comprising the challenge, the identity of the user, the requested operation, and the wallet user identifier and [assignment: other transaction attributes] and shall associate that transaction context with the communication session on which the request was received.
FIA_UAE_EXT.1.3: The TSF shall require that authentication evidence cryptographically bound to the transaction context of the requested operation be presented before the TSF performs any operation in operations defined in FIA_UAE_EXT.1.1.
FIA_UAE_EXT.1.4: The TSF shall verify presented authentication evidence against the authentication reference data associated with the identified user and shall verify that the evidence demonstrates that each authentication factor in a) the possession-based factor of the wallet user and b) the knowledge-based factor derived from the PIN was verified.
FIA_UAE_EXT.1.5: The TSF shall verify that presented authentication evidence was received no more than [assignment: validity period] after the corresponding challenge was issued.
FIA_UAE_EXT.1.6: The TSF shall deny the requested operation if any verification required by FIA_UAE_EXT.1.3, FIA_UAE_EXT.1.4 or FIA_UAE_EXT.1.5 fails.

Security functional requirement (SFR) · obligation: mandatory · PDF page 43

Referenced by: FAU_GEN.1, FIA_AFL.1/Wallet, FIA_USB.1/Wallet

FIA_UAE_EXT.2 — Single-use enforcement for authentication evidence

FIA_UAE_EXT.2.1: The TSF shall maintain a nonce registry covering all transaction identifiers issued and all evidence received within the validity window defined in FIA_UAE_EXT.1.5.
FIA_UAE_EXT.2.2: The TSF shall deny the requested operation if the presented authentication evidence refers to a challenge that was not issued by the TSF, that has already been used in successful verification, or whose validity period has expired.

Security functional requirement (SFR) · obligation: mandatory · PDF page 43

6.6 Class FMT — Security Management

Read section 6.6 in the full text

FMT_SMR.1 — Security roles

FMT_SMR.1.1: The TSF shall maintain the roles • Wallet User • Wallet Instance • Wallet Provider • [assignment: additional authorized identified roles].
FMT_SMR.1.2: The TSF shall be able to associate users with roles.

Security functional requirement (SFR) · obligation: mandatory · PDF page 43