Document Purpose
Confirmed by requirements: this cybersecurity requirement standard contributes 62 Markdown-derived RFQ requirements with the strongest evidence in core eca system behavior.
1001379436_P10_000_01_RDDM-1140152501-1744
Product and cybersecurity architecture understanding package generated from Markdown-derived requirements.
1001379436_P10_000_01_RDDM-1140152501-1744
Cybersecurity Requirement Standard · Cybersecurity · Core ECA system behavior
Executive Takeaway
Confirmed by requirements: this cybersecurity requirement standard contributes 62 Markdown-derived RFQ requirements with the strongest evidence in core eca system behavior. Inferred from requirement pattern: for RFQX it affects the Electric Clutch Actuator ECU on the TRATON GW AMT platform by shaping core eca system behavior; responsibility and customer approval model; system architecture design.
Confirmed by requirements: supplier positioning is 14 accept; 41 accept with assumption; 4 partially accept; 1 needs customer clarification; 2 informational only. The generated traceability links this document to 16 supplier system requirement records. Inferred from mapped features, capabilities, and interfaces: the main design/security impact is core eca system behavior; responsibility and customer approval model; system architecture design. These themes should drive concept updates, verification evidence, and supplier proposal assumptions only where the linked requirements support them.
Requires customer confirmation: 4 document-linked open point(s) remain, mainly: Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier.; Confirm the split of monitoring, triage, vulnerability handling and field response between OEM PSIRT and supplier.; Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy). (showing 3 of 4). Do not convert these items into agreed baseline scope until the customer confirms the decision. Confidence and limits: High confidence. Evidence is limited to Markdown-derived requirements, registers, open points, and SSR links; no downstream PDF analysis or AI-generated conclusion is claimed.
Requirements62from this PDF
Critical5ranked
Open Points4linked
Derived SSRs16linked
Concept Impactyesdocument-specific
Estimation Impactyesdocument-specific
Document Abstract
Engineering Interpretation
Inferred from requirement pattern: for RFQX it affects the Electric Clutch Actuator ECU on the TRATON GW AMT platform by shaping core eca system behavior; responsibility and customer approval model; system architecture design.
Main Requirement Themes
Core ECA system behavior; Responsibility and customer approval model; System architecture design; Cybersecurity concept and evidence; Cybersecurity (showing 5 of 8)
System / Security Impact
Inferred from mapped features, capabilities, and interfaces: the main design/security impact is core eca system behavior; responsibility and customer approval model; system architecture design. These themes should drive concept updates, verification evidence, and supplier proposal assumptions only where the linked requirements support them.
Supplier Proposal Impact
Confirmed by requirements: supplier positioning is 14 accept; 41 accept with assumption; 4 partially accept; 1 needs customer clarification; 2 informational only. The generated traceability links this document to 16 supplier system requirement records.
Customer Clarification Impact
Requires customer confirmation: 4 document-linked open point(s) remain, mainly: Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier.; Confirm the split of monitoring, triage, vulnerability handling and field response between OEM PSIRT and supplier.; Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy). (showing 3 of 4). Do not convert these items into agreed baseline scope until the customer confirms the decision.
Confidence and Limits
Confidence and limits: High confidence. Evidence is limited to Markdown-derived requirements, registers, open points, and SSR links; no downstream PDF analysis or AI-generated conclusion is claimed.
Main Requirement Themes
| Theme | Engineering Meaning | Requirement Count | Representative Requirements |
|---|---|---|---|
| Core ECA system behavior | Defines actuator ECU behavior, drivetrain integration, electrical/mechanical constraints, and verification scope. | 46 | REQ_SEC_0002; REQ-AUTO-00004; REQ-AUTO-00005 |
| Responsibility and customer approval model | Creates supplier/OEM allocation decisions for work products, backend infrastructure, approvals, and residual risk. | 44 | REQ-AUTO-00001; REQ_SEC_0001; REQ_SEC_0002 |
| System architecture design | Groups related document requirements into a single engineering theme. | 35 | REQ-AUTO-00004; REQ-AUTO-00005; REQ-AUTO-00006 |
| Cybersecurity concept and evidence | Drives cybersecurity concept, risk treatment, verification evidence, and traceability obligations. | 29 | REQ-AUTO-00001; REQ_SEC_0001; REQ_SEC_0002 |
| Cybersecurity | Groups related document requirements into a single engineering theme. | 23 | REQ-AUTO-00001; REQ_SEC_0001; REQ_SEC_0002 |
| Cybersecurity control | Groups related document requirements into a single engineering theme. | 23 | REQ-AUTO-00001; REQ_SEC_0001; REQ_SEC_0002 |
| Cybersecurity verification report | Groups related document requirements into a single engineering theme. | 23 | REQ-AUTO-00001; REQ_SEC_0001; REQ_SEC_0002 |
| Security services | Groups related document requirements into a single engineering theme. | 23 | REQ-AUTO-00001; REQ_SEC_0001; REQ_SEC_0002 |
Document Content Structure
| Section | Requirements | Critical | Open Points | SSR Links |
|---|---|---|---|---|
| 1 Introduction | 1 | 0 | 0 | 1 |
| -- 1.4 Abbreviated terms | 1 | 0 | 0 | 1 |
| -- 2.1 Development process | 15 | 1 | 1 | 4 |
| -- -- 2.1.3 Cybersecurity concept | 6 | 1 | 1 | 3 |
| -- -- 2.1.5 Documentation | 9 | 0 | 0 | 2 |
| -- 2.2 System requirements | 7 | 0 | 0 | 4 |
| -- -- 2.2.3 Cryptographic libraries | 7 | 0 | 0 | 4 |
| -- 2.4 Information security | 9 | 1 | 1 | 4 |
| -- 2.6 Cybersecurity lifecycle | 30 | 3 | 2 | 13 |
| -- -- 2.6.1 Security updates | 8 | 1 | 1 | 3 |
| -- -- 2.6.3 Vulnerability management | 9 | 1 | 1 | 5 |
| -- -- 2.6.4 Product lifecycle | 8 | 0 | 0 | 6 |
| -- -- 2.6.5 Logging | 5 | 1 | 0 | 5 |
What This PDF Is About
| Field | Value |
|---|---|
| Source PDF | customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf |
| Converted Markdown | converted/markdown/1001379436_P10_000_01_RDDM-1140152501-1744.md |
| Document Type | Cybersecurity Requirement Standard |
| Domain | Cybersecurity |
| Scope Summary | 62 extracted requirements; 16 linked SSRs; 4 linked open points. |
| Main Themes | Core ECA system behavior; Responsibility and customer approval model; System architecture design; Cybersecurity concept and evidence; Cybersecurity (showing 5 of 8) |
| Does Not Confirm | Customer-owned responsibility, final customer decisions, and unresolved open points remain unconfirmed. |
| Confidence | High |
| Evidence Basis | Markdown-derived requirements and generated RFQX registers; no downstream PDF analysis. |
Key Conclusions From This PDF
- Confirmed by requirements: this cybersecurity requirement standard contributes 62 Markdown-derived RFQ requirements with the strongest evidence in core eca system behavior.
- Confirmed by requirements: supplier positioning is 14 accept; 41 accept with assumption; 4 partially accept; 1 needs customer clarification; 2 informational only. The generated traceability links this document to 16 supplier system requirement records.
- Requires customer confirmation: 4 document-linked open point(s) remain, mainly: Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier.; Confirm the split of monitoring, triage, vulnerability handling and field response between OEM PSIRT and supplier.; Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy). (showing 3 of 4). Do not convert these items into agreed baseline scope until the customer confirms the decision.
Critical Requirements
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| ID | Score | Category | Requirement / Reason | Supplier Position |
|---|---|---|---|---|
| REQ-AUTO-00006 | 95 | High risk due to unclear OEM/supplier responsibility | Note: The vehicle manufacturer and supplier shall collaboratively define the context of the system or function to enable the supplier performing the risk assessment.security relevant; architecture relevant; Needs Customer Clarification; linked open point; Unknown estimation impact; blocks SSR derivation | Needs Customer Clarification |
| REQ_SEC_0016 | 77 | High risk due to unclear OEM/supplier responsibility | Key management - It shall be possible for the vehicle manufacturer to securely inject key material and other data used for cybersecurity controls into the ECU according to the specification of the vehicle manufacturer.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Partially Accept |
| REQ_SEC_0026 | 63 | High risk due to unclear OEM/supplier responsibility | Only hardware interfaces and protocols specified by the vehicle manufacturer shall be available in series production.security relevant; architecture relevant; Partially Accept; linked open point | Partially Accept |
| REQ_SEC_0034 | 63 | High risk due to unclear OEM/supplier responsibility | Following each identified and reported vulnerability, the supplier and vehicle manufacturer shall agree on an initial response to the vulnerability.security relevant; architecture relevant; Partially Accept; linked open point | Partially Accept |
| REQ_SEC_0050 | 48 | High risk due to unclear OEM/supplier responsibility | Marcus Lindner EPXC Published 12(16) - All secrets specified by the vehicle manufacturer shall be protected throughout the lifecycle of the ECU.security relevant; architecture relevant; Partially Accept | Partially Accept |
| REQ-AUTO-00001 | 44 | High impact on cybersecurity concept/work products | The cybersecurity concept shall describe the scope of the risk analysis, risks that were identified during the risk analysis, cybe rsecurity goals, cybersecurity requirements, mitigation strategies, validation, and verification strategies, etc.security relevant; architecture relevant; High estimation impact | Accept with Assumption |
| REQ_SEC_0001 | 44 | High impact on cybersecurity concept/work products | Cybersecurity methods and strategies - The supplier shall provide documentation describing their strategies and methods for working with embedded systems cybersecurity.security relevant; architecture relevant; High estimation impact | Accept with Assumption |
| REQ_SEC_0002 | 44 | General project impact | Risk assessment - The supplier shall perform risk assessment based on a threat and vulnerability analysis for each release, including any vehicle manufacturer-specific adaptations.security relevant; architecture relevant; High estimation impact | Accept with Assumption |
| REQ_SEC_0003 | 44 | High impact on cybersecurity concept/work products | Cybersecurity concept - The supplier shall describe the cybersecurity concept and how it is implemented in hardware and software respectively.security relevant; architecture relevant; High estimation impact | Accept with Assumption |
| REQ_SEC_0022 | 44 | High impact on cybersecurity concept/work products | Marcus Lindner EPXC Published 6(16) - All risks identified in cybersecurity risk analyses shall be evaluated.security relevant; architecture relevant; High estimation impact | Accept with Assumption |
| REQ-AUTO-00009 | 44 | High impact on cybersecurity concept/work products | For each risk identified in the cybersecurity risk analyses, a risk treatment decision shall be made to avoid, reduce, share, or retain the risk.security relevant; architecture relevant; High estimation impact | Accept with Assumption |
| REQ_SEC_0023 | 44 | High impact on cybersecurity concept/work products | Cybersecurity controls shall sufficiently reduce the risk.security relevant; architecture relevant; High estimation impact | Accept with Assumption |
Customer Clarifications / Open Points
Total Open Points4document-linked
P10priority
P20priority
Blocking Conceptyesyes/no
Blocking Estimationyesyes/no
Blocking SSRyesyes/no
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| Open Point | Priority | Question / Impact | Required Customer Decision | Recommended Supplier Position | Owner | Status |
|---|---|---|---|---|---|---|
| OP-003 | 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. | Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier. | Provide ECU-side secure storage and provisioning hooks; require OEM confirmation of PKI ownership and the provisioning interface. | OEM / Customer (PKI) + Supplier (ECU) | Open | |
| OP-006 | 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. | Confirm the split of monitoring, triage, vulnerability handling and field response between OEM PSIRT and supplier. | Define supplier vulnerability handling and field-fix capability; require OEM confirmation of monitoring/communication ownership. | OEM / Customer (fleet) + Supplier (ECU) | Open | |
| OP-008 | 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. | Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy). | Apply debug lock and secured production access; request the customer-confirmed production-security and EOL requirements. | Shared (OEM process / Supplier ECU) | Open | |
| OP-011 | Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline.Supplier position, estimation, and affected design allocation remain conditional for the listed requirements. | Decide whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context. | Carry the items as customer-confirmation dependencies and review them in the next clarification workshop. | OEM / Customer | Open |
Requirements From This PDF
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| ID | Requirement / Proposal | Supplier Position | Review | Security Capability | Feature / Interface | SSR | Open Point | Source |
|---|---|---|---|---|---|---|---|---|
| REQ-AUTO-00006 | Note: The vehicle manufacturer and supplier shall collaboratively define the context of the system or function to enable the supplier performing the risk assessment.Proposal: Needs customer clarification. The requirement implies customer-owned infrastructure, approval, or a responsibility split that is not yet available. | Needs Customer Clarification | Reviewed Internally | None | Application software behavior OEM/Customer Review Interface | None | OP-011 | 2.1.3 Cybersecurity concept page 5 Source detailsDocument section 2.1.3 Cybersecurity concept Section path 2.1 Development process > 2.1.3 Cybersecurity concept Page reference page 5 |
| REQ_SEC_0016 | Key management - It shall be possible for the vehicle manufacturer to securely inject key material and other data used for cybersecurity controls into the ECU according to the specification of the vehicle manufacturer.Proposal: Needs customer clarification. Supplier can implement ECU-side certificate/key handling, but ownership of PKI, certificate provisioning, lifecycle management, and backend responsibility must be confirmed through CIA/RASIC. | Partially Accept | Proposal Ready | Key management | Key management OEM/Customer Review Interface | SSR-KEY-001 | OP-003 | 2.6.1 Security updates page 9 Source detailsDocument section 2.6.1 Security updates Section path 2.6 Cybersecurity lifecycle > 2.6.1 Security updates Page reference page 9 |
| REQ_SEC_0026 | Only hardware interfaces and protocols specified by the vehicle manufacturer shall be available in series production.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Hardware platform support OEM/Customer Review Interface | SSR-COM-001 | OP-008 | 2.4 Information security page 8 Source detailsDocument section 2.4 Information security Section path 2.4 Information security Page reference page 8 |
| REQ_SEC_0034 | Following each identified and reported vulnerability, the supplier and vehicle manufacturer shall agree on an initial response to the vulnerability.Proposal: Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Partially Accept | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-VIH-004 | OP-006 | 2.6.3 Vulnerability management page 10 Source detailsDocument section 2.6.3 Vulnerability management Section path 2.6 Cybersecurity lifecycle > 2.6.3 Vulnerability management Page reference page 10 |
| REQ_SEC_0050 | Marcus Lindner EPXC Published 12(16) - All secrets specified by the vehicle manufacturer shall be protected throughout the lifecycle of the ECU.Proposal: Partially accept. Supplier can implement the ECU-side behaviour, but OEM-owned backend/PKI/fleet responsibilities require customer confirmation. | Partially Accept | Proposal Ready | None | Hardware platform support OEM/Customer Review Interface | SSR-COM-001 | - | 2.6.5 Logging page 12 Source detailsDocument section 2.6.5 Logging Section path 2.6 Cybersecurity lifecycle > 2.6.5 Logging Page reference page 12 |
| REQ-AUTO-00001 | The cybersecurity concept shall describe the scope of the risk analysis, risks that were identified during the risk analysis, cybe rsecurity goals, cybersecurity requirements, mitigation strategies, validation, and verification strategies, etc.Proposal: Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Accept with Assumption | Proposal Ready | Cybersecurity requirement handling | Cybersecurity requirement handling; Security evidence and traceability OEM/Customer Review Interface | SSR-CON-001 | - | 1.4 Abbreviated terms page 3 Source detailsDocument section 1.4 Abbreviated terms Section path 1 Introduction > 1.4 Abbreviated terms Page reference page 3 |
| REQ_SEC_0001 | Cybersecurity methods and strategies - The supplier shall provide documentation describing their strategies and methods for working with embedded systems cybersecurity.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | Cybersecurity requirement handling | Cybersecurity requirement handling; Security evidence and traceability OEM/Customer Review Interface | SSR-CON-001 | - | 2.1.3 Cybersecurity concept page 5 Source detailsDocument section 2.1.3 Cybersecurity concept Section path 2.1 Development process > 2.1.3 Cybersecurity concept Page reference page 5 |
| REQ_SEC_0002 | Risk assessment - The supplier shall perform risk assessment based on a threat and vulnerability analysis for each release, including any vehicle manufacturer-specific adaptations.Proposal: Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Accept with Assumption | Proposal Ready | Vulnerability management | Vulnerability management OEM/Customer Review Interface | SSR-VIH-001 | - | 2.1.3 Cybersecurity concept page 5 Source detailsDocument section 2.1.3 Cybersecurity concept Section path 2.1 Development process > 2.1.3 Cybersecurity concept Page reference page 5 |
| REQ_SEC_0003 | Cybersecurity concept - The supplier shall describe the cybersecurity concept and how it is implemented in hardware and software respectively.Proposal: Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Accept with Assumption | Proposal Ready | Cybersecurity requirement handling | Cybersecurity requirement handling OEM/Customer Review Interface | SSR-CON-001 | - | 2.1.3 Cybersecurity concept page 5 Source detailsDocument section 2.1.3 Cybersecurity concept Section path 2.1 Development process > 2.1.3 Cybersecurity concept Page reference page 5 |
| REQ_SEC_0022 | Marcus Lindner EPXC Published 6(16) - All risks identified in cybersecurity risk analyses shall be evaluated.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | Cybersecurity requirement handling | Cybersecurity requirement handling None | SSR-CON-001 | - | 2.1.5 Documentation page 6 Source detailsDocument section 2.1.5 Documentation Section path 2.1 Development process > 2.1.5 Documentation Page reference page 6 |
| REQ-AUTO-00009 | For each risk identified in the cybersecurity risk analyses, a risk treatment decision shall be made to avoid, reduce, share, or retain the risk.Proposal: Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Accept with Assumption | Proposal Ready | Cybersecurity requirement handling | Cybersecurity requirement handling None | SSR-CON-001 | - | 2.1.5 Documentation page 6 Source detailsDocument section 2.1.5 Documentation Section path 2.1 Development process > 2.1.5 Documentation Page reference page 6 |
| REQ_SEC_0023 | Cybersecurity controls shall sufficiently reduce the risk.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | Cybersecurity requirement handling | Cybersecurity requirement handling None | SSR-CON-001 | - | 2.1.5 Documentation page 6 Source detailsDocument section 2.1.5 Documentation Section path 2.1 Development process > 2.1.5 Documentation Page reference page 6 |
| REQ-AUTO-00011 | It shall be possible to verify which cybersecurity controls were derived from which requirements.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | Cybersecurity requirement handling | Cybersecurity requirement handling None | SSR-CON-001 | - | 2.1.5 Documentation page 6 Source detailsDocument section 2.1.5 Documentation Section path 2.1 Development process > 2.1.5 Documentation Page reference page 6 |
| REQ_SEC_0024 | The cybersecurity concept of the supplier shall contain a documentation of the accepted residual risk and be agreed with the vehicle manufacturer.Proposal: Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Accept with Assumption | Proposal Ready | Cybersecurity requirement handling | Cybersecurity requirement handling; Security evidence and traceability OEM/Customer Review Interface | SSR-CON-001 | - | 2.1.5 Documentation page 6 Source detailsDocument section 2.1.5 Documentation Section path 2.1 Development process > 2.1.5 Documentation Page reference page 6 |
| REQ_SEC_0004 | Verification and validation - The supplier shall provide documentation of the verification and validation methods of cybersecurity features.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | Cybersecurity requirement handling | Cybersecurity requirement handling; Security evidence and traceability OEM/Customer Review Interface | SSR-CON-001 | - | 2.1.5 Documentation page 6 Source detailsDocument section 2.1.5 Documentation Section path 2.1 Development process > 2.1.5 Documentation Page reference page 6 |
| REQ_SEC_0005 | The supplier shall provide test reports detailing the results from the verification and validation of cybersecurity features.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | Cybersecurity requirement handling | Cybersecurity requirement handling; Security evidence and traceability OEM/Customer Review Interface | SSR-CON-001 | - | 2.1.5 Documentation page 6 Source detailsDocument section 2.1.5 Documentation Section path 2.1 Development process > 2.1.5 Documentation Page reference page 6 |
| REQ_SEC_0025 | Marcus Lindner EPXC Published 7(16) - A BOM containing part numbers and versions of hardware components used in the product shall be provided by the supplier.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | None | Hardware platform support OEM/Customer Review Interface | SSR-COM-001 | - | 2.2.3 Cryptographic libraries page 7 Source detailsDocument section 2.2.3 Cryptographic libraries Section path 2.2 System requirements > 2.2.3 Cryptographic libraries Page reference page 7 |
| REQ_SEC_0042 | The vehicle manufacturer and the supplier shall set up a cybersecurity DIA to agree on the responsibilities for the distributed cybersecurity activities.Proposal: Accept. Provide the cybersecurity concept as a supplier work product covering scope, assumptions, risk-treatment traceability, cybersecurity goals/requirements, mitigation strategy, V&V approach, and open responsibility dependencies. | Accept with Assumption | Proposal Ready | Cybersecurity requirement handling | Cybersecurity requirement handling OEM/Customer Review Interface | SSR-CON-001 | - | 2.2.3 Cryptographic libraries page 7 Source detailsDocument section 2.2.3 Cryptographic libraries Section path 2.2 System requirements > 2.2.3 Cryptographic libraries Page reference page 7 |
| REQ_SEC_0008 | Software security - The ECU shall be able to verify integrity and authenticity of a vehicle manufacturer-specified set of data stored within the ECU.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | Authentication | Authentication OEM/Customer Review Interface | SSR-DAI-001 | - | 2.2.3 Cryptographic libraries page 7 Source detailsDocument section 2.2.3 Cryptographic libraries Section path 2.2 System requirements > 2.2.3 Cryptographic libraries Page reference page 7 |
| REQ_SEC_0009 | Security architecture - The supplier shall apply methods for isolation of software/hardware components and data to reduce the effect in case of a cybersecurity breach.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | Cybersecurity requirement handling | Cybersecurity requirement handling OEM/Customer Review Interface | SSR-CON-001 | - | 2.2.3 Cryptographic libraries page 7 Source detailsDocument section 2.2.3 Cryptographic libraries Section path 2.2 System requirements > 2.2.3 Cryptographic libraries Page reference page 7 |
| REQ_SEC_0020 | Cryptographic libraries - Selection of cryptographic methods and their use shall be agreed upon between the vehicle manufacturer and the supplier.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-SYS-001 | - | 2.2.3 Cryptographic libraries page 7 Source detailsDocument section 2.2.3 Cryptographic libraries Section path 2.2 System requirements > 2.2.3 Cryptographic libraries Page reference page 7 |
| REQ_SEC_0012 | Interfaces - Communication interfaces shall use boundary controls such as ingress/egress filtering.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | None | System behavior None | SSR-SYS-001 | - | 2.4 Information security page 8 Source detailsDocument section 2.4 Information security Section path 2.4 Information security Page reference page 8 |
| REQ_SEC_0014 | Any interfaces used for development purposes shall be removed or disabled in series production.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | None | System behavior None | SSR-SYS-001 | - | 2.4 Information security page 8 Source detailsDocument section 2.4 Information security Section path 2.4 Information security Page reference page 8 |
| REQ_SEC_0027 | Information security - It shall be possible for the vehicle manufacturer to securely inject data into the product in accordance with the specification provided by the vehicle manufacturer.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | Cybersecurity requirement handling | Cybersecurity requirement handling OEM/Customer Review Interface | SSR-CON-001 | - | 2.4 Information security page 8 Source detailsDocument section 2.4 Information security Section path 2.4 Information security Page reference page 8 |
| REQ_SEC_0019 | Secrets, public keys and other data used for cybersecurity controls in production vehicle systems shall be different from those used in pre-production phases.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | Key management | Key management None | SSR-KEY-001 | - | 2.6.1 Security updates page 9 Source detailsDocument section 2.6.1 Security updates Section path 2.6 Cybersecurity lifecycle > 2.6.1 Security updates Page reference page 9 |
| REQ_SEC_0015 | ECUs shall conform to the harmonized Security Access specification [1] provided by the vehicle manufacturer.Proposal: Accept with assumption. Implement the ECU-side diagnostic behavior with configurable authorization and verification evidence, subject to customer-confirmed UDS service allocation and role model. | Accept with Assumption | Proposal Ready | Cybersecurity requirement handling | Cybersecurity requirement handling OEM/Customer Review Interface | SSR-CON-001 | - | 2.6.1 Security updates page 9 Source detailsDocument section 2.6.1 Security updates Section path 2.6 Cybersecurity lifecycle > 2.6.1 Security updates Page reference page 9 |
| REQ_SEC_0043 | Security updates - It shall be possible to update the software of the ECU.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | Cybersecurity requirement handling | Cybersecurity requirement handling None | SSR-CON-001 | - | 2.6.1 Security updates page 9 Source detailsDocument section 2.6.1 Security updates Section path 2.6 Cybersecurity lifecycle > 2.6.1 Security updates Page reference page 9 |
| REQ_SEC_0030 | Marcus Lindner EPXC Published 10(16) - The supplier shall inform the vehicle manufacturer if any cybersecurity patches are available.Proposal: Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Accept with Assumption | Proposal Ready | Cybersecurity requirement handling | Cybersecurity requirement handling OEM/Customer Review Interface | SSR-CON-001 | - | 2.6.3 Vulnerability management page 10 Source detailsDocument section 2.6.3 Vulnerability management Section path 2.6 Cybersecurity lifecycle > 2.6.3 Vulnerability management Page reference page 10 |
| REQ_SEC_0045 | In case of cybersecurity incidents, the incident response process shall be used.Proposal: Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Accept with Assumption | Proposal Ready | Incident response | Incident response None | SSR-VIH-003 | - | 2.6.3 Vulnerability management page 10 Source detailsDocument section 2.6.3 Vulnerability management Section path 2.6 Cybersecurity lifecycle > 2.6.3 Vulnerability management Page reference page 10 |
| REQ-AUTO-00051 | The information shall contain • the version(s) of affected hardware or software components, • nature of the vulnerability, • description of the affected cybersecurity goal, • technical conditions to exploit the vulnerability, • impact of the exploitation and • possibilities to remove the vulnerability.Proposal: Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Accept with Assumption | Proposal Ready | Vulnerability management | Vulnerability management None | SSR-VIH-001 | - | 2.6.4 Product lifecycle page 11 Source detailsDocument section 2.6.4 Product lifecycle Section path 2.6 Cybersecurity lifecycle > 2.6.4 Product lifecycle Page reference page 11 |
| REQ_SEC_0051 | Logging - Security related events shall be identified and logged.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | Logging and audit trail | Logging and audit trail None | SSR-LOG-001 | - | 2.6.5 Logging page 12 Source detailsDocument section 2.6.5 Logging Section path 2.6 Cybersecurity lifecycle > 2.6.5 Logging Page reference page 12 |
| REQ-AUTO-00005 | Documentation on the method and results shall be provided to the vehicle manufacturer.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | None | System behavior; Security evidence and traceability OEM/Customer Review Interface | SSR-SYS-001 | - | 2.1.3 Cybersecurity concept page 5 Source detailsDocument section 2.1.3 Cybersecurity concept Section path 2.1 Development process > 2.1.3 Cybersecurity concept Page reference page 5 |
| REQ_SEC_0007 | Documentation - An inventory of software and protocols, including their versions, shall be provided by the supplier.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | None | Application software behavior; Security evidence and traceability OEM/Customer Review Interface | SSR-SYS-007 | - | 2.1.5 Documentation page 6 Source detailsDocument section 2.1.5 Documentation Section path 2.1 Development process > 2.1.5 Documentation Page reference page 6 |
| REQ_SEC_0010 | Services - All network services implemented in the ECU shall undergo hardening.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | None | Hardware platform support None | SSR-PROD-001 | - | 2.4 Information security page 8 Source detailsDocument section 2.4 Information security Section path 2.4 Information security Page reference page 8 |
| REQ_SEC_0011 | The ECU shall only expose network and communication services that have been agreed upon with the vehicle manufacturer.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | None | Hardware platform support OEM/Customer Review Interface | SSR-COM-001 | - | 2.4 Information security page 8 Source detailsDocument section 2.4 Information security Section path 2.4 Information security Page reference page 8 |
| REQ_SEC_0013 | Communication boundary controls shall be configurable by the vehicle manufacturer.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-SYS-001 | - | 2.4 Information security page 8 Source detailsDocument section 2.4 Information security Section path 2.4 Information security Page reference page 8 |
| REQ-AUTO-00030 | The details shall be agreed upon between the vehicle manufacturer and the supplier.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-SYS-001 | - | 2.4 Information security page 8 Source detailsDocument section 2.4 Information security Section path 2.4 Information security Page reference page 8 |
| REQ_SEC_0021 | ECUs shall only contain the secrets agreed between the vehicle manufacturer and the supplier.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-SYS-001 | - | 2.6.1 Security updates page 9 Source detailsDocument section 2.6.1 Security updates Section path 2.6 Cybersecurity lifecycle > 2.6.1 Security updates Page reference page 9 |
| REQ_SEC_0044 | Incident management - An incident response process shall be proposed to and approved by the vehicle manufacturer.Proposal: Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Accept with Assumption | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-VIH-002 | - | 2.6.3 Vulnerability management page 10 Source detailsDocument section 2.6.3 Vulnerability management Section path 2.6 Cybersecurity lifecycle > 2.6.3 Vulnerability management Page reference page 10 |
| REQ_SEC_0046 | The incident response process shall be maintained for the entire product lifetime.Proposal: Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Accept with Assumption | Proposal Ready | None | System behavior None | SSR-VIH-002 | - | 2.6.3 Vulnerability management page 10 Source detailsDocument section 2.6.3 Vulnerability management Section path 2.6 Cybersecurity lifecycle > 2.6.3 Vulnerability management Page reference page 10 |
| REQ_SEC_0032 | The incident response process shall ensure that risk is managed in coordination with the vehicle manufacturer.Proposal: Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Accept with Assumption | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-VIH-002 | - | 2.6.3 Vulnerability management page 10 Source detailsDocument section 2.6.3 Vulnerability management Section path 2.6 Cybersecurity lifecycle > 2.6.3 Vulnerability management Page reference page 10 |
| REQ_SEC_0033 | Vulnerability management - Any vulnerabilities that are identified during product lifecycle shall be promptly communicated to the vehicle manufacturer.Proposal: Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Accept with Assumption | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-VIH-004 | - | 2.6.3 Vulnerability management page 10 Source detailsDocument section 2.6.3 Vulnerability management Section path 2.6 Cybersecurity lifecycle > 2.6.3 Vulnerability management Page reference page 10 |
| REQ_SEC_0035 | Marcus Lindner EPXC Published 11(16) - Within adequate time after the initial vulnerability report, the supplier shall provide more information about the identified vulnerability.Proposal: Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Accept with Assumption | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-VIH-004 | - | 2.6.4 Product lifecycle page 11 Source detailsDocument section 2.6.4 Product lifecycle Section path 2.6 Cybersecurity lifecycle > 2.6.4 Product lifecycle Page reference page 11 |
| REQ_SEC_0036 | The supplier shall have a method for monitoring available vulnerability databases for vulnerabilities that can affect the delivered product.Proposal: Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Accept with Assumption | Proposal Ready | None | External interfaces External Interfaces; OEM/Customer Review Interface | SSR-VIH-005 | - | 2.6.4 Product lifecycle page 11 Source detailsDocument section 2.6.4 Product lifecycle Section path 2.6 Cybersecurity lifecycle > 2.6.4 Product lifecycle Page reference page 11 |
| REQ_SEC_0037 | Identified vulnerabilities shall be considered in all current development projects or projects under field monitoring.Proposal: Accept with assumption. Supplier can provide vulnerability monitoring, reporting, and initial response process evidence; vehicle-level incident ownership and escalation path require customer confirmation. | Accept with Assumption | Proposal Ready | None | System behavior None | SSR-SYS-001 | - | 2.6.4 Product lifecycle page 11 Source detailsDocument section 2.6.4 Product lifecycle Section path 2.6 Cybersecurity lifecycle > 2.6.4 Product lifecycle Page reference page 11 |
| REQ_SEC_0048 | Field-return analysis secrets shall not be operational in the field.Proposal: Accept. Implement as part of the cybersecurity concept and map to verification evidence, assuming the customer confirms responsibility allocation and method. | Accept with Assumption | Proposal Ready | None | System behavior None | SSR-SYS-001 | - | 2.6.4 Product lifecycle page 11 Source detailsDocument section 2.6.4 Product lifecycle Section path 2.6 Cybersecurity lifecycle > 2.6.4 Product lifecycle Page reference page 11 |
| REQ_SEC_0041 | The vehicle manufacturer reserves the right to request documentation and evidence as well as to perform or order a compliance audit to determine whether the listed requirements are fulfilled.Proposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | Security evidence and traceability None | None | - | 2.2.3 Cryptographic libraries page 7 Source detailsDocument section 2.2.3 Cryptographic libraries Section path 2.2 System requirements > 2.2.3 Cryptographic libraries Page reference page 7 |
| REQ-AUTO-00004 | Method and scope shall be proposed to and approved by the vehicle manufacturer.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-SYS-001 | - | 2.1.3 Cybersecurity concept page 5 Source detailsDocument section 2.1.3 Cybersecurity concept Section path 2.1 Development process > 2.1.3 Cybersecurity concept Page reference page 5 |
| REQ-AUTO-00021 | Methods shall be proposed to and approved by the vehicle manufacturer.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-SYS-001 | - | 2.2.3 Cryptographic libraries page 7 Source detailsDocument section 2.2.3 Cryptographic libraries Section path 2.2 System requirements > 2.2.3 Cryptographic libraries Page reference page 7 |
| REQ-AUTO-00028 | Methods shall be proposed and approved by the vehicle manufacturer.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-SYS-001 | - | 2.4 Information security page 8 Source detailsDocument section 2.4 Information security Section path 2.4 Information security Page reference page 8 |
| REQ_SEC_0028 | Marcus Lindner EPXC Published 9(16) - Data specified by the vehicle manufacturer shall be protected from manipulations.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-SYS-001 | - | 2.6.1 Security updates page 9 Source detailsDocument section 2.6.1 Security updates Section path 2.6 Cybersecurity lifecycle > 2.6.1 Security updates Page reference page 9 |
| REQ_SEC_0029 | Data specified by the vehicle manufacturer shall be protected from disclosure.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-SYS-001 | - | 2.6.1 Security updates page 9 Source detailsDocument section 2.6.1 Security updates Section path 2.6 Cybersecurity lifecycle > 2.6.1 Security updates Page reference page 9 |
| REQ_SEC_0006 | Intellectual property of the vehicle manufacturer shall be protected from disclosure.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-SYS-001 | - | 2.6.1 Security updates page 9 Source detailsDocument section 2.6.1 Security updates Section path 2.6 Cybersecurity lifecycle > 2.6.1 Security updates Page reference page 9 |
| REQ-AUTO-00047 | The report shall include information needed to identify the affected vehicles/products.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | System behavior None | SSR-SYS-001 | - | 2.6.3 Vulnerability management page 10 Source detailsDocument section 2.6.3 Vulnerability management Section path 2.6 Cybersecurity lifecycle > 2.6.3 Vulnerability management Page reference page 10 |
| REQ-AUTO-00048 | Methods including the stipulation of a reasonable notification time shall be proposed to and approved by the vehicle manufacturer.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-SYS-001 | - | 2.6.3 Vulnerability management page 10 Source detailsDocument section 2.6.3 Vulnerability management Section path 2.6 Cybersecurity lifecycle > 2.6.3 Vulnerability management Page reference page 10 |
| REQ-AUTO-00052 | Methods including the stipulation of a reasonable reporting time shall be proposed to and approved by the vehicle manufacturer.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | System behavior OEM/Customer Review Interface | SSR-SYS-001 | - | 2.6.4 Product lifecycle page 11 Source detailsDocument section 2.6.4 Product lifecycle Section path 2.6 Cybersecurity lifecycle > 2.6.4 Product lifecycle Page reference page 11 |
| REQ_SEC_0047 | Product lifecycle - An ECU returned from field shall allow for field-return analysis.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | Hardware platform support None | SSR-HW-001 | - | 2.6.4 Product lifecycle page 11 Source detailsDocument section 2.6.4 Product lifecycle Section path 2.6 Cybersecurity lifecycle > 2.6.4 Product lifecycle Page reference page 11 |
| REQ_SEC_0049 | An ECU enabled for field-return analysis shall not be possible to use as a spare part.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | Hardware platform support None | SSR-LIFE-001 | - | 2.6.4 Product lifecycle page 11 Source detailsDocument section 2.6.4 Product lifecycle Section path 2.6 Cybersecurity lifecycle > 2.6.4 Product lifecycle Page reference page 11 |
| REQ-AUTO-00059 | End-of-life and decommissioning shall be specifically considered.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | System behavior None | SSR-LIFE-002 | - | 2.6.5 Logging page 12 Source detailsDocument section 2.6.5 Logging Section path 2.6 Cybersecurity lifecycle > 2.6.5 Logging Page reference page 12 |
| REQ-AUTO-00060 | Notes: a) It shall not be possible for a third party to reuse an ECU without system support from the vehicle manufacturer.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | Hardware platform support OEM/Customer Review Interface | SSR-HW-001 | - | 2.6.5 Logging page 12 Source detailsDocument section 2.6.5 Logging Section path 2.6 Cybersecurity lifecycle > 2.6.5 Logging Page reference page 12 |
| REQ-AUTO-00061 | b) Decommissioning of an ECU shall not have the potential of causing unacceptable risk to the road user or the vehicle manufacturer.Proposal: Accept. Implement the ECA ECU behavior against the mapped feature/interface and verify through supplier test evidence, subject to customer-confirmed responsibility and acceptance criteria. | Accept | Proposal Ready | None | Hardware platform support OEM/Customer Review Interface | SSR-LIFE-001 | - | 2.6.5 Logging page 12 Source detailsDocument section 2.6.5 Logging Section path 2.6 Cybersecurity lifecycle > 2.6.5 Logging Page reference page 12 |
| REQ_SEC_0040 | The vehicle manufacturer reserves the right to perform penetration testing on the ECU to identify potential vulnerabilities.Proposal: Informational only. Keep as context; do not treat as an implementation requirement unless the customer confirms applicability. | Informational Only | Proposal Ready | None | None None | None | - | 2.1.5 Documentation page 6 Source detailsDocument section 2.1.5 Documentation Section path 2.1 Development process > 2.1.5 Documentation Page reference page 6 |
Derived Supplier System Requirements
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| SSR | Statement / Trace | Feature | Security Capability | Interface | Responsibility | Status | Verification |
|---|---|---|---|---|---|---|---|
| SSR-COM-001 | OEM/Customer Review Interface — Secure Communication and Boundary ControlThe ECU shall restrict and protect communication for OEM/Customer Review Interface, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.From this PDF: REQ_SEC_0011; REQ_SEC_0025; REQ_SEC_0026; REQ_SEC_0050. | OEM/Customer Review Interface | None | OEM/Customer Review Interface | Shared | Ready for Customer Alignment | Review + Test |
| SSR-CON-001 | Cybersecurity requirement handling — Cybersecurity Concept and EvidenceThe supplier shall produce and maintain the cybersecurity concept and verification evidence covering Cybersecurity requirement handling.From this PDF: REQ-AUTO-00001; REQ-AUTO-00009; REQ-AUTO-00011; REQ_SEC_0001; REQ_SEC_0003; REQ_SEC_0004; REQ_SEC_0005; REQ_SEC_0009; REQ_SEC_0015; REQ_SEC_0022; REQ_SEC_0023; REQ_SEC_0024; REQ_SEC_0027; REQ_SEC_0030; REQ_SEC_0042; REQ_SEC_0043. This SSR is also supported by requirements from other PDFs. | Cybersecurity requirement handling | Cybersecurity requirement handling | OEM/Customer Review Interface | Supplier-Owned | Candidate | Review + Test |
| SSR-DAI-001 | Authentication — Data Authenticity and Integrity VerificationThe ECU shall verify the authenticity and integrity of Authentication data and reject manipulated or unauthenticated data.From this PDF: REQ_SEC_0008. This SSR is also supported by requirements from other PDFs. | Authentication | Authentication | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-HW-001 | Hardware platform support — Hardware / HSM / Secure StorageThe ECU hardware shall provide the platform and secure-storage capabilities required for Hardware platform support.From this PDF: REQ-AUTO-00060; REQ_SEC_0047. This SSR is also supported by requirements from other PDFs. | Hardware platform support | None | OEM/Customer Review Interface | Shared | Ready for Customer Alignment | Review + Test |
| SSR-KEY-001 | Key management — Key and Certificate HandlingThe ECU shall manage key and certificate material for Key management across provisioning, storage, use, renewal and revocation per the agreed key lifecycle.From this PDF: REQ_SEC_0016; REQ_SEC_0019. This SSR is also supported by requirements from other PDFs. | Key management | Key management | OEM/Customer Review Interface | Shared | Blocked by Customer Clarification | Review + Test |
| SSR-LIFE-001 | Hardware platform support — Lifecycle / Field Return / DecommissioningThe ECU and supplier process shall handle lifecycle, field return and decommissioning for Hardware platform support, including secure data and key handling.From this PDF: REQ-AUTO-00061; REQ_SEC_0049. | Hardware platform support | None | OEM/Customer Review Interface | Supplier-Owned | Ready for Internal Review | Review + Test |
| SSR-LIFE-002 | System behavior — Lifecycle / Field Return / DecommissioningThe ECU and supplier process shall handle lifecycle, field return and decommissioning for System behavior, including secure data and key handling.From this PDF: REQ-AUTO-00059. This SSR is also supported by requirements from other PDFs. | System behavior | None | OEM/Customer Review Interface | Supplier-Owned | Candidate | Review + Test |
| SSR-LOG-001 | Logging and audit trail — Security Logging and Event HandlingThe ECU shall record bounded security-relevant events for Logging and audit trail with sufficient integrity and context for diagnostics and incident evidence.From this PDF: REQ_SEC_0051. | Logging and audit trail | Logging and audit trail | None | Supplier-Owned | Candidate | Review + Test |
| SSR-PROD-001 | Hardware platform support — Supplier Development and Production HardeningThe ECU and production process shall enforce development/production hardening for Hardware platform support, including debug lock and protected access.From this PDF: REQ_SEC_0010. | Hardware platform support | None | None | Supplier-Owned | Candidate | Review + Test |
| SSR-SYS-001 | System behavior — System FunctionThe ECU shall implement the System behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.From this PDF: REQ-AUTO-00004; REQ-AUTO-00005; REQ-AUTO-00021; REQ-AUTO-00028; REQ-AUTO-00030; REQ-AUTO-00047; REQ-AUTO-00048; REQ-AUTO-00052; REQ_SEC_0006; REQ_SEC_0012; REQ_SEC_0013; REQ_SEC_0014; REQ_SEC_0020; REQ_SEC_0021; REQ_SEC_0028; REQ_SEC_0029; REQ_SEC_0037; REQ_SEC_0048. This SSR is also supported by requirements from other PDFs. | System behavior | None | OEM/Customer Review Interface | Supplier-Owned | Candidate | Test |
| SSR-SYS-007 | Application software behavior — System FunctionThe ECU shall implement the Application software behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing.From this PDF: REQ_SEC_0007. This SSR is also supported by requirements from other PDFs. | Application software behavior | None | OEM/Customer Review Interface | Shared | Ready for Customer Alignment | Test |
| SSR-VIH-001 | Vulnerability management — Vulnerability and Incident HandlingThe supplier shall support vulnerability monitoring and incident handling for Vulnerability management over the defined lifecycle, including field updates.From this PDF: REQ-AUTO-00051; REQ_SEC_0002. | Vulnerability management | Vulnerability management | OEM/Customer Review Interface | Supplier-Owned | Candidate | Review + Test |
| SSR-VIH-002 | System behavior — Vulnerability and Incident HandlingThe supplier shall support vulnerability monitoring and incident handling for System behavior over the defined lifecycle, including field updates.From this PDF: REQ_SEC_0032; REQ_SEC_0044; REQ_SEC_0046. | System behavior | None | OEM/Customer Review Interface | Supplier-Owned | Candidate | Review + Test |
| SSR-VIH-003 | Incident response — Vulnerability and Incident HandlingThe supplier shall support vulnerability monitoring and incident handling for Incident response over the defined lifecycle, including field updates.From this PDF: REQ_SEC_0045. | Incident response | Incident response | None | Supplier-Owned | Candidate | Review + Test |
| SSR-VIH-004 | System behavior — Vulnerability and Incident HandlingThe supplier shall support vulnerability monitoring and incident handling for System behavior over the defined lifecycle, including field updates.From this PDF: REQ_SEC_0033; REQ_SEC_0034; REQ_SEC_0035. | System behavior | None | OEM/Customer Review Interface | Shared | Ready for Customer Alignment | Review + Test |
| SSR-VIH-005 | External interfaces — Vulnerability and Incident HandlingThe supplier shall support vulnerability monitoring and incident handling for External interfaces over the defined lifecycle, including field updates.From this PDF: REQ_SEC_0036. | External interfaces | None | External Interfaces | Supplier-Owned | Candidate | Review + Test |
System / Security Design Impact
| Impact Area | Evidence From This PDF |
|---|---|
| Impacted system features | Application software behavior; Application software behavior; Security evidence and traceability; Authentication; Cybersecurity requirement handling; Cybersecurity requirement handling; Security evidence and traceability; External interfaces; Hardware platform support; Incident response; Key management; Logging and audit trail; Security evidence and traceability; System behavior (showing 12 of 14) |
| Impacted interfaces | External Interfaces; OEM/Customer Review Interface; OEM/Customer Review Interface |
| Impacted security capabilities | Authentication; Cybersecurity requirement handling; Incident response; Key management; Logging and audit trail; Vulnerability management |
| Impacted architecture elements | Application Software; OEM/Customer Review Interface; Compliance Process; Compliance Process; OEM/Customer Review Interface; External Interfaces; OEM/Customer Review Interface; Hardware Platform; Hardware Platform; OEM/Customer Review Interface; Security Services; Security Services; OEM/Customer Review Interface; System Core; System Core; OEM/Customer Review Interface |
| Impacted work products | Cybersecurity concept; Cybersecurity verification report; DIA / cybersecurity case; System/architecture design |
| Tools / IT / hardware / test | High/Low/Low; High/Low/Medium; Low/High/Low; Low/Low/High; Low/Low/Low; Low/Low/Medium; Medium/Low/High; Medium/Low/Medium |
| Design assumptions introduced | Security-relevant requirement the ECU can own once responsibility/method is confirmed. |
| Design decisions required | Send linked open point to the customer for decision.; Agree responsibility split (DIA) for the non-ECU portion. |
Estimation / Resource / Tooling Impact
| Impact | Status |
|---|---|
| Estimation impact | yes |
| Resource/tool/IT/HW/test impact | High/Low/Low; High/Low/Medium; Low/High/Low; Low/Low/High; Low/Low/Low; Low/Low/Medium; Medium/Low/High; Medium/Low/Medium |
Document Impact Diagram
Document Impact
Generated from document-specific requirement, traceability, SSR, and open-point evidence.
flowchart LR
doc["1001379436_P10_000_01_RDDM-1140152501-1744.pdf"]
d0["Authentication"]
doc --> d0
d1["Cybersecurity requirement handling"]
doc --> d1
d2["Incident response"]
doc --> d2
f0["Feature: Application software behavior"]
doc --> f0
f1["Feature: Application software behavior; Security evidence and traceability"]
doc --> f1
f2["Feature: Authentication"]
doc --> f2
i0["Interface: External Interfaces; OEM/Customer Review Interface"]
doc --> i0
i1["Interface: OEM/Customer Review Interface"]
doc --> i1
s0["SSR: SSR-COM-001"]
doc --> s0
s1["SSR: SSR-CON-001"]
doc --> s1
s2["SSR: SSR-DAI-001"]
doc --> s2
o0["Open point: OP-003"]
doc --> o0
o1["Open point: OP-006"]
doc --> o1
o2["Open point: OP-008"]
doc --> o2
Mermaid source
flowchart LR
doc["1001379436_P10_000_01_RDDM-1140152501-1744.pdf"]
d0["Authentication"]
doc --> d0
d1["Cybersecurity requirement handling"]
doc --> d1
d2["Incident response"]
doc --> d2
f0["Feature: Application software behavior"]
doc --> f0
f1["Feature: Application software behavior; Security evidence and traceability"]
doc --> f1
f2["Feature: Authentication"]
doc --> f2
i0["Interface: External Interfaces; OEM/Customer Review Interface"]
doc --> i0
i1["Interface: OEM/Customer Review Interface"]
doc --> i1
s0["SSR: SSR-COM-001"]
doc --> s0
s1["SSR: SSR-CON-001"]
doc --> s1
s2["SSR: SSR-DAI-001"]
doc --> s2
o0["Open point: OP-003"]
doc --> o0
o1["Open point: OP-006"]
doc --> o1
o2["Open point: OP-008"]
doc --> o2
Traceability
This table is horizontally scrollable. Use the bottom scrollbar to view all columns.
| Customer Requirement | SSR | Disposition | Confidence | Reason |
|---|---|---|---|---|
| REQ-AUTO-00001 | SSR-CON-001 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| REQ_SEC_0001 | SSR-CON-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0002 | SSR-VIH-001 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| REQ-AUTO-00004 | SSR-SYS-001 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| REQ-AUTO-00005 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00006 | None | Blocked by Customer Clarification | n/a | Needs customer clarification before derivation. |
| REQ_SEC_0003 | SSR-CON-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0022 | SSR-CON-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00009 | SSR-CON-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0023 | SSR-CON-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00011 | SSR-CON-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0024 | SSR-CON-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0004 | SSR-CON-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0005 | SSR-CON-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0040 | None | Informational Only | n/a | Non-binding; not derived. |
| REQ_SEC_0007 | SSR-SYS-007 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| REQ_SEC_0025 | SSR-COM-001 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| REQ_SEC_0041 | None | Informational Only | n/a | Non-binding; not derived. |
| REQ_SEC_0042 | SSR-CON-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0008 | SSR-DAI-001 | Derive Supplier System Requirement | Low | Accepted requirement; seed of its SSR cluster. |
| REQ-AUTO-00021 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0009 | SSR-CON-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0020 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0010 | SSR-PROD-001 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| REQ_SEC_0011 | SSR-COM-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0012 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0013 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00028 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0014 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00030 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0026 | SSR-COM-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ_SEC_0027 | SSR-CON-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0028 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0029 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0006 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0016 | SSR-KEY-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ_SEC_0019 | SSR-KEY-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0021 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0015 | SSR-CON-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0043 | SSR-CON-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0030 | SSR-CON-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0044 | SSR-VIH-002 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| REQ_SEC_0045 | SSR-VIH-003 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| REQ_SEC_0046 | SSR-VIH-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0032 | SSR-VIH-002 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0033 | SSR-VIH-004 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| REQ-AUTO-00047 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00048 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0034 | SSR-VIH-004 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ_SEC_0035 | SSR-VIH-004 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00051 | SSR-VIH-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00052 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0036 | SSR-VIH-005 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
| REQ_SEC_0037 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0047 | SSR-HW-001 | Derive Supplier System Requirement | High | Accepted requirement; seed of its SSR cluster. |
| REQ_SEC_0048 | SSR-SYS-001 | Covered by Existing Supplier System Requirement | Medium | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0049 | SSR-LIFE-001 | Derive Supplier System Requirement | High | Accepted requirement; seed of its SSR cluster. |
| REQ_SEC_0050 | SSR-COM-001 | Shared Responsibility / CIA Needed | Medium | Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC. |
| REQ-AUTO-00059 | SSR-LIFE-002 | Derive Supplier System Requirement | High | Accepted requirement; seed of its SSR cluster. |
| REQ-AUTO-00060 | SSR-HW-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ-AUTO-00061 | SSR-LIFE-001 | Covered by Existing Supplier System Requirement | High | Accepted requirement; covered by a clustered SSR. |
| REQ_SEC_0051 | SSR-LOG-001 | Derive Supplier System Requirement | Medium | Accepted requirement; seed of its SSR cluster. |
Detailed Evidence
Document intelligence markdown
1001379436_P10_000_01_RDDM-1140152501-1744
- Source PDF:
customer-input/pdf/1001379436_P10_000_01_RDDM-1140152501-1744.pdf - Converted Markdown:
converted/markdown/1001379436_P10_000_01_RDDM-1140152501-1744.md - Document type: Cybersecurity Requirement Standard
- Domain: Cybersecurity
- Confidence: High
- Evidence basis: Markdown-derived requirements and generated RFQX registers; no downstream PDF analysis.
Executive Summary
Confirmed by requirements: this cybersecurity requirement standard contributes 62 Markdown-derived RFQ requirements with the strongest evidence in core eca system behavior. Inferred from requirement pattern: for RFQX it affects the Electric Clutch Actuator ECU on the TRATON GW AMT platform by shaping core eca system behavior; responsibility and customer approval model; system architecture design.
Confirmed by requirements: supplier positioning is 14 accept; 41 accept with assumption; 4 partially accept; 1 needs customer clarification; 2 informational only. The generated traceability links this document to 16 supplier system requirement records. Inferred from mapped features, capabilities, and interfaces: the main design/security impact is core eca system behavior; responsibility and customer approval model; system architecture design. These themes should drive concept updates, verification evidence, and supplier proposal assumptions only where the linked requirements support them.
Requires customer confirmation: 4 document-linked open point(s) remain, mainly: Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier.; Confirm the split of monitoring, triage, vulnerability handling and field response between OEM PSIRT and supplier.; Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy). (showing 3 of 4). Do not convert these items into agreed baseline scope until the customer confirms the decision. Confidence and limits: High confidence. Evidence is limited to Markdown-derived requirements, registers, open points, and SSR links; no downstream PDF analysis or AI-generated conclusion is claimed.
Document Abstract
| Field | Interpretation |
|---|---|
| Document Purpose | Confirmed by requirements: this cybersecurity requirement standard contributes 62 Markdown-derived RFQ requirements with the strongest evidence in core eca system behavior. |
| Engineering Interpretation | Inferred from requirement pattern: for RFQX it affects the Electric Clutch Actuator ECU on the TRATON GW AMT platform by shaping core eca system behavior; responsibility and customer approval model; system architecture design. |
| Supplier Proposal Impact | Confirmed by requirements: supplier positioning is 14 accept; 41 accept with assumption; 4 partially accept; 1 needs customer clarification; 2 informational only. The generated traceability links this document to 16 supplier system requirement records. |
| System / Security Impact | Inferred from mapped features, capabilities, and interfaces: the main design/security impact is core eca system behavior; responsibility and customer approval model; system architecture design. These themes should drive concept updates, verification evidence, and supplier proposal assumptions only where the linked requirements support them. |
| Customer Clarification Impact | Requires customer confirmation: 4 document-linked open point(s) remain, mainly: Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier.; Confirm the split of monitoring, triage, vulnerability handling and field response between OEM PSIRT and supplier.; Confirm production/debug hardening expectations (debug lock, secure end-of-line, developer-access policy). (showing 3 of 4). Do not convert these items into agreed baseline scope until the customer confirms the decision. |
| Confidence and Limits | Confidence and limits: High confidence. Evidence is limited to Markdown-derived requirements, registers, open points, and SSR links; no downstream PDF analysis or AI-generated conclusion is claimed. |
Main Requirement Themes
| Theme | Summary | Requirement Count | Representative Requirements |
|---|---|---|---|
| Core ECA system behavior | Defines actuator ECU behavior, drivetrain integration, electrical/mechanical constraints, and verification scope. | 46 | REQ_SEC_0002; REQ-AUTO-00004; REQ-AUTO-00005 |
| Responsibility and customer approval model | Creates supplier/OEM allocation decisions for work products, backend infrastructure, approvals, and residual risk. | 44 | REQ-AUTO-00001; REQ_SEC_0001; REQ_SEC_0002 |
| System architecture design | Groups related document requirements into a single engineering theme. | 35 | REQ-AUTO-00004; REQ-AUTO-00005; REQ-AUTO-00006 |
| Cybersecurity concept and evidence | Drives cybersecurity concept, risk treatment, verification evidence, and traceability obligations. | 29 | REQ-AUTO-00001; REQ_SEC_0001; REQ_SEC_0002 |
| Cybersecurity | Groups related document requirements into a single engineering theme. | 23 | REQ-AUTO-00001; REQ_SEC_0001; REQ_SEC_0002 |
| Cybersecurity control | Groups related document requirements into a single engineering theme. | 23 | REQ-AUTO-00001; REQ_SEC_0001; REQ_SEC_0002 |
| Cybersecurity verification report | Groups related document requirements into a single engineering theme. | 23 | REQ-AUTO-00001; REQ_SEC_0001; REQ_SEC_0002 |
| Security services | Groups related document requirements into a single engineering theme. | 23 | REQ-AUTO-00001; REQ_SEC_0001; REQ_SEC_0002 |
Document Content Structure
| Section | Requirements | Critical | Open Points | SSR Links |
|---|---|---|---|---|
| 1 Introduction | 1 | 0 | 0 | 1 |
| -- 1.4 Abbreviated terms | 1 | 0 | 0 | 1 |
| -- 2.1 Development process | 15 | 1 | 1 | 4 |
| -- -- 2.1.3 Cybersecurity concept | 6 | 1 | 1 | 3 |
| -- -- 2.1.5 Documentation | 9 | 0 | 0 | 2 |
| -- 2.2 System requirements | 7 | 0 | 0 | 4 |
| -- -- 2.2.3 Cryptographic libraries | 7 | 0 | 0 | 4 |
| -- 2.4 Information security | 9 | 1 | 1 | 4 |
| -- 2.6 Cybersecurity lifecycle | 30 | 3 | 2 | 13 |
| -- -- 2.6.1 Security updates | 8 | 1 | 1 | 3 |
| -- -- 2.6.3 Vulnerability management | 9 | 1 | 1 | 5 |
| -- -- 2.6.4 Product lifecycle | 8 | 0 | 0 | 6 |
| -- -- 2.6.5 Logging | 5 | 1 | 0 | 5 |
What this document does not confirm
Customer-owned responsibility, final customer decisions, and unresolved open points remain unconfirmed.
Critical Requirements
| ID | Score | Category | Reason | Statement |
|---|---|---|---|---|
| REQ-AUTO-00006 | 95 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Needs Customer Clarification; linked open point; Unknown estimation impact; blocks SSR derivation | Note: The vehicle manufacturer and supplier shall collaboratively define the context of the system or function to enable the supplier performing the risk assessment. |
| REQ_SEC_0016 | 77 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact | Key management REQ_SEC_0016 It shall be possible for the vehicle manufacturer to securely inject key material and other data used for cybersecurity controls into the ECU according to the specification of the vehicle manufacturer. |
| REQ_SEC_0026 | 63 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point | REQ_SEC_0026 Only hardware interfaces and protocols specified by the vehicle manufacturer shall be available in series production. |
| REQ_SEC_0034 | 63 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept; linked open point | REQ_SEC_0034 Following each identified and reported vulnerability, the supplier and vehicle manufacturer shall agree on an initial response to the vulnerability. |
| REQ_SEC_0050 | 48 | High risk due to unclear OEM/supplier responsibility | security relevant; architecture relevant; Partially Accept | Marcus Lindner EPXC Published 12(16) REQ_SEC_0050 All secrets specified by the vehicle manufacturer shall be protected throughout the lifecycle of the ECU. |
| REQ-AUTO-00001 | 44 | High impact on cybersecurity concept/work products | security relevant; architecture relevant; High estimation impact | The cybersecurity concept shall describe the scope of the risk analysis, risks that were identified during the risk analysis, cybe rsecurity goals, cybersecurity requirements, mitigation strategies, validation, and verification strategies, etc. |
| REQ_SEC_0001 | 44 | High impact on cybersecurity concept/work products | security relevant; architecture relevant; High estimation impact | Cybersecurity methods and strategies REQ_SEC_0001 The supplier shall provide documentation describing their strategies and methods for working with embedded systems cybersecurity. |
| REQ_SEC_0002 | 44 | General project impact | security relevant; architecture relevant; High estimation impact | Risk assessment REQ_SEC_0002 The supplier shall perform risk assessment based on a threat and vulnerability analysis for each release, including any vehicle manufacturer-specific adaptations. |
| REQ_SEC_0003 | 44 | High impact on cybersecurity concept/work products | security relevant; architecture relevant; High estimation impact | Cybersecurity concept REQ_SEC_0003 The supplier shall describe the cybersecurity concept and how it is implemented in hardware and software respectively. |
| REQ_SEC_0022 | 44 | High impact on cybersecurity concept/work products | security relevant; architecture relevant; High estimation impact | Marcus Lindner EPXC Published 6(16) REQ_SEC_0022 All risks identified in cybersecurity risk analyses shall be evaluated. |
Open Points
| Open Point | Priority | Question | Impact | Status |
|---|---|---|---|---|
| OP-003 | 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. | Open | |
| OP-006 | 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. | Open | |
| OP-008 | 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. | Open | |
| OP-011 | Confirm whether each listed requirement is binding supplier scope, customer-owned scope, or evidence-only context for the ECA ECU baseline. | Supplier position, estimation, and affected design allocation remain conditional for the listed requirements. | Open |
Supplier System Requirements
| SSR | Title | Statement | Reqs From This PDF | Other PDFs | Status |
|---|---|---|---|---|---|
| SSR-COM-001 | OEM/Customer Review Interface — Secure Communication and Boundary Control | The ECU shall restrict and protect communication for OEM/Customer Review Interface, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals. | REQ_SEC_0011; REQ_SEC_0025; REQ_SEC_0026; REQ_SEC_0050 | no | Ready for Customer Alignment |
| SSR-CON-001 | Cybersecurity requirement handling — Cybersecurity Concept and Evidence | The supplier shall produce and maintain the cybersecurity concept and verification evidence covering Cybersecurity requirement handling. | REQ-AUTO-00001; REQ-AUTO-00009; REQ-AUTO-00011; REQ_SEC_0001; REQ_SEC_0003; REQ_SEC_0004; REQ_SEC_0005; REQ_SEC_0009; REQ_SEC_0015; REQ_SEC_0022; REQ_SEC_0023; REQ_SEC_0024; REQ_SEC_0027; REQ_SEC_0030; REQ_SEC_0042; REQ_SEC_0043 | yes | Candidate |
| SSR-DAI-001 | Authentication — Data Authenticity and Integrity Verification | The ECU shall verify the authenticity and integrity of Authentication data and reject manipulated or unauthenticated data. | REQ_SEC_0008 | yes | Blocked by Customer Clarification |
| SSR-HW-001 | Hardware platform support — Hardware / HSM / Secure Storage | The ECU hardware shall provide the platform and secure-storage capabilities required for Hardware platform support. | REQ-AUTO-00060; REQ_SEC_0047 | yes | Ready for Customer Alignment |
| SSR-KEY-001 | Key management — Key and Certificate Handling | The ECU shall manage key and certificate material for Key management across provisioning, storage, use, renewal and revocation per the agreed key lifecycle. | REQ_SEC_0016; REQ_SEC_0019 | yes | Blocked by Customer Clarification |
| SSR-LIFE-001 | Hardware platform support — Lifecycle / Field Return / Decommissioning | The ECU and supplier process shall handle lifecycle, field return and decommissioning for Hardware platform support, including secure data and key handling. | REQ-AUTO-00061; REQ_SEC_0049 | no | Ready for Internal Review |
| SSR-LIFE-002 | System behavior — Lifecycle / Field Return / Decommissioning | The ECU and supplier process shall handle lifecycle, field return and decommissioning for System behavior, including secure data and key handling. | REQ-AUTO-00059 | yes | Candidate |
| SSR-LOG-001 | Logging and audit trail — Security Logging and Event Handling | The ECU shall record bounded security-relevant events for Logging and audit trail with sufficient integrity and context for diagnostics and incident evidence. | REQ_SEC_0051 | no | Candidate |
| SSR-PROD-001 | Hardware platform support — Supplier Development and Production Hardening | The ECU and production process shall enforce development/production hardening for Hardware platform support, including debug lock and protected access. | REQ_SEC_0010 | no | Candidate |
| SSR-SYS-001 | System behavior — System Function | The ECU shall implement the System behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing. | REQ-AUTO-00004; REQ-AUTO-00005; REQ-AUTO-00021; REQ-AUTO-00028; REQ-AUTO-00030; REQ-AUTO-00047; REQ-AUTO-00048; REQ-AUTO-00052; REQ_SEC_0006; REQ_SEC_0012; REQ_SEC_0013; REQ_SEC_0014; REQ_SEC_0020; REQ_SEC_0021; REQ_SEC_0028; REQ_SEC_0029; REQ_SEC_0037; REQ_SEC_0048 | yes | Candidate |
| SSR-SYS-007 | Application software behavior — System Function | The ECU shall implement the Application software behavior behaviour required by its allocated customer requirements, including the specified functions, signals, states and timing. | REQ_SEC_0007 | yes | Ready for Customer Alignment |
| SSR-VIH-001 | Vulnerability management — Vulnerability and Incident Handling | The supplier shall support vulnerability monitoring and incident handling for Vulnerability management over the defined lifecycle, including field updates. | REQ-AUTO-00051; REQ_SEC_0002 | no | Candidate |
| SSR-VIH-002 | System behavior — Vulnerability and Incident Handling | The supplier shall support vulnerability monitoring and incident handling for System behavior over the defined lifecycle, including field updates. | REQ_SEC_0032; REQ_SEC_0044; REQ_SEC_0046 | no | Candidate |
| SSR-VIH-003 | Incident response — Vulnerability and Incident Handling | The supplier shall support vulnerability monitoring and incident handling for Incident response over the defined lifecycle, including field updates. | REQ_SEC_0045 | no | Candidate |
| SSR-VIH-004 | System behavior — Vulnerability and Incident Handling | The supplier shall support vulnerability monitoring and incident handling for System behavior over the defined lifecycle, including field updates. | REQ_SEC_0033; REQ_SEC_0034; REQ_SEC_0035 | no | Ready for Customer Alignment |
| SSR-VIH-005 | External interfaces — Vulnerability and Incident Handling | The supplier shall support vulnerability monitoring and incident handling for External interfaces over the defined lifecycle, including field updates. | REQ_SEC_0036 | no | Candidate |
Design Impact
- Impacted System Features: Application software behavior; Application software behavior; Security evidence and traceability; Authentication; Cybersecurity requirement handling; Cybersecurity requirement handling; Security evidence and traceability; External interfaces; Hardware platform support; Incident response (showing 8 of 14)
- Impacted Interfaces: External Interfaces; OEM/Customer Review Interface; OEM/Customer Review Interface
- Impacted Security Capabilities: Authentication; Cybersecurity requirement handling; Incident response; Key management; Logging and audit trail; Vulnerability management
- Impacted Architecture Elements: Application Software; OEM/Customer Review Interface; Compliance Process; Compliance Process; OEM/Customer Review Interface; External Interfaces; OEM/Customer Review Interface; Hardware Platform; Hardware Platform; OEM/Customer Review Interface; Security Services; Security Services; OEM/Customer Review Interface (showing 8 of 10)
- Impacted Work Products: Cybersecurity concept; Cybersecurity verification report; DIA / cybersecurity case; System/architecture design
- Impacted Tools It Hardware Test: High/Low/Low; High/Low/Medium; Low/High/Low; Low/Low/High; Low/Low/Low; Low/Low/Medium; Medium/Low/High; Medium/Low/Medium
- Impacted Supplier System Requirements: SSR-COM-001; SSR-CON-001; SSR-DAI-001; SSR-HW-001; SSR-KEY-001; SSR-LIFE-001; SSR-LIFE-002; SSR-LOG-001 (showing 8 of 16)
- Design Assumptions Introduced: Security-relevant requirement the ECU can own once responsibility/method is confirmed.
- Design Decisions Required: Send linked open point to the customer for decision.; Agree responsibility split (DIA) for the non-ECU portion.