Products are delivered without known exploitable vulnerabilities and that comprises also implemented cryptography.
However, certain use cases or the product installation into a present user infrastructure may require the use of legacy protocols and cryptography.
As the product is delivered without known exploitable vulnerabilities, those legacy configurations cannot be the factory default setting, and may only be enabled after the user has been sufficiently informed about the security consequences.
***[REQ-CRYPTO-1]** The product’s default configuration shall only use cryptographic mechanisms that meet at least one of the following criteria:
1. ACM-listed: the cryptographic mechanism is listed in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [reference].
2. ACM-extended: the cryptographic mechanism is not listed in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [reference] and meets at least one of the following conditions:
1. the cryptographic mechanism is listed in clause K.3.2 as an ACM-extended cryptographic mechanism for the specific product function(s);
2. where the cryptographic mechanism is not listed in clause K.3.2, the cryptographic mechanism meets all the following criteria:
1. the cryptographic mechanism, or where applicable the ACM-listed cryptographic mechanism on which it is based, is not deprecated per the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [reference];
2. the cryptographic mechanism has been specified, developed or maintained through a transparent process by a recognised European, international or sector-specific standards development organisation, or by an industry specification organisation accountable for the relevant specification, including <mark>[list of organisations]</mark>; or the cryptographic mechanism is listed as suitable in a publicly available cryptographic catalogue maintained by a recognised national or governmental cybersecurity authority, where the catalogue is maintained under a documented revision and retirement process, including <mark>[list of catalogues]</mark>;
3. the cryptographic mechanism is described in a valid, publicly available and uniquely referenceable specification;
4. the cryptographic properties of the cryptographic mechanism are known;
5. no known weakness affects the cryptographic mechanism in a way that affects its cryptographic properties;
6. the cryptographic mechanism is required for a specific set of product functions;
7.<mark>[any additional criteria specified by the vertical standard, where applicable]</mark>.
3. Interoperability-based: the cryptographic mechanism is listed in clause K.4.2 as an interoperability-based cryptographic mechanism for specific product function(s) and external specification(s) or external requirement(s).
***[REQ-CRYPTO-3]** Cryptographic mechanisms not covered by **[REQ-CRYPTO-1]** shall be disabled by default.
***[REQ-CRYPTO-4]** To prevent rollback or downgrade:
* the product shall enforce a monotonic policy/configuration version (or equivalent mechanism);
* the product shall record changes in tamper-evident audit logs;
* the product shall prevent re-enabling deprecated algorithms or disabled security checks via rollback without an explicit logged administrative override.
***[REQ-CRYPTO-5]** For backward compatibility:
* the product shall inform the user about the security implications when not using the default configuration;
* the product shall inform the user the component requiring the weaker mechanism;
* the product shall inform the user the justification for backward compatibility;
* the product shall provide the user a instructions how to transition to a secure cryptography.
> NOTE 1: The reference to the product’s default configuration is intended to define a clear and assessable baseline, corresponding to the configuration in which the product is placed on the market. The product can provide several configurations that fulfil the requirement.
> NOTE 2: For products supplied as hardware platforms or components to be configured by an integrator, references in this annex to the product’s default configuration refer to the configuration specified for the intended operational use of the product after integration, including the relevant integration assumptions and configuration constraints.
> NOTE 3: The applicable ACM catalogue version is identified in the normative references of the present document.
> The lifecycle treatment of mechanisms affected by ACM deprecation dates, expiry dates, migration conditions or usage limitations is addressed in clause K.2.
> NOTE 4: In this clause, an external specification or external requirement means a specification or requirement that is imposed on the product, and which requires the use of a specific cryptographic mechanism for the product to interoperate with an identified system, platform or operational context.
> An external requirement can be a regulatory requirement, operational constraint, technical interoperability constraint, or platform compatibility requirement.
> NOTE 5: Inclusion of a cryptographic mechanism under the interoperability-based criterion does not classify that mechanism as state-of-the-art cryptography.
> EXAMPLE: Examples of product functions include secure communication based on TLS 1.3; authenticated encryption of communicated data based on AES-GCM; storage confidentiality based on AES-XTS; firmware signature verification based on Ed25519; and key derivation based on HKDF.
@@ -1058,16 +1058,16 @@ System operation is always an interplay of multiple components. Modern software
On product architecture and design:
***CYB_GENERAL_1**: The product shall define whether a service is completely fulfilled by the product itself.
***CYB_GENERAL_2**: The product shall describe the external services and systems that are required for the product operation.
***CYB_GENERAL_3**: The product shall define how it is dependent on RDPS.
***CYB_GENERAL_4**: The product shall describe the dependencies to Operating System essential security capabilities.
***CYB_GENERAL_1** The product shall define whether a service is completely fulfilled by the product itself.
***CYB_GENERAL_2** The product shall describe the external services and systems that are required for the product operation.
***CYB_GENERAL_3** The product shall define how it is dependent on RDPS.
***CYB_GENERAL_4** The product shall describe the dependencies to Operating System essential security capabilities.
On operative environment:
***CYB_GENERAL_5**: The product shall describe the core requirements and expectations for the operational environment (OE).
***CYB_GENERAL_6**: The product shall describe the traffic related to the product operation, including but not limited to configuration, metrics and API access, is addressed as Application level traffic as per RFC 1122.
***CYB_GENERAL_7**: Where the product relies on a remote data processing solution (RDPS) for the provision or support of one or more product functions, the product shall satisfy the applicable requirements specified in [Annex R](#annex-r-normative-additional-provisions-for-products-relying-on-remote-data-processing-solutions-rdps).
***CYB_GENERAL_5** The product shall describe the core requirements and expectations for the operational environment (OE).
***CYB_GENERAL_6** The product shall describe the traffic related to the product operation, including but not limited to configuration, metrics and API access, is addressed as Application level traffic as per RFC 1122.
***CYB_GENERAL_7** Where the product relies on a remote data processing solution (RDPS) for the provision or support of one or more product functions, the product shall satisfy the applicable requirements specified in [Annex R](#annex-r-normative-additional-provisions-for-products-relying-on-remote-data-processing-solutions-rdps).
[Annex R](#annex-r-normative-additional-provisions-for-products-relying-on-remote-data-processing-solutions-rdps) specifies supplementary requirements for the product-facing RDPS boundary and does not replace the requirements applicable to the product function as such.
@@ -1088,11 +1088,9 @@ Recognising that there may be vulnerabilities discovered between the time that a
## 5.4 Secure by default configuration
<mark>_Proposed ESR code SBD_</mark>
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (b).
This technical requirement may be accompanied by the following note:
***SBD__CRYPTO-1** Cryptographic mechanisms not covered by **CON_CRYPTO-1** shall be disabled by default.
> NOTE: The CRA essential requirement laid out in Annex 1 Part 1 (2) (b) foresees an applicability exception to the secure configuration by default in case there is an agreement between manufacturer and business user in relation to a tailor-made product with digital elements.
@@ -1265,7 +1263,46 @@ This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 P
***CON_INGEST-3** The product shall protect data in transit.
***CON_INGEST-4** When data relevant to monitoring, control, or security functions is transferred over connections not controlled by the product, the product shall provide measures appropriate to the intended and reasonably foreseeable use to protect the integrity and, where required, the confidentiality of that data.
<mark>Editor's Note:In this clause, reference can be made to the Annex K (normative), specifying State Of The Art Cryptography.</mark>
Products are delivered without known exploitable vulnerabilities and that comprises also implemented cryptography.
However, certain use cases or the product installation into a present user infrastructure may require the use of legacy protocols and cryptography.
As the product is delivered without known exploitable vulnerabilities, those legacy configurations cannot be the factory default setting, and may only be enabled after the user has been sufficiently informed about the security consequences.
***CON_CRYPTO-1** The product’s default configuration shall only use cryptographic mechanisms that meet at least one of the following criteria:
1. ACM-listed: the cryptographic mechanism is listed in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [reference].
2. ACM-extended: the cryptographic mechanism is not listed in the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [reference] and meets at least one of the following conditions:
1. the cryptographic mechanism is listed in clause K.3.2 as an ACM-extended cryptographic mechanism for the specific product function(s);
2. where the cryptographic mechanism is not listed in clause K.3.2, the cryptographic mechanism meets all the following criteria:
1. the cryptographic mechanism, or where applicable the ACM-listed cryptographic mechanism on which it is based, is not deprecated per the ECCG Agreed Cryptographic Mechanisms (ACM) catalogue [reference];
2. the cryptographic mechanism has been specified, developed or maintained through a transparent process by a recognised European, international or sector-specific standards development organisation, or by an industry specification organisation accountable for the relevant specification, including <mark>[list of organisations]</mark>; or the cryptographic mechanism is listed as suitable in a publicly available cryptographic catalogue maintained by a recognised national or governmental cybersecurity authority, where the catalogue is maintained under a documented revision and retirement process, including <mark>[list of catalogues]</mark>;
3. the cryptographic mechanism is described in a valid, publicly available and uniquely referenceable specification;
4. the cryptographic properties of the cryptographic mechanism are known;
5. no known weakness affects the cryptographic mechanism in a way that affects its cryptographic properties;
6. the cryptographic mechanism is required for a specific set of product functions;
7.<mark>[any additional criteria specified by the vertical standard, where applicable]</mark>.
3. Interoperability-based: the cryptographic mechanism is listed in clause K.4.2 as an interoperability-based cryptographic mechanism for specific product function(s) and external specification(s) or external requirement(s).
***CON_CRYPTO-3** To prevent rollback or downgrade:
* the product shall enforce a monotonic policy/configuration version (or equivalent mechanism);
* the product shall record changes in tamper-evident audit logs;
* the product shall prevent re-enabling deprecated algorithms or disabled security checks via rollback without an explicit logged administrative override.
***CON_CRYPTO-4** For backward compatibility:
* the product shall inform the user about the security implications when not using the default configuration;
* the product shall inform the user the component requiring the weaker mechanism;
* the product shall inform the user the justification for backward compatibility;
* the product shall provide the user a instructions how to transition to a secure cryptography.
> NOTE 1: The reference to the product’s default configuration is intended to define a clear and assessable baseline, corresponding to the configuration in which the product is placed on the market. The product can provide several configurations that fulfil the requirement.
> NOTE 2: For products supplied as hardware platforms or components to be configured by an integrator, references in this annex to the product’s default configuration refer to the configuration specified for the intended operational use of the product after integration, including the relevant integration assumptions and configuration constraints.
> NOTE 3: The applicable ACM catalogue version is identified in the normative references of the present document.
> The lifecycle treatment of mechanisms affected by ACM deprecation dates, expiry dates, migration conditions or usage limitations is addressed in clause K.2.
> NOTE 4: In this clause, an external specification or external requirement means a specification or requirement that is imposed on the product, and which requires the use of a specific cryptographic mechanism for the product to interoperate with an identified system, platform or operational context.
> An external requirement can be a regulatory requirement, operational constraint, technical interoperability constraint, or platform compatibility requirement.
> NOTE 5: Inclusion of a cryptographic mechanism under the interoperability-based criterion does not classify that mechanism as state-of-the-art cryptography.
> EXAMPLE: Examples of product functions include secure communication based on TLS 1.3; authenticated encryption of communicated data based on AES-GCM; storage confidentiality based on AES-XTS; firmware signature verification based on Ed25519; and key derivation based on HKDF.
## 5.8 Integrity protection
@@ -1273,12 +1310,12 @@ This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 P
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (f).
***[INT_CONF-1]** The product shall interface only through a [5.2.1 Secure channel].
***[INT_CONF-2]** Where the product distributes or makes available configuration to managed devices
***INT_CONF-1** The product shall interface only through a [5.2.1 Secure channel].
***INT_CONF-2** Where the product distributes or makes available configuration to managed devices
* The product shall ensure that the configuration is protected against unauthorized modification and disclosure;
* The product shall ensure that only the intended managed device can obtain and apply the relevant configuration;
* The prodcut shall ensure that the device can verify the integrity of the configuration.
***[INT_CONF-3]** The configuration interfacing design shall enable the managed device to verify the authenticity of the product.
***INT_CONF-3** The configuration interfacing design shall enable the managed device to verify the authenticity of the product.
## 5.9 Data minimisation
@@ -1369,30 +1406,30 @@ The logging requirements in this subclause define baseline event recording and a
For low risk:
***MON_LOG-0a:** The log file of events shall be protected from unauthorised access.
***MON_LOG-0b:** The log data of events shall be protected from modification including their deletion.
***MON_LOG-0c:** The log data of events shall be confidentiality protected.
***MON_LOG-0d:** The log shall include event time, actor identity, action type, and affected non-sensitive scope and object identifiers.
***MON_LOG-0e:** The product shall monitor and log all received relevant events from its managed elements, including, not conclusive, incidents, alarms, time and clock shift alarms.
***MON_LOG-0f:** The product shall define what is logged, and how long that record is kept.
***MON_LOG-0a** The log file of events shall be protected from unauthorised access.
***MON_LOG-0b** The log data of events shall be protected from modification including their deletion.
***MON_LOG-0c** The log data of events shall be confidentiality protected.
***MON_LOG-0d** The log shall include event time, actor identity, action type, and affected non-sensitive scope and object identifiers.
***MON_LOG-0e** The product shall monitor and log all received relevant events from its managed elements, including, not conclusive, incidents, alarms, time and clock shift alarms.
***MON_LOG-0f** The product shall define what is logged, and how long that record is kept.
The following requirements apply where the corresponding function exists:
***MON_LOG-1a:** The product shall generate auditable events for successful and failed authentication events.
***MON_LOG-1b:** The product shall generate auditable events for session establishment attempts with source details.
***MON_LOG-1c:** The product shall generate auditable events for session termination events with reason.
***MON_LOG-1d:** The product shall generate auditable events for session validation checks like number of concurrent sessions.
***MON_LOG-1e:** The product shall generate auditable events for privilege and role changes.
***MON_LOG-1f:** The product shall generate auditable events for configuration changes.
***MON_LOG-1g:** The product shall generate auditable events for device enrollment and unenrollment.
***MON_LOG-1h:** The product shall generate auditable events for trust-anchor changes.
***MON_LOG-1i:** The product shall generate auditable events for policy changes.
***MON_LOG-1j:** The product shall generate auditable events for credential changes.
***MON_LOG-2a:** The product shall log boot or initialisation events including timestamped boot stage progression.
***MON_LOG-2b:** The product shall log boot or initialisation events including software component verification and initialisation actions.
***MON_LOG-2c:** The product shall log boot or initialisation events including recovery mode activations if in use.
***MON_LOG-3c:** The product shall log events described by [5.3.4 Secure updates].
***MON_LOG-3d:** The product shall log installation successes and failures in the managed devices and the product itself if that information can be extracted from the targets.
***MON_LOG-1a** The product shall generate auditable events for successful and failed authentication events.
***MON_LOG-1b** The product shall generate auditable events for session establishment attempts with source details.
***MON_LOG-1c** The product shall generate auditable events for session termination events with reason.
***MON_LOG-1d** The product shall generate auditable events for session validation checks like number of concurrent sessions.
***MON_LOG-1e** The product shall generate auditable events for privilege and role changes.
***MON_LOG-1f** The product shall generate auditable events for configuration changes.
***MON_LOG-1g** The product shall generate auditable events for device enrollment and unenrollment.
***MON_LOG-1h** The product shall generate auditable events for trust-anchor changes.
***MON_LOG-1i** The product shall generate auditable events for policy changes.
***MON_LOG-1j** The product shall generate auditable events for credential changes.
***MON_LOG-2a** The product shall log boot or initialisation events including timestamped boot stage progression.
***MON_LOG-2b** The product shall log boot or initialisation events including software component verification and initialisation actions.
***MON_LOG-2c** The product shall log boot or initialisation events including recovery mode activations if in use.
***MON_LOG-3c** The product shall log events described by [5.3.4 Secure updates].
***MON_LOG-3d** The product shall log installation successes and failures in the managed devices and the product itself if that information can be extracted from the targets.
For medium risk:
@@ -1404,10 +1441,10 @@ For medium risk:
For high risk:
***MON_LOG-6:** The product shall support forwarding of relevant administrative events to an external logging or SIEM system.
***MON_LOG-7:** SIEM transfer format, field attributes and event descriptions shall made available in a machine readable format.
***MON_LOG-8:** Exported artifacts shall preserve essential fields at least, but not limited to: time, actor, action type, affected scope, result.
***MON_LOG-9:** The product shall record provenance sufficient to attribute the change to an actor and context information related to at least, but not limited to: user, automated workflow, policy or rule identifier, and triggering event reference.
***MON_LOG-6** The product shall support forwarding of relevant administrative events to an external logging or SIEM system.
***MON_LOG-7** SIEM transfer format, field attributes and event descriptions shall made available in a machine readable format.
***MON_LOG-8** Exported artifacts shall preserve essential fields at least, but not limited to: time, actor, action type, affected scope, result.
***MON_LOG-9** The product shall record provenance sufficient to attribute the change to an actor and context information related to at least, but not limited to: user, automated workflow, policy or rule identifier, and triggering event reference.
