Introduction

System and product designers are increasingly required to incorporate security measures into their designs due to standards and regulatory compliance, such as the CRA. Beyond mandatory compliance, it's important to consider the financial risks of overlooking security in system design. A cybersecurity incident involving a product can lead to reputational damage and potential legal action against the developer. Additionally, a compromised product can make a network or system vulnerable to further attacks. This situation drives the inclusion of additional security requirements in product and system specifications to minimize risks to products and the systems/networks they integrate with.

Security is never a certainty, it is a balance between:

• The cost of the attack (time, tools, skill, monetary, etc.).
• The impact of a compromise for both the attacker and the attacked (monetary, reputation, legal, regulatory, safety, etc.).

Enhancing a system's security often requires extra resources, which can lead to increased costs, longer execution and startup times, and added complexity in development, manufacturing and deployment. It's important to consider all these factors when deciding on the necessary security measures for a system. Defining the security goals and requirements at the start of system development is crucial. This ensures that the chosen hardware can meet these goals and requirements throughout the product's life cycle.

Security is also often implemented through layered defense. Having multiple layers of defense against a possible attack reduces the likelihood of a single point of failure compromising the entire system, or might limit the impact of the compromise of a single layer of the defense.

This document covers several common security use cases and examples of how the hardware features of the dsPIC33A family of microcontrollers support system designers to enable these cases in their products. Each section provides an example implementation of that use case, but there are often many other options that the hardware supports. These examples should be used as examples to understand the underlying hardware features in the context of a use case, but each system should evaluate their needs and design their system security around their requirements.