General Overview of RidgeRun Platform Security Manual
🚧 Documentation is under development
The RidgeRun Platform Security Manual guide is currently under active development. Some sections may be incomplete or change without notice.
Questions? Contact RidgeRun or email to support@ridgerun.com.
- Introduction
- General Security Concepts
- Getting Started
- Contact Us
- Sponsor your Favorite Feature
Why do I need to secure my project?
Modern embedded systems are no longer isolated devices. They are increasingly connected to networks, cloud services, mobile applications, external devices, and other infrastructure. While this connectivity enables new capabilities, it also increases the number of ways in which a system can potentially be accessed or attacked.
At the same time, cybersecurity expectations are changing. Customers expect their information and systems to be protected, organizations need to protect their infrastructure and intellectual property, and new regulations are introducing cybersecurity requirements for products throughout their lifecycle.
For these reasons, security should not be considered only as an additional product feature. It should be part of the system design from the beginning.
Cybersecurity is becoming a regulatory requirement
Cybersecurity is increasingly becoming a regulatory requirement rather than an optional product feature.
A relevant example is the European Union's Cyber Resilience Act (CRA). The CRA establishes cybersecurity requirements for products with digital elements and introduces responsibilities for manufacturers regarding the design, development, production, and maintenance of their products.
Among other requirements, manufacturers may need to:
- Assess the cybersecurity risks associated with their products.
- Design and develop products with an appropriate level of cybersecurity based on those risks.
- Avoid placing products on the market with known exploitable vulnerabilities.
- Provide secure configurations where applicable.
- Identify, document, and remediate vulnerabilities.
- Provide mechanisms to securely distribute security updates.
- Maintain vulnerability-handling processes throughout the product support period.
- Report certain actively exploited vulnerabilities and severe security incidents.
The CRA applies broadly to products with digital elements whose intended or reasonably foreseeable use includes a direct or indirect connection to another device or network.
This represents an important change in how product security is approached: cybersecurity is increasingly expected to be considered throughout the product lifecycle rather than being addressed only after a vulnerability or security incident is discovered.
For embedded product developers, security decisions can therefore affect not only the technical robustness of the system but also regulatory compliance and access to certain markets.
Connected systems have a larger attack surface
Modern embedded systems can expose multiple interfaces to the outside world.
Depending on the product, these may include:
- Ethernet and Wi-Fi connections.
- Bluetooth or other wireless interfaces.
- Cloud services and APIs.
- Remote administration interfaces.
- OTA update mechanisms.
- USB and other physical interfaces.
- Debug interfaces.
- Mobile or web applications.
- Third-party software and open-source components.
Each additional interface, service, and dependency can increase the system's attack surface: the set of possible points through which an attacker may attempt to access or influence the system.
An attacker may also have access to increasingly capable tools and publicly available information. Vulnerability databases, automated network scanners, security research, reverse-engineering tools, and reusable attack techniques can reduce the effort required to discover weaknesses in poorly protected systems.
This means that relying only on the assumption that an embedded device is difficult to access or understand is generally not an adequate security strategy.
Instead, systems should be designed under the assumption that potential attackers may eventually obtain information about the hardware, software, interfaces, or vulnerabilities used by the product.
What can be affected by a security compromise?
A cybersecurity incident does not necessarily affect only the device itself.
Depending on the application, several assets may be at risk:
| Asset | Possible impact |
|---|---|
| User data | Personal, confidential, or sensitive information could be exposed or modified. |
| Device operation | An attacker could modify the expected behavior of the device or gain unauthorized control over it. |
| Software and intellectual property | Proprietary software, algorithms, models, or other intellectual property could be extracted or modified. |
| Credentials and cryptographic material | Passwords, certificates, cryptographic keys, or other credentials could be extracted and used to access additional devices or services. |
| System availability | Devices or services could become unavailable, resulting in downtime or disruption of operations. |
| System integrity | Software, firmware, configuration, or data could be modified without authorization. |
| Safety | In systems that interact with the physical world, unauthorized behavior could create safety risks. |
| Connected infrastructure | A compromised device could potentially be used as an entry point to attack other systems on the same network or infrastructure. |
The importance of each of these assets depends on the purpose of the product and the environment in which it operates.
The impact of a security compromise depends on the industry
There is no single security level that is appropriate for every embedded system.
The consequences of a compromise can vary significantly depending on where the system is deployed and what it controls.
Consumer and IoT devices
Consumer and IoT products may store user information, credentials, network configuration, or cloud access tokens.
A compromised device may expose personal information, allow unauthorized access to the user's network, or become part of a larger attack against other systems.
Security therefore contributes directly to protecting user privacy and maintaining customer trust.
Industrial systems
Industrial embedded systems may monitor or control machinery, production lines, sensors, or other operational infrastructure.
A compromise may result in:
- Unauthorized modification of device behavior.
- Production downtime.
- Loss or manipulation of operational data.
- Equipment damage.
- Access to other systems on the industrial network.
- Potential safety risks.
In these environments, cybersecurity is therefore closely related to operational continuity and, in some cases, physical safety.
Medical systems
Medical systems can process sensitive patient information while also interacting directly or indirectly with healthcare services and medical equipment.
A cybersecurity incident could result in:
- Exposure of personal or medical information.
- Loss of availability of healthcare services.
- Manipulation of medical information.
- Disruption of medical devices or infrastructure.
- Potential risks to patient safety.
For this reason, users, healthcare organizations, and regulators need confidence that medical products appropriately protect both information and system operation.
Defense and critical infrastructure
Systems used in defense, communications, energy, transportation, or other critical infrastructure can have consequences beyond the individual device or user.
A compromise could expose sensitive information, disrupt critical services, provide unauthorized access to infrastructure, or allow an attacker to manipulate system behavior.
In these environments, cybersecurity can therefore become a matter of public safety, infrastructure resilience, or national security.
Security is also about trust
Security is not only about preventing technical attacks. It is also about establishing and maintaining trust.
Different stakeholders expect different things from a secure product:
- Users expect their personal and sensitive information to remain protected.
- Customers expect products to operate as intended and resist unauthorized access.
- Companies need to protect their infrastructure, intellectual property, credentials, and services.
- System integrators need confidence that a component will not introduce unnecessary vulnerabilities into a larger system.
- Regulators may require manufacturers to demonstrate that cybersecurity risks are appropriately identified and managed.
A security incident can therefore affect more than the compromised system. It may also affect customer confidence, company reputation, regulatory compliance, and future business opportunities.
Building security into a product helps establish confidence that the system can protect its assets and continue operating as expected even when exposed to potential threats.
Security should start with the system design
Security is generally more effective when it is considered during system design rather than added after development is complete.
However, this does not mean that every available security mechanism should be enabled.
Different projects have different assets, attack surfaces, threats, regulatory requirements, and consequences of compromise. A simple embedded sensor and a medical, industrial, or defense system may therefore require very different levels of protection.
Before deciding which security mechanisms a project needs, it is important to understand:
- What needs to be protected?
- Who could potentially attack the system?
- What level of access could an attacker obtain?
- Which interfaces could be used to attack the system?
- What would be the impact if the system were compromised?
- Which regulatory or customer requirements apply to the product?
These questions form the basis for identifying a project's security requirements.
Once those requirements are understood, appropriate security mechanisms can be selected. Depending on the system, these may include technologies such as Secure Boot, hardware-backed key storage, Trusted Execution Environments (TEE), TPMs, storage encryption, secure communication, secure OTA updates, access control, system hardening, or other security mechanisms.
The objective is not to enable every available security feature, but to implement protections that appropriately address the specific project's risk.
Understanding these risks is therefore the first step toward answering the next question: What do I need to consider before securing my project?