A Practical Approach to Integrating Security into Embedded DevOps

As embedded systems become more connected and complex, cybersecurity is no longer optional; it’s a fundamental system requirement. Yet, security in embedded development has traditionally been an afterthought, often addressed late in the lifecycle or even post-deployment. With the rise of sophisticated threats, including AI-driven attacks, delaying security is a risk developers and companies can no longer afford.

Instead of treating security as a hurdle, teams can embrace DevSecOps. This methodology integrates security directly into your embedded DevOps processes, making it a seamless and proactive part of the development cycle.

In this post, we’ll break down what DevSecOps is, how it impacts embedded development, and practical ways to adopt it to build more secure, resilient systems from day one.

The Shift Toward DevSecOps in Embedded Systems

Over the last couple of years, embedded teams have started to adopt wider practices in software engineering, like DevOps. DevOps is the integration of development (Dev) and operations (Ops) to streamline the design, development, testing, deployment, and maintenance of embedded software and firmware. DevOps emphasizes:

• Providing incremental value through small and frequent iterations (Continuous Integration/Continuous Deployment (CI/CD))
• Collaboration and communication
• Automation
• Feedback loops to improve efficiency, quality, and time-to-market 

The result so far has been that teams produce higher-quality software faster. 

Figure 1 – DevOps provides a value feedback loop between a company and its customers, improving collaboration and communication. 

DevSecOps (Development, Security, and Operations) is the DevOps process you’ve come to love with an added twist. Security is integrated into every development lifecycle phase rather than treating it as a separate or final step. It extends the principles of DevOps by embedding security practices into each area of the development cycle: 

• Design
• Coding (implementation)
• Testing
• Deployment
• Maintenance

The goal is to address vulnerabilities proactively throughout the development cycle, not just at the end.

Traditionally, security was always left to the end of the development cycle because it consisted of just a few activities:

1. Add a secure bootloader for secure firmware updates
2. Lock down the JTAG port
3. Add tamper protection (left out in many cases)

All of this can be done at the end of the development cycle IF it’s a standalone, disconnected device! 

The Challenge with IoT Devices

The challenge today is that most products are connected devices! The IoT is taking over the world! That means they aren’t just simple controllers but nodes on a global network that are always connected 24 hours a day, 7 days a week, and 365 days a year. 

Physical access to the devices isn’t the only security feature needed today. The network has become the most significant security threat, which means security can’t just be bolted on at the end; it needs to be thought about from the beginning and integrated throughout the entire development lifecycle. 

To provide a secure solution today, you need to understand the threats your system will face and plan how you will thwart those attacks. That means your software architecture, hardware, implementation, and testing must all consider security. Ignoring security along the way increases the likelihood you won’t be able to secure your system correctly in the end. 

For example, a potential customer approached me a week before their product was shipping, asking me to develop a secure bootloader for them. Upon reviewing their design, they had made several poor choices along the way:

1. Their hardware did not support a hardware-based Root-Of-Trust
2. There were no cryptographic accelerators so the boot process would be extremely slow 
3. Critical software assets were not partitioned into separate areas of concern. 

Sure, some things could be done to make the system feel secure, but it would have been all smoke and mirrors.

Regulatory Compliance

Even if you decide that you want to ship a product without security, you might find that your company could be liable for shipping a solution that isn’t secure. There are numerous security laws and regulations that are going into effect worldwide. 

These regulations are forcing businesses and developers to think about security early and often! A few that are affecting embedded developers include:

• Cyber Resilience Act (CRA)

Adopted on October 10, 2024, the CRA establishes comprehensive cybersecurity requirements for products with digital elements, including hardware and software. Manufacturers are now obligated to ensure security throughout a product’s lifecycle, conducting risk assessments and implementing vulnerability handling processes. 

Non-compliance can result in fines of up to €15 million or 2.5% of the offender’s worldwide annual revenue.

• Federal Trade Commission (FTC) Guidelines

