Abstract
This practitioner note publishes the Seven Anti-Patterns + Four-Question Review Protocol — a practical framework for evaluating TARA quality on automotive cybersecurity programs. The seven anti-patterns describe failure modes that recur across organisations executing TARA (Threat Analysis & Risk Assessment) under ISO/SAE 21434; the four review questions are the audit-time tool that surfaces most of them within an hour of review.
The catalog and protocol were developed from observation across Melina Security’s automotive cybersecurity engagement portfolio in 2024-2025 where TARA review or reconciliation was part of the scoped work. They are designed for OEM and Tier-1 supplier cybersecurity teams executing or reviewing TARA toward UN-R 155 and ISO/SAE 21434 type approval.
“The standard tells you what to produce. The anti-pattern catalog tells you what the produced artifact most often gets wrong. Reviewers without the catalog spend their time checking section completeness; reviewers with it spend their time on the four questions that surface the substantive issues.” — Tatiana K., CEO, Melina Security
1. Why a practitioner catalog
TARA sits at the centre of ISO/SAE 21434 implementation. It is the work product every other cybersecurity engineering activity references: concept-phase risk decisions, item-definition cybersecurity goals, verification-test planning, and the cybersecurity case at type approval. When TARA quality drifts, the downstream evidence chain inherits the drift and surfaces it at audit — by which point remediation cost is high.
The operational pressure that produces TARA quality drift is well understood by practitioners but rarely catalogued. TARA is often executed under engineering-schedule pressure by teams whose primary training is in functional safety, software engineering, or general security rather than automotive cybersecurity specifically. The standard provides a method but does not provide a quality bar that lets a TARA be audited internally before external review. Most organisations rely on external review or audit findings to discover quality gaps.
Practitioner observation is a useful complement to standards-text guidance because the standard cannot list the failure modes that recur across organisations. This catalog attempts to fill that gap.
2. Methodology
Observations are collected from Melina Security automotive cybersecurity engagement practice where TARA review or TARA reconciliation is part of the scoped work. Each observed quality issue is classified into an anti-pattern category and anonymised to remove identifying information about the OEM, supplier, vehicle program, or specific ECU class.
Pattern validation requires observation across at least three independent engagement contexts before inclusion in the catalogue. The seven anti-patterns reported here all meet that threshold. Patterns seen in only one or two engagements are tracked internally for future inclusion as the engagement portfolio expands.
The remediation patterns reported are descriptive of approaches that have produced demonstrated improvement in re-review outcomes. Quantitative effectiveness measurement is out of scope for this catalog.
3. The Seven Anti-Pattern Catalog
The catalog is organised by where in the TARA workflow each anti-pattern surfaces. The intent is that an internal reviewer can use the catalog as a checklist input during TARA close-out, before external review.
3.1 Granularity errors at asset identification
Assets are defined either too coarsely (entire ECU as a single asset) or too finely (every memory region as a separate asset). The most common cause is inheritance from a non-cybersecurity asset register — typically the safety or functional asset register — without re-evaluating granularity for cybersecurity purposes. The consequence is that damage scenarios either obscure material risk by aggregating it at the ECU level, or proliferate unmaintainably at the memory-region level.
Remediation that holds: an explicit granularity rule tied to the accountability boundary of the engineering team that owns the asset. If a different team owns a different aspect of the same physical component, those become separate assets.
3.2 Damage-scenario gaps at the safety/cybersecurity boundary
Damage scenarios under-cover cases where cybersecurity compromise produces safety-relevant outcomes. The cause is structural: cybersecurity and functional-safety teams sit in different reporting lines and review TARA work separately. The consequence is a TARA that passes cybersecurity review but misses scenarios a joint review would catch.
Remediation that works: a structured joint review session with the functional-safety team at the damage-scenario step, with the explicit question “does this damage scenario have safety relevance?“
3.3 Asset-classification drift between phases
Assets identified at concept phase change classification at item-definition phase without traceable rationale. The cause is independent assessment teams operating at each phase. The consequence is a TARA that appears self-consistent within phase but breaks under cross-phase traceability review.
Remediation: explicit phase-transition documentation that lists every asset classification carried forward, with documented rationale for any change.
3.4 Feasibility-rating over-confidence
Feasibility ratings systematically under-rate attack scenarios the assessor team has not personally executed. The cause is a cognitive bias against scenarios outside team experience. The consequence is risk-value computation that produces falsely-low risk for novel attack classes — exactly the classes most worth flagging.
Remediation that produces meaningful re-review delta: cross-team feasibility review with red-team input, particularly for attack scenarios outside assessor-team experience.
3.5 Impact-rating discrepancy between OEM and supplier
OEM and supplier impact ratings for the same asset diverge by one to two levels without documented rationale. The cause is different damage-scenario interpretation between the two parties. The consequence: the cybersecurity-interface agreement defines responsibility against a rating that one party disputes, creating a recurring discussion at every subsequent review cycle.
Remediation: structured OEM-supplier alignment workshop at the cybersecurity-interface boundary, with the cybersecurity-interface agreement as the documented output.
3.6 Treatment-decision documentation gaps
Risk-treatment decisions are documented as “mitigation” without traceable mapping to specific design decisions. The cause is time pressure at TARA close-out. The consequence is downstream verification that cannot trace what was actually mitigated, surfacing as gaps at the cybersecurity case.
Remediation: enforce a treatment-decision template that requires explicit mapping to design decisions, with the cybersecurity case generated from the template rather than written separately.
3.7 Traceability breaks to verification
TARA outputs are not traceably mapped to verification activities. The cause is organisational separation between TARA execution and verification planning. The consequence is a cybersecurity-case documentation gap that surfaces at type-approval review.
Remediation: a TARA-to-verification traceability matrix at TARA sign-off, with verification activity owners signing off on traceability before TARA is considered closed.
4. Anti-pattern frequency
Patterns 3.1 (granularity), 3.4 (feasibility), and 3.7 (traceability) recur in roughly every engagement we run where TARA review is in scope. Patterns 3.2 (safety boundary), 3.3 (phase drift), 3.5 (OEM-supplier discrepancy), and 3.6 (treatment documentation) appear more often in engagements involving the cybersecurity-interface boundary between an OEM and a Tier-1 supplier, where coordination cost amplifies any underlying methodology gap.
The frequency observation that may surprise practitioners: organisational maturity correlates only weakly with anti-pattern frequency. Mature organisations produce TARAs that are more internally consistent and better documented, but the underlying anti-pattern categories appear across maturity levels. The maturity gap shows up in how quickly anti-patterns are detected and remediated, not whether they appear.
“We see the same seven anti-patterns at Tier-1 suppliers with mature ISO/SAE 21434 programs and at first-time TARA executors. The difference is detection latency, not category. Mature organisations catch the patterns at internal review; less mature organisations catch them at external audit or type approval.” — Tatiana K., CEO, Melina Security
5. The Four-Question Review Protocol
OEM teams reviewing supplier-provided TARA, and internal reviewers conducting TARA close-out, should structure the review around four questions rather than around the standard’s section structure. The standard tells the reviewer what to check; the four questions tell the reviewer what to find.
Question 1 — Granularity rule: “Show me the granularity rule that determined what an asset is, and walk me through three examples.” Surfaces anti-pattern 3.1; secondarily 3.3 (phase-drift discrepancies become visible when asset definitions are made explicit).
Question 2 — Safety review: “For each high-impact damage scenario, who from the functional-safety team reviewed it?” Surfaces anti-pattern 3.2 directly. If no name can be provided, the joint review either did not happen or was not documented.
Question 3 — Treatment traceability: “For each risk treatment marked ‘mitigation,’ show me the specific design decision it traces to.” Surfaces anti-pattern 3.6. A reviewer who cannot get a specific design-decision reference within one minute per finding is looking at a TARA with incomplete treatment documentation.
Question 4 — Verification traceability: “Show me the TARA-to-verification traceability matrix and how completeness was checked.” Surfaces anti-pattern 3.7. The matrix should exist as a discrete artifact, not as an implied mapping in the cybersecurity case.
These four questions surface most of the catalogued anti-patterns within an hour of review time. Anti-patterns 3.4 (feasibility over-confidence) and 3.5 (OEM-supplier discrepancy) require additional structured review activities to surface — cross-team feasibility review and OEM-supplier alignment workshop respectively — but the Four-Question Protocol provides the fast-path detection layer.
6. Implications for the cybersecurity case
The cybersecurity case is the artifact that consolidates TARA outputs, design decisions, and verification activities for type approval. A cybersecurity case derived from a TARA with any of the seven anti-patterns inherits those patterns, often in compounded form. Pre-type-approval review of the cybersecurity case should explicitly check for the four review questions; finding a TARA-level anti-pattern at this stage is recoverable but expensive.
The remediation patterns described per anti-pattern in Section 3 are also the patterns that prevent the cybersecurity case from inheriting the defect: explicit granularity rules, joint safety/cybersecurity damage-scenario review, phase-transition documentation, cross-team feasibility review, OEM-supplier alignment, treatment-template enforcement, and TARA-to-verification traceability matrices.
7. Frequently asked questions
Why publish the catalog as a Four-Question Protocol rather than as a longer checklist?
Long checklists do not get used at audit time. Four questions are memorable and survive the operational pressure of an active review session. The longer per-anti-pattern remediation guidance in Section 3 is for internal program design; the four questions are for review execution.
Does the catalog apply to TARAs executed under standards other than ISO/SAE 21434?
The structural causes — organisational separation between cybersecurity and safety teams, assessor cognitive bias on feasibility ratings, time pressure at close-out — apply to any risk-assessment workflow. The specific anti-patterns are described in ISO/SAE 21434 vocabulary because that is the primary frame for our engagement portfolio. Practitioners executing TARAs under SAE J3061 or IEC 62443 can map the patterns onto their vocabulary without losing the operational signal.
How long does it take to remediate a TARA with all seven anti-patterns?
Variable, but the work decomposes. Patterns 3.1 and 3.6 are remediable in days because they are documentation patterns. Patterns 3.2, 3.5, and 3.7 require structured workshops or process changes that take weeks. Patterns 3.3 and 3.4 may require methodology overhauls if the organisation is producing them systematically. We typically scope remediation as a multi-cycle engagement rather than a single revision.
Can the catalog be applied by an internal reviewer without external assessor experience?
Yes. The Four-Question Protocol is specifically designed for internal review use, and the anti-pattern descriptions are written for practitioner self-application. External assessors add value in the structured workshops (joint safety review, OEM-supplier alignment workshop) where independent facilitation produces stronger outcomes than internal facilitation typically achieves.
Is the catalog going to expand?
Yes, as the engagement portfolio expands. Patterns observed in only one or two engagements are tracked internally; once a pattern reaches the three-independent-context threshold, it is added to the published catalog. We expect the catalog to grow to 10-12 patterns over the next 18 months.
Related
- Service: Automotive Cybersecurity
- Industry: Automotive OEMs and Tier-1 suppliers
- Glossary: TARA · ISO/SAE 21434 · UN-R 155
- FAQ: Is UN-R 155 the same as ISO/SAE 21434? · TARA before ECU pentest?