Industrial Device & Firmware Security Assessment
Security assessment of connected and embedded products, from physical interfaces, hardware security controls and boot chains through firmware, protocols, applications and relevant backend components.
Depending on the product architecture, the assessment combines hardware and firmware analysis with penetration testing of protocols, applications, APIs and connected backend services.
One product. Multiple trust boundaries.
A product rarely fails at one isolated layer. Debug access can expose firmware. Firmware can contain credentials. Device identity can affect backend trust. Update logic can undermine an otherwise correct secure-boot chain.
What we test
Hardware & physical access
Debug interfaces, maintenance interfaces, storage access, flash extraction, readout protection, lifecycle configuration and hardware-backed controls.
Boot & firmware trust
Boot stages, secure boot, recovery paths, rollback, firmware verification and privileged startup behavior.
Firmware & embedded software
Filesystems, binaries, parsers, services, privileged components, hidden maintenance logic and exposed functionality.
Identity, secrets & cryptography
Device credentials, key material, secure storage, provisioning, signing, device identity and cryptographic trust decisions.
Protocols & interfaces
Proprietary protocols, authentication, state handling, pairing, RF where relevant and protocol reverse engineering.
Applications & backend paths
Management applications, APIs and connected services where they affect the security of the product.
The exact assessment surface follows the product architecture. Not every engagement needs every layer.
The interesting findings often sit between layers.
Debug → Firmware → Backend
A maintenance interface exposes firmware. Extracted credentials allow access to an internal product API. The issue is no longer just “debug access.”
Update → Boot → Persistent compromise
The update package is signed, but recovery accepts an older valid image. A rollback path reintroduces a known exploitable state.
Device identity → Fleet impact
Credentials intended to identify one device are shared or clonable. A local product weakness becomes a fleet or backend trust problem.
What happens to the device while we have it.
Your device is opened, documented and surveyed for its interfaces: debug access such as UART and JTAG, memory buses such as SPI, wireless links such as Bluetooth LE and Thread. What exists, what is open, what does the state reveal about the production build?
We extract the firmware where its protection does not hold, and analyse the boot chain, update path and key storage. On a logic analyzer we trace what the device actually verifies in the first milliseconds after power-on. Connections to backend services are followed down to the protocol level.
Interventions that may damage the device, such as removing a memory chip, happen only with your written approval. Every step is documented. Your hardware stays yours, returned with a final report on its condition.
Tools: logic analyzer · SPI/JTAG programmers · BLE/Thread sniffers · ChipWhisperer for side-channel analysis where agreed. Depending on scope: EM fault injection, high-bandwidth oscilloscopy, near-field EM analysis; decapsulation and X-ray in cooperation with specialised partners.
Scope follows the product architecture.
Architecture
Product architecture, hardware platform, boot flow, update path, protocols, applications and connected services.
Attacker assumptions
Physical access, network access, credentials, product samples, firmware images, source code or other agreed starting conditions.
Technical depth
We select the methods needed to answer the actual security question rather than forcing the product into a fixed checklist.
A complete architecture package is not required before the first conversation.
What you get
Reproducible findings
Steps, evidence and affected components sufficient for engineering teams to reproduce the issue.
Technical impact
What the weakness actually enables under the agreed attacker assumptions.
Attack-path context
How findings interact across product layers rather than presenting isolated scanner-style observations.
Remediation & retest
Technical remediation context and verification of fixes against the original attack path where retesting is in scope.
- ACCESS
- physical device
- PATH
- recovery → signed legacy image → vulnerable service
- IMPACT
- persistent execution of vulnerable firmware
- STATUS
- reproducible
When this assessment fits
Need the assessment to support a regulatory requirement?
Where required, assessment scope and findings can be mapped to relevant technical requirements from the CRA, EN 18031 and IEC 62443.
Dr. Ewan Fleischmann
22+ years IT security · PhD cryptography · OSCP · OSCE · CISSP
Building a product that needs serious security testing?
Tell us what you're building, the current development stage and what you want tested. The scope follows from the product.