The FTC has issued recommendations emphasizing data security, user consent, and data minimization for companies involved in the Internet of Things (IoT). While these guidelines are not legally binding, they serve as a framework for best cybersecurity practices.  

• The U.S. Cyber Trust Mark

It is a voluntary cybersecurity labeling program introduced by the Federal Communications Commission (FCC) to help consumers identify internet-connected devices that meet established cybersecurity standards. Launched in January 2025, the program aims to enhance the security of consumer devices such as smart appliances, home security cameras, fitness trackers, and baby monitors.

These aren’t the only ones and won’t be the last. We’ve all heard the push about adopting Rust from the U.S. federal government as well. ( I would add a link, but the report seems no longer available on the government’s website). 

Failing to secure an embedded device could cause severe repercussions for companies that ignore these regulations. 

Core Principles of DevSecOps in Embedded Systems

When you consider adopting security as part of your Embedded DevOps solution and leveling up to DevSecOps, there are several core principles that you should adhere to. 

Principle #1 – Shift Security Left

It can still be tempting to leave security as an afterthought. After all, adopting security early also means that developers must fight with extra security throughout the entire development cycle. Doesn’t that mean shipping a product will take longer and cost more? Not necessarily! 

Shifting security left, from the end to throughout development, means that developers will be testing and working with security through the entire product life cycle! That has a ton of benefits like:

• Becoming more familiar and comfortable with security techniques and processes
• Testing the system’s security throughout the development cycle
• Improved code quality
• Accelerated compliance and certification
• Builds stakeholder trust

Instead of developing your product and waiting until the end to implement security, integrate security early in the development cycle. Security should be present at every stage, including the requirements and design phases. A secure system needs to be architected from the beginning, meaning security is shifted left. 

Principle #2 – Adopt Automation

Unfortunately, much of the push to secure an embedded system and shift security left involves following a checklist. While checklists are excellent and highly recommended, they overlook that teams get the most from their DevSecOps solution by automating as much of the security process as possible. 

Embedded teams have traditionally done a poor job of automating activities. The fact that the software touches hardware often gives teams an excuse that they need to perform checks manually and can’t automate it. Security testing, compliance checks, and vulnerability scanning can all be automated. 

Remove the burden from yourself and your teammates by automating security checks. Build them into your pipelines. Leverage tools to report the issues to you. (We’ll look at some ideas here later in this post). 

Principle #3 – Embrace Continuous Improvement and a Risk-Based Approach

Security doesn’t stop at deployment. It’s an ongoing process. Embedded systems, especially those in IoT, automotive, and industrial applications, often operate in the field for years or even decades. Security threats evolve, and vulnerabilities may emerge long after development. This makes continuous improvement and a risk-based approach essential elements of DevSecOps.

Continuous improvement can be performed throughout the product lifecycle and should include three core elements:

• Continuous Monitoring (Observability)
• Collaboration Between Teams
• A Risk-Based Approach

Continuous Monitoring (Observability)

Security in embedded systems should be proactive, not reactive. Implementing real-time monitoring for security threats and anomalies helps detect issues before they escalate. Logging, telemetry, and automated alerting mechanisms can help teams identify unauthorized access, unusual behavior, or potential vulnerabilities.

Collaboration Between Teams

Security is not just the responsibility of the security team. It’s a cross-functional effort. Developers, security teams, and operations must work together throughout the development lifecycle to ensure vulnerabilities are identified, mitigated, and patched efficiently. That’s why we call it DevSecOps! 

A Risk-Based Approach

Not all security threats are equal. Instead of applying one-size-fits-all security, prioritize efforts based on potential impact. Ask yourself:

• What are the most critical assets to protect?
• What are the likely attack vectors?
• How much security is necessary for the given threat model?

There’s no need to build Fort Knox when a simple lock will do; However, ensuring you’re adequately protected against real threats is essential. That’s why performing a Threat Model Security Analysis early and throughout your product lifecycle is best. 

By continuously monitoring, fostering collaboration, and focusing security efforts where they matter most, embedded teams can reduce risk, improve security posture, and ensure the long-term resilience of their products.

