ETSI EN 304 624

Cybersecurity (CYBER); CRA; Essential cybersecurity requirements for Public Key Infrastructure and digital certificate issuance software · vertical pack 0.1.0 · 69 clause-5 requirements · Annex K

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.

This is a vertical pack: a product-category standard, published in full and evaluated alongside the horizontal CRA rule pack— it supplements that pack for one Annex III category, it does not replace it. Everything below — every requirement, applicability entry, assessment block, correspondence row, threat and draft defect — is rendered from the same file the assessment engine reads. Nothing is generated at answer time, so this page cannot drift from what the product evaluates.

The same data, machine-readable, is served at /api/pack/vertical?id=en-304-624 — fetch it, keep a copy, and diff it when the draft moves. Because the standard is a moving draft, the source card pins exactly which text this pack was built from, and the draft gaps card records the defects we found in that text rather than papering over them.

On this page: source & license · how it attaches · requirement index · full text · Annex K · CRA correspondence · draft gaps · how it's built

Source, license and attribution

  • Source: https://labs.etsi.org/rep/stan4cra/en-304-624 (the ETSI Labs draft repository), commit adb0faa5, retrieved 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.

To be plain about what that means: the normative requirement and assessment text on this page is reproduced verbatim from the interim draft under the license above, with the required copyright notice, conditions and disclaimer preserved in full below. The draft is a consultation document, not an ETSI deliverable — approved versions of ETSI standards are available only from the ETSI Documentation Service, and nothing reproduced here confers any presumption of conformity.

Full license text
Copyright 2025 ETSI Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

How this pack attaches

The pack applies to products classified under the CRA Annex III item “Public key infrastructure and digital certificate issuance software” (pack category id: important-1). Attaches to a product whose CRA classification matched the Annex III PKI/certificate-issuance item, or manually. The horizontal CRA pack keeps evaluating the product either way; this pack adds the category-specific requirements on top.

Scope (the draft’s own)

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": - 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 - are only covered within the product context described in clause 4. The 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. Different 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.

Applicability (the draft’s own)

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. See the applicability fields associated with each technical cybersecurity requirement in the following Clause 5 subsections.

The 5 use cases

Applicability is declared per use case: the draft defines 5 product contexts, and each clause-5 requirement states, per use case, whether it is required. The index below renders every column; enabling the pack on an assessment means choosing one of these.

Private PKI for non critical sectorsUC1
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. In 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. Additionally, 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. > EXAMPLE 1: Products deployed to support software maintenance. > EXAMPLE 2: Products deployed to support internal IT service for network security deployments (e.g. VPN, ssh, TLS servers). > EXAMPLE 3: User management (identification and authentication) for services like User & Device Authentication, Single Sign-On (SSO).
Private PKI for critical entitiesUC2
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: - Network and physical security, - Encryption and access control of digital data, - Incident reporting obligations, - Compliance with secure operational practices. As 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. > EXAMPLE 1: Products deployed for Trust services. Software used to issue certificates for trust services including those used in electronic attribute attestation. > 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).
Public PKI for critical entitiesUC3
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. Such PKIs are deployed in highly controlled environments, including robust physical and logical security measures, along with strict policies and processes. > 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).
Public basic PKI for critical entitiesUC4
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. Such PKIs are deployed in highly controlled environments, including robust physical and logical security measures, along with strict policies and processes. > EXAMPLE 1: Products deployed for Trust services. Software used to issue certificates for trust services including those used in electronic attribute attestation.
Multi-authority PKI for critical entitiesUC5
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. The 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. > 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). > 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. > 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. > 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).

Requirement index

Every requirement in one place: the 69 clause-5 requirements with their per-use-case applicability. Ids link to the full verbatim text below; each row is addressable so a review can cite specific rows.

