DEV Community: Marco

Cyber Resilience Act: What Changes for Firmware and IoT

Marco — Thu, 13 Aug 2026 11:27:44 +0000

The Cyber Resilience Act will not yet come into full application on 11 September 2026. However, its first operational phase will begin: manufacturers will have to report actively exploited vulnerabilities and serious incidents that compromise the security of products with digital elements.

For a company that produces embedded devices, Linux gateways, IoT equipment or connected machines, the problem is not simply filling out a report. Before being able to communicate an event within the established deadlines, the company must know which products are involved, which firmware versions they use, which software components they contain, where they are installed and through what procedure they can be corrected.

If this information is scattered across outdated repositories, old development computers, Excel files, and technicians' personal knowledge, meeting a deadline of just a few hours becomes extremely difficult. The Cyber Resilience Act therefore highlights a principle that has often been underestimated in the embedded sector: security does not end with the delivery of the product, but must be managed throughout its life cycle.

The Regulation (EU) 2024/2847, known as the Cyber Resilience Act or CRA, does not mandate a single valid technical architecture for any device. However, it requires that hardware and software placed on the European market are designed, developed, documented, updated and maintained taking cybersecurity risks into account.

For a more specific overview of secure boot, updates and Linux systems, our in-depth analysis is also available on Secure embedded Linux, Cyber Resilience Act, secure boot and OTA. In this article we instead analyze what concretely changes from September 2026, how to prepare for full application in 2027 and why the CRA represents above all a product engineering problem.

In summary

The Cyber Resilience Act went into effect on December 10, 2024.
Reporting obligations for actively exploited vulnerabilities and serious incidents begin on September 11, 2026.
The main provisions of the Regulation will apply from 11 December 2027.
The reporting also concerns products already made available on the European market.
Firmware, bootloader, software dependencies, updates, SBOM, diagnostics and support period become parts of regulated product management.

This article is for informational and technical purposes. The legal qualification of a specific product, the choice of conformity assessment procedure and the interpretation of the Regulation must be confirmed with competent legal professionals or compliance specialists.

The CRA brings cybersecurity into the product

For many years the cybersecurity of an embedded device has been treated as an additional feature. The product was designed to perform a function and, at a later stage, it was evaluated whether to add communication encryption, a password, an upgradeable bootloader or some access control.

This approach can work when security is viewed solely as a business benefit. It becomes much more fragile when the manufacturer must demonstrate that the risks have been assessed, that the technical choices are consistent with those risks, and that there is a process to manage vulnerabilities after the sale.

The CRA then moves the planning application.

It is no longer enough to ask:

“Does the device communicate and perform its function correctly?”

It becomes necessary to ask yourself:

“How will the device react if a credential is compromised, a library has a vulnerability, an update is interrupted, or a maintenance interface is used by an unauthorized person?”

This transformation directly affects firmware, bootloaders, operating systems, connected cloud services, production tools, support procedures and technical documentation.

Compliance cannot be built at the end of the project by adding a statement to the manual. It must derive from a coherent chain:

risk analysis → security requirements → architecture → implementation → verification → release → monitoring → update → support

The dates of the Cyber Resilience Act should not be confused

One of the main sources of confusion is the presence of different deadlines. Saying generically that "the CRA comes into force in 2026" or that "everything will be mandatory in 2027" does not correctly describe the application path.

The Regulation has already entered into force on 10 December 2024. Some provisions have started to apply before full operation, while the main obligations will become applicable on 11 December 2027.

Date	What changes
December 10, 2024	Entry into force of Regulation (EU) 2024/2847.
June 11, 2026	Application of the provisions relating to the notification of conformity assessment bodies.
September 11, 2026	Application of the reporting obligations provided for in Article 14.
December 11, 2027	Full application of the main provisions of the Cyber Resilience Act.

The distinction is important because September 11, 2026 does not represent the date by which each device will already have to complete the entire CRA compliance assessment process.

From that date, however, the manufacturer must be able to manage and notify certain security events. This means that part of the organization and technical architecture must be prepared before 2027.

The European Commission maintains a page dedicated to the status of implementation of the Cyber Resilience Act, useful for following the progress of guidelines, application documents, standards and reporting infrastructures.

What must be reported from 11 September 2026

The CRA requires manufacturers to report two main categories of events: actively exploited vulnerabilities and serious incidents that impact product security.

This does not mean that any published bug, anomaly or vulnerability should automatically be reported.

An actively exploited vulnerability is one for which there is reliable evidence indicating actual, unauthorized malicious use. The mere presence of a CVE identifier or the publication of a vulnerability in a library used by the product does not demonstrate, in itself, that that vulnerability has been actively exploited in the context foreseen by the Regulation.

The manufacturer must still evaluate the problem, determine its impact and correct it when necessary. However, the reporting obligation of article 14 is triggered in the presence of the conditions established by the CRA, not for every security update available on the market.

The same principle applies to accidents. A reboot, communication failure, or temporary connection loss do not automatically become serious cybersecurity incidents. The nature, impact on safety, diffusion and consequences on the product and its users must be assessed.

The expected deadlines are particularly tight.

Phase	Indicative deadline set by the CRA
Initial alert	Within 24 hours from the moment the manufacturer becomes aware of the event.
Main notification	Within 72 hours of becoming aware of the event.
Final report for actively exploited vulnerability	No later than 14 days after the availability of a corrective or mitigation measure.
Final report for serious accident	Within one month of the primary 72 hour notification.

The initial alert does not necessarily presuppose that the entire investigation has already been concluded. It serves to quickly communicate the existence of the problem. The information can be completed during subsequent steps.

Notifications will be made through the ENISA Single Reporting Platform. The platform will forward the information to the competent CSIRT and, according to the methods established by the Regulation, to the other interested bodies.

The European Commission has published a page dedicated to Cyber Resilience Act reporting requirements, while ENISA has already made available instructions for registering representatives and sending notifications.

Reporting also concerns products already on the market

One of the most relevant points for the industrial sector is that reporting obligations do not only concern new products designed with a view to 2027.

The Commission's official summary clarifies that the reporting applies to products with digital elements made available on the European market, including those released before 11 December 2027.

Let's consider an industrial gateway marketed in 2022 and still used by hundreds of customers. If the manufacturer becomes aware of an actively exploited vulnerability affecting the security of that gateway in 2026, the original design date does not automatically eliminate the reporting requirement.

This creates an important difference between two plans.

For products placed on the market before 11 December 2027, the full application of the CRA provisions is also linked to the presence of a subsequent substantial modification. Reporting, however, follows its own transitory discipline and also affects products already distributed.

A company should therefore not interpret 2027 as a reason to postpone any activity. Even before new products comply, it must understand which existing families are still supported, which versions are in the field and who is responsible for managing a possible incident.

Which embedded and IoT products can fall under the CRA

The Cyber Resilience Act uses the definition of a product with digital elements. The definition includes software or hardware products and related remote data processing solutions, as well as separately marketed software or hardware components.

A product potentially enters the scope when it is made available on the market in the course of a commercial activity and its intended, or reasonably foreseeable, use includes a logical or physical connection, direct or indirect, with a device or network.

The connection therefore does not necessarily have to coincide with a direct connection to the Internet.

A controller can communicate with a machine via CAN, industrial Ethernet or serial. A card can be connected to a gateway. An application can depend on a remote service. A firmware can be marketed as a component to be integrated into a larger product.

Example	General evaluation
Linux gateway with Ethernet, VPN, MQTT or cloud connection	It normally presents the typical elements of a connected product to be evaluated for CRA purposes.
STM32 or ESP32 device with Wi-Fi, BLE or Ethernet	Potentially included, depending on commercialization, intended use and overall architecture.
Software or firmware component sold separately	It can be considered a product with digital elements.
Application accompanied by a cloud service essential for a function	The remote treatment solution can fit within the scope of the product.
System developed for internal use only and not made available on the market	It may be outside the scope of application of the CRA, without prejudice to the possible application of other regulations.
Prototype used exclusively for research, testing or demonstration	It must be evaluated based on the concrete conditions and provisions foreseen for prototypes and software that are not yet finished.

This table does not replace a product analysis. Some sectors and some categories are governed by specific European regulations, while other products may be excluded from the CRA or subject to rules coordinated with other acts.

The design point is that it is not enough to check for the presence of a Wi-Fi port. How the product is marketed, its functions, the intended connection, remote dependencies and the entity bringing it to market must be considered.

Who is the manufacturer when the firmware is developed externally

In the embedded sector it is common for a company to outsource the development of firmware, embedded Linux, applications, PCBs or cloud services to a consultant or external supplier.

The CRA considers the manufacturer to be the person who develops or produces the product, or has it developed or produced, and subsequently markets it under his own name or brand.

Let's imagine that a company produces an automatic machine and entrusts Silicon Logix with the development of the controller firmware. The machine is then sold under the brand of the client company.

In this scenario, the customer normally remains the manufacturer who places the product on the market under its own brand. Outsourcing development does not automatically transfer all of the manufacturer's regulatory obligations to the consultant.

However, this does not mean that the relationship with the external developer can remain informal.

To prepare technical documentation, manage vulnerabilities and maintain the product, the manufacturer will need information and activities from the supply chain: component versions, dependencies, build procedures, update policies, interface documentation, test results and future availability of technical support.

Development contracts will therefore have to more precisely define ownership and delivery of materials, vulnerability management, intervention times, maintenance responsibilities, updates, source accessibility and preservation of the build environment.

However, if a company develops its own software platform or device and sells it under its own brand, that company can directly assume the role of CRA manufacturer.

The 24-hour deadline requires product visibility

The real problem with reporting is not the platform used to send the report. The problem is being able to produce reliable information in a very short time.

When a vulnerability emerges in a TLS library, Linux kernel, bootloader or networking stack, the manufacturer needs to be able to attach the component to its product range.

The information chain should look like this:

vulnerability → component and version → firmware build → hardware variant → affected products → deployed devices → impact → mitigation → update

If the company does not know which version of the library was included in a certain firmware, the investigation begins with an archaeological reconstruction. If the device does not reliably expose the installed version, it becomes difficult to understand which drives are affected. If there is no inventory of products yet supported, it is unclear which customers need to be notified.

Reporting therefore makes certain capabilities necessary that were often considered only internal development tools: unique identification of releases, traceability of builds, preservation of sources, association between firmware and hardware, management of security alerts and definition of an incident manager.

In many products, diagnostics capable of distinguishing a normal malfunction from potentially anomalous behavior will also be useful. The level of telemetry must however be proportionate to the risk, privacy and characteristics of the system.

A small battery-powered sensor doesn't necessarily have to produce the same logs as a Linux gateway. Both, however, should offer the manufacturer sufficient information to identify version, status and conditions relevant to safety.

The risk assessment is not a generic document

The CRA requires the manufacturer to carry out a cybersecurity risk assessment and use the results during planning, design, development, manufacturing, delivery and maintenance.

It is not a question of attaching a generic table to the documentation with items such as "hacker risk" or "data loss".

A useful evaluation must start from the concrete product.

An industrial sensor with LoRaWAN link has a different attack surface than a Linux gateway with remote access. A controller installed in an electrical panel has different conditions than a consumer device reachable from the Internet. A system that controls an engine must consider different consequences than a simple data logger.

The analysis should relate at least four elements: the resources to be protected, the exposed interfaces, the realistic threats and the consequences of a compromise.

Planning question	Technical impact
Who can communicate with the device?	Authentication, identity, authorizations and credential management.
What data can be modified or read?	Integrity, encryption, access control and input validation.
What happens if the firmware is replaced?	Code signing, secure boot, bootloader protection and recovery.
How is a vulnerability fixed?	Upgrade, deployment, rollback, anti-downgrade and version management.
What happens if the network is unavailable?	Operational continuity, degraded mode and safe behavior.
How is an anomalous event detected?	Event logging, diagnostics, monitoring and retention.

Risk assessment must guide technical choices. Not every product will need the same secure element, the same cryptographic algorithm or the same OTA infrastructure.

What must be demonstrable is the coherence between risk, solution adopted and tests performed.

Secure by design doesn't mean adding TLS at the end

A product can use TLS and still be vulnerable.

Encrypted communication does not resolve a shared default password, unauthenticated firmware, a debug mode left accessible, an identical key on all drives, or a parser incapable of properly handling invalid data.

The cybersecurity of an embedded product derives from the entire architecture.

The boot chain, key generation and storage, device identity, user and service authentication, maintenance interface security, initial configuration, network exposure, error handling, and recovery capability must be evaluated.

Factory setup is also important. A product delivered with unnecessary services active, predictable credentials, or freely accessible diagnostic functionality transfers risk to the installer and user.

The default security principle instead requires that the product be delivered in a reasonably secure configuration, leaving the user the possibility to consciously enable any additional functions.

In the case of embedded Linux systems, security involves the bootloader, kernel, device tree, filesystem, system services, applications, privilege management, and the update process. Simply choosing a Linux distribution does not automatically make the product secure.

Secure boot and firmware signing: tools, not slogans

The CRA does not require that every device use the same secure boot implementation. In many products, however, the ability to verify the authenticity and integrity of the software before its execution represents a technical measure consistent with the risk.

Secure boot allows the device to verify that the code to boot comes from an authorized source and has not been altered.

However, the result depends on the entire chain of trust.

If the private key used to sign the firmware is stored without adequate protections, an attacker could produce seemingly valid images. If the bootloader can be replaced through an unsecured interface, the check can be bypassed. If the device accepts vulnerable older versions, a successful update can be undone through a downgrade attack.

A complete architecture can therefore include:

root of trust → verified bootloader → signed firmware → version control → key protection → recovery mode

The actual solution depends on the microcontroller, SoC, production volume, product criticality, and manufacturing process.

To learn more about this topic, the Silicon Logix pages dedicated to are available secure boot and embedded security and the comparison between bootloader for MCUs, embedded Linux and FPGAs.

Updates become part of the architecture

Managing a vulnerability also means being able to distribute a fix.

For many connected devices, a secure update mechanism therefore becomes a critical component. This doesn't mean that any card needs to be connected to a cloud service or automatically update via the Internet.

Isolated industrial equipment can use a signed local update, performed by authorized personnel. A gateway distributed across hundreds of locations may instead require remote infrastructure. A consumer device may have even different needs.

The correct question is not only:

“Can the firmware be updated?”

We need to ask ourselves:

“Can the device verify the authenticity of the update, recover from an outage, prevent the installation of unauthorized versions, and provide proof of which version was actually installed?”

A professional OTA system must consider signature, encryption when necessary, hardware compatibility, memory management, power control, progressive updates, recovery and traceability.

Rollback also needs to be carefully designed. Automatically rolling back to the previous version can restore functionality after a failed update, but should not allow you to reinstall a release containing a known vulnerability.

For this technical rollback and anti-downgrade protection must be coordinated.

Specific information is available in the article Secure OTA firmware update: architecture, signature and rollback and on the page dedicated to development of bootloaders and firmware updates.

The SBOM is the map of the software actually delivered

The Cyber Resilience Act explicitly introduces the Software Bill of Materials, normally referred to as SBOM.