Implementing DevSecOps in Embedded Development

Shifting security left is a significant first step, but we need to go further to truly integrate security into the embedded development process. DevSecOps isn’t about bolting security on—it’s about weaving it into your day-to-day tactics. That means security needs to be considered before a line of code is written, incorporated into build and test automation, and continuously monitored throughout the product lifecycle.

For our purposes today, we are going to look at three key areas for implementing DevSecOps in Embedded Development:

• Automated Analysis
• IP Protection
• Production Control

Automated Analysis

For developers, the foundation of any good DevSecOps solution is going to be automating testing through the use of a CI/CD tool. There are plenty of CI/CD solutions out there that you can leverage like Jenkins, GitHub, and Gitlab, so we aren’t going to look specifically at these solutions. Instead, we are going to look at a general pipeline design and some tools professional developers can use to secure their embedded products. 

First, you want to ensure that your pipeline supports standard automation features like build, analysis, testing, and reporting, as shown in Figure 2. Your pipelines for DevSecOps will be very similar to DevOps, except that we will add additional tools in the analysis and testing pipelines to ensure the code is robust and there are no security vulnerabilities. 

Figure 2 – Typical pipelines and jobs that are performed in an Embedded DevOps solution.

During the analysis pipeline, you want to ensure your code follows secure coding practices. Static analysis is a powerful tool within DevSecOps because you can automate the analysis within your pipelines so that you don’t have to do it yourself manually. 

Static analysis helps you find potential issues in your code by analyzing the source code when it isn’t executing. 

There are many practices that static analysis can verify for you automatically including adherence to CERT C. CERT C is a set of secure coding guidelines specifically designed for the C programming language, which is still used by 60 – 70% of embedded projects. To go even further, you may also want to perform checks for other standards like MISRA C:2023. MISRA C is all about automotive safety, but it’s found its way into industries beyond it.

It’s worth emphasizing that most successful cyberattacks against embedded systems don’t rely on sophisticated techniques—they exploit basic coding defects and vulnerabilities in application code. Hackers systematically probe for common weaknesses like buffer overflows, improper input validation, and memory management errors, using these as entry points to gain unauthorized access or control. This reality makes thorough code analysis and testing not just good practice but essential security measures. Static analysis tools that can automatically detect these vulnerabilities provide a critical first line of defense, potentially identifying and eliminating security flaws before malicious actors can discover and exploit them.

One of the tools that I use for static analysis is IAR’s C-STAT.  IAR C-STAT is a static code analysis tool integrated within the IAR Embedded Workbench IDE, designed to identify potential issues in C and C++ code by checking for compliance with coding standards like MISRA and detecting potential problems like buffer overflows, arithmetic errors, and memory management issues, essentially helping developers improve code quality by proactively finding potential bugs before runtime.

Figure 3 shows an example output from C-STAT that you can use to then improve not just the quality of your software but also its security. 

Figure 3 – IAR C-STAT example report.

Intellectual Property (IP) Protection

It’s not uncommon for developers to overlook the fact that the source code is a critical company asset. While we often think about protecting customer data, we also need to protect the company’s intellectual property. Think about how many person-months of effort went into developing your product’s source code!

There are adversaries out there who will want to gain access to your source code, either to get a leg up on you or to find additional exploits for your system. To protect your source code and your device, there are three key security features you need to implement as part of your DevSecOps solution:

• IP Code Protection
• Encryption and Decryption
• Secure boot

IP Code Protection

Beyond your typical microcontroller settings to lock down JTAG and memory, you need secure libraries and tools to help protect your code during production, firmware updates, etc. The toolchain that I use for this purpose is IAR Embedded Secure IP. 

You may recall that when securing a system, you rely on Confidentiality, Integrity, and Authenticity, the modern CIA model. Embedded Secure IP has several features that I’ve found helps protect IP through the CIA model. 

