Introduction
Over the last several months, I’ve been working deeply with two industries that historically spoke different languages: automotive safety and aviation design assurance.
What surprised me: when you look at the engineering required for secure software delivery in their highest safety tiers, ASIL-D (Automotive Safety Integrity Level D) and DAL-A (Design Assurance Level A), the systems are effectively the same.
Standards bodies in both domains are now explicitly cross-referencing each other. This is a deliberate recognition of the rigor necessary for software-defined safety operating at fleet scale.
This post explains:
- Why automotive and aviation converged
- What the modern secure delivery architecture looks like
- Which controls are identical vs. differently labeled
- What each industry can learn from the other
- Why this matters for certification, talent, and hiring
Why Convergence Happened
Historically, automotive and aviation had different assumptions:
| Industry | Past Assumption |
|---|---|
| Automotive | Software is a performance feature bolted onto mechanical safety |
| Aviation | Software supports but does not control physical flight mechanisms |
Those assumptions collapsed:
- Software directly controls safety outcomes
Brake-by-wire and fly-by-wire architectures made software a single point of failure. - Long-lifecycle assets require secure updates
Vehicles and aircraft must receive trustworthy updates for 15–20+ years. - Regulators recognized updates as a persistent attack surface
Cybersecurity is now inside the safety case.
As a result:
- Automotive: UN R155/R156 made cybersecurity and update management mandatory for type approval.
- Aviation: DO-326A/356A introduced cybersecurity artifacts into the certification basis.
Every software update must be cryptographically controlled, verifiable, and reversible without bricking fleets.
Standards Cross-Referencing
This convergence is codified:
- ISO/SAE 21434 references aviation security concepts from DO-326A
- DO-356A incorporates safety principles from ISO 26262
- eVTOL certification guidance borrows from automotive OTA security practice
Different roots. Same alignment.
Requirements Are Effectively the Same
When aligned by engineering controls, the equivalence becomes obvious:
| Concern | Automotive (ASIL-D) | Aviation (DAL-A) |
|---|---|---|
| Functional Safety | ISO 26262 | DO-178C |
| Cybersecurity | ISO/SAE 21434 + UN R155/R156 | DO-326A / DO-356A + DO-355A |
| Digital Signature Algorithms | e.g., RSA-3072 / ECDSA P-384 | ARINC 835 (same families) |
| Private Key Protection | HSM (FIPS 140-2/3) | HSM (FIPS 140-2/3) + offline custody |
| Revocation | CRL or OCSP | CRL or OCSP |
| Rollback Protection | Monotonic counter | Monotonic counter |
Different paperwork, same controls.
The cryptographic trust model is shared.
The Modern Secure Delivery Architecture
Here's an example architecture that meets both ASIL-D and DAL-A expectations for secure software delivery.
 |
| Figure 1: PKI-based secure delivery architecture supporting ASIL-D and DAL-A compliance. |
At a high level:
- An offline Root CA anchors trust, with tightly controlled ceremonies
- An HSM-protected Code-Signing CA issues signatures on release artifacts
- A revocation service distributes CRLs/OCSP responses
- Updates are distributed over UPTANE, ARINC 615A/827, or equivalent secure loaders
- The target ECU/LRU (Electronic Control Unit / Line Replaceable Unit):
- Verifies signature against a burned-in root public key
- Checks revocation status
- Enforces anti-rollback via monotonic counters
- Uses atomic install with dual-bank fallback
- Enforces secure boot on every power cycle
Every update package is treated as hostile until proven otherwise.
UPTANE dominates automotive OTA distribution. Aviation reaches the same controls via ARINC loaders and DO-326A artifacts. These are different implementation paths with the same trust requirements.
What Each Industry Gets Right
Aviation strengths
- Rigor in independent verification (no self-approval)
- Hardware-enforced rollback counters per critical module
- Zero tolerance for dead code in certified builds
Automotive strengths
- Mature SBOM workflows (CycloneDX / in-toto)
- Proven million-unit OTA rollout practices
- Faster iteration in cybersecurity management systems (CSMS)
Risk-Based Assurance: A Shared Language
| Level | Automotive | Aviation | Failure Condition |
|---|---|---|---|
| 4 | ASIL-D | DAL-A | Multiple fatalities, loss of vehicle/aircraft |
| 3 | ASIL-C | DAL-B | Single fatality / severe injury |
| 2 | ASIL-B | DAL-C | Mission abort / serious injury |
| 1 | ASIL-A | DAL-D | Minor injury / inconvenience |
| 0 | QM | DAL-E | No safety effect |
Certification Implications
If your secure delivery process is already approved for ASIL-D + ISO/SAE 21434 + UN R155 compliance, or DAL-A + DO-326A + ARINC 835 compliance — then you are very close to certification in the other domain.
Benefits of convergence:
- Faster multi-market productization
- Shared platform for PKI, SBOM, and secure boot
- Consolidated supplier requirements
- Broader talent mobility
The architecture is the same.
The talent pipeline is not.
Standards Ecosystem Alignment
 |
| Figure 3: Explicit cross-referencing across automotive and aviation security and safety standards. |
This map shows, at a glance:
- ISO 26262 and DO-178C as the functional safety backbone
- ISO/SAE 21434, UN R155/R156, DO-326A, DO-356A, and DO-355A framing cybersecurity
- Cross-reference arrows where one standard family borrows from or references the other
Conclusion
Automotive is becoming more like aviation — safety-critical actuators everywhere.
Aviation is becoming more like automotive — connected fleets with continuous updates.
The industry has already created common roots in a similar architecture.
If you are designing or certifying secure update pipelines in either domain and want to sanity-check your approach against both ecosystems, I’m always open to a conversation.
Where else are you seeing this convergence?
- Medical: IEC 62304 + IEC 80001-1 + FDA cyber guidance
- ICS: IEC 62443 + IEC 61508/61511
- Rail: EN 50128 + TS 50701
Secure, cryptographically controlled updates are becoming universal in safety-critical systems.