The SBOM describes the software components contained in the product and must be prepared in a commonly used and machine-readable format, covering at least the higher level dependencies required by the Regulation.

It should not be interpreted as a sheet compiled once and stored without connection to the development process.

An effective SBOM must correspond to a precise release.

A microcontroller's firmware may contain manufacturer HALs, RTOS, TCP/IP stack, TLS library, filesystem, bootloader, and proprietary components. In an embedded Linux system, package versions, kernel, bootloader, applications and distribution customizations must also be considered.

The useful relationship is therefore:

product → hardware variant → firmware release → reproducible build → SBOM → known vulnerabilities

If a library is updated, the new build must generate or update its own BOM. If there are different hardware variants, it must be clear which software is compatible with each variant.

The Regulation does not generally require that each SBOM be freely published online. The SBOM is part of the vulnerability management process and the documentation that must be available according to the conditions established by the CRA. Any publication obligations may depend on the product category or specific applicable procedures.

The true value of the SBOM is not administrative. When a vulnerability is published, it allows the manufacturer to quickly understand whether the affected component is present in their products.

Without this correlation, each vulnerability requires reopening the project, rebuilding the build environment, and manually analyzing the code.

The support period changes the economic model of the product

The manufacturer must establish a support period during which vulnerabilities will be effectively managed. The final date, including month and year, must be clearly communicated to the buyer.

The Regulation normally provides for a period of at least five years. When the product is intended to be used for less than five years, the support may correspond to the expected life of use.

However, five years should not automatically be read as the maximum duration.

A consumer gateway and a controller installed on an industrial machine can have very different usage expectations. When determining the period, the nature of the product, reasonably expected duration, dependencies and availability of updates must be considered.

For industrial equipment this point can have a significant impact. Many machines remain operational for ten or fifteen years, while the firmware is often considered finished a few months after delivery.

Maintaining a product means maintaining sufficient sources, documentation, keys, build environment, programming tools and skills to produce a new release.

It also means predicting the cost of monitoring vulnerabilities, testing, remediation and deploying updates.

The support period therefore becomes a technical and commercial characteristic of the product. It must be considered in pricing, maintenance contracts, component selection and resource planning.

Legacy firmware is the hardest problem

Companies starting a new project today can integrate security, upgradeability and traceability from the early stages.

The situation is more complex when the product uses firmware developed many years earlier.

A legacy project may depend on a no longer supported version of the compiler, on libraries without precise information, on a microcontroller nearing the end of its commercial life, or on sources that no longer produce the same binary.

In other cases the company only owns the executable file used in production, while the original developer is no longer available.

It is not always necessary to immediately rewrite the entire product. The decision must derive from a technical evaluation.

Stable, well-documented firmware can be brought under control by introducing versioning, component inventory, and an upgrade path. A project without sources, with shared credentials and exposed interfaces may require a more thorough review.

The economic question is not just how much it costs to change the firmware.

The cost of the intervention must be compared with the risk of maintaining a product on the market that cannot be analysed, updated or supported in a sustainable way.

Existing products and substantial modification

For products placed on the market before 11 December 2027, the Regulation provides for transitional regulations linked to the substantial modification.

Not every fix or update automatically becomes a breaking change.

The assessment must consider whether the change affects the conformity of the product with the essential requirements or changes its intended purpose. The addition of a new remote interface, a major transformation of functions, the replacement of the authentication architecture or the introduction of a cloud service may require a more in-depth evaluation.

Even the person who substantially modifies a product and makes it available again can assume obligations similar to those of the manufacturer.

This is why software change management must become more structured.

A release should not be described only as a “new version”. It should be accompanied by an evaluation of the change, updating the documentation and verifying the effect on the safety requirements and compliance procedure.

The European Commission has dedicated an important part of guidelines published on 27 July 2026 right to the scope, material changes, support periods, reporting and risk assessment.

The guidelines are an important interpretative tool, but they do not replace the text of the Regulation and are not binding.

Conformity assessment will not always require an external body

Another common misconception is that any connected device must be certified by a third-party laboratory.

The CRA distinguishes between products belonging to the predefined category and important or critical products, identified based on their main function.

For many products in the predefined category it will be possible to use an internal control procedure, i.e. a self-assessment by the manufacturer accompanied by the necessary documentation and tests.

Category	General assessment setup
Products from the default category	In general, the manufacturer's internal control is permitted.
Class I important products	Self-assessment is possible under certain conditions, for example by fully applying harmonized standards or equivalent tools provided; otherwise a notified body may be necessary.
Class II important products	A third party assessment or applicable European scheme is normally required.
Critical products	A more rigorous procedure is foreseen, normally based on the participation of a notified body or on applicable European schemes.

The classification should not be inferred from the economic value of the product or from the fact that it is used in a factory. It depends on the main function and the categories defined in the CRA annexes.

The Commission has further clarified the technical descriptions through the Implementing Regulation (EU) 2025/2392.

Incorrect classification can lead to two opposite results: applying an excessively burdensome procedure to a common product or discovering too late that the product requires external evaluation.

For this reason, the framework must be carried out in the initial stages, relating the legal analysis, commercial description and technical function of the product.

Harmonized standards will help, but waiting for them is not a strategy

Technical standards will play an important role because they can transform the general CRA requirements into applicable specifications and offer a presumption of conformity for the covered requirements.

The Commission adopted standardization request M/606, which includes 41 horizontal and product category-specific standards.

The horizontal standards will address common topics such as vulnerability management, secure development and documentation. Vertical standards will be more oriented towards the characteristics of specific product families.

At the time of writing this article, in August 2026, the standardization process is still ongoing. This doesn't mean companies should put projects on hold until every document is published.

Product inventory, version control, risk assessment, dependency tracking, signed updates, and vulnerability management take time regardless of the final standard.

A fragile architecture does not automatically become compliant by applying a checklist a few months before the deadline.

The Commission page dedicated to standardization for the Cyber Resilience Act allows you to follow the evolution of European documents and activities.

Open source does not transfer product responsibility

Linux, FreeRTOS, Zephyr, U-Boot, OpenSSL, Mbed TLS, lwIP, and numerous other open source components are used in commercial products.

The CRA recognizes the value of open source and provides specific treatment for non-commercialized free software and open-source software stewards.

An individual developer who contributes to an open source project does not automatically become responsible for the commercial products into which the code is integrated.

However, when a manufacturer inserts an open source component into its product, it remains responsible for evaluating the impact of that component on the safety of the final product.

Writing “the library is open source” in the documentation is no substitute for due diligence.

The manufacturer needs to know which version they use, how to receive alerts, what configurations are enabled, and how to distribute a fix.

Dependence can also be indirect. An application may depend on a package that itself incorporates other components. A Linux distribution can contain hundreds of packages, not all of which are necessarily used or exposed in the same way.

Reducing the number of unnecessary components decreases the attack surface and makes maintenance more sustainable.

The Commission has published a specific page on the application of the Cyber Resilience Act to open source software.

A realistic case: controller and gateway for an industrial machine

Let's consider an industrial machine composed of an STM32 controller, an operator panel and a Linux gateway connected to the company network.

The controller manages sensors and actuators. The gateway collects data, exposes a web interface and communicates via MQTT with a remote assistance service.

The product works properly and has been sold for several years. The controller firmware can be updated via a service port, while the gateway uses a custom Linux distribution.

However, the company discovers that there is no complete correlation between serial numbers, gateway version and controller version. Some machines were updated in the field without recording the intervention. The version of the TLS library depends on the installed image, and the microcontroller bootloader does not verify the firmware signature.

As long as a problem does not emerge, this situation may appear manageable.

However, suppose that a vulnerability relating to a version of the library present on some gateways is published and actively exploited.

The manufacturer should quickly determine which images contain the library, which machines use those images, whether the configuration is vulnerable, and what mitigation can be applied.

If the investigation requires manually contacting each installer or connecting to machines individually, reporting deadlines become difficult to meet.

A more sustainable technical path could introduce unique release identification, SBOM associated with the build, installation inventory, signed update, version diagnostics and a documented procedure for receiving and evaluating reports.

The new chain would become:

source code → controlled build → SBOM → signed image → tracked installation → monitoring → vulnerability → update → verify

The value of this architecture is not just in compliance. The company also reduces assistance times, better understands its installed fleet and limits the risk of non-reproducible interventions.

A realistic path from August 2026 to December 2027

The CRA cannot be addressed with a single intervention performed a few days before the deadline.

It is more effective to divide the work into phases, distinguishing immediate preparation for reporting from the compliance of products that will be placed on the market after full implementation.

Operational period	Technical objective
Before September 11, 2026	Identify managers and contacts, understand the ENISA procedure, define the reception of reports and map at least the products still supported.
End 2026	Classify product families, analyze architecture and dependencies, rebuild versions and start risk assessment.
First part of 2027	Implement priority interventions: secure upgrade, authentication, key management, SBOM, logging, interface security, and controlled builds.
Second part of 2027	Complete tests, technical documentation, instructions, support period and applicable conformity assessment procedure.
By 11 December 2027	Have the necessary process in place to place products on the market that comply with fully applicable provisions.

This is a possible technical roadmap, not a set of intermediate regulatory deadlines.

The actual order depends on the number of products, firmware status, source availability, CRA category and the company's business cycle.

A manufacturer with only one recent device can quickly complete the analysis. A company with twenty years of variants, different developers and products still in support must start from a broader mapping.

A CRA technical assessment should not just produce a checklist

A useful pre-test should not be limited to answering “present” or “absent” to a series of checks.

The first outcome should be understanding the product: functions, interfaces, variants, software, components, manufacturing process and how to upgrade.

From this basis it is possible to build a technical risk assessment and identify gaps that have a real impact.

An assessment can highlight, for example, that the product already has encrypted communications but uses the same credential on all units. Or it may detect that the update is signed, but there is no recovery mode in case of interruption.

The final result should link each problem to a priority and a possible intervention.

product and versions → attack surface → dependencies → technical gaps → risk → interventions → tests → documentation

For a legacy device, the first goal may be to make the build playable again. For a new project, this may include defining secure boot, key provisioning, and updating right from the start.

The assessment also allows us to distinguish necessary interventions from those that would be technically interesting but not proportionate to the risk.

This avoids turning the CRA into an oversized and expensive project.

How Silicon Logix can support businesses

Silicon Logix intervenes at the point where Cyber Resilience Act requirements become real issues of firmware, embedded Linux, bootloaders, connectivity and product maintenance.

The activity can start with a technical evaluation of the existing architecture, checking exposed surfaces, update process, software dependencies, release traceability, key protection and the possibility of identifying the installed version.

In the case of legacy firmware, the analysis may include recovery and organization of the sources, reconstruction of the build environment, identification of libraries and definition of a realistic maintenance path.

For new products, Silicon Logix can support the design of embedded firmware, bootloader, signed updates, diagnostics, credential management and recovery mechanisms.

In more complex systems the platform can also be analyzed Embedded Linux based on Yocto or Buildroot, including packages, services, configuration, updates and generation of information necessary for the SBOM.

The goal is not to apply every available technology without distinction.

The project must identify measures proportionate to the product and build technical evidence that can be reused in the manufacturer's documentation and in the subsequent conformity assessment procedure.

Silicon Logix does not replace the legal advisor, notified body or professional responsible for regulatory compliance. However, it can support the company in the engineering part: firmware analysis, architecture definition, implementation of interventions and preparation of the necessary technical information.

Cyber Resilience Act FAQ for Firmware and IoT
Does the CRA apply to any embedded device?

No. Marketing, intended use, direct or indirect connections, product function and any applicable sector regulations must be evaluated. Many connected devices are potentially within the scope, but the presence of a microcontroller is not enough to establish this.

Will all products have to be compliant from 11 September 2026?

No. From 11 September 2026 the reporting obligations of article 14 will apply. The main provisions of the Regulation will become applicable from 11 December 2027.

Should any vulnerabilities in the firmware be reported?

No. The reporting requirement concerns actively exploited vulnerabilities and serious incidents that impact product security. Other vulnerabilities must still be assessed and managed during the support period.

Does the reporting also cover devices sold before 2027?

Yes. The Commission's official indications clarify that the reporting obligations also concern products already made available on the European market before 11 December 2027.

Is secure boot always mandatory?

The Regulation defines security requirements and objectives to be achieved, not a single architecture for each product. Secure boot and firmware signing can be appropriate measures when you need to protect the authenticity and integrity of the software you run.

Does the CRA make an OTA update via cloud mandatory?

Not necessarily. The product must be able to effectively manage vulnerabilities and security updates according to applicable conditions. The solution can be remote, local or based on assistance tools, as long as it is consistent with the risk and the expected life cycle.

Does the SBOM need to be published on the manufacturer's website?

Not in general. It must be prepared and managed according to the requirements of the CRA and applicable documentation. Posting may depend on the product category or specific conditions, but is not a universal requirement for any product.

Does using Linux or open source libraries exempt the manufacturer from liability?

No. The CRA protects normal open source contributors and distinguishes non-commercial activities. The manufacturer that integrates open source components into a commercial product must still evaluate them, document them and manage their vulnerabilities.

Does entrusting the firmware to a consultant transfer CRA obligations?

Normally not. The person who markets the product under his own name or brand generally remains the manufacturer. However, the supplier's technical and contractual responsibilities must be precisely defined.

Is the support period always exactly five years?

No. The Regulation normally establishes a minimum period of five years, except for products whose expected life is shorter. The determination must consider the nature and expected usage time of the product.

Is a notified body always necessary?

No. Many products in the default category will be able to use the manufacturer's internal control. For important and critical products, different procedures and, in certain cases, a third-party evaluation may be required.

Is a microbusiness completely exempt from the CRA?

No. The Regulation provides for proportionality, support tools and some specific provisions for micro and small businesses, but does not introduce a general exemption from the obligations applicable to the product.

Can Silicon Logix issue a CRA certification?

Silicon Logix can support the technical evaluation, design and adaptation of firmware and embedded architectures. The formal conformity procedure, the possible intervention of a notified body and the legal interpretation must be managed by the competent parties.

Conclusion

The Cyber Resilience Act must not be read only as a new European requirement.

For the embedded sector it introduces a deeper change: the software becomes a part of the product that must be known, maintained and supported even after sale.

From September 2026, the manufacturer must be able to react quickly when it becomes aware of an actively exploited vulnerability or a serious incident. From December 2027 it will also have to demonstrate that new products have been designed, developed and maintained according to the applicable requirements.

This requires much more than encrypted communication.

You need identifiable versions, known dependencies, controlled builds, reliable updates, defined responsibilities, diagnostics and a sustainable support period.

The question is no longer just:

“Does the firmware work?”

The question becomes:

“Do we know what's in it, can we fix it, can we demonstrate how it was developed, and will we still be able to support it in a few years?”

Companies that start the journey starting from architecture will be able to transform the CRA into a concrete improvement in product quality.

Those who leave everything to the final documentation will instead risk discovering that the necessary information cannot be reconstructed without modifying firmware, tools and processes.

Official references

