Konova

Security assessments for connected devices and embedded systems.

We test the firmware and hardware of your connected product as an attacker would, under contract, NDA and your written authorization, then hand you a remediation plan your engineers can act on. We also prepare products for the cybersecurity requirements of EU CE marking.

Email Konova

  • Bootloader
  • LZMA kernel
  • SquashFS root filesystem
  • JFFS2 config
  • Encrypted blob
Entropy across an 8 MiB SPI flash image (illustrative). Flat plateaus near the top are compressed or encrypted data, jagged stretches are code, and drops to zero are erased flash. Mapping them is where a firmware assessment starts.

On the device

  • Debug port UART, SWD
  • External flash SPI

Microcontroller bootloader, firmware, keys

  • Radio links BLE, Wi-Fi, LoRaWAN, cellular
  • Companion app pairing, provisioning
  • Backend API, MQTT over TLS, updates
Attack surface of a typical connected device (illustrative). Each interface that carries code or data is an entry point, marked with a pad; the written authorization says which ones are in scope.

Debug port open on production units

Severity
High, CVSS v4.0 score 7.0 CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Weakness
CWE-1191, on-chip debug and test interface with improper access control
Affected
Hardware revision C, firmware 2.4.1
Evidence
A debugger on the SWD test points reads the whole internal flash, device private key included, without authentication.
Fix
Enable readout protection and lock the debug port at the end of production, then check the lock on every unit during end-of-line testing.
A finding as it appears in the report (illustrative): severity, weakness class, evidence and the fix, written so your engineers can act on it.
  1. Lock the debug port in production
  2. Give each unit its own credentials instead of a shared default password
  3. Sign update images and verify them before installing
  4. Rate-limit BLE pairing attempts
  5. Encrypt the external flash
Remediation plan (illustrative): each fix placed by the risk it removes and the effort it takes, numbered in the order we recommend.
  • ACM Access control Partial
  • AUM Authentication Missing
  • SUM Secure update Partial
  • SSM Secure storage Missing
  • SCM Secure communication Met
  • RLM Resilience Partial
  • NMM Network monitoring Not applicable
  • TCM Traffic control Not applicable
  • CCK Confidential cryptographic keys Partial
  • GEC General equipment capabilities Partial
  • CRY Cryptography Met
Gap analysis against the eleven requirement families of EN 18031-1 (illustrative). Network monitoring and traffic control apply to network equipment only.

Scope

Everything on the device and everything it talks to, within the scope you authorize.

Hardware
Debug and test interfaces (UART, JTAG, SWD), readout of external and on-chip memory, readout protection and debug lock settings.
Firmware
Acquisition and unpacking, static and dynamic analysis, hard-coded credentials and keys, use of cryptography, memory-safety bugs in parsers and protocol handlers.
Update and boot chain
Secure boot, image signing and verification, over-the-air delivery, rollback protection, and the components shipped in each image (SBOM).
Radio and protocols
BLE, Wi-Fi, LoRaWAN and cellular links, pairing and provisioning, MQTT and TLS between the device and its backend.
Cloud and companion app
The backend APIs your devices call, and the pairing and provisioning flows of the mobile app.

Rules of engagement

No test starts until all four are in place.

  • A signed services agreement and a non-disclosure agreement.
  • Written authorization from the party that holds the rights to the product. It names the devices and firmware versions in scope, the test window, the techniques allowed and the contacts on both sides.
  • Devices supplied by you and tested in our lab. Cloud endpoints are in scope only if you own them and the authorization names them.
  • Findings shared only with the contacts you designate. Public disclosure, such as a CVE, only with your agreement.

Method

Six steps, from written authorization to verified fixes.

  1. Scope and authorize

    We agree on goals, devices, firmware versions and rules of engagement, and collect the written authorization.

  2. Map the attack surface

    We list the interfaces, radios, update path and backend, and the assets an attacker would go after.

  3. Assess

    We test the device as an attacker would: hardware first, then firmware, radio links and the backend in scope. Every finding is reproduced before it is reported.

  4. Report

    Each finding comes with its severity (CVSS v4.0), its weakness class (CWE), the evidence and the steps to reproduce it. A summary sets out the risks for decision-makers.

  5. Plan the remediation

    We rank fixes by risk and effort and explain how to apply them on your platform: debug lock, secure boot, flash encryption, signed updates, key provisioning.

  6. Verify the fixes

    We retest what you fixed and confirm in writing which findings are closed.

We work from public references: the OWASP Firmware Security Testing Methodology, the OWASP IoT Security Verification Standard, ETSI EN 303 645 and NIST SP 800-115.

CE compliance

Two EU regulations make cybersecurity part of the CE marking of connected products. We assess your product against them and help you build the evidence.

Delegated Regulation (EU) 2022/30 under the Radio Equipment Directive applies to radio equipment that connects to the internet. The harmonised standards EN 18031-1, -2 and -3 were cited in the Official Journal in January 2025 with restrictions; where a restriction applies, a notified body must assess the product.
Under the Cyber Resilience Act, Regulation (EU) 2024/2847, manufacturers report actively exploited vulnerabilities and severe incidents through ENISA’s Single Reporting Platform, starting with an early warning within 24 hours.
The Cyber Resilience Act applies in full, including its essential requirements and conformity assessment for products with digital elements.

What we do

  • Gap analysis against EN 18031 and the CRA essential requirements (Annex I)
  • Cybersecurity risk assessment for the technical documentation
  • Vulnerability handling and coordinated disclosure process
  • Software bill of materials (SBOM)
  • Readiness to report within the CRA deadlines

Konova is not a notified body. We prepare your product and its documentation for self-assessment or for assessment by a notified body.

Contact

Konova SAS is an engineering firm founded in 2020 in Auvergne, France. We work in English and French.

Describe your product, its interfaces and your timeline:

To report a vulnerability in Konova’s own systems, see our security.txt.