Sr. Firmware Security Architect; Domain Security — Secure Boot, OTA & Vehicle Cybersecurity

42dot is a mobility AI company committed to solving mobility challenges with software and AI. As the Global Software Center of Hyundai Motor Group, 42dot pioneers the future of mobility by advancing the development of software-defined vehicles.

We develop safety-first, user-centric software-defined vehicle technologies that deliver the latest performance through continuous updates like smartphones. By advancing software and AI technology, 42dot envisions a world where everything is connected and moves autonomously through a self-managing urban transportation operating system.

As a Sr. Staff Firmware Security Architect, you will own the security architecture of our next-generation Software-Defined Vehicle (SDV) real-time platform end to end: the secure boot chain, the Uptane-based over-the-air update trust model, vehicle-lifecycle key management, secure diagnostics and debug, and the ISO/SAE 21434 work products that carry all of it through UNECE R155/R156 type approval. This is a builder's architect role: you decide what the boot chain and update client must do, prove it is enough, hold review authority over the engineers who implement it, and defend the design to OEM security engineers and third-party assessors.

Responsibilities

• Chain-of-Trust Architecture: Define the multi-stage secure boot sequence — boot ROM handoff, immutable and mutable boot loader stages, signature verification anchored in the hardware security engine, anti-rollback, A/B activation, recovery and fail-safe boot policy — with boot-time budgets that respect the platform's safety timing.

• Uptane Trust Model: Own the on-device Uptane security design: the online Director and offline-keyed Image repositories, metadata and role structure (Root, Timestamp, Snapshot, Targets), signature thresholds and key rotation, full-verification Primary versus partial-verification Secondary policy, and defenses against rollback, freeze, replay and mix-and-match attacks — for field campaigns and for the platform's own CI/CD path.

• Hardware Root of Trust & Key Management: Specify the key hierarchy, secure key storage and device attestation, end-of-line provisioning, secure debug lock/unlock and RMA re-provisioning, revocation and rotation, and the signing infrastructure and key-ceremony requirements the release process must follow.

• Cryptographic Policy: Own algorithm selection, key sizes and crypto-agility, including a post-quantum migration path for firmware signing across a vehicle's service life.

• Cloud & Fleet Interfaces: Author the platform's Uptane deployment profile (POUF) and co-design the edge-to-cloud interfaces with the Cloud/Infrastructure team: secure time attestation for Secondaries without a trusted clock, vehicle version manifests, and campaign and bundle integrity rules.

• Isolation & Defensive Engineering: Define the hardware-enforced isolation policy (resource-domain and MPU partitioning) between boot stages, security services and application code, and the threat model and countermeasure requirements for physical and electrical attack vectors — voltage and clock glitching, fault injection and side channels.

• Secure Diagnostics & Communication: Define security-access and reprogramming policy for the diagnostic path where OEM service processes require it, and the authentication and freshness scheme for safety-relevant traffic on the in-vehicle network and middleware.

• ISO/SAE 21434 & Regulation: Author the platform TARA, cybersecurity concept and cybersecurity case; determine CALs; produce the evidence the OEM's CSMS (UNECE R155) and SUMS (UNECE R156, ISO 24089) processes require from the platform; ensure compliance with OEM HSM and key-management specifications.

• Safety–Security…