layiq

/la·yiq/adjective

worthy; deserving; fitting; suitable.

A role, opportunity, or path that merits attention, time, and pursuit.

LAYIQ - Sr. Staff Firmware Security Architect (Domain Security — Secure Boot, OTA & Vehicle Cybersecurity) at 42dot

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.

Sr. Staff Firmware Security Architect (Domain Security — Secure Boot, OTA & Vehicle Cybersecurity)

Employer job description

About Us

About the Role

Responsibilities

Qualifications

Preferred Qualifications

Compensation

About 42dot Way →

Equal opportunity and accommodations

About this listing

Listing check

Similar jobs

Similar jobs