STPAWhen Security Controls Exceed the FTTI — Filling the Gap Between HARA and TARA with STPA

VisualPro Tech Brief

When Security Controls Exceed the FTTI — Filling the Gap Between HARA and TARA with STPA

How to catch the moment SecOC authentication delay becomes a functional safety failure, as a "too late" control action

VWAY Tech Brief · October 30, 2026 · About 8 min read

FTTISecOC message authenticationHARATARASTPA UCA "too late"Loss scenarios

01Summary

02The scene: braking that must finish within 50 ms, verification added to every message

The front camera and radar see a stopped vehicle. The AEB controller in the ADAS domain judges a collision risk and sends an emergency braking request over the vehicle bus. The request message carries a SecOC authentication tag (CMAC) and a freshness counter. The brake-by-wire brake ECU recalculates the tag and only applies brake pressure after confirming the request really came from the AEB controller.

The Electronics Weekly article uses exactly this process as its example. The FTTI for brake- and steer-by-wire is typically 10 to 50 ms, and any delay turns directly into braking distance. If the brake ECU verifies AES-128 in software at 2 ms per message and the CAN bus is saturated, the accumulated delay eats deep into the FTTI margin. The article's conclusion is clear: if a braking message exceeds the FTTI because of the security design, that is a functional safety failure in ISO 26262 terms.

No one would argue with that conclusion. But in a real project, where is that sentence written down?

03The HARA and TARA tables have no column for time

Even if both analyses are done in the same workshop, with columns like these the conflict ends up as a single line in the minutes. The safety team issues "FTTI 50 ms" as a requirement, the security team issues "do not execute before successful authentication" as a requirement, and the fact that both collide inside the same 50 ms only surfaces in integration testing.

One point needs correcting. The article recommends deriving TARA impact ratings "directly from the HARA's ASIL". In ISO/SAE 21434, however, the safety impact rating of a damage scenario is based on the severity (S) of ISO 26262-3. ASIL mixes in exposure and controllability, so taking it over as is misses the fact that an attack can change exposure or controllability. What to take over is S, not ASIL.

04STPA asks about time through UCAs

For every control action a controller issues, STPA asks whether it can become unsafe in four ways: not provided, provided when unsafe, provided too early, too late or out of order, and stopped too soon or applied too long. The third question is exactly where the FTTI belongs.

And in an STPA control structure, authentication and the bus sit directly on the control and feedback paths. Authentication verification lives in the brake ECU's control algorithm, bus delay in the control path, and freshness counter synchronization in the brake ECU's process model. Because the security control becomes part of the control loop rather than "another document outside the safety analysis", it naturally gets caught when you write loss scenarios.

05Example: the AEB emergency braking request path

This is a fictional system for education (not the design of any particular vehicle or manufacturer). The FTTI is set to an illustrative 50 ms. There are two losses, injury or loss of life and property damage, and two hazards: "safe distance is not maintained" (H-1) and "hard braking when it is not needed" (H-2). The system constraint reads:

This constraint ties into one sentence what the HARA safety goal and the TARA cybersecurity goal used to state separately.

4 UCAs

UCA-P-4 is what a TARA would have written as a threat scenario. In STPA it sits in the same table, right next to UCA-T-2. Loosen authentication and T-2 shrinks while P-4 grows; tighten it and the reverse happens. Seeing that balance on one screen is the point of this article.

5 loss scenarios

Put the five side by side and you find scenarios pointing in opposite directions. LS-1 and LS-2 arise because the security control is too slow, LS-5 because of an attempt to make it faster. LS-4 is the security control blocking a legitimate request and hiding that fact. If safety and security are analyzed separately, the first three are likely to end up in the safety team's documents, LS-5 in the security team's, and LS-4 in neither.

6 countermeasures

CM-3 needs care. Choosing "brake anyway if verification is late" prevents LS-1 but reopens LS-5. Neither the safety team nor the security team can make this decision alone, which is why both analyses need to sit on the same model.

06A latency budget: turning SC-2 into numbers

System constraint SC-2 can only be verified once it becomes a table like the one below. The numbers are illustrative.

Each cell in this table corresponds to an element on the STPA control and feedback paths. Loss scenarios ask "which cell can overflow?", and countermeasures decide "who proves the upper bound of that cell?".

07What to check tomorrow

Functional safety

• Does the FTTI budget for the safety goal include the security controls (authentication generation and verification) as separate lines?
• Was authentication verification time measured under worst-case conditions, not under normal load?

Cybersecurity

• Is the safety impact rating of TARA damage scenarios taken from severity (S), not from the HARA's ASIL?
• Were the freshness counter acceptance window and the behavior on authentication failure decided together with the safety team?

Architects

• Is the "authentication failed, request discarded" status fed back to the controller that sent the request?
• Has jitter simulation confirmed that safety-critical messages are not pushed back by encrypted, lower-priority traffic?

08Closing

VisualPro can perform HARA, TARA and STPA within a single project. The STPA example in this article was built in VisualPro STPA.

09Frequently Asked Questions