# Tradeoffs in Key Rotation Strategies for Industrial Internet of Things Devices and Firmware
## 4 Recommendations and Conclusions  
Based on the discussion points and analysis mentioned above, consider the following recommendations. First, identify and evaluate overarching factors that may pose an impact or influence over a particular rotation approach. For example, organizational constraints, such as industry regulatory requirements, organizational policies, standards, and accepted norms such as risk appetite, might influence the decision to use one rotation approach over the other. As a specific case, IEC 62443 is an internationally recognized standard that covers the cybersecurity requirements of industrial automation and control systems. Part 62433-4-2 specifies capabilities that ICS components must include, depending on the associated security level. Among the IEC 62443 parts are requirements for the protection of secrets, which necessitates strong key management capabilities [17]. As a result, the longevity of the keys combined with key management requirements should be considered when deciding on a given rotation approach. Do consult qualified experts as needed, such as cybersecurity staff and legal counsel. As a guiding principle and based on perceived risks such as the impact of compromised keys, such secrets must be adequately protected, and the product must be resilient to attack. Key management is a separate topic for discussion and is out of the scope of analysis in this paper. Second, evaluate the technical constraints presented in this paper in conjunction with risk factors such as the inherent or current risk [25] associated with the target system followed by residual risk. Inherent risk provides asset owners with a way to help rationalize cybersecurity requirements for a given system and ensures that the requirements are proportionally aligned to the inherent risk level. Specifically, inherent risk should consider factors such as the intended behavior and technical capabilities afforded a given system along with the intended deployment scenario and use cases. For example, locally accessible devices that provide read-only water consumption insights hold much less inherent risk than IIOT devices capable of remote water shut-off for an entire city. Residual risk is subsequently factored after additional controls such as rotation of certificates and keys have been applied. A key objective is to ensure residual risk is reduced to a level that falls within the risk appetite of related stakeholders such as the risk owner for the target system. As a result, consider inherent risk followed by the extent of residual risk afforded the target system when weighing options related to rotation of certificates and keys. Based on the tradeoffs covered in the previous section, consider the following recommendations:  
* Take advantage of certificate attributes such as organizational unit to set additional scope and filtering on the firmware validation process. Like access control, consider the pros and cons of keeping track of the mapping between attributes, firmware updates, and intended scopes, however. * Understand that there is no one-size-fits-all solution. Systems with fewer requirements for fast boot can engage in more adaptive systems, while other systems with rapid boot requirements and few resources might need to accept limited rotation capabilities at the lowest level. * Predetermine rotation practices based on the tradeoffs and implications involved with rotating certificates versus associated keys. For example, under a planned rotation scenario, certificates should be time-bound, with planned rotation based on a predetermined percentage of the certificate expiry in years as a threshold (e.g., rotate no later than x% of expiry). * Closely evaluate hardware platform constraints, such as processor architecture. Also, look for nuances such as related build utilities. On one hand, open systems might pave the way for increased levels of flexibility and modular use of cryptography. On the other hand, some might pose rigidity due to limited cryptographic support options.