European Union, Regulation (EU) 2024/2847 – Cyber Resilience Act, official text of the Regulation.
European Commission, Cyber Resilience Act, official overview, purposes and application deadlines.
European Commission, The Cyber Resilience Act – Summary of the legislative text, summary of scope, obligations, reporting and conformity assessment.
European Commission, Cyber Resilience Act – Reporting obligations, deadlines and how notifications work.
ENISA, CRA Single Reporting Platform, platform and operational indications for reporting.
European Commission, Guidance on the application of the Cyber Resilience Act, guidelines published on 27 July 2026.
European Commission, Cyber Resilience Act – Conformity assessment, product categories and evaluation procedures.
European Commission, Cyber Resilience Act – Standardisation, harmonized standards and request M/606.
European Commission, Cyber Resilience Act – Open source, application of the CRA to free software and open-source software stewards.
European Union, Implementing Regulation (EU) 2025/2392, technical descriptions of important and critical product categories.
ENISA, SME Cyber Resilience Maturity Assessment Model, a maturity assessment model dedicated to micro, small and medium-sized enterprises.

Is your product's firmware Cyber Resilience Act ready?

Silicon Logix can perform a preliminary technical assessment of firmware, bootloaders, embedded Linux, updates, software dependencies and diagnostics, identifying key gaps with respect to secure lifecycle management.

The activity can start from an existing product or a new project and produce a map of the architecture, versions, components used and priority interventions.

When necessary, the path can continue with secure boot, firmware signing, secure updates, recovery, SBOM, logging and revision of communication interfaces.

Request a technical evaluation of your product

Originally published on Silicon LogiX.

Galileo OSNMA and HAS: Europe's GNSS for embedded systems

Marco — Fri, 07 Aug 2026 11:41:21 +0000

Galileo OSNMA and Galileo HAS are changing how an embedded system can use satellite navigation. The job is no longer limited to calculating coordinates: a compatible receiver can verify the authenticity of Galileo navigation messages, use high-accuracy corrections, and contribute to a more resilient PNT architecture for drones, robots, vehicles, industrial systems and distributed infrastructure.

When people casually say “GPS”, they often mean a multi-constellation GNSS receiver. GPS is the United States system, while Galileo is the European Union's Global Navigation Satellite System. Modern receivers normally combine these and other global or regional constellations to improve availability and solution quality.

Galileo gives Europe its own infrastructure for Positioning, Navigation and Timing (PNT). Its value is not just the existence of a European constellation: services such as OSNMA and HAS add authentication and high-accuracy functions that can be designed into real embedded products.

For an introduction to constellations, NMEA messages, electronic modules and positioning techniques, see our guide to GPS and GNSS in embedded systems. This article focuses on Galileo OSNMA, Galileo HAS, development boards, Linux, SDR and the design of resilient PNT systems.

Key points

Galileo is the European Union's GNSS and provides positioning, navigation and timing services.
OSNMA lets a compatible receiver verify the authenticity of Galileo navigation messages.
OSNMA does not prevent jamming and does not automatically authenticate the entire position solution.
Galileo HAS distributes free global PPP corrections by satellite and over the Internet, targeting decimetre-level performance.
Development boards, Linux platforms, IMUs and SDRs make it possible to validate a PNT system before designing the final board.

From GPS to European PNT

Satellite navigation is often reduced to a dot on a map. GNSS systems actually provide three different resources: position, navigation and time. Position tells us where the receiver is; navigation also covers speed, heading and trajectory changes; a time reference synchronises equipment in different places. Together, these capabilities are known as PNT: Positioning, Navigation and Timing.

PNT is used by smartphones and vehicle navigation, but also by telecommunications, power networks, financial systems, agricultural machinery, drones, mobile robots, maritime transport, logistics and distributed industrial acquisition.

That dependency makes a European infrastructure strategically important. When a network, vehicle or automated system relies on position and time, GNSS is no longer an accessory: it is part of the operating architecture.

European autonomy does not mean configuring every receiver to use Galileo alone. A multi-GNSS device can combine Galileo, GPS and other constellations, increasing the number of visible satellites and improving solution geometry. Galileo's value is the availability of a complete European infrastructure on which specific European services can be built, without depending entirely on systems controlled by other states.

The problem is not only knowing where we are

A conventional GNSS receiver acquires satellite signals, decodes navigation messages and uses them to calculate position, velocity and time. In many applications the module simply returns coordinates and firmware passes them to an application, server or control system.

That design assumes the received data are trustworthy. GNSS signals can be degraded by obstructions, buildings, vegetation, reflections, electronic noise and interference from other radio sources. Jamming introduces interference that reduces or prevents reception; spoofing uses false or manipulated signals to make the receiver calculate the wrong position or time reference.

The consequences depend on the application. A mapping error may only be inconvenient; the same error on a drone, robot, synchronisation system or autonomous vehicle can change the behaviour of the whole system. The engineering question becomes: the device knows its position, but how can it assess whether the information it is using is trustworthy?

Galileo OSNMA: authenticating the navigation message

Galileo Open Service Navigation Message Authentication (OSNMA) is a free feature of the Galileo Open Service.

The initial OSNMA service was declared operational on 24 July 2025. In July 2026, one year after activation, EUSPA documented its progressive integration into professional receivers for timing, transport, maritime applications and connected devices.

OSNMA enables a compatible receiver to verify that a received navigation message genuinely comes from the Galileo system and has not been modified. Authentication information is carried in dedicated fields of the Galileo I/NAV message on the E1-B component. The receiver must extract that data, run the prescribed cryptographic functions and verify the authentication chain.

The protocol is based on TESLA (Timed Efficient Stream Loss-Tolerant Authentication). It uses authentication codes and delayed disclosure of the keys needed to verify them. The receiver stores messages and their cryptographic tags; when the relevant key becomes available, it can authenticate the previously received data. This deliberate delay explains why a position solution and authenticated navigation data are not necessarily available at the same instant.

What Galileo OSNMA changes in firmware

Adding OSNMA is not simply a matter of reading an extra flag from a GNSS module. A compatible receiver must extract OSNMA information from the Galileo message, perform the relevant cryptographic operations, start with sufficiently reliable Galileo System Time knowledge and preserve the integrity of the verification material.

Initial material includes items such as the Merkle-tree root and certified public keys. The product lifecycle must also allow that material to be updated or renewed through the service mechanisms. The requirement crosses several parts of the product:

GNSS receiver → key management → time reference → firmware → diagnostics → application logic

Firmware should distinguish several operating states. A position can be available while authentication is still in progress. In other cases the receiver can report failed authentication, incomplete information or inadequate radio quality.

Possible states in an embedded system using Galileo OSNMA

State	Meaning	Possible behaviour
No PVT solution	The receiver does not yet have enough information to calculate position, velocity and time.	Wait, use other sensors or enter a degraded mode.
PVT available, authentication in progress	A position is available, but Galileo data have not reached the required authentication state.	Use it for non-critical functions or wait for verification.
Authenticated navigation data	The receiver has verified the Galileo data covered by the service.	Use according to the product's normal operating policy.
Authentication failed	Verification did not complete or an inconsistent condition was detected.	Log the event, raise an alarm, exclude the affected data or switch to a safe mode.
Degraded or interfered GNSS	Radio quality, continuity or solution consistency is insufficient.	Use sensor fusion or dead reckoning, reduce functionality or perform a controlled stop.

The right response is driven by application risk. A logistics tracker may continue recording position with a reduced-confidence indicator. An industrial robot, autonomous vehicle or drone may need to limit certain functions or temporarily rely on other sensors.

A professional product should therefore log more than latitude and longitude: OSNMA state, estimated accuracy, constellations in use, signal quality, interference indicators and the reason for any transition to a degraded mode are all valuable diagnostic data.

OSNMA authenticates data, not automatically the position

Precise terminology matters. OSNMA provides data authentication: it authenticates specific information in the Galileo navigation message. It does not directly authenticate every satellite-range measurement, and it does not automatically certify the complete PVT solution computed by the receiver.

It is therefore accurate to say “a solution calculated using authenticated navigation data”, not “a certainly authentic, spoofing-proof position”.

OSNMA improves the system's ability to recognise unauthenticated data and makes a credible attack more difficult, but it does not prevent jamming or eliminate every form of spoofing. EUSPA also envisages further developments, including the Galileo Signal Authentication Service, intended to add authentication at the ranging-signal level and complement OSNMA's protection.

OSNMA should therefore be treated as an important component of a resilient PNT strategy, not as an isolated solution to every GNSS anomaly.

From an authenticated receiver to resilient PNT

A resilient embedded system can combine several information layers to assess navigation consistency. A multi-constellation receiver increases the satellites that can be used; multi-band reception can reduce some errors and improve behaviour in multipath conditions; OSNMA adds authentication of Galileo messages; receiver indicators can report noise, interference or anomalous changes.

Independent sensors can be added to that picture:

GNSS → IMU → magnetometer → barometer → odometry → vision → fusion and integrity logic

Consider a drone whose GNSS position is incompatible with its acceleration, attitude and barometric altitude. No individual sensor automatically proves spoofing, but the divergence among independent sources can create an anomaly indicator. A ground robot can compare GNSS trajectory with encoders and odometry; a vehicle can use wheel data, heading, maps and inertial sensors; a static system can monitor impossible shifts in position or time.

Sensor fusion does more than improve accuracy. It can let the system keep operating during a brief GNSS outage. This temporary operation is often called dead reckoning, and its effectiveness depends on sensor quality and calibration, the duration of the GNSS loss and vehicle dynamics.

Galileo HAS: European high-accuracy positioning

Galileo adds more than authentication services. The Galileo High Accuracy Service (HAS) is free and globally available for applications requiring better performance than the normal Open Service.

HAS uses PPP (Precise Point Positioning). It distributes precise orbit, satellite-clock and bias information needed to improve the receiver's solution. Corrections can be received directly through the Galileo E6-B signal or over the Internet through Galileo Service Centre services.

EUSPA describes HAS as capable of decimetre-level performance. Generic Galileo support on a module is not enough: the receiver, firmware and complete RF chain must be compatible with the delivery method in use.

Galileo HAS and RTK are not the same technology

HAS is sometimes presented as a direct replacement for RTK, but the two approaches have different characteristics. RTK uses corrections from a local base or a reference-station network, usually via RTCM. It can achieve centimetre-level accuracy and very short convergence times, but it requires corrections to be available and a channel to distribute them.

PPP instead uses precise corrections that apply over much wider areas. It does not necessarily require a local base, but it may need more time to converge before reaching the expected accuracy.

Comparison of standalone GNSS, RTK and Galileo HAS

Technology	Corrections	Main characteristic
Standalone GNSS	No external high-accuracy corrections	Simple architecture; accuracy depends on receiver, signals and environment.
RTK	Local base or reference network, normally via RTCM	Centimetre accuracy and fast convergence when infrastructure and connectivity are available.
PPP	Precise global corrections	Does not necessarily need a local base, but has different convergence dynamics.
Galileo HAS	Free PPP corrections via E6-B or Internet	Global coverage and decimetre-level performance without a local RTK-base dependency.

The choice follows the application. A robot that must immediately follow a centimetre-accurate path may need RTK. A device in a remote area with no local correction network may benefit from global PPP. Hybrid architectures are also possible.

2026 tests show the potential of Galileo HAS

In 2026, EUSPA published results from a Galileo HAS precision-agriculture trial. In the specific conditions of that campaign, the test recorded a 95% horizontal error of about 5.9 cm and a 95% vertical error of about 12.4 cm, below the service targets of 20 cm horizontally and 40 cm vertically.

Those values must not be read as guaranteed accuracy in every environment. Buildings, vegetation, multipath, satellite geometry, antenna design, receiver quality, vehicle dynamics and convergence time can materially change performance. The key point is that a free European high-accuracy correction service is becoming usable on commercial receivers and in real applications.

Industrial timing: reading NMEA time is not enough

A GNSS receiver is not only for finding a position. Satellites distribute extremely precise time references, and a receiver can use them to discipline its local clock. Telecommunications, power networks, financial systems, data loggers, industrial gateways and distributed acquisition platforms can depend on a shared time reference.

In a professional application, reading date and time from an NMEA sentence is not enough. Important factors include the time-pulse or 1PPS output, offset from the reference time scale, jitter, local-oscillator stability and holdover behaviour during a temporary GNSS outage.

Holdover is the ability to continue supplying a local time reference when satellite reception is lost. Its uncertainty grows over time according to the oscillator and environmental conditions. Software should therefore distinguish at least:

time acquired → valid synchronisation → authenticated source → degraded GNSS → holdover

Dedicated products such as the u-blox ZED-F9T and EVK-F9T make it possible to explore multi-band GNSS, OSNMA and 1PPS through a timing-oriented kit. Timing is consequently a system problem involving receiver, antenna, oscillator, power supply, firmware, signal distribution and diagnostics.

Experimenting with Galileo on commercial development boards

It is not necessary to design a custom RF board before starting work with Galileo. Development boards allow the receiver to be evaluated, data to be logged, antennas to be compared and firmware behaviour to be developed before committing to the final PCB.

The choice must start from the test objective. An inexpensive dual-band GNSS board may be enough to study acquisition, NMEA, PPS, power consumption and microcontroller integration. That does not mean it supports OSNMA, HAS, RTK or advanced interference indicators. Likewise, seeing “Galileo” in a datasheet does not automatically imply support for all Galileo services.

Examples of platforms for a Galileo and GNSS lab

Platform	Primary use	Engineering note
ST X-NUCLEO-LIV4A1	Introduction to dual-band GNSS, NMEA, PPS and STM32 Nucleo integration.	Useful for basic GNSS development; do not assume it is an OSNMA or HAS platform.
u-blox EVK-X20P	All-band GNSS, RTK, raw measurements, OSNMA, logging and high-accuracy evaluation.	Available features depend on the module variant and installed firmware.
u-blox ZED-X20P-01B	Galileo HAS, global PPP, RTK and high-accuracy positioning.	The 01B variant, announced in 2026, explicitly adds Galileo HAS support.
Septentrio mosaic-go X5	Professional RTK, OSNMA, interference analysis and integration with robotics or autonomous systems.	Includes AIM+ tools and a web interface for monitoring reception and RF spectrum.
u-blox EVK-F9T	GNSS timing, 1PPS, synchronisation and OSNMA.	Suitable when time, rather than dynamic positioning, is the principal requirement.
SDR with GNSS-SDR	Study of acquisition, tracking, Galileo messages and OSNMA in software.	A research and lab tool, not necessarily the final product receiver.

Verify support on the exact variant

One of the most important checks is the exact hardware variant and firmware version in use. A commercial family can contain modules with different capabilities. Even where package and main product name look similar, OSNMA support, received bands, HAS, RTK, timing and security features can change.

For example, OSNMA is available on the u-blox ZED-X20P platform, while Galileo HAS support must be verified on the specific variant. The ZED-X20P-01B was introduced in 2026 specifically with HAS and global PPP.

The product name alone is not sufficient. Before purchase or integration, verify:

part number → hardware revision → firmware version → bands → Galileo services → interfaces → antenna requirement

This avoids building a proof of concept around a board that cannot expose the functions required by the application.

A practical proof-of-concept architecture

A Galileo lab can be built progressively, without starting from a custom board. A first architecture can be:

multi-band antenna → GNSS development board → Linux platform → IMU → logging and dashboard

The receiver provides position, time, solution quality, OSNMA state and other available data. The IMU makes it possible to compare acceleration and rotation with GNSS-derived motion. The Linux platform collects data, records sessions and visualises system state in real time.

A later phase can add a cellular modem, LoRa link, local storage, battery power or application-specific sensors.

Progressive phases of a Galileo proof of concept

Phase	Objective
Commercial receiver	Verify constellations, bands, position, accuracy, OSNMA and supported services.
Linux logging	Record GNSS and diagnostic data during static and dynamic tests.
Sensor fusion	Compare GNSS with IMU, odometry or other independent sensors.
High-accuracy tests	Compare standalone, RTK, PPP and Galileo HAS.
SDR analysis	Observe Galileo signals and messages with deeper access to the processing chain.
Dedicated PCB	Integrate module, antenna, power and firmware into the final hardware.

Linux as a GNSS analysis platform

An embedded Linux computer can turn a GNSS development board into a portable lab. It can acquire position, satellite state, C/N0, estimated accuracy, OSNMA state, correction information, and data from an IMU or other sensors. During a road test, drone test or industrial-vehicle test, data can be stored locally for later analysis.

A dashboard can show:

constellations → satellites → bands → signal quality → position → OSNMA state → corrections → sensors

Linux also connects several interfaces at once: USB, UART, Ethernet, CAN, cellular modems, SDRs and measurement devices. Before final hardware design, this makes it easy to change configurations, compare receivers and create diagnostic tools that can be reused during product development.

Going deeper with software-defined radio

A commercial development board performs much of the GNSS processing chain internally and mainly returns messages, observables and processed results. With a software-defined radio (SDR), signal samples can be acquired and part of the processing moved onto a computer.

The open-source GNSS-SDR project implements a software-defined GNSS receiver and supports Galileo OSNMA. It lets a team study acquisition, tracking, navigation-message decoding, observables and authentication with access normally unavailable on a commercial module.

GNSS-SDR can use OSNMA in warning mode or configure a solution that accepts only authenticated data, depending on the source and configuration. That does not mean an SDR should replace the final receiver. A productive two-layer approach is:

commercial receiver for the product → SDR for analysis, research and validation

Record signals to make tests repeatable

Recording RF samples or the raw data produced by a receiver makes it possible to reproduce the same situation repeatedly. A field session can be analysed with different software versions or used to compare algorithms and configurations without immediately repeating the route.

Repeatability matters because satellite and radio conditions continually change. A data set can include:

IQ samples → observables → Galileo messages → PVT → OSNMA state → IMU → external reference

Tests that generate or retransmit GNSS signals over radio must be performed only in controlled, shielded environments. For normal development, prefer IQ files, cable-connected simulators or systems that cannot radiate signals capable of interfering with external receivers.

A good development board cannot fix poor RF design

Strong results from an evaluation board do not guarantee the final product will perform the same way. GNSS signals at ground level are extremely weak, so the antenna and RF path are decisive.

Evaluate antenna type, supported bands, ground plane, PCB position, enclosure, metal surfaces, cabling, filters, amplification and active-antenna power. The situation becomes more complex when LTE, 5G, Wi-Fi, Bluetooth, LoRa or other transmitters share the same device.

To use Galileo HAS by satellite, for example, the RF path must also support E6-B. A compatible receiver cannot use that band correctly if the antenna, filters or amplifiers do not pass it. Noise from switching converters, displays, processors and high-speed interfaces can also degrade reception.

Moving from a development board to the PCB therefore requires fresh validation with the real electronics, enclosure and intended mounting location.

A GNSS proof of concept is measured, not judged from a dot on a map

An apparently correct position is not enough to validate a receiver or PNT architecture. A professional trial must produce comparable data under the conditions in which the product will really operate. Tests can be static and dynamic and, when relevant, should include open areas, partially obstructed areas, buildings, vegetation, metal structures, motion, vibration and the radios present on the device.

Useful metrics when validating a Galileo and GNSS system

Metric	What it evaluates
Time To First Fix	Time to obtain the first solution after cold start, warm start and restart.
Time To First Authenticated Fix	Time to obtain authenticated data required by the application policy.
PVT availability	Percentage of the test during which position, velocity and time remain available.
50% and 95% error	Actual error distribution relative to a reference position or trajectory.
OSNMA state	Availability, continuity and any authentication failures.
C/N0 and satellites used	Reception quality and differences between environment, antenna and configuration.
DOP and satellite geometry	How satellite distribution affects solution uncertainty.
RTK fix ratio	Time spent in fixed, float or standalone solution states.
Correction age	Effect of the network and channel used to distribute RTCM, PPP or other data.
HAS or PPP convergence	Time to reach and maintain the required accuracy.
Interference indicators	RF noise, jamming, antenna degradation or anomalous conditions.
1PPS offset and jitter	Synchronisation quality in timing applications.
Power consumption	Whether the GNSS configuration fits the product's power and battery budget.

The outcome should be more than a visual demonstration. A useful proof of concept produces a report that compares receivers, antennas, configurations, firmware and operating conditions, making margins and limits visible before the final board is designed.

Which applications are realistic?

Galileo OSNMA, HAS and resilient-PNT techniques can be used in many sectors, but each application needs its own architecture.

In a drone, OSNMA can contribute to the assessment of Galileo-data trustworthiness, while IMU, barometer, magnetometer and vision systems compare real motion with GNSS-derived motion. In an outdoor mobile robot, RTK or HAS can be combined with odometry, encoders and visual localisation, while application logic handles transitions between open areas and satellite-obstructed areas.

In precision agriculture, RTK and Galileo HAS can be evaluated for assisted guidance, georeferencing, task automation and reduced overlap. In an industrial tracker, position and authentication state can be associated with timestamps, events, sensors and connectivity data, with only necessary information sent through LTE, LoRaWAN or other networks.

For timing, the device can be completely static: the receiver disciplines the local clock and synchronises distributed systems. In maritime applications, multi-band GNSS, OSNMA and interference indicators can contribute to a more observable navigation chain alongside the sensors and systems already on board.

What a development-board test does not prove

A successful development-board test does not automatically prove that the final product is spoofing-proof, works through every interference event or keeps centimetre accuracy in every environment. Bench results can change when the module is placed on a PCB beside other radios, put in an enclosure, mounted near metal structures or powered by a noisy converter.

OSNMA does not replace RF design, sensor fusion, integrity monitoring or an application policy for degraded conditions. Likewise, a HAS test in open field does not guarantee the same results near buildings, trees or obstacles. A proof of concept verifies feasibility and identifies limits; final-product validation must be repeated on the real hardware and installation.

Europe's future: Galileo and the Celeste LEO-PNT constellation

European PNT development will not stop with the operational Galileo constellation. On 28 March 2026, the European Space Agency launched the first two satellites of the Celeste LEO-PNT demonstration mission. In April 2026, Celeste broadcast the first European navigation signal from low Earth orbit.

The demonstrator is planned to include eleven satellites and will study new signals, bands and services designed to work with Galileo, EGNOS and other GNSS. Galileo satellites operate in medium Earth orbit; Celeste explores a complementary layer in low Earth orbit, closer to the surface.

The objective is not to replace Galileo, but to assess whether a new constellation can improve robustness, availability and performance through a multi-layer architecture. For embedded-system designers, the lesson is clear: the PNT subsystem should be modular and should not depend rigidly on a single source.

Galileo, EGNOS, future LEO signals, IMUs, odometry, vision and terrestrial radio technologies can all contribute to systems that assess position and time using different, complementary information.

How to evaluate a Galileo proof of concept

A GNSS project should not start by choosing the module with the largest number of constellations or the best datasheet accuracy. Start by defining the real requirements:

accuracy → availability → update rate → authentication → timing → dynamics → environment → power consumption → degraded behaviour

Then select a development board compatible with the functions to validate. Test in representative conditions: antenna placement, buildings or vegetation, motion, speed, other radios, power supply and possible noise sources. For safety-oriented systems, define the response when PNT quality drops: the product may continue with other sensors, restrict some operations, raise an alarm or stop functions for which a trusted position is essential.

Only after this phase does it make sense to define the final architecture, select the module, design the RF path and integrate the receiver on the PCB.

How Silicon Logix can help

Silicon Logix develops and prototypes systems that combine embedded firmware, microcontrollers, embedded Linux, sensors, communications and hardware interfaces.

A Galileo or GNSS project can begin with commercial development boards to quickly validate feasibility before investing in final hardware design. The proof of concept can include a multi-band receiver and antenna, Galileo OSNMA, RTK or HAS, a Linux platform, IMU, data acquisition and visualisation tools.

Tests can compare different configurations and measure accuracy, continuity, acquisition time, authentication state, reception quality and system behaviour in degraded conditions. For research and characterisation, an SDR platform can complement the commercial receiver and provide deeper access to Galileo signals and messages.

The output is not only a demonstration: it can be a technical report with a recommended architecture, measured metrics, identified limits, components to integrate and a path to the final PCB. If testing confirms feasibility, the prototype can evolve into a custom board with GNSS module, antenna, power supply, firmware, diagnostics, connectivity and sensor-fusion logic.

Frequently asked questions about Galileo OSNMA and HAS

Can Galileo work without GPS?

Yes. Galileo is an autonomous global GNSS. Commercial receivers often use it together with GPS and other constellations to improve availability, satellite count and geometry.

Does OSNMA completely prevent spoofing?

No. OSNMA authenticates specific Galileo navigation-message data and helps identify unauthenticated information. It does not prevent jamming and does not directly authenticate every range measurement used to calculate position.

Does every Galileo receiver support OSNMA?

No. The receiver must implement the required OSNMA functions. Support must be checked on the exact hardware variant and firmware version being used.

Does Galileo HAS replace RTK?

No. HAS uses PPP and distributes global corrections through E6-B and the Internet. RTK uses a base station or reference network, with different infrastructure, convergence and accuracy characteristics.

Can OSNMA be tested with a development board?

Yes, provided the board includes a receiver and firmware explicitly compatible with OSNMA. Receiving the Galileo constellation alone does not guarantee service support.

Is an Internet connection required for Galileo HAS?

Not necessarily. HAS corrections can arrive over the Internet or directly from the Galileo E6-B signal. Satellite reception requires a receiver and RF path compatible with the E6 band.

Can a GNSS receiver be used only for time synchronisation?

Yes. Timing-oriented receivers can provide 1PPS outputs and time information to synchronise networks, gateways, data-acquisition systems and distributed infrastructure.

Conclusion

Galileo is much more than a European alternative to GPS. A European GNSS infrastructure makes independent position, navigation and time services possible. OSNMA adds Galileo navigation-message authentication; HAS distributes free global PPP corrections with decimetre-level performance; timing services make Galileo valuable even for systems that do not move.

Development boards, commercial receivers, Linux platforms and SDRs make those technologies accessible to companies, developers and laboratories that want to validate them before designing custom hardware. But the value does not come from simply adding a GNSS module.

A professional system integrates receiver, antenna, firmware, diagnostics, sensor fusion and a clear policy for degraded conditions. The question is no longer only “Which GPS module can we add to the product?” It is “How can we build a system that knows where it is, how accurate that position is, and how far it can trust the information it uses?”

That is the level at which Galileo OSNMA, HAS, Linux, SDR and embedded firmware become components of a new generation of European PNT systems.

Technical references

[1] European GNSS Service Centre, Galileo Open Service Navigation Message Authentication – OSNMA: official service description, architecture and receiver requirements.

[2] European Union Agency for the Space Programme, Celebrating one year of Galileo OSNMA: a milestone for trusted positioning, 27 July 2026.

[3] European Union Agency for the Space Programme, Galileo to be the first GNSS to offer authentication service worldwide with launch of OSNMA, July 2025.

[4] European GNSS Service Centre, Galileo Services: operational and developing services.

[5] European Union Agency for the Space Programme, Galileo High Accuracy Service: description of the global PPP service.

[6] European GNSS Service Centre, Galileo High Accuracy Service – HAS: corrections, E6-B distribution and Internet access.

[7] European Union Agency for the Space Programme, Galileo HAS ready to increase efficiency of farming tasks: results of the 2026 test campaign.

[8] u-blox, ZED-X20P all-band high-precision GNSS module.

[9] u-blox, EVK-X20P evaluation kit.

[10] u-blox, ZED-X20P-01B with Galileo HAS and global PPP, 28 April 2026.

[11] u-blox, ZED-F9T high-accuracy timing module.

[12] Septentrio, mosaic-go X5 evaluation kit.

[13] STMicroelectronics, X-NUCLEO-LIV4A1: dual-band GNSS development board for STM32 Nucleo.

[14] GNSS-SDR, Introducing GNSS Navigation Message Authentication: Galileo OSNMA in a software-defined receiver.

[15] European Space Agency, Celeste LEO-PNT: European demonstrator for a complementary low-Earth-orbit navigation layer.

[16] European Space Agency, Celeste broadcasts first navigation signal from low Earth orbit, April 2026.

Would you like to integrate Galileo, OSNMA or GNSS features into your firmware?

Silicon Logix can support proofs of concept and embedded applications based on GNSS receivers and commercial development boards, focusing on the integration of module, firmware and software.

The project can include GNSS-data acquisition and management, receiver-message integration, OSNMA-state monitoring, logging, diagnostics, handling of fix-loss conditions, and Linux tools to visualise and analyse collected information.

An initial phase can use commercial hardware to validate the software architecture and define product requirements more confidently before any dedicated hardware development.

Let's discuss your GNSS project

Canonical source: Galileo OSNMA and HAS: Europe's GNSS for embedded systems.

Thermoelectric Energy Harvesting for Batteryless IoT Sensors

Marco — Mon, 27 Jul 2026 15:02:59 +0000

Industrial motors continuously reject energy as heat. Under the right conditions, a small part of that heat can power the sensor used to monitor the motor itself. This does not mean unlimited energy or zero engineering effort. It means designing an embedded node that measures, processes and transmits only when the available energy can support a complete operating cycle.

The idea is appealing in industrial IoT monitoring, where wiring every sensor may be expensive and replacing batteries across dozens or hundreds of nodes becomes an operational burden. The benefit is greatest on hard-to-reach assets, sealed enclosures and machinery that cannot be stopped frequently.

This article reviews a 2026 Sensors study in which a thermoelectric generator was installed on a 0.25 kW industrial gearmotor. The harvested energy powered a microcontroller and a LoRa transceiver. In the complete test, the system completed 41 wireless transmissions without an electrochemical battery while maintaining a positive energy balance.

Key findings

The TEG operated at a stabilized temperature difference of about 4.8-5.2 °C.
During the end-to-end test, the node harvested 6.17 J and consumed 6.05 J in 9,612 seconds.
The result demonstrates a duty-cycled LoRa node, not a maintenance-free sensor for every industrial motor.