IdRequirement (first line)UC1UC2UC3UC4UC5
5.2 — No known exploitable vulnerabilities
REQ-PKI-KEV-01The product shall not contain known exploitable vulnerabilities, unless vulnerability assessment demonstrates that:●●●●●
5.3 — Secure by default configuration
REQ-PKI-SBDC-01All assets of the system shall be defined as protected assets with default access condition of DENY.●●●●●
REQ-PKI-SBDC-02The audit log integrity protection event shall be performed by default once a day.—●●●●
REQ-PKI-SBDC-03All cryptographic mechanisms shall be configured by default in conformity to the general state of the art as defined in Annex K.●●●●●
REQ-PKI-SBDC-04Certificates validity periode shall be limited to 3 years by default.●●●●●
5.4 — Secure updates
REQ-PKI-SU-01The 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.●●●●●
REQ-PKI-SU-02Where 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.●●●●●
REQ-PKI-SU-03The product administrator shall be able to configure when available updates are installed.●●●●●
5.5 — Authentication and access control
REQ-PKI-AAC-01Only authorized users shall be able to access product functionalities, stored data, and configuration data.●●●●●
REQ-PKI-AAC-02The 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:●————
REQ-PKI-AAC-03The product shall manage different user profiles, allowing RBAC. This mechanism shall provide means to define specific user account capabilities for the following roles:—●●●●
5.6 — Confidentiality
REQ-PKI-CON-01The 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.●————
REQ-PKI-CON-02Where 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.—●●●●
REQ-PKI-CON-03If 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.————●
REQ-PKI-CON-04If 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.●●●—●
REQ-PKI-CON-05A 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.—●●●●
REQ-PKI-CON-06The 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.●●●—●
REQ-PKI-CON-07The cryptographic mechanisms used to sign and verify content shall conform to the general state of the art, as defined in Annex K.●●●—●
REQ-PKI-CON-08The cryptographic mechanisms used to encrypt and decrypt content shall conform to the general state of the art, as defined in Annex K.●●●●●
REQ-PKI-CON-09The 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.—●●●●
REQ-PKI-CON-10When 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.●●———
REQ-PKI-CON-11Secret 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.—●●●●
5.7 — Integrity
REQ-PKI-INT-01The 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.—●●●●
REQ-PKI-INT-02The timestamp shall be in the scope of the integrity protection of the audit record (to prevent manipulation of the time stamp after the event).—●●●●
REQ-PKI-INT-03The 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:——●●●
REQ-PKI-INT-04The product shall ensure the integrity of audit logs.—●———
REQ-PKI-INT-05The specified frequency at which the audit log signing event occurs shall be configurable.●●●●●
REQ-PKI-INT-06The product shall create certificate signature only by means of a Secure Cryptographic Device (SCD).——●●●
REQ-PKI-INT-07The cryptographic mechanisms used to create certificate signatures shall be as stated in Annex K.●●●●●
REQ-PKI-INT-08The product shall create CRL signature only by means of a Secure Cryptographic Device (SCD).——●●●
REQ-PKI-INT-09The cryptographic mechanisms used to create CRL signatures shall be as stated in Annex K.●●●●●
REQ-PKI-INT-10[CONDITIONAL] If Certificate Revocation Lists (CRLs) concerning end users certificates including any variants are used, the CRL shall be signed using a valid certificate.●●●●●
5.8 — Data minimisation
REQ-PKI-DM-01The product shall only maintain configuration data sufficient to connect to other elements of the PKI system that the product serves.●●●—●
REQ-PKI-DM-02The product shall only maintain configuration data sufficient to provide PKC management functions.●●●—●
REQ-PKI-DM-03The product shall only maintain and process user data necessary for certificate management.●●●●●
REQ-PKI-DM-04The 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.—●●●●
5.9 — Availability protection
REQ-PKI-AP-01Once a certificate has been revoked by means of REQ-PKI-EMM-08, it shall not be reinstated.●●●●●
REQ-PKI-AP-02[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".●●●●●
REQ-PKI-AP-03[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.●●●●●
REQ-PKI-AP-04[CONDITIONAL] If CARL is used, a new CARL shall be generated once a CA certificate has been revoked.●●●●●
REQ-PKI-AP-05Revocation status information shall provide information on the status of certificates at least until the certificate expires.●●●●●
REQ-PKI-AP-06OCSP or CRL shall be supported.—●●●●
REQ-PKI-AP-07If 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.●●●——
REQ-PKI-AP-08The product shall be able to maintain multiple key pairs.●●●●●
REQ-PKI-AP-09The product shall provide the capability for authorized users to delete keys.●●●●●
5.10 — Impact minimisation
5.11 — Minimisation of attack surfaces
REQ-PKI-MAS-01Only interfaces identified for each use case in Annex U shall be implemented.●●●●●
5.12 — Exploitation mitigation mechanisms
REQ-PKI-EMM-01aThe 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.●●●●●
REQ-PKI-EMM-01bThe format of the certificates issued by the certificate generation service shall comply with the IEEE 1609.2 standard,●●●●●
REQ-PKI-EMM-02The 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.●●●●●
REQ-PKI-EMM-03The product shall enable authorized users to specify the set of acceptable values for the following fields and extensions:●●●●●
REQ-PKI-EMM-04The product shall enable authorized users to specify the set of acceptable values for the following fields and extensions:●●●●●
REQ-PKI-EMM-05The product shall mark the following extensions as critical:●●●●●
REQ-PKI-EMM-06The product shall disallow the keyUsage extension to simultaneously include values from:●●●●●
REQ-PKI-EMM-07The 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.●●●●●
REQ-PKI-EMM-08The certificate status service shall provide certificate revocation statuses as either or both of:●●●——
REQ-PKI-EMM-09The product shall implement a CRL profile and shall ensure that issued CRls are consistent with that profile.●●●●●
REQ-PKI-EMM-10The product shall enable authorized users to specify the set of acceptable values for the following CRL fields and extensions:●●●●●
REQ-PKI-EMM-11The product shall implement an OCSP response profile and shall ensure that issued OCSP responses are consistent with that profile.●●●●●
REQ-PKI-EMM-12The product shall enable authorized users to specify the set of acceptable values for the responseType field.●●●●●
REQ-PKI-EMM-13The product shall enable authorized users to specify the set of acceptable values for the responderID field.●●●●●
REQ-PKI-EMM-14In case of certificate re-key, any modified certified names or attributes shall be validated and updated registration information shall be recorded.●●●●●
REQ-PKI-EMM-15In case of a request for certificate modification, any modified certified names or attributes shall be validated and updated registration information shall be recorded.●●●●●
5.13 — Logging and monitoring
REQ-PKI-MON-01The 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.●●●●●
REQ-PKI-MON-02The product shall record within each audit record at least the following information:●●●●●
REQ-PKI-MON-03The audit record shall identify the timing source used to generate the timestamp.●●●●●
REQ-PKI-MON-04For 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.●●●●●
REQ-PKI-MON-05The product shall prevent auditable events, except those taken by the auditor, if the audit log is full.●●●●●
5.14 — Data removal and transparency
REQ-PKI-DRT-01Public 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:●●●●●
REQ-PKI-DRT-02The product shall zeroize secrets in plaintext form.●●●●●
5.15 — Vulnerability handling

● = required for that use case · — = not required. Use cases: UC1 Private PKI for non critical sectors · UC2 Private PKI for critical entities · UC3 Public PKI for critical entities · UC4 Public basic PKI for critical entities · UC5 Multi-authority PKI for critical entities.

5.2 — No known exploitable vulnerabilities

This clause addresses the requirements in the CRA [[i.1]](#_ref_i.1) Annex 1 Part 1 (2) (a).
REQ-PKI-KEV-01 — The product shall not contain known exploitable vulnerabilities, unless vulnerability assessmen…Clause 5.2

Requirement (verbatim from the interim draft)

The product shall not contain known exploitable vulnerabilities, unless vulnerability assessment demonstrates that: - the vulnerability is not exploitable in the product; or - specific user guidance is provided to prevent exploitation. NOTE: Details of the vulnerability assessment are provided in the vulnerability handling process defined in prEN 40000-1-3 [[i.17]](#_ref_i.17).

Applicability

All use cases.

Objective

Verify that: - Known exploitable vulnerabilities affecting the product are identified. - For each identified known exploitable vulnerability, one of the following applies: - the vulnerability assessment demonstrates that the vulnerability is not exploitable in the product; or specific user guidance is provided to prevent exploitation. - 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). - Component inventory, bill of materials, or equivalent software identification information, including version and patch-level information where available. - 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. - Vulnerability scanning tools and associated vulnerability databases suitable for identifying candidate vulnerabilities in the product. - Access to recognized public vulnerability sources: - Public databases e.g. EUVD, CISA Known Exploited Vulnerabilities (KEV) Catalog, the CVE List, the NIST National Vulnerability Database (NVD)) and relevant vendor advisories; - 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. - Perform vulnerability scanning, where technically feasible, on the product or relevant components to identify candidate vulnerabilities affecting elements contained in the product. - 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. - For each identified known exploitable vulnerability, review the vulnerability assessment and verify whether it demonstrates that the vulnerability is not exploitable in the product: - 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. - Verify that no identified known exploitable vulnerability affecting the product remains without: - a vulnerability assessment demonstrating non-exploitability in the product; or - 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. - 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 the standard asks for

- Vulnerability scanning results, including the tools and vulnerability databases used. - Recognized public vulnerability sources, vendor advisories, and product identification information used in the assessment. - Vulnerability assessment records and conclusions produced in accordance with prEN 40000-1-3 [[i.17]](#_ref_i.17). - REQ-PKI-AAC-01Product user guidance relied upon to prevent exploitation, where applicable.

5.3 — Secure by default configuration

SDBC- Access control — This clause addresses the requirements in the CRA [[i.1]](#_ref_i.1) Annex 1 Part 1 (2) (b).
REQ-PKI-SBDC-01 — All assets of the system shall be defined as protected assets with default access condition of…Clause 5.3

Requirement (verbatim from the interim draft)

All assets of the system shall be defined as protected assets with default access condition of DENY. NOTE 1: See also clause 5.5. EXAMPLE: 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

All use cases.

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. - Default access control policies, role definitions, and authorization matrices. - Administrator documentation describing access control configuration. - 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. - Review access control configurations and verify that the default decision for all protected assets is DENY. - Verify that access permissions are granted only through explicit authorization rules. - Attempt to access protected assets using unauthenticated and unauthorized accounts. - Verify that access requests without explicit permissions are denied in a deterministic manner.

Verdict

- SUCCESS: - All identified assets are configured by default as protected assets. - The default access condition for all assets is DENY. - Access is permitted only when explicitly authorized. - Unauthorized access attempts are consistently denied. - FAIL: - One or more assets are not protected. - The default policy allows access without explicit authorization. - Unauthorized access attempts result in successful access or inconsistent behavior.

Evidence the standard asks for

- System architecture and asset inventory documents. - Access control policy configuration files. - Role and permission matrices. - Screenshots or configuration exports showing default DENY settings. - Test execution records and access attempt logs.
REQ-PKI-SBDC-02 — The audit log integrity protection event shall be performed by default once a day.Clause 5.3

Requirement (verbatim from the interim draft)

The audit log integrity protection event shall be performed by default once a day.

Applicability

UC2, UC3, UC4 and UC5.

Rationale (the draft’s own)

The audit record integrity ensures that all auditable events are traceable and misuse of the product functions can be traced.

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. - (If available) Documentation describing the audit integrity protection mechanism. - System scheduling and logging configurations. - Test environment with audit logging enabled.

Activities

- Review the audit logging configuration. - Verify that audit log integrity protection is enabled by default. - Review scheduler configuration and verify that integrity protection events are configured to execute once every 24 hours. - 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). - Verify that evidence of execution is retained in logs or reports.

Verdict

- SUCCESS: - Audit log integrity protection is enabled by default. - The integrity protection event is automatically executed at least once every 24 hours. - Execution records are generated and retained. - FAIL: - Integrity protection is disabled by default. - The integrity protection event is not scheduled or does not execute daily. - No evidence of execution can be produced.

Evidence the standard asks for

- Audit logging configuration files. - Scheduler or cron configuration. - System logs showing execution timestamps. - Integrity verification reports. - Screenshots or configuration exports demonstrating default settings.
REQ-PKI-SBDC-03 — All cryptographic mechanisms shall be configured by default in conformity to the general state…Clause 5.3

Requirement (verbatim from the interim draft)

All cryptographic mechanisms shall be configured by default in conformity to the general state of the art as defined in Annex K.

Applicability

All use cases.

Rationale (the draft’s own)

Cf. Annex K rational.

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. - Default security configuration files. - (If available) Tools capable of inspecting cryptographic configurations and certificates.

Activities

- Identify all cryptographic mechanisms implemented by the system. - Review default cryptographic configurations, including algorithms, protocols, key lengths, and operational parameters. - Compare the default configurations against Annex K assessment requirements. - Verify that deprecated, weak, or non-approved cryptographic mechanisms are not enabled by default. - Verify that cryptographic defaults remain compliant following installation or initialization.

Verdict

- SUCCESS: - All cryptographic mechanisms use algorithms and parameters conformant with Annex K assessment requirements. - Default installation results in a compliant cryptographic configuration. - FAIL: - One or more cryptographic mechanisms do not conform to Annex K requirements. - Default configurations require manual modification to achieve compliance.

Evidence the standard asks for

- Cryptographic architecture documentation. - Default configuration files. - Configuration exports and screenshots. - Cryptographic parameter inspection outputs. - Mapping of implemented mechanisms to Annex K requirements. - Test reports demonstrating default compliance.
REQ-PKI-SBDC-04 — Certificates validity periode shall be limited to 3 years by default.Clause 5.3

Requirement (verbatim from the interim draft)

Certificates validity periode shall be limited to 3 years by default.

Applicability

All use cases.

Rationale (the draft’s own)

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.

Objective

- Verify that the default certificate issuance configuration limits certificate validity periods to a maximum of three years.

Preparation

- Certificate management documentation. - Defaualt certificate issuance policy and configuration files. - Environment capable of generating certificates using default settings. - Tools to parse certificate content.

Activities

- Review the certificate issuance configuration and policies. - Verify that the default certificate validity period is configured to be no greater than three years. - Generate one or more certificates using default settings. - Inspect the generated certificates and calculate the validity period using the `Not Before` and `Not After` fields or any other field providing validity duration.. - Verify that no certificate generated using default settings exceeds three years of validity.

Verdict

- SUCCESS: - The default certificate validity period is configured to a maximum of three years. - Certificates generated using default settings do not exceed three years of validity. - FAIL: - The default configuration allows certificate validity periods exceeding three years. - Certificates generated using default settings exceed the permitted validity period.

Evidence the standard asks for

- Certificate issuance policies and configuration files. - Generated test certificates. - Certificate inspection outputs (`Not Before` and `Not After` values). - Screenshots or configuration exports showing default validity settings. - Test execution records and assessment report.

5.4 — Secure updates

This clause addresses the requirements in the CRA [[i.1]](#_ref_i.1) Annex 1 Part 1 (2) (c).
REQ-PKI-SU-01 — The product shall support software update mechanisms, that allow to update every part of the pr…Clause 5.4

Requirement (verbatim from the interim draft)

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. NOTE: Part of the product's software can be immutable due to its technology (e.g. software installed in a ROM).

Applicability

All use cases.

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. - Determine which components are mutable and which are immutable (e.g., ROM-based). - Prepare a test environment with access to the product's update mechanisms.

Activities

- Attempt to update each mutable component of the product's software. - Verify that updates are successfully applied to all mutable components. - Confirm that immutable components (e.g., ROM-based) are not updated and that this is justified by technical constraints. - Document any components that cannot be updated and validate their immutability.

Verdict

- SUCCESS: - All mutable components can be updated. - Immutable components are correctly identified and justified. - FAIL: - Any mutable component cannot be updated. - Immutable components are not justified or incorrectly classified.

Evidence the standard asks for

- Logs or screenshots of successful updates for mutable components. - Documentation or technical specifications justifying immutability for excluded components. - Test reports confirming the update process.
REQ-PKI-SU-02 — Where an update is made available to the device it shall only be installed if it has been signe…Clause 5.4

Requirement (verbatim from the interim draft)

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

All use cases.

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. - Obtain an unsigned update or an update signed with an invalid/unknown key. - 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. - Attempt to install the unsigned update or update signed with an invalid key and verify it is rejected. - Check that the product validates the signature and PKC before installation. - Test edge cases, such as expired or revoked certificates.

Verdict

- SUCCESS: - Valid signed updates are installed. - Unsigned or invalidly signed updates are rejected. - FAIL: - Valid signed updates are rejected. - Unsigned or invalidly signed updates are accepted.

Evidence the standard asks for

- Logs or screenshots showing successful installation of valid updates. - Logs or screenshots showing rejection of unsigned or invalidly signed updates. - Test reports confirming signature and PKC validation.
REQ-PKI-SU-03 — The product administrator shall be able to configure when available updates are installed.Clause 5.4

Requirement (verbatim from the interim draft)

The product administrator shall be able to configure when available updates are installed. EXAMPLE: Options may include immediately on receipt, deferred to an agreed "maintenance" period.

Applicability

All use cases.

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. - 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. - Configure the product to defer updates to a specified maintenance to specify the set of acceptable values for the and verify the behavior. - Attempt to trigger an update under each configuration and confirm it follows the configured timing. - Verify that the administrator has sufficient control over the update timing.

Verdict

- SUCCESS: - The administrator can configure update timing options. - Updates are installed according to the configured timing (immediate or deferred). - FAIL: - The administrator cannot configure update timing. - Updates are not installed according to the configured timing.

Evidence the standard asks for

- Screenshots or logs of the administrator interface showing configuration options. - Test reports confirming updates are installed according to the configured timing. - Documentation of the update process under different configurations.

5.5 — Authentication and access control

This clause addresses the requirements in the CRA [[i.1]](#_ref_i.1) Annex 1 Part 1 (2) (d).
REQ-PKI-AAC-01 — Only authorized users shall be able to access product functionalities, stored data, and configu…Clause 5.5

Requirement (verbatim from the interim draft)

Only authorized users shall be able to access product functionalities, stored data, and configuration data. To 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

All use cases.

Rationale (the draft’s own)

Only authorized, identified, and authenticated users should be able to access product services and stored data. This addresses all relevant threats.

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. - Attempt to perform protected actions without being identified or authenticated. - Log in as authorized users, then try to intercept and replay user authentication data or session authentication tokens. - 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. - FAIL: If unauthorized access or incorrect rights assignment is detected.

Evidence the standard asks for

- Results of identification and authentication attempts (both successful and failed). - 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.
REQ-PKI-AAC-02 — The product shall manage different user profiles, allowing Role Based Access Control (RBAC). Th…Clause 5.5

Requirement (verbatim from the interim draft)

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: - U.Administrator This shall include at least the capability to limit user profile rigths for the following product actions and their associtated assets (): - Product audit & administration - F.UserAccountManagement - F.NetworkConfiguration - F.InternalKeyManagement - F.AuditEventManagement - F.LoggingOfSecurityEvents - F.CertificateProfileManagement

Applicability

UC1.

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. - For each account: - Attempt to log in using credentials from other accounts or invalid credentials. - Log in with the correct credentials for each account. - Verify that only the authorized actions defined by the user profile are accessible. - If the account is not authorized to, attempt to read stored data - If the account is not authorized to, attempt to read configuration data - If the account is not authorized to, attempt to modify stored data - If the account is not authorized to, attempt to modify configuration data - 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. - FAIL: if unauthorized access or incorrect rights assignment is detected.

Evidence the standard asks for

- Results of identification and authentication attempts (successful and failed). - List of validated functionalities and data access rights for each user profile. - 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.
REQ-PKI-AAC-03 — The product shall manage different user profiles, allowing RBAC. This mechanism shall provide m…Clause 5.5

Requirement (verbatim from the interim draft)

The product shall manage different user profiles, allowing RBAC. This mechanism shall provide means to define specific user account capabilities for the following roles: - U.Administrator, U.Officer, U.Auditor This 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: - Product audit & administration - F.UserAccountManagement - F.NetworkConfiguration - F.InternalKeyManagement - F.ExternalKeyManagement - F.AuditEventManagement - F.LoggingOfSecurityEvents - F.CertificateProfileManagement - Registration - F.OnlineRegService - F.CertificateDissemination - F.PrivateKeyImportExport - F.OfficerRegistrationApproval - Certificate generation - F.SCD_BasedKeyPairGen - F.NoneSCD_BasedKeyPairGen - F.SubjectCertSignCreation - F.OfficerCertGenApproval - F.PseudonymCertIssuance - Certificate status - F.CertificateStatus - Revocation management - F.RevocationManagement - F.OfficerRevocationApproval

Applicability

UC2, UC3, UC4 and UC5.

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. - For each account: - Attempt to log in using credentials from other accounts or invalid credentials. - Log in with the correct credentials for each account. - Verify that only the authorized actions defined by the user profile are accessible. - If the account is not authorized to, attempt to read stored data - If the account is not authorized to, attempt to read configuration data - If the account is not authorized to, attempt to modify stored data - If the account is not authorized to, attempt to modify configuration data - 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. - FAIL: if unauthorized access or incorrect rights assignment is detected.

Evidence the standard asks for

- Results of identification and authentication attempts (successful and failed). - List of validated functionalities and data access rights for each user profile. - 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.

5.6 — Confidentiality

This clause addresses the requirements in the CRA [[i.1]](#_ref_i.1) Annex 1 Part 1 (2) (e).
REQ-PKI-CON-01 — The product shall provide capabilities to ensure that the private key generated by the product…Clause 5.6

Requirement (verbatim from the interim draft)

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. NOTE: 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.

Rationale (the draft’s own)

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.

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. - Documentation describing private key generation, storage, and access controls. - Identify interfaces, APIs, administrative functions, backup mechanisms, and export capabilities that may provide access to private keys. - Access to authorized and unauthorized user accounts.

Activities

- (If available) Review the design of private key generation and storage mechanisms. - Verify that generated private keys are stored in protected locations or secure cryptographic devices. - Verify that export or copy operations require explicit authorization. - Attempt to access, export, copy, or remove private keys using unauthorized accounts and interfaces. - Verify that unauthorized operations are denied and appropriately logged. - Where controlled migration of key pairs is supported, verify that transfer is performed only under documented and authorized procedures.

Verdict

- SUCCESS: - Unauthorized users cannot access, export, copy, or remove private keys. - All key management interfaces enforce authorization controls. - Any permitted key transfer mechanisms are appropriately controlled and documented. - FAIL: - Unauthorized users can obtain, copy, export, or remove private keys. - Key protection mechanisms can be bypassed. - Key migration mechanisms lack appropriate controls.

Evidence the standard asks for

- Key management design documentation. - Access control configurations. - Security architecture diagrams. - Test results of attempted unauthorized exports. - Audit logs of key management operations. - Configuration files and screenshots.
REQ-PKI-CON-02 — Where the private key is stored in a cryptographically protected way, those cryptographic mecha…Clause 5.6

Requirement (verbatim from the interim draft)

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

UC2, UC3, UC4 and UC5

Rationale (the draft’s own)

Cf. Annex K rational.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-PKI-CON-03 — If a pseudonymous certificate is used to exchange a public key related to an ephemeral identity…Clause 5.6

Requirement (verbatim from the interim draft)

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

UC5

Rationale (the draft’s own)

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.

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. - The certificate profile specification, including all mandatory and optional certificate fields and extensions. - Pseudonymous certificates generated by the product. - Product configuration settings for certificate generation and identity management. - Tools for certificate parsing and inspection. - 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. - Examine the certificate profile and identify all fields and extensions included in the pseudonymous certificate. - 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: - Personally identifiable information (PII); - Persistent identifiers linked to a specific user or device; - Information that permits direct or indirect sender identification; - Values that can be correlated across multiple certificates to establish sender identity. - Verify that any included certificate information is strictly limited to technical information necessary for certificate validation and cryptographic operation. - Assess whether certificate serial number generation, extension values, and metadata are randomly generated or otherwise designed to prevent sender correlation. - Review product configuration and operational procedures to ensure that pseudonymous certificates cannot be configured to include identifying information. - Attempt to correlate multiple pseudonymous certificates issued to the same sender and determine whether any certificate data enables identity linkage.

Verdict

- SUCCESS: - The product generates pseudonymous certificates containing only technical information necessary for cryptographic processing and validation. - No certificate field or extension contains identifying information, persistent identifiers, or metadata that can directly or indirectly reveal the sender's identity. - Multiple certificates associated with the same sender cannot be correlated using certificate contents. - Product configuration prevents the inclusion of identifying information in pseudonymous certificates. - FAIL: - One or more certificate fields contain information that directly or indirectly identifies the sender. - Certificate contents include persistent identifiers or metadata that enable correlation of certificates belonging to the same sender. - Certificate serial numbers, extensions, naming conventions, or custom attributes permit sender re-identification. - Product configuration allows pseudonymous certificates to include user-related identifying information.

Evidence the standard asks for

- Product architecture and design documentation describing pseudonymous certificate generation. - Certificate profile specifications and extension definitions. - Parsed representations of sample pseudonymous certificates. - Configuration files and settings controlling certificate generation. - Assessment records demonstrating inspection of certificate fields and extensions. - Correlation analysis results showing that certificate contents cannot be used to identify or link the sender. - 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.
REQ-PKI-CON-04 — If the product sends data intended/labelled as personal or sensitive to another entity the prod…Clause 5.6

Requirement (verbatim from the interim draft)

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. NOTE: This includes any remote administration.

Applicability

UC1, UC2, UC3 and UC5

Rationale (the draft’s own)

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.

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. - Data classification documentation identifying personal and sensitive data. - Cryptographic configuration documentation. - Network monitoring tools. - Test environment including external components the product will connect to.

Activities

- Identify all interfaces transmitting personal or sensitive data. - Verify that transmitted data is protected by cryptographic mechanisms compliant with Annex K. - Capture network traffic during data transmission. Verify that sensitive information is not transmitted in plaintext.

Verdict

- SUCCESS: - All identified sensitive data transmissions are cryptographically protected. - The implemented cryptographic mechanisms conform to Annex K assessment requirement. - No sensitive data is observable in plaintext. - FAIL: - Sensitive data is transmitted without cryptographic protection. - Non-approved or weak cryptographic mechanisms are used. - Sensitive information can be recovered from network captures.

Evidence the standard asks for

- Data flow diagrams. - Data classification documentation. - Network packet captures. - Cryptographic configuration files. - Protocol inspection reports. - 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.
REQ-PKI-CON-05 — A public key certificate request containing explicit personal data shall be protected in integr…Clause 5.6

Requirement (verbatim from the interim draft)

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

UC2, UC3, UC4 and UC5

Rationale (the draft’s own)

Cf. Annex K rational.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-PKI-CON-06 — The product shall implement a chosen set of cryptographic algorithms to decrypt data that has b…Clause 5.6

Requirement (verbatim from the interim draft)

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, UC2, UC3 and UC5

Rationale (the draft’s own)

Communication with external components requires to encrypt use case sensitive data using state of the art mechanisms (cf. Annex K rational).

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-PKI-CON-07 — The cryptographic mechanisms used to sign and verify content shall conform to the general state…Clause 5.6

Requirement (verbatim from the interim draft)

The cryptographic mechanisms used to sign and verify content shall conform to the general state of the art, as defined in Annex K. NOTE: 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, UC2, UC3 and UC5

Rationale (the draft’s own)

Cf. Annex K rational.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-PKI-CON-08 — The cryptographic mechanisms used to encrypt and decrypt content shall conform to the general s…Clause 5.6

Requirement (verbatim from the interim draft)

The cryptographic mechanisms used to encrypt and decrypt content shall conform to the general state of the art, as defined in Annex K. NOTE: 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

All use cases where the product implements encryption mechanisms either for data storage or external communications.

Rationale (the draft’s own)

Cf. Annex K rational.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-PKI-CON-09 — The product shall be able to establish and maintain a secure link with the SCD or KMS, and that…Clause 5.6

Requirement (verbatim from the interim draft)

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

UC2, UC3, UC4, UC5.

Rationale (the draft’s own)

To ensure the secure key managment, the proper and secure use of external SCD or KMS is required.

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. - Product interface specifications and API documentation. - Cryptographic configuration documentation. - Running product with access to an operational SCD or KMS. - Network monitoring tools.

Activities

- Review the architecture and communication methods used with the SCD or KMS. - Verify that communications are protected using authenticated and encrypted channels. - Verify that only documented interfaces and APIs are invoked. - Observe key management operations that invoke the SCD or KMS. - Capture network traffic during data transmission and verify that sensitive information is not transmitted in plaintext. - Introduce communication failures or invalid requests and verify proper error handling. - Verify that security-relevant interactions are logged.

Verdict

- SUCCESS: - Secure authenticated communications with the SCD or KMS are established and maintained. - Only approved interfaces are used. - Communication failures are securely handled. - FAIL: - Communications occur without appropriate protection. - Undocumented or insecure interfaces are used. - Communication failures compromise security functions.

Evidence the standard asks for

- Architecture documentation. - Interface specifications. - Communication configuration files. - Network captures. - API invocation logs. - 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.
REQ-PKI-CON-10 — When the product exports private or symmetric keys it shall use state of the art cryptographic…Clause 5.6

Requirement (verbatim from the interim draft)

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. EXAMPLES: The exported private or symmetric key can be encrypted such that only its designated recipient can decrypt it.

Applicability

UC1 and UC2.

Rationale (the draft’s own)

A secret key should not be compromised if its exported form is intercepted.

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. - Obtain export procedures and cryptographic documentation. - Prepare test keys and export environments.

Activities

- Verify whether key export functionality is supported. - Review mechanisms protecting exported keys. - Export private and symmetric keys using supported procedures. - Verify that exported keys are encrypted using approved algorithms and key management procedures as defined by Annex K assessment requirements. - Attempt to access exported keys without possessing required decryption material.

Verdict

- SUCCESS: - Exported keys are protected using approved cryptographic mechanisms. - Unauthorized parties cannot recover exported key material. - FAIL: - Keys are exported in plaintext. - Weak or non-approved protection mechanisms are used. - Exported key material can be recovered without authorization.

Evidence the standard asks for

- Export procedures. - Cryptographic configurations. - Exported key files. - Key inspection results. - 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.
REQ-PKI-CON-11 — Secret keys shall not be stored persistently in plaintext form. They shall be stored within a s…Clause 5.6

Requirement (verbatim from the interim draft)

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

UC2, UC3, UC4, UC5.

Rationale (the draft’s own)

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.

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. - Database and filesystem documentation. - Access to storage repositories and backup media. - (If possible) Known private key content

Activities

- Identify all locations where secret keys may be stored. - Review storage mechanisms and encryption methods. - Inspect storage locations, backups, and configuration files for plaintext secret keys. - Verify that keys stored outside secure cryptographic devices are encrypted using approved mechanisms. - Verify that plaintext key access occurs only temporarily during cryptographic operations.

Verdict

- SUCCESS: - Secret keys are never persistently stored in plaintext. - Stored keys are protected by secure cryptographic devices or approved encryption mechanisms. - Plaintext access is temporary and limited to operational requirements. - FAIL: - Secret keys are persistently stored in plaintext. - Encryption mechanisms do not comply with Annex K. - Plaintext key exposure exceeds operational requirements.

Evidence the standard asks for

- Architecture documentation. - Storage configuration files. - Database and filesystem inspection results. - Backup inspection results. - 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.

5.7 — Integrity

This clause addresses the requirements in the CRA [[i.1]](#_ref_i.1) Annex 1 Part 1 (2) (f).
REQ-PKI-INT-01 — The product shall be able to detect unauthorised modifications to the stored audit records duri…Clause 5.7

Requirement (verbatim from the interim draft)

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

UC2, UC3, UC4 and UC5.

Rationale (the draft’s own)

The audit record integrity and availability ensure that all auditable events are traceable and misuse of the product functions can be traced.

Objective

- Verify that unauthorized modifications to stored audit records are detected using cryptographic integrity mechanisms conforming to Annex K.

Preparation

- Audit architecture documentation. - Integrity protection mechanism specifications. - Prepare access to test audit records.

Activities

- Generate audit records. - Modify stored audit records without authorization. - Execute integrity verification procedures. - Verify that modifications are detected and reported. - Verify that integrity mechanisms are conform to Annex assessment requirements.

Verdict

- SUCCESS: Unauthorized modifications are reliably detected. - FAIL: Unauthorized modifications remain undetected.

Evidence the standard asks for

- Audit configuration. - Integrity verification reports. - Tampered audit records. - System logs.
REQ-PKI-INT-02 — The timestamp shall be in the scope of the integrity protection of the audit record (to prevent…Clause 5.7

Requirement (verbatim from the interim draft)

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

UC2, UC3, UC4 and UC5.

Rationale (the draft’s own)

The audit record integrity and timestamping validity ensure that all auditable events are traceable and misuse of the product functions can be traced.

Objective

- Verify that timestamps are included within the integrity protection scope of audit records.

Preparation

- Audit record mechanisms documentation. - Integrity mechanism specifications.

Activities

- Generate audit records. - Modify timestamps without changing other fields. - Execute integrity verification. - Verify that timestamp modification is detected.

Verdict

- SUCCESS: Timestamp modifications invalidate integrity verification. - FAIL: Timestamp modifications are not detected.

Evidence the standard asks for

- Audit record format documentation. - Test audit records. - Integrity verification results. - Audit logs.
REQ-PKI-INT-03 — The product shall periodically create an audit log signing event in which it computes a digital…Clause 5.7

Requirement (verbatim from the interim draft)

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: - every entry that has been added to the audit log since the previous audit log signing event; - 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. NOTE: An audit log signing event is performed even if no entry was added to the audit log since the last one.

Applicability

UC3, UC4 and UC5.

Rationale (the draft’s own)

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.

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. - Scheduler configuration. - Prepare a test environment allowing audit event logging.

Activities

- Generate audit entries. - Trigger multiple signing events. - Verify that cryptographic integrity protection include all entries since the previous signing event. - Verify inclusion of the previous signature value. - Verify that signing events occur even when no entries have been added. - Verify that all cryptographic integrity protection mechanisms conform to Annex K assessment requirement.

Verdict

- SUCCESS: Periodic signed audit chains are correctly created. - FAIL: Signatures omit entries, omit previous signature values, or fail to execute.

Evidence the standard asks for

- Scheduler configuration. - Audit logs. - Signature records. - Integrity verification reports.
REQ-PKI-INT-04 — The product shall ensure the integrity of audit logs.Clause 5.7

Requirement (verbatim from the interim draft)

The product shall ensure the integrity of audit logs. NOTE: 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

UC2

Rationale (the draft’s own)

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.

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. - Obtain integrity protection configuration.

Activities

- Review implemented integrity mechanisms. - Attempt unauthorized modification, deletion, or insertion of log entries. - Verify that integrity violations are prevented or detected. - Verify operation of external logging mechanisms where implemented.

Verdict

- SUCCESS: Audit log integrity is maintained and violations are detected. - FAIL: Audit logs can be modified without detection.

Evidence the standard asks for

- Logging architecture. - Configuration files. - Audit records. - Tests records
REQ-PKI-INT-05 — The specified frequency at which the audit log signing event occurs shall be configurable.Clause 5.7

Requirement (verbatim from the interim draft)

The specified frequency at which the audit log signing event occurs shall be configurable.

Applicability

All use cases.

Rationale (the draft’s own)

The audit record integrity ensures that all auditable events are traceable and misuse of the product functions can be traced.

Objective

- Verify that the frequency of audit log signing events is configurable.

Preparation

- Administration documentation. - Configuration access.

Activities

- Review available configuration settings. - Modify integrity protection frequency parameters. - Verify that changes are applied. - Verify operation using multiple configured frequencies.

Verdict

- SUCCESS: Signing frequency is configurable and functions correctly. - FAIL: Signing frequency cannot be configured or configuration changes are ineffective.

Evidence the standard asks for

- Configuration files. - Administrative procedures. - System logs. - Test records.
REQ-PKI-INT-06 — The product shall create certificate signature only by means of a Secure Cryptographic Device (…Clause 5.7

Requirement (verbatim from the interim draft)

The product shall create certificate signature only by means of a Secure Cryptographic Device (SCD).

Applicability

UC3, UC4 and UC5

Rationale (the draft’s own)

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.

Objective

- Verify that certificate signatures are created exclusively using an SCD.

Preparation

- Certificate signing architecture documentation. - SCD integration documentation.

Activities

- Generate certificate signing requests. - Observe certificate signing operations. - Verify that private signing keys remain within the SCD. - Attempt signing operations without the SCD.

Verdict

- SUCCESS: Certificate signatures are generated exclusively through the SCD. - FAIL: Certificate signatures can be generated outside the SCD.

Evidence the standard asks for

- Architecture documentation. - SCD logs. - Certificate generation logs. - Test records.
REQ-PKI-INT-07 — The cryptographic mechanisms used to create certificate signatures shall be as stated in Annex…Clause 5.7

Requirement (verbatim from the interim draft)

The cryptographic mechanisms used to create certificate signatures shall be as stated in Annex K.

Applicability

All use cases.

Rationale (the draft’s own)

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.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-PKI-INT-08 — The product shall create CRL signature only by means of a Secure Cryptographic Device (SCD).Clause 5.7

Requirement (verbatim from the interim draft)

The product shall create CRL signature only by means of a Secure Cryptographic Device (SCD).

Applicability

UC3, UC4 and UC5

Rationale (the draft’s own)

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.

Objective

- Verify that CRL signatures are created exclusively using an SCD.

Preparation

- Obtain CRL signing documentation. - Obtain SCD integration documentation.

Activities

- Generate CRLs. - Observe signing operations. - Verify that SCD logs identify the signature creation request and generation. - Verify that signing keys remain within the SCD. - Attempt CRL generation without the SCD.

Verdict

- SUCCESS: CRL signatures are generated only through the SCD. - FAIL: CRL signatures can be generated outside the SCD.

Evidence the standard asks for

- CRL generation logs. - SCD logs. - Architecture documentation. - 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.
REQ-PKI-INT-09 — The cryptographic mechanisms used to create CRL signatures shall be as stated in Annex K.Clause 5.7

Requirement (verbatim from the interim draft)

The cryptographic mechanisms used to create CRL signatures shall be as stated in Annex K.

Applicability

All use cases.

Rationale (the draft’s own)

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.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-PKI-INT-10 — [CONDITIONAL] If Certificate Revocation Lists (CRLs) concerning end users certificates includin…Clause 5.7

Requirement (verbatim from the interim draft)

[CONDITIONAL] If Certificate Revocation Lists (CRLs) concerning end users certificates including any variants are used, the CRL shall be signed using a valid certificate. NOTE: 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

Where the product has a certificate status service, issuing CRLs.

Rationale (the draft’s own)

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.

Objective

- Verify that CRLs are digitally signed.

Preparation

- Determine whether CRLs are supported. - CRL signing procedures and trust model documentation. - Prepare certificate and signature validation tools.

Activities

- Generate CRLs. - Inspect the signer identity and signature information. - 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`). - Validate the digital signature. - Attempt to validate a CRL modified after signing.

Verdict

- SUCCESS: - All CRLs are signed by authorized entities. - Signature validation succeeds. - Tampered CRLs fail validation. - FAIL: - CRLs are unsigned. - CRLs are signed by unauthorized entities. - Signature validation does not detect tampering.

Evidence the standard asks for

- CRL samples. - Signature validation reports. - Trust model documentation. - Delegation documentation. - 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.

5.8 — Data minimisation

This clause addresses the requirements in the CRA [[i.1]](#_ref_i.1) Annex 1 Part 1 (2) (g).
REQ-PKI-DM-01 — The product shall only maintain configuration data sufficient to connect to other elements of t…Clause 5.8

Requirement (verbatim from the interim draft)

The product shall only maintain configuration data sufficient to connect to other elements of the PKI system that the product serves.

Applicability

UC1, UC2, UC3, and UC5

Rationale (the draft’s own)

Unnecessary network configuration elements add complexity and increase the potential attack surface.

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. - List of external components and interfaces to connect to. - Access to configuration files, administrative guides, and installation procedures.

Activities

- Review the product design and configuration documentation. - Identify all stored network configuration parameters. - Verify that each configured endpoint, interface, protocol, and network parameter is required to support the applicable PKI use case. - Verify that no unused, unnecessary, or undocumented network configuration data are maintained. - Confirm that administrators cannot configure network connections unrelated to the PKI functions provided by the product.

Verdict

- SUCCESS: - All maintained network configuration data are necessary for communication with PKI elements required by the applicable use case. - No unnecessary network endpoints, protocols, interfaces, or configuration parameters are maintained. - FAIL: - The product maintains network configuration data unrelated to the applicable PKI functions. - Unnecessary interfaces or endpoints are configured or can be configured without operational justification.

Evidence the standard asks for

- Product architecture documentation. - Configuration files and parameter listings. - Assessment records demonstrating the review of network configuration parameters.
REQ-PKI-DM-02 — The product shall only maintain configuration data sufficient to provide PKC management functio…Clause 5.8

Requirement (verbatim from the interim draft)

The product shall only maintain configuration data sufficient to provide PKC management functions.

Applicability

UC1, UC2, UC3, and UC5

Rationale (the draft’s own)

Unnecessary PKC management function configurations (as defined per use case in Annex U) introduce unnecessary complexity and avoidable risks.

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. - List of implemented PKC management functions and associated configuration parameters.

Activities

1. Review the applicable use case requirements. 2. Identify all PKC management functions implemented by the product. 3. Review all PKC-related configuration parameters. 4. Verify that each configuration item supports an identified PKC management function. 5. Verify that unnecessary PKC management functions and associated configuration data are not maintained.

Verdict

- SUCCESS: - All PKC configuration parameters support identified certificate management functions required by the applicable use case. - No unnecessary PKC management functions or associated configuration data are maintained. - FAIL: - Configuration data are maintained for PKC functions not required by the applicable use case. - Unnecessary PKC management capabilities are present.

Evidence the standard asks for

- Use case analysis. - Configuration documentation. - 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.
REQ-PKI-DM-03 — The product shall only maintain and process user data necessary for certificate management.Clause 5.8

Requirement (verbatim from the interim draft)

The product shall only maintain and process user data necessary for certificate management. NOTE: Example of such data can be: certificate requests, updates, etc.

Applicability

All use cases.

Rationale (the draft’s own)

For each use case, only user data necessary for the certificate management functions identified in Annex U are required.

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. - Identify all user data related to certificate management (e.g., certificate requests, updates). - Verify that no unnecessary or unrelated user data is stored or processed. - 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. - FAIL: If unnecessary or unrelated user data is found.

Evidence the standard asks for

- List of stored and processed user data. - 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.
REQ-PKI-DM-04 — The product shall only create keys by means of a Secure Cryptographic Device (SCD) or remote Ke…Clause 5.8

Requirement (verbatim from the interim draft)

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

UC2, UC3, UC4, UC5

Rationale (the draft’s own)

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.

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. - Documentation for the SCD or KMS. - Cryptographic algorithm specifications and configuration information. - Identify all key generation functions.

Activities

- Review the product's cryptographic architecture. - Identify all key generation operations. - Verify that keys are generated only by approved SCDs or remote KMSs. - Verify that no software-based key generation mechanism exists outside the SCD or KMS. - Verify that the cryptographic mechanisms used by the SCD or KMS conform to Annex K requirements.

Verdict

- SUCCESS: - All key generation operations are delegated exclusively to approved SCDs or remote KMSs. - The cryptographic mechanisms employed conform to Annex K requirements. - FAIL: - Keys can be generated outside an SCD or KMS. - The SCD or KMS uses non-approved cryptographic mechanisms.

Evidence the standard asks for

- Cryptographic architecture documentation. - SCD/KMS specifications and certifications. - Configuration files. - Assessment records demonstrating key generation paths.

5.9 — Availability protection

This clause addresses the requirements in the CRA [[i.1]](#_ref_i.1) Annex 1 Part 1 (2) (h). This clause considers that certificates status availability and trust are direct part of availability protection of the PKI service, since
REQ-PKI-AP-01 — Once a certificate has been revoked by means of REQ-PKI-EMM-08, it shall not be reinstated.Clause 5.9

Requirement (verbatim from the interim draft)

Once a certificate has been revoked by means of REQ-PKI-EMM-08, it shall not be reinstated.

Applicability

All use cases where the product has a certificate generation service, issuing public-key certificates.

Rationale (the draft’s own)

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.

Objective

- Verify that revoked certificates cannot be returned to a valid status after revocation.

Preparation

- Certificate lifecycle management documentation. - Certificate status management procedures and configurations. - Prepare test certificates and authorized administrative accounts.

Activities

- Issue a test certificate. - Revoke the certificate using the supported revocation procedure. - Verify that the certificate status changes to revoked. - Attempt to reinstate, reactivate, or remove the revocation status of the certificate. - Verify that all attempts to restore the certificate to a valid state are rejected.

Verdict

- SUCCESS: - Once revoked, the certificate permanently remains in the revoked state. - No administrative interface or API permits reinstatement. - FAIL: - A revoked certificate can be returned to a valid state. - Revocation information can be modified to remove the revoked status.

Evidence the standard asks for

- Certificate lifecycle procedures. - Certificate status records. - Revocation logs. - Administrative interface screenshots. - Test execution records.
REQ-PKI-AP-02 — [CONDITIONAL] If Certificate Revocation Lists (CRLs) concerning end users certificates includin…Clause 5.9

Requirement (verbatim from the interim draft)

[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". NOTE: This requirement is derived from CSS-6.3.9-06 contained in ETSI EN 319 411-1 [[i.10]](#_ref_i.10)

Applicability

Where the product has a certificate status service, issuing CRLs according to REQ-PKI-EMM-08 and REQ-PKI-EMM-09.

Rationale (the draft’s own)

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.

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. - CRL generation procedures and configuration documentation. - Prepare CRL inspection tools.

Activities

- Generate one or more CRLs. - Inspect the `nextUpdate` field in each CRL. - Verify that ordinary CRLs contain the next scheduled issue time. - Where applicable, generate the final CRL and verify that `nextUpdate` is set to `99991231235959Z`. - Verify that no non-final CRL uses the special value.

Verdict

- SUCCESS: - All generated CRLs contain a valid `nextUpdate` field. - The special value is used only for the final CRL. - FAIL: - A CRL omits the `nextUpdate` field. - The special value is incorrectly used or omitted.

Evidence the standard asks for

- CRL configuration files. - Generated CRLs. - CRL inspection outputs. - Test records.
REQ-PKI-AP-03 — [CONDITIONAL] If CARL is used, a new CARL shall be generated at least once a year with a nextUp…Clause 5.9

Requirement (verbatim from the interim draft)

[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. NOTE: This requirement is derived from CSS-6.3.9-12 contained in ETSI EN 319 411-1 [[i.10]](#_ref_i.10)

Applicability

Where the product has a certificate status service issuing CARLs according.

Rationale (the draft’s own)

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.

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. - CARL generation procedures and scheduling configuration. - Prepare CARL inspection tools. - Product in executable state.

Activities

- Review CARL generation schedules. - Generate or inspect existing CARLs. - Verify the issuance dates and `nextUpdate` values. - Calculate the interval between issuance and `nextUpdate`. - Verify that the interval does not exceed one year.

Verdict

- SUCCESS: - CARLs are generated at least once per year. - `nextUpdate` is not more than one year after issuance. - FAIL: - CARLs are not generated annually. - `nextUpdate` exceeds one year.

Evidence the standard asks for

- CARL schedules. - Generated CARLs. - CARL inspection reports. - System logs.
REQ-PKI-AP-04 — [CONDITIONAL] If CARL is used, a new CARL shall be generated once a CA certificate has been rev…Clause 5.9

Requirement (verbatim from the interim draft)

[CONDITIONAL] If CARL is used, a new CARL shall be generated once a CA certificate has been revoked. NOTE: This requirement is derived from CSS-6.3.9-13 contained in ETSI EN 319 411-1 [[i.10]](#_ref_i.10)

Applicability

Where the product has a certificate status service, issuing CRLs or CARLs.

Rationale (the draft’s own)

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.

Objective

- Verify that revocation of a CA certificate immediately triggers generation of a new CARL.

Preparation

- Determine whether CARLs are supported. - Obtain CA revocation procedures and CARL generation procedures. - Prepare test CA certificates. - Product in executable state.

Activities

- Revoke a CA certificate. - Monitor the system response. - Verify that a new CARL is generated after revocation. - Verify that the revoked CA certificate is included in the CARL. - Verify that generation events are logged.

Verdict

- SUCCESS: - A new CARL is generated after CA certificate revocation. - The revoked CA certificate appears in the CARL. - FAIL: - No new CARL is generated. - The revoked CA certificate is omitted.

Evidence the standard asks for

- Revocation logs. - Generated CARLs. - System event logs. - Test reports.
REQ-PKI-AP-05 — Revocation status information shall provide information on the status of certificates at least…Clause 5.9

Requirement (verbatim from the interim draft)

Revocation status information shall provide information on the status of certificates at least until the certificate expires. NOTE: This requirement is derived from CSS-6.3.10-04 contained in ETSI EN 319 411-1 [[i.10]](#_ref_i.10)

Applicability

All use cases.

Rationale (the draft’s own)

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.

Objective

- Verify that revocation status information remains available until certificate expiration.

Preparation

- Obtain certificate status service documentation. - Product in executable state. - Prepare certificates with varying validity periods.

Activities

- Issue and revoke test certificates. - Query certificate status information during the certificate validity period. - Verify that status information remains available until expiration. - Verify behavior immediately after expiration.

Verdict

- SUCCESS: - Status information remains available until certificate expiration. - FAIL: - Status information becomes unavailable before certificate expiration.

Evidence the standard asks for

- Status service configuration. - Certificate status responses. - Test records. - Service logs.
REQ-PKI-AP-06 — OCSP or CRL shall be supported.Clause 5.9

Requirement (verbatim from the interim draft)

OCSP or CRL shall be supported. NOTE: This requirement is derived from CSS-6.3.10-05 contained in ETSI EN 319 411-1 [[i.10]](#_ref_i.10)

Applicability

UC2, UC3, UC4 and UC5.

Rationale (the draft’s own)

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.

Objective

- Verify that the product supports at least one certificate status mechanism: OCSP or CRL.

Preparation

- Obtain product documentation. - Prepare OCSP and CRL validation tools. - Product in executable state.

Activities

- Identify supported certificate status services. - Verify configuration and operation of each supported service. - Query certificate status information. - Verify that responses accurately reflect certificate status.

Verdict

- SUCCESS: - At least one certificate status mechanism is implemented and operational. - FAIL: - Neither OCSP nor CRL functionality is supported.

Evidence the standard asks for

- Product documentation. - Configuration files. - Status responses. - Test records.
REQ-PKI-AP-07 — If a product supports multiple methods to provide revocation status, the information provided b…Clause 5.9

Requirement (verbatim from the interim draft)

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. NOTE: This is aligned with requirement CSS-6.3.10-09 contained in ETSI EN 319 411-1 [[5]](#_ref_5). <mark>Editor's Note: This reference is missing</mark>

Applicability

UC1, UC2 and UC3.

Rationale (the draft’s own)

The product shall provide accurate and integrity protected certificates status.

Objective

- Verify that multiple certificate status services provide consistent certificate status information.

Preparation

- Determine supported status mechanisms. - Prepare certificates and status query tools. - Product in executable state.

Activities

- Issue and revoke test certificates. - Query all supported status services. - Record responses over time. - Verify that status information remains consistent, considering expected propagation delays. - Verify that discrepancies are temporary and documented.

Verdict

- SUCCESS: - All status mechanisms eventually provide consistent status information. - Any temporary differences are within documented synchronization periods. - FAIL: - Status information remains inconsistent. - Different services provide contradictory certificate statuses.

Evidence the standard asks for

- Status service configurations. - Status responses. - Synchronization documentation. - Test reports.
REQ-PKI-AP-08 — The product shall be able to maintain multiple key pairs.Clause 5.9

Requirement (verbatim from the interim draft)

The product shall be able to maintain multiple key pairs.

Applicability

All use cases.

Rationale (the draft’s own)

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.

Objective

- Verify that the product can generate, store, and manage multiple key pairs simultaneously.

Preparation

- Key management documentation. - Prepare administrative access and test environments. - Product in executable state.

Activities

- Generate multiple key pairs. - Assign key pairs to different services, authorities, or purposes. - Verify that multiple key pairs coexist without conflict. - Verify that management operations can be performed independently on each key pair. - Verify support for key lifecycle activities such as activation and rotation.

Verdict

- SUCCESS: - Multiple key pairs can be maintained simultaneously. - Key management operations function independently for each key pair. - FAIL: - Multiple key pairs cannot coexist. - Management operations interfere with other key pairs.

Evidence the standard asks for

- Key management documentation. - Key inventories. - Administrative screenshots. - System logs. - Test records.
REQ-PKI-AP-09 — The product shall provide the capability for authorized users to delete keys.Clause 5.9

Requirement (verbatim from the interim draft)

The product shall provide the capability for authorized users to delete keys.

Applicability

All use cases.

Rationale (the draft’s own)

Proper key management includes the capability for authorized users to delete key when necessary (as defined by the Certificate Policy).

Objective

- Verify that authorized users can delete keys and that unauthorized users cannot perform key deletion.

Preparation

- Key management procedures. - Prepare authorized and unauthorized user accounts for key deletion. - Generate test key pairs.

Activities

- Generate test key pairs. - Delete keys using authorized accounts. - Verify successful deletion and removal of associated key references. - Attempt key deletion using unauthorized accounts. - Verify that unauthorized deletion attempts are denied and logged.

Verdict

- SUCCESS: - Authorized users can successfully delete keys. - Unauthorized users cannot delete keys. - Key deletion events are logged. - FAIL: - Authorized users cannot delete keys. - Unauthorized users can delete keys. - Key deletion events are not properly recorded. - Keys are still accessible or usable after erasure request.

Evidence the standard asks for

- Key management procedures. - Access control configurations. - System and audit logs. - Administrative screenshots. - Test execution records.

5.10 — Impact minimisation

_Proposed ESR code: IM_ This clause addresses the requirements in the CRA [[i.1]](#_ref_i.1) Annex 1 Part 1 (2) (i). The 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.

5.11 — Minimisation of attack surfaces

_Proposed ESR code: MAS_ This clause addresses the requirements in the CRA [[i.1]](#_ref_i.1) Annex 1 Part 1 (2) (j).
REQ-PKI-MAS-01 — Only interfaces identified for each use case in Annex U shall be implemented.Clause 5.11

Requirement (verbatim from the interim draft)

Only interfaces identified for each use case in Annex U shall be implemented.

Applicability

All use cases.

Rationale (the draft’s own)

Only interfaces implementing functions provided by each use case are necessary.

Objective

- Verify that the product implements only the interfaces required to support the use case as defined in Annex U. - Verify that no additional, undocumented, unnecessary, or unauthorized interfaces are present or accessible.

Preparation

- List of use case interfaces as defined in Annex U. - Product architecture documentation, interface specifications, and deployment documentation. - Identify all communication interfaces that may be exposed by the product, including: - Network services and listening ports. - Administrative interfaces. - Web interfaces and APIs. - Command-line interfaces. - Database interfaces. - File transfer interfaces. - Prepare test tools capable of identifying exposed interfaces (e.g., port scanners, API discovery tools, operating system service enumeration utilities). - Product in executable state

Activities

- Review the product documentation and identify all interfaces required by the use case. - Enumerate all implemented interfaces exposed by the product in its operational configuration. - For each discovered interface: - Determine its purpose and associated functionality. - Verify that it is explicitly required by the use case. - Attempt to identify undocumented or hidden interfaces by: - Enumerating network ports and services. - Inspecting running processes and service configurations. - Discovering accessible APIs and endpoints. - Reviewing installation packages and configuration files for additional services. - Verify that: - No additional interfaces are active beyond those identified for the use case. - Disabled or unsupported interfaces cannot be accessed or enabled without authorization. - Administrative, debugging, maintenance, or test interfaces are either absent or explicitly identified and justified by the use case. - Document the mapping between each implemented interface and its corresponding Annex U use case.

Verdict

- SUCCESS: - Every implemented interface can be mapped to one or more interface identified for the use cases in Annex U. - No undocumented, unnecessary, or unauthorized interfaces are present. - No hidden, debugging, maintenance, or test interfaces are accessible unless explicitly required by the use case. - The implemented interfaces are limited to those necessary to provide the use case functionality. - FAIL: - One or more implemented interfaces cannot be mapped to an interface required for the use cases. - Additional, undocumented, or unnecessary interfaces are present or accessible. - Hidden, debugging, maintenance, or test interfaces are exposed without explicit authorization or justification.

Evidence the standard asks for

- Interface inventory showing all implemented interfaces. - Mapping matrix between implemented interfaces and Annex U use case. - Results of network port scans and service enumeration. - API discovery results and endpoint listings, where applicable. - Screenshots or reports showing active services and interfaces. - Product documentation identifying required interfaces. - Test records demonstrating that no additional interfaces are present or accessible.

5.12 — Exploitation mitigation mechanisms

This clause addresses the requirements in the CRA [[i.1]](#_ref_i.1) Annex 1 Part 1 (2) (k). 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.
REQ-PKI-EMM-01a — The format of the certificates issued by the certificate generation service shall comply with t…Clause 5.12

Requirement (verbatim from the interim draft)

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. NOTE: [[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

All use cases, not applicable if REQ-PKI-EMM-01b is used.

Rationale (the draft’s own)

Using normative formats ensures the interoperability of PKIs and enforces that certificate content contains only normalised and necessary information.

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. - Required user profiles defined to generate the certificate. - 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. - Provide a set of necessary and correct elements defined by the Certificate Policy. - Generate, i.e. activate the certificate generation fonction with the correct inputs - Verify that a certificate is generated including the inputed data - Verify that the signature is correct and covers all the necessary fields - Verify that certficates are not generated if inputed data are missing or incorrect related to the Certificate Policy configuratio - Provide a set of necessary and correct elements defined by the Certificate Policy. - Generate, i.e. activate the certificate generation fonction with the correct inputs - Verify that a certificate is generated including the inputed data - 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. - 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 the standard asks for

- Certificate generation requests parameters - Generated certficates or error messages generated by the product - 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.
REQ-PKI-EMM-01b — The format of the certificates issued by the certificate generation service shall comply with t…Clause 5.12

Requirement (verbatim from the interim draft)

The format of the certificates issued by the certificate generation service shall comply with the IEEE 1609.2 standard,

Applicability

UC5 for C-ITS

Rationale (the draft’s own)

Using normative formats ensures the interoperability of PKIs and enforces that certificate content contains only normalised and necessary information.

This interim draft contains no assessment block for this requirement. Recorded in the draft gaps.

REQ-PKI-EMM-02 — The product shall implement a certificate profile compliant to the base standard of REQ-PKI-EMM…Clause 5.12

Requirement (verbatim from the interim draft)

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

All use cases.

Rationale (the draft’s own)

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.

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. - Ability to request a certificate issuance for the different identified circumstances. - Document the certificate profile implemented by the product.

Activities

For each way the product may issue a certificate: - issue a certificate; - verify the certificate to match the constraints of the certificate profile; - 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. - 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 standard asks for

- The documentation of certificate issuance circumstances; - the documentation of the certificate profile; - the way issuances were requested, and the responses and issued certificates from the product.
REQ-PKI-EMM-03 — The product shall enable authorized users to specify the set of acceptable values for the follo…Clause 5.12

Requirement (verbatim from the interim draft)

The product shall enable authorized users to specify the set of acceptable values for the following fields and extensions: - the authority key identifier (if applicable); - the algorithm identifier for the subject’s public/private key pair; - the identifier of the certificate issuer or of the issuing certificate; - the duration for which the certificate is valid.

Applicability

All use cases.

Rationale (the draft’s own)

Only valid certificates, as defined by authorized users in conformity with the PKI certificate policy, shall be generated by the product, inlcuding those fields.

Objective

Verify the product enables the authorized user to specify the set of acceptable values for the following fields and extensions: - the authority key identifier; - the algorithm identifier for the subject’s public/private key pair; - the identifier of the certificate issuer; - the length of time for which the certificate is valid.

Preparation

- Authorized user access, to enable configuration. - 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. - For each way the product may issue a certificate: - For each of the identified fields and extensions: - attempt to issue a certificate, where all fields and extensions have acceptable values except the one being verified; - 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. - 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 standard asks for

- The documentation of public-key certificate issuance circumstances; - The applied configuration of the identified fields and extensions; - the way issuances were requested, and the responses and issued certificates from the product.
REQ-PKI-EMM-04 — The product shall enable authorized users to specify the set of acceptable values for the follo…Clause 5.12

Requirement (verbatim from the interim draft)

The product shall enable authorized users to specify the set of acceptable values for the following fields and extensions: - keyUsage; - basicConstraints; - certificatePolicies.

Applicability

All use cases, applicable only if REQ-PKI-EMM-01a is used.

Rationale (the draft’s own)

Only valid certifcates as defined by the product service provider policies shall be generated by the product inlcuding those fields.

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. - Authorized user access to certificate generation service and related configuration.

Activities

For each way the product may issue a public-key certificate: - verify that no certificate may be issued until acceptables values for the identified fields and extensions are set, i.e.: - keyUsage; - basicConstraints; - 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. - 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 standard asks for

- The documentation of public-key certificate issuance circumstances; - the way issuances were requested, and the responses from the product.
REQ-PKI-EMM-05 — The product shall mark the following extensions as critical:Clause 5.12

Requirement (verbatim from the interim draft)

The product shall mark the following extensions as critical: - keyUsage; - basicConstraints; - certificatePolicies.

Applicability

All use cases, applicable only if REQ-PKI-EMM-01a is used.

Rationale (the draft’s own)

Only valid certifcates as defined by the product service provider policies shall be generated by the product inlcuding those fields.

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: - issue a certificate; - verify the keyUsage, basicConstraints and certificatePolicies extensions to be marked critical; - 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. - 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 standard asks for

- The documentation of public-key certificate issuance circumstances; - The way issuances were requested, and the responses and issued certificates from the product.
REQ-PKI-EMM-06 — The product shall disallow the keyUsage extension to simultaneously include values from:Clause 5.12

Requirement (verbatim from the interim draft)

The product shall disallow the keyUsage extension to simultaneously include values from: - digitalSignature, contentCommitment, keyCertSign, cRLSign; and - keyEncipherment, dataEncipherment, keyAgreement.

Applicability

U2, UC3, UC4, UC5, applicable only if REQ-PKI-EMM-01a is used.

Rationale (the draft’s own)

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.

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: - issue a certificate; - verify the keyUsage extension does not contain values from simultaneously: - digitalSignature, contentCommitment, keyCertSign, cRLSign; and - keyEncipherment, dataEncipherment, keyAgreement. - 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. - 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 standard asks for

- The documentation of public-key certificate issuance circumstances; - The way issuances were requested, and the responses and issued certificates from the product.
REQ-PKI-EMM-07 — The product shall verify that the prospective certificate subject possesses the private key cor…Clause 5.12

Requirement (verbatim from the interim draft)

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

U2, UC3, UC4, UC5.

Rationale (the draft’s own)

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.

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. - Ability to request a certificate issuance.

Activities

For each way the product may issue a public-key certificate: - Attempt to issue a certificate with digital signature capabilities for a given public-key; - if the product does not generate the key pair itself, or it has left the issuance service: - provide an invalid signature when required; - verify the issuance to fail; - provide an valid signature when required; - verify the issuance to succed. - Attempt to issue a certificate with encryption or key agreement capabilities for a given public-key; - if the product does not generate the key pair itself, or it has left the issuance service: - provide an invalid decryption when required; - verify the issuance to fail. - provide an valid decryption when required; - verify the issuance to succed. - 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. - 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 standard asks for

- The documentation of public-key certificate issuance circumstances; - The way issuances were requested, and the responses from the product; - The key pairs issued by the product if any, and how and when they were obtained; - The random values generated by the product.
REQ-PKI-EMM-08 — The certificate status service shall provide certificate revocation statuses as either or both…Clause 5.12

Requirement (verbatim from the interim draft)

The certificate status service shall provide certificate revocation statuses as either or both of: - CRLs as defined by and subject to the requirements of ITU-T X.509 [[2]](#_ref_2); or - OCSP responses to OCSP requests as defined by and subject to the requirements of RFC 6960 [[i.3]](#_ref_i.3).

Applicability

UC1, UC2 and UC3.

Rationale (the draft’s own)

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).

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; - if successful, request a certificate for each way the product may issue a public-key certificate, and verify the issuances to fail. - For each way the product may successfully issue a public-key certificate: - request a certificate; - 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. - 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 standard asks for

- The configuration attempts, or other evidence such configuration is not supported; - the way issuances were requested, and the responses from the product.
REQ-PKI-EMM-09 — The product shall implement a CRL profile and shall ensure that issued CRls are consistent with…Clause 5.12

Requirement (verbatim from the interim draft)

The product shall implement a CRL profile and shall ensure that issued CRls are consistent with that profile.

Applicability

Where the product has a certificate status service, issuing CRLs.

Rationale (the draft’s own)

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.

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. - Documentation of the CRL profile implemented by the product.

Activities

- Request a CRL; - 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. FAIL: 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 standard asks for

The way the CRL was requested, and the response and CRL from the product.
REQ-PKI-EMM-10 — The product shall enable authorized users to specify the set of acceptable values for the follo…Clause 5.12

Requirement (verbatim from the interim draft)

The product shall enable authorized users to specify the set of acceptable values for the following CRL fields and extensions: - issuer; - issuerAltName; - nextUpdate. NOTE: The issuerAltName can be absent from the profile if issued certificates do not use it.

Applicability

Where the product has a certificate status service, issuing CRLs.

Rationale (the draft’s own)

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.

Objective

Verify that the product enables authorized users to specify the set of acceptable values for the fields and extensions: `issuer`, `issuerAltName`, `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`. - 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. - 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 standard asks for

The way CRLs were requested, and the responses from the product.
REQ-PKI-EMM-11 — The product shall implement an OCSP response profile and shall ensure that issued OCSP response…Clause 5.12

Requirement (verbatim from the interim draft)

The product shall implement an OCSP response profile and shall ensure that issued OCSP responses are consistent with that profile.

Applicability

Where the product has a certificate status service, issuing OCSP responses.

Rationale (the draft’s own)

The product shall provide accurate certificates statusas defined by the service provider chosen policies.

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; - 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. - FAIL: Any OCSP response is issued that does not conform to the OCSP response profile or violates its defined constraints.

Evidence the standard asks for

The way the OCSP response was requested, and the response and OCSP response from the product.
REQ-PKI-EMM-12 — The product shall enable authorized users to specify the set of acceptable values for the respo…Clause 5.12

Requirement (verbatim from the interim draft)

The product shall enable authorized users to specify the set of acceptable values for the responseType field.

Applicability

Where the product has a certificate status service, issuing OCSP responses, not restricted to the basic response type: UC1 and UC2.

Rationale (the draft’s own)

The product shall provide accurate certificates status as defined by the service provider chosen policies.

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. - FAIL: The product allows issuance of OCSP responses without configured acceptable values for `responseType`.

Evidence the standard asks for

The way OCSP responses were requested, and the responses and OCSP responses from the product.
REQ-PKI-EMM-13 — The product shall enable authorized users to specify the set of acceptable values for the respo…Clause 5.12

Requirement (verbatim from the interim draft)

The product shall enable authorized users to specify the set of acceptable values for the responderID field. NOTE: 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

Where the product has a certificate status service, issuing OCSP responses of the basic response type: UC1 and UC2.

Rationale (the draft’s own)

The product shall provide accurate certificates status as defined by the service provider chosen policies.

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. - FAIL: The product allows issuance of OCSP responses without configured acceptable values for `responderID`.

Evidence the standard asks for

The way OCSP responses were requested, and the responses and OCSP responses from the product.
REQ-PKI-EMM-14 — In case of certificate re-key, any modified certified names or attributes shall be validated an…Clause 5.12

Requirement (verbatim from the interim draft)

In case of certificate re-key, any modified certified names or attributes shall be validated and updated registration information shall be recorded.

Applicability

All use cases where the product has a certificate generation service, issuing public-key certificates and supporting certificate re-key.

Rationale (the draft’s own)

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.

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. - Ability to request certificate re-key operations. - Administrator or authorized user access to registration information and configuration.

Activities

- Perform certificate re-key requests with modified certified names and/or attributes. - Verify that all modified values are validated before issuance. - 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. - FAIL: Any re-keyed certificate is issued without validating modified certified names or attributes, or updated registration information is not recorded.

Evidence the standard asks for

- Re-key request inputs and configuration. - Issued re-keyed certificates. - Validation logs or system responses. - Registration database or records showing updated information.
REQ-PKI-EMM-15 — In case of a request for certificate modification, any modified certified names or attributes s…Clause 5.12

Requirement (verbatim from the interim draft)

In case of a request for certificate modification, any modified certified names or attributes shall be validated and updated registration information shall be recorded. NOTE: see ETSI 319 411-1 [[i.10]](#_ref_i.10) clause 6.3.8 for the definition of certificate modification.

Applicability

All use cases where the product has a certificate generation service, issuing public-key certificates and supporting certificate modification.

Rationale (the draft’s own)

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.

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. - Ability to request certificate modification operations. - Authorized user access to registration information and audit/configuration data.

Activities

- Perform certificate modification requests with changes to certified names and/or attributes. - Verify that all modified values are validated before issuance. - 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. - FAIL: Any modified certificate is issued without validation of updated certified names or attributes, or updated registration information is not recorded.

Evidence the standard asks for

- Certificate modification request inputs. - Issued modified certificates. - Validation results and system logs. - Registration records reflecting updated certificate information.

5.13 — Logging and monitoring

This clause addresses the requirements in the CRA [[i.1]](#_ref_i.1) Annex 1 Part 1 (2) (l). These 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.
REQ-PKI-MON-01 — The product shall record events related to all product functions identified for each use case (…Clause 5.13

Requirement (verbatim from the interim draft)

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

All use cases.

Rationale (the draft’s own)

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.

Objective

- Verify that the product records audit events for: - All product functions associated with the use cases defined in Annex U. - All privileged user login attempts, including both successful and failed attempts. - All product update activities.

Preparation

- List of PKI functions associated to the use cases as defined in Annex U. - List of privileged user roles supported by the product (e.g., PKI Administrator, Registration Authority Operator, Auditor, System Administrator). - Product in executable state and sufficient testing environment to activate desired functions. - Ensure the audit log storage is empty or note the current audit log state before testing. - Prepare test accounts for privileged users.

Activities

- Enable and verify audit logging functionality. - Execute each function identified in Annex U for the chosen use case. - For each executed function: - Perform at least one successful operation. - Where applicable, perform an unsuccessful or rejected operation. - Verify that an audit event is generated. - Using privileged user accounts: - Attempt successful logins. - Attempt failed logins using invalid credentials. - Attempt logins for disabled or locked accounts, if supported. - Verify that each login attempt generates an audit event. - Perform one or more product update operations when they exist, such as: - Software update installation. - Configuration package update. - Security patch application. - Version upgrade. - Verify that each update activity generates an audit event.

Verdict

- SUCCESS: - Audit records are generated for all functions. - Audit records are generated for all successful and failed privileged user login attempts. - Audit records are generated for all product update activities. - No required events are missing from the audit logs. - FAIL: - One or more functions do not generate audit records. - Privileged user login attempts are not consistently recorded. - Product update activities are not recorded. - Audit records lack sufficient information for accountability or traceability. - Audit logging can be bypassed, disabled without authorization, or fails to capture required events.

Evidence the standard asks for

- Audit log extracts. - Screenshots or exported reports of the audit logging interface. - Test execution records mapping each test activity to its corresponding audit event. - List of executed test cases and their corresponding timestamps and log entries.
REQ-PKI-MON-02 — The product shall record within each audit record at least the following information:Clause 5.13

Requirement (verbatim from the interim draft)

The product shall record within each audit record at least the following information: - Date and time of the event - Type of event - Subject identity (if applicable) - The outcome (success or failure) of the event NOTE: The audit shall not include in plaintext any secret keys or other critical security parameters.

Applicability

All use cases.

Rationale (the draft’s own)

The audit record timestamping and subject identification ensure that all auditable events are traceable and misuse of the product functions can be traced.

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. - Verify the audit record contains at least: - the date and time of the event; - the type of the event; - the subject identity (if applicable); - the outcome of the event. - Perform the above for each audit event type, and verify that the audit record additionally contains the additional information specified by the developper. - For each information verified to be present, verify it matches the expected value given when and how the event was triggered. - 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. - FAIL: Audit records are missing required fields, contain incorrect values, or expose secret/sensitive key material in plaintext.

Evidence the standard asks for

The way the events were triggered and at what time, and the corresponding audit records.
REQ-PKI-MON-03 — The audit record shall identify the timing source used to generate the timestamp.Clause 5.13

Requirement (verbatim from the interim draft)

The audit record shall identify the timing source used to generate the timestamp.

Applicability

All use cases.

Rationale (the draft’s own)

The audit record timestamping validity ensure that all auditable events are traceable and misuse of the product functions can be traced.

Objective

- Verify that the product employs reliable time stamps.

Preparation

- Ability to trigger auditable events, and ability to audit events. - 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. - 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. - 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. - 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. - FAIL: Audit timestamps are unreliable, non-monotonic, unauthenticated, or otherwise inconsistent with trusted time sources.

Evidence the standard asks for

- The way the events were triggered and at what time, and the corresponding audit records; - arguments relating to the authentication of a trusted source (if applicable); - arguments relating to the monotonicity of local time information (if applicable).
REQ-PKI-MON-04 — For audit events resulting from actions of identified users, the product shall be able to assoc…Clause 5.13

Requirement (verbatim from the interim draft)

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

All use cases.

Rationale (the draft’s own)

The audit record integrity and timestamping validity ensure that all auditable events are traceable and misuse of the product functions can be traced.

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. - 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. - Verify the audit record contains the identity of the user that caused the event. - 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. - FAIL: Unauthorized users can delete or alter audit records, or audit data is not preserved after deletion attempts.

Evidence the standard asks for

- The identity of the given user used for the test; - the way the event was triggered and at what time, and the corresponding audit record.
REQ-PKI-MON-05 — The product shall prevent auditable events, except those taken by the auditor, if the audit log…Clause 5.13

Requirement (verbatim from the interim draft)

The product shall prevent auditable events, except those taken by the auditor, if the audit log is full.

Applicability

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 (the draft’s own)

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.

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. - Verify that a given additional auditable event cannot be performed. - Identify as an auditor to the product. - 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. - FAIL: The system continues to allow non-auditor actions when the log is full, or improperly blocks auditor actions.

Evidence the standard asks for

- The configured maximum size of the audit log; - the size of the audit when full, or nearly so; - the way the additional event was attempted to be triggered, and the corresponding response from the product.

5.14 — Data removal and transparency

This clause addresses the requirements in the CRA [[i.1]](#_ref_i.1) Annex 1 Part 1 (2) (m).
REQ-PKI-DRT-01 — Public keys stored within the product, but not within a secure cryptographic device, shall be p…Clause 5.14

Requirement (verbatim from the interim draft)

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: - release the accessed public key to the caller; or - use the accessed public key.

Applicability

All use cases

Rationale (the draft’s own)

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.

Objective

- Verify that all public keys stored by the product outside of a secure cryptographic device are protected against undetected modification. - Verify that the product detects unauthorized modification of stored public keys before they are released or used. - 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). - Identify the mechanisms used to protect public key integrity (e.g., digital signatures, hashes, message authentication codes, integrity checks). - Valid test public keys and associated integrity protection information. - 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. - Access and use the stored public keys and verify that: - Integrity verification is performed prior to release or use. - Valid public keys are successfully released and used. - Modify a stored public key without updating its integrity protection information. - Attempt to access or use the modified public key and verify that: - The integrity verification mechanism detects the modification. - The modified public key is not returned to the requesting entity. - The modified public key is not used in any cryptographic operation. - Attempt to perform cryptographic operations that depend on the modified public key and verify that such operations fail safely. - Review system logs and verify that integrity verification failures are appropriately recorded, where logging is implemented.

Verdict

- SUCCESS: - All public keys stored outside secure cryptographic devices are protected by an integrity verification mechanism. - Unauthorized modifications of stored public keys are reliably detected. - Modified public keys are neither released nor used by the product. - Cryptographic operations depending on modified public keys fail safely and predictably. - FAIL: - A stored public key can be modified without detection. - A modified public key is released to a none-authorized user. - A modified public key is used by the product. - Integrity verification mechanisms can be bypassed or are not consistently applied. - Cryptographic operations continue using modified public keys.

Evidence the standard asks for

- Public key storage locations. - Documentation of integrity protection mechanisms. - Test records showing successful verification of valid public keys. - Test records demonstrating detection of unauthorized modifications. - Screenshots or log extracts showing integrity verification failures. - Evidence that modified public keys were neither released nor used.
REQ-PKI-DRT-02 — The product shall zeroize secrets in plaintext form.Clause 5.14

Requirement (verbatim from the interim draft)

The product shall zeroize secrets in plaintext form.

Applicability

Where the product temporarily manipulates secrets in plaintext form.

Rationale (the draft’s own)

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.

Objective

- Verify that all secrets temporarily manipulated by the product in plaintext form are zeroized after use. - Verify that plaintext secrets are not retained in memory, temporary files, caches, or other storage locations beyond their required period of use. - 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: - Private keys. - Authentication credentials. - Passphrases and passwords. - Key-encryption keys. - Session keys and other cryptographic secrets. - Identify all components and processes that temporarily process these secrets. - Documentation describing secret handling and zeroization mechanisms. - Tools capable of examining process memory, temporary files, and storage artifacts.

Activities

- Execute all functions that temporarily manipulate secrets in plaintext form. - During and after each operation, inspect: - Process memory. - Temporary files. - Cache locations. - Swap or paging areas, where applicable. - Inter-process communication buffers, where applicable. - Verify that plaintext secrets are present only for the duration necessary to perform the operation. - Verify that plaintext secrets are overwritten or cleared immediately after use. - Induce abnormal conditions, including: - Operation failures. - Interrupted processing. - Unexpected exceptions. - Service restarts. - Verify that plaintext secrets are also zeroized following abnormal termination conditions. - Repeat the assessment for all identified components that temporarily manipulate secrets.

Verdict

- SUCCESS: - All identified plaintext secrets are zeroized after use. - Plaintext secrets are not retained in memory or temporary storage beyond their operational need. - Zeroization occurs during both normal and abnormal execution paths. - No recoverable plaintext secret material remains after completion of processing. - FAIL: - One or more plaintext secrets remain accessible after use. - Plaintext secrets persist in memory, temporary files, caches, or buffers beyond their required lifetime. - Zeroization is not performed during abnormal termination conditions. - Recoverable plaintext secret material can be obtained after the completion of processing.

Evidence the standard asks for

- Inventory of secrets manipulated in plaintext form. - Design documentation describing secret handling and zeroization mechanisms. - Memory analysis reports demonstrating the removal of plaintext secrets. - Inspection results for temporary files, caches, and storage artifacts. - Test records for normal and abnormal execution scenarios. - Screenshots, logs, or forensic reports demonstrating successful zeroization.

5.15 — Vulnerability handling

This clause addresses the requirements in the CRA [[i.1]](#_ref_i.1) Annex 1 Part 2. The requirements specified in CEN/CLC JT013090:2026 (CEN/CLC prEN 40000-1-3) [[i.17]](#_ref_i.17) shall be fulfilled for the product.

Annex K — cryptography

The draft’s Annex K cryptography provisions, as this pack makes them answerable. Everything inside the entries is the draft’s text.

The assessment in clause K.1.2 verifies the cryptographic mechanisms used in the product’s default configuration against clause K.1.1. For 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.

The assessment cases of clause K.1.2

The draft assesses default-configuration cryptography through 3 cases. All of them, verbatim:

acm-listedK.1.2 assessment case

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. - 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: - a) each cryptographic mechanism claimed under clause K.1.1 item 1) is identified by reference to a relevant ACM entry; - b) the ACM entry corresponds to the cryptographic mechanism used in the product’s default configuration, including relevant parameters where applicable; - 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.

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). - The verdict FAIL shall be assigned otherwise.

Evidence the standard asks for

The assessment evidence shall include, as applicable: - a) description of the product’s default configuration; - b) list of cryptographic mechanisms claimed under clause K.1.1 item 1); - c) references to the relevant ACM entries; - d) relevant parameters, profiles, cipher suites or configuration constraints, where applicable; - e) relevant lifecycle information from the ACM catalogue, where applicable.
acm-extendedK.1.2 assessment case

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. - 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: - a) the relevant entry in clause K.3.2; or - 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: - 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; - 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; - 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; - 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; - 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; - f) where technically feasible, the cryptographic mechanism, parameters and configuration identified in the documentation correspond to the assessed product configuration.

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). - The verdict FAIL shall be assigned otherwise.

Evidence the standard asks for

The assessment evidence shall include, as applicable: - a) description of the product’s default configuration; - b) list of cryptographic mechanisms claimed under clause K.1.1 item 2); - c) reference to the relevant entry in clause K.3.2, where the mechanism is listed in clause K.3.2; - 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; - e) identification of the related product function using the cryptographic mechanism and the use case where applicable; - f) relevant characteristics, parameters, profiles, cipher suites or configuration constraints, where applicable; - 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.
interoperabilityK.1.2 assessment case

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. - 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: - 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; - b) the cryptographic mechanism used by the product corresponds to the cryptographic mechanism listed in clause K.4.2; - 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; - 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; - 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; - 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; - g) where technically feasible, the cryptographic mechanism, parameters and configuration identified in the documentation correspond to the assessed product configuration.

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). - The verdict FAIL shall be assigned otherwise. > 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. > 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.

Evidence the standard asks for

The assessment evidence shall include, as applicable: - a) description of the product’s default configuration; - b) list of cryptographic mechanisms claimed under clause K.1.1 item 3); - c) reference to the relevant entry in clause K.4.2; - d) identification of the related product function using the cryptographic mechanism and the use case where applicable; - e) identification of the external specification or external requirement requiring use of the cryptographic mechanism; - f) relevant characteristics, parameters, profiles, cipher suites or configuration constraints, where applicable; - g) evidence that the cryptographic mechanism is used in accordance with the conditions or limitations specified in clause K.4.2.

Correspondence to the CRA

The draft’s own correspondence table: which of its clauses address which essential requirement of CRA Annex I. This is the draft’s claim, reproduced as it stands — not Vandorisk’s judgment of coverage, and (status block above) not a presumption of conformity.

CRA provisionDraft clause(s)
Annex I, Part 1, (1)5
Annex I, Part 1, (2)(a)5.2
Annex I, Part 1, (2)(b)5.3
Annex I, Part 1, (2)(c)5.4
Annex I, Part 1, (2)(d)5.5
Annex I, Part 1, (2)(e)5.6
Annex I, Part 1, (2)(f)5.7
Annex I, Part 1, (2)(g)5.8
Annex I, Part 1, (2)(h)5.9
Annex I, Part 1, (2)(i)5.10
Annex I, Part 1, (2)(j)5.11
Annex I, Part 1, (2)(k)5.12
Annex I, Part 1, (2)(l)5.13
Annex I, Part 1, (2)(m)5.14
Annex I, Part 25.15

Where the table covers CRA Annex I Part 1 only, the Part 2 (vulnerability handling) obligations remain assessed through the horizontal CRA pack(II.1–II.8).

Draft gaps

Defects and holes we found in the interim draft while building this pack — recorded rather than papered over; they will be rechecked against each new draft. A standard under consultation is allowed to have holes. A pack that hides them is not.

  • 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).

How this pack is built, and corrections

The pack is produced by a deterministic parser over the vendored draft text pinned in the source card— no model writes or rewrites any requirement. When ETSI updates the draft, the pack is rebuilt from the new text, the draft gaps are rechecked, and the result ships as a new pack version — never a silent edit.

The interim draft and, once published, the standard itself are the authoritative texts — this pack reproduces and cites them, it does not replace them, and nothing on this page is legal advice. If you find an error — a mis-parsed requirement, an applicability entry that does not match the draft, a gap we missed — write to hello@vandorisk.com. The horizontal pack this one attaches alongside is published at /pack, with every tracked vertical standard listed there.