Preparing for the Cyber Resilience Act specifically? See CRA Readiness Assessment. Shipping a wireless product? Its cybersecurity is already regulated under RED. See RED & EN 18031 Assessment.
Find it before someone else does
Every connected product ships with weaknesses its makers can't see from the design documents: an unsigned firmware image, a radio link that trusts too much, a debug port left enabled, a cloud API that takes the app at its word. They live in the built product, not the build plan, which is exactly where most testing doesn't look.
Someone eventually finds them. A researcher, an attacker, a customer's security team, or a market-surveillance authority under the CRA. The only question is whether it's you first. An independent, hands-on assessment turns those unknowns into a short list you can fix on your own schedule, before a disclosure, a recall or a failed conformity assessment sets the schedule for you.
For wireless products, this is already the law
If your product has a radio, Wi-Fi, Bluetooth, cellular or a proprietary link, the Radio Equipment Directive's cybersecurity rules have applied since August 2025, and EN 18031 is the standard that demonstrates conformity. Unlike the CRA's deadlines, this one is already in force. It asks for exactly the things you can only check on the built device: signed and verified updates, no default passwords or hardcoded keys, protected secrets, secure communication, and a radio that can't be used to harm the network. That is the ground where the radio meets the firmware, which is the work we do. See RED & EN 18031 Assessment for that work in full.
From the binary, not the build plan
Documentation describes the product as designed. We assess the product as built, extracting and unpacking the shipped firmware, reversing the interesting parts, and verifying claims against what the binary actually does. That includes RTOS and bare-metal images, the firmware that standard analysis tooling reads as a blank page.
- Firmware reverse engineering
Extract, unpack and reverse the shipped image, including the RTOS and bare-metal binaries standard tooling reads as a blank page.
- SBOM from the binary
The real software inventory, built from what actually shipped and reconciled against your manifest.
- Secure boot and root of trust
Whether the boot chain can be bypassed, downgraded or fed unsigned code.
- Debug interfaces
What JTAG, SWD, UART and SPI leave open on the board, and what that hands an attacker.
- On-board secrets
Flash extraction, and how keys and credentials are stored on the device itself.
The radio, not just the firmware
Most assessments stop where the antenna starts. We take the radio link and the firmware behind it as one target. We capture the protocol off the air, correlate it with the handlers in the binary, and characterise the control channel end to end, covering pairing and encryption, application-layer authentication, replay and relay resistance. For wireless products this is exactly what EN 18031 covers, and it's where the combination of RF and firmware work in one lab pays off.
The app and cloud it talks to
A connected product is more than the box on the bench. The companion app and the cloud backend are part of it, and the device trusts both. We follow a command from the app, through the API, to the device, and check what is actually enforced along the way, how the app and backend authenticate each other, how sessions and keys are handled, and whether the device takes the cloud's word for things it shouldn't. A secure device behind a permissive API is still a vulnerable product.
What you get
- Findings report
Every finding with a severity, the evidence and steps to reproduce it, written for your engineers and with remediation that respects how the product is built.
- Standard mapping
Findings mapped to the standard you're certifying against (EN 18031, EN 303 645), in the certifier's language and ready for whichever body you choose.
- Attacker model
A realistic picture of who would attack the product, how, and from where.
- Re-testing
We re-check that the fixes hold once you've addressed them, included in the scope.
How an engagement runs
Scope
We agree the target and the boundaries before work starts. That covers which device, how we get the firmware and hardware, what access we need to the companion app and its backend, and which standard you need to meet. The scope and the price are fixed up front, with no open-ended hourly meters running in the background. Your firmware and the unit are handled in an isolated environment and deleted after the engagement, with the handling documented.
Assess
Firmware, hardware and RF work all happen in our own lab. We extract and reverse the firmware, probe the debug and radio interfaces, and correlate what the device does on the air with what the binary actually implements. Where there is a companion app and cloud backend, we trace commands from the app through the API to the device and check what each side enforces.
Report
You get a findings report with severity, evidence and reproduction steps, written for engineers and with remediation that respects how the product is built. We debrief the team directly, so the report turns into fixes rather than a document that sits on a shelf.
Re-test
Once you've addressed the findings, we verify that the fixes actually hold and update the report accordingly. The result is something you can put in front of a certifier or a customer with confidence.
For test labs and certification bodies
Are CRA and RED generating more technical assessment work than you have hands for? MKR Labs takes firmware and RF assessment work as a subcontractor. You hold the accreditation and the client relationship, we bring the lab and the hands, quietly and under your brand where needed.