The challenge is not producing voltage, but closing the energy budget

Energy harvesting can recover small amounts of energy from light, vibration, electromagnetic fields or temperature differences. The presence of an energy source, however, does not automatically make a sensor autonomous.

A practical design must account for conversion losses, regulator quiescent current, storage leakage, microcontroller sleep current, sensor acquisition and the short but demanding peaks caused by radio transmission. A few continuous microamps can be enough to break the budget when the harvested power is measured in microwatts or milliwatts.

The useful question is therefore not simply “how much voltage does the generator produce?” but “how much energy remains after every loss, and how often can the node safely acquire and transmit?”

How a thermoelectric generator works

A thermoelectric generator, usually abbreviated to TEG, uses the Seebeck effect. A voltage appears across the module when its two faces are at different temperatures.

As a first approximation, the open-circuit voltage rises with the temperature difference actually present across the module:

V_OC ≈ α × ΔT

Here V_OC is open-circuit voltage, α is the module’s effective Seebeck coefficient and ΔT is the real temperature difference between the hot and cold sides.

The key parameter is not the motor’s absolute temperature. It is the gradient applied directly to the TEG. If both faces approach the same temperature, electrical output falls even when the machine housing is hot.

Mechanical contact, surface flatness, interface material, heat-sink design, airflow and parasitic thermal paths all determine how much of the available heat can become useful electrical energy. At low ΔT, even a small loss at an interface can decide whether the design is viable.

The 0.25 kW industrial motor test

The prototype described in the paper was installed on a 0.25 kW Bosch Rexroth gearmotor used in a Smart Factory demonstrator at VSB-Technical University of Ostrava. Before installation, the researchers used thermal imaging to map the housing. Surface temperature ranged roughly from 35 to 60 °C, but the distribution was not uniform.

The selected TEG was a Marlow RC12-8-01LS, measuring 40 by 44.7 mm and 3.51 mm thick. Because the TEG is flat and the motor housing is curved, the team machined a custom aluminium adapter. A heat sink was mounted on the cold side, and a small duct directed part of the motor fan airflow through the fins.

Thermal paste was used between the interfaces to reduce microscopic voids and contact resistance.

Thermal chain in the prototype

Element	Role in the thermal budget
Motor housing	Heat source; surface temperature alone does not define the available electrical power.
Aluminium adapter	Matches the curved housing to the flat TEG and improves mechanical contact.
Marlow RC12-8-01LS TEG	Converts the temperature difference between its faces into electrical voltage.
Heat sink and fan airflow	Remove heat from the cold side and preserve a useful ΔT.

Why cooling the cold side matters

A TEG does not generate useful energy merely because it is heated. A thermal path must also remove heat from the cold side. In this prototype, the motor fan served two roles: cooling the motor as intended and forcing air through the additional heat sink.

That arrangement stabilized the TEG temperature difference between approximately 4.8 and 5.2 °C during steady operation. Including the warm-up and other transients, the average gradient over the full experiment was lower.

This is why “five degrees are enough” is the wrong takeaway. The product must create and preserve those five degrees across the TEG itself, including unfavourable conditions such as a hot ambient, reduced motor load, a dirty heat sink, changing airflow and ageing thermal interfaces.

From tens of millivolts to a usable supply

The TEG voltage was in the tens-of-millivolts range, far too low to directly power a microcontroller or radio. The study therefore used a power chain designed for extremely low-voltage sources:

TEG → LTC3109 → storage capacitor → TPS62840 → KL25Z4 microcontroller and SX1261 LoRa transceiver

Power path and node load

Stage	Component	Purpose
Harvesting source	TEG	Provides millivolt-level voltage from the thermal gradient.
Start-up and harvesting	LTC3109	Steps up very low input voltage and manages storage charging.
Storage	20 mF capacitor	Accumulates energy slowly to cover acquisition and radio peaks.
Regulation	TPS62840	Provides a regulated supply with very low quiescent current.
Processing and radio	KL25Z4 + SX1261	Acquire, process and transmit the LoRa payload when sufficient energy is available.

The first stage was an Analog Devices LTC3109, an ultralow-voltage step-up converter and power manager. Its documentation specifies cold start from roughly 30 mV under appropriate transformer, source-impedance and operating conditions.

Harvested energy was stored in a 20 mF capacitor. Downstream, a Texas Instruments TPS62840 buck converter was used, with a specified typical quiescent current of 60 nA. Control was handled by an NXP KL25Z4 Cortex-M0+ microcontroller, while the radio was a Semtech SX1261 LoRa transceiver.

What “batteryless” really means

In this experiment, batteryless means that the node uses no primary or rechargeable electrochemical battery. It does not mean the node has no energy storage at all.

The capacitor collects the TEG’s small output over time and releases it during short, high-current events. A radio transmission requires more instantaneous power than the generator can deliver directly at every moment.

For a real product, choosing between a capacitor, supercapacitor or hybrid store requires evaluating capacitance, leakage, temperature behaviour, peak current, life, cycling and cold-start time.

Firmware schedules work around available energy

An always-powered device can sample and transmit on a fixed timer. With harvested energy, that approach can cause brownouts when supply falls. The experimental firmware continuously monitored capacitor voltage and transmitted only after it exceeded 2 V. After a successful transmission, the node slept for 20 seconds while the TEG replenished part of the used energy.

Message timing was therefore not a fixed timer setting. It emerged from thermal power, conversion efficiency and the energy cost of the cycle. This is an energy-aware duty-cycling approach: available energy becomes a firmware state variable that controls sampling, processing and radio activity.

A production implementation should also include threshold hysteresis, brownout detection, a watchdog, safe restart behaviour, atomic writes to non-volatile memory, controlled peripheral shutdown and adaptive acquisition intervals. These are core firmware design concerns, not optional refinements.

LoRa configuration used in the test

Radio configuration in the experiment

Parameter	Setting
Band	EU868
Modulation	LoRa
Spreading factor	SF12
Bandwidth	125 kHz
Preamble	8 symbols
Payload	32 bytes

SF12 increases time on air relative to lower spreading factors, making this a comparatively demanding radio configuration. It is not automatically the best setting for every installation. A product design must consider distance, obstacles, antenna, link budget, regional constraints, retransmissions and the energy cost of the whole message.

Measured electrical output from the TEG

During resistive-load characterization, TEG output rose as the motor warmed. The reported maximum voltage was 89.6 mV, the average voltage 64.2 mV, maximum power 5.07 mW and average power 3.16 mW.

TEG electrical power measured with a resistive load

ΔT across the TEG	Measured power
0.5 °C	6.26 µW
1 °C	69.25 µW
2 °C	193.82 µW
3 °C	1.26 mW
4 °C	2.80 mW
5 °C	4.72 mW

The jump from 3 to 5 °C was not marginal: measured power rose from about 1.26 to 4.72 mW. Positioning, heat-sink design, contact pressure and interface material can therefore change the viable reporting interval dramatically.

The complete microcontroller and LoRa test

The most relevant result is the complete-node test, not the TEG characterization alone.

Measured end-to-end energy balance

Metric	Value
Harvested energy	6.17 J
Consumed energy	6.05 J
Energy margin	0.12 J
Completed LoRa transmissions	41

P_harv,avg = 6.17 J ÷ 9,612 s ≈ 0.64 mW

During the stable part of the test, many intervals between transmissions were roughly 170 to 220 seconds, with a median near 200 seconds. Dividing the full test time by all 41 messages, including start-up and transients, gives an average interval of about 234 seconds or 3.9 minutes.

All scheduled uplinks in that measurement window were received. The authors note that the evaluation was at packet level, not a dedicated RF bit-error-rate measurement. It is a positive result for that duration and those conditions, not a general reliability guarantee.

Why TEG power and system power are different

The TEG’s 3.16 mW average from resistive-load characterization and the approximately 0.64 mW average inferred from the complete node’s harvested energy are not directly comparable measurements.

The former is a generator characterization under a matched resistive load. The latter includes DC/DC conversion, storage, leakage, quiescent current, the microcontroller, radio bursts, start-up and changing thermal conditions. Dividing one value by the other would not produce a valid end-to-end efficiency. That requires synchronized measurements at defined points in the power path.

The 72-hour thermal test

The researchers also ran a 72.23-hour test with a 1 F capacitor to study thermal stability and storage over time. After the initial transient, the median gradient was 4.918 °C, with an interquartile range of 0.043 °C. Median TEG voltage was about 120.2 mV.

The capacitor reached 5.161 V, corresponding to roughly 13.319 J of stored energy.

E_C = 1/2 × C × (V_high² − V_low²)

With C = 1 F and V_low close to zero, the equation gives about 13.32 J. It is useful when estimating the energy actually available between two voltage thresholds.

The 72-hour test shows good thermal and electrical stability, but it is not a 72-hour end-to-end LoRa validation. Complete packet-success logs were not available for that data set. The authors project roughly 1,110 possible transmissions from the shorter test interval; that is an analytical projection, not 1,110 directly verified uplinks.

Measured performance versus estimated performance

The paper also estimates the reporting interval available at different gradients:

Transmission interval estimated by the authors

ΔT across the TEG	Estimated interval	Data type
0.5 °C	1,976 minutes	Estimate
1 °C	179 minutes	Estimate
2 °C	64 minutes	Estimate
3 °C	10 minutes	Estimate
4 °C	4.4 minutes	Estimate
4.5 °C	3.3 minutes	Estimate
5 °C	2.6 minutes	Estimate

Those values are not complete system tests at every temperature. They are extrapolations based on measured power and an experimentally verified operating point. They are useful for first-pass sizing, but not guaranteed field performance.

What this experiment proves, and what it does not

The work demonstrates that about 5 °C across a correctly installed TEG can power a small, duty-cycled embedded node; that a suitable power-management chain can turn tens of millivolts into a useful supply; and that energy-aware firmware can adapt reporting to actual available energy.

It does not make the prototype a production-ready industrial product. The complete node was verified for only a few hours, on one motor type, in relatively stable conditions. The study did not validate multi-year TEG and capacitor life, thermal-paste ageing, vibration resistance, repeated thermal cycling or a mechanical interface suitable for many motor geometries.

The 0.12 J margin is enough to demonstrate feasibility in the reported conditions, but a product needs allowance for ambient variation, motor load changes, restarts, radio retries, worst-case tolerances, additional sensors, leakage and ageing.

Predictive maintenance is a possible use case, not a validated outcome

The study presents predictive maintenance as a potential application, but its experimental validation concerns node power and wireless communication. It does not demonstrate a classifier for damaged bearings, fault detection or remaining-useful-life prediction.

A dependable condition-monitoring system also needs the right sensor, a suitable acquisition strategy, useful local features, data from normal and faulty conditions, and validation against false positives and false negatives. Energy harvesting can power the measurement platform; it does not replace the work of turning measurements into a trustworthy diagnosis.

Realistic applications

With average available power in the hundreds-of-microwatts range, this architecture fits short active periods followed by long sleep periods. Plausible applications include periodic temperature measurement, run-hour counting, sporadic event detection, aggregate statistics, low-rate alarms and monitoring hard-to-wire machinery.

For vibration monitoring, a practical approach is to wake an accelerometer periodically, capture a short window, calculate features such as RMS, peak, crest factor or selected spectral-band energy, and transmit only those features. Edge processing reduces radio energy by avoiding continuous waveform transfer.

Continuous high-frequency acquisition, frequent raw-waveform transmission, always-on Linux processing, video or large payloads are not realistic with the demonstrated budget.

How to evaluate a proof of concept on a real machine

Map the thermal source. Measure housing and ambient temperature, ΔT directly across the TEG, warm-up time, different loads, start-stop behaviour and seasonal variation.
Build the complete energy model. Include converter cold start and efficiency, storage leakage, regulator and MCU sleep current, sensor energy, radio energy, timeouts and retries.
Engineer the mechanical and thermal interface. Validate contact pressure, curvature, interface material, heat sink, vibration, contaminants, cable protection and maintainability.
Design for intermittent energy. Handle brownouts, watchdog recovery, threshold hysteresis, atomic non-volatile state, controlled peripheral shutdown and adaptive operation.
Validate over time. A proof of concept proves a direction. A product needs representative duration, temperature, vibration and environmental tests.

P_harv,avg > (E_cycle ÷ T_cycle) + P_sleep

This equation does not replace measurement. It makes the design constraint explicit: average harvested power must exceed the mean cost of operating cycles plus continuous sleep consumption.

Conclusion

The Sensors study is valuable because it integrates the TEG, power management, storage, microcontroller, firmware and LoRa communication, then measures a positive energy balance. It shows that waste heat from a small motor can sustain a duty-cycled wireless node when the whole system is designed around a very small power budget.

It does not mean that any hot motor can automatically power a maintenance-free sensor. Feasibility depends on the real gradient, mounting, heat rejection, machine operating profile, load consumption and long-term stability. Thermoelectric energy harvesting does not remove power-design work; it makes thermal, mechanical, electronics and firmware engineering more tightly coupled.

Technical references

[1] K. Bancik, J. Konecny, M. Stankus, R. Hercik, J. Koziorek, V. Markevičius, D. Andriukaitis and M. Prauzek, Batteryless IoT Sensing Using Thermoelectric Energy Harvesting from Industrial Motor Waste Heat, Sensors, 26(5), 1644, 2026. DOI: 10.3390/s26051644.

[2] Analog Devices, LTC3109: Auto-Polarity, Ultralow Voltage Step-Up Converter and Power Manager.

[3] Texas Instruments, TPS62840: 1.8-V to 6.5-V, 750-mA, 60-nA IQ Step-Down Converter.

[4] M. Prauzek, Batteryless IoT Sensing Using Thermoelectric Energy Harvesting from Industrial Motor Waste Heat, measurement data set and processing scripts, Zenodo. DOI: 10.5281/zenodo.17670801.

Considering a batteryless wireless sensor for an industrial asset?

Silicon LogiX can assess the available energy, build the power budget and develop the proof of concept: TEG integration, power management, low-power firmware, sensors, LoRa or BLE connectivity, gateway and operational dashboard.

Discuss an energy-harvesting proof of concept

Canonical source: Thermoelectric Energy Harvesting for Batteryless IoT Sensors.

AI for industrial alarms: turning SCADA events into useful diagnoses

Marco — Tue, 14 Jul 2026 07:35:03 +0000

A high-temperature SCADA alarm on a motor is not yet a diagnosis. A technician must determine whether it is a temporary spike or an emerging trend, check for unusual vibration or current draw, reconstruct recent maintenance work, and find the correct procedure for that specific machine. In many companies, the data already exists, but it is scattered across SCADA systems, PLCs, IoT gateways, PDF manuals, and maintenance records. The problem is not a lack of information. It is a lack of operational context.

This is where AI for industrial alarms can become a practical tool. It should not replace the maintenance technician or autonomously control the machine. Its role is to collect relevant data, connect it to technical documentation, and return a first diagnosis that people can verify. The goal is to reduce the time between an alarm and a useful decision while making interventions, work orders, and procedures more consistent.

