We attack your ECU the way a real adversary would — before one does.

What we test

An ECU is not one attack surface; it is a graded set of them. We scope each engagement from the threat model rather than a fixed checklist, then go deep where the risk is. Across an engagement we work the following surfaces — and the interesting findings almost always live in the seams between them.

Diagnostics & authentication (UDS — ISO 14229)

The most common production entry point. The ECU answers every request; the question is who is allowed to ask.

• SecurityAccess (0x27) — seed entropy and reuse, key strength and extractability, lockout / back-off enforcement across resets and session changes, brute-force resistance.
• Authentication (0x29, ISO 14229-1:2020) — certificate-based flows: trust-anchor scope, nonce/freshness handling, revocation, and silent fallback to a weaker 0x27 scheme.
• DiagnosticSessionControl (0x10) — whether the unlocked level genuinely gates the services it claims to, and whether it re-locks on S3 timeout / ECUReset / session change.
• SecOC — freshness-value handling, MAC truncation, and replay windows on protected messages and the routines diagnostics trigger.
• Typical finding: a protected service reachable on the bench through an unhandled state transition, not a broken cipher.

Secure boot & boot-chain integrity

A signed bootloader is not a secure boot chain. The chain is only as strong as the link you did not verify.

• Signature/integrity verification at each stage; partial-image acceptance; signature confusion; time-of-check / time-of-use gaps.
• Rollback / anti-downgrade an attacker cannot strip; the reaction on a failed check (halt, degrade, or — the finding you do not want — continue).
• Boot-status signalling and exfiltration via side-channel; debug re-entry into a verified chain.

HSM / SHE & cryptographic material

Good cryptography fails quietly at the boundary, not in the algorithm.

• Secure key storage, key-update / updater security, separation of debug vs production key material.
• Whether the application side actually respects the HSM/SHE boundary, and whether key material survives in NVM after rotation.

Secure flashing, NVM & anti-downgrade

• Post-flash data-flash erase and re-key behaviour; atomicity of post-processing; abort-mid-flash residue.
• Monotonic anti-downgrade counters verified end-to-end (write-once / HSM-protected), not a version field nothing enforces.
• NVM read-out and exfiltration gated against diagnostic and debug paths (UDS ReadMemoryByAddress, XCP, DAP).

Hardware interfaces & debug ports

• JTAG/SWD, UART, SPI and test pads that survived into production — whether debug locks are actually fused and active in the production state, or merely assumed.
• Firmware extraction attempts via exposed interfaces; boot-log and shell exposure on UART.

In-vehicle communications

• CAN / CAN-FD and automotive Ethernet: message injection, spoofing, MITM positioning and structured fuzzing of diagnostic and application traffic.
• Findings mapped to the affected function and its security goal — not reported as raw bus noise.

Secure software architecture & TEE

• Partition / privilege isolation, separation of safety-relevant partitions from the comms stack, dangerous APIs exposed to untrusted partitions, MPU configuration.
• Trusted Execution Environment: attempts to read/replace cryptographic data across the boundary.

Side-channel & fault injection

• Timing and MAC-comparison side-channels in software; key-derivation leakage on CMAC/AES verification.
• Voltage / clock glitching and physical-tamper resistance assessed against the ECU's stated security goals.

Lifecycle & ECU state machine

• Development-vs-production state, the customer switch-over that locks the part down, and the integrity of security flags across lifecycle transitions.
• A device that ships still reachable in a development state is a finding regardless of how strong its crypto is.

How we run an engagement

Risk-driven and process-disciplined, so the result is reviewable by your cybersecurity team and your assessor — not a list of what we happened to try.

1. Scope from the threat model. We start from your TARA (or build a focused one). Damage scenarios, threat scenarios and attack-feasibility ratings decide where effort goes; every test objective traces to an asset and a security goal.
2. Grade the effort by CAL. Test depth and the assumed attacker are set by the Cybersecurity Assurance Level, agreed before we start (see the table below).
3. Execute against NIST SP 800-115. Planning → discovery → attack → reporting. Each finding is captured as a reproducible test vector: setup, steps, observed result, evidence.
4. Test in rounds. Initial testing, your remediation, then a re-test that confirms the fix closed the finding and did not move it elsewhere. Regression on prior findings is part of every later round.
5. Report at mitigation grade. Impact, attack-feasibility, the traced asset/goal, a reproducible vector, and a concrete remediation with a verification criterion for the re-test.

CAL-graded effort

Assurance level	Assumed attacker	Engagement shape
CAL2	Limited time & tooling; adjacent/local access	Focused scope, single round on the highest-risk paths
CAL3	Skilled, resourced, time on target; knowledge of the item	Broad scope, two rounds over a multi-week window, invasive techniques in play
CAL4	Expert, well-funded, specialised equipment	Deep multi-round programme; advanced hardware attacks scoped explicitly

CAL reflects the rigour ISO/SAE 21434 expects of cybersecurity activities; we use it to size the attacker model and test depth, agreed with you up front.

What you receive

A report your engineers can act on and your assessor can read. Per finding:

• The asset and security goal affected, and the damage scenario behind it.
• Attack-feasibility rating and a justified severity — no inflation.
• A reproducible test vector: exact setup, steps, observed result, evidence — so you (or we, in a later round) reproduce it precisely.
• A concrete remediation with a verification criterion for the re-test.

Plus an executive summary that states residual risk in terms a cybersecurity manager can take to a release decision, and weekly status during the engagement — what was tested, what was found, what is blocked, what is next. The report is structured so it can serve as evidence in your ISO/SAE 21434 verification and your UNECE R155 type-approval file.

Frequently asked

What changes at a higher CAL (e.g. CAL3)?

A stronger assumed attacker — more time, expertise, equipment and prior knowledge — which widens the in-scope attack paths and how far each is pushed, typically across two rounds rather than a single sweep.

Black-, grey- or white-box?

All three. Grey- and white-box (with the TARA, interface specs and ideally source/design) find materially more per day, because effort goes to real attack paths instead of rediscovering the architecture.

Can you operate as an approved lab for an OEM programme?

Yes. We support the OEM's vendor-onboarding and lab-approval process and provide the lab, methodology and tester documentation an OEM cybersecurity authority requires to approve a test partner.

What do you need to start?

A DUT on a production-intent software release, the threat model / TARA, interface and diagnostic specs, and an agreed scope with explicit in- and out-of-scope items.

Why STS

We attack ECUs from the inside out because we build the stacks we attack — secure-diagnostic services, secure boot, HSM/SHE integration and secure flashing on production automotive MCUs. That builder’s view is why our findings point to the root cause and the fix, not just the symptom. And because we are engineers first, the engagement does not end at a list of problems: you get the remediation and the re-test that proves it closed.

Led by Adrian Valea — Automotive Cybersecurity (TÜV NORD), 25 years of automotive embedded engineering across OEM and Tier-1 programmes, with a delivery footprint across Germany, Romania, India and China.