
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.
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.
Security architects, system engineers, requirements engineers and product security managers.
Manufacturers in all six industries we serve.
Next: Secure coding. All modules share one product model.
Why threat modeling matters, where it is required, which problems it prevents and how long it takes.
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.
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.
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.
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.
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.
Tell us about your product and the rule you are facing. You talk to an engineer from the first call.