The starting point for this article is an NVIDIA technical article on AI agents for industrial alarm management, published on July 7, 2026. The proposed architecture receives an alarm together with its sensor data, retrieves history and procedures, runs targeted checks, and returns a structured evidence package containing an observation, a root-cause hypothesis, a remedy, and a recommended action. It is not a universal, ready-made solution for every factory, but it highlights a concrete direction: alarms can become an entry point into the operational data a company already owns.

An alarm is not a diagnosis

In a real plant, an error code or a threshold violation is only the beginning. Before deciding whether an intervention is actually required, staff must check whether the same event has occurred before, whether the value is unusual for the current production cycle, whether other sensors confirm the issue, and which procedure applies to that exact machine revision.

When answering these questions means opening several dashboards, searching through PDF documents, reviewing old tickets, and relying on the memory of the people who know the plant, even a simple alarm can become time-consuming. The risk is not limited to downtime. Teams may make decisions from incomplete information, while repeated events gradually become background noise.

An AI-based support system can help during triage. It can collect the event, inspect the available context, and prepare a useful technical brief. Instead of merely displaying “high temperature,” it can show how long the value has remained above the threshold, which related signals have changed, whether similar cases exist in the maintenance history, and which procedure deserves attention.

AI agents for industrial alarm triage

The idea behind an AI agent for industrial alarms is straightforward: every important event triggers a process that gathers, analyzes, and summarizes relevant information. The input is not a generic question typed into a chatbot. It is an operational payload containing an alarm code, timestamp, machine identifier, relevant sensor readings, and asset metadata.

The system can then consult different sources. SCADA alarms and PLC data help reconstruct the event sequence. Temperature, vibration, current, or pressure sensors help determine whether a real trend exists. Manuals, diagrams, and service procedures describe which checks should be performed. Maintenance records show whether the company has already solved a similar case and which intervention worked.

The output should not be vague prose. It should be a clear evidence package: what happened, which data supports the observation, which cause is plausible, which documentation was consulted, and which action should be evaluated. The technician remains in control of the decision without having to rebuild the entire context from scratch for every alarm.

A practical example: a pump with abnormal temperature

Consider a pump that raises a high-temperature alarm. A traditional dashboard may show the code, timestamp, and current value. An assisted diagnosis can surface much more useful evidence.

The system may detect that the temperature has remained above the threshold for eighteen minutes and has increased over three production cycles. It can then verify that motor current is stable while vibration on the coupling-side bearing has risen compared with the previous month's baseline. It can search earlier interventions on pumps from the same family and find cases related to misalignment or insufficient lubrication. Finally, it can retrieve the checks and reference values from the manual for the installed revision.

The resulting recommendation can be concrete: inspect the coupling and lubrication during the next available maintenance window, monitor the trend for a defined number of cycles, and open a work order if the value continues to rise. The AI should not command the pump, modify PLC parameters, or autonomously decide to stop the line. It should turn scattered data into an operational brief, supported by evidence that the technician can verify and correct.

Where the data comes from: SCADA, PLCs, gateways, and documents

A useful project does not necessarily require replacing the existing automation stack. In most cases, it starts from systems that are already in place: PLC signals acquired through Modbus, OPC UA, EtherNet/IP, or documented proprietary protocols; alarms and trends available in the SCADA system; data collected by IoT gateways or additional sensors; and manuals, service procedures, PDF reports, tickets, and maintenance history.

Normalization is the critical step. An alarm code must be linked to a machine, line, component, revision, relevant sensors, and the correct procedure. Without this foundation, AI can produce plausible but unreliable text. With an organized data model, it can accelerate the same information retrieval process that technical staff already perform every day.

This is why a serious project does not start with the AI model. It starts with the asset map, the data that is actually available, the quality of the historical records, and the operational meaning of each event. Only then does it make sense to choose between rules, statistical analysis, anomaly detection, document retrieval, or a more advanced AI agent.

Edge, cloud, or a hybrid architecture?

There is no single answer for every plant. The choice depends on data volume, required response time, available connectivity, and the type of analysis. A local gateway or industrial PC can collect, filter, and correlate field signals close to the machine. A central service can compare data across several sites, index technical documentation, and provide shared operational dashboards.

A hybrid architecture is often the most practical option. Critical data and logic remain close to the plant, while heavier analysis or document-retrieval services run centrally. A company with a few machines and limited historical data may begin with dashboards, rules, and document search. A production site with many events and enough data can later add anomaly-detection models and more structured AI services.

The architecture should follow the real process constraints, not the “AI” label. The objective is not to add technology everywhere. It is to make a decision that currently depends on time and distributed knowledge faster and more reliable.

How to start without creating an endless project

The right way to test this technology is not to build a “factory brain” on day one. Start with a narrow, measurable use case that is valuable to the people doing the work. One family of pumps, compressors, ovens, or motors with recurring alarms is an excellent starting point.

A proof of concept can focus on three to five high-priority error codes. For each event, connect process data, intervention history, and technical documentation. Maintenance technicians should then validate the system's responses. A spectacular demo is not the objective. The relevant questions are whether the suggestion is useful, whether the supporting data is correct, and whether the system reduces the time needed to reach a first intervention hypothesis.

At the end of the test, the company can measure average triage time, the percentage of events with correct technical context, false suggestions, source quality, and the cases in which the system avoided a manual search. These metrics show whether the project should be extended to other lines or whether the data, procedures, and integrations must be improved first.

What an industrial AI agent should not do

Defining boundaries is the most important part of this kind of project. A useful agent should suggest, explain, and connect information. It should not become an opaque control layer between the operator and the machine.

Control and safety logic must remain separate, deterministic, and managed by PLCs, certified systems, and company procedures. AI can support analysis and propose a sequence of checks, but approving an intervention, opening a work order, or changing parameters must remain under human control.

This distinction makes the project more credible and easier to adopt. AI is not presented as a replacement for experience, but as a tool that makes experience available when it is needed, including when the technician who knows a machine best is not present.

How Silicon LogiX can support industrial teams

Silicon LogiX develops systems that connect firmware, industrial connectivity, Linux gateways, data collection, operational dashboards, and on-device or on-premises AI. The objective is to turn alarms, logs, and technical documents into a practical tool for the people who manage machines and plants.

The work can begin with a single asset or an existing line. We evaluate protocols, available data, historical-data quality, technical procedures, and plant constraints. This analysis can lead to a proof of concept that combines PLC and gateway data collection, ticket or report integration, an operational dashboard, and clear criteria for measuring the value of the solution.

There is no need to begin with a large platform. In many cases, the first useful outcome is an assisted, readable, and traceable diagnosis that helps staff identify the likely cause of an alarm sooner and follow a more consistent procedure. If the test delivers value, the platform can evolve toward predictive maintenance, multi-site monitoring, anomaly classification, and integration with existing business processes.

Conclusion

Industrial alarms are already a valuable source of information, but they often remain isolated events inside separate systems. Connecting SCADA, sensor data, technical documentation, and maintenance history turns them into a starting point for faster diagnoses and better-documented decisions.

AI becomes valuable when it is applied to a concrete problem: reducing the time required to understand what is happening, giving technicians the right context, and making years of company knowledge easier to reuse. The first step is not purchasing a complex infrastructure. It is choosing a real use case, measuring it, and building a reliable technical foundation.

Do your alarms, logs, and technical documents work together today?

Silicon LogiX can evaluate a proof of concept on an existing asset or production line: PLC and gateway data collection, integration with historical records and documentation, an operational dashboard, and measurable criteria for determining whether AI delivers real value.

Evaluate an industrial proof of concept

Originally published at Silicon LogiX.

Secure BLE OTA Firmware Updates on nRF5340: Architecture Notes

Marco — Sun, 12 Jul 2026 18:02:33 +0000

Firmware updates are one of the places where an embedded prototype either becomes maintainable or becomes expensive to support. The hard part is not moving a binary from a laptop to a board. The hard part is making the whole path controlled, observable and recoverable when the device is in the field.

This internal R&D project explores that path on a Nordic nRF5340-DK. It uses Bluetooth Low Energy for a local maintenance connection, Zephyr and the nRF Connect SDK for the firmware base, MCUmgr SMP for management transport and MCUboot for verified boot and recovery.

Why use BLE for an OTA workflow?

Many embedded products are installed where permanent Internet access is not available, desirable or reliable. A technician may still be able to stand next to the device with a laptop or phone. BLE provides a practical local channel for commissioning, diagnostics and controlled updates without adding a cloud dependency simply for maintenance.

For that to be useful, the update flow needs more than a file picker. Before the upload, the operator should be able to identify the device and inspect its current firmware and diagnostic state. During the upload, the target should enforce its own policy. After reboot, the system must know whether the new image is actually healthy.

The update path

The browser dashboard uses Web Bluetooth to connect to the nRF5340-DK. The device exposes identity, version and diagnostic information, then accepts an approved firmware package over MCUmgr SMP carried by Bluetooth LE.

The uploaded image is written to the secondary slot. On the next reboot, MCUboot validates it and starts it as a test image. The application runs its defined startup checks and explicitly confirms the image only after it is operational. If confirmation never happens, MCUboot restores the previous known-good image on the following reboot.

That sequence creates a simple but important distinction:

an image can be transferred;
an image can be allowed to boot;
an image can be confirmed as healthy.

Treating those as separate states is what makes field recovery possible.

Signing and version policy

The prototype signs firmware images with ECDSA P-256. MCUboot verifies the signature against the public key in the boot chain before a candidate image is executed. A BLE connection alone is therefore not enough to make an arbitrary binary runnable.

The update policy also checks release metadata to prevent unsafe downgrades. The exact product rules can differ, but the principle is consistent: the target device must decide whether a package is appropriate for its hardware, software generation and operating state.

For normal operation, update access can be limited through a timed service mode. The device enables maintenance for a defined period, then closes it again automatically. This keeps the control near the target instead of relying entirely on the dashboard to behave correctly.

Dual-core nRF5340 design

The nRF5340 provides an application core and a network core. In this project, the application core owns the device logic, update policy and diagnostics, while the network core supports Bluetooth LE connectivity. The split is useful because it makes firmware responsibilities visible early, before more product-specific functions are added.

The development kit is not the final product, but it is the right place to test the interaction between flash layout, bootloader configuration, radio transfer and application startup. Those details are difficult to validate with desktop tooling alone.

What physical-hardware testing changed

The demo update sequence was verified on a real nRF5340-DK with signed releases from 1.0.11 to 1.0.14. The tests covered BLE transfer, boot behavior, version controls, image confirmation and automatic rollback.

The key lesson is that OTA is a system feature. The browser interface, BLE transport, MCUboot slots, firmware startup checks and service procedure all have to agree. A robust implementation is less about one clever component than about making the failure states explicit and recoverable.

Moving from a demo to a product

A production adaptation needs dedicated signing keys, secure key handling, a defined manufacturing process, protected debug policy and a repeatable release pipeline. It also needs an update process that fits the physical product: how technicians connect, what happens if power is interrupted and how the device is recovered in the rare case that both normal operation and the new image fail.

The case study is useful whenever a product needs local field maintenance without permanent Internet access, especially when custom electronics, firmware and the technician-facing interface need to work as one system.

Read the full case study on the Silicon LogiX Solutions Hub.

AI search and business websites: why companies should update now

Marco — Wed, 01 Jul 2026 13:00:43 +0000

AI-powered search is changing how people discover information, compare suppliers and decide which companies to contact.

For many businesses, this makes one thing very clear: having a website online is no longer enough.

The website has to be understandable, fast, structured and useful. It has to help both people and search systems understand what the company does, who it helps and why it should be trusted.

A website is no longer just a digital brochure

Many company websites were built with an old assumption: the goal was simply to be present online.

That often led to:

generic service pages
vague copy
slow mobile experience
hidden contact forms
no clear path from visit to enquiry
no useful data about what actually converts

This was already a problem in classic search. With AI-assisted search experiences, it becomes even more important. If a page is weak, unclear or generic, it is harder for users and systems to extract real value from it.

What changes with AI search

AI search does not remove SEO. It raises the bar.

A useful business website still needs:

indexable pages
clear technical structure
fast loading
mobile-readable content
dedicated service pages
internal links that explain context
useful content that answers real questions
visible calls to action
conversion tracking

There are no magic tricks here. The fundamentals simply matter more.

The real goal: from traffic to qualified contacts

Traffic is not the final metric.

For a business website, the key question is:

Does the visitor understand the offer quickly enough to take the next step?

A good website should explain:

what the company does
who the service is for
which problem it solves
what makes the company credible
what the next step is

For technical, industrial and service companies, this is especially important. Their value is often not obvious at first glance. The website has to educate, clarify and guide.

From brochure website to working platform

The best websites can grow into operational tools.

For some companies, the first step is a clearer and faster business website. For others, the website becomes:

a lead-focused landing page system
a customer portal
an internal dashboard
a document area
a ticketing system
a custom web management platform
an integration layer between customers, data and internal processes

At that point, the website is no longer only a communication channel. It becomes part of how the business works.

Practical checklist

Give every important service its own page.
Write pages around real customer questions, not generic slogans.
Make contact paths visible and measurable.
Track form submissions, CTA clicks and source pages.
Improve mobile speed and readability.
Connect related pages with useful internal links.
Keep content specific, current and trustworthy.
Treat the website as a system that evolves, not as a one-off project.

Final takeaway

AI search is not a reason to chase shortcuts. It is a reason to build better websites.

Companies that invest in clear structure, useful content, technical SEO and conversion paths will be better prepared for how users search, compare and choose suppliers in the next phase of the web.

Canonical source: AI search and business websites: why companies should update now

Silicon LogiX builds business websites, landing pages, dashboards, customer portals and custom web platforms for companies that want their website to become a real acquisition and work tool.

Firmware Black Box: diagnosing embedded resets in the field

Marco — Tue, 30 Jun 2026 09:26:29 +0000

A device that resets in the field is not always the hardest problem.

The harder problem is a device that resets, comes back online, and leaves no evidence about what happened before the reboot.

That is where a firmware black box becomes useful.

This is the DEV.to edition of a Silicon LogiX technical article. The canonical English source is linked at the end.

What a firmware black box is

A firmware black box is a small diagnostic subsystem inside the firmware. Its job is to preserve enough information to support post-mortem analysis after a reset, watchdog event, HardFault, panic or unexpected reboot.

It does not need to record everything. It needs to record the data that helps answer the first diagnostic questions:

why did the device reset?
how long had it been running?
which firmware build was installed?
what state was the application in?
which task was active?
did the watchdog fire?
did memory, stack or heap margins collapse?
did the network, modem, BLE, Wi-Fi or OTA flow fail just before the reboot?

Without that data, every field reset deletes most of the evidence.

Why sporadic resets are expensive

Rare embedded bugs are often more expensive than obvious failures.

A crash that happens every time in the same function can usually be analyzed with a debugger, logs and a repeatable test. A reset that appears once every ten days on a customer device is different.

The cause may depend on a combination of:

temperature
unstable power
brown-out
cable length
enclosure heating
network drops
modem state
memory fragmentation
stack exhaustion
long uptime
race conditions
a peripheral that stops responding
an OTA edge case

In the lab, the product may look clean. In the field, the environment changes. The customer report often becomes: "it rebooted", "it stopped communicating", or "we had to power-cycle it".

That is not enough for firmware diagnosis.

What to capture

A good first version does not need to be large. Start with a compact structure that survives the next boot:

reset reason
uptime before reset
firmware version and build ID
hardware variant
application state
last meaningful error
watchdog counters
recent application events
active RTOS task
stack high-water marks
minimum heap
OTA state
network state
fault registers or core dump when available

For FreeRTOS systems, values such as uxTaskGetStackHighWaterMark can be extremely useful when stack margins are suspected.

For Cortex-M systems, fault status registers, stack pointer information and the program counter can turn a blind HardFault into a useful post-mortem report.

For ESP32 products, ESP-IDF already provides useful mechanisms such as panic handling and core dump. The best design often combines those built-in tools with application-level event history and upload after reboot.

Watchdog is not enough

The watchdog is essential. It can recover service when firmware stops responding.

But if the watchdog resets the system and nothing is stored, the device is operational again while the root cause has disappeared.

A good watchdog restarts the device.

A good firmware black box explains why the restart was necessary.

Useful questions include:

which task failed to report health?
was the device reconnecting to the cloud?
was the modem stuck?
was heap decreasing over time?
was an OTA update in progress?
were there repeated DNS, TLS, MQTT or BLE errors?

This is the difference between recovery and diagnosis.

Logging and diagnostics are different

Many firmware projects have logs. That does not mean they are diagnosable.

UART logs are useful during development, but they often disappear in production. If nobody had a terminal connected when the customer device reset, those logs are gone.

Diagnostics should be designed for field conditions:

no debugger attached
no serial cable connected
no engineer present at the crash
limited memory
possible power loss
possible network failure
support team needs a readable report

A compact persistent ring buffer with the latest important events may be more valuable than thousands of UART lines that nobody will ever see.

Storage options

The right storage depends on the product:

retention RAM for fast data across software resets
internal flash for small critical reports
NVS or a dedicated partition on ESP32
EEPROM or FRAM for frequent diagnostic counters
local filesystem on embedded Linux gateways
cloud upload after reboot for connected devices

Do not make the cloud the only source of truth. The network may be part of the problem.

Also be careful with flash wear, power loss during writes, atomic updates and sensitive data. Diagnostic reports should not contain passwords, private keys, tokens or unnecessary personal data.

A practical checklist

Before shipping a connected embedded product, ask:

[ ] Is reset reason collected at boot?
[ ] Are watchdog, brown-out, software reset and manual reset distinguished?
[ ] Is firmware version tied to a build ID or commit?
[ ] Is hardware variant recorded?
[ ] Is there a useful HardFault or panic strategy?
[ ] Are RTOS task health and stack margins observable?
[ ] Is minimum heap recorded?
[ ] Is there a persistent event ring buffer?
[ ] Are network and OTA events included?
[ ] Can support export a report without JTAG?
[ ] Are sensitive data and credentials excluded?

Typical field scenario

Imagine an STM32 or ESP32 controller. It passes lab tests, talks to sensors, sends data to the cloud and supports OTA. The watchdog is enabled, so the team feels safe.

After release, some customers report random reboots.

Without a black box, the team guesses: maybe the modem, maybe a task stack, maybe power, maybe memory, maybe I2C, maybe Wi-Fi.

With a black box, the next episode can produce a report:

watchdog reset
uptime: 91 hours
application state: MQTT reconnect
network task stack almost exhausted
several DNS timeouts in the recent event buffer
firmware build ID identified

That is not the final fix, but it is a direction. In embedded debugging, a direction can save days or weeks.

Final takeaway

A firmware black box is not an extra feature for perfectionists. It is part of building maintainable embedded products.

A device in the field should not only recover. It should explain what happened.

When diagnostics are designed with reset reason, watchdog analysis, fault context, RTOS metrics, persistent events, OTA state and safe export, sporadic resets stop being mysterious and become measurable.

And a measurable problem is much closer to a fix.

Canonical source: Firmware Black Box: how to find out why an embedded device resets in the field

If you build embedded, IoT or firmware products and want a second pair of eyes on diagnostics, watchdog strategy, OTA behavior or field failures, Silicon LogiX can help turn hard-to-reproduce issues into measurable engineering work.

Bluetooth Channel Sounding: precise BLE ranging for embedded IoT

Marco — Tue, 09 Jun 2026 10:51:55 +0000

Most BLE proximity features start with RSSI. That is fine when the product only needs a rough "near or far" signal.

It becomes fragile when distance affects security, access control, asset tracking or industrial behavior.

Bluetooth Channel Sounding changes that by adding a standardized ranging capability to Bluetooth LE. Instead of relying only on received signal strength, two compatible devices exchange radio measurements that can be used to estimate distance more reliably.

Why RSSI is not enough

RSSI is easy to read, but it is not a stable distance sensor.

The value changes with antenna orientation, enclosure design, reflections, the user's body, walls, metallic objects, interference and multipath. Two devices at the same physical distance can report very different RSSI values.

That is acceptable for simple beacons. It is not ideal for:

Digital keys and secure access
Indoor asset tracking
Smart proximity features
Find-my devices
Industrial maintenance workflows
Distance-aware IoT products

What Channel Sounding adds

Bluetooth Channel Sounding was introduced with Bluetooth Core 6.0 and refined further in Bluetooth Core 6.3.

A procedure involves two roles:

Initiator: starts the measurement
Reflector: responds to the measurement sequence

The devices exchange signals across multiple Bluetooth LE channels. The system can then estimate distance using methods such as:

Phase-Based Ranging, based on phase changes across frequencies
Round-Trip Timing, based on signal travel time between devices

The useful part is that this is not a proprietary trick layered on top of BLE. It is part of the Bluetooth specification, which matters for interoperability and long-term product design.

Where it fits

Channel Sounding is interesting when distance becomes part of the product logic.

For example:

A smart lock should know whether the authorized phone is really close to the door.
An industrial cabinet may allow access only when the technician is physically present.
A warehouse gateway may estimate how close a tag is to an anchor.
A wearable or tracker can guide the user with more useful distance feedback.
A machine can enable local configuration only when the operator is nearby.

That is different from "I can hear a BLE device somewhere nearby". The product is now asking "how close is it, and can I trust that measurement enough to act on it?"

Architecture impact

A Channel Sounding product is not just a firmware flag. The whole embedded architecture is involved.

Area	What to verify
SoC	Real Channel Sounding support, not only generic BLE support
Bluetooth stack	Initiator, Reflector, HCI and SDK support
RF design	Antenna, layout, enclosure, ground plane and multipath behavior
Algorithm	Filtering, calibration, outlier handling and acceptance thresholds
Firmware	States, timeouts, fallback behavior and diagnostics
Security	Pairing, identity, secure boot, signed OTA and debug policy
Validation	Lab and field tests with motion, obstacles, angles and interference

This is where many projects get surprised. Ranging performance is not only about the Bluetooth version printed on a datasheet. It depends on the radio, stack, antenna, enclosure, firmware and test process working together.

Channel Sounding vs RSSI, AoA/AoD and UWB

RSSI is still useful for simple presence and low-cost beacon behavior.

AoA/AoD can be useful for localization systems that can afford antenna arrays and infrastructure.

UWB remains excellent for high-precision ranging and advanced digital-key systems, but it adds hardware, power and integration cost.

Bluetooth Channel Sounding sits in an interesting middle ground: more distance-aware than RSSI, inside the BLE ecosystem, and potentially simpler than adding a separate UWB path in products that already depend on Bluetooth.

Practical checklist

Before choosing Channel Sounding, I would check:

[ ] Does the product really need distance, or is generic proximity enough?
[ ] Have the RSSI failure modes been measured in the real environment?
[ ] Is UWB, AoA/AoD or GNSS a better fit for the accuracy target?
[ ] Does the selected SoC, controller, host stack and SDK actually support Channel Sounding?
[ ] Is the antenna strategy compatible with the enclosure and installation conditions?
[ ] How often will the product measure distance, and what is the battery impact?
[ ] What happens when the measurement is uncertain?
[ ] Are secure boot, signed OTA and debug-access policy already part of the architecture?
[ ] Can field logs explain why the device trusted or rejected a distance measurement?
[ ] Has the validation plan included multipath, movement, obstacles and edge cases?

Final takeaway

Bluetooth Channel Sounding is not simply "better RSSI".

It gives embedded teams a standardized way to make Bluetooth LE devices more distance-aware. That can unlock better secure access, asset tracking, smart proximity and industrial workflows.

But it has to be designed as a system feature: hardware, RF, stack, firmware, security, power budget and validation all matter.

When those pieces are handled early, Channel Sounding can turn Bluetooth from a connectivity feature into a useful distance and trust signal for embedded IoT products.

Canonical source: Bluetooth Channel Sounding: precise and secure distance measurement for embedded IoT

Silicon LogiX helps teams design embedded, firmware and IoT architectures when prototypes need to become maintainable products.

5G RedCap for embedded IoT: useful 5G without full 5G complexity

Marco — Wed, 27 May 2026 10:23:19 +0000

5G RedCap is becoming one of the more interesting connectivity options for embedded products that sit between classic cellular IoT and full 5G.

It is not meant to replace NB-IoT or LTE-M in tiny low-power sensors. It is also not meant to replace full 5G NR in high-throughput routers or eMBB devices.

The useful space is the middle: industrial gateways, connected cameras, mobile HMIs, richer asset trackers, smart grid equipment and edge devices that need more than LPWA but less than a full 5G modem.

What RedCap actually changes

RedCap means Reduced Capability. It was introduced in 3GPP Release 17 as a lighter 5G NR device category. The basic idea is to reduce device complexity by limiting capabilities such as maximum bandwidth, antenna configuration, carrier aggregation and processing requirements.

That matters in embedded systems because the modem is never isolated. It affects:

BOM and module availability
antenna design and enclosure constraints
peak current and sleep strategy
carrier certification
Linux integration
OTA behavior
diagnostics and field support
product security lifecycle

In other words, RedCap is not just a radio choice. It changes the system architecture.

Where it fits

RedCap can make sense when a device needs:

more bandwidth than NB-IoT or LTE-M
better alignment with 5G Standalone roadmaps
medium-size telemetry or diagnostic payloads
OTA updates that are too heavy for very low-power links
remote access, VPN or backend integration
private 5G or industrial network support
a longer product lifecycle than an LTE-only design may suggest

It is especially interesting for embedded Linux gateways, industrial routers, edge AI cameras, utility equipment and professional mobile devices.

Where it does not fit

RedCap is not automatically the best answer.

If a device sends a few bytes per day and must run for years on a small battery, NB-IoT or LTE-M may still be better.

If the product needs continuous high-bitrate video, heavy uplink or CPE-class performance, full 5G NR may be the right tool.

If the installation always has reliable local infrastructure, Wi-Fi or wired Ethernet may be simpler and cheaper.

The point is to compare technologies against the product behavior, not against the marketing label.

Embedded Linux integration checklist

For a Linux gateway, treat the RedCap modem as a critical subsystem.

redcap_linux_integration:
  modem_interface:
    qmi_or_mbim_selected: true
    modemmanager_profile_tested: true
    networkmanager_policy_defined: true
    hardware_reset_gpio_available: true
  connectivity:
    lte_fallback_tested: true
    roaming_policy_defined: true
    apn_profiles_versioned: true
    vpn_or_private_apn_evaluated: true
  operations:
    modem_firmware_update_process_defined: true
    logs_persisted_for_field_debug: true
    watchdog_recovery_flow_tested: true
    remote_diagnostics_enabled: true

The important details are usually boring and very practical:

Can the host reset the modem without a power cycle?
Are QMI, MBIM or AT flows deterministic enough for recovery?
Are network state transitions logged persistently?
Is LTE fallback validated in the target countries?
Can field support see RSSI, operator, APN, roaming and attach failures?
Is modem firmware update part of the maintenance process?

Security and OTA are part of the decision

A RedCap device is often remotely reachable, updateable and connected to cloud services. That makes secure boot, signed OTA, credential handling and vulnerability management part of the connectivity decision.

For new connected products in Europe, this also intersects with the Cyber Resilience Act lifecycle mindset: products need to be maintainable, updateable and designed with cybersecurity in mind from the beginning.

At minimum, I would verify:

signed firmware artifacts
downgrade prevention
rollback or recovery path
device identity model
TLS certificate lifecycle
hardened credential storage
debug access policy
vulnerability handling process
remote logs for update and modem failures

The modem gives the product reach. The security architecture decides whether that reach is acceptable.

Power and RF can make or break the project

RedCap reduces complexity compared with full 5G, but it should not be confused with ultra-low-power LPWA.

Measure on the real target:

attach peak current
idle current
sleep behavior
consumption during OTA
behavior with weak signal
reconnect and retry patterns
thermal behavior in enclosure
antenna performance in final mechanics

Many cellular product failures do not come from the selected standard. They come from optimistic power assumptions, weak antenna integration or recovery flows that were never tested outside the lab.

A practical adoption roadmap

flowchart TD
  A["Use-case analysis"] --> B["Compare NB-IoT, LTE-M, LTE Cat-1/4, RedCap and full 5G"]
  B --> C["Select module and target bands"]
  C --> D["PoC on real hardware"]
  D --> E["Measure power, attach, uplink, fallback and recovery"]
  E --> F["Integrate Linux, firmware, OTA and secure boot"]
  F --> G["Operator testing, certifications and field trial"]
  G --> H["Controlled rollout and lifecycle monitoring"]

The best time to evaluate RedCap is before the PCB, enclosure, antenna, power tree and update strategy are frozen.

Final takeaway

5G RedCap is not simply "slower 5G". It is a useful middle tier for connected embedded products that need more than LPWA, less than full 5G and a clearer path toward 5G-era networks.

For the right product, it can improve longevity, remote maintenance and industrial connectivity. For the wrong product, it can add unnecessary module cost, certification effort and power complexity.

So the question is not "should we use RedCap?". The better question is:

What does our device need to transmit, how long must it live in the field, how will we update it, and what network roadmap do we need to survive?

Useful references:

Canonical source: 5G RedCap for embedded IoT: benefits and roadmap for connected products.

Post-quantum cryptography for embedded and IoT: secure boot, TLS and OTA

Marco — Sat, 23 May 2026 11:43:06 +0000

Post-quantum cryptography is no longer just a research topic. It is starting to affect the way embedded teams design TLS, secure boot, OTA, firmware signing, device identity and long-term product maintenance.

NIST has finalized the first post-quantum standards. OpenSSL 3.5 now includes ML-KEM, ML-DSA and SLH-DSA support. The European roadmap points toward a coordinated transition, and embedded vendors are already moving PQC into MCU and firmware workflows.

For connected products that may stay in the field for 10, 15 or 20 years, this is not abstract security theater. It is architecture.

Why embedded teams should care

