EMB3D + ARIANNA: Bringing Embedded Risk Management Into Operations

A lot of embedded security programs still work the same way they did years ago.

A threat model is created. Risks are documented. Controls are defined. Someone exports a PDF, the document ends up in a project folder, and six months later nobody looks at it anymore.

The problem is not the framework itself. The problem is that embedded devices do not stand still.

New CVEs appear every week. Suppliers silently change components. Open source libraries become vulnerable. RTOS versions reach end-of-life. Exploits become public. Suddenly the original risk assessment no longer reflects reality.

This is exactly where frameworks like EMB3D become interesting when combined with a platform like ARIANNA.

EMB3D Makes Sense for Embedded Devices

One thing many security teams struggle with is that traditional IT risk methodologies often do not map well to embedded products.

An industrial controller is not a laptop. A medical device is not a web application. A smart sensor deployed for 15 years has completely different lifecycle challenges than enterprise IT.

EMB3D approaches security from an embedded perspective:

• Hardware dependencies
• Firmware architectures
• Field interfaces
• Constrained environments
• Supply chain exposure
• Safety and operational impact

That makes it much more practical for manufacturers building connected products.

It also aligns well with the direction regulations are moving, especially with the Cyber Resilience Act forcing manufacturers to take vulnerability management seriously over the full supported lifecycle of a product.

The Missing Piece in Most Risk Assessments

The real weakness in many embedded security programs is not the assessment itself. It is what happens afterwards.

Most risk assessments are static snapshots.

At the moment they are written, they may be technically correct. But the actual device keeps evolving:

• Libraries get updated
• Suppliers change parts
• Vulnerabilities are disclosed
• Attack techniques evolve
• Exploitability changes over time

So the document slowly drifts away from operational reality.

You can already see this becoming a problem with CRA discussions. Manufacturers are expected to continuously monitor vulnerabilities and maintain visibility into affected products. That is difficult if your risk management process ends after the initial assessment workshop.

ARIANNA Turns Risk Management Into Something Operational

This is where ARIANNA fits naturally next to EMB3D.

EMB3D helps define:

• What matters
• Where the risks are
• What should be protected
• Which attack paths are relevant

ARIANNA focuses on what happens afterwards:

• Continuous vulnerability monitoring
• SBOM and HBOM management
• Tracking exposure over time
• Correlating vulnerabilities to actual devices
• Monitoring supplier and component risks
• Maintaining evidence for compliance and reporting

Instead of treating the risk assessment as a one-time exercise, it becomes something alive.

A Practical Example

Take a connected industrial gateway running Linux with a mix of commercial and open source components.

Using EMB3D, a manufacturer identifies several relevant risks:

• Remote access exposure
• Outdated crypto dependencies
• Insecure maintenance interfaces
• Third-party software risks

That gives structure to the security architecture.

But then reality starts moving.

Three months later:

• A new OpenSSL vulnerability appears
• One supplier stops supporting a component
• An exploit becomes public
• A dependency inside the SBOM is suddenly high risk

Without continuous visibility, security teams often do not know which products are affected, whether the vulnerable component is actually present, or which customers are exposed.

That is exactly the operational gap ARIANNA is designed to solve.

Investigating EMB3D Integration Inside ARIANNA

At ARIANNA we are currently investigating how EMB3D concepts and workflows could be integrated more directly into the platform itself.

The idea is simple.

Today, many organizations separate:

• Threat modeling
• Risk management
• SBOM management
• Vulnerability monitoring
• Compliance evidence

Across different tools, spreadsheets, and teams.

We believe there is value in bringing those worlds closer together.

Imagine being able to:

• Link risks directly to device models
• Correlate threats with actual SBOM components
• Monitor whether mitigations remain effective over time
• Connect vulnerability intelligence directly to identified EMB3D risks
• Maintain a living view of device exposure instead of static documentation

For embedded manufacturers dealing with CRA requirements, this could significantly reduce the gap between architecture-level risk analysis and operational vulnerability management.

It is still an area we are actively exploring, but we believe the combination is promising.

Why This Combination Matters for CRA

The CRA is changing the conversation in embedded security.

For years, manufacturers mainly focused on getting products released. Security documentation was often created for certification or procurement purposes.

Now regulators expect something more operational:

• Vulnerability handling
• Continuous monitoring
• Coordinated disclosure processes
• SBOM management
• Lifecycle security maintenance
• Evidence that risks are actively managed

That means manufacturers need both:

• A structured risk methodology
• Operational visibility into deployed products

EMB3D covers the first part well.

ARIANNA addresses the second.

Embedded Security Is Becoming a Lifecycle Problem

The biggest shift happening right now is that embedded security is no longer only about secure development.

It is becoming a lifecycle management problem.

Especially in sectors like:

• Industrial automation
• Automotive
• Medical
• Aerospace
• Critical infrastructure

Devices stay operational for many years. During that time the threat landscape changes constantly.

A risk assessment done once at the start of development is simply not enough anymore.

The organizations that will handle CRA successfully are probably not the ones with the biggest PDF reports. They will be the ones that can continuously answer questions like:

• Which devices are exposed?
• Which components are vulnerable?
• Which customers are affected?
• What changed since last month?
• Which risks require action now?

That requires operational visibility, not just documentation.

Final Thoughts

EMB3D and ARIANNA solve different parts of the same problem.

EMB3D helps manufacturers understand risk from an embedded system perspective.

ARIANNA helps them keep that understanding connected to reality as products evolve over time.

We believe there is strong potential in bringing those worlds even closer together, and that is why we are actively investigating how EMB3D concepts can become part of the ARIANNA platform itself.

As embedded security moves toward continuous lifecycle management under regulations like the CRA, that connection between risk modeling and operational visibility becomes increasingly important.