Sr. Staff Firmware Security Architect

We are looking for the best

About Us

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.

About the Role

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 bootloader 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 Co-Engineering: Work with the platform safety lead so that security mechanisms — all ASIL-D code on this platform — carry their own safety analysis (freedom from interference, WCET, fault handling), and the safety case and the cybersecurity case never contradict each other.

• Review Authority: Write testable security requirements into the platform's traceability system, review boot-chain and update-client implementation against them at code level, scope and adjudicate penetration tests, and gate release.

• Vulnerability Response & Suppliers: Stand up the platform's vulnerability-handling and PSIRT interface for the product's field life, and own the security requirements flowed to suppliers building on the platform.

Qualifications

• Tenure: 15+ years in embedded or firmware engineering, at least 6 of them owning embedded or product security.

• <