CVS31

Responsibility Agreement / CIA / RASIC · Key / Certificate Handling · Core ECA system behavior

Executive Takeaway

Confirmed by requirements: this responsibility agreement / cia / rasic contributes 108 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; cybersecurity concept and evidence; responsibility and customer approval model.

Confirmed by requirements: supplier positioning is 20 accept; 24 accept with assumption; 60 partially accept; 1 needs internal review; 3 informational only. The generated traceability links this document to 18 supplier system requirement records. Inferred from mapped features, capabilities, and interfaces: the main design/security impact is core eca system behavior; cybersecurity concept and evidence; responsibility and customer approval model. These themes should drive concept updates, verification evidence, and supplier proposal assumptions only where the linked requirements support them.

Requires customer confirmation: 3 document-linked open point(s) remain, mainly: Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.; Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier.; Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. 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.

Requirements108from this PDF

Critical60ranked

Open Points3linked

Derived SSRs18linked

Concept Impactyesdocument-specific

Estimation Impactyesdocument-specific

Document Abstract

Document Purpose

Confirmed by requirements: this responsibility agreement / cia / rasic contributes 108 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; cybersecurity concept and evidence; responsibility and customer approval model.

Main Requirement Themes

Core ECA system behavior; Cybersecurity concept and evidence; Responsibility and customer approval model; System architecture design; Key, certificate, and PKI handling (showing 5 of 8)

System / Security Impact

Inferred from mapped features, capabilities, and interfaces: the main design/security impact is core eca system behavior; cybersecurity concept and evidence; responsibility and customer approval model. These themes should drive concept updates, verification evidence, and supplier proposal assumptions only where the linked requirements support them.

Supplier Proposal Impact

Customer Clarification Impact

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.	86	REQ-AUTO-00879; REQ-AUTO-00880; REQ-AUTO-00881
Cybersecurity concept and evidence	Drives cybersecurity concept, risk treatment, verification evidence, and traceability obligations.	67	REQ-AUTO-00881; REQ-AUTO-00883; REQ-AUTO-00886
Responsibility and customer approval model	Creates supplier/OEM allocation decisions for work products, backend infrastructure, approvals, and residual risk.	57	REQ-AUTO-00881; REQ-AUTO-00883; REQ-AUTO-00884
System architecture design	Groups related document requirements into a single engineering theme.	41	REQ-AUTO-00879; REQ-AUTO-00880; REQ-AUTO-00882
Key, certificate, and PKI handling	Affects ECU trust material storage, provisioning, lifecycle ownership, and customer PKI dependencies.	40	REQ-AUTO-00889; REQ-AUTO-00891; REQ-AUTO-00892
System	Groups related document requirements into a single engineering theme.	32	REQ-AUTO-00879; REQ-AUTO-00880; REQ-AUTO-00882
System core	Groups related document requirements into a single engineering theme.	31	REQ-AUTO-00879; REQ-AUTO-00882; REQ-AUTO-00884
Cybersecurity	Groups related document requirements into a single engineering theme.	22	REQ-AUTO-00892; REQ-AUTO-00895; REQ-AUTO-00907

Document Content Structure

Section	Requirements	Critical	Open Points	SSR Links
1 Scope	1	0	0	1
-- 1.1 Summary	1	0	0	1
2 Abbrevations	3	2	0	3
3 subFunctions	43	29	3	12
-- 3.1 verifyCertificateBidirectional	14	9	2	8
-- -- 3.1.1 Request	5	4	2	4
-- -- 3.1.2 Response	9	5	1	6
-- 3.2 proofOfOwnership	21	16	3	8
-- -- 3.2.1 Request	7	6	1	5
-- -- 3.2.2 Response	3	1	0	2
-- -- 3.2.3 Negative Response	7	6	1	4
-- 3.3 deAuthenticate	5	2	1	4
-- -- 3.3.3 Negative Response	5	2	1	4
4 General	55	29	3	14
-- 4.1 Certificate	30	14	2	10
-- -- 4.1.3 D-RBACC extension	9	3	1	6
-- -- 4.1.8 Certificate Validity Time	11	5	1	5
-- 4.2 State-keeping	8	8	1	4
-- 4.5 CRNG	4	1	0	3
-- 4.7 PassiveDeAuthentication	7	3	1	3
-- -- 4.7.1 TimeBasedPassiveDeAuthentication	7	3	1	3
-- 4.9 Authentication completion timer	6	3	1	4
6 Normative references	1	0	0	1

What This PDF Is About

Field	Value
Source PDF	customer-input/pdf/CVS31.pdf
Converted Markdown	converted/markdown/CVS31.md
Document Type	Responsibility Agreement / CIA / RASIC
Domain	Key / Certificate Handling
Scope Summary	108 extracted requirements; 18 linked SSRs; 3 linked open points.
Main Themes	Core ECA system behavior; Cybersecurity concept and evidence; Responsibility and customer approval model; System architecture design; Key, certificate, and PKI handling (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 responsibility agreement / cia / rasic contributes 108 Markdown-derived RFQ requirements with the strongest evidence in core eca system behavior.
Confirmed by requirements: supplier positioning is 20 accept; 24 accept with assumption; 60 partially accept; 1 needs internal review; 3 informational only. The generated traceability links this document to 18 supplier system requirement records.
Requires customer confirmation: 3 document-linked open point(s) remain, mainly: Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.; Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier.; Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. 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-00889	77	High risk due to unclear OEM/supplier responsibility	Table 4 – Supported subFunctions (ISO 14229-1:2020) Name verifyCertificateBidirectional proofOfOwnership deAuthenticate AUTH_REQ 155 The server shall not accept an application-layer service 0x29 request when it is received inside an SDT (service 0x84) protected message.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	Partially Accept
REQ-AUTO-00892	77	High risk due to unclear OEM/supplier responsibility	Table 5 – verifyCertificateBidirectional Request Field Description Type/Value Cvt Included in proofOfOwnershipServer Authentication Request SID Service ID for Authentication service request 0x29 M Yes verifyCertificateBidirectional] Initiate Authentication by verifying the Certificate and generating a Proof of Ownership from the server 0x02 M Yes communicationConfiguration NOT USED 0x00 M Yes lengthOfCertificateClient Length parameter for certificateClient uint16 M Yes certificateClient The Certificate to verify uint8[] M Yes lengthOfChallengeClient Length parameter for challengeClient uint16 M Yes challengeClient See 3.1.1.1 uint8[] M Yes AUTH_REQ 117 Upon reception of a verifyCertificateBidirectional request, the server shall determine whether the Authentication delay timer is currently running.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	Partially Accept
REQ-AUTO-00893	77	High risk due to unclear OEM/supplier responsibility	AUTH_REQ 118 If upon reception of verifyCertificateBidirectional request the Authentication delay timer is expired, the server shall continue to process the verifyCertificateBidirectional request.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	Partially Accept
REQ-AUTO-00895	77	High risk due to unclear OEM/supplier responsibility	AUTH_REQ 45 If the server verifies the client certificate as valid, the server shall create the requested client authentication pending state.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	Partially Accept
REQ-AUTO-00900	77	High risk due to unclear OEM/supplier responsibility	AUTH_REQ 173 The server shall verify the value of lengthOfCertificateClient upon reception of verifyCertificateBidirectional request.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	Partially Accept
REQ-AUTO-00901	77	High risk due to unclear OEM/supplier responsibility	AUTH_REQ 174 If the lengthOfCertificateClient value is not within the expected range, the server shall send negative response code 0x13 (incorrectMessageLengthOrInvalidFormat).security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	Partially Accept
REQ-AUTO-00906	77	High risk due to unclear OEM/supplier responsibility	3.1.3 Negative Response AUTH_REQ 121 If upon reception of verifyCertificateBidirectional request the Authentication delay timer is running, the server shall respond to the verifyCertificateBidirectional request with a Negative Response Code (NRC) 0x37, indicating requiredTimeDelayNotExpired.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	Partially Accept
REQ-AUTO-00907	77	High risk due to unclear OEM/supplier responsibility	AUTH_REQ 122 If the server verifies the client certificate as invalid, it shall respond to the verifyCertificateBidirectional request with a Negative Response Code (NRC) 0x10, indicating generalReject.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	Partially Accept
REQ-AUTO-00908	77	High risk due to unclear OEM/supplier responsibility	AUTH_REQ 123 If the server fails or cannot determine that the authentication pending state was stored, it shall respond to the verifyCertificateBidirectional request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	Partially Accept
REQ-AUTO-00910	77	High risk due to unclear OEM/supplier responsibility	Table 7 – proofOfOwnership Request Field Description Type/Value Cvt Included in proofOfOwnershipClient Authentication Request SID Service ID for 0x29 M Yes proofOfOwnership] Verify the Proof of Ownership from the client 0x03 M Yes lengthOfProofOfOwnershipClient This field indicates the length (in octets) of the proofOfOwnershipClient field proofOfOwnershipClient See 3.2.1.1 uint8[] M No lengthOfEphemeralPublicKey Client Length parameter for ephemeralPublicKey Client ephemeralPublicKeyClient See 3.2.1.2 uint16 M Yes AUTH_REQ 110 The server shall verify whether any existing authentication pending state corresponds to the client submitting the proofOfOwnership request.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	Partially Accept
REQ-AUTO-00922	77	High risk due to unclear OEM/supplier responsibility	AUTH_REQ 126 If the server cannot determine if the client does have an existing authentication pending state, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	Partially Accept
REQ-AUTO-00924	77	High risk due to unclear OEM/supplier responsibility	AUTH_REQ 128 If the server is trying to delete the authentication pending state as consequence of the client proofOfOwnership signature verification failure, and the server cannot determine that the authentication pending state was deleted, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable.security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	Partially Accept

Customer Clarifications / Open Points

Total Open Points3document-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	Question / Impact	Required Customer Decision	Recommended Supplier Position	Owner	Status
OP-002	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.	Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.	Implement configurable session/security-access on the ECU and request the customer-confirmed service-to-role table.	Shared (OEM policy / Supplier ECU)	Open
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-004	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.	Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied.	Implement authenticated, integrity-protected ECU programming with controlled boot/app state; require OEM update-chain definition.	Shared (OEM backend / Supplier ECU)	Open

Requirements From This PDF

