Security testing for connected products, from the circuit board to the cloud
We test the devices and products you make as one system: the hardware, the firmware, the app that pairs with it, the backend it reports to and the way it is updated. Inside a scope you authorise in writing, and with findings your engineers can act on.
Overview
Why a connected product needs its own test
A connected product is rarely one thing. It is a device with firmware, a mobile or desktop app, a cloud service, an API and an update channel, often built by different teams and suppliers. Weaknesses tend to sit where those parts meet, so we test them together and follow the trust between them.
We only test products you make or are entitled to have tested, on units and environments you provide or approve. The engagement covers the areas you choose, and we can review documentation, design and source code alongside the hands-on testing for a more complete picture.
The work can be shaped around recognised guidance, for example ETSI EN 303 645 for consumer IoT or the OWASP IoT guidance, and it produces evidence you can use when preparing for the EU Cyber Resilience Act. Black Fox is not a notified body and does not certify products. We test, report and help you fix what we find.
Who it is for
Manufacturers of connected devices and products, from consumer smart home and wearables to industrial, building and medical-adjacent equipment, and the teams that build their firmware, apps and cloud services. Especially useful for manufacturers preparing products for the EU Cyber Resilience Act or answering security questions from retailers, integrators and enterprise customers.
The work, from scoping to evidence.
What we do
Device and hardware
The physical unit and its exposed interfaces, such as debug and service ports, storage and buttons, and what someone with the device in hand could learn or change.
Firmware
A review of the firmware image and how it runs, including stored secrets, outdated components, default settings, local services and how the device protects its own code.
Companion app
The mobile or desktop app that sets up and controls the device: pairing, authentication, data stored on the phone or computer, and what it trusts from the device and the cloud.
Cloud backend and APIs
The services the device and app talk to, including device identity, account and access control, tenant separation and the APIs exposed to the device, the app and third parties.
Update process
How updates are built, signed, delivered and installed, and whether the device accepts only updates it should, with a look at rollback and recovery behaviour.
Communication and pairing
How the parts of the product talk to each other over the network and local radio links, and whether that traffic is protected and authenticated as the design intends.
How the engagement runs
Kickoff and scoping
We agree the product, the versions, the components in scope and what is out of bounds. An NDA can be signed before the first meeting.
Proposal and authorisation
A proposal, then written authorisation from someone entitled to give it, and rules of engagement: test units, environments, contacts and how critical findings are reported.
Product mapping
We map the components, interfaces, data flows and trust relationships from your documentation and the units you send, and agree where to focus.
Testing
Hands-on testing of the device, firmware, app, backend and update process within the agreed rules. Anything that cannot wait for the report is raised with you straight away.
Results handover
A business report, a technical report with proofs of concept and remediation advice, walked through with the engineers and product owners who will act on it.
Retest
Once fixes are in a new build or release, we test the reported findings again and record which ones are closed.
What you receive
- Agreed scope and rules of engagement
- Product map of components, interfaces and trust relationships
- Business report with risk assessment for management
- Technical report with proofs of concept and remediation advice per component
- Input for your cybersecurity risk assessment and technical documentation
- Retest results for the fixed findings
Questions
Do you test devices we did not make?
No. We test products you manufacture, or that you are entitled to have tested, with written authorisation. If a third-party component is in scope, we agree with you how it is handled before we start.
What do you need from us?
Usually test units, access to the app and a test environment for the backend, and any documentation you can share. Firmware images, design documents and source code are optional, but they let us cover more in the same engagement.
Does this test make our product compliant with the Cyber Resilience Act?
No. Testing is evidence for some essential requirements, but conformity rests on the risk assessment, design, vulnerability handling and documentation together. Black Fox is not a notified body. The test tells you where the product stands and what to fix.
Can you test before the product launches?
Yes, and it is often the best time. Testing a pre-release build leaves room to change design decisions that are hard to change once units are in customers' hands.
Related services
- Compliance and certificationEU Cyber Resilience ActCyber Resilience Act support from Black Fox Security: essential requirements gap assessment, product security testing, vulnerability handling and documentation.
- Offensive securityPenetration TestingPenetration testing by Black Fox Security: black, grey and white box tests against an agreed scope, business and technical reports, and a retest of your fixes.
- Offensive securityMobile App Security TestingMobile app security testing by Black Fox Security: your iOS and Android apps and the APIs behind them, tested in an agreed scope, with reports and a retest.
- Offensive securityRF and Wireless TestingRF and wireless testing by Black Fox Security: your Wi-Fi, Bluetooth, sub-GHz links and access cards, assessed under written authorisation and radio rules.
Tell us what you build
Describe the product, how it connects and how it is updated. We will come back with a scope and a proposal.