First, it has build-in libraries for authenticity. It leverages a unique X.509 device certificate that can be used with industry standard public key infrastructure to authenticate device interactions. If you push a firmware update, you can use the library to authenticate the source is really your company and not someone trying to push malware onto the device. 

Next, the solution also has anti-cloning capabilities for both hardware and software. That means an adversary can’t clone your device during the manufacturing process without your permission! I can’t tell you how many stories I’ve heard of those types of things happening at contract manufacturing facilities. 

Finally, the solution also complies with government regulations which ensures your device is following the latest in recommended security practices. 

Encryption & Decryption for Secure Communication

One of the biggest risks in embedded systems today is unauthorized access either through intercepted communications or firmware updates injected with malware. DevSecOps means encrypting sensitive data both at rest and in transit.

To solve this problem, I’ve been using IAR Embedded Trust, which provides support for:

• Well-established cryptographic algorithms (AES, RSA, ECC) to secure firmware updates and prevent unauthorized modifications.
• Symmetric and asymmetric key pairs to ensure that only authorized entities can access or modify firmware.
• Secure firmware updates that encrypt application code so it can’t be intercepted and reverse-engineered.

By integrating encryption into your development pipeline, you ensure that even if an attacker gains access to your firmware binaries, they can’t decipher or modify them without the proper cryptographic keys.

Secure Boot, the Foundation of Trust

At the heart of any secure embedded system is a robust, secure boot mechanism. Secure boot ensures that only trusted firmware executes on your device from the moment it powers on. If an attacker tries to load unauthorized firmware, the boot process halts, preventing the execution of compromised code.

IAR Embedded Trust provides an immutable secure boot manager, which:

• Runs immediately on reset. That means that before the application runs, the bootloader secures the system before any application code attempts to run. This is often done with the assistance of a hardware-based Root-of-Trust. 
• Authenticates and verifies the integrity of your application code, making it impossible for malware to load before security checks are in place.
• Manages firmware updates securely by ensuring only properly signed and encrypted updates are applied to the system.

A well-designed secure boot process becomes “part of the chip”, forming a Root of Trust that guarantees your firmware’s integrity from power-on to execution. Without it, attackers could inject malicious bootloaders, exploit vulnerabilities, or overwrite critical system code.

Production Control

When you hand over your design to a manufacturing partner, you expect them to build only the number of units you’ve authorized. However, without proper security controls, nothing stops them from producing extra units—often referred to as overproduction. These extra units can be sold on the grey market, either under your brand or rebranded under another company’s name. 

The Overproduction Problem

Manufacturing partners may produce extra units for various reasons, including:

• Maximizing their profits, selling additional units without your approval.
• “Insurance” for defective units. Some manufacturers produce more than ordered, anticipating failures in testing. If all units pass, they may sell the excess.
• Leaking designs to competitors. Unauthorized production can lead to clones of your product appearing in markets where you don’t compete yet.

This can damage your business in multiple ways. For example, you might find that your company has lost revenues due to extra units being sold without your knowledge. You may have brand reputation damage for unauthorized or lower-quality clones flooding the market and harming consumers. 

Solving the Overproduction

IAR Secure Deploy ensures that only authorized units are produced, with security built into the provisioning process. It provides cryptographic control over manufacturing by:

1. Enforcing Per-Device Security Credentials

Each unit manufactured must receive a unique, cryptographically verified identity. If a factory attempts to produce more units than authorized, they will lack valid credentials and be unable to function as legitimate products.

2. Ensuring Secure Programming at the Factory

With Secure Deploy, firmware can only be programmed onto verified, authorized devices. Unauthorized chips or hardware will fail to receive valid firmware, rendering them non-functional.

3. Tracking & Auditability

The system provides a traceable record of every unit manufactured, making it easy to identify and investigate anomalies. This means you can verify exactly how many products were built and detect any discrepancies.

4. Preventing Unauthorized Cloning

Secure Deploy helps lock down your software and firmware against unauthorized duplication. Even if someone manages to extract firmware, it won’t run on unauthorized hardware without the proper cryptographic keys.