Content / SectionSupplier PositionReview StatusSecurity CapabilityEstimation ImpactOpen Point

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-00889	Table 4 – Supported subFunctions (ISO 14229-1:2020) Name verifyCertificateBidirectional proofOfOwnership deAuthenticate AUTH_REQ 155 The server shall not accept an application-layer service 0x29 request when it is received inside an SDT (service 0x84) protected message.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	None	Application software behavior; Secure communication and freshness protection None	SSR-KEY-003	OP-002	3 subFunctions page 7 Source details Document section 3 subFunctions Section path 3 subFunctions Page reference page 7
REQ-AUTO-00892	Table 5 – verifyCertificateBidirectional Request Field Description Type/Value Cvt Included in proofOfOwnershipServer Authentication Request SID Service ID for Authentication service request 0x29 M Yes verifyCertificateBidirectional] Initiate Authentication by verifying the Certificate and generating a Proof of Ownership from the server 0x02 M Yes communicationConfiguration NOT USED 0x00 M Yes lengthOfCertificateClient Length parameter for certificateClient uint16 M Yes certificateClient The Certificate to verify uint8[] M Yes lengthOfChallengeClient Length parameter for challengeClient uint16 M Yes challengeClient See 3.1.1.1 uint8[] M Yes AUTH_REQ 117 Upon reception of a verifyCertificateBidirectional request, the server shall determine whether the Authentication delay timer is currently running.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	Authentication	Authentication None	SSR-DAI-001	OP-002	3.1.1 Request page 8 Source details Document section 3.1.1 Request Section path 3 subFunctions > 3.1 verifyCertificateBidirectional > 3.1.1 Request Page reference page 8
REQ-AUTO-00893	AUTH_REQ 118 If upon reception of verifyCertificateBidirectional request the Authentication delay timer is expired, the server shall continue to process the verifyCertificateBidirectional request.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	None	Backend and IT integration None	SSR-KEY-005	OP-003	3.1.1 Request page 8 Source details Document section 3.1.1 Request Section path 3 subFunctions > 3.1 verifyCertificateBidirectional > 3.1.1 Request Page reference page 8
REQ-AUTO-00895	AUTH_REQ 45 If the server verifies the client certificate as valid, the server shall create the requested client authentication pending state.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	Authentication	Authentication None	SSR-DAI-001	OP-003	3.1.1 Request page 8 Source details Document section 3.1.1 Request Section path 3 subFunctions > 3.1 verifyCertificateBidirectional > 3.1.1 Request Page reference page 8
REQ-AUTO-00900	AUTH_REQ 173 The server shall verify the value of lengthOfCertificateClient upon reception of verifyCertificateBidirectional request.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	None	Backend and IT integration None	SSR-KEY-005	OP-003	3.1.2 Response page 9 Source details Document section 3.1.2 Response Section path 3 subFunctions > 3.1 verifyCertificateBidirectional > 3.1.2 Response Page reference page 9
REQ-AUTO-00901	AUTH_REQ 174 If the lengthOfCertificateClient value is not within the expected range, the server shall send negative response code 0x13 (incorrectMessageLengthOrInvalidFormat).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	None	Backend and IT integration None	SSR-KEY-005	OP-003	3.1.2 Response page 9 Source details Document section 3.1.2 Response Section path 3 subFunctions > 3.1 verifyCertificateBidirectional > 3.1.2 Response Page reference page 9
REQ-AUTO-00906	3.1.3 Negative Response AUTH_REQ 121 If upon reception of verifyCertificateBidirectional request the Authentication delay timer is running, the server shall respond to the verifyCertificateBidirectional request with a Negative Response Code (NRC) 0x37, indicating requiredTimeDelayNotExpired.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	None	Backend and IT integration None	SSR-KEY-005	OP-003	3.2 proofOfOwnership page 11 Source details Document section 3.2 proofOfOwnership Section path 3 subFunctions > 3.2 proofOfOwnership Page reference page 11
REQ-AUTO-00907	AUTH_REQ 122 If the server verifies the client certificate as invalid, it shall respond to the verifyCertificateBidirectional request with a Negative Response Code (NRC) 0x10, indicating generalReject.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	Authentication	Authentication None	SSR-DAI-001	OP-003	3.2 proofOfOwnership page 11 Source details Document section 3.2 proofOfOwnership Section path 3 subFunctions > 3.2 proofOfOwnership Page reference page 11
REQ-AUTO-00908	AUTH_REQ 123 If the server fails or cannot determine that the authentication pending state was stored, it shall respond to the verifyCertificateBidirectional request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable.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	None	Backend and IT integration None	SSR-KEY-005	OP-003	3.2 proofOfOwnership page 11 Source details Document section 3.2 proofOfOwnership Section path 3 subFunctions > 3.2 proofOfOwnership Page reference page 11
REQ-AUTO-00910	Table 7 – proofOfOwnership Request Field Description Type/Value Cvt Included in proofOfOwnershipClient Authentication Request SID Service ID for 0x29 M Yes proofOfOwnership] Verify the Proof of Ownership from the client 0x03 M Yes lengthOfProofOfOwnershipClient This field indicates the length (in octets) of the proofOfOwnershipClient field proofOfOwnershipClient See 3.2.1.1 uint8[] M No lengthOfEphemeralPublicKey Client Length parameter for ephemeralPublicKey Client ephemeralPublicKeyClient See 3.2.1.2 uint16 M Yes AUTH_REQ 110 The server shall verify whether any existing authentication pending state corresponds to the client submitting the proofOfOwnership request.Proposal: Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.	Partially Accept	Proposal Ready	None	Application software behavior None	SSR-RBAC-004	OP-002	3.2.1 Request page 12 Source details Document section 3.2.1 Request Section path 3 subFunctions > 3.2 proofOfOwnership > 3.2.1 Request Page reference page 12
REQ-AUTO-00922	AUTH_REQ 126 If the server cannot determine if the client does have an existing authentication pending state, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable.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	Backend and IT integration None	SSR-COM-003	OP-004	3.2.3 Negative Response page 14 Source details Document section 3.2.3 Negative Response Section path 3 subFunctions > 3.2 proofOfOwnership > 3.2.3 Negative Response Page reference page 14
REQ-AUTO-00924	AUTH_REQ 128 If the server is trying to delete the authentication pending state as consequence of the client proofOfOwnership signature verification failure, and the server cannot determine that the authentication pending state was deleted, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable.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	Backend and IT integration; Security evidence and traceability OEM/Customer Review Interface	SSR-DAI-004	OP-004	3.2.3 Negative Response page 14 Source details Document section 3.2.3 Negative Response Section path 3 subFunctions > 3.2 proofOfOwnership > 3.2.3 Negative Response Page reference page 14
REQ-AUTO-00925	AUTH_REQ 129 If the server is deleting the authentication pending state as consequence of failure to store the authentication state, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable.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	Backend and IT integration None	SSR-TOOL-002	OP-004	3.2.3 Negative Response page 14 Source details Document section 3.2.3 Negative Response Section path 3 subFunctions > 3.2 proofOfOwnership > 3.2.3 Negative Response Page reference page 14
REQ-AUTO-00931	Internal Page 16 (31) AUTH_REQ 132 If the server is unable to delete the client's authentication state or cannot verify its presence, it shall respond to the deAuthenticate request with Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable.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	Backend and IT integration None	SSR-COM-003	OP-004	4.1 Certificate page 16 Source details Document section 4.1 Certificate Section path 4 General > 4.1 Certificate Page reference page 16
REQ-AUTO-00935	AUTH_REQ 177 The server shall use the private key corresponding to the server certificate to generate the signatures.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	Authentication	Authentication None	SSR-DAI-001	OP-003	4.1 Certificate page 16 Source details Document section 4.1 Certificate Section path 4 General > 4.1 Certificate Page reference page 16
REQ-AUTO-00937	AUTH_REQ 164 The server shall reject a received client’s certificate, sent using the verifyCertificateBidirectional subFunction, if it matches the server’s own certificate.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	Authentication	Authentication None	SSR-DAI-001	OP-003	4.1 Certificate page 16 Source details Document section 4.1 Certificate Section path 4 General > 4.1 Certificate Page reference page 16
REQ-AUTO-00938	AUTH_INFO 7 It should not be possible to “unlock” the server using its own key/certificate.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	Authentication	Authentication None	SSR-DAI-001	OP-003	4.1 Certificate page 16 Source details Document section 4.1 Certificate Section path 4 General > 4.1 Certificate Page reference page 16
REQ-AUTO-00939	AUTH_REQ 165 The server shall verify the client certificate, sent using the verifyCertificateBidirectional subFunction, according to Figure 3.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	Authentication	Authentication None	SSR-DAI-001	OP-003	4.1 Certificate page 16 Source details Document section 4.1 Certificate Section path 4 General > 4.1 Certificate Page reference page 16
REQ-AUTO-00940	AUTH_REQ 134 The server shall verify the Signature of the Client certificate using the AUTH-CA EMP entity public key.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	Authentication	Authentication None	SSR-DAI-001	OP-003	4.1 Certificate page 16 Source details Document section 4.1 Certificate Section path 4 General > 4.1 Certificate Page reference page 16
REQ-AUTO-00942	AUTH_REQ 9 • If the server NodeUID is not found in the NodeUID extension, the server shall reject the certificate and generate NRC 0x10 (generalReject).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	Authentication	Authentication None	SSR-DAI-001	OP-003	4.1.3 D-RBACC extension page 18 Source details Document section 4.1.3 D-RBACC extension Section path 4 General > 4.1 Certificate > 4.1.3 D-RBACC extension Page reference page 18
REQ-AUTO-00950	Internal Page 19 (31) As part of the certificate verification: AUTH_REQ 135 • The server shall validate the D-RBACC by parsing all its content.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	Authentication	Authentication; Security evidence and traceability OEM/Customer Review Interface	SSR-DAI-001	OP-003	4.1.8 Certificate Validity Time page 19 Source details Document section 4.1.8 Certificate Validity Time Section path 4 General > 4.1 Certificate > 4.1.8 Certificate Validity Time Page reference page 19
REQ-AUTO-00951	If content is invalid, the certificate is invalid and the server shall return a Negative Response Code (NRC) 0x10, indicating generalReject.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	Certificate handling	Certificate handling None	SSR-KEY-002	OP-003	4.1.8 Certificate Validity Time page 19 Source details Document section 4.1.8 Certificate Validity Time Section path 4 General > 4.1 Certificate > 4.1.8 Certificate Validity Time Page reference page 19
REQ-AUTO-00953	If non-compliant, the certificate is invalid and the server shall return a Negative Response Code (NRC) 0x10, indicating generalReject.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	Certificate handling	Certificate handling None	SSR-KEY-002	OP-003	4.1.8 Certificate Validity Time page 19 Source details Document section 4.1.8 Certificate Validity Time Section path 4 General > 4.1 Certificate > 4.1.8 Certificate Validity Time Page reference page 19
REQ-AUTO-00960	4.1.8 Certificate Validity Time AUTH_REQ 169 The server shall validate the certificate so that: 𝑛𝑜𝑡𝐵𝑒𝑓𝑜𝑟𝑒 ≤ 𝐶𝑒𝑟𝑡𝑖𝑓𝑖𝑐𝑎𝑡𝑒-𝑡𝑖𝑚𝑒 ≤ 𝑛𝑜𝑡𝐴𝑓𝑡𝑒𝑟 AUTH_INFO 137 The notBefore and notAfter are received as fields in the certificate while Certificate-Time is the EMP entity defined in CVS34.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	Authentication	Authentication None	SSR-DAI-001	OP-003	4.1.8 Certificate Validity Time page 19 Source details Document section 4.1.8 Certificate Validity Time Section path 4 General > 4.1 Certificate > 4.1.8 Certificate Validity Time Page reference page 19
REQ-AUTO-00962	AUTH_REQ 156 If a server reset is triggered by a client request (e.g., UDS service 0x11), the server shall send the corresponding response before invalidating the authentication pending state.Proposal: Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.	Partially Accept	Proposal Ready	None	Application software behavior None	SSR-DIAG-004	OP-002	4.2 State-keeping page 20 Source details Document section 4.2 State-keeping Section path 4 General > 4.2 State-keeping Page reference page 20
REQ-AUTO-00964	AUTH_REQ 157 If a server reset is triggered by a client request (e.g., UDS service 0x11), the server shall send the corresponding response before invalidating the authentication state.Proposal: Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.	Partially Accept	Proposal Ready	None	Application software behavior None	SSR-DIAG-004	OP-002	4.2 State-keeping page 20 Source details Document section 4.2 State-keeping Section path 4 General > 4.2 State-keeping Page reference page 20
REQ-AUTO-00967	AUTH_REQ 147 • Client roles (ECU diagnostic Role extension in client’s certificate) AUTH_REQ 148 • Client D-RBACC, if provided in the client’s certificate AUTH_REQ 149 The server shall support only one authentication state.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	Authentication	Authentication None	SSR-RBAC-002	OP-002	4.2 State-keeping page 21 Source details Document section 4.2 State-keeping Section path 4 General > 4.2 State-keeping Page reference page 21
REQ-AUTO-00973	Internal Page 23 (31) 4.6 Role Based Access Control AUTH_REQ 25 The server shall always allow the Authentication 0x29 service (ISO 14229-1:2020) regardless of the RBAC logic (CVS151).Proposal: Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.	Partially Accept	Proposal Ready	None	Application software behavior None	SSR-RBAC-004	OP-002	4.7.1 TimeBasedPassiveDeAuthentication page 23 Source details Document section 4.7.1 TimeBasedPassiveDeAuthentication Section path 4 General > 4.7 PassiveDeAuthentication > 4.7.1 TimeBasedPassiveDeAuthentication Page reference page 23
REQ-AUTO-00982	AUTH_REQ 151 If the delay timer is not running, the server shall start it as part of verifyCertificateBidirectional request.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	None	Backend and IT integration None	SSR-KEY-005	OP-003	4.9 Authentication completion timer page 24 Source details Document section 4.9 Authentication completion timer Section path 4 General > 4.9 Authentication completion timer Page reference page 24
REQ-AUTO-00890	If such an encapsulated 0x29 request is detected, the server shall return application-layer NRC 0x39, provided as a correctly formatted SDT positive response.Proposal: Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.	Partially Accept	Proposal Ready	None	Application software behavior; Secure communication and freshness protection None	SSR-RBAC-004	OP-002	3 subFunctions page 7 Source details Document section 3 subFunctions Section path 3 subFunctions Page reference page 7
REQ-AUTO-00930	AUTH_REQ 131 If the server cannot determine that the client is currently authenticated, it shall respond to the deAuthenticate request with a Negative Response Code (NRC) 0x94, indicating a ResourceTemporarilyNotAvailable.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	Backend and IT integration None	SSR-COM-003	OP-004	3.3.3 Negative Response page 15 Source details Document section 3.3.3 Negative Response Section path 3 subFunctions > 3.3 deAuthenticate > 3.3.3 Negative Response Page reference page 15
REQ-AUTO-00896	Internal Page 9 (31) AUTH_REQ 119 If an authentication pending state already exists, the server shall replace the existing authentication pending state with the new one.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	Backend and IT integration None	SSR-TOOL-002	-	3.1.2 Response page 9 Source details Document section 3.1.2 Response Section path 3 subFunctions > 3.1 verifyCertificateBidirectional > 3.1.2 Response Page reference page 9
REQ-AUTO-00903	AUTH_REQ 120 Upon positively responding, the server shall start the Authentication completion timer.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	Backend and IT integration None	SSR-TOOL-002	-	3.1.2 Response page 9 Source details Document section 3.1.2 Response Section path 3 subFunctions > 3.1 verifyCertificateBidirectional > 3.1.2 Response Page reference page 9
REQ-AUTO-00904	ephemeralPublicKeyServer See 3.1.2.3 uint8[] M Yes 3.1.2.1 challengeServer AUTH_REQ 6 The challengeServer field shall consists of 32 octets generated using a CRNG.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	System behavior None	SSR-SYS-006	-	3.1.2 Response page 10 Source details Document section 3.1.2 Response Section path 3 subFunctions > 3.1 verifyCertificateBidirectional > 3.1.2 Response Page reference page 10
REQ-AUTO-00911	AUTH_REQ 111 If an existing authentication pending state is found, the server shall verify if the Authentication completion timer is currently running.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	Backend and IT integration None	SSR-TOOL-002	-	3.2.1 Request page 12 Source details Document section 3.2.1 Request Section path 3 subFunctions > 3.2 proofOfOwnership > 3.2.1 Request Page reference page 12
REQ-AUTO-00912	AUTH_REQ 112 If the Authentication completion timer is currently running, the server shall continue to process the client’s proofOfOwnership request.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	Backend and IT integration None	SSR-TOOL-002	-	3.2.1 Request page 12 Source details Document section 3.2.1 Request Section path 3 subFunctions > 3.2 proofOfOwnership > 3.2.1 Request Page reference page 12
REQ-AUTO-00913	AUTH_REQ 113 If the client proofOfOwnership signature verification fails, the server shall delete the authentication pending state connected to the client submitting the proofOfOwnership request.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	Backend and IT integration; Security evidence and traceability OEM/Customer Review Interface	SSR-DAI-004	-	3.2.1 Request page 12 Source details Document section 3.2.1 Request Section path 3 subFunctions > 3.2 proofOfOwnership > 3.2.1 Request Page reference page 12
REQ-AUTO-00914	AUTH_REQ 114 If the server fails or cannot determine that the authentication state was stored, the server shall delete the authentication pending state connected to the client submitting the proofOfOwnership request.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	Backend and IT integration None	SSR-COM-003	-	3.2.1 Request page 12 Source details Document section 3.2.1 Request Section path 3 subFunctions > 3.2 proofOfOwnership > 3.2.1 Request Page reference page 12
REQ-AUTO-00915	AUTH_REQ 115 If the client’s proofOfOwnership signature is successfully verified, the server shall establish a new authentication state for the client.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	Backend and IT integration None	SSR-DAI-004	-	3.2.1 Request page 12 Source details Document section 3.2.1 Request Section path 3 subFunctions > 3.2 proofOfOwnership > 3.2.1 Request Page reference page 12
REQ-AUTO-00916	Internal Page 13 (31) If an active authentication state already exists, the server shall replace the existing state with the newly established one.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	Backend and IT integration None	SSR-TOOL-002	-	3.2.2 Response page 13 Source details Document section 3.2.2 Response Section path 3 subFunctions > 3.2 proofOfOwnership > 3.2.2 Response Page reference page 13
REQ-AUTO-00920	3.2.3 Negative Response AUTH_REQ 124 If the server determines that the client does not have an existing authentication pending state, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x24, indicating requestSequenceError.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	Backend and IT integration None	SSR-TOOL-002	-	3.2.3 Negative Response page 14 Source details Document section 3.2.3 Negative Response Section path 3 subFunctions > 3.2 proofOfOwnership > 3.2.3 Negative Response Page reference page 14
REQ-AUTO-00921	AUTH_REQ 125 If the server determines that the client have an existing authentication pending state and the Authentication completion timer is expired, the server shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x24, indicating requestSequenceError.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	Backend and IT integration None	SSR-TOOL-002	-	3.2.3 Negative Response page 14 Source details Document section 3.2.3 Negative Response Section path 3 subFunctions > 3.2 proofOfOwnership > 3.2.3 Negative Response Page reference page 14
REQ-AUTO-00923	AUTH_REQ 127 If the server is trying to delete the authentication pending state as consequence of the client proofOfOwnership signature verification failure, and the server determines that the authentication pending state was deleted, it shall respond to the proofOfOwnership request with a Negative Response Code (NRC) 0x10, indicating generalReject.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	Backend and IT integration; Security evidence and traceability OEM/Customer Review Interface	SSR-DAI-004	-	3.2.3 Negative Response page 14 Source details Document section 3.2.3 Negative Response Section path 3 subFunctions > 3.2 proofOfOwnership > 3.2.3 Negative Response Page reference page 14
REQ-AUTO-00928	0x00 – 0xFF M AUTH_REQ 158 The server shall delete/invalidate the client’s authentication prior to positively responding to the deAuthenticate request.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	Backend and IT integration None	SSR-TOOL-002	-	3.3.3 Negative Response page 15 Source details Document section 3.3.3 Negative Response Section path 3 subFunctions > 3.3 deAuthenticate > 3.3.3 Negative Response Page reference page 15
REQ-AUTO-00961	Internal Page 20 (31) 4.2 State-keeping The server shall invalidate the authentication pending state in the event of: AUTH_REQ 138 • The server is reset (i.e server is power cycled).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	Backend and IT integration None	SSR-TOOL-002	-	4.2 State-keeping page 20 Source details Document section 4.2 State-keeping Section path 4 General > 4.2 State-keeping Page reference page 20
REQ-AUTO-00963	If a client and server have successfully completed the authentication process, the server shall invalidate the authentication state in the event of: AUTH_REQ 16 • The server is reset (i.e server is power cycled).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	Backend and IT integration None	SSR-TOOL-002	-	4.2 State-keeping page 20 Source details Document section 4.2 State-keeping Section path 4 General > 4.2 State-keeping Page reference page 20
REQ-AUTO-00965	The server’s authentication pending state shall contain the minimum of (non-exhaustive list): AUTH_REQ 140 • Client address that issued the authentication request.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	Backend and IT integration None	SSR-TOOL-002	-	4.2 State-keeping page 20 Source details Document section 4.2 State-keeping Section path 4 General > 4.2 State-keeping Page reference page 20
REQ-AUTO-00966	The server’s authentication state shall contain the minimum of (non-exhaustive list): AUTH_REQ 21 • SessionKey.Proposal: Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.	Partially Accept	Proposal Ready	None	Backend and IT integration None	SSR-TOOL-002	-	4.2 State-keeping page 21 Source details Document section 4.2 State-keeping Section path 4 General > 4.2 State-keeping Page reference page 21
REQ-AUTO-00968	AUTH_REQ 150 The server shall support only one authentication pending state.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	Backend and IT integration None	SSR-TOOL-003	-	4.2 State-keeping page 21 Source details Document section 4.2 State-keeping Section path 4 General > 4.2 State-keeping Page reference page 21
REQ-AUTO-00971	AUTH_REQ 24 The server shall ensure that the sessionKey is exclusively used for the application responsible for communication over securedDataTransmission (CVS32).Proposal: Partially accept. Supplier can implement ECU-side UDS/session/security-access behavior; customer must confirm the service-to-role table, diagnostic authorization policy, and acceptance criteria.	Partially Accept	Proposal Ready	None	Application software behavior None	SSR-SYS-008	-	4.5 CRNG page 22 Source details Document section 4.5 CRNG Section path 4 General > 4.5 CRNG Page reference page 22
REQ-AUTO-00975	4.7.1 TimeBasedPassiveDeAuthentication AUTH_REQ 26 The server shall start the timer (A3) after a valid proofOfOwnership has been received.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	Backend and IT integration None	SSR-TOOL-003	-	4.7.1 TimeBasedPassiveDeAuthentication page 23 Source details Document section 4.7.1 TimeBasedPassiveDeAuthentication Section path 4 General > 4.7 PassiveDeAuthentication > 4.7.1 TimeBasedPassiveDeAuthentication Page reference page 23
REQ-AUTO-00977	AUTH_REQ 28 If the A3 timer timeouts before a new request is received (from the same client), the server shall invalidate the authentication state.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	Backend and IT integration None	SSR-TOOL-003	-	4.7.1 TimeBasedPassiveDeAuthentication page 23 Source details Document section 4.7.1 TimeBasedPassiveDeAuthentication Section path 4 General > 4.7 PassiveDeAuthentication > 4.7.1 TimeBasedPassiveDeAuthentication Page reference page 23
REQ-AUTO-00983	AUTH_REQ 152 If the server can determine that a delay is not running after reset, it shall accept a subsequent authentication request without any delay.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	Backend and IT integration None	SSR-COM-003	-	4.9 Authentication completion timer page 24 Source details Document section 4.9 Authentication completion timer Section path 4 General > 4.9 Authentication completion timer Page reference page 24
REQ-AUTO-00984	AUTH_REQ 153 If the server cannot determine that a delay is not running after reset, it shall not accept a subsequent authentication request without any delay.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	Backend and IT integration None	SSR-COM-003	-	4.9 Authentication completion timer page 24 Source details Document section 4.9 Authentication completion timer Section path 4 General > 4.9 Authentication completion timer Page reference page 24
REQ-AUTO-00886	It contains the information required for the server to verify the client’s subsequent request and to generate the corresponding response.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	Backend and IT integration None	SSR-TOOL-002	-	2 Abbrevations page 6 Source details Document section 2 Abbrevations Section path 2 Abbrevations Page reference page 6
REQ-AUTO-00887	It contains the information required for the server to maintain continuous authenticated communication with the client and to generate authenticated responses.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	Backend and IT integration None	SSR-COM-003	-	2 Abbrevations page 6 Source details Document section 2 Abbrevations Section path 2 Abbrevations Page reference page 6
REQ-AUTO-00894	AUTH_INFO 24 The column “Included in proofOfOwnershipServer”, present in several message-definition tables, indicates whether the corresponding field shall be covered by the proofOfOwnershipServer signature computed by the server and included in its response.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	Backend and IT integration None	SSR-DAI-004	-	3.1.1 Request page 8 Source details Document section 3.1.1 Request Section path 3 subFunctions > 3.1 verifyCertificateBidirectional > 3.1.1 Request Page reference page 8
REQ-AUTO-00948	AUTH_REQ 14 If D-RBACC extension is detected, the server shall overrule the RBACC with the D-RBACC permissions.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	Backend and IT integration None	SSR-RBAC-003	-	4.1.3 D-RBACC extension page 18 Source details Document section 4.1.3 D-RBACC extension Section path 4 General > 4.1 Certificate > 4.1.3 D-RBACC extension Page reference page 18
REQ-AUTO-00949	AUTH_INFO 61 This means that if D-RBACC logic denies/permits certain access, the server shall deny/permit the access regardless of what RBACC logic permits/denies.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	Application software behavior None	SSR-RBAC-004	-	4.1.3 D-RBACC extension page 18 Source details Document section 4.1.3 D-RBACC extension Section path 4 General > 4.1 Certificate > 4.1.3 D-RBACC extension Page reference page 18
REQ-AUTO-00952	AUTH_REQ 136 • The server shall verify that the D-RBACC version provided by the client is compatible with the server’s supported D-RBACC version.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	Backend and IT integration None	SSR-RBAC-003	-	4.1.8 Certificate Validity Time page 19 Source details Document section 4.1.8 Certificate Validity Time Section path 4 General > 4.1 Certificate > 4.1.8 Certificate Validity Time Page reference page 19
REQ-AUTO-00891	Internal Page 8 (31) 3.1 verifyCertificateBidirectional 3.1.1 Request AUTH_REQ 2 The request for verifyCertificateBidirectional subfunction shall be formatted according to Table 5.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.	Accept with Assumption	Proposal Ready	None	System behavior None	SSR-KEY-004	-	3.1.1 Request page 8 Source details Document section 3.1.1 Request Section path 3 subFunctions > 3.1 verifyCertificateBidirectional > 3.1.1 Request Page reference page 8
REQ-AUTO-00899	3.1.1.2 lengthOfCertificateClient AUTH_REQ 172 The expected range values of lengthOfCertificateClient shall be from 0x00C8 to 0x0800.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.	Accept with Assumption	Proposal Ready	None	System behavior None	SSR-KEY-004	-	3.1.2 Response page 9 Source details Document section 3.1.2 Response Section path 3 subFunctions > 3.1 verifyCertificateBidirectional > 3.1.2 Response Page reference page 9
REQ-AUTO-00902	3.1.2 Response AUTH_REQ 5 The response for verifyCertificateBidirectional subfunction shall be formatted according to Table 6.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.	Accept with Assumption	Proposal Ready	None	System behavior None	SSR-KEY-004	-	3.1.2 Response page 9 Source details Document section 3.1.2 Response Section path 3 subFunctions > 3.1 verifyCertificateBidirectional > 3.1.2 Response Page reference page 9
REQ-AUTO-00927	Table 9 – deAuthenticate request message layout Field Description Type/Value Cvt Authentication Request SID Service ID for 0x29 M SubFunction = [AuthenticationTask = deAuthenticate] Subfunction for request to leave the authenticated state 0x00 M 3.3.2 Response AUTH_REQ 96 The response for deAuthenticate subfunction shall be formatted according to Table 10.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	None	Application software behavior None	SSR-RBAC-004	-	3.3.3 Negative Response page 15 Source details Document section 3.3.3 Negative Response Section path 3 subFunctions > 3.3 deAuthenticate > 3.3.3 Negative Response Page reference page 15
REQ-AUTO-00933	4 General 4.1 Certificate AUTH_REQ 175 The signature algorithm used throughout the authentication process shall be ED25519.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.	Accept with Assumption	Proposal Ready	Authentication	Authentication None	SSR-DAI-001	-	4.1 Certificate page 16 Source details Document section 4.1 Certificate Section path 4 General > 4.1 Certificate Page reference page 16
REQ-AUTO-00934	AUTH_REQ 176 The client shall use the private key corresponding to the client certificate to generate the signatures.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.	Accept with Assumption	Proposal Ready	Authentication	Authentication None	SSR-DAI-001	-	4.1 Certificate page 16 Source details Document section 4.1 Certificate Section path 4 General > 4.1 Certificate Page reference page 16
REQ-AUTO-00936	AUTH_REQ 163 The format and the structure of the certificates shall be based on (CVS30).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.	Accept with Assumption	Proposal Ready	None	System behavior None	SSR-KEY-004	-	4.1 Certificate page 16 Source details Document section 4.1 Certificate Section path 4 General > 4.1 Certificate Page reference page 16
REQ-AUTO-00943	AUTH_REQ 106 If the NodeUID extension is not detected, the operation shall continue as in AUTH_INFO 25 A certificate without NodeUID extension implies that the certificate is applicable for any NodeUID.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.	Accept with Assumption	Proposal Ready	Authentication	Authentication None	SSR-DAI-001	-	4.1.3 D-RBACC extension page 18 Source details Document section 4.1.3 D-RBACC extension Section path 4 General > 4.1 Certificate > 4.1.3 D-RBACC extension Page reference page 18
REQ-AUTO-00944	4.1.2 ECU-Diagnostic Role extension AUTH_REQ 170 The ECU-Diagnostic role extension shall be included in the client certificate.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.	Accept with Assumption	Proposal Ready	Authentication	Authentication None	SSR-RBAC-002	-	4.1.3 D-RBACC extension page 18 Source details Document section 4.1.3 D-RBACC extension Section path 4 General > 4.1 Certificate > 4.1.3 D-RBACC extension Page reference page 18
REQ-AUTO-00955	4.1.5 Key Usage extension AUTH_REQ 15 The Key Usage extension (RFC 5280) shall be included in the client certificate.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.	Accept with Assumption	Proposal Ready	Authentication	Authentication None	SSR-DAI-001	-	4.1.8 Certificate Validity Time page 19 Source details Document section 4.1.8 Certificate Validity Time Section path 4 General > 4.1 Certificate > 4.1.8 Certificate Validity Time Page reference page 19
REQ-AUTO-00956	AUTH_REQ 47 The Key Usage extension shall contain DigitalSignature.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 None	SSR-DAI-001	-	4.1.8 Certificate Validity Time page 19 Source details Document section 4.1.8 Certificate Validity Time Section path 4 General > 4.1 Certificate > 4.1.8 Certificate Validity Time Page reference page 19
REQ-AUTO-00957	4.1.6 Extended Key Usage extension AUTH_REQ 95 The Extended Key Usage extension (RFC 5280) shall be included in the client certificate.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.	Accept with Assumption	Proposal Ready	Authentication	Authentication None	SSR-DAI-001	-	4.1.8 Certificate Validity Time page 19 Source details Document section 4.1.8 Certificate Validity Time Section path 4 General > 4.1 Certificate > 4.1.8 Certificate Validity Time Page reference page 19
REQ-AUTO-00958	AUTH_REQ 107 The extension ExtendedKeyUsage shall contain clientAuth (1.3.6.1.5.5.7.3.2).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-006	-	4.1.8 Certificate Validity Time page 19 Source details Document section 4.1.8 Certificate Validity Time Section path 4 General > 4.1 Certificate > 4.1.8 Certificate Validity Time Page reference page 19
REQ-AUTO-00969	AUTH_REQ 167 The private keys shall be generated using a CRNG.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-KEY-004	-	4.5 CRNG page 22 Source details Document section 4.5 CRNG Section path 4 General > 4.5 CRNG Page reference page 22
REQ-AUTO-00970	AUTH_REQ 168 The sessionKey shall be generated according to the pseudo code below.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	None	System behavior None	SSR-SYS-006	-	4.5 CRNG page 22 Source details Document section 4.5 CRNG Section path 4 General > 4.5 CRNG Page reference page 22
REQ-AUTO-00974	AUTH_REQ 109 Only Passive time-based de-authentication shall be supported.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-006	-	4.7.1 TimeBasedPassiveDeAuthentication page 23 Source details Document section 4.7.1 TimeBasedPassiveDeAuthentication Section path 4 General > 4.7 PassiveDeAuthentication > 4.7.1 TimeBasedPassiveDeAuthentication Page reference page 23
REQ-AUTO-00980	Internal Page 24 (31) 4.8 Authentication delay timer AUTH_INFO 38 The delay timer represents the required minimum time between verifyCertificateBidirectional request attempts.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.	Accept with Assumption	Proposal Ready	None	System behavior None	SSR-KEY-004	-	4.9 Authentication completion timer page 24 Source details Document section 4.9 Authentication completion timer Section path 4 General > 4.9 Authentication completion timer Page reference page 24
REQ-AUTO-00985	AUTH_REQ 154 The Authentication completion timer shall be set to 1 minute.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-006	-	4.9 Authentication completion timer page 24 Source details Document section 4.9 Authentication completion timer Section path 4 General > 4.9 Authentication completion timer Page reference page 24
REQ-AUTO-00932	AUTH_INFO 133 If the server is unable to delete the client’s authentication state or cannot retrieve it due to internal errors, the server responds NRC 0x94.This informs the client that the authentication state may still exist on the server.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	-	4.1 Certificate page 16 Source details Document section 4.1 Certificate Section path 4 General > 4.1 Certificate Page reference page 16
REQ-AUTO-00947	While the ECU-Diagnostic Role extension specifies the roles assigned to a client, the D-RBACC extension may both grant additional permissions and restrict permissions beyond those derived from the client’s roles.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	-	4.1.3 D-RBACC extension page 18 Source details Document section 4.1.3 D-RBACC extension Section path 4 General > 4.1 Certificate > 4.1.3 D-RBACC extension Page reference page 18
REQ-AUTO-00979	AUTH_INFO 14 The A3 timer differs from S3 timer in terms of expected behavior during timeout and should not be implemented as a single timer.Proposal: Needs internal review. Confirm whether this should-level requirement is in the committed baseline.	Needs Internal Review	Reviewed Internally	None	System behavior None	None	-	4.7.1 TimeBasedPassiveDeAuthentication page 23 Source details Document section 4.7.1 TimeBasedPassiveDeAuthentication Section path 4 General > 4.7 PassiveDeAuthentication > 4.7.1 TimeBasedPassiveDeAuthentication Page reference page 23
REQ-AUTO-00885	Shall be agreed between the supplier and 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-005	-	2 Abbrevations page 6 Source details Document section 2 Abbrevations Section path 2 Abbrevations Page reference page 6
REQ-AUTO-00905	AUTH_REQ 7 The proof/signature shall be generated according to the pseudo code below.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-DAI-002	-	3.2 proofOfOwnership page 11 Source details Document section 3.2 proofOfOwnership Section path 3 subFunctions > 3.2 proofOfOwnership Page reference page 11
REQ-AUTO-00919	AUTH_REQ 162 The signature shall be generated according to the pseudo code below.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-DAI-002	-	3.2.3 Negative Response page 14 Source details Document section 3.2.3 Negative Response Section path 3 subFunctions > 3.2 proofOfOwnership > 3.2.3 Negative Response Page reference page 14
REQ-AUTO-00945	AUTH_REQ 13 The roles shall correspond to a bit pattern-octet string.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-006	-	4.1.3 D-RBACC extension page 18 Source details Document section 4.1.3 D-RBACC extension Section path 4 General > 4.1 Certificate > 4.1.3 D-RBACC extension Page reference page 18
REQ-AUTO-00946	AUTH_INFO 8 The interpretation of the roles should follow as the example below: • Role 1 -> 0000 0000 0000 0000 0000 0000 0000 0001 – 00 00 00 01 • Role 32 -> 1000 0000 0000 0000 0000 0000 0000 0000 – 80 00 00 00 • Role 2 and 4 -> 0000 0000 0000 0000 0000 0000 0000 1010 – 00 00 00 0A.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-006	-	4.1.3 D-RBACC extension page 18 Source details Document section 4.1.3 D-RBACC extension Section path 4 General > 4.1 Certificate > 4.1.3 D-RBACC extension Page reference page 18
REQ-AUTO-00959	4.1.7 SignatureAlgorithm AUTH_REQ 105 The extension SignatureAlgorithm shall contain ED25519 (1.3.101.112).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-DAI-002	-	4.1.8 Certificate Validity Time page 19 Source details Document section 4.1.8 Certificate Validity Time Section path 4 General > 4.1 Certificate > 4.1.8 Certificate Validity Time Page reference page 19
REQ-AUTO-00879	The User shall apply the latest version of this CVS31.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-005	-	page-1 Page 1 page 1 Source details Document section page-1 Page 1 Section path Page 1 Page reference page 1
REQ-AUTO-00881	Any review of CVS31 shall only be done in agreement with the involved departments stated in the table on the first page under section “Technical responsibility”.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-009	-	page-3 Page 3 page 3 Source details Document section page-3 Page 3 Section path Page 3 Page reference page 3
REQ-AUTO-00882	The whole standard has been reworked and shall be read in its entirety.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-005	-	page-3 Page 3 page 3 Source details Document section page-3 Page 3 Section path Page 3 Page reference page 3
REQ-AUTO-00883	• Affiliate means any legal entity that directly or indirectly controls, is controlled by, or is commonly controlled with TRATON SE, it is being understood that “control” shall mean ownership of at least 50% of the voting rights or interest in the issued share capital, including for the avoidance of doubt any branch.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	Backend and IT integration None	SSR-TOOL-002	-	page-3 Page 3 page 3 Source details Document section page-3 Page 3 Section path Page 3 Page reference page 3
REQ-AUTO-00884	Any deviations from this specification shall be documented and must be reviewed 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-005	-	1.1 Summary page 4 Source details Document section 1.1 Summary Section path 1 Scope > 1.1 Summary Page reference page 4
REQ-AUTO-00888	AUTH_REQ 1 The server shall only support subfunctions in Table 4.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	Backend and IT integration None	SSR-TOOL-002	-	3 subFunctions page 7 Source details Document section 3 subFunctions Section path 3 subFunctions Page reference page 7
REQ-AUTO-00897	3.1.1.1 challengeClient AUTH_REQ 3 This field shall consists of 32 octets.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-005	-	3.1.2 Response page 9 Source details Document section 3.1.2 Response Section path 3 subFunctions > 3.1 verifyCertificateBidirectional > 3.1.2 Response Page reference page 9
REQ-AUTO-00898	AUTH_REQ 4 The challengeClient (ISO 14229-1:2020) shall be generated using a CRNG.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-009	-	3.1.2 Response page 9 Source details Document section 3.1.2 Response Section path 3 subFunctions > 3.1 verifyCertificateBidirectional > 3.1.2 Response Page reference page 9
REQ-AUTO-00909	Internal Page 12 (31) 3.2.1 Request AUTH_REQ 8 The request for proofOfOwnership subfunction shall be defined according to Table 7.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-006	-	3.2.1 Request page 12 Source details Document section 3.2.1 Request Section path 3 subFunctions > 3.2 proofOfOwnership > 3.2.1 Request Page reference page 12
REQ-AUTO-00917	AUTH_REQ 160 The proofOfOwnershipClient shall be generated according to the pseudo code below.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-006	-	3.2.2 Response page 13 Source details Document section 3.2.2 Response Section path 3 subFunctions > 3.2 proofOfOwnership > 3.2.2 Response Page reference page 13
REQ-AUTO-00918	3.2.2 Response AUTH_REQ 161 The response for proofOfOwnership subfunction shall be according to Table 8.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-006	-	3.2.2 Response page 13 Source details Document section 3.2.2 Response Section path 3 subFunctions > 3.2 proofOfOwnership > 3.2.2 Response Page reference page 13
REQ-AUTO-00926	3.3.1 Request AUTH_REQ 159 The request for deAuthenticate subfunction shall be formatted according to Table 9.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-006	-	3.3.3 Negative Response page 15 Source details Document section 3.3.3 Negative Response Section path 3 subFunctions > 3.3 deAuthenticate > 3.3.3 Negative Response Page reference page 15
REQ-AUTO-00929	3.3.3 Negative Response AUTH_REQ 130 If the server determines that the client is not currently authenticated, it shall respond to the deAuthenticate request with a Negative Response Code (NRC) 0x24, indicating a requestSequenceError.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	Backend and IT integration None	SSR-TOOL-002	-	3.3.3 Negative Response page 15 Source details Document section 3.3.3 Negative Response Section path 3 subFunctions > 3.3 deAuthenticate > 3.3.3 Negative Response Page reference page 15
REQ-AUTO-00941	Internal Page 18 (31) 4.1.1 NodeUID extension If the NodeUID extension is detected, the server shall: AUTH_REQ 166 • Check if the NodeUID of the server is present in the NodeUIDs extension.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	Backend and IT integration None	SSR-TOOL-002	-	4.1.3 D-RBACC extension page 18 Source details Document section 4.1.3 D-RBACC extension Section path 4 General > 4.1 Certificate > 4.1.3 D-RBACC extension Page reference page 18
REQ-AUTO-00954	4.1.4 basicContraints extension AUTH_REQ 42 The basicConstraints extension CA field shall be False.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-006	-	4.1.8 Certificate Validity Time page 19 Source details Document section 4.1.8 Certificate Validity Time Section path 4 General > 4.1 Certificate > 4.1.8 Certificate Validity Time Page reference page 19
REQ-AUTO-00972	4.5 CRNG AUTH_REQ 33 Solution for a CRNG shall be according to (CVS150).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-006	-	4.5 CRNG page 22 Source details Document section 4.5 CRNG Section path 4 General > 4.5 CRNG Page reference page 22
REQ-AUTO-00976	AUTH_REQ 27 The server shall restart the timer (A3) every time a request is received by the same client.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	Backend and IT integration None	SSR-TOOL-003	-	4.7.1 TimeBasedPassiveDeAuthentication page 23 Source details Document section 4.7.1 TimeBasedPassiveDeAuthentication Section path 4 General > 4.7 PassiveDeAuthentication > 4.7.1 TimeBasedPassiveDeAuthentication Page reference page 23
REQ-AUTO-00978	AUTH_REQ 29 The parameter for passive timeout based deAuthenticate shall be decided in the project.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-006	-	4.7.1 TimeBasedPassiveDeAuthentication page 23 Source details Document section 4.7.1 TimeBasedPassiveDeAuthentication Section path 4 General > 4.7 PassiveDeAuthentication > 4.7.1 TimeBasedPassiveDeAuthentication Page reference page 23
REQ-AUTO-00981	AUTH_REQ 133 The delay timer shall be set to 1 second.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-006	-	4.9 Authentication completion timer page 24 Source details Document section 4.9 Authentication completion timer Section path 4 General > 4.9 Authentication completion timer Page reference page 24
REQ-AUTO-00986	Internal Page 29 (31) Annex B (informative) Change history Release Date Changes The whole standard has been reworked and shall be read in its entirety.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-006	-	6 Normative references page 29 Source details Document section 6 Normative references Section path 6 Normative references Page reference page 29
REQ-AUTO-00880	Internal Page 3 (31) Foreword This CVS31 contains requirement specification for TRATON GROUP and may be used by all within TRATON Group, if applicable.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	-	page-3 Page 3 page 3 Source details Document section page-3 Page 3 Section path Page 3 Page reference page 3

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-003	Backend and IT integration — Secure Communication and Boundary ControlThe ECU shall restrict and protect communication for Backend and IT integration, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.From this PDF: REQ-AUTO-00887; REQ-AUTO-00914; REQ-AUTO-00922; REQ-AUTO-00930; REQ-AUTO-00931; REQ-AUTO-00983; REQ-AUTO-00984. This SSR is also supported by requirements from other PDFs.	Backend and IT integration	None	None	Shared	Blocked by Customer Clarification	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-AUTO-00892; REQ-AUTO-00895; REQ-AUTO-00907; REQ-AUTO-00933; REQ-AUTO-00934; REQ-AUTO-00935; REQ-AUTO-00937; REQ-AUTO-00938; REQ-AUTO-00939; REQ-AUTO-00940; REQ-AUTO-00942; REQ-AUTO-00943; REQ-AUTO-00950; REQ-AUTO-00955; REQ-AUTO-00956; REQ-AUTO-00957; REQ-AUTO-00960. This SSR is also supported by requirements from other PDFs.	Authentication	Authentication	OEM/Customer Review Interface	Shared	Blocked by Customer Clarification	Review + Test
SSR-DAI-002	System behavior — Data Authenticity and Integrity VerificationThe ECU shall verify the authenticity and integrity of System behavior data and reject manipulated or unauthenticated data.From this PDF: REQ-AUTO-00905; REQ-AUTO-00919; REQ-AUTO-00959. This SSR is also supported by requirements from other PDFs.	System behavior	None	OEM/Customer Review Interface	Supplier-Owned	Candidate	Review + Test
SSR-DAI-004	Backend and IT integration — Data Authenticity and Integrity VerificationThe ECU shall verify the authenticity and integrity of Backend and IT integration data and reject manipulated or unauthenticated data.From this PDF: REQ-AUTO-00894; REQ-AUTO-00913; REQ-AUTO-00915; REQ-AUTO-00923; REQ-AUTO-00924. This SSR is also supported by requirements from other PDFs.	Backend and IT integration	None	OEM/Customer Review Interface	Shared	Blocked by Customer Clarification	Review + Test
SSR-DIAG-004	Application software behavior — Diagnostic ServicesThe ECU shall provide the diagnostic services for Application software behavior required by the allocated customer requirements, including the specified services, sessions and data identifiers.From this PDF: REQ-AUTO-00962; REQ-AUTO-00964. This SSR is also supported by requirements from other PDFs.	Application software behavior	None	OEM/Customer Review Interface	Shared	Blocked by Customer Clarification	Test
SSR-KEY-002	Certificate handling — Key and Certificate HandlingThe ECU shall manage key and certificate material for Certificate handling across provisioning, storage, use, renewal and revocation per the agreed key lifecycle.From this PDF: REQ-AUTO-00951; REQ-AUTO-00953. This SSR is also supported by requirements from other PDFs.	Certificate handling	Certificate handling	None	Shared	Blocked by Customer Clarification	Review + Test
SSR-KEY-003	Application software behavior — Key and Certificate HandlingThe ECU shall manage key and certificate material for Application software behavior across provisioning, storage, use, renewal and revocation per the agreed key lifecycle.From this PDF: REQ-AUTO-00889.	Application software behavior	None	None	Shared	Blocked by Customer Clarification	Review + Test
SSR-KEY-004	System behavior — Key and Certificate HandlingThe ECU shall manage key and certificate material for System behavior across provisioning, storage, use, renewal and revocation per the agreed key lifecycle.From this PDF: REQ-AUTO-00891; REQ-AUTO-00899; REQ-AUTO-00902; REQ-AUTO-00936; REQ-AUTO-00969; REQ-AUTO-00980.	System behavior	None	None	Supplier-Owned	Candidate	Review + Test
SSR-KEY-005	Backend and IT integration — Key and Certificate HandlingThe ECU shall manage key and certificate material for Backend and IT integration across provisioning, storage, use, renewal and revocation per the agreed key lifecycle.From this PDF: REQ-AUTO-00893; REQ-AUTO-00900; REQ-AUTO-00901; REQ-AUTO-00906; REQ-AUTO-00908; REQ-AUTO-00982.	Backend and IT integration	None	None	Shared	Blocked by Customer Clarification	Review + Test
SSR-RBAC-002	Authentication — Secure Diagnostics / RBACThe ECU shall enforce authenticated, role-authorised access for Authentication, restricting security-relevant diagnostic services per the OEM-agreed role model.From this PDF: REQ-AUTO-00944; REQ-AUTO-00967. This SSR is also supported by requirements from other PDFs.	Authentication	Authentication	None	Shared	Blocked by Customer Clarification	Review + Test
SSR-RBAC-003	Backend and IT integration — Secure Diagnostics / RBACThe ECU shall enforce authenticated, role-authorised access for Backend and IT integration, restricting security-relevant diagnostic services per the OEM-agreed role model.From this PDF: REQ-AUTO-00948; REQ-AUTO-00952. This SSR is also supported by requirements from other PDFs.	Backend and IT integration	None	None	Shared	Blocked by Customer Clarification	Review + Test
SSR-RBAC-004	Application software behavior — Secure Diagnostics / RBACThe ECU shall enforce authenticated, role-authorised access for Application software behavior, restricting security-relevant diagnostic services per the OEM-agreed role model.From this PDF: REQ-AUTO-00890; REQ-AUTO-00910; REQ-AUTO-00927; REQ-AUTO-00949; REQ-AUTO-00973. This SSR is also supported by requirements from other PDFs.	Application software behavior	None	None	Shared	Blocked by Customer Clarification	Review + Test
SSR-SYS-005	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-00879; REQ-AUTO-00882; REQ-AUTO-00884; REQ-AUTO-00885; REQ-AUTO-00897. This SSR is also supported by requirements from other PDFs.	System behavior	None	OEM/Customer Review Interface	Shared	Blocked by Customer Clarification	Test
SSR-SYS-006	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-00904; REQ-AUTO-00909; REQ-AUTO-00917; REQ-AUTO-00918; REQ-AUTO-00926; REQ-AUTO-00945; REQ-AUTO-00946; REQ-AUTO-00954; REQ-AUTO-00958; REQ-AUTO-00970; REQ-AUTO-00972; REQ-AUTO-00974; REQ-AUTO-00978; REQ-AUTO-00981; REQ-AUTO-00985; REQ-AUTO-00986. This SSR is also supported by requirements from other PDFs.	System behavior	None	None	Shared	Ready for Customer Alignment	Test
SSR-SYS-008	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-AUTO-00971. This SSR is also supported by requirements from other PDFs.	Application software behavior	None	OEM/Customer Review Interface	Shared	Blocked by Customer Clarification	Test
SSR-SYS-009	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-00881; REQ-AUTO-00898. This SSR is also supported by requirements from other PDFs.	System behavior	None	OEM/Customer Review Interface	Supplier-Owned	Candidate	Test
SSR-TOOL-002	Backend and IT integration — Tooling / IT / Evidence StorageThe supplier shall provide the tooling, IT infrastructure and evidence storage required for Backend and IT integration.From this PDF: REQ-AUTO-00883; REQ-AUTO-00886; REQ-AUTO-00888; REQ-AUTO-00896; REQ-AUTO-00903; REQ-AUTO-00911; REQ-AUTO-00912; REQ-AUTO-00916; REQ-AUTO-00920; REQ-AUTO-00921; REQ-AUTO-00925; REQ-AUTO-00928; REQ-AUTO-00929; REQ-AUTO-00941; REQ-AUTO-00961; REQ-AUTO-00963; REQ-AUTO-00965; REQ-AUTO-00966. This SSR is also supported by requirements from other PDFs.	Backend and IT integration	None	None	Shared	Blocked by Customer Clarification	Review + Test
SSR-TOOL-003	Backend and IT integration — Tooling / IT / Evidence StorageThe supplier shall provide the tooling, IT infrastructure and evidence storage required for Backend and IT integration.From this PDF: REQ-AUTO-00968; REQ-AUTO-00975; REQ-AUTO-00976; REQ-AUTO-00977. This SSR is also supported by requirements from other PDFs.	Backend and IT integration	None	None	Shared	Ready for Customer Alignment	Review + Test

