Programs & Vehicle Architecture: Managing Cybersecurity Across Entire Vehicle Platforms

A modern vehicle platform can contain 70 to 150 Electronic Control Units, multiple network domains, dozens of external interfaces, and hundreds of software components from various suppliers. Performing cybersecurity analysis on each ECU or subsystem in isolation misses the systemic risks that emerge from their interactions. At the same time, managing all cybersecurity work in a single monolithic project becomes unwieldy as the scope grows. Automotive cybersecurity teams need an organizational structure that mirrors the vehicle architecture itself: a hierarchical approach where platform-level oversight coordinates subsystem-level and ECU-level analysis.

ThreatZ Programs provide this organizational structure. A Program represents an entire vehicle platform or product line, containing the vehicle architecture definition and linking to individual cybersecurity projects for each subsystem or ECU. This guide explains how Programs work, how the vehicle architecture canvas enables visual architecture modeling, and how the entire structure supports scalable cybersecurity management across complex vehicle platforms.

Programs vs. Projects: Understanding the Hierarchy

In ThreatZ, Projects and Programs serve fundamentally different roles in the cybersecurity management hierarchy.

A Project is where detailed cybersecurity engineering happens. Each project contains a complete TARA cycle: system modeling, threat modeling, risk assessment, risk treatment, SBOM management, validation and testing, and monitoring configuration. A project typically scopes to a single ECU, a specific subsystem, or a bounded component that can be analyzed as a coherent unit. Projects are where engineers spend their day-to-day work identifying threats, assessing risks, and defining controls.

A Program is the organizational umbrella that groups related projects and provides platform-level visibility. A program represents the entire vehicle — for example, "Model X 2027 Platform" — and contains the vehicle architecture definition that maps out all subsystems and ECUs. Individual cybersecurity projects are linked to specific nodes in this architecture, creating a traceable relationship between the vehicle structure and the security analysis performed on each component.

Key takeaway: Think of Programs as the "what" (the vehicle and its architecture) and Projects as the "how" (the detailed security analysis for each component). Programs provide the big picture; Projects provide the depth.

The 3-Level Vehicle Architecture Hierarchy

ThreatZ models vehicle architecture using a three-level hierarchy that reflects how automotive organizations typically structure their platforms:

Level 1: Vehicle

The top level represents the complete vehicle platform. This is the Program itself, encompassing everything from the highest-level system boundary to the last sensor on the most peripheral bus. The vehicle level captures platform-wide attributes such as the vehicle type (passenger car, commercial vehicle, two-wheeler), target markets and applicable regulations, and the overall cybersecurity strategy and policies that apply across the platform.

Level 2: SubSystem

SubSystems represent functional domains within the vehicle. Typical subsystems include Powertrain, Chassis and Safety, Body Electronics, Infotainment and Connectivity, ADAS/AD, and Telematics. Each subsystem groups the ECUs and components that collaborate to deliver a specific vehicle function. SubSystems serve as organizational containers that help teams understand domain boundaries and identify cross-domain interactions that require special security attention.

Level 3: ECU

ECUs are the individual electronic control units within each subsystem. Each ECU entry in the architecture captures the ECU name and function, its processor architecture and computational resources, the network buses it connects to, its external interfaces (diagnostic ports, wireless connections, sensor inputs), and the software components it runs. ECUs are the nodes where cybersecurity projects are typically linked, as each ECU represents a distinct scope for threat analysis and risk assessment.

This three-level hierarchy is not rigid. Some organizations may model certain components at the subsystem level rather than individual ECU level, depending on the granularity of their analysis. ThreatZ supports both approaches, allowing teams to link projects at either the subsystem or ECU level.

The Vehicle Architecture Canvas

ThreatZ provides an interactive 3D and 2D vehicle architecture canvas for visual architecture modeling. Rather than managing the vehicle architecture through tables and forms alone, the canvas provides a spatial representation where teams can see the physical and logical layout of the vehicle's electronic architecture.

3D Vehicle View

The 3D view presents a vehicle silhouette with ECUs positioned in their approximate physical locations. This spatial awareness matters for security analysis because physical proximity affects attack accessibility. An ECU located in the engine compartment has different physical attack exposure than one mounted behind the dashboard or in the trunk. The 3D view makes these spatial relationships immediately visible, helping teams identify ECUs with high physical accessibility that may require additional tamper protection.

