CRA reporting applies since 11 September 2026. Are your products ready?Book a CRA scoping call

Home / AITIGRITY

Threat modeling and concept design

TARA, security concept and security requirements in one module. It shows what needs protection, how it could be attacked and how serious that would be, and turns the result into requirements your teams can build and test, before the architecture is fixed.

1. What this module is

Threat analysis and risk assessment (TARA) for a product or system, the security concept and architecture that follow from it, and the security requirements that put them into practice, each linked to the risk it treats and the standard it fulfils.

2. Why it is useful

  • Every regulation starts with a documented risk assessment: CRA Article 13, ISO/SAE 21434 clause 15, IEC 62443-3-2 and 4-1.
  • A design change in concept costs a fraction of a change after release, and clear requirements tell developers and suppliers exactly what to build.
  • The analysis and its requirements become the reference for every later test and vulnerability decision, traceable for auditors.

3. How it works, briefly

  • You describe the system as blocks: functions, interfaces, data flows.
  • The platform proposes assets, damage scenarios, threat scenarios and attack paths, rates feasibility and risk, and derives the security concept and the security requirements.
  • Your engineers review, adjust and approve. Every decision is recorded with its rationale, and every requirement stays linked to its risk and standard.

4. Who uses it

Security architects, system engineers, requirements engineers and product security managers.

5. Which industries use it

Manufacturers in all six industries we serve.

Connected to

Next: Secure coding. All modules share one product model.

In depth: TARA, security concept and requirements

Why threat modeling matters, where it is required, which problems it prevents and how long it takes.

Why it matters

A threat analysis and risk assessment (TARA) is the foundation of product security. It identifies the assets worth protecting, the ways an attacker could reach them and how severe the damage would be. Its results become security requirements, each with the risk it treats and the standard clause it fulfils, so developers can build them and testers can verify them. Without a sound TARA and traceable requirements, security work is guesswork and cannot be defended in an audit.

Where it is required

ISO/SAE 21434 and UN R155 for vehicles and their components; IEC 62443-3-2 and 4-1 for the risk assessment and IEC 62443-3-3 and 4-2 for system and component requirements in industrial automation; the Cyber Resilience Act (Article 13 and Annex I) for products with digital elements; the risk assessment of the Machinery Regulation; and the FDA premarket guidance and IEC 81001-5-1 for medical devices. Customers also increasingly ask suppliers for the TARA and the security requirements of the components they buy.

Which problems it prevents

Late design changes when a weakness is only found after the architecture is fixed. Failed type approval or conformity assessment because the risk basis is missing. Treated risks that never turn into a requirement, and vague requirements that suppliers interpret differently. Over-engineering, where expensive measures protect assets that carry little risk. And blind spots, where an interface nobody analysed becomes the way in.

Typical effort without tooling

Done manually in workshops and spreadsheets, the path from a first TARA to an agreed security concept typically takes four to six months for a complex product. Writing and tracing the security requirements comes on top, and much of it repeats for every new variant.

With AITIGRITY

AITIGRITY proposes assets, damage scenarios, threat scenarios and attack paths from your system description, rates feasibility and risk, and generates the security requirements from the treated risks, while your engineers review and decide. This shortens the path from TARA to security concept to about two weeks, and the analysis is reused for variants instead of starting again.

Where does your product stand?

Tell us about your product and the rule you are facing. You talk to an engineer from the first call.