# Embetrix - full site content > Embedded Linux and security engineering. We help product teams build and maintain secure embedded Linux devices. --- # About Embetrix is an independent embedded Linux and security engineering practice, founded and run by Ayoub Zaki, based in Germany and working with product teams worldwide. Over 20 years of experience helping teams design, build and maintain secure embedded Linux devices, from BSP and Yocto development to system security, OTA updates and product industrialization. Founder: Ayoub Zaki (Founder, embedded Linux engineer) Location: Germany, working with product teams worldwide. How Embetrix works: - Independent: A single point of accountability with no subcontracting or offshore handoff. - Upstream-first: Patches go to the mainline kernel, Yocto layers and project trees. - Built for the long term: Reproducible builds, signed updates and CVE follow-up for products that ship for years. --- # Services Source: https://embetrix.com/services Embedded Linux and product security across the full product lifecycle, from architecture to field maintenance. ## Design and security architecture For new products and platform redesigns. We define an implementable embedded Linux architecture and resolve security decisions before they become expensive to change. - Security requirements for CRA, RED Delegated Act and IEC 62443 - Threat modelling and security architecture - Yocto or Buildroot platform architecture - Hardware root of trust and secure boot-chain design - PKI, certificate and device-identity architecture - OTA update and recovery strategy ## Build and integrate We bring up hardware, develop the Linux platform and integrate security features into a reproducible build and release process. - BSP development and board bring-up - Yocto layers, distributions and Buildroot integration - Secure boot, OP-TEE, secure storage and PKCS#11 - HSM-backed image and release signing - Applied cryptography and secure key-management integration - Reproducible builds and CI/CD pipelines ## Test and release We connect builds, signing, provisioning and tests on real hardware so each release is repeatable and important failure paths are checked before deployment. - Hardware-in-the-loop and Robot Framework testing - Network, security and peripheral testing - OTA, rollback, recovery and power-loss testing - SBOM generation and vulnerability scanning - Release signing and production provisioning - Open-source licence compliance and release evidence ## Update and maintain For deployed products. We establish reliable update and recovery paths, support vulnerability handling and maintain the Yocto or BSP platform over time. - OTA update system integration - Signed, encrypted and staged fleet rollouts - Atomic rollback and field recovery - CVE monitoring, triage and patch management - Certificate lifecycle management - Long-term Yocto, BSP and product security compliance support ## Engagements - Assessment: Review an existing platform and provide written findings with recommended priorities. - Implementation: Deliver a defined technical scope with agreed deliverables and handover to the team. - Ongoing support: Support releases, security updates and long-term platform maintenance. --- # Contact Source: https://embetrix.com/contact Need help with embedded Linux or product security? Email us or book a call. Email: info@embetrix.com (typical response within one working day). Book a 30-minute online call: https://calendly.com/embetrix/30min LinkedIn: https://www.linkedin.com/in/ayoub-zaki-embetrix GitHub: https://github.com/embetrix --- # Open source Source: https://embetrix.com/open-source Yocto layers, secure-boot tools and libraries maintained by Embetrix. - meta-stm32mp15x (BitBake): OpenEmbedded/Yocto BSP layer for STM32MP15x based MPUs. https://github.com/embetrix/meta-stm32mp15x - meta-raspberrypi-secure (BitBake): meta-raspberrypi add-on Yocto layer for enhanced security and OTA update. https://github.com/embetrix/meta-raspberrypi-secure - rpifwcrypto-pkcs11 (C): PKCS#11 module that exposes the Raspberry Pi firmware OTP ECDSA key through the PKCS#11 interface. https://github.com/embetrix/rpifwcrypto-pkcs11 - stm32mp-sign-tool (C++): Utility for signing and verifying firmware images compatible with STM32MP MPUs. https://github.com/embetrix/stm32mp-sign-tool - satobox (BitBake): A privacy-focused, secure Bitcoin full-node solution designed for embedded Linux devices. https://github.com/embetrix/satobox - bmap-writer (C++): A Yocto bmap-tools alternative written in C++. https://github.com/embetrix/bmap-writer --- # Impressum Source: https://embetrix.com/impressum Diensteanbieter und verantwortlich für den Inhalt gemäß § 18 Abs. 2 MStV: Ayoub Zaki Vaihinger Straße 2/1 71634 Ludwigsburg Deutschland E-Mail: info@embetrix.com Umsatzsteuer-ID gemäß § 27a Umsatzsteuergesetz: DE313902634 Embetrix ist eine beim Deutschen Patent- und Markenamt eingetragene Marke. Registernummer: 302022233555. --- # Bringing Post-Quantum Cryptography to SWUpdate Source: https://embetrix.com/2026/09/02/swupdate-post-quantum-cryptography Published: 2026-09-02 Quantum computing is advancing and the classical cryptography securing today's products will not remain safe forever. Devices built today may still be receiving updates when classical cryptography can no longer be trusted. The transition must therefore begin before the threat becomes real. Making OTA updates post-quantum ready is a critical first step. I have been contributing practical post-quantum safety directly to the upstream [SWUpdate](https://github.com/sbabic/swupdate) and [meta-swupdate](https://github.com/sbabic/meta-swupdate) projects. To the best of my knowledge this makes [SWUpdate](https://github.com/sbabic/swupdate) the first open-source OTA framework with practical post-quantum support for update signing and TLS. The work connects the algorithms provided by [OpenSSL 3.5.x+](https://openssl-library.org/news/openssl-3.5-notes/) to the real OTA workflow: - [Set the CMS digest](https://github.com/sbabic/meta-swupdate/commit/30b8bb07bde140ed9579395037d4cfa213178857) required for ML-DSA signing. - [Add multiple CMS signers](https://github.com/sbabic/meta-swupdate/commit/41b37d191c8373ecd92f75740f98eaf6890cb1a0) to the Yocto build flow. - [Require classical and post-quantum signatures](https://github.com/sbabic/swupdate/commit/ca6a85de51166d9774429d3bb2f7cd17e39540c5) on the device. - [Control TLS key-establishment groups](https://patchwork.ozlabs.org/project/swupdate/patch/20260831154235.278721-1-ayoub.zaki@embetrix.com/) The CMS siging changes are already upstream. The TLS group option settings is the latest part of the same effort. ## Securing long lived devices for the quantum era RSA and elliptic-curve are not yet broken but nobody can give an exact timeline for a cryptographically relevant quantum computer. But waiting for classical cryptography to break would be far too late. [NIST notes that a major cryptographic migration can take 10 to 20 years](https://www.nist.gov/cybersecurity-and-privacy/what-post-quantum-cryptography). That is already as long as the lifetime of many embedded products. There is also the “harvest now decrypt later” problem when an attacker can record encrypted TLS traffic today store it and try to decrypt it when better attacks become available. The broad transition timeline looks like this: - **2024:** NIST finalized ML-KEM, ML-DSA, and SLH-DSA. - **Now to 2030:** products need testing, hybrid deployment, and migration plans. - **After 2030:** NIST’s draft plan proposes deprecating 112-bit classical public-key schemes. - **After 2035:** the same draft proposes disallowing quantum-vulnerable public-key signatures and key establishment in NIST standards. These are migration targets not predictions for when a quantum computer will arrive. The point is simple is that the transition must begin while classical systems are still secure. ## Why hybrid cryptography? Post-quantum algorithms are still new and have not yet had the decades of real-world scrutiny behind today’s classical cryptography. A hybrid design therefore keeps trusted classical algorithms in place while adding post-quantum protection. For [SWUpdate](https://github.com/sbabic/swupdate), this means: - Signing an SWU artifact with both classical (RSA or ECDSA) and ML-DSA. - Establishing TLS keys with [X25519MLKEM768](https://www.rfc-editor.org/info/rfc10024) which combines classical X25519 key establishment with ML-KEM-768. The two mechanisms protect different parts of the update process. The CMS signatures authenticate **sw-description** whose hashes bind the update payloads to the signed manifest. Hybrid TLS protects the network session used to download or upload the SWU. ## Signing an update The build or signing host must provide [OpenSSL 3.5 or newer](https://docs.openssl.org/3.5/man7/EVP_PKEY-ML-DSA/), because ML-DSA support was added in that release. Check the available version and algorithms first: ```sh openssl version openssl list -signature-algorithms | grep ML-DSA ``` For a local test, create one ECDSA P-256 and one ML-DSA-65 signer: ```sh # ECDSA private key and self-signed certificate openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 \ -out update-ecdsa.key openssl req -new -x509 -key update-ecdsa.key -sha256 -days 3650 \ -subj "/CN=SWUpdate ECDSA signer" -out update-ecdsa.crt # ML-DSA private key and self-signed certificate openssl genpkey -algorithm ML-DSA-65 -out update-mldsa.key openssl req -new -x509 -key update-mldsa.key -days 3650 \ -subj "/CN=SWUpdate ML-DSA signer" -out update-mldsa.crt ``` These commands create unencrypted private keys for demonstration. Production keys should be generated and protected by a signing service or HSM and not stored directly on the build host. The [meta-swupdate](https://github.com/sbabic/meta-swupdate) signing flow now supports multiple CMS signers. Certificates and private keys are paired by their position in the configuration: ```ini SWUPDATE_SIGNING = "CMS" SWUPDATE_CMS_CERT = "/keys/update-ecdsa.crt /keys/update-mldsa.crt" SWUPDATE_CMS_KEY = "/keys/update-ecdsa.key /keys/update-mldsa.key" SWUPDATE_CMS_MD = "sha512" ``` OpenSSL produces a single CMS structure containing two independent signatures over the same *sw-description*. In this example one comes from ECDSA and the other from ML-DSA. But there is a catch: an attacker could remove one CMS signer while leaving the other signature valid. A hybrid update could quietly become classical-only. To prevent that downgrade I added Kconfig option: [CONFIG_CMS_REQUIRE_HYBRID_PQC](https://github.com/sbabic/swupdate/commit/ca6a85de51166d9774429d3bb2f7cd17e39540c5). When enabled, SWUpdate requires at least one trusted classical signer and one trusted post-quantum signer. Remove either one and the update is rejected. Hybrid signing is therefore enforced. ## Making hybrid TLS mandatory OpenSSL 3.5.x+ supports **X25519MLKEM768**, the standardized and recommended hybrid post-quantum key-agreement group for TLS 1.3. It combines classical X25519 with ML-KEM-768. However there is no guarantee it will be negotiated. The new [tls_group](https://patchwork.ozlabs.org/project/swupdate/patch/20260831154235.278721-1-ayoub.zaki@embetrix.com/) option makes that choice explicit: ```ini tls_group = "X25519MLKEM768"; ``` If the server does not support the hybrid group the handshake fails. [SWUpdate](https://github.com/sbabic/swupdate) cannot silently fall back to a classical-only connection. During a gradual rollout, compatibility can still be kept by using for example: ```ini tls_group = "X25519MLKEM768:secp256r1"; ``` This allows older servers but it also allows classical fallback. ## Extending hybrid TLS to the Web UI The [SWUpdate](https://github.com/sbabic/swupdate) Web UI can use [Mongoose](https://github.com/cesanta/mongoose) as its embedded web-server backend. With a PQC-capable TLS backend modern Chromium-based browsers and [Firefox](https://firefox-admin-docs.mozilla.org/reference/policies/postquantumkeyagreementenabled/) can negotiate **X25519MLKEM768** automatically. ## Conclusion The goal was to make post-quantum protection usable and enforceable: create hybrid CMS signatures require both signatures and be able to select the hybrid TLS group and fail instead of quietly downgrading. This does not make the complete device quantum-safe. TLS certificates, secure boot and storage and other trust boundaries still need attention. But it gives [SWUpdate](https://github.com/sbabic/swupdate) projects a practical migration path today. OpenSSL 3.5.x+ supplies the algorithms and [SWUpdate](https://github.com/sbabic/swupdate) can now turn them into a meaningful OTA security policy. For devices expected to remain in the field through the next decade, that is a transition worth starting now. ## References - [OpenSSL 3.5.x release notes](https://openssl-library.org/news/openssl-3.5-notes/) - [NIST: What is post-quantum cryptography?](https://www.nist.gov/cybersecurity-and-privacy/what-post-quantum-cryptography) - [NIST IR 8547 draft transition timeline](https://csrc.nist.gov/pubs/ir/8547/ipd) - [RFC10024](https://www.rfc-editor.org/info/rfc10024) Embetrix helps customers plan and implement that transition, from crypto-agility assessments and hybrid OTA signing to TLS migration and validation on real embedded hardware. If your products need a practical path to post-quantum security please [get in touch](/contact). --- # Cyber Resilience Act: Are Embedded-Device Manufacturers Ready for September 2026? Source: https://embetrix.com/2026/07/21/cyber-resilience-act-reporting-september-2026 Published: 2026-07-21 Most discussions of the EU Cyber Resilience Act ([Regulation (EU) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng)) revolve around 11 December 2027, when the essential cybersecurity requirements and vulnerability-handling obligations become fully applicable. That date matters but it is not the first one. The reporting obligations under Article 14 apply from **11 September 2026**. From that day manufacturers of products with digital elements sold on the EU market must report actively exploited vulnerabilities and severe incidents to the authorities, on fixed timelines measured in hours. This applies to products already on the market, not only to new releases. If you build embedded Linux devices, industrial controllers, IoT gateways, or connected appliances, September 2026 is the deadline to plan around. *This article is technical guidance, not legal advice. For binding interpretation, consult the regulation text and qualified counsel.* ## Why September 2026 matters The CRA entered into force on 10 December 2024. Its provisions phase in: - **11 September 2026:** Article 14 reporting obligations - **11 December 2027:** the remaining obligations, including the essential requirements of Annex I and the vulnerability-handling requirements Two things make the September date operationally hard. The timelines are short: an early warning is due within 24 hours of becoming aware and weekends do not pause the clock. And you cannot report what you cannot detect: awareness depends on vulnerability monitoring, a reachable security contact and a team that knows what to do with an incoming report. Neither can be improvised. ## What must be reported and what must not Article 14 does **not** require reporting every vulnerability. Two specific event types trigger the obligation: **An actively exploited vulnerability** in your product. Under Article 3(42), this means a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner. A CVE by itself is not reportable. Evidence of exploitation in the field is the trigger. **A severe incident having an impact on the security of the product.** Under Article 14(5), an incident is severe where it negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions, or where it has led, or is capable of leading, to the introduction or execution of malicious code in the product or in the network and information systems of a user. Concrete embedded examples: - A known vulnerability in a library is being exploited on devices to extract device keys or gain remote access: an actively exploited vulnerability, reportable. - Compromise of your OTA signing infrastructure enabling malicious update delivery: severe incident, reportable. - A CVE against BusyBox with no exploitation evidence, patch scheduled for the next release: not reportable under Article 14. It falls under the vulnerability-handling obligations that apply from December 2027. This distinction is important. Article 14 is a reporting duty for specific events. The broader obligations to handle vulnerabilities, maintain an SBOM and publish a coordinated vulnerability disclosure policy sit in Article 13 and Annex I Part II, applying from December 2027. Do not confuse the two, but note that meeting the reporting duty in practice pulls much of that machinery forward. ## Who is affected The CRA applies to products with digital elements made available on the EU market: hardware and software products and their remote data processing solutions, with defined exclusions for products under sectoral regimes such as medical devices, aviation and motor vehicles. For embedded manufacturers that covers PLCs, industrial controllers, edge gateways, building automation, connected appliances and software components sold separately such as a commercial BSP or middleware stack. Critically for reporting: Article 14 obligations from September 2026 also cover products placed on the market before December 2027. Your current portfolio is in scope, not just your roadmap. ## The reporting stages and deadlines Both event types follow a staged process, submitted via the single reporting platform. **Actively exploited vulnerability:** 1. **Early warning** within 24 hours of becoming aware 2. **Vulnerability notification** within 72 hours, with general information, severity and impact and corrective or mitigating measures where available 3. **Final report** no later than 14 days after a corrective or mitigating measure is available **Severe incident:** 1. **Early warning** within 24 hours, indicating whether the incident is suspected to be caused by unlawful or malicious acts 2. **Incident notification** within 72 hours, with general information, an initial assessment and applied or ongoing mitigations 3. **Final report** within one month after the incident notification Manufacturers must also inform impacted users of the product about the event and, where necessary, about corrective measures they can deploy. The engineering consequence: your internal process must produce a defensible initial assessment within 24 hours and a technical assessment within 72. That is an incident-response drill, not a compliance document. ## The ENISA Single Reporting Platform Under Article 16, ENISA establishes and operates a Single Reporting Platform (SRP). Manufacturers report once through the SRP. The notification is addressed to the CSIRT designated as coordinator in the Member State where the manufacturer has its main establishment and is simultaneously accessible to ENISA. The receiving CSIRT disseminates the notification to CSIRTs in other Member States where the product is available, subject to narrow security-related exceptions. There is a certain irony worth savouring here. Manufacturers are expected to file structured reports within 24 hours starting 11 September 2026. The platform they must file them through was as of mid-2026 still not operational! The Commission plans for it to be ready by the same 11 September with a testing period beforehand. So the deadline discipline demanded of industry apparently comes with a more relaxed interpretation when applied to the infrastructure industry must use. Plan accordingly: assume the platform arrives at the last minute and do not assume there will be time to rehearse with it. None of this changes your homework. The internal process that produces the report is your work and does not depend on the platform. Know your coordinating CSIRT now (for a manufacturer with main establishment in Germany, that is BSI's designated national CSIRT function) and watch [ENISA's SRP page and FAQ](https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp) for onboarding details. ## Why an SBOM alone is not enough Many teams equate CRA readiness with "we generate an SBOM in CI." Modern embedded Linux build systems can emit SPDX or CycloneDX documents per image build. That is necessary groundwork, but an SBOM is an inventory, not a process. An SBOM does not: - tell you which CVEs affect the versions you ship - tell you whether a vulnerability is exploitable in your configuration (a CVE in an unused kernel module compiled out of your defconfig is noise) - detect exploitation in the field - notify your CSIRT - ship a fix to devices The 24-hour clock starts at awareness and awareness comes from monitoring and intake, not from a document in an artifact store. The SBOM is the data layer under a vulnerability-management and incident-response process, not the deliverable. ## Building the process: practical engineering steps What follows are engineering recommendations, not legal requirements. They describe how a small team can realistically operate the reporting duty. **Product and component inventory.** Maintain a machine-readable mapping from shipped firmware versions to their SBOMs. Archive the SBOM of every release build together with the image and tag both against the exact source revision of the build. Without per-release SBOMs, you cannot answer "which fielded devices contain the affected component" inside 24 hours. **Vulnerability monitoring.** Run automated CVE matching against your SBOMs, using tools that consume SPDX or CycloneDX and match against NVD, OSV and vendor advisories. Schedule this in CI on a daily basis against released builds, not only on new ones. Route findings into your issue tracker automatically. **CVE triage.** Define a written triage procedure: who assesses, against what criteria (exploitability in your configuration, exposure of the interface, CVSS as an input rather than a verdict) and what the escalation path is when exploitation evidence appears. Record triage decisions in the tracker. If an authority asks why an issue was not reported, a documented "not exploitable in our configuration, module not built" is your answer. **Coordinated vulnerability disclosure.** Publish a security contact and a `security.txt` and answer it. External researchers and downstream customers are a primary source of the "reliable evidence of exploitation" that triggers Article 14. A CVD policy is formally an Annex I Part II obligation for 2027, but the intake channel is what makes you aware in time in 2026. **Incident-response procedure.** Write a short runbook: detection sources, severity assessment against the Article 14(5) criteria, who drafts the early warning, who approves it, who submits and how users are informed. Then run a tabletop exercise against the 24/72-hour timeline with a realistic scenario, for example "customer reports devices beaconing to an unknown host after exploitation of the web UI." **Secure OTA updates.** The final report for an exploited vulnerability is due 14 days after a corrective measure is available, which presumes you can deliver one. The CRA does not mandate any particular update architecture. What matters practically is a tested, remotely deliverable update path: if your only option is "customer use an USB stick or SD card for updates" your remediation timeline is not credible. **Release traceability.** Keep an auditable chain from source revision to build to SBOM to released artifact to fleet deployment record. Without it, you cannot say within 24 hours which fielded devices are affected and the early warning becomes guesswork. ## Readiness checklist for small manufacturers - [ ] Product list mapped to fielded firmware versions and per-release SBOMs - [ ] Automated CVE matching running daily against released SBOMs - [ ] Written triage criteria and documented triage decisions - [ ] Published, monitored security contact (CVD intake) - [ ] Incident-response runbook aligned to the 24h / 72h / final-report stages - [ ] Identified coordinating CSIRT and tracking of ENISA SRP onboarding - [ ] Procedure for informing impacted users - [ ] Tested OTA update path capable of fleet-wide remediation - [ ] One simulated incident walkthrough exercise completed before September 2026 ## Conclusion September 2026 is not a paperwork deadline. It is the date by which your organisation must be able to detect a reportable event, assess it and file a structured notification within 24 hours. The legal obligation is narrow: actively exploited vulnerabilities and severe incidents only. The engineering work behind it is broad: inventories, monitoring, triage, intake, response and a working secure-update path. Teams that build this now will find that most of the December 2027 vulnerability-handling obligations are already in place as a by-product. Teams that wait for Brussels to finish its own platform before starting will be reacting under a running clock, with less patience extended to them than the EU extends to itself. ## Sources and further reading - [Regulation (EU) 2024/2847 (Cyber Resilience Act), full text on EUR-Lex](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng) - [European Commission: Cyber Resilience Act overview](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act) - [European Commission: CRA summary of the legislative text](https://digital-strategy.ec.europa.eu/en/policies/cra-summary) - [European Commission: CRA reporting obligations](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting) - [ENISA: Single Reporting Platform (SRP) and FAQ](https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp) Embetrix helps embedded-product teams establish practical vulnerability monitoring, SBOM, secure-update and incident-response processes for CRA readiness.