2D Architecture Diagram

The 2D view presents a logical architecture diagram showing subsystems, ECUs, and the network buses connecting them. This view is optimized for understanding communication topology: which ECUs communicate with which, over what bus types, and through which gateways. Network buses are color-coded and labeled with their protocol type, making it easy to distinguish CAN-FD backbone networks from LIN sub-networks and Ethernet segments.

Subsystem and ECU Placement

Teams can place subsystems and ECUs on the canvas through drag-and-drop interaction, configure their properties through inline editing, and establish network connections by drawing bus links between components. The canvas supports the following network bus types for ECU connections:

• CAN-FD — Controller Area Network with Flexible Data-rate, the primary backbone for powertrain and chassis communication.
• Automotive Ethernet — 100BASE-T1 and 1000BASE-T1 for high-bandwidth domains like ADAS, infotainment, and zone controllers.
• LIN — Local Interconnect Network for low-speed peripheral devices such as seat controls, mirror adjustments, and window motors.
• FlexRay — Time-triggered protocol for safety-critical applications requiring deterministic communication.
• MOST — Media Oriented Systems Transport for multimedia and infotainment data streaming.

Unified Blueprints Catalog

One of the most powerful features of the Programs module is the Unified Blueprints catalog. Blueprints are reusable security analysis patterns that encode best-practice threat analyses, risk assessments, and control recommendations for common automotive components and architectures.

What Blueprints Contain

A Blueprint packages a complete security analysis template for a specific component type or architecture pattern. For example, a "Telematics Control Unit" Blueprint might include a pre-defined asset model with common TCU interfaces (cellular modem, GNSS receiver, CAN gateway, Bluetooth, Wi-Fi), a catalog of relevant threats drawn from industry threat databases and real-world attack research, recommended security controls mapped to each threat, cybersecurity requirements derived from the controls, and test case templates for validating the controls.

Blueprint Instantiation

When a team adds a new ECU to their program's vehicle architecture, they can instantiate a Blueprint to populate the linked project with pre-built security analysis content. This instantiation is not a simple copy. ThreatZ adapts the Blueprint content to the specific context: the ECU's actual network connections, its position in the architecture, and the program-level security policies all influence how the Blueprint content is applied.

Blueprints dramatically reduce the time required to start a new cybersecurity analysis. Instead of beginning with a blank project and identifying threats from scratch, teams start with a comprehensive baseline analysis and then customize it for their specific implementation. This approach is particularly valuable for Tier-1 suppliers who analyze similar component types across multiple OEM programs.

Key takeaway: Blueprints encode organizational knowledge into reusable templates. They ensure consistency across projects, accelerate analysis startup, and help junior engineers produce thorough analyses by building on proven patterns rather than starting from zero.

Creating and Linking Security Projects

Once the vehicle architecture is defined, teams create cybersecurity projects and link them to specific subsystems or ECUs in the architecture. This linking establishes a traceable relationship: the program dashboard can aggregate metrics from all linked projects, and navigating the architecture canvas provides direct access to the relevant project for any component.

Projects can be created directly from the architecture canvas by right-clicking an ECU node and selecting "Create Linked Project." This action creates a new project pre-configured with the ECU's name, its network connections, and its interfaces as the initial system model. If a matching Blueprint exists in the catalog, the team can choose to instantiate it during project creation, further accelerating the setup process.

Multiple projects can be linked to a single subsystem or ECU when the analysis is decomposed into multiple scopes. For example, an ADAS ECU might have separate projects for the perception pipeline, the decision-making algorithms, and the actuator interfaces, each analyzing a different aspect of the same hardware platform.

Program Creation Wizard

Creating a new Program follows a guided four-step wizard that ensures all necessary configuration is captured before the team begins work.

Step 1: Program Information

Enter the program name, vehicle type, target markets, planned production dates, and a description of the program scope. This information is used throughout the platform for reporting, filtering, and compliance mapping. The target market selection is particularly important as it determines which regulatory frameworks (UNECE R155, GB 44495, etc.) apply to the program.

Step 2: Team Assignment

Assign team members to the program and define their roles. Program-level roles include Program Owner (full administrative control), Program Manager (architecture and project management), Security Architect (vehicle architecture definition), and Team Member (project-level analysis). Each role maps to specific permissions within the program scope.

Step 3: Policy Selection

