EN 
DE 
According to the CRA, manufacturers are required to document, in a manner that is transparent to auditors, why they have or have not implemented security measures. Security decision records are ideally suited for documenting decision-making processes.
Fig.1: SDR stack
Traceable documentation of the risk assessment
The Cyber Resilience Act (CRA) requires all manufacturers to perform a cybersecurity risk assessment (Annex I.I) of their products that contain digital elements and to keep this assessment up to date throughout the entire product lifecycle (Article 13.1-4). This obligation applies to all machines, IoT devices, embedded systems and, of course, software.
In the event of an inspection by the market surveillance authority or a legal dispute, the manufacturer must be able to demonstrate that their product is adequately protected against cybersecurity risks. In such cases, the inspectors scrutinize the risk assessment very closely. Therefore, thorough documentation of the risk assessment (Annex VII.3) is extremely important.
An auditor must be able to understand why the manufacturer decided in favor of or against certain security measures for a given usage scenario. Architecture Decision Records (ADRs) . Security Decision Records (SDRs) have proven effective for documenting decision-making processes. Security decision records (SDRs) are a variant of ADRs designed to document security decisions made during risk assessment.
Common origin of risk assessment and security decision records
SDRs are particularly well-suited for documenting risk assessment because both can be derived from threat modeling. For threat modeling, I prefer the 4-questions framework by Adam Shostack because of its simplicity.
- Question 1: What are we working on? – Rephrased for the CRA: Which usage scenario are we currently considering?
- Question 2: What could go wrong? – Which key product characteristics, such as confidentiality, availability, or minimising he attack surface, are compromised?
- Question 3: What are we doing about it? – What security measures are we using to reduce or eliminate the risks posed by the compromised product characteristics?
- Question 4: Have we done a good job? – Have we addressed all possible risks adequately?
Now, all we need is a bridge between the identified risks and the CRA’s product characteristics. Once again, Adam Shostack provides this bridge in his article The Cyber Resilience Act (CRA). The product characteristics (Annex I.I.2b-m) follow a pattern.
Products must provide protection
– against a hazard (question 2)
– through appropriate safety measures (question 3).
A hazard (e.g. unauthorised access) is nothing more than a violation of a product characteristic (e.g. access only by authorised persons). By negation, we move from a hazard to a product characteristic.
I explain exactly how risk assessment works in the article A Pragmatic Approach to CRA Risk Assessment. In the next section, we’ll learn how to use the four questions to write an SDR.
Definition of a security decision record
SDR-NNN: Title
Status: Draft, Proposal, Accepted, Replaced, Rejected
Date: Date of latest status change
Author(s): Names of the author(s)
Context section
Usage scenario (question 1) with existing security measures.
The table reflects the current state, indicating which product characteristics are violated or not (question 2). Possible values are “+” for met, “-” for violated or “n/a” for not applicable.
2b 2c 2d 2e 2f 2g 2h 2j 2l 2m Current status
OptionsList of possible safety measures (question 3) to mitigate risks posed by defective product characteristics.
Decision
Selected options.
Before making a decision, we ensure that we have addressed or eliminated all hazards (question 4).
Consequences
Explanation of why the current state has or has not improved after applying the selected options.
The table summarizes the current state and specifies the target state, indicating which product characteristics are or are not compromised after applying the selected options (question 2).
2b 2c 2d 2e 2f 2g 2h 2j 2l 2m Current status Target status
Every SDR begins with a unique number SDR-NNN and a descriptive Title.This is followed by the Status, the Date of the last status change and the names of the Authors.
An SDR’s lifecycle begins with the status Draft.When the SDR is ready for review by the product team, we set the status to Proposal. If the SDR passes the review, the new status is Accepted. From that point on, we are no longer allowed to change the SDR so that we can easily trace the decision-making process in a few months or years.
If we do decide to change the decision later, we create a new SDR and set the status of the old SDR to Replaced. The old SDR references the new SDR. If a decision is no longer valid and there is no replacement, the SDR is given the status Rejected.
In the Context section, we describe a usage scenario, such as remote maintenance or the commissioning of a device by a technician. We then review the product characteristics from Annex I.I.2 of the CRA and determine which product characteristics are violated or met. We enter this degree of violation as the Current status in the table. The following diagram once again briefly summarises the product characteristics (2a)-(2m).
Fig. 2: All essential product characteristics (2a)-(2m) for documenting risk assessment in SDRs
For each product characteristic that is met, we explain why the existing safety measures are sufficient to mitigate the hazard or why no safety measures are necessary. In the latter case, we explain why the potential damage to the device itself or to connected devices is too minor, or why the specific usage circumstances or conditions of use derived from the intended purpose sufficiently mitigate the hazard. These justifications belong in the Context section.
Under Options , we list the safety measures that could be used to mitigate or eliminate the product characteristics that are not met. The first option is always to do nothing. Listing only this one option may appear suspicious to the reviewers. The reviewers might assume that the manufacturer has not adequately addressed the risks of this usage scenario. Therefore, it makes sense to offer at least two options.
In the Decision section, we specify which options we select. If we choose the “Do Nothing” option, we simply copy the “Actual State” column into the “Target State” column, and we’re done. If we decide to take action, we must explain under Consequences why the product characteristics will improve as a result of the selected safety measures. We do this in the same way as we did for the existing safety measures in the context. This completes our description of the Target status of the use scenario. We enter the severity level for each product characteristic in the “Target status” column of the table.
In the Decision section, we specify which options we choose. If we select the “Do Nothing” option, we simply copy the “Actual State” column into the “Target State” column, and we’re done. If we decide to take action, we must explain under “Consequences” why the product characteristics will improve as a result of the selected safety measures. We do this in exactly the same way as we did for the existing security measures in this context. We have now described the “Target State” of the usage scenario. We enter the severity level for each product characteristic in the “Target State” column of the table. Three product characteristics are missing from the table.
- 2a. The device must be shipped without any known exploitable vulnerabilities.
- 2i. The negative impacts on the device itself, as well as on the availability of other devices and networks, should be minimised.
- 2k. The effects of security incidents must be mitigated through appropriate measures.
Their omission is intentional, as these three properties are objectives and follow from the other properties. If our security measures satisfy the other properties, then these three properties are also satisfied.
Example of a security decisions record
Fig. 3: Operating environment of a heat pump from the user's perspective, with a use case for Remote maintenance via VNC
For this use case, we have selected remote maintenance via VNC for a heat pump. Further details can be found in the SDR.
SDR-007: Remote maintenance via VNC
Status: Accepted
Date: 16.09.2026
Author(s): Burkhard Stubert
Context section
A technician can connect to any of the manufacturer’s heat pumps via VNC at any time to perform remote maintenance. Using VNC, the technician operates the heat pump’s graphical user interface. In addition to the functions used by residents, the technician has access to additional functions for diagnostics and maintenance.
- The VNC connection is encrypted (2e).
- VNC transmits only the changed portions of the screen. It is very difficult to tamper with the transmitted data (2f), as the data is compressed and encrypted.
- The technician cannot view the home network’s Wi-Fi password or other residents’ login credentials (2g).
2b 2c 2d 2e 2f 2g 2h 2j 2l 2m Current status – n/a – + + + – – – n/a
Options
- Nothing to do.
- The technician must have successfully logged in to the cloud backend before he can connect to the heat pump via VNC
- By default, the VNC server on the heat pump is disabled. Only when a resident activates the VNC connection does the heat pump start the VNC server, allowing the technician to connect via VNC.
- The heat pump has a private IP address and is therefore not accessible from the Internet. Consequently, it must initiate the VNC connection. The cloud backend forwards the heat pump’s VNC connection request to the technician’s VNC client. The technician accepts the connection.
- The heat pump automatically closes the VNC connection after two hours. Residents can extend the session once by two hours before it expires and can end it at any time.
- The heat pump logs the start and end times of the VNC session as well as the technician’s identity as security events.
Decision
We select options 2, 3, 4, 5 and 6.
Consequences
In addition to the VNC API key, an attacker would need both a technician’s login credentials (option 2) and the explicit consent of a resident (option 3). This provides better protection for access (2d) to the heat pump.
Options 4 and 5 minimize the attack surface (2j), since the heat pump cannot be accessed by computers outside the home network and the VNC connection is strictly time-limited.
Due to option 5, a denial-of-service attack can last a maximum of four hours or until a resident ends the VNC session. This increases the heat pump’s availability (2h).
Option 6 logs security events (2l).
All options take effect upon commissioning, ensuring a secure default configuration (2b) for this usage scenario.
2b 2c 2d 2e 2f 2g 2h 2j 2l 2m Current status – n/a – + + + – – – n/a Target status + n/a + + + + + + + n/a
Incorporating SDRs into the technical documentation without modification
With regard to product characteristics, the CRA already specifies several standard usage scenarios that must be adequately protected against cyberattacks: commissioning (2b), decommissioning (2b and 2m), automatic security updates with an opt-out option (2c), and logging of security events (2l). In addition, there are all the core and supplementary functions listed in the intended use. For the heat pump, we can see these functions in the diagram:
- Direct operation of the indoor unit by residents or technicians
- Remote control via a mobile app or web app by residents
- Remote maintenance via VNC by technicians
- Remote monitoring via a web app by technicians
- Functional updates via the Internet or a USB flash drive
- User authentication at the cloud backend or on the indoor unit
When we look at the heat pump from a technical perspective, a number of additional usage scenarios come into play. Identifying all of these scenarios is the answer to question 4: Have we addressed all risks in all usage scenarios?
We document all these usage scenarios and their security relevance using SDRs. We incorporate these SDRs into the technical documentation without modification, thereby complying with Annex VII.3. SDRs enable us to document our decision-making process during risk assessment in a way that is easily traceable for external auditors.
Get up to speed on this highly topical subject: From 16-20 November 2026, the training The Cyber Resilience Act (CRA) – A Practical Guide for Embedded Development , led by Burkhard Stubert, will take place in Munich. Using a heat pump as an example, participants will learn how to conduct the CRA conformity assessment themselves.
Further information
MicroConsult-Training: The Cyber Resilience Act (CRA) – A Practical Guide for Embedded Development
MicroConsult Training & Coaching: Embedded and Real-Time Software Engineering
MicroConsult Expertise: Embedded and Real-Time Software Engineering
MicroConsult Training & Coaching Overview
Author
As a systems architect and chief engineer, Burkhard Stubert helps manufacturers make important decisions early on and correctly in order to avoid costly surprises. His clients build agricultural machinery, construction equipment, vending machines, cars, ovens, measuring instruments and other machines and devices. For 13 years, he has been running his own business.