System / Security Design Impact

Impact Area	Evidence From This PDF
Impacted system features	Application software behavior; Application software behavior; Secure communication and freshness protection; Authentication; Authentication; Security evidence and traceability; Backend and IT integration; Backend and IT integration; Security evidence and traceability; Certificate handling; System behavior
Impacted interfaces	OEM/Customer Review Interface
Impacted security capabilities	Authentication; Certificate handling
Impacted architecture elements	Application Software; Backend and IT Systems; Backend and IT Systems; OEM/Customer Review Interface; Compliance Process; 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; Requirement traceability record; System/architecture design
Tools / IT / hardware / test	High/High/Low; High/High/Medium; High/Low/Low; High/Low/Medium; Low/High/Low; Low/High/Medium; Low/Low/Low; Medium/Low/Medium
Design assumptions introduced	Security-relevant requirement the ECU can own once responsibility/method is confirmed.
Design decisions required	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/High/Low; High/High/Medium; High/Low/Low; High/Low/Medium; Low/High/Low; Low/High/Medium; Low/Low/Low; Medium/Low/Medium

Document Impact Diagram

Document Impact

Generated from document-specific requirement, traceability, SSR, and open-point evidence.

flowchart LR doc["CVS31.pdf"] d0["Authentication"] doc --> d0 d1["Certificate handling"] doc --> d1 f0["Feature: Application software behavior"] doc --> f0 f1["Feature: Application software behavior; Secure communication and freshness protection"] doc --> f1 f2["Feature: Authentication"] doc --> f2 i0["Interface: OEM/Customer Review Interface"] doc --> i0 s0["SSR: SSR-COM-003"] doc --> s0 s1["SSR: SSR-DAI-001"] doc --> s1 s2["SSR: SSR-DAI-002"] doc --> s2 o0["Open point: OP-002"] doc --> o0 o1["Open point: OP-003"] doc --> o1 o2["Open point: OP-004"] doc --> o2