Select the cybersecurity policies that apply to this program. Policies define the risk assessment methodology, risk acceptance criteria, required compliance standards, and security control frameworks. Policies are defined at the organization level and can be reused across programs to ensure consistent cybersecurity practices. All projects created within the program inherit the selected policies.

Step 4: Review and Create

Review all configuration before creating the program. Once created, the program opens to the vehicle architecture canvas where the team can begin defining the vehicle structure.

Program Status Lifecycle

Programs progress through a defined status lifecycle that reflects the natural phases of a vehicle program:

• Planning — Initial phase where the vehicle architecture is being defined and cybersecurity projects are being scoped. The program is being set up but detailed analysis has not yet begun.
• Active — The primary working phase where cybersecurity analysis is underway across the program's projects. The vehicle architecture is finalized (or near-final), and teams are conducting TARA, defining controls, and performing validation activities.
• Archived — The program has completed its active phase, typically after vehicle production has ended or the platform has been decommissioned. Archived programs remain fully accessible for reference and audit purposes but are excluded from active dashboards and reporting.

Program Dashboard

The Program dashboard provides platform-level visibility by aggregating data from all linked projects. This aggregation enables leadership and compliance teams to assess the cybersecurity status of the entire vehicle without drilling into individual project details.

Overview Cards

The dashboard presents summary cards showing the total number of linked projects, their completion status, the aggregate count of assets, threats, risks, and controls across all projects, and the program-level compliance score calculated as a weighted average of individual project scores.

Linked Project Metrics

A detailed table lists every linked project with its key metrics: risk count, average risk score, compliance percentage, and project status. This table enables quick identification of projects that need attention — for example, projects with high average risk scores or low compliance percentages that are dragging down the program-level metrics.

Compliance Trends

The dashboard tracks compliance scores over time across all linked projects, showing whether the program's overall cybersecurity posture is improving or declining. This trend visualization is valuable for management reviews and CSMS audit evidence, demonstrating continuous improvement at the platform level.

CAL (Cybersecurity Assurance Level) Tracking

ISO/SAE 21434 defines Cybersecurity Assurance Levels (CAL 1 through CAL 4) that determine the rigor required for cybersecurity activities. Different components within a vehicle may require different CAL levels based on their risk exposure and criticality. ThreatZ tracks CAL assignments across the program, ensuring that each project's analysis rigor matches its required assurance level.

The program dashboard highlights any mismatches where a project linked to a high-CAL component has not yet completed the activities required at that assurance level. This tracking helps teams prioritize their work and ensures that the most critical components receive appropriate analytical depth.

RBAC Roles in Program Context

Programs add a hierarchical dimension to ThreatZ's role-based access control. Program-level roles determine what actions a user can perform within the program scope:

These program-level roles work in conjunction with project-level roles. A user who is a Team Member at the program level but a Project Owner on a specific linked project has full control within that project but limited visibility at the program level.

Tier Limits and Availability

Programs and Vehicle Architecture are available on all paid ThreatZ tiers as part of the Foundation module. However, the number of programs varies by tier:

The Team tier provides sufficient capability for small teams managing a single vehicle program with a limited number of ECUs. Professional and Enterprise tiers unlock the scale and advanced features needed for OEMs and large Tier-1 suppliers managing multiple vehicle platforms simultaneously.

Practical Workflow: From Platform Definition to Linked Analysis

Here is a typical workflow for setting up and using Programs effectively:

1. Create the Program using the four-step wizard. Define the vehicle type, assign the core team, and select applicable cybersecurity policies.
2. Define the vehicle architecture on the canvas. Add subsystems for each functional domain, place ECUs within each subsystem, and configure network bus connections between components.
3. Identify critical components that require cybersecurity analysis. Assign CAL levels based on preliminary risk assessment and regulatory requirements.
4. Create linked projects for each component requiring analysis. Instantiate Blueprints where applicable to accelerate project setup.
5. Conduct detailed analysis within each project. Teams work on their assigned projects performing system modeling, threat analysis, risk assessment, and risk treatment.
6. Monitor progress on the program dashboard. Track project completion, review aggregate metrics, and identify projects that need additional attention or resources.
7. Review compliance trends to demonstrate continuous improvement across the entire vehicle platform. Use program-level reports for management reviews and audit evidence.

Key takeaway: Programs transform cybersecurity management from a collection of independent analyses into a coordinated, platform-level discipline. The vehicle architecture provides the structural backbone, Blueprints accelerate individual analyses, and the program dashboard provides the visibility needed for effective oversight.

