Nearly every vendor pitching for automotive embedded engineering work can point to an ISO 26262 or ISO 21434 certificate on a slide. That certificate proves a process framework exists somewhere in the organization — it doesn't prove the team in front of you has actually delivered a shipping ECU, closed out a real safety case, or handled a cybersecurity assessment under program pressure. Choosing an automotive software partner well means going past the certificate list and asking the harder, more specific questions that actually separate a team with genuine automotive delivery experience from one that has recently added automotive to its capability slide.
An ISO 26262 or ISO 21434 certification, whether it's a formal certificate or a process-maturity assessment, demonstrates that an organization's documented process meets the standard's structural requirements. What it does not demonstrate is execution quality: whether the same organization has actually run that process on a real ECU program, under real schedule and supplier pressure, and produced a safety case or cybersecurity argument an assessor genuinely accepted rather than one that technically checked the required boxes. Certificates are a floor, not a signal of depth, and treating them as sufficient due diligence is exactly the gap a genuinely rigorous evaluation process needs to close.
Technical due diligence for evaluating an automotive embedded engineering partner starts by asking for specifics a marketing deck won't volunteer: which ECU domains has the team actually shipped code into — powertrain, body, ADAS, infotainment — and at what SOP volume? What protocol stacks have they implemented from scratch versus integrated from a supplier's existing stack? Technical due diligence for evaluating an automotive embedded engineering partner also means asking to speak with the actual engineers who would work on the program, not only the account team that closes the deal, since a team's real depth is far easier to assess in a technical conversation than in a capabilities presentation.
What to check beyond an iso 26262/21434 certificate list includes asking a partner to walk through an actual hazard analysis and risk assessment (HARA) or TARA they led, not a generic template, and to explain how a specific safety goal or security control traced through to implementation and test evidence in a real program. What to check beyond an ISO 26262/21434 certificate list also includes asking how the partner has handled an assessor's pushback or a failed audit finding in the past — how a team responds when a safety case isn't accepted on the first pass reveals far more about real capability than a clean, uncontested certification ever will.
A safety case is an argument, not a checklist, and building one that survives an independent assessor's scrutiny takes a different skill than following a documented process template. Embien's own approach to this, detailed in building the ISO 26262 safety case argument, is a useful reference point for what a genuinely assessor-ready safety case actually requires versus what a process-compliant but argumentatively thin one looks like. The same distinction applies to cybersecurity, where Embien's guide to ISO 21434, TARA, and CSMS covers what a real, defensible TARA has to demonstrate beyond simply having run the process.
Questions to ask about a partner's real ecu and protocol-stack delivery history should press for specifics: which CAN, LIN, Ethernet, or diagnostic protocol stacks has the team built and validated against real hardware, on what MCU or SoC families, and shipped into what production volume? A team with genuine delivery history answers these questions with program names, hardware platforms, and specific technical tradeoffs they made — a team newer to the space tends to answer in more general, capability-statement language that doesn't get more specific under follow-up questioning.
Signs a vendor is newer to automotive than their marketing suggests are usually visible once you push past the first slide: certifications listed without any named program the certification was applied to, safety or security case examples that stay generic rather than citing a specific hazard or threat scenario the team actually worked through, and an inability to name the specific tooling (a particular static analysis suite, a specific AUTOSAR stack vendor, a named HIL rig) the team has hands-on experience with. None of these signs alone is disqualifying, but a pattern of vague answers across several of them is a reasonable basis for more scrutiny before committing a program to a partner.
A well-scoped proof-of-concept engagement is one of the most reliable ways to validate everything the due-diligence conversation surfaced, because it forces a prospective automotive software partner to demonstrate real delivery against a small, concrete piece of the actual program rather than a generic demo. A proof of concept worth running should touch the specific protocol stack, hardware platform, and safety or security process the full program will actually need, and it should be evaluated not just on whether it worked, but on how the partner's team communicated tradeoffs, handled a problem that came up mid-engagement, and documented what they delivered.
Embien Technologies works as an automotive software partner across ECU architecture, functional safety, and cybersecurity engineering, backed by a track record of shipped ECU programs and closed-out safety cases rather than certification alone. Teams evaluating a partner for their own program can see that delivery history reflected directly in Embien's automotive engineering services.
Embien's Edge Computing Services support embedded platforms, real-time processing, and hardware-software integration for automotive and other connected applications.
Embien supports automotive cybersecurity through threat analysis, secure boot, secure firmware updates, security assessments, and protection of connected vehicle systems.
A case study on developing a commercial vehicle instrument cluster using the Renesas RL78 MCU, focusing on embedded software and vehicle display functionality.