Mermaid source

flowchart LR
  doc["CVS31.pdf"]
  d0["Authentication"]
  doc --> d0
  d1["Certificate handling"]
  doc --> d1
  f0["Feature: Application software behavior"]
  doc --> f0
  f1["Feature: Application software behavior; Secure communication and freshness protection"]
  doc --> f1
  f2["Feature: Authentication"]
  doc --> f2
  i0["Interface: OEM/Customer Review Interface"]
  doc --> i0
  s0["SSR: SSR-COM-003"]
  doc --> s0
  s1["SSR: SSR-DAI-001"]
  doc --> s1
  s2["SSR: SSR-DAI-002"]
  doc --> s2
  o0["Open point: OP-002"]
  doc --> o0
  o1["Open point: OP-003"]
  doc --> o1
  o2["Open point: OP-004"]
  doc --> o2

Traceability

This table is horizontally scrollable. Use the bottom scrollbar to view all columns.

Customer Requirement	SSR	Disposition	Confidence	Reason
REQ-AUTO-00879	SSR-SYS-005	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00880	None	Informational Only	n/a	Non-binding; not derived.
REQ-AUTO-00881	SSR-SYS-009	Covered by Existing Supplier System Requirement	High	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00882	SSR-SYS-005	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00883	SSR-TOOL-002	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00884	SSR-SYS-005	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00885	SSR-SYS-005	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00886	SSR-TOOL-002	Shared Responsibility / CIA Needed	Medium	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00887	SSR-COM-003	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00888	SSR-TOOL-002	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00889	SSR-KEY-003	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00890	SSR-RBAC-004	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00891	SSR-KEY-004	Derive Supplier System Requirement	Medium	Accepted requirement; seed of its SSR cluster.
REQ-AUTO-00892	SSR-DAI-001	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00893	SSR-KEY-005	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00894	SSR-DAI-004	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00895	SSR-DAI-001	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00896	SSR-TOOL-002	Shared Responsibility / CIA Needed	Medium	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00897	SSR-SYS-005	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00898	SSR-SYS-009	Covered by Existing Supplier System Requirement	High	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00899	SSR-KEY-004	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00900	SSR-KEY-005	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00901	SSR-KEY-005	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00902	SSR-KEY-004	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00903	SSR-TOOL-002	Shared Responsibility / CIA Needed	Medium	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00904	SSR-SYS-006	Shared Responsibility / CIA Needed	Medium	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00905	SSR-DAI-002	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00906	SSR-KEY-005	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00907	SSR-DAI-001	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00908	SSR-KEY-005	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00909	SSR-SYS-006	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00910	SSR-RBAC-004	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00911	SSR-TOOL-002	Shared Responsibility / CIA Needed	Medium	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00912	SSR-TOOL-002	Shared Responsibility / CIA Needed	Medium	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00913	SSR-DAI-004	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00914	SSR-COM-003	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00915	SSR-DAI-004	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00916	SSR-TOOL-002	Shared Responsibility / CIA Needed	Medium	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00917	SSR-SYS-006	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00918	SSR-SYS-006	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00919	SSR-DAI-002	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00920	SSR-TOOL-002	Shared Responsibility / CIA Needed	Medium	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00921	SSR-TOOL-002	Shared Responsibility / CIA Needed	Medium	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00922	SSR-COM-003	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00923	SSR-DAI-004	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00924	SSR-DAI-004	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00925	SSR-TOOL-002	Shared Responsibility / CIA Needed	Medium	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00926	SSR-SYS-006	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00927	SSR-RBAC-004	Covered by Existing Supplier System Requirement	Low	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00928	SSR-TOOL-002	Shared Responsibility / CIA Needed	Medium	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00929	SSR-TOOL-002	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00930	SSR-COM-003	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00931	SSR-COM-003	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00932	None	Informational Only	n/a	Non-binding; not derived.
REQ-AUTO-00933	SSR-DAI-001	Covered by Existing Supplier System Requirement	Low	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00934	SSR-DAI-001	Covered by Existing Supplier System Requirement	Low	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00935	SSR-DAI-001	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00936	SSR-KEY-004	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00937	SSR-DAI-001	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00938	SSR-DAI-001	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00939	SSR-DAI-001	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00940	SSR-DAI-001	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00941	SSR-TOOL-002	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00942	SSR-DAI-001	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00943	SSR-DAI-001	Covered by Existing Supplier System Requirement	Low	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00944	SSR-RBAC-002	Covered by Existing Supplier System Requirement	Low	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00945	SSR-SYS-006	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00946	SSR-SYS-006	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00947	None	Informational Only	n/a	Non-binding; not derived.
REQ-AUTO-00948	SSR-RBAC-003	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00949	SSR-RBAC-004	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00950	SSR-DAI-001	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00951	SSR-KEY-002	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00952	SSR-RBAC-003	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00953	SSR-KEY-002	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00954	SSR-SYS-006	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00955	SSR-DAI-001	Covered by Existing Supplier System Requirement	Low	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00956	SSR-DAI-001	Covered by Existing Supplier System Requirement	Low	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00957	SSR-DAI-001	Covered by Existing Supplier System Requirement	Low	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00958	SSR-SYS-006	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00959	SSR-DAI-002	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00960	SSR-DAI-001	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00961	SSR-TOOL-002	Shared Responsibility / CIA Needed	Medium	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00962	SSR-DIAG-004	Shared Responsibility / CIA Needed	Medium	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00963	SSR-TOOL-002	Shared Responsibility / CIA Needed	Medium	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00964	SSR-DIAG-004	Shared Responsibility / CIA Needed	Medium	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00965	SSR-TOOL-002	Shared Responsibility / CIA Needed	Medium	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00966	SSR-TOOL-002	Shared Responsibility / CIA Needed	Medium	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00967	SSR-RBAC-002	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00968	SSR-TOOL-003	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00969	SSR-KEY-004	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00970	SSR-SYS-006	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00971	SSR-SYS-008	Shared Responsibility / CIA Needed	Medium	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00972	SSR-SYS-006	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00973	SSR-RBAC-004	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00974	SSR-SYS-006	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00975	SSR-TOOL-003	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00976	SSR-TOOL-003	Covered by Existing Supplier System Requirement	Low	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00977	SSR-TOOL-003	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00978	SSR-SYS-006	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00979	None	Needs Internal Review	n/a	Low confidence / human review before derivation.
REQ-AUTO-00980	SSR-KEY-004	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00981	SSR-SYS-006	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00982	SSR-KEY-005	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00983	SSR-COM-003	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00984	SSR-COM-003	Shared Responsibility / CIA Needed	Low	Partially accepted; ECU portion mapped, OEM portion needs CIA/RASIC.
REQ-AUTO-00985	SSR-SYS-006	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.
REQ-AUTO-00986	SSR-SYS-006	Covered by Existing Supplier System Requirement	Medium	Accepted requirement; covered by a clustered SSR.

