When to Use
- Plan or execute authorized security assessments on real hardware with a HIL rig (ECU, ECM, PLC, gateway, domain controller)
- Design test bench topology, bus taps, power/reset control, and safety interlocks before active testing
- Map attack surfaces on cyber-physical targets (diagnostics, flashing, debug ports, wireless, OTA paths) under lab conditions
- Develop fault injection and stimulus campaigns (bus frames, timing, signal, power) with reproducible test cases
- Monitor buses and interfaces during tests; correlate observations with firmware/vehicle security teams
- Capture evidence (logs, traces, captures, configuration snapshots) suitable for remediation and retest
- Coordinate retest after firmware patches, key rotation, or configuration hardening on the same bench
When NOT to Use
- Web application or API-only assessments (OWASP, proxy methodology) →
web-pentester - Network/AD/infra pentest without embedded targets on the bench →
network-pentester - General penetration test without HIL hardware, buses, or plant simulation →
penetration-tester - Disassembly, decompilation, patch diff, or malware RE as primary work →
reverse-engineer - SIEM alert triage, SOC playbooks, or shift operations →
soc-analyst - Live incident command, war room, or production containment →
incident-responder - LLM jailbreak, prompt injection, or agent tool abuse →
ai-redteam - Classified ISSO / accreditation paperwork without hands-on HIL testing →
information-systems-security-officer-classified-specialist - CI build validation or release gates without hardware under test →
build-validator - Enterprise security strategy, GRC roadmap, or policy without lab execution →
cybersecurity - Control testing and audit evidence mapping only (no active HIL tests) →
compliance-engineer
Related skills
| Need | Skill |
|---|---|
| Authorized general pentest (non-HIL primary) | penetration-tester |
| Binary/firmware RE, protocol reverse engineering | reverse-engineer |
| Implement fixes (IAM, SIEM, guardrails) on IT systems | information-security-engineer |
| Security program, risk acceptance, engagement governance | cybersecurity |
| Audit control mapping and evidence packages | compliance-engineer |
| Web/API layer when also in scope | web-pentester |
| Network/AD when bench includes enterprise segment | network-pentester |
| Threat context and TTP mapping for reports | cti-analyst |
| Customer-facing technical writeups | tech-writer-researcher |
Core Workflows
1. Authorization, scope, and bench readiness
Do not energize targets or inject faults without written authorization and completed safety review.
- Confirm signed SOW/ROE: targets, buses, methods, time windows, stop conditions
- Complete bench FMEA / hazard review with lab owner; document interlocks and e-stop
- Inventory target firmware versions, keys, calibration, and baseline configuration
- Define out-of-scope (moving machinery, public roads, production fleets, third-party networks)
- Establish emergency stop, power-down procedure, and escalation contacts
See references/hil_security_tester_scope.md and references/test_bench_and_safety.md.
2. Attack surface mapping and test design
baseline capture → interface inventory → trust boundaries → threat hypotheses → test cases → peer review
Prioritize interfaces exposed on the bench: OBD/diagnostics, flashing, debug (JTAG/SWD), wireless, USB/Ethernet, service modes, and cross-domain gateways.
See references/bus_and_interface_security.md and references/automotive_and_industrial_patterns.md.
3. Execute fault injection and stimulus (in scope)
- Run reproducible scripts or harness-defined sequences; version control stimulus definitions
- Record bus traces, power events, and target responses with synchronized timestamps (UTC)
- Stop at agreed impact; avoid unbounded fuzzing on safety-critical actuators without explicit approval
- Restore baseline configuration and clear test keys/sessions before handoff
See references/fault_injection_and_stimulus.md.
4. Evidence, reporting, and coordination
Per finding: title, severity, safety note, impact, preconditions, reproduction on bench, evidence refs, remediation owner, retest criteria. Coordinate with firmware/vehicle security on exploitability vs design intent.
See references/evidence_and_reporting.md.
When to load references
| Topic | Reference |
|---|---|
| Role boundaries and engagement types | references/hil_security_tester_scope.md |
| Bench topology, interlocks, lab safety | references/test_bench_and_safety.md |
| CAN/LIN/Ethernet/Modbus security angles | references/bus_and_interface_security.md |
| Fault injection and stimulus design | references/fault_injection_and_stimulus.md |
| Evidence capture and reporting | references/evidence_and_reporting.md |
| Automotive and industrial patterns | references/automotive_and_industrial_patterns.md |