**IMPORTANT:** Not all requirements are necessary for all products. The mapping tables at the end of each requirement shows which risk factors and use cases determine which requirements are necessary for the product. See Annex C for more information.
The most important quality of a technical requirement is that it should ideally be objectively testable on an instance of the product. If it can't be tested on the product itself, it is a documentation requirement, in which the manufacturer proves that it meets the requirement by collecting documentation of the steps they took to implement the requirement (such as configuration files or written policies used by employees).
The alternative option is “check-box” requirements, which only require that the vendor says that they did a thing (“Did you have every commit code-reviewed by a second person? [x] Yes [ ] No”). These are a last resort; testable on the product is better than a documentation requirement is better than a check-box requirement. In this case, the check box requirement could be turned into a documentation requirement by requiring the vendor to save the list of commits and who reviewed them.
The alternative is “check-box” requirements, which only require that the vendor says that they did a thing (“Did you have every commit code-reviewed by a second person? [x] Yes [ ] No”). These are not acceptable and should be converted into testable requirements if possible and documentation requirements otherwise.
The CRA requires the manufacturer to keep all the documentation necessary to show that the tests were conducted. In addition, the CRA explicitly grants the MSA the following rights in Article 13 Rec. 22:
> "Manufacturers shall, upon a reasoned request from a market surveillance authority, provide that authority, in a language which can be easily understood by that authority, with all the information and documentation, in paper or electronic form, necessary to demonstrate the conformity of the product with digital elements and of the processes put in place by the manufacturer with the essential cybersecurity requirements set out in Annex I. Manufacturers shall cooperate with that authority, at its request, on any measures taken to eliminate the cybersecurity risks posed by the product with digital elements which they have placed on the market."
The goal is that when the MSA does a “sweep” or otherwise decides to verify a product’s conformance with the CRA, it has enough information that it can do its own independent testing without unnecessary barriers that could be solved by vendor documentation (e.g., does not have to reverse-engineer how to attach a serial console and read logs). Note that the MSAs generally prefer evaluating via transparency - reviewing the test output and documentation to evaluate whether a mitigation is implemented - over actually testing the product themselves.
The goal is that when the MSA does a “sweep” or otherwise decides to verify a product’s conformance with the CRA, it has enough information that it can do its own independent testing without unnecessary barriers that could be solved by vendor documentation (e.g., does not have to reverse-engineer how to attach a serial console and read logs). Note that it is easer for an MSA to evaluate conformance via transparency - reviewing the test output and documentation to evaluate whether a mitigation is implemented - over actually testing the product themselves.
A few assumptions that we are making:
* Manufacturers are already required to provide the ability to enable testing and collect output on the product as placed on the market, and will supply instructions for enabling and collecting test data.
* The MSA can and will request source code if desired.
Mitigations are how a technical requirement can be satisfied. Mitigations should be tailored to the use case and take into account the user’s sophistication and the operational environment.
Some risks may be transferred partially or fully to other components of the system or the user of the product. When that is the case, migitations that transfer the risk will be included as an option to fulfill a technical requirement, depending on the use case and risk factors.
Format:
### 5.2.X **TR-XXXX**:
@@ -779,31 +789,7 @@ _Description of mitigation implementing the requirement in "shall" format._
### 5.2.1 General
This clause is a list of technical requirements necessary to satisfy the CRA essential requirements. Each technical requirement can be satisfied by one or more potential mitigations. Each mitigation may or may not be appropriate for an individual use case. The following clause will define which mitigations will be required, depending on a risk factor, the overall risk tolerance, and/or a use case in the following clause.
Some risks may be transferred partially or fully to other components of the system or the user of the product. When that is the case, migitations that transfer the risk will be included as an option to fulfill a technical requirement, depending on the use case and risk factors.
A few assumptions that we are making:
Manufacturers are already required to provide the ability to enable testing and collect output on the product as placed on the market, and will supply instructions for enabling and collecting test data.
The MSA can and will request source code if desired.
### 5.1.2 Notes on Mitigations
Specific technical mitigations should be articulated in relation to specific Risk Factors (Annex C.5).
This 1-to-1 mapping enables clear identification of appropriate mitigations for each Use Case based on the mapping of risk factors to use cases.
This also enables new use cases to be developed and, based on the existing list of risk factors, the relevant mitigations to be identified.
This clause is a list of technical requirements necessary to satisfy the CRA essential requirements. Each technical requirement can be satisfied by one or more potential mitigations. Each mitigation may or may not be appropriate for an individual use case. Each technical requirement will define which mitigations will be required, depending on a risk factor, the overall risk tolerance, and/or a use case in the following clause.
Some risks may be transferred partially or fully to other components of the system or the user of the product. When that is the case, migitations that transfer the risk will be included as an option to fulfill a technical requirement, depending on the use case and risk factors.
This section is a list of technical requirements necessary to satisfy the CRA essential requirements. Each technical requirement can be satisfied by one or more potential mitigations. Each mitigation may or may not be appropriate for an individual use case. The following section will define which mitigations will be required, depending on risk factors and/or a use case. See Annex C for more information.
### 5.2.X **TR-MISO**: Prevent local unauthorized access of memory-addressable security-relevant data
@@ -980,7 +966,7 @@ Most memory safety mitigations have the same Verdict and Evidence:
* Preparation: None
* Verdict: each involved thread fails to read or write the target data and takes a segmentation fault, has error handling code executed, or is terminated in all tests => PASS, otherwise FAIL
* Evidence: error messages, log message, or the OS reboots or halts
* Evidence: error messages, log message, or the product reboots or halts
For each mitigation grouped under requirement TR-MSAF, for each field Preparation, Verdict, or Evidence, if it is not specified for that test, then the above Preparation, Verdict, or Evidence field shall apply.
@@ -1018,7 +1004,7 @@ Both kernel and userspace threads shall reject writes beyond the bounds of alloc
* Objective: Prevent thread from writing beyond the end of heap memory
* Activities: For each of kernel and userspace, for each type of heap memory, allocate a fixed size from each class of heap memory, write beyond it
