Self-testing as optional

5.2.X TR-TEST: Enable testing and collection of test output

5.2.X.x Requirement

The operating system shall provide a method of running the tests for technical requirements and outputting the test results in a machine readable > format on the product as placed on the market.

I urge you to reconsider this stance, for several reasons.

1. This requirement cannot be derived from the CRA essential requirements nor from a general cybersecurity risk assessment of network interfaces. I think you can keep the idea, but present and argue for its value and limitations in an informative section.

2. Consider input validation in the sense of EN 18031-x:2024::GEC-6.

A self-test of this requirement would amount to the testing of certain internal functions, but does not necessarily equate to testing the full complexity of the input path. Often it will be the case that there are additional relevant layers or functions which will not be captured by the self-test, and thus it becomes misleading. For example a function called validate_L2_frame() might work perfectly and pass any self-test, whilst there still remain vulnerabilities in functions prior to this function being called.

I think if anything, you as the authors, can argue that a control tested in this manner is regarded as sufficiently tested (conformant) accordingly with the standard, but not that this manner of testing is necessary. You can do so if you consider the residual risk small enough and it gives flexibility to those manufacturers who wish to utilise self-testing.

If you instead strictly require self-testing, then you will create problems for manufacturers who do not consider that residual risk acceptable and would like to test strictly at the interface, for example using fuzzing techniques. Such manufacturers would have to jump through hoops to make that a reality, so that their product can self-test itself at the interface. I can't imagine that this is the intention.