What services does Yunga Labs provide?

Firmware engineering in C/C++ on bare-metal and RTOS, edge AI and TinyML on microcontrollers, AI-powered development environments for embedded teams, and EU Cyber Resilience Act readiness: SBOMs, secure boot, OTA updates, and the technical documentation regulators require.

What is the EU Cyber Resilience Act and does it affect my product?

The CRA is an EU regulation that requires products with digital elements — connected devices, embedded systems, and their software — to meet cybersecurity requirements such as vulnerability management, SBOMs, and secure updates. Most manufacturers selling in the EU must comply from 2027. Yunga Labs helps teams prepare with gap analysis, secure boot, OTA infrastructure, and compliance documentation.

Can machine learning really run on a microcontroller?

Yes. With TinyML techniques — model quantization, pruning, and optimized runtimes such as TensorFlow Lite Micro — anomaly detection, predictive maintenance, audio, and vision models run directly on MCUs and NPUs, without cloud connectivity. That means lower latency, lower cost, and better privacy.

Do you work with software companies or only hardware manufacturers?

Both. Yunga Labs works with any team building products that run in the real world: hardware manufacturers, software companies with connected or embedded products, and everything in between.

What industries does Yunga Labs have experience in?

Safety-critical and regulated systems: medical devices under IEC 62304, automotive telemetry, mission avionics, and industrial control. That level of engineering rigor is applied to every project, regulated or not.

Where is Yunga Labs based and where do you work?

Yunga Labs is based in Málaga, Spain, and works with teams across Europe — remotely by default, on-site when a project requires it.

Guide

EU Cyber Resilience Act: A Practical Checklist for Device Makers

Updated August 2026 · Yunga Labs

The EU Cyber Resilience Act (Regulation (EU) 2024/2847, the “CRA”) is the first European regulation that imposes cybersecurity requirements on virtually every product with digital elements sold in the EU — connected hardware, embedded devices, and standalone software alike. It entered into force in December 2024, and its obligations are now arriving on a fixed schedule. If you ship a connected product to European customers, the CRA applies to you, and CE marking will depend on meeting it.

Does the CRA apply to your product?

The CRA covers products with digital elements: any hardware or software product whose intended use involves a direct or indirect data connection to a device or network. That includes industrial sensors, gateways, consumer IoT, machine controllers, wearables, and the firmware and companion software inside them.

The main exclusions are products already covered by sector regulation: medical devices (under the MDR and IVDR), motor vehicles under type-approval, aviation, and marine equipment. Pure SaaS is out of scope unless the remote processing is integral to the product’s function. Non-commercial open-source software is also excluded — but the moment you monetize a product built on it, you are in scope for the product you ship.

The deadlines that matter

11 September 2026 — reporting obligations begin. Actively exploited vulnerabilities and severe incidents must be reported to your national CSIRT and ENISA: early warning within 24 hours, notification within 72 hours, final report after.
11 December 2027 — full application. Products placed on the EU market from this date must meet all essential requirements, with technical documentation and CE marking to prove it.

The practical consequence: a device shipping in 2027 is being designed and built now. Compliance is a current engineering constraint, not a future legal one.

The essential requirements, translated to engineering

Annex I of the CRA reads like legal text, but it maps to a concrete engineering checklist:

Ship without known exploitable vulnerabilities. You need dependency scanning and a process to prove you checked.
Secure by default. No default passwords, minimal attack surface, services off unless needed.
SBOM. A machine-readable Software Bill of Materials (CycloneDX or SPDX) covering at least the top-level dependencies of your firmware and software.
Secure update mechanism. Signed updates, delivered securely — for most connected devices this means OTA with secure boot and a hardware root of trust.
Vulnerability handling process. A coordinated disclosure policy, a public contact point, and the ability to patch and notify within the CRA’s reporting windows.
Security updates for the support period. You must define and honor a support period that reflects the product’s expected lifetime — five years is the reference point.
Technical documentation. Risk assessment, design decisions, test evidence — the file a market surveillance authority will ask for.

Product classes and conformity

Roughly 90% of products fall in the default category and can self-assess conformity. Products with a security-relevant function — routers, password managers, firewalls, hypervisors — fall into important Class I or II with stricter assessment routes, and a small critical category (smart meter gateways, smart cards) will require certification. Classify your product early: it determines how much process you need.

Where to start

Inventory your products and classify them against the CRA categories.
Generate an SBOM for your current firmware and score the known vulnerabilities in it — this single exercise usually reveals the real gap.
Assess your update path: can you sign, deliver, and verify a firmware update in the field today?
Stand up the vulnerability intake: a security contact, a disclosure policy, and an internal route from report to patch.
Start the technical file now — retrofitting documentation after the fact costs multiples of writing it alongside development.

This guide is an engineering summary, not legal advice. For the authoritative text, see Regulation (EU) 2024/2847 in the Official Journal of the European Union.

Getting your product CRA-ready

Yunga Labs helps device makers close exactly these gaps: SBOMs, secure boot and OTA, vulnerability handling, and the technical documentation regulators require — with a background in safety-critical systems where this level of rigor is standard.

Talk to us about CRA readiness