Detailed Evidence

Document intelligence markdown

CVS31

Source PDF: customer-input/pdf/CVS31.pdf
Converted Markdown: converted/markdown/CVS31.md
Document type: Responsibility Agreement / CIA / RASIC
Domain: Key / Certificate Handling
Confidence: High
Evidence basis: Markdown-derived requirements and generated RFQX registers; no downstream PDF analysis.

Executive Summary

Document Abstract

Field	Interpretation
Document Purpose	Confirmed by requirements: this responsibility agreement / cia / rasic contributes 108 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; cybersecurity concept and evidence; responsibility and customer approval model.
Supplier Proposal Impact	Confirmed by requirements: supplier positioning is 20 accept; 24 accept with assumption; 60 partially accept; 1 needs internal review; 3 informational only. The generated traceability links this document to 18 supplier system requirement records.
System / Security Impact	Inferred from mapped features, capabilities, and interfaces: the main design/security impact is core eca system behavior; cybersecurity concept and evidence; responsibility and customer approval model. 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: 3 document-linked open point(s) remain, mainly: Confirm the diagnostic role model, the authorized services per role, and which party owns the diagnostic authorization policy.; Confirm ownership and provisioning flow for keys/certificates (generation, injection, storage, renewal, revocation) between OEM and supplier.; Confirm the update chain ownership (backend/campaign vs. ECU programming) and the authenticity/integrity scheme to be applied. 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.	86	REQ-AUTO-00879; REQ-AUTO-00880; REQ-AUTO-00881
Cybersecurity concept and evidence	Drives cybersecurity concept, risk treatment, verification evidence, and traceability obligations.	67	REQ-AUTO-00881; REQ-AUTO-00883; REQ-AUTO-00886
Responsibility and customer approval model	Creates supplier/OEM allocation decisions for work products, backend infrastructure, approvals, and residual risk.	57	REQ-AUTO-00881; REQ-AUTO-00883; REQ-AUTO-00884
System architecture design	Groups related document requirements into a single engineering theme.	41	REQ-AUTO-00879; REQ-AUTO-00880; REQ-AUTO-00882
Key, certificate, and PKI handling	Affects ECU trust material storage, provisioning, lifecycle ownership, and customer PKI dependencies.	40	REQ-AUTO-00889; REQ-AUTO-00891; REQ-AUTO-00892
System	Groups related document requirements into a single engineering theme.	32	REQ-AUTO-00879; REQ-AUTO-00880; REQ-AUTO-00882
System core	Groups related document requirements into a single engineering theme.	31	REQ-AUTO-00879; REQ-AUTO-00882; REQ-AUTO-00884
Cybersecurity	Groups related document requirements into a single engineering theme.	22	REQ-AUTO-00892; REQ-AUTO-00895; REQ-AUTO-00907

