Penetration testing: attack your product before others do

A flaw found in-house costs a fix. The same flaw found by someone else costs an incident.

A penetration test means putting your product in the hands of someone whose only goal is to make it give way: read what it should not reveal, run what it should not run, take control where nobody expects it. We do it for you, within an agreed framework, and leave you with a report your developers can turn into fixes.

What we test

Embedded and IoT products

• Physical interfaces: debug ports (JTAG, SWD, UART) left open, flash readout, firmware extraction.
• Boot and update chain: does an unsigned image boot? Can you roll back to an old vulnerable version? Can the over-the-air update be hijacked?
• Embedded secrets: keys, passwords and certificates readable in the firmware or in memory.
• Radio links: Bluetooth Low Energy, LoRaWAN.

Web applications and APIs

• Authentication and session management.
• Access control: can one user read or change another user’s data?
• Injection, input validation, sensitive data exposed through REST APIs.

Industrial protocols

• Modbus/TCP, OPC UA and OT gateways: who can read and write a PLC’s registers, and with what proof of identity?
• Maintenance access and links between the production network and the office network.

Network and infrastructure

• Exposed services and vulnerable versions.
• Segmentation between IT and OT.
• Remote access: VPNs, remote maintenance tools.

Why firmware engineers to attack a product

We design bootloaders, signed update chains and industrial products. So we know where the shortcuts taken under schedule pressure hide: the debug port “we’ll close for production”, the sample signing key never replaced, the Modbus service open to the whole network. Our method is public: the CRA & Dev wiki documents, with code and a test bench, the attacks and defences we test (signed LoRaWAN updates, data integrity, secrets at rest), and our publications gather the rest.

And because we also know how to build, we don’t stop at the finding: we can fix it with your teams.

How a test runs

1. Scoping, free of charge: what you want to protect, what is in scope, what is not. It ends with a quote.
2. Written authorisation: scope, testing windows, emergency contacts. We test nothing without it.
3. Testing: on your hardware, your application or your network, within the agreed scope.
4. Report: each vulnerability with its severity, the evidence, the steps to reproduce it and the recommended fix. A summary for management, the detail for developers.
5. Debrief: we walk your teams through the results and answer their questions.
6. Remediation, if you want it: we fix with you, then check that the flaw is actually closed.

A penetration test is also CRA evidence

The Cyber Resilience Act requires manufacturers to apply effective and regular tests and reviews of the security of their product (Annex I, Part II, point 3), and to protect it against unauthorised access (Annex I, Part I). The test report, and the record of what was fixed, go straight into your technical documentation. The vulnerabilities found follow the same path as any other: fix, disclosure, update.

If you are preparing your product’s compliance, penetration testing fits with our CRA service; it can also be ordered on its own.

Pricing

Quoted after the free scoping call: the effort depends on the scope (one firmware, one application, a factory network) and the depth you need.

➡️ Book a scoping call, or write to us at info@adnt.io.