@@ -1128,14 +1128,11 @@ The period of the product lifecycle, which is after the release, is addressed in
This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (b).
<mark>[REQ-TECH-0] assesment: Needs the documentation trick.</mark>
***SBD_TECH-3** The product shall implement **CON_CRYPTO-1** in all interfaces, expect the ones that are available and reachable only in localhost by the local processes.
***SBD_TECH-4** When privileged information is transferred or accessed, a [5.7.2 Secure channel](#572-secure-channel) shall be used in transport.
***SBD_TECH-1** The product shall implement **CON_CRYPTO-1** in all interfaces, expect the ones that are available and reachable only in localhost by the local processes.
> NOTE: Cryptographic mechanisms not covered by **CON_CRYPTO-1** are disabled by default.
***SBD_CRYPTO-1** For backward compatibility, if supported:
***SBD_TECH-2** For backward compatibility, if supported:
* 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;
@@ -1922,7 +1919,7 @@ Verify that:
## 6.4 Secure by default configuration
### 6.4.4 SBD_TECH-4
### 6.4.1 SBD_TECH-1
**Objective:** Protect the integrity of the data.<br/>
**Preparation:** None<br/>
@@ -1945,6 +1942,30 @@ Verify that:
1. Listing of tested interfaces and the protocol replies that show that encryption is used.
2. Listing of interfaces showing authentication is used.
### 6.4.2 SBD_TECH-2
**Objective:** Enable transition to safer cryptograhpies.<br/>
**Preparation:**
1. Have the product initialised and available with the default configuration and required credentials.
2. Study the technical documentation.
**Activities:**
1. Study the technical documentation.
2. Enable a disabled by default, backward compatibile implementation.
**Verdict:**
1. Pass, if the listed requirements are implemented.
2. Fail otherwise.
**Supporting Evidence:**
* Relevant vendor or design documentation describing the applied measures;
* Test reports showing the steps performed and results obtained;
* Screenshots, captures, or console outputs confirming the correct execution or protection behaviour;
* Logs, configuration files, or audit traces demonstrating the implementation of the requirement.
