Under the CRA, the company that ships a product with open-source Mosquitto inside carries the obligation for the broker - not the project, not the Eclipse Foundation. Here is where that obligation lands, what it actually requires, and the patch-supply gap most teams miss.
The Cyber Resilience Act (CRA) is Regulation (EU) 2024/2847 (EUR-Lex). It sets binding cybersecurity rules for every product with digital elements placed on the EU market. If your product has open-source Mosquitto inside it, the broker is one of those digital elements - and the obligation for it sits with you, the company that ships the product. Not with the Mosquitto project, and not with the Eclipse Foundation.
That last point is where most teams are wrong, and it is the part worth getting right before the deadlines arrive.
Mosquitto and the Cyber Resilience Act: key takeaways
- The CRA (Regulation (EU) 2024/2847) applies to every product with digital elements placed on the EU market, including products from manufacturers based outside the EU.
- Two dates matter: vulnerability and incident reporting starts on 11 September 2026; full obligations including conformity assessment and CE marking apply from 11 December 2027 (Art. 71).
- Eclipse Mosquitto, published as free open source, sits outside manufacturer duties. The moment you embed it in a commercial product, you become the manufacturer and answer for the broker’s security, SBOM, updates and vulnerability handling - for that component, in the context of your product.
- The open-source project is not your supplier. It owes you nothing on your timeline. That is by design, and it is good for the ecosystem. It is also where the real gap is: your duty to ship a fix within the support period depends on a fix existing and reaching the field - and upstream moves at the community’s pace, not yours.
- Closing that gap is an engineering and process problem, not a configuration problem. Hardening the broker is the easy part. The ongoing work - monitoring, reporting on the clock, and reliable patch supply over years - is where teams come up short.
What the Cyber Resilience Act means for Mosquitto-based products
The CRA makes the company that places a product on the EU market responsible for its cybersecurity across the declared support period. A Mosquitto broker embedded in your gateway, appliance or IoT platform is a digital component of that product, so its configuration, maintenance and vulnerability handling fall under your obligations.
The scope is wide. Any product with digital elements made available in the EU is covered, and responsibility runs along the supply chain. You also owe due diligence on third-party components, including the open-source ones you integrate. The license stays free; the responsibility moves to whoever ships the commercial product. Treat the broker as part of your attack surface and document how you secure it, the same way you already handle MQTT security across your deployment.
Figure 1 - In a Mosquitto-based product, the broker is the CRA-relevant digital element between your edge devices and your IT systems.
Manufacturer or open-source steward: who carries which obligations?
This is the distinction that decides whether the CRA is your problem.
Eclipse Mosquitto, developed and shared as free open source, falls outside the manufacturer obligations of the CRA. The duties attach to commercial activity. Whether an activity is commercial is assessed against the CRA’s own criteria rather than a single monetisation test (Art. 3 and recitals 18-19), so individual contributors and non-commercial open-source projects generally stay out of scope. That protection is deliberate. It exists to keep open-source development alive without burying maintainers in regulatory duties.
A separate, lighter role - the open-source software steward - applies to a legal person that sustains an open-source project intended for commercial use (Art. 3(14) and Art. 24). This role is often held by a foundation, though a company that sustains a project can hold it too. A steward has real duties around cybersecurity policy and coordinated vulnerability disclosure, and it cooperates with authorities, but its obligations scale with its involvement and it is shielded from administrative fines (Art. 64(10)).
The CRA defines a manufacturer as anyone who develops or markets a product with digital elements under their own name or trademark, whether for payment or free of charge. The moment you sell, monetise or ship Mosquitto inside a product, you act as the manufacturer for that product (Art. 13). One organisation can be a steward for one project and a manufacturer for another - which is exactly how an open-source vendor is positioned.
| Obligation | Manufacturer (Art. 13) | Open-source software steward (Art. 24) |
|---|---|---|
| Conformity assessment and CE marking | Required | Not required |
| Technical documentation | Full | Not required (cooperate on request) |
| Machine-readable SBOM | Required | Cooperate on request |
| Vulnerability handling over support period | Required | Not applicable (no support period) |
| Coordinated vulnerability disclosure policy | Required | Required |
| Report actively exploited vulnerabilities | Required - 24h / 72h / 14 days (Art. 14) | Required, scaled to involvement |
| Administrative fines for infringement | Up to EUR 15M or 2.5% of worldwide annual turnover (Art. 64) | Exempt (Art. 64(10)) |
Read the table from the bottom up. The fine exemption is the practical line between the two roles: a steward that supports a project still has duties, but it is not exposed to the CRA’s fines. As soon as you place a commercial product on the market, you carry the full manufacturer liability for what is inside it - including the Mosquitto component.
So two common assumptions collapse here. “The CRA does not apply to me, I just use open source” is wrong the moment you ship a product. And “the Mosquitto project handles the CRA for me” is wrong because the project is a steward, not your supplier - it has no obligation to your product and no obligation to your timeline.
Figure 2 - Publishing open source and shipping a product are two different acts. The obligation for the broker moves to whoever ships the product.
What CRA-readiness actually requires
It helps to split this into the part that is easy and the part that is not.
The easy part: hardening the broker (table stakes)
Secure-by-design starts with broker configuration, and every measure maps to a concrete Mosquitto setting. Configure MQTT TLS encryption so traffic between devices and the broker is encrypted, run the broker on TLS port 8883 and switch off the plaintext listener on 1883. Encryption alone does not prove who is connecting, so add mutual TLS (mTLS) where device identity needs verification - with mTLS, devices and broker authenticate each other using client certificates. Then lock down access: disable anonymous connections, set per-client access control lists (ACLs) so each device reaches only its own topics, and manage credentials through proper authentication and authorization on Mosquitto rather than a shared password. Open-source Mosquitto provides role and group rules through its dynamic security plugin, which keeps these permissions auditable.
This is necessary, it is well documented, and you can do all of it on open-source Mosquitto today. Done properly, it is also how you meet several of the CRA’s essential requirements for the broker: secure-by-default configuration, a minimised attack surface and controlled access. It is the tractable part - a largely one-time setup you can demonstrate with a config file - but it is necessary, not sufficient. The duties that decide an audit are the ongoing ones.
The hard part: the obligations that never stop
The CRA expects a machine-readable SBOM, an active vulnerability handling process, and security updates for the declared support period - a minimum of five years, or the expected product lifetime if shorter (Art. 13(8)). For a Mosquitto-based product, that means listing the broker version and its dependencies in your SBOM (CycloneDX and SPDX are the common machine-readable formats; the CRA does not mandate one), continuously watching published CVEs for that version, and keeping a coordinated vulnerability disclosure (CVD) channel open.
From 11 September 2026, if a vulnerability in your product - including in the Mosquitto component - is actively exploited, you report it to ENISA and the relevant national CSIRT through the Single Reporting Platform: an early warning within 24 hours, a full notification within 72 hours, and a final report within 14 days of a corrective measure being available (Art. 14). Reliable Mosquitto broker logging gives you the evidence trail that reporting and audits depend on.
One detail decides whether this is manageable or not: the reporting obligation is yours. Importers, distributors and tools further down the chain only have to inform you. A scanner or a security vendor can help you detect an exploited CVE, but it cannot file the report for you, and it does not take the duty off your plate. The 24-hour clock runs against your organisation, on weekends included.
Mosquitto CRA-readiness checklist
A quick reference. The first three items are the one-time configuration; the last three are the ongoing duties that actually carry the support-period obligation.
- Enforce TLS on port 8883 and disable the plaintext listener (1883).
- Require authentication and set per-client ACLs (role and group rules via the dynamic security plugin).
- Enable access logging and retain access records.
- Generate a machine-readable SBOM for the broker and its dependencies.
- Monitor CVEs for your broker version and run a coordinated vulnerability disclosure process.
- Define and document a security update path - with a fix-time SLA - and the product’s support period.
The gap most teams miss
Look again at the support-period duty: you must ship security updates for years, and once an exploited vulnerability has a corrective measure, a 14-day clock to file your final report starts. Both of these duties assume one thing - that a fix actually exists and reaches the field.
Here is the problem with relying on the open-source project for that. The project publishes fixes on the community’s cadence - which can be days to weeks behind the moment a CVE becomes public - and it has no obligation to you, because a steward is not a supplier you can escalate to. If a version you depend on goes end-of-life upstream, the fix you need may never arrive at all. That is exactly where the compliance chain breaks: you can monitor perfectly and report on time, and still fail the support-period duty because you could not get a patch out.
This gap is structural. It is not a flaw in Mosquitto, and it is not a reason to avoid open source. It is the natural consequence of the CRA pushing accountability onto the commercial integrator while leaving the upstream project intentionally light. Recognising it is the difference between a paper plan and a process that survives an audit in 2028.
Your options to close the gap
There is no single right answer here. The honest options, each taken seriously:
- Build the capability in-house. Own the CVE monitoring for your Mosquitto version, maintain your own patch path, and staff the 24-hour reporting process. This is entirely viable. It is also real, ongoing engineering and on-call work that does not stop for the life of the product.
- Get commercial backing for the open-source broker. Keep running open-source Mosquitto, but back it with proactive vulnerability notifications, tested and signed builds on a fix-time SLA, security advisories and the component SBOM you can drop into your technical file, and a direct line to the people who maintain the broker. This closes the patch-supply gap without changing your stack.
- Move to a commercially supported edition. If you would rather not self-host and maintain the open-source broker at all, Pro Mosquitto and Management Center for Mosquitto ship the maintained update path, centralized RBAC, audit trail and certificate management as part of the product. It is the same broker your engineers already know, so there is no migration and no relearning.
What none of these change: the conformity assessment and CE marking for your finished product stay your responsibility as the manufacturer. The CRA does not let you outsource your liability. What you can outsource is the work and the risk of not having a fix in time - which, for a Mosquitto-based product, is the part that actually bites.
Deadlines and what to prepare
| Date | What applies |
|---|---|
| 10 December 2024 | The CRA entered into force |
| 11 June 2026 | Rules on notified conformity assessment bodies apply |
| 11 September 2026 | Vulnerability and incident reporting (24h early warning, 72h notification, 14-day final report) |
| 11 December 2027 | Full obligations: secure-by-design, technical documentation, SBOM, vulnerability handling, CE marking |
Penalties for breaching the essential requirements and manufacturer obligations reach EUR 15 million or 2.5 percent of worldwide annual turnover, whichever is higher (Art. 64). Most software like a message broker is expected to fall in the default category, where the manufacturer self-assesses conformity rather than going through a notified body - but you should confirm your product’s classification against the implementing rules before you rely on it.
Auditors look for evidence, not intentions. Expect questions on your technical documentation, the freshness of your SBOM, your CVD policy, and proof that updates actually reach the field. The frequent gap shows up at that last point: teams harden the broker once and never establish a patch path, which leaves the support-period duty unmet.
Map your CRA exposure with the team behind Mosquitto
If you ship a product with open-source Mosquitto inside it, the obligation for that broker is already yours - the only open question is whether you are set up to meet it before the dates do it for you.
If you are working out where your Mosquitto component sits under the CRA, talk to the team behind Mosquitto about your product and your obligations.
Mosquitto and the CRA - frequently asked questions
Is open-source Eclipse Mosquitto itself subject to the CRA?
Eclipse Mosquitto, made available as free and open-source software outside any commercial activity, sits outside the manufacturer obligations of the CRA. The duties attach to the commercial product that embeds it. If you ship Mosquitto inside something you sell or monetise, the broker becomes part of your regulated product.
Does using Mosquitto automatically make me a manufacturer under the CRA?
You become a manufacturer when you place a product with digital elements on the EU market under your own name or trademark, whether you charge for it or give it away (Art. 13). Embedding Mosquitto in that product puts the broker inside your scope. Internal use that never reaches the market is treated differently.
Can I outsource my CRA liability for the Mosquitto component?
No. The conformity assessment, CE marking and reporting obligations stay with you as the manufacturer, and the reporting clock runs against your organisation - a tool or vendor can help you detect and fix, but cannot file the report for you. What you can offload is the work and the risk: vulnerability monitoring, a reliable patch supply backed by an SLA, and the security artifacts for your technical file.
What is the difference between supported open-source Mosquitto and Pro Mosquitto?
Supported open-source Mosquitto keeps your existing open-source stack and adds the things the CRA makes hard to do alone: proactive vulnerability notifications, tested and signed builds on a fix-time SLA, security advisories and the component SBOM, and a direct line to the maintainers. Pro Mosquitto is a maintained commercial edition that also adds the operational layer - centralized RBAC, audit trail, certificate management, OAuth/LDAP/SSO, clustering for high availability and scalability, and integrations with external systems - for teams that would rather not self-host the open-source broker. Both are backed by the company behind Mosquitto.
What happens if I miss the 11 September 2026 reporting deadline?
From that date, manufacturers report actively exploited vulnerabilities and severe incidents within 24 hours as an early warning and 72 hours for a full notification (Art. 14). Missing these obligations exposes you to enforcement and fines of up to EUR 15 million or 2.5 percent of worldwide annual turnover (Art. 64). Set up the reporting process before the date, because exploited vulnerabilities rarely wait for a roadmap.