Secure deployment isn’t just about protecting software; it’s about protecting your business.

Overcoming Challenges in Adopting DevSecOps

Shifting to DevSecOps isn’t without its hurdles. Embedded teams often struggle with resource constraints, legacy code, and resistance to change. But these challenges aren’t excuses. They’re opportunities to build security in without breaking workflows.

Let’s take a look at a few of the common challenges and how you can overcome them.

Finding a Balance Between Security and Performance

Embedded systems don’t have the luxury of unlimited processing power and memory. Security features can’t just be bolted on if they slow things down or drain power. A poor-performing secure system may frustrate customers as much as an unsecured one. 

Overcoming this issue comes down to your hardware selection. Choose a microcontroller that has security peripherals like hardware-accelerated cryptographic operations. These peripherals can offload security tasks from the CPU to the peripheral, decreasing computation cycles. 

Another good practice is to optimize security checks to minimize performance impact, ensuring security doesn’t come at the cost of responsiveness. I know many of us love to use GCC or clang, but when it comes to security, you want the benefits of optimized code from a commercial compiler. I’ve done the measurements and found a 20 – 40% average improvement in execution speed. 

Securing Legacy Systems without a Rewrite

Most embedded projects weren’t designed with security in mind, making retrofitting a challenge. A full rewrite is often impractical, but that doesn’t mean security is off the table. It just means you have to be a little more creative and understand what exactly security means to you and your system. 

I recommend implementing incremental security improvements. Start by introducing static analysis tools to catch vulnerabilities early. Review your microcontrollers datasheet and implement any security features that might be supported. These are often low hanging fruit and even if they won’t fully secure your system, you have to remember there is no such thing. With enough resources and time, any system can be cracked. It’s about putting up enough road blocks that your adversary decides to pursue other targets. 

Finally, I would add secure update mechanisms (like signed firmware updates), which can help protect existing deployments without major code overhauls. These can sometimes be more challenging to developers without a lot of experience. I’ve written about 30+ bootloaders in my career. They aren’t for developers who don’t understand the underlying hardware and how it interacts with software. That’s why I often recommend the IAR tools. You can have a bootloader up and running within a few button clicks instead of a 3-month development effort. 

Overcoming Resistance to Change

Engineers worry that adding security will slow down development, introduce complexity, or disrupt their workflow. The key is making security frictionless. While security may have these effects, the idea is to look at those as pros not cons. If developers are working with the security solution through their entire development cycle, they’ll come to appreciate the process and better understand security concepts and how they keep your system safe. 

There are other methods as well that fit well with DevSecOps. For example, automate security checks. As many checks as possible should be automated and built directly into CI/CD pipelines so they run without extra effort. Make security a natural part of development, not an afterthought that adds roadblocks or frustrates developers. 

Security doesn’t have to be painful. The best approach is to integrate it seamlessly, so teams don’t even notice they’re doing DevSecOps, they’re just writing better, more secure code. 

The Bottom Line

Embedded security is no longer a “nice to have”; it’s a fundamental necessity. As IoT expands and regulatory pressure increases, securing your devices from day one isn’t just good practice; it’s a competitive advantage.

By embracing DevSecOps, embedded teams can integrate security seamlessly into development rather than treating it as an afterthought. Shifting security left improves code quality, simplifies compliance, and reduces the risk of costly vulnerabilities late in the product lifecycle.

The good news? Security doesn’t have to slow you down. Automation, secure toolchains, and proactive risk management make DevSecOps achievable without breaking workflows. Solutions like IAR Embedded Trust and Secure Deploy provide built-in security controls, ensuring firmware integrity, IP protection, and production security, all while keeping development agile.

The threat landscape is evolving, and attackers are getting smarter. But with the right mindset, tools, and processes, you can stay ahead, delivering secure, resilient embedded systems that stand the test of time.

Security isn’t a roadblock; it’s the foundation of trust, reliability, and long-term success. The only question left is: How soon will you start?