Document Content Structure

Section	Requirements	Critical	Open Points	SSR Links
1 Scope	1	0	0	1
-- 1.1 Summary	1	0	0	1
2 Abbrevations	3	2	0	3
3 subFunctions	43	29	3	12
-- 3.1 verifyCertificateBidirectional	14	9	2	8
-- -- 3.1.1 Request	5	4	2	4
-- -- 3.1.2 Response	9	5	1	6
-- 3.2 proofOfOwnership	21	16	3	8
-- -- 3.2.1 Request	7	6	1	5
-- -- 3.2.2 Response	3	1	0	2
-- -- 3.2.3 Negative Response	7	6	1	4
-- 3.3 deAuthenticate	5	2	1	4
-- -- 3.3.3 Negative Response	5	2	1	4
4 General	55	29	3	14
-- 4.1 Certificate	30	14	2	10
-- -- 4.1.3 D-RBACC extension	9	3	1	6
-- -- 4.1.8 Certificate Validity Time	11	5	1	5
-- 4.2 State-keeping	8	8	1	4
-- 4.5 CRNG	4	1	0	3
-- 4.7 PassiveDeAuthentication	7	3	1	3
-- -- 4.7.1 TimeBasedPassiveDeAuthentication	7	3	1	3
-- 4.9 Authentication completion timer	6	3	1	4
6 Normative references	1	0	0	1

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-00889	77	High risk due to unclear OEM/supplier responsibility	security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	Table 4 – Supported subFunctions (ISO 14229-1:2020) Name verifyCertificateBidirectional proofOfOwnership deAuthenticate AUTH_REQ 155 The server shall not accept an application-layer service 0x29 request when it is received inside an SDT (service 0x84) protected message.
REQ-AUTO-00892	77	High risk due to unclear OEM/supplier responsibility	security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	Table 5 – verifyCertificateBidirectional Request Field Description Type/Value Cvt Included in proofOfOwnershipServer Authentication Request SID Service ID for Authentication service request 0x29 M Yes verifyCertificateBidirectional] Initiate Authentication by verifying the Certificate and generating a Proof of Ownership from the server 0x02 M Yes communicationConfiguration NOT USED 0x00 M Yes lengthOfCertificateClient Length parameter for certificateClient uint16 M Yes certificateClient The Certificate to verify uint8[] M Yes lengthOfChallengeClient Length parameter for challengeClient uint16 M Yes challengeClient See 3.1.1.1 uint8[] M Yes AUTH_REQ 117 Upon reception of a verifyCertificateBidirectional request, the server shall determine whether the Authentication delay timer is currently running.
REQ-AUTO-00893	77	High risk due to unclear OEM/supplier responsibility	security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	AUTH_REQ 118 If upon reception of verifyCertificateBidirectional request the Authentication delay timer is expired, the server shall continue to process the verifyCertificateBidirectional request.
REQ-AUTO-00895	77	High risk due to unclear OEM/supplier responsibility	security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	AUTH_REQ 45 If the server verifies the client certificate as valid, the server shall create the requested client authentication pending state.
REQ-AUTO-00900	77	High risk due to unclear OEM/supplier responsibility	security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	AUTH_REQ 173 The server shall verify the value of lengthOfCertificateClient upon reception of verifyCertificateBidirectional request.
REQ-AUTO-00901	77	High risk due to unclear OEM/supplier responsibility	security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	AUTH_REQ 174 If the lengthOfCertificateClient value is not within the expected range, the server shall send negative response code 0x13 (incorrectMessageLengthOrInvalidFormat).
REQ-AUTO-00906	77	High risk due to unclear OEM/supplier responsibility	security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	3.1.3 Negative Response AUTH_REQ 121 If upon reception of verifyCertificateBidirectional request the Authentication delay timer is running, the server shall respond to the verifyCertificateBidirectional request with a Negative Response Code (NRC) 0x37, indicating requiredTimeDelayNotExpired.
REQ-AUTO-00907	77	High risk due to unclear OEM/supplier responsibility	security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	AUTH_REQ 122 If the server verifies the client certificate as invalid, it shall respond to the verifyCertificateBidirectional request with a Negative Response Code (NRC) 0x10, indicating generalReject.
REQ-AUTO-00908	77	High risk due to unclear OEM/supplier responsibility	security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	AUTH_REQ 123 If the server fails or cannot determine that the authentication pending state was stored, it shall respond to the verifyCertificateBidirectional request with a Negative Response Code (NRC) 0x94, indicating ResourceTemporarilyNotAvailable.
REQ-AUTO-00910	77	High risk due to unclear OEM/supplier responsibility	security relevant; architecture relevant; Partially Accept; linked open point; High estimation impact	Table 7 – proofOfOwnership Request Field Description Type/Value Cvt Included in proofOfOwnershipClient Authentication Request SID Service ID for 0x29 M Yes proofOfOwnership] Verify the Proof of Ownership from the client 0x03 M Yes lengthOfProofOfOwnershipClient This field indicates the length (in octets) of the proofOfOwnershipClient field proofOfOwnershipClient See 3.2.1.1 uint8[] M No lengthOfEphemeralPublicKey Client Length parameter for ephemeralPublicKey Client ephemeralPublicKeyClient See 3.2.1.2 uint16 M Yes AUTH_REQ 110 The server shall verify whether any existing authentication pending state corresponds to the client submitting the proofOfOwnership request.

