Shipping a wireless product? Its cybersecurity is already regulated under RED, in force now. See RED & EN 18031 Assessment. Here for a specific security question rather than compliance? See Product Security Assessment.
Two dates that matter
Vulnerability and incident reporting becomes binding for every product on the EU market, including products shipped years ago. You need to know what is in your firmware, and be able to react when a vulnerability lands in it.
Full application: essential cybersecurity requirements, technical documentation, conformity assessment and CE marking. Products that can't show the evidence don't ship.
The conformity-assessment machinery is still being stood up. Harmonised standards are pending and notified bodies are only now being designated. When formal assessment does arrive, the queue will be long. The work that pays off now is upstream, technical preparation before anyone formally assesses you.
Who this is for
Manufacturers of connected products selling into the EU or EEA, from consumer IoT to industrial equipment, and the engineering teams who have read the regulation and want to know what it means for their product, concretely, before committing to a conformity-assessment path.
On your side of the table
MKR Labs is an independent technical partner on your side of the certification process. We work closely with your engineering team to prepare the product and the evidence, so that whatever route to conformity applies to you goes smoothly. Together we figure out where to start, what a realistic path to compliance looks like, and how to solve the technical challenges along the way. When the formal assessment comes, you meet it with the work already done.
We frame the assessment around ENISA's CRA maturity model, so you and your auditors share an official vocabulary. Where a typical review reads your documents, MKR Labs tests your product. The essential requirements fall into two parts: the security the device must genuinely have, which we check on the bench, and the vulnerability and supply-chain side, which we read out of the firmware. The bench work is what a document review and a scanner both miss, and only a hands-on assessment can verify it.
- Secure boot and protected secrets
Whether the boot chain will run only signed code, and how keys and credentials are stored on the device. We follow the root of trust and read it off the hardware, because it can't be confirmed from a datasheet or a build manifest, only on the built product.
- Secure update mechanism
Whether the product can be patched safely at all, with signed and verified updates, rollback protection and an authenticated update channel. That technical ability to ship a fix the device will trust is what the CRA requires, and it has to exist before any release process around it matters.
- Secure defaults and hardening
The hardware and software attack surface a market-surveillance authority would reach first, debug interfaces left live on the board, default credentials, exposed services. We find it by probing the board, not by reading the spec.
- SBOM and component due diligence
We build the software inventory from the shipped binary, not the build manifest, and reconcile the two. Then we verify that the components your security actually depends on (cryptography, secure updates, communications) do what the product needs of them. The CRA requires that due diligence, and its guidance accepts hands-on testing as proof. Working from the binary is exactly that.
- Known-vulnerability exposure
Third-party components mapped to current CVEs, then triaged by reachability rather than raw CVSS. Whether a flaw is actually exploitable in your build is what the CRA guidance uses to decide what's even reportable, so this is what separates a real obligation from noise on the list.
- Detection and logging
Whether the product can notice when something is wrong and leave usable evidence. That means security-relevant logging, tamper and anomaly signals, and the telemetry that lets an incident be detected at all. That's the technical precondition for the CRA's reporting duties. The reporting process itself stays with your team; we make sure the product can feed it.
Already running an analysis platform?
Keep it. Automated firmware-analysis platforms are good at the continuous machine work. They generate an SBOM on every build, match components against new CVEs, and flag what changed.
The platform gives you a list of hundreds of components and dozens of findings. It can't say which ones matter for your product, whether the critical CVE is reachable in your build, or what lives in the binaries it couldn't parse. And it never opens the device, so secure boot, key storage and the state of the debug interfaces stay invisible to it. MKR Labs verifies and triages the list, and does the on-device work the platform can't reach, so your conformity claim rests on the product as built, not just its component manifest.
What you get
- Gap report
Every finding with evidence and a severity, mapped to the CRA essential requirements. The on-device findings lead (secure boot, key storage, exposed interfaces), followed by the component and vulnerability review. No speculative items.
- Remediation roadmap
Ordered by deadline exposure, covering what must exist by September 2026, what by December 2027, and what is good engineering either way.
- Verified SBOM
For the assessed firmware, in CycloneDX or SPDX.
- Re-verification
We re-check the fixes once you've closed the gaps.
How an engagement runs
Scope
We agree what's in and what's out before any work begins. That covers which product or product line, which markets and obligations apply, how we get the firmware and a unit to test, and how close your deadlines are. You get a fixed scope and a fixed price up front, so there are no open-ended hours and no surprises on the invoice. Your firmware and the unit are handled in an isolated environment and deleted after the engagement, with the handling documented.
Assess
The technical work happens in our own lab. We open the device to extract the firmware, follow the boot chain and root of trust, check how keys are stored and which interfaces are live on the board, and exercise the update path. Alongside that we build the SBOM from the shipped binary and map components to current vulnerabilities, reconciling all of it against how the product is actually built.
Report
You get a written report you can put in front of an auditor, with evidence and a severity on every finding. Then we walk your engineers through it in a working session rather than emailing a document and disappearing, so the findings turn into a plan the team owns.
Follow through
As you close the gaps, we stay available to answer questions and re-verify the fixes, so the evidence file reflects the product you actually ship rather than the one you intended to. When new vulnerabilities surface later, you already have a partner who knows the product.
An ongoing obligation
CRA compliance is continuous by design. From September 2026, you have to keep handling vulnerabilities as they show up. New CVEs land in components you've already shipped, and every firmware release changes what's in the product. One assessment gets you to a known state; staying there is the ongoing part.
Automation carries much of the routine watch between assessments, running SBOM and CVE checks on each build. But a significant firmware release can also change the product on the bench, a new signing key or a reworked update path, and that still needs a human to re-verify. MKR Labs works with your team on that recurring basis, re-checking both the components and the device as the product and the threat landscape move.
When a new CVE lands in something you have already shipped, the question is always the same. Does it actually affect this product? We answer it from the binary and the device, whether the vulnerable code is present, whether it is reachable, and whether it can be reproduced on the built product, so you patch and report what genuinely matters and can stand behind leaving the rest. Many teams keep this as a standing arrangement, so when the next CVE lands they already have someone who knows the product.