Skip to main content
Hands-on lab
Secure Developer
Leader

AutoSec Secure Development Lab

Harden ECU software on real hardware

Implement secure boot, SecOC and hardened diagnostic services on automotive-grade microcontrollers, then prove your controls hold under review and test.

Primary objectives

  1. Implement secure boot on an automotive microcontroller
  2. Integrate an HSM-backed key hierarchy
  3. Apply SecOC to a CAN communication matrix
  4. Harden UDS diagnostic access control

Overview

What This Lab Is For

The Secure Development Lab is where cryptographic theory meets a startup timing budget. Participants implement a verified chain of trust on automotive-grade microcontrollers — secure boot, an HSM-backed key hierarchy, SecOC on a live CAN matrix — and then prove the controls hold under test rather than asserting that they do.

Implement secure boot, SecOC and hardened diagnostic services on automotive-grade microcontrollers, then prove your controls hold under review and test.

Learning goals

  • Ship ECU software with a verifiable chain of trust
  • Integrate cryptographic services without breaking timing budgets

Technology stack

  • AUTOSAR
  • HSM
  • SecOC
  • UDS
  • C

Tools used

Hardware, Software and Security Tooling

Production-representative equipment and the toolchains engineers use on the job — not simulators standing in for them.

  • Hardware

    Physical targets and instrumentation you will work on directly.

    • Automotive-grade evaluation boardMicrocontroller with on-chip hardware security module
    • Hardware security moduleKey storage and cryptographic acceleration
    • JTAG debugger and trace probeDebugger
    • CAN bus interfaceBus interface
    • Automotive-grade evaluation boards
    • Debugger and trace probe
  • Software

    Toolchains and development environments used during the exercises.

    • HSM firmware toolchain

Exercises

2 Assessed Exercises

Each exercise is assessed rather than demonstrated. Durations are indicative and vary with cohort experience.

  1. Secure boot chain of trust

    advanced

    Build and verify a signed bootloader with rollback protection.

    Duration
    5 hours
  2. SecOC on a CAN bus

    advanced

    Add authentication and freshness to safety-relevant CAN frames.

    Duration
    4 hours

Learning outcomes

What You Can Demonstrate Afterwards

An at-a-glance summary — each item is expanded in the sections above and below.

Skills acquired

2

Assessed competencies, listed in full under Overview above.

Capability levels
L3 · Secure DeveloperL6 · Leader
Programs supported

4

Listed with their capability level in the next section.

Capability framework

Where This Lab Sits in the Framework

All six levels, and this lab’s relationship to each — including the ones it deliberately does not cover.

  1. Not covered

    Level 1 · Awareness

    Cybersecurity Awareness

    Covered by other labs in the estate

  2. Not covered

    Level 2 · Compliance

    Compliance Practitioner

    Covered by other labs in the estate

  3. Supported

    Level 3 · Secure Developer

    Build secure ECU software, crypto stack integration, SecOC, Secure Boot and HSM skills.

  4. Not covered

    Level 4 · Validation

    Security Validation Specialist

    Covered by other labs in the estate

  5. Not covered

    Level 5 · Offensive

    Offensive Security Expert

    Covered by other labs in the estate

  6. Supported

    Level 6 · Leader

    Lead CSMS transformation, security governance and enterprise capability programmes.

Common questions

AutoSec Secure Development Lab FAQ

What engineers and their managers ask before booking lab time.

What programming experience does the lab assume?
Working embedded C and comfort with a debugger. Cryptographic background is not assumed — key hierarchies and primitives are taught from the automotive constraint outward rather than from the mathematics.
Why does timing come up so often?
Because it is the constraint that defeats most first implementations. A body controller may have tens of milliseconds before it must respond on the bus, and serial verification of a large image does not fit. The lab makes you solve that rather than describe it.
Is the hardware the same as production silicon?
Production-representative evaluation hardware with the same security features. Engineering samples behave differently from production parts in exactly the areas that matter — debug locking in particular — and the lab covers where those differences bite.

Get Your Engineers Into the AutoSec Secure Development Lab

Lab access is included with the programs above, and can be delivered onsite, remotely or as part of a corporate academy.