Embedded products freeze cryptographic choices earlier than many teams expect:

bootloader verification logic
firmware image and manifest formats
OTA package signatures
device certificates
production PKI
secure elements and trust anchors
TLS or VPN libraries in Linux gateways
update and rollback policies

Once the device is deployed, changing those choices becomes expensive. Sometimes it becomes almost impossible without a carefully designed migration path.

That is the real value of post-quantum planning: not replacing RSA and ECC everywhere overnight, but introducing crypto agility before the product becomes too rigid.

ML-KEM and ML-DSA in plain terms

The two names embedded teams should recognize first are:

ML-KEM: a key encapsulation mechanism for establishing shared secrets, especially relevant to TLS and similar protocols.
ML-DSA: a digital signature scheme, relevant to secure boot, firmware signing, package signing, certificates and device identity.

For Linux gateways, ML-KEM is often the first practical entry point because TLS stacks can be tested and upgraded more easily than immutable boot chains.

For firmware and boot flows, ML-DSA is very relevant but needs more careful engineering. Signature sizes, verification time, image layout and manifest formats all matter.

Where PQC enters an embedded architecture

Area	What changes	Why it matters
TLS and networking	Hybrid groups, new key establishment, library updates	Gateways and edge devices can start testing now
Secure boot	Signature verification may need post-quantum readiness	Boot chains are hard to change after deployment
OTA	Manifests, package signing and rollback policies may need new formats	Update reliability and security are part of the same trust chain
PKI	Certificates, provisioning and trust anchors need migration planning	Device identity is a long-term product dependency
Memory budget	Stack, heap, flash and latency must be measured	Papers and release notes are not a substitute for target testing

A practical adoption path

Do not turn on PQC everywhere and hope for the best. A healthier path looks like this:

Inventory every cryptographic dependency in the product.
Map TLS, VPN, secure boot, OTA, package signing, certificates and PKI.
Identify code paths that cannot be updated after manufacturing.
Run a Linux gateway pilot with OpenSSL 3.5 or lab tools such as Open Quantum Safe.
Measure ML-KEM and ML-DSA impact on real hardware.
Review image formats, manifests, rollback and recovery paths.
Define a policy for trust anchor rotation and crypto agility.
Move only the justified parts into production.

Example checklist

pqc_embedded_audit:
  lifecycle:
    expected_field_life_checked: true
    non_updatable_signature_verifier_identified: true

  protocols:
    tls_or_vpn_usage_mapped: true
    certificates_and_pki_inventory_done: true

  firmware_chain:
    secure_boot_flow_reviewed: true
    ota_manifest_and_signature_format_reviewed: true
    rollback_and_recovery_paths_verified: true

  implementation:
    hybrid_transition_need_evaluated: true
    stack_heap_flash_measured_on_real_target: true
    latency_variance_measured: true

  operations:
    trust_anchor_rotation_plan_available: true
    crypto_agility_requirements_defined: true
    release_and_support_workflow_documented: true

When PQC makes sense

PQC planning is most useful when the product is:

connected
updateable
deployed for a long time
dependent on secure boot, OTA, certificates or secure networking
expensive to access physically
subject to compliance or long support windows

That makes Linux gateways, edge appliances, industrial IoT devices and remotely maintained firmware platforms natural candidates for early evaluation.

Where to be careful

PQC is not automatically the right move for every MCU or every firmware build.

Very constrained devices may have strict limits around stack, heap, flash, latency or power. Hybrid approaches can help with migration, but they also add complexity and testing cost. The goal is not to put post-quantum algorithms everywhere. The goal is to know where they reduce real product risk.

Final takeaway

Post-quantum cryptography is becoming part of embedded product architecture. The smartest move today is not panic migration; it is inventory, measurement and crypto agility.

Teams that understand their boot chain, OTA process, PKI and field lifecycle now will have a much easier transition later.

Canonical source: Post-quantum cryptography for embedded and IoT: secure boot, TLS and OTA

Silicon LogiX helps teams review embedded Linux, secure boot, firmware signing, OTA and security architecture for connected products.

eBPF on embedded Linux: diagnostics and runtime security for edge devices

Marco — Mon, 18 May 2026 10:57:22 +0000

eBPF is no longer only a cloud-native observability topic.

For embedded Linux teams, it can become a practical way to inspect deployed gateways, routers and edge devices without rebuilding the whole firmware image every time a new diagnostic question appears.

This is the DEV.to edition of a Silicon LogiX technical article. The canonical English source is linked at the end.

Why eBPF matters for embedded Linux

Embedded Linux products are often installed in places where debugging is expensive: factories, remote sites, customer networks, vehicles, appliances or industrial cabinets.

When a problem appears only in the field, the usual workflow is painful:

add logs
rebuild the image
deploy an update
reproduce the issue
hope the new logs are the right ones

eBPF gives teams another option. In many cases, it can collect kernel-level signals at runtime with controlled overhead, without turning every diagnostic question into a new firmware release.

Useful use cases

For embedded products, eBPF is most useful when it solves a specific operational problem:

measuring syscall frequency and latency
tracing I/O or filesystem behavior
observing network traffic on gateways and routers
collecting packet statistics with XDP
monitoring sensitive runtime events
profiling CPU or service bottlenecks
supporting remote diagnostics on deployed Linux devices

It does not replace good firmware architecture, logs, metrics or security design. It adds a deeper inspection layer when application-level visibility is not enough.

Embedded constraints still matter

A cloud server and an embedded gateway are very different environments.

Before adding eBPF to a product, check the real target:

kernel version and BPF support
CPU architecture and JIT availability
enabled hooks and kernel configuration
memory and CPU overhead
privileges required to load programs
Yocto or Buildroot integration
difference between development and production images

The best embedded approach is often to build tools off-target and deploy only the loader, BPF objects and runtime pieces that the product actually needs.

Architecture sketch

A typical solution has two parts:

a small eBPF program attached to a kernel event
a user-space loader that configures the program and reads data from BPF maps

The eBPF side should stay focused: collect, filter or count events. The user-space side can export logs, metrics, local dashboard data or remote diagnostic reports.

ebpf_embedded_strategy:
  development_image:
    tracing_tools_available: true
    debug_symbols_available: true
    kernel_config_visible: true

  production_image:
    minimal_loader_included: true
    only_required_bpf_programs: true
    unprivileged_bpf_disabled: true
    attack_surface_reduced: true

  build_process:
    kernel_config_versioned: true
    bpf_objects_built_reproducibly: true
    target_architecture_validated: true
    release_artifacts_tracked: true

Evaluation checklist

Before adopting eBPF in an embedded Linux product, run a focused audit:

ebpf_embedded_audit:
  kernel:
    kernel_version_checked: true
    bpf_support_enabled: true
    required_hooks_available: true
    architecture_jit_support_verified: true

  security:
    unprivileged_bpf_policy_reviewed: true
    capabilities_required_documented: true
    production_access_restricted: true
    attack_surface_evaluated: true

  runtime:
    cpu_overhead_measured: true
    memory_usage_measured: true
    long_running_test_completed: true
    failure_behavior_verified: true

  maintenance:
    bpf_program_versioned: true
    rollback_plan_available: true
    customer_support_workflow_defined: true

Adoption plan

Start from one real problem: latency, networking, syscall monitoring, security audit or field diagnostics.
Verify kernel support, architecture constraints and permissions.
Build a small proof of concept and measure overhead on the real target.
Integrate loader and BPF objects into the embedded build system.
Separate development tooling from the production image.
Define update, rollback, logging and support workflows.

Final takeaway

eBPF is powerful for embedded Linux when it becomes part of an engineered maintenance and observability strategy.

It should not be added because it is fashionable. It should be added when it reduces diagnostic time, improves runtime visibility, strengthens network or security insight, and helps keep deployed Linux devices maintainable for years.

Canonical source: eBPF on embedded Linux: advanced diagnostics and security for edge devices

If you build embedded Linux, IoT gateways or edge devices and want a second pair of eyes on diagnostics, runtime security or Yocto integration, Silicon LogiX can help turn field problems into maintainable engineering workflows.

ESP-IDF 6.0 migration: what ESP32 teams should test before production

Marco — Tue, 12 May 2026 11:33:00 +0000

ESP-IDF 6.0 is not a routine SDK bump for ESP32 products.

If your firmware runs on devices already installed in the field, updated through OTA, connected through TLS, or used in industrial environments, the migration should be treated as an engineering project rather than a quick dependency update.

This is the DEV.to edition of a Silicon LogiX technical article. The canonical English source is linked at the end.

Why ESP-IDF 6.0 matters

ESP-IDF 6.0 changes several areas that matter in production firmware:

Picolibc replaces Newlib as the default C library
Mbed TLS 4.x moves crypto work toward PSA Crypto APIs
Deprecated legacy drivers are removed
Build workflows and presets improve
Bootloader OTA recovery exists on supported chips
Some warnings can become build-blocking errors

For a prototype, this may look like a normal migration. For a product, it can affect RAM, flash footprint, task stack margins, TLS handshakes, OTA safety, provisioning and release repeatability.

What to check before migrating

Start with five questions:

Does the current firmware build cleanly?
Do custom components use legacy ESP-IDF APIs?
Are OTA partitions, rollback and bootloader compatibility documented?
Does the product use TLS, client certificates, secure boot or flash encryption?
Can CI reproduce the exact production build?

If the answer to any of these is unclear, migrate in stages.

Picolibc checklist

Picolibc can improve footprint, but do not stop at "it compiles".

picolibc_migration_check:
  memory:
    flash_size_before_after: true
    ram_usage_before_after: true
    heap_minimum_measured: true
    task_stack_margin_checked: true

  compatibility:
    third_party_libraries_reviewed: true
    stdio_usage_checked: true
    printf_formatting_tested: true
    cplusplus_components_tested: true

  runtime:
    long_running_test_completed: true
    watchdog_events_checked: true
    logging_behavior_verified: true

PSA Crypto and TLS

If your product uses HTTPS, MQTT over TLS, client certificates, secure storage or legacy Mbed TLS APIs, test real connections after the migration.

The subtle failures are often runtime failures: TLS handshakes that fail, certificates loaded differently, secure storage assumptions that no longer hold, or larger crypto footprint that pushes flash/RAM closer to limits.

OTA and bootloader

For field-deployed devices, OTA is the most sensitive part of the migration.

ota_readiness:
  partition_table:
    ota_slots_available: true
    ota_data_partition_present: true
    factory_partition_strategy_defined: true

  firmware_validation:
    image_signature_enabled: true
    rollback_enabled: true
    version_check_enabled: true

  bootloader:
    production_bootloader_version_recorded: true
    compatibility_tested: true
    recovery_strategy_defined: true

  rollout:
    staged_update_supported: true
    device_health_reported: true
    remote_recovery_plan_available: true

Migration plan

Audit the current firmware: IDF version, drivers, custom components, partitions, OTA and security.
Make the project build on ESP-IDF 6.0 and remove or isolate legacy APIs.
Compare flash, RAM, heap minimum and task stack margins before/after.
Test Wi-Fi, provisioning, TLS, MQTT/HTTPS, Web UI, watchdog behavior and long-running stability.
Release through staged rollout, with rollback and telemetry.

Final takeaway

ESP-IDF 6.0 is a useful technical step forward, but a production firmware migration should be measurable, reversible and repeatable.

The best outcome is not simply "the project builds". The best outcome is knowing that OTA, TLS, memory, drivers and release workflow still behave correctly after the upgrade.

Canonical source: ESP-IDF 6.0 migration: how to upgrade ESP32 firmware without production regressions

If you build embedded, IoT or firmware products and want a second pair of eyes on migration risk, OTA strategy or firmware architecture, Silicon LogiX can help turn prototypes into maintainable products.

DEV Community: Marco

Cyber Resilience Act: What Changes for Firmware and IoT

In summary

The CRA brings cybersecurity into the product

The dates of the Cyber ​​Resilience Act should not be confused

What must be reported from 11 September 2026

Reporting also concerns products already on the market

Which embedded and IoT products can fall under the CRA

Who is the manufacturer when the firmware is developed externally

The 24-hour deadline requires product visibility

The risk assessment is not a generic document

Secure by design doesn't mean adding TLS at the end

Secure boot and firmware signing: tools, not slogans

Updates become part of the architecture

The SBOM is the map of the software actually delivered

The support period changes the economic model of the product

Legacy firmware is the hardest problem

Existing products and substantial modification

Conformity assessment will not always require an external body

Harmonized standards will help, but waiting for them is not a strategy

Open source does not transfer product responsibility

A realistic case: controller and gateway for an industrial machine

A realistic path from August 2026 to December 2027

A CRA technical assessment should not just produce a checklist

How Silicon Logix can support businesses

Will all products have to be compliant from 11 September 2026?

Should any vulnerabilities in the firmware be reported?

Does the reporting also cover devices sold before 2027?

Is secure boot always mandatory?

Does the CRA make an OTA update via cloud mandatory?

Does the SBOM need to be published on the manufacturer's website?

Does using Linux or open source libraries exempt the manufacturer from liability?

Does entrusting the firmware to a consultant transfer CRA obligations?

Is the support period always exactly five years?

Is a notified body always necessary?

Is a microbusiness completely exempt from the CRA?

Can Silicon Logix issue a CRA certification?

Conclusion

Official references

Is your product's firmware Cyber ​​Resilience Act ready?

Galileo OSNMA and HAS: Europe's GNSS for embedded systems

Key points

From GPS to European PNT

The problem is not only knowing where we are

Galileo OSNMA: authenticating the navigation message

What Galileo OSNMA changes in firmware

OSNMA authenticates data, not automatically the position

From an authenticated receiver to resilient PNT

Galileo HAS: European high-accuracy positioning

Galileo HAS and RTK are not the same technology

2026 tests show the potential of Galileo HAS

Industrial timing: reading NMEA time is not enough

Experimenting with Galileo on commercial development boards

Verify support on the exact variant

A practical proof-of-concept architecture

Linux as a GNSS analysis platform

Going deeper with software-defined radio

Record signals to make tests repeatable

A good development board cannot fix poor RF design

A GNSS proof of concept is measured, not judged from a dot on a map

Which applications are realistic?

What a development-board test does not prove

Europe's future: Galileo and the Celeste LEO-PNT constellation

How to evaluate a Galileo proof of concept

How Silicon Logix can help

Frequently asked questions about Galileo OSNMA and HAS

Can Galileo work without GPS?

Does OSNMA completely prevent spoofing?

Does every Galileo receiver support OSNMA?

Does Galileo HAS replace RTK?

Can OSNMA be tested with a development board?

Is an Internet connection required for Galileo HAS?

Can a GNSS receiver be used only for time synchronisation?

Conclusion

Technical references

Would you like to integrate Galileo, OSNMA or GNSS features into your firmware?

Thermoelectric Energy Harvesting for Batteryless IoT Sensors

Key findings

The challenge is not producing voltage, but closing the energy budget

How a thermoelectric generator works

The dates of the Cyber Resilience Act should not be confused

Is your product's firmware Cyber Resilience Act ready?