Open Points & Customer Clarifications
Product and cybersecurity architecture understanding package generated from Markdown-derived requirements.
Executive Takeaway
Open points are the customer-decision backlog for the ECA ECU proposal. They protect the baseline from silently accepting unclear diagnostics, update, PKI, secure communication, TARA, or CIA/RASIC responsibility assumptions.
- High-priority items should be answered before agreement baseline.
- Each open point states the customer decision needed, why it matters, the unresolved impact, and the recommended supplier position.
Open Points Summary
| Status | Count | Next Action |
|---|---|---|
| Open | 9 | Send to customer / capture decision |
Open Points Register
| Open Point ID | Topic | Question | Required Customer Decision | Impact | Recommended Supplier Position | Owner | Status | Related Requirements |
|---|---|---|---|---|---|---|---|---|
| OP-001 | ECU designation, variant and item definition for TARA | Confirm the exact ECU designation/variant and the agreed item definition and boundary used for the risk analysis (TARA). | Confirm the exact ECU designation/variant and the agreed item definition and boundary used for the risk analysis (TARA). | TARA scope and effort stay open; downstream assets, goals and design may rework. | Proceed on the working ECA-ECU interpretation; flag every TARA-scope statement as assumption until confirmed. | OEM / Customer | Open | 3 |
| OP-002 | Diagnostic security role model and service authorization | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy. | Security-access design and verification scope cannot be frozen; risk of an unprotected diagnostic service. | Implement configurable session/security-access on the ECU and request the customer-confirmed service-to-role table. | Shared (OEM policy / Supplier ECU) | Open | 79 |
| OP-003 | Key and certificate ownership, provisioning and lifecycle | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | ECU secure-storage and provisioning design is blocked; production-line and PKI dependencies stay open. | Provide ECU-side secure storage and provisioning hooks; require OEM confirmation of PKI ownership and the provisioning interface. | OEM / Customer (PKI) + Supplier (ECU) | Open | 20 |
| OP-004 | Secure software update / backend campaign responsibility | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. | Update-control scope and evidence ownership stay open; risk of an unprotected update path. | Implement authenticated, integrity-protected ECU programming with controlled boot/app state; require OEM update-chain definition. | Shared (OEM backend / Supplier ECU) | Open | 20 |
| OP-005 | Secure on-board communication (SecOC/SDT) signal allocation | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication. | Protected-signal design, key needs and runtime budget stay open; risk of unprotected critical signals. | Support SecOC/SDT in the platform and request the customer-confirmed protected-signal list and freshness policy. | OEM / Customer | Open | 37 |
| OP-009 | Cybersecurity work products, DIA and responsibility split | Confirm the DIA / responsibility (RASIC/CIA) split for each cybersecurity work product before supplier scope is fixed. | Confirm the DIA / responsibility (RASIC/CIA) split for each cybersecurity work product before supplier scope is fixed. | Without an agreed DIA the supplier risks owning customer work products or leaving cybersecurity gaps in the case. | Deliver supplier-owned work products per concept; require a signed DIA/RASIC before treating shared items as supplier scope. | OEM / Customer + Supplier (DIA) | Open | 1 |
| OP-006 | Incident response and vulnerability management ownership | Confirm the split of monitoring, triage, vulnerability handling and field response between OEM PSIRT and supplier. | Confirm the split of monitoring, triage, vulnerability handling and field response between OEM PSIRT and supplier. | Lifecycle effort and field-response capability stay unbounded; risk of an R155 compliance gap. | Define supplier vulnerability handling and field-fix capability; require OEM confirmation of monitoring/communication ownership. | OEM / Customer (fleet) + Supplier (ECU) | Open | 1 |
| OP-008 | Production, development and debug-interface hardening | Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy). | Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy). | Hardware fusing and EOL process design stay open; risk of an exposed debug/production interface. | Apply debug lock and secured production access; request the customer-confirmed production-security and EOL requirements. | Shared (OEM process / Supplier ECU) | Open | 2 |
| OP-011 | Document-specific scope and responsibility confirmation | Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. | Decide whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context. | Supplier position, estimation, and affected design allocation remain conditional for the listed requirements. | Carry the items as customer-confirmation dependencies and review them in the next clarification workshop. | OEM / Customer | Open | 4 |
Document Traceability
Open Point Detail
OP-001 — ECU designation, variant and item definition for TARA (High)
Question: Confirm the exact ECU designation/variant and the agreed item definition and boundary used for the risk analysis (TARA).
Why it matters: The item definition fixes the scope of the whole cybersecurity case; without it, assets, goals and effort cannot be frozen.
Required customer decision: Confirm the exact ECU designation/variant and the agreed item definition and boundary used for the risk analysis (TARA).
Impact if unresolved: TARA scope and effort stay open; downstream assets, goals and design may rework.
Recommended supplier position: Proceed on the working ECA-ECU interpretation; flag every TARA-scope statement as assumption until confirmed.
Owner: OEM / Customer · Status: Open · Target: TBD
Related requirements: REQ-AUTO-00634;REQ-AUTO-00873;REQ-AUTO-00876
OP-002 — Diagnostic security role model and service authorization (High)
Question: Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.
Why it matters: Diagnostic access is a primary attack surface; authorization scope drives security access design and verification effort.
Required customer decision: Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.
Impact if unresolved: Security-access design and verification scope cannot be frozen; risk of an unprotected diagnostic service.
Recommended supplier position: Implement configurable session/security-access on the ECU and request the customer-confirmed service-to-role table.
Owner: Shared (OEM policy / Supplier ECU) · Status: Open · Target: TBD
Related requirements: REQ-AUTO-00282;REQ-AUTO-00299;REQ-AUTO-00310;REQ-AUTO-00333;REQ-AUTO-00334;REQ-AUTO-00350;REQ-AUTO-00366;REQ-AUTO-00377;REQ-AUTO-00411;REQ-AUTO-00412;REQ-AUTO-00413;REQ-AUTO-00442;REQ-AUTO-00450;REQ_UDS-0001;REQ_UDS-0047;REQ_UDS-0051;REQ_UDS-0338;REQ_UDS-0060;REQ_UDS-0063;REQ_UDS-0065;REQ_UDS-0067;REQ_UDS-0068;REQ_UDS-0071;REQ-AUTO-00578;REQ_UDS-0075;REQ_UDS-0076;REQ_UDS-0250;REQ_UDS-0082;REQ_UDS-0083;REQ_UDS-0089;REQ_UDS-0108;REQ_UDS-0109;REQ_UDS-0111;REQ_UDS-0112;REQ_UDS-0128;REQ_UDS-0158;REQ_UDS-0160;REQ_UDS-0170;REQ_UDS-0171;REQ_UDS-0172;REQ-AUTO-00733;REQ_UDS-0183;REQ_UDS-0185;REQ_UDS-0186;REQ_UDS-0187;REQ_UDS-0188;REQ_UDS-0190;REQ_UDS-0194;REQ_UDS-0202;REQ_UDS-0212;REQ_UDS-0223;REQ_UDS-0225;REQ_UDS-0227;REQ_UDS-0229;REQ_UDS-0230;REQ-AUTO-00789;REQ-AUTO-00804;REQ-AUTO-00806;REQ-AUTO-00808;REQ-AUTO-00810;REQ-AUTO-00814;REQ-AUTO-00817;REQ-AUTO-00820;REQ-AUTO-00821;REQ-AUTO-00832;REQ-AUTO-00833;REQ-AUTO-00834;REQ-AUTO-00835;REQ-AUTO-00837;REQ-AUTO-00889;REQ-AUTO-00890;REQ-AUTO-00892;REQ-AUTO-00910;REQ-AUTO-00962;REQ-AUTO-00964;REQ-AUTO-00967;REQ-AUTO-00973;REQ-AUTO-00994;REQ-AUTO-00995
OP-003 — Key and certificate ownership, provisioning and lifecycle (High)
Question: Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier.
Why it matters: Key lifecycle responsibility determines ECU storage requirements, provisioning interfaces and production-line dependencies.
Required customer decision: Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier.
Impact if unresolved: ECU secure-storage and provisioning design is blocked; production-line and PKI dependencies stay open.
Recommended supplier position: Provide ECU-side secure storage and provisioning hooks; require OEM confirmation of PKI ownership and the provisioning interface.
Owner: OEM / Customer (PKI) + Supplier (ECU) · Status: Open · Target: TBD
Related requirements: REQ_SEC_0016;REQ-AUTO-00818;REQ-AUTO-00893;REQ-AUTO-00895;REQ-AUTO-00900;REQ-AUTO-00901;REQ-AUTO-00906;REQ-AUTO-00907;REQ-AUTO-00908;REQ-AUTO-00935;REQ-AUTO-00937;REQ-AUTO-00938;REQ-AUTO-00939;REQ-AUTO-00940;REQ-AUTO-00942;REQ-AUTO-00950;REQ-AUTO-00951;REQ-AUTO-00953;REQ-AUTO-00960;REQ-AUTO-00982
OP-004 — Secure software update / backend campaign responsibility (High)
Question: Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied.
Why it matters: Update is a high-impact attack surface; the backend/ECU split decides which controls and evidence the supplier must deliver.
Required customer decision: Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied.
Impact if unresolved: Update-control scope and evidence ownership stay open; risk of an unprotected update path.
Recommended supplier position: Implement authenticated, integrity-protected ECU programming with controlled boot/app state; require OEM update-chain definition.
Owner: Shared (OEM backend / Supplier ECU) · Status: Open · Target: TBD
Related requirements: REQ-AUTO-00078;REQ-AUTO-00306;REQ-AUTO-00313;REQ-AUTO-00317;REQ-AUTO-00329;REQ-AUTO-00330;REQ-AUTO-00348;REQ-AUTO-00367;REQ-AUTO-00373;REQ-AUTO-00375;REQ-AUTO-00429;REQ-AUTO-00440;REQ-AUTO-00448;REQ-AUTO-00561;REQ-AUTO-00636;REQ-AUTO-00922;REQ-AUTO-00924;REQ-AUTO-00925;REQ-AUTO-00930;REQ-AUTO-00931
OP-005 — Secure on-board communication (SecOC/SDT) signal allocation (High)
Question: Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication.
Why it matters: Communication protection allocation drives CAN matrix changes, key needs and runtime budget; it cannot be inferred safely.
Required customer decision: Confirm which signals/PDUs require SecOC/SDT, the freshness scheme, and the key distribution for protected communication.
Impact if unresolved: Protected-signal design, key needs and runtime budget stay open; risk of unprotected critical signals.
Recommended supplier position: Support SecOC/SDT in the platform and request the customer-confirmed protected-signal list and freshness policy.
Owner: OEM / Customer · Status: Open · Target: TBD
Related requirements: REQ-AUTO-00997;REQ-AUTO-01000;REQ-AUTO-01002;REQ-AUTO-01003;REQ-AUTO-01006;REQ-AUTO-01007;REQ-AUTO-01012;REQ-AUTO-01014;REQ-AUTO-01016;REQ-AUTO-01017;REQ-AUTO-01022;REQ-AUTO-01023;REQ-AUTO-01034;REQ-AUTO-01035;REQ-AUTO-01036;REQ-AUTO-01037;REQ-AUTO-01038;REQ-AUTO-01041;REQ-AUTO-01042;REQ-AUTO-01051;REQ-AUTO-01052;REQ-AUTO-01053;REQ-AUTO-01054;REQ-AUTO-01057;REQ-AUTO-01058;REQ-AUTO-01059;REQ-AUTO-01060;REQ-AUTO-01061;REQ-AUTO-01062;REQ-AUTO-01063;REQ-AUTO-01064;REQ-AUTO-01065;REQ-AUTO-01066;REQ-AUTO-01067;REQ-AUTO-01068;REQ-AUTO-01075;REQ-AUTO-01076
OP-009 — Cybersecurity work products, DIA and responsibility split (High)
Question: Confirm the DIA / responsibility (RASIC/CIA) split for each cybersecurity work product before supplier scope is fixed.
Why it matters: ISO 21434 work-product ownership must be agreed; otherwise the supplier may carry OEM-owned obligations or leave gaps.
Required customer decision: Confirm the DIA / responsibility (RASIC/CIA) split for each cybersecurity work product before supplier scope is fixed.
Impact if unresolved: Without an agreed DIA the supplier risks owning customer work products or leaving cybersecurity gaps in the case.
Recommended supplier position: Deliver supplier-owned work products per concept; require a signed DIA/RASIC before treating shared items as supplier scope.
Owner: OEM / Customer + Supplier (DIA) · Status: Open · Target: TBD
Related requirements: REQ-AUTO-00691
OP-006 — Incident response and vulnerability management ownership (Medium)
Question: Confirm the split of monitoring, triage, vulnerability handling and field response between OEM PSIRT and supplier.
Why it matters: Post-SOP cybersecurity obligations (UNECE R155 / ISO 21434 clause 7) need a clear owner to bound lifecycle effort.
Required customer decision: Confirm the split of monitoring, triage, vulnerability handling and field response between OEM PSIRT and supplier.
Impact if unresolved: Lifecycle effort and field-response capability stay unbounded; risk of an R155 compliance gap.
Recommended supplier position: Define supplier vulnerability handling and field-fix capability; require OEM confirmation of monitoring/communication ownership.
Owner: OEM / Customer (fleet) + Supplier (ECU) · Status: Open · Target: TBD
Related requirements: REQ_SEC_0034
OP-008 — Production, development and debug-interface hardening (Medium)
Question: Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy).
Why it matters: Production and debug interfaces are a common attack surface; expectations drive hardware fusing and EOL process design.
Required customer decision: Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy).
Impact if unresolved: Hardware fusing and EOL process design stay open; risk of an exposed debug/production interface.
Recommended supplier position: Apply debug lock and secured production access; request the customer-confirmed production-security and EOL requirements.
Owner: Shared (OEM process / Supplier ECU) · Status: Open · Target: TBD
Related requirements: REQ_SEC_0026;REQ-AUTO-00321
OP-011 — Document-specific scope and responsibility confirmation (Medium)
Question: Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline.
Why it matters: These requirements affect supplier proposal scope, traceability status, and effort assumptions but do not map cleanly to a predefined decision topic.
Required customer decision: Decide whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context.
Impact if unresolved: Supplier position, estimation, and affected design allocation remain conditional for the listed requirements.
Recommended supplier position: Carry the items as customer-confirmation dependencies and review them in the next clarification workshop.
Owner: OEM / Customer · Status: Open · Target: TBD
Related requirements: REQ-AUTO-00006;REQ-AUTO-00146;REQ-AUTO-00488;REQ-AUTO-00866