Standards & Regulatory Alignment

ThreatZ Programs are designed to map directly to the organizational and project-level requirements of automotive cybersecurity standards. Understanding these alignments ensures that the Program structure serves as a compliance framework, not just a project management convenience.

ISO/SAE 21434 Clause 5: Organizational Cybersecurity Management

ISO/SAE 21434 Clause 5 requires organizations to establish cybersecurity governance at the organizational level, including policies, processes, and responsibilities that span across all vehicle programs. ThreatZ Programs map to these organizational-level CSMS activities by providing the top-level container where cybersecurity policies are defined, team roles are assigned, and governance structures are established. When an organization defines risk acceptance criteria, compliance standards, and security control frameworks at the Program level, these decisions flow down to every linked project — ensuring organizational consistency as required by Clause 5.

ISO/SAE 21434 Clause 6: Project-Dependent Cybersecurity Management

While Clause 5 addresses organizational governance, Clause 6 addresses project-level cybersecurity management — the detailed engineering work performed on specific items and components. ThreatZ Projects within Programs handle this component-level work. Each linked project contains the TARA, risk treatment, and validation activities required by Clause 6 for its specific ECU or subsystem. The Program/Project hierarchy mirrors the standard's own distinction between organizational and project-dependent cybersecurity management.

ISO/SAE 21434 Clauses 5 & 6: Programs provide the organizational-level CSMS governance (Clause 5) while linked Projects handle project-dependent cybersecurity engineering (Clause 6). This structural alignment ensures that ThreatZ users naturally satisfy both levels of management required by the standard.

UNECE R155: Vehicle Lifecycle Coverage

R155 requires the CSMS to cover the entire vehicle lifecycle from concept through post-production and decommissioning. Programs provide the vehicle-level scope needed to satisfy this requirement. The Program status lifecycle (Planning, Active, Archived) maps to the vehicle's progression through development, production, and end-of-life phases. Even after a vehicle platform reaches end-of-life, the archived Program retains all cybersecurity evidence for regulatory reference and potential future audits.

UNECE R156: Software Update Management Across Platforms

R156 requires software update management systems (SUMS) that track the impact of software updates across the vehicle. Programs enable this by maintaining the relationships between all ECU-level projects within a vehicle platform. When a software update affects one ECU, the Program's linked project structure allows teams to assess the update's impact on neighboring ECUs, shared network buses, and cross-domain dependencies. This platform-wide visibility is essential for demonstrating that software updates do not introduce unintended cybersecurity risks in other vehicle subsystems.

EU Cyber Resilience Act: Product-Level Documentation

The CRA requires product-level security documentation that encompasses all components with digital elements. Programs aggregate cybersecurity evidence from all component-level projects into a unified, product-level view. The Program dashboard's aggregate metrics, compliance scores, and trend analysis provide the product-level documentation that the CRA demands, without requiring separate documentation efforts beyond what teams already produce during their normal TARA workflow.

GB 44495: Vehicle-Level Cybersecurity Assessment

China's GB 44495 standard requires vehicle-level cybersecurity assessment, not just component-level analysis. ThreatZ Programs provide the organizational container for this vehicle-level assessment by aggregating threat landscapes, risk profiles, and compliance metrics across all subsystems and ECUs. For manufacturers targeting the Chinese market, the Program structure ensures that the GB 44495 vehicle-level assessment requirements are met through the same workflow used for R155 and ISO/SAE 21434 compliance.

Key takeaway: Programs are not just an organizational convenience — they are the structural embodiment of standards requirements. ISO/SAE 21434's organizational vs. project-level management, R155's vehicle lifecycle coverage, R156's cross-platform update tracking, and the CRA's product-level documentation all map directly to the Program/Project hierarchy in ThreatZ.

OEM & Tier-1 Program Operations

Programs serve different operational purposes for OEMs and Tier-1 suppliers. Understanding these distinct workflows helps organizations configure Programs to match their role in the automotive supply chain.

OEM Vehicle Program Lifecycle

