Research area · Product & OT Security
Security built into the product — from the control unit to the medical device
Connected vehicles, industrial controls, medical devices, and AI devices stay in the field for a long time. Vami Research examines how their security can be demonstrated across the entire lifecycle — from the TARA with the Automotive Threat Matrix through IEC 62443 and the Cyber Resilience Act to the maintenance of connected medical devices and AI in the device.
- Automotive Threat Matrix
- ISO/SAE 21434
- IEC 62443
- CRA reporting obligation
- MDR & IEC 81001-5-1
- AI in the product
- TISAX
- Deep Dives
- 10
- Whitepapers
- 3
- Solutions
- 3
When software is inside the product, security becomes a product property
Product security protects not your own IT but the product in the field — often against attackers with physical access and over service lives that significantly exceed typical IT support cycles. A vulnerability affects the entire installed base and can lead to safety consequences, recalls, or the loss of type approval. Responsibility thus shifts from IT operations to product development.
Regulation is catching up: since July 7, 2024, every new vehicle of categories M, N, and O in the EU has needed a cybersecurity type approval under UN R155; since August 1, 2025, cybersecurity requirements have applied to internet-connected radio equipment; and since September 11, 2026, the reporting obligations of the Cyber Resilience Act have applied. From January 20, 2027, the Machinery Regulation will impose binding cybersecurity requirements on machinery for the first time. Medical devices continue to be governed by the MDR — the CRA excludes them.
AI in the device adds a new dimension: planners, skills, and tool calls become commands to motors, locks, or valves. Vami Research therefore combines established methods such as TARA, zone models, and IoT pentests with threat models for agentic AI and publishes the results as deep dives, whitepapers, and expert articles, for example in the journal mt|medizintechnik.
Open questions in practice
- 01
How do you describe attacker behavior against vehicles so that TARA, pentest, and Vehicle SOC speak the same language?
Our approach
We use the Auto-ISAC's Automotive Threat Matrix, release v4.02 of December 4, 2025, with 14 tactics and 75 techniques. We freeze the version and record it in the TARA and CSMS; we anchor technique IDs in the PSIRT, the pentest scope, and the Vehicle SOC. For backend, companion app, OTA server, and charging, we maintain an extension layer of our own — the matrix primarily describes the vehicle itself.
- 02
How do manufacturers embed security from the threat model to the reporting of an actively exploited vulnerability?
Our approach
We follow ENISA's Secure by Design and Default Playbook: each principle with a checklist, minimum evidence, and a release gate. Added to this are threat modeling, an SBOM per release, and a PSIRT that meets the CRA deadlines of 24 hours, 72 hours, and 14 days. VamiGRC maps the Product Security Lifecycle with release gates, TARA, and SBOM; VamiAppSec prepares notifications as drafts.
- 03
How can production plants be secured without jeopardizing availability and functional safety?
Our approach
We divide plants into zones and conduits in line with IEC 62443 and define a target security level for each zone. Asset visibility comes from passive discovery, because active scans can disrupt older controllers. Remote maintenance runs through dedicated gateways with per-session activation. This makes the obligations under NIS2, which also covers manufacturing, implementable in the OT environment.
- 04
How do connected and AI-enabled medical devices stay secure in the field when security also means patient safety?
Our approach
We interlink security and safety risk management in line with MDCG 2019-16 and IEC 81001-5-1: inventory with SBOM, triage with clinical context, patches as controlled changes, and aligned reporting channels. For AI, prompt injection and excessive agent permissions enter the threat model; for AI medical devices that involve a notified body, the AI Act's high-risk obligations apply from August 2, 2028.
Key takeaways
- 01
An exhaustive risk assessment needs both the matrix and the UN R155 catalog
We mapped the 75 techniques of the Automotive Threat Matrix onto the UN R155 threat catalog: 52 map cleanly, whereas threats against backend servers are almost entirely missing from the matrix. The UN R155 catalog, in turn, shows no attack paths and does not justify feasibility. Only the two lists together, linked via stable IDs, carry the risk assessment.
Source: Automotive Threat Matrix
- 02
In AI products, a prompt injection can have physical consequences
When AI sits inside a device, planners and tool calls become commands to motors, locks, or valves. The product is then an IoT device, an AI system, and a cyber-physical system at the same time. Testing only one layer misses the attack chains in between — which is why we model with STRIDE and MAESTRO and test from the debug interface to the LLM.
Source: AI Product Pentesting
- 03
A device that has been read out can put the entire fleet at risk
Anyone holding a connected device can address debug interfaces, read out flash memory, and analyze the firmware. Credentials or signing keys from a single device often work for the entire fleet. Testing therefore checks whether debug ports are disabled, secure boot is effective, and secrets are stored in protected form.
Source: IoT Penetration Testing
- 04
For medical devices, clinical context determines priority
CVSS, EPSS, and KEV assess severity, likelihood, and ongoing attacks — but not whether a device is in use at the patient's side or whether tampering would alter diagnosis and therapy. Only these questions determine the priority class. A medium-rated vulnerability on a therapy system can therefore be more urgent than a critical one on an isolated device.
Source: Medical Device Maintenance
How we work
Vami Research combines industry-specific standards with a shared methodology: model threats, test across all layers, and maintain evidence that can be used in the TARA, the technical documentation, and the conformity assessment.
TARA with the Automotive Threat Matrix
Matrix techniques as building blocks of attack paths under ISO/SAE 21434, cross-checked against the UN R155 threat catalog; feasibility assumptions under version control.
STRIDE and MAESTRO
A threat model per data flow and trust boundary, for agentic AI along the seven MAESTRO layers — in VamiThreat with mapping to MITRE ATT&CK and ATLAS.
Zones, conduits, passive discovery
Divide plants into zones with target security levels in line with IEC 62443; build the inventory from mirrored traffic instead of active scans in the production network.
Testing from chip to cloud
IoT and AI product pentests along OWASP ISVS and ISTG as well as ETSI EN 303 645: hardware, firmware, radio, backend, app, and model in context.
Release gates with minimum evidence
ENISA playbooks with a checklist and release gate; SBOM per release, VEX, and a PSIRT process as the basis for reporting readiness under the CRA.
Clinical triage
Supplement the technical assessment with reachability, proximity to the patient, and consequences for diagnosis or therapy; roll out patches as controlled changes.
How to get started
- 1ModelCapture architecture, data flows, and trust boundaries; derive threats and attack paths via TARA, STRIDE, or MAESTRO.
- 2Test and hardenPentests from the debug interface to the LLM, segmentation by zones, release gates with minimum evidence.
- 3Operate in the fieldMonitor the SBOM per release, receive vulnerability reports via CVD and the PSIRT, and define reporting channels under the CRA, MDR, and BSI Act in advance.
Deep dives, whitepapers, and analyses
Deep Dives 10
Whitepapers 3
Analyses & news
From research area to implementation
Related research areas
Want to secure your product from the TARA to the notification?
Whether vehicle component, industrial control, or medical device: we put standards and deadlines in context, model threats, and test from the debug interface to the LLM.