Testing laboratory and consultancy · Granges-Paccot

Book a call

Cybersecurity · Connected products

Product penetration testing

Debug interfaces, memory, firmware, radio, app and cloud: we attack your product the way an attacker would, to find the vulnerabilities before they do. You receive a clear report, ranked by severity, with practical recommendations and a retest after your fixes.

Book a 30-minute callSee our services
CRA: regular security testing
Annex I
IEC 62443-4-1: penetration testing
SVV-4
The entire product chain
Hardware → cloud
After your fixes
Retest

Who it is for

What we test

  • Hardware interfaces

    Serial ports, JTAG and SWD, flash memory, secure boot.

  • Firmware

    Extraction, analysis, hard-coded secrets, vulnerable components.

  • Radio and network

    Wi-Fi, Bluetooth Low Energy, Zigbee, cellular, exposed services.

  • App and cloud

    Mobile app, product APIs, remote updates.

Our services

A penetration test tailored to your product

The scope follows the threat analysis: we test the attack paths that matter for your product first.

Test clip on the flash memory of a device, linked to a programmer and a computer
Hardware and firmware

Hardware interfaces and firmware

Debug ports left open, readable memory, unencrypted firmware, hard-coded keys and passwords, unverified boot: we open the product, extract and analyse the firmware, and check that a malicious update is indeed rejected.

What you receive

  • Analysis of the physical interfaces
  • Analysis of the firmware and components
  • Verification of boot and updates

References

  • OWASP ISTG v1.0.1
  • OWASP FSTM
Radio waves made of data packets, with one stream intercepted
Radio and network

Radio and network communications

Pairing, encryption, command replay, exposed network services, responses to malformed data (fuzzing): we analyse what the product transmits and accepts, on each of its communication interfaces.

What you receive

  • Map of exposed services
  • Pairing and encryption tests
  • Input robustness tests

References

  • IEC 62443-4-1:2018, SVV-3
  • OWASP ISTG v1.0.1
Engineer testing an electronic enclosure connected to a laptop
App and cloud

App, API and remote updates

The app that controls the product and the remote services it needs are part of its attack surface: authentication, access control between users, data protection, update chain.

What you receive

  • Mobile app testing
  • Product API testing
  • Analysis of the update chain

References

  • CRA, Art. 3, point 2
Application penetration testing
Glass shield whose cracks are sealed with golden lines
Report

Report, fixes and retest

Each vulnerability is described, demonstrated, ranked by severity and accompanied by a recommended fix. We discuss them with your developers, then verify the fixes with a retest. The report goes into the technical documentation.

What you receive

  • Executive summary
  • Detailed technical report
  • Retest report

References

  • CRA, Annex VII, point 6
  • IEC 62443-4-1:2018, SVV-4

Also

Approaches

Black box, grey box or white box

The more we know about the product, the deeper the test goes in the same time. We recommend the approach that suits your objective.

  • Black box

    We start from the product as sold, with no internal information, like an attacker who buys it.

  • Grey box

    With the documentation, test accounts and the known interfaces: more coverage in the same time.

  • White box

    With the schematics, source code and architecture: to check the security mechanisms in depth.

Cyber Resilience Act

Tests that support your technical file

The Cyber Resilience Act requires effective and regular security tests and reviews, and their reports are part of the technical documentation. Our reports are written to be included in it: scope, method, results, fixes and retest.

Sources: Regulation (EU) 2024/2847, Annex I, Part II, point 3, and Annex VII, point 6

The Cyber Resilience ActThreat analysis (TARA)

Standards

Testing frameworks

Our tests follow public, recognised methods, chosen according to your product and your regulatory objectives.

TypeStandardScope
IoTOWASP ISTG v1.0.1Security testing guide for connected devices
FirmwareOWASP FSTMFirmware security testing methodology, in nine stages
IndustryIEC 62443-4-1:2018SVV-3 vulnerability testing, SVV-4 penetration testing, SVV-5 independence
RadioEN 18031-1:2024Assessment of the effectiveness of security mechanisms (Annex A)
IoTETSI TS 103 701*Test cases for ETSI EN 303 645
GeneralOSSTMM 3Open security testing methodology (ISECOM)

* Version to be checked for your project. The OWASP methods are open projects that are updated regularly: we use the latest published version.

Our approach

Your penetration test in four steps

  1. Scoping

    Product, scope, approach, units and rules of engagement. 30 minutes.

  2. Testing

    Hardware, firmware, radio, app and cloud, according to the approved plan.

  3. Report

    Vulnerabilities ranked by severity, recommendations, debrief with your teams.

  4. Retest

    Verification of the fixes and final report for the technical file.

Frequently asked questions

Frequently asked questions on penetration testing

Does your product raise a specific question? Ask an engineer directly.

Book a call
Does the Cyber Resilience Act require a penetration test?

It requires effective and regular security tests and reviews, and their reports are part of the technical documentation. The regulation does not name penetration testing, but the Commission FAQ lists it, together with fuzzing and firmware analysis, among the appropriate means. It is the most direct way to show that the measures withstand a real attack.

Sources: Regulation (EU) 2024/2847, Annex I, Part II, point 3, and Annex VII, point 6; Commission FAQ v1.1, section 4.4.2

How many units of the product do you need?

Usually two: some tests, such as extracting the memory or accessing the debug interfaces, require opening the product and may damage it. We specify this in the test plan, before we start.

Can a prototype be tested?

Yes, and it is often the best time: a vulnerability found on a prototype can be fixed before industrialisation. The software and hardware tested simply need to be representative of the final product on the security points.

How does it differ from an EN 18031 assessment?

An EN 18031 assessment checks, requirement by requirement, that the expected security mechanisms exist and are adequate. A penetration test actively tries to get around them. The two complement each other: EN 18031 in fact provides for an examination of the implementation from an attacker’s point of view.

Sources: EN 18031-1:2024, Annex A

Do the results remain confidential?

Yes. The tests are carried out under a non-disclosure agreement, the report is delivered only to you and the vulnerabilities are not shared with anyone else. You then decide on disclosure, under your coordinated vulnerability disclosure policy.

Does every update need a new test?

Not necessarily a full test. After fixes, a targeted retest checks that the vulnerabilities are closed. For later versions, the threat analysis shows which parts have changed and what needs to be tested again.

Book a call

Tell us about your product

Book a 30-minute slot with an engineer directly. No back-and-forth by email: you choose the time, we prepare the call.

Choose a time slot

Contact details

Address
Säfeli Sàrl
Route d'Englisberg 3
1763 Granges-Paccot
Languages
French, German, English
Book a call