OEM vehicle programs follow well-defined lifecycle phases that ThreatZ Programs align with. During the concept phase, the Program is created with the vehicle architecture defined on the canvas, preliminary CAL levels assigned, and initial cybersecurity policies selected. During development, linked projects are created for each ECU and subsystem, Blueprints are instantiated, and detailed TARA work begins across the platform. At pre-production (PP), the Program dashboard is used to verify that all linked projects meet their compliance targets and that no high-risk items remain untreated. At SOP (Start of Production), the Program status transitions to Active with frozen baselines capturing the production-ready state. During post-production (SOP+), the Program remains active for ongoing monitoring, vulnerability response, and periodic review.

Platform Reuse with Blueprints

OEMs commonly develop multiple vehicle variants (sedan, SUV, truck, crossover) on a shared platform. Blueprints enable reuse of cybersecurity analysis across these variants. When the cybersecurity analysis for the sedan variant's Telematics Control Unit is completed and validated, that analysis can be captured as a Blueprint and instantiated for the same TCU in the SUV and truck variants. The Blueprint adapts to each variant's specific network configuration while preserving the core threat analysis, risk assessments, and control recommendations. This reuse dramatically reduces the cybersecurity engineering effort for platform-derived vehicles while maintaining analysis consistency.

Supplier Management and Traceability

OEMs manage dozens of Tier-1 suppliers, each responsible for specific ECUs or subsystems. Programs enable OEMs to link Tier-1 project deliverables to specific nodes in the vehicle architecture, creating full traceability from the vehicle-level CSMS down to individual supplier contributions. When a Tier-1 supplier delivers their cybersecurity documentation package (including frozen baselines from their own ThreatZ instance), the OEM can verify that the supplier's analysis aligns with the vehicle-level requirements defined in the Program. This traceability supports the supplier cybersecurity assessment process required by ISO/SAE 21434 Clause 7 (distributed cybersecurity activities).

CAL Flow-Down

Cybersecurity Assurance Levels (CAL) are assigned at the vehicle or subsystem level based on the overall risk exposure of the component. Programs enable CAL flow-down: program-level CAL targets cascade to subsystem and ECU projects, ensuring that each project's analysis rigor matches the assurance level required by the vehicle-level risk assessment. If a Program determines that the ADAS subsystem requires CAL 4 (highest rigor), all ECU projects linked to that subsystem inherit CAL 4 requirements. The Program dashboard tracks CAL compliance across all linked projects, highlighting any gaps where a project's analysis depth does not yet meet its required assurance level.

Cross-Functional Collaboration

Vehicle cybersecurity does not exist in isolation from functional safety (ISO 26262) and systems engineering. Programs support coordination between these disciplines by providing a shared vehicle architecture canvas where cybersecurity, safety, and systems engineering teams can visualize the same platform structure. When a Safety Architect assigns an ASIL level to a specific ECU, the Cybersecurity Architect can see this assignment on the shared canvas and ensure that the corresponding cybersecurity project addresses the intersection of safety and security requirements. This cross-functional visibility prevents the siloed analysis that leads to conflicting or incomplete requirements.

Type Approval Scope Definition

Programs define the vehicle-level scope for R155 CSMS certification. When a manufacturer submits for type approval, the Technical Service needs to understand the scope of the cybersecurity management system: which vehicle systems are covered, how the analysis is structured, and how completeness is demonstrated. The Program provides this scope definition through its vehicle architecture canvas (showing all covered subsystems and ECUs), linked project inventory (demonstrating analysis completeness), and aggregate compliance metrics (quantifying overall cybersecurity posture). This Program-level view serves as the entry point for Technical Service auditors, from which they can drill into specific projects for detailed examination.

Post-Production Posture Tracking

After SOP, the cybersecurity posture of the vehicle platform must be continuously monitored as required by R155 Article 7. Programs enable this post-production tracking by maintaining the relationships between all ECU projects and the vehicle architecture. When a new vulnerability is disclosed that affects a specific component, the Program structure allows rapid identification of all affected ECUs across the platform, assessment of the vulnerability's impact on neighboring subsystems, and coordination of the remediation response across multiple Tier-1 suppliers. Program-level baselines created after vulnerability responses document the updated security posture, demonstrating that the manufacturer's CSMS remains effective throughout the vehicle's production and field life.

Key takeaway: Programs provide the operational framework that OEMs and Tier-1 suppliers need to manage cybersecurity at vehicle-platform scale. From CAL flow-down and supplier traceability to type approval scope definition and post-production monitoring, Programs transform cybersecurity management from a collection of independent ECU analyses into a coordinated, platform-level discipline aligned with industry operational practices.