Open Points

Open Point	Question	Impact	Status
OP-002	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.	Open
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-004	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.	Open

Supplier System Requirements

SSR	Title	Statement	Reqs From This PDF	Other PDFs	Status
SSR-COM-003	Backend and IT integration — Secure Communication and Boundary Control	The ECU shall restrict and protect communication for Backend and IT integration, exposing only OEM-agreed services and applying authenticity/integrity/freshness and boundary controls on allocated signals.	REQ-AUTO-00887; REQ-AUTO-00914; REQ-AUTO-00922; REQ-AUTO-00930; REQ-AUTO-00931; REQ-AUTO-00983; REQ-AUTO-00984	yes	Blocked by Customer Clarification
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-AUTO-00892; REQ-AUTO-00895; REQ-AUTO-00907; REQ-AUTO-00933; REQ-AUTO-00934; REQ-AUTO-00935; REQ-AUTO-00937; REQ-AUTO-00938; REQ-AUTO-00939; REQ-AUTO-00940; REQ-AUTO-00942; REQ-AUTO-00943; REQ-AUTO-00950; REQ-AUTO-00955; REQ-AUTO-00956; REQ-AUTO-00957; REQ-AUTO-00960	yes	Blocked by Customer Clarification
SSR-DAI-002	System behavior — Data Authenticity and Integrity Verification	The ECU shall verify the authenticity and integrity of System behavior data and reject manipulated or unauthenticated data.	REQ-AUTO-00905; REQ-AUTO-00919; REQ-AUTO-00959	yes	Candidate
SSR-DAI-004	Backend and IT integration — Data Authenticity and Integrity Verification	The ECU shall verify the authenticity and integrity of Backend and IT integration data and reject manipulated or unauthenticated data.	REQ-AUTO-00894; REQ-AUTO-00913; REQ-AUTO-00915; REQ-AUTO-00923; REQ-AUTO-00924	yes	Blocked by Customer Clarification
SSR-DIAG-004	Application software behavior — Diagnostic Services	The ECU shall provide the diagnostic services for Application software behavior required by the allocated customer requirements, including the specified services, sessions and data identifiers.	REQ-AUTO-00962; REQ-AUTO-00964	yes	Blocked by Customer Clarification
SSR-KEY-002	Certificate handling — Key and Certificate Handling	The ECU shall manage key and certificate material for Certificate handling across provisioning, storage, use, renewal and revocation per the agreed key lifecycle.	REQ-AUTO-00951; REQ-AUTO-00953	yes	Blocked by Customer Clarification
SSR-KEY-003	Application software behavior — Key and Certificate Handling	The ECU shall manage key and certificate material for Application software behavior across provisioning, storage, use, renewal and revocation per the agreed key lifecycle.	REQ-AUTO-00889	no	Blocked by Customer Clarification
SSR-KEY-004	System behavior — Key and Certificate Handling	The ECU shall manage key and certificate material for System behavior across provisioning, storage, use, renewal and revocation per the agreed key lifecycle.	REQ-AUTO-00891; REQ-AUTO-00899; REQ-AUTO-00902; REQ-AUTO-00936; REQ-AUTO-00969; REQ-AUTO-00980	no	Candidate
SSR-KEY-005	Backend and IT integration — Key and Certificate Handling	The ECU shall manage key and certificate material for Backend and IT integration across provisioning, storage, use, renewal and revocation per the agreed key lifecycle.	REQ-AUTO-00893; REQ-AUTO-00900; REQ-AUTO-00901; REQ-AUTO-00906; REQ-AUTO-00908; REQ-AUTO-00982	no	Blocked by Customer Clarification
SSR-RBAC-002	Authentication — Secure Diagnostics / RBAC	The ECU shall enforce authenticated, role-authorised access for Authentication, restricting security-relevant diagnostic services per the OEM-agreed role model.	REQ-AUTO-00944; REQ-AUTO-00967	yes	Blocked by Customer Clarification
SSR-RBAC-003	Backend and IT integration — Secure Diagnostics / RBAC	The ECU shall enforce authenticated, role-authorised access for Backend and IT integration, restricting security-relevant diagnostic services per the OEM-agreed role model.	REQ-AUTO-00948; REQ-AUTO-00952	yes	Blocked by Customer Clarification
SSR-RBAC-004	Application software behavior — Secure Diagnostics / RBAC	The ECU shall enforce authenticated, role-authorised access for Application software behavior, restricting security-relevant diagnostic services per the OEM-agreed role model.	REQ-AUTO-00890; REQ-AUTO-00910; REQ-AUTO-00927; REQ-AUTO-00949; REQ-AUTO-00973	yes	Blocked by Customer Clarification
SSR-SYS-005	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-00879; REQ-AUTO-00882; REQ-AUTO-00884; REQ-AUTO-00885; REQ-AUTO-00897	yes	Blocked by Customer Clarification
SSR-SYS-006	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-00904; REQ-AUTO-00909; REQ-AUTO-00917; REQ-AUTO-00918; REQ-AUTO-00926; REQ-AUTO-00945; REQ-AUTO-00946; REQ-AUTO-00954; REQ-AUTO-00958; REQ-AUTO-00970; REQ-AUTO-00972; REQ-AUTO-00974; REQ-AUTO-00978; REQ-AUTO-00981; REQ-AUTO-00985; REQ-AUTO-00986	yes	Ready for Customer Alignment
SSR-SYS-008	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-AUTO-00971	yes	Blocked by Customer Clarification
SSR-SYS-009	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-00881; REQ-AUTO-00898	yes	Candidate
SSR-TOOL-002	Backend and IT integration — Tooling / IT / Evidence Storage	The supplier shall provide the tooling, IT infrastructure and evidence storage required for Backend and IT integration.	REQ-AUTO-00883; REQ-AUTO-00886; REQ-AUTO-00888; REQ-AUTO-00896; REQ-AUTO-00903; REQ-AUTO-00911; REQ-AUTO-00912; REQ-AUTO-00916; REQ-AUTO-00920; REQ-AUTO-00921; REQ-AUTO-00925; REQ-AUTO-00928; REQ-AUTO-00929; REQ-AUTO-00941; REQ-AUTO-00961; REQ-AUTO-00963; REQ-AUTO-00965; REQ-AUTO-00966	yes	Blocked by Customer Clarification
SSR-TOOL-003	Backend and IT integration — Tooling / IT / Evidence Storage	The supplier shall provide the tooling, IT infrastructure and evidence storage required for Backend and IT integration.	REQ-AUTO-00968; REQ-AUTO-00975; REQ-AUTO-00976; REQ-AUTO-00977	yes	Ready for Customer Alignment

Design Impact

Impacted System Features: Application software behavior; Application software behavior; Secure communication and freshness protection; Authentication; Authentication; Security evidence and traceability; Backend and IT integration; Backend and IT integration; Security evidence and traceability; Certificate handling; System behavior
Impacted Interfaces: OEM/Customer Review Interface
Impacted Security Capabilities: Authentication; Certificate handling
Impacted Architecture Elements: Application Software; Backend and IT Systems; Backend and IT Systems; OEM/Customer Review Interface; Compliance Process; 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; Requirement traceability record; System/architecture design
Impacted Tools It Hardware Test: High/High/Low; High/High/Medium; High/Low/Low; High/Low/Medium; Low/High/Low; Low/High/Medium; Low/Low/Low; Medium/Low/Medium
Impacted Supplier System Requirements: SSR-COM-003; SSR-DAI-001; SSR-DAI-002; SSR-DAI-004; SSR-DIAG-004; SSR-KEY-002; SSR-KEY-003; SSR-KEY-004 (showing 8 of 18)
Design Assumptions Introduced: Security-relevant requirement the ECU can own once responsibility/method is confirmed.
Design Decisions Required: Agree responsibility split (DIA) for the non-ECU portion.