{"packId":"en-304-624","packVersion":"0.1.0","standard":{"reference":"ETSI EN 304 624","title":"Cybersecurity (CYBER); CRA; Essential cybersecurity requirements for Public Key Infrastructure and digital certificate issuance software","status":"INTERIM DRAFT — ETSI open consultation; subject to substantial change before publication (target: second half of 2026). Not cited in the Official Journal: conformance confers NO presumption of conformity today.","sourceUrl":"https://labs.etsi.org/rep/stan4cra/en-304-624","sourceCommit":"adb0faa5","retrievedAt":"2026-09-02","license":"BSD-3-Clause, © 2025 ETSI. Redistributed with attribution as the license requires; the verbatim requirement and assessment text below is reproduced from the interim draft.","licenseText":"Copyright 2025 ETSI\n\nRedistribution and use in source and binary forms, with or without\nmodification, are permitted provided that the following conditions are met:\n1. Redistributions of source code must retain the above copyright notice,\n   this list of conditions and the following disclaimer.\n2. Redistributions in binary form must reproduce the above copyright notice,\n   this list of conditions and the following disclaimer in the documentation\n   and/or other materials provided with the distribution.\n3. Neither the name of the copyright holder nor the names of its contributors\n   may be used to endorse or promote products derived from this software without\n   specific prior written permission.\n\nTHIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS \"AS IS\" AND\nANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED\nWARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.\nIN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,\nINDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,\nBUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,\nDATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF\nLIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE\nOR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED\nOF THE POSSIBILITY OF SUCH DAMAGE."},"appliesTo":{"craCategory":"important-1","annexIIIItem":"Public key infrastructure and digital certificate issuance software","note":"Attaches to a product whose CRA classification matched the Annex III PKI/certificate-issuance item, or manually."},"scope":"The present document specifies vulnerability handling activities, technical requirements and corresponding assessment criteria for public key infrastructure and digital certificate issuance software related to cybersecurity. The products with digital elements in scope, thereafter \"the Products\":\n\n- are specified within the \"technical description\" of the \"category of product\" number \"9\" by the Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 on the technical description of the categories of important and critical products with digital elements pursuant to Regulation (EU) 2024/2847 of the European Parliament and of the Council. [\\[i.2\\]](#_ref_i.2); and\n- are only covered within the product context described in clause [4](#4-product-context).\n\nThe present document covers those Products to demonstrate compliance with essential cybersecurity requirements in the Regulation (EU) 2024/2847 [\\[i.1\\]](#_ref_i.1) Annex I under the conditions identified in annex [A](#annex-a-mapping-with-essential-requirements-of-the-cra).\n\nDifferent use cases representing different product architecture are presented in section 4.6. Requirements applicability in section 5 then defines which requirements apply to which use case to ensure compliance with the CRA's essential cybersecurity requirements.","applicabilityIntro":"The technical requirements of the present document apply under the product context described in Clause 4, which shall be in accordance with its intended use. The equipment shall comply with all applicable technical requirements of the present document at all times when operating in such product context.\n\nSee the applicability fields associated with each technical cybersecurity requirement in the following Clause 5 subsections.","useCases":[{"id":"UC1","title":"Private PKI for non critical sectors","description":"A private enterprise using public-key cryptography that manages a PKI internally to the enterprise. The enterprise therefore manages the policy framework, the generation of key pairs, the certification of key pairs and the purposes of keys.\nIn such organisations the PKI may be organised on department centric hierarchies, or on location centric hierarchies, or on organisation role hierarchies or some combination of these. Whilst the set of services to be enabled by the PKI in this use case are large they may include VPN access and management, timestamp services, disk or message encryption, email, and document access and distribution and so on. The deployment of such a private Public Key Infrastructure (PKI) is not driven by regulatory or standardized requirements but rather by the need to align with the entity’s internal policies and security practices.\nAdditionally, users of these PKI solutions often prioritize flexibility and ease of use over highly secure but restrictive technologies. For instance, they will not rely on Secure Cryptographic Devices (SCD) but rather have private keys stored using operating system or platform key management facilities that provide protection against unauthorised access at rest. The manufacturer shall document the protection mechanisms relied upon and their limitations. Where the platform facility supports hardware-backed protection (e.g. TPM), this should be the preferred configuration.\n\n> EXAMPLE 1: Products deployed to support software maintenance.\n\n> EXAMPLE 2: Products deployed to support internal IT service for network security deployments (e.g. VPN, ssh, TLS servers).\n\n> EXAMPLE 3: User management (identification and authentication) for services like User & Device Authentication, Single Sign-On (SSO)."},{"id":"UC2","title":"Private PKI for critical entities","description":"Critical entities often need to produce their own certificates to manage sensitive IT and network services. These services include VPNs, remote SSH connections, timestamp services, disk or message encryption, and PDF signatures. The deployment of such a private Public Key Infrastructure (PKI) is governed by regulatory or standardized requirements, which impose strict constraints, such as:\n- Network and physical security,\n- Encryption and access control of digital data,\n- Incident reporting obligations,\n- Compliance with secure operational practices.\n\nAs a result, users of these PKI solutions do not have the same deployment flexibility as in less regulated use cases (e.g., UC1). However, they are still permitted to use products that offer diverse functionalities.\n\n> EXAMPLE 1: Products deployed for Trust services. Software used to issue certificates for trust services including those used in electronic attribute attestation.\n\n> EXAMPLE 2: Products deployed by telecommunications service providers used to manage proofs of identity, authorization, and encryption to enable secure access to internal services and customer-facing networks, including e.g. 5G core and edge systems, as standardized in 3GPP TS 33.501 and ETSI GS NFV 003. The product is responsible for the issuance, revocation, and overall management of certificates and certificate status information (e.g., via CRLs or OCSP)."},{"id":"UC3","title":"Public PKI for critical entities","description":"Product used to support certification management services (registration, certificate generation, revocation and status management) provided within very large multi-site company or provided by a CA to the public, and where a compromise carries a significant risk of impact to the security of remote or unknown users, other products, networks or services, or to the health, security or safety of the public.\n\nSuch PKIs are deployed in highly controlled environments, including robust physical and logical security measures, along with strict policies and processes.\n\n> EXAMPLE 1: Products deployed for a PKI used in large enterprise or critical entities (e.g, eIDAS where in the context of the present document ETSI EN 319 411-1  [\\[i.10\\]](#_ref_i.10) defines requirements on security hardware elements of the PKI and requirement of software elements of the PKI for use in eIDAS)."},{"id":"UC4","title":"Public basic PKI for critical entities","description":"Product used to support certification services (certificate generation, revocation and status management) provided within very large multi-site company or provided by a CA to the public, and where a compromise carries a significant risk of impact to the security of remote or unknown users, other products, networks or services, or to the health, security or safety of the public.\n\nSuch PKIs are deployed in highly controlled environments, including robust physical and logical security measures, along with strict policies and processes.\n\n> EXAMPLE 1: Products deployed for Trust services. Software used to issue certificates for trust services including those used in electronic attribute attestation."},{"id":"UC5","title":"Multi-authority PKI for critical entities","description":"In general terms the multi-authority model separates the entity responsible for authentication from the entity responsible for authorisation of specific services, in like manner to the model of Kerberos [\\[i.5\\]](#_ref_i_5) but applied to a public key system.\n\nThe multi-authority PKI is intended to combine multiple authorities in a single (extended) domain, sharing resources, and enforcing minimisation of identifying data. In like manner to Kerberos the certificate model in multi-authority PKI enables anonymous or pseudonymous proof of authority. The product in multi-authority PKIs is expected to be able to generate and distribute signed attestations of authority, to verify any received attestation of authority, and to maintain the status of stored public keys.\n\n> EXAMPLE 1: The PKI dedicated to Co-operative Intelligent Transport Systems (C-ITS) is used to manage proofs of authorisation and identity to enable access to services on different components of ITS systems standardized in ETSI TS 102 940 [\\[i.16\\]](#_ref_i_16) and ETSI TS 102 941 [\\[i.7\\]](#_ref_i_7). The product is responsible for the issuance, revocation, and overall management of certificates and certificate status information. The PKI service architecture and its functionalities considered here are the one .The C-ITS PKI standards provide the basis for the EU C-ITS security credential management system [\\[i.20\\]](#_ref_i.20).\n\n> NOTE 1: For the C-ITS example within this use case the product requirements for the ITS-Station acting as a signature creation and verification element the European C-ITS trust model specifies that the ITS-S conforms to a specific protection profile.\n\n> NOTE 2: In the C-ITS model the product uses pseudonymous key pairs and cycles them rapidly and the product may need to have multiple key pairs maintained at any one time, this may place constraints on the number of private keys that have to be maintained in the product.\n\n> EXAMPLE 2: In a smart contract environment, such as that outlined in ETSI TR 119 540 [\\[i.15\\]](#_ref_i_15), the chain of trust requires that a device operates within multiple trust domains and evidenced in the use of a distributed ledger wherein some entries may be signed as proof of an attribute attestation (e.g. a contractual state transition), or signed as proof of an identity attestation (e.g. identifying the legal entity that is a smart contract stakeholder)."}],"craMap":[{"craRef":"Annex I, Part 1, (1)","clauses":"5"},{"craRef":"Annex I, Part 1, (2)(a)","clauses":"5.2"},{"craRef":"Annex I, Part 1, (2)(b)","clauses":"5.3"},{"craRef":"Annex I, Part 1, (2)(c)","clauses":"5.4"},{"craRef":"Annex I, Part 1, (2)(d)","clauses":"5.5"},{"craRef":"Annex I, Part 1, (2)(e)","clauses":"5.6"},{"craRef":"Annex I, Part 1, (2)(f)","clauses":"5.7"},{"craRef":"Annex I, Part 1, (2)(g)","clauses":"5.8"},{"craRef":"Annex I, Part 1, (2)(h)","clauses":"5.9"},{"craRef":"Annex I, Part 1, (2)(i)","clauses":"5.10"},{"craRef":"Annex I, Part 1, (2)(j)","clauses":"5.11"},{"craRef":"Annex I, Part 1, (2)(k)","clauses":"5.12"},{"craRef":"Annex I, Part 1, (2)(l)","clauses":"5.13"},{"craRef":"Annex I, Part 1, (2)(m)","clauses":"5.14"},{"craRef":"Annex I, Part 2","clauses":"5.15"}],"topics":[{"clause":"5.2","title":"No known exploitable vulnerabilities","overview":"This clause addresses the requirements in the CRA [\\[i.1\\]](#_ref_i.1) Annex 1 Part 1 (2) (a).","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"REQ-PKI-KEV-01","requirement":"The product shall not contain known exploitable vulnerabilities, unless vulnerability assessment demonstrates that:\n- the vulnerability is not exploitable in the product; or\n- specific user guidance is provided to prevent exploitation.\n\nNOTE: Details of the vulnerability assessment are provided in the vulnerability handling process defined in prEN 40000-1-3 [\\[i.17\\]](#_ref_i.17).","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","assessment":{"objective":"Verify that:\n- Known exploitable vulnerabilities affecting the product are identified.\n- For each identified known exploitable vulnerability, one of the following applies:\n   - the vulnerability assessment demonstrates that the vulnerability is not exploitable in the product; or\n   specific user guidance is provided to prevent exploitation.\n- No known exploitable vulnerability remains in the product without one of the above justifications.","preparation":"- Product documentation identifying elements contained in the product (elements may include software, firmware, or hardware elements, as applicable).\n- Component inventory, bill of materials, or equivalent software identification information, including version and patch-level information where available.\n- Access to the product, or to relevant components such as binaries, packages, images, firmware, containers, or file systems, sufficient to perform vulnerability scanning where technically feasible.\n- Vulnerability scanning tools and associated vulnerability databases suitable for identifying candidate vulnerabilities in the product.\n- Access to recognized public vulnerability sources:\n    - Public databases e.g. EUVD, CISA Known Exploited Vulnerabilities (KEV) Catalog, the CVE List, the NIST National Vulnerability Database (NVD)) and relevant vendor advisories;\n    - Complementary sources that may support identification of relevant vulnerabilities, where relevant, for example technical research papers, conference papers and other publicly available security research.","activities":"- Review the product documentation, component inventory, bill of materials, or equivalent information to identify the elements contained in the product (which may include software, firmware, or hardware elements, as applicable) and their relevant versions or patch levels, where available.\n- Perform vulnerability scanning, where technically feasible, on the product or relevant components to identify candidate vulnerabilities affecting elements contained in the product.\n- Assess, in accordance with prEN 40000-1-3  [\\[i.17\\]](#_ref_i.17), the vulnerabilities identified through correlation of scanning results, product identification information, vendor advisories, and recognized public vulnerability sources.\n- For each identified known exploitable vulnerability, review the vulnerability assessment and verify whether it demonstrates that the vulnerability is not exploitable in the product:\n- Where the treatment of an identified known exploitable vulnerability relies on user guidance, review the user guidance and verify that it specifically addresses the conditions to prevent exploitation.\n- Verify that no identified known exploitable vulnerability affecting the product remains without:\n   - a vulnerability assessment demonstrating non-exploitability in the product; or\n   - specific required user guidance to prevent exploitation.","verdict":"- Pass: Known exploitable vulnerabilities affecting the product are identified, and each such vulnerability is covered either by a vulnerability assessment demonstrating non-exploitability in the product, or by specific user guidance preventing exploitation.\n- Fail: Vulnerability assessment is missing or insufficient for one or more such vulnerabilities, user guidance is missing or inadequate where relied upon, or one or more known exploitable vulnerabilities remain without justified treatment.","evidence":"- Vulnerability scanning results, including the tools and vulnerability databases used.\n- Recognized public vulnerability sources, vendor advisories, and product identification information used in the assessment.\n- Vulnerability assessment records and conclusions produced in accordance with prEN 40000-1-3  [\\[i.17\\]](#_ref_i.17).\n- REQ-PKI-AAC-01Product user guidance relied upon to prevent exploitation, where applicable.","guidance":""}}]},{"clause":"5.3","title":"Secure by default configuration","overview":"\n\n**SDBC- Access control** — This clause addresses the requirements in the CRA [\\[i.1\\]](#_ref_i.1) Annex 1 Part 1 (2) (b).","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"REQ-PKI-SBDC-01","family":"SDBC- Access control","requirement":"All assets of the system shall be defined as protected assets with default access condition of DENY.\n\nNOTE 1: See also clause 5.5.\n\nEXAMPLE: The role of the access control countermeasure is described in ETSI TS 102 165-2 [\\[i.8\\]](#_ref_i.8) (clause 6) where permission to access a resource is only ever true (PERMIT) or false (DENY) and where the decision to give permission is always deterministic.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","assessment":{"objective":"- Verify that all system assets are identified as protected assets and that the default access control policy is configured to deny access unless an explicit permission is granted.","preparation":"- System architecture documentation and asset inventory.\n- Default access control policies, role definitions, and authorization matrices.\n- Administrator documentation describing access control configuration.\n- Default user accounts with different privilege levels, including unauthenticated and unauthorized accounts.","activities":"- Review the asset inventory and identify all system assets requiring access protection.\n- Review access control configurations and verify that the default decision for all protected assets is DENY.\n- Verify that access permissions are granted only through explicit authorization rules.\n- Attempt to access protected assets using unauthenticated and unauthorized accounts.\n- Verify that access requests without explicit permissions are denied in a deterministic manner.","verdict":"- SUCCESS:\n  - All identified assets are configured by default as protected assets.\n  - The default access condition for all assets is DENY.\n  - Access is permitted only when explicitly authorized.\n  - Unauthorized access attempts are consistently denied.\n- FAIL:\n  - One or more assets are not protected.\n  - The default policy allows access without explicit authorization.\n  - Unauthorized access attempts result in successful access or inconsistent behavior.","evidence":"- System architecture and asset inventory documents.\n- Access control policy configuration files.\n- Role and permission matrices.\n- Screenshots or configuration exports showing default DENY settings.\n- Test execution records and access attempt logs.","guidance":""}},{"id":"REQ-PKI-SBDC-02","family":"SBDC- Monitoring","requirement":"The audit log integrity protection event shall be performed by default once a day.","applicability":{"UC1":"not-required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"UC2, UC3, UC4 and UC5.","rationale":"The audit record integrity ensures that all auditable events are traceable and misuse of the product functions can be traced.","assessment":{"objective":"Verify that audit log integrity protection mechanisms are enabled by default and are executed automatically at least once every 24 hours.","preparation":"- Audit logging and monitoring configuration documentation.\n- (If available) Documentation describing the audit integrity protection mechanism.\n- System scheduling and logging configurations.\n- Test environment with audit logging enabled.","activities":"- Review the audit logging configuration.\n- Verify that audit log integrity protection is enabled by default.\n- Review scheduler configuration and verify that integrity protection events are configured to execute once every 24 hours.\n- Observe system operation or examine generated records to confirm execution of the integrity protection event when reaching expecting activation time (manually set system time if necessary).\n- Verify that evidence of execution is retained in logs or reports.","verdict":"- SUCCESS:\n  - Audit log integrity protection is enabled by default.\n  - The integrity protection event is automatically executed at least once every 24 hours.\n  - Execution records are generated and retained.\n- FAIL:\n  - Integrity protection is disabled by default.\n  - The integrity protection event is not scheduled or does not execute daily.\n  - No evidence of execution can be produced.","evidence":"- Audit logging configuration files.\n- Scheduler or cron configuration.\n- System logs showing execution timestamps.\n- Integrity verification reports.\n- Screenshots or configuration exports demonstrating default settings.","guidance":""}},{"id":"REQ-PKI-SBDC-03","family":"SBDC- Cryptography","requirement":"All cryptographic mechanisms shall be configured by default in conformity to the general state of the art as defined in Annex K.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","rationale":"Cf. Annex K rational.","assessment":{"objective":"- Verify that all cryptographic mechanisms are configured by default using algorithms, key lengths, protocols, and parameters that conform to the requirements specified in Annex K.","preparation":"- Cryptographic architecture documentation.\n- Default security configuration files.\n- (If available) Tools capable of inspecting cryptographic configurations and certificates.","activities":"- Identify all cryptographic mechanisms implemented by the system.\n- Review default cryptographic configurations, including algorithms, protocols, key lengths, and operational parameters.\n- Compare the default configurations against Annex K assessment requirements.\n- Verify that deprecated, weak, or non-approved cryptographic mechanisms are not enabled by default.\n- Verify that cryptographic defaults remain compliant following installation or initialization.","verdict":"- SUCCESS:\n  - All cryptographic mechanisms use algorithms and parameters conformant with Annex K assessment requirements.\n  - Default installation results in a compliant cryptographic configuration.\n- FAIL:\n  - One or more cryptographic mechanisms do not conform to Annex K requirements.\n  - Default configurations require manual modification to achieve compliance.","evidence":"- Cryptographic architecture documentation.\n- Default configuration files.\n- Configuration exports and screenshots.\n- Cryptographic parameter inspection outputs.\n- Mapping of implemented mechanisms to Annex K requirements.\n- Test reports demonstrating default compliance.","guidance":""}},{"id":"REQ-PKI-SBDC-04","family":"SBDC- Certificates","requirement":"Certificates validity periode shall be limited to 3 years by default.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","rationale":"The longer a certificate is valid, the higher the risk that cryptographic attacks on its signature may succeed. A default limitation to 3 years reduces unnecessary exposure of certificates to potential vulnerabilities.","assessment":{"objective":"- Verify that the default certificate issuance configuration limits certificate validity periods to a maximum of three years.","preparation":"- Certificate management documentation.\n- Defaualt certificate issuance policy and configuration files.\n- Environment capable of generating certificates using default settings.\n- Tools to parse certificate content.","activities":"- Review the certificate issuance configuration and policies.\n- Verify that the default certificate validity period is configured to be no greater than three years.\n- Generate one or more certificates using default settings.\n- Inspect the generated certificates and calculate the validity period using the `Not Before` and `Not After` fields or any other field providing validity duration..\n- Verify that no certificate generated using default settings exceeds three years of validity.","verdict":"- SUCCESS:\n  - The default certificate validity period is configured to a maximum of three years.\n  - Certificates generated using default settings do not exceed three years of validity.\n- FAIL:\n  - The default configuration allows certificate validity periods exceeding three years.\n  - Certificates generated using default settings exceed the permitted validity period.","evidence":"- Certificate issuance policies and configuration files.\n- Generated test certificates.\n- Certificate inspection outputs (`Not Before` and `Not After` values).\n- Screenshots or configuration exports showing default validity settings.\n- Test execution records and assessment report.","guidance":""}}]},{"clause":"5.4","title":"Secure updates","overview":"This clause addresses the requirements in the CRA [\\[i.1\\]](#_ref_i.1) Annex 1 Part 1 (2) (c).","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"REQ-PKI-SU-01","requirement":"The product shall support software update mechanisms, that allow to update every part of the product's software, except for parts of the product's software that are immutable due to technical reasons.\n\nNOTE: Part of the product's software can be immutable due to its technology (e.g. software installed in a ROM).","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","assessment":{"objective":"- Verify that the product supports software update mechanisms capable of updating all mutable parts of its software, excluding only those parts that are immutable due to technical constraints (e.g., ROM-based software).","preparation":"- Identify all software components of the product.\n- Determine which components are mutable and which are immutable (e.g., ROM-based).\n- Prepare a test environment with access to the product's update mechanisms.","activities":"- Attempt to update each mutable component of the product's software.\n- Verify that updates are successfully applied to all mutable components.\n- Confirm that immutable components (e.g., ROM-based) are not updated and that this is justified by technical constraints.\n- Document any components that cannot be updated and validate their immutability.","verdict":"- SUCCESS:\n  - All mutable components can be updated.\n  - Immutable components are correctly identified and justified.\n- FAIL:\n  - Any mutable component cannot be updated.\n  - Immutable components are not justified or incorrectly classified.","evidence":"- Logs or screenshots of successful updates for mutable components.\n- Documentation or technical specifications justifying immutability for excluded components.\n- Test reports confirming the update process.","guidance":""}},{"id":"REQ-PKI-SU-02","requirement":"Where an update is made available to the device it shall only be installed if it has been signed by a known and trusted entity with a valid key identified by its PKC.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","assessment":{"objective":"- Verify that the product only installs updates signed by a known and trusted entity with a valid key identified by its PKC (Public Key Certificate).","preparation":"- Obtain a valid signed update from a trusted entity.\n- Obtain an unsigned update or an update signed with an invalid/unknown key.\n- Prepare a test environment with the product configured to recognize the trusted entity's PKC.","activities":"- Attempt to install the valid signed update and verify it is accepted.\n- Attempt to install the unsigned update or update signed with an invalid key and verify it is rejected.\n- Check that the product validates the signature and PKC before installation.\n- Test edge cases, such as expired or revoked certificates.","verdict":"- SUCCESS:\n  - Valid signed updates are installed.\n  - Unsigned or invalidly signed updates are rejected.\n- FAIL:\n  - Valid signed updates are rejected.\n  - Unsigned or invalidly signed updates are accepted.","evidence":"- Logs or screenshots showing successful installation of valid updates.\n- Logs or screenshots showing rejection of unsigned or invalidly signed updates.\n- Test reports confirming signature and PKC validation.","guidance":""}},{"id":"REQ-PKI-SU-03","requirement":"The product administrator shall be able to configure when available updates are installed.\n\nEXAMPLE: Options may include immediately on receipt, deferred to an agreed \"maintenance\" period.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","assessment":{"objective":"- Verify that the device administrator can configure when available updates are installed, with options such as immediate installation upon receipt or deferred installation during a maintenance period.","preparation":"- Identify the administrator configuration interface for update settings.\n- Prepare test scenarios for different update installation options (e.g., immediate, deferred).","activities":"- Configure the product to install updates immediately upon receipt and verify the behavior.\n- Configure the product to defer updates to a specified maintenance to specify the set of acceptable values for the and verify the behavior.\n- Attempt to trigger an update under each configuration and confirm it follows the configured timing.\n- Verify that the administrator has sufficient control over the update timing.","verdict":"- SUCCESS:\n  - The administrator can configure update timing options.\n  - Updates are installed according to the configured timing (immediate or deferred).\n- FAIL:\n  - The administrator cannot configure update timing.\n  - Updates are not installed according to the configured timing.","evidence":"- Screenshots or logs of the administrator interface showing configuration options.\n- Test reports confirming updates are installed according to the configured timing.\n- Documentation of the update process under different configurations.","guidance":""}}]},{"clause":"5.5","title":"Authentication and access control","overview":"This clause addresses the requirements in the CRA [\\[i.1\\]](#_ref_i.1) Annex 1 Part 1 (2) (d).","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"REQ-PKI-AAC-01","requirement":"Only authorized users shall be able to access product functionalities, stored data, and configuration data.\nTo achieve this, the product shall enforce identification and authentication mechanisms by implementing cryptographic mechanisms conform to the general state of the art as defined in Annex K.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","rationale":"Only authorized, identified, and authenticated users should be able to access product services and stored data. This addresses all relevant threats.","assessment":{"objective":"- Verify that the product only allows identified and authenticated authorized users to perform access-controlled actions.","preparation":"- Access to the product interfaces.","activities":"- Enumerate product interfaces and identify any interfaces without access control.\n- Attempt to perform protected actions without being identified or authenticated.\n- Log in as authorized users, then try to intercept and replay user authentication data or session authentication tokens.\n- Systematically try all possible combinations of usernames, passwords, or other credentials to attempt unauthorized access.","verdict":"- SUCCESS: No unauthorized users may read or modify stored data or configuration data, or perform protected actions.\n- FAIL: If unauthorized access or incorrect rights assignment is detected.","evidence":"- Results of identification and authentication attempts (both successful and failed).\n- Screenshots or logs of access attempts, rights verification, or rejected actions.","guidance":"NOTE (Vandorisk): this is the draft's assessment case ACC-PKI-AAC-02 (clause 6), matched to this requirement by its stated objective — the draft's assessment-case numbering does not align one-to-one with requirement ids."}},{"id":"REQ-PKI-AAC-02","requirement":"The product shall manage different user profiles, allowing Role Based Access Control (RBAC). This mechanism shall provide means to define specific user account capabilities for the following privileged roles:\n- U.Administrator\n\nThis shall include at least the capability to limit user profile rigths for the following product actions and their associtated assets ():\n- Product audit & administration\n  - F.UserAccountManagement\n  - F.NetworkConfiguration\n  - F.InternalKeyManagement\n  - F.AuditEventManagement\n  - F.LoggingOfSecurityEvents\n  - F.CertificateProfileManagement","applicability":{"UC1":"required","UC2":"not-required","UC3":"not-required","UC4":"not-required","UC5":"not-required"},"applicabilityText":"UC1.","assessment":{"objective":"- Verify the product allows to create different user profiles (users with different access rights to functions, configuration, and stored data) for the roles defined by PKI policies, each with distinct credentials protected using state of the art cryptographic mecanisms.","preparation":"Access to the administrative and user interfaces of the product.","activities":"- Create one account for each manageable profile (at least: PKI Administrator, PKI Operator, PKI Officer, PKI Auditor) with unique credentials.\n- For each account:\n  - Attempt to log in using credentials from other accounts or invalid credentials.\n  - Log in with the correct credentials for each account.\n  - Verify that only the authorized actions defined by the user profile are accessible.\n  - If the account is not authorized to, attempt to read stored data\n  - If the account is not authorized to, attempt to read configuration data\n  - If the account is not authorized to, attempt to modify stored data\n  - If the account is not authorized to, attempt to modify configuration data\n- Validate supporting cryptographic mecanisms following annex K assessment requirements.","verdict":"- SUCCESS: if only correct identification and authentication allows access to the specific rights of a user profile, and only authorized users may read or modify stored data or configuration data, or perform protected actions.\n- FAIL: if unauthorized access or incorrect rights assignment is detected.","evidence":"- Results of identification and authentication attempts (successful and failed).\n- List of validated functionalities and data access rights for each user profile.\n- Screenshots or logs of access attempts and rights verification.","guidance":"NOTE (Vandorisk): this is the draft's assessment case ACC-PKI-AAC-01 (clause 6), matched to this requirement by its stated objective — the draft's assessment-case numbering does not align one-to-one with requirement ids."}},{"id":"REQ-PKI-AAC-03","requirement":"The product shall manage different user profiles, allowing RBAC. This mechanism shall provide means to define specific user account capabilities for the following roles:\n- U.Administrator, U.Officer, U.Auditor\n\nThis shall include at least the capability to limit user profile rigths for the following product actions and their associtated assets as defined in Annex U:\n - Product audit & administration\n    - F.UserAccountManagement\n    - F.NetworkConfiguration\n    - F.InternalKeyManagement\n    - F.ExternalKeyManagement\n    - F.AuditEventManagement\n    - F.LoggingOfSecurityEvents\n    - F.CertificateProfileManagement\n\n - Registration\n    - F.OnlineRegService\n    - F.CertificateDissemination\n    - F.PrivateKeyImportExport\n    - F.OfficerRegistrationApproval\n\n - Certificate generation\n    - F.SCD_BasedKeyPairGen\n    - F.NoneSCD_BasedKeyPairGen\n    - F.SubjectCertSignCreation\n    - F.OfficerCertGenApproval\n    - F.PseudonymCertIssuance\n\n - Certificate status\n    - F.CertificateStatus\n\n - Revocation management\n    - F.RevocationManagement\n    - F.OfficerRevocationApproval","applicability":{"UC1":"not-required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"UC2, UC3, UC4 and UC5.","assessment":{"objective":"- Verify the product allows to create different user profiles (users with different access rights to functions, configuration, and stored data) for the roles defined by PKI policies, each with distinct credentials protected using state of the art cryptographic mecanisms.","preparation":"Access to the administrative and user interfaces of the product.","activities":"- Create one account for each manageable profile (at least: PKI Administrator, PKI Operator, PKI Officer, PKI Auditor) with unique credentials.\n- For each account:\n  - Attempt to log in using credentials from other accounts or invalid credentials.\n  - Log in with the correct credentials for each account.\n  - Verify that only the authorized actions defined by the user profile are accessible.\n  - If the account is not authorized to, attempt to read stored data\n  - If the account is not authorized to, attempt to read configuration data\n  - If the account is not authorized to, attempt to modify stored data\n  - If the account is not authorized to, attempt to modify configuration data\n- Validate supporting cryptographic mecanisms following annex K assessment requirements.","verdict":"- SUCCESS: if only correct identification and authentication allows access to the specific rights of a user profile, and only authorized users may read or modify stored data or configuration data, or perform protected actions.\n- FAIL: if unauthorized access or incorrect rights assignment is detected.","evidence":"- Results of identification and authentication attempts (successful and failed).\n- List of validated functionalities and data access rights for each user profile.\n- Screenshots or logs of access attempts and rights verification.","guidance":"NOTE (Vandorisk): this is the draft's assessment case ACC-PKI-AAC-01 (clause 6), matched to this requirement by its stated objective — the draft's assessment-case numbering does not align one-to-one with requirement ids."}}]},{"clause":"5.6","title":"Confidentiality","overview":"This clause addresses the requirements in the CRA [\\[i.1\\]](#_ref_i.1) Annex 1 Part 1 (2) (e).","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"REQ-PKI-CON-01","family":"CON - General","requirement":"The product shall provide capabilities to ensure that the private key generated by the product cannot be removed or copied from the product by unauthorized users.\n\nNOTE: Where a device creates a public-private key pair and maintains the related PKC that set (key pair and PKC) can be moved from one physical entity to another within a strictly controlled environment as per use case.","applicability":{"UC1":"required","UC2":"not-required","UC3":"not-required","UC4":"not-required","UC5":"not-required"},"applicabilityText":"UC1.","rationale":"Private keys are the root of trust in a PKI. When they are not generated or protected by an external SCD or KMS, this requirement ensures that only the product has access to them, protecting them from export, copying, or disclosure.","assessment":{"objective":"- Verify that private keys generated by the product are protected against unauthorized export, copying, disclosure, or removal.","preparation":"- (If available) Key management architecture documentation.\n- Documentation describing private key generation, storage, and access controls.\n- Identify interfaces, APIs, administrative functions, backup mechanisms, and export capabilities that may provide access to private keys.\n- Access to authorized and unauthorized user accounts.","activities":"- (If available) Review the design of private key generation and storage mechanisms.\n- Verify that generated private keys are stored in protected locations or secure cryptographic devices.\n- Verify that export or copy operations require explicit authorization.\n- Attempt to access, export, copy, or remove private keys using unauthorized accounts and interfaces.\n- Verify that unauthorized operations are denied and appropriately logged.\n- Where controlled migration of key pairs is supported, verify that transfer is performed only under documented and authorized procedures.","verdict":"- SUCCESS:\n  - Unauthorized users cannot access, export, copy, or remove private keys.\n  - All key management interfaces enforce authorization controls.\n  - Any permitted key transfer mechanisms are appropriately controlled and documented.\n- FAIL:\n  - Unauthorized users can obtain, copy, export, or remove private keys.\n  - Key protection mechanisms can be bypassed.\n  - Key migration mechanisms lack appropriate controls.","evidence":"- Key management design documentation.\n- Access control configurations.\n- Security architecture diagrams.\n- Test results of attempted unauthorized exports.\n- Audit logs of key management operations.\n- Configuration files and screenshots.","guidance":""}},{"id":"REQ-PKI-CON-02","family":"CON - General","requirement":"Where the private key is stored in a cryptographically protected way, those cryptographic mechanisms shall conform to the general state of the art as defined in Annex K.","applicability":{"UC1":"not-required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"UC2, UC3, UC4 and UC5","rationale":"Cf. Annex K rational.","assessment":null},{"id":"REQ-PKI-CON-03","family":"CON - General","requirement":"If a pseudonymous certificate is used to exchange a public key related to an ephemeral identity the product shall ensure that no data is contained in the certificate that can be used to break the pseudonymity of the sender.","applicability":{"UC1":"not-required","UC2":"not-required","UC3":"not-required","UC4":"not-required","UC5":"required"},"applicabilityText":"UC5","rationale":"Pseudonymous certificates are designed to ensure privacy. If these certificates include data that can be linked to the user, the privacy protection is compromised, defeating the purpose of pseudonymity. This requires that the product is designed to create pseudonymous certificates containing only fields that provide technical information unrelated to the user.","assessment":{"objective":"- Verify that when a pseudonymous certificate is used to exchange a public key associated with an ephemeral identity, the certificate contains no information that could directly or indirectly reveal, correlate, or facilitate identification of the sender, thereby preserving sender pseudonymity.","preparation":"- Product security architecture documentation describing the implementation of pseudonymous certificates and ephemeral identities.\n- The certificate profile specification, including all mandatory and optional certificate fields and extensions.\n- Pseudonymous certificates generated by the product.\n- Product configuration settings for certificate generation and identity management.\n- Tools for certificate parsing and inspection.\n- Identify any external repositories, certificate databases, or services that may be used to correlate certificate information.","activities":"- Review the product design documentation to determine how pseudonymous certificates are generated and associated with ephemeral identities.\n- Examine the certificate profile and identify all fields and extensions included in the pseudonymous certificate.\n- Inspect sample certificates and verify that subject names, subject alternative names, serial numbers, issuer attributes, custom extensions, identifiers, URLs, metadata, or any other fields do not contain:\n  - Personally identifiable information (PII);\n  - Persistent identifiers linked to a specific user or device;\n  - Information that permits direct or indirect sender identification;\n  - Values that can be correlated across multiple certificates to establish sender identity.\n  - Verify that any included certificate information is strictly limited to technical information necessary for certificate validation and cryptographic operation.\n  - Assess whether certificate serial number generation, extension values, and metadata are randomly generated or otherwise designed to prevent sender correlation.\n  - Review product configuration and operational procedures to ensure that pseudonymous certificates cannot be configured to include identifying information.\n  - Attempt to correlate multiple pseudonymous certificates issued to the same sender and determine whether any certificate data enables identity linkage.","verdict":"- SUCCESS:\n    - The product generates pseudonymous certificates containing only technical information necessary for cryptographic processing and validation.\n    - No certificate field or extension contains identifying information, persistent identifiers, or metadata that can directly or indirectly reveal the sender's identity.\n    - Multiple certificates associated with the same sender cannot be correlated using certificate contents.\n    - Product configuration prevents the inclusion of identifying information in pseudonymous certificates.\n- FAIL:\n  - One or more certificate fields contain information that directly or indirectly identifies the sender.\n  - Certificate contents include persistent identifiers or metadata that enable correlation of certificates belonging to the same sender.\n  - Certificate serial numbers, extensions, naming conventions, or custom attributes permit sender re-identification.\n  - Product configuration allows pseudonymous certificates to include user-related identifying information.","evidence":"- Product architecture and design documentation describing pseudonymous certificate generation.\n- Certificate profile specifications and extension definitions.\n- Parsed representations of sample pseudonymous certificates.\n- Configuration files and settings controlling certificate generation.\n- Assessment records demonstrating inspection of certificate fields and extensions.\n- Correlation analysis results showing that certificate contents cannot be used to identify or link the sender.\n- Assessor observations and test logs supporting the final determination.","guidance":"NOTE (Vandorisk): this is the draft's assessment case ACC-PKI-CON-02 (clause 6), matched to this requirement by its stated objective — the draft's assessment-case numbering does not align one-to-one with requirement ids."}},{"id":"REQ-PKI-CON-04","family":"CON - General","requirement":"If the product sends data intended/labelled as personal or sensitive to another entity the product shall ensure that such data is protected from eavesdropping in a cryptographically protected way. These cryptographic mechanisms shall conform to the general state of the art as defined in Annex K.\n\nNOTE: This includes any remote administration.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"not-required","UC5":"required"},"applicabilityText":"UC1, UC2, UC3 and UC5","rationale":"Analysis has to be performed and justified by the developper to ensure that the product protects personal and sensitive data. This requires to define what data are considered personnal or sensitive and provide and associate cryptographic protection mechanisms.","assessment":{"objective":"- Verify that all transmissions of personal or sensitive data are protected using state-of-the-art cryptographic mechanisms in accordance with Annex K.","preparation":"- Data flow diagrams or interface specifications.\n- Data classification documentation identifying personal and sensitive data.\n- Cryptographic configuration documentation.\n- Network monitoring tools.\n- Test environment including external components the product will connect to.","activities":"- Identify all interfaces transmitting personal or sensitive data.\n- Verify that transmitted data is protected by cryptographic mechanisms compliant with Annex K.\n- Capture network traffic during data transmission. Verify that sensitive information is not transmitted in plaintext.","verdict":"- SUCCESS:\n  - All identified sensitive data transmissions are cryptographically protected.\n  - The implemented cryptographic mechanisms conform to Annex K assessment requirement.\n  - No sensitive data is observable in plaintext.\n- FAIL:\n  - Sensitive data is transmitted without cryptographic protection.\n  - Non-approved or weak cryptographic mechanisms are used.\n  - Sensitive information can be recovered from network captures.","evidence":"- Data flow diagrams.\n- Data classification documentation.\n- Network packet captures.\n- Cryptographic configuration files.\n- Protocol inspection reports.\n- Test execution records.","guidance":"NOTE (Vandorisk): this is the draft's assessment case ACC-PKI-CON-03 (clause 6), matched to this requirement by its stated objective — the draft's assessment-case numbering does not align one-to-one with requirement ids."}},{"id":"REQ-PKI-CON-05","family":"CON - General","requirement":"A public key certificate request containing explicit personal data shall be protected in integrity and confidentiality by implementing cryptographic mechanisms conform to the general state of the art as defined in Annex K.","applicability":{"UC1":"not-required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"UC2, UC3, UC4 and UC5","rationale":"Cf. Annex K rational.","assessment":null},{"id":"REQ-PKI-CON-06","family":"CON - General","requirement":"The product shall implement a chosen set of cryptographic algorithms to decrypt data that has been confidentiality-protected using a known key, ensuring it can recover the plaintext data. Those cryptographic mechanisms shall conform to the general state of the art as defined in Annex K.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"not-required","UC5":"required"},"applicabilityText":"UC1, UC2, UC3 and UC5","rationale":"Communication with external components requires to encrypt use case sensitive data using state of the art mechanisms (cf. Annex K rational).","assessment":null},{"id":"REQ-PKI-CON-07","family":"CON - General","requirement":"The cryptographic mechanisms used to sign and verify content shall conform to the general state of the art, as defined in Annex K.\n\nNOTE: If the product is intended for a specific environment with a defined set of agreed cryptographic mechanisms, the product has to be able to be used in accordance with those cryptographic requirements.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"not-required","UC5":"required"},"applicabilityText":"UC1, UC2, UC3 and UC5","rationale":"Cf. Annex K rational.","assessment":null},{"id":"REQ-PKI-CON-08","family":"CON - Secure storage and communications","requirement":"The cryptographic mechanisms used to encrypt and decrypt content shall conform to the general state of the art, as defined in Annex K.\n\nNOTE: If the product is intended for a specific environment with a defined set of agreed cryptographic mechanisms, the product has to be able to be used in accordance with those cryptographic requirements.","applicability":{},"applicabilityText":"All use cases where the product implements encryption mechanisms either for data storage or external communications.","rationale":"Cf. Annex K rational.","assessment":null},{"id":"REQ-PKI-CON-09","family":"CON - Secure storage and communications","requirement":"The product shall be able to establish and maintain a secure link with the SCD or KMS, and that the SCD or KMS interfaces are properly called.","applicability":{"UC1":"not-required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"UC2, UC3, UC4, UC5.","rationale":"To ensure the secure key managment, the proper and secure use of external SCD or KMS is required.","assessment":{"objective":"- Verify that communications with the SCD or KMS are securely established, maintained, and use only authorized and correctly implemented interfaces.","preparation":"- SCD/KMS integration documentation or API documentation.\n- Product interface specifications and API documentation.\n- Cryptographic configuration documentation.\n- Running product with access to an operational SCD or KMS.\n- Network monitoring tools.","activities":"- Review the architecture and communication methods used with the SCD or KMS.\n- Verify that communications are protected using authenticated and encrypted channels.\n- Verify that only documented interfaces and APIs are invoked.\n- Observe key management operations that invoke the SCD or KMS.\n- Capture network traffic during data transmission and verify that sensitive information is not transmitted in plaintext.\n- Introduce communication failures or invalid requests and verify proper error handling.\n- Verify that security-relevant interactions are logged.","verdict":"- SUCCESS:\n  - Secure authenticated communications with the SCD or KMS are established and maintained.\n  - Only approved interfaces are used.\n  - Communication failures are securely handled.\n- FAIL:\n  - Communications occur without appropriate protection.\n  - Undocumented or insecure interfaces are used.\n  - Communication failures compromise security functions.","evidence":"- Architecture documentation.\n- Interface specifications.\n- Communication configuration files.\n- Network captures.\n- API invocation logs.\n- Audit records.","guidance":"NOTE (Vandorisk): this is the draft's assessment case ACC-PKI-CON-04 (clause 6), matched to this requirement by its stated objective — the draft's assessment-case numbering does not align one-to-one with requirement ids."}},{"id":"REQ-PKI-CON-10","family":"CON - Key management","requirement":"When the product exports private or symmetric keys it shall use state of the art cryptographic mechanisms for guaranteeing its confidentiality as defined in Annex K.\n\nEXAMPLES: The exported private or symmetric key can be encrypted such that only its designated recipient can decrypt it.","applicability":{"UC1":"required","UC2":"required","UC3":"not-required","UC4":"not-required","UC5":"not-required"},"applicabilityText":"UC1 and UC2.","rationale":"A secret key should not be compromised if its exported form is intercepted.","assessment":{"objective":"- Verify that exported private or symmetric keys are protected against disclosure using cryptographic mechanisms conforming to Annex K.","preparation":"- Determine whether key export functionality exists.\n- Obtain export procedures and cryptographic documentation.\n- Prepare test keys and export environments.","activities":"- Verify whether key export functionality is supported.\n- Review mechanisms protecting exported keys.\n- Export private and symmetric keys using supported procedures.\n- Verify that exported keys are encrypted using approved algorithms and key management procedures as defined by Annex K assessment requirements.\n- Attempt to access exported keys without possessing required decryption material.","verdict":"- SUCCESS:\n  - Exported keys are protected using approved cryptographic mechanisms.\n  - Unauthorized parties cannot recover exported key material.\n- FAIL:\n  - Keys are exported in plaintext.\n  - Weak or non-approved protection mechanisms are used.\n  - Exported key material can be recovered without authorization.","evidence":"- Export procedures.\n- Cryptographic configurations.\n- Exported key files.\n- Key inspection results.\n- Test reports.","guidance":"NOTE (Vandorisk): this is the draft's assessment case ACC-PKI-CON-05 (clause 6), matched to this requirement by its stated objective — the draft's assessment-case numbering does not align one-to-one with requirement ids."}},{"id":"REQ-PKI-CON-11","family":"CON - Key management","requirement":"Secret keys shall not be stored persistently in plaintext form. They shall be stored within a secure cryptographic device or encrypted using approved algorithms as defined in Annex K using independently managed keys. They may only be accessed in plaintext form temporarily for a single operation or batch of operations.","applicability":{"UC1":"not-required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"UC2, UC3, UC4, UC5.","rationale":"To ensure trust the product must rely on secure and valid key creation and management systems accessible only to authorised users provided by hardware security devices.","assessment":{"objective":"- Verify that secret keys are never persistently stored in plaintext and are protected by secure cryptographic devices or encryption mechanisms using independently managed keys.","preparation":"- Key management and storage architecture documentation.\n- Database and filesystem documentation.\n- Access to storage repositories and backup media.\n- (If possible) Known private key content","activities":"- Identify all locations where secret keys may be stored.\n- Review storage mechanisms and encryption methods.\n- Inspect storage locations, backups, and configuration files for plaintext secret keys.\n- Verify that keys stored outside secure cryptographic devices are encrypted using approved mechanisms.\n- Verify that plaintext key access occurs only temporarily during cryptographic operations.","verdict":"- SUCCESS:\n  - Secret keys are never persistently stored in plaintext.\n  - Stored keys are protected by secure cryptographic devices or approved encryption mechanisms.\n  - Plaintext access is temporary and limited to operational requirements.\n- FAIL:\n  - Secret keys are persistently stored in plaintext.\n  - Encryption mechanisms do not comply with Annex K.\n  - Plaintext key exposure exceeds operational requirements.","evidence":"- Architecture documentation.\n- Storage configuration files.\n- Database and filesystem inspection results.\n- Backup inspection results.\n- Key management procedures.","guidance":"NOTE (Vandorisk): this is the draft's assessment case ACC-PKI-CON-06 (clause 6), matched to this requirement by its stated objective — the draft's assessment-case numbering does not align one-to-one with requirement ids."}}]},{"clause":"5.7","title":"Integrity","overview":"This clause addresses the requirements in the CRA [\\[i.1\\]](#_ref_i.1) Annex 1 Part 1 (2) (f).","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"REQ-PKI-INT-01","family":"INT - Monitoring","requirement":"The product shall be able to detect unauthorised modifications to the stored audit records during the audit using state of the art cryptographic mechanisms as defined in Annex K.","applicability":{"UC1":"not-required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"UC2, UC3, UC4 and UC5.","rationale":"The audit record integrity and availability ensure that all auditable events are traceable and misuse of the product functions can be traced.","assessment":{"objective":"- Verify that unauthorized modifications to stored audit records are detected using cryptographic integrity mechanisms conforming to Annex K.","preparation":"- Audit architecture documentation.\n- Integrity protection mechanism specifications.\n- Prepare access to test audit records.","activities":"- Generate audit records.\n- Modify stored audit records without authorization.\n- Execute integrity verification procedures.\n- Verify that modifications are detected and reported.\n- Verify that integrity mechanisms are conform to Annex assessment requirements.","verdict":"- SUCCESS: Unauthorized modifications are reliably detected.\n- FAIL: Unauthorized modifications remain undetected.","evidence":"- Audit configuration.\n- Integrity verification reports.\n- Tampered audit records.\n- System logs.","guidance":""}},{"id":"REQ-PKI-INT-02","family":"INT - Monitoring","requirement":"The timestamp shall be in the scope of the integrity protection of the audit record (to prevent manipulation of the time stamp after the event).","applicability":{"UC1":"not-required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"UC2, UC3, UC4 and UC5.","rationale":"The audit record integrity and timestamping validity ensure that all auditable events are traceable and misuse of the product functions can be traced.","assessment":{"objective":"- Verify that timestamps are included within the integrity protection scope of audit records.","preparation":"- Audit record mechanisms documentation.\n- Integrity mechanism specifications.","activities":"- Generate audit records.\n- Modify timestamps without changing other fields.\n- Execute integrity verification.\n- Verify that timestamp modification is detected.","verdict":"- SUCCESS: Timestamp modifications invalidate integrity verification.\n- FAIL: Timestamp modifications are not detected.","evidence":"- Audit record format documentation.\n  - Test audit records.\n  - Integrity verification results.\n- Audit logs.","guidance":""}},{"id":"REQ-PKI-INT-03","family":"INT - Monitoring","requirement":"The product shall periodically create an audit log signing event in which it computes a digital signature, keyed hash, or authentication code over the entries in the audit log. For that it shall use state of the art cryptographic mechanisms as defined in Annex K.The digital signature, keyed hash, or authentication code shall be computed over, at least:\n- every entry that has been added to the audit log since the previous audit log signing event;\n- the digital signature, keyed hash, or authentication code from the previous audit log signed event. The digital signature, keyed hash, or authentication code from the audit log signing event shall be included in the audit log.\n\nNOTE: An audit log signing event is performed even if no entry was added to the audit log since the last one.","applicability":{"UC1":"not-required","UC2":"not-required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"UC3, UC4 and UC5.","rationale":"All entries of the audit log, and the order and exhaustivity of batches of entries should impact authenticity checks of the audit log. The audit record integrity ensure that all auditable events are traceable and misuse of the product functions can be traced.","assessment":{"objective":"- Verify that audit log integrity protection events are periodically created and include chaining of current and previous integrity protection events.","preparation":"- Audit signing specifications.\n- Scheduler configuration.\n- Prepare a test environment allowing audit event logging.","activities":"- Generate audit entries.\n- Trigger multiple signing events.\n- Verify that cryptographic integrity protection include all entries since the previous signing event.\n- Verify inclusion of the previous signature value.\n- Verify that signing events occur even when no entries have been added.\n- Verify that all cryptographic integrity protection mechanisms conform to Annex K assessment requirement.","verdict":"- SUCCESS: Periodic signed audit chains are correctly created.\n- FAIL: Signatures omit entries, omit previous signature values, or fail to execute.","evidence":"- Scheduler configuration.\n- Audit logs.\n- Signature records.\n- Integrity verification reports.","guidance":""}},{"id":"REQ-PKI-INT-04","family":"INT - Monitoring","requirement":"The product shall ensure the integrity of audit logs.\n\nNOTE: Not all integrity protection mechanisms can be foreseen so for use cases with lower regulation of standardization constraints (UC1, UC2) other approaches can be valid and so not identified here. Acceptable mechanisms include: append-only log storage, file-system integrity monitoring, hash-chained log entries, or forwarding to a trusted external log management system. The choice should be proportionate to the risk profile.","applicability":{"UC1":"not-required","UC2":"required","UC3":"not-required","UC4":"not-required","UC5":"not-required"},"applicabilityText":"UC2","rationale":"Integrity protection of audit logs ensures that all auditable events are traceable and that product operations can be reliably tracked for accountability and security monitoring. For that the product shall use state of the art cryptographic mechanisms as defined in Annex K.","assessment":{"objective":"- Verify that the product ensures the integrity of audit logs using appropriate protection mechanisms without Annex Conformant cryptographic mechanisms.","preparation":"- Obtain logging architecture documentation.\n- Obtain integrity protection configuration.","activities":"- Review implemented integrity mechanisms.\n- Attempt unauthorized modification, deletion, or insertion of log entries.\n- Verify that integrity violations are prevented or detected.\n- Verify operation of external logging mechanisms where implemented.","verdict":"- SUCCESS: Audit log integrity is maintained and violations are detected.\n- FAIL: Audit logs can be modified without detection.","evidence":"- Logging architecture.\n- Configuration files.\n- Audit records.\n- Tests records","guidance":""}},{"id":"REQ-PKI-INT-05","family":"INT - Monitoring","requirement":"The specified frequency at which the audit log signing event occurs shall be configurable.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","rationale":"The audit record integrity ensures that all auditable events are traceable and misuse of the product functions can be traced.","assessment":{"objective":"- Verify that the frequency of audit log signing events is configurable.","preparation":"- Administration documentation.\n- Configuration access.","activities":"- Review available configuration settings.\n- Modify integrity protection frequency parameters.\n- Verify that changes are applied.\n- Verify operation using multiple configured frequencies.","verdict":"- SUCCESS: Signing frequency is configurable and functions correctly.\n- FAIL: Signing frequency cannot be configured or configuration changes are ineffective.","evidence":"- Configuration files.\n- Administrative procedures.\n- System logs.\n- Test records.","guidance":""}},{"id":"REQ-PKI-INT-06","family":"INT - Certificate signing","requirement":"The product shall create certificate signature only by means of a Secure Cryptographic Device (SCD).","applicability":{"UC1":"not-required","UC2":"not-required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"UC3, UC4 and UC5","rationale":"To ensure trust the product software must rely on secure and valid key creation and management systems accessible only to authorised users provided by hardware security devices.","assessment":{"objective":"- Verify that certificate signatures are created exclusively using an SCD.","preparation":"- Certificate signing architecture documentation.\n- SCD integration documentation.","activities":"- Generate certificate signing requests.\n- Observe certificate signing operations.\n- Verify that private signing keys remain within the SCD.\n- Attempt signing operations without the SCD.","verdict":"- SUCCESS: Certificate signatures are generated exclusively through the SCD.\n- FAIL: Certificate signatures can be generated outside the SCD.","evidence":"- Architecture documentation.\n- SCD logs.\n- Certificate generation logs.\n- Test records.","guidance":""}},{"id":"REQ-PKI-INT-07","family":"INT - Certificate signing","requirement":"The cryptographic mechanisms used to create certificate signatures shall be as stated in Annex K.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","rationale":"The use of recognized and validated cryptographic algorithms is mandatory for a PKI and thus a product to ensure trust. Known weak or insufficiently validated algorithms are not allowed.","assessment":null},{"id":"REQ-PKI-INT-08","family":"INT- CRL signing","requirement":"The product shall create CRL signature only by means of a Secure Cryptographic Device (SCD).","applicability":{"UC1":"not-required","UC2":"not-required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"UC3, UC4 and UC5","rationale":"To ensure trust the product software must rely on secure and valid key creation and management systems accessible only to authorised users provided by hardware security devices.","assessment":{"objective":"- Verify that CRL signatures are created exclusively using an SCD.","preparation":"- Obtain CRL signing documentation.\n- Obtain SCD integration documentation.","activities":"- Generate CRLs.\n- Observe signing operations.\n- Verify that SCD logs identify the signature creation request and generation.\n- Verify that signing keys remain within the SCD.\n- Attempt CRL generation without the SCD.","verdict":"- SUCCESS: CRL signatures are generated only through the SCD.\n- FAIL: CRL signatures can be generated outside the SCD.","evidence":"- CRL generation logs.\n- SCD logs.\n- Architecture documentation.\n- Test reports.","guidance":"NOTE (Vandorisk): this is the draft's assessment case ACC-PKI-INT-07 (clause 6), matched to this requirement by its stated objective — the draft's assessment-case numbering does not align one-to-one with requirement ids."}},{"id":"REQ-PKI-INT-09","family":"INT- CRL signing","requirement":"The cryptographic mechanisms used to create CRL signatures shall be as stated in Annex K.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","rationale":"The use of recognized and validated cryptographic algorithms is mandatory for a PKI and thus a product to ensure trust. Known weak or insufficiently validated algorithms are not allowed.","assessment":null},{"id":"REQ-PKI-INT-10","family":"INT- CRL signing","requirement":"[CONDITIONAL] If Certificate Revocation Lists (CRLs) concerning end users certificates including any variants are used, the CRL shall be signed using a valid certificate.\n\nNOTE: This requirement is derived from CSS-6.3.9-08 contained in ETSI EN 319 411-1  [\\[i.10\\]](#_ref_i.10). Example of variant can be Delta CRLs.","applicability":{},"applicabilityText":"Where the product has a certificate status service, issuing CRLs.","rationale":"If the CRL is not signed by the CA or a TSP-appointed entity, it may be usurped to mislead end-users regarding a certificate's status.","assessment":{"objective":"- Verify that CRLs are digitally signed.","preparation":"- Determine whether CRLs are supported.\n- CRL signing procedures and trust model documentation.\n- Prepare certificate and signature validation tools.","activities":"- Generate CRLs.\n- Inspect the signer identity and signature information.\n- Verify that the signer corresponds to a CA (e.g. `basicConstraints` field contains `CA:TRUE`) or an authorized delegated entity (certificate with `keyUsage` including `cRLSign`).\n- Validate the digital signature.\n- Attempt to validate a CRL modified after signing.","verdict":"- SUCCESS:\n  - All CRLs are signed by authorized entities.\n  - Signature validation succeeds.\n  - Tampered CRLs fail validation.\n- FAIL:\n  - CRLs are unsigned.\n  - CRLs are signed by unauthorized entities.\n  - Signature validation does not detect tampering.","evidence":"- CRL samples.\n- Signature validation reports.\n- Trust model documentation.\n- Delegation documentation.\n- Test execution records.","guidance":"NOTE (Vandorisk): this is the draft's assessment case ACC-PKI-INT-08 (clause 6), matched to this requirement by its stated objective — the draft's assessment-case numbering does not align one-to-one with requirement ids."}}]},{"clause":"5.8","title":"Data minimisation","overview":"This clause addresses the requirements in the CRA [\\[i.1\\]](#_ref_i.1) Annex 1 Part 1 (2) (g).","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"REQ-PKI-DM-01","family":"DM - General","requirement":"The product shall only maintain configuration data sufficient to connect to other elements of the PKI system that the product serves.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"not-required","UC5":"required"},"applicabilityText":"UC1, UC2, UC3, and UC5","rationale":"Unnecessary network configuration elements add complexity and increase the potential attack surface.","assessment":{"objective":"- Determine whether the product only maintains network configuration data necessary for communication with PKI system elements required by the applicable use case and does not maintain unnecessary network configuration information.","preparation":"- Product architecture and deployment documentation.\n- List of external components and interfaces to connect to.\n- Access to configuration files, administrative guides, and installation procedures.","activities":"- Review the product design and configuration documentation.\n- Identify all stored network configuration parameters.\n- Verify that each configured endpoint, interface, protocol, and network parameter is required to support the applicable PKI use case.\n- Verify that no unused, unnecessary, or undocumented network configuration data are maintained.\n- Confirm that administrators cannot configure network connections unrelated to the PKI functions provided by the product.","verdict":"- SUCCESS:\n  - All maintained network configuration data are necessary for communication with PKI elements required by the applicable use case.\n  - No unnecessary network endpoints, protocols, interfaces, or configuration parameters are maintained.\n- FAIL:\n  - The product maintains network configuration data unrelated to the applicable PKI functions.\n  - Unnecessary interfaces or endpoints are configured or can be configured without operational justification.","evidence":"- Product architecture documentation.\n- Configuration files and parameter listings.\n- Assessment records demonstrating the review of network configuration parameters.","guidance":""}},{"id":"REQ-PKI-DM-02","family":"DM - General","requirement":"The product shall only maintain configuration data sufficient to provide PKC management functions.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"not-required","UC5":"required"},"applicabilityText":"UC1, UC2, UC3, and UC5","rationale":"Unnecessary PKC management function configurations (as defined per use case in Annex U) introduce unnecessary complexity and avoidable risks.","assessment":{"objective":"- Determine whether the product maintains only the configuration data required to implement the PKC management functions applicable to the use case.","preparation":"- Product configuration documentation.\n- List of implemented PKC management functions and associated configuration parameters.","activities":"1. Review the applicable use case requirements.\n2. Identify all PKC management functions implemented by the product.\n3. Review all PKC-related configuration parameters.\n4. Verify that each configuration item supports an identified PKC management function.\n5. Verify that unnecessary PKC management functions and associated configuration data are not maintained.","verdict":"- SUCCESS:\n  - All PKC configuration parameters support identified certificate management functions required by the applicable use case.\n  - No unnecessary PKC management functions or associated configuration data are maintained.\n- FAIL:\n  - Configuration data are maintained for PKC functions not required by the applicable use case.\n  - Unnecessary PKC management capabilities are present.","evidence":"- Use case analysis.\n- Configuration documentation.\n- Assessment records mapping configuration parameters to PKC functions.","guidance":"NOTE (Vandorisk): this is the draft's assessment case ACC-PKI-DM-03 (clause 6), matched to this requirement by its stated objective — the draft's assessment-case numbering does not align one-to-one with requirement ids."}},{"id":"REQ-PKI-DM-03","family":"DM - General","requirement":"The product shall only maintain and process user data necessary for certificate management.\n\nNOTE: Example of such data can be: certificate requests, updates, etc.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","rationale":"For each use case, only user data necessary for the certificate management functions identified in Annex U are required.","assessment":{"objective":"- Verify that the product only maintains and processes user data necessary for certificate management.","preparation":"- Access to the product's user data storage and certificate management logs.","activities":"- Review the user data stored and processed by the product.\n- Identify all user data related to certificate management (e.g., certificate requests, updates).\n- Verify that no unnecessary or unrelated user data is stored or processed.\n- Confirm that the stored and processed data is limited to what is required for certificate management.","verdict":"- SUCCESS: If the product only maintains and processes user data necessary for certificate management.\n- FAIL: If unnecessary or unrelated user data is found.","evidence":"- List of stored and processed user data.\n- Documentation or logs showing the alignment of user data with certificate management requirements.","guidance":"NOTE (Vandorisk): this is the draft's assessment case REQ-PKI-DM-02 (clause 6), matched to this requirement by its stated objective — the draft's assessment-case numbering does not align one-to-one with requirement ids."}},{"id":"REQ-PKI-DM-04","family":"DM - Secret management","requirement":"The product shall only create keys by means of a Secure Cryptographic Device (SCD) or remote Key Management System providing cryptographic mechanisms conform to the general state of the art as defined in Annex K.","applicability":{"UC1":"not-required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"UC2, UC3, UC4, UC5","rationale":"To ensure trust the product software must rely on secure and valid key creation and management systems accessible only to authorised users provided by hardware security devices.","assessment":{"objective":"- Determine whether all key generation operations are performed exclusively by Secure Cryptographic Devices (SCDs) or remote Key Management Systems (KMSs) implementing cryptographic mechanisms conformant with Annex K.","preparation":"- Cryptographic architecture documentation.\n- Documentation for the SCD or KMS.\n- Cryptographic algorithm specifications and configuration information.\n- Identify all key generation functions.","activities":"- Review the product's cryptographic architecture.\n- Identify all key generation operations.\n- Verify that keys are generated only by approved SCDs or remote KMSs.\n- Verify that no software-based key generation mechanism exists outside the SCD or KMS.\n- Verify that the cryptographic mechanisms used by the SCD or KMS conform to Annex K requirements.","verdict":"- SUCCESS:\n  - All key generation operations are delegated exclusively to approved SCDs or remote KMSs.\n  - The cryptographic mechanisms employed conform to Annex K requirements.\n- FAIL:\n  - Keys can be generated outside an SCD or KMS.\n  - The SCD or KMS uses non-approved cryptographic mechanisms.","evidence":"- Cryptographic architecture documentation.\n- SCD/KMS specifications and certifications.\n- Configuration files.\n- Assessment records demonstrating key generation paths.","guidance":""}}]},{"clause":"5.9","title":"Availability protection","overview":"This clause addresses the requirements in the CRA [\\[i.1\\]](#_ref_i.1) Annex 1 Part 1 (2) (h).\n\nThis clause considers that certificates status availability and trust are direct part of availability protection of the PKI service, since","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"REQ-PKI-AP-01","family":"AP - Certificate suspension and revocation","requirement":"Once a certificate has been revoked by means of REQ-PKI-EMM-08, it shall not be reinstated.","applicability":{},"applicabilityText":"All use cases where the product has a certificate generation service, issuing public-key certificates.","rationale":"Revocation is intended to be a definitive action, from which this requirement stems. Tampering certificates status can enable distrust when it becomes unclear if certificates are valid or not, thus it also tampers the availability of the service which consists in providing trust.","assessment":{"objective":"- Verify that revoked certificates cannot be returned to a valid status after revocation.","preparation":"- Certificate lifecycle management documentation.\n- Certificate status management procedures and configurations.\n- Prepare test certificates and authorized administrative accounts.","activities":"- Issue a test certificate.\n- Revoke the certificate using the supported revocation procedure.\n- Verify that the certificate status changes to revoked.\n- Attempt to reinstate, reactivate, or remove the revocation status of the certificate.\n- Verify that all attempts to restore the certificate to a valid state are rejected.","verdict":"- SUCCESS:\n  - Once revoked, the certificate permanently remains in the revoked state.\n  - No administrative interface or API permits reinstatement.\n- FAIL:\n  - A revoked certificate can be returned to a valid state.\n  - Revocation information can be modified to remove the revoked status.","evidence":"- Certificate lifecycle procedures.\n- Certificate status records.\n- Revocation logs.\n- Administrative interface screenshots.\n- Test execution records.","guidance":""}},{"id":"REQ-PKI-AP-02","family":"AP - Certificate suspension and revocation","requirement":"[CONDITIONAL] If Certificate Revocation Lists (CRLs) concerning end users certificates including any variants are used as defined and provide a nextUpdate field, every CRL shall state a time for next scheduled CRL issue, unless it is the last CRL issued for those certificates in the scope of the CRL, in which case the nextUpdate field in the CRL, shall be set to \"99991231235959Z\".\n\nNOTE: This requirement is derived from CSS-6.3.9-06 contained in ETSI EN 319 411-1 [\\[i.10\\]](#_ref_i.10)","applicability":{},"applicabilityText":"Where the product has a certificate status service, issuing CRLs according to REQ-PKI-EMM-08 and REQ-PKI-EMM-09.","rationale":"The inclusion of an expiry of the CRL's validity reduces the ability of an attacker to replay the CRL to its users, and enables caching for end-users. The special value of that field in the event the next update would be the CRL issuer expires ensures the status information is valid until that expiry.","assessment":{"objective":"- Verify that CRLs contain a valid `nextUpdate` field and that the special value `99991231235959Z` is used only for the final CRL.","preparation":"- Determine whether CRLs are supported.\n- CRL generation procedures and configuration documentation.\n- Prepare CRL inspection tools.","activities":"- Generate one or more CRLs.\n- Inspect the `nextUpdate` field in each CRL.\n- Verify that ordinary CRLs contain the next scheduled issue time.\n- Where applicable, generate the final CRL and verify that `nextUpdate` is set to `99991231235959Z`.\n- Verify that no non-final CRL uses the special value.","verdict":"- SUCCESS:\n  - All generated CRLs contain a valid `nextUpdate` field.\n  - The special value is used only for the final CRL.\n- FAIL:\n  - A CRL omits the `nextUpdate` field.\n  - The special value is incorrectly used or omitted.","evidence":"- CRL configuration files.\n- Generated CRLs.\n- CRL inspection outputs.\n- Test records.","guidance":""}},{"id":"REQ-PKI-AP-03","family":"AP - Certificate suspension and revocation","requirement":"[CONDITIONAL] If CARL is used, a new CARL shall be generated at least once a year with a nextUpdate of at most 1 year after the issuing date.\n\nNOTE: This requirement is derived from CSS-6.3.9-12 contained in ETSI EN 319 411-1  [\\[i.10\\]](#_ref_i.10)","applicability":{},"applicabilityText":"Where the product has a certificate status service issuing CARLs according.","rationale":"With respect to the severity of a CA compromission, a revocation should be made known as quickly as possible by immediately issuing a new CARL, rather than waiting for the next scheduled CARL.","assessment":{"objective":"- Verify that CARLs are generated at least annually and that the `nextUpdate` value does not exceed one year after issuance.","preparation":"- Determine whether CARLs are supported.\n- CARL generation procedures and scheduling configuration.\n- Prepare CARL inspection tools.\n- Product in executable state.","activities":"- Review CARL generation schedules.\n- Generate or inspect existing CARLs.\n- Verify the issuance dates and `nextUpdate` values.\n- Calculate the interval between issuance and `nextUpdate`.\n- Verify that the interval does not exceed one year.","verdict":"- SUCCESS:\n  - CARLs are generated at least once per year.\n  - `nextUpdate` is not more than one year after issuance.\n- FAIL:\n  - CARLs are not generated annually.\n  - `nextUpdate` exceeds one year.","evidence":"- CARL schedules.\n- Generated CARLs.\n- CARL inspection reports.\n- System logs.","guidance":""}},{"id":"REQ-PKI-AP-04","family":"AP - Certificate suspension and revocation","requirement":"[CONDITIONAL] If CARL is used, a new CARL shall be generated once a CA certificate has been revoked.\n\nNOTE: This requirement is derived from CSS-6.3.9-13 contained in ETSI EN 319 411-1  [\\[i.10\\]](#_ref_i.10)","applicability":{},"applicabilityText":"Where the product has a certificate status service, issuing CRLs or CARLs.","rationale":"With respect to the severity of a CA compromission, a revocation should be made known as quickly as possible by immediately issuing a new CARL, rather than waiting for the next scheduled CARL.","assessment":{"objective":"- Verify that revocation of a CA certificate immediately triggers generation of a new CARL.","preparation":"- Determine whether CARLs are supported.\n- Obtain CA revocation procedures and CARL generation procedures.\n- Prepare test CA certificates.\n- Product in executable state.","activities":"- Revoke a CA certificate.\n- Monitor the system response.\n- Verify that a new CARL is generated after revocation.\n- Verify that the revoked CA certificate is included in the CARL.\n- Verify that generation events are logged.","verdict":"- SUCCESS:\n  - A new CARL is generated after CA certificate revocation.\n  - The revoked CA certificate appears in the CARL.\n- FAIL:\n  - No new CARL is generated.\n  - The revoked CA certificate is omitted.","evidence":"- Revocation logs.\n- Generated CARLs.\n- System event logs.\n- Test reports.","guidance":""}},{"id":"REQ-PKI-AP-05","family":"AP - Certificate status services","requirement":"Revocation status information shall provide information on the status of certificates at least until the certificate expires.\n\nNOTE: This requirement is derived from CSS-6.3.10-04 contained in ETSI EN 319 411-1  [\\[i.10\\]](#_ref_i.10)","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","rationale":"If no revocation information status is available before the end of the validity of a certificate, its status becomes unknown and it cannot be trusted anymore.","assessment":{"objective":"- Verify that revocation status information remains available until certificate expiration.","preparation":"- Obtain certificate status service documentation.\n- Product in executable state.\n- Prepare certificates with varying validity periods.","activities":"- Issue and revoke test certificates.\n- Query certificate status information during the certificate validity period.\n- Verify that status information remains available until expiration.\n- Verify behavior immediately after expiration.","verdict":"- SUCCESS:\n  - Status information remains available until certificate expiration.\n- FAIL:\n  - Status information becomes unavailable before certificate expiration.","evidence":"- Status service configuration.\n  - Certificate status responses.\n  - Test records.\n- Service logs.","guidance":""}},{"id":"REQ-PKI-AP-06","family":"AP - Certificate status services","requirement":"OCSP or CRL shall be supported.\n\nNOTE: This requirement is derived from CSS-6.3.10-05 contained in ETSI EN 319 411-1  [\\[i.10\\]](#_ref_i.10)","applicability":{"UC1":"not-required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"UC2, UC3, UC4 and UC5.","rationale":"If no revocation information status is available before the end of the validity of a certificate, its status becomes unknown and it cannot be trusted anymore.","assessment":{"objective":"- Verify that the product supports at least one certificate status mechanism: OCSP or CRL.","preparation":"- Obtain product documentation.\n- Prepare OCSP and CRL validation tools.\n- Product in executable state.","activities":"- Identify supported certificate status services.\n- Verify configuration and operation of each supported service.\n- Query certificate status information.\n- Verify that responses accurately reflect certificate status.","verdict":"- SUCCESS:\n  - At least one certificate status mechanism is implemented and operational.\n- FAIL:\n  - Neither OCSP nor CRL functionality is supported.","evidence":"- Product documentation.\n- Configuration files.\n- Status responses.\n- Test records.","guidance":""}},{"id":"REQ-PKI-AP-07","family":"AP - Certificate status services","requirement":"If a product supports multiple methods to provide revocation status, the information provided by all services shall be consistent over time taking into account different delays in updating the status information for all the methods.\n\nNOTE: This is aligned with requirement CSS-6.3.10-09 contained in ETSI EN 319 411-1 [\\[5\\]](#_ref_5).\n\n<mark>Editor's Note: This reference is missing</mark>","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"not-required","UC5":"not-required"},"applicabilityText":"UC1, UC2 and UC3.","rationale":"The product shall provide accurate and integrity protected certificates status.","assessment":{"objective":"- Verify that multiple certificate status services provide consistent certificate status information.","preparation":"- Determine supported status mechanisms.\n- Prepare certificates and status query tools.\n- Product in executable state.","activities":"- Issue and revoke test certificates.\n- Query all supported status services.\n- Record responses over time.\n- Verify that status information remains consistent, considering expected propagation delays.\n- Verify that discrepancies are temporary and documented.","verdict":"- SUCCESS:\n  - All status mechanisms eventually provide consistent status information.\n  - Any temporary differences are within documented synchronization periods.\n- FAIL:\n  - Status information remains inconsistent.\n  - Different services provide contradictory certificate statuses.","evidence":"- Status service configurations.\n- Status responses.\n- Synchronization documentation.\n- Test reports.","guidance":""}},{"id":"REQ-PKI-AP-08","family":"AP - Key management","requirement":"The product shall be able to maintain multiple key pairs.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","rationale":"A product requires multiple key pairs to provide essential services, including: support for different authorities (e.g., root CA, intermediate CAs, end-entities), use of various cryptographic mechanisms (e.g., separate key pairs for signing and encryption), facilitation of key rotation and lifecycle management (e.g., active and backup keys), etc.","assessment":{"objective":"- Verify that the product can generate, store, and manage multiple key pairs simultaneously.","preparation":"- Key management documentation.\n- Prepare administrative access and test environments.\n- Product in executable state.","activities":"- Generate multiple key pairs.\n- Assign key pairs to different services, authorities, or purposes.\n- Verify that multiple key pairs coexist without conflict.\n- Verify that management operations can be performed independently on each key pair.\n- Verify support for key lifecycle activities such as activation and rotation.","verdict":"- SUCCESS:\n  - Multiple key pairs can be maintained simultaneously.\n  - Key management operations function independently for each key pair.\n- FAIL:\n  - Multiple key pairs cannot coexist.\n  - Management operations interfere with other key pairs.","evidence":"- Key management documentation.\n- Key inventories.\n- Administrative screenshots.\n- System logs.\n- Test records.","guidance":""}},{"id":"REQ-PKI-AP-09","family":"AP - Key management","requirement":"The product shall provide the capability for authorized users to delete keys.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","rationale":"Proper key management includes the capability for authorized users to delete key when necessary (as defined by the Certificate Policy).","assessment":{"objective":"- Verify that authorized users can delete keys and that unauthorized users cannot perform key deletion.","preparation":"- Key management procedures.\n- Prepare authorized and unauthorized user accounts for key deletion.\n- Generate test key pairs.","activities":"- Generate test key pairs.\n- Delete keys using authorized accounts.\n- Verify successful deletion and removal of associated key references.\n- Attempt key deletion using unauthorized accounts.\n- Verify that unauthorized deletion attempts are denied and logged.","verdict":"- SUCCESS:\n  - Authorized users can successfully delete keys.\n  - Unauthorized users cannot delete keys.\n  - Key deletion events are logged.\n- FAIL:\n  - Authorized users cannot delete keys.\n  - Unauthorized users can delete keys.\n  - Key deletion events are not properly recorded.\n  - Keys are still accessible or usable after erasure request.","evidence":"- Key management procedures.\n- Access control configurations.\n- System and audit logs.\n- Administrative screenshots.\n- Test execution records.","guidance":""}}]},{"clause":"5.10","title":"Impact minimisation","overview":"_Proposed ESR code: IM_\n\nThis clause addresses the requirements in the CRA [\\[i.1\\]](#_ref_i.1) Annex 1 Part 1 (2) (i).\n\nThe primary impact of a product on its environment is the unavailability of its services. PKI systems are passive systems that respond to requests from external entities. Therefore, minimizing the impact on other systems relies on the combination of requirements identified in clause 5 that collectively ensure the product correctly manages the Public Key Certificate (PKC) lifecycle and provides the appropriate level of trust to dependent systems.","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[]},{"clause":"5.11","title":"Minimisation of attack surfaces","overview":"_Proposed ESR code: MAS_\n\nThis clause addresses the requirements in the CRA [\\[i.1\\]](#_ref_i.1) Annex 1 Part 1 (2) (j).","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"REQ-PKI-MAS-01","requirement":"Only interfaces identified for each use case in Annex U shall be implemented.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","rationale":"Only interfaces implementing functions provided by each use case are necessary.","assessment":{"objective":"- Verify that the product implements only the interfaces required to support the use case as defined in Annex U.\n- Verify that no additional, undocumented, unnecessary, or unauthorized interfaces are present or accessible.","preparation":"- List of use case interfaces as defined in Annex U.\n- Product architecture documentation, interface specifications, and deployment documentation.\n- Identify all communication interfaces that may be exposed by the product, including:\n  - Network services and listening ports.\n  - Administrative interfaces.\n  - Web interfaces and APIs.\n  - Command-line interfaces.\n  - Database interfaces.\n  - File transfer interfaces.\n- Prepare test tools capable of identifying exposed interfaces (e.g., port scanners, API discovery tools, operating system service enumeration utilities).\n- Product in executable state","activities":"- Review the product documentation and identify all interfaces required by the use case.\n- Enumerate all implemented interfaces exposed by the product in its operational configuration.\n- For each discovered interface:\n  - Determine its purpose and associated functionality.\n  - Verify that it is explicitly required by the use case.\n- Attempt to identify undocumented or hidden interfaces by:\n  - Enumerating network ports and services.\n  - Inspecting running processes and service configurations.\n  - Discovering accessible APIs and endpoints.\n  - Reviewing installation packages and configuration files for additional services.\n- Verify that:\n  - No additional interfaces are active beyond those identified for the use case.\n  - Disabled or unsupported interfaces cannot be accessed or enabled without authorization.\n  - Administrative, debugging, maintenance, or test interfaces are either absent or explicitly identified and justified by the use case.\n- Document the mapping between each implemented interface and its corresponding Annex U use case.","verdict":"- SUCCESS:\n  - Every implemented interface can be mapped to one or more interface identified for the use cases in Annex U.\n  - No undocumented, unnecessary, or unauthorized interfaces are present.\n  - No hidden, debugging, maintenance, or test interfaces are accessible unless explicitly required by the use case.\n  - The implemented interfaces are limited to those necessary to provide the use case functionality.\n- FAIL:\n  - One or more implemented interfaces cannot be mapped to an interface required for the use cases.\n  - Additional, undocumented, or unnecessary interfaces are present or accessible.\n  - Hidden, debugging, maintenance, or test interfaces are exposed without explicit authorization or justification.","evidence":"- Interface inventory showing all implemented interfaces.\n- Mapping matrix between implemented interfaces and Annex U use case.\n- Results of network port scans and service enumeration.\n- API discovery results and endpoint listings, where applicable.\n- Screenshots or reports showing active services and interfaces.\n- Product documentation identifying required interfaces.\n- Test records demonstrating that no additional interfaces are present or accessible.","guidance":""}}]},{"clause":"5.12","title":"Exploitation mitigation mechanisms","overview":"This clause addresses the requirements in the CRA [\\[i.1\\]](#_ref_i.1) Annex 1 Part 1 (2) (k).\n\n**EMM - Certificate issuance** — To limit certificate forgery or misuse of certificate content, this section defines requirements for the PKI to enforce the use of standardized certificate formats and recognized cryptographic signature mechanisms.","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"REQ-PKI-EMM-01a","family":"EMM - Certificate issuance","requirement":"The format of the certificates issued by the certificate generation service shall comply with the X.509 standard ITU-T X.509 [\\[2\\]](#_ref_2) or functionally-equivalent standard.\n\nNOTE: [\\[2\\]](#_ref_2) is normatively referenced as a whole. Although certain clauses are not relevant, its requirements and definitions are interdependent and the standard shall therefore be considered in its entirety when assessing conformity.","applicability":{},"applicabilityText":"All use cases, not applicable if REQ-PKI-EMM-01b is used.","rationale":"Using normative formats ensures the interoperability of PKIs and enforces that certificate content contains only normalised and necessary information.","assessment":{"objective":"- Verify the certificates issued by the certificate generation service are public-key certificates or attribute certificates whose format complies with the X.509 standard ITU-T X.509 [\\[2\\]](#_ref_2).","preparation":"- Certificate request interface accessible.\n- Required user profiles defined to generate the certificate.\n- Certificate Policy parameters defined, i.e. product configuration realted to configurable certficate generation constraints (e.g. Certificate validaty periode, mandatory Certificate fields and values, etc.)","activities":"- Verify that certficates are correctly generated when correct information is provided.\n  - Provide a set of necessary and correct elements defined by the Certificate Policy.\n  - Generate, i.e. activate the certificate generation fonction with the correct inputs\n  - Verify that a certificate is generated including the inputed data\n  - Verify that the signature is correct and covers all the necessary fields\n  - Verify that certficates are not generated if inputed data are missing or incorrect related to the Certificate Policy configuratio\n  - Provide a set of necessary and correct elements defined by the Certificate Policy.\n  - Generate, i.e. activate the certificate generation fonction with the correct inputs\n  - Verify that a certificate is generated including the inputed data\n  - Verify that the signature is correct and covers all the necessary fields","verdict":"- SUCCESS: Certificates are generated only when all required and correct inputs are provided, conform to the X.509 format, correctly include the supplied data, and have a valid signature covering all required fields.\n- FAIL: Certificates are generated with missing or incorrect inputs, do not conform to the X.509 format, contain incorrect data, have an invalid signature, or omit required fields from signature protection.","evidence":"- Certificate generation requests parameters\n- Generated certficates or error messages generated by the product\n- Signature verification input and output","guidance":"NOTE (Vandorisk): this is the draft's assessment case ACC-PKI-EMM-01 (clause 6), matched to this requirement by its stated objective — the draft's assessment-case numbering does not align one-to-one with requirement ids."}},{"id":"REQ-PKI-EMM-01b","family":"EMM - Certificate issuance","requirement":"The format of the certificates issued by the certificate generation service shall comply with the IEEE 1609.2 standard,","applicability":{},"applicabilityText":"UC5 for C-ITS","rationale":"Using normative formats ensures the interoperability of PKIs and enforces that certificate content contains only normalised and necessary information.","assessment":null},{"id":"REQ-PKI-EMM-02","family":"EMM - Certificate issuance","requirement":"The product shall implement a certificate profile compliant to the base standard of REQ-PKI-EMM-01 (a or b) and appropriate to its scope/context  and shall ensure that issued certificates are consistent with that profile.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","rationale":"The specification of a specific certificate profile (e.g. by reference to applicable standards such as IETF RFC 5280  [\\[i.18\\]](#_ref_i.18)  or ETSI TS 103 097  [\\[i.19\\]](#_ref_i.19) ) is in scope of a Certificate Policy and out of the scope of the present document. However, requiring the implementation of a certificate profile ensures that authorized users can ensure interoperability of PKIs and that certificate content contains only normalised and necessary information to minimize attack surface.","assessment":{"objective":"Verify the product implements and follows a certificate profile for issued certificates.","preparation":"- Document the circumstances in which the certificate generation service may issue a certificate.\n- Ability to request a certificate issuance for the different identified circumstances.\n- Document the certificate profile implemented by the product.","activities":"For each way the product may issue a certificate:\n- issue a certificate;\n- verify the certificate to match the constraints of the certificate profile;\n- for all constraints of the certificate profile, attempt to issue a certificate disrespecting the constraint, and verify the issuance to fail.","verdict":"- SUCCESS: All documented certificate issuance scenarios produce certificates conforming to the documented certificate profile, and all attempts to violate profile constraints are rejected without issuing a non-conforming certificate.\n- FAIL: Any valid issuance scenario fails, any issued certificate does not conform to the documented certificate profile, or any profile constraint can be bypassed to issue a non-conforming certificate.","evidence":"- The documentation of certificate issuance circumstances;\n- the documentation of the certificate profile;\n- the way issuances were requested, and the responses and issued certificates from the product.","guidance":""}},{"id":"REQ-PKI-EMM-03","family":"EMM - Certificate issuance","requirement":"The product shall enable authorized users to specify the set of acceptable values for the following fields and extensions:\n- the authority key identifier (if applicable);\n- the algorithm identifier for the subject’s public/private key pair;\n- the identifier of the certificate issuer or of the issuing certificate;\n- the duration for which the certificate is valid.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","rationale":"Only valid certificates, as defined by authorized users in conformity with the PKI certificate policy, shall be generated by the product, inlcuding those fields.","assessment":{"objective":"Verify the product enables the authorized user to specify the set of acceptable values for the following fields and extensions:\n- the authority key identifier;\n- the algorithm identifier for the subject’s public/private key pair;\n- the identifier of the certificate issuer;\n- the length of time for which the certificate is valid.","preparation":"- Authorized user access, to enable configuration.\n- Ability to request a certificate issuance for the different identified circumstances.","activities":"- Configure a set of acceptable values for each of the identified fields and extensions, which does not contain all possible values.\n- For each way the product may issue a certificate:\n    - For each of the identified fields and extensions:\n        - attempt to issue a certificate, where all fields and extensions have acceptable values except the one being verified;\n        - verify the issuance to fail or to be impossible.","verdict":"- SUCCESS: The authorized users can configure restricted sets of acceptable values for all specified certificate fields and extensions, and any certificate request containing a non-acceptable value is rejected or cannot be issued.\n- FAIL: The product does not allow restricting acceptable values for one or more specified fields or extensions, or a certificate can be issued using a value outside the configured acceptable set.","evidence":"- The documentation of public-key certificate issuance circumstances;\n- The applied configuration of the identified fields and extensions;\n- the way issuances were requested, and the responses and issued certificates from the product.","guidance":""}},{"id":"REQ-PKI-EMM-04","family":"EMM - Certificate issuance","requirement":"The product shall enable authorized users to specify the set of acceptable values for the following fields and extensions:\n- keyUsage;\n- basicConstraints;\n- certificatePolicies.","applicability":{},"applicabilityText":"All use cases, applicable only if REQ-PKI-EMM-01a is used.","rationale":"Only valid certifcates as defined by the product service provider policies shall be generated by the product inlcuding those fields.","assessment":{"objective":"Verify that the product enables the authorized user to specify the set of acceptable values for the fields and extensions: keyUsage, basicConstraints, CertificatePolicies.","preparation":"- Certificate generation service documentation.\n- Authorized user access to certificate generation service and related configuration.","activities":"For each way the product may issue a public-key certificate:\n- verify that no certificate may be issued until acceptables values for the identified fields and extensions are set, i.e.:\n  - keyUsage;\n  - basicConstraints;\n  - CertificatePolicies.","verdict":"- SUCCESS: The product prevents the issuance of any public-key certificate until the authorized user has configured acceptable values for all necessary fields and extensions.\n- FAIL: A public-key certificate can be issued before acceptable values for one or more required fields or extensions have been configured by the authorized user.","evidence":"- The documentation of public-key certificate issuance circumstances;\n- the way issuances were requested, and the responses from the product.","guidance":""}},{"id":"REQ-PKI-EMM-05","family":"EMM - Certificate issuance","requirement":"The product shall mark the following extensions as critical:\n- keyUsage;\n- basicConstraints;\n- certificatePolicies.","applicability":{},"applicabilityText":"All use cases, applicable only if REQ-PKI-EMM-01a is used.","rationale":"Only valid certifcates as defined by the product service provider policies shall be generated by the product inlcuding those fields.","assessment":{"objective":"- Verify the product marks the keyUsage, basicConstraints and certificatePolicies as critical in issued certificates.","preparation":"Document the circumstances in which the certificate generation service may issue a public-key certificate. Ability to request a certificate issuance for the different identified circumstances.","activities":"For each way the product may issue a public-key certificate:\n- issue a certificate;\n- verify the keyUsage, basicConstraints and certificatePolicies extensions to be marked critical;\n- if applicable, attempt to issue a certificate with either extension marked not critical, and verify the issuance to fail.","verdict":"- SUCCESS: All issued public-key certificates mark the keyUsage, basicConstraints, and certificatePolicies extensions as critical, and any attempt to issue a certificate with these extensions marked non-critical is rejected.\n- FAIL: Any issued public-key certificate does not mark one or more of the required extensions as critical, or a certificate can be issued with one of these extensions marked non-critical.","evidence":"- The documentation of public-key certificate issuance circumstances;\n- The way issuances were requested, and the responses and issued certificates from the product.","guidance":""}},{"id":"REQ-PKI-EMM-06","family":"EMM - Certificate issuance","requirement":"The product shall disallow the keyUsage extension to simultaneously include values from:\n- digitalSignature, contentCommitment, keyCertSign, cRLSign; and\n- keyEncipherment, dataEncipherment, keyAgreement.","applicability":{},"applicabilityText":"U2, UC3, UC4, UC5, applicable only if REQ-PKI-EMM-01a is used.","rationale":"The same public key cannot be used for signature verification, and encryption or key agreement. Only valid certifcates as defined by the PKI service provider policies shall be generated by the product.","assessment":{"objective":"- Verify the product disallows the keyUsage extension to offer both digital signature and encryption or key agreement capabilities.","preparation":"Document the circumstances in which the certificate generation service may issue a public-key certificate. Ability to request a certificate issuance for the different identified circumstances.","activities":"For each way the product may issue a public-key certificate:\n- issue a certificate;\n- verify the keyUsage extension does not contain values from simultaneously:\n   - digitalSignature, contentCommitment, keyCertSign, cRLSign; and\n   - keyEncipherment, dataEncipherment, keyAgreement.\n- if applicable, attempt to issue such a certificate and verify the issuance to fail.","verdict":"- SUCCESS: No issued public-key certificate contains both signature capabilities (digitalSignature, contentCommitment, keyCertSign, cRLSign) and encryption or key agreement capabilities (keyEncipherment, dataEncipherment, keyAgreement) in the keyUsage extension, and any attempt to issue such a certificate is rejected.\n- FAIL: A public-key certificate is issued containing both signature and encryption or key agreement capabilities in the keyUsage extension, or an attempt to issue such a certificate is not rejected.","evidence":"- The documentation of public-key certificate issuance circumstances;\n- The way issuances were requested, and the responses and issued certificates from the product.","guidance":""}},{"id":"REQ-PKI-EMM-07","family":"EMM - Certificate issuance","requirement":"The product shall verify that the prospective certificate subject possesses the private key corresponding to the public key contained in the certificate request by means of a cryptographic challenge before issuing a certificate, unless the public/private key pair was generated by the product and has never left the certificate issuance service.","applicability":{},"applicabilityText":"U2, UC3, UC4, UC5.","rationale":"A subject bringing forth his own public key should prove ownership of the corresponding private key. The product can generate a key pair and associated public key, and later communicate the private key to the correct subject in a secure manner. This can notably be done for other components of the product itself needing public-key certificates. The same private key should not be owned by distinct subjects, including other services of the product; if the private key was generated by the product but already provided to the subject once, the subject can and should prove its ownership.","assessment":{"objective":"- Verify the product ensures a prospective certificate subject possesses the private key that corresponds to the public key in the certificate request before issuing a certificate, unless the private key never left the certificate issuance service.","preparation":"- Document the circumstances in which the certificate generation service may issue a public-key certificate.\n- Ability to request a certificate issuance.","activities":"For each way the product may issue a public-key certificate:\n- Attempt to issue a certificate with digital signature capabilities for a given public-key;\n  - if the product does not generate the key pair itself, or it has left the issuance service:\n    - provide an invalid signature when required;\n      - verify the issuance to fail;\n    - provide an valid signature when required;\n      - verify the issuance to succed.\n- Attempt to issue a certificate with encryption or key agreement capabilities for a given public-key;\n  - if the product does not generate the key pair itself, or it has left the issuance service:\n    - provide an invalid decryption when required;\n      - verify the issuance to fail.\n    - provide an valid decryption when required;\n      - verify the issuance to succed.\n- Among all the issuance attempts involving signing or decryption, verify the random value to sign or decrypt is always distinct, and their concatenation of high entropy.","verdict":"- SUCCESS: The product verifies proof of possession of the private key before issuing a certificate whenever the private key is external to the issuance service, rejects invalid signing or decryption proofs, and uses distinct, high-entropy challenge values.\n- FAIL: A certificate can be issued without valid proof of possession of the corresponding private key, invalid proofs are accepted, or the challenge values used for proof of possession are not distinct or sufficiently random.","evidence":"- The documentation of public-key certificate issuance circumstances;\n- The way issuances were requested, and the responses from the product;\n- The key pairs issued by the product if any, and how and when they were obtained;\n- The random values generated by the product.","guidance":""}},{"id":"REQ-PKI-EMM-08","family":"EMM - Certificate status","requirement":"The certificate status service shall provide certificate revocation statuses as either or both of:\n- CRLs as defined by and subject to the requirements of ITU-T X.509 [\\[2\\]](#_ref_2); or\n- OCSP responses to OCSP requests as defined by and subject to the requirements of RFC 6960 [\\[i.3\\]](#_ref_i.3).","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"not-required","UC5":"not-required"},"applicabilityText":"UC1, UC2 and UC3.","rationale":"The product shall provide accurate and integrity protected certificates statuseither using the standardised CRL format ensuring integrity of revocation list or protected OCSP services as defined by RFC 6960 [\\[i.3\\]](#_ref_i.3).","assessment":{"objective":"Verify the certificate revocation statuses to be either or both of CRLs as defined by and subject to the requirements of ITU-T X.509 [\\[2\\]](#_ref_2), or OCSP responses as defined by and subject to the requirements of RFC 6960 [\\[i.3\\]](#_ref_i.3).","preparation":"Document the circumstances in which the certificate generation service may issue a public-key certificate. Ability to request a certificate issuance. Ability to configure revocation aspects of the certificate profile if supported.","activities":"- Attempt to configure the certificate profile to not offer any revocation source in issued certificates;\n  - if successful, request a certificate for each way the product may issue a public-key certificate, and verify the issuances to fail.\n- For each way the product may successfully issue a public-key certificate:\n  - request a certificate;\n  - verify the issued certificate to contain information allowing a verifier to obtain a CRL or OCSP response.","verdict":"- SUCCESS: The product does not issue certificates without a configured revocation mechanism and all issued public-key certificates contain information enabling retrieval of a CRL and/or an OCSP response.\n- FAIL: The product issues certificates without a revocation source, or any issued public-key certificate lacks information enabling retrieval of a CRL or OCSP response.","evidence":"- The configuration attempts, or other evidence such configuration is not supported;\n- the way issuances were requested, and the responses from the product.","guidance":""}},{"id":"REQ-PKI-EMM-09","family":"EMM - Certificate status","requirement":"The product shall implement a CRL profile and shall ensure that issued CRls are consistent with that profile.","applicability":{},"applicabilityText":"Where the product has a certificate status service, issuing CRLs.","rationale":"The product shall provide accurate and integrity protected certificates statususing the standardised CRL format ensuring integrity of revocation list and conformity to the product service provider chosen policies.","assessment":{"objective":"- Verify the product implements and enforces a CRL profile for issued CRLs.","preparation":"- Ability to request a CRL as certificate status for a given certificate.\n- Documentation of the CRL profile implemented by the product.","activities":"- Request a CRL;\n- verify the CRL to match the constraints of the CRL profile.","verdict":"- SUCCESS: All issued CRLs conform to the documented CRL profile, including all required fields, formats, and constraints, and are successfully validated against the profile.\nFAIL: Any issued CRL does not conform to the CRL profile, is missing required elements, or violates any defined constraint in the CRL profile.","evidence":"The way the CRL was requested, and the response and CRL from the product.","guidance":""}},{"id":"REQ-PKI-EMM-10","family":"EMM - Certificate status","requirement":"The product shall enable authorized users to specify the set of acceptable values for the following CRL fields and extensions:\n- issuer;\n- issuerAltName;\n- nextUpdate.\n\nNOTE: The issuerAltName can be absent from the profile if issued certificates do not use it.","applicability":{},"applicabilityText":"Where the product has a certificate status service, issuing CRLs.","rationale":"The product shall provide accurate and integrity protected certificates statususing the standardised CRL format ensuring integrity of revocation list and conformity to the product service provider chosen policies.","assessment":{"objective":"Verify that the product enables authorized users to specify the set of acceptable values for the fields and extensions: `issuer`, `issuerAltName`,\n`nextUpdate`.","preparation":"authorized users access to not-installed or reinitialised product, or specifically its certificate status service and related configuration.","activities":"- Verify that authorized users can modify the `issuer`, `issuerAltName`, `nextUpdate`.\n- Verify that no CRL may be issued until acceptables values for the issuer, issuerAltName and nextUpdate fields and extensions are set.","verdict":"- SUCCESS: Authorized users can configure the acceptable values for `issuer`, `issuerAltName`, and `nextUpdate`, and no CRL can be issued until all required values are properly set.\n- FAIL: The product does not allow configuration of acceptable values for the required fields, or it issues CRLs before these values are fully defined.","evidence":"The way CRLs were requested, and the responses from the product.","guidance":""}},{"id":"REQ-PKI-EMM-11","family":"EMM - Certificate status","requirement":"The product shall implement an OCSP response profile and shall ensure that issued OCSP responses are consistent with that profile.","applicability":{},"applicabilityText":"Where the product has a certificate status service, issuing OCSP responses.","rationale":"The product shall provide accurate certificates statusas defined by the service provider chosen policies.","assessment":{"objective":"Verify the product implements and enforces an OCSP response profile for issued OCSP responses.","preparation":"Ability to request an OCSP response as certificate status for a given certificate. Document the OCSP response profile implemented by the product.","activities":"- Request an OCSP response;\n- verify the OCSP response to match the constraints of the OCSP response profile.","verdict":"- SUCCESS: All issued OCSP responses conform to the defined OCSP response profile, including all required constraints and structure validation.\n- FAIL: Any OCSP response is issued that does not conform to the OCSP response profile or violates its defined constraints.","evidence":"The way the OCSP response was requested, and the response and OCSP response from the product.","guidance":""}},{"id":"REQ-PKI-EMM-12","family":"EMM - Certificate status","requirement":"The product shall enable authorized users to specify the set of acceptable values for the responseType field.","applicability":{},"applicabilityText":"Where the product has a certificate status service, issuing OCSP responses, not restricted to the basic response type: UC1 and UC2.","rationale":"The product shall provide accurate certificates status as defined by the service provider chosen policies.","assessment":{"objective":"Verify that the product enables the authorized users to specify the set of acceptable values for the responseType field.","preparation":"Authorized users access to not-installed or reinitialised product, or specifically its certificate status service and related configuration.","activities":"Verify that no OCSP response may be issued until acceptable values for the responseType field are set.","verdict":"- SUCCESS: OCSP responses cannot be issued until acceptable values for the `responseType` field are configured.\n- FAIL: The product allows issuance of OCSP responses without configured acceptable values for `responseType`.","evidence":"The way OCSP responses were requested, and the responses and OCSP responses from the product.","guidance":""}},{"id":"REQ-PKI-EMM-13","family":"EMM - Certificate status","requirement":"The product shall enable authorized users to specify the set of acceptable values for the responderID field.\n\nNOTE: An OCSP responder is required to be capable to emit OCSP responses of the basic type by RFC 6960 [\\[i.3\\]](#_ref_i.3).","applicability":{},"applicabilityText":"Where the product has a certificate status service, issuing OCSP responses of the basic response type: UC1 and UC2.","rationale":"The product shall provide accurate certificates status as defined by the service provider chosen policies.","assessment":{"objective":"Verify that the product enables the authorized users to specify the set of acceptable values for the responderID field.","preparation":"Authorized users access to not-installed or reinitialised product, or specifically its certificate status service and related configuration.","activities":"Verify that no OCSP response may be issued until acceptable values for the responderID field are set.","verdict":"- SUCCESS: OCSP responses cannot be issued until acceptable values for the `responderID` field are configured.\n- FAIL: The product allows issuance of OCSP responses without configured acceptable values for `responderID`.","evidence":"The way OCSP responses were requested, and the responses and OCSP responses from the product.","guidance":""}},{"id":"REQ-PKI-EMM-14","family":"EMM - Certificate re-key","requirement":"In case of certificate re-key, any modified certified names or attributes shall be validated and updated registration information shall be recorded.","applicability":{},"applicabilityText":"All use cases where the product has a certificate generation service, issuing public-key certificates and supporting certificate re-key.","rationale":"The product should never issue a certificate without having validated all its certified names and attributes at some point in time. The product should possess accurate registration information regarding certificates it re-keys.","assessment":{"objective":"- Verify that during certificate re-key operations, any modified certified names or attributes are validated and that updated registration information is properly recorded.","preparation":"- Certificate generation service supporting certificate re-key is available.\n- Ability to request certificate re-key operations.\n- Administrator or authorized user access to registration information and configuration.","activities":"- Perform certificate re-key requests with modified certified names and/or attributes.\n- Verify that all modified values are validated before issuance.\n- Verify that updated registration information is recorded and associated with the re-keyed certificate.","verdict":"- SUCCESS: All modified certified names and attributes are validated prior to issuance, and updated registration information is correctly recorded for all certificate re-key operations.\n- FAIL: Any re-keyed certificate is issued without validating modified certified names or attributes, or updated registration information is not recorded.","evidence":"- Re-key request inputs and configuration.\n- Issued re-keyed certificates.\n- Validation logs or system responses.\n- Registration database or records showing updated information.","guidance":""}},{"id":"REQ-PKI-EMM-15","family":"EMM - Certificate modification","requirement":"In case of a request for certificate modification, any modified certified names or attributes shall be validated and updated registration information shall be recorded.\n\nNOTE: see ETSI 319 411-1 [\\[i.10\\]](#_ref_i.10) clause 6.3.8 for the definition of certificate modification.","applicability":{},"applicabilityText":"All use cases where the product has a certificate generation service, issuing public-key certificates and supporting certificate modification.","rationale":"The product should never issue a certificate without having validated all its certified names and attributes at some point in time. The product should possess accurate registration information regarding certificates it modifies.","assessment":{"objective":"- Verify that during certificate modification operations, any modified certified names or attributes are validated and updated registration information is recorded.","preparation":"- Certificate generation service supporting certificate modification is available.\n- Ability to request certificate modification operations.\n- Authorized user access to registration information and audit/configuration data.","activities":"- Perform certificate modification requests with changes to certified names and/or attributes.\n- Verify that all modified values are validated before issuance.\n- Verify that updated registration information is recorded and correctly linked to the modified certificate.","verdict":"- SUCCESS: All modified certified names and attributes are validated before issuance, and updated registration information is correctly recorded for all certificate modification operations.\n- FAIL: Any modified certificate is issued without validation of updated certified names or attributes, or updated registration information is not recorded.","evidence":"- Certificate modification request inputs.\n- Issued modified certificates.\n- Validation results and system logs.\n- Registration records reflecting updated certificate information.","guidance":""}}]},{"clause":"5.13","title":"Logging and monitoring","overview":"This clause addresses the requirements in the CRA [\\[i.1\\]](#_ref_i.1) Annex 1 Part 1 (2) (l).\n\nThese requirements are about the collection and handling of auditable events, that is, particular events happening during the product operations which require to be traced so as to allow an authorised third-party to audit the PKI's operation. A PKI may produce other types of logs that do not fall under these requirements.","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"REQ-PKI-MON-01","requirement":"The product shall record events related to all product functions identified for each use case (as defined in Annex U), as well as all privileged user login attempts and product updates.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","rationale":"All management functions of the PKI can impact the overall confidence in the system. Therefore, events related to Registration, Certificate Generation, Certificate Status, and Revocation Management must be recorded. Additionally, the management of privileged user accounts and their login activities must be logged to ensure accountability, which is critical for maintaining trust in the produced and managed PKI certificates.","assessment":{"objective":"- Verify that the product records audit events for:\n  - All product functions associated with the use cases defined in Annex U.\n  - All privileged user login attempts, including both successful and failed attempts.\n  - All product update activities.","preparation":"- List of PKI functions associated to the use cases as defined in Annex U.\n- List of privileged user roles supported by the product (e.g., PKI Administrator, Registration Authority Operator, Auditor, System Administrator).\n- Product in executable state and sufficient testing environment to activate desired functions.\n- Ensure the audit log storage is empty or note the current audit log state before testing.\n- Prepare test accounts for privileged users.","activities":"- Enable and verify audit logging functionality.\n- Execute each function identified in Annex U for the chosen use case.\n- For each executed function:\n  - Perform at least one successful operation.\n  - Where applicable, perform an unsuccessful or rejected operation.\n  - Verify that an audit event is generated.\n- Using privileged user accounts:\n  - Attempt successful logins.\n  - Attempt failed logins using invalid credentials.\n  - Attempt logins for disabled or locked accounts, if supported.\n  - Verify that each login attempt generates an audit event.\n- Perform one or more product update operations when they exist, such as:\n  - Software update installation.\n  - Configuration package update.\n  - Security patch application.\n  - Version upgrade.\n  - Verify that each update activity generates an audit event.","verdict":"- SUCCESS:\n  - Audit records are generated for all functions.\n  - Audit records are generated for all successful and failed privileged user login attempts.\n  - Audit records are generated for all product update activities.\n  - No required events are missing from the audit logs.\n- FAIL:\n  - One or more functions do not generate audit records.\n  - Privileged user login attempts are not consistently recorded.\n  - Product update activities are not recorded.\n  - Audit records lack sufficient information for accountability or traceability.\n  - Audit logging can be bypassed, disabled without authorization, or fails to capture required events.","evidence":"- Audit log extracts.\n- Screenshots or exported reports of the audit logging interface.\n- Test execution records mapping each test activity to its corresponding audit event.\n- List of executed test cases and their corresponding timestamps and log entries.","guidance":""}},{"id":"REQ-PKI-MON-02","requirement":"The product shall record within each audit record at least the following information:\n- Date and time of the event\n- Type of event\n- Subject identity (if applicable)\n- The outcome (success or failure) of the event\n\nNOTE: The audit shall not include in plaintext any secret keys or other critical security parameters.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","rationale":"The audit record timestamping and subject identification ensure that all auditable events are traceable and misuse of the product functions can be traced.","assessment":{"objective":"- Verify that the product records within each audit record the required information, and that these records do not include any secret key or other secret parameter in plaintext form.","preparation":"- Ability to trigger auditable events, and ability to audit events.","activities":"Trigger an auditable event. Access the corresponding audit record.\n - Verify the audit record contains at least:\n    - the date and time of the event;\n    - the type of the event;\n    - the subject identity (if applicable);\n    - the outcome of the event.\n- Perform the above for each audit event type, and verify that the audit record additionally contains the additional information specified by the developper.\n- For each information verified to be present, verify it matches the expected value given when and how the event was triggered.\n- For each of the generated audit record, verify that no private or symmetric key, as well as no other secret parameter is present in plaintext form.","verdict":"- SUCCESS: All audit records include required metadata (timestamp, event type, subject identity where applicable, outcome) and contain no secret or sensitive key material in plaintext.\n- FAIL: Audit records are missing required fields, contain incorrect values, or expose secret/sensitive key material in plaintext.","evidence":"The way the events were triggered and at what time, and the corresponding audit records.","guidance":""}},{"id":"REQ-PKI-MON-03","requirement":"The audit record shall identify the timing source used to generate the timestamp.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","rationale":"The audit record timestamping validity ensure that all auditable events are traceable and misuse of the product functions can be traced.","assessment":{"objective":"- Verify that the product employs reliable time stamps.","preparation":"- Ability to trigger auditable events, and ability to audit events.\n- Access to a trusted time stamp origin. Determine how the product determines its time stamps.","activities":"Trigger an auditable event. Access the corresponding audit record. Verify the date and time of the event to match the trusted time stamp origin.\n- Repeat the above several times from different accesses to the product in parallel and verify the produced time stamps from the product to be monotonic.\n- If the product may determine its time stamps by querying time information from a source it trusts, verify that it authenticates that source messages using state of the art mechanisms.\n- If the product may increment temporary or long-term time information stored locally, verify that the time information may not be used in data issued by the product until it has been properly been incremented, or alternatively that the service responsible for it cannot fail.","verdict":"- SUCCESS: Audit timestamps are reliable, monotonic where applicable, and securely derived from trusted and authenticated time sources or correctly maintained local time mechanisms.\n- FAIL: Audit timestamps are unreliable, non-monotonic, unauthenticated, or otherwise inconsistent with trusted time sources.","evidence":"- The way the events were triggered and at what time, and the corresponding audit records;\n- arguments relating to the authentication of a trusted source (if applicable);\n- arguments relating to the monotonicity of local time information (if applicable).","guidance":""}},{"id":"REQ-PKI-MON-04","requirement":"For audit events resulting from actions of identified users, the product shall be able to associate each auditable event with the identity of the user that caused the event.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases.","rationale":"The audit record integrity and timestamping validity ensure that all auditable events are traceable and misuse of the product functions can be traced.","assessment":{"objective":"- Verify that the product records within each audit record resulting from actions of identified users the corresponding user information.","preparation":"- Ability to identify to the product as a given user.\n- Ability to trigger auditable events as a user, and ability to audit events.","activities":"Identify to the product as the given user. Trigger an auditable event as the given user. Access the corresponding audit record.\n- Verify the audit record contains the identity of the user that caused the event.\n- Verify this identity to match that of the given user.","verdict":"- SUCCESS: Audit records cannot be deleted by unauthorized users, and all protected audit logs remain intact after attempted deletion actions.\n- FAIL: Unauthorized users can delete or alter audit records, or audit data is not preserved after deletion attempts.","evidence":"- The identity of the given user used for the test;\n- the way the event was triggered and at what time, and the corresponding audit record.","guidance":""}},{"id":"REQ-PKI-MON-05","requirement":"The product shall prevent auditable events, except those taken by the auditor, if the audit log is full.","applicability":{},"applicabilityText":"Not applicable where the product implements or supports automatic log management mechanisms (e.g. log rotation with archival, log pruning, log forwarding to an external system) ensuring continuity of audit recording without data loss. Otherwise applicable to","rationale":"If the PKI system is properly deployed—with appropriate policies, effective system management, and regular log reviews—an overload of logs should be seen as a symptom of a potentially significant security issue. In such cases, corrective actions should be taken before operations return to normal. Meanwhile, a full audit log should never result in the loss of old audit records or prevent future auditable events from being recorded.  The audit record integrity and availability ensure that all auditable events are traceable and misuse of the product functions can be traced.","assessment":{"objective":"- Verify the product's prevention of auditable events, except those taken by the auditor, if the audit log is full.","preparation":"- Ability to trigger auditable events, and ability to audit events. The maximum size of the audit log may be reduced.","activities":"Do not identify as an auditor to the product. Trigger auditable events until the audit log is full, or nearly so.\n- Verify that a given additional auditable event cannot be performed.\n- Identify as an auditor to the product.\n- Verify that a given additional auditable event may be triggered as the auditor.","verdict":"- SUCCESS: When the audit log is full, non-auditor actions are blocked while auditor actions remain permitted and correctly recorded.\n- FAIL: The system continues to allow non-auditor actions when the log is full, or improperly blocks auditor actions.","evidence":"- The configured maximum size of the audit log;\n- the size of the audit when full, or nearly so;\n- the way the additional event was attempted to be triggered, and the corresponding response from the product.","guidance":""}}]},{"clause":"5.14","title":"Data removal and transparency","overview":"This clause addresses the requirements in the CRA [\\[i.1\\]](#_ref_i.1) Annex 1 Part 1 (2) (m).","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[{"id":"REQ-PKI-DRT-01","family":"DRT - Secret management","requirement":"Public keys stored within the product, but not within a secure cryptographic device, shall be protected against undetected modification. If verification fails, the product shall not:\n- release the accessed public key to the caller; or\n- use the accessed public key.","applicability":{"UC1":"required","UC2":"required","UC3":"required","UC4":"required","UC5":"required"},"applicabilityText":"All use cases","rationale":"Unauthorized modifications of public keys stored by the product should not go undetected. Public keys modified without authorization should not be considered safe for use and not be disseminated throughout or outside the product.","assessment":{"objective":"- Verify that all public keys stored by the product outside of a secure cryptographic device are protected against undetected modification.\n- Verify that the product detects unauthorized modification of stored public keys before they are released or used.\n- Verify that, upon detection of a modification, the product does not release the public key to the requesting entity and does not use the modified public key for any cryptographic operation.","preparation":"- Identify all locations where public keys are stored outside secure cryptographic devices (e.g., databases, filesystems, configuration repositories, directories, caches, backups).\n- Identify the mechanisms used to protect public key integrity (e.g., digital signatures, hashes, message authentication codes, integrity checks).\n- Valid test public keys and associated integrity protection information.\n- Tools and permissions necessary to modify stored public key data and integrity protection data.","activities":"- Store one or more valid public keys in each identified and accessible storage location.\n- Access and use the stored public keys and verify that:\n  - Integrity verification is performed prior to release or use.\n  - Valid public keys are successfully released and used.\n- Modify a stored public key without updating its integrity protection information.\n- Attempt to access or use the modified public key and verify that:\n  - The integrity verification mechanism detects the modification.\n  - The modified public key is not returned to the requesting entity.\n  - The modified public key is not used in any cryptographic operation.\n- Attempt to perform cryptographic operations that depend on the modified public key and verify that such operations fail safely.\n- Review system logs and verify that integrity verification failures are appropriately recorded, where logging is implemented.","verdict":"- SUCCESS:\n  - All public keys stored outside secure cryptographic devices are protected by an integrity verification mechanism.\n  - Unauthorized modifications of stored public keys are reliably detected.\n  - Modified public keys are neither released nor used by the product.\n  - Cryptographic operations depending on modified public keys fail safely and predictably.\n- FAIL:\n  - A stored public key can be modified without detection.\n  - A modified public key is released to a none-authorized user.\n  - A modified public key is used by the product.\n  - Integrity verification mechanisms can be bypassed or are not consistently applied.\n  - Cryptographic operations continue using modified public keys.","evidence":"- Public key storage locations.\n  - Documentation of integrity protection mechanisms.\n  - Test records showing successful verification of valid public keys.\n  - Test records demonstrating detection of unauthorized modifications.\n  - Screenshots or log extracts showing integrity verification failures.\n- Evidence that modified public keys were neither released nor used.","guidance":""}},{"id":"REQ-PKI-DRT-02","family":"DRT - Secret management","requirement":"The product shall zeroize secrets in plaintext form.","applicability":{},"applicabilityText":"Where the product temporarily manipulates secrets in plaintext form.","rationale":"Zeroizing secrets reduces the compromission of secrets during the temporary compromission of a product component, to only secrets used while the compromission is in effect. This enables better tracing of what secrets were likely compromised.","assessment":{"objective":"- Verify that all secrets temporarily manipulated by the product in plaintext form are zeroized after use.\n- Verify that plaintext secrets are not retained in memory, temporary files, caches, or other storage locations beyond their required period of use.\n- Verify that secret zeroization occurs consistently during normal operation and error conditions.","preparation":"- Identify all secrets that may be temporarily manipulated in plaintext form, including:\n  - Private keys.\n  - Authentication credentials.\n  - Passphrases and passwords.\n  - Key-encryption keys.\n  - Session keys and other cryptographic secrets.\n- Identify all components and processes that temporarily process these secrets.\n- Documentation describing secret handling and zeroization mechanisms.\n- Tools capable of examining process memory, temporary files, and storage artifacts.","activities":"- Execute all functions that temporarily manipulate secrets in plaintext form.\n- During and after each operation, inspect:\n  - Process memory.\n  - Temporary files.\n  - Cache locations.\n  - Swap or paging areas, where applicable.\n  - Inter-process communication buffers, where applicable.\n- Verify that plaintext secrets are present only for the duration necessary to perform the operation.\n- Verify that plaintext secrets are overwritten or cleared immediately after use.\n- Induce abnormal conditions, including:\n  - Operation failures.\n  - Interrupted processing.\n  - Unexpected exceptions.\n  - Service restarts.\n- Verify that plaintext secrets are also zeroized following abnormal termination conditions.\n- Repeat the assessment for all identified components that temporarily manipulate secrets.","verdict":"- SUCCESS:\n  - All identified plaintext secrets are zeroized after use.\n  - Plaintext secrets are not retained in memory or temporary storage beyond their operational need.\n  - Zeroization occurs during both normal and abnormal execution paths.\n  - No recoverable plaintext secret material remains after completion of processing.\n- FAIL:\n  - One or more plaintext secrets remain accessible after use.\n  - Plaintext secrets persist in memory, temporary files, caches, or buffers beyond their required lifetime.\n  - Zeroization is not performed during abnormal termination conditions.\n  - Recoverable plaintext secret material can be obtained after the completion of processing.","evidence":"- Inventory of secrets manipulated in plaintext form.\n- Design documentation describing secret handling and zeroization mechanisms.\n- Memory analysis reports demonstrating the removal of plaintext secrets.\n- Inspection results for temporary files, caches, and storage artifacts.\n- Test records for normal and abnormal execution scenarios.\n- Screenshots, logs, or forensic reports demonstrating successful zeroization.","guidance":""}}]},{"clause":"5.15","title":"Vulnerability handling","overview":"This clause addresses the requirements in the CRA [\\[i.1\\]](#_ref_i.1) Annex 1 Part 2.\n\nThe requirements specified in CEN/CLC JT013090:2026 (CEN/CLC prEN 40000-1-3) [\\[i.17\\]](#_ref_i.17) shall be fulfilled for the product.","addressedBy":[],"otherRequirements":[],"mappingTable":{},"requirements":[]}],"annexK":{"general":"The assessment in clause K.1.2 verifies the cryptographic mechanisms used in the product’s default configuration against clause K.1.1.\n\nFor ACM-extended cryptographic mechanisms, the assessment verifies that the cryptographic mechanism is either listed in clause K.3.2 or fulfils the criteria specified in clause K.1.1 item 2.b. For interoperability-based cryptographic mechanisms, the assessment verifies that the cryptographic mechanism is listed in clause K.4.2. The assessment also verifies that the product uses the cryptographic mechanism in accordance with the relevant characteristics, product functions, use cases where applicable, external specifications or external requirements, and conditions specified in the present document.","cryptoConfigAssessments":{"acm-listed":{"objective":"The purpose of this assessment case is to verify that cryptographic mechanisms claimed to comply with clause K.1.1 item 1) and used in the product’s default configuration are listed in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [\\[1\\]](#_ref_1).","preparation":"- Preconditions for the assessment: The product’s default configuration shall be used for the assessment.\n- The documentation shall provide a list of cryptographic mechanisms used in the product’s default configuration and claimed under clause K.1.1 item 1), including the related product function, relevant parameters where applicable, and the relevant ACM entry.","activities":"The assessment shall include verification that:\n\n- a) each cryptographic mechanism claimed under clause K.1.1 item 1) is identified by reference to a relevant ACM entry;\n- b) the ACM entry corresponds to the cryptographic mechanism used in the product’s default configuration, including relevant parameters where applicable;\n- c) where the ACM entry includes lifecycle information, such as expiry date, deprecation date, migration condition or usage limitation, this information is reflected in the documentation.","evidence":"The assessment evidence shall include, as applicable:\n\n- a) description of the product’s default configuration;\n- b) list of cryptographic mechanisms claimed under clause K.1.1 item 1);\n- c) references to the relevant ACM entries;\n- d) relevant parameters, profiles, cipher suites or configuration constraints, where applicable;\n- e) relevant lifecycle information from the ACM catalogue, where applicable.","verdict":"- The verdict PASS shall be assigned if the required evidence has been provided, is complete, is applicable to the assessed configuration, and demonstrates compliance with clause K.1.1 item 1).\n- The verdict FAIL shall be assigned otherwise."},"acm-extended":{"objective":"The purpose of this assessment case is to verify that cryptographic mechanisms claimed to comply with clause K.1.1 item 2) and used in the product’s default configuration are either listed as ACM-extended cryptographic mechanisms in clause K.3.2 or fulfil the criteria specified in clause K.1.1 item 2.b, and are used for the claimed product function(s).","preparation":"- Preconditions for the assessment: The product’s default configuration shall be used for the assessment.\n- The documentation shall provide a list of cryptographic mechanisms used in the product’s default configuration and claimed under clause K.1.1 item 2), including the related product function, use case where applicable, relevant parameters where applicable, and at least one of the following:\n  - a) the relevant entry in clause K.3.2; or\n  - b) evidence that the cryptographic mechanism fulfils all applicable criteria in clause K.1.1 item 2.b.","activities":"The assessment shall include verification that:\n\n- a) each cryptographic mechanism claimed under clause K.1.1 item 2) is either listed in clause K.3.2 as an ACM-extended cryptographic mechanism or supported by evidence demonstrating fulfilment of the applicable criteria in clause K.1.1 item 2.b;\n- b) the cryptographic mechanism used by the product corresponds to the mechanism listed in clause K.3.2 or described in the evidence provided under clause K.1.1 item 2.b;\n- c) the product function using the cryptographic mechanism, and the use case where applicable, correspond to the related product function and use case specified in clause K.3.2 or justified under clause K.1.1 item 2.b;\n- d) the relevant characteristics, parameters, profiles, cipher suites or configuration constraints of the cryptographic mechanism correspond to those specified in clause K.3.2 or justified under clause K.1.1 item 2.b, where applicable;\n- e) where clause K.3.2 or the justification under clause K.1.1 item 2.b defines conditions or limitations for the use of the cryptographic mechanism, these conditions or limitations are reflected in the product’s default configuration;\n- f) where technically feasible, the cryptographic mechanism, parameters and configuration identified in the documentation correspond to the assessed product configuration.","evidence":"The assessment evidence shall include, as applicable:\n\n- a) description of the product’s default configuration;\n- b) list of cryptographic mechanisms claimed under clause K.1.1 item 2);\n- c) reference to the relevant entry in clause K.3.2, where the mechanism is listed in clause K.3.2;\n- d) evidence that the cryptographic mechanism fulfils the criteria in clause K.1.1 item 2.b, where compliance with clause K.1.1 item 2 is claimed on the basis of those criteria;\n- e) identification of the related product function using the cryptographic mechanism and the use case where applicable;\n- f) relevant characteristics, parameters, profiles, cipher suites or configuration constraints, where applicable;\n- g) evidence that the cryptographic mechanism is used in accordance with the conditions or limitations specified in clause K.3.2 or in the justification under clause K.1.1 item 2.b, where applicable.","verdict":"- The verdict PASS shall be assigned if the required evidence has been provided, is complete, is applicable to the assessed configuration, and demonstrates compliance with clause K.1.1 item 2).\n- The verdict FAIL shall be assigned otherwise."},"interoperability":{"objective":"The purpose of this assessment case is to verify that cryptographic mechanisms claimed to comply with clause K.1.1 item 3) and used in the product’s default configuration are listed as interoperability-based cryptographic mechanisms in clause K.4.2 and are used in accordance with the characteristics, product functions, use cases where applicable, external specifications or external requirements, and conditions specified in clause K.4.2.","preparation":"- Preconditions for the assessment: The product’s default configuration shall be used for the assessment.\n- The documentation shall provide a list of cryptographic mechanisms used in the product’s default configuration and claimed under clause K.1.1 item 3), including the related product function, use case where applicable, relevant parameters where applicable, the external specification or external requirement requiring its use, and the relevant entry in clause K.4.2.","activities":"The assessment shall include verification that:\n\n- a) each cryptographic mechanism claimed under clause K.1.1 item 3) is listed in clause K.4.2 as an interoperability-based cryptographic mechanism;\n- b) the cryptographic mechanism used by the product corresponds to the cryptographic mechanism listed in clause K.4.2;\n- c) the product function using the cryptographic mechanism, and the use case where applicable, correspond to the related product function and use case specified in clause K.4.2;\n- d) the external specification or external requirement requiring the use of the cryptographic mechanism corresponds to the external specification or external requirement specified in clause K.4.2;\n- e) the relevant characteristics, parameters, profiles, cipher suites or configuration constraints of the cryptographic mechanism correspond to those specified in clause K.4.2, where applicable;\n- f) the conditions or limitations specified in clause K.4.2 for the use of the cryptographic mechanism are reflected in the product’s default configuration;\n- g) where technically feasible, the cryptographic mechanism, parameters and configuration identified in the documentation correspond to the assessed product configuration.","evidence":"The assessment evidence shall include, as applicable:\n\n- a) description of the product’s default configuration;\n- b) list of cryptographic mechanisms claimed under clause K.1.1 item 3);\n- c) reference to the relevant entry in clause K.4.2;\n- d) identification of the related product function using the cryptographic mechanism and the use case where applicable;\n- e) identification of the external specification or external requirement requiring use of the cryptographic mechanism;\n- f) relevant characteristics, parameters, profiles, cipher suites or configuration constraints, where applicable;\n- g) evidence that the cryptographic mechanism is used in accordance with the conditions or limitations specified in clause K.4.2.","verdict":"- The verdict PASS shall be assigned if the required evidence has been provided, is complete, is applicable to the assessed configuration, and demonstrates compliance with clause K.1.1 item 3).\n- The verdict FAIL shall be assigned otherwise.\n\n> NOTE 1: The assessment of the external specification or external requirement itself is outside the scope of this assessment case. The assessment verifies that the external specification or external requirement is identified in clause K.4.2 and that the cryptographic mechanism is used by the product for the related product function.\n\n> NOTE 2: Documentation review is a minimum assessment activity under the present annex. Functional and/or resistance testing activities can be added by vertical standards where relevant for the product category, product function or cryptographic mechanism."}},"cryptoAgility":{"requirement":"Where the product’s default configuration uses a cryptographic mechanism for which the ACM catalogue, or the present document, specifies a deprecation date, expiry date, migration condition or usage limitation falling within the intended lifetime of the product, the product shall provide means for addressing the affected cryptographic mechanism by one or more of the following:\n\n- a) updating the cryptographic mechanism;\n- b) using another cryptographic mechanism that complies with clause K.1.1 and is not subject to the relevant deprecation date, expiry date, migration condition or usage limitation;\n- c) disabling the use of the affected cryptographic mechanism; or\n- d) limiting the use of the affected product functions accordingly.\n\n> EXAMPLE: Where a security mechanism uses a hybrid cryptographic construction, for example a hybrid key-encapsulation mechanism combining a classical and a post-quantum primitive, the lifecycle status of each constituent primitive is relevant to the lifecycle status of the construction. Hybridization can be used as part of a planned migration strategy where permitted by the ACM catalogue or by the present document. However, hybridization does not, by itself, extend the recommended usage lifetime of a constituent primitive that has been deprecated.\n\n> NOTE 1: Where a hybrid cryptographic construction includes multiple cryptographic primitives, the lifecycle status of each constituent primitive is relevant to the lifecycle status of the construction. Hybridization is not assumed to mitigate the deprecation of a constituent primitive unless the ACM catalogue or the present document classifies the hybrid construction as suitable for the corresponding product function.\n\n> NOTE 2: Crypto agility supports maintaining appropriate cryptographic protection within the intended lifetime of the product, in addition to the capability of updating cryptographic mechanisms on the product in accordance with secure update and secure communication mechanisms.\n\n> NOTE 3: Deprecation information from sources other than the ACM catalogue or the present document can be considered as input to vulnerability management or security risk assessment but does not by itself trigger the requirement in clause K.2.1.\n\n> NOTE 4: Where the product provides cryptographic capabilities for use by other products, components or layers, the mechanism required by clause K.2.1 can consist of update, configuration, disabling, deprecation or limitation capabilities usable by the integrating product, system operator or user, where applicable.\n\n> NOTE 5: The applicability condition of this requirement can express exceptions based on product characteristics, e.g. cryptographic implementation based on immutable hardware co-processor(s) or hardware-based root of trust, or long-lived silicon used in a long-lived non-updateable environment.","assessment":{"objective":"The purpose of this assessment case is to verify whether, where the product’s default configuration uses a cryptographic mechanism for which the ACM catalogue, or the present document, specifies a deprecation date, expiry date, migration condition or usage limitation falling within the intended lifetime of the product, the product provides means to address the affected cryptographic mechanism in accordance with clause K.2.1.","preparation":"- Preconditions for the assessment: The product’s default configuration shall be used for the assessment.\n- The documentation shall identify:\n  - a) the intended lifetime of the product;\n  - b) the cryptographic mechanisms used in the product’s default configuration;\n  - c) the related product function(s) for each cryptographic mechanism;\n  - d) the lifecycle information applicable to each cryptographic mechanism, where specified by the ACM catalogue or the present document, including any deprecation date, expiry date, migration condition or usage limitation.","activities":"The assessment shall include verification that:\n\n- a) for each cryptographic mechanism used in the product’s default configuration, the lifecycle information specified by the ACM catalogue or the present document has been identified, where such information is specified;\n- b) where the ACM catalogue or the present document specifies a deprecation date, expiry date, migration condition or usage limitation for a cryptographic mechanism, this information is reflected in the documentation;\n- c) where a deprecation date, expiry date, migration condition or usage limitation falls within the intended lifetime of the product, the product provides an applicable mechanism for updating the cryptographic mechanism, using another cryptographic mechanism that complies with clause K.1.1 and is not subject to the relevant deprecation date, expiry date, migration condition or usage limitation, disabling the use of the affected cryptographic mechanism, or limiting the use of the affected product functions accordingly;\n- d) where another cryptographic mechanism is used, that cryptographic mechanism complies with clause K.1.1 and is not subject to the relevant deprecation date, expiry date, migration condition or usage limitation.","evidence":"The assessment evidence shall include, as applicable:\n\n- a) documentation of the intended lifetime of the product;\n- b) list of cryptographic mechanisms used in the product’s default configuration;\n- c) identification of the related product function(s) for each cryptographic mechanism;\n- d) references to the ACM catalogue entry or to the provision of the present document used to determine lifecycle information, where applicable;\n- e) identification of any deprecation date, expiry date, migration condition or usage limitation falling within the intended lifetime of the product;\n- f) description of the means provided by the product, such as update of the cryptographic mechanism, use of another cryptographic mechanism that complies with clause K.1.1 and is not subject to the relevant lifecycle constraint, disabling the use of the affected cryptographic mechanism, or limitation of the use of the affected product functions.","verdict":"- The verdict PASS shall be assigned if the required evidence has been provided, is complete, is applicable to the assessed configuration, and demonstrates compliance with clause K.2.1.\n- The verdict FAIL shall be assigned otherwise."}}},"rdps":{"applicability":"","families":[],"requirements":[]},"threats":[],"draftGaps":["REQ-PKI-CON-02: no assessment case in this interim draft — clause 6.6 delegates this requirement's crypto-validity to the Annex K assessment; no dedicated assessment case exists.","REQ-PKI-CON-05: no assessment case in this interim draft — clause 6.6 delegates this requirement's crypto-validity to the Annex K assessment; no dedicated assessment case exists.","REQ-PKI-CON-06: no assessment case in this interim draft — clause 6.6 delegates this requirement's crypto-validity to the Annex K assessment; no dedicated assessment case exists.","REQ-PKI-CON-07: no assessment case in this interim draft — clause 6.6 delegates this requirement's crypto-validity to the Annex K assessment; no dedicated assessment case exists.","REQ-PKI-CON-08: no assessment case in this interim draft — clause 6.6 delegates this requirement's crypto-validity to the Annex K assessment; no dedicated assessment case exists.","REQ-PKI-INT-07: no assessment case in this interim draft — crypto-mechanism conformity is assessed under Annex K (clause 6.7 note; the note's id list erroneously names CON ids); no dedicated assessment case exists.","REQ-PKI-INT-09: no assessment case in this interim draft — crypto-mechanism conformity is assessed under Annex K (clause 6.7 note; the note's id list erroneously names CON ids); no dedicated assessment case exists.","REQ-PKI-EMM-01b: no assessment case in this interim draft — clause 6.12 carries only the X.509-specific ACC-PKI-EMM-01; the IEEE 1609.2 alternative has no assessment case.","The draft's clause 6 assessment-case numbering (ACC-PKI-…) does not align one-to-one with requirement ids: cases for Annex-K-delegated requirements are absent and the remaining cases are renumbered (e.g. ACC-PKI-CON-04 assesses REQ-PKI-CON-09, ACC-PKI-INT-08 assesses REQ-PKI-INT-10). The pack maps each case to its requirement by the case's stated objective; every non-trivial match carries a note in the assessment's guidance field.","Clause 6.8's second assessment block is labelled with the requirement id REQ-PKI-DM-02 instead of an ACC id, and its content is swapped with ACC-PKI-DM-03 relative to their labels: the REQ-PKI-DM-02-labelled block assesses user-data minimisation (REQ-PKI-DM-03) and ACC-PKI-DM-03 assesses PKC-management configuration data (REQ-PKI-DM-02). The pack maps both by content.","ACC-PKI-AAC-01 is a single assessment case for the RBAC user-profile requirements and is attached to both REQ-PKI-AAC-02 (UC1) and REQ-PKI-AAC-03 (UC2-UC5); the draft does not provide separate cases for the two role sets.","REQ-PKI-MON-05's applicability text breaks off mid-sentence in the draft (“Otherwise applicable to”); the per-use-case applicability is left unparsed.","REQ-PKI-EMM-06 and REQ-PKI-EMM-07 list “U2” (a typo for UC2) in their applicability; the conditional prose is kept verbatim and unparsed.","Clause 5.10 (Impact minimisation) and clause 5.15 (Vulnerability handling) define no requirement ids: 5.10 states the property is ensured by the other clause-5 requirements collectively (clause 6.10 likewise), and 5.15 delegates entirely to CEN/CLC prEN 40000-1-3.","Annex K's criterion K.1.1 item 2.b.ii still contains the skeleton placeholders “[list of organisations]” and “[list of catalogues]”, and clauses K.3.2/K.4.2 carry empty list tables.","Annex B's threat catalogue, risk evaluation and requirements-to-threats mapping exist only as embedded PNG figures in the markdown source; no threat list could be extracted (threats is empty).","Annex A's Part 2 row (vulnerability handling) maps to clause 5.15, which contains no assessable requirements in this pack; those obligations remain assessed through the horizontal CRA pack (II.1–II.8)."]}